On Tue, 31 Jul 2007, Kostas Peletidis wrote:
Branden Sletteland wrote:
I have also noticed this delay and have through instrumenting code
have found that every block in the device gets read in. I never
checked if it was something in the df, filesystem, SCSI, or USB
subsystems that was
On Tue, Jul 31, 2007 at 11:08:37PM +0100, Kostas Peletidis wrote:
Branden Sletteland wrote:
I have also noticed this delay and have through instrumenting code
have found that every block in the device gets read in. I never
checked if it was something in the df, filesystem, SCSI, or USB
On Wed, 1 Aug 2007, Sergey Vlasov wrote:
On Tue, Jul 31, 2007 at 11:08:37PM +0100, Kostas Peletidis wrote:
Branden Sletteland wrote:
I have also noticed this delay and have through instrumenting code
have found that every block in the device gets read in. I never
checked if it was
On Wed, Aug 01, 2007 at 01:14:40PM -0400, Alan Stern wrote:
On Wed, 1 Aug 2007, Sergey Vlasov wrote:
On Tue, Jul 31, 2007 at 11:08:37PM +0100, Kostas Peletidis wrote:
Branden Sletteland wrote:
I have also noticed this delay and have through instrumenting code
have found that every
Sergey Vlasov wrote:
On Tue, Jul 31, 2007 at 11:08:37PM +0100, Kostas Peletidis wrote:
Branden Sletteland wrote:
I have also noticed this delay and have through instrumenting code
have found that every block in the device gets read in. I never
checked if it was something in the df,
On Wed, 1 Aug 2007, Sergey Vlasov wrote:
But reading the whole FAT is very different from reading the entire
partition.
Reading the entire 500GB in one minute? I would really like to have
such disk :)
Most likely every block here really means a large sequential read.
Not sure what
Sergey Vlasov wrote:
On Wed, Aug 01, 2007 at 01:14:40PM -0400, Alan Stern wrote:
On Wed, 1 Aug 2007, Sergey Vlasov wrote:
[...]
Without usefree the vfat code in 2.6.22 will read the whole FAT
to count free clusters on the filesystem.
But reading the whole FAT is very
Matthew Dharm wrote:
Did you change any USB-related compile options between the two builds?
Do you have usb device suspend enabled?
Can you tell (via top) where the 100% CPU usage is coming from (i.e. df,
usb-storage thread, syswait, etc)?
Matt
Hi Matt,
The most relevant USB
It would be interesting to turn on CONFIG_USB_STORAGE_DEBUG and capture the
debugging output.
Matt
On Tue, Jul 31, 2007 at 08:37:31PM +0100, Kostas Peletidis wrote:
Matthew Dharm wrote:
Did you change any USB-related compile options between the two builds?
Do you have usb device suspend
Alan Stern wrote:
On Mon, 30 Jul 2007, Kostas Peletidis wrote:
Hi all,
I would like to report a problem I have noticed since linux-2.6.22 that
most likely has to do with the USB subsystem.
I have tried both kernel versions 2.6.22 and 2.6.22.1(configured with
make oldconfig) and in both
On Tue, 31 Jul 2007, Kostas Peletidis wrote:
Hi Alan,
I enabled CONFIG_USB_DEBUG and reproduced the problem but didn't see any
messages in the dmesg output. To ensure that the debug code was indeed
built in I unplugged the disk then plugged it back in. I got quite a few
messages, here
I have also noticed this delay and have through instrumenting code
have found that every block in the device gets read in. I never
checked if it was something in the df, filesystem, SCSI, or USB
subsystems that was causing this. I am usually doing df on USB
storage devices formated as FAT 32 w/
Matthew Dharm wrote:
It would be interesting to turn on CONFIG_USB_STORAGE_DEBUG and capture the
debugging output.
Matt
On Tue, Jul 31, 2007 at 08:37:31PM +0100, Kostas Peletidis wrote:
Matthew Dharm wrote:
Did you change any USB-related compile options between the two builds?
Do
Branden Sletteland wrote:
I have also noticed this delay and have through instrumenting code
have found that every block in the device gets read in. I never
checked if it was something in the df, filesystem, SCSI, or USB
subsystems that was causing this. I am usually doing df on USB
storage
What the heck happened to your logs? It looks like about 75% of the data
is being lost from the log file...
Matt
On Tue, Jul 31, 2007 at 10:47:40PM +0100, Kostas Peletidis wrote:
Matthew Dharm wrote:
It would be interesting to turn on CONFIG_USB_STORAGE_DEBUG and capture the
debugging
That's how they appeared, messed up. I need to enable usb storage
debugging in my reference kernel(2.6.21.5) and see if the log looks any
better or if my 1GHz VIA Nehemiah is simply not fast enough for
debugging. But now I must switch to sleep mode :-)
--
Kostas
Matthew Dharm wrote:
What
Hi all,
I would like to report a problem I have noticed since linux-2.6.22 that
most likely has to do with the USB subsystem.
I have tried both kernel versions 2.6.22 and 2.6.22.1(configured with
make oldconfig) and in both cases whenever I plug in a fairly
large(500GB) MyBook usb2 hard disk
Did you change any USB-related compile options between the two builds?
Do you have usb device suspend enabled?
Can you tell (via top) where the 100% CPU usage is coming from (i.e. df,
usb-storage thread, syswait, etc)?
Matt
On Mon, Jul 30, 2007 at 11:24:27PM +0100, Kostas Peletidis wrote:
Hi
On Mon, 30 Jul 2007, Kostas Peletidis wrote:
Hi all,
I would like to report a problem I have noticed since linux-2.6.22 that
most likely has to do with the USB subsystem.
I have tried both kernel versions 2.6.22 and 2.6.22.1(configured with
make oldconfig) and in both cases whenever I
19 matches
Mail list logo
