On Sat, 26 Jan 2008 14:31:01 +0100, Stefan Richter said:
> Does your laptop have for example chained sg lists? :-)
Beats me - I don't see it on an 'lspci' ;) But I'm pretty sure it doesn't
have a 'powerpc' in it, so those threads get *totally* skipped...
My point was "personal interest in the
On Sat, 26 Jan 2008, Andrew Morton wrote:
On Thu, 24 Jan 2008 10:50:29 -0600 David Teigland <[EMAIL PROTECTED]> wrote:
From: Fabio M. Di Nitto <[EMAIL PROTECTED]>
gcc does not guarantee that a static buffer is 64bit aligned. This change
allows sparc64 to work.
This buffer is not static:
Linus,
please pull the following printk fix:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
it reverts 19ef9309273d: Kevin Winchester reported a
CONFIG_PRINTK_TIME=y related hang during X startup, and biscted it down
to this commit.
Ingo
> Add a new fops entry point to allow fasync without BKL. While it's arguably
> unclear this entry point is called often enough for it really matters
> it was still relatively easy to do. And there are far less async users
> in the tree than ioctls so it's likely they can be all converted
>
On Sun, 27 Jan 2008, Michael K?hn wrote:
>
> the attached Patch will remove a compiler warning in
> net/bluetooth/hci_sysfs.c:
Please don't do this. I realize that gcc suggests just adding parenthesis,
and yes, it makes the warning go away, but it's not sensible from a human
semantic
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > thanks Jason, i have applied your cleanups to x86.git.
>
> I don't recall having actually seen the kgdb patches recently. Have
> they had a suitable level of review?
it was posted three months ago to lkml (the upteenth time) and we picked
it up
Hi Mel
> > my patch stack is
> > 2.6.24-rc7 +
> > http://lkml.org/lkml/2007/8/24/220 +
>
> Can you replace this patch with the patch below instead and try again
> please? This is the patch that is actually in git-x86. Out of
> curiousity, have you tried the latest mm branch from git-x86?
to
On Sat, 26 Jan 2008, Rusty Russell wrote:
>
> module.c:1832 (in load_module)
>
> if (find_module(mod->name)) {
> err = -EEXIST;
> goto free_mod;
> }
>
> That's pretty early, and before this backtrace.
>
> Even for simultaneous loads, there's a mutex
* Ben Nizette <[EMAIL PROTECTED]> wrote:
> + * We just keep an empty definition of this around (a-la the asm-generic
> + * implementation) to keep /dev/mem happy
> + */
> +#define unxlate_dev_mem_ptr(p, a) {}
We havent had the PAT patches in x86.git for some time so there's no
* Kevin Winchester <[EMAIL PROTECTED]> wrote:
> The machine boots normally, but without that revert, X locks up. Does
> that make sense to anyone?
could you send your full bootlog? Also please send me the output of:
http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
and
> On Wed, 23 Jan 2008 10:29:37 -0800 Matt Helsley <[EMAIL PROTECTED]> wrote:
>
> Andrew, please consider this patch for inclusion in -mm.
>
> ...
>
Can't say that we're particularly exercised about mvfs's problems, but the
current way of doing /proc/pid/exe is indeed a nasty hack.
>
>
> On Tue, 22 Jan 2008 05:01:14 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> After running SetPageUptodate, preceeding stores to the page contents to
> actually bring it uptodate may not be ordered with the store to set the page
> uptodate.
>
> Therefore, another CPU which checks PageUptodate
> On Tue, 22 Jan 2008 11:23:45 +0900 Kyungmin Park <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This patch enables the uncompressed files support in cramfs.
>
> The word 'uncompressed file' is from linear cramfs (aka Application XIP).
> In linear cramfs, it is used to suport XIP on NOR. However it is
> On Thu, 24 Jan 2008 15:23:03 -0800 Tim Bird <[EMAIL PROTECTED]> wrote:
> Peter Zijlstra wrote:
> > I suspect these features reduce the chance a crash messages makes it out
> > onto the console, but fail to spot any of the copious text mention this
> > critical issue.
>
> Anything not in
> On Fri, 25 Jan 2008 14:03:25 +0800 Shaohua Li <[EMAIL PROTECTED]> wrote:
>
> - if (!page->mapping)
> + if (!page->mapping) {
> + if (!PageAnon(page) && PagePrivate(page))
> + try_to_release_page(page, GFP_KERNEL);
> goto rcu_unlock;
> +
> On Thu, 24 Jan 2008 13:41:49 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]>
> wrote:
> From: Chip Coldwell <[EMAIL PROTECTED]>
>
> This patch is based on the DMA-patch by Chip Coldwell for the
> AT91/AT32 serial USARTS, with some tweaks to make it apply neatly on
> top of the other patches in
> On Fri, 25 Jan 2008 18:06:29 -0400 Konrad Rzeszutek <[EMAIL PROTECTED]> wrote:
> Hey Andrew,
>
> Please add this patch along with Greg KH's kobject fixes.
erm, OK. But I don't think I'm the appropriate conduit for iscsi paches.
By what path _does_ iscsi ode get into the tree, anyway? Mike
> On Wed, 23 Jan 2008 19:47:52 +0100 Jan Kara <[EMAIL PROTECTED]> wrote:
> Implement dmode option for iso9660 filesystem to allow setting of access
> rights for directories on the filesystem.
Please update Documentation/filesystems/isofs.txt?
Also, the usual form for the description of this
> On Thu, 24 Jan 2008 20:33:41 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> Would you please consider these patches for -mm?
Sure, but I'm too lazy to pick through them and work out which ones need
updating, which ones got acked and which ones someone else merged, all on a
very
Please always include a diffstat with non-trivial patches.
> On Fri, 25 Jan 2008 18:06:29 -0400 Konrad Rzeszutek <[EMAIL PROTECTED]> wrote:
> --- a/arch/x86/kernel/setup_32.c
> +++ b/arch/x86/kernel/setup_32.c
lol. You touched x86 code.
--
To unsubscribe from this list: send the line
(cc netdev)
> On Fri, 25 Jan 2008 12:55:42 +0100 Michael Monnerie <[EMAIL PROTECTED]> wrote:
> Dear lists,
>
> I've been spending a LOT of time trying to find out where's the problem,
> but can't find it and therefore seek urgent help now. We have the
> following system:
>
> Server with
> On Thu, 24 Jan 2008 23:58:52 -0800 (PST) Alex Dubov <[EMAIL PROTECTED]> wrote:
> * Mark shared inline functions as static
>
> * Use member-at-a-time assignment for protocol structures
>
> * Comments for publicly exported functions
>
> * Use end_queued_request to end unhandled block layer
> On Fri, 25 Jan 2008 23:28:36 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Jason Wessel <[EMAIL PROTECTED]> wrote:
>
> > This patch is against the x86-git which included the kgdb core.
> >
> > Per review request from the x86-git maintainers, the kgdb-core has had
> > the
> On Fri, 25 Jan 2008 16:23:56 + Ian Abbott <[EMAIL PROTECTED]> wrote:
> From: Ian Abbott <[EMAIL PROTECTED]>
>
> If the fakephp driver is used to emulate removal of a PCI device by
> writing text string "0" to the "power" sysfs attribute file, this causes
> its parent directory and its
> On Thu, 24 Jan 2008 16:44:48 -0500 Len Brown <[EMAIL PROTECTED]> wrote:
> On Tuesday 25 December 2007 21:03, Matthew Garrett wrote:
> > The sysfs backlight class provides no mechanism for querying the
> > acceptable brightness for a backlight. The ACPI spec states that values
> > are only
> On Thu, 24 Jan 2008 10:50:29 -0600 David Teigland <[EMAIL PROTECTED]> wrote:
> From: Fabio M. Di Nitto <[EMAIL PROTECTED]>
>
> gcc does not guarantee that a static buffer is 64bit aligned. This change
> allows sparc64 to work.
>
This buffer is not static: changelog needs fixing:
> On Thu, 24 Jan 2008 10:50:30 -0600 David Teigland <[EMAIL PROTECTED]> wrote:
> void dlm_rcom_in(struct dlm_rcom *rc)
> {
> struct dlm_header *hd = (struct dlm_header *) rc;
aww, c'mon guys, this is nonsense.
struct dlm_header *hd = >rc_header;
there seems to be rather a lot of
> On Thu, 24 Jan 2008 03:01:53 +0800 "Wang Nan" <[EMAIL PROTECTED]> wrote:
> Hi, everyone.
> I have a question regarding to select system call's code. In
> do_select() function, after check each fd in the set, do_select() call
> cond_resched(). That line, according to my view, is to reduce the
>
On Sun, Jan 27, 2008 at 11:45:30AM +1100, Paul Mackerras wrote:
> This fixes vio_find_name() in arch/powerpc/kernel/vio.c, which is
> currently broken because it tries to use devices_subsys. That is bad
> for two reasons: (1) it's doing (or trying to do) a scan of all
> devices when it should
On Sat, 2008-01-26 at 17:59 -0800, Fernando Lopez-Lezcano wrote:
> Hi Ingo... back to testing.
> History:
>
> 2.6.23.x + rt has not been very usable for audio applications.
> 2.6.24-rt1: same so far.
>
> Why: Jack keeps printing "delayed..." messages and has xruns which means
> that somehow
>Investigating a bit more I realized that gcc looses the
>__used__ attribution due to the prototype.
>So there are two correct fixes:
>a) move the function up so we do not need the forward
> declaration
>b) add a __devexit to the forward decalration too.
>
>I strongly prefer the first version
Here's another patch that was missing in the previous BKL-removal series.
No BKL needed in pipe_ioctl
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/fs/pipe.c
===
--- linux.orig/fs/pipe.c
+++ linux/fs/pipe.c
@@ -576,9
On Sat, Jan 26, 2008 at 08:17:17PM +0100, Sam Ravnborg wrote:
>On Sat, Jan 26, 2008 at 04:55:58AM -0500, Jeff Garzik wrote:
>> WANG Cong wrote:
>> >diff --git a/drivers/video/kyro/fbdev.c b/drivers/video/kyro/fbdev.c
>> >index acb9370..437ebd0 100644
>> >--- a/drivers/video/kyro/fbdev.c
>> >+++
Hi,
the attached Patch will remove a compiler warning in
net/bluetooth/hci_sysfs.c:
--- hci_sysfs.c 2008-01-27 03:48:47.0 +0100
+++ hci_sysfs.c_new 2008-01-27 03:37:19.0 +0100
@@ -332,7 +332,7 @@
struct device *dev;
struct hci_conn *conn = container_of(work,
I checked ext4_ioctl and it looked largely safe to not be used
without BKL. So convert it over to unlocked_ioctl.
The only case where I wasn't quite sure was for the
dynamic fs grow ioctls versus umounting -- I kept the BKL for those.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
None of the callers of this function does actually take the BKL
as far as I can see. So remove the comment refering to the BKL.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/jbd/recovery.c |2 +-
fs/jbd2/recovery.c |2 +-
2 files
I checked ext3_ioctl and it looked largely safe to not be used
without BKL. So convert it over to unlocked_ioctl.
The only case where I wasn't quite sure was for the
dynamic fs grow ioctls versus umounting -- I kept the BKL for those.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
cifs_ioctl doesn't seem to need the BKL for anything, so convert it over
to use unlocked_ioctl.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/cifs/cifsfs.c | 10 +-
fs/cifs/cifsfs.h |4 ++--
fs/cifs/ioctl.c |4 ++--
3 files changed, 9
As far as I can see there is nothing in ocfs2_ioctl that requires the BKL,
so use unlocked_ioctl
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ocfs2/file.c |4 ++--
fs/ocfs2/ioctl.c | 12 +++-
fs/ocfs2/ioctl.h |3 +--
3 files changed, 6
Similar to the compat handlers of other file systems. The ioctls
are compatible except that they have different numbers.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/cifs/cifsfs.c | 15 +++
fs/cifs/cifsfs.h |2 ++
fs/cifs/ioctl.c | 19
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
net/socket.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/net/socket.c
===
--- linux.orig/net/socket.c
+++ linux/net/socket.c
@@
Convert jfs_ioctl over to not use the BKL. The only potential race
I could see was with two ioctls in parallel changing the flags
and losing the updates. Use the i_mutex to protect against this.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/jfs/file.c |2
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/fuse/dev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/fs/fuse/dev.c
===
--- linux.orig/fs/fuse/dev.c
+++ linux/fs/fuse/dev.c
@@
Not that it matters much, but it was easy.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/bad_inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/fs/bad_inode.c
===
--- linux.orig/fs/bad_inode.c
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/pipe.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux/fs/pipe.c
===
--- linux.orig/fs/pipe.c
+++ linux/fs/pipe.c
@@ -788,7 +788,7 @@ const
Add a new fops entry point to allow fasync without BKL. While it's arguably
unclear this entry point is called often enough for it really matters
it was still relatively easy to do. And there are far less async users
in the tree than ioctls so it's likely they can be all converted
eventually and
- Replace remote_llseek with remote_llseek_unlocked (to force compilation
failures in all users)
- Change all users to either use remote_llseek directly or take the
BKL around. I changed the file systems who don't use the BKL
for anything (CIFS, GFS) to call it directly. NCPFS and SMBFS and NFS
The ioctls were already compatible except for the actual values so this
was fairly easy to do.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/jfs/file.c |3 +++
fs/jfs/ioctl.c | 18 ++
fs/jfs/jfs_dinode.h |2 ++
BKL is not hold in any of those
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ext4/dir.c |2 +-
fs/ext4/inode.c |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
Index: linux/fs/ext4/dir.c
There is no BKL held on entry in ->fsync nor in the low level ext3_sync_file.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ext3/dir.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/fs/ext3/dir.c
[Andrew: I believe this is -mm material for .25]
- Convert some more file systems (generally those who don't use the BKL
for anything except mount) to use unlocked_bkl.
- Implement BKL less fasync (see patch for the rationale)
This is currently a separate entry point, but since the number of
No BKL used anywhere, so don't mention it.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ext2/inode.c |1 -
1 file changed, 1 deletion(-)
Index: linux/fs/ext2/inode.c
===
--- linux.orig/fs/ext2/inode.c
+++
I checked ext2_ioctl and could not find anything in there that would
need the BKL. So convert it over to use unlocked_ioctl
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ext2/dir.c |2 +-
fs/ext2/ext2.h |3 +--
fs/ext2/file.c |4 ++--
fs/ext2/ioctl.c | 12 +++-
On Sat, Jan 26, 2008 at 12:45:14PM +0200, Adrian Bunk wrote:
>On Sat, Jan 26, 2008 at 06:38:45PM +0800, WANG Cong wrote:
>>
>> Hi, Sam!
>>
>> When I built the latest linus tree, I got this error:
>>
>> ...
>> CC sound/oss/msnd.o
>> make[2]: *** No rule to make target
On Sat, 2007-12-08 at 10:17 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 2007-12-07 at 20:59 +0100, Ingo Molnar wrote:
> > > * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
> > >
> > > > > Nope, it doesn't still getting "delay" and "xrun"
On Thu, Jan 24, 2008 at 04:44:48PM -0500, Len Brown wrote:
> On Tuesday 25 December 2007 21:03, Matthew Garrett wrote:
> > The sysfs backlight class provides no mechanism for querying the
> > acceptable brightness for a backlight. The ACPI spec states that values
> > are only valid if they are
Sanka Piyaratna wrote:
Hi Everyone,
I am currently developing a custom PCIe device and the Linux kernel
driver for this. I am able to use the device as a character device with
PIO and now I am working on getting the DMA to work. I have implemented
2 BARs (BAR0 - mem and BAR5 - mem) in the
Yinghai Lu wrote:
diff --git a/arch/x86/boot/compressed/misc_64.c
b/arch/x86/boot/compressed/misc_64.c
index 8c1573b..bd822b7 100644
--- a/arch/x86/boot/compressed/misc_64.c
+++ b/arch/x86/boot/compressed/misc_64.c
@@ -372,8 +372,8 @@ asmlinkage void decompress_kernel(void *rmode, unsigned
On Jan 26, 2008 3:54 AM, Ian Campbell <[EMAIL PROTECTED]> wrote:
> It seems pretty arbitrary which version survives, so I chose the 32
> bit version.
>
> Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
> Cc: Thomas Gleixner <[EMAIL PROTECTED]>
> Cc: Ingo Molnar <[EMAIL PROTECTED]>
> Cc: H. Peter
On Jan 26, 2008 3:54 AM, Ian Campbell <[EMAIL PROTECTED]> wrote:
> This makes the file identical to vmlinux_32.scr.
>
> size shows an expected movement from .text to .data and 4 extra bytes
> of padding.
>
> Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
> Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Hello,
> > > On a big powerpc box I got the following oops with 2.6.24-git2:
> > >
> > > sym0: <1010-66> rev 0x1 at pci :d0:01.0 irq 215
> > > sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
> > > sym0: SCSI BUS has been reset.
> > > scsi0 : sym-2.2.3
> > > target0:0:8: FAST-40 WIDE
This fixes vio_find_name() in arch/powerpc/kernel/vio.c, which is
currently broken because it tries to use devices_subsys. That is bad
for two reasons: (1) it's doing (or trying to do) a scan of all
devices when it should only be scanning those on the vio bus, and
(2) devices_subsys was an
On Sun, 2008-01-27 at 01:18 +0100, Mariusz Kozlowski wrote:
> Hello,
>
> > On a big powerpc box I got the following oops with 2.6.24-git2:
> >
> > sym0: <1010-66> rev 0x1 at pci :d0:01.0 irq 215
> > sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
> > sym0: SCSI BUS has been reset.
> >
Kevin Winchester wrote:
> Hi Ingo,
>
> Starting X (autostarted with GDM) manages to lock up my system
> (requiring a hard reset) after the first few tree merges of the window,
> and bisection shows:
>
> -
>
> 19ef9309273d26cb005cb23e6a370353dca91099 is first bad commit
> commit
Hello,
> On a big powerpc box I got the following oops with 2.6.24-git2:
>
> sym0: <1010-66> rev 0x1 at pci :d0:01.0 irq 215
> sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi0 : sym-2.2.3
> target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns,
Hi Ingo,
Starting X (autostarted with GDM) manages to lock up my system
(requiring a hard reset) after the first few tree merges of the window,
and bisection shows:
-
19ef9309273d26cb005cb23e6a370353dca91099 is first bad commit
commit 19ef9309273d26cb005cb23e6a370353dca91099
There is a race between shutdown and creation of devices: fw-core may
attempt to add a device with the same name of an already existing
device. http://bugzilla.kernel.org/show_bug.cgi?id=9828
Impact of the bug: Happens rarely, forces the user to unplug and replug
the new device to get it
Tigran Aivazian wrote:
> On Sat, 26 Jan 2008, Dmitri Vorobiev wrote:
>> -inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME_SEC;
>> +inode->i_mtime = CURRENT_TIME_SEC;
>> +inode->i_atime = CURRENT_TIME_SEC;
>> +inode->i_ctime = CURRENT_TIME_SEC;
>
> multiple
On Saturday, 26 of January 2008, Len Brown wrote:
> On Friday 25 January 2008 19:32, Rafael J. Wysocki wrote:
> > Hi,
> >
> > I'd like to move the 64-bit suspend/hibernation files from arch/x86/kernel
> > to
> > arch/x86/power, modify the names of the 32-bit files already in
> > arch/x86/power
On Saturday, 26 of January 2008, Pavel Machek wrote:
> Hi!
>
> > I'd like to move the 64-bit suspend/hibernation files from arch/x86/kernel
> > to
> > arch/x86/power, modify the names of the 32-bit files already in
> > arch/x86/power and update the Makefiles accordingly, but there are some
> >
Without this patch the linker will generate a section
named .sched.text.1 which is unexpected.
This is because the gcc generated section has "ax" but the
assembler usage of .sched.text lacks the "ax" specifier.
It would be better to have a definition we could use from
assembler code but I did not
ld will generate an unique named section when assembler do not
use "ax" but gcc does. Add the misisng annotation.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/sparc/lib/rwsem.S |2 +-
arch/sparc64/lib/rwsem.S |2 +-
2 files changed, 2
Hi Andrew,
Nothing major, but the From: line in your -mm patch
pci-disable-decoding-during-sizing-of-bars.patch is wrong.
The patch is from Matthew Wilcox <[EMAIL PROTECTED]>, just Andreas helped
bring the issue to people's attention :)
Thanks,
Daniel
--
To unsubscribe from this list: send
On Sat, Jan 26, 2008 at 08:19:44PM -0200, Carlos Carvalho wrote:
> Near the end of the build this appears:
>
> KSYM.tmp_kallsyms2.S
> AS .tmp_kallsyms2.o
> LD vmlinux.o
> MODPOST vmlinux.o
> WARNING: vmlinux.o(.text.head+0xe4): Section mismatch: reference to
>
Near the end of the build this appears:
KSYM.tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux.o(.text.head+0xe4): Section mismatch: reference to
.init.data.2:trampoline_level4_pgt (between 'ident_complete' and
'secondary_startup_64')
Fix the following warning:
WARNING: arch/x86/kernel/built-in.o(.cpuinit.text+0x7a3): Section mismatch:
reference to .init.text:amd_detect_cmp in 'init_amd'
The function amd_detect_cmp were annotated __init and
was only used from init_amd() which are annotated __cpuinit.
Annotate
Fix following warning:
WARNING: arch/x86/kernel/built-in.o(__ksymtab+0x2b0): Section mismatch:
reference to .cpuinit.text:arch_register_cpu in '__ksymtab_arch_register_cpu'
Annotating exported symbols are wrong.
Previously the warning were hidden by avoiding the export
in the non HOTPLUG_CPU
Fix following warnings:
WARNING: arch/x86/kernel/built-in.o(.text+0x139e1): Section mismatch: reference
to .init.data:early_qrk in 'check_dev_quirk'
WARNING: arch/x86/kernel/built-in.o(.text+0x139f5): Section mismatch: reference
to .init.data:early_qrk in 'check_dev_quirk'
WARNING:
Fix the following warnings:
WARNING: arch/x86/mm/built-in.o(.text+0x1abc): Section mismatch: reference to
.init.data:nodes_parsed in 'unparse_node'
WARNING: arch/x86/mm/built-in.o(.text+0x1ac6): Section mismatch: reference to
.cpuinit.data:apicid_to_node in 'unparse_node'
WARNING:
Fix the following warning:
WARNING: arch/x86/kernel/built-in.o(.text+0x3): Section mismatch: reference to
.cpuinit.data:force_mwait in 'mwait_usable'
[Seen on 64 bit only but similar pattern exist on 32 bit so fix it there too]
mwait_usable() were only used by a function annotated __cpuinit
so
Fix following warning:
WARNING: arch/x86/kernel/built-in.o(.text+0x10ea0): Section mismatch: reference
to .cpuinit.data:num_processors in 'acpi_unmap_lsapic'
The exported function acpi_unmap_lsapic() references
the variable num_processors that is annotated __cpuinitdata.
Remove the annotation
Fix following warning:
WARNING: arch/x86/kernel/cpu/mcheck/built-in.o(.text+0x752): Section mismatch:
reference to .cpuinit.text:mce_create_device in 'mce_cpu_callback'
mce_cpu_callback() is only used by mce_cpu_notofier.
The notifier is only used for hotplugable cpu's as it is
registered using
Fix following warning:
WARNING: arch/x86/kernel/cpu/mcheck/built-in.o(.text+0x1584): Section mismatch:
reference to .cpuinit.text:threshold_create_device in 'threshold_cpu_callback'
threshold_cpu_callback() is only used by threshold_cpu_notifier.
threshold_cpu_notifier is only used for cpu hot
On a big powerpc box I got the following oops with 2.6.24-git2:
sym0: <1010-66> rev 0x1 at pci :d0:01.0 irq 215
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.3
target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
scsi 0:0:8:0:
On Sat, 2008-01-26 at 12:44 -0800, Greg KH wrote:
> On Sat, Jan 26, 2008 at 07:53:20PM +, Adrian McMenamin wrote:
> > Greg,
> >
> > Just updated my git to the latest sources and get these (seemingly
> > non-fatal) oops with the Dreamcast maple bus. I'll investigate further, but
> > they
The following serie of 8 patches contains:
x86: fix Section mismatch warning in srat_64.c
=> straightforward - please apply
x86: fix Section mismatch warning in mcheck/mce_64.c
=> I took some assumptions on use of notifier.
See comments and please review before applying
x86: fix Section
Added Ingo + Peter.
Sam
On Sat, Jan 26, 2008 at 10:38:15PM +0100, Toralf Förster wrote:
> It seems to be rather a scheduler issue than a governor issue b/c
> the issue went away after unsetting CONFIG_FAIR_GROUP_SCHED.
>
> If I unselect CONFIG_FAIR_GROUP_SCHED then the %CPU value raises
It seems to be rather a scheduler issue than a governor issue b/c
the issue went away after unsetting CONFIG_FAIR_GROUP_SCHED.
If I unselect CONFIG_FAIR_GROUP_SCHED then the %CPU value raises 80%
- which forces the ondemand governor do speed up the CPU frequency:
PID USER PR NI VIRT
On Jan 25, 2008 11:24 PM, Greg KH <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jan 25, 2008 at 11:08:53PM -0800, Yinghai Lu wrote:
> > On Jan 25, 2008 10:14 PM, Greg KH <[EMAIL PROTECTED]> wrote:
> > >
> > > On Fri, Jan 25, 2008 at 10:04:19PM -0800, Yinghai Lu wrote:
> > > > On Jan 25, 2008 2:50 PM,
On Saturday 26 January 2008, Christoph Hellwig wrote:
> On Sat, Jan 26, 2008 at 04:09:52AM -0500, Mike Frysinger wrote:
> > Per previous discussions about cleaning up ufs_fs.h, people just want
> > this straight up dropped from userspace export. The only remaining
> > consumer (silo) has been
Hello,
I was having problems with these FreedomLine cards with Linux before but
tested it thoroughly today. This card uses DEC 21041 chip and has TP and BNC
connectors:
00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip
21041 [Tulip Pass 3] [1011:0014] (rev 21)
de2104x
On Saturday 26 January 2008, Jan Engelhardt wrote:
>
> On Jan 26 2008 21:31, Frans Pop wrote:
> >> config BLK_DEV_IDE_PMAC
> >> - bool "Builtin PowerMac IDE support"
> >> + tristate "Builtin PowerMac IDE support"
this change is no-op at the moment because the next Kconfig line is:
On Sat, Jan 26, 2008 at 06:53:31PM +0530, Kamalesh Babulal wrote:
> Hi,
>
> The 2.6.24-git2 kernel build fails on the power boxes with following build
> failure
>
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/powerpc/kernel/built-in.o: In function `fphalf':
>
do_generic_mapping_read was used by gfs2 for internals reads, but this
use of the interface was rather suboptimal (as was the whole interface)
and has been replaced by an internal helper now. This patch kills
do_generic_mapping_read and surrounding damage in preparation of additional
cleanups for
On Sat, Jan 26, 2008 at 07:53:20PM +, Adrian McMenamin wrote:
> Greg,
>
> Just updated my git to the latest sources and get these (seemingly non-fatal)
> oops with the Dreamcast maple bus. I'll investigate further, but they may
> mean something to out out of the box.
>
> Adrian
>
>
>
>
On Jan 26 2008 21:31, Frans Pop wrote:
>> config BLK_DEV_IDE_PMAC
>> - bool "Builtin PowerMac IDE support"
>> + tristate "Builtin PowerMac IDE support"
>
>This does not seem to make sense: if the option is now tristate, it is no
>longer "Builtin", so probably s/Builtin // in the
> config BLK_DEV_IDE_PMAC
> - bool "Builtin PowerMac IDE support"
> + tristate "Builtin PowerMac IDE support"
This does not seem to make sense: if the option is now tristate, it is no
longer "Builtin", so probably s/Builtin // in the description.
Cheers,
FJP
--
To unsubscribe from
On Thursday 24 January 2008, Mattias Nissler wrote:
>
> On Thu, 2008-01-24 at 00:03 +, Chris Clayton wrote:
> > Thanks for the reply, John.
> >
> > On Wednesday 23 January 2008, John W. Linville wrote:
> > > On Wed, Jan 23, 2008 at 04:42:58PM +, Chris Clayton wrote:
> > > > On Wednesday
On Sat, Jan 26, 2008 at 04:09:52AM -0500, Mike Frysinger wrote:
> Per previous discussions about cleaning up ufs_fs.h, people just want this
> straight up dropped from userspace export. The only remaining consumer (silo)
> has been fixed a while ago to not rely on this header.
Thanks! Care to
On Fri, Jan 25, 2008 at 10:04:51PM -0700, Dan Williams wrote:
> Given an fd on a block device, returns a string like
>
> /block/sda/sda1
>
> which can be used to find related information in /sys.
>
> Ideally we should have an ioctl that works on char devices as well,
> but that seems far
1 - 100 of 487 matches
Mail list logo
