Bug 169674 - Crash in yenta_socket at boot
Crash in yenta_socket at boot
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
: 169757 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-30 17:53 EDT by Per Steinar Iversen
Modified: 2015-01-04 17:22 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-09 21:23:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
From the syslog when doing "modprobe yenta_socket" (2.72 KB, text/plain)
2005-09-30 17:55 EDT, Per Steinar Iversen
no flags Details
Output from lspci (2.11 KB, text/plain)
2005-09-30 17:56 EDT, Per Steinar Iversen
no flags Details
Log created when doing "modprobe yenta_socket" (1.33 KB, text/plain)
2005-11-10 15:17 EST, Per Steinar Iversen
no flags Details

  None (edit)
Description Per Steinar Iversen 2005-09-30 17:53:40 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
Upgraded to kernel-2.6.13-1.1526_FC4, but the kernel crashed during boot. From the screen dump it looked like yenta_socket was the problem so I booted to the previous kernel and add yenta_socket to /etc/hotplug/blacklist and this actually allowed the machine to boot with the new kernel. When doing "modprobe yenta_socket" after boot the machine locked up but produced some debug output in the syslog, see the following attachment.

Version-Release number of selected component (if applicable):
kernel-2.6.13-1.1526_FC4

How reproducible:
Always

Steps to Reproduce:
1. Boot
2. The machine hangs during boot
3.
  

Actual Results:  The machine does not boot unless yenta_socket is in etc/hotplug/blacklist

Expected Results:  Boot as with the previous kernel.

Additional info:

This is on a laptop, Acer 8104WLMi, lspci output will be attached.
Comment 1 Per Steinar Iversen 2005-09-30 17:55:25 EDT
Created attachment 119492 [details]
From the syslog when doing "modprobe yenta_socket"
Comment 2 Per Steinar Iversen 2005-09-30 17:56:08 EDT
Created attachment 119493 [details]
Output from lspci
Comment 3 Mary Ellen Foster 2005-10-03 12:27:28 EDT
*** Bug 169757 has been marked as a duplicate of this bug. ***
Comment 4 Mary Ellen Foster 2005-10-05 07:40:54 EDT
Further information from the person whose (very similar) problems are described
in bug 169757 ...

He tried rebuilding the 2.6.13-1.1526 kernel from source with a couple of
changes he's found necessary to get things working fully on his machine --
changing things so he can update the DSDT so that ACPI works, and rebuilding it
for the right processor type. (I can get the details of the exact configuration
he uses, if necessary.) Booting that kernel resulted in the same messages as in
the second trace from bug 16957 -- the ones starting with "PCI: Cannot allocate
resource region 7 of bridge 0000:00:1c.0".
Comment 5 Per Steinar Iversen 2005-10-24 14:54:00 EDT
I just tried loading yenta_socket under kernel 2.6.13-1.1532_FC4, this does not
crash the  kernel anymore and the following is logged:

ACPI: PCI Interrupt 0000:06:09.0[A] -> Link [LNKE] -> GSI 10 (level, low) -> IRQ 10
Yenta: CardBus bridge found at 0000:06:09.0 [1025:0070]
Yenta O2: res at 0x94/0xD4: ea/00
Yenta O2: enabling read prefetch/write burst
Yenta: ISA IRQ mask 0x0038, PCI irq 10
Socket status: 30000006
pcmcia: parent PCI bridge I/O window: 0x3000 - 0x4fff
cs: IO port probe 0x3000-0x4fff: clean.
pcmcia: parent PCI bridge Memory window: 0xc8200000 - 0xc82fffff
pcmcia: parent PCI bridge Memory window: 0x80000000 - 0x81ffffff
Yenta: no bus associated with 0000:06:09.1! (try 'pci=assign-busses')
Yenta: no bus associated with 0000:06:09.3! (try 'pci=assign-busses')

If I actually try adding "pci=assign-busses" to the kernel boot options the
machine locks up very early in the boot sequence.
Comment 6 Dave Jones 2005-11-10 14:56:05 EST
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.
Comment 7 Per Steinar Iversen 2005-11-10 15:17:19 EST
Created attachment 120902 [details]
Log created when doing "modprobe yenta_socket"

yenta_socket still suggest adding "pci=assign-busses", with kernel
2.6.14-1.1637_FC4 this actually works, see attached log.
Comment 8 Dave Jones 2006-02-03 02:06:53 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 9 Per Steinar Iversen 2006-02-04 06:50:41 EST
The kernel now boots without the "pci=assign-busses" option, so this problem
seems  to have been resolved.
Comment 10 Per Steinar Iversen 2006-02-04 06:51:14 EST
The kernel now boots without the "pci=assign-busses" option, so this problem
seems  to have been resolved.

Note You need to log in before you can comment on or make changes to this bug.