Re: FreeBSD 9.1 occasional kernel panic
On Wed, 6 Feb 2013 14:02:44 +0100 Jens Jahnke wrote: JJ> On Wed, 06 Feb 2013 14:40:47 +0200 JJ> Andriy Gapon wrote: JJ> JJ> AG> "error 6" is ENXIO, which usually corresponds to a disappearing JJ> AG> device or some such. Do you get anything in logs (or other JJ> AG> objective experience) that could look like that? JJ> JJ> Nothing found so far. System ran stable for the last 18 hours JJ> through. JJ> JJ> I'll look if the error occurs again. It seems that the error is somewhat hardware or bios related. If the machine has been powered off for at least some hours the error occurs on the first boot. It reoccurs if the machine is reset but does not if the machine is powered off and powered on again after a minute. If I set the board controller to ide mode everything is fine but my ssd is not recognized. Another option that seems to work is powering on the machine enter bios and let it run for some minutes. Afterwards I can boot without errors. So maybe the controller needs I "warmup phase". ;) Anyway, I can live with that and thanks for all your answers. Regards, Jens -- 09. Hornung 2013, 09:08 Homepage : http://www.jan0sch.de Fremen add life to spice! pgpL7S29yDWtj.pgp Description: PGP signature
Re: Intel 82574 issue reported on Slashdot
in message , wrote Daniel O'Connor thusly... > > > On 09/02/2013, at 4:46, Jack Vogel wrote: > > > recommends contacting your motherboard manufacturer if you have > > continued concerns or questions whether your products are > > impacted. Here is the link: > > > > http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement > > > > Any questions or concerns may be sent to me. > > In all honesty.. The blog post (and your email) are basically > information free, they don't name names and provide no script or > downloadable code that will allow end users to check if they are > affected. > "Contact your motherboard manufacturer" is much more time > consuming than "Run sysctl... | grep foo | awk ..." to see if your > system is affected. Gift^WStraight from horse's mouth ... http://blog.krisk.org/2013/02/packets-of-death.html http://www.kriskinc.com/intel-pod - parv -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Intel 82574 issue reported on Slashdot
On 09/02/2013, at 20:42, Parv wrote: >> "Contact your motherboard manufacturer" is much more time >> consuming than "Run sysctl... | grep foo | awk ..." to see if your >> system is affected. > > Gift^WStraight from horse's mouth ... > > http://blog.krisk.org/2013/02/packets-of-death.html I've already read this. > http://www.kriskinc.com/intel-pod I'd really rather a test which reads the EEPROM and tells me if it's a problem rather than hang the interface on a machine :) In any case that isn't the point - this may be a "vendor issue" but it reflects poorly on Intel that they didn't take proper ownership of the issue. It would be far, far better for their image to say "some systems may have the fault, go to http:// to find a way to test for your operating system". -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ethtool-like utility for FreeBSD ?
On Thu, Feb 07, 2013 at 03:10:32PM +0100, Kurt Jaeger wrote: > Hi! > > There is a posting public about Intel ethernet adapters and their > packets of death: > > http://blog.krisk.org/2013/02/packets-of-death.html > > Now, how can we test the EEPROM from FreeBSD, similar to the > ethtool of Linux ? > > Thanks for any pointer! See this forum posting: http://www.bsdforen.de/showpost.php?p=248107&postcount=3 pgpkP4D98rcqP.pgp Description: PGP signature
Re: patch which implements ZFS LZ4 compression
Jeremy Chadwick wrote: > On Fri, Feb 08, 2013 at 02:52:57PM -0800, Xin Li wrote: > > On 02/08/13 14:29, Dan Langille wrote: > > > Here is a patch against FreeBSD 9.1 STABLE which implements ZFS LZ4 > > > compression. > > > > > > https://plus.google.com/106386350930626759085/posts/PLbkNfndPiM > > > > > > short link: http://bpaste.net/show/76095 > > > > Please DO NOT use this patch! It will ruin your data silently. > > > > As I already posted on Ivan's Google+ post, I'm doing final universe > > builds to make sure that there is no regression and will merge my > > changes to -HEAD later today. > > Another compression algorithm, this time 50%+ faster than lzjb. Great, > fine, wonderful, awesome, kudos, huzzah, blah blah blah. > > So when is someone going to step up to the plate and fix how compression > (as well as dedup) destroys interactivity on FreeBSD? Do I need to > remind folks of this issue once again? Here you have it, dated October > 2011, including the root cause and how it was fixed in Solaris et al: > > Description: > > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012718.html > > Explanation and how Solaris et al fixed it, and how on Solaris the > problem was major enough that it even caused NFS timeouts (sound > familiar to anyone?): > > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012726.html > > Further testing showing gzip-1 vs. lzjb and interactivity stalls: > > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012752.html > > This is still a problem with base/stable/9. And as I have said > elsewhere on lists, do not ask me to run CURRENT -- it will be a cold > day in hell before I ever do that. I assume this same problem exists in > CURRENT unless I have some key developer/committer say "I backported > this fix in CURRENT, absolutely 100% sure". > > I'm also wondering why iXSystems hasn't stepped up to the plate to > contribute to making this happen, given their business focus. I do not > have the knowledge of the kernel (or of threading) to fix this myself, > and for that I do apologise. > > But every time I see compression or dedup mentioned, I use the > opportunity to bring up this subject. STOP ADDING FEATURES AND FIX > STUFF LIKE THIS INSTEAD -- while new algorithms are neat/fun toys, they > do not truly fix issues like this. How this problem has continually > gotten overlooked is beyond me. Did you consider that other people may have different priorities than you do? > If you want a PR for it, I'll file one, but all it's going to contain is > the contents of this Email. My impression is that your emails describe symptoms and contain some speculation about what the cause might be. I didn't see any sched traces, so it's unclear (to me) that priorities are actual the problem. It's also unclear to me why the dedup and compression issues should be related. There are lots of dedup performance issues reported for Solaris as well and I doubt that they can be fixed for FreeBSD without significantly deviating from the ZFS upstream. I'm not saying a PR would be useless, but in my experience PRs with insufficient information just stay open and if the problem isn't important enough for you to provide additional information filing a PR is unlikely to have a great impact: http://www.freebsd.org/cgi/query-pr-summary.cgi?category=&text=zfs Fabian signature.asc Description: PGP signature
Re: patch which implements ZFS LZ4 compression
On Sat, Feb 09, 2013 at 03:19:18PM +0100, Fabian Keil wrote: > Jeremy Chadwick wrote: > > > On Fri, Feb 08, 2013 at 02:52:57PM -0800, Xin Li wrote: > > > On 02/08/13 14:29, Dan Langille wrote: > > > > Here is a patch against FreeBSD 9.1 STABLE which implements ZFS LZ4 > > > > compression. > > > > > > > > https://plus.google.com/106386350930626759085/posts/PLbkNfndPiM > > > > > > > > short link: http://bpaste.net/show/76095 > > > > > > Please DO NOT use this patch! It will ruin your data silently. > > > > > > As I already posted on Ivan's Google+ post, I'm doing final universe > > > builds to make sure that there is no regression and will merge my > > > changes to -HEAD later today. > > > > Another compression algorithm, this time 50%+ faster than lzjb. Great, > > fine, wonderful, awesome, kudos, huzzah, blah blah blah. > > > > So when is someone going to step up to the plate and fix how compression > > (as well as dedup) destroys interactivity on FreeBSD? Do I need to > > remind folks of this issue once again? Here you have it, dated October > > 2011, including the root cause and how it was fixed in Solaris et al: > > > > Description: > > > > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012718.html > > > > Explanation and how Solaris et al fixed it, and how on Solaris the > > problem was major enough that it even caused NFS timeouts (sound > > familiar to anyone?): > > > > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012726.html > > > > Further testing showing gzip-1 vs. lzjb and interactivity stalls: > > > > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012752.html > > > > This is still a problem with base/stable/9. And as I have said > > elsewhere on lists, do not ask me to run CURRENT -- it will be a cold > > day in hell before I ever do that. I assume this same problem exists in > > CURRENT unless I have some key developer/committer say "I backported > > this fix in CURRENT, absolutely 100% sure". > > > > I'm also wondering why iXSystems hasn't stepped up to the plate to > > contribute to making this happen, given their business focus. I do not > > have the knowledge of the kernel (or of threading) to fix this myself, > > and for that I do apologise. > > > > But every time I see compression or dedup mentioned, I use the > > opportunity to bring up this subject. STOP ADDING FEATURES AND FIX > > STUFF LIKE THIS INSTEAD -- while new algorithms are neat/fun toys, they > > do not truly fix issues like this. How this problem has continually > > gotten overlooked is beyond me. > > Did you consider that other people may have different priorities > than you do? I see what you did there. > > If you want a PR for it, I'll file one, but all it's going to contain is > > the contents of this Email. > > My impression is that your emails describe symptoms and contain > some speculation about what the cause might be. I didn't see any > sched traces, so it's unclear (to me) that priorities are actual > the problem. They contain no speculation. Bob Friesenhahn, who has a lot of experience and familiarity with ZFS on Solaris, seemed to know exactly the behaviour I described. Others on FreeBSD have reported the same behaviour as well, just not in that thread circa 2011. Regarding "sched traces", please expand and include instructions. > It's also unclear to me why the dedup and compression issues should > be related. There are lots of dedup performance issues reported for > Solaris as well and I doubt that they can be fixed for FreeBSD without > significantly deviating from the ZFS upstream. What part of Bob's statement did you not understand? Here, let me repeat it verbatim: "Solaris solved the problem by putting the zfs writer threads into a special scheduling class so that they are usually lower priority than normal processing. Before this change, a desktop system would become almost unusable (intermittent loss of keyboard/mouse) while writing lots of data with compression enabled. Some NFS servers encountered severe enough issues that NFS clients reported NFS timeouts." > I'm not saying a PR would be useless, but in my experience PRs > with insufficient information just stay open and if the problem > isn't important enough for you to provide additional information > filing a PR is unlikely to have a great impact: > http://www.freebsd.org/cgi/query-pr-summary.cgi?category=&text=zfs Then someone in the know needs to explain exactly *what* data would help and (more importantly) *how* to go about providing it (i.e. what to enable in the kernel, what commands to issue, etc.). Eidan has repeatedly insisted that PRs are a Good Thing(tm) because they allow for an official way to track issues vs. mailing list threads that start and turn into tumbleweeds (just like the one I've referenced). Without those necessary instructions, in effect what you're asking me to do is "prove" that the problem exists, which I have already done so. You just d
ath patch from the head
Hello there, May be I've missed something or just can't find in the web, but As I see in HEAD there're some movement around ath driver and it seems to me that there's driver for AR93xx, especially AR938x, chip 0030. Is there any patches to stable to check this driver out, 'cause I just can't compile in this driver from the HEAD on 9.stable? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Interpreting "vmstat -z" output
On a server that's been experiencing some issues, I note the following in "vmstat -z": ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 188, 16, 188, 0, 0 UMA Zones: 3456, 0, 188, 0, 188, 0, 0 UMA Slabs: 568, 0, 1209668,6211,50929964, 0, 0 UMA RCntSlabs: 568, 0, 50791, 1, 50791, 0, 0 UMA Hash: 256, 0, 78, 12, 80, 0, 0 16 Bucket: 152, 0, 227, 23, 227, 0, 0 32 Bucket: 280, 0, 522, 10, 522, 0, 0 64 Bucket: 536, 0, 783, 1, 783, 156, 0 128 Bucket:1048, 0, 33513, 0, 33513,134423, 0 [...] How should I interpret the failure count for "64 Bucket" and "128 Bucket"? Does it represent a problem, or something that needs to be tuned? There are no obvious tunables, but the code is not exactly transparent. No other zones show failures. -GAWollman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9-STABLE -> NFS -> NetAPP:
Hi John …
Does this help?
root@io:~ # ps auxl | grep du
root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du -skx
/vm/2799 0 81426 0 20 0 newnfs
root12353 0.0 0.1 16176 5104 ?? DSat03AM 0:05.41 du -skx
/vm/2799 0 91597 0 20 0 newnfs
root64529 0.0 0.1 16176 5164 ?? DFri03AM 0:05.40 du -skx
/vm/2799 0 43227 0 20 0 newnfs
root12855 0.0 0.0 16308 1988 0 S+5:26AM 0:00.00 grep du
0 12847 0 20 0 piperd
root@io:~ # grep vm /etc/fstab
192.168.1.254:/vol/basic /vmnfs rw,nolockd,intr 0 0
Haven't rebooted yet … if there is anything I can do / try before … ?
The kernel is from Jan 21st …
On 2013-01-19, at 4:57 AM, John Baldwin wrote:
> On Tuesday, December 18, 2012 11:58:36 PM Hub- Marketing wrote:
>> I'm running a few servers sitting on top of a NetAPP file server …
>> everything runs great, but periodically I'm getting:
>>
>> nfs_getpages: error 13
>> vm_fault: pager read error, pid 11355 (https)
>
> Are you using interruptible mounts ("intr" mount option)?
>
> Also, can you get ps output that includes the 'l' flag to show what
> the processes are stuck on?
>
> --
> John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9-STABLE -> NFS -> NetAPP:
Thanks …
# procstat -kk 64529
PIDTID COMM TDNAME KSTACK
64529 100963 du -mi_switch+0x186 sleepq_wait+0x42
__lockmgr_args+0x5cb nfs_lock1+0x4a VOP_LOCK1_APV+0x46 _vn_lock+0x47 vget+0x70
cache_lookup_times+0x54f nfs_lookup+0x17e lookup+0x42f namei+0x4ac
vn_open_cred+0x3bd kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7
On 2013-02-09, at 9:58 PM, Jeremy Chadwick wrote:
> Off-list:
>
> Marc,
>
> You may want to also provide output from "procstat -kk 64529", as this
> will give a full thread calling stack.
>
> The -kk (double-kay) is not a typo. :-)
>
> --
> | Jeremy Chadwick j...@koitsu.org |
> | UNIX Systems Administratorhttp://jdc.koitsu.org/ |
> | Mountain View, CA, US|
> | Making life hard for others since 1977. PGP 4BD6C0CB |
>
> On Sat, Feb 09, 2013 at 09:29:30PM -0800, Marc Fournier wrote:
>>
>> Hi John ?
>>
>> Does this help?
>>
>> root@io:~ # ps auxl | grep du
>> root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du -skx
>> /vm/2799 0 81426 0 20 0 newnfs
>> root12353 0.0 0.1 16176 5104 ?? DSat03AM 0:05.41 du -skx
>> /vm/2799 0 91597 0 20 0 newnfs
>> root64529 0.0 0.1 16176 5164 ?? DFri03AM 0:05.40 du -skx
>> /vm/2799 0 43227 0 20 0 newnfs
>> root12855 0.0 0.0 16308 1988 0 S+5:26AM 0:00.00 grep du
>>0 12847 0 20 0 piperd
>> root@io:~ # grep vm /etc/fstab
>> 192.168.1.254:/vol/basic /vmnfs rw,nolockd,intr 0 0
>>
>> Haven't rebooted yet ? if there is anything I can do / try before ? ?
>>
>> The kernel is from Jan 21st ?
>>
>>
>> On 2013-01-19, at 4:57 AM, John Baldwin wrote:
>>
>>> On Tuesday, December 18, 2012 11:58:36 PM Hub- Marketing wrote:
I'm running a few servers sitting on top of a NetAPP file server ?
everything runs great, but periodically I'm getting:
nfs_getpages: error 13
vm_fault: pager read error, pid 11355 (https)
>>>
>>> Are you using interruptible mounts ("intr" mount option)?
>>>
>>> Also, can you get ps output that includes the 'l' flag to show what
>>> the processes are stuck on?
>>>
>>> --
>>> John Baldwin
>>
>> ___
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
