Re: [patch 3/5] sched: multilevel sbe and sbf

[Ingo Molnar]

* Nick Piggin <[EMAIL PROTECTED]> wrote:

> 3/5

> The fundamental problem that Suresh has with balance on exec and fork
> is that it only tries to balance the top level domain with the flag
> set.
> 
> This was worked around by removing degenerate domains, but is still a
> problem if people want to start using more complex sched-domains, especially
> multilevel NUMA that ia64 is already using.
> 
> This patch makes balance on fork and exec try balancing over not just the
> top most domain with the flag set, but all the way down the domain tree.
> 
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

Acked-by: Ingo Molnar <[EMAIL PROTECTED]>

note that no matter how much scheduler logic, in the end 
cross-scheduling of tasks between nodes on NUMA will always have a 
permanent penalty (i.e. the 'migration cost' is 'infinity' in the long 
run), so the primary focus _hast to be_ on 'get it right initially' When 
tasks must spill over to other nodes will always remain a special case.  
So balance-on-fork/exec/[clone] definitely needs to be aware of the full 
domain tree picture.

Ingo
-
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/5] sched: NULL domains

[Ingo Molnar]

* Nick Piggin <[EMAIL PROTECTED]> wrote:

> 2/5

> The previous patch fixed the last 2 places that directly access a
> runqueue's sched-domain and assume it cannot be NULL.
> 
> We can now use a NULL domain instead of a dummy domain to signify
> no balancing is to happen. No functional changes.
> 
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

Acked-by: Ingo Molnar <[EMAIL PROTECTED]>

Ingo
-
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/5] sched: NULL domains

[Ingo Molnar]

* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> 
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> 
> > 2/5
> 
> > The previous patch fixed the last 2 places that directly access a
> > runqueue's sched-domain and assume it cannot be NULL.
> > 
> > We can now use a NULL domain instead of a dummy domain to signify
> > no balancing is to happen. No functional changes.
> > 
> > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
> 
> Acked-by: Ingo Molnar <[EMAIL PROTECTED]>

if the previous 'remove degenerate domains' patch would go away then 
this patch needs to be merged/modified. (and most of the others as well)

Ingo
-
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/5] sched: remove degenerate domains

[Ingo Molnar]

* Nick Piggin <[EMAIL PROTECTED]> wrote:

> This is Suresh's patch with some modifications.

> Remove degenerate scheduler domains during the sched-domain init.

actually, i'd suggest to not do this patch. The point of booting with a 
CONFIG_NUMA kernel on a non-NUMA box is mostly for testing, and the 
'degenerate' toplevel domain exposed conceptual bugs in the 
sched-domains code. In that sense removing such 'unnecessary' domains 
inhibits debuggability to a certain degree. If we had this patch earlier 
we'd not have experienced the wrong decisions taken by the scheduler, 
only on the much rarer 'really NUMA' boxes.

is there any case where we'd want to simplify the domain tree? One more 
domain level is just one (and very minor) aspect of CONFIG_NUMA - i'd 
not want to run a CONFIG_NUMA kernel on a non-NUMA box, even if the 
domain tree got optimized. Hm?

Ingo
-
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/

chelsio build failure

[Dave Jones]

building this sucker as a module caused grief.

drivers/net/chelsio/cxgb2.c:113: error: `__mod_pci_device_table' aliased
to external symbol `t1_pci_tbl'.

This seems to do the trick. (untested beyond compile)

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

Dave

--- 2.6.12rc2mm1/drivers/net/chelsio/cxgb2.c~   2005-04-06 01:30:07.0 
-0400
+++ 2.6.12rc2mm1/drivers/net/chelsio/cxgb2.c2005-04-06 01:30:20.0 
-0400
@@ -110,7 +110,6 @@ static char driver_version[] = "2.1.0";
 MODULE_DESCRIPTION(MODULE_DESC);
 MODULE_AUTHOR("Chelsio Communications");
 MODULE_LICENSE("GPL");
-MODULE_DEVICE_TABLE(pci, t1_pci_tbl);
 
 static int dflt_msg_enable = DFLT_MSG_ENABLE;
 
--- 2.6.12rc2mm1/drivers/net/chelsio/subr.c~2005-04-06 01:30:25.0 
-0400
+++ 2.6.12rc2mm1/drivers/net/chelsio/subr.c 2005-04-06 01:30:35.0 
-0400
@@ -307,6 +307,7 @@ struct pci_device_id t1_pci_tbl[] = {
CH_DEVICE(10, 1, CH_BRD_N210_1F),
{ 0, }
 };
+MODULE_DEVICE_TABLE(pci, t1_pci_tbl);
 
 /*
  * Return the board_info structure with a given index.  Out-of-range indices
-
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: ext3 allocate-with-reservation latencies

[Mingming Cao]

On Tue, 2005-04-05 at 06:13 +0200, Ingo Molnar wrote:
> * Lee Revell <[EMAIL PROTECTED]> wrote:
> 
> > I can trigger latencies up to ~1.1 ms with a CVS checkout.  It looks
> > like inside ext3_try_to_allocate_with_rsv, we spend a long time in this
> > loop:
> > 
> > ext3_test_allocatable (bitmap_search_next_usable_block)
> > find_next_zero_bit (bitmap_search_next_usable_block)
> > find_next_zero_bit (bitmap_search_next_usable_block)
> > 
> > ext3_test_allocatable (bitmap_search_next_usable_block)
> > find_next_zero_bit (bitmap_search_next_usable_block)
> > find_next_zero_bit (bitmap_search_next_usable_block)
> 
> Breaking the lock is not really possible at that point, and it doesnt 
> look too easy to make that path preemptable either. (To make it 
> preemptable rsv_lock would need to become a semaphore (this could be 
> fine, as it's only used when a new reservation window is created).)

It seems we are holding the rsv_block while searching the bitmap for a
free bit.  In alloc_new_reservation(), we first find a available to
create a reservation window, then we check the bitmap to see if it
contains any free block. If not, we will search for next available
window, so on and on. During the whole process we are holding the global
rsv_lock.  We could, and probably should, avoid that.  Just unlock the
rsv_lock before the bitmap search and re-grab it after it.  We need to
make sure that the available space that are still available after we re-
grab the lock. 

Another option is to hold that available window before we release the
rsv_lock, and if there is no free bit inside that window, we will remove
it from the tree in the next round of searching for next available
window.

I prefer the second option, and plan to code it up soon. Any comments?

Thanks,

Mingming

-
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.12-rc2-mm1 compile error in mmx.c

[Andrew James Wade]

On April 5, 2005 09:22 pm, Berck E. Nash wrote:
> 2.6.12-rc2-mm1 fails to build for me with the following error:
> 
> arch/i386/lib/mmx.c:374: error: conflicting types for `mmx_clear_page'
> include/asm/mmx.h:11: error: previous declaration of `mmx_clear_page'
> make[1]: *** [arch/i386/lib/mmx.o] Error 1
> make: *** [arch/i386/lib] Error 2

I don't know the proper fix, but reversing this patch:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/broken-out/add-a-clear_pages-function-to-clear-pages-of-higher.patch
worked for me.
-
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] Add support for semaphore-like structure with support for asynchronous I/O

[hui]

On Tue, Apr 05, 2005 at 09:20:57PM -0400, Trond Myklebust wrote:
> ty den 05.04.2005 Klokka 11:46 (-0400) skreiv Benjamin LaHaise:
> 
> > I can see that goal, but I don't think introducing iosems is the right 
> > way to acheive it.  Instead (and I'll start tackling this), how about 
> > factoring out the existing semaphore implementations to use a common 
> > lib/semaphore.c, much like lib/rwsem.c?  The iosems can be used as a 
> > basis for the implementation, but we can avoid having to do a giant 
> > s/semaphore/iosem/g over the kernel tree.
> 
> If you're willing to take this on then you have my full support and I'd
> be happy to lend a hand.

I would expect also that some RT subgroups would be highly interested in
getting it to respect priority for reworking parts of softirq.

bill

-
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] add a clear_pages function to clear pages of higher order

[Gerrit Huizenga]

On Tue, 05 Apr 2005 21:48:22 PDT, David Mosberger wrote:
> > On Tue, 5 Apr 2005 17:33:59 -0700 (PDT), Christoph Lameter <[EMAIL 
> > PROTECTED]> said:
> 
>   Christoph> Which benchmark would you recommend for this?
> 
> I don't know about "recommend", but I think SPECweb, SPECjbb,
> the-UNIX-multi-user-benchmark-whose-name-I-keep-forgetting, and in
> general anything that involves process-activity and/or large working
> sets might be interesting (in other words: anything but
> microbenchmarks; I'm afraid).

SpecSDET, Aim7 or ReAim from OSDL are probably what you are thinking
of.

gerrit
-
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] Add support for semaphore-like structure with support for asynchronous I/O

[Suparna Bhattacharya]

On Tue, Apr 05, 2005 at 11:46:41AM -0400, Benjamin LaHaise wrote:
> On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote:
> > IOW: the current semaphore implementations really all need to die, and
> > be replaced by a single generic version to which it is actually
> > practical to add new functionality.
> 
> I can see that goal, but I don't think introducing iosems is the right 
> way to acheive it.  Instead (and I'll start tackling this), how about 
> factoring out the existing semaphore implementations to use a common 
> lib/semaphore.c, much like lib/rwsem.c?  The iosems can be used as a 
> basis for the implementation, but we can avoid having to do a giant 
> s/semaphore/iosem/g over the kernel tree.

That would be really neat, if you can get to it.

Regards
Suparna

> 
> > Failing that, it is _much_ easier to convert the generic code that needs
> > to support aio to use a new locking implementation and then test that.
> > It is not as if conversion to aio won't involve changes to the code in
> > the area surrounding those locks anyway.
> 
> Quite true.  There's a lot more work to do in this area, and these common 
> primatives are needed to make progress.  Someone at netapp sent me an 
> email yesterday asking about aio support in NFS, so there is some demand 
> out there.  Cheers,
> 
>   -ben
> -- 
> "Time is what keeps everything from happening all at once." -- John Wheeler
> --
> To unsubscribe, send a message with 'unsubscribe linux-aio' in
> the body to [EMAIL PROTECTED]  For more info on Linux AIO,
> see: http://www.kvack.org/aio/
> Don't email: mailto:"[EMAIL PROTECTED]">[EMAIL PROTECTED]

-- 
Suparna Bhattacharya ([EMAIL PROTECTED])
Linux Technology Center
IBM Software Lab, India

-
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] add a clear_pages function to clear pages of higher order

[David Mosberger]

> On Tue, 5 Apr 2005 17:33:59 -0700 (PDT), Christoph Lameter <[EMAIL 
> PROTECTED]> said:

  Christoph> Which benchmark would you recommend for this?

I don't know about "recommend", but I think SPECweb, SPECjbb,
the-UNIX-multi-user-benchmark-whose-name-I-keep-forgetting, and in
general anything that involves process-activity and/or large working
sets might be interesting (in other words: anything but
microbenchmarks; I'm afraid).

--david
-
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] Re: [RFC 5/6]clean cpu state after hotremove CPU

[Nathan Lynch]

On Tue, Apr 05, 2005 at 09:55:06AM +0800, Li Shaohua wrote:

> On Mon, 2005-04-04 at 23:33, Nathan Lynch wrote:
> > No.  It should make zero difference to the scheduler whether the "play
> > dead" cpu hotplug or "physical" hotplug is being used.  
> Keeping some fields like 'cpu_load' are meanless for a hotadded CPU to
> me. Just ignore them?

Reinitializing such things during the CPU_UP_PREPARE case in
migration_call should be sufficient, if it's not done already.


Nathan
-
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: Hyperthreading and Kernel 2.4

[Robert Hancock]

[EMAIL PROTECTED] wrote:
Hey,
I apologize in advance if this is not the right place
to ask. Feel free to redirect me there :)
I just wanted to know if the 2.4 kernel is aware of
hyperthreading the same way the 2.6 kernel ist or if
the issues posted earlier
I'm not sure if the stock 2.4 kernels ever had good HT support, but the 
patched 2.4.20 kernel in Red Hat 9, for example, seems to handle it 
reasonably well..

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
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: AMD64 Machine hardlocks when using memset

[Robert Hancock]

Alan Cox wrote:
On Sad, 2005-04-02 at 05:50, Robert Hancock wrote:
I'm wondering if one does a ton of these cache-bypassing stores whether 
something gets hosed because of that. Not sure what that could be 
though. I don't imagine the chipset is involved with any of that on the 
Athlon 64 - either the CPU or RAM seems the most likely suspect to me

The glibc version is essentially the "perfect" copy function for the
CPU. If you have any bus/memory problems or chipset bugs it will bite
you.
Anyone have any suggestions on how to track this further? It seems 
fairly clear what circumstances are causing it, but as for figuring out 
what's at fault..

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
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] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU

[Randy.Dunlap]

Derek Cheung wrote:

Below please find the patch file I "diff" against Linux 2.6.11.6. It
contains the I2C adaptor for ColdFire 5282 CPU. Since most ColdFire
CPU
shares the same I2C register set, the code can be easily adopted for
other ColdFire CPUs for I2C operations.
I have tested the code on a ColdFire 5282Lite CPU board
(http://www.axman.com/Pages/cml-5282LITE.html) running uClinux 2.6.9
with LM75 and DS1621 temperature sensor chips. As advised by David
McCullough, the code will be incorporated in the next uClinux
release.
The patch contains:
linux/drivers/i2c/busses
i2c-mcf5282.c (new file)
Limit source code lines to 80 characters (including comment lines).
+static int mcf5282_read_data():
+	if (ackType == NACK)
+		*MCF5282_I2C_I2CR |= MCF5282_I2C_I2CR_TXAK; // generate NA
+	else
+*MCF5282_I2C_I2CR &= ~MCF5282_I2C_I2CR_TXAK;// 
generate ACK

The 2 assignments above should begin in the same column.
Also, kernel comment style is C /* ... */, not C++ (or C99) // style.
+if (timeout <= 0)
+printk("%s - I2C IIF never set. Timeout is %d \n", 
__FUNCTION__, timeout);

All printk() calls should have a KERN_WARNING or KERN_ERR or
KERN_DEBUG level used in it...
+   if (timeout <= 0 )
No space before the closing ')'.
+static int mcf5282_write_data():
+if (timeout <=0)
should be (add a space)
+if (timeout <= 0)
+   if (timeout <= 0 )
Drop space before ')'
Drop the debugging printk's and DEREK_DEBUG blocks.
+switch (size) {
+case I2C_SMBUS_QUICK:
We usually don't indent the 'case' line to save one indent level.
It helps when using 8-space tabs.
+   // this is not yet ready!!!
Put blocks like this inside
#if 0
or
#if NOT_READY_YET
#endif
blocks.
+static u32 mcf5282_func(struct i2c_adapter *adapter)
+{
+   return(I2C_FUNC_SMBUS_QUICK |
+  I2C_FUNC_SMBUS_BYTE |
+  I2C_FUNC_SMBUS_PROC_CALL |
+  I2C_FUNC_SMBUS_BYTE_DATA |
+  I2C_FUNC_SMBUS_WORD_DATA |
+  I2C_FUNC_SMBUS_BLOCK_DATA);
+};
Don't use parens on return statements.
+static int __init i2c_mcf5282_init():
is not driver registration needed?  I don't know the I2C
subsystem, so maybe not...

Big Question:  does most Coldfire or I2C use volatile so heavily,
or is it just this one driver that does that?  Volatile here
semms very overused.
--
~Randy
-
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] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]

[Chen, Kenneth W]

Ingo Molnar wrote on Monday, April 04, 2005 8:05 PM
>
> latest patch attached. Changes:
>
>  - stabilized calibration even more, by using cache flushing
>instructions to generate a predictable working set. The cache
>flushing itself is not timed, it is used to create quiescent
>cache  state.
>
>I only guessed the ia64 version - e.g. i didnt know what 'type'
>argument to pass to ia64_sal_cache_flush() to get a d/cache
>flush+invalidate.

It is preferable to use a ia64_pal_cache_flush instead of SAL call. But
it hangs the machine with that pal call.  I will look at it tomorrow.
The type argument for sal_cache_flush is: 1 for icache, 2 for dcache,
and 3 for i+d.


>  - due to more stable results, reduced ITERATIONS from 3 to 2 - this
>should further speed up calibration.
>
> tested on x86, the calibration results look ok there.

Calibration result on ia64 (1.5 GHz, 9 MB), somewhat smaller in this
version compare to earlier estimate of 10.4ms.  The optimal setting
found by a db workload is around 16 ms.

-
| migration cost matrix (max_cache_size: 9437184, cpu: -1 MHz):

-
  [00][01][02][03]
[00]: - 9.3(0)  9.3(0)  9.3(0)
[01]:   9.3(0)- 9.3(0)  9.3(0)
[02]:   9.3(0)  9.3(0)- 9.3(0)
[03]:   9.3(0)  9.3(0)  9.3(0)-

| cacheflush times [1]: 9.3 (9329800)
| calibration delay: 16 seconds



-
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] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU

[Greg KH]

On Tue, Apr 05, 2005 at 10:18:15PM -0400, Derek Cheung wrote:
> Hi Greg and Andrew,

After you fix the diff issues that Randy pointed out, please be sure to
 CC: the sensors mailing list as found in the MAINTAINERS file.  I know
they will be able to give you feedback on the code.

thanks,

greg k-h
-
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/

[no subject]

[Abhinkar, Sameer]

unsubscribe linux-kernel
-
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] inotify for 2.6.11

[Adam Kropelin]

I've been meaning to play with inotify for a while now and finally made
time for it tonight. I'm not much of a GUI guy, so I'm mostly interested
in exploring the command line applications of inotify --i.e., what sort of
havoc can I wreak with it in a script.

To that end I sat down tonight a threw together a simple command line
interface. Before I tell you where the code is, please note that I wrote
it while half asleep and more than a little high on cough syrup, so it's
undoubtedly chock full of buffer overflows, infinite loops, segfaults,
and other gremlins just waiting to eat your data, so PLEASE FOR THE LOVE
OF MIKE don't use it on, around, under, or in the general vicinity of,
anything important.

http://www.kroptech.com/~adk0212/watchf.c

The basic usage is...

watchf [-i] [-e]  [-- ...>]  

-i says stay in an infinite loop, don't exit after one event
-e gives the list of events to wait for (see the code)
 is the file or directory to be watched
Everything after -- is taken as a command to run each time an
event ocurrs with any ocurrences of {} being replaced with the
name of the affected file, as returned in the inotify_event
structure.

So what's it good for? Well, besides making fun of my coding skills,
it can be used to watch a directory and run a command when something
changes. For example, a one-line auto-gzip daemon that will haul off and
gzip anything you drop into ./gzipme:

watchf -i -eWT gzipme -- gzip gzipme/{}

Where to go from here? The code is relatively half-baked at the moment,
but I imgaine this could be turned into a relatively useful generic
tool. For example, it should send the filename to stdout and return the
event mask when in single-shot mode. That would make it useful as part
of a longer pipeline.  You should be able to use it to wait for a specific
file to be created --although that will be interesting if one or more 
segments of the path don't exist yet.  Ultimately I'd like to get rid of
the  argument(s), but I can't think of any way to do it
that isn't going to end up missing events.

--Adam

-
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] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU

[Randy.Dunlap]

Derek Cheung wrote:

Below please find the patch file I "diff" against Linux 2.6.11.6. It
contains the I2C adaptor for ColdFire 5282 CPU. Since most ColdFire
CPU
shares the same I2C register set, the code can be easily adopted for
other ColdFire CPUs for I2C operations.
I have tested the code on a ColdFire 5282Lite CPU board
(http://www.axman.com/Pages/cml-5282LITE.html) running uClinux 2.6.9
with LM75 and DS1621 temperature sensor chips. As advised by David
McCullough, the code will be incorporated in the next uClinux
release.
The patch contains:
linux/drivers/i2c/busses
i2c-mcf5282.c (new file)
i2c-mcf5282.h (new file)
Kconfig (modified)
Makefile (modified)
It also includes Kconfig.orig & Makefile.orig &
m528xsim.h.orig .
You should use
  diff -X dontdiff
where dontdiff is a filename to exclude the listed files,
where dontdiff includes *.orig .
There is a fairly up-to-date dontdiff file available at
http://developer.osdl.org/rddunlap/doc/dontdiff-osdl
A diffstat summary would (hereby requested in the future)
would let us see which files are modified and how much
they are modified:
 drivers/i2c/busses/Kconfig|   10
 drivers/i2c/busses/Kconfig.orig   |  489 
++
 drivers/i2c/busses/Makefile   |2
 drivers/i2c/busses/Makefile.orig  |   46 +++
 drivers/i2c/busses/i2c-mcf5282.c  |  407 

 drivers/i2c/busses/i2c-mcf5282.h  |   45 +++
 include/asm-m68knommu/m528xsim.h  |  112 +++
 include/asm-m68knommu/m528xsim.h.orig |   45 +++
 8 files changed, 1156 insertions(+)


 
linux/include/asm-m68knommu
 		m528xsim.h (modified)

Please let me know if you have any questions.

The patch was very wordwrapped by your email client.  Please fix that up
(first email the patch to yourself and test that the result still
applies OK) or
resend as an email attachment.
linux_dev/include/asm-m68knommu/m528xsim.h:
some spaces in this expression (& elsewhere) would make it
easier to read:
+#define MCF5282_I2C_I2ADR_ADDR(x) 
(((x)&0x7F)<<0x01)

Oh, it's not even used don't need it then.
And this one is not used:
+#define MCF5282_I2C_I2FDR_IC(x) (((x)&0x3F))
Lots of the bit-level definitions aren't used and usually aren't
added unless used.
Comment (7) doesn't match name (hm, and it's not used):
+/* Interrupt Control Register 7 */
+#define MCF5282_INTC0_ICR17 (volatile u8 *) (MCF_IPSBAR + 0x0C51)
These are not used -- but if they were, we generally like to
have macro expressions wrapped in parentheses:
+#define MCF5282_QSPI_QMRMCF_IPSBAR + 0x0340
+#define MCF5282_QSPI_QDLYR  MCF_IPSBAR + 0x0344
+#define MCF5282_QSPI_QWRMCF_IPSBAR + 0x0348
+#define MCF5282_QSPI_QIRMCF_IPSBAR + 0x034C
+#define MCF5282_QSPI_QARMCF_IPSBAR + 0x0350
+#define MCF5282_QSPI_QDRMCF_IPSBAR + 0x0354
+#define MCF5282_QSPI_QCRMCF_IPSBAR + 0x0354
i2c-mcf5282.h:
Please limit line lengths to 80 characters in source files:  e.g.:
+static int mcf5282_i2c_start(const char read_write, const u16 
target_address, const enum I2C_START_TYPE i2c_start);

What is this one for?
+void dumpReg(char *, u16 addr, u8 data);
I'm looking over the primary .c file separately now.
--
~Randy
-
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/

[no subject]

[husiyev]

$B"#"""#(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B
(B $B!!7k:'!?M!'C#(B
(B $BM}A[$NAjhttp://www.deai2005.com/user.app?cmd=entry&[EMAIL PROTECTED]=sp
(B 
(B $B"!"!2K$J?M!"Nx?M!&7k:'$r9M$($F$$$k$J$i"!"!(B
(B $B!!4JC1A`:n$G%9%H%l%9$J$/4uK>$NAje(B!!
(B $B!!9%$_$NAjhttp://www.deai2005.com/user.app?cmd=entry&[EMAIL PROTECTED]=sp
(B 
(B $B"#"#"#"#"#"#"#!!(B1$BF|$N%"%/%;%9?M?t!X(B12$BK|?MFMGK(B!!$B!Y(B 
$B"#"#"#"#"#"#"#(B
(B $B!!!y$b$([EMAIL PROTECTED](B29$B:[EMAIL PROTECTED](B31$B:[EMAIL 
(BPROTECTED]@-!!(B51$B:P(B
(B $B!!!y$J$J$([EMAIL PROTECTED](B27$B:[EMAIL PROTECTED](B39$B:[EMAIL 
(BPROTECTED](B42$B:P(B
(B [EMAIL PROTECTED](B39$B:[EMAIL PROTECTED](B21$B:[EMAIL PROTECTED](B22$B:P(B
(B $B!!!y>f<[EMAIL PROTECTED](B61$B:[EMAIL PROTECTED](B29$B:[EMAIL 
(BPROTECTED](B21$B:P(B
(B $BB>!"B??t!*%.%c%k!&(BOL$B!&%;%l%V!&%5%i%j!<%^%s!&0e;U(Betc
(B 
(B $B"-"-L5NABN83"-"-(B
(B http://www.deai2005.com/user.app?cmd=entry&[EMAIL PROTECTED]=sp
(B 
(B [EMAIL PROTECTED](B!!
(B $B40A4L5NA$G$*Ajhttp://www.deai2005.com/user.app?cmd=entry&[EMAIL PROTECTED]=sp
(B 
(B $B"((B18$B:PL$K~$NJ}$N$4MxMQ$r8G$/$*CG$j$7$F$*$j$^$9!#(B
(B 
(B 
(B 
(B
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at  http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at  http://www.tux.org/lkml/

Re: Scheduling tasklets from process context...

[Kenneth Aafløy]

On Wednesday 06 April 2005 04:50, you wrote:
> Since tasklets are typically used for bottom half processing, is it
> acceptable/recommended that they be scheduled from a process context
> (say an ioctl handler)? 
> 
> Should one try to minimize such scheduling and try to do things in process
> context if possible, as tasklets run in interrupt context? Or is the driver
> writer free to use the tasklets at will? What is recommended here?

A tasklet does not run in interrupt context, it runs as a high priority thread,
that is scheduled from either user or interrupt context. The purpose is mostly
to defer workloads from interrupt context, to reduce the time spent with
interrupts disabled.

It would make sense to defer work from userspace to a tasklet if the hardware
takes an unusual amount of time to process the userspace data.

Correct me if I'm wrong :)

Kenneth
-
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/

Scheduling tasklets from process context...

[arun.prabha]

Hi,

I have a query.

Since tasklets are typically used for bottom half
processing, is it acceptable/recommended that they
be scheduled from a process context (say an ioctl handler)?

Should one try to minimize such scheduling and try to
do things in process context if possible, as tasklets run
in interrupt context? Or is the driver writer free to use
the tasklets at will? What is recommended here?

Thanks in advance,
Arun.
-
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.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop

[Shawn Starr]

So nobody minds if I make this into a CONFIG option marked as Deprecated? :)

Shawn.

>
> > Do you know if /proc/acpi/sleep will be deprecated in
> > favour of /sys/power/state? If so, this thread will be
> > moot ;)
>
> No idea, deprecating it would be ok with me.
>
>Pavel


pgpGfWAs0n7J0.pgp
Description: PGP signature

Re: Coding style: mixed-case

[Kenneth Aafløy]

On Wednesday 06 April 2005 04:09, Matt Mackall wrote:
> While there may be reasons why mixed case is suboptimal, the real
> reason is that it's hard to keep track of which style is used where.
> It's annoying and error-prone to have to remember the naming format
> for everything in addition to its name. As most things are in a
> standard style, things are made easier by having every piece of new
> code follow that style and let us slowly approach uniformity.

My primary concern was that of; why does the kernels own coding style
deviate from that advise given in it's documentation. Other than that
most mixed-case errors will be caught by the compiler, unless there
is an ambiguity with other mixed-case statements; which is probably
why that clause exists in the coding style documentation.

> If you posted a patch for pf_locked() and friends (and note that it's
> lowercase to match function-like usage), you'd probably find some
> enthusiasts and some naysayers. Most of the naysayers would object on
> the grounds of "it ain't broke", but if someone were to do it as part
> of a series of more substantial clean-ups, it'd likely be accepted.

Certainly I would like to have a go at a patch, but I must say that I do not
feel particularly familiar with the code in question to make such a change.
I would have risen to the challenge had this been a driver level change,
but the mmu is something that I will not touch untill I feel comfortable.
I feel that this is a change that would be best managed by an experienced
kernel janitor.

Kenneth
-
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] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU

[Derek Cheung]

Thanks Andrew. Enclosed please find the patch file.

Regards, 
Derek

-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED] 
Sent: April 5, 2005 10:22 PM
To: Derek Cheung
Cc: [EMAIL PROTECTED]; Linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU

"Derek Cheung" <[EMAIL PROTECTED]> wrote:
>
>  Below please find the patch file I "diff" against Linux 2.6.11.6. It
>  contains the I2C adaptor for ColdFire 5282 CPU. Since most ColdFire
CPU
>  shares the same I2C register set, the code can be easily adopted for
>  other ColdFire CPUs for I2C operations.
> 
>  I have tested the code on a ColdFire 5282Lite CPU board
>  (http://www.axman.com/Pages/cml-5282LITE.html) running uClinux 2.6.9
>  with LM75 and DS1621 temperature sensor chips. As advised by David
>  McCullough, the code will be incorporated in the next uClinux
release.
> 
>  The patch contains:
> 
>  linux/drivers/i2c/busses
>   i2c-mcf5282.c (new file)
>   i2c-mcf5282.h (new file)
>   Kconfig (modified)
>   Makefile (modified)
>   
>  linux/include/asm-m68knommu
>   m528xsim.h (modified)
> 
>  Please let me know if you have any questions.

The patch was very wordwrapped by your email client.  Please fix that up
(first email the patch to yourself and test that the result still
applies OK) or
resend as an email attachment.

Thanks.


linux_patch
Description: Binary data

Re: [PATCH] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU

[Andrew Morton]

"Derek Cheung" <[EMAIL PROTECTED]> wrote:
>
>  Below please find the patch file I "diff" against Linux 2.6.11.6. It
>  contains the I2C adaptor for ColdFire 5282 CPU. Since most ColdFire CPU
>  shares the same I2C register set, the code can be easily adopted for
>  other ColdFire CPUs for I2C operations.
> 
>  I have tested the code on a ColdFire 5282Lite CPU board
>  (http://www.axman.com/Pages/cml-5282LITE.html) running uClinux 2.6.9
>  with LM75 and DS1621 temperature sensor chips. As advised by David
>  McCullough, the code will be incorporated in the next uClinux release.
> 
>  The patch contains:
> 
>  linux/drivers/i2c/busses
>   i2c-mcf5282.c (new file)
>   i2c-mcf5282.h (new file)
>   Kconfig (modified)
>   Makefile (modified)
>   
>  linux/include/asm-m68knommu
>   m528xsim.h (modified)
> 
>  Please let me know if you have any questions.

The patch was very wordwrapped by your email client.  Please fix that up
(first email the patch to yourself and test that the result still applies OK) or
resend as an email attachment.

Thanks.
-
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/

[PATCH] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU

[Derek Cheung]

Hi Greg and Andrew,

Below please find the patch file I "diff" against Linux 2.6.11.6. It
contains the I2C adaptor for ColdFire 5282 CPU. Since most ColdFire CPU
shares the same I2C register set, the code can be easily adopted for
other ColdFire CPUs for I2C operations.

I have tested the code on a ColdFire 5282Lite CPU board
(http://www.axman.com/Pages/cml-5282LITE.html) running uClinux 2.6.9
with LM75 and DS1621 temperature sensor chips. As advised by David
McCullough, the code will be incorporated in the next uClinux release.

The patch contains:

linux/drivers/i2c/busses
i2c-mcf5282.c (new file)
i2c-mcf5282.h (new file)
Kconfig (modified)
Makefile (modified)
 
linux/include/asm-m68knommu
m528xsim.h (modified)

Please let me know if you have any questions.

Regards
Derek

Signed-off-by: Derek CL Cheung [EMAIL PROTECTED]
===

diff -uprN -X dontdiff linux-2.6.11.6/drivers/i2c/busses/i2c-mcf5282.c
linux_dev/drivers/i2c/busses/i2c-mcf5282.c
--- linux-2.6.11.6/drivers/i2c/busses/i2c-mcf5282.c 1969-12-31
19:00:00.0 -0500
+++ linux_dev/drivers/i2c/busses/i2c-mcf5282.c  2005-04-05
19:21:55.0 -0400
@@ -0,0 +1,407 @@
+/*
+i2c-mcf5282.c - Part of lm_sensors, Linux kernel modules for
hardware monitoring
+
+Copyright (c) 2005, Derek CL Cheung <[EMAIL PROTECTED]>
+

+
+This program is free software; you can redistribute it and/or
modify
+it under the terms of the GNU General Public License as published
by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+Changes:
+v0.1   26 March 2005
+   Initial Release - developed on uClinux with 2.6.9 kernel
+
+
+This I2C adaptor supports the ColdFire 5282 CPU I2C module. Since
most Coldfire
+CPUs' I2C module use the same register set (e.g., MCF5249), the
code is very
+portable and re-usable to other Coldfire CPUs.
+
+The transmission frequency is set at about 100KHz for the 5282Lite
CPU board with
+8MHz crystal. If the CPU board uses different system clock
frequency, you should
+change the following line:
+static int __init i2c_mcf5282_init(void)
+{
+.
+// Set transmission frequency 0x15 = ~100kHz
+*MCF5282_I2C_I2FDR = 0x15;
+
+}
+
+Remember to perform a dummy read to set the ColdFire CPU's I2C
module for read before
+reading the actual byte from a device
+
+The I2C_SM_BUS_BLOCK_DATA function are not yet ready but most
lm_senors do not care
+
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "i2c-mcf5282.h"
+
+
+static struct i2c_algorithm mcf5282_algorithm = {
+   .name   = "MCF5282 I2C algorithm",
+   .id = I2C_ALGO_SMBUS,
+   .smbus_xfer = mcf5282_i2c_access,
+   .functionality  = mcf5282_func,
+};
+
+
+static struct i2c_adapter mcf5282_adapter = {
+   .owner  = THIS_MODULE,
+   .class  = I2C_CLASS_HWMON,
+   .algo   = _algorithm,
+   .name   = "MCF5282 I2C Adapter",
+};
+
+
+/*
+ *  read one byte data from the I2C bus
+ */
+static int mcf5282_read_data(u8 * const rxData, const enum I2C_ACK_TYPE
ackType) {
+
+int timeout;
+
+   *MCF5282_I2C_I2CR &= ~MCF5282_I2C_I2CR_MTX; //
master receive mode
+
+   if (ackType == NACK)
+   *MCF5282_I2C_I2CR |= MCF5282_I2C_I2CR_TXAK; //
generate NA
+   else
+*MCF5282_I2C_I2CR &= ~MCF5282_I2C_I2CR_TXAK;//
generate ACK
+
+
+   // read data from the I2C bus
+   *rxData = *MCF5282_I2C_I2DR; 
+
+   // printk(">>> %s I2DR data is %.2x \n", __FUNCTION__, *rxData);
+
+// wait for data transfer to complete 
+timeout = 500;
+while (timeout-- && !(*MCF5282_I2C_I2SR &
MCF5282_I2C_I2SR_IIF))
+udelay(1);
+if (timeout <= 0) 
+printk("%s - I2C IIF never set. Timeout is %d \n",
__FUNCTION__, timeout);
+
+
+// reset the interrupt bit 
+*MCF5282_I2C_I2SR &= ~MCF5282_I2C_I2SR_IIF;
+
+   if (timeout <= 0 ) 
+return -1;
+else 
+   

Re: 2.6.12-rc2-mm1

[Neil Brown]

On Tuesday April 5, [EMAIL PROTECTED] wrote:
> 
> - Nobody said anything about the PM resume and DRI behaviour in
>   2.6.12-rc1-mm4.  So it's all perfect now?

Well, Seeing you asked...

PM resume certainly seems to be improving.
My main problem in rc1-mm3 is with PCMCIA.
If I stop cardmgr before suspend-to-RAM, and then try to
restart it after resume, I cannot.  Some message about the socket
being in use, and am I sure there is no other cardmgr running (there
isn't). 

I can stop and restart happily before suspending, but not after.
If I leave it running during a suspend/resume cycle it keeps working
but if I then stop and restart, it fails.

(and if I do leave it running, my PCMCIA wireless gets started before
my tg3 wired, so eth0 and eth1 get swapped).

I just tried rc2-mm1 and... decided to go back to rc1-mm3.

It seemed to boot mostly OK.  I tried suspend-to-RAM and it seems to
suspend.  But when I turned it back on again it rebooted rather than
resumed.

During boot I got:

Apr  6 10:18:46 localhost kernel: cs: memory probe 
0xf600-0xfbff:iounmap: bad address f8828000
Apr  6 10:18:46 localhost kernel:  [set_cis_map+150/256] set_cis_map+0x96/0x100
Apr  6 10:18:46 localhost kernel:  [remove_vm_area+60/80] 
remove_vm_area+0x3c/0x50
Apr  6 10:18:46 localhost kernel:  [pcmcia_read_cis_mem+412/560] 
pcmcia_read_cis_mem+0x19c/0x230
Apr  6 10:18:46 localhost kernel:  [set_cis_map+150/256] set_cis_map+0x96/0x100
Apr  6 10:18:46 localhost kernel:  [read_cis_cache+358/400] 
read_cis_cache+0x166/0x190
Apr  6 10:18:46 localhost kernel:  [follow_link+141/544] follow_link+0x8d/0x220
Apr  6 10:18:46 localhost kernel:  [pccard_get_next_tuple+688/784] 
pccard_get_next_tuple+0x2b0/0x310
Apr  6 10:18:46 localhost kernel:  [pccard_get_first_tuple+144/336] 
pccard_get_first_tuple+0x90/0x150
Apr  6 10:18:46 localhost kernel:  [pccard_validate_cis+151/592] 
pccard_validate_cis+0x97/0x250
Apr  6 10:18:46 localhost kernel:  [readable+90/160] readable+0x5a/0xa0
Apr  6 10:18:46 localhost kernel:  [cis_readable+129/224] cis_readable+0x81/0xe0
Apr  6 10:18:46 localhost kernel:  [do_mem_probe+469/496] 
do_mem_probe+0x1d5/0x1f0
Apr  6 10:18:46 localhost kernel:  [inv_probe+159/176] inv_probe+0x9f/0xb0
Apr  6 10:18:46 localhost kernel:  [validate_mem+271/304] 
validate_mem+0x10f/0x130
Apr  6 10:18:46 localhost kernel:  [default_wake_function+0/32] 
default_wake_function+0x0/0x20
Apr  6 10:18:46 localhost kernel:  [pcmcia_nonstatic_validate_mem+120/128] 
pcmcia_nonstatic_validate_mem+0x78/0x80
Apr  6 10:18:46 localhost kernel:  [pcmcia_validate_mem+26/32] 
pcmcia_validate_mem+0x1a/0x20
Apr  6 10:18:46 localhost kernel:  [pcmcia_card_add+42/208] 
pcmcia_card_add+0x2a/0xd0


Then it hung in some device discovery.  Not sure which device, maybe
firewire.
Alt-Sysrq-T showed

Apr  6 10:19:45 localhost kernel: khpsbpkt  S C04643E0 0  1956  1   
   1973   915 (L-TLB)
Apr  6 10:19:45 localhost kernel: f6cf3f94 0046 f68dd070 c04643e0 f7c0f030 
c0464410  f7c0f030 
Apr  6 10:19:45 localhost kernel:f6cf3f8c    
f68dd070 f68dd198 f8af2444 f6cf2000 
Apr  6 10:19:45 localhost kernel:0246 f68dd070 c031ce5d f8af244c 
 0001 f68dd070 c0114a70 
Apr  6 10:19:45 localhost kernel: Call Trace:
Apr  6 10:19:45 localhost kernel:  [__down_interruptible+157/300] 
__down_interruptible+0x9d/0x12c
Apr  6 10:19:45 localhost kernel:  [default_wake_function+0/32] 
default_wake_function+0x0/0x20
Apr  6 10:19:45 localhost kernel:  [__down_failed_interruptible+7/12] 
__down_failed_interruptible+0x7/0xc
Apr  6 10:19:45 localhost kernel:  [pg0+945105653/1067918336] 
.text.lock.ieee1394_core+0x1b/0x26 [ieee1394]
Apr  6 10:19:45 localhost kernel:  [pg0+945105424/1067918336] 
hpsbpkt_thread+0x0/0xb0 [ieee1394]
Apr  6 10:19:45 localhost kernel:  [kernel_thread_helper+5/24] 
kernel_thread_helper+0x5/0x18

Apr  6 10:19:45 localhost kernel: knodemgrd_0   S C04643E0 0  1973  1   
   2023  1956 (L-TLB)
Apr  6 10:19:45 localhost kernel: f7e75f7c 0046 f7c0f030 c04643e0 a1ff 
 c018a7cc f648e62c 
Apr  6 10:19:45 localhost kernel:f6ec8380    
f7c0f030 f7c0f158 f6f6b670 f7e74000 
Apr  6 10:19:45 localhost kernel:0246 f7c0f030 c031ce5d f6f6b678 
 0001 f7c0f030 c0114a70 
Apr  6 10:19:45 localhost kernel: Call Trace:
Apr  6 10:19:45 localhost kernel:  [sysfs_make_dirent+44/160] 
sysfs_make_dirent+0x2c/0xa0
Apr  6 10:19:45 localhost kernel:  [__down_interruptible+157/300] 
__down_interruptible+0x9d/0x12c
Apr  6 10:19:45 localhost kernel:  [default_wake_function+0/32] 
default_wake_function+0x0/0x20
Apr  6 10:19:45 localhost kernel:  [__down_failed_interruptible+7/12] 
__down_failed_interruptible+0x7/0xc
Apr  6 10:19:45 localhost kernel:  [pg0+945133083/1067918336] 
.text.lock.nodemgr+0x112/0x1a7 [ieee1394]
Apr  6 10:19:45 localhost kernel:  [pg0+945131536/1067918336] 
nodemgr_host_thread+0x0/0x190 [ieee1394]
Apr 

Re: Coding style: mixed-case

[Matt Mackall]

On Wed, Apr 06, 2005 at 03:29:21AM +0200, Kenneth Aafl?y wrote:
> Hi,
> 
> while reading Documentation/CodingStyle for the nth time, I realized that I 
> had
> read some conflicting coding style in some patch posted to the linux-kernel
> mailing-list; in include/linux/page-flags.h, there is a lot of defines that 
> are
> apparently frowned upon:
> 
> HOWEVER, while mixed-case names are frowned upon, descriptive names for
> global variables are a must.  To call a global function "foo" is a
> shooting offense.
> 
> Are those an exception to the rule or would for example
> PF_LOCKED/pf_locked be a nice replacement for PageLocked?

While there may be reasons why mixed case is suboptimal, the real
reason is that it's hard to keep track of which style is used where.
It's annoying and error-prone to have to remember the naming format
for everything in addition to its name. As most things are in a
standard style, things are made easier by having every piece of new
code follow that style and let us slowly approach uniformity.

If you posted a patch for pf_locked() and friends (and note that it's
lowercase to match function-like usage), you'd probably find some
enthusiasts and some naysayers. Most of the naysayers would object on
the grounds of "it ain't broke", but if someone were to do it as part
of a series of more substantial clean-ups, it'd likely be accepted.

-- 
Mathematics is the supreme nostalgia of our time.
-
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.12-rc2-mm1: ACPI=y, ACPI_BOOT=n problems

[Andrew Morton]

Steven Cole <[EMAIL PROTECTED]> wrote:
>
> arch/i386/kernel/setup.c: In function 'setup_arch':
>  arch/i386/kernel/setup.c:1571: warning: implicit declaration of function 
> 'acpi_boot_table_init'
>  arch/i386/kernel/setup.c:1572: warning: implicit declaration of function 
> 'acpi_boot_init'


diff -puN include/linux/acpi.h~no-acpi-build-fix include/linux/acpi.h
--- 25/include/linux/acpi.h~no-acpi-build-fix   2005-04-05 00:14:46.0 
-0700
+++ 25-akpm/include/linux/acpi.h2005-04-05 00:23:39.0 -0700
@@ -418,16 +418,6 @@ extern int sbf_port ;
 
 #define acpi_mp_config 0
 
-static inline int acpi_boot_init(void)
-{
-   return 0;
-}
-
-static inline int acpi_boot_table_init(void)
-{
-   return 0;
-}
-
 #endif /*!CONFIG_ACPI_BOOT*/
 
 unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low);
@@ -538,5 +528,18 @@ static inline int acpi_get_pxm(acpi_hand
 
 extern int pnpacpi_disabled;
 
+#else  /* CONFIG_ACPI */
+
+static inline int acpi_boot_init(void)
+{
+   return 0;
+}
+
+static inline int acpi_boot_table_init(void)
+{
+   return 0;
+}
+
 #endif /* CONFIG_ACPI */
+
 #endif /* _LINUX_ACPI_H */
_

-
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] Re: It's getting worse: 2.6.12-rc2-mm1 and suspend2ram

[Andrew Morton]

Norbert Preining <[EMAIL PROTECTED]> wrote:
>
> On Die, 05 Apr 2005, Pavel Machek wrote:
> > Well, I do not have working suspend-to-RAM setup close to me... Could
> > you try 2.6.12-rc1 to see if reboot problem is -mm specific or not?
> 
> 2.6.12-rc2 suspends and resumes with the very same config file (well,
> after running make oldconfig) without any problem.
> 
> So there is a change in -mm1 which triggers this. Should I start with
> backing out bk-acpi? or anything else?

bk-acpi would be a good choice.  It might be easier to start with
2.6.12-rc2 and add stuff, see when it breaks.

bk-acpi and bk-driver-core would be prime suspects.

Thanks for the help on this.
-
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/

Coding style: mixed-case

[Kenneth Aafløy]

Hi,

while reading Documentation/CodingStyle for the nth time, I realized that I had
read some conflicting coding style in some patch posted to the linux-kernel
mailing-list; in include/linux/page-flags.h, there is a lot of defines that are
apparently frowned upon:

HOWEVER, while mixed-case names are frowned upon, descriptive names for
global variables are a must.  To call a global function "foo" is a
shooting offense.

Are those an exception to the rule or would for example PF_LOCKED/pf_locked be
a nice replacement for PageLocked?

Just wondering; with no intention to change code that I do not understand :)

Kenneth
-
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.12-rc2-mm1 -- arch/i386/lib/mmx.c:374: error: conflicting types for `mmx_clear_page' include/asm/mmx.h:11: error: previous declaration of `mmx_clear_page' make[1]: *** [arch/i386/lib/mmx.o] Error 1

[Miles Lane]

arch/i386/lib/mmx.c:374: error: conflicting types for `mmx_clear_page'
include/asm/mmx.h:11: error: previous declaration of `mmx_clear_page'
make[1]: *** [arch/i386/lib/mmx.o] Error 1

CONFIG_X86_PC=y
CONFIG_MK7=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=m
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m


Linux Monkey100 2.6.12-rc1-mm4 #8 PREEMPT Thu Mar 31 13:41:55 EST 2005
i686 GNU/Linux

Gnu C  3.3.5
Gnu make   3.80
binutils   2.15
util-linux 2.12p
mount  2.12p
module-init-tools  3.2-pre1
e2fsprogs  1.37
reiserfsprogs  line
reiser4progs   line
xfsprogs   2.6.28
pcmcia-cs  3.2.5
PPP2.4.3
nfs-utils  1.0.7
Linux C Library2.3.2
Dynamic linker (ldd)   2.3.2
Procps 3.2.5
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.2.1
udev   056
Modules Loaded lp ipx p8022 psnap llc af_packet ndiswrapper
sata_nv ehci_hcd dm_mod autofs4 sd_mod sata_sil libata scsi_mod 3c59x
forcedeth floppy parport_pc parport eth1394 evdev psmouse ohci1394
ieee1394 ohci_hcd uhci_hcd usbcore pcmcia firmware_class yenta_socket
rsrc_nonstatic pcmcia_core video thermal processor hotkey fan button
battery ac ide_cd cdrom
-
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: [Ext2-devel] Re: OOM problems on 2.6.12-rc1 with many fsx tests

[Andrew Morton]

Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> I run the test(20 instances of fsx) with your patch on 2.6.12-rc1 with
>  512MB RAM (where I were able to constantly re-create the mem leak and
>  lead to OOM before). The result is the kernel did not get into OOM after
>  about 19 hours(before it took about 9 hours or so), system is still
>  responsive. However I did notice about ~60MB delta between Active
>  +Inactive and Buffers+cached+Swapcached+Mapped+Slab

yes.

Nobody has noticed the now-fixed leak since 2.6.6 and this one appears to
be 100x slower.  Which is fortunate because this one is going to take a
long time to fix.  I'll poke at it some more.
-
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.12-rc2-mm1 compile error in mmx.c

[Berck E. Nash]

2.6.12-rc2-mm1 fails to build for me with the following error:
arch/i386/lib/mmx.c:374: error: conflicting types for `mmx_clear_page'
include/asm/mmx.h:11: error: previous declaration of `mmx_clear_page'
make[1]: *** [arch/i386/lib/mmx.o] Error 1
make: *** [arch/i386/lib] Error 2
I hope this is useful-- I apologize if it is not.  (I browsed the 
archives, and no one seems to be complaining of the same thing so far.) 
 I'm not subscribed to the list, but I'll gladly provide more 
information if you CC me on a response.
-
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] inotify for 2.6.11

[Robert Love]

On Tue, 2005-04-05 at 17:53 -0700, Rusty Lynch wrote:

> From just a casual look, it seems like this could be used to monitor the
> comings and goings of processes by monitoring /proc.  Unfortunately
> inotify doesn't seem to be getting all the events on the proc filesystem
> like it does on a real filesystem because I am not seeing new events every
> time a new process is added or removed.  The same is true if you attempt
> to monitor something like /sys/bus/usb/devices/ and add/remove a usb
> device.
> 
> On a side note, it's still rather interesting to monitor /proc and watch
> all the traffic.

Yah, I agree.  I looked into doing this awhile back, when I noticed
inotify did not generate events for /proc.  We just need to add calls to
the fsnotify hooks to the proc_create() and proc_delete_foo() stuff.

The interfaces are capable, e.g. we can add support at anytime, even
after inotify is merged.  I'd be for it.

Robert Love


-
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] Add support for semaphore-like structure with support for asynchronous I/O

[Trond Myklebust]

ty den 05.04.2005 Klokka 11:46 (-0400) skreiv Benjamin LaHaise:

> I can see that goal, but I don't think introducing iosems is the right 
> way to acheive it.  Instead (and I'll start tackling this), how about 
> factoring out the existing semaphore implementations to use a common 
> lib/semaphore.c, much like lib/rwsem.c?  The iosems can be used as a 
> basis for the implementation, but we can avoid having to do a giant 
> s/semaphore/iosem/g over the kernel tree.

If you're willing to take this on then you have my full support and I'd
be happy to lend a hand.

Cheers,
  Trond
-- 
Trond Myklebust <[EMAIL PROTECTED]>

-
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.12-rc2-mm1

[Andrew Morton]

"Barry K. Nathan" <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 05, 2005 at 06:44:08AM -0700, Barry K. Nathan wrote:
> > swsusp: reading slkf;jalksfsadflkjas;dlfasdfkl (12345 pages): 34%
> > [sorry, I just got up so my short-term memory isn't working that well
> > yet]
> > 
> > takes 10-30 minutes (depending on whether it's closer to 11000 pages or
> > 2) rather than the 5-10 seconds or so that it takes under 2.6.11-ac5
> > (or mainline 2.6.11 if I remember correctly).

Odd.

> [snip]
> > I'll try to do some more testing to see (a) when this problem started
> > and (b) whether it still exists in 2.6.12-rc2 or later. This is going to
> > be ridiculously difficult for me to fit into my schedule right now, but
> > I'll try
> 
> 2.6.11-bk9 works (actually it takes under 2 seconds, not 5-10).
> 2.6.11-bk10 has the weird slowdown.

Unfortunately that's a pretty bug diff (2 megs).

The only thing I can see in the memory reclaim area is this:

--- b/mm/vmscan.c   2005-03-10 00:39:02 -08:00
+++ b/mm/vmscan.c   2005-03-13 15:29:39 -08:00
@@ -313,8 +313,20 @@
 */
if (!is_page_cache_freeable(page))
return PAGE_KEEP;
-   if (!mapping)
+   if (!mapping) {
+   /*
+* Some data journaling orphaned pages can have
+* page->mapping == NULL while being dirty with clean buffers.
+*/
+   if (PageDirty(page) && PagePrivate(page)) {
+   if (try_to_free_buffers(page)) {
+   ClearPageDirty(page);
+   printk("%s: orphaned page\n", __FUNCTION__);
+   return PAGE_CLEAN;
+   }
+   }
return PAGE_KEEP;
+   }
if (mapping->a_ops->writepage == NULL)
return PAGE_ACTIVATE;
if (!may_write_to_queue(mapping->backing_dev_info))

but you'd be getting a printk storm if that was triggering.

> I'll see if I can isolate it any further.

Please, that would help.
-
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: [03/08] fix ia64 syscall auditing

[Dave Jones]

On Tue, Apr 05, 2005 at 05:05:04PM -0700, Greg KH wrote:
 > On Tue, 2005-04-05 at 19:46 -0400, Ryan Anderson wrote:
 > > highlight WhitespaceEOL ctermbg=red guibg=red
 > > match WhitespaceEOL /\s\+$/
 > 
 > Very nice, thanks a lot for that.
 
let c_space_errors=1  also works great.

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: [PATCH] add a clear_pages function to clear pages of higher order

[Christoph Lameter]

On Tue, 5 Apr 2005, David Mosberger wrote:

> What LMbench test other than fork/exec would you have expected to be
> affected by this?  LMbench is not a good benchmark for this (remember:
> it's a _micro_ benchmark).

LMbench does a variety of things and I expected to see at least
something on the page fault test and hopefully also some variations for
other tests.

Which benchmark would you recommend for this?

-
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] add a clear_pages function to clear pages of higher order

[David Mosberger]

> On Tue, 5 Apr 2005 17:15:53 -0700 (PDT), Christoph Lameter <[EMAIL 
> PROTECTED]> said:

  Christoph> On Thu, 24 Mar 2005, David Mosberger wrote:
  >> That's definitely the case.  See my earlier post on this topic:

  >> http://www.gelato.unsw.edu.au/linux-ia64/0409/11012.html

  >> Unfortunately, nobody reported any results for larger machines
  >> and/or more interesting workloads, so the patch is in limbo at
  >> this time.  Clearly, if the CPU that's clearing the page is
  >> likely to use that same page soon after, it'd be useful to use
  >> temporal stores.

  Christoph> Here are some numbers using lmbench of temporal writes
  Christoph> vs. non temporal writes on ia64 (8p machine but lmbench
  Christoph> run only for one load). There seems to be some benefit
  Christoph> for fork/exec but overall this does not seem to be a
  Christoph> clear win. I suspect that the distinction between
  Christoph> temporal vs. nontemporal writes is be more beneficial on
  Christoph> machines with smaller pagesizes since the likelyhood that
  Christoph> most cachelines of a page are used soon is increased and
  Christoph> therefore hot zeroing is more beneficial.

What LMbench test other than fork/exec would you have expected to be
affected by this?  LMbench is not a good benchmark for this (remember:
it's a _micro_ benchmark).

--david
-
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] add a clear_pages function to clear pages of higher order

[Christoph Lameter]

On Thu, 24 Mar 2005, David Mosberger wrote:

> That's definitely the case.  See my earlier post on this topic:
>
>   http://www.gelato.unsw.edu.au/linux-ia64/0409/11012.html
>
> Unfortunately, nobody reported any results for larger machines and/or
> more interesting workloads, so the patch is in limbo at this time.
> Clearly, if the CPU that's clearing the page is likely to use that
> same page soon after, it'd be useful to use temporal stores.

Here are some numbers using lmbench of temporal writes vs. non temporal
writes on ia64 (8p machine but lmbench run only for one load). There seems
to be some benefit for fork/exec but overall this does not seem to be a
clear win. I suspect that the distinction between temporal vs. nontemporal
writes is be more beneficial on machines with smaller pagesizes since
the likelyhood that most cachelines of a page are used soon is increased
and therefore hot zeroing is more beneficial.


 L M B E N C H  3 . 0   S U M M A R Y
 
 (Alpha software, do not distribute)

Basic system parameters
---
Host OS Description  Mhz  tlb  cache  
mem   scal
 pages line   
par   load
  bytes
- - ---  - - 
-- 
margin Linux 2.6.12-rc1-bk3  ia64-linux-gnu 1300 128
   1
margin Linux 2.6.12-rc1-bk3  ia64-linux-gnu 1300 128
   1
margin Linux 2.6.12-rc1-bk3  ia64-linux-gnu 1300 128
   1
margin Linux 2.6.12-rc1-bk3  ia64-linux-gnu 1300 128
   1
margin Linux 2.6.12-rc1-bk3  ia64-linux-gnu 1300 128
   1
margin Linux 2.6.12-rc1-bk3  ia64-linux-gnu 1300 128
   1
margin Linux 2.6.12-rc1-bk3  ia64-linux-gnu 1300 128
   1
margin  Linux 2.6.12-rc1-bk3-dm  ia64-linux-gnu 1300 128
   1
margin  Linux 2.6.12-rc1-bk3-dm  ia64-linux-gnu 1300 128
   1
margin  Linux 2.6.12-rc1-bk3-dm  ia64-linux-gnu 1300 128
   1

Processor, Processes - times in microseconds - smaller is better
--
Host OS  Mhz null null  open slct sig  sig  
fork exec sh
 call  I/O stat clos TCP  inst hndl 
proc proc proc
- -         
  
margin Linux 2.6.12-rc1-bk3 1300 0.04 0.26 4.90 6.11 15.7 0.39 2.43 
528. 1926 4853
margin Linux 2.6.12-rc1-bk3 1300 0.04 0.27 4.86 6.10 15.7 0.39 2.45 
522. 1910 4260
margin Linux 2.6.12-rc1-bk3 1300 0.04 0.26 4.85 6.10 15.8 0.39 2.40 
526. 1916 4429
margin Linux 2.6.12-rc1-bk3 1300 0.04 0.26 4.84 6.11 15.7 0.39 2.40 
531. 1838 4429
margin Linux 2.6.12-rc1-bk3 1300 0.04 0.26 4.85 6.11 15.8 0.39 2.47 
553. 1931 5118
margin Linux 2.6.12-rc1-bk3 1300 0.04 0.26 5.09 6.37 15.7 0.39 2.40 
537. 1934 5133
margin Linux 2.6.12-rc1-bk3 1300 0.04 0.26 5.09 6.35 15.8 0.39 2.40 
555. 1939 5389
margin  Linux 2.6.12-rc1-bk3-dm 1300 0.04 0.26 4.88 6.10 15.8 0.39 2.42 
519. 1829 4787
margin  Linux 2.6.12-rc1-bk3-dm 1300 0.04 0.26 4.87 6.09 15.8 0.39 2.40 
516. 1830 5057
margin  Linux 2.6.12-rc1-bk3-dm 1300 0.04 0.27 4.86 6.10 15.8 0.39 2.40 
512. 1878 5166

Context switching - times in microseconds - smaller is better
-
Host OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 
16p/64K
 ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   
ctxsw
- - -- -- -- -- -- --- 
---
margin Linux 2.6.12-rc1-bk3 7.3300 2.7400 7.0400 4.4600 6.6200 3.94000 
8.38000
margin Linux 2.6.12-rc1-bk3 7.6100 8.1000 7.3200 4.5900 7.1700 5.5 
7.84000
margin Linux 2.6.12-rc1-bk3 7.2400 8. 7.2100 4.3800 6.7500 4.77000 
7.37000
margin Linux 2.6.12-rc1-bk3 7.4100 8.0400 7.0500 4.5100 7.2500 4.11000 
7.03000
margin Linux 2.6.12-rc1-bk3 7.2600 8.2100 7.2400 4.6500 6.6500 4.08000 
7.81000
margin Linux 2.6.12-rc1-bk3 7.4600 7.9000 7.3800 4.3800 6.6200 4.83000 
7.27000
margin Linux 2.6.12-rc1-bk3 7.4400 8.2000 7.2000 5.8700 6.8000 4.86000 
7.95000
margin  Linux 2.6.12-rc1-bk3-dm 7.4400 8.3100 7.1300 5.6900 6.6500 5.49000 
7.49000
margin  Linux 2.6.12-rc1-bk3-dm 2.1300 8.0100 7.3800 4.6700 6.5500 

Re: 2.6.12-rc2 compile error in drivers/usb/class/cdc-acm.c

[Adrian Bunk]

On Tue, Apr 05, 2005 at 10:54:09AM +0200, Ben Castricum wrote:
> 
> 2.6.12-rc1 compiles and runs perfectly.
> 
> gcc version 2.95.3 20010315 (release)
> 
>   CC [M]  drivers/usb/class/cdc-acm.o
> In file included from drivers/usb/class/cdc-acm.c:63:
> include/linux/usb_cdc.h:117: field `bDetailData' has incomplete type
> make[3]: *** [drivers/usb/class/cdc-acm.o] Error 1
> make[2]: *** [drivers/usb/class] Error 2
> make[1]: *** [drivers/usb] Error 2
> make: *** [drivers] Error 2


That's a known problem already fixed in -mm.


> I also get several warnings while compiling the kernel:
> 
> 
>   CC  fs/quota_v2.o
> fs/quota_v2.c: In function `v2_write_dquot':
> fs/quota_v2.c:399: warning: unknown conversion type character `z' in
> format
> fs/quota_v2.c:399: warning: too many arguments for format
> 
>   CC [M]  drivers/acpi/processor_idle.o
> drivers/acpi/processor_idle.c: In function
> `acpi_processor_power_seq_show':
> drivers/acpi/processor_idle.c:868: warning: unknown conversion type
> character `z' in format
> drivers/acpi/processor_idle.c:868: warning: too many arguments for format
> drivers/acpi/processor_idle.c:899: warning: unknown conversion type
> character `z' in format
> drivers/acpi/processor_idle.c:899: warning: too many arguments for format
> drivers/acpi/processor_idle.c:906: warning: unknown conversion type
> character `z' in format
> drivers/acpi/processor_idle.c:906: warning: too many arguments for format
>...


These are warnings that only occur with gcc 2.95 and that can safely be
ignored.


> Hope this helps,
> Ben


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Tue, Apr 05, 2005 at 08:56:09PM +0200, Josselin Mouette wrote:
> Le mardi 05 avril 2005 à 12:50 -0600, Chris Friesen a écrit :
> > Josselin Mouette wrote:
> > 
> > > The fact is also that mixing them with a GPLed software gives
> > > an result you can't redistribute - although it seems many people
> > > disagree with that assertion now.
> > 
> > This is only true if the result is considered a "derivative work" of the 
> > gpl'd code.
> > 
> > The GPL states "In addition, mere aggregation of another work not based 
> > on the Program with the Program (or with a work based on the Program) on 
> > a volume of a storage or distribution medium does not bring the other 
> > work under the scope of this License."
> > 
> > Since the main cpu does not actually run the binary firmware, the fact 
> > that it lives in main memory with the code that the cpu *does* run is 
> > irrelevent.  In this case, the Debian stance is that the kernel proper 
> > and the binary firmware are "merely aggregated" in a volume of storage ( 
> > ie. system memory).
> 
> It merely depends on the definition of "aggregation". I'd say that two
> works that are only aggregated can be easily distinguished and
> separated. This is not the case for a binary kernel module, from which
> you cannot easily extract the firmware and code parts.

Josselin, please read the thread i linked to in debian-legal, and as nobody
really gave reason to oppose it, i believe we have consensus that those
firmware blobs constitute mere agregation, provided they are clearly
identified and properly licenced, which they are not always.

Let's take this to debian-legal only if you want to further discuss it.

Friendly,

Sven Luther

-
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] new fifo I/O elevator that really does nothing at all

[Chen, Kenneth W]

Jens Axboe wrote on Tuesday, April 05, 2005 7:54 AM
> On Tue, Mar 29 2005, Chen, Kenneth W wrote:
> > Jens Axboe wrote on Tuesday, March 29, 2005 12:04 PM
> > > No such promise was ever made, noop just means it does 'basically
> > > nothing'. It never meant FIFO in anyway, we cannot break the semantics
> > > of block layer commands just for the hell of it.
> >
> > Acknowledged and understood, will try your patch shortly.
>
> Did you test it?

Experiment is in the queue, should have a result in a day or two.


-
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] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]

[Chen, Kenneth W]

Ingo Molnar wrote on Sunday, April 03, 2005 11:24 PM

> great! How long does the benchmark take (hours?), and is there any way
> to speed up the benchmarking (without hurting accuracy), so that
> multiple migration-cost settings could be tried? Would it be possible to
> try a few other values via the migration_factor boot option, in 0.5 msec
> steps or so, to find the current sweet spot? It used to be at 11 msec
> previously, correct?

It take days, each experiment is 5 hours.  Previous experiments on 2.6.8
shows that the sweet spot was 12.5ms.

This time on 2.6.11, it got pushed into 16 ms.  Results comparing to 10ms:

 8 ms  -0.3%
10 ms  --
12 ms   +0.11%
16 ms +0.14%
20 ms +0.06%

12ms and up all has about 1.5% idle time.  We are not anywhere near the
limits on what the disk storage can deliver.  So there is a potential to
to tune/optimize the scheduler and reap these extra idle time.

- Ken


-
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: [03/08] fix ia64 syscall auditing

[Greg KH]

On Tue, 2005-04-05 at 19:46 -0400, Ryan Anderson wrote:
> highlight WhitespaceEOL ctermbg=red guibg=red
> match WhitespaceEOL /\s\+$/

Very nice, thanks a lot for that.

greg k-h

-
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] drivers/scsi/sata_svw.c: fix compiler warnings

[Jeff Garzik]

Nick Wilson wrote:
Fixes compiler warnings:
  warning: passing arg 2 of `writeb' makes pointer from integer without a cast
  warning: passing arg 1 of `readw' makes pointer from integer without a cast
(added to CC list, just to update people on the status of these 
warnings...  I know they're annoying)

Thanks, but like I told someone else just yesterday, I'm not interested 
in patches which simply shift the warnings around.

You need something _far_ more substantial, like what I have attached, 
which updates libata to use the iomap infrastructure.

The warnings are there to let me (and others) know where the changes 
need to be made.  Applying a patch like yours will almost guarantee that 
I will miss a spot that needs to be converted.

Attachments:
patch.1:  97% of the iomap conversion.
patch.2:  add kernel infrastructure to map, and store, a bunch of PCI 
BARs.  For many IDE controllers, one must map 5-6 PCI BARs, but for 
others, everything is aggregated into a single MMIO PCI BAR.

The remaining task is to marry the two attached patches, and the work is 
complete.

Jeff



patch.1.bz2
Description: BZip2 compressed data


patch.2.bz2
Description: BZip2 compressed data

Re: [PATCH] Fix compat stat handling on sparc64

[Stephen Rothwell]

Hi Dave,

On Tue, 5 Apr 2005 13:57:37 -0700 "David S. Miller" <[EMAIL PROTECTED]> wrote:
>
> --- 1.19/include/asm-sparc64/compat.h 2005-02-17 21:53:03 -08:00
> +++ edited/include/asm-sparc64/compat.h   2005-04-05 12:37:58 -07:00
> @@ -51,11 +51,11 @@
>   compat_dev_tst_rdev;
>   compat_off_tst_size;
>   compat_time_t   st_atime;
> - u32 __unused1;
> + u32 st_atime_nsec;

Surely you meant to put compat_ulong_t instead of u32 ... :-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpldPR24lPfz.pgp
Description: PGP signature

[patch 5/5] sched: consolidate sbe sbf

[Nick Piggin]

5/5
Any ideas about what to do with schedstats?
Do we really need balance on exec and fork as seperate
statistics?
Consolidate balance-on-exec with balance-on-fork. This is made easy
by the sched-domains RCU patches.

As well as the general goodness of code reduction, this allows
the runqueues to be unlocked during balance-on-fork.

schedstats is a problem. Maybe just have balance-on-event instead
of distinguishing fork and exec?

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c   2005-04-05 18:39:14.0 +1000
+++ linux-2.6/kernel/sched.c2005-04-05 18:40:18.0 +1000
@@ -1013,8 +1013,57 @@ static int find_idlest_cpu(struct sched_
return idlest;
 }
 
+/*
+ * sched_balance_self: balance the current task (running on cpu) in domains
+ * that have the 'flag' flag set. In practice, this is SD_BALANCE_FORK and
+ * SD_BALANCE_EXEC.
+ *
+ * Balance, ie. select the least loaded group.
+ *
+ * Returns the target CPU number, or the same CPU if no balancing is needed.
+ *
+ * preempt must be disabled.
+ */
+static int sched_balance_self(int cpu, int flag)
+{
+   struct task_struct *t = current;
+   struct sched_domain *tmp, *sd = NULL;
 
-#endif
+   for_each_domain(cpu, tmp)
+   if (tmp->flags & flag)
+   sd = tmp;
+
+   while (sd) {
+   cpumask_t span;
+   struct sched_group *group;
+   int new_cpu;
+
+   span = sd->span;
+   group = find_idlest_group(sd, t, cpu);
+   if (!group)
+   goto nextlevel;
+
+   new_cpu = find_idlest_cpu(group, cpu);
+   if (new_cpu == -1 || new_cpu == cpu)
+   goto nextlevel;
+
+   /* Now try balancing at a lower domain level */
+   cpu = new_cpu;
+nextlevel:
+   sd = NULL;
+   for_each_domain(cpu, tmp) {
+   if (cpus_subset(span, tmp->span))
+   break;
+   if (tmp->flags & flag)
+   sd = tmp;
+   }
+   /* while loop will break here if sd == NULL */
+   }
+
+   return cpu;
+}
+
+#endif /* CONFIG_SMP */
 
 /*
  * wake_idle() will wake a task on an idle cpu if task->cpu is
@@ -1295,63 +1344,22 @@ void fastcall wake_up_new_task(task_t * 
int this_cpu, cpu;
runqueue_t *rq, *this_rq;
 #ifdef CONFIG_SMP
-   struct sched_domain *tmp, *sd = NULL;
-#endif
+   int new_cpu;
 
+   cpu = task_cpu(p);
+   preempt_disable();
+   new_cpu = sched_balance_self(cpu, SD_BALANCE_FORK);
+   preempt_enable();
+   if (new_cpu != cpu)
+   set_task_cpu(p, new_cpu);
+#endif
+   
+   cpu = task_cpu(p);
rq = task_rq_lock(p, );
-   BUG_ON(p->state != TASK_RUNNING);
this_cpu = smp_processor_id();
-   cpu = task_cpu(p);
-
-#ifdef CONFIG_SMP
-   for_each_domain(cpu, tmp)
-   if (tmp->flags & SD_BALANCE_FORK)
-   sd = tmp;
-
-   if (sd) {
-   cpumask_t span;
-   int new_cpu;
-   struct sched_group *group;
-
-again:
-   schedstat_inc(sd, sbf_cnt);
-   span = sd->span;
-   cpu = task_cpu(p);
-   group = find_idlest_group(sd, p, cpu);
-   if (!group) {
-   schedstat_inc(sd, sbf_balanced);
-   goto nextlevel;
-   }
 
-   new_cpu = find_idlest_cpu(group, cpu);
-   if (new_cpu == -1 || new_cpu == cpu) {
-   schedstat_inc(sd, sbf_balanced);
-   goto nextlevel;
-   }
-
-   if (cpu_isset(new_cpu, p->cpus_allowed)) {
-   schedstat_inc(sd, sbf_pushed);
-   set_task_cpu(p, new_cpu);
-   task_rq_unlock(rq, );
-   rq = task_rq_lock(p, );
-   cpu = task_cpu(p);
-   }
-
-   /* Now try balancing at a lower domain level */
-nextlevel:
-   sd = NULL;
-   for_each_domain(cpu, tmp) {
-   if (cpus_subset(span, tmp->span))
-   break;
-   if (tmp->flags & SD_BALANCE_FORK)
-   sd = tmp;
-   }
-
-   if (sd)
-   goto again;
-   }
+   BUG_ON(p->state != TASK_RUNNING);
 
-#endif
/*
 * We decrease the sleep average of forking parents
 * and children as well, to keep max-interactive tasks
@@ -1699,59 +1707,17 @@ out:
task_rq_unlock(rq, );
 }
 
-/*
- * sched_exec(): find the highest-level, exec-balance-capable
- * domain and try to migrate the task to the least 

Re: [03/08] fix ia64 syscall auditing

[Ryan Anderson]

On Tue, Apr 05, 2005 at 01:49:18PM -0700, Greg KH wrote:
> On Tue, 2005-04-05 at 13:27 -0700, David Mosberger wrote:
> > > On Tue, 5 Apr 2005 09:46:48 -0700, Greg KH <[EMAIL PROTECTED]> said:
> > 
> >   Greg> -stable review patch.  If anyone has any objections, please
> >   Greg> let us know.
> > 
> > Nitpick: the patch introduces trailing whitespace.
> 
> Sorry about that, I've removed it from the patch now.
> 
> > Why doesn't everybody use emacs and enable show-trailing-whitespace? ;-)
> 
> Because some of us use vim and ":set list" to see it, when we remember
> to... :)

Try adding this to your .vimrc:

highlight WhitespaceEOL ctermbg=red guibg=red
match WhitespaceEOL /\s\+$/

Then you'll have to resist the urge to fix whitespace issues instead of
not seeing them at all.

-- 

Ryan Anderson
  sometimes Pug Majere
-
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/

[patch 4/5] sched: RCU sched domains

[Nick Piggin]

4/5
One of the problems with the multilevel balance-on-fork/exec is that it
needs to jump through hoops to satisfy sched-domain's locking semantics
(that is, you may traverse your own domain when not preemptable, and
you may traverse others' domains when holding their runqueue lock).

balance-on-exec had to potentially migrate between more than one CPU before
finding a final CPU to migrate to, and balance-on-fork needed to potentially
take multiple runqueue locks.

So bite the bullet and make sched-domains go completely RCU. This actually
simplifies the code quite a bit.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c   2005-04-05 16:39:14.0 +1000
+++ linux-2.6/kernel/sched.c2005-04-05 18:39:05.0 +1000
@@ -825,22 +825,12 @@ inline int task_curr(const task_t *p)
 }
 
 #ifdef CONFIG_SMP
-enum request_type {
-   REQ_MOVE_TASK,
-   REQ_SET_DOMAIN,
-};
-
 typedef struct {
struct list_head list;
-   enum request_type type;
 
-   /* For REQ_MOVE_TASK */
task_t *task;
int dest_cpu;
 
-   /* For REQ_SET_DOMAIN */
-   struct sched_domain *sd;
-
struct completion done;
 } migration_req_t;
 
@@ -862,7 +852,6 @@ static int migrate_task(task_t *p, int d
}
 
init_completion(>done);
-   req->type = REQ_MOVE_TASK;
req->task = p;
req->dest_cpu = dest_cpu;
list_add(>list, >migration_queue);
@@ -4365,17 +4354,9 @@ static int migration_thread(void * data)
req = list_entry(head->next, migration_req_t, list);
list_del_init(head->next);
 
-   if (req->type == REQ_MOVE_TASK) {
-   spin_unlock(>lock);
-   __migrate_task(req->task, cpu, req->dest_cpu);
-   local_irq_enable();
-   } else if (req->type == REQ_SET_DOMAIN) {
-   rq->sd = req->sd;
-   spin_unlock_irq(>lock);
-   } else {
-   spin_unlock_irq(>lock);
-   WARN_ON(1);
-   }
+   spin_unlock(>lock);
+   __migrate_task(req->task, cpu, req->dest_cpu);
+   local_irq_enable();
 
complete(>done);
}
@@ -4606,7 +4587,6 @@ static int migration_call(struct notifie
migration_req_t *req;
req = list_entry(rq->migration_queue.next,
 migration_req_t, list);
-   BUG_ON(req->type != REQ_MOVE_TASK);
list_del_init(>list);
complete(>done);
}
@@ -4903,10 +4883,7 @@ static int __devinit sd_parent_degenerat
  */
 void __devinit cpu_attach_domain(struct sched_domain *sd, int cpu)
 {
-   migration_req_t req;
-   unsigned long flags;
runqueue_t *rq = cpu_rq(cpu);
-   int local = 1;
struct sched_domain *tmp;
 
/* Remove the sched domains which do not contribute to scheduling. */
@@ -4923,24 +4900,7 @@ void __devinit cpu_attach_domain(struct 
 
sched_domain_debug(sd, cpu);
 
-   spin_lock_irqsave(>lock, flags);
-
-   if (cpu == smp_processor_id() || !cpu_online(cpu)) {
-   rq->sd = sd;
-   } else {
-   init_completion();
-   req.type = REQ_SET_DOMAIN;
-   req.sd = sd;
-   list_add(, >migration_queue);
-   local = 0;
-   }
-
-   spin_unlock_irqrestore(>lock, flags);
-
-   if (!local) {
-   wake_up_process(rq->migration_thread);
-   wait_for_completion();
-   }
+   rq->sd = sd;
 }
 
 /* cpus with isolated domains */
@@ -5215,6 +5175,7 @@ static int update_sched_domains(struct n
case CPU_DOWN_PREPARE:
for_each_online_cpu(i)
cpu_attach_domain(NULL, i);
+   synchronize_kernel();
arch_destroy_sched_domains();
return NOTIFY_OK;
 

[patch 3/5] sched: multilevel sbe and sbf

[Nick Piggin]

3/5
The fundamental problem that Suresh has with balance on exec and fork
is that it only tries to balance the top level domain with the flag
set.

This was worked around by removing degenerate domains, but is still a
problem if people want to start using more complex sched-domains, especially
multilevel NUMA that ia64 is already using.

This patch makes balance on fork and exec try balancing over not just the
top most domain with the flag set, but all the way down the domain tree.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c   2005-04-05 16:38:53.0 +1000
+++ linux-2.6/kernel/sched.c2005-04-05 18:39:07.0 +1000
@@ -1320,21 +1320,24 @@ void fastcall wake_up_new_task(task_t * 
sd = tmp;
 
if (sd) {
+   cpumask_t span;
int new_cpu;
struct sched_group *group;
 
+again:
schedstat_inc(sd, sbf_cnt);
+   span = sd->span;
cpu = task_cpu(p);
group = find_idlest_group(sd, p, cpu);
if (!group) {
schedstat_inc(sd, sbf_balanced);
-   goto no_forkbalance;
+   goto nextlevel;
}
 
new_cpu = find_idlest_cpu(group, cpu);
if (new_cpu == -1 || new_cpu == cpu) {
schedstat_inc(sd, sbf_balanced);
-   goto no_forkbalance;
+   goto nextlevel;
}
 
if (cpu_isset(new_cpu, p->cpus_allowed)) {
@@ -1344,9 +1347,21 @@ void fastcall wake_up_new_task(task_t * 
rq = task_rq_lock(p, );
cpu = task_cpu(p);
}
+
+   /* Now try balancing at a lower domain level */
+nextlevel:
+   sd = NULL;
+   for_each_domain(cpu, tmp) {
+   if (cpus_subset(span, tmp->span))
+   break;
+   if (tmp->flags & SD_BALANCE_FORK)
+   sd = tmp;
+   }
+
+   if (sd)
+   goto again;
}
 
-no_forkbalance:
 #endif
/*
 * We decrease the sleep average of forking parents
@@ -1712,25 +1727,41 @@ void sched_exec(void)
sd = tmp;
 
if (sd) {
+   cpumask_t span;
struct sched_group *group;
+again:
schedstat_inc(sd, sbe_cnt);
+   span = sd->span;
group = find_idlest_group(sd, current, this_cpu);
if (!group) {
schedstat_inc(sd, sbe_balanced);
-   goto out;
+   goto nextlevel;
}
new_cpu = find_idlest_cpu(group, this_cpu);
if (new_cpu == -1 || new_cpu == this_cpu) {
schedstat_inc(sd, sbe_balanced);
-   goto out;
+   goto nextlevel;
}
 
schedstat_inc(sd, sbe_pushed);
put_cpu();
sched_migrate_task(current, new_cpu);
-   return;
+   
+   /* Now try balancing at a lower domain level */
+   this_cpu = get_cpu();
+nextlevel:
+   sd = NULL;
+   for_each_domain(this_cpu, tmp) {
+   if (cpus_subset(span, tmp->span))
+   break;
+   if (tmp->flags & SD_BALANCE_EXEC)
+   sd = tmp;
+   }
+
+   if (sd)
+   goto again;
}
-out:
+
put_cpu();
 }
 

[patch 2/5] sched: NULL domains

[Nick Piggin]

2/5
The previous patch fixed the last 2 places that directly access a
runqueue's sched-domain and assume it cannot be NULL.

We can now use a NULL domain instead of a dummy domain to signify
no balancing is to happen. No functional changes.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c   2005-04-05 16:38:40.0 +1000
+++ linux-2.6/kernel/sched.c2005-04-05 18:39:08.0 +1000
@@ -4887,7 +4887,7 @@ void __devinit cpu_attach_domain(struct 
tmp->parent = parent->parent;
}
 
-   if (sd_degenerate(sd))
+   if (sd && sd_degenerate(sd))
sd = sd->parent;
 
sched_domain_debug(sd, cpu);
@@ -5054,7 +5054,7 @@ static void __devinit arch_init_sched_do
cpus_and(cpu_default_map, cpu_default_map, cpu_online_map);
 
/*
-* Set up domains. Isolated domains just stay on the dummy domain.
+* Set up domains. Isolated domains just stay on the NULL domain.
 */
for_each_cpu_mask(i, cpu_default_map) {
int group;
@@ -5167,18 +5167,11 @@ static void __devinit arch_destroy_sched
 
 #endif /* ARCH_HAS_SCHED_DOMAIN */
 
-/*
- * Initial dummy domain for early boot and for hotplug cpu. Being static,
- * it is initialized to zero, so all balancing flags are cleared which is
- * what we want.
- */
-static struct sched_domain sched_domain_dummy;
-
 #ifdef CONFIG_HOTPLUG_CPU
 /*
  * Force a reinitialization of the sched domains hierarchy.  The domains
  * and groups cannot be updated in place without racing with the balancing
- * code, so we temporarily attach all running cpus to a "dummy" domain
+ * code, so we temporarily attach all running cpus to the NULL domain
  * which will prevent rebalancing while the sched domains are recalculated.
  */
 static int update_sched_domains(struct notifier_block *nfb,
@@ -5190,7 +5183,7 @@ static int update_sched_domains(struct n
case CPU_UP_PREPARE:
case CPU_DOWN_PREPARE:
for_each_online_cpu(i)
-   cpu_attach_domain(_domain_dummy, i);
+   cpu_attach_domain(NULL, i);
arch_destroy_sched_domains();
return NOTIFY_OK;
 
@@ -5253,7 +5246,7 @@ void __init sched_init(void)
rq->best_expired_prio = MAX_PRIO;
 
 #ifdef CONFIG_SMP
-   rq->sd = _domain_dummy;
+   rq->sd = NULL;
for (j = 1; j < 3; j++)
rq->cpu_load[j] = 0;
rq->active_balance = 0;

[patch 1/5] sched: remove degenerate domains

[Nick Piggin]

This is Suresh's patch with some modifications.
--
SUSE Labs, Novell Inc.
Remove degenerate scheduler domains during the sched-domain init.

For example on x86_64, we always have NUMA configured in. On Intel EM64T
systems, top most sched domain will be of NUMA and with only one sched_group in
it. 

With fork/exec balances(recent Nick's fixes in -mm tree), we always endup 
taking wrong decisions because of this topmost domain (as it contains only 
one group and find_idlest_group always returns NULL). We will endup loading 
HT package completely first, letting active load balance kickin and correct it.

In general, this patch also makes sense with out recent Nick's fixes
in -mm.

Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>

Modified to account for more than just sched_groups when scanning for
degenerate domains by Nick Piggin. Allow a runqueue's sd to go NULL, which
required small changes to the smtnice code.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>


Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c   2005-04-05 16:38:21.0 +1000
+++ linux-2.6/kernel/sched.c2005-04-05 18:39:09.0 +1000
@@ -2583,11 +2583,15 @@ out:
 #ifdef CONFIG_SCHED_SMT
 static inline void wake_sleeping_dependent(int this_cpu, runqueue_t *this_rq)
 {
-   struct sched_domain *sd = this_rq->sd;
+   struct sched_domain *tmp, *sd = NULL;
cpumask_t sibling_map;
int i;
+   
+   for_each_domain(this_cpu, tmp)
+   if (tmp->flags & SD_SHARE_CPUPOWER)
+   sd = tmp;
 
-   if (!(sd->flags & SD_SHARE_CPUPOWER))
+   if (!sd)
return;
 
/*
@@ -2628,13 +2632,17 @@ static inline void wake_sleeping_depende
 
 static inline int dependent_sleeper(int this_cpu, runqueue_t *this_rq)
 {
-   struct sched_domain *sd = this_rq->sd;
+   struct sched_domain *tmp, *sd = NULL;
cpumask_t sibling_map;
prio_array_t *array;
int ret = 0, i;
task_t *p;
 
-   if (!(sd->flags & SD_SHARE_CPUPOWER))
+   for_each_domain(this_cpu, tmp)
+   if (tmp->flags & SD_SHARE_CPUPOWER)
+   sd = tmp;
+
+   if (!sd)
return 0;
 
/*
@@ -4604,6 +4612,11 @@ static void sched_domain_debug(struct sc
 {
int level = 0;
 
+   if (!sd) {
+   printk(KERN_DEBUG "CPU%d attaching NULL sched-domain.\n", cpu);
+   return;
+   }
+   
printk(KERN_DEBUG "CPU%d attaching sched-domain:\n", cpu);
 
do {
@@ -4809,6 +4822,50 @@ static void init_sched_domain_sysctl(voi
 }
 #endif
 
+static int __devinit sd_degenerate(struct sched_domain *sd)
+{
+   if (cpus_weight(sd->span) == 1)
+   return 1;
+
+   /* Following flags need at least 2 groups */
+   if (sd->flags & (SD_LOAD_BALANCE |
+SD_BALANCE_NEWIDLE |
+SD_BALANCE_FORK |
+SD_BALANCE_EXEC)) {
+   if (sd->groups != sd->groups->next)
+   return 0;
+   }
+
+   /* Following flags don't use groups */
+   if (sd->flags & (SD_WAKE_IDLE |
+SD_WAKE_AFFINE |
+SD_WAKE_BALANCE))
+   return 0;
+
+   return 1;
+}
+
+static int __devinit sd_parent_degenerate(struct sched_domain *sd,
+   struct sched_domain *parent)
+{
+   unsigned long cflags = sd->flags, pflags = parent->flags;
+
+   if (sd_degenerate(parent))
+   return 1;
+
+   if (!cpus_equal(sd->span, parent->span))
+   return 0;
+
+   /* Does parent contain flags not in child? */
+   /* WAKE_BALANCE is a subset of WAKE_AFFINE */
+   if (cflags & SD_WAKE_AFFINE)
+   pflags &= ~SD_WAKE_BALANCE;
+   if ((~sd->flags) & parent->flags)
+   return 0;
+
+   return 1;
+}
+
 /*
  * Attach the domain 'sd' to 'cpu' as its base domain.  Callers must
  * hold the hotplug lock.
@@ -4819,6 +4876,19 @@ void __devinit cpu_attach_domain(struct 
unsigned long flags;
runqueue_t *rq = cpu_rq(cpu);
int local = 1;
+   struct sched_domain *tmp;
+
+   /* Remove the sched domains which do not contribute to scheduling. */
+   for (tmp = sd; tmp; tmp = tmp->parent) {
+   struct sched_domain *parent = tmp->parent;
+   if (!parent)
+   break;
+   if (sd_parent_degenerate(tmp, parent))
+   tmp->parent = parent->parent;
+   }
+
+   if (sd_degenerate(sd))
+   sd = sd->parent;
 
sched_domain_debug(sd, cpu);
 

Re: 2.6.12-rc2-mm1

[Nick Piggin]

Siddha, Suresh B wrote:
On Tue, Apr 05, 2005 at 05:33:49PM +1000, Nick Piggin wrote:

Suresh's underlying problem with the unnecessary sched domains
is a failing of sched-balance-exec and sched-balance-fork, which

That wasn't the only motivation. For example, on non-HT cpu's we shouldn't
be setting up SMT sched-domain, same with NUMA domains on non-NUMA systems.
Yep, sure. It is a good, if slight, optimisation. And I've also just
slightly extended your patch, so we don't have any domains if booting
with maxcpus=1

I am working on now.
Removing unnecessary domains is a nice optimisation, but just
needs to account for a few more flags before declaring that a

Can you elaborate when we require a domain with special flags but has
no or only one group in it.
The SD_WAKE_* flags do not use groups, so it would be legitimate to
have a domain that has one of these set, with no groups.

domain is unnecessary (not to mention this probably breaks if
isolcpus= is used). I have made some modifications to the patch

I have tested my patch with "ioslcpus=" and it works just fine.
OK, my apologies ;)

to fix these problems.
Lastly, I'd like to be a bit less intrusive with pinned task
handling improvements. I think we can do this while still being
effective in preventing livelocks.

We want to see this fixed. Please post your patch and I can let you know
the test results.
I will try to get it working and tested tonight for you.

I will keep you posted with regards to the various scheduler
patches.

Nick, Can you post the patches you sent me earlier to this list?
Yep, I'll post them.
--
SUSE Labs, Novell Inc.
-
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] radeonfb: (#2) Implement proper workarounds for PLL accesses

[Benjamin Herrenschmidt]

On Tue, 2005-04-05 at 23:44 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> 
> > After discussion with ATIs, it seems that the workarounds they initially
> > gave me were not completely correct.
> >
> > This patch implements the proper ones, which includes sleeping in PLL
> > accesses, and thus requires the previous patch to make sure we do not
> > call unblank at interrupt time (unless oops_in_progress is set, in which
> > case I use an mdelay).
> >
> > It also removes obsolete code that used to disable some power management
> > features in the accel init code.
> 
> This patch does no good on Radeon M6 (iBook G3).  It makes mode switching
> to take an extraordinary amount of time, ie. when switching away from X it
> takes about 2-3 seconds until the console is restored.

Hrm... it should only add a few ms, maybe about 20 ms to the mode
switching... If you remove the radeon_msleep(5) call from the
radeon_pll_errata_after_data() routine in radeonfb.h, does it make a
difference ?

Ben.


-
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/

[PATCH][RFC] disable built-in modules V2

[Magnus Damm]

Here comes version 2 of the disable built-in patch.

This patch makes it possible to disable built-in code from the kernel
command line. The patch is rather simple - it extends the compiled-in case 
of module_init() to include __setup() with a name based on KBUILD_MODNAME.

As an example, if you want to disable built-in firewire support then you
could pass "force_ohci1394=off" on the kernel command line. The feature added
by this patch comes handy when you want to boot a precompiled kernel from a 
live cd on som exotic hardware that makes built-in drivers crash.

Changes since last release:
- Upgraded and tested with 2.6.12-rc2
- Added "force_"-prefix to cope with namespace pollution

Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>

diff -urNp linux-2.6.12-rc2/include/linux/init.h 
linux-2.6.12-rc2-disable_builtin/include/linux/init.h
--- linux-2.6.12-rc2/include/linux/init.h   2005-04-05 16:57:29.0 
+0200
+++ linux-2.6.12-rc2-disable_builtin/include/linux/init.h   2005-04-06 
00:26:07.0 +0200
@@ -143,6 +143,16 @@ struct obs_kernel_param {
 
 /* Relies on saved_command_line being set */
 void __init parse_early_param(void);
+
+void __init disable_initcall(void *fn);
+#define __module_init_disable(x)   \
+static int __init x##_disable_module(char *str)\
+{  \
+   disable_initcall(x);\
+   return 1;   \
+}  \
+__setup("force_" __stringify(KBUILD_MODNAME) "=off", x##_disable_module)
+
 #endif /* __ASSEMBLY__ */
 
 /**
@@ -153,7 +163,7 @@ void __init parse_early_param(void);
  * builtin) or at module insertion time (if a module).  There can only
  * be one per module.
  */
-#define module_init(x) __initcall(x);
+#define module_init(x) __initcall(x); __module_init_disable(x);  
 
 /**
  * module_exit() - driver exit entry point
diff -urNp linux-2.6.12-rc2/init/main.c 
linux-2.6.12-rc2-disable_builtin/init/main.c
--- linux-2.6.12-rc2/init/main.c2005-04-05 16:59:55.0 +0200
+++ linux-2.6.12-rc2-disable_builtin/init/main.c2005-04-05 
21:07:05.0 +0200
@@ -539,6 +539,17 @@ struct task_struct *child_reaper = 
 
 extern initcall_t __initcall_start[], __initcall_end[];
 
+void __init disable_initcall(void *fn)
+{
+   initcall_t *call;
+
+   for (call = __initcall_start; call < __initcall_end; call++) {
+
+   if (*call == fn)
+   *call = NULL;
+   }
+}
+
 static void __init do_initcalls(void)
 {
initcall_t *call;
@@ -553,7 +564,8 @@ static void __init do_initcalls(void)
printk("\n");
}
 
-   (*call)();
+   if (*call)
+   (*call)();
 
msg = NULL;
if (preempt_count() != 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: AOE and large filesystems?

[Jeff Garzik]

Dan Stromberg wrote:
Some questions for the list:
1) Is anyone on the list using AOE in production?
2) Is anyone on the list using AOE in combination with md and/or LVM2?
3) Is anyone on the list using AOE on a 64 bit platform?
While I think AoE is "neat", IMO you really want to use something based 
on TCP, even on a LAN...

Your CPU usage w/ zerocopy offload could potentially be lowered w/ TCP, 
in addition to the built-in reliability.

As a tangent, I'd also like to see iSCSI over SCTP.
Jeff

-
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's the nforce4 support in Linux?

[Julien Wajsberg]

On Apr 5, 2005 4:10 PM, Richard B. Johnson <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Apr 2005, Julien Wajsberg wrote:
> 
> > On Mar 26, 2005 12:59 AM, Julien Wajsberg <[EMAIL PROTECTED]> wrote:
> >> I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
> >> experiment the following problem :
> >>
> >> Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
> >> Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
> >> Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
> >> Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
> >> DriveReady SeekComplete DataRequest }
> >> Mar 25 22:42:55 evenflow kernel:
> >> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> >> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> >> Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
> >> Mar 25 22:42:55 evenflow kernel:
> >> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> >> Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
>   ^
> >> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> >>
> >> Of course, if I disable DMA with hdparm, this problem disappear.. but
> >> it isn't a long-term solution ;-)
> >>
> 
> The long-term solution is to replace either the drive, cable, or the
> motherboard that can't do DMA.
It's a recent drive that did ultra DMA on another motherboard, and a
recent motherboard with a cable that did ultra DMA before.It was ultra
DMA2 on this old motherboard, but it still was ultra DMA.

> A bad DMA operation can write data
> anywhere (right into the middle of the kernel). There isn't
> anything software can do about it. Software sets up the
> controller for a DMA operation, then waits for an interrupt
> that tells it has completed or failed. Software can retry failed
> operations until software gets destroyed by the hardware, but
> there isn't anything else that can be done.
> 
> The fact that disabling DMA makes the problem(s) go away is
> proof that it isn't a software problem. There are flash-RAM
> devices that emulate IDE drives. Most of these can't do DMA
> and the IDE driver doesn't accept that fact. That is a known
> bug. One needs to use hdparm to tell it to stop trying to
> use DMA. In your case, the driver stopped using DMA when
> it found out that it didn't work. There is no bug.

In my case, the driver stopped for hdb, that is my dvd-burner/player.
It did nothing for hda or hdc, I had to disable DMA myself.


Will I have to install Windows XP to prove ultra DMA works correctly
on this setup ? I really don't hope...

-- 
Julien
-
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: Linux 2.4.30-rc3 md/ext3 problems (ext3 gurus : please check)

[Stephen C. Tweedie]

Hi,

On Wed, 2005-03-30 at 12:59, Marcelo Tosatti wrote:

> > I'm not certain that this is right, but it seems possible and would
> > explain the symptoms.  Maybe Stephen or Andrew could comments?
> 
> Andrew, Stephen?

Sorry, was offline for a week last week; I'll try to look at this more
closely tomorrow.  Checking the buffer_uptodate() without either a
refcount or a lock certainly looks unsafe at first glance.

There are lots of ways to pin the bh in that particular bit of the
code.  The important thing will be to do so without causing leaks if
we're truly finished with the buffer after this flush.


> > If some of the write succeeded and some failed, then I believe the
> > correct behaviour is to return the number of bytes that succeeded.
> > However this change to the return status (remember the above patch is
> > a reversal) causes any failure to over-ride any success. This, I
> > think, is wrong.
> 
> Yeap, that part also looks wrong.

Certainly it's normal for a short read/write to imply either error or
EOF, without the error necessarily needing to be returned explicitly. 
I'm not convinced that the Singleunix language actually requires that,
but it seems the most obvious and consistent behaviour.

--Stephen

-
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: Logitech MX1000 Horizontal Scrolling

[Jeremy Nickurak]

On mar, 2005-04-05 at 16:56 +0200, Esben Stien wrote:
> Esben Stien <[EMAIL PROTECTED]> writes:
> 
> > can't find a single problem with the device.
> 
> I should mention a couple of things after some testing: There are some
> inconsistencies with regard to cruise control.
> 
> When I press TOP CLICK BACKWARD/TOP CLICK FORWARD to cruise control
> down/up, it waits about 100ms before it starts cruising. This means
> that pressing a single click does not move me anywhere. I have to hold
> the key down and wait until it starts cruising.

This is probabbly because you're using the referenced xbindkeys trick to
delete the button11/12 event. Unfortunately, binding 11/12 while cruise
control is enabled also obscures the first scroll event.

The horrible-ugly-very-nasty-workaround is to bind that event to a
command that re-simulates the up/down click. I've attached a piece of C
code that'll do that. ('./click 4' will simulate button 4 going up and
down.)


> > 
> > # "cruise control" disabled:
> > "~/click/click 4"
> >   m:0x10 + b:11
> > "~/click/click 5"
> >   m:0x10 + b:12

I'm sort of guessing at the xbindkeys setting for this. Myself, i've
performed this bind event in my openbox configuration.

This still doesn't catch the button 11/12 mouse-up event, although that
doesn't seem to bother many applications



click.tgz
Description: application/compressed-tar


signature.asc
Description: This is a digitally signed message part

Re: [ACPI] Re: It's getting worse: 2.6.12-rc2-mm1 and suspend2ram

[Norbert Preining]

On Die, 05 Apr 2005, Pavel Machek wrote:
> Well, I do not have working suspend-to-RAM setup close to me... Could
> you try 2.6.12-rc1 to see if reboot problem is -mm specific or not?

2.6.12-rc2 suspends and resumes with the very same config file (well,
after running make oldconfig) without any problem.

So there is a change in -mm1 which triggers this. Should I start with
backing out bk-acpi? or anything else?

> input is known for some funky behaviour, especially with
> synaptics. Disabling cpufreq might be good idea, too...

rc2 with input compiled in and cpufreq compiled in did resume.

Best wishes

Norbert

---
Dr. Norbert Preining  Università di Siena
sip:[EMAIL PROTECTED] +43 (0) 59966-690018
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
THRUMSTRER (n.)
The irritating man next to you in a concert who thinks he's (a) the
conductor, (b) the brass section.
--- Douglas Adams, The Meaning of Liff
-
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: Use of C99 int types

[Kyle Moffett]

Please don't remove Linux-Kernel from the CC, I think this is an
important discussion.
On Apr 05, 2005, at 15:17, Renate Meijer wrote:
Strictly speaking, a definition starting with a double
underscore is reserved for use by the compiler and associated
libs
Well, _strictly_speaking_, it's "implementation defined", where the
"implementation" includes the kernel (due to the syscall interface).
Beg to differ. As far as i'm aware, the syscall interface is not part
of C. Hence the kernel,  in compiler terms, is not part of "the
implementation" of the compiler.
POSIX and such include information about signal handling and the
user-mode environment for C programs, both of which are completely
irrelevant from the compiler's point of view, including libc stuff.
But the C library is implicitly dependent on the kernel headers for
a wide variety of datatypes.
Correct. It is, however, not only dependent on the definitions as
provided by linux, but also of those provided by just about any other
OS the compiler is running on. Which, by the last count, was a pretty
impressive number.
I don't see how this applies.  We're only talking about the Linux
kernel here, right?
Well, Linus has supported that there is no standard, except where
ABI is concerned, there we must use __u32 so that it does not clash
with libc or user programs.
The fact that there is no standard is not an argument against at
least reaching some compromise. Surely 5 different names for a
simple, generic 32-bit integer is a bit much.
Personally, I don't care what you feel like requiring for purely
in-kernel interfaces, but __{s,u}{8,16,32,64} must stay to avoid
namespace collisions with glibc in the kernel include files as used
by userspace.
Especially the types with leading underscores look cool, but in
reality may cause a conflict with compiler internals and should only
be used when defining compiler libraries.
It's "implementation" (kernel+libc+gcc) defined.
I don't think the kernel has any place in that list.

   3.10
   [#1] implementation
   a  particular  set  of  software,  running  in  a particular
   translation environment under  particular  control  options,
   that  performs  translation  of  programs  for, and supports
   execution  of   functions   in,   a   particular   execution
   environment

This is kinda arguing semantics, but:
A particular set of software (linux+libc+gcc), running in a particular
translation environment (userspace) under particular control options
(Signals, nice values, etc), that performs translation of programs for
(emulating missing instructions), and supports execution of functions
(syscalls) in, a particular execution environment (also userspace).
Without the kernel userspace wouldn't have anything, because anything
syscall-related (which is basically everything) involves the kernel.
Heck, the kernel and its ABI is _more_ a part of the implementation
than glibc is!  I can write an assembly program that doesn't link to
or use libc, but without using syscalls I can do nothing whatsoever.
That's not to say that I _like_ the way things are set up, but it's not
practical to change them at the moment.

It would be nice if GCC provided a set of __gcc_foo inline definitions
for all sorts of useful functions and types, including various types of
memory barriers, sized types, etc and other platform-related garbage
that it would be good to have in the same place.  Then the kernel and
glibc could both just assume that they are there and not worry nearly
as much about what platform you're on.

But that goes only for those definitions that will eventually wind up
in /usr/include/*, not any code internal to (say) a driver and only
affects a minimal set of interfaces. That is, in comparison to
[EMAIL PROTECTED]:~/linux-2.6.11.6$ find . -name \*.h -exec grep __uint32 
{} \; -print

or worse
[EMAIL PROTECTED]:~/linux-2.6.11.6$ find . -name \*.c -exec grep __uint32 
{} \; -print\

On the bright side, most of it is in linux/fs/xfs so it's pretty
localized, on the other side, none of it is related to the ABI in
any way.
Uhh, how about:
grep -rl __u32 . | egrep '[^:]+\.h:'
or:
grep -rl __u32 . | egrep '[^:]+\.c:'
Both of those return a _LOT_ of stuff.
Nope. The syscall interface is employed by the library, no more,
no less. The C standard does not include *any* platform specific
stuff.
Which is why it reserves __ for use by the implementation so it can
play wherever it wants.
Quite on purpose, by the way. Not all the world is a linux machine
and an AVR doesn't even have syscalls.
But when I write my framebuffer library, I do:
#include 
#include 
And I expect it to work!  I want it to get the correct types, I
don't want it to clash with or require the libc types (My old
sources might redefine some stdint.h names, and I don't want it
to clash with my user-defined types.
Anything you like. 'kernel_' or simply 'k_' would be appropriate.
As long as you do not invade compiler namespace. It is 

Re: [patch] inotify for 2.6.11

[Robert Love]

On Tue, 2005-04-05 at 19:20 +0200, Prakash Punnoor wrote:

> BTW, what else could I use to make use of inotify? I know fam, which afaik
> only uses dnotify.

Here is a little sample glib application that shows the ease-yet-power
of inotify.

http://www.kernel.org/pub/linux/kernel/people/rml/inotify/glib/

It integrates inotify watches into the glib mainloop via GIOChannel.
Everything is abstracted behind simple interfaces, so this might prove a
nice start for curious inotify developers.

Robert Love


-
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.12-rc2-mm1

[Barry K. Nathan]

On Tue, Apr 05, 2005 at 07:14:45AM -0700, Barry K. Nathan wrote:
> 2.6.11-bk9 works (actually it takes under 2 seconds, not 5-10).
> 2.6.11-bk10 has the weird slowdown.
> 
> I'll see if I can isolate it any further.

2.6.11-mm2 works, but 2.6.11-mm3 has the ridiculously slow resumes.

Later today I'll see if I can narrow things down any further (e.g. to a
specific patch in 2.6.11-mm3 or whatever).

-Barry K. Nathan <[EMAIL PROTECTED]>

-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Brian Gerst]

Jeff Garzik wrote:
Josselin Mouette wrote:
Finally, you shouldn't forget that, technically speaking, using hotplug
for uploading the firmware is much more flexible and elegant than
including it in the kernel. Upgrading the firmware and the module should
be two independent operations. People who are advocating the current
situation are refusing technical improvements just because they are
brought by people they find convenient to call "zealots".

This is highly amusing, coming from someone who does not maintain a 
driver with a firmware.

The current firmware infrastructure is too primitive.  Compiling the 
firmware into the driver is much easier on the driver maintainers and 
users, presently.

Repeating myself,
* Most firmwares are a -collection- of images and data.  The firmware 
infrastructure should load an -archive- of firmwares and associated data 
values.
The firmware interface should only be concerned with getting the blob of 
data into kernel space.  Once it is in kernel space the driver can parse 
out whatever archive format it is in.  Take for example the ihex code 
that was posted recently.  Similar code could be written to parse out a 
tarball, cpio archive, etc.

--
Brian Gerst
-
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.12-rc2-mm1

[Sam Ravnborg]

On Tue, Apr 05, 2005 at 05:45:58PM +0200, Jan Dittmer wrote:
> Something has broken make O= :
> 
>   HOSTCC  scripts/kallsyms
>   HOSTCC  scripts/conmakehash
> make[1]: *** No rule to make target `include/asm', needed by 
> `arch/alpha/kernel/asm-offsets.s'.  Stop.
> make: *** [_all] Error 2
> 
> Happens for most archs. See http://l4x.org/k/

Thanks - here is a patch:

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/04/05 23:37:09+02:00 [EMAIL PROTECTED] 
#   kbuild: fix make O=... build
#   
#   It fixes the following error:
#   
#   make[1]: *** No rule to make target `include/asm', needed by 
`arch/alpha/kernel/asm-offsets.s'.  Stop.
#   
#   Reported by:
#   From: Jan Dittmer <[EMAIL PROTECTED]>
#   
#   In same patch fix spaces to tabs as reported by:
#   From: Adrian Bunk <[EMAIL PROTECTED]>
#   
#   Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
# 
# Makefile
#   2005/04/05 23:36:45+02:00 [EMAIL PROTECTED] +3 -3
#   fix make O=... build
# 
diff -Nru a/Makefile b/Makefile
--- a/Makefile  2005-04-05 23:37:38 +02:00
+++ b/Makefile  2005-04-05 23:37:38 +02:00
@@ -576,7 +576,7 @@
 
 ifdef CONFIG_LOCALVERSION_AUTO
localversion-auto := \
-   $(shell $(PERL) $(srctree)/scripts/setlocalversion $(srctree))
+   $(shell $(PERL) $(srctree)/scripts/setlocalversion $(srctree))
LOCALVERSION := $(LOCALVERSION)$(localversion-auto)
 endif
 
@@ -808,7 +808,7 @@
 # prepare1 creates a makefile if using a separate output directory
 prepare1: prepare2 outputmakefile
 
-prepare0: prepare1 include/linux/version.h $(objtree)/include/asm \
+prepare0: prepare1 include/linux/version.h include/asm \
include/config/MARKER
 ifneq ($(KBUILD_MODULES),)
$(Q)rm -rf $(MODVERDIR)
@@ -845,7 +845,7 @@
 #  hard to detect, but I suppose "make mrproper" is a good idea
 #  before switching between archs anyway.
 
-$(objtree)/include/asm:
+include/asm:
@echo '  SYMLINK $@ -> include/asm-$(ARCH)'
$(Q)if [ ! -d include ]; then mkdir -p include; fi;
@ln -fsn asm-$(ARCH) $@
-
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/

[PATCH] networking: restructuring of net/ kconfig

[Sam Ravnborg]

Hi Rany et all.

I have committed the following patch and it will be present in next -mm.

It is present (as the only additional cset) in
bk://linux-sam.bkbits.net/kconfig

davem - any suggestion for next step.
Preferably this goes to Linus via you - or?

Sam

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/04/05 22:59:54+02:00 [EMAIL PROTECTED] 
#   networking: restructure kconfig for net/
#   
#   Based on patch and several rounds of comments from:
#   "Randy.Dunlap" <[EMAIL PROTECTED]>
#   
#   Restructure Networking menu structure creating a separate menu
#   just before Device Drivers.
#   Device drivers for ordinary NIC's are still to be found
#   in the Device Drivers section, but Bluetooth, IrDA and ax25
#   are located with their corresponding menu entries.
#   
#   The patch does the following:
#   o Create a new "Networking" menu just before "Device Drivers"
#   o push all config bits to relevant Kconfig files in net/ hirachy
#   o create new Kconfig files for some subsystem to further push config
# bits out of net/Kconfig
#   o Make more consistent use of menu's avoiding the menuconfig statement
#   o Fix all menu indention for net/
#   
#   No intentional functional changes introduced.
#   
#   Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
# 
# net/x25/Kconfig
#   2005/04/05 22:59:31+02:00 [EMAIL PROTECTED] +35 -0
# 
# net/x25/Kconfig
#   2005/04/05 22:59:31+02:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/sam/bk/v2.6/net/x25/Kconfig
# 
# net/wanrouter/Kconfig
#   2005/04/05 22:59:30+02:00 [EMAIL PROTECTED] +31 -0
# 
# net/wanrouter/Kconfig
#   2005/04/05 22:59:30+02:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/sam/bk/v2.6/net/wanrouter/Kconfig
# 
# net/unix/Kconfig
#   2005/04/05 22:59:28+02:00 [EMAIL PROTECTED] +22 -0
# 
# net/unix/Kconfig
#   2005/04/05 22:59:28+02:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/sam/bk/v2.6/net/unix/Kconfig
# 
# net/packet/Kconfig
#   2005/04/05 22:59:26+02:00 [EMAIL PROTECTED] +26 -0
# 
# net/packet/Kconfig
#   2005/04/05 22:59:26+02:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/sam/bk/v2.6/net/packet/Kconfig
# 
# net/lapb/Kconfig
#   2005/04/05 22:59:24+02:00 [EMAIL PROTECTED] +24 -0
# 
# net/lapb/Kconfig
#   2005/04/05 22:59:24+02:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/sam/bk/v2.6/net/lapb/Kconfig
# 
# net/econet/Kconfig
#   2005/04/05 22:59:22+02:00 [EMAIL PROTECTED] +34 -0
# 
# net/econet/Kconfig
#   2005/04/05 22:59:22+02:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/sam/bk/v2.6/net/econet/Kconfig
# 
# net/core/Kconfig
#   2005/04/05 22:59:21+02:00 [EMAIL PROTECTED] +67 -0
# 
# net/core/Kconfig
#   2005/04/05 22:59:21+02:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/sam/bk/v2.6/net/core/Kconfig
# 
# net/bridge/Kconfig
#   2005/04/05 22:59:19+02:00 [EMAIL PROTECTED] +32 -0
# 
# net/bridge/Kconfig
#   2005/04/05 22:59:19+02:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/sam/bk/v2.6/net/bridge/Kconfig
# 
# net/atm/Kconfig
#   2005/04/05 22:59:17+02:00 [EMAIL PROTECTED] +79 -0
# 
# net/atm/Kconfig
#   2005/04/05 22:59:17+02:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/sam/bk/v2.6/net/atm/Kconfig
# 
# net/appletalk/Kconfig
#   2005/04/05 22:59:16+02:00 [EMAIL PROTECTED] +33 -0
# 
# net/appletalk/Kconfig
#   2005/04/05 22:59:16+02:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/sam/bk/v2.6/net/appletalk/Kconfig
# 
# net/8021q/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +21 -0
# 
# net/xfrm/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +14 -0
#   Move top-level config options from net/Kconfig
# 
# net/sctp/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +6 -3
#   Skip menu - no longer relevant
#   Added config option to fix indention in menuconfig
# 
# net/sched/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +40 -0
#   Move top-level config option from net/Kconfig
#   Wrap it in a menu
# 
# net/irda/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +4 -1
#   Use a real menu for IrDA"
# 
# net/ipx/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +33 -0
#   Move top-level config option from net/Kconfig
# 
# net/ipv6/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +20 -0
#   Move top-level config option from net/Kconfig
# 
# net/ipv4/netfilter/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +0 -5
#   Skip menu - no longer relevant
# 
# net/decnet/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +24 -0
#   Include high level config option from net/Kconfig
# 
# net/bridge/netfilter/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +1 -0
#   BRIDGE depends on INET
# 
# net/bluetooth/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +5 -1
#   Use a real menu for "Bluetooth"
# 
# net/ax25/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +4 -1
#   Use a real menu for "Amateur Radio Support"
# 
# net/Kconfig
#   2005/04/05 22:59:14+02:00 [EMAIL PROTECTED] +34 -507
#   

Re: ... no drivers for IEEE1394 product 0x/0x/0x in kernel 2.6.12-rc1-bk6

[Bob Gill]

Actually I don't use CONFIG_DEVFS_FS as it tends to break things here
(and I found wasn't necessary for things to work, in fact it got in the
way of some things working, some of the autodetect/hotplug peripherels
didn't like it).  Thank you for the reply though.
Bob

On Mon, 2005-04-04 at 20:14 -0700, Barry K. Nathan wrote:
> On Mon, Apr 04, 2005 at 08:22:56PM -0600, Bob Gill wrote:
> > Hi.  I recently built 2.6.12-rc1-bk6.  The kernel seems to be tripping
> > over sbp2.  The error messages keep right on rolling till I hit the
> > reboot button (I let it run for more than 90 seconds last time).
> > 2.6.11.6 builds/runs without any problems.
> [snip]
> 
> I was having the same problem on a system of mine too, but it went away
> after I disabled CONFIG_DEVFS_FS. You didn't include enough of your
> .config for me to be able to tell if that is at all relevant in your
> case however.
> 
> -Barry K. Nathan <[EMAIL PROTECTED]>
-- 
Bob Gill <[EMAIL PROTECTED]>

-
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] radeonfb: (#2) Implement proper workarounds for PLL accesses

[Andreas Schwab]

Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:

> After discussion with ATIs, it seems that the workarounds they initially
> gave me were not completely correct.
>
> This patch implements the proper ones, which includes sleeping in PLL
> accesses, and thus requires the previous patch to make sure we do not
> call unblank at interrupt time (unless oops_in_progress is set, in which
> case I use an mdelay).
>
> It also removes obsolete code that used to disable some power management
> features in the accel init code.

This patch does no good on Radeon M6 (iBook G3).  It makes mode switching
to take an extraordinary amount of time, ie. when switching away from X it
takes about 2-3 seconds until the console is restored.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
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/

fix stale PCI pm docs

[Pavel Machek]

Hi!

This fixes u32 vs. pm_message_t confusion in documentation, and
removes references to no-longer-existing (*save_state), too. With
exception of USB (I hope David will fix/apply my patch), this should
fix last piece of this confusion... famous last words.

Please apply,

Pavel
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

--- clean-mm/Documentation/power/pci.txt2004-12-25 13:34:57.0 
+0100
+++ linux-mm/Documentation/power/pci.txt2005-04-05 12:13:16.0 
+0200
@@ -165,40 +165,9 @@
 These functions are intended for use by individual drivers, and are defined in 
 struct pci_driver:
 
-int  (*save_state) (struct pci_dev *dev, u32 state);
-int  (*suspend) (struct pci_dev *dev, u32 state);
+int  (*suspend) (struct pci_dev *dev, pm_message_t state);
 int  (*resume) (struct pci_dev *dev);
-int  (*enable_wake) (struct pci_dev *dev, u32 state, int enable);
-
-
-save_state
---
-
-Usage:
-
-if (dev->driver && dev->driver->save_state)
-   dev->driver->save_state(dev,state);
-
-The driver should use this callback to save device state. It should take into
-account the current state of the device and the requested state in order to
-avoid any unnecessary operations.
-
-For example, a video card that supports all 4 states (D0-D3), all controller
-context is preserved when entering D1, but the screen is placed into a low 
power
-state (blanked). 
-
-The driver can also interpret this function as a notification that it may be
-entering a sleep state in the near future. If it knows that the device cannot
-enter the requested state, either because of lack of support for it, or because
-the device is middle of some critical operation, then it should fail.
-
-This function should not be used to set any state in the device or the driver
-because the device may not actually enter the sleep state (e.g. another driver
-later causes causes a global state transition to fail).
-
-Note that in intermediate low power states, a device's I/O and memory spaces 
may
-be disabled and may not be available in subsequent transitions to lower power
-states.
+int  (*enable_wake) (struct pci_dev *dev, pci_power_t state, int 
enable);
 
 
 suspend

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: Use of C99 int types

[Kyle Moffett]

On Apr 05, 2005, at 08:18, Richard B. Johnson wrote:
One cannot just use 'int' or 'long', in particular when interfacing
with an operating system. For example, look at the socket interface
code. Parameters are put into an array of longs and a pointer to
this array is passed to the socket interface. It's a mess when
converting this code to 64-bit world.
Exactly
If originally one used a structure of the correct POSIX integer
types, and a pointer to the structure was passed, then absolutely
nothing in the source-code would have to be changed at all when
compiling that interface for a 64-bit machine.
But you _can't_ use the POSIX integer types.  When compiling the
kernel, if you use the types, you must define them in the kernel
headers.  On the other hand, when compiling userspace stuff, you
_can't_ have them defined in the kernel headers because libc also
defines them.  The solution is to use __{s,u}{8,16,32,64}, which
are _only_ defined by the kernel, not by libc or gcc, and can be
therefore used in the ABI.
The continual short-cuts, with the continual "special-case"
hacks is what makes porting difficult. That's what the POSIX
types was supposed to help prevent.
Except the POSIX types themselves are not usable for the boundary
code for the reasons of double definition.  Google for Linus'
posts on this topic a couple months ago.
That's why I think if there was a stdint.h file in the kernel,
when people were performing maintenance or porting their code,
they could start using those types.
The types _are_ available from the kernel headers, but only when
compiling with __KERNEL__, to avoid conflicts from the libc
definitions.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r  
!y?(-)
--END GEEK CODE BLOCK--

-
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/

fix u32 vs. pm_message_t in driver/video

[Pavel Machek]

Hi!

This fixes u32 vs. pm_message_t confusion in drivers/video. Should
change no code. Please apply,

Pavel
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

--- clean-mm/drivers/video/backlight/corgi_bl.c 2005-03-19 00:31:59.0 
+0100
+++ linux-mm/drivers/video/backlight/corgi_bl.c 2005-04-05 12:13:38.0 
+0200
@@ -81,7 +81,7 @@
 }
 
 #ifdef CONFIG_PM
-static int corgibl_suspend(struct device *dev, u32 state, u32 level)
+static int corgibl_suspend(struct device *dev, pm_message_t state, u32 level)
 {
if (level == SUSPEND_POWER_DOWN)
corgibl_blank(FB_BLANK_POWERDOWN);
--- clean-mm/drivers/video/pxafb.c  2005-04-05 10:55:24.0 +0200
+++ linux-mm/drivers/video/pxafb.c  2005-04-05 12:13:38.0 +0200
@@ -942,7 +942,7 @@
  * Power management hooks.  Note that we won't be called from IRQ context,
  * unlike the blank functions above, so we may sleep.
  */
-static int pxafb_suspend(struct device *dev, u32 state, u32 level)
+static int pxafb_suspend(struct device *dev, pm_message_t state, u32 level)
 {
struct pxafb_info *fbi = dev_get_drvdata(dev);
 
--- clean-mm/drivers/video/sa1100fb.c   2005-04-05 10:55:24.0 +0200
+++ linux-mm/drivers/video/sa1100fb.c   2005-04-05 12:13:38.0 +0200
@@ -1307,7 +1307,7 @@
  * Power management hooks.  Note that we won't be called from IRQ context,
  * unlike the blank functions above, so we may sleep.
  */
-static int sa1100fb_suspend(struct device *dev, u32 state, u32 level)
+static int sa1100fb_suspend(struct device *dev, pm_message_t state, u32 level)
 {
struct sa1100fb_info *fbi = dev_get_drvdata(dev);
 
--- clean-mm/drivers/video/savage/savagefb_driver.c 2005-04-05 
10:55:24.0 +0200
+++ linux-mm/drivers/video/savage/savagefb_driver.c 2005-04-05 
12:13:38.0 +0200
@@ -2103,7 +2103,7 @@
}
 }
 
-static int savagefb_suspend (struct pci_dev* dev, u32 state)
+static int savagefb_suspend (struct pci_dev* dev, pm_message_t state)
 {
struct fb_info *info =
(struct fb_info *)pci_get_drvdata(dev);
@@ -2118,7 +2118,7 @@
release_console_sem();
 
pci_disable_device(dev);
-   pci_set_power_state(dev, state);
+   pci_set_power_state(dev, pci_choose_state(dev, state));
 
return 0;
 }
--- clean-mm/drivers/video/w100fb.c 2005-04-05 10:55:24.0 +0200
+++ linux-mm/drivers/video/w100fb.c 2005-04-05 12:13:38.0 +0200
@@ -544,7 +544,7 @@
 
 
 #ifdef CONFIG_PM
-static int w100fb_suspend(struct device *dev, u32 state, u32 level)
+static int w100fb_suspend(struct device *dev, pm_message_t state, u32 level)
 {
if (level == SUSPEND_POWER_DOWN) {
struct fb_info *info = dev_get_drvdata(dev);


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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/

fix u32 vs. pm_message_t in rest of the tree

[Pavel Machek]

Hi!

This fixes u32 vs. pm_message_t confusion in remaining
places. Fortunately there's few of them. Should
change no code. Please apply,

Pavel
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

--- clean-mm/arch/sh/kernel/cpu/bus.c   2004-08-15 19:14:54.0 +0200
+++ linux-mm/arch/sh/kernel/cpu/bus.c   2005-04-05 12:13:19.0 +0200
@@ -31,7 +31,7 @@
return shdev->dev_id == shdrv->dev_id;
 }
 
-static int sh_bus_suspend(struct device *dev, u32 state)
+static int sh_bus_suspend(struct device *dev, pm_message_t state)
 {
struct sh_dev *shdev = to_sh_dev(dev);
struct sh_driver *shdrv = to_sh_driver(dev->driver);
--- clean-mm/drivers/ide/pci/sc1200.c   2005-01-12 11:07:39.0 +0100
+++ linux-mm/drivers/ide/pci/sc1200.c   2005-04-05 12:13:23.0 +0200
@@ -346,7 +346,7 @@
 } sc1200_saved_state_t;
 
 
-static int sc1200_suspend (struct pci_dev *dev, u32 state)
+static int sc1200_suspend (struct pci_dev *dev, pm_message_t state)
 {
ide_hwif_t  *hwif = NULL;
 
--- clean-mm/drivers/macintosh/via-pmu.c2005-04-05 10:55:13.0 
+0200
+++ linux-mm/drivers/macintosh/via-pmu.c2005-04-05 12:13:24.0 
+0200
@@ -3052,7 +3052,7 @@
 
 static int pmu_sys_suspended = 0;
 
-static int pmu_sys_suspend(struct sys_device *sysdev, u32 state)
+static int pmu_sys_suspend(struct sys_device *sysdev, pm_message_t state)
 {
if (state != PM_SUSPEND_DISK || pmu_sys_suspended)
return 0;
--- clean-mm/include/asm-sh/bus-sh.h2004-08-15 19:15:05.0 +0200
+++ linux-mm/include/asm-sh/bus-sh.h2005-04-05 12:13:39.0 +0200
@@ -34,7 +34,7 @@
unsigned intbus_id;
int (*probe)(struct sh_dev *);
int (*remove)(struct sh_dev *);
-   int (*suspend)(struct sh_dev *, u32);
+   int (*suspend)(struct sh_dev *, pm_message_t);
int (*resume)(struct sh_dev *);
 };
 
--- clean-mm/include/linux/mmc/host.h   2004-10-01 00:30:30.0 +0200
+++ linux-mm/include/linux/mmc/host.h   2005-04-05 12:13:39.0 +0200
@@ -98,7 +98,7 @@
 #define mmc_priv(x)((void *)((x) + 1))
 #define mmc_dev(x) ((x)->dev)
 
-extern int mmc_suspend_host(struct mmc_host *, u32);
+extern int mmc_suspend_host(struct mmc_host *, pm_message_t);
 extern int mmc_resume_host(struct mmc_host *);
 
 extern void mmc_detect_change(struct mmc_host *);
--- clean-mm/sound/oss/cs46xx.c 2005-04-05 10:55:41.0 +0200
+++ linux-mm/sound/oss/cs46xx.c 2005-04-05 12:13:42.0 +0200
@@ -3640,7 +3640,7 @@
 
 static void cs461x_reset(struct cs_card *card);
 static void cs461x_proc_stop(struct cs_card *card);
-static int cs46xx_suspend(struct cs_card *card, u32 state)
+static int cs46xx_suspend(struct cs_card *card, pm_message_t state)
 {
unsigned int tmp;
CS_DBGOUT(CS_PM | CS_FUNCTION, 4, 


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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] Re: It's getting worse: 2.6.12-rc2-mm1 and suspend2ram

[Pavel Machek]

Hi!

> > I do not know why you can't unload them, but what about simply not
> > loading them at all? :-).
> 
> hotplug.
> 
> 
> Whatever, booting with init=/bin/sh I get these processes running
>   PID TTY  STAT   TIME COMMAND
> 1 ?R  0:00 /bin/bash
> 2 ?SN 0:00 [ksoftirqd/0]
> 3 ?S  0:00 [watchdog/0]
> 4 ?S< 0:00 [events/0]
> 5 ?S< 0:00 [khelper]
> 6 ?S< 0:00 [kthread]
> 8 ?S< 0:00 [kacpid]
>98 ?S< 0:00 [kblockd/0]
>   153 ?S  0:00 [pdflush]
>   154 ?S  0:00 [pdflush]
>   155 ?S  0:00 [kswapd0]
>   156 ?S< 0:00 [aio/0]
>   231 ?S  0:00 [kseriod]
>   301 ?S  0:00 [kjournald]
>   309 ?S   553 ?R  0:00 ps ax
> 
> and the same happens. Instant reboot.
> 
> So who could be the culprit from the compiled in stuff:
> cpufreq
> netfilter
> input stuff
> serio stuff
> snd stuff (but not the actual driver snd_interl8x0 which is modular)
> 
> well that's it. Strange.

Well, I do not have working suspend-to-RAM setup close to me... Could
you try 2.6.12-rc1 to see if reboot problem is -mm specific or not?

input is known for some funky behaviour, especially with
synaptics. Disabling cpufreq might be good idea, too...

Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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/

fix u32 vs. pm_message_t in drivers/

[Pavel Machek]

Hi!

-rc2-mm1 still contains few places where u32 and pm_message_t. This
fixes drivers/serial [should change no code]. Please apply,
Pavel

--- clean-mm/drivers/serial/amba-pl010.c2004-12-25 13:35:01.0 
+0100
+++ linux-mm/drivers/serial/amba-pl010.c2005-04-05 12:13:37.0 
+0200
@@ -772,7 +772,7 @@
return 0;
 }
 
-static int pl010_suspend(struct amba_device *dev, u32 state)
+static int pl010_suspend(struct amba_device *dev, pm_message_t state)
 {
struct uart_amba_port *uap = amba_get_drvdata(dev);
 
--- clean-mm/drivers/serial/imx.c   2005-04-05 10:55:20.0 +0200
+++ linux-mm/drivers/serial/imx.c   2005-04-05 12:13:37.0 +0200
@@ -825,7 +825,7 @@
.cons   = IMX_CONSOLE,
 };
 
-static int serial_imx_suspend(struct device *_dev, u32 state, u32 level)
+static int serial_imx_suspend(struct device *_dev, pm_message_t state, u32 
level)
 {
 struct imx_port *sport = dev_get_drvdata(_dev);
 
--- clean-mm/drivers/serial/pmac_zilog.c2005-02-03 22:27:18.0 
+0100
+++ linux-mm/drivers/serial/pmac_zilog.c2005-04-05 12:13:37.0 
+0200
@@ -1590,7 +1590,7 @@
 }
 
 
-static int pmz_suspend(struct macio_dev *mdev, u32 pm_state)
+static int pmz_suspend(struct macio_dev *mdev, pm_message_t pm_state)
 {
struct uart_pmac_port *uap = dev_get_drvdata(>ofdev.dev);
struct uart_state *state;
--- clean-mm/drivers/serial/pxa.c   2004-12-25 13:35:01.0 +0100
+++ linux-mm/drivers/serial/pxa.c   2005-04-05 12:13:37.0 +0200
@@ -797,7 +797,7 @@
.cons   = PXA_CONSOLE,
 };
 
-static int serial_pxa_suspend(struct device *_dev, u32 state, u32 level)
+static int serial_pxa_suspend(struct device *_dev, pm_message_t state, u32 
level)
 {
 struct uart_pxa_port *sport = dev_get_drvdata(_dev);
 
--- clean-mm/drivers/serial/s3c2410.c   2005-03-19 00:31:50.0 +0100
+++ linux-mm/drivers/serial/s3c2410.c   2005-04-05 12:13:37.0 +0200
@@ -1156,7 +1156,7 @@
 
 #ifdef CONFIG_PM
 
-int s3c24xx_serial_suspend(struct device *dev, u32 state, u32 level)
+int s3c24xx_serial_suspend(struct device *dev, pm_message_t state, u32 level)
 {
struct uart_port *port = s3c24xx_dev_to_port(dev);
 
--- clean-mm/drivers/serial/sa1100.c2005-03-19 00:31:50.0 +0100
+++ linux-mm/drivers/serial/sa1100.c2005-04-05 12:13:37.0 +0200
@@ -854,7 +854,7 @@
.cons   = SA1100_CONSOLE,
 };
 
-static int sa1100_serial_suspend(struct device *_dev, u32 state, u32 level)
+static int sa1100_serial_suspend(struct device *_dev, pm_message_t state, u32 
level)
 {
struct sa1100_port *sport = dev_get_drvdata(_dev);
 
--- clean-mm/drivers/serial/serial_txx9.c   2005-02-03 22:27:18.0 
+0100
+++ linux-mm/drivers/serial/serial_txx9.c   2005-04-05 12:13:37.0 
+0200
@@ -1095,7 +1095,7 @@
}
 }
 
-static int pciserial_txx9_suspend_one(struct pci_dev *dev, u32 state)
+static int pciserial_txx9_suspend_one(struct pci_dev *dev, pm_message_t state)
 {
int line = (int)(long)pci_get_drvdata(dev);
 
--- clean-mm/drivers/serial/vr41xx_siu.c2005-03-19 00:31:50.0 
+0100
+++ linux-mm/drivers/serial/vr41xx_siu.c2005-04-05 12:13:37.0 
+0200
@@ -1026,7 +1026,7 @@
return 0;
 }
 
-static int siu_suspend(struct device *dev, u32 state, u32 level)
+static int siu_suspend(struct device *dev, pm_message_t state, u32 level)
 {
struct uart_port *port;
int i;

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: fix u32 vs. pm_message_t in usb

[Pavel Machek]

Hi!

> Actually, please do NOT apply this.  It conflicts with other
> patches, which have been in the past few MM releases, have
> also been circulated on linux-usb-devel, and actually address
> some of the bugs which crept in as things have changed around
> the USB stack.

It seems to me that USB stack still needs some u32-vs-pm_message_t
changes (in rc2-mm1):

Could you apply them?
Pavel

--- clean-mm/drivers/usb/core/hub.c 2005-04-05 11:22:15.0 +0200
+++ linux-mm/drivers/usb/core/hub.c 2005-04-05 12:13:38.0 +0200
@@ -1456,7 +1456,7 @@
/* FIXME let caller ask to power down the port:
 *  - some devices won't enumerate without a VBUS power cycle
 *  - SRP saves power that way
-*  - usb_suspend_device(dev,PM_SUSPEND_DISK)
+*  - usb_suspend_device(dev, PMSG_SUSPEND)
 * That's easy if this hub can switch power per-port, and
 * khubd reactivates the port later (timer, SRP, etc).
 * Powerdown must be optional, because of reset/DFU.
@@ -1531,7 +1531,7 @@
 
 /*
  * Devices on USB hub ports have only one "suspend" state, corresponding
- * to ACPI D2 (PM_SUSPEND_MEM), "may cause the device to lose some context".
+ * to ACPI D2, "may cause the device to lose some context".
  * State transitions include:
  *
  *   - suspend, resume ... when the VBUS power link stays live
--- clean-mm/drivers/usb/gadget/omap_udc.c  2005-03-19 00:31:52.0 
+0100
+++ linux-mm/drivers/usb/gadget/omap_udc.c  2005-04-05 12:13:38.0 
+0200
@@ -2809,17 +2809,15 @@
return 0;
 }
 
-/* suspend/resume/wakeup from sysfs (echo > power/state) */
-
-static int omap_udc_suspend(struct device *dev, u32 state, u32 level)
+static int omap_udc_suspend(struct device *dev, pm_message_t state, u32 level)
 {
if (level != 0)
return 0;
 
DBG("suspend, state %d\n", state);
omap_pullup(>gadget, 0);
-   udc->gadget.dev.power.power_state = 3;
-   udc->gadget.dev.parent->power.power_state = 3;
+   udc->gadget.dev.power.power_state = PMSG_SUSPEND;
+   udc->gadget.dev.parent->power.power_state = PMSG_SUSPEND;
return 0;
 }
 
@@ -2829,8 +2827,8 @@
return 0;
 
DBG("resume + wakeup/SRP\n");
-   udc->gadget.dev.parent->power.power_state = 0;
-   udc->gadget.dev.power.power_state = 0;
+   udc->gadget.dev.parent->power.power_state = PMSG_ON;
+   udc->gadget.dev.power.power_state = PMSG_ON;
omap_pullup(>gadget, 1);
 
/* maybe the host would enumerate us if we nudged it */
--- clean-mm/drivers/usb/host/ohci-omap.c   2005-04-05 10:55:21.0 
+0200
+++ linux-mm/drivers/usb/host/ohci-omap.c   2005-04-05 12:13:38.0 
+0200
@@ -458,9 +458,11 @@
 
 /* states match PCI usage, always suspending the root hub except that
  * 4 ~= D3cold (ACPI D3) with clock off (resume sees reset).
+ *
+ * FIXME: above comment is not right, and code is wrong, too :-(.
  */
 
-static int ohci_omap_suspend(struct device *dev, u32 state, u32 level)
+static int ohci_omap_suspend(struct device *dev, pm_message_t state, u32 level)
 {
struct ohci_hcd *ohci = hcd_to_ohci(dev_get_drvdata(dev));
int status = -EINVAL;
--- clean-mm/drivers/usb/host/ohci-pxa27x.c 2005-03-19 00:31:53.0 
+0100
+++ linux-mm/drivers/usb/host/ohci-pxa27x.c 2005-04-05 12:13:38.0 
+0200
@@ -337,7 +337,7 @@
return 0;
 }
 
-static int ohci_hcd_pxa27x_drv_suspend(struct device *dev, u32 state, u32 
level)
+static int ohci_hcd_pxa27x_drv_suspend(struct device *dev, pm_message_t state, 
u32 level)
 {
 // struct platform_device *pdev = to_platform_device(dev);
 // struct usb_hcd *hcd = dev_get_drvdata(dev);
@@ -346,7 +346,7 @@
return 0;
 }
 
-static int ohci_hcd_pxa27x_drv_resume(struct device *dev, u32 state)
+static int ohci_hcd_pxa27x_drv_resume(struct device *dev, u32 level)
 {
 // struct platform_device *pdev = to_platform_device(dev);
 // struct usb_hcd *hcd = dev_get_drvdata(dev);


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Don Armstrong]

[MFT set to -legal, as this is becoming legal arcana probably not
particularly interesting to any other list.]

On Tue, 05 Apr 2005, Sven Luther wrote:
> There are two solutions to this issue, either you abide by the GPL
> and provide also the source code of those firmware binaries (the
> prefered solution :), or you modify the copyright statement of these
> files, to indicate that even thought the file per se is under the
> GPL, the firmware binary code is not, and give us a licence to
> distribute it. Something akin to :
> 
> /* This program, except the firmware binary code,  is free software; you can  
> */
> /* redistribute it and/or modify it under the terms of the GNU General Public 
> */
> /* License as published by the Free Software Foundation, located in the file  
> */
> /* LICENSE.   
> */
> /* Distribution, either as is or modified syntactically to adapt to the   
> */
> /* layout of the surrounding GPLed code is allowed, provided this copyright   
> */
> /* notice is acompanying it   
> */

Just a word of warning: The wording above fails to make it clear what
the second clause is applying to. Additionally it has the following
restrictions that are probably not intended:

   1) Does not specifically allow this firware to be sold as part of an
  aggregate

   2) The range of modifications allowed is rather vague, and implies
  that the firmware can't be extracted

I'd instead suggest applying a pre-existing license like MIT[1] to the
firmware portion of the code file, rather than inventing your own
licensing text that only partially deals with the problem(s) at issue.
(Inventing licensing text is quite often very hazardous to your
health.)


Don Armstrong

1: http://www.opensource.org/licenses/mit-license.php
-- 
Build a fire for a man, an he'll be warm for a day.  Set a man on   
fire, and he'll be warm for the rest of his life.
 -- Jules Bean

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: [ACPI] Re: It's getting worse: 2.6.12-rc2-mm1 and suspend2ram

[Norbert Preining]

On Die, 05 Apr 2005, Pavel Machek wrote:
> Well, I do not have working suspend-to-RAM setup close to me... Could
> you try 2.6.12-rc1 to see if reboot problem is -mm specific or not?

You mean rc2? with rc1-mm4 it is working.

> input is known for some funky behaviour, especially with
> synaptics. Disabling cpufreq might be good idea, too...

Hmm, ok, I compile it modular, and also cpufreq, and try again wiht
init=/bin/bash. But not today, time for going home.

Best wishes

Norbert

---
Dr. Norbert Preining  Università di Siena
sip:[EMAIL PROTECTED] +43 (0) 59966-690018
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
CLUNES (pl.n.)
People who just won't go.
--- Douglas Adams, The Meaning of Liff
-
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/

[PATCH] Fix linux/atalk.h header

[David S. Miller]

This recently got changed to include a lot of kernel internal
stuff in the non-__KERNEL__ area of the header, which isn't
so kosher and breaks libc builds.

The fix is pretty simple.

Signed-off-by: David S. Miller <[EMAIL PROTECTED]>

= include/linux/atalk.h 1.12 vs edited =
--- 1.12/include/linux/atalk.h  2005-03-07 09:33:17 -08:00
+++ edited/include/linux/atalk.h2005-04-02 13:20:13 -08:00
@@ -1,8 +1,6 @@
 #ifndef __LINUX_ATALK_H__
 #define __LINUX_ATALK_H__
 
-#include 
-
 /*
  * AppleTalk networking structures
  *
@@ -39,6 +37,10 @@
__u16   nr_lastnet;
 };
 
+#ifdef __KERNEL__
+
+#include 
+
 struct atalk_route {
struct net_device  *dev;
struct atalk_addr  target;
@@ -80,8 +82,6 @@
 {
return (struct atalk_sock *)sk;
 }
-
-#ifdef __KERNEL__
 
 #include 
 
-
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/

My SWSUSP problems

[Michal Semler]

Hi,

There are some problems I have on my laptop using SWSUPS. This is it's 
summary:

1] When hibernate with different hw configuratin (USB devices, pcmcia 
devices), computer freezes imeditially after reading hibernate file from swap 
and after reset with hw configuration I had when hibernating, file is not 
readed again - data are lost - CRITICAL PROBLEM
2] When playing some OpenGL game or starting OpenGL application after 
hibernate, this app doesn't work till I kills X server. - tested on Intel 
852/855 Extreme graphics - for testing try for example glxgears - COMMON BUG

PLS let me know if these problems are solved or not and if are some developers 
interested about fixing them.

I use linux vanilla 2.6.11.6, Debian Testing, Acer TravelMate 240 serie

Michal
-
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/5] Hotplug firmware loader for Keyspan usb-serial driver

[Jan Harkes]

On Tue, Apr 05, 2005 at 10:45:30PM +0200, Kay Sievers wrote:
> On Tue, 2005-04-05 at 15:38 -0400, Jan Harkes wrote:
> > Here is another stab at making the keyspan firmware easily loadable with
> > hotplug. Differences from the previous version,
> > 
> > - keep the IHEX parser into a separate module.
> > - added a fw-y and fw-m install targets to kbuild which will install a
> >   driver's firmware files in /lib/modules/`uname -r`/firmware.
> > 
> > 01 - Add lib/ihex_parser.ko.
> 
> Oh, I just see now that it's a EZ-USB device. Did you try adapting the
> driver to use fxload(8)? to load the firmware. I have a USB-Modem that
> works perfect with loading ez-firmware that way.

Never heard of fxload before. I just tried it by moving the firmware
directory out of the way so that hotplug wouldn't try to initialize the
device behind my back.

# fxload -v -t fx -D /proc/bus/usb/002/011 -I keyspan-usa19qi.fw 
microcontroller type: fx
single stage:  load on-chip memory
open RAM hexfile image keyspan-usa19qi.fw
stop CPU
write on-chip, addr 0x0033 len3 (0x0003)
write on-chip, addr 0x001a len4 (0x0004)
write on-chip, addr 0x0003 len   23 (0x0017)
write on-chip, addr 0x0023 len3 (0x0003)
write on-chip, addr 0x0046 len  192 (0x00c0)
write on-chip, addr 0x0043 len3 (0x0003)
write on-chip, addr 0x len3 (0x0003)
write on-chip, addr 0x0026 len   12 (0x000c)
write on-chip, addr 0x0106 len  960 (0x03c0)
write on-chip, addr 0x04c6 len  960 (0x03c0)
write on-chip, addr 0x0886 len  960 (0x03c0)
write on-chip, addr 0x0c46 len  905 (0x0389)
... WROTE: 4028 bytes, 12 segments, avg 335
reset CPU

# dmesg | tail
keyspan 2-1:1.0: device disconnected
usb 2-1: new full speed USB device using uhci_hcd and address 11
keyspan 2-1:1.0: Keyspan - (without firmware) converter detected
usb 2-1: Required firmware image (keyspan-usa19qi.fw) unavailable.
>>> fxload was used at this point
usb 2-1: USB disconnect, address 11
keyspan 2-1:1.0: device disconnected
usb 2-1: new full speed USB device using uhci_hcd and address 12
usb 2-1: configuration #1 chosen from 2 choices
keyspan 2-1:1.0: Keyspan 1 port adapter converter detected
usb 2-1: Keyspan 1 port adapter converter now attached to ttyUSB0

Looks like it works, so I guess the pre-numeration stuff in the driver
is really not necessary. We just need a bunch of hotplug rules to load
the correct firmware whenever an uninitialized device is plugged in and
some way to distribute the firmware images.

Jan

-
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: i8042 controller on Toshiba Satellite P10 notebook - patch

[Jaco Kroon]

Dmitry Torokhov wrote:
> On Apr 5, 2005 4:01 PM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
> 
>>btw Dmitri, that patch does not seem to work.  But the kernel panic that
>>kicks in when X starts up does imply that _something_ changed.  No sync
>>however, so no stack trace in the logs either.  In fact, looking at the
>>dmesg part of those two boot attempts the serio i8042 driver doesn't
>>even manage to find the KBD or AUX ports (No keyboard or mouse).
> 
> I wounder how it could be. The patch just does i8042_nomux=1, exactly
> as i8042.nomux does. Can I get that panic trace, please? I assume you
> see it on the screen?
Black screen.  That is it.  Will try again tomorrow if I can - right now
I dearly need some sleep.

>>I can do more trouble shooting at a later point.  For now I'll just use
>>"i8042.nomux=1 usb-handoff" to boot with.  Thanks for the effort.
> 
> You were still using "usb-handoff" with my patch, weren't you? Only
> "i8042.nomux" can be dropped.

Yes.

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Brian Gerst]

Jeff Garzik wrote:
Brian Gerst wrote:
Jeff Garzik wrote:
Josselin Mouette wrote:
Finally, you shouldn't forget that, technically speaking, using hotplug
for uploading the firmware is much more flexible and elegant than
including it in the kernel. Upgrading the firmware and the module 
should
be two independent operations. People who are advocating the current
situation are refusing technical improvements just because they are
brought by people they find convenient to call "zealots".


This is highly amusing, coming from someone who does not maintain a 
driver with a firmware.

The current firmware infrastructure is too primitive.  Compiling the 
firmware into the driver is much easier on the driver maintainers and 
users, presently.

Repeating myself,
* Most firmwares are a -collection- of images and data.  The firmware 
infrastructure should load an -archive- of firmwares and associated 
data values.

The firmware interface should only be concerned with getting the blob 
of data into kernel space.  Once it is in kernel space the driver can 
parse out whatever archive format it is in.  Take for example the ihex 
code that was posted recently.  Similar code could be written to parse 
out a tarball, cpio archive, etc.

The archive format for firmware data collections must be standardized, 
and generic code for loading such collections needs to be written, not 
duplicated into each driver.
I never said code shouldn't be standardized or shared.  I just said that 
it is a seperate function from the process of transferring the data from 
userspace to kernel space.  That said, initramfs already uses cpio, so 
that would be a good choice to use.

--
Brian Gerst
-
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: i8042 controller on Toshiba Satellite P10 notebook - patch

[Dmitry Torokhov]

On Apr 5, 2005 4:01 PM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
> 
> btw Dmitri, that patch does not seem to work.  But the kernel panic that
> kicks in when X starts up does imply that _something_ changed.  No sync
> however, so no stack trace in the logs either.  In fact, looking at the
> dmesg part of those two boot attempts the serio i8042 driver doesn't
> even manage to find the KBD or AUX ports (No keyboard or mouse).
> 

I wounder how it could be. The patch just does i8042_nomux=1, exactly
as i8042.nomux does. Can I get that panic trace, please? I assume you
see it on the screen?

> I can do more trouble shooting at a later point.  For now I'll just use
> "i8042.nomux=1 usb-handoff" to boot with.  Thanks for the effort.

You were still using "usb-handoff" with my patch, weren't you? Only
"i8042.nomux" can be dropped.

-- 
Dmitry
-
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/

[PATCH] ppc64 Kconfig memory models

[Mike Kravetz]

This patch changes some of the default behavior in the ppc64 Kconfig
file that was recently changed/added to 2.6.12-rc2-mm1 by Dave Hansen
in preparation for SPARSEMEM.  Patch allows the display of both FLAT
and DISCONTIG models on pseries.  As before, default is DISCONTIG for
SMP and PSERIES and FLAT for others.

-- 
Signed-off-by: Mike Kravetz <[EMAIL PROTECTED]>

diff -Naupr linux-2.6.12-rc2-mm1/arch/ppc64/Kconfig 
linux-2.6.12-rc2-mm1.work/arch/ppc64/Kconfig
--- linux-2.6.12-rc2-mm1/arch/ppc64/Kconfig 2005-04-05 18:44:57.0 
+
+++ linux-2.6.12-rc2-mm1.work/arch/ppc64/Kconfig2005-04-05 
18:54:36.0 +
@@ -199,9 +199,16 @@ config HMT
  pSeries systems p620 and p660 have such a cpu type.
 
 config ARCH_DISCONTIGMEM_ENABLE
-   bool "Discontiguous Memory Support"
+   def_bool y
depends on SMP && PPC_PSERIES
 
+config ARCH_DISCONTIGMEM_DEFAULT
+   def_bool y
+   depends on ARCH_DISCONTIGMEM_ENABLE
+
+config ARCH_FLATMEM_ENABLE
+   def_bool y
+
 source "mm/Kconfig"
 
 config NUMA
-
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: [SCSI] Driver Broken in 2.6.x (attemp 2)

[|TEcHNO|]

Hi,
I don't think anyone has the actual hardware, without which it's quite
difficult to fix the problem.

What was the last 2.6 kernel version that this worked with?
I guess I made a jump from 2.4.26 directly to 2.6.9 or maybe even 
higher, but I can't remember if I used the scanner since then, most 
probably is that it was last used it in 2.4.x.

Is mentioned in previous post, I can do as much as possible to help, 
including testing patches and/or recompiling the kernel in any way needed.

Sorry for posting to 2 gropus but I'm not subscribed to any, and I'm not 
sure to which (if any) was this reply sent to too.
--
pozdrawiam |"Help me master, I felt the burning twilight behind
[EMAIL PROTECTED]|those gates of stell..." --Perihelion, Prophecy Sequence
-
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.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop

[Pavel Machek]

Hi!

> I'm working o

???

> > > [4294672.065000] ACPI: CPU0 (power states: C1[C1]
> > C2[C2] C3[C3])
> > > [4294676.827000] ACPI: (supports S0 S3 S4 S5)
> > 
> > 
> > ...aha, but your system does not support S1 aka
> > standby.
> >  
> 
> Right, so nothing should happen if I try to do it, but
> something does only in /proc/acpi/sleep does the
> system attempt S1 which is not supported.

Feel free to fix it :-).

> Do you know if /proc/acpi/sleep will be deprecated in
> favour of /sys/power/state? If so, this thread will be
> moot ;)

No idea, deprecating it would be ok with me. 

Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: [03/08] fix ia64 syscall auditing

[Randy.Dunlap]

Greg KH wrote:
On Tue, 2005-04-05 at 13:27 -0700, David Mosberger wrote:
On Tue, 5 Apr 2005 09:46:48 -0700, Greg KH <[EMAIL PROTECTED]> said:
 Greg> -stable review patch.  If anyone has any objections, please
 Greg> let us know.
Nitpick: the patch introduces trailing whitespace.

Sorry about that, I've removed it from the patch now.

Why doesn't everybody use emacs and enable show-trailing-whitespace? ;-)

Because some of us use vim and ":set list" to see it, when we remember
to... :)
others check received patches with a script instead of
no, let's not debate $EDITOR.
--
~Randy
-
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 2.6.11] Take control of PCI Master Abort Mode

[Randy.Dunlap]

Ross Biro wrote:
Currently Linux 2.6 assumes the BIOS (or firmware) sets the master abort 
mode flag on PCI bridge chips in a coherent fashion.  This is not always 
the case and the consequences of getting this flag incorrect can cause 
hardware to fail or silent data corruption.  This patch lets the user 
override the BIOS master abort setting at boot time and the distro 
maintainer to set a default according to their target audience.

The comments in the patch are probably a bit too verbose, but I think it 
is a good patch to start discussions around.  If it is decided that 
something should be done about this problem, this patch could be 
included in a -mm release and migrate into Linus's kernel as appropriate.
The comments were helpful to me.
This incarnation of the patch has had minimal testing.  For our internal 
kernels, we always force the master abort mode to 1 and then let the 
device drivers for hardware we know can't handle target aborts switch 
the master abort mode to 0. This does not seem appropriate for general 
release.

Some background for those who do not spend most of their waking hours 
exploring buses and what can go wrong.
Is this related (or could it be -- or should it be) at all to the
current discussion on the linux-pci mailing list
[EMAIL PROTECTED]) about "PCI Error Recovery
API Proposal" ?
The master abort flag tells a PCI bridge what to do when a bus master 
behind the bridge requests the bus and the bridge is unable to get the 
bus.  With the flag clear, for master reads the bridge returns all 
0xff's (hence silent data corruption) and for master writes, it throws 
the data away.  With the bit set, the bridge sends a target abort to the 
master.  This can only happen when the system is heavily loaded.
or a PCI device isn't playing nicely?
The problem with always setting the bit is that some PCI hardware, 
notably some Intel E-1000 chips (Ethernet controller: Intel Corporation: 
Unknown device 1076) cannot properly handle the target abort bit.  In 
the case of the E-1000 chip, the driver must reset the chip to recover. 
This usually leads to the machine being off the network for several 
seconds, or sometimes even minutes, which can be bad for servers.

I even have a single motherboard with both a device that cannot handle 
the target abort and an IDE controller that can handle the target abort 
behind the same bridge.  For this motherboard, I have to choose the 
lesser of two evils, network hiccups or potential data corruption.
For the record, I have seen both occur.  Other people may make wish to 
make a different choice than we did, hence this patch allows the user to 
choose the mode at runtime.

Ross

diff -ur linux-2.6.11/drivers/pci/Kconfig linux-2.6.11-new/drivers/pci/Kconfig
--- linux-2.6.11/drivers/pci/Kconfig	2005-03-01 23:37:51.0 -0800
+++ linux-2.6.11-new/drivers/pci/Kconfig	2005-04-01 07:19:32.0 -0800
@@ -47,3 +47,38 @@
 
 	  When in doubt, say Y.
 
+choice
+	prompt "Enable PCI Master Abort Mode"
+	depends on PCI
+	default PCI_MASTER_ABORT_DEFAULT
+	help
+	  On PCI systems, when a bus is unavailable to a bus master, a 
+	  master abort occurs.  Older bridges satisfy the master request
+	  with all 0xFF's.  This can lead to silent data corruption.  Newer
+	  bridges can send a target abort to the bus master.  Some PCI
+	  hardware cannot handle the target abort.  Some x86 BIOSes configure
+  the buses in a suboptimal way.  This option allows you to override
  ^^^ extra spaces
+	  the BIOS setting.  If unsure chose default.  This choice can be
   choose
+ overridden at boot time with the pci_enable_master_abort={default,
+ enable, disable}
   boot option.
+
+config PCI_MASTER_ABORT_DEFAULT
+   bool "Default"
+   help
+ Choose this option if you are unsure, or believe your
+ firmware does the right thing.
+
+config PCI_MASTER_ABORT_ENABLE
+   bool "Enable"
+   help
+ Choose this option if it is more important for you to prevent
+ silent data loss than to have more hardware configurations work.
 ??
+
+
+config PCI_MASTER_ABORT_DISABLE
+   bool "Disable"
+   help
+ Choose this option if it is more important for you to have more
  
The phrase "have more hardware configurations work" need something
Maybe add something like:  "Some devices are known not to work with
PCI Master Aborts.  If you have one of these devices, you probably
want to Disable this option."

+	  hardware configurations work than to prevent silent data loss.
+
+endchoice
diff -ur linux-2.6.11/drivers/pci/probe.c linux-2.6.11-new/drivers/pci/probe.c
--- linux-2.6.11/drivers/pci/probe.c	2005-03-01 23:38:13.0 -0800
+++ 

linux-2.4.29-hf7 (minor update)

[Willy Tarreau]

Hi All,

just for completeness, I've updated the hotfix tree to hf7. The
changelog is ridiculously small (2 patches: 1 doc, 1 minor). The
2.4.29-hf tree is now up to date with 2.4.30. I will start the
2.4.30-hf soon (when 2.4.31-pre emerges), and will keep updating
2.4.29-hf as long as possible. For this, I'll have to make my
scripts a bit smarter to reduce the dual work, so first 2.4.30-hf
releases might be delayed a bit.

After one full 2.4 release, it seems that the 2.4-hf tree starts
to pay off : one patch which was finally removed in 2.4.30-rc4
never got its way to 2.4-hf and a potential problem affecting
usb-pwc for one 2.4.30 user theorically should not concern
2.4.29-hf. May be those will help maintainers and users of recent
kernels to find where their problem appeared ? Time will tell...

In the mean time, the patches are available at the usual store :

 http://linux.exosec.net/kernel/2.4-hf/


Regards,
Willy

--
Changelog From 2.4.29-hf6 to 2.4.29-hf7 (semi-automated)
---
'+' = added ; '-' = removed


+ bogus-mc_list-deletion-1 (Herbert Xu)

  Looks like I made a nasty typo in the 2.4 backport.  When entries
  are unlinked from mc_list, we link the list up with the regular
  hash bucket list by using next instead of bind_next!

+ recent-kernels-need-modutils-2414-1   (Willy Tarreau)

  From Keith Owens:
  > You need modutils >= 2.4.14 to use the combination of
  > CONFIG_MODVERSIONS with EXPORT_SYMBOL_GPL() on 2.4 kernels.


END.


-
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] network configs: disconnect network options from drivers

[Sam Ravnborg]

On Tue, Apr 05, 2005 at 10:42:25AM -0700, Sridhar Samudrala wrote:
> On Mon, 4 Apr 2005, Sam Ravnborg wrote:
> 
> >
> >Only bit that I am worried about is the statement in SCTP:
> > depends on IPV6 || IPV6=n
> >
> >That looked like a noop to me. It had the sideeffect that SCTP
> >menu entries where idented an extra level which was not desireable
> >with currect layout.
> >
> 
> No. This is not a noop. This is required to restrict SCTP configured as
> static when IPV6 is configured as module.

I see now - thanks.

Sam
-
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: crash in entry.S restore_all, 2.6.12-rc2, x86, PAGEALLOC

[Linus Torvalds]

On Tue, 5 Apr 2005, Ingo Molnar wrote:
> 
>  esi: 009b63f9   edi: 0001   ebp: f543a000   esp: f543bfc8
> 
> i.e. esp & 0xfff was 0xfc8 - while i think it should normally be 0xfc4 
> (page boundary minus size of pt_regs == 0 - 0x3c == 0xfc4). So somewhere 
> we lost 4 bytes of esp? An extra popl, or an addl $4, %esp? But why dont 
> we crash in that case

Normally, esp will be immediately reset by any user-land stuff: we'll 
forget the old kernel stack entirely, and always re-load esp from the esp0 
thing in the TSS.

And as long as we stay in kernel land, we'll obviously never touch the
esp/xss fields of pt_regs (except in this special case of doing the
speculative load of xss), so...

Linus
-
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: crash in entry.S restore_all, 2.6.12-rc2, x86, PAGEALLOC

[Ingo Molnar]

* Linus Torvalds <[EMAIL PROTECTED]> wrote:

> > > So I'd actually prefer to get that mystery explained..
> > IIRC if the interrupt doesn't do the CPL
> > switch, the interrupt gate doesn't save
> > the stack, and so there may not be the
> > full "struct pt_regs" when the kernel
> > thread is interrupted.
> 
> Yes. But how do you have _such_ an empty stack when the interrupt 
> comes in? See what I mean? IOW, that requires that the kernel stack 
> would have only two words on it when the interrupt happens. How?
> 
> It may be a 4kB stack issue or something. Does this happen only with 
> CONFIG_4KSTACKS, and just after a stack switch to an irq stack, for 
> example?

i didnt have 4K stacks set. In all crashes, esp had the same pattern:

 esi: 009b63f9   edi: 0001   ebp: f543a000   esp: f543bfc8

i.e. esp & 0xfff was 0xfc8 - while i think it should normally be 0xfc4 
(page boundary minus size of pt_regs == 0 - 0x3c == 0xfc4). So somewhere 
we lost 4 bytes of esp? An extra popl, or an addl $4, %esp? But why dont 
we crash in that case - it ought to shift all the pt_regs structure by a 
word, making it a completely senseless return frame. Any task in such a 
situation ought to at least segfault. So if this is during thread 
startup, i dont know how it survives the first execution.

Ingo
-
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: i8042 controller on Toshiba Satellite P10 notebook - patch

[Jaco Kroon]

Dmitry Torokhov wrote:
> On Apr 5, 2005 1:20 PM, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
>>Jaco Kroon wrote:
>>>Dmitry Torokhov wrote:
You should be able to control that in xorg.conf.
>>>
>>>My thoughts exactly.  The same goes for gpm.
>>
>>No. AFAIK multifinger taps are handled by the touchpad firmware, but not
>>on ALPS touchpads, only on synaptics.
> 
> Yes, you are right... I meant one could remap actions to corner and
> multi-finger taps in xorg.conf but if hardware does not recognize
> multi-finger taps then you are out of luck.
> 

Argh... This is going to take some getting used to.  Why would ALPS not
have multi-finger detection?  That was such a cool feature.  gpm seems
to be having problems getting the tapping thing right though but I
should most probably just rtfm a bit more :).

btw Dmitri, that patch does not seem to work.  But the kernel panic that
kicks in when X starts up does imply that _something_ changed.  No sync
however, so no stack trace in the logs either.  In fact, looking at the
dmesg part of those two boot attempts the serio i8042 driver doesn't
even manage to find the KBD or AUX ports (No keyboard or mouse).

I can do more trouble shooting at a later point.  For now I'll just use
"i8042.nomux=1 usb-handoff" to boot with.  Thanks for the effort.

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ACPI] Re: It's getting worse: 2.6.12-rc2-mm1 and suspend2ram

[Norbert Preining]

On Die, 05 Apr 2005, Pavel Machek wrote:
> I do not know why you can't unload them, but what about simply not
> loading them at all? :-).

hotplug.


Whatever, booting with init=/bin/sh I get these processes running
  PID TTY  STAT   TIME COMMAND
1 ?R  0:00 /bin/bash
2 ?SN 0:00 [ksoftirqd/0]
3 ?S  0:00 [watchdog/0]
4 ?S< 0:00 [events/0]
5 ?S< 0:00 [khelper]
6 ?S< 0:00 [kthread]
8 ?S< 0:00 [kacpid]
   98 ?S< 0:00 [kblockd/0]
  153 ?S  0:00 [pdflush]
  154 ?S  0:00 [pdflush]
  155 ?S  0:00 [kswapd0]
  156 ?S< 0:00 [aio/0]
  231 ?S  0:00 [kseriod]
  301 ?S  0:00 [kjournald]
  309 ?S Università di Siena
sip:[EMAIL PROTECTED] +43 (0) 59966-690018
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
AITH (n.)
The single bristle that sticks out sideways on a cheap paintbrush.
--- Douglas Adams, The Meaning of Liff
-
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/

x86_64 Opteron dual core panics on boot

[Tom Duffy]

I am trying to get any kernel to boot on dual core Opteron.  I have
tried with kernels 2.6.9-2.6.12-rc2 all with virtually the same panic.

Here is the output with 2.6.12-rc2:

Bootdata ok (command line is ro root=/dev/VolGroup00/LogVol00 console=ttyS0) 
Linux version 2.6.12-rc2andro ([EMAIL PROTECTED]) (gcc version 4.0.0 20050402 
(Red Hat 4.0.0-0.39)) #1 SMP Tue Apr 5 12:29:41 PDT 2005 BIOS-provided physical 
RAM map:
 BIOS-e820:  - 0009fc00 (usable)  BIOS-e820: 
0009fc00 - 000a (reserved)
 BIOS-e820: 000e6000 - 0010 (reserved)  BIOS-e820: 
0010 - 7ffd (usable)
 BIOS-e820: 7ffd - 7ffde000 (ACPI data)  BIOS-e820: 
7ffde000 - 8000 (ACPI NVS)
 BIOS-e820: fec0 - fec01000 (reserved)  BIOS-e820: 
fee0 - fee01000 (reserved)
 BIOS-e820: ffb0 - 0001 (reserved)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: PXM 1 -> APIC 2 -> Node 1
SRAT: PXM 1 -> APIC 3 -> Node 1
SRAT: PXM 2 -> APIC 4 -> Node 2
SRAT: PXM 2 -> APIC 5 -> Node 2
SRAT: PXM 3 -> APIC 6 -> Node 3
SRAT: PXM 3 -> APIC 7 -> Node 3
SRAT: Node 0 PXM 0 10-3fff
SRAT: Node 1 PXM 1 4000-7fff
SRAT: Node 0 PXM 0 0-3fff
Bootmem setup node 0 -3fff
Bootmem setup node 1 4000-7ffc
Nvidia board detected. Ignoring ACPI timer override.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:1 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:1 APIC version 16
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
Processor #2 15:1 APIC version 16
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
Processor #3 15:1 APIC version 16
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
Processor #4 15:1 APIC version 16
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled)
Processor #5 15:1 APIC version 16
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled)
Processor #6 15:1 APIC version 16
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
Processor #7 15:1 APIC version 16
ACPI: IOAPIC (id[0x08] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 8, version 17, address 0xfec0, GSI 0-23
ACPI: IOAPIC (id[0x09] address[0xfeaff000] gsi_base[24])
IOAPIC[1]: apic_id 9, version 17, address 0xfeaff000, GSI 24-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Checking aperture...
CPU 0: aperture @ 800 size 32 MB
Aperture from northbridge cpu 0 too small (32 MB)
No AGP bridge found
Built 2 zonelists
Kernel command line: ro root=/dev/VolGroup00/LogVol00 console=ttyS0
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 2200.043 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Memory: 2054928k/2096960k available (2400k kernel code, 0k reserved, 881k data, 
216k init)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(2) -> Node 0
CPU: Physical Processor ID: 0
Using local APIC NMI watchdog using perfctr0
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(2) -> Node 0
CPU: Physical Processor ID: 0
CPU0: AMD Athlon(tm) or Opteron(tm) CPU-model unknown stepping 00
Booting processor 1/1 rip 6000 rsp 81003ff85f58
Initializing CPU#1
--- [cut here ] - [please bite here ] -
Kernel BUG at timer:418
invalid operand:  [1] SMP
CPU 1
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.12-rc2andro
RIP: 0010:[] {cascade+41}
RSP: 0018:81007ff87ef0  EFLAGS: 00010087
RAX:  RBX:  RCX: 
RDX:  RSI:  RDI: 810001e12ae0
RBP: 810001e13af8 R08: 810001e11800 R09: 03d1
R10: 02dc55dc R11: 007d R12: 810001e12ae0
R13:  R14: 81007ff87f18 R15: 000a
FS:  () GS:80494c80() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2:  CR3: 00101000 CR4: 06a0
Process swapper (pid: 0, threadinfo 81003ff84000, task 81003ff80df0)
Stack:  80495990 810001e12ae0 0080
   80140d17 81007ff87f18 81007ff87f18 0011
   

[PATCH] Fix compat stat handling on sparc64

[David S. Miller]

The compat layer on sparc64 was not filling in the nanosecond
fields in properly for 32-bit compat tasks.  This caused things
like the test-utime.c test to fail in the libc sources.

A problem still remains for native 64-bit binaries.  Like Alpha
the normal stat structure doesn't have the nanosecond fields
so I have to add in the stat64 syscall entry points in the 64-bit
syscall table then add the necessary libc magic.

Signed-off-by: David S. Miller <[EMAIL PROTECTED]>

= arch/sparc64/kernel/sys_sparc32.c 1.118 vs edited =
--- 1.118/arch/sparc64/kernel/sys_sparc32.c 2005-03-21 09:56:06 -08:00
+++ edited/arch/sparc64/kernel/sys_sparc32.c2005-04-05 12:38:54 -07:00
@@ -352,11 +352,11 @@
err |= put_user(old_encode_dev(stat->rdev), >st_rdev);
err |= put_user(stat->size, >st_size);
err |= put_user(stat->atime.tv_sec, >st_atime);
-   err |= put_user(0, >__unused1);
+   err |= put_user(stat->atime.tv_nsec, >st_atime_nsec);
err |= put_user(stat->mtime.tv_sec, >st_mtime);
-   err |= put_user(0, >__unused2);
+   err |= put_user(stat->mtime.tv_nsec, >st_mtime_nsec);
err |= put_user(stat->ctime.tv_sec, >st_ctime);
-   err |= put_user(0, >__unused3);
+   err |= put_user(stat->ctime.tv_nsec, >st_ctime_nsec);
err |= put_user(stat->blksize, >st_blksize);
err |= put_user(stat->blocks, >st_blocks);
err |= put_user(0, >__unused4[0]);
= include/asm-sparc64/compat.h 1.19 vs edited =
--- 1.19/include/asm-sparc64/compat.h   2005-02-17 21:53:03 -08:00
+++ edited/include/asm-sparc64/compat.h 2005-04-05 12:37:58 -07:00
@@ -51,11 +51,11 @@
compat_dev_tst_rdev;
compat_off_tst_size;
compat_time_t   st_atime;
-   u32 __unused1;
+   u32 st_atime_nsec;
compat_time_t   st_mtime;
-   u32 __unused2;
+   u32 st_mtime_nsec;
compat_time_t   st_ctime;
-   u32 __unused3;
+   u32 st_ctime_nsec;
compat_off_tst_blksize;
compat_off_tst_blocks;
u32 __unused4[2];
-
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/