On Mon, 2007-01-29 at 13:31 -0800, john stultz wrote:
> Should I just revive the old 2.6.20-rc4-mm1 patches against your current
> tree and re-submit? Or should the HRT bits get settled first?
Thomas just pointed out that I had missed that the bits are back in
-mm2.
Sorry for the noise.
-john
-
On Tue, 30 Jan 2007, Oleg Nesterov wrote:
> Now we have 2 additional events, CPU_LOCK_ACQUIRE/CPU_LOCK_RELEASE,
> so cpuup_callback() can use them to lock/unlock cache_chain_mutex,
> but this is not related.
Then we wont need to do the mutex_lock/unlock in CPU_DOWN_XX
anymore, right? Which bring
On Mon, 29 Jan 2007 15:30:00 -0500
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> Is there any way to estimate the size of the user base for 2.6.16?
>
> e.g. how many downloads does it get?
I've often wondered that myself, as I'm concerned for it to continue
to be maintained. I'm very appreciative of
On Fri, 26 Jan 2007, Andrew Morton wrote:
> > The main benefit is a significant simplification of the VM, leading to
> > robust and reliable operations and a reduction of the maintenance
> > headaches coming with the additional zones.
> >
> > If we would introduce the ability of allocating from
Regarding the long fsyncs, here's a trace...
I upgraded to a more recent kernel - 2.6.18.6 - and ran it on a workstation.
This particular box has In this case the elevator is CFQ.
This sample came from a stall that lasted about 2.5 minutes(!) - the longest
one I've seen yet. The box is a bit mor
Le mardi 23 janvier 2007 à 09:44 +, Pavel Machek a écrit :
> Hi!
>
> > > > Whitelist? Let me blacklist it all the way to Timbuktu instead!
> > >
> > > > I've been doing more testing, and X never managed to come back to
> > > > working
> > > > state without some of my couple intel-agp changes
Hi!
> > Ok, I guess we'd like some testing here... so that in can be fixed in
> > mainline...
>
> I can confirm that this patch is needed for my Intel Mac Mini to resume
> correctly when used without BIOS emulation (EFI mode). Here're the
> relevant lspci lines:
Can you attach the patch you test
The utsname stuff has been moved from kernel/sysctl.c to the new file
utsname_sysctl.c. Let's use it...
Signed-off-by: Laurent Riffard <[EMAIL PROTECTED]>
---
Index: linux-2.6-mm/kernel/Makefile
===
--- linux-2.6-mm.orig/kernel/Mak
On 01/29, Christoph Lameter wrote:
>
> On Tue, 30 Jan 2007, Oleg Nesterov wrote:
>
> > Now we have 2 additional events, CPU_LOCK_ACQUIRE/CPU_LOCK_RELEASE,
> > so cpuup_callback() can use them to lock/unlock cache_chain_mutex,
> > but this is not related.
>
> Then we wont need to do the mutex_lock
These series of patches add UFS2 write-support.
UFS2 - is default file system for recent versions of FreeBSD.
The main differences from UFS1 from write support point of view
are:
1)Not all inodes are allocated during formatation of disk.
2)All meta-data(pointer to data blocks) are 64bit(in UFS1 th
This patch adds into write inode path function to write
UFS2 inode,
and modifys allocate inode path to allocate and init additional
inode chunks.
Also some cleanups:
- remove not used parameters in some functions
- remove i_gen field from ufs_inode_info structure,
there is i_generation in inode st
Patch adds ability to work with 64bit metadata,
this made by replacing work with 32bit pointers by
inline functions.
Signed-off-by: Evgeniy Dushistov <[EMAIL PROTECTED]>
---
Index: linux-2.6.20-rc5/fs/ufs/balloc.c
===
--- linux-2.6.
Hi Linus,
I made a silly error in my last upstream push. This patch makes
ocfs2 build again.
--Mark
Please pull from 'upstream-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git upstream-linus
to receive the following updates:
fs/ocfs2/ocfs2_fs.h |
Dear all,
I realized that any setting to /sys/module/usbhid/parameters/pb_fnmode
is just ignored until the machine does a suspend-resume cycle.
I've added a printk in drivers/usb/input/hid-core.c (which is the only
place where hid->pb_fnmode is set) and indeed only on module load ( in
my case us
On Sat, 2006-12-23 at 11:38 +0100, Soeren Sonnenburg wrote:
> On Fri, 2006-12-15 at 09:56 -0800, Greg KH wrote:
> > On Fri, Dec 15, 2006 at 09:36:04AM +0100, Soeren Sonnenburg wrote:
> > > On Sat, 2006-12-09 at 21:08 -0500, Joseph Fannin wrote:
> > > > On Fri, 2006-12-08 at 18:19 +0100, Soeren Sonn
On Sat, 27 Jan 2007, Soeren Sonnenburg wrote:
> > > > I've noticed that this patch is not in 2.6.20-rc1. Could you please
> > > > comment on what is wrong with it / whether it will ever have a chance to
> > > > be accepted in the way it is done ?
> > > It's in my queue right now, sorry. I'll cat
On Sat, 27 Jan 2007, Soeren Sonnenburg wrote:
> I realized that any setting to /sys/module/usbhid/parameters/pb_fnmode
> is just ignored until the machine does a suspend-resume cycle.
Hi Soeren,
I would probably not call this a regression, as this has been always
there, as far as I can see.
>
On Mon, 2007-01-29 at 10:55 +0100, Jiri Kosina wrote:
> On Sat, 27 Jan 2007, Soeren Sonnenburg wrote:
>
> > I realized that any setting to /sys/module/usbhid/parameters/pb_fnmode
> > is just ignored until the machine does a suspend-resume cycle.
[...]
> I would rather be inclined to just make the
On Mon, 29 Jan 2007, Soeren Sonnenburg wrote:
> Well I need in-kernel usbhid and the way this was implemented in 2.6.19
> (and before) one could change pb_fnmode on-the-fly. This is mentioned in
> all the power/i/mac/book tutorials and everyone is used to switching
> modes this way. I can happi
On Mon, Jan 29, 2007 at 10:55:48AM +0100, Jiri Kosina wrote:
> Changing module parameter values through sysfs is not a very nice idea,
> because the change of the value is indeed silent - the driver is not
> notified in any way, that the value has changed. So the driver should take
> care of it
On Mon, 2007-01-29 at 10:38 +0100, Jiri Kosina wrote:
> On Sat, 27 Jan 2007, Soeren Sonnenburg wrote:
[...]
> Soeren - could you please submit your patch with proper Signed-off-by
> line?
argh, sorry!
Attached!
Soeren
--
Sometimes, there's a moment as you're waking, when you become aware of
th
On Mon, 29 Jan 2007, Jiri Kosina wrote:
> Ah, now I see. The problem is that in pre-2.6.20-rc1 the pb_fnmode was
> setting global variable, but after the HID layer rework, this is a
> per-hid variable, which is of course not updated when write to sysfs
> triggers. I will try to fix this before
On Mon, 2007-01-29 at 12:13 +0100, Jiri Kosina wrote:
> On Mon, 29 Jan 2007, Jiri Kosina wrote:
>
> > Ah, now I see. The problem is that in pre-2.6.20-rc1 the pb_fnmode was
> > setting global variable, but after the HID layer rework, this is a
> > per-hid variable, which is of course not updated
On Mon, 29 Jan 2007, Soeren Sonnenburg wrote:
> That sounds good for me. Breaking with what was there is not a problem
> as long as this feature is still there, it can be done in a more clean
> way this way, and the new /sys/foo/bar path is documented (basically
> people nowadays expect slight
On Mon, 2007-01-29 at 12:45 +0100, Jiri Kosina wrote:
> On Mon, 29 Jan 2007, Soeren Sonnenburg wrote:
>
> > That sounds good for me. Breaking with what was there is not a problem
> > as long as this feature is still there, it can be done in a more clean
> > way this way, and the new /sys/foo/bar
The following patches (also available though the git tree) address a number
of code cleanliness issues with Unionfs.
You can pull from 'master' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/unionfs.git
to receive the following:
Adrian Bunk (1):
fs/unionfs/: possible cleanu
Josef 'Jeff' Sipek (3):
fs/unionfs/: Remove stale_inode.c
fs/unionfs/: Andrew Morton's comments
fs/unionfs/: Don't duplicate the struct nameidata
fs/unionfs/branchman.c |4 +-
fs/unionfs/commonfops.c | 54 +++---
fs/unionfs/copyup.c | 67 +
- rename {,un}lock_dentry to unionfs_{,un}lock_dentry
- few minor coding style fixes
- removed prototypes from .c files
- replaced dbstart macros etc with static inlines
- replaced UNIONFS_D(d)->sem semaphore with a mutex
- renamed sioq struct workqueue to superio_workqueue
- made unionfs_get_nlink
The only fields that we have to watch out for are the dentry and vfsmount.
Additionally, this makes Unionfs gentler on the stack as nameidata is rather
large.
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/inode.c | 22 --
1 files changed, 16 insertions
The stale inode operations were heavily based on bad inode operations. This
patch removes stale_inode.c and converts all users of stale_inode_ops to
bad_inode_ops as there seems to be no reason to return ESTALE instead of
EIO.
This is the more appropriate than porting the bad_inode.c fix (commit
b
From: Adrian Bunk <[EMAIL PROTECTED]> - unquoted
This patch contains the following possible cleanups:
- every function should #include the headers containing the prototypes
of it's global functions
- static functions in C files shouldn't be marked "inline", gcc should
know best when to inline
On Mon, Jan 29, 2007 at 03:37:43PM -0500, Josef 'Jeff' Sipek wrote:
> Josef 'Jeff' Sipek (3):
> fs/unionfs/: Remove stale_inode.c
> fs/unionfs/: Andrew Morton's comments
> fs/unionfs/: Don't duplicate the struct nameidata
>
> fs/unionfs/branchman.c |4 +-
> fs/unionfs/comm
Le lundi 29 janvier 2007 à 23:10 +0100, Pavel Machek a écrit :
> > > Ok, I guess we'd like some testing here... so that in can be fixed in
> > > mainline...
> >
> > I can confirm that this patch is needed for my Intel Mac Mini to resume
> > correctly when used without BIOS emulation (EFI mode). He
On Mon, 2007-01-29 at 13:38 -0800, Stephen Hemminger wrote:
> Sorry it was against the last patch I sent to Jeff for netdev.
> Here is against 2.6.20-rc6
Still the same problem. The only difference of this patch to the
previous version is, that the unhandled interrupt message is gone.
As I said b
On Mon, 29 Jan 2007 23:23:21 +0100
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-01-29 at 13:38 -0800, Stephen Hemminger wrote:
> > Sorry it was against the last patch I sent to Jeff for netdev.
> > Here is against 2.6.20-rc6
>
> Still the same problem. The only difference of this pat
Hi!
>The /proc/bus/input/devices has an extensible structure. You can just
>add an "A:" line (for Activity) instead of adding a new proc file.
>
> I know, but IMO there is too much stuff to parse in there. Activity counters
> are frequently accessed by daemons, and four or five concurrent
On Mon, 2007-01-29 at 14:23 -0800, Stephen Hemminger wrote:
> > Still the same problem. The only difference of this patch to the
> > previous version is, that the unhandled interrupt message is gone.
> >
> > As I said before:
> >
> > Reverting commit 44ade178249fe53d055fd92113eaa271e06acddd, whic
On Mon, 29 Jan 2007 13:54:38 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 26 Jan 2007, Andrew Morton wrote:
>
> > > The main benefit is a significant simplification of the VM, leading to
> > > robust and reliable operations and a reduction of the maintenance
> > > headache
On Mon, 29 Jan 2007, Thomas Gleixner wrote:
>
> Reverting commit 44ade178249fe53d055fd92113eaa271e06acddd, which added
> this hackery in the first place, makes the device survive
> suspend/resume.
I suspect some BIOSes do *not* screw up the MSI thing on resume, and
others do.
I would suggest
On Mon, Jan 29, 2007 at 11:21:31PM +0100, Frédéric Riss wrote:
> Le lundi 29 janvier 2007 à 23:10 +0100, Pavel Machek a écrit :
> > > > Ok, I guess we'd like some testing here... so that in can be fixed in
> > > > mainline...
> > >
> > > I can confirm that this patch is needed for my Intel Ma
On Mon, Jan 29, 2007 at 04:04:48PM -0500, Mike Houston wrote:
> On Mon, 29 Jan 2007 15:30:00 -0500
> Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> > Is there any way to estimate the size of the user base for 2.6.16?
> >
> > e.g. how many downloads does it get?
>
> I've often wondered that myself,
Le lundi 29 janvier 2007 à 23:23 +0100, Thomas Gleixner a écrit :
> On Mon, 2007-01-29 at 13:38 -0800, Stephen Hemminger wrote:
> > Sorry it was against the last patch I sent to Jeff for netdev.
> > Here is against 2.6.20-rc6
>
> Still the same problem. The only difference of this patch to the
> p
On Mon, Jan 29, 2007 at 04:10:29AM +0100, Andi Kleen wrote:
> On Saturday 27 January 2007 23:02, Andrew Morton wrote:
> > On Sat, 27 Jan 2007 15:01:51 -0500
> >
> > "Parag Warudkar" <[EMAIL PROTECTED]> wrote:
> > > Here is a patch that does what Andrew Morton suggested (plus some more
> > > as expl
Pavel Machek <[EMAIL PROTECTED]> writes:
Hi!
>The /proc/bus/input/devices has an extensible structure. You can just
>add an "A:" line (for Activity) instead of adding a new proc file.
>
> I know, but IMO there is too much stuff to parse in there. Activity
counters
> ar
On Mon, 29 Jan 2007 14:37:23 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 29 Jan 2007, Thomas Gleixner wrote:
> >
> > Reverting commit 44ade178249fe53d055fd92113eaa271e06acddd, which added
> > this hackery in the first place, makes the device survive
> > suspend/resume.
>
On Mon, 2007-01-29 at 23:38 +0100, Frédéric Riss wrote:
> I see the same symptoms on my Intel Mac Mini, and reverting the commit
> also allows the driver to seemingly resume correctly.
>
> However after coming out of sleep I need to reconfigure the network
> interface. No need to rmmod/insmod, ju
On Mon, 29 Jan 2007, Andrew Morton wrote:
> > All 64 bit machine will only have a single zone if we have such a range
> > alloc mechanism. The 32bit ones with HIGHMEM wont be able to avoid it,
> > true. But all arches that do not need gymnastics to access their memory
> > will be able run with
On Mon, Jan 29, 2007 at 02:45:06PM -0800, Christoph Lameter wrote:
> On Mon, 29 Jan 2007, Andrew Morton wrote:
>
> > > All 64 bit machine will only have a single zone if we have such a range
> > > alloc mechanism. The 32bit ones with HIGHMEM wont be able to avoid it,
> > > true. But all arches t
Le lundi 29 janvier 2007 à 23:45 +0100, Thomas Gleixner a écrit :
> On Mon, 2007-01-29 at 23:38 +0100, Frédéric Riss wrote:
> > I see the same symptoms on my Intel Mac Mini, and reverting the commit
> > also allows the driver to seemingly resume correctly.
> >
> > However after coming out of slee
Takashi asked me to send you this single patch as it conflicted with his
current tree and it is needed before 2.6.20 comes out to fix a userspace
ABI breakage that I caused earlier.
This patch fixes a bug with the sound core when CONFIG_SYSFS_DEPRECATED
is enabled. More details can be found in th
From: Takashi Iwai <[EMAIL PROTECTED]>
The recent change for a new sysfs tree with card* object breaks the
/sys/class/sound tree if CONFIG_SYSFS_DEPRECATED is enabled.
The device in each entry doesn't point the correct device object:
/sys/class/sound
...
|-- pcmC0D0c
| |-- dev
| |--
On Mon, 2007-01-29 at 23:50 +0100, Frédéric Riss wrote:
> > That's probably a userspace problem. Are you using DHCP ?
>
> Yep DHCP. Is that a known issue? I never had to reconfigure with older
> kernels.
Is dhclient running after resume ? What's the output of ifconfig (before
you do ifdown/up) ?
On Mon, 29 Jan 2007, Stephen Hemminger wrote:
>
> MSI works fine for almost all systems (except AMD systems where
> MSI is broken for ALL devices).
Why do you ignore reality?
MSI does *not* work fine, exactly because the firmware screws it up.
The fact that on a "hardware level" it may work i
Benjamin Herrenschmidt writes:
> > I'd hate to hit a different Hypervisor that did something close but
> > not quite the same and have the code fail then. So definitely
> > avoiding touching pci config space at all in the calls seems to make a
> > lot of sense. This includes avoiding pci_find_ca
On Mon, Jan 29, 2007 at 11:31:08PM +0300, Tomasz Kvarsin wrote:
> I try to compile and got:
>
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CHK include/linux/compile.h
> CC kernel/rcupreempt.o
> kernel/rcupreempt.c: In function 'rcupreempt_try_flip_state_nam
Hi,
On Monday, 29 January 2007 22:21, Nigel Cunningham wrote:
> Hi.
>
> On Mon, 2007-01-29 at 22:04 +0100, Oliver Neukum wrote:
> > Am Montag, 29. Januar 2007 21:14 schrieb Nigel Cunningham:
> > > Hi.
> > >
> > > On Mon, 2007-01-29 at 12:34 +0100, Oliver Neukum wrote:
> > > > Am Montag, 29. Janu
On Mon, 29 Jan 2007 17:02:14 -0500
"Matthew Kirk" <[EMAIL PROTECTED]> wrote:
> Regarding the long fsyncs, here's a trace...
>
> I upgraded to a more recent kernel - 2.6.18.6 - and ran it on a workstation.
> This particular box has In this case the elevator is CFQ.
>
> This sample came from a sta
Sigh. /me wanted to be too clever and needs to order more brown
paperbags now.
The rework of the jiffy update code introduced a one off error, which
led to a one off accounting error for last_jiffy_update. This made
jiffies lag behind.
Noticed by Karsten Wiese (cpufreq_ondemand weirdness).
Signe
On 29/01/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
http://www.stardust.webpages.pl/ltg/files/tools/witcher/witcher.py
example series diff
http://www.stardust.webpages.pl/ltg/files/tools/witcher/witcher-series
(it's not perfect, but should work)
Now 'quilt fold' works fine.
Happy testin
Le lundi 29 janvier 2007 à 23:57 +0100, Thomas Gleixner a écrit :
> On Mon, 2007-01-29 at 23:50 +0100, Frédéric Riss wrote:
> > > That's probably a userspace problem. Are you using DHCP ?
> >
> > Yep DHCP. Is that a known issue? I never had to reconfigure with older
> > kernels.
>
> Is dhclient r
Michael Ellerman writes:
> You can read config space, but it's not clear to me if the HV is allowed
> to filter it and hide things. It's also possible that the device
It appears that the HV does not prevent us from reading or writing any
config space registers for functions that are assigned to u
On Tue, 2007-01-30 at 00:26 +0100, Frédéric Riss wrote:
> > Have you checked the syslog ?
> Yes of course. Nothing interesting.
Just got the same issue on one of my test boxen. Different network card
though. The interface comes up fine, but DNS is not working. ifdown/up
resolves it.
/me keeps an
On Mon, 29 Jan 2007, Russell King wrote:
> This sounds like it could help ARM where we have some weird DMA areas.
Some ARM platforms have no need for a ZONE_DMA. The code in mm allows you
to not compile ZONE_DMA support into these kernels.
> What will help even more is if the block layer can al
> It's possible that the device can do MSI(X), but that using MSI(X)
> requires other platform resources (e.g. interrupt source numbers) and
> there are none free. I believe the platform guarantees a minimum
> number of MSI(X) interrupts per function, but a pci_enable_msix() call
> may not be abl
commmit 44ade178249fe53d055fd92113eaa271e06acddd breaks sane
MSI/ACPI/BIOS combinations. It's impossible to keep broken and sane
MSI/ACPI/BIOSes happy at the same time.
Revert the patch and disable MSI for sky2 when CONFIG_PM is enabled.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
diff --
On Mon, Jan 29, 2007 at 01:31:09AM +, Oleg Verych wrote:
>
> > From: Rainer Weikusat
> > Newsgroups: gmane.linux.kernel
> > Subject: Re: unfixed regression in 2.6.20-rc6 (since 2.6.19)
> > Date: Sun, 28 Jan 2007 14:34:56 +0100
>
> Hallo.
>
> > Greg KH <[EMAIL PROTECTED]> writes:
> []
> >> Pl
On Mon, 29 Jan 2007 15:04:06 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 29 Jan 2007, Stephen Hemminger wrote:
> >
> > MSI works fine for almost all systems (except AMD systems where
> > MSI is broken for ALL devices).
>
> Why do you ignore reality?
>
> MSI does *not*
Hello,
some months ago I sent to the MIPS and ARM mail lists a patch to unify
the several APM emulation codes adding a new dedicated directory so it
can be used to put there the per board specific code avoiding code
duplications (see files ./arch/arm/kernel/apm.c,
./arch/mips/kernel/apm.c and ./ar
Hello,
attached a patch to add support for Taos TSL2550 ambient light sensors
(http://www.taosinc.com/product_detail.asp?cateid=4&proid=18).
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Emb
On Tue, 2007-01-30 at 00:07 +0100, Rodolfo Giometti wrote:
> Now I try on this list in order to have some advice if this could be a
> good idea and what about if I add a new class "apm_emu" on the sysfs
> support with proper registrations functions.
I'm not sure this is a good idea. As you're crea
On Mon, Jan 29, 2007 at 11:53:46PM +, Richard Purdie wrote:
> I'm not sure this is a good idea. As you're creating a new interface,
> why not create something new/improved without the problems that
> confining yourself to APM emulation brings?
Because several applications (and expecially in e
Jan Engelhardt wrote:
or if I'm supposed to use a startup script instead.
This is the preffered way nowadays. One day, hopefully,
CONFIG_IP_PNP can go away.
It could be done reasonably easy, you know... :-/
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
Hi!
>>The /proc/bus/input/devices has an extensible structure. You can just
>>add an "A:" line (for Activity) instead of adding a new proc file.
>>
>> I know, but IMO there is too much stuff to parse in there. Activity
> counters
>> are frequently accessed by daemons,
On Monday 29 January 2007 18:00, Andrea Arcangeli wrote:
> On Sun, Jan 28, 2007 at 06:03:08PM +0100, Denis Vlasenko wrote:
> > I still don't see much difference between O_SYNC and O_DIRECT write
> > semantic.
>
> O_DIRECT is about avoiding the copy_user between cache and userland,
> when working w
On Mon, 29 Jan 2007 15:37:29 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> With a alloc_pages_range() one would be able to specify upper and lower
> boundaries.
Is there a proposal anywhere regarding how this would be implemented?
-
To unsubscribe from this list: send the line "unsu
On Mon, 29 Jan 2007, Stephen Hemminger wrote:
>
> Why do you insist on maintaining the wrong initialization order
> on resume? When I raised the issue, Len brought up that the resume
> order did not match spec, but then there has been slow progress
> in fixing it (it's buried in -mm tree).
It's
On Mon, 29 Jan 2007 16:12:27 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 29 Jan 2007, Stephen Hemminger wrote:
> >
> > Why do you insist on maintaining the wrong initialization order
> > on resume? When I raised the issue, Len brought up that the resume
> > order did not
When I modify a source file or two that belong to a particular
module, and then rebuild just that module with "make
dir1/dir/module.ko" (e.g.), the build system spends a couple of
minutes grinding away on "MODPOST" operations. Am I doing
something wrong? Is there a way to avoid this? It slows do
the checking_wrmsrl() macro in asm-x86_64/msr.h which is exported to userspace
utilizes the u32 type instead of __u32 ... trivial attached patch fixes that
-mike
pgpmUxTVCW5jn.pgp
Description: PGP signature
Use __u32 rather than u32 in checking_wrmsrl() exported to userspace.
Signed-off-by: Mik
H. Peter Anvin wrote:
Jan Engelhardt wrote:
or if I'm supposed to use a startup script instead.
This is the preffered way nowadays. One day, hopefully,
CONFIG_IP_PNP can go away.
It could be done reasonably easy, you know... :-/
If CONFIG_IP_PNP is going to go away, what is the proposed
On Mon, 29 Jan 2007, Stephen Hemminger wrote:
>
> On one and only one platform. It works fine on others. Don't blame the
> driver, stop it in PCI.
How sure are you that it's only those Sony laptops?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Chris Friesen wrote:
H. Peter Anvin wrote:
Jan Engelhardt wrote:
or if I'm supposed to use a startup script instead.
This is the preffered way nowadays. One day, hopefully,
CONFIG_IP_PNP can go away.
It could be done reasonably easy, you know... :-/
If CONFIG_IP_PNP is going to go away,
On Mon, 29 Jan 2007 16:25:48 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 29 Jan 2007, Stephen Hemminger wrote:
> >
> > On one and only one platform. It works fine on others. Don't blame the
> > driver, stop it in PCI.
>
> How sure are you that it's only those Sony lapto
useful for distros (and people with too much time on their hands) that support
a ton of architectures, headers_check_all is to headers_check as
headers_install_all is to headers_install
-mike
pgpFN4HRbqfFT.pgp
Description: PGP signature
Add new headers_check_all target for checking all arches i
On Tue, Jan 30, 2007 at 12:07:56AM +0100, Rodolfo Giometti wrote:
> some months ago I sent to the MIPS and ARM mail lists a patch to unify
> the several APM emulation codes adding a new dedicated directory so it
> can be used to put there the per board specific code avoiding code
> duplications (se
This patch contains the following cleanups:
- make needlessly global code static
- remove pointless fastcall annotations
- don't mark functions in C files as inline
- #if 0 the following unused function:
- arch/i386/kernel/vmitime.c: read_stolen_cycles()
Signed-off-by: Adrian Bunk <[EMAIL PROTEC
On Sat, Jan 27, 2007 at 11:49:28PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc4-mm1:
>...
> git-dvb.patch
>...
> git trees.
>...
This patch removes the unused struct radionorms.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.20-rc6-mm1/drivers/media/video/cx88/cx88
On Sat, Jan 27, 2007 at 11:49:28PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc4-mm1:
>...
> git-hid.patch
>...
> git trees.
>...
This patch contains the following CONFIG_INPUT_DEBUG improvements:
- remove Makefile code for the nonexisting CONFIG_INPUT_DEBUG
- simpler Makefile for
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 13 Jan 2007
fs/ecryptfs/crypto.c | 24
fs/ecryptfs/ecryptfs_kernel.h | 18 --
fs/ecryptfs/messaging.c
On Sat, Jan 27, 2007 at 11:49:28PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc4-mm1:
>...
> git-dvb.patch
>...
> git trees.
>...
v4l_printk_ioctl_arg() is no longer used.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/video/v4l2-common.c |7 ++-
inclu
On Sat, Jan 27, 2007 at 11:49:28PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc4-mm1:
>...
> git-ipwireless_cs.patch
>...
> git trees.
>...
This patch contains the following possible cleanups:
- proper prototypes for global functions in header files
- make the following needlessly
Hugh Dickins wrote:
On Mon, 29 Jan 2007, Nick Piggin wrote:
Moving page_cache_release(old_page) to below the next statement
will fix that problem.
Yes. I'm reluctant to steal your credit, but also reluctant to go
back and forth too much over this: please insert your Signed-off-by
_before_
Hi,
Evgenity, le Mon 29 Jan 2007 16:47:36 +0100, a écrit :
> Userspace M-on-N threading model is based on the idea, that when signal
> is delivered, kernel saves all information related to previous context
> in stack, so it is possible to find it and replace.
You may want to have a look at some e
On Mon, 29 Jan 2007, David Rientjes wrote:
> On Mon, 29 Jan 2007, Andi Kleen wrote:
>
> > On Thursday 25 January 2007 22:37, David Rientjes wrote:
> > > Any leftover memory is allocated
> > > to a final node unless the command-line ends with a comma.
> >
> > That sounds like syntactical vinegar
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap() is deadlockable in situations where a
large number of threads are trying to take two kmaps at the same ti
I have since found out that SMP kernels should(must?) have Enhanced RTC
support built-in.
It is stated in kernel config help for Enhanced RTC support, and I found
a number of references on the net as well.
Now I wonder why selecting SMP does not set Enhanced RTC support to "Y"
automaticall
On Mon, 29 Jan 2007 17:31:20 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
> Peter Zijlstra wrote:
> > On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
> >
> >> As Christoph says, it's very much preferred that code be migrated over to
> >> kmap_atomic(). Partly because kmap() is dead
Andrew Morton wrote:
On Mon, 29 Jan 2007 17:31:20 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap() i
On Tue, Jan 30, 2007 at 12:14:24PM +1100, Nick Piggin wrote:
> This is another discussion, but do we want the page locked here? Or
> are the filesystems happy to exclude truncate themselves?
No page lock please. Generally, Ocfs2 wants to order cluster locks outside
of page locks. Also, the sparse
Ingo Molnar wrote:
For every 64-bit Fedora box there's more than seven 32-bit boxes. I
think 32-bit is going to live with us far longer than many thought, so
we might as well make it work better. Both HIGHMEM and HIGHPTE is the
default on many distro kernels, which pushes the kmap infrastructu
201 - 300 of 400 matches
Mail list logo
