212,213b USB flash names not retained in Pmount, Univ Inst

Please post any bugs you have found
Message
Author
Jesse
Posts: 466
Joined: Sun 08 May 2005, 16:07
Location: Auckland, NZ

#91 Post by Jesse »

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

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#92 Post by PaulBx1 »

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:

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
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):

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
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!" :x

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? :roll:

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...

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#93 Post by Dougal »

I am curious: does this problem only exist with probepart and probedisk, or also with test-scsi?
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#94 Post by PaulBx1 »

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.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#95 Post by BarryK »

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.
Attachments
probepart.gz
(1.02 KiB) Downloaded 422 times

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#96 Post by PaulBx1 »

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:

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
However that probepartm file had this:

Code: Select all

/dev/hda1|vfat|19068
/dev/hdc|iso9660|0

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#97 Post by BarryK »

Huh? Don't put the 'probepart' script into /tmp, as the script creates a temporary file /tmp/probepart.
Note, my new script does not create /tmp/probepartm.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#98 Post by PaulBx1 »

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:

Code: Select all

sh-3.00# ./probepart
/dev/hda1|vfat|39053952
/dev/hdc|iso9660|0
Just like the "old" one in other words.

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#99 Post by plinej »

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.

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#100 Post by plinej »

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:

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
The original porbepart:

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
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:
Attachments
pmount-messed-up.jpg
(59.44 KiB) Downloaded 676 times

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#101 Post by PaulBx1 »

I like that missing information too. Maybe most scripts (who knows about pmount) don't need it, but it is nice for us humans. It's pretty easy to add back in, isn't it?

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#102 Post by plinej »

Yeah, I could add it back in but it doesn't seem to be the problem. Somehow my /dev/hda1 is being reported back to /tmp/probepart as "unknown" instead of "ext3" as it really is. Now I have to figure out why.

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#103 Post by plinej »

nevermind, it seems to be a grafpup specific problem due to permissions. Running as root I see my partition correctly in pmount.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#104 Post by BarryK »

plinej wrote:nevermind, it seems to be a grafpup specific problem due to permissions. Running as root I see my partition correctly in pmount.
Ah, "good", I was getting quite concerned reading down the thread! The problem still exists for grafpup though.

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 402 times

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#105 Post by plinej »

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 426 times

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#106 Post by plinej »

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.

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#107 Post by Dougal »

I say just drop those two apps... it's a shame to waste so much energy on trying to fix them, rather than just modifying Pmount and whatever else uses them...
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#108 Post by plinej »

Okay, revised once again.

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#109 Post by plinej »

Dougal, I definitely agree. I think with my recent revisions the scripts should work. Although I've proved test-scsi is buggy just like the original probedisk/probepart programs. I think with the cross referencing check with /var/log/messages that I just incorporated it should prove to work better.

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#110 Post by plinej »

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.

Post Reply