build warnings

build warnings

[Thorsten Glaser]

Hi,

currently At wOrk, but here is something from the log:

  CALL    /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/scripts/checksyscalls.sh
<stdin>:1522:2: warning: #warning syscall recvmmsg not implemented

  CC      arch/m68k/mm/cache.o
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/mm/cache.c: In function 'flush_icache_range':
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/mm/cache.c:58: warning: 'mmusr' may be used uninitialized in this function
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/mm/cache.c:51: note: 'mmusr' was declared here

  CC      security/keys/keyctl.o
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/security/keys/keyctl.c:1346:2: warning: #warning TIF_NOTIFY_RESUME not implemented

  CC      drivers/ide/ide-io.o
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/ide/ide-io.c: In function 'ide_lock_host':
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/ide/ide-io.c:415: warning: passing argument 2 of '__constant_test_and_set_bit' discards qualifiers from pointer target type
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/bitops_mm.h:30: note: expected 'long unsigned int *' but argument is of type 'volatile long unsigned int *'
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/ide/ide-io.c:415: warning: passing argument 2 of '__generic_test_and_set_bit' discards qualifiers from pointer target type
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/bitops_mm.h:42: note: expected 'long unsigned int *' but argument is of type 'volatile long unsigned int *'

  CC [M]  drivers/net/zorro8390.o
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:256: warning: '__ei_tx_timeout' defined but not used
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:302: warning: '__ei_start_xmit' defined but not used
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:526: warning: '__ei_poll' defined but not used
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:879: warning: '__ei_get_stats' defined but not used
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:981: warning: '__ei_set_multicast_list' defined but not used
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:1016: warning: '____alloc_ei_netdev' defined but not used
  CC [M]  drivers/net/eql.o
  CC [M]  drivers/net/a2065.o
  CC [M]  drivers/net/hydra.o
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:256: warning: '__ei_tx_timeout' defined but not used
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:302: warning: '__ei_start_xmit' defined but not used
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:526: warning: '__ei_poll' defined but not used
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:879: warning: '__ei_get_stats' defined but not used
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:981: warning: '__ei_set_multicast_list' defined but not used
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:1016: warning: '____alloc_ei_netdev' defined but not used

  CC [M]  drivers/parport/parport_pc.o
In file included from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/parport/parport_pc.c:67:
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/parport.h:14:1: warning: "insl" redefined
In file included from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/io.h:4,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/include/linux/scatterlist.h:8,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/include/linux/dma-mapping.h:7,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/parport/parport_pc.c:54:
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/io_mm.h:332:1: warning: this is the location of the previous definition
In file included from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/parport/parport_pc.c:67:
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/parport.h:15:1: warning: "outsl" redefined
In file included from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/io.h:4,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/include/linux/scatterlist.h:8,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/include/linux/dma-mapping.h:7,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/parport/parport_pc.c:54:
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/io_mm.h:335:1: warning: this is the location of the previous definition
In file included from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/parport/parport_pc.c:67:
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/parport.h:14:1: warning: "insl" redefined
In file included from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/io.h:4,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/include/linux/scatterlist.h:8,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/include/linux/dma-mapping.h:7,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/parport/parport_pc.c:54:
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/io_mm.h:332:1: warning: this is the location of the previous definition
In file included from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/parport/parport_pc.c:67:
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/parport.h:15:1: warning: "outsl" redefined
In file included from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/io.h:4,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/include/linux/scatterlist.h:8,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/include/linux/dma-mapping.h:7,
                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/parport/parport_pc.c:54:
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/io_mm.h:335:1: warning: this is the location of the previous definition

  CC [M]  drivers/video/mb862xx/mb862xxfb.o
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/video/mb862xx/mb862xxfb.c:326: warning: 'mb862xxfb_init_fbinfo' defined but not used
/tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/video/mb862xx/mb862xxfb.c:464: warning: 'dev_attr_dispregs' defined but not used


There are also a few that are probably Linux upstream warnings (but
then, I’m not surprised at these, 2.0 and 2.4 both had assembler
warnings (indirect lcall without *) that got not fixed for years, so
nobody seems to care about warnings there…). This is 2.6.37 (Debian
-1~experimental.1) plus for-linus and m68k-queue of yesterday. I also
discovered @Stephen that staging drivers are built again. In case you
are interested in the progress: preliminary deb source package is at
https://www.freewrt.org/~tg/debs68k/tmp/linux-2.6/

bye,
//mirabilos
-- 
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)

Re: build warnings

[Michael Schmitz]

Hi Thorsten,

On Fri, Jan 14, 2011 at 3:44 AM, Thorsten Glaser <tg@mirbsd.de> wrote:
> Hi,
>
> currently At wOrk, but here is something from the log:
>
>  CALL    /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/scripts/checksyscalls.sh
> <stdin>:1522:2: warning: #warning syscall recvmmsg not implemented

I'm sure I have seen this one before.

>  CC      arch/m68k/mm/cache.o
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/mm/cache.c: In function 'flush_icache_range':
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/mm/cache.c:58: warning: 'mmusr' may be used uninitialized in this function
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/mm/cache.c:51: note: 'mmusr' was declared here
>
>  CC      security/keys/keyctl.o
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/security/keys/keyctl.c:1346:2: warning: #warning TIF_NOTIFY_RESUME not implemented

Ditto.

>
>  CC      drivers/ide/ide-io.o
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/ide/ide-io.c: In function 'ide_lock_host':
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/ide/ide-io.c:415: warning: passing argument 2 of '__constant_test_and_set_bit' discards qualifiers from pointer target type
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/bitops_mm.h:30: note: expected 'long unsigned int *' but argument is of type 'volatile long unsigned int *'
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/ide/ide-io.c:415: warning: passing argument 2 of '__generic_test_and_set_bit' discards qualifiers from pointer target type
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/bitops_mm.h:42: note: expected 'long unsigned int *' but argument is of type 'volatile long unsigned int *'
>
>  CC [M]  drivers/net/zorro8390.o
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:256: warning: '__ei_tx_timeout' defined but not used
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:302: warning: '__ei_start_xmit' defined but not used
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:526: warning: '__ei_poll' defined but not used
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:879: warning: '__ei_get_stats' defined but not used
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:981: warning: '__ei_set_multicast_list' defined but not used
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:1016: warning: '____alloc_ei_netdev' defined but not used
>  CC [M]  drivers/net/eql.o
>  CC [M]  drivers/net/a2065.o
>  CC [M]  drivers/net/hydra.o
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:256: warning: '__ei_tx_timeout' defined but not used
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:302: warning: '__ei_start_xmit' defined but not used
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:526: warning: '__ei_poll' defined but not used
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:879: warning: '__ei_get_stats' defined but not used
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:981: warning: '__ei_set_multicast_list' defined but not used
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/net/lib8390.c:1016: warning: '____alloc_ei_netdev' defined but not used
>
>  CC [M]  drivers/parport/parport_pc.o
> In file included from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/parport/parport_pc.c:67:
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/parport.h:14:1: warning: "insl" redefined
> In file included from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/io.h:4,
>                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/include/linux/scatterlist.h:8,
>                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/include/linux/dma-mapping.h:7,
>                 from /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/drivers/parport/parport_pc.c:54:
> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/arch/m68k/include/asm/io_mm.h:332:1: warning: this is the location of the previous definition

Looks OK - should only be used on Q40 though.

-- Michael

Re: build warnings

[Geert Uytterhoeven]

On Thu, Jan 13, 2011 at 20:24, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
> On Fri, Jan 14, 2011 at 3:44 AM, Thorsten Glaser <tg@mirbsd.de> wrote:
>> currently At wOrk, but here is something from the log:
>>
>>  CALL    /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/scripts/checksyscalls.sh
>> <stdin>:1522:2: warning: #warning syscall recvmmsg not implemented
>
> I'm sure I have seen this one before.

It's a false positive, as we implement it through the socketcall demultiplexer.
Some archs implement them all using individual syscalls.
BTW, PPC recently started doing both, and is trying to phase out the
socketcall way.

>>  CC      security/keys/keyctl.o
>> /tmp/buildd/linux-2.6-2.6.37/debian/build/source_m68k_none/security/keys/keyctl.c:1346:2: warning: #warning TIF_NOTIFY_RESUME not implemented

Waiting for someone with spare time to implement it...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: build warnings

[Thorsten Glaser]

Dixi quod…

> -1~experimental.1) plus for-linus and m68k-queue of yesterday. I also
> discovered @Stephen that staging drivers are built again. In case you
> are interested in the progress: preliminary deb source package is at
> https://www.freewrt.org/~tg/debs68k/tmp/linux-2.6/

Ouch, just had a peek at the atari kernel which was built overnight
(it’s working on bvme now) and got this:

Running Aranym on X11: :0.0
ARAnyM 0.9.10
Using config file: 'aranym.config.x11'
Could not open audio:
Could not open joystick 0
ARAnyM RTC Timer: ioctl(256 Hz): Permission denied
ARAnyM LILO: Error loading ramdisk 'root.bin'
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.37-0+m68k.1-atari (Debian 2.6.37-1~experimental.1+m68k.1) (tg@mirbsd.de) (gcc version 4.4.5 (Debian 4.4.5-10) ) #1 Fri Jan 14 06:21:53 UTC 2011
[    0.000000] console [debug0] enabled
[    0.000000] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K ANALOG_JOY Blitter tried to read byte from register ff8a00 at 00783a
BLITTER IDE TT_CLK FDC_SPEED
[    0.000000] NatFeats found (ARAnyM, 1.0)
[    0.000000] On node 0 totalpages: 3584
[    0.000000] free_area_init_node: node 0, pgdat 00330b64, node_mem_map 00464000
[    0.000000]   DMA zone: 32 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 3552 pages, LIFO batch:0
[    0.000000] On node 1 totalpages: 196608
[    0.000000] free_area_init_node: node 1, pgdat 00331514, node_mem_map 00488090
[    0.000000]   DMA zone: 1728 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 194880 pages, LIFO batch:31
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 2 zonelists in Zone order, mobility grouping on.  Total pages: 198432
[    0.000000] Kernel command line: root=/dev/hda1 console=tty debug=par BOOT_IMAGE=vmlinux
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 787384k/787384k available (2488k kernel code, 10812k data, 108k init)
[    0.000000] SLUB: Genslabs=14, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
[    0.000000] Console: colour dummy device 80x25
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.37-0+m68k.1-atari (Debian 2.6.37-1~experimental.1+m68k.1) (tg@mirbsd.de) (gcc version 4.4.5 (Debian 4.4.5-10) ) #1 Fri Jan 14 06:21:53 UTC 2011
[    0.000000] console [debug0] enabled
[    0.000000] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
[    0.000000] NatFeats found (ARAnyM, 1.0)
[    0.000000] On node 0 totalpages: 3584
[    0.000000] free_area_init_node: node 0, pgdat 00330b64, node_mem_map 00464000
[    0.000000]   DMA zone: 32 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 3552 pages, LIFO batch:0
[    0.000000] On node 1 totalpages: 196608
[    0.000000] free_area_init_node: node 1, pgdat 00331514, node_mem_map 00488090
[    0.000000]   DMA zone: 1728 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 194880 pages, LIFO batch:31
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 2 zonelists in Zone order, mobility grouping on.  Total pages: 198432
[    0.000000] Kernel command line: root=/dev/hda1 console=tty debug=par BOOT_IMAGE=vmlinux
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 787384k/787384k available (2488k kernel code, 10812k data, 108k init)
[    0.000000] SLUB: Genslabs=14, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] Calibrating delay loop... 147.04 BogoMIPS (lpj=735232)
[    0.340000] pid_max: default: 32768 minimum: 301
[    0.340000] Security Framework initialized
[    0.350000] SELinux:  Disabled at boot.
[    0.350000] Mount-cache hash table entries: 512
[    0.360000] Initializing cgroup subsys ns
[    0.360000] ns_cgroup deprecated: consider using the 'clone_children' flag without the ns_cgroup.
[    0.360000] Initializing cgroup subsys cpuacct
[    0.360000] Initializing cgroup subsys devices
[    0.360000] Initializing cgroup subsys freezer
[    0.360000] Initializing cgroup subsys blkio
[    0.360000] devtmpfs: initialized
[    0.360000] regulator: core version 0.5
[    0.360000] regulator: dummy:
[    0.360000] NET: Registered protocol family 16
[    0.390000] bio: create slab <bio-0> at 0
[    0.390000] SCSI subsystem initialized
[    0.440000] NET: Registered protocol family 2
[    0.450000] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.450000] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.480000] TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
[    0.480000] TCP: Hash tables configured (established 131072 bind 65536)
[    0.480000] TCP reno registered
[    0.480000] UDP hash table entries: 512 (order: 1, 8192 bytes)
[    0.480000] UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
[    0.500000] NET: Registered protocol family 1
[    0.500000] nfeth API 5
[    0.500000] eth0: nfeth addr:192.168.0.1 (192.168.0.2) HWaddr:52:54:00:22:00:03
[    0.520000] nfhd8: found device with 20971440 blocks (512 bytes)
[    0.540000]  nfhd8: AHDI p1 p2
[    0.540000] audit: initializing netlink socket (disabled)
[    0.540000] type=2000 audit(1292318492.540:1): initialized
[    0.630000] VFS: Disk quotas dquot_6.5.2
[    0.650000] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.690000] msgmni has been set to 1537
[    0.690000] alg: No test for stdrng (krng)
[    0.690000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    0.690000] io scheduler noop registered
[    0.690000] io scheduler deadline registered
[    0.690000] io scheduler cfq registered (default)
[    0.690000] atafb_init: start
[    0.690000] atafb_init: initializing Falcon hw
[    0.690000] atafb: screen_base 00b4b000 real_screen_base 00b4b000 screen_len 307200
[    0.710000] Determined 640x480, depth 4
[    0.710000]    virtual 640x960
[    0.710000] Console: switching to colour frame buffer device 80x30
[    0.730000] fb0: frame buffer device, using 300K of video memory
[    0.730000] Non-volatile memory driver v1.3
[    0.730000] Atari floppy driver: max. HD, track buffering
[    0.730000] Probing floppy drive(s):
[    0.730000] fd0
[    0.870000] brd: module loaded
[    0.890000] Uniform Multi-Platform E-IDE driver
[    0.950000] ide: Falcon IDE controller
[    0.970000] Probing IDE interface ide0...
[    1.360000] hda: Master, ATA DISK drive
[    2.450000] ide0 at 0xfff00000 on irq 15 (serialized)
[    2.460000] ide-gd driver 1.18
[    2.500000] hda: max request size: 128KiB
[    2.530000] hda: 20971440 sectors (10737 MB) w/256KiB Cache, CHS=20805/16/63
[    2.570000]  hda: AHDI hda1 hda2
[    2.590000] ide-cd driver 5.00
[    2.600000] scsi0: options CAN_QUEUE=8 CMD_PER_LUN=1 SCAT-GAT=0 TAGGED-QUEUING=no HOSTID=7 generic options AUTOSENSE REAL DMA SCSI-2 TAGGED QUEUING generic release=7
[    2.660000] scsi0 : Atari native SCSI
[    2.690000] mice: PS/2 mouse device common for all mice
[    2.960000] input: Atari Keyboard as /devices/virtual/input/input0
[    2.980000] input: Atari mouse as /devices/virtual/input/input1
[    2.980000] blk_queue_max_segments: set to minimum 1
[    3.000000] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
[    3.040000] TCP cubic registered
[    3.070000] NET: Registered protocol family 17
[    3.080000] NET: Registered protocol family 15
[    3.100000] registered taskstats version 1
[    3.120000] scsi: waiting for bus probes to complete ...
[    3.390000] Unable to handle kernel NULL pointer dereference at virtual address   (null)
[    3.390000] Oops: 00000000
[    3.390000] Modules linked in:
[    3.390000] PC: [<00090d4a>] __slab_free+0x5a/0xd0
[    3.390000] SR: 2700  SP: 30d95d2c  a2: 00d72b50
[    3.390000] d0: 0000001d    d1: 000000ff    d2: 00000001    d3: 30d5f700
[    3.390000] d4: 00000002    d5: 00000024    a0: 00000000    a1: 00c4c030
[    3.390000] Process scsi_scan_0 (pid: 25, task=00d72b50)
[    3.390000] Frame format=7 eff addr=00000000 ssw=0505 faddr=00000000
[    3.390000] wb 1 stat/addr/data: 0000 00000000 00000000
[    3.390000] wb 2 stat/addr/data: 0000 00000000 00000000
[    3.390000] wb 3 stat/addr/data: 0000 00000000 00000000
[    3.390000] push data: 00000000 00000000 00000000 00000000
[    3.390000] Stack from 30d95d94:
[    3.390000]         00002300 00b424bc 00d82240 00000000 00091b80 00d82240 00b424bc 30d73f40
[    3.390000]         0015d04a 00000000 30d7bb6c 0015c08e 0015d04a 30d73f40 30d7bb50 30d7bab0
[    3.390000]         0015bfe4 30d7bb6c 0015c08e 30d7ba00 001c691e 30d7bb50 30d7ba00 00dc8c00
[    3.390000]         00000000 001c4414 30d7ba00 ffffffff 00000000 00dc8cd8 00000000 00000000
[    3.390000]         00000000 001bc98c 30d5f500 00dc8cd8 30d95f18 30d5f70f 0015c11c 00000001
[    3.390000]         00000024 30d5f708 30d5f710 30d7bab0 00000000 30d95f14 00000012 00000024
[    3.390000] Call Trace: [<00002300>] name_to_dev_t+0x48/0x2c8
[    3.390000]  [<00091b80>] kfree+0x92/0xc6
[    3.390000]  [<0015d04a>] kref_put+0x2c/0x5e
[    3.390000]  [<0015c08e>] kobject_release+0x0/0x7a
[    3.390000]  [<0015d04a>] kref_put+0x2c/0x5e
[    3.390000]  [<0015bfe4>] kobject_put+0x1e/0x54
[    3.390000]  [<0015c08e>] kobject_release+0x0/0x7a
[    3.390000]  [<001c691e>] __scsi_remove_device+0x38/0xb8
[    3.390000]  [<001c4414>] scsi_probe_and_add_lun+0x2fc/0xb5c
[    3.390000]  [<001bc98c>] scsi_is_host_device+0x0/0x14
[    3.390000]  [<0015c11c>] kobject_get+0x14/0x1e
[    3.390000]  [<001c4e90>] __scsi_scan_target+0xa2/0x652
[    3.390000]  [<001c4dee>] __scsi_scan_target+0x0/0x652
[    3.390000]  [<0002d8ea>] T.1015+0x0/0x34
[    3.390000]  [<0004167a>] wq_worker_sleeping+0x0/0x8c
[    3.390000]  [<0002ac5a>] dequeue_entity+0x0/0x168
[    3.390000]  [<0002ac70>] dequeue_entity+0x16/0x168
[    3.390000]  [<001c54a4>] scsi_scan_channel+0x64/0x98
[    3.390000]  [<001c5440>] scsi_scan_channel+0x0/0x98
[    3.390000]  [<001c559c>] scsi_scan_host_selected+0xc4/0x13a
[    3.390000]  [<001c56a6>] do_scan_async+0x0/0x124
[    3.390000]  [<001c569c>] do_scsi_scan_host+0x8a/0x94
[    3.390000]  [<001c56a6>] do_scan_async+0x0/0x124
[    3.390000]  [<001c56b6>] do_scan_async+0x10/0x124
[    3.390000]  [<001c56a6>] do_scan_async+0x0/0x124
[    3.390000]  [<0000294a>] kernel_thread+0x0/0x4e
[    3.390000]  [<000459f0>] kthread+0x66/0x70
[    3.390000]  [<0004598a>] kthread+0x0/0x70
[    3.390000]  [<0026b31e>] schedule+0x0/0x41e
[    3.390000]  [<00002984>] kernel_thread+0x3a/0x4e
[    3.390000]
[    3.390000] Code: 4cdf 3804 4e75 103c 001d e0aa 2074 2c66 <5290> 49eb 0018 2268 0008 214c 0008 5888 2748 0018 2749 001c 228c 4cdf 3804 4e75
[    3.390000] Disabling lock debugging due to kernel taint
[    4.660000] Unable to handle kernel NULL pointer dereference at virtual address   (null)
[    4.660000] Oops: 00000000
[    4.660000] Modules linked in:
[    4.660000] PC: [<00090d4a>] __slab_free+0x5a/0xd0
[    4.660000] SR: 2700  SP: 00db5ec0  a2: 00da49a0
[    4.660000] d0: 0000001d    d1: 00000054    d2: 00000001    d3: 00000024
[    4.660000] d4: 00000100    d5: 0000000a    a0: 00000000    a1: 30d7f270
[    4.660000] Process ksoftirqd/0 (pid: 3, task=00da49a0)
[    4.660000] Frame format=7 eff addr=00000000 ssw=0505 faddr=00000000
[    4.660000] wb 1 stat/addr/data: 0000 00000000 00000000
[    4.660000] wb 2 stat/addr/data: 0000 00000000 00000000
[    4.660000] wb 3 stat/addr/data: 0000 00000000 00000000
[    4.660000] push data: 00000000 00000000 00000000 00000000
[    4.660000] Stack from 00db5f28:
[    4.660000]         00002300 00b4266c 00d86180 0026aff0 000919ec 00d86180 00b4266c 30d7f270
[    4.660000]         000434de 00d72fec 00315a0c 0006528a 000434de 00d86180 30d7f270 30d72978
[    4.660000]         000651a4 30d7f270 00000001 00356688 000651cc 00316efc 00035580 00356688
[    4.660000]         00002304 0026b31e 00000000 00000000 00000000 000652be 0026b7fe 000355e4
[    4.660000]         0003560c 00000000 0003565c 00000000 00000000 00da9f64 00035610 0000294a
[    4.660000]         00db5ff4 000459f0 00000000 00000000 0004598a 00da9f64 00000000 00000000
[    4.660000] Call Trace: [<00002300>] name_to_dev_t+0x48/0x2c8
[    4.660000]  [<0026aff0>] printk+0x0/0x18
[    4.660000]  [<000919ec>] kmem_cache_free+0x86/0x92
[    4.660000]  [<000434de>] put_pid+0x32/0x50
[    4.660000]  [<0006528a>] rcu_bh_qs+0x0/0x34
[    4.660000]  [<000434de>] put_pid+0x32/0x50
[    4.660000]  [<000651a4>] __rcu_process_callbacks+0x3c/0x5a
[    4.660000]  [<000651cc>] rcu_process_callbacks+0xa/0x16
[    4.660000]  [<00035580>] __do_softirq+0x6a/0xce
[    4.660000]  [<00002304>] name_to_dev_t+0x4c/0x2c8
[    4.660000]  [<0026b31e>] schedule+0x0/0x41e
[    4.660000]  [<000652be>] rcu_sched_qs+0x0/0x70
[    4.660000]  [<0026b7fe>] _cond_resched+0x0/0x3c
[    4.660000]  [<000355e4>] do_softirq+0x0/0x2c
[    4.660000]  [<0003560c>] do_softirq+0x28/0x2c
[    4.660000]  [<0003565c>] run_ksoftirqd+0x4c/0x8e
[    4.660000]  [<00035610>] run_ksoftirqd+0x0/0x8e
[    4.660000]  [<0000294a>] kernel_thread+0x0/0x4e
[    4.660000]  [<000459f0>] kthread+0x66/0x70
[    4.660000]  [<0004598a>] kthread+0x0/0x70
[    4.660000]  [<0026b31e>] schedule+0x0/0x41e
[    4.660000]  [<00002984>] kernel_thread+0x3a/0x4e
[    4.660000]
[    4.660000] Code: 4cdf 3804 4e75 103c 001d e0aa 2074 2c66 <5290> 49eb 0018 2268 0008 214c 0008 5888 2748 0018 2749 001c 228c 4cdf 3804 4e75
[    4.660000] Kernel panic - not syncing: Aiee, killing interrupt handler!
[    4.660000] Call Trace: [<0026aea8>] panic+0x54/0x19c
[    4.660000]  [<0026aff0>] printk+0x0/0x18
[    4.660000]  [<000455b8>] kthread_should_stop+0x0/0xa
[    4.660000]  [<00033fe8>] do_exit+0x618/0x6ee
[    4.660000]  [<0026aff0>] printk+0x0/0x18
[    4.660000]  [<000455b8>] kthread_should_stop+0x0/0xa
[    4.660000]  [<0026b002>] printk+0x12/0x18
[    4.660000]  [<0000338a>] bad_super_trap+0x0/0x198
[    4.660000]  [<000075e2>] send_fault_sig+0xaa/0xc6
[    4.660000]  [<00003c6e>] buserr_c+0x242/0x6f8
[    4.660000]  [<000025c6>] buserr+0x1e/0x24
[    4.660000]  [<00002300>] name_to_dev_t+0x48/0x2c8
[    4.660000]  [<0026aff0>] printk+0x0/0x18
[    4.660000]  [<000919ec>] kmem_cache_free+0x86/0x92
[    4.660000]  [<000434de>] put_pid+0x32/0x50
[    4.660000]  [<0006528a>] rcu_bh_qs+0x0/0x34
[    4.660000]  [<000434de>] put_pid+0x32/0x50
[    4.660000]  [<000651a4>] __rcu_process_callbacks+0x3c/0x5a
[    4.660000]  [<000651cc>] rcu_process_callbacks+0xa/0x16
[    4.660000]  [<00035580>] __do_softirq+0x6a/0xce
[    4.660000]  [<00002304>] name_to_dev_t+0x4c/0x2c8
[    4.660000]  [<0026b31e>] schedule+0x0/0x41e
[    4.660000]  [<000652be>] rcu_sched_qs+0x0/0x70
[    4.660000]  [<0026b7fe>] _cond_resched+0x0/0x3c
[    4.660000]  [<000355e4>] do_softirq+0x0/0x2c
[    4.660000]  [<0003560c>] do_softirq+0x28/0x2c
[    4.660000]  [<0003565c>] run_ksoftirqd+0x4c/0x8e
[    4.660000]  [<00035610>] run_ksoftirqd+0x0/0x8e
[    4.660000]  [<0000294a>] kernel_thread+0x0/0x4e
[    4.660000]  [<000459f0>] kthread+0x66/0x70
[    4.660000]  [<0004598a>] kthread+0x0/0x70
[    4.660000]  [<0026b31e>] schedule+0x0/0x41e
[    4.660000]  [<00002984>] kernel_thread+0x3a/0x4e
[    4.660000]


Then I press ^C and get this:

 A0: 0003082c A4: 00064db8   D0: 00000036 D4: 00011f1c  USP=00000000
 A1: 00314218 A5: 00007aa8   D1: 00004977 D5: 0000000a  ISP=00db5d64
 A2: 00da49a0 A6: 00db5d7c   D2: 00418958 D6: 00000009  MSP=00000000
 A3: 000079e0 A7: 00db5d64   D3: 00000001 D7: 00000000  VBR=0032f99c
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0           TC=8000
CACR=80008000 DTT0=00000000 ITT0=00000000 SRP=00001000  SFC=101
CAAR=00000000 DTT1=fe00a040 ITT1=fe00a040 URP=00000000  DFC=101
FP0: 0 FP1: 0 FP2: 0 FP3: 0 N=0 Z=0
FP4: 0 FP5: 0 FP6: 0 FP7: 0 I=0 NAN=0
0026afdc: 5381 64fc 51c8 fff8 4240 SUB.L #$00000001,D1
next PC: 0026afde
>


Does this help?

bye,
//mirabilos
-- 
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)

Re: build warnings

[Geert Uytterhoeven]

On Fri, Jan 14, 2011 at 10:25, Thorsten Glaser <tg@mirbsd.de> wrote:
> Dixi quod…
>
>> -1~experimental.1) plus for-linus and m68k-queue of yesterday. I also
>> discovered @Stephen that staging drivers are built again. In case you
>> are interested in the progress: preliminary deb source package is at
>> https://www.freewrt.org/~tg/debs68k/tmp/linux-2.6/
>
> Ouch, just had a peek at the atari kernel which was built overnight
> (it’s working on bvme now) and got this:
>
> Running Aranym on X11: :0.0
> ARAnyM 0.9.10


> [    0.000000] Linux version 2.6.37-0+m68k.1-atari (Debian 2.6.37-1~experimental.1+m68k.1) (tg@mirbsd.de) (gcc version 4.4.5 (Debian 4.4.5-10) ) #1 Fri Jan 14 06:21:53 UTC 2011

> [    3.120000] scsi: waiting for bus probes to complete ...
> [    3.390000] Unable to handle kernel NULL pointer dereference at virtual address   (null)

Interesting, 2.6.37 with the m68k patches runs fine on ARAnyM for me...

There may be issues on real hardware though, as there's still a
half-finished patch
for SCSI from Michael pending.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: build warnings

[Michael Schmitz]

Hi Geert,

>> Ouch, just had a peek at the atari kernel which was built overnight
>> (it’s working on bvme now) and got this:
>>
>> Running Aranym on X11: :0.0
>> ARAnyM 0.9.10
>
>
>> [    0.000000] Linux version 2.6.37-0+m68k.1-atari (Debian 2.6.37-1~experimental.1+m68k.1) (tg@mirbsd.de) (gcc version 4.4.5 (Debian 4.4.5-10) ) #1 Fri Jan 14 06:21:53 UTC 2011
>
>> [    3.120000] scsi: waiting for bus probes to complete ...
>> [    3.390000] Unable to handle kernel NULL pointer dereference at virtual address   (null)
>
> Interesting, 2.6.37 with the m68k patches runs fine on ARAnyM for me...

Ditto - both 2.6.37rc1 and 2.6.37 worked fine on ARAnyM. rc1 runs fine
on the actual hardware (stram pool patch applied).  Aside from that,
and the outdatet-toolchain related issues, I have no other patches
applied.

> There may be issues on real hardware though, as there's still a
> half-finished patch
> for SCSI from Michael pending.

It seems as though that's not a real issue anymore. I have backed that
patch out (or rather, had to restart with a fresh git clone a way back
and haven't reactivated that patch yet) but someone else appears to
have worked on atari_NCR5380.c and imported changes that implement
proper request locking. Mounting the SCSI disks readonly I could not
get the SCSI driver to deadlock yet.

The reference to slab allocation in the above error message does ring
a bell - a colleague has panics that look kinda similar (Intel
hardware running virtual machines there). Does look like the kernel
can get out of memory without the proper plugs being pulled (my gut
feeling). I'll have to look into that some more. Maybe play with
memory or ST-RAM pool size in ARAnyM.

Can you send me a copy of that kernel image so I can give it a try on
my working ARAnyM config, Thorsten?

(on the buildd chroot image test: had to discover the spare IDE disk I
used for tests has died; need to get a new one finally)

Cheers,

  Michael

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: build warnings

[Thorsten Glaser]

Michael Schmitz dixit:

>The reference to slab allocation in the above error message does ring
>a bell - a colleague has panics that look kinda similar (Intel
>hardware running virtual machines there). Does look like the kernel
>can get out of memory without the proper plugs being pulled (my gut

Oh, ouch.

>feeling). I'll have to look into that some more. Maybe play with
>memory or ST-RAM pool size in ARAnyM.

Well, I do have a large number of patches applied (all of Debian’s
and the entire m68k queue)…

>Can you send me a copy of that kernel image so I can give it a try on
>my working ARAnyM config, Thorsten?

Sure: https://pfau.mirbsd.org/~tg/pub/vmlinux.gz

>(on the buildd chroot image test: had to discover the spare IDE disk I
>used for tests has died; need to get a new one finally)

Ah okay. Good luck anyway…

bye,
//mirabilos
-- 
<ch> you introduced a merge commit        │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo      │  fault (core dumped)
<ch> if I rebase that now, it's really ugh     │<mika:#grml> wuahhhhhh

Re: build warnings

[Michael Schmitz]

Thorsten,

>>The reference to slab allocation in the above error message does ring
>>a bell - a colleague has panics that look kinda similar (Intel
>>hardware running virtual machines there). Does look like the kernel
>>can get out of memory without the proper plugs being pulled (my gut
>
> Oh, ouch.

Might well be something different - upon closer inspection, the errors
look different at least.

>>feeling). I'll have to look into that some more. Maybe play with
>>memory or ST-RAM pool size in ARAnyM.
>
> Well, I do have a large number of patches applied (all of Debian’s
> and the entire m68k queue)…

Mmh - Geert's 2.6.37 does work just fine for me; I'll better get your
patches applied to a vanilla kernel and see how that differs from
2.6.37-m68k. vanilla plus the git branch m68k-queue _should_ just get
us to 2.6.37-m68k, right?

>>Can you send me a copy of that kernel image so I can give it a try on
>>my working ARAnyM config, Thorsten?
>
> Sure: https://pfau.mirbsd.org/~tg/pub/vmlinux.gz

Thanks, I'll try that one. 2.6.37-m68k (built as a minimal config so
it will fit on a floppy) does run OK on the Falcon right now, though I
had a weird IDE kernel panic with 2.6.37-rc1-m68k the other day.
Floppy detection has been a bit shaky on that one, and SCSI must have
had some weird issues as well - could not mount one of the SCSI
partitions whatever I tried, it always reported the device busy.
2.6.37-m68k would open the partition fine.

>>(on the buildd chroot image test: had to discover the spare IDE disk I
>>used for tests has died; need to get a new one finally)
>
> Ah okay. Good luck anyway…

Thanks - just a matter to drive out to a decent shop after work
sometime. Not something the consumer electronics shops in Auckland CBD
stock, for some reason.

Cheers,

  Michael

Re: build warnings

[Thorsten Glaser]

Michael Schmitz dixit:

>Mmh - Geert's 2.6.37 does work just fine for me; I'll better get your
>patches applied to a vanilla kernel and see how that differs from
>2.6.37-m68k. vanilla plus the git branch m68k-queue _should_ just get
>us to 2.6.37-m68k, right?

I applied all of m68k-queue and for-linus of that day (which is the
signal patchset for both m68ks and the rest of the queue) but on top
of a 2.6.37-1~experimental.1 Debian kernel.

I posted a link to the source package earlier. I cancelled the build
though due to this problem.

>sometime. Not something the consumer electronics shops in Auckland CBD
>stock, for some reason.

Heh well. I’ve had fun times buying an IDE drive with less than 1024
cylinders, floppies, and printer paper (not loose pages like copier
paper they use nowadays, no, real 21x30.48cm endless paper) too ;-)
But they had new print ribbon for my Epson FX-80, so… ☻☺

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”	-- Tonnerre, psychoschlumpf and myself in #nosec

Re: build warnings

[Michael Schmitz]

Thorsten,

>>Mmh - Geert's 2.6.37 does work just fine for me; I'll better get your
>>patches applied to a vanilla kernel and see how that differs from
>>2.6.37-m68k. vanilla plus the git branch m68k-queue _should_ just get
>>us to 2.6.37-m68k, right?
>
> I applied all of m68k-queue and for-linus of that day (which is the
> signal patchset for both m68ks and the rest of the queue) but on top
> of a 2.6.37-1~experimental.1 Debian kernel.

for-linus is what I would have missed ...

> I posted a link to the source package earlier. I cancelled the build
> though due to this problem.

Right you are, I'll work from that one then.

>>sometime. Not something the consumer electronics shops in Auckland CBD
>>stock, for some reason.
>
> Heh well. I’ve had fun times buying an IDE drive with less than 1024
> cylinders, floppies, and printer paper (not loose pages like copier
> paper they use nowadays, no, real 21x30.48cm endless paper) too ;-)

Floppies is a dark chapter indeed. I salvage floppies wherever I find
them. Will see about the 1024 cylinder limit though.

Cheers,

  Michael

Re: build warnings

[Michael Schmitz]

Hi Thorsten,

>> -1~experimental.1) plus for-linus and m68k-queue of yesterday. I also
>> discovered @Stephen that staging drivers are built again. In case you
>> are interested in the progress: preliminary deb source package is at
>> https://www.freewrt.org/~tg/debs68k/tmp/linux-2.6/
>
> Ouch, just had a peek at the atari kernel which was built overnight
> (it’s working on bvme now) and got this:

I get a different stack trace but it's basically the same type of OOM
error. Incidentially, this one happens in skb_free_datagram, and hence
looks a lot more like the one my former colleagues reported (Intel
hardware, virtual machine running a mail server there).

ARAnyM 0.9.9-1 here, 256 MB FastRam configured.

Can you try building from Geert's git source, using the same .config
as for the broken build?

Cheers,

  Michael


[   10.610000] Unable to handle kernel NULL pointer dereference at
virtual address   (null)
[   10.610000] Oops: 00000000
[   10.610000] Modules linked in:
[   10.610000] PC: [<00090d4a>] __slab_free+0x5a/0xd0
[   10.610000] SR: 2700  SP: 00d47c50  a2: 00bd4e70
[   10.610000] d0: 0000001d    d1: 00000007    d2: 00000001    d3: 000000a2
[   10.610000] d4: 00000000    d5: 00d47e0c    a0: 00000000    a1: 0074406c
[   10.610000] Process udevd (pid: 89, task=00bd4e70)
[   10.610000] Frame format=7 eff addr=00000000 ssw=0505 faddr=00000000
[   10.610000] wb 1 stat/addr/data: 0000 00000000 00000000
[   10.610000] wb 2 stat/addr/data: 0000 00000000 00000000
[   10.610000] wb 3 stat/addr/data: 0000 00000000 8000bf58
[   10.610000] push data: 00000000 00000000 00000000 00000000
[   10.610000] Stack from 00d47cb8:
[   10.610000]         00002300 00639120 00802510 00c11908 00091b80
00802510 00639120 10c04000
[   10.610000]         001f3330 00000000 00c118f0 00d47f6c 001f3330
10c04000 00c118f0 00b19200
[   10.610000]         001f6024 00c118f0 00b19200 0020fdb0 00b19200
00c118f0 00d47f6c 00001000
[   10.610000]         00000000 00d47e90 eff22744 eff2272c 00813e70
00d47e0c 00813e70 00d47e14
[   10.610000]         00c118f0 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[   10.610000]         00000040 00000000 002759a4 00000000 00d47e4c
001ec4c8 00d47d9e 00813e70
[   10.610000] Call Trace: [<00002300>] name_to_dev_t+0x48/0x2c8
[   10.610000]  [<00091b80>] kfree+0x92/0xc6
[   10.610000]  [<001f3330>] __kfree_skb+0x12/0x84
[   10.610000]  [<001f3330>] __kfree_skb+0x12/0x84
[   10.610000]  [<001f6024>] skb_free_datagram+0x10/0x36
[   10.610000]  [<0020fdb0>] netlink_recvmsg+0xfa/0x39c
[   10.610000]  [<00001000>] kernel_pg_dir+0x0/0x1000
[   10.610000]  [<001ec4c8>] sock_recvmsg+0xb0/0xd2
[   10.610000]  [<00001000>] kernel_pg_dir+0x0/0x1000
[   10.610000]  [<000200da>] _060_fpsp_effadd+0xb8ca/0xd518
[   10.610000]  [<00020000>] _060_fpsp_effadd+0xb7f0/0xd518
[   10.610000]  [<0001ffff>] _060_fpsp_effadd+0xb7ef/0xd518
[   10.610000]  [<00001774>] kernel_pg_dir+0x774/0x1000
[   10.610000]  [<0006ee38>] __alloc_pages_nodemask+0x0/0x546
[   10.610000]  [<0006eee0>] __alloc_pages_nodemask+0xa8/0x546
[   10.610000]  [<000200da>] _060_fpsp_effadd+0xb8ca/0xd518
[   10.610000]  [<00001000>] kernel_pg_dir+0x0/0x1000
[   10.610000]  [<001f5590>] verify_iovec+0x4e/0xca
[   10.610000]  [<001ec2d0>] __sys_recvmsg+0xca/0x15e
[   10.610000]  [<00001000>] kernel_pg_dir+0x0/0x1000
[   10.610000]  [<00100000>] ext2_write_failed+0x4/0x5a
[   10.610000]  [<000718dc>] put_page+0x0/0x15c
[   10.610000]  [<0007d32a>] do_wp_page+0x236/0x764
[   10.610000]  [<00029f5c>] check_preempt_wakeup+0xfc/0x214
[   10.610000]  [<0007e844>] handle_mm_fault+0x260/0x704
[   10.610000]  [<000076a6>] do_page_fault+0xa8/0x21a
[   10.610000]  [<001ec64c>] sockfd_lookup_light+0x1c/0x60
[   10.610000]  [<001ec8ea>] sys_recvmsg+0x34/0x70
[   10.610000]  [<001eded0>] sys_socketcall+0x10c/0x2ee
[   10.610000]  [<0000269c>] syscall+0x8/0xc
[   10.610000]
[   10.610000] Code: 4cdf 3804 4e75 103c 001d e0aa 2074 2c66 <5290>
49eb 0018 2268 0008 214c 0008 5888 2748 0018 2749 001c 228c 4cdf 3804
4e75

Re: build warnings

[Geert Uytterhoeven]

On Mon, Jan 17, 2011 at 03:48, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
>>>Mmh - Geert's 2.6.37 does work just fine for me; I'll better get your
>>>patches applied to a vanilla kernel and see how that differs from
>>>2.6.37-m68k. vanilla plus the git branch m68k-queue _should_ just get
>>>us to 2.6.37-m68k, right?
>>
>> I applied all of m68k-queue and for-linus of that day (which is the
>> signal patchset for both m68ks and the rest of the queue) but on top
>> of a 2.6.37-1~experimental.1 Debian kernel.
>
> for-linus is what I would have missed ...

for-linus is a always[*] subset of m68k-queue, so you can ignore it.

[*] Except if I feed extra stuff, like this time the m68knommu signal fixes.
    But those don't matter for m68k.

>>>sometime. Not something the consumer electronics shops in Auckland CBD
>>>stock, for some reason.
>>
>> Heh well. I’ve had fun times buying an IDE drive with less than 1024
>> cylinders, floppies, and printer paper (not loose pages like copier
>> paper they use nowadays, no, real 21x30.48cm endless paper) too ;-)
>
> Floppies is a dark chapter indeed. I salvage floppies wherever I find
> them. Will see about the 1024 cylinder limit though.

Guys, what are you smoking?
I was pleasantly surprised when my Amiga detected a "540 MB" drive, as the
one I bought was advertised as a "524 MB" drive. Turned out due to MS-DOS
supporting only 1024 cylinders, while the Amiga saw 1057 ;-)
I have to admit I bought this drive in 1993, not yesterday.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: build warnings

[Michael Schmitz]

Geert,

On Mon, Jan 17, 2011 at 7:51 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Jan 17, 2011 at 03:48, Michael Schmitz
> <schmitzmic@googlemail.com> wrote:
>>>>Mmh - Geert's 2.6.37 does work just fine for me; I'll better get your
>>>>patches applied to a vanilla kernel and see how that differs from
>>>>2.6.37-m68k. vanilla plus the git branch m68k-queue _should_ just get
>>>>us to 2.6.37-m68k, right?
>>>
>>> I applied all of m68k-queue and for-linus of that day (which is the
>>> signal patchset for both m68ks and the rest of the queue) but on top
>>> of a 2.6.37-1~experimental.1 Debian kernel.
>>
>> for-linus is what I would have missed ...
>
> for-linus is a always[*] subset of m68k-queue, so you can ignore it.

Good - I've unpacked the 2.6.37.experimental source and ran
dpkg-buildpackage -b -am68k on it up to the point where it fails
because I haven't got a cross-gcc-4.4 installed (flavors restricted to
atari only!). At that point, to my limited understanding of the kernel
build process, all patched ought to have been applied.

The good news is that the Atari SCSI driver is up to the latest git
version. But we had discounted that option already anyway.

The only patch that has been missed, but may be relevant for Atari still:

16 bit FAT default for GEMDOS:

--- linux-m68k-git/linux-m68k/fs/fat/inode.c    2010-11-10
19:40:40.131506952 +1300
+++ linux-2.6-2.6.37/debian/build/source_m68k_none/fs/fat/inode.c
 2011-01-17 20:18:44.484006839 +1300
@@ -923,10 +923,10 @@
        {Opt_err_cont, "errors=continue"},
        {Opt_err_panic, "errors=panic"},
        {Opt_err_ro, "errors=remount-ro"},
+       {Opt_discard, "discard"},
        {Opt_atari_yes, "atari=yes"},
        {Opt_atari_yes, "atari"},
        {Opt_atari_no, "atari=no"},
-       {Opt_discard, "discard"},
        {Opt_obsolate, "conv=binary"},
        {Opt_obsolate, "conv=text"},
        {Opt_obsolate, "conv=auto"},

I'd suggest I first test that this option is still required - will
have to sacrifice a spare SCSI disk for that.

So for all intents and purposes, Thorsten and I are using the same
source. I will still build the patched Debian source using my
toolchain, but I just cannot see why it would not work.

>>> Heh well. I’ve had fun times buying an IDE drive with less than 1024
>>> cylinders, floppies, and printer paper (not loose pages like copier
>>> paper they use nowadays, no, real 21x30.48cm endless paper) too ;-)
>>
>> Floppies is a dark chapter indeed. I salvage floppies wherever I find
>> them. Will see about the 1024 cylinder limit though.
>
> Guys, what are you smoking?

I gave up smoking  quite a few years back :-)

> I was pleasantly surprised when my Amiga detected a "540 MB" drive, as the
> one I bought was advertised as a "524 MB" drive. Turned out due to MS-DOS
> supporting only 1024 cylinders, while the Amiga saw 1057 ;-)
> I have to admit I bought this drive in 1993, not yesterday.

Slightly difficult to get a 540 MB drive anywhere these days - even
USB memory sticks have outgrown the MB range for a while now :-)

Currently in use on the Falcon:

hda: 2814336 sectors (1440 MB) w/128KiB Cache, CHS=2792/16/63

So I should not need to worry about the cylinder numbers ...

Cheers,

  Michael

Re: build warnings

[Geert Uytterhoeven]

On Mon, Jan 17, 2011 at 20:50, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
> The only patch that has been missed, but may be relevant for Atari still:
>
> 16 bit FAT default for GEMDOS:
>
> --- linux-m68k-git/linux-m68k/fs/fat/inode.c    2010-11-10
> 19:40:40.131506952 +1300
> +++ linux-2.6-2.6.37/debian/build/source_m68k_none/fs/fat/inode.c
>  2011-01-17 20:18:44.484006839 +1300
> @@ -923,10 +923,10 @@
>        {Opt_err_cont, "errors=continue"},
>        {Opt_err_panic, "errors=panic"},
>        {Opt_err_ro, "errors=remount-ro"},
> +       {Opt_discard, "discard"},
>        {Opt_atari_yes, "atari=yes"},
>        {Opt_atari_yes, "atari"},
>        {Opt_atari_no, "atari=no"},
> -       {Opt_discard, "discard"},
>        {Opt_obsolate, "conv=binary"},
>        {Opt_obsolate, "conv=text"},
>        {Opt_obsolate, "conv=auto"},

The order of the options shouldn't matter. Due to historical reasons,
it's different
on master and m68k-queue.

> I'd suggest I first test that this option is still required - will
> have to sacrifice a spare SCSI disk for that.

I think there was a half consensus or so that we still need it, but
not enough to
put some weight behind it ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: build warnings

[Michael Schmitz]

Geert,

On Tue, Jan 18, 2011 at 9:14 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Jan 17, 2011 at 20:50, Michael Schmitz
> <schmitzmic@googlemail.com> wrote:
>> The only patch that has been missed, but may be relevant for Atari still:
>>
>> 16 bit FAT default for GEMDOS:
>>
>> --- linux-m68k-git/linux-m68k/fs/fat/inode.c    2010-11-10
>> 19:40:40.131506952 +1300
>> +++ linux-2.6-2.6.37/debian/build/source_m68k_none/fs/fat/inode.c
>>  2011-01-17 20:18:44.484006839 +1300
>> @@ -923,10 +923,10 @@
>>        {Opt_err_cont, "errors=continue"},
>>        {Opt_err_panic, "errors=panic"},
>>        {Opt_err_ro, "errors=remount-ro"},
>> +       {Opt_discard, "discard"},
>>        {Opt_atari_yes, "atari=yes"},
>>        {Opt_atari_yes, "atari"},
>>        {Opt_atari_no, "atari=no"},
>> -       {Opt_discard, "discard"},
>>        {Opt_obsolate, "conv=binary"},
>>        {Opt_obsolate, "conv=text"},
>>        {Opt_obsolate, "conv=auto"},
>
> The order of the options shouldn't matter. Due to historical reasons,
> it's different
> on master and m68k-queue.

I thought the 'discard' marks the start of no longer used options
(i.e. option processing stops at discard). My bad.

>
>> I'd suggest I first test that this option is still required - will
>> have to sacrifice a spare SCSI disk for that.
>
> I think there was a half consensus or so that we still need it, but
> not enough to
> put some weight behind it ;-)

Given that I could not even remember what it was that I had to do to
the FAT code to get it to what it does now, we best leave it at that.
Schroedingers cat, and all that :-)

Cheers,

  Michael

Re: build warnings

[Geert Uytterhoeven]

On Tue, Jan 18, 2011 at 02:18, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
> On Tue, Jan 18, 2011 at 9:14 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Mon, Jan 17, 2011 at 20:50, Michael Schmitz
>> <schmitzmic@googlemail.com> wrote:
>>> The only patch that has been missed, but may be relevant for Atari still:
>>>
>>> 16 bit FAT default for GEMDOS:
>>>
>>> --- linux-m68k-git/linux-m68k/fs/fat/inode.c    2010-11-10
>>> 19:40:40.131506952 +1300
>>> +++ linux-2.6-2.6.37/debian/build/source_m68k_none/fs/fat/inode.c
>>>  2011-01-17 20:18:44.484006839 +1300
>>> @@ -923,10 +923,10 @@
>>>        {Opt_err_cont, "errors=continue"},
>>>        {Opt_err_panic, "errors=panic"},
>>>        {Opt_err_ro, "errors=remount-ro"},
>>> +       {Opt_discard, "discard"},
>>>        {Opt_atari_yes, "atari=yes"},
>>>        {Opt_atari_yes, "atari"},
>>>        {Opt_atari_no, "atari=no"},
>>> -       {Opt_discard, "discard"},
>>>        {Opt_obsolate, "conv=binary"},
>>>        {Opt_obsolate, "conv=text"},
>>>        {Opt_obsolate, "conv=auto"},
>>
>> The order of the options shouldn't matter. Due to historical reasons,
>> it's different
>> on master and m68k-queue.
>
> I thought the 'discard' marks the start of no longer used options
> (i.e. option processing stops at discard). My bad.

You got me, I never looked at it that way ;-)

No, it comes from commit 681142f9211b23e6aa2984259d38b76d7bdc05a8
("fat: make discard a mount option")

>>> I'd suggest I first test that this option is still required - will
>>> have to sacrifice a spare SCSI disk for that.
>>
>> I think there was a half consensus or so that we still need it, but
>> not enough to
>> put some weight behind it ;-)
>
> Given that I could not even remember what it was that I had to do to
> the FAT code to get it to what it does now, we best leave it at that.
> Schroedingers cat, and all that :-)

commit cc9c5fc236c0d02cae44c2fbcc8ffa3ae5e517b6 ("Atari FAT updates")
more or less summarizes it. It's the logic which decides whether the FAT is
16-bit or 12-bit.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: build warnings

[Michael Schmitz]

Geert,

>> I thought the 'discard' marks the start of no longer used options
>> (i.e. option processing stops at discard). My bad.
>
> You got me, I never looked at it that way ;-)
>
> No, it comes from commit 681142f9211b23e6aa2984259d38b76d7bdc05a8
> ("fat: make discard a mount option")

Now I'll have to go and look what that is about :-)

>> Given that I could not even remember what it was that I had to do to
>> the FAT code to get it to what it does now, we best leave it at that.
>> Schroedingers cat, and all that :-)
>
> commit cc9c5fc236c0d02cae44c2fbcc8ffa3ae5e517b6 ("Atari FAT updates")
> more or less summarizes it. It's the logic which decides whether the FAT is
> 16-bit or 12-bit.

Yep, I had seen it in the log message there when I had a look at what
still was on m68k-queue. Just couldn't remember any of that without
refreshing my memory.

I'm still being bitten by the limit on logical sector size for FAT -
partitions larger than 128M either can be read from Linux (sector size
4k) or TOS (sector size 8k) but not both. Has anyone found a
workaround for this?

In other news, SCSI on the Falcon is still broken - timeouts for SCSI
commands are started by the block layer, but commands cannot be
guaranteed to get queued in the lowlevel driver unless the lowlevel
driver has access to the SCSI DMA right away. Upon timeout, the
request isn't actually found on the lowlevel queue in case the queue
request had to wait. I'm unsure what the correct strategy is here:
defer queueing requests by pretending the driver is busy, or queue
requests and try to kick off the coroutine as soon as DMA gets
available?

Cheers,

  Michael

Re: build warnings

[Geert Uytterhoeven]

On Wed, Jan 19, 2011 at 00:54, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
> In other news, SCSI on the Falcon is still broken - timeouts for SCSI
> commands are started by the block layer, but commands cannot be
> guaranteed to get queued in the lowlevel driver unless the lowlevel
> driver has access to the SCSI DMA right away. Upon timeout, the
> request isn't actually found on the lowlevel queue in case the queue
> request had to wait. I'm unsure what the correct strategy is here:
> defer queueing requests by pretending the driver is busy, or queue
> requests and try to kick off the coroutine as soon as DMA gets
> available?

I guess pretending the driver is busy?
The alternative means duplicating request queueing, which people will frown
upon.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: build warnings

[Michael Schmitz]

Hi Thorsten,

>> I posted a link to the source package earlier. I cancelled the build
>> though due to this problem.
>>     
>
> Right you are, I'll work from that one then.
>
>   

I've seen a similar panic as the one you posted when I had quite a bit 
of memory pressure due to ext2fsck running. Otherwise, the kernel built 
with my old binutils boots fine and eventually crashes the emulator with:

terminate called after throwing an instance of 'm68k_exception'

after getting well into runlevel 2 and starting a few services.

Retesting your kernel - when I leave swap off I also get to runlevel 2, 
and it starts to throw panic messages as soon as inetd is started.
I've tried a few leads related to network stuff, but in the end 
replacing the  option CONFIG_SLUB=y by CONFIG_SLAB=y did fix it.

Whatever the reason - the SLUB allocator either is buggy outright for 
m68k, or we run into memory pressure a lot sooner than other 
architectures and the VM subsystem needs optimizing for SLUB.

I'd just replace the Debian default for the m68k kernels....

Cheers,

  Michael

Re: build warnings

[Thorsten Glaser]

Michael Schmitz dixit:

[ … ]
> I've tried a few leads related to network stuff, but in the end replacing the
> option CONFIG_SLUB=y by CONFIG_SLAB=y did fix it.
>
> Whatever the reason - the SLUB allocator either is buggy outright for m68k, or
> we run into memory pressure a lot sooner than other architectures and the VM
> subsystem needs optimizing for SLUB.

Oh, okay. Thanks a huge lot for taking the time to track this down.

> I'd just replace the Debian default for the m68k kernels....

Sounds reasonable.

Thanks,
//mirabilos
-- 
22:20⎜<asarch> The crazy that persists in his craziness becomes a master
22:21⎜<asarch> And the distance between the craziness and geniality is
only measured by the success                       22:21⎜<mksh> it’s a
very thin line anyway… with some, you don’t know which side they’re on

Re: build warnings

[Geert Uytterhoeven]

On Sun, Jan 30, 2011 at 06:37, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
> I've seen a similar panic as the one you posted when I had quite a bit of
> memory pressure due to ext2fsck running. Otherwise, the kernel built with my
> old binutils boots fine and eventually crashes the emulator with:
>
> terminate called after throwing an instance of 'm68k_exception'
>
> after getting well into runlevel 2 and starting a few services.
>
> Retesting your kernel - when I leave swap off I also get to runlevel 2, and
> it starts to throw panic messages as soon as inetd is started.
> I've tried a few leads related to network stuff, but in the end replacing
> the  option CONFIG_SLUB=y by CONFIG_SLAB=y did fix it.
>
> Whatever the reason - the SLUB allocator either is buggy outright for m68k,
> or we run into memory pressure a lot sooner than other architectures and the
> VM subsystem needs optimizing for SLUB.
>
> I'd just replace the Debian default for the m68k kernels....

If switching from SLUB to SLAB fixes the problem, please enable
CONFIG_SLUB_DEBUG and bring it up on lkml/with the SLUB people.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: build warnings

[Michael Schmitz]

Geert,
>>
>> Whatever the reason - the SLUB allocator either is buggy outright for m68k,
>> or we run into memory pressure a lot sooner than other architectures and the
>> VM subsystem needs optimizing for SLUB.
>>
>> I'd just replace the Debian default for the m68k kernels....
>>     
>
> If switching from SLUB to SLAB fixes the problem, please enable
> CONFIG_SLUB_DEBUG and bring it up on lkml/with the SLUB people.
>   
Can do that - I'll try and collect debug data from another case I know 
has had trouble with SLUB. I'll probably have to build a custom kernel 
for them and test that on the live mail server. Fun ... :-)

Cheers,

  Michael

Re: build warnings

[Finn Thain]

On Mon, 31 Jan 2011, Michael Schmitz wrote:

> Geert,
> > > 
> > > Whatever the reason - the SLUB allocator either is buggy outright 
> > > for m68k, or we run into memory pressure a lot sooner than other 
> > > architectures and the VM subsystem needs optimizing for SLUB.
> > > 
> > > I'd just replace the Debian default for the m68k kernels....
> > >     
> > 
> > If switching from SLUB to SLAB fixes the problem, please enable 
> > CONFIG_SLUB_DEBUG and bring it up on lkml/with the SLUB people.
> >   
> Can do that - I'll try and collect debug data from another case I know 
> has had trouble with SLUB. I'll probably have to build a custom kernel 
> for them and test that on the live mail server. Fun ... :-)

I haven't compared the log from Thorsten's kernel failure with the 
failures I saw, but (anecdotally) my experience was the same: SLUB on m68k 
was not usable, going back some years.

The introduction of the SLUB allocator was 2.6.22, but I can't help you 
bisect because I don't recall that it worked ever (?)

Anyway, I do recall building SLUB kernels at the time that would fail more 
often than they booted ... maybe the old releases could offer some clues?

Finn

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

Re: build warnings

[Michael Schmitz]

Geert,
>>
>> If switching from SLUB to SLAB fixes the problem, please enable
>> CONFIG_SLUB_DEBUG and bring it up on lkml/with the SLUB people.
>>   
> Can do that - I'll try and collect debug data from another case I know 
> has had trouble with SLUB. I'll probably have to build a custom kernel 
> for them and test that on the live mail server. Fun ... :-)
Done that with a fresh kernel as well as with the original one and 
slub_debug in the kernel options - there's no debug info in the logs, 
just the panic messages.

Booting with init=/bin/sh and running slabinfo -v results in:

> [   56.590000] Unable to handle kernel NULL pointer dereference at 
> virtual address 00000014
> [   56.590000] Oops: 00000000
> [   56.590000] Modules linked in:
> [   56.590000] PC: [<00075d84>] add_full+0x12/0x24
> [   56.590000] SR: 2714  SP: 00aa9cfc  a2: 00c16ca0
> [   56.590000] d0: 00000001    d1: 00010000    d2: 000000d0    d3: 
> 000000d0
> [   56.590000] d4: ffffffff    d5: 0008af80    a0: 006040a8    a1: 
> 00000014
> [   56.590000] Process slabinfo (pid: 29, task=00c16ca0)
> [   56.590000] Frame format=7 eff addr=00000014 ssw=0505 faddr=00000014
> [   56.590000] wb 1 stat/addr/data: 0000 00000000 00000000
> [   56.590000] wb 2 stat/addr/data: 0000 00000000 00000000
> [   56.590000] wb 3 stat/addr/data: 0000 00000014 00003339
> [   56.590000] push data: 00000000 00000000 00000000 00000000
> [   56.590000] Stack from 00aa9d64:
> [   56.590000]         00000000 00076602 00000000 00604090 00604090 
> 0007667c 00810000 00604090
> [   56.590000]         00000001 0060f24c 00000000 00810000 00076954 
> 00810000 0060f24c 00002300
> [   56.590000]         000000d0 008128f0 00000024 00000000 00810000 
> 006711c4 00076a5c 00810000
> [   56.590000]         000000d0 ffffffff 0008af80 0060f24c 000007bf 
> 006a0690 006a0690 006a0690
> [   56.590000]         0008af80 00810000 000000d0 006a0690 00d45108 
> 0008bab8 006a0690 000007bf
> [   56.590000]         006711c4 00d45108 10c012d0 0008bdd0 006a0690 
> 006711c4 000007bf 00ad7204
> [   56.590000] Call Trace: [<00076602>] unfreeze_slab+0x4a/0x7c
> [   56.590000]  [<0007667c>] deactivate_slab+0x48/0x52
> [   56.590000]  [<00076954>] __slab_alloc+0xa0/0x150
> [   56.590000]  [<00002300>] name_to_dev_t+0x14/0x250
> [   56.590000]  [<00076a5c>] kmem_cache_alloc+0x58/0x6a
> [   56.590000]  [<0008af80>] alloc_inode+0x6e/0x7e
> [   56.590000]  [<0008af80>] alloc_inode+0x6e/0x7e
> [   56.590000]  [<0008bab8>] get_new_inode_fast+0x16/0xa2
> [   56.590000]  [<0008bdd0>] iget_locked+0x3c/0x4a
> [   56.590000]  [<000bd7de>] sysfs_get_inode+0x16/0x3a
> [   56.590000]  [<000bedb0>] sysfs_lookup+0x58/0xe4
> [   56.590000]  [<0008273c>] d_alloc_and_lookup+0x40/0x66
> [   56.590000]  [<00082816>] do_lookup+0xb4/0x118
> [   56.590000]  [<00083d3a>] do_last+0x62/0x384
> [   56.590000]  [<0008287a>] link_path_walk+0x0/0x8be
> [   56.590000]  [<0008419c>] do_filp_open+0x140/0x42c
> [   56.590000]  [<0007692a>] __slab_alloc+0x76/0x150
> [   56.590000]  [<00076a5c>] kmem_cache_alloc+0x58/0x6a
> [   56.590000]  [<0008d214>] alloc_fd+0x7a/0x13e
> [   56.590000]  [<0007a9ac>] do_sys_open+0x4a/0xde
> [   56.590000]  [<0007aa56>] sys_open+0x16/0x1c
> [   56.590000]  [<00002630>] syscall+0x8/0xc
> [   56.590000]
> [   56.590000] Code: 307c 0018 d1ef 000c 327c 0014 d3ef 0008 <2651> 
> 2748 0004 208b 2149 0004 2288 265f 4e75 2f0b 206f 0008 2028 0004 0280 0001
> [   56.590000] Disabling lock debugging due to kernel taint

Similar panic in unfreeze_slab when running slabinfo -a. Previous traces 
had reference to 060 emulation in them so I disabled 060 support. Same 
result really.

add_full is only used in slab debugging, so we see some effect of 
debugging here.

Looking at unfreeze slab (debug printk added by me):

> static void unfreeze_slab(struct kmem_cache *s, struct page *page, int 
> tail)
>         __releases(bitlock)
> {
>         struct kmem_cache_node *n = get_node(s, page_to_nid(page));
>
>         if (!n)
>                printk(KERN_INFO "unfreeze slab: zero node for cache %p 
> page %p\n", s, page);
>
>         __ClearPageSlubFrozen(page);
>         if (page->inuse) {
>
>                 if (page->freelist) {
>                         add_partial(n, page, tail);
>                         stat(s, tail ? DEACTIVATE_TO_TAIL : 
> DEACTIVATE_TO_HEAD)
>                 } else {
>                         stat(s, DEACTIVATE_FULL);
>                         if (kmem_cache_debug(s) && (s->flags & 
> SLAB_STORE_USER)
>                                 add_full(n, page);
>                 }
>                 slab_unlock(page);

I do in fact see the expected message warning that the node pointer n is 
NULL right before the crash.

The whole problem seems to be exacerbated by a larger kernel or larger 
size of reserved ST-RAM pool. Using my own .config (tailored to keep the 
compressed kernel image smaller than 1.4 MB) I can boot the kernel using 
init=/bin/sh and run slabinfo without problems. Booting into runlevel 2 
either produces the same panic after initializing network interfaces, or 
throws the kernel into a tight loop there (still responding to keyboard 
but not progressing beyond the 'initializing network interfaces' message 
for minutes). Still no debug messages from the SLUB code though.

Any ideas? Is the reserved bootmem area being used by the SLUB allocator 
some way? I.e. does the allocator pass out memory that is already in use 
by the kernel?

Confused,

  Michael

Re: build warnings

[Michael Schmitz]

Hi Finn,
> I haven't compared the log from Thorsten's kernel failure with the 
> failures I saw, but (anecdotally) my experience was the same: SLUB on m68k 
> was not usable, going back some years.
>
> The introduction of the SLUB allocator was 2.6.22, but I can't help you 
> bisect because I don't recall that it worked ever (?)
>   
Thanks for sharing that information - that does sound like quite a 
fundamental problem, and not just limited to Atari then.
> Anyway, I do recall building SLUB kernels at the time that would fail more 
> often than they booted ... maybe the old releases could offer some clues?
>   
At least they fail in a very consistent manner now. I wonder whether 
it's worth debugging this at all?

Cheers,

  Michael

Re: build warnings

[Geert Uytterhoeven]

On Mon, Jan 31, 2011 at 07:41, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
>> I haven't compared the log from Thorsten's kernel failure with the
>> failures I saw, but (anecdotally) my experience was the same: SLUB on m68k
>> was not usable, going back some years.
>>
>> The introduction of the SLUB allocator was 2.6.22, but I can't help you
>> bisect because I don't recall that it worked ever (?)
>>
>
> Thanks for sharing that information - that does sound like quite a
> fundamental problem, and not just limited to Atari then.
>>
>> Anyway, I do recall building SLUB kernels at the time that would fail more
>> often than they booted ... maybe the old releases could offer some clues?
>>
>
> At least they fail in a very consistent manner now. I wonder whether it's
> worth debugging this at all?

Not for us, but please send your findings (e.g. crash log) to the SLUB people.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: build warnings

[Thorsten Glaser]

Finn Thain dixit:

>The introduction of the SLUB allocator was 2.6.22, but I can't help you 
>bisect because I don't recall that it worked ever (?)

It _appears_ to work well with 2.6.32 Debian though...

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.32-5+m68k.5-atari (Debian 2.6.32-30+m68k.5) (tg@mirbsd.de) (gcc version 4.4.5 (Debian 4.4.5-10) ) #1 Sun Jan 30 10:25:16 UTC 2011
[    0.000000] console [debug0] enabled
[    0.000000] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
[    0.000000] NatFeats found (ARAnyM, 1.0)
[    0.000000] On node 0 totalpages: 3584
[    0.000000] free_area_init_node: node 0, pgdat 003100f4, node_mem_map 00440000
[    0.000000]   DMA zone: 32 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 3552 pages, LIFO batch:0
[    0.000000] On node 1 totalpages: 196608
[    0.000000] free_area_init_node: node 1, pgdat 00310aec, node_mem_map 00464090
[    0.000000]   DMA zone: 1728 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 194880 pages, LIFO batch:31
[    0.000000] Built 2 zonelists in Zone order, mobility grouping on.  Total pages: 198432
[    0.000000] Kernel command line: root=/dev/hda1 console=tty debug=par BOOT_IMAGE=vmlinux
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 787440k/787568k available (2376k kernel code, 10752k data, 96k init)
[    0.000000] SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
[    0.000000] Hierarchical RCU implementation.
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.040000] Calibrating delay loop... 92.97 BogoMIPS (lpj=464896)
[    0.250000] Security Framework initialized
[    0.250000] SELinux:  Disabled at boot.
[    0.250000] Mount-cache hash table entries: 512
[    0.250000] Initializing cgroup subsys ns
[    0.250000] Initializing cgroup subsys cpuacct
[    0.250000] Initializing cgroup subsys devices
[    0.260000] Initializing cgroup subsys freezer
[    0.260000] devtmpfs: initialized
[    0.260000] regulator: core version 0.5
[    0.270000] NET: Registered protocol family 16
[    0.280000] bio: create slab <bio-0> at 0
[    0.280000] SCSI subsystem initialized
[    0.290000] NET: Registered protocol family 2
[    0.290000] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.300000] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.330000] TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
[    0.340000] TCP: Hash tables configured (established 131072 bind 65536)
[    0.340000] TCP reno registered
[    0.340000] NET: Registered protocol family 1
[    0.350000] nfeth API 5
[    0.350000] eth0: nfeth addr:192.168.0.1 (192.168.0.2) HWaddr:52:54:00:22:00:02
[    0.350000] nfhd8: found device with 20971440 blocks (512 bytes)
[    0.360000]  nfhd8: AHDI p1 p2
[    0.360000] audit: initializing netlink socket (disabled)
[    0.360000] type=2000 audit(1293993493.360:1): initialized
[    0.420000] VFS: Disk quotas dquot_6.5.2
[    0.420000] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.430000] msgmni has been set to 1538
[    0.440000] alg: No test for stdrng (krng)
[    0.440000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    0.440000] io scheduler noop registered
[    0.440000] io scheduler anticipatory registered
[    0.440000] io scheduler deadline registered
[    0.450000] io scheduler cfq registered (default)
[    0.450000] atafb_init: start
[    0.450000] atafb_init: initializing Falcon hw
[    0.450000] atafb: screen_base 00b27000 real_screen_base 00b27000 screen_len 307200
[    0.450000] Determined 640x480, depth 4
[    0.450000]    virtual 640x960
[    0.470000] Console: switching to colour frame buffer device 80x30
[    0.480000] fb0: frame buffer device, using 300K of video memory
[    0.530000] Non-volatile memory driver v1.3
[    0.530000] Atari floppy driver: max. HD, track buffering
[    0.540000] Probing floppy drive(s):
[    0.540000] fd0
[    0.590000] brd: module loaded
[    0.610000] Uniform Multi-Platform E-IDE driver
[    0.630000] ide: Falcon IDE controller
[    0.650000] Probing IDE interface ide0...
[    0.970000] hda: Master, ATA DISK drive
[    2.060000] ide0 at 0xfff00000 on irq 15 (serialized)
[    2.080000] ide-gd driver 1.18
[    2.090000] hda: max request size: 128KiB
[    2.110000] hda: 20971440 sectors (10737 MB) w/256KiB Cache, CHS=20805/16/63
[    2.140000]  hda: AHDI hda1 hda2
[    2.170000] ide-cd driver 5.00
[    2.200000] scsi0: options CAN_QUEUE=8 CMD_PER_LUN=1 SCAT-GAT=0 TAGGED-QUEUING=no HOSTID=7 generic options AUTOSENSE REAL DMA SCSI-2 TAGGED QUEUING generic release=7
[    2.250000] scsi0 : Atari native SCSI
[    2.270000] mice: PS/2 mouse device common for all mice
[    2.540000] input: Atari Keyboard as /devices/virtual/input/input0
[    2.550000] blk_queue_max_hw_segments: set to minimum 1
[    2.820000] blk_queue_max_hw_segments: set to minimum 1
[    3.090000] blk_queue_max_hw_segments: set to minimum 1
[    3.110000] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
[    3.130000] TCP cubic registered
[    3.150000] NET: Registered protocol family 17
[    3.170000] NET: Registered protocol family 15
[    3.190000] registered taskstats version 1
[    3.200000] scsi: waiting for bus probes to complete ...
[    3.480000] blk_queue_max_hw_segments: set to minimum 1
[    3.740000] blk_queue_max_hw_segments: set to minimum 1
[    4.000000] blk_queue_max_hw_segments: set to minimum 1
[    4.260000] blk_queue_max_hw_segments: set to minimum 1
[    4.570000] rtc-generic rtc-generic: setting system clock to 2011-02-02 18:38:18 UTC (1296671898)
[    4.650000] kjournald starting.  Commit interval 5 seconds
[    4.670000] EXT3-fs: mounted filesystem with ordered data mode.
[    4.690000] VFS: Mounted root (ext3 filesystem) readonly on device 3:1.
[  195.310000] Adding 1989616k swap on /dev/hda2.  Priority:-1 extents:1 across:1989616k
[  196.240000] EXT3 FS on hda1, internal journal
[  214.350000] NET: Registered protocol family 10
[  214.390000] lo: Disabled Privacy Extensions
[  225.290000] eth0: no IPv6 routers present

bye,
//mirabilos

PS: I put up a new /var/cache/pbuilder/base.cow as ustar.xz on
    https://wiki.debian.org/M68k/Cowbuilder (and got creative),
    for those who want to toy with Debian.
-- 
22:20⎜<asarch> The crazy that persists in his craziness becomes a master
22:21⎜<asarch> And the distance between the craziness and geniality is
only measured by the success                       22:21⎜<mksh> it’s a
very thin line anyway… with some, you don’t know which side they’re on

Re: build warnings

[Michael Schmitz]

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

Thorsten Glaser wrote:
> Finn Thain dixit:
>
>   
>> The introduction of the SLUB allocator was 2.6.22, but I can't help you 
>> bisect because I don't recall that it worked ever (?)
>>     
>
> It _appears_ to work well with 2.6.32 Debian though...
>   
It does indeed. slabinfo -v (run from an init=/bin/sh shell) does not 
crash, nor does it report anything fishy. This kernel even survives 
running e2fsck.

Output of slabinfo -l and slabinfo -T attached for both, FWIW.

I'll bisect this if I've got a bit of time, unless someone else beats me 
to it.

Cheers,

  Michael
> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 2.6.32-5+m68k.5-atari (Debian 2.6.32-30+m68k.5) (tg@mirbsd.de) (gcc version 4.4.5 (Debian 4.4.5-10) ) #1 Sun Jan 30 10:25:16 UTC 2011
> [    0.000000] console [debug0] enabled
> [    0.000000] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
> [    0.000000] NatFeats found (ARAnyM, 1.0)
> [    0.000000] On node 0 totalpages: 3584
> [    0.000000] free_area_init_node: node 0, pgdat 003100f4, node_mem_map 00440000
> [    0.000000]   DMA zone: 32 pages used for memmap
> [    0.000000]   DMA zone: 0 pages reserved
> [    0.000000]   DMA zone: 3552 pages, LIFO batch:0
> [    0.000000] On node 1 totalpages: 196608
> [    0.000000] free_area_init_node: node 1, pgdat 00310aec, node_mem_map 00464090
> [    0.000000]   DMA zone: 1728 pages used for memmap
> [    0.000000]   DMA zone: 0 pages reserved
> [    0.000000]   DMA zone: 194880 pages, LIFO batch:31
> [    0.000000] Built 2 zonelists in Zone order, mobility grouping on.  Total pages: 198432
> [    0.000000] Kernel command line: root=/dev/hda1 console=tty debug=par BOOT_IMAGE=vmlinux
> [    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> [    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [    0.000000] Memory: 787440k/787568k available (2376k kernel code, 10752k data, 96k init)
> [    0.000000] SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
> [    0.000000] Hierarchical RCU implementation.
> [    0.000000] Console: colour dummy device 80x25
> [    0.000000] console [tty0] enabled
> [    0.040000] Calibrating delay loop... 92.97 BogoMIPS (lpj=464896)
> [    0.250000] Security Framework initialized
> [    0.250000] SELinux:  Disabled at boot.
> [    0.250000] Mount-cache hash table entries: 512
> [    0.250000] Initializing cgroup subsys ns
> [    0.250000] Initializing cgroup subsys cpuacct
> [    0.250000] Initializing cgroup subsys devices
> [    0.260000] Initializing cgroup subsys freezer
> [    0.260000] devtmpfs: initialized
> [    0.260000] regulator: core version 0.5
> [    0.270000] NET: Registered protocol family 16
> [    0.280000] bio: create slab <bio-0> at 0
> [    0.280000] SCSI subsystem initialized
> [    0.290000] NET: Registered protocol family 2
> [    0.290000] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> [    0.300000] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> [    0.330000] TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
> [    0.340000] TCP: Hash tables configured (established 131072 bind 65536)
> [    0.340000] TCP reno registered
> [    0.340000] NET: Registered protocol family 1
> [    0.350000] nfeth API 5
> [    0.350000] eth0: nfeth addr:192.168.0.1 (192.168.0.2) HWaddr:52:54:00:22:00:02
> [    0.350000] nfhd8: found device with 20971440 blocks (512 bytes)
> [    0.360000]  nfhd8: AHDI p1 p2
> [    0.360000] audit: initializing netlink socket (disabled)
> [    0.360000] type=2000 audit(1293993493.360:1): initialized
> [    0.420000] VFS: Disk quotas dquot_6.5.2
> [    0.420000] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> [    0.430000] msgmni has been set to 1538
> [    0.440000] alg: No test for stdrng (krng)
> [    0.440000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
> [    0.440000] io scheduler noop registered
> [    0.440000] io scheduler anticipatory registered
> [    0.440000] io scheduler deadline registered
> [    0.450000] io scheduler cfq registered (default)
> [    0.450000] atafb_init: start
> [    0.450000] atafb_init: initializing Falcon hw
> [    0.450000] atafb: screen_base 00b27000 real_screen_base 00b27000 screen_len 307200
> [    0.450000] Determined 640x480, depth 4
> [    0.450000]    virtual 640x960
> [    0.470000] Console: switching to colour frame buffer device 80x30
> [    0.480000] fb0: frame buffer device, using 300K of video memory
> [    0.530000] Non-volatile memory driver v1.3
> [    0.530000] Atari floppy driver: max. HD, track buffering
> [    0.540000] Probing floppy drive(s):
> [    0.540000] fd0
> [    0.590000] brd: module loaded
> [    0.610000] Uniform Multi-Platform E-IDE driver
> [    0.630000] ide: Falcon IDE controller
> [    0.650000] Probing IDE interface ide0...
> [    0.970000] hda: Master, ATA DISK drive
> [    2.060000] ide0 at 0xfff00000 on irq 15 (serialized)
> [    2.080000] ide-gd driver 1.18
> [    2.090000] hda: max request size: 128KiB
> [    2.110000] hda: 20971440 sectors (10737 MB) w/256KiB Cache, CHS=20805/16/63
> [    2.140000]  hda: AHDI hda1 hda2
> [    2.170000] ide-cd driver 5.00
> [    2.200000] scsi0: options CAN_QUEUE=8 CMD_PER_LUN=1 SCAT-GAT=0 TAGGED-QUEUING=no HOSTID=7 generic options AUTOSENSE REAL DMA SCSI-2 TAGGED QUEUING generic release=7
> [    2.250000] scsi0 : Atari native SCSI
> [    2.270000] mice: PS/2 mouse device common for all mice
> [    2.540000] input: Atari Keyboard as /devices/virtual/input/input0
> [    2.550000] blk_queue_max_hw_segments: set to minimum 1
> [    2.820000] blk_queue_max_hw_segments: set to minimum 1
> [    3.090000] blk_queue_max_hw_segments: set to minimum 1
> [    3.110000] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
> [    3.130000] TCP cubic registered
> [    3.150000] NET: Registered protocol family 17
> [    3.170000] NET: Registered protocol family 15
> [    3.190000] registered taskstats version 1
> [    3.200000] scsi: waiting for bus probes to complete ...
> [    3.480000] blk_queue_max_hw_segments: set to minimum 1
> [    3.740000] blk_queue_max_hw_segments: set to minimum 1
> [    4.000000] blk_queue_max_hw_segments: set to minimum 1
> [    4.260000] blk_queue_max_hw_segments: set to minimum 1
> [    4.570000] rtc-generic rtc-generic: setting system clock to 2011-02-02 18:38:18 UTC (1296671898)
> [    4.650000] kjournald starting.  Commit interval 5 seconds
> [    4.670000] EXT3-fs: mounted filesystem with ordered data mode.
> [    4.690000] VFS: Mounted root (ext3 filesystem) readonly on device 3:1.
> [  195.310000] Adding 1989616k swap on /dev/hda2.  Priority:-1 extents:1 across:1989616k
> [  196.240000] EXT3 FS on hda1, internal journal
> [  214.350000] NET: Registered protocol family 10
> [  214.390000] lo: Disabled Privacy Extensions
> [  225.290000] eth0: no IPv6 routers present
>
> bye,
> //mirabilos
>
> PS: I put up a new /var/cache/pbuilder/base.cow as ustar.xz on
>     https://wiki.debian.org/M68k/Cowbuilder (and got creative),
>     for those who want to toy with Debian.
>   


[-- Attachment #2: slabinfo-T-2.6.37 --]
[-- Type: text/plain, Size: 1058 bytes --]

Slabcache Totals
----------------
Slabcaches : 133      Aliases  :   0->0   Active:  65
Memory used:   3.7M   # Loss   : 933.5K   MRatio:    33%
# Objects  :  18.0K   # PartObj:    325   ORatio:     1%

Per Cache    Average         Min         Max       Total
---------------------------------------------------------
#Objects         278           3        6.1K       18.0K
#Slabs             9           1         135         630
#PartSlab          0           0           6          19
%PartSlab         5%          0%         66%          3%
PartObjs           1           0          65         325
% PartObj         4%          0%         50%          1%
Memory         57.3K        4.0K        1.0M        3.7M
Used           42.9K        1.0K      862.2K        2.7M
Loss           14.3K         352      263.3K      933.5K

Per Object   Average         Min         Max
---------------------------------------------
Memory           198          60        8.2K
User             154          16        8.1K
Loss              44          42          56

[-- Attachment #3: slabinfo-T-2.6.32 --]
[-- Type: text/plain, Size: 1058 bytes --]

Slabcache Totals
----------------
Slabcaches : 116      Aliases  :   0->0   Active:  61
Memory used:   2.4M   # Loss   : 676.0K   MRatio:    39%
# Objects  :  13.0K   # PartObj:    259   ORatio:     1%

Per Cache    Average         Min         Max       Total
---------------------------------------------------------
#Objects         214           3        5.3K       13.0K
#Slabs             8           1         130         490
#PartSlab          0           0           2           8
%PartSlab         4%          0%         50%          1%
PartObjs           1           0          99         259
% PartObj         3%          0%         49%          1%
Memory         39.4K        4.0K      532.4K        2.4M
Used           28.4K         624      442.7K        1.7M
Loss           11.0K         512      232.9K      676.0K

Per Object   Average         Min         Max
---------------------------------------------
Memory           176          52        8.2K
User             132           8        8.1K
Loss              44          42          56

[-- Attachment #4: slabinfo-l-2.6.37 --]
[-- Type: text/plain, Size: 5517 bytes --]

Name                   Objects Objsize    Space Slabs/Part/Cpu  O/S O %Fr %Ef Flg
anon_vma                    68      16     4.0K          1/0/0   68 0   0  26 PZFU
anon_vma_chain              74      24     8.1K          2/1/0   60 0  50  21 PZFU
bdev_cache                  17     408     8.1K          1/0/0   17 1   0  84 APaZFU
bio-0                       23     124     4.0K          1/0/0   23 0   0  69 APZFU
biovec-16                   17     192     4.0K          1/0/0   17 0   0  79 APZFU
biovec-256                  10    3072    32.7K          1/0/0   10 3   0  93 APZFU
biovec-64                   10     768     8.1K          1/0/0   10 1   0  93 APZFU
bip-256                     10    3118    32.7K          1/0/0   10 3   0  95 APZFU
blkdev_ioc                  48      42     4.0K          1/0/0   48 0   0  49 PZFU
blkdev_queue                24     960    24.5K          3/0/0    8 1   0  93 PZFU
blkdev_requests             30     220     8.1K          2/0/0   15 0   0  80 PZFU
buffer_head                 80      56     8.1K          2/0/0   40 0   0  54 PaZFU
cfq_io_context              37      64     4.0K          1/0/0   37 0   0  57 PZFU
cfq_queue                   20     152     4.0K          1/0/0   20 0   0  74 PZFU
cred_jar                    49     106     8.1K          2/1/0   25 0  50  63 APZFU
dentry                    3032     128   552.9K        135/6/0   23 0   4  70 PaZFU
ext2_inode_cache           950     428   458.7K         56/2/0   17 1   3  88 PaZFU
file_lock_cache             30      94     4.0K          1/0/0   30 0   0  68 PZFU
files_cache                 18     176     4.0K          1/0/0   18 0   0  77 APZFU
filp                        38     120     8.1K          2/1/0   23 0  50  55 APZFU
fs_cache                    51      28     4.0K          1/0/0   51 0   0  34 APZFU
fsnotify_event              39      60     4.0K          1/0/0   39 0   0  57 PZFU
idr_layer_cache            146     148    28.6K          7/1/0   21 0  14  75 PZFU
inode_cache               2874     300     1.0M        125/1/0   23 1   0  84 PaZFU
kmalloc-1024                30    1024    32.7K          2/0/0   15 2   0  93 PZFU
kmalloc-128                 69     128    12.2K          3/0/0   23 0   0  71 PZFU
kmalloc-16                1725      16   110.5K         27/1/0   64 0   3  24 PZFU
kmalloc-192                272     192    65.5K         16/0/0   17 0   0  79 PZFU
kmalloc-2048                15    2048    32.7K          1/0/0   15 3   0  93 PZFU
kmalloc-256                 39     256    12.2K          3/0/0   13 0   0  81 PZFU
kmalloc-32                 255      32    20.4K          5/0/0   51 0   0  39 PZFU
kmalloc-4096                 7    4096    32.7K          1/0/0    7 3   0  87 PZFU
kmalloc-512                 98     512    57.3K          7/0/0   14 1   0  87 PZFU
kmalloc-64                 396      64    45.0K         11/0/0   36 0   0  56 PZFU
kmalloc-8192                 3    8192    32.7K          1/0/0    3 3   0  75 PZFU
kmalloc-96                 364      96    53.2K         13/0/0   28 0   0  65 PZFU
kmem_cache                  46     134     8.1K          2/0/0   23 0   0  75 *APZFU
kmem_cache_node            153      28    12.2K          3/0/0   51 0   0  34 *APZFU
mm_struct                    9     376     4.0K          1/0/0    9 0   0  82 APZFU
mnt_cache                   23     132     4.0K          1/0/0   23 0   0  74 APZFU
mqueue_inode_cache           8     468     4.0K          1/0/0    8 0   0  91 APZFU
names_cache                  7    4096    32.7K          1/0/0    7 3   0  87 APZFU
pid                         42      44     4.0K          1/0/0   42 0   0  45 APZFU
proc_inode_cache            11     324     4.0K          1/0/0   11 0   0  87 PaZFU
radix_tree_node             60     296    20.4K          5/0/0   12 0   0  86 PaZFU
RAW                         15     496     8.1K          1/0/0   15 1   0  90 APZFU
scsi_cmd_cache              21     146     4.0K          1/0/0   21 0   0  74 APZFU
scsi_sense_cache            28      96     4.0K          1/0/0   28 0   0  65 APZFU
sd_ext_cdb                  53      32     4.0K          1/0/0   53 0   0  41 PZFU
sgpool-128                  15    2048    32.7K          1/0/0   15 3   0  93 APZFU
sgpool-16                   13     256     4.0K          1/0/0   13 0   0  81 APZFU
sgpool-32                   14     512     8.1K          1/0/0   14 1   0  87 APZFU
sgpool-64                   15    1024    16.3K          1/0/0   15 2   0  93 APZFU
sgpool-8                    23     128     4.0K          1/0/0   23 0   0  71 APZFU
shmem_inode_cache          135     392    61.4K         15/0/0    9 0   0  86 PZFU
sighand_cache               35    1292    49.1K          3/1/0   12 2  33  92 APZFU
signal_cache                35     588    24.5K          3/1/0   12 1  33  83 APZFU
sigqueue                    21     144     4.0K          1/0/0   21 0   0  73 PZFU
skbuff_head_cache           18     176     4.0K          1/0/0   18 0   0  77 APZFU
sock_inode_cache            20     328     8.1K          2/0/0   10 0   0  80 APaZFU
sysfs_dir_cache           6118      46   544.7K        133/0/0   46 0   0  51 PZFU
task_delay_info             35      72     4.0K          1/0/0   35 0   0  61 PZFU
task_struct                 49    1220    65.5K          2/1/0   25 3  50  91 PZFU
UNIX                        17     418     8.1K          1/0/0   17 1   0  86 APZFU
vm_area_struct              61      88     8.1K          2/1/0   31 0  50  65 PZFU

[-- Attachment #5: slabinfo-l-2.6.32 --]
[-- Type: text/plain, Size: 5181 bytes --]

Name                   Objects Objsize    Space Slabs/Part/Cpu  O/S O %Fr %Ef Flg
anon_vma                    78       8     4.0K          1/0/0   78 0   0  15 PZFU
bdev_cache                  17     416     8.1K          1/0/0   17 1   0  86 APaZFU
bio-0                       23     124     4.0K          1/0/0   23 0   0  69 APZFU
biovec-16                   17     192     4.0K          1/0/0   17 0   0  79 APZFU
biovec-256                  10    3072    32.7K          1/0/0   10 3   0  93 APZFU
biovec-64                   10     768     8.1K          1/0/0   10 1   0  93 APZFU
bip-256                     10    3118    32.7K          1/0/0   10 3   0  95 APZFU
blkdev_ioc                  46      44     4.0K          1/0/0   46 0   0  49 PZFU
blkdev_queue                24    1248    32.7K          2/0/0   12 2   0  91 PZFU
blkdev_requests             28     200     8.1K          2/1/0   16 0  50  68 PZFU
buffer_head                 80      56     8.1K          2/0/0   40 0   0  54 PaZFU
cfq_io_context              29      96     4.0K          1/0/0   29 0   0  67 PZFU
cfq_queue                   26     108     4.0K          1/0/0   26 0   0  68 PZFU
cred_jar                    47     106     8.1K          2/1/0   25 0  50  60 APZFU
dentry                    2737     128   487.4K        119/0/0   23 0   0  71 PaZFU
ext2_inode_cache            80     440    40.9K         10/0/0    8 0   0  85 PaZFU
file_lock_cache             30      94     4.0K          1/0/0   30 0   0  68 PZFU
files_cache                 18     176     4.0K          1/0/0   18 0   0  77 APZFU
filp                        33     120     8.1K          2/1/0   23 0  50  48 APZFU
fs_cache                    51      28     4.0K          1/0/0   51 0   0  34 APZFU
idr_layer_cache             84     148    16.3K          4/0/0   21 0   0  75 PZFU
inode_cache               2508     312   933.8K        228/0/0   11 0   0  83 PaZFU
kmalloc-1024                30    1024    32.7K          2/0/0   15 2   0  93 PZFU
kmalloc-128                 69     128    12.2K          3/0/0   23 0   0  71 PZFU
kmalloc-16                1596      16   102.4K         25/1/0   64 0   4  24 PZFU
kmalloc-192                255     192    61.4K         15/0/0   17 0   0  79 PZFU
kmalloc-2048                15    2048    32.7K          1/0/0   15 3   0  93 PZFU
kmalloc-256                 52     256    16.3K          4/0/0   13 0   0  81 PZFU
kmalloc-32                 252      32    20.4K          5/2/0   51 0  40  39 PZFU
kmalloc-4096                14    4096    65.5K          2/0/0    7 3   0  87 PZFU
kmalloc-512                 84     512    49.1K          6/0/0   14 1   0  87 PZFU
kmalloc-64                 396      64    45.0K         11/0/0   36 0   0  56 PZFU
kmalloc-8192                 3    8192    32.7K          1/0/0    3 3   0  75 PZFU
kmalloc-96                 334      96    49.1K         12/1/0   28 0   8  65 PZFU
mm_struct                   19     368     8.1K          1/0/0   19 1   0  85 APZFU
mnt_cache                   23     124     4.0K          1/0/0   23 0   0  69 APZFU
mqueue_inode_cache          15     480     8.1K          1/0/0   15 1   0  87 APZFU
names_cache                  7    4096    32.7K          1/0/0    7 3   0  87 APZFU
pid                         42      44     4.0K          1/0/0   42 0   0  45 APZFU
proc_inode_cache            21     336     8.1K          1/0/0   21 1   0  86 PaZFU
radix_tree_node             80     288    28.6K          7/1/0   12 0  14  80 PaZFU
RAW                         15     480     8.1K          1/0/0   15 1   0  87 APZFU
scsi_cmd_cache              21     146     4.0K          1/0/0   21 0   0  74 APZFU
scsi_sense_cache            28      96     4.0K          1/0/0   28 0   0  65 APZFU
sd_ext_cdb                  53      32     4.0K          1/0/0   53 0   0  41 PZFU
sgpool-128                  15    2048    32.7K          1/0/0   15 3   0  93 APZFU
sgpool-16                   13     256     4.0K          1/0/0   13 0   0  81 APZFU
sgpool-32                   14     512     8.1K          1/0/0   14 1   0  87 APZFU
sgpool-64                   15    1024    16.3K          1/0/0   15 2   0  93 APZFU
sgpool-8                    23     128     4.0K          1/0/0   23 0   0  71 APZFU
shmem_inode_cache          135     404    61.4K         15/0/0    9 0   0  88 PZFU
sighand_cache               24    1292    32.7K          2/0/0   12 2   0  94 APZFU
signal_cache                26     568    16.3K          2/0/0   13 1   0  90 APZFU
sigqueue                    21     144     4.0K          1/0/0   21 0   0  73 PZFU
skbuff_head_cache           18     170     4.0K          1/0/0   18 0   0  74 APZFU
sock_inode_cache            20     348     8.1K          2/0/0   10 0   0  84 APaZFU
sysfs_dir_cache           5376      42   458.7K        112/0/0   48 0   0  49 PZFU
task_delay_info             35      72     4.0K          1/0/0   35 0   0  61 PZFU
task_struct                 24    1276    32.7K          2/0/0   12 2   0  93 PZFU
UNIX                         9     398     4.0K          1/0/0    9 0   0  87 APZFU
vm_area_struct              62      88    12.2K          3/2/0   31 0  66  44 PZFU

Re: build warnings

[Michael Schmitz]

Michael Schmitz wrote:
> Thorsten Glaser wrote:
>> Finn Thain dixit:
>>
>>  
>>> The introduction of the SLUB allocator was 2.6.22, but I can't help 
>>> you bisect because I don't recall that it worked ever (?)
>>>     
>>
>> It _appears_ to work well with 2.6.32 Debian though...
>>   
> It does indeed. slabinfo -v (run from an init=/bin/sh shell) does not 
> crash, nor does it report anything fishy. This kernel even survives 
> running e2fsck.
>
> Output of slabinfo -l and slabinfo -T attached for both, FWIW.
>
> I'll bisect this if I've got a bit of time, unless someone else beats 
> me to it.
Result:
 
7340cc84141d5236c5dd003359ee921513cd9b84 is the first bad commit
commit 7340cc84141d5236c5dd003359ee921513cd9b84
Author: Christoph Lameter <cl@linux.com>
Date:   Tue Sep 28 08:10:26 2010 -0500

    slub: reduce differences between SMP and NUMA
   
    Reduce the #ifdefs and simplify bootstrap by making SMP and NUMA as 
much alike
    as possible. This means that there will be an additional indirection 
to get to
    the kmem_cache_node field under SMP.
   
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Christoph Lameter <cl@linux.com>
    Signed-off-by: Pekka Enberg <penberg@kernel.org>

:040000 040000 689fb80a8015b41b68c41cfee356fe1bf1dd4f7b 
d7521accc03ea626f42b87a47830ea838085cad8 M    include
:040000 040000 d28f8440eee90f257bd7b522d4e688874b4449ae 
8eb57f33c45989c68e64d16be5523cdecb29899b M    mm

Diff in question - can anyone guess at what the problem may be?:

diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index b33c0f2..a6c43ec 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -96,8 +96,11 @@ struct kmem_cache {
      * Defragmentation by allocating from a remote node.
      */
     int remote_node_defrag_ratio;
-#endif
     struct kmem_cache_node *node[MAX_NUMNODES];
+#else
+    /* Avoid an extra cache line for UP */
+    struct kmem_cache_node local_node;
+#endif
 };
 
 /*
diff --git a/mm/slub.c b/mm/slub.c
index 064bda2..7e1fe66 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -233,7 +233,11 @@ int slab_is_available(void)
 
 static inline struct kmem_cache_node *get_node(struct kmem_cache *s, 
int node)
 {
+#ifdef CONFIG_NUMA
     return s->node[node];
+#else
+    return &s->local_node;
+#endif
 }
 
 /* Verify that a pointer has an address that is valid within a slab page */
@@ -867,7 +871,7 @@ static inline void inc_slabs_node(struct kmem_cache 
*s, int node, int objects)
      * dilemma by deferring the increment of the count during
      * bootstrap (see early_kmem_cache_node_alloc).
      */
-    if (n) {
+    if (!NUMA_BUILD || n) {
         atomic_long_inc(&n->nr_slabs);
         atomic_long_add(objects, &n->total_objects);
     }
@@ -2108,6 +2112,7 @@ static inline int alloc_kmem_cache_cpus(struct 
kmem_cache *s)
     return s->cpu_slab != NULL;
 }
 
+#ifdef CONFIG_NUMA
 static struct kmem_cache *kmem_cache_node;
 
 /*
@@ -2197,6 +2202,17 @@ static int init_kmem_cache_nodes(struct 
kmem_cache *s)
     }
     return 1;
 }
+#else
+static void free_kmem_cache_nodes(struct kmem_cache *s)
+{
+}
+
+static int init_kmem_cache_nodes(struct kmem_cache *s)
+{
+    init_kmem_cache_node(&s->local_node, s);
+    return 1;
+}
+#endif
 
 static void set_min_partial(struct kmem_cache *s, unsigned long min)
 {
@@ -3007,6 +3023,8 @@ void __init kmem_cache_init(void)
     int caches = 0;
     struct kmem_cache *temp_kmem_cache;
     int order;
+
+#ifdef CONFIG_NUMA
     struct kmem_cache *temp_kmem_cache_node;
     unsigned long kmalloc_size;
 
@@ -3030,6 +3048,12 @@ void __init kmem_cache_init(void)
         0, SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
 
     hotplug_memory_notifier(slab_memory_callback, SLAB_CALLBACK_PRI);
+#else
+    /* Allocate a single kmem_cache from the page allocator */
+    kmem_size = sizeof(struct kmem_cache);
+    order = get_order(kmem_size);
+    kmem_cache = (void *)__get_free_pages(GFP_NOWAIT, order);
+#endif
 
     /* Able to allocate the per node structures */
     slab_state = PARTIAL;
@@ -3040,6 +3064,7 @@ void __init kmem_cache_init(void)
     kmem_cache = kmem_cache_alloc(kmem_cache, GFP_NOWAIT);
     memcpy(kmem_cache, temp_kmem_cache, kmem_size);
 
+#ifdef CONFIG_NUMA
     /*
      * Allocate kmem_cache_node properly from the kmem_cache slab.
      * kmem_cache_node is separately allocated so no need to
@@ -3053,6 +3078,18 @@ void __init kmem_cache_init(void)
     kmem_cache_bootstrap_fixup(kmem_cache_node);
 
     caches++;
+#else
+    /*
+     * kmem_cache has kmem_cache_node embedded and we moved it!
+     * Update the list heads
+     */
+    INIT_LIST_HEAD(&kmem_cache->local_node.partial);
+    list_splice(&temp_kmem_cache->local_node.partial, 
&kmem_cache->local_node.partial);
+#ifdef CONFIG_SLUB_DEBUG
+    INIT_LIST_HEAD(&kmem_cache->local_node.full);
+    list_splice(&temp_kmem_cache->local_node.full, 
&kmem_cache->local_node.full);
+#endif
+#endif
     kmem_cache_bootstrap_fixup(kmem_cache);
     caches++;
     /* Free temporary boot structure */

Re: build warnings

[Thorsten Glaser]

Michael Schmitz dixit:

> Diff in question - can anyone guess at what the problem may be?:

Is it reversed? Looks like that to me, from the commit msg.
Not a clue about the problem, though (but I didn’t read the
surrounding code either, just had a quick look at the diff
while waiting for the coffee machine).

bye,
//mirabilos
-- 
13:47⎜<tobiasu> if i were omnipotent, i would divide by zero
                all day long ;)
(thinking about http://lobacevski.tumblr.com/post/3260866481 by waga)

Re: build warnings

[Michael Schmitz]

Hi Torsten,

the reversal seems to result from the way I ended the bisect. Applying
the posted patch to the Debian 2.6.27 source you had used initially
does indeed seem to fix the problem.  I still need to test that after
resetting my git tree, and I need to test on another ARAnyM
installation as well. Should not take another month though.

Cheers,

  Michael


On Fri, Feb 18, 2011 at 7:18 AM, Thorsten Glaser <tg@mirbsd.de> wrote:
> Michael Schmitz dixit:
>
>> Diff in question - can anyone guess at what the problem may be?:
>
> Is it reversed? Looks like that to me, from the commit msg.
> Not a clue about the problem, though (but I didn’t read the
> surrounding code either, just had a quick look at the diff
> while waiting for the coffee machine).
>
> bye,
> //mirabilos
> --
> 13:47⎜<tobiasu> if i were omnipotent, i would divide by zero
>                all day long ;)
> (thinking about http://lobacevski.tumblr.com/post/3260866481 by waga)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: build warnings

[Thorsten Glaser]

Michael Schmitz dixit:

>the reversal seems to result from the way I ended the bisect. Applying

Ah okay.

>the posted patch to the Debian 2.6.27 source you had used initially
>does indeed seem to fix the problem.  I still need to test that after

Good, then I can use that (for now).

Many thanks!
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Re: build warnings

[Michael Schmitz]

Hi Thorsten,
> Michael Schmitz dixit:
>
>   
>> the reversal seems to result from the way I ended the bisect. Applying
>>     
>
> Ah okay.
>
>   
>> the posted patch to the Debian 2.6.27 source you had used initially
>> does indeed seem to fix the problem.  I still need to test that after
>>     
>
> Good, then I can use that (for now).
>   
Finally had time to test it on my development ARAnyM system which has 
slabinfo installed. Debian 2.6.37 with the offending patch reverted does 
run fine there, and slabinfo -l or -T do not report any errors.

The only difference that patch introduces is to use a static kmem cache 
node in place of a dynamically allocated one. If the allocated one was 
freed by accident that would affect other architectures I presume.

Can you try Thorstens kernel and one with my patch on your Amiga, Geert? 
The brk address space randomization regression was only introduced later 
IIRC?

Just trying to find out whether the Atari init code is to blame here ...

Cheers,

  Michael


> Many thanks!
> //mirabilos
>   

Build Warnings

[Nick Krause]

On Wed, Aug 13, 2014 at 6:59 PM, Nick Krause <xerofoify@gmail.com> wrote:
> Hey Guys,
> With a build of allmodconfig on x86 I hit a few warnings.I am checking
> them myself too to see if there to be concerned
> about. In addition I will attach the file , errors which states where
> the build warnings our. Please let me known if there
> is any other work out there for me to do, I am willing to learn :).
> Cheers Nick
> P.S. I send out my patch for the other bug if you don't known which is
> the correct one, I will resend.
Also thanks to Valdis for the help and I do agreed with you that was a stupid
question and should have checked my code first(sorry again).
Nick

Build Warnings

[Nick Krause]

Hey Guys,
With a build of allmodconfig on x86 I hit a few warnings.I am checking
them myself too to see if there to be concerned
about. In addition I will attach the file , errors which states where
the build warnings our. Please let me known if there
is any other work out there for me to do, I am willing to learn :).
Cheers Nick
P.S. I send out my patch for the other bug if you don't known which is
the correct one, I will resend.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errors
Type: application/octet-stream
Size: 3235 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140813/278226d7/attachment.obj 

Re: build warnings

[Erik Faye-Lund]

On Fri, Jan 29, 2010 at 12:02 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Jan 29, 2010 at 08:03:37PM +1100, Michael Wookey wrote:
>
>> With current master (dace5dd1), the following build warnings appear on
>> Ubuntu 9.10 (x86):
>>
>>   run-command.c: In function ‘notify_parent’:
>>   run-command.c:70: warning: ignoring return value of ‘write’,
>> declared with attribute warn_unused_result
>>   run-command.c: In function ‘die_child’:
>>   run-command.c:80: warning: ignoring return value of ‘write’,
>> declared with attribute warn_unused_result
>>   run-command.c:81: warning: ignoring return value of ‘write’,
>> declared with attribute warn_unused_result
>>   run-command.c:82: warning: ignoring return value of ‘write’,
>> declared with attribute warn_unused_result
>
> There is no point in looking at the return value of any of those calls.
> The first one is about notifying the parent process of a child's failure
> to exec while it is dying (the surrounding function is even an atexit
> handler!). If we can't do that, there is really no alternative behavior.
> The latter three are printing fatal error messages. If we fail at that,
> there is not much to do (unless we should print an error...).
>
>>   ~$ gcc --version
>>   gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
>
> I have heard that Ubuntu recently switched on unused result warnings by
> default, and I have seen complaints that it is generating a lot of
> uninteresting warnings like these.
>
> Does anybody know if this behavior is here to stay? Can it be worked
> around with -Wno-warn-unused-result or something? There are few enough
> callsites here that I am not entirely opposed to annotating them with
> "(void)write" (does that actually work?), but I worry that this is a
> slippery slope. There are a lot of other calls whose return values are
> also uninteresting (just looking in the vicinity of this code, I see an
> fflush and a close, neither of whose failure would be interesting). I'm
> not excited at the prospect of annotating all of them.
>

In my experience, quieting warn-unused-result globally isn't ideal;
this warning has helped me track down some serious issues many times
in the past. IIRC, gcc requires a specific attribute on a function
prototype in order to generate warnings when the return-value isn't
used. I guess the issue we're seeing here is that the glibc that
Ubuntu ships has recently added this attribute for some CRT-functions.

Personally I think that quieting them ("(void)func(...)" does work
AFAIK) can make sense as long as there's only a few call-sites.
However, if it's so many that it'll generate substantial noise in the
git-sources or Ubuntu-users will get annoyed beyond sense,
"-Wno-warn-unused-result" might be the only choice. But perhaps this
is something Ubuntu-users would put in their config.mak?

-- 
Erik "kusma" Faye-Lund

Re: build warnings

[Jeff King]

On Fri, Jan 29, 2010 at 08:03:37PM +1100, Michael Wookey wrote:

> With current master (dace5dd1), the following build warnings appear on
> Ubuntu 9.10 (x86):
> 
>   run-command.c: In function ‘notify_parent’:
>   run-command.c:70: warning: ignoring return value of ‘write’,
> declared with attribute warn_unused_result
>   run-command.c: In function ‘die_child’:
>   run-command.c:80: warning: ignoring return value of ‘write’,
> declared with attribute warn_unused_result
>   run-command.c:81: warning: ignoring return value of ‘write’,
> declared with attribute warn_unused_result
>   run-command.c:82: warning: ignoring return value of ‘write’,
> declared with attribute warn_unused_result

There is no point in looking at the return value of any of those calls.
The first one is about notifying the parent process of a child's failure
to exec while it is dying (the surrounding function is even an atexit
handler!). If we can't do that, there is really no alternative behavior.
The latter three are printing fatal error messages. If we fail at that,
there is not much to do (unless we should print an error...).

>   ~$ gcc --version
>   gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1

I have heard that Ubuntu recently switched on unused result warnings by
default, and I have seen complaints that it is generating a lot of
uninteresting warnings like these.

Does anybody know if this behavior is here to stay? Can it be worked
around with -Wno-warn-unused-result or something? There are few enough
callsites here that I am not entirely opposed to annotating them with
"(void)write" (does that actually work?), but I worry that this is a
slippery slope. There are a lot of other calls whose return values are
also uninteresting (just looking in the vicinity of this code, I see an
fflush and a close, neither of whose failure would be interesting). I'm
not excited at the prospect of annotating all of them.

-Peff

build warnings

[Michael Wookey]

FYI,

With current master (dace5dd1), the following build warnings appear on
Ubuntu 9.10 (x86):

  run-command.c: In function ‘notify_parent’:
  run-command.c:70: warning: ignoring return value of ‘write’,
declared with attribute warn_unused_result
  run-command.c: In function ‘die_child’:
  run-command.c:80: warning: ignoring return value of ‘write’,
declared with attribute warn_unused_result
  run-command.c:81: warning: ignoring return value of ‘write’,
declared with attribute warn_unused_result
  run-command.c:82: warning: ignoring return value of ‘write’,
declared with attribute warn_unused_result

These warnings were introduced by the following commits:

  2b541bf8 ("start_command: detect execvp failures early")
  a5487ddf ("start_command: report child process setup errors to the
parent's stderr")

The GCC details are:

  ~$ gcc --version
  gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1

Re: build warnings

[John W. Linville]

On Mon, Oct 27, 2008 at 12:41:22PM +0200, Tomas Winkler wrote:
> On Mon, Oct 27, 2008 at 12:34 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > Tomas Winkler wrote:
> >> On Sat, Oct 25, 2008 at 10:24 AM, Johannes Berg
> >> <johannes@sipsolutions.net> wrote:
> >>> just FYI in case you haven't seen them. the p54 one looks like a genuine
> >>> problem.
> >>>
> >>> drivers/net/wireless/iwlwifi/iwl-scan.c:69: warning: 'scan_tx_ant'
> >>> defined but not used
> >>
> >> Strange. This variable was removed in 'iwlwifi: unify tx antenna toggling'
> >> patch
> >
> > odd. maybe I don't have the right tree here. Just mentioning the warnings
> > because in my experienced different gcc versions differ.
> >
> Really odd, the lines are just not there. Try to diff to
> wireless-testing master branch.

I advise you do the same -- I see the warning too.

The fault would seem to lie somewhere between me and git -- that bit
seems to have been added back with "wireless: consolidate on a single
escape_essid implementation".  Presumably this happened when I rebased
those patches, although I don't recall having done any manual fixups
that I could have flubbed.

Anyway, don't worry -- I'll take care of this one.

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: build warnings

[Tomas Winkler]

On Mon, Oct 27, 2008 at 12:34 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Tomas Winkler wrote:
>> On Sat, Oct 25, 2008 at 10:24 AM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>>> just FYI in case you haven't seen them. the p54 one looks like a genuine
>>> problem.
>>>
>>> drivers/net/wireless/iwlwifi/iwl-scan.c:69: warning: 'scan_tx_ant'
>>> defined but not used
>>
>> Strange. This variable was removed in 'iwlwifi: unify tx antenna toggling'
>> patch
>
> odd. maybe I don't have the right tree here. Just mentioning the warnings
> because in my experienced different gcc versions differ.
>
Really odd, the lines are just not there. Try to diff to
wireless-testing master branch.
Tomas

>

Re: build warnings

[Johannes Berg]

Tomas Winkler wrote:
> On Sat, Oct 25, 2008 at 10:24 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> just FYI in case you haven't seen them. the p54 one looks like a genuine
>> problem.
>>
>> drivers/net/wireless/iwlwifi/iwl-scan.c:69: warning: 'scan_tx_ant'
>> defined but not used
>
> Strange. This variable was removed in 'iwlwifi: unify tx antenna toggling'
> patch

odd. maybe I don't have the right tree here. Just mentioning the warnings
because in my experienced different gcc versions differ.

johannes

Re: build warnings

[Tomas Winkler]

On Sat, Oct 25, 2008 at 10:24 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> just FYI in case you haven't seen them. the p54 one looks like a genuine
> problem.
>
> drivers/net/wireless/iwlwifi/iwl-scan.c:69: warning: 'scan_tx_ant' defined but not used

Strange. This variable was removed in 'iwlwifi: unify tx antenna toggling' patch
Tomas

build warnings

[Johannes Berg]

just FYI in case you haven't seen them. the p54 one looks like a genuin=
e
problem.

drivers/net/wireless/iwlwifi/iwl-scan.c:69: warning: =E2=80=98scan_tx_a=
nt=E2=80=99 defined but not used
drivers/net/wireless/ath9k/hw.c: In function =E2=80=98ath9k_hw_eeprom_s=
et_board_values=E2=80=99:
drivers/net/wireless/ath9k/hw.c:544: warning: =E2=80=98ant_config=E2=80=
=99 may be used uninitialized in this function
drivers/net/wireless/p54/p54common.c: In function =E2=80=98p54_parse_ee=
prom=E2=80=99:
drivers/net/wireless/p54/p54common.c:325: warning: =E2=80=98synth=E2=80=
=99 may be used uninitialized in this function


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