FYI, the reporter was mistaken, the upstream bug was NOT public. He
could see it because he reported it. It might as well be now. (I just
removed the security flag from it, so it is indeed public now).
The patch he supplied (while a good start) was stated to be untested,
and we also determi
Moritz Muehlenhoff wrote on 12/27/05 8:30 PM:
this has been assigned CVE-2005-4534 by MITRE. Please refer to it
in the 2.16.11 release notes.
Thanks! I'm not getting any traction on trying to push a full release
out for this. Seems nobody cares about the 2.16 branch anymore (it's
two stabl
Upstream security advisory for this issue has been posted at
http://www.bugzilla.org/security/2.16.10-nr/
--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System
I think the reporter's interpreation of the assembler
code is incorrect.
If the branch to ".LL9" is taken, the load which initializes
"%g3" is executed.
The annulment of the load only occurs if the branch is not taken,
and for this snippet of code when the branch is not taken the
".LL9" label is
This was fixed incorrectly, and causes regressions. The sparcv9
optimized assembler routines are no longer enabled, amongst other
things. The change should be flat out reverted.
The error message originally reported in the build was due to a
bug in Sparc binutils, it wasn't turning on multiply
From: Kurt Roeckx
Date: Sun, 9 Sep 2012 08:42:46 +0200
> severity 649841 important
> thanks
>
> On Sun, Sep 09, 2012 at 01:55:38AM +0100, David Miller wrote:
>>
>> This was fixed incorrectly, and causes regressions. The sparcv9
>> optimized assembler routines
From: Kurt Roeckx
Date: Mon, 10 Sep 2012 21:30:56 +0200
> On Sun, Sep 09, 2012 at 01:55:38AM +0100, David Miller wrote:
>>
>> This was fixed incorrectly, and causes regressions. The sparcv9
>> optimized assembler routines are no longer enabled, amongst other
>> th
From: Hermann Lauer
Date: Mon, 1 Mar 2010 12:30:05 +0100
> What can be done to debug this further ?
Nothing really, I just simply have no time to look into it
with all the other things on my plate, sorry.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
From: Ben Hutchings
Date: Thu, 04 Mar 2010 14:59:20 +
> On Thu, 2010-03-04 at 10:19 +0100, Josip Rodin wrote:
> [...]
>> Fortunately David Miller came to the rescue and personally debugged the
>> problem on one of the buildds, and fixed the problem. His solution, that
&
From: Ben Hutchings
Date: Thu, 1 Apr 2010 19:05:12 +0100
> On Thu, Apr 01, 2010 at 06:03:48PM +0100, David Woodhouse wrote:
>> On Thu, 2010-04-01 at 05:34 +0100, Ben Hutchings wrote:
> [...]
>> > Since you've dealt with (a), and (b) is not really as important, I would
>> > just like to suggest so
The upstream GLIBC GIT commit for this fix is:
9c96ff23858b0759e12ad69e3c4599931c90bee8
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
From: Ben Hutchings
Date: Wed, 07 Sep 2011 05:16:01 +0100
> This is somewhat unusual in that the IDE controller will be sharing its
> IRQ, but that's supposed to work.
>
> However, the IDE core attempts to disable and enable the IRQ *before* it
> allocates it. If the UHCI driver then allocates
From: Ben Hutchings
Date: Wed, 07 Sep 2011 05:58:33 +0100
> Well, I'm concerned with what to do in distro configurations which
> aren't just for 'modern systems'. We already swapped over all the
> drivers not labelled as experimental. With the rest, I worry that we'd
> be exchanging obscure IDE
From: Eric Dumazet
Date: Sat, 30 Jul 2011 07:22:42 +0200
> [PATCH] sch_sfq: fix sfq_enqueue()
>
> commit 8efa88540635 (sch_sfq: avoid giving spurious NET_XMIT_CN signals)
> forgot to call qdisc_tree_decrease_qlen() to signal upper levels that a
> packet (from another flow) was dropped, leading t
From: Ben Hutchings
Date: Thu, 01 Sep 2011 04:45:34 +0100
> So anyway, this CPU doesn't implement popc and is wrongly being detected
> as doing so.
I posted a fix for this already yesterday and it's in Linus's tree
and queued up in Greg's -stable tree as well:
>From 1a8e0da5937a6c87807083baa318
From: Ben Hutchings
Date: Mon, 01 Jul 2013 00:13:27 +0100
> The firmware patch for the Saturn PHY fixes a bug, but is not absolutely
> essential. And its licence is unclear, so it is not included in all
> distributions. Just log an error message and continue if it is missing
> or invalid.
>
>
Please bring this up on the appropriate, public, mailing list,
rather than to me privately.
In this case that would be sparcli...@vger.kernel.org
Thank you.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists
The problem is how sha1.cc codes the SHA1 transform, it illegally
casts the on-stack workspace buffer to a type requiring more
alignment than 'workspace' is actually declared to have.
This only shows up recently because gcc-4.6 now does a really
aggressive optimization where it gets rid of the wo
From: Eric Dumazet
Date: Thu, 23 Feb 2012 21:17:23 +0100
> Le jeudi 23 février 2012 à 15:11 -0500, David Miller a écrit :
>> Three instances of the same piece of code, maybe a helper function is
>> appropriate at that point? :-) You might even get ambitious and add a
>>
From: Eric Dumazet
Date: Thu, 23 Feb 2012 15:36:26 +0100
> [PATCH] ipsec: be careful of non existing mac headers
>
> Nicollo Belli reported ipsec crashes in case we handle a frame without
> mac header (atm in his case)
>
> Before copying mac header, better make sure it is present.
>
> Bugzilla
From: Eric Dumazet
Date: Thu, 23 Feb 2012 21:55:02 +0100
> Niccolo Belli reported ipsec crashes in case we handle a frame without
> mac header (atm in his case)
>
> Before copying mac header, better make sure it is present.
>
> Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42
From: Ben Hutchings
Date: Mon, 9 Jan 2012 22:04:28 +
> Commit 5b7c84066733c5dfb0e4016d939757b38de189e4 ('ipv4: correct IGMP
> behavior on v3 query during v2-compatibility mode') added yet another
> case for query parsing, which can result in max_delay = 0. Substitute
> a value of 1, as in th
From: Ben Hutchings
Date: Sat, 07 Apr 2012 18:21:38 +0100
> cheetah_xcall_deliver() does appear to be relevant to the problem and it
> looks like it could loop indefinitely - though presumably only if a
> processor is behaving strangely?
I can only loop indefinitely if one of the cpus is hung an
From: Ben Hutchings
Date: Sun, 08 Apr 2012 22:12:06 +0100
> Will the recipient NACK if the cross-call interrupt is disabled, or do
> the processors have a buffer/FIFO for such IRQs?
Recipient's NACK when their incoming cross-call queue is
full. A cpu hung with PSTATE_IE clear will not take
vect
From: Bjørn Mork
Date: Thu, 26 Apr 2012 14:35:10 +0200
> The same comments as for v1 regarding testing applies. This is build
> tested only. Should go through some functional testing before being
> applied.
Well? Is anyone gonna test this?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ.
From: Markus Kolb
Date: Thu, 03 May 2012 06:57:39 +0200
> I'll build it during next rainy day and will report its success
> after some usage ;-)
Thank you.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists
From: Markus Kolb
Date: Sun, 06 May 2012 12:13:32 +0200
> David Miller wrote on 03.05.2012 07:11:
>> From: Markus Kolb
>> Date: Thu, 03 May 2012 06:57:39 +0200
>>
>>> I'll build it during next rainy day and will report its success
>>> after some usage
From: Eric Dumazet
Date: Wed, 15 Apr 2015 11:22:44 -0700
> On Wed, 2015-04-15 at 19:00 +0100, Ben Hutchings wrote:
>> Commit 355a901e6cf1 ("tcp: make connect() mem charging friendly")
>> changed tcp_send_syn_data() to perform an open-coded copy of the 'syn'
>> skb rather than using skb_copy_expan
There is no reason whatsoever to enable the CONFIG_PROM_CONSOLE
option in the kernel.
By definition it can only cause problems and conflicts with other
console drivers.
For one example, it unconditionally gets registered as a real console
before the Sun Hypervisor console driver has a chance to
From: Julien Cristau
Date: Sun, 24 May 2009 15:52:20 +0200
> I plan to revert it for lenny r2, and if time permits I'll try to
> make the xserver-xorg package generate an xorg.conf with Driver set
> to fbdev instead..
Indeed, that's likely to work much better.
--
To UNSUBSCRIBE, email to deb
From: Ben Hutchings
Date: Fri, 10 Jul 2009 04:54:35 +0100
> alloc_etherdev() used to install default implementations of these
> operations, but they must now be explicitly installed in struct
> net_device_ops.
>
> Signed-off-by: Ben Hutchings
Applied.
--
To UNSUBSCRIBE, email to debian-bug
From: Ben Hutchings
Date: Sun, 04 Oct 2009 04:42:44 +0100
> From: Bastian Blank
>
> The following user-space program fails to compile:
>
> #include
> #include
> int main() { return 0; }
>
> The reason is that tests __GLIBC__ to decide whether it
> should define various structur
From: Jose Calhariz <[EMAIL PROTECTED]>
Date: Fri, 29 Aug 2008 14:43:20 +0100
> I am sending this email again because I have more information.
Thanks for your report.
Yoshifuji-san, nothing in linux/pim.h should be exported to userspace.
The previous location, linux/mroute.h, EXPLICITLY __KERNEL
From: David Miller <[EMAIL PROTECTED]>
Date: Fri, 29 Aug 2008 13:56:14 -0700 (PDT)
> net: Unbreak userspace which includes linux/mroute.h
Actually, now that I can see how this linux/pim.h thing
is used by both linux/mroute.h and linux/mroute6.h I have
decided to fix the problem in a
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Thu, 8 May 2008 01:26:59 +0300 (EEST)
> [PATCH] [TCP] FRTO: SACK variant is errorneously used with NewReno
I applied this with a minor coding style fixup.
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Thu, 8 May 2008 01:26:59 +0300 (EEST)
> +sta
From: Bernd Zeimetz <[EMAIL PROTECTED]>
Date: Sun, 28 Oct 2007 04:03:44 +0100
>
>
>
> I think things got worse with 2.6.24...
> The machine shoots itself now, I guess by running cron jobs or so.
>
> [29074.766486] TSTATE: 11009600 TPC: 0042f984 TNPC:
> 0042f928 Y:
From: Bernd Zeimetz <[EMAIL PROTECTED]>
Date: Sat, 27 Oct 2007 20:09:47 +0200
> titan:~# [ 2427.313946] BUG: soft lockup - CPU#3 stuck for 11s!
> [aptitude:13375]
> [ 2427.389128] TSTATE: 11009602 TPC: 0042f93c TNPC:
> 0042f7d0 Y: Not tainted
> [ 2427.506821]
From: Ben Hutchings
Date: Tue, 07 Sep 2010 02:27:10 +0100
> This is the regression I mentioned before. 3c59x should be good after
> this.
Excellent, applied, thanks!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm
From: Ben Hutchings
Date: Fri, 10 Sep 2010 17:46:30 +0100
> Prior to Linux 2.6.35, net devices outside the initial net namespace
> did not have sysfs directories. Attempting to add attributes to
> them will trigger a BUG().
>
> Reported-and-tested-by: Russell Stuart
> Signed-off-by: Ben Hutchi
From: Ben Hutchings
Date: Sat, 26 Jun 2010 22:37:47 +0100
> Since addresses are only revalidated every 2 minutes, the reported
> valid_lft can underflow shortly before the address is deleted.
> Clamp it to a minimum of 0, as for prefered_lft.
>
> Reported-by: Piotr Lewandowski
> Signed-off-by:
From: Ben Hutchings
Date: Sat, 26 Jun 2010 22:42:55 +0100
> max_desync_factor can be configured per-interface, but nothing is
> using the value.
>
> Reported-by: Piotr Lewandowski
> Signed-off-by: Ben Hutchings
Applied to net-next-2.6
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@l
From: Ben Hutchings
Date: Fri, 19 Feb 2010 02:56:21 +
> Intergraph bought 3D Labs and some XVR-500 chips have Intergraph's
> vendor id.
>
> Reported-by: Jurij Smakov
> Signed-off-by: Ben Hutchings
> Cc: sta...@kernel.org
Applied, thanks Ben.
--
To UNSUBSCRIBE, email to debian-bugs-dis
From: Ben Hutchings
Date: Fri, 24 Sep 2010 21:43:33 +0100
> The lifetime management for per-namespace state in phonet is broken in
> 2.6.32. When a network namespace is destroyed it will crash
> (repeatably):
...
> This bug is known to be triggered by using Chromium (which
> creates a network na
From: Ben Hutchings
Date: Fri, 23 Jul 2010 01:18:28 +0100
> commit a095cfc40ec7ebe63e9532383c5b5c2a27b14075
> "3c59x: Specify window explicitly for access to windowed registers"
> changed the first parameter to mdio_sync(), from a pointer to the
> register mapping, to a pointer to the vortex_priv
From: Josip Rodin
Date: Fri, 27 Aug 2010 21:31:37 +0200
> David, can you please queue this sunxvr500.c post-2.6.32 bugfix
> to sta...@kernel.org?
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bdd32ce95f79fb5cc964cd789d7ae4500bba7c6f
>
> Same story as the la
From: Greg KH
Date: Mon, 30 Aug 2010 07:50:17 -0700
> As I stated above, I need the ACK from David to be able to add these
> patches.
>
> David?
I believe there were some regressions caused by these changes that were
fixed later, a bit after those commites went into the tree.
I'm only conforta
From: Richard Mortimer
Date: Mon, 17 Jan 2011 19:46:21 +
> As an example from drivers/scsi/scsi_error.c function scsi_eh_wakeup().
>
> This has relocation records of
...
> 2be4 R_SPARC_LO10 __tracepoint_scsi_eh_wakeup
> 2be4 R_SPARC_13*ABS*+0x000
From: Richard Mortimer
Date: Mon, 17 Jan 2011 23:34:03 +
> However the same R_SPARC_13 also exists in scsi_mod.ko. It exists in the
> original Debian 2.6.37-trunk-sparc64 version and in my current build of
> the same with the 8 byte alignment for _trace_events.
...
Thanks for the info Richa
From: Richard Mortimer
Date: Mon, 17 Jan 2011 23:34:03 +
> I guess that points towards the binutils linker not doing the correct
> thing.
Ok, it is in fact doing the correct thing.
I'm really surprised we never hit this before in all of these years
:-) I guess we've simply never hit this ki
From: "Bernhard R. Link"
Date: Mon, 17 Jan 2011 15:39:54 +0100
> * David Miller [110117 07:07]:
>> Ugh, and I just noticed that include/linux/klist.h does this fixed
>> alignment of "4" too, where is this stuff coming from? It's
>> wrong on 64-bit
From: Steven Rostedt
Date: Mon, 17 Jan 2011 09:11:26 -0500
> The problem comes when the linker puts these sections together. We read
> all the sections as one big array. If the linker puts in holes, then
> this breaks the array, and the kernel crashes while reading the section.
Ummm, this sounds
From: David Miller
Date: Mon, 17 Jan 2011 21:34:48 -0800 (PST)
> Where are these "holes" coming from? Reading the commit message for
> the change that introduced this problem
> (86c38a31aa7f2dd6e74a262710bf8ebf7455acc5), it seems like the issue is
> coming from the compil
From: David Miller
Date: Mon, 17 Jan 2011 22:00:39 -0800 (PST)
> ftrace: Remove unnecessary alignment tag from ftrace_event_call.
>
> It's completely unnecessary and causes problems on platforms
> where this tag down-aligns the structure's alignment.
>
> Si
From: "Bernhard R. Link"
Date: Mon, 17 Jan 2011 15:39:54 +0100
>> I think we want none of this, and I think we should elide the align
>> directives entirely, or at least fix them so we don't get unaligned
>> stuff on 64-bit.
>
> One fix might be to move the __attribute__ from include/trace/ftrac
From: Steven Rostedt
Date: Mon, 17 Jan 2011 09:15:41 -0500
> Again, this is to help the linker keep arrays in tacked. Tracepoints are
> allocated into the tracepoint section, and then read like an array. If
> the linker adds holes as it links sections into one big one, then the
> reading of the a
From: Mathieu Desnoyers
Date: Mon, 17 Jan 2011 14:35:25 -0500
> Steven, what were you trying to fix in the first place when you added the
> aligned(4) to the definition ? It might have just been that the _ftrace_events
> section needed to be aligned on at least 8 bytes in the linker scripts, but
From: David Miller
Date: Mon, 17 Jan 2011 16:37:09 -0800 (PST)
> So we do end up seeing the R_SPARC_LO10 + R_SPARC_13 sequences in the
> final module object.
>
> Therefore, we really should handle R_SPARC_13 in the sparc module loader.
Ok, I now feel like I'm hallucinating.
d
From: Richard Mortimer
Date: Tue, 18 Jan 2011 13:23:14 +
> To close this off as a non-issue as far as my boot failures are
> concerned I did some further checking and objdump is displaying
> R_SPARC_OLO10 as two separate entries. I checked the scsi_mod.ko binary
> and found the appropriate El
From: David Miller
Date: Tue, 18 Jan 2011 13:00:27 -0800 (PST)
> I'll look into fixing binutils so that it properly reports the
> correct R_SPARC_OLO10 relocation in dumps. There really is no
> excuse for what it's currently doing. In fact, I think this
> quirk has sent m
From: Mathieu Desnoyers
Date: Wed, 19 Jan 2011 00:08:45 -0500
> The following works fine for me now. Comments are welcome.
Thanks for doing this work Mathieu.
> - No aligned() type attribute nor variable attribute. I get a crash on x86_64
> (NULL pointer exception when executing __trace_add_e
From: Mathieu Desnoyers
Date: Wed, 19 Jan 2011 00:08:45 -0500
> - No aligned() type attribute nor variable attribute. I get a crash on x86_64
> (NULL pointer exception when executing __trace_add_event_call, the 5th
> call).
> __alignof__(struct ftrace_event_call) is worth 8.
I think I figur
From: David Miller
Date: Tue, 18 Jan 2011 22:32:47 -0800 (PST)
> As far as GCC can see, the object is static and also not part of an
> array or any other C construct for which things like this could matter
> as long as the alignment it chooses meets the minimum alignment
> require
From: Mathieu Desnoyers
Date: Wed, 19 Jan 2011 10:33:26 -0500
> I'm still unsure that __long_long_aligned is needed over __long_aligned
> though.
> AFAIK, the only requirement we have for, e.g. tracepoints, is to align on the
> pointer size (sizeof(long)), so RCU pointer updates are performed at
From: Mathieu Desnoyers
Date: Wed, 19 Jan 2011 13:20:53 -0500
> Now what I'm discussing with David Miller is if creating a
>
> __long_packed_aligned
>
> and using it for *both* type and variable alignment would be more palatable
> (it
> also works, and is more co
From: Steven Rostedt
Date: Wed, 19 Jan 2011 17:00:23 -0500
> We can add a comment next to these structures specifying this
> dependency, and hopefully it would be updated if we ever do include a
> long long in them.
Yes, I think a huge comment should be placed somewhere and also the
commit messa
From: Mathieu Desnoyers
Date: Wed, 19 Jan 2011 17:13:27 -0500
> Hrm, I'd like to see what kind of ill-conceived 32-bit architecture would
> generate a unaligned access for a 32-bit aligned u64. Do you have examples in
> mind ? By definition, the memory accesses should be at most 32-bit, no ?
> A
From: Mathieu Desnoyers
Date: Wed, 19 Jan 2011 17:15:38 -0500
> * David Miller (da...@davemloft.net) wrote:
>> If plain "__long_aligned" works and, since you're tagging it to the structure
>> definition, it only specifies a minimum-alignment, then I'm
From: Mathieu Desnoyers
Date: Wed, 19 Jan 2011 17:21:44 -0500
> I still wonder how a 32-bit system can generate an unaligned access trap for
> an
> access to a 64-bit variable aligned on 32-bit, given that there is, by
> definition, no 64-bit memory accesses available on the architecture ?
Spar
From: Mathieu Desnoyers
Date: Wed, 19 Jan 2011 17:33:39 -0500
> So I guess we go for the following. Is it verbose enough ?
It's got all of the details that seem to matter, thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
From: Jesper Nilsson
Date: Mon, 17 Jan 2011 10:05:57 +0100
> On Mon, Jan 17, 2011 at 07:07:55AM +0100, David Miller wrote:
>> Ugh, and I just noticed that include/linux/klist.h does this fixed
>> alignment of "4" too, where is this stuff coming from? It's
>&
From: Ben Hutchings
Date: Tue, 29 Mar 2011 04:12:52 +0100
> via-ircc has been passing a NULL pointer to DMA allocation functions,
> which is completely invalid and results in a BUG on PowerPC. Now
> that we always have the device pointer available, pass it in.
>
> Reference: http://bugs.debian.
From: Ben Hutchings
Date: Sun, 04 Apr 2010 17:33:29 +0100
> The driver attempts to select an IRQ for the NIC automatically by
> testing which of the supported IRQs are available and then probing
> each available IRQ with probe_irq_{on,off}(). There are obvious race
> conditions here, besides whi
From: Eric Dumazet
Date: Tue, 13 Apr 2010 16:42:21 +0200
> Le mardi 13 avril 2010 à 15:27 +0100, stephen mulcahy a écrit :
>> Ok, I've tried both of the following with my reproducer
>>
>> 1. ethtool -K eth0 tso off
>>
>> RESULT: reproducer causes multiple hosts to be come unresponsive on
>> fi
From: Ayaz Abdulla
Date: Wed, 14 Apr 2010 01:33:15 -0400
> Attached fix has been submitted to netdev.
Thanks!
I apply this soon.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
I've also been bitten by this bug - noticed it last Friday and it
doesn't seem to be fixed this morning.
Is there an ETA on a fix with packages?
Thanks,
--- David
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas.
From: Jurij Smakov
Date: Sun, 8 Feb 2009 23:05:21 +
> To give a little bit of background, this patch was supposed to fix
> http://bugs.debian.org/500358. Bug trail contains all the gory
> details, but the crux of the problem (as I understand it) is the
> following: the commit [0] into the
From: Josip Rodin
Date: Mon, 9 Feb 2009 09:20:39 +0100
> On Sun, Feb 08, 2009 at 04:58:08PM -0800, David Miller wrote:
> > So you're saying that X working is more important than machines
> > actually booting at all? These priorities are wrong.
>
> When N (where N >
From: Josip Rodin
Date: Mon, 9 Feb 2009 09:45:27 +0100
> But then, it would have been completely your prerogative to respond to that
> simply by saying - DTRT and go upgrade X, patching old X is a waste of my
> time, and I guess nobody wanted to risk hearing that answer? :)
No, I would have said
From: Julien Cristau
Date: Wed, 25 Feb 2009 13:41:08 +0100
> On Mon, 2009-02-09 at 12:49 +0100, Julien Cristau wrote:
> > On Mon, 2009-02-09 at 01:21 -0800, David Miller wrote:
> > > No, I would have said that if time is tight at least we can use
> > > "fbdev&quo
From: Eric Dumazet
Date: Thu, 14 Oct 2010 06:11:59 +0200
> net-next-2.6 contains a fix for this, adding the perc_cpu
> xmit_recursion limit. We might push it to net-2.6
We need to think a bit more about this.
We are essentially now saying that one can only configure
tunnels 3 levels deep, and n
From: Eric Dumazet
Date: Tue, 19 Oct 2010 11:02:36 +0200
> Le mardi 19 octobre 2010 à 01:53 -0700, David Miller a écrit :
>> From: Eric Dumazet
>> Date: Thu, 14 Oct 2010 06:11:59 +0200
>>
>> > net-next-2.6 contains a fix for this, adding the perc_cpu
>> >
From: Ben Hutchings
Date: Sun, 09 Jan 2011 03:00:40 +
> On Sun, 2011-01-09 at 01:05 +, Richard Mortimer wrote:
>> Package: linux-2.6
>> Version: 2.6.37-1~experimental.1
>> Severity: normal
>>
>> Boot of linux-image-2.6.37-trunk-sparc64 fails to find the disks and drops
>> to the initramf
From: Richard Mortimer
Date: Thu, 13 Jan 2011 23:34:01 +
> On Wed, 2011-01-12 at 00:37 +, Ben Hutchings wrote:
>> On Wed, 2011-01-12 at 00:27 +, Richard Mortimer wrote:
>> >
>> > On 09/01/2011 03:46, David Miller wrote:
>> > > From: Ben Hutchi
From: Richard Mortimer
Date: Fri, 14 Jan 2011 10:53:35 +
> On 13/01/2011 23:57, David Miller wrote:
>>
>> Relocation type 36 is R_SPARC_LM22.
>
> I'm confused now! Maybe I've missed something but looking at
> arch/sparc/kernel/module.c i
From: Bastian Blank
Date: Sat, 15 Jan 2011 11:00:11 +0100
> On Fri, Jan 14, 2011 at 11:38:28AM -0800, David Miller wrote:
>> From: Richard Mortimer
>> > So that means that the kernel is complaining about type 54 which is
>> > R_SPARC_UA64. That matches with the objdum
From: Richard Mortimer
Date: Fri, 14 Jan 2011 16:08:30 +
[ Frederic, Steven, Ingo, the short version of the story is that we
need to make it such that the _ftrace_events section is aligned
properly for 64-bit systems, and in particular that GCC can see this
too. Otherwise GCC thinks 64
From: Richard Mortimer
Date: Sun, 16 Jan 2011 14:17:49 +
> I'm wondering if gcc is just getting better at honouring the source
> code. The DEFINE_EVENT macros in include/trace/ftrace.h have a
> __aligned__(4) attribute in them. Maybe that should be 8 on sparc64
> systems.
> The aligned 4 seem
From: "Bernhard R. Link"
Date: Sun, 16 Jan 2011 22:09:24 +0100
> * David Miller [110116 20:39]:
>> From: Richard Mortimer
>> Date: Sun, 16 Jan 2011 14:17:49 +
>>
>> > I'm wondering if gcc is just getting better at honouring the source
>&g
From: David Miller
Date: Sat, 15 Jan 2011 21:17:22 -0800 (PST)
[ Please, everyone, retain the full CC: on all replies, thanks. Some
people are replying only into the debian bug alias, and that loses
information and exposure for fixing this bug. ]
> I think the problem we have here is t
From:
Date: Wed, 2 Dec 2009 11:18:34 +0800
> From: Jie Yang
>
> For hardware limit to support TSOV6, just disable this feature
> Signed-off-by: Jie Yang
Shouldn't we be applying this to net-2.6 since it's a bug fix?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
wit
From: Jie Yang
Date: Wed, 2 Dec 2009 16:34:18 +0800
> On Wednesday, December 02, 2009 4:32 PM
> David Miller wrote:
>>
>> From:
>> Date: Wed, 2 Dec 2009 11:18:34 +0800
>>
>> > From: Jie Yang
>> >
>> > For hardware limit to support TSOV
From: Jan Ceuleers
Date: Mon, 28 Dec 2009 10:36:03 +0100
> Jan Ceuleers wrote:
>> I have successfully booted a 2.6.32.2 kernel with this patch applied on top
>> on a PXE-booting machine with nfsroot.
>
> Obviously this was on a machine with a Via Velocity NIC.
Fair enough, applied to net-2.6,
From: Ben Hutchings
Date: Thu, 12 Nov 2009 02:00:05 +
> This reverts commit 9c501935a3cdcf6b1d35aaee3aa11c7a7051a305. That
> commit caused to require that is
> included first, breaking autoconf tests for and
> presumably some real programs too.
>
> Signed-off-by: Ben Hutchings
I'm not
From: Ben Hutchings
Date: Thu, 12 Nov 2009 03:05:15 +
> will not compile for userland, because
> is no longer defining sa_family_t. For userland, this
> should be defined by .
Still, you still essentially have two choices:
1) Tell userland, sorry you need to include sys/socket.h before
From: Ben Hutchings
Date: Tue, 15 Dec 2009 02:05:09 +
> velocity_open() calls velocity_give_many_rx_descs(), which gives RX
> descriptors to the NIC, before installing an interrupt handler or
> calling velocity_init_registers(). I think this is very unsafe and it
> appears to explain the bug
From: Ben Hutchings
Date: Wed, 22 Jun 2011 04:20:13 +0100
> David, these look like good candidates for longterm updates. What do
> you think?
Sure but I don't do submissions for the longterm stuff, I only
work on the -stable trees that Greg is actively maintaining.
--
To UNSUBSCRIBE, email
From: Noah Meyerhans
Date: Tue, 10 May 2011 16:35:40 -0700
> On Tue, May 10, 2011 at 03:11:00PM -0700, Stephen Hemminger wrote:
>> There were two more follow on commits in stable related to this.
>> I recommend merging 2.6.38.6 which includes these.
>
> The problem still exists in the current 2.
97 matches
Mail list logo
