2.6.17-rc6-rt1

2.6.17-rc6-rt1

[Ingo Molnar]

i have released the 2.6.17-rc6-rt1 tree, which can be downloaded from 
the usual place:

   http://redhat.com/~mingo/realtime-preempt/

the biggest change was the port to 2.6.17-rc6, and the moving to John's 
latest and greatest GTOD queue. Most of the porting was done by Thomas 
Gleixner (thanks Thomas!). We also picked up the freshest genirq queue 
from -mm and the freshest PI-futex patchset. There are also lots of ARM 
fixups and enhancements from Deepak Saxena and Daniel Walker.

if we accidentally dropped some fix in the process then please complain. 
x86 and x86_64 build and boot, but some initial rough edges are to be 
expected. Deepak, your ARM-GTOD patches are included but not tested yet.

to build a 2.6.17-rc6-rt1 tree, the following patches should be applied:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17-rc6.bz2
  http://redhat.com/~mingo/realtime-preempt/patch-2.6.17-rc6-rt1

	Ingo

Re: 2.6.17-rc6-rt1

[Daniel Walker]

On Wed, 2006-06-07 at 23:14 +0200, Ingo Molnar wrote:
> i have released the 2.6.17-rc6-rt1 tree, which can be downloaded from 
> the usual place:
> 
>    http://redhat.com/~mingo/realtime-preempt/
> 
> the biggest change was the port to 2.6.17-rc6, and the moving to John's 
> latest and greatest GTOD queue. Most of the porting was done by Thomas 
> Gleixner (thanks Thomas!). We also picked up the freshest genirq queue 
> from -mm and the freshest PI-futex patchset. There are also lots of ARM 
> fixups and enhancements from Deepak Saxena and Daniel Walker.
> 

Does this release also include the lastest hrtimers code ?

Daniel

Re: 2.6.17-rc6-rt1

[Mark Knecht]

Hi Ingo,
   Since the Gentoo Pro-Audio overlay guys were so quick to get
2.6.17-rc6-rt1 into an ebuild I downloaded and built the kernel this
evening using that method.

1) The kernel did boot on my AMD64 machine.

2) gdm segfaulted so I couldn't run X.

3) Basic functionality was available in a console window.

   I expect the gdm problem is on my end. Maybe it's a VGA driver
issue or something like that? I'll check that out tomorrow.

   Anyway, it does boot so that's a start.

Cheers,
Mark

On 6/7/06, Ingo Molnar <mingo@elte.hu> wrote:
> i have released the 2.6.17-rc6-rt1 tree, which can be downloaded from
> the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/
>
> the biggest change was the port to 2.6.17-rc6, and the moving to John's
> latest and greatest GTOD queue. Most of the porting was done by Thomas
> Gleixner (thanks Thomas!). We also picked up the freshest genirq queue
> from -mm and the freshest PI-futex patchset. There are also lots of ARM
> fixups and enhancements from Deepak Saxena and Daniel Walker.
>
> if we accidentally dropped some fix in the process then please complain.
> x86 and x86_64 build and boot, but some initial rough edges are to be
> expected. Deepak, your ARM-GTOD patches are included but not tested yet.
>
> to build a 2.6.17-rc6-rt1 tree, the following patches should be applied:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.tar.bz2
>   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.17-rc6.bz2
>   http://redhat.com/~mingo/realtime-preempt/patch-2.6.17-rc6-rt1
>
>         Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: 2.6.17-rc6-rt1

[Mark Knecht]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On 6/7/06, Mark Knecht <markknecht@gmail.com> wrote:
> Hi Ingo,
>    Since the Gentoo Pro-Audio overlay guys were so quick to get
> 2.6.17-rc6-rt1 into an ebuild I downloaded and built the kernel this
> evening using that method.
>
> 1) The kernel did boot on my AMD64 machine.
>
> 2) gdm segfaulted so I couldn't run X.
>
> 3) Basic functionality was available in a console window.
>
>    I expect the gdm problem is on my end. Maybe it's a VGA driver
> issue or something like that? I'll check that out tomorrow.
>
>    Anyway, it does boot so that's a start.
>
> Cheers,
> Mark
>

Hi all,
   I am still unable to get gdm to run. It just segfaults on me so
far. I tried rebuilding gdm under this kernel but that didn't fix it.

   I'm attaching the dmesg file that I get under the new kernel, along
with the config file zipped up.

Cheers,
Mark

[-- Attachment #2: dmesg-crash.txt --]
[-- Type: text/plain, Size: 15749 bytes --]

(64 bytes/line)
CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 00
Using local APIC timer interrupts.
result 12564478
Detected 12.564 MHz APIC timer.
testing NMI watchdog ... OK.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - 0000:00:09.0
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK3] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LMAC] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LPCA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled.
ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.
ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.
ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled.
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI-DMA: Disabling IOMMU.
PCI: Bridge: 0000:00:09.0
  IO window: disabled.
  MEM window: da000000-da0fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0b.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0d.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0e.0
  IO window: a000-afff
  MEM window: d8000000-d9ffffff
  PREFETCH window: d0000000-d7ffffff
PCI: Setting latency timer of device 0000:00:09.0 to 64
PCI: Setting latency timer of device 0000:00:0b.0 to 64
PCI: Setting latency timer of device 0000:00:0c.0 to 64
PCI: Setting latency timer of device 0000:00:0d.0 to 64
PCI: Setting latency timer of device 0000:00:0e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
TCP established hash table entries: 65536 (order: 10, 4194304 bytes)
TCP bind hash table entries: 32768 (order: 8, 1835008 bytes)
TCP: Hash tables configured (established 65536 bind 32768)
TCP reno registered
IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
Total HugeTLB memory allocated, 0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
io scheduler noop registered
io scheduler deadline registered (default)
io scheduler cfq registered
PCI: Setting latency timer of device 0000:00:0b.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0b.0:pcie00]
PCI: Setting latency timer of device 0000:00:0c.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0c.0:pcie00]
PCI: Setting latency timer of device 0000:00:0d.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0d.0:pcie00]
PCI: Setting latency timer of device 0000:00:0e.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0e.0:pcie00]
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
Using specific hotkey driver
ACPI: Thermal Zone [THRM] (40 C)
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.101 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
isa bounce pool size: 16 pages
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.54.
ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23
GSI 16 sharing vector 0xD9 and IRQ 16
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 217
PCI: Setting latency timer of device 0000:00:0a.0 to 64
forcedeth: using HIGHDMA
eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0
NFORCE-CK804: chipset revision 242
NFORCE-CK804: not 100% native mode: will probe irqs later
NFORCE-CK804: 0000:00:06.0 (rev f2) UDMA133 controller
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: LITE-ON DVDRW LDW-411S, ATAPI CD/DVD-ROM drive
hdb: LITE-ON LTR-48246S, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Probing IDE interface ide1...
hda: ATAPI 40X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdb: ATAPI 48X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
libata version 1.20 loaded.
sata_nv 0000:00:07.0: version 0.8
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
GSI 17 sharing vector 0xE1 and IRQ 17
ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 22 (level, low) -> IRQ 225
PCI: Setting latency timer of device 0000:00:07.0 to 64
ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD800 irq 225
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD808 irq 225
ata1: SATA link down (SStatus 0)
scsi0 : sata_nv
ata2: SATA link down (SStatus 0)
scsi1 : sata_nv
ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 21
GSI 18 sharing vector 0xE9 and IRQ 18
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 21 (level, low) -> IRQ 233
PCI: Setting latency timer of device 0000:00:08.0 to 64
ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 233
ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 233
ata3: SATA link up 1.5 Gbps (SStatus 113)
ata3: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3468 86:3c01 87:4023 88:407f
ata3: dev 0 ATA-7, max UDMA/133, 488397168 sectors: LBA48
nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
ata3: dev 0 configured for UDMA/133
scsi2 : sata_nv
ata4: SATA link down (SStatus 0)
scsi3 : sata_nv
  Vendor: ATA       Model: ST3250823AS       Rev: 3.03
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 >
sd 2:0:0:0: Attached scsi disk sda
Fusion MPT base driver 3.03.09
Copyright (c) 1999-2005 LSI Logic Corporation
Fusion MPT SPI Host driver 3.03.09
usbmon: debugfs is not available
ACPI: PCI Interrupt Link [APCL] enabled at IRQ 20
GSI 19 sharing vector 0x32 and IRQ 19
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 20 (level, low) -> IRQ 50
PCI: Setting latency timer of device 0000:00:02.1 to 64
ehci_hcd 0000:00:02.1: EHCI Host Controller
ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:02.1: debug port 1
PCI: cache line size of 64 is not supported by device 0000:00:02.1
ehci_hcd 0000:00:02.1: irq 50, io mem 0xfeb00000
ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 10 ports detected
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [APCF] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 23 (level, low) -> IRQ 217
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:02.0: irq 217, io mem 0xda104000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 10 ports detected
USB Universal Host Controller Interface driver v3.0
usb 2-4: new low speed USB device using ohci_hcd and address 2
usb 2-4: configuration #1 chosen from 1 choice
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
HID device not claimed by input or hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
oprofile: using NMI interrupt.
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
Time: tsc clocksource has been installed.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
*****************************************************************************
*                                                                           *
*  REMINDER, the following debugging options are turned on in your .config: *
*                                                                           *
*        CONFIG_CRITICAL_PREEMPT_TIMING                                     *
*        CONFIG_CRITICAL_IRQSOFF_TIMING                                     *
*                                                                           *
*  they may increase runtime overhead and latencies.                        *
*                                                                           *
*****************************************************************************
Freeing unused kernel memory: 200k freed
input: AT Translated Set 2 keyboard as /class/input/input0
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
Adding 2008084k swap on /dev/sda10.  Priority:-1 extents:1 across:2008084k
EXT3 FS on sda2, internal journal
[drm] Initialized drm 1.0.1 20051102
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
GSI 20 sharing vector 0x3A and IRQ 20
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 58
[drm] Initialized radeon 1.24.0 20060225 on minor 0
ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCJ] -> GSI 22 (level, low) -> IRQ 225
PCI: Setting latency timer of device 0000:00:04.0 to 64
intel8x0_measure_ac97_clock: measured 50616 usecs
intel8x0: clocking to 46873
ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
GSI 21 sharing vector 0x42 and IRQ 21
ACPI: PCI Interrupt 0000:05:06.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 66
ACPI: PCI Interrupt 0000:05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 58
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[58]  MMIO=[da014000-da0147ff]  Max Packet=[4096]  IR/IT contexts=[4/8]
Realtime LSM initialized (all groups, mlock=1)
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting...
ieee1394: Node added: ID:BUS[0-00:1023]  GUID[00303c020010645c]
ieee1394: Node added: ID:BUS[0-01:1023]  GUID[0050c504e0006463]
ieee1394: Host added: ID:BUS[0-02:1023]  GUID[0800286410000f43]
scsi4 : SBP-2 IEEE-1394
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: Maxtor 6  Model: Y160P0            Rev: YAR4
  Type:   Direct-Access-RBC                  ANSI SCSI revision: 04
SCSI device sdb: 320173056 512-byte hdwr sectors (163929 MB)
sdb: Write Protect is off
sdb: Mode Sense: 11 00 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 320173056 512-byte hdwr sectors (163929 MB)
sdb: Write Protect is off
sdb: Mode Sense: 11 00 00 00
SCSI device sdb: drive cache: write back
 sdb: sdb1 sdb2
sd 4:0:0:0: Attached scsi disk sdb
scsi5 : SBP-2 IEEE-1394
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-01:1023: Max speed [S400] - Max payload [2048]
  Vendor: Maxtor 6  Model: Y160P0            Rev: YAR4
  Type:   Direct-Access-RBC                  ANSI SCSI revision: 04
SCSI device sdc: 320173056 512-byte hdwr sectors (163929 MB)
sdc: Write Protect is off
sdc: Mode Sense: 11 00 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 320173056 512-byte hdwr sectors (163929 MB)
sdc: Write Protect is off
sdc: Mode Sense: 11 00 00 00
SCSI device sdc: drive cache: write back
 sdc: sdc1 sdc2 sdc3
sd 5:0:0:0: Attached scsi disk sdc
gdm[8956]: segfault at ffffffff8068d198 rip ffffffffff6000fb rsp 00007fffa5d11120 error 5
eth0: no IPv6 routers present

[-- Attachment #3: 2.6.17-rc6-rt1.config.bz2 --]
[-- Type: application/x-bzip2, Size: 6636 bytes --]

[PATCH -rt] Trivial compiler warning fix

[Jan Altenberg]

Hi,

this patch fixes a simple compiler warning:

kernel/workqueue.c: in function »set_workqueue_thread_prio«:
kernel/workqueue.c:393: warning: implicit declaration of function `sys_sched_setscheduler'


Signed-off-by: Jan Altenberg <tb10alj@tglx.de>

----------------------

--- linux-2.6.17-rc6-rt1/kernel/workqueue.c.orig	2006-06-08 08:14:00.000000000 +0200
+++ linux-2.6.17-rc6-rt1/kernel/workqueue.c	2006-06-08 08:29:46.000000000 +0200
@@ -28,6 +28,7 @@
 #include <linux/notifier.h>
 #include <linux/kthread.h>
 #include <linux/hardirq.h>
+#include <linux/syscalls.h>
 
 /*
  * The per-CPU workqueue (if single thread, we always use the first

Re: 2.6.17-rc6-rt1

[Mike Galbraith]

On Wed, 2006-06-07 at 23:14 +0200, Ingo Molnar wrote:
> i have released the 2.6.17-rc6-rt1 tree, which can be downloaded from 
> the usual place:
> 
>    http://redhat.com/~mingo/realtime-preempt/
> 
> the biggest change was the port to 2.6.17-rc6, and the moving to John's 
> latest and greatest GTOD queue.

hangcheck-timer.c misses monotonic_clock().

Re: 2.6.17-rc6-rt1

[john stultz]

On Thu, 2006-06-08 at 10:51 +0200, Mike Galbraith wrote:
> On Wed, 2006-06-07 at 23:14 +0200, Ingo Molnar wrote:
> > i have released the 2.6.17-rc6-rt1 tree, which can be downloaded from 
> > the usual place:
> > 
> >    http://redhat.com/~mingo/realtime-preempt/
> > 
> > the biggest change was the port to 2.6.17-rc6, and the moving to John's 
> > latest and greatest GTOD queue.
> 
> hangcheck-timer.c misses monotonic_clock().


This fix from Andrew's tree was missed:
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/broken-out/hangcheck-remove-monotomic_clock-on-x86.patch

Ingo, please apply.

thanks
-john

Re: 2.6.17-rc6-rt1

[Thomas Gleixner]

On Thu, 2006-06-08 at 12:52 -0700, john stultz wrote:

> This fix from Andrew's tree was missed:
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm1/broken-out/hangcheck-remove-monotomic_clock-on-x86.patch
> 

Thanks, it's also missing in hrt. I put it there and update -rt then.

	tglx

Re: 2.6.17-rc6-rt1

[Michal Piotrowski]

Hi Ingo,

On 07/06/06, Ingo Molnar <mingo@elte.hu> wrote:
> i have released the 2.6.17-rc6-rt1 tree, which can be downloaded from
> the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/
>

BUG at /usr/src/linux-rt/kernel/rtmutex.c:639!
------------[ cut here ]------------
kernel BUG at /usr/src/linux-rt/kernel/rtmutex.c:639!
invalid opcode: 0000 [#1]
PREEMPT SMP
Modules linked in: ipv6 w83627hf hwmon_vid hwmon i2c_isa af_packet
ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink
xt_tcpudp iptable_filter ip_tables x_tables p4_clockmod speedstep_lib
binfmt_misc thermal processor fan container parport_pc parport nvram
evdev sk98lin skge snd_intel8x0 snd_ac97_codec snd_ac97_bus
snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device
snd_pcm_oss snd_mixer_oss i2c_i801 snd_pcm snd_timer snd soundcore
snd_page_alloc intel_agp ide_cd agpgart cdrom rtc unix
CPU:    1
EIP:    0060:[<c02ba67d>]    Not tainted VLI
EFLAGS: 00010202   (2.6.17-rc6-rt1 #9)
EIP is at rt_lock_slowlock+0x99/0x1b2
eax: 00000032   ebx: c60be1a0   ecx: c60be1c4   edx: 00000282
esi: eed13000   edi: f03481c8   ebp: eed13df8   esp: eed13d90
ds: 007b   es: 007b   ss: 0068   preempt: 00000003
Process bash (pid: 2104, threadinfo=eed13000 task=eea54870
stack_left=3420 worst_left=-1)
Stack: c02cddd2 c02d4bb9 0000027f c015e320 c6226070 00000093 0000008c eed13dac
       eed13dac eed13db4 eed13db4 00000000 0000008c eed13dc4 eed13dc4 eed13dcc
       eed13dcc 00000000 00000000 11111111 11111111 11111111 11111111 ee516130
Call Trace:
 [<c0103f22>] show_stack_log_lvl+0x85/0x8f (36)
 [<c0104092>] show_registers+0x166/0x1e2 (60)
 [<c010445c>] die+0x17f/0x291 (52)
 [<c01045f7>] do_trap+0x89/0xa3 (32)
 [<c0104be7>] do_invalid_op+0x89/0x93 (180)
 [<c0103a07>] error_code+0x4f/0x54 (164)
 [<c02bad05>] rt_lock+0xb/0xd (8)
 [<c015e320>] kfree+0x30/0x86 (24)
 [<c01bd0f2>] selinux_task_free_security+0x1a/0x1c (8)
 [<c011d31c>] __put_task_struct+0x8d/0xc2 (12)
 [<c02b9910>] __schedule+0xebf/0xf01 (132)
 [<c02b99da>] preempt_schedule+0x3e/0x5e (16)
 [<c02bb227>] _raw_spin_unlock+0x23/0x25 (8)
 [<c02ba653>] rt_lock_slowlock+0x6f/0x1b2 (100)
 [<c02bad05>] rt_lock+0xb/0xd (8)
 [<c015ec9c>] kmem_cache_zalloc+0x4e/0xd9 (28)
 [<c015547d>] do_mmap_pgoff+0x340/0x5c7 (64)
 [<c01071e7>] sys_mmap2+0x87/0xa4 (36)
 [<c0102e73>] sysenter_past_esp+0x54/0x75 (-4020)
---------------------------
| preempt count: 00000003 ]
| 3-level deep critical section nesting:
----------------------------------------
.. [<c02b8acb>] .... __schedule+0x7a/0xf01
.....[<c02b99da>] ..   ( <= preempt_schedule+0x3e/0x5e)
.. [<c02bae55>] .... _raw_spin_lock+0x10/0x21
.....[<c02ba608>] ..   ( <= rt_lock_slowlock+0x24/0x1b2)
.. [<c02bae9a>] .... _raw_spin_lock_irqsave+0x14/0x3b
.....[<c010432c>] ..   ( <= die+0x4f/0x291)

Code: 00 e9 36 01 00 00 be 00 f0 ff ff 21 e6 8b 43 1c 83 e0 fc 3b 06
75 1f 68 7f 02 00 00 68 b9 4b 2d c0 68 d2 dd 2c c0 e8 7d 3f e6 ff <0f>
0b 7f 02 b9 4b 2d c0 83 c4 0c 8b 06 ba 04 00 00 00 87 10 89
EIP: [<c02ba67d>] rt_lock_slowlock+0x99/0x1b2 SS:ESP 0068:eed13d90
 <6>note: bash[2104] exited with preempt_count 2
BUG: soft lockup detected on CPU#1!
 [<c0104647>] show_trace+0xd/0xf (8)
 [<c010470c>] dump_stack+0x17/0x19 (12)
 [<c01438e1>] softlockup_tick+0xa2/0xb6 (32)
 [<c01272cf>] run_local_timers+0x12/0x14 (8)
 [<c0127430>] update_process_times+0x40/0x65 (20)
 [<c0132ec4>] handle_update+0x12/0x14 (8)
 [<c01115a7>] smp_apic_timer_interrupt+0x47/0x4f (12)
 [<c010393c>] apic_timer_interrupt+0x1c/0x24 (64)
 [<c02ba608>] rt_lock_slowlock+0x24/0x1b2 (100)
 [<c02bad05>] rt_lock+0xb/0xd (8)
 [<c015dd36>] kmem_cache_free+0x2e/0x51 (24)
 [<c0156f85>] anon_vma_unlink+0x4f/0x54 (20)
 [<c0153176>] free_pgtables+0x69/0x123 (36)
 [<c0153f59>] exit_mmap+0x9c/0x123 (48)
 [<c011be5b>] mmput+0x20/0x86 (16)
 [<c011f8a0>] exit_mm+0x110/0x118 (20)
 [<c0120dd0>] do_exit+0x1e5/0x89f (48)
 [<c0104548>] die+0x26b/0x291 (52)
 [<c01045f7>] do_trap+0x89/0xa3 (32)
 [<c0104be7>] do_invalid_op+0x89/0x93 (180)
 [<c0103a07>] error_code+0x4f/0x54 (164)
 [<c02bad05>] rt_lock+0xb/0xd (8)
 [<c015e320>] kfree+0x30/0x86 (24)
 [<c01bd0f2>] selinux_task_free_security+0x1a/0x1c (8)
 [<c011d31c>] __put_task_struct+0x8d/0xc2 (12)
 [<c02b9910>] __schedule+0xebf/0xf01 (132)
 [<c02b99da>] preempt_schedule+0x3e/0x5e (16)
 [<c02bb227>] _raw_spin_unlock+0x23/0x25 (8)
 [<c02ba653>] rt_lock_slowlock+0x6f/0x1b2 (100)
 [<c02bad05>] rt_lock+0xb/0xd (8)
 [<c015ec9c>] kmem_cache_zalloc+0x4e/0xd9 (28)
 [<c015547d>] do_mmap_pgoff+0x340/0x5c7 (64)
 [<c01071e7>] sys_mmap2+0x87/0xa4 (36)
 [<c0102e73>] sysenter_past_esp+0x54/0x75 (-4020)
---------------------------
| preempt count: 00010004 ]
| 4-level deep critical section nesting:
----------------------------------------
.. [<c02b8acb>] .... __schedule+0x7a/0xf01
.....[<c02b99da>] ..   ( <= preempt_schedule+0x3e/0x5e)
.. [<c02bae55>] .... _raw_spin_lock+0x10/0x21
.....[<c02ba608>] ..   ( <= rt_lock_slowlock+0x24/0x1b2)
.. [<c02bae55>] .... _raw_spin_lock+0x10/0x21
.....[<c02ba608>] ..   ( <= rt_lock_slowlock+0x24/0x1b2)
.. [<c02bae55>] .... _raw_spin_lock+0x10/0x21
.....[<c01438d1>] ..   ( <= softlockup_tick+0x92/0xb6)

Here is dmesg http://www.stardust.webpages.pl/files/rt/2.6.17-rc6-rt1/rt-dmesg
Here is config http://www.stardust.webpages.pl/files/rt/2.6.17-rc6-rt1/rt-config

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc6-rt1

[Michal Piotrowski]

On 08/06/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
[snip]
> EIP: [<c02ba67d>] rt_lock_slowlock+0x99/0x1b2 SS:ESP 0068:eed13d90
>  <6>note: bash[2104] exited with preempt_count 2
> BUG: soft lockup detected on CPU#1!

Here is something similar

EIP: [<c02ba67d>] rt_lock_slowlock+0x99/0x1b2 SS:ESP 0068:f42a2d18
 <1>Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: make/0x00000002/3014
 [<c0104647>] show_trace+0xd/0xf (8)
 [<c010470c>] dump_stack+0x17/0x19 (12)
 [<c02b8ab1>] __schedule+0x60/0xf01 (148)
 [<c02b9b0e>] schedule+0xaf/0xcd (12)
 [<c0120ccb>] do_exit+0xe0/0x89f (48)
 [<c0104548>] die+0x26b/0x291 (52)
 [<c01045f7>] do_trap+0x89/0xa3 (32)
 [<c0104be7>] do_invalid_op+0x89/0x93 (180)
 [<c0103a07>] error_code+0x4f/0x54 (164)
 [<c02bad05>] rt_lock+0xb/0xd (8)
  [<c015e320>] kfree+0x30/0x86 (24)
 [<c01bd0f2>] selinux_task_free_security+0x1a/0x1c (8)
 [<c011d31c>] __put_task_struct+0x8d/0xc2 (12)
 [<c02b9910>] __schedule+0xebf/0xf01 (132)
 [<c02b9eec>] preempt_schedule_irq+0x37/0x57 (16)
 [<c0102e14>] need_resched+0x20/0x24 (-3656)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c02b8acb>] .... __schedule+0x7a/0xf01
.....[<c02b9eec>] ..   ( <= preempt_schedule_irq+0x37/0x57)
.. [<c02bae55>] .... _raw_spin_lock+0x10/0x21
.....[<c02ba608>] ..   ( <= rt_lock_slowlock+0x24/0x1b2)


>
> Here is dmesg http://www.stardust.webpages.pl/files/rt/2.6.17-rc6-rt1/rt-dmesg
> Here is config http://www.stardust.webpages.pl/files/rt/2.6.17-rc6-rt1/rt-config

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc6-rt1

[Michal Piotrowski]

On 07/06/06, Ingo Molnar <mingo@elte.hu> wrote:
> i have released the 2.6.17-rc6-rt1 tree, which can be downloaded from
> the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/
>

I can't unload ip_conntrack module.

Here is strace http://www.stardust.webpages.pl/files/rt/2.6.17-rc6-rt1/ip_conntrack_strace

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc6-rt1

[Kevin Hilman]

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]

On Wed, 2006-06-07 at 23:14 +0200, Ingo Molnar wrote:
> i have released the 2.6.17-rc6-rt1 tree, which can be downloaded from 
> the usual place:
> 
>    http://redhat.com/~mingo/realtime-preempt/

Here's a couple of fixes/updates:

1) Fix for arm-generic-timeofday.patch which doesn't compile against
2.6.17-rc6

2) Add clocksource for arch/arm/mach-ixp4xx

Also, I notice both asm-arm/timeofday.h and asm-ia64/timeofday.h simply
include asm-generic/timeofday.h which doesn't exist.  Should the former
be removed also?

Kevin 



[-- Attachment #2: arm-generic-timeofday-fixups.patch --]
[-- Type: text/x-patch, Size: 362 bytes --]

Index: ixp4xx/arch/arm/kernel/time.c
===================================================================
--- ixp4xx.orig/arch/arm/kernel/time.c
+++ ixp4xx/arch/arm/kernel/time.c
@@ -28,7 +28,6 @@
 #include <linux/profile.h>
 #include <linux/sysdev.h>
 #include <linux/timer.h>
-#include <linux/timeofday.h>
 
 #include <asm/leds.h>
 #include <asm/thread_info.h>

[-- Attachment #3: arm-ixp4xx-clocksource.patch --]
[-- Type: text/x-patch, Size: 2218 bytes --]

Add a clocksource driver for the Intel IXP4xx platform allowing it to
use the generic time-of-day code.

Signed-off-by: Kevin Hilman <khilman@deeprooted.net>

Index: ixp4xx/arch/arm/mach-ixp4xx/common.c
===================================================================
--- ixp4xx.orig/arch/arm/mach-ixp4xx/common.c
+++ ixp4xx/arch/arm/mach-ixp4xx/common.c
@@ -27,6 +27,7 @@
 #include <linux/bitops.h>
 #include <linux/time.h>
 #include <linux/timex.h>
+#include <linux/clocksource.h>
 
 #include <asm/hardware.h>
 #include <asm/uaccess.h>
@@ -256,16 +257,6 @@ static unsigned volatile last_jiffy_time
 
 #define CLOCK_TICKS_PER_USEC	((CLOCK_TICK_RATE + USEC_PER_SEC/2) / USEC_PER_SEC)
 
-/* IRQs are disabled before entering here from do_gettimeofday() */
-static unsigned long ixp4xx_gettimeoffset(void)
-{
-	u32 elapsed;
-
-	elapsed = *IXP4XX_OSTS - last_jiffy_time;
-
-	return elapsed / CLOCK_TICKS_PER_USEC;
-}
-
 static irqreturn_t ixp4xx_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
 	write_seqlock(&xtime_lock);
@@ -300,8 +291,6 @@ static void __init ixp4xx_timer_init(voi
 	/* Setup the Timer counter value */
 	*IXP4XX_OSRT1 = (LATCH & ~IXP4XX_OST_RELOAD_MASK) | IXP4XX_OST_ENABLE;
 
-	/* Reset time-stamp counter */
-	*IXP4XX_OSTS = 0;
 	last_jiffy_time = 0;
 
 	/* Connect the interrupt handler and enable the interrupt */
@@ -310,7 +299,6 @@ static void __init ixp4xx_timer_init(voi
 
 struct sys_timer ixp4xx_timer = {
 	.init		= ixp4xx_timer_init,
-	.offset		= ixp4xx_gettimeoffset,
 };
 
 static struct resource ixp46x_i2c_resources[] = {
@@ -366,3 +354,30 @@ void __init ixp4xx_sys_init(void)
 			ixp4xx_exp_bus_size >> 20);
 }
 
+cycle_t ixp4xx_get_cycles(void)
+{
+	return *IXP4XX_OSTS;
+}
+
+static struct clocksource clocksource_ixp4xx = {
+	.name 		= "OSTS",
+	.rating		= 200,
+	.read		= ixp4xx_get_cycles,
+	.mask		= 0xFFFFFFFF,
+	.shift 		= 10,
+	.is_continuous 	= 1,
+};
+
+static int __init ixp4xx_clocksource_init(void)
+{
+	/* Reset time-stamp counter */
+	*IXP4XX_OSTS = 0;
+
+	clocksource_ixp4xx.mult =
+		clocksource_khz2mult(66660, clocksource_ixp4xx.shift);
+	clocksource_register(&clocksource_ixp4xx);
+
+	return 0;
+}
+
+device_initcall(ixp4xx_clocksource_init);

Re: 2.6.17-rc6-rt1

[Thomas Gleixner]

On Thu, 2006-06-08 at 11:27 -0700, Kevin Hilman wrote:
> On Wed, 2006-06-07 at 23:14 +0200, Ingo Molnar wrote:
> > i have released the 2.6.17-rc6-rt1 tree, which can be downloaded from 
> > the usual place:
> > 
> >    http://redhat.com/~mingo/realtime-preempt/
> 
> Here's a couple of fixes/updates:
> 
> 1) Fix for arm-generic-timeofday.patch which doesn't compile against
> 2.6.17-rc6
> 
> 2) Add clocksource for arch/arm/mach-ixp4xx

Thanks, applied

> Also, I notice both asm-arm/timeofday.h and asm-ia64/timeofday.h simply
> include asm-generic/timeofday.h which doesn't exist.  Should the former
> be removed also?

Yes, thats a leftover from the older timeofday code which was in
2.6.16-rtxx. Removed.

	tglx

Re: 2.6.17-rc6-rt1

[john stultz]

On Wed, 2006-06-07 at 23:14 +0200, Ingo Molnar wrote:
> if we accidentally dropped some fix in the process then please complain. 
> x86 and x86_64 build and boot, but some initial rough edges are to be 
> expected. Deepak, your ARM-GTOD patches are included but not tested yet.

Ingo,
	This fix will be needed in 2.6.17-rc6-rt1, as it includes the x86-64
TOD conversion (not yet in -mm).

I accidentally used the kernel-mapped vsyscall_gtod_data value, 
rather then the user-mapped __vsyscall_gtod_data value in do_get_tz.

This would cause gettimeofday to segfault when using a non-null 
timezone pointer.

Many thanks to Martin Murray, who pointed out this issue and its fix.

thanks
-john

Signed-off-by: John Stultz <johnstul@us.ibm.com>

diff --git a/arch/x86_64/kernel/vsyscall.c b/arch/x86_64/kernel/vsyscall.c
index 98692a4..0bda23b 100644
--- a/arch/x86_64/kernel/vsyscall.c
+++ b/arch/x86_64/kernel/vsyscall.c
@@ -125,7 +125,7 @@ static __always_inline void do_vgettimeo
 /* RED-PEN may want to readd seq locking, but then the variable should be write-once. */
 static __always_inline void do_get_tz(struct timezone * tz)
 {
-	*tz = vsyscall_gtod_data.sys_tz;
+	*tz = __vsyscall_gtod_data.sys_tz;
 }
 
 static __always_inline int gettimeofday(struct timeval *tv, struct timezone *tz)

Re: 2.6.17-rc6-rt1

[Thomas Gleixner]

On Thu, 2006-06-08 at 16:57 -0700, john stultz wrote:
> This would cause gettimeofday to segfault when using a non-null 
> timezone pointer.
> 
> Many thanks to Martin Murray, who pointed out this issue and its fix.

Thanks, 

I take it that applies to -hrt too.

	tglx

Re: 2.6.17-rc6-rt1

[Mike Galbraith]

On Wed, 2006-06-07 at 23:14 +0200, Ingo Molnar wrote:
> i have released the 2.6.17-rc6-rt1 tree, which can be downloaded from 
> the usual place:
> 
>    http://redhat.com/~mingo/realtime-preempt/
> 
> the biggest change was the port to 2.6.17-rc6, and the moving to John's 
> latest and greatest GTOD queue. Most of the porting was done by Thomas 
> Gleixner (thanks Thomas!). We also picked up the freshest genirq queue 
> from -mm and the freshest PI-futex patchset. There are also lots of ARM 
> fixups and enhancements from Deepak Saxena and Daniel Walker.

I have some fairly strange things going on with this kernel.

First of all, during boot, I end up with these two entries.
BUG: wq(events) setscheduler() returned: -22.
BUG: wq(events) setscheduler() returned: -22.

After boot, it takes a very long time for KDE to finish loading... more
than five minutes for the desktop background to finally appear.  Tasks
which are doing nothing but a ~50ms gettimeofday() select() idle loop
show up in top as using 1 to 3 percent cpu, though strace of these looks
fine.  Starting any threaded app takes ages, whereas plain-jane things
like gcc work fine.  For example, if I fire up xmms, the gui comes up
quickly, but it takes over three minutes from the time I poke play until
the first sound is emitted.  Starting evolution takes even longer.

Hoping that something might show up while running glibc-2.4 make check
to save me from wading through huge truckloads of strace, I tried it.
It repeatedly goes boom.  RT29 goes boom the same way, but doesn't
exhibit the slow threaded app symptom.  Drat.

rt/tst-cpuclock1

kernel BUG at :55017!
invalid opcode: 0000 [#1]
PREEMPT SMP 
Modules linked in: xt_pkttype ipt_LOG xt_limit snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device edd tda9887 saa7134 ir_kbd_i2c ip6t_REJECT xt_tcpudp ipt_REJECT xt_state bt878 prism54 ohci1394 iptable_mangle ieee1394 iptable_nat ip_nat iptable_filter i2c_i801 snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm ip6table_mangle snd_timer snd soundcore snd_page_alloc ip_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables tuner bttv video_buf firmware_class ir_common btcx_risc tveeprom nls_iso8859_1 nls_cp437 nls_utf8
CPU:    0
EIP:    0060:[<b10375ca>]    Not tainted VLI
EFLAGS: 00010202   (2.6.17-rc6-rt1-smp #166) 
EIP is at posix_cpu_timer_set+0x4bc/0x4db
eax: 00000286   ebx: d889ef78   ecx: ea8c72a0   edx: dfea8700
esi: 3b9aca00   edi: d889eef0   ebp: d889eeb8   esp: d889ee60
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process ld-linux.so.2 (pid: 27786, threadinfo=d889e000 task=dfea8700 stack_left=3628 worst_left=-1)
Stack: 00000001 b1555fa8 d889eefc b139cbb0 d889ef78 00000000 d889eee8 d7d1e7d8 
       0000002a 05f5e100 00000000 05f5e100 00000000 ea8c72a0 fffffffd d889eea8 
       b139ef00 00000000 d889eeb8 d889ef78 00000000 d889eef0 d889ef94 b10377fd 
Call Trace:
 [<b1004018>] show_stack_log_lvl+0x9d/0xc2 (36)
 [<b100421f>] show_registers+0x1a6/0x272 (72)
 [<b100441b>] die+0x130/0x2f6 (68)
 [<b1004651>] do_trap+0x70/0xaf (28)
 [<b1004edf>] do_invalid_op+0x97/0xa1 (180)
 [<b1003b4f>] error_code+0x4f/0x54 (148)
 [<b10377fd>] posix_cpu_nsleep+0x105/0x232 (220)
 [<b10345e8>] sys_clock_nanosleep+0xc6/0xcd (32)
 [<b1003023>] syscall_call+0x7/0xb (-4020)
Code: 68 00 00 00 00 c7 45 e0 fd ff ff ff e9 08 fe ff ff c7 41 6c ff ff ff ff c7 45 e0 01 00 00 00 c7 45 e8 01 00 00 00 e9 2f fc ff ff <0f> 0b e9 d6 fb ff ff b8 80 6a 54 b1 e8 f7 78 36 00 e9 ba fd ff 
EIP: [<b10375ca>] posix_cpu_timer_set+0x4bc/0x4db SS:ESP 0068:d889ee60

(gdb) list *posix_cpu_timer_set+0x4bc
0xb10375ea is in posix_cpu_timer_set (posix-cpu-timers.c:724).
719             }
720
721             /*
722              * Disarm any old timer after extracting its expiry time.
723              */
724             BUG_ON(!irqs_disabled());
725
726             ret = 0;
727             spin_lock(&p->sighand->siglock);
728             old_expires = timer->it.cpu.expires;
(gdb)

 ------------[ cut here ]------------
kernel BUG at z:12777!
invalid opcode: 0000 [#2]
PREEMPT SMP 
Modules linked in: xt_pkttype ipt_LOG xt_limit snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device edd tda9887 saa7134 ir_kbd_i2c ip6t_REJECT xt_tcpudp ipt_REJECT xt_state bt878 prism54 ohci1394 iptable_mangle ieee1394 iptable_nat ip_nat iptable_filter i2c_i801 snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm ip6table_mangle snd_timer snd soundcore snd_page_alloc ip_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables tuner bttv video_buf firmware_class ir_common btcx_risc tveeprom nls_iso8859_1 nls_cp437 nls_utf8
CPU:    0
EIP:    0060:[<b139e7d5>]    Not tainted VLI
EFLAGS: 00010246   (2.6.17-rc6-rt1-smp #166) 
EIP is at rt_lock_slowlock+0x10e/0x135
eax: dfea8700   ebx: b1623d40   ecx: b1546a98   edx: d889e000
esi: dfea8700   edi: b1546a80   ebp: d889ecb4   esp: d889ec70
ds: 007b   es: 007b   ss: 0068   preempt: 00000002
Process ld-linux.so.2 (pid: 27786, threadinfo=d889e000 task=dfea8700 stack_left=3132 worst_left=-1)
Stack: 00000000 dfdf2580 00000000 effe2800 00000000 dfd11440 d889ec98 b104c270 
       efcca388 efcca388 d889eca0 effeb4e8 00000000 b243abe0 b1623d40 dfea8700 
       dfea8bb4 d889ecbc b139edfc d889ecc4 b139ee7e d889ed10 b102559d d889ee60 
Call Trace:
 [<b1004018>] show_stack_log_lvl+0x9d/0xc2 (36)
 [<b100421f>] show_registers+0x1a6/0x272 (72)
 [<b100441b>] die+0x130/0x2f6 (68)
 [<b1004651>] do_trap+0x70/0xaf (28)
 [<b1004edf>] do_invalid_op+0x97/0xa1 (180)
 [<b1003b4f>] error_code+0x4f/0x54 (128)
 [<b139edfc>] rt_lock+0x22/0x27 (8)
 [<b139ee7e>] rt_write_lock+0x8/0xa (8)
 [<b102559d>] do_exit+0x2ab/0x953 (76)
 [<b10045e1>] do_trap+0x0/0xaf (68)
 [<b1004651>] do_trap+0x70/0xaf (28)
 [<b1004edf>] do_invalid_op+0x97/0xa1 (180)
 [<b1003b4f>] error_code+0x4f/0x54 (148)
 [<b10377fd>] posix_cpu_nsleep+0x105/0x232 (220)
 [<b10345e8>] sys_clock_nanosleep+0xc6/0xcd (32)
 [<b1003023>] syscall_call+0x7/0xb (-4020)
Code: 00 00 00 00 8b 5d ec 85 db 74 0a 8d 55 c4 89 f8 e8 cd db c9 ff 89 f8 e8 f4 d4 c9 ff 89 f8 e8 c7 0a 00 00 83 c4 38 5b 5e 5f 5d c3 <0f> 0b e9 31 ff ff ff c7 45 bc 00 00 00 00 eb 80 8d 47 08 89 47 
EIP: [<b139e7d5>] rt_lock_slowlock+0x10e/0x135 SS:ESP 0068:d889ec70

 (gdb) list *rt_lock_slowlock+0x10e
 0xb139e7f5 is in rt_lock_slowlock (rtmutex.c:639).
 634             if (try_to_take_rt_mutex(lock __IP__)) {
 635                     spin_unlock(&lock->wait_lock);
 636                     return;
 637             }
 638
 639             BUG_ON(rt_mutex_owner(lock) == current);
 640
 641             /*
 642              * Here we save whatever state the task was in originally,
 643              * we'll restore it at the end of the function and we'll take
 (gdb)

 Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: ld-linux.so.2/0x00000001/27786
 [<b1004077>] show_trace+0xd/0xf (8)
 [<b10049a6>] dump_stack+0x17/0x19 (12)
 [<b139cf5b>] __schedule+0x814/0x112a (148)
 [<b139d9c1>] schedule+0x30/0xed (28)
 [<b1025b15>] do_exit+0x823/0x953 (76)
 [<b10045e1>] do_trap+0x0/0xaf (68)
 [<b1004651>] do_trap+0x70/0xaf (28)
 [<b1004edf>] do_invalid_op+0x97/0xa1 (180)
 [<b1003b4f>] error_code+0x4f/0x54 (128)
 [<b139edfc>] rt_lock+0x22/0x27 (8)
 [<b139ee7e>] rt_write_lock+0x8/0xa (8)
 [<b102559d>] do_exit+0x2ab/0x953 (76)
 [<b10045e1>] do_trap+0x0/0xaf (68)
 [<b1004651>] do_trap+0x70/0xaf (28)
 [<b1004edf>] do_invalid_op+0x97/0xa1 (180)
 [<b1003b4f>] error_code+0x4f/0x54 (148)
 [<b10377fd>] posix_cpu_nsleep+0x105/0x232 (220)
 [<b10345e8>] sys_clock_nanosleep+0xc6/0xcd (32)
 [<b1003023>] syscall_call+0x7/0xb (-4020)

Re: 2.6.17-rc6-rt1

[Sébastien Dugué]

On Fri, 2006-06-09 at 10:42 +0200, Mike Galbraith wrote:
> On Wed, 2006-06-07 at 23:14 +0200, Ingo Molnar wrote:
> > i have released the 2.6.17-rc6-rt1 tree, which can be downloaded from 
> > the usual place:
> > 
> >    http://redhat.com/~mingo/realtime-preempt/
> > 
> > the biggest change was the port to 2.6.17-rc6, and the moving to John's 
> > latest and greatest GTOD queue. Most of the porting was done by Thomas 
> > Gleixner (thanks Thomas!). We also picked up the freshest genirq queue 
> > from -mm and the freshest PI-futex patchset. There are also lots of ARM 
> > fixups and enhancements from Deepak Saxena and Daniel Walker.
> 
> I have some fairly strange things going on with this kernel.
> 
> First of all, during boot, I end up with these two entries.
> BUG: wq(events) setscheduler() returned: -22.
> BUG: wq(events) setscheduler() returned: -22.
> 
> After boot, it takes a very long time for KDE to finish loading... more
> than five minutes for the desktop background to finally appear.  Tasks
> which are doing nothing but a ~50ms gettimeofday() select() idle loop
> show up in top as using 1 to 3 percent cpu, though strace of these looks
> fine.  Starting any threaded app takes ages, whereas plain-jane things
> like gcc work fine.  For example, if I fire up xmms, the gui comes up
> quickly, but it takes over three minutes from the time I poke play until
> the first sound is emitted.  Starting evolution takes even longer.
> 
> Hoping that something might show up while running glibc-2.4 make check
> to save me from wading through huge truckloads of strace, I tried it.
> It repeatedly goes boom.  RT29 goes boom the same way, but doesn't
> exhibit the slow threaded app symptom.  Drat.
> 

  Yep noticed that here too. As you pointed out it seems to be related
to threaded apps. ls, vi, ... work fine whereas xemacs or others are
real slow, portmapper fails to respond, ...

  I've got no indication in the logs that something went wrong, nor
do I see any kernel BUG or WARNING.

  My box is a dual 2.8GHz HT xeon w/ 2GB mem.

  rt29 was fine as is 2.6.17-rc6.

  I feel a bit perplexed here.


  Sébastien.

  

Re: 2.6.17-rc6-rt1

[Mike Galbraith]

On Fri, 2006-06-09 at 12:12 +0200, Sébastien Dugué wrote:
> On Fri, 2006-06-09 at 10:42 +0200, Mike Galbraith wrote:

> > After boot, it takes a very long time for KDE to finish loading... more
> > than five minutes for the desktop background to finally appear.  Tasks
> > which are doing nothing but a ~50ms gettimeofday() select() idle loop
> > show up in top as using 1 to 3 percent cpu, though strace of these looks
> > fine.  Starting any threaded app takes ages, whereas plain-jane things
> > like gcc work fine.  For example, if I fire up xmms, the gui comes up
> > quickly, but it takes over three minutes from the time I poke play until
> > the first sound is emitted.  Starting evolution takes even longer.
> > 
> > Hoping that something might show up while running glibc-2.4 make check
> > to save me from wading through huge truckloads of strace, I tried it.
> > It repeatedly goes boom.  RT29 goes boom the same way, but doesn't
> > exhibit the slow threaded app symptom.  Drat.
> > 
> 
>   Yep noticed that here too. As you pointed out it seems to be related
> to threaded apps. ls, vi, ... work fine whereas xemacs or others are
> real slow, portmapper fails to respond, ...
> 
>   I've got no indication in the logs that something went wrong, nor
> do I see any kernel BUG or WARNING.
> 
>   My box is a dual 2.8GHz HT xeon w/ 2GB mem.
> 
>   rt29 was fine as is 2.6.17-rc6.
> 
>   I feel a bit perplexed here.

I found xmms problem.

[pid  8498] 12:53:49.936186 socket(PF_INET, SOCK_STREAM, IPPROTO_IP <unfinished ...>
[pid  8498] 12:53:49.936551 <... socket resumed> ) = 9 <0.000301>
[pid  8498] 12:53:49.936774 fcntl64(9, F_SETFD, FD_CLOEXEC <unfinished ...>
[pid  8498] 12:53:49.937287 <... fcntl64 resumed> ) = 0 <0.000465>
[pid  8498] 12:53:49.937451 setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4 <unfinished ...>
[pid  8498] 12:53:49.937630 <... setsockopt resumed> ) = 0 <0.000110>
[pid  8498] 12:53:49.937893 connect(9, {sa_family=AF_INET, sin_port=htons(16001), sin_addr=inet_addr("127.0.0.1")}, 16 <unfinished ...>
[pid  8498] 12:56:58.902958 <... connect resumed> ) = -1 ETIMEDOUT (Connection timed out) <188.964934>

which should have been...

[pid  7385] 13:21:38.715146 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 9 <0.000011>
[pid  7385] 13:21:38.715192 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 <0.000007>
[pid  7385] 13:21:38.715237 setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000008>
[pid  7385] 13:21:38.715283 connect(9, {sa_family=AF_INET, sin_port=htons(16001), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused) <0.000060>

So much for the easy part.

	-Mike

Re: 2.6.17-rc6-rt1

[Sébastien Dugué]

On Fri, 2006-06-09 at 13:35 +0200, Mike Galbraith wrote:
> On Fri, 2006-06-09 at 12:12 +0200, Sébastien Dugué wrote:
> > On Fri, 2006-06-09 at 10:42 +0200, Mike Galbraith wrote:
> 
> > > After boot, it takes a very long time for KDE to finish loading... more
> > > than five minutes for the desktop background to finally appear.  Tasks
> > > which are doing nothing but a ~50ms gettimeofday() select() idle loop
> > > show up in top as using 1 to 3 percent cpu, though strace of these looks
> > > fine.  Starting any threaded app takes ages, whereas plain-jane things
> > > like gcc work fine.  For example, if I fire up xmms, the gui comes up
> > > quickly, but it takes over three minutes from the time I poke play until
> > > the first sound is emitted.  Starting evolution takes even longer.
> > > 
> > > Hoping that something might show up while running glibc-2.4 make check
> > > to save me from wading through huge truckloads of strace, I tried it.
> > > It repeatedly goes boom.  RT29 goes boom the same way, but doesn't
> > > exhibit the slow threaded app symptom.  Drat.
> > > 
> > 
> >   Yep noticed that here too. As you pointed out it seems to be related
> > to threaded apps. ls, vi, ... work fine whereas xemacs or others are
> > real slow, portmapper fails to respond, ...
> > 
> >   I've got no indication in the logs that something went wrong, nor
> > do I see any kernel BUG or WARNING.
> > 
> >   My box is a dual 2.8GHz HT xeon w/ 2GB mem.
> > 
> >   rt29 was fine as is 2.6.17-rc6.
> > 
> >   I feel a bit perplexed here.
> 
> I found xmms problem.
> 
> [pid  8498] 12:53:49.936186 socket(PF_INET, SOCK_STREAM, IPPROTO_IP <unfinished ...>
> [pid  8498] 12:53:49.936551 <... socket resumed> ) = 9 <0.000301>
> [pid  8498] 12:53:49.936774 fcntl64(9, F_SETFD, FD_CLOEXEC <unfinished ...>
> [pid  8498] 12:53:49.937287 <... fcntl64 resumed> ) = 0 <0.000465>
> [pid  8498] 12:53:49.937451 setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4 <unfinished ...>
> [pid  8498] 12:53:49.937630 <... setsockopt resumed> ) = 0 <0.000110>
> [pid  8498] 12:53:49.937893 connect(9, {sa_family=AF_INET, sin_port=htons(16001), sin_addr=inet_addr("127.0.0.1")}, 16 <unfinished ...>
> [pid  8498] 12:56:58.902958 <... connect resumed> ) = -1 ETIMEDOUT (Connection timed out) <188.964934>
> 
> which should have been...
> 
> [pid  7385] 13:21:38.715146 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 9 <0.000011>
> [pid  7385] 13:21:38.715192 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 <0.000007>
> [pid  7385] 13:21:38.715237 setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000008>
> [pid  7385] 13:21:38.715283 connect(9, {sa_family=AF_INET, sin_port=htons(16001), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused) <0.000060>
> 
> So much for the easy part.
> 

  I'm starting to believe that it's network related. Pinging my box from
a remote host gives a ~.3 ms round trip whereas pinging localhost gives
~500ms. Something real weird is going on here.

  I'm trying to dig deeper but I'm no expert here.

  Sébastien.

Re: 2.6.17-rc6-rt1

[Mike Galbraith]

On Fri, 2006-06-09 at 13:44 +0200, Sébastien Dugué wrote:
> On Fri, 2006-06-09 at 13:35 +0200, Mike Galbraith wrote:
> > 
> > I found xmms problem.
> > 
> > [pid  8498] 12:53:49.936186 socket(PF_INET, SOCK_STREAM, IPPROTO_IP <unfinished ...>
> > [pid  8498] 12:53:49.936551 <... socket resumed> ) = 9 <0.000301>
> > [pid  8498] 12:53:49.936774 fcntl64(9, F_SETFD, FD_CLOEXEC <unfinished ...>
> > [pid  8498] 12:53:49.937287 <... fcntl64 resumed> ) = 0 <0.000465>
> > [pid  8498] 12:53:49.937451 setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4 <unfinished ...>
> > [pid  8498] 12:53:49.937630 <... setsockopt resumed> ) = 0 <0.000110>
> > [pid  8498] 12:53:49.937893 connect(9, {sa_family=AF_INET, sin_port=htons(16001), sin_addr=inet_addr("127.0.0.1")}, 16 <unfinished ...>
> > [pid  8498] 12:56:58.902958 <... connect resumed> ) = -1 ETIMEDOUT (Connection timed out) <188.964934>
> > 
> > which should have been...
> > 
> > [pid  7385] 13:21:38.715146 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 9 <0.000011>
> > [pid  7385] 13:21:38.715192 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 <0.000007>
> > [pid  7385] 13:21:38.715237 setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 <0.000008>
> > [pid  7385] 13:21:38.715283 connect(9, {sa_family=AF_INET, sin_port=htons(16001), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused) <0.000060>
> > 
> > So much for the easy part.
> > 
> 
>   I'm starting to believe that it's network related. Pinging my box from
> a remote host gives a ~.3 ms round trip whereas pinging localhost gives
> ~500ms. Something real weird is going on here.

Wow.  I don't see anything near 500ms, but I am dropping packets, and
recvmsg, when it isn't saying -EAGAIN, is indeed taking way too long.

14:04:02.062550 sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\10\0$@\217\36\0\2\262c\211D\35\364\0\0\10\t\n\v\f\r\16"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 64 <0.000048>
14:04:02.062731 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={10, 0}}, NULL) = 0 <0.000016>
14:04:02.062826 recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(19889), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"E\0\0T\177]\0\0@\1\375I\177\0\0\1\177\0\0\1\0\0,@\217\36"..., 192}], msg_controllen=20, {cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0}, 0) = 84 <0.037660>

Re: 2.6.17-rc6-rt1

[Sébastien Dugué]

On Fri, 2006-06-09 at 14:20 +0200, Mike Galbraith wrote:
> > 
> >   I'm starting to believe that it's network related. Pinging my box from
> > a remote host gives a ~.3 ms round trip whereas pinging localhost gives
> > ~500ms. Something real weird is going on here.
> 
> Wow.  I don't see anything near 500ms, but I am dropping packets, and
> recvmsg, when it isn't saying -EAGAIN, is indeed taking way too long.
> 
> 14:04:02.062550 sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\10\0$@\217\36\0\2\262c\211D\35\364\0\0\10\t\n\v\f\r\16"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 64 <0.000048>
> 14:04:02.062731 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={10, 0}}, NULL) = 0 <0.000016>
> 14:04:02.062826 recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(19889), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"E\0\0T\177]\0\0@\1\375I\177\0\0\1\177\0\0\1\0\0,@\217\36"..., 192}], msg_controllen=20, {cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0}, 0) = 84 <0.037660>
> 

  Even weirder:

$ping localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.157 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=107 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=94.7 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=4 ttl=64 time=741 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=5 ttl=64 time=179 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=6 ttl=64 time=732 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=7 ttl=64 time=728 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=8 ttl=64 time=725 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=9 ttl=64 time=178 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=10 ttl=64 time=96.0 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=11 ttl=64 time=342 ms
...

$strace -tt -T ping localhost
14:48:07.764888 sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), 
sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\10\0:\221\341\v\0\3\7n\211DU\25
2\v\0\10\t\n\v\f\r\16\17"..., 64}], msg_controllen=0, msg_flags=0}, MSG_CONFIRM)
 = 64 <0.000078>
14:48:07.765930 recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), 
sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"E\0\0T\\\241\0\0@\1 \6\177\0\0\1
\177\0\0\1\0\0B\221\341"..., 192}], msg_controllen=20, {cmsg_len=20, cmsg_level=
SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0}, 0) = 84 <0.000402>
14:48:07.767598 write(1, "64 bytes from localhost.localdom"..., 8064 bytes from 
localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=1.86 ms
) = 80 <0.000307>

All the round trips under strace are in the 2ms range.

  How on earth can it be that stracing the ping gives better
performance???

  Sébastien.

Re: 2.6.17-rc6-rt1

[Thomas Gleixner]

On Fri, 2006-06-09 at 14:57 +0200, Sébastien Dugué wrote:
> All the round trips under strace are in the 2ms range.
> 
>   How on earth can it be that stracing the ping gives better
> performance???

Was busy fixing a scheduling while atomic bug. I just verified that I
have the same weird behaviour. I'm looking into it.

	tglx

Re: 2.6.17-rc6-rt1

[Mike Galbraith]

On Fri, 2006-06-09 at 15:11 +0200, Thomas Gleixner wrote:
> On Fri, 2006-06-09 at 14:57 +0200, Sébastien Dugué wrote:
> > All the round trips under strace are in the 2ms range.
> > 
> >   How on earth can it be that stracing the ping gives better
> > performance???
> 
> Was busy fixing a scheduling while atomic bug. I just verified that I
> have the same weird behaviour. I'm looking into it.

I downloaded and patched a ping.c to do a user triggered latency trace
around recvfrom() of a ping -c 1 127.0.0.1 running SCHED_RR.  We
schedule away at 25us, do aaaall kinds of interesting stuff, and come
back at 42234us.  If you want the trace, holler.  It's 51k bzipped.

	-Mike

Re: 2.6.17-rc6-rt1

[Thomas Gleixner]

On Fri, 2006-06-09 at 15:42 +0200, Mike Galbraith wrote:
> On Fri, 2006-06-09 at 15:11 +0200, Thomas Gleixner wrote:
> > On Fri, 2006-06-09 at 14:57 +0200, Sébastien Dugué wrote:
> > > All the round trips under strace are in the 2ms range.
> > > 
> > >   How on earth can it be that stracing the ping gives better
> > > performance???
> > 
> > Was busy fixing a scheduling while atomic bug. I just verified that I
> > have the same weird behaviour. I'm looking into it.
> 
> I downloaded and patched a ping.c to do a user triggered latency trace
> around recvfrom() of a ping -c 1 127.0.0.1 running SCHED_RR.  We
> schedule away at 25us, do aaaall kinds of interesting stuff, and come
> back at 42234us.  If you want the trace, holler.  It's 51k bzipped.

Yes, please send it offlist to me.

Thanks, 

	tglx

Re: 2.6.17-rc6-rt1

[Daniel Walker]

On Fri, 2006-06-09 at 15:42 +0200, Mike Galbraith wrote:
> On Fri, 2006-06-09 at 15:11 +0200, Thomas Gleixner wrote:
> > On Fri, 2006-06-09 at 14:57 +0200, Sébastien Dugué wrote:
> > > All the round trips under strace are in the 2ms range.
> > > 
> > >   How on earth can it be that stracing the ping gives better
> > > performance???
> > 
> > Was busy fixing a scheduling while atomic bug. I just verified that I
> > have the same weird behaviour. I'm looking into it.
> 
> I downloaded and patched a ping.c to do a user triggered latency trace
> around recvfrom() of a ping -c 1 127.0.0.1 running SCHED_RR.  We
> schedule away at 25us, do aaaall kinds of interesting stuff, and come
> back at 42234us.  If you want the trace, holler.  It's 51k bzipped.

What priority ?

Daniel

Re: 2.6.17-rc6-rt1

[Mike Galbraith]

On Fri, 2006-06-09 at 08:55 -0700, Daniel Walker wrote:
> On Fri, 2006-06-09 at 15:42 +0200, Mike Galbraith wrote:
> > On Fri, 2006-06-09 at 15:11 +0200, Thomas Gleixner wrote:
> > > On Fri, 2006-06-09 at 14:57 +0200, Sébastien Dugué wrote:
> > > > All the round trips under strace are in the 2ms range.
> > > > 
> > > >   How on earth can it be that stracing the ping gives better
> > > > performance???
> > > 
> > > Was busy fixing a scheduling while atomic bug. I just verified that I
> > > have the same weird behaviour. I'm looking into it.
> > 
> > I downloaded and patched a ping.c to do a user triggered latency trace
> > around recvfrom() of a ping -c 1 127.0.0.1 running SCHED_RR.  We
> > schedule away at 25us, do aaaall kinds of interesting stuff, and come
> > back at 42234us.  If you want the trace, holler.  It's 51k bzipped.
> 
> What priority ?

Bare minimum.  None of the other tasks that were scheduled were rt in
their own right though.

	-Mike

Re: 2.6.17-rc6-rt1

[Thomas Gleixner]

On Fri, 2006-06-09 at 20:41 +0200, Mike Galbraith wrote:
> > What priority ?
> 
> Bare minimum.  None of the other tasks that were scheduled were rt in
> their own right though.

I tracked it down. Working on the fix.

	tglx