This patch
- adds proper __init decoration to swiotlb's init code (and the code calling
it, where not already the case)
- replaces uses of 'unsigned long' with dma_addr_t where appropriate
- does miscellaneous simplicfication and cleanup
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
Index:
This patch adds abstraction so that the file can be used by environments other
than IA64 and EM64T, namely for Xen.
Even if this patch is considered too convoluted, I would appreciate if the
other three ones could still be considered for merging.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
This patch adds missing exports to allow several drivers to be built as
module with CONFIG_IA64_HP_ZX1_SWIOTLB.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.20-rc3/arch/ia64/hp/common/hwsw_iommu.c 2006-11-29
22:57:37.0 +0100
+++
Same problem with 2.6.19-rc3.
Apologies for the long spiel, if memory serves me correct, gzip'd
attachments are verboten.
openSUSE 10.2
Network does not get configured with "acpi=noirq" or "acpi=off".
There may be something in dmesg that allows further analysis of the
problem.
(list address corrected, and a question added...)
On 1/2/2007 4:53 PM, I wrote:
> Kyuma Ohta wrote:
> ...
>> Now,I'm testing 2.6.20-rc3 for x86_64, submitted patch for this issue;
>> "Fault has happened in 'cleanuped' sbp2/1394 module in *not 32bit*
>> architecture hardwares ."
>>
>> As result
> > > > I can very easily believe it. The US patent system and "justice"
> > > > system in the US is completely and totally insane, and companies
> > > > often feel they have to act accordingly. Remember this is the
> > > > country that has issued multi-million dollar awards to people who
> > >
When building 2.6.20-rc2-mm1 with CHECK_HEADERS=y, the Makefile will
build the target "include/config/kernel.release" twice. The first time,
the CONFIG_LOCALVERSION [and any auto local version] will correctly be
appended. Then, when it builds the "headers_check" target, the Makefile
will build
From: Pekka Enberg <[EMAIL PROTECTED]>
Add a missing debug_check_no_locks_freed() debug check for kmem_cache_free().
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
mm/slab.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
Hello Ingo,
In the mean time I have tested more with this problem:
1. Once, the RTC clock gets stopped during shutdown, it is **NEVER**
going to run again.
And I continuously see the problems with grub and the BIOS
time-of-day. Finally I had to remove the battery from the motherboard
to reset
I'm seeing utterly random behaviour from kernels on ARM SMP hardware
built after 2.6.19. I won't bother trying to paste the kernel output;
sometimes the kernel locks solid (no IRQs, no output to say what's wrong).
Other times I get the first line of an oops repeating but with random
addresses.
On Tuesday, January 2, 2007 2:36 am, Alan wrote:
> On Mon, 1 Jan 2007 21:01:38 -0800
>
> Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > Using MMCONFIG for PCI config space access is simply an
> > optimization, not a requirement. Therefore, when it can't be used,
> > there's no need for
>
> Some
On Tue, Jan 02, 2007 at 04:39:23PM +, Russell King wrote:
> I'm seeing utterly random behaviour from kernels on ARM SMP hardware
> built after 2.6.19. I won't bother trying to paste the kernel output;
> sometimes the kernel locks solid (no IRQs, no output to say what's wrong).
> Other times I
On Tue, 02 Jan 2007 10:28:38 -0500 Andrew Barr wrote:
> On Tue, 2007-01-02 at 00:32 -0800, Greg KH wrote:
> > On Mon, Jan 01, 2007 at 03:56:25PM -0500, Andrew Barr wrote:
> > > I have a simple question perhaps someone can help me with here...
> > >
> > > I have one of those simple LED keyboard
Hi Pavel,
> On 2.6.20-rc2, I got:
>
> This used to work before... certainly with 2.6.19.
>
> Running this multiple times seems to trigger it:
>
> #!/bin/bash
> #
> # Run tui on desktop machine, using t68i instead of a modem.
> #
>
> hciconfig hci0 name billionton
> hciconfig hci0 up
> hcid
>
Mark Lord wrote:
> The code (written 10 years ago) isn't the best in the world,
> and will be redone entirely for hdparm-7.0 this year.
OT but care to make -i and -I work equivalently? Such that -i reports
more detailed info and user can dump stored id block. Support for
IDENTIFY PACKET DEVICE
On Tue, 2 Jan 2007, Russell King wrote:
>
> How do I tell git bisect "I can't test this, this is neither good nor bad,
> please choose another to try" ? Or is git bisect hopeless given the large
> amount of unbuildable commits thanks to our weekly merges?
The easiest way to do this is to start
On Tue, 2007-01-02 at 08:36 -0800, Randy Dunlap wrote:
> On Tue, 02 Jan 2007 10:28:38 -0500 Andrew Barr wrote:
>
> > On Tue, 2007-01-02 at 00:32 -0800, Greg KH wrote:
> > > On Mon, Jan 01, 2007 at 03:56:25PM -0500, Andrew Barr wrote:
> > > > I have a simple question perhaps someone can help me
* Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> Add a missing debug_check_no_locks_freed() debug check for
> kmem_cache_free().
hm, i have a similar fix in -rt already, and i sent a patch for this:
http://lkml.org/lkml/2006/12/18/104
have i missed
On Jan 2 2007 10:01, Mark Lord wrote:
> Jens Axboe wrote:
>>
>> > But surely one of (not sure which) sync+async or async+sync may also
>> > be okay?
>> > Or would it?
>>
>> Async merge to sync request should be ok. But I wonder what happens with
>> hdparm, since it seems to trigger one of these
On Tue, 2006-12-26 at 01:08 +0059, Jiri Slaby wrote:
> Hi!
>
> * tty_flip_buffer_push- terminal
> * @tty: tty to push
> *
> * Queue a push of the terminal flip buffers to the line discipline. This
> * function must not be called from IRQ context if
Steve Youngs <[EMAIL PROTECTED]> wrote:
>
>The last kernel from Linus' tree[1] that boots for me is v2.6.19. And
>before I take my first stab at git-bisect, I thought I'd ask here in
>case it's just a PEBCAK.
>
>What happens in kernels since v2.6.19 is:
>
> o Choose the kernel to boot from lilo
El Sábado, 16 de Diciembre de 2006 18:41, Jose Alberto Reguero escribió:
> I am trying to make work the driver pata_marvell of linux-2.6.20-rc1 with
> Marvell 88SE6121.
> I added the PCI ID: 0x6121
>
> { PCI_DEVICE(0x11AB, 0x6101), },
> { PCI_DEVICE(0x11AB, 0x6145), },
> {
On Jan 2 2007 16:15, David Weinehall wrote:
>On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
>> On Tue, 2 Jan 2007, Theodore Tso wrote:
>>
>> 1) mcdonald's was not merely serving their coffee "hot," but
>> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
>>
> it's been nothing but trouble in 32-bit mode.
> It still works fine when I boot it in 64-bit mode.
A shot in the dark at the spontaneous reset issue, but no clue on the 32 vs
64-bit observation...
See if ACPI exports any temperature readings under
/proc/acpi/thermal_zone/*/temperature
and
On Tue, Jan 02, 2007 at 10:33:32AM +, Alan Cox wrote:
> On Mon, 1 Jan 2007 23:37:43 -0500
> Theodore Tso <[EMAIL PROTECTED]> wrote:
> > > Is this patch a consistency thing?
> >
> > The goal of the patch was to avoid filling /var/log/messages huge
> > amounts of sysrq text. Some of the
On Sat, 30 Dec 2006 22:50:41 -0600
Larry Finger <[EMAIL PROTECTED]> wrote:
> Tobin Davis wrote:
> > Which alsa patch was this? I'm not seeing anything in the hg logs for
> > this. Or is this something from the kernel side?
>
> It seems to have come from suse. The full commit message is:
>
>
Tejun Heo wrote:
OT but care to make -i and -I work equivalently? Such that -i reports
more detailed info and user can dump stored id block.
hdparm -I works just fine now.
hdparm -i requires the HDIO_GET_IDENTITY ioctl() from drivers/ide,
to retrieve the "boot time" copy of the identify
Mark Lord wrote:
> Tejun Heo wrote:
>>
>> OT but care to make -i and -I work equivalently? Such that -i reports
>> more detailed info and user can dump stored id block.
>
> hdparm -I works just fine now.
No objection there.
> hdparm -i requires the HDIO_GET_IDENTITY ioctl() from drivers/ide,
>
On Tue, Jan 02, 2007 at 10:33:32AM +, Alan wrote:
> On Mon, 1 Jan 2007 23:37:43 -0500
> Theodore Tso <[EMAIL PROTECTED]> wrote:
> > > Is this patch a consistency thing?
> >
> > The goal of the patch was to avoid filling /var/log/messages huge
> > amounts of sysrq text. Some of the sysrq
On Tue, Jan 02, 2007 at 12:25:57PM -0500, Len Brown wrote:
> > it's been nothing but trouble in 32-bit mode.
> > It still works fine when I boot it in 64-bit mode.
>
> A shot in the dark at the spontaneous reset issue, but no clue on the 32 vs
> 64-bit observation...
>
> See if ACPI exports
Being able to compile both SELinux and SLIM into the kernel was done
intentionally. The kernel parameters 'selinux' and 'slim' can enable
or disable the LSM module at boot. Perhaps, for the time being, the
SECURITY_SLIM_BOOTPARAM_VALUE should default to 0.
Mimi
-
To unsubscribe from this list:
Ingo Molnar wrote:
>
> (could you send me the whole trace if you still have it? It would be
> interesting to see a broader snippet from the life of individual java
> threads.)
>
> Ingo
Sure, I'll send it to you separately due to the size of the complete
trace.
Tim
-
To unsubscribe from
Tejun Heo wrote:
Mark Lord wrote:
Support for IDENTIFY PACKET DEVICE would be nice too.
It already does that, using HDIO_DRIVE_CMD to retrieve it
in the same way as for regular IDENTIFY DEVICE commands.
Hmmm... My hdparm doesn't seem to do that.
Sure it does.
Try "strace hdparm -I
On Tue, Jan 02, 2007 at 01:03:54PM -0500, Theodore Tso wrote:
> or perhaps better, making the sysrq-m information
> available via either /proc or /sys?
or debugfs ?
Dave
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe
I wonder if it wouldn't be better to make this change as part of a
larger change that moves towards an explicit iovec container struct
rather than bare 'struct iov *' and 'nr_segs' arguments.
I suspect it should be rather trivial to get this started. As a first
step we simply add a
struct
At least the Keyspan USA-19HS USB-to-serial converter supports
two different configurations, one where the input endpoints
have interrupt transfer type and one where they are bulk endpoints.
The default UHCI configuration uses the interrupt input endpoints.
The keyspan driver, OTOH, assumes that
Zach Brown wrote on Tuesday, January 02, 2007 10:22 AM
> >> I wonder if it wouldn't be better to make this change as part of a
> >> larger change that moves towards an explicit iovec container struct
> >> rather than bare 'struct iov *' and 'nr_segs' arguments.
>
> > I suspect it should be rather
Any comments on the attached patch would be appreciated. Thank you.
-Maynard
---
Maynard Johnson wrote:
The attached patch extends OProfile's Cell support (committed into
2.6.20-rc1), adding the capability to do time-based profiling of the SPUs.
This is a
> with tty->low_latency set, but it doesn't AFAICS. One possibility for
> deadlock is if the tty->buf.lock spinlock is taken on behalf of a user
> process...
The case to watch out for is
flip_buffer_push -> ldisc -> driver write of echo/^S/^Q
if you call flip_buffer_push while holding
On Monday 01 January 2007 09:56, Thomas Meyer wrote:
> I know this topic was already on the list. But 2.6.20-rc3 still gives me
> tons of these messages in the log buffer:
>
> "ACPI: EC: evaluating _Q10
> ACPI: EC: evaluating _Q10
> ACPI: EC: evaluating _Q10
> ACPI: EC: evaluating _Q10
> ACPI:
Ollie Wild <[EMAIL PROTECTED]> wrote:
> - I haven't tested this on a NOMMU architecture. Could someone please
> validate this?
There are a number of potential problems with NOMMU:
(1) The argument data is copied twice (once into kernel memory and once out
of kernel memory).
(2) The
On Mon, 1 Jan 2007, Andrey Borzenkov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wednesday 15 November 2006 00:28, Alan Stern wrote:
> > This patch (as822) prevents the OHCI autostop mechanism from kicking in
> > if the root hub is not able or not allowed to issue wakeup
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> FYI, i have forward ported your MAX_ARG_PAGES limit removal patch to
> 2.6.20-rc2 and have included it in the -rt kernel. It's working great -
> i can now finally do a "ls -t patches/*.patch" in my patch repository -
> something i havent been able to do
Paul Fulghum wrote:
With low_latency == 1, flush_to_ldisc() is deferred
until the ISR is complete and the internal spinlock is released.
Oops, I meant low_latency == 0 of course.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Tuesday 02 January 2007 13:04, Ken Moffat wrote:
> On Tue, Jan 02, 2007 at 12:25:57PM -0500, Len Brown wrote:
> > > it's been nothing but trouble in 32-bit mode.
> > > It still works fine when I boot it in 64-bit mode.
> >
> > A shot in the dark at the spontaneous reset issue, but no clue on
David Weinehall <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
>> 1) mcdonald's was not merely serving their coffee "hot," but
>> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
>> will produce third-degree burns almost
On Tue, 2007-01-02 at 11:17 -0600, Hollis Blanchard wrote:
> On Tue, 2006-12-26 at 01:08 +0059, Jiri Slaby wrote:
> > * Queue a push of the terminal flip buffers to the line discipline.
> > This
> > * function must not be called from IRQ context if tty->low_latency is
> > set.
> >
>
On Tue, 2007-01-02 at 13:05 -0500, Mimi Zohar wrote:
> Being able to compile both SELinux and SLIM into the kernel was done
> intentionally. The kernel parameters 'selinux' and 'slim' can enable
> or disable the LSM module at boot. Perhaps, for the time being, the
> SECURITY_SLIM_BOOTPARAM_VALUE
On Tue, 2007-01-02 at 08:22 -0500, Robert P. J. Day wrote:
> On Tue, 2 Jan 2007, Theodore Tso wrote:
>
> > I can very easily believe it. The US patent system and "justice"
> > system in the US is completely and totally insane, and companies
> > often feel they have to act accordingly. Remember
Hello,
Litte rework to supress this warning:
arch/powerpc/platforms/powermac/pic.c: In function 'pmacpic_find_viaint':
arch/powerpc/platforms/powermac/pic.c:625: warning: label 'not_found' defined
but not used
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
Hi Tejun,
Tejun Heo wrote:
>
> Please do the following and post the result.
>
> # strace mplayer -v dvd:// > out 2>&1
>
See attachment. I was lucky: On the first run with strace
mplayer could play the DVD (still using Tron). But this was
not reproducible.
Both strace files are attached. Hope
Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
[...]
> I don't know about others but I wouldn't write an offer with a fixed
> price for "look into assembler dumps, reverse engineer it and find an
> infringement on a list of given patents" so the patent holder has to
> list the patents and the
This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19
with patches available.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any
On Tue, Jan 02 2007, Adrian Bunk wrote:
> Subject: CFQ disk throughput halved
> References : http://lkml.org/lkml/2007/01/1/104
> Submitter : Rene Herman <[EMAIL PROTECTED]>
> Mark Lord <[EMAIL PROTECTED]>
> Caused-By : Jens Axboe <[EMAIL PROTECTED]>
> commit
On Tue, 2 Jan 2007, David Weinehall wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> > 1) mcdonald's was not merely serving their coffee "hot," but
> > *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> > will produce third-degree burns almost
On Tue, Jan 02, 2007 at 08:26:52PM +0100, Jens Axboe wrote:
> On Tue, Jan 02 2007, Adrian Bunk wrote:
> > Subject: CFQ disk throughput halved
> > References : http://lkml.org/lkml/2007/01/1/104
> > Submitter : Rene Herman <[EMAIL PROTECTED]>
> > Mark Lord <[EMAIL PROTECTED]>
> >
On Tue, Jan 02, 2007 at 01:42:32PM -0500, Len Brown wrote:
>
> You might remove and re-insert the DIMMS.
> Sometimes there are poor contacts if the DIMMS are not fully seated and
> clicked in.
>
> The real mystery is the 32 vs 64-bit thing.
> Are the devices configured the same way -- ie are
On Tue, 2007-01-02 at 18:38 +, Alan wrote:
> > with tty->low_latency set, but it doesn't AFAICS. One possibility
> for
> > deadlock is if the tty->buf.lock spinlock is taken on behalf of a
> user
> > process...
>
> The case to watch out for is
>
> flip_buffer_push -> ldisc -> driver
Hi
This is just a general question to understand where the improvement
can be made.
In the first setup, I have these processes:
- mencoder recording from bttv chip at 8 fps (cpu 3.5 %)
- mplayer playing from bttv chip at 10 fps (cpu 2.1 %)
In the second setup, I have these processes:
-
On Mon, 2007-01-01 at 17:27 +0100, Roman Zippel wrote:
> On Wednesday 20 December 2006 02:32, john stultz wrote:
>
> > > I know and all you have to change in the ntp and some related code is to
> > > replace HZ there with a variable, thus make it changable, so you can
> > > increase the update
* Chuck Ebbert ([EMAIL PROTECTED]) wrote:
> It's not in the queue for 2.6.19.2, though.
Should be there shortly, thanks.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Mon, 2007-01-01 at 19:29 +0100, Roman Zippel wrote:
> On Wednesday 20 December 2006 02:54, john stultz wrote:
>
> > And here would be the follow on patch (again *untested*) for
> > CONFIG_NO_HZ slowing the time accumulation down to once per second.
>
> Changing it to one creates a potential
On Sun, 2006-12-31 at 11:45 -0800, Daniel Walker wrote:
> On Sun, 2006-12-31 at 23:04 +0800, Fengguang Wu wrote:
> > Hi,
> >
> > The following messages keeps popping up when CONFIG_PROFILE_LIKELY=y:
> >
> > init[1]: segfault at 8118c110 rip 8118c110 rsp
> > 7fff9a9d14d8 error
On Tue, 02 Jan 2007 20:30:17 +0100, Geert Uytterhoeven said:
> > > 2) there had, for a decade prior, been some *700* cases where people
> > > had burned themselves with mcdonald's coffee, so it's not as if
> > > mcdonald's was unaware of the danger, yet continued to ignore it.
>
> Given the
Zachary Amsden wrote:
Rusty Russell wrote:
Rene Herman wrote:
Hmm, by the way, if romsignature() needs this
probe_kernel_address() thing, why doesn't romchecksum()?
I assume it's all in the same page, but CC'ing Zach is easier than
reading the code 8)
Some hypervisors don't emulate
On Tue, Jan 02, 2007 at 07:44:24PM +0100, Bodo Eggert wrote:
> David Weinehall <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
>
> >> 1) mcdonald's was not merely serving their coffee "hot," but
> >> *scalding* hot (180 to 190 degrees Fahrenheit),
> The recommendet _serving_ temperature for coffe is 55 °C or below.
Nonsense! 55C (100F) is ludicrously low for coffee.
70C (125F) is the *minimum* recommended serving temperature. 165-190F is the
preferred serving range. I can cite source after source for this. For
example:
On 1/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Tue, 02 Jan 2007 20:30:17 +0100, Geert Uytterhoeven said:
> > > 2) there had, for a decade prior, been some *700* cases where people
> > > had burned themselves with mcdonald's coffee, so it's not as if
> > > mcdonald's was unaware of
On Tue, Jan 02, 2007 at 06:13:46PM +0100, Jan Engelhardt wrote:
>
> On Jan 2 2007 16:15, David Weinehall wrote:
> >On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> >> On Tue, 2 Jan 2007, Theodore Tso wrote:
> >>
> >> 1) mcdonald's was not merely serving their coffee "hot," but
On Tue, 2 Jan 2007 15:47:06 +0200 (EET)
Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> I have been unable to find a NUMA-capable tester for this patch,
Any x86_64 box can be used to test NUMA code via the numa=fake=N boot option.
fake-numa is somewhat sick in mainline and you might find that it
Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> Add a missing debug_check_no_locks_freed() debug check for
> kmem_cache_free().
On 1/2/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
hm, i have a similar fix in -rt already, and i sent a patch for this:
http://lkml.org/lkml/2006/12/18/104
have i
On Tue, 2 Jan 2007, Pekka J Enberg wrote:
> +
> + if (nodeid == -1 || nodeid == numa_node_id()) {
> + if (unlikely(current->flags & (PF_SPREAD_SLAB | PF_MEMPOLICY)))
{
> + obj = alternate_node_alloc(cache, flags);
> + if (obj)
> +
Adrian Bunk wrote:
On Tue, Jan 02, 2007 at 08:26:52PM +0100, Jens Axboe wrote:
Patch is already merged in -git.
Thanks for this information, I missed this (as well as the merged SATA
fix) since it isn't yet at the git mirrors.
What's "-git" here? I just now pulled
On Tue, Jan 02 2007, Rene Herman wrote:
> Adrian Bunk wrote:
>
> >On Tue, Jan 02, 2007 at 08:26:52PM +0100, Jens Axboe wrote:
>
> >>Patch is already merged in -git.
> >
> >Thanks for this information, I missed this (as well as the merged SATA
> >fix) since it isn't yet at the git mirrors.
>
>
Apologies for the long spiel, if memory serves me correct, gzip'd
attachments are verboten.
openSUSE 10.2
Network does not get configured with "acpi=noirq" or "acpi=off".
There may be something in dmesg that allows further analysis of the
problem.
00:0a:e4:4e:a1:42 is the laptop MAC address.
On Tue, Jan 02, 2007 at 12:41:59AM +0100, Berthold Cogel wrote:
> Adrian Bunk schrieb:
> > On Tue, Dec 26, 2006 at 01:15:38AM +0100, Berthold Cogel wrote:
> >
> >> Hello!
> >
> > Hi Berthold!
> >
> >> 'shutdown -h now' doesn't work for my system (Acer Extensa 3002 WLMi)
> >> with
Hi!
> > >> It seems like the posix idea of unique doesn't
> > >> hold water for modern file systems
> > >
> > > are you really sure?
> >
> > Well Jan's example was of Coda that uses 128-bit internal file ids.
> >
> > > and if so, why don't we fix *THAT* instead
> >
> > Hmm, sometimes you
On 1/1/07, Russell King <[EMAIL PROTECTED]> wrote:
On Mon, Jan 01, 2007 at 11:15:04PM +0100, Miklos Szeredi wrote:
> > > > I'm willing to do that - and I guess this means we can probably do this
> > > > instead of walking the list of VMAs for the shared mapping, thereby
> > > > hitting both
On Tuesday 02 January 2007 10:41, Sid Boyce wrote:
> Same problem with 2.6.19-rc3.
Do you mean 2.6.20-rc3 still does not work?
What was the last kernel that worked properly with no cmdline parameters?
> Apologies for the long spiel, if memory serves me correct, gzip'd
> attachments are
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> There's a glaring bug in selinux_netlbl_inode_permission() - taking
> lock_sock() inside rcu_read_lock().
Note that the bug is still in -rc3, and is easily triggerable via a
default FC6 bootup. It's fixed by the (slightly modified) patch from
Len Brown schrieb:
The bigger question is why you get "tons of these" --
as EC events are usually infrequent.
Do you have a big number next to "acpi" in /proc/interrupts?
If so, at what rate is it growing?
thanks,
-Len
maybe tons were a bit to overstated... After a fresh reboot, i count 110
> > > >> It seems like the posix idea of unique doesn't
> > > >> hold water for modern file systems
> > > >
> > > > are you really sure?
> > >
> > > Well Jan's example was of Coda that uses 128-bit internal file ids.
> > >
> > > > and if so, why don't we fix *THAT* instead
> > >
> > > Hmm,
On Tue, 2 Jan 2007, Miklos Szeredi wrote:
It seems like the posix idea of unique doesn't
hold water for modern file systems
are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix
On Tue, 2007-01-02 at 11:46 -0800, john stultz wrote:
> On Mon, 2007-01-01 at 19:29 +0100, Roman Zippel wrote:
> > On Wednesday 20 December 2006 02:54, john stultz wrote:
> >
> > > And here would be the follow on patch (again *untested*) for
> > > CONFIG_NO_HZ slowing the time accumulation down
Alan wrote:
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it didn't work in the case of one
This is a resubmission of the earlier patch with the pidhash bits
dropped.
At the moment the inode/dentry cache hash tables (common by way of
alloc_large_system_hash()) are incorrectly sized by their respective
detection logic when we attempt to use large base pages on systems
with little memory.
On Fri, 29 Dec 2006 03:32:02 -0800
Amit Choudhary <[EMAIL PROTECTED]> wrote:
> Description: Fix error-path leak in function jffs2_scan_medium(), in file
> fs/jffs2/scan.c
>
> Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
>
> diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
> index
Unlike x86, x86_64 already passes arguments in registers. The use of
regparm attribute makes no difference in produced code, and the use of
fastcall just bloats the code.
--
Glauber de Oliveira Costa
Red Hat Inc.
"Free as in Freedom"
diff -rup
On Sun, Dec 31, 2006 at 04:55:51PM +, Alistair John Strachan wrote:
> On Sunday 31 December 2006 16:27, Adrian Bunk wrote:
> > On Sat, Dec 30, 2006 at 04:59:35PM +, Alistair John Strachan wrote:
> > > On Thursday 28 December 2006 04:14, Alistair John Strachan wrote:
> > > > On Thursday 28
On Tue, 2006-12-26 at 13:37 -0500, jamal wrote:
>On Tue, 2006-26-12 at 18:56 +0100, Ingo Molnar wrote:
>
>
> > + xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
> > + AUDIT_MAC_IPSEC_DELSPD, delete, xp, NULL);
> > +
> > if (!delete) {
> > struct
On Sun, Dec 31, 2006 at 04:48:43PM +, Alistair John Strachan wrote:
> On Sunday 31 December 2006 16:28, Adrian Bunk wrote:
> > On Sat, Dec 30, 2006 at 06:29:15PM +, Alistair John Strachan wrote:
> > > On Saturday 30 December 2006 17:21, Chuck Ebbert wrote:
> > > > In-Reply-To: <[EMAIL
> > This is a silly complaint because the SFF layer in libata doesn't handle
> > this case yet anyway.
>
> Yes, it's "silly" people people use configurations you find inconvenient.
>
> At least one embedded x86 case cares, that I know of. They only needed
> to make two minor changes to make it
> I/O errors could go unnoticed when syncing, for example the following code
> could
> write a file bigger than 10Mib on a 10Mib filesystem. With this patch, msync()
> will report the error originally encountered by sync(). Tuning the number of
> sync may be needed to reproduce the bug.
>
Alan wrote:
This is a silly complaint because the SFF layer in libata doesn't handle
this case yet anyway.
Yes, it's "silly" people people use configurations you find inconvenient.
At least one embedded x86 case cares, that I know of. They only needed
to make two minor changes to make it
Jeff Garzik wrote:
* After your patch, the code explicitly calls pci_request_region() for
BARs 0-4, but never for BAR5.
Without checking for failures, I might add.
Let's call that regression/obvious bug #4, because the previous code
actually CARED if the resource was reserved.
The 32bit and 64bit PARISC Linux kernels suffers from the problem, that the
gettimeofday() call sometimes returns non-monotonic times.
The easiest way to fix this, is to drop the PARISC-specific implementation and
switch over to the generic TIME_INTERPOLATION framework.
But in order to make it
Quoting Mimi Zohar ([EMAIL PROTECTED]):
> Being able to compile both SELinux and SLIM into the kernel was done
> intentionally.
Intentionally so that you can switch back and forth for testing?
> The kernel parameters 'selinux' and 'slim' can enable
> or disable the LSM module at boot. Perhaps,
On Tue, Jan 02, 2007 at 10:33:25PM +0100, Helge Deller wrote:
> Ok, not Ok ?
Um, this is still doing cmpxchg() with insufficient locking. So, not
OK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Mon, Dec 25, 2006 at 01:08:31AM -0700, Grant Grundler wrote:
> On Mon, Dec 25, 2006 at 01:06:35AM -0700, Grant Grundler wrote:
> > On Sat, Dec 23, 2006 at 11:07:26PM -0700, Grant Grundler wrote:
> > > "final" patch v7 and commit log entry appended below. :)
> >
> > v8 adds 2cd round of
Oops ;-) resending, as I forgot to sign last version:
Unlike x86, x86_64 already passes arguments in registers. The use of
regparm attribute makes no difference in produced code, and the use of
fastcall just bloats the code.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
--
501 - 600 of 772 matches
Mail list logo
