[linux-elitists] Laptop that doesn't suck?
Wed Jan 21 09:33:12 PST 2004
On Mon, Jan 19, 2004 at 02:05:20PM -0800, Greg KH wrote:
> SATA has only recently gotten Linux support. I can't really talk to
> that, but there are patches for 2.4 for this feature.
> Remember, as developers, we are SUPPOSED to do new types of development
> in the development kernel. After it's working there, do we do a
> backport to the stable kernel. That's just the proper way to do new
I absolutely agree. I'm just annoyed that the vendors aren't being
given the right incentives or whatever to donate developer time to
speeding the process up :)
> > 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.
> ACPI does not equal device suspend. They are two totally different
> things. See Pat Mochel's 2003 OLS paper for more information about
> this, and for an overview of all of the problems involved in trying to
> suspend a machine properly.
> So please do not blame ACPI for the lack of suspend working for your
> laptop. Truth is, suspend only barely works even on the 2.6 kernel.
> Again, see my previous comments about lack of caring by any company...
> Oh and a lack of device specs, that's another big one...
That was a good paper, thanks for the pointer.
I should probably start blaming things in addition to ACPI support for
my current suspend woes, but proper ACPI support is still required for
everything to work correctly on my particular laptop. Toshiba
implements some of the processor fan throttling stuff in AML, and for
whatever reason the implementations I've tried lock the system instead
of throttling the fan correctly.
> > > 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,
> My word. What is a "stock kernel" for Debian then? Isn't it a 2.2
> kernel? It's not the kernel developers fault that you are insisting on
> using a 2 year old or older, kernel. So don't grumble about lack of "new"
A package with a name matching the regex /^kernel-image/, or at least
that's my particular definition.
> > 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.
> I know there are 2.6 kernels available in Debian, and the last time I
> checked they had recent 2.4 kernels too. Hm, looks like it:
> $ apt-cache search kernel-image | grep "^kernel-image"
> kernel-image-2.2.20-reiserfs - Linux kernel binary image for version 2.2.20.
> kernel-image-2.4-386 - Linux kernel image for version 2.4 on 386.
> kernel-image-2.6.0-test9-1-386 - Linux kernel image for version 2.6.0-test9 on 386.
> But I'm running unstable on my Debian boxes :)
I'm running stable with 2.4.18, which doesn't cause all the machines
to suck down and upgrade dozens of packages every time I do an update
> > > 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.
> Ok. So Linux doesn't support suspend very well. That's a well known
> issue, and might change sometime in the future... (actually Linux on
> iBooks suspend quite well, but they have a limited number of devices...)
Yeah? Not even any weird crashes when you start it back up? Hmm,
maybe I'll have a look at doing that instead...
> For USB 2.0 you need a newer kernel than what you are using. It is
Yes, but I'd have to create custom kernels for a bunch of different
machines. That might not be a huge thing to do, but then I have to
*test* them so I don't piss anyone off by breaking something working,
and that's a whole different story :)
I'll probably do it for just my laptop during the next upgrade,
though. It's annoying having to wait for 3 minutes every time I do a
full rsync on my USB key :P
> > 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?
> I use ext3 and have a laptop with very good power saving support :)
And it doesn't keep the thing spun up the whole time? Which laptop is
this? The iBook? How does that work? I thought that the journal
commit every 5 seconds prevented any kind of hard drive power
management from working...
> > 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.
> Nothing the kernel can do there, sorry.
The point was that that is the reason I avoid development kernels,
even though using them would solve many of my current problems.
> > captive
> > zapata
> What are these two? Haven't heard of them before.
captive allows you to use the native Win32 ntfs.sys driver to access
your NTFS partitions from within Linux. It's basically a partial
Win32 kernel emulation layer. There's also two additional, competing
projects which emulate the parts of the Win32 kernel necessary to load
NDIS drivers, which allow you to use Windows NDIS drivers for network
devices (for support of wireless devices with no open driver, for
zapata is a telephony subsystem necessary to run asterisk, an open
source telephony application.
> > 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.
> You are saying that NVidia has code that infringes on another company's
> IP in their closed source module? Oh, that makes me feel even better...
No, they license it, or at least they did the last time I checked.
> > 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.
> The situations I'm describing are where I change a PCI api, and fix up
> all places in the kernel tree that use that api. As I can't see the
> NVidia code, I can't fix up their usages also.
> Users then grab the new kernel, and whine to me that their closed source
> code is broken. There's nothing I can do about this (and don't even try
> to say "don't change the api," that will _never_ happen, and is a whole
> different thread.)
I can see how that would be an annoying situation for you. You might
want to go to one of the 3-D developer conferences and meet some
NVidia engineers, which would allow you to have a more open dialogue
with the people that do the Linux driver development.
> > > 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.
> Pointers to specific drivers? Are they outside of the main kernel tree?
> I keep hearing this vague "people need to convert their drivers"
> argument, and it worries some people at my workplace, yet no one can
> come up with specifics...
The gdth driver is for the Intel/ICP raid cards, the vpb driver (not
in kernel) is for the Voicetronix telephony cards, the dialogic driver
(not in kernel) is for the Dialogic telephony cards, I can't remember
the name of the driver for the data acquisition board I was having
trouble with, modbusfs for Modbus filtering, and modp for Modicon cards.
- Jason Currently at: Ohlone College (Fremont, CA) (Fair)
A body of elderly gentlemen charged with high duties and
-- Ambrose Bierce
More information about the linux-elitists