Hello,
I have spend lots of time to find why my computer keep crashing (hard).
I was having a PIII@450 (don't remember the MB), then a PIV@2200 with a
MSI Max2-BLR motherboard, and now I have an amd64@3000 on an MSI Neo
K8T.
The gfx card with the PIII was a Matrox G400 and as it wasn't compatible
with the PIV I changed it for a Matrox G550.
I use DVB with VDR, but I can do the crash all the time without VDR, all
I have to do is to have xawtv running and having a process that write
fast enough data to an HD (I tested xfs, reiserfs, ext2 and ext3 with
same result). If I don't have xawtv running I can't make crashing my
system which is rock stable :-)
I have tried to put my palm on serial to see if I could grab anything
about the crash with appending
nmi_watchdog=1 console=ttyS0,57600 console=tty0
or with nmi_watchdog=2 but I don't receive anything.
The first problem appeared on my 2.2 kernels, and I have the same with
2.6.9 which I put under http://magma.epfl.ch/greg/linux/2.6.9-config
Please CC to me as I am not on this mailing list.
--
Gr?goire Favre
________________________________________________________________________
http://magma.epfl.ch/greg ICQ:16624071 mailto:[email protected]
Gregoire Favre wrote:
> I use DVB with VDR, but I can do the crash all the time without VDR, all
> I have to do is to have xawtv running and having a process that write
> fast enough data to an HD (I tested xfs, reiserfs, ext2 and ext3 with
> same result). If I don't have xawtv running I can't make crashing my
> system which is rock stable :-)
Is xawtv running as root or with real time privileges? That could do it.
Cheers,
Con
On Mon, Nov 08, 2004 at 10:53:46AM +1100, Con Kolivas wrote:
Hello again :-)
> Gregoire Favre wrote:
> >I use DVB with VDR, but I can do the crash all the time without VDR, all
> >I have to do is to have xawtv running and having a process that write
> >fast enough data to an HD (I tested xfs, reiserfs, ext2 and ext3 with
> >same result). If I don't have xawtv running I can't make crashing my
> >system which is rock stable :-)
>
> Is xawtv running as root or with real time privileges? That could do it.
Normally I start xawtv this way:
xawtv -c /dev/v4l/video0 -geometry 770x580-0-0 -xvport 61 & as a normal
user, but I don't know what real time privileges are ?
I haven't modified in any way xawtv :
-rwxr-xr-x 1 root root 243K Oct 12 09:36 /usr/bin/xawtv
I got the problem under my Mandrake Cooker, and now(due to amd64) I am
under a gentoo-amd64.
Thank you very much for your interest in my problem :-)
Plese keep CC to me as I am not on the LKML (read through NNTP).
--
Gr?goire Favre
________________________________________________________________________
http://magma.epfl.ch/greg ICQ:16624071 mailto:[email protected]
Gregoire Favre wrote:
> On Mon, Nov 08, 2004 at 10:53:46AM +1100, Con Kolivas wrote:
>
> Hello again :-)
>
>
>>Gregoire Favre wrote:
>>
>>>I use DVB with VDR, but I can do the crash all the time without VDR, all
>>>I have to do is to have xawtv running and having a process that write
>>>fast enough data to an HD (I tested xfs, reiserfs, ext2 and ext3 with
>>>same result). If I don't have xawtv running I can't make crashing my
>>>system which is rock stable :-)
>>
>>Is xawtv running as root or with real time privileges? That could do it.
>
>
> Normally I start xawtv this way:
> xawtv -c /dev/v4l/video0 -geometry 770x580-0-0 -xvport 61 & as a normal
> user, but I don't know what real time privileges are ?
> I haven't modified in any way xawtv :
> -rwxr-xr-x 1 root root 243K Oct 12 09:36 /usr/bin/xawtv
What does 'top' show as the PRI for xawtv?
Con
On Mon, Nov 08, 2004 at 11:08:11AM +1100, Con Kolivas wrote:
> >>>I use DVB with VDR, but I can do the crash all the time without VDR, all
> >>>I have to do is to have xawtv running and having a process that write
> >>>fast enough data to an HD (I tested xfs, reiserfs, ext2 and ext3 with
> >>>same result). If I don't have xawtv running I can't make crashing my
> >>>system which is rock stable :-)
> >>
> >>Is xawtv running as root or with real time privileges? That could do it.
> What does 'top' show as the PRI for xawtv?
I just started it and see 16 as priority in top. Should I renice it or
start it another way ?
--
Gr?goire Favre
________________________________________________________________________
http://magma.epfl.ch/greg ICQ:16624071 mailto:[email protected]
Gregoire Favre wrote:
> On Mon, Nov 08, 2004 at 11:08:11AM +1100, Con Kolivas wrote:
>
>
>>>>>I use DVB with VDR, but I can do the crash all the time without VDR, all
>>>>>I have to do is to have xawtv running and having a process that write
>>>>>fast enough data to an HD (I tested xfs, reiserfs, ext2 and ext3 with
>>>>>same result). If I don't have xawtv running I can't make crashing my
>>>>>system which is rock stable :-)
>>>>
>>>>Is xawtv running as root or with real time privileges? That could do it.
>
>
>>What does 'top' show as the PRI for xawtv?
>
>
> I just started it and see 16 as priority in top. Should I renice it or
> start it another way ?
No I was just excluding whether you were running real time or not. You
are not, so that excludes that as the cause of your problem. I have no
further ideas though I'm afraid.
Cheers,
Con
On Mon, Nov 08, 2004 at 11:37:57AM +1100, Con Kolivas wrote:
> No I was just excluding whether you were running real time or not. You
> are not, so that excludes that as the cause of your problem. I have no
> further ideas though I'm afraid.
OK, thank you very much for having taken from your time to investigate
my problem :-)
--
Gr?goire Favre
________________________________________________________________________
http://magma.epfl.ch/greg ICQ:16624071 mailto:[email protected]
On Mon, 8 Nov 2004, Con Kolivas wrote:
> Gregoire Favre wrote:
>> On Mon, Nov 08, 2004 at 11:08:11AM +1100, Con Kolivas wrote:
>>
>>
>>>>>> I use DVB with VDR, but I can do the crash all the time without VDR,
>>>>>> all
>>>>>> I have to do is to have xawtv running and having a process that write
>>>>>> fast enough data to an HD (I tested xfs, reiserfs, ext2 and ext3 with
>>>>>> same result). If I don't have xawtv running I can't make crashing my
>>>>>> system which is rock stable :-)
>>>>>
>>>>> Is xawtv running as root or with real time privileges? That could do it.
>>
>>
>>> What does 'top' show as the PRI for xawtv?
>>
>>
>> I just started it and see 16 as priority in top. Should I renice it or
>> start it another way ?
>
> No I was just excluding whether you were running real time or not. You are
> not, so that excludes that as the cause of your problem. I have no further
> ideas though I'm afraid.
I am seeing the same problem with my bttv card. It was present in the 2.4
day and is present to this day. There are some kernels that are more
probable to hang while others are less. It does not depend on -ck or any
other patchset or scheduling. I reported it to bttv maintainer year or two
ago, but it looks like he is very unresponsive. :-) I know that this is
not only my problem. And I know it is not probably related with nvidia or
any other binary drivers. And it happens with zapping or mplayer v4l[12]
too. And I tried every possible configuration of cards and IRQs. Nothing
helps.
I suspect two things:
- there is some bug in bttv and similar drivers (DVB) that corrupts memory
related with internal mm and vfs structures or does something equally bad,
- or maybe PCI bandwitch is overflowed, but I do not think it should
happen.
But it is very hard to prove any of these I am afraid.
Grzegorz Kulewski
Grzegorz Kulewski <[email protected]> writes:
> I am seeing the same problem with my bttv card. It was present in the
> 2.4 day and is present to this day. There are some kernels that are
> more probable to hang while others are less. It does not depend on -ck
> or any other patchset or scheduling. I reported it to bttv maintainer
> year or two ago, but it looks like he is very unresponsive. :-)
Well, if it happens almost independant of the kernel/driver version it
most likely is buggy hardware. I can't do much about it ...
Well known example are some via chipsets which have trouble with
multiple devices doing DMA at the same time (those tend to run stable
with bttv once you've turned off ide-dma ...).
Getting broken hardware run stable and fast is black magic. You can
try these (if that happens to help we can put that info into the pci
quirks btw.):
eskarina kraxel ~# modinfo bttv | grep "pci config"
parm: vsfx:set VSFX pci config bit [yet another chipset flaw workaround]
parm: triton1:set ETBF pci config bit [enable bug compatibility for triton1 + others]
Otherwise BIOS updates, obscure BIOS settings, shuffling cards in PCI
slots, enable/disable ACPI and/or APIC, whatelse may or may not help.
See also Documentation/video4linux/bttv/README.freeze
good luck,
Gerd
--
#define printk(args...) fprintf(stderr, ## args)
On Maandag 08 November 2004 09:30, Grzegorz Kulewski wrote:
> I suspect two things:
> - there is some bug in bttv and similar drivers (DVB) that corrupts memory
> related with internal mm and vfs structures or does something equally bad,
> - or maybe PCI bandwitch is overflowed, but I do not think it should
> happen.
>
> But it is very hard to prove any of these I am afraid.
I have the problem as well since I moved from my K6-II to an Opteron based
system. As a workaround, I only use the card in grab mode instead of
overlay, this reduces the frequency of the crashes from once per 30 minutes
to once per month.
Someone also suggested the problem might be related to the old bt848
(ca. 1997) chip not behaving well on modern PCI buses.
Arnd <><
On Mon, 8 Nov 2004, Gerd Knorr wrote:
> Grzegorz Kulewski <[email protected]> writes:
>
>> I am seeing the same problem with my bttv card. It was present in the
>> 2.4 day and is present to this day. There are some kernels that are
>> more probable to hang while others are less. It does not depend on -ck
>> or any other patchset or scheduling. I reported it to bttv maintainer
>> year or two ago, but it looks like he is very unresponsive. :-)
>
> Well, if it happens almost independant of the kernel/driver version it
> most likely is buggy hardware. I can't do much about it ...
Well, I have Abit KG7 with AMD 760 and VIA 686B and this machine is rock
stable. I am not able to lock it with any other usage than watching tv
with bttv. I tested it with memtest for 40+ hours, and with heavy disk
loads and I am compiling Gentoo from stage1 on it pretty often with
very expensive optimizations. So I think that it is not hardware problem.
Or it is hardware problem only when using bttv.
But others can reproduce similar problems. Two my friends have the same
problem on very different hardware. And under Windows everything seems to
be working well. And sometimes, but very rare, I get oops in my log
saying something about mm and fs structures broken. But I am using nvidia
binary drivers and I can reproduce this kind of oops once per half a year
or something, so I didn't posted it here. If you want to look at it, I can
search my old logs and post it off list.
It is not kernel independent too. Some 2.6 kernels are better, some are
worse. With some kernels I can have no hang for over a month (I think it
is near to maximal lifetime of kernel in my box) and with some others I
can get one per couple of hours.
It is not hardware dependent too. I saw people on this list that see
similar problems on AMD64.
> Well known example are some via chipsets which have trouble with
> multiple devices doing DMA at the same time (those tend to run stable
> with bttv once you've turned off ide-dma ...).
>
> Getting broken hardware run stable and fast is black magic. You can
> try these (if that happens to help we can put that info into the pci
> quirks btw.):
>
> eskarina kraxel ~# modinfo bttv | grep "pci config"
> parm: vsfx:set VSFX pci config bit [yet another chipset flaw workaround]
> parm: triton1:set ETBF pci config bit [enable bug compatibility for triton1 + others]
I will look at it. But now I have nearly IDE free setup. I have Silicon
Image simple SATA controller and I still can reproduce the same problem. I
am now using IDE only for CD/DVD, but cdrom.ko is loaded only on demand in
my system, and I am not using it with bttv at the same time.
> Otherwise BIOS updates, obscure BIOS settings, shuffling cards in PCI
> slots, enable/disable ACPI and/or APIC, whatelse may or may not help.
Tried 100000 times.
> See also Documentation/video4linux/bttv/README.freeze
It is mirrored in my brain.
Thanks for your work. I really see the difference betwen bttv from the
early 2.4 ancient era and smooth and clear image and sound from today's
2.6 bttv (always with the same BT878 Prolink Pixelview PlayTV PAK II
card).
Grzegorz Kulewski
On Mon, Nov 08, 2004 at 10:17:39AM +0100, Gerd Knorr wrote:
> Well, if it happens almost independant of the kernel/driver version it
> most likely is buggy hardware. I can't do much about it ...
? Why couldn't it be a bug present in all kernels/drivers ?
Under bugs.gentoo.org there are quiete a lots of those, for example
http://bugs.gentoo.org/show_bug.cgi?id=64728 and google can show a lots
more.
> Well known example are some via chipsets which have trouble with
> multiple devices doing DMA at the same time (those tend to run stable
> with bttv once you've turned off ide-dma ...).
I had those xawtv crash with an SCSI only system, and on all my
MB/CPU/RAM test I doubt that all hardware configuration were buggy.
> Getting broken hardware run stable and fast is black magic. You can
> try these (if that happens to help we can put that info into the pci
> quirks btw.):
>
> eskarina kraxel ~# modinfo bttv | grep "pci config"
> parm: vsfx:set VSFX pci config bit [yet another chipset flaw workaround]
> parm: triton1:set ETBF pci config bit [enable bug compatibility for triton1 + others]
>
> Otherwise BIOS updates, obscure BIOS settings, shuffling cards in PCI
> slots, enable/disable ACPI and/or APIC, whatelse may or may not help.
>
> See also Documentation/video4linux/bttv/README.freeze
I only have DVB hardware, is that also considered as bttv ?
I have tried a lots of different configuration, with or without fb,
playing in the BIOS, pre-empt/no, ACPI/noACPI ... no change at all.
Some things I have noticed : xawtv and kdetv don't need CPU to achieve
the best quality I know about BUT they make the system crash.
kvdr and tvtime needs lots of time and there quality are really lower
than the two others, BUT they don't crash my system.
I can't speak about xawdecode because I am not able to run it under
amd64... neither zapping.
What I do now is to stop xawtv before doing a large copy of files...
I would happily try any suggestion :-)
Thank you very much,
--
Gr?goire Favre
________________________________________________________________________
http://magma.epfl.ch/greg ICQ:16624071 mailto:[email protected]
> I suspect two things:
> - there is some bug in bttv and similar drivers (DVB) that corrupts memory
> related with internal mm and vfs structures or does something equally bad,
> - or maybe PCI bandwitch is overflowed, but I do not think it should
> happen.
This (first alternative) sounds related to the problem I had with DVB;
I got visible corruption of video memory when using xawtv on the DVB
video device using Xv on a G550. The cause might lie in either of:
- Hardware/AV7110 firmware
- Kernel DVB driver (probably: AV7110 videodevice part), tried many versions
- Xfree86 XV-over-videodevice driver, tried several versions
- Xfree86 MGA driver, tried several versions
Never found the cause, but the problem went away with disabling the Xv
extension (now using video overlay mode).
Olaf
On Mon, Nov 08, 2004 at 07:52:49PM +0100, Gregoire Favre wrote:
> On Mon, Nov 08, 2004 at 10:17:39AM +0100, Gerd Knorr wrote:
>
> > Well, if it happens almost independant of the kernel/driver version it
> > most likely is buggy hardware. I can't do much about it ...
>
> ? Why couldn't it be a bug present in all kernels/drivers ?
bttv runs rock solid for many people. Well, at least most versions,
some *are* buggy. I'm not perfect after all ;)
> > Well known example are some via chipsets which have trouble with
> > multiple devices doing DMA at the same time (those tend to run stable
> > with bttv once you've turned off ide-dma ...).
>
> I had those xawtv crash with an SCSI only system, and on all my
> MB/CPU/RAM test I doubt that all hardware configuration were buggy.
The point isn't IDE, the point is two devices doing DMA at the same
time. The usual system diagnose tools don't do that btw, they test one
device after another. For simliar reasons memtest may run perfectly
fine and neverless gcc segfaults on kernel builds due to bad RAM ...
What most people see is that the machine freezes are much more likely as
soon as they do disk I/O in parallel to watching TV. It doesn't really
matter whenever the IDE controller or the SCSI hostadapter does the DMA.
PCI-PCI transfers (i.e. DMA from bt878 to graphics card for overlay) are
another case which often broken in chipsets.
> I only have DVB hardware, is that also considered as bttv ?
Full-featured DVB cards (i.e. those with hardware mpeg decoder) do
things compareble to b878.
> Some things I have noticed : xawtv and kdetv don't need CPU to achieve
> the best quality I know about BUT they make the system crash.
> kvdr and tvtime needs lots of time and there quality are really lower
> than the two others, BUT they don't crash my system.
Then it's likely the PCI-PCI transfers which kill the system.
Try switching xawtv into grabdisplay mode, it most likely shows the
same behavior like tvtime then, i.e. eat CPU time and don't crash the
machine. Thats simply the fact that PCI-PCI transfers are not used
then. And it's almost certainly not a driver bug then, the driver
just has to setup stuff once and then let the hardware run on its
own (which sometimes has the funny effect that the video overlay
continues to run even after a kernel panic ;)
Gerd
--
#define printk(args...) fprintf(stderr, ## args)
Olaf Titz <[email protected]> writes:
> > I suspect two things:
> > - there is some bug in bttv and similar drivers (DVB) that corrupts memory
> > related with internal mm and vfs structures or does something equally bad,
> > - or maybe PCI bandwitch is overflowed, but I do not think it should
> > happen.
>
> This (first alternative) sounds related to the problem I had with DVB;
> I got visible corruption of video memory when using xawtv on the DVB
> video device using Xv on a G550.
Thats something completely different and usually caused by the gfx
card not being able to handle the bandwith needed for full video
display. Result are aborted PCI transfers, which results in the video
being displayed fine on the left side and not being displayed
correctly on the right side of the window.
Usually can be workarounded by using 16 bpp instead of 32 which halves
the video data rate.
Gerd
--
#define printk(args...) fprintf(stderr, ## args)
> Thats something completely different and usually caused by the gfx
> card not being able to handle the bandwith needed for full video
> display. Result are aborted PCI transfers, which results in the video
> being displayed fine on the left side and not being displayed
> correctly on the right side of the window.
The symptom is different (the picture has vertical stripes, as if
pixels get re-ordered in each horizontal line). xawtv running in
overlay mode works well. This does the same things to the hardware
wrt. PCI-PCI transfers as Xv, it's just a different driver programming
the registers - so I suspect a bug in either Xfree86 or DVB.
Olaf
On Tue, 09 Nov 2004 21:10:30 +0100, Olaf Titz said:
> The symptom is different (the picture has vertical stripes, as if
> pixels get re-ordered in each horizontal line).
Hmm.. somebody got confused for a 24-bit color (8/8/8) about whether
it takes 24 bits or 32 to store it?
> > The symptom is different (the picture has vertical stripes, as if
> > pixels get re-ordered in each horizontal line).
>
> Hmm.. somebody got confused for a 24-bit color (8/8/8) about whether
> it takes 24 bits or 32 to store it?
No, correct colors but the order of pixels is rearranged, like this:
if the correct numbering of pixels were abcdefghijkl
the display looks like fdbeacihlkjg
The actual pattern is different each time.
I suspect that some control data for the display hardware gets
corrupted, rather than the video data itself.
Olaf