Re: Disabling in-memory write cache for x86-64 in Linux II
On Tue 131029, Jan Kara wrote: > On Fri 25-10-13 11:15:55, Karl Kiniger wrote: > > On Fri 131025, Linus Torvalds wrote: > > Is it currently possible to somehow set above values per block device? > Yes, to some extent. You can set /sys/block//bdi/max_ratio to > the maximum proportion the device's dirty data can take from the total > amount. The caveat currently is that this setting only takes effect after > we have more than (dirty_background_ratio + dirty_ratio)/2 dirty data in > total because that is an amount of dirty data when we start to throttle > processes. So if the device you'd like to limit is the only one which is > currently written to, the limiting doesn't have a big effect. Thanks for the info - thats was I am looking for. You are right that the limiting doesn't have a big effect right now: on my 4x speed DVD+RW on /dev/sr0, x86_64, 4GB, Fedora19: max_ratio set to 100 - about 500MB buffered, sync time 2:10 min. max_ratio set to 1- about 330MB buffered, sync time 1:23 min. ... way too much buffering. (measured with strace -tt -ewrite dd if=/dev/zero of=bigfile bs=1M count=1000 by looking at the timestamps). Karl Honza > -- > Jan Kara > SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disabling in-memory write cache for x86-64 in Linux II
On Tue 131029, Jan Kara wrote: On Fri 25-10-13 11:15:55, Karl Kiniger wrote: On Fri 131025, Linus Torvalds wrote: Is it currently possible to somehow set above values per block device? Yes, to some extent. You can set /sys/block/device/bdi/max_ratio to the maximum proportion the device's dirty data can take from the total amount. The caveat currently is that this setting only takes effect after we have more than (dirty_background_ratio + dirty_ratio)/2 dirty data in total because that is an amount of dirty data when we start to throttle processes. So if the device you'd like to limit is the only one which is currently written to, the limiting doesn't have a big effect. Thanks for the info - thats was I am looking for. You are right that the limiting doesn't have a big effect right now: on my 4x speed DVD+RW on /dev/sr0, x86_64, 4GB, Fedora19: max_ratio set to 100 - about 500MB buffered, sync time 2:10 min. max_ratio set to 1- about 330MB buffered, sync time 1:23 min. ... way too much buffering. (measured with strace -tt -ewrite dd if=/dev/zero of=bigfile bs=1M count=1000 by looking at the timestamps). Karl Honza -- Jan Kara j...@suse.cz SUSE Labs, CR -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disabling in-memory write cache for x86-64 in Linux II
On Fri 131025, Linus Torvalds wrote: > On Fri, Oct 25, 2013 at 9:30 AM, Artem S. Tashkinov wrote: > > > > My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be > > percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or > > more) this value becomes unrealistic (13GB) and I've already had some > > unpleasant effects due to it. > > Right. The percentage notion really goes back to the days when we > typically had 8-64 *megabytes* of memory So if you had a 8MB machine > you wouldn't want to have more than one megabyte of dirty data, but if > you were "Mr Moneybags" and could afford 64MB, you might want to have > up to 8MB dirty!! > > Things have changed. > > So I would suggest we change the defaults. Or pwehaps make the rule be > that "the ratio numbers are 'ratio of memory up to 1GB'", to make the > semantics similar across 32-bit HIGHMEM machines and 64-bit machines. > > The modern way of expressing the dirty limits are to give the actual > absolute byte amounts, but we default to the legacy ratio mode.. > > Linus Is it currently possible to somehow set above values per block device? I want default behaviour for almost everything but DVD drives in DVD+RW packet writing mode may easily take several minutes in case of a sync. Karl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disabling in-memory write cache for x86-64 in Linux II
On Fri 131025, Linus Torvalds wrote: On Fri, Oct 25, 2013 at 9:30 AM, Artem S. Tashkinov t.ar...@lycos.com wrote: My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or more) this value becomes unrealistic (13GB) and I've already had some unpleasant effects due to it. Right. The percentage notion really goes back to the days when we typically had 8-64 *megabytes* of memory So if you had a 8MB machine you wouldn't want to have more than one megabyte of dirty data, but if you were Mr Moneybags and could afford 64MB, you might want to have up to 8MB dirty!! Things have changed. So I would suggest we change the defaults. Or pwehaps make the rule be that the ratio numbers are 'ratio of memory up to 1GB', to make the semantics similar across 32-bit HIGHMEM machines and 64-bit machines. The modern way of expressing the dirty limits are to give the actual absolute byte amounts, but we default to the legacy ratio mode.. Linus Is it currently possible to somehow set above values per block device? I want default behaviour for almost everything but DVD drives in DVD+RW packet writing mode may easily take several minutes in case of a sync. Karl -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tracing SCSI commands over SATA
Hi, I want to record all SCSI commands/status for a SATA DVD drive. Right now I am using a USB<>SATA bridge and wireshark on usbmon. Q: Can something similar be done without having to go over USB? I am interested only about the SCSI commands sent to a particular SATA drive and resulting status codes and also timing. ...looking for possible causes why a few drives are locking up for 10..20 minutes on DVD+RW packet writing on UDF and then continue like nothing happened. (linux tries hard to reset but the drives dont accept any commands until the 10..20 minutes are over), not even INQUIRE, nothing. Karl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
per block device cache use adjustable?
Using a 4.7 GB 4x DVD+RW I did: (Fedora 19, x86_64, 4GB RAM) mkudffs /dev/sr0 mount /dev/sr0 /dvd0 dd if=some-4gb-file of=/dvd0/bigfile.bin After a few seconds ls -l /dvd0/bigfile.bin displayed 600 MB which means that more than 30 seconds are kept in RAM. Is it possible to limit the write cache to a sane value for this specific device? (perhaps a few seconds at 2..3 MB/sec write speed) Thanks in advance for anything helpful, Karl PS: dd oflag=direct helps of course but I would like to have a tuning knob to play with to get optimal performance in my situation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
per block device cache use adjustable?
Using a 4.7 GB 4x DVD+RW I did: (Fedora 19, x86_64, 4GB RAM) mkudffs /dev/sr0 mount /dev/sr0 /dvd0 dd if=some-4gb-file of=/dvd0/bigfile.bin After a few seconds ls -l /dvd0/bigfile.bin displayed 600 MB which means that more than 30 seconds are kept in RAM. Is it possible to limit the write cache to a sane value for this specific device? (perhaps a few seconds at 2..3 MB/sec write speed) Thanks in advance for anything helpful, Karl PS: dd oflag=direct helps of course but I would like to have a tuning knob to play with to get optimal performance in my situation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tracing SCSI commands over SATA
Hi, I want to record all SCSI commands/status for a SATA DVD drive. Right now I am using a USBSATA bridge and wireshark on usbmon. Q: Can something similar be done without having to go over USB? I am interested only about the SCSI commands sent to a particular SATA drive and resulting status codes and also timing. ...looking for possible causes why a few drives are locking up for 10..20 minutes on DVD+RW packet writing on UDF and then continue like nothing happened. (linux tries hard to reset but the drives dont accept any commands until the 10..20 minutes are over), not even INQUIRE, nothing. Karl -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
On Wed 080123, Andi Kleen wrote: > Karl Kiniger <[EMAIL PROTECTED]> writes: > > > FYI, > > > > on http://www.feise.com/~jfeise/Downloads/linux-abi/ > > > > a patch named linux-abi-2.6.22.3_3.diff.bz2 can be found. > > So just add a reversed version of my binfmt_elf patch to that. > If people need to apply a patch anyways it doesn't make much > difference if it has a few more hunks. it will force to recompile. The latest version of linux-abi on SourceForge is named ibcs-3_4.tgz and IIRC it can be built as an external module w/o kernel recompile. Karl > > -Andi -- Karl Kinigermailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH & Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 Voip(GE): 1662 710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 C: +43 6991 3800 710 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
On Wed 080123, Andi Kleen wrote: Karl Kiniger [EMAIL PROTECTED] writes: FYI, on http://www.feise.com/~jfeise/Downloads/linux-abi/ a patch named linux-abi-2.6.22.3_3.diff.bz2 can be found. So just add a reversed version of my binfmt_elf patch to that. If people need to apply a patch anyways it doesn't make much difference if it has a few more hunks. it will force to recompile. The latest version of linux-abi on SourceForge is named ibcs-3_4.tgz and IIRC it can be built as an external module w/o kernel recompile. Karl -Andi -- Karl Kinigermailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 Voip(GE): 1662 710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 C: +43 6991 3800 710 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
On Tue 080122, Ingo Molnar wrote: > > * David Newall <[EMAIL PROTECTED]> wrote: > > > Andi Kleen wrote: > > > You seem to be under the illusion that iBCS2 support works currently > > > in mainline and that only this patch would break it. > > > > I cannot imagine what brings you to that conclusion. Suffice to say > > you are entirely and inexplicably wrong. > > it should be very easy for you to prove me wrong then. I've got a very > simple question: please tell me, how do i run a binary compiled for an > iBCS2 platform under Linux v2.6.23? at least the Changelog for ibcs-3.4.tar.gz found on http://sourceforge.net/project/showfiles.php?group_id=13130 says: 2007-10-11 Alex <[EMAIL PROTECTED]> ibcs-3.4 * support for Kernel 2.6.23 added * support for SUSE AppArmor I did not try this one myself. Karl > > I've got plenty of v2.6.23-running testsystems, tell me, if i wanted, > how could i run any iBCS2 binary on them? All i see is a massive, > 2.4-kernels-only patchkit: > >http://www.kernel.org/pub/linux/kernel/people/hch/linux-abi/v2.4/ > > which external patch-kit was not picked up by major distros and which > was never integrated into the upstream kernel either. iBCS2 support in > Linux 2.6 simply does not exist. > > Ingo > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Karl Kinigermailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH & Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 Voip(GE): 1662 710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 C: +43 6991 3800 710 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
FYI, on http://www.feise.com/~jfeise/Downloads/linux-abi/ a patch named linux-abi-2.6.22.3_3.diff.bz2 can be found. (and I know a friend of mine got it working OK - old Informix 4GL medical app compiled for SCO ... :-) Karl On Mon 080121, David Newall wrote: > Andi Kleen wrote: > > You seem to be under the illusion that iBCS2 support works currently > > in mainline and that only this patch would break it. > I cannot imagine what brings you to that conclusion. Suffice to say you > are entirely and inexplicably wrong. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Karl Kinigermailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH & Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 Voip(GE): 1662 710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 C: +43 6991 3800 710 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
FYI, on http://www.feise.com/~jfeise/Downloads/linux-abi/ a patch named linux-abi-2.6.22.3_3.diff.bz2 can be found. (and I know a friend of mine got it working OK - old Informix 4GL medical app compiled for SCO ... :-) Karl On Mon 080121, David Newall wrote: Andi Kleen wrote: You seem to be under the illusion that iBCS2 support works currently in mainline and that only this patch would break it. I cannot imagine what brings you to that conclusion. Suffice to say you are entirely and inexplicably wrong. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Karl Kinigermailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 Voip(GE): 1662 710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 C: +43 6991 3800 710 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for mm] Remove iBCS support
On Tue 080122, Ingo Molnar wrote: * David Newall [EMAIL PROTECTED] wrote: Andi Kleen wrote: You seem to be under the illusion that iBCS2 support works currently in mainline and that only this patch would break it. I cannot imagine what brings you to that conclusion. Suffice to say you are entirely and inexplicably wrong. it should be very easy for you to prove me wrong then. I've got a very simple question: please tell me, how do i run a binary compiled for an iBCS2 platform under Linux v2.6.23? at least the Changelog for ibcs-3.4.tar.gz found on http://sourceforge.net/project/showfiles.php?group_id=13130 says: 2007-10-11 Alex [EMAIL PROTECTED] ibcs-3.4 * support for Kernel 2.6.23 added * support for SUSE AppArmor I did not try this one myself. Karl I've got plenty of v2.6.23-running testsystems, tell me, if i wanted, how could i run any iBCS2 binary on them? All i see is a massive, 2.4-kernels-only patchkit: http://www.kernel.org/pub/linux/kernel/people/hch/linux-abi/v2.4/ which external patch-kit was not picked up by major distros and which was never integrated into the upstream kernel either. iBCS2 support in Linux 2.6 simply does not exist. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Karl Kinigermailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 Voip(GE): 1662 710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 C: +43 6991 3800 710 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
list_del corruption with fedora 6 kernels (fc5 was ok)
Jan 12 10:57:23 wszip-kinigka kernel: [] error_code+0x39/0x40 Jan 12 10:57:23 wszip-kinigka kernel: DWARF2 unwinder stuck at error_code+0x39/0x40 Jan 12 10:57:23 wszip-kinigka kernel: Leftover inexact backtrace: Jan 12 10:57:23 wszip-kinigka kernel: [] list_del+0x23/0x6c Jan 12 10:57:23 wszip-kinigka kernel: [] free_block+0x63/0xdc Jan 12 10:57:23 wszip-kinigka kernel: [] drain_array+0x8a/0xb5 Jan 12 10:57:23 wszip-kinigka kernel: [] cache_reap+0x53/0x117 Jan 12 10:57:23 wszip-kinigka kernel: [] run_workqueue+0x83/0xc5 Jan 12 10:57:23 wszip-kinigka kernel: [] cache_reap+0x0/0x117 Jan 12 10:57:23 wszip-kinigka kernel: [] worker_thread+0xd9/0x10d Jan 12 10:57:23 wszip-kinigka kernel: [] default_wake_function+0x0/0xc Jan 12 10:57:23 wszip-kinigka kernel: [] worker_thread+0x0/0x10d Jan 12 10:57:23 wszip-kinigka kernel: [] kthread+0xc0/0xed Jan 12 10:57:23 wszip-kinigka kernel: [] kthread+0x0/0xed Jan 12 10:57:23 wszip-kinigka kernel: [] kernel_thread_helper+0x7/0x10 Jan 12 10:57:23 wszip-kinigka kernel: ======= -- Karl Kiniger mailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH & Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
list_del corruption with fedora 6 kernels (fc5 was ok)
kernel: [c040588e] die+0x29d/0x2c2 Jan 12 10:57:23 wszip-kinigka kernel: [c0405fd3] do_invalid_op+0xa2/0xab Jan 12 10:57:23 wszip-kinigka kernel: [c0404b85] error_code+0x39/0x40 Jan 12 10:57:23 wszip-kinigka kernel: DWARF2 unwinder stuck at error_code+0x39/0x40 Jan 12 10:57:23 wszip-kinigka kernel: Leftover inexact backtrace: Jan 12 10:57:23 wszip-kinigka kernel: [c04e99ab] list_del+0x23/0x6c Jan 12 10:57:23 wszip-kinigka kernel: [c046b553] free_block+0x63/0xdc Jan 12 10:57:23 wszip-kinigka kernel: [c046b656] drain_array+0x8a/0xb5 Jan 12 10:57:23 wszip-kinigka kernel: [c046ca7a] cache_reap+0x53/0x117 Jan 12 10:57:23 wszip-kinigka kernel: [c0433c18] run_workqueue+0x83/0xc5 Jan 12 10:57:23 wszip-kinigka kernel: [c046ca27] cache_reap+0x0/0x117 Jan 12 10:57:23 wszip-kinigka kernel: [c0434508] worker_thread+0xd9/0x10d Jan 12 10:57:23 wszip-kinigka kernel: [c041fdbd] default_wake_function+0x0/0xc Jan 12 10:57:23 wszip-kinigka kernel: [c043442f] worker_thread+0x0/0x10d Jan 12 10:57:23 wszip-kinigka kernel: [c04369db] kthread+0xc0/0xed Jan 12 10:57:23 wszip-kinigka kernel: [c043691b] kthread+0x0/0xed Jan 12 10:57:23 wszip-kinigka kernel: [c0404dab] kernel_thread_helper+0x7/0x10 Jan 12 10:57:23 wszip-kinigka kernel: === -- Karl Kiniger mailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.30 Oops when connecting external USB hard drive
On Sat, Apr 16, 2005 at 07:53:05AM +0200, Willy Tarreau wrote: > On Fri, Apr 15, 2005 at 02:50:48PM +0200, Karl Kiniger wrote: > > On Thu, Apr 14, 2005 at 07:02:44AM +0200, Willy Tarreau wrote: > > > You may try to unload the ehci-hcd driver and load only uhci and check if > > > it still happens. I guess from the trace that the problem lies in the ehci > > > driver itself. > > > > Your guess is right. With only uhci loaded it works (dog slow of course). > > When I then insmod the ehci-hcd driver: instant Oops. > > > > Today I tried with another USB 2.0 enclosure w/o crash - it seems > > to dislike especially the Seagate enclosure. > > Fine, it may not be an important bug. To you :) - it is annoying for me. > > > perhaps the output of cat /proc/bus/usb/devices gives some hint? > > (BTW: what does the asterisk in the 'C:' lines mean?) > > I don't remember at all... > > > On the two "GE Med. Kretz" USB<>IDE devices there is > > a DVD recorder and a Maxtor HD connected, both are working fine > > as long as nobody tries to plug in this particular Seagate. > > > > What to do next? I have no clue about the innards of ehci-hcd > > You should CC the ehci-hcd the usb-storage maintainers, they probably tks for advice. > will have more clues or ideas about what you encounter. A post to the > linux-usb-users list would be a good idea too. Also, if you can test > 2.6 and find that it is broken only on 2.4, it will be easier for them > to send you some code to try. I will try to boot something like knoppix or RIP with a 2.6 kernel and see what happens. Thanks anyways, Karl > > Regards, > Willy -- Karl Kiniger mailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH & Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.30 Oops when connecting external USB hard drive
On Sat, Apr 16, 2005 at 07:53:05AM +0200, Willy Tarreau wrote: On Fri, Apr 15, 2005 at 02:50:48PM +0200, Karl Kiniger wrote: On Thu, Apr 14, 2005 at 07:02:44AM +0200, Willy Tarreau wrote: You may try to unload the ehci-hcd driver and load only uhci and check if it still happens. I guess from the trace that the problem lies in the ehci driver itself. Your guess is right. With only uhci loaded it works (dog slow of course). When I then insmod the ehci-hcd driver: instant Oops. Today I tried with another USB 2.0 enclosure w/o crash - it seems to dislike especially the Seagate enclosure. Fine, it may not be an important bug. To you :) - it is annoying for me. perhaps the output of cat /proc/bus/usb/devices gives some hint? (BTW: what does the asterisk in the 'C:' lines mean?) I don't remember at all... On the two GE Med. Kretz USBIDE devices there is a DVD recorder and a Maxtor HD connected, both are working fine as long as nobody tries to plug in this particular Seagate. What to do next? I have no clue about the innards of ehci-hcd You should CC the ehci-hcd the usb-storage maintainers, they probably tks for advice. will have more clues or ideas about what you encounter. A post to the linux-usb-users list would be a good idea too. Also, if you can test 2.6 and find that it is broken only on 2.4, it will be easier for them to send you some code to try. I will try to boot something like knoppix or RIP with a 2.6 kernel and see what happens. Thanks anyways, Karl Regards, Willy -- Karl Kiniger mailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.30 Oops when connecting external USB hard drive
On Thu, Apr 14, 2005 at 07:02:44AM +0200, Willy Tarreau wrote: > You may try to unload the ehci-hcd driver and load only uhci and check if > it still happens. I guess from the trace that the problem lies in the ehci > driver itself. Your guess is right. With only uhci loaded it works (dog slow of course). When I then insmod the ehci-hcd driver: instant Oops. Today I tried with another USB 2.0 enclosure w/o crash - it seems to dislike especially the Seagate enclosure. perhaps the output of cat /proc/bus/usb/devices gives some hint? (BTW: what does the asterisk in the 'C:' lines mean?) On the two "GE Med. Kretz" USB<>IDE devices there is a DVD recorder and a Maxtor HD connected, both are working fine as long as nobody tries to plug in this particular Seagate. What to do next? I have no clue about the innards of ehci-hcd Regards and thanks for trying to help, Karl T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d000 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0bc2 ProdID=0500 Rev= 0.00 S: Manufacturer=Seagate S: Product=Seagate Mass Storage S: SerialNumber=3JS461VN C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 11/900 us ( 1%), #Int= 1, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d400 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04b4 ProdID=6560 Rev= 0.08 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04ce ProdID=0002 Rev= 0.01 S: Manufacturer=GE Med. Kretz S: Product=USB to IDE S: SerialNumber=DEF107F12FAB C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms T: Bus=02 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04ce ProdID=0002 Rev= 0.01 S: Manufacturer=GE Med. Kretz S: Product=USB to IDE S: SerialNumber=DEF107F12FC6 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > Regards, > willy > > On Tue, Apr 12, 2005 at 07:39:11PM +0200, Kiniger wrote: > > Pls see the hand-copied decoded backtrace. [ deleted ] -- Karl Kiniger mailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH & Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.30 Oops when connecting external USB hard drive
On Thu, Apr 14, 2005 at 07:02:44AM +0200, Willy Tarreau wrote: You may try to unload the ehci-hcd driver and load only uhci and check if it still happens. I guess from the trace that the problem lies in the ehci driver itself. Your guess is right. With only uhci loaded it works (dog slow of course). When I then insmod the ehci-hcd driver: instant Oops. Today I tried with another USB 2.0 enclosure w/o crash - it seems to dislike especially the Seagate enclosure. perhaps the output of cat /proc/bus/usb/devices gives some hint? (BTW: what does the asterisk in the 'C:' lines mean?) On the two GE Med. Kretz USBIDE devices there is a DVD recorder and a Maxtor HD connected, both are working fine as long as nobody tries to plug in this particular Seagate. What to do next? I have no clue about the innards of ehci-hcd Regards and thanks for trying to help, Karl T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d000 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0bc2 ProdID=0500 Rev= 0.00 S: Manufacturer=Seagate S: Product=Seagate Mass Storage S: SerialNumber=3JS461VN C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 11/900 us ( 1%), #Int= 1, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d400 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04b4 ProdID=6560 Rev= 0.08 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04ce ProdID=0002 Rev= 0.01 S: Manufacturer=GE Med. Kretz S: Product=USB to IDE S: SerialNumber=DEF107F12FAB C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms T: Bus=02 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04ce ProdID=0002 Rev= 0.01 S: Manufacturer=GE Med. Kretz S: Product=USB to IDE S: SerialNumber=DEF107F12FC6 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms Regards, willy On Tue, Apr 12, 2005 at 07:39:11PM +0200, Kiniger wrote: Pls see the hand-copied decoded backtrace. [ deleted ] -- Karl Kiniger mailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
