Bug#679545: [RFC/PATCH] ia64, SR870, EFI bug breaks ata_piix, uninitialized ICH4 IDE EXBAR mem resource
My only disagreement here would be putting it in the ia64 paths. If someone does the same for x86-32 (and this is EFI so it'll presumbly smell the same on all platforms) then we'll want the same. Better I think to generically catch the 0/0 case. Alan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917115619.13d3a...@pyramind.ukuu.org.uk
Re: [RFC] Simplifying kernel configuration for distro issues
> > kconfig already spits out warnings for symbols being selected that > > don't exist. > > We can make these even bigger :-) Add lots of stars (*) around them! Make oldconfig already handles this just fine Alan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719184118.03cb3...@pyramind.ukuu.org.uk
Re: [RFC] Simplifying kernel configuration for distro issues
> Well, yes. I was thinking it would be more like: > > distro/Kconfig.fedora > menuconfig FEDORA > if FEDORA > config FEDORA_16 > select WHATEVER > config FEDORA_17 Nope you need distro/everyarchtheyship/everykernelvarianttkeyship(smp,largemem,arm boards)/Kconfig which for some distros is over 20 per release and the end user wouldn't have a cat in hells chance of knowing which to pick. For the end user case you need the distro to plonk the right file in the right place and be done with it, once they do that the rest is bikeshedding a ten line Makefile rule. Alan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120719183047.69de3...@pyramind.ukuu.org.uk
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
> Select the profile and then fixup the config the normal way. > > If what the admin wants is incompatible with the profile, admin doesn't > select the profile. Thats ugly - "distro except..." is a standard thing you ask users to do for debugging. However providing you separate the initial profile from the later tools it simply becomes make distroconfig [cp /etc/system-kconfig(.$ARCH?) .config make oldconfig] make menuconfig (if you want to customise) In addition the make oldconfig means you can ship a deliberately incomplete distroconfig and get the user asked some bits. make -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716180157.5f2d9...@pyramind.ukuu.org.uk
Bug#632187: megaraid vs i2o for PCI device ID 101e:1960
> Should this device be blacklisted from i2o_core? Are there likely other > MegaRAID devices that use the I2O PCI class but don't work with this > generic driver? I²O will probe I²O class devices. How well it works depends upon the firmware version of the specific board. The fix in this case is either updated firmware, or to go into the configuration for the board and turn off I2O support in the bios config. Alan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715154832.09647...@lxorguk.ukuu.org.uk
Bug#622997: libata-sff/pata_cmd64x problem with hardwired configurations
On Tue, 19 Apr 2011 13:50:12 +0200 Bartlomiej Zolnierkiewicz wrote: > On Tue, Apr 19, 2011 at 12:08 PM, Alan Cox wrote: > >> From: Bartlomiej Zolnierkiewicz > >> Subject: [PATCH v2] pata_cmd64x: add enablebits checking > >> > >> Fixes IDE -> libata regression. > > > > And causes a regression too > > Could you be more explicit? > > Regression in this patch would mean that old driver currently doesn't > work which is not true.. The old driver fails on some of the hot plug boxes because the enable bits don't seem to be valid. See the rest of the discussion on this thread Hence the comment I made about needing to also check the parent bridge Alan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110419132910.0c791...@lxorguk.ukuu.org.uk
Bug#622997: libata-sff/pata_cmd64x problem with hardwired configurations
> From: Bartlomiej Zolnierkiewicz > Subject: [PATCH v2] pata_cmd64x: add enablebits checking > > Fixes IDE -> libata regression. And causes a regression too With the check for parent bridge not being a split bridge I think however it'll do the job nicely. Alan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110419110838.3deaf...@lxorguk.ukuu.org.uk
Bug#504391: [PATCH] mmc: add module parameter to set whether cards are assumed removable
> Before we do suspend, pick few random sectors from the media, run that > through some hash function, thus creating some sort of watermark. Statistically speaking the chances are you'll catch zero sectors and lose. You'll also not detect the suspend, move to other box, use, put back error. That is one users make and we need to be at least vaguely robust against. Hence you need the fs checking here. Alan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504391: [PATCH] mmc: add module parameter to set whether cards are assumed removable
> You do not cater for having more than one slot e.g. N900 has two: > one internal non-removable and one external that is removable. > > What about a sysfs entry instead e.g. > > /sys/class/mmc-host/mmc*/nonremovable That continues the assumption that the user will somehow ever know about this stuff and configure it. Almost nobody will. Not only does it need to be per-port there needs to be a credible description of how it will automatically happen - who configures it, when, how and is the data needed available. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504391: [PATCH] mmc: add module parameter to set whether cards are assumed removable
> I'm afraid that's insufficient. What it would need to do is to is > flush everything (to make sure what's on disk matches what's in > memory), but also read back the filesystem on resume to verify that > nothing else modified it (i.e. making sure what's on disk still matches > what's in memory). For most file systems it is sufficient to check the superblock related information. So we'd need an fs->ops->validate_media() or somesuch but it wouldn't be that horrific or need to do much I/O in most cases. You could defeat that by being really stupid, but the purpose of the check isn't a stupidity filter but to stop accidents happening in normal use. > Another way of putting it is that the kernel needs to umount/mount > around suspend in a way that's transparent to users of the filesystem. No. The kernel needs to push stuff to media on suspend (which is good manners anyway), and validate on resume. if the validate fails you mark the media as changed and the block layer will already see to it that everything gets aborted as it already does with a truely removable device. In fact if you did this by media serial numbers and idents you don't even need the fs hook, although it would certainly be safer that way. Alan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#486798: [PATCH] restore export of handle_mm_fault for Mac on Linux
On Wed, 18 Jun 2008 12:14:02 +0200 Gaudenz Steinlin <[EMAIL PROTECTED]> wrote: > Hi > > The kernel modules for Mac on Linux (MOL) need handle_mm_fault. > MOL is a GPL licensed virtual machine to run MacOS(X) on PPC Linux. > > The export for handle_mm_fault was removed with commit > 41f9dc5c871600f53c8912b2975971d2a11c1c25. This sort of thing is going to happen if modules hide out of tree. If MOL is GPL why isn't it getting submitted to the kernel tree - other virtualisation subsystems such as KVM are in tree ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419482: Kernel 2.6.18 - ALI15X3 driver too optmistic about UDMA
> if (m5229_revision <= 0x20) {
> return 0;
> } else if ((m5229_revision < 0xC2) &&
So 0xC1 takes this path
> Looking back at the equivalent code in 2.4.27 (the previous kernel
> this machine ran), that's rather different:
>
> if (m5229_revision < 0xC1) {/* According to ALi */
> return 0;
> } else if ((m5229_revision < 0xC2) &&
And 0xC1 takes the same path.
> So it would seem there has been a regression here - the assumption now
> is that versions between 0x20 and 0xC1 can use UDMA fine unless there
> is a WDC drive attached, but the old code wouldn't try UDMA at all on
> chips older than rev C1.
There are no versions between 0x21 and 0xC0.
> I have the machine out and ready to experiment with if any more
> details are needed to help solve this problem.
Interesting report as we've had essentially no corruption reports
equivalent to this on common architectures for a long time and the
hardware is in a huge number of PC systems. Also UDMA transfers are CRC
protected by hardware at each end.
That makes me wonder if you have a platform or endian bug, or indeed your
firmware isn't setting up all the chipset as required by the ALi chipset
and BIOS documentation (which unfortunately is NDA)
Alan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340228: [PATCH, IDE] Blacklist CD-912E/ATK
> The drive is clearly broken. Adding blacklist to drivers/ide/ide-dma.c
> for this model ("CD-912E/ATK") fixes this problem.
That may be the case but knowing if th drive is the problem is more
tricky.
Firstly try it on a different controller
Secondly check for other firmware revisions
Thirdly blacklist only your firmware rev if there are others
> hdc: DMA disabled
> [ cut here ]
> kernel BUG at drivers/ide/ide-iops.c:949!
> invalid operand: [#1]
That is an IDE layer bug not a drive incompatibility. It may be one
triggered the other but until the BUG the kernel was correctly behaving
and had just turned off DMA anyway.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Llu, 2005-04-04 at 21:47, Jeff Garzik wrote: > Bluntly, Debian is being a pain in the ass ;-) > > There will always be non-free firmware to deal with, for key hardware. Firmware being seperate does make a lot of sense. It isn't going away but it doesn't generally belong in kernel now we have initrd and firmware loaders. Alan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
