On Thu, 24 Dec 2009 13:36:30 +0000 Darren Salt <[email protected]> wrote:
> I demand that Shawn Lamson may or may not have written... > > > On Tue, 22 Dec 2009 23:21:39 +0000 > > Darren Salt <[email protected]> wrote: > > [see below] > >> I demand that Shawn Lamson may or may not have top-posted... > >>> Thanks Darren - if I use your config on the 2.6.31.9 source do I also > >>> need to apply that rt2860 patch (yes, thats the driver that's used)? > >> No; the firmware loading is specific to the Debian kernel (DFSG-freeness > >> issues). > >>> The reason I moved to the 2.6.31-r6 and up was that the reports were that > >>> this was fixed in those versions (again, it seems to be a problem once > >>> again in 2.6.32, though)... > >> A different bug was fixed. > >> [snip] > >>> Thanks for the input, let me know about that patch and config, and i'll > >>> report back. > >> Which compiler version are you using? I ask mainly because there are > >> presently reasons to avoid 4.4 if certain kernel debugging options are > >> enabled. > > >> [snip; you don't top-post, I don't remove context] > > > well... pretty much the same results, unfortunately, with the 2.6.31 > > .config you provided Darren - though I must say it's a sweet piece of work. > > I had a few ups and downs with it, haven't ironed them out yet - at one > > point it just wouldn't boot at all (after a crash? after i removed > > something else?)... > > Which is a bit odd. It worked fine here, as did 2.6.32... > > > but i am keeping my stock 2.6.31-6 kernel for backup... > > > Would you entertain a couple of questions? I noticed that > > CONFIG_BLK_DEV_INITRD is not set and at first I thought maybe the kernel > > was small enough not to use initramfs, but i am not certain what's going on > > there... > > Everything which I need at startup is built in. > > > I wound up enabling this because i do generate initrd/initramfs images... > > is this covered somewhere else in the config options or is it ubiquitous > > now and assumed that initrd/initramfs is going to be used? > > It's not assumed at all; some of us choose not to use them. > > [snip] > > Also, aside from the situation where it wouldn't boot that kernel, the > > only other 2 issues i had were > > a) elantech touchpad mouse wouldn't accpet two-finger clicking (emulate 3rd > > > mouse button) ... I tried several compiles, enabling the > > # CONFIG_MOUSE_PS2_SYNAPTICS is not set > > Not needed. CONFIG_MOUSE_PS2_ELANTECH=y. > > > and > > # CONFIG_MOUSE_SYNAPTICS_I2C is not set > > Again, not needed. > > > but this didn't resolve it, I read up on it a bit, and i could try fixing > > it using some HAL setting or synclient ... > > Well... X/evdev default to not enabling tapping... I have a steep learning curve, I haven't tinkered that much with kernel/OS in the past few years, and a lot has changed recently ... I didn't know about HAL. I was able to get this working (Elantech touchpad) okay. Originally it had been identified as a Logitech mouse and it actually worked fine - the new kernel config just exposed an existing issue... creating /etc/hal/fdi/policy/touchpad.fdi as you suggested on http://wiki.debian.org/DebianEeePC/HowTo/ElantechTouchpad worked. > > > b) with AC plugged in, and SpeedStep enabled in BIOS, no luck, and if I > > boot up on battery and then plug in the AC while *not* in suspend-to-ram > > then likewise the system freezes - but with the config-2.6.31-eee you gave, > > this also happens with the HyperThreading Technology enabled in BIOS (and > > SpeedStep off) ... so it was actually technically a little worse in that > > regard. > > Hmm. Again, works fine here... > > > I'm going to play around with a few more .config tweaks, maybe using the > > 2.6.32 kernel source*, but if you can advise on the Elantech "two finger > > tap" issue that would probably make your .config and the 2.6.31-6 stock > > kernel equally functional and since yours is more elegant I'd settle on it. > > http://wiki.debian.org/DebianEeePC/HowTo/ElantechTouchpad has enough > information. > > > (yours takes under 20 minutes to compile - the ones i come up with take > > several hours, or else result in something not bootable!) > > Mine has no support for hardware which cannot be present, and support for > only that extra hardware which I'm likely to plug in. > > > * last time I tried 2.6.32 it was a no-go on suspend-to-ram -> resume but > > maybe things have changed in a week or so... i do use the rt2860 driver and > > i keep seeing "back and forth" on it in the various changelogs and bug > > reports... > > One thing which you should try: in /etc/default/eeepc-acpi-scripts, set > PWR_CLOCK_AC=1. This *shouldn't* make any difference, but it may well end up > making things work normally again. setting PWR_CLOCK_AC=1 in eeepc-acpi-scripts did the trick, i've been testing it for the last few days and it's unshakeable now, thanks, that was a long road. is there another mailing list (debian eeepc) for "general questions" that are less development related? I see there is an IRC channel, I guess I'll lurk there. Thanks again Darren - I hope Santa was good to you, and have a happy New Year. Shawn > > Trying > # echo 0 >/sys/devices/platform/eeepc/cpufv > on a "known-good" OS is probably also worth doing. > > (I'm still thinking "bad hardware".) > > > Merry Christmas! > > Humbug! ;-) > > > P.S. bonus round ... i compile the kernel on my desktop PC, then scp the > > .deb to the netbook and dpkg -i it there... here is what i get: > > > netbook:~# dpkg -i > /home/slamson/linux-image-2.6.31.9-eee901_2.6.31.9-eee901-10.00.Custom_i386.deb > [snip] > > Running postinst hook script update-grub. > > Generating grub.cfg ... > > Found background image: moreblue-orbit-grub.png > > Found linux image: /boot/vmlinuz-2.6.31.9-eee901 > > Found linux image: /boot/vmlinuz-2.6.31.6 > > Found initrd image: /boot/initrd.img-2.6.31.6 > > done > > > what's the deal with the /lib/modules directory? > > Buy one, get one free? Guaranteed free of symlink farms, or your money back? > > > and why do you think initramfs-tools fails? (see the "Found linux image" > > statements, missing initrd.img-2.6.31.9-eee901 ... but if i run > > update-initramfs -c -k 2.6.31.9-eee901 it works fine (in fact i got the > > commands by tracking down the initramfs-tools file! > > I don't see any failure there. > I misundertood what was intended by /etc/kernel/postinst.d/initramfs-tools # kernel-package passes an extra arg; hack to not run under kernel-package [ -z "$2" ] || exit 0 so it's not intended to generate an initramfs image when you run dpkg... -- Shawn Lamson [email protected] _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
