Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

2001-05-21 Thread Dave Jones

On Mon, 21 May 2001, Steven Walter wrote:

  Any particular reason this needs to be done in the kernel, as opposed
  to having your script read /dev/cpu/*/cpuid?
 Wouldn't that be the same reason we have /anything/ in cpuinfo?

When /proc/cpuinfo was added, we didn't have /dev/cpu/*/cpuid
Now that we do, we're stuck with keeping /proc/cpuinfo for
compatability reasons.

regards,

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

2001-05-22 Thread Dave Jones

On Tue, 22 May 2001, David Weinehall wrote:

   Wouldn't that be the same reason we have /anything/ in cpuinfo?
  When /proc/cpuinfo was added, we didn't have /dev/cpu/*/cpuid
  Now that we do, we're stuck with keeping /proc/cpuinfo for
  compatability reasons.

 AFAIK, not all processors support cpuid.

Fair point, but as there was limited information available
from the CPU, the likelyhood of /proc/cpuinfo getting
extended further is somewhat unlikely.
Moreso if the feature can be accomplished equally as well
in userspace (Like the original post in this thread).


regards,

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

2001-05-22 Thread Dave Jones

On Wed, 23 May 2001, Tomas Telensky wrote:

  Any particular reason this needs to be done in the kernel, as opposed
 It is already done in kernel, because it's displaying :)
 So, once evaluated, why not to give it to /proc/cpuinfo. I think it makes
 sense and gives it things in order.

Displaying at boottime only means the function can be marked as initcode,
and freed after usage. Putting it in proc/cpuinfo means we use up
kernel space that can't be freed.

regards,

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

2001-05-22 Thread Dave Jones

On Wed, 23 May 2001, Tomas Telensky wrote:

 Yes. Recently I tried to transform whole cpuid code to a userspace
 utility. Not easy, not clean... but it worked.

See http://www.sourceforge.net/projects/x86info
or ftp://ftp.suse.com/pub/people/davej/x86info/

regards,

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

2001-05-22 Thread Dave Jones

On Wed, 23 May 2001, Martin Knoblauch wrote:

  They may not be stupid, just mislead :-( When Intel created the cpuid
 Feature some way along the P3 line, they gave a stupid reason for it and
 created a big public uproar. As silly as I think that was (on both
 sides), the term cpuid is tainted. Some people just fear it like hell.
 Anyway.

I think you are confusing the CPU serial number with CPUID which is
not the same. CPUID instruction has been around since late 486en.

The P3 Serial number is still disabled by default in Linux,
unless overridden with a boottime switch.

regards,

Davej.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: ServerWorks LE and MTRR

2001-04-29 Thread Dave Jones

On Sun, 29 Apr 2001, Steffen Persvold wrote:

 ...
 Therefore please consider my small patch to allow the
 good ones to be able to use write-combining. I have several rev 06 and they are
 working fine with this patch.
 ...

ObPedant:
 Can you make a note of this in the comment a few lines above also,
so others who stumble across this code know why the check is there.
afaik, this chipset info isn't public, so it may not be obvious
in the future why the check has been added.

Just something simple like..

-/* ServerWorks LE chipsets have problems with  write-combining
+/* ServerWorks LE chipsets  rev 6 have problems with write-combining
   Don't allow it and  leave room for other chipsets to be tagged */


Otherwise, if this works for everyone else with rev 6+ serverworks
chipsets, looks ok to me.

regards,

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Changing CPU Speed while running Linux

2001-06-13 Thread Dave Jones

On Wed, 13 Jun 2001, Magnus Sandberg wrote:

 I have a brand new Dell Inspiron 8000, laptop. It can run in 700 MHz or
 850 MHz. The manual says that the machine/BIOS switches speed dependent on
 CPU load. I have not installed Linux yet, but it works with Win2000.

Intel Speedstep iirc. My Vaio also has it. My findings so far:

On mains it runs at 700MHz, whilst on batteries it drops to ~550MHz.
If I boot an ACPI enabled kernel, the speed changes according to CPU
load, but with a smaller window. I've seen it go as low as 50MHz,
but only up to a maximum of 200MHz.   The fact that it only has a maximum
of 200MHz in this mode probably explains the need for the no-idle switch
in the current ACPI implementation.

As there are no public documents on Speedstep, it's not clear to me
whether this is a limitation of Speedstep, or the ACPI implementation.
Judging by the fact that Windows seems to run at full speed, I'd
be inclined to think the latter.

regards,

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



RE: ACPI fundamental locking problems

2001-07-03 Thread Dave Jones

On Tue, 3 Jul 2001, Grover, Andrew wrote:

 We're depending on vendors (aka the BIOS) for all the ACPI tables, as well
 as every other piece of a priori data we need to boot the OS.

And this is the part that I find terrifying.
The minute we rely on BIOS vendors, they seem to find wonderful new
ways to screw things up royally.

 Could I please ask that you at least show me a system where this is a
 problem before throwing out all the work we've done on ACPI because of this
 technical nit?

Currently, with what we extract from BIOS space, we can
blacklist/whitelist according to DMI entries. With ACPI providing AML
code that's executed in kernel space, there's no telling what could
happen.

The whole black box, you don't need to know how this works, just call it
approach is scary. With ACPI having access to IDE taskfile commands, the
possibilities for all sorts of evil exist. Just when we thought the CPRM
nightmare was over, we have the BIOS feeding us IDE commands to throw
at drives with vendors telling us Trust it, it's ok, really.

Maybe I'm overly paranoid, but I'm sure I'm not the only one who feels
this way.

regards,

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: P-III Oddity.

2001-04-07 Thread Dave Jones

On Sat, 7 Apr 2001, Rogier Wolff wrote:

 One machine regularly crashes.
 Linux version 2.2.16-3 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 
19990314/Linux (egcs-1.1.2 release)) #1 Mon Jun 19 19:11:44 EDT 2000

Probably unrelated to the issue below. Try a more recent 2.2 ?

 cpuid level : 2

CPU serial number disabled.

 cpuid level : 3

CPU serial number enabled.


You should be able to confirm this with my x86info tool.
ftp://ftp.suse.com/pub/people/davej/x86info/x86info-1.0.tgz

If this isn't the case, can you send me the output of
x86info -a on both CPUs ?

Note, that 2.4 should be disabling the serial number by
default.
(Unless you booted with the `serialnumber' bootarg.)

regards,

Dave.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: P-III Oddity.

2001-04-07 Thread Dave Jones

On Sat, 7 Apr 2001, Trevor Hemsley wrote:

 I've got this on my dual processor P-III 600MHz. One of the cpus in
 this box reports cpuid level 2, the other 3. Serial number is disabled
 in the BIOS.

Interesting, the cpu serial number isn't being disabled on the
2nd CPU. Most odd. Well, we disable reporting that it's available,
but it looks like it still remains possible to get at it.

I'll dig some more tomorrow morning.

Dave.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: CML2 1.0.0 release announcement

2001-04-11 Thread Dave Jones

On Wed, 11 Apr 2001, Christoph Hellwig wrote:

  CML2 takes around 15 seconds before I get that far.
  This is on an Athlon 800 w/512MB. I dread to think how this
  responds on a 486.

 If you look for something _even_ faster try mconfig.  For everyone who is
 interested, I've put my latests half-way stable version is on ftp.  It's at
   ftp.openlinux.org:/pub/people/hch/mconfig/mconfig-0.19-pre1.tar.gz
 Props for all the hard work go to Michael Elizabeth Chastain!

This is the first I've heard of mconfig. (I don't track the kbuild list)
Does it solve all the problems that Eric's solution proposes?
It's certainly fast (CML1 menuconfig speed at least).

regards,

Dave.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

2001-04-12 Thread Dave Jones

On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote:

 Unfortunately, I'm fairly sure that finishing gcml would take long
 enough to render the point moot, because by the time it was done the
 average Linux machine would have sped up enough for the Python
 implementation not to be laggy anymore :-).

'Average' Linux machine is irrelevant. I still have a Sparc IPX
I occasionally use. I know people using still using 486's as they
can't afford anything better. Hell, even some of my P5 class machines
are starting to show their age, but they're still in daily use.
To say "Screw them, upgrade" is not an option IMO.

 I'm pretty sure that tuning the Python implementation (coming up with
 faster algorithms, perhaps by reorganizing the data structures to do
 more precomputation) will be a more effective use of my time.

Well if you can make this run faster, this would kill my main
complaint with CML2.  I'll try out an updated version sometime.

regards,

Davej.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

2001-04-12 Thread Dave Jones

On Thu, 12 Apr 2001, Steven Cole wrote:

 Excuse me, but this seems to be something of a red herring.
 ...
  Adding seconds or tens of seconds at this time on 2001 hardware will
 seem very moot by the time 2.5/2.6 is at the point 2.4.x is now.

Adding tens of seconds per build is not acceptable when you're building
a lot of kernels each day.

The beginning of this thread showed a 15 second stall on an Athlon 800,
vs a 1 second startup for the old system. The point now is that
Eric _is_ working on improving the performance. (Which was probably
in another post you missed).

 If you haven't seen my posts here before, I just joined this list last night.

Find a list archive, read the beginning of the thread.

regards,

Dave.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [2/2] 2.6.21-rc7: known regressions

2007-04-15 Thread Dave Jones
On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote:

  Subject: ThinkPad X60: resume no longer works  (PCI related?)
   workaround: booting with hpet=disable
  References : http://lkml.org/lkml/2007/3/13/3
  Submitter  : Dave Jones [EMAIL PROTECTED]
   Jeremy Fitzhardinge [EMAIL PROTECTED]
  Caused-By  : PCI merge
   commit 78149df6d565c36675463352d0bfeb02b7a7
  Handled-By : Eric W. Biederman [EMAIL PROTECTED]
   Rafael J. Wysocki [EMAIL PROTECTED]
  Status : unknown

note that this workaround doesn't seem to work in all cases.
Mine may a slightly different model (I have the tablet version)
but disabling hpet shows the same regression.
I've been fighting Eric's USB debug cable code in the hope
of getting _something_ useful out of it other than a black screen,
but I've been getting nowhere with it.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: BUG: Bad page state errors during kernel make

2007-04-15 Thread Dave Jones
On Sun, Apr 15, 2007 at 08:30:27PM -0700, Zach Carter wrote:

  Console Messages:
  Bad page state in process 'cc1'
  page:c1ca88e8 flags:0x5200 mapping:c100 mapcount:0 count:0
  Trying to fix it up, but a reboot is needed
  Backtrace:
[c015625d] bad_page+0x5e/0x89
[c0156ab1] get_page_from_freelist+0x1de/0x298
[c0156bd3] __alloc_pages+0x68/0x2aa
[c016322a] anon_vma_prepare+0x20/0xb8
[c0129647] tasklet_action+0x4b/0xa4
[c015e336] __handle_mm_fault+0x3b2/0x88f
[c0116dce] smp_apic_timer_interrupt+0x6e/0x7a
[c01380d7] hrtimer_run_queues+0x138/0x152
[c0315e4a] do_page_fault+0x23f/0x53c
[c0315c0b] do_page_fault+0x0/0x53c
[c031488c] error_code+0x7c/0x84
===
  list_del corruption. prev-next should be c21a4628, but was e21a4628

'c' became 'e' in that last address. A single bit flipped.
Given you've had this for some time, this smells like a hardware problem.
memtest86+ will probably show up something.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: BUG: Bad page state errors during kernel make

2007-04-15 Thread Dave Jones
On Sun, Apr 15, 2007 at 10:31:38PM -0700, Zach Carter wrote:
  
  Dave Jones wrote:
   On Sun, Apr 15, 2007 at 08:30:27PM -0700, Zach Carter wrote:
 list_del corruption. prev-next should be c21a4628, but was e21a4628
   
   'c' became 'e' in that last address. A single bit flipped.
   Given you've had this for some time, this smells like a hardware problem.
   memtest86+ will probably show up something.
  
  Hum.   I forgot to mention in my report that I had already run thru 10 clean 
  passes with memtest86+
  
  Do you think there might be other bad hw, or another explanation?

Maybe.  I've seen underpowered PSUs, bad motherboard capacitors, and
even poor ventilation caused by clogged fans causing similar bugs.

It could also actually be a software fault, but it's surprising that
you hit it so easily, for so long, and no-one else seems to be
equally as affected.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2/2] 2.6.21-rc7: known regressions

2007-04-16 Thread Dave Jones
On Mon, Apr 16, 2007 at 03:16:37AM +0200, Adrian Bunk wrote:
  On Sun, Apr 15, 2007 at 08:54:46PM -0400, Dave Jones wrote:
   On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote:
   
 Subject: ThinkPad X60: resume no longer works  (PCI related?)
  workaround: booting with hpet=disable
 References : http://lkml.org/lkml/2007/3/13/3
 Submitter  : Dave Jones [EMAIL PROTECTED]
  Jeremy Fitzhardinge [EMAIL PROTECTED]
 Caused-By  : PCI merge
  commit 78149df6d565c36675463352d0bfeb02b7a7
 Handled-By : Eric W. Biederman [EMAIL PROTECTED]
  Rafael J. Wysocki [EMAIL PROTECTED]
 Status : unknown
   
   note that this workaround doesn't seem to work in all cases.
   Mine may a slightly different model (I have the tablet version)
   but disabling hpet shows the same regression.
   I've been fighting Eric's USB debug cable code in the hope
   of getting _something_ useful out of it other than a black screen,
   but I've been getting nowhere with it.
  
  I'm not sure why I thought you two ran into the same regression.

I'm not sure why I never hit the same bug that Jeremy did
(again, maybe subtle hardware differences between our models),
but I finally got somewhere.   -rc7 with the same config I've
been testing exhibited exactly the same bug.   Disabling
the FB_BACKLIGHT option (and all the FB drivers that 'select' it),
I get a working display on resume again.

This makes a lot of sense. As before, when I resumed, the backlight
wasn't coming back on, but I knew the machine was alive, as
capslock was working.  (Amusingly, I never noticed the backlight
wasn't coming back on until tonight, when I started debugging this
with the lights off.  Late-night debugging ftw).

I'll try and narrow down exactly where it's failing in the
backlight code next, but it's getting late here, so I may
leave this until tomorrow for further investigation.
Some other clues for anyone playing along at home:
This X60 has Intel graphics.  ie, I'm not using any of
the drivers that 'select FB_BACKLIGHT', so somewhere in
the common fb code is code that I'm guessing is dependant
upon the framebuffer driver doing something or other
if FB_BACKLIGHT is set.

(Adding Richard to Cc: as he seems to be responsible for
 the FB backlight code from what I can tell.)

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2/2] 2.6.21-rc7: known regressions

2007-04-16 Thread Dave Jones
On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote:
 
  CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is
  enabled by FB_BACKLIGHT. So we can narrow it down further, can you try?
  
  CONFIG_FB_BACKLIGHT=y
  CONFIG_ACPI_VIDEO=n

That also gets me a dead display. Backlight doesn't turn back on.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2/2] 2.6.21-rc7: known regressions

2007-04-16 Thread Dave Jones
On Mon, Apr 16, 2007 at 03:32:02PM +0800, Antonino A. Daplas wrote:
  On Mon, 2007-04-16 at 03:23 -0400, Dave Jones wrote:
   On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote:

 CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is
 enabled by FB_BACKLIGHT. So we can narrow it down further, can you try?
 
 CONFIG_FB_BACKLIGHT=y
 CONFIG_ACPI_VIDEO=n
   
   That also gets me a dead display. Backlight doesn't turn back on.
  
  Anything under /sys/class/backlight?

Entries from ibm_acpi.  I rmmod'd that, leaving the dir empty,
and it still fails.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2/2] 2.6.21-rc7: known regressions

2007-04-16 Thread Dave Jones
On Mon, Apr 16, 2007 at 10:26:43AM +0100, Richard Purdie wrote:

CONFIG_FB_BACKLIGHT=y
CONFIG_ACPI_VIDEO=n
  
  That also gets me a dead display. Backlight doesn't turn back on.
 
 Anything under /sys/class/backlight?
   
   Entries from ibm_acpi.  I rmmod'd that, leaving the dir empty,
   and it still fails.
  
  What happens if you never load ibm-acpi?

Same thing. No backlight on resume.
I rm'd the .ko, so there's no chance it got loaded.

  I'm a bit puzzled as CONFIG_FB_BACKLIGHT doesn't do anything with the
  intelfb driver. One thing it does do is set
  CONFIG_BACKLIGHT_CLASS_DEVICE. When you disabled FB_BACKLIGHT and got a
  working display on resume, was that set and was (or had) ibm-acpi been
  loaded?
  
  A variety of other options such as ACPI_IBM also set
  CONFIG_BACKLIGHT_CLASS_DEVICE although without a backlight driver it
  will do nothing hence the suspicion is on ibm-acpi, perhaps interacting
  with the backlight class badly.
  
  Does echoing numbers to /sys/class/backlight/ibm_acpi/brightness change
  the backlight brightness as expected?

/sys/class/backlight/ibm/brightness takes a value from 0 to 7.
Starts off with a default of 0. I tried all values in there, and
it made no visible difference.  But as the no-backlight thing happens
without this even loaded, I think this is a separate problem.

  If you can ssh into the machine
  after its resumed with the display problem, it would be interesting to
  know what the brightness was and if changing it helped too...

When the backlight doesn't come on, for some reason, nothing else
runs.  Capslock works, so it's at least partially alive, but even
doing..

echo mem  /sys/power/state ; echo foo /bar ; sync

results in no /bar being created.
Ethernet remains down when its in this state too.

It's the reason it's taken this long to get any debug info out of it at all.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


drivers/video/output.c

2007-04-17 Thread Dave Jones
commit 2dec3ba8d872aa3ffbcdb8f6f8a2c0bcd44e9910 puzzles me.

git-bisect just fingered it as responsible for my backlight doesn't turn on
suspend/resume regression on the Thinkpad X60.  I think it's lying.

Why?  Because afaict, drivers/video/output.c is never compiled.
That commit adds the driver, but doesn't touch any Makefile, and I
don't see anything obvious in the follow-in commits that would 'enable' it.

Asides from git-bisect failing me again[1], what gives with this file?

Dave

[1] bisecting suspend regressions _really_ sucks.  Each time I've tried this
I've found 2-3 different ways we regressed along the bisection, making it
hard to say good or bad when the answer is bad, but broken differently

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2/2] 2.6.21-rc7: known regressions

2007-04-17 Thread Dave Jones
On Wed, Apr 18, 2007 at 07:48:55AM +0800, Antonino A. Daplas wrote:

   When the backlight doesn't come on, for some reason, nothing else
   runs.  Capslock works, so it's at least partially alive, but even
   doing..
   
   echo mem  /sys/power/state ; echo foo /bar ; sync
   
   results in no /bar being created.
   Ethernet remains down when its in this state too.
  
  Have you tried these boot options?
  
  acpi_sleep=s3_mode; or
  acpi_sleep=s3_bios,s3_mode

Yeah, did nothing. I also tried acpi_sleep=s3_bios on its own.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


mkinitrd. (was Re: [RFC] [PATCH] Allow overriding module parameters from kernel command_line)

2007-04-18 Thread Dave Jones
On Thu, Apr 19, 2007 at 08:47:13AM +1000, Neil Brown wrote:
 
   Fixed by changing /etc/fstab and rebuilding initrd, but IMO rootfstype=
   should have worked.
  
  I think these are both issues that should be solved by smarts in the
  initrd.

This is getting away from the intent of Kyle's original patch
(Which I think is worthwhile fwiw, having recently hit the exact
 same sata_nv bug that prompted him to write it)

  What we really need is a single reference implementation of mkinitrd
  which each distro can fiddle with to their heart's content.  Then
  sensible ideas like the above can be incorporated into the reference,
  and all distros will ultimately pick them up.
  
  But unfortunately I don't have the time to volunteer for this role...

The problem I see with such a 'one mkinitrd to rule them all', is that
it would suffer from the same thing that stopped any vendor stepping
up and getting behind hpa's klibc project...  Apathy due to our current
stuff works, why would we throw it all away and start again

It's a great idea in theory, in practise however, initrd construction
for every distro now contains years of custom hacks and workarounds
(that may not even be relevant on other distros).

Given the critical nature of mkinitrd (get something wrong, and your
system doesn't boot), unsurprisingly, people are reluctant to change
away from something they're familar with, unless there's a *really*
compelling reason.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Kill off legacy power management stuff.

2007-04-18 Thread Dave Jones
On Wed, Apr 18, 2007 at 05:23:15PM -0400, Len Brown wrote:

   p.p.s.  patch improvements that will let me avoid doing any of that
   myself always welcome. :-)
  
  well, I'm sorry that I've known about the APM issue for a long time
  and done nothing about it.  I did ping davej when he broke it,
  but his to-do list is probably even longer than mine.

ping timeout.

I don't recall too many of the details surrounding those changes,
but I certainly won't stand in the way of anyone trying to fix it.
It sounds like you and Robert are on top of it, or do you want
me to poke at it ?

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2/2] 2.6.21-rc7: known regressions

2007-04-19 Thread Dave Jones
On Thu, Apr 19, 2007 at 09:57:15PM -0700, Jeremy Fitzhardinge wrote:
  Adrian Bunk wrote:
   Subject: ThinkPad X60: resume no longer works  (PCI related?)
workaround: booting with hpet=disable
   References : http://lkml.org/lkml/2007/3/13/3
   Submitter  : Dave Jones [EMAIL PROTECTED]
Jeremy Fitzhardinge [EMAIL PROTECTED]
   Caused-By  : PCI merge
commit 78149df6d565c36675463352d0bfeb02b7a7
   Handled-By : Eric W. Biederman [EMAIL PROTECTED]
Rafael J. Wysocki [EMAIL PROTECTED]
   Status : unknown
 
  
  OK. 2.6.21-rc7 suspend/resume works perfectly for me.  It's the first
  kernel version in a long time.  I have no workarounds or special boot
  options.  It's using hpet as the clocksource.

Do you have the backlight code enabled ?
I'm guessing not.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2/2] 2.6.21-rc7: known regressions

2007-04-19 Thread Dave Jones
On Thu, Apr 19, 2007 at 10:15:48PM -0700, Jeremy Fitzhardinge wrote:
  Dave Jones wrote:
   Do you have the backlight code enabled ?
   I'm guessing not.
 
  
  Hm, think so.  backlight controls work, via both
  /proc/acpi/ibm/backlight and /sys/class/backlight/*/brightness.
  
  $ ls -l /sys/class/backlight/
  total 0
  drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video0
  drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video1
  drwxr-xr-x 2 root root 0 Apr 19 22:13 ibm

Hmm, given you hit the hpet problems and I didn't I think our X60's
aren't quite so similar.  Mine is the one with the swivelly touchscreen
tablet-pc mode. I understand they made a regular 'laptop' X60 too,
is that the one you have perhaps?

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2/2] 2.6.21-rc7: known regressions

2007-04-20 Thread Dave Jones
On Thu, Apr 19, 2007 at 10:33:39PM -0700, Jeremy Fitzhardinge wrote:
  Dave Jones wrote:
   Hmm, given you hit the hpet problems and I didn't I think our X60's
   aren't quite so similar.  Mine is the one with the swivelly touchscreen
   tablet-pc mode. I understand they made a regular 'laptop' X60 too,
   is that the one you have perhaps?
  
  Yes, mine is a normal laptop X60.  Still, its hard to imagine how they
  could be very different; same CPU, same chipset, same graphics.  The
  main difference is that your's has a Wacom tablet, presumably attached
  to USB.
  
  Details attached. How does it compare to your machine?

-1142MB HIGHMEM available.
+118MB HIGHMEM available.

So you have more RAM than I do :)

-NX (Execute Disable) protection: active

You enabled PAE, I didn't..
(Though I have tried both, makes no difference)

 DMI present.
+Using APIC driver default

Hmm.

 ACPI: RSDP 000F67B0, 0024 (r2 LENOVO)
-ACPI: XSDT 7F6D1896, 008C (r1 LENOVO TP-7B2060  LTP0)
-ACPI: FACP 7F6D1A00, 00F4 (r3 LENOVO TP-7B2060 LNVO1)
+ACPI: XSDT 3F6D12F5, 008C (r1 LENOVO TP-7J1050  LTP0)
+ACPI: FACP 3F6D1400, 00F4 (r3 LENOVO TP-7J1050 LNVO1)

BIOS differences (lots of these)

-Allocating PCI resources starting at 8800 (gap: 8000:7000)
+Allocating PCI resources starting at 5000 (gap: 4000:b000)

Probably due to the RAM differences shuffling the memmap.

-Kernel command line: ro root=LABEL=/ acpi_sleep=s3_bios combined_mode=libata
+Kernel command line: ro root=/dev/VolGroup00/LogVol00 profile=1

Hmm. I tried..
acpi_sleep=s3_bios
acpi_sleep=s3_mode
acpi_sleep=s3_bios,s3_mode
all did nothing for me.

-CPU: After all inits, caps: bfe9fbff 0010  2940 c1a9 
 
+CPU: After all inits, caps: bfe9f3ff 0010  2940 c1a9 
 

Probably PAE

-CPU0: Intel Genuine Intel(R) CPU   T2400  @ 1.83GHz stepping 08
+CPU0: Intel(R) Core(TM) Duo CPU  L2400  @ 1.66GHz stepping 0c

slightly different CPU, but probably not enough to make any difference.

-BUG: at arch/i386/kernel/sched-clock.c:170 init_sched_clock()
- [c01091b5] show_trace_log_lvl+0x1a/0x30
- [c010980c] show_trace+0x12/0x14
- [c01098cb] dump_stack+0x16/0x18
- [c0468dbd] init_sched_clock+0x58/0x9b
- [c0461502] init+0x14b/0x241
- [c0108d97] kernel_thread_helper+0x7/0x10
- ===

heh, one for Ingo :)

-ACPI: ACPI Dock Station Driver 
-ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: found ejectable bay
-ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: Adding notify handler
-ACPI: Bay [\_SB_.PCI0.IDE0.PRIM.MSTR] Added

Hmm, I should try without the dock stuff built.

-PCI: Using MMCONFIG
+PCI: PCI BIOS revision 2.10 entry at 0xfd82b, last bus=24
+PCI: Using configuration type 1

Think I've tried with and without MMCONFIG

-pnp: PnP ACPI: found 11 devices
+pnp: PnP ACPI: found 13 devices

My Wacom tablet is one of them. There's also a mysterious 13th device :)

 ibm_acpi: IBM ThinkPad ACPI Extras v0.13
 ibm_acpi: http://ibm-acpi.sf.net/
-ibm_acpi: ThinkPad EC firmware 7BHT37WW-1.10
+ibm_acpi: ThinkPad EC firmware 7JHT12WW-1.03

possibly just because of the touchscreen.

So most of the differences seem to be BIOS/firmware rather than hardware. 
The PCI bus layout is identical for eg.

Looking at your .config, I notice that you don't have CONFIG_FB_BACKLIGHT set
(because you don't have any framebuffer drivers that use it enabled).
Can you enable say.. CONFIG_FB_RADEON=m and CONFIG_FB_RADEON_BACKLIGHT=y
(which should turn on CONFIG_FB_BACKLIGHT=y by dependancy), and see if
it stops working for you? (You don't even need to load radeonfb.ko, just
have it compiled).

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: AGPGart / AMD K7

2007-04-20 Thread Dave Jones
On Fri, Apr 20, 2007 at 03:10:45AM -0400, Preston A. Elder wrote:
 
  I have a Tyan Thunder K7x Pro (S2469) and the amd-k7-agp module does not
  seem to be probing my AGP device.  I have even tried putting debugging
  code into the amd-k7-agp module, and sure enough I can see it being
  loaded, but the probe function is never called.  This is with kernel 2.6.19.

This is the second report of this I've heard, and I really have no good
explanation for it.

  As you can see, the first device is indeed showing up as AGP capable and
  such, its just never probed (at least the probe function in amd-k7-agp
  is never called once the module is loaded).
  
  To simplefy things, here is a pcitweak -l of the top two devices above:
  PCI: 00:00:0: chip 1022,700c card , rev 20 class 06,00,00 hdr 00
  PCI: 00:01:0: chip 1022,700d card , rev 00 class 06,04,00 hdr 01
  
  In the amd-k7-agp code, this is in the device list:
  {
  .class  = (PCI_CLASS_BRIDGE_HOST  8),
  .class_mask = ~0,
  .vendor = PCI_VENDOR_ID_AMD,
  .device = PCI_DEVICE_ID_AMD_FE_GATE_700C,
  .subvendor  = PCI_ANY_ID,
  .subdevice  = PCI_ANY_ID,
  },
  
  Which matches the first device.  So I'm completely unsure as to why this
  device is never probed or how to fix it.

try adding some instrumentation to __pci_register_driver and the functions
it calls.

oh, one thought.. do you have CONFIG_PCI_MULTITHREAD_PROBE set?
I'm wondering if the probing is racing with another driver which is claiming
the same PCI ID. (Edac, or watchdog for example)

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2/2] 2.6.21-rc7: known regressions

2007-04-20 Thread Dave Jones
On Fri, Apr 20, 2007 at 08:28:10AM -0700, Jeremy Fitzhardinge wrote:
  Dave Jones wrote:
   -BUG: at arch/i386/kernel/sched-clock.c:170 init_sched_clock()
   - [c01091b5] show_trace_log_lvl+0x1a/0x30
   - [c010980c] show_trace+0x12/0x14
   - [c01098cb] dump_stack+0x16/0x18
   - [c0468dbd] init_sched_clock+0x58/0x9b
   - [c0461502] init+0x14b/0x241
   - [c0108d97] kernel_thread_helper+0x7/0x10
   - ===
  
   heh, one for Ingo :)
  Andi, I think.  I've got his firstfloor.org patches applied to this kernel.

Ah, I saw you patched in CFS too, and thought it may be related.

   So most of the differences seem to be BIOS/firmware rather than hardware. 
   The PCI bus layout is identical for eg.
  
  Do you have Intel wireless?  I realized one chance I'd made was to swap
  the Atheros wireless with Intel, since it just seems to work better
  overall.  I'd never had any major suspend/resume problems that I could
  attribute to madwifi though (lots of minor wifi-related ones though).

yeah, the intel wireless.  Same as teh one in your pci.gz attachment..
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network 
Connection (rev 02)
Subsystem: Intel Corporation Unknown device 1010
Flags: bus master, fast devsel, latency 0, IRQ 21

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [2/2] 2.6.21-rc7: known regressions

2007-04-20 Thread Dave Jones
On Fri, Apr 20, 2007 at 10:16:54AM -0700, Jeremy Fitzhardinge wrote:
  Dave Jones wrote:
 Andi, I think.  I've got his firstfloor.org patches applied to this 
   kernel.
  
   Ah, I saw you patched in CFS too, and thought it may be related.
 
  
  Well, I have CONFIG_FB_BACKLIGHT enabled, and it still works.
  
  Maybe there's something in Andi's queue which is making it work?

Shrug, I'm out of ideas.  I'm hoping that it'll magically start working
when people start flushing their git trees for .22
Maybe that'll yield a clue for something that can be backported to .21.x
because right now, I'm completely puzzled.

I was testing on a vanilla 2.6.21-rc7-git3.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: AGPGart / AMD K7

2007-04-20 Thread Dave Jones
On Fri, Apr 20, 2007 at 12:53:31PM -0400, Preston A. Elder wrote:

  Linux agpgart interface v0.101 (c) Dave Jones
  agpgart: DEBUG 0
  agpgart: DEBUG 1
  __pci_register_driver: In function
  __pci_register_driver: driver = agpgart-amdk7, multithread = 0
  __pci_register_driver: Before Spinlock
  __pci_register_driver: Before List Init
  __pci_register_driver: Before Driver Register
  __pci_register_driver: Error = 0
  __pci_register_driver: Returning 0
  
  The DEBUG 0 and 1 are coming from agp_amdk7_init()
  There is a DEBUG 2 at the top of agp_amdk7_probe(), even before
  pci_find_capability, but the function never gets called.

bus_add_driver() returns 0 on error, but there's a few different
cases it can fail, which isn't helpful.  Add some printk's to
the error cases there, and see if that gives any more clues.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: AGPGart / AMD K7

2007-04-20 Thread Dave Jones
On Fri, Apr 20, 2007 at 02:04:45PM -0400, Preston A. Elder wrote:
  Dave Jones wrote:
   On Fri, Apr 20, 2007 at 12:53:31PM -0400, Preston A. Elder wrote:
  
 Linux agpgart interface v0.101 (c) Dave Jones
 agpgart: DEBUG 0
 agpgart: DEBUG 1
 __pci_register_driver: In function
 __pci_register_driver: driver = agpgart-amdk7, multithread = 0
 __pci_register_driver: Before Spinlock
 __pci_register_driver: Before List Init
 __pci_register_driver: Before Driver Register
 __pci_register_driver: Error = 0
 __pci_register_driver: Returning 0
 
 The DEBUG 0 and 1 are coming from agp_amdk7_init()
 There is a DEBUG 2 at the top of agp_amdk7_probe(), even before
 pci_find_capability, but the function never gets called.
  
   bus_add_driver() returns 0 on error, but there's a few different
   cases it can fail, which isn't helpful.

Actually I misparsed this function, see below..

   Add some printk's to
   the error cases there, and see if that gives any more clues.
  
  Here you go:

This is odd..

 __pci_register_driver: Before Driver Register
 __pci_register_driver: Error = 0
 __pci_register_driver: Returning 0

That __pci_register_driver code is (presumably with your printk's added..)

error = driver_register(drv-driver);
printk(Error = %d\n, error);
if (error) {
printk(Returning %d\n error);
return error;
}

Which doesn't make much sense.  If 'error' is 0, we shouldn't be
taking that second printk  return. What compiler version is this?

btw Greg, wtf does driver_register return a 0 as 'success' if it
completes the function, and 0 as 'failure' if !bus ?
That seems doomed to failure.

  Linux agpgart interface v0.101 (c) Dave Jones
  agpgart: DEBUG 0
  agpgart: DEBUG 1
  __pci_register_driver: In function
  __pci_register_driver: driver = agpgart-amdk7, multithread = 0
  __pci_register_driver: Before Spinlock
  __pci_register_driver: Before List Init
  __pci_register_driver: Before Driver Register
  bus_add_driver: In Function
  bus_add_driver: Before kobject_set_name (agpgart-amdk7)
  bus_add_driver: error = 0
  bus_add_driver: Before kobject_register
  bus_add_driver: error = 0
  bus_add_driver: Before driver_attach
  bus_add_driver: error = 0
  bus_add_driver: Before klist_add_tail
  bus_add_driver: Before module_add_driver
  bus_add_driver: Before driver_add_attrs
  bus_add_driver: error = 0
  bus_add_driver: Before add_bind_files
  bus_add_driver: error = 0
  bus_add_driver: Returning 0
  __pci_register_driver: Error = 0
  __pci_register_driver: Returning 0

So we completed bus_add_driver without failing, then popped back
up to __pci_register_driver and were somehow treated as
if we failed.   *scratches head*

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: AGPGart / AMD K7

2007-04-20 Thread Dave Jones
On Fri, Apr 20, 2007 at 02:31:01PM -0400, Preston A. Elder wrote:

  Here is the code for __pci_register_driver:
  ...
  
  So in the above case, we ARE saying if driver_register returns 0 then
  pci_create_newid_file.
  
  Is it different to the code you have?  As I said, this IS 2.6.19.

Yes, .20 changed this in this way..

@@ -445,9 +442,12 @@ int __pci_register_driver(struct pci_driver *drv, struct 
module *owner)
 
/* register with core */
error = driver_register(drv-driver);
+   if (error)
+   return error;
 
-   if (!error)
-   error = pci_create_newid_file(drv);
+   error = pci_create_newid_file(drv);
+   if (error)
+   driver_unregister(drv-driver);
 
return error;
 }


Retry your tracing with .20 (or better yet, .21rc7/todays git)

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: AGPGart / AMD K7

2007-04-20 Thread Dave Jones
On Fri, Apr 20, 2007 at 11:29:52AM -0700, Greg Kroah-Hartman wrote:
  On Fri, Apr 20, 2007 at 02:20:29PM -0400, Dave Jones wrote:
   
   btw Greg, wtf does driver_register return a 0 as 'success' if it
   completes the function, and 0 as 'failure' if !bus ?
   That seems doomed to failure.
  
  I don't know why the code does that, we should always have a bus
  assigned to a driver.  I'll change that and watch to see what breaks :)

Maybe this?

We should always have a bus in bus_add_driver()
Instead of returning success when we don't, BUG().

Signed-off-by: Dave Jones [EMAIL PROTECTED]

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 253868e..3ba8f1f 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -530,8 +530,7 @@ int bus_add_driver(struct device_driver *drv)
struct bus_type * bus = get_bus(drv-bus);
int error = 0;
 
-   if (!bus)
-   return 0;
+   BUG_ON(!bus);
 
pr_debug(bus %s: add driver %s\n, bus-name, drv-name);
error = kobject_set_name(drv-kobj, %s, drv-name);

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: AGPGart / AMD K7

2007-04-20 Thread Dave Jones
On Fri, Apr 20, 2007 at 04:22:06PM -0400, Preston A. Elder wrote:
  Dave, Greg,
  
  Here is the trace with 2.6.20.6
  
  I added back in my trace code, as you see.  As you can also see,
  agp_amdk7_probe is still not called.

Try looking down in __driver_attach()
The fact that we're not calling the -probe function is quite bizarre.

It could be this in __driver_attach

if (!dev-driver)
driver_probe_device(drv, dev);

Though that'd be odd.

Putting a #define DEBUG 1 in drivers/base/dd.c may also yield some clues.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: AGPGart / AMD K7

2007-04-20 Thread Dave Jones
On Fri, Apr 20, 2007 at 04:26:51PM -0700, Greg Kroah-Hartman wrote:
   We should always have a bus in bus_add_driver()
   Instead of returning success when we don't, BUG().
  
  Nah, I don't like adding BUG() calls to the kernel if it can be helped,
  how about the version I copied you on a few hours ago, which is also
  below?

Either works for me..

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC PATCH 1/3] x86: use defined names for all CPU feature flags

2007-04-21 Thread Dave Jones
On Fri, Apr 20, 2007 at 06:52:52PM -0400, Chuck Ebbert wrote:

  --- 2.6.21-rc7-d390.orig/arch/x86_64/kernel/setup.c
  +++ 2.6.21-rc7-d390/arch/x86_64/kernel/setup.c
  @@ -576,7 +576,7 @@ static void __cpuinit init_amd(struct cp
   
   /* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
  3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */
  -clear_bit(0*32+31, c-x86_capability);
  +clear_bit(X86_FEATURE_PBE, c-x86_capability);

The comment suggests this should be X86_FEATURE_3DNOW
Same for the other instances.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Nvidia AGP: Use refcount aware PCI interfaces

2007-04-23 Thread Dave Jones
On Mon, Apr 23, 2007 at 02:50:27PM +0100, Alan Cox wrote:
  Signed-off-by: Alan Cox [EMAIL PROTECTED]

This is lacking a changelog.  What's the purpose of changing this?
Is pci_find_slot() obsolete and going away? (If so, it should be
marked as such).  These devices aren't hotpluggable, so I'm not
sure why they need to be reference counted.

Inquisitive minds would like to know more.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Prevent softlockup triggering in nvidiafb

2007-04-23 Thread Dave Jones
If the chip locks up, we get into a long polling loop,
where the softlockup detector kicks in.
See https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151878
for an example.

Signed-off-by: Dave Jones [EMAIL PROTECTED]

--- linux-2.6.20.noarch/drivers/video/nvidia/nv_accel.c~2007-04-23 
11:06:12.0 -0400
+++ linux-2.6.20.noarch/drivers/video/nvidia/nv_accel.c 2007-04-23 
11:07:18.0 -0400
@@ -132,6 +132,8 @@ static void NVDmaWait(struct nvidia_par 
}
} else
par-dmaFree = dmaGet - par-dmaCurrent - 1;
+
+   touch_softlockup_watchdog();
}
 
if (!count) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Prevent softlockup triggering in nvidiafb

2007-04-23 Thread Dave Jones
On Mon, Apr 23, 2007 at 04:55:05PM +0100, Alan Cox wrote:
  On Mon, 23 Apr 2007 11:36:30 -0400
  Dave Jones [EMAIL PROTECTED] wrote:
  
   If the chip locks up, we get into a long polling loop,
   where the softlockup detector kicks in.
   See https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151878
   for an example.
  
  Surely in this situation the softlockup report and trap out is precisely
  what should be occurring.

We can't do anything useful with the trace.  It already prints out
info that the hardware locked up.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


serial8250 lockdep report from 2.6.21-rc7

2007-04-23 Thread Dave Jones
=
[ INFO: inconsistent lock state ]
2.6.20-1.3094.fc7 #1
-
inconsistent {hardirq-on-W} - {in-hardirq-W} usage.
swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
 (port_lock_key){++..}, at: [c0558f96] serial8250_interrupt+0x4a/0xe0
{hardirq-on-W} state was registered at:
  [c044021d] __lock_acquire+0x448/0xba9
  [c0440d70] lock_acquire+0x56/0x6f
  [c060ffd1] _spin_lock+0x2b/0x38
  [c055893b] serial8250_backup_timeout+0x6d/0xe8
  [c042c972] run_timer_softirq+0x121/0x189
  [c0429dfb] __do_softirq+0x6f/0xe2
  [c0407a64] do_softirq+0x61/0xd0
  [] 0x
irq event stamp: 332718
hardirqs last  enabled at (332717): [c0403dde] default_idle+0x3e/0x59
hardirqs last disabled at (332718): [c0406054] common_interrupt+0x24/0x40
softirqs last  enabled at (332708): [c0429e68] __do_softirq+0xdc/0xe2
softirqs last disabled at (332691): [c0407a64] do_softirq+0x61/0xd0

other info that might help us debug this:
1 lock held by swapper/0:
 #0:  (irq_lists[i].lock){+...}, at: [c0558f61] 
serial8250_interrupt+0x15/0xe0

stack backtrace:
 [c0406832] show_trace_log_lvl+0x1a/0x2f
 [c0406df1] show_trace+0x12/0x14
 [c0406e75] dump_stack+0x16/0x18
 [c043ed13] print_usage_bug+0x141/0x14b
 [c043f402] mark_lock+0xa2/0x419
 [c044018e] __lock_acquire+0x3b9/0xba9
 [c0440d70] lock_acquire+0x56/0x6f
 [c060ffd1] _spin_lock+0x2b/0x38
 [c0558f96] serial8250_interrupt+0x4a/0xe0
 [c045699a] handle_IRQ_event+0x1a/0x46
 [c0457a8a] handle_fasteoi_irq+0x7d/0xb6
 [c0407b84] do_IRQ+0xb1/0xd9
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

2007-04-24 Thread Dave Jones
On Tue, Apr 24, 2007 at 09:03:23PM +, William Heimbigner wrote:
  The following patches should allow selection of conservative, powersave, and 
  ondemand in the kernel configuration.

This has been rejected several times already.
Ondemand and conservative isn't a viable governor for all cpufreq 
implementations
(ie, ones with high switching latencies).  Also, see the comment in the Kconfig
a few lines above where you are adding this.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

2007-04-24 Thread Dave Jones
On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote:
  On 4/24/07, Dave Jones [EMAIL PROTECTED] wrote:
   On Tue, Apr 24, 2007 at 09:03:23PM +, William Heimbigner wrote:
 The following patches should allow selection of conservative, 
   powersave, and
 ondemand in the kernel configuration.
  
   This has been rejected several times already.
   Ondemand and conservative isn't a viable governor for all cpufreq
   implementations (ie, ones with high switching latencies).
  
  This piques my curiosity -- some governors don't work with some
  cpufreq implementations. Are those implementations in the kernel or in
  userspace? If in the kernel, then perhaps there should be some
  dependency expressed there in Kconfig between cpufreq implementation
  and the available governors

it can't be solved that easily. powernow-k8 for example is fine to
use with ondemand on newer systems, where the latency is low.
On older models however, it isn't.

   Also, see the
   comment in the Kconfig a few lines above where you are adding this.
  
  Are these governors unfixable? If

tbh, I've forgotten the original issues that caused the comment
to be placed there. Dominik ?

  Just looking for more info -- feel free to just point me at the archives.

cpufreq-list archives are at http://lists.linux.org.uk/mailman/listinfo/cpufreq
(though only available to list members)

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [3/3] 2.6.21-rc7: known regressions (v2)

2007-04-25 Thread Dave Jones
On Wed, Apr 25, 2007 at 01:31:02PM +0200, Adrian Bunk wrote:
  On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
   On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:
  ...
Subject: ThinkPad X60: resume no longer works  (PCI related?)
 workaround: CONFIG_FB_BACKLIGHT=n
References : http://lkml.org/lkml/2007/3/13/3
Submitter  : Dave Jones [EMAIL PROTECTED]
Caused-By  : PCI merge
 commit 78149df6d565c36675463352d0bfeb02b7a7
Handled-By : Eric W. Biederman [EMAIL PROTECTED]
 Rafael J. Wysocki [EMAIL PROTECTED]
 Antonino A. Daplas [EMAIL PROTECTED]
Status : unknown
   
   Is this related to the problems Jeremy has been looking at?
  ...
  
  Dave and Jeremy hran into similar looking but most likely different 
  problems.
  
  For Jeremy -rc7 is working fine, but for Dave it doesn't.

I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.21-rc3-mm1

2007-03-08 Thread Dave Jones
On Thu, Mar 08, 2007 at 09:50:43AM -0500, John W. Linville wrote:
  On Wed, Mar 07, 2007 at 08:18:39PM -0800, Andrew Morton wrote:
   By removing NET_RADIO, these changes pave the way to making wireless
   extensions optional when cfg80211 can fully take over for some 
  drivers
   and you don't have any older drivers that still require wext.
  
  Honestly, I'm tempted to add the pre-802.11 stuff to the features
  removal list.  I wonder if any of it still actually works...

FWIW, I've built these drivers in Fedora for aeons, and never had a single
bug filed against them. Either they're perfect, or no-one has that junk
any more.  I should turn them off for a build and see if anyone complains :)

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


irda rmmod lockdep trace.

2007-03-08 Thread Dave Jones
modprobe irda ; rmmod irda in 2.6.21rc3 gets me the spew below..

Dave

NET: Registered protocol family 23
NET: Unregistered protocol family 23

=
[ INFO: possible recursive locking detected ]
2.6.20-1.2966.fc7 #1
-
rmmod/16712 is trying to acquire lock:
 (hashbin-hb_spinlock){}, at: [884bf476] 
hashbin_delete+0x29/0x94 [irda]

but task is already holding lock:
 (hashbin-hb_spinlock){}, at: [884bf476] 
hashbin_delete+0x29/0x94 [irda]

other info that might help us debug this:
1 lock held by rmmod/16712:
 #0:  (hashbin-hb_spinlock){}, at: [884bf476] 
hashbin_delete+0x29/0x94 [irda]

stack backtrace:

Call Trace:
 [802a303b] __lock_acquire+0x151/0xbc4
 [884c1517] :irda:__irias_delete_attrib+0x0/0x31
 [802a3ea4] lock_acquire+0x4c/0x65
 [884bf476] :irda:hashbin_delete+0x29/0x94
 [80264011] _spin_lock_irqsave+0x2c/0x3c
 [884bf476] :irda:hashbin_delete+0x29/0x94
 [884c1918] :irda:__irias_delete_object+0x0/0x39
 [884c193d] :irda:__irias_delete_object+0x25/0x39
 [884bf48d] :irda:hashbin_delete+0x40/0x94
 [884c5e3a] :irda:iriap_cleanup+0x36/0x38
 [884c5fd6] :irda:irda_cleanup+0x29/0x3a
 [802aa1e1] sys_delete_module+0x199/0x1ca
 [8026ce36] syscall_trace_enter+0x9a/0x9f
 [8025c2b5] tracesys+0xdc/0xe1


-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


update 'getting sparse' info.

2007-03-08 Thread Dave Jones
- point to the sparse webpage
- use git:// instead of rsync://

Signed-off-by: Dave Jones [EMAIL PROTECTED]

--- linux-2.6.20.noarch/Documentation/sparse.txt~   2007-03-08 
19:40:30.0 -0500
+++ linux-2.6.20.noarch/Documentation/sparse.txt2007-03-08 
19:43:01.0 -0500
@@ -45,11 +45,15 @@ special.
 Getting sparse
 ~~
 
-With git, you can just get it from
+You can get latest released versions from the Sparse homepage at
+http://www.kernel.org/pub/linux/kernel/people/josh/sparse/
 
-rsync://rsync.kernel.org/pub/scm/devel/sparse/sparse.git
+Alternatively, you can get snapshots of the latest development version
+of sparse using git to clone..
 
-and DaveJ has tar-balls at
+git://git.kernel.org/pub/scm/linux/kernel/git/josh/sparse.git
+
+DaveJ has hourly generated tarballs of the git tree available at..
 
 http://www.codemonkey.org.uk/projects/git-snapshots/sparse/
 

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


2.6.21-rc3 snd-usb-audio lockdep report.

2007-03-09 Thread Dave Jones
=
[ INFO: possible recursive locking detected ]
2.6.20-1.2962.fc7 #1
-
rosegardenseque/5229 is trying to acquire lock:
 (grp-list_mutex){}, at: [881d4352] 
snd_seq_deliver_event+0x93/0x173 [snd_seq]

but task is already holding lock:
 (grp-list_mutex){}, at: [881d4352] 
snd_seq_deliver_event+0x93/0x173 [snd_seq]

other info that might help us debug this:
1 lock held by rosegardenseque/5229:
 #0:  (grp-list_mutex){}, at: [881d4352] 
snd_seq_deliver_event+0x93/0x173 [snd_seq]

stack backtrace:

Call Trace:
 [802a303b] __lock_acquire+0x151/0xbc4
 [802a3ea4] lock_acquire+0x4c/0x65
 [881d4352] :snd_seq:snd_seq_deliver_event+0x93/0x173
 [8029eab8] down_read+0x3e/0x4a
 [881d4352] :snd_seq:snd_seq_deliver_event+0x93/0x173
 [881d56c6] :snd_seq:snd_seq_kernel_client_dispatch+0x54/0x68
 [881fd05f] :snd_seq_dummy:dummy_input+0x54/0x5a
 [881d41cb] :snd_seq:snd_seq_deliver_single_event+0xf8/0x1ec
 [881d43a1] :snd_seq:snd_seq_deliver_event+0xe2/0x173
 [881d4819] :snd_seq:snd_seq_dispatch_event+0xed/0x110
 [881d6e0e] :snd_seq:snd_seq_check_queue+0xbc/0x105
 [881d70e3] :snd_seq:snd_seq_enqueue_event+0xb6/0xca
 [881d4501] :snd_seq:snd_seq_client_enqueue_event+0xcf/0x101
 [881d5db2] :snd_seq:snd_seq_write+0x140/0x198
 [8021634f] vfs_write+0xcf/0x178
 [80216d64] sys_write+0x47/0x70
 [8025c2b5] tracesys+0xdc/0xe1


-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.20.2: kernel BUG at fs/nfs/write.c:505!

2007-03-12 Thread Dave Jones
On Mon, Mar 12, 2007 at 01:00:31PM -0400, Trond Myklebust wrote:

   Code: 0f 0b eb fe f0 ff 41 44 c7 85 18 01 00 00 01 00 00 00 48 8b
   RIP  [8032fb83] nfs_wait_on_requests_locked+0x43/0xb2
RSP 81007d669ca8
  
  Known issue. There is already a fix available in the -mm kernel
  (attached).

Did this get sent to -stable too for .20.3 ?

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86_64, i386: Add command line length to boot protocol

2007-03-12 Thread Dave Jones
On Mon, Mar 12, 2007 at 10:43:52AM +, Pavel Machek wrote:
  On Tue 2007-03-06 13:21:34, Dave Jones wrote:
   On Tue, Mar 06, 2007 at 07:14:30PM +0100, Bernhard Walle wrote:
   
 +cmdline_size:   .long   COMMAND_LINE_SIZE-1 #length of the command 
   line,
   
   Why a long? It's unlikely that someone is going to have a command line
   bigger than 0x.
  
  Well, I could imagine overflowing that. Describing your numa setup,
  excluding few bad bits of ram using memmap=exact, set up your boot
  over iscsi on cmdline these are likely to eat insane ammount of
  cmdline space.

65535 characters? Are you for real?
Stop and think about just how big that is. If you have to create
a boot command line that long, you have serious, serious issues.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86_64, i386: Add command line length to boot protocol

2007-03-12 Thread Dave Jones
On Tue, Mar 13, 2007 at 12:12:20AM +0100, Pavel Machek wrote:

   65535 characters? Are you for real?
   Stop and think about just how big that is. If you have to create
   a boot command line that long, you have serious, serious issues.
  
  Well, it is about the same size as my .config...

So? That has *nothing* to do with the boot command line

  I agree we are unlikely to hit it any time soon... I could imagine
  some (ab)uses, like fixed_acpi_bios=lots of hex digits, but those
  are ugly.

That's beyond ugly, and rapidly heading towards 'loony'.

  I could also imagine some uses where entire embedded machine
  is described at kernel commandline.

There are far better ways to get configuration into the kernel
than the boot command line.

Anyways, I'm tired of arguing for the sake of arguing.
I really could care less.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


2.6.21rc suspend to ram regression on Lenovo X60

2007-03-12 Thread Dave Jones
I spent considerable time over the last day or so bisecting to
find out why an X60 stopped resuming somewhen between 2.6.20 and current -git.
(Total lockup, black screen of death).

The bisect log looked like this.

git-bisect start
# bad: [c8f71b01a50597e298dc3214a2f2be7b8d31170c] Linux 2.6.21-rc1
git-bisect bad c8f71b01a50597e298dc3214a2f2be7b8d31170c
# good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20
git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7
# bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of 
git://ftp.linux-mips.org/pub/scm/upstream-linus
git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8
# bad: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge 
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6
git-bisect bad 43187902cbfafe73ede0144166b741fb0f7d04e1
# good: [1545085a28f226b59c243f88b82ea25393b0d63f] drm: Allow for 44 bit 
user-tokens (or drm_file offsets)
git-bisect good 1545085a28f226b59c243f88b82ea25393b0d63f
# good: [c96e2c92072d3e78954c961f53d8c7352f7abbd7] Merge 
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6
git-bisect good c96e2c92072d3e78954c961f53d8c7352f7abbd7
# good: [31c56d820e03a2fd47f81d6c826f92caf511f9ee] [POWERPC] pasemi: iommu 
support
git-bisect good 31c56d820e03a2fd47f81d6c826f92caf511f9ee
# bad: [78149df6d565c36675463352d0bfeb02b7a7] Merge 
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6
git-bisect bad 78149df6d565c36675463352d0bfeb02b7a7
# good: [3d9c18872fa1db5c43ab97d8cbca43775998e49c] shpchp: remove 
CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE
git-bisect good 3d9c18872fa1db5c43ab97d8cbca43775998e49c
# good: [88187dfa4d8bb565df762f272511d2c91e427e0d] MSI: Replace pci_msi_quirk 
with calls to pci_no_msi()
git-bisect good 88187dfa4d8bb565df762f272511d2c91e427e0d
# good: [866a8c87c4e51046602387953bbef76992107bcb] msi: Fix 
msi_remove_pci_irq_vectors.
git-bisect good 866a8c87c4e51046602387953bbef76992107bcb
# good: [f7feaca77d6ad6bcfcc88ac54e3188970448d6fe] msi: Make MSI useable more 
architectures
git-bisect good f7feaca77d6ad6bcfcc88ac54e3188970448d6fe
# good: [14719f325e1cd4ff757587e9a221ebaf394563ee] Revert PCI: remove 
duplicate device id from ata_piix
git-bisect good 14719f325e1cd4ff757587e9a221ebaf394563ee

which led me to a final 'bad' commit of 78149df6d565c36675463352d0bfeb02b7a7
which is a merge changeset of lots of PCI bits.
Seeing a couple of MSI changes in there, on a hunch I booted latest tree with
pci=nomsi, and it resumed again.

Any ideas how to further debug this?
I'll try backing out individual changes from that merge tomorrow.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.21rc suspend to ram regression on Lenovo X60

2007-03-13 Thread Dave Jones
On Tue, Mar 13, 2007 at 10:22:53AM +0100, Rafael J. Wysocki wrote:
  On Tuesday, 13 March 2007 05:08, Dave Jones wrote:
   I spent considerable time over the last day or so bisecting to
   find out why an X60 stopped resuming somewhen between 2.6.20 and current 
   -git.
   (Total lockup, black screen of death).
  
  Do you have CONFIG_TICK_ONESHOT or CONFIG_NO_HZ set?  If you do, could you
  please unset them and retest?

I did try with NO_HZ unset, made no difference, I don't recall TICK_ONESHOT.
I'm in meetings all day, but I'll check when I get home.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.21rc suspend to ram regression on Lenovo X60

2007-03-15 Thread Dave Jones
On Thu, Mar 15, 2007 at 10:11:01AM -0600, Eric W. Biederman wrote:

  I haven't heard anything more on this thread.

Sorry, I've been stuck in meetings the last two days..

  I just wanted to double check.  The tree that failed did it include
  commits: 
  392ee1e6dd901db6c4504617476f6442ed91f72d and
  9f35575dfc172f0a93fb464761883c8f49599b7a
  
  Mostly I was wondering if any of my later work to sort out msi 
  suspend/resume actually solved anything.

I'll kick off some compiles and find out.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.21rc suspend to ram regression on Lenovo X60

2007-03-15 Thread Dave Jones
On Thu, Mar 15, 2007 at 10:11:01AM -0600, Eric W. Biederman wrote:
  Dave Jones [EMAIL PROTECTED] writes:
  
   On Tue, Mar 13, 2007 at 10:22:53AM +0100, Rafael J. Wysocki wrote:
 On Tuesday, 13 March 2007 05:08, Dave Jones wrote:
  I spent considerable time over the last day or so bisecting to
  find out why an X60 stopped resuming somewhen between 2.6.20 and 
   current
   -git.
  (Total lockup, black screen of death).
 
 Do you have CONFIG_TICK_ONESHOT or CONFIG_NO_HZ set?  If you do, could 
   you
 please unset them and retest?
  
   I did try with NO_HZ unset, made no difference, I don't recall 
   TICK_ONESHOT.
   I'm in meetings all day, but I'll check when I get home.
  
  I haven't heard anything more on this thread.
  
  I just wanted to double check.  The tree that failed did it include
  commits: 
  392ee1e6dd901db6c4504617476f6442ed91f72d and
  9f35575dfc172f0a93fb464761883c8f49599b7a
  
  Mostly I was wondering if any of my later work to sort out msi 
  suspend/resume actually solved anything.

I just did a build of top of tree, including those commits, and
it's still broken.  Booting with pci=nomsi no longer 'fixes' it
though, which may indicate that the MSI changes were a red herring.
(Or that the subsequent changes have regressed it even more,
 which seems unlikely looking at the changes).

.. or it could be something else introduced between rc3 (which is
what my bisect was based on) and todays tree.

sigh. I'll do more bisecting after lunch.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.21rc suspend to ram regression on Lenovo X60

2007-03-15 Thread Dave Jones
On Thu, Mar 15, 2007 at 12:45:20PM -0700, Jeremy Fitzhardinge wrote:
  Dave Jones wrote:
   I just did a build of top of tree, including those commits, and
   it's still broken.  Booting with pci=nomsi no longer 'fixes' it
   though, which may indicate that the MSI changes were a red herring.
   (Or that the subsequent changes have regressed it even more,
which seems unlikely looking at the changes).
 
  
  I just found the same thing on my X60.  Current top-of-tree with
  pci=nomsi does not improve things.  When it resumes, the CPU is working
  (capslock toggles, sysreq-b reboots), but the screen is blank.

Yeah, I noticed the capslock works.  Networking doesn't come back up
though, and it doesn't seem to answer to command that I type blindly.
Even trying to do something like..

pm-suspend ; dmesg dmesg.out; /sbin/reboot

doesn't seem to execute the commands on resume.

Switching tty's to X with alt-f7 seems to lock it up to the point that
even capslock doesn't work any more.


I'll try and hook up a usb serial cable and see if I'm lucky enough
to get something useful out of it in the absense of a serial port..

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: - rdmsr_on_cpu-wrmsr_on_cpu.patch removed from -mm tree

2007-02-10 Thread Dave Jones
On Thu, Feb 08, 2007 at 01:32:43PM -0800, [EMAIL PROTECTED] wrote:
  
  The patch titled
   rdmsr_on_cpu, wrmsr_on_cpu
  has been removed from the -mm tree.  Its filename was
   rdmsr_on_cpu-wrmsr_on_cpu.patch
  
  This patch was dropped because I've lost the plot on this thing

Alexey, send me the latest fixed up version of this, and I'll
queue this up to save Andrew trying to sort it out.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Size of 2.6.20 task_struct on x86_64 machines

2007-02-10 Thread Dave Jones
On Thu, Feb 08, 2007 at 11:14:13AM -0500, William Cohen wrote:
  This past week I was playing around with that pahole tool
  (http://oops.ghostprotocols.net:81/acme/dwarves/) and looking at the
  size of various struct in the kernel. I was surprised by the size of
  the task_struct on x86_64, approaching 4K.  I looked through the
  fields in task_struct and found that a number of them were declared as
  unsigned long rather than unsigned int despite them appearing okay
  as 32-bit sized fields. On x86_64 unsigned long ends up being 8
  bytes in size and forces 8 byte alignment. Is there a reason there
  a reason they are unsigned long?
  
  The patch below drops the size of the struct from 3808 bytes (60
  64-byte cachelines) to 3760 bytes (59 64-byte cachelines). A couple
  other fields in the task struct take a signficant amount of space:
  
  struct thread_struct   thread;   688
  struct held_lock   held_locks[30];   1680
  
  CONFIG_LOCKDEP is turned on in the .config

I sent this .. http://lkml.org/lkml/2007/1/2/299
last month which shrinks task struct by 480 bytes when lockdep
is enabled. Ingo acked it, but then it fell on the floor.

Here it is again..

Dave

Shrink the held_lock struct by using bitfields.
This shrinks task_struct on lockdep enabled kernels by 480 bytes.

Signed-off-by: Dave Jones [EMAIL PROTECTED]

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index ea097dd..ba81cce 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -175,11 +175,11 @@ struct held_lock {
 * The following field is used to detect when we cross into an
 * interrupt context:
 */
-   int irq_context;
-   int trylock;
-   int read;
-   int check;
-   int hardirqs_off;
+   unsigned char irq_context:1;
+   unsigned char trylock:1;
+   unsigned char read:2;
+   unsigned char check:1;
+   unsigned char hardirqs_off:1;
 };
 
 /*

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: -mm merge plans for 2.6.21

2007-02-10 Thread Dave Jones
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote:
  
  I'm getting fed up of holding onto hundreds of patches against subsystem
  trees, sending them over and over again seeing and nothing happen.  I sent 
  242
  patches out to subsystem maintainers on Monday and look at what's still here.
  
   agpgart-allow-drm-populated-agp-memory-types-tidy.patch
  remove-hotplug-cpu-crap-from-cpufreq.patch
  rewrite-lock-in-cpufreq-to-eliminate-cpufreq-hotplug-related-issues.patch
  ondemand-governor-restructure-the-work-callback.patch
  ondemand-governor-use-new-cpufreq-rwsem-locking-in-work-callback.patch
  cpu_freq_table-shouldnt-be-a-def_tristate.patch
  
- davej

Apologies, I suck.
I'll dispose of these appropriately tonight.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Documenting MS_RELATIME

2007-02-10 Thread Dave Jones
On Sat, Feb 10, 2007 at 09:56:07AM -0800, Michael Kerrisk wrote:
  Val,
  
  I'm just updating the mount(2) man page for MS_RELATIME, and this is the
  text I've come up with:
  
 MS_RELATIME(Since Linux 2.6.20)
When a file on this file system is accessed, only
update  the  file's last accessed time (atime) if
the current value of atime is less than or  equal
to  the file's last modified (mtime) or last sta-
tus change time (ctime).  This option  is  useful
for  programs, such as mutt(1), that need to know
when a file has been read since it was last modi-
fied.
  
  This text is based on your comments accompanying the various patches, but
  it differs in a respect.  Your comments said that the atime would only be
  updated if the atime is older than mtime/ctime.  However, what the code
  actually does is update atime if it is is = mtime/ctime -- i.e., atime is
  older than or *or equal to* mtime/ctime.
  
  I'm sure that the code implements your intention, but before incorporating
  the above text I thought I just better check, since the code differs from
  your comment.  Can you just confirm that the proposed man page text is okay.

Whilst on the subject of RELATIME, is there any good reason why
not to make this a default mount option ?

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Documenting MS_RELATIME

2007-02-12 Thread Dave Jones
On Sun, Feb 11, 2007 at 10:55:04PM -0800, Valerie Henson wrote:
  On Sat, Feb 10, 2007 at 07:54:00PM -0500, Dave Jones wrote:
   
   Whilst on the subject of RELATIME, is there any good reason why
   not to make this a default mount option ?
  
  Ubuntu has been shipping with noatime as the default for some time
  now, with no obvious problems (I'm running Ubuntu).  I see relatime as
  an improvement on noatime.

The one problem with noatime is that mutt's 'new mail arrived' breaks
as you mentioned in the relatime changelog, so I'm surprised that
they turned it on by default.  With relatime fixing that however,
I'm also unaware of anything that breaks.   I'd be curious to
do a Fedora test release with relatime, but I know the answer I'll
get when I recommend we add it to our generated fstabs..

If it's good enough, why isn't it the kernel default

Hence my current line of questioning ;-)

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Which CPU for VIA C7/Esther?

2007-02-12 Thread Dave Jones
On Mon, Feb 12, 2007 at 02:14:41PM -0500, Kyle McMartin wrote:
  On Mon, Feb 12, 2007 at 06:37:38PM +0100, Mark de Vries wrote:
   I've been googeling for about an hour now and can't find an answer to:
   What type of CPU should I select when compiling a recent 2.6 kernel if I
   have a VIA Esther CPU?
  
   stepping: 9
  
  config MVIAC3_2
  bool VIA C3-2 (Nehemiah)
  help
Select this for a VIA C3 Nehemiah. Selecting this enables usage
of SSE and tells gcc to treat the CPU as a 686.
Note, this kernel will not boot on older (pre model 9) C3s.
  
  Is the one you want, I believe.

The C7 doesn't seem to care much which you optimise it for.
Any of the 686 options should work just fine, but MVIAC3_2 is no
worse than any of the others.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Which CPU for VIA C7/Esther?

2007-02-12 Thread Dave Jones
On Mon, Feb 12, 2007 at 11:46:46PM +, Simon Arlott wrote:

  MVIAC3_2 doesn't enable X86_GOOD_APIC

which is pretty irrelevant unless you have a dual C7.

  , try M686 (Pentium-Pro) - but that won't enable MMX and SSE (via 
  -march=c3-2).

If gcc generated SSE/MMX instructions that would be a bug. (hint: it doesn't).

  These CPUs support SSE2 too... 

The SSE/SSE2/SSE3 etc support for userspace is unconditional. The context 
switch paths will
save/restore the registers regardless of the CPU you've compiled your kernel 
for.
The only SSE code in the kernel is the memcpy code (which wasn't that big a win 
when
I last tried it on VIA due to their poor memory bandwidth), and the RAID code, 
which
gets tested at runtime rather than compile time.

  Also, for the C7 you'll want CRYPTO_DEV_PADLOCK_* (Hardware Crypto Devices, 
  Support for VIA PadLock ACE) and HW_RANDOM_VIA (VIA HW Random Number 
  Generator support).

Yes. But these aren't dependant on any CPU config options.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/3] Introducing cpuidle: core cpuidle infrastructure

2007-02-12 Thread Dave Jones
On Mon, Feb 12, 2007 at 10:39:25AM -0800, Venkatesh Pallipadi wrote:
  
  Introducing 'cpuidle', a new CPU power management infrastructure to manage
  idle CPUs in a clean and efficient manner.
  cpuidle separates out the drivers that can provide support for multiple types
  of idle states and policy governors that decide on what idle state to use
  at run time.
  A cpuidle driver can support multiple idle states based on parameters like
  varying power consumption, wakeup latency, etc (ACPI C-states for example).
  A cpuidle governor can be usage model specific (laptop, server,
  laptop on battery etc).
  Main advantage of the infrastructure being, it allows independent development
  of drivers and governors and allows for better CPU power management.
  
  A huge thanks to Adam Belay and Shaohua Li who were part of this mini-project
  since its beginning and are greatly responsible for this patchset.

interesting.  Though I wonder about giving admins _more_ knobs to twiddle.
It took cpufreq a long time to settle down in this area, and typically
'ondemand' was the answer in the end for 99.9% of people.   I question the 
usefulness
for the whole multiple governors interface, because in the case of cpuidle
there shouldn't be any real trade-off between one algorithm and another afaics?
So why can't we just have one, that just 'does the right thing' ?
The only differentiator that I can think of would be latency, but that seems
to be a) covered in a different tunable, and b) probably wouldn't affect
most people enough where it matters.


I'll do a proper code review later, but one thing stuck out like a sore
thumb on a quick skim..


  +EXPORT_SYMBOL_GPL(current_driver);

That's a horribly generic name for an exported global.

current_cpuidle_driver maybe?

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


loosen dependancy on rtc cmos

2007-02-14 Thread Dave Jones
This option is useful for all of the X86 subarchs afaik (and especially 
X86_GENERICARCH).

Signed-off-by: Dave Jones [EMAIL PROTECTED]

--- linux-2.6.20.noarch/drivers/rtc/Kconfig~2007-02-14 13:07:07.0 
-0500
+++ linux-2.6.20.noarch/drivers/rtc/Kconfig 2007-02-14 13:07:13.0 
-0500
@@ -101,7 +101,7 @@ comment RTC drivers
 
 config RTC_DRV_CMOS
tristate PC-style 'CMOS' real time clock
-   depends on RTC_CLASS  (X86_PC || ALPHA || ARM26 || ARM \
+   depends on RTC_CLASS  (X86 || ALPHA || ARM26 || ARM \
|| M32R || ATARI || POWERPC)
help
  Say yes here to get direct support for the real time clock

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] use movntq version of fast_clear_page/fast_copy_page on Geode

2007-02-14 Thread Dave Jones
On Wed, Feb 14, 2007 at 05:08:39PM -0200, Marcelo Tosatti wrote:
  
  movntq instruction is supported by Geode CPU's, so use
  fast_clear_page/fast_copy_page versions that have it.

it's supported, but is it a win ?
The same was also true of the VIA C3/C7's, but due to
poor memory bandwidth, it turned out to be slower in most cases.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] use movntq version of fast_clear_page/fast_copy_page on Geode

2007-02-14 Thread Dave Jones
On Wed, Feb 14, 2007 at 06:17:36PM -0200, Marcelo Tosatti wrote:
  On Wed, Feb 14, 2007 at 02:55:46PM -0500, Dave Jones wrote:
   On Wed, Feb 14, 2007 at 05:08:39PM -0200, Marcelo Tosatti wrote:
 
 movntq instruction is supported by Geode CPU's, so use
 fast_clear_page/fast_copy_page versions that have it.
   
   it's supported, but is it a win ?
   The same was also true of the VIA C3/C7's, but due to
   poor memory bandwidth, it turned out to be slower in most cases.
  
  Do you have the numbers for VIA C3/C7 around?

I don't, and my 3dnow capable C3s are unplugged right now.
The newer generation (including the C7) have SSE/SSE2 instead,
which seems to be faster.  (Using a different benchmark app that uses SSE)

clear_page function 'normal clear_page()'took 9425 cycles per page 
(620.3 MB/s)
clear_page function 'new clear_page()   'took 3840 cycles per page 
(1522.7 MB/s)

copy_page function 'normal copy_page()'  took 11453 cycles per page (510.5 MB/s)
copy_page function 'new copy_page()   '  took 5024 cycles per page (1163.7 MB/s)


Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


export of_find_property

2007-02-14 Thread Dave Jones
Without this, building drivers/serial/of_serial.c as a module fails.

WARNING: .of_find_property [drivers/serial/of_serial.ko] undefined!

Signed-off-by: Dave Jones [EMAIL PROTECTED]

--- linux-2.6.20.noarch/arch/powerpc/kernel/prom.c~ 2007-02-14 
16:52:47.0 -0500
+++ linux-2.6.20.noarch/arch/powerpc/kernel/prom.c  2007-02-14 
16:52:57.0 -0500
@@ -1599,6 +1599,7 @@ struct property *of_find_property(const 
 
return pp;
 }
+EXPORT_SYMBOL(of_find_property);
 
 /*
  * Find a property with a given name for a given node

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Dave Jones
On Wed, Feb 14, 2007 at 07:41:12PM -0800, Andrew Morton wrote:

   77 files changed, 9681 insertions(+), 10 deletions(-)
  
  just to be able to sign modules.
  
  Normally I'd collapse writhing in laughter, but..
  
   These patches have been in use by RHEL and Fedora kernels for years, and so
   have been thoroughly tested.
  
  so I guess there's an argument for merging them so we can send them back to
  you guys.  But there's also an argument to declare all this gunk a
  vendor-only thing.  How much pain would that cause?

it needs rediffing pretty much every time the cryptoapi changes.
On a good month that means once per point release, otherwise...

One argument in its favour is aparently Red Hat isn't the only vendor
with something like this.  I've not investigated it, but I hear rumours
that suse has something similar.  Having everyone using the same code
would be a win for obvious reasons.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: GPL vs non-GPL device drivers

2007-02-14 Thread Dave Jones
On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote:
  This is in reference to the following thread:
  
  http://lkml.org/lkml/2006/12/14/63
  
  I am not sure if this is ever addressed in LKML, but linux is _very_
  popular in the embedded space. We (an embedded vendor) chose Linux 3
  years back because of its lack of royalty model, robustness and
  availability of infinite number of open-source tools.
 
Welcome to three months ago.
Here in the future, this was deemed a non-issue.
However this does highlight another problem.
End-users who take linux for use in embedded systems (especially)
tend to live in their own little world rarely contributing anything
back to upstream, popping up occasionally when months after decisions
have been made on things.   Remind me again why we should care about
your out of tree binary only modules ?

  The drivers which
  we have written over the last three years are suddenly under threat.

Were they part of the kernel tree, people might care enough to
a) fix them so that they work and b) care enough that they _keep working_
even if people changing APIs etc don't have the necessary hardware.

This isn't the 1990s any more, we shouldn't need to explain how all this works.

  However we have a worrying trend here. If at some point it becomes
  illegal to load our modules into the linux kernel, then it is
  unacceptable to us. We would have been better off choosing VxWorks or
  OSE 3 years ago when we made an OS choice. The fact that Linux is
  becoming more and more closed is very very alarming.

The question is do you care about giving back or are you intending
to leech of Linux and just complain when it changes in ways that
don't mesh with your plans?

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: GPL vs non-GPL device drivers

2007-02-14 Thread Dave Jones
On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:

  Not everybody has to be a contributor. The reason Linux is popular is
  because of its openness. Take that away and see where it goes.

please expand on this openness.
Especially wrt your add-ons.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: GPL vs non-GPL device drivers

2007-02-14 Thread Dave Jones
On Wed, Feb 14, 2007 at 10:46:13PM -0800, v j wrote:
  You don't get it do you. Our source code is meaningless to the Open
  Source community at large.

Linux supports entire _architectures_ of which there are single figures
of people using it.  What makes your hardware special ?
 
  We are only _using_ Linux.

If you're adding kernel modules, you're more than using Linux, you're
developing _for_ linux.  You're just choosing to keep the fruits of
those labors to yourself.
 
  Just as we could have used VxWorks or OSE.

You could.  But would you have had access to thousands of worldwide
contributors making your code better?
This is what you've missed out on with your current stance.
 
  Using our source code would not benefit anybody but
  our competitors.

This excuse has been given time and time again, and repeatedly been 
proven false.  And as soon as one of your competitors makes their
drivers open, guess which one gets 1000+ free developers working
on their code ?

  Sure we could make our drivers open-source. This is a
  decision that is made FIRST when evaluating an OS. If we we were
  required to make our drivers/HW open, we would just not have chosen
  Linux. It is as simple as that.

Please, revisit the 1990s. Read the cathedral and the bazaar.[1]
Listen to MC Hammer.   Realise the funky horror.  Then when you're ready
to revisit us with some points that haven't already been dismissed
please post again. Until then, you're offering nothing new.

Dave

[1] Jesus, I'm recommending ESR texts, I must be desperate.

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Dave Jones
On Wed, Feb 14, 2007 at 09:35:40PM -0800, Andreas Gruenbacher wrote:
  On Wednesday 14 February 2007 20:13, Dave Jones wrote:
   I've not investigated it, but I hear rumours that suse has something
   similar.
  
  Actually, no. We don't belive that module signing adds significant value,

ok, then I was misinformed.

  and it also doesn't work well with external modules.

well, the situation for external modules is no worse than usual.
They still work, they just aren't signed. Which from a distributor point
of view, is actually a nice thing, as they stick out like a sore thumb
in oops reports with (U) markers :)

  (The external modules we really care about are GPL ones; it gives us a way
  to update drivers without pushing out entirely new kernels.)

external modules still compile, and run just fine. The signed modules code
doesn't prevent loading of them unless the user decides to do so with
a special boot option (which is no different really than say, reducing
the cap-bound sysctl to prevent module loading).

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Dave Jones
On Wed, Feb 14, 2007 at 10:14:53PM -0800, Andreas Gruenbacher wrote:
  On Wednesday 14 February 2007 21:45, Dave Jones wrote:
   well, the situation for external modules is no worse than usual.
   They still work, they just aren't signed. Which from a distributor point
   of view, is actually a nice thing, as they stick out like a sore thumb
   in oops reports with (U) markers :)
  
  I agree, that's really what should happen. We solve this by marking modules 
  as 
  supported, partner supported, or unsupported, but in an insecure way, so 
  partners and users could try to fake the support status of a module and/or 
  remove status flags from Oopses, and cryptography wouldn't save us. We could 
  try to sign Oopses which I guess you guys are doing. This whole issue hasn't 
  been a serious problem in the past though, and we generally try to trust 
  users not to play games on us.

For the most part it works out.  I've had users file oopses where they've 
editted
out Tainted: P, and left in nvidia(U) for example :-)

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: GPL vs non-GPL device drivers

2007-02-15 Thread Dave Jones
On Thu, Feb 15, 2007 at 04:44:51AM -0500, Jeff Garzik wrote:
  Dave Jones wrote:
   On Wed, Feb 14, 2007 at 10:46:13PM -0800, v j wrote:
 Using our source code would not benefit anybody but
 our competitors.
   
   This excuse has been given time and time again, and repeatedly been 
   proven false.  And as soon as one of your competitors makes their
   drivers open, guess which one gets 1000+ free developers working
   on their code ?
  
  
  Customers also like to buy hardware where they -know- support will not 
  disappear in a year, when the vendor releases a new chip.

Absolutely. This is a very good point.
And users of binary blobs like nvidia.ko are already beginning to see
this problem.   (Nvidia dropped support for legacy cards a while back)

Only open drivers ensure ongoing vendor-independant support, which
is an important thing.   I'd not be happy buying a device that I know
the vendor is going to ship security updates for a year after release.
VJ, how long does your company support each product? And how much
engineering effort is spent doing so, vs effort that you could get
for free by opening your driver(s) ?

  In fact, in some markets, the engineers who wrote the code have often 
  moved to the next project, by the time the customers actually get their 
  hands on the end result.  Open source means that problems found in real 
  world field testing can be readily debugged and fixed.

Even open drivers have the same problem.  Take for example longhaul.c.
I lost interest in this a while ago and moved on to shinier new hardware
(whilst it still had numerous problems) and rafal picked this up and has
been fixing it up like something possessed since.
If this were a closed driver, it would have been doomed never to improve.

It's a great example of one of the strengths of the open process.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: GPL vs non-GPL device drivers

2007-02-15 Thread Dave Jones
On Thu, Feb 15, 2007 at 12:00:56PM +0100, Xavier Bestel wrote:
  On Thu, 2007-02-15 at 12:51 +0200, Mohammed Gamal wrote:
   I am still a kernel newbie, and I am still not very much aware about
   the GPL vs. Non-GPL drivers debate. I personally think it'd be better
   that all drivers should be GPL'd but if that's the case, what would be
   the legal position of such vendors as ATI or NVIDIA who supply closed
   source drivers? Would it be illegal to use them?
  
  Yeah, this is a recurrent debate, and the positions are mixed. Linus
  said that the nvidia driver isn't developed only for linux but also for
  windows, so it's not a true derivative of the kernel, so the GPL doesn't
  really apply. But not everyone (I mean core developpers) fully agrees
  IIRC.

to further expand on the above question it isn't really crystal clear
whether this (from the ATI driver) is legal..
(psuedo diff vs the kernel agp drivers)



+#ifdef STANDALONE_AGPGART
 MODULE_AUTHOR(Jeff Hartmann [EMAIL PROTECTED]);
 MODULE_PARM(agp_try_unsupported, 1i);
 #ifdef MODULE_LICENSE
 MODULE_LICENSE(GPL and additional rights);
+#endif


and then linking the result to their binary blob.
I assume ATI's lawyers think its legal, as it's been a year and
a half since I first brought this questionable act to their
attention.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: GPL vs non-GPL device drivers

2007-02-15 Thread Dave Jones
On Thu, Feb 15, 2007 at 09:05:11PM +1000, Trent Waddington wrote:
  On 2/15/07, Xavier Bestel [EMAIL PROTECTED] wrote:
   But that's not the case with VJ's drivers, which are apparently solely
   for linux, so should be distributed under the GPL.
  
  In any case, you're free to use any driver, regardless of license..
  copyright does not cover use, only copying and most, if not all,
  jurisdictions make it clear that copying into memory is not a
  copyright matter.

One area that is clear however is distribution of the result.
You're free to do whatever you want to my code as long as it
never leaves your computer.  As soon as you give it to someone else,
you're bound by the conditions of the license to give copies
of the modified source.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86: Unify pcspeaker platform device code between i386/x86-64

2007-02-15 Thread Dave Jones
On Thu, Feb 15, 2007 at 10:49:57AM +0100, Andi Kleen wrote:
  
   It's always seemed broken (though perhaps this was a distro bug?) in 
   module form, so I've been compiling it in to get it to work.
  
  Must have been a distro bug. It should have worked before as long 
  as the config was enabled.

If so, I'm not sure what distro Jeff was running, as it worked
fine in Fedora for some time on both 32bit and 64bit x86 for me.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-16 Thread Dave Jones
On Thu, Feb 15, 2007 at 10:13:04PM +, Pavel Machek wrote:
  Hi!
  
   Now, this is not a complete solution by any means: the core kernel is not
   protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
   controls) one relatively simple attack vector.
  
  Could we fix the /dev/*mem holes, first? They are already used by
  malicious modules (aka rootkits...).  Or can selinux already provide
  /dev/*mem protection with no way for admin to turn it off?

There are some valid uses for peeking through /dev/mem. Things like
dmidecode for example.  So you don't want to disable it completely
in a lot of cases, but have fine-grained access to specific parts
of the file.  I'm not sure SELinux can do this. Maybe the MLS stuff
helps here (though I'm far from an expert on this, so I could be
talking out of my rear).

The restricted dev/mem patches we've had in Fedora for a while
do the right thing, but they're a bit crufty (in part due to
drivers/char/mem.c being a bit of a mess before we even start
patching it).  I've had clean these up for upstream on my
todo for a while. I might get around to it one of these days.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] sysctl: move init_irq_proc into init/main where it belongs

2007-02-17 Thread Dave Jones
On Wed, Feb 14, 2007 at 05:00:19PM +, Linux Kernel wrote:
  Gitweb: 
  http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b04c3afb2b6e2f902b41bb62b73684d92d7e6c34
  Commit: b04c3afb2b6e2f902b41bb62b73684d92d7e6c34
  Parent: 0e03036c97b70b2602f7dedaa3a223ed7563c2c9
  Author: Eric W. Biederman [EMAIL PROTECTED]
  AuthorDate: Wed Feb 14 00:33:57 2007 -0800
  Committer:  Linus Torvalds [EMAIL PROTECTED]
  CommitDate: Wed Feb 14 08:09:58 2007 -0800
  
  [PATCH] sysctl: move init_irq_proc into init/main where it belongs
  
  Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
  Signed-off-by: Andrew Morton [EMAIL PROTECTED]
  Signed-off-by: Linus Torvalds [EMAIL PROTECTED]

This causes an implicit declaration which broke ppc32 builds for me..
(my builds use -Werror-implicit to catch this flaw early)

init/main.c: In function 'do_basic_setup':
init/main.c:744: error: implicit declaration of function 'init_irq_proc'

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [-mm patch] {rd,wr}msr_on_cpu SMP=n optimization

2007-02-19 Thread Dave Jones
On Tue, Feb 20, 2007 at 01:07:13AM +0100, Adrian Bunk wrote:
  On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
  ...
   Changes since 2.6.20-rc6-mm3:
  ...
   +rdmsr_on_cpu-wrmsr_on_cpu.patch
  ...
x86 updates
  ...
  
  Let's save a few bytes in the CONFIG_SMP=n case.
  
  Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
  
  ---
  
  BTW: currently -ENOUSERS

There was a follow-on patch that converted p4-clockmod to use it for one.

  +#ifdef CONFIG_SMP
   void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h);
   void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h);
  +#else  /*  CONFIG_SMP  */
  +static inline void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 
  *h)
  +{
  +rdmsr(msr_no, *l, *h);
  +}
  +static inline void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h)
  +{
  +wrmsr(msr_no, l, h);
  +}
  +#endif  /*  CONFIG_SMP  */

BUG_ON(cpu!=smp_processor_id()) maybe?

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [-mm patch] {rd,wr}msr_on_cpu SMP=n optimization

2007-02-19 Thread Dave Jones
On Tue, Feb 20, 2007 at 01:21:45AM +0100, Adrian Bunk wrote:
  On Mon, Feb 19, 2007 at 07:14:34PM -0500, Dave Jones wrote:
   On Tue, Feb 20, 2007 at 01:07:13AM +0100, Adrian Bunk wrote:
  ...
 +#ifdef CONFIG_SMP
  void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h);
  void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h);
 +#else  /*  CONFIG_SMP  */
 +static inline void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, 
   u32 *h)
 +{
 +   rdmsr(msr_no, *l, *h);
 +}
 +static inline void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, 
   u32 h)
 +{
 +   wrmsr(msr_no, l, h);
 +}
 +#endif  /*  CONFIG_SMP  */
   
   BUG_ON(cpu!=smp_processor_id()) maybe?
  
  This is the CONFIG_SMP=n case.

Yes. If someone is asking for the MSR on a specific CPU in UP mode,
it's a bug.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Delete obsolete RAW driver feature.

2007-03-20 Thread Dave Jones
On Sun, Mar 18, 2007 at 04:57:57PM +0100, Andi Kleen wrote:
  Robert P. J. Day [EMAIL PROTECTED] writes:
  
   Delete the allegedly obsolete raw driver feature, which has been
   marked for death since 2005.
  
  I think it would be better to replace it with a wrapper
  that forces O_DIRECT and opens the underlying block device.  I suspect 
  just dropping it will break many people's database setups, which is not
  nice.  Widely used admin interfaces should be only broken when 
  there is a very good reason and just there is a better way now 
  doesn't seem quite strong enough.

Agreed.  Given how this keeps coming up every few months, lets just
remove that from the list..  It's not that a 306 line driver is
particularly invasive anyways..

Signed-off-by: Dave Jones [EMAIL PROTECTED]

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index 0bc8b0b..6b845f3 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -21,14 +21,6 @@ Who: Pavel Machek [EMAIL PROTECTED]
 
 ---
 
-What:  RAW driver (CONFIG_RAW_DRIVER)
-When:  December 2005
-Why:   declared obsolete since kernel 2.6.3
-   O_DIRECT can be used instead
-Who:   Adrian Bunk [EMAIL PROTECTED]
-

-
 What:  raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
 When:  June 2007
 Why:   Deprecated in favour of the more efficient and robust rawiso interface.


-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] Export not_critical_when_idle feature in workqueue and use it in ondemand

2007-03-20 Thread Dave Jones
On Tue, Mar 20, 2007 at 10:04:18AM -0700, Pallipadi, Venkatesh wrote:

  just for kicks (actually because I was seeing the negative effects
  of not having this diff) I threw this in the Fedora devel kernel.
  Got a few people reporting softlockups during shutdown.
  jpeg from one user attached..
  
  Thanks for the report. I will take a look at this message.
  Looks like, this error is either coming from rmmod or changing the
  governor to default from ondemand during reboot. Does Fedora
  use ondemand as a module and rmmod on reboot or is it builtin?

Yes, it's modular.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: how can I touch softlockup watchdog on all cpus?

2007-03-21 Thread Dave Jones
On Wed, Mar 21, 2007 at 05:06:34PM +0100, Cestonaro, Thilo (external) wrote:
  Hey,
  
  my module generates this ugly softlockup dump, because all cpus are stopped 
  longer then 10 secs.
  What I do is:
  [code]
  local_irq_disable();
  // my stuff which takes long and stopps all cpus
  .
  touch_softlockup_watchdog();
  local_irq_enable();
  [/code]
  
  this prevents a dump of my current cpu but not for all.
  A call to smp_call_function with a function which calls 
  touch_softlockup_watchdog in it,
  doesn't work because smp_call_function needs to be done with irqs enabled, 
  so the watchdog comes first :(.
  
  Any hints or ideas how I can do it in a better way? Disabling softlockup 
  watchdog is not possible for me.

You didn't explain _why_ you need to sleep for such a long time,
and as you didn't give a pointer to your code, there's not
much people can do to recommend changes other than don't do that.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] Export deferrable timer through workqueue and use it in ondemand governor

2007-03-21 Thread Dave Jones
On Wed, Mar 21, 2007 at 01:23:40PM -0700, Venkatesh Pallipadi wrote:
  
  
  Add a new deferrable delayed work init. This can be used to schedule work
  that are 'unimportant' when CPU is idle and can be called later, when CPU
  eventually comes out of idle.
  
  Use this init in cpufreq ondemand governor.
   
  Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]

drivers/cpufreq/cpufreq_ondemand.c: In function 'dbs_timer_init':
drivers/cpufreq/cpufreq_ondemand.c:473: error: implicit declaration of function 
'init_timer_deferrable'

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] Export deferrable timer through workqueue and use it in ondemand governor

2007-03-21 Thread Dave Jones
On Wed, Mar 21, 2007 at 03:19:45PM -0700, Venki Pallipadi wrote:

  init_timer_deferrable is defined in
  [PATCH 1/2] Add support for deferrable timers
  http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/2064.html
  
  Do you get this error after that patch?

Ah, looks like I had 1/2 from the previous iteration of this patch.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Delete obsolete RAW driver feature.

2007-03-21 Thread Dave Jones
On Wed, Mar 21, 2007 at 03:19:52PM -0700, Andrew Morton wrote:

  We've given people years of notice and _some_ applications have converted
  over to open(/dev/sda1, O_DIRECT), as they should.
  
  Sure, it's a small and simple driver (now), so the cost of maintaining it
  is low.
  
  But otoh, there's no reason for it to exist, except for userspace
  sluggishness.
  
  So we can either give up, or we can push on: put a rude printk in there
  somewhere and who knows, maybe in five years time we can finally be rid of
  the thing.

We've actually tried to deprecate this twice. First in RHEL4, and more
recently in RHEL5.  The conversations go something like this..

Customer: app xyz doesn't work.
Us: it's using a deprecated API, it needs to be updated to use O_DIRECT
Customer: vendor says pay us $ to go to version N+1

Then we find out the customer can't move to N+1 because they have
some other piece of infrastructure that relies on semantics in the
old version, and screaming and hairpulling ensues.

(And this is one of the more promising conversations. Others
 that have happened with certain db vendors are enough to
 make the pope curse).

Adding printk's on open() of it doesn't solve the problem either.
The people that see them are the customers who run this stuff,
not the people who have the ability to change the code.

If it gets dropped from kernel.org, it wouldn't be long before
it'd find its way back into enterprise vendor kernels.
Isn't it better that we all at least ship the same thing? [1]

Dave

[1] Though admittedly the one in RHEL deviates from upstream
as it contains performance enhancements that were vetoed from
upstream acceptance due to it being deprecated.

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Delete obsolete RAW driver feature.

2007-03-21 Thread Dave Jones
On Wed, Mar 21, 2007 at 04:27:17PM -0700, Andrew Morton wrote:
   [1] Though admittedly the one in RHEL deviates from upstream
   as it contains performance enhancements that were vetoed from
   upstream acceptance due to it being deprecated.
  
  What enhancements are they?

Hmm, actually it seems I was mistaken, we didn't merge those after all,
we seem to be shipping what was upstream in 2.6.9/2.6.18.

The patches I was thinking of were a bunch of optimisations for higher
throughput from someone at Intel iirc. Ken Chen maybe?

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Delete obsolete RAW driver feature.

2007-03-21 Thread Dave Jones
On Thu, Mar 22, 2007 at 12:24:33AM +0100, Willy Tarreau wrote:
 
  Then a printk() on every open() should be enough. We've all been seeing
  Warning: tcpdump uses obsolete AF_PACKET... and it finally disappeared.

There's a difference.  We have the source for tcpdump.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Oops after cd /sys/.../cpufreq/; rmmod; cat stats/time_in_state

2007-03-21 Thread Dave Jones
On Wed, Mar 21, 2007 at 08:07:53PM -0700, Greg KH wrote:
 
   After modprobe/rmmod cpufreq/stats directory appears but doesn't get
   removed. Should it?
  Well, one can argue that those stats should never be in sysfs at all
  anyway, I mean come on, a histogram in sysfs?  That's, not ok.

Meh, it's only a cheesy debug thing, so it's not really that big a deal imo.
it could probably move to debugfs (we didn't have that when it was merged iirc)
I doubt anyone really cares enough to bother though I wouldn't
be averse to a patch.
To the best of my knowledge, nothing in userspace is relying on that stuff
being present (it'd have to cope with it not being there anyway given its
optional).

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Delete obsolete RAW driver feature.

2007-03-21 Thread Dave Jones
On Thu, Mar 22, 2007 at 05:12:42AM +0100, Willy Tarreau wrote:
  On Wed, Mar 21, 2007 at 07:43:18PM -0400, Dave Jones wrote:
   On Thu, Mar 22, 2007 at 12:24:33AM +0100, Willy Tarreau wrote:

 Then a printk() on every open() should be enough. We've all been seeing
 Warning: tcpdump uses obsolete AF_PACKET... and it finally 
   disappeared.
   
   There's a difference.  We have the source for tcpdump.
  
  But what's the problem with warning: process XXX uses obsolete raw driver
  and may not work anymore after 2007/XX/XX if not fixed ?

The target audience isn't going to read it.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Delete obsolete RAW driver feature.

2007-03-21 Thread Dave Jones
On Thu, Mar 22, 2007 at 05:45:40AM +0100, Willy Tarreau wrote:
  On Thu, Mar 22, 2007 at 12:17:51AM -0400, Dave Jones wrote:
   On Thu, Mar 22, 2007 at 05:12:42AM +0100, Willy Tarreau wrote:
 On Wed, Mar 21, 2007 at 07:43:18PM -0400, Dave Jones wrote:
  On Thu, Mar 22, 2007 at 12:24:33AM +0100, Willy Tarreau wrote:
   
Then a printk() on every open() should be enough. We've all been 
   seeing
Warning: tcpdump uses obsolete AF_PACKET... and it finally 
   disappeared.
  
  There's a difference.  We have the source for tcpdump.
 
 But what's the problem with warning: process XXX uses obsolete raw 
   driver
 and may not work anymore after 2007/XX/XX if not fixed ?
   
   The target audience isn't going to read it.
  
  Yes they will if you write it with KERN_CRIT.

*no*.

Users will see it. The developers of the software those users are running won't.
We're talking about apps here that we don't have the source to, and vendors
want extortionate amount of money to change.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


$CHECK can't be overridden

2007-03-21 Thread Dave Jones
make help implies that supplying $CHECK on the command line
should override sparse as the checker used when building with C=1
Yet, this doesn't seem to be the case.

This would be useful for cases where for eg, sparse isn't in
the $PATH, allowing an explicit path to the executable to be
passed in automated build environments.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: $CHECK can't be overridden

2007-03-21 Thread Dave Jones
On Thu, Mar 22, 2007 at 04:26:39PM +1100, Keith Owens wrote:
  Dave Jones (on Thu, 22 Mar 2007 01:15:25 -0400) wrote:
  make help implies that supplying $CHECK on the command line
  should override sparse as the checker used when building with C=1
  Yet, this doesn't seem to be the case.
  
  This would be useful for cases where for eg, sparse isn't in
  the $PATH, allowing an explicit path to the executable to be
  passed in automated build environments.
  
  Works for me.
  
  # make C=1 CHECK=foo

Ah, my bad. I was thinking it was an environment var rather
than a makefile var.  I was using 'CHECK=foo make bzImage C=1'

Thanks,

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Delete obsolete RAW driver feature.

2007-03-21 Thread Dave Jones
On Thu, Mar 22, 2007 at 06:53:06AM +0100, Willy Tarreau wrote:

  At most, they will ask their distro vendor for continued support of the
  feature (which there will be in the same minor release), and if vendors'
  feedback show there is enough demand, then we will just have to delay the
  removal.

Err, this is where we are _today_

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] fix cpufreq_stats attrs removal

2007-03-22 Thread Dave Jones
On Thu, Mar 22, 2007 at 06:43:21PM +0100, Mattia Dongili wrote:
  On Thu, Mar 22, 2007 at 06:02:01PM +0100, Mattia Dongili wrote:
  
  forgot... (should I resend the whole thing?)
  
  Signed-off-by: Mattia Dongili [EMAIL PROTECTED]

Nah, I'll cut-n-paste.
Ignore my other mail btw, I wasn't thinking straight.
Marking the stats module unsafe for removal won't prevent
the race when we remove _other_ modules :-)

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] fix cpufreq_stats attrs removal

2007-03-22 Thread Dave Jones
On Thu, Mar 22, 2007 at 06:02:01PM +0100, Mattia Dongili wrote:

  The problem is cpufreq_stats doesn't know when a cpufreq driver is
  removed and doesn't cleanup. I guess this affects any setup with
  cpufreq_stats.
  The attached patch seems to solve both symptoms and yes... it's quite
  invasive as it introduce one more cpufreq policy notification (REMOVED).
  
  BTW: the patch is against .21-rc4-mm1 but applies with some fuzz to
  2.6.20 too

Alternatively, as it's just debug functionality, we could just
mark it unsafe for rmmod, which is nastier, but a lot less invasive
to the non-debug code.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: how can I touch softlockup watchdog on all cpus?

2007-03-22 Thread Dave Jones
On Thu, Mar 22, 2007 at 03:46:54PM -0700, Jeremy Fitzhardinge wrote:
  Cestonaro, Thilo (external) wrote:
   It's a condition of a customer of us, so I can't change it.
  
   But it happens not often that my part is used. So I thought there is a 
   mechanism to disable or reset the watchdog
   because it is a legal pause for it. And there is one 
   touch_softlockup_watchdog(), that does what I want,
   BUT just for the current cpu. And so the watchdog blats from the other cpu.
 
  
  on_each_cpu(touch_softlockup_watchdog, NULL, 0, 0)?

He wants to do this with interrupts off. on_each_cpu won't work in
that situation.

  Or patch the softlockup watchdog to add a way to temporarily disable it.

Seems pretty much the only way you could make this work.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Kernel 2.6.20 takes a long time to load

2007-03-25 Thread Dave Jones
On Sun, Mar 25, 2007 at 02:22:08PM +0200, Helmut Auer wrote:
  Hello List,
  
  The kernel 2.6.20 makes a long delay during booting ( about 15 seconds ) 
  after showing:
  
  NET: Registered protocol family 2
  
  then it goes along with:
  
  IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
  TCP established hash table entries: 8192 (order: 4, 98304 bytes)
  ...
  
  I am using the kernel parameter lpj to avoid calculating processor speed 
  during kernel load.
  If I do not use the lpj parameter, the detection of cpu speed takes about 10 
  seconds, but then 
  there is no delay after:
  NET: Registered protocol family 2
  
  Any hints what I can try to get a fast booting kernel ?
  I am using 2.6.20 with some gentoo patches ( plain 2.6.20-4 has the same 
  problem ).

booting with initcall_debug will tell you the last thing it initialised before
the pause, which may give some clues.  Alternatively, git bisect ?

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


  1   2   3   4   5   6   7   8   9   10   >