kernel warning

kernel warning

[Robert Singleton]

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

Hello,

I found the following warning in the kernel boot message:

  WARNING: unexpected IO-APIC, please mail
           to linux-smp@vger.kernel.org

Is this of concern? I'm running Red Hat 7.2 on a Dell 620
Workstation. I've included the entire kernel boot message
as an attachment.

Thanks very much.

-- 
Robert Singleton                     office: (505)-667-8420
X-7 Material Science                 fax   : (505)-665-0218
Los Alamos National Laboratory       email : bobs1@lanl.gov
P.O. Box 1663, MSP223                MS    : P223
Los Alamos, NM 87545

RSA encryption-key finger print for bobs1@lanl.gov:
48:3A:11:2E:7A:F4:A2:41:83:B4:CD:1E:36:90:DB:22


[-- Attachment #2: dmesg.out --]
[-- Type: text/plain, Size: 14597 bytes --]

Linux version 2.4.7-10smp (bhcompile@stripples.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)) #1 SMP Thu Sep 6 17:09:31 EDT 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007ff9e000 (usable)
 BIOS-e820: 000000007ff9e000 - 0000000080000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
Scanning bios EBDA for MXT signature
1151MB HIGHMEM available.
found SMP MP-table at 000fe710
hm, page 000fe000 reserved twice.
hm, page 000ff000 reserved twice.
hm, page 000f0000 reserved twice.
On node 0 totalpages: 524190
zone(0): 4096 pages.
zone(1): 225280 pages.
zone(2): 294814 pages.
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: DELL     Product ID: WS 620       APIC at: 0xFEE00000
Processor #0 Pentium(tm) Pro APIC version 17
Processor #1 Pentium(tm) Pro APIC version 17
I/O APIC #2 Version 32 at 0xFEC00000.
Processors: 2
Kernel command line: ro root=/dev/sdb7 hdd=ide-scsi
ide_setup: hdd=ide-scsi
Initializing CPU#0
Detected 993.346 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1979.18 BogoMIPS
Memory: 2056476k/2096760k available (1396k kernel code, 37852k reserved, 102k data, 240k init, 1179256k highmem)
Dentry-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Mount-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 131072 (order: 7, 524288 bytes)
Page-cache hash table entries: 524288 (order: 10, 4194304 bytes)
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
CPU:             Common caps: 0383fbff 00000000 00000000 00000000
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
CPU:             Common caps: 0383fbff 00000000 00000000 00000000
CPU0: Intel Pentium III (Coppermine) stepping 06
per-CPU timeslice cutoff: 731.63 usecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000040
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 1985.74 BogoMIPS
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check reporting enabled on CPU#1.
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
CPU:             Common caps: 0383fbff 00000000 00000000 00000000
CPU1: Intel Pentium III (Coppermine) stepping 06
Total of 2 processors activated (3964.92 BogoMIPS).
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-13, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 62.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.... register #01: 00170020
.......     : max redirection entries: 0017
.......     : IO APIC version: 0020
 WARNING: unexpected IO-APIC, please mail
          to linux-smp@vger.kernel.org
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 003 03  0    0    0   0   0    1    1    39
 02 003 03  0    0    0   0   0    1    1    31
 03 003 03  0    0    0   0   0    1    1    41
 04 003 03  0    0    0   0   0    1    1    49
 05 003 03  0    0    0   0   0    1    1    51
 06 003 03  0    0    0   0   0    1    1    59
 07 003 03  0    0    0   0   0    1    1    61
 08 003 03  0    0    0   0   0    1    1    69
 09 003 03  0    0    0   0   0    1    1    71
 0a 003 03  0    0    0   0   0    1    1    79
 0b 003 03  0    0    0   0   0    1    1    81
 0c 003 03  0    0    0   0   0    1    1    89
 0d 000 00  1    0    0   0   0    0    0    00
 0e 003 03  0    0    0   0   0    1    1    91
 0f 003 03  0    0    0   0   0    1    1    99
 10 003 03  1    1    0   1   0    1    1    A1
 11 003 03  1    1    0   1   0    1    1    A9
 12 003 03  1    1    0   1   0    1    1    B1
 13 003 03  1    1    0   1   0    1    1    B9
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 993.2697 MHz.
..... host bus clock speed is 132.4358 MHz.
cpu: 0, clocks: 1324358, slice: 441452
CPU0<T0:1324352,T1:882896,D:4,S:441452,C:1324358>
cpu: 1, clocks: 1324358, slice: 441452
CPU1<T0:1324352,T1:441440,D:8,S:441452,C:1324358>
checking TSC synchronization across CPUs: passed.
PCI: PCI BIOS revision 2.10 entry at 0xfc03e, last bus=4
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 2: assuming transparent
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router PIIX [8086/2410] at 00:1f.0
PCI->APIC IRQ transform: (B0,I31,P3) -> 19
PCI->APIC IRQ transform: (B0,I31,P1) -> 17
PCI->APIC IRQ transform: (B1,I0,P0) -> 16
PCI->APIC IRQ transform: (B4,I3,P0) -> 19
PCI->APIC IRQ transform: (B4,I4,P0) -> 16
PCI->APIC IRQ transform: (B4,I5,P0) -> 17
PCI->APIC IRQ transform: (B4,I5,P1) -> 18
PCI->APIC IRQ transform: (B4,I7,P0) -> 19
PCI->APIC IRQ transform: (B4,I8,P0) -> 16
PCI->APIC IRQ transform: (B4,I10,P0) -> 18
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
apm: disabled - APM is not SMP safe.
mxt_scan_bios: enter
Starting kswapd v1.8
allocated 64 pages and 64 bhs reserved for the highmem bounces
VFS: Diskquotas version dquot_6.5.0 initialized
pty: 2048 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10d
block: queued sectors max/low 1365330kB/1234258kB, 4032 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz PCI bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev f9
PIIX4: chipset revision 2
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA
hda: IOMEGA ZIP 250 ATAPI, ATAPI FLOPPY drive
hdc: _NEC DV-5800A, ATAPI CD/DVD-ROM drive
hdd: SONY CD-RW CRX140E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide-floppy driver 0.97
hda: No disk in drive
hda: 244736kB, 239/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm
ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
ide-floppy driver 0.97
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 16384 buckets, 128Kbytes
TCP: Hash tables configured (established 524288 bind 65536)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 445k freed
VFS: Mounted root (ext2 filesystem).
SCSI subsystem driver Revision: 1.00
(scsi0) <Adaptec AIC-7899 Ultra 160/m SCSI host adapter> found at PCI 4/5/0
(scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 396 instructions downloaded
(scsi1) <Adaptec AIC-7899 Ultra 160/m SCSI host adapter> found at PCI 4/5/1
(scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 396 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0
       <Adaptec AIC-7899 Ultra 160/m SCSI host adapter>
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0
       <Adaptec AIC-7899 Ultra 160/m SCSI host adapter>
  Vendor: QUANTUM   Model: ATLAS10K2-TY367L  Rev: DA40
  Type:   Direct-Access                      ANSI SCSI revision: 03
  Vendor: FUJITSU   Model: MAJ3364MP         Rev: 5508
  Type:   Direct-Access                      ANSI SCSI revision: 04
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
(scsi0:0:0:0) Synchronous at 160.0 Mbyte/sec, offset 127.
SCSI device sda: 71132959 512-byte hdwr sectors (36420 MB)
Partition check:
 sda: sda1 sda2 < sda5 >
(scsi0:0:1:0) Synchronous at 160.0 Mbyte/sec, offset 127.
SCSI device sdb: 71132959 512-byte hdwr sectors (36420 MB)
 sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 >
Journalled Block Device driver loaded
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Freeing unused kernel memory: 240k freed
Adding Swap: 265032k swap-space (priority -1)
Adding Swap: 265032k swap-space (priority -2)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.259 $ time 17:18:11 Sep  6 2001
usb-uhci.c: High bandwidth mode enabled
PCI: Setting latency timer of device 00:1f.2 to 64
usb-uhci.c: USB UHCI at I/O 0xff80, IRQ 19
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: v1.251:USB Universal Host Controller Interface driver
EXT3 FS 2.4-0.9.8, 25 Aug 2001 on sd(8,23), internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.8, 25 Aug 2001 on sd(8,17), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
scsi2 : SCSI host adapter emulation for IDE ATAPI devices
  Vendor: SONY      Model: CD-RW  CRX140E    Rev: 1.0n
  Type:   CD-ROM                             ANSI SCSI revision: 02
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: ECP port cfgA=0x14 cfgB=0x40
0x378: ECP settings irq=<none or set by other means> dma=<none or set by other means>
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,EPP,ECP]
parport0: irq 7 detected
parport0: cpp_daisy: aa5500ff(08)
parport0: assign_addrs: aa5500ff(08)
parport0: cpp_daisy: aa5500ff(08)
parport0: assign_addrs: aa5500ff(08)
NET4: Linux IPX 0.47 for NET4.0
IPX Portions Copyright (c) 1995 Caldera, Inc.
IPX Portions Copyright (c) 2000, 2001 Conectiva, Inc.
NET4: AppleTalk 0.18a for Linux NET4.0
Creative EMU10K1 PCI Audio Driver, version 0.7, 17:18:51 Sep  6 2001
emu10k1: EMU10K1 rev 7 model 0x8022 found, IO at 0xece0-0xecff, IRQ 19
CSLIP: code copyright 1989 Regents of the University of California
PPP generic driver version 2.4.1
PPP BSD Compression module registered
PPP Deflate Compression module registered
hda: 244766kB, 489532 blocks, 512 sector size
hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
 hda: hda4
hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
 hda: hda4
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
 hda: hda4
hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
 hda: hda4
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
 hda: hda4
hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
 hda: hda4
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
 hda: hda4
hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
 hda: hda4
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended

Re: kernel warning

[Vladimir G. Ivanovic]

Allegedly not. It merely means that your motherboard is not recognized
as being OK.

My /proc/interrupts (different motherboard) looks like:

              CPU0       CPU1       
     0:    9208532    8999909    IO-APIC-edge  timer
     1:      49949      49416    IO-APIC-edge  keyboard
     2:          0          0          XT-PIC  cascade
     5:     461657     462659   IO-APIC-level  es1371, usb-uhci, usb-uhci
     8:   61549507   61639660    IO-APIC-edge  rtc
     9:     308474     307759   IO-APIC-level  sym53c8xx
    10:    3155516    3157266   IO-APIC-level  eth0
    11:        173        162   IO-APIC-level  sym53c8xx
    12:     715163     714417    IO-APIC-edge  PS/2 Mouse
    14:      48981      49208    IO-APIC-edge  ide0
    15:     728205     724269    IO-APIC-edge  ide1
   NMI:          0          0 
   LOC:   18208803   18208857 
   ERR:          0
   MIS:          0

which tells me that both CPUs are receiving interrupts. Yours should
look similar.

Presumably there are no other errors on your system...

--- Vladimir

--------
Vladimir G. Ivanovic                        http://leonora.org/~vladimir
2770 Cowper St.                                         vladimir@acm.org
Palo Alto, CA 94306-2447                                 +1 650 678 8014

"RS" == Robert Singleton <bobs1@lanl.gov> writes:

  RS> This is a multi-part message in MIME format.
  RS> --------------010302060606050702060007
  RS> Content-Type: text/plain; charset=us-ascii; format=flowed
  RS> Content-Transfer-Encoding: 7bit

  RS> Hello,

  RS> I found the following warning in the kernel boot message:

  RS>   WARNING: unexpected IO-APIC, please mail
  RS>            to linux-smp@vger.kernel.org

  RS> Is this of concern? I'm running Red Hat 7.2 on a Dell 620
  RS> Workstation. I've included the entire kernel boot message
  RS> as an attachment.

  RS> Thanks very much.

  RS> -- 
  RS> Robert Singleton                     office: (505)-667-8420
  RS> X-7 Material Science                 fax   : (505)-665-0218
  RS> Los Alamos National Laboratory       email : bobs1@lanl.gov
  RS> P.O. Box 1663, MSP223                MS    : P223
  RS> Los Alamos, NM 87545

  RS> RSA encryption-key finger print for bobs1@lanl.gov:
  RS> 48:3A:11:2E:7A:F4:A2:41:83:B4:CD:1E:36:90:DB:22


  RS> --------------010302060606050702060007
  RS> Content-Type: text/plain;
  RS>  name="dmesg.out"
  RS> Content-Transfer-Encoding: 7bit
  RS> Content-Disposition: inline;
  RS>  filename="dmesg.out"

  RS> Linux version 2.4.7-10smp (bhcompile@stripples.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)) #1 SMP Thu Sep 6 17:09:31 EDT 2001
  RS> BIOS-provided physical RAM map:
  RS>  BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
  RS>  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
  RS>  BIOS-e820: 0000000000100000 - 000000007ff9e000 (usable)
  RS>  BIOS-e820: 000000007ff9e000 - 0000000080000000 (reserved)
  RS>  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
  RS>  BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
  RS>  BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
  RS> Scanning bios EBDA for MXT signature
  RS> 1151MB HIGHMEM available.
  RS> found SMP MP-table at 000fe710
  RS> hm, page 000fe000 reserved twice.
  RS> hm, page 000ff000 reserved twice.
  RS> hm, page 000f0000 reserved twice.
  RS> On node 0 totalpages: 524190
  RS> zone(0): 4096 pages.
  RS> zone(1): 225280 pages.
  RS> zone(2): 294814 pages.
  RS> Intel MultiProcessor Specification v1.4
  RS>     Virtual Wire compatibility mode.
  RS> OEM ID: DELL     Product ID: WS 620       APIC at: 0xFEE00000
  RS> Processor #0 Pentium(tm) Pro APIC version 17
  RS> Processor #1 Pentium(tm) Pro APIC version 17
  RS> I/O APIC #2 Version 32 at 0xFEC00000.
  RS> Processors: 2
  RS> Kernel command line: ro root=/dev/sdb7 hdd=ide-scsi
  RS> ide_setup: hdd=ide-scsi
  RS> Initializing CPU#0
  RS> Detected 993.346 MHz processor.
  RS> Console: colour VGA+ 80x25
  RS> Calibrating delay loop... 1979.18 BogoMIPS
  RS> Memory: 2056476k/2096760k available (1396k kernel code, 37852k reserved, 102k data, 240k init, 1179256k highmem)
  RS> Dentry-cache hash table entries: 262144 (order: 9, 2097152 bytes)
  RS> Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
  RS> Mount-cache hash table entries: 32768 (order: 6, 262144 bytes)
  RS> Buffer-cache hash table entries: 131072 (order: 7, 524288 bytes)
  RS> Page-cache hash table entries: 524288 (order: 10, 4194304 bytes)
  RS> CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
  RS> CPU: L1 I cache: 16K, L1 D cache: 16K
  RS> CPU: L2 cache: 256K
  RS> Intel machine check architecture supported.
  RS> Intel machine check reporting enabled on CPU#0.
  RS> CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
  RS> CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
  RS> CPU:             Common caps: 0383fbff 00000000 00000000 00000000
  RS> Enabling fast FPU save and restore... done.
  RS> Enabling unmasked SIMD FPU exception support... done.
  RS> Checking 'hlt' instruction... OK.
  RS> POSIX conformance testing by UNIFIX
  RS> mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
  RS> mtrr: detected mtrr type: Intel
  RS> CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
  RS> CPU: L1 I cache: 16K, L1 D cache: 16K
  RS> CPU: L2 cache: 256K
  RS> Intel machine check reporting enabled on CPU#0.
  RS> CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
  RS> CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
  RS> CPU:             Common caps: 0383fbff 00000000 00000000 00000000
  RS> CPU0: Intel Pentium III (Coppermine) stepping 06
  RS> per-CPU timeslice cutoff: 731.63 usecs.
  RS> enabled ExtINT on CPU#0
  RS> ESR value before enabling vector: 00000040
  RS> ESR value after enabling vector: 00000000
  RS> Booting processor 1/1 eip 2000
  RS> Initializing CPU#1
  RS> masked ExtINT on CPU#1
  RS> ESR value before enabling vector: 00000000
  RS> ESR value after enabling vector: 00000000
  RS> Calibrating delay loop... 1985.74 BogoMIPS
  RS> CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
  RS> CPU: L1 I cache: 16K, L1 D cache: 16K
  RS> CPU: L2 cache: 256K
  RS> Intel machine check reporting enabled on CPU#1.
  RS> CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
  RS> CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
  RS> CPU:             Common caps: 0383fbff 00000000 00000000 00000000
  RS> CPU1: Intel Pentium III (Coppermine) stepping 06
  RS> Total of 2 processors activated (3964.92 BogoMIPS).
  RS> ENABLING IO-APIC IRQs
  RS> ...changing IO-APIC physical APIC ID to 2 ... ok.
  RS> init IO_APIC IRQs
  RS>  IO-APIC (apicid-pin) 2-0, 2-13, 2-20, 2-21, 2-22, 2-23 not connected.
  RS> ..TIMER: vector=0x31 pin1=2 pin2=0
  RS> number of MP IRQ sources: 62.
  RS> number of IO-APIC #2 registers: 24.
  RS> testing the IO APIC.......................

  RS> IO APIC #2......
  RS> .... register #00: 02000000
  RS> .......    : physical APIC id: 02
  RS> .... register #01: 00170020
  RS> .......     : max redirection entries: 0017
  RS> .......     : IO APIC version: 0020
  RS>  WARNING: unexpected IO-APIC, please mail
  RS>           to linux-smp@vger.kernel.org
  RS> .... register #02: 00000000
  RS> .......     : arbitration: 00
  RS> .... IRQ redirection table:
  RS>  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
  RS>  00 000 00  1    0    0   0   0    0    0    00
  RS>  01 003 03  0    0    0   0   0    1    1    39
  RS>  02 003 03  0    0    0   0   0    1    1    31
  RS>  03 003 03  0    0    0   0   0    1    1    41
  RS>  04 003 03  0    0    0   0   0    1    1    49
  RS>  05 003 03  0    0    0   0   0    1    1    51
  RS>  06 003 03  0    0    0   0   0    1    1    59
  RS>  07 003 03  0    0    0   0   0    1    1    61
  RS>  08 003 03  0    0    0   0   0    1    1    69
  RS>  09 003 03  0    0    0   0   0    1    1    71
  RS>  0a 003 03  0    0    0   0   0    1    1    79
  RS>  0b 003 03  0    0    0   0   0    1    1    81
  RS>  0c 003 03  0    0    0   0   0    1    1    89
  RS>  0d 000 00  1    0    0   0   0    0    0    00
  RS>  0e 003 03  0    0    0   0   0    1    1    91
  RS>  0f 003 03  0    0    0   0   0    1    1    99
  RS>  10 003 03  1    1    0   1   0    1    1    A1
  RS>  11 003 03  1    1    0   1   0    1    1    A9
  RS>  12 003 03  1    1    0   1   0    1    1    B1
  RS>  13 003 03  1    1    0   1   0    1    1    B9
  RS>  14 000 00  1    0    0   0   0    0    0    00
  RS>  15 000 00  1    0    0   0   0    0    0    00
  RS>  16 000 00  1    0    0   0   0    0    0    00
  RS>  17 000 00  1    0    0   0   0    0    0    00
  RS> IRQ to pin mappings:
  RS> IRQ0 -> 0:2
  RS> IRQ1 -> 0:1
  RS> IRQ3 -> 0:3
  RS> IRQ4 -> 0:4
  RS> IRQ5 -> 0:5
  RS> IRQ6 -> 0:6
  RS> IRQ7 -> 0:7
  RS> IRQ8 -> 0:8
  RS> IRQ9 -> 0:9
  RS> IRQ10 -> 0:10
  RS> IRQ11 -> 0:11
  RS> IRQ12 -> 0:12
  RS> IRQ14 -> 0:14
  RS> IRQ15 -> 0:15
  RS> IRQ16 -> 0:16
  RS> IRQ17 -> 0:17
  RS> IRQ18 -> 0:18
  RS> IRQ19 -> 0:19
  RS> .................................... done.
  RS> Using local APIC timer interrupts.
  RS> calibrating APIC timer ...
  RS> ..... CPU clock speed is 993.2697 MHz.
  RS> ..... host bus clock speed is 132.4358 MHz.
  RS> cpu: 0, clocks: 1324358, slice: 441452
  RS> CPU0<T0:1324352,T1:882896,D:4,S:441452,C:1324358>
  RS> cpu: 1, clocks: 1324358, slice: 441452
  RS> CPU1<T0:1324352,T1:441440,D:8,S:441452,C:1324358>
  RS> checking TSC synchronization across CPUs: passed.
  RS> PCI: PCI BIOS revision 2.10 entry at 0xfc03e, last bus=4
  RS> PCI: Using configuration type 1
  RS> PCI: Probing PCI hardware
  RS> Unknown bridge resource 0: assuming transparent
  RS> Unknown bridge resource 0: assuming transparent
  RS> Unknown bridge resource 2: assuming transparent
  RS> Unknown bridge resource 0: assuming transparent
  RS> Unknown bridge resource 1: assuming transparent
  RS> Unknown bridge resource 2: assuming transparent
  RS> Unknown bridge resource 2: assuming transparent
  RS> PCI: Using IRQ router PIIX [8086/2410] at 00:1f.0
  PCI-> APIC IRQ transform: (B0,I31,P3) -> 19
  PCI-> APIC IRQ transform: (B0,I31,P1) -> 17
  PCI-> APIC IRQ transform: (B1,I0,P0) -> 16
  PCI-> APIC IRQ transform: (B4,I3,P0) -> 19
  PCI-> APIC IRQ transform: (B4,I4,P0) -> 16
  PCI-> APIC IRQ transform: (B4,I5,P0) -> 17
  PCI-> APIC IRQ transform: (B4,I5,P1) -> 18
  PCI-> APIC IRQ transform: (B4,I7,P0) -> 19
  PCI-> APIC IRQ transform: (B4,I8,P0) -> 16
  PCI-> APIC IRQ transform: (B4,I10,P0) -> 18
  RS> isapnp: Scanning for PnP cards...
  RS> isapnp: No Plug & Play device found
  RS> Linux NET4.0 for Linux 2.4
  RS> Based upon Swansea University Computer Society NET3.039
  RS> Initializing RT netlink socket
  RS> apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
  RS> apm: disabled - APM is not SMP safe.
  RS> mxt_scan_bios: enter
  RS> Starting kswapd v1.8
  RS> allocated 64 pages and 64 bhs reserved for the highmem bounces
  RS> VFS: Diskquotas version dquot_6.5.0 initialized
  RS> pty: 2048 Unix98 ptys configured
  RS> Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
  RS> ttyS00 at 0x03f8 (irq = 4) is a 16550A
  RS> ttyS01 at 0x02f8 (irq = 3) is a 16550A
  RS> Real Time Clock Driver v1.10d
  RS> block: queued sectors max/low 1365330kB/1234258kB, 4032 slots per queue
  RS> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
  RS> Uniform Multi-Platform E-IDE driver Revision: 6.31
  RS> ide: Assuming 33MHz PCI bus speed for PIO modes; override with idebus=xx
  RS> PIIX4: IDE controller on PCI bus 00 dev f9
  RS> PIIX4: chipset revision 2
  RS> PIIX4: not 100% native mode: will probe irqs later
  RS>     ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio
  RS>     ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA
  RS> hda: IOMEGA ZIP 250 ATAPI, ATAPI FLOPPY drive
  RS> hdc: _NEC DV-5800A, ATAPI CD/DVD-ROM drive
  RS> hdd: SONY CD-RW CRX140E, ATAPI CD/DVD-ROM drive
  RS> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
  RS> ide1 at 0x170-0x177,0x376 on irq 15
  RS> ide-floppy driver 0.97
  RS> hda: No disk in drive
  RS> hda: 244736kB, 239/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm
  RS> ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
  RS> Floppy drive(s): fd0 is 1.44M
  RS> FDC 0 is a National Semiconductor PC87306
  RS> ide-floppy driver 0.97
  RS> md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
  RS> md: Autodetecting RAID arrays.
  RS> md: autorun ...
  RS> md: ... autorun DONE.
  RS> NET4: Linux TCP/IP 1.0 for NET4.0
  RS> IP Protocols: ICMP, UDP, TCP, IGMP
  RS> IP: routing cache hash table of 16384 buckets, 128Kbytes
  RS> TCP: Hash tables configured (established 524288 bind 65536)
  RS> Linux IP multicast router 0.06 plus PIM-SM
  RS> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
  RS> RAMDISK: Compressed image found at block 0
  RS> Freeing initrd memory: 445k freed
  RS> VFS: Mounted root (ext2 filesystem).
  RS> SCSI subsystem driver Revision: 1.00
  RS> (scsi0) <Adaptec AIC-7899 Ultra 160/m SCSI host adapter> found at PCI 4/5/0
  RS> (scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs
  RS> (scsi0) Downloading sequencer code... 396 instructions downloaded
  RS> (scsi1) <Adaptec AIC-7899 Ultra 160/m SCSI host adapter> found at PCI 4/5/1
  RS> (scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs
  RS> (scsi1) Downloading sequencer code... 396 instructions downloaded
  RS> scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0
  RS>        <Adaptec AIC-7899 Ultra 160/m SCSI host adapter>
  RS> scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0
  RS>        <Adaptec AIC-7899 Ultra 160/m SCSI host adapter>
  RS>   Vendor: QUANTUM   Model: ATLAS10K2-TY367L  Rev: DA40
  RS>   Type:   Direct-Access                      ANSI SCSI revision: 03
  RS>   Vendor: FUJITSU   Model: MAJ3364MP         Rev: 5508
  RS>   Type:   Direct-Access                      ANSI SCSI revision: 04
  RS> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
  RS> Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
  RS> (scsi0:0:0:0) Synchronous at 160.0 Mbyte/sec, offset 127.
  RS> SCSI device sda: 71132959 512-byte hdwr sectors (36420 MB)
  RS> Partition check:
  RS>  sda: sda1 sda2 < sda5 >
  RS> (scsi0:0:1:0) Synchronous at 160.0 Mbyte/sec, offset 127.
  RS> SCSI device sdb: 71132959 512-byte hdwr sectors (36420 MB)
  RS>  sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 >
  RS> Journalled Block Device driver loaded
  RS> kjournald starting.  Commit interval 5 seconds
  RS> EXT3-fs: mounted filesystem with ordered data mode.
  RS> Freeing unused kernel memory: 240k freed
  RS> Adding Swap: 265032k swap-space (priority -1)
  RS> Adding Swap: 265032k swap-space (priority -2)
  RS> usb.c: registered new driver usbdevfs
  RS> usb.c: registered new driver hub
  RS> usb-uhci.c: $Revision: 1.259 $ time 17:18:11 Sep  6 2001
  RS> usb-uhci.c: High bandwidth mode enabled
  RS> PCI: Setting latency timer of device 00:1f.2 to 64
  RS> usb-uhci.c: USB UHCI at I/O 0xff80, IRQ 19
  RS> usb-uhci.c: Detected 2 ports
  RS> usb.c: new USB bus registered, assigned bus number 1
  RS> hub.c: USB hub found
  RS> hub.c: 2 ports detected
  RS> usb-uhci.c: v1.251:USB Universal Host Controller Interface driver
  RS> EXT3 FS 2.4-0.9.8, 25 Aug 2001 on sd(8,23), internal journal
  RS> kjournald starting.  Commit interval 5 seconds
  RS> EXT3 FS 2.4-0.9.8, 25 Aug 2001 on sd(8,17), internal journal
  RS> EXT3-fs: mounted filesystem with ordered data mode.
  RS> hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
  RS> Uniform CD-ROM driver Revision: 3.12
  RS> scsi2 : SCSI host adapter emulation for IDE ATAPI devices
  RS>   Vendor: SONY      Model: CD-RW  CRX140E    Rev: 1.0n
  RS>   Type:   CD-ROM                             ANSI SCSI revision: 02
  RS> 0x378: FIFO is 16 bytes
  RS> 0x378: writeIntrThreshold is 8
  RS> 0x378: readIntrThreshold is 8
  RS> 0x378: PWord is 8 bits
  RS> 0x378: Interrupts are ISA-Pulses
  RS> 0x378: ECP port cfgA=0x14 cfgB=0x40
  RS> 0x378: ECP settings irq=<none or set by other means> dma=<none or set by other means>
  RS> parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,EPP,ECP]
  RS> parport0: irq 7 detected
  RS> parport0: cpp_daisy: aa5500ff(08)
  RS> parport0: assign_addrs: aa5500ff(08)
  RS> parport0: cpp_daisy: aa5500ff(08)
  RS> parport0: assign_addrs: aa5500ff(08)
  RS> NET4: Linux IPX 0.47 for NET4.0
  RS> IPX Portions Copyright (c) 1995 Caldera, Inc.
  RS> IPX Portions Copyright (c) 2000, 2001 Conectiva, Inc.
  RS> NET4: AppleTalk 0.18a for Linux NET4.0
  RS> Creative EMU10K1 PCI Audio Driver, version 0.7, 17:18:51 Sep  6 2001
  RS> emu10k1: EMU10K1 rev 7 model 0x8022 found, IO at 0xece0-0xecff, IRQ 19
  RS> CSLIP: code copyright 1989 Regents of the University of California
  RS> PPP generic driver version 2.4.1
  RS> PPP BSD Compression module registered
  RS> PPP Deflate Compression module registered
  RS> hda: 244766kB, 489532 blocks, 512 sector size
  RS> hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
  RS> ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
  RS>  hda: hda4
  RS> hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
  RS> ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
  RS>  hda: hda4
  RS> EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
  RS> hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
  RS> ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
  RS>  hda: hda4
  RS> hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
  RS> ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
  RS>  hda: hda4
  RS> EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
  RS> hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
  RS> ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
  RS>  hda: hda4
  RS> hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
  RS> ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
  RS>  hda: hda4
  RS> EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
  RS> hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
  RS> ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
  RS>  hda: hda4
  RS> hda: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
  RS> ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
  RS>  hda: hda4
  RS> EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended

  RS> --------------010302060606050702060007--

  RS> -
  RS> To unsubscribe from this list: send the line "unsubscribe linux-smp" in
  RS> the body of a message to majordomo@vger.kernel.org
  RS> More majordomo info at  http://vger.kernel.org/majordomo-info.html

kernel warning

[Brian May]

While compiling the kernel, 2.4.19, with the latest lsm-SE Linux
patches from Russell (I am not sure how to double check this; but it is
POLICYDB_VERSION 12), I happened to glance at my screen when this was
displayed:

gcc -D__KERNEL__ -I/home/bam/tmp/woody/selinux/kernel-image/kernel-image-2.4.19-i386-2.4.19/build-k6/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6    -Iinclude  -nostdinc -I /usr/lib/gcc-lib/i386-linux/2.95.4/include -DKBUILD_BASENAME=hooks  -c -o hooks.o hooks.c
hooks.c:66: warning: #warning "SELinux:  The separate SELinux kernel patch has not been applied.  Using SELinux without this patch is not recommended."

Looking at the code I see:

#ifndef _SELINUX_KERNEL_PATCH_
#warning "SELinux:  The separate SELinux kernel patch has not been applied.  Using SELinux without this patch is not recommended."
#endif

Further down I see:

#ifdef _SELINUX_KERNEL_PATCH_
[...]
#else
       printk(KERN_WARNING "SELinux:  The separate SELinux kernel patch was not applied.  Using SELinux without this patch is not recommended.\n");
[...]
#endif

However, _SELINUX_KERNEL_PATCH_ is only used, and never defined, in this
file.

I have also checked this against Russell's patch, it appears to be the
same.

Have I made a mistake somewhere in patching the kernel, or maybe this
code is obsolete? Or perhaps Russell's patch is not intended to be used
standalone anymore but must be used in conjection with another patch?

What is this "seperate kernel patch"?
-- 
Brian May <bam@snoopy.apana.org.au>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Stephen Smalley]

On Sun, 27 Oct 2002, Brian May wrote:

> While compiling the kernel, 2.4.19, with the latest lsm-SE Linux
> patches from Russell (I am not sure how to double check this; but it is
> POLICYDB_VERSION 12), I happened to glance at my screen when this was
> displayed:
>
> gcc -D__KERNEL__ -I/home/bam/tmp/woody/selinux/kernel-image/kernel-image-2.4.19-i386-2.4.19/build-k6/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6    -Iinclude  -nostdinc -I /usr/lib/gcc-lib/i386-linux/2.95.4/include -DKBUILD_BASENAME=hooks  -c -o hooks.o hooks.c
> hooks.c:66: warning: #warning "SELinux:  The separate SELinux kernel patch has not been applied.  Using SELinux without this patch is not recommended."
<snip>
> Have I made a mistake somewhere in patching the kernel, or maybe this
> code is obsolete? Or perhaps Russell's patch is not intended to be used
> standalone anymore but must be used in conjection with another patch?
>
> What is this "seperate kernel patch"?

SELinux has always included a separate SELinux-specific kernel patch to be
applied on top of the LSM patch, although the precise purpose of the patch
has varied over time.  In the current release, the patch is available in
the SELinux archive in selinux/module/selinux-2.4.patch or directly from
http://www.nsa.gov/selinux/patches/selinux-2.4-2002102211.patch.gz.  In
the latest release, the dependence of the SELinux module on this patch has
increased due to the elimination of precondition functions.  Some of the
changes in this patch may find their way back into the mainstream LSM
patch in a more general form in the future (they have all been discussed
on the LSM mailing list), but some changes are likely to remain
SELinux-specific.

As a side note, please be aware that the lsm-2.4 tree and LSM patch that
is provided on the NSA SELinux web site is also different from the
old 2.4.19-lsm1 snapshot patch from WireX.  It is consistent with the head
of the LSM BitKeeper tree, so it includes many changes that have been
committed since that snapshot patch.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Brian May]

On Mon, Oct 28, 2002 at 07:57:06AM -0500, Stephen Smalley wrote:
> SELinux has always included a separate SELinux-specific kernel patch to be
> applied on top of the LSM patch, although the precise purpose of the patch
> has varied over time.  In the current release, the patch is available in
> the SELinux archive in selinux/module/selinux-2.4.patch or directly from
> http://www.nsa.gov/selinux/patches/selinux-2.4-2002102211.patch.gz.  In
> the latest release, the dependence of the SELinux module on this patch has
> increased due to the elimination of precondition functions.  Some of the
> changes in this patch may find their way back into the mainstream LSM
> patch in a more general form in the future (they have all been discussed
> on the LSM mailing list), but some changes are likely to remain
> SELinux-specific.
> 
> As a side note, please be aware that the lsm-2.4 tree and LSM patch that
> is provided on the NSA SELinux web site is also different from the
> old 2.4.19-lsm1 snapshot patch from WireX.  It is consistent with the head
> of the LSM BitKeeper tree, so it includes many changes that have been
> committed since that snapshot patch.

Russell,

Do you have any plans to include this patch, which currently appears to
be missing into your Debian package kernel-patch-2.4-lsm?

When I next get the chance I will patch my kernel source image available
online my website with this extra patch.
--
Brian May <bam@snoopy.apana.org.au>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Russell Coker]

On Mon, 28 Oct 2002 23:53, Brian May wrote:
> Do you have any plans to include this patch, which currently appears to
> be missing into your Debian package kernel-patch-2.4-lsm?
>
> When I next get the chance I will patch my kernel source image available
> online my website with this extra patch.

Yes, I'll do it now.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Brian May]

On Mon, Oct 28, 2002 at 07:57:06AM -0500, Stephen Smalley wrote:
> SELinux has always included a separate SELinux-specific kernel patch to be
> applied on top of the LSM patch, although the precise purpose of the patch
> has varied over time.  In the current release, the patch is available in
> the SELinux archive in selinux/module/selinux-2.4.patch or directly from
> http://www.nsa.gov/selinux/patches/selinux-2.4-2002102211.patch.gz.  In
> the latest release, the dependence of the SELinux module on this patch has
> increased due to the elimination of precondition functions.  Some of the
> changes in this patch may find their way back into the mainstream LSM
> patch in a more general form in the future (they have all been discussed
> on the LSM mailing list), but some changes are likely to remain
> SELinux-specific.

It appears that with this patch, it is no longer possible to
compile the patched kernel without SE-LINUX support.

Maybe the call to selinux_init() in main.c needs
to be wrapped with #ifdef CONFIG_SECURITY_SELINUX?
-- 
Brian May <bam@snoopy.apana.org.au>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Stephen Smalley]

On Wed, 30 Oct 2002, Brian May wrote:

> It appears that with this patch, it is no longer possible to
> compile the patched kernel without SE-LINUX support.
>
> Maybe the call to selinux_init() in main.c needs
> to be wrapped with #ifdef CONFIG_SECURITY_SELINUX?

You would only apply this patch if you intend to use SELinux, so it is
implicit that SELinux is going to be enabled.  We could #ifdef it, but I'm
not sure what the point is.  Now, if a generalized form of early
initialization is added to the LSM patch, then this would go away and the
SELinux-specific code would be hidden.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Russell Coker]

On Wed, 30 Oct 2002 14:23, Stephen Smalley wrote:
> > It appears that with this patch, it is no longer possible to
> > compile the patched kernel without SE-LINUX support.
> >
> > Maybe the call to selinux_init() in main.c needs
> > to be wrapped with #ifdef CONFIG_SECURITY_SELINUX?
>
> You would only apply this patch if you intend to use SELinux, so it is
> implicit that SELinux is going to be enabled.  We could #ifdef it, but I'm
> not sure what the point is.  Now, if a generalized form of early
> initialization is added to the LSM patch, then this would go away and the
> SELinux-specific code would be hidden.

This means that I can't produce a single kernel-patch package that can be used 
by SE Linux, LIDS, and DTE users...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Kerry Thompson]

The 'Everything in one Part' download at
http://www.nsa.gov/selinux/archives/lsm-2.4-selinux-2002102211.tgz doesn't
seem to have this patch included, and the NSA site isn't very clear that
the patch is required. Could we please have the patch added to the next
all-in-one snapshot?

Kerry

Stephen Smalley said:
>
> SELinux has always included a separate SELinux-specific kernel patch to
> be applied on top of the LSM patch, although the precise purpose of the
> patch has varied over time.  In the current release, the patch is
> available in the SELinux archive in selinux/module/selinux-2.4.patch or
> directly from
> http://www.nsa.gov/selinux/patches/selinux-2.4-2002102211.patch.gz.  In
> the latest release, the dependence of the SELinux module on this patch
> has increased due to the elimination of precondition functions.  Some of
> the changes in this patch may find their way back into the mainstream
> LSM patch in a more general form in the future (they have all been
> discussed on the LSM mailing list), but some changes are likely to
> remain
> SELinux-specific.



-- 
Kerry Thompson, CCNA CISSP
Information Systems Security Consultant
http://www.crypt.gen.nz  kerry@crypt.gen.nz




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Stephen Smalley]

On Wed, 30 Oct 2002, Russell Coker wrote:

> This means that I can't produce a single kernel-patch package that can be used
> by SE Linux, LIDS, and DTE users...

That isn't new; in prior releases, the SELinux-specific patch set the
SELinux option defaults in defconfig and set EXTRAVERSION to -selinux in
the top-level Makefile, so it wasn't appropriate for LIDS or DTE users
anyway.  [Are LIDS users now using the LSM kernel patch package, or are
they still using the separate LIDS package?  Are there any DTE users?]
For the separate SELinux patch to work for LIDS and DTE users, you would
need to drop those changes as well as #ifdef the initialization call.  You
would also need to add stub hook functions for inode_init to the LIDS and
DTE modules.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Stephen Smalley]

On Thu, 31 Oct 2002, Kerry Thompson wrote:

> The 'Everything in one Part' download at
> http://www.nsa.gov/selinux/archives/lsm-2.4-selinux-2002102211.tgz doesn't
> seem to have this patch included, and the NSA site isn't very clear that
> the patch is required. Could we please have the patch added to the next
> all-in-one snapshot?

The separate SELinux-specific patch is in that archive.  If you expand the
archive, you'll find it in selinux/module/selinux-2.4.patch.  If you
follow the installation instructions in selinux/README, that patch will be
applied to the lsm-2.4 tree prior to building the kernel.  The only change
from the prior release with regard to this issue was that the patch file
was renamed from lsm-2.4.patch to selinux-2.4.patch for clarity and the
set of changes within the patch have increased.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Russell Coker]

On Wed, 30 Oct 2002 22:45, Stephen Smalley wrote:
> > That isn't new; in prior releases, the SELinux-specific patch set the
> > SELinux option defaults in defconfig and set EXTRAVERSION to -selinux in
> > the top-level Makefile, so it wasn't appropriate for LIDS or DTE users
> > anyway.
>
> By the way, the EXTRAVERSION change was requested by you a year ago
> (distribution of kernel patches thread on the selinux list).  But I get

Correct.  However unofficial Debian policy regarding kernel patches changed 
after that time and I reluctantly changed my packages to match.

> the impression that you've been dropping the Makefile and defconfig
> changes from your kernel patch packages (not sure whether you have been
> including the netsyms.c changes, those are needed for building Selopt as a
> module, and are #ifdef'd appropriately).

I've just built a new kernel-patch package with this.  I'll upload it now.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Brian May]

On Wed, Oct 30, 2002 at 08:23:58AM -0500, Stephen Smalley wrote:
> You would only apply this patch if you intend to use SELinux, so it is
> implicit that SELinux is going to be enabled.  We could #ifdef it, but I'm

I find it considerably easier to maintain my kernel sources, if I only
need to maintain one kernel source tree for all systems.

This means I don't have the situation in several months time "I have to
compile this 3rd party closed source driver[1], but I can't remember how
I created the original kernel source." (This did happen to me recently
too, I thought I had the kernel tree safe, but I must have accidently
modified it somehow...) In comparision, keeping track of the config
files is very easy, Debian kernel packages do this automatically.

So I use the same kernel source now for all my systems. It has been
patched with not only SE-Linux, but also ISDN DOV[2], ISDN Voice, and
Freeswan. Sometime in the future I may also investigate adding the
EVMS patch (assuming it doesn't conflict in any way with any of the
other patches).

This doesn't mean that I want to use all of these features on all
systems (for instance I am not ready to install SE-Linux on all my
systems just yet), it just makes it easier to maintain.

So for now, I have patched my kernel source to make that init
call optional.

Another option I might consider is creating a extremely simply policy,
maybe with only one domain and give that domain access to everything.
That way I can install SE-Linux kernels on computers where I am not yet
ready to install a full blown SE-Linux policy, but at the same time not
flood the console with lots of warnings, or risk DOS attacks.

Notes:
[1] Unfortunately, sometimes as much as we all hate to use closed
    source drivers, it is the only choice, for instance with
    a certain brand (or maybe even any brand) of satellite cards.

[2] The DOV patch will be obsolete as of 2.4.20, it has been intergrated
    into the main kernel.
--
Brian May <bam@snoopy.apana.org.au>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Brian May]

On Wed, Oct 30, 2002 at 02:48:12PM -0500, Stephen Smalley wrote:
> For the separate SELinux patch to work for LIDS and DTE users, you would
> need to drop those changes as well as #ifdef the initialization call.  You
> would also need to add stub hook functions for inode_init to the LIDS and
> DTE modules.

What parts of the seperate SELinux patch would break LIDS and DTE users?
--
Brian May <bam@snoopy.apana.org.au>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Stephen Smalley]

On Thu, 31 Oct 2002, Brian May wrote:

> On Wed, Oct 30, 2002 at 02:48:12PM -0500, Stephen Smalley wrote:
> > For the separate SELinux patch to work for LIDS and DTE users, you would
> > need to drop those changes as well as #ifdef the initialization call.  You
> > would also need to add stub hook functions for inode_init to the LIDS and
> > DTE modules.
>
> What parts of the seperate SELinux patch would break LIDS and DTE users?

As I said, you would need to drop the Makefile and defconfig diffs
entirely, wrap the init/main.c diff with an #ifdef, and add inode_init
stub hook functions to LIDS and DTE.  I don't plan on dropping the
Makefile and defconfig diffs from our patch, but I'm willing to fix up the
other issues in our patch.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Russell Coker]

On Wed, 30 Oct 2002 23:08, Brian May wrote:
> On Wed, Oct 30, 2002 at 02:48:12PM -0500, Stephen Smalley wrote:
> > For the separate SELinux patch to work for LIDS and DTE users, you would
> > need to drop those changes as well as #ifdef the initialization call. 
> > You would also need to add stub hook functions for inode_init to the LIDS
> > and DTE modules.
>
> What parts of the seperate SELinux patch would break LIDS and DTE users?

I'm not sure.  It was my understanding of the conversation between you and 
Steve that some parts of SE Linux will be unconditionally enabled if you 
apply the second patch.  So in my latest kernel patch package I put a bunch 
of extra #ifdef's in...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: kernel warning

[Stephen Smalley]

On Wed, 30 Oct 2002, Russell Coker wrote:

> I'm not sure.  It was my understanding of the conversation between you and
> Steve that some parts of SE Linux will be unconditionally enabled if you
> apply the second patch.  So in my latest kernel patch package I put a bunch
> of extra #ifdef's in...

Yes, this works.  An alternative to #ifdef'ing the inode_init hook is to
simply add trivial stub foo_inode_init hook functions to the DTE and LIDS
modules, like the other hooks that are not truly used by those modules.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the xen tree got a conflict in
arch/x86/include/asm/spinlock.h between a series of commits  from the tip
tree and a smaller series of similar commits from the xen tree.

I see that Linus is commenting on these patches at the moment, and its
not easy to resolve the conflicts, so I will just use the xen tree from
next-20110824 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

On 08/24/2011 09:24 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/include/asm/spinlock.h between a series of commits from the tip
> tree and a smaller series of similar commits from the xen tree.
>
> I see that Linus is commenting on these patches at the moment, and its
> not easy to resolve the conflicts, so I will just use the xen tree from
> next-20110824 for today.
>

Thanks Stephen; the xen tree ones are more current, and I want to make
sure I didn't screw up any of the cmpxchg/xadd changes in a wider test env.

    J

Re: linux-next: manual merge of the xen tree with the tip tree

[H. Peter Anvin]

On 08/25/2011 11:13 AM, Jeremy Fitzhardinge wrote:
> On 08/24/2011 09:24 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the xen tree got a conflict in
>> arch/x86/include/asm/spinlock.h between a series of commits from the tip
>> tree and a smaller series of similar commits from the xen tree.
>>
>> I see that Linus is commenting on these patches at the moment, and its
>> not easy to resolve the conflicts, so I will just use the xen tree from
>> next-20110824 for today.
>>
> 
> Thanks Stephen; the xen tree ones are more current, and I want to make
> sure I didn't screw up any of the cmpxchg/xadd changes in a wider test env.
> 

Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
should be dropped.

	-hpa

Re: linux-next: manual merge of the xen tree with the tip tree

[H. Peter Anvin]

On 08/25/2011 11:13 AM, Jeremy Fitzhardinge wrote:
> On 08/24/2011 09:24 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the xen tree got a conflict in
>> arch/x86/include/asm/spinlock.h between a series of commits from the tip
>> tree and a smaller series of similar commits from the xen tree.
>>
>> I see that Linus is commenting on these patches at the moment, and its
>> not easy to resolve the conflicts, so I will just use the xen tree from
>> next-20110824 for today.
>>
> 
> Thanks Stephen; the xen tree ones are more current, and I want to make
> sure I didn't screw up any of the cmpxchg/xadd changes in a wider test env.
> 

Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
should be dropped.

	-hpa

Kernel Warning

[Carsten Schiers]

Is that a Xen thing that anybody's interested in?

BR,
Carsten.

[    0.011657] ------------[ cut here ]------------
[    0.011734] WARNING: at arch/x86/xen/enlighten.c:729 
init_hw_perf_events+0x337/0x3d7()
[    0.011834] Hardware name: M56S-S3
[    0.011908] Modules linked in:
[    0.012000] Pid: 0, comm: swapper Not tainted 2.6.32.44-xen-amd64 #6
[    0.012000] Call Trace:
[    0.012000]  [<ffffffff8104d70f>] ? warn_slowpath_common+0x76/0x8c
[    0.012000]  [<ffffffff814e216e>] ? init_hw_perf_events+0x337/0x3d7
[    0.012000]  [<ffffffff814e1c7b>] ? identify_boot_cpu+0x15/0x3d
[    0.012000]  [<ffffffff814e1e12>] ? check_bugs+0x9/0x2e
[    0.012000]  [<ffffffff814dace3>] ? start_kernel+0x3cb/0x3e5
[    0.012000]  [<ffffffff814dcba9>] ? xen_start_kernel+0x5e1/0x5e7
[    0.012000] ---[ end trace a7919e7f17c0a725 ]---

Re: Kernel Warning

[Ian Campbell]

On Thu, 2011-08-25 at 20:31 +0100, Carsten Schiers wrote:
> Is that a Xen thing that anybody's interested in?

It's a harmless warning but it gets reported a lot and it taints the
kernel which causes some confusion is there is subsequently another
error. I proposed toning it down a bit a couple of days ago:
http://marc.info/?l=xen-devel&m=131400621622691

Ian.

> 
> BR,
> Carsten.
> 
> [    0.011657] ------------[ cut here ]------------
> [    0.011734] WARNING: at arch/x86/xen/enlighten.c:729 
> init_hw_perf_events+0x337/0x3d7()
> [    0.011834] Hardware name: M56S-S3
> [    0.011908] Modules linked in:
> [    0.012000] Pid: 0, comm: swapper Not tainted 2.6.32.44-xen-amd64 #6
> [    0.012000] Call Trace:
> [    0.012000]  [<ffffffff8104d70f>] ? warn_slowpath_common+0x76/0x8c
> [    0.012000]  [<ffffffff814e216e>] ? init_hw_perf_events+0x337/0x3d7
> [    0.012000]  [<ffffffff814e1c7b>] ? identify_boot_cpu+0x15/0x3d
> [    0.012000]  [<ffffffff814e1e12>] ? check_bugs+0x9/0x2e
> [    0.012000]  [<ffffffff814dace3>] ? start_kernel+0x3cb/0x3e5
> [    0.012000]  [<ffffffff814dcba9>] ? xen_start_kernel+0x5e1/0x5e7
> [    0.012000] ---[ end trace a7919e7f17c0a725 ]---
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Kernel Warning

[Jeremy Fitzhardinge]

On 08/25/2011 12:39 PM, Ian Campbell wrote:
> On Thu, 2011-08-25 at 20:31 +0100, Carsten Schiers wrote:
>> Is that a Xen thing that anybody's interested in?
> It's a harmless warning but it gets reported a lot and it taints the
> kernel which causes some confusion is there is subsequently another
> error. I proposed toning it down a bit a couple of days ago:
> http://marc.info/?l=xen-devel&m=131400621622691

I'd tend towards just silently eating APIC writes, unless we want to go
through and try to silence each one at the source.

    J

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

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

Hi,

On Thu, 25 Aug 2011 11:26:37 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 08/25/2011 11:13 AM, Jeremy Fitzhardinge wrote:
> > On 08/24/2011 09:24 PM, Stephen Rothwell wrote:
> >>
> >> Today's linux-next merge of the xen tree got a conflict in
> >> arch/x86/include/asm/spinlock.h between a series of commits from the tip
> >> tree and a smaller series of similar commits from the xen tree.
> >>
> >> I see that Linus is commenting on these patches at the moment, and its
> >> not easy to resolve the conflicts, so I will just use the xen tree from
> >> next-20110824 for today.
> >>
> > 
> > Thanks Stephen; the xen tree ones are more current, and I want to make
> > sure I didn't screw up any of the cmpxchg/xadd changes in a wider test env.
> > 
> 
> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> should be dropped.

That's a bit tricky as I get a rolled up tip tree.  The best I could do
is revert the commit that merges the x86/spinlocks branch into
auto-latest ...  I'll do that for today (unless something happens to the
tip tree in the next hour).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the xen tree with the tip tree

[H. Peter Anvin]

On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
>>
>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
>> should be dropped.
> 
> That's a bit tricky as I get a rolled up tip tree.  The best I could do
> is revert the commit that merges the x86/spinlocks branch into
> auto-latest ...  I'll do that for today (unless something happens to the
> tip tree in the next hour).
> 

OK, let me bother Ingo about it.

	-hpa

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

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

On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> >>
> >> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> >> should be dropped.
> > 
> > That's a bit tricky as I get a rolled up tip tree.  The best I could do
> > is revert the commit that merges the x86/spinlocks branch into
> > auto-latest ...  I'll do that for today (unless something happens to the
> > tip tree in the next hour).
> > 
> 
> OK, let me bother Ingo about it.

For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
tip tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

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

Hi,

On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >
> > On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> > >>
> > >> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> > >> should be dropped.
> > > 
> > > That's a bit tricky as I get a rolled up tip tree.  The best I could do
> > > is revert the commit that merges the x86/spinlocks branch into
> > > auto-latest ...  I'll do that for today (unless something happens to the
> > > tip tree in the next hour).
> > > 
> > 
> > OK, let me bother Ingo about it.
> 
> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> tip tree.

I am still doing this in each linux-next, and it doesn't appear to have
been fixed up the the tree on tesla.tglx.de, yet, I think.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the xen tree with the tip tree

[Thomas Gleixner]

On Tue, 13 Sep 2011, Stephen Rothwell wrote:
> Hi,
> 
> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> > >
> > > On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> > > >>
> > > >> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> > > >> should be dropped.
> > > > 
> > > > That's a bit tricky as I get a rolled up tip tree.  The best I could do
> > > > is revert the commit that merges the x86/spinlocks branch into
> > > > auto-latest ...  I'll do that for today (unless something happens to the
> > > > tip tree in the next hour).
> > > > 
> > > 
> > > OK, let me bother Ingo about it.
> > 
> > For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> > tip tree.
> 
> I am still doing this in each linux-next, and it doesn't appear to have
> been fixed up the the tree on tesla.tglx.de, yet, I think.

We'll take it out. Thanks,

      tglx

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
> On Tue, 13 Sep 2011, Stephen Rothwell wrote:
>> Hi,
>>
>> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
>>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
>>>>>> should be dropped.
>>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
>>>>> is revert the commit that merges the x86/spinlocks branch into
>>>>> auto-latest ...  I'll do that for today (unless something happens to the
>>>>> tip tree in the next hour).
>>>>>
>>>> OK, let me bother Ingo about it.
>>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
>>> tip tree.
>> I am still doing this in each linux-next, and it doesn't appear to have
>> been fixed up the the tree on tesla.tglx.de, yet, I think.
> We'll take it out. 

Actually, the tip x86/spinlocks was the most up-to-date version of those
patches (since hpa had rebased them to a more recent version of mainline).

But never mind.  Stephen, could you use

    git://github.com/jsgf/linux-xen.git upstream/xen

for linux-next instead of the kernel.org xen.git, and I've re-added the
up-to-date spinlock changes there.

Thanks,
    J

Re: linux-next: manual merge of the xen tree with the tip tree

[Thomas Gleixner]

On Tue, 13 Sep 2011, Jeremy Fitzhardinge wrote:

> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
> > On Tue, 13 Sep 2011, Stephen Rothwell wrote:
> >> Hi,
> >>
> >> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> >>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> >>>>>> should be dropped.
> >>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
> >>>>> is revert the commit that merges the x86/spinlocks branch into
> >>>>> auto-latest ...  I'll do that for today (unless something happens to the
> >>>>> tip tree in the next hour).
> >>>>>
> >>>> OK, let me bother Ingo about it.
> >>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> >>> tip tree.
> >> I am still doing this in each linux-next, and it doesn't appear to have
> >> been fixed up the the tree on tesla.tglx.de, yet, I think.
> > We'll take it out. 
> 
> Actually, the tip x86/spinlocks was the most up-to-date version of those
> patches (since hpa had rebased them to a more recent version of mainline).

Mooo. You tell that after we did a nasty rebase from hell :(
 
Thanks,

	tglx

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

On 09/13/2011 01:56 PM, Thomas Gleixner wrote:
> On Tue, 13 Sep 2011, Jeremy Fitzhardinge wrote:
>
>> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
>>> On Tue, 13 Sep 2011, Stephen Rothwell wrote:
>>>> Hi,
>>>>
>>>> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>>>>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
>>>>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
>>>>>>>> should be dropped.
>>>>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
>>>>>>> is revert the commit that merges the x86/spinlocks branch into
>>>>>>> auto-latest ...  I'll do that for today (unless something happens to the
>>>>>>> tip tree in the next hour).
>>>>>>>
>>>>>> OK, let me bother Ingo about it.
>>>>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
>>>>> tip tree.
>>>> I am still doing this in each linux-next, and it doesn't appear to have
>>>> been fixed up the the tree on tesla.tglx.de, yet, I think.
>>> We'll take it out. 
>> Actually, the tip x86/spinlocks was the most up-to-date version of those
>> patches (since hpa had rebased them to a more recent version of mainline).
> Mooo. You tell that after we did a nasty rebase from hell :(

I'd been meaning to take it out of my tree to solve Stephen's problem,
but, well, kernel.org.

    J

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

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

Hi Jeremy,

On Tue, 13 Sep 2011 13:53:39 -0700 Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
> > On Tue, 13 Sep 2011, Stephen Rothwell wrote:
> >>
> >> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> >>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> >>>>>> should be dropped.
> >>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
> >>>>> is revert the commit that merges the x86/spinlocks branch into
> >>>>> auto-latest ...  I'll do that for today (unless something happens to the
> >>>>> tip tree in the next hour).
> >>>>>
> >>>> OK, let me bother Ingo about it.
> >>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> >>> tip tree.
> >> I am still doing this in each linux-next, and it doesn't appear to have
> >> been fixed up the the tree on tesla.tglx.de, yet, I think.
> > We'll take it out. 
> 
> Actually, the tip x86/spinlocks was the most up-to-date version of those
> patches (since hpa had rebased them to a more recent version of mainline).
> 
> But never mind.  Stephen, could you use
> 
>     git://github.com/jsgf/linux-xen.git upstream/xen
> 
> for linux-next instead of the kernel.org xen.git, and I've re-added the
> up-to-date spinlock changes there.

OK, I have switched to this from today.

My understanding is this:  I do *not* need to revert the spinlock changes
from tip anymore, correct?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

On 09/13/2011 05:32 PM, Stephen Rothwell wrote:
> Hi Jeremy,
>
> On Tue, 13 Sep 2011 13:53:39 -0700 Jeremy Fitzhardinge
<jeremy@goop.org> wrote:
>>
>> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
>>> On Tue, 13 Sep 2011, Stephen Rothwell wrote:
>>>>
>>>> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell
<sfr@canb.auug.org.au> wrote:
>>>>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com>
wrote:
>>>>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
>>>>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
>>>>>>>> should be dropped.
>>>>>>> That's a bit tricky as I get a rolled up tip tree. The best I
could do
>>>>>>> is revert the commit that merges the x86/spinlocks branch into
>>>>>>> auto-latest ... I'll do that for today (unless something happens
to the
>>>>>>> tip tree in the next hour).
>>>>>>>
>>>>>> OK, let me bother Ingo about it.
>>>>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
>>>>> tip tree.
>>>> I am still doing this in each linux-next, and it doesn't appear to have
>>>> been fixed up the the tree on tesla.tglx.de, yet, I think.
>>> We'll take it out.
>>
>> Actually, the tip x86/spinlocks was the most up-to-date version of those
>> patches (since hpa had rebased them to a more recent version of mainline).
>>
>> But never mind. Stephen, could you use
>>
>> git://github.com/jsgf/linux-xen.git upstream/xen
>>
>> for linux-next instead of the kernel.org xen.git, and I've re-added the
>> up-to-date spinlock changes there.
>
> OK, I have switched to this from today.
>
> My understanding is this: I do *not* need to revert the spinlock changes
> from tip anymore, correct?

Right.  tglx has removed these changes from tip.git (even though they
were OK), and I've reinstated the proper versions in my tree.  The
xen.git on git.kernel.org still has old versions, but I'll sort that out
once it's back online.  I expect it will ultimately go upstream via
tip.git, but we can work that out later too.

Thanks,
    J

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

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

Hi all,

On Wed, 14 Sep 2011 10:32:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> My understanding is this:  I do *not* need to revert the spinlock changes
> from tip anymore, correct?

Right, having looked at the tip tree, they are not in there any more.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]