Re: [patch] rfc: introduce /dev/hugetlb
> > But for non-programming reasons, we're just not there yet: people want to > program direct to the kernel interfaces simply because of the > distribution/coordination problems with libraries. It would be nice to fix > that problem. What is then needed to get a small subset of user-space in the kernel-development cycle? Maybe a topic worth to take up at LKS... The build system is anyway ready but that the smallest issue of all :-( 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/
Re: [2/5] 2.6.21-rc4: known regressions (v2)
Ray, On Fri, 2007-03-23 at 17:14 -0700, Ray Lee wrote: > (I wondered about the IPI on a UP system, seemed a bit weird :-).) > > Works great, booting both with NOAPIC and without. *Much* thanks for > debugging this while you're also handling a bunch of other issues at > the same time. Thank you for debugging and excellent problem descriptions ! > Patch reproduced below, with an acked-by (and, uhm, a couple of spelling > fixes in the description -- don't hate me, 'kay?). I know that my English sucks. Thanks, tglx - 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: [QUICKLIST 1/5] Quicklists for page table pages V4
On Fri, 23 Mar 2007 10:54:12 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote: > Here are the results of aim9 tests on x86_64. There are some minor > performance > improvements and some fluctuations. There are a lot of numbers there - what do they tell us? > 2.6.21-rc4 bare > 2.6.21-rc4 x86_64 quicklist So what has changed here? From a quick look it appears that x86_64 is using get_zeroed_page() for ptes, puds and pmds and is using a custom quicklist for pgds. After your patches, x86_64 is using a common quicklist allocator for puds, pmds and pgds and continues to use get_zeroed_page() for ptes. Or something totally different, dunno. I tire. My question is pretty simple: how do we justify the retention of this custom allocator? Because simply removing it is the preferable way of fixing the SLUB problem. - 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: introduce /dev/hugetlb
On Fri, 23 Mar 2007 22:32:31 -0700 "Nish Aravamudan" <[EMAIL PROTECTED]> wrote: > > Probably the kernel team should be maintaining, via existing processes, a > > separate libkernel project, to fix these distributional problems. The > > advantage in this case is of course that our new hugetlb functionality > > would be available to people on 2.6.18 kernels, not only on 2.6.22 and > > later. > > That sounds like a good idea. For this hugetlb stuff, though, I plan > on simply taking advantage of /dev/hugetlb (or whatever it is called) > if it exists, and otherwise falling back to hugetlbfs (which > admittedly requires some admin intervention (mounting hugetlbfs, > permissions, and such), but then again, so does using hugepages in the > first place (either at boot-time or via /proc/sys/vm/nr_hugepages)). > Is that what you mean by available to 2.6.18 (falling back to > hugetlbfs) and 2.6.22 (using the chardev)? My point is: a) Ken observes that obtaining private hugetlb memory via hugetlbfs involves "fuss". b) the libhugetlbfs maintainers then go off and implement a no-fuss way of doing this. c) voila, people can now use the new no-fuss interface on older kernels. Whereas Ken's kernel patch would require that they upgrade to a new kernel. It wasn't a vary big point ;) I'm assuming that users find that upgrading libhugetlb is less costly than upgrading their kernel. > > Am I wrong? > > I don't think so. And hugepages are hard enough to use (and with > enough architecture specific quirks) that it was worth creating > libhugetlbfs. While having some nice features like segment remapping > and overriding malloc, it is also meant to provide an API that is > useful for general use of hugepages: we currently export > gethugepagesize(), hugetlbfs_test_path() (verify a path is a valid > hugetlbfs mount), hugetlbfs_find_path() (gives you the hugetlbfs > mount) and hugetlbfs_unlinked_fd() (gives you an unlinked file in the > hugetlbfs mount). > > Then again, maybe I'm missing some much bigger picture here and you > meant something completely different -- sorry for the noise in that > case :/ You got it. The fact that a kernel interface is "hard to use" really shouldn't be an issue for us, because that hardness can be addressed in libraries. Kernel interfaces should be good, and complete, and maintainable, and etcetera. If that means that they end up hard to use, well, that's not necessarily a bad thing. I'm not sure that in all cases we want to be optimising for ease-of-use just because libraries-are-hard. But for non-programming reasons, we're just not there yet: people want to program direct to the kernel interfaces simply because of the distribution/coordination problems with libraries. It would be nice to fix that problem. For a counter-example, look at futexes. Their kernel interfaces are *damned* hard to use. But practically nobody is affected by that because glibc solved the problem and programmers just use the pthread API. More of this, please ;) - 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: Linux-VServer example results for sharing vs. separate mappings ...
On Fri, 23 Mar 2007 20:30:00 +0100 Herbert Poetzl <[EMAIL PROTECTED]> wrote: > > Hi Eric! > Hi Folks! > > here is a real world example result from one of my tests > regarding the benefit of sharing over separate memory > > the setup is quite simple, a typical machine used by > providers all over the world, a dual Pentium D 3.2GHz > with 4GB of memory and a single 160GB SATA disk running > a Linux-VServer kernel (2.6.19.7-vs2.2.0-rc18) > > the Guest systems used are Mandriva 2007 guests with > syslog, crond, sshd, apache, postfix and postgresql > installed and running (all in all 17 processes per guest) > > the disk space used by one guests is roughly 148MB > > in addition to that, a normal host system is running > with a few daemons (like sshd, httpd, postfix ...) > > > the first test setup is starting 200 of those guests > one after the other and measuring the memory usage > before and after the guest did start, as well as > recording the time used to start them ... > > this is done right after the machine was rebooted, in > one test with 200 separate guests (i.e. 200 x 148MB) > and in a second run with 200 unified guests (which > means roughly 138MB of shared files) Please define your terms. What is a "separated guest", what is a "unified guest" and how do they differ? If a "separated" guest is something in which separate guests will use distinct physical pages to cache the contents of /etc/passwd (ie: a separate filesystem per guest) then I don't think that's interesting information, frankly. Because nobody (afaik) is proposing that pagecache be duplicated across instances in this fashion. We obviously must share pagecache across instances - if we didn't want to do that then we could do something completely dumb such as use xen/kvm/vmware/etc ;) The issue with pagecache (afaik) is that if we use containers based on physical pages (an approach which is much preferred by myself) then we can get in a situation where a pagecache page is physically in container A, is not actually used by any process in container A, but is being releatedly referenced by processes which are in other containers and hence unjustly consumes resources in container A. How significant a problem this is likely to be I do not know. And there are perhaps things which we can do about 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: [patch] rfc: introduce /dev/hugetlb
On 3/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Fri, 23 Mar 2007 01:44:38 -0700 "Ken Chen" <[EMAIL PROTECTED]> wrote: > On 3/21/07, Adam Litke <[EMAIL PROTECTED]> wrote: > > The main reason I am advocating a set of pagetable_operations is to > > enable the development of a new hugetlb interface. During the hugetlb > > BOFS at OLS last year, we talked about a character device that would > > behave like /dev/zero. Many of the people were talking about how they > > just wanted to create MAP_PRIVATE hugetlb mappings without all the fuss > > about the hugetlbfs filesystem. /dev/zero is a familiar interface for > > getting anonymous memory so bringing that model to huge pages would make > > programming for anonymous huge pages easier. > > I think we have enough infrastructure currently in hugetlbfs to > implement what Adam wants for something like a /dev/hugetlb char > device (except we can't afford to have a zero hugetlb page since it > will be too costly on some arch). > > I really like the idea of having something similar to /dev/zero for > hugetlb page. So I coded it up on top of existing hugetlbfs. The > core change is really small and half of the patch is really just > moving things around. I think this at least can partially fulfill the > goal. Standing back and looking at this... afaict the whole reason for this work is to provide a quick-n-easy way to get private mappings of hugetlb pages. With the emphasis on quick-n-easy. I agree. We can do the same with hugetlbfs, but that involves (horror) "fuss". Yes. The way to avoid "fuss" is of course to do it once, do it properly then stick it in a library which everyone uses. That's sort of what libhugetlbfs (http://sourceforge.net/projects/libhugetlbfs for stable releases, http://libhugetlbfs.ozlabs.org/ for development snapshots/git tree) is for; while it currently only tries to abstract/provide functionality via hugetlbfs, that's mostly because that is the only interface available (or was, pending some sort of char dev being merged). But libraries are hard, for a number of distributional reasons. It is easier for us to distribute this functionality within the kernel. In fact, if Linus's tree included a ./userspace/libkernel/libhugetlb/ then we'd probably provide this functionality in there. libhugetlbfs is available for both SLES10 and RHEL5. This comes up regularly, and it's pretty sad. I agree. There is simply some functionality that is *very* closely tied to the kernel. Probably the kernel team should be maintaining, via existing processes, a separate libkernel project, to fix these distributional problems. The advantage in this case is of course that our new hugetlb functionality would be available to people on 2.6.18 kernels, not only on 2.6.22 and later. That sounds like a good idea. For this hugetlb stuff, though, I plan on simply taking advantage of /dev/hugetlb (or whatever it is called) if it exists, and otherwise falling back to hugetlbfs (which admittedly requires some admin intervention (mounting hugetlbfs, permissions, and such), but then again, so does using hugepages in the first place (either at boot-time or via /proc/sys/vm/nr_hugepages)). Is that what you mean by available to 2.6.18 (falling back to hugetlbfs) and 2.6.22 (using the chardev)? Am I wrong? I don't think so. And hugepages are hard enough to use (and with enough architecture specific quirks) that it was worth creating libhugetlbfs. While having some nice features like segment remapping and overriding malloc, it is also meant to provide an API that is useful for general use of hugepages: we currently export gethugepagesize(), hugetlbfs_test_path() (verify a path is a valid hugetlbfs mount), hugetlbfs_find_path() (gives you the hugetlbfs mount) and hugetlbfs_unlinked_fd() (gives you an unlinked file in the hugetlbfs mount). Then again, maybe I'm missing some much bigger picture here and you meant something completely different -- sorry for the noise in that case :/ Thanks, Nish - 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] Avoid time_offset overflows
Hi, On Fri, 23 Mar 2007, john stultz wrote: > @@ -314,8 +314,8 @@ #endif > freq_adj += time_freq; > freq_adj = min(freq_adj, (s64)MAXFREQ_NSEC); > time_freq = max(freq_adj, (s64)-MAXFREQ_NSEC); > - time_offset = (time_offset / NTP_INTERVAL_FREQ) > - << SHIFT_UPDATE; > + do_div(time_offset, NTP_INTERVAL_FREQ); > + time_offset <<= SHIFT_UPDATE; > } /* STA_PLL */ > } /* txc->modes & ADJ_OFFSET */ > if (txc->modes & ADJ_TICK) This is wrong, time_offset is signed and do_div is unsigned. In general I planned to do the same change, but the do_div API could use a little cleanup to provide some clear function for signed/unsigned divide (hopefully with a better name than div_long_long_rem_signed or do_div_llr). 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: [QUICKLIST 1/5] Quicklists for page table pages V4
On Fri, 23 Mar 2007 22:39:24 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
>
> > but it crashes early in the page allocator (i386) and I don't see why. It
> > makes me wonder if we have a use-after-free which is hidden by the presence
> > of the quicklist buffering or something.
>
> Does CONFIG_DEBUG_PAGEALLOC catch it?
It'll be a while before I can get onto doing anything with this.
I do have an oops trace:
kjournald starting. Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 296k freed
Write protecting the kernel read-only data: 921k
BUG: unable to handle kernel paging request at virtual address 00100104
printing eip:
c015b676
*pde =
Oops: 0002 [#1]
SMP
Modules linked in:
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010002 (2.6.21-rc4 #6)
EIP is at get_page_from_freelist+0x166/0x3d0
eax: c1b110bc ebx: 0001 ecx: 00100100 edx: 00200200
esi: c1b11090 edi: c04cc500 ebp: f67d3b88 esp: f67d3b34
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process default.hotplug (pid: 872, ti=f67d2000 task=f6748030 task.ti=f67d2000)
Stack: 0001 0044 c067eae8 0001 0001 c04cc6c0 c04cc4a0
0001 000284d0 c04ccb78 0286 0001 f67b6000
0001 c04cc4a0 f6748030 84d0 f67d3bcc c015b92e 0044
Call Trace:
[] show_trace_log_lvl+0x1a/0x30
[] show_stack_log_lvl+0xa9/0xd0
[] show_registers+0x1e9/0x2f0
[] die+0x115/0x250
[] do_page_fault+0x27e/0x630
[] error_code+0x7c/0x84
[] __alloc_pages+0x4e/0x2f0
[] pte_alloc_one+0x14/0x20
[] __pte_alloc+0x1b/0xa0
[] __handle_mm_fault+0x7fd/0x940
[] do_page_fault+0x119/0x630
[] error_code+0x7c/0x84
[] padzero+0x1f/0x30
[] load_elf_binary+0x76e/0x1a80
[] search_binary_handler+0x97/0x220
[] load_script+0x1d6/0x220
[] search_binary_handler+0x97/0x220
[] do_execve+0x14f/0x200
[] sys_execve+0x2e/0x80
[] sysenter_past_esp+0x5d/0x99
===
Code: 06 8b 4d c0 8b 7d c8 8d 04 81 8d 44 82 20 01 c7 9c 8f 45 dc fa e8 4b f4
fd ff 8b 07 85 c0 74 7b 8b 47 0c 8b 08 8d 70 d4 8b 50 04 <89> 51 04 89 0a c7 40
04 00 02 20 00 c7 00 00 01 10 00 ff 0f 8b
EIP: [] get_page_from_freelist+0x166/0x3d0 SS:ESP 0068:f67d3b34
Not pretty. That was bare mainline+christoph's patches+that patch which I sent.
Using http://userweb.kernel.org/~akpm/config-vmm.txt
-
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.21-rc4-mm1
On Fri, 23 Mar 2007 11:10:29 +0100 Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Thu, 22 Mar 2007 13:55:51 -0500,
> Larry Finger <[EMAIL PROTECTED]> wrote:
>
> > Cornelia Huck wrote:
> > > On Thu, 22 Mar 2007 07:23:06 -0500,
> > >
> > > This would indicate that dev_uevent had been called. But how could
> > > kobject_uevent then return an error without moaning about an uevent()
> > > error code? Maybe the following debug patch could shed some light on
> > > this (all moaning is prefixed with kobject_uevent_env, so it should be
> > > easy to spot)...
> >
> > I applied the debug patch, but I don't see any error codes being returned.
> > This time I also got the
> > General Protection Faults. An excerpt of the log is attached.
>
> Hm, I think I have an idea about what happened.
>
> The firmware class tried to suppress the first KOBJ_ADD uevent by
> returning -ENODEV in firmware_uevent if FW_STATUS_READY was not set.
> This only worked as long as the return code of kobject_uevent was not
> checked in device_add. hack-to-make-wireless-work.patch made that first
> uevent return successfully, but this possible triggered some udev rule
> too early, leading to firmware load failures.
>
> The following (completely untested) patch uses uevent_suppress to stop
> the uevent from being generated during device_add. Does this work for
> you?
>
> ---
> drivers/base/firmware_class.c |2 ++
> 1 file changed, 2 insertions(+)
>
> --- linux-2.6.orig/drivers/base/firmware_class.c
> +++ linux-2.6/drivers/base/firmware_class.c
> @@ -333,6 +333,7 @@ static int fw_register_device(struct dev
> f_dev->parent = device;
> f_dev->class = _class;
> dev_set_drvdata(f_dev, fw_priv);
> + f_dev->uevent_suppress = 1;
> retval = device_register(f_dev);
> if (retval) {
> printk(KERN_ERR "%s: device_register failed\n",
> @@ -385,6 +386,7 @@ static int fw_setup_device(struct firmwa
> set_bit(FW_STATUS_READY, _priv->status);
> else
> set_bit(FW_STATUS_READY_NOHOTPLUG, _priv->status);
> + f_dev->uevent_suppress = 0;
> *dev_p = f_dev;
> goto out;
hm.
Would I be right in guessing that this was all triggered by
uevent-improve-error-checking-and-handling.patch?
If so, do you think I should labour on with
uevent-improve-error-checking-and-handling.patch plus your fix, or should I
drop the lot? (I'm inclined toward the latter, but I'm still not
sure which patch(es) need to be dropped).
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: [patch] rfc: introduce /dev/hugetlb
On Fri, 23 Mar 2007 01:44:38 -0700 "Ken Chen" <[EMAIL PROTECTED]> wrote: > On 3/21/07, Adam Litke <[EMAIL PROTECTED]> wrote: > > The main reason I am advocating a set of pagetable_operations is to > > enable the development of a new hugetlb interface. During the hugetlb > > BOFS at OLS last year, we talked about a character device that would > > behave like /dev/zero. Many of the people were talking about how they > > just wanted to create MAP_PRIVATE hugetlb mappings without all the fuss > > about the hugetlbfs filesystem. /dev/zero is a familiar interface for > > getting anonymous memory so bringing that model to huge pages would make > > programming for anonymous huge pages easier. > > I think we have enough infrastructure currently in hugetlbfs to > implement what Adam wants for something like a /dev/hugetlb char > device (except we can't afford to have a zero hugetlb page since it > will be too costly on some arch). > > I really like the idea of having something similar to /dev/zero for > hugetlb page. So I coded it up on top of existing hugetlbfs. The > core change is really small and half of the patch is really just > moving things around. I think this at least can partially fulfill the > goal. Standing back and looking at this... afaict the whole reason for this work is to provide a quick-n-easy way to get private mappings of hugetlb pages. With the emphasis on quick-n-easy. We can do the same with hugetlbfs, but that involves (horror) "fuss". The way to avoid "fuss" is of course to do it once, do it properly then stick it in a library which everyone uses. But libraries are hard, for a number of distributional reasons. It is easier for us to distribute this functionality within the kernel. In fact, if Linus's tree included a ./userspace/libkernel/libhugetlb/ then we'd probably provide this functionality in there. This comes up regularly, and it's pretty sad. Probably the kernel team should be maintaining, via existing processes, a separate libkernel project, to fix these distributional problems. The advantage in this case is of course that our new hugetlb functionality would be available to people on 2.6.18 kernels, not only on 2.6.22 and later. Am I wrong? - 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: [ckrm-tech] [PATCH 7/7] containers (V7): Container interface to nsproxy subsystem
On Mon, Feb 12, 2007 at 12:15:28AM -0800, [EMAIL PROTECTED] wrote:
> +/*
> + * Rules: you can only create a container if
> + * 1. you are capable(CAP_SYS_ADMIN)
> + * 2. the target container is a descendant of your own container
> + */
> +static int ns_create(struct container_subsys *ss, struct container *cont)
> +{
> + struct nscont *ns;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
Does this check break existing namespace semantics in a subtle way?
It now requires that unshare() of namespaces by any task requires
CAP_SYS_ADMIN capabilities.
clone(.., CLONE_NEWUTS, ..)->copy_namespaces()->ns_container_clone()->
->container_clone()-> .. -> container_create() -> ns_create()
Earlier, one could unshare his uts namespace w/o CAP_SYS_ADMIN
capabilities. Now it is required. Is that fine? Don't know.
I feel we can avoid this check totally and let the directory permissions
take care of these checks.
Serge, what do you think?
--
Regards,
vatsa
-
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.6.21-rc3] pci: set pci=bfsort for PowerEdge R900
This patch automatically enables pci=bfsort for the Dell PowerEdge
R900. This is necessary to ensure the onboard NICs enumerate in the
proper order, similar to the other systems already on the list.
I'd appreciate this being applied before 2.6.21-final if possible.
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
diff --git a/arch/i386/pci/common.c b/arch/i386/pci/common.c
index 1bb0693..9484366 100644
--- a/arch/i386/pci/common.c
+++ b/arch/i386/pci/common.c
@@ -193,6 +193,14 @@ static struct dmi_system_id __devinitdat
},
{
.callback = set_bf_sort,
+ .ident = "Dell PowerEdge R900",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge R900"),
+ },
+ },
+ {
+ .callback = set_bf_sort,
.ident = "HP ProLiant BL20p G3",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "HP"),
-
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: sysfs reclaim crash
On Fri, Mar 23, 2007 at 12:43:27PM -0700, Ethan Solomita wrote:
> I ran stress testing overnight and came up with a similar failure
> (s_dentry == NULL) but in a different location. A NULL pointer
> dereference happened in sysfs_readdir():
>
> |if (next->s_dentry)
> |ino =
> next->s_dentry->d_inode->i_ino;
>
> It seems that d_inode was NULL. I don't have the pointer to d_inode
> to look at, but I have next and, lo and behold, its s_dentry is now
> NULL, which it clearly wasn't when the if-clause above ran.
>
> I tried to reconstruct the sysfs_dirents starting with "next". I
> filled in all the structure contents that I had data for:
>
> sysfs_dirent 0x81000fc61690:
> s_count 1
> s_sibling 81000fc616e8 / 81000e0c7468
> s_children 81000fc616a8 / 81000fc616a8
> s_element 81000f4ad1b0
> DOR__ATA1RTS
> 8800b600
> 124
> s_type 4
> s_mode 8124
> s_dentryNULL
> s_iattr NULL
> s_event 0
>
> s_sibling.prev:
> s_count 1
> s_sibling 81000fc61738 / 81000fc61698
> s_children 81000fc616f8 / 81000fc616f8
> s_element 81000f4ad148
> s_type 4
> s_mode 8124
>
>
> s_sibling.next:
> s_count 1
> s_sibling 81000fc61698 / 81000fc61648
> s_children 81000e0c7478 / 81000e0c7478
> s_element NULL
> s_type 0
> s_mode 0
> s_dentryNULL
> s_iattr NULL
> s_event 0
>
> s_sibling.next.next:
> s_count 1
> s_sibling 81000e0c7468 / 81000fc615f8
> s_children 81000fc61658 / 81000fc61658
> s_element 81000f4ad218
> DOR__ATA1RTS
> 8800b600
> 124
> s_type 4
> s_mode 8124
> s_dentryNULL
> s_iattr NULL
> s_event 0
>
> s_sibling.next.next.next:
> s_count 1
> s_sibling 81000fc61648 / 81000fc610f8
> s_children 81000fc61608 / 81000fc61608
> s_element 81000f4ad280
> CK??ATCR
> 8800b600
> 124
> s_type 4
> s_mode 8124
> s_dentryNULL
> s_iattr NULL
> s_event 0
>
> I should acknowledge that this is based upon 2.6.18 with some newer
> code backported. If there are fixes since 2.6.18 that we should know
> about I can try backporting them into our kernel.
>
> Thanks,
> -- Ethan
Hi Ethan,
Thank you very much for the crash data. This is helpful. Could you please
test the appended patch. Here we avoid modifying s_dentry in sysfs_d_iput()
and also uses iunique() in sysfs_readdir() instead of accessing s_dentry
to get the inode number.
Though I was not able to recreate this race without the patch, but I am
running this patch successfully for more than 6 hrs now with the following
loops parallely on a 4-way SMP system. So, at least it has not done anything
bad.
1. while true; do insmod drivers/net/dummy.ko ; rmmod dummy; done
2. [EMAIL PROTECTED] net]# pwd
/sys/class/net
[EMAIL PROTECTED] net]# while true; do find | xargs cat > /dev/null; done
3. [EMAIL PROTECTED] sys]# pwd
/sys
[EMAIL PROTECTED] sys]# while true; do ls -liR; done
Also, CC-ed Viro and lkml for feedback.
Thanks
Maneesh
o sysfs_d_iput() is invoked in dentry reclaim path under memory pressure. This
happens without i_mutex. It also nullifies s_dentry just to indicate that
the associated dentry is evicted. sysfs_readdir() access the s_dentry,
and gets the inode number from the associated dentry, if there is one, else
it invokes iunique(). This can create a race situation, and crash while
accessing the dentry/inode in sysfs_readdir().
o The following patch always use i_unique() to get the inode number. This
is ok as sysfs doesnot have permanent inode numbering. It could be slower
but avoids the above mentioned race.
o This also avoids the now unnecessary s_dentry in sysfs_d_iput().
Signed-off-by: Maneesh Soni <[EMAIL PROTECTED]>
---
linux-2.6.21-rc4-git8-maneesh/fs/sysfs/dir.c |6 +-
1 files changed, 1 insertion(+), 5 deletions(-)
diff -puN fs/sysfs/dir.c~fix-sysfs-reclaim-race fs/sysfs/dir.c
--- linux-2.6.21-rc4-git8/fs/sysfs/dir.c~fix-sysfs-reclaim-race 2007-03-24
02:06:38.0 +0530
+++ linux-2.6.21-rc4-git8-maneesh/fs/sysfs/dir.c2007-03-24
02:09:26.0 +0530
@@ -20,7 +20,6 @@ static void sysfs_d_iput(struct dentry *
if (sd) {
BUG_ON(sd->s_dentry != dentry);
- sd->s_dentry = NULL;
sysfs_put(sd);
}
iput(inode);
@@ -538,10 +537,7 @@ static int sysfs_readdir(struct file * f
name = sysfs_get_name(next);
len = strlen(name);
- if (next->s_dentry)
- ino = next->s_dentry->d_inode->i_ino;
-
Re: 2.6.21-rc4-mm1
Zan Lynx wrote: > > It may have partly been a problem of having half of softmac and half > devicescape. I'm not entirely sure what udev did. > > I tried a patch for the Sonic Silicon that was posted and I turned off > all the configuration for the softmac driver. > > It isn't crashing right now but 802.11 isn't working either. I may get > a chance this weekend to try some things with it, and some different > firmware sets. That is my experience with a 4311. It does the open authentication and associates, but the WPA authentication step times out and I never get connected. > If the new bcm43xx drivers do not support 802.11b at all and never will, > I missed the documentation. Someone should add that to Kconfig. Yes it should. Until bcm43xx-mac80211 got picked up by -mm, it was only used within the bcm43xx group and that was understood in that circle. It has just been decided that the softmac version of the driver will be renamed bcm4301 and be converted to use mac80211. When bcm43xx-mac80211 goes mainline, bcm4301 will be restricted to 802.11b-only cards. That is the way we will support the older cards. The reason for a separate driver is that the bcm4301 and bcm4303 do not have sufficient memory to run the latest firmware (V4), and bcm43xx-mac80211 only uses that firmware; whereas bcm4301 will use the older V3 firmware. 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/
Re: [patch] cache pipe buf page address for non-highmem arch
On Fri, Mar 23, 2007 at 10:14:52AM +, Christoph Hellwig wrote: > I think you're fixing the symptom here and not the cause. If calculating > the virtual address of a page is so expensive on your setup it should > define WANT_PAGE_VIRTUAL and we should always cache the virtual address > in struct page. There's a lot more code, epecially in filesystems that's > rather upset about a slow page_address. Andi shot that down when I brought it up a while ago, as it does show up in profiles for networking and other code paths. His argument is that the loss of memory is excessive. Personally, I think the benefits of a 64 byte struct page on x86-64 outweigh the memory loss, as it means page index to address translations are a simple shift. -ben -- "Time is of no importance, Mr. President, only life is important." Don't Email: <[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: [PATCH] sysctl: vfs_cache_divisor
On Mar 23, 2007, at 20:45:21, Kyle Moffett wrote:
On Mar 23, 2007, at 16:59:02, H. Peter Anvin wrote:
Randy Dunlap wrote:
That makes a lot of sense to me. It gives us finer-grained
control without having to support fixed-point data. I've been
working on the fixed-point data patch, but I'm going to give this
method some time also, to see how it looks in code (instead of
just thinking about it).
Well, to be specific, it actually is the same thing with different
syntax (38.55 or 3855/100).
/* On input: reduce num/den but retain old values for display
purposes */
gcd = euclid(, );
num = inputnum/gcd;
den = inputden/gcd;
Whoops, if I divide inputnum and inputden by gcd I don't need to pass
by reference.
The trivial implementation of euclid (modulo the bogus address-of
operations above) is of course something like this:
unsigned long euclid(unsigned long a, unsigned long b)
{
unsigned long q, r;
if (!a || !b)
return 1;
do {
q = a / b;
r = a % b;
a = b;
b = r;
} while (r);
return a;
}
-
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] cache pipe buf page address for non-highmem arch
On 3/23/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: I think you're fixing the symptom here and not the cause. If calculating the virtual address of a page is so expensive on your setup it should define WANT_PAGE_VIRTUAL and we should always cache the virtual address in struct page. There's a lot more code, epecially in filesystems that's rather upset about a slow page_address. Adding WANT_PAGE_VIRTUAL would be too costly I think as it will expand the sizeof struct page. I would rather go incremental fix on these issues and not blindly increase page struct size. - 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.21-rc regression in mptbase
> On Fri, Mar 23, 2007 at 11:39:12PM +0100, Jan Engelhardt wrote:
> > Hello world,
> >
> >
> > in at least 2.6.21-rc4, one or more of the mptscsi scsi modules is
> > broken with respect to not detecting any harddisk (VMware provides that
> > virtual LSI MPT controller), which means no working system.
> > No problems in 2.6.20.2.
> >...
>
> Could be a bug in the driver or a bug in the emulation exposed by a
> change in the driver.
>
> Can you bisect which change to the driver broke it?
Hello,
it is bug in the emulation. It should be fixed in Workstation 6.0 RC1. If
you
want to use VMware's LSILogic emulation with older products, you need fix below
until
new releases come out (or unless I'll put out binary patch to fix binaries to
return 16 instead of previous value).
Petr
If port reports that no devices are connected to it, assume that 16 devices
are there. Hopefully nobody will ever build device with port but no devices,
and even for them it should be safe as before code always probed 16 devices
regardless of MaxDevices reported by port facts.
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
--- linux/drivers/message/fusion/mptbase.c.orig 2007-03-20 13:47:28.0
-0700
+++ linux/drivers/message/fusion/mptbase.c 2007-03-23 17:45:51.0
-0700
@@ -2564,6 +2564,16 @@
pfacts->IOCStatus = le16_to_cpu(pfacts->IOCStatus);
pfacts->IOCLogInfo = le32_to_cpu(pfacts->IOCLogInfo);
pfacts->MaxDevices = le16_to_cpu(pfacts->MaxDevices);
+ /*
+* VMware emulation is broken, its PortFact's MaxDevices reports value
+* programmed by IOC Init, so if you program IOC Init to 256 (which is
0,
+* as that field is only 8 bit), it reports back 0 in port facts,
instead
+* of 256... And unfortunately using 256 triggers another bug in the
+* code (parallel SCSI can have only 16 devices).
+*/
+ if (pfacts->MaxDevices == 0) {
+ pfacts->MaxDevices = 16;
+ }
pfacts->PortSCSIID = le16_to_cpu(pfacts->PortSCSIID);
pfacts->ProtocolFlags = le16_to_cpu(pfacts->ProtocolFlags);
pfacts->MaxPostedCmdBuffers = le16_to_cpu(pfacts->MaxPostedCmdBuffers);
-
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] cache pipe buf page address for non-highmem arch
On 3/22/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
If we're going to do this then we should also implement pipe_kunmap_atomic().
Relying upon kunmap_atomic() internals like this is weird-looking, and is
fragile
against future changes to kunmap_atomic().
OK, I added the matching pipe_kunmap variants. Now that we have the
matching pair, I made further optimization to make both pipe_kmap and
pipe_kmap_atomic the same because pipe_kmap does not hold any critical
resource that can't sleep. There is no reason to make them different.
Full patch and changelog:
It is really sad that we always call kmap and friends for every pipe
buffer page on 64-bit arch that doesn't use HIGHMEM, or on
configuration that doesn't turn on HIGHMEM.
The effect of calling kmap* is visible in the execution profile when
pipe code is being stressed. It is especially true on amd's x86-64
platform where kmap() has to traverse through numa node index
calculation in order to convert struct page * to kernel virtual
address. It is fairly pointless to perform that calculation repeatly
on system with no highmem (i.e., 64-bit arch like x86-64). This patch
caches kernel pipe buffer page's kernel vaddr to speed up pipe buffer
mapping functions.
There is another suboptimal block in pipe_read() where wake_up is
called twice. I think it was an oversight since in pipe_write(), it
looks like it is doing the right thing.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff --git a/fs/pipe.c b/fs/pipe.c
index ebafde7..4cd1d68 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -21,6 +21,21 @@ #include
#include
#include
+#ifdef CONFIG_HIGHMEM
+#define pipe_kmap kmap
+#define pipe_kmap_atomic kmap_atomic
+#define pipe_kunmapkunmap
+#define pipe_kunmap_atomic kunmap_atomic
+#else /* CONFIG_HIGHMEM */
+static inline void *pipe_kmap(struct page *page)
+{
+ return (void *) page->private;
+}
+#define pipe_kmap_atomic(page, type) pipe_kmap(page)
+#define pipe_kunmap(page) do { } while (0)
+#define pipe_kunmap_atomic(page, type) do { } while (0)
+#endif
+
/*
* We use a start+len construction, which provides full use of the
* allocated memory.
@@ -169,10 +184,10 @@ void *generic_pipe_buf_map(struct pipe_i
{
if (atomic) {
buf->flags |= PIPE_BUF_FLAG_ATOMIC;
- return kmap_atomic(buf->page, KM_USER0);
+ return pipe_kmap_atomic(buf->page, KM_USER0);
}
- return kmap(buf->page);
+ return pipe_kmap(buf->page);
}
void generic_pipe_buf_unmap(struct pipe_inode_info *pipe,
@@ -180,9 +195,9 @@ void generic_pipe_buf_unmap(struct pipe_
{
if (buf->flags & PIPE_BUF_FLAG_ATOMIC) {
buf->flags &= ~PIPE_BUF_FLAG_ATOMIC;
- kunmap_atomic(map_data, KM_USER0);
+ pipe_kunmap_atomic(map_data, KM_USER0);
} else
- kunmap(buf->page);
+ pipe_kunmap(buf->page);
}
int generic_pipe_buf_steal(struct pipe_inode_info *pipe,
@@ -316,6 +331,7 @@ redo:
if (do_wakeup) {
wake_up_interruptible_sync(>wait);
kill_fasync(>fasync_writers, SIGIO, POLL_OUT);
+ do_wakeup = 0;
}
pipe_wait(pipe);
}
@@ -423,6 +439,8 @@ redo1:
ret = ret ? : -ENOMEM;
break;
}
+ page->private = (unsigned long)
+ page_address(page);
pipe->tmp_page = page;
}
/* Always wake up, even if the copy fails. Otherwise
@@ -438,16 +456,16 @@ redo1:
iov_fault_in_pages_read(iov, chars);
redo2:
if (atomic)
- src = kmap_atomic(page, KM_USER0);
+ src = pipe_kmap_atomic(page, KM_USER0);
else
- src = kmap(page);
+ src = pipe_kmap(page);
error = pipe_iov_copy_from_user(src, iov, chars,
atomic);
if (atomic)
- kunmap_atomic(src, KM_USER0);
+ pipe_kunmap_atomic(src, KM_USER0);
else
- kunmap(page);
+ pipe_kunmap(page);
if (unlikely(error)) {
if (atomic) {
-
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] sysctl: vfs_cache_divisor
On Mar 23, 2007, at 16:59:02, H. Peter Anvin wrote: Randy Dunlap wrote: Hi, That makes a lot of sense to me. It gives us finer-grained control without having to support fixed-point data. I've been working on the fixed-point data patch, but I'm going to give this method some time also, to see how it looks in code (instead of just thinking about it). Well, to be specific, it actually is the same thing with different syntax (38.55 or 3855/100). Not quite; if you're dealing with numbers near the limit of the range of "int" then IIRC fixed point is harder to get both good accuracy and good overflow behavior compared to a user-set fraction: Assuming "fraction" is a reduce (num, den) pair, then to compute "result = value * fraction" with optimal accuracy: /* On input: reduce num/den but retain old values for display purposes */ gcd = euclid(, ); num = inputnum/gcd; den = inputden/gcd; valmax = UINT_MAX / num; /* For computation: */ result = (val > valmax) ? (val/den)*num : (val*num)/den; Doing that with fixed point is possible, but a bit more tricky, and you lose accuracy for something like "1/3", which isn't quite equal to "0.". Note that if you aren't really careful with your fixed- point then "0. * 3" ends up being 0: ( * 3) / 1 == / 1 == 0. Rounding is possible but it's better to just let them specify the exact fraction directly and avoid the confusion. Cheers, Kyle Moffett - 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: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 14:54 -0700, Linus Torvalds wrote: > > On Fri, 23 Mar 2007, john stultz wrote: > > > > The incorrect clocksource selection is resolved w/ this patch: > > http://lkml.org/lkml/2007/3/22/287 > > > > There is still an issue of why the PIT clocksource hangs, but for the > > moment the issue its worked-around. > > Hmm.. I haven't seen it until now. Is it waiting for something? Not really. Just waiting for Andrew to pick it up and push it on. thanks -john - 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] Avoid time_offset overflows
I've been seeing some odd NTP behavior recently on a few boxes and
finally narrowed it down to time_offset overflowing when converted to
SHIFT_UPDATE units (which was a side effect from my HZfreeNTP patch).
This patch converts time_offset from a long to a s64 which resolves the
issue.
thanks
-john
Signed-off-by: John Stultz <[EMAIL PROTECTED]>
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index eb12509..eaa3d24 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -32,7 +32,7 @@ #define MAX_TICKADJ_SCALED(((u64)(MAX_T
/* TIME_ERROR prevents overwriting the CMOS clock */
static int time_state = TIME_OK; /* clock synchronization status */
int time_status = STA_UNSYNC; /* clock status bits*/
-static long time_offset; /* time adjustment (ns) */
+static s64 time_offset;/* time adjustment (ns) */
static long time_constant = 2; /* pll time constant*/
long time_maxerror = NTP_PHASE_LIMIT; /* maximum error (us) */
long time_esterror = NTP_PHASE_LIMIT; /* estimated error (us) */
@@ -196,7 +196,7 @@ void __attribute__ ((weak)) notify_arch_
*/
int do_adjtimex(struct timex *txc)
{
- long ltemp, mtemp, save_adjust;
+ long mtemp, save_adjust;
s64 freq_adj, temp64;
int result;
@@ -277,14 +277,14 @@ #endif
time_adjust = txc->offset;
}
else if (time_status & STA_PLL) {
- ltemp = txc->offset * NSEC_PER_USEC;
+ time_offset = txc->offset * NSEC_PER_USEC;
/*
* Scale the phase adjustment and
* clamp to the operating range.
*/
- time_offset = min(ltemp, MAXPHASE * NSEC_PER_USEC);
- time_offset = max(time_offset, -MAXPHASE * NSEC_PER_USEC);
+ time_offset = min(time_offset, (s64)MAXPHASE *
NSEC_PER_USEC);
+ time_offset = max(time_offset, (s64)-MAXPHASE *
NSEC_PER_USEC);
/*
* Select whether the frequency is to be controlled
@@ -297,11 +297,11 @@ #endif
mtemp = xtime.tv_sec - time_reftime;
time_reftime = xtime.tv_sec;
- freq_adj = (s64)time_offset * mtemp;
+ freq_adj = time_offset * mtemp;
freq_adj = shift_right(freq_adj, time_constant * 2 +
(SHIFT_PLL + 2) * 2 - SHIFT_NSEC);
if (mtemp >= MINSEC && (time_status & STA_FLL || mtemp >
MAXSEC)) {
- temp64 = (s64)time_offset << (SHIFT_NSEC - SHIFT_FLL);
+ temp64 = time_offset << (SHIFT_NSEC - SHIFT_FLL);
if (time_offset < 0) {
temp64 = -temp64;
do_div(temp64, mtemp);
@@ -314,8 +314,8 @@ #endif
freq_adj += time_freq;
freq_adj = min(freq_adj, (s64)MAXFREQ_NSEC);
time_freq = max(freq_adj, (s64)-MAXFREQ_NSEC);
- time_offset = (time_offset / NTP_INTERVAL_FREQ)
- << SHIFT_UPDATE;
+ do_div(time_offset, NTP_INTERVAL_FREQ);
+ time_offset <<= SHIFT_UPDATE;
} /* STA_PLL */
} /* txc->modes & ADJ_OFFSET */
if (txc->modes & ADJ_TICK)
@@ -330,7 +330,7 @@ leave: if ((time_status & (STA_UNSYNC|ST
if ((txc->modes & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT)
txc->offset= save_adjust;
else
- txc->offset= shift_right(time_offset, SHIFT_UPDATE)
+ txc->offset= ((long)shift_right(time_offset, SHIFT_UPDATE))
* NTP_INTERVAL_FREQ / 1000;
txc->freq = (time_freq / NSEC_PER_USEC)
<< (SHIFT_USEC - SHIFT_NSEC);
-
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 2.6.20.3] Flush writes to MSI-X table
On Fri, Mar 23, 2007 at 05:28:02PM -0700, Greg KH wrote: > On Fri, Mar 23, 2007 at 05:24:23PM -0700, Williams, Mitch A wrote: > > Greg KH wrote: > > >Well, I'm sure you can agree that it is _very_ late in the 2.6.21 > > >release cycle to expect to get this in for that kernel. How about > > >waiting for 2.6.22 and if it's a big deal, getting it into the > > >2.6.21-stable tree if needed. > > > > > >So far I have not seen any bug reports that this patch would fix, have > > >you? > > > > Well, I've seen several bug reports on this issue -- but they're all > > internal to Intel. > > > > However, we do have here a real bug, which shows up on real hardware, > > which will be released soon. Obviously, I can't discuss release > > schedules, but "soon" is a good word to use. You might find out more if > > you read The Register (wink, wink). > > Ok, but again, as this is something that no one outside of a company can > see, it doesn't really make sense to rush it into the kernel. > > > Given the time frame for release of 2.6.21, I'd be fine with skipping > > 2.6.20.x, and putting this in 2.6.21. But we really don't want to wait > > for 2.6.22. > > I think it needs to wait, especially given that there is no public > hardware yet. > > I'll add this to my queue. No, nevermind, I'll wait till it hits linux-pci and gets review from the people there, as there are a _ton_ of other pending MSI patches that you will need to be aware of, as they might conflict with this patch. Please see the linux-pci archives for details of them. thanks, greg k-h - 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 2.6.20.3] Flush writes to MSI-X table
On Fri, Mar 23, 2007 at 05:24:23PM -0700, Williams, Mitch A wrote: > Greg KH wrote: > >Well, I'm sure you can agree that it is _very_ late in the 2.6.21 > >release cycle to expect to get this in for that kernel. How about > >waiting for 2.6.22 and if it's a big deal, getting it into the > >2.6.21-stable tree if needed. > > > >So far I have not seen any bug reports that this patch would fix, have > >you? > > Well, I've seen several bug reports on this issue -- but they're all > internal to Intel. > > However, we do have here a real bug, which shows up on real hardware, > which will be released soon. Obviously, I can't discuss release > schedules, but "soon" is a good word to use. You might find out more if > you read The Register (wink, wink). Ok, but again, as this is something that no one outside of a company can see, it doesn't really make sense to rush it into the kernel. > Given the time frame for release of 2.6.21, I'd be fine with skipping > 2.6.20.x, and putting this in 2.6.21. But we really don't want to wait > for 2.6.22. I think it needs to wait, especially given that there is no public hardware yet. I'll add this to my queue. thanks, greg k-h - 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.21-rc regression in mptbase
On Fri, Mar 23, 2007 at 11:39:12PM +0100, Jan Engelhardt wrote: > Hello world, > > > in at least 2.6.21-rc4, one or more of the mptscsi scsi modules is > broken with respect to not detecting any harddisk (VMware provides that > virtual LSI MPT controller), which means no working system. > No problems in 2.6.20.2. >... Could be a bug in the driver or a bug in the emulation exposed by a change in the driver. Can you bisect which change to the driver broke it? > Jan 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 2.6.20.3] Flush writes to MSI-X table
Greg KH wrote: >Well, I'm sure you can agree that it is _very_ late in the 2.6.21 >release cycle to expect to get this in for that kernel. How about >waiting for 2.6.22 and if it's a big deal, getting it into the >2.6.21-stable tree if needed. > >So far I have not seen any bug reports that this patch would fix, have >you? Well, I've seen several bug reports on this issue -- but they're all internal to Intel. However, we do have here a real bug, which shows up on real hardware, which will be released soon. Obviously, I can't discuss release schedules, but "soon" is a good word to use. You might find out more if you read The Register (wink, wink). Given the time frame for release of 2.6.21, I'd be fine with skipping 2.6.20.x, and putting this in 2.6.21. But we really don't want to wait for 2.6.22. I'll take Auke's suggestion and repost this Monday and cc linux-pci and a slew of other people. -Mitch - 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/5] 2.6.21-rc4: known regressions (v2)
Thomas Gleixner wrote:
> On Fri, 2007-03-23 at 19:48 +0100, Adrian Bunk wrote:
>> Subject: x86_64: ACPI regression with noapic (APICTIMER_STOPS_ON_C3?)
>> References : http://lkml.org/lkml/2007/3/8/468
>> http://lkml.org/lkml/2007/3/22/156
>> Submitter : Ray Lee <[EMAIL PROTECTED]>
>> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
>> Status : problem is being debugged
>
> Ray,
>
> can you please test the patch below ?
>
> Thanks,
>
> tglx
(I wondered about the IPI on a UP system, seemed a bit weird :-).)
Works great, booting both with NOAPIC and without. *Much* thanks for
debugging this while you're also handling a bunch of other issues at
the same time.
Patch reproduced below, with an acked-by (and, uhm, a couple of spelling
fixes in the description -- don't hate me, 'kay?). Please apply before
2.6.21 final.
-->
Subject: [PATCH] x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to itself
Ray Lee reported, that on an UP kernel with "noapic" command line option
set, the box locks hard during boot.
Adding some debug printks revealed, that the last action on the box
before stalling was "Send IPI" - a debug printk which was put into
smp_send_timer_broadcast_ipi().
It seems that send_IPI_mask(mask, LOCAL_TIMER_VECTOR) fails when
"noapic" is set on the command line on an UP kernel.
Aside of that it does not make much sense to trigger an interrupt
instead of calling the function directly on the CPU which gets the
PIT/HPET interrupt in case of broadcasting.
Reported-by: Ray Lee <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Acked-by: Ray Lee <[EMAIL PROTECTED]>
diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
index 723417d..83328e1 100644
--- a/arch/x86_64/kernel/apic.c
+++ b/arch/x86_64/kernel/apic.c
@@ -930,9 +930,17 @@ EXPORT_SYMBOL(switch_APIC_timer_to_ipi);
void smp_send_timer_broadcast_ipi(void)
{
+ int cpu = smp_processor_id();
cpumask_t mask;
cpus_and(mask, cpu_online_map, timer_interrupt_broadcast_ipi_mask);
+
+ if (cpu_isset(cpu, mask)) {
+ cpu_clear(cpu, mask);
+ add_pda(apic_timer_irqs, 1);
+ smp_local_timer_interrupt();
+ }
+
if (!cpus_empty(mask)) {
send_IPI_mask(mask, LOCAL_TIMER_VECTOR);
}
-
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.21-rc regression in mptbase
On Mar 23 2007 19:06, Chuck Ebbert wrote: >Jan Engelhardt wrote: >> Hello world, >> >> >> in at least 2.6.21-rc4, one or more of the mptscsi scsi modules is >> broken with respect to not detecting any harddisk (VMware provides that >> virtual LSI MPT controller), which means no working system. >> No problems in 2.6.20.2. >> >> I will be trying 2.6.21-rc1 shortly. Note: The harddisk is detected [or not] when mptspi.ko is loaded, but the message that something has been detected is printed by mptbase, so I do not exactly know which one is at fault. >Also try 2.6.20.4. There are reports of this problem there as well. Ok, will do that. 2.6.21-rc1 = broken 2.6.20.4 = works Jan -- - 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 1/2] hugetlb: add resv argument to hugetlb_file_setup
On Mar 23 2007 15:53, Ken Chen wrote:
>
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 8c718a3..981886f 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -734,7 +734,7 @@ static int can_do_hugetlb_shm(void)
> can_do_mlock());
> }
>
> -struct file *hugetlb_zero_setup(size_t size)
> +struct file *hugetlb_file_setup(size_t size, int resv)
> {
> int error = -ENOMEM;
> struct file *file;
> @@ -771,7 +771,7 @@ struct file *hugetlb_zero_setup(size_t s
> goto out_file;
>
> error = -ENOMEM;
> - if (hugetlb_reserve_pages(inode, 0, size >> HPAGE_SHIFT))
> + if (resv && hugetlb_reserve_pages(inode, 0, size >> HPAGE_SHIFT))
> goto out_inode;
>
> d_instantiate(dentry, inode);
Could not this be made a bool, then?
Jan
--
-
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 3/3] Use correct IDE error recovery
Hi,
On Thursday 08 March 2007, Suleiman Souhlal wrote:
>
> On Mar 7, 2007, at 1:16 PM, Bartlomiej Zolnierkiewicz wrote:
> > Please respin the patch so I could merge it.
>
> Ok.
Since I think that it's worth to have it in 2.6.21-final and respin didn't
happen I did the required changes myself (it also turned out that I missed
few things during initial review), then applied the patch...
Please let my know whether you are fine with my changes, thanks.
[PATCH] ide: use correct IDE error recovery
From: Suleiman Souhlal <[EMAIL PROTECTED]>
IDE error recovery is using IDLE IMMEDIATE if the drive is busy or has DRQ set.
This violates the ATA spec (can only send IDLEÂ IMMEDIATE when drive is not
busy) and really hoses up some drives (modern drives will not be able to
recover using this error handling). The correct thing to do is issue a SRST
followed by a SET FEATURES command. This is what Western Digital recommends
for error recovery and what Western Digital says Windows does.  It also does
not violate the ATA spec as far as I can tell.
Bart:
* port the patch over the current tree
* undo the recalibration code removal
* send SET FEATURES command after checking for good drive status
* don't check whether the current request is of REQ_TYPE_ATA_{CMD,TASK}
type because we need to send SET FEATURES before handling any requests
* some pre-ATA4 drives require INITIALIZE DEVICE PARAMETERS command before
other commands (except IDENTIFY) so send SET FEATURES only if there are
no pending drive->special requests
* update comments and patch description
* any bugs introduced by this patch are mine and not Suleiman's :-)
Signed-off-by: Suleiman Souhlal <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-io.c | 32 +---
drivers/ide/ide-iops.c |3 +++
include/linux/ide.h|1 +
3 files changed, 25 insertions(+), 11 deletions(-)
Index: b/drivers/ide/ide-io.c
===
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -519,21 +519,24 @@ static ide_startstop_t ide_ata_error(ide
if ((stat & DRQ_STAT) && rq_data_dir(rq) == READ &&
hwif->err_stops_fifo == 0)
try_to_flush_leftover_data(drive);
+ if (rq->errors >= ERROR_MAX || blk_noretry_request(rq)) {
+ ide_kill_rq(drive, rq);
+ return ide_stopped;
+ }
+
if (hwif->INB(IDE_STATUS_REG) & (BUSY_STAT|DRQ_STAT))
- /* force an abort */
- hwif->OUTB(WIN_IDLEIMMEDIATE, IDE_COMMAND_REG);
+ rq->errors |= ERROR_RESET;
- if (rq->errors >= ERROR_MAX || blk_noretry_request(rq))
- ide_kill_rq(drive, rq);
- else {
- if ((rq->errors & ERROR_RESET) == ERROR_RESET) {
- ++rq->errors;
- return ide_do_reset(drive);
- }
- if ((rq->errors & ERROR_RECAL) == ERROR_RECAL)
- drive->special.b.recalibrate = 1;
+ if ((rq->errors & ERROR_RESET) == ERROR_RESET) {
++rq->errors;
+ return ide_do_reset(drive);
}
+
+ if ((rq->errors & ERROR_RECAL) == ERROR_RECAL)
+ drive->special.b.recalibrate = 1;
+
+ ++rq->errors;
+
return ide_stopped;
}
@@ -1025,6 +1028,13 @@ static ide_startstop_t start_request (id
if (!drive->special.all) {
ide_driver_t *drv;
+ /*
+* We reset the drive so we need to issue a SETFEATURES.
+* Do it _after_ do_special() restored device parameters.
+*/
+ if (drive->current_speed == 0xff)
+ ide_config_drive_speed(drive, drive->desired_speed);
+
if (rq->cmd_type == REQ_TYPE_ATA_CMD ||
rq->cmd_type == REQ_TYPE_ATA_TASK ||
rq->cmd_type == REQ_TYPE_ATA_TASKFILE)
Index: b/drivers/ide/ide-iops.c
===
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -1094,6 +1094,9 @@ static void pre_reset(ide_drive_t *drive
if (HWIF(drive)->pre_reset != NULL)
HWIF(drive)->pre_reset(drive);
+ if (drive->current_speed != 0xff)
+ drive->desired_speed = drive->current_speed;
+ drive->current_speed = 0xff;
}
/*
Index: b/include/linux/ide.h
===
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -615,6 +615,7 @@ typedef struct ide_drive_s {
u8 init_speed; /* transfer rate set at boot */
u8 pio_speed; /* unused by core, used by some drivers for
fallback from DMA */
u8 current_speed; /* current transfer rate set */
+ u8 desired_speed; /* desired transfer rate set */
Re: [PATCH]: Fix bogus softlockup warning with sysrq-t
We've seen these here and had arrived at a similar patch. Extensive prints on the console can take longer than the watchdog likes. Acked-by: Rick Lindsley <[EMAIL PROTECTED]> Rick - 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 UPDATED][2] cosmetic adaption of drivers/ide/Kconfig concerning SATA
On Sunday 18 March 2007, Patrick Ringl wrote: > Bartlomiej Zolnierkiewicz wrote: > > Hello, > > On Sunday 18 March 2007, Patrick Ringl wrote: > >> Hello, > > > > Hi, > > > >> since especially Serial ATA has it's own menu point now, I guess we can > >> change the description of the deprecated SATA driver as well, since the > >> new libATA subsystem is not configured through a SCSI low-level driver > >> anymore, but has it's own menu point. > >> > >> The following patch is against 2.6.21-rc4: > >> > >> --- linux-2.6.20.old/drivers/ide/Kconfig 2007-03-18 00:05:11.0 > >> +0100 > >> +++ linux-2.6.20/drivers/ide/Kconfig 2007-03-18 00:09:47.0 > >> +0100 > >> @@ -103,7 +103,7 @@ > >>---help--- > >> There are two drivers for Serial ATA controllers. > >> > >> -The main driver, "libata", exists inside the SCSI subsystem > >> +The main driver, "libata", exists inside the ATA subsystem > > > > Strictly speaking libata is not a separate subsystem (it still uses SCSI > > subsystem) and "ATA subsystem" may be misleading, since we now have: > > > > * "ATA/ATAPI/MFM/RLL support" menu for drivers/ide > > > > * "Serial ATA (prod) and Parallel ATA (experimental) drivers" menu for > > libata > > > > What about replacing "exists inside" into "uses" and adding info about > > the new menu instead? > Well, that's even a better idea :-) I wasn't that sure about what to do > .. it's just that it could be misleading since the new (s/p)ata drivers > are not living in the scsi low-level subsystem anymore, but got their > own menu point. > > Here's a different patch >:) applied [ The patch was whitespace damaged and didn't apply et all so I had to manually change the Kconfig to merge your change. ] Thanks, Bart - 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] max_loop limit
Hi,
here's one. Allocates all the fluff dynamically. It does not create any
dev nodes by itself, so you need to do it (Ã la mdadm), but you'll get all
1048576 available minors.
Sadly, it locks up the foreground process (losetup that would be), and I
have not yet figured out why. And the mpt regression elsewhere is
hindering me in finding out faster.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc4/drivers/block/loop.c
===
--- linux-2.6.21-rc4.orig/drivers/block/loop.c
+++ linux-2.6.21-rc4/drivers/block/loop.c
@@ -77,9 +77,8 @@
#include
-static int max_loop = 8;
-static struct loop_device *loop_dev;
-static struct gendisk **disks;
+static LIST_HEAD(loop_devices);
+static DEFINE_SPINLOCK(loop_devices_lock);
/*
* Transfer functions
@@ -183,7 +182,7 @@ figure_loop_size(struct loop_device *lo)
if (unlikely((loff_t)x != size))
return -EFBIG;
- set_capacity(disks[lo->lo_number], x);
+ set_capacity(lo->lo_disk, x);
return 0;
}
@@ -812,7 +811,7 @@ static int loop_set_fd(struct loop_devic
lo->lo_queue->queuedata = lo;
lo->lo_queue->unplug_fn = loop_unplug;
- set_capacity(disks[lo->lo_number], size);
+ set_capacity(lo->lo_disk, size);
bd_set_size(bdev, size << 9);
set_blocksize(bdev, lo_blocksize);
@@ -832,7 +831,7 @@ out_clr:
lo->lo_device = NULL;
lo->lo_backing_file = NULL;
lo->lo_flags = 0;
- set_capacity(disks[lo->lo_number], 0);
+ set_capacity(lo->lo_disk, 0);
invalidate_bdev(bdev, 0);
bd_set_size(bdev, 0);
mapping_set_gfp_mask(mapping, lo->old_gfp_mask);
@@ -918,7 +917,7 @@ static int loop_clr_fd(struct loop_devic
memset(lo->lo_crypt_name, 0, LO_NAME_SIZE);
memset(lo->lo_file_name, 0, LO_NAME_SIZE);
invalidate_bdev(bdev, 0);
- set_capacity(disks[lo->lo_number], 0);
+ set_capacity(lo->lo_disk, 0);
bd_set_size(bdev, 0);
mapping_set_gfp_mask(filp->f_mapping, gfp);
lo->lo_state = Lo_unbound;
@@ -1357,8 +1356,6 @@ static struct block_device_operations lo
/*
* And now the modules code and kernel interface.
*/
-module_param(max_loop, int, 0);
-MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
MODULE_LICENSE("GPL");
MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);
@@ -1383,7 +1380,7 @@ int loop_unregister_transfer(int number)
xfer_funcs[n] = NULL;
- for (lo = _dev[0]; lo < _dev[max_loop]; lo++) {
+ list_for_each_entry(lo, _devices, lo_list) {
mutex_lock(>lo_ctl_mutex);
if (lo->lo_encryption == xfer)
@@ -1398,102 +1395,102 @@ int loop_unregister_transfer(int number)
EXPORT_SYMBOL(loop_register_transfer);
EXPORT_SYMBOL(loop_unregister_transfer);
-static int __init loop_init(void)
+static struct loop_device *loop_find_dev(unsigned int number)
+{
+ struct loop_device *lo;
+ list_for_each_entry(lo, _devices, lo_list)
+ if (lo->lo_number == number)
+ return lo;
+ return NULL;
+}
+
+static struct loop_device *loop_init_one(unsigned int number)
{
- int i;
+ struct loop_device *lo;
+ struct gendisk *disk;
+
+ lo = kzalloc(sizeof(struct loop_device), GFP_KERNEL);
+ if (lo == NULL)
+ goto out;
+
+ lo->lo_queue = blk_alloc_queue(GFP_KERNEL);
+ if (lo->lo_queue == NULL)
+ goto out_free_dev;
+
+ disk = lo->lo_disk = alloc_disk(1);
+ if (disk == NULL)
+ goto out_free_queue;
+
+ mutex_init(>lo_ctl_mutex);
+ lo->lo_number = number;
+ lo->lo_thread = NULL;
+ init_waitqueue_head(>lo_event);
+ spin_lock_init(>lo_lock);
+ disk->major= LOOP_MAJOR;
+ disk->first_minor = number;
+ disk->fops = _fops;
+ disk->private_data = lo;
+ disk->queue= lo->lo_queue;
+ sprintf(disk->disk_name, "loop%u", number);
+ add_disk(lo->lo_disk);
+
+ spin_lock(_devices_lock);
+ list_add_tail(>lo_list, _devices);
+ spin_unlock(_devices_lock);
+ return lo;
+
+ out_free_queue:
+ blk_cleanup_queue(lo->lo_queue);
+ out_free_dev:
+ kfree(lo);
+ out:
+ return ERR_PTR(-ENOMEM);
+}
+
+static void loop_del_one(struct loop_device *lo)
+{
+ del_gendisk(lo->lo_disk);
+ blk_cleanup_queue(lo->lo_queue);
+ put_disk(lo->lo_disk);
+ list_del(>lo_list);
+ kfree(lo);
+ return;
+}
+
+static struct kobject *loop_probe(dev_t dev, int *part, void *data)
+{
+ unsigned int number = dev & MINORMASK;
+ struct loop_device *lo;
- if (max_loop < 1 || max_loop > 256) {
- printk(KERN_WARNING "loop: invalid max_loop (must be between"
- " 1 and 256), using
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 23:43 +0100, Thomas Gleixner wrote:
> On Fri, 2007-03-23 at 18:23 -0400, Chuck Ebbert wrote:
> > Thomas Gleixner wrote:
> > > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> > >> Subject: gettimeofday increments too slowly
> > >> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
> > >> Submitter : David L <[EMAIL PROTECTED]>
> > >> Caused-By : Thomas Gleixner <[EMAIL PROTECTED]>
> > >> commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
> > >> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
> > >> Status : problem is being debugged
> > >
> > > Patch available: http://lkml.org/lkml/2007/3/22/301
> > >
> > > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4
> > >
> >
> > For the other issue raised there, clock running too slow, I now
> > realize there is a similar report:
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626
>
> That's a different one, AFAICT. Davids problem is probably caused by me
> breaking the TSC watchdog.
>
> /me orders paperbags prophylactically and goes back to look at the code
David,
can you please test the patch below ?
tglx
->
Subject: [PATCH] clocksource: Fix thinko in watchdog selection
The watchdog implementation excludes low res / non continuous
clocksources from being selected as a watchdog reference
unintentionally.
Allow using jiffies/PIT as a watchdog reference as long as no better
clocksource is available. This is necessary to detect TSC breakage on
systems, which have no pmtimer/hpet.
The main goal of the initial patch (preventing to switch to highres/nohz
when no reliable fallback clocksource is available) is still guaranteed
by the checks in clocksource_watchdog().
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 5b0e46b..fe5c7db 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -151,7 +151,8 @@ static void clocksource_check_watchdog(struct clocksource
*cs)
watchdog_timer.expires = jiffies + WATCHDOG_INTERVAL;
add_timer(_timer);
}
- } else if (cs->flags & CLOCK_SOURCE_IS_CONTINUOUS) {
+ } else {
+ if (cs->flags & CLOCK_SOURCE_IS_CONTINUOUS)
cs->flags |= CLOCK_SOURCE_VALID_FOR_HRES;
if (!watchdog || cs->rating > watchdog->rating) {
-
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/
debug rsdl 0.33
On Saturday 24 March 2007 08:45, Con Kolivas wrote:
> On Friday 23 March 2007 23:28, Andy Whitcroft wrote:
> > Andy Whitcroft wrote:
> > > Con Kolivas wrote:
> > >> On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
> > >>> Ok, I have yet a third x86_64 machine is is blowing up with the
> > >>> latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
> > >>> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix
> > >>> levels so I have just fired off a set of tests across the affected
> > >>> machines on that latest hotfix stack plus the RSDL backout and the
> > >>> results should be in in the next hour or two.
> > >>>
> > >>> I think there is a strong correlation between RSDL and these hangs.
> > >>> Any suggestions as to the next step.
> > >>
> > >> Found a nasty in requeue_task
> > >> +if (list_empty(old_array->queue + old_prio))
> > >> +__clear_bit(old_prio, p->array->prio_bitmap);
> > >>
> > >> see anything wrong there? I do :P
> > >>
> > >> I'll queue that up with the other changes pending and hopefully that
> > >> will fix your bug.
> > >
> > > Tests queued with your rdsl-0.33 patch (I am assuming its in there).
> > > Will let you know how it looks.
> >
> > Hmmm, this is good for the original machine (as was 0.32) but not for
> > either of the other two. I am seeing panics as below on those two.
>
> This machine seems most sensitive to it (first column):
> elm3b6
> amd64
> newisys
> 4cpu
> config: amd64
>
> Can you throw this debugging patch at it please? The console output might
> be very helpful. On top of sched-rsdl-0.33 thanks!
Better yet this one which checks the expired array as well and after
pull_task.
If anyone's getting a bug they think might be due to rsdl please try this (on
rsdl 0.33).
---
kernel/sched.c | 51 +++
1 file changed, 51 insertions(+)
Index: linux-2.6.21-rc4-mm1/kernel/sched.c
===
--- linux-2.6.21-rc4-mm1.orig/kernel/sched.c2007-03-24 08:32:19.0
+1100
+++ linux-2.6.21-rc4-mm1/kernel/sched.c 2007-03-24 10:22:59.0 +1100
@@ -659,6 +659,35 @@ static inline void set_task_entitlement(
p->time_slice = p->quota;
}
+static int debug_rqbitmap(struct rq *rq)
+{
+ struct list_head *queue;
+ int idx = 0, error = 0;
+ struct prio_array *array;
+
+ for (idx = 0; idx < MAX_PRIO; idx++) {
+ array = rq->active;
+ queue = array->queue + idx;
+ if (!list_empty(queue)) {
+ if (!test_bit(idx, rq->dyn_bitmap)) {
+ __set_bit(idx, rq->dyn_bitmap);
+ error = 1;
+ printk(KERN_ERR "MISSING DYNAMIC BIT %d\n",
idx);
+ }
+ }
+ array = rq->expired;
+ queue = array->queue + idx;
+ if (!list_empty(queue)) {
+ if (!test_bit(idx, rq->exp_bitmap)) {
+ __set_bit(idx, rq->exp_bitmap);
+ error = 1;
+ printk(KERN_ERR "MISSING EXPIRED BIT %d\n",
idx);
+ }
+ }
+ }
+ return error;
+}
+
/*
* There is no specific hard accounting. The dynamic bits can have
* false positives. rt_tasks can only be on the active queue.
@@ -679,6 +708,7 @@ static void dequeue_task(struct task_str
list_del_init(>run_list);
if (list_empty(p->array->queue + p->prio))
__clear_bit(p->prio, p->array->prio_bitmap);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -797,12 +827,14 @@ static void enqueue_task(struct task_str
{
__enqueue_task(p, rq);
list_add_tail(>run_list, p->array->queue + p->prio);
+ WARN_ON(debug_rqbitmap(rq));
}
static inline void enqueue_task_head(struct task_struct *p, struct rq *rq)
{
__enqueue_task(p, rq);
list_add(>run_list, p->array->queue + p->prio);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -820,6 +852,7 @@ static void requeue_task(struct task_str
__clear_bit(old_prio, old_array->prio_bitmap);
set_dynamic_bit(p, rq);
}
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -906,6 +939,7 @@ static inline void __activate_task(struc
{
enqueue_task(p, rq);
inc_nr_running(p, rq);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -1006,6 +1040,7 @@ static void deactivate_task(struct task_
{
dec_nr_running(p, rq);
dequeue_task(p, rq);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -1718,9 +1753,11 @@ void fastcall wake_up_new_task(struct ta
* Parent and child are on different CPUs, now get the
* parent runqueue to update the parent's ->flags:
*/
+ WARN_ON(debug_rqbitmap(rq));
Re: [patch 0/7] Add IRQF_IRQPOLL_IRQ flag to allow irqpoll
On Fri, 23 Mar 2007, Bernhard Walle wrote: > * Guennadi Liakhovetski <[EMAIL PROTECTED]> [2007-03-23 23:15]: > > On Fri, 23 Mar 2007, Bernhard Walle wrote: > > > > > irqpoll is broken on some architectures that don't use the IRQ 0 for the > > > timer > > > interrupt like IA64. This patch adds a IRQF_IRQPOLL_IRQ flag. > > > > emn, please, cannot we come up with a better name - one that doesn't have > > "IRQ" 3 (!) times in it?... > > Well, it was suggested by Andrew. What's your suggestion? Purely esthetically (ehm, am I saying that?...) your original suggestion to use IRQF_IRQPOLL looks better to me. Or even IRQF_POLL, but, maybe, it's a bit too much of a simplification. Thanks Guennadi --- Guennadi Liakhovetski - 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] [bugfix] loop.c
On Fri, 23 Mar 2007, Michael Tokarev wrote: > Speaking of which, I wonder... Here, and in many other places. > If some variable is marked as MODULE_PARAM (or whatever it is called > nowadays), used in module init routine, AND subsequently used for > various bound checks and loops... [...] > and so on. Together with: > # modprobe foo n=10 > # echo 20 > /sys/module/foo/parameters/n > After that, we have 10 entries in mem[], and n is equal to 20, so the > for-loop above will be up to i=19. Which will reference unallocated > memory Amd I dreaming? This can be solved either by using module_param_call() in every module, and properly handling the "asynchronous" changes of module parameter, or by just disallowing the parameter from being tuned through sysfs completely (by setting the 'permissions' parameter of module_param() to zero ... which is what many drivers do anyway, I'd guess). -- Jiri Kosina - 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] - Schedule mcdx for removal ? was: warning: #warning You have not edited mcdx.h
On Fri, Mar 23, 2007 at 11:59:40PM +0100, roland wrote: > why not? > > why should unused code be maintained to death ? This driver hasn't been actively maintained for years - it's nearly zero-cost to carry such a driver in the kernel sources. > if there are discussions about removing features people are still using, i > think it should be legitimate to discuss about removing drivers nobody > needs anymore There's a difference between obsolete features and drivers for old hardware: There's usually a replacement for the obsolete features. 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: PCI probing failure in 2.6.21-rc3
On Thu, Mar 15, 2007 at 11:06:47AM -0800, Andrew Morton wrote: > > On Wed, 14 Mar 2007 09:47:42 +0100 "Francis Moreau" <[EMAIL PROTECTED]> > > wrote: > > I already posted this issue but it was on a 2.6.19.7 kernel > > (2.6.19-1.2911.6.5.fc6 to be accurate). So it doesn't seem to be a > > regression. > > > > During boot the console shows up this: > > > > [...] > > PCI: Probing PCI hardware (bus 00) > > PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO > > PCI quirk: region 1180-11bf claimed by ICH6 GPIO > > :00:1f.2: trying to change BAR0 from to 01F0 > > :00:1f.2: trying to change BAR1 from to 03F4 > > :00:1f.2: trying to change BAR2 from to 0170 > > :00:1f.2: trying to change BAR3 from to 0374 > > Boot video device is :01:00.0 > > PCI: Transparent bridge - :00:1e.0 > > PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06 (-#07) > > (try 'pci=assign-busses') > > Please report the result to linux-kernel to fix this permanently > > [...] > > > > I haven't time to test 'pci=assign-busses' option, I'll do it later, > > but I wanted to report this ASAP. > > Greg, could we please either > > a) start doing something about these reports or > b) publish sufficient info to permit others to do something about these >reports or > c) remove the printk? Ugh, I'm getting really tired of it too. Bernhard, any plans on addressing these constant reports? You sent me this patch and then seem to have disappered when dealing with the fallout of the different messages :( Should I just revert your original patch all-together? thanks, greg k-h - 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.21-rc regression in mptbase
Jan Engelhardt wrote: > Hello world, > > > in at least 2.6.21-rc4, one or more of the mptscsi scsi modules is > broken with respect to not detecting any harddisk (VMware provides that > virtual LSI MPT controller), which means no working system. > No problems in 2.6.20.2. > > I will be trying 2.6.21-rc1 shortly. > Also try 2.6.20.4. There are reports of this problem there as well. - 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: [4/5] 2.6.21-rc4: known regressions (v2)
Adrian Bunk wrote: >>> >> For the other issue raised there, clock running too slow, I now >> realize there is a similar report: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 > > It shouldn't be the same issue: > 2.6.20-1.2925.fc6 is based in 2.6.20.3-rc1 while this issue is a > 2.6.21-rc regression. > Or do the -rc kernels include parts of the -rt patchsets? > Sometimes problems leak from the next kernel version into -stable via the stable kernel patches. Other times the bug may have been there all along but nobody had found it yet... - 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: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, Mar 23, 2007 at 06:23:17PM -0400, Chuck Ebbert wrote: > Thomas Gleixner wrote: > > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > >> Subject: gettimeofday increments too slowly > >> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 > >> Submitter : David L <[EMAIL PROTECTED]> > >> Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> > >> commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 > >> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > >> Status : problem is being debugged > > > > Patch available: http://lkml.org/lkml/2007/3/22/301 > > > > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 > > > > For the other issue raised there, clock running too slow, I now > realize there is a similar report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 It shouldn't be the same issue: 2.6.20-1.2925.fc6 is based in 2.6.20.3-rc1 while this issue is a 2.6.21-rc regression. Or do the -rc kernels include parts of the -rt patchsets? 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] - Schedule mcdx for removal ? was: warning: #warning You have not edited mcdx.h
why not? why should unused code be maintained to death ? if there are discussions about removing features people are still using, i think it should be legitimate to discuss about removing drivers nobody needs anymore - Original Message - From: "Oliver Neukum" <[EMAIL PROTECTED]> To: "roland" <[EMAIL PROTECTED]> Cc: ; <[EMAIL PROTECTED]> Sent: Thursday, March 22, 2007 10:35 AM Subject: Re: [RFC] - Schedule mcdx for removal ? was: warning: #warning You have not edited mcdx.h Am Donnerstag, 22. März 2007 10:14 schrieb roland: i wonder if there still exist any of those devices in functional state in this world, at least not attached to some system being able to boot 2.6.21+ - so, maybe mcdx driver is something for Documentation/feature-removal-schedule.txt , being removed in 2.6.25 or so after being announced for some time (i.e. driver telling "i will be gone soon, go spend those $15 to get a new drive") ? Why? For the sake of sheer removal? Regards Oliver -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) This signature is a legal requirement - 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 1/2] hugetlb: add resv argument to hugetlb_file_setup
On 3/23/07, Nish Aravamudan <[EMAIL PROTECTED]> wrote:
Comment needs updating too.
Thanks. How could I miss that :-(
updated patch:
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8c718a3..981886f 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -734,7 +734,7 @@ static int can_do_hugetlb_shm(void)
can_do_mlock());
}
-struct file *hugetlb_zero_setup(size_t size)
+struct file *hugetlb_file_setup(size_t size, int resv)
{
int error = -ENOMEM;
struct file *file;
@@ -771,7 +771,7 @@ struct file *hugetlb_zero_setup(size_t s
goto out_file;
error = -ENOMEM;
- if (hugetlb_reserve_pages(inode, 0, size >> HPAGE_SHIFT))
+ if (resv && hugetlb_reserve_pages(inode, 0, size >> HPAGE_SHIFT))
goto out_inode;
d_instantiate(dentry, inode);
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 3f3e7a6..55cccd8 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -163,7 +163,7 @@ static inline struct hugetlbfs_sb_info *
extern const struct file_operations hugetlbfs_file_operations;
extern struct vm_operations_struct hugetlb_vm_ops;
-struct file *hugetlb_zero_setup(size_t);
+struct file *hugetlb_file_setup(size_t, int);
int hugetlb_get_quota(struct address_space *mapping);
void hugetlb_put_quota(struct address_space *mapping);
@@ -185,7 +185,7 @@ #else /* !CONFIG_HUGETLBFS */
#define is_file_hugepages(file) 0
#define set_file_hugepages(file)BUG()
-#define hugetlb_zero_setup(size) ERR_PTR(-ENOSYS)
+#define hugetlb_file_setup(size, resv) ERR_PTR(-ENOSYS)
#endif /* !CONFIG_HUGETLBFS */
diff --git a/ipc/shm.c b/ipc/shm.c
index 4fefbad..81c8344 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -365,8 +365,8 @@ static int newseg (struct ipc_namespace
}
if (shmflg & SHM_HUGETLB) {
- /* hugetlb_zero_setup takes care of mlock user accounting */
- file = hugetlb_zero_setup(size);
+ /* hugetlb_file_setup takes care of mlock user accounting */
+ file = hugetlb_file_setup(size, 1);
shp->mlock_user = current->user;
} else {
int acctflag = VM_ACCOUNT;
-
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 1/2] hugetlb: add resv argument to hugetlb_file_setup
On 3/23/07, Ken Chen <[EMAIL PROTECTED]> wrote:
rename hugetlb_zero_setup() to hugetlb_file_setup() to better match
function name convention like shmem implementation. Also add an
argument to the function to indicate whether file setup should reserve
hugetlb page upfront or not.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8c718a3..981886f 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -734,7 +734,7 @@ static int can_do_hugetlb_shm(void)
can_do_mlock());
}
-struct file *hugetlb_zero_setup(size_t size)
+struct file *hugetlb_file_setup(size_t size, int resv)
{
int error = -ENOMEM;
struct file *file;
@@ -771,7 +771,7 @@ struct file *hugetlb_zero_setup(size_t s
goto out_file;
error = -ENOMEM;
- if (hugetlb_reserve_pages(inode, 0, size >> HPAGE_SHIFT))
+ if (resv && hugetlb_reserve_pages(inode, 0, size >> HPAGE_SHIFT))
goto out_inode;
d_instantiate(dentry, inode);
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 3f3e7a6..55cccd8 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -163,7 +163,7 @@ static inline struct hugetlbfs_sb_info *
extern const struct file_operations hugetlbfs_file_operations;
extern struct vm_operations_struct hugetlb_vm_ops;
-struct file *hugetlb_zero_setup(size_t);
+struct file *hugetlb_file_setup(size_t, int);
int hugetlb_get_quota(struct address_space *mapping);
void hugetlb_put_quota(struct address_space *mapping);
@@ -185,7 +185,7 @@ #else /* !CONFIG_HUGETLBFS */
#define is_file_hugepages(file)0
#define set_file_hugepages(file) BUG()
-#define hugetlb_zero_setup(size) ERR_PTR(-ENOSYS)
+#define hugetlb_file_setup(size, resv) ERR_PTR(-ENOSYS)
#endif /* !CONFIG_HUGETLBFS */
diff --git a/ipc/shm.c b/ipc/shm.c
index 4fefbad..c64643f 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -366,7 +366,7 @@ static int newseg (struct ipc_namespace
if (shmflg & SHM_HUGETLB) {
/* hugetlb_zero_setup takes care of mlock user accounting */
- file = hugetlb_zero_setup(size);
+ file = hugetlb_file_setup(size, 1);
Comment needs updating too.
Thanks,
Nish
-
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: HPA patches
Alan Cox wrote: What is 0x40? can it be #defined (or enum-ed) instead of a magic value? please? (more of same below) >>> It's 0x40. Its a "command dependant bit" - no useful name. >> dependent. OK, thanks. > > IDE is a bit like that. I'm amazed some of the command flags arent in > latin. > Hmm, what's latin for "no useful name?" You could call it that. - 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/2] hugetlb: add /dev/hugetlb char device
add a char device /dev/hugetlb that behaves similar to /dev/zero,
built on top of internal hugetlbfs mount.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff -u b/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
--- b/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -795,6 +795,23 @@
return ERR_PTR(error);
}
+int hugetlb_zero_setup(struct file *file, struct vm_area_struct *vma)
+{
+ file = hugetlb_file_setup(vma->vm_end - vma->vm_start, 0);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ if (vma->vm_file)
+ fput(vma->vm_file);
+ vma->vm_file = file;
+ return hugetlbfs_file_mmap(file, vma);
+}
+
+const struct file_operations hugetlb_dev_fops = {
+ .mmap = hugetlb_zero_setup,
+ .get_unmapped_area = hugetlb_get_unmapped_area,
+};
+
static int __init init_hugetlbfs_fs(void)
{
int error;
diff -u b/include/linux/hugetlb.h b/include/linux/hugetlb.h
--- b/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -162,6 +162,7 @@
}
extern const struct file_operations hugetlbfs_file_operations;
+extern const struct file_operations hugetlb_dev_fops;
extern struct vm_operations_struct hugetlb_vm_ops;
struct file *hugetlb_file_setup(size_t, int);
int hugetlb_get_quota(struct address_space *mapping);
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -27,6 +27,7 @@ #include
#include
#include
#include
+#include
#include
#include
@@ -939,6 +940,12 @@ #ifdef CONFIG_CRASH_DUMP
filp->f_op = _fops;
break;
#endif
+#ifdef CONFIG_HUGETLBFS
+ case 13:
+ printk("open hugetlb dev device\n");
+ filp->f_op = _dev_fops;
+ break;
+#endif
default:
return -ENXIO;
}
@@ -971,6 +978,9 @@ #endif
#ifdef CONFIG_CRASH_DUMP
{12,"oldmem",S_IRUSR | S_IWUSR | S_IRGRP, _fops},
#endif
+#ifdef CONFIG_HUGETLBFS
+ {13, "hugetlb",S_IRUGO | S_IWUGO, _dev_fops},
+#endif
};
static struct class *mem_class;
-
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/2] hugetlb: add resv argument to hugetlb_file_setup
rename hugetlb_zero_setup() to hugetlb_file_setup() to better match
function name convention like shmem implementation. Also add an
argument to the function to indicate whether file setup should reserve
hugetlb page upfront or not.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8c718a3..981886f 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -734,7 +734,7 @@ static int can_do_hugetlb_shm(void)
can_do_mlock());
}
-struct file *hugetlb_zero_setup(size_t size)
+struct file *hugetlb_file_setup(size_t size, int resv)
{
int error = -ENOMEM;
struct file *file;
@@ -771,7 +771,7 @@ struct file *hugetlb_zero_setup(size_t s
goto out_file;
error = -ENOMEM;
- if (hugetlb_reserve_pages(inode, 0, size >> HPAGE_SHIFT))
+ if (resv && hugetlb_reserve_pages(inode, 0, size >> HPAGE_SHIFT))
goto out_inode;
d_instantiate(dentry, inode);
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 3f3e7a6..55cccd8 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -163,7 +163,7 @@ static inline struct hugetlbfs_sb_info *
extern const struct file_operations hugetlbfs_file_operations;
extern struct vm_operations_struct hugetlb_vm_ops;
-struct file *hugetlb_zero_setup(size_t);
+struct file *hugetlb_file_setup(size_t, int);
int hugetlb_get_quota(struct address_space *mapping);
void hugetlb_put_quota(struct address_space *mapping);
@@ -185,7 +185,7 @@ #else /* !CONFIG_HUGETLBFS */
#define is_file_hugepages(file) 0
#define set_file_hugepages(file)BUG()
-#define hugetlb_zero_setup(size) ERR_PTR(-ENOSYS)
+#define hugetlb_file_setup(size, resv) ERR_PTR(-ENOSYS)
#endif /* !CONFIG_HUGETLBFS */
diff --git a/ipc/shm.c b/ipc/shm.c
index 4fefbad..c64643f 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -366,7 +366,7 @@ static int newseg (struct ipc_namespace
if (shmflg & SHM_HUGETLB) {
/* hugetlb_zero_setup takes care of mlock user accounting */
- file = hugetlb_zero_setup(size);
+ file = hugetlb_file_setup(size, 1);
shp->mlock_user = current->user;
} else {
int acctflag = VM_ACCOUNT;
-
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 0/2] introduce /dev/hugetlb char device
Introduce /dev/hugetlb device that behaves similar to /dev/zero for allocating anonymous hugetlb page. It is especially beneficial that application developers can have an easy way to create MAP_PRIVATE hugetlb mappings without all the fuss about the hugetlbfs filesystem. Two follow on patches has more detail description for each changeset. Signed-off-by: Ken Chen <[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/
2.6.21-rc regression in mptbase
Hello world,
in at least 2.6.21-rc4, one or more of the mptscsi scsi modules is
broken with respect to not detecting any harddisk (VMware provides that
virtual LSI MPT controller), which means no working system.
No problems in 2.6.20.2.
I will be trying 2.6.21-rc1 shortly.
2.6.20.2:
<6>PIIX4: IDE controller at PCI slot :00:07.1
<6>PIIX4: chipset revision 1
<6>PIIX4: not 100% native mode: will probe irqs later
<6>ide1: BM-DMA at 0x1058-0x105f, BIOS settings: hdc:DMA, hdd:pio
<7>Probing IDE interface ide1...
<4>hdc: VMware Virtual IDE CDROM Drive, ATAPI CD/DVD-ROM drive
<4>ide1 at 0x170-0x177,0x376 on irq 15
<6>Fusion MPT base driver 3.04.03
<6>Copyright (c) 1999-2007 LSI Logic Corporation
<6>Fusion MPT SPI Host driver 3.04.03
<6>ACPI: PCI Interrupt :00:10.0[A] -> GSI 17 (level, low) -> IRQ 17
<6>mptbase: Initiating ioc0 bringup
<6>ioc0: 53C1030: Capabilities={Initiator}
<6>scsi0 : ioc0: LSI53C1030, FwRev=01032920h, Ports=1, MaxQ=128, IRQ=17
<5>scsi 0:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2
<6> target0:0:0: Beginning Domain Validation
<6> target0:0:0: Domain Validation skipping write tests
<6> target0:0:0: Ending Domain Validation
<6> target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 127)
<5>SCSI device sda: 16777216 512-byte hdwr sectors (8590 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 5d 00 00 00
<5>sda: cache data unavailable
<3>sda: assuming drive cache: write through
<5>SCSI device sda: 16777216 512-byte hdwr sectors (8590 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 5d 00 00 00
<5>sda: cache data unavailable
<3>sda: assuming drive cache: write through
<6> sda: sda1 sda2
<5>sd 0:0:0:0: Attached scsi disk sda
<5>sd 0:0:0:0: Attached scsi generic sg0 type 0
<7>libata version 2.00 loaded.
<6>BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
<6>SGI XFS with ACLs, security attributes, realtime, large block numbers, no
debug enabled
<6>SGI XFS Quota Management subsystem
<5>XFS mounting filesystem sda2
2.6.21:
Loading piix
PIIX4: IDE controller at PCI slot :00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide1: BM-DMA at 0x1058-0x105f, BIOS settings: hdc:DMA, hdd:pio
hdc: VMware Virtual IDE CDROM Drive, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Loading scsi_transport_spi
Loading mptbase
Fusion MPT base driver 3.04.04
Copyright (c) 1999-2007 LSI Logic Corporation
Loading mptscsih
Loading mptspi
Fusion MPT SPI Host driver 3.04.04
ACPI: PCI Interrupt :00:10.0[A] -> GSI 17 (level, low) -> IRQ 17
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator}
scsi0 : ioc0: LSI53C1030, FwRev=01032920h, Ports=1, MaxQ=128, IRQ=17
Loading libata
Loading ata_piix
Loading fan
Loading edd
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Loading xfs
SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug
enabled
SGI XFS Quota Management subsystem
Waiting for device /dev/sda2 to appear: ...
Jan
--
-
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: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 18:23 -0400, Chuck Ebbert wrote: > Thomas Gleixner wrote: > > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > >> Subject: gettimeofday increments too slowly > >> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 > >> Submitter : David L <[EMAIL PROTECTED]> > >> Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> > >> commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 > >> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > >> Status : problem is being debugged > > > > Patch available: http://lkml.org/lkml/2007/3/22/301 > > > > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 > > > > For the other issue raised there, clock running too slow, I now > realize there is a similar report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 That's a different one, AFAICT. Davids problem is probably caused by me breaking the TSC watchdog. /me orders paperbags prophylactically and goes back to look at the code tglx - 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: HELP!!! SD and suspend damage i-node.
On Friday, 23 March 2007 12:25, Sergey Smirnov wrote: > It's happen only with 4G SD. I made the same test in 512Mb SD. > After suspend/resume there is no errors on fs. > > If I resume PDA with 4G SD it go back to suspend after few seconds. Well, I believe the problem is related to the SD driver (maintainer added to the Cc list) or to the zaurus-specific code. Rafael > Rafael J. Wysocki wrote: > > On Thursday, 22 March 2007 13:35, Sergey Smirnov wrote: > >> I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750 > >> (PXA255). > >> After suspend/resume filesystem stay clean. But some i-nodes become broken. > >> Some files looks like block device or pipe with strange permissions, owner > >> etc. > >> I'm sure that there is no bad blocks on SD. > >> I'll send any additional information. Just say me what you need to help me. > >> I had i lot of tries. Apply patches, remove its, change fstype etc. > >> output of fsck -f > > > > I assume this is the suspend to RAM? > > > > 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/ > > -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - 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: [4/5] 2.6.21-rc4: known regressions (v2)
Thomas Gleixner wrote: > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: >> Subject: gettimeofday increments too slowly >> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027 >> Submitter : David L <[EMAIL PROTECTED]> >> Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> >> commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 >> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> >> Status : problem is being debugged > > Patch available: http://lkml.org/lkml/2007/3/22/301 > > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4 > For the other issue raised there, clock running too slow, I now realize there is a similar report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626 - 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/7] Add IRQF_IRQPOLL_IRQ flag to allow irqpoll
* Guennadi Liakhovetski <[EMAIL PROTECTED]> [2007-03-23 23:15]: > On Fri, 23 Mar 2007, Bernhard Walle wrote: > > > irqpoll is broken on some architectures that don't use the IRQ 0 for the > > timer > > interrupt like IA64. This patch adds a IRQF_IRQPOLL_IRQ flag. > > emn, please, cannot we come up with a better name - one that doesn't have > "IRQ" 3 (!) times in it?... Well, it was suggested by Andrew. What's your suggestion? Thanks, Bernhard - 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 2.6.20.3] Flush writes to MSI-X table
On Fri, Mar 23, 2007 at 02:50:45PM -0700, Kok, Auke wrote: > Greg KH wrote: > >On Thu, Mar 22, 2007 at 02:08:19PM -0700, Mitch Williams wrote: > >>Because both MSI-X interrupt messages and MSI-X table writes are posted, > >>it's possible for them to cross while in-flight. This results in > >>interrupts being received long after the kernel thinks they're disabled, > >>and in interrupts being sent to stale vectors after rebalancing. > >> > >>This patch performs a read flush after writes to the MSI-X table for > >>enable/disable and rebalancing operations. Because this is an expensive > >>operation, we do not perform the read flush after mask/unmask > >>operations. Hardware which supports MSI-X typically also supports some > >>sort of interrupt moderation, so a read-flush is not necessary for > >>mask/unmask operations. > >> > >>This patch has been validated with (unreleased) network hardware which > >>uses MSI-X. > > > >Is this needed for any hardware that is public today? > > yes. Every msi-x capable piece of hardware in the field will crash if it > does any form of interrupt balancing. (okay that is not that much stuff out > there... I know, but the patch is not that big at all - all it does is > subtly add a few read flushes to make sure that critical changes in the > msix vector tables are pushed out at the proper time). > > >Also, it seems a bit too big of a patch for -stable right now, > >especially as the mainline patch will not make it into 2.6.22 at the > >earliest. > > I think Mitch was way too sensitive when he worded his e-mail. We should > really be trying to get this fix into 2.6.21 at least. > > Mitch, can you re-post this and include Eric Biederman, linux-pci, our > intel platform guys and perhaps Linus and Andrew? > > A lot of vendors (not just us) will be pushing msi-x capable hardware out, > and this fix is absolutely needed. Getting it in soon is really preferred. > Not to mention that Mitch has spent well over 8 weeks I think making sure > that this is indeed the issue and the proper fix... Well, I'm sure you can agree that it is _very_ late in the 2.6.21 release cycle to expect to get this in for that kernel. How about waiting for 2.6.22 and if it's a big deal, getting it into the 2.6.21-stable tree if needed. So far I have not seen any bug reports that this patch would fix, have you? thanks, greg k-h - 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/7] Add IRQF_IRQPOLL_IRQ flag to allow irqpoll
On Fri, 23 Mar 2007, Bernhard Walle wrote: > irqpoll is broken on some architectures that don't use the IRQ 0 for the timer > interrupt like IA64. This patch adds a IRQF_IRQPOLL_IRQ flag. emn, please, cannot we come up with a better name - one that doesn't have "IRQ" 3 (!) times in it?... Thanks Guennadi --- Guennadi Liakhovetski - 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: introduce /dev/hugetlb
On 3/23/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote: On Fri, 23 Mar 2007, William Lee Irwin III wrote: >> Lack of compiletesting beyond x86-64 in all probability. On Fri, Mar 23, 2007 at 03:15:55PM +, Mel Gorman wrote: > Ok, this will go kablamo on Power then even if it compiles. I don't > consider it a fundamental problem though. For the purposes of an RFC, it's > grand and something that can be worked with. He needs to un-#ifdef the prototype (which he already does), but he needs to leave the definition under #ifdef while removing the static qualifier. A relatively minor fixup. Yes, sorry about that for lack of access to non-x86-64 machines. I needed to move the function prototype to hugetlb.h and evidently removed the #ifdef by mistake. I'm not going to touch this in my next clean up patch, instead I will just declare char specific file_operations struct in hugetlbfs and then have char device reference it. But nevertheless, hugetlb_get_unmapped_area function prototype better be in a header file somewhere. - Ken - 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: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 23 Mar 2007, john stultz wrote: > > The incorrect clocksource selection is resolved w/ this patch: > http://lkml.org/lkml/2007/3/22/287 > > There is still an issue of why the PIT clocksource hangs, but for the > moment the issue its worked-around. Hmm.. I haven't seen it until now. Is it waiting for something? 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] rfc: introduce /dev/hugetlb
On 3/23/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
I like this patch a lot, though I'm not likely to get around to testing
it today. If userspace testcode is available that would be great to see
posted so I can just boot into things and run that.
Here is the test code that I used:
(warning: x86 centric)
#include
#include
#include
#include
#define SIZE(4*1024*1024UL)
int main(void)
{
int fd;
long i;
char *addr;
fd = open("/dev/hugetlb", O_RDWR);
if (fd == -1) {
perror("open failure");
exit(1);
}
addr = mmap(0, SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
if (addr == MAP_FAILED) {
perror("mmap failure");
exit(2);
}
for (i = 0; i < SIZE; i+=4096)
addr[i] = 1;
printf("success!\n");
}
-
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: [git patches] net driver fixes
Jeff, might be worth getting the sk_buff leak fix in ppp from http://www.spinics.net/lists/netdev/msg27706.html in 2.6.21 too? Don't know how important it is for stable. It was present in 2.6.18 too. Thanks Guennadi --- Guennadi Liakhovetski - 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 2.6.20.3] Flush writes to MSI-X table
Greg KH wrote: On Thu, Mar 22, 2007 at 02:08:19PM -0700, Mitch Williams wrote: Because both MSI-X interrupt messages and MSI-X table writes are posted, it's possible for them to cross while in-flight. This results in interrupts being received long after the kernel thinks they're disabled, and in interrupts being sent to stale vectors after rebalancing. This patch performs a read flush after writes to the MSI-X table for enable/disable and rebalancing operations. Because this is an expensive operation, we do not perform the read flush after mask/unmask operations. Hardware which supports MSI-X typically also supports some sort of interrupt moderation, so a read-flush is not necessary for mask/unmask operations. This patch has been validated with (unreleased) network hardware which uses MSI-X. Is this needed for any hardware that is public today? yes. Every msi-x capable piece of hardware in the field will crash if it does any form of interrupt balancing. (okay that is not that much stuff out there... I know, but the patch is not that big at all - all it does is subtly add a few read flushes to make sure that critical changes in the msix vector tables are pushed out at the proper time). Also, it seems a bit too big of a patch for -stable right now, especially as the mainline patch will not make it into 2.6.22 at the earliest. I think Mitch was way too sensitive when he worded his e-mail. We should really be trying to get this fix into 2.6.21 at least. Mitch, can you re-post this and include Eric Biederman, linux-pci, our intel platform guys and perhaps Linus and Andrew? A lot of vendors (not just us) will be pushing msi-x capable hardware out, and this fix is absolutely needed. Getting it in soon is really preferred. Not to mention that Mitch has spent well over 8 weeks I think making sure that this is indeed the issue and the proper fix... Auke - 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.21-rc4-mm1
On Friday 23 March 2007 23:28, Andy Whitcroft wrote:
> Andy Whitcroft wrote:
> > Con Kolivas wrote:
> >> On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
> >>> Ok, I have yet a third x86_64 machine is is blowing up with the latest
> >>> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
> >>> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels
> >>> so I have just fired off a set of tests across the affected machines on
> >>> that latest hotfix stack plus the RSDL backout and the results should
> >>> be in in the next hour or two.
> >>>
> >>> I think there is a strong correlation between RSDL and these hangs.
> >>> Any suggestions as to the next step.
> >>
> >> Found a nasty in requeue_task
> >> + if (list_empty(old_array->queue + old_prio))
> >> + __clear_bit(old_prio, p->array->prio_bitmap);
> >>
> >> see anything wrong there? I do :P
> >>
> >> I'll queue that up with the other changes pending and hopefully that
> >> will fix your bug.
> >
> > Tests queued with your rdsl-0.33 patch (I am assuming its in there).
> > Will let you know how it looks.
>
> Hmmm, this is good for the original machine (as was 0.32) but not for
> either of the other two. I am seeing panics as below on those two.
This machine seems most sensitive to it (first column):
elm3b6
amd64
newisys
4cpu
config: amd64
Can you throw this debugging patch at it please? The console output might be
very helpful. On top of sched-rsdl-0.33 thanks!
---
kernel/sched.c | 39 +++
1 file changed, 39 insertions(+)
Index: linux-2.6.21-rc4-mm1/kernel/sched.c
===
--- linux-2.6.21-rc4-mm1.orig/kernel/sched.c2007-03-24 08:32:19.0
+1100
+++ linux-2.6.21-rc4-mm1/kernel/sched.c 2007-03-24 08:42:04.0 +1100
@@ -659,6 +659,25 @@ static inline void set_task_entitlement(
p->time_slice = p->quota;
}
+static int debug_rqbitmap(struct rq *rq)
+{
+ struct list_head *queue;
+ int idx = 0, error = 0;
+ struct prio_array *array = rq->active;
+
+ for (idx = 0; idx < MAX_PRIO; idx++) {
+ queue = array->queue + idx;
+ if (!list_empty(queue)) {
+ if (!test_bit(idx, rq->dyn_bitmap)) {
+ __set_bit(idx, rq->dyn_bitmap);
+ error = 1;
+ printk(KERN_ERR "MISSING DYNAMIC BIT %d\n",
idx);
+ }
+ }
+ }
+ return error;
+}
+
/*
* There is no specific hard accounting. The dynamic bits can have
* false positives. rt_tasks can only be on the active queue.
@@ -679,6 +698,7 @@ static void dequeue_task(struct task_str
list_del_init(>run_list);
if (list_empty(p->array->queue + p->prio))
__clear_bit(p->prio, p->array->prio_bitmap);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -797,12 +817,14 @@ static void enqueue_task(struct task_str
{
__enqueue_task(p, rq);
list_add_tail(>run_list, p->array->queue + p->prio);
+ WARN_ON(debug_rqbitmap(rq));
}
static inline void enqueue_task_head(struct task_struct *p, struct rq *rq)
{
__enqueue_task(p, rq);
list_add(>run_list, p->array->queue + p->prio);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -820,6 +842,7 @@ static void requeue_task(struct task_str
__clear_bit(old_prio, old_array->prio_bitmap);
set_dynamic_bit(p, rq);
}
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -906,6 +929,7 @@ static inline void __activate_task(struc
{
enqueue_task(p, rq);
inc_nr_running(p, rq);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -1006,6 +1030,7 @@ static void deactivate_task(struct task_
{
dec_nr_running(p, rq);
dequeue_task(p, rq);
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -1718,9 +1743,11 @@ void fastcall wake_up_new_task(struct ta
* Parent and child are on different CPUs, now get the
* parent runqueue to update the parent's ->flags:
*/
+ WARN_ON(debug_rqbitmap(rq));
task_rq_unlock(rq, );
this_rq = task_rq_lock(current, );
}
+ WARN_ON(debug_rqbitmap(this_rq));
task_rq_unlock(this_rq, );
}
@@ -3357,6 +3384,7 @@ static inline void major_prio_rotation(s
rq->dyn_bitmap = rq->active->prio_bitmap;
rq->best_static_prio = MAX_PRIO - 1;
rq->prio_rotation++;
+ WARN_ON(debug_rqbitmap(rq));
}
/*
@@ -3399,6 +3427,8 @@ static inline void rotate_runqueue_prior
}
memset(rq->prio_quota, 0, ARRAY_SIZE(rq->prio_quota));
major_prio_rotation(rq);
+ WARN_ON(debug_rqbitmap(rq));
+
} else {
/* Minor rotation */
new_prio_level = rq->prio_level + 1;
@@ -3409,6 +3439,7 @@ static
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > This email lists some known regressions in Linus' tree compared to 2.6.20. > > If you find your name in the Cc header, you are either submitter of one > of the bugs, maintainer of an affectected subsystem or driver, a patch > of you caused a breakage or I'm considering you in any other way > possibly involved with one or more of these issues. > > Due to the huge amount of recipients, please trim the Cc when answering. > Subject: boot hangs during IDE detection (clocksource) > References : http://lkml.org/lkml/2007/3/19/465 > Submitter : Bob Tracy <[EMAIL PROTECTED]> > Caused-By : John Stultz <[EMAIL PROTECTED]> > commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd > Handled-By : John Stultz <[EMAIL PROTECTED]> > Status : problem is being debugged The incorrect clocksource selection is resolved w/ this patch: http://lkml.org/lkml/2007/3/22/287 There is still an issue of why the PIT clocksource hangs, but for the moment the issue its worked-around. thanks -john - 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] i386: clear segment register padding in core dumps
The segment register slots in struct pt_regs are padded to 32 bits. Some of these are stored with instructions like "pushl %es", which leaves the high 16 bits as they were. So the high bits of these fields in struct pt_regs contain kernel stack garbage. These bits are ignored by everything and never leak to user space, except in core dumps. The user struct pt_regs is always at the base of the thread's kernel stack and so it seems unlikely the information that leaks from here is ever worthwhile so as to be a security concern, but I'm not sure about that. It has been this way for ages; userland consumers of core dumps all mask off these high bits themselves. So it is not urgent. This change masks off the padding bits of the segment register slots in core dumps. ptrace already masks off these high bits, so this makes the values in core dumps consistent with what ptrace would report just before the process died. As I read the processor manuals, the cs and ss values will always be padded with zero bits rather than stack garbage. But unlike "pushl %es", this is not simple to test with a userland program. So I added the two instructions rather than wonder if they are really never necessary. I think that x86_64 does not have this problem (for either 32-bit or 64-bit processes). It only uses "mov" instructions from segment registers, which zero-extend. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- include/asm-i386/elf.h | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/asm-i386/elf.h b/include/asm-i386/elf.h index 8d33c9b..793bbd1 100644 --- a/include/asm-i386/elf.h +++ b/include/asm-i386/elf.h @@ -88,16 +88,16 @@ typedef struct user_fxsr_struct elf_fpxr pr_reg[4] = regs->edi; \ pr_reg[5] = regs->ebp; \ pr_reg[6] = regs->eax; \ - pr_reg[7] = regs->xds; \ - pr_reg[8] = regs->xes; \ - pr_reg[9] = regs->xfs; \ + pr_reg[7] = regs->xds & 0x; \ + pr_reg[8] = regs->xes & 0x; \ + pr_reg[9] = regs->xfs & 0x; \ savesegment(gs,pr_reg[10]); \ pr_reg[11] = regs->orig_eax;\ pr_reg[12] = regs->eip; \ - pr_reg[13] = regs->xcs; \ + pr_reg[13] = regs->xcs & 0x;\ pr_reg[14] = regs->eflags; \ pr_reg[15] = regs->esp; \ - pr_reg[16] = regs->xss; + pr_reg[16] = regs->xss & 0x; /* This yields a mask that user programs can use to figure out what instruction set this CPU supports. This could be done in user space, - 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 2.6.21-rc4] hwmon: HP Mobile Data Protection System 3D ACPI driver
Hi,
your code looks very nice and clean, only few comments, see below
> +static int mdps_joystick_kthread(void *data)
> +{
> + int x = 0, y = 0, z = 0;
> +
> + while (!kthread_should_stop()) {
> + if (input_3d) {
> + mdps_get_xyz(mdps.device->handle, , , );
> + input_report_abs(mdps.idev, ABS_Z, z - mdps.zcalib);
> + } else
> + mdps_get_xy(mdps.device->handle, , );
> +
> + input_report_abs(mdps.idev, ABS_X, x - mdps.xcalib);
> + input_report_abs(mdps.idev, ABS_Y, y - mdps.ycalib);
> +
> + input_sync(mdps.idev);
> +
> + try_to_freeze();
> + msleep_interruptible(MDPS_POLL_INTERVAL);
> + }
what if you get a signal? you probably at least want to handle that
somehow. Also, waking up every 30 miliseconds is going to suck up
power ... but that might not be avoidable I suppose if you have to poll
the hardware.
> +static int mdps_misc_open(struct inode *inode, struct file *file)
> +{
> + int ret;
> +
> + if (!atomic_dec_and_test()) {
> + atomic_inc();
> + return -EBUSY; /* already open */
> + }
I often get a bit nervous at seeing such "open me once" code, but it
might well be ok ... I'll let others comment
> +
> + atomic_set(, 0);
> +
> + ret = request_irq(mdps.irq, mdps_irq, 0, "mdps", mdps_irq);
don't you want to allow shared interrupts?
> + if (ret) {
> + printk(KERN_ERR "mdps: IRQ%d allocation failed\n", mdps.irq);
> + return -ENODEV;
> + }
wouldn't you want to inc the atomic in this case?
> +static ssize_t mdps_misc_read(struct file *file, char __user *buf,
> + size_t count, loff_t *pos)
> +{
> + DECLARE_WAITQUEUE(wait, current);
> + u32 data;
> + ssize_t retval = count;
> +
> + if (count != sizeof(u32))
> + return -EINVAL;
> +
> + add_wait_queue(_wait, );
> + for (;;) {
> + set_current_state(TASK_INTERRUPTIBLE);
> + data = atomic_xchg(, 0);
> + if (data)
> + break;
> +
> + if (file->f_flags & O_NONBLOCK) {
> + retval = -EAGAIN;
> + goto out;
> + }
> +
> + if (signal_pending(current)) {
> + retval = -ERESTARTSYS;
> + goto out;
> + }
> +
> + schedule();
> + }
> +
> + if (copy_to_user(buf, , sizeof(data)))
I'm not entirely sure you want to go into copy_to_user() with a
TASK_INTERRUPTIBLE state, I would feel a lot better if you did an
explicit __set_current_state(TASK_RUNNING) just before this.
> + retval = -EFAULT;
> +
> +out:
> + set_current_state(TASK_RUNNING);
.. which you do here anyway
> mdps_get_resource(struct acpi_resource *resource, void *context)
> +{
> + if (resource->type == ACPI_RESOURCE_TYPE_EXTENDED_IRQ) {
> + struct acpi_resource_extended_irq *irq;
> + u32 *device_irq = context;
> +
> + irq = >data.extended_irq;
> + *device_irq = irq->interrupts[0];
eh wait.. if this thing gives you an interrupt.. why do you need to poll
every 30 msec? am I missing something?
-
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 2.6.20.3] Flush writes to MSI-X table
On Thu, Mar 22, 2007 at 02:08:19PM -0700, Mitch Williams wrote: > Because both MSI-X interrupt messages and MSI-X table writes are posted, > it's possible for them to cross while in-flight. This results in > interrupts being received long after the kernel thinks they're disabled, > and in interrupts being sent to stale vectors after rebalancing. > > This patch performs a read flush after writes to the MSI-X table for > enable/disable and rebalancing operations. Because this is an expensive > operation, we do not perform the read flush after mask/unmask > operations. Hardware which supports MSI-X typically also supports some > sort of interrupt moderation, so a read-flush is not necessary for > mask/unmask operations. > > This patch has been validated with (unreleased) network hardware which > uses MSI-X. Is this needed for any hardware that is public today? Also, it seems a bit too big of a patch for -stable right now, especially as the mainline patch will not make it into 2.6.22 at the earliest. thanks, greg k-h - 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: introduce /dev/hugetlb
> -#ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
> -unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long
> addr,
> - unsigned long len, unsigned long pgoff, unsigned long flags);
> -#else
> -static unsigned long
> +unsigned long
> hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
> unsigned long len, unsigned long pgoff, unsigned long flags)
> {
> @@ -150,7 +145,6 @@ full_search:
> addr = ALIGN(vma->vm_end, HPAGE_SIZE);
> }
> }
> -#endif
WTF ? get_unmapped_area() -has- to be arch in some platforms like
power...
I'm trying to improve the whole get_unmapped_area() to better handle
multiple constraints (cacheability, page size, ...) though I haven't
quite yet settled on an interface I like.
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: [2/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:48 +0100, Adrian Bunk wrote:
> Subject: x86_64: ACPI regression with noapic (APICTIMER_STOPS_ON_C3?)
> References : http://lkml.org/lkml/2007/3/8/468
> http://lkml.org/lkml/2007/3/22/156
> Submitter : Ray Lee <[EMAIL PROTECTED]>
> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
> Status : problem is being debugged
Ray,
can you please test the patch below ?
Thanks,
tglx
-->
Subject: [PATCH] x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to itself
Ray Lee reported, that on an UP kernel with "noapic" commandline option
set, the box locks hard during boot.
Adding some debug printks revieled, that the last action on the box
before stalling was "Send IPI" - a debug printk which was put into
smp_send_timer_broadcast_ipi().
It seems that send_IPI_mask(mask, LOCAL_TIMER_VECTOR) fails when
"noapic" is set on the commandline on an UP kernel.
Aside of that it does not make much sense to trigger an interrupt
instead of calling the function directly on the CPU which gets the
PIT/HPET interrupt in case of broadcasting.
Reported-by: Ray Lee <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
index 723417d..83328e1 100644
--- a/arch/x86_64/kernel/apic.c
+++ b/arch/x86_64/kernel/apic.c
@@ -930,9 +930,17 @@ EXPORT_SYMBOL(switch_APIC_timer_to_ipi);
void smp_send_timer_broadcast_ipi(void)
{
+ int cpu = smp_processor_id();
cpumask_t mask;
cpus_and(mask, cpu_online_map, timer_interrupt_broadcast_ipi_mask);
+
+ if (cpu_isset(cpu, mask)) {
+ cpu_clear(cpu, mask);
+ add_pda(apic_timer_irqs, 1);
+ smp_local_timer_interrupt();
+ }
+
if (!cpus_empty(mask)) {
send_IPI_mask(mask, LOCAL_TIMER_VECTOR);
}
-
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 2.6.21-rc4] hwmon: HP Mobile Data Protection System 3D ACPI driver
Dmitry Torokhov wrote: Hi Yan, On 3/23/07, Yan Burman <[EMAIL PROTECTED]> wrote: + +static unsigned int input_3d; +module_param(input_3d, bool, S_IRUGO); +MODULE_PARM_DESC(input_3d, "Operate as a 3D joystick instead of 2D"); Why do you need that? Just have the driver always report all 3 events and have applications decide if they want to use ABS_Z events... Getting the coordinates goes through ACPI, so it eats up CPU. I think I remember seeing up to 15-16% CPU usage with all 3 events. That is why you probably want to disable it in most cases. - 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] sysctl: vfs_cache_divisor
Randy Dunlap wrote: Hi, That makes a lot of sense to me. It gives us finer-grained control without having to support fixed-point data. I've been working on the fixed-point data patch, but I'm going to give this method some time also, to see how it looks in code (instead of just thinking about it). Well, to be specific, it actually is the same thing with different syntax (38.55 or 3855/100). -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: HPA patches
On Fri, Mar 23, 2007 at 07:13:21PM +, Alan Cox wrote: > +static int ata_ignore_hpa = 0; > +module_param_named(ignore_hpa, ata_ignore_hpa, int, 0644); > +MODULE_PARM_DESC(ignore_hpa, "Ignore HPA (0=off 1=on)"); I'm not sure I like the language here. "Ignore HPA" appears to mean "Explicitly disable the HPA", which I guess is one interpretation of "ignore" - however, naively I'd expect "Ignore HPA" to mean "Don't touch the HPA" with the result that it would remain inaccessible to userspace. -- Matthew Garrett | [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: [3/5] 2.6.21-rc4: known regressions (v2)
On Friday, 23 March 2007 19:50, Adrian Bunk wrote: > This email lists some known regressions in Linus' tree compared to 2.6.20. > > If you find your name in the Cc header, you are either submitter of one > of the bugs, maintainer of an affectected subsystem or driver, a patch > of you caused a breakage or I'm considering you in any other way > possibly involved with one or more of these issues. > > Due to the huge amount of recipients, please trim the Cc when answering. > [--snip--] > Subject: suspend to disk hangs > References : http://lkml.org/lkml/2007/3/16/126 > Submitter : Maxim Levitsky <[EMAIL PROTECTED]> > Caused-By : Rafael J. Wysocki <[EMAIL PROTECTED]> > commit e3c7db621bed4afb8e231cb005057f2feb5db557 > commit ed746e3b18f4df18afa3763155972c5835f284c5 > commit 259130526c267550bc365d3015917d90667732f1 > Status : unknown The problem has been identified as the known issue related to the XFS freezable workqueues. There is a patch available (http://lkml.org/lkml/2007/3/21/328), that has been merged. Still, there is a problem with the microcode update driver that's being worked on. The reporters of the resume problems who use the microcode driver, please check if the problems go away if you unload the driver before the suspend. Greetings, 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: race condition in dm-crypt?
Jan C. Nordholz wrote: I think I'm experiencing a race condition: Irregularly my kernel runs into an Oops when it tries to initialize my crypt containers. FYI, there are similiar reports on the net, going as far back as May 2006: http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/1636 is the oldest one I could find. Bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=7388 I, too, ran into the bug and failed to reproduce it. However, it might be worth knowing that the system went to 100% iowait afterwards. Regards, Christoph Maier - 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: HPA patches
On Fri, 23 Mar 2007 12:22:32 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: Alan Cox <[EMAIL PROTECTED]> > Date: Fri, 23 Mar 2007 20:08:19 + > > > u64 is always unsigned long long (and its debug anyway) > > It's plain "unsigned long" on sparc64 and some other 64-bit platforms. I stand corrected. In which case Randy is right and I do need to go fix that formatting. 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: HPA patches
> > > What is 0x40? can it be #defined (or enum-ed) instead of a magic > > > value? please? (more of same below) > > > > It's 0x40. Its a "command dependant bit" - no useful name. > > dependent. OK, thanks. IDE is a bit like that. I'm amazed some of the command flags arent in latin. > Already corrected (printk types). And putting > hpa_sectors); > on a separate line doesn't hurt readability. Maybe Thanks for looking over the diff. 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] sysctl: vfs_cache_divisor
Kyle Moffett wrote: On Mar 21, 2007, at 19:11:40, Andrew Morton wrote: On Wed, 21 Mar 2007 16:01:32 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: I prefer the fixed-point values for pressure and dirty* to having duplicated entries for each of them. I'll proceed with that idea. Problem is, if a read of /proc/sys/vm/dirty_ratio is changed to return 7.457 then existing userspace might get confused. This might be acceptable if we are careful to ensure that reads of /proc/sys/vm/dirty_ratio will always return an integer if it was previously initialised with an integer. What about instead adding support for fractions (IE: "1/1000") in /proc/sys/vm/dirty_ratio? If the denominator is 100, the default, then it prints in the form "$NUMERATOR", otherwise it prints answers of the form "$NUMERATOR/$DENOMINATOR". Input could be of either form, with the kernel auto-setting the denominator to 100 if none is specified. Hi, That makes a lot of sense to me. It gives us finer-grained control without having to support fixed-point data. I've been working on the fixed-point data patch, but I'm going to give this method some time also, to see how it looks in code (instead of just thinking about it). Thanks. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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/
ALSA initialization still seems to be too late?
The commit below from 2005 (sic) seems to be an example that workarounds
often have quite a long lifetime.
Can we get this sorted out properly for 2.6.22?
TIA
Adrian
commit c7ac6b42ffba28c350cbcd48268f46689f6eb1cc
Author: Linus Torvalds <[EMAIL PROTECTED]>
Date: Wed Dec 21 14:52:32 2005 -0800
Initialize drivers/media/video/saa7134 late
When compiled-in, make sure the sound system has initialized
before these drivers do.
Reported by Adrian Bunk <[EMAIL PROTECTED]>
(The right fix would be to make the sound core use "subsys_initcall()"
and thus initialize before all normal drivers, but this is the quick
and limited safe fix for 2.6.15).
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
b/drivers/media/video/saa7134/saa7134-alsa.c
index 953d5fe..6752dd1 100644
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -1028,7 +1028,8 @@ static void saa7134_alsa_exit(void)
return;
}
-module_init(saa7134_alsa_init);
+/* We initialize this late, to make sure the sound system is up and running */
+late_initcall(saa7134_alsa_init);
module_exit(saa7134_alsa_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Ricardo Cerqueira");
diff --git a/drivers/media/video/saa7134/saa7134-oss.c
b/drivers/media/video/saa7134/saa7134-oss.c
index 513a699..c450d57 100644
--- a/drivers/media/video/saa7134/saa7134-oss.c
+++ b/drivers/media/video/saa7134/saa7134-oss.c
@@ -1002,7 +1002,8 @@ static void saa7134_oss_exit(void)
return;
}
-module_init(saa7134_oss_init);
+/* We initialize this late, to make sure the sound system is up and running */
+late_initcall(saa7134_oss_init);
module_exit(saa7134_oss_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Gerd Knorr <[EMAIL PROTECTED]> [SuSE Labs]");
-
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 2.6.21-rc4] hwmon: HP Mobile Data Protection System 3D ACPI driver
Hi Yan, On 3/23/07, Yan Burman <[EMAIL PROTECTED]> wrote: + +static unsigned int input_3d; +module_param(input_3d, bool, S_IRUGO); +MODULE_PARM_DESC(input_3d, "Operate as a 3D joystick instead of 2D"); Why do you need that? Just have the driver always report all 3 events and have applications decide if they want to use ABS_Z events... -- Dmitry - 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/
default functions for gpio
WHY I"M ASKING THIS QUESTION: I'm implementing some gpio calls in the ep93xx arch. My problem is that gpio's are really board specific, not just mach specific. I can code the function calls into my board init, but where should these functions be prototyped? Ideally, I think the compiler should build a "default" function for int gpio_request which fails, rather than a compile error for other boards within the same arch. THE ACTUAL QUESTION: Is there a way to build a "default" function, which is compiled in if it's not defined elsewhere? Anyone know where an example of this might be lurking. Also, if this is possible, is it a good idea? thx, NZG - 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/
Linux 2.6.20.4
We (the -stable team) are announcing the release of the 2.6.20.4 kernel. It contains a number of bugfixes and all 2.6.20 users are recommended to upgrade. The diffstat and short summary of the fixes are below. I'll also be replying to this message with a copy of the patch between 2.6.20.3 and 2.6.20.4. The updated 2.6.20.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.20.y.git and can be browsed at the normal kernel.org git web browser: www.kernel.org/git/ thanks, greg k-h Makefile |2 arch/ia64/kernel/iosapic.c |8 ++- arch/ia64/sn/kernel/irq.c| 14 +- arch/sparc64/kernel/ktlb.S |8 +++ arch/sparc64/kernel/tsb.S|1 arch/sparc64/lib/NGbzero.S |1 arch/sparc64/lib/NGmemcpy.S |2 arch/sparc64/lib/NGpage.S|2 arch/sparc64/mm/hugetlbpage.c|3 + arch/sparc64/mm/init.c | 30 - arch/um/include/os.h |2 arch/um/os-Linux/sys-x86_64/Makefile |2 arch/um/os-Linux/sys-x86_64/prctl.c | 12 + arch/um/sys-x86_64/syscalls.c| 76 ++- arch/um/sys-x86_64/tls.c | 11 +++-- drivers/input/serio/i8042.c | 20 ++--- drivers/md/linear.c |2 drivers/net/r8169.c | 10 ++-- drivers/pci/probe.c | 45 ++-- drivers/scsi/gdth.c |2 drivers/scsi/st.c| 23 +- drivers/scsi/st.h|3 - drivers/usb/host/ehci-hub.c |4 + fs/nfs/inode.c |3 - include/asm-sparc64/tsb.h|2 include/asm-um/processor-x86_64.h|6 +- include/asm-um/ptrace-x86_64.h |6 -- include/linux/ktime.h|6 ++ kernel/auditsc.c | 24 +-- kernel/fork.c|2 kernel/futex.c |2 kernel/hrtimer.c |6 ++ mm/filemap.c | 46 - mm/madvise.c |5 +- mm/oom_kill.c|2 net/core/skbuff.c|1 net/ipv4/cipso_ipv4.c|7 +-- net/ipv4/devinet.c |4 + net/ipv4/fib_trie.c |2 net/ipv6/ipv6_sockglue.c |2 net/ipv6/tcp_ipv6.c |1 net/irda/irttp.c |1 net/netfilter/nfnetlink_log.c|8 --- net/xfrm/xfrm_state.c|6 +- sound/pci/hda/hda_intel.c| 13 + 45 files changed, 321 insertions(+), 117 deletions(-) Summary of changes from v2.6.20.3 to v2.6.20.4 == Al Viro (1): fix deadlock in audit_log_task_context() Alan Stern (1): EHCI: add delay to bus_resume before accessing ports Alexey Dobriyan (1): Copy over mac_len when cloning an skb Andy Isaacson (1): fix read past end of array in md/linear.c Ankita Garg (1): oom fix: prevent oom from killing a process with children/sibling unkillable David Miller (3): Fix sparc64 hugepage bugs Fix page allocation debugging on sparc64 Fix niagara memory corruption Dmitry Torokhov (3): Input: i8042 - really suppress ACK/NAK during panic blink Input: i8042 - fix AUX IRQ delivery check Input: i8042 - another attempt to fix AUX delivery checks Evgeniy Polyakov (1): Fix rtm_to_ifaddr() error return. Francois Romieu (1): r8169: fix a race between PCI probe and dev_open Greg Kroah-Hartman (1): Linux 2.6.20.4 Ingo Molnar (1): futex: PI state locking fix Jan Beulich (1): adjust legacy IDE resource setting (v2) Jeff Dike (1): UML - arch_prctl should set thread fs Joerg Dorchain (1): gdth: fix oops in gdth_copy_cmd() Joy Latten (1): Fix extraneous IPSEC larval SA creation KAMEZAWA Hiroyuki (1): IA64: fix NULL pointer in ia64/irq_chip-mask/unmask function Kai Makisara (1): st: fix Tape dies if wrong block size used, bug 7919 Masayuki Nakagawa (1): Fix ipv6 flow label inheritance Michal Miroslaw (1): NETFILTER: nfnetlink_log: fix reference counting Nick Piggin (1): mm: fix madvise infinine loop Olaf Kirch (1): Fix another NULL pointer deref in ipv6_sockglue.c Paul Moore (1): NetLabel: Verify sensitivity level has a valid CIPSO mapping Robert Olsson (1): Fix GFP_KERNEL with preemption disabled in fib_trie Samuel Ortiz (1): IrDA: irttp_dup spin_lock initialisation Takashi Iwai (1): hda-intel - Fix codec probe with ATI controllers Thomas Gleixner (2): hrtimer: prevent overrun DoS in hrtimer_forward() fix MTIME_SEC_MAX on 32-bit Trond
Re: Linux 2.6.20.4
diff --git a/Makefile b/Makefile
index 7d2f304..ea076ae 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 20
-EXTRAVERSION = .3
+EXTRAVERSION = .4
NAME = Homicidal Dwarf Hamster
# *DOCUMENTATION*
diff --git a/arch/ia64/kernel/iosapic.c b/arch/ia64/kernel/iosapic.c
index 0fc5fb7..02479e1 100644
--- a/arch/ia64/kernel/iosapic.c
+++ b/arch/ia64/kernel/iosapic.c
@@ -446,7 +446,7 @@ iosapic_end_level_irq (unsigned int irq)
#define iosapic_disable_level_irq mask_irq
#define iosapic_ack_level_irq nop
-struct hw_interrupt_type irq_type_iosapic_level = {
+struct irq_chip irq_type_iosapic_level = {
.name = "IO-SAPIC-level",
.startup = iosapic_startup_level_irq,
.shutdown = iosapic_shutdown_level_irq,
@@ -454,6 +454,8 @@ struct hw_interrupt_type irq_type_iosapic_level = {
.disable = iosapic_disable_level_irq,
.ack = iosapic_ack_level_irq,
.end = iosapic_end_level_irq,
+ .mask = mask_irq,
+ .unmask = unmask_irq,
.set_affinity = iosapic_set_affinity
};
@@ -493,7 +495,7 @@ iosapic_ack_edge_irq (unsigned int irq)
#define iosapic_disable_edge_irq nop
#define iosapic_end_edge_irq nop
-struct hw_interrupt_type irq_type_iosapic_edge = {
+struct irq_chip irq_type_iosapic_edge = {
.name = "IO-SAPIC-edge",
.startup = iosapic_startup_edge_irq,
.shutdown = iosapic_disable_edge_irq,
@@ -501,6 +503,8 @@ struct hw_interrupt_type irq_type_iosapic_edge = {
.disable = iosapic_disable_edge_irq,
.ack = iosapic_ack_edge_irq,
.end = iosapic_end_edge_irq,
+ .mask = mask_irq,
+ .unmask = unmask_irq,
.set_affinity = iosapic_set_affinity
};
diff --git a/arch/ia64/sn/kernel/irq.c b/arch/ia64/sn/kernel/irq.c
index 8c5bee0..8d2a1bf 100644
--- a/arch/ia64/sn/kernel/irq.c
+++ b/arch/ia64/sn/kernel/irq.c
@@ -205,7 +205,17 @@ static void sn_set_affinity_irq(unsigned int irq,
cpumask_t mask)
(void)sn_retarget_vector(sn_irq_info, nasid, slice);
}
-struct hw_interrupt_type irq_type_sn = {
+static void
+sn_mask_irq(unsigned int irq)
+{
+}
+
+static void
+sn_unmask_irq(unsigned int irq)
+{
+}
+
+struct irq_chip irq_type_sn = {
.name = "SN hub",
.startup= sn_startup_irq,
.shutdown = sn_shutdown_irq,
@@ -213,6 +223,8 @@ struct hw_interrupt_type irq_type_sn = {
.disable= sn_disable_irq,
.ack= sn_ack_irq,
.end= sn_end_irq,
+ .mask = sn_mask_irq,
+ .unmask = sn_unmask_irq,
.set_affinity = sn_set_affinity_irq
};
diff --git a/arch/sparc64/kernel/ktlb.S b/arch/sparc64/kernel/ktlb.S
index e492db8..d4024ac 100644
--- a/arch/sparc64/kernel/ktlb.S
+++ b/arch/sparc64/kernel/ktlb.S
@@ -138,9 +138,15 @@ kvmap_dtlb_4v:
brgez,pn%g4, kvmap_dtlb_nonlinear
nop
+#ifdef CONFIG_DEBUG_PAGEALLOC
+ /* Index through the base page size TSB even for linear
+* mappings when using page allocation debugging.
+*/
+ KERN_TSB_LOOKUP_TL1(%g4, %g6, %g5, %g1, %g2, %g3, kvmap_dtlb_load)
+#else
/* Correct TAG_TARGET is already in %g6, check 4mb TSB. */
KERN_TSB4M_LOOKUP_TL1(%g6, %g5, %g1, %g2, %g3, kvmap_dtlb_load)
-
+#endif
/* TSB entry address left in %g1, lookup linear PTE.
* Must preserve %g1 and %g6 (TAG).
*/
diff --git a/arch/sparc64/kernel/tsb.S b/arch/sparc64/kernel/tsb.S
index eedf94f..10adb2f 100644
--- a/arch/sparc64/kernel/tsb.S
+++ b/arch/sparc64/kernel/tsb.S
@@ -546,6 +546,7 @@ NGtsb_init:
subcc %o1, 0x100, %o1
bne,pt %xcc, 1b
add%o0, 0x100, %o0
+ membar #Sync
retl
wr %g2, 0x0, %asi
.size NGtsb_init, .-NGtsb_init
diff --git a/arch/sparc64/lib/NGbzero.S b/arch/sparc64/lib/NGbzero.S
index e86baec..f10e452 100644
--- a/arch/sparc64/lib/NGbzero.S
+++ b/arch/sparc64/lib/NGbzero.S
@@ -88,6 +88,7 @@ NGbzero_loop:
bne,pt %xcc, NGbzero_loop
add%o0, 64, %o0
+ membar #Sync
wr %o4, 0x0, %asi
brz,pn %o1, NGbzero_done
NGbzero_medium:
diff --git a/arch/sparc64/lib/NGmemcpy.S b/arch/sparc64/lib/NGmemcpy.S
index 8e522b3..66063a9 100644
--- a/arch/sparc64/lib/NGmemcpy.S
+++ b/arch/sparc64/lib/NGmemcpy.S
@@ -247,6 +247,8 @@ FUNC_NAME: /* %o0=dst, %o1=src, %o2=len */
/* fall through */
60:
+ membar #Sync
+
/* %o2 contains any final bytes still needed to be copied
* over. If anything is left, we copy it one byte at a time.
*/
diff --git a/arch/sparc64/lib/NGpage.S b/arch/sparc64/lib/NGpage.S
index 7d7c3bb..8ce3a0c 100644
---
Re: request_queue_t depends on CONFIG_BLOCK
On Friday 23 March 2007, Olaf Hering wrote: > On Fri, Mar 23, Bartlomiej Zolnierkiewicz wrote: > > > > Because it is needed in a few places. > > > > Is there really any PPC64 specific code which needs > > (ppc_ide_md is used only by PPC32)? I suspect that the answer to my question is "not really", if so then shouldn't the problem that you've encountered be fixed with a one-line patch which removes include from arch/powerpc/kernel/setup_64.c? Please try it. > This is about CONFIG_BLOCK=n, not about arch/... Is all non-driver > code which has to poke into ide code supposed to put an #ifdef > CONFIG_IDE around #include ? Such code is _broken_ (as you've just found out) by _implicitly_ depending on CONFIG_IDE specific data structures and functions. Please note that is CONFIG_IDE specific and CONFIG_IDE depends on CONFIG_BLOCK=y so should _not_ be included et all for CONFIG_BLOCK=n case... PS IDE subsystem has allowed per arch/platform host drivers for years and if somebody needs help in fixing the existing arch/... (ab)users of I'll be glad to provide it. Thanks, Bart - 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: HPA patches
On Fri, 23 Mar 2007 20:08:19 + Alan Cox wrote:
> > > +static int ata_ignore_hpa = 0;
> >
> > Don't init to 0. Not needed, bloats binary files.
>
> It'll be one for the final release 8)
>
> > > +module_param_named(ignore_hpa, ata_ignore_hpa, int, 0644);
> > > +MODULE_PARM_DESC(ignore_hpa, "Ignore HPA (0=off 1=on)");
> >
> > So 1 = on = ignore, right?
>
> Yes.
>
> > > + tf.command = ATA_CMD_READ_NATIVE_MAX_EXT;
> > > + tf.flags |= ATA_TFLAG_DEVICE | ATA_TFLAG_LBA48 | ATA_TFLAG_ISADDR;
> > > + tf.protocol |= ATA_PROT_NODATA;
> > > + tf.device = 0x40;
> >
> > What is 0x40? can it be #defined (or enum-ed) instead of a magic
> > value? please? (more of same below)
>
> It's 0x40. Its a "command dependant bit" - no useful name.
dependent. OK, thanks.
> > > + u64 sectors = dev->n_sectors;
> > > + u64 hpa_sectors;
> > > +
> > > + if (ata_id_has_lba48(dev->id))
> > > + hpa_sectors = ata_read_native_max_address_ext(dev);
> > > + else
> > > + hpa_sectors = ata_read_native_max_address(dev);
> > > +
> > > + /* if no hpa, both should be equal */
> > > + ata_dev_printk(dev, KERN_INFO, "%s 1: sectors = %lld, hpa_sectors =
> > > %lld\n",
> > > + __FUNCTION__, sectors, hpa_sectors);
> >
> > (long long) or (unsigned long long) on sectors and hpa_sectors...
>
> u64 is always unsigned long long (and its debug anyway)
>
> >
> > > +
> > > + if (hpa_sectors > sectors) {
> > > + ata_dev_printk(dev, KERN_INFO,
> > > + "Host Protected Area detected:\n"
> > > + "\tcurrent size: %lld sectors\n"
> > > + "\tnative size: %lld sectors\n",
> > > + sectors, hpa_sectors);
> >
> > printk format types ok?
>
> Yes
>
> > > + if (hpa_sectors) {
> > > + ata_dev_printk(dev, KERN_INFO,
> > > + "native size increased to %lld
> > > sectors\n", hpa_sectors);
> >
> > Line lengths < 80 and printk format types?
>
> See above, and the 80 column fascists can suffer in the name of
> readability.
Already corrected (printk types). And putting
hpa_sectors);
on a separate line doesn't hurt readability.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > Subject: soft lockup detected on CPU#0 > References : http://lkml.org/lkml/2007/3/3/152 > Submitter : Michal Piotrowski <[EMAIL PROTECTED]> > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > Ingo Molnar <[EMAIL PROTECTED]> > Status : unknown Michal, any news on that one ? You said the same problem exists in 2.6.20.1. Has this been resolved in 2.6.20.2/3 Thanks, tglx - 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] utsns: fix !CONFIG_UTS_NS behavior
From: "Serge E. Hallyn" <[EMAIL PROTECTED]>
Subject: [PATCH] utsns: fix !CONFIG_UTS_NS behavior
When CONFIG_UTS_NS=n, clone(CLONE_NEWUTS) quietly refuses. So correctly does
not unshare a new uts namespace, but also does not return -EINVAL.
Fix this to return -EINVAL so the caller knows his request was denied.
Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
---
include/linux/utsname.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
bc350994ac67df8f1b917f9979c065d87757eabe
diff --git a/include/linux/utsname.h b/include/linux/utsname.h
index a4555fe..e10267d 100644
--- a/include/linux/utsname.h
+++ b/include/linux/utsname.h
@@ -70,6 +70,8 @@ static inline int unshare_utsname(unsign
static inline int copy_utsname(int flags, struct task_struct *tsk)
{
+ if (flags & CLONE_NEWUTS)
+ return -EINVAL;
return 0;
}
static inline void put_uts_ns(struct uts_namespace *ns)
--
1.1.6
-
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: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > Subject: Dynticks and High resolution Timer hanging the system > workaround: clocksource=acpi_pm > References : http://lkml.org/lkml/2007/3/7/504 > Submitter : Stephane Casset <[EMAIL PROTECTED]> > Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> > Status : unknown Stephane, does the problem still exists with Linus latest ? Thanks, tglx - 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] [bugfix] loop.c
Eric Dumazet wrote:
[]
>
> MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-16384)");
Speaking of which, I wonder... Here, and in many other places.
If some variable is marked as MODULE_PARAM (or whatever it is called
nowadays), used in module init routine, AND subsequently used for various
bound checks and loops...
Consider this:
MODULE_PARAM(n);
foo_init() {
mem = kmalloc(n * sizeof(void*));
..
}
foo_func() {
for (i = 0; i < n; ++i)
do_something_with_mem(mem[i])
}
and so on. Together with:
# modprobe foo n=10
# echo 20 > /sys/module/foo/parameters/n
After that, we have 10 entries in mem[], and
n is equal to 20, so the for-loop above will be
up to i=19. Which will reference unallocated
memory
Amd I dreaming?
Thanks.
/mjt
-
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: [Bluez-devel] 2.6.21-rc4-mm1
On Wed, 2007-03-21 at 15:12 +0100, Marcel Holtmann wrote: > Hi Andrew, > > > > * Freezes immediately if I allow Bluetooth to configure. > > > > cc bluez-devel > > is the -mm specific or does this also happens with 2.6.21-rc4? Bluetooth works now, so it isn't entirely -mm's fault. I applied a posted patch for the Sonic Silicon Backplane. I also set all the older BCM43xx driver modules to N, and my freeze with wireless went away. On this laptop (a Compaq R3000) the Bluetooth and the wireless are controlled by the same front panel button, so I wonder if they are related in other ways as well. If I get a chance to play with it this weekend I will see if I can isolate the change that fixes/breaks it. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way
> possibly involved with one or more of these issues.
>
> Due to the huge amount of recipients, please trim the Cc when answering.
>
>
> Subject: system doesn't come out of suspend (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/2/22/391
> Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]>
> Soeren Sonnenburg <[EMAIL PROTECTED]>
> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
> Ingo Molnar <[EMAIL PROTECTED]>
> Tejun Heo <[EMAIL PROTECTED]>
> Rafael J. Wysocki <[EMAIL PROTECTED]>
> Status : problem is being debugged
>
>
> Subject: first disk access after resume takes several minutes
> ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> References : http://lkml.org/lkml/2007/3/8/117
> Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]>
> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
> Ingo Molnar <[EMAIL PROTECTED]>
> Status : problem is being debugged
I lost track of Michaels various nested problems.
Michael can you please give a summary on _all_ entries in the
regressions list against Linus latest ?
Thanks,
tglx
-
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] UML - host VDSO fix
This fixes a problem seen by a number of people running UML on newer host
kernels. init would hang with an infinite segfault loop.
It turns out that the host kernel was providing a AT_SYSINFO_EHDR of
0xe000, which faked UML into believing that the host VDSO page could be
reused. However, AT_SYSINFO pointed into the middle of the address space, and
was unmapped as a result. Because UML was providing AT_SYSINFO_EHDR and
AT_SYSINFO to its own processes, these would branch to nowhere when trying to
use the VDSO.
The fix is to also check the location of AT_SYSINFO when deciding whether to
use the host's VDSO.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/os-Linux/elf_aux.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6.17/arch/um/os-Linux/elf_aux.c
===
--- linux-2.6.17.orig/arch/um/os-Linux/elf_aux.c2007-02-23
15:00:51.0 -0500
+++ linux-2.6.17/arch/um/os-Linux/elf_aux.c 2007-02-23 15:09:58.0
-0500
@@ -39,6 +39,9 @@ __init void scan_elf_aux( char **envp)
switch ( auxv->a_type ) {
case AT_SYSINFO:
__kernel_vsyscall = auxv->a_un.a_val;
+ /* See if the page is under TASK_SIZE */
+ if (__kernel_vsyscall < (unsigned long) envp)
+ __kernel_vsyscall = 0;
break;
case AT_SYSINFO_EHDR:
vsyscall_ehdr = auxv->a_un.a_val;
-
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.21-rc4-mm1
On Wed, 2007-03-21 at 11:13 -0500, Larry Finger wrote: > Andrew Morton wrote: > > On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx <[EMAIL PROTECTED]> wrote: > >> First impressions: > >> Several of the same bugs as rc3-mm*: > >> * Freezes immediately if I touch the wlan0 device after loading > >> the new Broadcom wireless driver. > > --snip-- > > >> 02:02.0 Network controller: Broadcom Corporation BCM4303 802.11b Wireless > >> LAN Controller (rev 02) > > I'm a little confused. The bcm43xx-mac80211 driver does not handle 802.11b > devices, and the > bcm43xx-softmac driver should not freeze. Which one was configured here? It may have partly been a problem of having half of softmac and half devicescape. I'm not entirely sure what udev did. I tried a patch for the Sonic Silicon that was posted and I turned off all the configuration for the softmac driver. It isn't crashing right now but 802.11 isn't working either. I may get a chance this weekend to try some things with it, and some different firmware sets. If the new bcm43xx drivers do not support 802.11b at all and never will, I missed the documentation. Someone should add that to Kconfig. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
[BUG][x86_64]pci layer may report wrong iomem resources data to drivers
lo,
aic7xxx driver mmio / dma on x86_64 linux broken here.
i need some comments and further investigation advice on this:
(resend, mozilla misconfig )
thomas schorpp wrote:
James Bottomley wrote:
On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
i agree for this to be a 32bit dma busmaster chip,
since pci_resource_flags and lspci say 64bit mem resource type
aic7xxx: pci_resource_start f000 *maddr 2 mem64 4
static int
ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
u_long *bus_addr,
uint8_t __iomem **maddr)
{
// u_long start;
u_long len;
int error;
uint64_t start;
...
printk(KERN_WARNING "aic7xxx: pci_resource_start 0x%llx mem64 0x%lx\n", start,
pci_resource_flags(ahc->dev_softc, 1) & PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp
return (error);
aic7xxx: pci_resource_start 0xff000 mem64 0x4
---^
just to doublecheck the situation, posted lspci already.
will check next, if
len = pci_resource_len(ahc->dev_softc, 1);
if (start != 0) {
*bus_addr = start;
// if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
if (request_mem_region(start, len, "aic7xxx") == 0)
succeeds.
no. so the pci layer reports wrong start:
start = pci_resource_start(ahc->dev_softc, 1);
len = pci_resource_len(ahc->dev_softc, 1);
if (start != 0) {
*bus_addr = start;
// if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
if (request_mem_region(start, len, "aic7xxx") == 0)
error = ENOMEM;
printk(KERN_WARNING "aic7xxx: req_mem_region 0x%x memlen 0x%lx \n",
error, len ); //schorpp
tom1:~# dmesg |grep aic
aic7xxx: DMA_32BIT_MASK
aic7xxx: req_mem_region 0x0 memlen 0x1000
aic7xxx: pci_resource_start 0xff000 *maddr 0x2 mem64 0x4
aic7xxx: PCI Device 0:6:0 failed memory mapped test. Using PIO.
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
we've a bug in the x86_64 linux pci config, BIOS is ok, the hardware worked
fine in a winxp_x64 test setup a few months ago.
will ask LKML.
y
tom
sorry, wrong according to http://download.adaptec.com/pdfs/aic7892.pdf.
"66 MHz, 64-bit, PCI interface that
supports zero wait-state memory;
also operates on 33 MHz, 32-bit
PCI busses"
this chip is capable of 64bit addressing, as pci_resource_ (checking this)
on x86_64 platform and lspci on x86_64 *and* AMDK7 configured kernels reports,
even on PCI/32, right?
or is it impossible to do multiplexed 64bit mem addressing on PCI/32?
It can only do 37 bit addressing ... only the aic79xx can do the full 64
bits, so I suspect it should never get a 64 bit BAR, since it wouldn't
be able to decode the full 32 bits. I can fix the mmio check not to
hang, but the card won't actually work mmio until whatever's assigning
the BAR above 32 bits is fixed (that could either be a kernel PCI bug or
a BIOS bug).
ok, i trust in that. adaptor bios and mainboard bios *are* out, winxp_x64
driver handled all.
so agree on kernel pci hal issue.
but what for const uint64_t mask_39bit = 0x7FULL;
then?
can adaptec.inc pls comment? since the aha19160 card is still in production
state, i assume they want to have a linux x86_64 dma capable driver. so far it
is not, or can other users having this card pls confirm my pci system broken?
James
y
tom
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.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/
Linux-VServer example results for sharing vs. separate mappings ...
Hi Eric! Hi Folks! here is a real world example result from one of my tests regarding the benefit of sharing over separate memory the setup is quite simple, a typical machine used by providers all over the world, a dual Pentium D 3.2GHz with 4GB of memory and a single 160GB SATA disk running a Linux-VServer kernel (2.6.19.7-vs2.2.0-rc18) the Guest systems used are Mandriva 2007 guests with syslog, crond, sshd, apache, postfix and postgresql installed and running (all in all 17 processes per guest) the disk space used by one guests is roughly 148MB in addition to that, a normal host system is running with a few daemons (like sshd, httpd, postfix ...) the first test setup is starting 200 of those guests one after the other and measuring the memory usage before and after the guest did start, as well as recording the time used to start them ... this is done right after the machine was rebooted, in one test with 200 separate guests (i.e. 200 x 148MB) and in a second run with 200 unified guests (which means roughly 138MB of shared files) separate guests: GUEST TIMEACTIVE BUFFERS CACHEANON MAPPEDSLAB RECLAIM URECL -- 001 0 163642600 20716474834608164 24565708 002 7 307003816 4211290528200 11056 38847172 003 13 446404872 62112 13364 12872 13248 52687980 004 20 585045972 82028 17684 17504 15348 66168732 005 28 723527056 102052 21948 22172 17640 80209620 1961567 2072172 156404 2409368 841168 915484 414056 246952 167104 1971576 2080836 154680 2402344 845544 920268 414432 246784 167648 1981585 2093424 153400 2399560 849696 924760 414892 246572 168320 1991593 2103368 151540 2394048 854020 929660 415300 246324 168976 2001599 2113004 149272 2382964 858344 934336 415528 245896 169632 unified guests: GUEST TIMEACTIVE BUFFERS CACHEANON MAPPEDSLAB RECLAIM URECL -- 001 0 165762620 20948476034448232 25205712 002 10 313684672 7495690688140 12976 57607216 003 14 35364 110508 133689696 16516 83608156 004 18 440686104 146044 17696 11236 19868109728896 005 22 493246824 181540 21964 12764 23264135809684 1961289 1159780 88856 2503448 841864 304544 383196 232944 150252 1971294 1166528 88524 2500616 846168 306068 384056 233096 150960 1981304 1172124 88468 2492268 850452 307596 384560 232988 151572 1991313 1178876 88896 2488476 854840 309092 385384 233064 152320 2001322 1184368 88568 2483208 858988 310640 386256 233388 152868 the second test was quite interesting too, as it showed nicely what the effect on the overall performance can be: in this test, all guests are started at the same time, and the script waits until the last guest has successfully started ... the 200 separate guests (as you probably can imagine) caused quite a load when started at once (there are a number of userspace tools preparing the guest on startup and setting up the context) and obviously they also pushed the memory limits somewhat ... the startup for 200 separate guests (at once) did take this system 1h 11m 27s (compared to the 26m 39s in sequence) the startup for 200 unified guests (at once) OTOH, did take 45s (yes, below a minute! compared to 22m 2s in sequential order) HTH, Herbert PS: if you need details for the setup, and/or want to recreate that on your system, just let me know, I can provide all the required data (including the guests) - 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/
other potentially deletable header files
include/ math-emu/ extended.h media/ cs53l32a.h wm8775.h thoughts? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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] queued spinlocks (i386)
On Fri, Mar 23, 2007 at 10:40:17AM +0100, Eric Dumazet wrote:
> On Fri, 23 Mar 2007 09:59:11 +0100
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> >
> > Implement queued spinlocks for i386. This shouldn't increase the size of
> > the spinlock structure, while still able to handle 2^16 CPUs.
> >
> > Not completely implemented with assembly yet, to make the algorithm a bit
> > clearer.
> >
> > The queued spinlock has 2 fields, a head and a tail, which are indexes
> > into a FIFO of waiting CPUs. To take a spinlock, a CPU performs an
> > "atomic_inc_return" on the head index, and keeps the returned value as
> > a ticket. The CPU then spins until the tail index is equal to that
> > ticket.
> >
> > To unlock a spinlock, the tail index is incremented (this can be non
> > atomic, because only the lock owner will modify tail).
> >
> > Implementation inefficiencies aside, this change should have little
> > effect on performance for uncontended locks, but will have quite a
> > large cost for highly contended locks [O(N) cacheline transfers vs
> > O(1) per lock aquisition, where N is the number of CPUs contending].
> > The benefit is is that contended locks will not cause any starvation.
> >
> > Just an idea. Big NUMA hardware seems to have fairness logic that
> > prevents starvation for the regular spinlock logic. But it might be
> > interesting for -rt kernel or systems with starvation issues.
>
> It's a very nice idea Nick.
Amen to that.
>
> You also have for free the number or cpus that are before you.
>
> On big SMP/NUMA, we could use this information to call a special
> lock_cpu_relax() function to avoid cacheline transferts.
>
> asm volatile(LOCK_PREFIX "xaddw %0, %1\n\t"
>: "+r" (pos), "+m" (lock->qhead) : : "memory");
> for (;;) {
> unsigned short nwait = pos - lock->qtail;
> if (likely(nwait == 0))
> break;
> lock_cpu_relax(lock, nwait);
> }
>
> lock_cpu_relax(raw_spinlock_t *lock, unsigned int nwait)
> {
> unsigned int cycles = nwait * lock->min_cycles_per_round;
> busy_loop(cycles);
> }
Good Idea. Hopefully, this should reduce the number of cacheline transfers
in the contended case.
-
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/
[BUG][x86_64]pci layer may report wrong iomem resources data to drivers
lo,
aic7xxx driver mmio / dma on x86_64 linux broken here.
i need some comments and further investigation advice on this:
thomas schorpp wrote:
James Bottomley wrote:
On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
i agree for this to be a 32bit dma busmaster chip, since
pci_resource_flags and lspci say 64bit mem resource type
aic7xxx: pci_resource_start f000 *maddr 2 mem64 4
static int ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
u_long *bus_addr, uint8_t __iomem **maddr) { // u_long start;
u_long len; int error; uint64_t start; ...
printk(KERN_WARNING "aic7xxx: pci_resource_start 0x%llx mem64
0x%lx\n", start, pci_resource_flags(ahc->dev_softc, 1) &
PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp return (error);
aic7xxx: pci_resource_start 0xff000 mem64 0x4
---^
just to doublecheck the situation, posted lspci already.
will check next, if len = pci_resource_len(ahc->dev_softc, 1); if
(start != 0) { *bus_addr = start; // if
(request_mem_region(start, 0x1000, "aic7xxx") == 0) if
(request_mem_region(start, len, "aic7xxx") == 0)
succeeds.
no. so the pci layer reports wrong start:
start = pci_resource_start(ahc->dev_softc, 1); len =
pci_resource_len(ahc->dev_softc, 1); if (start != 0) { *bus_addr =
start; // if (request_mem_region(start, 0x1000,
"aic7xxx") == 0) if (request_mem_region(start, len, "aic7xxx") == 0)
error = ENOMEM; printk(KERN_WARNING "aic7xxx: req_mem_region 0x%x
memlen 0x%lx \n", error, len ); //schorpp
tom1:~# dmesg |grep aic aic7xxx: DMA_32BIT_MASK aic7xxx:
req_mem_region 0x0 memlen 0x1000 aic7xxx: pci_resource_start
0xff000 *maddr 0x2 mem64 0x4 aic7xxx: PCI Device 0:6:0 failed
memory mapped test. Using PIO. aic7892: Ultra160 Wide Channel A,
SCSI Id=7, 32/253 SCBs
we've a bug in the x86_64 linux pci config, BIOS is ok, the
hardware worked fine in a winxp_x64 test setup a few months
ago.
will ask LKML.
y tom
sorry, wrong according to
http://download.adaptec.com/pdfs/aic7892.pdf.
"66 MHz, 64-bit, PCI interface that supports zero wait-state
memory; also operates on 33 MHz, 32-bit PCI busses"
this chip is capable of 64bit addressing, as pci_resource_
(checking this) on x86_64 platform and lspci on x86_64 *and*
AMDK7 configured kernels reports, even on PCI/32, right? or is
it impossible to do multiplexed 64bit mem addressing on PCI/32?
It can only do 37 bit addressing ... only the aic79xx can do the
full 64 bits, so I suspect it should never get a 64 bit BAR,
since it wouldn't be able to decode the full 32 bits. I can fix
the mmio check not to hang, but the card won't actually work mmio
until whatever's assigning the BAR above 32 bits is fixed (that
could either be a kernel PCI bug or a BIOS bug).
ok, i trust in that. adaptor bios and mainboard bios *are* out,
winxp_x64 driver handled all. so agree on kernel pci hal issue. but
what for const uint64_t mask_39bit = 0x7FULL;
then?
can adaptec.inc pls comment? since the aha19160 card is still
in production state, i assume they want to have a linux x86_64
dma capable driver. so far it is not, or can other users having
this card pls confirm my pci system broken?
James
y tom
- To unsubscribe from this list: send the line "unsubscribe
linux-scsi" in the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.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: BUG: soft lockup during suspend
Takashi Iwai wrote: > At Tue, 20 Mar 2007 17:08:48 +0100, > I wrote: >> At Tue, 20 Mar 2007 12:05:07 -0400, >>> >>> http://lkml.org/lkml/2006/12/3/9 >> This is a different problem. >> A known workaround is to provide probe_mask=1 module option. > > BTW, does this happen on the latest linus git tree? (rc4 may work, > though) > 2.6.21-rc4 works perfectly, detecting my Acer notebook's model properly and adding the sound devices to the bus. Very nice... - 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: HPA patches
From: Alan Cox <[EMAIL PROTECTED]> Date: Fri, 23 Mar 2007 20:08:19 + > u64 is always unsigned long long (and its debug anyway) It's plain "unsigned long" on sparc64 and some other 64-bit platforms. - 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: [QUICKLIST 1/5] Quicklists for page table pages V4
On Thu, Mar 22, 2007 at 11:48:48PM -0800, Andrew Morton wrote: >>> afacit that two-year-old, totally-different patch has nothing to do with my >>> repeatedly-asked question. It appears to be consolidating three separate >>> quicklist allocators into one common implementation. >>> In an attempt to answer my own question (and hence to justify the retention >>> of this custom allocator) I did this: >> [... patch changing allocator alloc()/free() to bare page allocations ...] >>> but it crashes early in the page allocator (i386) and I don't see why. It >>> makes me wonder if we have a use-after-free which is hidden by the presence >>> of the quicklist buffering or something. On Fri, Mar 23, 2007 at 04:29:20AM -0700, William Lee Irwin III wrote: >> Sorry I flubbed the first message. Anyway this does mean something is >> seriously wrong and needs to be debugged. Looking into it now. On Fri, Mar 23, 2007 at 07:57:07AM -0700, William Lee Irwin III wrote: > I know what's happening. I just need to catch the culprit. Are you tripping the BUG_ON() in include/linux/mm.h:256 with CONFIG_DEBUG_VM set? -- wli - 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: [4/5] 2.6.21-rc4: known regressions (v2)
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote: > Subject: dynticks makes ksoftirqd1 use unreasonable amount of cpu time > References : http://bugzilla.kernel.org/show_bug.cgi?id=8100 > Submitter : Emil Karlson <[EMAIL PROTECTED]> > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > Status : problem is being debugged The problem is not reproducible on any of my machines. Emil, is it still there with Linus latest ? tglx - 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/
