Annoying kernel behaviour

Annoying kernel behaviour

[Dylan Griffiths]

	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.

Re: Annoying kernel behaviour

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>	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).

Look in the people/mingo directory for a patch

>  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:

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.

 working in 2.4.5-ac12 SMP+RAID.  I used

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.


>and accesing mod_video, the box locked up hard (not even sysrq worked).  And

I don't run mod_video, but xawtv works fine.  Did you try that or
rebuilding mod_video?


>when I rebooted, I found that some files is /etc were eaten -- even though

You must have grues.


-- 
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

ditto

Re: Annoying kernel behaviour

[Dylan Griffiths]

Colonel wrote:
> Look in the people/mingo directory for a patch

The patch did not work.
 
> 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.
 
> 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.
> 
> >and accesing mod_video, the box locked up hard (not even sysrq worked).  And
> 
> I don't run mod_video, but xawtv works fine.  Did you try that or
> rebuilding mod_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.

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

Re: Annoying kernel behaviour

[Colonel]

In clouddancer.list.kernel, you wrote:


>bttv0: Bt848 (rev 18) at 00:0f.0, irq: 10, latency: 64, memory: 0xd79ff000

> ** ^^ this worked in 2.2.19 as 
>bttv0: Brooktree Bt848 (rev 18) bus: 0, devfn: 88, irq: 11, memory:
>
>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


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?



-- 
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

ditto

Re: Annoying kernel behaviour

[Dylan Griffiths]

Colonel wrote:
> 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.

Re: Annoying kernel behaviour

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>Colonel wrote:
>> 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.
>
>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.


>Waht part of this do you fail to grasp?

Hehe.  The only reason you got a reply from me was that I run
video4linux with 2.4 kernels without a problem (or at least I think I
do, there are some problems but never when using xawtv).
Additionally, I've run the new RAID since the initrd period and
mingo's patches have never failed.  Any problems with RAID mentioned
on the mailing list were always traced to user error.  In short, what
you were trying to run worked fine here.

Replies afterwards were merely some guesses based on the
information you supplied.  Such as: try pulling out some hardware and
seeing if that helps.  You need to troubleshoot down to something
repeatable in order to get additional help.



-- 
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

ditto

Re: Annoying kernel behaviour

[Gerd Knorr]

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

-- 
Damn lot people confuse usability and eye-candy.