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
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: 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-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Con
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: Sun, 09 Jun 2013 21:07:31 +0100
> All architectures must implement IRQ functions. Since various
> dependencies on !S390 were removed, there are various drivers that can
> be selected but will fail to link. Provide a dummy implementation of
> these functions for the !PC
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.
>
>
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: Sat, 09 Apr 2011 23:55:51 +0100
> The following changes are present in Debian's kernel based on 2.6.32,
> but not yet in 2.6.32.y. I would like to send these to
> sta...@kernel.org but I know you prefer to pick which networking changes
> go into stable/longterm updates.
From: Ben Hutchings
Date: Wed, 13 Apr 2011 05:27:24 +0100
> On Tue, 2011-04-12 at 14:59 -0700, David Miller wrote:
>> From: Ben Hutchings
>> Date: Sat, 09 Apr 2011 23:55:51 +0100
>>
>> > The following changes are present in Debian's kernel based on 2.6.3
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.
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: 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: Jurij Smakov
Date: Sat, 12 Nov 2011 10:39:04 +
> It took a while, but the daily installer images [0] now include a
> kernel which should support Niagara T3. David, if you could try it out
> and report your findings, it would be greatly appreciated.
>
> I would like to use this opport
From: Ben Hutchings
Date: Thu, 24 Nov 2011 07:23:30 +
> Commit 88491d8103498a6166f70d502fec70924314 ("drivers/net: Kconfig
> & Makefile cleanup") changed the type of these options to bool, but
> they select code that could (and still can) be built as modules.
>
> Signed-off-by: Ben Hutch
From: Ben Hutchings
Date: Fri, 25 Nov 2011 14:07:51 +
> Well, I can't think why it would be built in, since PHY modules can be
> auto-loaded now.
It's because drivers select the thing.
Try allmodconfig for yourself.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with
From: Ben Hutchings
Date: Fri, 25 Nov 2011 18:40:42 +
> On Fri, 2011-11-25 at 13:22 -0500, David Miller wrote:
>> Try allmodconfig for yourself.
>
> OK, on x86_64, this does end up with PHYLIB=y but only because
> NET_DSA=y. And I don't believe NET_DSA is appropriat
From: Ben Hutchings
Date: Fri, 25 Nov 2011 19:37:43 +
> On Fri, 2011-11-25 at 13:50 -0500, David Miller wrote:
>> From: Ben Hutchings
>> Date: Fri, 25 Nov 2011 18:40:42 +
>>
>> > On Fri, 2011-11-25 at 13:22 -0500, David Miller wrote:
>> >> Tr
From: Jurij Smakov
Date: Sat, 12 Nov 2011 10:39:04 +
> It took a while, but the daily installer images [0] now include a
> kernel which should support Niagara T3. David, if you could try it out
> and report your findings, it would be greatly appreciated.
>
> I would like to use this opport
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: Jurij Smakov
Date: Sat, 12 Nov 2011 10:39:04 +
> On Sun, Aug 14, 2011 at 07:23:28PM +0100, Jurij Smakov wrote:
>> Thanks. I've built a test source package including all necessary
>> patches and a test build is running now. Ben tells me, however, that
>> 3.0.2 which includes all these p
From: Jurij Smakov
Date: Fri, 13 Jan 2012 19:39:11 +
> Thanks for testing. I've committed a fix to Debian kernel svn repo
> which will add mpt2sas to installer udebs with next kernel upload.
> I'll let you know once it makes it into the daily installer images.
Thanks a lot.
--
To UNSUBS
From: David Miller
Date: Fri, 13 Jan 2012 13:13:45 -0800 (PST)
> From: Jurij Smakov
> Date: Fri, 13 Jan 2012 19:39:11 +
>
>> Thanks for testing. I've committed a fix to Debian kernel svn repo
>> which will add mpt2sas to installer udebs with next kernel upload.
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: 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: Steven Rostedt
Date: Mon, 15 Aug 2011 11:40:23 -0400
> Actually, I think option d) is the best.
>
> d) have sparc support recordmcount.c
Maybe you misunderstand what these guys are doing.
The recordmcount.pl script wants to look at the output of the
architecture of the built kernel. It'
From: Steven Rostedt
Date: Mon, 15 Aug 2011 15:55:00 -0400
> But if they use recordmcount.c instead, then nothing needs to be done
> with recordmcount.pl.
>
> recordmcount.c looks at the elf file itself to determine what arch it is
> for. If this is supported, then everything should work, and yo
From: Steven Rostedt
Date: Mon, 15 Aug 2011 15:55:00 -0400
> But if they use recordmcount.c instead, then nothing needs to be done
> with recordmcount.pl.
Thanks again Steven, I'll push the following via the sparc tree.
>From 178a29600340bef5b13cd4157053679debe35351 Mon Sep
From: Ben Hutchings
Date: Mon, 22 Aug 2011 16:08:00 +0100
> David, I think we need this in 3.0-stable:
The change is already in -stable as it went into 3.0-final.
If anything this might suggest that the fix in question is
the cause of this bug, since the commit went in right after
3.0-rc4
Try
From: Ben Hutchings
Date: Mon, 22 Aug 2011 22:44:14 +0100
> On Mon, Aug 22, 2011 at 01:27:24PM -0700, David Miller wrote:
>> From: Ben Hutchings
>> Date: Mon, 22 Aug 2011 16:08:00 +0100
>>
>> > David, I think we need this in 3.0-stable:
>>
>> The ch
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: David Miller
Date: Sun, 15 Jan 2012 12:19:04 -0800 (PST)
> I won't be until mid-March before I can test install images again
> since I don't want to be physically away from the machine if something
> goes really wrong and I can't even reset or power cycle it remotel
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-kernel-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-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.de
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: Martin Habets <[EMAIL PROTECTED]>
Date: Sat, 26 May 2007 01:24:40 +0100
> Hi Kyle,
>
> After some minor fixes this builds, and the DRM drivers also
> build again. I cannot test this since I do not have a machine with
> PCI or these cards.
> Removed your name in the comment, as that went out
From: Kyle McMartin <[EMAIL PROTECTED]>
Date: Sat, 26 May 2007 10:45:09 -0400
> On Fri, May 25, 2007 at 10:00:36PM -0700, David Miller wrote:
> > > After some minor fixes this builds, and the DRM drivers also
> > > build again. I cannot test this since I do not have
From: Martin Habets <[EMAIL PROTECTED]>
Date: Sat, 26 May 2007 20:39:09 +0100
> LOL, that was my initial approach until I saw Kyle's code.
> Here's the patch I was preparing for that:
Even better would be to test if the platform has a real CMPXCHG
instruction since sparc32 is not the only platfor
From: Dave Airlie <[EMAIL PROTECTED]>
Date: Sat, 26 May 2007 21:32:10 +0100 (IST)
> the DRM can use cmpxchg in userspace, to implement DRM_CAS, have a look in
> drm git libdrm/xf86drm.h we appear to have a sparc implementation, this
> gives us fast userspace locking, however if an arch doesn't i
From: Kyle McMartin <[EMAIL PROTECTED]>
Date: Sat, 26 May 2007 19:41:34 -0400
> I don't see what the problem is? If we can't do it in userspace, we fall
> back to a heavyweight ioctl lock. This sounds sensible to me.
>
> On parisc we implement userspace CAS with a lightweight syscall on our
> gat
From: Martin Habets <[EMAIL PROTECTED]>
Date: Mon, 28 May 2007 01:07:46 +0100
> On Sat, May 26, 2007 at 03:59:21PM -0700, David Miller wrote:
> > Alternatively we can have a KCONFIG variable with reversed
> > logic, like "EMULATED_CMPXCHG" which only the atomicall
From: Kyle McMartin <[EMAIL PROTECTED]>
Date: Sun, 27 May 2007 23:11:14 -0400
> Yeah, David Howells wanted to use cmpxchg in his work struct patch, but
> had to not because not everyone implements it.
>
> >From what I can tell, very few arches actually have CAS, and others
> emulate it with LL/SC
From: Martin Habets <[EMAIL PROTECTED]>
Date: Tue, 29 May 2007 00:37:01 +0100
> Good to see someone has a crystal ball handy. So a patch like like this
> to solve the DRM issue? With it DRM can no longer be selected.
>
> ---
> The DRM code depends on an atomic version of cmpxchg(), which is not
>
From: Martin Habets <[EMAIL PROTECTED]>
Date: Tue, 29 May 2007 21:30:45 +0100
> On Tue, May 29, 2007 at 01:12:33AM -0700, David Miller wrote:
> > From: Martin Habets <[EMAIL PROTECTED]>
> > Date: Tue, 29 May 2007 00:37:01 +0100
> >
> > > Good to see so
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: 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
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: 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:
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-kernel-requ...@lists.debian.org
with a
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: 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: 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: 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-kernel-r
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-kernel-requ...@lists.debian.org
with a subject of "u
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
&
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-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@
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-kernel-requ...@list
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: 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
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-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://l
1 - 100 of 116 matches
Mail list logo
