AMD Mobile Athlon 64 VERY slow on 6-STABLE and 7-CURRENT

Miguel Ramos miguel at anjos.strangled.net
Thu Feb 16 05:12:04 PST 2006


Qua, 2006-02-15 às 21:11 +0100, Gianmarco Giovannelli escreveu:
> At 16.54 14/02/2006, Miguel Ramos wrote:
> 
>  >> Check with vmstat -i to see if you have an interrupt storm of
>  >> some sort.
>  >>
>  >> 	David.
>  >
>  >It is on irq11 (devices cbb0, cardbus and ohci0++, whatever ++ is).
>  >53000 interrupts per second... That might just slow down even an Athlon
>  >64.
>  >I'm going to disable cardbus first and then ohci. Isn't there a specific
>  >command to keep an interrupt source quiet?
> 
> Also I have the same problem with 6.0-stable and 6.1-pre on a intel 
> centrino HP dv1000.
> Interrupt storm on irq11 and cbb0. I have to remove from kernel to 
> let the laptop work.
> 
> Any idea why it happens ? Bogus hardware ?

Or bogus software, your laptop is a centrino, and mine an amd64, very
different.

Actually my problem is with ehci, if I compile GENERIC commenting just
the line that says "device ehci", then everything works.
I tried to disable all suspects, usb, cardbus and firewire, one at a
time...

Qua, 2006-02-15 às 10:00 +1030, Daniel O'Connor escreveu: 
> Might help if you sent a verbose boot dmesg and a copy of your kernel config 
> (unless you're running GENERIC)
> 
> Are you using i386 or amd64?
> What is the output of sysctl kern.timecounter and hw.acpi?

This happens on both i386 and amd64, all generic kernels of 6.0-RELEASE, 6.1-BETA1, 6-STABLE and 7-CURRENT, but not on 5-STABLE, ehci is disabled on 5-STABLE and that explains it.
Everything is right with kern.timecounter and acpi is disabled. I've kept a copy of a verbose boot dmesg for the ehci people.

----

So, now I know what doesn't work with my hardware. My questions for you is:

- Don't you think that this is the effect of two problems? That one problem is the fact that ehci doesn't work with my hardware and causes an interrupt storm (ok, that's not critical), and another problem is the fact that interrupt storm protection in the kernel didn't work (see /usr/src/sys/kern/kern_intr.c) ... it should have slowed it down to service only one such interrupt per clock tick... this one is quite critical...
- Should I send two PRs ? Should I send it first to freebsd-bugs? What is the correct procedure for reporting this?

Thank you all for your helpful comments. I think this is my last message on this thread.

Miguel




More information about the freebsd-stable mailing list