Re: [PATCH v2] serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt
On 02/06/2017 03:30 PM, Douglas Anderson wrote:
On a Rockchip rk3399-based board during suspend/resume testing, we
found that we could get the console UART into a state where it would
print this to the console a lot:
serial8250: too much work for irq42
Followed eventually by:
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 11s!
Upon debugging I found that we're in this state:
iir = 0x00cc
lsr = 0x0060
It appears that somehow we have a RX Timeout interrupt but there is no
actual data present to receive. When we're in this state the UART
driver claims that it handled the interrupt but it actually doesn't
really do anything. This means that we keep getting the interrupt
over and over again.
Normally we don't actually need to do anything special to handle a RX
Timeout interrupt. We'll notice that there is some data ready and
we'll read it, which will end up clearing the RX Timeout. In this
case we have a problem specifically because we got the RX TImeout
without any data. Reading a bogus byte is confirmed to get us out of
this state.
It's unclear how exactly the UART got into this state, but it is known
that the UART lines are essentially undriven and unpowered during
suspend, so possibly during resume some garbage / half transmitted
bits are seen on the line and put the UART into this state.
Its been a long time since I looked at this, but IIRC it wasn't garbage
bits, but spurious interrupts. The FIFO is implemented in such a way
that it acts as a ring, and with a known input you could know ahead of
time what the result of the extra read would be. This tricked me up, as
with the inputs I was originally using it appeared to be valid data,
when in fact it was just the next buffer in the ring which still had old
data.
This probably doesn't help much, but at least gives some background
knowledge.
---
Cal
The UART on the rk3399 is a DesignWare based 8250 UART. From mailing
list posts, it appears that other people have run into similar
problems with DesignWare based IP. Presumably this problem is unique
to that IP, so I have placed the workaround there to avoid possibly of
accidentally triggering bad behavior on other IP. Also note the RX
Timeout behaves very differently in the DMA case, for for now the
workaround is only applied to the non-DMA case.
Signed-off-by: Douglas Anderson <diand...@chromium.org>
---
Testing and development done on a kernel-4.4 based tree, then picked
to ToT, where the code applied cleanly.
Changes in v2:
- Only apply to 8250_dw, not all 8250
- Only apply to the non-DMA case
drivers/tty/serial/8250/8250_dw.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index c89ae4581378..6ee55a2d47bb 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -201,8 +201,31 @@ static unsigned int dw8250_serial_in32be(struct uart_port
*p, int offset)
static int dw8250_handle_irq(struct uart_port *p)
{
+ struct uart_8250_port *up = up_to_u8250p(p);
struct dw8250_data *d = p->private_data;
unsigned int iir = p->serial_in(p, UART_IIR);
+ unsigned int status;
+ unsigned long flags;
+
+ /*
+* There are ways to get Designware-based UARTs into a state where
+* they are asserting UART_IIR_RX_TIMEOUT but there is no actual
+* data available. If we see such a case then we'll do a bogus
+* read. If we don't do this then the "RX TIMEOUT" interrupt will
+* fire forever.
+*
+* This problem has only been observed so far when not in DMA mode
+* so we limit the workaround only to non-DMA mode.
+*/
+ if (!up->dma && ((iir & 0x3f) == UART_IIR_RX_TIMEOUT)) {
+ spin_lock_irqsave(>lock, flags);
+ status = p->serial_in(p, UART_LSR);
+
+ if (!(status & (UART_LSR_DR | UART_LSR_BI)))
+ (void) p->serial_in(p, UART_RX);
+
+ spin_unlock_irqrestore(>lock, flags);
+ }
if (serial8250_handle_irq(p, iir))
return 1;
Re: [PATCH v2] serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt
On 02/06/2017 03:30 PM, Douglas Anderson wrote:
On a Rockchip rk3399-based board during suspend/resume testing, we
found that we could get the console UART into a state where it would
print this to the console a lot:
serial8250: too much work for irq42
Followed eventually by:
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 11s!
Upon debugging I found that we're in this state:
iir = 0x00cc
lsr = 0x0060
It appears that somehow we have a RX Timeout interrupt but there is no
actual data present to receive. When we're in this state the UART
driver claims that it handled the interrupt but it actually doesn't
really do anything. This means that we keep getting the interrupt
over and over again.
Normally we don't actually need to do anything special to handle a RX
Timeout interrupt. We'll notice that there is some data ready and
we'll read it, which will end up clearing the RX Timeout. In this
case we have a problem specifically because we got the RX TImeout
without any data. Reading a bogus byte is confirmed to get us out of
this state.
It's unclear how exactly the UART got into this state, but it is known
that the UART lines are essentially undriven and unpowered during
suspend, so possibly during resume some garbage / half transmitted
bits are seen on the line and put the UART into this state.
Its been a long time since I looked at this, but IIRC it wasn't garbage
bits, but spurious interrupts. The FIFO is implemented in such a way
that it acts as a ring, and with a known input you could know ahead of
time what the result of the extra read would be. This tricked me up, as
with the inputs I was originally using it appeared to be valid data,
when in fact it was just the next buffer in the ring which still had old
data.
This probably doesn't help much, but at least gives some background
knowledge.
---
Cal
The UART on the rk3399 is a DesignWare based 8250 UART. From mailing
list posts, it appears that other people have run into similar
problems with DesignWare based IP. Presumably this problem is unique
to that IP, so I have placed the workaround there to avoid possibly of
accidentally triggering bad behavior on other IP. Also note the RX
Timeout behaves very differently in the DMA case, for for now the
workaround is only applied to the non-DMA case.
Signed-off-by: Douglas Anderson
---
Testing and development done on a kernel-4.4 based tree, then picked
to ToT, where the code applied cleanly.
Changes in v2:
- Only apply to 8250_dw, not all 8250
- Only apply to the non-DMA case
drivers/tty/serial/8250/8250_dw.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index c89ae4581378..6ee55a2d47bb 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -201,8 +201,31 @@ static unsigned int dw8250_serial_in32be(struct uart_port
*p, int offset)
static int dw8250_handle_irq(struct uart_port *p)
{
+ struct uart_8250_port *up = up_to_u8250p(p);
struct dw8250_data *d = p->private_data;
unsigned int iir = p->serial_in(p, UART_IIR);
+ unsigned int status;
+ unsigned long flags;
+
+ /*
+* There are ways to get Designware-based UARTs into a state where
+* they are asserting UART_IIR_RX_TIMEOUT but there is no actual
+* data available. If we see such a case then we'll do a bogus
+* read. If we don't do this then the "RX TIMEOUT" interrupt will
+* fire forever.
+*
+* This problem has only been observed so far when not in DMA mode
+* so we limit the workaround only to non-DMA mode.
+*/
+ if (!up->dma && ((iir & 0x3f) == UART_IIR_RX_TIMEOUT)) {
+ spin_lock_irqsave(>lock, flags);
+ status = p->serial_in(p, UART_LSR);
+
+ if (!(status & (UART_LSR_DR | UART_LSR_BI)))
+ (void) p->serial_in(p, UART_RX);
+
+ spin_unlock_irqrestore(>lock, flags);
+ }
if (serial8250_handle_irq(p, iir))
return 1;
Re: [BUG] 3.4.109 - unable to handle kernel NULL pointer dereference at (null)
acklight i2c_piix4 usbcore i2c_algo_bit processor i2c_core sg thermal_sys usb_common button power_supply r8169 hwmon firmware_class mii loop! ext4 bd2 crc16 raid1 dm_mod raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx md_mod ahci libahci libata sd_mod scsi_mod Pid: 1862, comm: X Tainted: G D 3.4.108-00059-g961bd13 #7 MICRO-STAR INTERNATIONAL CO.,LTD MS-7551/KA780G (MS-7551) RIP: 0010:[] [] mutex_lock_interruptible+0xe/0x40 RSP: 0018:880211dd7698 EFLAGS: 00010296 RAX: RBX: 00a1 RCX: 00e9 RDX: 880211dd7fd8 RSI: 8802105d1e40 RDI: 00a1 RBP: 0019 R08: 000128c0 R09: R10: 0001 R11: R12: 88021184f800 R13: 8802105d1e50 R14: 0010 R15: 8802105d1e40 FS: 7f649ddd08a0() GS:88021fc0() knlGS:f70486d0 CS: 0010 DS: ES: CR0: 8005003b CR2: 00a1 CR3: 0160b000 CR4: 07f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process X (pid: 1862, threadinfo 880211dd6000, task 8802135e62d0) Stack: 00a1 a01621e0 8802105d1e40 88021184ea00 88021184f800 8802105d1e40 810c0de8 0001 001f 8102ef1d Call Trace: [] ? evdev_flush+0x30/0x80 [evdev] [] ? filp_close+0x38/0x90 [] ? put_files_struct+0x8d/0x100 [] ? do_exit+0x63d/0x870 [] ? printk+0x40/0x45 [] ? oops_end+0x73/0xa0 [] ? no_context+0x122/0x2d0 [] ? do_page_fault+0x3c5/0x420 [] ? __switch_to_xtra+0xcd/0x130 [] ? __switch_to+0x34f/0x3b0 [] ? wait_for_common+0xe6/0x190 [] ? try_to_wake_up+0x280/0x280 [] ? page_fault+0x1f/0x30 [] ? evdev_poll+0x2a/0x70 [evdev] [] ? do_select+0x333/0x5f0 [] ? r600_cs_packet_parse+0x42/0x140 [radeon] [] ? __pollwait+0x110/0x110 Oct 3 23:24:40 lancer last message repeated 7 times [] ? kmem_cache_free+0x86/0x90 [] ? __dequeue_signal+0x102/0x190 [] ? core_sys_select+0x20c/0x380 [] ? set_current_blocked+0x38/0x60 [] ? block_sigmask+0x3c/0x50 [] ? do_signal+0x1d4/0x620 [] ? ktime_get_ts+0x6d/0xe0 [] ? sys_select+0x42/0x110 [] ? system_call_fastpath+0x16/0x1b Code: 8b 44 24 08 48 89 42 08 48 89 10 80 43 04 01 b8 fc ff ff ff eb 96 0f 1f 80 00 00 00 00 53 48 89 fb e8 97 11 00 00 b8 ff ff ff ff 0f c1 03 ff c8 78 11 65 48 8b 04 25 c0 a7 00 00 48 89 43 18 RIP [] mutex_lock_interruptible+0xe/0x40 RSP CR2: 00a1 ---[ end trace 369d4585fbe82a05 ]--- Fixing recursive fault but reboot is needed! -- Cal Peake
Re: [BUG] 3.4.109 - unable to handle kernel NULL pointer dereference at (null)
d_page_alloc pata_atiixp backlight i2c_piix4 usbcore i2c_algo_bit processor i2c_core sg thermal_sys usb_common button power_supply r8169 hwmon firmware_class mii loop! ext4 bd2 crc16 raid1 dm_mod raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx md_mod ahci libahci libata sd_mod scsi_mod Pid: 1862, comm: X Tainted: G D 3.4.108-00059-g961bd13 #7 MICRO-STAR INTERNATIONAL CO.,LTD MS-7551/KA780G (MS-7551) RIP: 0010:[] [] mutex_lock_interruptible+0xe/0x40 RSP: 0018:880211dd7698 EFLAGS: 00010296 RAX: RBX: 00a1 RCX: 00e9 RDX: 880211dd7fd8 RSI: 8802105d1e40 RDI: 00a1 RBP: 0019 R08: 000128c0 R09: R10: 0001 R11: R12: 88021184f800 R13: 8802105d1e50 R14: 0010 R15: 8802105d1e40 FS: 7f649ddd08a0() GS:88021fc0() knlGS:f70486d0 CS: 0010 DS: ES: CR0: 8005003b CR2: 00a1 CR3: 0160b000 CR4: 07f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process X (pid: 1862, threadinfo 880211dd6000, task 8802135e62d0) Stack: 00a1 a01621e0 8802105d1e40 88021184ea00 88021184f800 8802105d1e40 810c0de8 0001 001f 8102ef1d Call Trace: [] ? evdev_flush+0x30/0x80 [evdev] [] ? filp_close+0x38/0x90 [] ? put_files_struct+0x8d/0x100 [] ? do_exit+0x63d/0x870 [] ? printk+0x40/0x45 [] ? oops_end+0x73/0xa0 [] ? no_context+0x122/0x2d0 [] ? do_page_fault+0x3c5/0x420 [] ? __switch_to_xtra+0xcd/0x130 [] ? __switch_to+0x34f/0x3b0 [] ? wait_for_common+0xe6/0x190 [] ? try_to_wake_up+0x280/0x280 [] ? page_fault+0x1f/0x30 [] ? evdev_poll+0x2a/0x70 [evdev] [] ? do_select+0x333/0x5f0 [] ? r600_cs_packet_parse+0x42/0x140 [radeon] [] ? __pollwait+0x110/0x110 Oct 3 23:24:40 lancer last message repeated 7 times [] ? kmem_cache_free+0x86/0x90 [] ? __dequeue_signal+0x102/0x190 [] ? core_sys_select+0x20c/0x380 [] ? set_current_blocked+0x38/0x60 [] ? block_sigmask+0x3c/0x50 [] ? do_signal+0x1d4/0x620 [] ? ktime_get_ts+0x6d/0xe0 [] ? sys_select+0x42/0x110 [] ? system_call_fastpath+0x16/0x1b Code: 8b 44 24 08 48 89 42 08 48 89 10 80 43 04 01 b8 fc ff ff ff eb 96 0f 1f 80 00 00 00 00 53 48 89 fb e8 97 11 00 00 b8 ff ff ff ff 0f c1 03 ff c8 78 11 65 48 8b 04 25 c0 a7 00 00 48 89 43 18 RIP [] mutex_lock_interruptible+0xe/0x40 RSP CR2: 00a1 ---[ end trace 369d4585fbe82a05 ]--- Fixing recursive fault but reboot is needed! -- Cal Peake
Re: [PATCH] [154/2many] MAINTAINERS - DIGI INTL. EPCA DRIVER
On Mon, 13 Aug 2007, Joe Perches wrote:
> On Tue, 2007-08-14 at 00:29 -0400, Cal Peake wrote:
> > Prolly /[^a-z0-9]/i would the safest bet. Also don't forget to escape
> > double quotes (e.g. "Jonathan \"Jon\" Doe" <[EMAIL PROTECTED]>).
>
> A-Z and [[:space:]] are OK too.
The 'i' at the end of the regex means case-insensitive ;) but yes, I
forgot whitespace. So something like:
if ($name =~ /[^a-z0-9[:space:]]/i) {
quote_name;
}
> I skimmed the spec, but nothing jumped out at me.
My recommendation was mostly based on what pine does. It seems to be a
pretty sane MUA...
--
Cal Peake
-
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] [154/2many] MAINTAINERS - DIGI INTL. EPCA DRIVER
On Mon, 13 Aug 2007, Joe Perches wrote:
> On Mon, 2007-08-13 at 09:35 -0700, Joe Perches wrote:
> > On Mon, 2007-08-13 at 09:15 -0700, Kok, Auke wrote:
> > > or properly put it on "quotes":
> >
> > I'll improve the script and revert the name changes.
>
> # check for "must quote" chars in name
>
> sub format_email {
> my ($name, $email) = @_;
>
> if ($name =~ tr@,\@<>@@) {
> $formatted_email = "\"${name}\"\ \<${email}\>";
> } else {
> $formatted_email = "${name} \<${email}\>";
> }
> return $formatted_email;
> }
>
> Anyone know what chars require the name be quoted?
> I've got: "," "@" "<" ">" ?
Prolly /[^a-z0-9]/i would the safest bet. Also don't forget to escape
double quotes (e.g. "Jonathan \"Jon\" Doe" <[EMAIL PROTECTED]>).
Cheers,
--
Cal Peake
-
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] [154/2many] MAINTAINERS - DIGI INTL. EPCA DRIVER
On Mon, 13 Aug 2007, Joe Perches wrote:
On Mon, 2007-08-13 at 09:35 -0700, Joe Perches wrote:
On Mon, 2007-08-13 at 09:15 -0700, Kok, Auke wrote:
or properly put it on quotes:
I'll improve the script and revert the name changes.
# check for must quote chars in name
sub format_email {
my ($name, $email) = @_;
if ($name =~ tr@,\@@@) {
$formatted_email = \${name}\\ \${email}\;
} else {
$formatted_email = ${name} \${email}\;
}
return $formatted_email;
}
Anyone know what chars require the name be quoted?
I've got: , @ ?
Prolly /[^a-z0-9]/i would the safest bet. Also don't forget to escape
double quotes (e.g. Jonathan \Jon\ Doe [EMAIL PROTECTED]).
Cheers,
--
Cal Peake
-
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] [154/2many] MAINTAINERS - DIGI INTL. EPCA DRIVER
On Mon, 13 Aug 2007, Joe Perches wrote:
On Tue, 2007-08-14 at 00:29 -0400, Cal Peake wrote:
Prolly /[^a-z0-9]/i would the safest bet. Also don't forget to escape
double quotes (e.g. Jonathan \Jon\ Doe [EMAIL PROTECTED]).
A-Z and [[:space:]] are OK too.
The 'i' at the end of the regex means case-insensitive ;) but yes, I
forgot whitespace. So something like:
if ($name =~ /[^a-z0-9[:space:]]/i) {
quote_name;
}
I skimmed the spec, but nothing jumped out at me.
My recommendation was mostly based on what pine does. It seems to be a
pretty sane MUA...
--
Cal Peake
-
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] [8/12] x86_64: Use global flag to disable broken local apic timer on AMD CPUs.
On Thu, 9 Aug 2007, Andi Kleen wrote: > Index: linux/arch/i386/kernel/apic.c > === > --- linux.orig/arch/i386/kernel/apic.c > +++ linux/arch/i386/kernel/apic.c > @@ -61,8 +61,9 @@ static int enable_local_apic __initdata > > /* Local APIC timer verification ok */ > static int local_apic_timer_verify_ok; > -/* Disable local APIC timer from the kernel commandline or via dmi quirk */ > -static int local_apic_timer_disabled; > +/* Disable local APIC timer from the kernel commandline or via dmi quirk > + or using CPU MSR check */ > +int local_apic_timer_disabled; > /* Local APIC timer works in C2 */ > int local_apic_timer_c2_ok; > EXPORT_SYMBOL_GPL(local_apic_timer_c2_ok); > @@ -370,9 +371,6 @@ void __init setup_boot_APIC_clock(void) > long delta, deltapm; > int pm_referenced = 0; > > - if (boot_cpu_has(X86_FEATURE_LAPIC_TIMER_BROKEN)) > - local_apic_timer_disabled = 1; > - > /* >* The local apic timer can be disabled via the kernel >* commandline or from the test above. Register the lapic Andi, just noticed that the comment above needs to be updated now. -- Cal Peake - 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] [8/12] x86_64: Use global flag to disable broken local apic timer on AMD CPUs.
On Thu, 9 Aug 2007, Andi Kleen wrote: Index: linux/arch/i386/kernel/apic.c === --- linux.orig/arch/i386/kernel/apic.c +++ linux/arch/i386/kernel/apic.c @@ -61,8 +61,9 @@ static int enable_local_apic __initdata /* Local APIC timer verification ok */ static int local_apic_timer_verify_ok; -/* Disable local APIC timer from the kernel commandline or via dmi quirk */ -static int local_apic_timer_disabled; +/* Disable local APIC timer from the kernel commandline or via dmi quirk + or using CPU MSR check */ +int local_apic_timer_disabled; /* Local APIC timer works in C2 */ int local_apic_timer_c2_ok; EXPORT_SYMBOL_GPL(local_apic_timer_c2_ok); @@ -370,9 +371,6 @@ void __init setup_boot_APIC_clock(void) long delta, deltapm; int pm_referenced = 0; - if (boot_cpu_has(X86_FEATURE_LAPIC_TIMER_BROKEN)) - local_apic_timer_disabled = 1; - /* * The local apic timer can be disabled via the kernel * commandline or from the test above. Register the lapic Andi, just noticed that the comment above needs to be updated now. -- Cal Peake - 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: Make checkpatch warn about pointless casting of kalloc returns.
On Wed, 8 Aug 2007, Dave Jones wrote:
> > I haven't tried it but how about something like:
> >
> > if($rawline =~/\(.*\)\s*k[czm]alloc/){
>
> Hmm, could even just drop the check for the '*'
> )[ ]k.. should be good enough.
There is none, both the '*'s are qualifiers :)
> > which if I got it right should match the typecast with any combination of
> spacing.
> >
> > > +WARN("No need to cast return value.\n");
> >
> > Could the warning be more descriptive? This describes what, but it should
> also describe
> > why; after all if somebody made this error they may not know they why.
>
> I'm open to suggestions..
Point to or quote from: http://c-faq.com/malloc/mallocnocast.html ?
--
Cal Peake
-
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] drop unneeded variable in amd_apic_timer_broken
On Wed, 8 Aug 2007, Andi Kleen wrote: > Can you please test if this patch works? Yep, seems to do the trick. Thanks! > BTW I checked with AMD and they seem to think it's just a buggy BIOS. Nod. Atleast we can work around it. > Use global flag to disable broken local apic timer on AMD CPUs. > > The Averatec 2370 laptop BIOS seems to program the ENABLE_C1E s~2370~2370/2371~ to be completely accurate ;) > MSR inconsistently between cores. This confuses the lapic > use heuristics wants to know if C1E is enabled anywhere. > > Use a global flag instead of a per cpu flag to handle this. > If any CPU has C1E enabled disabled lapic use. > > Thanks to Cal Peake for debugging. > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Acked-by: Cal Peake <[EMAIL PROTECTED]> -- Cal Peake - 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] drop unneeded variable in amd_apic_timer_broken
On Wed, 8 Aug 2007, Andi Kleen wrote: Can you please test if this patch works? Yep, seems to do the trick. Thanks! BTW I checked with AMD and they seem to think it's just a buggy BIOS. Nod. Atleast we can work around it. Use global flag to disable broken local apic timer on AMD CPUs. The Averatec 2370 laptop BIOS seems to program the ENABLE_C1E s~2370~2370/2371~ to be completely accurate ;) MSR inconsistently between cores. This confuses the lapic use heuristics wants to know if C1E is enabled anywhere. Use a global flag instead of a per cpu flag to handle this. If any CPU has C1E enabled disabled lapic use. Thanks to Cal Peake for debugging. Signed-off-by: Andi Kleen [EMAIL PROTECTED] Acked-by: Cal Peake [EMAIL PROTECTED] -- Cal Peake - 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: Make checkpatch warn about pointless casting of kalloc returns.
On Wed, 8 Aug 2007, Dave Jones wrote:
I haven't tried it but how about something like:
if($rawline =~/\(.*\)\s*k[czm]alloc/){
Hmm, could even just drop the check for the '*'
)[ ]k.. should be good enough.
There is none, both the '*'s are qualifiers :)
which if I got it right should match the typecast with any combination of
spacing.
+WARN(No need to cast return value.\n);
Could the warning be more descriptive? This describes what, but it should
also describe
why; after all if somebody made this error they may not know they why.
I'm open to suggestions..
Point to or quote from: http://c-faq.com/malloc/mallocnocast.html ?
--
Cal Peake
-
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/
[PATCH] drop unneeded variable in amd_apic_timer_broken
On Wed, 8 Aug 2007, Andi Kleen wrote:
> Not sure why the MSR varies between cores though.
Yeah that boggled me too.
> It's better to just make it a global instead.
Haven't gotten to figuring out how to do *that* yet... but here's a
cleanup for the detection function:
From: Cal Peake <[EMAIL PROTECTED]>
We only care about the lower 32-bits when reading the Interrupt Pending
Message Register so drop the 'hi' variable and use rdmsrl() instead.
Signed-off-by: Cal Peake <[EMAIL PROTECTED]>
--- ./arch/i386/kernel/cpu/amd.c~orig 2007-08-07 20:22:26.0 -0400
+++ ./arch/i386/kernel/cpu/amd.c2007-08-07 20:23:22.0 -0400
@@ -34,7 +34,7 @@ __asm__(".align 4\nvide: ret");
/* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
static __cpuinit int amd_apic_timer_broken(void)
{
- u32 lo, hi;
+ u32 msr;
u32 eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE);
switch (eax & CPUID_XFAM) {
case CPUID_XFAM_K8:
@@ -42,8 +42,8 @@ static __cpuinit int amd_apic_timer_brok
break;
case CPUID_XFAM_10H:
case CPUID_XFAM_11H:
- rdmsr(MSR_K8_ENABLE_C1E, lo, hi);
- if (lo & ENABLE_C1E_MASK)
+ rdmsrl(MSR_K8_ENABLE_C1E, msr);
+ if (msr & ENABLE_C1E_MASK)
return 1;
break;
default:
-
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: ACPI on Averatec 2370
On Fri, 3 Aug 2007, Linus Torvalds wrote: > > MSR_K8_ENABLE_C1E lo == 0x04c14015 > > MSR_K8_ENABLE_C1E hi == 0x > > lo & ENABLE_C1E_MASK == 0 > > And yeah, that claims that C1E is not on, but: > > > amd_apic_timer_broken: forcing return value of 1 So it seems my initial debugging report was, err, incomplete. I failed to notice that the amd_apic_timer_broken function was getting called twice, once for each core. The second call shows this: MSR_K8_ENABLE_C1E == 0x14c14015 which causes our ENABLE_C1E_MASK check to be true and thus properly return 1 from the function. So when we call the above function from init_amd we prolly need to do a set_bit(X86_FEATURE_LAPIC_TIMER_BROKEN, c->x86_capability); for each core if any of them happen to return true upon checking for a broken timer. Andi, does that seem right? -- Cal Peake - 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: ACPI on Averatec 2370
On Fri, 3 Aug 2007, Linus Torvalds wrote: MSR_K8_ENABLE_C1E lo == 0x04c14015 MSR_K8_ENABLE_C1E hi == 0x lo ENABLE_C1E_MASK == 0 And yeah, that claims that C1E is not on, but: amd_apic_timer_broken: forcing return value of 1 So it seems my initial debugging report was, err, incomplete. I failed to notice that the amd_apic_timer_broken function was getting called twice, once for each core. The second call shows this: MSR_K8_ENABLE_C1E == 0x14c14015 which causes our ENABLE_C1E_MASK check to be true and thus properly return 1 from the function. So when we call the above function from init_amd we prolly need to do a set_bit(X86_FEATURE_LAPIC_TIMER_BROKEN, c-x86_capability); for each core if any of them happen to return true upon checking for a broken timer. Andi, does that seem right? -- Cal Peake - 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/
[PATCH] drop unneeded variable in amd_apic_timer_broken
On Wed, 8 Aug 2007, Andi Kleen wrote:
Not sure why the MSR varies between cores though.
Yeah that boggled me too.
It's better to just make it a global instead.
Haven't gotten to figuring out how to do *that* yet... but here's a
cleanup for the detection function:
From: Cal Peake [EMAIL PROTECTED]
We only care about the lower 32-bits when reading the Interrupt Pending
Message Register so drop the 'hi' variable and use rdmsrl() instead.
Signed-off-by: Cal Peake [EMAIL PROTECTED]
--- ./arch/i386/kernel/cpu/amd.c~orig 2007-08-07 20:22:26.0 -0400
+++ ./arch/i386/kernel/cpu/amd.c2007-08-07 20:23:22.0 -0400
@@ -34,7 +34,7 @@ __asm__(.align 4\nvide: ret);
/* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
static __cpuinit int amd_apic_timer_broken(void)
{
- u32 lo, hi;
+ u32 msr;
u32 eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE);
switch (eax CPUID_XFAM) {
case CPUID_XFAM_K8:
@@ -42,8 +42,8 @@ static __cpuinit int amd_apic_timer_brok
break;
case CPUID_XFAM_10H:
case CPUID_XFAM_11H:
- rdmsr(MSR_K8_ENABLE_C1E, lo, hi);
- if (lo ENABLE_C1E_MASK)
+ rdmsrl(MSR_K8_ENABLE_C1E, msr);
+ if (msr ENABLE_C1E_MASK)
return 1;
break;
default:
-
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: spurious NCQ completions from FUJITSU MHW2120BH
On Fri, 3 Aug 2007, Meelis Roos wrote: > Todays git gave me some EH errors during fsck (30 times mounted and time > to check), then recovered and works fine. Seems to be spurious NCQ > completion. The disk is > > Device Model: FUJITSU MHW2120BH > Firmware Version: 0012 > User Capacity:120?034?123?776 bytes As a data point: I've got the same drive w/ same revision in my laptop and haven't had any NCQ errors pop up. Currently running 2.6.23-rc2. ata1.00: ATA-8: FUJITSU MHW2120BH, 0012, max UDMA/100 ata1.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/100 Might be dependent on the controller and/or the driver. Got a nVidia MCP51 using sata_nv here. -- Cal Peake
Re: spurious NCQ completions from FUJITSU MHW2120BH
On Fri, 3 Aug 2007, Meelis Roos wrote: Todays git gave me some EH errors during fsck (30 times mounted and time to check), then recovered and works fine. Seems to be spurious NCQ completion. The disk is Device Model: FUJITSU MHW2120BH Firmware Version: 0012 User Capacity:120?034?123?776 bytes As a data point: I've got the same drive w/ same revision in my laptop and haven't had any NCQ errors pop up. Currently running 2.6.23-rc2. ata1.00: ATA-8: FUJITSU MHW2120BH, 0012, max UDMA/100 ata1.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/100 Might be dependent on the controller and/or the driver. Got a nVidia MCP51 using sata_nv here. -- Cal Peake
Re: CD/DVD-ROM: ide vs. libata
On Fri, 3 Aug 2007, Grega Fajdiga wrote: > Hello, LKML, > > I'm wondering if the old ide-cd from the ide subsystem is still > necessary to get a CD/DVD-ROM working or is there a libata driver > available already, Check the ATA menu in the kernel config to see if your controller has a driver. If so, enable it, enable SCSI cdrom support, and disable the old IDE stuff. If all goes well you should get /dev/sr0 which will be your new cdrom device. Cheers, -- Cal Peake - 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: Regression in 2.6.22, clock problems on Turion with 32-bit kernel
On Fri, 3 Aug 2007, Ben Collins wrote: > nolapic_timer does not fix it for me. Only nolapic and acpi=off works. I > commented on that thread as well now, thanks. Interesting. However, I don't have NO_HZ so maybe that plays on it... -- Cal Peake - 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: Regression in 2.6.22, clock problems on Turion with 32-bit kernel
On Fri, 3 Aug 2007, Ben Collins wrote: > > On Fri, 2007-08-03 at 08:30 -0700, Arjan van de Ven wrote: > > > I've tried every combination of boot param revolving around clocksource > > > and interrupts. The only thing that gets me booting is nolapic, but then > > > again, that knocks me down to a single cpu. > > > > hummm I wonder how nolapic knows you down to a single cpu... > > that is just an entirely strange relationship. > > Sorry, s/cpu/core/, but not sure if that makes a difference. Ben, Tim, See thread <http://marc.info/?t=11857327166=1=2>. Short version: nolapic_timer should fix things for the moment. Long term: some AMD kernel code needs to be fixed up to deal with a broken local APIC. Cheers, -- Cal Peake - 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: Regression in 2.6.22, clock problems on Turion with 32-bit kernel
On Fri, 3 Aug 2007, Ben Collins wrote: On Fri, 2007-08-03 at 08:30 -0700, Arjan van de Ven wrote: I've tried every combination of boot param revolving around clocksource and interrupts. The only thing that gets me booting is nolapic, but then again, that knocks me down to a single cpu. hummm I wonder how nolapic knows you down to a single cpu... that is just an entirely strange relationship. Sorry, s/cpu/core/, but not sure if that makes a difference. Ben, Tim, See thread http://marc.info/?t=11857327166r=1w=2. Short version: nolapic_timer should fix things for the moment. Long term: some AMD kernel code needs to be fixed up to deal with a broken local APIC. Cheers, -- Cal Peake - 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: Regression in 2.6.22, clock problems on Turion with 32-bit kernel
On Fri, 3 Aug 2007, Ben Collins wrote: nolapic_timer does not fix it for me. Only nolapic and acpi=off works. I commented on that thread as well now, thanks. Interesting. However, I don't have NO_HZ so maybe that plays on it... -- Cal Peake - 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: CD/DVD-ROM: ide vs. libata
On Fri, 3 Aug 2007, Grega Fajdiga wrote: Hello, LKML, I'm wondering if the old ide-cd from the ide subsystem is still necessary to get a CD/DVD-ROM working or is there a libata driver available already, Check the ATA menu in the kernel config to see if your controller has a driver. If so, enable it, enable SCSI cdrom support, and disable the old IDE stuff. If all goes well you should get /dev/sr0 which will be your new cdrom device. Cheers, -- Cal Peake - 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: ACPI on Averatec 2370
On Thu, 2 Aug 2007, Linus Torvalds wrote: > On Thu, 2 Aug 2007, Cal Peake wrote: > > > > Figured I should have sent that right after I hit the send key... > > > > processor : 0 > > vendor_id : AuthenticAMD > > cpu family : 15 > > model : 72 > > model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52 > > Sadly, this doesn't show the "extended family" stuff from cpuid. > > So it doesn't show any of the bits we actually care about. Sad. > > That said, the "AMD Turion(tm) 64 X2 Mobile Technology TL-52" _should_ be > a REV-F CPU afaik, and it should have thus fallen through to the > "ENABLE_C1E_MASK" logic. Afaik that's broken. > > Cal - can you > (a) test that forcing a "return 1" from that amd_apic_timer_broken() > function fixes it for you. ACK > (b) make that function print out the values it uses for debugging (ie the > xtended family and model numbers, and the MSR_K8_ENABLE_C1E MSR > values)? eax & CPUID_XFAM == 0x eax & CPUID_XMOD == 0x0004 MSR_K8_ENABLE_C1E lo == 0x04c14015 MSR_K8_ENABLE_C1E hi == 0x lo & ENABLE_C1E_MASK == 0 amd_apic_timer_broken: forcing return value of 1 -- Cal Peake - 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: ACPI on Averatec 2370
On Thu, 2 Aug 2007, Chuck Ebbert wrote: > On 08/02/2007 03:42 PM, Cal Peake wrote: > > On Thu, 2 Aug 2007, Chuck Ebbert wrote: > > > >> Try the 'nolapic_timer' option. > > > > Ah, thank you Chuck! This looks to have fixed the stalling/hanging > > problems I was having. > > > > Now I'm wondering if arch/i386/kernel/cpu/amd.c:amd_apic_timer_broken() > > can (or needs to) be updated for this particular CPU revision. > > What does your /proc/cpuinfo say? Figured I should have sent that right after I hit the send key... processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52 stepping: 2 cpu MHz : 1607.320 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc bogomips: 3216.76 clflush size: 64 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52 stepping: 2 cpu MHz : 1607.320 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc bogomips: 3214.55 clflush size: 64 -- Cal Peake - 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: ACPI on Averatec 2370
On Thu, 2 Aug 2007, Chuck Ebbert wrote: > On 08/02/2007 01:50 PM, Cal Peake wrote: > > This problem seems to be getting worse. With the latest linus tree, after > > the initial hang where the power button is needed to bring the system back > > to life, the boot process slows to a crawl. > > > > Although if I repeatedly press the shift key it'll help move things along. > > I'm guessing the keyboard interrupt firing off is doing something to help > > it. The system seems OK though after booting is finished. > > > > Upon shutdown it actually stalls out without help from the shift key. > > > > Any thoughts on this, or tips to help debug it further? > > Try the 'nolapic_timer' option. Ah, thank you Chuck! This looks to have fixed the stalling/hanging problems I was having. Now I'm wondering if arch/i386/kernel/cpu/amd.c:amd_apic_timer_broken() can (or needs to) be updated for this particular CPU revision. Andi? Thanks, -- Cal Peake - 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: ACPI on Averatec 2370
This problem seems to be getting worse. With the latest linus tree, after the initial hang where the power button is needed to bring the system back to life, the boot process slows to a crawl. Although if I repeatedly press the shift key it'll help move things along. I'm guessing the keyboard interrupt firing off is doing something to help it. The system seems OK though after booting is finished. Upon shutdown it actually stalls out without help from the shift key. Any thoughts on this, or tips to help debug it further? thx, Cal On Mon, 30 Jul 2007, Cal Peake wrote: > On Sun, 29 Jul 2007, Gabriel C wrote: > > > Frank Hale wrote: > > [ added linux-acpi to CC ] > > > I have an Averatec 2370 laptop with the nVidia MCP51. With kernel > > > 2.6.20 I had no issues with ACPI however with 2.6.21 and higher the > > > kernel will hang on boot until I press the suspend button or the power > > > button in which case the kernel wakes up and finishes the boot > > > process. Including the following support only causes the issue: > > > > > > [*] ACPI Support > > > > > > What I mean by that is every ACPI option has been deactivated and only > > > ACPI support checked. The boot process with 2.6.21 and higher hangs at > > > the point where the Scheduler is being registered. > > > > > > io scheduler cfq registered (default) > > > > > > If I allow it to sit there it never comes back to life and finishes > > > booting. If I press the power or suspend button it will finish booting > > > as expected. > > > > > > I've scoured google for quite a while but cannot find any relevant > > > information pertaining to this issue. For now I've disabled ACPI > > > altogether. > > Frank, thanks for the tip about 2.6.20 being good, it gave me a nice place > to start bisecting from. > > Thomas, Ingo, > > Regarding the issue described above that Frank and I are having, I've > narrowed it down to commit e9e2cdb4[1]: [PATCH] clockevents: i386 drivers > > About our systems: > Averatec 2370/2371 Laptop > AMD Turion 64 X2 TL-50/TL-52 > nVidia MCP51 chipset > > Here a small matrix of my tests: > > 2.6.20.15 SMP : OK > 2.6.21.5 SMP : hang > 2.6.21.5 UP w/o APIC : OK > 2.6.22.1 UP : hang > 2.6.22.1 UP w/o IO-APIC : hang > 2.6.22.1 UP w/o APIC : OK > 2.6.22.1 SMP : hang > 2.6.22.1 SMP w/o ACPI : OK > > Please let me know if there's anything else I can provide to help. > > thanks! > -- > Cal Peake > > [1] > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e9e2cdb412412326c4827fc78ba27f410d837e6e - 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: ACPI on Averatec 2370
This problem seems to be getting worse. With the latest linus tree, after the initial hang where the power button is needed to bring the system back to life, the boot process slows to a crawl. Although if I repeatedly press the shift key it'll help move things along. I'm guessing the keyboard interrupt firing off is doing something to help it. The system seems OK though after booting is finished. Upon shutdown it actually stalls out without help from the shift key. Any thoughts on this, or tips to help debug it further? thx, Cal On Mon, 30 Jul 2007, Cal Peake wrote: On Sun, 29 Jul 2007, Gabriel C wrote: Frank Hale wrote: [ added linux-acpi to CC ] I have an Averatec 2370 laptop with the nVidia MCP51. With kernel 2.6.20 I had no issues with ACPI however with 2.6.21 and higher the kernel will hang on boot until I press the suspend button or the power button in which case the kernel wakes up and finishes the boot process. Including the following support only causes the issue: [*] ACPI Support What I mean by that is every ACPI option has been deactivated and only ACPI support checked. The boot process with 2.6.21 and higher hangs at the point where the Scheduler is being registered. io scheduler cfq registered (default) If I allow it to sit there it never comes back to life and finishes booting. If I press the power or suspend button it will finish booting as expected. I've scoured google for quite a while but cannot find any relevant information pertaining to this issue. For now I've disabled ACPI altogether. Frank, thanks for the tip about 2.6.20 being good, it gave me a nice place to start bisecting from. Thomas, Ingo, Regarding the issue described above that Frank and I are having, I've narrowed it down to commit e9e2cdb4[1]: [PATCH] clockevents: i386 drivers About our systems: Averatec 2370/2371 Laptop AMD Turion 64 X2 TL-50/TL-52 nVidia MCP51 chipset Here a small matrix of my tests: 2.6.20.15 SMP : OK 2.6.21.5 SMP : hang 2.6.21.5 UP w/o APIC : OK 2.6.22.1 UP : hang 2.6.22.1 UP w/o IO-APIC : hang 2.6.22.1 UP w/o APIC : OK 2.6.22.1 SMP : hang 2.6.22.1 SMP w/o ACPI : OK Please let me know if there's anything else I can provide to help. thanks! -- Cal Peake [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e9e2cdb412412326c4827fc78ba27f410d837e6e - 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: ACPI on Averatec 2370
On Thu, 2 Aug 2007, Chuck Ebbert wrote: On 08/02/2007 01:50 PM, Cal Peake wrote: This problem seems to be getting worse. With the latest linus tree, after the initial hang where the power button is needed to bring the system back to life, the boot process slows to a crawl. Although if I repeatedly press the shift key it'll help move things along. I'm guessing the keyboard interrupt firing off is doing something to help it. The system seems OK though after booting is finished. Upon shutdown it actually stalls out without help from the shift key. Any thoughts on this, or tips to help debug it further? Try the 'nolapic_timer' option. Ah, thank you Chuck! This looks to have fixed the stalling/hanging problems I was having. Now I'm wondering if arch/i386/kernel/cpu/amd.c:amd_apic_timer_broken() can (or needs to) be updated for this particular CPU revision. Andi? Thanks, -- Cal Peake - 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: ACPI on Averatec 2370
On Thu, 2 Aug 2007, Chuck Ebbert wrote: On 08/02/2007 03:42 PM, Cal Peake wrote: On Thu, 2 Aug 2007, Chuck Ebbert wrote: Try the 'nolapic_timer' option. Ah, thank you Chuck! This looks to have fixed the stalling/hanging problems I was having. Now I'm wondering if arch/i386/kernel/cpu/amd.c:amd_apic_timer_broken() can (or needs to) be updated for this particular CPU revision. What does your /proc/cpuinfo say? Figured I should have sent that right after I hit the send key... processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52 stepping: 2 cpu MHz : 1607.320 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc bogomips: 3216.76 clflush size: 64 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52 stepping: 2 cpu MHz : 1607.320 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc bogomips: 3214.55 clflush size: 64 -- Cal Peake - 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: ACPI on Averatec 2370
On Thu, 2 Aug 2007, Linus Torvalds wrote: On Thu, 2 Aug 2007, Cal Peake wrote: Figured I should have sent that right after I hit the send key... processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52 Sadly, this doesn't show the extended family stuff from cpuid. So it doesn't show any of the bits we actually care about. Sad. That said, the AMD Turion(tm) 64 X2 Mobile Technology TL-52 _should_ be a REV-F CPU afaik, and it should have thus fallen through to the ENABLE_C1E_MASK logic. Afaik that's broken. Cal - can you (a) test that forcing a return 1 from that amd_apic_timer_broken() function fixes it for you. ACK (b) make that function print out the values it uses for debugging (ie the xtended family and model numbers, and the MSR_K8_ENABLE_C1E MSR values)? eax CPUID_XFAM == 0x eax CPUID_XMOD == 0x0004 MSR_K8_ENABLE_C1E lo == 0x04c14015 MSR_K8_ENABLE_C1E hi == 0x lo ENABLE_C1E_MASK == 0 amd_apic_timer_broken: forcing return value of 1 -- Cal Peake - 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: Multiple CD-ROM Drives
On Mon, 30 Jul 2007, Brian D. McGrew wrote: > Using FC5 with a 2.6.15 kernel my system (Dell Optiplex) see both > drives. > > Using the 2.6.16.16 kernel that I've built I see no CD-ROM drives. > > What could I have missed in the configuration? Maybe send your working and broken configs to be examined? :) -- Cal Peake - 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] documentation fixes
On Tue, 31 Jul 2007, Ph. Marek wrote: > Hello everybody, > > here are some small documentation fixes - mostly typing errors. > > Please take a look at the last chunk - I think that klibc.bkbits.net > is no longer the current version, but I'm not sure whether the > other link is better. git://git.kernel.org/pub/scm/libs/klibc/klibc.git should be a safe replacement > Whom should I CC for other documentation updates? Is the maintainer > the correct person, or are such small fixes "send and forget"? For spelling and grammar fixes, sending to [EMAIL PROTECTED] is prolly the best bet with a CC to l-k. Also, please see Documentation/SubmittingPatches, particularly section 12 about signing off your work. cheers, -- Cal Peake - 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] documentation fixes
On Tue, 31 Jul 2007, Ph. Marek wrote: Hello everybody, here are some small documentation fixes - mostly typing errors. Please take a look at the last chunk - I think that klibc.bkbits.net is no longer the current version, but I'm not sure whether the other link is better. git://git.kernel.org/pub/scm/libs/klibc/klibc.git should be a safe replacement Whom should I CC for other documentation updates? Is the maintainer the correct person, or are such small fixes send and forget? For spelling and grammar fixes, sending to [EMAIL PROTECTED] is prolly the best bet with a CC to l-k. Also, please see Documentation/SubmittingPatches, particularly section 12 about signing off your work. cheers, -- Cal Peake - 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: Multiple CD-ROM Drives
On Mon, 30 Jul 2007, Brian D. McGrew wrote: Using FC5 with a 2.6.15 kernel my system (Dell Optiplex) see both drives. Using the 2.6.16.16 kernel that I've built I see no CD-ROM drives. What could I have missed in the configuration? Maybe send your working and broken configs to be examined? :) -- Cal Peake - 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: ACPI on Averatec 2370
On Sun, 29 Jul 2007, Gabriel C wrote: > Frank Hale wrote: > [ added linux-acpi to CC ] > > I have an Averatec 2370 laptop with the nVidia MCP51. With kernel > > 2.6.20 I had no issues with ACPI however with 2.6.21 and higher the > > kernel will hang on boot until I press the suspend button or the power > > button in which case the kernel wakes up and finishes the boot > > process. Including the following support only causes the issue: > > > > [*] ACPI Support > > > > What I mean by that is every ACPI option has been deactivated and only > > ACPI support checked. The boot process with 2.6.21 and higher hangs at > > the point where the Scheduler is being registered. > > > > io scheduler cfq registered (default) > > > > If I allow it to sit there it never comes back to life and finishes > > booting. If I press the power or suspend button it will finish booting > > as expected. > > > > I've scoured google for quite a while but cannot find any relevant > > information pertaining to this issue. For now I've disabled ACPI > > altogether. Frank, thanks for the tip about 2.6.20 being good, it gave me a nice place to start bisecting from. Thomas, Ingo, Regarding the issue described above that Frank and I are having, I've narrowed it down to commit e9e2cdb4[1]: [PATCH] clockevents: i386 drivers About our systems: Averatec 2370/2371 Laptop AMD Turion 64 X2 TL-50/TL-52 nVidia MCP51 chipset Here a small matrix of my tests: 2.6.20.15 SMP : OK 2.6.21.5 SMP: hang 2.6.21.5 UP w/o APIC: OK 2.6.22.1 UP : hang 2.6.22.1 UP w/o IO-APIC : hang 2.6.22.1 UP w/o APIC: OK 2.6.22.1 SMP: hang 2.6.22.1 SMP w/o ACPI : OK Please let me know if there's anything else I can provide to help. thanks! -- Cal Peake [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e9e2cdb412412326c4827fc78ba27f410d837e6e - 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: ACPI on Averatec 2370
On Sun, 29 Jul 2007, Gabriel C wrote: Frank Hale wrote: [ added linux-acpi to CC ] I have an Averatec 2370 laptop with the nVidia MCP51. With kernel 2.6.20 I had no issues with ACPI however with 2.6.21 and higher the kernel will hang on boot until I press the suspend button or the power button in which case the kernel wakes up and finishes the boot process. Including the following support only causes the issue: [*] ACPI Support What I mean by that is every ACPI option has been deactivated and only ACPI support checked. The boot process with 2.6.21 and higher hangs at the point where the Scheduler is being registered. io scheduler cfq registered (default) If I allow it to sit there it never comes back to life and finishes booting. If I press the power or suspend button it will finish booting as expected. I've scoured google for quite a while but cannot find any relevant information pertaining to this issue. For now I've disabled ACPI altogether. Frank, thanks for the tip about 2.6.20 being good, it gave me a nice place to start bisecting from. Thomas, Ingo, Regarding the issue described above that Frank and I are having, I've narrowed it down to commit e9e2cdb4[1]: [PATCH] clockevents: i386 drivers About our systems: Averatec 2370/2371 Laptop AMD Turion 64 X2 TL-50/TL-52 nVidia MCP51 chipset Here a small matrix of my tests: 2.6.20.15 SMP : OK 2.6.21.5 SMP: hang 2.6.21.5 UP w/o APIC: OK 2.6.22.1 UP : hang 2.6.22.1 UP w/o IO-APIC : hang 2.6.22.1 UP w/o APIC: OK 2.6.22.1 SMP: hang 2.6.22.1 SMP w/o ACPI : OK Please let me know if there's anything else I can provide to help. thanks! -- Cal Peake [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e9e2cdb412412326c4827fc78ba27f410d837e6e - 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: ACPI on Averatec 2370
On Sun, 29 Jul 2007, Gabriel C wrote: > Frank Hale wrote: > [ added linux-acpi to CC ] > > I have an Averatec 2370 laptop with the nVidia MCP51. With kernel > > 2.6.20 I had no issues with ACPI however with 2.6.21 and higher the > > kernel will hang on boot until I press the suspend button or the power > > button in which case the kernel wakes up and finishes the boot > > process. Including the following support only causes the issue: > > > > [*] ACPI Support > > > > What I mean by that is every ACPI option has been deactivated and only > > ACPI support checked. The boot process with 2.6.21 and higher hangs at > > the point where the Scheduler is being registered. > > > > io scheduler cfq registered (default) > > > > If I allow it to sit there it never comes back to life and finishes > > booting. If I press the power or suspend button it will finish booting > > as expected. > > > > I've scoured google for quite a while but cannot find any relevant > > information pertaining to this issue. For now I've disabled ACPI > > altogether. Hi Frank et al. Same laptop (well 2371 actually - same hardware though), same issue. In my testing I've determined that SMP is influential on it hanging up. Building my same config with SMP disabled causes the hang to go away. Same with the Slackware 12 default kernels, 2.6.21.5 is OK, 2.6.21.5-smp hangs. Frank, can you try a non-SMP build with ACPI and see if you still have the problem? I've tried so many different option combos I don't remember if I've done one with SMP and w/o ACPI but I'll try that sometime today. Haven't tried ACPI debugging yet either so we'll see if that shows anything. Maybe we can narrow it down to something with ACPI and SMP. Cheers, -- Cal Peake - 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: ACPI on Averatec 2370
On Sun, 29 Jul 2007, Gabriel C wrote: Frank Hale wrote: [ added linux-acpi to CC ] I have an Averatec 2370 laptop with the nVidia MCP51. With kernel 2.6.20 I had no issues with ACPI however with 2.6.21 and higher the kernel will hang on boot until I press the suspend button or the power button in which case the kernel wakes up and finishes the boot process. Including the following support only causes the issue: [*] ACPI Support What I mean by that is every ACPI option has been deactivated and only ACPI support checked. The boot process with 2.6.21 and higher hangs at the point where the Scheduler is being registered. io scheduler cfq registered (default) If I allow it to sit there it never comes back to life and finishes booting. If I press the power or suspend button it will finish booting as expected. I've scoured google for quite a while but cannot find any relevant information pertaining to this issue. For now I've disabled ACPI altogether. Hi Frank et al. Same laptop (well 2371 actually - same hardware though), same issue. In my testing I've determined that SMP is influential on it hanging up. Building my same config with SMP disabled causes the hang to go away. Same with the Slackware 12 default kernels, 2.6.21.5 is OK, 2.6.21.5-smp hangs. Frank, can you try a non-SMP build with ACPI and see if you still have the problem? I've tried so many different option combos I don't remember if I've done one with SMP and w/o ACPI but I'll try that sometime today. Haven't tried ACPI debugging yet either so we'll see if that shows anything. Maybe we can narrow it down to something with ACPI and SMP. Cheers, -- Cal Peake - 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/
[PATCH] Fix inotify maintainers entry
Update the inotify entry in MAINTAINERS to be consistent with the rest of the file. Signed-off-by: Cal Peake <[EMAIL PROTECTED]> --- ./MAINTAINERS~orig 2006-12-12 11:44:01.0 -0500 +++ ./MAINTAINERS 2006-12-12 12:08:02.0 -0500 @@ -1504,8 +1504,10 @@ S: Maintained INOTIFY -P: John McCutchan and Robert Love -M: [EMAIL PROTECTED] and [EMAIL PROTECTED] +P: John McCutchan +M: [EMAIL PROTECTED] +P: Robert Love +M: [EMAIL PROTECTED] L: linux-kernel@vger.kernel.org S: Maintained - 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/
[PATCH] Note subscribers only lists for input subsystem
According to Dmitry in <http://lkml.org/lkml/2006/10/17/280>, the input list is subscribers only. I'm assuming here that both are but a confirmation would be nice... :) From: Cal Peake <[EMAIL PROTECTED]> Annotate the MAINTAINERS file to reflect the subscribers only nature of the input mailing lists. Signed-off-by: Cal Peake <[EMAIL PROTECTED]> --- ./MAINTAINERS~orig 2006-12-10 14:58:32.0 -0500 +++ ./MAINTAINERS 2006-12-12 11:56:01.0 -0500 @@ -1498,8 +1498,8 @@ INPUT (KEYBOARD, MOUSE, JOYSTICK) DRIVER P: Dmitry Torokhov M: [EMAIL PROTECTED] M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +L: [EMAIL PROTECTED] (subscribers-only) T: git kernel.org:/pub/scm/linux/kernel/git/dtor/input.git S: Maintained - 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/
[PATCH] Note subscribers only lists for input subsystem
According to Dmitry in http://lkml.org/lkml/2006/10/17/280, the input list is subscribers only. I'm assuming here that both are but a confirmation would be nice... :) From: Cal Peake [EMAIL PROTECTED] Annotate the MAINTAINERS file to reflect the subscribers only nature of the input mailing lists. Signed-off-by: Cal Peake [EMAIL PROTECTED] --- ./MAINTAINERS~orig 2006-12-10 14:58:32.0 -0500 +++ ./MAINTAINERS 2006-12-12 11:56:01.0 -0500 @@ -1498,8 +1498,8 @@ INPUT (KEYBOARD, MOUSE, JOYSTICK) DRIVER P: Dmitry Torokhov M: [EMAIL PROTECTED] M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +L: [EMAIL PROTECTED] (subscribers-only) T: git kernel.org:/pub/scm/linux/kernel/git/dtor/input.git S: Maintained - 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/
[PATCH] Fix inotify maintainers entry
Update the inotify entry in MAINTAINERS to be consistent with the rest of the file. Signed-off-by: Cal Peake [EMAIL PROTECTED] --- ./MAINTAINERS~orig 2006-12-12 11:44:01.0 -0500 +++ ./MAINTAINERS 2006-12-12 12:08:02.0 -0500 @@ -1504,8 +1504,10 @@ S: Maintained INOTIFY -P: John McCutchan and Robert Love -M: [EMAIL PROTECTED] and [EMAIL PROTECTED] +P: John McCutchan +M: [EMAIL PROTECTED] +P: Robert Love +M: [EMAIL PROTECTED] L: linux-kernel@vger.kernel.org S: Maintained - 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: Brand-new notebook useless with Linux...
On Mon, 5 Sep 2005, Mathieu wrote: > the bioses released by phoenix seem a little broken. try a 2.6.13 > kernel with the option ec_burst=1. I agree with the broken phoenix part but be careful playing with ec_burst. When it was set to default pre-2.6.13-rc6 it caused my laptop to overheat and trip the thermal shutdown on several occasions before I figured out what the hell was going on (the fan wasn't getting spun when needed). good luck, -cp -- ". . . tell 'em we use Linux." -- Dave Chappelle - 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: Brand-new notebook useless with Linux...
On Mon, 5 Sep 2005, Mathieu wrote: the bioses released by phoenix seem a little broken. try a 2.6.13 kernel with the option ec_burst=1. I agree with the broken phoenix part but be careful playing with ec_burst. When it was set to default pre-2.6.13-rc6 it caused my laptop to overheat and trip the thermal shutdown on several occasions before I figured out what the hell was going on (the fan wasn't getting spun when needed). good luck, -cp -- . . . tell 'em we use Linux. -- Dave Chappelle - 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/
ftp.kernel.org/.../v2.6/snapshots/ cleanup; 2.6.13-git1 empty
Linus, I think I remember reading one time that you have permissions on the snapshots/ dir on kernel.org? Any chance all the pre-2.6.13 stuff can be pushed to the old/ dir? Also, 2.6.13-git1 didn't get generated right (it's empty!) but the log is fine (300k worth). Hopefully someone can fix this too? thanks, -cp -- ". . . tell 'em we use Linux." -- Dave Chappelle - 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/
ftp.kernel.org/.../v2.6/snapshots/ cleanup; 2.6.13-git1 empty
Linus, I think I remember reading one time that you have permissions on the snapshots/ dir on kernel.org? Any chance all the pre-2.6.13 stuff can be pushed to the old/ dir? Also, 2.6.13-git1 didn't get generated right (it's empty!) but the log is fine (300k worth). Hopefully someone can fix this too? thanks, -cp -- . . . tell 'em we use Linux. -- Dave Chappelle - 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: amd64-agp vs. swsusp
On Fri, 5 Aug 2005, Andreas Steinmetz wrote: > AFAIK it works when agp is built into the kernel. You will get problems > when it is built as a module. In the module case you may want to try if > loading the module before resuming helps. Strange. I've had it built as a module from day one and never had a problem resuming. -cp -- "There are three kinds of lies: lies, damned lies, and statistics." -- Benjamin Disraeli - 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: amd64-agp vs. swsusp
On Fri, 5 Aug 2005, Andreas Steinmetz wrote: AFAIK it works when agp is built into the kernel. You will get problems when it is built as a module. In the module case you may want to try if loading the module before resuming helps. Strange. I've had it built as a module from day one and never had a problem resuming. -cp -- There are three kinds of lies: lies, damned lies, and statistics. -- Benjamin Disraeli - 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: amd64-agp vs. swsusp
On Thu, 4 Aug 2005, Andrew Morton wrote: > Michal Schmidt <[EMAIL PROTECTED]> wrote: > > > > Does resuming from swsuspend work for anyone with amd64-agp loaded? > > It would seem not ;) Must have missed the OP. Yes I can resume fine from swsusp with amd64-agp. System is an Averatec 3270 (Mobile Sempron(K8)). Not that this helps at all other than confirming it is possible ;) -cp -- "There are three kinds of lies: lies, damned lies, and statistics." -- Benjamin Disraeli - 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: amd64-agp vs. swsusp
On Thu, 4 Aug 2005, Andrew Morton wrote: Michal Schmidt [EMAIL PROTECTED] wrote: Does resuming from swsuspend work for anyone with amd64-agp loaded? It would seem not ;) Must have missed the OP. Yes I can resume fine from swsusp with amd64-agp. System is an Averatec 3270 (Mobile Sempron(K8)). Not that this helps at all other than confirming it is possible ;) -cp -- There are three kinds of lies: lies, damned lies, and statistics. -- Benjamin Disraeli - 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.13-rc4
On Fri, 29 Jul 2005, Mickey Stein wrote:
> This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
> and gave it a test run. It had a bit of a problem and ground to a halt after
> spewing these into the log.
>
> If I can find the time tomorrow morning, I'll leave parport_pc commented out
> of modprobe.conf and see if something else pops loose. I don't use the
> parallel port, but I try to keep a fairly robust config for noticing bugs.
Hi Mick,
Can you please try the patch below from Linus (or -git2 tomorrow) and
confirm that it fixes it for you?
thx,
-cp
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -335,14 +335,13 @@ static inline unsigned long __ffs(unsign
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
int x = 0;
- do {
- if (*addr)
- return __ffs(*addr) + x;
- addr++;
- if (x >= size)
- break;
+
+ while (x < size) {
+ unsigned long val = *addr++;
+ if (val)
+ return __ffs(val) + x;
x += (sizeof(*addr)<<3);
- } while (1);
+ }
return x;
}
--
"Democracy can learn some things from Communism; for example,
when a Communist politician is through, he is through."
-- Unknown
-
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.13-rc4 (snd-cs46xx)
On Fri, 29 Jul 2005, Linus Torvalds wrote:
> Thanks. Just out of interest, does this patch fix it instead?
Indeed it does, thanks Linus!
-cp
>
> diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
> --- a/include/asm-i386/bitops.h
> +++ b/include/asm-i386/bitops.h
> @@ -335,14 +335,13 @@ static inline unsigned long __ffs(unsign
> static inline int find_first_bit(const unsigned long *addr, unsigned size)
> {
> int x = 0;
> - do {
> - if (*addr)
> - return __ffs(*addr) + x;
> - addr++;
> - if (x >= size)
> - break;
> +
> + while (x < size) {
> + unsigned long val = *addr++;
> + if (val)
> + return __ffs(val) + x;
> x += (sizeof(*addr)<<3);
> - } while (1);
> + }
> return x;
> }
>
>
--
"Democracy can learn some things from Communism; for example,
when a Communist politician is through, he is through."
-- Unknown
-
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.13-rc4 (snd-cs46xx)
On Thu, 28 Jul 2005, Andrew Morton wrote:
> The procfs inode IDR tree is scrogged. I'd be suspecting a random memory
> scribble. I'd suggest that you enable CONFIG_DEBUG_SLAB,
> CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_everything_else and retest.
>
> If that doesn't show anything, try eliminating stuff from your kernel
> config.
>
> If it _is_ a scribble then there's a good chance that changing the config
> will simply make it disappear, or will make it manifest in different ways.
Thanks Andrew! Indeed your suspicions are correct. Adding in all the
debugging moved the problem around, it now shows itself when probing
parport. Upon further investigation reverting the commit below seems to
have nixed the problem.
thx,
-cp
[PATCH] speed up on find_first_bit for i386 (let compiler do the work)
Avoid using "rep scas", just let the compiler select a sequence of
regular instructions.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
commit: cd85c8b4457a52d3545fdb9532082b2c1ebd5f21
--- ./include/asm-i386/bitops.h
+++ ./include/asm-i386/bitops.h
@@ -311,6 +311,20 @@ static inline int find_first_zero_bit(co
int find_next_zero_bit(const unsigned long *addr, int size, int offset);
/**
+ * __ffs - find first bit in word.
+ * @word: The word to search
+ *
+ * Undefined if no bit exists, so code should check against 0 first.
+ */
+static inline unsigned long __ffs(unsigned long word)
+{
+ __asm__("bsfl %1,%0"
+ :"=r" (word)
+ :"rm" (word));
+ return word;
+}
+
+/**
* find_first_bit - find the first set bit in a memory region
* @addr: The address to start the search at
* @size: The maximum size to search
@@ -320,22 +334,16 @@ int find_next_zero_bit(const unsigned lo
*/
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
- int d0, d1;
- int res;
-
- /* This looks at memory. Mark it volatile to tell gcc not to move it
around */
- __asm__ __volatile__(
- "xorl %%eax,%%eax\n\t"
- "repe; scasl\n\t"
- "jz 1f\n\t"
- "leal -4(%%edi),%%edi\n\t"
- "bsfl (%%edi),%%eax\n"
- "1:\tsubl %%ebx,%%edi\n\t"
- "shll $3,%%edi\n\t"
- "addl %%edi,%%eax"
- :"=a" (res), "=" (d0), "=" (d1)
- :"1" ((size + 31) >> 5), "2" (addr), "b" (addr) : "memory");
- return res;
+ int x = 0;
+ do {
+ if (*addr)
+ return __ffs(*addr) + x;
+ addr++;
+ if (x >= size)
+ break;
+ x += (sizeof(*addr)<<3);
+ } while (1);
+ return x;
}
/**
@@ -360,20 +368,6 @@ static inline unsigned long ffz(unsigned
return word;
}
-/**
- * __ffs - find first bit in word.
- * @word: The word to search
- *
- * Undefined if no bit exists, so code should check against 0 first.
- */
-static inline unsigned long __ffs(unsigned long word)
-{
- __asm__("bsfl %1,%0"
- :"=r" (word)
- :"rm" (word));
- return word;
-}
-
/*
* fls: find last bit set.
*/
--
"Democracy can learn some things from Communism; for example,
when a Communist politician is through, he is through."
-- Unknown
-
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.13-rc4 (snd-cs46xx)
On Thu, 28 Jul 2005, Andrew Morton wrote:
The procfs inode IDR tree is scrogged. I'd be suspecting a random memory
scribble. I'd suggest that you enable CONFIG_DEBUG_SLAB,
CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_everything_else and retest.
If that doesn't show anything, try eliminating stuff from your kernel
config.
If it _is_ a scribble then there's a good chance that changing the config
will simply make it disappear, or will make it manifest in different ways.
Thanks Andrew! Indeed your suspicions are correct. Adding in all the
debugging moved the problem around, it now shows itself when probing
parport. Upon further investigation reverting the commit below seems to
have nixed the problem.
thx,
-cp
[PATCH] speed up on find_first_bit for i386 (let compiler do the work)
Avoid using rep scas, just let the compiler select a sequence of
regular instructions.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
commit: cd85c8b4457a52d3545fdb9532082b2c1ebd5f21
--- ./include/asm-i386/bitops.h
+++ ./include/asm-i386/bitops.h
@@ -311,6 +311,20 @@ static inline int find_first_zero_bit(co
int find_next_zero_bit(const unsigned long *addr, int size, int offset);
/**
+ * __ffs - find first bit in word.
+ * @word: The word to search
+ *
+ * Undefined if no bit exists, so code should check against 0 first.
+ */
+static inline unsigned long __ffs(unsigned long word)
+{
+ __asm__(bsfl %1,%0
+ :=r (word)
+ :rm (word));
+ return word;
+}
+
+/**
* find_first_bit - find the first set bit in a memory region
* @addr: The address to start the search at
* @size: The maximum size to search
@@ -320,22 +334,16 @@ int find_next_zero_bit(const unsigned lo
*/
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
- int d0, d1;
- int res;
-
- /* This looks at memory. Mark it volatile to tell gcc not to move it
around */
- __asm__ __volatile__(
- xorl %%eax,%%eax\n\t
- repe; scasl\n\t
- jz 1f\n\t
- leal -4(%%edi),%%edi\n\t
- bsfl (%%edi),%%eax\n
- 1:\tsubl %%ebx,%%edi\n\t
- shll $3,%%edi\n\t
- addl %%edi,%%eax
- :=a (res), =c (d0), =D (d1)
- :1 ((size + 31) 5), 2 (addr), b (addr) : memory);
- return res;
+ int x = 0;
+ do {
+ if (*addr)
+ return __ffs(*addr) + x;
+ addr++;
+ if (x = size)
+ break;
+ x += (sizeof(*addr)3);
+ } while (1);
+ return x;
}
/**
@@ -360,20 +368,6 @@ static inline unsigned long ffz(unsigned
return word;
}
-/**
- * __ffs - find first bit in word.
- * @word: The word to search
- *
- * Undefined if no bit exists, so code should check against 0 first.
- */
-static inline unsigned long __ffs(unsigned long word)
-{
- __asm__(bsfl %1,%0
- :=r (word)
- :rm (word));
- return word;
-}
-
/*
* fls: find last bit set.
*/
--
Democracy can learn some things from Communism; for example,
when a Communist politician is through, he is through.
-- Unknown
-
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.13-rc4 (snd-cs46xx)
On Fri, 29 Jul 2005, Linus Torvalds wrote:
Thanks. Just out of interest, does this patch fix it instead?
Indeed it does, thanks Linus!
-cp
diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -335,14 +335,13 @@ static inline unsigned long __ffs(unsign
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
int x = 0;
- do {
- if (*addr)
- return __ffs(*addr) + x;
- addr++;
- if (x = size)
- break;
+
+ while (x size) {
+ unsigned long val = *addr++;
+ if (val)
+ return __ffs(val) + x;
x += (sizeof(*addr)3);
- } while (1);
+ }
return x;
}
--
Democracy can learn some things from Communism; for example,
when a Communist politician is through, he is through.
-- Unknown
-
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.13-rc4
On Fri, 29 Jul 2005, Mickey Stein wrote:
This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
and gave it a test run. It had a bit of a problem and ground to a halt after
spewing these into the log.
If I can find the time tomorrow morning, I'll leave parport_pc commented out
of modprobe.conf and see if something else pops loose. I don't use the
parallel port, but I try to keep a fairly robust config for noticing bugs.
Hi Mick,
Can you please try the patch below from Linus (or -git2 tomorrow) and
confirm that it fixes it for you?
thx,
-cp
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -335,14 +335,13 @@ static inline unsigned long __ffs(unsign
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
int x = 0;
- do {
- if (*addr)
- return __ffs(*addr) + x;
- addr++;
- if (x = size)
- break;
+
+ while (x size) {
+ unsigned long val = *addr++;
+ if (val)
+ return __ffs(val) + x;
x += (sizeof(*addr)3);
- } while (1);
+ }
return x;
}
--
Democracy can learn some things from Communism; for example,
when a Communist politician is through, he is through.
-- Unknown
-
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.13-rc4 (snd-cs46xx)
Hi, Getting this nastiness when probing snd-cs46xx: Unable to handle kernel paging request at virtual address 000a75a8 printing eip: c01afe52 *pde = Oops: [#1] Modules linked in: snd_cs46xx gameport snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc ipt_state ipt_REJECT ipt_LOG ip_conntrack iptable_filter ip_tables nfs lockd sunrpc cifs smbfs hfsplus udf isofs zlib_inflate ntfs msdos vfat fat nls_utf8 nls_iso8859_1 nls_cp437 nls_base e100 mii usb_storage sd_mod scsi_mod usbhid ohci_hcd ehci_hcd usbcore parport_pc parport psmouse pcspkr ide_cd cdrom floppy loop radeon drm nvidia_agp agpgart thermal processor fan button ac CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010246 (2.6.13-rc4) EIP is at sub_alloc+0x42/0x170 eax: 0440 ebx: 0022 ecx: edx: f7c3cd5c esi: 0440 edi: 000a75a8 ebp: esp: f7c3cd44 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 762, threadinfo=f7c3c000 task=f7df4550) Stack: f7c3cd5c 0020 0440 0440 c1cdf26c c1ceaf54 c1cdf260 00d0 f7736018 c1cdf26c 0002 f7733f60 c1ceaf54 c0335a74 c01afff8 c0335a74 f7c3cda0 Call Trace: [] idr_get_new_above_int+0x78/0x120 [] idr_get_new+0x1f/0x50 [] get_inode_number+0x39/0x60 [] proc_register+0x17/0xb0 [] create_proc_entry+0x85/0xd0 [] snd_create_proc_entry+0x20/0x30 [snd] [] snd_info_register+0x44/0xb0 [snd] [] snd_pcm_lib_preallocate_pages1+0x92/0xd0 [snd_pcm] [] snd_pcm_lib_preallocate_pages_for_all+0x44/0x70 [snd_pcm] [] snd_cs46xx_pcm_rear+0xe0/0x100 [snd_cs46xx] [] snd_card_cs46xx_probe+0xf9/0x250 [snd_cs46xx] [] pci_match_device+0x1d/0xb0 [] __pci_device_probe+0x58/0x70 [] pci_device_probe+0x2f/0x50 [] driver_probe_device+0x38/0xb0 [] __driver_attach+0x0/0x50 [] __driver_attach+0x4c/0x50 [] bus_for_each_dev+0x69/0x80 [] driver_attach+0x26/0x30 [] __driver_attach+0x0/0x50 [] bus_add_driver+0x83/0xe0 [] pci_register_driver+0x6d/0x90 [] alsa_card_cs46xx_init+0xf/0x13 [snd_cs46xx] [] sys_init_module+0x141/0x1d0 [] syscall_call+0x7/0xb Code: 08 8b 3a c7 44 8c 1c 00 00 00 00 49 89 4c 24 14 8d 2c 89 8d b6 00 00 00 00 8b 44 24 10 89 e9 8d 54 24 18 d3 f8 89 44 24 0c 89 c6 <8b> 07 83 e6 1f c7 44 24 04 20 00 00 00 89 14 24 89 74 24 08 f7 2.6.13-rc3-git9 is OK. I'll try poking around at the ALSA changes, see if I can figure out which one is the culprit. thx, -cp -- "Democracy can learn some things from Communism; for example, when a Communist politician is through, he is through." -- Unknown - 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.13-rc4 (snd-cs46xx)
Hi, Getting this nastiness when probing snd-cs46xx: Unable to handle kernel paging request at virtual address 000a75a8 printing eip: c01afe52 *pde = Oops: [#1] Modules linked in: snd_cs46xx gameport snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc ipt_state ipt_REJECT ipt_LOG ip_conntrack iptable_filter ip_tables nfs lockd sunrpc cifs smbfs hfsplus udf isofs zlib_inflate ntfs msdos vfat fat nls_utf8 nls_iso8859_1 nls_cp437 nls_base e100 mii usb_storage sd_mod scsi_mod usbhid ohci_hcd ehci_hcd usbcore parport_pc parport psmouse pcspkr ide_cd cdrom floppy loop radeon drm nvidia_agp agpgart thermal processor fan button ac CPU:0 EIP:0060:[c01afe52]Not tainted VLI EFLAGS: 00010246 (2.6.13-rc4) EIP is at sub_alloc+0x42/0x170 eax: 0440 ebx: 0022 ecx: edx: f7c3cd5c esi: 0440 edi: 000a75a8 ebp: esp: f7c3cd44 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 762, threadinfo=f7c3c000 task=f7df4550) Stack: f7c3cd5c 0020 0440 0440 c1cdf26c c1ceaf54 c1cdf260 00d0 f7736018 c1cdf26c 0002 f7733f60 c1ceaf54 c0335a74 c01afff8 c0335a74 f7c3cda0 Call Trace: [c01afff8] idr_get_new_above_int+0x78/0x120 [c01b010f] idr_get_new+0x1f/0x50 [c017d409] get_inode_number+0x39/0x60 [c017d6c7] proc_register+0x17/0xb0 [c017db05] create_proc_entry+0x85/0xd0 [f8b18f80] snd_create_proc_entry+0x20/0x30 [snd] [f8b194f4] snd_info_register+0x44/0xb0 [snd] [f8bbc0d2] snd_pcm_lib_preallocate_pages1+0x92/0xd0 [snd_pcm] [f8bbc184] snd_pcm_lib_preallocate_pages_for_all+0x44/0x70 [snd_pcm] [f8be5030] snd_cs46xx_pcm_rear+0xe0/0x100 [snd_cs46xx] [f8be30f9] snd_card_cs46xx_probe+0xf9/0x250 [snd_cs46xx] [c01b9cbd] pci_match_device+0x1d/0xb0 [c01b9da8] __pci_device_probe+0x58/0x70 [c01b9def] pci_device_probe+0x2f/0x50 [c01fb168] driver_probe_device+0x38/0xb0 [c01fb270] __driver_attach+0x0/0x50 [c01fb2bc] __driver_attach+0x4c/0x50 [c01fa799] bus_for_each_dev+0x69/0x80 [c01fb2e6] driver_attach+0x26/0x30 [c01fb270] __driver_attach+0x0/0x50 [c01fac73] bus_add_driver+0x83/0xe0 [c01ba08d] pci_register_driver+0x6d/0x90 [f897e00f] alsa_card_cs46xx_init+0xf/0x13 [snd_cs46xx] [c012efb1] sys_init_module+0x141/0x1d0 [c0102c95] syscall_call+0x7/0xb Code: 08 8b 3a c7 44 8c 1c 00 00 00 00 49 89 4c 24 14 8d 2c 89 8d b6 00 00 00 00 8b 44 24 10 89 e9 8d 54 24 18 d3 f8 89 44 24 0c 89 c6 8b 07 83 e6 1f c7 44 24 04 20 00 00 00 89 14 24 89 74 24 08 f7 2.6.13-rc3-git9 is OK. I'll try poking around at the ALSA changes, see if I can figure out which one is the culprit. thx, -cp -- Democracy can learn some things from Communism; for example, when a Communist politician is through, he is through. -- Unknown - 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/
SMP boot failure, Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00
Not subscribed, so please forgive the unthreaded post. As per K.R. Foley's report, booting on SMP fails. I tried & failed to capture the boot messages via serial, so the best I can offer is a pic of what remained visible on screen at the death. <http://www.graggrag.com/rt/rt-V0.7.41-00-20050320.jpg> I suspect there was more prior to that, but so far that's the best I can offer. Booting with maxcpus=1 didn't fail completely, but also suffered dramas. Loss of usb mouse was the most noticable. If that scenario might be interesting or helpful, I'll pursue it further. cheers, Cal - 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/
SMP boot failure, Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00
Not subscribed, so please forgive the unthreaded post. As per K.R. Foley's report, booting on SMP fails. I tried failed to capture the boot messages via serial, so the best I can offer is a pic of what remained visible on screen at the death. http://www.graggrag.com/rt/rt-V0.7.41-00-20050320.jpg I suspect there was more prior to that, but so far that's the best I can offer. Booting with maxcpus=1 didn't fail completely, but also suffered dramas. Loss of usb mouse was the most noticable. If that scenario might be interesting or helpful, I'll pursue it further. cheers, Cal - 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/
2.6.11-rc2-mm2 (& bk9) - rowdy little warn in drivers/usb/input/hid-input.c
With 2.6.11-rc2-mm2 & 2.6.11-rc2-bk9 and usb mouse, the warn("event
field not found") in drivers/usb/input/hid-input.c is hyperactive
whenever the mouse moves.
hihone kernel: drivers/usb/input/hid-input.c: event field not found
hihone last message repeated 619 times
hihone last message repeated 919 times
hihone last message repeated 1325 times
hihone last message repeated 1045 times
On the deviant case, both type and code appear to have the value 4 (if
that helps). The mouse reports as
hihone kernel: input: USB HID v1.00 Mouse [Microsoft Microsoft
IntelliMouse Optical] on usb-:00:07.2-2
cheers, Cal
(not subscribed, pls cc if needed)
-
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/
2.6.11-rc2-mm2 ( bk9) - rowdy little warn in drivers/usb/input/hid-input.c
With 2.6.11-rc2-mm2 2.6.11-rc2-bk9 and usb mouse, the warn(event field not found) in drivers/usb/input/hid-input.c is hyperactive whenever the mouse moves. hihone kernel: drivers/usb/input/hid-input.c: event field not found hihone last message repeated 619 times hihone last message repeated 919 times hihone last message repeated 1325 times hihone last message repeated 1045 times On the deviant case, both type and code appear to have the value 4 (if that helps). The mouse reports as hihone kernel: input: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouseAE Optical] on usb-:00:07.2-2 cheers, Cal (not subscribed, pls cc if needed) - 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, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D8
Ingo Molnar wrote: thanks, this pinpointed the bug - i've uploaded the -D8 patch to the usual place: http://redhat.com/~mingo/rt-limit-patches/ does it fix your crash? Mike Galbraith reported a crash too that i think could be the same one. Yep, with D8 and SMP the test completes successfully. cheers, Cal - 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, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D8
Ingo Molnar wrote: thanks, this pinpointed the bug - i've uploaded the -D8 patch to the usual place: http://redhat.com/~mingo/rt-limit-patches/ does it fix your crash? Mike Galbraith reported a crash too that i think could be the same one. Yep, with D8 and SMP the test completes successfully. cheers, Cal - 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: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7
Jack O'Quin wrote: You seem to have eliminated the mlock() failure as the cause of this crash. It should not have caused it anyway, but it *was* one noticeable difference between your tests and mine. Since do_page_fault() appears in the backtrace, that is useful to know. The other big difference is SMP. What happens if you build a UP kernel and run it on your SMP machine? Sorry for the delay, some sleep required. A build without SMP also fails, with multiple oops. <http://www.graggrag.com/200501271213-oops/>. cheers, Cal (NetEase AntiSpam+ at mail.edu.cn has been bouncing someone's copy) - 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: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7
Jack O'Quin wrote: I notice that JACK's call to mlockall() is failing. This is one difference between your system and mine (plus, my machine is UP). As an experiment, you might try testing with `ulimit -l unlimited'. I went for the panic retraction on the first report when I saw the failures in the log. With ulimit -l unlimited, jack seems happier. Before the change, ulimit -l showed 32. At what feels like approaching the end of the run, it still goes clunk - totally so, dead and gone! <http://www.graggrag.com/200501270420-oops/> I'll re-read the mails that have gone by, and think about the next step. cheers, Cal - 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: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7
Please ignore that, I've just started looking through the log properly. cheers. - 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: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7
Ingo Molnar wrote: [...] the -D7 patch available from the usual place: Hi, Consideringthe amount and rate of work in progress, this may well be no longer be pertinent, but I'm consistently getting an oops running the basic jack_test3.2 with rt-limit-2.6.11-rc2-D7 on SMP (P3 993 x 2). The oops and jacktest log are at <http://www.graggrag.com/20050127-oops/>. cheers, Cal - 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: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7
Ingo Molnar wrote: [...] the -D7 patch available from the usual place: Hi, Consideringthe amount and rate of work in progress, this may well be no longer be pertinent, but I'm consistently getting an oops running the basic jack_test3.2 with rt-limit-2.6.11-rc2-D7 on SMP (P3 993 x 2). The oops and jacktest log are at http://www.graggrag.com/20050127-oops/. cheers, Cal - 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: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7
Please ignore that, I've just started looking through the log properly. cheers. - 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: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7
Jack O'Quin wrote: I notice that JACK's call to mlockall() is failing. This is one difference between your system and mine (plus, my machine is UP). As an experiment, you might try testing with `ulimit -l unlimited'. I went for the panic retraction on the first report when I saw the failures in the log. With ulimit -l unlimited, jack seems happier. Before the change, ulimit -l showed 32. At what feels like approaching the end of the run, it still goes clunk - totally so, dead and gone! http://www.graggrag.com/200501270420-oops/ I'll re-read the mails that have gone by, and think about the next step. cheers, Cal - 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: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7
Jack O'Quin wrote: You seem to have eliminated the mlock() failure as the cause of this crash. It should not have caused it anyway, but it *was* one noticeable difference between your tests and mine. Since do_page_fault() appears in the backtrace, that is useful to know. The other big difference is SMP. What happens if you build a UP kernel and run it on your SMP machine? Sorry for the delay, some sleep required. A build without SMP also fails, with multiple oops. http://www.graggrag.com/200501271213-oops/. cheers, Cal (NetEase AntiSpam+ at mail.edu.cn has been bouncing someone's copy) - 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: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
Con Kolivas wrote: Comments and testing welcome. There's a collection of test summaries from jack_test3.2 runs at <http://www.graggrag.com/ck-tests/ck-tests-0501182249.txt> Tests were run with iso_cpu at 70, 90, 99, 100, each test was run twice. The discrepancies between consecutive runs (with same parameters) is puzzling. Also recorded were tests with SCHED_FIFO and SCHED_RR. Before drawing any hardball conclusions, verification of the results would be nice. At first glance, it does seem that we still have that fateful gap between "harm minimisation" (policy) and "zero tolerance" (audio reality requirement). cheers, Cal - 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: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
Con Kolivas wrote: Comments and testing welcome. There's a collection of test summaries from jack_test3.2 runs at http://www.graggrag.com/ck-tests/ck-tests-0501182249.txt Tests were run with iso_cpu at 70, 90, 99, 100, each test was run twice. The discrepancies between consecutive runs (with same parameters) is puzzling. Also recorded were tests with SCHED_FIFO and SCHED_RR. Before drawing any hardball conclusions, verification of the results would be nice. At first glance, it does seem that we still have that fateful gap between harm minimisation (policy) and zero tolerance (audio reality requirement). cheers, Cal - 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/
