Package: linux-2.6
Severity: important
When attempting to install with d-i daily builds (or hand built d-i
images) via the network I find that I am unable to use r8189 network
controllers which had ethernet cables connected at modprobe time. The
system detects the three r8169 controllers that
Package: linux-image-2.6.18-4
Severity: important
Tags: patch
Kernel 2.6.18 contains a version of the natsemi driver which supports
NAPI but has buggy handling of shared interrupts. The patch below
(which is a slightly cut down version of one which has been accepted
upstream, omitting reversion
Package: linux-image-2.6.21-1-powerpc
Version: 2.6.21-4
Severity: important
Since upgrading to this kernel version any attempt to suspend my laptop
has failed. The machine begins to suspend, complains that it cannot
suspend and then attempts to abort the suspend but fails to do so,
forcing a
reassign 429662 linux-image-2.6.22-1-powerpc
found 429662 2.6.22-3
thanks
On Thu, Jul 05, 2007 at 12:39:16PM +0100, Mark Brown wrote:
Suspending via closing the laptop lid appears to have been fixed by
2.6.21-2-powerpc but if I try to initiate a suspend from the GNOME power
manager GUI
Package: linux-support-2.6.22-1
Version: 2.6.22-3
Severity: important
Attempting to build a module module package such as
linux-modules-extra-2.6 which uses gencontrol.py fails even when using
the copy of gencontrol.py included in the package as
tag 436260 + patch
thanks
The enclosed gencontrol.py for use in module packages probably fixes
interoperation with module packages for current kernel versions. It
appears to work for me but I have relatively little confidence in my
changes given that I don't particularly understand the changes
by the kernel team.
On Mon, Aug 06, 2007 at 08:03:13PM +0100, Mark Brown wrote:
tag 436260 + patch
There is no patch attached.
Sorry, here's the updated gencontrol.py. I've not generated a patch
since I don't really know what to generate it against.
--
You grabbed my hand and we fell into it, like
On Tue, May 13, 2008 at 01:46:51AM +0200, maximilian attems wrote:
humm is that reproducible with a recent Lenny kernel?
thanks for update.
I left the job where I had access to the hardware about seven months
ago. I seem to remember we were able to avoid the issue by using 2.6.22
or so so
On Wed, May 21, 2008 at 08:59:23PM +0200, maximilian attems wrote:
can we have an update on a recent linux image aka 2.6.25 from sid
installs just fine in testing.
thanks
I do not currently run Linux on the affected machine. I could test with
a d-i image?
--
You grabbed my hand and we fell
On Wed, Nov 12, 2008 at 11:03:55PM +0100, Moritz Muehlenhoff wrote:
On Mon, Jun 30, 2008 at 02:13:33PM +0200, maximilian attems wrote:
if you can reproduce it with 2.6.25 or newer snapshots.
i'm all ears unless so it is assumed fixed.
Mark, does the problem still exist for you with the
reopen 436260
thanks
On Sun, Jun 29, 2008 at 03:48:07PM +, Debian Bug Tracking System wrote:
closing as this general assumption seems not true
quite a bunch of external modules is build.
As far as I remember (this was all quite some time ago) the external
module packages were all using
On Sun, Jun 29, 2008 at 11:01:43PM +0200, maximilian attems wrote:
there was no patch provided nor any proof of any trouble by your
side, so tagging with moreinfo and willl close in 10 days
unless something substantial comes up.
Uh, message 10 of the bug report contains the updated version of
On Mon, Apr 05, 2010 at 07:49:23PM +0100, Ben Hutchings wrote:
On Mon, 2010-04-05 at 20:00 +0300, Rami Autiom??ki wrote:
My laptop suspends and resumes find, but sound is not working after
computer is
suspended and resumed. I compiled vanilla kernel 2.6.33.2 from kernel.org,
after
On Wed, Oct 21, 2009 at 01:21:20PM +0100, Martin Michlmayr wrote:
Another exception that should be added here is for devices which have
well-defined hardware components. For example, I don't need hardware
information for a QNAP TS-209 because it's a consumer NAS machine and
you cannot change
On Tue, Jun 08, 2010 at 02:02:48PM +0200, Bastian Blank wrote:
On Tue, Jun 08, 2010 at 11:31:41AM +0200, Thibaut Girka wrote:
X-Git-Url:
http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=470379585be3e2e116e9412e114698debb02eb9e
MFD: pcf50633: Fix bitfield logic in interrupt
Package: linux-2.6
Version: 2.6.37-2
Severity: normal
As soon as the kernel switches to framebuffer mode on 2.6.37-2-amd64 the
display becomes unrecoverably corrupted though everything appears to
continue to run fine and a reboot can be initiated. With 2.6.32-5-amd64
the display appears fine.
On Mon, Mar 14, 2011 at 11:15:04AM +, Debian Bug Tracking System wrote:
If you wish to submit further information on this problem, please
send it to 618...@bugs.debian.org.
This appears to be resolved by 2.6.38-rc7.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
On Mon, Mar 14, 2011 at 01:24:26PM +, Ben Hutchings wrote:
I notice that this system is using the radeon driver but does not have
the Radeon firmware installed. On older hardware the firmware is only
needed for 3D acceleration, but I suspect that other functions also
depend on it now.
On Mon, Dec 21, 2009 at 01:56:05AM +, Ben Hutchings wrote:
On Mon, 2009-12-21 at 09:24 +0800, Paul Wise wrote:
I guess oss4-dkms will be enough to take care of these users,
hopefully it will reach squeeze in time.
Hopefully not. OSS4 on Linux is part of the problem, not part of the
On Mon, Feb 07, 2011 at 05:15:07PM -0500, Michael Gilbert wrote:
On Mon, Feb 7, 2011 at 5:09 PM, Julien Cristau wrote:
What does that buy us? ??It means instead of dealing with bugs on an
ongoing basis, you get them all at the same time and get to bisect along
many kernel versions at once
On Mon, Sep 16, 2013 at 10:11:47AM +0200, Arnaud Patard wrote:
exynos in armmp won't happen anytime soon unless you bug upstream about
multiplatform support. iirc, even in -next, it's still not possible to
enable exynos in multiplatform builds.
It does mostly work with mainline, audio still
On 16 August 2013 09:42, Ben Hutchings b...@decadent.org.uk wrote:
Please use the advertised e-mail addresses for maintainers.
On Thu, 2013-08-15 at 19:16 -0500, Robert Nelson wrote:
This is fixed in the sound next branch:
On Sat, Aug 17, 2013 at 06:25:44PM +0200, Ben Hutchings wrote:
On Fri, 2013-08-16 at 11:34 +0100, Mark Brown wrote:
Please use the advertised e-mail addresses for maintainers.
Expand, please? I took your address from the commit that Robert pointed
out.
You're better off with MAINTAINERS
On Tue, Aug 20, 2013 at 01:39:40AM +0200, Ben Hutchings wrote:
On Mon, 2013-08-19 at 11:41 +0100, Mark Brown wrote:
Could you be more specific as to what you believe the problem that
exists is? You mentioned that the kernel would be tainted but that
doesn't seem like a not working thing
On Thu, Jun 06, 2013 at 02:01:14AM +0200, Tomasz Figa wrote:
I don't see any other solution here than moving all the Allwinner code to
DT (as it has been suggested in this thread several times already), as
this is the only hardware description method supported by ARM Linux.
Well, the server
On Sun, Sep 14, 2014 at 06:10:24PM +0100, Ben Hutchings wrote:
The first patch in the series restores the module aliases to m25p80, but
it does so by duplicating the list of names. This should be suitable
for stable, but it isn't viable in the longer term.
Please don't CC patches not for the
On Mon, Sep 29, 2014 at 11:47:53AM +0200, Rafał Miłecki wrote:
This simplifies the way we use spi_nor framework and will allow us to
drop spi_nor_match_id.
Please don't CC linux-spi on spi-nor patches that don't have SPI level
changes, it just clogs up patchwork.
signature.asc
Description:
Package: src:linux
Version: 3.16.3-2
Severity: serious
The staging driver r8723au is enabled in the kernel but there appear to
be very good reasons why it's in staging - when it loads it routinely
locks up my system (hard with no output unfortunately). It seems to
make sense to disable the
I've tested this with v3.17 from experimental and the driver seems
vastly more stable with that kernel version so this probably only
applies to v3.16, Ben did point out to me that there had been a lot of
work on the driver between the two versions.
signature.asc
Description: Digital signature
On Mon, May 23, 2016 at 04:40:47PM +0200, Steinar H. Gunderson wrote:
> On Mon, May 23, 2016 at 03:47:37PM +0200, Steinar H. Gunderson wrote:
> > In this case, it's not just an annoyance, though; they're so many that they
> > keep the system from booting unless loglevel is turned down. Cc-ing
On Tue, May 24, 2016 at 05:26:38PM +0200, Steinar H. Gunderson wrote:
> On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote:
> > Please send an appropriate separate patch for fixing this. Your email
> > did not reach people, I think.
> I only sent one patch so far, namely the
On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote:
> What other problems exactly do you have? Late binding of S2MPS11
> regulator driver? That does not look like a problem. If it is built as
> a module then it should be loaded, probably from initramfs because
> these are
On Thu, Jan 03, 2019 at 01:49:49PM +, Mark Brown wrote:
> Even with only one monitor connected the system is unable to do anything
> useful with the display, it has trouble setting up a valid clock
> configuration though there is no oops:
>
> Dec 29 17:57:14 debutante kernel
Package: src:linux
Version: 4.19.13-1
Severity: important
As covered in the kernel log below the amdgpu driver fails to initialize
a multi-monitor DisplayPort chain connected to a and AMD RX560
(Polaris11), rendering the system unusable in desktop configurations.
There is an oops earlier in the
On Sun, Sep 05, 2021 at 05:01:18PM +0100, Steve McIntyre wrote:
> On Sat, Sep 04, 2021 at 06:50:16PM +0100, Steve McIntyre wrote:
> >
> >I have a synquacer here still and I'll take a look. I noticed on
> >bullseye release day that USB stuff didn't seem to work in the
> >installer on the synquacer
On Tue, Mar 29, 2022 at 01:02:34AM +0100, Mark Brown wrote:
> On Sun, Sep 05, 2021 at 05:01:18PM +0100, Steve McIntyre wrote:
> I bisected this to
>
> commit 7a8b64d17e35810dc3176fe61208b45c15d25402
>
> of/address: use range parser for of_dma_get_range
>
> on what a
the issues there.
Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown
Cc: Luca Di Stefano
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
---
drivers/of/address.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/of
On Fri, Jan 27, 2023 at 12:37:35PM -0600, Rob Herring wrote:
> Looks to me like we are leaking 'r' with this change.
Oh, probably now that you mention it. Usually the OF code keeps
track of more things than I expect...
> Wouldn't this change work:
> diff --git a/drivers/of/address.c
the issues there.
Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown
Cc: Luca Di Stefano
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
---
Changes in v2:
- Don't leak parsed resources.
- Link to v1:
https://lore.kernel.org/r/20230126-synquacer
39 matches
Mail list logo
