Re: various laptop nagles - any suggestions? (note: 2.6.19-rc2-mm1 but applies to multiple kernels)

[Andrew Morton <akpm@osdl.org>]

On Fri, 20 Oct 2006 09:30:37 -0700
teunis <teunis@wintersgift.com> wrote:

> 

Please don't play with the Cc:s!  Just do reply-to-all, thanks.

> Andrew Morton wrote:
> > On Thu, 19 Oct 2006 09:05:49 -0700
> > teunis <teunis@wintersgift.com> wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Setting the internal clock to 100 Hz stablizes the laptop - and the
> >> synaptics touchpad stops "crashing"  (when "crashed" the pad reads out
> >> all kinds of seemingly random values).   I would suspect the driver
> >> needs adjusting for the variable clock.   Also - it's definitely nicer
> >> on the laptop power use as far as I can tell - should this be in the
> >> documentation?
> > 
> > So you're saying that CONFIG_NO_HZ breaks the touchpad?
> 
> yes.  At least for Acer Travelmate 8000 and HP nx6310 and HP nx7400.
> Other than the touchpad - there is not a lot of common hardware between
> these units.   The readout becomes highly unreliable.   (in X it starts
> jumping around - it SORT OF resembles the output)
> 
> My suspicion is a timing problem in the synaptic USB driver

OK, that's going to be hard to fix and it'd be awkward (and unpopular) to
make inclusion of the dynamic-ticks feature dependent on fixing this. 
(Then again, it'd get Ingo into device drivers ;))

However I would suggest that NO_HZ (at least) be dependent upon
CONFIG_EXPERIMENTAL, no?

Also, NO_HZ breaks my laptop (and presumably quite a few others) quite
horridly, which means nobody can ship the feature.  Some runtime
turn-it-off work needs to be done there.


> - but I'm
> not familiar with timing on kernels these days.  It's been a few years
> since I last really did any kernel work.
> 
> > 
> >> I'm very grateful that compact flash-based booting on a SATA system
> >> works well.   It hasn't been so reliable in 2.6.19-rc2-mm1 for IDE/CF
> >> adaptors but I haven't yet solved why.   (tested with various laptops)
> > 
> > hm.  What goes wrong?
> 
> Fails to boot some of the time on SanDisk ultraII 8.0GB and SanDisk
> Extreme IV 8.0GB.   The latter is less stable.   It crashes during GRUB
> read actually so I haven't been entirely sure it's a kernel problem...

Don't know, sorry.

> > 
> >> resume from "suspend to ram" (ACPI S3 mode) - the keyboard and mouse do
> >> not recover on 945G chipset.   Note that otherwise the chipset works
> >> well in 2.6.19-rc2-mm1 - and this is the first kernel that does work well).
> > 
> > So this might not be a new bug?
> 
> A regression.   2.6.19-rc1-git6 seemed to work actually.   I couldn't
> get any other kernel to work though...   mind you, 2.6.18 worked as well
> although the intel 945G driver did not - so X was operating under VESA only.

So you're saying that there is some patch in the -mm lineup which causes
the keyboard and mouse to die after resume-from-RAM?

What makes you think this is related to the 945G support?

> >> LVM2 - when adding and removing physical volumes (again, on Compact
> >> Flash cards via USB and Firewire adaptors) - it doesn't always remove
> >> the volume properly (pvremove /dev/sda or equiv) from the device-mapper.
> >>  This leaves me unable to plug in another.   I suspect this to be an
> >> LVM2 problem (no hotplug?) rather than a compact flash or SCSI problem.
> > 
> > Can you identify an earlier kernel in which this worked OK?
> 
> As far as I can it never has.
> 
> I've only tested it with:
> 2.6.16-debian, 2.6.17-debian, 2.6.18, 2.6.19, 2.6.19-rc1,
> 2.6.19-rc1-git4, 2.6.19-rc1-git6, 2.6.19-rc2, 2.6.19-rc2-mm1 (which
> otherwise works quite nicely)

Please try 2.6.19-rc2-mm2: it has a blockdev refcounting fix (well - a
change, at least) which could conceivable help here.

Also, if you're keen,
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt will
allow us to identify the problematic -mm patches.  It would be super-useful
is you could do that.

Thanks.