*** Bug 28332 has been marked as a duplicate of this bug. ***

The same thing happened for me.  I have a Toshiba Portege 320CT laptop PC.  I 
don't have a CD-ROM for it, just a network connection via a 10-Mbit PCMCIA 
network card.  I downloaded the beta just fine, using FTP, but the system hangs 
hard as soon as it tries to load the pcmcia service.  Cntl-alt-del doesn't 
respond -- I have to power off or hit the reset button to reboot.  It even 
happens when I don't have a PCMCIA card installed, and turn off other 
services.  Here's the tail of the dmesg, which is virtually identical to the 
one listed in this bug:

   Starting pcmcia:  PCI: No IRQ known for interrupt 
      pin A of device 00:02.0. Please try using pci=biosirq.

   PCI: No IRQ known for
      pin B of device 00:02.1. Please try using pci=biosirq.

   Yenta IRQ list 04b8, PCI irq0

   Socket status: 30000007

BTW, I'm not upset about it.  The beta download page warned me that PCMCIA was 
broke, so I wasn't counting on a clean install anyway.  The rest of the beta 
looks pretty good.  If I can get networking up, I may go ahead and keep running 
it, despite the beta status.  

Oh, and if you guys want to telnet into my machine and try some experiments on 
it, feel free to ask.  I don't have any critical or sensitive data on it -- 
it's just a test machine.  Of course, I'll need to get networking up on it 
first.  :-)

Have fun,

--Will

We (Red Hat) should really try to resolve this before next release.

It looks like I'll need my test machine for some work stuff, so I'm going to 
wipe the disk soon and reinstall with RedHat 6.2 or 7.0 or Debian or 
something.  Not sure yet.  Anyway, if you want me to run some tests on this 
machine, speak up now and I'll try to help.  In another day or two, I won't be 
able to recreate this PCMCIA bug any more, since I won't be running Fisher.

--Will

So far, every report we have received of a hang is with a Toshiba
notebook.  We suspect either faulty bios or faulty yenta socket.
We're testing with one Toshiba notebook, but it is quite possible
(indeed, highly likely) that Toshiba has used multiple yenta chips
and they have certainly used different bioses.

We don't have any imminent fix for this bug coming out in the next
few days.

Latest Rawhide kernels have fixes for this. Please try those and reopen this
bug if those kernels don't fix this.

Hmm.  I have 6.2 running pretty well now, but the machine 
was put back in test status, so I suppose it's available 
for a reinstall of 7.1 now.

OK, I'll go ahead and reinstall 7.1 into my laptop PC (a 
Toshiba Portege 320CT), probably some time this week.  
To apply the fix, do I just need to reinstall the current 
7.1 from the Red Hat site?  If I need to do anything else, 
please let me know.

In all seriousness, I'd be more than happy to give you 
guys remote access and the root password to it.  That way 
you could ssh into it and snoop around yourselves, instead 
of waiting for Bugzilla reports.  This machine is mostly 
used for testing, so I wipe out the disk entirely and 
reinstall from scratch fairly often.  Let me know if you're 
interested.

--Will

I am trying to install RH7.1 on a Toshiba Portege 320CT and I am experiencing a 
problem similar to that above. The RH7.1 source is on our local server here and 
I want to do a FTP install via pcmcia Xircom Ce3 10/100 nic. 
I boot from the pcmcia.img disk I created, and then it asks for the driver 
disk. I give it the pcmciadd.img disk I created and then I switch over to vt 3 
(ALT-F3) and watch as it does 'going to insmod pcmcia' and then as soon as it 
displays 'going to insmod yenta socket' the machine locks up completely, no ctl-
alt-del. 

I searched for solutions on the web and tried the following suggestions from 
others:

Changed bios settings, ie. disabled com1, internal modem, lpt1, sound.
  -no effect
Passed the following options when booting from the pcmcia.img disk:
linux pci=biosirq
linux pci=irqmask=0x8fff
linux pci=irqmask=0xafff
  -no effect
Upgraded bios to latest version (8.00) and set PCI config option to 'OS config'
  -no effect
Again changed bios settings: disabled com1, internal modem, lpt1, sound.
  -no effect

I'm not sure what else to try at this point.
I'm open to any suggestions.
Regards,
Rebecca

I have the same problem on a Toshiba Tecra 550CDT

I have any one found a solution ?
/Per

I got it working by changing in bios, setting  pcmcia : auto-selected ->
cardbus/16 
/Per

Is the bug fix for the described problem in PCMCIA support (for the Toshiba
ToPIC 97 card) in the current Redhat beta (Roswell)?  I think I have run into
the bug on my Toshiba Satellite 2060 CDS after installing Redhat 7.1.  I am not
sure whether to try to upgrade my kernel and PCMCIA services to the version in
Roswell or Rawhide (as was recommended on Bugzilla - reference 28348).  It looks
like I will finally have enough time to try a kernel upgrade within the next two
weeks.  If the bug fix is in both versions of the kernel and PCMCIA, I would
upgrade to whatever is considered more stable - the current beta or Rawhide and
presumably that means the beta?  The bug fix is in Rosswell, isn't it - the
advice to use the Rawhide kernel was posted in March?
William Nicholson

I believe the fix arjan mentioned is in rawhide but not roswell; that it
was done after roswell was cut.  rawhide is at
ftp://ftp.redhat.com/pub/redhat/linux/rawhide/

oops, I read a "3" as an "8" and thought arjan's comment was from
August when it is actually from March.  Must change font size...

Sounds like Per's suggestion is the right one.

Yes, I just checked and setting the BIOS setting for PCMCIA from auto to
Cardbus/ 16 does allow the PCMCIA card controller to be recognised and for
PCMCIA services and cardmgr to be started successfully (on my Toshiba Satellite
2060CDS).  When the ToPIC97 card controller is in Cardbus/ 16 mode, Windows 98
thinks it is a ToPIC95 (and loads up a new driver) and probe in Linux thinks it
is a ToPIC95B apparently. 
Unfortunately, although PCMCIA services start up successfully with this change,
the system crashes when I attempt to plug in any of the three cards I own (a
3com modem card, a 3com combo card and an SMC wireless card).  When I insert any
of the cards, there is a single beep and then the system hangs.  I may submit a
completely new bug report on this other problem when I have time.

This bug is still there in Redhat 9.0. It bit me on a Toshiba Satellite Pro 480
CDT, with a ToPIC97 cardbus bridge. A workaround was reported a long time ago in
http://www.michaelminn.com/linux/notebooks/toshiba335.html#section3: "This
problem can be fixed by changing the BIOS setting for the PC Card. AS THE
COMPUTER IS BEING REBOOTED OR TURNED ON, hold the <ESC> key down. The computer
will prompt you to press the F1 key - do so. This will bring up the System Setup
utility.

Press the <PgDn> key to go to page 2/2 of values. Press the Down Arrow key to
advance the cursor to the "PC CARD" Controller Mode value. It probably will be
set to "Auto-Selected". Press the space bar until it reads "CardBus/16-bit".

Then press the <End> button to exit the utility and respond "Y" when asked "Are
you sure?". The system will reboot and you should have no problems with PCMCIA
services.

Many thanks to Chad Wood for providing this fix."