Bug 169700 - Badness in send_IPI_mask_bitmask at shutdown
Badness in send_IPI_mask_bitmask at shutdown
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-01 11:28 EDT by jmw
Modified: 2015-01-04 17:22 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-16 21:16:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg for boot option acpi=off (13.11 KB, text/plain)
2005-12-16 10:29 EST, jmw
no flags Details
1653 dmesg for no additional boot options (15.53 KB, text/plain)
2005-12-16 10:31 EST, jmw
no flags Details

  None (edit)
Description jmw 2005-10-01 11:28:33 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 Fedora/1.7.12-1.5.1

Description of problem:
2.6.13-1526_FC4smp appears to start and run normally.  on shutdown, everything appears normal until the line "Power down.", then i see line after line of some kind of core dump.  text seems to indicate this is related to a "line 164" of "...kernel/smp.c".  i've never de-bugged this kind of thing, and don't yet know what it means.  a text description follows, below.

the problem does not occur with kernel-2.6.13-1526_FC4 (not smp), and does not occur with earlier versions of the smp kernel.  there has not been any other change to this machine, prior to installation of the 1526smp kernel.

Version-Release number of selected component (if applicable):
kernel-smp-2.6.13-1.1526_FC4

How reproducible:
Always

Steps to Reproduce:
1. boot to the smp kernel, run for any length of time
2. click on 'logout' in a genome panel
3. choose 'shutdown' from the menu
  

Actual Results:  kernel (?) throws some kind of core dump, after the line "Power down" and machine remains on, but becomes unresponsive.

Expected Results:  machine should halt, no other activity dumped to screen.

Additional info:

this is what i am able to transcribe, from the most recent event:

[...stopping processes, turning things off...]

Turning off swap:		[  OK  ]
Turning off quotas:		[  OK  ]
Unmounting pipe file systems:	[  OK  ]
Unmounting file systems:	[  OK  ]
Halting system...
md: stopping all md devices.
md: md0 switched to read-only mode.
Synchronizing SCSI cache for disk sdc:
Synchronizing SCSI cache for disk sdb:
Synchronizing SCSI cache for disk sda:
Power down.
Badness in send_IPI_mask_bitmask at arch/i386/kernel/smp.c:169 (Not tainted)
[<c011482d>] send_IPI_mask_bitmask+0x78/0x7a
[<c0114be1>] smp_send_reschedule+0x1a/0x1b
[<c011e080>] __migrate_task+0xab/0xad
[<c011e114>] migration_thread+0x92/0x114
[<c011e082>] migration_thread+0x0/0x114
[<c01343d9>] kthread+0x93/0x97
[<c0134346>] kthread+0x0/0x97
[<c0101ca1>] kernel_thread_helper+0x5/0xb

machine is not responsive, beyond the last line above.  at one other such shutdown event, many more lines were dumped to the screen.
Comment 1 jmw 2005-10-23 17:46:15 EDT
an update to the SMP kernel was released late last week.  i find the same
problem for 2.6.13-1.1532_FC4SMP that i found in the earlier bug report.  so
far, it seems that 2.6.13-1.1532_FC4 (not SMP) functions normally at shutdown. 
this was the same set of conditions for 2.6.13-1.1526 -- the single processor
version shut down normally, the SMP version did not.

for 2.6.13-1.1532_FC4SMP, i get a series of lines at 'shutdown' that is similar
to the lines that appear in the start of this bugzilla report.  i have not yet
verified that the error message is identical for the newer kernel.
Comment 2 Dave Jones 2005-11-10 15:14:30 EST
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.
Comment 3 jmw 2005-11-10 17:19:07 EST
10 nov 05 - this is what i find:
kernel-smp-2.6.14-1.1637_FC4 -- "Badness..." at shutdown (no obvious change)
kernel-2.6.14-1.1637_FC4 -- normal shutdown and power-off
kernel-smp-2.6.13-1.1532_FC4 -- "Badness..." at shutdown
kernel-2.6.13-1.1532_FC4 -- normal shutdown and power-off
kernel-smp-2.6.12-1.1456_FC4 -- normal shutdown, no power-off (expected)
kernel-2.6.12-1.1456_FC4 -- normal shutdown and power-off

it seems this problem is common to more than one version of Linux.  i Go Ogle
"badness..." and i get many hits, not just FC4.  there is one somewhat minor
difference -- earlier FC4-SMP versions would alternately return the lines
originally cited above, sometimes return many more lines; this latest SMP
version always seems to dump 'many more lines'.  i don't understand the
behavior, so i don't know what else to try.
Comment 4 Alexander Valdez 2005-11-20 20:41:44 EST
(In reply to comment #3)
> 10 nov 05 - this is what i find:
> kernel-smp-2.6.14-1.1637_FC4 -- "Badness..." at shutdown (no obvious change)
> kernel-2.6.14-1.1637_FC4 -- normal shutdown and power-off
> kernel-smp-2.6.13-1.1532_FC4 -- "Badness..." at shutdown
> kernel-2.6.13-1.1532_FC4 -- normal shutdown and power-off
> kernel-smp-2.6.12-1.1456_FC4 -- normal shutdown, no power-off (expected)
> kernel-2.6.12-1.1456_FC4 -- normal shutdown and power-off
> 
> it seems this problem is common to more than one version of Linux.  i Go Ogle
> "badness..." and i get many hits, not just FC4.  there is one somewhat minor
> difference -- earlier FC4-SMP versions would alternately return the lines
> originally cited above, sometimes return many more lines; this latest SMP
> version always seems to dump 'many more lines'.  i don't understand the
> behavior, so i don't know what else to try.

I have been observing the same behavior on my system with FC4 on shutdown:
Badness in send_IPL_mask_bitmask at arch/i386/kernel/smp.c:168(not
tainted)
send_IPL_mask_bitmask+0x78/0x7a
smp_send_reschedule+0x1a/0x1b
_migrate_task+0xab/0xad
migration_thread+0x92/0x114
migration_thread+0x0/0x114
kthread+0x93/0x97
kthread+0x0/0x97
kernel_thread_helper+0x5/0xb

I have also been observing this since I switched to FC4, and it continues to the
following version Linux version 2.6.14-1.1637_FC4smp
(bhcompile@hs20-bc1-4.build.redhat.com) (gcc version 4.0.1 20050727 (Red Hat
4.0.1-5)) #1 SMP Wed Nov 9 18:34:11 EST 2005

My system dmesg is as follows:
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000017ff0000 (usable)
 BIOS-e820: 0000000017ff0000 - 0000000017ff3000 (ACPI NVS)
 BIOS-e820: 0000000017ff3000 - 0000000018000000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
383MB LOWMEM available.
found SMP MP-table at 000f5770
Using x86 segment limits to approximate NX protection
On node 0 totalpages: 98288
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 94192 pages, LIFO batch:31
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
Using APIC driver default
ACPI: RSDP (v000 VIA694                                ) @ 0x000f70b0
ACPI: RSDT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x17ff3000
ACPI: FADT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x17ff3040
ACPI: MADT (v001 VIA694          0x00000000  0x00000000) @ 0x17ff56c0
ACPI: DSDT (v001 VIA694 AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000
ACPI: BIOS age (2000) fails cutoff (2001), acpi=force is required to enable ACPI
ACPI: Disabling ACPI support
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 6:8 APIC version 17
Processor #1 6:8 APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 2
Allocating PCI resources starting at 20000000 (gap: 18000000:e6c00000)
Built 1 zonelists
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
CPU 0 irqstacks, hard=c0449000 soft=c0429000
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 732.242 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 382524k/393152k available (2177k kernel code, 10084k reserved, 808k
data, 224k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1467.40 BogoMIPS (lpj=2934805)
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: 512
CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000 00000000
00000000 00000000
CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000 00000000
00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383f3ff 00000000 00000000 00000040 00000000
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel Pentium III (Coppermine) stepping 03
Booting processor 1/1 eip 2000
CPU 1 irqstacks, hard=c044a000 soft=c042a000
Initializing CPU#1
Calibrating delay using timer specific routine.. 1464.39 BogoMIPS (lpj=2928782)
CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000 00000000
00000000 00000000
CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000 00000000
00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383f3ff 00000000 00000000 00000040 00000000
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel Pentium III (Coppermine) stepping 03
Total of 2 processors activated (2931.79 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
checking if image is initramfs... it is
Freeing initrd memory: 1660k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb3a0, last bus=1
PCI: Using configuration type 1
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs.
mtrr: corrected configuration.
ACPI: Subsystem revision 20050902
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 6000-607f claimed by vt82c868 HW-mon
PCI quirk: region 5000-500f claimed by vt82c868 SMB
Boot video device is 0000:01:00.0
PCI: Using IRQ router VIA [1106/0686] at 0000:00:07.0
PCI->APIC IRQ transform: 0000:00:07.2[D] -> IRQ 161
PCI->APIC IRQ transform: 0000:00:07.3[D] -> IRQ 161
PCI->APIC IRQ transform: 0000:00:0a.0[A] -> IRQ 145
PCI->APIC IRQ transform: 0000:00:0c.0[A] -> IRQ 161
PCI->APIC IRQ transform: 0000:00:0e.0[A] -> IRQ 153
PCI->APIC IRQ transform: 0000:01:00.0[A] -> IRQ 137
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: dc000000-ddffffff
  PREFETCH window: d4000000-dbffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
apm: disabled - APM is not SMP safe.
audit: initializing netlink socket (disabled)
audit(1132477654.484:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SELinux:  Registering netfilter hooks
Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 2A9D19A62139EA9
- User ID: Red Hat, Inc. (Kernel Module GPG key)
PCI: Enabling Via external APIC routing
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected VIA Apollo Pro 133 chipset
agpgart: AGP aperture is 64M @ 0xd0000000
PNP: No PS/2 controller found. Probing ports directly.
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 $ 32 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
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
VP_IDE: IDE controller at PCI slot 0000:00:07.1
PCI: Via IRQ fixup for 0000:00:07.1, from 255 to 0
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:07.1
    ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: WDC WD102AA, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: ATAPI CD-ROM MAX 52X, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
HPT370: IDE controller at PCI slot 0000:00:0e.0
PCI: Enabling device 0000:00:0e.0 (0005 -> 0007)
HPT370: chipset revision 3
HPT370: 100% native mode on irq 153
HPT37X: using 33MHz PCI clock
    ide2: BM-DMA at 0xe400-0xe407, BIOS settings: hde:DMA, hdf:pio
HPT37X: using 33MHz PCI clock
    ide3: BM-DMA at 0xe408-0xe40f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: ST330621A, ATA DISK drive
ide2 at 0xd400-0xd407,0xd802 on irq 153
Probing IDE interface ide3...
Probing IDE interface ide3...
hda: max request size: 128KiB
hda: 20044080 sectors (10262 MB) w/2048KiB Cache, CHS=19885/16/63, UDMA(66)
hda: cache flushes not supported
 hda: hda1 hda2
hde: max request size: 128KiB
hde: 58633344 sectors (30020 MB) w/512KiB Cache, CHS=58168/16/63, UDMA(100)
hde: cache flushes not supported
 hde: hde1 hde2 hde3 hde4
hdc: ATAPI 52X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.20
ide-floppy driver 0.99.newide
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.2 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 3.39
NET: Registered protocol family 2
input: AT Translated Set 2 keyboard on isa0060/serio0
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 6, 327680 bytes)
TCP bind hash table entries: 16384 (order: 6, 327680 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
Freeing unused kernel memory: 224k freed
logips2pp: Detected unknown logitech mouse model 1
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
input: PS/2 Logitech Mouse on isa0060/serio1
cdrom: open failed.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
security:  3 users, 6 roles, 764 types, 87 bools
security:  55 classes, 182383 rules
SELinux:  Completing initialization.
SELinux:  Setting up existing superblocks.
SELinux: initialized (dev dm-0, 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), not configured for labeling
SELinux: initialized (dev hugetlbfs, type hugetlbfs), not configured for labeling
SELinux: initialized (dev devpts, type devpts), uses transition SIDs
SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts
SELinux: initialized (dev inotifyfs, type inotifyfs), not configured for labeling
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
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002
  originally by Donald Becker <becker@scyld.com>
  http://www.scyld.com/network/natsemi.html
  2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
natsemi eth0: NatSemi DP8381[56] at 0xdf000000 (0000:00:0c.0),
00:0f:b5:06:29:a6, IRQ 161, port TP.
parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
parport_pc: Current parallel port base: 0x378
parport0: PC-style at 0x378, irq 7 [PCSPP,EPP]
parport_pc: VIA parallel port: io=0x378, irq=7
shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x1001
USB Universal Host Controller Interface driver v2.3
PCI: Via IRQ fixup for 0000:00:07.2, from 10 to 1
uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:07.2: irq 161, io base 0x0000c400
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
PCI: Via IRQ fixup for 0000:00:07.3, from 10 to 1
uhci_hcd 0000:00:07.3: UHCI Host Controller
uhci_hcd 0000:00:07.3: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:07.3: irq 161, io base 0x0000c800
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
SELinux: initialized (dev ramfs, type ramfs), uses genfs_contexts
NET: Registered protocol family 10
Disabled Privacy Extensions on device c0398e80(lo)
IPv6 over IPv4 tunneling driver
audit(1132477688.254:2): avc:  denied  { create } for  pid=1202 comm="hwclock"
scontext=system_u:system_r:hwclock_t tcontext=system_u:system_r:hwclock_t
tclass=netlink_audit_socket
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
cdrom: open failed.
audit(1132477689.714:3): avc:  denied  { write } for  pid=1224 comm="fsck"
name="rhgb-console" dev=ramfs ino=4225 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:ramfs_t tclass=fifo_file
EXT3 FS on dm-0, 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
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hde2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: initialized (dev hde2, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hde1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: initialized (dev hde1, type ext3), uses xattr
Adding 786424k swap on /dev/VolGroup00/LogVol01.  Priority:-1 extents:1
across:786424k
SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts
ip_tables: (C) 2000-2002 Netfilter core team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.3 (3071 buckets, 24568 max) - 236 bytes per conntrack
eth0: DSPCFG accepted after 0 usec.
eth0: link up.
eth0: Setting full-duplex based on negotiated link capability.
audit(1132477696.739:4): avc:  denied  { write } for  pid=1634 comm="auditd"
name="oom_adj" dev=proc ino=107085853 scontext=system_u:system_r:auditd_t
tcontext=system_u:system_r:auditd_t tclass=file
SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
Bluetooth: Core ver 2.7
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.7
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM ver 1.5
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
lp0: using parport0 (interrupt-driven).
lp0: console ready
eth0: no IPv6 routers present
application mixer_applet2 uses obsolete OSS audio interface
APIC error on CPU0: 00(02)
APIC error on CPU0: 02(04)


Comment 5 jmw 2005-11-29 12:20:40 EST
an update, 28 Nov 05:
installed the latest release, 2.6.14-1.1644_FC4smp.  there is no obvious
difference in shutdown behavior.  to date, 2.6.12-1.1456_FC4smp was the last FC4
version that would shutdown without a "badness in send_IPI_mask_bitmask" error
message.  so far, all 'single processor' versions (non SMP) shut down normally.
Comment 6 jmw 2005-12-06 13:45:27 EST
an experiment, 6 Dec 05:

this system has pre-2000 bios, so acpi is not automagically enabled.  if i set
acpi=on in grub.conf, there is no change in behavior for SMP shutdown.  if i set
acpi=force, then the SMP version will shutdown in the same manner as the
single-processor version (no obvious "Badness in send_IPI_mask_bitmask"
message).  however, this option somehow prevents detection of my sound device
(CS4236B, on the main board).  if i remove the acpi option in grub.conf, i'm
back where i started.  next, i will look for some kind of device conflict.
Comment 7 jmw 2005-12-15 00:17:32 EST
14 dec 05
there are new releases for the kernel -- 2.6.14-1.1653_FC4smp, and
2.6.14-1.1653_FC4.  each of these now require acpi=off if i want to use my sound
system.  without this boot option, CS4236B (the sound device) is not detected.
Comment 8 Dave Jones 2005-12-15 14:17:02 EST
can you attach the output of 'dmesg -s 128000' from 1653, both with and without
the acpi=off boot option.
Comment 9 jmw 2005-12-16 10:29:29 EST
Created attachment 122324 [details]
dmesg for boot option acpi=off

file 1 of 2
Comment 10 jmw 2005-12-16 10:31:00 EST
Created attachment 122325 [details]
1653 dmesg for no additional boot options

file 2 of 2
Comment 11 Dave Jones 2005-12-16 16:01:11 EST
does the test kernel at http://people.redhat.com/davej/kernels/Fedora/FC4
exhibit the same problem ?
Comment 12 jmw 2005-12-18 19:03:27 EST
i found a 1769 SMP version there and installed that.  behavior of 1769 seems
essentially the same as 1653 -- if i don't add a boot option, the SMP version
shuts down normally but does not detect my sound chip on boot-up.  to get sound,
i must add acpi=off to boot options.  when i set acpi off at boot, 1769 SMP
returns even more dump file lines than versions after 1456 and up to 1653.

other data -- i updated the kernel to 1653 on a Dell I7500 laptop (so, of
course, only one CPU); that machine's BIOS is dated 2000; both sound and
power-off appear to work normally.
Comment 13 jmw 2006-01-15 10:22:58 EST
1656 (one cpu) and 1656 SMP both find the CS4236B sound chip, without ACPI=off
in boot options.  now, for this system, all that remains is the 'send_IPI... at
shutdown' behavior.  it seems everything else behaves normally.
Comment 14 Len Brown 2006-01-18 00:24:06 EST
hmmm, first the system ran with acpi disabled by default and
got the SMP send_IPI poweroff failure.
You used acpi=force to enable ACPI, and that fixed shutdown,
but broke sound.
Later kernels enabled ACPI by default and you needed acpi=off
to get sound back.
finally, comment #13 says that the latest kernel is back to
send_IPI failure, but sound is working -- does that kernel
have acpi enabled or disabled?
Comment 15 jmw 2006-01-18 01:11:13 EST
i don't use any extra boot options with 1656, and did not re-compile it, so i
assume some 'CS4236B detect bug' got fixed.  i also assume ACPI is enabled in
1656 by default, but have not verified that.

the loss of sound first appeared with 1653.  versions between 1456 and 1653 did
not return problems with sound, but did show the send_IPI behavior at shutdown.
 i no longer have versions between 1456 and 1653, so cannot verify what effect
ACPI=off would have had on them (i discovered the effect of this option only
recently).

summary: 1656 seems to put things back to the same as post-1456, corrects a
sound problem with 1653, retains the send_IPI behavior at shutdown for the SMP
version.
Comment 16 Dave Jones 2006-02-03 02:17:10 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 17 jmw 2006-02-03 13:03:22 EST
for 2.6.15-1.1830_FC4:

there were several updates released in the last 24 hours or so, aside from the
new kernel.  i used Yum-Extender to install both versions (1830, 1830SMP) today,
along with all the other  updates.  so far, it seems that one of the updates has
done something that completely hoses my display on boot-up, meaning that the
login screen first appears in some low resolution mode, nothing is synchronized
horizontally, there are interleaved horizontal lines on-screen but nothing is
readable.  the system appears to operate normally otherwise, because i can
ignore screen appearance and log-in, hit CTRL-ALT-DEL, then ENTER, and the
system goes through a new login.  a normal login screen then appears, i can
log-in, and it seems the display is restored and everything else works normally.
 on shut-down, the screen goes completely blank, so i don't know whether there
are any other error messages on that event.  now, i need to find whatinhell has
happened to display settings on boot-up and shut-down.  so far, it seems the
above events are endlessly repeatable, for both 1830 and 1830SMP and now for
1656/1656SMP.

for "send_IPI_mask...": 
with this new display problem, the screen goes completely blank on shutdown. 
when that happens, i cannot see what may or may not be happening with this
"send_IPI..." problem.  "completely blank on shut-down" now happens with 1656 as
well (did not happen before today).  i do notice that 1830 eventually powers-off
in the same way that 1656 does (no obvious other problem).  1830SMP appears to
hang on shut-down, just as 1656SMP does.  again, i can't be certain this is the
same IPI problem, because the screen is blank on shut-down.  but so far, "hang
at end" behavior otherwise seems unchanged with 1830SMP.

if it helps:

this systems has a Radeon 9K Pro card, 1GB ram.  'df' returns this:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      32597816   7125456  23789724  24% /
/dev/sdb1               101086     31492     64375  33% /boot
/dev/shm                517216         0    517216   0% /dev/shm

Bios: pre-2000, CPU: Dual P-IIs, Display: Dell 2001FP

the system is 'triple boot' -- FC4, Win 2k, and Win NT.  the Windows partitions
have not been changed.  FC4 manages OS selection through the Grub boot screen. 
Win 2k was in use last night.  i have not yet tried the others today, but have
no reason to suspect there is any problem with them.
Comment 18 jmw 2006-02-05 00:28:30 EST
i found a work-around for the graphical greeter initial display.  it seems i
need to add the boot option "vga=794", where none was needed before.

now, i do actually find a difference in 1830SMP shutdown behavior:

Badness in smp_send_reschedule at arch/i386/kernel/smp.c:482 (Not tainted)
[dozen lines of some kind of data dump, similar to original problem]

Followed by the (by now) old favorite:

Badness in send_IPI_mask_bitmask at arch/i386/kernel/smp.c:168 (Not tainted)
[dozen lines of some kind of data dump]

i suppose this is 'progress', of a sort.  anyway, i don't find other problems yet.
Comment 19 Dave Jones 2006-09-16 23:02:13 EDT
[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.
Comment 20 Dave Jones 2006-10-16 20:06:51 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 21 jmw 2006-10-16 20:59:03 EDT
I quit following this one a long time ago.  The machine where this problem
occurred has long since been converted to Win 2K.  I have FC4 on one small
laptop, but otherwise I run FC5 on newer Win-tel boxes.

FC5 seemes to behave much better in this regard. 

Note You need to log in before you can comment on or make changes to this bug.