On Mon, Sep 25, 2023 at 02:03:35AM +0200, Bastian Blank wrote:
> The current way does not work. See all the bug reports about
> uninstallable packages and what not with dkms.
>
> To build modules against version x, you'll need to install version x of
> the headers, not x-1 or x+1. This
On Fri, May 05, 2023 at 07:24:19PM +0200, fab...@greffrath.com wrote:
> Am 05.05.2023 18:23, schrieb Cyril Brulebois:
> > Right, initial support seems to have been merged in time for v6.2-rc1
> > only.
>
> Oh, no!
>
> When will be the earliest chance for a D-I image with kernel >= 6.2?
I am
On Fri, Jun 05, 2020 at 03:08:55PM +0200, John Paul Adrian Glaubitz wrote:
> Is POWER5 still supported by the Linux kernel? I thought IBM removed a
> bunch of older machines but kept PowerPC 970 support.
4.17 dropped power4. power5 and up are still supported just fine.
--
Len Sorensen
On Fri, Jun 05, 2020 at 08:37:02AM +0200, John Paul Adrian Glaubitz wrote:
> I would like to switch the ppc64 kernel back to 4k pages. The majority
> of our users are people on G5 Macs anyway, so I don't see a point
> in using 64k pages.
>
> Anyone with a large modern POWER machine is going to
I was under the impression stretch would release with 4.9 kernel.
So fixing it in 4.10 and marking it done seems like it might loose the
bug report without ever getting it actually included in stretch.
Will the config change in the 4.10 experimental automatically be included
in any updates to the
On Wed, Feb 01, 2017 at 02:27:39PM +0530, shirish शिरीष wrote:
> Basically the article's statement is wrong.
> There is no such thing as explicit itable initialization IO bandwidth
> restriction in MB/s. itable initialization rate is controlled by init_itable=N
> see:
On Wed, Feb 01, 2017 at 04:53:34AM +0530, shirish शिरीष wrote:
> hmm From what little I understand, it always the slowest interface
> that needs to be supported.
>
> And IIUC , in ext4lazyinit's case it is probably some of the MMC cards
> due to which the 16 MB/S transmission is kept -
On Wed, Feb 01, 2017 at 12:46:48AM +0530, shirish शिरीष wrote:
> Hi all,
>
> Warning - is a bit of a long read.
>
> >From what all I read and understood, ext4lazyinit simply makes you
> start using the hdd without creating all the inodes for your system.
> The only way that you know ext4lazyinit
On Thu, Oct 06, 2016 at 04:31:39PM +0200, Gianluca Renzi wrote:
> Just a clue: try to add a module parameter, for example videodepth= where
> you pass to the module offb.
> So if not passed gets the default, otherwise get the correct bpp value
> (8,15,16,24,32)???
The offb.c code seems to clearly
On Thu, Oct 06, 2016 at 07:44:35AM +0200, Mathieu Malaterre wrote:
> That's precisely what I tried yesterday.
>
> Anytime I press 'Enter' after '22 set-mode' or '32 set-depth' I loose
> display (either black or corrupted). when I then type 'boot' it goes
> back to normal 8 bits. I have access to
On Wed, Oct 05, 2016 at 08:55:50PM +0200, Mathieu Malaterre wrote:
> Will do ASAP. For reference:
>
> https://bugs.debian.org/825840#92
>
> and
>
> devalias tells me that 'screen' points to
> '/pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0'
Not sure how that maps to the dev syntax
On Wed, Oct 05, 2016 at 06:40:36PM +0200, Mathieu Malaterre wrote:
> On Tue, Oct 4, 2016 at 10:24 PM, Lennart Sorensen
> <lsore...@csclub.uwaterloo.ca> wrote:
> > On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
> >> On Tue, Oct 4, 2016 at 4:44 PM, L
On Tue, Oct 04, 2016 at 09:39:12PM +0200, Mathieu Malaterre wrote:
> Here is what I see:
>
> [ 52.270154] bus: 'pci': add driver radeonfb
> [ 52.270224] bus: 'pci': driver_probe_device: matched device
> :00:10.0 with driver radeonfb
> [ 52.270233] bus: 'pci': really_probe: probing
On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
> On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
> <lsore...@csclub.uwaterloo.ca> wrote:
> > On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
> >> € grep bogl_set_palette *
> &g
On Tue, Oct 04, 2016 at 08:41:45PM +0200, Mathieu Malaterre wrote:
> Hi Len,
>
> Here is the release function I am using:
>
> static void offb_destroy(struct fb_info *info)
> {
> struct offb_par *par = (struct offb_par *) info->par;
> if (info->screen_base)
>
On Tue, Oct 04, 2016 at 08:20:13AM +0200, Mathieu Malaterre wrote:
> Hi,
>
> > Well it seems ATY,Rockhopper2 (not Rockhopper) in the Mac Mini is in fact
> > a Radeon, and the way the radeonfb driver handles the pallete appears
> > to match the cmap_radeon in offb, so perhaps this would work in
On Tue, Oct 04, 2016 at 04:47:21PM +0200, Mathieu Malaterre wrote:
> Yes. If you re-read my post on debian-powerpc :) But getting `modprobe
> radeonfb` to work does not work as you know very well :)
> So the userland code in bterm is correct (no big endian issue).
Yes I also really doubt this is
On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
> € grep bogl_set_palette *
> bogl.c: bogl_set_palette = bogl_fb_set_palette;
> bogl.c: bogl_set_palette = bogl_fb_set_palette;
> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
> bogl.c: the palette with
On Tue, Oct 04, 2016 at 08:20:13AM +0200, Mathieu Malaterre wrote:
> I had time to test this patch yesterday night. It did not work using
> `cmap_radeon` codepath. I even tried changing:
>
> out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));
>
> into:
>
> out_le32(par->cmap_adr +
Well it seems ATY,Rockhopper2 (not Rockhopper) in the Mac Mini is in fact
a Radeon, and the way the radeonfb driver handles the pallete appears
to match the cmap_radeon in offb, so perhaps this would work in offb.c
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -333,7
I think the problem with registereing the PCI address in radeonfb is
that the offb does not unmap its addresses fully in the destroy function.
After all, it allocates both info->screen_base and par->cmap_addr as
using seperate ioremap calls on some hardware. The radeonfb on the
other hand does a
On Wed, Jun 22, 2016 at 09:24:51PM +0200, deloptes wrote:
> Sorry previous went out incomplete, because of some shortcut I pressed
> wrongly
>
> Here is what I found
>
> lrwxrwxrwx 1 root root 9 Jun 22 14:16
> ata-WDC_WD800GD-75FLC3_WD-WMAKE1962410 -> ../../sda
> lrwxrwxrwx 1 root root 9 Jun
On Fri, Jun 10, 2016 at 08:47:34PM +0200, Mathieu Malaterre wrote:
> Actually there are two issues in #714345, the last one which I suspect
> (trailing 'C' in alias) has still not been merged ([GIT PULL] Please
> pull powerpc/linux.git powerpc-4.7-3 tag)
You are right. I misread the patches
On Fri, Jun 10, 2016 at 08:28:12PM +0200, Mathieu Malaterre wrote:
> Wolfram,
>
> Could you please double check the following output from modinfo and
> confirm this is the same issue as Debian #714345
Well if it is, then manually doing:
modprobe airport
should detect the wifi on the new kernel.
On Thu, May 12, 2016 at 02:22:40AM +0100, Ben Hutchings wrote:
> It hit sid too. Our patch acceptance policy isn't quite as rigid as
> suggested. :-)
I see. Now all but Alpha are back at the same version. Nice to see.
--
Len Sorensen
On Thu, May 05, 2016 at 11:19:42PM +0200, John Paul Adrian Glaubitz wrote:
> On 05/05/2016 10:45 PM, Lennart Sorensen wrote:
> >> I just verified that the patch provided fixes the problem as expected.
> >
> > I have submitted it upstream.
>
> Great, that was
On Thu, May 05, 2016 at 10:26:18PM +0200, John Paul Adrian Glaubitz wrote:
> Control: tags -1 + patch
>
> On 05/05/2016 09:32 PM, John Paul Adrian Glaubitz wrote:
> >> If it works, I can submit it to the kernel. I don't have a powerpcspe
> >> environment to try building it, but I did notice that
On Thu, May 05, 2016 at 06:59:33PM +0200, John Paul Adrian Glaubitz wrote:
> Source: linux
> Version: 4.5.2-1
> Severity: normal
> User: debian-powe...@lists.debian.org
> Usertags: powerpcspe
>
> Hi!
>
> linux currently fails to build from source on powerpcspe since the compiler
> is using FPU
On Thu, May 05, 2016 at 06:59:33PM +0200, John Paul Adrian Glaubitz wrote:
> Source: linux
> Version: 4.5.2-1
> Severity: normal
> User: debian-powe...@lists.debian.org
> Usertags: powerpcspe
>
> Hi!
>
> linux currently fails to build from source on powerpcspe since the compiler
> is using FPU
On Thu, Dec 24, 2015 at 12:33:31AM +0100, Gianluca Renzi wrote:
> In this case I suppose even the userspace code (dynamic linking library)
> could not to be used
> with this linker bug and not only the kernel module loader tool. The
> undefined symbols are discarded in every way. The only way to
I just tried building and installing binutils from sid on jessie, and
then building a kernel module for the current kernel on the machine.
Module built with binutils from jessie loads fine, modules built with
binutils from sid has the mcount symbol error.
So I would agree, these two bugs do not
I found indications that perhaps both problems are in fact caused by ld
no longer including undefined symbols in the output.
Here is a section from the working module built with old binutils:
0012980: 0047 4343 3a20 2844 6562 6961 6e20 342e .GCC: (Debian 4.
0012990: 392e 322d 3130 2920 342e
On Mon, Dec 21, 2015 at 12:19:17PM -0500, wrote:
> I was looking at the module headers and found this pattern:
>
> In 4.2.1-2, 4.2.5-1, and 4.2.6-1 the order of the header for fat.ko says:
>
> 17 .data.rel.ro 01c0 00011418 2**3
>
On Mon, Dec 21, 2015 at 02:55:16PM -0500, wrote:
> I tried various binutils versions, and any version starting from
> 2.25.51.20151014-1 seems to be reordering the sections, even though
> the arch/powerpc/kernel/vmlinux.lds file explicitly says to use the
> order with .toc at the end. So somehow
I was looking at the module headers and found this pattern:
In 4.2.1-2, 4.2.5-1, and 4.2.6-1 the order of the header for fat.ko says:
17 .data.rel.ro 01c0 00011418 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
18 .opd 0af8
On Mon, Dec 07, 2015 at 07:42:42PM +, Ben Hutchings wrote:
> I intend to upload linux version 4.3.1-1 after version 4.2.6-3
> transitions to testing, which should happen later this week.
>
> This involves an ABI change, of course. Also, the 586 kernel flavour
> for i386 has been dropped in
On Mon, Dec 07, 2015 at 09:43:45PM +0100, Joachim Wiedorn wrote:
> But I think Geode LX doesn't work with 686. I have one
> so I will test it in the next week with the new kernel.
Well it appears that as long as the 686 kernel does not set
CONFIG_X86_P6_NOP, then the Geode LX should work with a
On Sun, May 24, 2015 at 04:09:30PM +0100, Ben Hutchings wrote:
Thanks for the analysis. There were a few more related patches, but
this got me on the right track. I've applied them for 3.16.7-ckt11-1.
Great. I imagine some beaglebone users will be pleased.
Using the 4.0 image from sid seems
On Fri, Nov 28, 2014 at 08:25:56AM +, Ian Campbell wrote:
It looks to me like you have discovered a bug[0] rather than some sort
of conspiracy against well maintained module packages. I recommend
filing it in the BTS as such.
OK, I will do so. I just thought I should ask before filing a
Source: linux
Version: 3.16.7-2
Severity: normal
Dear Maintainer,
I was trying to build the loop-aes-source modules and kept having odd
errors about loop.h-3.x not existing, while for some reason the loop.h-2.6
was there. Of course the build was for a 3.16 kernel and hence wanted
the 3.x file.
I was trying to compile loop-aes-source, but it keeps failing. For some
reason it kept thinking the kernel version was 2.6, when it is in
fact 3.16. The problem is that it looks at the VERSION and PATCHLEVEL
in the Makefile of the headers, which for some reason is being modified
to read 2 and 6
On Thu, Sep 04, 2014 at 05:57:47PM +0200, Sylvain Rabot wrote:
Hi,
I'm trying to setup a PXE with netboot install of squeeze for some HP
hardware that uses broadcom 10G cards.
Those broadcom cards are only correctly detected with the 3.2 kernel from
the backports (and with an additional
On Thu, Jun 27, 2013 at 09:29:12PM +, Luca Filipozzi wrote:
We have to start somewhere, however. Having equipment on which to build, is a
good start. I'll let the release team and the buildd team decide what to
build, when and where. My goal is meet the supportability / reliability
On Thu, Jun 27, 2013 at 07:27:54PM +, David Power wrote:
Hey Guys, I stumbled upon this thread while trying to investigate if
debian would work on the calxeda platform. We're one of calxedas partners
and have specific customers who would really love to see debian working on
ours/calxedas
On Fri, Jun 07, 2013 at 08:52:43AM +0100, luke.leighton wrote:
coming back to what you said earlier: i'm formulating what to say to
allwinner [and need to pre-send something by monday so that they can
consider it before the meeting]. so far, it consists of:
* device-tree is what the linux
On Wed, Jun 05, 2013 at 11:38:52PM +0100, Luke Kenneth Casson Leighton wrote:
their sheer overwhelming success provides us with mass-volume
ultra-low cost hardware. to not make an effort to accommodate them
would in this specific instance be a huge missed opportunity,
responsibility for
On Thu, Jun 06, 2013 at 07:28:10PM +0200, Maxime Ripard wrote:
I should also add that Allwinner not only talked to us already, but also
expressed interest in doing actual modern kernel development (like using
recently introduced kernel frameworks, like the clk framework).
I've received
On Wed, Jun 05, 2013 at 10:24:15PM +0100, Luke Kenneth Casson Leighton wrote:
https://github.com/linux-sunxi/u-boot-sunxi
And Then Some, stephen. there are two versions of u-boot being used:
one is the community-assembled [GPL-compliant] one, and the other
includes a
On Thu, Mar 21, 2013 at 08:42:49AM +, Tixy wrote:
A single multiplatform kernel can support both armv6 and armv7 (or armv4
+ armv5). I don't know if Debian plans to have separate versions for
each architecture version - there may be performance benefits to this -
in which case using armv6
On Wed, Feb 27, 2013 at 12:05:06AM +0100, Andreas Beckmann wrote:
nvidia-kernel-{source,dkms} don't use upstream's conftest.sh to test for
availability of features, instead we ship (probably for historic reasons
where conftest.sh was not working properly) a manually generated
conftest.h that
On Thu, Feb 07, 2013 at 09:33:54PM +0100, martinwguy wrote:
There is a way: for Debian armhf to re-target on v6 in a future release.
That would break none of the existing installations and make Debian
more Universal as per its manifesto. With hindsight it would have been
better for Debian
On Sun, Mar 04, 2012 at 06:31:06PM -0700, dann frazier wrote:
I reuploaded w/o that patch - that fix was POWER7 specific, and it
looks like POWER7 support wasn't supported in the lenny timeframe
anyway.
POWER7 only really got added to the installer in 6.0.4 (not even 6.0)
so, seems perfectly
I lost access to wireless as well with the upgraded kernel. -20 doesn't
work either, haven't tried -21 yet (not that the changelog gives me
any hope). 2.6.32-3-amd64 which I have installed also doesn't work
(I think that one is from before I got the new wifi card).
I will try looking at the
After a bunch more poking, it found that 2.6.32-3 and 2.6.32-4 didn't
work on the machine anymore either, so I started suspecting other things.
Turns out network-manager showed every device as unmanaged. Somehow a
new version of network-manager included a new config file, but it was
left as
On Thu, Aug 26, 2010 at 11:24:46AM +1000, Vincent McIntyre wrote:
this problem is also occurring on Dell Optiplex 780 machines,
the PCI ID of the network card is 8086:10de.
I tried installing using this netboot image:
I just wanted to add that for my wifi, it actually connects to the access
point, and about 3 to 4 seconds later (that's how many ping packets make
it through) the connection stops doing anything.
I am looking through 2.6.32.2 to see which changes might affect it.
The ones related to wifi power
My iwlagn (intel 5100) is also broken. Worked with 2.6.32-2, broken with
2.6.32-3, same as the atheros, same as the ralink rt61. Seems something
changed between -2 and -3 that took out pretty much all wifi cards.
I am running amd64 in case it matters.
I can't even begin to guess which of the
I am starting to think that debian has completely broken support for
compiling out of tree kernel modules as of 2.6.29 now.
It used to be, that if you needed to know if a certain function used one
style or another, then you could do a compile test against the kernel
headers and see if it worked
On Mon, Apr 13, 2009 at 09:13:50PM +0100, Ben Hutchings wrote:
On Mon, 2009-04-13 at 14:52 -0400, Lennart Sorensen wrote:
I am starting to think that debian has completely broken support for
compiling out of tree kernel modules as of 2.6.29 now.
It used to be, that if you needed to know
On Tue, Mar 31, 2009 at 10:16:39AM +0200, Bastian Blank wrote:
On Mon, Mar 30, 2009 at 08:19:32PM -0400, Lennart Sorensen wrote:
Out of couriosity (and to try and fix the nvidia driver build system)...
Documented by who? Debian or the linux kernel?
Documentation/kbuild/modules.txt
linux-headers-2.6.29-1-686 is missing all the symlinks to
linux-headers-2.6.29-1-common.
For example:
# ls -l /lib/modules/2.6.26-2-686/build/include/linux/agp_backend.h
lrwxrwxrwx 1 root root 66 Mar 30 19:30
/lib/modules/2.6.26-2-686/build/include/linux/agp_backend.h -
OK, so I see now that the symlinks from the past release are no longer
used due to new magic Makefile stuff. Rather neat.
However as the original bug says, Makefile_32.cpu is in fact missing
from linux-headers-2.6.29-1-common, which breaks i386. amd64 doesn't
need it and hence works fine.
On Sat, Mar 28, 2009 at 11:28:07PM +0100, Bastian Blank wrote:
severity 521515 wishlist
tags 521515 wontfix
thanks
On Fri, Mar 27, 2009 at 09:02:04PM -0400, Aaron M. Ucko wrote:
As of 2.6.29-1, that no longer
holds, causing trouble for packages such as
On Wed, Jun 25, 2008 at 03:42:55AM +0200, maximilian attems wrote:
On Mon, 23 Jun 2008, Otavio Salvador wrote:
Kernel Team, please give us some guidance on that. Should we use
ide-generic-pci or ide-generic?
on my TODO, currently fjp has the best write up on the current situation.
wanted
On Wed, Jun 25, 2008 at 05:21:34PM +0200, maximilian attems wrote:
that there is *zero* point in having it loaded first.
also win 95 killed ISA thankfully. gone dead.
if someone really complains we can start wasting time there.
Win95 ran just fine on an ISA only 486. Not dead what so ever.
On Wed, Jun 25, 2008 at 06:49:32PM +0200, maximilian attems wrote:
this thread goes no where.
loading a module on *all* boxes for 0.01% percent of the population
is not the right thing to do.
And what solution is there for the 0.01% that would like to continue
using their systems? Do you
On Wed, Jun 25, 2008 at 06:18:46PM +0200, Sven Luther wrote:
ide-generic did hurt a lot, it took over the ide device in various case
over the native driver, and disk support broke.
Which cases? lack of ide-generic hurts a lot when it is the only driver
for your controller too.
Also, this
On Mon, Jun 23, 2008 at 12:19:18AM +0200, Bastian Blank wrote:
ndiswrapper is a module loader. But it does not take the appropriate
actions while handling non-free modules.
It sure tries.
| /*
| * ndiswrapper is under GPL by itself, but loads proprietary
modules.
|
On Fri, Jun 20, 2008 at 08:03:16PM +0200, Bastian Blank wrote:
Several people, including Linux upstream, declares ndiswrapper as
non-free. Please move it to the appropriate section.
No they don't. There are even completely GPL drivers that are possible
to run under ndiswrapper.
The upstream
On Fri, Jun 20, 2008 at 10:38:42AM +0200, Daniel Baumann wrote:
it is a (not yet written) policy that each module-source package needs
to work like this in order get into linux-modules-*.
why/what is it so difficult to add/adjust the toplevel makefile to do that?
Well perhaps documentation
On Fri, Jun 20, 2008 at 04:57:00PM +0200, Daniel Baumann wrote:
jup, is on my (quite large) todo list. though I prefere to work on the
RC issues first, that's why it's not yet done.
we should get nvidia-* really done now. may I have a look at what you
have right now?
The current release
On Thu, May 22, 2008 at 02:33:24PM +1000, Babstar wrote:
There is no problem with the Nvidia script, the problem is Nvidia does
not support xen kernels.
I'm all for a better solution to this problem, however, a huge number of
users have *no choice* as to which video card is installed in their
On Thu, May 22, 2008 at 07:12:03AM +0100, Ian Campbell wrote:
That is true of the original Xen kernels (up to 2.6.18) but not of the
new Xen kernels (2.6.22+).
Is that a result of the paravirt stuff going in?
The original Xen port of Linux required that you build a specific Xen
kernel which
On Thu, May 22, 2008 at 03:13:09PM +0100, Ian Campbell wrote:
The solution to this is to remove the CONFIG_XEN check and all the
#ifdef CONFIG_XEN bits from the code
Patch is attached, together with [0] from #476504 for 2.6.25 support it
builds fine and works on native (not sure what happens
I would like to know why it was decided to enable Xen on all i386
kernels. The changelog simply states it was done, which isn't exactly
helpful, other than to show it apparently was on purpose and not an
accident.
Meanwhile amd64 kernels don't have it enabled. Why the difference?
Perhaps I am
On Wed, May 21, 2008 at 06:33:12PM +0200, maximilian attems wrote:
the reason seems quite evident.
to be able to have any debian kernel as xen guest.
it is a frequent feature request we received.
Well I would like to request a kernel without this feature again. It
isn't as if a 686-noxen
On Wed, May 21, 2008 at 06:47:25PM +0200, Bastian Blank wrote:
Because it is not supported.
OK, that is a good reason.
The Xen support only adds something, it does not remove something which
was there before.
I was under the impression it changed some of the ways to access
physical
On Wed, May 21, 2008 at 08:25:44PM +0200, maximilian attems wrote:
why?
their scripts are buggy, beat them to it.
you seem to have enough energy.
I am doing that now. I was under the (apparently mistaken) impression
that the xen features would break the driver's access to the hardware
On Wed, May 21, 2008 at 03:31:45PM -0400, Lennart Sorensen wrote:
I am doing that now. I was under the (apparently mistaken) impression
that the xen features would break the driver's access to the hardware
without changes.
I guess the real case is that the driver should work on a kernel
On Fri, Jan 25, 2008 at 12:03:59AM +0100, maximilian attems wrote:
you have to repost to the other one.
but be warned oops or bugs with tainted kernels don't get love here
unless they are reproduced without proprietary crap.
I have resubmitted it to the correct bug number.
Please disregard my
There is no reason what so ever to say it is a driver bug.
kwin crashes with the nvidia driver. kwin should not crash no matter
what garbage the driver may return to it. It can detect that it got bad
data back and give an error, but a crash is simply sloppy coding and
hence a bug in kwin.
On Thu, Jan 24, 2008 at 04:08:23PM +0100, maximilian attems wrote:
On Thu, Jan 24, 2008 at 09:43:03AM -0500, Lennart Sorensen wrote:
There is no reason what so ever to say it is a driver bug.
no idea what bug you are reffering to but your message seems
in no way to correlate with 461182
On Sun, Nov 25, 2007 at 10:32:31PM +0200, Teodor wrote:
A few minutes ago I've upgraded the BIOS to the latest version
available 1601beta and the system is freezing immediately after I start
the firefox browser, probably caused by a growing load on the CPUs.
Unfortunately I don't have a
On Thu, Jun 15, 2006 at 12:42:26AM +0200, Frederik Schueler wrote:
-generic is odd and too long. I am considering to change the naming
scheme completely, and call the flavours 2.6.x-y-amd64 and
2.6.x-y-em64t respectively.
So if you use amd64 now, then what will you use when amd releases an
On Tue, Jun 13, 2006 at 07:12:00PM +0200, Goswin von Brederlow wrote:
amd64-k8 runs on em64t?
Looking at the 2.6.16 sources, it appears that CONFIG_CPU_GENERIC sets
all the cache size options of CONFIG_MSPC (em64t), and the only other
difference is that CPU_GENERIC doesn't set -march at all. So
On Tue, Apr 11, 2006 at 07:21:49PM -0700, Gordon Haverland wrote:
Occasionally I get an email from someone who is reporting back to
many people, but in general I have gotten NO FEEDBACK on this bug
report! It apparently wasn't reproducible to the person fielding
the bug report, but it is
On Wed, Feb 01, 2006 at 08:30:06AM -0800, belahcene abdelkader wrote:
I downloaded the last CD debian testing Disk 1 (janv
30), the installation began correctly from the CD ( so
it is detected ide cdrom well known type) after a
while, it gave an error : no cdrom detected , !!!
So I went to
On Wed, Dec 07, 2005 at 09:16:34PM +0100, Frederik Schueler wrote:
due to upstream changes in 2.6.15-rc series, the current i386 386 flavour
does not build anymore with plain old M386 support activated.
Deactivating those drivers - which need those instructions not available on
M386 - is
On Wed, Sep 14, 2005 at 08:19:16AM +0200, Sven Luther wrote:
Is this not the moment to modify the way our kernel .udeb packages are built,
and either use a single package building all .udebs or at least some common
infrastructure for building them all if there is still problems in the
archive,
On Wed, Sep 14, 2005 at 03:28:30PM +0200, Sven Luther wrote:
not sure i fully understand what you mean here. I guess you are saying you can
kind of fix the b-i/kernel rules to install either linux-image or
kernel-image, but that would be counter productive, now that we have some nice
unified
On Wed, Sep 14, 2005 at 03:56:07PM +0200, Sven Luther wrote:
We would only package those needed for the installer, we can list those in the
.udebs actually, there should be around a 100 or so. multiplied by around 50
flavours (maybe less) this brings us around 5000 packages.
Well, we may
On Wed, Sep 14, 2005 at 11:04:27AM -0400, Joey Hess wrote:
[EMAIL PROTECTED]:~/lib/debian/unstablefor d in *2.6.12*; do dpkg --contents
$d; done |grep \.ko |wc -l
340
Does that include the missing modules like sata-uli, ahci, etc? Well at
least they were missing from the udeb building
On Wed, Sep 14, 2005 at 07:45:25PM +0200, Sven Luther wrote:
Which was a missing .udeb indeed, and quite bothersome. Not sure if it was
introduced by a change in the hfsplus module, or by a change in d-i. That
said, this is orthogonal to the issues discussed here. Also notice that if we
had
On Fri, Nov 05, 2004 at 01:14:35PM +0900, Horms wrote:
Sounds like a memory leak in the kernel somewhere.
Certainly does. I never saw it before 2.6.7 I think and it seems as of
one of the last 2.6.8 builds in testing it has gone away again.
I think it would be worth seeing if the behaviour is
94 matches
Mail list logo
