PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[Alexandre Pereira Nunes]

Hi, I'm using kernel 2.4.19-pre10-ac2 and it just printed the pretty
message below. Other pertinent information follows.

CC: if needed, because I'm not in the list.

Cheers,

Alexandre
--

kernel BUG at page_alloc.c:131!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c014177e>]    Tainted: P
EFLAGS: 00010286
eax: cba53f48   ebx: c144955c   ecx: c025f6dc   edx: 00000000
esi: 00000000   edi: 138de070   ebp: 00001000   esp: c41b7ec8
ds: 0018   es: 0018   ss: 0018
Process X (pid: 3924, stackpage=c41b7000)
Stack: c144955c c0142fca c02ba2a0 00000000 00000001 c144955c 00000000
138de070
       d38de070 00000000 138de070 00001000 c01351c6 c144955c 0000000e
d2fca688
       0000000e 00000001 40400000 cd841404 4001d000 00000000 c013320b
d5decd40
Call Trace: [<c0142fca>] [<c01351c6>] [<c013320b>] [<c01367a1>]
[<c01368ca>]
   [<c010ba0f>]

Code: 0f 0b 83 00 53 b0 23 c0 8b 43 18 c6 43 24 05 89 f1 89 dd 83
 <3>X[3924] exited with preempt_count 1



-- 

The output of scripts/ver_linux:

If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux PolesApart 2.4.19-pre10-ac2 #1 Sat Jun 22 17:58:33 BRT 2002 i686
unknown

Gnu C                  gcc (GCC) 3.1 Copyright (C) 2002 Free Software
Foundation, Inc. This is free software; see the source for copying
conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.
Gnu make               3.79.1
util-linux             2.11r
mount                  2.11r
modutils               2.4.16
e2fsprogs              1.27
pcmcia-cs              3.1.33
PPP                    2.4.1
Linux C Library        2.2.5
Dynamic linker (ldd)   2.2.5
Linux C++ Library      4.0.0
Procps                 2.0.7
Net-tools              1.60
Kbd                    1.06
Sh-utils               2.0
Modules Loaded         ide-cd agpgart NVdriver cs4281 soundcore autofs
8139too mii sr_mod scsi_mod cdrom


# Output from /proc/cpuinfo

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 6
model		: 4
model name	: AMD Athlon(tm) Processor
stepping	: 2
cpu MHz		: 908.105
cache size	: 256 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips	: 1808.79


# Output from /proc/modules

ide-cd                 34072   0 (autoclean)
agpgart                15080   3 (autoclean)
NVdriver              999648  12 (autoclean)
cs4281                 49512   0
soundcore               4068   3 [cs4281]
autofs                 12388   1 (autoclean)
8139too                15784   1
mii                     1280   0 [8139too]
sr_mod                 15064   0 (autoclean) (unused)
scsi_mod               59636   1 (autoclean) [sr_mod]
cdrom                  29056   0 (autoclean) [ide-cd sr_mod]

# Output from /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
a400-a4ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C
  a400-a4ff : 8139too
d000-d01f : VIA Technologies, Inc. UHCI USB (#2)
d400-d41f : VIA Technologies, Inc. UHCI USB
d800-d80f : VIA Technologies, Inc. Bus Master IDE
  d800-d807 : ide0
  d808-d80f : ide1
e200-e27f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
e400-e4ff : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
e800-e80f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]

# Output from /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-15febfff : System RAM
  00100000-00230c70 : Kernel code
  00230c71-0026995f : Kernel data
15fec000-15feefff : ACPI Tables
15fef000-15ffefff : reserved
15fff000-15ffffff : ACPI Non-volatile Storage
d4800000-d48000ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C
  d4800000-d48000ff : 8139too
d5000000-d500ffff : Cirrus Logic Crystal CS4281 PCI Audio
d5800000-d5800fff : Cirrus Logic Crystal CS4281 PCI Audio
d6000000-d7dfffff : PCI Bus #01
  d6000000-d6ffffff : nVidia Corporation NV11 (GeForce2 MX DDR)
d7f00000-dfffffff : PCI Bus #01
  d8000000-dfffffff : nVidia Corporation NV11 (GeForce2 MX DDR)
e0000000-e7ffffff : VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
ffff0000-ffffffff : reserved

# lspci -vvv
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
	Subsystem: Asustek Computer, Inc. A7V Mainboard
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 8
	Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
	Capabilities: [a0] AGP version 2.0
		Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4
		Command: RQ=0 SBA- AGP+ 64bit- FW+ Rate=x4
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000e000-0000dfff
	Memory behind bridge: d6000000-d7dfffff
	Prefetchable memory behind bridge: d7f00000-dfffffff
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
	Subsystem: Asustek Computer, Inc. A7V Mainboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Region 4: I/O ports at d800 [size=16]
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:04.2 USB Controller: VIA Technologies, Inc. USB (rev 10) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32, cache line size 08
	Interrupt: pin D routed to IRQ 9
	Region 4: I/O ports at d400 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:04.3 USB Controller: VIA Technologies, Inc. USB (rev 10) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32, cache line size 08
	Interrupt: pin D routed to IRQ 9
	Region 4: I/O ports at d000 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:04.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
	Subsystem: Asustek Computer, Inc. A7V Mainboard
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin ? routed to IRQ 9
	Capabilities: [68] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0a.0 Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI Audio (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (1000ns min, 6000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at d5800000 (32-bit, non-prefetchable) [size=4K]
	Region 1: Memory at d5000000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10)
	Subsystem: Realtek Semiconductor Co., Ltd. RT8139
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (8000ns min, 16000ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at a400 [size=256]
	Region 1: Memory at d4800000 (32-bit, non-prefetchable) [size=256]
	Expansion ROM at <unassigned> [disabled] [size=64K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX DDR] (rev b2) (prog-if 00 [VGA])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 248 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at d6000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at d8000000 (32-bit, prefetchable) [size=128M]
	Expansion ROM at d7ff0000 [disabled] [size=64K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [44] AGP version 2.0
		Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2,x4
		Command: RQ=31 SBA- AGP+ 64bit- FW+ Rate=x4



#Xfree is the version bundled with slackware 8.1
XFree86 Version 4.2.0 / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 18 January 2002
        If the server is older than 6-12 months, or if your card is
        newer than the above date, look for a newer version before
        reporting problems.  (See http://www.XFree86.Org/)
Build Operating System: Linux 2.4.18 i686 [ELF]
Module Loader present

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[Diego Calleja]

On Sat, 22 Jun 2002 22:13:52 -0300 (BRT)
Alexandre Pereira Nunes <alex@PolesApart.dhs.org> escribió:
> 
> kernel BUG at page_alloc.c:131!
> invalid operand: 0000
> CPU:    0
> EIP:    0010:[<c014177e>]    Tainted: P
> EFLAGS: 00010286
> eax: cba53f48   ebx: c144955c   ecx: c025f6dc   edx: 00000000
> esi: 00000000   edi: 138de070   ebp: 00001000   esp: c41b7ec8
> ds: 0018   es: 0018   ss: 0018
> Process X (pid: 3924, stackpage=c41b7000)
> Stack: c144955c c0142fca c02ba2a0 00000000 00000001 c144955c 00000000
> 138de070
>        d38de070 00000000 138de070 00001000 c01351c6 c144955c 0000000e
> d2fca688
>        0000000e 00000001 40400000 cd841404 4001d000 00000000 c013320b
> d5decd40
> Call Trace: [<c0142fca>] [<c01351c6>] [<c013320b>] [<c01367a1>]
> [<c01368ca>]
>    [<c010ba0f>]
> 
> Code: 0f 0b 83 00 53 b0 23 c0 8b 43 18 c6 43 24 05 89 f1 89 dd 83
>  <3>X[3924] exited with preempt_count 1

It'd be nice if you could pass this oops throught ksymoops....

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[Alexandre Pereira Nunes]

On Sun, 23 Jun 2002, Diego Calleja wrote:

>
> It'd be nice if you could pass this oops throught ksymoops....
>

Ok, here it is...

Cheers,

Alexandre

>---------------------------------------------------

ksymoops 2.4.5 on i686 2.4.19-pre10-ac2.  Options used
     -v /usr/src/linux-2.4.19-pre/vmlinux (specified)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.19-pre10-ac2/ (default)
     -m /usr/src/linux/System.map (default)

kernel BUG at page_alloc.c:131!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c014177e>]    Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: cba53f48   ebx: c144955c   ecx: c025f6dc   edx: 00000000
esi: 00000000   edi: 138de070   ebp: 00001000   esp: c41b7ec8
ds: 0018   es: 0018   ss: 0018
Process X (pid: 3924, stackpage=c41b7000)
Stack: c144955c c0142fca c02ba2a0 00000000 00000001 c144955c 00000000 138de070
       d38de070 00000000 138de070 00001000 c01351c6 c144955c 0000000e d2fca688
       0000000e 00000001 40400000 cd841404 4001d000 00000000 c013320b d5decd40
Call Trace: [<c0142fca>] [<c01351c6>] [<c013320b>] [<c01367a1>] [<c01368ca>]
   [<c010ba0f>]
Code: 0f 0b 83 00 53 b0 23 c0 8b 43 18 c6 43 24 05 89 f1 89 dd 83


>>EIP; c014177e <__free_pages_ok+be/2a0>   <=====

>>eax; cba53f48 <_end+b77b478/165f9530>
>>ebx; c144955c <_end+1170a8c/165f9530>
>>ecx; c025f6dc <contig_page_data+dc/3c0>
>>edi; 138de070 Before first symbol
>>ebp; 00001000 Before first symbol
>>esp; c41b7ec8 <_end+3edf3f8/165f9530>

Trace; c0142fca <remove_exclusive_swap_page+ba/120>
Trace; c01351c6 <zap_pte_range+106/260>
Trace; c013320b <zap_page_range+9b/120>
Trace; c01367a1 <do_munmap+221/300>
Trace; c01368ca <sys_munmap+4a/70>
Trace; c010ba0f <system_call+33/38>

Code;  c014177e <__free_pages_ok+be/2a0>
00000000 <_EIP>:
Code;  c014177e <__free_pages_ok+be/2a0>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c0141780 <__free_pages_ok+c0/2a0>
   2:   83 00 53                  addl   $0x53,(%eax)
Code;  c0141783 <__free_pages_ok+c3/2a0>
   5:   b0 23                     mov    $0x23,%al
Code;  c0141785 <__free_pages_ok+c5/2a0>
   7:   c0 8b 43 18 c6 43 24      rorb   $0x24,0x43c61843(%ebx)
Code;  c014178c <__free_pages_ok+cc/2a0>
   e:   05 89 f1 89 dd            add    $0xdd89f189,%eax
Code;  c0141791 <__free_pages_ok+d1/2a0>
  13:   83 00 00                  addl   $0x0,(%eax)

-- 
Life would be so much easier if we could just look at the source code.

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[William Lee Irwin III]

On Sat, Jun 22, 2002 at 10:13:52PM -0300, Alexandre Pereira Nunes wrote:
> Hi, I'm using kernel 2.4.19-pre10-ac2 and it just printed the pretty
> message below. Other pertinent information follows.
> CC: if needed, because I'm not in the list.
> Cheers,
> Alexandre
>  <3>X[3924] exited with preempt_count 1

Would you mind showing us the patch you used to merge preempt into -ac?


Thanks,
Bill

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[Bongani]

IIRC the preemptive patch is now part of -ac

On Wed, 2002-06-26 at 22:47, William Lee Irwin III wrote:
> On Sat, Jun 22, 2002 at 10:13:52PM -0300, Alexandre Pereira Nunes wrote:
> > Hi, I'm using kernel 2.4.19-pre10-ac2 and it just printed the pretty
> > message below. Other pertinent information follows.
> > CC: if needed, because I'm not in the list.
> > Cheers,
> > Alexandre
> >  <3>X[3924] exited with preempt_count 1
> 
> Would you mind showing us the patch you used to merge preempt into -ac?
> 
> 
> Thanks,
> Bill
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[khromy]

On Wed, Jun 26, 2002 at 11:00:08PM +0200, Bongani wrote:
> IIRC the preemptive patch is now part of -ac

I don't think that's correct.  I currently have to apply rml's
preempt-kernel-rml-2.4.19-pre9-ac3-a.patch on top of 2.4.19-pre10-ac2 in
order to get preempt support.

-- 
L1:	khromy		;khromy(at)lnuxlab.ath.cx

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[Robert Love]

On Wed, 2002-06-26 at 17:00, Bongani wrote:
> IIRC the preemptive patch is now part of -ac

The preemptive kernel is not part of 2.4-ac.

Btw, fwiw, I do not think this problem has anything to do with
preemption.  The "exited with preempt_count" message just means the task
exited with preemption disabled.  It is not a problem if the task died
abnormally.

	Robert Love

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[Robert Love]

On Wed, 2002-06-26 at 18:12, Bongani wrote:
> Sorry I was confusing the preemptive patch with the O(1) patch
> I just remember that you worked on a patch for -ac ;) 

Ah yes O(1) is in 2.4-ac and I have been working on bits for Alan :)

	Robert Love

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[Bongani]

Sorry I was confusing the preemptive patch with the O(1) patch
I just remember that you worked on a patch for -ac ;) 



On Wed, 2002-06-26 at 23:54, Robert Love wrote:
> On Wed, 2002-06-26 at 17:00, Bongani wrote:
> > IIRC the preemptive patch is now part of -ac
> 
> The preemptive kernel is not part of 2.4-ac.
> 
> Btw, fwiw, I do not think this problem has anything to do with
> preemption.  The "exited with preempt_count" message just means the task
> exited with preemption disabled.  It is not a problem if the task died
> abnormally.
> 
> 	Robert Love
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[William Lee Irwin III]

On Wed, 2002-06-26 at 17:00, Bongani wrote:
> The preemptive kernel is not part of 2.4-ac.

On Wed, Jun 26, 2002 at 05:54:13PM -0400, Robert Love wrote:
> Btw, fwiw, I do not think this problem has anything to do with
> preemption.  The "exited with preempt_count" message just means the task
> exited with preemption disabled.  It is not a problem if the task died
> abnormally.

Well, my concern here is for the pte_chain_lock() / pte_chain_unlock()
bits. Teaching them about preemption should be all that's needed there.


Cheers,
Bill

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[Robert Love]

On Wed, 2002-06-26 at 20:54, William Lee Irwin III wrote:

> Well, my concern here is for the pte_chain_lock() / pte_chain_unlock()
> bits. Teaching them about preemption should be all that's needed there.

The newest patch should have the code I shared with you.  So we are OK,
no?

	Robert Love

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[William Lee Irwin III]

On Wed, 2002-06-26 at 20:54, William Lee Irwin III wrote:
>> Well, my concern here is for the pte_chain_lock() / pte_chain_unlock()
>> bits. Teaching them about preemption should be all that's needed there.

On Thu, Jun 27, 2002 at 11:40:39AM -0400, Robert Love wrote:
> The newest patch should have the code I shared with you.  So we are OK,
> no?

That should cover it, yes. The only questions left are if the user is
using the right version and where the bug is.

Cheers,
Bill

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[Alexandre P. Nunes]

William Lee Irwin III wrote:

>On Wed, 2002-06-26 at 20:54, William Lee Irwin III wrote:
>  
>
>>>Well, my concern here is for the pte_chain_lock() / pte_chain_unlock()
>>>bits. Teaching them about preemption should be all that's needed there.
>>>      
>>>
>
>On Thu, Jun 27, 2002 at 11:40:39AM -0400, Robert Love wrote:
>  
>
>>The newest patch should have the code I shared with you.  So we are OK,
>>no?
>>    
>>
>
>That should cover it, yes. The only questions left are if the user is
>using the right version and where the bug is.
>
>Cheers,
>Bill
>  
>
The user (oops, that is me) was using 
preempt-kernel-rml-2.4.19-pre10-ac2-1, by the time of the report.

Cheers,

Alexandre

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[Robert Love]

On Thu, 2002-06-27 at 14:29, Alexandre P. Nunes wrote:

> The user (oops, that is me) was using 
> preempt-kernel-rml-2.4.19-pre10-ac2-1, by the time of the report.

Ah try preempt-kernel-rml-2.4.19-pre10-ac2-2 which has the bit lock
safing William mentioned.

	Robert Love

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[Alexandre P. Nunes]

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

Robert Love wrote:

>On Thu, 2002-06-27 at 14:29, Alexandre P. Nunes wrote:
>
>  
>
>>The user (oops, that is me) was using 
>>preempt-kernel-rml-2.4.19-pre10-ac2-1, by the time of the report.
>>    
>>
>
>Ah try preempt-kernel-rml-2.4.19-pre10-ac2-2 which has the bit lock
>safing William mentioned.
>
>	Robert Love
>
>  
>
I'll, possibly at the weekend, since the machine is in home and I 
usually don't use it in business days. If I find something relevant, 
I'll send feedback.

Thank you, I'll upgrade my machine at work anyway. :-)

Alexandre

P.S..: Someone knows if 2.4.19-rc1 has O(1) applied?

Re: PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131

[J Sloan]

Alexandre P. Nunes wrote:

>
>
> P.S..: Someone knows if 2.4.19-rc1 has O(1) applied?
>
That would be nice... but no -

both -aa and -ac have it though, and it seems
solid, so maybe there's hope for 2.4 mainline
getting it eventually.

Joe

2.4.19-rc1 + O(1) scheduler

[Alexandre P. Nunes]

> That would be nice... but no -
>
> both -aa and -ac have it though, and it seems
> solid, so maybe there's hope for 2.4 mainline
> getting it eventually.
>
> Joe
>
>
It seems that the version of O(1) scheduler on 2.4.19-pre10-ac2 is not 
perfect (see below), but I asked because it gave me overall performance 
gains, specially in multithreading programs (and now I'm going to try 
with ngpt 2.00). At least that is the first impression, I'm trying it 
for a few days.

I said "not perfect" because a rather non-important benchmarking called 
quake 3 seens a lot worse in pre10-ac2 with preemptive patches when 
compared against -pre10 with preemptive patches: sound and screen popped 
sometimes, like if there was a background task borrowing some cpu, which 
was not the case, I mean, no other background tasks compared with 
testing against -pre10. That was the only exception to the above 
paragraph that I can remember of.

Anyway, that "benchmarking tool" isn't rather serious and I'm no 
benchmarking expert :-)

Thank you,

Alexandre

Re: 2.4.19-rc1 + O(1) scheduler

[J Sloan]

Alexandre P. Nunes wrote:

>> That would be nice... but no -
>>
>> both -aa and -ac have it though, and it seems
>> solid, so maybe there's hope for 2.4 mainline
>> getting it eventually.
>>
>> Joe
>>
>>
>
> I said "not perfect" because a rather non-important benchmarking 
> called quake 3 seens a lot worse in pre10-ac2 with preemptive patches 
> when compared against -pre10 with preemptive patches: sound and screen 
> popped sometimes, like if there was a background task borrowing some 
> cpu, which was not the case, I mean, no other background tasks 
> compared with testing against -pre10. That was the only exception to 
> the above paragraph that I can remember of.

I am running -pre10-ac2 on one box - but also
the preemptive patch - are you running that?

On another box, I'm running -pre10aa4, which
also includes the low latency mini patch.

I also follow the q3a benchmark closely, and
RtCW as well. (The enemy is weakened!)

-ac + preempt and -aa both seem OK here, but
I prefer -aa since I use tux.

Joe

Re: 2.4.19-rc1 + O(1) scheduler

[Robert Love]

	
	.GK22961@holomorphy.com>	<1025125214.1911.40.camel@localhost.localdomain>	<1
	 025128477.1144.3.camel@icbm>
	<20020627005431.GM22961@holomorphy.com>	<1025192465.1084.3.camel@icbm>
	<20020627154712.GO22961@holomorphy.com> <3D1B5982.60008@PolesApart.dhs.org>
	<1025202738.1084.12.camel@icbm> <3D1B5F1D.2000706@PolesApart.wox.org>
	<3D1B7005.2090200@tmsusa.com>  <3D1B7440.3040605@PolesApart.wox.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) 
Date: 27 Jun 2002 16:35:46 -0400
Message-Id: <1025210179.1080.22.camel@icbm>
Mime-Version: 1.0

On Thu, 2002-06-27 at 16:23, Alexandre P. Nunes wrote:

> It seems that the version of O(1) scheduler on 2.4.19-pre10-ac2 is not 
> perfect (see below), but I asked because it gave me overall performance 
> gains, specially in multithreading programs (and now I'm going to try 
> with ngpt 2.00). At least that is the first impression, I'm trying it 
> for a few days.

Alan has some patches queued and I will continue to send him updates as
we get them into 2.5 and they prove stable.

I also will update my 2.4 O(1) scheduler patches when I return from
OLS.  This would allow a 2.4-ac vs 2.4-O(1) test.

> I said "not perfect" because a rather non-important benchmarking called 
> quake 3 seens a lot worse in pre10-ac2 with preemptive patches when 
> compared against -pre10 with preemptive patches: sound and screen popped 
> sometimes, like if there was a background task borrowing some cpu, which 
> was not the case, I mean, no other background tasks compared with 
> testing against -pre10. That was the only exception to the above 
> paragraph that I can remember of.

There is some "rudeness" in the current O(1) scheduler code in 2.4-ac
that could result in poor latency under certain workloads.

The patch should be in a near future 2.4-ac although I will need to
update the preempt-kernel patch to take advantage of it.

	Robert Love