Re: AppArmor Security Goal
On Sat, November 10, 2007 22:04, Andi Kleen wrote: > Crispin Cowan <[EMAIL PROTECTED]> writes: > > The document should be a good base for a merge. > >> * A confined process can operate on a file descriptor passed to it >> by an unconfined process, even if it manipulates a file not in the >> confined process's profile. To block this attack, confine the >> process that passed the file descriptor. > > That is the only thing that tripped me up a bit while reading the > document. > Can you expand a bit on the reasons why the fd is not rechecked in > the context of the target process? Best do it in a new version of the > document. You must try to considder what could actualy be a valid reason for re-checking here, and what it could accomplish. If the unconfined process A is in 'full communication' with the unconfined process B and wants B to have the 'authority' to do anything with file C that it can do, there is no way of stopping A from doing so. Stopping A from communicating its 'permission' to do so would thus be useless for that purpose. The only way of stopping A from comminucating its authority with A is stopping A from communicating with B period. Ones you accept that trying to stop delegation of authority by stopping delegation of permission is useless, you can see that ther are major advantages with respect to allowing a process with least authority, if you actualy 'accomodate' the delegation of authority. This is the main reason why I actualy feel strongly that a more extended set of delegation possibilities (both of ambient and object capabilities) would be complementary to AppArmor, in that it would allow the convenience of defining the lower bound of priviledges to a delegation based scheme, while allowing at the same time a 'thin profile' for OC aware programs. Rob J Meijer - 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 patch] net/ipv4/ipvs/: remove unused exports
On Sun, Nov 11, 2007 at 07:48:40AM +0100, Adrian Bunk wrote:
> This patch removes the following unused EXPORT_SYMBOL's:
> - ip_vs_try_bind_dest
> - ip_vs_find_dest
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Looks fine to me.
Should Dave Miller put this in his tree,
or do you want to handle it a different way?
Acked-by: Simon Horman <[EMAIL PROTECTED]>
>
> ---
>
> net/ipv4/ipvs/ip_vs_conn.c |1 -
> net/ipv4/ipvs/ip_vs_ctl.c |1 -
> 2 files changed, 2 deletions(-)
>
> ad9f400d4f66ea3423f97e609d6ef2572055c603
> diff --git a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c
> index b7eeae6..0a9f3c3 100644
> --- a/net/ipv4/ipvs/ip_vs_conn.c
> +++ b/net/ipv4/ipvs/ip_vs_conn.c
> @@ -441,7 +441,6 @@ struct ip_vs_dest *ip_vs_try_bind_dest(struct ip_vs_conn
> *cp)
> } else
> return NULL;
> }
> -EXPORT_SYMBOL(ip_vs_try_bind_dest);
>
>
> /*
> diff --git a/net/ipv4/ipvs/ip_vs_ctl.c b/net/ipv4/ipvs/ip_vs_ctl.c
> index 3c4d22a..b64cf45 100644
> --- a/net/ipv4/ipvs/ip_vs_ctl.c
> +++ b/net/ipv4/ipvs/ip_vs_ctl.c
> @@ -604,7 +604,6 @@ struct ip_vs_dest *ip_vs_find_dest(__be32 daddr, __be16
> dport,
> ip_vs_service_put(svc);
> return dest;
> }
> -EXPORT_SYMBOL(ip_vs_find_dest);
>
> /*
> * Lookup dest by {svc,addr,port} in the destination trash.
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
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 patch] x86 pci-calgary_64.c: make a variable static
On Fri, Nov 09, 2007 at 07:03:30AM +0100, Adrian Bunk wrote: > "debugging" is a horrible name for a global variable - thankfully it can > become static. > > Also put it out of __read_mostly so that gcc no longer has to emit it > at all. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Thanks, applied. Will push with my next batch of Calgary updates. Cheers, Muli - 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] mm: unlockless reclaim
Combined with the previous and subsequent patches, throughput of pages through the pagecache on an Opteron system here goes up by anywhere from 50% to 500%, depending on the number of files and threads involved. -- unlock_page is fairly expensive. It can be avoided in page reclaim. Signed-off-by: Nick Piggin <[EMAIL PROTECTED]> --- Index: linux-2.6/mm/vmscan.c === --- linux-2.6.orig/mm/vmscan.c +++ linux-2.6/mm/vmscan.c @@ -589,7 +589,14 @@ static unsigned long shrink_page_list(st goto keep_locked; free_it: - unlock_page(page); + /* +* At this point, we have no other references and there is +* no way to pick any more up (removed from LRU, removed +* from pagecache). Can use non-atomic bitops now (and +* we obviously don't have to worry about waking up a process +* waiting on the page lock, because there are no references. +*/ + __clear_page_locked(page); nr_reclaimed++; if (!pagevec_add(&freed_pvec, page)) __pagevec_release_nonlru(&freed_pvec); - 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: Coding Style: indenting with tabs vs. spaces
On Nov. 10, 2007, 14:27 +0200, Xavier Bestel <[EMAIL PROTECTED]> wrote: > Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit : >> Hi Benny :) >> >> * Benny Halevy <[EMAIL PROTECTED]> dixit: >>> I would like to hear peoples opinion about the indentation convention >>> described below that I personally found the most practical with >>> several different editors. >> While I respect you opinion about tabs, I find tab indentation the most >> evil thing ever invented. Even if done right (that is, not indenting >> using a mixture of spaces and tabs), the only advantage is that you save >> a few bytes. > > Who cares ? > The only advantage is that people can make tabs as big (or as small) as > they wish. Tabs become "logical indentation". So one's indentation isn't > forced on anotherone's editor. Right. That's exactly the point. I find it harder to read someone else's code if (s)he uses 2 space indentation. With tabs, when done right, I can expand to my personal preference. > > Xav > > - 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/
drivers/net/ax88796.c compile error on sh64
Commit 8687991a734a67f1638782c968f46fff0f94bb1f causes the following compile error on sh64: <-- snip --> ... CC [M] drivers/net/ax88796.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c: In function 'ax_get_8390_hdr': /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:187: error: implicit declaration of function 'readsw' /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:189: error: implicit declaration of function 'readsb' /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c: In function 'ax_block_output': /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:275: error: implicit declaration of function 'writesw' /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:277: error: implicit declaration of function 'writesb' make[3]: *** [drivers/net/ax88796.o] Error 1 <-- snip --> 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 1/3] include files for kvmclock
Gerd Hoffmann wrote:
+/*
+ * Guest has page alignment and padding requirements. At the host, it will
+ * only lead to wasted space at the vcpu struct. For this reason, the struct
+ * is not anonymous
+ */
+union kvm_hv_clock {
+ struct kvm_hv_clock_s {
+ u64 tsc_mult;
+ u64 now_ns;
+ /* That's the wall clock, not the water closet */
+ u64 wc_sec;
+ u64 last_tsc;
+ /* At first, we could use the tsc value as a marker, but Jeremy
+* well noted that it will cause us locking problems in 32-bit
+* sys, so we have a special version field */
+ u32 version;
+ } fields;
+ char page_align[PAGE_SIZE];
+};
What is the point in using a whole page per vcpu? You probably don't
want struct kvm_hv_clock_s cross a page border. Is that the only reason
or are there other constrains too?
We don't even have the cross-page-boundary constraint.
The real issue is that on i386 physical addresses are 64-bit while
hypercall arguments are 32-bit. A page frame number is 32-bit and so
poses no issues.
I see two workarounds for this:
- make the first hypercall argument a u64 rather than a long (using two
registers on i386)
- use an msr for registering the clock address
The first is more general, while the second has the nice property of
taking care of live migration automatically.
As the kvm clock looks quite simliar to what xen does, how about making
the structs binary-compatible or simply reuse the xen version (struct
vcpu_time_info in xen/interface/xen.h)?
If there are no technical issues, I have no objections.
--
error compiling committee.c: too many arguments to function
-
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: Coding Style: indenting with tabs vs. spaces
DervishD wrote: Bonjour Xavier :) * Xavier Bestel <[EMAIL PROTECTED]> dixit: Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit : * Benny Halevy <[EMAIL PROTECTED]> dixit: I would like to hear peoples opinion about the indentation convention described below that I personally found the most practical with several different editors. While I respect you opinion about tabs, I find tab indentation the most evil thing ever invented. Even if done right (that is, not indenting using a mixture of spaces and tabs), the only advantage is that you save a few bytes. Who cares ? About the space saving? Not me, of course. It's just that I didn't see any other advantage. The only advantage is that people can make tabs as big (or as small) as they wish. Tabs become "logical indentation". So one's indentation isn't forced on anotherone's editor. The only way of having a sane indentation using tabs is to make sure that ALL indentation are tabs, not a mix of tabs and spaces (spaces, if any, should be at the end of indentation for aesthetical purposes, but should be removed without the logical indentation being lost). A good editor can ensure that all indentation are tabs and not a mix, but a good editor can adapt indentation to your likings when loading the file and save the file translating your favourite indentation back to spaces or whatever. If everybody used tabs correctly, indenting using tabs would be great, but IMHO indenting with spaces is much better. Raúl Núñez de Arenas Coronado Just use the linux ./scripts/checkpatch.pl --file It does all the indent checks for you before you submit a patch. I.e. I checks that one has not mixed tabs with spaces etc. So, any patches to the Linux kernel will have tabs used correctly. Where is the problem? James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drivers/net/ax88796.c compile error on sh64
On Sun, Nov 11, 2007 at 10:06:21AM +0100, Adrian Bunk wrote: > Commit 8687991a734a67f1638782c968f46fff0f94bb1f causes the following > compile error on sh64: > > <-- snip --> > > ... > CC [M] drivers/net/ax88796.o > /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c: In function > 'ax_get_8390_hdr': > /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:187: error: > implicit declaration of function 'readsw' > /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:189: error: > implicit declaration of function 'readsb' > /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c: In function > 'ax_block_output': > /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:275: error: > implicit declaration of function 'writesw' > /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:277: error: > implicit declaration of function 'writesb' > make[3]: *** [drivers/net/ax88796.o] Error 1 > > <-- snip --> > That's a pretty good argument for the PLAT_HAS_xxx stuff in the Kconfig space. We could have a if (CONFIG_SUPERH && !CONFIG_SUPERH64) thing here, but there's probably not much point. I'm planning on merging them in the 2.6.25 time period anyways, so adding a stop-gap solution to hide this driver's visibility doesn't really seem like a worthwhile endeavour. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] netx: remove bogus defconfig patch with wrong -p
So what's happening with this? Who's going to merge it? On Sat, Nov 10, 2007 at 02:41:54PM +0100, Robert Schwebel wrote: > Remove bogus commit f33bac8dd4573428b94c67149c5607be489092d1 which had > an incorrect path in the patch, leading to modify arm/... instead of > arch/arm/..., then re-add the right netx_defconfig file. > > Signed-off-by: Robert Schwebel <[EMAIL PROTECTED]> > --- > arch/arm/configs/netx_defconfig | 550 +++ > arm/configs/netx_defconfig | 925 > --- > 2 files changed, 266 insertions(+), 1209 deletions(-) > > diff --git a/arch/arm/configs/netx_defconfig b/arch/arm/configs/netx_defconfig > index 57f32f3..4ed31f8 100644 > --- a/arch/arm/configs/netx_defconfig > +++ b/arch/arm/configs/netx_defconfig > @@ -1,44 +1,64 @@ > # > # Automatically generated make config: don't edit > -# Linux kernel version: 2.6.17-rc6 > -# Tue Jun 6 15:26:53 2006 > +# Linux kernel version: 2.6.24-rc2 > +# Sat Nov 10 14:00:40 2007 > # > CONFIG_ARM=y > +CONFIG_SYS_SUPPORTS_APM_EMULATION=y > +# CONFIG_GENERIC_GPIO is not set > +# CONFIG_GENERIC_TIME is not set > +# CONFIG_GENERIC_CLOCKEVENTS is not set > CONFIG_MMU=y > +# CONFIG_NO_IOPORT is not set > +CONFIG_GENERIC_HARDIRQS=y > +CONFIG_STACKTRACE_SUPPORT=y > +CONFIG_LOCKDEP_SUPPORT=y > +CONFIG_TRACE_IRQFLAGS_SUPPORT=y > +CONFIG_HARDIRQS_SW_RESEND=y > +CONFIG_GENERIC_IRQ_PROBE=y > CONFIG_RWSEM_GENERIC_SPINLOCK=y > +# CONFIG_ARCH_HAS_ILOG2_U32 is not set > +# CONFIG_ARCH_HAS_ILOG2_U64 is not set > CONFIG_GENERIC_HWEIGHT=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > +CONFIG_ZONE_DMA=y > CONFIG_VECTORS_BASE=0x > +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > > # > -# Code maturity level options > +# General setup > # > CONFIG_EXPERIMENTAL=y > CONFIG_BROKEN_ON_SMP=y > CONFIG_LOCK_KERNEL=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > - > -# > -# General setup > -# > CONFIG_LOCALVERSION="" > CONFIG_LOCALVERSION_AUTO=y > CONFIG_SWAP=y > CONFIG_SYSVIPC=y > +CONFIG_SYSVIPC_SYSCTL=y > CONFIG_POSIX_MQUEUE=y > CONFIG_BSD_PROCESS_ACCT=y > # CONFIG_BSD_PROCESS_ACCT_V3 is not set > -CONFIG_SYSCTL=y > +# CONFIG_TASKSTATS is not set > +# CONFIG_USER_NS is not set > # CONFIG_AUDIT is not set > CONFIG_IKCONFIG=y > CONFIG_IKCONFIG_PROC=y > +CONFIG_LOG_BUF_SHIFT=17 > +# CONFIG_CGROUPS is not set > +CONFIG_FAIR_GROUP_SCHED=y > +CONFIG_FAIR_USER_SCHED=y > +# CONFIG_FAIR_CGROUP_SCHED is not set > +CONFIG_SYSFS_DEPRECATED=y > # CONFIG_RELAY is not set > -CONFIG_INITRAMFS_SOURCE="" > -CONFIG_UID16=y > +# CONFIG_BLK_DEV_INITRD is not set > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > +CONFIG_SYSCTL=y > # CONFIG_EMBEDDED is not set > +CONFIG_UID16=y > +CONFIG_SYSCTL_SYSCALL=y > CONFIG_KALLSYMS=y > -# CONFIG_KALLSYMS_ALL is not set > # CONFIG_KALLSYMS_EXTRA_PASS is not set > CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > @@ -46,28 +66,29 @@ CONFIG_BUG=y > CONFIG_ELF_CORE=y > CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > +CONFIG_ANON_INODES=y > CONFIG_EPOLL=y > +CONFIG_SIGNALFD=y > +CONFIG_EVENTFD=y > CONFIG_SHMEM=y > +CONFIG_VM_EVENT_COUNTERS=y > CONFIG_SLAB=y > +# CONFIG_SLUB is not set > +# CONFIG_SLOB is not set > +CONFIG_RT_MUTEXES=y > # CONFIG_TINY_SHMEM is not set > CONFIG_BASE_SMALL=0 > -# CONFIG_SLOB is not set > -CONFIG_OBSOLETE_INTERMODULE=y > - > -# > -# Loadable module support > -# > CONFIG_MODULES=y > CONFIG_MODULE_UNLOAD=y > CONFIG_MODULE_FORCE_UNLOAD=y > # CONFIG_MODVERSIONS is not set > # CONFIG_MODULE_SRCVERSION_ALL is not set > CONFIG_KMOD=y > - > -# > -# Block layer > -# > +CONFIG_BLOCK=y > +# CONFIG_LBD is not set > # CONFIG_BLK_DEV_IO_TRACE is not set > +# CONFIG_LSF is not set > +# CONFIG_BLK_DEV_BSG is not set > > # > # IO Schedulers > @@ -85,32 +106,47 @@ CONFIG_DEFAULT_IOSCHED="anticipatory" > # > # System Type > # > +# CONFIG_ARCH_AAEC2000 is not set > +# CONFIG_ARCH_INTEGRATOR is not set > +# CONFIG_ARCH_REALVIEW is not set > +# CONFIG_ARCH_VERSATILE is not set > +# CONFIG_ARCH_AT91 is not set > # CONFIG_ARCH_CLPS7500 is not set > # CONFIG_ARCH_CLPS711X is not set > # CONFIG_ARCH_CO285 is not set > # CONFIG_ARCH_EBSA110 is not set > # CONFIG_ARCH_EP93XX is not set > # CONFIG_ARCH_FOOTBRIDGE is not set > -# CONFIG_ARCH_INTEGRATOR is not set > -# CONFIG_ARCH_IOP3XX is not set > -# CONFIG_ARCH_IXP4XX is not set > -# CONFIG_ARCH_IXP2000 is not set > +CONFIG_ARCH_NETX=y > +# CONFIG_ARCH_H720X is not set > +# CONFIG_ARCH_IMX is not set > +# CONFIG_ARCH_IOP13XX is not set > +# CONFIG_ARCH_IOP32X is not set > +# CONFIG_ARCH_IOP33X is not set > # CONFIG_ARCH_IXP23XX is not set > +# CONFIG_ARCH_IXP2000 is not set > +# CONFIG_ARCH_IXP4XX is not set > # CONFIG_ARCH_L7200 is not set > +# CONFIG_ARCH_KS8695 is not set > +# CONFIG_ARCH_NS9XXX is not set > +# CONFIG_ARCH_MXC is not set > +# CONFIG_ARCH_PNX4008 is not set > # CONFIG_ARCH_PXA is not set > # CONFIG_ARCH_RPC is not set > # CONFIG_ARCH_SA1100 is not set > # CONFIG_ARCH_S3C2410 is not set > # CONFIG_ARCH_SHARK is
Bind mount bug?
I'm not sure whether this is a bug or expected behavior. Suppose I create a "looped" bind mount situation as follows. # mkdir test # touch test/foo # mkdir bindtest # touch bindtest/bar # mkdir bindtest/test # mount --bind test/ bindtest/test/ # ls bindtest/test/ foo # mount --bind bindtest/ test/ # ls test/ bar test # ls test/test/ # I'd expected the last command to list "foo", but it shows an empty dir. Shouldn't it also show the original contents of test (as they were before the first bind mount)? # mount | grep test /root/test on /root/bindtest/test type none (rw,bind) /root/bindtest on /root/test type none (rw,bind) Cheers, Frans Pop - 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/3] kvmclock - the host part.
Glauber de Oliveira Costa wrote: This is the host part of kvm clocksource implementation. As it does not include clockevents, it is a fairly simple implementation. We only have to register a per-vcpu area, and start writting to it periodically. Missing live migration support (a way for userspace to read and write the guest clock address). Should probably be in a separate patch. @@ -1924,6 +1955,7 @@ out: goto preempted; } + kvm_write_guest_time(vcpu); post_kvm_run_save(vcpu, kvm_run); Why here? Seems like we're leaving the guest for a while at this place. Suggest putting it on top of __vcpu_run(), guarded by a flag, and setting the flag every time we put the vcpu. -- error compiling committee.c: too many arguments to function - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bind mount bug?
On Sunday 11 November 2007, Frans Pop wrote: > I'd expected the last command to list "foo", but it shows an empty dir. > Shouldn't it also show the original contents of test (as they were before > the first bind mount)? The problem is of course also that any changes made into /test/test will get lost into thin space: # touch test/test/baz # ls bindtest/test foo # umount test # ls test foo # - 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/6] Suppress A.OUT library support if !CONFIG_BINFMT_AOUT [try #5]
On Fri, Nov 09, 2007 at 03:34:37PM +, David Howells wrote:
> Suppress A.OUT library support if CONFIG_BINFMT_AOUT is not set.
>
> Not all architectures support the A.OUT binfmt, so the ELF binfmt should not
> be permitted to go looking for A.OUT libraries to load in such a case. Not
> only that, but under such conditions A.OUT core dumps are not produced either.
>
> To make this work, this patch also does the following:
>
> (1) Makes the existence of the contents of linux/a.out.h more or less
> contingent on one of:
>
> CONFIG_BINFMT_AOUT=[ym]
> CONFIG_IA32_AOUT=[ym]
> CONFIG_BINFMT_AOUT32=[ym]
>
> (2) Moves STACK_TOP[_MAX] out of asm/a.out.h and into asm/processor.h as
> they're required whether or not A.OUT format is available.
>
> (3) Renames dump_thread() to aout_dump_thread() as it's only called by A.OUT
> core dumping code.
>
> (4) Moves aout_dump_thread() into asm/a.out-core.h and makes it inline. This
> is then included only where needed. This means that this bit of arch
> code will be stored in the appropriate A.OUT binfmt module rather than
> the core kernel.
>
> (5) Removes a lot of now obsolete {linux,asm}/a.out.h inclusions.
>
> (6) Drops A.OUT support for Blackfin (according to Mike Frysinger it's not
> needed).
>...
I do not like this patch for the following reasons:
- too many cleanups lumped into one patch
- it adds #ifdef's in fs/binfmt_elf.c for code that is anyway
scheduled for removal in 2.6.25
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/
[2.6 patch] libata: remove unused functions
This patch removes the following obsolete functions:
- libata-core.c: __sata_phy_reset()
- libata-core.c: sata_phy_reset()
- libata-eh.c: ata_qc_timeout()
- libata-eh.c: ata_eng_timeout()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 78 ---
drivers/ata/libata-eh.c | 95 --
include/linux/libata.h|4 -
3 files changed, 177 deletions(-)
7e9868b7e921f3235d044c78f28da8797cc63e5a
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 8189803..1584164 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -2581,81 +2581,6 @@ void sata_print_link_status(struct ata_link *link)
}
/**
- * __sata_phy_reset - Wake/reset a low-level SATA PHY
- * @ap: SATA port associated with target SATA PHY.
- *
- * This function issues commands to standard SATA Sxxx
- * PHY registers, to wake up the phy (and device), and
- * clear any reset condition.
- *
- * LOCKING:
- * PCI/etc. bus probe sem.
- *
- */
-void __sata_phy_reset(struct ata_port *ap)
-{
- struct ata_link *link = &ap->link;
- unsigned long timeout = jiffies + (HZ * 5);
- u32 sstatus;
-
- if (ap->flags & ATA_FLAG_SATA_RESET) {
- /* issue phy wake/reset */
- sata_scr_write_flush(link, SCR_CONTROL, 0x301);
- /* Couldn't find anything in SATA I/II specs, but
-* AHCI-1.1 10.4.2 says at least 1 ms. */
- mdelay(1);
- }
- /* phy wake/clear reset */
- sata_scr_write_flush(link, SCR_CONTROL, 0x300);
-
- /* wait for phy to become ready, if necessary */
- do {
- msleep(200);
- sata_scr_read(link, SCR_STATUS, &sstatus);
- if ((sstatus & 0xf) != 1)
- break;
- } while (time_before(jiffies, timeout));
-
- /* print link status */
- sata_print_link_status(link);
-
- /* TODO: phy layer with polling, timeouts, etc. */
- if (!ata_link_offline(link))
- ata_port_probe(ap);
- else
- ata_port_disable(ap);
-
- if (ap->flags & ATA_FLAG_DISABLED)
- return;
-
- if (ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT)) {
- ata_port_disable(ap);
- return;
- }
-
- ap->cbl = ATA_CBL_SATA;
-}
-
-/**
- * sata_phy_reset - Reset SATA bus.
- * @ap: SATA port associated with target SATA PHY.
- *
- * This function resets the SATA bus, and then probes
- * the bus for devices.
- *
- * LOCKING:
- * PCI/etc. bus probe sem.
- *
- */
-void sata_phy_reset(struct ata_port *ap)
-{
- __sata_phy_reset(ap);
- if (ap->flags & ATA_FLAG_DISABLED)
- return;
- ata_bus_reset(ap);
-}
-
-/**
* ata_dev_pair- return other device on cable
* @adev: device
*
@@ -7653,8 +7578,6 @@ EXPORT_SYMBOL_GPL(ata_dev_disable);
EXPORT_SYMBOL_GPL(sata_set_spd);
EXPORT_SYMBOL_GPL(sata_link_debounce);
EXPORT_SYMBOL_GPL(sata_link_resume);
-EXPORT_SYMBOL_GPL(sata_phy_reset);
-EXPORT_SYMBOL_GPL(__sata_phy_reset);
EXPORT_SYMBOL_GPL(ata_bus_reset);
EXPORT_SYMBOL_GPL(ata_std_prereset);
EXPORT_SYMBOL_GPL(ata_std_softreset);
@@ -7725,7 +7648,6 @@ EXPORT_SYMBOL_GPL(ata_port_desc);
#ifdef CONFIG_PCI
EXPORT_SYMBOL_GPL(ata_port_pbar_desc);
#endif /* CONFIG_PCI */
-EXPORT_SYMBOL_GPL(ata_eng_timeout);
EXPORT_SYMBOL_GPL(ata_port_schedule_eh);
EXPORT_SYMBOL_GPL(ata_link_abort);
EXPORT_SYMBOL_GPL(ata_port_abort);
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index ed8813b..0dac69d 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -559,101 +559,6 @@ void ata_port_wait_eh(struct ata_port *ap)
}
}
-/**
- * ata_qc_timeout - Handle timeout of queued command
- * @qc: Command that timed out
- *
- * Some part of the kernel (currently, only the SCSI layer)
- * has noticed that the active command on port @ap has not
- * completed after a specified length of time. Handle this
- * condition by disabling DMA (if necessary) and completing
- * transactions, with error if necessary.
- *
- * This also handles the case of the "lost interrupt", where
- * for some reason (possibly hardware bug, possibly driver bug)
- * an interrupt was not delivered to the driver, even though the
- * transaction completed successfully.
- *
- * TODO: kill this function once old EH is gone.
- *
- * LOCKING:
- * Inherited from SCSI layer (none, can sleep)
- */
-static void ata_qc_timeout(struct ata_queued_cmd *qc)
-{
- struct ata_port *ap = qc->ap;
- u8 host_stat = 0, drv_stat;
- unsigned long flags;
-
- DPRINTK("ENTER\n");
-
- ap->hsm_task_state = HSM_ST_IDLE;
-
- spin_lock_irqsave(ap->lock, flags);
-
- switch (qc->tf.protocol) {
-
- case ATA_PROT_DMA:
-
Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86
On Sun, Nov 11, 2007 at 06:09:45AM +0100, Adrian Bunk wrote:
> On Sat, Nov 10, 2007 at 09:40:38PM +0100, Sam Ravnborg wrote:
>
> > As discussed in another thread the right thing is to add a generic solution
> > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
> >...
>
> I seriously question this would be "the right thing".
>
> 32/64bit isn't that special that this and only this option would require
> special casing, and the KISS principle of having only one way to specify
> something like this has it's advantages.
"The right thing" in the correct context.
It was discussed to keep ARCH={i386,x86_64} and the point I have
is that if we are going to extend ARCH=... to be useable to
specify kernel bit size then it should be done in a generic way
and not like it was done before on x86.
I do not consider the discussion about keeping/dropping
ARCH={i386,x86_64} as concluded.
And if we decide on keeping ARCH={i386,x86_64} then I have
questioned the semantics. Clear opinions are missing..
ARCH= semantic
Impact before now
32/64 bit yes yes
bzImage location yes no
different Kconfig files yes no
decide defconfig yes yes
asm symlink nono
build option yes no [1]
[did I miss anything? I think I did]
[1] ARCH=... select 32/64-bit during configuration.
There is no difference between ARCH={x86,i386,x86_64}
when building the kernel because the 32/64 bit
choice is done at configuration time.
The table above reflect the [now] semantics with the
patches that is present at lkml.
And the patch needed to implment the above
semantic (after the preparational stuff which
is generic) are:
$ git diff --stat HEAD~1..HEAD
Makefile | 18 ++
arch/x86/Makefile|8 ++--
scripts/kconfig/Makefile |2 +-
3 files changed, 21 insertions(+), 7 deletions(-)
The scripts/kconfig/Makefile change is a bugfix that maybe
should be included in another patch. It is not x86 specific.
So 19 additional lines and 5 deleted lines to introduce the
ARCH= semantics above.
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.6.24-rc1-g74521c28: oops during boot [] :power_supply:power_supply_show_property+0x94/0x150
Thomas Bächler schrieb: > Rafael J. Wysocki schrieb: >> On Saturday, 3 November 2007 12:31, Thomas Bächler wrote: >>> I am trying to boot 2.6.24-rc1-g74521c28 from the linux-2.6 git tree. >>> During boot, I get a kernel oops when udevtrigger is running, thus most >>> devices are not created and the boot stalls. >>> >>> Fortunately, the services are still started (though I don't see anything >>> due to missing ttys) and syslog caught the oops. The logfile and config >>> are attached. >> Can you please attach these files to the bugzilla entry at: >> >> http://bugzilla.kernel.org/show_bug.cgi?id=9299 > > Done. I just tested again (with 2.6.24-rc2-gecd744ee). If I only load the 'ac' kernel module and not the 'battery' kernel module, then the system boots fine. However, if I load the 'battery' module during boot or later, I still get the oops. I am running 2.6.24-rc2-gecd744ee right now, but without the battery module. I am forwarding this to the ACPI list as well. signature.asc Description: OpenPGP digital signature
[PATCH] fs/hfs: remove duplicated defines
Remove duplicated defines. Signed-off-by: Nicolas Kaiser <[EMAIL PROTECTED]> --- fs/hfs/btree.h |5 - 1 file changed, 5 deletions(-) --- a/fs/hfs/btree.h2007-10-09 22:31:38.0 +0200 +++ b/fs/hfs/btree.h2007-11-11 12:42:59.0 +0100 @@ -153,11 +153,6 @@ u32 reserved3[16]; } __packed; -#define HFS_NODE_INDEX 0x00/* An internal (index) node */ -#define HFS_NODE_HEADER0x01/* The tree header node (node 0) */ -#define HFS_NODE_MAP 0x02/* Holds part of the bitmap of used nodes */ -#define HFS_NODE_LEAF 0xFF/* A leaf (ndNHeight==1) node */ - #define BTREE_ATTR_BADCLOSE0x0001 /* b-tree not closed properly. not used by hfsplus. */ #define HFS_TREE_BIGKEYS 0x0002 /* key length is u16 instead of u8. - 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] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi Adrian, On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > What exactly are the use cases where someone would need this? Glad you asked. Today, when I want to recompile a kernel while changing a CONFIG_ option, I manually edit the .config, remove the appropriate line and then run make oldconfig. I'd like to be able to do: make oldconfig CONFIG_FOO=bar. Also, when working on a specific feature of the kernel, I tend to install both a kernel with the CONFIG_ option set and one with the option unset. Scripts to do that can twiddle the .config file, but it would be more convenient if kbuild could avoid that. As you see, I'm more interested in make oldconfig than make all*config. Cheers. -- Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser(2)
Hi! > > A Smack Rule in an "egrep" format is: > > > > "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n" Perhaps you should make it space, not 'space or tab', and only allow lowercase permissions? That way, parser will be slightly simpler, and you'll still have a chance to use 'R' as 'slightly different r'. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sun, Nov 11, 2007 at 01:43:28PM +0100, Guillaume Chazarain wrote: > Hi Adrian, Hi Guillaume, > On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > What exactly are the use cases where someone would need this? > > Glad you asked. Today, when I want to recompile a kernel while > changing a CONFIG_ option, I manually edit the .config, > remove the appropriate line and then run make oldconfig. > I'd like to be able to do: make oldconfig CONFIG_FOO=bar. first of all it's obvious that there can't be any guarantee that your CONFIG_FOO variable will actually get the value bar since dependencies might enable or disable it despite you wanting the opposite. Another important point is that users that know about and see CONFIG_* variables are kernel hackers, not the normal kconfig users. > Also, when working on a specific feature of the kernel, I tend to > install both a kernel with the CONFIG_ option set and one with > the option unset. Scripts to do that can twiddle the .config file, > but it would be more convenient if kbuild could avoid that. I'm wondering why you don't use two different O= output directories instead? Depending on the CONFIG_ option in question this might even greatly reduce your compile times. And you won't upgrade the kernel you work against that often compared to working on and testing of your own changes when developing code. > As you see, I'm more interested in make oldconfig than > make all*config. That's clear. > Cheers. > Guillaume 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: pdflush stuck in D state with v2.6.24-rc1-192-gef49c32
Florin Iucha iucha.net> writes: > > It's really curious - I tried your .config and commands, and still > > could not trigger the high iowait. I'm running 64bit Intel Core 2, > > and kernel 2.6.24-rc1-git6 with the above patch. > > Curious but 100% reproducible, at least on my box. What I'm going to > try is booting into the kernel with your patch and just doing the find > / md5sum. It would be really interesting if the read-only access > triggers it. > > florin > I can confirm this issue too on any .24-rc. I'm also using reiserfs on a LVM. And there is one more user on Gentoo forums having the same issue. http://forums.gentoo.org/viewtopic-t-612959.html So you are not alone, florian. - 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/
DaveM collecting netdev patches this week
I'm about to disappear (virtually) through Friday for vacation. David Miller has agreed to collect net driver bug fix patches in my absence, with Stephen and Francois (and others, hopefully) helping out with patch review. David -- note that my 2.6.25 was opened a little while ago. If you feel motivated enough to collect non-bugfix patches, please make sure to apply them on top of netdev-2.6.git#upstream. There is already quite a collection of stuff for 2.6.25 queued... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Tejun collecting libata patches this week
I'm about to disappear (virtually) through Friday for vacation. Tejun Heo has agreed to collect libata bug fix patches in my absence. Thanks! Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] Suppress A.OUT library support if !CONFIG_BINFMT_AOUT [try #5]
Adrian Bunk <[EMAIL PROTECTED]> wrote: > - too many cleanups lumped into one patch Perhaps, but unfortunately a lot of them are related and required for a compilable patch. I can probably split it up 4 ways if you really want me to, in order: (1) Move STACK_TOP[_MAX]. (2) Rename dump_thread() -> aout_dump_thread(). (3) Everything else. (4) Remove obsolete a.out.h inclusions. I don't think it's really worth splitting (2) from (3) though. > - it adds #ifdef's in fs/binfmt_elf.c for code that is anyway > scheduled for removal in 2.6.25 Yes, but that patch isn't there now, and won't be there in the next version - assuming this arch has a hope of getting in on that one - according to your statement. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] MN10300: Add MTD flash support for the ASB2303 board [try #5]
David Woodhouse <[EMAIL PROTECTED]> wrote: > Dunno why it's called "try #5" when I haven't directly received it even > once yet. As far as LKML is concerned, it's part of patchset try #5. > We're trying to avoid taking new simple map drivers -- you should be > able to use a platform device instead. Example? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] Use one zonelist that is filtered by nodemask
On (09/11/07 09:26), Christoph Lameter didst pronounce: > On Fri, 9 Nov 2007, Lee Schermerhorn wrote: > > > > On the other hand, if we call alloc_pages() with GFP_THISNODE set, there > > > is no nid to base the allocation on, so we "fallback" to numa_node_id() > > > [ almost like the nid had been specified as -1 ]. > > > > > > So I guess this is logical -- but I wonder, do we have any callers of > > > alloc_pages(GFP_THISNODE) ? It seems like an odd thing to do, when > > > alloc_pages_node() exists? > > > > I don't know if we have any current callers that do this, but absent any > > documentation specifying otherwise, Mel's implementation matches what > > I'd expect the behavior to be if I DID call alloc_pages with 'THISNODE. > > However, we could specify that THISNODE is ignored in __alloc_pages() > > and recommend the use of alloc_pages_node() passing numa_node_id() as > > the nid parameter to achieve the behavior. This would eliminate the > > check for 'THISNODE in __alloc_pages(). Just mask it off before calling > > down to __alloc_pages_internal(). > > > > Does this make sense? > > I like consistency. If someone absolutely wants a local page then > specifying GFP_THISNODE to __alloc_pages is okay. Leave as is I guess. > Agreed. > What happens though if an MPOL_BIND policy is in effect? The node used > must then be the nearest node from the policy mask > If MPOL_BIND is in effect, the allocation will be filtered based on the current allowed nodemask. If they specify THISNODE and the specified node or current node is not in the mask, I would expect the allocation to fail. Is that unexpected to anybody? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/capability.c get_task_comm compile error (MMOTM)
* Erez Zadok <[EMAIL PROTECTED]> wrote: > Small patch below fixes compile error. > + char name[sizeof(current->comm)]; > warned++; > printk(KERN_INFO > "warning: process `%s' sets w/ old libcap\n", > -get_task_comm(current)); > +get_task_comm(name, current)); that's buggy - get_task_comm() returns void. the proper fix would be to first do a get_task_comm() then pass in 'name' as an argument to printk. Ingo - 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/6] Suppress A.OUT library support if !CONFIG_BINFMT_AOUT [try #5]
On Sun, Nov 11, 2007 at 01:59:29PM +, David Howells wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > - too many cleanups lumped into one patch > > Perhaps, but unfortunately a lot of them are related and required for a > compilable patch. I can probably split it up 4 ways if you really want me > to, in order: > > (1) Move STACK_TOP[_MAX]. > > (2) Rename dump_thread() -> aout_dump_thread(). It's BTW not an improvement that you do not only rename them but change such big functions to static inline functions in header files. > (3) Everything else. > > (4) Remove obsolete a.out.h inclusions. > > I don't think it's really worth splitting (2) from (3) though. Something like this. > > - it adds #ifdef's in fs/binfmt_elf.c for code that is anyway > > scheduled for removal in 2.6.25 > > Yes, but that patch isn't there now, and won't be there in the next version - > assuming this arch has a hope of getting in on that one - according to your > statement. I'm not the one to decide, but the only excuse for getting that late into 2.6.24 would be "it can't cause any regression". The arch/mn10300/ and include/asm-mn10300/ additions can't cause regressions, and for all the drivers/ parts it seems to be easily verifiable that they can't cause regressions. But changes to binfmt_elf.c after the merge window that might introduce regressions (e.g. you (ab)use CONFIG_BINFMT_AOUT where you might have to introduce an CONFIG_ARCH_SUPPORTS_AOUT instead) decrease your chances of being merged that late. But you might be able to do something like a cp include/asm-xtensa/a.out.h include/asm-mn10300/ instead. > David 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] Add quirk to set AHCI mode on ICH boards
On 10.11.2007 00:32, Matthias Schniedermeyer wrote: > [...] > My computer/mainboard @work has such a "broken" BIOS. Of the 5 > SATA-Ports this MB has only 1 (and 1 "missing" that is reported by > linux but i can't find on the MB) is configured as AHCI [...] There is nothing "broken" here. You have a ICH8 (without R) that drives four SATA ports, which are handled by ata_piix. Then you have a Jmicron JMB363 -- it handles the PATA-Channel and two SATA-Ports -- one internal (near the battery)/next to the PCI-Slot and a external eSATA port. Seems you configured it in AHCI-Mode in the BIOS-Setup. Linux will work just fine if you connect the hard disc to that port. But if you want to install Windows XP you need a driver from Jmicron. There were BIOSes for the P5B where you could enabled AHCI for the ICH8 as well. It seems Asus removed it in the later BIOS-versions again as Intel doesn't provide a Windows-AHCI driver for the basic ICH8. HTH and clarifies some of your problems. Cu knurd -- Thorsten Leemhuis c't- Magazin für Computertechnik webhttp://www.heise.de/ct/ Heise Zeitschriften Verlag GmbH&Co.KG phone +49 (0)511 5352 666 Helstorfer Str. 7 icq140593172 D-30625 Hannover, Germany jabber [EMAIL PROTECTED] /* Heise Zeitschriften Verlag GmbH & Co. KG, Registergericht: Amtsgericht Hannover HRA 26709; Persönlich haftende Gesellschafterin: Heise Zeitschriften Verlag Geschäftsführung GmbH, Registergericht: Amtsgericht Hannover, HRB 60405 Geschäftsführer: Ansgar Heise, Steven P. Steinkraus, Dr. Alfons Schräder */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Andrew Morton <[EMAIL PROTECTED]> wrote: > If it is indeed the case that this architecture is used internally by a > single organisation then perhaps it doesn't make sense for us to merge it. I don't know that this is so. I can ask them, but I don't know if they'll tell me that. Furthermore, it's better to have the code upstream[*]. That way the person wanting to make a sweeping change across all arches who knows how the change should be made can have a go at making the change, rather than someone who's constantly playing catchup and may not understand fully. [*] As people keep saying. Constantly playing catchup really isn't fun, as I'm sure you appreciate with maintaining the -mm tree. You, after all, do it on a much larger scale than everyone else. > I guess if it were possible to install a self-built kernel into a Panasonic > gadget then we could look at it on that basis. Do you know if that's the > case? I don't, no. Besides, I *do* have Panasonic devices I can install random software and hardware on to:-) But it's not COTS stuff. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] improved hacks to allow -rt to run kernbench on POWER
On Sun, 11 Nov 2007, Benjamin Herrenschmidt wrote: > > > Removed this as well, also seemed to work. Please note, however, that > > this is just running kernbench. But this did seem to get rid of some > > of the warnings as well. ;-) Now only have the xics_startup() warning. > > > > > Overall, looks fine ! > > > > I bet that there are more gotchas lurking in there somewhere, but in > > the meantime here is the updated patch. > > > > Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]> > > --- > > Well, I suppose the patch could go in, maybe with some ifdef's around > the bits in _switch_to, there's little point in doing that on non-rt > kernels. As Nick Piggin already stated, and I'll even state it for the RT kernel, we do not allow preemption in switch_to. So it is safe to remove those "preempt_disable" bits from the patch. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Alan Cox <[EMAIL PROTECTED]> wrote: > memory mapped registers should be read with readw and friends and that > should contain the volatile not the public code. So you would say change the global h/w register variables[*] to be addresses instead, and change all the references to be readX and writeX? I'm wary of doing that in case some special logic needs to be inserted in there to handle funny buses differently. I used to have code like that in there, though there's none at the moment. On the other hand, since the CPU addresses are for the most part constants, I can probably do something clever with __builtin_const_p() if it comes to that. [*] This includes auxiliary CPU control registers, though I suppose that doesn't make any difference. > Similarly spin_lock/unlock are store barriers so for ring buffers should > be sufficient unless you have cache management requirements in which case > the dma_* APIs will handle those bits. I don't actually need locks, but sticking smp_rmb()/smp_wmb() is probably the right thing to do now that I know how to use them. This code was written five or six years ago and I haven't really thought about changing that since. I don't see how the dma_* APIs would help. The buffer is filled by a higher priority interrupt routine that does 'virtual DMA'. It's not actually done by real DMA. Normal interrupt disablement doesn't really disable interrupts, it justs excludes normal priority interrupts. The virtual DMA is done is ASM as it has to be really quick. It's unfortunate, but, the on-chip serial ports don't have a FIFO. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > Another important point is that users that know about and see CONFIG_* > variables are kernel hackers, not the normal kconfig users. But kconfig is mainly for kernel hackers, otherwise it would be called CML2 ;-) > > Also, when working on a specific feature of the kernel, I tend to > > install both a kernel with the CONFIG_ option set and one with > > the option unset. Scripts to do that can twiddle the .config file, > > but it would be more convenient if kbuild could avoid that. > > I'm wondering why you don't use two different O= output directories > instead? > > Depending on the CONFIG_ option in question this might even greatly > reduce your compile times. /me is filled with wonder at the discovery that .config is saved in the O= directory. Thanks a lot Adrian for this time saver. So it's not strictly an output directory, more a build directory. I still think "make oldconfig CONFIG_FOO=bar" is useful for the occasional config change, but thanks again for this great tip. -- Guillaume - 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/6] Suppress A.OUT library support if !CONFIG_BINFMT_AOUT [try #5]
Adrian Bunk <[EMAIL PROTECTED]> wrote: > It's BTW not an improvement that you do not only rename them but change > such big functions to static inline functions in header files. I'm not sure what you meant by that. Renaming them indicates more clearly that their only purpose is for A.OUT support. Making them inline is an improvement because it compiles the code into the binfmt_aout module rather than the core kernel, and gives the compiler optimiser a chance to reduce the size of the overall code. And the functions aren't actually all that big or complex. They're about shovelling data and don't do anything clever. Actually, I could probably do another patch split to inline these functions first before doing AOUT suppression. > Something like this. Was that an agreement with my suggested break up, or was there something more meant to be there? > But changes to binfmt_elf.c after the merge window that might introduce > regressions (e.g. you (ab)use CONFIG_BINFMT_AOUT where you might have to > introduce an CONFIG_ARCH_SUPPORTS_AOUT instead) decrease your chances of > being merged that late. That was more or less what I wanted to do originally, but I was told to use CONFIG_BINFMT_AOUT instead - which actually proves to have two variants:-( Perhaps I could start with the patch that you mentioned to remove AOUT interpreter support from binfmt_elf. Can you point me at it or send it to me? That's still not sufficient, but it removes part of the changes I have to make. > But you might be able to do something like a > cp include/asm-xtensa/a.out.h include/asm-mn10300/ > instead. No. That would be wrong. MN10300 does not define an exec struct, and nor should it provide an asm/a.out.h header. It does not do AOUT format. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Alan Cox <[EMAIL PROTECTED]> wrote: > memory mapped registers should be read with readw and friends and that > should contain the volatile not the public code. Actually, I can think of a good reason for *not* doing that. What I have at the moment encodes the size of the register to be accessed in the type. What you're suggesting does not. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/video/s1d13xxxfb.c as module with dbg
On Nov 11, 2007 12:29 AM, dave chung <[EMAIL PROTECTED]> wrote: > we also need to look at splitting out the "chip revision", which is > currently hard set, as I have had very good results with this driver > and chip S1D13506, which is functionally similar but without the > external clocking and without teh internal ram. Well I wrote the initial driver mostly as a rather quick hack. I didn't have access to other hw from the s1d13 family (other than the 806) at that time, and could only guess that supporting them shouldn't be too complicated. Nowadays I don't even have access to the 806 itself anymore, so I'm afraid I won't be of much help. HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
> So you would say change the global h/w register variables[*] to be addresses > instead, and change all the references to be readX and writeX? I'm wary of Ok so these are not addresses but magic registers in the processor ? Then I guess volatile makes complete sense. > > Similarly spin_lock/unlock are store barriers so for ring buffers should > > be sufficient unless you have cache management requirements in which case > > the dma_* APIs will handle those bits. > > I don't actually need locks, but sticking smp_rmb()/smp_wmb() is probably the > right thing to do now that I know how to use them. This code was written five > or six years ago and I haven't really thought about changing that since. > > I don't see how the dma_* APIs would help. The buffer is filled by a higher > priority interrupt routine that does 'virtual DMA'. It's not actually done by > real DMA. Normal interrupt disablement doesn't really disable interrupts, it > justs excludes normal priority interrupts. For real DMA the dma_ APIs keep coherency > The virtual DMA is done is ASM as it has to be really quick. It's > unfortunate, > but, the on-chip serial ports don't have a FIFO. For PIO (virtual DMA or otherwise) the locking does that. Because spin_unlock and spin_lock are compiler barriers the need to use volatile shouldn't normally be there. If you are doing it via asm without locks then I would expect atomic_t because the sematics of volatile are horribly vague on their own ? - 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/6] Suppress A.OUT library support if !CONFIG_BINFMT_AOUT [try #5]
On Sun, Nov 11, 2007 at 03:03:56PM +, David Howells wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > It's BTW not an improvement that you do not only rename them but change > > such big functions to static inline functions in header files. > > I'm not sure what you meant by that. > > Renaming them indicates more clearly that their only purpose is for A.OUT > support. > > Making them inline is an improvement because it compiles the code into the > binfmt_aout module rather than the core kernel, and gives the compiler > optimiser a chance to reduce the size of the overall code. > > And the functions aren't actually all that big or complex. They're about > shovelling data and don't do anything clever. >... My thoughts go more into the direction that we have hundreds of similar cases where e.g. a VFS function might currently only by used by OCFS2 and therefore be dead code for most users, and the only maintainable solution will be to solve these at the compiler and/or linker level. > > Something like this. > > Was that an agreement with my suggested break up, or was there something more > meant to be there? That was an agreement. > > But changes to binfmt_elf.c after the merge window that might introduce > > regressions (e.g. you (ab)use CONFIG_BINFMT_AOUT where you might have to > > introduce an CONFIG_ARCH_SUPPORTS_AOUT instead) decrease your chances of > > being merged that late. > > That was more or less what I wanted to do originally, but I was told to use > CONFIG_BINFMT_AOUT instead - which actually proves to have two variants:-( > > Perhaps I could start with the patch that you mentioned to remove AOUT > interpreter support from binfmt_elf. Can you point me at it or send it to me? > That's still not sufficient, but it removes part of the changes I have to > make. Andi scheduled it for removal, and I don't know whether he already has a patch. > > But you might be able to do something like a > > cp include/asm-xtensa/a.out.h include/asm-mn10300/ > > instead. > > No. That would be wrong. MN10300 does not define an exec struct, and nor > should it provide an asm/a.out.h header. It does not do AOUT format. Read the comment at the top of the xtensa header. ;-) For 2.6.25 a better solution is appreciated, but for 2.6.24 such a small dirty workaround that can't cause breakages on other architectures would be better. > David 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/
PCI card initialisation at boot
Hi I am looking for someone to help explain my findings, which I have searched the net but could not find any related infomation. We have 40 linux PCs deployed in a mobile environment, so they are subjected to pretty harsh conditions that can cause BIOS corruptions. In one of the units, I noticed the kernel had difficulty initialising the PCI card, with messages stating that the PCI resource/address is invalid (I am very sorry that I did not manage to capture the exact output). It continues to boot to userspace, but the machine hangs when the user app tries to access the pci card. Rebooting the PC several times gave the same message, so at least the problem was consistent. Removing the PCI card from the slot, and putting a spare card, solved the problem. Then, putting the first card back worked again. I am guessing that the ESCD has been corrupted, and putting a spare device caused the BIOS to reset the ESCD. In the BIOS, it has been setup as "Resource allocation by Auto(ESCD)". There is another option in the BIOS to set "Resource allocation by Manual". I have tried this setting and Linux has no problems booting up and using the PCI card. My question is: Will setting the BIOS to "Resource allocation by Manual" prevent the crash from happening in the future? More specifically, does Linux still depend on ESCD even if the resource allocation is set to Manual? Regards Keith - 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] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sun, Nov 11, 2007 at 03:59:54PM +0100, Guillaume Chazarain wrote: > > I'm wondering why you don't use two different O= output directories > > instead? > > > > Depending on the CONFIG_ option in question this might even greatly > > reduce your compile times. > > /me is filled with wonder at the discovery that .config is saved in the O= > directory. Thanks a lot Adrian for this time saver. So it's not strictly an > output directory, more a build directory. The opposite All output is placed there - including the configuration generated by the *config frontends. It is not limited to kernel-build output. One of the use cases for "make O=.." is a setup where the kernel source is located in a RO location (CDROM, restricted permissions etc). 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: [PATCH 1/6] Suppress A.OUT library support if !CONFIG_BINFMT_AOUT [try #5]
> My thoughts go more into the direction that we have hundreds of similar > cases where e.g. a VFS function might currently only by used by OCFS2 > and therefore be dead code for most users, and the only maintainable > solution will be to solve these at the compiler and/or linker level. -ffunction-sections can mostly do it, but only for non modular kernels One problem is that EXPORT_SYMBOL always creates a reference to the function even when nothing uses it. We would need a weak EXPORT_SYMBOL and some way to check references over main kernel and modules. I suppose it could be done as part of modpost and then generating a custom linker script that only includes the function sections referenced by anybody. But to make this work it would require putting all the EXPORT_SYMBOLs into own sections too, but I suppose that would be possible. In the past we had trouble that the explicit linker scripts mentioning every function section made the linker very slow, but perhaps that's fixed now. The whole thing would likely made a lot of out of tree modules unhappy though. Distribution kernels might need to turn it off generally because of that. The question is if it would be still have a large enough user base without the distribution kernels. If it would be only used by a few users I don't think the maintenance overhead would be worth it. > Andi scheduled it for removal, and I don't know whether he already has a > patch. I don't have a patch yet, but I can submit one for -mm* if it's helpful. It's not very difficult. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On 11/11/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > So it's not strictly an > > output directory, more a build directory. > The opposite > All output is placed there - including the configuration generated by > the *config frontends. I meant, it's not strictly an output directory as if I do make O=dir oldconfig it will _read_ dir/.config, so the O= directory is also used for input. And yes, I was splitting hairs ;-) Sorry for the confusion. -- Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 13/13] Char: nozomi, cleanup read and write
On Sonntag 11 November 2007 03:37:28, you (Frank Seidel) wrote:
> While in the read_mem32 the unlikekly really seems to be of no use at all (the
> switch-case ahead seems to be hit nearly always), the unlikely in the
> write_mem32 seems to be fine.
> I compared after each 30 seconds and got median ratio of 1381:1 (for the
> likely path) after about 20 minutes, i see a range between 1046:1 and
> 3511:1. So i wouldn't call it a bad guess from my beginners point of view.
I even did some more tracking which pathes get used in there with what
size_bytes values for write_mem32. To what i could see i get about
50% of the calls with size_bytes == 4 (what gets handled in the
switch-case shortcut), about 30% of the calls with size_bytes == 1 (
so i also added a shortcut for this which was just one line) and the
remaining calls (not handled in the switch-case ahead) still reach
a ratio of about 800:1 for the 4-byte-case to the (unlikely) 2-byte-
case.
So i did a rework of that patch which is nearly as nice as Jiris,
but works here without problems and has the size_bytes 1 shortcut,
plus the "unlikely" for the remaining 2-bytes path.
I know the format of the patch isn't fully correct, but i'll integrate
it into the complete patch und polish it there before posting that
again.
Thanks a lot,
Frank
---
Index: linux/drivers/char/nozomi.c
===
--- linux.orig/drivers/char/nozomi.c
+++ linux/drivers/char/nozomi.c
@@ -104,6 +104,7 @@
#include
#include
#include
+#include
#include
@@ -265,7 +266,7 @@ enum port_type {
PORT_ERROR = -1,
};
-#ifdef __ARMEB__
+#ifdef __BIG_ENDIAN
/* Big endian */
struct toggles {
@@ -547,11 +548,7 @@ static void read_mem32(u32 *buf, const v
u32 size_bytes)
{
u32 i = 0;
-#ifdef __ARMEB__
- const u32 *ptr = (u32 *) mem_addr_start;
-#else
const u32 *ptr = (__force u32 *) mem_addr_start;
-#endif
u16 *buf16;
if (unlikely(!ptr || !buf))
@@ -561,19 +558,11 @@ static void read_mem32(u32 *buf, const v
switch (size_bytes) {
case 2: /* 2 bytes */
buf16 = (u16 *) buf;
-#ifdef __ARMEB__
- *buf16 = __le16_to_cpu(readw(ptr));
-#else
- *buf16 = readw((void __iomem *)ptr);
-#endif
+ *buf16 = __le16_to_cpu(readw((void __iomem *)ptr));
goto out;
break;
case 4: /* 4 bytes */
-#ifdef __ARMEB__
- *(buf) = __le32_to_cpu(readl(ptr));
-#else
- *(buf) = readl((void __iomem *)ptr);
-#endif
+ *(buf) = __le32_to_cpu(readl((void __iomem *)ptr));
goto out;
break;
}
@@ -582,19 +571,11 @@ static void read_mem32(u32 *buf, const v
if (size_bytes - i == 2) {
/* Handle 2 bytes in the end */
buf16 = (u16 *) buf;
-#ifdef __ARMEB__
- *(buf16) = __le16_to_cpu(readw(ptr));
-#else
- *(buf16) = readw((void __iomem *)ptr);
-#endif
+ *(buf16) = __le16_to_cpu(readw((void __iomem *)ptr));
i += 2;
} else {
/* Read 4 bytes */
-#ifdef __ARMEB__
- *(buf) = __le32_to_cpu(readl(ptr));
-#else
- *(buf) = readl((void __iomem *)ptr);
-#endif
+ *(buf) = __le32_to_cpu(readl((void __iomem *)ptr));
i += 4;
}
buf++;
@@ -613,11 +594,7 @@ static u32 write_mem32(void __iomem *mem
u32 size_bytes)
{
u32 i = 0;
-#ifdef __ARMEB__
- u32 *ptr = (u32 *) mem_addr_start;
-#else
u32 *ptr = (__force u32 *) mem_addr_start;
-#endif
u16 *buf16;
if (unlikely(!ptr || !buf))
@@ -627,40 +604,28 @@ static u32 write_mem32(void __iomem *mem
switch (size_bytes) {
case 2: /* 2 bytes */
buf16 = (u16 *) buf;
-#ifdef __ARMEB__
- writew(__le16_to_cpu(*buf16), ptr);
-#else
- writew(*buf16, (void __iomem *)ptr);
-#endif
+ writew(__cpu_to_le16(*buf16), (void __iomem *)ptr);
return 2;
break;
+ case 1:
+ /* also need to write 4 bytes in this case
+* so falling through..
+*/
case 4: /* 4 bytes */
-#ifdef __ARMEB__
- writel(__cpu_to_le32(*buf), ptr);
-#else
- writel(*buf, (void __iomem *)ptr);
-#endif
+ writel(__cpu_to_le32(*buf), (void __iomem *)ptr);
return 4;
break;
}
while (i < size_bytes) {
- if (size_bytes - i == 2) {
+ if (unlikely(size_bytes - i == 2)) {
/* 2 bytes */
buf16 = (u16 *) buf;
-#ifdef __ARMEB__
- wri
Re: [PATCH 1/6] Suppress A.OUT library support if !CONFIG_BINFMT_AOUT [try #5]
On Sun, Nov 11, 2007 at 04:46:26PM +0100, Andi Kleen wrote: > > > My thoughts go more into the direction that we have hundreds of similar > > cases where e.g. a VFS function might currently only by used by OCFS2 > > and therefore be dead code for most users, and the only maintainable > > solution will be to solve these at the compiler and/or linker level. > > -ffunction-sections can mostly do it, but only for non modular kernels > > One problem is that EXPORT_SYMBOL always creates a reference to the function > even when nothing uses it. > > We would need a weak EXPORT_SYMBOL and some way to check references > over main kernel and modules. I suppose it could be done as part of modpost > and then generating a custom linker script that only includes the function > sections referenced by anybody. But to make this work it would require > putting all the EXPORT_SYMBOLs into own sections too, but I suppose > that would be possible. > > In the past we had trouble that the explicit linker scripts mentioning every > function section made the linker very slow, but perhaps that's fixed now. I don't remember the technical details, but Denys Vlasenko posted some patches that implemented -ffunction-sections while retaining exports. Another approach would be calling gcc with "-combine -fwhole-program". David Woodhouse once sent a whacky patch that implemented this on a per-module basis retaining exports. Much harder, but with the biggest possible savings, would be a CONFIG_MODULES=n kernel built with one gcc call. >... > The question is if it would be still have a large enough user base without > the > distribution kernels. If it would be only used by a few users I don't think > the maintenance overhead would be worth it. >... You forget the big embedded userbase - some even stay at kernel 2.4 since kernel 2.6 is much bigger. > -Andi 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 card initialisation at boot
"Keith Chew" <[EMAIL PROTECTED]> writes: > > My question is: Will setting the BIOS to "Resource allocation by > Manual" prevent the crash from happening in the future? More > specifically, does Linux still depend on ESCD even if the resource > allocation is set to Manual? Linux does not directly use the ESCD, but it uses configuration coming from the BIOS (like PCI bridge setup or ACPI resources) that might depend on the ESCD depending on your BIOS implementation. You would probably need to ask someone familiar with your BIOS what the ESCD influences in your configuration and what Manual allocation changes exactly. Most likely the real fix would be to add a checksum to it, but only the BIOS can do that. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] Suppress A.OUT library support if !CONFIG_BINFMT_AOUT [try #5]
Andi Kleen <[EMAIL PROTECTED]> wrote: > One problem is that EXPORT_SYMBOL always creates a reference to the function > even when nothing uses it. Exactly. This function is for use in something that can be compiled as a module, therefore this sort of thing is academic - unless we take away the ability of the aout binfmt to be built as a module. What's wrong, anyway, with inlining the function? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
Alan Cox <[EMAIL PROTECTED]> wrote: > Ok so these are not addresses but magic registers in the processor ? Then > I guess volatile makes complete sense. They are such magic registers, though of various grades. Some are part of the CPU core and affect things like CPU core itself, CPU caches, MMU/TLB and exceptions/interrupts. Others are on-silicon devices such as the serial ports, the bus controller, the SDRAM controller. > For PIO (virtual DMA or otherwise) the locking does that. Because > spin_unlock and spin_lock are compiler barriers the need to use volatile > shouldn't normally be there. If you are doing it via asm without locks > then I would expect atomic_t because the sematics of volatile are > horribly vague on their own ? Using memory barriers ought to be good enough for the ring buffer. There aren't actually any atomic ops available other than bit-set and bit-clear. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]
> Some are part of the CPU core and affect things like CPU core itself, CPU > caches, MMU/TLB and exceptions/interrupts. Others are on-silicon devices such > as the serial ports, the bus controller, the SDRAM controller. How are they addressed - as CPU registers or as memory/IO 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/
[RFC] Re: nozomi version 2.1d for review
Hello, this one also holds the - little reworked and optimized - cleanup of the read/write_mem32 functions. Comments and any feedback is more than welcome. Thanks a lot - especially to Jiri, Alan and Greg, Frank --- >From [EMAIL PROTECTED] Tue Apr 9 12:12:43 2002 Date: Thu, 24 Aug 2006 01:25:46 -0700 To: Greg KH <[EMAIL PROTECTED]> From: Greg Kroah-Hartman <[EMAIL PROTECTED]> Subject: Add nozomi driver to the tree This is a driver to control the cardbus wireless data card that works on 3g networks. It still needs a lot of cleanup, but is getting there... at least it builds with no warnings on i386 now... Thanks to Arnaud Patard <[EMAIL PROTECTED]> for help with bugfixing. Thanks to Alan Cox for a lot of tty fixes. Thanks to Satyam Sharma <[EMAIL PROTECTED]> for fixing buildbreakage. Thanks to Frank Seidel <[EMAIL PROTECTED]> for a lot of bugfixes and rewriting to make it a sane Linux driver. Thanks to Jiri Slaby <[EMAIL PROTECTED]> for a lot bugfixes, cleanups and rewrites that make it much more readable. Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> Signed-off-by: Frank Seidel <[EMAIL PROTECTED]> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> --- drivers/char/Kconfig | 10 drivers/char/Makefile |1 drivers/char/nozomi.c | 2105 ++ 3 files changed, 2116 insertions(+) --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -373,6 +373,16 @@ config ISTALLION To compile this driver as a module, choose M here: the module will be called istallion. +config NOZOMI + tristate "HSDPA Broadband Wireless Data Card - Globe Trotter" + depends on PCI && EXPERIMENTAL + help + If you have a HSDPA driver Broadband Wireless Data Card - + Globe Trotter PCMCIA card, say Y here. + + To compile this driver as a module, choose M here, the module + will be called nozomi. + config A2232 tristate "Commodore A2232 serial support (EXPERIMENTAL)" depends on EXPERIMENTAL && ZORRO && BROKEN_ON_SMP --- a/drivers/char/Makefile +++ b/drivers/char/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_SERIAL167) += serial167.o obj-$(CONFIG_CYCLADES) += cyclades.o obj-$(CONFIG_STALLION) += stallion.o obj-$(CONFIG_ISTALLION)+= istallion.o +obj-$(CONFIG_NOZOMI) += nozomi.o obj-$(CONFIG_DIGIEPCA) += epca.o obj-$(CONFIG_SPECIALIX)+= specialix.o obj-$(CONFIG_MOXA_INTELLIO)+= moxa.o --- /dev/null +++ b/drivers/char/nozomi.c @@ -0,0 +1,2105 @@ +/* + * nozomi.c -- HSDPA driver Broadband Wireless Data Card - Globe Trotter + * + * Written by: Ulf Jakobsson, + * Jan �erfeldt, + * Stefan Thomasson, + * + * Maintained by: Paul Hardwick ([EMAIL PROTECTED]) + * + * Patches: + * Locking code changes for Vodafone by Sphere Systems Ltd, + * Andrew Bird ([EMAIL PROTECTED] ) + * & Phil Sanderson + * + * Source has been ported from an implementation made by Filip Aben @ Option + * + * -- + * + * Copyright (c) 2005,2006 Option Wireless Sweden AB + * Copyright (c) 2006 Sphere Systems Ltd + * Copyright (c) 2006 Option Wireless n/v + * All rights Reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * + * -- + */ + +/* + * CHANGELOG + * Version 2.1d + * 11-November-2007 Jiri Slaby, Frank Seidel + * - Major cleanups (semaphore to mutex, endianess) + * - Optimizations + * + * Version 2.1c + * 30-October-2007 Frank Seidel + * - Completed multicard support + * - Minor cleanups + * + * Version 2.1b + * 07-August-2007 Frank Seidel + * - Minor cleanups + * - theoretical multicard support + * + * Version 2.1 + * 03-July-2006 Paul Hardwick + * + * - Stability Improvements. Incorporated spinlock wraps patch. + * - Updated for newer 2.6.14+ kernels (tty_buffer_request_room) + * - using __devexit macro for tty + * + * + * Version 2.0 + * 08-feb-2006 15:34:10:Ulf + * + * -Fixed issue when not waking up line disipine layer, could probably result + * in better uplink performance for 2.4. + * + * -Fixed issue with big endian during inital
Re: PCI card initialisation at boot
> I am guessing that the ESCD has been corrupted, and putting a spare > device caused the BIOS to reset the ESCD. In the BIOS, it has been > setup as "Resource allocation by Auto(ESCD)". Quite possibily. It may also be that the card had simply developed a bad connection. > There is another option in the BIOS to set "Resource allocation by > Manual". I have tried this setting and Linux has no problems booting > up and using the PCI card. > > My question is: Will setting the BIOS to "Resource allocation by > Manual" prevent the crash from happening in the future? More > specifically, does Linux still depend on ESCD even if the resource > allocation is set to Manual? Linux by default uses the BIOS resource assignments. It doesn't know where those came from other than "the BIOS". Also as most vendors checksum the ESCD I'd be suprised if an ESCD error caused the problem, but I guess you can get unlucky. Cards can simply lose connection especially if in a dirty, damp or particularly in a vibration high environment. In the shipping industry, for example, it is not uncommon to dismantle all the cards from a PC and refit them then tighten all the screws as a routine maintenance activity. 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/
[PATCH] powerpc: Add EXPORT_SYMBOL for symbols required by fs_enet and cpm_uart
fs_enet and cpm_uart need symbols from commproc.c (for CPM1) or cpm2_common.c. Add EXPORT_SYMBOL for cpmp, cpm_setbrg and cpm2_immr, so the drivers can be compiled as modules. Building modules, stage 2. MODPOST 5 modules ERROR: "cpm2_immr" [drivers/net/fs_enet/fs_enet.ko] undefined! ERROR: "cpmp" [drivers/net/fs_enet/fs_enet.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/commproc.c|3 +++ arch/powerpc/sysdev/cpm2_common.c |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c index f6a6378..d5a0dcf 100644 --- a/arch/powerpc/sysdev/commproc.c +++ b/arch/powerpc/sysdev/commproc.c @@ -51,6 +51,8 @@ static void m8xx_cpm_dpinit(void); static uint host_buffer; /* One page of host buffer */ static uint host_end;/* end + 1 */ cpm8xx_t __iomem *cpmp; /* Pointer to comm processor space */ +EXPORT_SYMBOL(cpmp); + immap_t __iomem *mpc8xx_immr; static cpic8xx_t __iomem *cpic_reg; @@ -302,6 +304,7 @@ cpm_setbrg(uint brg, uint rate) out_be32(bp, (((BRG_UART_CLK_DIV16 / rate) - 1) << 1) | CPM_BRG_EN | CPM_BRG_DIV16); } +EXPORT_SYMBOL(cpm_setbrg); #ifndef CONFIG_PPC_CPM_NEW_BINDING /* diff --git a/arch/powerpc/sysdev/cpm2_common.c b/arch/powerpc/sysdev/cpm2_common.c index 859362f..4ed5df6 100644 --- a/arch/powerpc/sysdev/cpm2_common.c +++ b/arch/powerpc/sysdev/cpm2_common.c @@ -51,11 +51,13 @@ static void cpm2_dpinit(void); #endif cpm_cpm2_t __iomem *cpmp; /* Pointer to comm processor space */ +EXPORT_SYMBOL(cpmp); /* We allocate this here because it is used almost exclusively for * the communication processor devices. */ cpm2_map_t __iomem *cpm2_immr; +EXPORT_SYMBOL(cpm2_immr); #define CPM_MAP_SIZE(0x4) /* 256k - the PQ3 reserve this amount of space for CPM as it is larger @@ -117,6 +119,7 @@ cpm_setbrg(uint brg, uint rate) cpm2_unmap(bp); } +EXPORT_SYMBOL(cpm_setbrg); /* This function is used to set high speed synchronous baud rate * clocks. -- 1.5.3.5 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
laptop reboots right after hibernation
echo disk > /sys/power/state successfully saves that state to the disk, but just as the laptop is about to turn itself off, it reboots (successfully, so the hibernation/resume process works well, even with X running! which is awesome :) ). But I'd rather like the computer turned off after I hibernate it. Where could the problem be? It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few days, both suspend and hibernate worked there (with one or two crashes, probably due to X, I've read that the intel driver got some suspend/resume improvements recently). Now I'm running gentoo, kernel 2.6.24-rc2. I'm using newer versions of almost all software now compared to the ubuntu system. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc: Add support for PORTA sor and PORTB odr registers
PORTA has an so register and PORTB had an odr register, as well.
However, the PORTB odr register is only 16bit.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/commproc.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index f6a6378..a9f5fcf 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -438,6 +438,13 @@ static void cpm1_set_pin32(int port, int pin, int flags)
else
clrbits32(&iop->par, pin);
+ if (port == CPM_PORTB) {
+ if (flags & CPM_PIN_OPENDRAIN)
+ setbits16(&mpc8xx_immr->im_cpm.cp_pbodr, pin);
+ else
+ clrbits16(&mpc8xx_immr->im_cpm.cp_pbodr, pin);
+ }
+
if (port == CPM_PORTE) {
if (flags & CPM_PIN_SECONDARY)
setbits32(&iop->sor, pin);
@@ -471,7 +478,7 @@ static void cpm1_set_pin16(int port, int pin, int flags)
else
clrbits16(&iop->par, pin);
- if (port == CPM_PORTC) {
+ if ((port == CPM_PORTA) || (port == CPM_PORTC)) {
if (flags & CPM_PIN_SECONDARY)
setbits16(&iop->sor, pin);
else
--
1.5.3.5
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/capability.c get_task_comm compile error (MMOTM)
In message <[EMAIL PROTECTED]>, Ingo Molnar writes:
>
> * Erez Zadok <[EMAIL PROTECTED]> wrote:
>
> > Small patch below fixes compile error.
>
> > + char name[sizeof(current->comm)];
> > warned++;
> > printk(KERN_INFO
> >"warning: process `%s' sets w/ old libcap\n",
> > - get_task_comm(current));
> > + get_task_comm(name, current));
>
> that's buggy - get_task_comm() returns void.
>
> the proper fix would be to first do a get_task_comm() then pass in
> 'name' as an argument to printk.
>
> Ingo
Ingo, I don't see how it can return NULL. This is what get_task_comm looks
like in MMOTM-2007-11-10-19-05:
char *get_task_comm(char *buf, struct task_struct *tsk)
{
/* buf must be at least sizeof(tsk->comm) in size */
task_lock(tsk);
strncpy(buf, tsk->comm, sizeof(tsk->comm));
task_unlock(tsk);
return buf;
}
The only way it'd return NULL is if a null buf was passed, in which case the
strncpy will oops first.
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] netx: remove bogus defconfig patch with wrong -p
On Sun, 11 Nov 2007, Russell King wrote: > > So what's happening with this? Who's going to merge it? Well, I already removed the bogus file. But whether the defconfig file in arch/arm needs updating or not is up to you guys. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/24] make vsmp a paravirt client
On Fri, Nov 09, 2007 at 04:43:05PM -0200, Glauber de Oliveira Costa wrote: > This patch makes vsmp a paravirt client. It now uses the whole > infrastructure provided by pvops. When we detect we're running > a vsmp box, we change the irq-related paravirt operations (and so, > it have to happen quite early), and the patching function The PARAVIRT ifdefs look wrong. Surely you don't need them at all because it cannot work at all without paravirt. Also you got some white space damage. And the "EM64T based comment" is wrong because there are AMD based vSMPs too. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 regression: hibernation hangs on "Suspending console" in low-battery condition
On Sunday, 11 of November 2007, Andrey Borzenkov wrote: > On Monday 05 November 2007, Andrey Borzenkov wrote: > > Notice "hung" not "hangs". This happened so far only once - when low > > battery > > condition triggered suspend to disk. I was not able to reproduce it after > > this running on AC. > > > > Just in case it rings the bell for someone. This is not suspend regression > > reported earlier by Jens - I do not even have SATA nor is using libata > > drivers. > > > > This happened second time, now with 2.6.24-rc2. I have kpowersave configured > to initiate suspend-to-disk on low battery. Suspend-to-disk is initiated, > but system stops after Suspending console line. Suspend image is not created. > > This did work before although I do not name exact version. > > I am rather at loss how to proceed further ... any idea? dmesg and config > attached just in case. The problem is that hibernation works when I initiate > it manually ... Have you tried it with the battery removed? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add quirk to set AHCI mode on ICH boards
On 11.11.2007 15:05, Thorsten Leemhuis wrote: > On 10.11.2007 00:32, Matthias Schniedermeyer wrote: > > [...] > > My computer/mainboard @work has such a "broken" BIOS. Of the 5 > > SATA-Ports this MB has only 1 (and 1 "missing" that is reported by > > linux but i can't find on the MB) is configured as AHCI [...] > > There is nothing "broken" here. You have a ICH8 (without R) that drives > four SATA ports, which are handled by ata_piix. > > Then you have a Jmicron JMB363 -- it handles the PATA-Channel and two > SATA-Ports -- one internal (near the battery)/next to the PCI-Slot and a > external eSATA port. Seems you configured it in AHCI-Mode in the > BIOS-Setup. Linux will work just fine if you connect the hard disc to > that port. But if you want to install Windows XP you need a driver from > Jmicron. > > There were BIOSes for the P5B where you could enabled AHCI for the ICH8 > as well. It seems Asus removed it in the later BIOS-versions again as > Intel doesn't provide a Windows-AHCI driver for the basic ICH8. I don't have an P5B @work, but i guess MSI cooks with water too. :-) But i have a (1 year old) P5B @home and it is exactly like you said. My main point is still the same, if Linux could force AHCI mode, i wouldn't have to switch between those modes when booting Wintendo to play some games. (And i could use AHCI @work where i can't switch it in BIOS) On a side note, with the mainboard i had before the P5B (ASUS, 925X Chipset, ICH 6 or 7) Linux worked in AHCI-mode and Wintendo worked also without problems. (IOW: I did not need to switch modes in BIOS!) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading
On Saturday, 10 of November 2007, Chris Friedhoff wrote: > please cc me, I'm not not subscribed to LKML > > Hello, > > with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but > when I start the system and the suspended systemimage is loaded, it > fails to "activate" this suspended systemimage and continues after some > time with following the normal boot sequence. > > I can sucessfully STD the system with the following sequence > echo platform > /sys/power/disk > echo disk > /sys/power/state > and when I start the laptop the suspended system is sucessfully > restored. > > Both behaviors are reliable reproducable. Thanks for the report. > googling for >"Freezing of tasks failed" swapper< brought > "Nigel Cunningham - PID namespaces break initrd+hibernate combination?" > http://lkml.org/lkml/2007/11/4/140 Yes, this looks similarly. > dmesg output: > <> > RAMDISK: ext2 filesystem found at block 0 > RAMDISK: Loading 2000KiB [1 disk] into ram disk... done. > EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > VFS: Mounted root (ext2 filesystem). > swsusp: Marking nosave pages: 0009f000 - 0010 > swsusp: Basic memory bitmaps created > Clocksource tsc unstable (delta = -128791628 ns) > Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... > Freezing of tasks failed after 20.00 seconds (1 tasks refusing to > freeze): taskPC stack pid father > swapper S c1835a88 0 1 0 > 0046 c0118c80 c1835a88 0004 0001 c011e875 > 0286 c01025a6 c1835b64 c1835a90 > 0001 007b c1835a90 > c0118c80 Call Trace: > [] default_wake_function+0x0/0x10 > [] do_wait+0x335/0xac0 > [] kernel_thread+0x96/0xb0 > [] default_wake_function+0x0/0x10 > [] sys_wait4+0x31/0x40 > [] initrd_load+0x1b3/0x3a0 > [] prepare_namespace+0x98/0x1b0 > [] sys_access+0x1f/0x30 > [] kernel_init+0x166/0x260 > [] ret_from_fork+0x6/0x1c > [] kernel_init+0x0/0x260 > [] kernel_init+0x0/0x260 > [] kernel_thread_helper+0x7/0x18 > === > kthreadd S 038f 0 2 0 > 0046 c0487790 038f c183ff1c c012d81b > c012d7b0 c0104b8f > > Call Trace: > [] kthreadd+0x6b/0xd0 > [] kthreadd+0x0/0xd0 > [] kernel_thread_helper+0x7/0x18 > === > ksoftirqd/0 S 0 3 2 > 0046 fffc c0120f00 c0120f7a > c012d782 c012d740 c0104b8f c183ff3c > > Call Trace: > [] ksoftirqd+0x0/0x80 > [] ksoftirqd+0x7a/0x80 > [] kthread+0x42/0x70 > [] kthread+0x0/0x70 > [] kernel_thread_helper+0x7/0x18 > > <> Can you please attach your kernel configuration file to the bugzilla entry at http://bugzilla.kernel.org/show_bug.cgi?id=9345 ? Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Temporary lockup on loopback block device
> > Why are there over-limit dirty pages that no one is writing? > > Please do a sysrq-t, and cat /proc/vmstat during the hang. Those > will show us what exactly is happening. I did and I posted relevant information from my finding --- it looped in balance_dirty_pages. > I've seen this type of hang many times, and I agree with Peter, that > it's probably about loopback, and is fixed in 2.6.24-rc. On 2.6.23 it could happen even without loopback --- loopback just made it happen very often. 2.6.24 seems ok. Mikulas > Thanks, > Miklos > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] log2.h: Define order_base_2() macro for convenience.
On Sat, 10 Nov 2007 22:53:36 -0500 (EST) Robert P. J. Day wrote: > > Given a number of places in the tree that need to calculate this value > explicitly, might as well just create a macro for it. > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > --- > > run-time tested for the first several values. note that this macro > is defined strictly in terms of rounding *up* -- i've seen no places > in the tree that require this expression to be rounded down, so i'm > not drawing that distinction. > > diff --git a/include/linux/log2.h b/include/linux/log2.h > index c8cf5e8..ed121c0 100644 > --- a/include/linux/log2.h > +++ b/include/linux/log2.h > @@ -190,4 +190,20 @@ unsigned long __rounddown_pow_of_two(unsigned long n) > __rounddown_pow_of_two(n) \ > ) > > +/** > + * order_base_2 - calculate the (rounded up) base 2 order of the argument > + * @n - parameter * @n: argument (mostly changing - to :) > + * > + * The first few values calculated by this routine: > + * ob2(0) = 0 > + * ob2(1) = 0 > + * ob2(2) = 1 > + * ob2(3) = 2 > + * ob2(4) = 2 > + * ob2(5) = 3 > + * ... and so on. > + */ > + > +#define order_base_2(n) ilog2(roundup_pow_of_two(n)) > + > #endif /* _LINUX_LOG2_H */ > > -- --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Strage buffer behaviour
Hi folks, I noticed that the kernel (2.6.23.1) seems to buffer only certain partitions on my system: $ for i in 1 2 3 4 ; do for j in 1 2 ; do dd if=/dev/sda$i of=/dev/null bs=1024k count=100 ; done ; done 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 3.01471 seconds, 34.8 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.86945 seconds, 36.5 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.92038 seconds, 35.9 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 3.00272 seconds, 34.9 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 4.07722 seconds, 25.7 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.0944248 seconds, 1.1 GB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 5.61527 seconds, 18.7 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.331822 seconds, 316 MB/s The dd command reads 100 MB from each partition two times in a row. It looks like sda1 and sda2 are not bufferd (the first 4 dd runs), but sda3 and sda4 are (the last 4 dd runs). The computer is a Mac mini with a 2,5" SATA hard disk. The first 2 partitions contain EFI and MacOS X, and are unused in Linux. The last 2 partitions are an ext3 partition for / and an LVM for the rest of the sytem. Any hints how the dd/buffering behaviour could be explained? The system was mostly idle, and the numbers are reproducible across reboots. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser(2)
Hi Pavel, On Nov 11, 2007 2:44 PM, Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > > A Smack Rule in an "egrep" format is: > > > > > > "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n" > > Perhaps you should make it space, not 'space or tab', and only allow > lowercase permissions? That way, parser will be slightly simpler, and > you'll still have a chance to use 'R' as 'slightly different r'. > Thanks for your care about this. It seems not a lot of people have noticed, but to stop any objections not related to the core smack code, Casey decided to let the parsing be done in a user-space utility that sends the rules to the kernel in a predefined strict format. You can find how the whole story in the smackv11 announcement here: http://article.gmane.org/gmane.linux.kernel.lsm/4463 Regards, -- Ahmed S. Darwish Homepage: http://darwish.07.googlepages.com Blog: http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Unionfs: stop using iget() and read_inode()
Andrew, the following small patch is critical to have after: iget-stop-unionfs-from-using-iget-and-read_inode.patch Question: since the above patch isn't in my unionfs.git tree (not until the whole iget series makes it to Linus), then do you prefer if I give you a replacement patch to the above patch, or a small incremental one; either way, you can choose to fold the above and below patches into one. Thanks, Erez. Unionfs: bugfix to initialize unionfs_inode_info node Signed-off-by: Erez Zadok <[EMAIL PROTECTED]> diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c index 7408b0f..d6544f8 100644 --- a/fs/unionfs/super.c +++ b/fs/unionfs/super.c @@ -38,6 +38,7 @@ struct inode *unionfs_iget(struct super_block *sb, unsigned long ino) unionfs_read_lock(sb); + info = UNIONFS_I(inode); memset(info, 0, offsetof(struct unionfs_inode_info, vfs_inode)); info->bstart = -1; info->bend = -1; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Reported regressions from 2.6.23
On Saturday, 10 of November 2007, Frans Pop wrote: > Rafael J. Wysocki wrote: > > If you know of any other unresolved regressions from 2.6.23, please let me > > know either and I'll add them to the list. > > Probably this issue should be added: > http://lkml.org/lkml/2007/11/1/207 > Latest proposed patch that I'm aware of is at: > http://lkml.org/lkml/2007/11/1/246 > > To be honest, I'm a bit surprised no patch for that has made it into > mainline yet. Added. Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 regression: hibernation hangs on "Suspending console" in low-battery condition
On Sunday 11 November 2007, Rafael J. Wysocki wrote: > On Sunday, 11 of November 2007, Andrey Borzenkov wrote: > > On Monday 05 November 2007, Andrey Borzenkov wrote: > > > Notice "hung" not "hangs". This happened so far only once - when low > > > battery > > > condition triggered suspend to disk. I was not able to reproduce it after > > > this running on AC. > > > > > > Just in case it rings the bell for someone. This is not suspend > > > regression > > > reported earlier by Jens - I do not even have SATA nor is using libata > > > drivers. > > > > > > > This happened second time, now with 2.6.24-rc2. I have kpowersave configured > > to initiate suspend-to-disk on low battery. Suspend-to-disk is initiated, > > but system stops after Suspending console line. Suspend image is not > > created. > > > > This did work before although I do not name exact version. > > > > I am rather at loss how to proceed further ... any idea? dmesg and config > > attached just in case. The problem is that hibernation works when I initiate > > it manually ... > > Have you tried it with the battery removed? > > It works. Subjectively I have relatively long pause after first Suspending console message (where it hangs otherwise), according to dmesg timestamp it is about 1 second before next messages appear. Also last two times I tried it writeout of suspend image was really slow; it was both with and without battery. Reading on resume in really in order of magnitude faster. But manual STD so far works both on AC (with or without battery) or on battery. Of course it is possible that battery gets exhausted during STD, but system is not switched off. Rather I would suspect something like ACPI notification that comes during freeze ... If someone can advice which options to enable I could try netconsole. But likely not before next weekend. signature.asc Description: This is a digitally signed message part.
Re: 2.6.24 regression: hibernation hangs on "Suspending console" in low-battery condition
On Sunday, 11 of November 2007, Andrey Borzenkov wrote: > On Sunday 11 November 2007, Rafael J. Wysocki wrote: > > On Sunday, 11 of November 2007, Andrey Borzenkov wrote: > > > On Monday 05 November 2007, Andrey Borzenkov wrote: > > > > Notice "hung" not "hangs". This happened so far only once - when low > > > > battery > > > > condition triggered suspend to disk. I was not able to reproduce it > > > > after > > > > this running on AC. > > > > > > > > Just in case it rings the bell for someone. This is not suspend > > > > regression > > > > reported earlier by Jens - I do not even have SATA nor is using libata > > > > drivers. > > > > > > > > > > This happened second time, now with 2.6.24-rc2. I have kpowersave > > > configured > > > to initiate suspend-to-disk on low battery. Suspend-to-disk is initiated, > > > but system stops after Suspending console line. Suspend image is not > > > created. > > > > > > This did work before although I do not name exact version. > > > > > > I am rather at loss how to proceed further ... any idea? dmesg and config > > > attached just in case. The problem is that hibernation works when I > > > initiate > > > it manually ... > > > > Have you tried it with the battery removed? > > > > > > It works. Subjectively I have relatively long pause after first Suspending > console > message (where it hangs otherwise), according to dmesg timestamp it is about > 1 second before next messages appear. Also last two times I tried it writeout > of suspend image was really slow; it was both with and without battery. > Reading > on resume in really in order of magnitude faster. > > But manual STD so far works both on AC (with or without battery) or on > battery. > > Of course it is possible that battery gets exhausted during STD, but system > is not switched off. Rather I would suspect something like ACPI notification > that comes during freeze ... Frankly, I'm suspecting a deadlock in the ACPI code. Please try to make kpowersave start hibernation a bit earlier and see what happens. What's your critical time now? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-g74521c28: oops during boot [] :power_supply:power_supply_show_property+0x94/0x150
>>> http://bugzilla.kernel.org/show_bug.cgi?id=9299 > > I just tested again (with 2.6.24-rc2-gecd744ee). If I only load the 'ac' > kernel module and not the 'battery' kernel module, then the system boots > fine. However, if I load the 'battery' module during boot or later, I > still get the oops. > > I am running 2.6.24-rc2-gecd744ee right now, but without the battery > module. I am forwarding this to the ACPI list as well. > Replying to myself again. Apparently, a fix for this bug was applied to the linux-acpi tree independently of my bug report, see here: http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=4c41d3ad6544f1c9aec37c441af04f5d0ad3a731 signature.asc Description: OpenPGP digital signature
Re: 2.6.24-rc1-g74521c28: oops during boot [] :power_supply:power_supply_show_property+0x94/0x150
On Sunday, 11 of November 2007, Thomas Bächler wrote: > >>> http://bugzilla.kernel.org/show_bug.cgi?id=9299 > > > > I just tested again (with 2.6.24-rc2-gecd744ee). If I only load the 'ac' > > kernel module and not the 'battery' kernel module, then the system boots > > fine. However, if I load the 'battery' module during boot or later, I > > still get the oops. > > > > I am running 2.6.24-rc2-gecd744ee right now, but without the battery > > module. I am forwarding this to the ACPI list as well. > > > > Replying to myself again. Apparently, a fix for this bug was applied to > the linux-acpi tree independently of my bug report, see here: > http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=4c41d3ad6544f1c9aec37c441af04f5d0ad3a731 I'm having some problems with accessing git.kernel.org right now. I'll have a look when it works again. Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
enable dual rng on VIA C7
Hello, Any reason why the second rng on the VIA C7 CPU is not enabled? Kind regards, Udo --- old/drivers/char/hw_random/via-rng.c2007-11-11 19:39:49.0 +0100 +++ new/drivers/char/hw_random/via-rng.c2007-11-11 19:40:41.0 +0100 @@ -41,6 +41,7 @@ VIA_STRFILT_ENABLE = (1 << 14), VIA_RAWBITS_ENABLE = (1 << 13), VIA_RNG_ENABLE = (1 << 6), + VIA_RNG_DUAL= (1 << 9), VIA_XSTORE_CNT_MASK = 0x0F, VIA_RNG_CHUNK_8 = 0x00, /* 64 rand bits, 64 stored bits */ @@ -128,6 +129,7 @@ lo &= ~(0x7f << VIA_STRFILT_CNT_SHIFT); lo &= ~VIA_XSTORE_CNT_MASK; lo &= ~(VIA_STRFILT_ENABLE | VIA_STRFILT_FAIL | VIA_RAWBITS_ENABLE); + lo |= VIA_RNG_DUAL; lo |= VIA_RNG_ENABLE; if (lo != old_lo)
Re: 2.6.24-rc1: pata_acpi fails to activate DMA for DVD-ROM on ALi M5229 secondary channel
On Friday 26 October 2007, Alan Cox wrote: > On Fri, 26 Oct 2007 21:30:02 +0400 > Andrey Borzenkov <[EMAIL PROTECTED]> wrote: > > > Running legacy IDE drivers apparently works in DMA mode for both: > > Thanks - can you send me an lspci -vvxxx off list > BTW in rc2 it does not even boot - it babbles something about Unable to determine IRQ for 00:04.0 (which is IDE controller) and that is the end of story. No IDE device is found. signature.asc Description: This is a digitally signed message part.
[patch] x86: fix taking DNA during 64bit sigreturn
restore sigcontext is taking a DNA exception while restoring FP context from
the user stack, during the sigreturn. Appended patch fixes it by doing clts()
if the app doesn't touch FP during the signal handler execution. This will
stop generating a DNA, during the fxrstor in the sigreturn.
This improves 64-bit lat_sig numbers by ~30% on my core2 platform.
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/kernel/i387_64.c b/arch/x86/kernel/i387_64.c
index 56c1f11..bfaff28 100644
--- a/arch/x86/kernel/i387_64.c
+++ b/arch/x86/kernel/i387_64.c
@@ -92,13 +92,14 @@ int save_i387(struct _fpstate __user *buf)
if (task_thread_info(tsk)->status & TS_USEDFPU) {
err = save_i387_checking((struct i387_fxsave_struct __user
*)buf);
if (err) return err;
+ task_thread_info(tsk)->status &= ~TS_USEDFPU;
stts();
- } else {
- if (__copy_to_user(buf, &tsk->thread.i387.fxsave,
+ } else {
+ if (__copy_to_user(buf, &tsk->thread.i387.fxsave,
sizeof(struct i387_fxsave_struct)))
return -1;
- }
- return 1;
+ }
+ return 1;
}
/*
diff --git a/include/asm-x86/i387_64.h b/include/asm-x86/i387_64.h
index 0217b74..3a4ffba 100644
--- a/include/asm-x86/i387_64.h
+++ b/include/asm-x86/i387_64.h
@@ -203,6 +203,11 @@ static inline void save_init_fpu(struct task_struct *tsk)
*/
static inline int restore_i387(struct _fpstate __user *buf)
{
+ set_used_math();
+ if (!(task_thread_info(current)->status & TS_USEDFPU)) {
+ clts();
+ task_thread_info(current)->status |= TS_USEDFPU;
+ }
return restore_fpu_checking((__force struct i387_fxsave_struct *)buf);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/capability.c get_task_comm compile error (MMOTM)
On Sun, 11 Nov 2007 15:15:10 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Erez Zadok <[EMAIL PROTECTED]> wrote: > > > Small patch below fixes compile error. > > > + char name[sizeof(current->comm)]; > > warned++; > > printk(KERN_INFO > >"warning: process `%s' sets w/ old libcap\n", > > - get_task_comm(current)); > > + get_task_comm(name, current)); > > that's buggy - get_task_comm() returns void. > > the proper fix would be to first do a get_task_comm() then pass in > 'name' as an argument to printk. yup, it is all dependent upon http://lkml.org/lkml/2007/11/8/231 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strage buffer behaviour
On Sun, Nov 11, 2007 at 07:33:35PM +0100, Tino Keitel wrote: > I noticed that the kernel (2.6.23.1) seems to buffer only certain > partitions on my system: > > $ for i in 1 2 3 4 ; do for j in 1 2 ; do dd if=/dev/sda$i of=/dev/null > bs=1024k count=100 ; done ; done > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 3.01471 seconds, 34.8 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 2.86945 seconds, 36.5 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 2.92038 seconds, 35.9 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 3.00272 seconds, 34.9 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 4.07722 seconds, 25.7 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 0.0944248 seconds, 1.1 GB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 5.61527 seconds, 18.7 MB/s > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 0.331822 seconds, 316 MB/s > > The dd command reads 100 MB from each partition two times in a row. It > looks like sda1 and sda2 are not bufferd (the first 4 dd runs), but > sda3 and sda4 are (the last 4 dd runs). Strange.. I'm running 2.6.24-rc1 here. Reading data from /dev/hda1 caches well, but not from /dev/sd[ab]1. PS. you can flush caches with: echo 1 > /proc/sys/vm/drop_caches -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-g74521c28: oops during boot [] :power_supply:power_supply_show_property+0x94/0x150
Rafael J. Wysocki schrieb: >> Replying to myself again. Apparently, a fix for this bug was applied to >> the linux-acpi tree independently of my bug report, see here: >> http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=4c41d3ad6544f1c9aec37c441af04f5d0ad3a731 > > I'm having some problems with accessing git.kernel.org right now. I'll have a > look when it works again. Same problem here, it took me some time until I could view it. I forgot to mention that the patch actually fixes the bug in my case, I can boot 2.6.24 without oopses now. signature.asc Description: OpenPGP digital signature
2.6.24-rc2: Reported regressions from 2.6.23 (updated)
[Note: Due to git.kernel.org not responding I'm unable to check which fixes have already been merged since the last report.] This message contains a list of some regressions from 2.6.23 which have been reported since 2.6.24-rc1 was released and for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. Subject : On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at virtual address 3d15b925 Submitter : Giacomo Catenazzi <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/24/487 http://bugzilla.kernel.org/show_bug.cgi?id=9246 Handled-By : Patch : Subject : Potential regression in -git15: can't resume stopped root shell? Submitter : Theodore Tso <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/20/114 http://bugzilla.kernel.org/show_bug.cgi?id=9247 Handled-By : Serge Hallyn <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=13361&action=view http://bugzilla.kernel.org/attachment.cgi?id=13375&action=view Subject : irq 21: nobody cared 2.6.24-rc1 Submitter : Bongani Hlope <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/25/90 http://bugzilla.kernel.org/show_bug.cgi?id=9249 Handled-By : Patch : Subject : [BUG] panic after umount (biscted) Submitter : Sebastian Siewior <[EMAIL PROTECTED]> References : http://marc.info/?l=linux-kernel&m=119338387030335&w=2 http://bugzilla.kernel.org/show_bug.cgi?id=9250 Handled-By : Jens Axboe <[EMAIL PROTECTED]> Patch : http://marc.info/?l=linux-kernel&m=119348520210349&w=2 Subject : 2.6.24-rc1 sysctl table check failed on PowerMac Submitter : Mikael Pettersson <[EMAIL PROTECTED]> References : http://marc.info/?l=linux-kernel&m=119350802331857&w=2 http://bugzilla.kernel.org/show_bug.cgi?id=9251 Handled-By : Alexey Dobriyan <[EMAIL PROTECTED]> Patch : http://marc.info/?l=linux-kernel&m=119351015801660&w=2 Subject : 2.6.24-rc1: pata_acpi fails to activate DMA for DVD-ROM on ALi M5229 secondary channel Submitter : Andrey Borzenkov <[EMAIL PROTECTED]> References : http://marc.info/?l=linux-kernel&m=119342005216716&w=2 http://bugzilla.kernel.org/show_bug.cgi?id=9252 Handled-By : Alan Cox <[EMAIL PROTECTED]> Patch : Note: pata_acpi was not present in 2.6.23 Subject : 2.6.24-rc1 freezes on powerbook at first boot stage Submitter : Elimar Riesebieter <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/24/205 http://bugzilla.kernel.org/show_bug.cgi?id=9254 Handled-By : Patch : Subject : build #286 failed for 2.6.24-rc1-gea45d15 in linux/arch/x86/kernel/setup_32.c Submitter : Toralf Förster <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/28/110 http://bugzilla.kernel.org/show_bug.cgi?id=9256 Handled-By : "H. Peter Anvin" <[EMAIL PROTECTED]> Patch : http://marc.info/[EMAIL PROTECTED] Subject : 2.6.24-rc1 kills onboard r8169 (rtl8111b) NIC Submitter : "Sergey S. Kostyliov" <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/28/144 http://bugzilla.kernel.org/show_bug.cgi?id=9257 Handled-By : Francois Romieu <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=13441&action=view Subject : Commit "Hibernation: Enter platform hibernation state in a consistent way)" makes my system to resume instantly from S4 Submitter : Maxim Levitsky <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/27/66 http://bugzilla.kernel.org/show_bug.cgi?id=9258 Handled-By : "Rafael J. Wysocki" <[EMAIL PROTECTED]> Patch : Note: $subject commit apparently exposes a problem that existed previously Subject : leds: ledtrig-timer calls sleeping function from invalid context Submitter : Márton Németh <[EMAIL PROTECTED]> References : http://bugzilla.kernel.org/show_bug.cgi?id=9264 Handled-By : Patch : Subject : Device mapper regression 2.6.23 vs. v2.6.23-6597-gcfa76f0 Submitter : Thomas Meyer <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/21/153 http://bugzilla.kernel.org/show_bug.cgi?id=9280 Handled-By : Patch : Subject : [2.6.24-rc1][BUG] Oops on battery removal Submitter : Rolf Eike Beer <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/11/2/23 http://bugzilla.kernel.or
Re: dio_get_page() lockdep complaints
On Fri, 2007-11-09 at 12:45 -0500, Trond Myklebust wrote:
> On Fri, 2007-11-09 at 09:30 -0800, Zach Brown wrote:
> > So, reiserfs and NFS are nesting i_mutex inside the mmap_sem.
> >
> > >>[] mutex_lock+0x1c/0x1f
> > >>[] reiserfs_file_release+0x54/0x447
> > >>[] __fput+0x53/0x101
> > >>[] fput+0x19/0x1c
> > >>[] remove_vma+0x3b/0x4d
> > >>[] do_munmap+0x17f/0x1cf
> >
> > >[] _mutex_lock+0x28/0x34
> > >[] nfs_revalidate_mapping+0x6d/0xac [nfs]
> > >[] nfs_file_mmap+0x5c/0x74 [nfs]
> > >[] do_mmap_pgoff+0x51a/0x817
> > >[] sys_mmap+0x90/0x119
> >
> > I think i_mutex is fundamentally nested outside of the mmap_sem because
> > of faulting in the buffered write path. I think these warnings could be
> > reproduced with a careful test app which tries buffered writes from an
> > address which will fault.
> >
> > DIO just tripped it up because it *always* performs get_user_pages() on
> > the memory.
> >
> > So reiser and NFS need to be fixed. No?
>
> Actually, it is rather mmap() needs to be fixed. It is cold calling the
> filesystem while holding all sorts of nasty locks. It needs to be
> migrated to the same sort of syscall layout as read() and write().
>
> You _first_ call the filesystem so that it can make whatever
> preparations it needs outside the lock. The filesystem then calls the
> VM, which can then call the filesystem back if needed.
Right, which gets us into all kinds of trouble because some sites need
mmap_sem to resolve some races, notably s390 31-bit and shm.
Quick proto-type that moves mmap_sem into do_mmap{,_pgoff} and provides
_locked functions for those few icky sites.
The !_locked functions also call f_op->mmap_prepare() before taking the
mmap_sem. Which makes for some ugly asymetry :-/
Anyway, I'm not comming up with anything nicer atm, hopefully a nice
idea will present itself soon.
(compile tested only - mostly for illustrational purposes)
Not-signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
arch/alpha/kernel/osf_sys.c |2 -
arch/arm/kernel/sys_arm.c |2 -
arch/avr32/kernel/sys_avr32.c |2 -
arch/blackfin/kernel/sys_bfin.c |2 -
arch/cris/kernel/sys_cris.c |2 -
arch/frv/kernel/sys_frv.c |4 --
arch/h8300/kernel/sys_h8300.c |4 --
arch/ia64/ia32/sys_ia32.c | 30 +---
arch/ia64/kernel/sys_ia64.c |2 -
arch/m32r/kernel/sys_m32r.c |2 -
arch/m68k/kernel/sys_m68k.c |4 --
arch/m68knommu/kernel/sys_m68k.c|2 -
arch/mips/kernel/irixelf.c | 10 -
arch/mips/kernel/linux32.c |2 -
arch/mips/kernel/syscall.c |2 -
arch/mips/kernel/sysirix.c |5 --
arch/parisc/kernel/sys_parisc.c |2 -
arch/powerpc/kernel/syscalls.c |2 -
arch/s390/kernel/compat_linux.c |5 +-
arch/s390/kernel/sys_s390.c |2 -
arch/sh/kernel/sys_sh.c |2 -
arch/sh64/kernel/sys_sh64.c |2 -
arch/sparc/kernel/sys_sparc.c |2 -
arch/sparc/kernel/sys_sunos.c |2 -
arch/sparc64/kernel/binfmt_aout32.c |6 ---
arch/sparc64/kernel/sys_sparc.c |2 -
arch/sparc64/kernel/sys_sunos32.c |2 -
arch/sparc64/solaris/misc.c |2 -
arch/um/kernel/syscall.c|2 -
arch/v850/kernel/syscalls.c |2 -
arch/x86/ia32/ia32_aout.c |6 ---
arch/x86/ia32/sys_ia32.c|5 --
arch/x86/kernel/sys_i386_32.c |2 -
arch/x86/kernel/sys_x86_64.c|2 -
arch/xtensa/kernel/syscall.c|2 -
drivers/char/drm/drm_bufs.c |4 --
drivers/char/drm/i810_dma.c |2 -
fs/aio.c|4 +-
fs/binfmt_aout.c|6 ---
fs/binfmt_elf.c |6 ---
fs/binfmt_elf_fdpic.c |9
fs/binfmt_flat.c|6 +--
fs/binfmt_som.c |6 ---
fs/nfs/file.c | 25 +
include/linux/fs.h |1
include/linux/mm.h | 13 ++-
ipc/shm.c |2 -
mm/mmap.c | 65 +---
48 files changed, 109 insertions(+), 169 deletions(-)
Index: linux-2.6-2/arch/alpha/kernel/osf_sys.c
===
--- linux-2.6-2.orig/arch/alpha/kernel/osf_sys.c
+++ linux-2.6-2/arch/alpha/kernel/osf_sys.c
@@ -193,9 +193,7 @@ osf_mmap(unsigned long addr, unsigned lo
goto out;
}
flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE);
- down_write(¤t->mm->mmap_sem);
ret = do_mmap(file, addr, len, prot, flags, off);
- up_write(¤t->mm->mmap_sem);
if (file)
fput(file);
out:
Index: linux-2.6-2/arch/arm/kernel/sys_ar
Race in setup_irq?
I am writing a device driver for the Dreamcast CD Drive (the "GD Rom")
and I am hitting what looks like some sort of race in
kernel/irq/manage.c. Can anybody point me in the right direction or is
there a bug here?
This never seems to return in setup_irq:
spin_unlock_irqrestore(&desc->lock, flags);
(line 597)
I cannot see any reason why it would fail, though. And I know how
difficult these things are to debug - but if I put a printk either
side, it works for all interrupt set ups, but not this one.
Here is the calling code:
static int gdrom_set_command_interrupt_handler(void)
{
int err;
#ifdef GDROMDEBUG
printk("%s\n", __FUNCTION__);
#endif
/* need a queue to wait in */
init_waitqueue_head(&command_queue);
err = request_irq(HW_EVENT_GDROM_CMD, gdrom_command_interrupt,
IRQF_PROBE_SHARED, "gdrom", gd.disk);
if (err)
return -err;
#ifdef GDROMDEBUG
printk("Interrupt is registered\n");
#endif
return 0;
}
Here is the .config file:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc2
# Sun Nov 11 17:50:05 2007
#
CONFIG_SUPERH=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_SYS_SUPPORTS_PCI=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_ARCH_NO_VIRT_TO_BUS=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# System type
#
CONFIG_CPU_SH4=y
# CONFIG_CPU_SUBTYPE_SH7619 is not set
# CONFIG_CPU_SUBTYPE_SH7206 is not set
# CONFIG_CPU_SUBTYPE_SH7705 is not set
# CONFIG_CPU_SUBTYPE_SH7706 is not set
# CONFIG_CPU_SUBTYPE_SH7707 is not set
# CONFIG_CPU_SUBTYPE_SH7708 is not set
# CONFIG_CPU_SUBTYPE_SH7709 is not set
# CONFIG_CPU_SUBTYPE_SH7710 is not set
# CONFIG_CPU_SUBTYPE_SH7712 is not set
# CONFIG_CPU_SUBTYPE_SH7720 is not set
# CONFIG_CPU_SUBTYPE_SH7750 is not set
CONFIG_CPU_SUBTYPE_SH7091=y
# CONFIG_CPU_SUBTYPE_SH7750R is not set
# CONFIG_CPU_SUBTYPE_SH7750S is not set
# CONFIG_CPU_SUBTYPE_SH7751 is not set
# CONFIG_CPU_SUBTYPE_SH7751R is not set
# CONFIG_CPU_SUBTYPE_SH7760 is not set
# CONFIG_CPU_SUBTYPE_SH4_202 is not set
# CONFIG_CPU_SUBTYPE_SH7770 is not set
# CONFIG_CPU_SUBTYPE_SH7780 is not set
# CONFIG_CPU_SUBTYPE_SH7785 is not set
# CONFIG_CPU_SUBTYPE_SHX3 is not set
# CONFIG_CPU_SUBTYPE_SH7343 is not set
# CONFIG_CPU_SUBTYPE_SH7722 is not set
#
# Memory management options
#
CONFIG_QUICKLIST=y
CONFIG_MMU=y
CONFIG_PAGE_OFFSET=0x8000
CONFIG_MEMORY_START=0x0c00
CONFIG_MEMORY_SIZE=0x0100
CONFIG_VSYSCALL=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_MAX_ACTIVE_REGIONS=1
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_PAGE_SIZE_4KB=y
# CONFIG_PAGE_SIZE_8KB is not set
# CONFIG_PAGE_SIZE_64KB is not set
CONFIG_HUGETLB_PAGE_SIZE_64K=y
# CONFIG_HUGETLB_PAGE_SIZE_256K is not set
# CONFIG_HUGETLB_PAGE_SIZE_1MB is not set
# CONFIG_HUGETLB_PAGE_
Re: [PATCH] Unionfs: stop using iget() and read_inode()
On Sun, 11 Nov 2007 13:38:04 -0500 Erez Zadok <[EMAIL PROTECTED]> wrote: > Andrew, the following small patch is critical to have after: > > iget-stop-unionfs-from-using-iget-and-read_inode.patch Thanks > Question: since the above patch isn't in my unionfs.git tree (not until the > whole iget series makes it to Linus), then do you prefer if I give you a > replacement patch to the above patch, or a small incremental one; either > way, you can choose to fold the above and below patches into one. Incrementals are usually preferred. But it's usually more convenient for the originator to generate a new patch, and I will almost always turn that into an incremental so that I can review what was changed. The downside to this is that nobody else will be able to see what was changed. So there are pros and cons and I'm not particularly fussed either way, really. But if a patch is large and has already had some testing and review and has been in -mm for a while then that's when wholesale replacement becomes problematic: it pretty much sets us back to square one. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1: pata_acpi fails to activate DMA for DVD-ROM on ALi M5229 secondary channel
> BTW in rc2 it does not even boot - it babbles something about > Unable to determine IRQ for 00:04.0 (which is IDE controller) and that is > the end of story. No IDE device is found. Thats not an IDE breakage I suspect. Various people are reporting IRQ related breakage with -rc2 so you should probably report that to the main linux-kernel list Doesn't explain the ALi DMA problem but I think its unrelated Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Reported regressions from 2.6.23 (updated)
> Subject : 2.6.24-rc1: pata_acpi fails to activate DMA for > DVD-ROM on ALi M5229 secondary channel > Submitter : Andrey Borzenkov <[EMAIL PROTECTED]> > References: http://marc.info/?l=linux-kernel&m=119342005216716&w=2 > http://bugzilla.kernel.org/show_bug.cgi?id=9252 > Handled-By: Alan Cox <[EMAIL PROTECTED]> > Patch : > Note : pata_acpi was not present in 2.6.23 As I said before pata_acpi was not present in 2.6.23 -> Not a regression. WONTFIX for 2.6.24. Not actually clear it is even a bug, the interactions between using pata_acpi and simplex controllers are not documented anywhere 8( > Subject : 2.6.24-rc1: pata_amd fails to detect 80-pin wire > Submitter : "Thomas Lindroth" <[EMAIL PROTECTED]> > References: http://lkml.org/lkml/2007/11/7/152 > http://bugzilla.kernel.org/show_bug.cgi?id=9322 Tejun is looking into this - its not trivial so may be 2.6.25 material. Similar reports for some other controllers (notably VIA). > Subject : cd/dvd inaccessible in 2.6.24-rc2 > Submitter : Will Trives <[EMAIL PROTECTED]> > References: http://lkml.org/lkml/2007/11/9/290 > http://bugzilla.kernel.org/show_bug.cgi?id=9346 > Handled-By: Alan Cox <[EMAIL PROTECTED]> > Jeff Garzik <[EMAIL PROTECTED]> Not sure who is handling this now - seems to be an IRQ routing bug introduced in -rc2. I've got a pile of similar breakage reports for random ATA controllers. Thanks Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: Add EXPORT_SYMBOL for symbols required by fs_enet and cpm_uart
On Sun, Nov 11, 2007 at 06:01:37PM +0100, Jochen Friedrich wrote: > --- a/arch/powerpc/sysdev/commproc.c > +++ b/arch/powerpc/sysdev/commproc.c > @@ -51,6 +51,8 @@ static void m8xx_cpm_dpinit(void); > static uint host_buffer; /* One page of host buffer */ > static uint host_end;/* end + 1 */ > cpm8xx_t __iomem *cpmp; /* Pointer to comm processor space */ > +EXPORT_SYMBOL(cpmp); Sorry, but this is a nightmare waiting to happen. Please define proper accessors instead. (And get rid of the typedef while you're at it) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Reported regressions from 2.6.23 (updated)
On Sunday, 11 of November 2007, Alan Cox wrote: > > Subject : 2.6.24-rc1: pata_acpi fails to activate DMA for > > DVD-ROM on ALi M5229 secondary channel > > Submitter : Andrey Borzenkov <[EMAIL PROTECTED]> > > References : http://marc.info/?l=linux-kernel&m=119342005216716&w=2 > > http://bugzilla.kernel.org/show_bug.cgi?id=9252 > > Handled-By : Alan Cox <[EMAIL PROTECTED]> > > Patch : > > Note: pata_acpi was not present in 2.6.23 > > As I said before pata_acpi was not present in 2.6.23 -> Not a regression. OK, dropped. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23: no more free evdev devices - evdev leak?
On Tue, 2007-11-06 at 15:52 +0100, Jiri Kosina wrote: > On Tue, 6 Nov 2007, Dmitry Torokhov wrote: > > > Could you please try sticking a printk in > > hidinput_disconnect(drivers/hid/hid-input.c) to verify that > > input_unregister_device is in fact being called? > > Also, is 2.6.23 the only kernel you are experiencing this with please? So far yes. I am now on 2.6.24rc2 and although the input device numbers steadily increase s2ram does reliably work even when done >10 times in a row and no problems with evdev devices not being available. However resume is slower as some ata device (I think my cdrom) is timing out. So it could be related to a too fast resume from suspend. So the problem may re-appear if matthew garrets fix for [PATCH] Don't fail ata device revalidation for bad _GTF methods will be committed. Is there still a need to do tests with the printk's in 2.6.23? Soeren - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Reported regressions from 2.6.23 (updated)
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > Subject : [regression] v2.6.24-rc1-497-gb1d08ac: kde battery > icon gone > Submitter : Thomas Meyer <[EMAIL PROTECTED]> > References: http://lkml.org/lkml/2007/11/2/165 > http://bugzilla.kernel.org/show_bug.cgi?id=9297 > Handled-By: Andrey Borzenkov <[EMAIL PROTECTED]> > Ingo Molnar <[EMAIL PROTECTED]> > Patch : > Note : goes away if ACPI_PROCFS is set should be fixed by acpi-make-acpi_procfs-default-to-y.patch in -mm. (not yet upstream i think, but should before v2.6.24) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Reported regressions from 2.6.23 (updated)
Rafael J. Wysocki <[EMAIL PROTECTED]> : > [Note: Due to git.kernel.org not responding I'm unable to check which fixes > have already been merged since the last report.] [...] > Subject : 2.6.24-rc1 kills onboard r8169 (rtl8111b) NIC > Submitter : "Sergey S. Kostyliov" <[EMAIL PROTECTED]> > References: http://lkml.org/lkml/2007/10/28/144 > http://bugzilla.kernel.org/show_bug.cgi?id=9257 > Handled-By: Francois Romieu <[EMAIL PROTECTED]> > Patch : http://bugzilla.kernel.org/attachment.cgi?id=13441&action=view Fixed and merged in Linus's tree as: - 50d84c2dc00e48ff9ba018ed0dd23276cf79e566 - b9d04e2401bf308df921d3bbbdacab40fadc27bb -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] v2.6.24-rc1-497-gb1d08ac: kde battery icon gone
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > See this commit: > > > > commit fb804714560463534ebcb538a3b0a3c687a830ec > > Author: Len Brown <[EMAIL PROTECTED]> > > Date: Tue Jul 24 01:50:46 2007 -0400 > > > > ACPI: Kconfig: CONFIG_ACPI_PROCFS now defaults to N > > > > delete "default y" from CONFIG_ACPI_PROCFS > > (effectively making the default 'N') > > > > List exactly what /proc files this option controls, > > and clarify that it doesn't change non-deprecated files. > > > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > > > So at least battery change should have added /proc/acpi/battery to this > > list. > > IMHO, the source of the problem is the battery change that has > introduced the dependency on ACPI_PROCFS _although_ it's unset by > default and that is a regression (ie. confuses users with older user > space). "older user space" meaning just about every Linux box that is out there at the moment. So this is a regression, the user does not care why it happened, and needs fixing. > > May be we need separate ACPI_PROCFS_xxx for every subsystem. > > Well, I'm not sure. I think that documenting the dependency should be > sufficient. No. We never remove a bit of relied-on API from the kernel like that. At minimum it must go through a long deprecation cycle before it's turned off by default. Really, is this some sort of weird "how can we piss off and lose as many beta testers as possible in the shortest amount of time" contest? Will people search for a few new lines of documentation (out of the 1 million lines of kernel code that 2.6.24 changes) when 'make oldconfig' breaks their laptop setup - or will they just go over to a more tester-friendly project? Compatibility is our utmost priority (and your regressions list is a very good tool for us to keep compatibility), especially in an incredibly easy case like this where the fix is 1 changed byte with no harm done to anyone. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/capability.c get_task_comm compile error (MMOTM)
* Erez Zadok <[EMAIL PROTECTED]> wrote:
> Ingo, I don't see how it can return NULL. This is what get_task_comm
> looks like in MMOTM-2007-11-10-19-05:
>
> char *get_task_comm(char *buf, struct task_struct *tsk)
> {
> /* buf must be at least sizeof(tsk->comm) in size */
> task_lock(tsk);
> strncpy(buf, tsk->comm, sizeof(tsk->comm));
> task_unlock(tsk);
> return buf;
> }
>
> The only way it'd return NULL is if a null buf was passed, in which
> case the strncpy will oops first.
hm, here it says in include/linux/sched.h:
extern void get_task_comm(char *to, struct task_struct *tsk);
HEAD ecd744eec3a.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFC] improved hacks to allow -rt to run kernbench on POWER
On Sun, 2007-11-11 at 09:45 -0500, Steven Rostedt wrote: > > Well, I suppose the patch could go in, maybe with some ifdef's > around > > the bits in _switch_to, there's little point in doing that on non-rt > > kernels. > > As Nick Piggin already stated, and I'll even state it for the RT > kernel, > we do not allow preemption in switch_to. So it is safe to remove those > "preempt_disable" bits from the patch Sure, I know that, I'm not talking about that, I'm talking about the added code that flush pending batches & save the batch state, since on non-rt kernel, this is not useful (the batch is only ever active within a spinlocked section, which cannot be preempted on non-rt). Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/11 v3] enable "make ARCH=x86"
Theodore Tso <[EMAIL PROTECTED]> wrote: > On Sat, Nov 10, 2007 at 12:35:01PM -0800, H. Peter Anvin wrote: >> In fact, we should be able to get rid of ARCH entirely; CONFIG_ options >> have the huge advantage that they're saved in a file, and you don't have to >> type them on every make run. The only option that I can't see us getting >> rid of easily is HOSTCC, since it is used before config is run, but >> probably something clever can be done there, too. > Yes, please! One of the more annoying things is forgetting the > ARCH=um when rebuilding UML. It would be awfully nice if ARCH was set > via a CONFIG_ option and was persistent. This should have been fixed, or it's about to be fixed. My patch is here: http://groups.google.com/group/linux.kernel/browse_thread/thread/93e5c33fc6e8cff6/39aff558a636ad02 (This patch was superseded by another patch, which may be delayed or mm-only.) OTOH, if you can implement ARCH= using CONFIG_ARCH, why not? Just don't forget to keep the scripts running, and make randconfig only select buildable archs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Race in setup_irq?
On 11/11/2007, Adrian McMenamin <[EMAIL PROTECTED]> wrote > I am writing a device driver for the Dreamcast CD Drive (the "GD Rom") > and I am hitting what looks like some sort of race in > kernel/irq/manage.c. Can anybody point me in the right direction or is > there a bug here? > > This never seems to return in setup_irq: > > spin_unlock_irqrestore(&desc->lock, flags); > > (line 597) I guess, you are referring to setup_irq() (the line without a particular kernel version doesn't make much sense). What do you mean by "never seems to return"? Does your machine hang? If so, the reason might be some kind of (logical) error in your ISR. spin_unlock_irqrestore() unmasks the interrupts and your target device might have already generated an interrupt by this moment (sure, it depends on the initialization logic of your code and device spec.)... --> ISR runs and due to some error e.g. loops endlessly/deadlocks/etc. Tried placing printk() at the beginning of ISR? -- Best regards, Dmitry Adamushko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Race in setup_irq?
On 11/11/2007, Dmitry Adamushko <[EMAIL PROTECTED]> wrote: > On 11/11/2007, Adrian McMenamin <[EMAIL PROTECTED]> wrote > > I am writing a device driver for the Dreamcast CD Drive (the "GD Rom") > > and I am hitting what looks like some sort of race in > > kernel/irq/manage.c. Can anybody point me in the right direction or is > > there a bug here? > > > > This never seems to return in setup_irq: > > > > spin_unlock_irqrestore(&desc->lock, flags); > > > > (line 597) > > I guess, you are referring to setup_irq() (the line without a > particular kernel version doesn't make much sense). > Sorry, it was in the config: 2.6.24-rc2 > What do you mean by "never seems to return"? Does your machine hang? > > If so, the reason might be some kind of (logical) error in your ISR. > spin_unlock_irqrestore() unmasks the interrupts and your target device > might have already generated an interrupt by this moment (sure, it > depends on the initialization logic of your code and device spec.)... > --> ISR runs and due to some error e.g. loops endlessly/deadlocks/etc. > > Tried placing printk() at the beginning of ISR? > You are absolutely right. Sorry for wasting evetybody's time and thanks for the tip! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading
kernel config attached to comment#2 for bugreport 9345 s2disk comes from suspend-0.7 package Thanks, Chris On Sun, 11 Nov 2007 19:45:06 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Saturday, 10 of November 2007, Chris Friedhoff wrote: > > please cc me, I'm not not subscribed to LKML > > > > Hello, > > > > with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but > > when I start the system and the suspended systemimage is loaded, it > > fails to "activate" this suspended systemimage and continues after some > > time with following the normal boot sequence. > > > > I can sucessfully STD the system with the following sequence > > echo platform > /sys/power/disk > > echo disk > /sys/power/state > > and when I start the laptop the suspended system is sucessfully > > restored. > > > > Both behaviors are reliable reproducable. > > Thanks for the report. > > > googling for >"Freezing of tasks failed" swapper< brought > > "Nigel Cunningham - PID namespaces break initrd+hibernate combination?" > > http://lkml.org/lkml/2007/11/4/140 > > Yes, this looks similarly. > > > dmesg output: > > <> > > RAMDISK: ext2 filesystem found at block 0 > > RAMDISK: Loading 2000KiB [1 disk] into ram disk... done. > > EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > > VFS: Mounted root (ext2 filesystem). > > swsusp: Marking nosave pages: 0009f000 - 0010 > > swsusp: Basic memory bitmaps created > > Clocksource tsc unstable (delta = -128791628 ns) > > Syncing filesystems ... done. > > Freezing user space processes ... (elapsed 0.00 seconds) done. > > Freezing remaining freezable tasks ... > > Freezing of tasks failed after 20.00 seconds (1 tasks refusing to > > freeze): taskPC stack pid father > > swapper S c1835a88 0 1 0 > > 0046 c0118c80 c1835a88 0004 0001 c011e875 > > 0286 c01025a6 c1835b64 c1835a90 > > 0001 007b c1835a90 > > c0118c80 Call Trace: > > [] default_wake_function+0x0/0x10 > > [] do_wait+0x335/0xac0 > > [] kernel_thread+0x96/0xb0 > > [] default_wake_function+0x0/0x10 > > [] sys_wait4+0x31/0x40 > > [] initrd_load+0x1b3/0x3a0 > > [] prepare_namespace+0x98/0x1b0 > > [] sys_access+0x1f/0x30 > > [] kernel_init+0x166/0x260 > > [] ret_from_fork+0x6/0x1c > > [] kernel_init+0x0/0x260 > > [] kernel_init+0x0/0x260 > > [] kernel_thread_helper+0x7/0x18 > > === > > kthreadd S 038f 0 2 0 > > 0046 c0487790 038f c183ff1c c012d81b > > c012d7b0 c0104b8f > > > > Call Trace: > > [] kthreadd+0x6b/0xd0 > > [] kthreadd+0x0/0xd0 > > [] kernel_thread_helper+0x7/0x18 > > === > > ksoftirqd/0 S 0 3 2 > > 0046 fffc c0120f00 c0120f7a > > c012d782 c012d740 c0104b8f c183ff3c > > > > Call Trace: > > [] ksoftirqd+0x0/0x80 > > [] ksoftirqd+0x7a/0x80 > > [] kthread+0x42/0x70 > > [] kthread+0x0/0x70 > > [] kernel_thread_helper+0x7/0x18 > > > > <> > > Can you please attach your kernel configuration file to the bugzilla entry > at http://bugzilla.kernel.org/show_bug.cgi?id=9345 ? > > Thanks, > Rafael Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bind mount bug?
Hi Frans! Let's see whether I can explain this (I'm not a guru...) On 11 Nov 2007, at 11:06, Frans Pop wrote: I'm not sure whether this is a bug or expected behavior. Suppose I create a "looped" bind mount situation as follows. # mkdir test # touch test/foo # mkdir bindtest # touch bindtest/bar # mkdir bindtest/test # mount --bind test/ bindtest/test/ # ls bindtest/test/ foo # mount --bind bindtest/ test/ This mounts the bindtest/ tree on test/ _without_ copying the mount points which are found on subtrees. This is necessary to avoid loops in the filesystem (bind mounts are somewhat like hardlinks on directories, just without the headaches). # ls test/ bar test # ls test/test/ # This lists the contents of the original bintest/test/ directory which you created above. Creating e.g. a file in there stores that file physically in bindtest/test/bla, where "test" does _not_ mean the bind mount but the underlying directory here. I'd expected the last command to list "foo", but it shows an empty dir. Shouldn't it also show the original contents of test (as they were before the first bind mount)? # mount | grep test /root/test on /root/bindtest/test type none (rw,bind) /root/bindtest on /root/test type none (rw,bind) You see, the bindtest/test/ mount was not propagated to test/test/. This is very much by design. You can e.g. do # mkdir -p test/test # mount --bind test test/test # ls test/test test # ls test/test/test # so there is no loop (`find test` would actually say that it terminates because it has detected a loop, so it cannot be used to test this). # touch test/test/test/a # ls test/test/test a # ls test/test # umount test/test # ls test/test a # So, you see, test/test/test/a was (as it should) physically created in test/test, where it is shadowed by the bind mount as long as that is not removed. Nothing vanishes into "thin air" ;-) Ciao, Roland -- TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching Telefon 089/289-12575; Telefax 089/289-12570 -- CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482 -- Any society that would give up a little liberty to gain a little security will deserve neither and lose both. - Benjamin Franklin -BEGIN GEEK CODE BLOCK- Version: 3.12 GS/CS/M/MU d-(++) s:+ a-> C+++ UL P+++ L+++ E(+) W+ !N K- w--- M + !V Y+ PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++> h y+++ --END GEEK CODE BLOCK-- PGP.sig Description: This is a digitally signed message part
Re: 2.6.24-rc2: Reported regressions from 2.6.23 (updated)
On Sunday 11 November 2007, Alan Cox wrote:
> > Subject : 2.6.24-rc1: pata_amd fails to detect 80-pin wire
> > Submitter : "Thomas Lindroth" <[EMAIL PROTECTED]>
> > References : http://lkml.org/lkml/2007/11/7/152
> > http://bugzilla.kernel.org/show_bug.cgi?id=9322
http://lkml.org/lkml/2007/10/12/537
The regression itself has been foreseen a month ago and it is quite
sad that it is still not fixed...
> Tejun is looking into this - its not trivial so may be 2.6.25 material.
> Similar reports for some other controllers (notably VIA).
We may fix the regression in a bit different way for now and give Tejun
some more time for the complete rework of the cable detection code.
[PATCH] pata_amd/pata_via: de-couple programming of PIO/MWDMA and UDMA timings
* Don't program UDMA timings when programming PIO or MWDMA modes.
This has also a nice side-effect of fixing regression added by commit
681c80b5d96076f447e8101ac4325c82d8dce508 ("libata: correct handling of
SRST reset sequences") (->set_piomode method for PIO0 is called before
->cable_detect method which checks UDMA timings to get the cable type).
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
Untested, please don't merge until it is confirmed to fix the problem.
drivers/ata/pata_amd.c |5 +++--
drivers/ata/pata_via.c |4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
Index: b/drivers/ata/pata_amd.c
===
--- a/drivers/ata/pata_amd.c
+++ b/drivers/ata/pata_amd.c
@@ -25,7 +25,7 @@
#include
#define DRV_NAME "pata_amd"
-#define DRV_VERSION "0.3.9"
+#define DRV_VERSION "0.3.10"
/**
* timing_setup- shared timing computation and load
@@ -115,7 +115,8 @@ static void timing_setup(struct ata_port
}
/* UDMA timing */
- pci_write_config_byte(pdev, offset + 0x10 + (3 - dn), t);
+ if (at.udma)
+ pci_write_config_byte(pdev, offset + 0x10 + (3 - dn), t);
}
/**
Index: b/drivers/ata/pata_via.c
===
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -63,7 +63,7 @@
#include
#define DRV_NAME "pata_via"
-#define DRV_VERSION "0.3.2"
+#define DRV_VERSION "0.3.3"
/*
* The following comes directly from Vojtech Pavlik's ide/pci/via82cxxx
@@ -296,7 +296,7 @@ static void via_do_set_mode(struct ata_p
}
/* Set UDMA unless device is not UDMA capable */
- if (udma_type) {
+ if (udma_type && t.udma) {
u8 cable80_status;
/* Get 80-wire cable detection bit */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] init/calibrate.c compile error (MMOTM-2007-11-10-19-05)
I'm using -mm (MMOTM-2007-11-10-19-05) and getting $ make CC init/calibrate.o In file included from include/linux/jiffies.h:8, from init/calibrate.c:7: include/linux/timex.h:246: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'read_current_timer' init/calibrate.c: In function 'calibrate_delay_direct': init/calibrate.c:41: error: implicit declaration of function 'read_current_timer' make[1]: *** [init/calibrate.o] Error 1 make: *** [init] Error 2 That's because the definition of __devinit isn't known at that point. The following small patch appears to fix the compilation error. Someone should verify that it's the proper fix. Cheers, Erez. Signed-off-by: Erez Zadok <[EMAIL PROTECTED]> diff --git a/include/linux/timex.h b/include/linux/timex.h index 40383f9..57bb18c 100644 --- a/include/linux/timex.h +++ b/include/linux/timex.h @@ -55,6 +55,7 @@ #include #include +#include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bind mount bug?
>> I'm not sure whether this is a bug or expected behavior. >> Suppose I create a "looped" bind mount situation as follows. >> >> # mkdir test >> # touch test/foo >> # mkdir bindtest >> # touch bindtest/bar >> # mkdir bindtest/test >> # mount --bind test/ bindtest/test/ >> # ls bindtest/test/ >> foo >> # mount --bind bindtest/ test/ > >This mounts the bindtest/ tree on test/ _without_ copying the mount >points which are found on subtrees. This is necessary to avoid loops >in the filesystem (bind mounts are somewhat like hardlinks on >directories, just without the headaches). What you seek is mount --rbind. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch/x86/kernel/setup_64.c compile error (MMOTM-2007-11-10-19-05)
I'm using -mm (MMOTM-2007-11-10-19-05) and getting $ make CC arch/x86/kernel/setup_64.o arch/x86/kernel/setup_64.c: In function 'setup_arch': arch/x86/kernel/setup_64.c:420: error: implicit declaration of function 'early_quirks' That's because the externs for early_quirks() aren't on unless CONFIG_ACPI is on, but the code in setup_64.c calls early_quirks() if CONFIG_PCI is on (and early-quirks.c is compiled only if CONFIG_PCI=y). I'm not sure if the small fix below is correct, hence no signed-off-by. But it seems to get the kernel compiling and linking at least. Someone should check. Cheers, Erez. diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c index 5a09161..64644d4 100644 --- a/arch/x86/kernel/setup_64.c +++ b/arch/x86/kernel/setup_64.c @@ -416,7 +416,7 @@ void __init setup_arch(char **cmdline_p) reserve_crashkernel(); paging_init(); -#ifdef CONFIG_PCI +#if defined(CONFIG_PCI) && defined(CONFIG_ACPI) early_quirks(); #endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bind mount bug?
On Sunday 11 November 2007, Roland Kuhn wrote: > This mounts the bindtest/ tree on test/ _without_ copying the mount > points which are found on subtrees. Right. I guess this is the key point that tripped me up. > So, you see, test/test/test/a was (as it should) physically created > in test/test, where it is shadowed by the bind mount as long as that > is not removed. Which means that to continue the example from my follw-up mail: > # ls bindtest/test > foo > # umount test > # ls test > foo # umount bindtest/test # ls bindtest/test baz And there indeed is the missing file. > Nothing vanishes into "thin air" ;-) Yeah, I saw that syntax error after sending the mail "into space" would have been OK too, but not my combining the two :-) Thanks for the explanation! Cheers, FJP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
