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
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.
/proc/sys/net/ipv4/conf/all/arp_a
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
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
ACP
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 :01:0
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 r
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 of
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
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
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
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 ;)
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 in
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
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:
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 linu
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
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.
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 root=/dev
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 int
(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
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.
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
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&#
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)
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 by the
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:
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 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
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 co
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 to
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
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
[ 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
eith
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, s
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: kernel/buil
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).
At
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
[ 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 d
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 freq
[ 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
John Sigler wrote:
Len Brown wrote:
John Sigler wrote:
# cat /proc/interrupts
CPU0
0: 37XT-PIC-XTtimer
1: 2XT-PIC-XTi8042
2: 0XT-PIC-XTcascade
7: 0XT-PIC-XTacpi
10:175XT
John Sigler wrote:
Len Brown wrote:
John Sigler wrote:
# cat /proc/interrupts
CPU0
0: 37XT-PIC-XTtimer
1: 2XT-PIC-XTi8042
2: 0XT-PIC-XTcascade
7: 0XT-PIC-XTacpi
10:175XT
Len Brown wrote:
John Sigler wrote:
# cat /proc/interrupts
CPU0
0: 37XT-PIC-XTtimer
1: 2XT-PIC-XTi8042
2: 0XT-PIC-XTcascade
7: 0XT-PIC-XTacpi
10:175XT-PIC-XTeth2
Karsten Wiese wrote:
John Sigler wrote:
Is there some form of priority inheritance? Does the IRQ handler get a
priority boost if a high priority task is waiting for it?
No. But that would be "nice to have".
No to the first question? to the second question? or to both? :-)
Ingo Molnar wrote:
John Sigler wrote:
Ingo Molnar wrote:
does your test-app have higher priority than softirq--4 ?
PID 4 is [softirq-timer/0] and has priority 50 in SCHED_FIFO. My
process has priority 80 in SCHED_RR. It is waiting for IRQ10.
My user-space app has higher priority than
(Dropping [EMAIL PROTECTED])
Ingo Molnar wrote:
John Sigler wrote:
With a pair of the following in the middle:
softirq--4 0 670us : call_rcu (rt_run_flush)
softirq--4 0D..1 670us : __rcu_advance_callbacks (call_rcu)
Any idea what went wrong in the above function trace? Why
John Sigler wrote:
Ingo Molnar wrote:
add 'notrace' to the definition of read_tsc in arch/i386/kernel/tsc.c
( 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
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): new 345 us user-latency
Ingo Molnar wrote:
add 'notrace' to the definition of read_tsc in arch/i386/kernel/tsc.c
( 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 use
Ingo Molnar wrote:
add 'notrace' to the definition of read_tsc in arch/i386/kernel/tsc.c
OK.
(or do echo 1 > /proc/sys/kernel/trace_use_raw_cycles
if you are using recent enough -rt)
Is patch-2.6.20-rt8 recent enough?
# ./trace-it 1 >trace
# cat trace
preemption latency trace v1.1.5 on 2.
Ingo Molnar wrote:
John Sigler wrote:
Here's a /proc/latency_trace dump. What is there to understand?
# cat /proc/latency_trace
preemption latency trace v1.1.5 on 2.6.20.7-rt8
latency: 26 us, #2/2, CPU#0 | (M:rt VP:0,
Hello everyone,
I have been experimenting with the CONFIG_PREEMPT_RT patch for a few
months. Specifically kernel 2.6.20.7-rt8.
http://rt.wiki.kernel.org/index.php/Main_Page
I've been running into some unexpected problems, so I wanted to ask
those who have some experience with this patch what
John Sigler wrote:
Hello everyone,
Here's my situation:
I'm pushing data in chunks of 1316 bytes to a PCI device at 38 Mbit/s.
In other words, I write 1316 bytes to the device every 277 microseconds.
I've noticed that the latency of this operation varies immensely. Most
Arjan van de Ven wrote:
On Tue, 2007-06-19 at 13:59 +0200, John Sigler wrote:
As far as I understand (which is not very far), if I define
CONFIG_MODVERSIONS,
just don't enable modversions.. it doesn't provide you any real safety
at all. and it makes your build a LOT slo
Hello everyone,
As far as I understand (which is not very far), if I define
CONFIG_MODVERSIONS, then checksums for various functions (all exported
functions?) and various structures (which ones?) will be included inside
the kernel image, and written to Module.symvers. When an out-of-tree
module i
Hello everyone,
Here's my situation:
I'm pushing data in chunks of 1316 bytes to a PCI device at 38 Mbit/s.
In other words, I write 1316 bytes to the device every 277 microseconds.
I've noticed that the latency of this operation varies immensely. Most
of the time it completes in 50-80 microsec
Chris Friesen wrote:
Helge Hafting wrote:
My guess:
Something needs memory but finds there is none to be had
oom-killer is invoked and targets myapp.
myapp takes some time to die. Particularly, the memory it uses
isn't freed up instantly.
Has anyone considered actually bumping up the priorit
Helge Hafting wrote:
John Sigler wrote:
Andrea Arcangeli wrote:
On Wed, Jun 13, 2007 at 10:49:29AM +0200, John Sigler wrote:
Question 2: how can I tell which process or kernel thread was
hogging most of the RAM when the oom-killer kicked in?
Theoretically the one that was killed first
Andrea Arcangeli wrote:
On Wed, Jun 13, 2007 at 10:49:29AM +0200, John Sigler wrote:
Question 2: how can I tell which process or kernel thread was hogging
most of the RAM when the oom-killer kicked in?
Theoretically the one that was killed first but not for sure in
current mainline hence
Hello,
I have a problem with an app I wrote: after it has run for a long time
(sometimes 10-15 hours, sometimes several days) the oom-killer kicks in
and snipes most processes in the system.
(My process runs in SCHED_RR.)
There is a good probability that there is a memory leak in my app, but
Hello,
I work for a small company involved in broadcast.
For the past year, we've been looking for a PCI board that meets
at least the following requirements:
1. Serial Digital Interface input
http://en.wikipedia.org/wiki/Serial_Digital_Interface
2. On-board (hardware) MPEG-2 encoder (our app
Jan Engelhardt wrote:
On May 22 2007 10:13, John Sigler wrote:
How do I list the checksums within a module?
Is there a simpler way to list all the checksums?
22:25 ichi:~ > modinfo aes
srcversion: 8CB82B3A254D5A950FD0D14
I think this one checksum is computed out of all functions that
Sam Ravnborg wrote:
On Fri, May 18, 2007 at 10:27:06PM +0200, Jan Engelhardt wrote:
On May 18 2007 17:02, John Sigler wrote:
I'm getting "disagrees about version of symbol struct_module" messages,
and I'm trying to understand why.
As far as I understand (which is not ve
Jan Engelhardt wrote:
On May 18 2007 17:02, John Sigler wrote:
I'm getting "disagrees about version of symbol struct_module" messages,
and I'm trying to understand why.
As far as I understand (which is not very far), if I define
CONFIG_MODVERSIONS, then checksums for va
Hello everyone,
I'm getting "disagrees about version of symbol struct_module" messages,
and I'm trying to understand why.
As far as I understand (which is not very far), if I define
CONFIG_MODVERSIONS, then checksums for various functions (all exported
functions?) and various structures (whi
Preston A. Elder wrote:
What is this edac, btw?
AFAIK, EDAC stands for Error Detection and Correction.
http://bluesmoke.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.k
Thomas Gleixner wrote:
On Fri, 2007-04-20 at 15:15 +0200, John Sigler wrote:
I've tweaked patch-2.6.20-rt8(*) so that it applies to 2.6.20.7
(*) http://rt.wiki.kernel.org/index.php/Main_Page
The original patch can be found here:
http://people.redhat.com/mingo/realtime-preempt/older/
Hello,
I've tweaked patch-2.6.20-rt8(*) so that it applies to 2.6.20.7
(*) http://rt.wiki.kernel.org/index.php/Main_Page
The original patch can be found here:
http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.20-rt8
http://linux.kernel.free.fr/patch-2.6.20-rt8
diff to the original
Andrew Shewmaker wrote:
John Sigler wrote:
Andi Kleen wrote:
There are usually chipset specific bits that can be set to disable
SMMs. See the datasheet if you can get them. Unfortunately most
chipset vendors don't give out data sheets easily.
I managed to find the south bridge data
Andi Kleen wrote:
There are usually chipset specific bits that can be set to disable
SMMs. See the datasheet if you can get them. Unfortunately most
chipset vendors don't give out data sheets easily.
I managed to find the south bridge data sheet.
http://linux.kernel.free.fr/VT82C686B.pdf
(I'
John Sigler wrote:
# : >/var/log/kern.log; cat /proc/interrupts; /bin/time insmod houba.ko;
cat /proc/interrupts; rmmod houba
CPU0
0: 519083XT-PIC-XTtimer
2: 0XT-PIC-XTcascade
9: 0XT-PIC-XTacpi
10: 9786XT-
Andi Kleen wrote:
Modern x86 CPUs execute code out of order and in parallel.
I am aware of the (apparent) non-deterministic nature of
superscalar out-of-order speculative execution.
The reordering window can be quite large and the CPU can execute code
speculatively. This can add large errors
John Sigler wrote:
static int hello_init(void)
{
int i;
int *lat;
printk(KERN_ALERT "INIT\n");
lat = kmalloc(MAX * sizeof *lat, GFP_KERNEL);
if (lat == NULL) return -1;
for (i=0; i < MAX; ++i) lat[i] = 0;
for (i=0; i < 5; ++i) foo();
for (i=0; i < N; ++i)
{
Andi Kleen wrote:
Please use a full real name for posting.
OK.
John Sigler wrote:
AFAIU, even a hard real-time OS is "defenseless" against SMIs that
kick the CPU into SMM.
There are usually chipset specific bits that can be set to disable SMMs.
See the datasheet if you ca
85 matches
Mail list logo
