212,213b USB flash names not retained in Pmount, Univ Inst
Hi PaulBx1,
I had a look-see in the kernel source, and couldn't spot a bug, but that code does look a little confusing to me, I can't say that its 100% bug free... however I did spot something that can possibly help you debug the situation further...
From my 'educated guessing' I discover that the USB bus location "usb 1-1.3" broken down means:
'usb 1' = "usb 1.0 or usb 1.1 standard speeds"
'usb x-1.y' = non-root Hub #1
'usb x-1.3' = non-root Hub #1, hub port 3.
Understandably your hub has only 4? ports. so you can only have addresses through it of x-1.1 x-1.2 x-1.3 x-1.4. These are I guess supposed to correlate to the physical ports.
Notice that the unexpected behavior problem only occurs when you re-insert the device.
According to the dmesg, your other disk goes missing at this point, why? because the inserted disk has the same bus location.
Notice that:
Feb 21 12:34:03 (none) user.info kernel: usb 1-1.3: USB disconnect, address 4
Feb 21 12:34:03 (none) user.info kernel: usb 1-1.3: new full speed USB device using uhci_hcd and address 6
"address 4" and "address 6" type addresses appear to be a unique number for usb devices to identify them.
Logically only one device can occupy a hubs port, so goodbye device known as "address 4".
So it looks like one or more of these things might be true:
1) Your hub can change index on each port.
2) Your hub may have a bug, or non-standard behavior.
3) Kernel drivers do not understand how your hub works.
4) Your SanDisk and hub are not 100% incompatible.
Diagnostic steps:
Debug your hub, use only one device in it at a time, plug in, wait 10 secs, check dmesg usb address for usb-port, unplug, wait 10, re-plug, recheck usbport address. Do this for each port on the hub.
If you get confusing results with a usb disk, try a different disk.
If you get an unexpected port change, keep the disk in the hub, but unplug the hub.
You may find that you need to unplug the hub before unpluging a device, to get it the hub to be consistent.
Have you got another hub to try?
Jesse
I had a look-see in the kernel source, and couldn't spot a bug, but that code does look a little confusing to me, I can't say that its 100% bug free... however I did spot something that can possibly help you debug the situation further...
From my 'educated guessing' I discover that the USB bus location "usb 1-1.3" broken down means:
'usb 1' = "usb 1.0 or usb 1.1 standard speeds"
'usb x-1.y' = non-root Hub #1
'usb x-1.3' = non-root Hub #1, hub port 3.
Understandably your hub has only 4? ports. so you can only have addresses through it of x-1.1 x-1.2 x-1.3 x-1.4. These are I guess supposed to correlate to the physical ports.
Notice that the unexpected behavior problem only occurs when you re-insert the device.
According to the dmesg, your other disk goes missing at this point, why? because the inserted disk has the same bus location.
Notice that:
Feb 21 12:34:03 (none) user.info kernel: usb 1-1.3: USB disconnect, address 4
Feb 21 12:34:03 (none) user.info kernel: usb 1-1.3: new full speed USB device using uhci_hcd and address 6
"address 4" and "address 6" type addresses appear to be a unique number for usb devices to identify them.
Logically only one device can occupy a hubs port, so goodbye device known as "address 4".
So it looks like one or more of these things might be true:
1) Your hub can change index on each port.
2) Your hub may have a bug, or non-standard behavior.
3) Kernel drivers do not understand how your hub works.
4) Your SanDisk and hub are not 100% incompatible.
Diagnostic steps:
Debug your hub, use only one device in it at a time, plug in, wait 10 secs, check dmesg usb address for usb-port, unplug, wait 10, re-plug, recheck usbport address. Do this for each port on the hub.
If you get confusing results with a usb disk, try a different disk.
If you get an unexpected port change, keep the disk in the hub, but unplug the hub.
You may find that you need to unplug the hub before unpluging a device, to get it the hub to be consistent.
Have you got another hub to try?
Jesse
Thanks for going so far as to dig into kernel code, Jesse. This will be embarassing if it turns out to be nothing but a bad hub hardware design.
I tried the one-at-a-time test you suggested. The physical port number guess you made turned out to be correct; I have never seen any problem with the reporting of that. On the "address x" thing, though, it turns out a new address is generated any time another device is plugged in, even if it was the same one that just got pulled out. I was up to address 49 in my testing.
Anyway that test was boring; nothing very interesting happened. Here is one example of a plug and unplug, and the beginning of the next plug:
I then plugged the Istick into port 1 and the Sandisk into port 3, as it failed Wednesday (leaving out the Lexar this time). This is what I get (there is no failure):
Like Wednesday, you can see the act of plugging in the Istick caused the Sandisk to become unplugged, even though I hadn't touched the Sandisk. I'm guessing this is a bug in the hub design. Today the kernel still kept working with both the Istick and the Sandisk, however many times I tried it. On Wednesday's log, at Feb 21 12:33:48, you can see it simply stops working with the Istick, doesn't see it at all although I had plugged it in and like today it had triggered a disconnect on port 3.
Since this is kernel stuff there is nothing we can do to fix it. The bug appears to be something in the hub (a CyberPower model CP-H420MO battery-powered hub) or some interaction between it and the kernel. I have no other hub, but I do have a USB2.0 pcmcia card I am going to start using more since it now works with 2.14. On the hub, I will tape a message, "NO HOT-PLUGGING!"
While we can assume that this bug caused my two flash drives to be wiped (who knows the actual mechanism), I'm still left with a queasy feeling. Why? Because pakt had the same experience. I wonder if he's got the same hub?
It looks like Jason's latest probedisk/probepart is good, although more folks ought to test it, and with more applications. Seems to fix pmount anyway.
Thanks for that tip G2. Now I remember we used to "tail -f" the log(s) and watch things happen as they happened, along with dumping messages into the logs to record steps in our test procedures. Brings back the good old days...
I tried the one-at-a-time test you suggested. The physical port number guess you made turned out to be correct; I have never seen any problem with the reporting of that. On the "address x" thing, though, it turns out a new address is generated any time another device is plugged in, even if it was the same one that just got pulled out. I was up to address 49 in my testing.
Anyway that test was boring; nothing very interesting happened. Here is one example of a plug and unplug, and the beginning of the next plug:
Code: Select all
Feb 23 12:01:07 (none) user.notice root: ------Using SanDisk in fourth port, multiple plugging/unplugging------
Feb 23 12:01:13 (none) user.info kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 25
Feb 23 12:01:13 (none) user.info kernel: usb 1-1.4: configuration #1 chosen from 1 choice
Feb 23 12:01:13 (none) user.info kernel: scsi22 : SCSI emulation for USB Mass Storage devices
Feb 23 12:01:13 (none) user.debug kernel: usb-storage: device found at 25
Feb 23 12:01:13 (none) user.debug kernel: usb-storage: waiting for device to settle before scanning
Feb 23 12:01:18 (none) user.notice kernel: Vendor: SanDisk Model: Cruzer Micro Rev: 0.2
Feb 23 12:01:18 (none) user.notice kernel: Type: Direct-Access ANSI SCSI revision: 02
Feb 23 12:01:18 (none) user.notice kernel: SCSI device sda: 501759 512-byte hdwr sectors (257 MB)
Feb 23 12:01:18 (none) user.notice kernel: sda: Write Protect is off
Feb 23 12:01:18 (none) user.debug kernel: sda: Mode Sense: 03 00 00 00
Feb 23 12:01:18 (none) user.err kernel: sda: assuming drive cache: write through
Feb 23 12:01:18 (none) user.notice kernel: SCSI device sda: 501759 512-byte hdwr sectors (257 MB)
Feb 23 12:01:18 (none) user.notice kernel: sda: Write Protect is off
Feb 23 12:01:18 (none) user.debug kernel: sda: Mode Sense: 03 00 00 00
Feb 23 12:01:18 (none) user.err kernel: sda: assuming drive cache: write through
Feb 23 12:01:18 (none) user.info kernel: sda1
Feb 23 12:01:18 (none) user.notice kernel: sd 22:0:0:0: Attached scsi removable disk sda
Feb 23 12:01:18 (none) user.debug kernel: usb-storage: device scan complete
Feb 23 12:01:22 (none) user.info kernel: usb 1-1.4: USB disconnect, address 25
Feb 23 12:01:32 (none) user.info kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 26
Code: Select all
Feb 23 12:23:25 (none) user.notice root: ------OK, plugging and unplugging sda again------
Feb 23 12:23:28 (none) user.info kernel: usb 1-1.1: USB disconnect, address 46
Feb 23 12:23:37 (none) user.info kernel: usb 1-1.1: new full speed USB device using uhci_hcd and address 48
Feb 23 12:23:37 (none) user.info kernel: usb 1-1.1: configuration #1 chosen from 1 choice
Feb 23 12:23:37 (none) user.info kernel: scsi45 : SCSI emulation for USB Mass Storage devices
Feb 23 12:23:37 (none) user.debug kernel: usb-storage: device found at 48
Feb 23 12:23:37 (none) user.debug kernel: usb-storage: waiting for device to settle before scanning
Feb 23 12:23:37 (none) user.info kernel: usb 1-1.3: USB disconnect, address 47
Feb 23 12:23:37 (none) user.info kernel: usb 1-1.3: new full speed USB device using uhci_hcd and address 49
Feb 23 12:23:37 (none) user.info kernel: usb 1-1.3: configuration #1 chosen from 1 choice
Feb 23 12:23:37 (none) user.info kernel: scsi46 : SCSI emulation for USB Mass Storage devices
Feb 23 12:23:37 (none) user.debug kernel: usb-storage: device found at 49
Feb 23 12:23:37 (none) user.debug kernel: usb-storage: waiting for device to settle before scanning
Feb 23 12:23:42 (none) user.notice kernel: Vendor: I-Stick2 Model: IntelligentStick Rev: 0.00
Feb 23 12:23:42 (none) user.notice kernel: Type: Direct-Access ANSI SCSI revision: 02
Feb 23 12:23:42 (none) user.notice kernel: SCSI device sda: 2007040 512-byte hdwr sectors (1028 MB)
Feb 23 12:23:42 (none) user.notice kernel: sda: Write Protect is off
Feb 23 12:23:42 (none) user.debug kernel: sda: Mode Sense: 00 00 00 00
Feb 23 12:23:42 (none) user.err kernel: sda: assuming drive cache: write through
Feb 23 12:23:42 (none) user.notice kernel: SCSI device sda: 2007040 512-byte hdwr sectors (1028 MB)
Feb 23 12:23:42 (none) user.notice kernel: sda: Write Protect is off
Feb 23 12:23:42 (none) user.debug kernel: sda: Mode Sense: 00 00 00 00
Feb 23 12:23:42 (none) user.err kernel: sda: assuming drive cache: write through
Feb 23 12:23:42 (none) user.info kernel: sda1
Feb 23 12:23:42 (none) user.notice kernel: sd 45:0:0:0: Attached scsi removable disk sda
Feb 23 12:23:42 (none) user.debug kernel: usb-storage: device scan complete
Feb 23 12:23:42 (none) user.notice kernel: Vendor: SanDisk Model: Cruzer Micro Rev: 0.2
Feb 23 12:23:42 (none) user.notice kernel: Type: Direct-Access ANSI SCSI revision: 02
Feb 23 12:23:42 (none) user.notice kernel: SCSI device sdb: 501759 512-byte hdwr sectors (257 MB)
Feb 23 12:23:42 (none) user.notice kernel: sdb: Write Protect is off
Feb 23 12:23:42 (none) user.debug kernel: sdb: Mode Sense: 03 00 00 00
Feb 23 12:23:42 (none) user.err kernel: sdb: assuming drive cache: write through
Feb 23 12:23:42 (none) user.notice kernel: SCSI device sdb: 501759 512-byte hdwr sectors (257 MB)
Feb 23 12:23:42 (none) user.notice kernel: sdb: Write Protect is off
Feb 23 12:23:42 (none) user.debug kernel: sdb: Mode Sense: 03 00 00 00
Feb 23 12:23:42 (none) user.err kernel: sdb: assuming drive cache: write through
Feb 23 12:23:42 (none) user.info kernel: sdb1
Feb 23 12:23:42 (none) user.notice kernel: sd 46:0:0:0: Attached scsi removable disk sdb
Feb 23 12:23:42 (none) user.debug kernel: usb-storage: device scan complete
Since this is kernel stuff there is nothing we can do to fix it. The bug appears to be something in the hub (a CyberPower model CP-H420MO battery-powered hub) or some interaction between it and the kernel. I have no other hub, but I do have a USB2.0 pcmcia card I am going to start using more since it now works with 2.14. On the hub, I will tape a message, "NO HOT-PLUGGING!"
While we can assume that this bug caused my two flash drives to be wiped (who knows the actual mechanism), I'm still left with a queasy feeling. Why? Because pakt had the same experience. I wonder if he's got the same hub?
It looks like Jason's latest probedisk/probepart is good, although more folks ought to test it, and with more applications. Seems to fix pmount anyway.
Thanks for that tip G2. Now I remember we used to "tail -f" the log(s) and watch things happen as they happened, along with dumping messages into the logs to record steps in our test procedures. Brings back the good old days...
The original problem with probedisk/probepart was that they were not written with hot-pluggable USB devices in mind. It was a USB problem. I think Jason has fixed that now with his latest version, which probably ought to be propagated back into standard puppy if they've been tested for a while (as they are used in several programs).
I don't know what test-scsi is, does that have anything to do with USB? When I try invoking it, nothing happens.
I don't know what test-scsi is, does that have anything to do with USB? When I try invoking it, nothing happens.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
I just tested Jason's probedisk and probepart -- excellent work!
On my laptop probepart printed an inappropriate error message and one line was scrambled. This is because it does not handle extended partitions correctly. I have hda4 extended partition with hda5, hda6 and hda7 logical partitions in it. I fixed that, and took the liberty of making a few changes in a few other places -- for example, it didn't handle the '-k' parameter. It's attached, try it and see if it works okay for you.
Jason, one small point, I don't know if you considered it or if it was mentioned earlier in this thread, but 'fdisk -l' gives much of the info needed about the partitions.
On my laptop probepart printed an inappropriate error message and one line was scrambled. This is because it does not handle extended partitions correctly. I have hda4 extended partition with hda5, hda6 and hda7 logical partitions in it. I fixed that, and took the liberty of making a few changes in a few other places -- for example, it didn't handle the '-k' parameter. It's attached, try it and see if it works okay for you.
Jason, one small point, I don't know if you considered it or if it was mentioned earlier in this thread, but 'fdisk -l' gives much of the info needed about the partitions.
- Attachments
-
- probepart.gz
- (1.02 KiB) Downloaded 423 times
Hmmm, comparing the probepart I am using (no longer sure if it is the original or plinej's) with this new one which is in /tmp:
However that probepartm file had this:
Code: Select all
sh-3.00# probepart
/dev/hda1|vfat|39053952
/dev/hdc|iso9660|0
sh-3.00# /tmp/probepart
/tmp/probepart: line 1: /dev/hda1: Permission denied
/tmp/probepart: line 1: vfat: command not found
/tmp/probepart: line 1: 39053952: command not found
/tmp/probepart: line 2: /dev/hdc: Permission denied
/tmp/probepart: line 2: iso9660: command not found
/tmp/probepart: line 2: 0: command not found
Code: Select all
/dev/hda1|vfat|19068
/dev/hdc|iso9660|0
Well, I didn't put it there; the download did. I just ran it from where it ended up. I moved it to /root and it did this:
Just like the "old" one in other words.
Code: Select all
sh-3.00# ./probepart
/dev/hda1|vfat|39053952
/dev/hdc|iso9660|0
Sorry, haven't checked this thread in quite a while. I think I did use fdisk -l in one of the versions of the scripts I wrote but can't remember. I haven't messed with this in a while but I'll give your updated version a try. I was thinking of using dougal's idea with test-scsi & test-eide but just haven't thought about it in a while.
Well, I gave it a shot but somehow pmount is missing my hda1 ext3 partition even though it's reported back by (the new) probepart. I am using grafpup but I don't think that should matter since the original probepart works correctly with pmount. Here's what (the new) probepart says:
The original porbepart:
Maybe the information after the size of the drive is necessary to not cause pmount to mess up? Here's a picture of my pmount missing /dev/hda1:
Code: Select all
sh-3.00# probepart
/dev/hda1|ext3|14683346
/dev/hda2|swap|1028160
/dev/hda3|ext3|71296470
/dev/hda4|ext3|69288344
/dev/sda1|vfat|16002
/dev/sda2|ext3|3903794
/dev/sda3|ext3|308656844
/dev/hdc|iso9660|0
Code: Select all
sh-3.00# probepart-old
/dev/hdc|iso9660|0|Optiarc DVD RW AD-5540A
/dev/hda1|ext3|14683347|Linux Ext3FS
/dev/hda2|swap|1028160|Linux Swap
/dev/hda3|ext3|71296470|Linux Ext3FS
/dev/hda4|ext3|69288345|Linux Ext3FS
/dev/sda1|msdos|16002|DOS 16-bit FAT >=32M
/dev/sda2|ext3|3903795|Linux Ext3FS
/dev/sda3|ext3|308656845|Linux Ext3FS
- Attachments
-
- pmount-messed-up.jpg
- (59.44 KiB) Downloaded 676 times
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Ah, "good", I was getting quite concerned reading down the thread! The problem still exists for grafpup though.plinej wrote:nevermind, it seems to be a grafpup specific problem due to permissions. Running as root I see my partition correctly in pmount.
I've made another change to Pmount. I had a bug displaying the partition mounted on '/' for a full hd install. Attached:
- Attachments
-
- pmount.gz
- (5.92 KiB) Downloaded 404 times
I did some more work on the replacement scripts. I was having issues with probedisk thinking my usb external dvdburner was my rio mp3 player. I fixed this by commenting out the section to find extra scsi drives and utilizing test-scsi to find any other drives. Seems to work fine for me.
- Attachments
-
- probedisk-probepart-rewrites.tar.gz
- (1.62 KiB) Downloaded 428 times
I'm still encountering weird issues. I had 3 usb drives connected (sda, sdb, sdc). I removed sdb but test-scsi shows that my sdc drive is now my sdb drive (which is not the case per /proc/partitions). I'm going to see if I can't come up with some more revisions to my scripts. I'll probably just cross reference everything against /proc/partitions but in some cases that won't work. My usb dvd burner is not recognized in /proc/partitions. In those cases I'll have to think something else up.
The sg3_utils package seems to be very reliable in getting the correct usb device info.
sg_map -i
is the command that will get the desired info.
You can find their web page here:
http://sg.torque.net/sg/index.html#mozTocId689512
Of course that would be extra overhead but in order to correctly find usb/scsi devices it might be the way to go.
My revised probedisk/probepart scripts still depend on test-scsi from the libhardware package but other than that they don't need any other programs. I'm hoping that I've finally got them good enough to work well. Of course I need people to test them to make sure they work on their systems too.
sg_map -i
is the command that will get the desired info.
You can find their web page here:
http://sg.torque.net/sg/index.html#mozTocId689512
Of course that would be extra overhead but in order to correctly find usb/scsi devices it might be the way to go.
My revised probedisk/probepart scripts still depend on test-scsi from the libhardware package but other than that they don't need any other programs. I'm hoping that I've finally got them good enough to work well. Of course I need people to test them to make sure they work on their systems too.