New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

where to ask for support? #5

Open
jobenvil opened this Issue May 29, 2016 · 35 comments

Comments

Projects
None yet
5 participants
@jobenvil

jobenvil commented May 29, 2016

Hi @tobetter where is the place to post or ask for help where you are active?
I would ask which kernel starts to supports uas on odroidxu4? I see on def_conf is istill uncommented. I have usb device controller (JMicron 567) which supports scsi + uas. Thanks!

@tobetter

This comment has been minimized.

Show comment
Hide comment
@tobetter

tobetter May 29, 2016

Owner

@jobenvil it's ok to post here your questions or drop me an email any time. As of now, I've not tested UAS yet. So no proof XU4 kernel can support it perfectly as of now.

Owner

tobetter commented May 29, 2016

@jobenvil it's ok to post here your questions or drop me an email any time. As of now, I've not tested UAS yet. So no proof XU4 kernel can support it perfectly as of now.

@jobenvil

This comment has been minimized.

Show comment
Hide comment
@jobenvil

jobenvil Jun 13, 2016

Thanks Kim.

Enabling in .config CONFIG_USB_UAS=y I have no succes, even with 4.7.-rc.2-next.

I bought two different USB-SATA-Adapter which should support uas:

  • JMicron USA Technology Corp. JMS567
root@hiperborea ~ # lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 004: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 004 Device 003: ID 05e3:0616 Genesys Logic, Inc. hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@hiperborea ~ # lsusb -vvv -d   152d:3562 | grep -ie 'id\|maxpower\|streams\|protocol'
Bus 004 Device 004: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
  bDeviceProtocol         0
  idVendor           0x152d JMicron Technology Corp. / JMicron USA Technology Corp.
  idProduct          0x3562 JMS567 SATA 6Gb/s bridge
    MaxPower                2mA
      bInterfaceProtocol     80 Bulk-Only
      bInterfaceProtocol     98
        MaxStreams             32
        MaxStreams             32
        MaxStreams             32

and

  • ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge
root@hiperborea ~ # lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 003: ID 0bda:8153 Realtek Semiconductor Corp.
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


root@hiperborea ~ # lsusb -vvv -d  174c:55aa | grep -ie 'id\|maxpower\|streams\|protocol'
Bus 004 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
  bDeviceProtocol         0
  idVendor           0x174c ASMedia Technology Inc.
  idProduct          0x55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
    MaxPower                0mA
      bInterfaceProtocol     80 Bulk-Only
      bInterfaceProtocol     98
        MaxStreams             32
        MaxStreams             32
        MaxStreams             32

but kernel messages indicate that uas will not work and therefore Bulk-Only protocol will rule:

[    4.404523] usb 4-1.1: new SuperSpeed USB device number 3 using xhci-hcd
[    4.431002] usb 4-1.1: New USB device found, idVendor=174c, idProduct=55aa
[    4.441566] usb 4-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[    4.452431] usb 4-1.1: Product: ASMT1051
[    4.459905] usb 4-1.1: Manufacturer: asmedia
[    4.467710] usb 4-1.1: SerialNumber: 12345678DCA3
[    4.479543] usb 4-1.1: USB controller xhci-hcd.2.auto does not support streams, which are required by the UAS driver.
[    4.493897] usb 4-1.1: Please try an other USB controller if you wish to use UAS.
[    4.505279] usb 4-1.1: USB controller xhci-hcd.2.auto does not support streams, which are required by the UAS driver.
[    4.519732] usb 4-1.1: Please try an other USB controller if you wish to use UAS.

According to MaxPower = 0 mW and uas-detect.h , I should have the ASM1153. Some hint or direction to dig? Thanks in advance.

jobenvil commented Jun 13, 2016

Thanks Kim.

Enabling in .config CONFIG_USB_UAS=y I have no succes, even with 4.7.-rc.2-next.

I bought two different USB-SATA-Adapter which should support uas:

  • JMicron USA Technology Corp. JMS567
root@hiperborea ~ # lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 004: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 004 Device 003: ID 05e3:0616 Genesys Logic, Inc. hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@hiperborea ~ # lsusb -vvv -d   152d:3562 | grep -ie 'id\|maxpower\|streams\|protocol'
Bus 004 Device 004: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
  bDeviceProtocol         0
  idVendor           0x152d JMicron Technology Corp. / JMicron USA Technology Corp.
  idProduct          0x3562 JMS567 SATA 6Gb/s bridge
    MaxPower                2mA
      bInterfaceProtocol     80 Bulk-Only
      bInterfaceProtocol     98
        MaxStreams             32
        MaxStreams             32
        MaxStreams             32

and

  • ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge
root@hiperborea ~ # lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 003: ID 0bda:8153 Realtek Semiconductor Corp.
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


root@hiperborea ~ # lsusb -vvv -d  174c:55aa | grep -ie 'id\|maxpower\|streams\|protocol'
Bus 004 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
  bDeviceProtocol         0
  idVendor           0x174c ASMedia Technology Inc.
  idProduct          0x55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
    MaxPower                0mA
      bInterfaceProtocol     80 Bulk-Only
      bInterfaceProtocol     98
        MaxStreams             32
        MaxStreams             32
        MaxStreams             32

but kernel messages indicate that uas will not work and therefore Bulk-Only protocol will rule:

[    4.404523] usb 4-1.1: new SuperSpeed USB device number 3 using xhci-hcd
[    4.431002] usb 4-1.1: New USB device found, idVendor=174c, idProduct=55aa
[    4.441566] usb 4-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[    4.452431] usb 4-1.1: Product: ASMT1051
[    4.459905] usb 4-1.1: Manufacturer: asmedia
[    4.467710] usb 4-1.1: SerialNumber: 12345678DCA3
[    4.479543] usb 4-1.1: USB controller xhci-hcd.2.auto does not support streams, which are required by the UAS driver.
[    4.493897] usb 4-1.1: Please try an other USB controller if you wish to use UAS.
[    4.505279] usb 4-1.1: USB controller xhci-hcd.2.auto does not support streams, which are required by the UAS driver.
[    4.519732] usb 4-1.1: Please try an other USB controller if you wish to use UAS.

According to MaxPower = 0 mW and uas-detect.h , I should have the ASM1153. Some hint or direction to dig? Thanks in advance.

@tobetter

This comment has been minimized.

Show comment
Hide comment
@tobetter

tobetter Jun 13, 2016

Owner

Hey @jobenvil,

What's the product of ASM1153?
Any reason you have to use ASM1153, not JMS567?

Owner

tobetter commented Jun 13, 2016

Hey @jobenvil,

What's the product of ASM1153?
Any reason you have to use ASM1153, not JMS567?

@jobenvil

This comment has been minimized.

Show comment
Hide comment
@jobenvil

jobenvil Jun 14, 2016

No special reason, I just bought to test them because they have USB attached SCSI support.

Update: With iotf master branch 4.6.0+ are recogniced both adapters like USB Attached SCSI / uas:

  • Example lsusb -v JM567:
Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98
      iInterface             10 MSC USB Attached SCSI

dmesg JM567

[    8.665627] usb 4-1.1: new SuperSpeed USB device number 3 using xhci-hcd
[    8.686851] usb 4-1.1: New USB device found, idVendor=152d, idProduct=3562
[    8.692283] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    8.699563] usb 4-1.1: Product: AD TO BE II
[    8.703713] usb 4-1.1: Manufacturer: ADMKIV
[    8.707874] usb 4-1.1: SerialNumber: DB123456789628
[    8.724382] scsi host0: uas
[    8.727286] scsi 0:0:0:0: Direct-Access     ADplus   SuperVer         6302 PQ: 0 ANSI: 6
[    8.767014] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[    8.767224] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    8.778375] sd 0:0:0:0: [sda] 4096-byte physical blocks
[    8.784305] sd 0:0:0:0: [sda] Write Protect is off
[    8.788308] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[    8.788680] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    8.881738]  sda: sda1 sda2
[    8.885725] sd 0:0:0:0: [sda] Attached SCSI disk
...
...
[   12.901106] usbcore: registered new interface driver r8152
[   12.931370] usbcore: registered new interface driver cdc_ether
[   13.098440] usb 6-1: reset SuperSpeed USB device number 2 using xhci-hcd
[   13.185062] r8152 6-1:1.0 eth0: v1.08.3
[   13.402296] usb 4-1.1: USB disconnect, device number 3
[   13.421351] sd 0:0:0:0: [sda] tag#0 uas_zap_pending 0 uas-tag 1 inflight: CMD
[   13.421376] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 01 10 00 00 f0 00
[   13.421407] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[   13.421420] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 01 10 00 00 f0 00
[   13.421430] blk_update_request: I/O error, dev sda, sector 272
[   13.426899] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[   13.565685] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00
[   17.135625] usb 4-1.1: new SuperSpeed USB device number 4 using xhci-hcd
[   17.151751] usb 4-1.1: New USB device found, idVendor=152d, idProduct=3562
[   17.151765] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   17.151774] usb 4-1.1: Product: AD TO BE II
[   17.151783] usb 4-1.1: Manufacturer: ADMKIV
[   17.151793] usb 4-1.1: SerialNumber: DB123456789628
[   17.155010] scsi host0: uas
[   17.157219] scsi 0:0:0:0: Direct-Access     ADplus   SuperVer         6302 PQ: 0 ANSI: 6
[   17.206579] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   17.206749] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[   17.206769] sd 0:0:0:0: [sda] 4096-byte physical blocks
[   17.207577] sd 0:0:0:0: [sda] Write Protect is off
[   17.207593] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[   17.207997] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   17.269708]  sda: sda1 sda2
[   17.272640] sd 0:0:0:0: [sda] Attached SCSI disk


  • ASMedia ASM1153:
[    3.534477] usb 4-1.1: new SuperSpeed USB device number 3 using xhci-hcd
[    3.555420] usb 4-1.1: New USB device found, idVendor=174c, idProduct=55aa
[    3.561388] usb 4-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[    3.568613] usb 4-1.1: Product: ASMT1051
[    3.572096] usb 4-1.1: Manufacturer: asmedia
[    3.576515] usb 4-1.1: SerialNumber: 12345678DCA3
[    3.593457] scsi host0: uas
[    3.595907] scsi 0:0:0:0: Direct-Access     ASMT     2115             0    PQ: 0 ANSI: 6
[    3.615155] random: nonblocking pool is initialized
[    3.646398] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    3.646614] sd 0:0:0:0: [sda] Spinning up disk...
[    4.024476] raid6: int32x1  gen()   429 MB/s
[    4.109377] raid6: int32x1  xor()   325 MB/s
[    4.194421] raid6: int32x2  gen()   625 MB/s
[    4.279385] raid6: int32x2  xor()   471 MB/s
[    4.364420] raid6: int32x4  gen()   719 MB/s
[    4.449358] raid6: int32x4  xor()   581 MB/s
[    4.534393] raid6: int32x8  gen()   947 MB/s
[    4.619338] raid6: int32x8  xor()   592 MB/s
[    4.622125] raid6: using algorithm int32x8 gen() 947 MB/s
[    4.627518] raid6: .... xor() 592 MB/s, rmw enabled
[    4.632370] raid6: using intx1 recovery algorithm
[    4.637818] xor: measuring software checksum speed
[    4.649400] .
[    4.689356]    arm4regs  :  2943.200 MB/sec
[    4.739369]    8regs     :  2458.400 MB/sec
[    4.789342]    32regs    :  2351.200 MB/sec
[    4.792046] xor: using function: arm4regs (2943.200 MB/sec)
[    4.810989] Btrfs loaded, assert=on
[    5.654403] ....ready
[    8.670778] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[    8.677382] sd 0:0:0:0: [sda] Write Protect is off
[    8.681583] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[    8.681878] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    8.800104]  sda: sda1 sda2
[    8.803908] sd 0:0:0:0: [sda] Attached SCSI disk

and corresponding lsusb -v:

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98
      iInterface              0

I cannot update you about the uas performance compared with other kernels since I don't have a stable environment to test them. When I have it, I will update you. You may like close the issue.

jobenvil commented Jun 14, 2016

No special reason, I just bought to test them because they have USB attached SCSI support.

Update: With iotf master branch 4.6.0+ are recogniced both adapters like USB Attached SCSI / uas:

  • Example lsusb -v JM567:
Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98
      iInterface             10 MSC USB Attached SCSI

dmesg JM567

[    8.665627] usb 4-1.1: new SuperSpeed USB device number 3 using xhci-hcd
[    8.686851] usb 4-1.1: New USB device found, idVendor=152d, idProduct=3562
[    8.692283] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    8.699563] usb 4-1.1: Product: AD TO BE II
[    8.703713] usb 4-1.1: Manufacturer: ADMKIV
[    8.707874] usb 4-1.1: SerialNumber: DB123456789628
[    8.724382] scsi host0: uas
[    8.727286] scsi 0:0:0:0: Direct-Access     ADplus   SuperVer         6302 PQ: 0 ANSI: 6
[    8.767014] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[    8.767224] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    8.778375] sd 0:0:0:0: [sda] 4096-byte physical blocks
[    8.784305] sd 0:0:0:0: [sda] Write Protect is off
[    8.788308] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[    8.788680] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    8.881738]  sda: sda1 sda2
[    8.885725] sd 0:0:0:0: [sda] Attached SCSI disk
...
...
[   12.901106] usbcore: registered new interface driver r8152
[   12.931370] usbcore: registered new interface driver cdc_ether
[   13.098440] usb 6-1: reset SuperSpeed USB device number 2 using xhci-hcd
[   13.185062] r8152 6-1:1.0 eth0: v1.08.3
[   13.402296] usb 4-1.1: USB disconnect, device number 3
[   13.421351] sd 0:0:0:0: [sda] tag#0 uas_zap_pending 0 uas-tag 1 inflight: CMD
[   13.421376] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 01 10 00 00 f0 00
[   13.421407] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[   13.421420] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 01 10 00 00 f0 00
[   13.421430] blk_update_request: I/O error, dev sda, sector 272
[   13.426899] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[   13.565685] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00
[   17.135625] usb 4-1.1: new SuperSpeed USB device number 4 using xhci-hcd
[   17.151751] usb 4-1.1: New USB device found, idVendor=152d, idProduct=3562
[   17.151765] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   17.151774] usb 4-1.1: Product: AD TO BE II
[   17.151783] usb 4-1.1: Manufacturer: ADMKIV
[   17.151793] usb 4-1.1: SerialNumber: DB123456789628
[   17.155010] scsi host0: uas
[   17.157219] scsi 0:0:0:0: Direct-Access     ADplus   SuperVer         6302 PQ: 0 ANSI: 6
[   17.206579] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   17.206749] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[   17.206769] sd 0:0:0:0: [sda] 4096-byte physical blocks
[   17.207577] sd 0:0:0:0: [sda] Write Protect is off
[   17.207593] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[   17.207997] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   17.269708]  sda: sda1 sda2
[   17.272640] sd 0:0:0:0: [sda] Attached SCSI disk


  • ASMedia ASM1153:
[    3.534477] usb 4-1.1: new SuperSpeed USB device number 3 using xhci-hcd
[    3.555420] usb 4-1.1: New USB device found, idVendor=174c, idProduct=55aa
[    3.561388] usb 4-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[    3.568613] usb 4-1.1: Product: ASMT1051
[    3.572096] usb 4-1.1: Manufacturer: asmedia
[    3.576515] usb 4-1.1: SerialNumber: 12345678DCA3
[    3.593457] scsi host0: uas
[    3.595907] scsi 0:0:0:0: Direct-Access     ASMT     2115             0    PQ: 0 ANSI: 6
[    3.615155] random: nonblocking pool is initialized
[    3.646398] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    3.646614] sd 0:0:0:0: [sda] Spinning up disk...
[    4.024476] raid6: int32x1  gen()   429 MB/s
[    4.109377] raid6: int32x1  xor()   325 MB/s
[    4.194421] raid6: int32x2  gen()   625 MB/s
[    4.279385] raid6: int32x2  xor()   471 MB/s
[    4.364420] raid6: int32x4  gen()   719 MB/s
[    4.449358] raid6: int32x4  xor()   581 MB/s
[    4.534393] raid6: int32x8  gen()   947 MB/s
[    4.619338] raid6: int32x8  xor()   592 MB/s
[    4.622125] raid6: using algorithm int32x8 gen() 947 MB/s
[    4.627518] raid6: .... xor() 592 MB/s, rmw enabled
[    4.632370] raid6: using intx1 recovery algorithm
[    4.637818] xor: measuring software checksum speed
[    4.649400] .
[    4.689356]    arm4regs  :  2943.200 MB/sec
[    4.739369]    8regs     :  2458.400 MB/sec
[    4.789342]    32regs    :  2351.200 MB/sec
[    4.792046] xor: using function: arm4regs (2943.200 MB/sec)
[    4.810989] Btrfs loaded, assert=on
[    5.654403] ....ready
[    8.670778] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[    8.677382] sd 0:0:0:0: [sda] Write Protect is off
[    8.681583] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[    8.681878] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    8.800104]  sda: sda1 sda2
[    8.803908] sd 0:0:0:0: [sda] Attached SCSI disk

and corresponding lsusb -v:

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98
      iInterface              0

I cannot update you about the uas performance compared with other kernels since I don't have a stable environment to test them. When I have it, I will update you. You may like close the issue.

@tobetter

This comment has been minimized.

Show comment
Hide comment
@tobetter

tobetter Jun 14, 2016

Owner

@jobenvil Ok, thank you for update. I recently got a board of JMicro, different chipset with yours. I was planning to adapt it to XU4. FYI, I've started to create a branch with v4.6 recently, hope it could work.
https://github.com/tobetter/linux/commits/odroidxu4-v4.6

Owner

tobetter commented Jun 14, 2016

@jobenvil Ok, thank you for update. I recently got a board of JMicro, different chipset with yours. I was planning to adapt it to XU4. FYI, I've started to create a branch with v4.6 recently, hope it could work.
https://github.com/tobetter/linux/commits/odroidxu4-v4.6

@jobenvil

This comment has been minimized.

Show comment
Hide comment
@jobenvil

jobenvil Jun 14, 2016

FYI, I've started to create a branch with v4.6 recently, hope it could work.
https://github.com/tobetter/linux/commits/odroidxu4-v4.6

@tobetter thank you, this will be very usefull since I'm still testing.

jobenvil commented Jun 14, 2016

FYI, I've started to create a branch with v4.6 recently, hope it could work.
https://github.com/tobetter/linux/commits/odroidxu4-v4.6

@tobetter thank you, this will be very usefull since I'm still testing.

@uDude

This comment has been minimized.

Show comment
Hide comment
@uDude

uDude Jun 14, 2016

Ams1053 works well but does not have pm.
On Jun 14, 2016 5:02 AM, "José Benlloch" notifications@github.com wrote:

FYI, I've started to create a branch with v4.6 recently, hope it could
work.
https://github.com/tobetter/linux/commits/odroidxu4-v4.6

@tobetter https://github.com/tobetter thank you, this will be very
usefull since I'm still testing.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeCKi486kmRnFYru-TlcslWieyyKQks5qLopOgaJpZM4IpQzo
.

uDude commented Jun 14, 2016

Ams1053 works well but does not have pm.
On Jun 14, 2016 5:02 AM, "José Benlloch" notifications@github.com wrote:

FYI, I've started to create a branch with v4.6 recently, hope it could
work.
https://github.com/tobetter/linux/commits/odroidxu4-v4.6

@tobetter https://github.com/tobetter thank you, this will be very
usefull since I'm still testing.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeCKi486kmRnFYru-TlcslWieyyKQks5qLopOgaJpZM4IpQzo
.

@tobetter

This comment has been minimized.

Show comment
Hide comment
@tobetter

tobetter Jun 14, 2016

Owner

@uDude could you share more detail about your running environment? Like kernel version and platform?
@jobenvil would you mind to share your expectation in terms of the performance and how you are planning to measure it?

Owner

tobetter commented Jun 14, 2016

@uDude could you share more detail about your running environment? Like kernel version and platform?
@jobenvil would you mind to share your expectation in terms of the performance and how you are planning to measure it?

@uDude

This comment has been minimized.

Show comment
Hide comment
@uDude

uDude Jun 14, 2016

Sure,

I have xu4 to an asmedia 1053 based chip set (
http://www.datoptic.com/ec/usb3-to-sata3-6gb-s-bridge.html). This connects
to western digital red 3T disks.

Kernel is the tobetter 4.2.x.

I get about 144 MB/s write speed.

I am using CloudDB, Ubuntu 16.04. These are server only so I cannot
comment on sound or video.
On Jun 14, 2016 6:48 AM, "Dongjin Kim" notifications@github.com wrote:

@uDude https://github.com/uDude could you share more detail about your
running environment? Like kernel version and platform?
@jobenvil https://github.com/jobenvil would you mind to share your
expectation in terms of the performance and how you are planning to measure
it?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeIHW0UgS9a1G1HovuTWpzgLr0KBiks5qLqMFgaJpZM4IpQzo
.

uDude commented Jun 14, 2016

Sure,

I have xu4 to an asmedia 1053 based chip set (
http://www.datoptic.com/ec/usb3-to-sata3-6gb-s-bridge.html). This connects
to western digital red 3T disks.

Kernel is the tobetter 4.2.x.

I get about 144 MB/s write speed.

I am using CloudDB, Ubuntu 16.04. These are server only so I cannot
comment on sound or video.
On Jun 14, 2016 6:48 AM, "Dongjin Kim" notifications@github.com wrote:

@uDude https://github.com/uDude could you share more detail about your
running environment? Like kernel version and platform?
@jobenvil https://github.com/jobenvil would you mind to share your
expectation in terms of the performance and how you are planning to measure
it?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeIHW0UgS9a1G1HovuTWpzgLr0KBiks5qLqMFgaJpZM4IpQzo
.

@jobenvil

This comment has been minimized.

Show comment
Hide comment
@jobenvil

jobenvil Jun 14, 2016

@tobetter I read some time ago this sunxi article regarding UASP and found interesting why not to get enabled in odroidxu4 if is only a matter of find out a working UAS adapter. After that, @tkaiser from ARMBIAN asked in ODROID Forum for check the uas performance in OdroidXU4 devices. This is the history behind.

and how you are planning to measure it?

Don't expect more than what I know, like hdparm, dd, iozone, HELIOS LanTest. Basically blocking the uas on kernel module load. @uDude if you have uas enabled, can you try blacklisting the uas module and test performance w/o?

would you mind to share your expectation in terms of the performance

UAS is really performing better than w/o. Check the notes here. On Lemaker Banana Pro running Kernel 4.6.2 / Ubuntu 16.04 using the USB2.0 ports with JM567 I got around 40MB/S for write and read, what it is worth to consider the re-use of the USB2.0 ports again.

jobenvil commented Jun 14, 2016

@tobetter I read some time ago this sunxi article regarding UASP and found interesting why not to get enabled in odroidxu4 if is only a matter of find out a working UAS adapter. After that, @tkaiser from ARMBIAN asked in ODROID Forum for check the uas performance in OdroidXU4 devices. This is the history behind.

and how you are planning to measure it?

Don't expect more than what I know, like hdparm, dd, iozone, HELIOS LanTest. Basically blocking the uas on kernel module load. @uDude if you have uas enabled, can you try blacklisting the uas module and test performance w/o?

would you mind to share your expectation in terms of the performance

UAS is really performing better than w/o. Check the notes here. On Lemaker Banana Pro running Kernel 4.6.2 / Ubuntu 16.04 using the USB2.0 ports with JM567 I got around 40MB/S for write and read, what it is worth to consider the re-use of the USB2.0 ports again.

@uDude

This comment has been minimized.

Show comment
Hide comment
@uDude

uDude Jun 15, 2016

Hmmmm,

I do my builds on the XU4 and somewhere in the recent commits the kernel
compile is broken. See below:

drivers/phy/phy-exynos5-usbdrd.c: In function
‘exynos5420_usbdrd_phy_calibrate’:
drivers/phy/phy-exynos5-usbdrd.c:652:10: warning: ‘return’ with a value, in
function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:666:10: warning: ‘return’ with a value, in
function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:699:9: warning: ‘return’ with a value, in
function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c: At top level:
drivers/phy/phy-exynos5-usbdrd.c:804:28: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
.phy_exynos_calibrate = exynos5420_usbdrd_phy_calibrate,
^
drivers/phy/phy-exynos5-usbdrd.c:804:28: note: (near initialization for
‘exynos5420_usbdrd_phy.phy_exynos_calibrate’)

I didn't think the aufs patch updated the usbdrd. Regardless, when I get a
chance I have a separate branch that compiles that I'll enable the
requested changes on and let you know. I want to do the speed tests
against identical kernels with only that one difference.

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

It will be a few days be patient and I'll get you the requested
comparisons. Note my builds giving 140 MB/s (not 140 Mb/s) are using the
@tobetter defconfig.

uDude

On Tue, Jun 14, 2016 at 10:03 PM, José Benlloch notifications@github.com
wrote:

@tobetter https://github.com/tobetter I read some time ago this sunxi
article regarding UASP http://linux-sunxi.org/USB/UAS and found
interesting why not to get enabled in odroidxu4 if is only a matter of find
out a working UAS adapter. After that, @tkaiser from ARMBIAN asked in
ODROID Forum http://forum.odroid.com/viewtopic.php?f=97&t=17349 for
check the uas performance in OdroidXU4 devices. This is the history behind.

and how you are planning to measure it?

Don't expect more than what I know, like hdparm, dd, iozone, HELIOS
LanTest. Basically blocking the uas on kernel module load. @uDude
https://github.com/uDude if you have uas enabled, can you try
blacklisting the uas module and test performance w/o?

would you mind to share your expectation in terms of the performance

UAS is really performing better than w/o. Check the notes here.
http://pastebin.com/aGZyeryT On Lemaker Banana Pro running Kernel 4.6.2
/ Ubuntu 16.04 using the USB2.0 ports with JM567 I got around 40MB/S for
write and read, what it is worth to consider the re-use of the USB2.0 ports
again.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeIKll4Ek5BRzRsT8e0iTI74tAZKsks5qLyUzgaJpZM4IpQzo
.

uDude commented Jun 15, 2016

Hmmmm,

I do my builds on the XU4 and somewhere in the recent commits the kernel
compile is broken. See below:

drivers/phy/phy-exynos5-usbdrd.c: In function
‘exynos5420_usbdrd_phy_calibrate’:
drivers/phy/phy-exynos5-usbdrd.c:652:10: warning: ‘return’ with a value, in
function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:666:10: warning: ‘return’ with a value, in
function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:699:9: warning: ‘return’ with a value, in
function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c: At top level:
drivers/phy/phy-exynos5-usbdrd.c:804:28: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
.phy_exynos_calibrate = exynos5420_usbdrd_phy_calibrate,
^
drivers/phy/phy-exynos5-usbdrd.c:804:28: note: (near initialization for
‘exynos5420_usbdrd_phy.phy_exynos_calibrate’)

I didn't think the aufs patch updated the usbdrd. Regardless, when I get a
chance I have a separate branch that compiles that I'll enable the
requested changes on and let you know. I want to do the speed tests
against identical kernels with only that one difference.

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

It will be a few days be patient and I'll get you the requested
comparisons. Note my builds giving 140 MB/s (not 140 Mb/s) are using the
@tobetter defconfig.

uDude

On Tue, Jun 14, 2016 at 10:03 PM, José Benlloch notifications@github.com
wrote:

@tobetter https://github.com/tobetter I read some time ago this sunxi
article regarding UASP http://linux-sunxi.org/USB/UAS and found
interesting why not to get enabled in odroidxu4 if is only a matter of find
out a working UAS adapter. After that, @tkaiser from ARMBIAN asked in
ODROID Forum http://forum.odroid.com/viewtopic.php?f=97&t=17349 for
check the uas performance in OdroidXU4 devices. This is the history behind.

and how you are planning to measure it?

Don't expect more than what I know, like hdparm, dd, iozone, HELIOS
LanTest. Basically blocking the uas on kernel module load. @uDude
https://github.com/uDude if you have uas enabled, can you try
blacklisting the uas module and test performance w/o?

would you mind to share your expectation in terms of the performance

UAS is really performing better than w/o. Check the notes here.
http://pastebin.com/aGZyeryT On Lemaker Banana Pro running Kernel 4.6.2
/ Ubuntu 16.04 using the USB2.0 ports with JM567 I got around 40MB/S for
write and read, what it is worth to consider the re-use of the USB2.0 ports
again.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeIKll4Ek5BRzRsT8e0iTI74tAZKsks5qLyUzgaJpZM4IpQzo
.

@uDude

This comment has been minimized.

Show comment
Hide comment
@uDude

uDude Jun 15, 2016

Change the return value of the function to static int from static void and
all is well. I say that w/o testing only that the build completes.

On Wed, Jun 15, 2016 at 1:55 AM, Mike Kyle mfkyle@gmail.com wrote:

Hmmmm,

I do my builds on the XU4 and somewhere in the recent commits the kernel
compile is broken. See below:

drivers/phy/phy-exynos5-usbdrd.c: In function
‘exynos5420_usbdrd_phy_calibrate’:
drivers/phy/phy-exynos5-usbdrd.c:652:10: warning: ‘return’ with a value,
in function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:666:10: warning: ‘return’ with a value,
in function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:699:9: warning: ‘return’ with a value, in
function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c: At top level:
drivers/phy/phy-exynos5-usbdrd.c:804:28: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
.phy_exynos_calibrate = exynos5420_usbdrd_phy_calibrate,
^
drivers/phy/phy-exynos5-usbdrd.c:804:28: note: (near initialization for
‘exynos5420_usbdrd_phy.phy_exynos_calibrate’)

I didn't think the aufs patch updated the usbdrd. Regardless, when I get
a chance I have a separate branch that compiles that I'll enable the
requested changes on and let you know. I want to do the speed tests
against identical kernels with only that one difference.

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

It will be a few days be patient and I'll get you the requested
comparisons. Note my builds giving 140 MB/s (not 140 Mb/s) are using the
@tobetter defconfig.

uDude

On Tue, Jun 14, 2016 at 10:03 PM, José Benlloch notifications@github.com
wrote:

@tobetter https://github.com/tobetter I read some time ago this sunxi
article regarding UASP http://linux-sunxi.org/USB/UAS and found
interesting why not to get enabled in odroidxu4 if is only a matter of find
out a working UAS adapter. After that, @tkaiser from ARMBIAN asked in
ODROID Forum http://forum.odroid.com/viewtopic.php?f=97&t=17349 for
check the uas performance in OdroidXU4 devices. This is the history behind.

and how you are planning to measure it?

Don't expect more than what I know, like hdparm, dd, iozone, HELIOS
LanTest. Basically blocking the uas on kernel module load. @uDude
https://github.com/uDude if you have uas enabled, can you try
blacklisting the uas module and test performance w/o?

would you mind to share your expectation in terms of the performance

UAS is really performing better than w/o. Check the notes here.
http://pastebin.com/aGZyeryT On Lemaker Banana Pro running Kernel
4.6.2 / Ubuntu 16.04 using the USB2.0 ports with JM567 I got around 40MB/S
for write and read, what it is worth to consider the re-use of the USB2.0
ports again.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeIKll4Ek5BRzRsT8e0iTI74tAZKsks5qLyUzgaJpZM4IpQzo
.

uDude commented Jun 15, 2016

Change the return value of the function to static int from static void and
all is well. I say that w/o testing only that the build completes.

On Wed, Jun 15, 2016 at 1:55 AM, Mike Kyle mfkyle@gmail.com wrote:

Hmmmm,

I do my builds on the XU4 and somewhere in the recent commits the kernel
compile is broken. See below:

drivers/phy/phy-exynos5-usbdrd.c: In function
‘exynos5420_usbdrd_phy_calibrate’:
drivers/phy/phy-exynos5-usbdrd.c:652:10: warning: ‘return’ with a value,
in function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:666:10: warning: ‘return’ with a value,
in function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:699:9: warning: ‘return’ with a value, in
function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c: At top level:
drivers/phy/phy-exynos5-usbdrd.c:804:28: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
.phy_exynos_calibrate = exynos5420_usbdrd_phy_calibrate,
^
drivers/phy/phy-exynos5-usbdrd.c:804:28: note: (near initialization for
‘exynos5420_usbdrd_phy.phy_exynos_calibrate’)

I didn't think the aufs patch updated the usbdrd. Regardless, when I get
a chance I have a separate branch that compiles that I'll enable the
requested changes on and let you know. I want to do the speed tests
against identical kernels with only that one difference.

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

It will be a few days be patient and I'll get you the requested
comparisons. Note my builds giving 140 MB/s (not 140 Mb/s) are using the
@tobetter defconfig.

uDude

On Tue, Jun 14, 2016 at 10:03 PM, José Benlloch notifications@github.com
wrote:

@tobetter https://github.com/tobetter I read some time ago this sunxi
article regarding UASP http://linux-sunxi.org/USB/UAS and found
interesting why not to get enabled in odroidxu4 if is only a matter of find
out a working UAS adapter. After that, @tkaiser from ARMBIAN asked in
ODROID Forum http://forum.odroid.com/viewtopic.php?f=97&t=17349 for
check the uas performance in OdroidXU4 devices. This is the history behind.

and how you are planning to measure it?

Don't expect more than what I know, like hdparm, dd, iozone, HELIOS
LanTest. Basically blocking the uas on kernel module load. @uDude
https://github.com/uDude if you have uas enabled, can you try
blacklisting the uas module and test performance w/o?

would you mind to share your expectation in terms of the performance

UAS is really performing better than w/o. Check the notes here.
http://pastebin.com/aGZyeryT On Lemaker Banana Pro running Kernel
4.6.2 / Ubuntu 16.04 using the USB2.0 ports with JM567 I got around 40MB/S
for write and read, what it is worth to consider the re-use of the USB2.0
ports again.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeIKll4Ek5BRzRsT8e0iTI74tAZKsks5qLyUzgaJpZM4IpQzo
.

@tobetter

This comment has been minimized.

Show comment
Hide comment
@tobetter

tobetter Jun 15, 2016

Owner

@uDude I think you need this patch,
13c3c92

Guys, this is good input for me. Actually I am not very expert at such performance tuning and integration, but very interesting...I don't have ASMedia device, would try to purchase if possible to compare with JMicron.

Please keep me in your track. I hope to share you guys with v4.6 kernel in debian or Ubuntu server on next week if possible.

Owner

tobetter commented Jun 15, 2016

@uDude I think you need this patch,
13c3c92

Guys, this is good input for me. Actually I am not very expert at such performance tuning and integration, but very interesting...I don't have ASMedia device, would try to purchase if possible to compare with JMicron.

Please keep me in your track. I hope to share you guys with v4.6 kernel in debian or Ubuntu server on next week if possible.

@uDude

This comment has been minimized.

Show comment
Hide comment
@uDude

uDude Jun 15, 2016

I have two 4.6 kernels ready to test. I need to obtain an adaptor with a
chipset that supports UASP. My ASMEDIA 1053 does not. The 1053E does. I
prefer to stick with a chipset that I know works well with the xu4 ss chip.

I'll scour amazon and see what I can find. If this works It will be worth
the $$ for me. If you know of one please drop me a line.

On Wed, Jun 15, 2016 at 2:29 AM, Mike Kyle mfkyle@gmail.com wrote:

Change the return value of the function to static int from static void and
all is well. I say that w/o testing only that the build completes.

On Wed, Jun 15, 2016 at 1:55 AM, Mike Kyle mfkyle@gmail.com wrote:

Hmmmm,

I do my builds on the XU4 and somewhere in the recent commits the kernel
compile is broken. See below:

drivers/phy/phy-exynos5-usbdrd.c: In function
‘exynos5420_usbdrd_phy_calibrate’:
drivers/phy/phy-exynos5-usbdrd.c:652:10: warning: ‘return’ with a value,
in function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:666:10: warning: ‘return’ with a value,
in function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:699:9: warning: ‘return’ with a value,
in function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c: At top level:
drivers/phy/phy-exynos5-usbdrd.c:804:28: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
.phy_exynos_calibrate = exynos5420_usbdrd_phy_calibrate,
^
drivers/phy/phy-exynos5-usbdrd.c:804:28: note: (near initialization for
‘exynos5420_usbdrd_phy.phy_exynos_calibrate’)

I didn't think the aufs patch updated the usbdrd. Regardless, when I get
a chance I have a separate branch that compiles that I'll enable the
requested changes on and let you know. I want to do the speed tests
against identical kernels with only that one difference.

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

It will be a few days be patient and I'll get you the requested
comparisons. Note my builds giving 140 MB/s (not 140 Mb/s) are using the
@tobetter defconfig.

uDude

On Tue, Jun 14, 2016 at 10:03 PM, José Benlloch <notifications@github.com

wrote:

@tobetter https://github.com/tobetter I read some time ago this sunxi
article regarding UASP http://linux-sunxi.org/USB/UAS and found
interesting why not to get enabled in odroidxu4 if is only a matter of find
out a working UAS adapter. After that, @tkaiser from ARMBIAN asked in
ODROID Forum http://forum.odroid.com/viewtopic.php?f=97&t=17349 for
check the uas performance in OdroidXU4 devices. This is the history behind.

and how you are planning to measure it?

Don't expect more than what I know, like hdparm, dd, iozone, HELIOS
LanTest. Basically blocking the uas on kernel module load. @uDude
https://github.com/uDude if you have uas enabled, can you try
blacklisting the uas module and test performance w/o?

would you mind to share your expectation in terms of the performance

UAS is really performing better than w/o. Check the notes here.
http://pastebin.com/aGZyeryT On Lemaker Banana Pro running Kernel
4.6.2 / Ubuntu 16.04 using the USB2.0 ports with JM567 I got around 40MB/S
for write and read, what it is worth to consider the re-use of the USB2.0
ports again.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeIKll4Ek5BRzRsT8e0iTI74tAZKsks5qLyUzgaJpZM4IpQzo
.

uDude commented Jun 15, 2016

I have two 4.6 kernels ready to test. I need to obtain an adaptor with a
chipset that supports UASP. My ASMEDIA 1053 does not. The 1053E does. I
prefer to stick with a chipset that I know works well with the xu4 ss chip.

I'll scour amazon and see what I can find. If this works It will be worth
the $$ for me. If you know of one please drop me a line.

On Wed, Jun 15, 2016 at 2:29 AM, Mike Kyle mfkyle@gmail.com wrote:

Change the return value of the function to static int from static void and
all is well. I say that w/o testing only that the build completes.

On Wed, Jun 15, 2016 at 1:55 AM, Mike Kyle mfkyle@gmail.com wrote:

Hmmmm,

I do my builds on the XU4 and somewhere in the recent commits the kernel
compile is broken. See below:

drivers/phy/phy-exynos5-usbdrd.c: In function
‘exynos5420_usbdrd_phy_calibrate’:
drivers/phy/phy-exynos5-usbdrd.c:652:10: warning: ‘return’ with a value,
in function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:666:10: warning: ‘return’ with a value,
in function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c:699:9: warning: ‘return’ with a value,
in function returning void
return ret;
^
drivers/phy/phy-exynos5-usbdrd.c: At top level:
drivers/phy/phy-exynos5-usbdrd.c:804:28: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
.phy_exynos_calibrate = exynos5420_usbdrd_phy_calibrate,
^
drivers/phy/phy-exynos5-usbdrd.c:804:28: note: (near initialization for
‘exynos5420_usbdrd_phy.phy_exynos_calibrate’)

I didn't think the aufs patch updated the usbdrd. Regardless, when I get
a chance I have a separate branch that compiles that I'll enable the
requested changes on and let you know. I want to do the speed tests
against identical kernels with only that one difference.

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

It will be a few days be patient and I'll get you the requested
comparisons. Note my builds giving 140 MB/s (not 140 Mb/s) are using the
@tobetter defconfig.

uDude

On Tue, Jun 14, 2016 at 10:03 PM, José Benlloch <notifications@github.com

wrote:

@tobetter https://github.com/tobetter I read some time ago this sunxi
article regarding UASP http://linux-sunxi.org/USB/UAS and found
interesting why not to get enabled in odroidxu4 if is only a matter of find
out a working UAS adapter. After that, @tkaiser from ARMBIAN asked in
ODROID Forum http://forum.odroid.com/viewtopic.php?f=97&t=17349 for
check the uas performance in OdroidXU4 devices. This is the history behind.

and how you are planning to measure it?

Don't expect more than what I know, like hdparm, dd, iozone, HELIOS
LanTest. Basically blocking the uas on kernel module load. @uDude
https://github.com/uDude if you have uas enabled, can you try
blacklisting the uas module and test performance w/o?

would you mind to share your expectation in terms of the performance

UAS is really performing better than w/o. Check the notes here.
http://pastebin.com/aGZyeryT On Lemaker Banana Pro running Kernel
4.6.2 / Ubuntu 16.04 using the USB2.0 ports with JM567 I got around 40MB/S
for write and read, what it is worth to consider the re-use of the USB2.0
ports again.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeIKll4Ek5BRzRsT8e0iTI74tAZKsks5qLyUzgaJpZM4IpQzo
.

@jobenvil

This comment has been minimized.

Show comment
Hide comment
@jobenvil

jobenvil Jun 15, 2016

Some comments:

I had terrible performance with some jmicro chipsets, but the ASMedia 1053 (no port-multiplier) works great for me.

Yes, but newer JMicron chipsets performs well, see these chipsets here and explained. In the past some UAS ASMedia Chipset were blacklisted. Ensure that you get ASM1153 chip and it will work with UAS.

I want to do the speed tests against identical kernels with only that one difference.

Thats the point. It is not a matter of max read/write results, instead a porcentual gain since the other parameters depend on harddisk model, filesystem, I/O scheduler, mounting flags, etc. Don't expect more gain with UAS if your maximal specifications for your hardrive are already 140MB/s as well

I'll scour amazon and see what I can find. If this works It will be worth the $$ for me. If you know of one please drop me a line.

I have these two which really support UAS. See my third post.

jobenvil commented Jun 15, 2016

Some comments:

I had terrible performance with some jmicro chipsets, but the ASMedia 1053 (no port-multiplier) works great for me.

Yes, but newer JMicron chipsets performs well, see these chipsets here and explained. In the past some UAS ASMedia Chipset were blacklisted. Ensure that you get ASM1153 chip and it will work with UAS.

I want to do the speed tests against identical kernels with only that one difference.

Thats the point. It is not a matter of max read/write results, instead a porcentual gain since the other parameters depend on harddisk model, filesystem, I/O scheduler, mounting flags, etc. Don't expect more gain with UAS if your maximal specifications for your hardrive are already 140MB/s as well

I'll scour amazon and see what I can find. If this works It will be worth the $$ for me. If you know of one please drop me a line.

I have these two which really support UAS. See my third post.

@uDude

This comment has been minimized.

Show comment
Hide comment
@uDude

uDude Jun 15, 2016

Not sure where I put it, but I have a 1T Samsung Evo sad that should be
suitable for the tests.
On Jun 15, 2016 2:46 AM, "José Benlloch" notifications@github.com wrote:

Some comments:

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

Yes, but newer JMicron chipsets performs well, see these chipsets here
and explained http://linux-sunxi.org/USB/UAS. In the past some UAS
ASMedia Chipset were blacklisted. Ensure that you get ASM1153 chip and it
will work with UAS.

I want to do the speed tests against identical kernels with only that
one difference
.

Thats the point. It is not a matter of max read/write results, instead a
porcentual gain since the other parameters depend on harddisk model,
filesystem, I/O scheduler, mounting flags, etc. Don't expect more gain with
UAS if your maximal specifications for your hardrive are already 140MB/s as
well

I'll scour amazon and see what I can find. If this works It will be worth
the $$ for me. If you know of one please drop me a line.

I have these two which really support UAS. See my third post.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeHB72WgH3MsCwICMIjNn3Xy1lhX4ks5qL7v9gaJpZM4IpQzo
.

uDude commented Jun 15, 2016

Not sure where I put it, but I have a 1T Samsung Evo sad that should be
suitable for the tests.
On Jun 15, 2016 2:46 AM, "José Benlloch" notifications@github.com wrote:

Some comments:

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

Yes, but newer JMicron chipsets performs well, see these chipsets here
and explained http://linux-sunxi.org/USB/UAS. In the past some UAS
ASMedia Chipset were blacklisted. Ensure that you get ASM1153 chip and it
will work with UAS.

I want to do the speed tests against identical kernels with only that
one difference
.

Thats the point. It is not a matter of max read/write results, instead a
porcentual gain since the other parameters depend on harddisk model,
filesystem, I/O scheduler, mounting flags, etc. Don't expect more gain with
UAS if your maximal specifications for your hardrive are already 140MB/s as
well

I'll scour amazon and see what I can find. If this works It will be worth
the $$ for me. If you know of one please drop me a line.

I have these two which really support UAS. See my third post.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeHB72WgH3MsCwICMIjNn3Xy1lhX4ks5qL7v9gaJpZM4IpQzo
.

@uDude

This comment has been minimized.

Show comment
Hide comment
@uDude

uDude Jun 15, 2016

Regardless, it is clear that UASP should be enabled as a module by default.
On Jun 15, 2016 8:26 AM, "Mike Kyle" mfkyle@gmail.com wrote:

Not sure where I put it, but I have a 1T Samsung Evo sad that should be
suitable for the tests.
On Jun 15, 2016 2:46 AM, "José Benlloch" notifications@github.com wrote:

Some comments:

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

Yes, but newer JMicron chipsets performs well, see these chipsets here
and explained http://linux-sunxi.org/USB/UAS. In the past some UAS
ASMedia Chipset were blacklisted. Ensure that you get ASM1153 chip and it
will work with UAS.

I want to do the speed tests against identical kernels with only that
one difference
.

Thats the point. It is not a matter of max read/write results, instead a
porcentual gain since the other parameters depend on harddisk model,
filesystem, I/O scheduler, mounting flags, etc. Don't expect more gain with
UAS if your maximal specifications for your hardrive are already 140MB/s as
well

I'll scour amazon and see what I can find. If this works It will be worth
the $$ for me. If you know of one please drop me a line.

I have these two which really support UAS. See my third post.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeHB72WgH3MsCwICMIjNn3Xy1lhX4ks5qL7v9gaJpZM4IpQzo
.

uDude commented Jun 15, 2016

Regardless, it is clear that UASP should be enabled as a module by default.
On Jun 15, 2016 8:26 AM, "Mike Kyle" mfkyle@gmail.com wrote:

Not sure where I put it, but I have a 1T Samsung Evo sad that should be
suitable for the tests.
On Jun 15, 2016 2:46 AM, "José Benlloch" notifications@github.com wrote:

Some comments:

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

Yes, but newer JMicron chipsets performs well, see these chipsets here
and explained http://linux-sunxi.org/USB/UAS. In the past some UAS
ASMedia Chipset were blacklisted. Ensure that you get ASM1153 chip and it
will work with UAS.

I want to do the speed tests against identical kernels with only that
one difference
.

Thats the point. It is not a matter of max read/write results, instead a
porcentual gain since the other parameters depend on harddisk model,
filesystem, I/O scheduler, mounting flags, etc. Don't expect more gain with
UAS if your maximal specifications for your hardrive are already 140MB/s as
well

I'll scour amazon and see what I can find. If this works It will be worth
the $$ for me. If you know of one please drop me a line.

I have these two which really support UAS. See my third post.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeHB72WgH3MsCwICMIjNn3Xy1lhX4ks5qL7v9gaJpZM4IpQzo
.

@uDude

This comment has been minimized.

Show comment
Hide comment
@uDude

uDude Jun 21, 2016

So I got a 1153 device in and used an EVO SSD.

W/O UAS I am getting 185 MB/s, with UAS I am getting 210 MB/s (a 15%
increase). Not as attractive as you'd like to see with the EVO, but still
screaming fast for an ARM SBC.

uDude

On Wed, Jun 15, 2016 at 2:30 PM, Mike Kyle mfkyle@gmail.com wrote:

Regardless, it is clear that UASP should be enabled as a module by default.
On Jun 15, 2016 8:26 AM, "Mike Kyle" mfkyle@gmail.com wrote:

Not sure where I put it, but I have a 1T Samsung Evo sad that should be
suitable for the tests.
On Jun 15, 2016 2:46 AM, "José Benlloch" notifications@github.com
wrote:

Some comments:

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

Yes, but newer JMicron chipsets performs well, see these chipsets here
and explained http://linux-sunxi.org/USB/UAS. In the past some UAS
ASMedia Chipset were blacklisted. Ensure that you get ASM1153 chip and it
will work with UAS.

I want to do the speed tests against identical kernels with only that
one difference
.

Thats the point. It is not a matter of max read/write results, instead a
porcentual gain since the other parameters depend on harddisk model,
filesystem, I/O scheduler, mounting flags, etc. Don't expect more gain with
UAS if your maximal specifications for your hardrive are already 140MB/s as
well

I'll scour amazon and see what I can find. If this works It will be
worth the $$ for me. If you know of one please drop me a line.

I have these two which really support UAS. See my third post.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeHB72WgH3MsCwICMIjNn3Xy1lhX4ks5qL7v9gaJpZM4IpQzo
.

uDude commented Jun 21, 2016

So I got a 1153 device in and used an EVO SSD.

W/O UAS I am getting 185 MB/s, with UAS I am getting 210 MB/s (a 15%
increase). Not as attractive as you'd like to see with the EVO, but still
screaming fast for an ARM SBC.

uDude

On Wed, Jun 15, 2016 at 2:30 PM, Mike Kyle mfkyle@gmail.com wrote:

Regardless, it is clear that UASP should be enabled as a module by default.
On Jun 15, 2016 8:26 AM, "Mike Kyle" mfkyle@gmail.com wrote:

Not sure where I put it, but I have a 1T Samsung Evo sad that should be
suitable for the tests.
On Jun 15, 2016 2:46 AM, "José Benlloch" notifications@github.com
wrote:

Some comments:

I had terrible performance with some jmicro chipsets, but the ASMedia
1053 (no port-multiplier) works great for me.

Yes, but newer JMicron chipsets performs well, see these chipsets here
and explained http://linux-sunxi.org/USB/UAS. In the past some UAS
ASMedia Chipset were blacklisted. Ensure that you get ASM1153 chip and it
will work with UAS.

I want to do the speed tests against identical kernels with only that
one difference
.

Thats the point. It is not a matter of max read/write results, instead a
porcentual gain since the other parameters depend on harddisk model,
filesystem, I/O scheduler, mounting flags, etc. Don't expect more gain with
UAS if your maximal specifications for your hardrive are already 140MB/s as
well

I'll scour amazon and see what I can find. If this works It will be
worth the $$ for me. If you know of one please drop me a line.

I have these two which really support UAS. See my third post.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeHB72WgH3MsCwICMIjNn3Xy1lhX4ks5qL7v9gaJpZM4IpQzo
.

@jobenvil

This comment has been minimized.

Show comment
Hide comment
@jobenvil

jobenvil Jun 21, 2016

@uDude awesome, quite amazing speeds! If you have some time free, could you please perform these tests:

iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K
iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K
iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m

you can install the iozone deb package from here. Ensure before run iozone that CPU 's governor is settled to performance:

cpufreq-set -c 0 -g performance; cpufreq-set -c 4 -g performance

jobenvil commented Jun 21, 2016

@uDude awesome, quite amazing speeds! If you have some time free, could you please perform these tests:

iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K
iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K
iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m

you can install the iozone deb package from here. Ensure before run iozone that CPU 's governor is settled to performance:

cpufreq-set -c 0 -g performance; cpufreq-set -c 4 -g performance

@rhkean

This comment has been minimized.

Show comment
Hide comment
@rhkean

rhkean Jun 21, 2016

@jobenvil ,

I've been running the hardkernel 4.2-rc1 kernel with UAS for about 3 months with 12 TB of hard drive space active. I haven't tested with @tobetter 's 4.2 kernel since early April, but I'm pretty sure it worked also. I came over here to see about testing the 4.6 kernel and discovered this discussion.

DietPi.com forum post on speed comparison here

I have 2 Seagate USB3 5TB drives and a 2TB SATA3 drive installed in a VANTEC NST-370A31-BK USB3.1 enclosure.

note the "Driver=uas"

root@keanbean:~# lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
            |__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
                |__ Port 1: Dev 6, If 0, Class=Mass Storage, Driver=uas, 5000M
                |__ Port 2: Dev 7, If 0, Class=Mass Storage, Driver=uas, 5000M
                |__ Port 3: Dev 8, If 0, Class=Mass Storage, Driver=uas, 5000M
            |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 5000M
                |__ Port 1: Dev 9, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 4: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
    |__ Port 1: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 1: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M

rhkean commented Jun 21, 2016

@jobenvil ,

I've been running the hardkernel 4.2-rc1 kernel with UAS for about 3 months with 12 TB of hard drive space active. I haven't tested with @tobetter 's 4.2 kernel since early April, but I'm pretty sure it worked also. I came over here to see about testing the 4.6 kernel and discovered this discussion.

DietPi.com forum post on speed comparison here

I have 2 Seagate USB3 5TB drives and a 2TB SATA3 drive installed in a VANTEC NST-370A31-BK USB3.1 enclosure.

note the "Driver=uas"

root@keanbean:~# lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
            |__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
                |__ Port 1: Dev 6, If 0, Class=Mass Storage, Driver=uas, 5000M
                |__ Port 2: Dev 7, If 0, Class=Mass Storage, Driver=uas, 5000M
                |__ Port 3: Dev 8, If 0, Class=Mass Storage, Driver=uas, 5000M
            |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 5000M
                |__ Port 1: Dev 9, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 4: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
    |__ Port 1: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 1: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
@jobenvil

This comment has been minimized.

Show comment
Hide comment
@jobenvil

jobenvil Jun 21, 2016

@rhkean thanks for the comments. Yes, indeed in my 3rd post, it is indicated that both enclosures work properly with uas. Earlier kernels <4 has already support on UAS.Yes, HardKernel odroidx4_defconfig has UAS module not activated. It is necessary to enable it. This could be a easy PR ;-)
If you have time, can you test with iozone commands.

jobenvil commented Jun 21, 2016

@rhkean thanks for the comments. Yes, indeed in my 3rd post, it is indicated that both enclosures work properly with uas. Earlier kernels <4 has already support on UAS.Yes, HardKernel odroidx4_defconfig has UAS module not activated. It is necessary to enable it. This could be a easy PR ;-)
If you have time, can you test with iozone commands.

@rhkean

This comment has been minimized.

Show comment
Hide comment
@rhkean

rhkean Jun 22, 2016

how does iozone work? There's no option to specify a device to test? And the man page makes reference system-wide performance. If that is the case, wouldn't it be testing all drives and averaging them? And, if that is so, wouldn't that include your boot device which could be pretty slow if you're using a sub-class-10 uSD?

Anyhow... tests are running... I'll paste the results when i have them.

rhkean commented Jun 22, 2016

how does iozone work? There's no option to specify a device to test? And the man page makes reference system-wide performance. If that is the case, wouldn't it be testing all drives and averaging them? And, if that is so, wouldn't that include your boot device which could be pretty slow if you're using a sub-class-10 uSD?

Anyhow... tests are running... I'll paste the results when i have them.

@rhkean

This comment has been minimized.

Show comment
Hide comment
@rhkean

rhkean Jun 22, 2016

nevermind... I'm an idiot.... It just clicked in my head that the test is dependent on $PWD

rhkean commented Jun 22, 2016

nevermind... I'm an idiot.... It just clicked in my head that the test is dependent on $PWD

@rhkean

This comment has been minimized.

Show comment
Hide comment
@rhkean

rhkean Jun 22, 2016

Here's from one of the Seagate Expansion 5TB drive

root@keanbean:/srv/data/data2# cpufreq-info -o
          minimum CPU frequency  -  maximum CPU frequency  -  governor
CPU  0       200000 kHz ( 14 %)  -    1400000 kHz (100 %)  -  performance
CPU  1       200000 kHz ( 10 %)  -    2000000 kHz (100 %)  -  performance
CPU  2       200000 kHz ( 10 %)  -    2000000 kHz (100 %)  -  performance
CPU  3       200000 kHz ( 10 %)  -    2000000 kHz (100 %)  -  performance
CPU  4       200000 kHz ( 10 %)  -    2000000 kHz (100 %)  -  performance
CPU  5       200000 kHz ( 14 %)  -    1400000 kHz (100 %)  -  performance
CPU  6       200000 kHz ( 14 %)  -    1400000 kHz (100 %)  -  performance
CPU  7       200000 kHz ( 14 %)  -    1400000 kHz (100 %)  -  performance
root@keanbean:/srv/data/data2# iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K
        Iozone: Performance Test of File I/O
                Version $Revision: 3.397 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                     Ben England.

        Run began: Tue Jun 21 22:28:18 2016

        Auto Mode
        Using maximum file size of 4096000 kilobytes.
        File size set to 4096000 KB
        Record Size 4 KB
        Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K
        Output is in Kbytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random  random    bkwd   record   stride
              KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
         4096000       4   94362  102709    71886    71798

iozone test complete.
root@keanbean:/srv/data/data2# iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K
        Iozone: Performance Test of File I/O
                Version $Revision: 3.397 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                     Ben England.

        Run began: Tue Jun 21 22:31:40 2016

        Auto Mode
        Using maximum file size of 4096000 kilobytes.
        File size set to 4096000 KB
        Record Size 1024 KB
        Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K
        Output is in Kbytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random  random    bkwd   record   stride
              KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
         4096000    1024  107345  110874   104107   108021

iozone test complete.
root@keanbean:/srv/data/data2# iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
        Iozone: Performance Test of File I/O
                Version $Revision: 3.397 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                     Ben England.

        Run began: Tue Jun 21 22:34:17 2016

        OPS Mode. Output is in operations per second.
        Include fsync in write timing
        No retest option selected
        Record Size 4 KB
        File size set to 2048000 KB
        Command line used: iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random  random    bkwd   record   stride
              KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
         2048000       4   25653       0    23837        0     329    1007

iozone test complete.

rhkean commented Jun 22, 2016

Here's from one of the Seagate Expansion 5TB drive

root@keanbean:/srv/data/data2# cpufreq-info -o
          minimum CPU frequency  -  maximum CPU frequency  -  governor
CPU  0       200000 kHz ( 14 %)  -    1400000 kHz (100 %)  -  performance
CPU  1       200000 kHz ( 10 %)  -    2000000 kHz (100 %)  -  performance
CPU  2       200000 kHz ( 10 %)  -    2000000 kHz (100 %)  -  performance
CPU  3       200000 kHz ( 10 %)  -    2000000 kHz (100 %)  -  performance
CPU  4       200000 kHz ( 10 %)  -    2000000 kHz (100 %)  -  performance
CPU  5       200000 kHz ( 14 %)  -    1400000 kHz (100 %)  -  performance
CPU  6       200000 kHz ( 14 %)  -    1400000 kHz (100 %)  -  performance
CPU  7       200000 kHz ( 14 %)  -    1400000 kHz (100 %)  -  performance
root@keanbean:/srv/data/data2# iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K
        Iozone: Performance Test of File I/O
                Version $Revision: 3.397 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                     Ben England.

        Run began: Tue Jun 21 22:28:18 2016

        Auto Mode
        Using maximum file size of 4096000 kilobytes.
        File size set to 4096000 KB
        Record Size 4 KB
        Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K
        Output is in Kbytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random  random    bkwd   record   stride
              KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
         4096000       4   94362  102709    71886    71798

iozone test complete.
root@keanbean:/srv/data/data2# iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K
        Iozone: Performance Test of File I/O
                Version $Revision: 3.397 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                     Ben England.

        Run began: Tue Jun 21 22:31:40 2016

        Auto Mode
        Using maximum file size of 4096000 kilobytes.
        File size set to 4096000 KB
        Record Size 1024 KB
        Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K
        Output is in Kbytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random  random    bkwd   record   stride
              KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
         4096000    1024  107345  110874   104107   108021

iozone test complete.
root@keanbean:/srv/data/data2# iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
        Iozone: Performance Test of File I/O
                Version $Revision: 3.397 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                     Ben England.

        Run began: Tue Jun 21 22:34:17 2016

        OPS Mode. Output is in operations per second.
        Include fsync in write timing
        No retest option selected
        Record Size 4 KB
        File size set to 2048000 KB
        Command line used: iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random  random    bkwd   record   stride
              KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
         2048000       4   25653       0    23837        0     329    1007

iozone test complete.

@uDude

This comment has been minimized.

Show comment
Hide comment
@uDude

uDude Jun 22, 2016

I would use 40GB rather than 10. The reason performance a hours jump abbot
60 or 70%. The write performance will stay in the 15 to 30 percent increaae.

I'll try \of get to iozone testing on identical @tobetter 4.2 kernel with
and w/o uas. Informal testing shows noticeable increases using an EVO 840
1T SSD. Hard numbers coming from a setup here.
On Jun 21, 2016 10:14 PM, "Robert Kean" notifications@github.com wrote:

Here's from one of the Seagate Expansion 5TB drive

root@keanbean:/srv/data/data2# cpufreq-info -o
minimum CPU frequency - maximum CPU frequency - governor
CPU 0 200000 kHz ( 14 %) - 1400000 kHz (100 %) - performance
CPU 1 200000 kHz ( 10 %) - 2000000 kHz (100 %) - performance
CPU 2 200000 kHz ( 10 %) - 2000000 kHz (100 %) - performance
CPU 3 200000 kHz ( 10 %) - 2000000 kHz (100 %) - performance
CPU 4 200000 kHz ( 10 %) - 2000000 kHz (100 %) - performance
CPU 5 200000 kHz ( 14 %) - 1400000 kHz (100 %) - performance
CPU 6 200000 kHz ( 14 %) - 1400000 kHz (100 %) - performance
CPU 7 200000 kHz ( 14 %) - 1400000 kHz (100 %) - performance
root@keanbean:/srv/data/data2# iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K
Iozone: Performance Test of File I/O
Version $Revision: 3.397 $
Compiled for 32 bit mode.
Build: linux

    Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                 Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                 Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                 Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                 Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                 Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                 Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                 Ben England.

    Run began: Tue Jun 21 22:28:18 2016

    Auto Mode
    Using maximum file size of 4096000 kilobytes.
    File size set to 4096000 KB
    Record Size 4 KB
    Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K
    Output is in Kbytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 Kbytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                        random  random    bkwd   record   stride
          KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
     4096000       4   94362  102709    71886    71798

iozone test complete.
root@keanbean:/srv/data/data2# iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K
Iozone: Performance Test of File I/O
Version $Revision: 3.397 $
Compiled for 32 bit mode.
Build: linux

    Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                 Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                 Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                 Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                 Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                 Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                 Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                 Ben England.

    Run began: Tue Jun 21 22:31:40 2016

    Auto Mode
    Using maximum file size of 4096000 kilobytes.
    File size set to 4096000 KB
    Record Size 1024 KB
    Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K
    Output is in Kbytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 Kbytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                        random  random    bkwd   record   stride
          KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
     4096000    1024  107345  110874   104107   108021

iozone test complete.
root@keanbean:/srv/data/data2# iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
Iozone: Performance Test of File I/O
Version $Revision: 3.397 $
Compiled for 32 bit mode.
Build: linux

    Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                 Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                 Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                 Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                 Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                 Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                 Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                 Ben England.

    Run began: Tue Jun 21 22:34:17 2016

    OPS Mode. Output is in operations per second.
    Include fsync in write timing
    No retest option selected
    Record Size 4 KB
    File size set to 2048000 KB
    Command line used: iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 Kbytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                        random  random    bkwd   record   stride
          KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
     2048000       4   25653       0    23837        0     329    1007

iozone test complete.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeDehqax4ZNlqZc3PIUqscgtOwFOYks5qOLajgaJpZM4IpQzo
.

uDude commented Jun 22, 2016

I would use 40GB rather than 10. The reason performance a hours jump abbot
60 or 70%. The write performance will stay in the 15 to 30 percent increaae.

I'll try \of get to iozone testing on identical @tobetter 4.2 kernel with
and w/o uas. Informal testing shows noticeable increases using an EVO 840
1T SSD. Hard numbers coming from a setup here.
On Jun 21, 2016 10:14 PM, "Robert Kean" notifications@github.com wrote:

Here's from one of the Seagate Expansion 5TB drive

root@keanbean:/srv/data/data2# cpufreq-info -o
minimum CPU frequency - maximum CPU frequency - governor
CPU 0 200000 kHz ( 14 %) - 1400000 kHz (100 %) - performance
CPU 1 200000 kHz ( 10 %) - 2000000 kHz (100 %) - performance
CPU 2 200000 kHz ( 10 %) - 2000000 kHz (100 %) - performance
CPU 3 200000 kHz ( 10 %) - 2000000 kHz (100 %) - performance
CPU 4 200000 kHz ( 10 %) - 2000000 kHz (100 %) - performance
CPU 5 200000 kHz ( 14 %) - 1400000 kHz (100 %) - performance
CPU 6 200000 kHz ( 14 %) - 1400000 kHz (100 %) - performance
CPU 7 200000 kHz ( 14 %) - 1400000 kHz (100 %) - performance
root@keanbean:/srv/data/data2# iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K
Iozone: Performance Test of File I/O
Version $Revision: 3.397 $
Compiled for 32 bit mode.
Build: linux

    Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                 Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                 Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                 Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                 Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                 Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                 Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                 Ben England.

    Run began: Tue Jun 21 22:28:18 2016

    Auto Mode
    Using maximum file size of 4096000 kilobytes.
    File size set to 4096000 KB
    Record Size 4 KB
    Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K
    Output is in Kbytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 Kbytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                        random  random    bkwd   record   stride
          KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
     4096000       4   94362  102709    71886    71798

iozone test complete.
root@keanbean:/srv/data/data2# iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K
Iozone: Performance Test of File I/O
Version $Revision: 3.397 $
Compiled for 32 bit mode.
Build: linux

    Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                 Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                 Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                 Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                 Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                 Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                 Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                 Ben England.

    Run began: Tue Jun 21 22:31:40 2016

    Auto Mode
    Using maximum file size of 4096000 kilobytes.
    File size set to 4096000 KB
    Record Size 1024 KB
    Command line used: iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K
    Output is in Kbytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 Kbytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                        random  random    bkwd   record   stride
          KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
     4096000    1024  107345  110874   104107   108021

iozone test complete.
root@keanbean:/srv/data/data2# iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
Iozone: Performance Test of File I/O
Version $Revision: 3.397 $
Compiled for 32 bit mode.
Build: linux

    Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                 Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                 Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                 Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                 Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                 Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                 Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
                 Ben England.

    Run began: Tue Jun 21 22:34:17 2016

    OPS Mode. Output is in operations per second.
    Include fsync in write timing
    No retest option selected
    Record Size 4 KB
    File size set to 2048000 KB
    Command line used: iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 Kbytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                        random  random    bkwd   record   stride
          KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
     2048000       4   25653       0    23837        0     329    1007

iozone test complete.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMeDehqax4ZNlqZc3PIUqscgtOwFOYks5qOLajgaJpZM4IpQzo
.

@jobenvil

This comment has been minimized.

Show comment
Hide comment
@jobenvil

jobenvil Jun 22, 2016

@uDude Info: for me was not working blocking the uas module. When I blocked it, the device was not listed and therefore not possible to test. It was necessary to recompile.

jobenvil commented Jun 22, 2016

@uDude Info: for me was not working blocking the uas module. When I blocked it, the device was not listed and therefore not possible to test. It was necessary to recompile.

@uDude

This comment has been minimized.

Show comment
Hide comment
@uDude

uDude Jun 23, 2016

I tested with separate kernels, as well.
On Jun 22, 2016 12:03 AM, "José Benlloch" notifications@github.com wrote:

@uDude https://github.com/uDude Info: for me was not working blocking
the uas module. When I blocked it, the device was not listed and therefore
not possible to test. It was necessary to recompile.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMePuPU59D2ywEMhho0a8AMq55__V1ks5qONApgaJpZM4IpQzo
.

uDude commented Jun 23, 2016

I tested with separate kernels, as well.
On Jun 22, 2016 12:03 AM, "José Benlloch" notifications@github.com wrote:

@uDude https://github.com/uDude Info: for me was not working blocking
the uas module. When I blocked it, the device was not listed and therefore
not possible to test. It was necessary to recompile.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AIiMePuPU59D2ywEMhho0a8AMq55__V1ks5qONApgaJpZM4IpQzo
.

@rhkean

This comment has been minimized.

Show comment
Hide comment
@rhkean

rhkean Jun 23, 2016

VANTEC NST-370A31-BK USB 3.1 enclosure

chipset: Bus 004 Device 008: ID 174c:1351 ASMedia Technology Inc.
ASM1351 chipset

interestingly, the writes are a 2-15% slower, but the reads are 40-45% faster
iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K

module write rewrite read reread
usb-storage 184369 194620 144026 145958
uas 171599 185977 208177 212003

iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K

module write rewrite read reread
usb-storage 189773 193279 147610 150657
uas 161176 189238 211724 212117

iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m

module write rewrite read reread random read random write
usb-storage 45745 0 36518 0 294 224
uas 39719 0 51881 0 330 225

rhkean commented Jun 23, 2016

VANTEC NST-370A31-BK USB 3.1 enclosure

chipset: Bus 004 Device 008: ID 174c:1351 ASMedia Technology Inc.
ASM1351 chipset

interestingly, the writes are a 2-15% slower, but the reads are 40-45% faster
iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K

module write rewrite read reread
usb-storage 184369 194620 144026 145958
uas 171599 185977 208177 212003

iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 1024K

module write rewrite read reread
usb-storage 189773 193279 147610 150657
uas 161176 189238 211724 212117

iozone -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 2000m

module write rewrite read reread random read random write
usb-storage 45745 0 36518 0 294 224
uas 39719 0 51881 0 330 225
@jobenvil

This comment has been minimized.

Show comment
Hide comment
@jobenvil

jobenvil Jun 23, 2016

@rhkean is the second iozone command with 4kor 1024k? Is your Kernel still 4.2-rc1? Your info is very wellcome, since I don't have such performant harddrives or enclosures. I'm observing right now that independently of the uas, the results are tinted or oscillating to much -in my case- because the properly task distribution of the tasks in the diferent type of CPUs. Because less frequency cores are being used and they get in some point of the tests saturated. I tested harddisk and adapters in another ARMv7 SoC with two equal cores and the results were not oscillating so much.

jobenvil commented Jun 23, 2016

@rhkean is the second iozone command with 4kor 1024k? Is your Kernel still 4.2-rc1? Your info is very wellcome, since I don't have such performant harddrives or enclosures. I'm observing right now that independently of the uas, the results are tinted or oscillating to much -in my case- because the properly task distribution of the tasks in the diferent type of CPUs. Because less frequency cores are being used and they get in some point of the tests saturated. I tested harddisk and adapters in another ARMv7 SoC with two equal cores and the results were not oscillating so much.

@rhkean

This comment has been minimized.

Show comment
Hide comment
@rhkean

rhkean Jun 23, 2016

is the second iozone command with 4kor 1024k?

1024K .... sorry, bad copy/paste.

Is your Kernel still 4.2-rc1?

user1@odroidxu4:~$ uname -a
Linux odroidxu4.local.net 4.2.0-rc1+ #2 SMP PREEMPT Sun Jun 19 08:42:58 BST 2016 armv7l GNU/Linux

rhkean commented Jun 23, 2016

is the second iozone command with 4kor 1024k?

1024K .... sorry, bad copy/paste.

Is your Kernel still 4.2-rc1?

user1@odroidxu4:~$ uname -a
Linux odroidxu4.local.net 4.2.0-rc1+ #2 SMP PREEMPT Sun Jun 19 08:42:58 BST 2016 armv7l GNU/Linux

@rhkean

This comment has been minimized.

Show comment
Hide comment
@rhkean

rhkean Jun 24, 2016

I tried testing with this 4.6 kernel, but I can't get it to boot.... I opened a separate ticket for that, though (see #6 ).

rhkean commented Jun 24, 2016

I tried testing with this 4.6 kernel, but I can't get it to boot.... I opened a separate ticket for that, though (see #6 ).

@tobetter

This comment has been minimized.

Show comment
Hide comment
@tobetter

tobetter Jul 6, 2016

Owner

Hello, please visit the link if you guys want to try another Debian/Ubuntu image on ODROID-XU4. Please keep in mind that the images would have many bugs and not stable enough for your purpose. Any feedback would be welcomed. :)

http://linuxfactory.or.kr/dokuwiki/doku.php?id=yet_another_debian_ubuntu_release_for_odroid-xu4&#pre-installed_packages

Owner

tobetter commented Jul 6, 2016

Hello, please visit the link if you guys want to try another Debian/Ubuntu image on ODROID-XU4. Please keep in mind that the images would have many bugs and not stable enough for your purpose. Any feedback would be welcomed. :)

http://linuxfactory.or.kr/dokuwiki/doku.php?id=yet_another_debian_ubuntu_release_for_odroid-xu4&#pre-installed_packages

mhaehnel pushed a commit to mhaehnel/linux that referenced this issue Sep 6, 2016

kexec: fix double-free when failing to relocate the purgatory
If kexec_apply_relocations fails, kexec_load_purgatory frees pi->sechdrs
and pi->purgatory_buf.  This is redundant, because in case of error
kimage_file_prepare_segments calls kimage_file_post_load_cleanup, which
will also free those buffers.

This causes two warnings like the following, one for pi->sechdrs and the
other for pi->purgatory_buf:

  kexec-bzImage64: Loading purgatory failed
  ------------[ cut here ]------------
  WARNING: CPU: 1 PID: 2119 at mm/vmalloc.c:1490 __vunmap+0xc1/0xd0
  Trying to vfree() nonexistent vm area (ffffc90000e91000)
  Modules linked in:
  CPU: 1 PID: 2119 Comm: kexec Not tainted 4.8.0-rc3+ #5
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
    dump_stack+0x4d/0x65
    __warn+0xcb/0xf0
    warn_slowpath_fmt+0x4f/0x60
    ? find_vmap_area+0x19/0x70
    ? kimage_file_post_load_cleanup+0x47/0xb0
    __vunmap+0xc1/0xd0
    vfree+0x2e/0x70
    kimage_file_post_load_cleanup+0x5e/0xb0
    SyS_kexec_file_load+0x448/0x680
    ? putname+0x54/0x60
    ? do_sys_open+0x190/0x1f0
    entry_SYSCALL_64_fastpath+0x13/0x8f
  ---[ end trace 158bb74f5950ca2b ]---

Fix by setting pi->sechdrs an pi->purgatory_buf to NULL, since vfree
won't try to free a NULL pointer.

Link: http://lkml.kernel.org/r/1472083546-23683-1-git-send-email-bauerman@linux.vnet.ibm.com
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
@jobenvil

This comment has been minimized.

Show comment
Hide comment
@jobenvil

jobenvil Sep 20, 2016

Considering following test setup:

  • cpufreq-set to performance both A7&A15 cores
  • MicroSDHC 32GB EVO Plus UHS-I Grade 1 Class 10, date: 07/2016
  • SSD Samsung 850 EVO 500GB, Firmware Revision EMT02B6Q
  • USB3/SATA6 enclousure: idProduct ASMT1051 (0x55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge)

Tested OdroidXU4 branches:

  1. Kernel: ioft/linux branch || Kernel 4.8-rc5 || default odroidxu4_defconfig with UAS Support
  2. Kernel: tobetter/linux branch || kernel 4.8-rc5+ || default odroidxu4_defconfig without UAS

1) Performance on SSD:

Command line tests:

1.- iozone -e -I -a -s 100M -r 4k -r 16k -r 32k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

  • Results without uas (usb-storage modus):
KB reclen write rewrite read reread random read random write
102400 4 15085 14353 16074 16183 14223 14199
102400 16 44326 52025 49768 49678 48749 51244
102400 32 76708 77953 80884 78109 78348 84464
102400 512 192734 200385 169273 172458 177746 209328
102400 1024 188233 207142 176447 176386 176189 211852
102400 16384 163030 215054 178055 178316 178484 215469
  • Results with with uas:
KB reclen write rewrite read reread random read random write
102400 4 15919 18279 22359 22342 17333 21088
102400 16 60395 63605 71811 71835 57757 64621
102400 32 98007 104145 104709 104633 87834 105577
102400 512 211427 229984 188341 188498 185005 238125
102400 1024 255740 259705 226446 226927 224105 269753
102400 16384 260751 333293 317813 317566 317351 334061

2.- dd if=/dev/zero of=test oflag=direct bs=8M count=64 && dd if=test of=/dev/null iflag=direct bs=8M && rm test

  • Results tobetter 4.8-rc5 Kernel:

536870912 bytes (537 MB, 512 MiB) copied, 3,40853 s, 158 MB/s for Write
536870912 bytes (537 MB, 512 MiB) copied, 2,85195 s, 188 MB/s for Read

  • Results ioft 4.8-rc5 Kernel:

536870912 bytes (537 MB, 512 MiB) copied, 1,98129 s, 271 MB/s for Write
536870912 bytes (537 MB, 512 MiB) copied, 1,86621 s, 288 MB/s for Read

3.- hdparm -tT /dev/sda1 and hdparm -t --direct /dev/sda1

  • Results tobetter 4.8-rc5 Kernel:
Timing cached reads:   872 MB in  2.00 seconds = 435.31 MB/sec
Timing buffered disk reads: 596 MB in  3.00 seconds = 198.48 MB/sec
Timing O_DIRECT disk reads: 514 MB in  3.00 seconds = 171.30 MB/sec
  • Results ioft 4.8-rc5 Kernel:
Timing cached reads:   856 MB in  2.00 seconds = 427.38 MB/sec
Timing buffered disk reads: 806 MB in  3.01 seconds = 268.12 MB/sec
Timing O_DIRECT disk reads: 652 MB in  3.00 seconds = 217.14 MB/sec

4.- HELIOS LanTest (SAMBA):

  • Results tobetter 4.8-rc5 Kernel:

tobetter 4 8-rc5 lantest ssd

  • Results ioft 4.8-rc5 Kernel:

ioft 4 8-rc5 lantest ssd

2) Performance on MicroSDHC

Command line tests:

1.- iozone -e -I -a -s 100M -r 4k -r 16k -r 32k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

  • Results tobetter 4.8-rc5 Kernel with awesome UHS-I patch:
KB reclen write rewrite read reread random read random write
102400 4 4252 4209 12177 12176 12131 4330
102400 16 19081 20295 31904 31571 32115 20364
102400 32 30360 30919 38230 38046 37685 31072
102400 512 57890 58322 65399 65356 65384 58563
102400 1024 59893 59565 67419 67416 67378 60509
102400 16384 58663 63522 75495 75465 75496 63752
  • Results ioft 4.8-rc5 Kernel:
KB reclen write rewrite read reread random read random write
102400 4 2159 2746 8168 8100 8166 2845
102400 16 10498 11342 15344 15277 15579 11504
102400 32 13997 14942 17800 17840 17729 14593
102400 512 19671 19739 21763 21764 21756 20550
102400 1024 19020 19938 21965 21982 21980 20705
102400 16384 20199 21383 22791 22776 22791 21413

2.- dd if=/dev/zero of=test oflag=direct bs=8M count=64 && dd if=test of=/dev/null iflag=direct bs=8M && rm test

  • Results tobetter 4.8-rc5 Kernel (has UHS-I patch. dmesg like ultra high speed):

536870912 bytes (537 MB, 512 MiB) copied, 25,1051 s, 21,4 MB/s for Write
536870912 bytes (537 MB, 512 MiB) copied, 6,92232 s, 77,6 MB/s for Read

  • Results ioft 4.8-rc5 Kernel (it doesn't have UHS-I patch. dmesg like high speed):

536870912 bytes (537 MB, 512 MiB) copied, 35,2372 s, 15,2 MB/s for Write
536870912 bytes (537 MB, 512 MiB) copied, 23,0035 s, 23,3 MB/s for Read

3.- hdparm -tT /dev/mmcblk1p2 and hdparm -t --direct /dev/mmcblk1p2

  • Results tobetter 4.8-rc5 Kernel:
Timing cached reads:   854 MB in  2.00 seconds = 426.94 MB/sec
Timing buffered disk reads: 180 MB in  3.02 seconds =  59.55 MB/sec
Timing O_DIRECT disk reads: 178 MB in  3.02 seconds =  59.02 MB/sec
  • Results ioft 4.8-rc5 Kernel:
Timing cached reads:   814 MB in  2.00 seconds = 406.69 MB/sec
Timing buffered disk reads:  64 MB in  3.04 seconds =  21.03 MB/sec
Timing O_DIRECT disk reads:  64 MB in  3.01 seconds =  21.29 MB/sec

4.- HELIOS LanTest (SAMBA):

  • Results tobetter 4.8-rc5 Kernel:

tobetter 4 8-rc5 lantest usdhc

  • Results ioft 4.8-rc5 Kernel:

ioft 4 8-rc5 lantest usdhc


Having:

  1. Samba configuration

jobenvil commented Sep 20, 2016

Considering following test setup:

  • cpufreq-set to performance both A7&A15 cores
  • MicroSDHC 32GB EVO Plus UHS-I Grade 1 Class 10, date: 07/2016
  • SSD Samsung 850 EVO 500GB, Firmware Revision EMT02B6Q
  • USB3/SATA6 enclousure: idProduct ASMT1051 (0x55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge)

Tested OdroidXU4 branches:

  1. Kernel: ioft/linux branch || Kernel 4.8-rc5 || default odroidxu4_defconfig with UAS Support
  2. Kernel: tobetter/linux branch || kernel 4.8-rc5+ || default odroidxu4_defconfig without UAS

1) Performance on SSD:

Command line tests:

1.- iozone -e -I -a -s 100M -r 4k -r 16k -r 32k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

  • Results without uas (usb-storage modus):
KB reclen write rewrite read reread random read random write
102400 4 15085 14353 16074 16183 14223 14199
102400 16 44326 52025 49768 49678 48749 51244
102400 32 76708 77953 80884 78109 78348 84464
102400 512 192734 200385 169273 172458 177746 209328
102400 1024 188233 207142 176447 176386 176189 211852
102400 16384 163030 215054 178055 178316 178484 215469
  • Results with with uas:
KB reclen write rewrite read reread random read random write
102400 4 15919 18279 22359 22342 17333 21088
102400 16 60395 63605 71811 71835 57757 64621
102400 32 98007 104145 104709 104633 87834 105577
102400 512 211427 229984 188341 188498 185005 238125
102400 1024 255740 259705 226446 226927 224105 269753
102400 16384 260751 333293 317813 317566 317351 334061

2.- dd if=/dev/zero of=test oflag=direct bs=8M count=64 && dd if=test of=/dev/null iflag=direct bs=8M && rm test

  • Results tobetter 4.8-rc5 Kernel:

536870912 bytes (537 MB, 512 MiB) copied, 3,40853 s, 158 MB/s for Write
536870912 bytes (537 MB, 512 MiB) copied, 2,85195 s, 188 MB/s for Read

  • Results ioft 4.8-rc5 Kernel:

536870912 bytes (537 MB, 512 MiB) copied, 1,98129 s, 271 MB/s for Write
536870912 bytes (537 MB, 512 MiB) copied, 1,86621 s, 288 MB/s for Read

3.- hdparm -tT /dev/sda1 and hdparm -t --direct /dev/sda1

  • Results tobetter 4.8-rc5 Kernel:
Timing cached reads:   872 MB in  2.00 seconds = 435.31 MB/sec
Timing buffered disk reads: 596 MB in  3.00 seconds = 198.48 MB/sec
Timing O_DIRECT disk reads: 514 MB in  3.00 seconds = 171.30 MB/sec
  • Results ioft 4.8-rc5 Kernel:
Timing cached reads:   856 MB in  2.00 seconds = 427.38 MB/sec
Timing buffered disk reads: 806 MB in  3.01 seconds = 268.12 MB/sec
Timing O_DIRECT disk reads: 652 MB in  3.00 seconds = 217.14 MB/sec

4.- HELIOS LanTest (SAMBA):

  • Results tobetter 4.8-rc5 Kernel:

tobetter 4 8-rc5 lantest ssd

  • Results ioft 4.8-rc5 Kernel:

ioft 4 8-rc5 lantest ssd

2) Performance on MicroSDHC

Command line tests:

1.- iozone -e -I -a -s 100M -r 4k -r 16k -r 32k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

  • Results tobetter 4.8-rc5 Kernel with awesome UHS-I patch:
KB reclen write rewrite read reread random read random write
102400 4 4252 4209 12177 12176 12131 4330
102400 16 19081 20295 31904 31571 32115 20364
102400 32 30360 30919 38230 38046 37685 31072
102400 512 57890 58322 65399 65356 65384 58563
102400 1024 59893 59565 67419 67416 67378 60509
102400 16384 58663 63522 75495 75465 75496 63752
  • Results ioft 4.8-rc5 Kernel:
KB reclen write rewrite read reread random read random write
102400 4 2159 2746 8168 8100 8166 2845
102400 16 10498 11342 15344 15277 15579 11504
102400 32 13997 14942 17800 17840 17729 14593
102400 512 19671 19739 21763 21764 21756 20550
102400 1024 19020 19938 21965 21982 21980 20705
102400 16384 20199 21383 22791 22776 22791 21413

2.- dd if=/dev/zero of=test oflag=direct bs=8M count=64 && dd if=test of=/dev/null iflag=direct bs=8M && rm test

  • Results tobetter 4.8-rc5 Kernel (has UHS-I patch. dmesg like ultra high speed):

536870912 bytes (537 MB, 512 MiB) copied, 25,1051 s, 21,4 MB/s for Write
536870912 bytes (537 MB, 512 MiB) copied, 6,92232 s, 77,6 MB/s for Read

  • Results ioft 4.8-rc5 Kernel (it doesn't have UHS-I patch. dmesg like high speed):

536870912 bytes (537 MB, 512 MiB) copied, 35,2372 s, 15,2 MB/s for Write
536870912 bytes (537 MB, 512 MiB) copied, 23,0035 s, 23,3 MB/s for Read

3.- hdparm -tT /dev/mmcblk1p2 and hdparm -t --direct /dev/mmcblk1p2

  • Results tobetter 4.8-rc5 Kernel:
Timing cached reads:   854 MB in  2.00 seconds = 426.94 MB/sec
Timing buffered disk reads: 180 MB in  3.02 seconds =  59.55 MB/sec
Timing O_DIRECT disk reads: 178 MB in  3.02 seconds =  59.02 MB/sec
  • Results ioft 4.8-rc5 Kernel:
Timing cached reads:   814 MB in  2.00 seconds = 406.69 MB/sec
Timing buffered disk reads:  64 MB in  3.04 seconds =  21.03 MB/sec
Timing O_DIRECT disk reads:  64 MB in  3.01 seconds =  21.29 MB/sec

4.- HELIOS LanTest (SAMBA):

  • Results tobetter 4.8-rc5 Kernel:

tobetter 4 8-rc5 lantest usdhc

  • Results ioft 4.8-rc5 Kernel:

ioft 4 8-rc5 lantest usdhc


Having:

  1. Samba configuration

mhaehnel pushed a commit to mhaehnel/linux that referenced this issue Sep 26, 2016

ath9k: fix client mode beacon configuration
For pure station mode, iter_data.primary_beacon_vif was used and passed
to ath_beacon_config, but not set to the station vif.
This was causing the following warning:

[  100.310919] ------------[ cut here ]------------
[  100.315683] WARNING: CPU: 0 PID: 7 at compat-wireless-2016-06-20/drivers/net/wireless/ath/ath9k/beacon.c:642 ath9k_calculate_summary_state+0x250/0x60c [ath9k]()
[  100.402028] CPU: 0 PID: 7 Comm: kworker/u2:1 Tainted: G        W       4.4.15 #5
[  100.409676] Workqueue: phy0 ieee80211_ibss_leave [mac80211]
[  100.415351] Stack : 8736e98c 870b4b20 87a25b54 800a6800 8782a080 80400d63 8039b96c 00000007
[  100.415351]    803c5edc 87875914 80400000 800a47cc 87a25b54 800a6800 803a0fd8 80400000
[  100.415351]    00000003 87875914 80400000 80094ae0 87a25b54 8787594c 00000000 801ef308
[  100.415351]    803ffe70 801ef300 87193d58 87b3a400 87b3ad00 70687930 00000000 00000000
[  100.415351]    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  100.415351]    ...
[  100.451703] Call Trace:
[  100.454235] [<800a6800>] vprintk_default+0x24/0x30
[  100.459110] [<800a47cc>] printk+0x2c/0x38
[  100.463190] [<800a6800>] vprintk_default+0x24/0x30
[  100.468072] [<80094ae0>] print_worker_info+0x148/0x174
[  100.473378] [<801ef308>] serial8250_console_putchar+0x0/0x44
[  100.479122] [<801ef300>] wait_for_xmitr+0xc4/0xcc
[  100.484014] [<87193d58>] ieee80211_ibss_leave+0xb90/0x1900 [mac80211]
[  100.490590] [<80081604>] warn_slowpath_common+0xa0/0xd0
[  100.495922] [<801a359c>] dump_stack+0x14/0x28
[  100.500350] [<80071a00>] show_stack+0x50/0x84
[  100.504784] [<80081604>] warn_slowpath_common+0xa0/0xd0
[  100.510106] [<87024c60>] ath9k_calculate_summary_state+0x250/0x60c [ath9k]
[  100.517105] [<800816b8>] warn_slowpath_null+0x18/0x24
[  100.522256] [<87024c60>] ath9k_calculate_summary_state+0x250/0x60c [ath9k]
[  100.529273] [<87025418>] ath9k_set_txpower+0x148/0x498 [ath9k]
[  100.535302] [<871d2c64>] cleanup_module+0xa74/0xd4c [mac80211]
[  100.541237] [<801ef308>] serial8250_console_putchar+0x0/0x44
[  100.547042] [<800a5d18>] wake_up_klogd+0x54/0x68
[  100.551730] [<800a6650>] vprintk_emit+0x404/0x43c
[  100.556623] [<871b9db8>] ieee80211_sta_rx_notify+0x258/0x32c [mac80211]
[  100.563475] [<871ba6a4>] ieee80211_sta_rx_queued_mgmt+0x63c/0x734 [mac80211]
[  100.570693] [<871aa49c>] ieee80211_tx_prepare_skb+0x210/0x230 [mac80211]
[  100.577609] [<800af5d4>] mod_timer+0x15c/0x190
[  100.582220] [<871ba8b8>] ieee80211_sta_work+0xfc/0xe1c [mac80211]
[  100.588539] [<871940b4>] ieee80211_ibss_leave+0xeec/0x1900 [mac80211]
[  100.595122] [<8009ec84>] dequeue_task_fair+0x44/0x130
[  100.600281] [<80092a34>] process_one_work+0x1f8/0x334
[  100.605454] [<80093830>] worker_thread+0x2b4/0x408
[  100.610317] [<8009357c>] worker_thread+0x0/0x408
[  100.615019] [<8009357c>] worker_thread+0x0/0x408
[  100.619705] [<80097b68>] kthread+0xdc/0xe8
[  100.623886] [<80097a8c>] kthread+0x0/0xe8
[  100.627961] [<80060878>] ret_from_kernel_thread+0x14/0x1c
[  100.633448]
[  100.634956] ---[ end trace aafbe57e9ae6862f ]---

Fixes: cfda2d8 ("ath9k: Fix beacon configuration for addition/removal of interfaces")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

mhaehnel pushed a commit to mhaehnel/linux that referenced this issue Sep 26, 2016

Sebastian Andrzej Siewior Thomas Gleixner
perf/x86/intel/bts: Make sure debug store is valid
Since commit 4d4c474 ("perf/x86/intel/bts: Fix BTS PMI detection")
my box goes boom on boot:

| .... node  #0, CPUs:      #1 #2 #3 #4 #5 #6 #7
| BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
| IP: [<ffffffff8100c463>] intel_bts_interrupt+0x43/0x130
| Call Trace:
|  <NMI> d [<ffffffff8100b341>] intel_pmu_handle_irq+0x51/0x4b0
|  [<ffffffff81004d47>] perf_event_nmi_handler+0x27/0x40

This happens because the code introduced in this commit dereferences the
debug store pointer unconditionally. The debug store is not guaranteed to
be available, so a NULL pointer check as on other places is required.

Fixes: 4d4c474 ("perf/x86/intel/bts: Fix BTS PMI detection")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: vince@deater.net
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/20160920131220.xg5pbdjtznszuyzb@breakpoint.cc
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
@derkostka

This comment has been minimized.

Show comment
Hide comment
@derkostka

derkostka Oct 10, 2016

Nice documentation. Thanks, especially the UHS-I patch seems to perform good.

By the way, the link to iozone is dead, but is is available here, also:

http://launchpadlibrarian.net/118371464/iozone3_397-2ubuntu1_armhf.deb

derkostka commented Oct 10, 2016

Nice documentation. Thanks, especially the UHS-I patch seems to perform good.

By the way, the link to iozone is dead, but is is available here, also:

http://launchpadlibrarian.net/118371464/iozone3_397-2ubuntu1_armhf.deb

@jobenvil

This comment has been minimized.

Show comment
Hide comment
@jobenvil

jobenvil Oct 10, 2016

@derkostka Much appreciated. iozone link was rectified. Thanks!

jobenvil commented Oct 10, 2016

@derkostka Much appreciated. iozone link was rectified. Thanks!

bkrepo pushed a commit to bkrepo/linux that referenced this issue Oct 28, 2016

kexec: fix double-free when failing to relocate the purgatory
commit 070c43e upstream.

If kexec_apply_relocations fails, kexec_load_purgatory frees pi->sechdrs
and pi->purgatory_buf.  This is redundant, because in case of error
kimage_file_prepare_segments calls kimage_file_post_load_cleanup, which
will also free those buffers.

This causes two warnings like the following, one for pi->sechdrs and the
other for pi->purgatory_buf:

  kexec-bzImage64: Loading purgatory failed
  ------------[ cut here ]------------
  WARNING: CPU: 1 PID: 2119 at mm/vmalloc.c:1490 __vunmap+0xc1/0xd0
  Trying to vfree() nonexistent vm area (ffffc90000e91000)
  Modules linked in:
  CPU: 1 PID: 2119 Comm: kexec Not tainted 4.8.0-rc3+ #5
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
    dump_stack+0x4d/0x65
    __warn+0xcb/0xf0
    warn_slowpath_fmt+0x4f/0x60
    ? find_vmap_area+0x19/0x70
    ? kimage_file_post_load_cleanup+0x47/0xb0
    __vunmap+0xc1/0xd0
    vfree+0x2e/0x70
    kimage_file_post_load_cleanup+0x5e/0xb0
    SyS_kexec_file_load+0x448/0x680
    ? putname+0x54/0x60
    ? do_sys_open+0x190/0x1f0
    entry_SYSCALL_64_fastpath+0x13/0x8f
  ---[ end trace 158bb74f5950ca2b ]---

Fix by setting pi->sechdrs an pi->purgatory_buf to NULL, since vfree
won't try to free a NULL pointer.

Link: http://lkml.kernel.org/r/1472083546-23683-1-git-send-email-bauerman@linux.vnet.ibm.com
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bkrepo pushed a commit to bkrepo/linux that referenced this issue Oct 28, 2016

reiserfs: Unlock superblock before calling reiserfs_quota_on_mount()
commit 420902c upstream.

If we hold the superblock lock while calling reiserfs_quota_on_mount(), we can
deadlock our own worker - mount blocks kworker/3:2, sleeps forever more.

crash> ps|grep UN
    715      2   3  ffff880220734d30  UN   0.0       0      0  [kworker/3:2]
   9369   9341   2  ffff88021ffb7560  UN   1.3  493404 123184  Xorg
   9665   9664   3  ffff880225b92ab0  UN   0.0   47368    812  udisks-daemon
  10635  10403   3  ffff880222f22c70  UN   0.0   14904    936  mount
crash> bt ffff880220734d30
PID: 715    TASK: ffff880220734d30  CPU: 3   COMMAND: "kworker/3:2"
 #0 [ffff8802244c3c20] schedule at ffffffff8144584b
 #1 [ffff8802244c3cc8] __rt_mutex_slowlock at ffffffff814472b3
 #2 [ffff8802244c3d28] rt_mutex_slowlock at ffffffff814473f5
 #3 [ffff8802244c3dc8] reiserfs_write_lock at ffffffffa05f28fd [reiserfs]
 #4 [ffff8802244c3de8] flush_async_commits at ffffffffa05ec91d [reiserfs]
 #5 [ffff8802244c3e08] process_one_work at ffffffff81073726
 #6 [ffff8802244c3e68] worker_thread at ffffffff81073eba
 #7 [ffff8802244c3ec8] kthread at ffffffff810782e0
 #8 [ffff8802244c3f48] kernel_thread_helper at ffffffff81450064
crash> rd ffff8802244c3cc8 10
ffff8802244c3cc8:  ffffffff814472b3 ffff880222f23250   .rD.....P2."....
ffff8802244c3cd8:  0000000000000000 0000000000000286   ................
ffff8802244c3ce8:  ffff8802244c3d30 ffff880220734d80   0=L$.....Ms ....
ffff8802244c3cf8:  ffff880222e8f628 0000000000000000   (.."............
ffff8802244c3d08:  0000000000000000 0000000000000002   ................
crash> struct rt_mutex ffff880222e8f628
struct rt_mutex {
  wait_lock = {
    raw_lock = {
      slock = 65537
    }
  },
  wait_list = {
    node_list = {
      next = 0xffff8802244c3d48,
      prev = 0xffff8802244c3d48
    }
  },
  owner = 0xffff880222f22c71,
  save_state = 0
}
crash> bt 0xffff880222f22c70
PID: 10635  TASK: ffff880222f22c70  CPU: 3   COMMAND: "mount"
 #0 [ffff8802216a9868] schedule at ffffffff8144584b
 #1 [ffff8802216a9910] schedule_timeout at ffffffff81446865
 #2 [ffff8802216a99a0] wait_for_common at ffffffff81445f74
 #3 [ffff8802216a9a30] flush_work at ffffffff810712d3
 #4 [ffff8802216a9ab0] schedule_on_each_cpu at ffffffff81074463
 #5 [ffff8802216a9ae0] invalidate_bdev at ffffffff81178aba
 #6 [ffff8802216a9af0] vfs_load_quota_inode at ffffffff811a3632
 #7 [ffff8802216a9b50] dquot_quota_on_mount at ffffffff811a375c
 #8 [ffff8802216a9b80] finish_unfinished at ffffffffa05dd8b0 [reiserfs]
 #9 [ffff8802216a9cc0] reiserfs_fill_super at ffffffffa05de825 [reiserfs]
    RIP: 00007f7b9303997a  RSP: 00007ffff443c7a8  RFLAGS: 00010202
    RAX: 00000000000000a5  RBX: ffffffff8144ef12  RCX: 00007f7b932e9ee0
    RDX: 00007f7b93d9a400  RSI: 00007f7b93d9a3e0  RDI: 00007f7b93d9a3c0
    RBP: 00007f7b93d9a2c0   R8: 00007f7b93d9a550   R9: 0000000000000001
    R10: ffffffffc0ed040e  R11: 0000000000000202  R12: 000000000000040e
    R13: 0000000000000000  R14: 00000000c0ed040e  R15: 00007ffff443ca20
    ORIG_RAX: 00000000000000a5  CS: 0033  SS: 002b

Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Acked-by: Mike Galbraith <mgalbraith@suse.de>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tobetter pushed a commit that referenced this issue Oct 29, 2017

scsi: zfcp: fix erp_action use-before-initialize in REC action trace
v4.10 commit 6f2ce1c ("scsi: zfcp: fix rport unblock race with LUN
recovery") extended accessing parent pointer fields of struct
zfcp_erp_action for tracing.  If an erp_action has never been enqueued
before, these parent pointer fields are uninitialized and NULL. Examples
are zfcp objects freshly added to the parent object's children list,
before enqueueing their first recovery subsequently. In
zfcp_erp_try_rport_unblock(), we iterate such list. Accessing erp_action
fields can cause a NULL pointer dereference.  Since the kernel can read
from lowcore on s390, it does not immediately cause a kernel page
fault. Instead it can cause hangs on trying to acquire the wrong
erp_action->adapter->dbf->rec_lock in zfcp_dbf_rec_action_lvl()
                      ^bogus^
while holding already other locks with IRQs disabled.

Real life example from attaching lots of LUNs in parallel on many CPUs:

crash> bt 17723
PID: 17723  TASK: ...               CPU: 25  COMMAND: "zfcperp0.0.1800"
 LOWCORE INFO:
  -psw      : 0x0404300180000000 0x000000000038e424
  -function : _raw_spin_lock_wait_flags at 38e424
...
 #0 [fdde8fc90] zfcp_dbf_rec_action_lvl at 3e0004e9862 [zfcp]
 #1 [fdde8fce8] zfcp_erp_try_rport_unblock at 3e0004dfddc [zfcp]
 #2 [fdde8fd38] zfcp_erp_strategy at 3e0004e0234 [zfcp]
 #3 [fdde8fda8] zfcp_erp_thread at 3e0004e0a12 [zfcp]
 #4 [fdde8fe60] kthread at 173550
 #5 [fdde8feb8] kernel_thread_starter at 10add2

zfcp_adapter
 zfcp_port
  zfcp_unit <address>, 0x404040d600000000
  scsi_device NULL, returning early!
zfcp_scsi_dev.status = 0x40000000
0x40000000 ZFCP_STATUS_COMMON_RUNNING

crash> zfcp_unit <address>
struct zfcp_unit {
  erp_action = {
    adapter = 0x0,
    port = 0x0,
    unit = 0x0,
  },
}

zfcp_erp_action is always fully embedded into its container object. Such
container object is never moved in its object tree (only add or delete).
Hence, erp_action parent pointers can never change.

To fix the issue, initialize the erp_action parent pointers before
adding the erp_action container to any list and thus before it becomes
accessible from outside of its initializing function.

In order to also close the time window between zfcp_erp_setup_act()
memsetting the entire erp_action to zero and setting the parent pointers
again, drop the memset and instead explicitly initialize individually
all erp_action fields except for parent pointers. To be extra careful
not to introduce any other unintended side effect, even keep zeroing the
erp_action fields for list and timer. Also double-check with
WARN_ON_ONCE that erp_action parent pointers never change, so we get to
know when we would deviate from previous behavior.

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: 6f2ce1c ("scsi: zfcp: fix rport unblock race with LUN recovery")
Cc: <stable@vger.kernel.org> #2.6.32+
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

tobetter pushed a commit that referenced this issue Oct 29, 2017

perf buildid-list: Fix crash when processing PERF_RECORD_NAMESPACE
Thomas reported that 'perf buildid-list' gets a SEGFAULT due to NULL
pointer deref when he ran it on a data with namespace events.  It was
because the buildid_id__mark_dso_hit_ops lacks the namespace event
handler and perf_too__fill_default() didn't set it.

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000000000 in ?? ()
  Missing separate debuginfos, use: dnf debuginfo-install audit-libs-2.7.7-1.fc25.s390x bzip2-libs-1.0.6-21.fc25.s390x elfutils-libelf-0.169-1.fc25.s390x
  +elfutils-libs-0.169-1.fc25.s390x libcap-ng-0.7.8-1.fc25.s390x numactl-libs-2.0.11-2.ibm.fc25.s390x openssl-libs-1.1.0e-1.1.ibm.fc25.s390x perl-libs-5.24.1-386.fc25.s390x
  +python-libs-2.7.13-2.fc25.s390x slang-2.3.0-7.fc25.s390x xz-libs-5.2.3-2.fc25.s390x zlib-1.2.8-10.fc25.s390x
  (gdb) where
  #0  0x0000000000000000 in ?? ()
  #1  0x00000000010fad6a in machines__deliver_event (machines=<optimized out>, machines@entry=0x2c6fd18,
      evlist=<optimized out>, event=event@entry=0x3fffdf00470, sample=0x3ffffffe880, sample@entry=0x3ffffffe888,
      tool=tool@entry=0x1312968 <build_id.mark_dso_hit_ops>, file_offset=1136) at util/session.c:1287
  #2  0x00000000010fbf4e in perf_session__deliver_event (file_offset=1136, tool=0x1312968 <build_id.mark_dso_hit_ops>,
      sample=0x3ffffffe888, event=0x3fffdf00470, session=0x2c6fc30) at util/session.c:1340
  #3  perf_session__process_event (session=0x2c6fc30, session@entry=0x0, event=event@entry=0x3fffdf00470,
      file_offset=file_offset@entry=1136) at util/session.c:1522
  #4  0x00000000010fddde in __perf_session__process_events (file_size=11880, data_size=<optimized out>,
      data_offset=<optimized out>, session=0x0) at util/session.c:1899
  #5  perf_session__process_events (session=0x0, session@entry=0x2c6fc30) at util/session.c:1953
  #6  0x000000000103b2ac in perf_session__list_build_ids (with_hits=<optimized out>, force=<optimized out>)
      at builtin-buildid-list.c:83
  #7  cmd_buildid_list (argc=<optimized out>, argv=<optimized out>) at builtin-buildid-list.c:115
  #8  0x00000000010a026c in run_builtin (p=0x1311f78 <commands+24>, argc=argc@entry=2, argv=argv@entry=0x3fffffff3c0)
      at perf.c:296
  #9  0x000000000102bc00 in handle_internal_command (argv=<optimized out>, argc=2) at perf.c:348
  #10 run_argv (argcp=<synthetic pointer>, argv=<synthetic pointer>) at perf.c:392
  #11 main (argc=<optimized out>, argv=0x3fffffff3c0) at perf.c:536
  (gdb)

Fix it by adding a stub event handler for namespace event.

Committer testing:

Further clarifying, plain using 'perf buildid-list' will not end up in a
SEGFAULT when processing a perf.data file with namespace info:

  # perf record -a --namespaces sleep 1
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 2.024 MB perf.data (1058 samples) ]
  # perf buildid-list | wc -l
  38
  # perf buildid-list | head -5
  e2a171c7b905826fc8494f0711ba76ab6abbd604 /lib/modules/4.14.0-rc3+/build/vmlinux
  874840a02d8f8a31cedd605d0b8653145472ced3 /lib/modules/4.14.0-rc3+/kernel/arch/x86/kvm/kvm-intel.ko
  ea7223776730cd8a22f320040aae4d54312984bc /lib/modules/4.14.0-rc3+/kernel/drivers/gpu/drm/i915/i915.ko
  5961535e6732a8edb7f22b3f148bb2fa2e0be4b9 /lib/modules/4.14.0-rc3+/kernel/drivers/gpu/drm/drm.ko
  f045f54aa78cf1931cc893f78b6cbc52c72a8cb1 /usr/lib64/libc-2.25.so
  #

It is only when one asks for checking what of those entries actually had
samples, i.e. when we use either -H or --with-hits, that we will process
all the PERF_RECORD_ events, and since tools/perf/builtin-buildid-list.c
neither explicitely set a perf_tool.namespaces() callback nor the
default stub was set that we end up, when processing a
PERF_RECORD_NAMESPACE record, causing a SEGFAULT:

  # perf buildid-list -H
  Segmentation fault (core dumped)
  ^C
  #

Reported-and-Tested-by: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Fixes: f3b3614 ("perf tools: Add PERF_RECORD_NAMESPACES to include namespaces related info")
Link: http://lkml.kernel.org/r/20171017132900.11043-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

tobetter pushed a commit that referenced this issue Jan 4, 2018

tipc: fix tipc_mon_delete() oops in tipc_enable_bearer() error path
Calling tipc_mon_delete() before the monitor has been created will oops.
This can happen in tipc_enable_bearer() error path if tipc_disc_create()
fails.

[   48.589074] BUG: unable to handle kernel paging request at 0000000000001008
[   48.590266] IP: tipc_mon_delete+0xea/0x270 [tipc]
[   48.591223] PGD 1e60c5067 P4D 1e60c5067 PUD 1eb0cf067 PMD 0
[   48.592230] Oops: 0000 [#1] SMP KASAN
[   48.595610] CPU: 5 PID: 1199 Comm: tipc Tainted: G    B            4.15.0-rc4-pc64-dirty #5
[   48.597176] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
[   48.598489] RIP: 0010:tipc_mon_delete+0xea/0x270 [tipc]
[   48.599347] RSP: 0018:ffff8801d827f668 EFLAGS: 00010282
[   48.600705] RAX: ffff8801ee813f00 RBX: 0000000000000204 RCX: 0000000000000000
[   48.602183] RDX: 1ffffffff1de6a75 RSI: 0000000000000297 RDI: 0000000000000297
[   48.604373] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff1dd1533
[   48.605607] R10: ffffffff8eafbb05 R11: fffffbfff1dd1534 R12: 0000000000000050
[   48.607082] R13: dead000000000200 R14: ffffffff8e73f310 R15: 0000000000001020
[   48.608228] FS:  00007fc686484800(0000) GS:ffff8801f5540000(0000) knlGS:0000000000000000
[   48.610189] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   48.611459] CR2: 0000000000001008 CR3: 00000001dda70002 CR4: 00000000003606e0
[   48.612759] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   48.613831] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   48.615038] Call Trace:
[   48.615635]  tipc_enable_bearer+0x415/0x5e0 [tipc]
[   48.620623]  tipc_nl_bearer_enable+0x1ab/0x200 [tipc]
[   48.625118]  genl_family_rcv_msg+0x36b/0x570
[   48.631233]  genl_rcv_msg+0x5a/0xa0
[   48.631867]  netlink_rcv_skb+0x1cc/0x220
[   48.636373]  genl_rcv+0x24/0x40
[   48.637306]  netlink_unicast+0x29c/0x350
[   48.639664]  netlink_sendmsg+0x439/0x590
[   48.642014]  SYSC_sendto+0x199/0x250
[   48.649912]  do_syscall_64+0xfd/0x2c0
[   48.650651]  entry_SYSCALL64_slow_path+0x25/0x25
[   48.651843] RIP: 0033:0x7fc6859848e3
[   48.652539] RSP: 002b:00007ffd25dff938 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[   48.654003] RAX: ffffffffffffffda RBX: 00007ffd25dff990 RCX: 00007fc6859848e3
[   48.655303] RDX: 0000000000000054 RSI: 00007ffd25dff990 RDI: 0000000000000003
[   48.656512] RBP: 00007ffd25dff980 R08: 00007fc685c35fc0 R09: 000000000000000c
[   48.657697] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000d13010
[   48.658840] R13: 00007ffd25e009c0 R14: 0000000000000000 R15: 0000000000000000
[   48.662972] RIP: tipc_mon_delete+0xea/0x270 [tipc] RSP: ffff8801d827f668
[   48.664073] CR2: 0000000000001008
[   48.664576] ---[ end trace e811818d54d5ce88 ]---

Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tommi Rantala <tommi.t.rantala@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tobetter pushed a commit that referenced this issue Mar 4, 2018

scsi: zfcp: fix erp_action use-before-initialize in REC action trace
commit ab31fd0 upstream.

v4.10 commit 6f2ce1c ("scsi: zfcp: fix rport unblock race with LUN
recovery") extended accessing parent pointer fields of struct
zfcp_erp_action for tracing.  If an erp_action has never been enqueued
before, these parent pointer fields are uninitialized and NULL. Examples
are zfcp objects freshly added to the parent object's children list,
before enqueueing their first recovery subsequently. In
zfcp_erp_try_rport_unblock(), we iterate such list. Accessing erp_action
fields can cause a NULL pointer dereference.  Since the kernel can read
from lowcore on s390, it does not immediately cause a kernel page
fault. Instead it can cause hangs on trying to acquire the wrong
erp_action->adapter->dbf->rec_lock in zfcp_dbf_rec_action_lvl()
                      ^bogus^
while holding already other locks with IRQs disabled.

Real life example from attaching lots of LUNs in parallel on many CPUs:

crash> bt 17723
PID: 17723  TASK: ...               CPU: 25  COMMAND: "zfcperp0.0.1800"
 LOWCORE INFO:
  -psw      : 0x0404300180000000 0x000000000038e424
  -function : _raw_spin_lock_wait_flags at 38e424
...
 #0 [fdde8fc90] zfcp_dbf_rec_action_lvl at 3e0004e9862 [zfcp]
 #1 [fdde8fce8] zfcp_erp_try_rport_unblock at 3e0004dfddc [zfcp]
 #2 [fdde8fd38] zfcp_erp_strategy at 3e0004e0234 [zfcp]
 #3 [fdde8fda8] zfcp_erp_thread at 3e0004e0a12 [zfcp]
 #4 [fdde8fe60] kthread at 173550
 #5 [fdde8feb8] kernel_thread_starter at 10add2

zfcp_adapter
 zfcp_port
  zfcp_unit <address>, 0x404040d600000000
  scsi_device NULL, returning early!
zfcp_scsi_dev.status = 0x40000000
0x40000000 ZFCP_STATUS_COMMON_RUNNING

crash> zfcp_unit <address>
struct zfcp_unit {
  erp_action = {
    adapter = 0x0,
    port = 0x0,
    unit = 0x0,
  },
}

zfcp_erp_action is always fully embedded into its container object. Such
container object is never moved in its object tree (only add or delete).
Hence, erp_action parent pointers can never change.

To fix the issue, initialize the erp_action parent pointers before
adding the erp_action container to any list and thus before it becomes
accessible from outside of its initializing function.

In order to also close the time window between zfcp_erp_setup_act()
memsetting the entire erp_action to zero and setting the parent pointers
again, drop the memset and instead explicitly initialize individually
all erp_action fields except for parent pointers. To be extra careful
not to introduce any other unintended side effect, even keep zeroing the
erp_action fields for list and timer. Also double-check with
WARN_ON_ONCE that erp_action parent pointers never change, so we get to
know when we would deviate from previous behavior.

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: 6f2ce1c ("scsi: zfcp: fix rport unblock race with LUN recovery")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

tobetter pushed a commit that referenced this issue Mar 12, 2018

perf record: Fix crash in pipe mode
Currently we can crash perf record when running in pipe mode, like:

  $ perf record ls | perf report
  # To display the perf.data header info, please use --header/--header-only options.
  #
  perf: Segmentation fault
  Error:
  The - file has no samples!

The callstack of the crash is:

    0x0000000000515242 in perf_event__synthesize_event_update_name
  3513            ev = event_update_event__new(len + 1, PERF_EVENT_UPDATE__NAME, evsel->id[0]);
  (gdb) bt
  #0  0x0000000000515242 in perf_event__synthesize_event_update_name
  #1  0x00000000005158a4 in perf_event__synthesize_extra_attr
  #2  0x0000000000443347 in record__synthesize
  #3  0x00000000004438e3 in __cmd_record
  #4  0x000000000044514e in cmd_record
  #5  0x00000000004cbc95 in run_builtin
  #6  0x00000000004cbf02 in handle_internal_command
  #7  0x00000000004cc054 in run_argv
  #8  0x00000000004cc422 in main

The reason of the crash is that the evsel does not have ids array
allocated and the pipe's synthesize code tries to access it.

We don't force evsel ids allocation when we have single event, because
it's not needed. However we need it when we are in pipe mode even for
single event as a key for evsel update event.

Fixing this by forcing evsel ids allocation event for single event, when
we are in pipe mode.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20180302161354.30192-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

tobetter pushed a commit that referenced this issue Apr 25, 2018

scsi: libiscsi: Allow sd_shutdown on bad transport
[ Upstream commit d754941 ]

If, for any reason, userland shuts down iscsi transport interfaces
before proper logouts - like when logging in to LUNs manually, without
logging out on server shutdown, or when automated scripts can't
umount/logout from logged LUNs - kernel will hang forever on its
sd_sync_cache() logic, after issuing the SYNCHRONIZE_CACHE cmd to all
still existent paths.

PID: 1 TASK: ffff8801a69b8000 CPU: 1 COMMAND: "systemd-shutdow"
 #0 [ffff8801a69c3a30] __schedule at ffffffff8183e9ee
 #1 [ffff8801a69c3a80] schedule at ffffffff8183f0d5
 #2 [ffff8801a69c3a98] schedule_timeout at ffffffff81842199
 #3 [ffff8801a69c3b40] io_schedule_timeout at ffffffff8183e604
 #4 [ffff8801a69c3b70] wait_for_completion_io_timeout at ffffffff8183fc6c
 #5 [ffff8801a69c3bd0] blk_execute_rq at ffffffff813cfe10
 #6 [ffff8801a69c3c88] scsi_execute at ffffffff815c3fc7
 #7 [ffff8801a69c3cc8] scsi_execute_req_flags at ffffffff815c60fe
 #8 [ffff8801a69c3d30] sd_sync_cache at ffffffff815d37d7
 #9 [ffff8801a69c3da8] sd_shutdown at ffffffff815d3c3c

This happens because iscsi_eh_cmd_timed_out(), the transport layer
timeout helper, would tell the queue timeout function (scsi_times_out)
to reset the request timer over and over, until the session state is
back to logged in state. Unfortunately, during server shutdown, this
might never happen again.

Other option would be "not to handle" the issue in the transport
layer. That would trigger the error handler logic, which would also need
the session state to be logged in again.

Best option, for such case, is to tell upper layers that the command was
handled during the transport layer error handler helper, marking it as
DID_NO_CONNECT, which will allow completion and inform about the
problem.

After the session was marked as ISCSI_STATE_FAILED, due to the first
timeout during the server shutdown phase, all subsequent cmds will fail
to be queued, allowing upper logic to fail faster.

Signed-off-by: Rafael David Tinoco <rafael.tinoco@canonical.com>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tobetter pushed a commit that referenced this issue May 2, 2018

RDS: IB: Fix null pointer issue
[ Upstream commit 2c0aa08 ]

Scenario:
1. Port down and do fail over
2. Ap do rds_bind syscall

PID: 47039  TASK: ffff89887e2fe640  CPU: 47  COMMAND: "kworker/u:6"
 #0 [ffff898e35f159f0] machine_kexec at ffffffff8103abf9
 #1 [ffff898e35f15a60] crash_kexec at ffffffff810b96e3
 #2 [ffff898e35f15b30] oops_end at ffffffff8150f518
 #3 [ffff898e35f15b60] no_context at ffffffff8104854c
 #4 [ffff898e35f15ba0] __bad_area_nosemaphore at ffffffff81048675
 #5 [ffff898e35f15bf0] bad_area_nosemaphore at ffffffff810487d3
 #6 [ffff898e35f15c00] do_page_fault at ffffffff815120b8
 #7 [ffff898e35f15d10] page_fault at ffffffff8150ea95
    [exception RIP: unknown or invalid address]
    RIP: 0000000000000000  RSP: ffff898e35f15dc8  RFLAGS: 00010282
    RAX: 00000000fffffffe  RBX: ffff889b77f6fc00  RCX:ffffffff81c99d88
    RDX: 0000000000000000  RSI: ffff896019ee08e8  RDI:ffff889b77f6fc00
    RBP: ffff898e35f15df0   R8: ffff896019ee08c8  R9:0000000000000000
    R10: 0000000000000400  R11: 0000000000000000  R12:ffff896019ee08c0
    R13: ffff889b77f6fe68  R14: ffffffff81c99d80  R15: ffffffffa022a1e0
    ORIG_RAX: ffffffffffffffff  CS: 0010 SS: 0018
 #8 [ffff898e35f15dc8] cma_ndev_work_handler at ffffffffa022a228 [rdma_cm]
 #9 [ffff898e35f15df8] process_one_work at ffffffff8108a7c6
 #10 [ffff898e35f15e58] worker_thread at ffffffff8108bda0
 #11 [ffff898e35f15ee8] kthread at ffffffff81090fe6

PID: 45659  TASK: ffff880d313d2500  CPU: 31  COMMAND: "oracle_45659_ap"
 #0 [ffff881024ccfc98] __schedule at ffffffff8150bac4
 #1 [ffff881024ccfd40] schedule at ffffffff8150c2cf
 #2 [ffff881024ccfd50] __mutex_lock_slowpath at ffffffff8150cee7
 #3 [ffff881024ccfdc0] mutex_lock at ffffffff8150cdeb
 #4 [ffff881024ccfde0] rdma_destroy_id at ffffffffa022a027 [rdma_cm]
 #5 [ffff881024ccfe10] rds_ib_laddr_check at ffffffffa0357857 [rds_rdma]
 #6 [ffff881024ccfe50] rds_trans_get_preferred at ffffffffa0324c2a [rds]
 #7 [ffff881024ccfe80] rds_bind at ffffffffa031d690 [rds]
 #8 [ffff881024ccfeb0] sys_bind at ffffffff8142a670

PID: 45659                          PID: 47039
rds_ib_laddr_check
  /* create id_priv with a null event_handler */
  rdma_create_id
  rdma_bind_addr
    cma_acquire_dev
      /* add id_priv to cma_dev->id_list */
      cma_attach_to_dev
                                    cma_ndev_work_handler
                                      /* event_hanlder is null */
                                      id_priv->id.event_handler

Signed-off-by: Guanglei Li <guanglei.li@oracle.com>
Signed-off-by: Honglei Wang <honglei.wang@oracle.com>
Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Yanjun Zhu <yanjun.zhu@oracle.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Acked-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tobetter pushed a commit that referenced this issue May 15, 2018

nsh: fix infinite loop
syzbot caught an infinite recursion in nsh_gso_segment().

Problem here is that we need to make sure the NSH header is of
reasonable length.

BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
depth: 48  max: 48!
48 locks held by syz-executor0/10189:
 #0:         (ptrval) (rcu_read_lock_bh){....}, at: __dev_queue_xmit+0x30f/0x34c0 net/core/dev.c:3517
 #1:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #1:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #2:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #2:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #3:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #3:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #4:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #4:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #5:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #5:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #6:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #6:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #7:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #7:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #8:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #8:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #9:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #9:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #10:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #10:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #11:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #11:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #12:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #12:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #13:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #13:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #14:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #14:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #15:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #15:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #16:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #16:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #17:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #17:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #18:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #18:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #19:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #19:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #20:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #20:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #21:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #21:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #22:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #22:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #23:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #23:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #24:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #24:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #25:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #25:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #26:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #26:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #27:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #27:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #28:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #28:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #29:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #29:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #30:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #30:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #31:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #31:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
dccp_close: ABORT with 65423 bytes unread
 #32:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #32:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #33:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #33:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #34:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #34:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #35:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #35:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #36:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #36:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #37:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #37:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #38:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #38:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #39:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #39:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #40:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #40:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #41:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #41:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #42:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #42:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #43:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #43:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #44:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #44:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #45:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #45:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #46:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #46:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
 #47:         (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
 #47:         (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
INFO: lockdep is turned off.
CPU: 1 PID: 10189 Comm: syz-executor0 Not tainted 4.17.0-rc2+ #26
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 __lock_acquire+0x1788/0x5140 kernel/locking/lockdep.c:3449
 lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3920
 rcu_lock_acquire include/linux/rcupdate.h:246 [inline]
 rcu_read_lock include/linux/rcupdate.h:632 [inline]
 skb_mac_gso_segment+0x25b/0x720 net/core/dev.c:2789
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
 skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
 __skb_gso_segment+0x3bb/0x870 net/core/dev.c:2865
 skb_gso_segment include/linux/netdevice.h:4025 [inline]
 validate_xmit_skb+0x54d/0xd90 net/core/dev.c:3118
 validate_xmit_skb_list+0xbf/0x120 net/core/dev.c:3168
 sch_direct_xmit+0x354/0x11e0 net/sched/sch_generic.c:312
 qdisc_restart net/sched/sch_generic.c:399 [inline]
 __qdisc_run+0x741/0x1af0 net/sched/sch_generic.c:410
 __dev_xmit_skb net/core/dev.c:3243 [inline]
 __dev_queue_xmit+0x28ea/0x34c0 net/core/dev.c:3551
 dev_queue_xmit+0x17/0x20 net/core/dev.c:3616
 packet_snd net/packet/af_packet.c:2951 [inline]
 packet_sendmsg+0x40f8/0x6070 net/packet/af_packet.c:2976
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg+0xd5/0x120 net/socket.c:639
 __sys_sendto+0x3d7/0x670 net/socket.c:1789
 __do_sys_sendto net/socket.c:1801 [inline]
 __se_sys_sendto net/socket.c:1797 [inline]
 __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1797
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fixes: c411ed8 ("nsh: add GSO support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jiri Benc <jbenc@redhat.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Acked-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tobetter pushed a commit that referenced this issue May 22, 2018

usbip: usbip_host: fix bad unlock balance during stub_probe()
stub_probe() calls put_busid_priv() in an error path when device isn't
found in the busid_table. Fix it by making put_busid_priv() safe to be
called with null struct bus_id_priv pointer.

This problem happens when "usbip bind" is run without loading usbip_host
driver and then running modprobe. The first failed bind attempt unbinds
the device from the original driver and when usbip_host is modprobed,
stub_probe() runs and doesn't find the device in its busid table and calls
put_busid_priv(0 with null bus_id_priv pointer.

usbip-host 3-10.2: 3-10.2 is not in match_busid table...  skip!

[  367.359679] =====================================
[  367.359681] WARNING: bad unlock balance detected!
[  367.359683] 4.17.0-rc4+ #5 Not tainted
[  367.359685] -------------------------------------
[  367.359688] modprobe/2768 is trying to release lock (
[  367.359689]
==================================================================
[  367.359696] BUG: KASAN: null-ptr-deref in print_unlock_imbalance_bug+0x99/0x110
[  367.359699] Read of size 8 at addr 0000000000000058 by task modprobe/2768

[  367.359705] CPU: 4 PID: 2768 Comm: modprobe Not tainted 4.17.0-rc4+ #5

Fixes: 2207655 ("usbip: usbip_host: fix NULL-ptr deref and use-after-free errors") in usb-linus
Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment