Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having

On 10 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<1149936934.387240.124510@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, iforone wrote:

I know you know I'm not the OP, and for the sake of clarification, my
issue seems to be the almost exact *opposite* of the OP's; In my win98
+ Debian Sarge 3.1r1 (2.6.8-2 kernel) dual-boot setup, it's when I boot
up into *win98* after being in Debian for a while (anywhere from 1 day
to however long) that Microcrud's 'ZeroConf' crap occurs in win98 for
me. My (quickest) workaround has been to just reboot....ala the MS way
:-/

OK - let's clarify this - when you reboot to get it to work, it this a
power-cycle (or front panel reset button), or just the three-finger-salute?

The rational is that a power-cycle or front panel reset switch does a full
hardware reset - there actually is a wire on the motherboard going to all
ISA and/or PCI sockets and the "important" chips on the motherboard (such
as the CPU) labeled /RESET. Dragging that "low" for <mumble> clock cycles
resets all hardware to a known state. The three-finger-salute on the
other hand, just generates a signal to the operating system ALONE to start
running some piece of code (in windoze, this used to cause it to restart
the software - in Linux, look in /etc/inittab to see what your system is
configured to do), but it does exactly nothing to the hardware. Also, if
the operating system is out in la-la land somewhere and not reading the
keyboard, the three-finger-salute isn't even seen, never mind acted upon.

The ZeroConf address would come up in windoze if it thinks it loaded the
device driver OK (meaning only that no error messages were received while
loading the driver), and then when it tried to contact a DHCP server, it
got no error indication from the hardware, but also was not able to contact
any DHCP server.

In your case, this is _somewhat_ similar to the O/P (although you seem to
have a different NIC), in that the one operating system is leaving the
hardware in a mode that the other operating system doesn't recognize, or
doesn't know how to correct.

Some information that may be relevant;
* WakeOnLan connection from NIC to Mobo is 'connected', though I don't
use it.

I don't _think_ it's relevant - if it were, I'd expect either no, or
constant booting problems

0000:00:0e.0 Ethernet controller: National Semiconductor Corporation
DP83815 (MacPhyter) Ethernet Controller
Subsystem: Netgear: Unknown device f312

http://pciids.sourceforge.net

100b National Semiconductor Corporation
0020 DP83815 (MacPhyter) Ethernet Controller
103c 0024 Pavilion ze4400 builtin Network
1385 f311 FA311 / FA312 (FA311 with WoL HW)

OK, I think. My notes suggest that's a 'natsemi' driver.

* ACPI is active (via 'acpi=force' in GRUB Kernel command line) on this
circa 1999 Intel 440BX (PentiumII) mobo;

Can't help there.

I've uninstalled the AppleTalk Services(?) a couple months back --
During Boot, the system would take a l-o-n-g time and get hung up
(30-60seconds) trying to locate/find/initialize the AppleTalk stuff
that gets installed when choosing 'FileServer'

That's a disadvantage of some of these overly helpful installation
programs. If I wanted support for Apple (or Novell, or Samba, or...), I'd
have told you. Stop being so helpful!! Hack! Smash! Grrr...

w00t! -- I just figured out how to use gzip to view docs that have root
as owner :-) (KDE, Konquerer complains - permission denied, for good
reason, I know)

Security - it's not entirely unknown for all kinds of "sensitive" information
to accidentally get into the logs. We've had more than one user who attempted
to log in as his password, and then enter his username when prompted for the
secret word (invariably, some real wiz from Mahogany Row). Sigh...

$ sudo gzip -dc syslog.5.gz | less

That will do the trick.

So...
because my problem is the opposite, I wouldn't think this would be
useful to me(?) since it's winblows that has this 169.254.x.x addy
*after* being booted into Debian.

It could still be something similar - point is, how do you induce the
failure mode. I have only one system that dual boots (Slackware and
Red Hat), and I can not get '/sbin/shutdown -r now' to cleanly restart
the system. I must use '/sbin/shutdown -h now' and then poke the reset
button after the system reports "System Halted" - which is a lie anyway
as I can still ping the "halted" box (though I can't connect to any
other network services). If I don't do this (reset), the system gets
lost during the subsequent reboot, and wedges solid.

I wonder how much the Client for MS Networking (win98) munges the
settings.

I dunno - the snippet from Becker was responding to someone with that
problem in win98.

Thanks for any/all input about these problems, and I hope I haven't
hijacked this thread...

QUICK, SOMEONE CALL THE USENET POLICE!! HIJACKING IN PROGRESS!!!

if I have - just disregard this post - this minor issue is not a huge
deal for me, considering all the other issues I'm having with my
installation (too intricate - especially for this thread).

Not a problem. You changed the subject line, so if the O/P responds to
my original response or your response over in c.o.l.h, the subject line
will tell things apart - not that it really matters, as the problems are
related.

Old guy
.