Quoting "Patrick M. Hausen" :
Hi!
On Fri, Jul 03, 2009 at 05:05:08PM +0200, Dimitry Andric wrote:
E.g. the debug stuff is put into the .symbols files. The kernel itself
still contains the function and data names, though:
Understood. Thanks. No, I don't want the kernel to be void
of any info
Hi Dan,
basically the "size" in df shows the current free space plus the used
space of the specific filesystem. This makes sense: Since per default
all disk space is shared, and thus can be used by all filesystems, all
filesystems need to report it as free space. Well, and used space has
to be add
On Sun, Jul 5, 2009 at 2:26 AM, Freddie Cash wrote:
>
>
> On Sat, Jul 4, 2009 at 2:55 PM, Dan Naumov wrote:
>>
>> Hello list.
>>
>> I have a single 2tb disk used on a 7.2-release/amd64 system with a
>> small part of it given to UFS and most of the disk given to a single
>> "simple" zfs pool with s
On Sat, Jul 4, 2009 at 2:55 PM, Dan Naumov wrote:
> Hello list.
>
> I have a single 2tb disk used on a 7.2-release/amd64 system with a
> small part of it given to UFS and most of the disk given to a single
> "simple" zfs pool with several filesystems without redundancy. I've
> noticed a really we
Hello list.
I have a single 2tb disk used on a 7.2-release/amd64 system with a
small part of it given to UFS and most of the disk given to a single
"simple" zfs pool with several filesystems without redundancy. I've
noticed a really weird thing regarding what "df" reports regarding the
"total spac
This is a message in multipart MIME format. Your mail client should not be
displaying this. Consider upgrading your mail client to view this message
correctly.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freeb
On 12/23/-58 20:59, Ian J Hart wrote:
> Is this likely to be hardware? Details will
> follow if not.
>
> [copied from a screen dump]
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address = 0x0
> fault code = supervisor write data, page not present
>
On Fri, 3 Jul 2009, Ian J Hart wrote:
Is this likely to be hardware? Details will follow if not.
This looks like a kernel NULL pointer deference (faulting address 0x0), which
means it is most likely a kernel bug, although it could be triggered by a
hardare problem. If this early in the boo
Dear all
The issue was solved. It was a our side mistake. On a modification we
made to libutils, we execute following line without checking whether
the group is empty or not. In our case, it was empty, therefore,
crashes:
running = strdup(*(grp->gr_mem));
So that now login, su
