Hi Garrett,
On Sun, 28 Sep 2014 18:43:45 -0700, Garrett Cooper wrote
[...]
> When I was debugging getting ACPI to work on my netbook, here were
> some other things I did to get the system up and going: - Built a
> stripped down kernel that just contains the essential bits (CPU,
> filesystem, st
It seems that the strptime changes broke the recognition of
/etc/dumpdates. Last night's level 2 dump turned into a level 0:
DUMP: Date of this level 2 dump: Mon Sep 29 00:10:26 2014
DUMP: Unknown intermediate format in /etc/dumpdates, line 1
DUMP: Unknown intermediate format in /etc/dumpdat
On 9/29/2014 at 2:15 AM José Pérez Arauzo wrote:
|This encoded message has been converted to an attachment.
|
|Hi Mike,
|It looks like we are hitting the same problem. If we find a
|third person with the same issue we can fund a club. :)
|Interesting to note:
| 1) we both run FBSD on small netb
> On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote:
>
>> Where can I get that information? Where was it sent? Why am I
>> not allowed to view it?
>>
>
> Sounds to me like the kernel ring buffer is now too small for all the early
> boot messages?
OK more investigation indicates that bumping
kern.msgb
Hi,
while trying the netmap-enabled libpcap library with tcpdump, i
noticed it fails to return data on a kernel with capsicum (the
string "capability mode sandbox enabled" made me suspicious, and
removing the cap_*() calls from tcpdump.c seems to make things
work again).
Would anyone be able to p
On 09/29/2014 10:31, Chris H wrote:
>> On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote:
>>
>>> Where can I get that information? Where was it sent? Why am I
>>> not allowed to view it?
>>>
>>
>> Sounds to me like the kernel ring buffer is now too small for all the early
>> boot messages?
> OK more
On 9/28/2014 at 5:01 PM Steven Hartland wrote:
|The only recent ATAPI change I recall is 270327, does it still occur
|if you revert that?
|
=
I downloaded 11-current via svn, then copied over the pre-270327
version of ata_xpt.c.
make buildworld
make buildkernel
make installkernel
re
On Mon, Sep 29, 2014 at 05:30:43PM +0200, Luigi Rizzo wrote:
>
> Hi,
> while trying the netmap-enabled libpcap library with tcpdump, i
> noticed it fails to return data on a kernel with capsicum (the
> string "capability mode sandbox enabled" made me suspicious, and
> removing the cap_*() calls fr
On Mon, Sep 29, 2014 at 05:27:09PM +, Brooks Davis wrote:
> On Mon, Sep 29, 2014 at 05:30:43PM +0200, Luigi Rizzo wrote:
> >
> > Hi,
> > while trying the netmap-enabled libpcap library with tcpdump, i
> > noticed it fails to return data on a kernel with capsicum (the
> > string "capability mod
> On 09/29/2014 10:31, Chris H wrote:
>>> On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote:
>>>
Where can I get that information? Where was it sent? Why am I
not allowed to view it?
>>>
>>> Sounds to me like the kernel ring buffer is now too small for all the early
>>> boot messages?
On 2014-09-29 14:22, Chris H wrote:
>> On 09/29/2014 10:31, Chris H wrote:
On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote:
> Where can I get that information? Where was it sent? Why am I
> not allowed to view it?
>
Sounds to me like the kernel ring buffer is now too
> On 2014-09-29 14:22, Chris H wrote:
>>> On 09/29/2014 10:31, Chris H wrote:
> On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote:
>
>> Where can I get that information? Where was it sent? Why am I
>> not allowed to view it?
>>
>
> Sounds to me like the kernel ring buffer
On Mon, Sep 29, 2014 at 08:20:08PM +0200, Luigi Rizzo wrote:
> On Mon, Sep 29, 2014 at 05:27:09PM +, Brooks Davis wrote:
> > On Mon, Sep 29, 2014 at 05:30:43PM +0200, Luigi Rizzo wrote:
> > >
> > > Hi,
> > > while trying the netmap-enabled libpcap library with tcpdump, i
> > > noticed it fails
On 9/28/2014 at 5:01 PM Steven Hartland wrote:
|The only recent ATAPI change I recall is 270327, does it still occur
|if you revert that?
|
|Regards
|Steve
=
Another data point. I just downloaded the image:
FreeBSD-10.1-BETA3-i386-disc1
The looping occurs also w
On Mon, Sep 29, 2014 at 06:53:08PM +, Brooks Davis wrote:
> On Mon, Sep 29, 2014 at 08:20:08PM +0200, Luigi Rizzo wrote:
...
> > The nm_open() (which includes open and mmap) occurs before the
> > cap_enter() call, and poll() works fine until we do the
> > cap_enter()/cap_sandboxed() calls.
> >
On 9/28/2014 at 5:01 PM Steven Hartland wrote:
|The only recent ATAPI change I recall is 270327, does it still occur
|if you revert that?
|
|Regards
|Steve
=
Yet another data point (actually two data points). I had an older
STABLE image sitting around.
FreeBSD-10.0
Hi Mike,
On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote
[...]
> So that should put a time bracket on the issue, roughly the first
> half of 2014.
can you boot 271146? Just buildkernel and installkernel. Thank you.
BR,
--
José Pérez Arauzo
___
freebsd
Reminder: the deadline for 2014Q3 status reports is just over a week away!
Thanks,
Ben (on behalf of monthly@)
On Tue, 2 Sep 2014, Ed Maste wrote:
> Dear FreeBSD Community,
>
> The deadline for the next FreeBSD Quarterly Status update is October 7,
> for work done in July through September.
>
>
Hi,
I've added support for QAC AR816x/AR817x ethernet controllers. It
passed my limited testing and I need more testers. You can find
patches from the following URLs.
http://people.freebsd.org/~yongari/alc/pci.quirk.diff
and
http://people.freebsd.org/~yongari/alc/alc.diff.20140930
pci.qurik.dif
So, I've noticed nscd hasn't worked right for awhile now. Since I
upgraded to 10.0 it never seemed to cache properly but I never bothered
to really dig into it until recently and here's what I've found. In my
environment I have nsswitch set to use caching and LDAP as such:
group: files cache ld
I think that currently vt_suspend / vt_resume are called at quite unsuitable
times. For example, vt_suspend performs a vt switch which requires cooperation
from an X server, but that could be problematic given that some devices may
already be suspended.
I believe that it is better to do what sc(4
Hello.
I just made the last update of the ports yesterday (I use portmaster -da
performing this
task) and obviously or superficially everything went all right.
I'm running on the boxes in question most recent CURRENT.
On one system, a subsequent start of updating ports starts to freak out when
On Tue, 30 Sep 2014 08:13+0200, O. Hartmann wrote:
>
> Hello.
>
> I just made the last update of the ports yesterday (I use portmaster -da
> performing this
> task) and obviously or superficially everything went all right.
>
> I'm running on the boxes in question most recent CURRENT.
>
> On o
On Tue, 30 Sep 2014 08:40+0200, Trond Endrestøl wrote:
> On Tue, 30 Sep 2014 08:13+0200, O. Hartmann wrote:
>
> >
> > Hello.
> >
> > I just made the last update of the ports yesterday (I use portmaster -da
> > performing this
> > task) and obviously or superficially everything went all right.
Am Tue, 30 Sep 2014 08:40:19 +0200 (CEST)
Trond Endrestøl schrieb:
> On Tue, 30 Sep 2014 08:13+0200, O. Hartmann wrote:
>
> >
> > Hello.
> >
> > I just made the last update of the ports yesterday (I use portmaster -da
> > performing
> > this task) and obviously or superficially everything wen
25 matches
Mail list logo
