Bug 101630 - (ACPI) can't get network address via dhcp after a PXEboot of the kernel, unless pci=noacpi
(ACPI) can't get network address via dhcp after a PXEboot of the kernel, unle...
Status: CLOSED UPSTREAM
Product: Red Hat Linux Beta
Classification: Retired
Component: kernel (Show other bugs)
beta1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Brian Brock
:
: 101633 101654 (view as bug list)
Depends On:
Blocks: CambridgeTarget
  Show dependency treegraph
 
Reported: 2003-08-04 17:37 EDT by david d zuhn
Modified: 2013-07-02 22:13 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-03-03 03:47:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output from acpidmp (75.16 KB, text/plain)
2003-08-11 13:27 EDT, david d zuhn
no flags Details
Output from dmidecode (5.14 KB, text/plain)
2003-08-11 13:28 EDT, david d zuhn
no flags Details
dmesg output from DHCP failure (8.85 KB, text/plain)
2003-08-11 13:35 EDT, david d zuhn
no flags Details
/proc/interrrupts from a boot where DHCP failed (505 bytes, text/plain)
2003-08-11 13:36 EDT, david d zuhn
no flags Details
dmesg & /proc/interrupts from a non-working boot (no ACPI kernel options) (9.36 KB, text/plain)
2003-08-12 11:03 EDT, david d zuhn
no flags Details
dmesg & /proc/interrupts from a working kernel (pci=noacpi) (9.47 KB, text/plain)
2003-08-12 11:03 EDT, david d zuhn
no flags Details
ACPI VT86/Award PCI interrupt patch. (12.21 KB, patch)
2003-08-21 18:23 EDT, Len Brown
no flags Details | Diff

  None (edit)
Description david d zuhn 2003-08-04 17:37:32 EDT
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.
Comment 1 david d zuhn 2003-08-04 17:44:14 EDT
*** Bug 101633 has been marked as a duplicate of this bug. ***
Comment 2 Bill Nottingham 2003-08-04 23:42:23 EDT
What happens if you boot with acpi=off?
Comment 3 david d zuhn 2003-08-05 10:15:35 EDT
I get past this stage correctly when I boot with the same command line having
added acpi=off.

Comment 4 Michael Fulbright 2003-08-05 11:12:35 EDT
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.
Comment 5 Michael K. Johnson 2003-08-08 15:59:48 EDT
Please run as root and post the output of
/usr/sbin/dmidecode
/usr/sbin/acpidmp
Comment 6 Len Brown 2003-08-08 18:06:34 EDT
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.

Comment 7 david d zuhn 2003-08-11 13:27:49 EDT
Created attachment 93580 [details]
Output from acpidmp
Comment 8 david d zuhn 2003-08-11 13:28:19 EDT
Created attachment 93581 [details]
Output from dmidecode
Comment 9 david d zuhn 2003-08-11 13:35:25 EDT
Created attachment 93582 [details]
dmesg output from DHCP failure

The boot command did NOT have any APCI specific flags for this run.
Comment 10 david d zuhn 2003-08-11 13:36:02 EDT
Created attachment 93583 [details]
/proc/interrrupts from a boot where DHCP failed
Comment 11 david d zuhn 2003-08-11 13:40:06 EDT
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.

 
Comment 12 Len Brown 2003-08-11 18:09:17 EDT
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. 
 
Comment 13 david d zuhn 2003-08-12 11:01:54 EDT
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.


 

Comment 14 david d zuhn 2003-08-12 11:03:17 EDT
Created attachment 93601 [details]
dmesg & /proc/interrupts from a non-working boot (no ACPI kernel options)
Comment 15 david d zuhn 2003-08-12 11:03:51 EDT
Created attachment 93602 [details]
dmesg & /proc/interrupts from a working kernel (pci=noacpi)
Comment 16 Len Brown 2003-08-21 18:23:35 EDT
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
Comment 17 Bill Nottingham 2003-10-21 16:20:48 EDT
*** Bug 101654 has been marked as a duplicate of this bug. ***

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