Yup, it needs cleaning up (I haven't tested the latest two commit, probably should have). The USB code is defaulted to on, however it *should* (but again, probably doesn't) respond to the regular usb command, I'll take a look and see why. I really should fix those typos in that comment too. The usb_loop() code is only run once, I'm not sure where you see it happening multiple times (each part in the wile loop is run for each usb device, just like it was before without my changes. Yes, it definitely needs to be able to be turned off). If you are wondering, the whole point of that usb patch is that it lets the Asus 1201n boot off of a usb drive without issues, before you had to disable usb 2.0 in the bios.
Anyways, it looks like the freeze is due to the kernel patcher as all of the usb code is run and finishes. The only code after that is asm that starts the kernel.
Hi Mek,
my post wasn't that clear so, i made more tests and took some pics. About the usb_loop; my normal experience with the USB fixes on Chameleon is this:
- i need to use USBBusFix=y or i get all sorts of usb problems.
- if i use Wait=y i get stuck, pressing any key to continue does nothing; the keyboard still works so, it's the usb bus that gets disconnected;
- i isolated the problem to the use of UHCIreset; if i use only EHCIacquire i can go on but, that alone doesn't solve the usb problems; they are maybe related to Legacy USB, i don't know; the mobo is in fact manufactured by Asus (check my sig if you get curious); it does have an option to disable Legacy USB on BIOS, but i can't use it because the keyboard/mouse need it.
- pic 1: my normal boot
- usb devices by lspci:
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 01)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 01)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 01)
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 01)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 01)
So, i had already realized that making the usb fixes run before Wait=y would fix the problem, but i still don't have the knowledge to do it
As this is a problem that affects more people (though i don't see reports about this around), as soon as i saw the way you did it, it caught my attention. This is how it goes with the usb_loop on rev 156:
- pic 2: it hangs there.
- pic 3: still hangs. Why it goes further here, beats me!? The diff is that i added USBLegacyOff=No to Boot.plist.
- pic 4: here i removed just the LegacyOff code from the loop, added a "pause()" after usb_loop call and used Wait=y to take the pic and catch the after "Wait". USBBusFix=No also doesn't work.
I just didn't explained my self properly; what i meant with "several times" is that the loop runs the 3 fixes on every usb device that finds; not the way it usually works (or should!?). In the last situation were i removed LegacyOff, i can boot normally so, the loop doesn't "hurt" the fixes. They should be set to "false" by default and activated at user request.
You should remove LegacyOff from USBBusFix too; well, here i can also start using the separate keys instead of USBBusFix
not a must. LegacyOff is really of no interest for me atm, for obvious reasons.
About the kernel_patcher; it doesn't look like it's causing the hang! With LegacyOff removed it works.. that is, worked till rev 150. Latest fails.
Hope this is more clear and helpful
I know i'm looking at the usb patch in a diff perspective but, it's the best compromise i can think of for this "Wait problem". Would love to see this merged to the trunk.