unhandled IRQ 39 + graphics failure on real hardware

[uityyy]

Are you at all interested in usage reports from real hardware at this point? If so I can debug this farther.

I Booted on ISO in real hardware just for kicks, and got successfully to he shell, but "unhandled IRQ 39" scrolls across screen except when modifier key is held down, and startx and other graphics commands give a general protection fault and reboot the machine.

If you're interested in knowing what's failing, the obvious next step would be for me check whether disconnecting expansion cards or changing BIOS settings changes the behavior

Hardware:
CPU: Early x86-64 (AMD, single core I think)
Motherboard: GeForce6100SM-M or similar with both PCI and PCIe
BIOS: Phoenix - Award WorkstationBIOS v6.00
Video BIOS: 982B GeForce 8400GS VGA BIOS 2725 Version 62.98.29.00.00
Memory: 4GB
Disks: 1m: IDE DVD, 1s: HDD, 3m: SATA HDD 4m: SATA DVD, fdd0: 1.44M
Keyboard and mouse: PS/2.
Expansion cards: PCI Soundcard; PCI wi-fi card; PCIe eSATA card
Motherboard: USB, serial, parallel, LAN, sound. and disabled video on motherboard.

Error:

   [ERROR General protection fault]
   [ERROR Selector error code 0x00000000 interpreted below]
   [ERROR Exception occurred inside processor]
   [INFO Selector index follows]

   ================== registers ================
   eax: 0x80000010      ecx: 0x00000000  edx: 0xc0016260  ebx: 0xc000bfab
   esp: 0x00007bd2      ebp: 0xdfffff00  esi: 0xdffffef4  edi: 0x00007c00
   eip: 0x00007c3d      int: 0x0000000d  err: 0x00000000  cs:  0x00000018
   useresp: 0x0000dead  ss:  0xff000000  efl: 0x00010002
   gs:  0x00000020      fs:  0x00000020  es:  0x00000020  ds:  0x00000020
   [INFO PID 7 encountered unrecoverable fault, killing...]

(and then in a few seconds the machine resets)

[codyd51]

I'm extremely interested in getting axle running properly on real hardware. Thank you for your detailed bug report! This is exactly what I hope to see when people decide to report bugs. Kudos.

I'm not sure what causes IRQ 39 to be thrown, though you are the second user to report this on real hardware. I'm guessing I'm mapping IRQ's wrong, but more investigation is needed. I'm going to leave this issue open for now.

As far as VESA code failing on real hardware, this is not (entirely) unexpected, though it is disappointing; VESA support is largely a hack at the moment and the code quality is not up to par with what I would hope for. I do wish Bochs VBE extensions were available on real hardware. I was playing with that a few days ago, and it made it dead-simple to set an arbitrary resolution.

I might attempt to switch VESA to use bank-switching, as then I won't have to worry about mapping the entire LFB. As a slightly unrelated subnote, it seems the heap is overwriting the VESA framebuffer when it expands too large, though I may be misinterpreting that bug.

[codyd51]

I'm curious: do the commands gfxtest or rexle vga cause the same issue with triple faulting? Those two would use VGA graphics as opposed to VESA, so hopefully the bug is isolated to VESA code and those would work.

[uityyy]

No, rexle vga also fails, and I've verified that it happens with my motherboard video too.

Similar registers but
useresp: 0x00000004
ebp: 0xdffffb10
edx: 0xdffff7d1
esi: 0xdffff7d2
ebx: 0xc000bfaa

[uityyy]

I also verified that the IRQ wasn't coming from an expansion card or removable USB device (or apparently the PS/2 mouse). I didn't rule out all disks because I was booting from one, but it does still occur when only the IDE DVD drive or only the SATA DVD drive is plugged in. I also haven't investigated possible BIOS settings that could affect it.

[codyd51]

Interesting. Does the spurious IRQ message occur at regular intervals, or is there any recognizable pattern for when it shows up? It could be the RTC being wired differently on real hardware. If the IRQ appears every second, that'd be a likely candidate.

I've implemented VBE into this build. Would you mind trying it and see if it sets a graphics mode? It should just be a 1024x768 blue screen. axle.iso.zip

I'm curious, how are you deploying to a real machine? There's one other person who's done that, and I never asked what he did.

[uityyy]

Ok. That iso link did not work.

To boot before, I just burned the v0.5 ISO to a CD and booted, and it started with no hassle -- even worked with both my IDE and my SATA DVD drive. :) I have GRUB on my machine, so I should be able to easily wire it to load the kernel and initrd from the hard disk for more frequent upgrading unless there is some GRUB 1/GRUB 2 incompatibility with the format. (I've seen that with one other system which also, coincidentally had problems with my machine's video.)

The IRQ seems to get reported in spurts of a variable number at a time a variable number of seconds apart (~0.5-8, typically filling the screen within 10 seconds). I checked that it didn't seem affected by whether I whether I turned the High Precision Event Timer on or off in the BIOS.

[codyd51]

Mind giving this link a shot? https://www.dropbox.com/s/ecwbnapissdlbcs/axle.iso?dl=0

Cool, good to know! axle's ramdisk is loaded as a GRUB2 module IIRC, so there may not be a working FS with GRUB1.

Damn. I'll have to take another look at IDT code, I don't know what the cause of that could be. I don't think HPET should have any impact, as axle doesn't have an HPET driver. As far as timing, axle has an RTC and PIT driver.

[uityyy]

Ok:
[AXLE OS v0.6.0]
[INFO Testing colors...]
@@@@@@@@@@@@@@@@
[INFO Available memory:]
3143552 -> 3069MB
[INFO Installing GDT...]
[INFO Installing IDT...]
[INFO Testing interrupts...]
[ERROR Unhandled ISR: 3]
[INFO Initializing serial driver...]
[INFO Initializing PIT driver...]
[INFO Initializing serial driver...]
[INFO Detected 1 GRUB modules]
[INFO Initializing paging...]
[INFO finished identity mapping kernel pages]
[DEBUG unhandled IRQ 39]
[INFO Initializing syscalls...]
[INFO Initializing tasking...]
[DEBUG unhandled IRQ 39]
[INFO Tasking initialized with kernel PID 1]
[INFO Initializing keyboard driver...]
[DEBUG unhandled IRQ 44]
[DEBUG unhandled IRQ 44]
[INFO Registering pci devices...]
[DEBUG unhandled IRQ 39]
[DEBUG unhandled IRQ 39]
...
[[[introductory help message, more unhandled IRQ 39 and me typing the startx or rexle command]
...
[INFO Press any key when ready]
[DEBUG unhandled IRQ 39]
[DEBUG unhandled IRQ 39]
...
[DEBUG unhandled IRQ 39]
[DEBUG General protection fault]
[[[ as we are familiar with]]]

(PS: This is substantially better than Aprom OS which hangs when it goes into graphics mode and does so so thoroughly that I must unplug, not just power down the machine in order for the video card to initialize on next boot.)

[codyd51]

I've been working on a substantial change to axle's outputting today: instead of booting to text mode and using (admittedly hacky) code to switch to VESA mode when necessary, axle will now attempt to use GRUB to boot directly into 1024x768x24 (or the nearest supported resolution).

This ISO should be considered very early alpha quality, I just want to ensure that the graphics mode is set correctly on real hardware before integrating this upstream. All debug boot info/shell interface should now be output in this high resolution graphics mode. With this version, you shouldn't expect anything which changes graphics mode, such as rexle or startx, to function properly.
axle.iso.zip

[uityyy]

That switches graphics modes after the "BOOTING AXLE" message and immediately freezes with an interesting pattern of whitish pixels in the upper-right-hand corner of the screen that seems to be about the same each time I boot (it also looked the same when I tried with an older Pentium 4).

[codyd51]

I'm guessing that means your computer wasn't able to set the graphics mode axle requested, especially considering you say the pattern is consistent. Sounds like a rendering bug.

Sorry for having you try out all these broken ISOs, I'm hoping this should work. This version requests 640x480x32bpp, which is the fallback resolution that all VGA cards should be able to support.

That build also includes some nicer font rendering which automatically scales size/padding based on boot resolution.

[uityyy]

Sorry for the delayed response. I was pretty busy yesterday.

I am now booting Axle OS from the GRUB 2 already on my hard disk to save CDs when not debugging CD-boot specific things. For the previous revision this yielded the same result as booting from CD. For this revision I presume it does but haven't checked.

There's good news and bad news: The good news is that the latest build boots up and accepts commands on my system. The bad news is that it looks like something is wrong with how video memory is being accessed. The monitor reports that it is in 640x480, but Axle is writing over and over to parts of the first two and a bit rows of text with different offsets rather than using the whole screen properly.

http://i.imgur.com/wp9ZDYu.jpg

[uityyy]

I'm fairly certain there's a bits-per-pixel issue here. When I boot the ISO in VirtualBox it says it's running in the standard 640x480x4, not 640x480x32, but when I boot on my actual hardware early on I see a few junk pixels that are pretty clearly not on the 16-color (4bpp) palette.

[codyd51]

Sorry for being so late responding to this; my semester just began.

Huh, I could've sworn I read 640x480x32 was default. GRUB won't even boot to 640x480x4 for me, falling back to 640x480x32 when I give it an invalid resolution (QEMU). I'll change things so axle should do reasonable stuff with 4bits/pixel.

Thanks again for your help debugging!

[uityyy]

It was my pleasure. Let me know when I should do it some more. :)

[codyd51]

Hey!

I'm not completely convinced this is a 4bit color palette, as in your screenshot the colors show up correctly, and those are rendered by axle with 32bits/px.

Writing this out, I'm starting to think (assuming it does boot into 640x480x4 bit) that gfx_bpp is getting rounded down to 0, causing all those weird rendering/overlap issues as stuff is being drawn at the right place. That still doesn't explain why colors are showing up correctly, though.

I'm still not able to get VirtualBox to boot into 4 bits per pixel; however, 4 bytes per pixel (shown by axle as 640x480x32) works fine. Can you confirm that you're booting in VB with 4bits/px?

[uityyy]

I'm not seeing that text in VirtualBox today, but I just ran Axle on qemu on linux, which also resulted in overlapping text on my system, and I observed the following in the overlapping text:
640 x 480 x 3
size is 8x8,

That does appear to be 3 with a blanked cell after it, not 32 with the end overwritten.

[codyd51]

Ah, I think I see what's happening there; I just ran that version of axle in qemu on linux, and it seems that build reports resolution in bytes/pixel rather than bits/pixel. So that'd be 640x480x24. I'm not getting any overlapping text on my end; what's your host's native resolution?

[coolstar]

Just a heads up regarding the IRQ's, if you have Windows installed on your machine, you can use "msinfo32" to get a list of IRQ's and the hardware they're assigned to.

Example:

[codyd51]

Oh, good to know. I wonder what's causing that spurious IRQ 39. Bad IDT mappings, maybe?

[coolstar]

what's assigned to IRQ 39 will vary depending on the motherboard and connected devices

[codyd51]

wiki.osdev.org shows this table for x86 PIC lines:

• Standard ISA IRQs
  IRQ Description
• 0 Programmable Interrupt Timer Interrupt
• 1 Keyboard Interrupt
• 2 Cascade (used internally by the two PICs. never raised)
• 3 COM2 (if enabled)
• 4 COM1 (if enabled)
• 5 LPT2 (if enabled)
• 6 Floppy Disk
• 7 LPT1 / Unreliable "spurious" interrupt (usually)
• 8 CMOS real-time clock (if enabled)
• 9 Free for peripherals / legacy SCSI / NIC
• 10 Free for peripherals / SCSI / NIC
• 11 Free for peripherals / SCSI / NIC
• 12 PS2 Mouse
• 13 FPU / Coprocessor / Inter-processor
• 14 Primary ATA Hard Disk
• 15 Secondary ATA Hard Disk

In axle's kernel, the hardware int lines are mapped to interrupt vectors as + 32. This makes ISR #39 = IRQ 7, which that table lists as spurious.

I'll update with a commit to ignore that interrupt. It's nice to have closure on this bug!