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
On Tue, 30 Jan 2007 01:31:33 +0100
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-01-29 at 16:21 -0800, Stephen Hemminger wrote:
> > > > The Sony VAIO BIOS resets to INTx on resume. This happens
> > > > after device resume, so device irq's get misrouted.
> > >
> > > Err? My Sony VAIO
On Mon, 2007-01-29 at 16:21 -0800, Stephen Hemminger wrote:
> > > The Sony VAIO BIOS resets to INTx on resume. This happens
> > > after device resume, so device irq's get misrouted.
> >
> > Err? My Sony VAIO does _NOT_ do that. It works fine without that.
> > It's just the sky2 hackery which
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
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
On Tue, 2007-01-30 at 01:22 +0100, Thomas Gleixner wrote:
> On Mon, 2007-01-29 at 15:50 -0800, Stephen Hemminger wrote:
> > The Sony VAIO BIOS resets to INTx on resume. This happens
> > after device resume, so device irq's get misrouted.
>
> Err? My Sony VAIO does _NOT_ do that. It works fine
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
On Tue, 30 Jan 2007 01:22:54 +0100
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-01-29 at 15:50 -0800, Stephen Hemminger wrote:
> > The Sony VAIO BIOS resets to INTx on resume. This happens
> > after device resume, so device irq's get misrouted.
>
> Err? My Sony VAIO does _NOT_ 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:
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
On Mon, 2007-01-29 at 15:50 -0800, Stephen Hemminger wrote:
> The Sony VAIO BIOS resets to INTx on resume. This happens
> after device resume, so device irq's get misrouted.
Err? My Sony VAIO does _NOT_ do that. It works fine without that.
It's just the sky2 hackery which fucked up things.
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
On Mon, 2007-01-29 at 15:47 -0800, Andrew Morton wrote:
> What we don't want to happen is for those disks to spin down during a
> reboot.
> It seems that this is OK with this patch.
>
> Also, we probably don't want them to be spun down during a kexec_load,
> but
> I expect that's OK too.
On Sat, Jan 27, 2007 at 02:04:43AM -0500, Len Brown wrote:
> From: John Keller <[EMAIL PROTECTED]>
>
> Support for dynamic loading and unloading of ACPI SSDT tables upon slot
> hotplugs and unplugs.
>
> On SN platforms, we now represent every populated root bus slot with a single
> ACPI SSDT
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).
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
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
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,
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
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
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
Andrew Morton wrote:
triviata:
--- linux-2.6.20-rc6nv/drivers/scsi/sd.c2007-01-28 17:00:00.0
-0600
+++ linux-2.6.20-rc6nvedit/drivers/scsi/sd.c2007-01-28 18:08:53.0
-0600
@@ -821,6 +821,39 @@ static int sd_sync_cache(struct scsi_dev
return res;
}
Hello,
attached a patch to add support for Taos TSL2550 ambient light sensors
(http://www.taosinc.com/product_detail.asp?cateid=4=18).
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded
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
The Sony VAIO BIOS resets to INTx on resume. This happens
after device resume, so device irq's get misrouted.
This hack turns off MSI on this laptop, until power management
initialization order is fixed.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/pci/quirks.c | 32
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*
On Sun, 28 Jan 2007 19:47:27 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> Here's a patch for sd.c I've cooked up which issues a START STOP UNIT
> command to stop the drive when the SCSI disk is removed or the machine
> is powered down. The rationale behind this is that apparently on many
>
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:
> []
> >>
> 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
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 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
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
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
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
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).
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
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.
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
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
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
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) ?
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
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
|
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
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
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, 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,
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
>
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
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
>
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 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,
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
> > >
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
Paweł Sikora wrote:
> On Thursday 25 of January 2007 05:50:45 Len Brown wrote:
>
>> On Wednesday 24 January 2007 17:52, Adrian Bunk wrote:
>>
>>> On Wed, Jan 24, 2007 at 11:46:44PM +0100, Paweł Sikora wrote:
>>>
for 2.6.20rc5 i get an acpi related oops during x86-64 boot:
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,
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
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
i'd like to rename the members in the _xt_align struct in
netfilter/x_tables.h ... by not using 'u8', 'u16', etc..., it's possible to
filter headers meant for userspace through the preprocessor and pull out
people who accidentally utilize these internal types ... however, by using
struct
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
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).
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
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
===
---
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
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
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
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
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
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
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 Mon, 29 Jan 2007, Andrew Morton wrote:
> On Mon, 29 Jan 2007 12:41:33 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > +#ifdef CONFIG_ZONE_DMA
> > if (CONFIG_ZONE_DMA_FLAG)
>
> We don't need the `if (CONFIG_ZONE_DMA_FLAG)' any more, do we?
Correct.
-
To
On Mon, 29 Jan 2007 21:10:30 +0100
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-01-29 at 11:31 -0800, Stephen Hemminger wrote:
> > Does this fix it?
>
> Don't know.
Sorry it was against the last patch I sent to Jeff for netdev.
Here is against 2.6.20-rc6
---
drivers/net/sky2.c |
Le 29.01.2007 09:12, Andrew Morton a écrit :
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-rc6-mm2/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm2/
- Dropped git-block due to CFQ breakage
Nice, reiser4
Hi,
On Mon, Jan 22, 2007 at 12:45:19PM +0800, Wang Zhenyu wrote:
> I've post a patch which trys to resolve pci config restore issue, see
> http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G machine,
> that my X can come back to live after s3, but I wasn't aware of the issues
>
On Sat, 2007-01-27 at 18:17 -0800, Andrew Morton wrote:
> On Tue, 23 Jan 2007 22:00:55 -
> Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > This is a full replacement queue for the high resolution timer / dynamic
> > ticks implemementation in -mm.
>
> The Vaio broke again. Seems to hang
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. Januar 2007 12:24 schrieb Nigel Cunningham:
> > > > Hi.
> > > >
> > > > On Mon,
On Mon, Jan 29, 2007 at 12:04:59PM -0800, Mark Fasheh wrote:
> Hi Linus,
> I made a silly error in my last upstream push. This patch makes
> ocfs2 build again.
Ok, never mind - I just noticed that you directly applied my patch on
Friday. Thanks!
--Mark
--
Mark Fasheh
Senior
On 1/29/07, Patrick Ale <[EMAIL PROTECTED]> wrote:
A lot of crap. And i am a fruitcake, nutter, headcase.
*sigh* sorry for wasting your time, I found my problem.
Since I thought libata worked like my old ata drivers and 2.6.19 was
booting well, I reconfigured my kernel source and changed
On 01/29, Christoph Lameter wrote:
>
> Here is the patch against 2.6.20-rc6-mm2. CPU_DOWN_PREPARE and
> CPU_DOWN_FAILED somehow vanished in mm?
No, no, there are still in place, so I believe your patch is good.
Now we have 2 additional events, CPU_LOCK_ACQUIRE/CPU_LOCK_RELEASE,
so
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. Januar 2007 12:24 schrieb Nigel Cunningham:
> > > Hi.
> > >
> > > On Mon, 2007-01-29 at 12:06 +0100, Oliver Neukum wrote:
> > > > Hi,
> > > >
> > > >
On 1/29/07, Patrick Ale <[EMAIL PROTECTED]> wrote:
Okay so, I unplugged the keyboard the moment I selected a kernel to boot.
The last thing i see on my screen, regarding SCSI is:
scsi 0:0:0:0: Direct-Access ATA WDC WD2000JB-00G 08.0 PQ: 0 ANSI: 5
scsi 1:0:0:0 CD-ROM
On Mon, 29 Jan 2007 12:41:33 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> +#ifdef CONFIG_ZONE_DMA
> if (CONFIG_ZONE_DMA_FLAG)
We don't need the `if (CONFIG_ZONE_DMA_FLAG)' any more, do we?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Okay so, I unplugged the keyboard the moment I selected a kernel to boot.
The last thing i see on my screen, regarding SCSI is:
scsi 0:0:0:0: Direct-Access ATA WDC WD2000JB-00G 08.0 PQ: 0 ANSI: 5
scsi 1:0:0:0 CD-ROM AOPEN DUW1608/ARR A060 PW: 0 ANSI: 5
then
On Jan 29 2007 12:36, Kevin Nicoll wrote:
>
> My question is if it is intended to be able to use more than one "ip="
> parameter in the kernel command line,
Possibly not ...
> or if I'm supposed to use a startup script instead.
This is the preffered way nowadays. One day, hopefully,
I also hit the same issue. Here is the patch:
Fix slab build failure if !CONFIG_ZONE_DMA
I also needed this to get 2.6.20-rc6-mm2 to build. Fixes the fix by the
complainer about the fixes. #ifdef cannot be avoided since cs_dmacachep
is no longer defined.
Signed-off-by: Christoph Lameter
On Mon, 29 Jan 2007, Hugh Dickins wrote:
> On Mon, 29 Jan 2007, Nick Piggin wrote:
> > After do_wp_page calls page_mkwrite on its target (old_page), it then drops
> > the reference to the page before locking the ptl and verifying that the pte
> > points to old_page.
> >
> > Unfortunately,
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 +-
>
Josh Boyer wrote:
> On 1/29/07, 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?
>
> Are you including distros that use it as well?
>
Yes, if they're based on Adrian's stable series.
-
To
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
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
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
- 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
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
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
On 1/29/07, 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?
Are you including distros that use it as well?
josh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
> You can read config space, but it's not clear to me if the HV is allowed
> to filter it and hide things.
I've seen it do it for example with EADS bridges. I haven't seen doing
it with devices (other than hiding entire functions) but I wouldn't
exclude it...
> It's also possible that the
Is there any way to estimate the size of the user base for 2.6.16?
e.g. how many downloads does it get?
-
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
101 - 200 of 800 matches
Mail list logo
