wolfwings

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

Flat | Top-Level Comments Only

From:

wolfwings.livejournal.com

I don't have a video driver installed yet. It's running VESA frame-buffer or straight VGA-text-console.

I don't have a sound-card driver installed yet at all. Not even a PC Speaker Beep.

I don't have any bluetooth devices paired yet. And not loading the driver didn't help.

I didn't have any Secure Digital cards loaded. And not loading the driver didn't help.

It's the System CPU Percentage under Linux that spikes when the wireless card is active with the driver loaded. And when it's that highly loaded I can't even SSH in from another box to examing the kernel. I only know it's the System CPU Percentage because I left a script jotting down the results from various /proc entries as fast as possible and left the machine sit for 20 minutes before using the physical kill-switch on the 802.11 card that frees up the system again.

And this only happened when I applied a BIOS patch to fix a clock-skew error that was happening with my laptop, and the patch did fix that error. So I'm guessing it's related.

aerowolf.livejournal.com

Hmm. If you can recompile the kernel with DEBUG, then there's a directory in /proc that contains a bunch of information (such as number of hardware interrupts, number of non-maskable interrupts, and so on).

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

Problem...

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.

Most likely will.

What's the 802.11 chipset?

Broadcom Airforce One 802.11g

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. =^.^=

Well damn... that sucked.

None of the above applies in this case.

Re: None of the above applies in this case.

Re: None of the above applies in this case.

Re: None of the above applies in this case.

Re: None of the above applies in this case.

Style Credit

Profile