Phil,
I was seeing the exact same behavior with the livecd distro as well as my own install from a fresh mandrake 10.0 install (which used same version of everything on the livecd).
I had all my cameras set to rgb24. Behavior happened irrespective of # of cameras.
See above for full specs of mobo etc.
Sean
linux crashing - $500 bounty!
Hi Phil,
I also had this problem with the LMLBT44 card. With both 2.4 and 2.6 kernels.
It does not seem to be only a ZM issue, as xawtv would also cause a reboot. TVTime however would not.
I have no idea about distros other than Mandrake, but this issue has persisted since MDK 9.2 stock 2.4 kernel up through 2.6.7
I emailed LML and asked if they would consider donating a card for testing with the livecd, as I was still searching for the solution, but no longer had a card to experiment with. They did not even reply my email. Strange since there is no other good software to use with their card. And they make a point of it working with ZoneMinder.
Anyway, I think further testing is needed to determine if a combination of capture card and mobo, or chipset is the culprit. Testing with other distros would be good too.
regards,
Ross
I also had this problem with the LMLBT44 card. With both 2.4 and 2.6 kernels.
It does not seem to be only a ZM issue, as xawtv would also cause a reboot. TVTime however would not.
I have no idea about distros other than Mandrake, but this issue has persisted since MDK 9.2 stock 2.4 kernel up through 2.6.7
I emailed LML and asked if they would consider donating a card for testing with the livecd, as I was still searching for the solution, but no longer had a card to experiment with. They did not even reply my email. Strange since there is no other good software to use with their card. And they make a point of it working with ZoneMinder.
Anyway, I think further testing is needed to determine if a combination of capture card and mobo, or chipset is the culprit. Testing with other distros would be good too.
regards,
Ross
Can anyone share insight as to what differences might be relevant in YUV422 vs RGB24?
I thought these were just different color spaces... how could choosing one over the other trigger a hard crash?
Is there a significant difference in memory layout or such, which requires different handling of one pallette vs another? I would think that kernel crashes could only be precipitated by serious errors like letting the card write to memory outside its prescribed shared mem space...
Is it a kernel bug or a problem with the card? Is it specific to the spectra8?
AFAICT there is no real difference between the spectra8 and the LML card. Both use the same chips but the LML has some extra IO goodies. It appears that this problem is common to both, so I guess it is a general issue with the BT878 chips.
Anyway I'm now at 24hrs uptime, so all is good.
I thought these were just different color spaces... how could choosing one over the other trigger a hard crash?
Is there a significant difference in memory layout or such, which requires different handling of one pallette vs another? I would think that kernel crashes could only be precipitated by serious errors like letting the card write to memory outside its prescribed shared mem space...
Is it a kernel bug or a problem with the card? Is it specific to the spectra8?
AFAICT there is no real difference between the spectra8 and the LML card. Both use the same chips but the LML has some extra IO goodies. It appears that this problem is common to both, so I guess it is a general issue with the BT878 chips.
Anyway I'm now at 24hrs uptime, so all is good.
Ask me about my Squeezebox
-
subliminal_boy_9
- Posts: 14
- Joined: Wed Nov 10, 2004 6:32 pm
Sean -
I don't know the answer to your questions, but I'll second your experience. Your thread has saved what is left of my hair. I've been chasing my tail for several weeks now trying to find out why the system would eventually crash out. Opteron optimized kernels only made the problem worse (ie., crashed faster).
Anyhow, now running on dual Opteron (240s) with 1GB RAM, 4x250 SATA on hardware raid (event storage), 2x120GB (software raid1) for OS/database. Running Gentoo, 2.6.9 kernel.
YUV422 and greyscale both work fine. RGB24 eventually leads to a death spiral on the system. In addition, nph-zms appears to clean up better than zms does, though I have zero idea as to why that would be the case.
FWIW, the cards I'm using are Provideo PV150's. BT chipset, like yours, 8 cameras per card, four chips per card. So two cameras per chip. Currently have 8 cameras plugged up, shooting for a full 16 capacity. If it holds up at the framerates, resolutions, and color depth I'm using, I may give it even more to do. Unfortunately, the tg3 code for Broadcom gigabit adapters is poor at this stage, so I'm stuck with burning my last PCI slot that way.
I don't know the answer to your questions, but I'll second your experience. Your thread has saved what is left of my hair. I've been chasing my tail for several weeks now trying to find out why the system would eventually crash out. Opteron optimized kernels only made the problem worse (ie., crashed faster).
Anyhow, now running on dual Opteron (240s) with 1GB RAM, 4x250 SATA on hardware raid (event storage), 2x120GB (software raid1) for OS/database. Running Gentoo, 2.6.9 kernel.
YUV422 and greyscale both work fine. RGB24 eventually leads to a death spiral on the system. In addition, nph-zms appears to clean up better than zms does, though I have zero idea as to why that would be the case.
FWIW, the cards I'm using are Provideo PV150's. BT chipset, like yours, 8 cameras per card, four chips per card. So two cameras per chip. Currently have 8 cameras plugged up, shooting for a full 16 capacity. If it holds up at the framerates, resolutions, and color depth I'm using, I may give it even more to do. Unfortunately, the tg3 code for Broadcom gigabit adapters is poor at this stage, so I'm stuck with burning my last PCI slot that way.
seanadams wrote:Can anyone share insight as to what differences might be relevant in YUV422 vs RGB24?
I thought these were just different color spaces... how could choosing one over the other trigger a hard crash?
Is there a significant difference in memory layout or such, which requires different handling of one pallette vs another? I would think that kernel crashes could only be precipitated by serious errors like letting the card write to memory outside its prescribed shared mem space...
Is it a kernel bug or a problem with the card? Is it specific to the spectra8?
AFAICT there is no real difference between the spectra8 and the LML card. Both use the same chips but the LML has some extra IO goodies. It appears that this problem is common to both, so I guess it is a general issue with the BT878 chips.
Anyway I'm now at 24hrs uptime, so all is good.