Re: Linux 2.6.12-rc2
Its a T41 "without p" :) On Apr 8, 2005 9:09 PM, Nish Aravamudan <[EMAIL PROTECTED]> wrote: > On Apr 7, 2005 11:28 PM, AsterixTheGaul <[EMAIL PROTECTED]> wrote: > > > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, > > > except that neither returns from suspend-to-ram with video restored on > > > the LCD. I believe I was able to get video restored on an external CRT > > > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't > > > restore (can verify later today, if you'd like). I had dumped out the > > > radeontool regs values before & after the sleep, in case they help. > > > They are attached. > > > > Hmm... I have 2.6.12-rc2 on a T41 and "suspend to ram" works good (well > > except for a backtrace complaining about __might_sleep but otherwise ok). > > A T41 or a T41p? I believe they have different graphics cards... > > Thanks, > Nish > - 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: Linux 2.6.12-rc2
On Apr 7, 2005 11:28 PM, AsterixTheGaul <[EMAIL PROTECTED]> wrote: > > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, > > except that neither returns from suspend-to-ram with video restored on > > the LCD. I believe I was able to get video restored on an external CRT > > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't > > restore (can verify later today, if you'd like). I had dumped out the > > radeontool regs values before & after the sleep, in case they help. > > They are attached. > > Hmm... I have 2.6.12-rc2 on a T41 and "suspend to ram" works good (well > except for a backtrace complaining about __might_sleep but otherwise ok). A T41 or a T41p? I believe they have different graphics cards... Thanks, Nish - 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: Linux 2.6.12-rc2
Ok this time I did with radeontool and it works good :)) (2.6.12-rc2 on T41). 1. I have "radeontool regs" before susp to ram (presusp) 2. turn off LCD with "radeontool light off" 3. Suspend to RAM and wake up. (same backtrace) 4. LCD is back on (no problem) 5. regs in postsusp only diff is < RADEON_CRTC_GEN_CNTL=03200600 --- > RADEON_CRTC_GEN_CNTL=03000600 presusp --- RADEON_DAC_CNTL=ff002102 RADEON_DAC_CNTL2= RADEON_TV_DAC_CNTL=07680142 RADEON_DISP_OUTPUT_CNTL=1002 RADEON_CONFIG_MEMSIZE=0200 RADEON_AUX_SC_CNTL= RADEON_CRTC_EXT_CNTL=8048 RADEON_CRTC_GEN_CNTL=03200600 RADEON_CRTC2_GEN_CNTL=0080 RADEON_DEVICE_ID=4c66 RADEON_DISP_MISC_CNTL=5b300600 RADEON_GPIO_MONID= RADEON_GPIO_MONIDB=0300 RADEON_GPIO_CRT2_DDC=0300 RADEON_GPIO_DVI_DDC=0013 RADEON_GPIO_VGA_DDC=0003 RADEON_LVDS_GEN_CNTL=003dffa1 postsusp --- RADEON_DAC_CNTL=ff002102 RADEON_DAC_CNTL2= RADEON_TV_DAC_CNTL=07680142 RADEON_DISP_OUTPUT_CNTL=1002 RADEON_CONFIG_MEMSIZE=0200 RADEON_AUX_SC_CNTL= RADEON_CRTC_EXT_CNTL=8048 RADEON_CRTC_GEN_CNTL=03000600 RADEON_CRTC2_GEN_CNTL=0080 RADEON_DEVICE_ID=4c66 RADEON_DISP_MISC_CNTL=5b300600 RADEON_GPIO_MONID= RADEON_GPIO_MONIDB=0300 RADEON_GPIO_CRT2_DDC=0300 RADEON_GPIO_DVI_DDC=0013 RADEON_GPIO_VGA_DDC=0003 RADEON_LVDS_GEN_CNTL=003dffa1 On Apr 8, 2005 12:09 PM, AsterixTheGaul <[EMAIL PROTECTED]> wrote: > Err... never mind... I was not doing any radeon control. > > On Apr 8, 2005 11:58 AM, AsterixTheGaul <[EMAIL PROTECTED]> wrote: > > > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, > > > except that neither returns from suspend-to-ram with video restored on > > > the LCD. I believe I was able to get video restored on an external CRT > > > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't > > > restore (can verify later today, if you'd like). I had dumped out the > > > radeontool regs values before & after the sleep, in case they help. > > > They are attached. > > > > Hmm... I have 2.6.12-rc2 on a T41 and "suspend to ram" works good (well > > except for a backtrace complaining about __might_sleep but otherwise ok). > > > > Apr 7 23:17:10 localhost kernel: Debug: sleeping function called from > > invalid context at mm/slab.c:2090 > > Apr 7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1 > > Apr 7 23:17:10 localhost kernel: [] __might_sleep+0xa3/0xc0 > > Apr 7 23:17:10 localhost kernel: [] kmem_cache_alloc+0x50/0x60 > > Apr 7 23:17:10 localhost kernel: [] acpi_pci_link_set+0x4a/0x1a2 > > Apr 7 23:17:10 localhost kernel: [] irqrouter_resume+0x1c/0x24 > > Apr 7 23:17:10 localhost kernel: [] sysdev_resume+0x66/0xc4 > > Apr 7 23:17:10 localhost kernel: [] device_power_up+0x5/0xa > > Apr 7 23:17:10 localhost kernel: [] suspend_enter+0x36/0x60 > > Apr 7 23:17:10 localhost kernel: [] suspend_prepare+0x63/0xb0 > > Apr 7 23:17:10 localhost kernel: [] enter_state+0x5c/0x70 > > Apr 7 23:17:10 localhost kernel: [] state_store+0xa9/0xbc > > Apr 7 23:17:10 localhost kernel: [] state_store+0x0/0xbc > > Apr 7 23:17:10 localhost kernel: [] subsys_attr_store+0x36/0x50 > > Apr 7 23:17:10 localhost kernel: [] flush_write_buffer+0x2e/0x40 > > Apr 7 23:17:10 localhost kernel: [] sysfs_write_file+0x4e/0x80 > > Apr 7 23:17:10 localhost kernel: [] vfs_write+0x12e/0x130 > > Apr 7 23:17:10 localhost kernel: [] sys_write+0x41/0x70 > > Apr 7 23:17:10 localhost kernel: [] sysenter_past_esp+0x54/0x75 > > > > > > > > > > I posted these problems in the "Call for help S3" thread, but no one > > > responded. > > > > > > Thanks, > > > Nish > > > > > > > > > > > > - 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: Linux 2.6.12-rc2
Err... never mind... I was not doing any radeon control. On Apr 8, 2005 11:58 AM, AsterixTheGaul <[EMAIL PROTECTED]> wrote: > > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, > > except that neither returns from suspend-to-ram with video restored on > > the LCD. I believe I was able to get video restored on an external CRT > > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't > > restore (can verify later today, if you'd like). I had dumped out the > > radeontool regs values before & after the sleep, in case they help. > > They are attached. > > Hmm... I have 2.6.12-rc2 on a T41 and "suspend to ram" works good (well > except for a backtrace complaining about __might_sleep but otherwise ok). > > Apr 7 23:17:10 localhost kernel: Debug: sleeping function called from > invalid context at mm/slab.c:2090 > Apr 7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1 > Apr 7 23:17:10 localhost kernel: [] __might_sleep+0xa3/0xc0 > Apr 7 23:17:10 localhost kernel: [] kmem_cache_alloc+0x50/0x60 > Apr 7 23:17:10 localhost kernel: [] acpi_pci_link_set+0x4a/0x1a2 > Apr 7 23:17:10 localhost kernel: [] irqrouter_resume+0x1c/0x24 > Apr 7 23:17:10 localhost kernel: [] sysdev_resume+0x66/0xc4 > Apr 7 23:17:10 localhost kernel: [] device_power_up+0x5/0xa > Apr 7 23:17:10 localhost kernel: [] suspend_enter+0x36/0x60 > Apr 7 23:17:10 localhost kernel: [] suspend_prepare+0x63/0xb0 > Apr 7 23:17:10 localhost kernel: [] enter_state+0x5c/0x70 > Apr 7 23:17:10 localhost kernel: [] state_store+0xa9/0xbc > Apr 7 23:17:10 localhost kernel: [] state_store+0x0/0xbc > Apr 7 23:17:10 localhost kernel: [] subsys_attr_store+0x36/0x50 > Apr 7 23:17:10 localhost kernel: [] flush_write_buffer+0x2e/0x40 > Apr 7 23:17:10 localhost kernel: [] sysfs_write_file+0x4e/0x80 > Apr 7 23:17:10 localhost kernel: [] vfs_write+0x12e/0x130 > Apr 7 23:17:10 localhost kernel: [] sys_write+0x41/0x70 > Apr 7 23:17:10 localhost kernel: [] sysenter_past_esp+0x54/0x75 > > > > > > I posted these problems in the "Call for help S3" thread, but no one > > responded. > > > > Thanks, > > Nish > > > > > > > - 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: Linux 2.6.12-rc2
> FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, > except that neither returns from suspend-to-ram with video restored on > the LCD. I believe I was able to get video restored on an external CRT > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't > restore (can verify later today, if you'd like). I had dumped out the > radeontool regs values before & after the sleep, in case they help. > They are attached. Hmm... I have 2.6.12-rc2 on a T41 and "suspend to ram" works good (well except for a backtrace complaining about __might_sleep but otherwise ok). Apr 7 23:17:10 localhost kernel: Debug: sleeping function called from invalid context at mm/slab.c:2090 Apr 7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1 Apr 7 23:17:10 localhost kernel: [] __might_sleep+0xa3/0xc0 Apr 7 23:17:10 localhost kernel: [] kmem_cache_alloc+0x50/0x60 Apr 7 23:17:10 localhost kernel: [] acpi_pci_link_set+0x4a/0x1a2 Apr 7 23:17:10 localhost kernel: [] irqrouter_resume+0x1c/0x24 Apr 7 23:17:10 localhost kernel: [] sysdev_resume+0x66/0xc4 Apr 7 23:17:10 localhost kernel: [] device_power_up+0x5/0xa Apr 7 23:17:10 localhost kernel: [] suspend_enter+0x36/0x60 Apr 7 23:17:10 localhost kernel: [] suspend_prepare+0x63/0xb0 Apr 7 23:17:10 localhost kernel: [] enter_state+0x5c/0x70 Apr 7 23:17:10 localhost kernel: [] state_store+0xa9/0xbc Apr 7 23:17:10 localhost kernel: [] state_store+0x0/0xbc Apr 7 23:17:10 localhost kernel: [] subsys_attr_store+0x36/0x50 Apr 7 23:17:10 localhost kernel: [] flush_write_buffer+0x2e/0x40 Apr 7 23:17:10 localhost kernel: [] sysfs_write_file+0x4e/0x80 Apr 7 23:17:10 localhost kernel: [] vfs_write+0x12e/0x130 Apr 7 23:17:10 localhost kernel: [] sys_write+0x41/0x70 Apr 7 23:17:10 localhost kernel: [] sysenter_past_esp+0x54/0x75 > > I posted these problems in the "Call for help S3" thread, but no one > responded. > > Thanks, > Nish > > > - 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: Linux 2.6.12-rc2
FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before after the sleep, in case they help. They are attached. Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well except for a backtrace complaining about __might_sleep but otherwise ok). Apr 7 23:17:10 localhost kernel: Debug: sleeping function called from invalid context at mm/slab.c:2090 Apr 7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1 Apr 7 23:17:10 localhost kernel: [c011d9e3] __might_sleep+0xa3/0xc0 Apr 7 23:17:10 localhost kernel: [c015beb0] kmem_cache_alloc+0x50/0x60 Apr 7 23:17:10 localhost kernel: [c0269750] acpi_pci_link_set+0x4a/0x1a2 Apr 7 23:17:10 localhost kernel: [c0269bc9] irqrouter_resume+0x1c/0x24 Apr 7 23:17:10 localhost kernel: [c02b70f6] sysdev_resume+0x66/0xc4 Apr 7 23:17:10 localhost kernel: [c02bbcc5] device_power_up+0x5/0xa Apr 7 23:17:10 localhost kernel: [c014a426] suspend_enter+0x36/0x60 Apr 7 23:17:10 localhost kernel: [c014a3a3] suspend_prepare+0x63/0xb0 Apr 7 23:17:10 localhost kernel: [c014a4ec] enter_state+0x5c/0x70 Apr 7 23:17:10 localhost kernel: [c014a639] state_store+0xa9/0xbc Apr 7 23:17:10 localhost kernel: [c014a590] state_store+0x0/0xbc Apr 7 23:17:10 localhost kernel: [c01d27c6] subsys_attr_store+0x36/0x50 Apr 7 23:17:10 localhost kernel: [c01d2a6e] flush_write_buffer+0x2e/0x40 Apr 7 23:17:10 localhost kernel: [c01d2ace] sysfs_write_file+0x4e/0x80 Apr 7 23:17:10 localhost kernel: [c017bdee] vfs_write+0x12e/0x130 Apr 7 23:17:10 localhost kernel: [c017bea1] sys_write+0x41/0x70 Apr 7 23:17:10 localhost kernel: [c01039ff] sysenter_past_esp+0x54/0x75 I posted these problems in the Call for help S3 thread, but no one responded. Thanks, Nish - 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: Linux 2.6.12-rc2
Err... never mind... I was not doing any radeon control. On Apr 8, 2005 11:58 AM, AsterixTheGaul [EMAIL PROTECTED] wrote: FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before after the sleep, in case they help. They are attached. Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well except for a backtrace complaining about __might_sleep but otherwise ok). Apr 7 23:17:10 localhost kernel: Debug: sleeping function called from invalid context at mm/slab.c:2090 Apr 7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1 Apr 7 23:17:10 localhost kernel: [c011d9e3] __might_sleep+0xa3/0xc0 Apr 7 23:17:10 localhost kernel: [c015beb0] kmem_cache_alloc+0x50/0x60 Apr 7 23:17:10 localhost kernel: [c0269750] acpi_pci_link_set+0x4a/0x1a2 Apr 7 23:17:10 localhost kernel: [c0269bc9] irqrouter_resume+0x1c/0x24 Apr 7 23:17:10 localhost kernel: [c02b70f6] sysdev_resume+0x66/0xc4 Apr 7 23:17:10 localhost kernel: [c02bbcc5] device_power_up+0x5/0xa Apr 7 23:17:10 localhost kernel: [c014a426] suspend_enter+0x36/0x60 Apr 7 23:17:10 localhost kernel: [c014a3a3] suspend_prepare+0x63/0xb0 Apr 7 23:17:10 localhost kernel: [c014a4ec] enter_state+0x5c/0x70 Apr 7 23:17:10 localhost kernel: [c014a639] state_store+0xa9/0xbc Apr 7 23:17:10 localhost kernel: [c014a590] state_store+0x0/0xbc Apr 7 23:17:10 localhost kernel: [c01d27c6] subsys_attr_store+0x36/0x50 Apr 7 23:17:10 localhost kernel: [c01d2a6e] flush_write_buffer+0x2e/0x40 Apr 7 23:17:10 localhost kernel: [c01d2ace] sysfs_write_file+0x4e/0x80 Apr 7 23:17:10 localhost kernel: [c017bdee] vfs_write+0x12e/0x130 Apr 7 23:17:10 localhost kernel: [c017bea1] sys_write+0x41/0x70 Apr 7 23:17:10 localhost kernel: [c01039ff] sysenter_past_esp+0x54/0x75 I posted these problems in the Call for help S3 thread, but no one responded. Thanks, Nish - 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: Linux 2.6.12-rc2
Ok this time I did with radeontool and it works good :)) (2.6.12-rc2 on T41). 1. I have radeontool regs before susp to ram (presusp) 2. turn off LCD with radeontool light off 3. Suspend to RAM and wake up. (same backtrace) 4. LCD is back on (no problem) 5. regs in postsusp only diff is RADEON_CRTC_GEN_CNTL=03200600 --- RADEON_CRTC_GEN_CNTL=03000600 presusp --- RADEON_DAC_CNTL=ff002102 RADEON_DAC_CNTL2= RADEON_TV_DAC_CNTL=07680142 RADEON_DISP_OUTPUT_CNTL=1002 RADEON_CONFIG_MEMSIZE=0200 RADEON_AUX_SC_CNTL= RADEON_CRTC_EXT_CNTL=8048 RADEON_CRTC_GEN_CNTL=03200600 RADEON_CRTC2_GEN_CNTL=0080 RADEON_DEVICE_ID=4c66 RADEON_DISP_MISC_CNTL=5b300600 RADEON_GPIO_MONID= RADEON_GPIO_MONIDB=0300 RADEON_GPIO_CRT2_DDC=0300 RADEON_GPIO_DVI_DDC=0013 RADEON_GPIO_VGA_DDC=0003 RADEON_LVDS_GEN_CNTL=003dffa1 postsusp --- RADEON_DAC_CNTL=ff002102 RADEON_DAC_CNTL2= RADEON_TV_DAC_CNTL=07680142 RADEON_DISP_OUTPUT_CNTL=1002 RADEON_CONFIG_MEMSIZE=0200 RADEON_AUX_SC_CNTL= RADEON_CRTC_EXT_CNTL=8048 RADEON_CRTC_GEN_CNTL=03000600 RADEON_CRTC2_GEN_CNTL=0080 RADEON_DEVICE_ID=4c66 RADEON_DISP_MISC_CNTL=5b300600 RADEON_GPIO_MONID= RADEON_GPIO_MONIDB=0300 RADEON_GPIO_CRT2_DDC=0300 RADEON_GPIO_DVI_DDC=0013 RADEON_GPIO_VGA_DDC=0003 RADEON_LVDS_GEN_CNTL=003dffa1 On Apr 8, 2005 12:09 PM, AsterixTheGaul [EMAIL PROTECTED] wrote: Err... never mind... I was not doing any radeon control. On Apr 8, 2005 11:58 AM, AsterixTheGaul [EMAIL PROTECTED] wrote: FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before after the sleep, in case they help. They are attached. Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well except for a backtrace complaining about __might_sleep but otherwise ok). Apr 7 23:17:10 localhost kernel: Debug: sleeping function called from invalid context at mm/slab.c:2090 Apr 7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1 Apr 7 23:17:10 localhost kernel: [c011d9e3] __might_sleep+0xa3/0xc0 Apr 7 23:17:10 localhost kernel: [c015beb0] kmem_cache_alloc+0x50/0x60 Apr 7 23:17:10 localhost kernel: [c0269750] acpi_pci_link_set+0x4a/0x1a2 Apr 7 23:17:10 localhost kernel: [c0269bc9] irqrouter_resume+0x1c/0x24 Apr 7 23:17:10 localhost kernel: [c02b70f6] sysdev_resume+0x66/0xc4 Apr 7 23:17:10 localhost kernel: [c02bbcc5] device_power_up+0x5/0xa Apr 7 23:17:10 localhost kernel: [c014a426] suspend_enter+0x36/0x60 Apr 7 23:17:10 localhost kernel: [c014a3a3] suspend_prepare+0x63/0xb0 Apr 7 23:17:10 localhost kernel: [c014a4ec] enter_state+0x5c/0x70 Apr 7 23:17:10 localhost kernel: [c014a639] state_store+0xa9/0xbc Apr 7 23:17:10 localhost kernel: [c014a590] state_store+0x0/0xbc Apr 7 23:17:10 localhost kernel: [c01d27c6] subsys_attr_store+0x36/0x50 Apr 7 23:17:10 localhost kernel: [c01d2a6e] flush_write_buffer+0x2e/0x40 Apr 7 23:17:10 localhost kernel: [c01d2ace] sysfs_write_file+0x4e/0x80 Apr 7 23:17:10 localhost kernel: [c017bdee] vfs_write+0x12e/0x130 Apr 7 23:17:10 localhost kernel: [c017bea1] sys_write+0x41/0x70 Apr 7 23:17:10 localhost kernel: [c01039ff] sysenter_past_esp+0x54/0x75 I posted these problems in the Call for help S3 thread, but no one responded. Thanks, Nish - 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: Linux 2.6.12-rc2
On Apr 7, 2005 11:28 PM, AsterixTheGaul [EMAIL PROTECTED] wrote: FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before after the sleep, in case they help. They are attached. Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well except for a backtrace complaining about __might_sleep but otherwise ok). A T41 or a T41p? I believe they have different graphics cards... Thanks, Nish - 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: Linux 2.6.12-rc2
Its a T41 without p :) On Apr 8, 2005 9:09 PM, Nish Aravamudan [EMAIL PROTECTED] wrote: On Apr 7, 2005 11:28 PM, AsterixTheGaul [EMAIL PROTECTED] wrote: FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before after the sleep, in case they help. They are attached. Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well except for a backtrace complaining about __might_sleep but otherwise ok). A T41 or a T41p? I believe they have different graphics cards... Thanks, Nish - 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: Linux 2.6.12-rc2
On Apr 7, 2005 3:45 PM, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote: > > On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote: > > > Benjamin Herrenschmidt wrote: > > > > > 1. When resuming from S3 suspend and having switched off the backlight > > > > > with radeontool the backlight isn't switched back on any more. > > > > > > > > I'm not sure what's up here, it's a nasty issue with backlight. Can > > > > radeontool bring it back ? > > > > > > Before suspending I power down the backlight with "radeontool light off" > > > and with 2.6.11 the display is properly restored. With 2.6.12rc2 the > > > backlight remains switched off and if I switch it on with radeontool it > > > becomes lighter, but there's still no text from the fbcon, just the blank > > > screen. > > > > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, > > except that neither returns from suspend-to-ram with video restored on > > the LCD. I believe I was able to get video restored on an external CRT > > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't > > restore (can verify later today, if you'd like). I had dumped out the > > radeontool regs values before & after the sleep, in case they help. > > They are attached. > > > > I posted these problems in the "Call for help S3" thread, but no one > > responded. > > I would say the different value in LVDS_GEN_CNTL explains it. I'll see > if I can force radeonfb to save/restore this. Great! That seemed odd to me, as well. I'll be more than happy to try any patches (I'll take a look at the code tonight myself). Thanks, Nish - 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: Linux 2.6.12-rc2
On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote: > On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote: > > Benjamin Herrenschmidt wrote: > > > > 1. When resuming from S3 suspend and having switched off the backlight > > > > with radeontool the backlight isn't switched back on any more. > > > > > > I'm not sure what's up here, it's a nasty issue with backlight. Can > > > radeontool bring it back ? > > > > Before suspending I power down the backlight with "radeontool light off" > > and with 2.6.11 the display is properly restored. With 2.6.12rc2 the > > backlight remains switched off and if I switch it on with radeontool it > > becomes lighter, but there's still no text from the fbcon, just the blank > > screen. > > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, > except that neither returns from suspend-to-ram with video restored on > the LCD. I believe I was able to get video restored on an external CRT > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't > restore (can verify later today, if you'd like). I had dumped out the > radeontool regs values before & after the sleep, in case they help. > They are attached. > > I posted these problems in the "Call for help S3" thread, but no one > responded. I would say the different value in LVDS_GEN_CNTL explains it. I'll see if I can force radeonfb to save/restore this. Ben. - 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: Linux 2.6.12-rc2
On Thu, 2005-04-07 at 19:50 +0200, Moritz Muehlenhoff wrote: > Benjamin Herrenschmidt wrote: > > > 1. When resuming from S3 suspend and having switched off the backlight > > > with radeontool the backlight isn't switched back on any more. > > > > I'm not sure what's up here, it's a nasty issue with backlight. Can > > radeontool bring it back ? > > Before suspending I power down the backlight with "radeontool light off" > and with 2.6.11 the display is properly restored. With 2.6.12rc2 the > backlight remains switched off and if I switch it on with radeontool it > becomes lighter, but there's still no text from the fbcon, just the blank > screen. > > > > 2. I'm using fbcon as my primary work environment, but tty switching has > > > become _very_ sloppy, it's at least a second now, while with 2.6.11 it > > > was as fast as a few ms. Is this caused by the "proper PLL accesses"? > > > > Yes. Unfortunately. It's surprised it is that slow though, there > > shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with > > 5ms pause for each, that should still be very reasonable. It looks like > > we are doing a lot more accesses which I don't completely understand. > > Can you tell me which function you have in mind, so that I can insert > some printks to see how often it's called? radeon_pll_errata_after_data() calls radeon_msleep() (it's in radeonfb.h) Ben. - 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: Linux 2.6.12-rc2
On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote: > Benjamin Herrenschmidt wrote: > > > 1. When resuming from S3 suspend and having switched off the backlight > > > with radeontool the backlight isn't switched back on any more. > > > > I'm not sure what's up here, it's a nasty issue with backlight. Can > > radeontool bring it back ? > > Before suspending I power down the backlight with "radeontool light off" > and with 2.6.11 the display is properly restored. With 2.6.12rc2 the > backlight remains switched off and if I switch it on with radeontool it > becomes lighter, but there's still no text from the fbcon, just the blank > screen. FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before & after the sleep, in case they help. They are attached. I posted these problems in the "Call for help S3" thread, but no one responded. Thanks, Nish radeontool_pre Description: Binary data radeontool_post Description: Binary data
Re: Linux 2.6.12-rc2
Benjamin Herrenschmidt wrote: > > 1. When resuming from S3 suspend and having switched off the backlight > > with radeontool the backlight isn't switched back on any more. > > I'm not sure what's up here, it's a nasty issue with backlight. Can > radeontool bring it back ? Before suspending I power down the backlight with "radeontool light off" and with 2.6.11 the display is properly restored. With 2.6.12rc2 the backlight remains switched off and if I switch it on with radeontool it becomes lighter, but there's still no text from the fbcon, just the blank screen. > > 2. I'm using fbcon as my primary work environment, but tty switching has > > become _very_ sloppy, it's at least a second now, while with 2.6.11 it > > was as fast as a few ms. Is this caused by the "proper PLL accesses"? > > Yes. Unfortunately. It's surprised it is that slow though, there > shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with > 5ms pause for each, that should still be very reasonable. It looks like > we are doing a lot more accesses which I don't completely understand. Can you tell me which function you have in mind, so that I can insert some printks to see how often it's called? Cheers, Moritz - 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: Linux 2.6.12-rc2
Benjamin Herrenschmidt wrote: 1. When resuming from S3 suspend and having switched off the backlight with radeontool the backlight isn't switched back on any more. I'm not sure what's up here, it's a nasty issue with backlight. Can radeontool bring it back ? Before suspending I power down the backlight with radeontool light off and with 2.6.11 the display is properly restored. With 2.6.12rc2 the backlight remains switched off and if I switch it on with radeontool it becomes lighter, but there's still no text from the fbcon, just the blank screen. 2. I'm using fbcon as my primary work environment, but tty switching has become _very_ sloppy, it's at least a second now, while with 2.6.11 it was as fast as a few ms. Is this caused by the proper PLL accesses? Yes. Unfortunately. It's surprised it is that slow though, there shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with 5ms pause for each, that should still be very reasonable. It looks like we are doing a lot more accesses which I don't completely understand. Can you tell me which function you have in mind, so that I can insert some printks to see how often it's called? Cheers, Moritz - 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: Linux 2.6.12-rc2
On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff [EMAIL PROTECTED] wrote: Benjamin Herrenschmidt wrote: 1. When resuming from S3 suspend and having switched off the backlight with radeontool the backlight isn't switched back on any more. I'm not sure what's up here, it's a nasty issue with backlight. Can radeontool bring it back ? Before suspending I power down the backlight with radeontool light off and with 2.6.11 the display is properly restored. With 2.6.12rc2 the backlight remains switched off and if I switch it on with radeontool it becomes lighter, but there's still no text from the fbcon, just the blank screen. FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before after the sleep, in case they help. They are attached. I posted these problems in the Call for help S3 thread, but no one responded. Thanks, Nish radeontool_pre Description: Binary data radeontool_post Description: Binary data
Re: Linux 2.6.12-rc2
On Thu, 2005-04-07 at 19:50 +0200, Moritz Muehlenhoff wrote: Benjamin Herrenschmidt wrote: 1. When resuming from S3 suspend and having switched off the backlight with radeontool the backlight isn't switched back on any more. I'm not sure what's up here, it's a nasty issue with backlight. Can radeontool bring it back ? Before suspending I power down the backlight with radeontool light off and with 2.6.11 the display is properly restored. With 2.6.12rc2 the backlight remains switched off and if I switch it on with radeontool it becomes lighter, but there's still no text from the fbcon, just the blank screen. 2. I'm using fbcon as my primary work environment, but tty switching has become _very_ sloppy, it's at least a second now, while with 2.6.11 it was as fast as a few ms. Is this caused by the proper PLL accesses? Yes. Unfortunately. It's surprised it is that slow though, there shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with 5ms pause for each, that should still be very reasonable. It looks like we are doing a lot more accesses which I don't completely understand. Can you tell me which function you have in mind, so that I can insert some printks to see how often it's called? radeon_pll_errata_after_data() calls radeon_msleep() (it's in radeonfb.h) Ben. - 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: Linux 2.6.12-rc2
On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote: On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff [EMAIL PROTECTED] wrote: Benjamin Herrenschmidt wrote: 1. When resuming from S3 suspend and having switched off the backlight with radeontool the backlight isn't switched back on any more. I'm not sure what's up here, it's a nasty issue with backlight. Can radeontool bring it back ? Before suspending I power down the backlight with radeontool light off and with 2.6.11 the display is properly restored. With 2.6.12rc2 the backlight remains switched off and if I switch it on with radeontool it becomes lighter, but there's still no text from the fbcon, just the blank screen. FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before after the sleep, in case they help. They are attached. I posted these problems in the Call for help S3 thread, but no one responded. I would say the different value in LVDS_GEN_CNTL explains it. I'll see if I can force radeonfb to save/restore this. Ben. - 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: Linux 2.6.12-rc2
On Apr 7, 2005 3:45 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote: On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff [EMAIL PROTECTED] wrote: Benjamin Herrenschmidt wrote: 1. When resuming from S3 suspend and having switched off the backlight with radeontool the backlight isn't switched back on any more. I'm not sure what's up here, it's a nasty issue with backlight. Can radeontool bring it back ? Before suspending I power down the backlight with radeontool light off and with 2.6.11 the display is properly restored. With 2.6.12rc2 the backlight remains switched off and if I switch it on with radeontool it becomes lighter, but there's still no text from the fbcon, just the blank screen. FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, except that neither returns from suspend-to-ram with video restored on the LCD. I believe I was able to get video restored on an external CRT in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't restore (can verify later today, if you'd like). I had dumped out the radeontool regs values before after the sleep, in case they help. They are attached. I posted these problems in the Call for help S3 thread, but no one responded. I would say the different value in LVDS_GEN_CNTL explains it. I'll see if I can force radeonfb to save/restore this. Great! That seemed odd to me, as well. I'll be more than happy to try any patches (I'll take a look at the code tonight myself). Thanks, Nish - 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: Linux 2.6.12-rc2
On Wed, Apr 06, 2005 at 05:20:52PM -0600, Bob Gill wrote: > OK. So far so good. I can get 2.6.12-rc2 to run fine if: > 1. I do not in any way attempt to *ahem* overclock the box. > --if I do, I get really ugly race errors flying around from just about > everywhere (pick a device at random, have it trip, and the scheduler > tripping right behind it). "Doctor it hurts when I do this.." > 2. I do not attempt in any way to run any sort of Nvidia (non-GPL) > driver. Totally unsurprising. They'll need serious brain surgery to work with the multi-gart support. I'm amazed they even compiled for you. Dave - 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: Linux 2.6.12-rc2
OK. So far so good. I can get 2.6.12-rc2 to run fine if: 1. I do not in any way attempt to *ahem* overclock the box. --if I do, I get really ugly race errors flying around from just about everywhere (pick a device at random, have it trip, and the scheduler tripping right behind it). 2. I do not attempt in any way to run any sort of Nvidia (non-GPL) driver. It fights with SBP2 (in a lot of different ways, first the drivers want to kill off Firewire drives (one detected, the other not, then on next boot, the reverse...), and also, when using GLX apps (and trying to write to an SBP2 connected device, they clash (and fight and the kernel doesn't die but gets bogged in errors...) and with the notes above, as I say, so far, so good. I am attempting to hammer away at every device I have on the box (scanner, printer, video (only GPL Nvidia), audio, cd, dvd, tv tuner etc.) so far, so good. Bob -- Bob Gill <[EMAIL PROTECTED]> - 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: Linux 2.6.12-rc2
On Wed, 2005-04-06 at 19:14 +0200, Moritz Muehlenhoff wrote: > Linus Torvalds wrote: > > Benjamin Herrenschmidt: > > o radeonfb: Implement proper workarounds for PLL accesses > > o radeonfb: DDC i2c fix > > o radeonfb: Fix mode setting on CRT monitors > > o radeonfb: Preserve TMDS setting > > One of these patches introduced two regressions on my Thinkpad X31 with > "ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA])": > > 1. When resuming from S3 suspend and having switched off the backlight > with radeontool the backlight isn't switched back on any more. I'm not sure what's up here, it's a nasty issue with backlight. Can radeontool bring it back ? > 2. I'm using fbcon as my primary work environment, but tty switching has > become _very_ sloppy, it's at least a second now, while with 2.6.11 it > was as fast as a few ms. Is this caused by the "proper PLL accesses"? Yes. Unfortunately. It's surprised it is that slow though, there shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with 5ms pause for each, that should still be very reasonable. It looks like we are doing a lot more accesses which I don't completely understand. Ben. - 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: Linux 2.6.12-rc2
Linus Torvalds wrote: > Benjamin Herrenschmidt: > o radeonfb: Implement proper workarounds for PLL accesses > o radeonfb: DDC i2c fix > o radeonfb: Fix mode setting on CRT monitors > o radeonfb: Preserve TMDS setting One of these patches introduced two regressions on my Thinkpad X31 with "ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA])": 1. When resuming from S3 suspend and having switched off the backlight with radeontool the backlight isn't switched back on any more. 2. I'm using fbcon as my primary work environment, but tty switching has become _very_ sloppy, it's at least a second now, while with 2.6.11 it was as fast as a few ms. Is this caused by the "proper PLL accesses"? Cheers, Moritz - 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: Linux 2.6.12-rc2
Linus Torvalds wrote: Benjamin Herrenschmidt: o radeonfb: Implement proper workarounds for PLL accesses o radeonfb: DDC i2c fix o radeonfb: Fix mode setting on CRT monitors o radeonfb: Preserve TMDS setting One of these patches introduced two regressions on my Thinkpad X31 with ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA]): 1. When resuming from S3 suspend and having switched off the backlight with radeontool the backlight isn't switched back on any more. 2. I'm using fbcon as my primary work environment, but tty switching has become _very_ sloppy, it's at least a second now, while with 2.6.11 it was as fast as a few ms. Is this caused by the proper PLL accesses? Cheers, Moritz - 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: Linux 2.6.12-rc2
On Wed, 2005-04-06 at 19:14 +0200, Moritz Muehlenhoff wrote: Linus Torvalds wrote: Benjamin Herrenschmidt: o radeonfb: Implement proper workarounds for PLL accesses o radeonfb: DDC i2c fix o radeonfb: Fix mode setting on CRT monitors o radeonfb: Preserve TMDS setting One of these patches introduced two regressions on my Thinkpad X31 with ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA]): 1. When resuming from S3 suspend and having switched off the backlight with radeontool the backlight isn't switched back on any more. I'm not sure what's up here, it's a nasty issue with backlight. Can radeontool bring it back ? 2. I'm using fbcon as my primary work environment, but tty switching has become _very_ sloppy, it's at least a second now, while with 2.6.11 it was as fast as a few ms. Is this caused by the proper PLL accesses? Yes. Unfortunately. It's surprised it is that slow though, there shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with 5ms pause for each, that should still be very reasonable. It looks like we are doing a lot more accesses which I don't completely understand. Ben. - 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: Linux 2.6.12-rc2
OK. So far so good. I can get 2.6.12-rc2 to run fine if: 1. I do not in any way attempt to *ahem* overclock the box. --if I do, I get really ugly race errors flying around from just about everywhere (pick a device at random, have it trip, and the scheduler tripping right behind it). 2. I do not attempt in any way to run any sort of Nvidia (non-GPL) driver. It fights with SBP2 (in a lot of different ways, first the drivers want to kill off Firewire drives (one detected, the other not, then on next boot, the reverse...), and also, when using GLX apps (and trying to write to an SBP2 connected device, they clash (and fight and the kernel doesn't die but gets bogged in errors...) and with the notes above, as I say, so far, so good. I am attempting to hammer away at every device I have on the box (scanner, printer, video (only GPL Nvidia), audio, cd, dvd, tv tuner etc.) so far, so good. Bob -- Bob Gill [EMAIL PROTECTED] - 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: Linux 2.6.12-rc2
On Wed, Apr 06, 2005 at 05:20:52PM -0600, Bob Gill wrote: OK. So far so good. I can get 2.6.12-rc2 to run fine if: 1. I do not in any way attempt to *ahem* overclock the box. --if I do, I get really ugly race errors flying around from just about everywhere (pick a device at random, have it trip, and the scheduler tripping right behind it). Doctor it hurts when I do this.. 2. I do not attempt in any way to run any sort of Nvidia (non-GPL) driver. Totally unsurprising. They'll need serious brain surgery to work with the multi-gart support. I'm amazed they even compiled for you. Dave - 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: Linux 2.6.12-rc2
2.6.12-rc2 still does not boot properly on my box. Hubert Tonneau wrote: > > When switching from 2.6.11 to 2.6.12-rc1, > I get a 'cannot open root device' fatal error at end of kernel boot process. > Root device is 'hda1'. > > Hardware content of the box: > > 8086 Intel Corporation 334082855PM 0 > Host-Hub Interface Bridge > 8086 Intel Corporation 334182855PM 0 AGP > Bridge > 8086 Intel Corporation 24C282801DB/DBL/DBM B > USB UHCI Controller #1 > 8086 Intel Corporation 24C482801DB/DBL/DBM B > USB UHCI Controller #2 > 8086 Intel Corporation 24C782801DB/DBL/DBM B > USB UHCI Controller #3 > 8086 Intel Corporation 24CD82801DB/DBL/DBM B > USB EHCI Controller > 8086 Intel Corporation 244882801BAM/CAM/DBM0 > Hub Interface to PCI Bridge > 8086 Intel Corporation 24CC82801DBM0 LPC > Interface Bridge > 8086 Intel Corporation 24CA82801DBMB IDE > Controller (UltraATA/100) > 8086 Intel Corporation 24C582801DB/DBL/DBM B > AC97 Audio Controller > 8086 Intel Corporation 24C682801DB/DBM B AC97 > Modem Controller > 10DE NVIDIA Corporation 0324NV31B NVIDIA NV31GL > 14E4 Broadcom Corporation165DBCM5705MB > Broadcom NetXtreme Gigabit Ethernet > 104C Texas Instruments AC477510/4510 B Cardbus > 104C Texas Instruments AC4AB > 104C Texas Instruments 802BB > 104C Texas Instruments 82044610, 4515, 4610FM 0 > TI UltraMedia Firmware Loader Device > 8086 Intel Corporation 4220MPCI3B B Intel 2200 mPCI > 3B - RoW > > 2.6.11 kernel report: > > <4>Linux version 2.6.11 ([EMAIL PROTECTED]) (gcc version 3.3 (Debian)) #1 Sun > Mar 6 12:00:57 CET 2005 > <6>BIOS-provided physical RAM map: > <4> BIOS-e820: - 0009f000 (usable) > <4> BIOS-e820: 0009f000 - 000a (reserved) > <4> BIOS-e820: 0010 - 3ffae000 (usable) > <4> BIOS-e820: 3ffae000 - 4000 (reserved) > <4> BIOS-e820: feda - fee0 (reserved) > <4> BIOS-e820: ffb0 - 0001 (reserved) > <4>Warning only 896MB will be used. > <4>Use a HIGHMEM enabled kernel. > <5>896MB LOWMEM available. > <7>On node 0 totalpages: 229376 > <7> DMA zone: 4096 pages, LIFO batch:1 > <7> Normal zone: 225280 pages, LIFO batch:16 > <7> HighMem zone: 0 pages, LIFO batch:1 > <6>DMI 2.3 present. > <7>ACPI: RSDP (v000 DELL ) @ 0x000fdf00 > <7>ACPI: RSDT (v001 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff > <7>ACPI: FADT (v001 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff0400 > <7>ACPI: ASF! (v016 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff0800 > <7>ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 MSFT 0x010e) @ 0x > <4>Allocating PCI resources starting at 4000 (gap: 4000:beda) > <4>Built 1 zonelists > <4>Kernel command line: BOOT_IMAGE=recover ro root=301 > <4>Local APIC disabled by BIOS -- you can enable it with "lapic" > <7>mapped APIC to d000 (01703000) > <6>Initializing CPU#0 > <4>PID hash table entries: 4096 (order: 12, 65536 bytes) > <4>Detected 1998.546 MHz processor. > <6>Using tsc for high-res timesource > <4>Console: colour VGA+ 80x25 > <4>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > <4>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > <6>Memory: 906620k/917504k available (1598k kernel code, 10432k reserved, > 518k data, 140k init, 0k highmem) > <4>Checking if this processor honours the WP bit even in supervisor mode... > Ok. > <7>Calibrating delay loop... 3956.73 BogoMIPS (lpj=1978368) > <4>Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > <7>CPU: After generic identify, caps: afe9f9bf > 0180 > <7>CPU: After vendor identify, caps: afe9f9bf > 0180 > <6>CPU: L1 I cache: 32K, L1 D cache: 32K > <6>CPU: L2 cache: 2048K > <7>CPU: After all inits, caps: afe9f9bf 0040 0180 > > <6>Intel machine check architecture supported. > <6>Intel machine check reporting enabled on CPU#0. > <4>CPU: Intel(R) Pentium(R) M processor 2.00GHz stepping 06 > <6>Enabling fast FPU save and restore... done. > <6>Enabling unmasked SIMD FPU exception support... done. > <6>Checking 'hlt' instruction... OK. > <4>ACPI: setting ELCR to 0200 (from 0800) > <6>NET: Registered protocol family 16 > <6>PCI: PCI BIOS revision 2.10 entry at 0xfc96e, last bus=2 > <6>PCI: Using
Re: Linux 2.6.12-rc2
Oleg Nesterov <[EMAIL PROTECTED]> wrote: > > > Oleg Nesterov: > > o x86: fix ESP corruption CPU bug (take 2) > > I don't even absolutely understand what this patch does :) > I only send a very minor fix on top of Stas Sergeev's patch. > I'm suspecting a problem in the reporting scripts. The patch had: From: Stas Sergeev <[EMAIL PROTECTED]> Attached patch works around the corruption of the high word of the ESP register, which is the official bug of x86 CPUs. The bug triggers only when the one is using the 16bit stack segment, and is described here: http://www.intel.com/design/intarch/specupdt/27287402.PDF From: Oleg Nesterov <[EMAIL PROTECTED]> I think that Stas tries to steal 1024 bytes from kernel's memory. Acked-by: Linus Torvalds <[EMAIL PROTECTED]> Acked-by: Petr Vandrovec <[EMAIL PROTECTED]> Acked-by: Pavel Machek <[EMAIL PROTECTED]> Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> It looks like the final From: was used... - 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: Linux 2.6.12-rc2
> Oleg Nesterov: > o x86: fix ESP corruption CPU bug (take 2) I don't even absolutely understand what this patch does :) I only send a very minor fix on top of Stas Sergeev's patch. Oleg. - 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: Linux 2.6.12-rc2
Oleg Nesterov: o x86: fix ESP corruption CPU bug (take 2) I don't even absolutely understand what this patch does :) I only send a very minor fix on top of Stas Sergeev's patch. Oleg. - 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: Linux 2.6.12-rc2
Oleg Nesterov [EMAIL PROTECTED] wrote: Oleg Nesterov: o x86: fix ESP corruption CPU bug (take 2) I don't even absolutely understand what this patch does :) I only send a very minor fix on top of Stas Sergeev's patch. I'm suspecting a problem in the reporting scripts. The patch had: From: Stas Sergeev [EMAIL PROTECTED] Attached patch works around the corruption of the high word of the ESP register, which is the official bug of x86 CPUs. The bug triggers only when the one is using the 16bit stack segment, and is described here: http://www.intel.com/design/intarch/specupdt/27287402.PDF From: Oleg Nesterov [EMAIL PROTECTED] I think that Stas tries to steal 1024 bytes from kernel's memory. Acked-by: Linus Torvalds [EMAIL PROTECTED] Acked-by: Petr Vandrovec [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Signed-off-by: Stas Sergeev [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] It looks like the final From: was used... - 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: Linux 2.6.12-rc2
2.6.12-rc2 still does not boot properly on my box. Hubert Tonneau wrote: When switching from 2.6.11 to 2.6.12-rc1, I get a 'cannot open root device' fatal error at end of kernel boot process. Root device is 'hda1'. Hardware content of the box: 8086 Intel Corporation 334082855PM 0 Host-Hub Interface Bridge 8086 Intel Corporation 334182855PM 0 AGP Bridge 8086 Intel Corporation 24C282801DB/DBL/DBM B USB UHCI Controller #1 8086 Intel Corporation 24C482801DB/DBL/DBM B USB UHCI Controller #2 8086 Intel Corporation 24C782801DB/DBL/DBM B USB UHCI Controller #3 8086 Intel Corporation 24CD82801DB/DBL/DBM B USB EHCI Controller 8086 Intel Corporation 244882801BAM/CAM/DBM0 Hub Interface to PCI Bridge 8086 Intel Corporation 24CC82801DBM0 LPC Interface Bridge 8086 Intel Corporation 24CA82801DBMB IDE Controller (UltraATA/100) 8086 Intel Corporation 24C582801DB/DBL/DBM B AC97 Audio Controller 8086 Intel Corporation 24C682801DB/DBM B AC97 Modem Controller 10DE NVIDIA Corporation 0324NV31B NVIDIA NV31GL 14E4 Broadcom Corporation165DBCM5705MB Broadcom NetXtreme Gigabit Ethernet 104C Texas Instruments AC477510/4510 B Cardbus 104C Texas Instruments AC4AB 104C Texas Instruments 802BB 104C Texas Instruments 82044610, 4515, 4610FM 0 TI UltraMedia Firmware Loader Device 8086 Intel Corporation 4220MPCI3B B Intel 2200 mPCI 3B - RoW 2.6.11 kernel report: 4Linux version 2.6.11 ([EMAIL PROTECTED]) (gcc version 3.3 (Debian)) #1 Sun Mar 6 12:00:57 CET 2005 6BIOS-provided physical RAM map: 4 BIOS-e820: - 0009f000 (usable) 4 BIOS-e820: 0009f000 - 000a (reserved) 4 BIOS-e820: 0010 - 3ffae000 (usable) 4 BIOS-e820: 3ffae000 - 4000 (reserved) 4 BIOS-e820: feda - fee0 (reserved) 4 BIOS-e820: ffb0 - 0001 (reserved) 4Warning only 896MB will be used. 4Use a HIGHMEM enabled kernel. 5896MB LOWMEM available. 7On node 0 totalpages: 229376 7 DMA zone: 4096 pages, LIFO batch:1 7 Normal zone: 225280 pages, LIFO batch:16 7 HighMem zone: 0 pages, LIFO batch:1 6DMI 2.3 present. 7ACPI: RSDP (v000 DELL ) @ 0x000fdf00 7ACPI: RSDT (v001 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff 7ACPI: FADT (v001 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff0400 7ACPI: ASF! (v016 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff0800 7ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 MSFT 0x010e) @ 0x 4Allocating PCI resources starting at 4000 (gap: 4000:beda) 4Built 1 zonelists 4Kernel command line: BOOT_IMAGE=recover ro root=301 4Local APIC disabled by BIOS -- you can enable it with lapic 7mapped APIC to d000 (01703000) 6Initializing CPU#0 4PID hash table entries: 4096 (order: 12, 65536 bytes) 4Detected 1998.546 MHz processor. 6Using tsc for high-res timesource 4Console: colour VGA+ 80x25 4Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) 4Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) 6Memory: 906620k/917504k available (1598k kernel code, 10432k reserved, 518k data, 140k init, 0k highmem) 4Checking if this processor honours the WP bit even in supervisor mode... Ok. 7Calibrating delay loop... 3956.73 BogoMIPS (lpj=1978368) 4Mount-cache hash table entries: 512 (order: 0, 4096 bytes) 7CPU: After generic identify, caps: afe9f9bf 0180 7CPU: After vendor identify, caps: afe9f9bf 0180 6CPU: L1 I cache: 32K, L1 D cache: 32K 6CPU: L2 cache: 2048K 7CPU: After all inits, caps: afe9f9bf 0040 0180 6Intel machine check architecture supported. 6Intel machine check reporting enabled on CPU#0. 4CPU: Intel(R) Pentium(R) M processor 2.00GHz stepping 06 6Enabling fast FPU save and restore... done. 6Enabling unmasked SIMD FPU exception support... done. 6Checking 'hlt' instruction... OK. 4ACPI: setting ELCR to 0200 (from 0800) 6NET: Registered protocol family 16 6PCI: PCI BIOS revision 2.10 entry at 0xfc96e, last bus=2 6PCI: Using configuration type 1 6mtrr: v2.0 (20020519) 6ACPI: Subsystem revision 20050211 6ACPI: Interpreter enabled 6ACPI: Using PIC for interrupt routing 6ACPI: PCI Root Bridge [PCI0] (00:00) 4PCI: Probing
Re: Linux 2.6.12-rc2
On Monday 04 April 2005 17:32, Linus Torvalds wrote: >The diffstat output tells the story: this is a lot of very small > changes, ie tons of small cleanups and bug fixes. With a few new > drivers thrown in for good measure. > >This is also the point where I ask people to calm down, and not send > me anything but clear bug-fixes etc. We're definitely well into -rc > land. So keep it quiet out there, > > Linus Well, I'm happy to report that it not only built, it booted, and that the one program thats been a noshow for video, tvtime, in any kernel newer than -rc1, failing in all the . releases after .2, or any -mm I tried, is working quite nicely thank you in -rc2. Its late, and I'll check the rest of my checklist in the morning. -rc1 was one heck of an improvement in feel and usability, I hope -rc2 will continue that tradition. Great stuff. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - 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: Linux 2.6.12-rc2
On Tue, Apr 05, 2005 at 12:49:55AM +0100, Russell King wrote: > IOW, when sysdev.h is updated to prototype the function pointer with > pm_message_t, this'll also be solved. > > Therefore, if anything, linux/pm.h should be added to linux/sysdev.h as > the minimal patch. OK... - 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: Linux 2.6.12-rc2
On Tue, Apr 05, 2005 at 09:37:18AM +1000, Stephen Rothwell wrote: > On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> > wrote: > > > > o missing include in lanai.c > > After this patch I have ended up with linux/dma-mapping.h included twice > in this file ... Argh. Looks like the same fix went in twice (now and in -rc1-bk3) and these patches added include in places just far enough from each other to create no rejects when porting patchset to -bk3 and further. - 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: Linux 2.6.12-rc2
On Tue, Apr 05, 2005 at 12:24:19AM +0100, Al Viro wrote: > On Mon, Apr 04, 2005 at 02:32:52PM -0700, Linus Torvalds wrote: > > This is also the point where I ask people to calm down, and not send me > > anything but clear bug-fixes etc. We're definitely well into -rc land. So > > keep it quiet out there, > > * missing include in arm/kernel/time.c - see #ifdef CONFIG_PM > further down in the file. See previous threads. The include should be in linux/sysdev.h. The reason this has come up is because the ARM changes got merged before the generic changes, so there's currently a minor disparity with the calling convention for system device suspend methods. IOW, when sysdev.h is updated to prototype the function pointer with pm_message_t, this'll also be solved. Therefore, if anything, linux/pm.h should be added to linux/sysdev.h as the minimal patch. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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: Linux 2.6.12-rc2
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote: > > > The diffstat output tells the story: this is a lot of very small changes, > ie tons of small cleanups and bug fixes. With a few new drivers thrown in > for good measure. > > This is also the point where I ask people to calm down, and not send me > anything but clear bug-fixes etc. We're definitely well into -rc land. So > keep it quiet out there, > > Linus > > > Summary of changes from v2.6.12-rc1 to v2.6.12-rc2 > == > [...] > Andres Salomon: > o Possible AMD8111e free irq issue > o Possible VIA-Rhine free irq issue These first two fixes were from Panagiotis Issaris <[EMAIL PROTECTED]>; I merely forwarded them to gregkh & co. > o fix pci_disable_device in 8139too - 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: Linux 2.6.12-rc2
On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > o missing include in lanai.c After this patch I have ended up with linux/dma-mapping.h included twice in this file ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpaAmtwPxCtH.pgp Description: PGP signature
Re: Linux 2.6.12-rc2
On Mon, Apr 04, 2005 at 02:32:52PM -0700, Linus Torvalds wrote: > This is also the point where I ask people to calm down, and not send me > anything but clear bug-fixes etc. We're definitely well into -rc land. So > keep it quiet out there, * missing include in arm/kernel/time.c - see #ifdef CONFIG_PM further down in the file. diff -urN RC12-rc2-base/arch/arm/kernel/time.c current/arch/arm/kernel/time.c --- RC12-rc2-base/arch/arm/kernel/time.c2005-04-04 18:20:42.0 -0400 +++ current/arch/arm/kernel/time.c 2005-04-04 19:17:12.446004816 -0400 @@ -28,6 +28,7 @@ #include #include #include +#include #include #include - 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: Linux 2.6.12-rc2
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote: > > > The diffstat output tells the story: this is a lot of very small changes, > ie tons of small cleanups and bug fixes. With a few new drivers thrown in > for good measure. > > This is also the point where I ask people to calm down, and not send me > anything but clear bug-fixes etc. We're definitely well into -rc land. So > keep it quiet out there, > > Linus > > > Summary of changes from v2.6.12-rc1 to v2.6.12-rc2 > == > [...] > Andres Salomon: > o Possible AMD8111e free irq issue > o Possible VIA-Rhine free irq issue > o fix pci_disable_device in 8139too > The first two fixes were from Panagiotis Issaris <[EMAIL PROTECTED]>; I merely forwarded them on. - 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: Linux 2.6.12-rc2
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote: [...] > > > Summary of changes from v2.6.12-rc1 to v2.6.12-rc2 > == > [...] > > Andres Salomon: > o Possible AMD8111e free irq issue > o Possible VIA-Rhine free irq issue Those two were from Panagiotis Issaris <[EMAIL PROTECTED]>; I just forwarded them on. > o fix pci_disable_device in 8139too - 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: Linux 2.6.12-rc2
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote: [...] Summary of changes from v2.6.12-rc1 to v2.6.12-rc2 == [...] Andres Salomon: o Possible AMD8111e free irq issue o Possible VIA-Rhine free irq issue Those two were from Panagiotis Issaris [EMAIL PROTECTED]; I just forwarded them on. o fix pci_disable_device in 8139too - 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: Linux 2.6.12-rc2
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote: The diffstat output tells the story: this is a lot of very small changes, ie tons of small cleanups and bug fixes. With a few new drivers thrown in for good measure. This is also the point where I ask people to calm down, and not send me anything but clear bug-fixes etc. We're definitely well into -rc land. So keep it quiet out there, Linus Summary of changes from v2.6.12-rc1 to v2.6.12-rc2 == [...] Andres Salomon: o Possible AMD8111e free irq issue o Possible VIA-Rhine free irq issue o fix pci_disable_device in 8139too The first two fixes were from Panagiotis Issaris [EMAIL PROTECTED]; I merely forwarded them on. - 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: Linux 2.6.12-rc2
On Mon, Apr 04, 2005 at 02:32:52PM -0700, Linus Torvalds wrote: This is also the point where I ask people to calm down, and not send me anything but clear bug-fixes etc. We're definitely well into -rc land. So keep it quiet out there, * missing include in arm/kernel/time.c - see #ifdef CONFIG_PM further down in the file. diff -urN RC12-rc2-base/arch/arm/kernel/time.c current/arch/arm/kernel/time.c --- RC12-rc2-base/arch/arm/kernel/time.c2005-04-04 18:20:42.0 -0400 +++ current/arch/arm/kernel/time.c 2005-04-04 19:17:12.446004816 -0400 @@ -28,6 +28,7 @@ #include linux/profile.h #include linux/sysdev.h #include linux/timer.h +#include linux/pm.h #include asm/hardware.h #include asm/io.h - 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: Linux 2.6.12-rc2
On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: o missing include in lanai.c After this patch I have ended up with linux/dma-mapping.h included twice in this file ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpaAmtwPxCtH.pgp Description: PGP signature
Re: Linux 2.6.12-rc2
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote: The diffstat output tells the story: this is a lot of very small changes, ie tons of small cleanups and bug fixes. With a few new drivers thrown in for good measure. This is also the point where I ask people to calm down, and not send me anything but clear bug-fixes etc. We're definitely well into -rc land. So keep it quiet out there, Linus Summary of changes from v2.6.12-rc1 to v2.6.12-rc2 == [...] Andres Salomon: o Possible AMD8111e free irq issue o Possible VIA-Rhine free irq issue These first two fixes were from Panagiotis Issaris [EMAIL PROTECTED]; I merely forwarded them to gregkh co. o fix pci_disable_device in 8139too - 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: Linux 2.6.12-rc2
On Tue, Apr 05, 2005 at 09:37:18AM +1000, Stephen Rothwell wrote: On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: o missing include in lanai.c After this patch I have ended up with linux/dma-mapping.h included twice in this file ... Argh. Looks like the same fix went in twice (now and in -rc1-bk3) and these patches added include in places just far enough from each other to create no rejects when porting patchset to -bk3 and further. - 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: Linux 2.6.12-rc2
On Tue, Apr 05, 2005 at 12:49:55AM +0100, Russell King wrote: IOW, when sysdev.h is updated to prototype the function pointer with pm_message_t, this'll also be solved. Therefore, if anything, linux/pm.h should be added to linux/sysdev.h as the minimal patch. OK... - 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: Linux 2.6.12-rc2
On Monday 04 April 2005 17:32, Linus Torvalds wrote: The diffstat output tells the story: this is a lot of very small changes, ie tons of small cleanups and bug fixes. With a few new drivers thrown in for good measure. This is also the point where I ask people to calm down, and not send me anything but clear bug-fixes etc. We're definitely well into -rc land. So keep it quiet out there, Linus Well, I'm happy to report that it not only built, it booted, and that the one program thats been a noshow for video, tvtime, in any kernel newer than -rc1, failing in all the . releases after .2, or any -mm I tried, is working quite nicely thank you in -rc2. Its late, and I'll check the rest of my checklist in the morning. -rc1 was one heck of an improvement in feel and usability, I hope -rc2 will continue that tradition. Great stuff. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - 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/