Kris Kennaway wrote:I disagree - anything that causes a panic is a stability problem. Panics = persist AFTER the tunings (for i386 certainly, and there are unsolved=20 reports about it on amd64 also) and are present even when driving kmem=20 size to the maximum. The tunings *can not solve the problems* currently, = they can only delay the time until they appear, which, by Murphy, often=20 means "sometime around midnight at Saturday". See also the possibility=20 of deadlocks in the ZIL, reported by some users. I did, once to Pawel and once to the lists. Pawel couldn't help me and=20 nobody responded on the lists. Can you perform a MySQL read-write=20 benchmark on one of the 8-core machines with database on ZFS for about=20 an hour without pause? On a machine with 2 GB (or less) of RAM,=20 preferrably? I've seen problems on i386 but maybe they are also present=20 on amd64.
| James Bottomley | [Ksummit-2008-discuss] Fixing the Kernel Janitors project |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| David Miller | Slow DOWN, please!!! |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
