Bug 101630
| Summary: | (ACPI) can't get network address via dhcp after a PXEboot of the kernel, unless pci=noacpi | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux Beta | Reporter: | david d zuhn <zoo> |
| Component: | kernel | Assignee: | Jeff Garzik <jgarzik> |
| Status: | CLOSED UPSTREAM | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | beta1 | CC: | acpi-bugzilla, davej, ivo, peterm |
| 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-03-03 08:47:54 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: | |||
| Bug Blocks: | 100644 | ||
| Attachments: | |||
*** Bug 101633 has been marked as a duplicate of this bug. *** What happens if you boot with acpi=off? I get past this stage correctly when I boot with the same command line having added acpi=off. I've seen this problem on a duron system with a e100 card as well. I've since dismantled it so I can't immediately verify the apci=off would work. Please run as root and post the output of /usr/sbin/dmidecode /usr/sbin/acpidmp Try booting with "pci=noacpi", and if that fails, "noapic" If you get the disk installed and can boot from there with a failing e100, then snag the dmesg and /proc/interrupts. Then the dmesg and /proc/interrupts from the working system. TIA. Created attachment 93580 [details]
Output from acpidmp
Created attachment 93581 [details]
Output from dmidecode
Created attachment 93582 [details]
dmesg output from DHCP failure
The boot command did NOT have any APCI specific flags for this run.
Created attachment 93583 [details]
/proc/interrrupts from a boot where DHCP failed
Booting the installer kernel with pci=noacpi gets me past the failing DHCP. I need to do the same for the running kernel (via grub.conf in my case), or else I fail to get a working DHCP lease on system boot. The various items asked for have all been attached. I'm also using the same system for other testing, but I can recreate this installation easily, but it may require a bit of time. The dmesg kernel build date/time doesn't match the severn installed kernel I've got, nor does it match the floppy or cdrom installer kernel. I guess this is a special PXE boot config'd kernel? It would be handy to know the config for the kernel, since it is behaving as if APIC support is _not_ built in. The system is coming up in XT-PIC mode, even though your acpidmp output has an MADT showing both LAPIC and APIC support. I would expect to see something like this from the CDROM install kernel, or either the UP or SMP installed kernels: ACPI: APIC (v001 BIOSTA AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x(nil) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0]) ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x0]) ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x0] trigger[0x0]) Even so, XT-PIC mode should still work -- but you're getting this: parport0: irq 7 detected lp0: using parport0 (polling). lp0: console ready spurious 8259A interrupt: IRQ7. While /proc/interrupts doesn't show anything registered on IRQ7, and it doesn't show eth0 registered at all. For the installed kernel, can you: 1. boot w/ no params (failure case), capture dmesg and /proc/interrupts? 2. boot w/ pci=noacpi (success case), capture dmesg and /proc/interrupts? If you go to the trouble to build your own kernel, enabling CONFIG_ACPI_DEBUG might give give us some clues. TIA. Well, the initial install was done via PXE, so I was using the kernel & initrd from disc1/images/pxeboot/, but the same issues apply to the installed kernel as well. This is a stock RH kernel, on an Athlon system, so I have the Athlon specific kernel installed. I have not rebuilt from source. Created attachment 93601 [details]
dmesg & /proc/interrupts from a non-working boot (no ACPI kernel options)
Created attachment 93602 [details]
dmesg & /proc/interrupts from a working kernel (pci=noacpi)
Created attachment 93838 [details]
ACPI VT86/Award PCI interrupt patch.
This patch has fixed the ACPI interrupt problem for similar systems.
Please try applying it to a copy of your Severn BETA1 kernel to
see if works for you too:
~/src/linux-2.4.21-20.1.2024.2.1.nptl> patch -Np1 < ./pci_link-severn.patch
patching file arch/i386/kernel/io_apic.c
patching file arch/i386/kernel/mpparse.c
patching file drivers/acpi/pci_irq.c
patching file drivers/acpi/pci_link.c
patching file include/acpi/acpi_drivers.h
*** Bug 101654 has been marked as a duplicate of this bug. *** |
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131 Description of problem: I've configured a machine to do PXE based network installations. I've done many network installations on this configuration, so I'm sure I've got a fairly normal network configuration on my existing server (DHCP, tftp, etc). This machine is completely headless. A serial port is used for console access. I have no VGA screen attached, nor a mouse. A keyboard is attached, but is not used at all during this process. I have the following two boot lines in the pxelinux config file: label install-rhel kernel /redhat/rhel/ia32/vmlinuz append ip=dhcp initrd=/redhat/rhel/ia32/initrd.img console=ttyS0,115200 vnc vncpassword=<password> label install-severn kernel /redhat/severn/vmlinuz append ip=dhcp initrd=/redhat/severn/initrd.img console=ttyS0,115200 vnc vncpassword=<password> When I install RHEL (Taroon beta), my networking setup works as I expect. When I install Severn, the installer is repeatedly offered an IP address, but apparently ignores the offer and eventually times out and re-prompts me for my networking configuration. If I manually enter the right values, and then I enter my NFS server information, the Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. boot my system via PXE. The kernel and initrd are from severn disc 1, images/pxeboot. 2. use the pxelinux config line for install-severn (see above). 3. I'm prompted for language (English), install type (NFS), and then the installer does a round of DHCP queries (from my DHCP server log, I see the DHCPREQUESTs and the DHCPOFFERs, which all look correct). 4. I'm then prompted to enter my networking information, with an option to use DHCP. If I use DHCP, the same round of activity occurs. This occurs as many times as I'm willing to attempt the cycle (probably 6 or 7 cycles). 5. If I enter the information manually, I'm then prompted for my NFS server & pathname and then (after a pause), I get the following error message "That directory could not be mounted from the server.". No NFS errors messages showed up in the logs on my server machine. Actual Results: I cannot do a complete network installation. Expected Results: I should be able to do an installation entirely via the network. I am able to do so using Taroon or Red Hat Linux 9, on this exact hardware configuration. Additional info: This machine has an e100 card as the sole network device.