* build warnings
@ 2011-01-13 14:44 Thorsten Glaser
2011-01-13 19:24 ` Michael Schmitz
2011-01-14 9:25 ` Thorsten Glaser
0 siblings, 2 replies; 43+ messages in thread
From: Thorsten Glaser @ 2011-01-13 14:44 UTC (permalink / raw)
To: linux-m68k
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 :-)
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-01-13 14:44 build warnings Thorsten Glaser
@ 2011-01-13 19:24 ` Michael Schmitz
2011-01-13 20:55 ` Geert Uytterhoeven
2011-01-14 9:25 ` Thorsten Glaser
1 sibling, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2011-01-13 19:24 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-13 19:24 ` Michael Schmitz
@ 2011-01-13 20:55 ` Geert Uytterhoeven
0 siblings, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2011-01-13 20:55 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-13 14:44 build warnings Thorsten Glaser
2011-01-13 19:24 ` Michael Schmitz
@ 2011-01-14 9:25 ` Thorsten Glaser
2011-01-14 12:17 ` Geert Uytterhoeven
2011-01-17 6:50 ` Michael Schmitz
1 sibling, 2 replies; 43+ messages in thread
From: Thorsten Glaser @ 2011-01-14 9:25 UTC (permalink / raw)
To: linux-m68k
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 :-)
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-14 9:25 ` Thorsten Glaser
@ 2011-01-14 12:17 ` Geert Uytterhoeven
2011-01-16 4:36 ` Michael Schmitz
2011-01-17 6:50 ` Michael Schmitz
1 sibling, 1 reply; 43+ messages in thread
From: Geert Uytterhoeven @ 2011-01-14 12:17 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-01-14 12:17 ` Geert Uytterhoeven
@ 2011-01-16 4:36 ` Michael Schmitz
2011-01-16 13:54 ` Thorsten Glaser
0 siblings, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2011-01-16 4:36 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Thorsten Glaser, linux-m68k
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
>
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-01-16 4:36 ` Michael Schmitz
@ 2011-01-16 13:54 ` Thorsten Glaser
2011-01-16 21:26 ` Michael Schmitz
0 siblings, 1 reply; 43+ messages in thread
From: Thorsten Glaser @ 2011-01-16 13:54 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Geert Uytterhoeven, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-16 13:54 ` Thorsten Glaser
@ 2011-01-16 21:26 ` Michael Schmitz
2011-01-16 22:29 ` Thorsten Glaser
0 siblings, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2011-01-16 21:26 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: Geert Uytterhoeven, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-16 21:26 ` Michael Schmitz
@ 2011-01-16 22:29 ` Thorsten Glaser
2011-01-17 2:48 ` Michael Schmitz
0 siblings, 1 reply; 43+ messages in thread
From: Thorsten Glaser @ 2011-01-16 22:29 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Geert Uytterhoeven, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-16 22:29 ` Thorsten Glaser
@ 2011-01-17 2:48 ` Michael Schmitz
2011-01-17 6:51 ` Geert Uytterhoeven
2011-01-30 5:37 ` Michael Schmitz
0 siblings, 2 replies; 43+ messages in thread
From: Michael Schmitz @ 2011-01-17 2:48 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: Geert Uytterhoeven, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-17 2:48 ` Michael Schmitz
@ 2011-01-17 6:51 ` Geert Uytterhoeven
2011-01-17 19:50 ` Michael Schmitz
2011-01-30 5:37 ` Michael Schmitz
1 sibling, 1 reply; 43+ messages in thread
From: Geert Uytterhoeven @ 2011-01-17 6:51 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-01-17 6:51 ` Geert Uytterhoeven
@ 2011-01-17 19:50 ` Michael Schmitz
2011-01-17 20:14 ` Geert Uytterhoeven
0 siblings, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2011-01-17 19:50 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-01-17 19:50 ` Michael Schmitz
@ 2011-01-17 20:14 ` Geert Uytterhoeven
2011-01-18 1:18 ` Michael Schmitz
0 siblings, 1 reply; 43+ messages in thread
From: Geert Uytterhoeven @ 2011-01-17 20:14 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-01-17 20:14 ` Geert Uytterhoeven
@ 2011-01-18 1:18 ` Michael Schmitz
2011-01-18 13:29 ` Geert Uytterhoeven
0 siblings, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2011-01-18 1:18 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-01-18 1:18 ` Michael Schmitz
@ 2011-01-18 13:29 ` Geert Uytterhoeven
2011-01-18 23:54 ` Michael Schmitz
0 siblings, 1 reply; 43+ messages in thread
From: Geert Uytterhoeven @ 2011-01-18 13:29 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-01-18 13:29 ` Geert Uytterhoeven
@ 2011-01-18 23:54 ` Michael Schmitz
2011-01-19 7:59 ` Geert Uytterhoeven
0 siblings, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2011-01-18 23:54 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-01-18 23:54 ` Michael Schmitz
@ 2011-01-19 7:59 ` Geert Uytterhoeven
0 siblings, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2011-01-19 7:59 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-17 2:48 ` Michael Schmitz
2011-01-17 6:51 ` Geert Uytterhoeven
@ 2011-01-30 5:37 ` Michael Schmitz
2011-01-30 13:53 ` Thorsten Glaser
2011-01-30 18:57 ` Geert Uytterhoeven
1 sibling, 2 replies; 43+ messages in thread
From: Michael Schmitz @ 2011-01-30 5:37 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Thorsten Glaser, Geert Uytterhoeven, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-30 5:37 ` Michael Schmitz
@ 2011-01-30 13:53 ` Thorsten Glaser
2011-01-30 18:57 ` Geert Uytterhoeven
1 sibling, 0 replies; 43+ messages in thread
From: Thorsten Glaser @ 2011-01-30 13:53 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Geert Uytterhoeven, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-30 5:37 ` Michael Schmitz
2011-01-30 13:53 ` Thorsten Glaser
@ 2011-01-30 18:57 ` Geert Uytterhoeven
2011-01-31 1:49 ` Michael Schmitz
1 sibling, 1 reply; 43+ messages in thread
From: Geert Uytterhoeven @ 2011-01-30 18:57 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-01-30 18:57 ` Geert Uytterhoeven
@ 2011-01-31 1:49 ` Michael Schmitz
2011-01-31 4:03 ` Finn Thain
2011-01-31 6:28 ` Michael Schmitz
0 siblings, 2 replies; 43+ messages in thread
From: Michael Schmitz @ 2011-01-31 1:49 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Michael Schmitz, Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-31 1:49 ` Michael Schmitz
@ 2011-01-31 4:03 ` Finn Thain
2011-01-31 6:41 ` Michael Schmitz
2011-02-05 23:41 ` Thorsten Glaser
2011-01-31 6:28 ` Michael Schmitz
1 sibling, 2 replies; 43+ messages in thread
From: Finn Thain @ 2011-01-31 4:03 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Geert Uytterhoeven, Thorsten Glaser, linux-m68k
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
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-31 4:03 ` Finn Thain
@ 2011-01-31 6:41 ` Michael Schmitz
2011-01-31 7:10 ` Geert Uytterhoeven
2011-02-05 23:41 ` Thorsten Glaser
1 sibling, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2011-01-31 6:41 UTC (permalink / raw)
To: Finn Thain
Cc: Michael Schmitz, Geert Uytterhoeven, Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-31 6:41 ` Michael Schmitz
@ 2011-01-31 7:10 ` Geert Uytterhoeven
0 siblings, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2011-01-31 7:10 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Finn Thain, Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-31 4:03 ` Finn Thain
2011-01-31 6:41 ` Michael Schmitz
@ 2011-02-05 23:41 ` Thorsten Glaser
2011-02-13 4:34 ` Michael Schmitz
1 sibling, 1 reply; 43+ messages in thread
From: Thorsten Glaser @ 2011-02-05 23:41 UTC (permalink / raw)
To: linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-02-05 23:41 ` Thorsten Glaser
@ 2011-02-13 4:34 ` Michael Schmitz
2011-02-17 7:22 ` Michael Schmitz
0 siblings, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2011-02-13 4:34 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: linux-m68k
[-- 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-02-13 4:34 ` Michael Schmitz
@ 2011-02-17 7:22 ` Michael Schmitz
2011-02-17 18:18 ` Thorsten Glaser
0 siblings, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2011-02-17 7:22 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: linux-m68k
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 */
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: build warnings
2011-02-17 7:22 ` Michael Schmitz
@ 2011-02-17 18:18 ` Thorsten Glaser
2011-03-13 7:34 ` Michael Schmitz
0 siblings, 1 reply; 43+ messages in thread
From: Thorsten Glaser @ 2011-02-17 18:18 UTC (permalink / raw)
Cc: linux-m68k
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)
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2011-02-17 18:18 ` Thorsten Glaser
@ 2011-03-13 7:34 ` Michael Schmitz
2011-03-13 10:37 ` Thorsten Glaser
0 siblings, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2011-03-13 7:34 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: linux-m68k
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
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-03-13 7:34 ` Michael Schmitz
@ 2011-03-13 10:37 ` Thorsten Glaser
2011-03-26 1:26 ` Michael Schmitz
0 siblings, 1 reply; 43+ messages in thread
From: Thorsten Glaser @ 2011-03-13 10:37 UTC (permalink / raw)
Cc: linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-03-13 10:37 ` Thorsten Glaser
@ 2011-03-26 1:26 ` Michael Schmitz
0 siblings, 0 replies; 43+ messages in thread
From: Michael Schmitz @ 2011-03-26 1:26 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: linux-m68k, Geert Uytterhoeven
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
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-31 1:49 ` Michael Schmitz
2011-01-31 4:03 ` Finn Thain
@ 2011-01-31 6:28 ` Michael Schmitz
1 sibling, 0 replies; 43+ messages in thread
From: Michael Schmitz @ 2011-01-31 6:28 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Geert Uytterhoeven, Thorsten Glaser, linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2011-01-14 9:25 ` Thorsten Glaser
2011-01-14 12:17 ` Geert Uytterhoeven
@ 2011-01-17 6:50 ` Michael Schmitz
1 sibling, 0 replies; 43+ messages in thread
From: Michael Schmitz @ 2011-01-17 6:50 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: linux-m68k
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Build Warnings
@ 2014-08-13 22:59 Nick Krause
2014-08-14 4:14 ` Nick Krause
0 siblings, 1 reply; 43+ messages in thread
From: Nick Krause @ 2014-08-13 22:59 UTC (permalink / raw)
To: kernelnewbies
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Build Warnings
2014-08-13 22:59 Build Warnings Nick Krause
@ 2014-08-14 4:14 ` Nick Krause
0 siblings, 0 replies; 43+ messages in thread
From: Nick Krause @ 2014-08-14 4:14 UTC (permalink / raw)
To: kernelnewbies
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* build warnings
@ 2010-01-29 9:03 Michael Wookey
2010-01-29 11:02 ` Jeff King
0 siblings, 1 reply; 43+ messages in thread
From: Michael Wookey @ 2010-01-29 9:03 UTC (permalink / raw)
To: Git Mailing List, Johannes Sixt
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: build warnings
2010-01-29 9:03 build warnings Michael Wookey
@ 2010-01-29 11:02 ` Jeff King
2010-01-29 11:23 ` Erik Faye-Lund
0 siblings, 1 reply; 43+ messages in thread
From: Jeff King @ 2010-01-29 11:02 UTC (permalink / raw)
To: Michael Wookey; +Cc: Git Mailing List, Johannes Sixt
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2010-01-29 11:02 ` Jeff King
@ 2010-01-29 11:23 ` Erik Faye-Lund
0 siblings, 0 replies; 43+ messages in thread
From: Erik Faye-Lund @ 2010-01-29 11:23 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Wookey, Git Mailing List, Johannes Sixt
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* build warnings
@ 2008-10-25 8:24 Johannes Berg
2008-10-27 10:30 ` Tomas Winkler
0 siblings, 1 reply; 43+ messages in thread
From: Johannes Berg @ 2008-10-25 8:24 UTC (permalink / raw)
To: linux-wireless; +Cc: Chr, Tomas Winkler, mcgrof
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2008-10-25 8:24 Johannes Berg
@ 2008-10-27 10:30 ` Tomas Winkler
2008-10-27 10:34 ` Johannes Berg
0 siblings, 1 reply; 43+ messages in thread
From: Tomas Winkler @ 2008-10-27 10:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Chr, mcgrof
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2008-10-27 10:30 ` Tomas Winkler
@ 2008-10-27 10:34 ` Johannes Berg
2008-10-27 10:41 ` Tomas Winkler
0 siblings, 1 reply; 43+ messages in thread
From: Johannes Berg @ 2008-10-27 10:34 UTC (permalink / raw)
To: Tomas Winkler; +Cc: linux-wireless, Chr, mcgrof
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2008-10-27 10:34 ` Johannes Berg
@ 2008-10-27 10:41 ` Tomas Winkler
2008-10-27 13:28 ` John W. Linville
0 siblings, 1 reply; 43+ messages in thread
From: Tomas Winkler @ 2008-10-27 10:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Chr, mcgrof
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
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: build warnings
2008-10-27 10:41 ` Tomas Winkler
@ 2008-10-27 13:28 ` John W. Linville
0 siblings, 0 replies; 43+ messages in thread
From: John W. Linville @ 2008-10-27 13:28 UTC (permalink / raw)
To: Tomas Winkler; +Cc: Johannes Berg, linux-wireless, Chr, mcgrof
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.
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2014-08-14 4:14 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-13 14:44 build warnings Thorsten Glaser
2011-01-13 19:24 ` Michael Schmitz
2011-01-13 20:55 ` Geert Uytterhoeven
2011-01-14 9:25 ` Thorsten Glaser
2011-01-14 12:17 ` Geert Uytterhoeven
2011-01-16 4:36 ` Michael Schmitz
2011-01-16 13:54 ` Thorsten Glaser
2011-01-16 21:26 ` Michael Schmitz
2011-01-16 22:29 ` Thorsten Glaser
2011-01-17 2:48 ` Michael Schmitz
2011-01-17 6:51 ` Geert Uytterhoeven
2011-01-17 19:50 ` Michael Schmitz
2011-01-17 20:14 ` Geert Uytterhoeven
2011-01-18 1:18 ` Michael Schmitz
2011-01-18 13:29 ` Geert Uytterhoeven
2011-01-18 23:54 ` Michael Schmitz
2011-01-19 7:59 ` Geert Uytterhoeven
2011-01-30 5:37 ` Michael Schmitz
2011-01-30 13:53 ` Thorsten Glaser
2011-01-30 18:57 ` Geert Uytterhoeven
2011-01-31 1:49 ` Michael Schmitz
2011-01-31 4:03 ` Finn Thain
2011-01-31 6:41 ` Michael Schmitz
2011-01-31 7:10 ` Geert Uytterhoeven
2011-02-05 23:41 ` Thorsten Glaser
2011-02-13 4:34 ` Michael Schmitz
2011-02-17 7:22 ` Michael Schmitz
2011-02-17 18:18 ` Thorsten Glaser
2011-03-13 7:34 ` Michael Schmitz
2011-03-13 10:37 ` Thorsten Glaser
2011-03-26 1:26 ` Michael Schmitz
2011-01-31 6:28 ` Michael Schmitz
2011-01-17 6:50 ` Michael Schmitz
-- strict thread matches above, loose matches on Subject: below --
2014-08-13 22:59 Build Warnings Nick Krause
2014-08-14 4:14 ` Nick Krause
2010-01-29 9:03 build warnings Michael Wookey
2010-01-29 11:02 ` Jeff King
2010-01-29 11:23 ` Erik Faye-Lund
2008-10-25 8:24 Johannes Berg
2008-10-27 10:30 ` Tomas Winkler
2008-10-27 10:34 ` Johannes Berg
2008-10-27 10:41 ` Tomas Winkler
2008-10-27 13:28 ` John W. Linville
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.