No system timer interrupt on some ATI chipsets

[euan]

It seems like some motherboards with ATI chipsets don't route IRQs normally through the PIT. My HP laptop stalls unless I press keys or move the mouse to generate interrupts.

Laptop is HP6715b (ATI Xpress 1250) My Desktop with Asus A8R-MVP mobo is also affected. (ATI CrossFire™ Xpress 1600 chipset)

Linux prints the following clues:

ATI board detected. Disabling timer routing over 8254.

[mmu_man]

Yes I had to work around it in Zeta on my ATI IXP-based laptop. Changing the edge-level trigger register seemed to work in Zeta but I couldn't get Haiku to cold boot yet.

[euan]

snippets of linux syslog with apic=debug in boot args

[mmlr]

See also #2369 that is a duplicate of this and contains additional attachments.

[dustin howett]

Could this be something to be put in the isa/pit timer module, once Stefano commits it? If so, I could handle that. If anything, i'd hold off on changing it because the x86 timer system is going to change drastically :) Adding "mrsunshine" to the cc list so he gets updates on this bug, since his was marked duplicate and this seems important to him.

[euan]

Just a note to say the HP no longer boots at all, and hangs at the same place that ticket #2369 seems to suggest. Will report back if the same change affects my laptop.

In the smp kernel file I also tried enabling the disabled virtual wire code, but it made no difference.

[axeld]

This doesn't belong to the timer code, but the interrupt setup. In fact, I tried setting up the edge/trigger registers (see x86/arch_int.c, line 231), but as it didn't seem to have any effect on modern hardware, I commented it out.

Maybe we should just change that, but I find it a bit strange that writing a 1 helped in 0x4d0, as that sets almost everything to edge triggered interrupts (while level is what we would want to have), but just not the timer interrupt. So using 0xf9 should to the trick as well -- can you check that, mrsunshine?

Euan, can you check that for your board as well?

[mmlr]

By the way it doesn't surprise me at all that the system now hangs at boot. It seems that certain VIA and ATI EHCI controllers do lose interrupts and if this is the case with the hardware at hand, it is easily possible that queued transfers (when starting up and enumerating EHCI for example) do hang and never return (even if there is in fact no acknowledge from the device, they should just time out in the controller and be reported back as TD errors). If these controllers are actually still in use and losing the interrupts is not related to the cause of this bug, then I will look into also implementing such a workaround.

[mrsunshine]

"outb 0x4d0 0xf9" works just as well =)

[mmu_man]

The fix I used in Zeta back then was like: out8(in8(PIC_MASTER_TRIGGER_MODE) | 0x01, PIC_MASTER_TRIGGER_MODE);

Also, in Haiku one must also disable APIC timer as well, else this doesn't work as it uses a different IRQ.

[euan]

I tried all the suggestions above last night, as well as 0xf8 and 0x01, and even applying change to SLAVE_TRIGGER_MODE too just for kicks. The outcome is the same in all cases. Additionally I removed USB which gets me past the USB init block, but the boot fails later on with either DMA or PIO timeouts on the harddisk depending on whether I try ide or ata bus component.

[mmu_man]

I repeat, APIC timer must be disabled. Oddly I never had any other problem than the clock in Zeta, which was fixed this way...

[euan]

any advice as to how one disables the APIC timer?

[euan]

i tested with the hrev26265 changes. still no change. Is there anything I can do to recommend / override the timer used? Any specific debug that could be enabled?

[dustin howett]

Turning off SMP in the boot menu should disable the APIC timer. Of course, that's not an optimal solution, if you need/want SMP.

[euan]

no change with SMP off. :(

[mmu_man]

As I said I have a fix pending, but I need to clean it up, please be patient.

[mrsunshine]

Still not working even after the timer split and APIC timer removed from sTimers... =)

[mrsunshine]

Well, removed the whole kernel tree, updated it and now haiku boots, just takes some time for it to do it but it actualy boots without trouble, no more outb 0x4d0 1 etc =)

[mmu_man]

Maybe APIC timers actually work on IXP ?

[euan]

I would suspect that the timer is still broken, it's just that other hardware devices are regularly generating interrupts. At least that's how my system seemed to respond about 6 months ago. It was only with other kernel changes, and IDE changes that it stopped booting. The main clue was that when you say clicked shutdown the dialog box would only appear after the mouse was moved, or a key pressed.

I might try rebuilding the tree anyways.

After hope, there's always desperation... :D

[mmu_man]

Hopefully hrev27333 should fix it. Please test.

[euan]

Should get a chance to test this sometime over the next couple of days. Many thanks.

[Minoru-kun]

Booting on my laptop with ATI IXP still fails reporting an error (in debug mode) like this:

usb_ohci: successfully started the controller.
usb_ehci: the host controller is bios-owned
usb_ehci: claiming ownership of the host controller
usb_ehci: controller is still bios-owned, waiting
Last message repeated 19 times
usb_ehci: successfully started the controller
USB ControlPipe: timeout waiting for queued request to complete
USB ControlPipe: timeout waiting for queued request to complete
usb_ehci: qtd (0x02ab7680) error: 0x00080248
USB ControlPipe: timeout waiting for queued request to complete
usb_ehci: qtd (0x02ab7680) error: 0x00080248
USB BusManager: error while setting device address
usb_ehci: lowspeed device connected, giving up
get_boot_partitions(): boot volume message:
<...>

(I've already reported this problem in #2083).

But Linux works fine.

[euan]

Hi.

Sorry about delay. Tried it about 6 days ago, haiku booted much farther than usual, however IDE DMA errors were as frequent as usual, but the booting persisted, eventually it stopped and the desktop never appeared (was booting to vesa). Can't get syslog either unfortunately.

I'll try again today with ATA driver instead of ide.

[mmu_man]

Well in any case it seems the clock issue is fixed. Maybe the IDE IRQ would also need changing the edge/level trigger register...

[euan]

It's certainly an improvement. I guess I can tinker around with IRQ settings. I still have my ATI chipset desktop to try. Hopefully it will fare better. Thanks for taking the time to try and fix it. It is 100% appreciated!

[euan]

Still having problems with my HP 6715b laptop. Found the following info regarding linux that might shed some light on the evil details of this laptop:

​http://bugzilla.kernel.org/show_bug.cgi?id=11715#c11 ​http://www.nabble.com/-PATCH--x86:-remove-superfluous-dmi_ignore_irq0_timer_override-quirks-td20011385.html

Is the above bios issue something of interest to Haiku's setup? This info was in the linux DMI quirks file (2nd link):

HP laptops which use a DSDT reporting as HP/SB400/10000, which includes some code which overrides all temperature trip points to 16C if the INTIN2 input of the I/O APIC is enabled. This input is incorrectly designated the ISA IRQ 0 via an interrupt source override even though it is wired to the output of the master 8259A and INTIN0 is not connected at all. Force ignoring BIOS IRQ0 pin2 override in that cases.

Applies to the SB600 chipset too apparently.

[tqh]

I think Euan wants something like this: ​http://fxr.watson.org/fxr/source/amd64/acpica/madt.c#L591 which seems to be the handling of the timer interrupt in FreeBSD for this case.

Also, but I guess you already know: The Linux code in drivers/pci/quirks.c has quite a lot of info which is probably useful to get things working. A quick look at FreeBSD's ​http://fxr.watson.org/fxr/source/dev/acpica/acpi_quirks might also be worth a look.

[mmlr]

We don't use the IO-APIC at all yet. Also we do not use ACPI to get the interrupt routing, that's basically what is missing to make the IO-APIC usable. So what we see here is certainly not ACPI related. It's well possible that after the IO-APIC is in use we'll have to deal with those quirks, but for now it's sadly not going to help.

[euan]

What could the problem be, surely it must be something related as the hardware is clearly broken. If the bios is lying about IRQ setup, perhaps it can only work if the bios is overridden in the first place?

Using the USB boot method the boot hangs at detecting OHCI hardware. If I press fn-f3 then fn-F4 (suspend and then LCD/VGA) it seems to give it a kick and it dumps some more lines until waiting for another kick. Boot fails when no boot partitions are found, probably due to timeout failures in the USB disk module.

I'd love to dump my pc and laptop, but a shiny new sony laptop with Intel chip and Ati graphics are expensive these days. :)

[tqh]

mmu_man, shouldn't the ati_fixup_ixp() in our pci_fixup.cpp loose the INTEL #ifdef as it seems to exist for AMD as well. Is the #ifdef needed at all?

[umccullough]

Replying to tqh:

mmu_man, shouldn't the ati_fixup_ixp() in our pci_fixup.cpp loose the INTEL #ifdef as it seems to exist for AMD as well. Is the #ifdef needed at all?

I'm pretty certain that INTEL just represents x86 as opposed to PPC - it should be set by the compiler anyhow...

[mmlr]

(In #3579) Yup, that's the one. Sadly it seems that with going IO APIC we'll just run into the next quirks. These are hardware/BIOS bugs btw. so nothing we can do much about except for working around them...

[tqh]

This might be worth checking: ​http://fxr.watson.org/fxr/source/i386/pci/pci_cfgreg.c?im=bigexcerpts#L592

[totish]

Hi! I have the same problems with my Toshiba Satellite L30-134(chipset - RADEON XPRESS 200M).

1-- I can booted haiku in Live-CD mode only and in fail-safe video mode,haiku don't see sata hdd drive.

2--on hdd installed Windows XP and Xubuntu 11.04 , in linux I succesfully build haiku on partition of sata hdd, add it to Grub menu, but haiku_loader don't find any booting partition.

3-- revision 41946.

[mmlr]

That syslog is useless sadly as it only contains debug spam from wifi scanning.

[totish]

Replying to mmlr:

That syslog is useless sadly as it only contains debug spam from wifi scanning.

Oh! It's my mistake.Infirmation about booting of Haiku is in syslog.old.

I saved it after succesfully loaded from Live-CD. Syslog saved during the work of system. My english is not perfect. :-(

[MrSunshine]

Sorry to report that the computer in question for my part is broken, found it but it does not start :/ So no more information from me ...

[euan]

I would suggest closing this ticket. The ati chipsets weren't exactly mainstream and are pretty much obsolete now. Most of the bugs were caused by dodgy chipsets, and lack of modern timer support. I don't own any of the effected hardware anymore either.

[pulkomandy]

Ok, closing for now. If anyone still has a machine with this problem, please comment here and we'll reopen.