Hi Martin,
Thanks for the bug report. Yes, I would like full dmesg from your
system, including the oops if you have it.
Can you reproduce this bug on an updated 3.4.24 kernel? It sounds like
a difficult bug to trigger, but the oops wasn't helpful enough for me to
pinpoint the problem.
If you can trigger the bug on the 3.4.24 kernel, please recompile with
CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and send me dmesg showing the
oops. You may have to capture dmesg via netconsole to a separate box in
order to capture the oops.
Sarah Sharp
On Wed, Dec 19, 2012 at 03:34:46PM +0100, Martin Mokrejs wrote:
> Hi (resend with smaller image attached to pass mailing list filters),
> I had a Prolific-based USB3.0-to-2xSATA dongle connected to my
> Dell Vostro 3550 laptop via its Texas Instruments-based USB3.0
> chip connector. The dongle apparently made the disks sleep and once I
> wanted to access the data I got:
>
> Dec 18 19:23:05 vostro kernel: [87422.577634] EXT4-fs error (device sdc1):
> __ext4_get_inode_loc:3564: inode #2: block 1057: comm ls: unable to read
> itable block
> Dec 18 19:23:05 vostro kernel: [87422.577637] EXT4-fs error (device sdc1) in
> ext4_reserve_inode_write:4382: IO failure
> Dec 18 19:23:10 vostro kernel: [87427.816708] Buffer I/O error on device
> sdc1, logical block 365985792
> Dec 18 19:23:10 vostro kernel: [87427.816711] lost page write due to I/O
> error on sdc1
> Dec 18 19:23:10 vostro kernel: [87427.816714] JBD2: Error -5 detected when
> updating journal superblock for sdc1-8.
> Dec 18 19:23:10 vostro kernel: [87427.816732] Aborting journal on device
> sdc1-8.
> Dec 18 19:23:10 vostro kernel: [87427.816734] Buffer I/O error on device
> sdc1, logical block 365985792
> Dec 18 19:23:10 vostro kernel: [87427.816736] lost page write due to I/O
> error on sdc1
> Dec 18 19:23:10 vostro kernel: [87427.816738] JBD2: Error -5 detected when
> updating journal superblock for sdc1-8.
> Dec 18 19:23:35 vostro kernel: [87452.589793] EXT3-fs error (device sdd1):
> ext3_get_inode_loc: unable to read inode block - inode=2, block=1027
> Dec 18 19:23:35 vostro kernel: [87452.589950] Buffer I/O error on device
> sdd1, logical block 0
> Dec 18 19:23:35 vostro kernel: [87452.589952] lost page write due to I/O
> error on sdd1
> Dec 18 19:23:35 vostro kernel: [87452.589954] EXT3-fs (sdd1): I/O error while
> writing superblock
> Dec 18 19:23:35 vostro kernel: [87452.589956] EXT3-fs (sdd1): error in
> ext3_reserve_inode_write: IO failure
> Dec 18 19:23:35 vostro kernel: [87452.590098] Buffer I/O error on device
> sdd1, logical block 0
> Dec 18 19:23:35 vostro kernel: [87452.590100] lost page write due to I/O
> error on sdd1
> Dec 18 19:23:35 vostro kernel: [87452.590101] EXT3-fs (sdd1): I/O error while
> writing superblock
> Dec 18 19:23:40 vostro kernel: [87457.731802] Buffer I/O error on device
> sdd1, logical block 122061318
> Dec 18 19:23:40 vostro kernel: [87457.731804] lost page write due to I/O
> error on sdd1
> Dec 18 19:23:40 vostro kernel: [87457.731807] Aborting journal on device sdd1.
> Dec 18 19:23:40 vostro kernel: [87457.731810] Buffer I/O error on device
> sdd1, logical block 122061314
> Dec 18 19:23:40 vostro kernel: [87457.731811] lost page write due to I/O
> error on sdd1
> Dec 18 19:23:40 vostro kernel: [87457.731813] JBD: I/O error detected when
> updating journal superblock for sdd1.
>
>
> I think it was said on this list few times already that this is a Prolific
> chip problem ignoring the host and powering off the disks. Actually, I am not
> sure
> they were really spun off but that is not the issue I am to report here.
> However,
> I decided to turn off the power from the dongle powering the disks and unplug
> the
> USB cable. I think the computer survived that but after powered back up the
> dongle
> with drives and re-plugged in the USB cable I got a kernel OOPs. My apologies
> that I am not certain when it crashed exactly, took me a while to fight
> through
> some other obstackles and somehow forgot the details meanwhile. :(
> The crash was with 3.4.17 kernel. I retyped the stacktrace from a camera
> picture (attached), sadly, it did NOT fit onto the screen so it's NOT
> complete.
> Anyway, here it goes:
>
> resched_task
> check_preempt_curr
> xhci_irq
> ttwu_do_activate.constprop
> try_to_wake_up
> flat_send_IPI_mask
> trigger_load_balance
> init_timer_deferrable_key
> wake_up_process
> _raw_spin_lock_irq
> xhci_msi_irq
> handle_irq_event_percpu
> handle_irq_event
> ack_apic_edge
> handle_edge_irq
> handle_irq
> do_IRQ
> common_interrupt
> <EOI>
> ? put_page_testzero
> release_pages
> free_pages_and_swap_cache
> tlb_flush_mmu
> tlb_finish_mmu
> exit_mmap
> mmput
> flush_old_exec
> load_elf_binary
> ? _raw_read_lock
> ? load_misc_binary
> ? get_user_pages
> ? get_arg_page
> ? put_page
> search_binary_handler
> ? elf_core_dump
> do_execve_common.isra
> do_execve
> sys_execve
> stub_execve
>
> RIP ring_doorbell_for_active_rings
>
>
> Please let me know if you need more info (dmesg?). I expect that this won't be
> helpful immediately and now that there now is even 3.4.24 kernel ... but
> maybe
> it will help once somebody else hitting similar OOPS stacktrace. Please Cc: me
> in replies.
> Martin
>
>
> Bus 004 Device 006: ID 067b:2773 Prolific Technology, Inc.
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 3.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 9
> idVendor 0x067b Prolific Technology, Inc.
> idProduct 0x2773
> bcdDevice 1.00
> iManufacturer 1 Prolific Technology Inc.
> iProduct 2 USB-SATA Bridge
> iSerial 3 PROLIFICMP000000007
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 44
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xc0
> Self Powered
> MaxPower 24mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 8 Mass Storage
> bInterfaceSubClass 6 SCSI
> bInterfaceProtocol 80 Bulk-Only
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 1024 bytes
> bInterval 0
> bMaxBurst 15
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x01 EP 1 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 1024 bytes
> bInterval 0
> bMaxBurst 15
> Binary Object Store Descriptor:
> bLength 5
> bDescriptorType 15
> wTotalLength 42
> bNumDeviceCaps 3
> USB 2.0 Extension Device Capability:
> bLength 7
> bDescriptorType 16
> bDevCapabilityType 2
> bmAttributes 0x00000002
> Link Power Management (LPM) Supported
> SuperSpeed USB Device Capability:
> bLength 10
> bDescriptorType 16
> bDevCapabilityType 3
> bmAttributes 0x00
> wSpeedsSupported 0x000e
> Device can operate at Full Speed (12Mbps)
> Device can operate at High Speed (480Mbps)
> Device can operate at SuperSpeed (5Gbps)
> bFunctionalitySupport 1
> Lowest fully-functional device speed is Full Speed (12Mbps)
> bU1DevExitLat 10 micro seconds
> bU2DevExitLat 2047 micro seconds
> Container ID Device Capability:
> bLength 20
> bDescriptorType 16
> bDevCapabilityType 4
> bReserved 0
> ContainerID {d12781bb-91e8-34a5-a14d-c4e2646c9164}
> Device Status: 0x0001
> Self Powered
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
