On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze
wrote:
> Trond Endrestøl wrote:
>
> > I guess we who live outside the US should take into account that PCs
> > are initialised by firmware to the US keyboard layout and the 437 code
> > page, courtesy of IBM, 1981.
>
> In 1981 I had accepted this.
On Thursday, December 03, 2015 07:16:45 PM Joe Maloney wrote:
> It works! Would it be helpful if I did a pull request from github, or just
> let you guys take it from here? Thanks for helping me figure out how to get
> up, and running! This will be so much better than the framebuffer driver I
Well, this seems to be either hardware or software (driver code) bug.
After `usbconfig -d ugen1.4 reset` webcamd restarting sometimes creates the
device /dev/video0 -- sometimes,, but not every time. More often than not it
doesn't. So there's no method seen in this behaviour so far. I wonder how
Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 04:09:17PM +0100, Fabian Keil wrote:
> > Thanks. I'm currently testing the patch on three systems but it may take a
> > while ...
> >
>
> Better use mjg' patch with the small adjustment. I put it below.
Will do.
Fabian
pgpARhuAh6qDb.p
On 16 Dec, Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
>> Konstantin Belousov wrote:
>> > It is the values of *p and *(p->p_pgrp) that are needed, from the frame 8.
>>
>> Unfortunately it's not available and apparently I removed the attempts
>> to get
On Wed, Dec 16, 2015 at 11:00:19AM +0100, Willem Jan Withagen wrote:
> On 14-12-2015 16:35, Brad Davis wrote:
> > On Mon, Dec 14, 2015 at 06:03:25AM -0700, Warner Losh wrote:
> >> On Mon, Dec 14, 2015 at 2:21 AM, Ronald Klop wrote:
> >>
> >>> On Mon, 14 Dec 2015 10:11:35 +0100, Ronald Klop
> >>>
> On 14.12.2015 г., at 17:35, Brad Davis wrote:
>
>
> Or just use pkg-static. :)
>
I always wondered, why pkg is not static ONLY. That eliminates the chicken/egg
dilemma.
Yes, you eliminate the friendly reminder that your system is out of sync with
the FreeBSD package building platforms,
Trond Endrestøl wrote:
> I guess we who live outside the US should take into account that PCs
> are initialised by firmware to the US keyboard layout and the 437 code
> page, courtesy of IBM, 1981.
In 1981 I had accepted this. Now it's simply a bug and I wonder it has not
been fixed in 22 ye
On Wed, Dec 16, 2015 at 04:09:17PM +0100, Fabian Keil wrote:
> Thanks. I'm currently testing the patch on three systems but it may take a
> while ...
>
Better use mjg' patch with the small adjustment. I put it below.
diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c
index 435a07b..fc392
Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
> > Konstantin Belousov wrote:
> > > It is the values of *p and *(p->p_pgrp) that are needed, from the frame
> > > 8.
> >
> > Unfortunately it's not available and apparently I removed the attempts
> >
Oliver Pinter wrote:
> Yes, it's a HardenedBSD commit. Currently only a workaround, because I have
> now lesser time for the real fix in this month.
>
> Are you running on ZFS?
Yes.
Fabian
pgpuOBy_BlV8u.pgp
Description: OpenPGP digital signature
On Wed, 16 Dec 2015 11:04+0100, Carsten Kunze wrote:
> Hello,
>
> according to the boot messages the keymap is set after decryption of
> file systems. I consider this as a bug. The geli decryption script
> asks for the passphrase which can't of course be input if the kaymap
> is not set.
>
Hello,
according to the boot messages the keymap is set after decryption of file
systems. I consider this as a bug. The geli decryption script asks for the
passphrase which can't of course be input if the kaymap is not set.
Handbook §17.12 does not mention the keymap setup. What can I do to
Hello,
disk decryption works for me when I put
kbdcontrol -l /usr/share/syscons/keymaps/german.iso.kbd
into /etc/rc.d/geli.
But do the keymaps need to be in a file system which may be mounted delayed?
If there is an error at boot time and something needs to be input to the
console the keyboa
On Wed, Dec 16, 2015 at 02:54:27PM +0100, Mateusz Guzik wrote:
> While I agree with analysis the patch does not look right. Since the
> struct is only assigned and all locks get dropped, there is nothing
> preventing another thread from the forking process to change the process
> group.
>
> Intere
Hi!
Is this with latest 11-CURRENT or 10-STABLE?
Or contains the ad578c311ef commit?
On Tuesday, December 15, 2015, Shawn Webb
wrote:
> On Tue, Dec 15, 2015 at 05:42:38PM +0100, Fabian Keil wrote:
> > I've seen the following panic a couple of times in the last three
> > months, usually while p
Hello Simon,
> > .SUFFIXES:
> > .SUFFIXES: .roff .in .ps .mom .pdf .me .ms .ps .html .txt .texi .dvi .pdf
> .xhtml .man .c .cpp .log .o .obj .sed .sin .test .test$(EXEEXT) .trs .ypp
>
> What is the value of EXEEXT at this point?
You are right, the example is not as small as it could be for repr
On Wed, Dec 16, 2015 at 02:10:00PM +0200, Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
> > Konstantin Belousov wrote:
> > > It is the values of *p and *(p->p_pgrp) that are needed, from the frame 8.
> >
> > Unfortunately it's not available and apparent
Yes, it's a HardenedBSD commit. Currently only a workaround, because I have
now lesser time for the real fix in this month.
Are you running on ZFS?
On Wednesday, December 16, 2015, Fabian Keil
wrote:
> Oliver Pinter > wrote:
>
> > Is this with latest 11-CURRENT or 10-STABLE?
> >
> > Or contains
On 14-12-2015 16:35, Brad Davis wrote:
> On Mon, Dec 14, 2015 at 06:03:25AM -0700, Warner Losh wrote:
>> On Mon, Dec 14, 2015 at 2:21 AM, Ronald Klop wrote:
>>
>>> On Mon, 14 Dec 2015 10:11:35 +0100, Ronald Klop
>>> wrote:
>>>
>>> On Mon, 14 Dec 2015 08:18:40 +0100, Matthias Apitz
wrote:
>>
Oliver Pinter wrote:
> Is this with latest 11-CURRENT or 10-STABLE?
>
> Or contains the ad578c311ef commit?
The panic is from a system based on 11-CURRENT r290926.
Is ad578c311ef a HardenedBSD commit? It doesn't seem to
exist in https://github.com/freebsd/freebsd.git.
Fabian
pgpHRlok72ddQ.p
On Tue, Dec 15, 2015 at 05:42:38PM +0100, Fabian Keil wrote:
> I've seen the following panic a couple of times in the last three
> months, usually while poudriere was running and with sh being the
> current process.
>
> This one is from a system based on r290926 running with
> kern.randompid=9001
On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
> Konstantin Belousov wrote:
> > It is the values of *p and *(p->p_pgrp) that are needed, from the frame 8.
>
> Unfortunately it's not available and apparently I removed the attempts
> to get it from the previous output.
> allproc is a
Konstantin Belousov wrote:
> On Tue, Dec 15, 2015 at 05:42:38PM +0100, Fabian Keil wrote:
> > I've seen the following panic a couple of times in the last three
> > months, usually while poudriere was running and with sh being the
> > current process.
> >
> > This one is from a system based on r2
24 matches
Mail list logo
