Re: Basic linux network questions (long)
> Richard Wurdack writes:
> >> I discover, however, that if I shut the lid on the box (it might be
> >> hibernating, don't know - I didn't doing anything special for APM),
> >> and reopen it, pon can't dial out without a reboot (just like
> >> Windows!).
>
> ThinkPads, by default, suspend when you shut the lid. You can probably
> change it . . .
>
> BTW, since you're using a ThinkPad, you might want to look at the tpctl
> and tpctl-modules-source packages. It's configuration tools for
> ThinkPads, which may or may not work on your particular model. You'll
> need to install tpctl-modules-source first, build and install the
> modules, and then you can install tpctl.
definitely worth looking for.
> Heather> Nowadays some boxen are much better at speaking ACPI, but the
> Heather> degrade after a kernel build suggests that APM was probably
> Heather> enough. In "make menuconfig" this is at the bottom of one of
> Heather> the upper sections.
>
> If you want to try ACPI, though, beware that kernel support for it is
> not as mature as for APM, and it may not work as well.
To clarify re ACPI:
Kernel support seems to be much further along than it was several months
ago... but that's just allowing the core to "speak ACPI". Numerous kernel
drivers need to be updated to match it, in order for those respective
devices to do the right thing when a given ACPI level is triggered. This
is somewhat more complicated than the simple yea/nay of APM and so it's
going a bit slowly.
Incredibly basic services are getting covered though and a userland daemon
must be used for ACPI just as in APM.
To clarify re what I meant to say:
The *hardware* is better on many modern boxen, at providing or responding to
ACPI rather than APM style signalling.
So you have a tradeoff, excellent software in the APM space but a brain-dmgd
suspend-APM signal will (and often does) result in spurious crashes on
suspend/resume. As opposed to excellent hardware but minimal software in the
ACPI space, means some devices may not get on the clue wagon, and not be quite
right after resumes. aaaagh ;P
> >> Problem #3 This is the real blocking issue. Today I bring the laptop
> >> back to work, because I want to download some big packages. First,
> >> no pcmcia, because I didn't really do everything I needed to when I
> >> build 2.2.20 (specifically, no pcmcia module in
> >> /lib/modules/linux2.2.20). Ok, no big deal, since I still have my
> >> 2.2.19 kernel in /boot. Boot 2.2.19, run dhcpcd (as usual, see
> >> Problem #1). Domain names aren't resolving (ping www.yahoo.com
> >> <http://www.yahoo.com> - host unreachable), but I can ping IP
> >> addresses.
>
> For a 2.2 kernel, you'll need to get the pcmcia-source and compile it.
> As Heather suggests, make-kpkg can help reduce headaches.
> "kernel-package" is the name of the package you should install. Then
> "man make-kpkg".
>
> Heather> David Hinds' stuff available as source seperately or from
> Heather> unstable.
>
> (David Hinds? Oh, pcmcia-cs.)
Yes.
In the 2.4 kernel series Linus has a competing tree of pcmcia support,
and trying to use both may have... odd effects. Me, I'm grumpy because
that stuff doesn't support some odd bits around my lab, so I stick with
the real deal, and have so far recommended it unless you happen to have
the "yenta" cardbus (as he calls it -- newer series Intel??), in which
case, Linus may support you a bit better at the bridge level.
> >> Looked at the networking HOWTO - the only thing I found that looked
> >> wrong was that route.conf was empty, so I added our DNS servers. I
> >> can ping the DNS servers (by IP address), but name resolution still
> >> fails.
>
> Look at resolv.conf. That's where your DNS servers should go.
> (man resolve.conf)
^^
There was an "e" eating monster roaming around during the early days of
UNIX. It nailed the creat() system call too. No wait, the SAGE (sysadmin's
guild) claims responsibility for that last one :)
* Heather Stern * star@ many places...
Reply to: