Am 15.11.2011 um 23:35 schrieb GR:
> So, I switched to static assignement and it changes the behaviour (and
> "fixes" the "bug").
> My guess is that during the time waiting for the DHCP offer, all aliases are
> already configured on the network interface, and the IP address given by DHCP
> is a
On 11/15/11, Jeremie Le Hen wrote:
> Hi,
>
> On Wed, Oct 19, 2011 at 12:37:44AM +0200, Oliver Pinter wrote:
>> In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X
>> (~nxstack), mprotect restriction, veriexec, mmap randomization[2]...)
>>
>> [0] http://pax.grsecurity.net/docs/index.htm
On Tue, Nov 15, 2011 at 11:35:37PM +0100, GR wrote:
> >From "Kristof Provost" :
> [..]
> > The 'ia' pointer is later used to return the IP address.
> >
> > In other words: it returns the first address on the interface
> > of type IF_INET (which isn't assigned to a jail).
> >
> > I think the order
On Tue, Nov 15, 2011 at 12:46:41PM -0500, John Baldwin wrote:
[...]
> and
> > 10 remove that block :
> > http://people.freebsd.org/~bapt/workaround-to-boot-p5ne.diff
>
> Yeah, the problem is that NVIDIA chipsets seem to have really odd behavior in
> that once you turn MSI mapping on for a given n
>From "Kristof Provost" :
[..]
> The 'ia' pointer is later used to return the IP address.
>
> In other words: it returns the first address on the interface
> of type IF_INET (which isn't assigned to a jail).
>
> I think the order of the addresses is not fixed, or rather it depends
> on
> the orde
On (15/11/2011 18:10), GR wrote:
> Hello list,
>
> more insights since my last post. Here is a small code to trigger the bug
> (end of email).
> When you run it on 9.0-RC1, it gets an alias address instead of the main inet
> address:
>
> % ./get-ip re0
> inet: 192.168.2.10
> # Main ad
On 2011-11-15 18:10:01 (+0100), GR wrote:
> more insights since my last post. Here is a small code to trigger the bug
> (end of email).
> When you run it on 9.0-RC1, it gets an alias address instead of the main inet
> address:
>
> % ./get-ip re0
> inet: 192.168.2.10
> # Main address b
On 15.11.2011 22:54, Marcus von Appen wrote:
On, Tue Nov 15, 2011, Alexander Motin wrote:
On 15.11.2011 21:29, Marcus von Appen wrote:
I wonder, if I am correct with my assumption that the usb_ctl_report*
structures mentioned in uhid(4) have to be defined and created by the
code portion that u
On Tuesday 15 November 2011 21:54:06 Marcus von Appen wrote:
> struct usb_ctl_report {
> int ucr_report;
> u_char ucr_data[1024];
> };
Hi,
Before the descriptor length was limited to 1024 bytes.
Now it is limited to 65535 bytes, which is the USB maximum for control
endpoints.
Havi
On, Tue Nov 15, 2011, Alexander Motin wrote:
> On 15.11.2011 21:29, Marcus von Appen wrote:
> > I wonder, if I am correct with my assumption that the usb_ctl_report*
> > structures mentioned in uhid(4) have to be defined and created by the
> > code portion that uses the USB_GET_REPORT(), USB_SET_R
On Sunday, November 06, 2011 11:42:04 am Kostik Belousov wrote:
> On Sun, Nov 06, 2011 at 07:22:51AM -0800, m...@freebsd.org wrote:
> > On Sun, Nov 6, 2011 at 4:43 AM, Kostik Belousov
wrote:
> > > Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has
> > > a lot of violations in
On 15.11.2011 21:29, Marcus von Appen wrote:
I wonder, if I am correct with my assumption that the usb_ctl_report*
structures mentioned in uhid(4) have to be defined and created by the
code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(),
... calls.
In FreeBSD< 800063 we defined them i
Hi,
I wonder, if I am correct with my assumption that the usb_ctl_report*
structures mentioned in uhid(4) have to be defined and created by the
code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(),
... calls.
In FreeBSD < 800063 we defined them in the header files of the USB
subsystem. A
2011/11/15 :
> On Tue, Nov 15, 2011 at 10:15 AM, Attilio Rao wrote:
>> 2011/11/7 Kostik Belousov :
>>> On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote:
Ok. I'll offer one final suggestion. Please consider an alternative
suffix to "func". Perhaps, "kbi" or "KBI". In other wo
On Tue, Nov 15, 2011 at 10:15 AM, Attilio Rao wrote:
> 2011/11/7 Kostik Belousov :
>> On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote:
>>> Ok. I'll offer one final suggestion. Please consider an alternative
>>> suffix to "func". Perhaps, "kbi" or "KBI". In other words, something
>>> t
2011/11/7 Kostik Belousov :
> On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote:
>> Ok. I'll offer one final suggestion. Please consider an alternative
>> suffix to "func". Perhaps, "kbi" or "KBI". In other words, something
>> that hints at the function's reason for existing.
>
> Sure. B
On Friday, November 11, 2011 5:59:07 pm Baptiste Daroussin wrote:
> On Fri, Nov 11, 2011 at 11:10:58PM +0100, Baptiste Daroussin wrote:
> > On Thu, Sep 29, 2011 at 12:22:54AM +0200, Baptiste Daroussin wrote:
> > > On Sun, Sep 11, 2011 at 10:39:38PM +0200, Baptiste Daroussin wrote:
> > > > > > the r
Hi,
On Wed, Oct 19, 2011 at 12:37:44AM +0200, Oliver Pinter wrote:
> In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X
> (~nxstack), mprotect restriction, veriexec, mmap randomization[2]...)
>
> [0] http://pax.grsecurity.net/docs/index.html
> [1] http://www.netbsd.org/~elad/recent/m
Hello list,
more insights since my last post. Here is a small code to trigger the bug (end
of email).
When you run it on 9.0-RC1, it gets an alias address instead of the main inet
address:
% ./get-ip re0
inet: 192.168.2.10
# Main address being 192.168.1.148
On 8.2-RELEASE, all goes w
19 matches
Mail list logo
