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
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
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
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
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,
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
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
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:
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
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
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.
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
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
(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
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
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
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
17 matches
Mail list logo