Opened 14 years ago

Closed 14 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:
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 14 years ago.
KDL
DSCF3978-bt.JPG (366.3 KB ) - added by humdinger 14 years ago.
Backtrace
DSCF3981-kdl.JPG (136.0 KB ) - added by humdinger 14 years ago.
Another try: KDL
DSCF3982-bt.JPG (168.8 KB ) - added by humdinger 14 years ago.
Another try: Backtrace

Download all attachments as: .zip

Change History (14)

by humdinger, 14 years ago

Attachment: DSCF3977-kdl.JPG added

KDL

by humdinger, 14 years ago

Attachment: DSCF3978-bt.JPG added

Backtrace

comment:1 by anevilyak, 14 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, 14 years ago

Attachment: DSCF3981-kdl.JPG added

Another try: KDL

by humdinger, 14 years ago

Attachment: DSCF3982-bt.JPG added

Another try: Backtrace

comment:2 by humdinger, 14 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, 14 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, 14 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, 14 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, 14 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, 14 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, 14 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, 14 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 14 years ago by luroh (previous) (diff)

comment:10 by humdinger, 14 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.