This issue started to appear in around the 2.6.11-mm series.. it
continues even now with 2.6.12-rc2-mm3.
Attempting to copy an image to a device with a tool like dd, results
in the device node being overwritten with the data, but the data is
never sent to the destination drive for instance.
To try to put it more plainly, I have a firmware image I am copying to
an ipod. Normally the image sends with no issues and the ipod has the
new firmware.
With the recent mm's it treats the device node as a file and ls -l
will show the size of the image as the size of the device node.
Even things like fdisk are useless. I am not sure whether this is
some sort of a udev crash or a problem with usb-storage. Nevertheless
it is a problem, and it continues to happen.
The last non-affected mm i can think of is 2.6.11-rc4-mm1.. though I'm
fairly sure rc5 is good too.
Thanks,
Joe
Joe <[email protected]> wrote:
>
> This issue started to appear in around the 2.6.11-mm series.. it
> continues even now with 2.6.12-rc2-mm3.
>
> Attempting to copy an image to a device with a tool like dd, results
> in the device node being overwritten with the data, but the data is
> never sent to the destination drive for instance.
>
> To try to put it more plainly, I have a firmware image I am copying to
> an ipod. Normally the image sends with no issues and the ipod has the
> new firmware.
>
> With the recent mm's it treats the device node as a file and ls -l
> will show the size of the image as the size of the device node.
>
> Even things like fdisk are useless. I am not sure whether this is
> some sort of a udev crash or a problem with usb-storage. Nevertheless
> it is a problem, and it continues to happen.
>
> The last non-affected mm i can think of is 2.6.11-rc4-mm1.. though I'm
> fairly sure rc5 is good too.
Greg stuff.
Is the device node in /dev actually a block-special device, or is is coming
up as a regular file or something?
We might have fixed this. Please retest next -mm, which right now is
looking to be ~30 hours away.
Ok, I will test when its out.
>Is the device node in /dev actually a block-special device, or is is coming
>up as a regular file or something?
It appears as a special block device before an image is sent. After
that it appears as a regular file.
On Wed, Apr 27, 2005 at 07:52:39PM -0400, Joe wrote:
> This issue started to appear in around the 2.6.11-mm series.. it
> continues even now with 2.6.12-rc2-mm3.
>
> Attempting to copy an image to a device with a tool like dd, results
> in the device node being overwritten with the data, but the data is
> never sent to the destination drive for instance.
>
> To try to put it more plainly, I have a firmware image I am copying to
> an ipod. Normally the image sends with no issues and the ipod has the
> new firmware.
Is the device "disappearing" and then the udev deletes the device node,
and then dd starts dumping data to a file instead?
Anything in your kernel log when this happens?
Does this happen with 2.6.12-rc3?
thanks,
greg k-h
On 4/28/05, Greg KH <[email protected]> wrote:
> Is the device "disappearing" and then the udev deletes the device node,
> and then dd starts dumping data to a file instead?
>
> Anything in your kernel log when this happens?
>
> Does this happen with 2.6.12-rc3?
>
> thanks,
>
> greg k-h
>
I've checked the kernel logs and was unable to find anything
suspicious. This does not seem to happen on vanilla, its a mm only
issue.
The device becomes a regular file, and udev seems to forget about it..
even if I replug in the device, udev will not touch this file. It
also seems to have trouble recreating the node even when the file has
been deleted
Hope that helps,
Joe
On Thu, Apr 28, 2005 at 12:57:46AM -0400, Joe wrote:
> On 4/28/05, Greg KH <[email protected]> wrote:
> > Is the device "disappearing" and then the udev deletes the device node,
> > and then dd starts dumping data to a file instead?
> >
> > Anything in your kernel log when this happens?
> >
> > Does this happen with 2.6.12-rc3?
> >
> > thanks,
> >
> > greg k-h
> >
>
> I've checked the kernel logs and was unable to find anything
> suspicious. This does not seem to happen on vanilla, its a mm only
> issue.
>
> The device becomes a regular file, and udev seems to forget about it..
That implies that udev got a hotplug event that told it to delete the
node.
Any kernel log entries? Is the device in usb or firewire mode?
> even if I replug in the device, udev will not touch this file.
That's because the file is not a node, and udev will not overwrite that.
> It also seems to have trouble recreating the node even when the file
> has been deleted
"trouble" how?
thanks,
greg k-h
On 4/28/05, Greg KH <[email protected]> wrote:
> On Thu, Apr 28, 2005 at 12:57:46AM -0400, Joe wrote:
> > It also seems to have trouble recreating the node even when the file
> > has been deleted
>
> "trouble" how?
>
Apparantly the other partitions of the device (ex. sdb1, sdb3) are
still considered nodes. udev also seems to ignore them and hotplug
does not remove these nodes when the device is unplugged.
Additionally, when plugged back in, the device won't recreate the
nodes unless ALL of them are deleted, and even then its a hit and miss
as to whether it will decide to create them.
On Thu, Apr 28, 2005 at 01:20:32AM -0400, Joe wrote:
> On 4/28/05, Greg KH <[email protected]> wrote:
> > On Thu, Apr 28, 2005 at 12:57:46AM -0400, Joe wrote:
> > > It also seems to have trouble recreating the node even when the file
> > > has been deleted
> >
> > "trouble" how?
> >
>
> Apparantly the other partitions of the device (ex. sdb1, sdb3) are
> still considered nodes. udev also seems to ignore them and hotplug
> does not remove these nodes when the device is unplugged.
>
> Additionally, when plugged back in, the device won't recreate the
> nodes unless ALL of them are deleted, and even then its a hit and miss
> as to whether it will decide to create them.
Again, usb or firewire?
And if usb, are you _sure_ there are no kernel log messages? There
should be something there...
Otherwise I have no idea what is happening, and don't know how to find
out either :(
thanks,
greg k-h
On 4/28/05, Greg KH <[email protected]> wrote:
> Again, usb or firewire?
> And if usb, are you _sure_ there are no kernel log messages? There
> should be something there...
Ok here we go. This is what dmesg outputs during the time I copy it over.
scsi5 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 6
usb-storage: waiting for device to settle before scanning
ACPI: No ACPI bus support for 1-4:1.0
Vendor: Apple Model: iPod Rev: 1.62
Type: Direct-Access ANSI SCSI revision: 00
SCSI device sdb: 39063023 512-byte hdwr sectors (20000 MB)
sdb: Write Protect is off
sdb: Mode Sense: 64 00 00 08
sdb: assuming drive cache: write through
SCSI device sdb: 39063023 512-byte hdwr sectors (20000 MB)
sdb: Write Protect is off
sdb: Mode Sense: 64 00 00 08
sdb: assuming drive cache: write through
sdb: sdb2 sdb3
Attached scsi removable disk sdb at scsi5, channel 0, id 0, lun 0
ACPI: No ACPI bus support for 5:0:0:0
Attached scsi generic sg1 at scsi5, channel 0, id 0, lun 0, type 0
usb-storage: device scan complete
I find it odd sdb1 disappears (as this was where I was attempting to
copy the image during this time)
Also from /var/log/messages:
Apr 28 01:26:20 redefine usb 1-4: new high speed USB device using
ehci_hcd and address 6
Apr 28 01:26:20 redefine ACPI: No ACPI bus support for 1-4
Apr 28 01:26:20 redefine scsi5 : SCSI emulation for USB Mass Storage devices
Apr 28 01:26:20 redefine usb-storage: device found at 6
Apr 28 01:26:20 redefine usb-storage: waiting for device to settle
before scanning
Apr 28 01:26:20 redefine ACPI: No ACPI bus support for 1-4:1.0
Apr 28 01:26:25 redefine Vendor: Apple Model: iPod Rev: 1.62
Apr 28 01:26:25 redefine Type: Direct-Access
ANSI SCSI revision: 00
Apr 28 01:26:25 redefine SCSI device sdb: 39063023 512-byte hdwr
sectors (20000 MB)
Apr 28 01:26:25 redefine sdb: Write Protect is off
Apr 28 01:26:25 redefine sdb: Mode Sense: 64 00 00 08
Apr 28 01:26:25 redefine sdb: assuming drive cache: write through
Apr 28 01:26:25 redefine SCSI device sdb: 39063023 512-byte hdwr
sectors (20000 MB)
Apr 28 01:26:25 redefine sdb: Write Protect is off
Apr 28 01:26:25 redefine sdb: Mode Sense: 64 00 00 08
Apr 28 01:26:25 redefine sdb: assuming drive cache: write through
Apr 28 01:26:25 redefine sdb: sdb2 sdb3
Apr 28 01:26:25 redefine Attached scsi removable disk sdb at scsi5,
channel 0, id 0, lun 0
Apr 28 01:26:25 redefine ACPI: No ACPI bus support for 5:0:0:0
Apr 28 01:26:25 redefine Attached scsi generic sg1 at scsi5, channel
0, id 0, lun 0, type 0
Apr 28 01:26:25 redefine usb-storage: device scan complete
Apr 28 01:26:25 redefine scsi.agent[17573]: disk at
/devices/pci0000:00/0000:00:1e.0/0000:02:09.2/usb1/1-4/1-4:1.0/host5/target5:0:0/5:0:0:0
Hope This Can Help,
Joe
On Thu, Apr 28, 2005 at 01:32:56AM -0400, Joe wrote:
> On 4/28/05, Greg KH <[email protected]> wrote:
> > Again, usb or firewire?
> > And if usb, are you _sure_ there are no kernel log messages? There
> > should be something there...
>
> Ok here we go. This is what dmesg outputs during the time I copy it over.
>
> scsi5 : SCSI emulation for USB Mass Storage devices
> usb-storage: device found at 6
> usb-storage: waiting for device to settle before scanning
> ACPI: No ACPI bus support for 1-4:1.0
> Vendor: Apple Model: iPod Rev: 1.62
> Type: Direct-Access ANSI SCSI revision: 00
> SCSI device sdb: 39063023 512-byte hdwr sectors (20000 MB)
> sdb: Write Protect is off
> sdb: Mode Sense: 64 00 00 08
> sdb: assuming drive cache: write through
> SCSI device sdb: 39063023 512-byte hdwr sectors (20000 MB)
> sdb: Write Protect is off
> sdb: Mode Sense: 64 00 00 08
> sdb: assuming drive cache: write through
> sdb: sdb2 sdb3
> Attached scsi removable disk sdb at scsi5, channel 0, id 0, lun 0
> ACPI: No ACPI bus support for 5:0:0:0
> Attached scsi generic sg1 at scsi5, channel 0, id 0, lun 0, type 0
> usb-storage: device scan complete
>
> I find it odd sdb1 disappears (as this was where I was attempting to
> copy the image during this time)
I don't see a "sdb1" partition in the message from the scsi core. Does
ls /sys/block/sdb
show a sdb1 partition?
If not, nothing that udev can do, must be a scsi issue :)
> Also from /var/log/messages:
>
> Apr 28 01:26:20 redefine usb 1-4: new high speed USB device using
> ehci_hcd and address 6
> Apr 28 01:26:20 redefine ACPI: No ACPI bus support for 1-4
> Apr 28 01:26:20 redefine scsi5 : SCSI emulation for USB Mass Storage devices
> Apr 28 01:26:20 redefine usb-storage: device found at 6
> Apr 28 01:26:20 redefine usb-storage: waiting for device to settle
> before scanning
> Apr 28 01:26:20 redefine ACPI: No ACPI bus support for 1-4:1.0
> Apr 28 01:26:25 redefine Vendor: Apple Model: iPod Rev: 1.62
> Apr 28 01:26:25 redefine Type: Direct-Access
> ANSI SCSI revision: 00
> Apr 28 01:26:25 redefine SCSI device sdb: 39063023 512-byte hdwr
> sectors (20000 MB)
> Apr 28 01:26:25 redefine sdb: Write Protect is off
> Apr 28 01:26:25 redefine sdb: Mode Sense: 64 00 00 08
> Apr 28 01:26:25 redefine sdb: assuming drive cache: write through
> Apr 28 01:26:25 redefine SCSI device sdb: 39063023 512-byte hdwr
> sectors (20000 MB)
> Apr 28 01:26:25 redefine sdb: Write Protect is off
> Apr 28 01:26:25 redefine sdb: Mode Sense: 64 00 00 08
> Apr 28 01:26:25 redefine sdb: assuming drive cache: write through
> Apr 28 01:26:25 redefine sdb: sdb2 sdb3
Again, no sdb1.
thanks,
greg k-h
On Thursday 28 April 2005 03:15, Joe wrote:
> Ok, I will test when its out.
>
> >Is the device node in /dev actually a block-special device, or is is coming
> >up as a regular file or something?
>
> It appears as a special block device before an image is sent. After
> that it appears as a regular file.
What does this mean, "image is sent"? Can you be more specific, like
"I do this: 'cp my_file /dev/sdb1'"
Also, watch logs closely, both syslog (where hotplug and udev are sending
their messages (btw hotplug is shell scripts, you may add debug messages
into them if you need to)), and kernel log.
You can also 'strace -p <pid of udevd>' and strace your cp or whatever
you use to copy image to device.
--
vda
Interesting.. this appears to be a completley different issue also
now. sdb1 is a free space partition (type 0 in fdisk). Well
apparently that doesn't appear with the new mm's and this is the
source of all my problems.
So I was mistaken about it being overwritten I think... this is a
little more different then I thought.
I use dd if=my_sw.bin of=/dev/sdb1 to copy the image over.. but as the
sdb1 node isn't being created.. its just sending it to a file. I'll
continue to look more at it now.
Thanks,
Joe