Mailing List Archive

On 30 November 2010 11:00, Andrew Pollock <andrew-ivtv@andrew.net.au> wrote:
> ...
> The eSATA controller has 4 SATA drives attached to it, in a RAID-10
> configuration, with LVM on top (hosting a JFS filesystem in a logical volume
> if it makes a difference).
> ...

Hi Andrew, it's interesting that all those panic screenshots are
having some problem with ext3.

I assume you're using ext3 as the filesystem of some other drive in
your MythTV box.

I'm not sure where you'd start but can you poke around to see if you
can find IRQ, IO or PCI conflicts between the eSATA controller, the
PVR-350 and your existing drives?

Sorry, not much help.

Yours,
Ralph

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Tue, 2010-11-30 at 16:27 +1000, Andrew Pollock wrote:
> Hi,
>
> I've just attempted to consolidate two computers into one, putting a Silicon
> Image SiI 3124 4 port eSATA controller (1095:3124) into my existing MythTV
> backend (a Dell Dimension 3100), which has a Hauppauge PVR-350 (4444:0803)
> in it.
>
> The eSATA controller has 4 SATA drives attached to it, in a RAID-10
> configuration, with LVM on top (hosting a JFS filesystem in a logical volume
> if it makes a difference).
>
> The problem I have is that the kernel has been panicking left and right
> since I did this.
>
> After a lot of swearing, and trial and error, I've narrowed down the crux of
> the problem:
>
> If I load the IVTV firmware, and am doing any sort of serious I/O on any of
> the eSATA-connected drives, the kernel will panic (in what seems to be weird
> and wonderful ways).
>
> The ways I've been synthesizing I/O have been to just dd one of the disks to
> /dev/null, or to get mdadm to do a RAID check (echo check >
> /sys/block/md0/md/sync_action)
>
> The way I've been triggering a firmware load is to just cat /dev/video0 out
> to /dev/null
>
> I can be exercising the disks happily, up until I trigger the firmware to
> load, and then BOOM, it panics.
>
> I've tried totally unloading the sata_sil24 driver, loading the firmware,
> and the reloading sata_sil24, with the same results, so I don't believe it's
> an ordering thing(yes, I've seen
> http://ivtvdriver.org/index.php/Firmware#warning:_SCSI_devicename_collisions,
> and I'm not sure this is still relevant, but I figure that unloading
> sata_sil24 and loading the firmware, then loading sata_sil24 again should do
> the trick). I've also tried completely unloading both ivtv and sata_sil24,
> and reloading sata_sil24 first, then ivtv and the firmware. Same deal.
>
> I've got some partial camera photos of some of the panics at
> http://www.andrew.net.au/~apollock/ivtv+sii=oops/ and if it'll help at all,
> I can do the requisite hoop jumping to try and get a higher-resolution
> display attached and hopefully capture the entire back trace.
>
> I've experienced this with 2.6.26 and 2.6.32, and a home-rolled 2.6.36 (I
> tried to use kexec/kdump to get a dump, but the kdump kernel panicked for
> some reason).

When a system panics it will not write to the file systems.

UNIX systems do this because generally, when one is panicking, the worst
thing to do would be to try and fix something. ;)


> I've also tried disabling hyperthreading (by shutting down the second CPU).
>
> Any thoughts, or assistance would be greatly appreciated.

The screenshots indicate that this is a VFS/Ext3 problem.

ext3_show_options() appears to just build a list of non-default mount
options that are in effect by looking at the filesystem's superblock for
the defaults.

A firmware load for ivtv will prompt udev read some scripts
under /usr/share, twiddle a "loading" node under /sys, and the copy the
firmware files from /lib/firmware into a "firmware" node under /sys.
I'm not sure how that could be the problem.

I'm assuming you have either:

1. (static) corruption in your ext3 filesystems on disk. Just because
the journal says things are clean, doesn't mean it can't be there.

2. (dynamic) corruption caused by a bug in the sata_sil24 driver and/or
it combination with the entire VFS driver stack you use: ext3, dm, lvm,
raid, etc.

3. (dynamic) corruption because the sata_sil24 hardware and the ivtv
hardware are sharing the same interrupt line and the sata_sil24 driver
doesn't handle that properly. (That's conjecture, I have not checked
the sata_sil24 driver.)


Some things to try:

a. See if the ivtv card and the sata_sil24 card share an IRQ line

cat /proc/interrupts


b. See if simply invoking ext3_show_options() with lots of disk activity
is enough to invoke the problem.

(generate lots of disk activity)
cat /proc/mounts

(I think that will do it.)


c. Force an fsck on you filesystems.

Backup any data you care about, knowing that it may be corrupt
Temporarily add "forcefsck" to your kernel commandline on reboot


d. E-mail the relevant mailing list for ext2/3/4 file system
development. They'll have a much better idea of what's causing your
VFS/Ext3 oops's than I will.


e. Transcribe the 64 "Code:" bytes from your dumps (Registers, and the
EIP and CR2 contents would be nice too) into an e-mail.

I can put the code bytes back into a small binary with xxd, and then run
objdump to get a disassembly to see exactly where in ext3_show_options()
the oops is occurring. That may help somewhat narrow the VFS/Ext3
problem, but that alone won't fix the system level problem you have.

Regards,
Andy



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Tue, 2010-11-30 at 07:46 -0500, Andy Walls wrote:
> On Tue, 2010-11-30 at 16:27 +1000, Andrew Pollock wrote:
> > Hi,
> >
> > I've just attempted to consolidate two computers into one, putting a Silicon
> > Image SiI 3124 4 port eSATA controller (1095:3124) into my existing MythTV
> > backend (a Dell Dimension 3100), which has a Hauppauge PVR-350 (4444:0803)
> > in it.
> >
> >
> > If I load the IVTV firmware, and am doing any sort of serious I/O on any of
> > the eSATA-connected drives, the kernel will panic (in what seems to be weird
> > and wonderful ways).
> >

One more:

> Some things to try:

f. Take *all* the PCI cards out of the machine and blow the dust out of
*all* the slots. Reinstall all the cards and test again.

The PCI bus uses reflected wave switching, so a problem with crud in one
connector can affect all the other devices on the bus.

Regards,
Andy




_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Tue, Nov 30, 2010 at 11:57:31AM +0000, Ralph Livock wrote:
> On 30 November 2010 11:00, Andrew Pollock <andrew-ivtv@andrew.net.au> wrote:
> > ...
> > The eSATA controller has 4 SATA drives attached to it, in a RAID-10
> > configuration, with LVM on top (hosting a JFS filesystem in a logical volume
> > if it makes a difference).
> > ...
>
> Hi Andrew, it's interesting that all those panic screenshots are
> having some problem with ext3.

Yeah, that bothered me somewhat. I figured it was because it was probably
trying to log something at the time. I really need to get a full kernel back
trace.

> I assume you're using ext3 as the filesystem of some other drive in
> your MythTV box.

Yes, the internal disk has ext3 filesystems on it.

> I'm not sure where you'd start but can you poke around to see if you
> can find IRQ, IO or PCI conflicts between the eSATA controller, the
> PVR-350 and your existing drives?

I've already looked at IRQ conflicts, and there don't appear to be any. I
imagine I look at /proc/ioports for IO conflicts. How do I look for PCI
conflicts?

> Sorry, not much help.
>
> Yours,
> Ralph
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users