Re: patch-2.6.21.3-rt9 misnamed?
Ingo Molnar wrote: > * K.R. Foley <[EMAIL PROTECTED]> wrote: > >> Ingo Molnar wrote: >>> * K.R. Foley <[EMAIL PROTECTED]> wrote: >>> >>>> Ingo, >>>> >>>> I believe that patch-2.6.21.3-rt9 is misnamed. It applies cleanly to >>>> 2.6.21 but seems to contain stuff that is already in 2.6.21.3. >>> yes - it includes all of 2.6.21.3. >>> >>> Ingo >>> >> So actually it is not really misnamed, it's just done a bit >> differently than previous versions. Sorry. > > yeah. Maybe we should make the 2.6.21.3 -rt patches relative to 2.6.21.3 > - but that would be one extra patching step for people who already have > a 2.6.21 tree. But ... maybe that makes the most sense after all. > > Ingo > Well don't change any of this on my account. Whatever is easiest for everyone else is fine with me. I was merely pointing it out to possibly help someone else out rather than as a complaint. -- 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: patch-2.6.21.3-rt9 misnamed?
Ingo Molnar wrote: > * K.R. Foley <[EMAIL PROTECTED]> wrote: > >> Ingo, >> >> I believe that patch-2.6.21.3-rt9 is misnamed. It applies cleanly to >> 2.6.21 but seems to contain stuff that is already in 2.6.21.3. > > yes - it includes all of 2.6.21.3. > > Ingo > So actually it is not really misnamed, it's just done a bit differently than previous versions. Sorry. -- 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/
patch-2.6.21.3-rt9 misnamed?
Ingo, I believe that patch-2.6.21.3-rt9 is misnamed. It applies cleanly to 2.6.21 but seems to contain stuff that is already in 2.6.21.3. -- 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/
patch-2.6.21.3-rt9 misnamed?
Ingo, I believe that patch-2.6.21.3-rt9 is misnamed. It applies cleanly to 2.6.21 but seems to contain stuff that is already in 2.6.21.3. -- 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: patch-2.6.21.3-rt9 misnamed?
Ingo Molnar wrote: * K.R. Foley [EMAIL PROTECTED] wrote: Ingo, I believe that patch-2.6.21.3-rt9 is misnamed. It applies cleanly to 2.6.21 but seems to contain stuff that is already in 2.6.21.3. yes - it includes all of 2.6.21.3. Ingo So actually it is not really misnamed, it's just done a bit differently than previous versions. Sorry. -- 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: patch-2.6.21.3-rt9 misnamed?
Ingo Molnar wrote: * K.R. Foley [EMAIL PROTECTED] wrote: Ingo Molnar wrote: * K.R. Foley [EMAIL PROTECTED] wrote: Ingo, I believe that patch-2.6.21.3-rt9 is misnamed. It applies cleanly to 2.6.21 but seems to contain stuff that is already in 2.6.21.3. yes - it includes all of 2.6.21.3. Ingo So actually it is not really misnamed, it's just done a bit differently than previous versions. Sorry. yeah. Maybe we should make the 2.6.21.3 -rt patches relative to 2.6.21.3 - but that would be one extra patching step for people who already have a 2.6.21 tree. But ... maybe that makes the most sense after all. Ingo Well don't change any of this on my account. Whatever is easiest for everyone else is fine with me. I was merely pointing it out to possibly help someone else out rather than as a complaint. -- 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: Problem with 2.6.20 based kernels on SUSE 9.3
Sorry it has taken me so long to get back to this. I did finally make some time to dig into this more. roland wrote: >> Waiting for mandatory devices: eth-id-00:01:6c:ad:2b:c9 >> 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 1 0 >>eth-id-00:01:6c:ad:2b:c9No interface found >> failedSetting up service network . . . . . . . > > I had such issues when using suse 9.3 inside vmware very often - > typically removing network configuration completely in yast and > re-adding it fixed it for me - but sometimes it re-appeared, though - > and i never knew, why. > > Due to lack of time, i never dug into the device detection routines in > depth, but i assume there must be some issue in older suse with that > routines around "Waiting for mandatory devices" . > It seems, that this has gone better in more recent distros, but i see > that problem from time to time. > > You may also try setting MODULE_LOADED_ON_BOOT in /etc/sysconfig/kernel > , please report if this helps It does resolve the issue to add the modules to MODULES_LOADED_ON_BOOT. It also works to add hal and dbus to the dependencies of /etc/init.d/network like they are in SUSE 10.1. Thanks again. > > ## Path:System/Kernel > ## Description: Modules to load after initial boot > ## Type:string > ## ServiceRestart: boot.loadmodules > # > # This variable contains the list of modules to be loaded > # once the main filesystem is active > # > MODULES_LOADED_ON_BOOT="" > > > Just came across this one - maybe it`s worth taking a look: > http://en.opensuse.org/SDB:Waiting_for_Mandatory_Device > > regards > roland > > > > > > > List: linux-kernel > Subject:Problem with 2.6.20 based kernels on SUSE 9.3 > From: "K.R. Foley" > Date: 2007-02-12 15:51:51 > Message-ID: 45D08D17.8050808 () cybsft ! com > [Download message RAW] > > I am having a problem with 2.6.20 based kernels on SUSE 9.3. It boots > fine except that the network card is not detected at boot time. After > the system boots I can "modprobe " and the network comes up > fine. > > I am having this same problem on two different Suse 9.3 systems, one is > a a dual Xeon the other is an AMD Athlon. I have no such problems on > Suse 10.1 systems on similar hardware. Kernels prior to 2.6.20-rc? work > fine on these systems. > > The dual Xeon is using a 3Com card with the sk98lin driver. > :06:00.0 Ethernet controller: 3Com Corporation 3c940 > 10/100/1000Base-T [Marvell] (rev 10) > > The Athlon is using a SIS900 with the sis900 driver. > :00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] > SiS900 PCI Fast Ethernet (rev 91) > > I get the following when the system is booting: > > Setting up network interfaces: >lo >loIP address: 127.0.0.1/8 > doneWaiting for mandatory devices: eth-id-00:01:6c:ad:2b:c9 > 19 18 17 startproc: execve (/opt/kde3/bin/kdm) [ > /opt/kde3/bin/kdm ], [ LC_MONETARY= CONSOLE=/dev/console > ROOTFS_FSTYPE=reiserfs SHELL=/bin/sh TERM=linux ROOTFS_FSCK=0 > LC_NUMERIC= QTDIR=/usr/lib/qt3 LC_ALL= INIT_VERSION=sysvinit-2.85 > INIT=/sbin/init KDEROOTHOME=/root/.kdm REDIRECT=/dev/tty1 COLUMNS=128 > PATH=/sbin:/usr/sbin:/bin:/usr/bin:/lib/klibc/bin LC_MESSAGES= vga=0x317 > RUNLEVEL=5 LC_COLLATE= SPLASHCFG= PWD=/ LANG=en_US.UTF-8 > ROOTFS_REALDEV=/lib/klibc//dev/hda2 PREVLEVEL=N LINES=48 SHLVL=2 HOME=/ > XCURSOR_THEME=crystalwhite WINDOWMANAGER=/usr/X11R6/bin/kde > LC_CTYPE=en_US.UTF-8 SPLASH=no splash=silent LC_TIME= > ROOTFS_BLKDEV=/dev/hda2 _=/sbin/startproc DAEMON=/opt/kde3/bin/kdm ] > checkproc: /opt/kde3/bin/kdm 4094 > 16 15 14 13 12 11 10 9 8 7 6 5 4 3 1 0 >eth-id-00:01:6c:ad:2b:c9No interface found > failedSetting up service network . . . . . . . . . . . . . > . . .failed > > > I am attaching my config for the SMP system. Any ideas? Pointers? > > Thanks, > -- 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: Problem with 2.6.20 based kernels on SUSE 9.3
Sorry it has taken me so long to get back to this. I did finally make some time to dig into this more. roland wrote: Waiting for mandatory devices: eth-id-00:01:6c:ad:2b:c9 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 1 0 eth-id-00:01:6c:ad:2b:c9No interface found failedSetting up service network . . . . . . . I had such issues when using suse 9.3 inside vmware very often - typically removing network configuration completely in yast and re-adding it fixed it for me - but sometimes it re-appeared, though - and i never knew, why. Due to lack of time, i never dug into the device detection routines in depth, but i assume there must be some issue in older suse with that routines around Waiting for mandatory devices . It seems, that this has gone better in more recent distros, but i see that problem from time to time. You may also try setting MODULE_LOADED_ON_BOOT in /etc/sysconfig/kernel , please report if this helps It does resolve the issue to add the modules to MODULES_LOADED_ON_BOOT. It also works to add hal and dbus to the dependencies of /etc/init.d/network like they are in SUSE 10.1. Thanks again. ## Path:System/Kernel ## Description: Modules to load after initial boot ## Type:string ## ServiceRestart: boot.loadmodules # # This variable contains the list of modules to be loaded # once the main filesystem is active # MODULES_LOADED_ON_BOOT= Just came across this one - maybe it`s worth taking a look: http://en.opensuse.org/SDB:Waiting_for_Mandatory_Device regards roland List: linux-kernel Subject:Problem with 2.6.20 based kernels on SUSE 9.3 From: K.R. Foley kr () cybsft ! com Date: 2007-02-12 15:51:51 Message-ID: 45D08D17.8050808 () cybsft ! com [Download message RAW] I am having a problem with 2.6.20 based kernels on SUSE 9.3. It boots fine except that the network card is not detected at boot time. After the system boots I can modprobe nic module and the network comes up fine. I am having this same problem on two different Suse 9.3 systems, one is a a dual Xeon the other is an AMD Athlon. I have no such problems on Suse 10.1 systems on similar hardware. Kernels prior to 2.6.20-rc? work fine on these systems. The dual Xeon is using a 3Com card with the sk98lin driver. :06:00.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 10) The Athlon is using a SIS900 with the sis900 driver. :00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 91) I get the following when the system is booting: Setting up network interfaces: lo loIP address: 127.0.0.1/8 doneWaiting for mandatory devices: eth-id-00:01:6c:ad:2b:c9 19 18 17 noticestartproc: execve (/opt/kde3/bin/kdm) [ /opt/kde3/bin/kdm ], [ LC_MONETARY= CONSOLE=/dev/console ROOTFS_FSTYPE=reiserfs SHELL=/bin/sh TERM=linux ROOTFS_FSCK=0 LC_NUMERIC= QTDIR=/usr/lib/qt3 LC_ALL= INIT_VERSION=sysvinit-2.85 INIT=/sbin/init KDEROOTHOME=/root/.kdm REDIRECT=/dev/tty1 COLUMNS=128 PATH=/sbin:/usr/sbin:/bin:/usr/bin:/lib/klibc/bin LC_MESSAGES= vga=0x317 RUNLEVEL=5 LC_COLLATE= SPLASHCFG= PWD=/ LANG=en_US.UTF-8 ROOTFS_REALDEV=/lib/klibc//dev/hda2 PREVLEVEL=N LINES=48 SHLVL=2 HOME=/ XCURSOR_THEME=crystalwhite WINDOWMANAGER=/usr/X11R6/bin/kde LC_CTYPE=en_US.UTF-8 SPLASH=no splash=silent LC_TIME= ROOTFS_BLKDEV=/dev/hda2 _=/sbin/startproc DAEMON=/opt/kde3/bin/kdm ] noticecheckproc: /opt/kde3/bin/kdm 4094 16 15 14 13 12 11 10 9 8 7 6 5 4 3 1 0 eth-id-00:01:6c:ad:2b:c9No interface found failedSetting up service network . . . . . . . . . . . . . . . .failed I am attaching my config for the SMP system. Any ideas? Pointers? Thanks, -- 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: v2.6.21-rt3
Ingo Molnar wrote:
> i'm pleased to announce the v2.6.21-rt3 kernel, which can be downloaded
> from the usual place:
>
This is actually regarding v2.6.21-rt5 but I don't remember seeing an
announcement for that one. The attached patch is necessary if you happen
to have RTC_HISTOGRAM enabled, which I'm guessing most folks don't.
BTW, what was the consensus on pagefault_enable and pagefault_disable?
--
kr
--- linux-2.6.21/drivers/char/rtc.c.orig 2007-05-21 08:32:42.0 -0500
+++ linux-2.6.21/drivers/char/rtc.c 2007-05-21 08:33:49.0 -0500
@@ -93,6 +93,10 @@
#include
#endif
+static unsigned long rtc_port;
+static int rtc_irq = PCI_IRQ_NONE;
+#endif
+
#ifdef CONFIG_MIPS
# include
#endif
@@ -119,10 +123,6 @@ enum rtc_states {
#endif
-static unsigned long rtc_port;
-static int rtc_irq = PCI_IRQ_NONE;
-#endif
-
#ifdef CONFIG_HPET_RTC_IRQ
#undef RTC_IRQ
#endif
Re: v2.6.21-rt3
Ingo Molnar wrote:
i'm pleased to announce the v2.6.21-rt3 kernel, which can be downloaded
from the usual place:
This is actually regarding v2.6.21-rt5 but I don't remember seeing an
announcement for that one. The attached patch is necessary if you happen
to have RTC_HISTOGRAM enabled, which I'm guessing most folks don't.
BTW, what was the consensus on pagefault_enable and pagefault_disable?
--
kr
--- linux-2.6.21/drivers/char/rtc.c.orig 2007-05-21 08:32:42.0 -0500
+++ linux-2.6.21/drivers/char/rtc.c 2007-05-21 08:33:49.0 -0500
@@ -93,6 +93,10 @@
#include asm/isa.h
#endif
+static unsigned long rtc_port;
+static int rtc_irq = PCI_IRQ_NONE;
+#endif
+
#ifdef CONFIG_MIPS
# include asm/time.h
#endif
@@ -119,10 +123,6 @@ enum rtc_states {
#endif
-static unsigned long rtc_port;
-static int rtc_irq = PCI_IRQ_NONE;
-#endif
-
#ifdef CONFIG_HPET_RTC_IRQ
#undef RTC_IRQ
#endif
Re: v2.6.20-rt1, yum/rpm
Ingo Molnar wrote: > * K.R. Foley <[EMAIL PROTECTED]> wrote: > >> Ingo Molnar wrote: >>> i have released the v2.6.20-rt1 kernel, which can be downloaded from the >>> usual place: >>> >> I have a couple of questions regarding priorities of the softirqs, IRQ >> handlers, etc. >> >> With some exceptions, back in 2.6.18 and prior patches the IRQ threads >> were prioritized between 50 and 25 and the most of the softirqs were >> prioritized at 1? In newer patches it looks like they are all >> prioritized at 50? >> >> I was just curious what went into making these choices? I am just >> trying to better understand these decisions. > > The basically random order-of-request_irq() prioritization was causing > problems (it worked for some but didnt work for others), so i got rid of > trying to auto-guess some priority order. Also, now that we've got > tools/scripts like set_kthread_prio and rtprio it seemed more consistent > to just not attempt to prioritize interrupts and softirqs at all, but to > keep them all 'in the middle' of the RT priority range. > > Ingo > Thanks. -- 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: v2.6.20-rt1, yum/rpm
Ingo Molnar wrote: * K.R. Foley [EMAIL PROTECTED] wrote: Ingo Molnar wrote: i have released the v2.6.20-rt1 kernel, which can be downloaded from the usual place: I have a couple of questions regarding priorities of the softirqs, IRQ handlers, etc. With some exceptions, back in 2.6.18 and prior patches the IRQ threads were prioritized between 50 and 25 and the most of the softirqs were prioritized at 1? In newer patches it looks like they are all prioritized at 50? I was just curious what went into making these choices? I am just trying to better understand these decisions. The basically random order-of-request_irq() prioritization was causing problems (it worked for some but didnt work for others), so i got rid of trying to auto-guess some priority order. Also, now that we've got tools/scripts like set_kthread_prio and rtprio it seemed more consistent to just not attempt to prioritize interrupts and softirqs at all, but to keep them all 'in the middle' of the RT priority range. Ingo Thanks. -- 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: v2.6.20-rt1, yum/rpm
Ingo Molnar wrote: > i have released the v2.6.20-rt1 kernel, which can be downloaded from the > usual place: > I have a couple of questions regarding priorities of the softirqs, IRQ handlers, etc. With some exceptions, back in 2.6.18 and prior patches the IRQ threads were prioritized between 50 and 25 and the most of the softirqs were prioritized at 1? In newer patches it looks like they are all prioritized at 50? I was just curious what went into making these choices? I am just trying to better understand these decisions. Thanks, -- 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: v2.6.20-rt1, yum/rpm
Ingo Molnar wrote: i have released the v2.6.20-rt1 kernel, which can be downloaded from the usual place: I have a couple of questions regarding priorities of the softirqs, IRQ handlers, etc. With some exceptions, back in 2.6.18 and prior patches the IRQ threads were prioritized between 50 and 25 and the most of the softirqs were prioritized at 1? In newer patches it looks like they are all prioritized at 50? I was just curious what went into making these choices? I am just trying to better understand these decisions. Thanks, -- 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: 2.6.19-rt14 slowdown compared to 2.6.19
Chen, Tim C wrote:
> Ingo,
>
> We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19
> kernel and noticed several slowdowns. The test machine is a 2 socket
> woodcrest machine with your default configuration.
>
> Netperf TCP Streaming was slower by 40% ( 1 server and 1 client
> each bound to separate cpu cores on different socket, network
> loopback mode was used).
>
> Volanomark was slower by 80% (Server and Clients communicate with
> network loopback mode. Idle time goes from 1% to 60%)
>
> Re-Aim7 was slower by 40% (idle time goes from 0% to 20%)
>
> Wonder if you have any suggestions on what could cause the slowdown.
> We've tried disabling CONFIG_NO_HZ and it didn't help much.
>
> Thanks.
>
> Tim
Take a look at this. Not sure if this is the same problem but it looks
like a candidate. I can definitely say that some latencies I have seen
in my recent testing have gone away in the last few versions
2.6.20-rc1-rt{3,4}.
--
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: 2.6.19-rt14 slowdown compared to 2.6.19
Chen, Tim C wrote:
> Ingo,
>
> We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19
> kernel and noticed several slowdowns. The test machine is a 2 socket
> woodcrest machine with your default configuration.
>
> Netperf TCP Streaming was slower by 40% ( 1 server and 1 client
> each bound to separate cpu cores on different socket, network
> loopback mode was used).
>
> Volanomark was slower by 80% (Server and Clients communicate with
> network loopback mode. Idle time goes from 1% to 60%)
>
> Re-Aim7 was slower by 40% (idle time goes from 0% to 20%)
>
> Wonder if you have any suggestions on what could cause the slowdown.
> We've tried disabling CONFIG_NO_HZ and it didn't help much.
>
> Thanks.
>
> Tim
Take a look at this. Not sure if this is the same problem but it looks
like a candidate. I can definitely say that some latencies I have seen
in my recent testing have gone away in the last few versions
2.6.20-rc1-rt{3,4}.
Sorry I missed the URL first time around.
http://marc.theaimsgroup.com/?l=linux-kernel=116670388527349=2
--
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: 2.6.19-rt14 slowdown compared to 2.6.19
Chen, Tim C wrote:
Ingo,
We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19
kernel and noticed several slowdowns. The test machine is a 2 socket
woodcrest machine with your default configuration.
Netperf TCP Streaming was slower by 40% ( 1 server and 1 client
each bound to separate cpu cores on different socket, network
loopback mode was used).
Volanomark was slower by 80% (Server and Clients communicate with
network loopback mode. Idle time goes from 1% to 60%)
Re-Aim7 was slower by 40% (idle time goes from 0% to 20%)
Wonder if you have any suggestions on what could cause the slowdown.
We've tried disabling CONFIG_NO_HZ and it didn't help much.
Thanks.
Tim
Take a look at this. Not sure if this is the same problem but it looks
like a candidate. I can definitely say that some latencies I have seen
in my recent testing have gone away in the last few versions
2.6.20-rc1-rt{3,4}.
Sorry I missed the URL first time around.
http://marc.theaimsgroup.com/?l=linux-kernelm=116670388527349w=2
--
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: 2.6.19-rt14 slowdown compared to 2.6.19
Chen, Tim C wrote:
Ingo,
We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19
kernel and noticed several slowdowns. The test machine is a 2 socket
woodcrest machine with your default configuration.
Netperf TCP Streaming was slower by 40% ( 1 server and 1 client
each bound to separate cpu cores on different socket, network
loopback mode was used).
Volanomark was slower by 80% (Server and Clients communicate with
network loopback mode. Idle time goes from 1% to 60%)
Re-Aim7 was slower by 40% (idle time goes from 0% to 20%)
Wonder if you have any suggestions on what could cause the slowdown.
We've tried disabling CONFIG_NO_HZ and it didn't help much.
Thanks.
Tim
Take a look at this. Not sure if this is the same problem but it looks
like a candidate. I can definitely say that some latencies I have seen
in my recent testing have gone away in the last few versions
2.6.20-rc1-rt{3,4}.
--
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: [BUG] 2.6.19-rt14 does not compile with CONFIG_NO_HZ
Remy Bohmer wrote: > Hello, > > For your Information, I get the following compile error when > CONFIG_NO_HZ is NOT configured on 2.6.19.1-rt14: > > -- > CC kernel/sched.o > kernel/sched.c: In function '__schedule': > kernel/sched.c:4135: error: 'notick' undeclared (first use in this > function) > kernel/sched.c:4135: error: (Each undeclared identifier is reported only > once > kernel/sched.c:4135: error: for each function it appears in.) > make[1]: *** [kernel/sched.o] Error 1 > -- > > For me it is not a real problem as I configured the kernel now as a > tickless system. > Attached 2 config files, 1 showing the error, and 1 that is working. > > Kind Regards, > > Remy Bohmer See Steven's patch to fix this here: > http://marc.theaimsgroup.com/?l=linux-kernel=116611237701140=2 -- 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: [BUG] 2.6.19-rt14 does not compile with CONFIG_NO_HZ
Remy Bohmer wrote: Hello, For your Information, I get the following compile error when CONFIG_NO_HZ is NOT configured on 2.6.19.1-rt14: -- CC kernel/sched.o kernel/sched.c: In function '__schedule': kernel/sched.c:4135: error: 'notick' undeclared (first use in this function) kernel/sched.c:4135: error: (Each undeclared identifier is reported only once kernel/sched.c:4135: error: for each function it appears in.) make[1]: *** [kernel/sched.o] Error 1 -- For me it is not a real problem as I configured the kernel now as a tickless system. Attached 2 config files, 1 showing the error, and 1 that is working. Kind Regards, Remy Bohmer See Steven's patch to fix this here: http://marc.theaimsgroup.com/?l=linux-kernelm=116611237701140w=2 -- 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: v2.6.19-rt6, yum/rpm
Ingo Molnar wrote: > * K.R. Foley <[EMAIL PROTECTED]> wrote: > >> Ingo Molnar wrote: >> >> The attached patch is necessary to build 2.6.19-rt8 without KEXEC >> enabled. Without KEXEC enabled crash.c doesn't get included. I believe >> this is correct. > > ah, indeed. I went for a slightly different approach - see the patch > below. Sending an NMI to all CPUs is not something that is tied to > KEXEC, it belongs into nmi.c. > > Ingo Much better I think. It still requires the patch below, which includes mach_ipi.h, to build here. -- kr --- linux-2.6.19/arch/i386/kernel/nmi.c.orig 2006-12-07 13:03:12.0 -0600 +++ linux-2.6.19/arch/i386/kernel/nmi.c 2006-12-07 13:03:21.0 -0600 @@ -30,6 +30,7 @@ #include #include "mach_traps.h" +#include int unknown_nmi_panic; int nmi_watchdog_enabled;
Re: v2.6.19-rt6, yum/rpm
Ingo Molnar wrote:
The attached patch is necessary to build 2.6.19-rt8 without KEXEC
enabled. Without KEXEC enabled crash.c doesn't get included. I believe
this is correct.
--
kr
--- linux-2.6.19/arch/i386/kernel/nmi.c.orig 2006-12-07 09:35:22.0 -0600
+++ linux-2.6.19/arch/i386/kernel/nmi.c 2006-12-07 09:36:04.0 -0600
@@ -935,7 +935,9 @@ void nmi_show_all_regs(void)
for_each_online_cpu(i)
nmi_show_regs[i] = 1;
+#ifdef CONFIG_KEXEC
smp_send_nmi_allbutself();
+#endif
for_each_online_cpu(i) {
while (nmi_show_regs[i] == 1)
Re: v2.6.19-rt6, yum/rpm
Ingo Molnar wrote: > i have released the 2.6.19-rt6 tree, which can be downloaded from the > usual place: > Attached patch fixes rtc histogram. Looks like it got broken around 2.6.18-rt?, probably during the merge for 2.6.18? -- kr --- linux-2.6.19/drivers/char/rtc.c.orig 2006-12-06 21:46:16.0 -0600 +++ linux-2.6.19/drivers/char/rtc.c 2006-12-06 21:46:48.0 -0600 @@ -427,9 +427,9 @@ irqreturn_t rtc_interrupt(int irq, void if (rtc_callback) rtc_callback->func(rtc_callback->private_data); spin_unlock(_task_lock); - wake_up_interruptible(_wait); - kill_fasync (_async_queue, SIGIO, POLL_IN); + rtc_wake_event(); + wake_up_interruptible(_wait); return IRQ_HANDLED; } @@ -1328,7 +1328,6 @@ static void rtc_dropped_irq(unsigned lon printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq); /* Now we have new data */ - rtc_wake_event(); wake_up_interruptible(_wait); kill_fasync (_async_queue, SIGIO, POLL_IN);
Re: v2.6.19-rt6, yum/rpm
Ingo Molnar wrote: i have released the 2.6.19-rt6 tree, which can be downloaded from the usual place: Attached patch fixes rtc histogram. Looks like it got broken around 2.6.18-rt?, probably during the merge for 2.6.18? -- kr --- linux-2.6.19/drivers/char/rtc.c.orig 2006-12-06 21:46:16.0 -0600 +++ linux-2.6.19/drivers/char/rtc.c 2006-12-06 21:46:48.0 -0600 @@ -427,9 +427,9 @@ irqreturn_t rtc_interrupt(int irq, void if (rtc_callback) rtc_callback-func(rtc_callback-private_data); spin_unlock(rtc_task_lock); - wake_up_interruptible(rtc_wait); - kill_fasync (rtc_async_queue, SIGIO, POLL_IN); + rtc_wake_event(); + wake_up_interruptible(rtc_wait); return IRQ_HANDLED; } @@ -1328,7 +1328,6 @@ static void rtc_dropped_irq(unsigned lon printk(KERN_WARNING rtc: lost some interrupts at %ldHz.\n, freq); /* Now we have new data */ - rtc_wake_event(); wake_up_interruptible(rtc_wait); kill_fasync (rtc_async_queue, SIGIO, POLL_IN);
Re: v2.6.19-rt6, yum/rpm
Ingo Molnar wrote:
The attached patch is necessary to build 2.6.19-rt8 without KEXEC
enabled. Without KEXEC enabled crash.c doesn't get included. I believe
this is correct.
--
kr
--- linux-2.6.19/arch/i386/kernel/nmi.c.orig 2006-12-07 09:35:22.0 -0600
+++ linux-2.6.19/arch/i386/kernel/nmi.c 2006-12-07 09:36:04.0 -0600
@@ -935,7 +935,9 @@ void nmi_show_all_regs(void)
for_each_online_cpu(i)
nmi_show_regs[i] = 1;
+#ifdef CONFIG_KEXEC
smp_send_nmi_allbutself();
+#endif
for_each_online_cpu(i) {
while (nmi_show_regs[i] == 1)
Re: 2.6.13-rc7-rt3 compile fix
Steven Rostedt wrote: > On Fri, 2005-08-26 at 16:17 -0500, K.R. Foley wrote: > >>2.6.13-rc7-rt3 won't compile without the simple patch below. >> > > - __raw_spin_lock(old_owner->task->pi_lock); > + __raw_spin_lock(_owner->task->pi_lock); > TRACE_WARN_ON_LOCKED(plist_empty(>pi_list)); > TRACE_WARN_ON_LOCKED(lock_owner(lock)); > > @@ -683,7 +683,7 @@ > } > TRACE_WARN_ON_LOCKED(1); > ok: > - __raw_spin_unlock(old_owner->task->pi_lock); > + __raw_spin_unlock(_owner->task->pi_lock); > return; > > > Oops! my bad. I saw that needed locking, but I didn't have the tracing > on (I was trying for internal deadlocks), so that part of the code > wasn't compiling. If you turn off tracing it would compile :-) Understood. ;-) > > Anyway, the next time I modify code that's protected by ifdefs, I'll > change my config and see at least the code compiles. > > Thanks, > > -- Steve > > > -- 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/
2.6.13-rc7-rt3 compile fix
2.6.13-rc7-rt3 won't compile without the simple patch below. -- kr --- linux-2.6.13/kernel/rt.c.orig 2005-08-26 15:51:35.0 -0500 +++ linux-2.6.13/kernel/rt.c 2005-08-26 15:51:55.0 -0500 @@ -672,7 +672,7 @@ struct rt_mutex_waiter *w; struct plist *curr1; - __raw_spin_lock(old_owner->task->pi_lock); + __raw_spin_lock(_owner->task->pi_lock); TRACE_WARN_ON_LOCKED(plist_empty(>pi_list)); TRACE_WARN_ON_LOCKED(lock_owner(lock)); @@ -683,7 +683,7 @@ } TRACE_WARN_ON_LOCKED(1); ok: - __raw_spin_unlock(old_owner->task->pi_lock); + __raw_spin_unlock(_owner->task->pi_lock); return; }
2.6.13-rc7-rt3 compile fix
2.6.13-rc7-rt3 won't compile without the simple patch below. -- kr --- linux-2.6.13/kernel/rt.c.orig 2005-08-26 15:51:35.0 -0500 +++ linux-2.6.13/kernel/rt.c 2005-08-26 15:51:55.0 -0500 @@ -672,7 +672,7 @@ struct rt_mutex_waiter *w; struct plist *curr1; - __raw_spin_lock(old_owner-task-pi_lock); + __raw_spin_lock(old_owner-task-pi_lock); TRACE_WARN_ON_LOCKED(plist_empty(waiter-pi_list)); TRACE_WARN_ON_LOCKED(lock_owner(lock)); @@ -683,7 +683,7 @@ } TRACE_WARN_ON_LOCKED(1); ok: - __raw_spin_unlock(old_owner-task-pi_lock); + __raw_spin_unlock(old_owner-task-pi_lock); return; }
Re: 2.6.13-rc7-rt3 compile fix
Steven Rostedt wrote: On Fri, 2005-08-26 at 16:17 -0500, K.R. Foley wrote: 2.6.13-rc7-rt3 won't compile without the simple patch below. - __raw_spin_lock(old_owner-task-pi_lock); + __raw_spin_lock(old_owner-task-pi_lock); TRACE_WARN_ON_LOCKED(plist_empty(waiter-pi_list)); TRACE_WARN_ON_LOCKED(lock_owner(lock)); @@ -683,7 +683,7 @@ } TRACE_WARN_ON_LOCKED(1); ok: - __raw_spin_unlock(old_owner-task-pi_lock); + __raw_spin_unlock(old_owner-task-pi_lock); return; Oops! my bad. I saw that needed locking, but I didn't have the tracing on (I was trying for internal deadlocks), so that part of the code wasn't compiling. If you turn off tracing it would compile :-) Understood. ;-) Anyway, the next time I modify code that's protected by ifdefs, I'll change my config and see at least the code compiles. Thanks, -- Steve -- 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/
2.6.13-rc6-rt15 won't compile without HR-Timers
Ingo,
Without the attached patch 2.6.13-rc6-rt15 won't compile for me with
CONFIG_HIGH_RES_TIMERS not configured.
--
kr
--- linux-2.6.13/include/linux/timer.h.orig 2005-08-24 11:15:22.0 -0500
+++ linux-2.6.13/include/linux/timer.h 2005-08-24 11:15:35.0 -0500
@@ -76,6 +76,7 @@
#ifdef CONFIG_HIGH_RES_TIMERS
extern void add_hres_timer_us(struct timer_list *timer, unsigned long usec);
+extern void init_hrtimers(void);
#else
#define add_hres_timer_us(t,exp) mod_timer(t,(exp*HZ)/100)
#endif
@@ -125,7 +126,6 @@
#define del_singleshot_timer_sync(t) del_timer_sync(t)
extern void init_timers(void);
-extern void init_hrtimers(void);
extern void run_local_timers(void);
extern void it_real_fn(unsigned long);
--- linux-2.6.13/kernel/timer.c.orig 2005-08-24 11:16:04.0 -0500
+++ linux-2.6.13/kernel/timer.c 2005-08-24 11:06:32.0 -0500
@@ -1920,9 +1920,9 @@
.notifier_call = timer_cpu_notify,
};
+#ifdef CONFIG_HIGH_RES_TIMERS
void __init init_hrtimers(void)
{
-#ifdef CONFIG_HIGH_RES_TIMERS
open_softirq(HRTIMER_SOFTIRQ,
(void (*)(struct softirq_action*))hrtimers_expire_timers,
NULL);
@@ -1931,8 +1931,8 @@
printk("arch_cycles_per_jiffy: %ld\n", arch_cycles_per_jiffy);
printk("hr_max_jiffies_expiry: %d\n", hr_max_jiffies_expiry);
printk("hr_max_expiry: %d\n", hr_max_expiry);
-#endif
}
+#endif
void __init init_timers(void)
{
2.6.13-rc6-rt15 won't compile without HR-Timers
Ingo,
Without the attached patch 2.6.13-rc6-rt15 won't compile for me with
CONFIG_HIGH_RES_TIMERS not configured.
--
kr
--- linux-2.6.13/include/linux/timer.h.orig 2005-08-24 11:15:22.0 -0500
+++ linux-2.6.13/include/linux/timer.h 2005-08-24 11:15:35.0 -0500
@@ -76,6 +76,7 @@
#ifdef CONFIG_HIGH_RES_TIMERS
extern void add_hres_timer_us(struct timer_list *timer, unsigned long usec);
+extern void init_hrtimers(void);
#else
#define add_hres_timer_us(t,exp) mod_timer(t,(exp*HZ)/100)
#endif
@@ -125,7 +126,6 @@
#define del_singleshot_timer_sync(t) del_timer_sync(t)
extern void init_timers(void);
-extern void init_hrtimers(void);
extern void run_local_timers(void);
extern void it_real_fn(unsigned long);
--- linux-2.6.13/kernel/timer.c.orig 2005-08-24 11:16:04.0 -0500
+++ linux-2.6.13/kernel/timer.c 2005-08-24 11:06:32.0 -0500
@@ -1920,9 +1920,9 @@
.notifier_call = timer_cpu_notify,
};
+#ifdef CONFIG_HIGH_RES_TIMERS
void __init init_hrtimers(void)
{
-#ifdef CONFIG_HIGH_RES_TIMERS
open_softirq(HRTIMER_SOFTIRQ,
(void (*)(struct softirq_action*))hrtimers_expire_timers,
NULL);
@@ -1931,8 +1931,8 @@
printk(arch_cycles_per_jiffy: %ld\n, arch_cycles_per_jiffy);
printk(hr_max_jiffies_expiry: %d\n, hr_max_jiffies_expiry);
printk(hr_max_expiry: %d\n, hr_max_expiry);
-#endif
}
+#endif
void __init init_timers(void)
{
Re: 2.6.13-rc6-rt6
Ingo Molnar wrote:
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
On Wed, 2005-08-17 at 10:24 -0400, Steven Rostedt wrote:
OK the output from netconsole still seems like netconsole itself is
causing some problems. But I think it is also showing this lockup. I'll
recompile my kernel as UP and see if netconsole works fine.
Well, the UP kernel boots on my laptop, but netconsole gives strange
warnings.
OK, what's the scoop with the illegal_API_call? What is it about, and
what is the expected work around?
this is a recent change: i've started flagging "naked" use of
local_irq_disable(), because it's a problem on PREEMPT_RT and it's a
potential SMP bug on upstream kernels. A local_irq_disable() is
converted either to raw_local_irq_disable() when justified (it's mostly
only justified for lowlevel arch code), or is eliminated totally.
(either by merging it into a nearby spin_lock API call, or by removing
it altogether, making sure that code doesnt break).
Right now we print a warning on the first such API use, and then shut up
about it. All local_irq_() APIs map to NOPs. (we keep the PF_IRQSOFF
flag for compatibility, but only to get irqs_off() right which in turn
shuts off a number of BUG_ON(!irqs_disabled()) warnings, and it doesnt
have any other functional purpose.)
the desired end-result would be the total elimination of local_irq_*()
API calls.
I'm also getting the following output on shutdown:
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.7
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM ver 1.5
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
BUG: nonzero lock count 1 at exit time?
nfsd: 4696 [f7183830, 115]
[] check_no_held_locks+0x62/0x330 (8)
[] do_exit+0x257/0x480 (32)
[] __module_put_and_exit+0x52/0x70 (40)
[] nfsd+0x2b3/0x340 [nfsd] (12)
[] nfsd+0x0/0x340 [nfsd] (48)
[] kernel_thread_helper+0x5/0x18 (16)
---
| preempt count: ]
| 0-level deep critical section nesting:
--
| showing all locks held by: | (nfsd/4696 [f7183830, 116]):
--
#001: [c038e184] {kernel_sem.lock}
... acquired at: lock_kernel+0x21/0x40
BUG: nfsd/4696, BKL held at task exit time!
hm, it seems nfsd forgets to do an unlock_kernel() in some exit path it
seems? We are enforcing strict balanced lock use in PREEMPT_RT - the
upstream kernel is more relaxed about it.
This one has been biting me in the shorts since going to the 2.6.13-rc?
RT series on my older SMP system at home. In every case the system hangs
on shutdown and requires a hard reset. I just hadn't had the time to
check into it. I was just in the process of building 2.6.13-rc6 without
RT to check if it still happened. Guess I won't bother now. :-)
Aug 16 11:11:09 porky kernel: BUG: nonzero lock count 1 at exit time?
Aug 16 11:11:09 porky kernel: nfsd: 4476 [dd1691a0, 115]
Aug 16 11:11:09 porky kernel: [] dump_stack+0x1e/0x20 (20)
Aug 16 11:11:09 porky kernel: []
check_no_held_locks+0x1af/0x370 (36)
Aug 16 11:11:09 porky kernel: [] do_exit+0x26f/0x480 (44)
Aug 16 11:11:09 porky kernel: []
__module_put_and_exit+0x51/0x70 (16)
Aug 16 11:11:09 porky kernel: [] nfsd+0x2bd/0x340 [nfsd] (68)
Aug 16 11:11:09 porky kernel: []
kernel_thread_helper+0x5/0x10 (65485
2124)
Aug 16 11:11:09 porky kernel: ---
Aug 16 11:11:09 porky kernel: | preempt count: ]
Aug 16 11:11:09 porky kernel: | 0-level deep critical section nesting:
Aug 16 11:11:09 porky kernel:
Aug 16 11:11:09 porky kernel:
Aug 16 11:11:09 porky kernel: --
Aug 16 11:11:09 porky kernel: | showing all locks held by: | (nfsd/4476
[dd1691
a0, 116]):
Aug 16 11:11:09 porky kernel: --
Aug 16 11:11:09 porky kernel:
Aug 16 11:11:09 porky kernel: #001: [c0390fe4] {kernel_sem.lock}
Aug 16 11:11:09 porky kernel: ... acquired at:
lock_kernel+0x28/0x50
Aug 16 11:11:09 porky kernel:
Aug 16 11:11:09 porky kernel: BUG: nfsd/4476, BKL held at task exit time!
Aug 16 11:11:09 porky kernel: BKL acquired at: nfsd+0x273/0x340 [nfsd]
Aug 16 11:11:09 porky kernel: [c0390fe4] {kernel_sem.lock}
Aug 16 11:11:09 porky kernel: .. held by: nfsd: 4476
[dd1691a0, 116]
Aug 16 11:11:09 porky kernel: ... acquired at:
lock_kernel+0x28/0x50
Aug 16 11:46:44 porky syslogd 1.4.1: restart.
And it goes on and on. This happens everytime. Without netconsole, I
only get the nonzero lock count error. Also, one of my lockups on SMP
had to do with the kernel_thread_helper:
Using IPI Shortcut mode
khelper/794[CPU#0]: BUG in set_new_owner at kernel/rt.c:916
this is a 'must not happen'. Somehow lock->held list got
Re: 2.6.13-rc6-rt6
Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
On Wed, 2005-08-17 at 10:24 -0400, Steven Rostedt wrote:
OK the output from netconsole still seems like netconsole itself is
causing some problems. But I think it is also showing this lockup. I'll
recompile my kernel as UP and see if netconsole works fine.
Well, the UP kernel boots on my laptop, but netconsole gives strange
warnings.
OK, what's the scoop with the illegal_API_call? What is it about, and
what is the expected work around?
this is a recent change: i've started flagging naked use of
local_irq_disable(), because it's a problem on PREEMPT_RT and it's a
potential SMP bug on upstream kernels. A local_irq_disable() is
converted either to raw_local_irq_disable() when justified (it's mostly
only justified for lowlevel arch code), or is eliminated totally.
(either by merging it into a nearby spin_lock API call, or by removing
it altogether, making sure that code doesnt break).
Right now we print a warning on the first such API use, and then shut up
about it. All local_irq_() APIs map to NOPs. (we keep the PF_IRQSOFF
flag for compatibility, but only to get irqs_off() right which in turn
shuts off a number of BUG_ON(!irqs_disabled()) warnings, and it doesnt
have any other functional purpose.)
the desired end-result would be the total elimination of local_irq_*()
API calls.
I'm also getting the following output on shutdown:
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.7
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM ver 1.5
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
BUG: nonzero lock count 1 at exit time?
nfsd: 4696 [f7183830, 115]
[c0136922] check_no_held_locks+0x62/0x330 (8)
[c011df67] do_exit+0x257/0x480 (32)
[c013d052] __module_put_and_exit+0x52/0x70 (40)
[f8d54583] nfsd+0x2b3/0x340 [nfsd] (12)
[f8d542d0] nfsd+0x0/0x340 [nfsd] (48)
[c010140d] kernel_thread_helper+0x5/0x18 (16)
---
| preempt count: ]
| 0-level deep critical section nesting:
--
| showing all locks held by: | (nfsd/4696 [f7183830, 116]):
--
#001: [c038e184] {kernel_sem.lock}
... acquired at: lock_kernel+0x21/0x40
BUG: nfsd/4696, BKL held at task exit time!
hm, it seems nfsd forgets to do an unlock_kernel() in some exit path it
seems? We are enforcing strict balanced lock use in PREEMPT_RT - the
upstream kernel is more relaxed about it.
This one has been biting me in the shorts since going to the 2.6.13-rc?
RT series on my older SMP system at home. In every case the system hangs
on shutdown and requires a hard reset. I just hadn't had the time to
check into it. I was just in the process of building 2.6.13-rc6 without
RT to check if it still happened. Guess I won't bother now. :-)
Aug 16 11:11:09 porky kernel: BUG: nonzero lock count 1 at exit time?
Aug 16 11:11:09 porky kernel: nfsd: 4476 [dd1691a0, 115]
Aug 16 11:11:09 porky kernel: [c010418e] dump_stack+0x1e/0x20 (20)
Aug 16 11:11:09 porky kernel: [c013b7ff]
check_no_held_locks+0x1af/0x370 (36)
Aug 16 11:11:09 porky kernel: [c0122e3f] do_exit+0x26f/0x480 (44)
Aug 16 11:11:09 porky kernel: [c01413c1]
__module_put_and_exit+0x51/0x70 (16)
Aug 16 11:11:09 porky kernel: [e5a8558d] nfsd+0x2bd/0x340 [nfsd] (68)
Aug 16 11:11:09 porky kernel: [c0101315]
kernel_thread_helper+0x5/0x10 (65485
2124)
Aug 16 11:11:09 porky kernel: ---
Aug 16 11:11:09 porky kernel: | preempt count: ]
Aug 16 11:11:09 porky kernel: | 0-level deep critical section nesting:
Aug 16 11:11:09 porky kernel:
Aug 16 11:11:09 porky kernel:
Aug 16 11:11:09 porky kernel: --
Aug 16 11:11:09 porky kernel: | showing all locks held by: | (nfsd/4476
[dd1691
a0, 116]):
Aug 16 11:11:09 porky kernel: --
Aug 16 11:11:09 porky kernel:
Aug 16 11:11:09 porky kernel: #001: [c0390fe4] {kernel_sem.lock}
Aug 16 11:11:09 porky kernel: ... acquired at:
lock_kernel+0x28/0x50
Aug 16 11:11:09 porky kernel:
Aug 16 11:11:09 porky kernel: BUG: nfsd/4476, BKL held at task exit time!
Aug 16 11:11:09 porky kernel: BKL acquired at: nfsd+0x273/0x340 [nfsd]
Aug 16 11:11:09 porky kernel: [c0390fe4] {kernel_sem.lock}
Aug 16 11:11:09 porky kernel: .. held by: nfsd: 4476
[dd1691a0, 116]
Aug 16 11:11:09 porky kernel: ... acquired at:
lock_kernel+0x28/0x50
Aug 16 11:46:44 porky syslogd 1.4.1: restart.
And it goes on and on. This happens everytime. Without netconsole, I
only get the nonzero lock count error. Also, one of my lockups on SMP
had to do with the kernel_thread_helper:
Using IPI Shortcut mode
khelper/794[CPU#0]: BUG in
Re: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
Esben Nielsen wrote: On Wed, 27 Jul 2005, K.R. Foley wrote: Esben Nielsen wrote: On Wed, 27 Jul 2005, Ingo Molnar wrote: * Steven Rostedt <[EMAIL PROTECTED]> wrote: Perfectly understood. I've had two customers ask me to increase the priorities for them, but those where custom kernels, and a config option wasn't necessary. But since I've had customers asking, I thought that this might be something that others want. But I deal with a niche market, and what my customers want might not be what everyone wants. (hence the RFC in the subject). So if there are others out there that would prefer to change their priority ranges, speak now otherwise this patch will go by the waste side. i'm not excluding that this will become necessary in the future. We should also add the safety check to sched.h - all i'm suggesting is to not make it a .config option just now, because that tends to be fiddled with. Isn't there a way to mark it "warning! warning! dangerous!" ? Anyway: I think 100 RT priorities is way overkill - and slowing things down by making the scheduler checking more empty slots in the runqueue. Default ought to be 10. In practise it will be very hard to have a task at the lower RT priority behaving real-time with 99 higher priority tasks around. I find it hard to believe that somebody has an RT app needing more than 10 priorities and can't do with RR or FIFO scheduling within a fewer number of prorities. Esben Actually, is it really that slow to search a bitmap for a slot that needs processing? No, it is ultra fast - but done very often. :-) I'm not going to argue this. You could definitely save a few instructions if you had fewer priorities and it probably wouldn't be very hard to create a patch to do this. I work on real-time test stands which are less of an embedded system and more of a real Unix system that require determinism. It is very nice in some cases to have more than 10 RT priorities to work with. What for? Why can't you use FIFO at the same priorities for some of your tasks? I pretty much quess you have a very few tasks which have some high requirements. The rest of you "RT" task could easily share the lowest RT priority. FIFO would also be more effective as you will have context switches. This about multiple priorities probably comes from an ordering of tasks: You have a lot of task. You have a feeling about which one ought to be more important than the other. Thus you end of with an ordered list of tasks. BUT when you boil it down to what RT is all about, namely meeting your deadlines, it doesn't matter after the 5-10 priorities because the 5-10 priorities have introduced a lot of jitter to the rest of the tasks anyway. You can just as well just put them at the same priority. Esben All of the RT priorities that we have are not absolutely necessary. As I think Steven pointed out in another email, it is nice though to be able to priortize tasks using large jumps in priorities and then being able to fill in tasks that are dependent on other tasks in between. Even if you think of nothing but the IRQ handlers, the 5-10 priorities quickly get crowded without any user tasks. -- 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: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
Esben Nielsen wrote: On Wed, 27 Jul 2005, Ingo Molnar wrote: * Steven Rostedt <[EMAIL PROTECTED]> wrote: Perfectly understood. I've had two customers ask me to increase the priorities for them, but those where custom kernels, and a config option wasn't necessary. But since I've had customers asking, I thought that this might be something that others want. But I deal with a niche market, and what my customers want might not be what everyone wants. (hence the RFC in the subject). So if there are others out there that would prefer to change their priority ranges, speak now otherwise this patch will go by the waste side. i'm not excluding that this will become necessary in the future. We should also add the safety check to sched.h - all i'm suggesting is to not make it a .config option just now, because that tends to be fiddled with. Isn't there a way to mark it "warning! warning! dangerous!" ? Anyway: I think 100 RT priorities is way overkill - and slowing things down by making the scheduler checking more empty slots in the runqueue. Default ought to be 10. In practise it will be very hard to have a task at the lower RT priority behaving real-time with 99 higher priority tasks around. I find it hard to believe that somebody has an RT app needing more than 10 priorities and can't do with RR or FIFO scheduling within a fewer number of prorities. Esben Actually, is it really that slow to search a bitmap for a slot that needs processing? I work on real-time test stands which are less of an embedded system and more of a real Unix system that require determinism. It is very nice in some cases to have more than 10 RT priorities to work with. -- 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: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
Esben Nielsen wrote: On Wed, 27 Jul 2005, Ingo Molnar wrote: * Steven Rostedt [EMAIL PROTECTED] wrote: Perfectly understood. I've had two customers ask me to increase the priorities for them, but those where custom kernels, and a config option wasn't necessary. But since I've had customers asking, I thought that this might be something that others want. But I deal with a niche market, and what my customers want might not be what everyone wants. (hence the RFC in the subject). So if there are others out there that would prefer to change their priority ranges, speak now otherwise this patch will go by the waste side. i'm not excluding that this will become necessary in the future. We should also add the safety check to sched.h - all i'm suggesting is to not make it a .config option just now, because that tends to be fiddled with. Isn't there a way to mark it warning! warning! dangerous! ? Anyway: I think 100 RT priorities is way overkill - and slowing things down by making the scheduler checking more empty slots in the runqueue. Default ought to be 10. In practise it will be very hard to have a task at the lower RT priority behaving real-time with 99 higher priority tasks around. I find it hard to believe that somebody has an RT app needing more than 10 priorities and can't do with RR or FIFO scheduling within a fewer number of prorities. Esben Actually, is it really that slow to search a bitmap for a slot that needs processing? I work on real-time test stands which are less of an embedded system and more of a real Unix system that require determinism. It is very nice in some cases to have more than 10 RT priorities to work with. -- 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: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
Esben Nielsen wrote: On Wed, 27 Jul 2005, K.R. Foley wrote: Esben Nielsen wrote: On Wed, 27 Jul 2005, Ingo Molnar wrote: * Steven Rostedt [EMAIL PROTECTED] wrote: Perfectly understood. I've had two customers ask me to increase the priorities for them, but those where custom kernels, and a config option wasn't necessary. But since I've had customers asking, I thought that this might be something that others want. But I deal with a niche market, and what my customers want might not be what everyone wants. (hence the RFC in the subject). So if there are others out there that would prefer to change their priority ranges, speak now otherwise this patch will go by the waste side. i'm not excluding that this will become necessary in the future. We should also add the safety check to sched.h - all i'm suggesting is to not make it a .config option just now, because that tends to be fiddled with. Isn't there a way to mark it warning! warning! dangerous! ? Anyway: I think 100 RT priorities is way overkill - and slowing things down by making the scheduler checking more empty slots in the runqueue. Default ought to be 10. In practise it will be very hard to have a task at the lower RT priority behaving real-time with 99 higher priority tasks around. I find it hard to believe that somebody has an RT app needing more than 10 priorities and can't do with RR or FIFO scheduling within a fewer number of prorities. Esben Actually, is it really that slow to search a bitmap for a slot that needs processing? No, it is ultra fast - but done very often. :-) I'm not going to argue this. You could definitely save a few instructions if you had fewer priorities and it probably wouldn't be very hard to create a patch to do this. I work on real-time test stands which are less of an embedded system and more of a real Unix system that require determinism. It is very nice in some cases to have more than 10 RT priorities to work with. What for? Why can't you use FIFO at the same priorities for some of your tasks? I pretty much quess you have a very few tasks which have some high requirements. The rest of you RT task could easily share the lowest RT priority. FIFO would also be more effective as you will have context switches. This about multiple priorities probably comes from an ordering of tasks: You have a lot of task. You have a feeling about which one ought to be more important than the other. Thus you end of with an ordered list of tasks. BUT when you boil it down to what RT is all about, namely meeting your deadlines, it doesn't matter after the 5-10 priorities because the 5-10 priorities have introduced a lot of jitter to the rest of the tasks anyway. You can just as well just put them at the same priority. Esben All of the RT priorities that we have are not absolutely necessary. As I think Steven pointed out in another email, it is nice though to be able to priortize tasks using large jumps in priorities and then being able to fill in tasks that are dependent on other tasks in between. Even if you think of nothing but the IRQ handlers, the 5-10 priorities quickly get crowded without any user tasks. -- 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: 2.6.12 PREEMPT_RT && PPC
Ingo Molnar wrote: * K.R. Foley <[EMAIL PROTECTED]> wrote: On X86 -51-36 won't build with CONFIG_BLOCKER=Y without the attached patch. thanks. I changed the include to asm/rtc.h, this should give what PPC wants to have, and should work on all architectures. Released the -37 patch. Ingo Sorry I overlooked the get_tbu and get_tbl calls. Thought the include was a leftover or something. :-/ -- 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: 2.6.12 PREEMPT_RT && PPC
Ingo Molnar wrote: * john cooper <[EMAIL PROTECTED]> wrote: Ingo, Attached is a patch for 51-28 which brings PPC up to date for 2.6.12 PREEMPT_RT. My goal was to get a more recent vintage of this work building and minimally booting for PPC. Yet this has been stable even under our internal stress tests. We now have this running on 8560 and 8260 PPC targets with a few others in the pipe. great. I've applied most of your patch and have released the -51-37 kernel. A couple of generic bits i did not apply. On X86 -51-36 won't build with CONFIG_BLOCKER=Y without the attached patch. -- kr --- linux-2.6.12/drivers/char/blocker.c.orig 2005-07-26 09:32:28.0 -0500 +++ linux-2.6.12/drivers/char/blocker.c 2005-07-26 09:32:33.0 -0500 @@ -4,7 +4,6 @@ #include #include -#include #define BLOCKER_MINOR 221
Re: 2.6.12 PREEMPT_RT PPC
Ingo Molnar wrote: * john cooper [EMAIL PROTECTED] wrote: Ingo, Attached is a patch for 51-28 which brings PPC up to date for 2.6.12 PREEMPT_RT. My goal was to get a more recent vintage of this work building and minimally booting for PPC. Yet this has been stable even under our internal stress tests. We now have this running on 8560 and 8260 PPC targets with a few others in the pipe. great. I've applied most of your patch and have released the -51-37 kernel. A couple of generic bits i did not apply. snip On X86 -51-36 won't build with CONFIG_BLOCKER=Y without the attached patch. -- kr --- linux-2.6.12/drivers/char/blocker.c.orig 2005-07-26 09:32:28.0 -0500 +++ linux-2.6.12/drivers/char/blocker.c 2005-07-26 09:32:33.0 -0500 @@ -4,7 +4,6 @@ #include linux/fs.h #include linux/miscdevice.h -#include asm/time.h #define BLOCKER_MINOR 221
Re: 2.6.12 PREEMPT_RT PPC
Ingo Molnar wrote: * K.R. Foley [EMAIL PROTECTED] wrote: snip On X86 -51-36 won't build with CONFIG_BLOCKER=Y without the attached patch. thanks. I changed the include to asm/rtc.h, this should give what PPC wants to have, and should work on all architectures. Released the -37 patch. Ingo Sorry I overlooked the get_tbu and get_tbl calls. Thought the include was a leftover or something. :-/ -- 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/
BUG triggered in Real-Time Preemption, -RT-2.6.12-final-V0.7.51-32
I had the following happen last night while running while running Con's Interbench. Looking back through my log, I do see one other case where the same BUG triggered from running updatedb (2.6.12-RT-V0.7.51-31), but it didn't have all of the ext3 errors that followed this one. I really don't have any idea if this is a problem with RT or upstream. Dell Precision 620 or 630 Dual 933 w/ 512MB ram [EMAIL PROTECTED] ~]$ /sbin/lspci 00:00.0 Host bridge: Intel Corp. 82840 840 (Carmel) Chipset Host Bridge (Hub A)(rev 02) 00:01.0 PCI bridge: Intel Corp. 82840 840 (Carmel) Chipset AGP Bridge (rev 02) 00:02.0 PCI bridge: Intel Corp. 82840 840 (Carmel) Chipset PCI Bridge (Hub B) (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02) 00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02) 00:1f.3 SMBus: Intel Corp. 82801AA SMBus (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV10GL [Quadro] (rev 10) 02:1f.0 PCI bridge: Intel Corp. 82806AA PCI64 Hub PCI Bridge (rev 03) 03:00.0 PIC: Intel Corp. 82806AA PCI64 Hub Advanced Programmable Interrupt Controller (rev 01) 04:04.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 04:05.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 04:05.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 04:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 20) ### Relevant portion of the log: Jul 19 23:16:34 porky kernel: ( pdflush-81 |#1): new 62 us maximum-latency wakeup. Jul 19 23:16:34 porky kernel: ( interbench-5583 |#1): new 76 us maximum-latency wakeup. Jul 19 23:16:34 porky kernel: VFS: brelse: Trying to free free buffer Jul 19 23:16:34 porky kernel: swapper/0[CPU#0]: BUG in __brelse at fs/buffer.c:1295 Jul 19 23:16:34 porky kernel: [] dump_stack+0x23/0x30 (20) Jul 19 23:16:34 porky kernel: [] __WARN_ON+0x6b/0x90 (52) Jul 19 23:16:34 porky kernel: [] __brelse+0x4a/0x50 (20) Jul 19 23:16:34 porky kernel: [] invalidate_bh_lru+0x3f/0x80 (20) Jul 19 23:16:34 porky kernel: [] smp_call_function_interrupt+0x48/0x70 (24) Jul 19 23:16:34 porky kernel: [] call_function_interrupt+0x1c/0x24 (60) Jul 19 23:16:34 porky kernel: [] cpu_idle+0x62/0xe0 (40) Jul 19 23:16:34 porky kernel: [] start_kernel+0x1a6/0x220 (32) Jul 19 23:16:34 porky kernel: [] 0xc010020e (1099694095) Jul 19 23:16:34 porky kernel: --- Jul 19 23:16:34 porky kernel: | preempt count: 00010003 ] Jul 19 23:16:34 porky kernel: | 3-level deep critical section nesting: Jul 19 23:16:34 porky kernel: Jul 19 23:16:34 porky kernel: .. [] add_preempt_count+0x1c/0x20 Jul 19 23:16:34 porky kernel: .[] .. ( <= invalidate_bh_lru+0x19/0x80) Jul 19 23:16:34 porky kernel: .. [] add_preempt_count+0x1c/0x20 Jul 19 23:16:34 porky kernel: .[] .. ( <= __WARN_ON+0x27/0x90) Jul 19 23:16:34 porky kernel: .. [] add_preempt_count+0x1c/0x20 Jul 19 23:16:34 porky kernel: .[] .. ( <= print_traces+0x1b/0x50) Jul 19 23:16:34 porky kernel: Jul 19 23:16:34 porky kernel: -- Jul 19 23:16:34 porky kernel: | showing all locks held by: | (swapper/0 [c037fe80, 140]): Jul 19 23:16:34 porky kernel: -- Jul 19 23:16:34 porky kernel: Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440927 Jul 19 23:16:34 porky kernel: Aborting journal on device sdb1. Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440928 Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440929 Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440930 Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_free_blocks_sb: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_free_blocks_sb: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_reserve_inode_write: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_truncate: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_reserve_inode_write: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_orphan_del: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_reserve_inode_write: Journal has aborted -- kr # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-RT-V0.7.51-32 # Tue Jul 19 10:00:22 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y
BUG triggered in Real-Time Preemption, -RT-2.6.12-final-V0.7.51-32
I had the following happen last night while running while running Con's Interbench. Looking back through my log, I do see one other case where the same BUG triggered from running updatedb (2.6.12-RT-V0.7.51-31), but it didn't have all of the ext3 errors that followed this one. I really don't have any idea if this is a problem with RT or upstream. Dell Precision 620 or 630 Dual 933 w/ 512MB ram [EMAIL PROTECTED] ~]$ /sbin/lspci 00:00.0 Host bridge: Intel Corp. 82840 840 (Carmel) Chipset Host Bridge (Hub A)(rev 02) 00:01.0 PCI bridge: Intel Corp. 82840 840 (Carmel) Chipset AGP Bridge (rev 02) 00:02.0 PCI bridge: Intel Corp. 82840 840 (Carmel) Chipset PCI Bridge (Hub B) (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02) 00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02) 00:1f.3 SMBus: Intel Corp. 82801AA SMBus (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV10GL [Quadro] (rev 10) 02:1f.0 PCI bridge: Intel Corp. 82806AA PCI64 Hub PCI Bridge (rev 03) 03:00.0 PIC: Intel Corp. 82806AA PCI64 Hub Advanced Programmable Interrupt Controller (rev 01) 04:04.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 04:05.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 04:05.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 04:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 20) ### Relevant portion of the log: Jul 19 23:16:34 porky kernel: ( pdflush-81 |#1): new 62 us maximum-latency wakeup. Jul 19 23:16:34 porky kernel: ( interbench-5583 |#1): new 76 us maximum-latency wakeup. Jul 19 23:16:34 porky kernel: VFS: brelse: Trying to free free buffer Jul 19 23:16:34 porky kernel: swapper/0[CPU#0]: BUG in __brelse at fs/buffer.c:1295 Jul 19 23:16:34 porky kernel: [c0104143] dump_stack+0x23/0x30 (20) Jul 19 23:16:34 porky kernel: [c011f03b] __WARN_ON+0x6b/0x90 (52) Jul 19 23:16:34 porky kernel: [c016f86a] __brelse+0x4a/0x50 (20) Jul 19 23:16:34 porky kernel: [c016fcaf] invalidate_bh_lru+0x3f/0x80 (20) Jul 19 23:16:34 porky kernel: [c0110688] smp_call_function_interrupt+0x48/0x70 (24) Jul 19 23:16:34 porky kernel: [c0103c2c] call_function_interrupt+0x1c/0x24 (60) Jul 19 23:16:34 porky kernel: [c0100da2] cpu_idle+0x62/0xe0 (40) Jul 19 23:16:34 porky kernel: [c045cab6] start_kernel+0x1a6/0x220 (32) Jul 19 23:16:34 porky kernel: [c010020e] 0xc010020e (1099694095) Jul 19 23:16:34 porky kernel: --- Jul 19 23:16:34 porky kernel: | preempt count: 00010003 ] Jul 19 23:16:34 porky kernel: | 3-level deep critical section nesting: Jul 19 23:16:34 porky kernel: Jul 19 23:16:34 porky kernel: .. [c013fa8c] add_preempt_count+0x1c/0x20 Jul 19 23:16:34 porky kernel: .[c016fc89] .. ( = invalidate_bh_lru+0x19/0x80) Jul 19 23:16:34 porky kernel: .. [c013fa8c] add_preempt_count+0x1c/0x20 Jul 19 23:16:34 porky kernel: .[c011eff7] .. ( = __WARN_ON+0x27/0x90) Jul 19 23:16:34 porky kernel: .. [c013fa8c] add_preempt_count+0x1c/0x20 Jul 19 23:16:34 porky kernel: .[c0140b8b] .. ( = print_traces+0x1b/0x50) Jul 19 23:16:34 porky kernel: Jul 19 23:16:34 porky kernel: -- Jul 19 23:16:34 porky kernel: | showing all locks held by: | (swapper/0 [c037fe80, 140]): Jul 19 23:16:34 porky kernel: -- Jul 19 23:16:34 porky kernel: Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440927 Jul 19 23:16:34 porky kernel: Aborting journal on device sdb1. Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440928 Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440929 Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440930 snip repetative Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_free_blocks_sb: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_free_blocks_sb: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_reserve_inode_write: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_truncate: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_reserve_inode_write: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_orphan_del: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_reserve_inode_write: Journal has aborted -- kr # # Automatically generated make config:
Re: [announce] 'patchview' script
randy_dunlap wrote:
Hi,
Someone asked me about a tool like this and I didn't know of one,
so I made this little script.
'patchview' merges a patch file and a source tree to a set of
temporary modified files. This enables better patch (re)viewing
and more viewable context. (hopefully)
Are there already other tools that do something similar to this?
(other than SCMs)
The patchview script is here:
http://www.xenotime.net/linux/scripts/patchview
usage: patchview [-f] patchfile srctree
-f : force tkdiff even if 'patch' has errors
It uses (requires) lsdiff (from patchutils) and tkdiff.
patchutils: http://cyberelk.net/tim/patchutils/
tkdiff: http://sourceforge.net/projects/tkdiff/
---
~Randy
Randy,
As Nick already pointed out, mktemp fails if the parent dir doesn't
exist. The attached patch tries to create the parent if it doesn't
exist. It also accepts a [-s] argument to bring up a single viewer at a
time. Otherwise, if there are many different files being touched by the
patch it dies a horrible death on my machine. Nice utility, btw.
--
kr
--- patchview.orig 2005-07-19 16:08:21.0 -0500
+++ patchview 2005-07-19 16:30:07.0 -0500
@@ -3,7 +3,6 @@
# License: GPL v2.
#
# uses patchutils (lsdiff) and tkdiff
-
# returns 'base'
function strip_filename()
{
@@ -25,20 +24,55 @@
}
force=0
-patchfile=$1
-srctree=$2
+single=0
VIEWER="tkdiff"
# or maybe "sh -c colordiff" would work
-if [ "$patchfile" == "-f" ]; then
- force=1
- patchfile=$2
- srctree=$3
-fi
+while [ -n "$1" ]
+do
+ case $1 in
+ -f)
+ force=1
+ ;;
+
+ -s)
+ single=1
+ ;;
+ -*)
+ if [ "${1#-}" = '?' ]
+ then
+ echo "usage: patchview [-f] [-s] patchfile srctree"
+ echo " -f : force tkdiff even if 'patch' has errors"
+ echo " -s : single tkdiff even if 'patch' contains
multiple files"
+ exit 0
+ fi
+ ;;
+
+ *)
+ # Accept filename or report a warning
+ if [ -z "${patchfile}" ]
+ then
+ patchfile=$1
+ srctree=$2
+ break
+ else
+ echo "usage: patchview [-f] [-s] patchfile srctree"
+ echo " -f : force tkdiff even if 'patch' has errors"
+ echo " -s : single tkdiff even if 'patch' contains
multiple files"
+ exit 0
+ fi
+ ;;
+ esac
+
+ # Shift argument 2 into argument 1's slot. Loop to check the argument.
+ shift
+done
+
if [ "$patchfile" = "" -o "$srctree" = "" ]; then
echo "usage: patchview [-f] patchfile srctree"
echo " -f : force tkdiff even if 'patch' has errors"
+ echo " -s : single tkdiff even if 'patch' contains multiple files"
exit 1
fi
@@ -48,6 +82,10 @@
else
TMPDIR=/tmp
fi
+if [ ! -d ${TMPDIR}/XX ];then
+ mkdir ${TMPDIR}/XX || echo "failed mktemp for patch files dir."
+fi
+
WORKDIR=`mktemp -d -p ${TMPDIR}/XX` || echo "failed mktemp for patch files
dir."
pfiles=`lsdiff --strip 1 $patchfile`
@@ -73,8 +111,13 @@
for pf in $pfiles ; do
$VIEWER $WORKDIR/$pf.orig $WORKDIR/$pf &
+ if [ ${single} -eq 1 ];then
+ wait # for viewer to exit
+ fi
done
-wait # for all viewers to exit
+if [ ${single} -eq 0 ];then
+ wait # for all viewers to exit
+fi
rm -rf $WORKDIR
Re: [announce] 'patchview' script
randy_dunlap wrote:
Hi,
Someone asked me about a tool like this and I didn't know of one,
so I made this little script.
'patchview' merges a patch file and a source tree to a set of
temporary modified files. This enables better patch (re)viewing
and more viewable context. (hopefully)
Are there already other tools that do something similar to this?
(other than SCMs)
The patchview script is here:
http://www.xenotime.net/linux/scripts/patchview
usage: patchview [-f] patchfile srctree
-f : force tkdiff even if 'patch' has errors
It uses (requires) lsdiff (from patchutils) and tkdiff.
patchutils: http://cyberelk.net/tim/patchutils/
tkdiff: http://sourceforge.net/projects/tkdiff/
---
~Randy
Randy,
As Nick already pointed out, mktemp fails if the parent dir doesn't
exist. The attached patch tries to create the parent if it doesn't
exist. It also accepts a [-s] argument to bring up a single viewer at a
time. Otherwise, if there are many different files being touched by the
patch it dies a horrible death on my machine. Nice utility, btw.
--
kr
--- patchview.orig 2005-07-19 16:08:21.0 -0500
+++ patchview 2005-07-19 16:30:07.0 -0500
@@ -3,7 +3,6 @@
# License: GPL v2.
#
# uses patchutils (lsdiff) and tkdiff
-
# returns 'base'
function strip_filename()
{
@@ -25,20 +24,55 @@
}
force=0
-patchfile=$1
-srctree=$2
+single=0
VIEWER=tkdiff
# or maybe sh -c colordiff would work
-if [ $patchfile == -f ]; then
- force=1
- patchfile=$2
- srctree=$3
-fi
+while [ -n $1 ]
+do
+ case $1 in
+ -f)
+ force=1
+ ;;
+
+ -s)
+ single=1
+ ;;
+ -*)
+ if [ ${1#-} = '?' ]
+ then
+ echo usage: patchview [-f] [-s] patchfile srctree
+ echo -f : force tkdiff even if 'patch' has errors
+ echo -s : single tkdiff even if 'patch' contains
multiple files
+ exit 0
+ fi
+ ;;
+
+ *)
+ # Accept filename or report a warning
+ if [ -z ${patchfile} ]
+ then
+ patchfile=$1
+ srctree=$2
+ break
+ else
+ echo usage: patchview [-f] [-s] patchfile srctree
+ echo -f : force tkdiff even if 'patch' has errors
+ echo -s : single tkdiff even if 'patch' contains
multiple files
+ exit 0
+ fi
+ ;;
+ esac
+
+ # Shift argument 2 into argument 1's slot. Loop to check the argument.
+ shift
+done
+
if [ $patchfile = -o $srctree = ]; then
echo usage: patchview [-f] patchfile srctree
echo -f : force tkdiff even if 'patch' has errors
+ echo -s : single tkdiff even if 'patch' contains multiple files
exit 1
fi
@@ -48,6 +82,10 @@
else
TMPDIR=/tmp
fi
+if [ ! -d ${TMPDIR}/XX ];then
+ mkdir ${TMPDIR}/XX || echo failed mktemp for patch files dir.
+fi
+
WORKDIR=`mktemp -d -p ${TMPDIR}/XX` || echo failed mktemp for patch files
dir.
pfiles=`lsdiff --strip 1 $patchfile`
@@ -73,8 +111,13 @@
for pf in $pfiles ; do
$VIEWER $WORKDIR/$pf.orig $WORKDIR/$pf
+ if [ ${single} -eq 1 ];then
+ wait # for viewer to exit
+ fi
done
-wait # for all viewers to exit
+if [ ${single} -eq 0 ];then
+ wait # for all viewers to exit
+fi
rm -rf $WORKDIR
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?
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?
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?
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?
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?
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?
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: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
Ingo Molnar wrote: * K.R. Foley <[EMAIL PROTECTED]> wrote: Ingo Molnar wrote: * Daniel Walker <[EMAIL PROTECTED]> wrote: I observed a situation on a dual xeon where IOAPIC_POSTFLUSH , if on, would actually cause spurious interrupts. It was odd cause it's suppose to stop them .. If there was a lot of interrupt traffic on one IRQ , it would cause interrupt traffic on another IRQ. This would result in "nobody cared" messages , and the storming IRQ line would get shutdown. This would only happen in PREEMPT_RT . does it happen with the latest kernel too? There were a couple of things broken in the IOAPIC code in various earlier versions. Ingo Is this why I have been able to boot the latest versions without the noapic option (and without noticeable keyboard repeat problems) or has it just been dumb luck? yes, i think it's related - the IO-APIC code is now more robust than ever, and that's why any known-broken system would be important to re-check. Ingo Well I have booted -27 a couple of times and -28 once now without supplying the noapic boot option and I haven't seen any of the keyboard repeat problems that I reported late last week. This was on my dual 2.6 Xeon w/HT. I have never seen this behavior on any of my older systems. Because of the fact that the problem showed up sporadically, I can't say for sure that it is gone. However, so far so good. I will report any changes that I see. -- 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: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
Ingo Molnar wrote: * Daniel Walker <[EMAIL PROTECTED]> wrote: I observed a situation on a dual xeon where IOAPIC_POSTFLUSH , if on, would actually cause spurious interrupts. It was odd cause it's suppose to stop them .. If there was a lot of interrupt traffic on one IRQ , it would cause interrupt traffic on another IRQ. This would result in "nobody cared" messages , and the storming IRQ line would get shutdown. This would only happen in PREEMPT_RT . does it happen with the latest kernel too? There were a couple of things broken in the IOAPIC code in various earlier versions. Ingo Is this why I have been able to boot the latest versions without the noapic option (and without noticeable keyboard repeat problems) or has it just been dumb luck? -- 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: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
Ingo Molnar wrote: * Daniel Walker [EMAIL PROTECTED] wrote: I observed a situation on a dual xeon where IOAPIC_POSTFLUSH , if on, would actually cause spurious interrupts. It was odd cause it's suppose to stop them .. If there was a lot of interrupt traffic on one IRQ , it would cause interrupt traffic on another IRQ. This would result in nobody cared messages , and the storming IRQ line would get shutdown. This would only happen in PREEMPT_RT . does it happen with the latest kernel too? There were a couple of things broken in the IOAPIC code in various earlier versions. Ingo Is this why I have been able to boot the latest versions without the noapic option (and without noticeable keyboard repeat problems) or has it just been dumb luck? -- 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: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
Ingo Molnar wrote: * K.R. Foley [EMAIL PROTECTED] wrote: Ingo Molnar wrote: * Daniel Walker [EMAIL PROTECTED] wrote: I observed a situation on a dual xeon where IOAPIC_POSTFLUSH , if on, would actually cause spurious interrupts. It was odd cause it's suppose to stop them .. If there was a lot of interrupt traffic on one IRQ , it would cause interrupt traffic on another IRQ. This would result in nobody cared messages , and the storming IRQ line would get shutdown. This would only happen in PREEMPT_RT . does it happen with the latest kernel too? There were a couple of things broken in the IOAPIC code in various earlier versions. Ingo Is this why I have been able to boot the latest versions without the noapic option (and without noticeable keyboard repeat problems) or has it just been dumb luck? yes, i think it's related - the IO-APIC code is now more robust than ever, and that's why any known-broken system would be important to re-check. Ingo Well I have booted -27 a couple of times and -28 once now without supplying the noapic boot option and I haven't seen any of the keyboard repeat problems that I reported late last week. This was on my dual 2.6 Xeon w/HT. I have never seen this behavior on any of my older systems. Because of the fact that the problem showed up sporadically, I can't say for sure that it is gone. However, so far so good. I will report any changes that I see. -- 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: Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems
Ingo Molnar wrote: * K.R. Foley <[EMAIL PROTECTED]> wrote: Ingo, I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when running the RT patches. The problem manifests itself as if the key were stuck but happens far too quickly for that to be the case. I realize that the statements above are far from scientific, but I can't seem to narrow it down further. 2.6.12 doesn't seem to have the problem at all, only when running the RT patches. It SEEMS to have gotten worse lately. I am attaching my config as well as the output from lspci. Adjusting the delay in the keyboard repeat seems to help. Any ideas? hm. Would be nice to somehow find a condition that triggers it. One possibility is that something else is starving the keyboard handling path. Right now it's handled via workqueues, which live in keventd. Do things improve if you chrt keventd up to prio 99? Also i'd chrt the keyboard IRQ thread up to prio 99 too. I would like very much to come up with a condition that causes it. Unfortunately, the only event that I know of that is associated with this typing. :-) There does not seem to be a method to the madness. As for bumping the priorities, I tried them all, at least the ones mentioned above. I also tried the timer just for grins, after changing the keyboard repeat delay seemed to help a bit. None of them seemed to help, at least not for an extended period of time. the other possibility is some IRQ handling bug - those are usually specific to the IRQ controller, so try turning off (or on) the IO-APIC [if the box has an IO-APIC], does that change anything? You may be on to something here. Booting with noapic SEEMS to help. Ingo -- 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: Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems
Doug Maxey wrote: On Fri, 08 Jul 2005 21:13:26 +0200, Ingo Molnar wrote: * K.R. Foley <[EMAIL PROTECTED]> wrote: Ingo, I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when running the RT patches. The problem manifests itself as if the key were stuck but happens far too quickly for that to be the case. I realize that the statements above are far from scientific, but I can't seem to narrow it down further. 2.6.12 doesn't seem to have the problem at all, only when running the RT patches. It SEEMS to have gotten worse lately. I am attaching my config as well as the output from lspci. Adjusting the delay in the keyboard repeat seems to help. Any ideas? Is the keyboard standard (PS2) or USB? Did not see the detail. Sorry. It is PS2. hm. Would be nice to somehow find a condition that triggers it. One possibility is that something else is starving the keyboard handling path. Right now it's handled via workqueues, which live in keventd. Do things improve if you chrt keventd up to prio 99? Also i'd chrt the keyboard IRQ thread up to prio 99 too. the other possibility is some IRQ handling bug - those are usually specific to the IRQ controller, so try turning off (or on) the IO-APIC [if the box has an IO-APIC], does that change anything? FWIW, I have seen this issue under USB, off and on since about 2.6.9. Never have dug into it, was always simpler to just unplug and re-plug the keyboard. Of course, this predates RT. ++doug -- 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: Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems
Dave Neuer wrote: On 7/8/05, Ingo Molnar <[EMAIL PROTECTED]> wrote: * K.R. Foley <[EMAIL PROTECTED]> wrote: Ingo, I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when running the RT patches. 2.6.12 doesn't seem to have the problem at all, only when running the RT patches. It SEEMS to have gotten worse lately. Adjusting the delay in the keyboard repeat seems to help. Any ideas? hm. Would be nice to somehow find a condition that triggers it. FWIW, I've had this problem from time to time on my Compaq Presario x1010us laptop (which also uses the ICH-4 chipset) with several kernel versions between 2.6.7 and 2.6.12, and I have _not_ been running the RT patches (though I plan to start soon). It seems to only happen when the laptop has been running for a while. Also, X has been running each time. When it occurs, the stuck key events follow the mouse focus from window to window, and in the few cases where I'm able to either switch out of X to a different VT or kill X, the keyboard is still "wedged" -- if I recall correctly, switching VTs results in no keyboard events reaching that VT (as if X is still consuming them). Can't remember what happens when I've successfully killed X. I have seen this happen once or twice, but this behaves more like the keyboard really is stuck. The situation I am having is very brief repeats of a key rather than just sticking forever. FWIW, when I have seen the above situation it behaved just as you described with the stuck key following the focus. Again, happens uncommonly enough that I haven't put much effort into debugging it. Anyway, unless it's a similar but unlrelated bug, it's not _caused_ by RT. Dave -- 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/
Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems
Sorry Ingo. Missed cc'ing lkml the first time. Ingo, I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when running the RT patches. The problem manifests itself as if the key were stuck but happens far too quickly for that to be the case. I realize that the statements above are far from scientific, but I can't seem to narrow it down further. 2.6.12 doesn't seem to have the problem at all, only when running the RT patches. It SEEMS to have gotten worse lately. I am attaching my config as well as the output from lspci. Adjusting the delay in the keyboard repeat seems to help. Any ideas? -- kr 00:00.0 Host bridge: Intel Corp. E7505 Memory Controller Hub (rev 03) 00:00.1 Class ff00: Intel Corp. E7505/E7205 Series RAS Controller (rev 03) 00:01.0 PCI bridge: Intel Corp. E7505/E7205 PCI-to-AGP Bridge (rev 03) 00:02.0 PCI bridge: Intel Corp. E7505 Hub Interface B PCI-to-PCI Bridge (rev 03) 00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) 00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 82) 00:1f.0 ISA bridge: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801DB (ICH4) IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3) 02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03) 02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03) 02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03) 02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03) 04:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet (rev 02) 05:01.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-RT-V0.7.51-17 # Fri Jul 8 11:32:56 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_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 is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set 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 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 is not set CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y # 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_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_IOAPIC_FAST=y
Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems
Sorry Ingo. Missed cc'ing lkml the first time. Ingo, I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when running the RT patches. The problem manifests itself as if the key were stuck but happens far too quickly for that to be the case. I realize that the statements above are far from scientific, but I can't seem to narrow it down further. 2.6.12 doesn't seem to have the problem at all, only when running the RT patches. It SEEMS to have gotten worse lately. I am attaching my config as well as the output from lspci. Adjusting the delay in the keyboard repeat seems to help. Any ideas? -- kr 00:00.0 Host bridge: Intel Corp. E7505 Memory Controller Hub (rev 03) 00:00.1 Class ff00: Intel Corp. E7505/E7205 Series RAS Controller (rev 03) 00:01.0 PCI bridge: Intel Corp. E7505/E7205 PCI-to-AGP Bridge (rev 03) 00:02.0 PCI bridge: Intel Corp. E7505 Hub Interface B PCI-to-PCI Bridge (rev 03) 00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) 00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 82) 00:1f.0 ISA bridge: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801DB (ICH4) IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3) 02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03) 02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03) 02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03) 02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03) 04:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet (rev 02) 05:01.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-RT-V0.7.51-17 # Fri Jul 8 11:32:56 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_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 is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set 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 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 is not set CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y # 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_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_IOAPIC_FAST=y
Re: Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems
Dave Neuer wrote: On 7/8/05, Ingo Molnar [EMAIL PROTECTED] wrote: * K.R. Foley [EMAIL PROTECTED] wrote: Ingo, I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when running the RT patches. snip 2.6.12 doesn't seem to have the problem at all, only when running the RT patches. It SEEMS to have gotten worse lately. snip Adjusting the delay in the keyboard repeat seems to help. Any ideas? hm. Would be nice to somehow find a condition that triggers it. FWIW, I've had this problem from time to time on my Compaq Presario x1010us laptop (which also uses the ICH-4 chipset) with several kernel versions between 2.6.7 and 2.6.12, and I have _not_ been running the RT patches (though I plan to start soon). It seems to only happen when the laptop has been running for a while. Also, X has been running each time. When it occurs, the stuck key events follow the mouse focus from window to window, and in the few cases where I'm able to either switch out of X to a different VT or kill X, the keyboard is still wedged -- if I recall correctly, switching VTs results in no keyboard events reaching that VT (as if X is still consuming them). Can't remember what happens when I've successfully killed X. I have seen this happen once or twice, but this behaves more like the keyboard really is stuck. The situation I am having is very brief repeats of a key rather than just sticking forever. FWIW, when I have seen the above situation it behaved just as you described with the stuck key following the focus. Again, happens uncommonly enough that I haven't put much effort into debugging it. Anyway, unless it's a similar but unlrelated bug, it's not _caused_ by RT. Dave -- 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: Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems
Doug Maxey wrote: On Fri, 08 Jul 2005 21:13:26 +0200, Ingo Molnar wrote: * K.R. Foley [EMAIL PROTECTED] wrote: Ingo, I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when running the RT patches. The problem manifests itself as if the key were stuck but happens far too quickly for that to be the case. I realize that the statements above are far from scientific, but I can't seem to narrow it down further. 2.6.12 doesn't seem to have the problem at all, only when running the RT patches. It SEEMS to have gotten worse lately. I am attaching my config as well as the output from lspci. Adjusting the delay in the keyboard repeat seems to help. Any ideas? Is the keyboard standard (PS2) or USB? Did not see the detail. Sorry. It is PS2. hm. Would be nice to somehow find a condition that triggers it. One possibility is that something else is starving the keyboard handling path. Right now it's handled via workqueues, which live in keventd. Do things improve if you chrt keventd up to prio 99? Also i'd chrt the keyboard IRQ thread up to prio 99 too. the other possibility is some IRQ handling bug - those are usually specific to the IRQ controller, so try turning off (or on) the IO-APIC [if the box has an IO-APIC], does that change anything? FWIW, I have seen this issue under USB, off and on since about 2.6.9. Never have dug into it, was always simpler to just unplug and re-plug the keyboard. Of course, this predates RT. ++doug -- 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: Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems
Ingo Molnar wrote: * K.R. Foley [EMAIL PROTECTED] wrote: Ingo, I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when running the RT patches. The problem manifests itself as if the key were stuck but happens far too quickly for that to be the case. I realize that the statements above are far from scientific, but I can't seem to narrow it down further. 2.6.12 doesn't seem to have the problem at all, only when running the RT patches. It SEEMS to have gotten worse lately. I am attaching my config as well as the output from lspci. Adjusting the delay in the keyboard repeat seems to help. Any ideas? hm. Would be nice to somehow find a condition that triggers it. One possibility is that something else is starving the keyboard handling path. Right now it's handled via workqueues, which live in keventd. Do things improve if you chrt keventd up to prio 99? Also i'd chrt the keyboard IRQ thread up to prio 99 too. I would like very much to come up with a condition that causes it. Unfortunately, the only event that I know of that is associated with this typing. :-) There does not seem to be a method to the madness. As for bumping the priorities, I tried them all, at least the ones mentioned above. I also tried the timer just for grins, after changing the keyboard repeat delay seemed to help a bit. None of them seemed to help, at least not for an extended period of time. the other possibility is some IRQ handling bug - those are usually specific to the IRQ controller, so try turning off (or on) the IO-APIC [if the box has an IO-APIC], does that change anything? You may be on to something here. Booting with noapic SEEMS to help. Ingo -- 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/
2.6.12-rc3 won't boot from aic7899
I am having a problem getting my Dell Precision 620 with dual PIII 933's and 512 Mb memory to boot 2.6.12-rc3. The problem seems to be the aic7899. The aic7899 driver is compiled into the kernel along with the rest of scsi. I have had to compile in the scsi for every version of 2.6.12-x, but they have all worked until 2.6.12-rc3. I am attaching the output from lspci, the serial console log and the config file. If there is anything else that I can provide, test, etc. I will be glad to do so. -- kr [EMAIL PROTECTED] ~]$ /sbin/lspci 00:00.0 Host bridge: Intel Corp. 82840 840 (Carmel) Chipset Host Bridge (Hub A)(rev 02) 00:01.0 PCI bridge: Intel Corp. 82840 840 (Carmel) Chipset AGP Bridge (rev 02) 00:02.0 PCI bridge: Intel Corp. 82840 840 (Carmel) Chipset PCI Bridge (Hub B) (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02) 00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02) 00:1f.3 SMBus: Intel Corp. 82801AA SMBus (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV10GL [Quadro] (rev 10) 02:1f.0 PCI bridge: Intel Corp. 82806AA PCI64 Hub PCI Bridge (rev 03) 03:00.0 PIC: Intel Corp. 82806AA PCI64 Hub Advanced Programmable Interrupt Controller (rev 01) 04:04.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 04:05.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 04:05.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 04:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 20) Linux version 2.6.12-rc3 ([EMAIL PROTECTED]) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)) #2 SMP Fri Apr 22 12:39:45 CDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1ff9e000 (usable) BIOS-e820: 1ff9e000 - 2000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 511MB LOWMEM available. found SMP MP-table at 000fe710 DMI 2.3 present. ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:8 APIC version 17 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) Using ACPI for processor (LAPIC) configuration information Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: DELL Product ID: WS 620 APIC at: 0xFEE0 I/O APIC #2 Version 32 at 0xFEC0. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 2 Allocating PCI resources starting at 2000 (gap: 2000:dec0) Built 1 zonelists Kernel command line: ro root=LABEL=/ console=ttyS0,38400 console=tty0 nmi_watchdog=1 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 931.181 MHz processor. Using tsc 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: 514180k/523896k available (2105k kernel code, 9148k reserved, 1134k data, 232k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 512 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel Pentium III (Coppermine) stepping 06 Booting processor 1/1 eip 2000 Initializing CPU#1 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel Pentium III (Coppermine) stepping 06 Total of 2 processors activated (3698.68 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=0 testing NMI watchdog ... CPU#1: NMI appears to be stuck! checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs checking if image is initramfs... it is Freeing initrd memory: 295k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfc03e, last bus=4 PCI: Using configuration type 1 mtrr: v2.0 (20020519) Linux Plug and Play Support v0.97 (c) Adam Belay SCSI subsystem initialized PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Transparent bridge - :00:1e.0 PCI: Using IRQ router PIIX/ICH [8086/2410] at :00:1f.0 PCI->APIC IRQ transform: :00:1f.2[D] -> IRQ 19 PCI->APIC IRQ
Re: fix ultrastor.c compile error
Linus Torvalds wrote: On Fri, 22 Apr 2005, K.R. Foley wrote: This simple patch fixes a compile error in the ultrastor driver. Patch was originally submitted by Barry K. Nathan as referenced here: http://marc.theaimsgroup.com/?l=linux-kernel=111391774018717=2 I just regenerated it against your current git tree. Please apply. Can you also verify that it works? No. I can only verify that it compiles. I don't have the hardware. Enabled by default in the config and it hadn't blown up before. Finally, when forwarding other peoples patches, please make sure that you include their commentary, and their sign-off. In this case the original definitely has them.. Will do. Linus -- 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/
2.6.12-rc3 won't boot from aic7899
I am having a problem getting my Dell Precision 620 with dual PIII 933's and 512 Mb memory to boot 2.6.12-rc3. The problem seems to be the aic7899. The aic7899 driver is compiled into the kernel along with the rest of scsi. I have had to compile in the scsi for every version of 2.6.12-x, but they have all worked until 2.6.12-rc3. I am attaching the output from lspci, the serial console log and the config file. If there is anything else that I can provide, test, etc. I will be glad to do so. -- kr [EMAIL PROTECTED] ~]$ /sbin/lspci 00:00.0 Host bridge: Intel Corp. 82840 840 (Carmel) Chipset Host Bridge (Hub A)(rev 02) 00:01.0 PCI bridge: Intel Corp. 82840 840 (Carmel) Chipset AGP Bridge (rev 02) 00:02.0 PCI bridge: Intel Corp. 82840 840 (Carmel) Chipset PCI Bridge (Hub B) (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02) 00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02) 00:1f.3 SMBus: Intel Corp. 82801AA SMBus (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV10GL [Quadro] (rev 10) 02:1f.0 PCI bridge: Intel Corp. 82806AA PCI64 Hub PCI Bridge (rev 03) 03:00.0 PIC: Intel Corp. 82806AA PCI64 Hub Advanced Programmable Interrupt Controller (rev 01) 04:04.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 04:05.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 04:05.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 04:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 20) Linux version 2.6.12-rc3 ([EMAIL PROTECTED]) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)) #2 SMP Fri Apr 22 12:39:45 CDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1ff9e000 (usable) BIOS-e820: 1ff9e000 - 2000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 511MB LOWMEM available. found SMP MP-table at 000fe710 DMI 2.3 present. ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:8 APIC version 17 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) Using ACPI for processor (LAPIC) configuration information Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: DELL Product ID: WS 620 APIC at: 0xFEE0 I/O APIC #2 Version 32 at 0xFEC0. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 2 Allocating PCI resources starting at 2000 (gap: 2000:dec0) Built 1 zonelists Kernel command line: ro root=LABEL=/ console=ttyS0,38400 console=tty0 nmi_watchdog=1 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 931.181 MHz processor. Using tsc 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: 514180k/523896k available (2105k kernel code, 9148k reserved, 1134k data, 232k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 512 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel Pentium III (Coppermine) stepping 06 Booting processor 1/1 eip 2000 Initializing CPU#1 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel Pentium III (Coppermine) stepping 06 Total of 2 processors activated (3698.68 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=0 testing NMI watchdog ... CPU#1: NMI appears to be stuck! checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs checking if image is initramfs... it is Freeing initrd memory: 295k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfc03e, last bus=4 PCI: Using configuration type 1 mtrr: v2.0 (20020519) Linux Plug and Play Support v0.97 (c) Adam Belay SCSI subsystem initialized PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Transparent bridge - :00:1e.0 PCI: Using IRQ router PIIX/ICH [8086/2410] at :00:1f.0 PCI-APIC IRQ transform: :00:1f.2[D] - IRQ 19 PCI-APIC IRQ transform:
Re: fix ultrastor.c compile error
Linus Torvalds wrote: On Fri, 22 Apr 2005, K.R. Foley wrote: This simple patch fixes a compile error in the ultrastor driver. Patch was originally submitted by Barry K. Nathan as referenced here: http://marc.theaimsgroup.com/?l=linux-kernelm=111391774018717w=2 I just regenerated it against your current git tree. Please apply. Can you also verify that it works? No. I can only verify that it compiles. I don't have the hardware. Enabled by default in the config and it hadn't blown up before. Finally, when forwarding other peoples patches, please make sure that you include their commentary, and their sign-off. In this case the original definitely has them.. Will do. Linus -- 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/
fix ultrastor.c compile error
This simple patch fixes a compile error in the ultrastor driver. Patch
was originally submitted by Barry K. Nathan as referenced here:
http://marc.theaimsgroup.com/?l=linux-kernel=111391774018717=2
I just regenerated it against your current git tree. Please apply.
--
kr
Signed-off-by: K.R. Foley <[EMAIL PROTECTED]>
--- linux.test/drivers/scsi/ultrastor.c.orig 2005-04-22 08:38:06.0 -0500
+++ linux.test/drivers/scsi/ultrastor.c 2005-04-22 08:38:12.0 -0500
@@ -945,7 +945,7 @@
config.mscp[mscp_index].SCint, SCpnt);
#endif
if (config.mscp[mscp_index].SCint == 0)
- return FAILURE;
+ return FAILED;
if (config.mscp[mscp_index].SCint != SCpnt) panic("Bad abort");
config.mscp[mscp_index].SCint = NULL;
fix ultrastor.c compile error
This simple patch fixes a compile error in the ultrastor driver. Patch was originally submitted by Barry K. Nathan as referenced here: http://marc.theaimsgroup.com/?l=linux-kernelm=111391774018717w=2 I just regenerated it against your current git tree. Please apply. -- kr Signed-off-by: K.R. Foley [EMAIL PROTECTED] --- linux.test/drivers/scsi/ultrastor.c.orig 2005-04-22 08:38:06.0 -0500 +++ linux.test/drivers/scsi/ultrastor.c 2005-04-22 08:38:12.0 -0500 @@ -945,7 +945,7 @@ config.mscp[mscp_index].SCint, SCpnt); #endif if (config.mscp[mscp_index].SCint == 0) - return FAILURE; + return FAILED; if (config.mscp[mscp_index].SCint != SCpnt) panic(Bad abort); config.mscp[mscp_index].SCint = NULL;
Re: Heads up on 2.6.12-rc1 and later
Tom Duffy wrote: On Thu, 2005-04-14 at 12:29 -0400, [EMAIL PROTECTED] wrote: In testing with 2.6.12-rc1 and -rc2, we've been encountering an issue on SMP machines with the loading of scsi_mod and sd_mod modules. The sd_mod load fails with unresolved symbols. It appears to be a race condition based on how quickly the modules load. This works fine on uni systems and on 2.6.11. Evidently, this problem has been before and is resolved by a short delay between module loads. http://seclists.org/lists/linux-kernel/2005/Apr/0383.html BTW. I haven't had time to debug this any further myself, but for me adding a one second delay between module loads DOES NOT WORK for me. Given it's been around for 2 -rc itterations, I expect it needed some highlighting. Ah, so it is not just me (thought I was going crazy -- couldn't get a kernel to boot on my SMP system): Mounting sysfs Creating /dev Starting udev Loading scsi_modSCSI subsystem initialized .ko module LoadFusion MPT base driver 3.01.20 ing sd_mod.ko momptscsih: Unknown symbol mpt_deregister mptscsih: Unknown symbol mpt_reset_deregister mptscsih: Unknown symbol mpt_config mptscsih: Unknown symbol mpt_device_driver_deregister mptscsih: Unknown symbol mpt_free_msg_frame mptscsih: Unknown symbol scsi_remove_host mptscsih: Unknown symbol mpt_print_ioc_summary mptscsih: Unknown symbol mpt_GetIocState mptscsih: Unknown symbol mpt_put_msg_frame mptscsih: Unknown symbol mpt_register mptscsih: Unknown symbol mpt_add_sge mptscsih: Unknown symbol mpt_event_deregister mptscsih: Unknown symbol scsi_host_put mptscsih: Unknown symbol mpt_read_ioc_pg_3 mptscsih: Unknown symbol scsi_scan_host mptscsih: Unknown symbol mpt_event_register mptscsih: Unknown symbol mpt_send_handshake_request mptscsih: Unknown symbol scsi_add_host mptscsih: Unknown symbol mpt_device_driver_register mptscsih: Unknown symbol scsi_adjust_queue_depth mptscsih: Unknown symbol mpt_get_msg_frame mptscsih: Unknown symbol mpt_reset_register mptscsih: Unknown symbol mpt_HardResetHandler mptscsih: Unknown symbol scsi_host_alloc mptscsih: Unknown symbol ioc_list dule Loading mpinput: ImPS/2 Generic Wheel Mouse on isa0060/serio1 sd_mod: Unknown symbol scsi_device_get sd_mod: Unknown symbol scsi_wait_req sd_mod: Unknown symbol scsi_get_sense_info_fld sd_mod: Unknown symbol scsicam_bios_param sd_mod: Unknown symbol scsi_command_normalize_sense sd_mod: Unknown symbol scsi_test_unit_ready sd_mod: Unknown symbol scsi_block_when_processing_errors sd_mod: Unknown symbol scsi_register_driver sd_mod: Unknown symbol scsi_ioctl sd_mod: Unknown symbol scsi_nonblockable_ioctl sd_mod: Unknown symbol scsi_device_put sd_mod: Unknown symbol scsi_request_normalize_sense sd_mod: Unknown symbol __scsi_mode_sense sd_mod: Unknown symbol scsi_logging_level sd_mod: Unknown symbol scsi_print_req_sense sd_mod: Unknown symbol scsi_release_request sd_mod: Unknown symbol scsi_print_sense sd_mod: Unknown symbol scsi_allocate_request sd_mod: Unknown symbol scsi_io_completion sd_mod: Unknown symbol scsi_set_medium_removal Loading mptscsiCopyright (c) 1999-2004 LSI Logic Corporation h.ko module LoaACPI: PCI Interrupt :05:05.0[A] -> ding dm-mod.ko mGSI 72 (level, low) -> IRQ 185 odule Loading jmptbase: Initiating ioc0 bringup bd.ko module Lodevice-mapper: 4.4.0-ioctl (2005-01-12) initialised: [EMAIL PROTECTED] ading ext3.ko moext3: Unknown symbol journal_force_commit dule insmod: erext3: Unknown symbol journal_dirty_data ror inserting '/tK3e:r Unenkl npowann iscy -m bonlo t jsouynrncailn_gf: oArctete_mcopmtemdit t_no eskitledl iniext!t3 Unknown symbol journal_init_dev -- 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: Heads up on 2.6.12-rc1 and later
Tom Duffy wrote: On Thu, 2005-04-14 at 12:29 -0400, [EMAIL PROTECTED] wrote: In testing with 2.6.12-rc1 and -rc2, we've been encountering an issue on SMP machines with the loading of scsi_mod and sd_mod modules. The sd_mod load fails with unresolved symbols. It appears to be a race condition based on how quickly the modules load. This works fine on uni systems and on 2.6.11. Evidently, this problem has been before and is resolved by a short delay between module loads. http://seclists.org/lists/linux-kernel/2005/Apr/0383.html BTW. I haven't had time to debug this any further myself, but for me adding a one second delay between module loads DOES NOT WORK for me. Given it's been around for 2 -rc itterations, I expect it needed some highlighting. Ah, so it is not just me (thought I was going crazy -- couldn't get a kernel to boot on my SMP system): Mounting sysfs Creating /dev Starting udev Loading scsi_modSCSI subsystem initialized .ko module LoadFusion MPT base driver 3.01.20 ing sd_mod.ko momptscsih: Unknown symbol mpt_deregister mptscsih: Unknown symbol mpt_reset_deregister mptscsih: Unknown symbol mpt_config mptscsih: Unknown symbol mpt_device_driver_deregister mptscsih: Unknown symbol mpt_free_msg_frame mptscsih: Unknown symbol scsi_remove_host mptscsih: Unknown symbol mpt_print_ioc_summary mptscsih: Unknown symbol mpt_GetIocState mptscsih: Unknown symbol mpt_put_msg_frame mptscsih: Unknown symbol mpt_register mptscsih: Unknown symbol mpt_add_sge mptscsih: Unknown symbol mpt_event_deregister mptscsih: Unknown symbol scsi_host_put mptscsih: Unknown symbol mpt_read_ioc_pg_3 mptscsih: Unknown symbol scsi_scan_host mptscsih: Unknown symbol mpt_event_register mptscsih: Unknown symbol mpt_send_handshake_request mptscsih: Unknown symbol scsi_add_host mptscsih: Unknown symbol mpt_device_driver_register mptscsih: Unknown symbol scsi_adjust_queue_depth mptscsih: Unknown symbol mpt_get_msg_frame mptscsih: Unknown symbol mpt_reset_register mptscsih: Unknown symbol mpt_HardResetHandler mptscsih: Unknown symbol scsi_host_alloc mptscsih: Unknown symbol ioc_list dule Loading mpinput: ImPS/2 Generic Wheel Mouse on isa0060/serio1 sd_mod: Unknown symbol scsi_device_get sd_mod: Unknown symbol scsi_wait_req sd_mod: Unknown symbol scsi_get_sense_info_fld sd_mod: Unknown symbol scsicam_bios_param sd_mod: Unknown symbol scsi_command_normalize_sense sd_mod: Unknown symbol scsi_test_unit_ready sd_mod: Unknown symbol scsi_block_when_processing_errors sd_mod: Unknown symbol scsi_register_driver sd_mod: Unknown symbol scsi_ioctl sd_mod: Unknown symbol scsi_nonblockable_ioctl sd_mod: Unknown symbol scsi_device_put sd_mod: Unknown symbol scsi_request_normalize_sense sd_mod: Unknown symbol __scsi_mode_sense sd_mod: Unknown symbol scsi_logging_level sd_mod: Unknown symbol scsi_print_req_sense sd_mod: Unknown symbol scsi_release_request sd_mod: Unknown symbol scsi_print_sense sd_mod: Unknown symbol scsi_allocate_request sd_mod: Unknown symbol scsi_io_completion sd_mod: Unknown symbol scsi_set_medium_removal Loading mptscsiCopyright (c) 1999-2004 LSI Logic Corporation h.ko module LoaACPI: PCI Interrupt :05:05.0[A] - ding dm-mod.ko mGSI 72 (level, low) - IRQ 185 odule Loading jmptbase: Initiating ioc0 bringup bd.ko module Lodevice-mapper: 4.4.0-ioctl (2005-01-12) initialised: [EMAIL PROTECTED] ading ext3.ko moext3: Unknown symbol journal_force_commit dule insmod: erext3: Unknown symbol journal_dirty_data ror inserting '/ex0tK3e:r Unenkl npowann iscy -m bonlo t jsouynrncailn_gf: oArctete_mcopmtemdit t_no eskitledl iniext!t3 Unknown symbol journal_init_dev -- 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: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00
Ingo, It would seem that in the latest patch RT-V0.7.45-00 we have reverted back to removing the define of jbd_debug which the attached patch (against one of the 2.6.11 versions) fixed. -- kr --- linux-2.6.11/include/linux/jbd.h.orig 2005-03-16 09:18:51.0 -0600 +++ linux-2.6.11/include/linux/jbd.h2005-03-16 09:19:24.0 -0600 @@ -65,6 +65,7 @@ extern int journal_enable_debug; } \ } while (0) #else +#define jbd_debug(f, a...) /**/ #endif extern void * __jbd_kmalloc (const char *where, size_t size, int flags, int retry);
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00
Ingo, It would seem that in the latest patch RT-V0.7.45-00 we have reverted back to removing the define of jbd_debug which the attached patch (against one of the 2.6.11 versions) fixed. -- kr --- linux-2.6.11/include/linux/jbd.h.orig 2005-03-16 09:18:51.0 -0600 +++ linux-2.6.11/include/linux/jbd.h2005-03-16 09:19:24.0 -0600 @@ -65,6 +65,7 @@ extern int journal_enable_debug; } \ } while (0) #else +#define jbd_debug(f, a...) /**/ #endif extern void * __jbd_kmalloc (const char *where, size_t size, int flags, int retry);
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00
Lee Revell wrote: On Fri, 2005-04-08 at 15:26 -0500, K.R. Foley wrote: Lee Revell wrote: Meh, I'll try again, maybe it's some weird NFS problem. Lee Hmm. Maybe. I should probably mention that I am doing an FC3 install via NFS from my older SMP system right now while also building V0.7.44-03. Tried again and it works. Weird... Lee Very wierd. It worries me when things like that happen. ;-) -- 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: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00
Lee Revell wrote: On Fri, 2005-04-08 at 15:15 -0500, K.R. Foley wrote: Lee Revell wrote: On Fri, 2005-04-08 at 16:22 +0100, Rui Nuno Capela wrote: Our first victim!! :-) No kidding!? V0.7.44-02 does not even compile for me. It appears to be full of merge errors. I must be in the twilight zone over here. V0.7.44-02 runs fine on my UP system, my older SMP system (although I have to compile in my SCSI drivers, but that has nothing to do with this patch) and my faster P4/HT SMP system at the office. Meh, I'll try again, maybe it's some weird NFS problem. Lee Hmm. Maybe. I should probably mention that I am doing an FC3 install via NFS from my older SMP system right now while also building V0.7.44-03. -- 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: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00
Lee Revell wrote: On Fri, 2005-04-08 at 15:15 -0500, K.R. Foley wrote: Lee Revell wrote: On Fri, 2005-04-08 at 16:22 +0100, Rui Nuno Capela wrote: Our first victim!! :-) No kidding!? V0.7.44-02 does not even compile for me. It appears to be full of merge errors. I must be in the twilight zone over here. V0.7.44-02 runs fine on my UP system, my older SMP system (although I have to compile in my SCSI drivers, but that has nothing to do with this patch) and my faster P4/HT SMP system at the office. Meh, I'll try again, maybe it's some weird NFS problem. Lee Hmm. Maybe. I should probably mention that I am doing an FC3 install via NFS from my older SMP system right now while also building V0.7.44-03. -- 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: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00
Lee Revell wrote: On Fri, 2005-04-08 at 15:26 -0500, K.R. Foley wrote: Lee Revell wrote: Meh, I'll try again, maybe it's some weird NFS problem. Lee Hmm. Maybe. I should probably mention that I am doing an FC3 install via NFS from my older SMP system right now while also building V0.7.44-03. Tried again and it works. Weird... Lee Very wierd. It worries me when things like that happen. ;-) -- 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: 2.6.12-rc1 won't boot if SCSI drivers are selected as modules
Jon Smirl wrote: On Apr 1, 2005 7:17 AM, K.R. Foley <[EMAIL PROTECTED]> wrote: I have an old Dell Precision 620 workstation with dual PIII 933's and 512 Mb memory. It also uses AIC-7899P U160/m SCSI controllers with one U160 drive (boot drive) and one slower 18 Gb. I have been running many different variants of the kernel on this system for quite some time with much success. However, no amount of gnashing of teeth or pulling of hair have been able to get this system to boot ANY 2.6.12-rc1 (including 2.6.12-rc1 vanilla, 2.6.12-rc1-mm3 and various RT patches) variant when the SCSI drivers are selected as modules (which is the way that I have always done it). Last night I built all of the necessary drivers into the kernel and the system boots fine. I am also seeing this but not on every boot. My work around is to add a 'sleep 2' to the nash script after the modules are loaded. Compling everything in also worked. I will give this a try. Although I did compare the init from a working initrd with the init from a non-working initrd, with no differences :-/ This is discussed in the thread: "current linus bk, error mounting root". I believe the answer is that it is not a kernel problem, instead the init scripts have to be fixed. I figured it probably had been discussed if anyone else was having this problem, it's just that I have been pretty scarce in the last couple of weeks. I did try searching the archives but that didn't produce any help. ;-) I will go back and take a look at this thread. Thanks much. -- 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: 2.6.12-rc1 won't boot if SCSI drivers are selected as modules
Jon Smirl wrote: On Apr 1, 2005 7:17 AM, K.R. Foley [EMAIL PROTECTED] wrote: I have an old Dell Precision 620 workstation with dual PIII 933's and 512 Mb memory. It also uses AIC-7899P U160/m SCSI controllers with one U160 drive (boot drive) and one slower 18 Gb. I have been running many different variants of the kernel on this system for quite some time with much success. However, no amount of gnashing of teeth or pulling of hair have been able to get this system to boot ANY 2.6.12-rc1 (including 2.6.12-rc1 vanilla, 2.6.12-rc1-mm3 and various RT patches) variant when the SCSI drivers are selected as modules (which is the way that I have always done it). Last night I built all of the necessary drivers into the kernel and the system boots fine. I am also seeing this but not on every boot. My work around is to add a 'sleep 2' to the nash script after the modules are loaded. Compling everything in also worked. I will give this a try. Although I did compare the init from a working initrd with the init from a non-working initrd, with no differences :-/ This is discussed in the thread: current linus bk, error mounting root. I believe the answer is that it is not a kernel problem, instead the init scripts have to be fixed. I figured it probably had been discussed if anyone else was having this problem, it's just that I have been pretty scarce in the last couple of weeks. I did try searching the archives but that didn't produce any help. ;-) I will go back and take a look at this thread. Thanks much. -- 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: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
Gene Heskett wrote: On Friday 01 April 2005 13:27, K.R. Foley wrote: Gene Heskett wrote: It was up to 43-04 by the time I got there. This one didn't go in cleanly Ingo. From my build-src scripts output: --- Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 [...] patching file lib/rwsem-spinlock.c Hunk #5 FAILED at 133. Hunk #6 FAILED at 160. Hunk #7 FAILED at 179. Hunk #8 FAILED at 194. Hunk #9 FAILED at 204. Hunk #10 FAILED at 231. Hunk #11 FAILED at 250. Hunk #12 FAILED at 265. Hunk #13 FAILED at 274. Hunk #14 FAILED at 293. Hunk #15 FAILED at 314. 11 out of 15 hunks FAILED -- saving rejects to file lib/rwsem-spinlock.c.rej --- I doubt it would run, so I haven't built it. Should I? Adding the attached patch on top of the above should resolve the failures, at least in the patching. Still working on building it. I assume you mean apply before the 43-04 patch? No actually I meant to apply it after the 43-04 patch. However, Ingo has a new patch that should cover this also. I'll give it a go later today, right now I've got dirt to move in the yard. -- 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: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
Gene Heskett wrote:
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts output:
---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file lib/rwsem-spinlock.c
Hunk #5 FAILED at 133.
Hunk #6 FAILED at 160.
Hunk #7 FAILED at 179.
Hunk #8 FAILED at 194.
Hunk #9 FAILED at 204.
Hunk #10 FAILED at 231.
Hunk #11 FAILED at 250.
Hunk #12 FAILED at 265.
Hunk #13 FAILED at 274.
Hunk #14 FAILED at 293.
Hunk #15 FAILED at 314.
11 out of 15 hunks FAILED -- saving rejects to file
lib/rwsem-spinlock.c.rej
---
I doubt it would run, so I haven't built it. Should I?
Adding the attached patch on top of the above should resolve the
failures, at least in the patching. Still working on building it.
--
kr
--- linux-2.6.12/lib/rwsem-spinlock.c.orig 2005-04-01 12:00:21.0 -0600
+++ linux-2.6.12/lib/rwsem-spinlock.c 2005-04-01 12:19:06.0 -0600
@@ -18,7 +18,7 @@ struct rwsem_waiter {
};
#if RWSEM_DEBUG
-void rwsemtrace(struct rw_semaphore *sem, const char *str)
+void rwsemtrace(struct compat_rw_semaphore *sem, const char *str)
{
if (sem->debug)
printk("[%d] %s({%d,%d})\n",
@@ -30,7 +30,7 @@ void rwsemtrace(struct rw_semaphore *sem
/*
* initialise the semaphore
*/
-void fastcall init_rwsem(struct rw_semaphore *sem)
+void fastcall compat_init_rwsem(struct compat_rw_semaphore *sem)
{
sem->activity = 0;
spin_lock_init(>wait_lock);
@@ -49,8 +49,8 @@ void fastcall init_rwsem(struct rw_semap
* - woken process blocks are discarded from the list after having task zeroed
* - writers are only woken if wakewrite is non-zero
*/
-static inline struct rw_semaphore *
-__rwsem_do_wake(struct rw_semaphore *sem, int wakewrite)
+static inline struct compat_rw_semaphore *
+__rwsem_do_wake(struct compat_rw_semaphore *sem, int wakewrite)
{
struct rwsem_waiter *waiter;
struct task_struct *tsk;
@@ -111,8 +111,8 @@ __rwsem_do_wake(struct rw_semaphore *sem
/*
* wake a single writer
*/
-static inline struct rw_semaphore *
-__rwsem_wake_one_writer(struct rw_semaphore *sem)
+static inline struct compat_rw_semaphore *
+__rwsem_wake_one_writer(struct compat_rw_semaphore *sem)
{
struct rwsem_waiter *waiter;
struct task_struct *tsk;
@@ -133,7 +133,8 @@ __rwsem_wake_one_writer(struct rw_semaph
/*
* get a read lock on the semaphore
*/
-void fastcall __sched __down_read(struct rw_semaphore *sem)
+void fastcall __sched __down_read(struct compat_rw_semaphore *sem)
+
{
struct rwsem_waiter waiter;
struct task_struct *tsk;
@@ -179,7 +180,8 @@ void fastcall __sched __down_read(struct
/*
* trylock for reading -- returns 1 if successful, 0 if contention
*/
-int fastcall __down_read_trylock(struct rw_semaphore *sem)
+int fastcall __down_read_trylock(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
int ret = 0;
@@ -204,7 +206,8 @@ int fastcall __down_read_trylock(struct
* get a write lock on the semaphore
* - we increment the waiting count anyway to indicate an exclusive lock
*/
-void fastcall __sched __down_write(struct rw_semaphore *sem)
+void fastcall __sched __down_write(struct compat_rw_semaphore *sem)
+
{
struct rwsem_waiter waiter;
struct task_struct *tsk;
@@ -250,7 +253,8 @@ void fastcall __sched __down_write(struc
/*
* trylock for writing -- returns 1 if successful, 0 if contention
*/
-int fastcall __down_write_trylock(struct rw_semaphore *sem)
+int fastcall __down_write_trylock(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
int ret = 0;
@@ -274,7 +278,8 @@ int fastcall __down_write_trylock(struct
/*
* release a read lock on the semaphore
*/
-void fastcall __up_read(struct rw_semaphore *sem)
+void fastcall __up_read(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
@@ -293,7 +298,7 @@ void fastcall __up_read(struct rw_semaph
/*
* release a write lock on the semaphore
*/
-void fastcall __up_write(struct rw_semaphore *sem)
+void fastcall __up_write(struct compat_rw_semaphore *sem)
{
unsigned long flags;
@@ -314,7 +319,7 @@ void fastcall __up_write(struct rw_semap
* downgrade a write lock into a read lock
* - just wake up any readers at the front of the queue
*/
-void fastcall __downgrade_write(struct rw_semaphore *sem)
+void fastcall __downgrade_write(struct compat_rw_semaphore *sem)
{
unsigned long flags;
@@ -331,7 +336,7 @@ void fastcall __downgrade_write(struct r
rwsemtrace(sem, "Leaving __downgrade_write");
}
-EXPORT_SYMBOL(init_rwsem);
+EXPORT_SYMBOL(compat_init_rwsem);
EXPORT_SYMBOL(__down_read);
EXPORT_SYMBOL(__down_read_trylock);
EXPORT_SYMBOL(__down_write);
2.6.12-rc1 won't boot if SCSI drivers are selected as modules
I have an old Dell Precision 620 workstation with dual PIII 933's and 512 Mb memory. It also uses AIC-7899P U160/m SCSI controllers with one U160 drive (boot drive) and one slower 18 Gb. I have been running many different variants of the kernel on this system for quite some time with much success. However, no amount of gnashing of teeth or pulling of hair have been able to get this system to boot ANY 2.6.12-rc1 (including 2.6.12-rc1 vanilla, 2.6.12-rc1-mm3 and various RT patches) variant when the SCSI drivers are selected as modules (which is the way that I have always done it). Last night I built all of the necessary drivers into the kernel and the system boots fine. I don't have an oops or anything that really helps diagnose this. The symptoms are: when booting init tries to load the modules from the initrd and usually loading of sd_mod produces several unresolved symbols and it goes down hill from there. The symbols that it is bitching about scsi_request_normalize_sense, __scsi_mode_sense, scsi_logging_level, etc.) are in fact in scsi_mod (according to nm) which should have been and appears to have been loaded prior to trying to load sd_mod. I am attaching my config and output from lspci. If there is anything else that I have left out that I could provide, let me know. I do have these kernels running without incident on my IDE based workstation at the office. -- kr # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1 # Tue Mar 29 14:43:07 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_LOCK_KERNEL=y # # 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 is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_CPUSETS=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set 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 CONFIG_STOP_MACHINE=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=y # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # 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_MGEODE 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_RWSEM_XCHGADD_ALGORITHM=y 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 is not set CONFIG_SMP=y CONFIG_NR_CPUS=8 # CONFIG_SCHED_SMT is not set # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # CONFIG_SECCOMP is not set # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # # CONFIG_ACPI is not set CONFIG_ACPI_BOOT=y # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY_PROC is not set
2.6.12-rc1 won't boot if SCSI drivers are selected as modules
I have an old Dell Precision 620 workstation with dual PIII 933's and 512 Mb memory. It also uses AIC-7899P U160/m SCSI controllers with one U160 drive (boot drive) and one slower 18 Gb. I have been running many different variants of the kernel on this system for quite some time with much success. However, no amount of gnashing of teeth or pulling of hair have been able to get this system to boot ANY 2.6.12-rc1 (including 2.6.12-rc1 vanilla, 2.6.12-rc1-mm3 and various RT patches) variant when the SCSI drivers are selected as modules (which is the way that I have always done it). Last night I built all of the necessary drivers into the kernel and the system boots fine. I don't have an oops or anything that really helps diagnose this. The symptoms are: when booting init tries to load the modules from the initrd and usually loading of sd_mod produces several unresolved symbols and it goes down hill from there. The symbols that it is bitching about scsi_request_normalize_sense, __scsi_mode_sense, scsi_logging_level, etc.) are in fact in scsi_mod (according to nm) which should have been and appears to have been loaded prior to trying to load sd_mod. I am attaching my config and output from lspci. If there is anything else that I have left out that I could provide, let me know. I do have these kernels running without incident on my IDE based workstation at the office. -- kr # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1 # Tue Mar 29 14:43:07 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_LOCK_KERNEL=y # # 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 is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_CPUSETS=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set 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 CONFIG_STOP_MACHINE=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=y # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # 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_MGEODE 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_RWSEM_XCHGADD_ALGORITHM=y 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 is not set CONFIG_SMP=y CONFIG_NR_CPUS=8 # CONFIG_SCHED_SMT is not set # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # CONFIG_SECCOMP is not set # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # # CONFIG_ACPI is not set CONFIG_ACPI_BOOT=y # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY_PROC is not set
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
Gene Heskett wrote:
snip
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts output:
---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file lib/rwsem-spinlock.c
Hunk #5 FAILED at 133.
Hunk #6 FAILED at 160.
Hunk #7 FAILED at 179.
Hunk #8 FAILED at 194.
Hunk #9 FAILED at 204.
Hunk #10 FAILED at 231.
Hunk #11 FAILED at 250.
Hunk #12 FAILED at 265.
Hunk #13 FAILED at 274.
Hunk #14 FAILED at 293.
Hunk #15 FAILED at 314.
11 out of 15 hunks FAILED -- saving rejects to file
lib/rwsem-spinlock.c.rej
---
I doubt it would run, so I haven't built it. Should I?
Adding the attached patch on top of the above should resolve the
failures, at least in the patching. Still working on building it.
--
kr
--- linux-2.6.12/lib/rwsem-spinlock.c.orig 2005-04-01 12:00:21.0 -0600
+++ linux-2.6.12/lib/rwsem-spinlock.c 2005-04-01 12:19:06.0 -0600
@@ -18,7 +18,7 @@ struct rwsem_waiter {
};
#if RWSEM_DEBUG
-void rwsemtrace(struct rw_semaphore *sem, const char *str)
+void rwsemtrace(struct compat_rw_semaphore *sem, const char *str)
{
if (sem-debug)
printk([%d] %s({%d,%d})\n,
@@ -30,7 +30,7 @@ void rwsemtrace(struct rw_semaphore *sem
/*
* initialise the semaphore
*/
-void fastcall init_rwsem(struct rw_semaphore *sem)
+void fastcall compat_init_rwsem(struct compat_rw_semaphore *sem)
{
sem-activity = 0;
spin_lock_init(sem-wait_lock);
@@ -49,8 +49,8 @@ void fastcall init_rwsem(struct rw_semap
* - woken process blocks are discarded from the list after having task zeroed
* - writers are only woken if wakewrite is non-zero
*/
-static inline struct rw_semaphore *
-__rwsem_do_wake(struct rw_semaphore *sem, int wakewrite)
+static inline struct compat_rw_semaphore *
+__rwsem_do_wake(struct compat_rw_semaphore *sem, int wakewrite)
{
struct rwsem_waiter *waiter;
struct task_struct *tsk;
@@ -111,8 +111,8 @@ __rwsem_do_wake(struct rw_semaphore *sem
/*
* wake a single writer
*/
-static inline struct rw_semaphore *
-__rwsem_wake_one_writer(struct rw_semaphore *sem)
+static inline struct compat_rw_semaphore *
+__rwsem_wake_one_writer(struct compat_rw_semaphore *sem)
{
struct rwsem_waiter *waiter;
struct task_struct *tsk;
@@ -133,7 +133,8 @@ __rwsem_wake_one_writer(struct rw_semaph
/*
* get a read lock on the semaphore
*/
-void fastcall __sched __down_read(struct rw_semaphore *sem)
+void fastcall __sched __down_read(struct compat_rw_semaphore *sem)
+
{
struct rwsem_waiter waiter;
struct task_struct *tsk;
@@ -179,7 +180,8 @@ void fastcall __sched __down_read(struct
/*
* trylock for reading -- returns 1 if successful, 0 if contention
*/
-int fastcall __down_read_trylock(struct rw_semaphore *sem)
+int fastcall __down_read_trylock(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
int ret = 0;
@@ -204,7 +206,8 @@ int fastcall __down_read_trylock(struct
* get a write lock on the semaphore
* - we increment the waiting count anyway to indicate an exclusive lock
*/
-void fastcall __sched __down_write(struct rw_semaphore *sem)
+void fastcall __sched __down_write(struct compat_rw_semaphore *sem)
+
{
struct rwsem_waiter waiter;
struct task_struct *tsk;
@@ -250,7 +253,8 @@ void fastcall __sched __down_write(struc
/*
* trylock for writing -- returns 1 if successful, 0 if contention
*/
-int fastcall __down_write_trylock(struct rw_semaphore *sem)
+int fastcall __down_write_trylock(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
int ret = 0;
@@ -274,7 +278,8 @@ int fastcall __down_write_trylock(struct
/*
* release a read lock on the semaphore
*/
-void fastcall __up_read(struct rw_semaphore *sem)
+void fastcall __up_read(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
@@ -293,7 +298,7 @@ void fastcall __up_read(struct rw_semaph
/*
* release a write lock on the semaphore
*/
-void fastcall __up_write(struct rw_semaphore *sem)
+void fastcall __up_write(struct compat_rw_semaphore *sem)
{
unsigned long flags;
@@ -314,7 +319,7 @@ void fastcall __up_write(struct rw_semap
* downgrade a write lock into a read lock
* - just wake up any readers at the front of the queue
*/
-void fastcall __downgrade_write(struct rw_semaphore *sem)
+void fastcall __downgrade_write(struct compat_rw_semaphore *sem)
{
unsigned long flags;
@@ -331,7 +336,7 @@ void fastcall __downgrade_write(struct r
rwsemtrace(sem, Leaving __downgrade_write);
}
-EXPORT_SYMBOL(init_rwsem);
+EXPORT_SYMBOL(compat_init_rwsem);
EXPORT_SYMBOL(__down_read);
EXPORT_SYMBOL(__down_read_trylock);
EXPORT_SYMBOL(__down_write);
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
Gene Heskett wrote: On Friday 01 April 2005 13:27, K.R. Foley wrote: Gene Heskett wrote: snip It was up to 43-04 by the time I got there. This one didn't go in cleanly Ingo. From my build-src scripts output: --- Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 [...] patching file lib/rwsem-spinlock.c Hunk #5 FAILED at 133. Hunk #6 FAILED at 160. Hunk #7 FAILED at 179. Hunk #8 FAILED at 194. Hunk #9 FAILED at 204. Hunk #10 FAILED at 231. Hunk #11 FAILED at 250. Hunk #12 FAILED at 265. Hunk #13 FAILED at 274. Hunk #14 FAILED at 293. Hunk #15 FAILED at 314. 11 out of 15 hunks FAILED -- saving rejects to file lib/rwsem-spinlock.c.rej --- I doubt it would run, so I haven't built it. Should I? Adding the attached patch on top of the above should resolve the failures, at least in the patching. Still working on building it. I assume you mean apply before the 43-04 patch? No actually I meant to apply it after the 43-04 patch. However, Ingo has a new patch that should cover this also. I'll give it a go later today, right now I've got dirt to move in the yard. -- 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: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
Ingo Molnar wrote: * Ingo Molnar <[EMAIL PROTECTED]> wrote: * Ingo Molnar <[EMAIL PROTECTED]> wrote: hm, another thing: i think call_rcu() needs to take the read-lock. Right now it assumes that it has the data structure private, but that's only statistically true on PREEMPT_RT: another CPU may have this CPU's RCU control structure in use. So IRQs-off (or preempt-off) is not a guarantee to have the data structure, the read lock has to be taken. i've reworked the code to use the read-lock to access the per-CPU data RCU structures, and it boots with 2 CPUs and PREEMPT_RT now. The -40-05 patch can be downloaded from the usual place: bah, it's leaking dentries at a massive scale. I'm giving up on this variant for the time being and have gone towards a much simpler variant, implemented in the -40-07 patch at: http://redhat.com/~mingo/realtime-preempt/ Actually this is more correctly related to -RT-2.6.12-rc1-V0.7.41-08. This one boots on one of my SMP systems (dual 2.6 GHz Zeon) doesn't on the other (dual PIII 933 MHz). Unfortunately not close to the one that doesn't boot right now so can't debug it at all. Was still building on the UP box, but now that one seems to have gone down in flames. This system was running -RT-2.6.12-rc1-V0.7.41-00 while trying to build -RT-2.6.12-rc1-V0.7.41-07. :( -- 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: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
Ingo Molnar wrote: * Ingo Molnar [EMAIL PROTECTED] wrote: * Ingo Molnar [EMAIL PROTECTED] wrote: hm, another thing: i think call_rcu() needs to take the read-lock. Right now it assumes that it has the data structure private, but that's only statistically true on PREEMPT_RT: another CPU may have this CPU's RCU control structure in use. So IRQs-off (or preempt-off) is not a guarantee to have the data structure, the read lock has to be taken. i've reworked the code to use the read-lock to access the per-CPU data RCU structures, and it boots with 2 CPUs and PREEMPT_RT now. The -40-05 patch can be downloaded from the usual place: bah, it's leaking dentries at a massive scale. I'm giving up on this variant for the time being and have gone towards a much simpler variant, implemented in the -40-07 patch at: http://redhat.com/~mingo/realtime-preempt/ Actually this is more correctly related to -RT-2.6.12-rc1-V0.7.41-08. This one boots on one of my SMP systems (dual 2.6 GHz Zeon) doesn't on the other (dual PIII 933 MHz). Unfortunately not close to the one that doesn't boot right now so can't debug it at all. Was still building on the UP box, but now that one seems to have gone down in flames. This system was running -RT-2.6.12-rc1-V0.7.41-00 while trying to build -RT-2.6.12-rc1-V0.7.41-07. :( -- 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: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00
Lee Revell wrote:
On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote:
i have released the -V0.7.41-00 Real-Time Preemption patch (merged to
2.6.12-rc1), which can be downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
3ms latency in the NFS client code. Workload was a kernel compile over
NFS.
preemption latency trace v1.1.4 on 2.6.12-rc1-RT-V0.7.41-00
latency: 3178 ïs, #4095/14224, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-
_--=> CPU#
/ _-=> irqs-off
| / _=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
(T1/#0)<...> 32105 0 3 0004 [0011939614227867] 0.000ms (+4137027.445ms): <6500646c> (<6100>)
(T1/#2)<...> 32105 0 3 0004 0002 [0011939614228097] 0.000ms (+0.000ms): __trace_start_sched_wakeup+0x9a/0xd0 (try_to_wake_up+0x94/0x140 )
(T1/#3)<...> 32105 0 3 0003 0003 [0011939614228436] 0.000ms (+0.000ms): preempt_schedule+0x11/0x80 (try_to_wake_up+0x94/0x140 )
(T3/#4)<...>-32105 0dn.30ïs : try_to_wake_up+0x11e/0x140 <<...>-2> (69 76):
(T1/#5)<...> 32105 0 3 0002 0005 [0011939614228942] 0.000ms (+0.000ms): preempt_schedule+0x11/0x80 (try_to_wake_up+0xf8/0x140 )
(T1/#6)<...> 32105 0 3 0002 0006 [0011939614229130] 0.000ms (+0.000ms): wake_up_process+0x35/0x40 (do_softirq+0x3f/0x50 )
(T6/#7)<...>-32105 0dn.11ïs < (1)
(T1/#8)<...> 32105 0 2 0001 0008 [0011939614229782] 0.001ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70 (nfs_wait_on_requests+0x6d/0x110 )
(T1/#9)<...> 32105 0 2 0001 0009 [0011939614229985] 0.001ms (+0.000ms): __lookup+0xe/0xd0 (radix_tree_gang_lookup+0x52/0x70 )
(T1/#10)<...> 32105 0 2 0001 000a [0011939614230480] 0.001ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70 (nfs_wait_on_requests+0x6d/0x110 )
(T1/#11)<...> 32105 0 2 0001 000b [0011939614230634] 0.002ms (+0.000ms): __lookup+0xe/0xd0 (radix_tree_gang_lookup+0x52/0x70 )
(T1/#12)<...> 32105 0 2 0001 000c [0011939614230889] 0.002ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70 (nfs_wait_on_requests+0x6d/0x110 )
(T1/#13)<...> 32105 0 2 0001 000d [0011939614231034] 0.002ms (+0.000ms): __lookup+0xe/0xd0 (radix_tree_gang_lookup+0x52/0x70 )
(T1/#14)<...> 32105 0 2 0001 000e [0011939614231302] 0.002ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70 (nfs_wait_on_requests+0x6d/0x110 )
(T1/#15)<...> 32105 0 2 0001 000f [0011939614231419] 0.002ms (+0.000ms): __lookup+0xe/0xd0 (radix_tree_gang_lookup+0x52/0x70 )
(last two lines just repeat)
This is probably not be a regression; I had never tested this with NFS
before.
Lee
Lee,
I did some testing with NFS quite a while ago. Actually it was the NFS
compile within the stress-kernel pkg. I had similar crappy performance
problems. Ingo pointed out that there were serious locking issues with
NFS and suggested that I report the problems to the NFS folks, which I
did. The reports seemed to fall mostly on deaf ears, at least that was
my perspective. I decided to move on and took the NFS compile out of my
stress testing to be revisited at a later time.
--
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: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00
Lee Revell wrote:
On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote:
i have released the -V0.7.41-00 Real-Time Preemption patch (merged to
2.6.12-rc1), which can be downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
3ms latency in the NFS client code. Workload was a kernel compile over
NFS.
preemption latency trace v1.1.4 on 2.6.12-rc1-RT-V0.7.41-00
latency: 3178 s, #4095/14224, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-
_--= CPU#
/ _-= irqs-off
| / _= need-resched
|| / _---= hardirq/softirq
||| / _--= preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
(T1/#0)... 32105 0 3 0004 [0011939614227867] 0.000ms (+4137027.445ms): 6500646c (6100)
(T1/#2)... 32105 0 3 0004 0002 [0011939614228097] 0.000ms (+0.000ms): __trace_start_sched_wakeup+0x9a/0xd0 c013150a (try_to_wake_up+0x94/0x140 c0110474)
(T1/#3)... 32105 0 3 0003 0003 [0011939614228436] 0.000ms (+0.000ms): preempt_schedule+0x11/0x80 c02b57c1 (try_to_wake_up+0x94/0x140 c0110474)
(T3/#4)...-32105 0dn.30s : try_to_wake_up+0x11e/0x140 c01104fe ...-2 (69 76):
(T1/#5)... 32105 0 3 0002 0005 [0011939614228942] 0.000ms (+0.000ms): preempt_schedule+0x11/0x80 c02b57c1 (try_to_wake_up+0xf8/0x140 c01104d8)
(T1/#6)... 32105 0 3 0002 0006 [0011939614229130] 0.000ms (+0.000ms): wake_up_process+0x35/0x40 c0110555 (do_softirq+0x3f/0x50 c011b05f)
(T6/#7)...-32105 0dn.11s (1)
(T1/#8)... 32105 0 2 0001 0008 [0011939614229782] 0.001ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70 c01e05ee (nfs_wait_on_requests+0x6d/0x110 c01c744d)
(T1/#9)... 32105 0 2 0001 0009 [0011939614229985] 0.001ms (+0.000ms): __lookup+0xe/0xd0 c01e051e (radix_tree_gang_lookup+0x52/0x70 c01e0632)
(T1/#10)... 32105 0 2 0001 000a [0011939614230480] 0.001ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70 c01e05ee (nfs_wait_on_requests+0x6d/0x110 c01c744d)
(T1/#11)... 32105 0 2 0001 000b [0011939614230634] 0.002ms (+0.000ms): __lookup+0xe/0xd0 c01e051e (radix_tree_gang_lookup+0x52/0x70 c01e0632)
(T1/#12)... 32105 0 2 0001 000c [0011939614230889] 0.002ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70 c01e05ee (nfs_wait_on_requests+0x6d/0x110 c01c744d)
(T1/#13)... 32105 0 2 0001 000d [0011939614231034] 0.002ms (+0.000ms): __lookup+0xe/0xd0 c01e051e (radix_tree_gang_lookup+0x52/0x70 c01e0632)
(T1/#14)... 32105 0 2 0001 000e [0011939614231302] 0.002ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70 c01e05ee (nfs_wait_on_requests+0x6d/0x110 c01c744d)
(T1/#15)... 32105 0 2 0001 000f [0011939614231419] 0.002ms (+0.000ms): __lookup+0xe/0xd0 c01e051e (radix_tree_gang_lookup+0x52/0x70 c01e0632)
(last two lines just repeat)
This is probably not be a regression; I had never tested this with NFS
before.
Lee
Lee,
I did some testing with NFS quite a while ago. Actually it was the NFS
compile within the stress-kernel pkg. I had similar crappy performance
problems. Ingo pointed out that there were serious locking issues with
NFS and suggested that I report the problems to the NFS folks, which I
did. The reports seemed to fall mostly on deaf ears, at least that was
my perspective. I decided to move on and took the NFS compile out of my
stress testing to be revisited at a later time.
--
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: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00
Lee Revell wrote: On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote: the biggest change in this patch is the merge of Paul E. McKenney's preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it is still quite experimental at this stage, it allowed the removal of locking cruft (mainly in the networking code), so it could solve some of the longstanding netfilter/networking deadlocks/crashes reported by a number of people. Be careful nevertheless. With PREEMPT_RT my machine deadlocked within 20 minutes of boot. "apt-get dist-upgrade" seemed to trigger the crash. I did not see any Oops unfortunately. Lee Lee, Just curious. Is this with UP or SMP? I currently have my UP box running PREEMPT_RT, with no problems thus far. However, my SMP box dies while booting (with an oops). I am working on trying to get setup to capture the oops, although it might be tomorrow before I get that done. -- 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: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00
Lee Revell wrote: On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote: the biggest change in this patch is the merge of Paul E. McKenney's preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it is still quite experimental at this stage, it allowed the removal of locking cruft (mainly in the networking code), so it could solve some of the longstanding netfilter/networking deadlocks/crashes reported by a number of people. Be careful nevertheless. With PREEMPT_RT my machine deadlocked within 20 minutes of boot. apt-get dist-upgrade seemed to trigger the crash. I did not see any Oops unfortunately. Lee Lee, Just curious. Is this with UP or SMP? I currently have my UP box running PREEMPT_RT, with no problems thus far. However, my SMP box dies while booting (with an oops). I am working on trying to get setup to capture the oops, although it might be tomorrow before I get that done. -- 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: [PATCH 0/5] ppc RT: Realtime preempt support for PPC
Ingo Molnar wrote: hi Frank - sorry about the late reply, was busy with other things. Your ppc patches look mostly mergeable, with some small details still open: * Frank Rowand <[EMAIL PROTECTED]> wrote: The patches are: 1/5 ppc_rt.patch - the core realtime functionality for PPC what is the rationale behind the rt_lock.h changes? The #ifdef CONFIG_PPC32 changes in generic code are not really acceptable, the -RT tree tries to keep a single spinlock definition and debugging primitives, across all architectures. to drive things forward, i've applied the first 3 patches (except the rt_lock.h chunk from the first patch), and released it as part of the 40-03 patch: http://redhat.com/~mingo/realtime-preempt/ Is no one else having trouble compiling this one? The attached one liner reverses a one line in the above patch. kr --- linux-2.6.11/include/linux/jbd.h.orig 2005-03-16 09:18:51.0 -0600 +++ linux-2.6.11/include/linux/jbd.h 2005-03-16 09:19:24.0 -0600 @@ -65,6 +65,7 @@ extern int journal_enable_debug; } \ } while (0) #else +#define jbd_debug(f, a...) /**/ #endif extern void * __jbd_kmalloc (const char *where, size_t size, int flags, int retry);
Re: [PATCH 0/5] ppc RT: Realtime preempt support for PPC
Ingo Molnar wrote: hi Frank - sorry about the late reply, was busy with other things. Your ppc patches look mostly mergeable, with some small details still open: * Frank Rowand [EMAIL PROTECTED] wrote: The patches are: 1/5 ppc_rt.patch - the core realtime functionality for PPC what is the rationale behind the rt_lock.h changes? The #ifdef CONFIG_PPC32 changes in generic code are not really acceptable, the -RT tree tries to keep a single spinlock definition and debugging primitives, across all architectures. to drive things forward, i've applied the first 3 patches (except the rt_lock.h chunk from the first patch), and released it as part of the 40-03 patch: http://redhat.com/~mingo/realtime-preempt/ Is no one else having trouble compiling this one? The attached one liner reverses a one line in the above patch. kr --- linux-2.6.11/include/linux/jbd.h.orig 2005-03-16 09:18:51.0 -0600 +++ linux-2.6.11/include/linux/jbd.h 2005-03-16 09:19:24.0 -0600 @@ -65,6 +65,7 @@ extern int journal_enable_debug; } \ } while (0) #else +#define jbd_debug(f, a...) /**/ #endif extern void * __jbd_kmalloc (const char *where, size_t size, int flags, int retry);
