KDL after bootup

[humdinger]

This is hrev39155.

Some of the latest changes seem to have broken something...
I've build an anyboot image from hrev39155. Booting from it, I get over all boot icons, the background turns blue and after 10-20 secs I enter KDL. I hope the attached photos are usable.

[humdinger]

KDL

[humdinger]

Backtrace

[anevilyak]

Would you be able to get a shot in slightly better lighting? it's nearly impossible to read the actual panic message properly, though it appears to be timing out trying to read from the disk.

[humdinger]

Another try: KDL

[humdinger]

Another try: Backtrace

[humdinger]

Uploaded two more shots from another session. Those are better lit (I moved away with the camera and zoomed in a bit instead; apparently the viewing angle from my crappy LCD panel is quite limited which one doesn't notice when viewing from a normal distance).
Hope this helps!

[phoudoin]

Seems the KDL is raised while Bash is executing [user]bootscript. The path argument passed to dir_open() looks suspicious: 0x401, a valid address!?

[phoudoin]

Could you check what your Bootscript and UserBootScript does. What do you have in /boot/home/config/boot/launch folder?

[humdinger]

It should all be clean, as I didn't change things in my UserBuildScript. It's booting from a freshly dd'ed anyboot image. I'll rebuild a new image and mount it in Haiku to see if there's anything amiss. I'll also dd a nightly anyboot from the build factory, to see if something's from in my checked out trunk. Thanks for having a look!

[humdinger]

I now dd'ed a nightly hrev39156 ggc4h onto a stick: boots up no problem. Then I updated my trunk to hrev39156, build and dd'ed: KDL. Bootscripts are the same... The UserBuildConfig also just adds some OptionalPackages etc...
So... you think I should scrap the whole trunk and checkout once more?

[phoudoin]

what gcc flavor do you build for? And is it a clean build, aka a jam -a one? Clearly, something is different between the way BOM build a gcc4h hrev39156 image and your build environment does it.

[humdinger]

I build gcc4hybrid images, the same flavour I downloaded from the BuildFactory. I did a "jam -qa" and removed the objects, attributes and tmp folders before. You're right, something has to be different. :)

[luroh]

Is your buildtools/ kosher? Run 'svn stat' there to check for local changes, remove any suspicious files and 'svn up' it again. Delete everything in generated/ (except for maybe downloads/), configure and build again.

[humdinger]

Well, damn! Turns out Colin's BG023 hack of my iprowifi3945 was a time bomb...
It was compiled a couple of times and either put on an USB stick to replace the driver of the Haiku installation (or directly updated via jam @HD update iprowifi3945). Worked in the end. Strangely, now, when building a complete anyboot image, the bootup hangs[[BR]] Closing this ticket, sorry about that... Here's the little diff, if anyone's interested:

src/add-ons/kernel/drivers/network/wlan/iprowifi3945/dev/wpi$ svn diff

Index: if_wpi.c
===================================================================
--- if_wpi.c	(Revision 39165)
+++ if_wpi.c	(Arbeitskopie)
@@ -547,9 +547,9 @@
 	sc->sc_sh = rman_get_bushandle(sc->mem);
 
 	sc->irq_rid = 0;
-	if ((result = pci_msi_count(dev)) == 1 &&
-	    pci_alloc_msi(dev, &result) == 0)
-		sc->irq_rid = 1;
+//	if ((result = pci_msi_count(dev)) == 1 &&
+//	    pci_alloc_msi(dev, &result) == 0)
+//		sc->irq_rid = 1;
 	sc->irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, &sc->irq_rid,
 	    RF_ACTIVE | RF_SHAREABLE);
 	if (sc->irq == NULL) {
@@ -558,6 +558,8 @@
 		goto fail;
 	}
 
+	sc->irq->r_bushandle = 19;
+
 	/*
 	 * Allocate DMA memory for firmware transfers.
 	 */