Jarek Poplawski wrote:
On Sat, Dec 30, 2006 at 02:21:15AM +, Sid Boyce wrote:
Jarek Poplawski wrote:
On 28-12-2006 04:23, Sid Boyce wrote:
I first saw the problem on the 64x2 box after upgrading to 2.6.19. The
network appeared OK with ifconfig and route -n, but I had no network
access. Pin
Jens Axboe wrote:
I did have to massage the second patch to get it to apply cleanly
after the first patch. You may want to regenerate it against -rc3.
Hmm odd, I thought I did. Will double check.
Ahh.. I get it now.
I tried to apply the second patch *on top* of the first patch,
whereas it
On Tue, Jan 02 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >
> >>I did have to massage the second patch to get it to apply cleanly
> >>after the first patch. You may want to regenerate it against -rc3.
> >
> >Hmm odd, I thought I did. Will double check.
>
> Ahh.. I get it now.
>
> I tried to ap
On Tue, 2 Jan 2007, Oliver Neukum wrote:
> Am Dienstag, 2. Januar 2007 16:26 schrieb Alan Stern:
> > On Tue, 2 Jan 2007, Oliver Neukum wrote:
> >
> > > Hi,
> > >
> > > if a driver returns an error in fill_read_buffer(), the buffer will be
> > > marked as filled. Subsequent reads will return eof.
Am Dienstag, 2. Januar 2007 16:47 schrieb Alan Stern:
> On Tue, 2 Jan 2007, Oliver Neukum wrote:
>
> > Am Dienstag, 2. Januar 2007 16:26 schrieb Alan Stern:
> > > On Tue, 2 Jan 2007, Oliver Neukum wrote:
> > >
> > > > Hi,
> > > >
> > > > if a driver returns an error in fill_read_buffer(), the bu
On Mon, 1 Jan 2007, Alan wrote:
>
> If you revert the commit you end with all the PCI resource tree breakage
> back
Which weren't a regression or anything new.
Alan: regressions are what we don't do. Ever. If your second patch is
found to have some other problems, we revert them both. It's th
On Tue, Jan 02, 2007 at 11:58:34AM +, 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.
Thanks,
I can confirm that with t
From: Pekka Enberg <[EMAIL PROTECTED]>
The PageSlab debug check in kfree_debugcheck() is broken for compound
pages. It is also redundant as we already do BUG_ON for non-slab pages in
page_get_cache() and page_get_slab() which are always called before we
free any actual objects.
Signed-off-by:
* Remy Bohmer <[EMAIL PROTECTED]> wrote:
> Hello Ingo,
>
> I have discovered 3 problems that are likely all related to the same
> root-cause, likely to be caused by the RT-kernel.
> I use the 2.6.19-rt15 kernel, with the configuration attached to this mail.
> It is running on a standard x86, i94
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)
> +
When the old IDE layer calls into methods in the driver during error
handling it is essentially random whether ide_lock is already held. This
causes a deadlock in the atiixp driver which also uses ide_lock internally
for locking.
Switch to a private lock instead.
Signed-off-by: Alan Cox <[EMAIL
* Segher Boessenkool <[EMAIL PROTECTED]> [070102 12:37]:
> Are you really suggesting that using a kernel copy of the
> device tree is the correct thing to do, and the only correct
> thing to do -- with the sole argument that "that's what the
> current ports do"?
There might also be a speed advanta
This patch fixes
- marking I-cache clean of pages DMAed to now only done for IA64
- broken multiple inclusion in include/asm-x86_64/swiotlb.h
- missing phys-to-virt translation in swiotlb_sync_sg()
- missing call to mark_clean in swiotlb_sync_sg()
- a (perhaps only theoretical) issue in swiotlb_dma
Convert all phys_to_virt/virt_to_phys uses to bus_to_virt/virt_to_bus, as
is what is meant and what is needed in (at least) some virtualized
environments like Xen.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Index: 2.6.20-rc3-swiotlb-bugs/lib/swiot
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: 2.6
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]>
In
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
+++ 2.6.20-rc3-ia64-zx1-swiotlb/arch/ia64/hp/
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.
00:0a:e4:4e:a1:4
(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 o
> > > > 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 th
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: 2.6/mm/slab.c
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 the
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. Ot
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 hardw
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 la
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
> r
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 w
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 wit
* 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 so
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 tty->low_laten
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), },
> { P
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
>> wil
> 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 if
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 s
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:
>
> co
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 bloc
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 comma
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 any
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: s
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 th
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 /dev/sr0
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 linux-kernel"
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 iod
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 th
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 prelimina
> 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 yo
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: EC
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 perm
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 reque
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" i
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 t
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 immediately
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 t
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]>
arch/powerpc/platforms
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 amoun
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 oth
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 719d340
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 immediate
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]>
> > C
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 the
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 w
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:
- mencoder
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 int
* 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 http://vger.kernel.org/maj
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 pr
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 1
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 popul
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 the
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), a
> 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:
http://www.bunn.com
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 th
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 do
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 miss
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
git://git2.kernel.org/
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.
>
> W
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.
00
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 linux-2.6.20-rc
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 can
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 anony
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 verboten.
* 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
Parag
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, so
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 to
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 cha
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.
101 - 200 of 386 matches
Mail list logo
