On Fri, 28 Dec 2007 13:05:39 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> FUJITA Tomonori wrote:
> [snip]
> > Thanks,
> >
> > Can you try this?
> >
> >
> > diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> > index e7d8544..495575a 100644
> > --- a/lib/iommu-helper.c
> > +++ b/lib/iommu-
On 12/13/2007 02:27 AM, Dave Young wrote:
> On Dec 13, 2007 12:37 AM, Michal Schmidt <[EMAIL PROTECTED]> wrote:
>> On Wed, 12 Dec 2007 07:24:36 -0700
>> Justin Banks <[EMAIL PROTECTED]> wrote:
>>
> (2.6.9-55.0.9.ELsmp)
>>> -^^
>
> I'm so blind.
>
>>> It's really really old
On 12/12/2007 10:56 AM, Dave Young wrote:
> On Dec 12, 2007 5:17 PM, Oliver Falk <[EMAIL PROTECTED]> wrote:
>> Can someone explain me that?
>>
>> Dec 12 00:24:15 santorini kernel: Unable to handle kernel NULL pointer
>> dereference at virtual address
>> Dec 12 00:24:15 santorini kernel: p
On Thu, 27 Dec 2007 10:57:20 -0800 "Russell Leidich" <[EMAIL PROTECTED]> wrote:
> Thanks Andrew. I have a few questions on your comments...
>
> On Dec 25, 2007 2:04 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > + unsigned int apic_lv_therm;
> > > +
> > > + /* Set up APIC_LVTTHMR to
On 12/12/2007 03:55 PM, Luiz Fernando N. Capitulino wrote:
> Em Wed, 12 Dec 2007 10:17:10 +0100
> Oliver Falk <[EMAIL PROTECTED]> escreveu:
>
> | Can someone explain me that?
> |
> | Dec 12 00:24:15 santorini kernel: Unable to handle kernel NULL pointer
> | dereference at virtual address
FUJITA Tomonori wrote:
[snip]
> Thanks,
>
> Can you try this?
>
>
> diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> index e7d8544..495575a 100644
> --- a/lib/iommu-helper.c
> +++ b/lib/iommu-helper.c
> @@ -8,15 +8,20 @@
> static unsigned long find_next_zero_area(unsigned long *map,
>
On 12/12/2007 03:24 PM, Justin Banks wrote:
> Dave Young wrote
>> On Dec 12, 2007 5:17 PM, Oliver Falk <[EMAIL PROTECTED]> wrote:
>>> Can someone explain me that?
>>>
>>> Dec 12 00:24:15 santorini kernel: Unable to handle kernel NULL pointer
>>> dereference at virtual address
>>> Dec 12 00
On Thu, 27 Dec 2007 12:54:34 -0500 [EMAIL PROTECTED] wrote:
> On Sat, 22 Dec 2007 23:30:56 PST, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
>
> I seem to be on a roll here... :)
Yup. But please do try to get the cc's right. E
James Morris wrote:
On Fri, 28 Dec 2007, KaiGai Kohei wrote:
+ snprintf(tmp, sizeof(tmp),
+cap_entry == &cap_entries[0] ? "0x%08x" : "%u",
+cap_entry->code);
+ len = strlen(tmp);
You don't need to call strlen(), just use scnprintf() and grab the re
Hi Michael,
// sorry for the delay...
On Mon, Dec 10, 2007 at 06:02:55PM -0800, Michael Rubin wrote:
> From: Michael Rubin <[EMAIL PROTECTED]>
>
> Fixing a bug where writing to large files while concurrently writing to
> smaller ones creates a situation where writeback cannot keep up with the
>
On Thu, 2007-12-27 at 13:12 -0500, Vivek Goyal wrote:
> On Thu, Dec 27, 2007 at 10:33:13AM +0800, Huang, Ying wrote:
> > On Wed, 2007-12-26 at 20:57 -0500, Vivek Goyal wrote:
> > [...]
> > > > 9. Now, you are in the original kernel again. You can read/write the
> > > >memory image of kexeced ke
Hi,
On Fri, Dec 28, 2007 at 09:22:01AM +0300, Alexey Dobriyan wrote:
> On Thu, Dec 27, 2007 at 11:17:28PM +0100, Andreas Mohr wrote:
> > And this is the state that my 2.6.24-rc_six_-mm1 tree is in already.
>
> OK.
>
> > So either it didn't help here or it broke again by some later change or
> >
On Fri, 28 Dec 2007, KaiGai Kohei wrote:
> + snprintf(tmp, sizeof(tmp),
> + cap_entry == &cap_entries[0] ? "0x%08x" : "%u",
> + cap_entry->code);
> + len = strlen(tmp);
You don't need to call strlen(), just use scnprintf() and grab the return
value.
- James
-
gt; > > >
> > > >
> > > > Yes. Denis and Eric are tossing around competing patches but afaik
> > > > nobody
> > > > is happy with any of them. Guys, could we get this sorted soonish
> > > > please?
> > >
> > &g
The attached patch enables to export capability code/name pairs
under /capability of securityfs (revision 2).
Inprovements from the first revison:
- simple_read_from_buffer() is used for read method.
- cap_entries[] array is generated from include/linux/capability.h
automatically.
Remaining iss
On Thu, 2007-12-27 at 21:37 -0800, Linus Torvalds wrote:
>
> On Fri, 28 Dec 2007, Benjamin Herrenschmidt wrote:
> >
> > I have embedded boards where proper CRS operations is critical since the
> > kernel brings the PCIe link up itself, and thus is likely to hit devices
> > still in the middle of
On Thu, 27 Dec 2007, Linus Torvalds wrote:
> On Thu, 27 Dec 2007, Daniel Barkalow wrote:
> >
> > I'd actually bet that the hardware bug is actually that any device that
> > gives a CRS response the first time will have its Vendor ID appear as 0001
> > on subsequent mmconfig accesses, which mean
>> I think the following code in fib6_del_route in the latest kernel is useless.
>> 1125 if (fn->leaf == NULL && fn->fn_flags&RTN_TL_ROOT)
>> 1126 fn->leaf = &ip6_null_entry;
>>
>> ip6_null_entry will never be unlinked from fn->leaf now, that is,
>> fn->leaf == NULL will nev
On Thu, 27 Dec 2007, Robert Hancock wrote:
>
> I doubt they would prefer the later ordering in any way that matters, if the
> Windows version they were designed for uses the earlier ordering.
Well, I wouldn't say it's abotu "preferring" one over the other. It's very
possible that the BIOS writ
On Fri, 28 Dec 2007, Benjamin Herrenschmidt wrote:
>
> I have embedded boards where proper CRS operations is critical since the
> kernel brings the PCIe link up itself, and thus is likely to hit devices
> still in the middle of CRS.
.. but that's perfectly fine. A PCI-E bridge will certainly re
On Thu, 2007-12-27 at 23:18 +0100, Kai Ruhnau wrote:
> That one did not work out so well.
> I reenabled the call to pci_enable_crs() and changed the line as above.
> That resulted in two timeouts (from dmesg):
>
> []
> ACPI: Interpreter enabled
> ACPI: (supports S0 S3 S4 S5)
> ACPI: Using IO
On Thu, 27 Dec 2007, Daniel Barkalow wrote:
>
> I'd actually bet that the hardware bug is actually that any device that
> gives a CRS response the first time will have its Vendor ID appear as 0001
> on subsequent mmconfig accesses, which means that it's actually a bus
> quirk that probably on
On Thu, 27 Dec 2007 11:15:37 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> FUJITA Tomonori wrote:
> > On Thu, 27 Dec 2007 10:08:25 +0530
> > Balbir Singh <[EMAIL PROTECTED]> wrote:
> >
> >> FUJITA Tomonori wrote:
> >>> On Mon, 24 Dec 2007 10:18:50 +0530
> >>> Balbir Singh <[EMAIL PROTECTED]> wr
On Thu, 2007-12-27 at 13:37 -0800, Linus Torvalds wrote:
> The code doesn't actually do what CRS is supposed to help with (ie go
> on
> to probe another device and then come back to the slow one later), so
> right now it's pretty much useless *anyway*.
It's not totally useless... Instead of no
On Thu, 2007-12-27 at 13:37 -0800, Linus Torvalds wrote:
>
> > Does anybody knows what was the original rational to call
> > pci_enable_crs() by default?
>
> .. another good question. I don't think anybody expected it to be
> broken,
> but if this turns out to be the thing that triggers it, I t
From: Gui Jianfeng <[EMAIL PROTECTED]>
Date: Thu, 27 Dec 2007 15:26:46 +0800
> I think the following code in fib6_del_route in the latest kernel is useless.
> 1125 if (fn->leaf == NULL && fn->fn_flags&RTN_TL_ROOT)
> 1126 fn->leaf = &ip6_null_entry;
>
> ip6_null_entry will
On Thu, 2007-12-27 at 08:08 +0100, Julia Lawall wrote:
> On Wed, 26 Dec 2007, H. Peter Anvin wrote:
>
> > Ray Lee wrote:
> > > On Dec 26, 2007 7:21 AM, Julia Lawall <[EMAIL PROTECTED]> wrote:
> > > > - if (jiffies - ent->last_usage < timeout)
> > > > + if (time_before(j
On Thu, 27 Dec 2007, Kai Ruhnau wrote:
> Linus Torvalds wrote:
> > On Thu, 27 Dec 2007, Linus Torvalds wrote:
> >
> >> Kai, can you try that? Just remove the call to pci_enable_crs() in
> >> pci_scan_bridge() in drivers/pci/probe.c, and see if mmconfig starts
> >> working for you?
> >>
>
On Thu, Dec 27, 2007 at 07:49:01PM -0500, Mike Frysinger wrote:
> On Thursday 27 December 2007, Joe Perches wrote:
> > I also added a function gdrom_is_busy() to make a couple of tests
> > fit on a single line and perhaps easier to read.
>
> i'd tend to agree it does make it easier to read, howeve
Thanks for the response Phillip. See below for response.
I already am using "console=ttyS0" as well as set the inittab correctly.
I would like to debug this node behavior. Can you please let me know
which routine gets called first when there is, for example a read() call
from user program. Eventu
On Thu, Dec 27, 2007 at 06:19:46PM -0800, Christoph Lameter wrote:
> nfsd4_delegations? What is this about?
The random lifetimes of user-visible files you create in sysfs.
> How do I scan for the symlinks in sysfs?
At which point are you going to do that? AFAICS, the fundamental problem
is that
On Sun, 2007-12-23 at 20:11 -0500, Rik van Riel wrote:
> On Mon, 24 Dec 2007 04:29:36 +0530
> Balbir Singh <[EMAIL PROTECTED]> wrote:
> > Rik van Riel wrote:
>
> > > In the real world, users with large JVMs on their servers, which
> > > sometimes go a little into swap, can trigger this system. A
Hi Gustavo,
>By mistake we activate intel I/oat dma support on a laptop with a
>centrino duo to try to get better performance on IO.
I/OAT is for accelerating network operations on newer Xeon processors
and E1000 nics. Some information about it is available here:
http://lwn.net/Articles/165131/
On Thu, Dec 27, 2007 at 05:00:12PM +0200, saeed bishara wrote:
> > >> Are you using TCP? Are you using NFSv4, or an older version?
> > > I'm using NFSv3/UDP.
> >
> > IMO, you definitely want TCP and NFSv4. Much better network behavior,
> > with some of the silly UDP limits (plus greatly improved
shacky wrote:
[ Added linux-hotplug to CC ]
> Hi.
Hi,
>
> I'm writing here because I didn't found a mailing list specific for udev.
There it is :
http://vger.kernel.org/vger-lists.html#linux-hotplug
> I'm sorry if I am out of topic. In this case please tell me.
>
> I'm trying to get an Hu
On Fri, 28 Dec 2007, Al Viro wrote:
> Oh, lovely. So we can have module A do kmem_cache_create(), calling
> cache "foo". Then module B does (without any knowlegde about A)
> completely unrelated kmem_cache_create(), calling the sucker "bar".
> mm/slub decides that they are mergable. Then we get
Make the control flow of kprobe_handler more obvious.
Collapse the separate if blocks/gotos with if/else blocks
this unifies the duplication of the check for a breakpoint
instruction race with another cpu.
Create two jump targets:
preempt_out: re-enables preemption before returning ret
Serge E. Hallyn wrote:
Quoting KaiGai Kohei ([EMAIL PROTECTED]):
This patch enables to export the code/name pairs of capabilities under
/capability of securityfs.
In the current libcap, it obtains the list of capabilities from header file
on the build environment statically. However, it is not
Make the control flow of kprobe_handler more obvious.
Collapse the separate if blocks/gotos with if/else blocks
this unifies the duplication of the check for a breakpoint
instruction race with another cpu.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Masami, please have a look at this,
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > Did any earlier version of the 2.6 kernel work OK?
Kernel 2.6.14 does not work any better than 2.6.23.x, and my F8 userspace
environment rejects a
2.4.35 kernel. I will try a 2.6.0 kernel next, but have noticed tonight that a
stock Fedora kernel
In article <[EMAIL PROTECTED]> (at Thu, 27 Dec 2007 08:08:53 +0100 (CET)),
Julia Lawall <[EMAIL PROTECTED]> says:
> On Wed, 26 Dec 2007, H. Peter Anvin wrote:
>
> > Ray Lee wrote:
> > > On Dec 26, 2007 7:21 AM, Julia Lawall <[EMAIL PROTECTED]> wrote:
> > > > - if (jiffies - ent->la
Hi
What's the purpose of the val in __do_proc_dointvec ?
It seems no one ever uses this val.
Tomohiro Kusumi
Signed-off-by: Tomohiro Kusumi <[EMAIL PROTECTED]>
diff -Nur linux-2.6.23.org/kernel/sysctl.c linux-2.6.23/kernel/sysctl.c
--- linux-2.6.23.org/kernel/sysctl.c2007-12-28 09:29:18.
On Thursday 27 December 2007, Joe Perches wrote:
> On Thu, 2007-12-27 at 16:52 +, Adrian McMenamin wrote:
> > This patch adds support for the CD-Rom drive on the SEGA Dreamcast.
>
> Because it was already so close, might as well make it checkpatch clean.
for the 80 col limit, that's up to the
On Thu, Dec 27, 2007 at 04:02:56PM -0800, Christoph Lameter wrote:
> > Why would you want these symlinks to stick around for longer than that?
>
> /sys/kernel/slab/cache_name is a real directory but then there are the
> aliases in /sys/kernel/slab/alias_name pointing to that directory that
> als
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 to be called before
suspending devices and 3.0 says that the AML must not depe
From: [EMAIL PROTECTED]
Date: Thu, 27 Dec 2007 16:16:25 -0800
> 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 instea
Linus Torvalds wrote:
But as mentioned, there were other reports too of the exact same bug (with
different PCI devices, but the same "vendor == 0001" bogosity).
Googling for
lspci "Unknown device 0001:" mmconfig
shows reports like these:
http://lkml.org/lkml/2007/10/29/500
tor, 27 12 2007 kl. 14:58 -0800, skrev Joe Perches:
> On Thu, 2007-12-27 at 16:52 +, Adrian McMenamin wrote:
> > This patch adds support for the CD-Rom drive on the SEGA Dreamcast.
>
> Because it was already so close, might as well make it checkpatch clean.
>
> I also added a function gdrom_i
From: [EMAIL PROTECTED]
Date: Thu, 27 Dec 2007 16:10:49 -0800
> V1->V2:
> - add support for PER_CPU_ATTRIBUTES
>
> 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 a
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.
> >
> > Note:
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
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
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.
Cc: David Miller <[EMAIL PROTECTED]>
Si
V1->V2:
- add missing #endif
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).
Cc: Paul Mackerras <[EMAIL PROTECTED]>
V1->V2:
- Merge fixes
- Remove transitional check for PER_CPU_ATTRIBUTES from linux/percpu.h
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-off-by: Christoph Lameter <[EMAIL PROTE
V1->V2:
- add support for PER_CPU_ATTRIBUTES
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 may define:
__per_cpu_offsetDo not use the generic pointer array.
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
V1->V2:
- Special consideration for IA64: Add the ability to specify
arch specific per cpu flags
The arch definitions are all the same. So move them into linux/percpu.h.
We cannot move DECLARE_PER_CPU since some include files just include
asm/percpu.h to avoid include recursion problems.
Cc: R
[resending as my first attempt sent only a partial list.]
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
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
From: [EMAIL PROTECTED]
Date: Thu, 27 Dec 2007 16:10:48 -0800
> V1->V2:
> - Special consideration for IA64: Add the ability to specify
> arch specific per cpu flags
>
> The arch definitions are all the same. So move them into linux/percpu.h.
>
> We cannot move DECLARE_PER_CPU since some includ
From: [EMAIL PROTECTED]
Date: Thu, 27 Dec 2007 16:10:47 -0800
> 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
V1->V2:
- Special consideration for IA64: Add the ability to specify
arch specific per cpu flags
The arch definitions are all the same. So move them into linux/percpu.h.
We cannot move DECLARE_PER_CPU since some include files just include
asm/percpu.h to avoid include recursion problems.
Cc: R
V1->V2:
- add missing #endif
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).
Cc: Paul Mackerras <[EMAIL PROTECTED]>
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
V1->V2:
- add support for PER_CPU_ATTRIBUTES
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 may define:
__per_cpu_offsetDo not use the generic pointer array.
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
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.
> >
> > Note:
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
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->
On Thu, 27 Dec 2007, Al Viro wrote:
> On Thu, Dec 27, 2007 at 03:53:43PM -0800, Christoph Lameter wrote:
> > On Thu, 27 Dec 2007, Christoph Lameter wrote:
> >
> > > > a) remove symlink when slab goes away
> > >
> > > Ok. Need to think about how to code that.
> >
> > How do I iterate over all sy
>
> Mike, what's going on? I definitely told you last time I
> looked at this patch that it is a bug to call
> sysfs_remove_group() under spinlock, because
> sysfs_remove_group() takes sleeping locks. Yet here it is again.
>
> Maybe you lost my email. It is here:
> http://lkml.org/lkml/2007/11/2
On Thu, Dec 27, 2007 at 03:53:43PM -0800, Christoph Lameter wrote:
> On Thu, 27 Dec 2007, Christoph Lameter wrote:
>
> > > a) remove symlink when slab goes away
> >
> > Ok. Need to think about how to code that.
>
> How do I iterate over all symlinks in /sys/kernel/slab/*?
>
> I remember trying
On Thu, Dec 27, 2007 at 03:22:28PM -0800, Christoph Lameter wrote:
> > a) remove symlink when slab goes away
>
> Ok. Need to think about how to code that.
Huh? Just call it from kmem_cache_destroy(); what business does that symlink
have being around after that point?
> > b) instead of kfree() i
On Thu, 27 Dec 2007, Christoph Lameter wrote:
> > a) remove symlink when slab goes away
>
> Ok. Need to think about how to code that.
How do I iterate over all symlinks in /sys/kernel/slab/*?
I remember trying to do it before and not being able to find a sysfs
method for that.
--
To unsubscri
On Thu, 27 Dec 2007, Al Viro wrote:
> On Thu, Dec 27, 2007 at 12:28:14PM -0800, Christoph Lameter wrote:
> > Hmmm.. If I separately allocate the kobject then I can no longer get to
> > the kmem_cache structure from the kobject.
> >
> > I need to add a second kobject_del to sysfs_slab_remove() t
On Thu, Dec 27, 2007 at 12:28:14PM -0800, Christoph Lameter wrote:
> Hmmm.. If I separately allocate the kobject then I can no longer get to
> the kmem_cache structure from the kobject.
>
> I need to add a second kobject_del to sysfs_slab_remove() to make sysfs
> completely forget about the obj
On Thu, 2007-12-27 at 16:52 +, Adrian McMenamin wrote:
> This patch adds support for the CD-Rom drive on the SEGA Dreamcast.
Because it was already so close, might as well make it checkpatch clean.
I also added a function gdrom_is_busy() to make a couple of tests
fit on a single line and perh
The get_vm_area() allocates one extra guard page, and stores the augmented
size in area->size. But the ioremap/iounmap code on x86 relies on finding
the original size in area->size (otherwise it does change the attribute
of some random device in the linear-map by using a wrong size in
ioremap_chang
Hi.
I'm writing here because I didn't found a mailing list specific for udev.
I'm sorry if I am out of topic. In this case please tell me.
I'm trying to get an Huawei e220 UMTS/HSDPA USB modem working on my Ubuntu 7.10.
The problem of that peripheral is that when you plug the modem in the
USB por
On Thursday, 27 of December 2007, Carlos Corbacho wrote:
> On Thursday 27 December 2007 18:03:52 Rafael J. Wysocki wrote:
> > Please review (and test, if possible).
>
> Suspend now works properly here with this patch set.
>
> Tested-by: Carlos Corbacho <[EMAIL PROTECTED]>
Thanks a lot for testin
On Thu, Dec 27, 2007 at 04:52:19PM +, Adrian McMenamin wrote:
> This patch adds support for the CD-Rom drive on the SEGA Dreamcast.
>
> The SEGA Dreamcast has a built in CD-Rom drive, electrically similar
> to an ATA-3 drive, but implementing a proprietary packet interface -
> the so-called Se
On Sunday 23 December 2007, Al Boldi wrote:
>
> Reogranize USB Kconfig Menu, and move USB_GADGET out into the Device Driver
> Menu. This helps the USB Kconfig Menu to be more logical/usable.
>
> Cc: David Brownell <[EMAIL PROTECTED]>
> Cc: Greg KH <[EMAIL PROTECTED]>
> Cc: Andrew Morton <[EMAIL
Linus Torvalds wrote:
> On Thu, 27 Dec 2007, Linus Torvalds wrote:
>
>> Kai, can you try that? Just remove the call to pci_enable_crs() in
>> pci_scan_bridge() in drivers/pci/probe.c, and see if mmconfig starts
>> working for you?
>>
>
> We could also make the error handling more permissi
afaik nobody
> > > is happy with any of them. Guys, could we get this sorted soonish please?
> >
> > "Soonish" being rather earlier than 20071227?
> > 'cause it's still throwing a fit for me on 2.6.24-rc6-mm1(!) (plus hotfix),
> >
Linus Torvalds wrote:
> On Thu, 27 Dec 2007, Loic Prylli wrote:
>
>> Does the 0001 vendor-id still shows up if pci_enable_crs() has never
>> been called?
>>
>
> I don't believe we have ever tried, but it would be very interesting to
> hear.
>
> Kai, can you try that? Just remove the call
On Thu, 27 Dec 2007, Linus Torvalds wrote:
>
> Kai, can you try that? Just remove the call to pci_enable_crs() in
> pci_scan_bridge() in drivers/pci/probe.c, and see if mmconfig starts
> working for you?
We could also make the error handling more permissive, and just check for
the low 16 bit
On Thu, 27 Dec 2007, Loic Prylli wrote:
>
> The root pcie port implementation is obviously buggy. But did we confirm
> whether that hardware bug might be partly related to
> "configuration-retry-status" pcie-root handling as introduced/described in:
Ahh, yes, that sounds like an excellent expla
On Thu, Dec 27, 2007 at 04:10:33PM -0500, Loic Prylli wrote:
> The root pcie port implementation is obviously buggy. But did we confirm
> whether that hardware bug might be partly related to
> "configuration-retry-status" pcie-root handling as introduced/described in:
>
> http://marc.info/?l=linux
On 12/27/2007 1:58 PM, Linus Torvalds wrote:
>
> There was a thread called "PCI vendor id == 1 regression?" (Kai Ruhnau was
> the main reporter for that one). But looking back, it seems that one
> didn't hit the kernel mailing list, so I guess google cannot pick it up. I
> can forward all the em
>From ed2e7764917fd56d9743630bd7072f67ff30adc2 Mon Sep 17 00:00:00 2001
From: Serge Hallyn <[EMAIL PROTECTED]>
Date: Wed, 26 Dec 2007 15:04:50 -0800
Subject: [PATCH 1/1] capabilities: oom_kill: don't set PF_SUPERPRIV for oom
check
With 64-bit capabilities came an inadvertent change such
that the
On Wed, Dec 26, 2007 at 08:26:27AM +1100, Benjamin Herrenschmidt wrote:
>
> > This is exactly what's supposed to be happening, but the code is buggy
> > and nobody noticed :-) (I'm mixing up IORESOURCE_* flags and
> > PCI_COMMAND_* flags). Thanks for reviewing !
>
> Note that this patch isn't in
On Thu, 2007-12-27 at 16:52 +, Adrian McMenamin wrote:
> This patch adds support for the CD-Rom drive on the SEGA Dreamcast.
>
> The SEGA Dreamcast has a built in CD-Rom drive, electrically similar
> to an ATA-3 drive, but implementing a proprietary packet interface -
> the so-called Sega Pac
On 12/27/2007 06:21 PM, Adrian Bunk wrote:
> On Thu, Dec 27, 2007 at 06:19:31PM +0300, Michael Tokarev wrote:
>> Jiri Slaby wrote:
>>> (Old) mxser is obsoleted by mxser_new and scheduled for removal on Dec 2007.
>>> Remove it.
>>>
>>> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
>>> ---
>>> Docum
Hmmm.. If I separately allocate the kobject then I can no longer get to
the kmem_cache structure from the kobject.
I need to add a second kobject_del to sysfs_slab_remove() to make sysfs
completely forget about the object?
Probably should track down any remaining symlinks at that point and nuk
* alloc_slabmgmt: initialize all slab fields in 1 function
* slab->nodeid was initialized twice: in alloc_slabmgmt
and immediately after it in cache_grow
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Christoph Lameter <[EMAIL PROTECTED]>
CC: Pekka Enberg <[EMAIL PROTECTED]>
diff --git a/
Siva Prasad wrote:
Hi,
How do the device nodes work as an interface between user and kernel
programs, and how to go debugging it?
This is as part of my debugging effort on an embedded board.
The filesystem sets specific bits in the mode mask and elsewhere in the
inode to mark the file as a d
On Thu, Dec 27 2007, Adrian McMenamin wrote:
>
> On Thu, 2007-12-27 at 17:18 +0900, Paul Mundt wrote:
> > On Thu, Dec 27, 2007 at 01:26:47AM +, Adrian McMenamin wrote:
>
> >
> > > + /* now seek to take the request spinlock
> > > + * before handling ending the request
On Thu, 27 Dec 2007 11:59:23 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> >> 2) [non-minor] h.
> >>
> >>[EMAIL PROTECTED] ~]$ lspci -n | wc -l
> >>23
> >>
> >> So I would have to perform 23 sysfs twiddles, before I could
> >> obtain a full and unabridged
On Thursday, 27 of December 2007, Robert Hancock wrote:
> Rafael J. Wysocki wrote:
> > On Wednesday, 26 of December 2007, Linus Torvalds wrote:
> >> On Tue, 25 Dec 2007, Rafael J. Wysocki wrote:
> >>> the ACPI specification between versions 1.0x and 2.0. Namely, while ACPI
> >>> 2.0 and later want
1 - 100 of 192 matches
Mail list logo
