Re: Realtime Preemption, 2.6.12, Beginners Guide?
Am Dienstag, 19. Juli 2005 17:19 schrieb Gene Heskett: > On Tuesday 19 July 2005 09:57, Ingo Molnar wrote: > >* Karsten Wiese <[EMAIL PROTECTED]> wrote: > >> > Found another error: > >> > the ioapic cache isn't fully initialized in -51-31's > >> > ioapic_cache_init(). > >> > >> and another: some NULL-pointers are used in -51-31 instead of > >> ioapic_data[0]. Please apply attached patch on top of -51-31. It > >> includes yesterday's fix. > > > >thanks, i've applied it and released -32. > > And this fixed ntpd (in mode 4) right up. But now Im seeing some > fussing from Xprint when its started, from my logs: > > Jul 19 10:59:58 coyote rc: Starting xprint: succeeded > Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 > Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 > Jul 19 10:59:59 coyote Xprt_33: lpstat: Unable to connect to server: > Connection refused > Jul 19 10:59:59 coyote Xprt_33: No matching visual for __GLcontextMode with > visual class = 0 (32775), nplanes = > 8 > Jul 19 11:00:00 coyote kernel: set_rtc_mmss: can't update from 7 to 59 > > The font path stuff I snipped has been there since forever. > And, I didn't get the set_rtc_mmss messages when I did a service xprint > restart. > And then it "xprinted" right away just fine? > Is this even connected to Xprint, that looks like something from maybe ntp? > "set_rtc_mmss: can't update from 7 to 59" is printk()ed from here: linux-2.6.12-RT/include/asm-i386/mach-default/mach_time.h /* * In order to set the CMOS clock precisely, set_rtc_mmss has to be * called 500 ms after the second nowtime has started, because when * nowtime is written into the registers of the CMOS clock, it will * jump to the next second precisely 500 ms later. Check the Motorola * MC146818A or Dallas DS12887 data sheet for details. * * BUG: This routine does not handle hour overflow properly; it just * sets the minutes. Usually you'll only notice that after reboot! */ static inline int mach_set_rtc_mmss(unsigned long nowtime) so its a rtc timingrelated. which PREEMPT_RT / mode 4 was the last one to do it on the fly ? > And of course in mode 4, tvtime has a blue screen. But you knew that. :) > what is tvtime supposed to do, is it a wine thing as in "bleu screen"? Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Tuesday 19 July 2005 09:57, Ingo Molnar wrote: >* Karsten Wiese <[EMAIL PROTECTED]> wrote: >> > Found another error: >> > the ioapic cache isn't fully initialized in -51-31's >> > ioapic_cache_init(). >> >> and another: some NULL-pointers are used in -51-31 instead of >> ioapic_data[0]. Please apply attached patch on top of -51-31. It >> includes yesterday's fix. > >thanks, i've applied it and released -32. And this fixed ntpd (in mode 4) right up. But now Im seeing some fussing from Xprint when its started, from my logs: Jul 19 10:59:58 coyote rc: Starting xprint: succeeded Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 Jul 19 10:59:59 coyote Xprt_33: lpstat: Unable to connect to server: Connection refused Jul 19 10:59:59 coyote Xprt_33: No matching visual for __GLcontextMode with visual class = 0 (32775), nplanes = 8 Jul 19 11:00:00 coyote kernel: set_rtc_mmss: can't update from 7 to 59 The font path stuff I snipped has been there since forever. And, I didn't get the set_rtc_mmss messages when I did a service xprint restart. Is this even connected to Xprint, that looks like something from maybe ntp? And of course in mode 4, tvtime has a blue screen. But you knew that. :) > Ingo >- >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/ -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime Preemption, 2.6.12, Beginners Guide?
* Karsten Wiese <[EMAIL PROTECTED]> wrote: > > Found another error: > > the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init(). > > > > > > and another: some NULL-pointers are used in -51-31 instead of > ioapic_data[0]. Please apply attached patch on top of -51-31. It > includes yesterday's fix. thanks, i've applied it and released -32. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Tuesday 19 July 2005 07:14, Karsten Wiese wrote: >Am Sonntag, 17. Juli 2005 14:07 schrieb Karsten Wiese: >> Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar: >> > * Karsten Wiese <[EMAIL PROTECTED]> wrote: >> > > Have I corrected the other path of ioapic early >> > > initialization, which had lacked virtual-address setup before >> > > ioapic_data[ioapic] was to be filled in -51-28? Please test >> > > attached patch on top of -51-29 or later. Also on Systems that >> > > liked -51-28. >> > >> > thanks - i've applied it to my tree and have released the -51-31 >> > patch. It looks good on my testboxes. >> >> Found another error: >> the ioapic cache isn't fully initialized in -51-31's >> ioapic_cache_init(). > >and another: some NULL-pointers are used in -51-31 instead of > ioapic_data[0]. Please apply attached patch on top of -51-31. It > includes yesterday's fix. > >Karsten I found yesterday, that a -31 build in mode 4 seems to do something to ntpd, it fails startup, and floods the log with bad file descriptor messages. I put some debugging echo's in the ntpd script but wasn't able to see any problems there. So I'm back to -30, in mode 3 ATM, so tvtime works. But everything else works far better in mode 4. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Am Sonntag, 17. Juli 2005 14:07 schrieb Karsten Wiese:
> Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar:
> >
> > * Karsten Wiese <[EMAIL PROTECTED]> wrote:
> >
> > > Have I corrected the other path of ioapic early initialization, which
> > > had lacked virtual-address setup before ioapic_data[ioapic] was to be
> > > filled in -51-28? Please test attached patch on top of -51-29 or
> > > later. Also on Systems that liked -51-28.
> >
> > thanks - i've applied it to my tree and have released the -51-31 patch.
> > It looks good on my testboxes.
> >
> Found another error:
> the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init().
>
>
and another: some NULL-pointers are used in -51-31 instead of ioapic_data[0].
Please apply attached patch on top of -51-31. It includes yesterday's fix.
Karsten
--- linux-2.6.12-RT-51-31/arch/i386/kernel/io_apic.c 2005-07-17 12:40:35.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/io_apic.c 2005-07-19 12:53:00.0 +0200
@@ -158,7 +158,7 @@
static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
{
int reg;
- for (reg = 0; reg < (ioapic->nr_registers + 10); reg++)
+ for (reg = 0; reg < (0x10 + 2 * ioapic->nr_registers); reg++)
ioapic->cached_val[reg] = __raw_io_apic_read(ioapic, reg);
}
# endif
@@ -1396,8 +1396,8 @@
* Add it to the IO-APIC irq-routing table:
*/
spin_lock_irqsave(_lock, flags);
- io_apic_write(0, 0x11+2*pin, *(((int *))+1));
- io_apic_write(0, 0x10+2*pin, *(((int *))+0));
+ io_apic_write(ioapic_data[0], 0x11+2*pin, *(((int *))+1));
+ io_apic_write(ioapic_data[0], 0x10+2*pin, *(((int *))+0));
spin_unlock_irqrestore(_lock, flags);
enable_8259A_irq(0);
@@ -2087,25 +2087,25 @@
* races.
*/
static struct hw_interrupt_type ioapic_edge_type = {
- .typename = "IO-APIC-edge",
+ .typename = "IO-APIC-edge",
.startup = startup_edge_ioapic,
.shutdown = shutdown_edge_ioapic,
.enable = enable_edge_ioapic,
.disable = disable_edge_ioapic,
.ack = ack_edge_ioapic,
.end = end_edge_ioapic,
- .set_affinity = set_ioapic_affinity,
+ .set_affinity = set_ioapic_affinity,
};
static struct hw_interrupt_type ioapic_level_type = {
- .typename = "IO-APIC-level",
+ .typename = "IO-APIC-level",
.startup = startup_level_ioapic,
.shutdown = shutdown_level_ioapic,
.enable = enable_level_ioapic,
.disable = disable_level_ioapic,
.ack = mask_and_ack_level_ioapic,
.end = end_level_ioapic,
- .set_affinity = set_ioapic_affinity,
+ .set_affinity = set_ioapic_affinity,
};
static inline void init_IO_APIC_traps(void)
@@ -2169,13 +2169,13 @@
static void end_lapic_irq (unsigned int i) { /* nothing */ }
static struct hw_interrupt_type lapic_irq_type = {
- .typename = "local-APIC-edge",
- .startup = NULL, /* startup_irq() not used for IRQ0 */
- .shutdown = NULL, /* shutdown_irq() not used for IRQ0 */
- .enable = enable_lapic_irq,
- .disable = disable_lapic_irq,
- .ack = ack_lapic_irq,
- .end = end_lapic_irq
+ .typename = "local-APIC-edge",
+ .startup = NULL, /* startup_irq() not used for IRQ0 */
+ .shutdown = NULL, /* shutdown_irq() not used for IRQ0 */
+ .enable = enable_lapic_irq,
+ .disable = disable_lapic_irq,
+ .ack = ack_lapic_irq,
+ .end = end_lapic_irq
};
static void setup_nmi (void)
@@ -2209,16 +2209,17 @@
struct IO_APIC_route_entry entry0, entry1;
unsigned char save_control, save_freq_select;
unsigned long flags;
+ struct ioapic_data_struct *ioapic0 = ioapic_data[0];
pin = find_isa_irq_pin(8, mp_INT);
if (pin == -1)
return;
spin_lock_irqsave(_lock, flags);
- *(((int *)) + 1) = io_apic_read(0, 0x11 + 2 * pin);
- *(((int *)) + 0) = io_apic_read(0, 0x10 + 2 * pin);
+ *(((int *)) + 1) = io_apic_read(ioapic0, 0x11 + 2 * pin);
+ *(((int *)) + 0) = io_apic_read(ioapic0, 0x10 + 2 * pin);
spin_unlock_irqrestore(_lock, flags);
- clear_IO_APIC_pin(0, pin);
+ clear_IO_APIC_pin(ioapic0, pin);
memset(, 0, sizeof(entry1));
@@ -2231,8 +2232,8 @@
entry1.vector = 0;
spin_lock_irqsave(_lock, flags);
- io_apic_write(0, 0x11 + 2 * pin, *(((int *)) + 1));
- io_apic_write(0, 0x10 + 2 * pin, *(((int *)) + 0));
+ io_apic_write(ioapic0, 0x11 + 2 * pin, *(((int *)) + 1));
+ io_apic_write(ioapic0, 0x10 + 2 * pin, *(((int *)) + 0));
spin_unlock_irqrestore(_lock, flags);
save_control = CMOS_READ(RTC_CONTROL);
@@ -2250,11 +2251,11 @@
CMOS_WRITE(save_control, RTC_CONTROL);
CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
- clear_IO_APIC_pin(0, pin);
+ clear_IO_APIC_pin(ioapic0, pin);
spin_lock_irqsave(_lock, flags);
- io_apic_write(0, 0x11 + 2 * pin, *(((int *)) + 1));
- io_apic_write(0, 0x10 + 2 * pin, *(((int *)) + 0));
+ io_apic_write(ioapic0, 0x11 + 2 * pin, *(((int *)) + 1));
+ io_apic_write(ioapic0, 0x10 + 2 * pin, *(((int *)) + 0));
spin_unlock_irqrestore(_lock, flags);
}
@@ -2268,6 +2269,7 @@
{
int pin1, pin2;
int vector;
+ struct ioapic_data_struct *ioapic0 = ioapic_data[0];
/*
* get/set the timer IRQ
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Am Sonntag, 17. Juli 2005 14:07 schrieb Karsten Wiese:
Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar:
* Karsten Wiese [EMAIL PROTECTED] wrote:
Have I corrected the other path of ioapic early initialization, which
had lacked virtual-address setup before ioapic_data[ioapic] was to be
filled in -51-28? Please test attached patch on top of -51-29 or
later. Also on Systems that liked -51-28.
thanks - i've applied it to my tree and have released the -51-31 patch.
It looks good on my testboxes.
Found another error:
the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init().
snip
and another: some NULL-pointers are used in -51-31 instead of ioapic_data[0].
Please apply attached patch on top of -51-31. It includes yesterday's fix.
Karsten
--- linux-2.6.12-RT-51-31/arch/i386/kernel/io_apic.c 2005-07-17 12:40:35.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/io_apic.c 2005-07-19 12:53:00.0 +0200
@@ -158,7 +158,7 @@
static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
{
int reg;
- for (reg = 0; reg (ioapic-nr_registers + 10); reg++)
+ for (reg = 0; reg (0x10 + 2 * ioapic-nr_registers); reg++)
ioapic-cached_val[reg] = __raw_io_apic_read(ioapic, reg);
}
# endif
@@ -1396,8 +1396,8 @@
* Add it to the IO-APIC irq-routing table:
*/
spin_lock_irqsave(ioapic_lock, flags);
- io_apic_write(0, 0x11+2*pin, *(((int *)entry)+1));
- io_apic_write(0, 0x10+2*pin, *(((int *)entry)+0));
+ io_apic_write(ioapic_data[0], 0x11+2*pin, *(((int *)entry)+1));
+ io_apic_write(ioapic_data[0], 0x10+2*pin, *(((int *)entry)+0));
spin_unlock_irqrestore(ioapic_lock, flags);
enable_8259A_irq(0);
@@ -2087,25 +2087,25 @@
* races.
*/
static struct hw_interrupt_type ioapic_edge_type = {
- .typename = IO-APIC-edge,
+ .typename = IO-APIC-edge,
.startup = startup_edge_ioapic,
.shutdown = shutdown_edge_ioapic,
.enable = enable_edge_ioapic,
.disable = disable_edge_ioapic,
.ack = ack_edge_ioapic,
.end = end_edge_ioapic,
- .set_affinity = set_ioapic_affinity,
+ .set_affinity = set_ioapic_affinity,
};
static struct hw_interrupt_type ioapic_level_type = {
- .typename = IO-APIC-level,
+ .typename = IO-APIC-level,
.startup = startup_level_ioapic,
.shutdown = shutdown_level_ioapic,
.enable = enable_level_ioapic,
.disable = disable_level_ioapic,
.ack = mask_and_ack_level_ioapic,
.end = end_level_ioapic,
- .set_affinity = set_ioapic_affinity,
+ .set_affinity = set_ioapic_affinity,
};
static inline void init_IO_APIC_traps(void)
@@ -2169,13 +2169,13 @@
static void end_lapic_irq (unsigned int i) { /* nothing */ }
static struct hw_interrupt_type lapic_irq_type = {
- .typename = local-APIC-edge,
- .startup = NULL, /* startup_irq() not used for IRQ0 */
- .shutdown = NULL, /* shutdown_irq() not used for IRQ0 */
- .enable = enable_lapic_irq,
- .disable = disable_lapic_irq,
- .ack = ack_lapic_irq,
- .end = end_lapic_irq
+ .typename = local-APIC-edge,
+ .startup = NULL, /* startup_irq() not used for IRQ0 */
+ .shutdown = NULL, /* shutdown_irq() not used for IRQ0 */
+ .enable = enable_lapic_irq,
+ .disable = disable_lapic_irq,
+ .ack = ack_lapic_irq,
+ .end = end_lapic_irq
};
static void setup_nmi (void)
@@ -2209,16 +2209,17 @@
struct IO_APIC_route_entry entry0, entry1;
unsigned char save_control, save_freq_select;
unsigned long flags;
+ struct ioapic_data_struct *ioapic0 = ioapic_data[0];
pin = find_isa_irq_pin(8, mp_INT);
if (pin == -1)
return;
spin_lock_irqsave(ioapic_lock, flags);
- *(((int *)entry0) + 1) = io_apic_read(0, 0x11 + 2 * pin);
- *(((int *)entry0) + 0) = io_apic_read(0, 0x10 + 2 * pin);
+ *(((int *)entry0) + 1) = io_apic_read(ioapic0, 0x11 + 2 * pin);
+ *(((int *)entry0) + 0) = io_apic_read(ioapic0, 0x10 + 2 * pin);
spin_unlock_irqrestore(ioapic_lock, flags);
- clear_IO_APIC_pin(0, pin);
+ clear_IO_APIC_pin(ioapic0, pin);
memset(entry1, 0, sizeof(entry1));
@@ -2231,8 +2232,8 @@
entry1.vector = 0;
spin_lock_irqsave(ioapic_lock, flags);
- io_apic_write(0, 0x11 + 2 * pin, *(((int *)entry1) + 1));
- io_apic_write(0, 0x10 + 2 * pin, *(((int *)entry1) + 0));
+ io_apic_write(ioapic0, 0x11 + 2 * pin, *(((int *)entry1) + 1));
+ io_apic_write(ioapic0, 0x10 + 2 * pin, *(((int *)entry1) + 0));
spin_unlock_irqrestore(ioapic_lock, flags);
save_control = CMOS_READ(RTC_CONTROL);
@@ -2250,11 +2251,11 @@
CMOS_WRITE(save_control, RTC_CONTROL);
CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
- clear_IO_APIC_pin(0, pin);
+ clear_IO_APIC_pin(ioapic0, pin);
spin_lock_irqsave(ioapic_lock, flags);
- io_apic_write(0, 0x11 + 2 * pin, *(((int *)entry0) + 1));
- io_apic_write(0, 0x10 + 2 * pin, *(((int *)entry0) + 0));
+ io_apic_write(ioapic0, 0x11 + 2 * pin, *(((int *)entry0) + 1));
+ io_apic_write(ioapic0, 0x10 + 2 * pin, *(((int *)entry0) + 0));
spin_unlock_irqrestore(ioapic_lock, flags);
}
@@ -2268,6 +2269,7 @@
{
int pin1, pin2;
int
Re: Realtime Preemption, 2.6.12, Beginners Guide?
On Tuesday 19 July 2005 07:14, Karsten Wiese wrote: Am Sonntag, 17. Juli 2005 14:07 schrieb Karsten Wiese: Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar: * Karsten Wiese [EMAIL PROTECTED] wrote: Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks - i've applied it to my tree and have released the -51-31 patch. It looks good on my testboxes. Found another error: the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init(). snip and another: some NULL-pointers are used in -51-31 instead of ioapic_data[0]. Please apply attached patch on top of -51-31. It includes yesterday's fix. Karsten I found yesterday, that a -31 build in mode 4 seems to do something to ntpd, it fails startup, and floods the log with bad file descriptor messages. I put some debugging echo's in the ntpd script but wasn't able to see any problems there. So I'm back to -30, in mode 3 ATM, so tvtime works. But everything else works far better in mode 4. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime Preemption, 2.6.12, Beginners Guide?
* Karsten Wiese [EMAIL PROTECTED] wrote: Found another error: the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init(). snip and another: some NULL-pointers are used in -51-31 instead of ioapic_data[0]. Please apply attached patch on top of -51-31. It includes yesterday's fix. thanks, i've applied it and released -32. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Tuesday 19 July 2005 09:57, Ingo Molnar wrote: * Karsten Wiese [EMAIL PROTECTED] wrote: Found another error: the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init(). snip and another: some NULL-pointers are used in -51-31 instead of ioapic_data[0]. Please apply attached patch on top of -51-31. It includes yesterday's fix. thanks, i've applied it and released -32. And this fixed ntpd (in mode 4) right up. But now Im seeing some fussing from Xprint when its started, from my logs: Jul 19 10:59:58 coyote rc: Starting xprint: succeeded Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 Jul 19 10:59:59 coyote Xprt_33: lpstat: Unable to connect to server: Connection refused Jul 19 10:59:59 coyote Xprt_33: No matching visual for __GLcontextMode with visual class = 0 (32775), nplanes = 8 Jul 19 11:00:00 coyote kernel: set_rtc_mmss: can't update from 7 to 59 The font path stuff I snipped has been there since forever. And, I didn't get the set_rtc_mmss messages when I did a service xprint restart. Is this even connected to Xprint, that looks like something from maybe ntp? And of course in mode 4, tvtime has a blue screen. But you knew that. :) Ingo - 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/ -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Am Dienstag, 19. Juli 2005 17:19 schrieb Gene Heskett: On Tuesday 19 July 2005 09:57, Ingo Molnar wrote: * Karsten Wiese [EMAIL PROTECTED] wrote: Found another error: the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init(). snip and another: some NULL-pointers are used in -51-31 instead of ioapic_data[0]. Please apply attached patch on top of -51-31. It includes yesterday's fix. thanks, i've applied it and released -32. And this fixed ntpd (in mode 4) right up. But now Im seeing some fussing from Xprint when its started, from my logs: Jul 19 10:59:58 coyote rc: Starting xprint: succeeded Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 Jul 19 10:59:59 coyote Xprt_33: lpstat: Unable to connect to server: Connection refused Jul 19 10:59:59 coyote Xprt_33: No matching visual for __GLcontextMode with visual class = 0 (32775), nplanes = 8 Jul 19 11:00:00 coyote kernel: set_rtc_mmss: can't update from 7 to 59 The font path stuff I snipped has been there since forever. And, I didn't get the set_rtc_mmss messages when I did a service xprint restart. And then it xprinted right away just fine? Is this even connected to Xprint, that looks like something from maybe ntp? set_rtc_mmss: can't update from 7 to 59 is printk()ed from here: linux-2.6.12-RT/include/asm-i386/mach-default/mach_time.h snip /* * In order to set the CMOS clock precisely, set_rtc_mmss has to be * called 500 ms after the second nowtime has started, because when * nowtime is written into the registers of the CMOS clock, it will * jump to the next second precisely 500 ms later. Check the Motorola * MC146818A or Dallas DS12887 data sheet for details. * * BUG: This routine does not handle hour overflow properly; it just * sets the minutes. Usually you'll only notice that after reboot! */ static inline int mach_set_rtc_mmss(unsigned long nowtime) /snip so its a rtc timingrelated. which PREEMPT_RT / mode 4 was the last one to do it on the fly ? And of course in mode 4, tvtime has a blue screen. But you knew that. :) what is tvtime supposed to do, is it a wine thing as in bleu screen? Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - 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: Realtime Preemption, 2.6.12, Beginners Guide?
Karsten Wiese wrote: Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar: * Karsten Wiese <[EMAIL PROTECTED]> wrote: Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks - i've applied it to my tree and have released the -51-31 patch. It looks good on my testboxes. Found another error: the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init(). Please apply attached patch on top of -51-31. Karsten I have this successfully booted on both of my SMP boxes now. -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
Karsten Wiese wrote: Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar: * Karsten Wiese [EMAIL PROTECTED] wrote: Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks - i've applied it to my tree and have released the -51-31 patch. It looks good on my testboxes. Found another error: the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init(). Please apply attached patch on top of -51-31. Karsten I have this successfully booted on both of my SMP boxes now. -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar:
>
> * Karsten Wiese <[EMAIL PROTECTED]> wrote:
>
> > Have I corrected the other path of ioapic early initialization, which
> > had lacked virtual-address setup before ioapic_data[ioapic] was to be
> > filled in -51-28? Please test attached patch on top of -51-29 or
> > later. Also on Systems that liked -51-28.
>
> thanks - i've applied it to my tree and have released the -51-31 patch.
> It looks good on my testboxes.
>
Found another error:
the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init().
Please apply attached patch on top of -51-31.
Karsten
--- linux-2.6.12-RT-51-31/arch/i386/kernel/io_apic.c 2005-07-17 12:40:35.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/io_apic.c 2005-07-17 13:33:06.0 +0200
@@ -158,7 +158,7 @@
static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
{
int reg;
- for (reg = 0; reg < (ioapic->nr_registers + 10); reg++)
+ for (reg = 0; reg < (0x10 + 2 * ioapic->nr_registers); reg++)
ioapic->cached_val[reg] = __raw_io_apic_read(ioapic, reg);
}
# endif
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar:
* Karsten Wiese [EMAIL PROTECTED] wrote:
Have I corrected the other path of ioapic early initialization, which
had lacked virtual-address setup before ioapic_data[ioapic] was to be
filled in -51-28? Please test attached patch on top of -51-29 or
later. Also on Systems that liked -51-28.
thanks - i've applied it to my tree and have released the -51-31 patch.
It looks good on my testboxes.
Found another error:
the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init().
Please apply attached patch on top of -51-31.
Karsten
--- linux-2.6.12-RT-51-31/arch/i386/kernel/io_apic.c 2005-07-17 12:40:35.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/io_apic.c 2005-07-17 13:33:06.0 +0200
@@ -158,7 +158,7 @@
static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
{
int reg;
- for (reg = 0; reg (ioapic-nr_registers + 10); reg++)
+ for (reg = 0; reg (0x10 + 2 * ioapic-nr_registers); reg++)
ioapic-cached_val[reg] = __raw_io_apic_read(ioapic, reg);
}
# endif
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Ingo Molnar wrote: > * Karsten Wiese <[EMAIL PROTECTED]> wrote: > > >>Have I corrected the other path of ioapic early initialization, which >>had lacked virtual-address setup before ioapic_data[ioapic] was to be >>filled in -51-28? Please test attached patch on top of -51-29 or >>later. Also on Systems that liked -51-28. > > > thanks - i've applied it to my tree and have released the -51-31 patch. > It looks good on my testboxes. > > Ingo > I have booted this on my older SMP system (the one that wouldn't boot -51-28) as well as an older duron box and thus far all is well. -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Karsten Wiese <[EMAIL PROTECTED]> wrote: > Have I corrected the other path of ioapic early initialization, which > had lacked virtual-address setup before ioapic_data[ioapic] was to be > filled in -51-28? Please test attached patch on top of -51-29 or > later. Also on Systems that liked -51-28. thanks - i've applied it to my tree and have released the -51-31 patch. It looks good on my testboxes. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Karsten Wiese [EMAIL PROTECTED] wrote: Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks - i've applied it to my tree and have released the -51-31 patch. It looks good on my testboxes. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
Ingo Molnar wrote: * Karsten Wiese [EMAIL PROTECTED] wrote: Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks - i've applied it to my tree and have released the -51-31 patch. It looks good on my testboxes. Ingo I have booted this on my older SMP system (the one that wouldn't boot -51-28) as well as an older duron box and thus far all is well. -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Thursday 14 Jul 2005 21:16, Lee Revell wrote: > On Thu, 2005-07-14 at 20:58 +0100, Alistair John Strachan wrote: > > the responsiveness of our instrument to 300us which is low enough > > for the real-time PCR industry > > PCR, as in polymerase chain reaction? They can do that in realtime? > Impressive. > > Lee Yes, and yes. And it is impressive. And Linux will power a major instrument in the future. -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student:CS/CSim Undergraduate contact:1F2 55 South Clerk Street, Edinburgh. EH8 9PP. - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Thursday 14 Jul 2005 21:16, Lee Revell wrote: On Thu, 2005-07-14 at 20:58 +0100, Alistair John Strachan wrote: the responsiveness of our instrument to 300us which is low enough for the real-time PCR industry PCR, as in polymerase chain reaction? They can do that in realtime? Impressive. Lee Yes, and yes. And it is impressive. And Linux will power a major instrument in the future. -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student:CS/CSim Undergraduate contact:1F2 55 South Clerk Street, Edinburgh. EH8 9PP. - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Thu, 2005-07-14 at 20:58 +0100, Alistair John Strachan wrote: > the responsiveness of our instrument to 300us which is low enough > for the real-time PCR industry PCR, as in polymerase chain reaction? They can do that in realtime? Impressive. Lee - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Wednesday 13 Jul 2005 16:30, Ingo Molnar wrote: > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > it worked upon the first try, and indeed my testbox crashed within 10 > > seconds: > > > > BUG: Unable to handle kernel NULL pointer dereference > > BUG: Unable to handle kernel NULL pointer dereference at virtual address > > 0006 > > a couple of crashes later i got an important clue: > > BUG: bad soft irq-flag value 0f64, openvpn/3386! > [] dump_stack+0x1f/0x21 (20) > [] check_soft_flags+0x73/0xc9 (24) > [<0f78>] 0xf78 (1066836133) > > it turns out that a small portion of the softirq processing path was > still using the soft IRQ-flag, instead of the raw IRQ-flag! Given enough > irq and softirq workload, we were interrupted in a piece of code where > the data structure was inconsistent. (tinfo.task was already changed, > but %esp not yet) Since interrupts were enabled during the crash > printout, it would crash again and again as it got more interrupts. The > backtrace printout crashed too due to the inconsistency. That's why you > got those repeat = lines. > > the patch below should fix this bug and i've uploaded the -51-30 patch > with this fix included. Could you check whether 4K stacks are now stable > for you under PREEMPT_RT? > > so your intuitition about this being related to 4K stacks was completely > right. > Ingo, This fixes the issue. It's one more 'crossed t' on the rt-preempt patches. I'll let you know if I discover anything else; your work has already allowed us to bring the responsiveness of our instrument to 300us which is low enough for the real-time PCR industry. Thanks a lot! This debugging process has been extremely eye opening, thanks for the detailed descriptions of what's gone wrong at every stage. I just wish I was competent enough to fix these things myself. -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student:CS/CSim Undergraduate contact:1F2 55 South Clerk Street, Edinburgh. EH8 9PP. - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Thu, 14 Jul 2005, Karsten Wiese wrote: Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks, Karsten I applied your patch on top of -51-30 and all is well. I am applied it on top of -51-29 just for the heck of it and it's working well too, FWIW. -- Charles D. (Chuck) Harding <[EMAIL PROTECTED]> Voice: 925-423-8879 Senior Computer Associate ICCDFax: 925-423-6961 Lawrence Livermore National Laboratory Computation Directorate Livermore, CA USA http://www.llnl.gov GPG Public Key ID: B9EB6601 -- http://tinyurl.com/5w5ey --- -- Too bad stupidity isn't painful. -- - 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: Realtime Preemption, 2.6.12, Beginners Guide?
K.R. Foley wrote: K.R. Foley wrote: Karsten Wiese wrote: Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley: Ingo Molnar wrote: * Chuck Harding <[EMAIL PROTECTED]> wrote: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo I too had the same problem booting -51-28 on my older SMP system at home. -51-29 just booted fine. Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks, Karsten Karsten, Just booted on my 2.6 dual Xeon w/HT and thus far all is well. I am still building on the older SMP system that didn't like -51-28. Will report after I try booting that one. Just booted on my older SMP box that barfed on -51-28. It would appear that the init problem is resolved. DOH! All of the above is on -51-30 with Karsten's patch applied. -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
K.R. Foley wrote: Karsten Wiese wrote: Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley: Ingo Molnar wrote: * Chuck Harding <[EMAIL PROTECTED]> wrote: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo I too had the same problem booting -51-28 on my older SMP system at home. -51-29 just booted fine. Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks, Karsten Karsten, Just booted on my 2.6 dual Xeon w/HT and thus far all is well. I am still building on the older SMP system that didn't like -51-28. Will report after I try booting that one. Just booted on my older SMP box that barfed on -51-28. It would appear that the init problem is resolved. -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
Karsten Wiese wrote: Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley: Ingo Molnar wrote: * Chuck Harding <[EMAIL PROTECTED]> wrote: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo I too had the same problem booting -51-28 on my older SMP system at home. -51-29 just booted fine. Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks, Karsten Karsten, Just booted on my 2.6 dual Xeon w/HT and thus far all is well. I am still building on the older SMP system that didn't like -51-28. Will report after I try booting that one. -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
Ingo Molnar wrote: * Chuck Harding <[EMAIL PROTECTED]> wrote: I missed getting -51-29 but just booted up -51-30 and all is well. Thanks. Just out of curiosity, what was changed between -51-28, 29, and 30? -51-29 had new IO-APIC optimizations - and i reverted them in -51-30. Ingo Ingo, I just noticed that the keyboard repeat problem is back in a bad way in -51-30. I was not seeing this before I left this PC about 16 hours ago. And the uptime is: 08:34:10 up 18:46, 7 users, load average: 3.32, 3.24, 2.53 -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
> Ingo Molnar wrote:
> > * Chuck Harding <[EMAIL PROTECTED]> wrote:
> >
> >
> >>>CC [M] sound/oss/emu10k1/midi.o
> >>>sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__'
> >>>sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token
> >>>
> >>>Here's the offending line:
> >>>
> >>> 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused)));
> >>>
> >>>Lee
> >>>
> >>
> >>I got it to compile but it won't boot - it hangs right after the
> >>'Uncompressing Linux... OK, booting the kernel' - I'm using .config
> >>from 51-27 (attached)
> >
> >
> > and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic
> > changes undone (will re-apply them once Karsten has figured out what's
> > wrong).
> >
> > Ingo
>
> I too had the same problem booting -51-28 on my older SMP system at
> home. -51-29 just booted fine.
>
Have I corrected the other path of ioapic early initialization, which had lacked
virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28?
Please test attached patch on top of -51-29 or later.
Also on Systems that liked -51-28.
thanks, Karsten
diff -ur ../linux-2.6.12-RT-51-23/arch/i386/kernel/apic.c ./arch/i386/kernel/apic.c
--- ../linux-2.6.12-RT-51-23/arch/i386/kernel/apic.c 2005-07-14 12:31:33.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/apic.c 2005-07-14 12:34:53.0 +0200
@@ -832,10 +832,10 @@
ioapic_phys = (unsigned long)
alloc_bootmem_pages(PAGE_SIZE);
ioapic_phys = __pa(ioapic_phys);
+set_fixmap_nocache(idx, ioapic_phys);
+printk(KERN_DEBUG "faked IOAPIC to %08lx (%08lx)\n",
+ __fix_to_virt(idx), ioapic_phys);
}
- set_fixmap_nocache(idx, ioapic_phys);
- printk(KERN_DEBUG "mapped IOAPIC to %08lx (%08lx)\n",
- __fix_to_virt(idx), ioapic_phys);
idx++;
}
}
diff -ur ../linux-2.6.12-RT-51-23/arch/i386/kernel/io_apic.c ./arch/i386/kernel/io_apic.c
--- ../linux-2.6.12-RT-51-23/arch/i386/kernel/io_apic.c 2005-07-09 23:49:21.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/io_apic.c 2005-07-14 12:34:54.0 +0200
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -55,11 +56,6 @@
int sis_apic_bug = -1;
/*
- * # of IRQ routing registers
- */
-int nr_ioapic_registers[MAX_IO_APICS];
-
-/*
* Rough estimation of how many shared IRQs there are, can
* be changed anytime.
*/
@@ -132,88 +128,74 @@
# define IOAPIC_CACHE
#endif
-#ifdef IOAPIC_CACHE
-# define MAX_IOAPIC_CACHE 512
-/*
- * Cache register values:
- */
-static struct {
- unsigned int reg;
- unsigned int val[MAX_IOAPIC_CACHE];
-} io_apic_cache[MAX_IO_APICS]
- cacheline_aligned_in_smp;
+
+struct ioapic_data_struct {
+ struct sys_device dev;
+ int nr_registers; // # of IRQ routing registers
+ volatile unsigned int *base;
+ struct IO_APIC_route_entry *entry;
+#ifdef IOAPIC_CACHE
+ unsigned int reg_set;
+ u32 cached_val[0];
#endif
+};
-volatile unsigned int *io_apic_base[MAX_IO_APICS];
+static struct ioapic_data_struct *ioapic_data[MAX_IO_APICS];
-static inline unsigned int __raw_io_apic_read(unsigned int apic, unsigned int reg)
+
+static inline unsigned int __raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
{
- volatile unsigned int *io_apic;
-#ifdef IOAPIC_CACHE
- io_apic_cache[apic].reg = reg;
-#endif
- io_apic = io_apic_base[apic];
- io_apic[0] = reg;
- return io_apic[4];
+# ifdef IOAPIC_CACHE
+ ioapic->reg_set = reg;
+# endif
+ ioapic->base[0] = reg;
+ return ioapic->base[4];
}
-unsigned int raw_io_apic_read(unsigned int apic, unsigned int reg)
+
+# ifdef IOAPIC_CACHE
+static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
{
- unsigned int val = __raw_io_apic_read(apic, reg);
+ int reg;
+ for (reg = 0; reg < (ioapic->nr_registers + 10); reg++)
+ ioapic->cached_val[reg] = __raw_io_apic_read(ioapic, reg);
+}
+# endif
-#ifdef IOAPIC_CACHE
- io_apic_cache[apic].val[reg] = val;
-#endif
+
+static unsigned int raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
+{
+ unsigned int val = __raw_io_apic_read(ioapic, reg);
+
+# ifdef IOAPIC_CACHE
+ ioapic->cached_val[reg] = val;
+# endif
return val;
}
-unsigned int io_apic_read(unsigned int apic, unsigned int reg)
+static unsigned int io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
{
-#ifdef IOAPIC_CACHE
- if (unlikely(reg >= MAX_IOAPIC_CACHE)) {
- static int once = 1;
-
- if (once) {
- once = 0;
- printk("WARNING: ioapic register cache overflow: %d.\n",
-reg);
- dump_stack();
- }
- return __raw_io_apic_read(apic, reg);
- }
- if (io_apic_cache[apic].val[reg] && !sis_apic_bug) {
- io_apic_cache[apic].reg = -1;
- return io_apic_cache[apic].val[reg];
+# ifdef IOAPIC_CACHE
+ if (likely(!sis_apic_bug)) {
+ ioapic->reg_set = -1;
+ return ioapic->cached_val[reg];
}
-#endif
- return raw_io_apic_read(apic, reg);
+# endif
+ return
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
Ingo Molnar wrote:
* Chuck Harding [EMAIL PROTECTED] wrote:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__'
sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token
Here's the offending line:
48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused)));
Lee
I got it to compile but it won't boot - it hangs right after the
'Uncompressing Linux... OK, booting the kernel' - I'm using .config
from 51-27 (attached)
and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic
changes undone (will re-apply them once Karsten has figured out what's
wrong).
Ingo
I too had the same problem booting -51-28 on my older SMP system at
home. -51-29 just booted fine.
Have I corrected the other path of ioapic early initialization, which had lacked
virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28?
Please test attached patch on top of -51-29 or later.
Also on Systems that liked -51-28.
thanks, Karsten
diff -ur ../linux-2.6.12-RT-51-23/arch/i386/kernel/apic.c ./arch/i386/kernel/apic.c
--- ../linux-2.6.12-RT-51-23/arch/i386/kernel/apic.c 2005-07-14 12:31:33.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/apic.c 2005-07-14 12:34:53.0 +0200
@@ -832,10 +832,10 @@
ioapic_phys = (unsigned long)
alloc_bootmem_pages(PAGE_SIZE);
ioapic_phys = __pa(ioapic_phys);
+set_fixmap_nocache(idx, ioapic_phys);
+printk(KERN_DEBUG faked IOAPIC to %08lx (%08lx)\n,
+ __fix_to_virt(idx), ioapic_phys);
}
- set_fixmap_nocache(idx, ioapic_phys);
- printk(KERN_DEBUG mapped IOAPIC to %08lx (%08lx)\n,
- __fix_to_virt(idx), ioapic_phys);
idx++;
}
}
diff -ur ../linux-2.6.12-RT-51-23/arch/i386/kernel/io_apic.c ./arch/i386/kernel/io_apic.c
--- ../linux-2.6.12-RT-51-23/arch/i386/kernel/io_apic.c 2005-07-09 23:49:21.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/io_apic.c 2005-07-14 12:34:54.0 +0200
@@ -31,6 +31,7 @@
#include linux/mc146818rtc.h
#include linux/compiler.h
#include linux/acpi.h
+#include linux/bootmem.h
#include linux/sysdev.h
#include asm/io.h
@@ -55,11 +56,6 @@
int sis_apic_bug = -1;
/*
- * # of IRQ routing registers
- */
-int nr_ioapic_registers[MAX_IO_APICS];
-
-/*
* Rough estimation of how many shared IRQs there are, can
* be changed anytime.
*/
@@ -132,88 +128,74 @@
# define IOAPIC_CACHE
#endif
-#ifdef IOAPIC_CACHE
-# define MAX_IOAPIC_CACHE 512
-/*
- * Cache register values:
- */
-static struct {
- unsigned int reg;
- unsigned int val[MAX_IOAPIC_CACHE];
-} io_apic_cache[MAX_IO_APICS]
- cacheline_aligned_in_smp;
+
+struct ioapic_data_struct {
+ struct sys_device dev;
+ int nr_registers; // # of IRQ routing registers
+ volatile unsigned int *base;
+ struct IO_APIC_route_entry *entry;
+#ifdef IOAPIC_CACHE
+ unsigned int reg_set;
+ u32 cached_val[0];
#endif
+};
-volatile unsigned int *io_apic_base[MAX_IO_APICS];
+static struct ioapic_data_struct *ioapic_data[MAX_IO_APICS];
-static inline unsigned int __raw_io_apic_read(unsigned int apic, unsigned int reg)
+
+static inline unsigned int __raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
{
- volatile unsigned int *io_apic;
-#ifdef IOAPIC_CACHE
- io_apic_cache[apic].reg = reg;
-#endif
- io_apic = io_apic_base[apic];
- io_apic[0] = reg;
- return io_apic[4];
+# ifdef IOAPIC_CACHE
+ ioapic-reg_set = reg;
+# endif
+ ioapic-base[0] = reg;
+ return ioapic-base[4];
}
-unsigned int raw_io_apic_read(unsigned int apic, unsigned int reg)
+
+# ifdef IOAPIC_CACHE
+static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
{
- unsigned int val = __raw_io_apic_read(apic, reg);
+ int reg;
+ for (reg = 0; reg (ioapic-nr_registers + 10); reg++)
+ ioapic-cached_val[reg] = __raw_io_apic_read(ioapic, reg);
+}
+# endif
-#ifdef IOAPIC_CACHE
- io_apic_cache[apic].val[reg] = val;
-#endif
+
+static unsigned int raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
+{
+ unsigned int val = __raw_io_apic_read(ioapic, reg);
+
+# ifdef IOAPIC_CACHE
+ ioapic-cached_val[reg] = val;
+# endif
return val;
}
-unsigned int io_apic_read(unsigned int apic, unsigned int reg)
+static unsigned int io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
{
-#ifdef IOAPIC_CACHE
- if (unlikely(reg = MAX_IOAPIC_CACHE)) {
- static int once = 1;
-
- if (once) {
- once = 0;
- printk(WARNING: ioapic register cache overflow: %d.\n,
-reg);
- dump_stack();
- }
- return __raw_io_apic_read(apic, reg);
- }
- if (io_apic_cache[apic].val[reg] !sis_apic_bug) {
- io_apic_cache[apic].reg = -1;
- return io_apic_cache[apic].val[reg];
+# ifdef IOAPIC_CACHE
+ if (likely(!sis_apic_bug)) {
+ ioapic-reg_set = -1;
+ return ioapic-cached_val[reg];
}
-#endif
- return raw_io_apic_read(apic, reg);
+# endif
+ return raw_io_apic_read(ioapic,
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Ingo Molnar wrote: * Chuck Harding [EMAIL PROTECTED] wrote: I missed getting -51-29 but just booted up -51-30 and all is well. Thanks. Just out of curiosity, what was changed between -51-28, 29, and 30? -51-29 had new IO-APIC optimizations - and i reverted them in -51-30. Ingo Ingo, I just noticed that the keyboard repeat problem is back in a bad way in -51-30. I was not seeing this before I left this PC about 16 hours ago. And the uptime is: 08:34:10 up 18:46, 7 users, load average: 3.32, 3.24, 2.53 -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
Karsten Wiese wrote: Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley: Ingo Molnar wrote: * Chuck Harding [EMAIL PROTECTED] wrote: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo I too had the same problem booting -51-28 on my older SMP system at home. -51-29 just booted fine. Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks, Karsten Karsten, Just booted on my 2.6 dual Xeon w/HT and thus far all is well. I am still building on the older SMP system that didn't like -51-28. Will report after I try booting that one. snip -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
K.R. Foley wrote: K.R. Foley wrote: Karsten Wiese wrote: Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley: Ingo Molnar wrote: * Chuck Harding [EMAIL PROTECTED] wrote: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo I too had the same problem booting -51-28 on my older SMP system at home. -51-29 just booted fine. Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks, Karsten Karsten, Just booted on my 2.6 dual Xeon w/HT and thus far all is well. I am still building on the older SMP system that didn't like -51-28. Will report after I try booting that one. snip Just booted on my older SMP box that barfed on -51-28. It would appear that the init problem is resolved. DOH! All of the above is on -51-30 with Karsten's patch applied. -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Thu, 14 Jul 2005, Karsten Wiese wrote: Have I corrected the other path of ioapic early initialization, which had lacked virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28? Please test attached patch on top of -51-29 or later. Also on Systems that liked -51-28. thanks, Karsten I applied your patch on top of -51-30 and all is well. I am applied it on top of -51-29 just for the heck of it and it's working well too, FWIW. -- Charles D. (Chuck) Harding [EMAIL PROTECTED] Voice: 925-423-8879 Senior Computer Associate ICCDFax: 925-423-6961 Lawrence Livermore National Laboratory Computation Directorate Livermore, CA USA http://www.llnl.gov GPG Public Key ID: B9EB6601 -- http://tinyurl.com/5w5ey --- -- Too bad stupidity isn't painful. -- - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Wednesday 13 Jul 2005 16:30, Ingo Molnar wrote: * Ingo Molnar [EMAIL PROTECTED] wrote: it worked upon the first try, and indeed my testbox crashed within 10 seconds: BUG: Unable to handle kernel NULL pointer dereference BUG: Unable to handle kernel NULL pointer dereference at virtual address 0006 a couple of crashes later i got an important clue: BUG: bad soft irq-flag value 0f64, openvpn/3386! [c0104052] dump_stack+0x1f/0x21 (20) [c013b883] check_soft_flags+0x73/0xc9 (24) [0f78] 0xf78 (1066836133) it turns out that a small portion of the softirq processing path was still using the soft IRQ-flag, instead of the raw IRQ-flag! Given enough irq and softirq workload, we were interrupted in a piece of code where the data structure was inconsistent. (tinfo.task was already changed, but %esp not yet) Since interrupts were enabled during the crash printout, it would crash again and again as it got more interrupts. The backtrace printout crashed too due to the inconsistency. That's why you got those repeat = lines. the patch below should fix this bug and i've uploaded the -51-30 patch with this fix included. Could you check whether 4K stacks are now stable for you under PREEMPT_RT? so your intuitition about this being related to 4K stacks was completely right. Ingo, This fixes the issue. It's one more 'crossed t' on the rt-preempt patches. I'll let you know if I discover anything else; your work has already allowed us to bring the responsiveness of our instrument to 300us which is low enough for the real-time PCR industry. Thanks a lot! This debugging process has been extremely eye opening, thanks for the detailed descriptions of what's gone wrong at every stage. I just wish I was competent enough to fix these things myself. -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student:CS/CSim Undergraduate contact:1F2 55 South Clerk Street, Edinburgh. EH8 9PP. - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Thu, 2005-07-14 at 20:58 +0100, Alistair John Strachan wrote: the responsiveness of our instrument to 300us which is low enough for the real-time PCR industry PCR, as in polymerase chain reaction? They can do that in realtime? Impressive. Lee - 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: Realtime Preemption, 2.6.12, Beginners Guide?
51-28 still hangs. Attached is dmesg from 51-27 with apic=debug and .config On Wed, 13 Jul 2005, karsten wiese wrote: Please unselect CONFIG_X86_IOAPIC_FAST and try 51-28 again. Also please boot the newest "working for you" RT kernel with the kernel parameter 'apic=debug' added. Post the dmesg that you get right after boot. Karsten -- Charles D. (Chuck) Harding <[EMAIL PROTECTED]> Voice: 925-423-8879 Senior Computer Associate ICCDFax: 925-423-6961 Lawrence Livermore National Laboratory Computation Directorate Livermore, CA USA http://www.llnl.gov GPG Public Key ID: B9EB6601 -- http://tinyurl.com/5w5ey --- -- Never enter a battle of wits unarmed. -- Linux version 2.6.12-RT-V0.7.51-27 ([EMAIL PROTECTED]) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)) #2 Mon Jul 11 15:41:51 PDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3ff77000 (usable) BIOS-e820: 3ff77000 - 3ff79000 (ACPI NVS) BIOS-e820: 3ff79000 - 4000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000fe710 On node 0 totalpages: 262007 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 32631 pages, LIFO batch:15 DMI 2.3 present. DELL GX240 detected: force use of acpi=ht ACPI: RSDP (v000 DELL ) @ 0x000fd570 ACPI: RSDT (v001 DELLGX240 0x0006 ASL 0x0061) @ 0x000fd584 ACPI: FADT (v001 DELLGX240 0x0006 ASL 0x0061) @ 0x000fd5b8 ACPI: SSDT (v001 DELLst_ex 0x1000 MSFT 0x010d) @ 0xfffe6189 ACPI: MADT (v001 DELLGX240 0x0006 ASL 0x0061) @ 0x000fd62c ACPI: BOOT (v001 DELLGX240 0x0006 ASL 0x0061) @ 0x000fd688 ACPI: DSDT (v001 DELLdt_ex 0x1000 MSFT 0x010d) @ 0x ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:1 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled) Using ACPI for processor (LAPIC) configuration information Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: DELL Product ID: Opti GX240 APIC at: 0xFEE0 I/O APIC #1 Version 32 at 0xFEC0. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 1 Allocating PCI resources starting at 4000 (gap: 4000:bec0) Real-Time Preemption Support (C) 2004-2005 Ingo Molnar Built 1 zonelists Kernel command line: ro root=LABEL=/ selinux=0 profile=1 nmi_watchdog=2 apic=debug kernel profiling enabled (shift: 1) mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 1993.768 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1030848k/1048028k available (2021k kernel code, 16796k reserved, 721k data, 156k init, 130524k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 3948.54 BogoMIPS (lpj=1974272) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 3febfbff CPU: After vendor identify, caps: 3febfbff CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 256K CPU: After all inits, caps: 3febfbff 0080 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz stepping 02 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. Getting VERSION: 50014 Getting VERSION: 50014 Getting ID: 0 Getting LVT0: 700 Getting LVT1: 400 enabled ExtINT on CPU#0 ENABLING IO-APIC IRQs Setting 1 in the phys_id_present_map softlockup thread 0 started up. ...changing IO-APIC physical APIC ID to 1 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 1-0, 1-13, 1-20, 1-21, 1-22 not connected. ..TIMER: vector=0x31 pin1=2 pin2=0 number of MP IRQ sources: 39. number of IO-APIC #1 registers: 24. testing the IO APIC... IO APIC #1.. register #00: 0100 ...: physical APIC id: 01 ...: Delivery Type: 0
Re: Realtime Preemption, 2.6.12, Beginners Guide?
* Chuck Harding <[EMAIL PROTECTED]> wrote: > I missed getting -51-29 but just booted up -51-30 and all is well. > Thanks. Just out of curiosity, what was changed between -51-28, 29, > and 30? -51-29 had new IO-APIC optimizations - and i reverted them in -51-30. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Wed, 13 Jul 2005, K.R. Foley wrote: Ingo Molnar wrote: * Chuck Harding <[EMAIL PROTECTED]> wrote: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo I too had the same problem booting -51-28 on my older SMP system at home. -51-29 just booted fine. I missed getting -51-29 but just booted up -51-30 and all is well. Thanks. Just out of curiosity, what was changed between -51-28, 29, and 30? -- Charles D. (Chuck) Harding <[EMAIL PROTECTED]> Voice: 925-423-8879 Senior Computer Associate ICCDFax: 925-423-6961 Lawrence Livermore National Laboratory Computation Directorate Livermore, CA USA http://www.llnl.gov GPG Public Key ID: B9EB6601 -- http://tinyurl.com/5w5ey --- -- I'm leaving my body to science fiction. -- - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> it worked upon the first try, and indeed my testbox crashed within 10
> seconds:
>
> BUG: Unable to handle kernel NULL pointer dereference
> BUG: Unable to handle kernel NULL pointer dereference at virtual address
> 0006
a couple of crashes later i got an important clue:
BUG: bad soft irq-flag value 0f64, openvpn/3386!
[] dump_stack+0x1f/0x21 (20)
[] check_soft_flags+0x73/0xc9 (24)
[<0f78>] 0xf78 (1066836133)
it turns out that a small portion of the softirq processing path was
still using the soft IRQ-flag, instead of the raw IRQ-flag! Given enough
irq and softirq workload, we were interrupted in a piece of code where
the data structure was inconsistent. (tinfo.task was already changed,
but %esp not yet) Since interrupts were enabled during the crash
printout, it would crash again and again as it got more interrupts. The
backtrace printout crashed too due to the inconsistency. That's why you
got those repeat = lines.
the patch below should fix this bug and i've uploaded the -51-30 patch
with this fix included. Could you check whether 4K stacks are now stable
for you under PREEMPT_RT?
so your intuitition about this being related to 4K stacks was completely
right.
Ingo
Index: linux/arch/i386/kernel/irq.c
===
--- linux.orig/arch/i386/kernel/irq.c
+++ linux/arch/i386/kernel/irq.c
@@ -169,7 +169,7 @@ asmlinkage void do_softirq(void)
if (in_interrupt())
return;
- local_irq_save(flags);
+ raw_local_irq_save(flags);
if (local_softirq_pending()) {
curctx = current_thread_info();
@@ -190,7 +190,7 @@ asmlinkage void do_softirq(void)
);
}
- local_irq_restore(flags);
+ raw_local_irq_restore(flags);
}
EXPORT_SYMBOL(do_softirq);
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan <[EMAIL PROTECTED]> wrote: > Ours links to a company server with a consumer grade 1Mbit ADSL > connection, and transferring just about anything at 110K/s causes the > kernel to crash within about 10 seconds. > > I wish you the best of luck with getting this going, and I apologise > in advance for the poor instructions. it worked upon the first try, and indeed my testbox crashed within 10 seconds: BUG: Unable to handle kernel NULL pointer dereference BUG: Unable to handle kernel NULL pointer dereference at virtual address 0006 printing eip: 0006 *pde = Oops: [#1] PREEMPT Modules linked in: CPU:0 EIP:0060:[<0006>]Not tainted VLI EFLAGS: 00010286 (2.6.12-RT-V0.7.51-30-debug) EIP is at 0x6 eax: c057fef8 ebx: c0614340 ecx: c04490b8 edx: 0001 esi: c057ff34 edi: c0135d52 ebp: c057ff54 esp: c057ff3c ds: 007b es: 007b ss: 0068 preempt: 2002 it was enough to "ssh 10.0.0.1" from the client, and typing "yes" would trigger the crash very soon. thanks for the instructions - now i can start debugging this :-) Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
Ingo Molnar wrote: * Chuck Harding <[EMAIL PROTECTED]> wrote: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo I too had the same problem booting -51-28 on my older SMP system at home. -51-29 just booted fine. -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Wednesday 13 July 2005 06:39, Ingo Molnar wrote: >* Chuck Harding <[EMAIL PROTECTED]> wrote: >> > CC [M] sound/oss/emu10k1/midi.o >> >sound/oss/emu10k1/midi.c:48: error: syntax error before >> > '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error >> > before ')' token >> > >> >Here's the offending line: >> > >> > 48 static DEFINE_SPINLOCK(midi_spinlock >> > __attribute((unused))); >> > >> >Lee >> >> I got it to compile but it won't boot - it hangs right after the >> 'Uncompressing Linux... OK, booting the kernel' - I'm using >> .config from 51-27 (attached) > >and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic >changes undone (will re-apply them once Karsten has figured out > what's wrong). > > Ingo >- 27 and 28 both worked in mode 4 here Ingo, except of course for tvtime. I built a 28 in mode 3 last night but haven't rebooted to it yet. I don't have an sblive in this box either. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime Preemption, 2.6.12, Beginners Guide?
* Chuck Harding <[EMAIL PROTECTED]> wrote: > > CC [M] sound/oss/emu10k1/midi.o > >sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' > >sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token > > > >Here's the offending line: > > > > 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); > > > >Lee > > > > I got it to compile but it won't boot - it hangs right after the > 'Uncompressing Linux... OK, booting the kernel' - I'm using .config > from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
--- Ingo Molnar <[EMAIL PROTECTED]> schrieb: > > hm, -28 is broken, and your patch is the only significant > change: > > - Forwarded message from Chuck Harding > <[EMAIL PROTECTED]> - > > Date: Tue, 12 Jul 2005 14:01:04 -0700 (PDT) > From: Chuck Harding <[EMAIL PROTECTED]> > To: Linux Kernel Discussion List > > Subject: Re: Realtime Preemption, 2.6.12, Beginners > Guide? > Cc: Ingo Molnar <[EMAIL PROTECTED]> > > On Tue, 12 Jul 2005, Lee Revell wrote: > > >On Mon, 2005-07-11 at 17:07 +0200, Ingo Molnar wrote: > >>I've uploaded -27 with the fix - but it should > >>only confirm that it's not a stack overflow. > > > >V0.7.51-28 does not compile: > > > > CC [M] sound/oss/emu10k1/midi.o > >sound/oss/emu10k1/midi.c:48: error: syntax error before > '__attribute__' > >sound/oss/emu10k1/midi.c:48: error: syntax error before > ')' token > > > >Here's the offending line: > > > > 48 static DEFINE_SPINLOCK(midi_spinlock > __attribute((unused))); > > > >Lee > > > > I got it to compile but it won't boot - it hangs right > after the > 'Uncompressing Linux... OK, booting the kernel' - I'm > using .config > from 51-27 (attached) > Please unselect CONFIG_X86_IOAPIC_FAST and try 51-28 again. Also please boot the newest "working for you" RT kernel with the kernel parameter 'apic=debug' added. Post the dmesg that you get right after boot. Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - 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: Realtime Preemption, 2.6.12, Beginners Guide?
--- Ingo Molnar [EMAIL PROTECTED] schrieb: hm, -28 is broken, and your patch is the only significant change: - Forwarded message from Chuck Harding [EMAIL PROTECTED] - Date: Tue, 12 Jul 2005 14:01:04 -0700 (PDT) From: Chuck Harding [EMAIL PROTECTED] To: Linux Kernel Discussion List linux-kernel@vger.kernel.org Subject: Re: Realtime Preemption, 2.6.12, Beginners Guide? Cc: Ingo Molnar [EMAIL PROTECTED] On Tue, 12 Jul 2005, Lee Revell wrote: On Mon, 2005-07-11 at 17:07 +0200, Ingo Molnar wrote: I've uploaded -27 with the fix - but it should only confirm that it's not a stack overflow. V0.7.51-28 does not compile: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) Please unselect CONFIG_X86_IOAPIC_FAST and try 51-28 again. Also please boot the newest working for you RT kernel with the kernel parameter 'apic=debug' added. Post the dmesg that you get right after boot. Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Chuck Harding [EMAIL PROTECTED] wrote: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Wednesday 13 July 2005 06:39, Ingo Molnar wrote: * Chuck Harding [EMAIL PROTECTED] wrote: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo - 27 and 28 both worked in mode 4 here Ingo, except of course for tvtime. I built a 28 in mode 3 last night but haven't rebooted to it yet. I don't have an sblive in this box either. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Ingo Molnar wrote: * Chuck Harding [EMAIL PROTECTED] wrote: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo I too had the same problem booting -51-28 on my older SMP system at home. -51-29 just booted fine. -- kr - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan [EMAIL PROTECTED] wrote: Ours links to a company server with a consumer grade 1Mbit ADSL connection, and transferring just about anything at 110K/s causes the kernel to crash within about 10 seconds. I wish you the best of luck with getting this going, and I apologise in advance for the poor instructions. it worked upon the first try, and indeed my testbox crashed within 10 seconds: BUG: Unable to handle kernel NULL pointer dereference BUG: Unable to handle kernel NULL pointer dereference at virtual address 0006 printing eip: 0006 *pde = Oops: [#1] PREEMPT Modules linked in: CPU:0 EIP:0060:[0006]Not tainted VLI EFLAGS: 00010286 (2.6.12-RT-V0.7.51-30-debug) EIP is at 0x6 eax: c057fef8 ebx: c0614340 ecx: c04490b8 edx: 0001 esi: c057ff34 edi: c0135d52 ebp: c057ff54 esp: c057ff3c ds: 007b es: 007b ss: 0068 preempt: 2002 it was enough to ssh 10.0.0.1 from the client, and typing yes would trigger the crash very soon. thanks for the instructions - now i can start debugging this :-) Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Ingo Molnar [EMAIL PROTECTED] wrote:
it worked upon the first try, and indeed my testbox crashed within 10
seconds:
BUG: Unable to handle kernel NULL pointer dereference
BUG: Unable to handle kernel NULL pointer dereference at virtual address
0006
a couple of crashes later i got an important clue:
BUG: bad soft irq-flag value 0f64, openvpn/3386!
[c0104052] dump_stack+0x1f/0x21 (20)
[c013b883] check_soft_flags+0x73/0xc9 (24)
[0f78] 0xf78 (1066836133)
it turns out that a small portion of the softirq processing path was
still using the soft IRQ-flag, instead of the raw IRQ-flag! Given enough
irq and softirq workload, we were interrupted in a piece of code where
the data structure was inconsistent. (tinfo.task was already changed,
but %esp not yet) Since interrupts were enabled during the crash
printout, it would crash again and again as it got more interrupts. The
backtrace printout crashed too due to the inconsistency. That's why you
got those repeat = lines.
the patch below should fix this bug and i've uploaded the -51-30 patch
with this fix included. Could you check whether 4K stacks are now stable
for you under PREEMPT_RT?
so your intuitition about this being related to 4K stacks was completely
right.
Ingo
Index: linux/arch/i386/kernel/irq.c
===
--- linux.orig/arch/i386/kernel/irq.c
+++ linux/arch/i386/kernel/irq.c
@@ -169,7 +169,7 @@ asmlinkage void do_softirq(void)
if (in_interrupt())
return;
- local_irq_save(flags);
+ raw_local_irq_save(flags);
if (local_softirq_pending()) {
curctx = current_thread_info();
@@ -190,7 +190,7 @@ asmlinkage void do_softirq(void)
);
}
- local_irq_restore(flags);
+ raw_local_irq_restore(flags);
}
EXPORT_SYMBOL(do_softirq);
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
On Wed, 13 Jul 2005, K.R. Foley wrote: Ingo Molnar wrote: * Chuck Harding [EMAIL PROTECTED] wrote: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic changes undone (will re-apply them once Karsten has figured out what's wrong). Ingo I too had the same problem booting -51-28 on my older SMP system at home. -51-29 just booted fine. I missed getting -51-29 but just booted up -51-30 and all is well. Thanks. Just out of curiosity, what was changed between -51-28, 29, and 30? -- Charles D. (Chuck) Harding [EMAIL PROTECTED] Voice: 925-423-8879 Senior Computer Associate ICCDFax: 925-423-6961 Lawrence Livermore National Laboratory Computation Directorate Livermore, CA USA http://www.llnl.gov GPG Public Key ID: B9EB6601 -- http://tinyurl.com/5w5ey --- -- I'm leaving my body to science fiction. -- - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Chuck Harding [EMAIL PROTECTED] wrote: I missed getting -51-29 but just booted up -51-30 and all is well. Thanks. Just out of curiosity, what was changed between -51-28, 29, and 30? -51-29 had new IO-APIC optimizations - and i reverted them in -51-30. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
51-28 still hangs. Attached is dmesg from 51-27 with apic=debug and .config On Wed, 13 Jul 2005, karsten wiese wrote: Please unselect CONFIG_X86_IOAPIC_FAST and try 51-28 again. Also please boot the newest working for you RT kernel with the kernel parameter 'apic=debug' added. Post the dmesg that you get right after boot. Karsten -- Charles D. (Chuck) Harding [EMAIL PROTECTED] Voice: 925-423-8879 Senior Computer Associate ICCDFax: 925-423-6961 Lawrence Livermore National Laboratory Computation Directorate Livermore, CA USA http://www.llnl.gov GPG Public Key ID: B9EB6601 -- http://tinyurl.com/5w5ey --- -- Never enter a battle of wits unarmed. -- Linux version 2.6.12-RT-V0.7.51-27 ([EMAIL PROTECTED]) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)) #2 Mon Jul 11 15:41:51 PDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3ff77000 (usable) BIOS-e820: 3ff77000 - 3ff79000 (ACPI NVS) BIOS-e820: 3ff79000 - 4000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000fe710 On node 0 totalpages: 262007 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 32631 pages, LIFO batch:15 DMI 2.3 present. DELL GX240 detected: force use of acpi=ht ACPI: RSDP (v000 DELL ) @ 0x000fd570 ACPI: RSDT (v001 DELLGX240 0x0006 ASL 0x0061) @ 0x000fd584 ACPI: FADT (v001 DELLGX240 0x0006 ASL 0x0061) @ 0x000fd5b8 ACPI: SSDT (v001 DELLst_ex 0x1000 MSFT 0x010d) @ 0xfffe6189 ACPI: MADT (v001 DELLGX240 0x0006 ASL 0x0061) @ 0x000fd62c ACPI: BOOT (v001 DELLGX240 0x0006 ASL 0x0061) @ 0x000fd688 ACPI: DSDT (v001 DELLdt_ex 0x1000 MSFT 0x010d) @ 0x ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:1 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled) Using ACPI for processor (LAPIC) configuration information Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: DELL Product ID: Opti GX240 APIC at: 0xFEE0 I/O APIC #1 Version 32 at 0xFEC0. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 1 Allocating PCI resources starting at 4000 (gap: 4000:bec0) Real-Time Preemption Support (C) 2004-2005 Ingo Molnar Built 1 zonelists Kernel command line: ro root=LABEL=/ selinux=0 profile=1 nmi_watchdog=2 apic=debug kernel profiling enabled (shift: 1) mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 1993.768 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1030848k/1048028k available (2021k kernel code, 16796k reserved, 721k data, 156k init, 130524k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 3948.54 BogoMIPS (lpj=1974272) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 3febfbff CPU: After vendor identify, caps: 3febfbff CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 256K CPU: After all inits, caps: 3febfbff 0080 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz stepping 02 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. Getting VERSION: 50014 Getting VERSION: 50014 Getting ID: 0 Getting LVT0: 700 Getting LVT1: 400 enabled ExtINT on CPU#0 ENABLING IO-APIC IRQs Setting 1 in the phys_id_present_map softlockup thread 0 started up. ...changing IO-APIC physical APIC ID to 1 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 1-0, 1-13, 1-20, 1-21, 1-22 not connected. ..TIMER: vector=0x31 pin1=2 pin2=0 number of MP IRQ sources: 39. number of IO-APIC #1 registers: 24. testing the IO APIC... IO APIC #1.. register #00: 0100 ...: physical APIC id: 01 ...: Delivery Type: 0 ...
Re: Realtime Preemption, 2.6.12, Beginners Guide?
On Tue, 12 Jul 2005, Lee Revell wrote: On Mon, 2005-07-11 at 17:07 +0200, Ingo Molnar wrote: I've uploaded -27 with the fix - but it should only confirm that it's not a stack overflow. V0.7.51-28 does not compile: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) -- Charles D. (Chuck) Harding <[EMAIL PROTECTED]> Voice: 925-423-8879 Senior Computer Associate ICCDFax: 925-423-6961 Lawrence Livermore National Laboratory Computation Directorate Livermore, CA USA http://www.llnl.gov GPG Public Key ID: B9EB6601 -- http://tinyurl.com/5w5ey --- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-RT-V0.7.51-28 # Tue Jul 12 12:18:43 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_RCU=y CONFIG_PREEMPT_BKL=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ASM_SEMAPHORES=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_IOAPIC_FAST=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=2001 # CONFIG_ACPI_DEBUG is
Re: Realtime Preemption, 2.6.12, Beginners Guide?
On Mon, 2005-07-11 at 17:07 +0200, Ingo Molnar wrote: > I've uploaded -27 with the fix - but it should > only confirm that it's not a stack overflow. V0.7.51-28 does not compile: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* William Weston <[EMAIL PROTECTED]> wrote: > On Sat, 9 Jul 2005, Ingo Molnar wrote: > > > this patch reduces ip_setsockopt's stack footprint from 572 bytes to 164 > > bytes. (Note: needs review and testing as i could not excercise this > > multicast codepath.) > > This patch breaks multicast source group joins. Here's the fix: ouch - indeed, thanks. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Tue, 12 Jul 2005, Lee Revell wrote: On Mon, 2005-07-11 at 17:07 +0200, Ingo Molnar wrote: I've uploaded -27 with the fix - but it should only confirm that it's not a stack overflow. V0.7.51-28 does not compile: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee I got it to compile but it won't boot - it hangs right after the 'Uncompressing Linux... OK, booting the kernel' - I'm using .config from 51-27 (attached) -- Charles D. (Chuck) Harding [EMAIL PROTECTED] Voice: 925-423-8879 Senior Computer Associate ICCDFax: 925-423-6961 Lawrence Livermore National Laboratory Computation Directorate Livermore, CA USA http://www.llnl.gov GPG Public Key ID: B9EB6601 -- http://tinyurl.com/5w5ey --- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-RT-V0.7.51-28 # Tue Jul 12 12:18:43 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_RCU=y CONFIG_PREEMPT_BKL=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ASM_SEMAPHORES=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_IOAPIC_FAST=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=2001 # CONFIG_ACPI_DEBUG is not
Re: Realtime Preemption, 2.6.12, Beginners Guide?
* William Weston [EMAIL PROTECTED] wrote: On Sat, 9 Jul 2005, Ingo Molnar wrote: this patch reduces ip_setsockopt's stack footprint from 572 bytes to 164 bytes. (Note: needs review and testing as i could not excercise this multicast codepath.) This patch breaks multicast source group joins. Here's the fix: ouch - indeed, thanks. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Mon, 2005-07-11 at 17:07 +0200, Ingo Molnar wrote: I've uploaded -27 with the fix - but it should only confirm that it's not a stack overflow. V0.7.51-28 does not compile: CC [M] sound/oss/emu10k1/midi.o sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__' sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token Here's the offending line: 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); Lee - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Mon, 2005-07-11 at 15:38 +0100, Alistair John Strachan wrote: > I realise 4KSTACKS is a considerable rework of the IRQ handler, etc. and > probably even more heavily modified by rt-preempt, but is there nothing else > that can be tested before a serial console run? > Well, netconsole is a lot quicker to set up than serial, but AIUI can fail in some cases where serial console succeeds. Lee - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan <[EMAIL PROTECTED]> wrote: > Here's a screenshot of the oops. Notice that "stack left" is now -52. > We've confirmed this is a stack overflow! > > http://devzero.co.uk/~alistair/oops8.jpeg > > I'm going to try the 8K stack kernel with the same stuff and see if I > can get a stack trace. I hope this is the beginning of the end for > this problem. might be an incorrect printout of stack_left :( The esp looks more or less normal. Not sure why it printed -52. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Monday 11 Jul 2005 15:16, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > might be an incorrect printout of stack_left :( The esp looks more or
> > less normal. Not sure why it printed -52.
>
> here's the stack_left calculation:
>
> + printk("ds: %04x es: %04x ss: %04x preempt: %08x\n",
> + regs->xds & 0x, regs->xes & 0x, ss,
> preempt_count()); + printk("Process %s (pid: %d, threadinfo=%p
> task=%p stack_left=%ld worst_left=%ld)", + current->comm,
> current->pid, current_thread_info(), current, + (regs->esp &
> (THREAD_SIZE-1))-sizeof(struct thread_info), +
> worst_stack_left);
>
> i cannot see anything wrong in it, but your esp is 0xc04cded0,
> THREAD_SIZE-1 is 0xfff, so the result should be:
>
> 0xed0-sizeof(struct thread_info).
>
> which should not be -52.
Actually, it's now pretty much confirmed that this ISN'T a stack overflow, not
just because of what you've said (now and before), but also because I've
tried an 8K stacks kernel and, sadly, there's no stand-out stack abusers.
It's annoying that this is so readily reproducible here, yet almost impossible
to debug, and clearly a sideaffect of 4KSTACKS.. without it actually being a
stack overflow.
I realise 4KSTACKS is a considerable rework of the IRQ handler, etc. and
probably even more heavily modified by rt-preempt, but is there nothing else
that can be tested before a serial console run?
--
Cheers,
Alistair.
personal: alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:CS/CSim Undergraduate
contact:1F2 55 South Clerk Street,
Edinburgh. EH8 9PP.
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan <[EMAIL PROTECTED]> wrote: > It's annoying that this is so readily reproducible here, yet almost > impossible to debug, and clearly a sideaffect of 4KSTACKS.. without it > actually being a stack overflow. > > I realise 4KSTACKS is a considerable rework of the IRQ handler, etc. > and probably even more heavily modified by rt-preempt, but is there > nothing else that can be tested before a serial console run? 4K stacks never really caused any trouble under PREEMPT_RT (or any other kernel i tried). It's not that complex either. one useful thing could be to give me exact instructions on how to set up an openvpn network similar to yours, and what kind of workload to generate. Maybe i can reproduce it here. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > might be an incorrect printout of stack_left :( The esp looks more or
> > less normal. Not sure why it printed -52.
>
> here's the stack_left calculation:
>
> + printk("ds: %04x es: %04x ss: %04x preempt: %08x\n",
> + regs->xds & 0x, regs->xes & 0x, ss, preempt_count());
> + printk("Process %s (pid: %d, threadinfo=%p task=%p stack_left=%ld
> worst_left=%ld)",
> + current->comm, current->pid, current_thread_info(), current,
> + (regs->esp & (THREAD_SIZE-1))-sizeof(struct thread_info),
> + worst_stack_left);
>
> i cannot see anything wrong in it, [...]
that should be "esp", not "regs->esp". regs->esp is something different
upon in-kernel faults. I've uploaded -27 with the fix - but it should
only confirm that it's not a stack overflow.
Ingo
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
On Sat, 9 Jul 2005, Ingo Molnar wrote:
> this patch reduces ip_setsockopt's stack footprint from 572 bytes to 164
> bytes. (Note: needs review and testing as i could not excercise this
> multicast codepath.)
This patch breaks multicast source group joins. Here's the fix:
--- linux.old/net/ipv4/ip_sockglue.c2005-07-11 01:50:19.0 -0700
+++ linux/net/ipv4/ip_sockglue.c2005-07-11 13:54:34.0 -0700
@@ -738,7 +738,7 @@
break;
if (optlen != sizeof(struct group_source_req))
goto free_greqs_e_inval;
- if (copy_from_user(, optval, sizeof(*greqs))) {
+ if (copy_from_user(greqs, optval, sizeof(*greqs))) {
err = -EFAULT;
goto free_greqs_break;
}
Cheers,
--ww
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
On Monday 11 Jul 2005 15:43, Ingo Molnar wrote:
> * Alistair John Strachan <[EMAIL PROTECTED]> wrote:
> > It's annoying that this is so readily reproducible here, yet almost
> > impossible to debug, and clearly a sideaffect of 4KSTACKS.. without it
> > actually being a stack overflow.
> >
> > I realise 4KSTACKS is a considerable rework of the IRQ handler, etc.
> > and probably even more heavily modified by rt-preempt, but is there
> > nothing else that can be tested before a serial console run?
>
> 4K stacks never really caused any trouble under PREEMPT_RT (or any other
> kernel i tried). It's not that complex either.
>
> one useful thing could be to give me exact instructions on how to set up
> an openvpn network similar to yours, and what kind of workload to
> generate. Maybe i can reproduce it here.
OpenVPN isn't terribly difficult to set up, but it's more than a 5 minute job.
You'll need universal tun/tap in your kernel before you start, and openvpn
itself installed (I've compiled from source and used Debian's 2.0.0 package,
I'm sure Red Hat has an equivalent), then it's just a case of setting up a
client and a server.
If you like, I can generate the "keys" used for server/client and I've
attached the configs for the server and the client they we use here.
Obviously for security reasons I can't attach OUR keys verbatim, but I'll
instruct you on how to generate them.
So, on the server:
a) Install OpenVPN
b) mkdir -p /etc/openvpn/keys
c) Copy attached server.conf to /etc/openvpn
d) Modify server.conf if necessary (shouldn't be required)
e) Generate your server and client keys (see below)
This mostly repeats the moderately good documentation on
http://openvpn.net/howto.html, but I can't expect you to read it all so I'll
give you a bite-sized version. It saves you figuring out the same rubbish I
had to about 6 months ago. OpenVPN will create (with my configs) a verbose
log in /etc/openvpn/log on both machines.
1) cd /usr/share/doc/openvpn/easy-rsa
2) Edit "vars". Change line export KEY_DIR=... to:
export KEY_DIR=/etc/openvpn/keys
3) Save and exit
4) On Bash (at least) type
. ./vars
Which imports "vars" into your environment.
5) ./clean-all
6) ./build-ca (enter any old crap)
7) ./build-key-server server
Enter the common-name as "server" again. No password.
8) Finally, generate the client key (used by the client for crypto)
./build-key client1
Where "client1" is an arbitrary name. When prompted for "common-name",
enter
the same string; this is important and I was head-scratching for some
time
as to why it wouldn't work without this... Again no password.
8) ./build-dh (this takes a while)
With that done, /etc/openvpn/keys should contain at least..
01.pem
ca.{crt,key}
dh1024.pem
server.{crt,csr,key}
client1.{crt,csr,key}
Plus some other cruft that's probably not required. Now you should be able to
start the openvpn server with something like..
openvpn --cd /etc/openvpn --config server.conf
Add some other flags like verbose if you want to see what's happening.
Remember it's logging everything to /etc/openvpn/log which you can supress by
commenting out the logfile line in the config.
It'll bring up a tun device on the server side, and wait patiently for VPN
connections.
The client side is a piece of cake.
1) mkdir /etc/openvpn
2) Copy client1.crt, client1.key, and ca.crt from the server's /etc/openvpn
directory to the client's /etc/openvpn directory.
3) Copy the attached client.conf to the same directory.
4) Edit the config as necessary and save (should work with only the server IP
changes).
Again, the client machine will need to have the universal tun/tap driver
loaded. Bring up the openvpn with:
openvpn --cd /etc/openvpn --config client.conf
A connection should be established and, hopefully, you'll get a pingable route
to 10.0.0.1. I then made this my default gateway with:
route del default wlan
route add default tun0
Then I was able to ping machines on the server side without having a local
gateway to them. One working VPN.
I suggest you try all this on a "stable" kernel, and once you've established
it works, just transfer a file at a reasonable data rate through the tunnel.
Ours links to a company server with a consumer grade 1Mbit ADSL connection,
and transferring just about anything at 110K/s causes the kernel to crash
within about 10 seconds.
I wish you the best of luck with getting this going, and I apologise in
advance for the poor instructions.
--
Cheers,
Alistair.
personal: alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:CS/CSim Undergraduate
contact:1F2 55 South Clerk Street,
Edinburgh. EH8 9PP.
client
remote 192.168.99.1 443
ca ca.crt
cert client1.crt
key client1.key
ns-cert-type server
dev tun
proto udp
nobind
user nobody
group nobody
persist-key
persist-tun
log /etc/openvpn/log
verb 3
server 10.0.0.0 255.255.255.0
port 443
Re: Realtime Preemption, 2.6.12, Beginners Guide?
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> might be an incorrect printout of stack_left :( The esp looks more or
> less normal. Not sure why it printed -52.
here's the stack_left calculation:
+ printk("ds: %04x es: %04x ss: %04x preempt: %08x\n",
+ regs->xds & 0x, regs->xes & 0x, ss, preempt_count());
+ printk("Process %s (pid: %d, threadinfo=%p task=%p stack_left=%ld
worst_left=%ld)",
+ current->comm, current->pid, current_thread_info(), current,
+ (regs->esp & (THREAD_SIZE-1))-sizeof(struct thread_info),
+ worst_stack_left);
i cannot see anything wrong in it, but your esp is 0xc04cded0,
THREAD_SIZE-1 is 0xfff, so the result should be:
0xed0-sizeof(struct thread_info).
which should not be -52.
Ingo
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
On Saturday 09 Jul 2005 17:04, Alistair John Strachan wrote: > On Saturday 09 Jul 2005 16:57, Ingo Molnar wrote: > > * Alistair John Strachan <[EMAIL PROTECTED]> wrote: > > > Okay, I'll send you the vmlinux from -18 with a new digital photo, and > > > config, with CONFIG_4KSTACKS enabled. > > > > this crash too seems to indicate trigger_softirqs()/wakeup_softirqd(). > > Somewhere we somehow corrupt the stack and e.g. in oops7.jpg we return > > to 00c011ed. Note that it's a right-shifted address that could be one of > > these: > > > > c011ed50 t wakeup_softirqd > > c011ed80 t trigger_softirqs > > > > but it looks pretty weird. DEBUG_STACK_POISON (and the full-debug > > .config i sent) could perhaps uncover other types of stack corruptions. > > You weren't kidding about the overhead from DEBUG_STACK_POISON. > Unfortunately that config causes a triple fault randomly after boot. The > machine doesn't crash, or oops, it just resets. > > This problem has gone from bad to worse :-) Okay, maybe not. Some combination of the debug options you enabled causes this problem, but DEBUG_STACK_POISON itself is not the cause. Today I compiled Yet Another (tm) CONFIG_4KSTACKS kernel with DEBUG_STACK_POISON, CONFIG_DEBUG_STACKOVERFLOW and CONFIG_LATENCY_TRACE, which worked fine (from a random reboot perspective). I've also upgraded GCC to 4.0.1 as Jakub highlighted elsewhere in this thread that it had been released. Here's a screenshot of the oops. Notice that "stack left" is now -52. We've confirmed this is a stack overflow! http://devzero.co.uk/~alistair/oops8.jpeg I'm going to try the 8K stack kernel with the same stuff and see if I can get a stack trace. I hope this is the beginning of the end for this problem. -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student:CS/CSim Undergraduate contact:1F2 55 South Clerk Street, Edinburgh. EH8 9PP. - 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: Realtime Preemption, 2.6.12, Beginners Guide?
Ingo Molnar wrote:
(gdb)
(gdb) # c013ebf4, stack size: 388 bytes #
(gdb)
(gdb) 0xc013ebf4 is in __print_symbol (kernel/kallsyms.c:234).
The attached patch fixes this partially by reducing the stack usage by
128 bytes. Compile, boot and run tested and apparently it works fine.
I didn't want to use kmalloc's in there because this function is
probably called from very "hard" contexts (kernel OOPS, stack overflow
dumps, etc.).
The stack usage could be reduced even further (I can do a patch for this
if needed) by changing the function to receive a "prefix" and a "suffix"
string instead of a format string.
The function could then simply do:
printk(prefix);
printk(symbol);
printk(address);
if (module) printk(module name);
printk(suffix);
This way it wouldn't need to allocate a buffer big enough for the whole
string, just for one symbol name (128 bytes).
This is a much more intrusive change however (there are ~65 callers that
would need changing), so I leave the decision to more experienced hackers :)
--
Paulo Marques - www.grupopie.com
It is a mistake to think you can solve any major problems
just with potatoes.
Douglas Adams
--- ./kernel/kallsyms.c.orig 2005-07-11 12:32:32.0 +0100
+++ ./kernel/kallsyms.c 2005-07-11 12:34:42.0 +0100
@@ -232,23 +232,21 @@ const char *kallsyms_lookup(unsigned lon
/* Replace "%s" in format with address, or returns -errno. */
void __print_symbol(const char *fmt, unsigned long address)
{
- char *modname;
+ char *modname, *bufend;
const char *name;
unsigned long offset, size;
- char namebuf[KSYM_NAME_LEN+1];
char buffer[sizeof("%s+%#lx/%#lx [%s]") + KSYM_NAME_LEN +
2*(BITS_PER_LONG*3/10) + MODULE_NAME_LEN + 1];
- name = kallsyms_lookup(address, , , , namebuf);
+ name = kallsyms_lookup(address, , , , buffer);
if (!name)
sprintf(buffer, "0x%lx", address);
else {
+ bufend = strchr(buffer, '\0');
+ bufend += sprintf(bufend, "+%#lx/%#lx", offset, size);
if (modname)
- sprintf(buffer, "%s+%#lx/%#lx [%s]", name, offset,
-size, modname);
- else
- sprintf(buffer, "%s+%#lx/%#lx", name, offset, size);
+ sprintf(bufend, " [%s]", modname);
}
printk(fmt, buffer);
}
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Ingo Molnar wrote:
(gdb)
(gdb) # c013ebf4, stack size: 388 bytes #
(gdb)
(gdb) 0xc013ebf4 is in __print_symbol (kernel/kallsyms.c:234).
The attached patch fixes this partially by reducing the stack usage by
128 bytes. Compile, boot and run tested and apparently it works fine.
I didn't want to use kmalloc's in there because this function is
probably called from very hard contexts (kernel OOPS, stack overflow
dumps, etc.).
The stack usage could be reduced even further (I can do a patch for this
if needed) by changing the function to receive a prefix and a suffix
string instead of a format string.
The function could then simply do:
printk(prefix);
printk(symbol);
printk(address);
if (module) printk(module name);
printk(suffix);
This way it wouldn't need to allocate a buffer big enough for the whole
string, just for one symbol name (128 bytes).
This is a much more intrusive change however (there are ~65 callers that
would need changing), so I leave the decision to more experienced hackers :)
--
Paulo Marques - www.grupopie.com
It is a mistake to think you can solve any major problems
just with potatoes.
Douglas Adams
--- ./kernel/kallsyms.c.orig 2005-07-11 12:32:32.0 +0100
+++ ./kernel/kallsyms.c 2005-07-11 12:34:42.0 +0100
@@ -232,23 +232,21 @@ const char *kallsyms_lookup(unsigned lon
/* Replace %s in format with address, or returns -errno. */
void __print_symbol(const char *fmt, unsigned long address)
{
- char *modname;
+ char *modname, *bufend;
const char *name;
unsigned long offset, size;
- char namebuf[KSYM_NAME_LEN+1];
char buffer[sizeof(%s+%#lx/%#lx [%s]) + KSYM_NAME_LEN +
2*(BITS_PER_LONG*3/10) + MODULE_NAME_LEN + 1];
- name = kallsyms_lookup(address, size, offset, modname, namebuf);
+ name = kallsyms_lookup(address, size, offset, modname, buffer);
if (!name)
sprintf(buffer, 0x%lx, address);
else {
+ bufend = strchr(buffer, '\0');
+ bufend += sprintf(bufend, +%#lx/%#lx, offset, size);
if (modname)
- sprintf(buffer, %s+%#lx/%#lx [%s], name, offset,
-size, modname);
- else
- sprintf(buffer, %s+%#lx/%#lx, name, offset, size);
+ sprintf(bufend, [%s], modname);
}
printk(fmt, buffer);
}
Re: Realtime Preemption, 2.6.12, Beginners Guide?
On Saturday 09 Jul 2005 17:04, Alistair John Strachan wrote: On Saturday 09 Jul 2005 16:57, Ingo Molnar wrote: * Alistair John Strachan [EMAIL PROTECTED] wrote: Okay, I'll send you the vmlinux from -18 with a new digital photo, and config, with CONFIG_4KSTACKS enabled. this crash too seems to indicate trigger_softirqs()/wakeup_softirqd(). Somewhere we somehow corrupt the stack and e.g. in oops7.jpg we return to 00c011ed. Note that it's a right-shifted address that could be one of these: c011ed50 t wakeup_softirqd c011ed80 t trigger_softirqs but it looks pretty weird. DEBUG_STACK_POISON (and the full-debug .config i sent) could perhaps uncover other types of stack corruptions. You weren't kidding about the overhead from DEBUG_STACK_POISON. Unfortunately that config causes a triple fault randomly after boot. The machine doesn't crash, or oops, it just resets. This problem has gone from bad to worse :-) Okay, maybe not. Some combination of the debug options you enabled causes this problem, but DEBUG_STACK_POISON itself is not the cause. Today I compiled Yet Another (tm) CONFIG_4KSTACKS kernel with DEBUG_STACK_POISON, CONFIG_DEBUG_STACKOVERFLOW and CONFIG_LATENCY_TRACE, which worked fine (from a random reboot perspective). I've also upgraded GCC to 4.0.1 as Jakub highlighted elsewhere in this thread that it had been released. Here's a screenshot of the oops. Notice that stack left is now -52. We've confirmed this is a stack overflow! http://devzero.co.uk/~alistair/oops8.jpeg I'm going to try the 8K stack kernel with the same stuff and see if I can get a stack trace. I hope this is the beginning of the end for this problem. -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student:CS/CSim Undergraduate contact:1F2 55 South Clerk Street, Edinburgh. EH8 9PP. - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Ingo Molnar [EMAIL PROTECTED] wrote: might be an incorrect printout of stack_left :( The esp looks more or less normal. Not sure why it printed -52. here's the stack_left calculation: + printk(ds: %04x es: %04x ss: %04x preempt: %08x\n, + regs-xds 0x, regs-xes 0x, ss, preempt_count()); + printk(Process %s (pid: %d, threadinfo=%p task=%p stack_left=%ld worst_left=%ld), + current-comm, current-pid, current_thread_info(), current, + (regs-esp (THREAD_SIZE-1))-sizeof(struct thread_info), + worst_stack_left); i cannot see anything wrong in it, but your esp is 0xc04cded0, THREAD_SIZE-1 is 0xfff, so the result should be: 0xed0-sizeof(struct thread_info). which should not be -52. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Monday 11 Jul 2005 15:43, Ingo Molnar wrote:
* Alistair John Strachan [EMAIL PROTECTED] wrote:
It's annoying that this is so readily reproducible here, yet almost
impossible to debug, and clearly a sideaffect of 4KSTACKS.. without it
actually being a stack overflow.
I realise 4KSTACKS is a considerable rework of the IRQ handler, etc.
and probably even more heavily modified by rt-preempt, but is there
nothing else that can be tested before a serial console run?
4K stacks never really caused any trouble under PREEMPT_RT (or any other
kernel i tried). It's not that complex either.
one useful thing could be to give me exact instructions on how to set up
an openvpn network similar to yours, and what kind of workload to
generate. Maybe i can reproduce it here.
OpenVPN isn't terribly difficult to set up, but it's more than a 5 minute job.
You'll need universal tun/tap in your kernel before you start, and openvpn
itself installed (I've compiled from source and used Debian's 2.0.0 package,
I'm sure Red Hat has an equivalent), then it's just a case of setting up a
client and a server.
If you like, I can generate the keys used for server/client and I've
attached the configs for the server and the client they we use here.
Obviously for security reasons I can't attach OUR keys verbatim, but I'll
instruct you on how to generate them.
So, on the server:
a) Install OpenVPN
b) mkdir -p /etc/openvpn/keys
c) Copy attached server.conf to /etc/openvpn
d) Modify server.conf if necessary (shouldn't be required)
e) Generate your server and client keys (see below)
This mostly repeats the moderately good documentation on
http://openvpn.net/howto.html, but I can't expect you to read it all so I'll
give you a bite-sized version. It saves you figuring out the same rubbish I
had to about 6 months ago. OpenVPN will create (with my configs) a verbose
log in /etc/openvpn/log on both machines.
1) cd /usr/share/doc/openvpn/easy-rsa
2) Edit vars. Change line export KEY_DIR=... to:
export KEY_DIR=/etc/openvpn/keys
3) Save and exit
4) On Bash (at least) type
. ./vars
Which imports vars into your environment.
5) ./clean-all
6) ./build-ca (enter any old crap)
7) ./build-key-server server
Enter the common-name as server again. No password.
8) Finally, generate the client key (used by the client for crypto)
./build-key client1
Where client1 is an arbitrary name. When prompted for common-name,
enter
the same string; this is important and I was head-scratching for some
time
as to why it wouldn't work without this... Again no password.
8) ./build-dh (this takes a while)
With that done, /etc/openvpn/keys should contain at least..
01.pem
ca.{crt,key}
dh1024.pem
server.{crt,csr,key}
client1.{crt,csr,key}
Plus some other cruft that's probably not required. Now you should be able to
start the openvpn server with something like..
openvpn --cd /etc/openvpn --config server.conf
Add some other flags like verbose if you want to see what's happening.
Remember it's logging everything to /etc/openvpn/log which you can supress by
commenting out the logfile line in the config.
It'll bring up a tun device on the server side, and wait patiently for VPN
connections.
The client side is a piece of cake.
1) mkdir /etc/openvpn
2) Copy client1.crt, client1.key, and ca.crt from the server's /etc/openvpn
directory to the client's /etc/openvpn directory.
3) Copy the attached client.conf to the same directory.
4) Edit the config as necessary and save (should work with only the server IP
changes).
Again, the client machine will need to have the universal tun/tap driver
loaded. Bring up the openvpn with:
openvpn --cd /etc/openvpn --config client.conf
A connection should be established and, hopefully, you'll get a pingable route
to 10.0.0.1. I then made this my default gateway with:
route del default wlan
route add default tun0
Then I was able to ping machines on the server side without having a local
gateway to them. One working VPN.
I suggest you try all this on a stable kernel, and once you've established
it works, just transfer a file at a reasonable data rate through the tunnel.
Ours links to a company server with a consumer grade 1Mbit ADSL connection,
and transferring just about anything at 110K/s causes the kernel to crash
within about 10 seconds.
I wish you the best of luck with getting this going, and I apologise in
advance for the poor instructions.
--
Cheers,
Alistair.
personal: alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:CS/CSim Undergraduate
contact:1F2 55 South Clerk Street,
Edinburgh. EH8 9PP.
client
remote 192.168.99.1 443
ca ca.crt
cert client1.crt
key client1.key
ns-cert-type server
dev tun
proto udp
nobind
user nobody
group nobody
persist-key
persist-tun
log /etc/openvpn/log
verb 3
server 10.0.0.0 255.255.255.0
port 443
ca keys/ca.crt
cert keys/server.crt
Re: Realtime Preemption, 2.6.12, Beginners Guide?
On Sat, 9 Jul 2005, Ingo Molnar wrote:
this patch reduces ip_setsockopt's stack footprint from 572 bytes to 164
bytes. (Note: needs review and testing as i could not excercise this
multicast codepath.)
This patch breaks multicast source group joins. Here's the fix:
--- linux.old/net/ipv4/ip_sockglue.c2005-07-11 01:50:19.0 -0700
+++ linux/net/ipv4/ip_sockglue.c2005-07-11 13:54:34.0 -0700
@@ -738,7 +738,7 @@
break;
if (optlen != sizeof(struct group_source_req))
goto free_greqs_e_inval;
- if (copy_from_user(greqs, optval, sizeof(*greqs))) {
+ if (copy_from_user(greqs, optval, sizeof(*greqs))) {
err = -EFAULT;
goto free_greqs_break;
}
Cheers,
--ww
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
* Ingo Molnar [EMAIL PROTECTED] wrote: might be an incorrect printout of stack_left :( The esp looks more or less normal. Not sure why it printed -52. here's the stack_left calculation: + printk(ds: %04x es: %04x ss: %04x preempt: %08x\n, + regs-xds 0x, regs-xes 0x, ss, preempt_count()); + printk(Process %s (pid: %d, threadinfo=%p task=%p stack_left=%ld worst_left=%ld), + current-comm, current-pid, current_thread_info(), current, + (regs-esp (THREAD_SIZE-1))-sizeof(struct thread_info), + worst_stack_left); i cannot see anything wrong in it, [...] that should be esp, not regs-esp. regs-esp is something different upon in-kernel faults. I've uploaded -27 with the fix - but it should only confirm that it's not a stack overflow. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan [EMAIL PROTECTED] wrote: It's annoying that this is so readily reproducible here, yet almost impossible to debug, and clearly a sideaffect of 4KSTACKS.. without it actually being a stack overflow. I realise 4KSTACKS is a considerable rework of the IRQ handler, etc. and probably even more heavily modified by rt-preempt, but is there nothing else that can be tested before a serial console run? 4K stacks never really caused any trouble under PREEMPT_RT (or any other kernel i tried). It's not that complex either. one useful thing could be to give me exact instructions on how to set up an openvpn network similar to yours, and what kind of workload to generate. Maybe i can reproduce it here. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Monday 11 Jul 2005 15:16, Ingo Molnar wrote: * Ingo Molnar [EMAIL PROTECTED] wrote: might be an incorrect printout of stack_left :( The esp looks more or less normal. Not sure why it printed -52. here's the stack_left calculation: + printk(ds: %04x es: %04x ss: %04x preempt: %08x\n, + regs-xds 0x, regs-xes 0x, ss, preempt_count()); + printk(Process %s (pid: %d, threadinfo=%p task=%p stack_left=%ld worst_left=%ld), + current-comm, current-pid, current_thread_info(), current, + (regs-esp (THREAD_SIZE-1))-sizeof(struct thread_info), + worst_stack_left); i cannot see anything wrong in it, but your esp is 0xc04cded0, THREAD_SIZE-1 is 0xfff, so the result should be: 0xed0-sizeof(struct thread_info). which should not be -52. Actually, it's now pretty much confirmed that this ISN'T a stack overflow, not just because of what you've said (now and before), but also because I've tried an 8K stacks kernel and, sadly, there's no stand-out stack abusers. It's annoying that this is so readily reproducible here, yet almost impossible to debug, and clearly a sideaffect of 4KSTACKS.. without it actually being a stack overflow. I realise 4KSTACKS is a considerable rework of the IRQ handler, etc. and probably even more heavily modified by rt-preempt, but is there nothing else that can be tested before a serial console run? -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student:CS/CSim Undergraduate contact:1F2 55 South Clerk Street, Edinburgh. EH8 9PP. - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan [EMAIL PROTECTED] wrote: Here's a screenshot of the oops. Notice that stack left is now -52. We've confirmed this is a stack overflow! http://devzero.co.uk/~alistair/oops8.jpeg I'm going to try the 8K stack kernel with the same stuff and see if I can get a stack trace. I hope this is the beginning of the end for this problem. might be an incorrect printout of stack_left :( The esp looks more or less normal. Not sure why it printed -52. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Mon, 2005-07-11 at 15:38 +0100, Alistair John Strachan wrote: I realise 4KSTACKS is a considerable rework of the IRQ handler, etc. and probably even more heavily modified by rt-preempt, but is there nothing else that can be tested before a serial console run? Well, netconsole is a lot quicker to set up than serial, but AIUI can fail in some cases where serial console succeeds. Lee - 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/
PCMCIA stack reduction patch [Was: Re: Realtime Preemption, 2.6.12, Beginners Guide?]
Hi, On Sat, Jul 09, 2005 at 03:26:57PM +0200, Ingo Molnar wrote: > > > (gdb) > > (gdb) # c02a0a26, stack size: 416 bytes # > > (gdb) > > (gdb) 0xc02a0a26 is in pcmcia_device_query (drivers/pcmcia/ds.c:436). > > > this patch reduces the stack footprint of pcmcia_device_query() from 416 > bytes to 36 bytes. (patch only build-tested) Applied and tested, but without the final hunk. > @@ -856,7 +868,9 @@ static int bind_request(struct pcmcia_bu > rescan: > p_dev->cardmgr = p_drv; > > - pcmcia_device_query(p_dev); > + ret = pcmcia_device_query(p_dev); > + if (ret) > + goto err_put_module; > > /* >* Prevent this racing with a card insertion. We don't check the return value here for a reason. Thanks, Dominik - 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/
PCMCIA stack reduction patch [Was: Re: Realtime Preemption, 2.6.12, Beginners Guide?]
Hi, On Sat, Jul 09, 2005 at 03:26:57PM +0200, Ingo Molnar wrote: (gdb) (gdb) # c02a0a26, stack size: 416 bytes # (gdb) (gdb) 0xc02a0a26 is in pcmcia_device_query (drivers/pcmcia/ds.c:436). this patch reduces the stack footprint of pcmcia_device_query() from 416 bytes to 36 bytes. (patch only build-tested) Applied and tested, but without the final hunk. @@ -856,7 +868,9 @@ static int bind_request(struct pcmcia_bu rescan: p_dev-cardmgr = p_drv; - pcmcia_device_query(p_dev); + ret = pcmcia_device_query(p_dev); + if (ret) + goto err_put_module; /* * Prevent this racing with a card insertion. We don't check the return value here for a reason. Thanks, Dominik - 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: Realtime Preemption, 2.6.12, Beginners Guide?
On Saturday 09 Jul 2005 16:57, Ingo Molnar wrote: > * Alistair John Strachan <[EMAIL PROTECTED]> wrote: > > Okay, I'll send you the vmlinux from -18 with a new digital photo, and > > config, with CONFIG_4KSTACKS enabled. > > this crash too seems to indicate trigger_softirqs()/wakeup_softirqd(). > Somewhere we somehow corrupt the stack and e.g. in oops7.jpg we return > to 00c011ed. Note that it's a right-shifted address that could be one of > these: > > c011ed50 t wakeup_softirqd > c011ed80 t trigger_softirqs > > but it looks pretty weird. DEBUG_STACK_POISON (and the full-debug > .config i sent) could perhaps uncover other types of stack corruptions. > You weren't kidding about the overhead from DEBUG_STACK_POISON. Unfortunately that config causes a triple fault randomly after boot. The machine doesn't crash, or oops, it just resets. This problem has gone from bad to worse :-) -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student:CS/CSim Undergraduate contact:1F2 55 South Clerk Street, Edinburgh. EH8 9PP. - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > c011ed50 t wakeup_softirqd > c011ed80 t trigger_softirqs > > but it looks pretty weird. DEBUG_STACK_POISON (and the full-debug > .config i sent) could perhaps uncover other types of stack > corruptions. there's one more pretty efficient debugging method: echo 1 > /proc/sys/kernel/trace_print_at_crash echo 1 > /proc/sys/kernel/trace_freerunning and then upon oopses the kernel will print a full execution trace that led up to the crash. But this definitely needs a serial console to be usable, as the kernel will print out thousands of trace entries. (also, since it seems your kernel crashes when trying to print out the stacktrace, you'd also have to move the print_traces(task) line within arch/i386/kernel/traps.c:show_trace() to the beginning of that function.) Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan <[EMAIL PROTECTED]> wrote: > Okay, I'll send you the vmlinux from -18 with a new digital photo, and > config, with CONFIG_4KSTACKS enabled. this crash too seems to indicate trigger_softirqs()/wakeup_softirqd(). Somewhere we somehow corrupt the stack and e.g. in oops7.jpg we return to 00c011ed. Note that it's a right-shifted address that could be one of these: c011ed50 t wakeup_softirqd c011ed80 t trigger_softirqs but it looks pretty weird. DEBUG_STACK_POISON (and the full-debug .config i sent) could perhaps uncover other types of stack corruptions. Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan <[EMAIL PROTECTED]> wrote: > I guess also, as you suggested elsewhere in this thread, I could try > an 8K stacks kernel, let openvpn run (even just for 5 minutes, then > close it) and see if I get a stack-footprint dump *for openvpn*, which > so far I've not been able to observe. > > Hopefully this would negate the possibility that there's a > stack-footprint waiting to be generated, but just masked by the crash. indeed, you are right. I think we can exclude the stack-overflow for now. (also, the likelyhood of it not being detected and printed in a safe manner as it happens is very low. We do a stack-overflow test for every function entered, and the threshold is 1024 bytes - more than the biggest (realistic) offenders could cause.) > Is this actually useful to you? yeah. You are triggering a type of crash that is hard to debug. Those are always important to track down, so that we can see whether the debug infrastructure can be improved to make the debugging process much quicker. Next time such a bug could be sporadic, making it close to impossible to debug. if you still have some debugging stamina left then i'd now suggest to try an 'all debugging options enabled' (including the enabling DEBUG_STACK_POISON in kernel/latency.c) run with the latest -51-20 kernel. I've attached a .config with all the debug options set that may matter - it should be ready-to-use for you. Ingo config2.bz2 Description: BZip2 compressed data
Re: Realtime Preemption, 2.6.12, Beginners Guide?
On Saturday 09 Jul 2005 12:58, Ingo Molnar wrote: > * Alistair John Strachan <[EMAIL PROTECTED]> wrote: > > Got this (slightly better) oops. Figured out how to use my camera :-) > > > > http://devzero.co.uk/~alistair/oops6.jpeg > > this was a bit more useful - shows a softirq wakeup. Could you send me > your vmlinux (bzip -9 compressed, via private mail), your gcc generates > a slightly different code layout so i couldnt match up everything that > might be useful. Okay, I'll send you the vmlinux from -18 with a new digital photo, and config, with CONFIG_4KSTACKS enabled. Do you want me to apply the patch blitz you just sent to the list before testing? Those are some impressive stack reductions, the ip_sockglue.c/blkdev_get() ones in combination look promising. > > > Onto your stack-footprint metric. I don't know what the number means, > > but at a guess it's the size of the stack. Unfortunately, if this is > > the case, it's unlikely to be an overflow causing the crash. Here's a > > grep of dmesg just before the crash. > > it could still be near an overflow. To make sure i've changed the oops > printout to also include the current stack left, and the worst-case > stack-left value, and have uploaded the -51-18 kernel - could you try > it? That way we can tell for sure. (note that the maximum-tracker can > not always do an immediate printout of a worst-case - we have to skip > printouts if irqs are disabled. [or we could recurse from within the > scheduler or the printk code] Even in those cases we save the worst-case > stack and print it out as soon as interrupts are enabled again. (The > worst-case stack-left value printed out at oops time is immediate.) I guess also, as you suggested elsewhere in this thread, I could try an 8K stacks kernel, let openvpn run (even just for 5 minutes, then close it) and see if I get a stack-footprint dump *for openvpn*, which so far I've not been able to observe. Hopefully this would negate the possibility that there's a stack-footprint waiting to be generated, but just masked by the crash. Is this actually useful to you? -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student:CS/CSim Undergraduate contact:1F2 55 South Clerk Street, Edinburgh. EH8 9PP. - 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: Realtime Preemption, 2.6.12, Beginners Guide?
> (gdb)
> (gdb) # c0169503, stack size: 408 bytes #
> (gdb)
> (gdb) 0xc0169503 is in blkdev_get (fs/block_dev.c:663).
this patch reduces the stack footprint of blkdev_get() from 408 bytes to
28 bytes. Build and boot-tested.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Index: linux/fs/block_dev.c
===
--- linux.orig/fs/block_dev.c
+++ linux/fs/block_dev.c
@@ -667,14 +667,32 @@ int blkdev_get(struct block_device *bdev
* For now, block device ->open() routine must _not_
* examine anything in 'inode' argument except ->i_rdev.
*/
- struct file fake_file = {};
- struct dentry fake_dentry = {};
- fake_file.f_mode = mode;
- fake_file.f_flags = flags;
- fake_file.f_dentry = _dentry;
- fake_dentry.d_inode = bdev->bd_inode;
-
- return do_open(bdev, _file);
+ struct file *fake_file;
+ struct dentry *fake_dentry;
+ int err = -ENOMEM;
+
+ fake_file = kmalloc(sizeof(*fake_file), GFP_KERNEL);
+ if (!fake_file)
+ goto out;
+ memset(fake_file, 0, sizeof(*fake_file));
+
+ fake_dentry = kmalloc(sizeof(*fake_dentry), GFP_KERNEL);
+ if (!fake_dentry)
+ goto out_free_file;
+ memset(fake_dentry, 0, sizeof(*fake_dentry));
+
+ fake_file->f_mode = mode;
+ fake_file->f_flags = flags;
+ fake_file->f_dentry = fake_dentry;
+ fake_dentry->d_inode = bdev->bd_inode;
+
+ err = do_open(bdev, fake_file);
+
+ kfree(fake_dentry);
+out_free_file:
+ kfree(fake_file);
+out:
+ return err;
}
EXPORT_SYMBOL(blkdev_get);
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
> (gdb)
> (gdb) # c02a0a26, stack size: 416 bytes #
> (gdb)
> (gdb) 0xc02a0a26 is in pcmcia_device_query (drivers/pcmcia/ds.c:436).
this patch reduces the stack footprint of pcmcia_device_query() from 416
bytes to 36 bytes. (patch only build-tested)
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Index: linux/drivers/pcmcia/ds.c
===
--- linux.orig/drivers/pcmcia/ds.c
+++ linux/drivers/pcmcia/ds.c
@@ -436,9 +436,13 @@ static int pcmcia_device_query(struct pc
{
cistpl_manfid_t manf_id;
cistpl_funcid_t func_id;
- cistpl_vers_1_t vers1;
+ cistpl_vers_1_t *vers1;
unsigned int i;
+ vers1 = kmalloc(sizeof(*vers1), GFP_KERNEL);
+ if (!vers1)
+ return -ENOMEM;
+
if (!pccard_read_tuple(p_dev->socket, p_dev->func,
CISTPL_MANFID, _id)) {
p_dev->manf_id = manf_id.manf;
@@ -455,23 +459,30 @@ static int pcmcia_device_query(struct pc
/* rule of thumb: cards with no FUNCID, but with
* common memory device geometry information, are
* probably memory cards (from pcmcia-cs) */
- cistpl_device_geo_t devgeo;
+ cistpl_device_geo_t *devgeo;
+
+ devgeo = kmalloc(sizeof(*devgeo), GFP_KERNEL);
+ if (!devgeo) {
+ kfree(vers1);
+ return -ENOMEM;
+ }
if (!pccard_read_tuple(p_dev->socket, p_dev->func,
- CISTPL_DEVICE_GEO, )) {
+ CISTPL_DEVICE_GEO, devgeo)) {
ds_dbg(0, "mem device geometry probably means "
"FUNCID_MEMORY\n");
p_dev->func_id = CISTPL_FUNCID_MEMORY;
p_dev->has_func_id = 1;
}
+ kfree(devgeo);
}
if (!pccard_read_tuple(p_dev->socket, p_dev->func, CISTPL_VERS_1,
- )) {
- for (i=0; i < vers1.ns; i++) {
+ vers1)) {
+ for (i=0; i < vers1->ns; i++) {
char *tmp;
unsigned int length;
- tmp = vers1.str + vers1.ofs[i];
+ tmp = vers1->str + vers1->ofs[i];
length = strlen(tmp) + 1;
if ((length < 3) || (length > 255))
@@ -487,6 +498,7 @@ static int pcmcia_device_query(struct pc
}
}
+ kfree(vers1);
return 0;
}
@@ -856,7 +868,9 @@ static int bind_request(struct pcmcia_bu
rescan:
p_dev->cardmgr = p_drv;
- pcmcia_device_query(p_dev);
+ ret = pcmcia_device_query(p_dev);
+ if (ret)
+ goto err_put_module;
/*
* Prevent this racing with a card insertion.
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
> (gdb)
> (gdb) # c02decd6, stack size: 460 bytes #
> (gdb)
> (gdb) 0xc02decd6 is in ip_getsockopt (net/ipv4/ip_sockglue.c:877).
this patch reduces the stack footprint of ip_getsockopt() from 460 bytes
to 188 bytes. (note: needs review & testing because i did not excercise
this multicast codepath.)
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Index: linux/net/ipv4/ip_sockglue.c
===
--- linux.orig/net/ipv4/ip_sockglue.c
+++ linux/net/ipv4/ip_sockglue.c
@@ -1006,20 +1024,28 @@ int ip_getsockopt(struct sock *sk, int l
}
case MCAST_MSFILTER:
{
- struct group_filter gsf;
+ struct group_filter *gsf;
int err;
+ gsf = kmalloc(sizeof(*gsf), GFP_KERNEL);
+ if (!gsf) {
+ release_sock(sk);
+ return -ENOMEM;
+ }
if (len < GROUP_FILTER_SIZE(0)) {
release_sock(sk);
+ kfree(gsf);
return -EINVAL;
}
- if (copy_from_user(, optval, GROUP_FILTER_SIZE(0)))
{
+ if (copy_from_user(gsf, optval, GROUP_FILTER_SIZE(0))) {
release_sock(sk);
+ kfree(gsf);
return -EFAULT;
}
- err = ip_mc_gsfget(sk, ,
+ err = ip_mc_gsfget(sk, gsf,
(struct group_filter __user *)optval, optlen);
release_sock(sk);
+ kfree(gsf);
return err;
}
case IP_PKTOPTIONS:
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
> (gdb)
> (gdb) # c02de0f3, stack size: 572 bytes #
> (gdb)
> (gdb) 0xc02de0f3 is in ip_setsockopt (net/ipv4/ip_sockglue.c:385).
this patch reduces ip_setsockopt's stack footprint from 572 bytes to 164
bytes. (Note: needs review and testing as i could not excercise this
multicast codepath.)
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Index: linux/net/ipv4/ip_sockglue.c
===
--- linux.orig/net/ipv4/ip_sockglue.c
+++ linux/net/ipv4/ip_sockglue.c
@@ -691,52 +691,65 @@ int ip_setsockopt(struct sock *sk, int l
case MCAST_JOIN_GROUP:
case MCAST_LEAVE_GROUP:
{
- struct group_req greq;
+ struct group_req *greq;
struct sockaddr_in *psin;
struct ip_mreqn mreq;
+ err = -ENOMEM;
+ greq = kmalloc(sizeof(*greq), GFP_KERNEL);
+ if (!greq)
+ break;
if (optlen < sizeof(struct group_req))
- goto e_inval;
+ goto free_greq_e_inval;
err = -EFAULT;
- if(copy_from_user(, optval, sizeof(greq)))
- break;
- psin = (struct sockaddr_in *)_group;
+ if(copy_from_user(greq, optval, sizeof(*greq)))
+ goto free_greq_break;
+ psin = (struct sockaddr_in *)>gr_group;
if (psin->sin_family != AF_INET)
- goto e_inval;
+ goto free_greq_e_inval;
memset(, 0, sizeof(mreq));
mreq.imr_multiaddr = psin->sin_addr;
- mreq.imr_ifindex = greq.gr_interface;
+ mreq.imr_ifindex = greq->gr_interface;
if (optname == MCAST_JOIN_GROUP)
err = ip_mc_join_group(sk, );
else
err = ip_mc_leave_group(sk, );
+free_greq_break:
+ kfree(greq);
break;
+free_greq_e_inval:
+ kfree(greq);
+ goto e_inval;
}
case MCAST_JOIN_SOURCE_GROUP:
case MCAST_LEAVE_SOURCE_GROUP:
case MCAST_BLOCK_SOURCE:
case MCAST_UNBLOCK_SOURCE:
{
- struct group_source_req greqs;
+ struct group_source_req *greqs;
struct ip_mreq_source mreqs;
struct sockaddr_in *psin;
int omode, add;
+ err = -ENOMEM;
+ greqs = kmalloc(sizeof(*greqs), GFP_KERNEL);
+ if (!greqs)
+ break;
if (optlen != sizeof(struct group_source_req))
- goto e_inval;
- if (copy_from_user(, optval, sizeof(greqs))) {
+ goto free_greqs_e_inval;
+ if (copy_from_user(, optval, sizeof(*greqs))) {
err = -EFAULT;
- break;
+ goto free_greqs_break;
}
- if (greqs.gsr_group.ss_family != AF_INET ||
- greqs.gsr_source.ss_family != AF_INET) {
+ if (greqs->gsr_group.ss_family != AF_INET ||
+ greqs->gsr_source.ss_family != AF_INET) {
err = -EADDRNOTAVAIL;
- break;
+ goto free_greqs_break;
}
- psin = (struct sockaddr_in *)_group;
+ psin = (struct sockaddr_in *)>gsr_group;
mreqs.imr_multiaddr = psin->sin_addr.s_addr;
- psin = (struct sockaddr_in *)_source;
+ psin = (struct sockaddr_in *)>gsr_source;
mreqs.imr_sourceaddr = psin->sin_addr.s_addr;
mreqs.imr_interface = 0; /* use index for mc_source */
@@ -749,14 +762,14 @@ int ip_setsockopt(struct sock *sk, int l
} else if (optname == MCAST_JOIN_SOURCE_GROUP) {
struct ip_mreqn mreq;
- psin = (struct sockaddr_in *)_group;
+ psin = (struct sockaddr_in *)>gsr_group;
mreq.imr_multiaddr = psin->sin_addr;
Re: Realtime Preemption, 2.6.12, Beginners Guide?
> (gdb)
> (gdb) # c0228ec3, stack size: 764 bytes #
> (gdb)
> (gdb) 0xc0228ec3 is in calc_mode_timings (drivers/video/fbmon.c:317).
fix below.
Ingo
--
quick hack to remove a 764 bytes stack footprint from fbmon.c. Codepath
is most likely serialized but with the semaphore it's for sure.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Index: linux/drivers/video/fbmon.c
===
--- linux.orig/drivers/video/fbmon.c
+++ linux/drivers/video/fbmon.c
@@ -315,9 +315,11 @@ static int edid_is_monitor_block(unsigne
static void calc_mode_timings(int xres, int yres, int refresh, struct
fb_videomode *mode)
{
- struct fb_var_screeninfo var;
- struct fb_info info;
-
+ static struct fb_var_screeninfo var;
+ static struct fb_info info;
+ static DECLARE_MUTEX(fb_lock);
+
+ down(_lock);
var.xres = xres;
var.yres = yres;
fb_get_mode(FB_VSYNCTIMINGS | FB_IGNOREMON,
@@ -334,6 +336,7 @@ static void calc_mode_timings(int xres,
mode->vsync_len = var.vsync_len;
mode->vmode = 0;
mode->sync = 0;
+ up(_lock);
}
static int get_est_timing(unsigned char *block, struct fb_videomode *mode)
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan <[EMAIL PROTECTED]> wrote:
> | new stack-footprint maximum: krootimage/2846, 1204 bytes.
> | new stack-footprint maximum: konqueror/2938, 836 bytes.
btw., that's quite borderline to overflow. STACK_WARN is 512 bytes, i.e.
another 324 bytes of stack footprint and you'd trigger an overflow
warning. The worst-case stack footprint that your .config has is 1300+
bytes (zlib). Does openvpn trigger any zlib functionality? Also, the
worst-case stack footprint you had was an XFS trace. Below i've attached
a printout of all stackframes that are larger than 256 bytes (using your
.config).
Ingo
-
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 12
EXTRAVERSION = -RT-V0.7.51-18
(gdb)
(gdb)
(gdb) # c049d976, stack size: 1368 bytes #
(gdb)
(gdb) 0xc049d976 is in inflate_dynamic (inflate.c:765).
760 /*
761 * We use `noinline' here to prevent gcc-3.5 from using too much stack
space
762 */
763 STATIC int noinline INIT inflate_dynamic(void)
764 /* decompress an inflated type 2 (dynamic Huffman codes) block. */
765 {
766 int i;/* temporary variables */
767 unsigned j;
768 unsigned l; /* last length */
769 unsigned m; /* mask for bit lengths table */
(gdb) 770 unsigned n; /* number of lengths to get */
771 struct huft *tl; /* literal/length code table */
772 struct huft *td; /* distance code table */
773 int bl; /* lookup bits for tl */
774 int bd; /* lookup bits for td */
775 unsigned nb; /* number of bit length codes */
776 unsigned nl; /* number of literal/length codes */
777 unsigned nd; /* number of distance codes */
778 #ifdef PKZIP_BUG_WORKAROUND
779 unsigned ll[288+32]; /* literal/length and distance code lengths */
(gdb)
(gdb)
(gdb) # c049d7b5, stack size: 1196 bytes #
(gdb)
(gdb) 0xc049d7b5 is in inflate_fixed (inflate.c:711).
706 */
707 STATIC int noinline INIT inflate_fixed(void)
708 /* decompress an inflated type 1 (fixed Huffman codes) block. We should
709either replace this with a custom decoder, or at least precompute the
710Huffman tables. */
711 {
712 int i;/* temporary variable */
713 struct huft *tl; /* literal/length code table */
714 struct huft *td; /* distance code table */
715 int bl; /* lookup bits for tl */
(gdb) 716 int bd; /* lookup bits for td */
717 unsigned l[288]; /* length list for huft_build */
718
719 DEBG("xres = xres;
326 mode->yres = yres;
327 mode->pixclock = var.pixclock;
328 mode->refresh = refresh;
329 mode->left_margin = var.left_margin;
330 mode->right_margin = var.right_margin;
331 mode->upper_margin = var.upper_margin;
(gdb)
(gdb)
(gdb) # c0208e26, stack size: 600 bytes #
(gdb)
(gdb) 0xc0208e26 is in semctl_main (ipc/sem.c:586).
581 sem_unlock(sma);
582 return err;
583 }
584
585 static int semctl_main(int semid, int semnum, int cmd, int version,
union semun arg)
586 {
587 struct sem_array *sma;
588 struct sem* curr;
589 int err;
590 ushort fast_sem_io[SEMMSL_FAST];
(gdb) 591 ushort* sem_io = fast_sem_io;
592 int nsems;
593
594 sma = sem_lock(semid);
595 if(sma==NULL)
596 return -EINVAL;
597
598 nsems = sma->sem_nsems;
599
600 err=-EIDRM;
(gdb)
(gdb)
(gdb) # c02de0f3, stack size: 572 bytes #
(gdb)
(gdb) 0xc02de0f3 is in ip_setsockopt (net/ipv4/ip_sockglue.c:385).
380 * Socket option code for IP. This is the end of the line after
any TCP,UDP etc options on
381 * an IP socket.
382 */
383
384 int ip_setsockopt(struct sock *sk, int level, int optname, char __user
*optval, int optlen)
385 {
386 struct inet_sock *inet = inet_sk(sk);
387 int val=0,err;
388
389 if (level != SOL_IP)
(gdb) 390 return -ENOPROTOOPT;
391
392 if (((1< sc_semopm)
1070return -E2BIG;
1071if(nsops > SEMOPM_FAST) {
(gdb)
(gdb)
(gdb) # c02decd6, stack size: 460 bytes #
(gdb)
(gdb) 0xc02decd6 is in ip_getsockopt (net/ipv4/ip_sockglue.c:877).
872 * Get the options. Note for future reference. The GET of IP
Re: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan <[EMAIL PROTECTED]> wrote: > Got this (slightly better) oops. Figured out how to use my camera :-) > > http://devzero.co.uk/~alistair/oops6.jpeg this was a bit more useful - shows a softirq wakeup. Could you send me your vmlinux (bzip -9 compressed, via private mail), your gcc generates a slightly different code layout so i couldnt match up everything that might be useful. > Onto your stack-footprint metric. I don't know what the number means, > but at a guess it's the size of the stack. Unfortunately, if this is > the case, it's unlikely to be an overflow causing the crash. Here's a > grep of dmesg just before the crash. it could still be near an overflow. To make sure i've changed the oops printout to also include the current stack left, and the worst-case stack-left value, and have uploaded the -51-18 kernel - could you try it? That way we can tell for sure. (note that the maximum-tracker can not always do an immediate printout of a worst-case - we have to skip printouts if irqs are disabled. [or we could recurse from within the scheduler or the printk code] Even in those cases we save the worst-case stack and print it out as soon as interrupts are enabled again. (The worst-case stack-left value printed out at oops time is immediate.) Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan [EMAIL PROTECTED] wrote: Got this (slightly better) oops. Figured out how to use my camera :-) http://devzero.co.uk/~alistair/oops6.jpeg this was a bit more useful - shows a softirq wakeup. Could you send me your vmlinux (bzip -9 compressed, via private mail), your gcc generates a slightly different code layout so i couldnt match up everything that might be useful. Onto your stack-footprint metric. I don't know what the number means, but at a guess it's the size of the stack. Unfortunately, if this is the case, it's unlikely to be an overflow causing the crash. Here's a grep of dmesg just before the crash. it could still be near an overflow. To make sure i've changed the oops printout to also include the current stack left, and the worst-case stack-left value, and have uploaded the -51-18 kernel - could you try it? That way we can tell for sure. (note that the maximum-tracker can not always do an immediate printout of a worst-case - we have to skip printouts if irqs are disabled. [or we could recurse from within the scheduler or the printk code] Even in those cases we save the worst-case stack and print it out as soon as interrupts are enabled again. (The worst-case stack-left value printed out at oops time is immediate.) Ingo - 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: Realtime Preemption, 2.6.12, Beginners Guide?
* Alistair John Strachan [EMAIL PROTECTED] wrote:
| new stack-footprint maximum: krootimage/2846, 1204 bytes.
| new stack-footprint maximum: konqueror/2938, 836 bytes.
btw., that's quite borderline to overflow. STACK_WARN is 512 bytes, i.e.
another 324 bytes of stack footprint and you'd trigger an overflow
warning. The worst-case stack footprint that your .config has is 1300+
bytes (zlib). Does openvpn trigger any zlib functionality? Also, the
worst-case stack footprint you had was an XFS trace. Below i've attached
a printout of all stackframes that are larger than 256 bytes (using your
.config).
Ingo
-
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 12
EXTRAVERSION = -RT-V0.7.51-18
(gdb)
(gdb)
(gdb) # c049d976, stack size: 1368 bytes #
(gdb)
(gdb) 0xc049d976 is in inflate_dynamic (inflate.c:765).
760 /*
761 * We use `noinline' here to prevent gcc-3.5 from using too much stack
space
762 */
763 STATIC int noinline INIT inflate_dynamic(void)
764 /* decompress an inflated type 2 (dynamic Huffman codes) block. */
765 {
766 int i;/* temporary variables */
767 unsigned j;
768 unsigned l; /* last length */
769 unsigned m; /* mask for bit lengths table */
(gdb) 770 unsigned n; /* number of lengths to get */
771 struct huft *tl; /* literal/length code table */
772 struct huft *td; /* distance code table */
773 int bl; /* lookup bits for tl */
774 int bd; /* lookup bits for td */
775 unsigned nb; /* number of bit length codes */
776 unsigned nl; /* number of literal/length codes */
777 unsigned nd; /* number of distance codes */
778 #ifdef PKZIP_BUG_WORKAROUND
779 unsigned ll[288+32]; /* literal/length and distance code lengths */
(gdb)
(gdb)
(gdb) # c049d7b5, stack size: 1196 bytes #
(gdb)
(gdb) 0xc049d7b5 is in inflate_fixed (inflate.c:711).
706 */
707 STATIC int noinline INIT inflate_fixed(void)
708 /* decompress an inflated type 1 (fixed Huffman codes) block. We should
709either replace this with a custom decoder, or at least precompute the
710Huffman tables. */
711 {
712 int i;/* temporary variable */
713 struct huft *tl; /* literal/length code table */
714 struct huft *td; /* distance code table */
715 int bl; /* lookup bits for tl */
(gdb) 716 int bd; /* lookup bits for td */
717 unsigned l[288]; /* length list for huft_build */
718
719 DEBG(fix);
720
721 /* set up literal table */
722 for (i = 0; i 144; i++)
723 l[i] = 8;
724 for (; i 256; i++)
725 l[i] = 9;
(gdb)
(gdb)
(gdb) # c0228ec3, stack size: 764 bytes #
(gdb)
(gdb) 0xc0228ec3 is in calc_mode_timings (drivers/video/fbmon.c:317).
312 else
313 return 0;
314 }
315
316 static void calc_mode_timings(int xres, int yres, int refresh, struct
fb_videomode *mode)
317 {
318 struct fb_var_screeninfo var;
319 struct fb_info info;
320
321 var.xres = xres;
(gdb) 322 var.yres = yres;
323 fb_get_mode(FB_VSYNCTIMINGS | FB_IGNOREMON,
324 refresh, var, info);
325 mode-xres = xres;
326 mode-yres = yres;
327 mode-pixclock = var.pixclock;
328 mode-refresh = refresh;
329 mode-left_margin = var.left_margin;
330 mode-right_margin = var.right_margin;
331 mode-upper_margin = var.upper_margin;
(gdb)
(gdb)
(gdb) # c0208e26, stack size: 600 bytes #
(gdb)
(gdb) 0xc0208e26 is in semctl_main (ipc/sem.c:586).
581 sem_unlock(sma);
582 return err;
583 }
584
585 static int semctl_main(int semid, int semnum, int cmd, int version,
union semun arg)
586 {
587 struct sem_array *sma;
588 struct sem* curr;
589 int err;
590 ushort fast_sem_io[SEMMSL_FAST];
(gdb) 591 ushort* sem_io = fast_sem_io;
592 int nsems;
593
594 sma = sem_lock(semid);
595 if(sma==NULL)
596 return -EINVAL;
597
598 nsems = sma-sem_nsems;
599
600 err=-EIDRM;
(gdb)
(gdb)
(gdb) # c02de0f3, stack size: 572 bytes #
(gdb)
(gdb) 0xc02de0f3 is in ip_setsockopt (net/ipv4/ip_sockglue.c:385).
380 *
Re: Realtime Preemption, 2.6.12, Beginners Guide?
(gdb)
(gdb) # c0228ec3, stack size: 764 bytes #
(gdb)
(gdb) 0xc0228ec3 is in calc_mode_timings (drivers/video/fbmon.c:317).
fix below.
Ingo
--
quick hack to remove a 764 bytes stack footprint from fbmon.c. Codepath
is most likely serialized but with the semaphore it's for sure.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Index: linux/drivers/video/fbmon.c
===
--- linux.orig/drivers/video/fbmon.c
+++ linux/drivers/video/fbmon.c
@@ -315,9 +315,11 @@ static int edid_is_monitor_block(unsigne
static void calc_mode_timings(int xres, int yres, int refresh, struct
fb_videomode *mode)
{
- struct fb_var_screeninfo var;
- struct fb_info info;
-
+ static struct fb_var_screeninfo var;
+ static struct fb_info info;
+ static DECLARE_MUTEX(fb_lock);
+
+ down(fb_lock);
var.xres = xres;
var.yres = yres;
fb_get_mode(FB_VSYNCTIMINGS | FB_IGNOREMON,
@@ -334,6 +336,7 @@ static void calc_mode_timings(int xres,
mode-vsync_len = var.vsync_len;
mode-vmode = 0;
mode-sync = 0;
+ up(fb_lock);
}
static int get_est_timing(unsigned char *block, struct fb_videomode *mode)
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
(gdb)
(gdb) # c02de0f3, stack size: 572 bytes #
(gdb)
(gdb) 0xc02de0f3 is in ip_setsockopt (net/ipv4/ip_sockglue.c:385).
this patch reduces ip_setsockopt's stack footprint from 572 bytes to 164
bytes. (Note: needs review and testing as i could not excercise this
multicast codepath.)
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Index: linux/net/ipv4/ip_sockglue.c
===
--- linux.orig/net/ipv4/ip_sockglue.c
+++ linux/net/ipv4/ip_sockglue.c
@@ -691,52 +691,65 @@ int ip_setsockopt(struct sock *sk, int l
case MCAST_JOIN_GROUP:
case MCAST_LEAVE_GROUP:
{
- struct group_req greq;
+ struct group_req *greq;
struct sockaddr_in *psin;
struct ip_mreqn mreq;
+ err = -ENOMEM;
+ greq = kmalloc(sizeof(*greq), GFP_KERNEL);
+ if (!greq)
+ break;
if (optlen sizeof(struct group_req))
- goto e_inval;
+ goto free_greq_e_inval;
err = -EFAULT;
- if(copy_from_user(greq, optval, sizeof(greq)))
- break;
- psin = (struct sockaddr_in *)greq.gr_group;
+ if(copy_from_user(greq, optval, sizeof(*greq)))
+ goto free_greq_break;
+ psin = (struct sockaddr_in *)greq-gr_group;
if (psin-sin_family != AF_INET)
- goto e_inval;
+ goto free_greq_e_inval;
memset(mreq, 0, sizeof(mreq));
mreq.imr_multiaddr = psin-sin_addr;
- mreq.imr_ifindex = greq.gr_interface;
+ mreq.imr_ifindex = greq-gr_interface;
if (optname == MCAST_JOIN_GROUP)
err = ip_mc_join_group(sk, mreq);
else
err = ip_mc_leave_group(sk, mreq);
+free_greq_break:
+ kfree(greq);
break;
+free_greq_e_inval:
+ kfree(greq);
+ goto e_inval;
}
case MCAST_JOIN_SOURCE_GROUP:
case MCAST_LEAVE_SOURCE_GROUP:
case MCAST_BLOCK_SOURCE:
case MCAST_UNBLOCK_SOURCE:
{
- struct group_source_req greqs;
+ struct group_source_req *greqs;
struct ip_mreq_source mreqs;
struct sockaddr_in *psin;
int omode, add;
+ err = -ENOMEM;
+ greqs = kmalloc(sizeof(*greqs), GFP_KERNEL);
+ if (!greqs)
+ break;
if (optlen != sizeof(struct group_source_req))
- goto e_inval;
- if (copy_from_user(greqs, optval, sizeof(greqs))) {
+ goto free_greqs_e_inval;
+ if (copy_from_user(greqs, optval, sizeof(*greqs))) {
err = -EFAULT;
- break;
+ goto free_greqs_break;
}
- if (greqs.gsr_group.ss_family != AF_INET ||
- greqs.gsr_source.ss_family != AF_INET) {
+ if (greqs-gsr_group.ss_family != AF_INET ||
+ greqs-gsr_source.ss_family != AF_INET) {
err = -EADDRNOTAVAIL;
- break;
+ goto free_greqs_break;
}
- psin = (struct sockaddr_in *)greqs.gsr_group;
+ psin = (struct sockaddr_in *)greqs-gsr_group;
mreqs.imr_multiaddr = psin-sin_addr.s_addr;
- psin = (struct sockaddr_in *)greqs.gsr_source;
+ psin = (struct sockaddr_in *)greqs-gsr_source;
mreqs.imr_sourceaddr = psin-sin_addr.s_addr;
mreqs.imr_interface = 0; /* use index for mc_source */
@@ -749,14 +762,14 @@ int ip_setsockopt(struct sock *sk, int l
} else if (optname == MCAST_JOIN_SOURCE_GROUP) {
struct ip_mreqn mreq;
- psin = (struct sockaddr_in *)greqs.gsr_group;
+ psin = (struct sockaddr_in *)greqs-gsr_group;
mreq.imr_multiaddr =
Re: Realtime Preemption, 2.6.12, Beginners Guide?
(gdb)
(gdb) # c02decd6, stack size: 460 bytes #
(gdb)
(gdb) 0xc02decd6 is in ip_getsockopt (net/ipv4/ip_sockglue.c:877).
this patch reduces the stack footprint of ip_getsockopt() from 460 bytes
to 188 bytes. (note: needs review testing because i did not excercise
this multicast codepath.)
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Index: linux/net/ipv4/ip_sockglue.c
===
--- linux.orig/net/ipv4/ip_sockglue.c
+++ linux/net/ipv4/ip_sockglue.c
@@ -1006,20 +1024,28 @@ int ip_getsockopt(struct sock *sk, int l
}
case MCAST_MSFILTER:
{
- struct group_filter gsf;
+ struct group_filter *gsf;
int err;
+ gsf = kmalloc(sizeof(*gsf), GFP_KERNEL);
+ if (!gsf) {
+ release_sock(sk);
+ return -ENOMEM;
+ }
if (len GROUP_FILTER_SIZE(0)) {
release_sock(sk);
+ kfree(gsf);
return -EINVAL;
}
- if (copy_from_user(gsf, optval, GROUP_FILTER_SIZE(0)))
{
+ if (copy_from_user(gsf, optval, GROUP_FILTER_SIZE(0))) {
release_sock(sk);
+ kfree(gsf);
return -EFAULT;
}
- err = ip_mc_gsfget(sk, gsf,
+ err = ip_mc_gsfget(sk, gsf,
(struct group_filter __user *)optval, optlen);
release_sock(sk);
+ kfree(gsf);
return err;
}
case IP_PKTOPTIONS:
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
(gdb)
(gdb) # c02a0a26, stack size: 416 bytes #
(gdb)
(gdb) 0xc02a0a26 is in pcmcia_device_query (drivers/pcmcia/ds.c:436).
this patch reduces the stack footprint of pcmcia_device_query() from 416
bytes to 36 bytes. (patch only build-tested)
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Index: linux/drivers/pcmcia/ds.c
===
--- linux.orig/drivers/pcmcia/ds.c
+++ linux/drivers/pcmcia/ds.c
@@ -436,9 +436,13 @@ static int pcmcia_device_query(struct pc
{
cistpl_manfid_t manf_id;
cistpl_funcid_t func_id;
- cistpl_vers_1_t vers1;
+ cistpl_vers_1_t *vers1;
unsigned int i;
+ vers1 = kmalloc(sizeof(*vers1), GFP_KERNEL);
+ if (!vers1)
+ return -ENOMEM;
+
if (!pccard_read_tuple(p_dev-socket, p_dev-func,
CISTPL_MANFID, manf_id)) {
p_dev-manf_id = manf_id.manf;
@@ -455,23 +459,30 @@ static int pcmcia_device_query(struct pc
/* rule of thumb: cards with no FUNCID, but with
* common memory device geometry information, are
* probably memory cards (from pcmcia-cs) */
- cistpl_device_geo_t devgeo;
+ cistpl_device_geo_t *devgeo;
+
+ devgeo = kmalloc(sizeof(*devgeo), GFP_KERNEL);
+ if (!devgeo) {
+ kfree(vers1);
+ return -ENOMEM;
+ }
if (!pccard_read_tuple(p_dev-socket, p_dev-func,
- CISTPL_DEVICE_GEO, devgeo)) {
+ CISTPL_DEVICE_GEO, devgeo)) {
ds_dbg(0, mem device geometry probably means
FUNCID_MEMORY\n);
p_dev-func_id = CISTPL_FUNCID_MEMORY;
p_dev-has_func_id = 1;
}
+ kfree(devgeo);
}
if (!pccard_read_tuple(p_dev-socket, p_dev-func, CISTPL_VERS_1,
- vers1)) {
- for (i=0; i vers1.ns; i++) {
+ vers1)) {
+ for (i=0; i vers1-ns; i++) {
char *tmp;
unsigned int length;
- tmp = vers1.str + vers1.ofs[i];
+ tmp = vers1-str + vers1-ofs[i];
length = strlen(tmp) + 1;
if ((length 3) || (length 255))
@@ -487,6 +498,7 @@ static int pcmcia_device_query(struct pc
}
}
+ kfree(vers1);
return 0;
}
@@ -856,7 +868,9 @@ static int bind_request(struct pcmcia_bu
rescan:
p_dev-cardmgr = p_drv;
- pcmcia_device_query(p_dev);
+ ret = pcmcia_device_query(p_dev);
+ if (ret)
+ goto err_put_module;
/*
* Prevent this racing with a card insertion.
-
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: Realtime Preemption, 2.6.12, Beginners Guide?
(gdb)
(gdb) # c0169503, stack size: 408 bytes #
(gdb)
(gdb) 0xc0169503 is in blkdev_get (fs/block_dev.c:663).
this patch reduces the stack footprint of blkdev_get() from 408 bytes to
28 bytes. Build and boot-tested.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Index: linux/fs/block_dev.c
===
--- linux.orig/fs/block_dev.c
+++ linux/fs/block_dev.c
@@ -667,14 +667,32 @@ int blkdev_get(struct block_device *bdev
* For now, block device -open() routine must _not_
* examine anything in 'inode' argument except -i_rdev.
*/
- struct file fake_file = {};
- struct dentry fake_dentry = {};
- fake_file.f_mode = mode;
- fake_file.f_flags = flags;
- fake_file.f_dentry = fake_dentry;
- fake_dentry.d_inode = bdev-bd_inode;
-
- return do_open(bdev, fake_file);
+ struct file *fake_file;
+ struct dentry *fake_dentry;
+ int err = -ENOMEM;
+
+ fake_file = kmalloc(sizeof(*fake_file), GFP_KERNEL);
+ if (!fake_file)
+ goto out;
+ memset(fake_file, 0, sizeof(*fake_file));
+
+ fake_dentry = kmalloc(sizeof(*fake_dentry), GFP_KERNEL);
+ if (!fake_dentry)
+ goto out_free_file;
+ memset(fake_dentry, 0, sizeof(*fake_dentry));
+
+ fake_file-f_mode = mode;
+ fake_file-f_flags = flags;
+ fake_file-f_dentry = fake_dentry;
+ fake_dentry-d_inode = bdev-bd_inode;
+
+ err = do_open(bdev, fake_file);
+
+ kfree(fake_dentry);
+out_free_file:
+ kfree(fake_file);
+out:
+ return err;
}
EXPORT_SYMBOL(blkdev_get);
-
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/
