Bug 26686 - Freeze at boot from 4.3-RC4 floopies - USB conflict? (or if_ed?)
Summary: Freeze at boot from 4.3-RC4 floopies - USB conflict? (or if_ed?)
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Remko Lodder
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-04-18 22:40 UTC by lazaro
Modified: 2007-01-05 09:51 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description lazaro 2001-04-18 22:40:01 UTC
When trying to install from floppies the machine hangs.
This is the output before freezing (have to pull the power cable to reboot)

Preloaded elf kernel "kernel" at 0xc0672000.
Preloaded mfs_root "/mfsroot" at 0xc0672084.
Pentium Pro MTRR support enabled
md0: Preloaded image </mfsroot> 2949120 bytes at 0xc03a0628
md1: Malloc disk
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcbi0: <Intel 82443LX (440 LX) host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pcbi1: <Intel 82443LX (440 LX) PCI-PCI (AGP) bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pci1: <Cirrus Logic GD5465 SVGA controller> at 0.0 irq 9
isab0: <Intel 82371AB PCI to ISA bridge> at device 4.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX4 ATA33 controller> port 0xfcd0-0xfcdf at device 4.1 on pci0

ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: <Intel 82731AB/EB (PIIX4) USB controller> irq 9 at device 4.2 on pci0
uhci0: Could not map ports
device_probe_and_attach: uhci0 attach returned 6
chip1: <Intel 82371AB Power management controller> port 0x8800-0x880f at device 4.3 on pci0
pci0: <Number Nine Imagine 128 graphics accelerator at 12.0 irq 9

----
 The only thing I can do here is reboot the machine.
I tried disabling the Irq 9 on the BIOS setup, but that does not help.
The same messages repeat with another irq (i.e. 10 or 11) instead of 9

Fix: 

I do not really know, but I had this problem with every single 4.x release
since 4.0 (I have reported this previously but it seems no one else has
the problem :-( ). 
It seems to me that probing USB is the cuplrit. I tried (some time
ago on a 4.1x src/sys  tree to compile a kernel without any USB support, 
and the problem still showed up at boot time.
This is the only reason why I cannot upgrade my 3.5-Stable (becoming aged)
boxes to the 4.x branch. A real inconvenience.
Comment 1 Doug Barton freebsd_committer freebsd_triage 2001-04-25 08:28:10 UTC
State Changed
From-To: open->closed


Please: 
A) Pick more realistic priority settings for your future PR's 
B) Submit details of your system and what you're trying to do 
to freebsd-questions@freebsd.org. It may be that no one 
can help you because no one knows the answer to your problem. 

Good luck. 


Comment 2 Doug Barton freebsd_committer freebsd_triage 2001-04-25 08:28:10 UTC
Responsible Changed
From-To: gnats-admin->freebsd-bugs


Misfiled PR.
Comment 3 n_hibma 2001-04-25 10:00:26 UTC
Do you have two graphics cards in your system? Or is pcib1 an internal
PCI bus for the graphics card?

     pcbi0: <Intel 82443LX (440 LX) host to PCI bridge> on motherboard
     pci0: <PCI bus> on pcib0
     pcbi1: <Intel 82443LX (440 LX) PCI-PCI (AGP) bridge> at device 1.0
on pci0
     pci1: <PCI bus> on pcib1
     pci1: <Cirrus Logic GD5465 SVGA controller> at 0.0 irq 9
     pci0: <Number Nine Imagine 128 graphics accelerator at 12.0 irq 9

Also, it looks like you have posted a partial dmesg. Is this correct? If
so, would it be possible that you post a complete dmesg? It might
contain missing information that looks irrelevant to you but is actually
relevant.

Cheers,

Nick
Comment 4 Nick Hibma freebsd_committer freebsd_triage 2001-04-25 10:01:01 UTC
State Changed
From-To: closed->open

This is a bug not a question. A machine should boot and not 
get hung halfway through probing the PCI bus with a GENERIC 
kernel.
Comment 5 "mas039" 2001-04-27 18:11:01 UTC
I have also had a similar problem which I've found to be caused by the
ex driver causing ne2000 boards (ed0) to freeze the machine.   The
effect does vary; some slightly different models of ne2000 boards
tolerate the ex driver, but then work at a reduced speed.
Under 3.x the ex device could be disabled from the kernel configuration
editor, but under 4.x it does not appear (why not?), so cannot be
disabled.  I have to build a new kernel (omitting the ex driver,
together with other options to reduce the kernel size appropriately)
strip it, compress it and copy it to the boot floppy.  It would be very
convenient if this problem was solved!

Gareth.

--
Dr G W Roberts                             Dr G W Roberts
Adran Mathemateg                           Department of Mathematics
Ysgol Gwybodeg                             School of Informatics
Prifysgol Cymru                            University of Wales
Stryd y Deon                               Dean Street
Bangor                                     Bangor
Gwynedd                                    Gwynedd
LL57 1UT                                   LL57 1UT
DU                                         UK

Email: G.W.Roberts@bangor.ac.uk
Tel:   +44 (0)1248 382480
Ffacs: +44 (0)1248 361429
WWW: http://www.bangor.ac.uk/ma
Comment 6 salem 2001-05-21 14:37:54 UTC
As G.W. Roberts wisely pointed out, the problem seems to be related to
another driver conflicting w/the NE2000 NIC I _did_ have installed
when the problem occurred. He suggests the ex driver, but I do not
know how to check that

In a private communication G.W. Roberts wrote:

>If you have a ne2000 NIC installed which is freezing the system when
probed
>by the ex driver, the only way to boot is to physically remove the
network
>card.  Disabling the ne driver in the kernel configuration does not
help.
>It is not a conflict between the ex driver and the ne driver, but
between the
>ex driver and the ne2000 NIC.

So yesterdy I tried removing the NE2000 and voila....! FreeBSD 4.3R,
4.0R,
and 4.1R all were able to fully boot my box.

I mention those releases as they are relevant to the following related
PRs I submitted before (
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18201 )
and after (http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26736 ) the
present
one you are reading ( http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26686 )


>
>On the other had, if the ex driver showed up in the kernel
configuration list,
>then disabling it would solve the problem, as I used to do in FreeBSD
3.2 and
>3.3.  However, in FreeBSD 4 it isn't listed - can someone explain why
not?!
>
>As I wrote in my follow-up, it would be extremely convenient if this
problem
>was resolved as soon as possible!

I second George in this. Otherwise I would have to use an 8bits isolan
based
on the not so robust LANCE lnc0 driver.

The nice developers at FreeBSD might consider the "priority" for this PR

"high" but the severity of this PR is certainly "critical":
No GENERIC kernel should hang at boot time before spitting out sensible
mesagges (I has been around this bug since 4.0R and although I made it
public in Aug 2000 in PR 18201, no hint was given until Apr-2001).
Knowing were to look for the problem is at least and that is a
good starting point.

Thank to all of you for your valuable time.

Cheers,
Lazaro
Comment 7 iedowse freebsd_committer freebsd_triage 2002-11-03 17:53:17 UTC
State Changed
From-To: open->feedback


Is this problem still present with more recent releases?
Comment 8 iedowse 2002-12-01 00:39:59 UTC
Adding to the audit trail:

In message <3DE18EFF@epostleser.online.no>, lazaro writes:
>Yes the problem is still there with FreeBSD 4.7-R.
>PLease be aware the description might be misleading.
>This has most probably nothing to do with USB.
>The problem has been identified and is referred to
in the PR and other PR's referenced therein.
>Thanks!
>LDS
>
Comment 9 iedowse freebsd_committer freebsd_triage 2002-12-01 00:40:33 UTC
State Changed
From-To: feedback->open


Problem still exists with 4.7-RELEASE.
Comment 10 Kris Kennaway freebsd_committer freebsd_triage 2003-07-18 01:34:16 UTC
Responsible Changed
From-To: freebsd-bugs->joe

Assign to USB maintainer
Comment 11 njl freebsd_committer freebsd_triage 2003-08-22 04:21:55 UTC
Responsible Changed
From-To: joe->freebsd-bugs

The problem is NOT USB-related.  It is related to ed(4) and potentially 
other ISA devices.  Perhaps someone who knows ed(4) would be interested?
Comment 12 Remko Lodder freebsd_committer freebsd_triage 2006-12-29 20:08:53 UTC
State Changed
From-To: open->feedback

Hello, the world changed a lot since you submitted this, we also 
handle the cards differently nowadays (OLDCARD/NEWCARD afair), can 
you perhaps say whether this is still a problem on freebsd 6.x? 


Comment 13 Remko Lodder freebsd_committer freebsd_triage 2006-12-29 20:08:53 UTC
Responsible Changed
From-To: freebsd-bugs->remko

grab the pr.
Comment 14 Remko Lodder freebsd_committer freebsd_triage 2007-01-05 09:51:25 UTC
State Changed
From-To: feedback->closed

We cannot reproduce this problem since the hardware from the submitter 
had changed a lot. If someone has feedback please notify me so that we 
can workout the details. Thanks for the feedback!