Well damn... that sucked.
Feb. 14th, 2006 07:07 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
wolfwingsLinux Kernel 2.6.15...
Flash Reader works. Beautifully.
Bluetooth works. Beautifully.
Loading the 802.11 driver via ndiswrapper?
*CHUG*
The system suddenly is under such high system load I was watching individual lines of the screen get redrawn. Pixel by pixel.
Trying earlier kernels and earlier ndiswrapper versions didn't seem to change the behaviour.
So... I've apparently found an interesting... bug. And unfortunately one I couldn't debug... honest, I tried, but I couldn't figure out the first step towards trying to diagnose where this was bogging down.
And the kicker?
It's apparently a side-effect of upgrading the BIOS on my laptop to fix a clock-skew error I was running into. Joygasm.
So... for now I dumped a quick install of Windows on the boxen again for the moment. There's some wierd interaction between the clock-skew BIOS fix that was recently released, and 2.6.15 in combination with the SDHCI patch and ndiswrapper that causes no errors, but puts the system under such high load (I'm guessing interrupt load) that it can't even get enough time to redraw the screen fully.
Flash Reader works. Beautifully.
Bluetooth works. Beautifully.
Loading the 802.11 driver via ndiswrapper?
*CHUG*
The system suddenly is under such high system load I was watching individual lines of the screen get redrawn. Pixel by pixel.
Trying earlier kernels and earlier ndiswrapper versions didn't seem to change the behaviour.
So... I've apparently found an interesting... bug. And unfortunately one I couldn't debug... honest, I tried, but I couldn't figure out the first step towards trying to diagnose where this was bogging down.
And the kicker?
It's apparently a side-effect of upgrading the BIOS on my laptop to fix a clock-skew error I was running into. Joygasm.
So... for now I dumped a quick install of Windows on the boxen again for the moment. There's some wierd interaction between the clock-skew BIOS fix that was recently released, and 2.6.15 in combination with the SDHCI patch and ndiswrapper that causes no errors, but puts the system under such high load (I'm guessing interrupt load) that it can't even get enough time to redraw the screen fully.
Re: None of the above applies in this case.
Date: 2006-02-15 08:04 am (UTC)You could also try putting printk()s into both the 802.11 driver and the clock driver to see what's going on. (My guess is that the 802.11 driver is using the system clock to determine its timing, and the clock driver is getting confused by the constant querying.)
Re: None of the above applies in this case.
Date: 2006-02-15 08:34 pm (UTC)The vast majority of the 802.11 driver is a black-box binary-only Windows driver. It's one of the few things nobody's reverse-engineered a driver for, because it works so well through ndiswrapper.
Hell, I even made a kernel set to maximally pre-emptable, even throwing the 'Preempt the Big Kernel Lock' option on. System was still bogged down to the point the keyboard was unresponsive most of the time.
I'll try it again today, and see if I can get it working with some of the other clock-drivers possibly even if I have to switch off CPU frequency scaling for now for some of them, and try to get some debugging info with your ideas. Those are ones I hadn't tried. Time for a suicide-install of Gentoo. =^.^=
Sorely tempted to call you and discuss this remotely if you have the time later tonight.
Re: None of the above applies in this case.
Date: 2006-02-16 01:20 am (UTC)What's the 802.11 chipset?
Re: None of the above applies in this case.
Date: 2006-02-16 02:17 am (UTC)Yup, Broadcom. Masters of the concealed and unknown with drivers that are the original (and still current) focus of the ndiswrapper project, so they usually work flawlessly. =^.^=