Hello.
SSD is Intel SSD 530 series (INTEL SSDSC2BW180A4 DC12)
Controler is onboard intel sata controler, motherboard is Supermicro X9SRL-F so
it's Intel C602 chipset
All cache ssd connected to sata 2 ports.
System has LSI MPS controler (SAS2308) with firmware version - 16.00.00.00, but
only h
Hello.
Problem description is in -
http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045088.html
As we find later first begin's problem with errors counter in arcstats than
size of l2 grows abnormal.
After patch rollback everything is ok.
Justin T. Gibbs wrote:
JTG> You'll hav
On Fri, Oct 11, 2013 at 11:52 PM, Miguel C. wrote:
> I updated to alpha5 it is indeed removed.
>
> Thanks
>
>
> "Edward Tomasz Napierała" wrote:
> >Dnia 11 paź 2013 o godz. 13:15 "Mike C."
> >napisał(a):
> >
> >>
> >>> On 10/11/13 09:24, Edward Tomasz Napierała wrote:
> Wiadomość napisana
Ohh stupid question what hardware are you running this on,
specifically what SSD's and what controller and if relavent
what controller Firmware version?
I wonder if you might have bad HW / FW, such as older LSI
mps Firmware, which is know to causing corruption with
some delete methods.
Without t
- Original Message -
From: "Justin T. Gibbs"
I took a quick look at arc.c and see that the trim_map_free()
calls don't take into account ashift. I don't know if that
has anything to do with your problem though. I would expect
this would just make the trim less efficient, but I need
I took a quick look at arc.c and see that the trim_map_free() calls don't take
into account ashift. I don't know if that has anything to do with your problem
though. I would expect this would just make the trim less efficient, but I
need to dig further.
--
Justin
On Oct 16, 2013, at 4:42 PM,
You'll have to be more specific. I don't have that email or know what list on
which to search.
Thanks,
Justin
On Oct 16, 2013, at 2:01 AM, Vitalij Satanivskij wrote:
> Hello.
>
> Patch brocke cache functionality.
>
> Look at's Dmitriy's mail from Mon, 07 Oct 2013 21:09:06 +0300
>
> With s
On 10/14/13 10:00, Ian Lepore wrote:
> The embedded systems we create at $work have readonly root and mfs /var,
> but we do have writable storage on another filesystem. It would work
> for us (not that we need this feature right now) if there were an rcvar
> that pointed to the marker file. Of co
Steven Hartland wrote:
SH> I'm not clear what you rolled back there as r255173 has ntothing to do
SH> with this. Could you clarify
r255173 with you patch from email dated Tue, 17 Sep 2013 23:53:12 +0100 with
subject Re: ZFS secondarycache on SSD problem on r255173
Errors wich we gets is in arcs
On Wed, 16 Oct 2013, Daniel Kalchev wrote:
On 16.10.13 08:42, Kevin Oberman wrote:
nslookup(1) was deprecated about a decade ago because it often provides
misleading results when used for DNS troubleshooting. It generally
works fine for simply turning a name to an address or vice-versa.
Pe
Eitan Adler writes:
> On Wed, Oct 16, 2013 at 1:42 AM, Kevin Oberman wrote:
>> nslookup(1) was deprecated about a decade ago because it often provides
>> misleading results when used for DNS troubleshooting. It generally works
>> fine for simply turning a name to an address or vice-versa.
>
> Ca
On 2013-10-16 05:44, Daniel Kalchev wrote:
>
> On 16.10.13 08:42, Kevin Oberman wrote:
>>
>> nslookup(1) was deprecated about a decade ago because it often provides
>> misleading results when used for DNS troubleshooting. It generally works
>> fine for simply turning a name to an address or vice-ve
I'm not clear what you rolled back there as r255173 has ntothing to do
with this. Could you clarify
Any errors recorded in /var/log/messages?
Could you add code to record the none zero value of zio->io_error in
l2arc_read_done as this may give some indication of the underlying
issue.
Additional
>From kostik...@gmail.com Wed Oct 16 13:02:51 2013
>
>On Wed, Oct 16, 2013 at 02:55:26PM +0300, Konstantin Belousov wrote:
>> On Wed, Oct 16, 2013 at 09:02:19AM +0100, Anton Shterenlikht wrote:
>> > panic:
>> > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/182999
>>=20
>> db> show pginfo 0xe00
On Wed, Oct 16, 2013 at 1:42 AM, Kevin Oberman wrote:
> nslookup(1) was deprecated about a decade ago because it often provides
> misleading results when used for DNS troubleshooting. It generally works
> fine for simply turning a name to an address or vice-versa.
Can you give a bit more detail o
Yes
We have 15 servers, all of them have problem while using with patch fo ashift,
sh we rollback path (for r255173)
and all of them works for a week without that's problem's. Yesterday one of of
servers was updated to stable/10 (beta1)
wich include patch and after around 12 hours of works
On 10/15/13 11:13 PM, Rui Paulo wrote:
On 8 Oct 2013, at 10:41, Julian H. Stacey wrote:
I too am seeing
urtwn0: timeout waiting for checksum report
Sorry, this is a know problem that I haven't been able to figure out... It
probably exists in the OpenBSD driver as well. Usually retryi
Have you confirmed the ashift changes are the actual cause of this
by backing out just those changes and retesting on the same hardware.
Also worth checking your disks smart values to confirm there are no
visible signs of HW errors.
Regards
Steve
- Original Message -
From: "Vital
On Wed, Oct 16, 2013 at 02:55:26PM +0300, Konstantin Belousov wrote:
> On Wed, Oct 16, 2013 at 09:02:19AM +0100, Anton Shterenlikht wrote:
> > panic:
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/182999
>
> db> show pginfo 0xe0027d352600
> page 0xe0027d352600 obj 0xe000128fda00
On Wed, Oct 16, 2013 at 09:02:19AM +0100, Anton Shterenlikht wrote:
> panic:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/182999
db> show pginfo 0xe0027d352600
page 0xe0027d352600 obj 0xe000128fda00 pidx 0x0 phys 0x275dc6000 q 255
hold 0 wire 1
af 0x0 of 0x0 f 0x0 act 0 busy 1 v
On 16.10.13 08:42, Kevin Oberman wrote:
nslookup(1) was deprecated about a decade ago because it often provides
misleading results when used for DNS troubleshooting. It generally works
fine for simply turning a name to an address or vice-versa.
People should really use host(1) for simple looku
for MSI Z77 MPOWER motherboard on FreeBSD 10.0-BETA1, from /var/run/dmesg.boot:
re0: Using 1 MSI-X message
re0: Chip rev. 0x2c80
re0: MAC rev. 0x
miibus0: on re0
rgephy0: PHY 1 on miibus0
rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX
Hi,
I have desktop with 10-alpha2 (before BIND_* removal) and laptop/another
box with alpha3/11-CURRENT
All 3 boxes have the same /etc/resolv.conf:
# Generated by resolvconf
search minsk.domain
nameserver 192.168.9.250
nameserver 192.168.9.1
192.168.9.1 haven't named running, I forget to remove
TB --- 2013-10-16 04:39:11 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2013-10-16 04:39:11 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2013
panic:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/182999
deadlock:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/183007
Anton
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe
Hello.
Patch brocke cache functionality.
Look at's Dmitriy's mail from Mon, 07 Oct 2013 21:09:06 +0300
With subject ZFS L2ARC - incorrect size and abnormal system load on r255173
As patch alredy in head and BETA it's not good.
Yesterday we update one machine up to beta1 and forgot about patch
26 matches
Mail list logo