Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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.