Re: [linux-usb-devel] Re: 2.6.13-rc4-mm1

On Sun, Jul 31, 2005 at 11:25:10AM -0700, david-b <at> pacbell.net wrote:
> I think that "continuing" codepath came from someone at Phoenix, FWIW;
> the problem is that I see the PCI quirks code has evolved even farther
> from the main copy of the init code in the USB tree.  Sigh.

I don't like that either, but can't think of a way to make it easier to
keep them in sync.  Can you?

thanks,

greg k-h

Re: revert yenta free_irq on suspend

Hi!

> > In general, I think that calling free_irq is the right behavior.
> 
> I DO NOT CARE!
> 
> It breaks hundreds of drivers. End of discussion.
> 
> You can do the free_irq() and request_irq() changes _without_ breaking 
> hundreds of drivers by just doing one driver at a time. 
> 
> And if ACPI then restores the irq controller state, the drivers that 
> _don't_ do this will _also_ continue to work.
> 
> Let me re-iterate: the ACPI changes provably BROKE REAL PEOPLES SETUPS. 
> 
> For absolutely _zero_ gain. Drivers that want to free and re-aquire an 
> interrupt can do so _regardless_ of whether ACPI restores irq routings 
> automatically or not.
> 
> And that's my argument. We don't do stupid things that break peoples 
> existing setups in ways that nobody can debug. 

Ok, so we'll keep adding those free_irq/request_irq pairs, and
re-introduce that ACPI change when we are ready? It would be helpfull
to keep the "right thing" in -mm, so there's real motivation to add
free_irq/request_irq.
								Pavel
--

-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: [2.6 patch] remove support for gcc < 3.2

Hi.

On Mon, 2005-08-01 at 08:36, David S. Miller wrote:
> Many people still use 2.95 because it's still the fastest
> way to get a kernel build done and that's important for
> many people.

Yes, please don't remove 2.95 support.

Regards,

Nigel
--

-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

Re: revert yenta free_irq on suspend

> >
> > In general, I think that calling free_irq is the right behavior.
> 
> I DO NOT CARE!
> 
> It breaks hundreds of drivers. End of discussion.
> 
> You can do the free_irq() and request_irq() changes _without_ breaking
> hundreds of drivers by just doing one driver at a time.
> 

So are driver writers supposed to start accepting patches to
free/request irqs? in a sense of making it all go forward so at some
point we can switch over to doing the correct thing? but my patch for
yenta breaks setups for some strange reason..... (maybe just APM
ones..)

If so we should put the patch to break links into -mm and then start
fixing up drivers...

Dave.

Re: Power consumption HZ100, HZ250, HZ1000: new numbers

In article <20050731223247.GA27580 <at> elf.ucw.cz> you wrote:
> No, I'm saying that 99% users enable ACPI and cpufreq. ACPI is needed
> on new machines, and cpufreq is usefull to keep your desktop cold,
> too.

And with the recent ongoing packing of CPU cores into racks, it is even more
so important for Servers.

Gruss
Bernd

Re: Power consumption HZ100, HZ250, HZ1000: new numbers

On Mon, 2005-08-01 at 00:47 +0200, Pavel Machek wrote:
> I'm pretty sure at least one distro will go with HZ<300 real soon now
> .
> 

Any idea what their official recommendation for people running apps that
require the 1ms sleep resolution is?  Something along the lines of "Get
bent"?

Lee

Re: revert yenta free_irq on suspend

On Mon, 1 Aug 2005, Pavel Machek wrote:
> 
> Ok, so we'll keep adding those free_irq/request_irq pairs

I would suggest doing so only if you have a case where it can matter.

> and re-introduce that ACPI change when we are ready?

Why do it _ever_? There is _zero_ upside to doing it, I don't see why you 
want to.

Just make ACPI restore the dang thing. It's the right thing to do.

			Linus

Re: revert yenta free_irq on suspend

Hi!

> > Ok, so we'll keep adding those free_irq/request_irq pairs
> 
> I would suggest doing so only if you have a case where it can matter.
> 
> > and re-introduce that ACPI change when we are ready?
> 
> Why do it _ever_? There is _zero_ upside to doing it, I don't see why you 
> want to.

Being able to turn off your soundcard at runtime when you are not
using it was one of examples...

> Just make ACPI restore the dang thing. It's the right thing to do.

Requires interpretter running with interrupts disabled => ugly .

								Pavel
--

-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: Power consumption HZ100, HZ250, HZ1000: new numbers

Hi!

> > I'm pretty sure at least one distro will go with HZ<300 real soon now
> > .
> > 
> 
> Any idea what their official recommendation for people running apps that
> require the 1ms sleep resolution is?  Something along the lines of "Get
> bent"?

So you busy wait for 1msec, big deal. Some machines can't even keep
time properly with HZ=1000. Official recommendation is likely "help us
with CONFIG_NO_IDLE_HZ" or "get over it".
								Pavel
--

-- 
if you have sharp zaurus hardware you don't need... you know my address

[git patch] libata fix

Please pull from the 'upstream-fixes' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

to obtain the damnable-annoying[1] fix described in the attached 
diffstat/changelog/patch.

	Jeff

[1] the option is truly a boolean, that enables or disables a menu (not 
any code).  But it won't work as a boolean apparently :/  Roman doesn't 
have any better suggestions, so oh well.

 drivers/scsi/Kconfig |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

commit faa725332f39329288f52b7f872ffda866ba5b09
Author: Adrian Bunk <bunk <at> stusta.de>
Date:   Wed Jul 27 01:06:35 2005 -0700

    [PATCH] SCSI_SATA has to be a tristate

    SCSI=m must disallow static drivers.

    The problem is that all the SATA drivers depend on SCSI_SATA.

    With SCSI=m and SCSI_SATA=y this allows the static enabling of the SATA
    drivers with unwanted effects, e.g.:
    - SCSI=m, SCSI_SATA=y, SCSI_ATA_ADMA=y