This amused me.
(17:43:34:davej@nemesis:~)$ ll /proc/acpi/processor/
total 0
dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU1/
dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU2/
dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU3/
(17:43:36:davej@nemesis:~)$
As cool as a 3-way x86-64 sounds, it's really only got 2.
Two of these..
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 244
stepping : 8
cpu MHz : 1789.412
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 3578.59
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts ttp
(17:45:21:davej@nemesis:~)$ cat /proc/acpi/processor/CPU*/info
processor id: 0
acpi id: 1
bus mastering control: no
power management: no
throttling control: yes
limit interface: yes
processor id: 1
acpi id: 2
bus mastering control: no
power management: no
throttling control: no
limit interface: no
processor id: 255
acpi id: 3
bus mastering control: no
power management: no
throttling control: no
limit interface: no
I guess the '255' has confused something.
This made my 'bug of the day' :)
Dave
This may be the "ACPI core", dedicated to running the ACPI interpreter.
:-)
> -----Original Message-----
> From: [email protected] [mailto:linux-acpi-
> [email protected]] On Behalf Of Dave Jones
> Sent: Wednesday, March 01, 2006 2:47 PM
> To: [email protected]
> Cc: [email protected]
> Subject: 2.6.16rc5 'found' an extra CPU.
>
> This amused me.
>
> (17:43:34:davej@nemesis:~)$ ll /proc/acpi/processor/
> total 0
> dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU1/
> dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU2/
> dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU3/
> (17:43:36:davej@nemesis:~)$
>
> As cool as a 3-way x86-64 sounds, it's really only got 2.
>
> Two of these..
>
> vendor_id : AuthenticAMD
> cpu family : 15
> model : 5
> model name : AMD Opteron(tm) Processor 244
> stepping : 8
> cpu MHz : 1789.412
> cache size : 1024 KB
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca
> cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext
> 3dnow
> bogomips : 3578.59
> TLB size : 1024 4K pages
> clflush size : 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virtual
> power management: ts ttp
>
>
> (17:45:21:davej@nemesis:~)$ cat /proc/acpi/processor/CPU*/info
> processor id: 0
> acpi id: 1
> bus mastering control: no
> power management: no
> throttling control: yes
> limit interface: yes
> processor id: 1
> acpi id: 2
> bus mastering control: no
> power management: no
> throttling control: no
> limit interface: no
> processor id: 255
> acpi id: 3
> bus mastering control: no
> power management: no
> throttling control: no
> limit interface: no
>
> I guess the '255' has confused something.
>
> This made my 'bug of the day' :)
>
> Dave
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 01, 2006 at 05:46:47PM -0500, Dave Jones wrote:
> This amused me.
>
> (17:43:34:davej@nemesis:~)$ ll /proc/acpi/processor/
> total 0
> dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU1/
> dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU2/
> dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU3/
> (17:43:36:davej@nemesis:~)$
Digging further. I notice more oddities (or maybe I've just
misunderstood this -- corrections welcomed)
(17:59:02:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/core_id
0
(17:59:23:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/core_id
0
(17:59:38:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/core_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
(17:59:47:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002
Neither of these CPUs are HT / dual-core, so shouldn't these be the same ?
(18:00:04:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
(18:00:09:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/thread_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002
Ditto ?
Dave
On Thursday 02 March 2006 00:03, Dave Jones wrote:
> On Wed, Mar 01, 2006 at 05:46:47PM -0500, Dave Jones wrote:
> > This amused me.
> >
> > (17:43:34:davej@nemesis:~)$ ll /proc/acpi/processor/
> > total 0
> > dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU1/
> > dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU2/
> > dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU3/
> > (17:43:36:davej@nemesis:~)$
>
> Digging further. I notice more oddities (or maybe I've just
> misunderstood this -- corrections welcomed)
Probably related to Ashok's ACPI CPU hotplug patches.
What's the full bootup log?
> (17:59:02:davej@nemesis:~)$ cat
> /sys/devices/system/cpu/cpu0/topology/core_id 0
> (17:59:23:davej@nemesis:~)$ cat
> /sys/devices/system/cpu/cpu1/topology/core_id 0
>
> (17:59:38:davej@nemesis:~)$ cat
> /sys/devices/system/cpu/cpu0/topology/core_siblings
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
> (17:59:47:davej@nemesis:~)$ cat
> /sys/devices/system/cpu/cpu1/topology/core_siblings
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002
>
> Neither of these CPUs are HT / dual-core, so shouldn't these be the same ?
It looks like a standard dual socket machine. Each CPU is a sibling of its own
only.
-Andi
In-Reply-To: <[email protected]>
On Wed, 1 Mar 2006 18:03:17, Dave Jones wrote:
> (17:59:38:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/core_siblings
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
> (17:59:47:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002
>
> Neither of these CPUs are HT / dual-core, so shouldn't these be the same ?
Those are bitmaps. 1 => only bit 0 is set => CPU 0 is all alone.
Did you really build a 256-CPU SMP kernel or is ACPI ignoring CONFIG_NR_CPUS
or something?
--
Chuck
"The sleet in Crete falls neatly in the street."
On Wed, Mar 01, 2006 at 07:55:25PM -0500, Chuck Ebbert wrote:
> In-Reply-To: <[email protected]>
>
> On Wed, 1 Mar 2006 18:03:17, Dave Jones wrote:
>
> > (17:59:38:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/core_siblings
> > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
> > (17:59:47:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
> > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002
> >
> > Neither of these CPUs are HT / dual-core, so shouldn't these be the same ?
>
> Those are bitmaps. 1 => only bit 0 is set => CPU 0 is all alone.
>
> Did you really build a 256-CPU SMP kernel or is ACPI ignoring CONFIG_NR_CPUS
> or something?
Yes, it's =256.
Dave
On Thu, Mar 02, 2006 at 01:55:46AM +0100, Andi Kleen wrote:
> On Thursday 02 March 2006 00:03, Dave Jones wrote:
> > On Wed, Mar 01, 2006 at 05:46:47PM -0500, Dave Jones wrote:
> > > This amused me.
> > >
> > > (17:43:34:davej@nemesis:~)$ ll /proc/acpi/processor/
> > > total 0
> > > dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU1/
> > > dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU2/
> > > dr-xr-xr-x 2 root root 0 Mar 1 17:43 CPU3/
> > > (17:43:36:davej@nemesis:~)$
> >
> > Digging further. I notice more oddities (or maybe I've just
> > misunderstood this -- corrections welcomed)
>
> Probably related to Ashok's ACPI CPU hotplug patches.
Could be..
SMP: Allowing 4 CPUs, 2 hotplug CPUs
I thought we chopped out the heuristic to do NRCPUS/2 as hotplug?
(*checks*... yes, we did).
This machine isn't hotplug cpu capable (its an early tyan 2885)
so I'd be surprised if the bios is advertising that ability.
It looks like 'num_processors' is incorrect somehow.
> What's the full bootup log?
below.
Dave
Bootdata ok (command line is ro root=/dev/hda2 vga=791 profile=1)
Linux version 2.6.15-1.1990_FC5 ([email protected]) (gcc version 4.1.0 20060219 (Red Hat 4.1.0-0.29)) #1 SMP Mon Feb 27 02:51:40 EST 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000e8ff0000 (usable)
BIOS-e820: 00000000e8ff0000 - 00000000e8fff000 (ACPI data)
BIOS-e820: 00000000e8fff000 - 00000000e9000000 (ACPI NVS)
BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 1 -> APIC 1 -> Node 1
SRAT: Node 0 PXM 0 100000-80000000
SRAT: Node 1 PXM 1 80000000-e9000000
SRAT: Node 1 PXM 1 80000000-100000000
SRAT: Node 0 PXM 0 0-80000000
Bootmem setup node 0 0000000000000000-0000000080000000
Bootmem setup node 1 0000000080000000-00000000e8ff0000
ACPI: PM-Timer IO Port: 0x5008
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfd9ff000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 17, address 0xfd9ff000, GSI 24-27
ACPI: IOAPIC (id[0x04] address[0xfd9fe000] gsi_base[28])
IOAPIC[2]: apic_id 4, version 17, address 0xfd9fe000, GSI 28-31
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Setting APIC routing to physical flat
ACPI: HPET id: 0x102282a0 base: 0xfec01000
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at ea000000 (gap: e9000000:16780000)
Checking aperture...
CPU 0: aperture @ f0000000 size 128 MB
CPU 1: aperture @ f0000000 size 128 MB
SMP: Allowing 4 CPUs, 2 hotplug CPUs
Built 2 zonelists
Kernel command line: ro root=/dev/hda2 vga=791 profile=1
kernel profiling enabled (shift: 1)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 14.318180 MHz WALL HPET GTOD HPET timer.
time.c: Detected 1789.412 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Memory: 3740452k/3817408k available (2320k kernel code, 76568k reserved, 1212k data, 196k init)
Calibrating delay using timer specific routine.. 3585.35 BogoMIPS (lpj=7170702)
Security Framework v1.0.0 initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(1) -> Node 0 -> Core 0
Using local APIC timer interrupts.
result 12426477
Detected 12.426 MHz APIC timer.
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 3578.59 BogoMIPS (lpj=7157190)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1(1) -> Node 1 -> Core 0
AMD Opteron(tm) Processor 244 stepping 08
CPU 1: Syncing TSC to CPU 0.
CPU 1: synchronized TSC with CPU 0 (last diff -8 cycles, maxerr 1033 cycles)
Brought up 2 CPUs
testing NMI watchdog ... OK.
migration_cost=467
checking if image is initramfs... it is
Freeing initrd memory: 1046k freed
DMI 2.3 present.
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)
ACPI: PCI Root Bridge [PCIB] (0000:04)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 15 devices
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
hpet0: at MMIO 0xfec01000 (virtual 0xffffffffff5fe000), IRQs 2, 8, 0
hpet0: 3 32-bit timers, 14318180 Hz
agpgart: Detected AMD 8151 AGP Bridge rev B2
agpgart: AGP aperture is 128M @ 0xf0000000
PCI-DMA: Disabling IOMMU.
pnp: 00:09: ioport range 0x680-0x6ff has been reserved
pnp: 00:09: ioport range 0x295-0x296 has been reserved
PCI: Bridge: 0000:00:06.0
IO window: a000-bfff
MEM window: fd700000-fd7fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0a.0
IO window: disabled.
MEM window: fd800000-fd8fffff
PREFETCH window: e9400000-e94fffff
PCI: Bridge: 0000:00:0b.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:04:01.0
IO window: disabled.
MEM window: fda00000-feafffff
PREFETCH window: e9600000-ed5fffff
IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
audit: initializing netlink socket (disabled)
audit(1141045958.664:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
SELinux: Registering netfilter hooks
Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 9A50E414E2E99FF
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI: MSI quirk detected. pci_msi_quirk set.
PCI: MSI quirk detected. pci_msi_quirk set.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
vesafb: framebuffer at 0xea000000, mapped to 0xffffc20000100000, using 3072k, total 32768k
vesafb: mode is 1024x768x16, linelength=2048, pages=9
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
ACPI: Processor [CPU1] (supports 8 throttling states)
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.101 (c) Dave Jones
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 controller doesn't have AUX irq; using default 12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: IDE controller at PCI slot 0000:00:07.1
AMD8111: chipset revision 3
AMD8111: not 100% native mode: will probe irqs later
AMD8111: 0000:00:07.1 (rev 03) UDMA133 controller
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: ST340014A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: HL-DT-STDVD-ROM GDR8162B, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
HPT370: IDE controller at PCI slot 0000:01:0a.0
GSI 16 sharing vector 0xA9 and IRQ 16
ACPI: PCI Interrupt 0000:01:0a.0[A] -> GSI 16 (level, low) -> IRQ 16
HPT370: chipset revision 3
HPT370: 100% native mode on irq 16
ide2: BM-DMA at 0xa800-0xa807, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xa808-0xa80f, BIOS settings: hdg:pio, hdh:pio
hde: IC35L080AVVA07-0, ATA DISK drive
ide2 at 0xbc00-0xbc07,0xb802 on irq 16
hdg: IC35L080AVVA07-0, ATA DISK drive
ide3 at 0xb400-0xb407,0xb002 on irq 16
hda: max request size: 512KiB
hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
hda: hda1 hda2 hda3
hde: max request size: 128KiB
hde: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=65535/16/63, UDMA(100)
hde: cache flushes supported
hde: hde1 hde2
hdg: max request size: 128KiB
hdg: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=65535/16/63, UDMA(100)
hdg: cache flushes supported
hdg: hdg1 hdg2
hdc: ATAPI 48X DVD-ROM drive, 256kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ide-floppy driver 0.99.newide
usbcore: registered new driver libusual
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 131072 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
powernow-k8: Power state transitions not supported
powernow-k8: Power state transitions not supported
input: AT Translated Set 2 keyboard as /class/input/input0
ACPI wakeup devices:
PCI1 USB0 USB1 PS2K UAR1 UAR2 GOLA GLAN GOLB SMBC AC97 MODM PWRB
ACPI: (supports S0 S1 S4 S5)
Freeing unused kernel memory: 196k freed
Write protecting the kernel read-only data: 435k
SCSI subsystem initialized
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
security: 3 users, 6 roles, 1135 types, 133 bools, 1 sens, 256 cats
security: 55 classes, 37676 rules
SELinux: Completing initialization.
SELinux: Setting up existing superblocks.
SELinux: initialized (dev hda2, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts
SELinux: initialized (dev devpts, type devpts), uses transition SIDs
SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts
SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
SELinux: initialized (dev cpuset, type cpuset), not configured for labeling
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
matroxfb: Matrox G550 detected
matroxfb: probe of 0000:05:00.0 failed with error -1
tg3.c:v3.49 (Feb 2, 2006)
GSI 17 sharing vector 0xB1 and IRQ 17
ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 24 (level, low) -> IRQ 17
eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCI:66MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:29:93:fe
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[763f0000]
GSI 18 sharing vector 0xB9 and IRQ 18
ACPI: PCI Interrupt 0000:01:00.0[D] -> GSI 19 (level, low) -> IRQ 18
ohci_hcd 0000:01:00.0: OHCI Host Controller
ohci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:01:00.0: irq 18, io mem 0xfd7de000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ACPI: PCI Interrupt 0000:01:00.1[D] -> GSI 19 (level, low) -> IRQ 18
ohci_hcd 0000:01:00.1: OHCI Host Controller
ohci_hcd 0000:01:00.1: new USB bus registered, assigned bus number 2
ohci_hcd 0000:01:00.1: irq 18, io mem 0xfd7df000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
GSI 19 sharing vector 0xC1 and IRQ 19
ACPI: PCI Interrupt 0000:02:07.0[A] -> GSI 26 (level, low) -> IRQ 19
ohci_hcd 0000:02:07.0: OHCI Host Controller
ohci_hcd 0000:02:07.0: new USB bus registered, assigned bus number 3
ohci_hcd 0000:02:07.0: irq 19, io mem 0xfd8fd000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
usb 2-2: new low speed USB device using ohci_hcd and address 2
usb 2-2: configuration #1 chosen from 1 choice
input: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM) as /class/input/input1
input: USB HID v1.10 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)] on usb-0000:01:00.1-2
GSI 20 sharing vector 0xC9 and IRQ 20
ACPI: PCI Interrupt 0000:02:07.1[B] -> GSI 27 (level, low) -> IRQ 20
ohci_hcd 0000:02:07.1: OHCI Host Controller
ohci_hcd 0000:02:07.1: new USB bus registered, assigned bus number 4
ohci_hcd 0000:02:07.1: irq 20, io mem 0xfd8fe000
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:02:07.2[C] -> GSI 24 (level, low) -> IRQ 17
ehci_hcd 0000:02:07.2: EHCI Host Controller
ehci_hcd 0000:02:07.2: new USB bus registered, assigned bus number 5
ehci_hcd 0000:02:07.2: irq 17, io mem 0xfd8ffc00
ehci_hcd 0000:02:07.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 5 ports detected
GSI 21 sharing vector 0xD1 and IRQ 21
ACPI: PCI Interrupt 0000:00:07.5[B] -> GSI 17 (level, low) -> IRQ 21
intel8x0_measure_ac97_clock: measured 58085 usecs
intel8x0: clocking to 48000
hw_random: AMD768 system management I/O registers at 0x5000.
hw_random hardware driver 1.0.0 loaded
Non-volatile memory driver v1.2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
lp: driver loaded but no devices found
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ibm_acpi: ec object not found
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
md: md0 stopped.
md: bind<hdg2>
md: bind<hde2>
md: raid0 personality registered for level 0
md0: setting max_sectors to 128, segment boundary to 32767
raid0: looking at hde2
raid0: comparing hde2(79440896) with hde2(79440896)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at hdg2
raid0: comparing hdg2(79440896) with hde2(79440896)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 158881792 blocks.
raid0 : conf->hash_spacing is 158881792 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 8 bytes for hash.
device-mapper: 4.5.0-ioctl (2005-10-04) initialised: [email protected]
EXT3 FS on hda2, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: initialized (dev hda1, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on md0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: initialized (dev md0, type ext3), uses xattr
audit(1141063982.492:2): avc: denied { write } for pid=1421 comm="swapon" name="blkid.tab" dev=hda2 ino=3555770 scontext=system_u:system_r:fsadm_t:s0 tcontext=user_u:object_r:etc_t:s0 tclass=file
Adding 2040244k swap on /dev/hda3. Priority:-1 extents:1 across:2040244k
audit(1141063982.508:3): avc: denied { write } for pid=1421 comm="swapon" name="blkid.tab" dev=hda2 ino=3555770 scontext=system_u:system_r:fsadm_t:s0 tcontext=user_u:object_r:etc_t:s0 tclass=file
Adding 977216k swap on /dev/hde1. Priority:-2 extents:1 across:977216k
audit(1141063982.528:4): avc: denied { write } for pid=1421 comm="swapon" name="blkid.tab" dev=hda2 ino=3555770 scontext=system_u:system_r:fsadm_t:s0 tcontext=user_u:object_r:etc_t:s0 tclass=file
Adding 977216k swap on /dev/hdg1. Priority:-3 extents:1 across:977216k
SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
Installing knfsd (copyright (C) 1996 [email protected]).
SELinux: initialized (dev nfsd, type nfsd), uses genfs_contexts
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: unable to find recovery directory /var/lib/nfs/v4recovery
NFSD: starting 90-second grace period
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> Processor #0 15:5 APIC version 16
> ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> Processor #1 15:5 APIC version 16
> ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
> ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
It's because of the two disabled CPUs. We decreed at some point
that disabled CPUs mean hotpluggable CPUs. But it's doing
this for some time so you probably only noticed now.
All is ok. Sorry for blaming you wrongly, Ashok.
-Andi
On Thu, Mar 02, 2006 at 02:38:31AM +0100, Andi Kleen wrote:
>
> > ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> > Processor #0 15:5 APIC version 16
> > ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> > Processor #1 15:5 APIC version 16
> > ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
> > ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
>
> It's because of the two disabled CPUs. We decreed at some point
> that disabled CPUs mean hotpluggable CPUs. But it's doing
> this for some time so you probably only noticed now.
*boggle*, there really are only two single-core CPUs in there,
with no empty sockets. It's an early stepping of the motherboard
too that supposedly doesn't support dual-core. So why these are present
at all, let alone 'disabled' is a mystery to me.
logrotate ate the old logs, so I don't have any old bootlogs
to grep through, but I'll take your word for it :)
Why ACPI decides to create 3 processor entries is still odd though.
Dave
On Thursday 02 March 2006 04:13, Dave Jones wrote:
> *boggle*, there really are only two single-core CPUs in there,
> with no empty sockets. It's an early stepping of the motherboard
> too that supposedly doesn't support dual-core. So why these are present
> at all, let alone 'disabled' is a mystery to me.
It's probably for the second cores. Instead of rewriting the tables
dynamically they just change the enable/disable bit. That's pretty
common actually, often seen on laptops too.
With Quadcores it will get interesting I guess.
If you had to write in 16bit x86 asm you would likely use such
tricks too ;-)
> logrotate ate the old logs, so I don't have any old bootlogs
> to grep through, but I'll take your word for it :)
>
> Why ACPI decides to create 3 processor entries is still odd though.
It should be four.
-Andi
On Thu, Mar 02, 2006 at 04:24:41AM +0100, Andi Kleen wrote:
> > Why ACPI decides to create 3 processor entries is still odd though.
>
> It should be four.
Then I guess the ACPI guys have an off-by-one bug somewhere ;)
Dave
On Thu, Mar 02, 2006 at 02:38:31AM +0100, Andi Kleen wrote:
>
> > ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> > Processor #0 15:5 APIC version 16
> > ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> > Processor #1 15:5 APIC version 16
> > ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
> > ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
>
> It's because of the two disabled CPUs. We decreed at some point
> that disabled CPUs mean hotpluggable CPUs. But it's doing
> this for some time so you probably only noticed now.
>
> All is ok. Sorry for blaming you wrongly, Ashok.
Phew!..
The ACPI hotplug code isnt in 2.6.15-rc* yet. It should be in the next
-mm when Andrew rolls the next mm.
But the 3 entries seem weird, we should only see 2 sysfs entries in
/sys/devices/system/cpu and just 2 entries in proc/acpi/processor as well.
--
Cheers,
Ashok Raj
- Open Source Technology Center
On Wed, Mar 01, 2006 at 07:52:19PM -0800, Ashok Raj wrote:
> On Thu, Mar 02, 2006 at 02:38:31AM +0100, Andi Kleen wrote:
> >
> > > ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> > > Processor #0 15:5 APIC version 16
> > > ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> > > Processor #1 15:5 APIC version 16
> > > ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
> > > ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
> >
> > It's because of the two disabled CPUs. We decreed at some point
> > that disabled CPUs mean hotpluggable CPUs. But it's doing
> > this for some time so you probably only noticed now.
> >
> > All is ok. Sorry for blaming you wrongly, Ashok.
>
>
> Phew!..
>
> The ACPI hotplug code isnt in 2.6.15-rc* yet. It should be in the next
> -mm when Andrew rolls the next mm.
>
> But the 3 entries seem weird, we should only see 2 sysfs entries in
> /sys/devices/system/cpu and just 2 entries in proc/acpi/processor as well.
sysfs gets it right.
(23:11:01:davej@nemesis:~)$ ls /sys/devices/system/cpu/
cpu0/ cpu1/
(23:11:07:davej@nemesis:~)$ ls /proc/acpi/processor/
CPU1/ CPU2/ CPU3/
(23:11:11:davej@nemesis:~)$
Dave
>sysfs gets it right.
>
>(23:11:01:davej@nemesis:~)$ ls /sys/devices/system/cpu/
>cpu0/ cpu1/
>(23:11:07:davej@nemesis:~)$ ls /proc/acpi/processor/
>CPU1/ CPU2/ CPU3/
This is because the BIOS has three "Processor" objects in the DSDT.
As I've mentioned before, /proc/acpi/*/* should not exist.
Internal ACPI BIOS names "CPU1, CPU1, CPU3" in this case
are actually arbitray 4-character strings, and should
never be exposed to the user in the file-system.
sysfs with cpu0, cpu1 -- predictable strings for objects --
gets it right, and is the direction we are going.
I'm afraid that even after we get this stuff out of /proc
and into sysfs where it belongs, we'll have to leave /proc/acpi around
for a while b/c unfortunately people are under the impression
that the path names there actually mean something and
they can actually count on them -- which they can't.
-Len
Please bear with me for jumping in this thread, but I have a related
question:
On Thu, Mar 02, 2006 at 12:49:53AM -0500, Brown, Len wrote:
>
> I'm afraid that even after we get this stuff out of /proc
> and into sysfs where it belongs, we'll have to leave /proc/acpi around
> for a while b/c unfortunately people are under the impression
> that the path names there actually mean something and
> they can actually count on them -- which they can't.
Is it possible to obtain the same control/information with sysfs that is
available from /proc/acpi? For example, I use quite extensively CPU
throttling on my VAIO ("cool & quiet home-made mode"), and I was unable to
find the equivalent of /proc/acpi/processor/CPU0/throttling ...
Thanks,
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
http://www.dea.icai.upcomillas.es/romano/
--
La presente comunicaci?n tiene car?cter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribuci?n, reproducci?n o uso de esta comunicaci?n y/o de la informaci?n contenida en la misma est?n estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicaci?n por error, por favor, notif?quelo inmediatamente al remitente contestando a este mensaje y proceda a continuaci?n a destruirlo. Gracias por su colaboraci?n.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.
On Thursday 02 March 2006 06:49, Brown, Len wrote:
> I'm afraid that even after we get this stuff out of /proc
> and into sysfs where it belongs, we'll have to leave /proc/acpi around
> for a while b/c unfortunately people are under the impression
> that the path names there actually mean something and
> they can actually count on them -- which they can't.
But they should. Once you provide an interface here you
have to provide it essentially forever. Or at least if you really
change it use a very long deprecation period, but even that
is a bad thing to do to users.
-Andi
On Thu, 2 Mar 2006, Romano Giannetti wrote:
> On Thu, Mar 02, 2006 at 12:49:53AM -0500, Brown, Len wrote:
> >
> > I'm afraid that even after we get this stuff out of /proc
> > and into sysfs where it belongs, we'll have to leave /proc/acpi around
> > for a while b/c unfortunately people are under the impression
> > that the path names there actually mean something and
> > they can actually count on them -- which they can't.
>
> Is it possible to obtain the same control/information with sysfs that is
> available from /proc/acpi? For example, I use quite extensively CPU
> throttling on my VAIO ("cool & quiet home-made mode"), and I was unable to
> find the equivalent of /proc/acpi/processor/CPU0/throttling ...
I can't help thinking that that should be going through cpufreq.
On Thu, Mar 02, 2006 at 07:53:39AM -0800, Zwane Mwaikambo wrote:
> On Thu, 2 Mar 2006, Romano Giannetti wrote:
>
> > On Thu, Mar 02, 2006 at 12:49:53AM -0500, Brown, Len wrote:
> > >
> > > I'm afraid that even after we get this stuff out of /proc
> > > and into sysfs where it belongs, we'll have to leave /proc/acpi around
> > > for a while b/c unfortunately people are under the impression
> > > that the path names there actually mean something and
> > > they can actually count on them -- which they can't.
> >
> > Is it possible to obtain the same control/information with sysfs that is
> > available from /proc/acpi? For example, I use quite extensively CPU
> > throttling on my VAIO ("cool & quiet home-made mode"), and I was unable to
> > find the equivalent of /proc/acpi/processor/CPU0/throttling ...
>
> I can't help thinking that that should be going through cpufreq.
Yes, I agree. But in the relevant /sys/devices/system/cpu/cpu0/cpufreq there
were no "throttling" options (well: as of 2.6.11). Maybe it's something
failing in my old vaio fx701, but scaling down frequencies is not sufficient
to keep it cool (compiling a kernel in summer in Madrid without air
conditioning reliably triggers thermal shutdown if I do not throttle the CPU
at level 4 when overheating; I have a little python script running for it).
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
http://www.dea.icai.upcomillas.es/romano/
--
La presente comunicaci?n tiene car?cter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribuci?n, reproducci?n o uso de esta comunicaci?n y/o de la informaci?n contenida en la misma est?n estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicaci?n por error, por favor, notif?quelo inmediatamente al remitente contestando a este mensaje y proceda a continuaci?n a destruirlo. Gracias por su colaboraci?n.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.
On Wed, Mar 01, 2006 at 09:49:53PM -0800, Brown, Len wrote:
>
> >sysfs gets it right.
> >
> >(23:11:01:davej@nemesis:~)$ ls /sys/devices/system/cpu/
> >cpu0/ cpu1/
> >(23:11:07:davej@nemesis:~)$ ls /proc/acpi/processor/
> >CPU1/ CPU2/ CPU3/
>
> This is because the BIOS has three "Processor" objects in the DSDT.
>
I have a dual core + HT platform. I disabled HT to have the same situation
as Dave.
ACPI DSDT dump shows 4 objects in \_PR scope as below.
Scope (\_PR)
{
Processor (CPU0, 0x01, 0x00000410, 0x06) {}
Processor (CPU1, 0x02, 0x00000410, 0x06) {}
Processor (CPU2, 0x03, 0x00000410, 0x06) {}
Processor (CPU3, 0x04, 0x00000410, 0x06) {}
}
Only 2 are marked enabled in the ACPI MADT..
>From boot log
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
Processor #2 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled)
But proc/acpi/processor also lists just 2 entries.
[root@araj-sfield-2 tmp]# ls /proc/acpi/processor/
CPU0 CPU2
I suspect that the BIOS is goofy and sending a valid acpiid when we try
to evaluate the processor object.
Could you see what comes out of the /proc/acpi/processor/CPUx/info for all the
3 listed in your system?
Also if you can send DSDT dump just to look over.
Cheers,
ashok
>On Thursday 02 March 2006 06:49, Brown, Len wrote:
>
>> I'm afraid that even after we get this stuff out of /proc
>> and into sysfs where it belongs, we'll have to leave
>/proc/acpi around
>> for a while b/c unfortunately people are under the impression
>> that the path names there actually mean something and
>> they can actually count on them -- which they can't.
>
>But they should. Once you provide an interface here you
>have to provide it essentially forever. Or at least if you really
>change it use a very long deprecation period, but even that
>is a bad thing to do to users.
The 4-character strings in the path names (eg "CPU0") are _arbitrary_.
They come _directly_ from the BIOS source code and depend
on whatever mood the BIOS writer was in that day.
For this reason, users _can't_ count on these strings
and these path-names being consistent across platforms.
Yes, this is a horrible design.
Yes, I want to delete it in favor of sysfs as soon as possible,
Patrick has a big patch set in development to get that ball rolling.
Yes, users kick and scream whenever you change something they can see
and thus it takes a long time.
-Len
>I have a dual core + HT platform. I disabled HT to have the
>same situation as Dave.
>
>ACPI DSDT dump shows 4 objects in \_PR scope as below.
>
> Scope (\_PR)
> {
> Processor (CPU0, 0x01, 0x00000410, 0x06) {}
> Processor (CPU1, 0x02, 0x00000410, 0x06) {}
> Processor (CPU2, 0x03, 0x00000410, 0x06) {}
> Processor (CPU3, 0x04, 0x00000410, 0x06) {}
> }
>
>Only 2 are marked enabled in the ACPI MADT..
>
>From boot log
>
>ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
>Processor #0 15:4 APIC version 20
>ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
>Processor #2 15:4 APIC version 20
>ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled)
>ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled)
>
>But proc/acpi/processor also lists just 2 entries.
We were certainly on safer ground when we used
to completely ignore disabled entries.
-Len
On Thu, Mar 02, 2006 at 08:30:38AM -0800, Ashok Raj wrote:
> Could you see what comes out of the /proc/acpi/processor/CPUx/info for all the
> 3 listed in your system?
I thought I already posted that..
(13:43:44:davej@nemesis:~)$ cat /proc/acpi/processor/CPU*/info
processor id: 0
acpi id: 1
bus mastering control: no
power management: no
throttling control: yes
limit interface: yes
processor id: 1
acpi id: 2
bus mastering control: no
power management: no
throttling control: no
limit interface: no
processor id: 255
acpi id: 3
bus mastering control: no
power management: no
throttling control: no
limit interface: no
> Also if you can send DSDT dump just to look over.
http://people.redhat.com/davej/dsdt
Dave
> /proc/acpi/processor/CPU0/throttling
Yes, the generic layer should expose throttling.
But before it does so, it needs to learn that T-states
have very different implications from P-states.
Indeed it is a bug in the current architecture that
P-states are exposed by cpufreq on some systems,
and T-states are exposed on other systems, and
they are treated like they are the same.
It is also bug that T-states are exposed
on some systems, while ACPI is simultaneously
assuming exclusive access to them for thermal throttling.
-Len
>I have a dual core + HT platform. I disabled HT to have the
>same situation as Dave.
>
>ACPI DSDT dump shows 4 objects in \_PR scope as below.
>
> Scope (\_PR)
> {
> Processor (CPU0, 0x01, 0x00000410, 0x06) {}
> Processor (CPU1, 0x02, 0x00000410, 0x06) {}
> Processor (CPU2, 0x03, 0x00000410, 0x06) {}
> Processor (CPU3, 0x04, 0x00000410, 0x06) {}
> }
>
>Only 2 are marked enabled in the ACPI MADT..
>
>From boot log
>
>ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
>Processor #0 15:4 APIC version 20
>ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
>Processor #2 15:4 APIC version 20
>ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled)
>ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled)
>
>But proc/acpi/processor also lists just 2 entries.
>
>[root@araj-sfield-2 tmp]# ls /proc/acpi/processor/
>CPU0 CPU2
This system looks totally correct to me.
Do you see something wrong with it?
-Len
On Thu, Mar 02, 2006 at 01:44:28PM -0500, Dave Jones wrote:
> I thought I already posted that..
>
Sorry.. i noticed it later...
I think the problem is the return type u8, and -1 being treated as error
return.
You probably missed the warning that flew by...
could you check if the attached patch works for you?
--
Cheers,
Ashok Raj
- Open Source Technology Center
Local apic entries are only 8 bits, but it seemed to not be caught with
u8 return value result in the check
cpu_index >= NR_CPUS becomming always false.
drivers/acpi/processor_core.c: In function `acpi_processor_get_info':
drivers/acpi/processor_core.c:483: warning: comparison is always false due to limited range of data type
Signed-off-by: Ashok Raj <[email protected]>
-----------------------------------------------------
drivers/acpi/processor_core.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.16-rc5-mm1/drivers/acpi/processor_core.c
===================================================================
--- linux-2.6.16-rc5-mm1.orig/drivers/acpi/processor_core.c
+++ linux-2.6.16-rc5-mm1/drivers/acpi/processor_core.c
@@ -395,7 +395,7 @@ static int acpi_processor_remove_fs(stru
#define ARCH_BAD_APICID (0xff)
#endif
-static u8 convert_acpiid_to_cpu(u8 acpi_id)
+static int convert_acpiid_to_cpu(u8 acpi_id)
{
u16 apic_id;
int i;
@@ -421,7 +421,7 @@ static int acpi_processor_get_info(struc
acpi_status status = 0;
union acpi_object object = { 0 };
struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
- u8 cpu_index;
+ int cpu_index;
static int cpu0_initialized;
ACPI_FUNCTION_TRACE("acpi_processor_get_info");
@@ -466,7 +466,7 @@ static int acpi_processor_get_info(struc
cpu_index = convert_acpiid_to_cpu(pr->acpi_id);
/* Handle UP system running SMP kernel, with no LAPIC in MADT */
- if (!cpu0_initialized && (cpu_index == 0xff) &&
+ if (!cpu0_initialized && (cpu_index == -1) &&
(num_online_cpus() == 1)) {
cpu_index = 0;
}
@@ -480,7 +480,7 @@ static int acpi_processor_get_info(struc
* less than the max # of CPUs. They should be ignored _iff
* they are physically not present.
*/
- if (cpu_index >= NR_CPUS) {
+ if (cpu_index == -1) {
if (ACPI_FAILURE
(acpi_processor_hotadd_init(pr->handle, &pr->id))) {
ACPI_ERROR((AE_INFO,
Dave,
Your DSDT looks fine.
I was wrong assuming there were 3 Processor entries there.
> > Did you really build a 256-CPU SMP kernel or is ACPI
> > ignoring CONFIG_NR_CPUS or something?
>
>Yes, it's =256.
I expect this is the root problem.
-Len
On Thursday 02 March 2006 20:26, Brown, Len wrote:
> Dave,
> Your DSDT looks fine.
> I was wrong assuming there were 3 Processor entries there.
>
> > > Did you really build a 256-CPU SMP kernel or is ACPI
> > > ignoring CONFIG_NR_CPUS or something?
> >
> >Yes, it's =256.
>
> I expect this is the root problem.
It's useless anyways because the x86 apics cannot handle more than
255. Best fix is probably just the appended one. Does that fix the
issue?
i386 already had it correct BTW.
-Andi
Limit max number of CPUs to 255
Because 256 causes overflows in some code that stores them in 8 bit
fields and the x86 APIC architecture cannot handle more than 255
anyways.
Signed-off-by: Andi Kleen <[email protected]>
Index: linux/arch/x86_64/Kconfig
===================================================================
--- linux.orig/arch/x86_64/Kconfig
+++ linux/arch/x86_64/Kconfig
@@ -323,7 +323,7 @@ config HAVE_ARCH_EARLY_PFN_TO_NID
config NR_CPUS
int "Maximum number of CPUs (2-256)"
- range 2 256
+ range 2 255
depends on SMP
default "8"
help
On Thu, Mar 02, 2006 at 02:26:24PM -0500, Brown, Len wrote:
> Dave,
> Your DSDT looks fine.
> I was wrong assuming there were 3 Processor entries there.
>
> > > Did you really build a 256-CPU SMP kernel or is ACPI
> > > ignoring CONFIG_NR_CPUS or something?
> >
> >Yes, it's =256.
>
> I expect this is the root problem.
If this is the _cause_, something needs fixing, but it's hardly
something we can brush off as 'the root problem'.
It's entirely possible for such a configuration (higher
CONFIG_NR_CPUS than actual cpus), cf. distro kernels.
Dave
>On Thu, Mar 02, 2006 at 02:26:24PM -0500, Brown, Len wrote:
> > Dave,
> > Your DSDT looks fine.
> > I was wrong assuming there were 3 Processor entries there.
> >
> > > > Did you really build a 256-CPU SMP kernel or is ACPI
> > > > ignoring CONFIG_NR_CPUS or something?
> > >
> > >Yes, it's =256.
> >
> > I expect this is the root problem.
>
>If this is the _cause_, something needs fixing, but it's hardly
>something we can brush off as 'the root problem'.
>
>It's entirely possible for such a configuration (higher
>CONFIG_NR_CPUS than actual cpus), cf. distro kernels.
I agree.
Did Ashok's sigined-unsigned patch work?
Ashok Raj <[email protected]> wrote:
>
> Local apic entries are only 8 bits, but it seemed to not be caught with
> u8 return value result in the check
>
> cpu_index >= NR_CPUS becomming always false.
>
> drivers/acpi/processor_core.c: In function `acpi_processor_get_info':
> drivers/acpi/processor_core.c:483: warning: comparison is always false due to limited range of data type
>
>
> Signed-off-by: Ashok Raj <[email protected]>
> -----------------------------------------------------
> drivers/acpi/processor_core.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> Index: linux-2.6.16-rc5-mm1/drivers/acpi/processor_core.c
> ===================================================================
> --- linux-2.6.16-rc5-mm1.orig/drivers/acpi/processor_core.c
> +++ linux-2.6.16-rc5-mm1/drivers/acpi/processor_core.c
> @@ -395,7 +395,7 @@ static int acpi_processor_remove_fs(stru
> #define ARCH_BAD_APICID (0xff)
> #endif
>
> -static u8 convert_acpiid_to_cpu(u8 acpi_id)
> +static int convert_acpiid_to_cpu(u8 acpi_id)
> {
> u16 apic_id;
> int i;
> @@ -421,7 +421,7 @@ static int acpi_processor_get_info(struc
> acpi_status status = 0;
> union acpi_object object = { 0 };
> struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
> - u8 cpu_index;
> + int cpu_index;
> static int cpu0_initialized;
>
> ACPI_FUNCTION_TRACE("acpi_processor_get_info");
> @@ -466,7 +466,7 @@ static int acpi_processor_get_info(struc
> cpu_index = convert_acpiid_to_cpu(pr->acpi_id);
>
> /* Handle UP system running SMP kernel, with no LAPIC in MADT */
> - if (!cpu0_initialized && (cpu_index == 0xff) &&
> + if (!cpu0_initialized && (cpu_index == -1) &&
> (num_online_cpus() == 1)) {
> cpu_index = 0;
> }
> @@ -480,7 +480,7 @@ static int acpi_processor_get_info(struc
> * less than the max # of CPUs. They should be ignored _iff
> * they are physically not present.
> */
> - if (cpu_index >= NR_CPUS) {
> + if (cpu_index == -1) {
> if (ACPI_FAILURE
> (acpi_processor_hotadd_init(pr->handle, &pr->id))) {
> ACPI_ERROR((AE_INFO,
On a uniprocessor build this causes a crash in acpi_processor_start():
BUG_ON((pr->id >= NR_CPUS) || (pr->id < 0));
pr->id is 255.
I could bodge around this in various ways, but the semantics of cpu IDs in
there seem to be a bit opaque, and I suspect some more thought needs to go
into it all.
As well as uniprocessor testing ;)
On Thu, Mar 02, 2006 at 11:14:52PM -0800, Andrew Morton wrote:
> On a uniprocessor build this causes a crash in acpi_processor_start():
>
> BUG_ON((pr->id >= NR_CPUS) || (pr->id < 0));
>
> pr->id is 255.
>
> I could bodge around this in various ways, but the semantics of cpu IDs in
> there seem to be a bit opaque, and I suspect some more thought needs to go
> into it all.
>
> As well as uniprocessor testing ;)
The UP definition of convert_acpiid_to_cpu() was left as (0xff), i should
have converted that to (-1) now that its an "int".
Here is the updated one, this time i also testbooted the UP kernel. :-)
--
Cheers,
Ashok Raj
- Open Source Technology Center
Local apic entries are only 8 bits, but it seemed to not be caught with
u8 return value result in the check
cpu_index >= NR_CPUS becomming always false.
drivers/acpi/processor_core.c: In function `acpi_processor_get_info':
drivers/acpi/processor_core.c:483: warning: comparison is always false due to limited range of data type
Signed-off-by: Ashok Raj <[email protected]>
-----------------------------------------------------
drivers/acpi/processor_core.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6.16-rc5-mm1/drivers/acpi/processor_core.c
===================================================================
--- linux-2.6.16-rc5-mm1.orig/drivers/acpi/processor_core.c
+++ linux-2.6.16-rc5-mm1/drivers/acpi/processor_core.c
@@ -382,7 +382,7 @@ static int acpi_processor_remove_fs(stru
/* Use the acpiid in MADT to map cpus in case of SMP */
#ifndef CONFIG_SMP
-#define convert_acpiid_to_cpu(acpi_id) (0xff)
+#define convert_acpiid_to_cpu(acpi_id) (-1)
#else
#ifdef CONFIG_IA64
@@ -395,7 +395,7 @@ static int acpi_processor_remove_fs(stru
#define ARCH_BAD_APICID (0xff)
#endif
-static u8 convert_acpiid_to_cpu(u8 acpi_id)
+static int convert_acpiid_to_cpu(u8 acpi_id)
{
u16 apic_id;
int i;
@@ -421,7 +421,7 @@ static int acpi_processor_get_info(struc
acpi_status status = 0;
union acpi_object object = { 0 };
struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
- u8 cpu_index;
+ int cpu_index;
static int cpu0_initialized;
ACPI_FUNCTION_TRACE("acpi_processor_get_info");
@@ -466,7 +466,7 @@ static int acpi_processor_get_info(struc
cpu_index = convert_acpiid_to_cpu(pr->acpi_id);
/* Handle UP system running SMP kernel, with no LAPIC in MADT */
- if (!cpu0_initialized && (cpu_index == 0xff) &&
+ if (!cpu0_initialized && (cpu_index == -1) &&
(num_online_cpus() == 1)) {
cpu_index = 0;
}
@@ -480,7 +480,7 @@ static int acpi_processor_get_info(struc
* less than the max # of CPUs. They should be ignored _iff
* they are physically not present.
*/
- if (cpu_index >= NR_CPUS) {
+ if (cpu_index == -1) {
if (ACPI_FAILURE
(acpi_processor_hotadd_init(pr->handle, &pr->id))) {
ACPI_ERROR((AE_INFO,
Dave Jones <[email protected]> wrote:
>
> On Wed, Mar 01, 2006 at 07:55:25PM -0500, Chuck Ebbert wrote:
> > In-Reply-To: <[email protected]>
> >
> > On Wed, 1 Mar 2006 18:03:17, Dave Jones wrote:
> >
> > > (17:59:38:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/core_siblings
> > > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
> > > (17:59:47:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
> > > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002
> > >
> > > Neither of these CPUs are HT / dual-core, so shouldn't these be the same ?
> >
> > Those are bitmaps. 1 => only bit 0 is set => CPU 0 is all alone.
> >
> > Did you really build a 256-CPU SMP kernel or is ACPI ignoring CONFIG_NR_CPUS
> > or something?
>
> Yes, it's =256.
>
Is that the only way in which to trigger the bug?
If so, I'd be inclined to hold the fix back for 2.6.17.
From: Ashok Raj <[email protected]>
Local apic entries are only 8 bits, but it seemed to not be caught with u8
return value result in the check cpu_index >= NR_CPUS becomming always false.
drivers/acpi/processor_core.c: In function `acpi_processor_get_info':
drivers/acpi/processor_core.c:483: warning: comparison is always false due to limited range of data type
Signed-off-by: Ashok Raj <[email protected]>
Cc: "Brown, Len" <[email protected]>
Cc: Dave Jones <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
drivers/acpi/processor_core.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff -puN drivers/acpi/processor_core.c~acpi-signedness-fix-2 drivers/acpi/processor_core.c
--- 25/drivers/acpi/processor_core.c~acpi-signedness-fix-2 Fri Mar 3 16:25:09 2006
+++ 25-akpm/drivers/acpi/processor_core.c Fri Mar 3 16:25:09 2006
@@ -382,7 +382,7 @@ static int acpi_processor_remove_fs(stru
/* Use the acpiid in MADT to map cpus in case of SMP */
#ifndef CONFIG_SMP
-#define convert_acpiid_to_cpu(acpi_id) (0xff)
+#define convert_acpiid_to_cpu(acpi_id) (-1)
#else
#ifdef CONFIG_IA64
@@ -395,7 +395,7 @@ static int acpi_processor_remove_fs(stru
#define ARCH_BAD_APICID (0xff)
#endif
-static u8 convert_acpiid_to_cpu(u8 acpi_id)
+static int convert_acpiid_to_cpu(u8 acpi_id)
{
u16 apic_id;
int i;
@@ -421,7 +421,7 @@ static int acpi_processor_get_info(struc
acpi_status status = 0;
union acpi_object object = { 0 };
struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
- u8 cpu_index;
+ int cpu_index;
static int cpu0_initialized;
ACPI_FUNCTION_TRACE("acpi_processor_get_info");
@@ -466,7 +466,7 @@ static int acpi_processor_get_info(struc
cpu_index = convert_acpiid_to_cpu(pr->acpi_id);
/* Handle UP system running SMP kernel, with no LAPIC in MADT */
- if (!cpu0_initialized && (cpu_index == 0xff) &&
+ if (!cpu0_initialized && (cpu_index == -1) &&
(num_online_cpus() == 1)) {
cpu_index = 0;
}
@@ -480,7 +480,7 @@ static int acpi_processor_get_info(struc
* less than the max # of CPUs. They should be ignored _iff
* they are physically not present.
*/
- if (cpu_index >= NR_CPUS) {
+ if (cpu_index == -1) {
if (ACPI_FAILURE
(acpi_processor_hotadd_init(pr->handle, &pr->id))) {
ACPI_ERROR((AE_INFO,
_
On Sat, Mar 04, 2006 at 04:42:38PM -0800, Andrew Morton wrote:
> Dave Jones <[email protected]> wrote:
> >
> > On Wed, Mar 01, 2006 at 07:55:25PM -0500, Chuck Ebbert wrote:
> > > In-Reply-To: <[email protected]>
> > >
> > > On Wed, 1 Mar 2006 18:03:17, Dave Jones wrote:
> > >
> > > > (17:59:38:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/core_siblings
> > > > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
> > > > (17:59:47:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
> > > > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002
> > > >
> > > > Neither of these CPUs are HT / dual-core, so shouldn't these be the same ?
> > >
> > > Those are bitmaps. 1 => only bit 0 is set => CPU 0 is all alone.
> > >
> > > Did you really build a 256-CPU SMP kernel or is ACPI ignoring CONFIG_NR_CPUS
> > > or something?
> >
> > Yes, it's =256.
> >
>
> Is that the only way in which to trigger the bug?
>
> If so, I'd be inclined to hold the fix back for 2.6.17.
not had chance to test Ashok's change yet (and probably won't until
at least Monday), but Andi's one-liner to limit x86-64's NR_CPUs
to 255 instead of 256 did the trick, and is a lot less invasive
for 2.6.16
Dave