|
|
 Up |
|
  |
Author: pluknetpluknet
Date: Jun 8, 2010 11:30
hi,
I faced w/ subj. issue on IBM ServeRAID M5015 (LSISAS2108 SAS2.0 6Gbps).
As I can see, lockup is caused by sleeping on sx lock after Giant was acquired.
Can r160217 help me or am I go the wrong way?
from r160217: "Use a sleep mutex instead of an sx lock for the kernel
environment."
after `# mfiutil create raid5 8,9,10,11,12,13`
db> bt 924
Tracing pid 924 tid 100156 td 0xc6fcb340
sched_switch(c6fcb340,0,2) at sched_switch+0x15b
mi_switch(2,0,c0ac4020,0,c09b478a,...) at mi_switch+0x270
critical_exit(1,c6fcb340,c677d88a,b,a,......
|
| Show full article (2.77Kb) |
|
| |
2 Comments |
|
|
Author: Yoshiaki KasaharaYoshiaki Kasahara
Date: Jun 8, 2010 11:11
Hello,
I'd like to add another instance of similar problems. I recently
updated my FreeBSD amd64 box with ZFS root and 8GB RAM from 8-STABLE
(as of Mar 1st) to 8.1-PRERELEASE (as of May 27th). After that, my
box started to crash every couple of days due to kmem_map too small.
Here is a (last week) screenshot of Munin graph about the memory usage
of the box:
http://eron.info/munin-memory.png
In "by month" graph, a white gap at the end of "Week 20" is the update
period from 8-STABLE to 8.1-PRERELEASE I mentioned above. Before the
upgrade, the system was rock solid without any kmem tuning in
loader.conf (vm.kmem_size was around 2.7GB IIRC).
After the update, I could see that more wired memory was assigned, and
then steep drop (crash) occured.
"by day" graph shows my experiment to bump vm.kmem_size=12G
(recommended somewhere in this thread) and explicitly limit
vfs.zfs.arc_max=2G. I was surprised because the wired memory quickly
increased over 5GB...
|
| Show full article (1.81Kb) |
|
| |
4 Comments |
|
|
Author: Pyun YongHyeonPyun YongHyeon
Date: Jun 8, 2010 01:09
On Mon, Jun 07, 2010 at 04:06:11PM +0200, Olaf Seibert wrote:
> On Thu 27 May 2010 at 10:42:11 -0700, Pyun YongHyeon wrote:
>> On Thu, May 27, 2010 at 03:13:10PM +0200, Olaf Seibert wrote:
>>> Here is the output of netstat -m while the problem was going on:
>>>
>>> 25751/1774/27525 mbufs in use (current/cache/total)
>>> 24985/615/25600/25600 mbuf clusters in use (current/cache/total/max)
>> ^^^^^^^^^^^^^^^^^^^^^
>> As Jeremy said, it seems you're hitting mbuf shortage situation. I
>> think nfe(4) is dropping received frames in that case. See how many
>> packets were dropped due to mbuf shortage from the output of
>> "netstat -ndI nfe0". You can also use "sysctl dev.nfe.0.stats" to
>> see MAC statistics maintained in nfe(4) if your MCP controller
>> supports hardware MAC counters.
>
> The sysctl command gives me (among other figures):
>
> dev.nfe.0.stats.rx.drops: 338180
>
> so indeed frames seem to be dropped. ...
|
| Show full article (2.62Kb) |
|
no comments
|
|
|
Author: ThomasThomas
Date: Jun 7, 2010 23:46
Am 04.06.10 01:51, schrieb Xin LI:
> On 2010/06/03 16:24, Thomas wrote:
>> Hello
>
>> I tryed to use crunchgen. It's not working for me. I always get a
>> NFS4ACL error.
>
>> root@bert:/usr/src/release/i386# crunchgen boot_crunch.conf
>> Run "make -f boot_crunch.mk" to build crunched binary. >
>> (cd /usr/src/sbin/tunefs && make -DRELEASE_CRUNCH -Dlint depend &&
>> make -DRELEASE_CRUNCH -Dlint tunefs.o)
>> cc -mtune=native -O2 -fno-strict-aliasing -pipe -march=native -std=gnu99
>> -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
>> -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/tunefs/tunefs.c
>> /usr/src/sbin/tunefs/tunefs.c: In function 'main':
>> /usr/src/sbin/tunefs/tunefs.c:274: error: 'FS_NFS4ACLS' undeclared
>> (first use in this function)
>> /usr/src/sbin/tunefs/tunefs.c:274: error: (Each undeclared identifier is
>> reported only once ...
|
| Show full article (2.01Kb) |
|
no comments
|
|
|
Author: Mikolaj GolubMikolaj Golub
Date: Jun 7, 2010 21:48
On Mon, 7 Jun 2010 16:06:11 +0200 Olaf Seibert wrote:
OS> I do get the impression there is a mbuf leak somehow. On a much older
OS> file server (FreeBSD 6.1, serves a bit of NFS but has no ZFS) the mbuf
OS> cluster useage is much lower, despite a longer uptime:
OS> 256/634/890/25600 mbuf clusters in use (current/cache/total/max)
OS> Also, it shows signs that measures are taken in case of mbuf shortage:
OS> 2259806/466391/598621 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
OS> 1016 calls to protocol drain routines
OS> whereas the FreeBSD 8.0 machine has zero or very low numbers:
OS> 0/3956/1959 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
OS> 0 calls to protocol drain routines
OS> and useage keeps growing:
OS> 26122/1782/27904/32768 mbuf clusters in use (current/cache/total/max)
|
| Show full article (1.21Kb) |
|
no comments
|
|
|
|
|
|
Author: Mark StapperMark Stapper
Date: Jun 1, 2010 09:58
On 30/05/2010 08:31, Garrett Cooper wrote:
> On Wed, May 26, 2010 at 12:05 PM, Mark Stapper wrote:
>
>> On 25/05/2010 20:05, Garrett Cooper wrote:
>>
>>> On Tue, May 25, 2010 at 3:06 AM, Mark Stapper wrote:
>>>
>>>
>>>> On 18/05/2010 08:14, Mark Stapper wrote:
>>>>
>>>>
>>>>> On 18/05/2010 00:22, Garrett Cooper wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Mon, May 17, 2010 at 11:21 AM, Mark Stapper wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> ...
|
| Show full article (26.57Kb) |
|
no comments
|
|
|
Author: Alexander MotinAlexander Motin
Date: Jun 1, 2010 09:15
Hi.
Phil wrote:
> Is it expected behaviour that ahci performs a time-out during boot, even
> though camcontrol indicates success? This is on 8.1-PRERELEASE csup'ed
> today.
>
> I've enclosed dmesg, camcontrol and pciconf information. The timeout is
> approximately 12 to 14 seconds for each connected disk-drive. If I
> run with only usb devices, there are no timeouts. The following
> dmesg is when I connect two HDD's on a VIA SN18000 motherboard, and
> the BIOS has ahci selected, i.e. not IDE nor RAID.
>
> # pciconf -lv | grep -A 4 ahci
> ahci0@pci0:0:15:0: class=0x010601 card=0x62871106 chip=0x62871106
> rev=0x20 hdr=0x00
> vendor = 'VIA Technologies, Inc.'
> device = 'VT8251 AHCI Controller'
> class = mass storage
> subclass = SATA
|
| Show full article (1.45Kb) |
|
no comments
|
|
|
Author: PhilPhil
Date: Jun 1, 2010 07:15
Is it expected behaviour that ahci performs a time-out during boot, even
though camcontrol indicates success? This is on 8.1-PRERELEASE csup'ed
today.
I've enclosed dmesg, camcontrol and pciconf information. The timeout is
approximately 12 to 14 seconds for each connected disk-drive. If I
run with only usb devices, there are no timeouts. The following
dmesg is when I connect two HDD's on a VIA SN18000 motherboard, and
the BIOS has ahci selected, i.e. not IDE nor RAID.
These machines are personal servers and are permanently running.
# dmesg | egrep -i "ahci|ada"
ahci0: port
0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem
0xfcfffc00-0xfcffffff irq 21 at device 15.0 on pci0...
|
| Show full article (2.57Kb) |
|
no comments
|
|
|
|
|
|
Author: Nick RogersNick Rogers
Date: Jun 1, 2010 04:54
I have an 8.0-RELEASE system with 4000 "permanent" ARP entries due to having
a network interface (em(4)) configured with 4000 aliases. The "arp -na"
command takes what I consider to be an extremely long time to finish (up to
30s on an otherwise unloaded system). I am able to replicate this in a test
environment by installing 8.0-RELEASE-amd64 on a VMWare VM w/ 1GB of RAM and
a 2GHz CPU. The 4000 aliases/entries is arbitrary, but nicely illustrates
the performance problem.
The performance is much worse on a real/loaded system. I realize the 4k
aliases on an interface is unusual but I have been effectively using this
configuration in my network to try and keep my end-users's each on his/her
own broadcast domain. The box is a router and I allocate addresses to each
user and put each on his/her own subnet with a netmask of /30. If you would
like more info on this I can provide it, but it has worked effectively in
FreeBSD 6.0-7.2. The slow performance of "arp -na" is an issue for me
because I have a web/CGI tool that runs various reports, many of them
relying on acquiring the current "ARP table", and the performance of arp(8)
makes the web interface extremely slow.
|
| Show full article (5.16Kb) |
|
no comments
|
|
|
|
|
