On Mon, 26 Feb 2007 23:07:47 +0300, Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
> Yeah, tc35815_1.c in our looks like the one in the CELF archive (what I
> didn't get is why they decided to keep both drivers around?)
I think tc35815_1.c can just replace old tc35815.c. New one lacks
tc35815_ki
Hello.
Atsushi Nemoto wrote:
I know both MontaVista and CELF have new driver for the chip. If
anybody in MontaVista did not complain I can send CELF's one available
at http://tree.celinuxforum.org/pubwiki/moin.cgi/PatchArchive. (it
Yeah, tc35815_1.c in our looks like the one in the CELF
On Mon, 26 Feb 2007 10:26:59 +, Ralf Baechle <[EMAIL PROTECTED]> wrote:
> > I created my own patch for this (and one other bug), and checked it in.
> >
> > Really, though, someone in MIPS-land should give this driver some loving
> > care. It is filled with bugs and 2.4-era anachronisms.
>
>
On Sat, Feb 24, 2007 at 05:04:01PM -0500, Jeff Garzik wrote:
> >>I am a graduate student working on finding bugs in Linux drivers using
> >>an automated research tool. I think I've found a possible bug in
> >>net/tc35815.c, and I'd appreciate it if you could confirm/disconfirm it.
> >>
> >>Thanks
Michal Piotrowski wrote:
Hi Philip,
Philip Guo napisał(a):
Hi,
I am a graduate student working on finding bugs in Linux drivers using
an automated research tool. I think I've found a possible bug in
net/tc35815.c, and I'd appreciate it if you could confirm/disconfirm it.
Thanks,
Philip
---
Hi Philip,
Philip Guo napisał(a):
> Hi,
>
> I am a graduate student working on finding bugs in Linux drivers using
> an automated research tool. I think I've found a possible bug in
> net/tc35815.c, and I'd appreciate it if you could confirm/disconfirm it.
>
> Thanks,
> Philip
>
> ---
> net/tc
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Thu, 25 Jan 2007 16:22:20 +0300
> Actually, it can. Return value was used only as sign of error,
> so that the mistake was to return original unsigned result casted to int.
>
> Alternative fix is enclosed. To be honest, it is not better than
> your
Hello!
> So this whole idea to make run_filter() return signed integers
> and fail on negative is entirely flawed, it simply cannot work
> and retain the expected semantics which have been there forever.
Actually, it can. Return value was used only as sign of error,
so that the mistake was to ret
From: Raivis Bucis <[EMAIL PROTECTED]>
Date: Thu, 4 Jan 2007 17:47:46 +0200
> I believe I have found a bug in PF_PACKET socket filtering
> (introduced in linux-2.6.19). If BPF returns values larger than
> 0x8000u, run_filter in af_packet.c considers that as error
> instead o
ongly recommended by
the TCP-Hybla authors in order to mitigate congestion episodes and limit
the initial cwnd overshoot phenomenon respectively.
A new version for linux-2.6.19 has been released at
http://www.sf.net/projects/multitcp/
Hybla's authors future goal would be to produce official patche
Hello,
I believe I have found a bug in PF_PACKET socket filtering (introduced in
linux-2.6.19). If BPF returns values larger than 0x8000u, run_filter in
af_packet.c considers that as error instead of simply accepting packet in its
full length. sk_filter does not have this problem.
Raivis
On Mon, 11 Dec 2006 10:43:31 +0100 Toralf Förster wrote:
>
> Hello,
>
> the build with the attached .config failed, make ends with:
> ...
> LD drivers/media/dvb/bt8xx/built-in.o
> LD drivers/media/dvb/cinergyT2/built-in.o
> LD drivers/media/dvb/dvb-core/built-in.o
> LD
On Thursday 30 November 2006 03:15, David Miller wrote:
> From: Phil Oester <[EMAIL PROTECTED]>
> Date: Wed, 29 Nov 2006 17:49:04 -0800
>
> > Getting an oops on boot here, caused by commit
> > e81c73596704793e73e6dbb478f41686f15a4b34 titled
> > "[NET]: Fix MAX_HEADER setting".
> >
> > Reverting tha
On Wed, Nov 29, 2006 at 06:15:37PM -0800, David Miller wrote:
> In fact it does, the NDISC code is using MAX_HEADER incorrectly. It
> needs to explicitly allocate space for the struct ipv6hdr in 'len'.
> Luckily the TCP ipv6 code was doing it right.
>
> What a horrible bug, this patch should fix
From: Phil Oester <[EMAIL PROTECTED]>
Date: Wed, 29 Nov 2006 17:49:04 -0800
> Getting an oops on boot here, caused by commit
> e81c73596704793e73e6dbb478f41686f15a4b34 titled
> "[NET]: Fix MAX_HEADER setting".
>
> Reverting that patch fixes things up for me. Dave?
I suspect that it might be bec
On Sunday 05 November 2006 7:45 pm, David Miller wrote:
> From: Paul Moore <[EMAIL PROTECTED]>
> Date: Sun, 5 Nov 2006 16:24:07 -0500 (EST)
>
> > On Sun, 5 Nov 2006, Toralf Förster wrote:
> > > Hello,
> > >
> > > the build with the attached .config failed, make ends with:
> > > ...
> > >
> > > : un
From: Paul Moore <[EMAIL PROTECTED]>
Date: Sun, 5 Nov 2006 16:24:07 -0500 (EST)
> On Sun, 5 Nov 2006, Toralf Förster wrote:
> >
> > Hello,
> >
> > the build with the attached .config failed, make ends with:
> > ...
> > : undefined reference to `cipso_v4_sock_getattr'
> > net/built-in.o: In functio
On Sun, 5 Nov 2006, Toralf F?rster wrote:
Hello,
the build with the attached .config failed, make ends with:
...
: undefined reference to `cipso_v4_sock_getattr'
net/built-in.o: In function `netlbl_socket_getattr':
Ah ha! Why did you have to go and build a kernel without TCP/IP
networking ;)
On Sunday 05 November 2006 1:43 pm, Toralf Förster wrote:
> Hello,
>
> the build with the attached .config failed, make ends with:
> ...
>
> : undefined reference to `cipso_v4_sock_getattr'
Hmm, that's both strange and not good :( I'm grabbing Linus' latests bits and
I'll see what I can do.
--
On Tue, 31 Oct 2006 17:02:09 + Athanasius wrote:
> On Mon, Oct 30, 2006 at 08:27:17PM -0800, Linus Torvalds wrote:
> > Before I forget, I'd like to thank Adrian Bunk for his regressions
> > listings, and ask people who are involved with those (both on the blamer
> > and blamee sides) to foll
On Mon, Oct 30, 2006 at 08:27:17PM -0800, Linus Torvalds wrote:
> Before I forget, I'd like to thank Adrian Bunk for his regressions
> listings, and ask people who are involved with those (both on the blamer
> and blamee sides) to follow them, and keep making sure that we get them
> resolved - i
Hello,
the build with the attached .config failed, make ends with:
...
LD arch/i386/boot/compressed/vmlinux
OBJCOPY arch/i386/boot/vmlinux.bin
HOSTCC arch/i386/boot/tools/build
BUILD arch/i386/boot/bzImage
Root device is (3, 8)
Boot sector 512 bytes.
Setup is 4714 bytes.
System is
From: Randy Dunlap <[EMAIL PROTECTED]>
com20020.c needs to export functions if either of the ISA or PCI
modules are built as loadable modules. Or they could always be
exported.
WARNING: "com20020_found" [drivers/net/arcnet/com20020-pci.ko] undefined!
WARNING: "com20020_check" [drivers/net/arcnet
23 matches
Mail list logo
