Annoying kernel behaviour
I upgraded a fileserver to 2.4.5 because of the RAID support (the 0.90
patch I grabbed did not apply cleanly to 2.2.19, despite it being a fresh copy). Besides a nice speed increase (the EEPro now pumps 10 megs a second, instead of 2 or 3), there is a problem with the video4linux in it. The box has a bttv card hooked up to a camera. Under 2.2.19, Apache had mod_video installed, which would produce a jpeg of the composite in on the card (a cheapy CCD camera is hooked up). Upon insmoding:
Module Size Used by
bttv 55184 0 (unused) videodev 4864 2 [bttv] i2c-algo-bit 7712 1 [bttv] i2c-dev 3904 0 (unused) i2c-core 12656 0 [bttv i2c-algo-bit i2c-dev]
and accesing mod_video, the box locked up hard (not even sysrq worked). And when I rebooted, I found that some files is /etc were eaten -- even though that partition is mounted with the sync option, and even though it'd had a good 2-5 seconds the write the ~10k data file.
So why does bttv lock the box, and why does sync not sync? I don't feel like converting ~80gb to some other FS than ext2 just yet.
PS: I can't give an Oops because the DPMS mode on the console was on, and it won't return when it locks up (perhaps turn on monitor as part of Oops handling?). Assuming there even was an oops.
PPS: Please CC me since I'm not on the list.
--
www.kuro5hin.org -- technology and culture, from the trenches.
Quoted 1 line · Colonel
Look in the people/mingo directory for a patch
The patch did not work.
Quoted 12 lines
I have:
Linux video capture interface: v1.00
bttv: driver version 0.7.63 loaded
bttv: using 2 buffers with 2080k (4160k total) for capture
bttv: Host bridge needs ETBF enabled.
bttv: Bt8xx card found (0).
bttv0: Bt878 (rev 2) at 00:0b.0, irq: 10, latency: 32, memory:0xe3000000
bttv0: subsystem: 144f:3000 => TView 99 (CPH063) => card=38
bttv0: model: BT878(TView99 CPH063) [autodetected]
bttv0: enabling ETBF (430FX/VP3 compatibilty)
i2c-core.o: adapter bt848 #0 registered as adapter 0.
Linux video capture interface: v1.00
bttv: driver version 0.7.57 loaded
bttv: using 2 buffers with 2080k (4160k total) for capture
bttv: Bt8xx card found (0).
bttv0: Bt848 (rev 18) at 00:0f.0, irq: 10, latency: 64, memory: 0xd79ff000
bttv0: model: BT848A( *** UNKNOWN *** ) [autodetected] i2c-dev.o: Registered 'bt848 #0' as minor 0
i2c-core.o: adapter bt848 #0 registered as adapter 0.
** ^^ this worked in 2.2.19 as
bttv0: Brooktree Bt848 (rev 18) bus: 0, devfn: 88, irq: 11, memory:0xe4102000.
bttv: 1 Bt8xx card(s) found.
bttv0: NO fader chip: TEA6300
bttv0: model: BT848(Miro)
Sigh.. I'll try the update.
Quoted 9 lines
Bttv-0.7.63-2.4.3.patch.bz2
from the website. Video4linux has always worked in the various 2.4 kernels I've tried.
Quoted 1 line
and accesing
mod_video, the box locked up hard (not even sysrq worked). AndI don't run
mod_video, but xawtv works fine. Did you try that or rebuildingmod_video?
It shouldn't matter, as userspace programs should not be able te fuck te kernel over in such a complete instant deadlock. There is something seriously rotten with video4linux or the driver if my little userspace app can take out machines with no warnings and no error messages on conesole/in logs.
Recompiling didn't affect it, either.
Quoted 3 lines
Quoted 1 line
when I rebooted, I found that some files is /etc were eaten -- even though
You must have grues.
No, the sync writes seem broken in 2.4.5. That is very bad.
--
www.kuro5hin.org -- technology and culture, from the trenches.
Quoted 3 lines · Colonel
Ah, notice that the IRQ shifted? Perhaps there is something else on irq 10, such as the SCSI controller? My video cards always end up on that IRQ, perhaps the computer is still accessible via the network?
I would expect the IRQ to shift as the system has a different motherboard/processor than it did in December.
CPU0
0: 3208074 XT-PIC timer 1: 2 XT-PIC keyboard 2: 0 XT-PIC cascade 10: 1 XT-PIC bttv 12: 10444 XT-PIC eth0 14: 12366 XT-PIC ide0 15: 67 XT-PIC ide1 NMI: 0 ERR: 0
There are no conflicts, and PCI should be able to share anyways.
That machine, being a server, is only accesible via the network. And when all my SSH sessions to it died, and the pings weren't pinging, I went over to the server corner, attached a monitor to the machaine and tried the magic sysrq on the keyboard after verifying that I couldn't get a local response. As I said, I can easily lock an entire system in a way that corrupts files even on a synchronuslly mounted partition from userland with no warning, no error messages.
Waht part of this do you fail to grasp?
--
www.kuro5hin.org -- technology and culture, from the trenches.
Quoted 6 lines
Quoted 1 line
There are no conflicts, and PCI should be able to share anyways.
That's the theory now for some time, has never worked. Even hacking the SCSI driver, any attempted IRQ sharing kills my systems. Even my quad ethernet is not successful at sharing IRQs with itself, in 2+ very different motherboards.
For bttv I know that irq sharing works in some cases and not on others. Last not-working report was bttv sharing with a nvidia. Moving the grabber board to another PCI slot (nvidia having a exclusive irq then, bttv shared the irq with something else) fixed it.
Gerd
Signature · 1 line
Damn lot people confuse usability and eye-candy.