From: Kim Johansen (kim_at_webdealhosting.com)
Date: Thu Dec 06 2007 - 10:22:53 CET
From: Kim Johansen <kim@webdealhosting.com> Date: Thu, 06 Dec 2007 10:22:53 +0100 Message-Id: <1196932973.17894.12.camel@lotta.webdeal.no> Subject: Re: [suse-sles-e] Updates to sles10
On Wed, 2007-12-05 at 18:36 +0100, Kim Johansen wrote:
> On Wed, 2007-12-05 at 18:28 +0100, Marcus Meissner wrote:
> > On Wed, Dec 05, 2007 at 06:21:52PM +0100, Kim Johansen wrote:
> > > On Wed, 2007-12-05 at 17:52 +0100, Marcus Meissner wrote:
> > > > On Wed, Dec 05, 2007 at 05:52:35PM +0100, Kim Johansen wrote:
> > > > > On Wed, 2007-12-05 at 17:41 +0100, Marcus Meissner wrote:
> > > > > > On Wed, Dec 05, 2007 at 05:41:05PM +0100, Kim Johansen wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > As I can see, there has not been any update for SLES10 lately. Does that
> > > > > > > mean we all need to update to SLES10 SP1 to get the latest security
> > > > > > > updates?
> > > > > >
> > > > > > Yes.
> > > > >
> > > > > There is a bug in the ibmvscsi driver, it came together with SLES10 SP1.
> > > > > It cause the system to be very unstable when updating to SP1. And it is
> > > > > not possible to install sles10 SP1 on a LPAR when using vscsi. When will
> > > > > this be fixed? It critical because we cant update to sles10 sp1 before
> > > > > this is fixed.
> > > >
> > > > I am not aware of this specific bug. Do you have any kind of reference?
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/scsi/ibmvscsi
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2b541f8f77fd339e4c5c5cbe8549b52445012704
> >
> > Large parts of this patch are applied in the SLES 10 SP1 codebase at least.
> > The version of the ibmvscsi driver in the SP1 tree is 1.5.8 too.
> >
> > Not sure if this has been fixed after your tests or not, but there were some
> > vscsi fixes.
>
> I will see if I can find more detailed description of the problem, and
> how to reproduce it. A update for SP1 would not help because it not
> possible to install SLES10 SP1 on a LPAR using vscsi.
>
> Updating to SP1 from SLES10 will you a lots of strange behaviour, like
> md5sum's changes on all the files all the time.
Here is a description of the problem:
Model: IBM Power5 505, 9115-505 running SLES10
We're using the SLES10 I/O server, software Raid and LVM. Both disks and
Raid set is reported to be healthy. 2 virtualized servers (lpars) are
running in addition to the I/O server.
Problem:
Integrity issues on files,i.e a tar.gz (approx. 500 mb) when extracting:
..
data/base/23573/24313
data/base/23573/24314
gzip: stdin: invalid compressed data--format violated
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
A continuous md5sum check on the file gives variable checksum without
actually doing anything on the system:
lpar1:/home/postgres/backup # md5sum
backup_postgresql_20070914_092229.tar.gz
b50452659d2cc592f8cb299935f48140
backup_postgresql_20070914_092229.tar.gz
lpar1:/home/postgres/backup # md5sum
backup_postgresql_20070914_092229.tar.gz
6e4591bb8ad0a1cc2ae883e3afc21ee6
backup_postgresql_20070914_092229.tar.gz
The tar.gz file is checked and double checked with md5sum before
transferred from source server. The md5sum is then checked on the
failing target server,and there does not seem to be any problems with
transfer. The problems starts when the file is being extracted. Source
server is a SystemP 550 (virtualized) with SLES10 SP1. We tested the
same procedure on another 550 LPAR (with both SLES10 and SLES10SP!),
with no errors. Note that the 550 has hardware RAID controller, but else
from that, the disk setup is no different.
The same integrity error happens on other files as well. We've tested
with iso files, and software binary files. As an example, we tested the
vim binary, and this file changed. However, after a reboot, the file was
ok. The tar.gz and the iso file get permanent damage.
On the 505 system we run 2 more or like identical lpars in addition to
the I/O server.We've been able to reproduce this error on both lpars.
We've also got the same issue on a SystemP 710 server, with software
raid. It's tempting to assume the problem could be related to the
software raid, since we do not have these problems on the 550 model with
hardware raid. We've also cecked the reiserfs file system (in rescue
mode), but no errors were reported
We have not been able to spot any errors regarding hardware from either
reporting tools
or HMC. We've contacted IBM support, but they claim this is a software
bug.
Please also note that we also have severe problems getting SLES10 SP1 to
work on both 505 and
710. During an upgrade earlier this fall, we ended up with a corrupt
system unable to create the initrd image during the kernel upgrade
process. We tried a forced upgrade after rescue mode and
boot from SLES10 kernel:
lpar1:~ # rpm -Uvh --force kernel-ppc64-2.6.16.46-0.12.ppc.rpm
Preparing... ###########################################
[100%]
1:kernel-ppc64 ###########################################
[100%]
Setting up /lib/modules/2.6.16.46-0.12-ppc64
Root device: /dev/sda3 (mounted on / as reiserfs)
Module list: pdc202xx_new ibmvscsic (xennet xenblk)
Kernel image: /boot/vmlinux-2.6.16.46-0.12-ppc64
Initrd image: /boot/initrd-2.6.16.46-0.12-ppc64
No modules found for kernel
You may now have to update your boot loader configuration.
/sbin/mkinitrd failed
error: %post(kernel-ppc64-2.6.16.46-0.12.ppc) scriptlet failed, exit
status
The same error we do get on a clean SLES10 SP1 installation. Server
firmware does not seem to affect this, since we've tried several. We've
also tried SLES10 SP1 as virtual i/o server, but in this case we've not
been able to boot the client lpars, resulting with nasty errors on the
I/O server:
Oops: Kernel access of bad area, sig: 11 [#1]
Nov 14 18:35:33 vios kernel: SMP NR_CPUS=128 NUMA PSERIES LPAR
Nov 14 18:35:33 vios kernel: Modules linked in: ipv6 apparmor
aamatch_pcre loop bridge dm_mod ibmvscsis e1000 ibmveth linear raid5 xor
raid0 raid1 sg ipr liba
ta firmware_class sd_mod scsi_mod
Nov 14 18:35:33 vios kernel: NIP: C00000000037E3B8 LR: C0000000001C04D8
CTR: C0000000001C049C
Nov 14 18:35:33 vios kernel: REGS: c00000000fdd7780 TRAP: 0300 Not
tainted (2.6.16.53-016-ppc64)
Nov 14 18:35:33 vios kernel: MSR: 8000000000001032 <ME,IR,DR> CR:
24000088 XER: 00000018
Nov 14 18:35:33 vios kernel: DAR: 0000000000000000, DSISR:
0000000040000000
Nov 14 18:35:33 vios kernel: TASK = c00000000292c340[63] 'kblockd/0'
THREAD: c00000000fdd4000 CPU: 0
...
One of our technicians contacted the Linux test lab at IBM in Austin,
Texas, and the found out that the file integrity problem could be
related to the ibmvscsis driver and the bandwidth in the IBM hypervisor.
The problem could temporarily be fixed by reducing the sector max size:
echo 40 > block/sda/queue/max_sectors_kb (which is originally 256)
However this is a performance killer, and is not usable in production.
This is the error messages we've found on the i/o server
I/0 server
------
Sep 27 10:20:18 vios kernel: kblockd/1: page allocation failure.
order:5, mode:0xd0
Sep 27 10:20:18 vios kernel: Call Trace:
Sep 27 10:20:18 vios kernel: [C00000000FD07520] [C00000000000E9E4]
.show_stack+0x68/0x1b0 (unreliable)
Sep 27 10:20:18 vios kernel: [C00000000FD075C0] [C00000000009AE80]
.__alloc_pages+0x31c/0x374
Sep 27 10:20:18 vios kernel: [C00000000FD076B0] [C0000000000B6FA0]
.alloc_page_interleave+0x4c/0xb4
Sep 27 10:20:18 vios kernel: [C00000000FD07740] [C00000000009A490]
.__get_free_pages+0x20/0x9c
Sep 27 10:20:18 vios kernel: [C00000000FD077C0] [C000000000026C28]
.iommu_alloc_coherent+0x84/0x110
Sep 27 10:20:18 vios kernel: [C00000000FD07860] [C000000000020500]
.vio_alloc_coherent+0x14/0x28
Sep 27 10:20:18 vios kernel: [C00000000FD078D0] [C0000000000258D0]
.dma_alloc_coherent+0x64/0x94
Sep 27 10:20:18 vios kernel: [C00000000FD07970] [D0000000002A9318]
.get_data_buffer+0xb8/0xf4 [ibmvscsis]
Sep 27 10:20:18 vios kernel: [C00000000FD07A00] [D0000000002A9834]
.process_rw+0x180/0x500 [ibmvscsis]
Sep 27 10:20:18 vios kernel: [C00000000FD07AC0] [D0000000002AAE88]
.process_cmd+0xef8/0x11e0 [ibmvscsis]
Sep 27 10:20:18 vios kernel: [C00000000FD07BB0] [D0000000002AB2F8]
.run_cmd_queue+0x188/0x738 [ibmvscsis]
Sep 27 10:20:18 vios kernel: [C00000000FD07C90] [D0000000002AC2A0]
.crq_task+0x38/0xb4 [ibmvscsis]
Sep 27 10:20:18 vios kernel: [C00000000FD07D20] [C000000000074F48]
.run_workqueue+0xdc/0x168
Sep 27 10:20:18 vios kernel: [C00000000FD07DC0] [C000000000075BA0]
.worker_thread+0x138/0x1a8
Sep 27 10:20:18 vios kernel: [C00000000FD07EE0] [C00000000007AB88]
.kthread+0x128/0x178
Sep 27 10:20:18 vios kernel: [C00000000FD07F90] [C000000000025514]
.kernel_thread+0x4c/0x68
Sep 27 10:20:18 vios kernel: Mem-info:
Sep 27 10:20:18 vios kernel: Node 0 DMA per-cpu:
Sep 27 10:20:18 vios kernel: cpu 0 hot: high 186, batch 31 used:126
Sep 27 10:20:18 vios kernel: cpu 0 cold: high 62, batch 15 used:54
Sep 27 10:20:18 vios kernel: cpu 1 hot: high 186, batch 31 used:13
Sep 27 10:20:18 vios kernel: cpu 1 cold: high 62, batch 15 used:52
Sep 27 10:20:18 vios kernel: Node 0 DMA32 per-cpu: empty
Sep 27 10:20:18 vios kernel: Node 0 Normal per-cpu: empty
Sep 27 10:20:18 vios kernel: Node 0 HighMem per-cpu: empty
Sep 27 10:20:18 vios kernel: Free pages: 4692kB (0kB HighMem)
Sep 27 10:20:18 vios kernel: Active:24523 inactive:81980 dirty:0
writeback:0 unstable:0 free:1173 slab:10813 mapped:11603 pagetables:514
Sep 27 10:20:18 vios kernel: Node 0 DMA free:4692kB min:2896kB
low:3620kB high:4344kB active:98092kB inactive:327792kB present:524288kB
pages_scanned:66 all_unreclaimable? no
Sep 27 10:20:18 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:18 vios kernel: Node 0 DMA32 free:0kB min:0kB low:0kB
high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0
all_unreclaimable? no
Sep 27 10:20:18 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:18 vios kernel: Node 0 Normal free:0kB min:0kB low:0kB
high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0
all_unreclaimable? no
Sep 27 10:20:18 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:18 vios kernel: Node 0 HighMem free:0kB min:128kB low:128kB
high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0
all_unreclaimable? no
Sep 27 10:20:18 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:18 vios kernel: Node 0 DMA: 55*4kB 78*8kB 110*16kB 53*32kB
6*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB
0*16384kB = 4812kB
Sep 27 10:20:18 vios kernel: Node 0 DMA32: empty
Sep 27 10:20:18 vios kernel: Node 0 Normal: empty
Sep 27 10:20:18 vios kernel: Node 0 HighMem: empty
Sep 27 10:20:18 vios kernel: Swap cache: add 19, delete 0, find 0/0,
race 0+0
Sep 27 10:20:18 vios kernel: Free swap = 2104364kB
Sep 27 10:20:18 vios kernel: Total swap = 2104440kB
Sep 27 10:20:18 vios kernel: Free swap: 2104364kB
Sep 27 10:20:18 vios kernel: 131072 pages of RAM
Sep 27 10:20:18 vios kernel: 6594 reserved pages
Sep 27 10:20:18 vios kernel: 108881 pages shared
Sep 27 10:20:18 vios kernel: 19 pages swap cached
Sep 27 10:20:18 vios kernel: ibmvscsis: Not able to get 29 pages for
buffer, retrying later
Sep 27 10:20:18 vios kernel: kblockd/1: page allocation failure.
order:5, mode:0xd0
Sep 27 10:20:18 vios kernel: Call Trace:
Sep 27 10:20:18 vios kernel: [C00000000FD07520] [C00000000000E9E4]
.show_stack+0x68/0x1b0 (unreliable)
Sep 27 10:20:18 vios kernel: [C00000000FD075C0] [C00000000009AE80]
.__alloc_pages+0x31c/0x374
Sep 27 10:20:18 vios kernel: [C00000000FD076B0] [C0000000000B6FA0]
.alloc_page_interleave+0x4c/0xb4
Sep 27 10:20:18 vios kernel: [C00000000FD07740] [C00000000009A490]
.__get_free_pages+0x20/0x9c
Sep 27 10:20:18 vios kernel: [C00000000FD077C0] [C000000000026C28]
.iommu_alloc_coherent+0x84/0x110
Sep 27 10:20:18 vios kernel: [C00000000FD07860] [C000000000020500]
.vio_alloc_coherent+0x14/0x28
Sep 27 10:20:18 vios kernel: [C00000000FD078D0] [C0000000000258D0]
.dma_alloc_coherent+0x64/0x94
ep 27 10:20:18 vios kernel: [C00000000FD07970] [D0000000002A9318]
get_data_buffer+0xb8/0xf4 [ibmvscsis]
Sep 27 10:20:18 vios kernel: [C00000000FD07A00] [D0000000002A9834]
.process_rw+0x180/0x500 [ibmvscsis]
Sep 27 10:20:18 vios kernel: [C00000000FD07AC0] [D0000000002AAE88]
.process_cmd+0xef8/0x11e0 [ibmvscsis]
Sep 27 10:20:18 vios kernel: [C00000000FD07BB0] [D0000000002AB2F8]
.run_cmd_queue+0x188/0x738 [ibmvscsis]
Sep 27 10:20:18 vios kernel: [C00000000FD07C90] [D0000000002AC2A0]
.crq_task+0x38/0xb4 [ibmvscsis]
Sep 27 10:20:18 vios kernel: [C00000000FD07D20] [C000000000074F48]
.run_workqueue+0xdc/0x168
Sep 27 10:20:18 vios kernel: [C00000000FD07DC0] [C000000000075BA0]
.worker_thread+0x138/0x1a8
Sep 27 10:20:18 vios kernel: [C00000000FD07EE0] [C00000000007AB88]
.kthread+0x128/0x178
Sep 27 10:20:18 vios kernel: [C00000000FD07F90] [C000000000025514]
.kernel_thread+0x4c/0x68
Sep 27 10:20:18 vios kernel: Mem-info:
Sep 27 10:20:18 vios kernel: Node 0 DMA per-cpu:
Sep 27 10:20:18 vios kernel: cpu 0 hot: high 186, batch 31 used:124
Sep 27 10:20:18 vios kernel: cpu 0 cold: high 62, batch 15 used:51
Sep 27 10:20:18 vios kernel: cpu 1 hot: high 186, batch 31 used:8
Sep 27 10:20:18 vios kernel: cpu 1 cold: high 62, batch 15 used:56
Sep 27 10:20:18 vios kernel: Node 0 DMA32 per-cpu: empty
Sep 27 10:20:18 vios kernel: Node 0 Normal per-cpu: empty
Sep 27 10:20:18 vios kernel: Node 0 HighMem per-cpu: empty
Sep 27 10:20:18 vios kernel: Free pages: 5056kB (0kB HighMem)
Sep 27 10:20:18 vios kernel: Active:24484 inactive:81827 dirty:1
writeback:1 unstable:0 free:1264 slab:10821 mapped:11603 pagetables:514
Sep 27 10:20:18 vios kernel: Node 0 DMA free:5056kB min:2896kB
low:3620kB high:4344kB active:97936kB inactive:327308kB present:524288kB
pages_scanned:0 all_unreclaimable? no
Sep 27 10:20:18 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:18 vios kernel: Node 0 DMA32 free:0kB min:0kB low:0kB
high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0
all_unreclaimable? no
Sep 27 10:20:18 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:18 vios kernel: Node 0 Normal free:0kB min:0kB low:0kB
high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0
all_unreclaimable? no
Sep 27 10:20:18 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:18 vios kernel: Node 0 HighMem free:0kB min:128kB low:128kB
high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0
all_unreclaimable? no
Sep 27 10:20:18 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:18 vios kernel: Node 0 DMA: 82*4kB 86*8kB 114*16kB 59*32kB
5*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB
0*16384kB = 5176kB
Sep 27 10:20:18 vios kernel: Node 0 DMA32: empty
Sep 27 10:20:18 vios kernel: Node 0 Normal: empty
Sep 27 10:20:18 vios kernel: Node 0 HighMem: empty
Sep 27 10:20:18 vios kernel: Swap cache: add 19, delete 0, find 0/0,
race 0+0
Sep 27 10:20:18 vios kernel: Free swap = 2104364kB
Sep 27 10:20:18 vios kernel: Total swap = 2104440kB
Sep 27 10:20:18 vios kernel: Free swap: 2104364kB
Sep 27 10:20:18 vios kernel: 131072 pages of RAM
Sep 27 10:20:18 vios kernel: 6594 reserved pages
Sep 27 10:20:18 vios kernel: 108486 pages shared
Sep 27 10:20:18 vios kernel: 19 pages swap cached
Sep 27 10:20:18 vios kernel: ibmvscsis: Not able to get 17 pages for
buffer, retrying later
Sep 27 10:20:18 vios kernel: kblockd/1: page allocation failure.
order:5, mode:0xd0
Sep 27 10:20:18 vios kernel: Call Trace:
Sep 27 10:20:18 vios kernel: [C00000000FD07520] [C00000000000E9E4]
.show_stack+0x68/0x1b0 (unreliable)
Sep 27 10:20:18 vios kernel: [C00000000FD075C0] [C00000000009AE80]
.__alloc_pages+0x31c/0x374
Sep 27 10:20:18 vios kernel: [C00000000FD076B0] [C0000000000B6FA0]
.alloc_page_interleave+0x4c/0xb4
Sep 27 10:20:21 vios kernel: [C00000000FD07740] [C00000000009A490]
.__get_free_pages+0x20/0x9c
Sep 27 10:20:21 vios kernel: [C00000000FD077C0] [C000000000026C28]
.iommu_alloc_coherent+0x84/0x110
Sep 27 10:20:21 vios kernel: [C00000000FD07860] [C000000000020500]
.vio_alloc_coherent+0x14/0x28
Sep 27 10:20:23 vios kernel: [C00000000FD078D0] [C0000000000258D0]
.dma_alloc_coherent+0x64/0x94
Sep 27 10:20:24 vios kernel: [C00000000FD07970] [D0000000002A9318]
.get_data_buffer+0xb8/0xf4 [ibmvscsis]
Sep 27 10:20:24 vios kernel: [C00000000FD07A00] [D0000000002A9834]
.process_rw+0x180/0x500 [ibmvscsis]
Sep 27 10:20:24 vios kernel: [C00000000FD07AC0] [D0000000002AAE88]
.process_cmd+0xef8/0x11e0 [ibmvscsis]
Sep 27 10:20:24 vios kernel: [C00000000FD07BB0] [D0000000002AB2F8]
.run_cmd_queue+0x188/0x738 [ibmvscsis]
Sep 27 10:20:24 vios kernel: [C00000000FD07C90] [D0000000002AC2A0]
.crq_task+0x38/0xb4 [ibmvscsis]
Sep 27 10:20:24 vios kernel: [C00000000FD07D20] [C000000000074F48]
.run_workqueue+0xdc/0x168
Sep 27 10:20:24 vios kernel: [C00000000FD07DC0] [C000000000075BA0]
.worker_thread+0x138/0x1a8
Sep 27 10:20:25 vios kernel: [C00000000FD07EE0] [C00000000007AB88]
.kthread+0x128/0x178
Sep 27 10:20:25 vios kernel: [C00000000FD07F90] [C000000000025514]
.kernel_thread+0x4c/0x68
Sep 27 10:20:25 vios kernel: Mem-info:
Sep 27 10:20:25 vios kernel: Node 0 DMA per-cpu:
Sep 27 10:20:25 vios kernel: cpu 0 hot: high 186, batch 31 used:171
Sep 27 10:20:25 vios kernel: cpu 0 cold: high 62, batch 15 used:58
Sep 27 10:20:25 vios kernel: cpu 1 hot: high 186, batch 31 used:31
Sep 27 10:20:25 vios kernel: cpu 1 cold: high 62, batch 15 used:49
Sep 27 10:20:25 vios kernel: Node 0 DMA32 per-cpu: empty
Sep 27 10:20:25 vios kernel: Node 0 Normal per-cpu: empty
Sep 27 10:20:25 vios kernel: Node 0 HighMem per-cpu: empty
Sep 27 10:20:25 vios kernel: Free pages: 11376kB (0kB HighMem)
Sep 27 10:20:25 vios kernel: Active:24125 inactive:80370 dirty:1
writeback:1 unstable:0 free:2844 slab:10824 mapped:11603 pagetables:514
Sep 27 10:20:25 vios kernel: Node 0 DMA free:11376kB min:2896kB
low:3620kB high:4344kB active:96500kB inactive:321480kB present:524288kB
pages_scanned:0 all_unreclaimable? no
Sep 27 10:20:25 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:25 vios kernel: Node 0 DMA32 free:0kB min:0kB low:0kB
high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0
all_unreclaimable? no
Sep 27 10:20:25 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:25 vios kernel: Node 0 Normal free:0kB min:0kB low:0kB
high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0
all_unreclaimable? no
Sep 27 10:20:25 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:25 vios kernel: Node 0 HighMem free:0kB min:128kB low:128kB
high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0
all_unreclaimable? no
Sep 27 10:20:25 vios kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 10:20:25 vios kernel: Node 0 DMA: 451*4kB 225*8kB 205*16kB
98*32kB 22*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB
0*8192kB 0*16384kB = 11556kB
Sep 27 10:20:25 vios kernel: Node 0 DMA32: empty
Sep 27 10:20:25 vios kernel: Node 0 Normal: empty
Sep 27 10:20:25 vios kernel: Node 0 HighMem: empty
Sep 27 10:20:25 vios kernel: Swap cache: add 19, delete 0, find 0/0,
race 0+0
Sep 27 10:20:25 vios kernel: Free swap = 2104364kB
Sep 27 10:20:25 vios kernel: Total swap = 2104440kB
Sep 27 10:20:25 vios kernel: Free swap: 2104364kB
Sep 27 10:20:25 vios kernel: 131072 pages of RAM
Sep 27 10:20:25 vios kernel: 6594 reserved pages
Sep 27 10:20:25 vios kernel: 106820 pages shared
Sep 27 10:20:25 vios kernel: 19 pages swap cached
Sep 27 10:20:25 vios kernel: ibmvscsis: Not able to get 25 pages for
buffer, retrying later
- Kim
>
> >
> > Ciao, Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
> For additional commands, e-mail: suse-sles-e-help@suse.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
For additional commands, e-mail: suse-sles-e-help@suse.com
This archive was generated by hypermail 2.1.7 : Wed Dec 05 2007 - 23:21:56 CET