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 - (ACPI) can't get network address via dhcp after a PXEboot of the kernel, unless pci=noacpi
Summary: (ACPI) can't get network address via dhcp after a PXEboot of the kernel, unle...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: kernel
Version: beta1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Brian Brock
URL:
Whiteboard:
: 101633 101654 (view as bug list)
Depends On:
Blocks: CambridgeTarget
TreeView+ depends on / blocked
 
Reported: 2003-08-04 21:37 UTC by david d zuhn
Modified: 2013-07-03 02:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-03-03 08:47:54 UTC
Embargoed:

Attachments (Terms of Use)
Output from acpidmp (deleted)
2003-08-11 17:27 UTC, david d zuhn 		no flags Details
Output from dmidecode (deleted)
2003-08-11 17:28 UTC, david d zuhn 		no flags Details
dmesg output from DHCP failure (deleted)
2003-08-11 17:35 UTC, david d zuhn 		no flags Details
/proc/interrrupts from a boot where DHCP failed (deleted)
2003-08-11 17:36 UTC, david d zuhn 		no flags Details
dmesg & /proc/interrupts from a non-working boot (no ACPI kernel options) (deleted)
2003-08-12 15:03 UTC, david d zuhn 		no flags Details
dmesg & /proc/interrupts from a working kernel (pci=noacpi) (deleted)
2003-08-12 15:03 UTC, david d zuhn 		no flags Details
ACPI VT86/Award PCI interrupt patch. (deleted)
2003-08-21 22:23 UTC, Len Brown 		no flags Details | Diff
View All

Description david d zuhn 2003-08-04 21:37:32 UTC 
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 21:44:14 UTC 
*** Bug 101633 has been marked as a duplicate of this bug. ***
Comment 2 Bill Nottingham 2003-08-05 03:42:23 UTC 
What happens if you boot with acpi=off?
Comment 3 david d zuhn 2003-08-05 14:15:35 UTC 
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 15:12:35 UTC 
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 19:59:48 UTC 
Please run as root and post the output of
/usr/sbin/dmidecode
/usr/sbin/acpidmp
Comment 6 Len Brown 2003-08-08 22:06:34 UTC 
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 17:27:49 UTC 
Created attachment 93580 [details]
Output from acpidmp
Comment 8 david d zuhn 2003-08-11 17:28:19 UTC 
Created attachment 93581 [details]
Output from dmidecode
Comment 9 david d zuhn 2003-08-11 17:35:25 UTC 
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 17:36:02 UTC 
Created attachment 93583 [details]
/proc/interrrupts from a boot where DHCP failed
Comment 11 david d zuhn 2003-08-11 17:40:06 UTC 
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 22:09:17 UTC 
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 15:01:54 UTC 
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 15:03:17 UTC 
Created attachment 93601 [details]
dmesg & /proc/interrupts from a non-working boot (no ACPI kernel options)
Comment 15 david d zuhn 2003-08-12 15:03:51 UTC 
Created attachment 93602 [details]
dmesg & /proc/interrupts from a working kernel (pci=noacpi)
Comment 16 Len Brown 2003-08-21 22:23:35 UTC 
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 20:20:48 UTC 
*** 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.