[linux-elitists] Laptop that doesn't suck?

Jason Spence jspence@lightconsulting.com
Mon Jan 19 13:12:14 PST 2004


On Mon, Jan 19, 2004 at 09:32:34AM -0800, Greg KH wrote: 
> On Sun, Jan 18, 2004 at 02:50:18PM -0800, Jason Spence wrote:
> > 
> > I have a few other things to say about laptop support: every 2 to 2
> > 1/2 years or so the state of Linux support for newish standards in the
> > stable kernel goes down the toilet because everyone's concentrating on
> > the development kernel and many users aren't able or willing to do
> > free troubleshooting with the development kernel in addition to trying
> > to use their apps on their laptop.
> 
> So, to be specific, what do you mean here?  ACPI?  There was a patch
> that lived a _long_ time outside of the main 2.4 kernel tree due to the
> stable maintainer wanting to be careful about what was merged.  So if
> you needed good ACPI support on 2.4, you simply used that patch.  It's
> been successfully merged into the mainline 2.4 kernel a while ago.

ACPI is one of the big ones, yes.  Other culprits include serial ATA
w/ tagged queuing and stable USB drivers for some of my camera
equipment.  

I'm aware of the ACPI patches, but they don't solve the underlying
problem which is that the driver architecture isn't very friendly to
power management.  The last time I tried the bleeding edge ACPI stuff
for 2.4, I still couldn't suspend 2 out of 3 laptops I tried it with.

> How about USB?  USB 2.0 support was offered as a backport to 2.4, and
> made it into the main 2.4 tree, relatively quickly (way before any other
> OS had support for it.)

Unfortunately, Debian doesn't support USB 2.0 in their stock kernel,
and at one site I deal with they're so heterogenous that it's not cost
effective for me to maintain custom kernels for all their machines.  I
also can't use anything but Debian because the site (a school) can't
afford RHN.

> Is this what you were talking about?  Or do you have other specifics of
> stuff that during 2.4 was not available, but only present in the 2.5
> tree?

Those are the only ones I can think of off the top of my head; I may
be forgetting something, though.

> > Sometimes you get lucky and the development kernel doesn't suck, but
> > other times it's just a pain in the ass and you get these weird bugs
> > that cause your machine to lock up and you lose data...
> 
> I used _every_ 2.5 kernel on my main desktop machine and my laptops and
> never lost any data.  Sure stability wasn't the best at times (usually
> my own code's fault), but using a journalling filesystem prevented long
> fsck times at reboot.

Well, the thing about ext3 is that it keeps the hard disk active all
the time :) It's a big power drain to keep my 40GB driver spinning the
entire time I have the laptop on.  I've heard anecdotal reports that
xfs and/or jfs don't do that; are those the journalling filesystems
you're referring to?

The other annoying thing is that the web browsers don't talk to the
session manager on KDE or GNOME, so every time I get a crash I have to
reopen all this context I had available on virtual desktops, etc.

> > The dip in standards support is especially bad now, because of all the
> > new standards that suddenly started getting used heavily in laptops,
> > such as ACPI, SATA, new SMBIOS standards, the video chips, non 4:3
> > screens, etc.  Until most of the vendors start porting their stuff to
> > 2.6, you can't get good driver support from h/w vendors and kernel
> > support for core stuff like ACPI (which is less sucky in 2.6, but is
> > still nowhere near as complete as even FreeBSD's support).
> 
> Heh, you do realize that the FreeBSD and Linux ACPI code is identical
> and is generated from the same main code base?  A bunch of filters are
> used to generate the code for the different OSs to match their coding
> standards and other things.  So there are no differences :)

Yes, I'm aware that they come from the Intel thingie.  The thing I'm
complaining about isn't those components, it's their integration with
the other parts of the kernel.  It's one thing for the AML interpreter
to run whatever AML is in the BIOS to respond to a suspend event, but
it's a completely different thing to put all the devices in S3
correctly so when you start the machine back up everything works :)

For whatever reason, that scenario is way more reliable in FreeBSD
than in Linux at the moment on my particular hardware.

> Also, what vendors will port to 2.6?  What vendors keep stuff outside of
> the kernel that is meant for laptop or desktop hardware?  I know of some
> scsi drivers, that are vendor maintained and need to be ported, but
> that's about it.  I don't want to talk about nVidia, their closed source
> driver causes more problems for kernel developers than I think anyone
> knows (my inbox turned into a smoking mess after I "broke" the nvida
> driver during the 2.5 development cycle.  Nevermind the fact that I have
> no way of knowing that I would do such a thing as there's no way to see
> the source of the driver...)

Off the top of my head, I have to recompile these modules whenever I
upgrade the kernel:

VMware monitor/network drivers
NVidia video drivers 
lm_sensors
captive
zapata

The only two closed source ones on here are VMware and NVidia, and I'm
wary of upgrading some of my production machines (including my laptop)
until the vendors claim it works ok with 2.6.  I might get lucky and
everything might work, but on the other hand I might start getting
weird lockups in the X server and then I get to play the
stare-at-the-code game to figure out whether it's a NVidia 2.6
compatibility issue or me poking the OpenGL libraries incorrectly.

In defense of NVidia: SGI owns a buttload of 3-D patents on various
things, and it's rather difficult to put together a hardware
accelerated OpenGL implementation that performs at competitive speeds
AND includes all the SGI_* ARB extensions without paying off SGI and
using the IP.  As a result, NVidia has very little choice except to
make some of the kernel parts of their driver closed source.  So if
we're going to complain to anyone, it should be SGI, not NVidia.
There's also another vendor that owns a bunch of IP which NVidia
licenses, but I can't remember their name right now.

I'm rather happy that I have a commercial quality GLX/OpenGL
implementation for my favorite operating system, regardless of the
closed sourceness of the driver.  I already know many details of the
internals of their implementation and really wouldn't benefit from
being able to read the source.  If I have problems, I talk to their
engineers and they're very responsive to my problem reports.  I'm very
surprised you haven't developed a relationship with one of them to
help with situations like the one you're describing.

> Remember, no laptop vendors care about Linux yet.  No one is paying
> anyone to port or develop this code.  Intel has a very small number of
> developers working part time on the Linux ACPI code base, but that's
> mainly because so many servers rely on ACPI these days (and they
> realized that this was going to happen, so it was nice of them to
> provide the support for it, Linux and the BSDs are better off now
> because of it.)
> 
> So besides that meager support from Intel, what vendors are you thinking
> of?  Hell, no one even cares about USB enough to fund its development,
> even though you can't buy a server these days without a USB connection
> for the keyboard...

Some of the RAID card vendors (Intel/ICP comes to mind), telephony
card vendors, data acquisition boards, and some of the industrial
control network interfaces are the ones that I've been worrying about
this month.

-- 
 - Jason              Last known location:  1.0 miles southeast of Fremont, CA

Go 'way!  You're bothering me!



More information about the linux-elitists mailing list