Re: de-modularising for the win!

2008-10-03 Thread Peter Jones
Kyle McMartin wrote: On Fri, Oct 03, 2008 at 11:25:49AM -0400, Peter Jones wrote: Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch

Re: de-modularising for the win!

2008-10-03 Thread Peter Jones
Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch is on top of yours): diff --git a/config-generic b/config-generic index 0f43c42..de33831 100

Re: de-modularising for the win!

2008-09-18 Thread Peter Jones
Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch is on top of yours): diff --git a/config-generic b/config-generic index 0f43c42..de33831 1

Re: de-modularising for the win!

2008-09-18 Thread Peter Jones
Dave Jones wrote: On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote: > See various and sundry plumber's conf discussions. > > Comments? (The netfilter stuff needs further investigation.) looks like some of the lower-hanging fruit. definite room for further expansion. how well

Re: [PATCH] make sr_mod report more accurate drive status after closing the tray.

2008-07-11 Thread Peter Jones
So, what's happening here is that the drive is reporting a sense of 2/4/1 ("logical unit is becoming ready") from sr_test_unit_ready(), and then we ask for the media event notification before checking that result at all. The check_media_event_descriptor() call isn't getting a check condition,

Re: [PATCH] make sr_mod report more accurate drive status after closing the tray.

2008-07-11 Thread Peter Jones
James Bottomley wrote: On Thu, 2008-07-10 at 17:24 -0400, Peter Jones wrote: Right now, when using sr_mod and issuing the CDROM_DRIVE_STATUS ioctl, there's no way to differentiate between when you've just closed the drive tray, but the media is not yet loaded, and when there's

[PATCH] make sr_mod report more accurate drive status after closing the tray.

2008-07-10 Thread Peter Jones
o fix this behaviour: Signed-off-by: Peter Jones <[EMAIL PROTECTED]> diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c index ae87d08..43a084b 100644 --- a/drivers/scsi/sr_ioctl.c +++ b/drivers/scsi/sr_ioctl.c @@ -306,10 +306,9 @@ int sr_drive_status(struct cdrom_d

Re: Patch to arch/x86/mm/init_32.c causes EFI-32 machines to reboot early in startup

2008-07-02 Thread Peter Jones
Hugh Dickins wrote: On Wed, 2 Jul 2008, Peter Jones wrote: The inline patch works, thanks! Oh, that's good news, thank you! I'll write a better description and send it off to Linus and Ingo for 2.6.26 now. I'll say "Fedora reports..." and say "Tested-by:

Re: Patch to arch/x86/mm/init_32.c causes EFI-32 machines to reboot early in startup

2008-07-02 Thread Peter Jones
Hugh Dickins wrote: Does a CONFIG_SMP=n kernel boot okay with EFI? I'd expect it to suffer from the same problem, and it just hasn't been tried because you've got 2 or more cores on those machines? But confirmation or denial would be interesting. Well, it hasn't been tried with CONFIG_SMP=n

Patch to arch/x86/mm/init_32.c causes EFI-32 machines to reboot early in startup

2008-07-01 Thread Peter Jones
Hi. Using git bisect, I've discovered that commit 61165d7a035f6571c7576e7f51e7230157724c8d is the cause of 32-bit Intel Mac machines to reboot very early during startup when booting with EFI (but not if using BIOS). The last change in that commit is: diff --git a/arch/x86/mm/init_32.c b/arch

Re: revisit: turning some of the "always used" modules to built-in

2008-06-24 Thread Peter Jones
Dave Jones wrote: On Sun, Jun 22, 2008 at 11:42:18AM -0700, Arjan van de Ven wrote: > Category 1: Always loaded anyway > > Rationale: Since we load these always anyway, why bother making it modules > - ata_generic, pata_acpi These ones make me hrmm a bit.

[PATCH] Merge the IMAC mode code with efifb and remove imacfb entirely.

2008-03-24 Thread Peter Jones
This mail contains a patch which merges the IMAC mode code into the efifb driver and removes the imacfb driver entirely. There are also a couple of minor bug fixes. Any comments before I start bothering the upstream maintainers with it? --- drivers/video/Kconfig | 15 +-- drivers/video/Makef

Re: kernel posttrans and preun hooks for other packages

2008-02-18 Thread Peter Jones
Peter Jones wrote: (Adding Panu to the Cc) Jason L Tibbitts III wrote: "MD" == Matt Domsch <[EMAIL PROTECTED]> writes: MD> [...] there's no ordering guarantee between the two such that we MD> know kernel-devel is always installed before kernel. It should be po

Re: kernel posttrans and preun hooks for other packages

2008-02-18 Thread Peter Jones
(Adding Panu to the Cc) Jason L Tibbitts III wrote: "MD" == Matt Domsch <[EMAIL PROTECTED]> writes: MD> [...] there's no ordering guarantee between the two such that we MD> know kernel-devel is always installed before kernel. It should be possible to have kernel-devel have Requires(post): ker

Re: kernels won't boot

2008-01-03 Thread Peter Jones
David Zeuthen wrote: On Sat, 2007-12-22 at 08:28 -0500, Steve Grubb wrote: On Saturday 22 December 2007 07:16:32 Build System wrote: kernel-2.6.24-0.123.rc6.fc9 --- * Fri Dec 21 2007 David Woodhouse <[EMAIL PROTECTED]> - Disable CONFIG_PS3_USE_LPAR_ADDR to fix PS3 memory

Re: CONFIG_USB_SUSPEND

2007-06-20 Thread Peter Jones
Bill Nottingham wrote: Dave Jones ([EMAIL PROTECTED]) said: > Of course, upstream doesn't seem all that inclined[1] to make it so that > devices can actually work. *sigh* Adding udev callouts as he suggests shouldn't be difficult though should it? You don't want udev callouts that simpl

Re: kmods poll

2007-06-20 Thread Peter Jones
David Woodhouse wrote: And if it isn't good enough for upstream to ship and support, why in $DEITY's name would we want to ship it, again? From http://fedoraproject.org/wiki/Objectives : * To be on the leading edge of free and open source technology, by adopting and helping develop new featu