Looking at how selrecord() / selwakeup() and their Linux counterparts
poll_wait() and wake_up() are used, i noticed the following:
- linux tends to call wake_up() unconditionally
at the beginning of the poll handler
- FreeBSD tends to call selrecord() only when it detects a blocking
situation
On Tue, Jan 21, 2014 at 10:47 AM, Andriy Gapon wrote:
> on 21/01/2014 13:18 Andrey V. Elsukov said the following:
> > On 21.01.2014 14:45, Andriy Gapon wrote:
> What do I need to do to get the boot2 code written to /dev/ada0s1a?
> >>>
> >>> This will work only if ada0s1a isn't in use. The de
On Tue, Jan 21, 2014 at 8:49 AM, John Baldwin wrote:
> On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote:
> >
> > On 21 Jan 2014, at 07:13, Antonio Olivares
> wrote:
> >
> > > On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras
> wrote:
> > >> Hi,
> > >>
> > >> Is there any way I can avoid
On Tue, Jan 21, 2014 at 12:37 PM, Outback Dingo wrote:
>
>
>
> On Thu, Dec 19, 2013 at 6:32 PM, wrote:
>>
>> On Wed, Dec 18, 2013 at 2:40 PM, Outback Dingo
>> wrote:
>> >
>> >
>> >
>> > On Wed, Dec 18, 2013 at 4:40 PM, Alan Somers
>> > wrote:
>> >>
>> >> On Wed, Dec 18, 2013 at 11:47 AM, Outbac
On Thu, Dec 19, 2013 at 6:32 PM, wrote:
> On Wed, Dec 18, 2013 at 2:40 PM, Outback Dingo
> wrote:
> >
> >
> >
> > On Wed, Dec 18, 2013 at 4:40 PM, Alan Somers
> wrote:
> >>
> >> On Wed, Dec 18, 2013 at 11:47 AM, Outback Dingo >
> >> wrote:
> >> >
> >> >
> >> > On Wed, Dec 18, 2013 at 12:39 PM,
On Tuesday, December 24, 2013 6:20:53 am Roger Pau Monne wrote:
> This allows Dom0 to manage physical hardware, redirecting the
> physical interrupts to event channels.
> ---
> sys/x86/xen/xen_intr.c | 190
+--
> sys/xen/xen_intr.h | 11 +++
> 2
On Tuesday, December 24, 2013 6:20:55 am Roger Pau Monne wrote:
> Minor fixes and workarounds to make the Xen Dom0 console work.
Looks ok to me.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/free
On Tuesday, December 24, 2013 6:20:50 am Roger Pau Monne wrote:
> We need to do some tweaking of the hardware e820 map, since the memory
> layout provided by Xen and the e820 map doesn't match.
>
> This consists in clamping the e820 map so that regions above max_pfn
> are marked as unusuable.
> --
On Tuesday, December 24, 2013 6:20:51 am Roger Pau Monne wrote:
> Create some hooks for IO APIC operations that will diverge from bare
> metal when implemented for Xen Dom0.
>
> This patch should not introduce any changes in functionality, it's a
> preparatory patch for the implementation of the X
On Tuesday, December 24, 2013 6:20:54 am Roger Pau Monne wrote:
> Implement a different set of hooks for IO APIC to use when running
> under Xen Dom0.
> ---
> sys/x86/xen/pv.c | 44
> 1 files changed, 44 insertions(+), 0 deletions(-)
>
> diff --git a
On Wednesday, January 15, 2014 6:47:36 pm Aleksandr Rybalko wrote:
> On Wed, 15 Jan 2014 23:35:39 +
> Ed Schouten wrote:
>
> > Hello there,
> >
> > On Wed Jan 15 2014 at 1:43:56 PM, Aleksandr Rybalko
> > wrote:
> >
> > > I've just committed update to xboxfb driver for vt(9). But I have
> >
On Wednesday, January 15, 2014 6:34:30 am Gleb Smirnoff wrote:
> Damn, what a mess. I'd like to go towards absolutely unmodified packets
> for the 11-release cycle.
I agree.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.free
On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote:
>
> On 21 Jan 2014, at 07:13, Antonio Olivares wrote:
>
> > On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras wrote:
> >> Hi,
> >>
> >> Is there any way I can avoid manually resolving hundreds of merge
> >> conflicts of the following typ
on 21/01/2014 13:18 Andrey V. Elsukov said the following:
> On 21.01.2014 14:45, Andriy Gapon wrote:
What do I need to do to get the boot2 code written to /dev/ada0s1a?
>>>
>>> This will work only if ada0s1a isn't in use. The debugflags trick works
>>> only for whole disk, i.e. for geoms with
On 21 Jan 2014, at 07:13, Antonio Olivares wrote:
> On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras wrote:
>> Hi,
>>
>> Is there any way I can avoid manually resolving hundreds of merge
>> conflicts of the following type while using freebsd-update ?
>>
>> 1 <<< current version
>>
>>
>> 2
On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras wrote:
> Hi,
>
> Is there any way I can avoid manually resolving hundreds of merge
> conflicts of the following type while using freebsd-update ?
>
> 1 <<< current version
>
>
> 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z
Hi,
Is there any way I can avoid manually resolving hundreds of merge
conflicts of the following type while using freebsd-update ?
1 <<< current version
2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z
peter $
3 ===
4 # $FreeBSD: release/10.0.0/etc/csh.csh
On Sun, Jan 19, 2014 at 02:42:32AM +0100, Olivier Cochard-Labbé wrote:
O> > Olivier,
O> >
O> >
O> > TL;DR version: you need not subtract iphdrlen in 10.0. Code in
O> > igmp.c:accept_igmp()
O> > should be smth like:
O> >
O> > iphdrlen = ip->ip_hl << 2;
O> > #ifdef RAW_INPUT_IS_RAW /* Linux */
On 21.01.2014 14:45, Andriy Gapon wrote:
>>> What do I need to do to get the boot2 code written to /dev/ada0s1a?
>>
>> This will work only if ada0s1a isn't in use. The debugflags trick works
>> only for whole disk, i.e. for geoms with rank=1. Another way is
>> calculate needed offset and write boot
on 21/01/2014 11:35 Andrey V. Elsukov said the following:
> On 20.01.2014 23:32, Thomas Hoffmann wrote:
>> I am running 11.0-CURRENT (r260850) with zfs on root with MBR.
>>
>> After upgrading my 10.0-RELEASE (r260669) system to 11.0-CURRENT (r260850)
>> my zpools reported that they needed to be upg
On 20.01.2014 23:32, Thomas Hoffmann wrote:
> I am running 11.0-CURRENT (r260850) with zfs on root with MBR.
>
> After upgrading my 10.0-RELEASE (r260669) system to 11.0-CURRENT (r260850)
> my zpools reported that they needed to be upgraded. So, I upgraded my
> zpools and I am attempting to update
Last follow-up: I just saw that there are some additional messages (errors?) on
the serial console when changing the device from IB to Ethernet, maybe they
mean something to someone:
root@one:~ # sysctl sys.device.mlx4_core0.mlx4_port1=eth
sys.device.mlx4_core0.mlx4_port1: auto (ib)<7>ib0: stopp
On 2014-1-21, at 10:04, Lars Eggert wrote:
> See the attached dmesg
which I of course forget to attach (sigh). See below.
Lars
GDB: no debug ports present970
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2014 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986,
Hi,
On 2014-1-20, at 21:59, John Baldwin wrote:
> I believe this should work, yes. Getting a crashdump or the panic messages
> would be really helpful in figuring out why it isn't. Thanks.
I rebuilt the kernel, and see no crashes anymore. So that's good.
But there are a bunch of other issues
24 matches
Mail list logo
