Re: Bizzare crashes on IBM Thinkpad A22e

Re: Bizzare crashes on IBM Thinkpad A22e

[Tester]

Another thing,

Linuxcare has certified this laptop as being compatible with Linux 7.1
http://www.linuxcare.com/labs/certs/ibm/thinkpad/A22e/pada22e-2655-rh7-sys.epl

Did they do something that I dont know of? Is there anyone left there?

Tester

On Fri, 31 Aug 2001, Sean Hunter wrote:

> <Possibly not relevant to your problem>

It is indeed not relevant.. I dont have any pcmcia card as there is an
integrated Network adapter... (Intel EEPro100)

> I have a thinkpad and had all sorts of wierd and unpredictable crashes until I
> removed the old 3com pcmcia network card and replaced it with a new cardbus
> card.  The old card works fine in all sorts of other laptops, but the thinkpad
> just wasn't having it.
>
> Since replacing the card its worked great.
> </>
>
> Sean
>
> On Thu, Aug 30, 2001 at 06:30:27PM -0400, Tester wrote:
> > Hi,
> >
> > Its a 256 megs machine.. Celeron 800..
> > I tried using mem=255M or mem=200M and it did not change anything and
> > still crashed. The celeron A22e seems to have the same bios as the A21e...
> >
> > Btw, I received it as part of a ThinkPad University program (laptop at
> > school) from IBM with the old mandrake installed. And they IS guy of the
> > university told us that they didnt install the latest released because IBM
> > had not approved it... IBM probably already knows of the problem... So a
> > message to IBM and IBMers: Why dont you fix your known bugs?
> >
> > Also it works correctly in w2k, but win2k uses ACPI and not APM (and it
> > has a IBM pm driver...)
> >
> > Tester
> > tester@videotron.ca
> >
>

-- 
Tester
tester@videotron.ca

Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Olivier Crete]

Hi,

Ok, I've tried removing different parts of the kernel and I have been able
to find that the instability (repetable freezes) start to appear when the
yenta_socket.o module is loaded. I dont see the link between this module
and the events that trigger the freezes... It crashes when I do the
following things: use any of the non-keyboard buttons (thinkpad buttons
and volume control), brightness control, etc.. These buttons fn-X
combination have in common that they do not generate a scancode as shown
by showkey.

-- 
Olivier Crete
Tester
tester@videotron.ca
oliviercrete@videotron.ca

Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Gerd Knorr]

Olivier Crete wrote:
>  Hi,
>  
>  Ok, I've tried removing different parts of the kernel and I have been able
>  to find that the instability (repetable freezes) start to appear when the
>  yenta_socket.o module is loaded. I dont see the link between this module
>  and the events that trigger the freezes... It crashes when I do the
>  following things: use any of the non-keyboard buttons (thinkpad buttons
>  and volume control), brightness control, etc.. These buttons fn-X
>  combination have in common that they do not generate a scancode as shown
>  by showkey.

Try -ac kernels with PNPBIOS enabled ...

  Gerd

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

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Erik Mouw]

On Sat, Sep 01, 2001 at 12:50:30AM -0400, Olivier Crete wrote:
> Ok, I've tried removing different parts of the kernel and I have been able
> to find that the instability (repetable freezes) start to appear when the
> yenta_socket.o module is loaded. I dont see the link between this module
> and the events that trigger the freezes... It crashes when I do the
> following things: use any of the non-keyboard buttons (thinkpad buttons
> and volume control), brightness control, etc.. These buttons fn-X
> combination have in common that they do not generate a scancode as shown
> by showkey.

Hmm, I had a similar kind of freeze when using USB hotplug and PCMCIA.
I could solve mine by only having CardBus support in the kernel:

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
CONFIG_CARDBUS=y
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Linus Torvalds]

In article <Pine.LNX.4.33.0109010022440.1295-100000@TesterTop.PolyDom>,
Olivier Crete  <Tester@videotron.ca> wrote:
>
>Ok, I've tried removing different parts of the kernel and I have been able
>to find that the instability (repetable freezes) start to appear when the
>yenta_socket.o module is loaded. I dont see the link between this module
>and the events that trigger the freezes... It crashes when I do the
>following things: use any of the non-keyboard buttons (thinkpad buttons
>and volume control), brightness control, etc.. These buttons fn-X
>combination have in common that they do not generate a scancode as shown
>by showkey.

What they are doing, however, is to generate a SCI, ie "System Control
Interrupt". Which, I bet you five bucks, is routed to the same interrupt
that your CardBus controller is on.

So the fact that the system hangs only with the CardBus module loaded
really has nothing to do with the yenta code itself - it's just that
before the yenta module is loaded, the SCI will be entirely ignored.
Once yenta _is_ loaded, however, we have a interrupt handler for the
interrupt and will start accepting it.

However, the interrupt handler we have is _not_ aware of system
control interrupts. So it won't be able to handle them, and the
interrupts will go on forever - locking up the machine.


The problem here is that the SCI really _should_not_ generate a regular
interrupt unless the system is ready to accept it. The SCI can be routed
to a SMI (system management interrupt, which puts the CPU in SMM mode,
at which point the BIOS SMM routines can handle it), _or_ if you have
ACPI enabled, ACPI should be (a) enabling the SCI->regular irq routine
_and_ (b) actually handling the irq.

Do you have ACPI enabled in your kernel?

What are the bootup messages?

		Linus

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Tester]

Hi,

I dont have ACPI enabled, but I have APM support...
Should I try enabling ACPI?

And the result of dmesg follows:

Linux version 2.4.9 (Tester@TesterTop) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #15 Fri Aug 31 16:04:04 EDT 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
 BIOS-e820: 000000000fff0000 - 000000000fffec00 (ACPI data)
 BIOS-e820: 000000000fffec00 - 0000000010000000 (ACPI NVS)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=linux ro root=305 BOOT_FILE=/boot/vmlinuz
Initializing CPU#0
Detected 206.245 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 430.89 BogoMIPS
Memory: 255768k/262080k available (887k kernel code, 5924k reserved, 292k data, 176k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0383f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383f9ff 00000000 00000000 00000000
CPU:     After generic, caps: 0383f9ff 00000000 00000000 00000000
CPU:             Common caps: 0383f9ff 00000000 00000000 00000000
CPU: Intel Celeron (Coppermine) stepping 0a
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfd9af, last bus=3
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7198] at 00:07.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
IBM machine detected. Enabling interrupts during APM calls.
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
Journalled Block Device driver loaded
pty: 256 Unix98 ptys configured
block: 128 slots per queue, batch=16
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 0
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x1890-0x1897, BIOS settings: hda:DMA, hdb:DMA
hda: IC25N015ATDA04-0, ATA DISK drive
hdb: CD-224E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 29498175 sectors (15103 MB) w/347KiB Cache, CHS=1950/240/63
hdb: ATAPI 24X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: hda1 hda2 < hda5 hda6 hda7 >
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
IPv4 over IPv4 tunneling driver
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 176k freed
Adding Swap: 529160k swap-space (priority -1)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.259 $ time 16:13:30 Aug 31 2001
usb-uhci.c: High bandwidth mode enabled
PCI: Found IRQ 11 for device 00:07.2
usb-uhci.c: USB UHCI at I/O 0x18a0, IRQ 11
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
usb-uhci.c: v1.251:USB Universal Host Controller Interface driver
EXT3 FS 2.4-0.9.6-249, 18 Aug 2001 on ide0(3,5), internal journal
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw@saw.sw.com.sg> and others
PCI: Found IRQ 11 for device 00:03.0
PCI: Sharing IRQ 11 with 00:03.1
eth0: OEM i82557/i82558 10/100 Ethernet, 00:03:47:8E:AE:4D, IRQ 11.
  Board assembly a30469-008, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
    Secondary interface chip i82555.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x3258698e).
Intel 810 + AC97 Audio, version 0.03, 16:13:09 Aug 31 2001
PCI: Found IRQ 11 for device 00:00.1
PCI: Setting latency timer of device 00:00.1 to 64
i810: Intel 440MX found at IO 0x1800 and 0x2000, IRQ 11
ac97_codec: AC97 Audio codec, id: 0x4352:0x5935 (Unknown)
i810_audio: setting clocking to 177230
CSLIP: code copyright 1989 Regents of the University of California
PPP generic driver version 2.4.1
Loading Lucent Modem Controller driver version 6.00
Detected Parameters Irq=11 BaseAddress=0x1880 ComAddress=0x0
Lucent Modem Interface driver version 6.00 (2001-01-26) with SHARE_IRQ enabled
ttyLT00 at 0x1880 (irq = 11) is a Lucent Modem
PPP BSD Compression module registered
PPP Deflate Compression module registered

--
Olivier Crete
Tester
tester@videotron.ca

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Linus Torvalds]

On Sat, 1 Sep 2001, Tester wrote:
>
> I dont have ACPI enabled, but I have APM support...
> Should I try enabling ACPI?

It would be interesting to hear what happens. I bet you won't be happy
with it compared to APM due to the lack of proper suspend etc, but from a
testing standpoint it would be good to hear what happens, and what
/proc/interrupts and ACPI report about the thing..

		Linus

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Tester]

Hi,

ACPI doesnt give a different result.. using 2.4.9-ac5 with pnpbios enabled
doesnt change anything either...

Tester

On Sat, 1 Sep 2001, Linus Torvalds wrote:

>
> On Sat, 1 Sep 2001, Tester wrote:
> >
> > I dont have ACPI enabled, but I have APM support...
> > Should I try enabling ACPI?
>
> It would be interesting to hear what happens. I bet you won't be happy
> with it compared to APM due to the lack of proper suspend etc, but from a
> testing standpoint it would be good to hear what happens, and what
> /proc/interrupts and ACPI report about the thing..
>
> 		Linus
>
>

-- 
Tester
tester@videotron.ca

Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Gunther Mayer]

Tester wrote:
> 
> Hi,
> 
> ACPI doesnt give a different result.. using 2.4.9-ac5 with pnpbios enabled
> doesnt change anything either...

On PNPBIOS: recently a hard hang was fixed in -ac by reserving port 
ranges of PNP0c02 (or 0c01?) devices (else yenta would choose these...)

Can you compare "lspnp -v" to see if there is another builtin device
in conflict with the yenta ioport window allocation ?

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Tester]

Hi,

I dont see any conflicts with ac5, and it still doesnt work... I think
Linus's explanation of the problem is more probable... Also, I have not
been able to reproduce the crash with ACPI recently.. It seems that if I
have ACPI, but no APM, it does freeze... Kernel with APM or with no power
management at all will crash under the same circumstances... But how do I
fix that... I dont know...

show version:
ACPI enabled kernel works fine...
Everything else freezes with yenta...

Tester

On Sun, 2 Sep 2001, Gunther Mayer wrote:

> Tester wrote:
> >
> > Hi,
> >
> > ACPI doesnt give a different result.. using 2.4.9-ac5 with pnpbios enabled
> > doesnt change anything either...
>
> On PNPBIOS: recently a hard hang was fixed in -ac by reserving port
> ranges of PNP0c02 (or 0c01?) devices (else yenta would choose these...)
>
> Can you compare "lspnp -v" to see if there is another builtin device
> in conflict with the yenta ioport window allocation ?
>

-- 
Tester
tester@videotron.ca

Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Alan Garrison]

On Sun, Sep 02, 2001 at 05:51:19PM -0400, Tester wrote:
> Hi,
> 
> I dont see any conflicts with ac5, and it still doesnt work... I think
> Linus's explanation of the problem is more probable... Also, I have not
> been able to reproduce the crash with ACPI recently.. It seems that if I
> have ACPI, but no APM, it does freeze... Kernel with APM or with no power
> management at all will crash under the same circumstances... But how do I
> fix that... I dont know...
> 
> show version:
> ACPI enabled kernel works fine...
> Everything else freezes with yenta...

I am in the same boat as Tester.  My laptop using kernels 2.4.8, 2.4.9, 
and a few -ac patches locks every single time when yenta_socket loads.  
Everything besides yenta_socket seems to work fine (so far).  I 
generally compile APM as a module and I am not loading it on boot, so 
there are few modules loading on a raw boot.  Perhaps I am required to 
use some sort of PNP setup with 2.4.x?  My stupid bios has absolutely 
no settings regarding pcmcia/pccard.  The only half-relevant option is 
the "PNP OS Installed?  Y/N".  Using 2.2.19pre17 (stock Debian Potato 
kernel) works generally fine with i82365/pcnet_cs loaded.

If anyone needs more h/w info or would like me to test patches I'd be 
more than happy to help.

***** 2.4.9 "lspci" output:

00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04)
00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04)
00:03.0 CardBus bridge: Texas Instruments PCI1251B
00:03.1 CardBus bridge: Texas Instruments PCI1251B
00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV] (rev 0a)
00:09.0 Multimedia audio controller: ESS Technology ES1978 Maestro 2E (rev 10)
00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev 20)
00:11.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU (rev 09)
00:13.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage LT Pro AGP-133 (rev dc)

> Tester
 
-- 
alan at       __  Corporate Accounts Payable, Nina speaking... Just a moment.
alangarrison  __  Corporate Accounts Payable, Nina speaking... Just a moment.
dot com       __  Corporate Accounts Payable, Nina speaking... Just a moment.
"all your apt-get are / belong to us dist-upgrade / now for great honour" -MM

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Tester]

Hi,

On Sat, 1 Sep 2001, Linus Torvalds wrote:

> In article <Pine.LNX.4.33.0109010022440.1295-100000@TesterTop.PolyDom>,
> Olivier Crete  <Tester@videotron.ca> wrote:
> >
> >Ok, I've tried removing different parts of the kernel and I have been
able
> >to find that the instability (repetable freezes) start to appear when the
> >yenta_socket.o module is loaded. I dont see the link between this module
> >and the events that trigger the freezes... It crashes when I do the
> >following things: use any of the non-keyboard buttons (thinkpad buttons
> >and volume control), brightness control, etc.. These buttons fn-X
> >combination have in common that they do not generate a scancode as shown
> >by showkey.
>
> What they are doing, however, is to generate a SCI, ie "System Control
> Interrupt". Which, I bet you five bucks, is routed to the same interrupt
> that your CardBus controller is on.

Seems like you may have lost five bucks... When ACPI is enabled the sci is
on IRQ 9, while the CardBus controller is on a IRQ 11 along with
the Sound card, the ethernet card, the modem and the usb controller. The
SCI seems to go to irq 9... and be alone there...  The bug does not happen
when acpi is enabled tho... So I can't confirm...

> So the fact that the system hangs only with the CardBus module loaded
> really has nothing to do with the yenta code itself - it's just that
> before the yenta module is loaded, the SCI will be entirely ignored.
> Once yenta _is_ loaded, however, we have a interrupt handler for the
> interrupt and will start accepting it.
>
> However, the interrupt handler we have is _not_ aware of system
> control interrupts. So it won't be able to handle them, and the
> interrupts will go on forever - locking up the machine.

Where would that loop occur?



-- 
Tester
tester@videotron.ca

Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer

Re: Bizzare crashes on IBM Thinkpad A22e.. yenta_socket related

[Linus Torvalds]

On Tue, 4 Sep 2001, Tester wrote:
> >
> > What they are doing, however, is to generate a SCI, ie "System Control
> > Interrupt". Which, I bet you five bucks, is routed to the same interrupt
> > that your CardBus controller is on.
>
> Seems like you may have lost five bucks... When ACPI is enabled the sci is
> on IRQ 9, while the CardBus controller is on a IRQ 11 along with
> the Sound card, the ethernet card, the modem and the usb controller. The
> SCI seems to go to irq 9... and be alone there...  The bug does not happen
> when acpi is enabled tho... So I can't confirm...

No, I think I'll keep my 5 bucks, cheap bastard that I am.

The thing is, enabling ACPI will also force the _correct_ routing of the
SCI interrupt (assuming ACPI works - it doesn't on all machines), and thus
it doesn't show up as some random other irq. Which is why you don't get a
lockup.

> > However, the interrupt handler we have is _not_ aware of system
> > control interrupts. So it won't be able to handle them, and the
> > interrupts will go on forever - locking up the machine.
>
> Where would that loop occur?

There won't be any explicit loop - what will happen is that irq12 will
stay active, so we will keep on having irq12 interrupts that the CardBus
interrupt handler doesn't know what to do with - and immediately when the
irq handler returns and acks the interrupt we'll just take the irq again.

Over and over.

		Linus