Page fault, GEOM problem??

[Johan Ström]

On 18 nov 2005, at 23.39, Michal Mertl wrote:

> Johan Ström wrote:
>> Hi!
>>
>> On 18 nov 2005, at 18.43, Xin LI wrote:
>>
>>> Hi, Johan,
>
> < large snip>
>
>> So, it seems it does run savecore after running dumpon and mounting
>> disks etc... Is that wrong?
>
> No, this is normal. When you run savecore you need to have mounted
> filesystems. In order to mount the filesystems they may have to be
> checked. The fsck program requires big amount of memory to check  
> larger
> filesystems so the swap has to be enabled. Core dumps are written  
> to the
> dump device (swap) from the end whereas the swap is normally used from
> the beginning (or the other way around). Therefore there's quite a big
> chance that, even when the swap has to be used for fsck, the core dump
> is intact and usable. If the usage of the swap file by fsck  
> corrupts the
> core dump you may start after next crash in single user mode and  
> run the
> commands manually (without enabling swap).
>
> As to why you can write kernel core dumps only to certain devices the
> answer is that at the time, when the kernel is dumping core, it is
> usually in pretty bad state, kernel internals may be corrupted and so
> on. The dumping code is therefore written to be quite low level so  
> that
> even wedged kernel can be dumped. The dumping code is part of hard  
> disk
> controller's drivers. The gmirror is quite high-level device and geom
> itself needs working scheduler so there will probably never be a  
> way to
> dump on gmirror provided swap. When you issue the dumpon command the
> check is performed whether the driver for the disk you want to dump on
> supports kernel core dumps.
>
> Michal

Well that makes sense... Then that is right at least.. :)

I just noticed another thing... My disk performance... sucks! :P

Some examples (from an otherwise unloaded system):

root at elfi:/home/johan$ time dd if=/dev/zero of=bigfile.zero bs=1024  
count=1000000
1000000+0 records in
1000000+0 records out
1024000000 bytes transferred in 77.014797 secs (13296146 bytes/sec)

real    1m17.100s
user    0m0.244s
sys     0m10.140s

13MB/s from /dev/zero?? This was to my home dir (gm0s1f, last label  
on the slice/disk))..
When I'm about to open a new window in screen (ctrl-a-c) it takes  
forever (or rather, bash takes forever) to init when the above dd is  
running...
Well, iostat during dd:

johan at elfi:~$ iostat
       tty             ad0              ad6               
ad10             cpu
tin tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy  
in id
    0  164  2.19   0  0.00  50.52   3  0.17  50.99   3  0.17   1  0   
1  1 97


0.17MB/s?? Am i missreading these iostats or something?..
Load averages directly after the dd is complete is at 0.36, 0.15,  
0.05, so the dd doesnt take that much of aload to make bash work soo  
slow...Gotta be something else...


Running diskinfo -t gives me good values (for /dev/ad6 and /dev/ad10)

Transfer rates:
         outside:       102400 kbytes in   1.846578 sec =    55454  
kbytes/sec
         middle:        102400 kbytes in   1.879855 sec =    54472  
kbytes/sec
         inside:        102400 kbytes in   3.147158 sec =    32537  
kbytes/sec

So it shouldnt be the disk itself.. those values are the same as when  
I hade the disk in the "temp" system.. However I never did try any dd  
speedtests there.
Btw, tried to do regular cp on a dirtree at some gigs, same slooow  
speed..

Maybee my customkernel is fuckedup or something? It's just a GENERIC  
with some nonused devicedrivers removed so it would be strange...
I'll recompile during night and test GENERIC tomorrow, reporting back..

Did try to move the cards (network/vga/sata) arround in the PCI  
ports, in case there were any strange conflicts... No difference  
except I only got one txerror from xl since last boot (wooh!)

No crash so far.

--
Johan