Bug 101685

Summary: (ACPI) Xircom RBEM-56G-100 on Tecra 8000 no go with acpi
Product: [Retired] Red Hat Linux Beta Reporter: Patrick <rh_bugzilla>
Component: kernelAssignee: Jeff Garzik <jgarzik>
Status: CLOSED UPSTREAM QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: beta1CC: acpi-bugzilla, peterm
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-03-03 08:49:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 100644    
Attachments:
Description Flags
Output of dmesg -s40000 on Toshiba Tecra 8000 with pci=noacpi
none
Output of acpidmp on toshiba Tecra 8000 with pci=noacpi none

Description Patrick 2003-08-05 16:02:15 UTC 
Description of problem:
Cleanly installed Severn via nfs with linux askmethod nofb acpi=off. The system
reboots, boots linux and when it tries to start the pcmcia service it hangs with
messages that is doesn't know an IRQ for Pin A and B of the pcmcia card.

Version-Release number of selected component (if applicable):
no idea

How reproducible:
Just reboot the laptop and wait. Always happens.

Steps to Reproduce:
1. turn on laptop
2. let it run or add runlevel 3 in grub menu
3. wait till laptop hangs after "Starting pcmcia"

Actual results:


Expected results:
That it properly activates the pcmcia slot & Xircom card and boots fine so I can
enjoy Severn :)

Additional info:
The problem does *not* occur when I add pci=noacpi to the grub menu line. Then
the pcmcia services are started correctly and the Xircom card is recognized and
properly activated (I can ping another host).
Comment 1 Bill Nottingham 2003-08-05 17:19:08 UTC 
Can you post the output of 'acpidmp' and 'dmidecode'?
Comment 2 Len Brown 2003-08-05 18:26:17 UTC 
/proc/interrupts and dmesg -s40000 output from the success case could also help.  
Also, if you've got a serial port on this model it would be great if we can get a look at 
the boot messages from the failing boot.
Comment 3 Patrick 2003-10-18 16:02:40 UTC 
Created attachment 95281 [details]
Output of dmesg -s40000 on Toshiba Tecra 8000 with pci=noacpi
Comment 4 Patrick 2003-10-18 16:03:58 UTC 
Created attachment 95282 [details]
Output of acpidmp on toshiba Tecra 8000 with pci=noacpi
Comment 5 Patrick 2003-10-18 16:06:26 UTC 
Sorry for the delay guys. I've moved on to Fedora Core Test3 with kernel
2.4.22-1.2097.nptl. Just ran up2date and tried again with acpi=on. Problem
remains. Here are the final lines from the boot process
                                                                                
Starting pcmcia:   PCI: Emabling device 00:0b.0 (0000 -> 0002)
PCI: No IRQ known for interrupt pin A on device 00.0b.0 - using IRQ 255
PCI: Enabling device 00:0b.1 (0000 -> 0002)
PCI: No IRQ known for interrupt pin B on device 00.0b.1 - using IRQ 255
Yenta IRQ list 8498, PCI irq0
Socket status: 30000020
<laptop hangs indefinitely>
                                                                           
/proc/interrupts:
[root@tecra root]# cat /proc/interrupts
           CPU0
  0:      28959          XT-PIC  timer
  1:          2          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:          1          XT-PIC  MS Sound System
  8:          1          XT-PIC  rtc
 11:        800          XT-PIC  usb-uhci, Toshiba America Info Systems ToPIC97,
Toshiba America Info Systems ToPIC97 (#2), eth0
 14:       3146          XT-PIC  ide0
 15:         22          XT-PIC  ide1
NMI:          0
ERR:          0

Output of dmidecode is:
[root@tecra root]# dmidecode
RSD PTR found at 0xF1130
checksum failed.
OEM TOSHIB
PNP BIOS present.
                                                                       
The output of acpidmp and dmesg -s40000 is attached.
Comment 6 Patrick 2003-10-22 00:50:49 UTC 
This has been resolved partially. Please see the comments at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107458