On 21/02/2013, at 19:33, "Steven Hartland" wrote:
>> I had a quick look at the code and AFAIK it doesn't do anything (on 9.1
>> anyway).
>> Actually at a guess I would say it's a hangover from sio(4) where 0x20
>> forced the
>> device in question to be the console.
>
> According to the handboo
- Original Message -
From: "Daniel O'Connor"
On 21/02/2013, at 9:06, "Steven Hartland" wrote:
If I change the console redirect to com1, my screen stays blank. Would
you perhaps know how to use com1 for redirect and connect to it using
ipmi-console (or ipmi-tool)?
We use the followin
Hello,
I've noticed that getpeereid/LOCAL_PEERCRED doesn't work with sockets
created through socketpair, but only through actual listen/connect calls.
I notice that in unp_connect, we stash the peercred of the thread, then
call on to unp_connect2. In kern_socketpair, we call straight through to
u
On Thu, Feb 21, 2013 at 12:57:45AM +0200, Damjan Jovanovic wrote:
> On Wed, Feb 20, 2013 at 10:51 PM, Tijl Coosemans wrote:
> > On 20-02-2013 16:48, Konstantin Belousov wrote:
> >> On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote:
> >>> Hi
> >>>
> >>> Wine needs some of its librari
anyone have tested method on doing this?
tried blocking port 5938 as well as teamviewer.com domain in squid (and
all port 80 traffic is already forwarded to squid).
Still doesn't work.
thanks for any help.
___
freebsd-hackers@freebsd.org mailing lis
On 21 Feb 2013 16:22, "Wojciech Puchar"
wrote:
>
> anyone have tested method on doing this?
>
> tried blocking port 5938 as well as teamviewer.com domain in squid (and
all port 80 traffic is already forwarded to squid).
>
> Still doesn't work.
>
> thanks for any help.
You would have better luck o
All
I am looking into an issue with timecounter hardware on a number of HP
DL165 G7's
They all run FreeBSD 9.1-RELEASE and all have the same CPU and firmware.
However they report strange results when you probe kern.timecounter.choice
and
kern.timecounter.hardware
Take this example
ssh root@ss
El día Thursday, February 21, 2013 a las 05:22:02PM +0100, Wojciech Puchar
escribió:
> anyone have tested method on doing this?
>
> tried blocking port 5938 as well as teamviewer.com domain in squid (and
> all port 80 traffic is already forwarded to squid).
>
> Still doesn't work.
What the h.
All
So Xin's patch works so far I see no unexpected issues; can I get a MFC ?
Also on a unrelated MFC request would someone be willing to merge
stable/7/sys/netinet/tcp_input.cr246999 into 6-STABLE . This cleanly
applied and I saw no issues.
On Wed, Feb 20, 2013 at 6:18 PM, Adrian Chadd wr
sorry for polluting a list. i've got somewhat worried about general human
stupidity.
On Thu, 21 Feb 2013, Chris Rees wrote:
On 21 Feb 2013 16:22, "Wojciech Puchar" wrote:
>
> anyone have tested method on doing this?
>
> tried blocking port 5938 as well as teamviewer.com domain in squid (and
On Thu, Feb 21, 2013 at 01:53:44PM -0500, Mark Saad wrote:
> All
> So Xin's patch works so far I see no unexpected issues; can I get a MFC ?
> Also on a unrelated MFC request would someone be willing to merge
> stable/7/sys/netinet/tcp_input.cr246999 into 6-STABLE . This cleanly
> applied and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/21/13 10:53, Mark Saad wrote:
> All So Xin's patch works so far I see no unexpected issues; can I
> get a MFC ? Also on a unrelated MFC request would someone be
> willing to merge stable/7/sys/netinet/tcp_input.cr246999 into
> 6-STABLE . Th
Hi Damjan,
On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote:
>
> Wine needs some of its libraries to be loaded at specific base
> addresses (https://wiki.freebsd.org/Wine), something FreeBSD currently
> lacks.
>
> I've written a patch to the dynamic loader (/libexec/ld-elf.so.1)
On Thu, Feb 21, 2013 at 01:53:44PM -0500, Mark Saad wrote:
> All
> So Xin's patch works so far I see no unexpected issues; can I get a MFC ?
> Also on a unrelated MFC request would someone be willing to merge
> stable/7/sys/netinet/tcp_input.cr246999 into 6-STABLE . This cleanly
> applied and
I recently saw an issue where all interrupts from a particular interrupt
vector were never raised. After investigating it appears that I ran into
the bug fixed in r239095[1], where an interrupt handler that uses an
ithread was added to the list of interrupt handlers for a particular event
before t
On 21-02-2013 16:44, Konstantin Belousov wrote:
> On Thu, Feb 21, 2013 at 12:57:45AM +0200, Damjan Jovanovic wrote:
>> On Wed, Feb 20, 2013 at 10:51 PM, Tijl Coosemans wrote:
>>> On 20-02-2013 16:48, Konstantin Belousov wrote:
On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jovanovic wrote:
On Thu, Feb 21, 2013 at 5:44 PM, Konstantin Belousov
wrote:
> On Thu, Feb 21, 2013 at 12:57:45AM +0200, Damjan Jovanovic wrote:
>> On Wed, Feb 20, 2013 at 10:51 PM, Tijl Coosemans wrote:
>> > On 20-02-2013 16:48, Konstantin Belousov wrote:
>> >> On Wed, Feb 20, 2013 at 05:29:01PM +0200, Damjan Jo
17 matches
Mail list logo