yenta_socket hangs sager laptop in kernel 2.4.6

yenta_socket hangs sager laptop in kernel 2.4.6

[Martin Murray]

Hi,

	I have a sager 9820 laptop with an Ali chipset and a TI 1251B
pcmcia socket. The stock redhat 7.0 kernel works fine (2.2.16-22),
however, booting 2.4.3, 2.4.5, or 2.4.6 all cause the computer to hang
about a second and a half after loading yenta_socket. Someone suggested
that it might be a pci irq routing problem, and I suspect it may still be
an irq problem (see ahead), however, both 2.2.16 and 2.4.6 assign it irq
11. For brevity, I have omitted /proc/pci, but, if someone wants it, or
any other information, I'd be happy to pass it on. 
	To do as much as I could, before I troubled all of you, I booted
in single user mode, and loaded the yenta_socket with the debug output. 
This is what I crudely copied down on a legal pad, from output on the
screen:
(the actual output was different, I just copied the information)
exca_readb c68307e8 6 0
exca_writeb c6807e8 43 0 
exca_writew c6807e8 28 0
exca_writew c6807e8 2a 0
exca_writew c6807e8 2c 0
exca_readb c68307e8 6 0
exca_writeb c6807e8 44 0
exca_writew c6807e8 30 0
exca_writew c6807e8 32 0
exca_writew c6807e8 34 0
exca_readb c6807e8 3 40
exca_writeb c6807e8 3 50

The repeating block (read byte, write byte, 3xwrite word) seems to be the
end of yenta_clear_maps() which is the last thing done by yenta_init() -
so I suspect that the yenta_socket() stuff is loading correctly. The last
two operations seem to be enabling interrupts, and then a short moment
later, the machine hangs. I suspect that the last call is
yenta_set_socket() because that is the only explicit exca_writeb() to
I365_INTCTL. Does anyone have any suggestions? I think its important to
remember that the machine does hang immediately, I generally have time to
scratch off an 'ls' before the machine freezes. 

Thank you, Martin Murray 

-- 
Martin Murray, <mmurray@deepthought.org>
- What is Industrial Music? It's the sound of angry 
  Belgians having a fight with a washing machine.
Fear: Seeing B8:00:4C:CD:21, and knowing what it means.

Re: yenta_socket hangs sager laptop in kernel 2.4.6

[Linus Torvalds]

In article <Pine.LNX.4.21.0107112003170.17294-100000@cobalt.deepthought.org>,
>
>	To do as much as I could, before I troubled all of you, I booted
>in single user mode, and loaded the yenta_socket with the debug output.

Hey, thanks. That's very helpful.

>exca_readb c6807e8 3 40
>exca_writeb c6807e8 3 50
>
>The repeating block (read byte, write byte, 3xwrite word) seems to be the
>end of yenta_clear_maps() which is the last thing done by yenta_init() -
>so I suspect that the yenta_socket() stuff is loading correctly. The last
>two operations seem to be enabling interrupts, and then a short moment
>later, the machine hangs. I suspect that the last call is
>yenta_set_socket() because that is the only explicit exca_writeb() to
>I365_INTCTL.

No, it's "int ti_intctl()", and it's the part that enables PCI
interrupts for the TI yenta controllers.  You missed it because it's
hidden in the TI-specific stuff in ti113x.h. 

Can you do two things for me?

 1) your debug output seems to imply that the thing still has
    I365_PC_RESET set. In ti_initctl(), how about making the

	new = reg & ~I365_INTR_ENA;

    be a

	new = reg & ~(I365_INTR_ENA | I365_PC_RESET);

 2) do a "lspci -vvvxx" as root, and also do a "dump_pirq" and send it
    all by email to me..

Also, does it matter if you have anything plugged in or not?

		Linus

-----
#!/usr/bin/perl
#
# dump_pirq 1.20 2000/12/19 19:19:52
#
# 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";
	print "  Level mask: "; print_mask((inb(0x4d1)<<8) + inb(0x4d0));

    } 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");
	}

    } 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);
	# 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]\n" : "unrouted\n");
	}
	$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";

    } 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");
	}
    }

}

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

# 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: yenta_socket hangs sager laptop in kernel 2.4.6

[Linus Torvalds]

Well, I think I've found the reason for your hang.

Your video card is also on irq11.

And I bet you don't have a driver that knows about it.

So let's run a thought experiment:
 - enabling yenta enables the irq routing for "link 0x01", which is the
   first IRQ input into the southbridge.
 - some time later a vertical refresh happens
 - the video card, that is also routed to link 0x01, raises the vertical
   refresh irq.
 - Linux has a irq handler for irq11, but no yenta state changes, so the
   irq handler returns immediately without doing anything.
 - the video card (being a PCI card) still raises the irq. Forever. Repeat.

Ho humm.. I'd love to test this out some way, but the video card does seem
to be physically routed to the same southbridge interupt pin, so while I
can move that interrupt around, the video card will always move with it.
So it wouldn't help, for example, to try to make pci-irq.c try to select
another irq line.

So you can try two things:
 - if you have a BIOS setting for VGA interrupts, turn it OFF.
 - if you don't (or you just think you're too manly to resort to BIOS
   settings), you could try to add something like this as a hack to
   yenta.c (somewhere in the init routines)

	struct pci_dev * video;

	video = pci_find_class(PCI_CLASS_DISPLAY_VGA, NULL);
	if (video) {
		char * base = ioremap(pci_resource_start(dev, 2), 4096);

		/* Turn off interrupts for ATI Rage graphics card */
		writel(0, base + 0x40);
	}

Note, that "writel()" may or may not work. It's a guess from some rather
limited documentation, namely the header #defines of the XFree86 driver.

The above is a complete hack, and assumes that the only VGA-compatible
controller in the system is an ATI card. But if you can't find a VGA irq
enable thing in the BIOS setup, it might be worth trying.

		Linus

Re: yenta_socket hangs sager laptop in kernel 2.4.6

[Martin Murray]

Sorry, I've been away for a few days. 

> Well, I think I've found the reason for your hang.
 
> Your video card is also on irq11.

So does my usb controller. It seems that all the integrated stuff use IRQ
11. 

> And I bet you don't have a driver that knows about it.

You know. 2.2.19 uses my cardbus controller on IRQ 11 without a
problem. Could it be something in the way the yenta_socket driver sets up
the controller? I was thinking of dumping the read/write's from the i82365
from 2.2.19, and comparing it to the yenta_socket driver. Do you think
this is worthwhile? I know your time is precious, but I'd like to fix this
problem and will happily do the work if you can spare a few brain cycles
on the problem. ;)

Thanks, Martin

Re: yenta_socket hangs sager laptop in kernel 2.4.6

[Linus Torvalds]

On Tue, 17 Jul 2001, Martin Murray wrote:
>
> > And I bet you don't have a driver that knows about it.
>
> You know. 2.2.19 uses my cardbus controller on IRQ 11 without a
> problem.

Does it actually _use_ the cardbus PCI interrupt at all? At least older
versions of the external pcmcia package didn't use the PCI interrupt by
default at all, and relied on polling the state and the old ISA interrupts
instead..

		Linus

Re: yenta_socket hangs sager laptop in kernel 2.4.6

[Martin Murray]

> On Tue, 17 Jul 2001, Martin Murray wrote:
> >
> > > And I bet you don't have a driver that knows about it.
> >
> > You know. 2.2.19 uses my cardbus controller on IRQ 11 without a
> > problem.
> 
> Does it actually _use_ the cardbus PCI interrupt at all? At least older
> versions of the external pcmcia package didn't use the PCI interrupt by
> default at all, and relied on polling the state and the old ISA interrupts
> instead.. 

 Near as I can tell, it's listed in /proc/interrupts, and
inserting/removing cards definately causes the counter to increment. I'm
using pcmcia-cs-3.1.27's i82365. Also, dmesg shows it requesting the PCI
IRQ. Ie, I get messages like:

...
Linux PCMCIA Card Services 3.1.27
  kernel build: 2.2.19 #2 Sat Jul 14 12:21:14 EDT 2001
  options:  [pci] [cardbus] [apm]
PCI routing table version 1.0 at 0xfdf60
  00:03.0 -> irq 11
  00:03.1 -> irq 11
Intl PCIC probe:
  TI 1251B rev 00 PCI-to-CardBus at slot 00:03, mem 0x6800000
...

I just inserted and removed my aironet card, and the value in
/proc/interrupts went from 9 to 14.. 

Could this be a problem in yenta_socket()'s initialization sequence?

Thanks, Martin

Re: yenta_socket hangs sager laptop in kernel 2.4.6

[kuznet]

Hello!

> You know. 2.2.19 uses my cardbus controller on IRQ 11 without a
> problem. Could it be something in the way the yenta_socket driver sets up
> the controller? I was thinking of dumping the read/write's from the i82365
> from 2.2.19, and comparing it to the yenta_socket driver. Do you think
> this is worthwhile?

Did you make any progress on this?


I have similar problem. Probably, we could cooperate to find a way to solve
this.

Seems, you are right, yenta.c corrupts something in hardware
and the problem is not related to irqs. Observations are:


* No irqs are generated at all after lockup. Printk added at do_IRQ, no activity.
  (Moreover, here yenta irq is not shared with vga, but shared with firewire
   port though.) Nothing. I did not find any software activity at all.
* No activity at pcmcia is required to lockup. Loading yenta_socket is enough.
* Unloading yenta before lockup happened does not help, i.e. something
  is corrupted at time of yenta_init().
* Lockup _inevitably_ happens when yenta_init was executed once
  and I make any operation from set:
  1. any call to APM bios, except for cpu idle.
  2. Pressing any hotkey, including change of LCD brightness
     (Sic! The last event is _absolutely_ invisible to software,
      so that yenta_init does something terrible with hardware).

linux-2.2 with pcmcia does work, so that puzzle really can be solved
comparing operations made by both implementations. Did you make this?

Alexey Kuznetsov

Re: yenta_socket hangs sager laptop in kernel 2.4.6

[Ben Greear]

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

kuznet@ms2.inr.ac.ru wrote:
> 
> Hello!
> 
> > You know. 2.2.19 uses my cardbus controller on IRQ 11 without a
> > problem. Could it be something in the way the yenta_socket driver sets up
> > the controller? I was thinking of dumping the read/write's from the i82365
> > from 2.2.19, and comparing it to the yenta_socket driver. Do you think
> > this is worthwhile?
> 
> Did you make any progress on this?
> 
> I have similar problem. Probably, we could cooperate to find a way to solve
> this.
> 

This sounds suspiciously like the problem(s) I'm seeing with my Sony VAIO
and the 2.4.5 and 2.4.6* kernels.  It seems to work with RH 7.1 kernel
(2.4.2+) though....  I did notice some messages about IRQ routing problems,
but I'm not sure if they are really a problem...  Here is a piece of the boot sequence
from the 2.4.2 RH 7.1 kernel, via dmesg:
.....
Via 686a audio driver 1.1.14b
PCI: Found IRQ 10 for device 00:07.5
IRQ routing conflict in pirq table for device 00:07.5
IRQ routing conflict in pirq table for device 00:07.6
PCI: The same IRQ used for device 00:0a.1
PCI: The same IRQ used for device 00:10.0
via82cxxx: timeout while reading AC97 codec (0xAA0000)
.....

The full dmesg output is attached in case that helps.


> Seems, you are right, yenta.c corrupts something in hardware
> and the problem is not related to irqs. Observations are:
> 
> * No irqs are generated at all after lockup. Printk added at do_IRQ, no activity.
>   (Moreover, here yenta irq is not shared with vga, but shared with firewire
>    port though.) Nothing. I did not find any software activity at all.
> * No activity at pcmcia is required to lockup. Loading yenta_socket is enough.
> * Unloading yenta before lockup happened does not help, i.e. something
>   is corrupted at time of yenta_init().
> * Lockup _inevitably_ happens when yenta_init was executed once
>   and I make any operation from set:
>   1. any call to APM bios, except for cpu idle.
>   2. Pressing any hotkey, including change of LCD brightness
>      (Sic! The last event is _absolutely_ invisible to software,
>       so that yenta_init does something terrible with hardware).
> 
> linux-2.2 with pcmcia does work, so that puzzle really can be solved
> comparing operations made by both implementations. Did you make this?
> 
> Alexey Kuznetsov
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

[-- Attachment #2: foo.txt --]
[-- Type: text/plain, Size: 8156 bytes --]

Linux version 2.4.2-2 (root@porky.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 8 20:41:30 EDT 2001
BIOS-provided physical RAM map:
 BIOS-e820: 000000000009f800 @ 0000000000000000 (usable)
 BIOS-e820: 0000000000000800 @ 000000000009f800 (reserved)
 BIOS-e820: 0000000000015c00 @ 00000000000ea400 (reserved)
 BIOS-e820: 0000000007ef0000 @ 0000000000100000 (usable)
 BIOS-e820: 000000000000fc00 @ 0000000007ff0000 (ACPI data)
 BIOS-e820: 0000000000000400 @ 0000000007fffc00 (ACPI NVS)
 BIOS-e820: 0000000000020000 @ 00000000fffe0000 (reserved)
On node 0 totalpages: 32752
zone(0): 4096 pages.
zone DMA has max 32 cached pages.
zone(1): 28656 pages.
zone Normal has max 223 cached pages.
zone(2): 0 pages.
zone HighMem has max 1 cached pages.
Kernel command line: auto BOOT_IMAGE=linux ro root=305 BOOT_FILE=/boot/vmlinuz-2.4.2-2
Initializing CPU#0
Detected 800.052 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1595.80 BogoMIPS
Memory: 126412k/131008k available (1365k kernel code, 4208k reserved, 92k data, 236k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
VFS: Diskquotas version dquot_6.5.0 initialized
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: AMD Duron(tm) Processor stepping 01
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfd83d, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
  got res[10000000:10000fff] for resource 0 of Texas Instruments PCI1420
  got res[10001000:10001fff] for resource 0 of Texas Instruments PCI1420 (#2)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 83866kB/27955kB, 256 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1
    ide0: BM-DMA at 0x1c40-0x1c47, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1c48-0x1c4f, BIOS settings: hdc:DMA, hdd:pio
hda: FUJITSU MHM2100AT, ATA DISK drive
hdc: HITACHI DVD-ROM GD-S200, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 19640880 sectors (10056 MB) w/2048KiB Cache, CHS=1222/255/63, UDMA(33)
Partition check:
 hda: hda1 hda2 < hda5 hda6 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Serial driver version 5.02 (2000-08-09) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10d
md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md.c: sizeof(mdp_super_t) = 4096
autodetecting RAID arrays
autorun ...
... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 236k freed
Adding Swap: 265032k swap-space (priority -1)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.251 $ time 20:53:29 Apr  8 2001
usb-uhci.c: High bandwidth mode enabled
PCI: Assigned IRQ 9 for device 00:07.2
PCI: The same IRQ used for device 00:07.3
PCI: The same IRQ used for device 00:0e.0
PCI: Setting latency timer of device 00:07.2 to 64
usb-uhci.c: USB UHCI at I/O 0x1c00, IRQ 9
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 9 for device 00:07.3
PCI: The same IRQ used for device 00:07.2
PCI: The same IRQ used for device 00:0e.0
PCI: Setting latency timer of device 00:07.3 to 64
usb-uhci.c: USB UHCI at I/O 0x1c20, IRQ 9
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict!
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq=<none or set by other means> dma=<none or set by other means>
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,COMPAT,ECP]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport_pc: Via 686A parallel port: io=0x378, irq=7
8139too Fast Ethernet driver 0.9.15 loaded
PCI: Assigned IRQ 10 for device 00:10.0
IRQ routing conflict in pirq table for device 00:07.5
IRQ routing conflict in pirq table for device 00:07.6
PCI: The same IRQ used for device 00:0a.1
PCI: Setting latency timer of device 00:10.0 to 64
eth0: RealTek RTL8139 Fast Ethernet at 0xc883d800, 08:00:46:1d:7b:d8, IRQ 10
eth0:  Identified 8139 chip type 'RTL-8139C'
eth0: Setting half-duplex based on auto-negotiated partner ability 0000.
Linux PCMCIA Card Services 3.1.22
  options:  [pci] [cardbus] [pm]
PCI: Assigned IRQ 9 for device 00:0a.0
PCI: Found IRQ 10 for device 00:0a.1
IRQ routing conflict in pirq table for device 00:07.5
IRQ routing conflict in pirq table for device 00:07.6
PCI: The same IRQ used for device 00:10.0
Yenta IRQ list 0808, PCI irq9
Socket status: 30000010
Yenta IRQ list 0808, PCI irq10
Socket status: 30000010
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
eth1: NE2000 (DL10022 rev 30): io 0x300, irq 3, hw_addr 00:50:BA:70:69:F1
eth2: NE2000 (DL10022 rev 30): io 0x320, irq 11, hw_addr 00:50:BA:70:69:EC
NET4: Linux IPX 0.46 for NET4.0
IPX Portions Copyright (c) 1995 Caldera, Inc.
IPX Portions Copyright (c) 2000, 2001 Conectiva, Inc.
NET4: AppleTalk 0.18a for Linux NET4.0
eth1: MII is missing!
eth1: found link beat
eth1: autonegotiation complete: 100baseT-FD selected
eth2: MII is missing!
eth2: found link beat
eth2: autonegotiation complete: 100baseT-FD selected
mtrr: type mismatch for f5000000,800000 old: write-back new: write-combining
mtrr: type mismatch for f5000000,800000 old: write-back new: write-combining
Via 686a audio driver 1.1.14b
PCI: Found IRQ 10 for device 00:07.5
IRQ routing conflict in pirq table for device 00:07.5
IRQ routing conflict in pirq table for device 00:07.6
PCI: The same IRQ used for device 00:0a.1
PCI: The same IRQ used for device 00:10.0
via82cxxx: timeout while reading AC97 codec (0xAA0000)
ac97_codec: AC97 Audio codec, id: 0x4144:0x5348 (Analog Devices AD1881A)
via82cxxx: board #1 at 0x1000, IRQ 5
hdc: ATAPI 24X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12

Re: yenta_socket hangs sager laptop in kernel 2.4.6

[Gerd Knorr]

>  Seems, you are right, yenta.c corrupts something in hardware
>  and the problem is not related to irqs.

It is not IRQ-related at all.

>  Observations are:
>  
>  * No irqs are generated at all after lockup. Printk added at do_IRQ, no activity.
>    (Moreover, here yenta irq is not shared with vga, but shared with firewire
>     port though.) Nothing. I did not find any software activity at all.
>  * No activity at pcmcia is required to lockup. Loading yenta_socket is enough.
>  * Unloading yenta before lockup happened does not help, i.e. something
>    is corrupted at time of yenta_init().
>  * Lockup _inevitably_ happens when yenta_init was executed once
>    and I make any operation from set:
>    1. any call to APM bios, except for cpu idle.
>    2. Pressing any hotkey, including change of LCD brightness
>       (Sic! The last event is _absolutely_ invisible to software,
>        so that yenta_init does something terrible with hardware).

Same problem here.  I've spend some time today to figure what is going
on.  Workaround:

---------------------------- cut here -----------------------------
--- 2.4.9/drivers/pcmcia/yenta.c.fix	Mon Aug 20 11:02:23 2001
+++ 2.4.9/drivers/pcmcia/yenta.c	Mon Aug 20 14:21:33 2001
@@ -729,7 +729,7 @@
 	if (type & IORESOURCE_IO) {
 		align = 1024;
 		size = 256;
-		min = PCIBIOS_MIN_IO;
+		min = 0x4000 /* PCIBIOS_MIN_IO */;
 		max = 0xffff;
 	}
 		
---------------------------- cut here -----------------------------

Looks like a ressource conflict to me.  The kernel gives I/O ranges to
the cardbus socket which it thinks are free but which are *not* free for
some reason (and probably used for APM stuff).  BIOS bug?  PCI quirks
time?

/proc/ioports looks like this (with patch):

0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
02f8-02ff : nsc-ircc
03c0-03df : vesafb
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1100-110f : Intel Corporation 82440MX EIDE Controller
  1100-1107 : ide0
1200-121f : Intel Corporation 82440MX USB Universal Host Controller
  1200-121f : usb-uhci
1500-153f : Intel Corporation 82440MX AC'97 Audio Controller
  1500-153f : Intel 440MX
1600-16ff : Intel Corporation 82440MX AC'97 Audio Controller
  1600-16ff : Intel 440MX
1700-177f : PCI device 8086:7196 (Intel Corporation)
1800-18ff : PCI device 8086:7196 (Intel Corporation)
3000-30ff : ATI Technologies Inc 3D Rage P/M Mobility
3e00-3eff : Realtek Semiconductor Co., Ltd. RTL-8139
  3e00-3eff : 8139too
4000-40ff : PCI CardBus #01
4400-44ff : PCI CardBus #01

lspci says:

00:00.0 Host bridge: Intel Corporation 82440MX I/O Controller (rev 01)
	Subsystem: Mitac: Unknown device 7722
	Flags: bus master, medium devsel, latency 64

00:00.1 Multimedia audio controller: Intel Corporation 82440MX AC'97 Audio Controller
	Subsystem: Mitac: Unknown device 7722
	Flags: bus master, fast devsel, latency 0, IRQ 5
	I/O ports at 1600 [size=256]
	I/O ports at 1500 [size=64]

00:00.2 Modem: Intel Corporation: Unknown device 7196 (prog-if 00 [Generic])
	Subsystem: Mitac: Unknown device 7722
	Flags: bus master, fast devsel, latency 0, IRQ 5
	I/O ports at 1800 [size=256]
	I/O ports at 1700 [size=128]

00:07.0 ISA bridge: Intel Corporation 82440MX PCI to ISA Bridge (rev 01)
	Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corporation 82440MX EIDE Controller (prog-if 80 [Master])
	Flags: bus master, medium devsel, latency 64
	I/O ports at 1100 [size=16]

00:07.2 USB Controller: Intel Corporation 82440MX USB Universal Host Controller (prog-if 00 [UHCI])
	Flags: bus master, medium devsel, latency 240, IRQ 11
	I/O ports at 1200 [size=32]

00:07.3 Bridge: Intel Corporation 82440MX Power Management Controller
	Flags: medium devsel

00:08.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
	Subsystem: Mitac: Unknown device 7722
	Flags: bus master, medium devsel, latency 168, IRQ 10
	Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=01, subordinate=04, sec-latency=176
	Memory window 0: 10400000-107ff000 (prefetchable)
	Memory window 1: 10800000-10bff000
	I/O window 0: 00004000-000040ff
	I/O window 1: 00004400-000044ff
	16-bit legacy interface ports at 0001

00:09.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mobility (rev 64) (prog-if 00 [VGA])
	Subsystem: Mitac: Unknown device 7722
	Flags: bus master, stepping, medium devsel, latency 0
	Memory at c0000000 (32-bit, non-prefetchable) [size=16M]
	I/O ports at 3000 [size=256]
	Memory at c1000000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at <unassigned> [disabled] [size=128K]
	Capabilities: [5c] Power Management version 1

00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
	Subsystem: Mitac: Unknown device 7722
	Flags: bus master, medium devsel, latency 128, IRQ 11
	I/O ports at 3e00 [size=256]
	Memory at e9100000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [50] Power Management version 2

00:0b.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00cd (rev 02) (prog-if 10 [OHCI])
	Subsystem: Mitac: Unknown device 7722
	Flags: bus master, medium devsel, latency 64, IRQ 10
	Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [60] Power Management version 1

  Gerd

-- 
Damn lot people confuse usability and eye-candy.

Re: yenta_socket hangs sager laptop in kernel 2.4.6

[Alexey Kuznetsov]

Hello!

> Same problem here.  I've spend some time today to figure what is going
> on.  Workaround:
> 
> ---------------------------- cut here -----------------------------
> --- 2.4.9/drivers/pcmcia/yenta.c.fix	Mon Aug 20 11:02:23 2001
> +++ 2.4.9/drivers/pcmcia/yenta.c	Mon Aug 20 14:21:33 2001
> @@ -729,7 +729,7 @@
>  	if (type & IORESOURCE_IO) {
>  		align = 1024;
>  		size = 256;
> -		min = PCIBIOS_MIN_IO;
> +		min = 0x4000 /* PCIBIOS_MIN_IO */;
>  		max = 0xffff;
>  	}
>  		
> ---------------------------- cut here -----------------------------

I do not know how to thank you... You saved my life. :-)
How did you guess this?



> Looks like a ressource conflict to me.  The kernel gives I/O ranges to
> the cardbus socket which it thinks are free but which are *not* free for
> some reason (and probably used for APM stuff).  BIOS bug?  PCI quirks
> time?

The same hardware is here, Mitac M722. :-) BTW what bios is installed
on your one?

Anyway, Windows with the _same_ bios manages to guess and to reserve
a few of ports tagged as some obscure "motherboard resources":
230-233, 398-399, 4d0-4d1, 1000-103f(!), 1400-140f(!) and 3810-381f.
yenta_socket eats ones marked with !. At least 1400 is really critical,
it is interface to SM mode. So, probably, more correct fix
is something sort of:

--- mitac-quirk.c

#include <linux/config.h>
#include <linux/version.h>
#include <linux/module.h>

#include <linux/kernel.h>
#include <linux/ioport.h>
#include <linux/init.h>

static __init int mitac_init(void)
{
	/* No guesses */
	request_region(0x230, 4, "Mitac");

	/* Hmm... look at 0x64 @ 0:7.3, 0x398 is set there, no doubts.
	 * What is this? */
	request_region(0x398, 2, "Mitac");

	/* 82440MX: ELCR 1&2, Edge/Level Control Regs */
	request_region(0x4D0, 2, "82440MX INT CNTRL");

	/* No guesses */
	request_region(0x1000, 0x40, "Mitac");

	/* SMBus: selected with bits 4:15 at 0x90 @ 0:7.3 */
	request_region(0x1400, 0x10, "82440MX SMBus");

	/* No guesses. */
	request_region(0x3810, 0x10, "Mitac");
	return 0;
}

module_init(mitac_init);

/*
 * Local variables:
 * compile-command: "gcc -DMODULE -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -c mitac.c"
 * End:
 */


Alexey

Re: yenta_socket hangs sager laptop in kernel 2.4.6

[Gerd Knorr]

In lists.linux.kernel, you wrote:
>  Hello!
>  
> > Same problem here.  I've spend some time today to figure what is going
> > on.  Workaround:
> > -		min = PCIBIOS_MIN_IO;
> > +		min = 0x4000 /* PCIBIOS_MIN_IO */;
>  
>  I do not know how to thank you... You saved my life. :-)
>  How did you guess this?

Long trial-and-error session.  Deactivate code and see if it still does
crash to narrow down the code lines which trigger the lockup.  Once I've
figured that enabling the I/O-Windows triggers the lookup the guess was
easy ...

> > Looks like a ressource conflict to me.  The kernel gives I/O ranges to
> > the cardbus socket which it thinks are free but which are *not* free for
> > some reason (and probably used for APM stuff).  BIOS bug?  PCI quirks
> > time?
>  
>  The same hardware is here, Mitac M722. :-) BTW what bios is installed
>  on your one?

"SYSTEM BIOS R1.02"

>  Anyway, Windows with the _same_ bios manages to guess and to reserve
>  a few of ports tagged as some obscure "motherboard resources":
>  230-233, 398-399, 4d0-4d1, 1000-103f(!), 1400-140f(!) and 3810-381f.
>  yenta_socket eats ones marked with !. At least 1400 is really critical,
>  it is interface to SM mode.

0x1000 is critical too.  Activating the first I/O window only is enough
to hang the notebook on any APM activity.

>  So, probably, more correct fix
>  is something sort of:
>  
>  --- mitac-quirk.c
>  [ reserve resources ]

I've also noticed this in the boot messages:

PCI: PCI BIOS revision 2.10 entry at 0xeb1d0, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7198] at 00:07.0
PCI: Cannot allocate resource region 0 of device 00:0b.0
  got res[10000000:10000fff] for resource 0 of Texas Instruments PCI1410 PC card Cardbus Controller
  got res[10001000:10001fff] for resource 0 of PCI device 1033:00cd (NEC Corporation)
PCI: BIOS reporting unknown device 00:01
PCI: BIOS reporting unknown device 00:02

The "unknown device" looks suspicious to me ...

  Gerd

-- 
Damn lot people confuse usability and eye-candy.

Re: yenta_socket hangs sager laptop in kernel 2.4.6-> PNPBIOS life saver

[Gunther Mayer]

Gerd Knorr wrote:
> 
> In lists.linux.kernel, you wrote:
> >  Hello!
> >
> > > Same problem here.  I've spend some time today to figure what is going
> > > on.  Workaround:
> > > -           min = PCIBIOS_MIN_IO;
> > > +           min = 0x4000 /* PCIBIOS_MIN_IO */;
> >
> >  I do not know how to thank you... You saved my life. :-)
> >  How did you guess this?
> 
> Long trial-and-error session.  Deactivate code and see if it still does
> crash to narrow down the code lines which trigger the lockup.  Once I've
> figured that enabling the I/O-Windows triggers the lookup the guess was
> easy ...
> 
> > > Looks like a ressource conflict to me.  The kernel gives I/O ranges to
> > > the cardbus socket which it thinks are free but which are *not* free for
> > > some reason (and probably used for APM stuff).  BIOS bug?  PCI quirks
> > > time?

Longstanding Linux Bug: "ignore a _seven_ year old standard called PNPBIOS".

> >
> >  The same hardware is here, Mitac M722. :-) BTW what bios is installed
> >  on your one?
> 
> "SYSTEM BIOS R1.02"
> 
> >  Anyway, Windows with the _same_ bios manages to guess and to reserve
> >  a few of ports tagged as some obscure "motherboard resources":
> >  230-233, 398-399, 4d0-4d1, 1000-103f(!), 1400-140f(!) and 3810-381f.
> >  yenta_socket eats ones marked with !. At least 1400 is really critical,
> >  it is interface to SM mode.
> 
> 0x1000 is critical too.  Activating the first I/O window only is enough
> to hang the notebook on any APM activity.

PNPBIOS _easily_ resolves this problem !

Try -ac Kernels with integrated PNPBIOS and "lspnp -v",
then you will see your "motherboard resources". No magic.

Note: Linux currently does _not_ yet reserve these resources automatically
(although I think the standalone pcmcia package has such an option).

By confirming (and posting your lspnp results) you could encourage
some developers to rectify this situation :-)

Alan, 2.4 would largely benefit from PNPBIOS, do you plan
to submit this to LT (probably with the proposed life saver fix) ?


-
Gunther