8139too not working in 2.6

8139too not working in 2.6

[Mirko Caserta]

Yes, I know, it's a damn cheap eth card and I should get it replaced :)

Besides that, this card works just fine with 2.4.25 while it refuses to  
work on a recent 2.6 kernel. I tried 2.6.5 and even  
2.6.5-rc2-mm2-broken-out with no luck.

The card is correctly recognized but the kernel refuses to transmit any  
packet:

8139too Fast Ethernet driver 0.9.27
eth0: RealTek RTL8139 at 0xe0821000, MAC_ADDR_REMOVED, IRQ 5
eth0:  Identified 8139 chip type 'RTL-8139C'
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth0: Transmit timeout, status 0c 0005 c07f media 10.
eth0: Tx queue start entry 4  dirty entry 0.
eth0:  Tx descriptor 0 is 0008a03c. (queue head)
eth0:  Tx descriptor 1 is 0008a03c.
eth0:  Tx descriptor 2 is 0008a03c.
eth0:  Tx descriptor 3 is 0008a03c.

Someone told me to play around with the driver options but the machine is  
in production and I cannot play much with reboots :/

Any help would be very appreciated.

Mirko

Re: 8139too not working in 2.6

[David Johnson]

On Monday 26 Apr 2004 12:35, Mirko Caserta wrote:
> Yes, I know, it's a damn cheap eth card and I should get it replaced :)
>
> Besides that, this card works just fine with 2.4.25 while it refuses to
> work on a recent 2.6 kernel. I tried 2.6.5 and even
> 2.6.5-rc2-mm2-broken-out with no luck.
>

Just to say that I'm having the exact same problem.

The card works fine with 2.6.3 but not 2.6.5. I haven't tried 2.6.4.


Regards,
David.

-- 
David Johnson
http://www.david-web.co.uk/

Re: 8139too not working in 2.6

[MNH]

On Mon, 2004-04-26 at 17:11, David Johnson wrote:
> On Monday 26 Apr 2004 12:35, Mirko Caserta wrote:
> > Yes, I know, it's a damn cheap eth card and I should get it replaced :)
> >
> > Besides that, this card works just fine with 2.4.25 while it refuses to
> > work on a recent 2.6 kernel. I tried 2.6.5 and even
> > 2.6.5-rc2-mm2-broken-out with no luck.
> >
> 
> Just to say that I'm having the exact same problem.
> 
> The card works fine with 2.6.3 but not 2.6.5. I haven't tried 2.6.4.
> 
> 
> Regards,
> David.

I have that card, its worked fine in all 2.6.x kernels.
-- 
Windows - "Its been almost an hour since I crashed. Rebooting just to
make sure everything is OK. All your data will be lost."

Re: 8139too not working in 2.6

[Gene Heskett]

On Monday 26 April 2004 07:41, David Johnson wrote:
>On Monday 26 Apr 2004 12:35, Mirko Caserta wrote:
>> Yes, I know, it's a damn cheap eth card and I should get it
>> replaced :)
>>
>> Besides that, this card works just fine with 2.4.25 while it
>> refuses to work on a recent 2.6 kernel. I tried 2.6.5 and even
>> 2.6.5-rc2-mm2-broken-out with no luck.
>
>Just to say that I'm having the exact same problem.
>
>The card works fine with 2.6.3 but not 2.6.5. I haven't tried 2.6.4.
>
Please see my other reply to Mirko.
>
>Regards,
>David.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: 8139too not working in 2.6

[David Johnson]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

Here's the full information for my machine.

Attached is my dmesg, lspci and the output of dump_pirq.pl.
This was when running 2.6.6-rc1.

Regards,
David.

-- 
David Johnson
http://www.david-web.co.uk/

[-- Attachment #2: dmesg.gz --]
[-- Type: application/x-gzip, Size: 4546 bytes --]

[-- Attachment #3: dump_pirq.gz --]
[-- Type: application/x-gzip, Size: 374 bytes --]

[-- Attachment #4: lspci.gz --]
[-- Type: application/x-gzip, Size: 3066 bytes --]

Re: 8139too not working in 2.6

[OGAWA Hirofumi]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

David Johnson <dj@david-web.co.uk> writes:

> Attached is my dmesg, lspci and the output of dump_pirq.pl.
> This was when running 2.6.6-rc1.

Looks like 8139too still isn't loaded. Could you apply the attached
patch, and send the output of dmesg after the problem was happened?

I'd like to see the debugging message of rtl8139_tx_timeout().

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 8139too-useful-txtimeout.patch --]
[-- Type: text/x-patch, Size: 2377 bytes --]


[PATCH] 8139too: more useful debug info for tx_timeout

	/* disable Tx ASAP, if not already */
	tmp8 = RTL_R8 (ChipCmd);
	if (tmp8 & CmdTxEnb)
		RTL_W8 (ChipCmd, CmdRxEnb);

The above will clear the Tx Descs. So, this prints the debugging info
before rtl8139_tx_timeout() does it. And IntrStatus etc. also prints
anytime for the debug.


---

 drivers/net/8139too.c |   26 +++++++++++---------------
 1 files changed, 11 insertions(+), 15 deletions(-)

diff -puN drivers/net/8139too.c~8139too-useful-txtimeout drivers/net/8139too.c
--- linux-2.6.6-rc2/drivers/net/8139too.c~8139too-useful-txtimeout	2004-04-22 02:14:42.000000000 +0900
+++ linux-2.6.6-rc2-hirofumi/drivers/net/8139too.c	2004-04-22 02:14:42.000000000 +0900
@@ -1677,11 +1677,17 @@ static void rtl8139_tx_timeout (struct n
 	u8 tmp8;
 	unsigned long flags;
 
-	DPRINTK ("%s: Transmit timeout, status %2.2x %4.4x "
-		 "media %2.2x.\n", dev->name,
-		 RTL_R8 (ChipCmd),
-		 RTL_R16 (IntrStatus),
-		 RTL_R8 (MediaStatus));
+	printk (KERN_DEBUG "%s: Transmit timeout, status %2.2x %4.4x %4.4x "
+		"media %2.2x.\n", dev->name, RTL_R8 (ChipCmd),
+		RTL_R16(IntrStatus), RTL_R16(IntrMask), RTL_R8(MediaStatus));
+	/* Emit info to figure out what went wrong. */
+	printk (KERN_DEBUG "%s: Tx queue start entry %ld  dirty entry %ld.\n",
+		dev->name, tp->cur_tx, tp->dirty_tx);
+	for (i = 0; i < NUM_TX_DESC; i++)
+		printk (KERN_DEBUG "%s:  Tx descriptor %d is %8.8lx.%s\n",
+			dev->name, i, RTL_R32 (TxStatus0 + (i * 4)),
+			i == tp->dirty_tx % NUM_TX_DESC ?
+				" (queue head)" : "");
 
 	tp->xstats.tx_timeouts++;
 
@@ -1694,15 +1700,6 @@ static void rtl8139_tx_timeout (struct n
 	/* Disable interrupts by clearing the interrupt mask. */
 	RTL_W16 (IntrMask, 0x0000);
 
-	/* Emit info to figure out what went wrong. */
-	printk (KERN_DEBUG "%s: Tx queue start entry %ld  dirty entry %ld.\n",
-		dev->name, tp->cur_tx, tp->dirty_tx);
-	for (i = 0; i < NUM_TX_DESC; i++)
-		printk (KERN_DEBUG "%s:  Tx descriptor %d is %8.8lx.%s\n",
-			dev->name, i, RTL_R32 (TxStatus0 + (i * 4)),
-			i == tp->dirty_tx % NUM_TX_DESC ?
-				" (queue head)" : "");
-
 	/* Stop a shared interrupt from scavenging while we are. */
 	spin_lock_irqsave (&tp->lock, flags);
 	rtl8139_tx_clear (tp);
@@ -1714,7 +1711,6 @@ static void rtl8139_tx_timeout (struct n
 		netif_wake_queue (dev);
 	}
 	spin_unlock(&tp->rx_lock);
-	
 }
 
 

_

Re: 8139too not working in 2.6

[Jorge Bernal (Koke)]

On Lunes, 26 de Abril de 2004 13:35, Mirko Caserta wrote:
> Yes, I know, it's a damn cheap eth card and I should get it replaced :)
>
> Besides that, this card works just fine with 2.4.25 while it refuses to
> work on a recent 2.6 kernel. I tried 2.6.5 and even
> 2.6.5-rc2-mm2-broken-out with no luck.
>

I have tried with 2.6.5 and now with 2.6.6-rc2-mm1 and works perfectly. This 
message is going through that card ;)

Mine is:
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)

Re: 8139too not working in 2.6

[David Johnson]

On Monday 26 Apr 2004 13:05, Jorge Bernal (Koke) wrote:
>
> I have tried with 2.6.5 and now with 2.6.6-rc2-mm1 and works perfectly.
> This message is going through that card ;)

Do you mean that both 2.6.5 and 2.6.6-rc2-mm1 worked or that only 
2.6.6-rc2-mm1 worked and 2.6.5 didn't?

>
> Mine is:
> 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
>

I should have said what my card is shouldn't I...

>From dmesg:
eth0: RealTek RTL8139 at 0xe0914000, 00:90:f5:25:91:22, IRQ 11
eth0:  Identified 8139 chip type 'RTL-8100B/8139D'

>From lspci:
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)


-- 
David Johnson
http://www.david-web.co.uk/

Re: 8139too not working in 2.6

[Jorge Bernal]

On Mon, Apr 26, 2004 at 01:13:37PM +0100, David Johnson wrote:
> On Monday 26 Apr 2004 13:05, Jorge Bernal (Koke) wrote:
> >
> > I have tried with 2.6.5 and now with 2.6.6-rc2-mm1 and works perfectly.
> > This message is going through that card ;)
> 
> Do you mean that both 2.6.5 and 2.6.6-rc2-mm1 worked or that only 
> 2.6.6-rc2-mm1 worked and 2.6.5 didn't?
> 

Both worked and I can't remember exactly but think that 2.6.3 (or .4)
also worked.

-- 
"Sólo el éxito diferencia al genio del loco"

Blog: http://www.amedias.org/koke
Web Personal: http://sindominio.net/~koke/
JID: koke@zgzjabber.ath.cx

Re: 8139too not working in 2.6

[Derek Chen-Becker]

Mirko Caserta wrote:
> 
> Yes, I know, it's a damn cheap eth card and I should get it replaced :)
> 
> Besides that, this card works just fine with 2.4.25 while it refuses to  
> work on a recent 2.6 kernel. I tried 2.6.5 and even  
> 2.6.5-rc2-mm2-broken-out with no luck.
> 

Mine works fine in 2.6.5:

eth0: RealTek RTL8139 at 0xca844000, xx:xx:xx:xx:xx:xx, IRQ 5
eth0:  Identified 8139 chip type 'RTL-8139C'
eth1: RealTek RTL8139 at 0xca895000, xx:xx:xx:xx:xx:xx, IRQ 3
eth1:  Identified 8139 chip type 'RTL-8139C'
eth0: link up, 10Mbps, half-duplex, lpa 0x0000
eth1: link up, 100Mbps, full-duplex, lpa 0x45E1

lspci:

00:03.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
00:04.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)

Derek


-- 
+---------------------------------------------------------------+
| Derek Chen-Becker                                             |
| derek@chen-becker.org                                         |
| http://chen-becker.org                                        |
|                                                               |
| PGP key available on request or from public key servers       |
| ID: 21A7FB53                                                  |
| Fngrprnt: 209A 77CA A4F9 E716 E20C  6348 B657 77EC 21A7 FB53  |
+---------------------------------------------------------------+

Re: 8139too not working in 2.6

[OGAWA Hirofumi]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

"Mirko Caserta" <mirko@mcaserta.com> writes:

> eth0: Transmit timeout, status 0c 0005 c07f media 10.

This problem looks like miss configuration of level/edge-triggerd, or
IRQ-routing problem.

The attached script may clarify the problem. Also "lspci -vvvxxx" and
output of dmesg would be useful.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dump_pirq.pl --]
[-- Type: text/x-perl, Size: 9194 bytes --]

#!/usr/bin/perl
#
# dump_pirq 1.21 2001/09/05 02:59:31
#
# A utility to parse the BIOS PCI IRQ Routing Table
#
# Copyright (C) 2000 David A. Hinds -- dahinds@users.sourceforge.net
#

#-----------------------------------------------------------------------

sub dev {
    my($devfn) = @_;
    sprintf "%02x.%d", ($devfn>>3), ($devfn&7);
}

sub print_mask
{
    my($mask) = @_;
    printf "0x%04x [", $mask;
    for (my $i = 0; $i < 16; $i++) {
	next if (!($mask & (1<<$i)));
	$mask &= ~(1<<$i);
	print (($mask) ? "$i," : "$i");
    }
    print "]\n";
}

sub row {
    my($tag, $link, $mask) = @_;
    if ($link != 0) {
	printf "  INT$tag: link 0x%02x, irq mask ", $link;
	print_mask($mask);
    }
}

sub class_of
{
    my($slot) = @_;
    open(IN, "/sbin/lspci -s $slot |");
    $_ = <IN>;
    close(IN);
    return (/^....... ([^:]+):/) ? $1 : "";
}

sub parse_pirq
{
    my($buf) = @_;

    my($p) = index($buf, "\$PIR");
    my($minor,$major,$size,$rbus,$rdev,$mask,$cvd,$mini) =
	unpack "CCSCCSLL", substr($buf, $p+4, 16);

    printf "Interrupt routing table found at address 0xf%04x:\n", $p;
    printf "  Version $major.$minor, size 0x%04x\n", $size;
    printf "  Interrupt router is device %02x:%s\n", $rbus, dev($rdev);
    print "  PCI exclusive interrupt mask: ";
    print_mask($mask);
    if ($cvd) {
	printf("  Compatible router: vendor 0x%04x device 0x%04x\n",
	       ($cvd & 0xffff), ($cvd >> 16));
    }

    $ofs = 32;
    while ($ofs < $size) {
	# Parse a table entry describing a single PCI device
	($bus, $devfn, $la, $ma, $lb, $mb, $lc, $mc, $ld, $md, $slot) =
	    unpack "CCCSCSCSCSC", substr($buf, $p+$ofs, 15);
	$s = sprintf "%02x:%s", $bus, dev($devfn);
	printf "\nDevice $s (slot $slot): %s\n", class_of($s);
	row("A", $la, $ma); row("B", $lb, $mb);
	row("C", $lc, $mc); row("D", $ld, $md);
	push(@{$dev{$la}}, $s . "1");
	push(@{$dev{$lb}}, $s . "2");
	push(@{$dev{$lc}}, $s . "3");
	push(@{$dev{$ld}}, $s . "4");
	$ofs += 16;
    }
    return ($rbus, $rdev, $cvd);
}

#-----------------------------------------------------------------------

# The link values in the interrupt routing table are implementation
# dependent.  Here, we'll try to interpret the link values for some
# known PCI bridge types.

%pIIx = (0x122e8086, "82371FB PIIX",
	 0x70008086, "82371SB PIIX3",
	 0x71108086, "82371AB PIIX4/PIIX4E",
	 0x71988086, "82443MX",
	 0x24108086, "82801AA ICH",
	 0x24208086, "82801AB ICH0",
	 0x24408086, "82801BA ICH2",
	 0x244c8086, "82801BAM ICH2-M");

%via = (0x05861106, "82C586",
	0x05961106, "82C596",
	0x06861106, "82C686");

%opti = (0xc7001045, "82C700");

%pico = (0x00021066, "PT86C523");

%ali = (0x153310b9, "Aladdin M1533");

%sis = (0x04961039, "85C496/497",
	0x00081039, "85C503");

%cyrix = (0x01001078, "5530");

%all_routers = (%pIIx, %via, %opti, %pico, %ali, %sis, %cyrix);

sub outb
{
    my($data,$port) = @_;
    open(IO, ">/dev/port") || die;
    sysseek(IO, $port, 0) || die;
    my $x = pack "C", $data;
    syswrite(IO, $x, 1);
    close(IO);
}

sub inb
{
    my($port) = @_;
    my($data);
    open(IO, "/dev/port") || die;
    sysseek(IO, $port, 0) || die;
    sysread(IO, $data, 1);
    close(IO);
    return unpack "C", $data;
}

sub dump_router
{
    my($rbus, $rdev, $cvd) = @_;
    my($buf, @p, $i, $irq);

    printf "\nInterrupt router at %02x:%s: ", $rbus, dev($rdev);
    $rf = sprintf "/proc/bus/pci/%02x/%s", $rbus, dev($rdev);
    open(IN, $rf);
    if (sysread(IN, $buf, 0x100) != 0x100) {
	print "\nCould not read router info from $rf.\n";
	exit;
    }
    close(IN);
    my $vd = unpack "L", substr($buf, 0, 4);

    if ((defined $pIIx{$vd}) || (defined $pIIx{$cvd})) {

	$name = (defined $pIIx{$vd}) ? $pIIx{$vd} : $pIIx{$cvd};
	printf "Intel $name PCI-to-ISA bridge\n";
	@p = unpack "CCCCC", substr($buf, 0x60, 5);
	for ($i = 0; $i < 4; $i++) {
	    printf "  PIRQ%d (link 0x%02x): ", $i+1, 0x60+$i;
	    print (($p[$i] < 16) ? "irq $p[$i]\n" : "unrouted\n");
	}
	print "  Serial IRQ:";
	print (($p[4] & 0x80) ? " [enabled]" : " [disabled]");
	print (($p[4] & 0x40) ? " [continuous]" : " [quiet]");
	print " [frame=", (($p[4] >> 2) & 15) + 17, "]";
	print " [pulse=", (($p[4] & 3) * 4 + 4), "]\n";

    } elsif ((defined $via{$vd}) || (defined $via{$cvd})) {

	$name = (defined $via{$vd}) ? $via{$vd} : $via{$cvd};
	printf "VIA $name PCI-to-ISA bridge\n";
	$p = unpack "L", substr($buf, 0x55, 4);
	%tag = (1, "A", 2, "B", 3, "C", 5, "D");
	foreach $link (1,2,3,5) {
	    $irq = ($p >> ($link * 4)) & 15;
	    print "  PIRQ$tag{$link} (link 0x0$link): ";
	    print ($irq ? "irq $irq\n" : "unrouted\n");
	}
	$p = unpack "C", substr($buf, 0x54, 1);
	%tag = (0 => "A", 1 => "B", 2 => "C", 3 => "D");
	foreach $n (0, 1, 2, 3) {
	    printf "  PIRQ$tag{$n} : %s\n", ($p & (1 << $n)) ? "edge" : "level";
	}

    } elsif ((defined $opti{$vd}) || (defined $opti{$cvd})) {

	$name = (defined $opti{$vd}) ? $opti{$vd} : $opti{$cvd};
	printf "OPTi $name PCI-to-ISA bridge\n";
	$p = unpack "S", substr($buf, 0xb8, 2);
	for ($i = 0; $i < 4; $i++) {
	    $irq = ($p >> ($i * 4)) & 15;
	    printf "  PCIRQ$i (link 0x%02x): ", ($i<<4)+0x02;
	    print ($irq ? "irq $irq\n" : "unrouted\n");
	}

    } elsif ((defined $pico{$vd} || defined $pico{$cvd})) {

	$name = (defined $pico{$vd}) ? $pico{$vd} : $pico{$cvd};
	printf "PicoPower $name PCI-to-ISA bridge\n";
	outb(0x10, 0x24); $p = inb(0x26);
	outb(0x11, 0x24); $p += inb(0x26)<<8;
	@tag = ("A", "B", "C", "D");
	for ($i = 0; $i < 4; $i++) {
	    $irq = ($p >> ($i * 4)) & 15;
	    print "  INT$tag[$i] (link 0x0", $i+1, "): ";
	    print ($irq ? "irq $irq\n" : "unrouted\n");
	}

    } elsif ((defined $ali{$vd} || defined $ali{$cvd})) {

	$name = (defined $ali{$vd}) ? $ali{$vd} : $ali{$cvd};
	printf "AcerLabs $name PCI-to-ISA bridge\n";
	$p = unpack "L", substr($buf, 0x48, 4);
	$t = unpack "L", substr($buf, 0x4C, 4);
	# This mapping is insane!
	@map = (0, 9, 3, 10, 4, 5, 7, 6, 1, 11, 0, 12, 0, 14, 0, 15);
	for ($i = 0; $i < 8; $i++) {
	    $irq = ($p >> ($i*4)) & 15;
	    print "  INT", $i+1, " (link ", $i+1, "): ";
	    print ($map[$irq] ? "irq $map[$irq]" : "unrouted");
	    printf " (%s)\n", ($t & (1 << $i)) ? "edge" : "level";
	}
	$s = unpack "C", substr($buf, 0x70, 1);
	print "  Serial IRQ:";
	print (($s & 0x80) ? " [enabled]" : " [disabled]");
	print (($s & 0x40) ? " [continuous]" : " [quiet]");
	print " [frame=", (($s >> 2) & 15) + 17, "]";
	print " [pulse=", (($s & 3) * 4 + 4), "]\n";

	%table = (0x44 => IDE1, 0x74 => USB, 0x75 => IDE2, 0x76 => PMU,
		  0x77 => SMB);
	foreach $n (keys %table) {
	    $p = unpack "C", substr($buf, $n, 1);
	    printf "  %s level to edge: %s\n", $table{$n},
		($p & 4) ? "enable" : "disable";
	}

    } elsif ((defined $sis{$vd}) || (defined $sis{$cvd})) {

	$name = (defined $sis{$vd}) ? $sis{$vd} : $sis{$cvd};
	printf "SiS $name PCI-to-ISA bridge\n";
	$base = ($name eq "85C496/497") ? 0xc0 : 0x41;
	@p = unpack "CCCC", substr($buf, $base, 4);
	@tag = ("A", "B", "C", "D");
	for ($i = 0; $i < 4; $i++) {
	    $irq = ($p[$i] & 0x80) ? 0 : ($p[$i] & 0x0f);
	    printf "  INT$tag[$i] (link 0x%02x): ", $i+$base;
	    print ($irq ? "irq $irq\n" : "unrouted\n");
	}

    } elsif ((defined $cyrix{$vd}) || (defined $cyrix{$cvd})) {

	$name = (defined $cyrix{$vd}) ? $cyrix{$vd} : $cyrix{$cvd};
	printf "CYRIX $name PCI-to-ISA bridge\n";
	$p = unpack "S", substr($buf, 0x5c, 2);
	%tag = ("A", "B", "C", "D");
	for ($i = 0; $i < 4; $i++) {
	    $irq = ($p >> ($i * 4)) & 15;
	    printf "  PIRQ$tag{$i} (link 0x%02x): ", $i+1;
	    print ($irq ? "irq $irq\n" : "unrouted\n");
	}

    } else {

	printf("unknown vendor 0x%04x device 0x%04x\n",
	       ($vd & 0xffff), ($vd >> 16));
	foreach $k (sort keys %dev) {
	    next if ($k == 0);
	    printf "  PIRQ? (link 0x%02x): ", $k;
	    $irq = 0;
	    foreach $d (@{$dev{$k}}) {
		$d =~ /(..):(..)\..(.)/;
		($bus,$dev,$pin) = ($1,$2,$3);
		for ($fn = 0; $fn < 8; $fn++) {
		    open(IN, "/proc/bus/pci/$bus/$dev.$fn") || last;
		    sysread(IN, $buf, 0x100);
		    close(IN);
		    ($i,$p) = unpack "CC", substr($buf, 0x3c, 2);
		    $irq = $i if (($p == $pin) && $i && ($i != 255));
		}
	    }
	    print ($irq ? "irq $irq\n" : "unrouted?\n");
	}
    }
    print "  PIC Level mask: "; print_mask((inb(0x4d1)<<8) + inb(0x4d0));
}

#-----------------------------------------------------------------------

# Grab the BIOS from 0xf0000-0xfffff
open(IN, "/dev/mem") || die "cannot open /dev/mem\n";
sysseek(IN, 0xf0000, 0) || die;
die if (sysread(IN, $buf, 0x10000) != 0x10000);
close(IN);

if (index($buf, "\$PIR") >= 0) {

    # Dump the PIRQ table, and the router information
    ($rbus, $rdev, $cvd) = parse_pirq($buf);
    dump_router($rbus, $rdev, $cvd);

} else {

    # Scan for any interrupt router device we recognize
    print "No PCI interrupt routing table was found.\n";
    open(DEV, "/proc/bus/pci/devices");
    while (<DEV>) {
	($rbus,$rdev,$vd) = /^(..)(..)\s+(........)/;
	$rbus = hex($rbus); $rdev = hex($rdev); $vd = hex($vd);
	$vd = (($vd & 0xffff0000) >> 16) | (($vd & 0xffff) << 16);
	if (defined $all_routers{$vd}) {
	    dump_router($rbus, $rdev, $vd);
	    $nr++;
	}
    }
    print "\nNo known PCI interrupt routers were found.\n" if (!$nr);

}

Re: 8139too not working in 2.6

[Mirko Caserta]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Mon, 26 Apr 2004 21:58:05 +0900, OGAWA Hirofumi  
<hirofumi@mail.parknet.co.jp> wrote:

> "Mirko Caserta" <mirko@mcaserta.com> writes:
>
>> eth0: Transmit timeout, status 0c 0005 c07f media 10.
>
> This problem looks like miss configuration of level/edge-triggerd, or
> IRQ-routing problem.
>
> The attached script may clarify the problem. Also "lspci -vvvxxx" and
> output of dmesg would be useful.

I have attached a tarball with output from dmesg, lspci -vvvxxx, cat  
/proc/interrupts and your dump_pirq.pl utility.

Please note that before booting the 2.6.6-rc2-mm2 kernel I got into the  
BIOS and disabled "Assign IRQ for USB" which is why lspci and dmesg show  
irq 0 assigned to the USB chips.

Besides that change in the BIOS, everything is just the same between the  
reboots, apart from the card not properly working in 2.6.6-rc2-mm2 :/

Anyway, it doesn't look like an irq problem to me. It looks more like a  
wrong detection of the TX triggering level in the driver.

Thanks again, Mirko.


[-- Attachment #2: carbon-kernel-debug.tar.bz2 --]
[-- Type: application/bzip2, Size: 12964 bytes --]

Re: 8139too not working in 2.6

[OGAWA Hirofumi]

"Mirko Caserta" <mirko@mcaserta.com> writes:

> Anyway, it doesn't look like an irq problem to me. It looks more like
> a  wrong detection of the TX triggering level in the driver.

In interrupts-2.6.6-rc2-mm2-broken-out,

           CPU0       CPU1       
  0:     103394         48    IO-APIC-edge  timer
  1:        157          0    IO-APIC-edge  i8042
  5:          2          1    IO-APIC-edge  eth0
                              ^^^^^^^^^^^^-- wrong
  8:          2          0    IO-APIC-edge  rtc
  9:          0          0   IO-APIC-level  acpi
 11:          3          1    IO-APIC-edge  i91u
 12:         87          0    IO-APIC-edge  i8042
 14:       1068          2    IO-APIC-edge  ide0
 15:        953          1    IO-APIC-edge  ide1

The above must be IO-APIC-level.
And the following is interesting one.

    ACPI: ACPI tables contain no PCI IRQ routing entries
    PCI: Invalid ACPI-PCI IRQ routing table
    PCI: Probing PCI hardware
    PCI: Using IRQ router default [1106/3091] at 0000:00:00.0
    PCI BIOS passed nonexistent PCI bus 0!
    PCI BIOS passed nonexistent PCI bus 0!
    PCI BIOS passed nonexistent PCI bus 0!
    PCI BIOS passed nonexistent PCI bus 0!
    PCI BIOS passed nonexistent PCI bus 0!
    PCI BIOS passed nonexistent PCI bus 1!
    PCI BIOS passed nonexistent PCI bus 0!

Um.. can you try "pci=noacpi" or "acpi=off"?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: 8139too not working in 2.6 (works now)

[Mirko Caserta]

I tried "acpi=off" and it worked like a charm. He's the new  
/proc/interrupts:

carbon:~# cat /proc/interrupts
            CPU0       CPU1
   0:     857627         12    IO-APIC-edge  timer
   1:       1073          0    IO-APIC-edge  i8042
   2:          0          0          XT-PIC  cascade
   8:          1          1    IO-APIC-edge  rtc
  12:         87          0    IO-APIC-edge  i8042
  14:       4103          2    IO-APIC-edge  ide0
  15:       4900          2    IO-APIC-edge  ide1
  21:       4505          1   IO-APIC-level  eth0
  27:       1484          0   IO-APIC-level  i91u, uhci_hcd, uhci_hcd,  
uhci_hcd
NMI:          0          0
LOC:     857482     857455
ERR:          0
MIS:          0

Hope this helps someone else too.

Thanks a lot, Mirko.

On Tue, 27 Apr 2004 00:14:29 +0900, OGAWA Hirofumi  
<hirofumi@mail.parknet.co.jp> wrote:

> "Mirko Caserta" <mirko@mcaserta.com> writes:
>
>> Anyway, it doesn't look like an irq problem to me. It looks more like
>> a  wrong detection of the TX triggering level in the driver.
>
> In interrupts-2.6.6-rc2-mm2-broken-out,
>
>            CPU0       CPU1
>   0:     103394         48    IO-APIC-edge  timer
>   1:        157          0    IO-APIC-edge  i8042
>   5:          2          1    IO-APIC-edge  eth0
>                               ^^^^^^^^^^^^-- wrong
>   8:          2          0    IO-APIC-edge  rtc
>   9:          0          0   IO-APIC-level  acpi
>  11:          3          1    IO-APIC-edge  i91u
>  12:         87          0    IO-APIC-edge  i8042
>  14:       1068          2    IO-APIC-edge  ide0
>  15:        953          1    IO-APIC-edge  ide1
>
> The above must be IO-APIC-level.
> And the following is interesting one.
>
>     ACPI: ACPI tables contain no PCI IRQ routing entries
>     PCI: Invalid ACPI-PCI IRQ routing table
>     PCI: Probing PCI hardware
>     PCI: Using IRQ router default [1106/3091] at 0000:00:00.0
>     PCI BIOS passed nonexistent PCI bus 0!
>     PCI BIOS passed nonexistent PCI bus 0!
>     PCI BIOS passed nonexistent PCI bus 0!
>     PCI BIOS passed nonexistent PCI bus 0!
>     PCI BIOS passed nonexistent PCI bus 0!
>     PCI BIOS passed nonexistent PCI bus 1!
>     PCI BIOS passed nonexistent PCI bus 0!
>
> Um.. can you try "pci=noacpi" or "acpi=off"?

Re: 8139too not working in 2.6 (works now)

[OGAWA Hirofumi]

"Mirko Caserta" <mirko@mcaserta.com> writes:

> I tried "acpi=off" and it worked like a charm. He's the new
> /proc/interrupts:

Sorry, I don't know whether this is ACPI subsystem's bug or not.
Probably ACPI peoples can look it...

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>