ip/ipconfig
it communicates with the router and does
the whole DHCP business just fine.
However, when I boot into my newly installed
system and run
ip/ipconfig -D -d ether /net/ether0
I get:
ipconfig: dhcprecv: read timed out
...
forever. So, why would DHCP work in the
boot CD but not in the installed system?
The binaries haven't changed; I haven't
changed any hardware configurations.
What's going on?
Thanks,
ak
ipconfig -g gateway ether /net/ether0 ip mask
also does not work (trying ip/ping router,
for example, gives no communication).
So, still, what's going on?
ak
*nomp=1
*nobiosload=1
*nodumpstack=1
to plan9.ini, and magically
DHCP worked.
Bugs? Hardware/BIOS
problems?
On Fri, Jul 9, 2010 at 3:28 PM, Akshat Kumar
<aku...@mail.nanosouffle.net> wrote:
sounds like an interrupt routing problem. with
mp interrupts.
if you are using a 9atom kernel, the output of
/dev/irqalloc
/dev/mp*
/dev/kmesg
would be good to send along (offline) in my direction.
it sounds like the rx interrupt of your card is being
lost, and that would explain everything that you've
seen.
no (plan 9) bugs required.
- erik
without knowing the specifics, it's very hard to say.
i suppose you did try ip/ipconfig without any options
at all? and that when you did try to specify everything
manually, you did use either an old-school netmask like
255.255.255.0 or /120 and not /24. since all plan 9 ip
addresses are stored in v6 format, the netmasks need
to specify the number of bits in the network accordingly.
when i debug dhcp problems, i generally start by running
snoopy on the dhcp server.
- erik
ron
given an ioapic, the mp table just doesn't have enough information
to uniquely determine vector mappings. unfortunately this problem was
never solved. (vendor's answer: use acpi instead.) this is a leading
cause of "broken" mp tables. another leading cause is forgetting to
delete entries for hardware that bios has configured off.
- erik