'better' usbstoragefunc in the init script

Message

edoc · #16 Post by **edoc** » Sat 12 Aug 2006, 14:03

It is great to read that y'all are chasing the USB problem. On our 2.02 desktop the bug also
jams up any effort to write to a FDD or CD.

I've been struggling with this for weeks in a different thread and only today heard that
anyone even recognized that there was a problem.

Almost began to think that my computer had a demon!

I guess the PC is unuseable until the fix is released, unless I wipe it and reinstall an earlier version, perhaps pre-2.xx?

I do worry that I have been referring folks to Puppy and bragging about the 2.xx release.

Thanks! doc

Jesse · #17 Post by **Jesse** » Sat 12 Aug 2006, 23:44

Hi Barry,

Yes there is a big delay between these two lines:

usb-storage: device found at
usb-storage: device scan complete

Each usb-storage device on the usb has a pair of those two lines.
The "device found at" means there is a usb chip saying "i do usb-storage" and comes up right away, the "device scan complete" means that the chip has finished identifying its device(s) and told the system about them.

My guess is that I've coded it right for 1.1 as well as 2.0. I'll go test it aye!

Jesse

BarryK · #18 Post by **BarryK** » Sat 12 Aug 2006, 23:56

Okay, I did it.
I fired up a usb1 PC, did 'rmmod usb-storage' and I wrote a little script with a
loop that loads usb-storage then reports what's in dmesg every 1 sec.
I plugged in the usb1 flash drive (into the usb1 interface) then immediately
ran the script.

yes, 'usb-storage: device found at' comes up immediately.
I got 'usb-storage: device scan complete' after 6 seconds.

Same thing for a usb2 flash drive plugged into the usb1 interface.

lookin good!

That delay you want beteen loading usb-storage and running the
usbstoragecompleteionfunc, that's not normally needed is it?
Not for flash drive anyway. I think that you thought it may be needed
for usb hard drives.

Jesse · #19 Post by **Jesse** » Sun 13 Aug 2006, 00:48

Hi Barry,

Coolies, yep I thought it would work.
I think that 1 sec sleep might be needed beteen loading usb-storage and running the usbstoragecompleteionfunc, as there is no catch if there are zero "device found at" lines, might have to check that one out.

I've also been having a bit of success with getting SCSI disk to boot, see thread:

http://www.murga.org/~puppy/viewtopic.php?p=62770

with only a few more minor tweaks to the init script, and a few more kb of drivers.

Jesse

pakt · #20 Post by **pakt** » Sun 13 Aug 2006, 06:19

BarryK wrote: yes, 'usb-storage: device found at' comes up immediately.
I got 'usb-storage: device scan complete' after 6 seconds.

Yep, 6 seconds sounds familiar - that's the same figure I came up with when we were getting USB detection to work with the new kernel in 2.00b.

BarryK · #21 Post by **BarryK** » Sun 13 Aug 2006, 21:57

Jesse,
in that scsi thread you mentioned needing a whole lot of scsi modules in the initrd.
But, what about one or two generic scsi modules? Has anyone looked in the DSL
initrd?

BarryK · #22 Post by **BarryK** » Sun 13 Aug 2006, 22:10

Can someone test this initrd?
It is supposed to boot from SATA HD, USB CD, plus has Jesse's improved
and faster USB drive detection.

Unfortunately I have one of those SATA systems that don't work. I bought a
new PC with SATA HD especially for testing Puppy, but found the motherboard
chip's SATA interface isn't supported -- I found out that it will probably be
supported in the 2.6.18 kernel.

So, my mods to the init script are theoretical...

Oh, I just realised the initrd.gz is too big to post to the forum, so I'll just post the
init script...

Jesse · #23 Post by **Jesse** » Mon 14 Aug 2006, 08:22

Hi Barry,

I've had a look into DSL's minit24.gz (initrd.gz equivilent) and their init script.
Unfortunately there is no quick and easy fix like 'one or two generic scsi modules'

DSL initrd modules:

a100u2w advansys aha152x aha1542 aha1740 aic7xxx ataraid
atp870u BusLogic dtc eata ehci-hcd fdomain gdth hptraid
ide-cd ide-scsi ieee1394 initio megaraid mptscsih NCR53c406a
ncr53c8xx ohci1394 pas16 pci2000 pci2220i pdcraid psi240i
sbp2 seagate silraid t128 tmscsim u14-34f ultrastor usbcore
usb-ohci usb-storage usb-uhci wd7000

Looks like DSL uses a 2.4 kernel. Puppy is on a 2.6 Kernel, so these names may not have a 1-1 comparison, and the list does not show what is compilied directly into the kernel.

Nevermind, we should still be able to come up with a solution for Puppy.

I'm looking at DSL as it looks very different but similar, the inird is much smaller and I'm trying to understand why, it would be nice if we can cutout any unnecessary kb from our initrd.gz and still keep it Puppy!

Jesse

PaulBx1 · #24 Post by **PaulBx1** » Wed 16 Aug 2006, 03:04

Well, I made a lengthy post here but it seems to have disappeared.

Probably previewed it but forgot to post it.

Anyway, my problem was detection of USB mice. I was having problems and wondered if Jesse's initrd would fix it. At first I thought it didn't, but today it is working. But today the stock initrd is working too. So it looks intermittent at this point. If it fails again I will list that elspci command that you wondered about. For what it's worth, here it is in a working condition:

Code: Select all

sh-3.1# /initrd/bin/elspci -l 
02:00.0 020000 168C:0013 <ndiswrapper>
01:00.0 030000 1002:4C4D <>
00:07.3 068000 8086:7113 <>
00:07.2 0C0300 8086:7112 <uhci_hcd>
00:07.1 010180 8086:7111 <PIIX_IDE>
00:07.0 068000 8086:7110 <>
00:05.0 040100 1013:6003 <Sound Fusion CS46xx>
00:03.0 078000 11C1:0449 <>
00:02.1 060700 104C:AC1B <yenta_cardbus>
00:02.0 060700 104C:AC1B <yenta_cardbus>
00:01.0 060400 8086:7191 <>
00:00.0 060000 8086:7190 <agpgart-intel>
sh-3.1#

BTW it's a Thinkpad A21m with USB 1.1 port, a hub on that, and the mouse plugged into the hub.

PaulBx1 · #25 Post by **PaulBx1** » Wed 16 Aug 2006, 14:16

OK, today it decided to not work. I first booted with the stock initrd, then when I saw it was not working I rebooted with Jesse's. Still not working. Here's the elspci:

Code: Select all

sh-3.1# /initrd/bin/elspci -l
02:00.0 020000 168C:0013 <ndiswrapper>
01:00.0 030000 1002:4C4D <>
00:07.3 068000 8086:7113 <>
00:07.2 0C0300 8086:7112 <uhci_hcd>
00:07.1 010180 8086:7111 <PIIX_IDE>
00:07.0 068000 8086:7110 <>
00:05.0 040100 1013:6003 <Sound Fusion CS46xx>
00:03.0 078000 11C1:0449 <>
00:02.1 060700 104C:AC1B <yenta_cardbus>
00:02.0 060700 104C:AC1B <yenta_cardbus>
00:01.0 060400 8086:7191 <>
00:00.0 060000 8086:7190 <agpgart-intel>
sh-3.1#

pop-pop · #26 Post by **pop-pop** » Thu 17 Aug 2006, 11:32

Barry asked:

Can someone test this initrd?
It is supposed to boot from SATA HD, USB CD, plus has Jesse's improved
and faster USB drive detection.

I was going to test the SATA boot for you but ran into a snag:

Code: Select all

sh-3.1# tar -xvzf init.gz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Error exit delayed from previous errors

What did you pack the init.gz file with?

pop-pop · #27 Post by **pop-pop** » Thu 17 Aug 2006, 13:05

What did you pack the init.gz file with?

Oops! brainphart on my part

It was packed with gzip.

Jesse · #28 Post by **Jesse** » Thu 17 Aug 2006, 13:17

Hi PaulBx1,

Thanks for posting, I can't tell you what the exact problem is, because I am still trying to put my finger precisely on it.
I've been messing about, trying lots of ideas, with a lot of rebooting involved, and all I can say for sure is that I am getting confused.
I think I might have stumbled on the key to understanding usb though, its very complicated and we need to be smarter

Theres something about usb devices and usb controllers, some or all of the below I have reason to suspect is true:
1) They can keep their state past a bus 'reset'.
2) Loading kernel modules in certain orders that can make for all sorts of confusion, like devices registering with the first driver, then jumping to the second.
3) USB 2.0 controllers and devices are supposed to work (and do) with a USB 1.1 driver, from bios and Kernel OS.
4) USB devices must be able to switch between kernel and bios drivers, because they never loose power.
5) Resetting the computer part way through Windows boot sequence (or OS I suppose) can put the USB bus into a very confusing state.
6) USB bus will stay on after you 'shutdown' and computer has switched off.
7) Modern computers have a power supply that supplies power to USB even if you pull the wall socket, for about 10 - 20 seconds.

I'm probably missing other things that can affect things.
9) All sorts of interactions from all the above...

Ok, well, if I can cover all those things I might be able to find a solution that works at least as well as Barrys solution...
The "real solution" might involve getting the shutdown script in sync with the init script, and never having anything crash badly enough to require the 'reset' button to be pressed, and always getting the user to use the shutdown command (in all their OSs), and never having any 'momentary' power brownouts. hmmmm...
I'll try a few more things tomorrow.

Jesse

pop-pop · #29 Post by **pop-pop** » Thu 17 Aug 2006, 20:00

I was going to test booting from an SATA hard drive with Jesse's "init" but I need some help.

I have a spare empty SATA HD that will be a RAID drive one of these days and I was going to use that for boot testing.

My plan was to first get the "init" working with my Puppy 2.02 installation on /dev/sda and install to the spare SATA drive from there. The existing "/sbin/init" is a symbolic link to busybox. Just replacing that link with the "init" file doesn't work.

Do I need to be working from a Puppy on CD or what?

karlandtanya · #30 Post by **karlandtanya** » Sat 02 Sep 2006, 15:11

Jesse wrote: Attachment includes the init script and the elspci file.

Jesse

First, note that puppy 202 works beautifully from a CD, and I've successfully compiled the kernel, truecrypt, and a couple other packages I like to use.

I would, very much like to be able to run puppy from my USB memory device.

I'm running into a little issue with USB booting:
The laptop I carry with me is a Dell Latitude D500.
Here's what I've done so far:
I'm using superfloppy mode. (BIOS doesn't like the boot sector)
I'm using the init and elspci from for_initrd in this forum.
I can boot as far as loading initrd, but no farther.
See dmesg_out (attached)
init seems to fail to find the "cannot find Puppy on usbflash boot media"
See init_out (attached)
however, I can manually mount hda on tmpfs
See manually_mount_out (attached)
See ls_mnt_tmpfs_out

Notes
I have put the new /init in /sbin/init in initrd
checked that this is the updated one by finding the lines
#v2.10 jesse has created 'elspci' that improves usb detection (t=)...
#comment-out the old stuff...
in there after booting as described above.
Also, I have put elspci in /sbin on initrd, and the new /sbin/init seems to find it.

hardware:
Dell latitidue D500, BIOS ???? (I'll write it down next boot & follow up)
USB controller Intel 82801DB/DBM
Kingston Data Traveller II, 1G

I am not sufficiently proficient to improve the init script, but I'm guessing that if I can manually mount the filesystem on the memory stick, then there must be a way to automate that process.

Can anybody suggest what I might do differently or point me to the section of script I should be looking at?

I would very much appreciate any help you can offer

Thanks

PS
If anybody cares about truecrypt, I'll post; I have NOT yet made a dotpup because I'm not sure how to correctly append the lines to modules.dep (what about duplicates). I'm guessing just steal it from the truecrypt install script...

BarryK · #31 Post by **BarryK** » Sun 03 Sep 2006, 01:05

Have you tested Puppy 2.10alpha?
That has the latest init script.

karlandtanya · #32 Post by **karlandtanya** » Sun 03 Sep 2006, 17:29

BarryK wrote:Have you tested Puppy 2.10alpha?
That has the latest init script.

Just did it; no help.

Works fantastic on CDROM;

Used the universal installer to install to the Kingston Data Traveller II, 1GB
Then, "failed to find Puppy on usb boot device"

dmesg > dmesg_out (please ignore the /dev/hda stuff; I fatfingered--see below)

After failing to find puppy on usb boot device, I tried to mount /dev/sda (the usb device)

I successfully mounted it with no arguments (it came up as MSDOS), and as vfat with -t vfat. See output of mount, also attached.

Thanks again for all the help and the great distro!

I booted from the CD at work and got right on the internet via the LAN. Very, very easy!

BarryK · #33 Post by **BarryK** » Sun 03 Sep 2006, 22:14

I looked at the dmesg output, the usb drive is being recognised.
It may be a problem with it being a "superfloppy" as we haven't done much
testing booting from such.

Can you try this:
# disktype /dev/sda
...zip or gzip the output and post here -- I think you can insert the text directly
in a reply to this thread, but be sure to choose "Code" button (see above) so
that it displays with all the correct spacing.

I did test booting from a superfloppy awhile back, but it is possible that it got
broken after that. Your o/p from disktype will help me to correct that.

BarryK · #34 Post by **BarryK** » Sun 03 Sep 2006, 22:16

While you're at it, try these also:

# probedisk

# probepart

karlandtanya · #35 Post by **karlandtanya** » Mon 04 Sep 2006, 13:05

OK, booted from CD & ran the specified commands

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

'better' usbstoragefunc in the init script

new init and elspci with Dell Latitude D500

output with usb superfloppy