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
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
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
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 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/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
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
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
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, 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 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 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 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 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
>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 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
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 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
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
19 matches
Mail list logo
