is this a bug?

is this a bug?

[Thodoris Pitikaris]

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

As you will see in the attached file (it's a dmesg from the boot)
I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX 
motherboard with 100mhz SDRAM.When I compiled the kernel with 
cputype=Athlon I continiusly experienced this crash.When I compiled with 
cputype=i686 everything went smooth (OS is Redhat 7.1)        
Yours

Theodore Pitikaris

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

Linux version 2.4.8-pre4 (root@feidias.kerkyra.gr) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)) #1 Ôñé Áýã 7 13:28:12 EEST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000bff0000 (usable)
 BIOS-e820: 000000000bff0000 - 000000000bff8000 (ACPI data)
 BIOS-e820: 000000000bff8000 - 000000000c000000 (ACPI NVS)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
On node 0 totalpages: 49136
zone(0): 4096 pages.
zone(1): 45040 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=new ro root=306 BOOT_FILE=/boot/2.4.8 lba32
Initializing CPU#0
Detected 1002.302 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1998.84 BogoMIPS
Memory: 191352k/196544k available (834k kernel code, 4804k reserved, 286k data, 188k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU:     After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU:             Common caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... 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
PCI: PCI BIOS revision 2.10 entry at 0xfdb71, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
Applying VIA PCI latency patch (found VT82C686B).
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
block: 128 slots per queue, batch=16
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA
hda: QUANTUM FIREBALLlct08 17, ATA DISK drive
hdb: ST39140A, ATA DISK drive
hdc: ASUS DVD-ROM E608, ATAPI CD/DVD-ROM drive
hdd: SONY CDU4811, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 33906432 sectors (17360 MB) w/418KiB Cache, CHS=2110/255/63, UDMA(33)
hdb: 17803440 sectors (9115 MB) w/448KiB Cache, CHS=1108/255/63, UDMA(33)
hdc: ATAPI 40X DVD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 48X CD-ROM drive, 120kB Cache, UDMA(33)
Partition check:
 hda: hda1 hda2 < hda5 hda6 >
 hdb: hdb1
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 149M
agpgart: Detected Via Apollo Pro KT133 chipset
agpgart: AGP aperture is 64M @ 0xe0000000
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 188k freed
Adding Swap: 248968k swap-space (priority -1)
memory.c:83: bad pmd c5e77b40.
memory.c:83: bad pmd c5e5e000.
memory.c:83: bad pmd c020ac74.
memory.c:83: bad pmd c117f59c.
memory.c:83: bad pmd c020ac98.
memory.c:83: bad pmd 00000001.
memory.c:83: bad pmd 00000002.
kernel BUG at page_alloc.c:73!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129603>]
EFLAGS: 00010282
eax: 0000001f   ebx: c1324048   ecx: 00000001   edx: c02099e4
esi: c1324048   edi: 00000000   ebp: c675e1d8   esp: cbc2de7c
ds: 0018   es: 0018   ss: 0018
Process ifup-aliases (pid: 161, stackpage=cbc2d000)
Stack: c01d98a6 c01d997a 00000049 c01cbf4f c11b0ac8 c117f844 c011fc7c c65ce000 
       c1324048 c1324048 00048000 c675e1d8 c012a535 4015dcbc ffffffff 00000001 
       c13cd440 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000 
Call Trace: [<c01cbf4f>] [<c011fc7c>] [<c012a535>] [<c011ef04>] [<c010fd50>] [<c010fec6>] [<c0121638>] 
       [<c01385ba>] [<c0111a66>] [<c0115832>] [<c01109a4>] [<c010fd50>] [<c0106ecb>] 

Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68 
kernel BUG at page_alloc.c:73!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129603>]
EFLAGS: 00010282
eax: 0000001f   ebx: c1324048   ecx: 00000001   edx: c02099e4
esi: c1324048   edi: 00000000   ebp: c66fb1d8   esp: cbc2de7c
ds: 0018   es: 0018   ss: 0018
Process ifup-aliases (pid: 163, stackpage=cbc2d000)
Stack: c01d98a6 c01d997a 00000049 c01cbf4f c11d34e0 c117f844 c011fc7c c6df4000 
       c1324048 c1324048 00048000 c66fb1d8 c012a535 4015dcbc ffffffff 00000001 
       c13cd380 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000 
Call Trace: [<c01cbf4f>] [<c011fc7c>] [<c012a535>] [<c011ef04>] [<c010fd50>] [<c010fec6>] [<c0121638>] 
       [<c01385ba>] [<c0111a66>] [<c0115832>] [<c01109a4>] [<c010fd50>] [<c0106ecb>] 

Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68 
kernel BUG at page_alloc.c:73!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129603>]
EFLAGS: 00010286
eax: 0000001f   ebx: c1324048   ecx: 00000001   edx: c02099e4
esi: c1324048   edi: 00000000   ebp: c6f511d8   esp: c4ab5b80
ds: 0018   es: 0018   ss: 0018
Process ifup-post (pid: 170, stackpage=c4ab5000)
Stack: c01d98a6 c01d997a 00000049 c4ab5c88 cbfe56c0 c01398ac cbfe55c0 00000001 
       c1324048 c1324048 00048000 c6f511d8 c012a535 08054b88 00000001 40016000 
       c4ab4000 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000 
Call Trace: [<c01398ac>] [<c012a535>] [<c011ef04>] [<c0142cba>] [<c0122c43>] [<c0121638>] [<c0122d10>] 
       [<c01375a3>] [<c0137710>] [<c01454ff>] [<c01c5507>] [<c01450c0>] [<c0137c6f>] [<c0137efb>] [<c0138dad>] 
       [<c0105b4d>] [<c0106ecb>] 

Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68 
exit_mmap: map count is 25
PCI: Found IRQ 10 for device 00:0d.0
3c59x.c:LK1.1.15 6 June 2001  Donald Becker and others. http://www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
00:0d.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xd400,  00:60:08:7e:13:4b, IRQ 10
  product code 4b4b rev 00.0 date 01-25-98
  8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
  MII transceiver found at address 24, status 786f.
  Enabling bus-master transmits and whole-frame receives.
00:0d.0: scatter/gather enabled. h/w checksums disabled
eth0: first available media type: MII
kernel BUG at page_alloc.c:73!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129603>]
EFLAGS: 00010286
eax: 0000001f   ebx: c1324048   ecx: 00000001   edx: c02099e4
esi: c1324048   edi: 00000000   ebp: c609a1d8   esp: cbbafb80
ds: 0018   es: 0018   ss: 0018
Process S10network (pid: 256, stackpage=cbbaf000)
Stack: c01d98a6 c01d997a 00000049 cbbafc88 cbfe56c0 c01398ac cbfe55c0 00000001 
       c1324048 c1324048 00048000 c609a1d8 c012a535 cbbae000 080c5dd4 c0144a2c 
       080c5dd4 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000 
Call Trace: [<c01398ac>] [<c012a535>] [<c0144a2c>] [<c011ef04>] [<c0142cba>] [<c0122c43>] [<c0121638>] 
       [<c0122d10>] [<c01375a3>] [<c0137710>] [<c01454ff>] [<c0137caf>] [<c01450c0>] [<c0137c6f>] [<c0137efb>] 
       [<c0138dad>] [<c0105b4d>] [<c0106ecb>] 

Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68 
exit_mmap: map count is 25
kernel BUG at page_alloc.c:168!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129a84>]
EFLAGS: 00010082
eax: 00000020   ebx: c11600a4   ecx: 00000001   edx: c02099e4
esi: c020ac98   edi: 00000001   ebp: 00000000   esp: c9f97e54
ds: 0018   es: 0018   ss: 0018
Process S85gpm (pid: 365, stackpage=c9f97000)
Stack: c01d98a6 c01d997a 000000a8 000042d5 00000286 00000000 c020ac74 c020ac74 
       c020ae00 00000000 000000d2 c0129c74 00000001 c020adfc bfffefe0 c1312168 
       0b8f6065 c13cda40 c011fc41 c020ac74 c020ac74 c020ade0 00000000 bfffefe0 
Call Trace: [<c0129c74>] [<c011fc41>] [<c01202f0>] [<c01cbe3d>] [<c010fd50>] [<c010fec6>] [<c0111d4a>] 
       [<c0112757>] [<c012ef22>] [<c010fd50>] [<c0106fbc>] 

Code: 0f 0b 83 c4 0c ff 74 24 04 9d c7 43 14 01 00 00 00 8b 44 24 

Re: is this a bug?

[Andrzej Krzysztofowicz]

"Thodoris Pitikaris wrote:"
> As you will see in the attached file (it's a dmesg from the boot)
> I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX 
> motherboard with 100mhz SDRAM.When I compiled the kernel with 
> cputype=Athlon I continiusly experienced this crash.When I compiled with 
> cputype=i686 everything went smooth (OS is Redhat 7.1)        

Try the newest -ac patches. They contain discussed on the list workaround
for a VIA chipset bug.
VIA chipsets seem to be unstable when processing fast memory-to-memory
copy.

It is definitely not an Athlon processor problem.

Andrzej
-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk

Re: is this a bug?

[Dr. Kelsey Hudson]

On Tue, 7 Aug 2001, Thodoris Pitikaris wrote:

> As you will see in the attached file (it's a dmesg from the boot)
> I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX
> motherboard with 100mhz SDRAM.When I compiled the kernel with
> cputype=Athlon I continiusly experienced this crash.When I compiled with
> cputype=i686 everything went smooth (OS is Redhat 7.1)

It's a bug in that screwed up compiler redhat shipped with 7.1. AFAIK, the
only difference between an athlon-specific kernel and an i686-specific
kernel are the options in the compiler command line when compiling the
kernel.

Is gcc 3.0 binary compatible with the stupid redhat compiler? If it is, I
would upgrade to that. I haven't, myself, because I simply don't know (and
can't find any information one way or the other) if binaries from the two
compilers are compatible. Someone who knows better, could you shed some
light on the subject?

 Kelsey Hudson                                           khudson@ctica.com
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------

Re: is this a bug?

[J Sloan]

"Dr. Kelsey Hudson" wrote:

> It's a bug in that screwed up compiler redhat shipped with 7.1.

Oh please, not this FUD again.....

jjs

Re: is this a bug?

[Dr. Kelsey Hudson]

On Tue, 7 Aug 2001, J Sloan wrote:

> "Dr. Kelsey Hudson" wrote:

> > It's a bug in that screwed up compiler redhat shipped with 7.1.

> Oh please, not this FUD again.....

Call it what you wish -- But, if I see something break when using a
certain compiler option versus another compiler option that does not
cause a break, chances are it's a bug in the compiler. After all, the
Athlon support *is* a new feature, is it not?

I don't even know why I bothered replying. Don't feed the trolls... Gotta
watch for those signs....

 Kelsey Hudson                                           khudson@ctica.com
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------

Re: is this a bug?

[David Weinehall]

On Tue, Aug 07, 2001 at 08:45:15PM -0700, Dr. Kelsey Hudson wrote:
> On Tue, 7 Aug 2001, J Sloan wrote:
> 
> > "Dr. Kelsey Hudson" wrote:
> 
> > > It's a bug in that screwed up compiler redhat shipped with 7.1.
> 
> > Oh please, not this FUD again.....
> 
> Call it what you wish -- But, if I see something break when using a
> certain compiler option versus another compiler option that does not
> cause a break, chances are it's a bug in the compiler. After all, the
> Athlon support *is* a new feature, is it not?
> 
> I don't even know why I bothered replying. Don't feed the trolls... Gotta
> watch for those signs....

Ah, but if you'd been observant you'd have noticed what kind of motherboard
he has (a VIA) and if you have been reading your kernel-list lately,
you'd have known that almost noone has been able to get a Athlon-optimized
kernel to work in a stable manner on those; probably because of the
Athlon-optimizations stressing the hardware too much.

I'd say flakey hardware is the problem here, not the compiler.


/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: is this a bug?

[Alan Cox]

> > cputype=Athlon I continiusly experienced this crash.When I compiled with
> > cputype=i686 everything went smooth (OS is Redhat 7.1)
> 
> It's a bug in that screwed up compiler redhat shipped with 7.1. AFAIK, the
> only difference between an athlon-specific kernel and an i686-specific
> kernel are the options in the compiler command line when compiling the
> kernel.

Please stop deliberately spreading misinformation. The last thing an end
user with a problem needs is a bigot with an axe to grind lying to them to
make a political point.

Its the classic 'bought the wrong VIA chipset mainboard' problem

Alan

Re: is this a bug?

[Ron Flory]

"Dr. Kelsey Hudson" wrote:
> 
> On Tue, 7 Aug 2001, Thodoris Pitikaris wrote:
> 
> > As you will see in the attached file (it's a dmesg from the boot)
> > I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX
> > motherboard with 100mhz SDRAM.When I compiled the kernel with
> > cputype=Athlon I continiusly experienced this crash.When I compiled with
> > cputype=i686 everything went smooth (OS is Redhat 7.1)
> 
> It's a bug in that screwed up compiler redhat shipped with 7.1. AFAIK, the
> only difference between an athlon-specific kernel and an i686-specific
> kernel are the options in the compiler command line when compiling the
> kernel.

 RH has posted updates to many of the gcc-xxx tools, have you installed
the updated compilers and libraries ?

ron

Re: is this a bug?

[jury gerold]

I have the same motherboard, same chipset, same CPU and the same crash.
No memory test cpu burn UDMA on/off, replace or remove of components
did any good.
Then i replaced the 100mhz SDRAM with a 133mhz and it is 100 % stable 
since then.
No matter which compiler, kernel version, cputype.
It simply works now.

Gerold

Thodoris Pitikaris wrote:

> As you will see in the attached file (it's a dmesg from the boot)
> I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX 
> motherboard with 100mhz SDRAM.When I compiled the kernel with 
> cputype=Athlon I continiusly experienced this crash.When I compiled 
> with cputype=i686 everything went smooth (OS is Redhat 7.1)        Yours
>
> Theodore Pitikaris

Re: is this a bug?

[Eric W. Biederman]

jury gerold <geroldj@grips.com> writes:

> I have the same motherboard, same chipset, same CPU and the same crash.
> No memory test cpu burn UDMA on/off, replace or remove of components
> did any good.
> Then i replaced the 100mhz SDRAM with a 133mhz and it is 100 % stable since
> then.
> 
> No matter which compiler, kernel version, cputype.
> It simply works now.

Do you happen to have the SDRAM timings of the two sets of DIMMS?
It would be interesting to see what changed besides the clock speed on
the DIMMS.  I'm assuming your PC133 DIMMs are running at at 133Mhz,
and you aren't over clocking anything.

Eric

Re: is this a bug?

[jury gerold]

Hi Eric

The CPU is a 1.1GHz tbird 200MHz FSB and i am running it this way.
The motherboard can do 100 and 133 MHz but i run
the SDRAM at 100MHz from the beginning, since i have seen lot's
of boards with memory problems and i wanted to be on the good side.
Both, the old 128MB and the new 256MB SDRAM where sold as PC133.
It is a single DIMM in both cases.

When i started to sue the SDRAM for the trouble i checked the SPD and found
the 128MB-PC133 was actually a PC100 with a few steps towards PC66 
(major brand).
So i tried a new one that, at least from the SPD, is a real PC133 and 
suddenly ...

I have tried to kill it

kernel 2.4.7-xfs from cvs at the moment
athlon optimisations
UDMA on ide0 and ide1
2 harddrives, 1 cdrom, 1 cd/rw

since then, but it works, works, works.


This weekend does not see me at home.
I will send the timings on sunday/monday.

What do you expect to get out of this ?

Gerold


Eric W. Biederman wrote:

>jury gerold <geroldj@grips.com> writes:
>
>>I have the same motherboard, same chipset, same CPU and the same crash.
>>No memory test cpu burn UDMA on/off, replace or remove of components
>>did any good.
>>Then i replaced the 100mhz SDRAM with a 133mhz and it is 100 % stable since
>>then.
>>
>>No matter which compiler, kernel version, cputype.
>>It simply works now.
>>
>
>Do you happen to have the SDRAM timings of the two sets of DIMMS?
>It would be interesting to see what changed besides the clock speed on
>the DIMMS.  I'm assuming your PC133 DIMMs are running at at 133Mhz,
>and you aren't over clocking anything.
>
>Eric
>

Re: is this a bug?

[Eric W. Biederman]

jury gerold <geroldj@grips.com> writes:

> Hi Eric
> 
> The CPU is a 1.1GHz tbird 200MHz FSB and i am running it this way.
> The motherboard can do 100 and 133 MHz but i run
> the SDRAM at 100MHz from the beginning, since i have seen lot's
> of boards with memory problems and i wanted to be on the good side.
> Both, the old 128MB and the new 256MB SDRAM where sold as PC133.
> It is a single DIMM in both cases.
> 
> When i started to sue the SDRAM for the trouble i checked the SPD and found
> the 128MB-PC133 was actually a PC100 with a few steps towards PC66 (major
> brand).
> 
> So i tried a new one that, at least from the SPD, is a real PC133 and suddenly
> ...
> 
> I have tried to kill it
> 
> kernel 2.4.7-xfs from cvs at the moment
> athlon optimisations
> UDMA on ide0 and ide1
> 2 harddrives, 1 cdrom, 1 cd/rw
> 
> since then, but it works, works, works.
> 
> 
> This weekend does not see me at home.
> I will send the timings on sunday/monday.
> 
> What do you expect to get out of this ?

Mostly I am curious about what is going on.  I work on linuxBIOS so
(a) I might just have to figure out if there are software work arounds
    if/when I port to this platform. 
(b) I have written enough memory setup code that does SPD on the fly,
    to compute the DIMM timings, that understanding DIMMS and memory
    controllers is one of my areas of competence.

If the ram was really PC100 mislabeled, as PC133 and it was being run
at 133Mhz I can see the problem.  If it was only being run as PC100
I have a problem seeing, why you would have a problem.

Eric

Is this a bug?

[Peter Teoh]

I got this crashdump inside QEMU (running 4.11.0 stable):


[    0.588497] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    1.778428] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
[    2.991744] pci 0000:00:02.0: Video device with shadowed ROM at
[mem 0x000c0000-0x000dffff]
[    2.992993] Unpacking initramfs...
[  453.628449] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 21s!
[swapper/0:1]
[  453.629130] Modules linked in:
[  453.629370] irq event stamp: 6845090
[  453.629710] hardirqs last  enabled at (6845089):
[<ffffffff816b8c6c>] mem_cgroup_commit_charge+0x15c/0x2f0
[  453.630462] hardirqs last disabled at (6845090):
[<ffffffff82cf51ee>] apic_timer_interrupt+0x8e/0xa0
[  453.631147] softirqs last  enabled at (6844578):
[<ffffffff82cf9dd4>] __do_softirq+0x664/0x883
[  453.631780] softirqs last disabled at (6844571):
[<ffffffff8118cc53>] irq_exit+0x1a3/0x1d0
[  453.632359] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0syz #7
[  453.632890] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[  453.633605] task: ffff880064a48040 task.stack: ffff880064a50000
[  453.634113] RIP: 0010:__memset+0x24/0x30
[  453.634384] RSP: 0000:ffff880064a576a0 EFLAGS: 00010206 ORIG_RAX:
ffffffffffffff10
[  453.634901] RAX: 0000000000000000 RBX: ffff8800378001e0 RCX: 00000000000001c4
[  453.635366] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800378001e0
[  453.635829] RBP: ffff880064a576c0 R08: 0000000000000000 R09: ffff8800378001e0
[  453.636290] R10: ffff880037800fff R11: 0000000000000000 R12: 0000000000000e20
[  453.636826] R13: 0000000000000000 R14: ffff880064a48040 R15: 00000000000001e0
[  453.637320] FS:  0000000000000000(0000) GS:ffff880065400000(0000)
knlGS:0000000000000000
[  453.637835] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  453.638208] CR2: 0000000000000000 CR3: 0000000003613000 CR4: 00000000000006f0
[  453.638684] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  453.639339] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  453.639944] Call Trace:
[  453.640119]  ? memset+0x31/0x40
[  453.640436]  simple_write_begin+0x18f/0x2b0
[  453.640799]  generic_perform_write+0x274/0x520
[  453.641204]  ? __page_cache_alloc+0x310/0x310
[  453.641532]  ? file_update_time+0xce/0x3d0
[  453.641821]  ? current_time+0xd0/0xd0
[  453.642135]  ? lock_acquire+0x17d/0x350
[  453.642457]  __generic_file_write_iter+0x32f/0x5b0
[  453.642806]  generic_file_write_iter+0x2ea/0x600
[  453.643162]  __vfs_write+0x3d4/0x650
[  453.643435]  ? vfs_iter_write+0x550/0x550
[  453.643772]  ? rcu_sync_lockdep_assert+0x78/0xb0
[  453.644092]  ? __sb_start_write+0x1ed/0x2b0
[  453.644499]  vfs_write+0x175/0x4e0
[  453.644741]  SyS_write+0xe8/0x1d0
[  453.644996]  ? SyS_read+0x1d0/0x1d0
[  453.645275]  ? zlib_inflate+0x282/0x5d40
[  453.645574]  xwrite+0x36/0x8a
[  453.645831]  do_copy+0xb5/0xf6
[  453.646070]  write_buffer+0x5d/0x77
[  453.646387]  flush_buffer+0x3a/0xff
[  453.646658]  __gunzip+0x64e/0x7e6
[  453.646929]  ? bunzip2+0x980/0x980
[  453.647164]  ? write_buffer+0x77/0x77
[  453.647461]  ? write_buffer+0x77/0x77
[  453.647721]  gunzip+0x43/0x52
[  453.647942]  ? md_run_setup+0xad/0xad
[  453.648225]  ? __gunzip+0x7e6/0x7e6
[  453.648535]  unpack_to_rootfs+0x284/0x527
[  453.648822]  ? md_run_setup+0xad/0xad
[  453.649091]  ? do_reset+0x91/0x91
[  453.649377]  populate_rootfs+0x116/0x344
[  453.649657]  ? maybe_link.part.5+0x31c/0x31c
[  453.650089]  do_one_initcall+0xb9/0x290
[  453.650384]  ? initcall_blacklisted+0x1b0/0x1b0
[  453.650732]  ? parse_args+0x228/0xb60
[  453.651008]  kernel_init_freeable+0x49a/0x54e
[  453.651348]  ? rest_init+0x190/0x190
[  453.651650]  kernel_init+0x18/0x180
[  453.651965]  ? rest_init+0x190/0x190
[  453.652223]  ret_from_fork+0x31/0x40
[  453.652543] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 f9 48
89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01
48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48
89 d1
[  530.660850] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 21s!
[swapper/0:1]
[  530.661442] Modules linked in:
[  530.661679] irq event stamp: 6876482
[  530.661939] hardirqs last  enabled at (6876481):
[<ffffffff816b8c6c>] mem_cgroup_commit_charge+0x15c/0x2f0
[  530.662715] hardirqs last disabled at (6876482):
[<ffffffff82cf51ee>] apic_timer_interrupt+0x8e/0xa0
[  530.663385] softirqs last  enabled at (6876448):
[<ffffffff82cf9dd4>] __do_softirq+0x664/0x883
[  530.664000] softirqs last disabled at (6876441):
[<ffffffff8118cc53>] irq_exit+0x1a3/0x1d0
[  530.664728] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G             L
4.11.0syz #7
[  530.665360] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[  530.666139] task: ffff880064a48040 task.stack: ffff880064a50000
[  530.666649] RIP: 0010:__memcpy+0x12/0x20
[  530.667065] RSP: 0000:ffff880064a57670 EFLAGS: 00010246 ORIG_RAX:
ffffffffffffff10
[  530.668093] RAX: ffff8800aac00000 RBX: 0000000000001000 RCX: 0000000000000200
[  530.668694] RDX: 0000000000000000 RSI: ffff8800627fc394 RDI: ffff8800aac00000
[  530.669348] RBP: ffff880064a57690 R08: 0000000000000000 R09: ffffed00155801ff
[  530.669978] R10: ffff8800aac00fff R11: 0000000000000000 R12: ffff8800aac00000
[  530.670715] R13: ffff8800627fc394 R14: ffffffff82f737c0 R15: ffff880064a57948
[  530.671329] FS:  0000000000000000(0000) GS:ffff880065400000(0000)
knlGS:0000000000000000
[  530.672049] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  530.672560] CR2: 0000000000000000 CR3: 0000000003613000 CR4: 00000000000006f0
[  530.673212] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  530.673818] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  530.674432] Call Trace:
[  530.674717]  ? memcpy+0x45/0x50
[  530.675051]  iov_iter_copy_from_user_atomic+0x67d/0x8a0
[  530.675537]  ? grab_cache_page_write_begin+0x8b/0xa0
[  530.675999]  generic_perform_write+0x2df/0x520
[  530.676397]  ? __mark_inode_dirty+0x2c0/0xe90
[  530.676816]  ? __page_cache_alloc+0x310/0x310
[  530.677269]  ? __mnt_drop_write_file+0x12/0x70
[  530.677686]  ? file_update_time+0xce/0x3d0
[  530.678047]  ? current_time+0xd0/0xd0
[  530.678422]  ? lock_acquire+0x17d/0x350
[  530.678795]  __generic_file_write_iter+0x32f/0x5b0
[  530.679240]  generic_file_write_iter+0x2ea/0x600
[  530.679643]  __vfs_write+0x3d4/0x650
[  530.680038]  ? vfs_iter_write+0x550/0x550
[  530.680440]  ? rcu_sync_lockdep_assert+0x78/0xb0
[  530.680900]  ? __sb_start_write+0x1ed/0x2b0
[  530.681313]  vfs_write+0x175/0x4e0
[  530.681676]  SyS_write+0xe8/0x1d0
[  530.681966]  ? SyS_read+0x1d0/0x1d0
[  530.682306]  ? zlib_inflate+0x282/0x5d40
[  530.682684]  xwrite+0x36/0x8a
[  530.682988]  do_copy+0xb5/0xf6
[  530.683396]  write_buffer+0x5d/0x77
[  530.683741]  flush_buffer+0x3a/0xff
[  530.684264]  __gunzip+0x64e/0x7e6
[  530.684741]  ? bunzip2+0x980/0x980
[  530.685084]  ? write_buffer+0x77/0x77
[  530.685481]  ? write_buffer+0x77/0x77
[  530.685840]  gunzip+0x43/0x52
[  530.686152]  ? md_run_setup+0xad/0xad
[  530.686559]  ? __gunzip+0x7e6/0x7e6
[  530.686897]  unpack_to_rootfs+0x284/0x527
[  530.687279]  ? md_run_setup+0xad/0xad
[  530.687628]  ? do_reset+0x91/0x91
[  530.688028]  populate_rootfs+0x116/0x344
[  530.688429]  ? maybe_link.part.5+0x31c/0x31c
[  530.688874]  do_one_initcall+0xb9/0x290
[  530.689244]  ? initcall_blacklisted+0x1b0/0x1b0
[  530.689760]  ? parse_args+0x228/0xb60
[  530.690138]  kernel_init_freeable+0x49a/0x54e
[  530.690542]  ? rest_init+0x190/0x190
[  530.690916]  kernel_init+0x18/0x180
[  530.691320]  ? rest_init+0x190/0x190
[  530.691762]  ret_from_fork+0x31/0x40
[  530.692127] Code: 90 ff e9 4d ff ff ff e8 ad bb 90 ff eb 8f e8 a6
bb 90 ff e9 66 ff ff ff 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9
03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89
d1 f3


Not sure if the QEMU reboot itself or not

-- 
Regards,
Peter Teoh

Re: is this a bug?

[Steven Rostedt]

Strange mail client you have.

On Wed, Mar 23, 2011 at 05:46:56PM -0700, Jay wrote:
> Hi,
> 
> Assuming vmscan is doing its job to steal the last page from an
> inode's namespace, so:
> 
> shrink_page_list -> remove_mapping -> __remove_from_page_cache:
> 
> void __remove_from_page_cache(struct page *page)
> 
> {
> 
>         ...
> 
>         radix_tree_delete(&mapping->page_tree, page->index);
> 
>         page->mapping = NULL;
> 
> >>> after removing the page from radix tree, it stuck at here.
> 
>         mapping->nrpages--;
> 
>         ...
> 
> }
> 
> then another process just calls iput_final to release the inode, so
> iput_final -> evict:
> 
> static void evict(struct inode *inode)
> 
> {
> 
>        ...
> 
>         } else {
> 
>                 if (inode->i_data.nrpages)
> 
> >>> here it finds that nrpage is 1, so go into truncate_inode_pages() but it won't find any page in the page tree.
> 
>                         truncate_inode_pages(&inode->i_data, 0);
> 
> >>> here nrpages remains 1.
> 
>                 end_writeback(inode);
> 
> >>> hit  BUG_ON(inode->i_data.nrpages) in end_writeback().


Did you actually hit this bug?

> 
>         }
> 
>         ...
> 
> }
> 
> The root cause of this problem is that nrpages is accessed w/o holding
> mapping->page_tree. The fix is also easy, just grab ->tree_lock inside
> truncate_inode_pages_range:
> 
> +       spin_lock_irq(&mapping->tree_lock);
> 
> -         if (mapping->nrpages == 0)
> 
> +        if (mapping->nrpages == 0) {
> 
> +               spin_unlock_irq(&mapping->tree_lock);
> 
>                 return;
> 
> +        }
> 
> +        spin_unlock_irq(&mapping->tree_lock);
> 
> Am I missed anything?

Perhaps the comment before the __remove_from_page_cache()

/*
 * Remove a page from the page cache and free it. Caller has to make
 * sure the page is locked and that nobody else uses it - or that usage
 * is safe.  The caller must hold the mapping's tree_lock.
 */

-- Steve

is this a bug?

[Jay]

Hi,

Assuming vmscan is doing its job to steal the last page from an
inode's namespace, so:

shrink_page_list -> remove_mapping -> __remove_from_page_cache:

void __remove_from_page_cache(struct page *page)

{

        ...

        radix_tree_delete(&mapping->page_tree, page->index);

        page->mapping = NULL;

>>> after removing the page from radix tree, it stuck at here.

        mapping->nrpages--;

        ...

}

then another process just calls iput_final to release the inode, so
iput_final -> evict:

static void evict(struct inode *inode)

{

       ...

        } else {

                if (inode->i_data.nrpages)

>>> here it finds that nrpage is 1, so go into truncate_inode_pages() but it won't find any page in the page tree.

                        truncate_inode_pages(&inode->i_data, 0);

>>> here nrpages remains 1.

                end_writeback(inode);

>>> hit  BUG_ON(inode->i_data.nrpages) in end_writeback().

        }

        ...

}

The root cause of this problem is that nrpages is accessed w/o holding
mapping->page_tree. The fix is also easy, just grab ->tree_lock inside
truncate_inode_pages_range:

+       spin_lock_irq(&mapping->tree_lock);

-         if (mapping->nrpages == 0)

+        if (mapping->nrpages == 0) {

+               spin_unlock_irq(&mapping->tree_lock);

                return;

+        }

+        spin_unlock_irq(&mapping->tree_lock);

Am I missed anything?

Thanks