Discussion:
bt878(0): IRQ lockup, cleared int mask
David Johnson
2005-07-30 21:17:17 UTC
Permalink
Hi all,

I'm using a Nebula DVB-T PCI card with the mt352 frontend [1] and am having
problems with the card stopping sending data. I'm using the DVB drivers in
kernel 2.6.13-rc4, which are very close to if not identical to those in the
current dvb-kernel CVS.

I'm using mplayer as a viewer (I've tried with others too and get the same
issue, so I'm confident this isn't a viewer bug) which starts up OK and I can
watch TV. However after a random time, normally between 10 seconds and 10
minutes, the card stops sending data and mplayer dies:

dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 5 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 4 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 3 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 2 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 1 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 5 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 4 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 3 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 2 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 1 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, return 0 bytes
TS_PARSE: COULDN'T SYNC

As I'm watching TV, I'm getting lots of the following messages in demsg:

bt878(0): irq FDSR FBUS risc_pc=1fc66010
bt878(0): irq FBUS risc_pc=1fc66158
bt878(0): irq FBUS risc_pc=1fc66158
bt878(0): irq FBUS risc_pc=1fc66040
bt878(0): irq FBUS risc_pc=1fc66040
bt878(0): irq FBUS risc_pc=1fc66198
bt878(0): irq FBUS risc_pc=1fc661a0
bt878(0): irq FBUS risc_pc=1fc66080
bt878(0): irq FDSR FBUS risc_pc=1fc660b8
bt878(0): irq FBUS risc_pc=1fc66170
bt878(0): irq FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210

Then when the card stops sending data and mplayer dies, I get the following in
dmesg:

bt878(0): IRQ lockup, cleared int mask

If I restart mplayer it opens the card fine and I can carry on where I left
off - until it happens again.

Any advice would be greatfully received and I'd be more than happy to help
debug this if it's a bug (as long as someone tells me how!).

Thanks in advance,
David.

[1] made to work using the code from this patch:
http://www.linuxtv.org/pipermail/linux-dvb/2005-April/001479.html
Matt
2005-07-30 23:03:21 UTC
Permalink
Post by David Johnson
Hi all,
I'm using a Nebula DVB-T PCI card with the mt352 frontend [1] and am having
problems with the card stopping sending data. I'm using the DVB drivers in
kernel 2.6.13-rc4, which are very close to if not identical to those in the
current dvb-kernel CVS.
I'm using mplayer as a viewer (I've tried with others too and get the same
issue, so I'm confident this isn't a viewer bug) which starts up OK and I can
watch TV. However after a random time, normally between 10 seconds and 10
dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 5 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 4 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 3 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 2 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 1 failed with errno 0 when reading 1640 bytes
dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 5 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 4 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 3 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 2 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 1 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, return 0 bytes
TS_PARSE: COULDN'T SYNC
bt878(0): irq FDSR FBUS risc_pc=1fc66010
bt878(0): irq FBUS risc_pc=1fc66158
bt878(0): irq FBUS risc_pc=1fc66158
bt878(0): irq FBUS risc_pc=1fc66040
bt878(0): irq FBUS risc_pc=1fc66040
bt878(0): irq FBUS risc_pc=1fc66198
bt878(0): irq FBUS risc_pc=1fc661a0
bt878(0): irq FBUS risc_pc=1fc66080
bt878(0): irq FDSR FBUS risc_pc=1fc660b8
bt878(0): irq FBUS risc_pc=1fc66170
bt878(0): irq FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
bt878(0): irq FDSR FBUS risc_pc=1fc66210
Then when the card stops sending data and mplayer dies, I get the following in
bt878(0): IRQ lockup, cleared int mask
If I restart mplayer it opens the card fine and I can carry on where I left
off - until it happens again.
Any advice would be greatfully received and I'd be more than happy to help
debug this if it's a bug (as long as someone tells me how!).
Thanks in advance,
David.
http://www.linuxtv.org/pipermail/linux-dvb/2005-April/001479.html
_______________________________________________
linux-dvb mailing list
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
I had exactly the same problem with a avermedia 771 with the same front
end. The way I fixed it was to edit drivers/media/dvb/bt8xx/bt878.c on
line 330 changing 20 to 120, this number I think is the number of errors
a device can handle before giving up, a better solution would be to
attempt to restart the stream rather than simply stopping it.

Matt
Edgar Toernig
2005-07-31 01:51:22 UTC
Permalink
Post by David Johnson
bt878(0): irq FDSR FBUS risc_pc=1fc66010
bt878(0): irq FBUS risc_pc=1fc66158
bt878(0): IRQ lockup, cleared int mask
Look for the line

controlreg |= 0x1b;

in drivers/media/dvb/bt8xx/bt878.c and change it to

controlreg |= 0x13;

That works for me. It lowers the fifo-threshold at which the DMA
controller starts its DMA cycle. I don't know why this happens
with newer kernels. With 2.6.8 (SuSE-9.2 kernel) everything was
fine ...

I'll make a patch with some other stuff (for cx24110 and bttv) when
2.6.13 is out.

Ciao, ET.
Hamish Moffatt
2005-07-31 05:58:58 UTC
Permalink
Post by Edgar Toernig
Post by David Johnson
bt878(0): irq FDSR FBUS risc_pc=1fc66010
bt878(0): irq FBUS risc_pc=1fc66158
bt878(0): IRQ lockup, cleared int mask
Look for the line
controlreg |= 0x1b;
in drivers/media/dvb/bt8xx/bt878.c and change it to
controlreg |= 0x13;
I tried this on the Avermedia 761 (BT878) and it didn't help.
I threw the card away in the end.


Hamish
--
Hamish Moffatt VK3SB <***@debian.org> <***@cloud.net.au>
Jukka Tastula
2005-07-31 03:05:49 UTC
Permalink
Post by David Johnson
bt878(0): irq FDSR FBUS risc_pc=1fc66010
bt878(0): irq FBUS risc_pc=1fc66158
bt878(0): IRQ lockup, cleared int mask
I had exact same problem for a very long time with my nxt6000 nebula. I
finally some weeks ago tracked it down to the nic I was using (rtl8139).

These errors would appear when data was moving over the network. It seemed
completely random at first but became apparent when I started using nfs
for vdr recording storage; fast forwarding would always trigger it
instantly. The dvb card apparently also completely stopped transferring
data while these errors happened so I'd have unexplained gaps in my
recordings.

I still don't understand why it dislikes the nic as the other dvb-t card I
have (also bt878 based) doesn't seem to bork like the nebula does.

For now I'm using the onboard nic, via rhineII. Not really the perfect
trade as the driver is utter crap. Keeps resetting itself all the time so
bad that the average maximum bandwidth comes out to about 4MB/s, but at
least the nebula doesn't keep losing irqs anymore and my recordings don't
have gaps in them.

Tried with two different motherboards, the nebula just doesn't seem to like
to play well with others. I tried all kinds of latency tricks on the nic
and both dvb cards. Nothing less than throwing away the nic "cured" it.
David Johnson
2005-07-31 13:08:08 UTC
Permalink
Post by Jukka Tastula
Post by David Johnson
bt878(0): irq FDSR FBUS risc_pc=1fc66010
bt878(0): irq FBUS risc_pc=1fc66158
bt878(0): IRQ lockup, cleared int mask
I had exact same problem for a very long time with my nxt6000 nebula. I
finally some weeks ago tracked it down to the nic I was using (rtl8139).
I've tracked down the cause on my system - it generates irq messages every
time the disk (an SATA drive using the sata_nv driver) is accessed. Accessing
a large file makes the card die much quicker than it otherwise would.
Post by Jukka Tastula
Look for the line
controlreg |= 0x1b;
in drivers/media/dvb/bt8xx/bt878.c and change it to
controlreg |= 0x13;
This actually makes things much worse for me - IRQ errors are generated much
more frequently than they are with the setting at 1b.
Post by Jukka Tastula
I had exactly the same problem with a avermedia 771 with the same front
end. The way I fixed it was to edit drivers/media/dvb/bt8xx/bt878.c on
line 330 changing 20 to 120, this number I think is the number of errors
a device can handle before giving up, a better solution would be to
attempt to restart the stream rather than simply stopping it.
So this makes the card last longer before dying, but it still dies after 120
errors. I suppose I could just comment out that section of code completely,
but there's still something causing this problem and it would be much better
to track it down and fix it rather than just hide it.

Thanks to everyone for their help so far,
David.
Ilkka Pirskanen
2005-07-31 13:18:37 UTC
Permalink
Post by David Johnson
Post by Matt
I had exactly the same problem with a avermedia 771 with the same
front end. The way I fixed it was to edit
drivers/media/dvb/bt8xx/bt878.c on line 330 changing 20 to 120, this
number I think is the number of errors a device can handle before
giving up, a better solution would be to attempt to restart the stream
rather than simply stopping it.
Post by David Johnson
So this makes the card last longer before dying, but it still dies after
120 errors. I suppose I could just comment out that section of code
completely, >but there's still something causing this problem and it would
be much better to track it down and fix it rather than just hide it.
Post by David Johnson
Thanks to everyone for their help so far, David.
Thank you very much David for taking up the task of providing mt352 support
in dvb-bt8xx. As the card works without problem on Windows XP, there
probably cannot be any fundamental hardware conflict? It must be some kind
of Linux kernel interoperability problem?

Ilkka
Hamish Moffatt
2005-07-31 13:19:21 UTC
Permalink
Post by David Johnson
Post by Jukka Tastula
Post by David Johnson
bt878(0): irq FDSR FBUS risc_pc=1fc66010
bt878(0): irq FBUS risc_pc=1fc66158
bt878(0): IRQ lockup, cleared int mask
I had exact same problem for a very long time with my nxt6000 nebula. I
finally some weeks ago tracked it down to the nic I was using (rtl8139).
I've tracked down the cause on my system - it generates irq messages every
time the disk (an SATA drive using the sata_nv driver) is accessed. Accessing
a large file makes the card die much quicker than it otherwise would.
I had the same problem. As soon as I started using the SATA controller
(which in my case was not sata_nv but one of the SIL drivers), I had
trouble with the BT878.

Getting errors was as simple as

tzap -r 'some channel' &
cat /dev/dvb/adapter0/dvr0 > /path/to/sata/disk/file
Post by David Johnson
So this makes the card last longer before dying, but it still dies after 120
errors. I suppose I could just comment out that section of code completely,
but there's still something causing this problem and it would be much better
to track it down and fix it rather than just hide it.
In my opinion the FIFO in the BT878 is simply not big enough for this
application. It is designed for carrying audio data at up to 1Mbit,
not DVB-T data at up to 23Mbit or more.

I replaced the card with a CX2388x-based card and I've never had an
issue since.

You might have some luck adjusting the PCI latencies using setpci,
powertweak etc. I never did though.

Hamish
--
Hamish Moffatt VK3SB <***@debian.org> <***@cloud.net.au>
David Johnson
2005-07-31 19:24:37 UTC
Permalink
Post by Hamish Moffatt
I had the same problem. As soon as I started using the SATA controller
(which in my case was not sata_nv but one of the SIL drivers), I had
trouble with the BT878.
Getting errors was as simple as
tzap -r 'some channel' &
cat /dev/dvb/adapter0/dvr0 > /path/to/sata/disk/file
Yeah, that exactly the same behaviour I'm seeing.
So that's at least two SATA modules which conflict with bt878... strange. Is
anyone using a bt878 card in a machine with SATA and /not/ having problems?

Thanks,
David.
Matt
2005-07-31 20:56:56 UTC
Permalink
Post by David Johnson
Post by Hamish Moffatt
I had the same problem. As soon as I started using the SATA controller
(which in my case was not sata_nv but one of the SIL drivers), I had
trouble with the BT878.
Getting errors was as simple as
tzap -r 'some channel' &
cat /dev/dvb/adapter0/dvr0 > /path/to/sata/disk/file
Yeah, that exactly the same behaviour I'm seeing.
So that's at least two SATA modules which conflict with bt878... strange. Is
anyone using a bt878 card in a machine with SATA and /not/ having problems?
Thanks,
David.
_______________________________________________
linux-dvb mailing list
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
I do not have SATA in my machine and it works ok (with a kernel tweak),
the reason why I get so many errors is because the reception around here
is not great. By the way the 120 errors is in a row I think.

Regards

Matt
Hamish Moffatt
2005-07-31 22:55:51 UTC
Permalink
Post by Matt
Post by David Johnson
Post by Hamish Moffatt
Getting errors was as simple as
tzap -r 'some channel' &
cat /dev/dvb/adapter0/dvr0 > /path/to/sata/disk/file
Yeah, that exactly the same behaviour I'm seeing.
So that's at least two SATA modules which conflict with bt878... strange.
Is anyone using a bt878 card in a machine with SATA and /not/ having
problems?
I do not have SATA in my machine and it works ok (with a kernel tweak),
the reason why I get so many errors is because the reception around here
is not great. By the way the 120 errors is in a row I think.
I don't see how poor reception could cause FDSR errors - the BT878 isn't
aware that the data you are transferring is corrupt.

One possibility is that your application software is writing to a log
file every time a corrupt packet is received. MythTV used to do that. I
suspect that hard disk activity contributes to the 878's problems.

Hamish
--
Hamish Moffatt VK3SB <***@debian.org> <***@cloud.net.au>
Ilkka Pirskanen
2005-07-31 21:10:30 UTC
Permalink
Post by David Johnson
Yeah, that exactly the same behaviour I'm seeing.
So that's at least two SATA modules which conflict with bt878... strange.
Is anyone using a bt878 card in a machine with SATA and /not/ having
problems?
Post by David Johnson
Thanks,
David.
I have got a single SATA hard drive on a ASUS P4C800-E Deluxe motherboard
(about two years old). I can give the patch a try if you can send me the
modified dvb-bt8xx or the patch itself (I have SUSE 9.3 Professional, and
vermagic is 2.6.11.4-21.7-smp SMP 586 REGPARM gcc-3.3). It will take a
couple of days as I am very new to Linux and I have to sort out various
things relating to kernel compiling first. I have a dual-boot system with
Windows XP, and on Windows the Nebula card works OK.

Ilkka
Ilkka Pirskanen
2005-08-02 16:47:29 UTC
Permalink
Post by David Johnson
Yeah, that exactly the same behaviour I'm seeing.
So that's at least two SATA modules which conflict with bt878... strange.
Is anyone using a bt878 card in a machine with SATA and /not/ having
problems?
Post by David Johnson
Thanks,
David.
I have now installed Linux 2.6.13-rc4 kernel and dvb-bt8xx.c modified by
David on my computer. I have some general problems with the new kernel
(there is no sound and it doesn't recognize my USB wheel mouse), but DVB
front-end seems to be working OK. This is the "dmesg" of modprobe dvb-bt8xx.

bt878: AUDIO driver version 0.0.0 loaded
bt878: Bt878 AUDIO function found (0).
ACPI: PCI Interrupt 0000:03:0d.1[A] -> GSI 21 (level, low) -> IRQ 193
bt878(0): Bt878 (rev 17) at 03:0d.1, irq: 193, latency: 64, memory:
0xf7eff000
DVB: registering new adapter (bttv0).
DVB: registering frontend 0 (Zarlink MT352 DVB-T)...

I have ASUS P4C800-E Deluxe motherboard. The only hard disk I have is
connected to a S-ATA connection supported by South Bridge (Intel ICH5R). In
addition, there is an integrated Promise PDC20378 controller which I don't
use. These are the BIOS settings:

Onboard IDE Operate Mode: Enhanced Mode
Enhanced Mode Support on: S-ATA
Configure S-ATA as RAID: No

I watched the TV for about ten minutes and made little file copying on the
background. How fast should the problem appear, and are the problems written
on "dmesg"? I have no messages there.

Kind regards

Ilkka
David Johnson
2005-08-03 20:57:19 UTC
Permalink
Post by Ilkka Pirskanen
I have now installed Linux 2.6.13-rc4 kernel and dvb-bt8xx.c modified by
David on my computer. I have some general problems with the new kernel
(there is no sound and it doesn't recognize my USB wheel mouse), but DVB
front-end seems to be working OK. This is the "dmesg" of modprobe dvb-bt8xx.
bt878: AUDIO driver version 0.0.0 loaded
bt878: Bt878 AUDIO function found (0).
ACPI: PCI Interrupt 0000:03:0d.1[A] -> GSI 21 (level, low) -> IRQ 193
0xf7eff000
DVB: registering new adapter (bttv0).
DVB: registering frontend 0 (Zarlink MT352 DVB-T)...
I have ASUS P4C800-E Deluxe motherboard. The only hard disk I have is
connected to a S-ATA connection supported by South Bridge (Intel ICH5R). In
addition, there is an integrated Promise PDC20378 controller which I don't
Onboard IDE Operate Mode: Enhanced Mode
Enhanced Mode Support on: S-ATA
Configure S-ATA as RAID: No
I watched the TV for about ten minutes and made little file copying on the
background. How fast should the problem appear, and are the problems
written on "dmesg"? I have no messages there.
The errors normally appear in dmesg as soon as there is any disk activity
while the card is active - it seems you don't have this problem.
That's annoying; I was rather hoping it was going to be triggered by every
SATA driver, as this would no doubt have made it easier for the devs to track
down the problem...

So far the issue has been reported on systems with sata_nv and sata_sil. I
don't suppose anyone else has either of those SATA chipsets and a bt878-based
card? It would be helpful to know if the problem is always triggered by this
combination, or whether there is something else going on.

Thanks,
David.
Ilkka Pirskanen
2005-08-03 23:11:56 UTC
Permalink
From: linux-dvb-***@linuxtv.org [mailto:linux-dvb-***@linuxtv.org]
On Behalf Of David Johnson

The errors normally appear in dmesg as soon as there is any disk activity
while the card is active - it seems you don't have this problem.
That's annoying; I was rather hoping it was going to be triggered by every
SATA driver, as this would no doubt have made it easier for the devs to
track down the problem...

So far the issue has been reported on systems with sata_nv and sata_sil. I
don't suppose anyone else has either of those SATA chipsets and a
bt878-based card? It would be helpful to know if the problem is always
triggered by this combination, or whether there is something else going on.

Thanks,
David.

=========

Just for completeness, here are the SATA-relevant entries from my dmesg:

Linux version 2.6.13-rc5-smp (***@a80-186-173-81) (gcc version 3.3.5
20050117 (prerelease) (SUSE Linux)) #1 SMP Wed Aug 3 02:11:10 EEST 2005
...
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 Boot video device is
0000:01:00.0
...
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH5: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 169
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio Probing
IDE interface ide0...
hda: HL-DT-ST DVDRAM GSA-4163B, ATAPI CD/DVD-ROM drive
hdb: DM-2000TE, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
libata version 1.11 loaded.
ata_piix version 1.03
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xEFE0 ctl 0xEFAE bmdma 0xEF60 irq 169
ata2: SATA max UDMA/133 cmd 0xEFA0 ctl 0xEFAA bmdma 0xEF68 irq 169
ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003
88:207f
ata1: dev 0 ATA, max UDMA/133, 312581808 sectors: lba48
ata1: dev 0 configured for UDMA/133
scsi0 : ata_piix
ata2: SATA port has no device.
scsi1 : ata_piix
Vendor: ATA Model: ST3160023AS Rev: 3.05
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) SCSI device
sda: drive cache: write back SCSI device sda: 312581808 512-byte hdwr
sectors (160042 MB) SCSI device sda: drive cache: write back
sda: sda1 sda2 < sda5 > sda3 sda4
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
hda: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdb: ATAPI 16X DVD-ROM drive, 256kB Cache, UDMA(33) Attempting manual resume
swsusp: Suspend partition has wrong signature?
ReiserFS: sda4: found reiserfs format "3.6" with standard journal
ReiserFS: sda4: using ordered data mode
ReiserFS: sda4: journal params: device sda4, size 8192, journal first block
18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda4: checking transaction log (sda4)
ReiserFS: sda4: Using r5 hash to sort names
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
Adding 1044216k swap on /dev/sda3. Priority:42 extents:1
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-***@redhat.com
NTFS driver 2.1.23 [Flags: R/W MODULE].
NTFS volume version 3.1.
NTFS volume version 3.1.
Capability LSM initialized
...
bttv: driver version 0.9.16 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
ACPI: PCI Interrupt 0000:03:0d.0[A] -> GSI 21 (level, low) -> IRQ 193
bttv0: Bt878 (rev 17) at 0000:03:0d.0, irq: 193, latency: 64, mmio:
0xf7efe000
bttv0: detected: Nebula Electronics DigiTV [card=104], PCI subsystem ID is
0071:0101
bttv0: using: Nebula Electronics DigiTV [card=104,autodetected]
bttv0: gpio: en=00000000, out=00000000 in=00ff00cb [init]
i2c-algo-bit.o: (0) scl=1, sda=1
i2c-algo-bit.o: (1) scl=1, sda=0
i2c-algo-bit.o: (2) scl=1, sda=1
i2c-algo-bit.o: (3) scl=0, sda=1
i2c-algo-bit.o: (4) scl=1, sda=1
i2c-algo-bit.o: bt878 #0 [sw] passed test.
bttv0: IRQ lockup, cleared int mask [bits: GPINT*]
bttv0: using tuner=-1
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 => 35468950 .. ok
bttv0: add subdevice "dvb0"

(dvb-bt8xx front-end has to be loaded separately by modprobe, the same
mechanism as in SUSE 9.3 kernel 2.6.11.4-21.7-smp doesn't work here)


And thank you very much for integrating the support in the dvb-bt8xx.c! I
hope that this SATA issue will be resolved. My SATA controller is about two
years old, so may be those drivers are mature enough, and the new ones more
problematic.

Kind regards

Ilkka
Edgar Toernig
2005-08-04 03:36:54 UTC
Permalink
Post by Ilkka Pirskanen
bttv0: using: Nebula Electronics DigiTV [card=104,autodetected]
bttv0: gpio: en=00000000, out=00000000 in=00ff00cb [init]
i2c-algo-bit.o: (0) scl=1, sda=1
i2c-algo-bit.o: (1) scl=1, sda=0
i2c-algo-bit.o: (2) scl=1, sda=1
i2c-algo-bit.o: (3) scl=0, sda=1
i2c-algo-bit.o: (4) scl=1, sda=1
i2c-algo-bit.o: bt878 #0 [sw] passed test.
bttv0: IRQ lockup, cleared int mask [bits: GPINT*]
bttv0: using tuner=-1
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 => 35468950 .. ok
bttv0: add subdevice "dvb0"
Just a note: this IRQ lockup is not the same I was refering to.
This one seems to be caused by an enabled interrupt (GPINT) which
noone wants to handle. The one I see is a FIFO overrun caused
by high latency on the PCI bus.

Ciao, ET.
Manu Abraham
2005-08-05 14:00:54 UTC
Permalink
Post by Ilkka Pirskanen
On Behalf Of David Johnson
The errors normally appear in dmesg as soon as there is any disk activity
while the card is active - it seems you don't have this problem.
That's annoying; I was rather hoping it was going to be triggered by every
SATA driver, as this would no doubt have made it easier for the devs to
track down the problem...
No problem here though.

Manu


[***@Orbit01 ~]# lspci
00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub
Interface (rev 02)
00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev
02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI #3
(rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface
Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE
Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev
02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev
02)
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200]
(rev a1)
02:00.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture
(rev 11)
02:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev
11)
02:01.0 Multimedia controller: Twinhan Technology Co. Ltd: Unknown device 4e35
(rev 01)
02:03.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
02:03.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev
0a)
02:04.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev
74)
Hamish Moffatt
2005-08-05 14:45:54 UTC
Permalink
Post by Manu Abraham
No problem here though.
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev
02)
02:00.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture
(rev 11)
02:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev
11)
02:01.0 Multimedia controller: Twinhan Technology Co. Ltd: Unknown device 4e35
(rev 01)
Your SATA controller isn't on the same PCI bus as your BT878.
Mine was. 0000:01 is my PCI slots:

0000:01:0d.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)
0000:01:07.0 Multimedia video controller: Conexant Winfast TV2000 XP (rev 05)
0000:01:07.2 Multimedia controller: Conexant: Unknown device 8802 (rev 05)
0000:01:08.0 Multimedia video controller: Conexant Winfast TV2000 XP (rev 05)
0000:01:08.2 Multimedia controller: Conexant: Unknown device 8802 (rev 05)
0000:01:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)

(Two CX23883 cards and an SAA7146, plus Atheros Wifi, onboard gigabit
RTL8169, SB Live! etc. No problem with the CX23883 or SAA7146 chipsets,
but the BT878 was bad news.

Hamish
--
Hamish Moffatt VK3SB <***@debian.org> <***@cloud.net.au>
Loading...