Kernel panic - not syncing: Fatal exception in int (Solved)

[champted]

When booting Puppy 2.01r2 or 2.02, I get the following:
- the boot process stalls
- after about a minute, a Call Trace line appears, followed by nineteen lines of text, each one beginning with an 8-digit hex number enclosed in [< and >]
- the word Code: followed by 64 pairs of hex numbers
- the following line:
<0> Kernel panic - not syncing: Fatal exception in interrupt
- and then I have to push the reset button to get anything else to happen.

In Puppy 2.01r2, this happens after the following line appears in the boot process:
Registering unionfs 20060417-0541

In Puppy 2.02, this happens after the following three lines appear:
Registering unionfs 20060503-0408
fuse init (API version 7.6)
Looking for Puppy in partition hdc (iso9660 filesystem)

The CD-ROMs I am using boot fine in two other machines I have, so they are not suspect.

Another Linux distro that I tried in this particular machine would not boot unless I added "probe=scsi" to the boot command.

I suspect the CD-ROM drive hardware may be contributing to the problem, but I don't know how it would.

The info requested for beginners' posts follows, after the = sign:

The make of your machine. = DFI
The amount of RAM (memory) installed. = 128 MB
The CPU (processor) speed. = Pentium MMX 233 MHz
What Hard Drives, CDROMs and DVDs that are installed. =
- first IDE: WDC WD102AA hard drive 10 GB
- second IDE: <none>
- third IDE: FX320S CD-ROM drive
- fourth IDE: Seagate STT8000A tape drive
The Partitions, size and type, on any hard drives. =
- 7632 MB, type 83 Linux
- 486 MB, type 82 Linux swap
- 1663 MB, type 83 Linux
What type of Keyboard & Mouse i.e. Serial, PS/2, USB or other. = both PS/2
Which version of Puppy you are working with. = see above

Thankx in advance for any help.
--champted

[J_Rey]

OK. First, are all the drives IDE or are there any SCSI drives/controllers? Does anything different happen if you type puppy probe=scsi at the boot prompt, as you mentioned? Since this does sound to be related to your specific hardware, especially with the "Fatal exception in interrupt" error, you might try to see if trying different ACPI options may be related also. See the boot parameter wiki page for more.

[fluxit]

champted,

You might want to try puppy ide=nodma as well.

--Lee

[champted]

J_Rey and fluxit:

Thank you for your replies, the pointers to information, and your help.

The drives are all IDE; there are no SCSI drives or controllers in the box. That is why I was a little confused when the other distro would boot with "probe=scsi".

However, I did try the following, with the results indicated:
- boot: puppy probe=scsi <- no joy
- boot: puppy acpi=off <- no joy
- boot: puppy acpi=force <- no joy
- boot: puppy ide=nodma <- WORKS!!

I couldn't find anything out about "probe=scsi" in any of the information referred to. I'll have to check the documentation for the other distro to see if possibly its "probe=scsi" boot option does the same thing as "ide=nodma" does for Puppy.

Thankx again!
Ted Champagne (champted)

[Sit Heel Speak]

Ah. Vintage-1996 hardware. This is good to know. Question:

Ted, when you boot Windows on this machine, do you by any chance have a

device=c:\windows\dblbuff.sys

line in config.sys (if you have same) (this line loads the disk cache buffer into low memory, which is guaranteeably DMA-enabled, whereas upper memory is not), and/or do you have a

DoubleBuffer=1

line (which accomplishes the same thing as the dblbuff.sys line) in msdos.sys? I assume the "other" OS is some flavor of Win9x.

You can check without having to open either file for editing, by opening a DOS window and issuing

mem /c | find "dblbuff" /i

and see if a line appears.

I am thinking a little above my experience-level now, that it may be possible to recompile the Linux kernel to specify that the disk cache buffers are loaded low, not high, just as dblbuff does. My theory being, that it is the inconsistency between the request for DMA and the upper memory's lack thereof, and not the DMA request itself, that is the stumbling block. If my theory is correct, then this slight change would greatly speed up both disk and CD access on older hardware such as Ted's.

[champted]

Hello, Sit Heel Speak, and thankx for your reply.

Ah. Vintage-1996 hardware.

Actually, 1998, but close enough for our discussion.

Ted, when you boot Windows on this machine, do you by any chance have a

device=c:\windows\dblbuff.sys

line in config.sys (if you have same) (this line loads the disk cache buffer into low memory, which is guaranteeably DMA-enabled, whereas upper memory is not), and/or do you have a

DoubleBuffer=1

line (which accomplishes the same thing as the dblbuff.sys line) in msdos.sys? I assume the "other" OS is some flavor of Win9x.

I wiped Win95 off the hard drive about a year ago, so I can't give you a definitive answer based on looking at it right now, but I am just about positive that it was not using double-buffering. I had read an article somewhere that I interpreted to mean that double-buffering was A Bad Thing for my particular PC, so I made sure it didn't have it, but this was so long ago that I can't be absolutely sure.

I am sure, however, that it did have DOS=HIGH,UMB in config.sys .

I hope this helps.

--Ted

[Sit Heel Speak]

Thanks for the reply. I'll try it both ways, someday, when I finally learn how to compile the kernel and do so on my own 233MMX.

Actually, my P3-800 Thinkpad T21 does not have upper memory DMA-enabled, either, except for the block at D000-DFFF. I can't help but wonder whether this slows my Puppy disk access. But it isn't a front-burner issue.

[Max Headroom]

OK, I've Read This Solution / Reply, Unfortunately it does Not Compute ( I'm Home, Sick Today w/ th' Flu ), I'm Trying 2 Install "Puppy 2 w/ Opera" ( M' Favorite Browser ) onto an Old Dell Tower PC, Pentium MMX 166 MHz, 64 MB RAMemory /dev/hda1 = 1 GB, /dev/hdb5 = 160 MB Swap, /dev/hdb6 = 1840? MB Home or User ( When I Learn How 2 Do it ), Currently I'm Stuck w/ this
"<0>Kernel panic - not syncing: Fatal exception in interrupt" Error Message I've seen B4w/ Other Earlier & Different Puppy Breeds, But Never Understood it or been able 2 Resolve it.
I did get SimplePup 2 Run Live in RAMemory, Got on th' InterNet w/ it, had it Partially Installed / Configured, But Got Stuck w/ th' Swap File ( Wasted a Lot o' Time B4 Finally Resorting 2 Typing which Hate, PLEASE HELP!!! )

[nicom]

Does starting Puppy with nodma mean that dma will not be used at all and that all transfers will be through the cpu? If this is the case won't it slow down data transfer?