Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
Alan Stern wrote: David, what can you make of that? I make that he should try with the patch I posted yesterday. It just finished 15 hours of usb-storage stress testing (two drives) on a VT6202 for me, maybe that'll reproduce for him? :) --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
On Mon, 16 Jun 2003, Major A wrote: It wouldn't be surprising if the file that cp hung on was the same one that generated those usb_bulk/control_msg timeouts in the previous set of I did a simpler version of what you told me, and it's the file /sys/devices/pci0/00:09.2/usb5/5-1/product that hangs. I can still read any other file, but that single file fails. Not too surprising, since reading that file causes a USB transfer to be performed, see core/driverfs.c:show_product(). However, the .../manufacturer file should do the same thing; maybe your device doesn't define that string. Here is a trace for the relevant processes: Jun 16 22:49:10 ventus kernel: cpD FFFE7555 4287842736 2176 2009 (NOTLB) Jun 16 22:49:10 ventus kernel: Call Trace: Jun 16 22:49:10 ventus kernel: [c012b168] schedule_timeout+0xa8/0xd0 Jun 16 22:49:10 ventus kernel: [c012b0b0] process_timeout+0x0/0x10 Jun 16 22:49:10 ventus kernel: [c02ae7d7] usb_start_wait_urb+0xd7/0x190 Jun 16 22:49:10 ventus kernel: [c011c290] default_wake_function+0x0/0x20 Jun 16 22:49:10 ventus kernel: [c011c290] default_wake_function+0x0/0x20 Jun 16 22:49:10 ventus kernel: [c02ae913] usb_internal_control_msg+0x83/0xa0 Jun 16 22:49:10 ventus kernel: [c02ae99e] usb_control_msg+0x6e/0x90 Jun 16 22:49:10 ventus kernel: [c02af44f] usb_get_string+0x3f/0x50 David, what can you make of that? It looks like it's stuck in schedule_timeout() waiting for a timer that must have already expired. Unless I'm reading it wrong and it's actually stuck in process_timeout() -- but all that does is call wake_up_process(). -?? Furthermore, this is the full log that I get when I unplug the device (in the hung state). The cp completes successfully on unplugging, and from then on any new cp also works fine. Its contents are VIA Technologies, In USB 2.0. Are you sure that's the same file? I would expect that to be the contents of .../usb5/product, not .../usb5/5-1/product. The rest of the log looks normal for a failing connection. The oops is reiserfs getting upset about its journalling device going offline. Alan Stern --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
On Mon, 16 Jun 2003, Major A wrote: This is the kernel log I got when I plugged the disk in: Jun 16 22:00:59 ventus kernel: sda1 Jun 16 22:00:59 ventus kernel: devfs_mk_dir: invalid argument.5Attached scsi disk sda at scsi2, channel 0, id 0, lun 0 Hmm... Try adding to drivers/scsi/sd.c, approximately line 1346, right after the line that says strcpy(gd-devfs_name,sdp-devfs_name); the statement printk(KERN_INFO scsi devfs_name: %s\n, sdp-devfs_name); and then try again plugging in the disk with sd_mod already loaded. Alan Stern --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
On Sat, 14 Jun 2003, David Brownell wrote: Major A wrote: [ 2.5.70 + ehci-0613 patch, log output sent, Subject: wrong ] Just to summarize for the peanut gallery: the logs showed no problems at all ... until the PCI files spontaneously vanished from sysfs. That's not allowed to happen, something's deeply wrong outside USB on that system if PCI goes that bad. Isn't it only in the last ehci-* directory that files are missing? Yes, only the PCI files -- but not ones added by the EHCI driver. Though the usb5/* directory was there, without its USB files; and without the subdirectory indicating any device plugged in. That is probably because cp fails to obtain these files after the actual crash/freeze, I guess, and also the reason why cp can't be killed (it's stuck in kernel mode). There was also the problem that there were only usb-storage messages, while a misbehavior of that magnitude should have been spewing *all sorts* of informative messages. You can use Alt-SysRq-T to find out the kernel stack info, too. (echo t /proc/sysrq* maybe.) To enable the magic sysrq key, echo 1 /proc/sys/kernel/sysrq. It wouldn't be surprising if the file that cp hung on was the same one that generated those usb_bulk/control_msg timeouts in the previous set of logs. Here's one way to find out which file is causing the problem. Andras, before you do your big md5sum, use find to create a list of all the regular files (not directories) in the sysfs subtree that you're copying. Then after usb-storage hangs up, have a little script go through that list, writing out the name of each file before trying to copy it somewhere else. The last name written out will be the one causing a problem. At that point, you could try removing that filename from the list and running the script again, to see if any other files also cause problems. Also, there's not much point in including the sysfs copies from before the hang occurs. All they do is show everything working correctly. It's the state of the system after everything stops that matters. Alan Stern --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
The sd_mod module is loaded automatically on boot. I find that when sd_mod is loaded at the time the USB drive is plugged in, the kernel doesn't find the partition table (fdisk claims it's blank), and any attempt to unload sd_mod segfaults. I had to unload the module before plugging the disk in to make things work. That sounds interesting. Can you post a copy of the oops output? Maybe also a copy of the usb-storage debugging log showing what happens when you try to run fdisk? There is no log output on doing fdisk -l /dev/sda. The drive does show up in /proc/scsi/scsi though, and the partition table is there because it works if sd_mod isn't loaded at the time the drive is connected. Here is the oops output. rmmod segfaults on this, in case that helps. Jun 16 22:01:53 ventus kernel: _devfs_find_entry(): too short Jun 16 22:01:53 ventus kernel: Unable to handle kernel NULL pointer dereference at virtual address 0020 Jun 16 22:01:53 ventus kernel: printing eip: Jun 16 22:01:53 ventus kernel: c01d01d2 Jun 16 22:01:53 ventus kernel: *pde = Jun 16 22:01:53 ventus kernel: Oops: [#1] Jun 16 22:01:53 ventus kernel: CPU:0 Jun 16 22:01:53 ventus kernel: EIP:0060:[c01d01d2]Not tainted Jun 16 22:01:53 ventus kernel: EFLAGS: 00010202 Jun 16 22:01:53 ventus kernel: EIP is at devfs_remove+0x42/0x60 Jun 16 22:01:53 ventus kernel: eax: e8fb4000 ebx: ecx: edx: e8fb4000 Jun 16 22:01:53 ventus kernel: esi: e91c6c48 edi: 0001 ebp: e8fb5ea8 esp: e8fb5e60 Jun 16 22:01:53 ventus kernel: ds: 007b es: 007b ss: 0068 Jun 16 22:01:53 ventus kernel: Process rmmod (pid: 2424, threadinfo=e8fb4000 task=e932c300) Jun 16 22:01:53 ventus kernel: Stack: e98f15b0 7261702f ef003174 efc85930 0286 efc85974 c03dd0e8 Jun 16 22:01:53 ventus kernel:e91cb300 0078 0074 c016f67b efff487c efc85934 0286 e8fb5ebc Jun 16 22:01:53 ventus kernel:c016f67b effefb48 e8fb5ec8 c01a6c45 c034bff6 e91c6c80 0001 0001 Jun 16 22:01:53 ventus kernel: Call Trace: Jun 16 22:01:53 ventus kernel: [c016f67b] bdput+0x12b/0x140 Jun 16 22:01:53 ventus kernel: [c016f67b] bdput+0x12b/0x140 Jun 16 22:01:53 ventus kernel: [c01a6c45] delete_partition+0x65/0x90 Jun 16 22:01:53 ventus kernel: [c01a714e] del_gendisk+0x1e/0xc0 Jun 16 22:01:53 ventus kernel: [f0864d08] sd_remove+0x18/0x170 [sd_mod] Jun 16 22:01:53 ventus kernel: [f0866904] sd_template+0x4/0x88 [sd_mod] Jun 16 22:01:53 ventus kernel: [f0866904] sd_template+0x4/0x88 [sd_mod] Jun 16 22:01:53 ventus kernel: [c027b042] device_release_driver+0x42/0x60 Jun 16 22:01:53 ventus kernel: [f0866964] sd_template+0x64/0x88 [sd_mod] Jun 16 22:01:53 ventus kernel: [f0866964] sd_template+0x64/0x88 [sd_mod] Jun 16 22:01:53 ventus kernel: [c027b07f] driver_detach+0x1f/0x40 Jun 16 22:01:53 ventus kernel: [c027b2ea] bus_remove_driver+0x3a/0x70 Jun 16 22:01:53 ventus kernel: [f0866904] sd_template+0x4/0x88 [sd_mod] Jun 16 22:01:53 ventus kernel: [f0866904] sd_template+0x4/0x88 [sd_mod] Jun 16 22:01:53 ventus kernel: [c027b69e] driver_unregister+0xe/0x35 Jun 16 22:01:53 ventus kernel: [f0866904] sd_template+0x4/0x88 [sd_mod] Jun 16 22:01:53 ventus kernel: [f08669c0] +0x0/0x140 [sd_mod] Jun 16 22:01:53 ventus kernel: [f086500b] +0x2b/0x60 [sd_mod] Jun 16 22:01:53 ventus kernel: [f0866904] sd_template+0x4/0x88 [sd_mod] Jun 16 22:01:53 ventus kernel: [f08669c0] +0x0/0x140 [sd_mod] Jun 16 22:01:53 ventus kernel: [c013cea8] sys_delete_module+0x168/0x190 Jun 16 22:01:53 ventus kernel: [c01556a4] sys_munmap+0x44/0x70 Jun 16 22:01:53 ventus kernel: [c0109c07] syscall_call+0x7/0xb Jun 16 22:01:53 ventus kernel: Jun 16 22:01:53 ventus kernel: Code: 8b 43 20 50 e8 75 fc ff ff 53 e8 ff e9 ff ff 53 e8 f9 e9 ff Jun 16 22:01:53 ventus kernel: 6note: rmmod[2424] exited with preempt_count 1 Jun 16 22:01:53 ventus kernel: bad: scheduling while atomic! Jun 16 22:01:53 ventus kernel: Call Trace: Jun 16 22:01:53 ventus kernel: [c011bcac] schedule+0x3c/0x5d0 Jun 16 22:01:53 ventus kernel: [c0150504] unmap_vmas+0xf4/0x2d0 Jun 16 22:01:53 ventus kernel: [c011dd97] __cond_resched+0x17/0x20 Jun 16 22:01:53 ventus kernel: [c01505d5] unmap_vmas+0x1c5/0x2d0 Jun 16 22:01:53 ventus kernel: [c01559d6] exit_mmap+0xd6/0x240 Jun 16 22:01:53 ventus kernel: [c011eddd] mmput+0xcd/0xf0 Jun 16 22:01:53 ventus kernel: [c0124596] do_exit+0x286/0x990 Jun 16 22:01:53 ventus kernel: [c010acfc] die+0x1cc/0x1d0 Jun 16 22:01:53 ventus kernel: [c011951c] do_page_fault+0x2dc/0x40a Jun 16 22:01:53 ventus kernel: [c0119240] do_page_fault+0x0/0x40a Jun 16 22:01:53 ventus kernel: [c011c012] schedule+0x3a2/0x5d0 Jun 16 22:01:53 ventus kernel: [c011c26c] preempt_schedule+0x2c/0x50 Jun 16 22:01:53 ventus kernel: [c011c410] __wake_up+0x110/0x120 Jun 16 22:01:53 ventus kernel: [c012263f] release_console_sem+0x23f/0x250 Jun 16 22:01:53 ventus
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
It wouldn't be surprising if the file that cp hung on was the same one that generated those usb_bulk/control_msg timeouts in the previous set of I'll try to reproduce that behaviour in a moment, but first I have some more news: I borrowed an NEC-based USB 2.0 PCI card today, and the USB HDD works without any problems with 2.4.21 with ehci24-0613 applied (haven't tried without). That is, I could read the contents of the entire drive (28GB), write another 2GB onto it, and it didn't crash or hang or anything. Now the bad news -- the same card doesn't work with 2.5.70-bk9 with ehci-0613. It does very much the same as the EHCI on the motherboard (VIA), except that the sysfs files can all be copied at all times. Here is the end of the log, in case it helps, and I've attached a tarball with the sysfs files. Jun 16 22:30:03 ventus kernel: usb-storage: *** thread awakened. Jun 16 22:30:03 ventus kernel: usb-storage: Command READ_10 (10 bytes) Jun 16 22:30:03 ventus kernel: usb-storage: 28 00 02 dc 0b b0 00 00 80 00 Jun 16 22:30:03 ventus kernel: usb-storage: Bulk command S 0x43425355 T 0x11a Trg 0 LUN 0 L 65536 F 128 CL 10 Jun 16 22:30:03 ventus kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jun 16 22:30:03 ventus kernel: usb-storage: Status code 0; transferred 31/31 Jun 16 22:30:03 ventus kernel: usb-storage: -- transfer complete Jun 16 22:30:03 ventus kernel: usb-storage: Bulk command transfer result=0 Jun 16 22:30:03 ventus kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 65536 bytes, 16 entries Jun 16 22:30:03 ventus kernel: usb-storage: Status code 0; transferred 65536/65536 Jun 16 22:30:03 ventus kernel: usb-storage: -- transfer complete Jun 16 22:30:03 ventus kernel: usb-storage: Bulk data transfer result 0x0 Jun 16 22:30:03 ventus kernel: usb-storage: Attempting to get CSW... Jun 16 22:30:03 ventus kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jun 16 22:30:03 ventus kernel: usb-storage: Status code 0; transferred 13/13 Jun 16 22:30:03 ventus kernel: usb-storage: -- transfer complete Jun 16 22:30:03 ventus kernel: usb-storage: Bulk status result = 0 Jun 16 22:30:03 ventus kernel: usb-storage: Bulk status Sig 0x53425355 T 0x11a R 0 Stat 0x0 Jun 16 22:30:03 ventus kernel: usb-storage: scsi cmd done, result=0x0 Jun 16 22:30:03 ventus kernel: usb-storage: *** thread sleeping. Jun 16 22:30:03 ventus kernel: usb-storage: queuecommand() called Jun 16 22:30:03 ventus kernel: usb-storage: *** thread awakened. Jun 16 22:30:03 ventus kernel: usb-storage: Command READ_10 (10 bytes) Jun 16 22:30:03 ventus kernel: usb-storage: 28 00 02 dc 0c 30 00 00 90 00 Jun 16 22:30:03 ventus kernel: usb-storage: Bulk command S 0x43425355 T 0x11b Trg 0 LUN 0 L 73728 F 128 CL 10 Jun 16 22:30:03 ventus kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jun 16 22:30:03 ventus kernel: usb-storage: Status code 0; transferred 31/31 Jun 16 22:30:03 ventus kernel: usb-storage: -- transfer complete Jun 16 22:30:03 ventus kernel: usb-storage: Bulk command transfer result=0 Jun 16 22:30:03 ventus kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 73728 bytes, 18 entries Jun 16 22:30:03 ventus kernel: usb-storage: Status code 0; transferred 73728/73728 Jun 16 22:30:03 ventus kernel: usb-storage: -- transfer complete Jun 16 22:30:03 ventus kernel: usb-storage: Bulk data transfer result 0x0 Jun 16 22:30:03 ventus kernel: usb-storage: Attempting to get CSW... Jun 16 22:30:03 ventus kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jun 16 22:30:03 ventus kernel: usb-storage: Status code 0; transferred 13/13 Jun 16 22:30:03 ventus kernel: usb-storage: -- transfer complete Jun 16 22:30:03 ventus kernel: usb-storage: Bulk status result = 0 Jun 16 22:30:03 ventus kernel: usb-storage: Bulk status Sig 0x53425355 T 0x11b R 0 Stat 0x0 Jun 16 22:30:03 ventus kernel: usb-storage: scsi cmd done, result=0x0 Jun 16 22:30:03 ventus kernel: usb-storage: *** thread sleeping. Jun 16 22:30:03 ventus kernel: usb-storage: queuecommand() called Jun 16 22:30:03 ventus kernel: usb-storage: *** thread awakened. Jun 16 22:30:03 ventus kernel: usb-storage: Command READ_10 (10 bytes) Jun 16 22:30:03 ventus kernel: usb-storage: 28 00 02 dc 0c c0 00 01 00 00 Jun 16 22:30:03 ventus kernel: usb-storage: Bulk command S 0x43425355 T 0x11c Trg 0 LUN 0 L 131072 F 128 CL 10 Jun 16 22:30:03 ventus kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jun 16 22:30:03 ventus kernel: usb-storage: Status code 0; transferred 31/31 Jun 16 22:30:03 ventus kernel: usb-storage: -- transfer complete Jun 16 22:30:03 ventus kernel: usb-storage: Bulk command transfer result=0 Jun 16 22:30:03 ventus kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 131072 bytes, 32 entries Jun 16 22:30:03 ventus kernel: usb-storage: Status code 0; transferred 131072/131072 Jun 16 22:30:03 ventus kernel: usb-storage: -- transfer complete Jun 16
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
Sorry, pressed the wrong button at the wrong time. Here is the sysfs tarball. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ehci.tar.bz2 Description: Binary data
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
It wouldn't be surprising if the file that cp hung on was the same one that generated those usb_bulk/control_msg timeouts in the previous set of I did a simpler version of what you told me, and it's the file /sys/devices/pci0/00:09.2/usb5/5-1/product that hangs. I can still read any other file, but that single file fails. Here is a trace for the relevant processes: Jun 16 22:49:10 ventus kernel: usb-storage D E8FC4000 4291389936 2093 1 2094 2078 (L-TLB) Jun 16 22:49:10 ventus kernel: Call Trace: Jun 16 22:49:10 ventus kernel: [c011c935] wait_for_completion+0x175/0x290 Jun 16 22:49:10 ventus kernel: [c011c290] default_wake_function+0x0/0x20 Jun 16 22:49:10 ventus kernel: [c011c290] default_wake_function+0x0/0x20 Jun 16 22:49:10 ventus kernel: [c02b9357] usb_stor_msg_common+0x137/0x170 Jun 16 22:49:10 ventus kernel: [c012263f] release_console_sem+0x23f/0x250 Jun 16 22:49:10 ventus kernel: [c02b98e9] usb_stor_bulk_transfer_buf+0x79/0xc0 Jun 16 22:49:10 ventus kernel: [c02ba27c] usb_stor_Bulk_transport+0x17c/0x230 Jun 16 22:49:10 ventus kernel: [c011c2e3] __wake_up_common+0x33/0x50 Jun 16 22:49:10 ventus kernel: [c02b9aa3] usb_stor_invoke_transport+0x23/0x390 Jun 16 22:49:10 ventus kernel: [c012230f] printk+0x26f/0x310 Jun 16 22:49:10 ventus kernel: [c02b9180] usb_stor_transparent_scsi_command+0xd0/0x110 Jun 16 22:49:10 ventus kernel: [c02bad20] usb_stor_control_thread+0x4d0/0x6f0 Jun 16 22:49:10 ventus kernel: [c02ba850] usb_stor_control_thread+0x0/0x6f0 Jun 16 22:49:10 ventus kernel: [c0107331] kernel_thread_helper+0x5/0x14 Jun 16 22:49:10 ventus kernel: scsi_eh_2 S E8F92000 4291188464 2094 1 2093 (L-TLB) Jun 16 22:49:10 ventus kernel: Call Trace: Jun 16 22:49:10 ventus kernel: [c011c2a9] default_wake_function+0x19/0x20 Jun 16 22:49:10 ventus kernel: [c01082a5] __down_interruptible+0x175/0x2c0 Jun 16 22:49:10 ventus kernel: [c011c290] default_wake_function+0x0/0x20 Jun 16 22:49:10 ventus kernel: [c010854e] __down_failed_interruptible+0xa/0x10 Jun 16 22:49:10 ventus kernel: [c029f641] .text.lock.scsi_error+0x41/0x50 Jun 16 22:49:10 ventus kernel: [c029f0b0] scsi_error_handler+0x0/0x310 Jun 16 22:49:10 ventus kernel: [c0107331] kernel_thread_helper+0x5/0x14 Jun 16 22:49:10 ventus kernel: md5sumD E8971E24 4288961712 2174 2131 (NOTLB) Jun 16 22:49:10 ventus kernel: Call Trace: Jun 16 22:49:10 ventus kernel: [c011ddce] io_schedule+0xe/0x20 Jun 16 22:49:10 ventus kernel: [c0140217] __lock_page+0x87/0xb0 Jun 16 22:49:10 ventus kernel: [c011ea70] autoremove_wake_function+0x0/0x40 Jun 16 22:49:10 ventus kernel: [c011ea70] autoremove_wake_function+0x0/0x40 Jun 16 22:49:10 ventus kernel: [c0140cd3] do_generic_mapping_read+0x183/0x460 Jun 16 22:49:10 ventus kernel: [c0141240] __generic_file_aio_read+0x180/0x1a0 Jun 16 22:49:10 ventus kernel: [c0140fb0] file_read_actor+0x0/0x110 Jun 16 22:49:10 ventus kernel: [c014132f] generic_file_read+0x7f/0xa0 Jun 16 22:49:10 ventus kernel: [c0152eb0] handle_mm_fault+0xf0/0x270 Jun 16 22:49:10 ventus kernel: [c011938b] do_page_fault+0x14b/0x40a Jun 16 22:49:10 ventus kernel: [c011b4b1] try_to_wake_up+0x1f1/0x200 Jun 16 22:49:10 ventus kernel: [c012b0b0] process_timeout+0x0/0x10 Jun 16 22:49:10 ventus kernel: [c011b4cf] wake_up_process+0xf/0x20 Jun 16 22:49:10 ventus kernel: [c012b0bb] process_timeout+0xb/0x10 Jun 16 22:49:10 ventus kernel: [c012ae92] run_timer_softirq+0x2f2/0x300 Jun 16 22:49:10 ventus kernel: [c01649be] vfs_read+0x9e/0xd0 Jun 16 22:49:10 ventus kernel: [c0164ba0] sys_read+0x30/0x50 Jun 16 22:49:10 ventus kernel: [c0109c07] syscall_call+0x7/0xb Jun 16 22:49:10 ventus kernel: cpD FFFE7555 4287842736 2176 2009 (NOTLB) Jun 16 22:49:10 ventus kernel: Call Trace: Jun 16 22:49:10 ventus kernel: [c012b168] schedule_timeout+0xa8/0xd0 Jun 16 22:49:10 ventus kernel: [c012b0b0] process_timeout+0x0/0x10 Jun 16 22:49:10 ventus kernel: [c02ae7d7] usb_start_wait_urb+0xd7/0x190 Jun 16 22:49:10 ventus kernel: [c011c290] default_wake_function+0x0/0x20 Jun 16 22:49:10 ventus kernel: [c011c290] default_wake_function+0x0/0x20 Jun 16 22:49:10 ventus kernel: [c02ae913] usb_internal_control_msg+0x83/0xa0 Jun 16 22:49:10 ventus kernel: [c02ae99e] usb_control_msg+0x6e/0x90 Jun 16 22:49:10 ventus kernel: [c02af44f] usb_get_string+0x3f/0x50 Jun 16 22:49:10 ventus kernel: [c02afa69] usb_string+0xd9/0x160 Jun 16 22:49:10 ventus kernel: [c02b1054] show_product+0x24/0x40 Jun 16 22:49:10 ventus kernel: [c027a18d] dev_attr_show+0x1d/0x30 Jun 16 22:49:10 ventus kernel: [c01a7fb5] fill_read_buffer+0x55/0x70 Jun 16 22:49:10 ventus kernel: [c01a808c] sysfs_read_file+0x1c/0x40 Jun 16 22:49:10 ventus kernel: [c01649be] vfs_read+0x9e/0xd0 Jun 16 22:49:10 ventus kernel: [c0164ba0] sys_read+0x30/0x50 Jun 16 22:49:10 ventus kernel: [c0109c07]
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
Major A wrote: I'll try to reproduce that behaviour in a moment, but first I have some more news: I borrowed an NEC-based USB 2.0 PCI card today, and the USB HDD works without any problems with 2.4.21 with ehci24-0613 ... Now the bad news -- the same card doesn't work with 2.5.70-bk9 with ehci-0613. ... ... try with the patch I just sent by. One of the problems it resolves could explain all those inconsistencies. --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
Tomita, Haruo wrote: Thank you very much. I tried your patch. In VT6202, it was unstable. OK, so I've had three reports of problems with VT6202. Looks like I'll need to swap a card... that chip has given more trouble than all the others combined! I've tested reasonably extensively with VT6212, ISP1562, VT8235, and the NEC 0.95 chip using that patch, and didn't see any problems during two days of stress testing with usb-storage (multiple drives). It'd be good to know whether you see issues with other controllers. Thanks for the feedback. - Dave --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
Dave wrote, Haruo Thank you very much. I tried your patch. Haruo In VT6202, it was unstable. Dave OK, so I've had three reports of problems with VT6202. Dave Looks like I'll need to swap a card... that chip has Dave given more trouble than all the others combined! What is the problem of VT6202? Please let me know. # I also think that VT6202 is unstable. # Is this the problem of a chip? Dave I've tested reasonably extensively with VT6212, ISP1562, Dave VT8235, and the NEC 0.95 chip using that patch, and didn't Dave see any problems during two days of stress testing with Dave usb-storage (multiple drives). It'd be good to know Dave whether you see issues with other controllers. OK. I test in NEC (uPD720100A). Of course, the test of VT6202 is also continued. It will repot, if a result comes out. Dave Thanks for the feedback. You are welcomed. Please give mail, if it may be able to cooperate in me. Thanks!! Haruo --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
Major A wrote: [ 2.5.70 + ehci-0613 patch, log output sent, Subject: wrong ] After mounting (which went fine), and listing a few directories, the command md5sum *.png md5sums was entered. When the problem occurred, the system load climbed continuously to 5 and has stayed there since, top says the CPU spends all its time in IO-wait mode. Just to summarize for the peanut gallery: the logs showed no problems at all ... until the PCI files spontaneously vanished from sysfs. That's not allowed to happen, something's deeply wrong outside USB on that system if PCI goes that bad. - Dave --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
Major A wrote: [ 2.5.70 + ehci-0613 patch, log output sent, Subject: wrong ] Just to summarize for the peanut gallery: the logs showed no problems at all ... until the PCI files spontaneously vanished from sysfs. That's not allowed to happen, something's deeply wrong outside USB on that system if PCI goes that bad. Isn't it only in the last ehci-* directory that files are missing? Yes, only the PCI files -- but not ones added by the EHCI driver. Though the usb5/* directory was there, without its USB files; and without the subdirectory indicating any device plugged in. That is probably because cp fails to obtain these files after the actual crash/freeze, I guess, and also the reason why cp can't be killed (it's stuck in kernel mode). There was also the problem that there were only usb-storage messages, while a misbehavior of that magnitude should have been spewing *all sorts* of informative messages. You can use Alt-SysRq-T to find out the kernel stack info, too. (echo t /proc/sysrq* maybe.) - Dave --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
Dear Dave, Dave wrote, Dave This patch brings the 2.4.21-rc8 EHCI driver mostly back Dave into sync with the latest 2.5 driver (*), and adds a patch Dave to avoid a relink problem (symptoms: rx hang, tx overflow) Dave which causes trouble on 2.4 (especially with usb-storage). Dave I was able to reproduce some of the 2.4 problems folk had Dave been reporting recently, and verified they went away. Dave Please give it a try. Thank you very much. I tried your patch. In VT6202, it was unstable. The I/O error occurred. For the moment, it generates and the issue of a lock does not become precocious. It is dmesg when becoming an error. Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.12 scsi0: ERROR on channel 0, id 0, lun 0, CDB: Read (10) 00 00 00 1e a4 00 00 3f 00 Current sd0b:00: sense key Medium Error Additional sense indicates No seek complete I/O error: dev 0b:00, sector 31376 scsi0: ERROR on channel 0, id 0, lun 0, CDB: Read (10) 00 00 00 1e e3 00 00 01 00 Current sd0b:00: sense key Medium Error Additional sense indicates No seek complete I/O error: dev 0b:00, sector 31628 scsi0: ERROR on channel 0, id 0, lun 0, CDB: Read (10) 00 00 00 1e a4 00 00 02 00 Current sd0b:00: sense key Medium Error Additional sense indicates No seek complete I/O error: dev 0b:00, sector 31376 I test again. A result is reported later. Thanks!! Haruo --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
On Sat, 14 Jun 2003, Major A wrote: The sd_mod module is loaded automatically on boot. I find that when sd_mod is loaded at the time the USB drive is plugged in, the kernel doesn't find the partition table (fdisk claims it's blank), and any attempt to unload sd_mod segfaults. I had to unload the module before plugging the disk in to make things work. That sounds interesting. Can you post a copy of the oops output? Maybe also a copy of the usb-storage debugging log showing what happens when you try to run fdisk? Alan Stern --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
This patch brings the 2.4.21-rc8 EHCI driver mostly back into sync with the latest 2.5 driver (*), and adds a patch to avoid a relink problem (symptoms: rx hang, tx overflow) which causes trouble on 2.4 (especially with usb-storage). Just tried (patched 2.4.21 with it) with the hard drive, it really does the same as 2.5.70-bk8 with your earlier patch (ehci-0609.patch): it hangs. In fact, 2.4.21 was a bit better than this, and 2.4.20 was loads better. Not sure whether it's this patch or just plain 2.4.21 that causes trouble -- I haven't tried the latter. Let me know if I can do some more testing. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
The last 2.5 patch was ehci-0612, and it had key differences from 0609 that affected problems I saw on NEC hardware, which you were using. (You never tested 0610...) Attached, you'll see ohci-0613, which should be just 0612 with that relink fix. I'm confused -- what does this have to do with ohci? I'm not using NEC hardware BTW, that was my hub which I have since disconnected. The EHCI is a VIA. Is it still worth trying this one? At least provide a good description of your _current_ failure mode. Doing it on 2.5 with the sysfs dumps would be most useful, also answering all the usual questions about what exactly hangs, and how. Descriptions like it hangs are pretty useless. Sorry for not being specific: it fails in exactly the same way as 2.5.70-bk8 with ehci-0609 did, and I sent you detailed logs and sysfs dumps of that one. (BTW, the NEC hub wasn't connected at the time of the logs.) I'll try any configuration you like, just let me know which one. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
Major A wrote: The last 2.5 patch was ehci-0612, and it had key differences from 0609 that affected problems I saw on NEC hardware, which you were using. (You never tested 0610...) Attached, you'll see ohci-0613, which should be just 0612 with that relink fix. I'm confused -- what does this have to do with ohci? Nothing except a small typo, the attachment was ehci-0613... Sorry for not being specific: it fails in exactly the same way as 2.5.70-bk8 with ehci-0609 did, and I sent you detailed logs and sysfs dumps of that one. (BTW, the NEC hub wasn't connected at the time of the logs.) I'll try any configuration you like, just let me know which one. Add ehci-0613 and send the logs + sysfs output on 2.5 ... the diagnostic info in sysfs changed slightly, it should show a few things that weren't previously visible. - Dave --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
Correction: doesn't find the partition table (fdisk claims it's blank), and any attempt to unload sd_mod segfaults. I had to unload the module before ^ Sorry, this should read causes an oops. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 2.4.21-rc8] ehci-hcd updates
Major A wrote: The sd_mod module is loaded automatically on boot. I find that when sd_mod is loaded at the time the USB drive is plugged in, the kernel doesn't find the partition table (fdisk claims it's blank), and any attempt to unload sd_mod segfaults. I had to unload the module before plugging the disk in to make things work. I noticed another report about partition table bugs recently, with an SBP2 (firewire) drive. It might be the same bug. Thanks for the log data, I'll look at it. - Dave --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
