Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 24 Oct 2014, 16:40
All times are UTC - 4
 Forum index » House Training » Bugs ( Submit bugs )
212,213b USB flash names not retained in Pmount, Univ Inst
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 7 of 10 Posts_count   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Next
Author Message
Jesse

Joined: 08 May 2005
Posts: 465
Location: Auckland, NZ

PostPosted: Wed 21 Feb 2007, 20:54    Post_subject:  

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
Back to top
View user's profile Send_private_message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Fri 23 Feb 2007, 16:06    Post_subject:  

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

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? Rolling Eyes

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...
Back to top
View user's profile Send_private_message 
Dougal


Joined: 19 Oct 2005
Posts: 2505
Location: Hell more grotesque than any medieval woodcut

PostPosted: Sun 25 Feb 2007, 10:02    Post_subject:  

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
Back to top
View user's profile Send_private_message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Sun 25 Feb 2007, 14:05    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 7047
Location: Perth, Western Australia

PostPosted: Sun 08 Apr 2007, 20:02    Post_subject:  

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.
probepart.gz
Description 
gz

 Download 
Filename  probepart.gz 
Filesize  1.02 KB 
Downloaded  313 Time(s) 
Back to top
View user's profile Send_private_message Visit_website 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Mon 09 Apr 2007, 00:28    Post_subject:  

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:
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:
/dev/hda1|vfat|19068
/dev/hdc|iso9660|0
Back to top
View user's profile Send_private_message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 7047
Location: Perth, Western Australia

PostPosted: Mon 09 Apr 2007, 09:26    Post_subject:  

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.
Back to top
View user's profile Send_private_message Visit_website 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Wed 11 Apr 2007, 00:36    Post_subject:  

Well, I didn't put it there; the download did. I just ran it from where it ended up. Smile I moved it to /root and it did this:

Code:
sh-3.00# ./probepart
/dev/hda1|vfat|39053952
/dev/hdc|iso9660|0


Just like the "old" one in other words.
Back to top
View user's profile Send_private_message 
plinej

Joined: 13 Aug 2006
Posts: 1522

PostPosted: Wed 11 Apr 2007, 10:31    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
plinej

Joined: 13 Aug 2006
Posts: 1522

PostPosted: Wed 11 Apr 2007, 11:23    Post_subject:  

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:

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:
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:
pmount-messed-up.jpg
 Description   
 Filesize   59.44 KB
 Viewed   649 Time(s)

pmount-messed-up.jpg

Back to top
View user's profile Send_private_message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Wed 11 Apr 2007, 12:17    Post_subject:  

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?
Back to top
View user's profile Send_private_message 
plinej

Joined: 13 Aug 2006
Posts: 1522

PostPosted: Wed 11 Apr 2007, 12:49    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
plinej

Joined: 13 Aug 2006
Posts: 1522

PostPosted: Wed 11 Apr 2007, 13:03    Post_subject:  

nevermind, it seems to be a grafpup specific problem due to permissions. Running as root I see my partition correctly in pmount.
Back to top
View user's profile Send_private_message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 7047
Location: Perth, Western Australia

PostPosted: Wed 11 Apr 2007, 23:08    Post_subject:  

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:
pmount.gz
Description 
gz

 Download 
Filename  pmount.gz 
Filesize  5.92 KB 
Downloaded  299 Time(s) 
Back to top
View user's profile Send_private_message Visit_website 
plinej

Joined: 13 Aug 2006
Posts: 1522

PostPosted: Fri 20 Apr 2007, 19:39    Post_subject:  

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.
probedisk-probepart-rewrites.tar.gz
Description 
gz

 Download 
Filename  probedisk-probepart-rewrites.tar.gz 
Filesize  1.62 KB 
Downloaded  301 Time(s) 
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 7 of 10 Posts_count   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » House Training » Bugs ( Submit bugs )
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1157s ][ Queries: 13 (0.0060s) ][ GZIP on ]