On 07-01-08 23:27, Bodo Eggert wrote:
On Mon, 7 Jan 2008, H. Peter Anvin wrote:
There might have been a few 386/20's clocking the ISA bus at ÷3 (6.67
MHz) rather than ÷2 (10 MHz) or ÷2.5 (8 MHz).
Yes, and the remaining users should set the kernel option. Both of them.
The question is: Ho
On Mon, 07 Jan 2008 14:37:17 MST, Matthew Wilcox said:
> If you can reproduce a bug reliably, you can reproduce it without the
> nvidia module loaded.
Theoretically, at least. Sometimes, in the real world, other constraints
enter into it...
You're welcome to stop by and figure out why (I've sunk
On Mon, Jan 07, 2008 at 02:13:52PM -0800, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
>>> +
>>> +#define LARGE_PAGE_SIZE(_AC(1,UL) << PMD_SHIFT)
>>> +#define LARGE_PAGE_MASK(~(LARGE_PAGE_SIZE-1))
>>> +
>>> +#define HPAGE_SHIFTPMD_SHIFT
>>> +#define HPAGE_S
Today I upgraded my kernel from 2.6.23.9 to 2.6.23.12 and in the past
30 minutes I have had to restart my computer twice.
I believe its a kernel oops or a kernel panic because when the
computer freezes it blinks the caps and scroll lock LEDs.
I don't know what is causing the problem but I am willin
On Mon, Jan 07, 2008 at 06:04:25PM -0500, [EMAIL PROTECTED] wrote:
> Theoretically, at least. Sometimes, in the real world, other constraints
> enter into it...
So you're saying that you can't find reliable ways to reproduce problems
on demand? Those are some of the lower quality bug reports, so
On Jan 6, 2008 2:11 PM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> On Sunday, 6 of January 2008, Parag Warudkar wrote:
> > On Jan 6, 2008 7:57 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > > On Sunday, 6 of January 2008, Ingo Molnar wrote:
> > > >
> > > > * Rafael J. Wysocki <[EMAIL PR
On Sun, 6 Jan 2008 14:56:01 +0100
J__rn Engel <[EMAIL PROTECTED]> wrote:
> - * Copyright (C) 2004-2006 Jörn Engel <[EMAIL PROTECTED]>
> + * Copyright (C) 2004-2006 Joern Engel <[EMAIL PROTECTED]>
Yup. Your name comes out like that when sylpheed does its
save-email-to-a-file thing as well an
Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and
PIT? Does anyone care about just sticking in a udelay(2) (or 1) there as
a replacement and call it a day?
PIT is problematic because the PIT may be necessary for udelay setup.
-hpa
--
To unsubs
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> David - will you look into this?
Do you have a config?
David
--
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
Pleas
> But overclocking is not the problem for udelay, it would err to the safe
> side. The problem would be a BUS having < 8 MHz, and since the days of
> 80286, they are hard to find. IMO having an option to set the bus speed
> for those systems should be enough.
If you get it wrong you risk data co
On Mon, 7 Jan 2008 21:44:26 +0100
Marcin Slusarz <[EMAIL PROTECTED]> wrote:
> > There's some overly long lines here and some odd style, this should look
> > more like:
> These long lines were split later in "[PATCH 1/7] udf: fix coding style"
Confused. How can patch 1/n come "later" than this on
On 08-01-08 00:24, H. Peter Anvin wrote:
Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and
PIT? Does anyone care about just sticking in a udelay(2) (or 1) there
as a replacement and call it a day?
PIT is problematic because the PIT may be necessary f
On Sun, 06 Jan 2008 14:46:14 +0100
Philipp Zabel <[EMAIL PROTECTED]> wrote:
> The DS1WM driver incorrectly infers the IAS bit (1-wire interrupt active
> high) from IRQ settings. There are devices that have IAS=0 but still need
> the IRQ to trigger on a rising edge. With this patch, machines with D
Hi All,
Please CC me on responses.
I am working on a SD/MMC Host driver .
I am getting kerenl oops after mmc_register_card () is called.
i working on LINUX 2.6.22.1 kerenl.
What might be the reason for this.
I installed the modules in follwing order. I did nothing else after
installing the mo
On Mon, 7 Jan 2008 17:15:01 -0600
"Stoyan Gaydarov" <[EMAIL PROTECTED]> wrote:
> Today I upgraded my kernel from 2.6.23.9 to 2.6.23.12 and in the past
> 30 minutes I have had to restart my computer twice.
> I believe its a kernel oops or a kernel panic because when the
> computer freezes it blinks
Jesse Barnes wrote:
On Monday, January 07, 2008 2:47 Andi Kleen wrote:
This patch
commit c5182babd1d0706f1294af7b8dbf64e378b066bb
Author: Robert Hancock <[EMAIL PROTECTED]>
Date: Sat Jan 5 13:26:32 2008 +0100
x86: validate against ACPI motherboard resources
...
recently added to git-x8
> I don't see in the code where you implement the "size > PAGE_SIZE"
> condition. But I only just got back from holidays .. :)
Indeed ... a "quilt ref" was missing :-(
New patch coming ...
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
powerpc: Workaround for iommu page alignment
Our iommu page size is currently always 4K. That means with our current
code, drivers may do a dma_map_sg() of a 64K page and obtain a dma_addr_t
that is only 4K aligned.
This works fine in most cases except some infiniband HW it seems, where
they tell
On 08/01/2008, Stoyan Gaydarov <[EMAIL PROTECTED]> wrote:
> Today I upgraded my kernel from 2.6.23.9 to 2.6.23.12 and in the past
> 30 minutes I have had to restart my computer twice.
> I believe its a kernel oops or a kernel panic because when the
> computer freezes it blinks the caps and scroll l
On Mon, 07 Jan 2008 15:25:36 +0200
Boaz Harrosh <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 07 2008 at 8:53 +0200, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > On Sun, 23 Dec 2007 13:09:05 +0200
> > Boaz Harrosh <[EMAIL PROTECTED]> wrote:
> >
> >> On Fri, Dec 21 2007 at 4:30 +0200, Benjamin Herren
On Sat, 5 Jan 2008 16:16:55 -0600
David Fries <[EMAIL PROTECTED]> wrote:
> The kernel has a divide by zero crash when trying to run the system
> timer less than 100Hz. The problem is x/(HZ/USER_HZ) and related.
> Now x*(USER_HZ/HZ) will be used if HZ
> I'm running the Linux kernel under qemu and
On Tuesday, 8 of January 2008, Parag Warudkar wrote:
> On Jan 6, 2008 2:11 PM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> >
> > On Sunday, 6 of January 2008, Parag Warudkar wrote:
> > > On Jan 6, 2008 7:57 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > > > On Sunday, 6 of January 2008, In
Andrew Morton wrote:
diff --git a/include/linux/acct.h b/include/linux/acct.h
index 302eb72..86b848d 100644
--- a/include/linux/acct.h
+++ b/include/linux/acct.h
@@ -173,7 +173,11 @@ typedef struct acct acct_t;
static inline u32 jiffies_to_AHZ(unsigned long x)
{
#if (TICK_NSEC % (NSEC_PER_SEC
H. Peter Anvin wrote:
Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and
PIT? Does anyone care about just sticking in a udelay(2) (or 1) there
as a replacement and call it a day?
PIT is problematic because the PIT may be necessary for udelay setup.
On Mon, 07 Jan 2008 15:51:09 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> >> + do_div(x, HZ / USER_HZ);
> >> + #endif
> >> #else
> >>/*
> >> * There are better ways that don't overflow early,
> >
> > Alas, I get 100% rejects due to conflicting changes from Peter's
> > av
Allen Martin wrote:
Dunno about the NVidia version.
Theirs works rather differently - the GO bit is there, but there's
another append register which is used to tell the controller
that a new
tag has been added to the CPB list.
The only thing we currently use the GO bit for is to switch
be
On another topic. I have indeed determined what device uses port 80 on
Quanta AMD64 laptops from HP.
I had lunch with Jim Gettys of OLPC a week ago; he's an old friend since
he worked on the original X windows system. After telling him my story
about port 80, he mentioned that the OLPC XO m
On Mon, 2008-01-07 at 15:10 -0800, Andrew Morton wrote:
> On Sun, 06 Jan 2008 14:46:14 +0100
> Philipp Zabel <[EMAIL PROTECTED]> wrote:
>
> > The DS1WM driver incorrectly infers the IAS bit (1-wire interrupt active
> > high) from IRQ settings. There are devices that have IAS=0 but still need
> > t
David P. Reed wrote:
And actually, if I had looked at the /sys/bus/pnp definitions, rather
than /proc/ioports, I would have noticed that port 80 was part of a
PNP0C02 resource set. That means exactly one thing: ACPI says that
port 80 is NOT free to be used, for delays or anything else.
T
On Monday, 7 of January 2008, Alan Stern wrote:
> On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
[--snip--]
>
> > Okay, well, now I'm leaning towards the asynchronous approach.
> >
> > I'll prepare a new patch and send it later today.
>
> Okay.
Appended is what I managed to put together today.
I
Laurès wrote:
Hello,
Dear kernel developers, my dmesg asked me to report this, so here I go ;)
Here is what I found in my dmesg: "anticipatory: forced dispatching is
broken (nr_sorted=1), please report this".
- First, let's talk about the machine: it's quite pushed so maybe the
cause is me d
On Monday, 7 of January 2008, Rafael J. Wysocki wrote:
> On Monday, 7 of January 2008, Pavel Machek wrote:
> > Unify arch/x86/kernel/acpi/sleep*.c
> >
> > Pretty trivial unification; when two functions differed, it was
> > usually in error handling, and better of the two was picked up.
> >
> > Si
On Jan 7, 2008 6:54 PM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Well, now you're saying 2.6.23.12 is also affected, so this doesn't seem to
> be a recent regression in fact?
>
I have run 2.6.23 series before but my usage pattern seems to have not
triggered the bug before.
But yes, this is
HI all...
On Sun, 6 Jan 2008 14:19:16 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
> It's been two weeks since rc6, but let's face it, with xmas and new years
> (and birthdays) in between, there hasn't actually been a lot of working
> days, and the incremental patch from -rc6 is a
Hi,
I am running 2.6.23 kernel on a DUAL core and QUAD core i386 boxes and
after everyboot, when the ethernet traffic starts i get this warning.
All the ports in the system are e1000 and i am using the kernel e1000
driver.
Jan 7 22:31:00 localhost [warning] WARNING: at kernel/softirq.c:139
l
On Mon, Jan 07, 2008 at 05:31:58PM -0600, Robert Hancock wrote:
> Jesse Barnes wrote:
Hmm -- I didn't see Jesse's mail?
> I believe that such a change is in Greg KH's tree. So -mm (with both
> trees) would probably work.
Yes 2.6.24-rc6-mm1 works, but plain git-x86 does not:
PCI: MCFG configur
It's possible that the values used in and returned from jiffies_to_usecs() are
incorrect because of truncation when variables of type u64 are involved. So a
function specific to that type is used instead.
Updated from previous submission with feedback from Peter Anvin.
Diff'd against: linux/kern
Andi Kleen wrote:
On Mon, Jan 07, 2008 at 05:31:58PM -0600, Robert Hancock wrote:
Jesse Barnes wrote:
Hmm -- I didn't see Jesse's mail?
I believe that such a change is in Greg KH's tree. So -mm (with both
trees) would probably work.
Yes 2.6.24-rc6-mm1 works, but plain git-x86 does not:
P
[EMAIL PROTECTED] wrote:
> I am running 2.6.23 kernel on a DUAL core and QUAD core i386 boxes and
> after everyboot, when the ethernet traffic starts i get this warning.
>
> All the ports in the system are e1000 and i am using the kernel e1000
> driver.
[added netdev to the Cc:]
can you repro th
On Mon, 7 January 2008 15:23:00 -0800, Andrew Morton wrote:
> On Sun, 6 Jan 2008 14:56:01 +0100
> J__rn Engel <[EMAIL PROTECTED]> wrote:
You found a new one! That make a round dozen, I believe.
http://logfs.org/logfs/joern
> > - * Copyright (C) 2004-2006 Jörn Engel <[EMAIL PROTECTED]>
> > + * C
from Vince Fuller <[EMAIL PROTECTED]>
This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
(aka "class-E") address space as consistent with the Internet Draft
draft-fuller-240space-00.txt.
Signed-off-by: Vince Fuller <[EMAIL PROTECTED]>
---
--- include/linux/in.h.orig 2007-
Andi Kleen wrote:
THREAD_ORDER should be used on 32bit too.
32bit also has the equivalent of irq stacks (quite similar)
and exception stacks (somewhat different). Currently they use
other defines, but they could use the same. Also i386 has varying
irqstack orders disabling them with 8k stacks,
J. Bruce Fields wrote:
> On Sat, Jan 05, 2008 at 09:39:35PM +, Al Viro wrote:
>> On Sat, Jan 05, 2008 at 01:06:17PM -0800, Arjan van de Ven wrote:
>>> The http://www.kerneloops.org website collects kernel oops and
>>> warning reports from various mailing lists and bugzillas as well
>>> as wit
Dear all
A lot of google searches reflect that, the latest kernel supporting
Huawei EC321 CDMA PCCARD is 2.6.17. My version (2.6.22-14 on Ubuntu)
doesn't work.
I am not sure if I should file a bug somewhere or how to contact the
right person. I see another version of this card (Huawei E220) was
d
native_read_tsc is needed by modules, so it should be exported.
make -C /home/jeremy/hg/xen/paravirt/linux O=/home/jeremy/hg/xen/paravirt/linux-x86_64
Using /home/jeremy/hg/xen/paravirt/linux as source for kernel
GEN /home/jeremy/hg/xen/paravirt/linux-x86_64/Makefile
CHK include/linu
On Tue, 2008-01-08 at 09:02 +1100, Michael Ellerman wrote:
> On Thu, 2008-01-03 at 14:15 +0800, Shaohua Li wrote:
> > PCI Express ASPM defines a protocol for PCI Express components in the D0
> > state to reduce Link power by placing their Links into a low power state
> > and instructing the other
H. Peter Anvin wrote:
And shoot the designer of this particular microcontroller firmware.
Well, some days I want to shoot the "designer" of the entire Wintel
architecture... it's not exactly "designed" by anybody of course, and
today it's created largely by a collection of Taiwanese and Ch
On Mon, Jan 07, 2008 at 03:25:00AM -0700, Eric W. Biederman wrote:
> I think someone failed to notice that using /proc/sys slowed to a crawl
> in that event, and now that I am doing a lookup on register it seems to
> showing up in the benchmarks.
The directory that is problematic rarely gets acces
On Mon, 2008-01-07 at 10:19 -0800, Kok, Auke wrote:
> Shaohua Li wrote:
> > On Thu, 2008-01-03 at 11:33 -0800, Kok, Auke wrote:
> >> Shaohua Li wrote:
> >>> PCI Express ASPM defines a protocol for PCI Express components in the D0
> >>> state to reduce Link power by placing their Links into a low p
> The PIT usage for calibrating the delay loop can be moderated, if need
> by, by using the PC BIOS which by definition uses the PIT correctly it
> its int 15 function 83 call.. Just do it before coming up in a state
> where the PC BIOS int 15h calls no longer work. I gave code to do this
>
V1->V2:
- add missing #endif
V2->V3:
- use generic percpy_modcopy()
Powerpc has a way to determine the address of the per cpu area of the
currently executing processor via the paca and the array of per cpu
offsets is avoided by looking up the per cpu area from the remote
paca's (copying x86_64).
V1->V2:
- Use def_bool as suggested by Randy.
The use of the __GENERIC_PERCPU is a bit problematic since arches
may want to run their own percpu setup while using the generic
percpu definitions. Replace it through a kconfig variable.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL
V2->V3:
On Thu, 29 Nov 2007, Martin Schwidefsky wrote:
> On Wed, 2007-11-28 at 13:09 -0800, Christoph Lameter wrote:
> > s390 has a special way to determine the pointer to a per cpu area
> > plus there is a way to access the base of the per cpu area of the
> > currently executing processor.
> >
V1->V2:
- Merge fixes
- Remove transitional check for PER_CPU_ATTRIBUTES from linux/percpu.h
V2-.V3:
- use generic percpy_modcopy()
ia64 has a special processor specific mapping that can be used to locate the
offset for the current per cpu area.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed
Form a single percpu.h from percpu_32.h and percpu_64.h. Both are now pretty
small so this is simply adding them together.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTE
V1->V2:
- add support for PER_CPU_ATTRIBUTES
V2->V3:
- fix generic smp percpu_modcopy to use per_cpu_offset() macro.
Add the ability to use generic/percpu even if the arch needs to override
several aspects of its operations. This will enable the use of generic
percpu.h for all arches.
An arch ma
x86_64 provides an optimized way to determine the local per cpu area
offset through the pda and determines the base by accessing a remote
pda.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMA
x86_32 only provides a special way to obtain the local per cpu area offset
via x86_read_percpu. Otherwise it can fully use the generic handling.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL
V2->V3:
- use generic percpy_modcopy()
Sparc64 has a way of providing the base address for the per cpu area of the
currently executing processor in a global register.
Sparc64 also provides a way to calculate the address of a per cpu area
from a base address instead of performing an array lookup.
V1->V2:
- Special consideration for IA64: Add the ability to specify
arch specific per cpu flags
V2->V3:
- remove .data.percpu attribute from DEFINE_PER_CPU for non-smp case.
The arch definitions are all the same. So move them into linux/percpu.h.
We cannot move DECLARE_PER_CPU since some incl
This patchset simplifies the code that arches need to maintain to support
per cpu functionality. Most of the code is moved into arch independent
code. Only a minimal set of definitions is kept for each arch.
The patch also unifies the x86 arch so that there is only a single
asm-x86/percpu.h
V1->
Sometimes cpu_idle_wait gets stuck because it might miss CPUS that are
already in idle, have no tasks waiting to run and have no interrupts
going to them. This is common on bootup when switching cpu idle
governors.
This patch accounts for CPUs already in idle.
Background:
---
I notice t
!Congratulations! You have won.
Contact Dr.F.Drenthe.
Tel/Fax no:+31 847 549 511.
Email: [EMAIL PROTECTED]
For your prize fund of $1,000,000,00 USD(your e-mail ID won in a random computer
ballot program for Internet users.
Yours Sincerely,
Mrs. Kate Veldhuizen,
www.lotto.nl
Your Winning Informa
The following patchset allows additional "attributes" to be
passed to dma_map_*/dma_unmap_* implementations. (The reason
why this is useful/necessary has been mentioned several times,
most recently here:
http://marc.info/?l=linux-kernel&m=119258541412724&w=2.)
This is incomplete in that only i
Place the definition of enum dma_data_direction in its own
include file, and add the definition of enum dma_data_attr
and some simple routines for manipulating the direction and
attributes.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
dma-direction.h | 53 +
just found that when kexec 2.6.24-rc7 from RHEL 5.1 kernel got
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 2000
Bad page state in process 'swapper'
page:e2000418 flag
Allow dma "attributes" to be used by dma_map_*/dma_unmap_*
implementations on the ia64/sn2 architecture. (This one also
includes some changes to lib/swiotlb.c which aren't specific
to ia64/sn2.)
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
arch/ia64/sn/pci/pci_dma.c | 45 ++
Allow dma "attributes" to be passed to dma_map_*/dma_unmap_*
implementations on x86_64.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
arch/x86/kernel/pci-calgary_64.c | 13 -
arch/x86/kernel/pci-gart_64.c| 27 +--
arch/x86/kernel/pci-nommu_64.c
wonder why free_pages_check mm/page_alloc.c is using bit OR than logical OR
@@ -450,9 +450,9 @@ static inline void __free_one_page(struc
static inline int free_pages_check(struct page *page)
{
- if (unlikely(page_mapcount(page) |
- (page->mapping != NULL) |
-
On Tuesday 08 January 2008 00:09, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > No. I mean call the bit PG_private2. That way non-pagecache and
> > filesystems that don't use fscache can use it.
>
> The bit is called PG_owner_priv_2, and then 'subclassed' to PG_fscache,
> much l
On Fri, 2007-12-28 at 08:25 +0800, Robert Hancock wrote:
> Rafael J. Wysocki wrote:
> >> Also, as was pointed out, pre-Vista versions of Windows follow ACPI
> 1.0
> >> and Vista follows 3.0, so 2.0 doesn't really matter since BIOS
> people
> >> won't test against it. 1.0 specifies that _PTS is
On Mon, 7 Jan 2008 18:43:46 -0800 "Yinghai Lu" <[EMAIL PROTECTED]> wrote:
> wonder why free_pages_check mm/page_alloc.c is using bit OR than logical OR
>
> @@ -450,9 +450,9 @@ static inline void __free_one_page(struc
>
> static inline int free_pages_check(struct page *page)
> {
> - if (u
On Mon, 07 Jan 2008 20:38:09 +0100
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Christer Weinigel <[EMAIL PROTECTED]> wrote:
>
> > How do you find out the speed of the ISA bus? AFAIK there is no
> > standardized way to do that. On the Geode SC2200 the ISA bus speed
> > is usually the PCI clock divi
On Tuesday 08 January 2008 02:48:23 James Bottomley wrote:
> We're always open to new APIs (or more powerful and expanded old ones).
> The way we've been doing the sg_chain conversion is to slide API layers
> into the drivers so sg_chain becomes a simple API flip when we turn it
> on. Unfortunatel
On Monday 07 January 2008 21:05:26 Peter Zijlstra wrote:
> On Sun, 2008-01-06 at 14:11 -0500, Erez Zadok wrote:
> > > Ingo, Peter, does either of you actually care about this problem? In
> > > the last round when I debugged this problem there was a notable lack of
> > > reaction from either of you
Greg,
Have you given this patch-set any more consideration?
I've submitted the changes you requested.
Regards,
Tony
--
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
On Mon, 7 Jan 2008, Kevin Winchester wrote:
> J. Bruce Fields wrote:
> >
> > Is there any good basic documentation on this to point people at?
>
> I would second this question. I see people "decode" oops on lkml often
> enough, but I've never been entirely sure how its done. Is it somewhere
On Mon, Jan 07, 2008 at 09:27:24PM -0500, Steven Rostedt wrote:
>
> Sometimes cpu_idle_wait gets stuck because it might miss CPUS that are
> already in idle, have no tasks waiting to run and have no interrupts
> going to them. This is common on bootup when switching cpu idle
> governors.
I must
On Tuesday 08 January 2008 13:43, Yinghai Lu wrote:
> wonder why free_pages_check mm/page_alloc.c is using bit OR than logical OR
>
> @@ -450,9 +450,9 @@ static inline void __free_one_page(struc
>
> static inline int free_pages_check(struct page *page)
> {
> - if (unlikely(page_mapcount(pag
On Tue, Jan 08, 2008 at 10:34:22AM +1100, Benjamin Herrenschmidt wrote:
> powerpc: Workaround for iommu page alignment
>
> Our iommu page size is currently always 4K. That means with our current
> code, drivers may do a dma_map_sg() of a 64K page and obtain a dma_addr_t
> that is only 4K aligned.
On Thu, 2007-12-20 at 22:50 +0300, Ivan Kokshaysky wrote:
> Use type 1 just for the first 64 bytes and tg3 will be happy. All we need
> is to avoid touching BARs with mmconfig.
>
> Ivan.
I've tried Ivan's suggestion, and it works.
The patch is appended below.
My question is, do we want to in
From: Dmitri Vorobiev <[EMAIL PROTECTED]>
I noticed that the commit f197465384bf7ef1af184c2ed1a4e268911a91e3
(MIPS Tech: Get rid of volatile in core code) broke the software
reset functionality for MIPS Malta boards in big-endian mode.
According to the MIPS Malta board user's manual, writing the
> And sloppy of me to not catch it. Anyway:
>
> Acked-by: Olof Johansson <[EMAIL PROTECTED]>
>
> I wonder how long until there's a device that has some other < PAGE_SIZE
> alignment bug^Wrequirement that we'll need to meet too. :(
Yeah, it's a worry...
Ben.
--
To unsubscribe from this list: s
On Mon, 7 Jan 2008 10:31:53 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> We could replace the __you_cannot_kmalloc_that_much() with a BUG()
> statement so we have the same effect in SLAB?
>
sounds like a bad idea; a compile time failure is of course nicer than
a runtime failure fo
On Mon, Jan 07, 2008 at 12:04:06PM -0800, Christoph Lameter wrote:
> Here is the cleaned version of the patch. Dhaval is testing it.
>
>
> quicklists: Only consider memory that can be used with GFP_KERNEL
>
> Quicklists calculates the size of the quicklists based on the number
> of free pages. T
On Mon, Jan 07, 2008 at 10:20:23PM -0500, Tony Camuso wrote:
> Greg,
>
> Have you given this patch-set any more consideration?
Which patch-set, there have been a number of them :)
> I've submitted the changes you requested.
Care to respin them all so I'm not confused?
thanks,
greg k-h
--
To
The boot protocol has until now required that the initrd be located in
lowmem, which makes the lowmem/highmem boundary visible to the boot
loader. This was exported to the bootloader via a compile-time
field. Unfortunately, the vmalloc= command-line option breaks this
part of the protocol; instea
Subject: Turn 64 bit x86 HANDLE_STACK into print_context_stack like 32 bit has
From: Arjan van de Ven <[EMAIL PROTECTED]>
This patch turns the x86 64 bit HANDLE_STACK macro in the backtrace code into
a function, just like 32 bit has. This is needed pre work in order to get exact
backtraces for CO
Subject: Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER
on x86-64
From: Arjan van de Ven <[EMAIL PROTECTED]>
x86 32 bit already has this feature: This patch uses the stack frames with
frame pointer into an exact stack trace, by following the frame pointer.
This only affec
On Mon, 7 Jan 2008, Arjan van de Ven wrote:
> sounds like a bad idea; a compile time failure is of course nicer than
> a runtime failure for the cases we can find the bug at compile-time already.
>
There is not much chance of a runtime failure these days since kmalloc now
supports up to 4MB all
This patch corrects some erroneous dentry handling in eCryptfs.
If there is a problem creating the lower file, then there is nothing
that the persistent lower file can do to really help us. This patch
makes a vfs_create() failure in the lower filesystem always lead to an
unconditional do_create fa
On Mon, Jan 07, 2008 at 12:24:46PM -0800, Harvey Harrison wrote:
> Use a central is_kprobe_fault() inline in kprobes.h to remove all
> of the arch-dependant, practically identical implementations in
> avr32, ia64, powerpc, s390, sparc64, and x86.
>
> avr32 was the only arch without the preempt_dis
On Mon, Jan 07, 2008 at 09:02:53PM -0800, H. Peter Anvin wrote:
> The boot protocol has until now required that the initrd be located in
> lowmem, which makes the lowmem/highmem boundary visible to the boot
> loader. This was exported to the bootloader via a compile-time
> field. Unfortunately, t
On Mon, 7 Jan 2008 23:25:42 -0600 Michael Halcrow <[EMAIL PROTECTED]> wrote:
> --- a/fs/ecryptfs/inode.c
> +++ b/fs/ecryptfs/inode.c
> @@ -120,22 +120,9 @@ ecryptfs_do_create(struct inode *directory_inode,
> rc = ecryptfs_create_underlying_file(lower_dir_dentry->d_inode,
>
On Mon, 7 Jan 2008, Yinghai Lu wrote:
> try to kexec 2.6.23 from RHEL 5.1, will get
> Your BIOS doesn't leave a aperture memory hole
> Please enable the IOMMU option in the BIOS setup
> This costs you 64 MB of RAM ==> reboot
>
> but 2.6.24-rc7 kexec 2.6.24-rc7 is ok.
BUG in 2.6.23 kexec?
--
This patch export the boot parameters via debugfs for debugging.
The files added are as follow:
boot_params/data: binary file for struct boot_params
boot_params/version : boot protocol version
This patch is based on 2.6.24-rc5-mm1 and has been tested on i386 and
x86_64 platform.
This patc
Nick Piggin wrote:
On Tuesday 08 January 2008 13:43, Yinghai Lu wrote:
wonder why free_pages_check mm/page_alloc.c is using bit OR than logical OR
@@ -450,9 +450,9 @@ static inline void __free_one_page(struc
static inline int free_pages_check(struct page *page)
{
- if (unlikely(page_ma
On Saturday January 5, [EMAIL PROTECTED] wrote:
> Move the initialzation in __svc_create_thread that happens prior to
> thread creation to a new function. Export the function to allow
> services to have better control over the svc_rqst structs.
>
> Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
>
On Mon, Jan 07, 2008 at 07:26:12PM -0800, Linus Torvalds wrote:
> I usually just compile a small program like
>
> const char array[]="\xnn\xnn\xnn...";
>
> int main(int argc, char **argv)
> {
> printf("%p\n", array);
> *(int *)0=0;
> }
Heh. I
From: Brice Goglin <[EMAIL PROTECTED]>
Date: Mon, 07 Jan 2008 14:33:32 +0100
> [PATCH][LRO] Fix lro_mgr->features checks
>
> lro_mgr->features contains a bitmask of LRO_F_* values which are
> defined as power of two, not as bit indexes.
> They must be checked with x&LRO_F_FOO, not with test_bit(L
301 - 400 of 425 matches
Mail list logo
