* 2.6.14-rc5-rt3 - `IRQ 8'[798] is being piggy
@ 2005-10-21 17:03 Mark Knecht
2005-10-21 17:40 ` Mark Knecht
0 siblings, 1 reply; 8+ messages in thread
From: Mark Knecht @ 2005-10-21 17:03 UTC (permalink / raw)
To: linux-kernel; +Cc: Ingo Molnar
[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]
Hi,
Maybe I'm catching something here? Maybe not - no xruns as of yet,
but I've never seen these messages before. Kernel config attached.
dmesg has filled up with these messages:
Read missed before next interrupt
`IRQ 8'[798] is being piggy. need_resched=0, cpu=0
Read missed before next interrupt
`IRQ 8'[798] is being piggy. need_resched=0, cpu=0
Read missed before next interrupt
`IRQ 8'[798] is being piggy. need_resched=0, cpu=0
Read missed before next interrupt
wow! That was a 14 millisec bump
`IRQ 8'[798] is being piggy. need_resched=0, cpu=0
Read missed before next interrupt
wow! That was a 12 millisec bump
`IRQ 8'[798] is being piggy. need_resched=0, cpu=0
Read missed before next interrupt
wow! That was a 17 millisec bump
`IRQ 8'[798] is being piggy. need_resched=0, cpu=0
Read missed before next interrupt
wow! That was a 89 millisec bump
lightning ~ #
lightning ~ # cat /proc/interrupts
CPU0
0: 928484 IO-APIC-edge timer
1: 572 IO-APIC-edge i8042
7: 2 IO-APIC-edge lpptest
8: 529468 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 91942 IO-APIC-edge i8042
14: 48 IO-APIC-edge ide0
50: 2 IO-APIC-level ehci_hcd:usb1
58: 534656 IO-APIC-level hdsp
66: 2 IO-APIC-level ohci1394
217: 532660 IO-APIC-level ohci_hcd:usb2, eth0
225: 24239 IO-APIC-level libata, NVidia CK804
233: 9083 IO-APIC-level libata
NMI: 263
LOC: 928256
ERR: 1
MIS: 0
lightning ~ #
Cheers,
Mark
[-- Attachment #2: knecht.config-2.6.14-rc5-rt3.bz2 --]
[-- Type: application/x-bzip2, Size: 6492 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: 2.6.14-rc5-rt3 - `IRQ 8'[798] is being piggy 2005-10-21 17:03 2.6.14-rc5-rt3 - `IRQ 8'[798] is being piggy Mark Knecht @ 2005-10-21 17:40 ` Mark Knecht 2005-10-21 18:45 ` Lee Revell 0 siblings, 1 reply; 8+ messages in thread From: Mark Knecht @ 2005-10-21 17:40 UTC (permalink / raw) To: linux-kernel; +Cc: Ingo Molnar On 10/21/05, Mark Knecht <markknecht@gmail.com> wrote: > Hi, > Maybe I'm catching something here? Maybe not - no xruns as of yet, > but I've never seen these messages before. Kernel config attached. > > dmesg has filled up with these messages: > > Read missed before next interrupt > `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 > Read missed before next interrupt > `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 > Read missed before next interrupt > `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 > Read missed before next interrupt > wow! That was a 14 millisec bump > `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 > Read missed before next interrupt > wow! That was a 12 millisec bump > `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 > Read missed before next interrupt > wow! That was a 17 millisec bump > `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 > Read missed before next interrupt > wow! That was a 89 millisec bump > lightning ~ # > > lightning ~ # cat /proc/interrupts > CPU0 > 0: 928484 IO-APIC-edge timer > 1: 572 IO-APIC-edge i8042 > 7: 2 IO-APIC-edge lpptest > 8: 529468 IO-APIC-edge rtc > 9: 0 IO-APIC-level acpi > 12: 91942 IO-APIC-edge i8042 > 14: 48 IO-APIC-edge ide0 > 50: 2 IO-APIC-level ehci_hcd:usb1 > 58: 534656 IO-APIC-level hdsp > 66: 2 IO-APIC-level ohci1394 > 217: 532660 IO-APIC-level ohci_hcd:usb2, eth0 > 225: 24239 IO-APIC-level libata, NVidia CK804 > 233: 9083 IO-APIC-level libata > NMI: 263 > LOC: 928256 > ERR: 1 > MIS: 0 > lightning ~ # > > Cheers, > Mark OK, I am able to reproduce this reliably. This machine has two sound cards: IRQ58 - RME HDSP 9652 - running Jack IRQ225 - Internal NVidia running Alsa The NVidia is default for system sounds. The RME is for serious audio work. 1) I start the Jack server using the RME card: mark@lightning ~ $ /usr/bin/jackd -R -P80 -p512 -dalsa -dhw:1 -r44100 -p64 -n2 jackd 0.100.5 Copyright 2001-2005 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK compiled with System V SHM support. loading driver .. apparent rate = 44100 creating alsa driver ... hw:1|hw:1|64|2|44100|0|0|nomon|swmeter|-|32bit control device hw:1 configuring for 44100Hz, period = 64 frames, buffer = 2 periods nperiods = 2 for capture nperiods = 2 for playback 2) I start MythTV using the NVidia chip. (NOT Jack) No problem in dmesg occur until I start streaming a recorded TV program. As soon streaming as I start I get the messages. I stop more or less immediately and view dmesg. ( X-7686 |#0): new 22 us maximum-latency critical section. => started at timestamp 2496745046: <do_IRQ+0x29/0x50> => ended at timestamp 2496745068: <do_IRQ+0x39/0x50> Call Trace: <IRQ> <ffffffff8014dabc>{check_critical_timing+492} <ffffffff8014dd65>{sub_preempt_count_ti+117} <ffffffff801101e9>{do_IRQ+57} <ffffffff8010e1bc>{ret_from_intr+0} <EOI> --------------------------- | preempt count: 00000001 ] | 1-level deep critical section nesting: ---------------------------------------- .. [<ffffffff80157160>] .... __do_IRQ+0xe0/0x180 .....[<00000000>] .. ( <= _stext+0x7feff0e8/0xe8) => dump-end timestamp 2496745158 ( X-7686 |#0): new 22 us maximum-latency critical section. => started at timestamp 2498025339: <do_IRQ+0x29/0x50> => ended at timestamp 2498025362: <do_IRQ+0x39/0x50> Call Trace: <IRQ> <ffffffff8014dabc>{check_critical_timing+492} <ffffffff8014dd65>{sub_preempt_count_ti+117} <ffffffff801101e9>{do_IRQ+57} <ffffffff8010e1bc>{ret_from_intr+0} <EOI> --------------------------- | preempt count: 00000001 ] | 1-level deep critical section nesting: ---------------------------------------- .. [<ffffffff80157160>] .... __do_IRQ+0xe0/0x180 .....[<00000000>] .. ( <= _stext+0x7feff0e8/0xe8) => dump-end timestamp 2498025445 ( mythfrontend-8048 |#0): new 32 us maximum-latency critical section. => started at timestamp 2537338337: <rtc_open+0xf/0xc0> => ended at timestamp 2537338369: <rtc_open+0x6b/0xc0> Call Trace:<ffffffff8014dabc>{check_critical_timing+492} <ffffffff8014dd65>{sub_preempt_count_ti+117} <ffffffff802a228b>{rtc_open+107} <ffffffff80297039>{misc_open+473} <ffffffff80182999>{chrdev_open+457} <ffffffff80178757>{__dentry_open+295} <ffffffff80178937>{filp_open+135} <ffffffff8014dd65>{sub_preempt_count_ti+117} <ffffffff80178ac6>{get_unused_fd+230} <ffffffff80178c31>{do_sys_open+81} <ffffffff8010dc16>{system_call+126} --------------------------- | preempt count: 00000001 ] | 1-level deep critical section nesting: ---------------------------------------- .. [<ffffffff802a222f>] .... rtc_open+0xf/0xc0 .....[<00000000>] .. ( <= _stext+0x7feff0e8/0xe8) => dump-end timestamp 2537338467 `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt wow! That was a 9 millisec bump `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt wow! That was a 10 millisec bump `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt wow! That was a 8 millisec bump `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt wow! That was a 11 millisec bump `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt wow! That was a 2 millisec bump `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt wow! That was a 3 millisec bump `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt wow! That was a 9 millisec bump `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt wow! That was a 5 millisec bump `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt wow! That was a 3 millisec bump `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt wow! That was a 43 millisec bump `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt `IRQ 8'[798] is being piggy. need_resched=0, cpu=0 Read missed before next interrupt rtc latency histogram of {mythfrontend/8043, 15216 samples}: 3 13365 4 817 5 236 6 114 7 48 8 64 9 91 10 44 11 45 12 23 13 13 14 3 15 6 16 6 17 3 18 2 19 5 20 2 21 4 22 3 23 16 24 9 25 4 26 3 29 1 32 3 33 1 34 1 35 1 39 2 46 1 57 1 66 1 71 1 83 1 169 1 331 1 347 1 348 1 351 1 365 1 368 1 369 2 370 1 372 3 373 2 374 2 375 2 376 3 377 1 378 4 379 2 380 4 382 1 384 1 385 5 386 1 387 3 388 2 389 2 390 2 391 1 393 1 394 3 395 2 396 2 398 2 399 1 400 1 401 2 403 2 404 4 405 1 406 2 407 7 411 1 412 1 413 3 414 2 416 3 417 1 418 1 419 1 420 2 421 1 422 3 423 1 425 1 427 3 428 1 430 3 431 2 435 1 436 1 437 2 438 2 439 1 440 1 441 1 442 1 443 1 445 2 446 1 449 1 450 1 452 1 456 2 457 1 460 1 461 1 462 1 466 1 468 1 469 1 478 1 480 1 481 2 483 1 485 1 486 1 489 1 490 1 491 1 495 1 499 1 500 1 503 2 504 2 507 2 508 1 509 1 511 2 512 1 518 1 519 1 520 1 522 1 523 2 524 1 525 1 526 2 527 1 528 1 529 1 530 1 531 1 532 1 536 2 537 2 543 2 544 1 547 1 549 1 552 1 553 2 554 2 555 1 557 2 558 1 559 2 562 1 564 1 565 1 566 3 568 1 571 1 573 1 574 2 575 3 583 2 584 2 591 1 595 1 597 1 599 1 603 2 604 2 606 1 612 1 620 1 621 1 627 1 629 1 639 1 659 1 681 1 692 1 704 1 937 1 1026 1 1027 1 1210 2 1214 1 1227 1 1231 1 1236 1 1237 1 1243 1 1246 1 1253 2 1254 1 1272 1 1277 1 1284 1 1285 1 1290 1 1308 1 1310 1 1312 1 1323 1 1331 1 1339 1 1342 2 1349 1 1372 1 1611 1 1798 1 2739 1 3524 1 3668 1 5921 1 8438 1 9018 1 9131 1 9999 3 lightning ~ # Why does using MythTV apparently cause so much trouble for the rtc? Thanks, Mark ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.6.14-rc5-rt3 - `IRQ 8'[798] is being piggy 2005-10-21 17:40 ` Mark Knecht @ 2005-10-21 18:45 ` Lee Revell 2005-10-21 18:52 ` Mark Knecht 0 siblings, 1 reply; 8+ messages in thread From: Lee Revell @ 2005-10-21 18:45 UTC (permalink / raw) To: Mark Knecht; +Cc: linux-kernel, Ingo Molnar On Fri, 2005-10-21 at 10:40 -0700, Mark Knecht wrote: > On 10/21/05, Mark Knecht <markknecht@gmail.com> wrote: > > Hi, > > Maybe I'm catching something here? Maybe not - no xruns as of yet, > > but I've never seen these messages before. Kernel config attached. > > > > dmesg has filled up with these messages: > > This isn't a real problem. You enabled CONFIG_RTC_HISTOGRAM. Don't do that. Lee ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.6.14-rc5-rt3 - `IRQ 8'[798] is being piggy 2005-10-21 18:45 ` Lee Revell @ 2005-10-21 18:52 ` Mark Knecht 2005-10-21 19:44 ` Lee Revell 0 siblings, 1 reply; 8+ messages in thread From: Mark Knecht @ 2005-10-21 18:52 UTC (permalink / raw) To: Lee Revell; +Cc: linux-kernel, Ingo Molnar On 10/21/05, Lee Revell <rlrevell@joe-job.com> wrote: > On Fri, 2005-10-21 at 10:40 -0700, Mark Knecht wrote: > > On 10/21/05, Mark Knecht <markknecht@gmail.com> wrote: > > > Hi, > > > Maybe I'm catching something here? Maybe not - no xruns as of yet, > > > but I've never seen these messages before. Kernel config attached. > > > > > > dmesg has filled up with these messages: > > > > > This isn't a real problem. You enabled CONFIG_RTC_HISTOGRAM. Don't do > that. > > Lee Right, but the 'piggy' messages are a real prblem, aren't they? Thanks, Mark ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.6.14-rc5-rt3 - `IRQ 8'[798] is being piggy 2005-10-21 18:52 ` Mark Knecht @ 2005-10-21 19:44 ` Lee Revell 2005-10-21 22:25 ` Mark Knecht 0 siblings, 1 reply; 8+ messages in thread From: Lee Revell @ 2005-10-21 19:44 UTC (permalink / raw) To: Mark Knecht; +Cc: linux-kernel, Ingo Molnar On Fri, 2005-10-21 at 11:52 -0700, Mark Knecht wrote: > On 10/21/05, Lee Revell <rlrevell@joe-job.com> wrote: > > On Fri, 2005-10-21 at 10:40 -0700, Mark Knecht wrote: > > > On 10/21/05, Mark Knecht <markknecht@gmail.com> wrote: > > > > Hi, > > > > Maybe I'm catching something here? Maybe not - no xruns as of yet, > > > > but I've never seen these messages before. Kernel config attached. > > > > > > > > dmesg has filled up with these messages: > > > > > > > > This isn't a real problem. You enabled CONFIG_RTC_HISTOGRAM. Don't do > > that. > > > > Lee > > > Right, but the 'piggy' messages are a real prblem, aren't they? No I don't think so. CONFIG_RTC_HISTOGRAM is a hack, designed to work with a specific test program that runs SCHED_FIFO and poll()s on the RTC. VLC apparently poll()s on the RTC but does not run SCHED_FIFO. So of course there will be delays. Now that the kernel has good soft realtime support and non-root RT scheduling, these apps really need to adopt a correct soft RT design like JACK. AFAICT they don't even bother to try to get SCHED_FIFO for the time-sensitive rendering threads. I can't even get totem-xine (the default "Sound and Movie Player" for Gnome) to keep the audio and video in sync. mplayer only plays smoothly if I run it at nice -10. Etc. The Linux kernel is pretty good for RT these days but compared to OSX or even Windows the apps are a joke. Lee ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.6.14-rc5-rt3 - `IRQ 8'[798] is being piggy 2005-10-21 19:44 ` Lee Revell @ 2005-10-21 22:25 ` Mark Knecht 2005-10-21 23:28 ` Lee Revell 0 siblings, 1 reply; 8+ messages in thread From: Mark Knecht @ 2005-10-21 22:25 UTC (permalink / raw) To: Lee Revell; +Cc: linux-kernel, Ingo Molnar On 10/21/05, Lee Revell <rlrevell@joe-job.com> wrote: > On Fri, 2005-10-21 at 11:52 -0700, Mark Knecht wrote: > > On 10/21/05, Lee Revell <rlrevell@joe-job.com> wrote: > > > On Fri, 2005-10-21 at 10:40 -0700, Mark Knecht wrote: > > > > On 10/21/05, Mark Knecht <markknecht@gmail.com> wrote: > > > > > Hi, > > > > > Maybe I'm catching something here? Maybe not - no xruns as of yet, > > > > > but I've never seen these messages before. Kernel config attached. > > > > > > > > > > dmesg has filled up with these messages: > > > > > > > > > > > This isn't a real problem. You enabled CONFIG_RTC_HISTOGRAM. Don't do > > > that. > > > > > > Lee > > > > > > Right, but the 'piggy' messages are a real prblem, aren't they? > > No I don't think so. CONFIG_RTC_HISTOGRAM is a hack, designed to work > with a specific test program that runs SCHED_FIFO and poll()s on the > RTC. VLC apparently poll()s on the RTC but does not run SCHED_FIFO. So > of course there will be delays. > > Now that the kernel has good soft realtime support and non-root RT > scheduling, these apps really need to adopt a correct soft RT design > like JACK. AFAICT they don't even bother to try to get SCHED_FIFO for > the time-sensitive rendering threads. I can't even get totem-xine (the > default "Sound and Movie Player" for Gnome) to keep the audio and video > in sync. mplayer only plays smoothly if I run it at nice -10. Etc. > > The Linux kernel is pretty good for RT these days but compared to OSX or > even Windows the apps are a joke. > > Lee Lee, Indeed, you are correct. Apparently under character devices I had turned on the RTC histogram feature. With that off I am not only getting the maximum latency values we expect. Now I'll have to let it run for hours/days to see if I catch any info on these xruns, should I get another rash of them. Yesterday they came only after about 14 hours of work. I had none the previous two days. Thanks, Mark ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.6.14-rc5-rt3 - `IRQ 8'[798] is being piggy 2005-10-21 22:25 ` Mark Knecht @ 2005-10-21 23:28 ` Lee Revell 2005-10-22 3:44 ` Ingo Molnar 0 siblings, 1 reply; 8+ messages in thread From: Lee Revell @ 2005-10-21 23:28 UTC (permalink / raw) To: Mark Knecht; +Cc: linux-kernel, Ingo Molnar On Fri, 2005-10-21 at 15:25 -0700, Mark Knecht wrote: > > > > No I don't think so. CONFIG_RTC_HISTOGRAM is a hack, designed to work > > with a specific test program that runs SCHED_FIFO and poll()s on the > > RTC. VLC apparently poll()s on the RTC but does not run SCHED_FIFO. So > > of course there will be delays. > Lee, > Indeed, you are correct. Apparently under character devices I had > turned on the RTC histogram feature. With that off I am not only > getting the maximum latency values we expect. > > Now I'll have to let it run for hours/days to see if I catch any > info on these xruns, should I get another rash of them. Yesterday they > came only after about 14 hours of work. I had none the previous two > days. In general you should avoid enabling/disabling random config options between runs. If you keep changing the .config it makes it impossible to hunt bugs or compare one set of results to another. The easiest way is to do: zcat /proc/config.gz > .config make oldconfig Lee ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.6.14-rc5-rt3 - `IRQ 8'[798] is being piggy 2005-10-21 23:28 ` Lee Revell @ 2005-10-22 3:44 ` Ingo Molnar 0 siblings, 0 replies; 8+ messages in thread From: Ingo Molnar @ 2005-10-22 3:44 UTC (permalink / raw) To: Lee Revell; +Cc: Mark Knecht, linux-kernel * Lee Revell <rlrevell@joe-job.com> wrote: > On Fri, 2005-10-21 at 15:25 -0700, Mark Knecht wrote: > > > > > > No I don't think so. CONFIG_RTC_HISTOGRAM is a hack, designed to work > > > with a specific test program that runs SCHED_FIFO and poll()s on the > > > RTC. VLC apparently poll()s on the RTC but does not run SCHED_FIFO. So > > > of course there will be delays. > > > Lee, > > Indeed, you are correct. Apparently under character devices I had > > turned on the RTC histogram feature. With that off I am not only > > getting the maximum latency values we expect. > > > > Now I'll have to let it run for hours/days to see if I catch any > > info on these xruns, should I get another rash of them. Yesterday they > > came only after about 14 hours of work. I had none the previous two > > days. > > In general you should avoid enabling/disabling random config options > between runs. If you keep changing the .config it makes it impossible > to hunt bugs or compare one set of results to another. i think i'll remove the CONFIG_RTC_HISTOGRAM feature altogether from the -rt tree - meanwhile we've got more advanced (and less verbose) latency histogram features via WAKEUP_LATENCY_HIST, PREEMPT_OFF_HIST and INTERRUPT_OFF_HIST. Ingo ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-10-22 3:44 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-10-21 17:03 2.6.14-rc5-rt3 - `IRQ 8'[798] is being piggy Mark Knecht 2005-10-21 17:40 ` Mark Knecht 2005-10-21 18:45 ` Lee Revell 2005-10-21 18:52 ` Mark Knecht 2005-10-21 19:44 ` Lee Revell 2005-10-21 22:25 ` Mark Knecht 2005-10-21 23:28 ` Lee Revell 2005-10-22 3:44 ` Ingo Molnar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).