Most recent kernel where this bug did not occur: 2.6.8 (don't know if most recent)
Distribution: Debian GNU/Linux
Hardware Environment: Acer TravelMate 2410
Problem Description: PenDrive is detected and initialized as an scsi device
/dev/sda1, but is not mounted due to i/o error. This didn't happen on Mandrake
10.1 linux with 2.6.8 kernel. On Debian I use udev and hal, on Mandrake hotplug
devices were managed by hotplug, but when I submited this bug to udev mailing
list they claimed that it is a kernel or pendrive problem. Pendrive worked well
under mandrake and it does so under windows.
Created attachment 7588 [details]
Created attachment 7589 [details]
Judging from the logical block numbers in the error messages, it looks like the
partition table on the pendrive may be messed up. What do you get from "fdisk
"fdisk -l /dev/sda" lists a FAT partition on the pendrive
But what are the sector numbers for the start and end of the the sda1 partition?
And if they are okay, the next question is whether the filesystem itself has
been corrupted. Have you tried running dosfsck on /dev/sda1?
The point here is that your mount command failed because some software component
was trying to read block 508378384, but the pendrive only contains 251904
blocks! No wonder you got an error.
Created attachment 7628 [details]
output of "fdisk -l /dev/sda"
this is the output of fdisk command. I'll send the dosfsck output in a while
Created attachment 7733 [details]
"dosfsck /dev/sda1" output
This is the output of "dosfsck /dev/sda1" (at last;P). It is quite strange I
think... More strange is the fact that I've checked the same pendrive on other
computer with linux kernel 2.6.15-1 (2.6.15-1.1833_FC4 on Fedora Core 4) and it
worked... Couldn't it be some problem with other software, eg. udev? Or maby
with hardware? I also tried the original linux kernel 2.6.16-git8 and the
pendrive worked, but it was on the second computer (on Fedora, not Debian
system). I will try the newest kernel on the Debian system and send the
results. I don't know if Debian team changes something in the kernel, but if
they do - could it be the source of the problem?
Here's something that might help. Try doing this on each of the computers (or
under each of the kernels):
dd if=/dev/sda1 bs=512 count=1 | hexdump -C
Be careful to keep track of which computer and which kernel produced which
output. Normally one would expect the all outputs to be the same, but I bet
they won't be.
Created attachment 7772 [details]
output of "dd if=/dev/sda1..." on FC4 (kernel: 2.6.15-1.1833_FC4)
this is the output of "dd if=/dev/sda1 bs=512 count=1 | hexdump -C" on computer
with Fedora Core 4 with 2.6.15-1.1833_FC4 kernel
Created attachment 7773 [details]
output of "dd if=/dev/sda1..." on FC4 (kernel: 184.108.40.206)
And here is the ouput of the same command. The same computer, Fedora Core 4,
linux kernel 220.127.116.11 (I've installed this kernel over 2.6.16-git8, and the
pendrive also worked well). Both outputs are the same (I used diff to check
it). In few days Ill send the output from Debian installed on laptop.
Created attachment 7900 [details]
output of "dd if=/dev/sda1..." on Debian (kernel: 2.6.15-1-686-debian)
The output of dd command. Debian system on the laptop, kernel 2.6.15-1-686
compiled by Debian team
Created attachment 7901 [details]
output of "dd if=/dev/sda1..." on Debian (kernel: 2.6.16)
output from Debian on the laptop, kernel 2.6.16 from kernel.org
Created attachment 7902 [details]
output of "dd if=/dev/sda1..." on Debian (kernel: 2.6.17-rc1)
and finally from Debian on the laptop, with kernel 2.6.17-rc1 from kernel.org.
They are identical (I've checked with diff).
As one can see they are different from those from FC4 on the other machine.
It's obvious that the FC4 tests are doing what they are supposed to (reading the
first sector of /dev/sda1) whereas the tests on the laptop are actually reading
the first sector of /dev/sda instead of /dev/sda1. That's why the errors occur.
At this point it's hard to tell if the difference is due to the system, the
kernel version, or the hardware. The first thing to do is "ls -l /dev/sda*" on
both machines. In particular, check to see that the major and minor numbers for
/dev/sda and /dev/sda1 aren't identical.
Can you copy the 2.6.17-rc1 kernel from the laptop to the other computer and run
the test under it? If you do, is the output the same as from the FC4 kernels on
that computer or is it the same as on the laptop?
Also try this: Monitor the output from usbmon while running the "dd..." test.
usbmon is described in Documentation/usb/usbmon.txt in the kernel source. You
will probably have to rebuild the 2.6.17-rc1 kernel with CONFIG_USB_MON and
CONFIG_DEBUG_FS set. Do this on both machines and attach the results here.
Created attachment 8069 [details]
output of "ls /dev/sda*" on laptop, debian with kernel-2.6.15-1-686 (debian)
Created attachment 8070 [details]
output of "ls /dev/sda*" on laptop, debian with kernel-2.6.17-rc1 (kernel.org)
Created attachment 8071 [details]
output of usbmon on laptop while dd command (debian with linux-2.6.17-rc1)
Created attachment 8072 [details]
output of usbmon on laptop while pendrive attatch (debian with linux-2.6.17-rc1)
Created attachment 8073 [details]
output of usbmon on laptop while pendrive detatch (debian with linux-2.6.17-rc1)
On each of your two systems, what's in the file /sys/block/sda/sda1/start ?
Probably on the laptop it says 0 and on the other system it says something like
512. If so, that's the root of the problem -- but we still don't know what's
Created attachment 8108 [details]
output of "ls /dev/sda*" on computer, FC4 with2.6.15-1.1833_FC4 kernel
Created attachment 8109 [details]
output of usbmon on computer while dd (2.6.15-1.1833_FC4)
Created attachment 8110 [details]
output of usbmon on computer while attatch (2.6.15-1.1833_FC4)
Created attachment 8111 [details]
output of usbmon on computer while detatch (2.6.15-1.1833_FC4)
The above are the outputs of ls and usbmon on FC4 (on the desktop computer) with it's own 2.6.15-1.
1833_FC4 kernel. The content of /sys/block/sda/sda1/start on the system is 32.
In a while I will send the output of the commands made on FC4 with the kernel copied from the laptop.
In few days I will send the content of the /sys/block/sda/sda1/start from the laptop.
Bad news... The kernel copied from laptop wouldn't run on the computer. Maby it's because the kernel
is compiled for intel processor and on the computer there is an AMD64? Anyway I will send the /sys/
block/sda/sda1/start from the laptop in few days
Created attachment 8152 [details]
/sys/block/sda/sda1/start from laptop with Debian
Well, that's strange. The file contains "60 480 0 0" but it should contain
"32", just like on the other computer. I suspect that this was caused by a
Debian modification to the kernel.
Is it possible for you to install a vanilla kernel (or even a Fedora kernel) on
the laptop? Or even just boot it from a live CD with a recent non-Debian
kernel. If the PenDrive works then this is definitely a Debian problem and you
should speak to them. If it doesn't work, then let us know which kernel you
tried and show the contents of /sys/block/sda/sda1/start.
Wait a minute! It looks like you posted the contents of
/sys/block/sda/sda1/stat, not /sys/block/sda/sda1/start. Try doing it again.
(By the way, you don't need to create a separate attachment for a 1-line file.
Just include it in with your comments.)
It was the correct file (/sys/block/sda/sda1/start), but after formatting the
pendrive (under windows) the content of the file changed to 0.
The Fedora kernel is 64bit and the laptop has 32bit processor, so it won't run.
But I'm downloading some non-debian Live-CD distribution of linux so I will try
it on the laptop. I have also Installed recently a Debian on the computer, so I
will also try the pendrive on that system.
In my first comment I wrote that the pendrive worked on laptop but under
My mistake... "60 480 0 0" was from stat, not from start even before formatting
the pendrive... Any way i have connected the pendrive to the computer with the
same debian installed and the situation was the same as in the case of laptop.
So I am now sure that is Debian's fault. I'm also sure that when I run a
non-debian LiveCD on the laptop the pendrive will work.
I've run a non-debian Linux distribution on the laptop and the pendrive worked
well. The distribution was Pingwinek GNU/Linux 1.0 preview 3. I've also tried
DSL Linux 3.0 RC 1, which is, as far as I know, Knoppix based, and the
pendrive did not work.
Then you should mark this bug as REJECTED and file a bug report with the Debian
maintainers. Let them know about this report though, so they can read through
it and benefit from what we've learned.