Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p
On Mon, Feb 25, 2008 at 11:46:11 -0800, Andrew Morton wrote: > On Mon, 25 Feb 2008 21:19:24 +0200 "Michael S. Tsirkin" <[EMAIL PROTECTED]> > wrote: > > > On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses > > such as Fn-F4 and lid open/close, prints them in /var/log/acpid > > and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4). > > You mean suspend-to-ram works correctly on your t61p? > > Mine suspends, then five seconds later magically resumes itself and the > screen is all black. I also have a T61p, on which STR works. I haven't tried 2.6.25, but it works with 2.6.24. Both using the suspend scripts included in Ubuntu 7.10, and with s2ram 0.8 (although I need to use --acpi_sleep 2 (s3_mode) as an option, instead of 1 (s3_bios), which is used by default on my model). But I'm using the NVidia module, so that most likely changes a lot of things. I'll see if I can find time tonight to test 2.6.25-rc3 + nv, and report back. -- Kind regards Klaus S. Madsen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p
On Mon, Feb 25, 2008 at 11:46:11 -0800, Andrew Morton wrote: On Mon, 25 Feb 2008 21:19:24 +0200 Michael S. Tsirkin [EMAIL PROTECTED] wrote: On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses such as Fn-F4 and lid open/close, prints them in /var/log/acpid and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4). You mean suspend-to-ram works correctly on your t61p? Mine suspends, then five seconds later magically resumes itself and the screen is all black. I also have a T61p, on which STR works. I haven't tried 2.6.25, but it works with 2.6.24. Both using the suspend scripts included in Ubuntu 7.10, and with s2ram 0.8 (although I need to use --acpi_sleep 2 (s3_mode) as an option, instead of 1 (s3_bios), which is used by default on my model). But I'm using the NVidia module, so that most likely changes a lot of things. I'll see if I can find time tonight to test 2.6.25-rc3 + nv, and report back. -- Kind regards Klaus S. Madsen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: T61P sound issue
On Mon, Feb 04, 2008 at 19:40:38 -0800, Andrew Morton wrote: > On Sun, 27 Jan 2008 08:49:29 -0500 "Felipe Balbi" <[EMAIL PROTECTED]> wrote: > > If a bug report fell in a forest, would ... > > > Hi all, > > > > Could anyone make T61P's ICH8 sound controller to work properly? > > ooh, a fellow t61p owner. How's suspend and resume working? I'm also a T61p owner, and for me suspend is working. I'm using Linux 2.6.24 (32 bit version) and the newest driver from NVidia (yes, I know I should be using the opensource driver, but it didn't work when I got my laptop). I haven't got hibernation working yet, but I haven't yet tried without the NVidia module loaded (and as suspend works, hibernation isn't that important for me). > > Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) > > > > Running linux-2.6.24 stable. If there's a know bug, I could try to dig > > more on it and get more info. > > It works for me. http://userweb.kernel.org/~akpm/config-t61p.txt Sound also works for me. Config at http://hogthrob.42.dk/config-t61p.txt > > Call Trace: > >[] __report_bad_irq+0x30/0x72 > > [] note_interrupt+0x22a/0x26b > > [] handle_fasteoi_irq+0xa9/0xd0 > > [] do_IRQ+0x6c/0xd5 > > [] ret_from_intr+0x0/0xa > > [] lapic_next_event+0x0/0xa > > [] __do_softirq+0x5a/0xce > > [] tick_program_event+0x31/0x4d > > [] call_softirq+0x1c/0x28 > > [] do_softirq+0x2c/0x7d > > [] irq_exit+0x3f/0x84 > > [] smp_apic_timer_interrupt+0x3f/0x53 > > [] apic_timer_interrupt+0x66/0x70 > > > > handlers: > > [] (usb_hcd_irq+0x0/0x52) > > Disabling IRQ #19 > > > > (everyone gets this btw - some weird bluetooth-vs-usb thing which we don't > know how to fix). This is actually fixed by upgrading to the newest version of the BIOS. I'm currently running version 7LETA7WW (2.07), and haven't seen the problem since I upgraded. -- Med venlig hilsen Klaus S. Madsen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: T61P sound issue
On Mon, Feb 04, 2008 at 19:40:38 -0800, Andrew Morton wrote: On Sun, 27 Jan 2008 08:49:29 -0500 Felipe Balbi [EMAIL PROTECTED] wrote: If a bug report fell in a forest, would ... Hi all, Could anyone make T61P's ICH8 sound controller to work properly? ooh, a fellow t61p owner. How's suspend and resume working? I'm also a T61p owner, and for me suspend is working. I'm using Linux 2.6.24 (32 bit version) and the newest driver from NVidia (yes, I know I should be using the opensource driver, but it didn't work when I got my laptop). I haven't got hibernation working yet, but I haven't yet tried without the NVidia module loaded (and as suspend works, hibernation isn't that important for me). Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) Running linux-2.6.24 stable. If there's a know bug, I could try to dig more on it and get more info. It works for me. http://userweb.kernel.org/~akpm/config-t61p.txt Sound also works for me. Config at http://hogthrob.42.dk/config-t61p.txt Call Trace: IRQ [80263b5f] __report_bad_irq+0x30/0x72 [80263dcb] note_interrupt+0x22a/0x26b [8026463a] handle_fasteoi_irq+0xa9/0xd0 [8020e6cf] do_IRQ+0x6c/0xd5 [8020c411] ret_from_intr+0x0/0xa [8021c1a4] lapic_next_event+0x0/0xa [8023a692] __do_softirq+0x5a/0xce [8024f060] tick_program_event+0x31/0x4d [8020d08c] call_softirq+0x1c/0x28 [8020e4e0] do_softirq+0x2c/0x7d [8023a5f3] irq_exit+0x3f/0x84 [8021c55c] smp_apic_timer_interrupt+0x3f/0x53 [8020cb36] apic_timer_interrupt+0x66/0x70 EOI handlers: [803fa647] (usb_hcd_irq+0x0/0x52) Disabling IRQ #19 (everyone gets this btw - some weird bluetooth-vs-usb thing which we don't know how to fix). This is actually fixed by upgrading to the newest version of the BIOS. I'm currently running version 7LETA7WW (2.07), and haven't seen the problem since I upgraded. -- Med venlig hilsen Klaus S. Madsen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC][BUG] updating the ctime and mtime time stamps in msync()
On Wed, Jan 09, 2008 at 15:50:15 -0500, Rik van Riel wrote: > > Specifically, the ctime and mtime time stamps do change > > when modifying the mapped memory and do not change when > > there have been no write references between the mmap() > > and msync() system calls. > > As long as the ctime and mtime stamps change when the memory is > written to, what exactly is the problem? A "not" is missing from the sentence above. The quote above should have read: > > Specifically, the ctime and mtime time stamps do _not_ change when > > modifying the mapped memory and do not change when there have been > > no write references between the mmap() and msync() system calls. So essentially the problem is that mtime stamps are _never_ changed when the file is only modified through mmap. Not even when calling msync(). -- Kind regards, Klaus S. Madsen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC][BUG] updating the ctime and mtime time stamps in msync()
On Wed, Jan 09, 2008 at 15:50:15 -0500, Rik van Riel wrote: Specifically, the ctime and mtime time stamps do change when modifying the mapped memory and do not change when there have been no write references between the mmap() and msync() system calls. As long as the ctime and mtime stamps change when the memory is written to, what exactly is the problem? A not is missing from the sentence above. The quote above should have read: Specifically, the ctime and mtime time stamps do _not_ change when modifying the mapped memory and do not change when there have been no write references between the mmap() and msync() system calls. So essentially the problem is that mtime stamps are _never_ changed when the file is only modified through mmap. Not even when calling msync(). -- Kind regards, Klaus S. Madsen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
