On Tue, 23 Jan 2007 22:48:15 -0500
"Kristian Høgsberg" <[EMAIL PROTECTED]> wrote:
> I've moved the new FireWire stack to an in-tree git repository and
> moved over the missing patches from my out-of-tree version.
arm:
drivers/firewire/fw-device.c: In function `fw_device_init':
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 table containing info for every device and PPB attached to the slot.
These
From: John Keller <[EMAIL PROTECTED]>
Add SN platform support for running with an ACPI
capable PROM that defines PCI devices in SSDT
tables. There is a SSDT table for every occupied
slot on a root bus, containing info for every
PPB and/or device on the bus. The SSDTs will be
dynamically
Replace the apparent typo CONFIG_ACPI_DEBUG_OUTPUT with
the non-Kconfig conditional ACPI_DEBUG_OUTPUT, which is what every
other file uses.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 698a154..d65142a 100644
---
Syntax only -- no functional changes.
Signed-off-by: Len Brown <[EMAIL PROTECTED]
---
arch/ia64/sn/kernel/io_common.c | 10 ++
arch/ia64/sn/kernel/iomv.c |5 ++---
include/asm-ia64/sn/acpi.h | 18 ++
3 files changed, 26 insertions(+), 7 deletions(-)
On Friday 26 January 2007 20:10, Andrew Morton wrote:
> On Wed, 15 Nov 2006 09:24:54 -0600
> John Keller <[EMAIL PROTECTED]> wrote:
>
> > Add SN platform support for running with an ACPI
> > capable PROM that defines PCI devices in SSDT
> > tables. There is a SSDT table for every occupied
> >
27-01-2007, H. Peter Anvin:
> Just for everyone's information...
>
> The git performance issues (especially) on kernel.org has been very
> frustrating, obviously. We're putting a dedicated git server in place
> hopefully the week of February 5.
Thanks.
Hope it will have fast git-web face
Hallo.
On Sat, Jan 27, 2007 at 01:18:30AM +0100, Tim Schmielau wrote:
> On Fri, 26 Jan 2007, Oleg Verych wrote:
>
> > In Debian's version it has no `bc', while native `bc' is producing
> > crap like that:
> > ,-*- bash -*-
> > |[EMAIL PROTECTED]:~$ printf "%u" $(( -1 )) ; echo
> >
Is there a convention regarding the information that a wireless MAC layer
should provide when
reporting scan data from an AP with a hidden SSID?
In ieee80211, the software inserts the string "" for such an AP, which
seems to give
wpa_supplicant fits because it rejects the SSID before even
The bulk of this patch is largely paranoia-based changes, that turn off
various PATA-related bits.
The SATA portion of this patch is verified working... if I disable
CONFIG_PCI_MSI and CONFIG_PCI_MMCONFIG. If those are not disabled, then
my ICH9 test box dies in an interrupt storm. Booting
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 27 Jan 2007 12:01:46 +1100
> In fact, the shaper device doesn't even seem to take a ref count of
> the device it has attached to. So that device can go away at any time.
> What's more, there are drivers that can change hard_header at run-time
>
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 27 Jan 2007 11:45:05 +1100
> David Miller <[EMAIL PROTECTED]> wrote:
> >
> > Shaper is actually OK. None of these hardware header callbacks
> > should be invoked if the device is down. Yet, this is what is
> > accidently being allowed in the
On Friday 26 January 2007 5:19 pm, Matthew Garrett wrote:
> On Fri, Jan 26, 2007 at 04:42:56PM -0800, David Brownell wrote:
> > On Friday 26 January 2007 3:15 pm, Matthew Garrett wrote:
> > > It's certainly the case that fixing those drivers would result in a
> > > better long-term situation -
> > > It's certainly the case that fixing those drivers would result in a
> > > better long-term situation - however, nobody currently seems to have any
> > > interest in doing so...
> >
> > And the way these things work, unfortunately, is that merging your patch
> > would ensure nobody ever
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
hfc_usb.c | 40
hfc_usb.h |3 ---
2 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/drivers/isdn/hisax/hfc_usb.c
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
capifunc.c |4
di.c | 16 +-
message.c | 360 ++---
os_pri.c |4
platform.h |8 -
5 files changed, 192
On Fri, Jan 26, 2007 at 12:54:02PM -0500, Justin Piszcz wrote:
> When I disconnect my UPS from the wall, I have to wait 15-30 seconds
> before the USB drier 'polls' this information and tells me that the UPS is
> on battery power (via knutclient or syslog via nut):
>
> [EMAIL PROTECTED] POWER
On Fri, Jan 26, 2007 at 12:42:26PM -0800, Greg KH wrote:
> No, it's not stable material, as drivers would have to be modified to
> support it, and that is adding new stuff. See my other comment about
> why this was changed because it was broken...
Which drivers? The current code simply bails if
On Fri, Jan 26, 2007 at 04:42:56PM -0800, David Brownell wrote:
> On Friday 26 January 2007 3:15 pm, Matthew Garrett wrote:
> > It's certainly the case that fixing those drivers would result in a
> > better long-term situation - however, nobody currently seems to have any
> > interest in doing
Just for everyone's information...
The git performance issues (especially) on kernel.org has been very
frustrating, obviously. We're putting a dedicated git server in place
hopefully the week of February 5.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe
On Wed, 15 Nov 2006 09:24:54 -0600
John Keller <[EMAIL PROTECTED]> wrote:
> Add SN platform support for running with an ACPI
> capable PROM that defines PCI devices in SSDT
> tables. There is a SSDT table for every occupied
> slot on a root bus, containing info for every
> PPB and/or device on
On Sat, Jan 27, 2007 at 11:45:05AM +1100, Herbert Xu wrote:
> David Miller <[EMAIL PROTECTED]> wrote:
> >
> > Shaper is actually OK. None of these hardware header callbacks
> > should be invoked if the device is down. Yet, this is what is
> > accidently being allowed in the AF_PACKET socket
On Fri, 26 Jan 2007 16:42:56 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Friday 26 January 2007 3:15 pm, Matthew Garrett wrote:
> > On Fri, Jan 26, 2007 at 01:56:41PM -0800, David Brownell wrote:
> >
> > > I thought the resolution was that fixing a few of those drivers
> > > should
David Miller <[EMAIL PROTECTED]> wrote:
>
> Shaper is actually OK. None of these hardware header callbacks
> should be invoked if the device is down. Yet, this is what is
> accidently being allowed in the AF_PACKET socket layer.
Hmm, what if the device goes down after the check?
Cheers,
--
On Friday 26 January 2007 8:49 am, Pierre Ossman wrote:
> Hans-Peter Nilsson wrote:
> >
> > Future improvements:
> > A rewrite. Not only for the new MMC framework (I haven't looked
> > at it so I don't know what's involved) but also because this
> > code seems a little too, um, experimental to
On Friday 26 January 2007 7:21 am, Hans-Peter Nilsson wrote:
> > From: David Brownell <[EMAIL PROTECTED]>
> > Just so we don't lose count here: this is the *third* example of
> > an SPI protocol tweaking option that seems to be needed just to
> > support an MMC-over-SPI stack:
> >
> > -
On Friday 26 January 2007 3:15 pm, Matthew Garrett wrote:
> On Fri, Jan 26, 2007 at 01:56:41PM -0800, David Brownell wrote:
>
> > I thought the resolution was that fixing a few of those drivers
> > should solve the problem Matthew needed resolved, and that in
> > the meanwhile "rmmod drivername"
On Friday 26 January 2007 6:31 am, Hans-Peter Nilsson wrote:
> > From: David Brownell <[EMAIL PROTECTED]>
> > Date: Thu, 25 Jan 2007 04:59:37 -0800
>
> > So to summarize ... you now have MMC-over-SPI working on CRIS
> > hardware, with these patches?
>
> Yes. FWIW, we'll ship with our ETRAX FS
On Friday 26 January 2007 2:46 am, Hans-Peter Nilsson wrote:
> > From: David Brownell <[EMAIL PROTECTED]>
> > Date: Thu, 25 Jan 2007 05:02:56 -0800
>
> > On Wednesday 24 January 2007 8:52 pm, Hans-Peter Nilsson wrote:
> > > (Please CC me on replies, I'm not subscribed to LKML or the SPI list.
>
Andrew Morton napisał(a):
> On Sat, 27 Jan 2007 00:23:47 +0100
> "Michal Piotrowski" <[EMAIL PROTECTED]> wrote:
>
>> On 26/01/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
>>> [EMAIL PROTECTED] napisał(a):
The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to
Signed-off-by: Peter Eriksen <[EMAIL PROTECTED]>
---
There are only a few places using the conditional operator in the
meaning of the absolute value, and this is is one such place.
Compile tested only.
sound/isa/gus/gus_main.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
On Sat, 27 Jan 2007 00:23:47 +0100
"Michal Piotrowski" <[EMAIL PROTECTED]> wrote:
> On 26/01/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] napisał(a):
> > > The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to
> > >
> > >
> > >
On 1/17/07, Hans-Peter Jansen <[EMAIL PROTECTED]> wrote:
Am Montag, 15. Januar 2007 15:53 schrieb Vaidyanathan Srinivasan:
>
> 33Mhz 32-bit PCI bus on typical PC can do around 100MB/sec...
Substract roughly n * 5MB for VIA chipsets, where n is the age (1 <= n <=
4), and even more for SIS, ATI..
On 26/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz
It almost work :)
I'm getting a lot of
BUG: sleeping function called
Sergei Shtylyov wrote:
> Hello.
>
> Marc St-Jean wrote:
>
> >> > Index: linux_2_6/drivers/serial/8250.c
> >> > ===
> >> > RCS file: linux_2_6/drivers/serial/8250.c,v
> >> > retrieving revision 1.1.1.7
> >> > diff -u -r1.1.1.7
On Fri, 26 Jan 2007, Oleg Verych wrote:
> In Debian's version it has no `bc', while native `bc' is producing
> crap like that:
> ,-*- bash -*-
> |[EMAIL PROTECTED]:~$ printf "%u" $(( -1 )) ; echo
> |18446744073709551615
> |[EMAIL PROTECTED]:~$ echo -1 | bc
> |-1
> |[EMAIL PROTECTED]:~$ printf
>
> The OwnerId field within a namespace node is 8 bits, and this is the
> main constraint on the maximum OwnerId. You can't simply bump up the
> number of owner ids without changing this field.
Isn't this accomplished with the mod to aclocal.h below - i.e.
by making a acpi_owner_id a u16
On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
> >> Phillip Susi wrote:
> >>> Denis Vlasenko wrote:
> You mean "You can use aio_write" ?
> >>> Exactly. You generally don't use O_DIRECT without aio.
On Friday 26 January 2007 21:41, Andrew Morton wrote:
> I'm somewhat surprised that this wasn't done earlier. I wonder if there's
> some subtle reason why this won't work. How well tested is this?
http://www.opengroup.org/onlinepubs/95399/functions/utimes.html
lists a slight difference
The OwnerId field within a namespace node is 8 bits, and this is the
main constraint on the maximum OwnerId. You can't simply bump up the
number of owner ids without changing this field.
If we need more than 255 owner Ids, the width of this field will have to
be increased, or we will need to use
On Friday 26 January 2007 18:05, Phillip Susi wrote:
> Denis Vlasenko wrote:
> > Which shouldn't be true. There is no fundamental reason why
> > ordinary writes should be slower than O_DIRECT.
>
> Again, there IS a reason: O_DIRECT eliminates the cpu overhead of the
> kernel-user copy,
You
> Long term it may make sense for us to give ourselves plenty of
> planning slop of more like 24 months, so if one location doesn't work
> out we have time to work out another one.
That looks way too conservative. If kernel summit had 500+ attendees, I
can see why you'd need a such long lead
On Fri, Jan 26, 2007 at 01:56:41PM -0800, David Brownell wrote:
> I thought the resolution was that fixing a few of those drivers
> should solve the problem Matthew needed resolved, and that in
> the meanwhile "rmmod drivername" should suffice. There also seemed
> to be agreement that power
(Please respond via reply-to-all, not via the bugzilla web interface)
On Fri, 26 Jan 2007 14:40:09 -0800
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=7891
>
>Summary: vdso page is no longer mapped for a.out binaries in
> kernel 2.6.18
>
Pieter Palmers wrote:
> cc'ing linux1394-devel because it seems to be a problem in the ieee1394
> stack.
Yes, this bug is in stock Linux 2.6 too. Ever has been.
http://bugzilla.kernel.org/show_bug.cgi?id=7121
--
Stefan Richter
-=-=-=== ---= ==-=-
http://arcgraph.de/sr/
-
To unsubscribe from
Auke Kok wrote:
Hi,
I've established a regression in the MSI vector/irq allocation routine for both
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for
serveral minutes which allocates msi vectors and frees them. These tests have
been running fine until 2.6.19.
On 1/26/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
Less trivial (and I wonder whether you've come to this from an ia64
or a powerpc direction): I notice that ia64 has more stringent REGION
checks in its ia64_do_page_fault, before calling expand_stack or
expand_upwards. So on that path, the
90% resend from yesterday. Added a few more fixes.
If you pulled the previous submission, that's ok, git history will still
be correct (it's appended, not rebased).
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
To support systems with large IO configurations,
this patch increases the number of available ACPI
owner ids to 1023.
On SN platforms, we represent every populated root
bus slot with an ACPI SSDT table containing info
for every device and PPB attached to the slot.
Each SSDT requires a unique ACPI
This patch makes all the changes suggested by Christopher, with the
exception of the suggestion to use the sched_flags field versus a new
member to the spu_context struct to signal the need to "notify already
active". I don't have the sched_flags change in my 2.6.20-rc1 tree. I
can send
Hi,
I've established a regression in the MSI vector/irq allocation routine for both
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for
serveral minutes which allocates msi vectors and frees them. These tests have
been running fine until 2.6.19.
git-bisecting I've
On Fri, Jan 26, 2007 at 01:56:41PM -0800, David Brownell wrote:
> > Or am I misstating that long thread? David, your thoughts?
>
> My recollection of that thread was that *NOBODY* claimed that a
> replacement of that (broken-by-design) mechanism would ever exist.
>
> However, there was some
ALSA + GCC 4.1.1 + -Os is known to be a bad combination on some
arches; see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363 . (I
tripped over it on an ARM target, but my limited understanding of GCC
internals does not allow me to conclude that it is ARM-specific.) A
patch claiming to fix the
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>While working with the latest bonding code I noticed a nasty problem
>that will prevent arp monitoring from always functioning correctly on
>x86_64 systems. Comparing ints to longs and expecting reliable results
>on x86_64 is a bad idea. With this
On 1/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
Ok, I'll do it through my trees, but I'll wait for Monty to finish
building and testing.
/me hands Monty a copy of distcc and ccache :)
More like a disk that isn't strangely crippled.
(This kernel isn't getting anywhere near the studly machines
for more details see PR 7889 at kernel bugzilla.
-
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/
On Friday 26 January 2007 12:41 pm, Greg KH wrote:
> On Thu, Jan 25, 2007 at 05:00:09AM +, Matthew Garrett wrote:
> > This patch allows the bus driver to check whether a specific driver
> > requires the split. If not, the 2.6.18 functionality is restored. It
> > also alters
Quoting Pierre Ossman <[EMAIL PROTECTED]>:
> Hi Petr,
Hello,
> I was hoping you could give me some input on another concern I have.
> Which of TCP and UDP is the preferred transport for NCP? The client for
> Windows seems to use TCP, which would suggest that that is the most
> tested dialect. I
Alan Cox wrote:
On Wed, Jan 24, 2007 at 01:47:45PM -0600, Scott Preece wrote:
Hmm - Sounds like it needs to go to Halifax! [I was going to suggest
Reykjavik, but was surprised to see it was in the same time zone as
the UK.]
Reykjavik is a fantastic place with some truely wonderful Linux
On Sat, 27 Jan 2007 02:30:17 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> > > As a consequence of keeping track of RCU readers, the readers
> > > have a slight overhead (optimizations in the paper).
> > > This implementation co-exists with the "classic" RCU
> > > implementations and can be
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386.
saa5246a.c| 10 +-
saa5246a.h|9 ++---
saa5249.c | 41 ++---
saa7134/saa7134-i2c.c | 24
I get the following Oops when ejecting a firewire cardbus controller.
The kernel is a 2.6.20-rc6 (git pull from a few hours ago), patched with
Ingo's -rt2 patch.
cc'ing linux1394-devel because it seems to be a problem in the ieee1394
stack.
Pieter
Jan 26 22:29:37 localhost kernel: pccard:
Mel Gorman wrote:
On Fri, 26 Jan 2007, Chris Friesen wrote:
We currently see this issue on our systems, as we have older e1000
hardware with 9KB jumbo frames. After a while we just fail to
allocate buffers and the system goes belly-up.
Can you describe a reliable way of triggering this
On Sat, 27 Jan 2007 02:14:06 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
> > On Sat, 27 Jan 2007 01:16:22 +0530
> > Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> > > > The plan is, I hope, to rip it all out and do
On Fri, 26 Jan 2007 12:10:00 -0800
Khai Doan <[EMAIL PROTECTED]> wrote:
> Sorry if this is the wrong list. I've search google, but have not found
> solution to my problem.
>
> I have a long running application which split out lots of debugging
> information. I can't redirect the output to a
On Fri, Jan 26, 2007 at 06:17:03PM +, Jose Goncalves wrote:
> Frederik Deweerdt wrote:
> > On Fri, Jan 26, 2007 at 03:50:25PM +, Jose Goncalves wrote:
> >
> >> I'm having a problem with the latest 2.6.16 kernel (I've found the
> >> problem on 2.6.16.37 and 2.6.16.38). I have a
Looking at drivers/base/core.c:dev_uevent() I wonder whenever
a device can have both bus-specific uevent function AND
class-specific one. If yes, the code in that routine is umm..
wrong. Because in this case, bus-specific attributes will
be owerwritten by class-specific ones.
I mean this code
Phillip Susi napsal(a):
Khai Doan wrote:
Sorry if this is the wrong list. I've search google, but have not
found solution to my problem.
I have a long running application which split out lots of debugging
information. I can't redirect the output to a regular file because
that file would
On Thu, 25 Jan 2007, Adam Litke wrote:
> When expanding the stack, we don't currently check if the VMA will cross into
> an area of the address space that is reserved for hugetlb pages. Subsequent
> faults on the expanded portion of such a VMA will confuse the low-level MMU
> code, resulting in
On Tue, Jan 23, 2007 at 04:32:59PM -0800, Andrew Morton wrote:
> On Tue, 16 Jan 2007 00:58:58 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
>
> > This patch implements a new version of RCU which allows its read-side
> > critical sections to be preempted.
>
> Why is it selectable if
26-01-2007:
> I am running 2.6.19.2 kernel from kernel.org.
2.6.18 debian, didn't see before, but maybe it was just big uptime ;)
> This is my first SMP kernel.
>
> The problem I describe below has not happend with non-SMP kernels ever...
>
> I have installed my new AMD64 x2 4800 CPU just a few
Come to think of it, you can just use "tail" as the application that
reads the FIFO.
-hpa
-
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
Khai Doan wrote:
Sorry if this is the wrong list. I've search google, but have not found
solution to my problem.
I have a long running application which split out lots of debugging
information. I can't redirect the output to a regular file because that
file would grow and eat up all the
Khai Doan wrote:
Sorry if this is the wrong list. I've search google, but have not found
solution to my problem.
I have a long running application which split out lots of debugging
information. I can't redirect the output to a regular file because that
file would grow and eat up all the
Andrew Morton wrote:
> OK, but I don't recall having seeing a demand for lutimes(). Opinions
> are sought?
It's an interface which has been available on other platforms forever
(lutimes, not lutimesat). If it can be implemented correctly on the
interesting file systems I'd say "go ahead", it
On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
> On Sat, 27 Jan 2007 01:16:22 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> > > The plan is, I hope, to rip it all out and do freeze_processes() on the
> > > hotplug side, so nobody else needs to worry about cpu hotplug any
On Fri, Jan 26, 2007 at 11:59:05AM -0800, Andrew Morton wrote:
> On Thu, 25 Jan 2007 05:00:09 +
> Matthew Garrett <[EMAIL PROTECTED]> wrote:
>
> > In 2.6.19, support for splitting driver suspend and resume callbacks
> > into interrupt and non-interrupt contexts was added. Unfortunately, this
On Fri, 26 Jan 2007, Chris Friesen wrote:
Mel Gorman wrote:
Worse, the problem is to have high order contiguous blocks free at the time
of allocation without reclaim or migration. If the allocations were not
atomic, anti-fragmentation as it is today would be enough.
Has anyone looked at
On Thu, Jan 25, 2007 at 05:00:09AM +, Matthew Garrett wrote:
> In 2.6.19, support for splitting driver suspend and resume callbacks
> into interrupt and non-interrupt contexts was added. Unfortunately, this
> broke /sys/device/.../power/state support for all devices. In the long
> run, this
On Sat, 27 Jan 2007 01:16:22 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> > The plan is, I hope, to rip it all out and do freeze_processes() on the
> > hotplug side, so nobody else needs to worry about cpu hotplug any more.
> > But at present everyone seems to be in hiding.
>
> This would
On Fri, 26 Jan 2007 14:21:42 +0300
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> Rewrite via do_utimes() like compat_sys_utime().
>
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
> ---
>
> fs/utimes.c | 50 +++---
> 1 file changed, 7
On Fri, 26 Jan 2007 14:23:45 +0300
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> lutimesat(2) does everything futimesat(2) does except it doesn't follow
> symlinks.
>
> It could be used by tar(1) and cp(1).
>
> FreeBSD and NetBSD have lutimes(2) which can be emulated by C library:
>
>
On Fri, 26 Jan 2007, Christoph Lameter wrote:
On Fri, 26 Jan 2007, Mel Gorman wrote:
The zone-based approach does nothing to help jumbo frame allocations. It only
helps hugepage allocations at runtime and potentially memory hot-remove.
Sounds like the max order based approach is better in
On Fri, 26 Jan 2007 11:58:18 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > If the only demonstrable benefit is a saving of a few k of text on a small
> > number of machines then things are looking very grim, IMO.
>
> The main benefit is a significant simplification of the VM,
Sorry if this is the wrong list. I've search google, but have not found
solution to my problem.
I have a long running application which split out lots of debugging
information. I can't redirect the output to a regular file because that
file would grow and eat up all the diskspace. I can't
On Fri, Jan 26, 2007 at 12:47:20PM -0500, Rob Landley wrote:
> On Thursday 25 January 2007 4:18 pm, Oleg Verych wrote:
>
> > > As I said, I'm not particularly interested in a more intrusive solution
> > > solving a problem I haven't actually seen. I don't see any obvious
> > > reason
> > >
On Thu, 25 Jan 2007 13:40:52 -0800
Adam Litke <[EMAIL PROTECTED]> wrote:
> When expanding the stack, we don't currently check if the VMA will cross into
> an area of the address space that is reserved for hugetlb pages. Subsequent
> faults on the expanded portion of such a VMA will confuse the
On Thu, 25 Jan 2007 05:00:09 +
Matthew Garrett <[EMAIL PROTECTED]> wrote:
> In 2.6.19, support for splitting driver suspend and resume callbacks
> into interrupt and non-interrupt contexts was added. Unfortunately, this
> broke /sys/device/.../power/state support for all devices. In the
On Fri, 26 Jan 2007, Andrew Morton wrote:
> As Mel points out, distros will ship with CONFIG_ZONE_DMA=y, so the number
> of machines which will actually benefit from this change is really small.
> And the benefit to those few machines will also, I suspect, be small.
>
> > > - We kicked around
Greg KH wrote:
On Thu, Jan 25, 2007 at 03:38:24PM -0800, Pete Zaitcev wrote:
On Thu, 25 Jan 2007 16:18:35 -0500, Kristian H??gsberg <[EMAIL PROTECTED]>
wrote:
I see that ORBs are always allocated with a call (like SKB) and not
embedded into drivers (like URBs). It's great, keep it up. Also,
On Fri, Jan 26, 2007 at 11:47:13AM -0800, Mark Fasheh wrote:
> On Fri, Jan 26, 2007 at 07:49:42PM +0100, Adrian Bunk wrote:
> > I don't know why gcc 3.3 generates this now since ocfs2_backup_super_blkno()
> > seems to be unused, but there is a bug for 32 bit systems that should be
> > fixed:
> >
On Sat, 27 Jan 2007 00:41:13 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 25, 2007 at 02:36:45AM +0530, Dipankar Sarma wrote:
> > On Wed, Jan 24, 2007 at 08:15:59AM -0800, Paul E. McKenney wrote:
> >
> > It should be relatively easy. Setting the offlined cpu's flags
> > to
On Fri, Jan 26, 2007 at 07:49:42PM +0100, Adrian Bunk wrote:
> I don't know why gcc 3.3 generates this now since ocfs2_backup_super_blkno()
> seems to be unused, but there is a bug for 32 bit systems that should be
> fixed:
>
> Commit 50af94b14c98f5769860a282a397c6f3b135c8a8 adds:
> offset /=
On Fri, 26 Jan 2007 14:33:36 -0500
"Matthew Kirk" <[EMAIL PROTECTED]> wrote:
> Sorry, this will show my ignorance... my system is lacking
> /proc/sysrq-trigger. I can find how to build a kernel with the magic sysrq
> key (CONFIG_MAGIC_SYSRQ=y), and have done so, but I still don't have
>
On Fri, Jan 26, 2007 at 11:28:37AM -0800, Andrew Morton wrote:
> On Sat, 27 Jan 2007 00:41:13 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
>
> > Is this a good example to
> > show why per-subsystem locks might be unmaintainable ?
>
> Maybe. It might also be a good example of confused
On Fri, 26 Jan 2007 07:56:09 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 26 Jan 2007, Andrew Morton wrote:
>
> > - They add zillions of ifdefs
>
> They just add a few for ZONE_DMA where we alreaday have similar ifdefs for
> ZONE_DMA32 and ZONE_HIGHMEM.
I refreshed my
[EMAIL PROTECTED] napisał(a):
> The mm snapshot broken-out-2007-01-26-00-36.tar.gz has been uploaded to
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-01-26-00-36.tar.gz
security/selinux/hooks.c: In function 'selinux_sysctl':
security/selinux/hooks.c:1440: error:
.config: http://www.msxnet.org/config-2.6.20-rc5
=
[ INFO: possible recursive locking detected ]
2.6.20-rc5 #1
-
swapper/0 is trying to acquire lock:
(>lock){++..}, at: [] __wake_up+0x18/0x43
but task is
On Wednesday 24 January 2007 12:37, Thomas Gleixner wrote:
> On Wed, 2007-01-24 at 03:00 +0100, Pavel Pisa wrote:
> > stays NULL after clock event registration. Interrupts
> > runs, but my code doesnot call any function. The notification
> > chain and clock events list seems to be filled
Sorry, this will show my ignorance... my system is lacking
/proc/sysrq-trigger. I can find how to build a kernel with the magic sysrq
key (CONFIG_MAGIC_SYSRQ=y), and have done so, but I still don't have
/proc/sysrq-* and cannot seem to find how to build in sysrq functionality
itself - assuming
1 - 100 of 678 matches
Mail list logo
