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
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]
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 result is:
2011/11/7 Kostik Belousov kostik...@gmail.com:
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.
On Tue, Nov 15, 2011 at 10:15 AM, Attilio Rao atti...@freebsd.org wrote:
2011/11/7 Kostik Belousov kostik...@gmail.com:
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
2011/11/15 m...@freebsd.org:
On Tue, Nov 15, 2011 at 10:15 AM, Attilio Rao atti...@freebsd.org wrote:
2011/11/7 Kostik Belousov kostik...@gmail.com:
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.
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.
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
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 kostik...@gmail.com
wrote:
Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has
a lot of
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(),
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.
Having
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
On 2011-11-15 18:10:01 (+0100), GR free...@gomor.org 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
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 address
From Kristof Provost kris...@sigsegv.be:
[..]
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
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 node in
On Tue, Nov 15, 2011 at 11:35:37PM +0100, GR wrote:
From Kristof Provost kris...@sigsegv.be:
[..]
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
On 11/15/11, Jeremie Le Hen jere...@le-hen.org 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]
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 added at
19 matches
Mail list logo
