Hello,
On Sun, 06 Jan 2008 23:42:07 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Paul Rolland <[EMAIL PROTECTED]>
> Date: Mon, 7 Jan 2008 08:37:04 +0100
>
> > I remember reading some time ago about a network driver to "simulate"
> > network default, for example packet loss...
> >
From: Paul Rolland <[EMAIL PROTECTED]>
Date: Mon, 7 Jan 2008 08:37:04 +0100
> I remember reading some time ago about a network driver to "simulate"
> network default, for example packet loss...
> Unfortunately, I can't find the post, neither in my mailbox nor in
> archives...
>
> Does anyone has
On Mon, Jan 07, 2008 at 09:13:22AM +0200, Ilpo Järvinen wrote:
>
> There still seems to be good candidates for inline in *.c files, in worst
> case I had +172 due to inline removed and ~60 are on +10-+90 range with
> my gcc, later gccs might do better but I definately would just blindly
> remove
On Sun, 6 Jan 2008 21:03:42 +0100
"Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> On Jan 6, 2008 2:33 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > On Sun, 6 Jan 2008 12:35:35 +0100
> > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > > On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]
On Sat, 5 Jan 2008, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Sun, 06 Jan 2008 11:29:35 +1100
>
> > We should never use inline except when it's on the fast path and this
> > is definitely not a fast path. If a function ends up being called
> > just once the compiler will
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> :
>> Kernel is 2.6.24-rc6 + linuxpps patches, which are all to the serial
>> port driver.
>>
>> 2.6.23 was known stable. I haven't tested earlier 2.6.24 releases.
>> I think it happened once before; I got a black-screen lockup with
>> keyboard LEDs blinking
1) In tty.c the BUG_ON at line 115 will never be called, because the the before
list_del_init in this same function.
115 BUG_ON(!list_empty(&dev->list));
So move the list_del_init to rfcomm_dev_del
2) The rfcomm_dev_del could be called from diffrent path
(rfcomm_tty_hangup/rfcomm_dev_
On Sun, 06 Jan 2008 20:01:40 +, Andy Furniss wrote
> Denys Fedoryshchenko wrote:
> > Hi
> >
> > I took risk and installed ESFQ on my main backbone QoS. I found it highly
> > useful, and very need in setup's where is more than 128 flows passing and
> > especially where is nat available.
>
>
On 2008.01.04 23:26:33 +0100, Björn Steinbrink wrote:
> For cards that initially have the MAC address stored in reverse order,
> the forcedeth driver uses a flag to signal whether the address was
> already corrected, so that it is not reversed again on a subsequent
> probe.
>
> Unfortunately this
On 2008.01.06 19:49:49 -0200, Adolfo R. Brandes wrote:
> I have this forcedeth MAC address reversal problem when suspending
> on 2 distinct boxes. I can confirm Steinbrink's patch fixes the
> problem on only one of them:
>
> 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev f3)
>
From: [EMAIL PROTECTED] (Thomas Bogendoerfer)
Date: Sun, 6 Jan 2008 12:38:16 +0100
> On Sun, Jan 06, 2008 at 12:23:05AM -0800, David Miller wrote:
> > I know that this whole driver is full of assumptions about
> > the endianness of the system this chip is found on, so
> > I'm only interested in if
easy to trigger as user with sfuzz.
irda_create() is quiet on unknown sock->type,
match this behaviour for SOCK_DGRAM unknown protocol
Signed-off-by: maximilian attems <[EMAIL PROTECTED]>
---
net/irda/af_irda.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/irda/af
I have this forcedeth MAC address reversal problem when suspending
on 2 distinct boxes. I can confirm Steinbrink's patch fixes the
problem on only one of them:
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev f3)
On the other one the problem persists:
00:14.0 Bridge: nVidia C
On Sun, Jan 06, 2008 at 09:04:02PM +0100, Ralph Spitzner wrote:
> With Kernel 2.6.23.12 && ath5k I get this:
> --
>
> Jan 6 20:42:44 meepmeep kernel: CPU:0
> Jan 6 20:42:44 meepmeep kernel: EIP:0060:[]Not tainted
> VLI
>
With Kernel 2.6.23.12 && ath5k I get this:
--
Jan 6 20:42:44 meepmeep kernel: CPU:0
Jan 6 20:42:44 meepmeep kernel: EIP:0060:[]Not
tainted VLI
Jan 6 20:42:44 meepmeep kernel: EFLAGS: 00010246 (2.6.23.12 #1)
Jan 6
Denys Fedoryshchenko wrote:
Hi
I took risk and installed ESFQ on my main backbone QoS. I found it highly
useful, and very need in setup's where is more than 128 flows passing and
especially where is nat available.
I agree it will be good when it's in.
Here is results with overloaded class
On Jan 6, 2008 2:33 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Sun, 6 Jan 2008 12:35:35 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > > On Sun, 6 Jan 2008 11:41:10 +0100
> > > "Torsten Kaiser" <[EMAIL PROTECT
Congratulations!!Your email I.D was selected and you have therefore
been awarded the sum of 500,000GBP by the Microsoft Online 2008
promotion. contact the Agent email below for further instrution.
E-mail: [EMAIL PROTECTED]
Thank you.
--
To unsubscribe from this list: send the line "unsubscri
On Sun, Jan 06, 2008 at 11:30:48AM +0100, Torsten Kaiser wrote:
...
> I think this bug is highly timing dependent. Its not always the same
> package that dies and as this is a SMP system I would guess two CPUs
> using the same data will trigger this.
> And using the poison-option will definitily sl
On Sun, 6 Jan 2008 12:35:35 +0100
"Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > On Sun, 6 Jan 2008 11:41:10 +0100
> > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > > I will applie your patch and see if this hunk from
> > > f
On Sun, Jan 06, 2008 at 12:23:05AM -0800, David Miller wrote:
> > + u64 macaddr;
> >
> > - for (i = 0; i < 6; i++)
> > - dev->dev_addr[i] = o2meth_eaddr[i];
> > DPRINTK("Loading MAC Address: %s\n", print_mac(mac, dev->dev_addr));
> > - mace->eth.mac_addr = (*(unsigned long*)o2
On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Sun, 6 Jan 2008 11:41:10 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > I will applie your patch and see if this hunk from
> > find_next_zero_area() makes a difference:
> >
> >end = index + nr;
> > - if
On Sun, 6 Jan 2008 11:41:10 +0100
"Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> On Jan 6, 2008 4:28 AM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > On Sat, 5 Jan 2008 17:25:24 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > On Sat, 5 Jan 2008 23:10:17 +0100 "Torsten Kaiser" <[EMAIL PRO
On Jan 6, 2008 4:28 AM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Sat, 5 Jan 2008 17:25:24 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Sat, 5 Jan 2008 23:10:17 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]>
> > wrote:
> > > But the cause of my mail is the following question:
> > > Re
On Jan 6, 2008 9:27 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On Sat, Jan 05, 2008 at 03:52:32PM +0100, Torsten Kaiser wrote:
> ...
> > So my personal conclusion would be, that someone is writing to memory
> > that he no longer owns. Most probably 0-bytes. (the complete_routine
> > got NULLe
Hi,
The info placeholder member of dst_entry seems to be unused in the
network stack.
Regards,
Rami Rosen
Signed-off-by: Rami Rosen <[EMAIL PROTECTED]>
diff --git a/include/net/dst.h b/include/net/dst.h
index 31468c9..e03ea0c 100644
--- a/include/net/dst.h
+++ b/include/net/ds
On Sat, Jan 05, 2008 at 11:20:33PM -0800, David Miller wrote:
> From: Amos Waterland <[EMAIL PROTECTED]>
> Date: Sat, 5 Jan 2008 22:58:16 -0500
>
> > ADDRESS ASSIGNED
> >
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -append "ip=on"
> > qemu -kernel x86/arch/i386/boot/bzImage /dev/zero -a
On Sat, Jan 05, 2008 at 03:52:32PM +0100, Torsten Kaiser wrote:
...
> So my personal conclusion would be, that someone is writing to memory
> that he no longer owns. Most probably 0-bytes. (the complete_routine
> got NULLed and the warning about dst->__refcnt being 0).
>
> Use-after-free or someth
From: Thomas Bogendoerfer <[EMAIL PROTECTED]>
Date: Sat, 5 Jan 2008 23:48:42 +0100 (CET)
> meth didn't set a valid mac address during probing, but later during
> open. Newer kernel refuse to open device with 00:00:00:00:00:00 as
> mac address -> dead ethernet. This patch sets the mac address in
>
29 matches
Mail list logo
