Re: [2.6 patch] net/ipv4/ipvs/: remove unused exports
On Sun, Nov 11, 2007 at 04:09:40PM +0900, Simon Horman wrote: > On Sun, Nov 11, 2007 at 07:48:40AM +0100, Adrian Bunk wrote: > > This patch removes the following unused EXPORT_SYMBOL's: > > - ip_vs_try_bind_dest > > - ip_vs_find_dest > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > Looks fine to me. > > Should Dave Miller put this in his tree, > or do you want to handle it a different way? >... If Dave applies it that would be perfect. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 13/13] Char: nozomi, cleanup read and write
On Sat, Nov 10, 2007 at 11:04:41PM +0100, Jiri Slaby wrote:
> On 11/10/2007 05:15 PM, Adrian Bunk wrote:
> > On Fri, Nov 09, 2007 at 06:51:35PM -0500, Jiri Slaby wrote:
> >> ...
> >> --- a/drivers/char/nozomi.c
> >> +++ b/drivers/char/nozomi.c
> >> ...
> >> - if (size_bytes - i == 2) {
> >> + if (unlikely(size_bytes - i == 2)) {
> >> ...
> >
> > Please don't add likely/unlikely in drivers unless it brings a
> > measurable improvement.
>
> Why? Anyway I think this is the case. The body of the then branch is executed
> at
> most once, while the else branch each time but last. If you write/read 1002
> bytes, it means 250:1. ...and it's invoked from interrupt too...
AFAIK there is no well defined semantics whether likely/unlikely means
10:1 or 1:1 that is guaranteed to not change during the next
10 years.
Unless there's a measurable difference, it's best to write readable
C code and simply leave all optimizations to the compiler.
> regards,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
On Sat, Nov 10, 2007 at 11:43:20AM -0800, Andrew Morton wrote: > On Sat, 10 Nov 2007 12:18:50 + David Howells <[EMAIL PROTECTED]> wrote: >... > > has a couple of examples on it's front page. If you work through the menus > > of > > modern Panasonic tellies, you might find a URL pointing somewhere on this > > website that isn't reachable by linking from the index page of the website. > > > > I don't know who else uses this CPU, but it's possible MEI sell them to > > other > > companies. > > If it is indeed the case that this architecture is used internally by a > single organisation then perhaps it doesn't make sense for us to merge it. > > One of the main reasons we put code into the kernel is as a means of > distribution: to get it into the hands of people who need it. But in this > situation there is no advantage to *anyone* from this merge apart from MEI. > > IOW, the submitter gains and everyone else loses. It's a curious situation. >... You miss the point that we want people to be able to use Linux in such situations. There are basically two choices: - Either tell them code won't get merged and offer some degree of API stability in exchange or - allow all code with >= 1 users to enter the kernel. [1] With the current development model (and the mere amount of changes merged), the first choice is not possible. The only reason for not merging it [1] would be if it would be unmaintained and bitrot, but considering that David is already doing a good job at maintaining the frv port that's not an issue here. cu Adrian [1] assuming the code itself is considered OK -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 Please read the FAQ at http://www.tux.org/lkml/
[PATCH] log2.h: Define order_base_2() macro for convenience.
Given a number of places in the tree that need to calculate this value explicitly, might as well just create a macro for it. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- run-time tested for the first several values. note that this macro is defined strictly in terms of rounding *up* -- i've seen no places in the tree that require this expression to be rounded down, so i'm not drawing that distinction. diff --git a/include/linux/log2.h b/include/linux/log2.h index c8cf5e8..ed121c0 100644 --- a/include/linux/log2.h +++ b/include/linux/log2.h @@ -190,4 +190,20 @@ unsigned long __rounddown_pow_of_two(unsigned long n) __rounddown_pow_of_two(n) \ ) +/** + * order_base_2 - calculate the (rounded up) base 2 order of the argument + * @n: parameter + * + * The first few values calculated by this routine: + * ob2(0) = 0 + * ob2(1) = 0 + * ob2(2) = 1 + * ob2(3) = 2 + * ob2(4) = 2 + * ob2(5) = 3 + * ... and so on. + */ + +#define order_base_2(n) ilog2(roundup_pow_of_two(n)) + #endif /* _LINUX_LOG2_H */ -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] log2.h: Define order_base_2() macro for convenience.
On Sun, 11 Nov 2007, Randy Dunlap wrote: > On Sat, 10 Nov 2007 22:53:36 -0500 (EST) Robert P. J. Day wrote: > > > > +/** > > + * order_base_2 - calculate the (rounded up) base 2 order of the argument > > + * @n - parameter > > * @n: argument > > (mostly changing - to :) ah, yes, fix coming shortly. rday - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] module: fix and elaborate comments
On Friday 09 November 2007 03:37:38 Matti Linnanvuori wrote: > From: Matti Linnanvuori <[EMAIL PROTECTED]> > > Fix and elaborate comments. Thanks, applied. Rusty. - 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 Please read the FAQ at http://www.tux.org/lkml/
XFS related Oops
Hi,
after resume from suspend with 2.6.23.1, I got the following Oops:
BUG: unable to handle kernel paging request at virtual address 3e0d204c
printing eip:
c022807f
*pde =
Oops: [#1]
SMP
Modules linked in: dvb_usb_cinergyT2 i915 drm cpufreq_stats usblp
firewire_ohci firewire_core dvb_usb crc_itu_t evdev snd_hda_intel
rtc_cmos sky2 dvb_core applesmc led_class coretemp hwmon
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202 (2.6.23.1 #4)
EIP is at xfs_iget_core+0x6f/0x690
eax: 0033f000 ebx: 3e0d2010 ecx: f7826000 edx: 0033f000
esi: 001346d7 edi: ebp: f7525214 esp: f68b7cb4
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process squid (pid: 2967, ti=f68b6000 task=f6833030 task.ti=f68b6000)
Stack: c024f1b1 0001 f6a3d6c0 001346d7 f789ce00 c18993d8 c04fb280
f7525218
f7826000 e652c240 3e0d2010 e652c25c
e652c240
001346d7 f7826000 c0228774 001346d7
f68b7d80
Call Trace:
[] kmem_zone_alloc+0x51/0xb0
[] xfs_iget+0xd4/0x160
[] xfs_dir_lookup_int+0x9b/0x100
[] xfs_lookup+0x75/0xa0
[] xfs_vn_lookup+0x54/0x90
[] do_lookup+0x122/0x1a0
[] __link_path_walk+0x784/0xd80
[] __next_cpu+0x12/0x30
[] find_busiest_group+0x19d/0x6a0
[] link_path_walk+0x45/0xc0
[] process_timeout+0x0/0x10
[] get_unused_fd_flags+0x52/0xc0
[] do_path_lookup+0x73/0x1b0
[] get_empty_filp+0x58/0x120
[] __path_lookup_intent_open+0x51/0xa0
[] path_lookup_open+0x20/0x30
[] open_namei+0x66/0x640
[] lock_timer_base+0x27/0x60
[] try_to_del_timer_sync+0x45/0x50
[] do_filp_open+0x2e/0x60
[] process_timeout+0x0/0x10
[] get_unused_fd_flags+0x52/0xc0
[] do_sys_open+0x4c/0xe0
[] sys_open+0x1c/0x20
[] sysenter_past_esp+0x5f/0x85
===
Code: 44 24 1c 8b 44 24 1c e8 60 92 1b 00 8b 5d 00 85 db 89 5c 24 34 75
14 e9 90 00 00 00 8b 5b 04 85 db 89 5c 24 34 0f 84 81 00 00 00 <8b> 53
3c 8b 43 38 31 fa 31 f0 09 c2 75 e3 8d 83 dc 00 00 00 e8
EIP: [] xfs_iget_core+0x6f/0x690 SS:ESP 0068:f68b7cb4
Does this ring any bells?
Regards,
Tino
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] scsi: megaraid_sas - call cmd completion from reset
On Fri, 2007-11-09 at 04:35 -0500, bo yang wrote: > Driver will call cmd completion routine from Reset path without waiting for > cmd completion from isr context. Thanks. I'm going to take a look at this, as well as the other recent 2 patches for a couple of test kernels we have that are based on the -RT patchset. We are seeing occasional problems with megasas (so far only exhibited on specific systems based upon the PERC 5 cards) when: * Using an -RT kernel. * Lots of outstanding IO. My analysis suggests that this happens because the -RT patch changes tasklet behavior such that we won't run nearly as quickly as in vanilla Linux, and we might end up with a lot more IO cmds outstanding with the FW before we get around to dequeing them. I think there exists (but I haven't proved it yet) a timing problem in that driver. In a 2.6.21 test kernel we have, there's an inconsistency wrt. upstream changes that happened at that time - James and Christoph were racing wrt. oneanother and the use of the additional (optional) scsi host callback that sas happens to use to handle io throttling. In later kernels, this behavior almost seems to be working - I backported this to 2.6.21 and can see the throttle function get called a few times before we finally go out to lunch. I'm planning to finish debugging tomorrow. This is an FYI really, just to say that I'm actively poking at megasas at the moment. I would also love to hear from yourself, and anyone else who is (or who has) test[ing|ed] these ongoing patches on -RT. Jon. - 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 Please read the FAQ at http://www.tux.org/lkml/
DMA descriptor alignment
For those variants of BCM43xx cards that use 64-bit DMA, there is a requirement that all descriptor rings must be aligned on an 8K boundary and must fit within an 8K page. On the x86_64 architecture where the page size is 4K, I was getting addresses like 0x67AF000 when using dma_alloc_coherent calls. From the description of the dma_pool_create and dma_pool_allocate routines, I thought they would fix my problems; however, even with a dma_pool_create(name, dev, 8192, 8192, 8192) call, I'm still getting 4K rather than 8K alignment, which results in DMA errors. Is there a bug in these routines, am I using them incorrectly, or do I have a misunderstanding of what it takes to get this kind of alignment? Thanks, Larry - 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 Please read the FAQ at http://www.tux.org/lkml/
the kernel, gcc and libgcc
[ linux-arch added to the Cc,
a copy of my original email is at the bottom ]
On Sun, Nov 11, 2007 at 04:34:22PM +0900, Paul Mundt wrote:
> On Sun, Nov 11, 2007 at 07:48:29AM +0100, Adrian Bunk wrote:
> > But the kernel does (at least on some architectures) not link with
> > libgcc or ship other code providing the required libgcc functions.
> >
> > Richard Guenther suggested in gcc bug #32044 to use -fno-tree-scev-cprop
> > (new option in gcc 4.3) as a workaround and I confirmed that it fixes
> > the compilation.
> >
> And some architectures do link it in, so the call to libgcc code doesn't
> necessarily matter. Perhaps the architectures that don't link in libgcc
> can turn this flag on conditionally, it shouldn't be forced on the
> architectures that do link it in.
We seem to have 3 different kinds of architectures:
- does not provide libgcc at all
- provides part of libgcc itself
- links with libgcc
And we also _might_ get away without requiring -fno-tree-scev-cprop on
some of the 64bit architectures that do not provide or link with libgcc.
This all is horrible fragile, with the root of the problem being a
disagreement between what gcc expects an environment to provide and what
the kernel provides.
After all, the real question is not whether we are able to limit the
workaround of disabling a minor optimization to fewer architectures,
but to get this fixed properly.
Ideally, we solve the latter making my patch not required on any
architecture.
cu
Adrian
<-- snip -->
The gcc from svn that will become gcc 4.3 generates libgcc calls in
cases like the following (on 32bit architectures):
<-- snip -->
static inline void timespec_add_ns(struct timespec *a, u64 ns)
{
...
while(ns >= NSEC_PER_SEC) {
ns -= NSEC_PER_SEC;
a->tv_sec++;
}
...
<-- snip -->
It can make sense to emit assembler code doing division for such C code -
that doesn't seem to be something that would generally be wrong.
But the kernel does (at least on some architectures) not link with
libgcc or ship other code providing the required libgcc functions.
Richard Guenther suggested in gcc bug #32044 to use -fno-tree-scev-cprop
(new option in gcc 4.3) as a workaround and I confirmed that it fixes
the compilation.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
f2357fcb8addd855f1be6ac9fdf4ef3c3ab8256d
diff --git a/Makefile b/Makefile
index e28dde8..9d8a831 100644
--- a/Makefile
+++ b/Makefile
@@ -527,6 +527,9 @@ KBUILD_CFLAGS += $(call
cc-option,-Wdeclaration-after-statement,)
# disable pointer signed / unsigned warnings in gcc 4.0
KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
+# workaround to avoid gcc 4.3 emitting libgcc calls (see gcc bug #32044)
+KBUILD_CFLAGS += $(call cc-option,-fno-tree-scev-cprop,)
+
# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
# But warn user when we do so
warn-assign = \
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: cd/dvd inaccessible in 2.6.24-rc2
Hello, My mistake, it looks like the issue is to do with writing only. Mounting a standard DVD works fine with 2.6.24-rc2-git2. As soon as I try to use wodim or load k3b, that's when drive gets locked up. The issue was still there with 2.6.23-git15 , I will continue to test with previous ones. Regards, Will Trives On Sun, 2007-11-11 at 15:40 +1100, Will Trives wrote: > Hello Jeff, > > Yes it is. I'll keep testing with previous kernels. > > Dmesg does look different with 2.6.23 vs 2.6.24-rc2 > > This is 2.6.23 : > > scsi8 : pata_jmicron > scsi9 : pata_jmicron > ata9: PATA max UDMA/100 cmd 0x0001c000 ctl 0x0001c102 bmdma > 0x0001c400 irq 17 > ata10: PATA max UDMA/100 cmd 0x0001c200 ctl 0x0001c302 bmdma > 0x0001c408 irq 17 > ata9.00: ATAPI: BENQDVD DD DW1640, BSRB, max UDMA/33 > ata9.00: configured for UDMA/33 > ata9: EH pending after completion, repeating EH (cnt=4) > scsi 8:0:0:0: CD-ROMBENQ DVD DD DW1640BSRB PQ: 0 ANSI: 5 > > > This is 2.6.24-rc2 : > > scsi8 : pata_jmicron > scsi9 : pata_jmicron > ata9: PATA max UDMA/100 cmd 0xc000 ctl 0xc100 bmdma 0xc400 irq 17 > ata10: PATA max UDMA/100 cmd 0xc200 ctl 0xc300 bmdma 0xc408 irq 17 > ata9.00: ATAPI: BENQ DVD DD DW1640, BSRB, max UDMA/33 > ata9.00: configured for UDMA/33 > scsi 8:0:0:0: CD-ROM BENQ DVD DD DW1640 BSRB PQ: 0 ANSI: 5 > > Regards, > > Will Trives > > On Sat, 2007-11-10 at 18:35 -0500, Jeff Garzik wrote: > > Will Trives wrote: > > > Hello, > > > > > > Motherboard: Gigabyte GA-P35-DS4 (rev. 1.1) > > > Chipset: Intel P35 + ICH9R > > > PATA port runs off JMicron controller > > > CD/DVD Device: BENQ DW1640 16X > > > > > > I cannot access my dvd burner under 2.6.24-rc2, I have no problems under > > > 2.6.23. Basically the drive is detected OK, everything looks ok but as > > > soon as I go to use it errors like this occur: > > > > Is 2.6.24-rc1 also broken? > > > > Jeff > > > > - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: msync(2) bug(?), returns AOP_WRITEPAGE_ACTIVATE to userland
On Fri, 9 Nov 2007, Erez Zadok wrote:
> In message <[EMAIL PROTECTED]>, Hugh Dickins writes:
> >
> > One, I think you would be safer to do a set_page_dirty(lower_page)
> > before your clear_page_dirty_for_io(lower_page). I know that sounds
> > silly, but see Linus' "Yes, Virginia" comment in clear_page_dirty_for_io:
> > there's a lot of subtlety hereabouts, and I think you'd be mimicing the
> > usual path closer if you set_page_dirty first - there's nothing else
> > doing it on that lower_page, is there? I'm not certain that you need
> > to, but I think you'd do well to look into it and make up your own mind.
>
> Hugh, my code looks like:
>
> if (wbc->for_reclaim) {
> set_page_dirty(lower_page);
> unlock_page(lower_page);
> goto out_release;
> }
> BUG_ON(!lower_mapping->a_ops->writepage);
> clear_page_dirty_for_io(lower_page); /* emulate VFS behavior */
> err = lower_mapping->a_ops->writepage(lower_page, wbc);
>
> Do you mean I should set_page_dirty(lower_page) unconditionally before
> clear_page_dirty_for_io? (I already do that in the 'if' statement above it.)
Yes. Whether you're wrong not to be doing that already, I've not checked;
but I think doing so will make unionfs safer against any future changes
in the relationship between set_page_dirty and clear_page_dirty_for_io.
For example, look at clear_page_dirty_for_io: it's decrementing some
statistics which __set_page_dirty_nobuffers increments. Does use of
unionfs (over some filesystems) make those numbers wrap increasingly
negative? Does adding this set_page_dirty(lower_page) correct that?
I suspect so, but may be wrong.
> > Two, I'm unsure of the way you're clearing or setting PageUptodate on
> > the upper page there. The rules for PageUptodate are fairly obvious
> > when reading, but when a write fails, it's not so obvious. Again, I'm
> > not saying what you've got is wrong (it may be unavoidable, to keep
> > synch between lower and upper), but it deserves a second thought.
>
> I looked at all mainline filesystems's ->writepage to see what, if any, they
> do with their page's uptodate flag. Most f/s don't touch the flag one way
> or another.
I'm not going to try and guess what assorted filesystems are up to,
and not all of them will be bugfree. The crucial point of PageUptodate
is that we insert a filesystem page into the page cache before it's had
any data read in: it needs to be !PageUptodate until the data is there,
and then marked PageUptodate to say the data is good and others can
start using it. See mm/filemap.c.
> And finally, unionfs clears the uptodate flag on error from the lower
> ->writepage, and otherwise sets the flag on success from the lower
> ->writepage. My gut feeling is that unionfs shouldn't change the page
> uptodate flag at all: if the VFS passes unionfs_writepage a page which isn't
> uptodate, then the VFS has a serious problem b/c it'd be asking a f/s to
> write out a page which isn't up-to-date, right? Otherwise, whether
> unionfs_writepage manages to write the lower page or not, why should that
> invalidate the state of the unionfs page itself? Come to think of it, I
> think clearing pageuptodate on error from ->writepage(lower_page) may be
> bad. Imagine if after such a failed unionfs_writepage, I get a
> unionfs_readpage: that ->readpage will get data from the lower f/s page and
> copy it *over* the unionfs page, even if the upper page's data was more
> recent prior to the failed call to unionfs_writepage. IOW, we could be
> reverting a user-visible mmap'ed page to a previous on-disk version. What
> do you think: could this happen? Anyway, I'll run some exhaustive testing
> next and see what happens if I don't set/clear the uptodate flag in
> unionfs_writepage.
That was my point, and I don't really have more to add. It's unusual
to do anything with PageUptodate when writing. By clearing it when the
lower level has an error, you're throwing away the changes already made
at the upper level. You might have some good reason for that, but it's
worth questioning. If you don't know why you're Set/Clear'ing it there,
better to just take that out.
Hugh
-
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
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH] Export force_sig_info
This change allows force_sig_info to be called from modules. Signed-off-by: Jeremy Kerr <[EMAIL PROTECTED]> -- Any objections to exporting this symbol? I'm planning to move some SPU fault-handling code from the kernel to the spufs.ko object. --- kernel/signal.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6-spufs/kernel/signal.c === --- linux-2.6-spufs.orig/kernel/signal.c +++ linux-2.6-spufs/kernel/signal.c @@ -815,6 +815,7 @@ force_sig_info(int sig, struct siginfo * return ret; } +EXPORT_SYMBOL_GPL(force_sig_info); void force_sig_specific(int sig, struct task_struct *t) - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86
On Mon, Nov 12, 2007 at 03:47:02AM +0100, Roman Zippel wrote: > Hi, > > On Sat, 10 Nov 2007, Sam Ravnborg wrote: > > > As discussed in another thread the right thing is to add a generic solution > > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al. > > Could you please point me to this discussion? It starts with this post from Jeff Garzik: http://lkml.org/lkml/2007/11/9/274 Sam - 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 Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] voyager: fix smp init sections
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix Voyager section mismatch due to using __devinit instead of __cpuinit.
WARNING: vmlinux.o(.text+0xd943): Section mismatch: reference to
.init.text:init_gdt (between 'voyager_smp_prepare_boot_cpu' and
'smp_vic_cmn_interrupt')
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
arch/x86/mach-voyager/voyager_smp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.24-rc2-git2.orig/arch/x86/mach-voyager/voyager_smp.c
+++ linux-2.6.24-rc2-git2/arch/x86/mach-voyager/voyager_smp.c
@@ -1900,7 +1900,7 @@ voyager_smp_prepare_cpus(unsigned int ma
smp_boot_cpus();
}
-static void __devinit voyager_smp_prepare_boot_cpu(void)
+static void __cpuinit voyager_smp_prepare_boot_cpu(void)
{
init_gdt(smp_processor_id());
switch_to_new_gdt();
@@ -1911,7 +1911,7 @@ static void __devinit voyager_smp_prepar
cpu_set(smp_processor_id(), cpu_present_map);
}
-static int __devinit
+static int __cpuinit
voyager_cpu_up(unsigned int cpu)
{
/* This only works at boot for x86. See "rewrite" above. */
-
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
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] voyager: fix voyager_cat_init section
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix Voyager section mismatches: voyager_cat_init() should be __init.
WARNING: vmlinux.o(.text+0xee83): Section mismatch: reference to
.init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xeea6): Section mismatch: reference to .init.data:
(between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xeeac): Section mismatch: reference to .init.data:
(between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xeeb2): Section mismatch: reference to .init.data:
(between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xef4c): Section mismatch: reference to .init.data:
(between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xef56): Section mismatch: reference to .init.data:
(between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf10f): Section mismatch: reference to
.init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf13b): Section mismatch: reference to .init.data:
(between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf14b): Section mismatch: reference to .init.data:
(between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf159): Section mismatch: reference to .init.data:
(between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf1b1): Section mismatch: reference to
.init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf1bb): Section mismatch: reference to .init.data:
(between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf1c1): Section mismatch: reference to
.init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf1c7): Section mismatch: reference to
.init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf1e6): Section mismatch: reference to .init.data:
(between 'voyager_cat_init' and 'aes_enc_blk')
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
arch/x86/mach-voyager/voyager_cat.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.24-rc2-git2.orig/arch/x86/mach-voyager/voyager_cat.c
+++ linux-2.6.24-rc2-git2/arch/x86/mach-voyager/voyager_cat.c
@@ -568,7 +568,7 @@ static voyager_module_t *voyager_initial
* boot cpu *after* all memory initialisation has been done (so we can
* use kmalloc) but before smp initialisation, so we can probe the SMP
* configuration and pick up necessary information. */
-void
+void __init
voyager_cat_init(void)
{
voyager_module_t **modpp = _initial_module;
-
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
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] voyager: use correct header file name
From: Randy Dunlap <[EMAIL PROTECTED]> Fix header file name for Voyager build. In file included from arch/x86/kernel/setup_32.c:61: include/asm-x86/mach-voyager/setup_arch.h:2:26: error: asm/setup_32.h: No such file or directory make[1]: *** [arch/x86/kernel/setup_32.o] Error 1 Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- include/asm-x86/mach-voyager/setup_arch.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.24-rc2-git2.orig/include/asm-x86/mach-voyager/setup_arch.h +++ linux-2.6.24-rc2-git2/include/asm-x86/mach-voyager/setup_arch.h @@ -1,5 +1,5 @@ #include -#include +#include #define VOYAGER_BIOS_INFO ((struct voyager_bios_info *) \ (_params.apm_bios_info)) - 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 Please read the FAQ at http://www.tux.org/lkml/
[patch] ia64: Guard elfcorehdr_addr with #if CONFIG_PROC_FS
Access to elfcorehdr_addr needs to be guarded by #if CONFIG_PROC_FS
as well as the existing #if guards.
Fixes the following build problem:
arch/ia64/hp/common/built-in.o: In function
`sba_init':arch/ia64/hp/common/sba_iommu.c:2043: undefined reference to
`elfcorehdr_addr'
:arch/ia64/hp/common/sba_iommu.c:2043: undefined reference to `elfcorehdr_addr'
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: net-2.6/arch/ia64/hp/common/sba_iommu.c
===
--- net-2.6.orig/arch/ia64/hp/common/sba_iommu.c2007-11-12
12:49:23.0 +0900
+++ net-2.6/arch/ia64/hp/common/sba_iommu.c 2007-11-12 13:29:07.0
+0900
@@ -2034,7 +2034,8 @@ sba_init(void)
if (!ia64_platform_is("hpzx1") && !ia64_platform_is("hpzx1_swiotlb"))
return 0;
-#if defined(CONFIG_IA64_GENERIC) && defined(CONFIG_CRASH_DUMP)
+#if defined(CONFIG_IA64_GENERIC) && defined(CONFIG_CRASH_DUMP) && \
+defined(CONFIG_PROC_FS)
/* If we are booting a kdump kernel, the sba_iommu will
* cause devices that were not shutdown properly to MCA
* as soon as they are turned back on. Our only option for
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc][patch] remove nopage
On Sun, Nov 11, 2007 at 09:04:29PM -0500, Jeff Garzik wrote:
> Nick Piggin wrote:
> >Index: linux-2.6/sound/oss/via82cxxx_audio.c
> >===
> >--- linux-2.6.orig/sound/oss/via82cxxx_audio.c
> >+++ linux-2.6/sound/oss/via82cxxx_audio.c
> >@@ -2099,8 +2099,7 @@ static void via_dsp_cleanup (struct via_
> > }
> >
> >
> >-static struct page * via_mm_nopage (struct vm_area_struct * vma,
> >-unsigned long address, int *type)
> >+static int via_mm_fault (struct vm_area_struct *vma, struct vm_fault *vmf)
> > {
> > struct via_info *card = vma->vm_private_data;
> > struct via_channel *chan = >ch_out;
> >@@ -2108,22 +2107,14 @@ static struct page * via_mm_nopage (stru
> > unsigned long pgoff;
> > int rd, wr;
> >
> >-DPRINTK ("ENTER, start %lXh, ofs %lXh, pgoff %ld, addr %lXh\n",
> >- vma->vm_start,
> >- address - vma->vm_start,
> >- (address - vma->vm_start) >> PAGE_SHIFT,
> >- address);
> >-
> >-if (address > vma->vm_end) {
> >-DPRINTK ("EXIT, returning NOPAGE_SIGBUS\n");
> >-return NOPAGE_SIGBUS; /* Disallow mremap */
> >-}
> >+DPRINTK ("ENTER, pgoff %ld\n", vmf->pgoff);
> >+
> > if (!card) {
> >-DPRINTK ("EXIT, returning NOPAGE_SIGBUS\n");
> >-return NOPAGE_SIGBUS; /* Nothing allocated */
> >+DPRINTK ("EXIT, returning VM_FAULT_SIGBUS\n");
> >+return VM_FAULT_SIGBUS; /* Nothing allocated */
> > }
> >
> >-pgoff = vma->vm_pgoff + ((address - vma->vm_start) >> PAGE_SHIFT);
> >+pgoff = vmf->pgoff;
> > rd = card->ch_in.is_mapped;
> > wr = card->ch_out.is_mapped;
> >
> >@@ -2150,9 +2141,8 @@ static struct page * via_mm_nopage (stru
> > DPRINTK ("EXIT, returning page %p for cpuaddr %lXh\n",
> > dmapage, (unsigned long) chan->pgtbl[pgoff].cpuaddr);
> > get_page (dmapage);
> >-if (type)
> >-*type = VM_FAULT_MINOR;
> >-return dmapage;
> >+vmf->page = dmapage;
> >+return 0;
> > }
>
>
> Although the overall concept looks nice (ACK, good work), the above
> change does not build. The code continues to reference via_mm_nopage(),
> which has been renamed to via_mm_fault() in your patch.
Ah dang, it was just the .nopage in the same file that I missed.
Fixed. Thanks.
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA eating my disk, port reset, destroying unrelated data
Robert Hancock wrote: > Norbert Preining wrote: >> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 > > Serror 0x40 means a handshake error. Usually Serror indications are > due to a hardware problem (bad SATA cable, power or drive problem). > >> ata1.00: (BMDMA stat 0x25) >> ata1.00: cmd 35/00:00:2a:6f:c0/00:04:0c:00:00/e0 tag 0 cdb 0x0 data >> 524288 out >> res 51/84:10:1a:72:c0/84:01:0c:00:00/e0 Emask 0x10 (ATA bus >> error) And error register value 0x84 - ICRC (CRC error on ATA bus) and ABRT (command abort) - agrees with what SError indicates. You're experiencing transmission errors. >> ata1: soft resetting port >> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) >> ata1.00: configured for UDMA/133 >> ata1: EH complete >> >> Even worse, sometimes the reset does not work ... >> >> ata1: device not ready (errno=-16), forcing hardreset >> ata1: hard resetting port >> ata1 SRST failed (errno=-19) >> ata1: reset failed (errno=-19), retrying in 10 secs >> .. >> >> (typed from a digital photo, nothing remains in the logs) >> >> After this I need to do a cold boot otherwise the drive is really in a >> bad state and not even the bios gets it right. > > If even the BIOS cannot reset properly then that also really points to a > hardware problem.. Also, firmware on some harddrives die solidly when transmission errors occur. Maybe yours is one. There's nothing much the driver can do about both the transmission error and the drive locking up afterward. If the transmission errors occur frequently, the chance is that either your drive or power supply is dying. As for the drive lock up, maybe firmware update will help. * "smartctl -a /dev/sda" might report something interesting. * Connect the drive to different SATA and power connector and see if the problem persists. * Connect the drive to a separate power supply and see if the problem persists. -- tejun - 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 Please read the FAQ at http://www.tux.org/lkml/
[PULL] lguest and virtio fixes
The following changes since commit 6e800af233e0bdf108efb7bd23c11ea6fa34cdeb: Jerome Pinot (1): ACPI: add documentation for deprecated /proc/acpi/battery in ACPI_PROCFS are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-virtio.git for-linus Anthony Liguori (3): virtio: fix vring_init for 64 bits virtio: Fix used_idx wrap-around lguest: Fix lguest virtio-blk backend size computation Rusty Russell (2): virtio: more fallout from scatterlist changes. virtio: Force use of power-of-two for descriptor ring sizes Documentation/lguest/lguest.c | 17 + drivers/lguest/lguest_device.c |3 ++- drivers/net/virtio_net.c |3 +++ drivers/virtio/virtio_ring.c | 10 -- include/linux/virtio_ring.h| 21 - 5 files changed, 34 insertions(+), 20 deletions(-) - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1: pata_amd fails to detect 80-pin wire
Hello, Cable detection has always been broken for pata_amd. Recent changes seem to have broken some other subset tho. The following patchset to get it fixed once and for all is pending. http://thread.gmane.org/gmane.linux.ide/24524 Thanks. -- tejun - 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 Please read the FAQ at http://www.tux.org/lkml/
[PATCH] core dump: remain dumpable
The coredump code always calls set_dumpable(0) when it starts (even
if RLIMIT_CORE prevents any core from being dumped). The effect of
this (via task_dumpable) is to make /proc/pid/* files owned by root
instead of the user, so the user can no longer examine his own
process--in a case where there was never any privileged data to
protect. This affects e.g. auxv, environ, fd; in Fedora (execshield)
kernels, also maps. In practice, you can only notice this when a
debugger has requested PTRACE_EVENT_EXIT tracing.
set_dumpable was only used in do_coredump for synchronization and not
intended for any security purpose. (It doesn't secure anything that wasn't
already unsecured when a process dies by SIGTERM instead of SIGQUIT.)
This changes do_coredump to check the core_waiters count as the means of
synchronization, which is sufficient. Now we leave the "dumpable" bits alone.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
fs/exec.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 2c942e2..3f70c3e 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1692,7 +1692,10 @@ int do_coredump(long signr, int exit_code, struct
pt_regs * regs)
if (!binfmt || !binfmt->core_dump)
goto fail;
down_write(>mmap_sem);
- if (!get_dumpable(mm)) {
+ /*
+* If another thread got here first, or we are not dumpable, bail out.
+*/
+ if (mm->core_waiters || !get_dumpable(mm)) {
up_write(>mmap_sem);
goto fail;
}
@@ -1706,7 +1709,6 @@ int do_coredump(long signr, int exit_code, struct pt_regs
* regs)
flag = O_EXCL; /* Stop rewrite attacks */
current->fsuid = 0; /* Dump root private */
}
- set_dumpable(mm, 0);
retval = coredump_wait(exit_code);
if (retval < 0)
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86
Hi, On Sat, 10 Nov 2007, Sam Ravnborg wrote: > As discussed in another thread the right thing is to add a generic solution > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al. Could you please point me to this discussion? Thanks. bye, Roman - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: iozone write 50% regression in kernel 2.6.24-rc1
On Fri, 2007-11-09 at 10:54 +0100, Peter Zijlstra wrote: > On Fri, 2007-11-09 at 17:47 +0800, Zhang, Yanmin wrote: > > Comparing with 2.6.23, iozone sequential write/rewrite (512M) has 50% > > regression > > in kernel 2.6.24-rc1. 2.6.24-rc2 has the same regression. > > > > My machine has 8 processor cores and 8GB memory. > > > > By bisect, I located patch > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=04fbfdc14e5f48463820d6b9807daa5e9c92c51f. > > > > > > Another behavior: with kernel 2.6.23, if I run iozone for many times after > > rebooting machine, > > the result looks stable. But with 2.6.24-rc1, the first run of iozone got a > > very small result and > > following run has 4Xorig_result. > > So the second run is 4x as fast as the first run? Pls. see below comments. > > > What I reported is the regression of 2nd/3rd run, because first run has > > bigger regression. > > So the 2nd and 3rd run are stable at 50% slower than .23? Almostly. I did more testing today. Pls. see below result list. > > > I also tried to change /proc/sys/vm/dirty_ratio,dirty_backgroud_ratio and > > didn't get improvement. > > Could you try: > > --- > Subject: mm: speed up writeback ramp-up on clean systems I tested kernel 2.6.23, 2,6,24-rc2, 2.6.24-rc2_peter(2.6.24-rc2+this patch). 1) Compare among first/second/following running 2.6.23: second run of iozone will get about 28% improvement than first run. Following run is very stable like 2nd run. 2.6.24-rc2: second run of iozone will get about 170% improvement than first run. 3rd run will get about 80% improvement than 2nd. Following run is very stable like 3rd run. 2.6.24-rc2_peter: second run of iozone will get about 14% improvement than first run. Following run is mostly stable like 2nd run. So the new patch really improves the first run result. Comparing wiht 2.6.24-rc2, 2.6.24-rc2_peter has 330% improvement on the first run. 2) Compare among different kernels(based on the stable highest result): 2.6.24-rc2 has about 50% regression than 2.6.23. 2.6.24-rc2_peter has the same result like 2.6.24-rc2. >From this point of view, above patch has no improvement. :) -yanmin - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc][patch] remove nopage
Nick Piggin wrote:
Index: linux-2.6/sound/oss/via82cxxx_audio.c
===
--- linux-2.6.orig/sound/oss/via82cxxx_audio.c
+++ linux-2.6/sound/oss/via82cxxx_audio.c
@@ -2099,8 +2099,7 @@ static void via_dsp_cleanup (struct via_
}
-static struct page * via_mm_nopage (struct vm_area_struct * vma,
- unsigned long address, int *type)
+static int via_mm_fault (struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct via_info *card = vma->vm_private_data;
struct via_channel *chan = >ch_out;
@@ -2108,22 +2107,14 @@ static struct page * via_mm_nopage (stru
unsigned long pgoff;
int rd, wr;
- DPRINTK ("ENTER, start %lXh, ofs %lXh, pgoff %ld, addr %lXh\n",
-vma->vm_start,
-address - vma->vm_start,
-(address - vma->vm_start) >> PAGE_SHIFT,
-address);
-
-if (address > vma->vm_end) {
- DPRINTK ("EXIT, returning NOPAGE_SIGBUS\n");
- return NOPAGE_SIGBUS; /* Disallow mremap */
- }
+ DPRINTK ("ENTER, pgoff %ld\n", vmf->pgoff);
+
if (!card) {
- DPRINTK ("EXIT, returning NOPAGE_SIGBUS\n");
- return NOPAGE_SIGBUS; /* Nothing allocated */
+ DPRINTK ("EXIT, returning VM_FAULT_SIGBUS\n");
+ return VM_FAULT_SIGBUS; /* Nothing allocated */
}
- pgoff = vma->vm_pgoff + ((address - vma->vm_start) >> PAGE_SHIFT);
+ pgoff = vmf->pgoff;
rd = card->ch_in.is_mapped;
wr = card->ch_out.is_mapped;
@@ -2150,9 +2141,8 @@ static struct page * via_mm_nopage (stru
DPRINTK ("EXIT, returning page %p for cpuaddr %lXh\n",
dmapage, (unsigned long) chan->pgtbl[pgoff].cpuaddr);
get_page (dmapage);
- if (type)
- *type = VM_FAULT_MINOR;
- return dmapage;
+ vmf->page = dmapage;
+ return 0;
}
Although the overall concept looks nice (ACK, good work), the above
change does not build. The code continues to reference via_mm_nopage(),
which has been renamed to via_mm_fault() in your patch.
Jeff
-
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
Please read the FAQ at http://www.tux.org/lkml/
[rfc][patch] remove nopage
Hi all,
This is a patch to remove 'nopage' from the tree.
I've gone through all the drivers and converted them to use fault as best
I can. When using fault, I've also tried to use vmf->pgoff rather than the
virtual address to find the page (which is much preferred). Mostly it has
been OK, but DRM is a bit difficult, as it seems to use vma->vm_pgoff as
a 2nd dimension of addressing.
I've also done some other things while going through at the code...
Converted incorrect OOM returns to SIGBUS. OOM should only be returned as a
result of a memory allocation failure. We will actually want the fault path OOM
handling to be unified with the normal OOM killing path in future, and that
means the box will panic if panic_on_oom is set, or it will oom-kill random
processes before retrying the fault, etc. SIGBUS means something like
"physical address (ie. after translation) does not exist", which is appropriate
AFAIKS in all cases (but please double check).
Got rid of some bogus looking "disallow mremap" checks that just check for
address > vma->vm_end. Am I missing something here? Presumably this is supposed
to prevent an mremap expanding the mapping outside the limit of the underlying
resource, but actually mremap will update vma->vm_end, and anyway this
condition is already checked in the page fault code. Others seem to get this
right by checking the underlying resource itself. Others don't seem to even
care. Might be a fair window for corruption / security problems here. Probably
we need a flag that explicitly prevents mremap() so driver writers don't have
to think too hard.
Now all these are going to need to be split up properly, but if we can
take a look at this all together, the discussion will be more coherent ;)
---
Documentation/fb/deferred_io.txt |6 -
Documentation/feature-removal-schedule.txt |9 -
Documentation/filesystems/Locking|3
arch/ia64/ia32/binfmt_elf32.c| 34 +++
drivers/char/agp/alpha-agp.c | 17 +--
drivers/char/drm/drm_vm.c| 131 ---
drivers/ieee1394/dma.c | 39 +++-
drivers/infiniband/hw/ipath/ipath_file_ops.c | 29 ++---
drivers/kvm/kvm_main.c | 38 ++-
drivers/media/video/videobuf-dma-sg.c| 20 +---
drivers/scsi/sg.c| 23 ++--
drivers/uio/uio.c| 14 +-
drivers/usb/mon/mon_bin.c| 16 +--
drivers/video/fb_defio.c | 17 +--
include/linux/mm.h |8 -
kernel/relay.c | 24 +---
mm/memory.c | 22 +---
mm/mincore.c |2
mm/mmap.c| 19 +--
mm/rmap.c|1
sound/core/pcm_native.c | 59 +---
sound/oss/via82cxxx_audio.c | 26 +
sound/usb/usx2y/usX2Yhwdep.c | 21 +---
sound/usb/usx2y/usx2yhwdeppcm.c | 19 +--
24 files changed, 238 insertions(+), 359 deletions(-)
Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -162,8 +162,6 @@ struct vm_operations_struct {
void (*open)(struct vm_area_struct * area);
void (*close)(struct vm_area_struct * area);
int (*fault)(struct vm_area_struct *vma, struct vm_fault *vmf);
- struct page *(*nopage)(struct vm_area_struct *area,
- unsigned long address, int *type);
unsigned long (*nopfn)(struct vm_area_struct *area,
unsigned long address);
@@ -611,12 +609,6 @@ static inline int page_mapped(struct pag
}
/*
- * Error return values for the *_nopage functions
- */
-#define NOPAGE_SIGBUS (NULL)
-#define NOPAGE_OOM ((struct page *) (-1))
-
-/*
* Error return values for the *_nopfn functions
*/
#define NOPFN_SIGBUS ((unsigned long) -1)
Index: linux-2.6/kernel/relay.c
===
--- linux-2.6.orig/kernel/relay.c
+++ linux-2.6/kernel/relay.c
@@ -37,37 +37,31 @@ static void relay_file_mmap_close(struct
}
/*
- * nopage() vm_op implementation for relay file mapping.
+ * fault() vm_op implementation for relay file mapping.
*/
-static struct page *relay_buf_nopage(struct vm_area_struct *vma,
-unsigned long address,
-int *type)
+static int relay_buf_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct page *page;
struct rchan_buf *buf = vma->vm_private_data;
- unsigned long offset = address - vma->vm_start;
+ pgoff_t pgoff = vmf->pgoff;
- if (address > vma->vm_end)
- return
[PATCH] IA64 efi: make full use of macro efi_md_size
Macro efi_md_size is defined in efi.c, and here we apply it
throughout efi.c.
Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
---
arch/ia64/kernel/efi.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 0e4ef20..7392d7b 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -369,7 +369,7 @@ efi_get_pal_addr (void)
continue;
}
- if (md->num_pages << EFI_PAGE_SHIFT > IA64_GRANULE_SIZE)
+ if (efi_md_size(md) > IA64_GRANULE_SIZE)
panic("Woah! PAL code size bigger than a granule!");
#if EFI_DEBUG
@@ -377,7 +377,7 @@ efi_get_pal_addr (void)
printk(KERN_INFO "CPU %d: mapping PAL code [0x%lx-0x%lx) into
[0x%lx-0x%lx)\n",
smp_processor_id(), md->phys_addr,
- md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
+ md->phys_addr + efi_md_size(md),
vaddr & mask, (vaddr & mask) + IA64_GRANULE_SIZE);
#endif
return __va(md->phys_addr);
@@ -522,7 +522,7 @@ efi_init (void)
md = p;
printk("mem%02u: type=%u, attr=0x%lx,
range=[0x%016lx-0x%016lx) (%luMB)\n",
i, md->type, md->attribute, md->phys_addr,
- md->phys_addr + (md->num_pages <<
EFI_PAGE_SHIFT),
+ md->phys_addr + efi_md_size(md),
md->num_pages >> (20 - EFI_PAGE_SHIFT));
}
}
@@ -655,7 +655,7 @@ efi_memory_descriptor (unsigned long phys_addr)
for (p = efi_map_start; p < efi_map_end; p += efi_desc_size) {
md = p;
- if (phys_addr - md->phys_addr < (md->num_pages <<
EFI_PAGE_SHIFT))
+ if (phys_addr - md->phys_addr < efi_md_size(md))
return md;
}
return NULL;
@@ -1159,7 +1159,7 @@ efi_initialize_iomem_resources(struct resource
*code_resource,
res->name = name;
res->start = md->phys_addr;
- res->end = md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) -
1;
+ res->end = md->phys_addr + efi_md_size(md) - 1;
res->flags = flags;
if (insert_resource(_resource, res) < 0)
--
1.5.3.rc7
-
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
Please read the FAQ at http://www.tux.org/lkml/
Could you please merge the x86_64 EFI boot support patchset?
Hi, Linus, Could you please merge the following patchset: [PATCH 0/2 -v3] x86_64 EFI boot support [PATCH 1/2 -v3] x86_64 EFI boot support: EFI frame buffer driver [PATCH 2/2 -v3] x86_64 EFI boot support: EFI boot document The patchset has been in -mm tree from 2.6.23-rc2-mm2 on. Andrew Moton had suggested it to be merged into 2.6.24 during early merge window of 2.6.24. It was not merged because the 32-bit boot protocol had not been done at that time. Now, the 32-bit boot protocol has been merged into 2.6.24. And this patch has been in x86 patch queue. I know that it is a little late for this patchset to be merged into 2.6.24. But this patchset is very simple, just adds a framebuffer driver, so it is impossible for this patchset to break anything. And this patchset will be helpful for people have machine with UEFI 64 firmware instead of legacy BIOS. Best Regards, Huang Ying - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi: Remove unnecessary code in iwl3945 and iwl4965 drivers
On Sat, 2007-11-10 at 20:49 +0100, Miguel Botón wrote: > Remove unnecesary code in iwl3945 and iwl4965 drivers. > > "final_mode" variable is already initialized with the value of the > "mode" variable. > > Signed-off-by: Miguel Boton <[EMAIL PROTECTED]> ACK. Or you can do "u32 uninitialized_var(final_mode);". Both are OK with me. Thanks, -yi - 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 Please read the FAQ at http://www.tux.org/lkml/
[PATCH] SCSI: Fix bugs and canonicalize irq handler usage in NCR5380 drivers
* Always pass the same value to free_irq() that we pass to
request_irq(). This fixes several bugs.
* Always call NCR5380_intr() with 'irq' and 'dev_id' arguments.
Note, scsi_falcon_intr() is the only case now where dev_id is not the
scsi_host.
* Always pass Scsi_Host to request_irq(). For most cases, the drivers
already did so, and I merely neated the source code line. In other
cases, either NULL or a non-sensical value was passed, verified to be
unused, then changed to be Scsi_Host in anticipation of the future.
In addition to the bugs fixes, this change makes the interface usage
consistent, which in turn enables the possibility of directly
referencing Scsi_Host from all NCR5380_intr() invocations.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
Resend #1. Originally sent on Oct 26.
Please send upstream for 2.6.24-rc in some form, this fixes obvious
free_irq() problems that prevent irq release.
drivers/scsi/atari_scsi.c| 10 +-
drivers/scsi/dtc.c |5 +++--
drivers/scsi/g_NCR5380.c |5 +++--
drivers/scsi/mac_scsi.c |4 ++--
drivers/scsi/pas16.c |5 +++--
drivers/scsi/sun3_scsi.c |4 ++--
drivers/scsi/sun3_scsi_vme.c |4 ++--
drivers/scsi/t128.c |5 +++--
8 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index 6f8403b..f5732d8 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -393,7 +393,7 @@ static irqreturn_t scsi_tt_intr(int irq, void *dummy)
#endif /* REAL_DMA */
- NCR5380_intr(0, 0);
+ NCR5380_intr(irq, dummy);
#if 0
/* To be sure the int is not masked */
@@ -458,7 +458,7 @@ static irqreturn_t scsi_falcon_intr(int irq, void *dummy)
#endif /* REAL_DMA */
- NCR5380_intr(0, 0);
+ NCR5380_intr(irq, dummy);
return IRQ_HANDLED;
}
@@ -684,7 +684,7 @@ int atari_scsi_detect(struct scsi_host_template *host)
* interrupt after having cleared the pending flag for the DMA
* interrupt. */
if (request_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr, IRQ_TYPE_SLOW,
-"SCSI NCR5380", scsi_tt_intr)) {
+"SCSI NCR5380", instance)) {
printk(KERN_ERR "atari_scsi_detect: cannot allocate irq
%d, aborting",IRQ_TT_MFP_SCSI);
scsi_unregister(atari_scsi_host);
atari_stram_free(atari_dma_buffer);
@@ -701,7 +701,7 @@ int atari_scsi_detect(struct scsi_host_template *host)
IRQ_TYPE_PRIO, "Hades DMA emulator",
hades_dma_emulator)) {
printk(KERN_ERR "atari_scsi_detect: cannot
allocate irq %d, aborting (MACH_IS_HADES)",IRQ_AUTO_2);
- free_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr);
+ free_irq(IRQ_TT_MFP_SCSI, instance);
scsi_unregister(atari_scsi_host);
atari_stram_free(atari_dma_buffer);
atari_dma_buffer = 0;
@@ -761,7 +761,7 @@ int atari_scsi_detect(struct scsi_host_template *host)
int atari_scsi_release(struct Scsi_Host *sh)
{
if (IS_A_TT())
- free_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr);
+ free_irq(IRQ_TT_MFP_SCSI, sh);
if (atari_dma_buffer)
atari_stram_free(atari_dma_buffer);
return 1;
diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
index 2596165..c2677ba 100644
--- a/drivers/scsi/dtc.c
+++ b/drivers/scsi/dtc.c
@@ -277,7 +277,8 @@ found:
/* With interrupts enabled, it will sometimes hang when doing
heavy
* reads. So better not enable them until I finger it out. */
if (instance->irq != SCSI_IRQ_NONE)
- if (request_irq(instance->irq, dtc_intr, IRQF_DISABLED,
"dtc", instance)) {
+ if (request_irq(instance->irq, dtc_intr, IRQF_DISABLED,
+ "dtc", instance)) {
printk(KERN_ERR "scsi%d : IRQ%d not free,
interrupts disabled\n", instance->host_no, instance->irq);
instance->irq = SCSI_IRQ_NONE;
}
@@ -459,7 +460,7 @@ static int dtc_release(struct Scsi_Host *shost)
NCR5380_local_declare();
NCR5380_setup(shost);
if (shost->irq)
- free_irq(shost->irq, NULL);
+ free_irq(shost->irq, shost);
NCR5380_exit(shost);
if (shost->io_port && shost->n_io_port)
release_region(shost->io_port, shost->n_io_port);
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 607336f..75585a5 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -460,7 +460,8 @@ int __init
Re: [PATCH] Fix problem with size of allocation in libsas
On 12/11/2007, James Bottomley <[EMAIL PROTECTED]> wrote: > On Mon, 2007-11-12 at 01:13 +0100, Jesper Juhl wrote: > > On 12/11/2007, James Bottomley <[EMAIL PROTECTED]> wrote: > > > On Mon, 2007-11-12 at 00:24 +0100, Jesper Juhl wrote: > > > > From: Jesper Juhl <[EMAIL PROTECTED]> > > > > > > > > in sas_get_phy_change_count(), the line > > > > disc_resp = alloc_smp_resp(DISCOVER_RESP_SIZE); > > > > will allocate 56 bytes due to this define: > > > > #define DISCOVER_RESP_SIZE 56 > > > > But, the struct is actually 60 bytes in size. > > > > > > > > So change the define to be > > > > #define DISCOVER_RESP_SIZE sizeof(struct smp_resp) > > > > so we always get the correct size even when people > > > > fiddle with the structure. > > > > > > > > This change also fixes the same problem in > > > > sas_get_phy_attached_sas_addr() > > > > > > > > (Found by the Coverity checker. Compile tested only) > > > > > > Well, your fix is definitely wrong. > > > > > > Could you explain the problem a little more? The discover response SMP > > > frame is 56 bytes as mandated by the standard. I don't see anywhere in > > > the code where we're actually using a value beyond the 56th byte ... > > > where is the problem use? > > > > > > > I haven't found any actual problem *use*, I just looked at the size of > > 'struct smp_resp' and noticed that coverity seemed to be right that 56 > > bytes are not sufficient to hold the members of the struct. > > There are 11 current (well, as of the 1.1 standard) SMP frame responses. > Each of them is actually a different length. This driver treats SMP > frame response underruns as errors, so the fix you propose would cause > the whole discovery process to collapse. > > > There are > > 32 bytes in the first members + the union and I don't see how that can > > ever stay at 56 bytes...? So, we are allocating memory and storing it > > in a 'struct smp_resp *', but we are allocating less than > > sizeof(smp_resp) - how is that not a (potential) problem? > > We're not storing anything. We're allocating a byte area for the driver > to deposit a response frame, we know we just sent a SMP DISCOVER > request, so we'd better get a discover response back (and the driver > will error on underrun or overrun, so we know if it returns successfully > that's exatly what we have). The struct smp_resp contains the SMP > invariant header and then a union of all the other response data types, > so as long as we use either the header or the disc piece of the union, > there's no possibility of error, is there? > No, as long as the driver will err on underrun and overrun (of 56 bytes) and we only use those parts of the structure that lie within the first 56 bytes, then I don't see how it could fail. But it still makes the hairs on the back of my head stand on end to see memory allocated, and pointed to by a "struct foo *", that is less than "sizeof(struct foo)"... -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: iozone write 50% regression in kernel 2.6.24-rc1
On Fri, 2007-11-09 at 04:36 -0800, Martin Knoblauch wrote: > - Original Message > > From: "Zhang, Yanmin" <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Cc: LKML > > Sent: Friday, November 9, 2007 10:47:52 AM > > Subject: iozone write 50% regression in kernel 2.6.24-rc1 > > > > Comparing with 2.6.23, iozone sequential write/rewrite (512M) has > > 50% > > > regression > > in kernel 2.6.24-rc1. 2.6.24-rc2 has the same regression. > > > > My machine has 8 processor cores and 8GB memory. > > > > By bisect, I located patch > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h= > > 04fbfdc14e5f48463820d6b9807daa5e9c92c51f. > > > > > > Another behavior: with kernel 2.6.23, if I run iozone for many > > times > > > after rebooting machine, > > the result looks stable. But with 2.6.24-rc1, the first run of > > iozone > > > got a very small result and > > following run has 4Xorig_result. > > > > What I reported is the regression of 2nd/3rd run, because first run > > has > > > bigger regression. > > > > I also tried to change > > /proc/sys/vm/dirty_ratio,dirty_backgroud_ratio > > > and didn't get improvement. > could you tell us the exact iozone command you are using? iozone -i 0 -r 4k -s 512m > I would like to repeat it on my setup, because I definitely see the opposite > behaviour in 2.6.24-rc1/rc2. The speed there is much better than in 2.6.22 > and before (I skipped 2.6.23, because I was waiting for the per-bdi changes). > I definitely do not see the difference between 1st and subsequent runs. But > then, I do my tests with 5GB file sizes like: > > iozone3_283/src/current/iozone -t 5 -F /scratch/X1 /scratch/X2 /scratch/X3 > /scratch/X4 /scratch/X5 -s 5000M -r 1024 -c -e -i 0 -i 1 My machine uses SATA (AHCI) disk. -yanmin - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix problem with size of allocation in libsas
On Sun, 2007-11-11 at 19:33 -0500, Douglas Gilbert wrote: > James Bottomley wrote: > > On Mon, 2007-11-12 at 00:24 +0100, Jesper Juhl wrote: > >> From: Jesper Juhl <[EMAIL PROTECTED]> > >> > >> in sas_get_phy_change_count(), the line > >>disc_resp = alloc_smp_resp(DISCOVER_RESP_SIZE); > >> will allocate 56 bytes due to this define: > >>#define DISCOVER_RESP_SIZE 56 > >> But, the struct is actually 60 bytes in size. > >> > >> So change the define to be > >>#define DISCOVER_RESP_SIZE sizeof(struct smp_resp) > >> so we always get the correct size even when people > >> fiddle with the structure. > >> > >> This change also fixes the same problem in > >> sas_get_phy_attached_sas_addr() > >> > >> (Found by the Coverity checker. Compile tested only) > > > > Well, your fix is definitely wrong. > > > > Could you explain the problem a little more? The discover response SMP > > frame is 56 bytes as mandated by the standard. I don't see anywhere in > > the code where we're actually using a value beyond the 56th byte ... > > where is the problem use? > > The response size of SMP DISCOVER keeps growing with > each rev. Currently in SAS-2 revision 12 it is 112 bytes long! > The original SAS standard and SAS 1.1 have implicit response > sizes and for DISCOVER that is 56 bytes. > > To be compliant with SAS-2 the code should read byte 3 of > a DISCOVER response. If it is zero then the response length > is 56 bytes, otherwise the response length is that many > dwords (i.e. 4 byte units) plus 4 bytes for the CRC. > [Similar logic applies to many other SMP responses.] > > I have tables for all SMP requests and response (up until > SAS-2 rev 12) in my smp_utils package, see the smp_lib.c > file. Right at the moment, we're requiring the 1.1 56 byte response because the request has byte three zeroed (sas 2 requires responders to return the 1.1 response frame in this case). I suppose if we ever need to do zoning, there might be a case to move to larger sizes, but at the moment it would just tell us about features we're not using anyway (plus we're bound to confuse some older expanders). James - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel panic at boot with ondemand governor as default (2.6.24-rc2)
2007年11月11日 23:45, Arjan van de Ven wrote/a écrit: On Sun, 11 Nov 2007 20:10:23 +0100 Eric Piel <[EMAIL PROTECTED]> wrote: Hello, I've tried kernel 2.6.24-rc2 and I have a problem with the new option for setting up the cpufreq ondemand governor as default: a kernel panic happens early at boot time. If I boot first with performance governor and later change to ondemand, everything is fine (as usual). This seems related to the delayed_workqueue. The kernel panic message finishes by: EIP: [] wq_per_cpu+0x0/0x10 SS:ESP 0068:c191be58 Kernel panic - not syncing: Attempted to kill init! A picture of the whole message is available here: http://pieleric.free.fr/unorder/1162-ondemand-panic.jpg My computer is a x86 using speedstep-ich, and you can find the full .config leading to the panic attached. has ondemand ever worked for you? Yes, ondemand works perfectly fine on this computer. The panic happens only if selecting it as the _default_ governor (which has been introduced by commit 1c2562459faedc35927546cfa5273ec6c2884cce). Eric - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix problem with size of allocation in libsas
On Mon, 2007-11-12 at 01:13 +0100, Jesper Juhl wrote: > On 12/11/2007, James Bottomley <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-11-12 at 00:24 +0100, Jesper Juhl wrote: > > > From: Jesper Juhl <[EMAIL PROTECTED]> > > > > > > in sas_get_phy_change_count(), the line > > > disc_resp = alloc_smp_resp(DISCOVER_RESP_SIZE); > > > will allocate 56 bytes due to this define: > > > #define DISCOVER_RESP_SIZE 56 > > > But, the struct is actually 60 bytes in size. > > > > > > So change the define to be > > > #define DISCOVER_RESP_SIZE sizeof(struct smp_resp) > > > so we always get the correct size even when people > > > fiddle with the structure. > > > > > > This change also fixes the same problem in > > > sas_get_phy_attached_sas_addr() > > > > > > (Found by the Coverity checker. Compile tested only) > > > > Well, your fix is definitely wrong. > > > > Could you explain the problem a little more? The discover response SMP > > frame is 56 bytes as mandated by the standard. I don't see anywhere in > > the code where we're actually using a value beyond the 56th byte ... > > where is the problem use? > > > > I haven't found any actual problem *use*, I just looked at the size of > 'struct smp_resp' and noticed that coverity seemed to be right that 56 > bytes are not sufficient to hold the members of the struct. There are 11 current (well, as of the 1.1 standard) SMP frame responses. Each of them is actually a different length. This driver treats SMP frame response underruns as errors, so the fix you propose would cause the whole discovery process to collapse. > There are > 32 bytes in the first members + the union and I don't see how that can > ever stay at 56 bytes...? So, we are allocating memory and storing it > in a 'struct smp_resp *', but we are allocating less than > sizeof(smp_resp) - how is that not a (potential) problem? We're not storing anything. We're allocating a byte area for the driver to deposit a response frame, we know we just sent a SMP DISCOVER request, so we'd better get a discover response back (and the driver will error on underrun or overrun, so we know if it returns successfully that's exatly what we have). The struct smp_resp contains the SMP invariant header and then a union of all the other response data types, so as long as we use either the header or the disc piece of the union, there's no possibility of error, is there? James - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix problem with size of allocation in libsas
James Bottomley wrote: > On Mon, 2007-11-12 at 00:24 +0100, Jesper Juhl wrote: >> From: Jesper Juhl <[EMAIL PROTECTED]> >> >> in sas_get_phy_change_count(), the line >> disc_resp = alloc_smp_resp(DISCOVER_RESP_SIZE); >> will allocate 56 bytes due to this define: >> #define DISCOVER_RESP_SIZE 56 >> But, the struct is actually 60 bytes in size. >> >> So change the define to be >> #define DISCOVER_RESP_SIZE sizeof(struct smp_resp) >> so we always get the correct size even when people >> fiddle with the structure. >> >> This change also fixes the same problem in >> sas_get_phy_attached_sas_addr() >> >> (Found by the Coverity checker. Compile tested only) > > Well, your fix is definitely wrong. > > Could you explain the problem a little more? The discover response SMP > frame is 56 bytes as mandated by the standard. I don't see anywhere in > the code where we're actually using a value beyond the 56th byte ... > where is the problem use? The response size of SMP DISCOVER keeps growing with each rev. Currently in SAS-2 revision 12 it is 112 bytes long! The original SAS standard and SAS 1.1 have implicit response sizes and for DISCOVER that is 56 bytes. To be compliant with SAS-2 the code should read byte 3 of a DISCOVER response. If it is zero then the response length is 56 bytes, otherwise the response length is that many dwords (i.e. 4 byte units) plus 4 bytes for the CRC. [Similar logic applies to many other SMP responses.] I have tables for all SMP requests and response (up until SAS-2 rev 12) in my smp_utils package, see the smp_lib.c file. Doug Gilbert - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: PCI card initialisation at boot
Matt Domsch wrote: On Sun, Nov 11, 2007 at 04:46:44PM +, Alan Cox wrote: Linux by default uses the BIOS resource assignments. It doesn't know where those came from other than "the BIOS". Slightly tangential, but I'm starting to hear requests to have the OS re-assign resources when it might make better sense. For example, if you have a graphics card with a 1GB memory allocation, the BIOS may assign it into address ranges below 4GB because it doesn't know if the OS will be 32-bit or 64-bit capable. But, it would be beneficial to have it located above 4GB, and to fill in the (new) hole below 4GB with RAM. Linux right now doesn't have a way to do this. It will assign resources for cards that the BIOS left unassigned, but won't intentionally move resources. Not really. If the OS is 64-bit capable, it can just use the RAM above 4 GB. -hpa - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix problem with size of allocation in libsas
On 12/11/2007, James Bottomley <[EMAIL PROTECTED]> wrote: > On Mon, 2007-11-12 at 00:24 +0100, Jesper Juhl wrote: > > From: Jesper Juhl <[EMAIL PROTECTED]> > > > > in sas_get_phy_change_count(), the line > > disc_resp = alloc_smp_resp(DISCOVER_RESP_SIZE); > > will allocate 56 bytes due to this define: > > #define DISCOVER_RESP_SIZE 56 > > But, the struct is actually 60 bytes in size. > > > > So change the define to be > > #define DISCOVER_RESP_SIZE sizeof(struct smp_resp) > > so we always get the correct size even when people > > fiddle with the structure. > > > > This change also fixes the same problem in > > sas_get_phy_attached_sas_addr() > > > > (Found by the Coverity checker. Compile tested only) > > Well, your fix is definitely wrong. > > Could you explain the problem a little more? The discover response SMP > frame is 56 bytes as mandated by the standard. I don't see anywhere in > the code where we're actually using a value beyond the 56th byte ... > where is the problem use? > I haven't found any actual problem *use*, I just looked at the size of 'struct smp_resp' and noticed that coverity seemed to be right that 56 bytes are not sufficient to hold the members of the struct. There are 32 bytes in the first members + the union and I don't see how that can ever stay at 56 bytes...? So, we are allocating memory and storing it in a 'struct smp_resp *', but we are allocating less than sizeof(smp_resp) - how is that not a (potential) problem? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Let 'make help' output info about includecheck
From: Jesper Juhl <[EMAIL PROTECTED]> 'make includecheck' is useful and we want people to run it, so let 'make help' output information about its existence. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index e28dde8..2e5eba0 100644 --- a/Makefile +++ b/Makefile @@ -1181,6 +1181,7 @@ help: @echo '' @echo 'Static analysers' @echo ' checkstack - Generate a list of stack hogs' + @echo ' includecheck- Generate a list of files with duplicate header includes' @echo ' namespacecheck - Name space analysis on compiled kernel' @echo ' export_report - List the usages of all exported symbols' @if [ -r $(srctree)/include/asm-$(SRCARCH)/Kbuild ]; then \ - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix problem with size of allocation in libsas
On Mon, 2007-11-12 at 00:24 +0100, Jesper Juhl wrote: > From: Jesper Juhl <[EMAIL PROTECTED]> > > in sas_get_phy_change_count(), the line > disc_resp = alloc_smp_resp(DISCOVER_RESP_SIZE); > will allocate 56 bytes due to this define: > #define DISCOVER_RESP_SIZE 56 > But, the struct is actually 60 bytes in size. > > So change the define to be > #define DISCOVER_RESP_SIZE sizeof(struct smp_resp) > so we always get the correct size even when people > fiddle with the structure. > > This change also fixes the same problem in > sas_get_phy_attached_sas_addr() > > (Found by the Coverity checker. Compile tested only) Well, your fix is definitely wrong. Could you explain the problem a little more? The discover response SMP frame is 56 bytes as mandated by the standard. I don't see anywhere in the code where we're actually using a value beyond the 56th byte ... where is the problem use? James - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: PCI card initialisation at boot
On Sun, Nov 11, 2007 at 04:46:44PM +, Alan Cox wrote: > Linux by default uses the BIOS resource assignments. It doesn't know > where those came from other than "the BIOS". Slightly tangential, but I'm starting to hear requests to have the OS re-assign resources when it might make better sense. For example, if you have a graphics card with a 1GB memory allocation, the BIOS may assign it into address ranges below 4GB because it doesn't know if the OS will be 32-bit or 64-bit capable. But, it would be beneficial to have it located above 4GB, and to fill in the (new) hole below 4GB with RAM. Linux right now doesn't have a way to do this. It will assign resources for cards that the BIOS left unassigned, but won't intentionally move resources. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Bind mount bug?
On Sunday 11 November 2007, Jan Engelhardt wrote: > >This mounts the bindtest/ tree on test/ _without_ copying the mount > >points which are found on subtrees. This is necessary to avoid loops > >in the filesystem (bind mounts are somewhat like hardlinks on > >directories, just without the headaches). > > What you seek is mount --rbind. Thanks! That works fine with mount from util-linux-ng. Busybox' mount (at least Debian's admittedly old 1.1.3 version) seems to fail to do the recursing. I'll file a BR against busybox in Debian and check that again when we have a more current version. - 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 Please read the FAQ at http://www.tux.org/lkml/
mm_release() call in exit_mm() looks dangerous
In kernel/exit.c we have this code :
static void exit_mm(struct task_struct * tsk)
{
struct mm_struct *mm = tsk->mm;
mm_release(tsk, mm);
if (!mm)
return;
...
But, mm_release() may dereference it's second argument ('mm'), so
shouldn't we be doing the "!mm" test *before* we call mm_release() and
not after?
I don't know the mm code well enough to be able to tell if some of the
other stuff mm_release does needs to be done always and the mm
dereference can't actually happen, but maybe someone else who knows
the code better can tell... In any case, what's currently there looks
a little shaky..
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix problem with size of allocation in libsas
From: Jesper Juhl <[EMAIL PROTECTED]> in sas_get_phy_change_count(), the line disc_resp = alloc_smp_resp(DISCOVER_RESP_SIZE); will allocate 56 bytes due to this define: #define DISCOVER_RESP_SIZE 56 But, the struct is actually 60 bytes in size. So change the define to be #define DISCOVER_RESP_SIZE sizeof(struct smp_resp) so we always get the correct size even when people fiddle with the structure. This change also fixes the same problem in sas_get_phy_attached_sas_addr() (Found by the Coverity checker. Compile tested only) Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- sas_expander.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c index 8727436..a666cb1 100644 --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -211,7 +211,7 @@ static void sas_set_ex_phy(struct domain_device *dev, int phy_id, } #define DISCOVER_REQ_SIZE 16 -#define DISCOVER_RESP_SIZE 56 +#define DISCOVER_RESP_SIZE sizeof(struct smp_resp) static int sas_ex_phy_discover_helper(struct domain_device *dev, u8 *disc_req, u8 *disc_resp, int single) - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] markers: modpost
* David Smith ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> > Hrm, what would happen if a gcc optimization eventually decides to mix
> > the memory layout of the strings ? Is there something that specifies
> > that they won't ?
>
> Here's another patch that Roland wrote and I tested that
> attempts to solve the potential problem of string ordering
> by merging the name and format strings.
>
Yup, it looks good. I'll give it a try.
Thanks!
Mathieu
> ---
> This adds some new magic in the MODPOST phase for CONFIG_MARKERS.
> Analogous to the Module.symvers file, the build will now write a
> Module.markers file when CONFIG_MARKERS=y is set. This file lists
> the name, defining module, and format string of each marker,
> separated by \t characters. This simple text file can be used by
> offline build procedures for instrumentation code, analogous to
> how System.map and Module.symvers can be useful to have for
> kernels other than the one you are running right now.
>
> The strings are made easy to extract by having the __trace_mark macro
> define the name and format together in a single array called __mstrtab_*
> in the __markers_strings section. This is straightforward and reliable
> as long as the marker structs are always defined by this macro. It is
> an unreasonable amount of hairy work to extract the string pointers from
> the __markers section structs, which entails handling a relocation type
> for every machine under the sun.
>
> Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
> ---
> include/linux/marker.h |9 +--
> scripts/Makefile.modpost | 11 +++
> scripts/mod/modpost.c| 163
> +-
> scripts/mod/modpost.h|3 +
> 4 files changed, 179 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/marker.h b/include/linux/marker.h
> index 5f36cf9..b978bbe 100644
> --- a/include/linux/marker.h
> +++ b/include/linux/marker.h
> @@ -51,15 +51,12 @@ struct marker {
> */
> #define __trace_mark(generic, name, call_data, format, args...)
> \
> do {\
> - static const char __mstrtab_name_##name[] \
> + static const char __mstrtab_##name[]\
> __attribute__((section("__markers_strings"))) \
> - = #name;\
> - static const char __mstrtab_format_##name[] \
> - __attribute__((section("__markers_strings"))) \
> - = format; \
> + = #name "\0" format;\
> static struct marker __mark_##name \
> __attribute__((section("__markers"), aligned(8))) = \
> - { __mstrtab_name_##name, __mstrtab_format_##name, \
> + { __mstrtab_##name, &__mstrtab_##name[sizeof(#name)], \
> 0, __mark_empty_function, NULL }; \
> __mark_check_format(format, ## args); \
> if (!generic) { \
> diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
> index d988f5d..6321870 100644
> --- a/scripts/Makefile.modpost
> +++ b/scripts/Makefile.modpost
> @@ -13,6 +13,7 @@
> # 2) modpost is then used to
> # 3) create one .mod.c file pr. module
> # 4) create one Module.symvers file with CRC for all exported symbols
> +# 4a) [CONFIG_MARKERS] create one Module.markers file listing defined markers
> # 5) compile all .mod.c files
> # 6) final link of the module to a file
>
> @@ -45,6 +46,10 @@ include scripts/Makefile.lib
>
> kernelsymfile := $(objtree)/Module.symvers
> modulesymfile := $(firstword $(KBUILD_EXTMOD))/Module.symvers
> +kernelmarkersfile := $(objtree)/Module.markers
> +modulemarkersfile := $(firstword $(KBUILD_EXTMOD))/Module.markers
> +
> +markersfile = $(if
> $(KBUILD_EXTMOD),$(modulemarkersfile),$(kernelmarkersfile))
>
> # Step 1), find all modules listed in $(MODVERDIR)/
> __modules := $(sort $(shell grep -h '\.ko' /dev/null $(wildcard
> $(MODVERDIR)/*.mod)))
> @@ -62,6 +67,8 @@ modpost = scripts/mod/modpost\
> $(if $(KBUILD_EXTMOD),-i,-o) $(kernelsymfile) \
> $(if $(KBUILD_EXTMOD),-I $(modulesymfile)) \
> $(if $(KBUILD_EXTMOD),-o $(modulesymfile)) \
> + $(if $(CONFIG_MARKERS),-K $(kernelmarkersfile)) \
> + $(if $(CONFIG_MARKERS),-M $(markersfile))\
> $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w)
>
> quiet_cmd_modpost = MODPOST $(words $(filter-out vmlinux FORCE, $^)) modules
> @@ -81,6 +88,10 @@ vmlinux.o: FORCE
> $(symverfile): __modpost ;
> $(modules:.ko=.mod.c): __modpost ;
>
> +ifdef CONFIG_MARKERS
> +$(markersfile): __modpost ;
> +endif
> +
>
> # Step 5), compile all *.mod.c files
>
[PATCH] Fix memory leak in discard case of sctp_sf_abort_violation()
From: Jesper Juhl <[EMAIL PROTECTED]>
In net/sctp/sm_statefuns.c::sctp_sf_abort_violation() we may leak
the storage allocated for 'abort' by returning from the function
without using or freeing it. This happens in case
"sctp_auth_recv_cid(SCTP_CID_ABORT, asoc)" is true and we jump to
the 'discard' label.
Spotted by the Coverity checker.
The simple fix is to simply move the creation of the "abort chunk"
to after the possible jump to the 'discard' label. This way we don't
even have to allocate the memory at all in the problem case.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
sm_statefuns.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index f01b408..4c5c5e7 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -4064,11 +4064,6 @@ static sctp_disposition_t sctp_sf_abort_violation(
struct sctp_chunk *chunk = arg;
struct sctp_chunk *abort = NULL;
- /* Make the abort chunk. */
- abort = sctp_make_abort_violation(asoc, chunk, payload, paylen);
- if (!abort)
- goto nomem;
-
/* SCTP-AUTH, Section 6.3:
*It should be noted that if the receiver wants to tear
*down an association in an authenticated way only, the
@@ -4083,6 +4078,11 @@ static sctp_disposition_t sctp_sf_abort_violation(
if (sctp_auth_recv_cid(SCTP_CID_ABORT, asoc))
goto discard;
+ /* Make the abort chunk. */
+ abort = sctp_make_abort_violation(asoc, chunk, payload, paylen);
+ if (!abort)
+ goto nomem;
+
if (asoc) {
sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Include header required for INT_MAX
>> Nack, we shoiuld never include userspace headers in kernel headers, >> an even more never add !__KERNEL__ ifdefs. Just make sure your >> programs include limit.h before including linux/cdrom.h. > >I think header files should be complete, and should not use undefined >macros, picking up every random definition that may be in effect when >the header is included, don't you agree? No, because I be damn sure that some developers try compiling programs in non-linux environments (cygwin, solaris, andyourpersonaldistro, you name it) which do not have to adhere to . It might use instead, or whatever. Hence, such extra includes are a nogo. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improve cgroup printks
>When I boot with the 'quiet' parameter, I see on the screen:
>
>[0.00] Initializing cgroup subsys cpuset
>[0.00] Initializing cgroup subsys cpu
>[ 39.036026] Initializing cgroup subsys cpuacct
>[ 39.036080] Initializing cgroup subsys debug
>[ 39.036118] Initializing cgroup subsys ns
>
>This patch lowers the priority of those messages, adds a "cgroup: "
>prefix to another couple of printks and kills the useless reference to
>the source file.
>- printk(KERN_ERR "Initializing cgroup subsys %s\n", ss->name);
>+ printk("Initializing cgroup subsys %s\n", ss->name);
Every printk should have a loglevel.
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Reported regressions from 2.6.23 (updated)
> [PATCH] pata_amd/pata_via: de-couple programming of PIO/MWDMA and UDMA timings
>
> * Don't program UDMA timings when programming PIO or MWDMA modes.
>
> This has also a nice side-effect of fixing regression added by commit
> 681c80b5d96076f447e8101ac4325c82d8dce508 ("libata: correct handling of
> SRST reset sequences") (->set_piomode method for PIO0 is called before
> ->cable_detect method which checks UDMA timings to get the cable type).
I'm not sure this helps as if the ACPI _GTF method is looking at the
flags and stuff but it has to be worth a try.
Works for me as a 2.6.24 band aid
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel panic at boot with ondemand governor as default (2.6.24-rc2)
On Sun, 11 Nov 2007 20:10:23 +0100 Eric Piel <[EMAIL PROTECTED]> wrote: > Hello, > > I've tried kernel 2.6.24-rc2 and I have a problem with the new option > for setting up the cpufreq ondemand governor as default: a kernel > panic happens early at boot time. If I boot first with performance > governor and later change to ondemand, everything is fine (as usual). > > This seems related to the delayed_workqueue. The kernel panic message > finishes by: > EIP: [] wq_per_cpu+0x0/0x10 SS:ESP 0068:c191be58 > Kernel panic - not syncing: Attempted to kill init! > > A picture of the whole message is available here: > http://pieleric.free.fr/unorder/1162-ondemand-panic.jpg > > My computer is a x86 using speedstep-ich, and you can find the full > .config leading to the panic attached. > > Does anyone has any idea was it going wrong? > Thanks, > Eric > > PS: I haven't tried 2.6.24-rc1. > has ondemand ever worked for you? -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Bind mount bug?
On Sunday 11 November 2007, Roland Kuhn wrote: > This mounts the bindtest/ tree on test/ _without_ copying the mount > points which are found on subtrees. Right. I guess this is the key point that tripped me up. > So, you see, test/test/test/a was (as it should) physically created > in test/test, where it is shadowed by the bind mount as long as that > is not removed. Which means that to continue the example from my follw-up mail: > # ls bindtest/test > foo > # umount test > # ls test > foo # umount bindtest/test # ls bindtest/test baz And there indeed is the missing file. > Nothing vanishes into "thin air" ;-) Yeah, I saw that syntax error after sending the mail "into space" would have been OK too, but not my combining the two :-) Thanks for the explanation! Cheers, FJP - 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 Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch/x86/kernel/setup_64.c compile error (MMOTM-2007-11-10-19-05)
I'm using -mm (MMOTM-2007-11-10-19-05) and getting $ make CC arch/x86/kernel/setup_64.o arch/x86/kernel/setup_64.c: In function 'setup_arch': arch/x86/kernel/setup_64.c:420: error: implicit declaration of function 'early_quirks' That's because the externs for early_quirks() aren't on unless CONFIG_ACPI is on, but the code in setup_64.c calls early_quirks() if CONFIG_PCI is on (and early-quirks.c is compiled only if CONFIG_PCI=y). I'm not sure if the small fix below is correct, hence no signed-off-by. But it seems to get the kernel compiling and linking at least. Someone should check. Cheers, Erez. diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c index 5a09161..64644d4 100644 --- a/arch/x86/kernel/setup_64.c +++ b/arch/x86/kernel/setup_64.c @@ -416,7 +416,7 @@ void __init setup_arch(char **cmdline_p) reserve_crashkernel(); paging_init(); -#ifdef CONFIG_PCI +#if defined(CONFIG_PCI) && defined(CONFIG_ACPI) early_quirks(); #endif - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Bind mount bug?
>> I'm not sure whether this is a bug or expected behavior. >> Suppose I create a "looped" bind mount situation as follows. >> >> # mkdir test >> # touch test/foo >> # mkdir bindtest >> # touch bindtest/bar >> # mkdir bindtest/test >> # mount --bind test/ bindtest/test/ >> # ls bindtest/test/ >> foo >> # mount --bind bindtest/ test/ > >This mounts the bindtest/ tree on test/ _without_ copying the mount >points which are found on subtrees. This is necessary to avoid loops >in the filesystem (bind mounts are somewhat like hardlinks on >directories, just without the headaches). What you seek is mount --rbind. - 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 Please read the FAQ at http://www.tux.org/lkml/
[PATCH] init/calibrate.c compile error (MMOTM-2007-11-10-19-05)
I'm using -mm (MMOTM-2007-11-10-19-05) and getting $ make CC init/calibrate.o In file included from include/linux/jiffies.h:8, from init/calibrate.c:7: include/linux/timex.h:246: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'read_current_timer' init/calibrate.c: In function 'calibrate_delay_direct': init/calibrate.c:41: error: implicit declaration of function 'read_current_timer' make[1]: *** [init/calibrate.o] Error 1 make: *** [init] Error 2 That's because the definition of __devinit isn't known at that point. The following small patch appears to fix the compilation error. Someone should verify that it's the proper fix. Cheers, Erez. Signed-off-by: Erez Zadok <[EMAIL PROTECTED]> diff --git a/include/linux/timex.h b/include/linux/timex.h index 40383f9..57bb18c 100644 --- a/include/linux/timex.h +++ b/include/linux/timex.h @@ -55,6 +55,7 @@ #include #include +#include #include - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Reported regressions from 2.6.23 (updated)
On Sunday 11 November 2007, Alan Cox wrote:
> > Subject : 2.6.24-rc1: pata_amd fails to detect 80-pin wire
> > Submitter : "Thomas Lindroth" <[EMAIL PROTECTED]>
> > References : http://lkml.org/lkml/2007/11/7/152
> > http://bugzilla.kernel.org/show_bug.cgi?id=9322
http://lkml.org/lkml/2007/10/12/537
The regression itself has been foreseen a month ago and it is quite
sad that it is still not fixed...
> Tejun is looking into this - its not trivial so may be 2.6.25 material.
> Similar reports for some other controllers (notably VIA).
We may fix the regression in a bit different way for now and give Tejun
some more time for the complete rework of the cable detection code.
[PATCH] pata_amd/pata_via: de-couple programming of PIO/MWDMA and UDMA timings
* Don't program UDMA timings when programming PIO or MWDMA modes.
This has also a nice side-effect of fixing regression added by commit
681c80b5d96076f447e8101ac4325c82d8dce508 ("libata: correct handling of
SRST reset sequences") (->set_piomode method for PIO0 is called before
->cable_detect method which checks UDMA timings to get the cable type).
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
Untested, please don't merge until it is confirmed to fix the problem.
drivers/ata/pata_amd.c |5 +++--
drivers/ata/pata_via.c |4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
Index: b/drivers/ata/pata_amd.c
===
--- a/drivers/ata/pata_amd.c
+++ b/drivers/ata/pata_amd.c
@@ -25,7 +25,7 @@
#include
#define DRV_NAME "pata_amd"
-#define DRV_VERSION "0.3.9"
+#define DRV_VERSION "0.3.10"
/**
* timing_setup- shared timing computation and load
@@ -115,7 +115,8 @@ static void timing_setup(struct ata_port
}
/* UDMA timing */
- pci_write_config_byte(pdev, offset + 0x10 + (3 - dn), t);
+ if (at.udma)
+ pci_write_config_byte(pdev, offset + 0x10 + (3 - dn), t);
}
/**
Index: b/drivers/ata/pata_via.c
===
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -63,7 +63,7 @@
#include
#define DRV_NAME "pata_via"
-#define DRV_VERSION "0.3.2"
+#define DRV_VERSION "0.3.3"
/*
* The following comes directly from Vojtech Pavlik's ide/pci/via82cxxx
@@ -296,7 +296,7 @@ static void via_do_set_mode(struct ata_p
}
/* Set UDMA unless device is not UDMA capable */
- if (udma_type) {
+ if (udma_type && t.udma) {
u8 cable80_status;
/* Get 80-wire cable detection bit */
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: Bind mount bug?
Hi Frans! Let's see whether I can explain this (I'm not a guru...) On 11 Nov 2007, at 11:06, Frans Pop wrote: I'm not sure whether this is a bug or expected behavior. Suppose I create a "looped" bind mount situation as follows. # mkdir test # touch test/foo # mkdir bindtest # touch bindtest/bar # mkdir bindtest/test # mount --bind test/ bindtest/test/ # ls bindtest/test/ foo # mount --bind bindtest/ test/ This mounts the bindtest/ tree on test/ _without_ copying the mount points which are found on subtrees. This is necessary to avoid loops in the filesystem (bind mounts are somewhat like hardlinks on directories, just without the headaches). # ls test/ bar test # ls test/test/ # This lists the contents of the original bintest/test/ directory which you created above. Creating e.g. a file in there stores that file physically in bindtest/test/bla, where "test" does _not_ mean the bind mount but the underlying directory here. I'd expected the last command to list "foo", but it shows an empty dir. Shouldn't it also show the original contents of test (as they were before the first bind mount)? # mount | grep test /root/test on /root/bindtest/test type none (rw,bind) /root/bindtest on /root/test type none (rw,bind) You see, the bindtest/test/ mount was not propagated to test/test/. This is very much by design. You can e.g. do # mkdir -p test/test # mount --bind test test/test # ls test/test test # ls test/test/test # so there is no loop (`find test` would actually say that it terminates because it has detected a loop, so it cannot be used to test this). # touch test/test/test/a # ls test/test/test a # ls test/test # umount test/test # ls test/test a # So, you see, test/test/test/a was (as it should) physically created in test/test, where it is shadowed by the bind mount as long as that is not removed. Nothing vanishes into "thin air" ;-) Ciao, Roland -- TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching Telefon 089/289-12575; Telefax 089/289-12570 -- CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482 -- Any society that would give up a little liberty to gain a little security will deserve neither and lose both. - Benjamin Franklin -BEGIN GEEK CODE BLOCK- Version: 3.12 GS/CS/M/MU d-(++) s:+ a-> C+++ UL P+++ L+++ E(+) W+ !N K- w--- M + !V Y+ PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++> h y+++ --END GEEK CODE BLOCK-- PGP.sig Description: This is a digitally signed message part
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading
kernel config attached to comment#2 for bugreport 9345 s2disk comes from suspend-0.7 package Thanks, Chris On Sun, 11 Nov 2007 19:45:06 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Saturday, 10 of November 2007, Chris Friedhoff wrote: > > please cc me, I'm not not subscribed to LKML > > > > Hello, > > > > with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but > > when I start the system and the suspended systemimage is loaded, it > > fails to "activate" this suspended systemimage and continues after some > > time with following the normal boot sequence. > > > > I can sucessfully STD the system with the following sequence > > echo platform > /sys/power/disk > > echo disk > /sys/power/state > > and when I start the laptop the suspended system is sucessfully > > restored. > > > > Both behaviors are reliable reproducable. > > Thanks for the report. > > > googling for >"Freezing of tasks failed" swapper< brought > > "Nigel Cunningham - PID namespaces break initrd+hibernate combination?" > > http://lkml.org/lkml/2007/11/4/140 > > Yes, this looks similarly. > > > dmesg output: > > <> > > RAMDISK: ext2 filesystem found at block 0 > > RAMDISK: Loading 2000KiB [1 disk] into ram disk... done. > > EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > > VFS: Mounted root (ext2 filesystem). > > swsusp: Marking nosave pages: 0009f000 - 0010 > > swsusp: Basic memory bitmaps created > > Clocksource tsc unstable (delta = -128791628 ns) > > Syncing filesystems ... done. > > Freezing user space processes ... (elapsed 0.00 seconds) done. > > Freezing remaining freezable tasks ... > > Freezing of tasks failed after 20.00 seconds (1 tasks refusing to > > freeze): taskPC stack pid father > > swapper S c1835a88 0 1 0 > > 0046 c0118c80 c1835a88 0004 0001 c011e875 > > 0286 c01025a6 c1835b64 c1835a90 > > 0001 007b c1835a90 > > c0118c80 Call Trace: > > [] default_wake_function+0x0/0x10 > > [] do_wait+0x335/0xac0 > > [] kernel_thread+0x96/0xb0 > > [] default_wake_function+0x0/0x10 > > [] sys_wait4+0x31/0x40 > > [] initrd_load+0x1b3/0x3a0 > > [] prepare_namespace+0x98/0x1b0 > > [] sys_access+0x1f/0x30 > > [] kernel_init+0x166/0x260 > > [] ret_from_fork+0x6/0x1c > > [] kernel_init+0x0/0x260 > > [] kernel_init+0x0/0x260 > > [] kernel_thread_helper+0x7/0x18 > > === > > kthreadd S 038f 0 2 0 > > 0046 c0487790 038f c183ff1c c012d81b > > c012d7b0 c0104b8f > > > > Call Trace: > > [] kthreadd+0x6b/0xd0 > > [] kthreadd+0x0/0xd0 > > [] kernel_thread_helper+0x7/0x18 > > === > > ksoftirqd/0 S 0 3 2 > > 0046 fffc c0120f00 c0120f7a > > c012d782 c012d740 c0104b8f c183ff3c > > > > Call Trace: > > [] ksoftirqd+0x0/0x80 > > [] ksoftirqd+0x7a/0x80 > > [] kthread+0x42/0x70 > > [] kthread+0x0/0x70 > > [] kernel_thread_helper+0x7/0x18 > > > > <> > > Can you please attach your kernel configuration file to the bugzilla entry > at http://bugzilla.kernel.org/show_bug.cgi?id=9345 ? > > Thanks, > Rafael Chris Friedhoff [EMAIL PROTECTED] - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Race in setup_irq?
On 11/11/2007, Dmitry Adamushko <[EMAIL PROTECTED]> wrote: > On 11/11/2007, Adrian McMenamin <[EMAIL PROTECTED]> wrote > > I am writing a device driver for the Dreamcast CD Drive (the "GD Rom") > > and I am hitting what looks like some sort of race in > > kernel/irq/manage.c. Can anybody point me in the right direction or is > > there a bug here? > > > > This never seems to return in setup_irq: > > > > spin_unlock_irqrestore(>lock, flags); > > > > (line 597) > > I guess, you are referring to setup_irq() (the line without a > particular kernel version doesn't make much sense). > Sorry, it was in the config: 2.6.24-rc2 > What do you mean by "never seems to return"? Does your machine hang? > > If so, the reason might be some kind of (logical) error in your ISR. > spin_unlock_irqrestore() unmasks the interrupts and your target device > might have already generated an interrupt by this moment (sure, it > depends on the initialization logic of your code and device spec.)... > --> ISR runs and due to some error e.g. loops endlessly/deadlocks/etc. > > Tried placing printk() at the beginning of ISR? > You are absolutely right. Sorry for wasting evetybody's time and thanks for the tip! - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Race in setup_irq?
On 11/11/2007, Adrian McMenamin <[EMAIL PROTECTED]> wrote > I am writing a device driver for the Dreamcast CD Drive (the "GD Rom") > and I am hitting what looks like some sort of race in > kernel/irq/manage.c. Can anybody point me in the right direction or is > there a bug here? > > This never seems to return in setup_irq: > > spin_unlock_irqrestore(>lock, flags); > > (line 597) I guess, you are referring to setup_irq() (the line without a particular kernel version doesn't make much sense). What do you mean by "never seems to return"? Does your machine hang? If so, the reason might be some kind of (logical) error in your ISR. spin_unlock_irqrestore() unmasks the interrupts and your target device might have already generated an interrupt by this moment (sure, it depends on the initialization logic of your code and device spec.)... --> ISR runs and due to some error e.g. loops endlessly/deadlocks/etc. Tried placing printk() at the beginning of ISR? -- Best regards, Dmitry Adamushko - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/11 v3] enable "make ARCH=x86"
Theodore Tso <[EMAIL PROTECTED]> wrote: > On Sat, Nov 10, 2007 at 12:35:01PM -0800, H. Peter Anvin wrote: >> In fact, we should be able to get rid of ARCH entirely; CONFIG_ options >> have the huge advantage that they're saved in a file, and you don't have to >> type them on every make run. The only option that I can't see us getting >> rid of easily is HOSTCC, since it is used before config is run, but >> probably something clever can be done there, too. > Yes, please! One of the more annoying things is forgetting the > ARCH=um when rebuilding UML. It would be awfully nice if ARCH was set > via a CONFIG_ option and was persistent. This should have been fixed, or it's about to be fixed. My patch is here: http://groups.google.com/group/linux.kernel/browse_thread/thread/93e5c33fc6e8cff6/39aff558a636ad02 (This patch was superseded by another patch, which may be delayed or mm-only.) OTOH, if you can implement ARCH= using CONFIG_ARCH, why not? Just don't forget to keep the scripts running, and make randconfig only select buildable archs. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] improved hacks to allow -rt to run kernbench on POWER
On Sun, 2007-11-11 at 09:45 -0500, Steven Rostedt wrote: > > Well, I suppose the patch could go in, maybe with some ifdef's > around > > the bits in _switch_to, there's little point in doing that on non-rt > > kernels. > > As Nick Piggin already stated, and I'll even state it for the RT > kernel, > we do not allow preemption in switch_to. So it is safe to remove those > "preempt_disable" bits from the patch Sure, I know that, I'm not talking about that, I'm talking about the added code that flush pending batches & save the batch state, since on non-rt kernel, this is not useful (the batch is only ever active within a spinlocked section, which cannot be preempted on non-rt). Ben. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/capability.c get_task_comm compile error (MMOTM)
* Erez Zadok <[EMAIL PROTECTED]> wrote:
> Ingo, I don't see how it can return NULL. This is what get_task_comm
> looks like in MMOTM-2007-11-10-19-05:
>
> char *get_task_comm(char *buf, struct task_struct *tsk)
> {
> /* buf must be at least sizeof(tsk->comm) in size */
> task_lock(tsk);
> strncpy(buf, tsk->comm, sizeof(tsk->comm));
> task_unlock(tsk);
> return buf;
> }
>
> The only way it'd return NULL is if a null buf was passed, in which
> case the strncpy will oops first.
hm, here it says in include/linux/sched.h:
extern void get_task_comm(char *to, struct task_struct *tsk);
HEAD ecd744eec3a.
Ingo
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] v2.6.24-rc1-497-gb1d08ac: kde battery icon gone
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > See this commit: > > > > commit fb804714560463534ebcb538a3b0a3c687a830ec > > Author: Len Brown <[EMAIL PROTECTED]> > > Date: Tue Jul 24 01:50:46 2007 -0400 > > > > ACPI: Kconfig: CONFIG_ACPI_PROCFS now defaults to N > > > > delete "default y" from CONFIG_ACPI_PROCFS > > (effectively making the default 'N') > > > > List exactly what /proc files this option controls, > > and clarify that it doesn't change non-deprecated files. > > > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > > > So at least battery change should have added /proc/acpi/battery to this > > list. > > IMHO, the source of the problem is the battery change that has > introduced the dependency on ACPI_PROCFS _although_ it's unset by > default and that is a regression (ie. confuses users with older user > space). "older user space" meaning just about every Linux box that is out there at the moment. So this is a regression, the user does not care why it happened, and needs fixing. > > May be we need separate ACPI_PROCFS_xxx for every subsystem. > > Well, I'm not sure. I think that documenting the dependency should be > sufficient. No. We never remove a bit of relied-on API from the kernel like that. At minimum it must go through a long deprecation cycle before it's turned off by default. Really, is this some sort of weird "how can we piss off and lose as many beta testers as possible in the shortest amount of time" contest? Will people search for a few new lines of documentation (out of the 1 million lines of kernel code that 2.6.24 changes) when 'make oldconfig' breaks their laptop setup - or will they just go over to a more tester-friendly project? Compatibility is our utmost priority (and your regressions list is a very good tool for us to keep compatibility), especially in an incredibly easy case like this where the fix is 1 changed byte with no harm done to anyone. Ingo - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Reported regressions from 2.6.23 (updated)
Rafael J. Wysocki <[EMAIL PROTECTED]> : > [Note: Due to git.kernel.org not responding I'm unable to check which fixes > have already been merged since the last report.] [...] > Subject : 2.6.24-rc1 kills onboard r8169 (rtl8111b) NIC > Submitter : "Sergey S. Kostyliov" <[EMAIL PROTECTED]> > References: http://lkml.org/lkml/2007/10/28/144 > http://bugzilla.kernel.org/show_bug.cgi?id=9257 > Handled-By: Francois Romieu <[EMAIL PROTECTED]> > Patch : http://bugzilla.kernel.org/attachment.cgi?id=13441=view Fixed and merged in Linus's tree as: - 50d84c2dc00e48ff9ba018ed0dd23276cf79e566 - b9d04e2401bf308df921d3bbbdacab40fadc27bb -- Ueimor - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Reported regressions from 2.6.23 (updated)
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > Subject : [regression] v2.6.24-rc1-497-gb1d08ac: kde battery > icon gone > Submitter : Thomas Meyer <[EMAIL PROTECTED]> > References: http://lkml.org/lkml/2007/11/2/165 > http://bugzilla.kernel.org/show_bug.cgi?id=9297 > Handled-By: Andrey Borzenkov <[EMAIL PROTECTED]> > Ingo Molnar <[EMAIL PROTECTED]> > Patch : > Note : goes away if ACPI_PROCFS is set should be fixed by acpi-make-acpi_procfs-default-to-y.patch in -mm. (not yet upstream i think, but should before v2.6.24) Ingo - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23: no more free evdev devices - evdev leak?
On Tue, 2007-11-06 at 15:52 +0100, Jiri Kosina wrote: > On Tue, 6 Nov 2007, Dmitry Torokhov wrote: > > > Could you please try sticking a printk in > > hidinput_disconnect(drivers/hid/hid-input.c) to verify that > > input_unregister_device is in fact being called? > > Also, is 2.6.23 the only kernel you are experiencing this with please? So far yes. I am now on 2.6.24rc2 and although the input device numbers steadily increase s2ram does reliably work even when done >10 times in a row and no problems with evdev devices not being available. However resume is slower as some ata device (I think my cdrom) is timing out. So it could be related to a too fast resume from suspend. So the problem may re-appear if matthew garrets fix for [PATCH] Don't fail ata device revalidation for bad _GTF methods will be committed. Is there still a need to do tests with the printk's in 2.6.23? Soeren - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Reported regressions from 2.6.23 (updated)
On Sunday, 11 of November 2007, Alan Cox wrote: > > Subject : 2.6.24-rc1: pata_acpi fails to activate DMA for > > DVD-ROM on ALi M5229 secondary channel > > Submitter : Andrey Borzenkov <[EMAIL PROTECTED]> > > References : http://marc.info/?l=linux-kernel=119342005216716=2 > > http://bugzilla.kernel.org/show_bug.cgi?id=9252 > > Handled-By : Alan Cox <[EMAIL PROTECTED]> > > Patch : > > Note: pata_acpi was not present in 2.6.23 > > As I said before pata_acpi was not present in 2.6.23 -> Not a regression. OK, dropped. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: Add EXPORT_SYMBOL for symbols required by fs_enet and cpm_uart
On Sun, Nov 11, 2007 at 06:01:37PM +0100, Jochen Friedrich wrote: > --- a/arch/powerpc/sysdev/commproc.c > +++ b/arch/powerpc/sysdev/commproc.c > @@ -51,6 +51,8 @@ static void m8xx_cpm_dpinit(void); > static uint host_buffer; /* One page of host buffer */ > static uint host_end;/* end + 1 */ > cpm8xx_t __iomem *cpmp; /* Pointer to comm processor space */ > +EXPORT_SYMBOL(cpmp); Sorry, but this is a nightmare waiting to happen. Please define proper accessors instead. (And get rid of the typedef while you're at it) - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Reported regressions from 2.6.23 (updated)
> Subject : 2.6.24-rc1: pata_acpi fails to activate DMA for > DVD-ROM on ALi M5229 secondary channel > Submitter : Andrey Borzenkov <[EMAIL PROTECTED]> > References: http://marc.info/?l=linux-kernel=119342005216716=2 > http://bugzilla.kernel.org/show_bug.cgi?id=9252 > Handled-By: Alan Cox <[EMAIL PROTECTED]> > Patch : > Note : pata_acpi was not present in 2.6.23 As I said before pata_acpi was not present in 2.6.23 -> Not a regression. WONTFIX for 2.6.24. Not actually clear it is even a bug, the interactions between using pata_acpi and simplex controllers are not documented anywhere 8( > Subject : 2.6.24-rc1: pata_amd fails to detect 80-pin wire > Submitter : "Thomas Lindroth" <[EMAIL PROTECTED]> > References: http://lkml.org/lkml/2007/11/7/152 > http://bugzilla.kernel.org/show_bug.cgi?id=9322 Tejun is looking into this - its not trivial so may be 2.6.25 material. Similar reports for some other controllers (notably VIA). > Subject : cd/dvd inaccessible in 2.6.24-rc2 > Submitter : Will Trives <[EMAIL PROTECTED]> > References: http://lkml.org/lkml/2007/11/9/290 > http://bugzilla.kernel.org/show_bug.cgi?id=9346 > Handled-By: Alan Cox <[EMAIL PROTECTED]> > Jeff Garzik <[EMAIL PROTECTED]> Not sure who is handling this now - seems to be an IRQ routing bug introduced in -rc2. I've got a pile of similar breakage reports for random ATA controllers. Thanks Alan - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1: pata_acpi fails to activate DMA for DVD-ROM on ALi M5229 secondary channel
> BTW in rc2 it does not even boot - it babbles something about > Unable to determine IRQ for 00:04.0 (which is IDE controller) and that is > the end of story. No IDE device is found. Thats not an IDE breakage I suspect. Various people are reporting IRQ related breakage with -rc2 so you should probably report that to the main linux-kernel list Doesn't explain the ALi DMA problem but I think its unrelated Alan - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Unionfs: stop using iget() and read_inode()
On Sun, 11 Nov 2007 13:38:04 -0500 Erez Zadok <[EMAIL PROTECTED]> wrote: > Andrew, the following small patch is critical to have after: > > iget-stop-unionfs-from-using-iget-and-read_inode.patch Thanks > Question: since the above patch isn't in my unionfs.git tree (not until the > whole iget series makes it to Linus), then do you prefer if I give you a > replacement patch to the above patch, or a small incremental one; either > way, you can choose to fold the above and below patches into one. Incrementals are usually preferred. But it's usually more convenient for the originator to generate a new patch, and I will almost always turn that into an incremental so that I can review what was changed. The downside to this is that nobody else will be able to see what was changed. So there are pros and cons and I'm not particularly fussed either way, really. But if a patch is large and has already had some testing and review and has been in -mm for a while then that's when wholesale replacement becomes problematic: it pretty much sets us back to square one. - 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 Please read the FAQ at http://www.tux.org/lkml/
Race in setup_irq?
I am writing a device driver for the Dreamcast CD Drive (the "GD Rom")
and I am hitting what looks like some sort of race in
kernel/irq/manage.c. Can anybody point me in the right direction or is
there a bug here?
This never seems to return in setup_irq:
spin_unlock_irqrestore(>lock, flags);
(line 597)
I cannot see any reason why it would fail, though. And I know how
difficult these things are to debug - but if I put a printk either
side, it works for all interrupt set ups, but not this one.
Here is the calling code:
static int gdrom_set_command_interrupt_handler(void)
{
int err;
#ifdef GDROMDEBUG
printk("%s\n", __FUNCTION__);
#endif
/* need a queue to wait in */
init_waitqueue_head(_queue);
err = request_irq(HW_EVENT_GDROM_CMD, gdrom_command_interrupt,
IRQF_PROBE_SHARED, "gdrom", gd.disk);
if (err)
return -err;
#ifdef GDROMDEBUG
printk("Interrupt is registered\n");
#endif
return 0;
}
Here is the .config file:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc2
# Sun Nov 11 17:50:05 2007
#
CONFIG_SUPERH=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_SYS_SUPPORTS_PCI=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_ARCH_NO_VIRT_TO_BUS=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# System type
#
CONFIG_CPU_SH4=y
# CONFIG_CPU_SUBTYPE_SH7619 is not set
# CONFIG_CPU_SUBTYPE_SH7206 is not set
# CONFIG_CPU_SUBTYPE_SH7705 is not set
# CONFIG_CPU_SUBTYPE_SH7706 is not set
# CONFIG_CPU_SUBTYPE_SH7707 is not set
# CONFIG_CPU_SUBTYPE_SH7708 is not set
# CONFIG_CPU_SUBTYPE_SH7709 is not set
# CONFIG_CPU_SUBTYPE_SH7710 is not set
# CONFIG_CPU_SUBTYPE_SH7712 is not set
# CONFIG_CPU_SUBTYPE_SH7720 is not set
# CONFIG_CPU_SUBTYPE_SH7750 is not set
CONFIG_CPU_SUBTYPE_SH7091=y
# CONFIG_CPU_SUBTYPE_SH7750R is not set
# CONFIG_CPU_SUBTYPE_SH7750S is not set
# CONFIG_CPU_SUBTYPE_SH7751 is not set
# CONFIG_CPU_SUBTYPE_SH7751R is not set
# CONFIG_CPU_SUBTYPE_SH7760 is not set
# CONFIG_CPU_SUBTYPE_SH4_202 is not set
# CONFIG_CPU_SUBTYPE_SH7770 is not set
# CONFIG_CPU_SUBTYPE_SH7780 is not set
# CONFIG_CPU_SUBTYPE_SH7785 is not set
# CONFIG_CPU_SUBTYPE_SHX3 is not set
# CONFIG_CPU_SUBTYPE_SH7343 is not set
# CONFIG_CPU_SUBTYPE_SH7722 is not set
#
# Memory management options
#
CONFIG_QUICKLIST=y
CONFIG_MMU=y
CONFIG_PAGE_OFFSET=0x8000
CONFIG_MEMORY_START=0x0c00
CONFIG_MEMORY_SIZE=0x0100
CONFIG_VSYSCALL=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_MAX_ACTIVE_REGIONS=1
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_PAGE_SIZE_4KB=y
# CONFIG_PAGE_SIZE_8KB is not set
# CONFIG_PAGE_SIZE_64KB is not set
CONFIG_HUGETLB_PAGE_SIZE_64K=y
# CONFIG_HUGETLB_PAGE_SIZE_256K is not set
# CONFIG_HUGETLB_PAGE_SIZE_1MB is not set
# CONFIG_HUGETLB_PAGE_SIZE_4MB is
Re: dio_get_page() lockdep complaints
On Fri, 2007-11-09 at 12:45 -0500, Trond Myklebust wrote:
> On Fri, 2007-11-09 at 09:30 -0800, Zach Brown wrote:
> > So, reiserfs and NFS are nesting i_mutex inside the mmap_sem.
> >
> > >>[] mutex_lock+0x1c/0x1f
> > >>[] reiserfs_file_release+0x54/0x447
> > >>[] __fput+0x53/0x101
> > >>[] fput+0x19/0x1c
> > >>[] remove_vma+0x3b/0x4d
> > >>[] do_munmap+0x17f/0x1cf
> >
> > >[] _mutex_lock+0x28/0x34
> > >[] nfs_revalidate_mapping+0x6d/0xac [nfs]
> > >[] nfs_file_mmap+0x5c/0x74 [nfs]
> > >[] do_mmap_pgoff+0x51a/0x817
> > >[] sys_mmap+0x90/0x119
> >
> > I think i_mutex is fundamentally nested outside of the mmap_sem because
> > of faulting in the buffered write path. I think these warnings could be
> > reproduced with a careful test app which tries buffered writes from an
> > address which will fault.
> >
> > DIO just tripped it up because it *always* performs get_user_pages() on
> > the memory.
> >
> > So reiser and NFS need to be fixed. No?
>
> Actually, it is rather mmap() needs to be fixed. It is cold calling the
> filesystem while holding all sorts of nasty locks. It needs to be
> migrated to the same sort of syscall layout as read() and write().
>
> You _first_ call the filesystem so that it can make whatever
> preparations it needs outside the lock. The filesystem then calls the
> VM, which can then call the filesystem back if needed.
Right, which gets us into all kinds of trouble because some sites need
mmap_sem to resolve some races, notably s390 31-bit and shm.
Quick proto-type that moves mmap_sem into do_mmap{,_pgoff} and provides
_locked functions for those few icky sites.
The !_locked functions also call f_op->mmap_prepare() before taking the
mmap_sem. Which makes for some ugly asymetry :-/
Anyway, I'm not comming up with anything nicer atm, hopefully a nice
idea will present itself soon.
(compile tested only - mostly for illustrational purposes)
Not-signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
arch/alpha/kernel/osf_sys.c |2 -
arch/arm/kernel/sys_arm.c |2 -
arch/avr32/kernel/sys_avr32.c |2 -
arch/blackfin/kernel/sys_bfin.c |2 -
arch/cris/kernel/sys_cris.c |2 -
arch/frv/kernel/sys_frv.c |4 --
arch/h8300/kernel/sys_h8300.c |4 --
arch/ia64/ia32/sys_ia32.c | 30 +---
arch/ia64/kernel/sys_ia64.c |2 -
arch/m32r/kernel/sys_m32r.c |2 -
arch/m68k/kernel/sys_m68k.c |4 --
arch/m68knommu/kernel/sys_m68k.c|2 -
arch/mips/kernel/irixelf.c | 10 -
arch/mips/kernel/linux32.c |2 -
arch/mips/kernel/syscall.c |2 -
arch/mips/kernel/sysirix.c |5 --
arch/parisc/kernel/sys_parisc.c |2 -
arch/powerpc/kernel/syscalls.c |2 -
arch/s390/kernel/compat_linux.c |5 +-
arch/s390/kernel/sys_s390.c |2 -
arch/sh/kernel/sys_sh.c |2 -
arch/sh64/kernel/sys_sh64.c |2 -
arch/sparc/kernel/sys_sparc.c |2 -
arch/sparc/kernel/sys_sunos.c |2 -
arch/sparc64/kernel/binfmt_aout32.c |6 ---
arch/sparc64/kernel/sys_sparc.c |2 -
arch/sparc64/kernel/sys_sunos32.c |2 -
arch/sparc64/solaris/misc.c |2 -
arch/um/kernel/syscall.c|2 -
arch/v850/kernel/syscalls.c |2 -
arch/x86/ia32/ia32_aout.c |6 ---
arch/x86/ia32/sys_ia32.c|5 --
arch/x86/kernel/sys_i386_32.c |2 -
arch/x86/kernel/sys_x86_64.c|2 -
arch/xtensa/kernel/syscall.c|2 -
drivers/char/drm/drm_bufs.c |4 --
drivers/char/drm/i810_dma.c |2 -
fs/aio.c|4 +-
fs/binfmt_aout.c|6 ---
fs/binfmt_elf.c |6 ---
fs/binfmt_elf_fdpic.c |9
fs/binfmt_flat.c|6 +--
fs/binfmt_som.c |6 ---
fs/nfs/file.c | 25 +
include/linux/fs.h |1
include/linux/mm.h | 13 ++-
ipc/shm.c |2 -
mm/mmap.c | 65 +---
48 files changed, 109 insertions(+), 169 deletions(-)
Index: linux-2.6-2/arch/alpha/kernel/osf_sys.c
===
--- linux-2.6-2.orig/arch/alpha/kernel/osf_sys.c
+++ linux-2.6-2/arch/alpha/kernel/osf_sys.c
@@ -193,9 +193,7 @@ osf_mmap(unsigned long addr, unsigned lo
goto out;
}
flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE);
- down_write(>mm->mmap_sem);
ret = do_mmap(file, addr, len, prot, flags, off);
- up_write(>mm->mmap_sem);
if (file)
fput(file);
out:
Index: linux-2.6-2/arch/arm/kernel/sys_arm.c
2.6.24-rc2: Reported regressions from 2.6.23 (updated)
[Note: Due to git.kernel.org not responding I'm unable to check which fixes have already been merged since the last report.] This message contains a list of some regressions from 2.6.23 which have been reported since 2.6.24-rc1 was released and for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. Subject : On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at virtual address 3d15b925 Submitter : Giacomo Catenazzi <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/24/487 http://bugzilla.kernel.org/show_bug.cgi?id=9246 Handled-By : Patch : Subject : Potential regression in -git15: can't resume stopped root shell? Submitter : Theodore Tso <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/20/114 http://bugzilla.kernel.org/show_bug.cgi?id=9247 Handled-By : Serge Hallyn <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=13361=view http://bugzilla.kernel.org/attachment.cgi?id=13375=view Subject : irq 21: nobody cared 2.6.24-rc1 Submitter : Bongani Hlope <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/25/90 http://bugzilla.kernel.org/show_bug.cgi?id=9249 Handled-By : Patch : Subject : [BUG] panic after umount (biscted) Submitter : Sebastian Siewior <[EMAIL PROTECTED]> References : http://marc.info/?l=linux-kernel=119338387030335=2 http://bugzilla.kernel.org/show_bug.cgi?id=9250 Handled-By : Jens Axboe <[EMAIL PROTECTED]> Patch : http://marc.info/?l=linux-kernel=119348520210349=2 Subject : 2.6.24-rc1 sysctl table check failed on PowerMac Submitter : Mikael Pettersson <[EMAIL PROTECTED]> References : http://marc.info/?l=linux-kernel=119350802331857=2 http://bugzilla.kernel.org/show_bug.cgi?id=9251 Handled-By : Alexey Dobriyan <[EMAIL PROTECTED]> Patch : http://marc.info/?l=linux-kernel=119351015801660=2 Subject : 2.6.24-rc1: pata_acpi fails to activate DMA for DVD-ROM on ALi M5229 secondary channel Submitter : Andrey Borzenkov <[EMAIL PROTECTED]> References : http://marc.info/?l=linux-kernel=119342005216716=2 http://bugzilla.kernel.org/show_bug.cgi?id=9252 Handled-By : Alan Cox <[EMAIL PROTECTED]> Patch : Note: pata_acpi was not present in 2.6.23 Subject : 2.6.24-rc1 freezes on powerbook at first boot stage Submitter : Elimar Riesebieter <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/24/205 http://bugzilla.kernel.org/show_bug.cgi?id=9254 Handled-By : Patch : Subject : build #286 failed for 2.6.24-rc1-gea45d15 in linux/arch/x86/kernel/setup_32.c Submitter : Toralf Förster <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/28/110 http://bugzilla.kernel.org/show_bug.cgi?id=9256 Handled-By : "H. Peter Anvin" <[EMAIL PROTECTED]> Patch : http://marc.info/[EMAIL PROTECTED] Subject : 2.6.24-rc1 kills onboard r8169 (rtl8111b) NIC Submitter : "Sergey S. Kostyliov" <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/28/144 http://bugzilla.kernel.org/show_bug.cgi?id=9257 Handled-By : Francois Romieu <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=13441=view Subject : Commit "Hibernation: Enter platform hibernation state in a consistent way)" makes my system to resume instantly from S4 Submitter : Maxim Levitsky <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/27/66 http://bugzilla.kernel.org/show_bug.cgi?id=9258 Handled-By : "Rafael J. Wysocki" <[EMAIL PROTECTED]> Patch : Note: $subject commit apparently exposes a problem that existed previously Subject : leds: ledtrig-timer calls sleeping function from invalid context Submitter : Márton Németh <[EMAIL PROTECTED]> References : http://bugzilla.kernel.org/show_bug.cgi?id=9264 Handled-By : Patch : Subject : Device mapper regression 2.6.23 vs. v2.6.23-6597-gcfa76f0 Submitter : Thomas Meyer <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/21/153 http://bugzilla.kernel.org/show_bug.cgi?id=9280 Handled-By : Patch : Subject : [2.6.24-rc1][BUG] Oops on battery removal Submitter : Rolf Eike Beer <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/11/2/23 http://bugzilla.kernel.org/show_bug.cgi?id=9283 Handled-By :
Re: Strage buffer behaviour
On Sun, Nov 11, 2007 at 07:33:35PM +0100, Tino Keitel wrote: > I noticed that the kernel (2.6.23.1) seems to buffer only certain > partitions on my system: > > $ for i in 1 2 3 4 ; do for j in 1 2 ; do dd if=/dev/sda$i of=/dev/null > bs=1024k count=100 ; done ; done > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 3.01471 seconds, 34.8 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 2.86945 seconds, 36.5 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 2.92038 seconds, 35.9 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 3.00272 seconds, 34.9 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 4.07722 seconds, 25.7 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 0.0944248 seconds, 1.1 GB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 5.61527 seconds, 18.7 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 0.331822 seconds, 316 MB/s > > The dd command reads 100 MB from each partition two times in a row. It > looks like sda1 and sda2 are not bufferd (the first 4 dd runs), but > sda3 and sda4 are (the last 4 dd runs). Strange.. I'm running 2.6.24-rc1 here. Reading data from /dev/hda1 caches well, but not from /dev/sd[ab]1. PS. you can flush caches with: echo 1 > /proc/sys/vm/drop_caches -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/capability.c get_task_comm compile error (MMOTM)
On Sun, 11 Nov 2007 15:15:10 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Erez Zadok <[EMAIL PROTECTED]> wrote: > > > Small patch below fixes compile error. > > > + char name[sizeof(current->comm)]; > > warned++; > > printk(KERN_INFO > >"warning: process `%s' sets w/ old libcap\n", > > - get_task_comm(current)); > > + get_task_comm(name, current)); > > that's buggy - get_task_comm() returns void. > > the proper fix would be to first do a get_task_comm() then pass in > 'name' as an argument to printk. yup, it is all dependent upon http://lkml.org/lkml/2007/11/8/231 - 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 Please read the FAQ at http://www.tux.org/lkml/
[patch] x86: fix taking DNA during 64bit sigreturn
restore sigcontext is taking a DNA exception while restoring FP context from
the user stack, during the sigreturn. Appended patch fixes it by doing clts()
if the app doesn't touch FP during the signal handler execution. This will
stop generating a DNA, during the fxrstor in the sigreturn.
This improves 64-bit lat_sig numbers by ~30% on my core2 platform.
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/kernel/i387_64.c b/arch/x86/kernel/i387_64.c
index 56c1f11..bfaff28 100644
--- a/arch/x86/kernel/i387_64.c
+++ b/arch/x86/kernel/i387_64.c
@@ -92,13 +92,14 @@ int save_i387(struct _fpstate __user *buf)
if (task_thread_info(tsk)->status & TS_USEDFPU) {
err = save_i387_checking((struct i387_fxsave_struct __user
*)buf);
if (err) return err;
+ task_thread_info(tsk)->status &= ~TS_USEDFPU;
stts();
- } else {
- if (__copy_to_user(buf, >thread.i387.fxsave,
+ } else {
+ if (__copy_to_user(buf, >thread.i387.fxsave,
sizeof(struct i387_fxsave_struct)))
return -1;
- }
- return 1;
+ }
+ return 1;
}
/*
diff --git a/include/asm-x86/i387_64.h b/include/asm-x86/i387_64.h
index 0217b74..3a4ffba 100644
--- a/include/asm-x86/i387_64.h
+++ b/include/asm-x86/i387_64.h
@@ -203,6 +203,11 @@ static inline void save_init_fpu(struct task_struct *tsk)
*/
static inline int restore_i387(struct _fpstate __user *buf)
{
+ set_used_math();
+ if (!(task_thread_info(current)->status & TS_USEDFPU)) {
+ clts();
+ task_thread_info(current)->status |= TS_USEDFPU;
+ }
return restore_fpu_checking((__force struct i387_fxsave_struct *)buf);
}
-
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
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1: pata_acpi fails to activate DMA for DVD-ROM on ALi M5229 secondary channel
On Friday 26 October 2007, Alan Cox wrote: > On Fri, 26 Oct 2007 21:30:02 +0400 > Andrey Borzenkov <[EMAIL PROTECTED]> wrote: > > > Running legacy IDE drivers apparently works in DMA mode for both: > > Thanks - can you send me an lspci -vvxxx off list > BTW in rc2 it does not even boot - it babbles something about Unable to determine IRQ for 00:04.0 (which is IDE controller) and that is the end of story. No IDE device is found. signature.asc Description: This is a digitally signed message part.
Re: 2.6.24-rc1-g74521c28: oops during boot [] :power_supply:power_supply_show_property+0x94/0x150
Rafael J. Wysocki schrieb: >> Replying to myself again. Apparently, a fix for this bug was applied to >> the linux-acpi tree independently of my bug report, see here: >> http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=4c41d3ad6544f1c9aec37c441af04f5d0ad3a731 > > I'm having some problems with accessing git.kernel.org right now. I'll have a > look when it works again. Same problem here, it took me some time until I could view it. I forgot to mention that the patch actually fixes the bug in my case, I can boot 2.6.24 without oopses now. signature.asc Description: OpenPGP digital signature
enable dual rng on VIA C7
Hello, Any reason why the second rng on the VIA C7 CPU is not enabled? Kind regards, Udo --- old/drivers/char/hw_random/via-rng.c2007-11-11 19:39:49.0 +0100 +++ new/drivers/char/hw_random/via-rng.c2007-11-11 19:40:41.0 +0100 @@ -41,6 +41,7 @@ VIA_STRFILT_ENABLE = (1 << 14), VIA_RAWBITS_ENABLE = (1 << 13), VIA_RNG_ENABLE = (1 << 6), + VIA_RNG_DUAL= (1 << 9), VIA_XSTORE_CNT_MASK = 0x0F, VIA_RNG_CHUNK_8 = 0x00, /* 64 rand bits, 64 stored bits */ @@ -128,6 +129,7 @@ lo &= ~(0x7f << VIA_STRFILT_CNT_SHIFT); lo &= ~VIA_XSTORE_CNT_MASK; lo &= ~(VIA_STRFILT_ENABLE | VIA_STRFILT_FAIL | VIA_RAWBITS_ENABLE); + lo |= VIA_RNG_DUAL; lo |= VIA_RNG_ENABLE; if (lo != old_lo)
Re: 2.6.24-rc1-g74521c28: oops during boot [] :power_supply:power_supply_show_property+0x94/0x150
On Sunday, 11 of November 2007, Thomas Bächler wrote: > >>> http://bugzilla.kernel.org/show_bug.cgi?id=9299 > > > > I just tested again (with 2.6.24-rc2-gecd744ee). If I only load the 'ac' > > kernel module and not the 'battery' kernel module, then the system boots > > fine. However, if I load the 'battery' module during boot or later, I > > still get the oops. > > > > I am running 2.6.24-rc2-gecd744ee right now, but without the battery > > module. I am forwarding this to the ACPI list as well. > > > > Replying to myself again. Apparently, a fix for this bug was applied to > the linux-acpi tree independently of my bug report, see here: > http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=4c41d3ad6544f1c9aec37c441af04f5d0ad3a731 I'm having some problems with accessing git.kernel.org right now. I'll have a look when it works again. Thanks, Rafael - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-g74521c28: oops during boot [] :power_supply:power_supply_show_property+0x94/0x150
>>> http://bugzilla.kernel.org/show_bug.cgi?id=9299 > > I just tested again (with 2.6.24-rc2-gecd744ee). If I only load the 'ac' > kernel module and not the 'battery' kernel module, then the system boots > fine. However, if I load the 'battery' module during boot or later, I > still get the oops. > > I am running 2.6.24-rc2-gecd744ee right now, but without the battery > module. I am forwarding this to the ACPI list as well. > Replying to myself again. Apparently, a fix for this bug was applied to the linux-acpi tree independently of my bug report, see here: http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=4c41d3ad6544f1c9aec37c441af04f5d0ad3a731 signature.asc Description: OpenPGP digital signature
Re: 2.6.24 regression: hibernation hangs on "Suspending console" in low-battery condition
On Sunday, 11 of November 2007, Andrey Borzenkov wrote: > On Sunday 11 November 2007, Rafael J. Wysocki wrote: > > On Sunday, 11 of November 2007, Andrey Borzenkov wrote: > > > On Monday 05 November 2007, Andrey Borzenkov wrote: > > > > Notice "hung" not "hangs". This happened so far only once - when low > > > > battery > > > > condition triggered suspend to disk. I was not able to reproduce it > > > > after > > > > this running on AC. > > > > > > > > Just in case it rings the bell for someone. This is not suspend > > > > regression > > > > reported earlier by Jens - I do not even have SATA nor is using libata > > > > drivers. > > > > > > > > > > This happened second time, now with 2.6.24-rc2. I have kpowersave > > > configured > > > to initiate suspend-to-disk on low battery. Suspend-to-disk is initiated, > > > but system stops after Suspending console line. Suspend image is not > > > created. > > > > > > This did work before although I do not name exact version. > > > > > > I am rather at loss how to proceed further ... any idea? dmesg and config > > > attached just in case. The problem is that hibernation works when I > > > initiate > > > it manually ... > > > > Have you tried it with the battery removed? > > > > > > It works. Subjectively I have relatively long pause after first Suspending > console > message (where it hangs otherwise), according to dmesg timestamp it is about > 1 second before next messages appear. Also last two times I tried it writeout > of suspend image was really slow; it was both with and without battery. > Reading > on resume in really in order of magnitude faster. > > But manual STD so far works both on AC (with or without battery) or on > battery. > > Of course it is possible that battery gets exhausted during STD, but system > is not switched off. Rather I would suspect something like ACPI notification > that comes during freeze ... Frankly, I'm suspecting a deadlock in the ACPI code. Please try to make kpowersave start hibernation a bit earlier and see what happens. What's your critical time now? - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 regression: hibernation hangs on "Suspending console" in low-battery condition
On Sunday 11 November 2007, Rafael J. Wysocki wrote: > On Sunday, 11 of November 2007, Andrey Borzenkov wrote: > > On Monday 05 November 2007, Andrey Borzenkov wrote: > > > Notice "hung" not "hangs". This happened so far only once - when low > > > battery > > > condition triggered suspend to disk. I was not able to reproduce it after > > > this running on AC. > > > > > > Just in case it rings the bell for someone. This is not suspend > > > regression > > > reported earlier by Jens - I do not even have SATA nor is using libata > > > drivers. > > > > > > > This happened second time, now with 2.6.24-rc2. I have kpowersave configured > > to initiate suspend-to-disk on low battery. Suspend-to-disk is initiated, > > but system stops after Suspending console line. Suspend image is not > > created. > > > > This did work before although I do not name exact version. > > > > I am rather at loss how to proceed further ... any idea? dmesg and config > > attached just in case. The problem is that hibernation works when I initiate > > it manually ... > > Have you tried it with the battery removed? > > It works. Subjectively I have relatively long pause after first Suspending console message (where it hangs otherwise), according to dmesg timestamp it is about 1 second before next messages appear. Also last two times I tried it writeout of suspend image was really slow; it was both with and without battery. Reading on resume in really in order of magnitude faster. But manual STD so far works both on AC (with or without battery) or on battery. Of course it is possible that battery gets exhausted during STD, but system is not switched off. Rather I would suspect something like ACPI notification that comes during freeze ... If someone can advice which options to enable I could try netconsole. But likely not before next weekend. signature.asc Description: This is a digitally signed message part.
Re: 2.6.24-rc2: Reported regressions from 2.6.23
On Saturday, 10 of November 2007, Frans Pop wrote: > Rafael J. Wysocki wrote: > > If you know of any other unresolved regressions from 2.6.23, please let me > > know either and I'll add them to the list. > > Probably this issue should be added: > http://lkml.org/lkml/2007/11/1/207 > Latest proposed patch that I'm aware of is at: > http://lkml.org/lkml/2007/11/1/246 > > To be honest, I'm a bit surprised no patch for that has made it into > mainline yet. Added. Thanks, Rafael - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Unionfs: stop using iget() and read_inode()
Andrew, the following small patch is critical to have after: iget-stop-unionfs-from-using-iget-and-read_inode.patch Question: since the above patch isn't in my unionfs.git tree (not until the whole iget series makes it to Linus), then do you prefer if I give you a replacement patch to the above patch, or a small incremental one; either way, you can choose to fold the above and below patches into one. Thanks, Erez. Unionfs: bugfix to initialize unionfs_inode_info node Signed-off-by: Erez Zadok <[EMAIL PROTECTED]> diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c index 7408b0f..d6544f8 100644 --- a/fs/unionfs/super.c +++ b/fs/unionfs/super.c @@ -38,6 +38,7 @@ struct inode *unionfs_iget(struct super_block *sb, unsigned long ino) unionfs_read_lock(sb); + info = UNIONFS_I(inode); memset(info, 0, offsetof(struct unionfs_inode_info, vfs_inode)); info->bstart = -1; info->bend = -1; - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser(2)
Hi Pavel, On Nov 11, 2007 2:44 PM, Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > > A Smack Rule in an "egrep" format is: > > > > > > "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n" > > Perhaps you should make it space, not 'space or tab', and only allow > lowercase permissions? That way, parser will be slightly simpler, and > you'll still have a chance to use 'R' as 'slightly different r'. > Thanks for your care about this. It seems not a lot of people have noticed, but to stop any objections not related to the core smack code, Casey decided to let the parsing be done in a user-space utility that sends the rules to the kernel in a predefined strict format. You can find how the whole story in the smackv11 announcement here: http://article.gmane.org/gmane.linux.kernel.lsm/4463 Regards, -- Ahmed S. Darwish Homepage: http://darwish.07.googlepages.com Blog: http://darwish-07.blogspot.com - 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 Please read the FAQ at http://www.tux.org/lkml/
Strage buffer behaviour
Hi folks, I noticed that the kernel (2.6.23.1) seems to buffer only certain partitions on my system: $ for i in 1 2 3 4 ; do for j in 1 2 ; do dd if=/dev/sda$i of=/dev/null bs=1024k count=100 ; done ; done 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 3.01471 seconds, 34.8 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.86945 seconds, 36.5 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.92038 seconds, 35.9 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 3.00272 seconds, 34.9 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 4.07722 seconds, 25.7 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.0944248 seconds, 1.1 GB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 5.61527 seconds, 18.7 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.331822 seconds, 316 MB/s The dd command reads 100 MB from each partition two times in a row. It looks like sda1 and sda2 are not bufferd (the first 4 dd runs), but sda3 and sda4 are (the last 4 dd runs). The computer is a Mac mini with a 2,5" SATA hard disk. The first 2 partitions contain EFI and MacOS X, and are unused in Linux. The last 2 partitions are an ext3 partition for / and an LVM for the rest of the sytem. Any hints how the dd/buffering behaviour could be explained? The system was mostly idle, and the numbers are reproducible across reboots. Regards, Tino - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] log2.h: Define order_base_2() macro for convenience.
On Sat, 10 Nov 2007 22:53:36 -0500 (EST) Robert P. J. Day wrote: > > Given a number of places in the tree that need to calculate this value > explicitly, might as well just create a macro for it. > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > --- > > run-time tested for the first several values. note that this macro > is defined strictly in terms of rounding *up* -- i've seen no places > in the tree that require this expression to be rounded down, so i'm > not drawing that distinction. > > diff --git a/include/linux/log2.h b/include/linux/log2.h > index c8cf5e8..ed121c0 100644 > --- a/include/linux/log2.h > +++ b/include/linux/log2.h > @@ -190,4 +190,20 @@ unsigned long __rounddown_pow_of_two(unsigned long n) > __rounddown_pow_of_two(n) \ > ) > > +/** > + * order_base_2 - calculate the (rounded up) base 2 order of the argument > + * @n - parameter * @n: argument (mostly changing - to :) > + * > + * The first few values calculated by this routine: > + * ob2(0) = 0 > + * ob2(1) = 0 > + * ob2(2) = 1 > + * ob2(3) = 2 > + * ob2(4) = 2 > + * ob2(5) = 3 > + * ... and so on. > + */ > + > +#define order_base_2(n) ilog2(roundup_pow_of_two(n)) > + > #endif /* _LINUX_LOG2_H */ > > -- --- ~Randy - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Temporary lockup on loopback block device
> > Why are there over-limit dirty pages that no one is writing? > > Please do a sysrq-t, and cat /proc/vmstat during the hang. Those > will show us what exactly is happening. I did and I posted relevant information from my finding --- it looped in balance_dirty_pages. > I've seen this type of hang many times, and I agree with Peter, that > it's probably about loopback, and is fixed in 2.6.24-rc. On 2.6.23 it could happen even without loopback --- loopback just made it happen very often. 2.6.24 seems ok. Mikulas > Thanks, > Miklos > > - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading
On Saturday, 10 of November 2007, Chris Friedhoff wrote: > please cc me, I'm not not subscribed to LKML > > Hello, > > with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but > when I start the system and the suspended systemimage is loaded, it > fails to "activate" this suspended systemimage and continues after some > time with following the normal boot sequence. > > I can sucessfully STD the system with the following sequence > echo platform > /sys/power/disk > echo disk > /sys/power/state > and when I start the laptop the suspended system is sucessfully > restored. > > Both behaviors are reliable reproducable. Thanks for the report. > googling for >"Freezing of tasks failed" swapper< brought > "Nigel Cunningham - PID namespaces break initrd+hibernate combination?" > http://lkml.org/lkml/2007/11/4/140 Yes, this looks similarly. > dmesg output: > <> > RAMDISK: ext2 filesystem found at block 0 > RAMDISK: Loading 2000KiB [1 disk] into ram disk... done. > EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > VFS: Mounted root (ext2 filesystem). > swsusp: Marking nosave pages: 0009f000 - 0010 > swsusp: Basic memory bitmaps created > Clocksource tsc unstable (delta = -128791628 ns) > Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... > Freezing of tasks failed after 20.00 seconds (1 tasks refusing to > freeze): taskPC stack pid father > swapper S c1835a88 0 1 0 > 0046 c0118c80 c1835a88 0004 0001 c011e875 > 0286 c01025a6 c1835b64 c1835a90 > 0001 007b c1835a90 > c0118c80 Call Trace: > [] default_wake_function+0x0/0x10 > [] do_wait+0x335/0xac0 > [] kernel_thread+0x96/0xb0 > [] default_wake_function+0x0/0x10 > [] sys_wait4+0x31/0x40 > [] initrd_load+0x1b3/0x3a0 > [] prepare_namespace+0x98/0x1b0 > [] sys_access+0x1f/0x30 > [] kernel_init+0x166/0x260 > [] ret_from_fork+0x6/0x1c > [] kernel_init+0x0/0x260 > [] kernel_init+0x0/0x260 > [] kernel_thread_helper+0x7/0x18 > === > kthreadd S 038f 0 2 0 > 0046 c0487790 038f c183ff1c c012d81b > c012d7b0 c0104b8f > > Call Trace: > [] kthreadd+0x6b/0xd0 > [] kthreadd+0x0/0xd0 > [] kernel_thread_helper+0x7/0x18 > === > ksoftirqd/0 S 0 3 2 > 0046 fffc c0120f00 c0120f7a > c012d782 c012d740 c0104b8f c183ff3c > > Call Trace: > [] ksoftirqd+0x0/0x80 > [] ksoftirqd+0x7a/0x80 > [] kthread+0x42/0x70 > [] kthread+0x0/0x70 > [] kernel_thread_helper+0x7/0x18 > > <> Can you please attach your kernel configuration file to the bugzilla entry at http://bugzilla.kernel.org/show_bug.cgi?id=9345 ? Thanks, Rafael - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add quirk to set AHCI mode on ICH boards
On 11.11.2007 15:05, Thorsten Leemhuis wrote: > On 10.11.2007 00:32, Matthias Schniedermeyer wrote: > > [...] > > My computer/mainboard @work has such a "broken" BIOS. Of the 5 > > SATA-Ports this MB has only 1 (and 1 "missing" that is reported by > > linux but i can't find on the MB) is configured as AHCI [...] > > There is nothing "broken" here. You have a ICH8 (without R) that drives > four SATA ports, which are handled by ata_piix. > > Then you have a Jmicron JMB363 -- it handles the PATA-Channel and two > SATA-Ports -- one internal (near the battery)/next to the PCI-Slot and a > external eSATA port. Seems you configured it in AHCI-Mode in the > BIOS-Setup. Linux will work just fine if you connect the hard disc to > that port. But if you want to install Windows XP you need a driver from > Jmicron. > > There were BIOSes for the P5B where you could enabled AHCI for the ICH8 > as well. It seems Asus removed it in the later BIOS-versions again as > Intel doesn't provide a Windows-AHCI driver for the basic ICH8. I don't have an P5B @work, but i guess MSI cooks with water too. :-) But i have a (1 year old) P5B @home and it is exactly like you said. My main point is still the same, if Linux could force AHCI mode, i wouldn't have to switch between those modes when booting Wintendo to play some games. (And i could use AHCI @work where i can't switch it in BIOS) On a side note, with the mainboard i had before the P5B (ASUS, 925X Chipset, ICH 6 or 7) Linux worked in AHCI-mode and Wintendo worked also without problems. (IOW: I did not need to switch modes in BIOS!) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 regression: hibernation hangs on "Suspending console" in low-battery condition
On Sunday, 11 of November 2007, Andrey Borzenkov wrote: > On Monday 05 November 2007, Andrey Borzenkov wrote: > > Notice "hung" not "hangs". This happened so far only once - when low > > battery > > condition triggered suspend to disk. I was not able to reproduce it after > > this running on AC. > > > > Just in case it rings the bell for someone. This is not suspend regression > > reported earlier by Jens - I do not even have SATA nor is using libata > > drivers. > > > > This happened second time, now with 2.6.24-rc2. I have kpowersave configured > to initiate suspend-to-disk on low battery. Suspend-to-disk is initiated, > but system stops after Suspending console line. Suspend image is not created. > > This did work before although I do not name exact version. > > I am rather at loss how to proceed further ... any idea? dmesg and config > attached just in case. The problem is that hibernation works when I initiate > it manually ... Have you tried it with the battery removed? - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/24] make vsmp a paravirt client
On Fri, Nov 09, 2007 at 04:43:05PM -0200, Glauber de Oliveira Costa wrote: > This patch makes vsmp a paravirt client. It now uses the whole > infrastructure provided by pvops. When we detect we're running > a vsmp box, we change the irq-related paravirt operations (and so, > it have to happen quite early), and the patching function The PARAVIRT ifdefs look wrong. Surely you don't need them at all because it cannot work at all without paravirt. Also you got some white space damage. And the "EM64T based comment" is wrong because there are AMD based vSMPs too. -Andi - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] netx: remove bogus defconfig patch with wrong -p
On Sun, 11 Nov 2007, Russell King wrote: > > So what's happening with this? Who's going to merge it? Well, I already removed the bogus file. But whether the defconfig file in arch/arm needs updating or not is up to you guys. Linus - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/capability.c get_task_comm compile error (MMOTM)
In message <[EMAIL PROTECTED]>, Ingo Molnar writes:
>
> * Erez Zadok <[EMAIL PROTECTED]> wrote:
>
> > Small patch below fixes compile error.
>
> > + char name[sizeof(current->comm)];
> > warned++;
> > printk(KERN_INFO
> >"warning: process `%s' sets w/ old libcap\n",
> > - get_task_comm(current));
> > + get_task_comm(name, current));
>
> that's buggy - get_task_comm() returns void.
>
> the proper fix would be to first do a get_task_comm() then pass in
> 'name' as an argument to printk.
>
> Ingo
Ingo, I don't see how it can return NULL. This is what get_task_comm looks
like in MMOTM-2007-11-10-19-05:
char *get_task_comm(char *buf, struct task_struct *tsk)
{
/* buf must be at least sizeof(tsk->comm) in size */
task_lock(tsk);
strncpy(buf, tsk->comm, sizeof(tsk->comm));
task_unlock(tsk);
return buf;
}
The only way it'd return NULL is if a null buf was passed, in which case the
strncpy will oops first.
Erez.
-
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
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc: Add support for PORTA sor and PORTB odr registers
PORTA has an so register and PORTB had an odr register, as well.
However, the PORTB odr register is only 16bit.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/commproc.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index f6a6378..a9f5fcf 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -438,6 +438,13 @@ static void cpm1_set_pin32(int port, int pin, int flags)
else
clrbits32(>par, pin);
+ if (port == CPM_PORTB) {
+ if (flags & CPM_PIN_OPENDRAIN)
+ setbits16(_immr->im_cpm.cp_pbodr, pin);
+ else
+ clrbits16(_immr->im_cpm.cp_pbodr, pin);
+ }
+
if (port == CPM_PORTE) {
if (flags & CPM_PIN_SECONDARY)
setbits32(>sor, pin);
@@ -471,7 +478,7 @@ static void cpm1_set_pin16(int port, int pin, int flags)
else
clrbits16(>par, pin);
- if (port == CPM_PORTC) {
+ if ((port == CPM_PORTA) || (port == CPM_PORTC)) {
if (flags & CPM_PIN_SECONDARY)
setbits16(>sor, pin);
else
--
1.5.3.5
-
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
Please read the FAQ at http://www.tux.org/lkml/
laptop reboots right after hibernation
echo disk > /sys/power/state successfully saves that state to the disk, but just as the laptop is about to turn itself off, it reboots (successfully, so the hibernation/resume process works well, even with X running! which is awesome :) ). But I'd rather like the computer turned off after I hibernate it. Where could the problem be? It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few days, both suspend and hibernate worked there (with one or two crashes, probably due to X, I've read that the intel driver got some suspend/resume improvements recently). Now I'm running gentoo, kernel 2.6.24-rc2. I'm using newer versions of almost all software now compared to the ubuntu system. tom - 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 Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc: Add EXPORT_SYMBOL for symbols required by fs_enet and cpm_uart
fs_enet and cpm_uart need symbols from commproc.c (for CPM1) or cpm2_common.c. Add EXPORT_SYMBOL for cpmp, cpm_setbrg and cpm2_immr, so the drivers can be compiled as modules. Building modules, stage 2. MODPOST 5 modules ERROR: "cpm2_immr" [drivers/net/fs_enet/fs_enet.ko] undefined! ERROR: "cpmp" [drivers/net/fs_enet/fs_enet.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/commproc.c|3 +++ arch/powerpc/sysdev/cpm2_common.c |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c index f6a6378..d5a0dcf 100644 --- a/arch/powerpc/sysdev/commproc.c +++ b/arch/powerpc/sysdev/commproc.c @@ -51,6 +51,8 @@ static void m8xx_cpm_dpinit(void); static uint host_buffer; /* One page of host buffer */ static uint host_end;/* end + 1 */ cpm8xx_t __iomem *cpmp; /* Pointer to comm processor space */ +EXPORT_SYMBOL(cpmp); + immap_t __iomem *mpc8xx_immr; static cpic8xx_t __iomem *cpic_reg; @@ -302,6 +304,7 @@ cpm_setbrg(uint brg, uint rate) out_be32(bp, (((BRG_UART_CLK_DIV16 / rate) - 1) << 1) | CPM_BRG_EN | CPM_BRG_DIV16); } +EXPORT_SYMBOL(cpm_setbrg); #ifndef CONFIG_PPC_CPM_NEW_BINDING /* diff --git a/arch/powerpc/sysdev/cpm2_common.c b/arch/powerpc/sysdev/cpm2_common.c index 859362f..4ed5df6 100644 --- a/arch/powerpc/sysdev/cpm2_common.c +++ b/arch/powerpc/sysdev/cpm2_common.c @@ -51,11 +51,13 @@ static void cpm2_dpinit(void); #endif cpm_cpm2_t __iomem *cpmp; /* Pointer to comm processor space */ +EXPORT_SYMBOL(cpmp); /* We allocate this here because it is used almost exclusively for * the communication processor devices. */ cpm2_map_t __iomem *cpm2_immr; +EXPORT_SYMBOL(cpm2_immr); #define CPM_MAP_SIZE(0x4) /* 256k - the PQ3 reserve this amount of space for CPM as it is larger @@ -117,6 +119,7 @@ cpm_setbrg(uint brg, uint rate) cpm2_unmap(bp); } +EXPORT_SYMBOL(cpm_setbrg); /* This function is used to set high speed synchronous baud rate * clocks. -- 1.5.3.5 - 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 Please read the FAQ at http://www.tux.org/lkml/
