| Summary: | System freeze booting from (i386) 4.3 floppies on HP Vectra VL 6/233 Series 7 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | lazaro <lazaro> |
| Component: | i386 | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
A followup to a related PR has been submitted with a work around this problem See: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26686 also related is http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18201 The IRQ peculiarity mentioned here has nothing to do with the freeze. Neither does the USB or Power management intrinsic to the HP/Vectra. It has been suggested the culprit is the ex driver probing an installed the NE2000 NIC. Disabling the NE2000 did not not help. Physically removing the NE2000 did help and the boot completed without problems. If the ex driver is the culprit, why cannot we disabled at the kernel configuration stage? This was possible to do in the 3.x releases, but is not possible to do with the 4.x releases. Cheers hi,
According to the Active drivers in your Visual Kernel Config:
==================
Active Drivers:
Dev---IRQ--Port
Storage:
ata0 14 0x1f0
ata1 15 0x170
fdc0 6 0x3f0
Communications:
ppc0 7
sio0 4 0x3f8
Input:
atkbd0 1
psm0 12
sc0
Miscellaneous:
npx0 13 0xf0
=================
The 'pci' controller has been removed from the 'Miscelleneous' category,
and
according to my doubts, it hangs right where a PCI scan starts, this
means that
you will have to leave the 'pci0' controller in, otherwise the system
will hang.
This means, doing nothing to the Miscelleneous Category of the Kernel
Configuration
step, when booting of the installation.
regards,
- Hiten
- <hiten@uk.FreeBSD.org>
--
1024 45:a5:9c:f2:fb:07:da:70:18:02:0b:f3:63:f1:7a:a6 hitenp@hpdi.ath.cx
State Changed From-To: open->feedback We need to know whether the problem Mr Pandya guesses is the cause is indeed the problem affecting the originator. State Changed From-To: feedback->closed Feedback timeout. Dear Lazaro, [please Cc: answers to bug-followup@freebsd.org so GNATS knows about them.] On Mon, Aug 12, 2002 at 09:29:02AM +0200, Lazaro Daniel Salem wrote: # # Dear Jens, # I cannot recall receiving a request for feedback I have not answered. I was referring to this state change: State-Changed-From-To: open->feedback State-Changed-By: sheldonh State-Changed-When: Mon Jan 14 03:47:28 PST 2002 State-Changed-Why: We need to know whether the problem Mr Pandya guesses is the cause is indeed the problem affecting the originator. Is the answer to this in a related PR? # I still observe the same problems with 4.6R. Please read the related PRs # mentioned in this one. # # The 3 PRs revolve on the same same thing, something I did not known at # first, but when # I got the clue I did mention in all of them by following-up. # # I had recently had a crash on th HD where 4.4 stable was installed so I am # quite sure # 4.5R and 4.6R did not solve the problem as I tried to install from the CDs. # In both cases I observed the same problem already reported. Do you want me to reopen this PR or is this problem adequately handled by one of the mentioned PRs? We should try to avoid duplicates if we can. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) > Is the answer to this in a related PR? No. the answer to Mr Pandya is not in this or other PR as I could not make sense of his suggestion (I should have answered anyway). Notice the ne2000 (ISA card) was/is not using the IRQ assigned to the pci. When I remove the ISA NE200 card from the box the machine boots without any problem (which confirms Mr Pandya observation misses the real problem). Reading the followups in the other PRs http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26686 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18201 sheds lights on the problem, and also suggests a solution originally proposed by G.W.Roberts <mas039"@bangor.ac.uk> on 27-Apr-2001. There is certainly a duplication of the PR, but at the time I wrote those I did not know. May I suggest you collect the relevant info in the latest PR's with references to the other (probably to-be-closed ones)? Thanks for such a timely and good "user support" work! Lazaro D. Salem ------------------------------------------------------------------- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you. |
I am using the 4.3RC4 floppies. After inserting the mfsroot.flp and configuring drivers w/Kernel config Menu in visual mode, I left (the minimal) following Active Drivers: Dev---IRQ--Port Storage: ata0 14 0x1f0 ata1 15 0x170 fdc0 6 0x3f0 Communications: ppc0 7 sio0 4 0x3f8 Input: atkbd0 1 psm0 12 sc0 Miscellaneous: npx0 13 0xf0 Them quit and saved config, and let the kernel autoprobe devices: --- begin transcript of last lines seen on the screen: 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> port 0xfce0-0xfcff irq 9 at device 4.2 on pci0 usb0: USB revision 1.0 uhub0: 2 ports with 2 removable, self powered chip1: <Intel 82371AB Power management controchip1: <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 --- End of transcript After which the system completely hangs. The only way to reboot/turn-off the system is by pulling the cable from the wall. No keyboard or on/off switch reaction. -- Notice the IRQ 9 is used by the two graphic cards on this system, and by the USB, although at different ports. I then tried disabling IRQ 9 on the BIOS setup as following: From the PhoenixBIOS Setup Utility -> Advanced -> ISA Resource Exclusion (*) -> I then changed the value of the IRQ 9 item from "Available" to "Reserved" (**). All the other IRQ items (3,4,5,7,10,11 and 15) were left "Available". Trying to boot again after this BIOS setup, does not help: The system freezes at the same point with the same messages as above except for the following: every instance of 'irq 9' in the text above is replaced by 'irq 11'. If in addition to disabling the IRQ 9, I also disable the IRQ 11 and retry, the machine still hangs ('irq 11' is now replaced by 'irq 10'). Notes: (*) For this option, from the 'Item Specific Help' panel in the BIOS setup, I read: Reserves interrupts for legacy ISA devices to prevent conflict with PCI/PnP devices (**) The option Available allows to allocate IRQ for PCI or ISA PnP devices. Fix: Workaround: Maybe disabling probing of USB _and_ Power management in GENERIC? Fix: I do not really know. First, notice the system has presently two graphic cards: one integrated in the motherboard (AGP Cirrus Logic Laguna GD5465) and an external one (Number 9 Imagine 128) and both are on the PCI bus. The USB and the two graphic cards presently are reported to use the same IRQ, although at different ports. Should that happen at all? I am also not really sure that this is an IRQ asignement problem, as a first look suggests. It might have to do with the power management controller... It is worth to mention I had this problem every time I tried booting from releases floppies in the 4.x branch. In all those attempts (specifically using 4.0-R,4.1.1-R and 4.2-R floppies) I had only _one_ graphic card. I still observed the same problem, which was reported in PR misc/18201. The USB messages were then slightly different. I guess that is due to the work done on the USB code since 4.0-R. But still the IRQ 9 was shared by the USB and the single graphic card (Cirrus Logic GD5465). In those cases the system stopped responding just after printing: [snip previous lines] chip1: <Intel 82371AB Power management controller> port 0x8800-0x880f at device 4.3 on pci0 -- After that I had always to pull the chord to reboot. Puzzle: with 4.3RC4 the system hangs after recognizing the 2nd graphic card, printed after probing the Power management controller. If the 82371AB was the culprit, shouldn't it hang before the last line when trying 4.3RC floppies?. Another failed attempt was as follows: When playing with the 4.1.1 CD, I managed to install the src/sys tree, edited GENERIC, commented out all USB support in it (at least I thought so) and finally compiled a 4.x kernel which I copied to the kernel.flp diskette. No changes to mfsroot.flp, though. I tried in this way to eliminate the sharing of one IRQ by two devices. The system still hanged at boot time with these floppies. ---- The box presently runs 3.5-STABLE without no other inconvenience than be "forced" to do so. I am willing to test any floppy pair you send me to overcome this problem. Thank you for reading this long post.