Boot Panic with ipwifi3945(abg) : out of MTRRs! [r35779]

[composr]

Hello all, this is finally my first submission, which I will be happy to work out with the developers as much as possible. I have been following Haiku for a long time, and have been wanting to be more involved, so here we go.

Setup I am running this particular build of Haiku on a Dell Latitude D830, which contains an Intel PROSet Wireless 3495ABG adapter. I have the machine set up with 4 partitions:

• sda1: Linux / (root)
• sda2: [swap]
• sda3: Linux /liferay (for work projects)
• sda4: Haiku

All seems well, and I have the development environment set up in my Linux system, following the configuration for a GCC4-cross-compile and all.

Procedure I updated my SVN to hrev35779 and built out a raw image, which was then written to a USB stick. I rebooted from the USB stick to find it would not boot. The splash screen shows up, and each icon lights up predictably during the boot process. Once the boot script is launched, I get a black screen indefinitely. Upon reboot, and configuring the screen dump instead of the splash screen, I end up with the following panic message:

"(PANIC: add_used_mtrr(0xe00000000, 0x20000000, 1): out of MTRRs!)"

I cannot retrieve the end of what the screen dump says, because it dumps to the screen, which immediately clears and drops to the kernel debugger.

There are two ways I have confirmed this is a result of the wireless chipset:

1) Upon reboot, I drop into the BIOS setup, and disable the wireless adapter completely. Upon save and continue booting, Haiku boots as normal. 2) I have rebuilt Haiku, commenting out the inclusion of the wifi drivers in the HaikuImage ruleset in jam. Upon boot, proceeds as expected with no errors.

Unfortunately, since the only way to get system information is through turning off the wireless adapter, it does not show up in the dumps I am attaching. I will plan on rebuilding Haiku, commenting out the wifi drivers install script, and hope that I can get it booted so I can provide dumps that contain the wireless adapter's information.

I apologise for any confusion, and look forward to helping out as much as possible.

[composr]

Current syslog, with one failed boot and one successful

[composr]

Kernel Debugger interrupts immediately following panic

[composr]

Kdbg Panic message

[composr]

Listdev containing a disabled wireless adapter

[composr]

Once again, the wireless adapter is BIOS-disabled

[composr]

Device dump from Linux, to give a more accurate picture

[composr]

I would like to clarify that this has occurred for me on previous revisions; ever since the wifi stack was included by default in the build, I have had this problem with this wireless adapter. Hope that makes the issue clearer. :)

[stippi]

This panic was recently introduced by Ingo, after he worked some more on the MTRR setup routine. It is a continuable panic, just type "cont" at the kernel debugger prompt (possibly multiple times). I think what could be useful is attaching your MTRR setup from Linux, I forgot how that is retrieved. Either you can find instructions in another ticket, or perhaps Ingo or someone else leaves a note.

[composr]

I understand it is an MTRR setup issue, however, it is irresolvable without disabling the wireless controller. I have attempted, at muiltiple builds and boots, to continue from the kernel debugger. After about two or three panics, it simply freezes the system. I have left it alone for up to fifteen minutes after that, with no response from the system, and had to force a shutdown. I am attaching the dmesg, kern.log and debug dumps from linux. Let me know what else I can do to help :) Thanks!

[composr]

Dmesg dump from Linux

[composr]

Debug dump from linux

[composr]

Kernel log from Linux

[bonefish]

Replying to composr:

I understand it is an MTRR setup issue, however, it is irresolvable without disabling the wireless controller. I have attempted, at muiltiple builds and boots, to continue from the kernel debugger. After about two or three panics, it simply freezes the system.

As in "can't enter the kernel debugger via Alt-SysReq-D"? Or does it just fail continuing to boot? An unfortunate side effect of a panic in the boot process is that, if you stay too long in KDL, I/O can time out, which might stop the boot process.

I have left it alone for up to fifteen minutes after that, with no response from the system, and had to force a shutdown. I am attaching the dmesg, kern.log and debug dumps from linux. Let me know what else I can do to help :) Thanks!

The Linux stuff is not so interesting. A complete syslog up to the point where the panic() occurs would be helpful. Unfortunately the interesting part is missing in the attached one. If you could capture the serial output, that would be perfect. Alternatively in the kernel debugger a "syslog | tail 50" may or may not contain the missing output (more might be needed). You could also try a to replace the panic() in ​http://dev.haiku-os.org/browser/haiku/trunk/src/system/kernel/arch/x86/arch_vm.cpp#L125 by a dprintf(). Maybe it will fully boot. If it doesn't and you can enter the kernel debugger, you could run "on_exit sync" and "co" in the hope that it writes back all syslog additions to disk. And reboot thereafter.

As a general hint: Most Linux distributions have a "befs" file system module which does at least allow you to read-access BFS volumes. I.e. you don't need to boot Haiku to grab the syslog.

[composr]

Replying to bonefish:

As in "can't enter the kernel debugger via Alt-SysReq-D"? Or does it just fail continuing to boot? An unfortunate side effect of a panic in the boot process is that, if you stay too long in KDL, I/O can time out, which might stop the boot process.

Both; I have tried any forms of input whatever, as well as re-entering the debugger, with no success.

The Linux stuff is not so interesting. A complete syslog up to the point where the panic() occurs would be helpful. Unfortunately the interesting part is missing in the attached one. If you could capture the serial output, that would be perfect. Alternatively in the kernel debugger a "syslog | tail 50" may or may not contain the missing output (more might be needed). You could also try a to replace the panic() in ​http://dev.haiku-os.org/browser/haiku/trunk/src/system/kernel/arch/x86/arch_vm.cpp#L125 by a dprintf(). Maybe it will fully boot. If it doesn't and you can enter the kernel debugger, you could run "on_exit sync" and "co" in the hope that it writes back all syslog additions to disk. And reboot thereafter.

I will, of course, try to have a syslog that captures that; it is not practical for me to catch the on-screen output before and up to the panic, since I don't have the ability to do that. I will certainly try to capture the log and re-post it up here for you. The linux stuff was only due to a request, as per the previous comment. I apologise if it's superfluous.

As a general hint: Most Linux distributions have a "befs" file system module which does at least allow you to read-access BFS volumes. I.e. you don't need to boot Haiku to grab the syslog.

This may provide with a better chance of getting the panic text. Will reply with the aforementioned information. I, too, want to see what the log looks like leading to the panic :)

[diver]

After Ingo fixed #4399 I think I have the same issue here. If I enable on screen debug output it hangs after 3 pages without any related messages, but if I press "p" to disable paging in the beginning of debug output it gets me much further (btw, is that expected or I should open another ticket?). I end up with the following messages:

add_memory_type_range(2249,0x0,0x1000)
add_used_mtrr(0xf00000000, 0x10000000, 1): out of MTRRs!
add_used_mtrr(0xe00000000, 0x20000000, 1): out of MTRRs!

[bonefish]

Replying to diver:

After Ingo fixed #4399 I think I have the same issue here. If I enable on screen debug output it hangs after 3 pages without any related messages, but if I press "p" to disable paging in the beginning of debug output it gets me much further (btw, is that expected or I should open another ticket?).

Might be related.

I end up with the following messages:

add_memory_type_range(2249,0x0,0x1000)
add_used_mtrr(0xf00000000, 0x10000000, 1): out of MTRRs!
add_used_mtrr(0xe00000000, 0x20000000, 1): out of MTRRs!

A full syslog would be nice, or at last all lines with "add_memory_type_range" or "remove_memory_type_range". As of hrev35817 there's the "Select debug options" -> "Enable debug syslog" option in the boot loader. When you enable it and boot normally otherwise and then reenter the boot loader directly after reset, the same menu will have the item "Display syslog from previous session", which allows to scroll through the previous syslog. Might be a bit longish, though.

[diver]

It took me some time to write down all this lines using this method, this machine doesn't have a serial port. I wish it would be possible to dump this syslog to usb flash, sigh. Anyway, please look at the attached MTRR_output.txt.

[bonefish]

Replying to diver:

It took me some time to write down all this lines using this method, this machine doesn't have a serial port.

Sorry, I totally forgot to mention that the matching add_memory_type_range()/remove_memory_type_range() pairs can be omitted.

I wish it would be possible to dump this syslog to usb flash, sigh.

Yeah, that would be nice. Unfortunately writing to a file system on disk is not so simple in the boot loader. Maybe at least FAT32 support can be added.

Anyway, please look at the attached MTRR_output.txt.

Thanks! I'm not quite sure why it ends in garbage. Maybe the data had not yet been written from the CPU cache back to memory when the reset happened. I haven't encountered that in my tests. How did you reset the machine?

Anyway, the syslog does at least suggest that there are several very small RAM ranges which complicate the MTRR setup significantly. As of hrev35825 those will simply be ignored. Please give it a try. Even if it works please add a fresh syslog for reference.

[diver]

Ingo, you rock once again! Haiku is now fully boots again on this pc. I will attach syslog now, it looks truncated, though. The only showstopper for me is #5221.

[diver]

syslog from hrev35830

[bonefish]

Thanks! The syslog looks good. I hope that things work for composr, too.

[bonefish]

Replying to bonefish:

Thanks! The syslog looks good. I hope that things work for composr, too.

Assuming that they do. Closing...

[composr]

Just wanted to round out the bug closure by confirming testing on two devices - bugfix worked. Thank you all.