Hi.
On 23.07.2017 0:28, Eugene M. Zheganin wrote:
Hi,
On 22.07.2017 17:08, Eugene M. Zheganin wrote:
is this weird error "cannot destroy: already exists" related to the
fact that the zvol is faulty ? Does it indicate that metadata is
probably faulty too ? Anyway, is there a way to destroy t
On Sun, Jul 23, 2017 at 10:47 PM, Terry Kennedy wrote:
> My offer of a test system with the card is still open, if someone wants
> to pick this up again. I will note that in my case, it only happens in my
> Supermicro systems (but again, Linux works well with it on those boxes).
> The SM961 in
> I bought this card but never could get it to fail, despite trying them in a
> number of different systems :(. So lighten up please...
They are obviously working for some people, but enough people are seeing
the same problem over and over that there is definitely something wrong.
I spent a g
On Jul 23, 2017 7:05 PM, "Terry Kennedy" wrote:
> It's an SM961, not PM951.
Welcome to the club! 8-{
See PR211723 - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211713
as well as the forums: https://forums.freebsd.org/threads/58170/#post-334061
I (and others) have offered developers
On Thu, Jul 20, 2017 at 03:45:39PM +0200, Mark Martinec wrote:
> 2017-07-20 02:03, Mark Johnston wrote:
> > One thing to try at this point would be to disable EARLY_AP_STARTUP in
> > the kernel config. That is, take a configuration with which you're able
> > to reproduce the hang during boot, and r
On Sun, Jul 23, 2017 at 04:26:45PM +0700, Eugene Grosbein wrote:
> On 14.01.2017 18:40, Eugene Grosbein wrote:
> >
> >> I suspect that this is because we only stop the scheduler upon a panic
> >> if SMP is configured. Can you retest with the patch below applied?
> >>
> >> Index: sys/kern/kern_shut
> It's an SM961, not PM951.
Welcome to the club! 8-{
See PR211723 - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211713
as well as the forums: https://forums.freebsd.org/threads/58170/#post-334061
I (and others) have offered developers remote console access to systems
that exhibit the
Hi Glen,
thanks for the update..
Your work (and the work of others of course) is one of the main reasons why i
use and promote the use of FreeBSD. One of the last truly engineered Operating
Systems.
Thank you for your work, you probably can guess it already, i truly appreciate
it.
I'll stor
Hi Sydney,
The release date in UPDATING actually was a mistake. (I looked at the
wrong month...)
Glen
On Sun, Jul 23, 2017 at 10:23:43PM +0200, Sydney Meyer via freebsd-stable wrote:
> Hi Dimitry,
>
> thank you for your reply.
>
> Please excuse me if i came across impatiently, that was not my
Hi Dimitry,
thank you for your reply.
Please excuse me if i came across impatiently, that was not my intention.
It's just that i find the way the project handles events like these, new
releases, security incidents, etc. very interesting and just generally love to
hear about it.
Glen, e.g., se
On 23.07.2017 20:02, Eugene Grosbein wrote:
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0xa
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0x80e494e1
> stack pointer =
Hi!
Long story short: stable/11 r321371 started to panic at the moment of smartd
invocation
after my SSD died.
I have Intel motherboard with graid-supported pseudo-raid.
I use it in RAID1 mode with one HDD and one SSD.
Yesterday the SSD has died: it is not detected by BIOS nor FreeBSD kernel
(
On 23 Jul 2017, at 14:36, Sydney Meyer via freebsd-stable
wrote:
>
> are there any "last-minute" issues/changes with the 11.1-RELEASE build?
>
> The 11.1-RELEASE appears to be gone from SVN after the switch from
> releng/11.1 to -RELEASE and the Press Release Schedule seems to have changed
>
Hello @re,
are there any "last-minute" issues/changes with the 11.1-RELEASE build?
The 11.1-RELEASE appears to be gone from SVN after the switch from releng/11.1
to -RELEASE and the Press Release Schedule seems to have changed without notice.
Not that this is an issue to me, as the releases are
On 14.01.2017 18:40, Eugene Grosbein wrote:
>
>> I suspect that this is because we only stop the scheduler upon a panic
>> if SMP is configured. Can you retest with the patch below applied?
>>
>> Index: sys/kern/kern_shutdown.c
>> ===
15 matches
Mail list logo
