Opened 9 years ago

Closed 9 years ago

#6753 closed bug (invalid)

KDL after bootup

Reported by: humdinger Owned by: axeld
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (4)

DSCF3977-kdl.JPG (192.6 KB ) - added by humdinger 9 years ago.
KDL
DSCF3978-bt.JPG (366.3 KB ) - added by humdinger 9 years ago.
Backtrace
DSCF3981-kdl.JPG (136.0 KB ) - added by humdinger 9 years ago.
Another try: KDL
DSCF3982-bt.JPG (168.8 KB ) - added by humdinger 9 years ago.
Another try: Backtrace

Download all attachments as: .zip

Change History (14)

by humdinger, 9 years ago

Attachment: DSCF3977-kdl.JPG added

KDL

by humdinger, 9 years ago

Attachment: DSCF3978-bt.JPG added

Backtrace

comment:1 by anevilyak, 9 years ago

Component: Servers/net_serverSystem/Kernel

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.

by humdinger, 9 years ago

Attachment: DSCF3981-kdl.JPG added

Another try: KDL

by humdinger, 9 years ago

Attachment: DSCF3982-bt.JPG added

Another try: Backtrace

comment:2 by humdinger, 9 years ago

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!

comment:3 by phoudoin, 9 years ago

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

comment:4 by phoudoin, 9 years ago

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

comment:5 by humdinger, 9 years ago

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!

comment:6 by humdinger, 9 years ago

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?

comment:7 by phoudoin, 9 years ago

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.

comment:8 by humdinger, 9 years ago

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. :)

comment:9 by luroh, 9 years ago

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.

Last edited 9 years ago by luroh (previous) (diff)

comment:10 by humdinger, 9 years ago

Resolution: invalid
Status: newclosed

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.
 	 */
Note: See TracTickets for help on using tickets.