Bug 53209

Summary: Patch1860 breaks existing hardware.
Product: [Retired] Red Hat Linux Reporter: Sam Varshavchik <mrsam>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED CURRENTRELEASE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: hjl
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-09-30 15:39:10 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: 51706    
Bug Blocks:    
Attachments:
Description Flags
A patch
none
A new patch
none
Replacement patch doesn't work. Cardbus ports simply don't get detected, no errors logged. none

Description Sam Varshavchik 2001-09-05 03:29:02 UTC
I tried to do an HTTP install of RC2.  I boot with pcmcia.img, it then
prompts for pcmciadd.img

The installer reads pcmcia.img off the floppy, but then immediately jumps
to the language selection dialog, apparently without even trying to
initialize the card.  Subsequently, the only available install choice is a
hard drive install.

There are no error messages of any kind.  The language selection dialog
pops up immediately after the floppy is read.

00:00.0 Host bridge: OPTi Inc. 82C557 [Viper-M] (rev 14)
        Flags: bus master, medium devsel, latency 0

00:01.0 ISA bridge: OPTi Inc. 82C558 [Viper-M ISA+IDE] (rev 02)
        Flags: bus master, medium devsel, latency 0

00:06.0 VGA compatible controller: Chips and Technologies F65550 (rev c6)
(prog-if 00 [VGA])
        Flags: stepping, medium devsel
        Memory at c0000000 (32-bit, non-prefetchable) [size=16M]
        Expansion ROM at <unassigned> [disabled] [size=256K]

00:07.0 CardBus bridge: Texas Instruments PCI1130 (rev 04)
        Flags: bus master, medium devsel, latency 168
        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: 00001400-000014ff
        I/O window 1: 00001800-000018ff
        16-bit legacy interface ports at 0001
00:07.1 CardBus bridge: Texas Instruments PCI1130 (rev 04)
        Flags: bus master, medium devsel, latency 168
        Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=05, subordinate=08, sec-latency=176
        Memory window 0: 10c00000-10fff000 (prefetchable)
        Memory window 1: 11000000-113ff000
        I/O window 0: 00001c00-00001cff
        I/O window 1: 00002000-000020ff
        16-bit legacy interface ports at 0001

00:14.0 IDE interface: OPTi Inc. 82C621 (rev 12) (prog-if 80 [Master])
        Flags: bus master, medium devsel, latency 0
        I/O ports at 1000 [size=16]


00:00.0 Class 0600: 1045:c557 (rev 14)
00:01.0 Class 0601: 1045:c558 (rev 02)
00:06.0 Class 0300: 102c:00e0 (rev c6)
00:07.0 Class 0607: 104c:ac12 (rev 04)
00:07.1 Class 0607: 104c:ac12 (rev 04)
00:14.0 Class 0101: 1045:c621 (rev 12)

Comment 1 Michael Fulbright 2001-09-05 15:57:31 UTC
Brent please try to reproduce.

Comment 2 Sam Varshavchik 2001-09-05 16:44:00 UTC
Found the following logged to /dev/tty3:

...
*going to insmod yenta_socket.o (path is NULL)
/tmp/yenta_socket.o: init_module: %m
Hint: insmod errors can be caused by incorrect module parameters,...
*failed to load pcic
...
Looks like insmod of yenta_socket fails.  Reassign to kernel?



Comment 3 Jeremy Katz 2001-09-05 21:41:34 UTC
Could you try remaking the disk images?  I've seen this happen with bad disks in
the past and just confirmed that pcmcia installs do properly use pcmciadd and
yenta_socket with the current tree

Comment 4 Sam Varshavchik 2001-09-05 21:57:06 UTC
I have reformatted and reimaged the floppies already.  From past experience I
know that if the boot floppy is bad, syslinux will stop and won't boot the
kernel.  There are no apparent signs of the floppy drive having problems reading
anything.



Comment 5 Matt Wilson 2001-09-05 22:07:35 UTC
copy /tmp/syslog from within the installer to a floppy and attach it, please


Comment 6 Matt Wilson 2001-09-05 22:09:52 UTC

*** This bug has been marked as a duplicate of 52673 ***

Comment 7 Sam Varshavchik 2001-09-06 04:27:52 UTC
Reopening.  This does not appear to be a dupe of 52673.  I backed out patch1860
from 2.4.7-6, then built a new pcmciadd.img with the reverted yenta_socket.o. 
The network card came up fine.  I was able to get to start anaconda, and load
via HTTP stage2, over the network.  I did not yet install rc2, since I need to
rebuild the main kernel rpm with the fixed yenta socket driver.

Bug 52673 appears to predate the introduction of patch1860, which I backed out
in order to make this chipset work again.

So...  It's not clear what patch1860 intended to fix.  Perhaps some chipset
hardware needs it to work.  But its presence apparently breaks other chipsets. 
So there you go.




Comment 8 Arjan van de Ven 2001-09-06 09:03:35 UTC
I agree this is a separate bug.
/me goes to look at the patch long and hard

Comment 9 hjl 2001-09-29 21:52:36 UTC
I am not sure what the current solution is. Backing out 1860 is certainly
not. I saw 2.4.9-0.12 reenable it. What is the story here?

Comment 10 Sam Varshavchik 2001-09-29 22:19:00 UTC
Well, unless this patch is backed out, hardware that worked on everything since
kernel 2.0 will now break and not work at all.  Perhaps this patch is needed for
certain PCI IDs only, and should be driven based on PCI IDs.

Comment 11 hjl 2001-09-29 22:50:19 UTC
Can you find out why it breaks your hardware? On my notebook,
there is no IRQ on one of the cardbus slots. The kernel hangs
when it calls add_pci_socket () since the interrupt it is waiting
for will never come.  My patch just skips slots without IRQ.
Somehow it doesn't work for you. Can you find out why?

Comment 12 Sam Varshavchik 2001-09-30 00:00:28 UTC
As far as I could decipher the boot messages, the PCMCIA network card in one of
my slots does not use an interrupt, at least not until it is activated.  With
the patch, the kernel skips over the slot, and does not detect the network card.


Comment 13 hjl 2001-09-30 00:10:17 UTC
Is that "doesn't use an interrupt" or "doesn't have an interrupt assigned"?
There is a big difference. If it doesn't have an interrupt assigned, which
kernel function assignes the interrupt?

Comment 14 Sam Varshavchik 2001-10-01 00:24:47 UTC
The interrupt gets assigned far later into the boot process, when the PCMCIA
stuff gets loaded.  The bootstrap messages are:

PCI: No IRQ known for interrupt pin A of device 00:07.0. Please try using
pci=biosirq.
PCI: No IRQ known for interrupt pin B of device 00:07.1. Please try using
pci=biosirq.
spurious 8259A interrupt: IRQ7.
Yenta IRQ list 0e80, PCI irq0
Socket status: 30000010
Yenta IRQ list 0e80, PCI irq0

This is where the patch break things.  By blowing away the initialization in
pcisocket if irq is 0, the ports are not initialized.

Further along into the boot...

Socket status: 30000006
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x200-0x207 0x220-0x22f 0x300-0x307
0x378-0x37f 0x388-0x38f 0x398-0x39f 0x400-0x40f 0x480-0x48f 0x4c0-0x4df
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
eth0: 3Com 3c589, io 0x310, irq 9, hw_addr 00:60:97:46:2E:61
  8K FIFO split 5:3 Rx:Tx, auto xcvr
eth0: flipped to 10baseT
eth0: flipped to 10baseT
pcmcia gets loaded, sees the 3com card, gives it irq 9, and off we go.



Comment 15 hjl 2001-10-01 20:55:22 UTC
It looks like a cardbus slot without an assigned IRQ can only work
with a special driver. Can you please try my new patch? I will
test it on my notebook later.

Comment 16 hjl 2001-10-01 20:56:01 UTC
Created attachment 33139 [details]
A patch

Comment 17 Sam Varshavchik 2001-10-02 02:55:47 UTC
Did you want to run this patch with or instead of patch1860?  I assumed with
1860, and it doesn't work.  No slots were detected, and PCMCIA did not work with
both 1860 and this patch.



Comment 18 hjl 2001-10-02 04:38:01 UTC
Created attachment 33158 [details]
A new patch

Comment 19 hjl 2001-10-02 04:40:42 UTC
Oops. I uploaded a new patch. Please use it to replace
patch1860. If it doesn't work. please provide the output

# dmesg

Comment 20 Sam Varshavchik 2001-10-02 12:02:21 UTC
Created attachment 33200 [details]
Replacement patch doesn't work. Cardbus ports simply don't get detected, no errors logged.

Comment 21 hjl 2001-10-02 16:33:26 UTC
It doesn't look right. My new patch should work for you. At
least, it should print out something that a slot is ignored.  Please
play with my patch to see why it doesn't work for you. You can
put in some "#if 0/#endif" to check which changes of mine break
your notebook. You can boot your notebook to the run level 1 and
do

# cd build
# cp -af /usr/src/linux-2.4... .
# cd linux-2.4...
# make oldconfig
# make SUBDIRS=drivers/pcmcia modules

to rebuild yenta_socket.o. Then do

# cd drivers/pcmcia
# insmod ./pcmcia_core.o
# insmod ./yenta_scoket.o
# dmesg

You can find out why change breaks your notebook.
Please make sure you back out the previous patch1860
and apply my new one.

Comment 22 Sam Varshavchik 2001-10-02 22:49:56 UTC
I think I might be having some problem building a patched kernel RPM - none of
the pcmcia modules were installed in lib/modules/version/pcmcia, for some
reason, in the final RPM.  Manually inserting the modules appears to work, but
I'm going to still try to build a functional kernel that actually starts properly.


Comment 23 Sam Varshavchik 2001-10-03 01:37:53 UTC
This patch works for me.



Comment 24 hjl 2001-10-03 23:52:24 UTC
Great. Thanks for testing. May I suggest to replace patch1860 with the
new one? Also, it will be nice to enable interrupt on the Toshiba
CardBus bridge. Unfortunately, I couldn't find any doc for it.

Comment 25 Bugzilla owner 2004-09-30 15:39:10 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/