Opened 11 years ago

Closed 4 years ago

#2342 closed bug (no change required)

No system timer interrupt on some ATI chipsets

Reported by: euan Owned by: mmu_man
Priority: high Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc: mrsunshine
Blocked By: Blocking: #3579
Has a Patch: no Platform: All

Description

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.

Attachments (4)

apic.txt (2.1 KB) - added by euan 11 years ago.
snippets of linux syslog with apic=debug in boot args
listdev.txt (2.0 KB) - added by totish 8 years ago.
syslog (320.0 KB) - added by totish 8 years ago.
syslog.old (404.9 KB) - added by totish 8 years ago.

Download all attachments as: .zip

Change History (44)

comment:1 Changed 11 years ago by mmu_man

Status: newassigned

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.

Changed 11 years ago by euan

Attachment: apic.txt added

snippets of linux syslog with apic=debug in boot args

comment:2 Changed 11 years ago by mmlr

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

comment:3 Changed 11 years ago by dustin howett

Cc: mrsunshine added

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.

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by 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?

comment:6 Changed 11 years ago by 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.

comment:7 Changed 11 years ago by mrsunshine

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

comment:8 Changed 11 years ago by 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.

comment:9 Changed 11 years ago by 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.

comment:10 Changed 11 years ago by 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...

comment:11 Changed 11 years ago by euan

any advice as to how one disables the APIC timer?

comment:12 Changed 11 years ago by 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?

comment:13 Changed 11 years ago by 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.

comment:14 Changed 11 years ago by euan

no change with SMP off. :(

comment:15 Changed 11 years ago by mmu_man

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

comment:16 Changed 11 years ago by mrsunshine

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

comment:17 Changed 11 years ago by 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 =)

comment:18 Changed 11 years ago by mmu_man

Maybe APIC timers actually work on IXP ?

comment:19 Changed 11 years ago by 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

comment:20 Changed 11 years ago by mmu_man

Hopefully hrev27333 should fix it. Please test.

comment:21 Changed 11 years ago by euan

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

comment:22 Changed 11 years ago by 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.

comment:23 Changed 11 years ago by 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.

comment:24 Changed 11 years ago by 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...

comment:25 Changed 11 years ago by 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!

comment:26 Changed 10 years ago by 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.

comment:27 Changed 10 years ago by 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.

comment:28 Changed 10 years ago by 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.

comment:29 Changed 10 years ago by 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. :)

comment:30 Changed 10 years ago by 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?

comment:31 in reply to:  30 Changed 10 years ago by 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...

comment:32 Changed 10 years ago by mmlr

Blocking: 3579 added

(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...

comment:34 Changed 8 years ago by 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 41771 , gcc2 .

Last edited 8 years ago by totish (previous) (diff)

Changed 8 years ago by totish

Attachment: listdev.txt added

Changed 8 years ago by totish

Attachment: syslog added

comment:35 Changed 8 years ago by mmlr

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

Changed 8 years ago by totish

Attachment: syslog.old added

comment:36 in reply to:  35 Changed 8 years ago by 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. :-(

comment:37 Changed 8 years ago by diver

Version: R1/pre-alpha1R1/Development

comment:38 Changed 8 years ago by 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 ...

comment:39 Changed 4 years ago by 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.

comment:40 Changed 4 years ago by pulkomandy

Resolution: no change required
Status: in-progressclosed

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

Note: See TracTickets for help on using tickets.