John Sigler wrote:
I noticed the following message in my kernel log.
kernel: neigh: timer & !nud_in_timer
(Might be due to a race condition.)
I'm running a UP Linux version 2.6.22.1-rt9
( http://rt.wiki.kernel.org/index.php )
The following /proc entries might be relevant.
/proc/sys/net/
John Sigler wrote:
I noticed the following message in my kernel log.
kernel: neigh: timer !nud_in_timer
(Might be due to a race condition.)
I'm running a UP Linux version 2.6.22.1-rt9
( http://rt.wiki.kernel.org/index.php )
The following /proc entries might be relevant.
/proc/sys/net/ipv4
Hello,
I noticed the following message in my kernel log.
kernel: neigh: timer & !nud_in_timer
(Might be due to a race condition.)
I'm running a UP Linux version 2.6.22.1-rt9
( http://rt.wiki.kernel.org/index.php )
The following /proc entries might be relevant.
Hello,
I noticed the following message in my kernel log.
kernel: neigh: timer !nud_in_timer
(Might be due to a race condition.)
I'm running a UP Linux version 2.6.22.1-rt9
( http://rt.wiki.kernel.org/index.php )
The following /proc entries might be relevant.
Dick Johnson wrote:
You can't just touch a scope-probe to the PCI
clock pin and clip the scope-probe grounding
lead to a convenient "ground" to make these
measurements! You need a special fixture that
will make a low-inductance connection to the
PCI bus in the same manner as the interface chip.
Hello Sébastien,
Sébastien Dugué wrote:
John Sigler wrote:
I have an x86 system, running Linux 2.6.22.1-rt9, in which I plug one
or two PCI I/O boards. I had been experiencing complete system lock-ups
until I sent the system to the board manufacturer, and he fixed the
problem. However, he
Hello everyone,
I have an x86 system, running Linux 2.6.22.1-rt9, in which I plug one
or two PCI I/O boards. I had been experiencing complete system lock-ups
until I sent the system to the board manufacturer, and he fixed the
problem. However, he told me that the PCI clock seemed out of spec,
as
Hello everyone,
I have an x86 system, running Linux 2.6.22.1-rt9, in which I plug one
or two PCI I/O boards. I had been experiencing complete system lock-ups
until I sent the system to the board manufacturer, and he fixed the
problem. However, he told me that the PCI clock seemed out of spec,
as
Hello Sébastien,
Sébastien Dugué wrote:
John Sigler wrote:
I have an x86 system, running Linux 2.6.22.1-rt9, in which I plug one
or two PCI I/O boards. I had been experiencing complete system lock-ups
until I sent the system to the board manufacturer, and he fixed the
problem. However, he
Dick Johnson wrote:
You can't just touch a scope-probe to the PCI
clock pin and clip the scope-probe grounding
lead to a convenient ground to make these
measurements! You need a special fixture that
will make a low-inductance connection to the
PCI bus in the same manner as the interface chip.
John Sigler wrote:
John Sigler wrote:
I have an x86 system with two PCI slots, in which I inserted two
specialized output cards (Dektec DTA-105).
http://www.dektec.com/Products/DTA-105/
(They provide an open source driver.)
My problem is: when I write to the 4 ports (each card has 2 ports
John Sigler wrote:
John Sigler wrote:
I have an x86 system with two PCI slots, in which I inserted two
specialized output cards (Dektec DTA-105).
http://www.dektec.com/Products/DTA-105/
(They provide an open source driver.)
My problem is: when I write to the 4 ports (each card has 2 ports
John Sigler wrote:
When I run 'halt' or 'poweroff' (sysvinit-2.86) the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI interrupt for device :01:05.0 disabled
ACPI: PCI interrupt for device :01:04.0 disabled
ACPI: PCI interrupt for device :01:03.0 disabled
ACPI: PCI interrupt
John Sigler wrote:
I have an x86 system with two PCI slots, in which I inserted two
specialized output cards (Dektec DTA-105).
http://www.dektec.com/Products/DTA-105/
(They provide an open source driver.)
My problem is: when I write to the 4 ports (each card has 2 ports) "at
the same
Hello,
When I run 'halt' or 'poweroff' (sysvinit-2.86) the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI interrupt for device :01:05.0 disabled
ACPI: PCI interrupt for device :01:04.0 disabled
ACPI: PCI interrupt for device :01:03.0 disabled
ACPI: PCI interrupt for device
Hello,
When I run 'halt' or 'poweroff' (sysvinit-2.86) the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI interrupt for device :01:05.0 disabled
ACPI: PCI interrupt for device :01:04.0 disabled
ACPI: PCI interrupt for device :01:03.0 disabled
ACPI: PCI interrupt for device
John Sigler wrote:
I have an x86 system with two PCI slots, in which I inserted two
specialized output cards (Dektec DTA-105).
http://www.dektec.com/Products/DTA-105/
(They provide an open source driver.)
My problem is: when I write to the 4 ports (each card has 2 ports) at
the same time
John Sigler wrote:
When I run 'halt' or 'poweroff' (sysvinit-2.86) the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI interrupt for device :01:05.0 disabled
ACPI: PCI interrupt for device :01:04.0 disabled
ACPI: PCI interrupt for device :01:03.0 disabled
ACPI: PCI interrupt
Hello everyone,
I have an x86 system with two PCI slots, in which I inserted two
specialized output cards (Dektec DTA-105).
http://www.dektec.com/Products/DTA-105/
(They provide an open source driver.)
My problem is: when I write to the 4 ports (each card has 2 ports) "at
the same time" (not
Hello everyone,
I have an x86 system with two PCI slots, in which I inserted two
specialized output cards (Dektec DTA-105).
http://www.dektec.com/Products/DTA-105/
(They provide an open source driver.)
My problem is: when I write to the 4 ports (each card has 2 ports) at
the same time (not
Steven Rostedt wrote:
--
(Strange characters.)
John Sigler wrote:
APIC timer registered as dummy, due to nmi_watchdog=1!
Clockevents: could not switch to one-shot mode: lapic is not functional.
Could not switch to high resolution mode on CPU 0
Do you know why nmi_watchdog=1 disables high
Hello Martin,
Martin Mares wrote:
I ran lspci -vvv on a system:
http://linux.kernel.free.fr/halt/lspci.txt
(I used lspci version 2.2.5 in case it matters.)
But I'm having a hard time making sense of the output.
1. How many PCI buses are there in the system?
Two, just see the bus numbers
Alexey Starikovskiy wrote:
John Sigler wrote:
Alexey Starikovskiy wrote:
John Sigler wrote:
+===+
| Soft-Off by PWR-BTTN |
|---|
| Instant-Off . [v
Hello everyone,
I ran lspci -vvv on a system:
http://linux.kernel.free.fr/halt/lspci.txt
(I used lspci version 2.2.5 in case it matters.)
But I'm having a hard time making sense of the output.
1. How many PCI buses are there in the system?
2. Do any of the PCI buses support 66 MHz operation?
Alexey Starikovskiy wrote:
John Sigler wrote:
+===+
| Soft-Off by PWR-BTTN |
|---|
| Instant-Off . [v]|
| Delay 4 Sec
Alexey Starikovskiy wrote:
John Sigler wrote:
+===+
| Soft-Off by PWR-BTTN |
|---|
| Instant-Off . [v]|
| Delay 4 Sec
Hello everyone,
I ran lspci -vvv on a system:
http://linux.kernel.free.fr/halt/lspci.txt
(I used lspci version 2.2.5 in case it matters.)
But I'm having a hard time making sense of the output.
1. How many PCI buses are there in the system?
2. Do any of the PCI buses support 66 MHz operation?
Alexey Starikovskiy wrote:
John Sigler wrote:
Alexey Starikovskiy wrote:
John Sigler wrote:
+===+
| Soft-Off by PWR-BTTN |
|---|
| Instant-Off . [v
Hello Martin,
Martin Mares wrote:
I ran lspci -vvv on a system:
http://linux.kernel.free.fr/halt/lspci.txt
(I used lspci version 2.2.5 in case it matters.)
But I'm having a hard time making sense of the output.
1. How many PCI buses are there in the system?
Two, just see the bus numbers
Steven Rostedt wrote:
--
(Strange characters.)
John Sigler wrote:
APIC timer registered as dummy, due to nmi_watchdog=1!
Clockevents: could not switch to one-shot mode: lapic is not functional.
Could not switch to high resolution mode on CPU 0
Do you know why nmi_watchdog=1 disables high
Dick Johnson wrote:
John Sigler wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9148
Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to
hang my system in acpi_os_write_port(). What can I do about that?
Another observation: if I connect a screen to the system's VGA port
John Sigler wrote:
Alexey Starikovskiy wrote:
Could you please open bug at bugzilla.kernel.org and put all these
files there?
http://bugzilla.kernel.org/show_bug.cgi?id=9148
Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to
hang my system in acpi_os_write_port(). What
John Sigler wrote:
Alexey Starikovskiy wrote:
Could you please open bug at bugzilla.kernel.org and put all these
files there?
http://bugzilla.kernel.org/show_bug.cgi?id=9148
Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to
hang my system in acpi_os_write_port(). What
Dick Johnson wrote:
John Sigler wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9148
Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to
hang my system in acpi_os_write_port(). What can I do about that?
Another observation: if I connect a screen to the system's VGA port
Arjan van de Ven wrote:
John Sigler wrote:
I'm experiencing a full system lockup. I'm using an out-of-tree
driver which I suspect is responsible. I'm trying to enable the NMI
watchdog.
one thing worth a shot is enabling lockdep.. that often finds deadlocks
for you ;)
I enabled every
Alexey Starikovskiy wrote:
John Sigler wrote:
Alexey Starikovskiy wrote:
Could you please open bug at bugzilla.kernel.org and put all
these files there?
http://bugzilla.kernel.org/show_bug.cgi?id=9148
Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears
to hang my system
John Sigler wrote:
Alexey Starikovskiy wrote:
Could you please open bug at bugzilla.kernel.org and put all these
files there?
http://bugzilla.kernel.org/show_bug.cgi?id=9148
Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to
hang my system in acpi_os_write_port(). What
John Sigler wrote:
Alexey Starikovskiy wrote:
Could you please open bug at bugzilla.kernel.org and put all these
files there?
http://bugzilla.kernel.org/show_bug.cgi?id=9148
Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to
hang my system in acpi_os_write_port(). What
Alexey Starikovskiy wrote:
John Sigler wrote:
Alexey Starikovskiy wrote:
Could you please open bug at bugzilla.kernel.org and put all
these files there?
http://bugzilla.kernel.org/show_bug.cgi?id=9148
Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears
to hang my system
Arjan van de Ven wrote:
John Sigler wrote:
I'm experiencing a full system lockup. I'm using an out-of-tree
driver which I suspect is responsible. I'm trying to enable the NMI
watchdog.
one thing worth a shot is enabling lockdep.. that often finds deadlocks
for you ;)
I enabled every
Steven Rostedt wrote:
John Sigler wrote:
I'm experiencing a full system lockup. I'm using an out-of-tree driver
which I suspect is responsible. I'm trying to enable the NMI watchdog.
# cat /proc/version
Linux version 2.6.22.1-rt9 (gcc version 3.4.6) #1 PREEMPT RT Tue Oct 9
12:25:47 CEST 2007
Alexey Starikovskiy wrote:
Could you please open bug at bugzilla.kernel.org and put all these
files there?
http://bugzilla.kernel.org/show_bug.cgi?id=9148
(In my browser, halt output is incorrectly displayed in UTF-8.)
Regards.
-
To unsubscribe from this list: send the line "unsubscribe
Björn Steinbrink wrote:
John Sigler wrote:
I'm experiencing a full system lockup. I'm using an out-of-tree driver
which I suspect is responsible. I'm trying to enable the NMI watchdog.
# cat /proc/version
Linux version 2.6.22.1-rt9 (gcc version 3.4.6) #1 PREEMPT RT Tue Oct 9
12:25:47 CEST
John Sigler wrote:
When I run 'halt' the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI interrupt for device :01:05.0 disabled
ACPI: PCI interrupt for device :01:04.0 disabled
ACPI: PCI interrupt for device :01:03.0 disabled
ACPI: PCI interrupt for device :01:02.0 disabled
Hello,
I'm experiencing a full system lockup. I'm using an out-of-tree driver
which I suspect is responsible. I'm trying to enable the NMI watchdog.
# cat /proc/version
Linux version 2.6.22.1-rt9 (gcc version 3.4.6) #1 PREEMPT RT Tue Oct 9
12:25:47 CEST 2007
# cat /proc/cmdline
ro
Hello,
I'm experiencing a full system lockup. I'm using an out-of-tree driver
which I suspect is responsible. I'm trying to enable the NMI watchdog.
# cat /proc/version
Linux version 2.6.22.1-rt9 (gcc version 3.4.6) #1 PREEMPT RT Tue Oct 9
12:25:47 CEST 2007
# cat /proc/cmdline
ro
Steven Rostedt wrote:
John Sigler wrote:
I'm experiencing a full system lockup. I'm using an out-of-tree driver
which I suspect is responsible. I'm trying to enable the NMI watchdog.
# cat /proc/version
Linux version 2.6.22.1-rt9 (gcc version 3.4.6) #1 PREEMPT RT Tue Oct 9
12:25:47 CEST 2007
Alexey Starikovskiy wrote:
Could you please open bug at bugzilla.kernel.org and put all these
files there?
http://bugzilla.kernel.org/show_bug.cgi?id=9148
(In my browser, halt output is incorrectly displayed in UTF-8.)
Regards.
-
To unsubscribe from this list: send the line unsubscribe
Björn Steinbrink wrote:
John Sigler wrote:
I'm experiencing a full system lockup. I'm using an out-of-tree driver
which I suspect is responsible. I'm trying to enable the NMI watchdog.
# cat /proc/version
Linux version 2.6.22.1-rt9 (gcc version 3.4.6) #1 PREEMPT RT Tue Oct 9
12:25:47 CEST
John Sigler wrote:
When I run 'halt' the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI interrupt for device :01:05.0 disabled
ACPI: PCI interrupt for device :01:04.0 disabled
ACPI: PCI interrupt for device :01:03.0 disabled
ACPI: PCI interrupt for device :01:02.0 disabled
Hello Remy,
Remy Bohmer wrote:
John Sigler wrote:
When I run 'halt' the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI interrupt for device :01:05.0 disabled
ACPI: PCI interrupt for device :01:04.0 disabled
ACPI: PCI interrupt for device :01:03.0 disabled
ACPI: PCI interrupt
(The original message seems to have been ignored by the mailing list
robot, probably because the attachments made it too large. Re-send with
links instead of attaching the documents to the message.)
John Sigler wrote:
When I run 'halt' the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI
(The original message seems to have been ignored by the mailing list
robot, probably because the attachments made it too large. Re-send with
links instead of attaching the documents to the message.)
John Sigler wrote:
When I run 'halt' the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI
Hello Remy,
Remy Bohmer wrote:
John Sigler wrote:
When I run 'halt' the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI interrupt for device :01:05.0 disabled
ACPI: PCI interrupt for device :01:04.0 disabled
ACPI: PCI interrupt for device :01:03.0 disabled
ACPI: PCI interrupt
John Sigler wrote:
When I run 'halt' the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI interrupt for device :01:05.0 disabled
ACPI: PCI interrupt for device :01:04.0 disabled
ACPI: PCI interrupt for device :01:03.0 disabled
ACPI: PCI interrupt for device :01:02.0 disabled
John Sigler wrote:
When I run 'halt' the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI interrupt for device :01:05.0 disabled
ACPI: PCI interrupt for device :01:04.0 disabled
ACPI: PCI interrupt for device :01:03.0 disabled
ACPI: PCI interrupt for device :01:02.0 disabled
Sergei Shtylyov wrote:
John Sigler wrote:
When my system boots, I get several set_drive_speed_status errors.
(Please see attached dmesg output.)
Can someone explain what they mean? How do I get rid of them?
IDE code attempts to autotune PIO mode and fails at that because your
device
[ Re-sending... Please feel free to comment, even if you don't have
"The Solution". I'd just like to get some feedback. ]
Hello everyone,
I'm using 2.6.20.7-rt8 on a P3.
I've noticed that the frequency offset of my system clock (computed
either by ntpd, or by hand) changes drastically across
[ Re-sending... Please feel free to comment, even if you don't have
The Solution. I'd just like to get some feedback. ]
Hello everyone,
I'm using 2.6.20.7-rt8 on a P3.
I've noticed that the frequency offset of my system clock (computed
either by ntpd, or by hand) changes drastically across
Eric wrote:
John Sigler wrote:
According to my supplier, herre is the data sheet for the DOMs:
http://www.pqimemory.com/documents/domdata.pdf
PIO mode 2 is mentioned. Even DMA seems to be supported.
Or am I mistaken?
Page 3 states max interface burst speed is 8.3MB/s in PIO2. I
wouldn't
Alan Cox wrote:
John Sigler wrote:
http://www.pqimemory.com/documents/domdata.pdf
PIO mode 2 is mentioned. Even DMA seems to be supported.
Or am I mistaken?
Could there be a bug in my south bridge?
Nothing there about DMA support.
cf. document's page 12.
DMACK- (DMA acknowledge
Alan Cox wrote:
John Sigler wrote:
http://www.pqimemory.com/documents/domdata.pdf
PIO mode 2 is mentioned. Even DMA seems to be supported.
Or am I mistaken?
Could there be a bug in my south bridge?
Nothing there about DMA support.
cf. document's page 12.
DMACK- (DMA acknowledge
Eric wrote:
John Sigler wrote:
According to my supplier, herre is the data sheet for the DOMs:
http://www.pqimemory.com/documents/domdata.pdf
PIO mode 2 is mentioned. Even DMA seems to be supported.
Or am I mistaken?
Page 3 states max interface burst speed is 8.3MB/s in PIO2. I
wouldn't
John Sigler wrote:
Petr Vandrovec wrote:
John Sigler wrote:
Alan Cox wrote:
Basically your dinosaur is working correctly.
What do the warnings mean? :-)
That your drive does not support set transfer mode/speed command at
all, or that value which kernel tried is not supported
Petr Vandrovec wrote:
John Sigler wrote:
Alan Cox wrote:
Basically your dinosaur is working correctly.
What do the warnings mean? :-)
That your drive does not support set transfer mode/speed command at all,
or that value which kernel tried is not supported by the drive...
I would
Alan Cox wrote:
John Sigler wrote:
Standards:
Likely used: 1
Prehistory
The tragic bit is that we were sold similar DOMs in 2007...
(It's probably time to change suppliers?)
LBA, IORDY not likely
No DMA, nothing above PIO2
OK. (Grumble)
Buffer type: 0002
Alan Cox wrote:
John Sigler wrote:
Standards:
Likely used: 1
Prehistory
The tragic bit is that we were sold similar DOMs in 2007...
(It's probably time to change suppliers?)
LBA, IORDY not likely
No DMA, nothing above PIO2
OK. (Grumble)
Buffer type: 0002
Petr Vandrovec wrote:
John Sigler wrote:
Alan Cox wrote:
Basically your dinosaur is working correctly.
What do the warnings mean? :-)
That your drive does not support set transfer mode/speed command at all,
or that value which kernel tried is not supported by the drive...
I would
John Sigler wrote:
Petr Vandrovec wrote:
John Sigler wrote:
Alan Cox wrote:
Basically your dinosaur is working correctly.
What do the warnings mean? :-)
That your drive does not support set transfer mode/speed command at
all, or that value which kernel tried is not supported
Hello,
When my system boots, I get several set_drive_speed_status errors.
(Please see attached dmesg output.)
Can someone explain what they mean? How do I get rid of them?
Is there something I need to set in the config? or something I should
not have set?
Bonus question: is there some way
Hello,
When my system boots, I get several set_drive_speed_status errors.
(Please see attached dmesg output.)
Can someone explain what they mean? How do I get rid of them?
Is there something I need to set in the config? or something I should
not have set?
Bonus question: is there some way
Daniel Walker wrote:
John Sigler wrote:
Why does pdflush kick in to ruin my party? :-)
The expected latency is ~600 µs.
http://linux.kernel.free.fr/latency/pdflush.trace
Does ide_inb mean I'm reading from the disk?
Does your real time application lock its memory, or allow itself
Hello,
I've been using the latency tracing tool in -rt.
Linux version 2.6.22.1-rt9 (gcc version 3.4.4) #1 PREEMPT RT
prctl(0, 1); /* start tracing */
TsOut.Write(buf, packet_size);
prctl(0, 0); /* stop tracing */
Write() calls the driver through an ioctl, which schedules a DMA to
Hello,
I've been using the latency tracing tool in -rt.
Linux version 2.6.22.1-rt9 (gcc version 3.4.4) #1 PREEMPT RT
prctl(0, 1); /* start tracing */
TsOut.Write(buf, packet_size);
prctl(0, 0); /* stop tracing */
Write() calls the driver through an ioctl, which schedules a DMA to
Daniel Walker wrote:
John Sigler wrote:
Why does pdflush kick in to ruin my party? :-)
The expected latency is ~600 µs.
http://linux.kernel.free.fr/latency/pdflush.trace
Does ide_inb mean I'm reading from the disk?
Does your real time application lock its memory, or allow itself
Paul E. McKenney wrote:
John Sigler wrote:
I wrote a Linux app where I need high-resolution timers. I went all the
way and installed the -rt patch, which includes the -hrt patches, as far
as I understand.
Since I could not afford to change kernels with every new release, I
decided
Daniel Walker wrote:
John Sigler wrote:
Would anyone care to comment?
I'm not sure if this is the answer that you're looking for, but yes you
certainly will find fixed bug is older version of the tree.
I am not a kernel hacker, therefore I can only imagine how complex it is
to bring real
Daniel Walker wrote:
John Sigler wrote:
Would anyone care to comment?
I'm not sure if this is the answer that you're looking for, but yes you
certainly will find fixed bug is older version of the tree.
I am not a kernel hacker, therefore I can only imagine how complex it is
to bring real
Paul E. McKenney wrote:
John Sigler wrote:
I wrote a Linux app where I need high-resolution timers. I went all the
way and installed the -rt patch, which includes the -hrt patches, as far
as I understand.
Since I could not afford to change kernels with every new release, I
decided
John Sigler wrote:
I wrote a Linux app where I need high-resolution timers. I went all the
way and installed the -rt patch, which includes the -hrt patches, as far
as I understand.
Since I could not afford to change kernels with every new release, I
decided to track the 2.6.20 branch
John Sigler wrote:
The -rt patch includes the following update:
Index: linux/arch/i386/oprofile/Kconfig
===
--- linux.orig/arch/i386/oprofile/Kconfig
+++ linux/arch/i386/oprofile/Kconfig
@@ -15,3 +15,6 @@ config OPROFILE
John Sigler wrote:
The -rt patch includes the following update:
Index: linux/arch/i386/oprofile/Kconfig
===
--- linux.orig/arch/i386/oprofile/Kconfig
+++ linux/arch/i386/oprofile/Kconfig
@@ -15,3 +15,6 @@ config OPROFILE
John Sigler wrote:
I wrote a Linux app where I need high-resolution timers. I went all the
way and installed the -rt patch, which includes the -hrt patches, as far
as I understand.
Since I could not afford to change kernels with every new release, I
decided to track the 2.6.20 branch
[ Expanding recipients list to include NTP mailing list ]
John Sigler wrote:
I'm using 2.6.20.7-rt8 on a P3.
(But some ntpd users have reported the problem with mainline kernels and
different versions.)
I've noticed that the frequency offset of my system clock (computed
either by ntpd
[ Expanding recipients list to include NTP mailing list ]
John Sigler wrote:
I'm using 2.6.20.7-rt8 on a P3.
(But some ntpd users have reported the problem with mainline kernels and
different versions.)
I've noticed that the frequency offset of my system clock (computed
either by ntpd
Hello,
The -rt patch includes the following update:
Index: linux/arch/i386/oprofile/Kconfig
===
--- linux.orig/arch/i386/oprofile/Kconfig
+++ linux/arch/i386/oprofile/Kconfig
@@ -15,3 +15,6 @@ config OPROFILE
If unsure,
Hello,
I'm trying to build a 2.6.22.1-rt9 kernel for a P3.
I used 'make xconfig' to create .config
http://linux.kernel.free.fr/latency/config-2.6.22.1-rt9-adlink
I get the following warning:
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
MODPOST vmlinux
WARNING:
Hello,
I'm trying to build a 2.6.22.1-rt9 kernel for a P3.
I used 'make xconfig' to create .config
http://linux.kernel.free.fr/latency/config-2.6.22.1-rt9-adlink
I get the following warning:
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
MODPOST vmlinux
WARNING:
Hello,
The -rt patch includes the following update:
Index: linux/arch/i386/oprofile/Kconfig
===
--- linux.orig/arch/i386/oprofile/Kconfig
+++ linux/arch/i386/oprofile/Kconfig
@@ -15,3 +15,6 @@ config OPROFILE
If unsure,
Hello,
I wrote a Linux app where I need high-resolution timers. I went all the
way and installed the -rt patch, which includes the -hrt patches, as far
as I understand.
Since I could not afford to change kernels with every new release, I
decided to track the 2.6.20 branch (arbitrarily).
Hello,
I wrote a Linux app where I need high-resolution timers. I went all the
way and installed the -rt patch, which includes the -hrt patches, as far
as I understand.
Since I could not afford to change kernels with every new release, I
decided to track the 2.6.20 branch (arbitrarily).
Maciej W. Rozycki wrote:
John Sigler wrote:
As far as I understand, the Local APIC was integrated directly to the CPU
12-15 years ago. Why would a BIOS implementor choose to disable it?
Because they are lazy/incapable/out-of-time/select-your-favourite-excuse.
For the chip to work you have
I have several systems here where Linux tells me:
Local APIC disabled by BIOS -- you can enable it with "lapic"
As far as I understand, the Local APIC was integrated directly to the
CPU 12-15 years ago. Why would a BIOS implementor choose to disable it?
(And what does it mean to "disable" the
I have several systems here where Linux tells me:
Local APIC disabled by BIOS -- you can enable it with lapic
As far as I understand, the Local APIC was integrated directly to the
CPU 12-15 years ago. Why would a BIOS implementor choose to disable it?
(And what does it mean to disable the
Maciej W. Rozycki wrote:
John Sigler wrote:
As far as I understand, the Local APIC was integrated directly to the CPU
12-15 years ago. Why would a BIOS implementor choose to disable it?
Because they are lazy/incapable/out-of-time/select-your-favourite-excuse.
For the chip to work you have
[ Expanding recipients list ]
John Sigler wrote:
I'm using 2.6.20.7-rt8 on a P3.
But some ntpd users have reported the problem with mainline kernels and
different versions.
I've noticed that the frequency offset of my system clock (computed
either by ntpd, or by hand) changes drastically
[ Expanding recipients list ]
John Sigler wrote:
I'm using 2.6.20.7-rt8 on a P3.
But some ntpd users have reported the problem with mainline kernels and
different versions.
I've noticed that the frequency offset of my system clock (computed
either by ntpd, or by hand) changes drastically
Hello everyone,
I'm using 2.6.20.7-rt8 on a P3.
I've noticed that the frequency offset of my system clock (computed
either by ntpd, or by hand) changes drastically across reboots.
By drastically, I mean +/- 60 ppm every time I reboot.
Apparently this is caused by some imprecision in the
Hello everyone,
I'm using 2.6.20.7-rt8 on a P3.
I've noticed that the frequency offset of my system clock (computed
either by ntpd, or by hand) changes drastically across reboots.
By drastically, I mean +/- 60 ppm every time I reboot.
Apparently this is caused by some imprecision in the
[ Adding linux-net to the mix ]
John Sigler wrote:
( check_dektec_in-1095 |#0): new 271 us user-latency.
( check_dektec_in-1095 |#0): new 275 us user-latency.
( check_dektec_in-1095 |#0): new 290 us user-latency.
( check_dektec_in-1095 |#0): new 297 us user-latency.
( check_dektec_in-1095 |#0
1 - 100 of 169 matches
Mail list logo
