Author Topic: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.  (Read 63806 times)

0 Members and 3 Guests are viewing this topic.

meklort

  • VoodooLabs
  • Posts: 65
Try r156, and if that doesn't work, try booting with USBBusFix=No
« Last Edit: May 16, 2010, 01:47:59 AM by meklort »
return c ? c : !c;

Eps

  • Entrant
  • Posts: 7
Try r156, and if that doesn't work, try booting with USBBusFix=No

r156 still hangs,and verbose following info.

Code: [Select]
EHCI controller [8086:27c8] at 00:1d.0 DMA @0
UHCI controller [8086:27c8] at 00:1d.0 base 301(6021)
Setting Legacy USB Off on controller [8086:27c8] at 00:1d.0
Legacy USB Off Done
EHCI controller [8086:27c9] at 00:1d.1 DMA @0
UHCI controller [8086:27c9] at 00:1d.1 base 302(6041)
Setting Legacy USB Off on controller [8086:27c9] at 00:1d.1
Legacy USB Off Done
EHCI controller [8086:27ca] at 00:1d.2 DMA @0
UHCI controller [8086:27ca] at 00:1d.2 base 303(6061)
Setting Legacy USB Off on controller [8086:27ca] at 00:1d.2
Legacy USB Off Done
EHCI controller [8086:27cb] at 00:1d.3 DMA @0
UHCI controller [8086:27cb] at 00:1d.3 base 304(6081)
Setting Legacy USB Off on controller [8086:27cb] at 00:1d.3
Legacy USB Off Done
EHCI controller [8086:27cc] at 00:1d.7 DMA @0e8284000
UHCI controller [8086:27cc] at 00:1d.7 base 0(0)
Setting Legacy USB Off on controller [8086:27cc] at 00:1d.7
Legacy USB Off Done

USBBusFix=No doesn't work.
It still run Legacy USB Off function whatever I added USBBusFix=No in com.apple.Boot.plist or not.
« Last Edit: May 16, 2010, 03:02:36 AM by Eps »

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Hi @Meklort, very nice patches you are playing with, besides kernel patcher.
You need to take a look at the usb_loop; the way it's done it's out of control, always runs (several times) and can't be controlled by e.g.: LegacyOff=No. As i have a usb keyboard/mouse that depends on "legacy usb", i can't have LegacyOff running or i get stuck like @Eps mentions.
Anyway, my real interest on this patch lies on the fact that, the way you implemented it also fixes a problem i have with Wait=y+UHCIreset=y.. makes me hang. UHCIreset needs the same treatment as LegacyOff:
Quote
NOTE2: This should be called after any getc() call. (aka, after the Wait=y keyworkd is used)
.. just needs to be under control. EHCIacquire=y doesn't cause the same problem.
I always use USBBusFix; "strange" random stuff happens when i don't.

Will give some more input later, about the other patches.
Thanks

Edit: and kernel patcher is not working anymore. If i revert it to e.g.: rev 146, it works.
« Last Edit: May 16, 2010, 10:58:11 AM by Azimutz »
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

meklort

  • VoodooLabs
  • Posts: 65
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.
return c ? c : !c;

Eps

  • Entrant
  • Posts: 7
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.

So I have hanged in Chameleon RC4 before if USBBusFix function is enabled.
But it boots OK in your r150 build,it's odd.
Maybe it could be a kernel patcher problem.
Anyway,thank for your help.  :D

boot.teqs

  • Guest
hi @all, I tested the last revision (156), and I would like to test the ramdisk load at boot. But I don't know which args to pass to hdiutil to make a loadable image (Postboot.img).
I used this
Quote
hdiutil create -srcfolder /Volumes/EFI/Extra
That gave me a .dmg file, that is unloadable, perhaps because it doen't have .img extension. Also reviewed Perms, and gave it 755.
Any help for this please?

meklort

  • VoodooLabs
  • Posts: 65
I would like to test the ramdisk load at boot.

This is the command I use (copied form my NetbookInstaller build script, with a few modifications).

Code: [Select]
SIZE=set size here (in number of blocks)
RAMDISK=`hdiutil attach -nomount ram://$SIZE`
RAMDISK=`echo -e $RAMDISK`

newfs_hfs -v Postboot "$RAMDISK"
diskutil mount -mountPoint "${TARGET_BUILD_DIR}/Postboot" $RAMDISK
cp -rf "${TARGET_BUILD_DIR}/PostbootTmp/"* "${TARGET_BUILD_DIR}/Postboot"

diskutil unmount "$RAMDISK"
dd if="$RAMDISK" of="${TARGET_BUILD_DIR}/Postboot.img"
diskutil eject "$RAMDISK"

Do note that the ramdisk is only used to load a ramdisk using the bootloader, and have it attached to /dev/md0 in xnu. You can then mount it and use it how you like. I personally use it plus unionfs to patch the install dvd so that you don't have to run any extra commands to have a bootable system (patches install dvd to install chameleon and /Extra files during the regular install).

Eps: I'll take a look later today and see whats going on, that is after I'm finished with my adventure with wine + native kernel support (like rosetta).
return c ? c : !c;

boot.teqs

  • Guest
Thank you for the reply Meklort. Can you tell me more about ramdisks ? I was putting all the contents of V/E/E there and removed them form /V/E/E afterwards. And was hoping kexts+dsdt get loaded from Postboot.img (in /Extra) at boot time. but that didn't seem to work. Even-though, I can clearly see the .img file being loaded at boot time. Any clue ? please.

meklort

  • VoodooLabs
  • Posts: 65
Like I said before, the whole point of that ramdisk code is load up Postboot.img into kernel memory, and then notify xnu (the Mac OS X kernel) that it should attach said ramdisk to /dev/md0. Chameleon does *nothing* with the ramdisk other than get the memory location and length, and add it to the ioregistery.

There are two uses (that I know of at the moment) for this.
The first, and what I originally tested it with, is to load a livecd into ram and have a read / write file system. I tested the code using a 2009 puredarwin nano vmware image, and it results in the vmware image being being booted, while also allowing you to have write access to the ramdisk.

The other use, which for me is more useful, is to instead of using md0 as the root partition (root=md0), is instead to mount the /dev/md0 node later in the boot sequence. I use this by mounting it over essential system files using unionfs (the gui), and then cause my dvd patching code to modify the OSInstall.pkg file so that the final, installed, os does not need to be patched again. If you are wondering, the reason why I did it this way is because the xnu kernel cannot handle mounting another patition over / using union fs. It'll cause a kernel panic (and I really don't feel like fixing that bug at the moment).

Again, the point of this is *not* to house /Extra (there is no reason for that, it will not work, and you should just use the Preboot.dmg for that). The ramdisk code is instead useful to notify XNU that a ramdisk exists. That's it. Once XNU knows about the ramdisk, you can do whatever you like with it by messing with /dev/md0.
return c ? c : !c;

boot.teqs

  • Guest
Anyway, this stuff would really expand new ideas over it. Thank you very much for your great effort.
Regards.

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
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:
Code: [Select]
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 :P 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.
« Last Edit: May 20, 2010, 06:10:04 PM by Azimutz »
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

meklort

  • VoodooLabs
  • Posts: 65
I've changed the source code in svn:
- the CPU model is overridden for only Atom cpu's, panic is removed otherwise
- The lapic_init patch no longer causes a panic, I was off by one byte before
- Temporarily disabled legacy off code
- USB options are nolonger ignored, but they all enabled by default
return c ? c : !c;

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Hi Mek,
kernel patch is working again with my Pentium D 925.
« Last Edit: July 26, 2010, 12:20:01 PM by Azimutz »
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

Donk

  • Entrant
  • Posts: 7
Can confirm the new lapic patch now works. Thanks.

meklort

  • VoodooLabs
  • Posts: 65
Azimutz:

These patches are currently 32bit only, the don't work on the 64bit kernel.

I'm also not about to change *all* unknown cpu's to a specific model. What I will do is add your specific cpu to the switch, and patch based on that if you can tell me your cpuid.
return c ? c : !c;