Re: Since sysfs_mount is static and used only in sysfs_init function, it could be just an automatic variable.
On Sun, Dec 02, 2007 at 02:52:17PM +0800, rae l wrote:
> On Dec 2, 2007 12:48 PM, Greg KH <[EMAIL PROTECTED]> wrote:
> ...
> > > and where is a detailed explaination on kern_mount? could someone give
> > > some comments or documentation pointers on this?
> >
> > See the patches that Eric Biederman just posted to lkml for why this
> > structure is a static pointer this way right now, it's in preparation
> > for future patches.
> I have checked commit 7d0c7d676cc066413e1583b5af9fba8011972d41 by Eric
> W. Biederman,
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7d0c7d676cc066413e1583b5af9fba8011972d41
>
> which just make sysfs_mount from externally visible to static that
> could be only used in one c file,
>
> but I mean that the static variable is still on kernel bss section,
> this consumes a pointer (4 or 8 bytes) memory,
>
> through a grep from fs/sysfs/, it appears that the variable
> sysfs_mount is only used in the sysfs_init function,
>
> $ grep -RsInw sysfs_mount fs/sysfs/
> fs/sysfs/mount.c:25:static struct vfsmount *sysfs_mount;
> fs/sysfs/mount.c:101: sysfs_mount = kern_mount(_fs_type);
> fs/sysfs/mount.c:102: if (IS_ERR(sysfs_mount)) {
> fs/sysfs/mount.c:104: err = PTR_ERR(sysfs_mount);
> fs/sysfs/mount.c:105: sysfs_mount = NULL;
>
> we could mark this variable an automatic one, which scope is just in
> this function, thus created and destroyed with the stack,
> this approach does not consume a pointer on kernel bss section,
>
> Why not do this?
Again, see the patches he _just_ posted to lkml, the specific message
you are looking for is:
Message-ID: <[EMAIL PROTECTED]>
Subject: [PATCH 01/10] sysfs: Make sysfs_mount static again.
Also see the whole long thread for more details.
If you have further questions about this, please ask Eric.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: blackfin compile error
On Sat, 1 Dec 2007 22:59:05 -0800 David Brownell <[EMAIL PROTECTED]> wrote: > On Saturday 01 December 2007, Bryan Wu wrote: > > On Dec 2, 2007 8:42 AM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > It seems commit 5d448dd50712ae42f8176b5bb8db4703bef6f0f5 was incomplete: > > > > > > <-- snip --> > > > > > > ... > > > CC arch/blackfin/mach-bf537/boards/stamp.o > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: > > > error: unknown field 'pin_req' specified in initializer > > > > Yes, there is a SPI patch adding the field 'pin_req' in a Blackfin SPI > > header file which is in -mm tree. > > > > David, could you please submit the Blackfin SPI update to mainline? > > So far as I know they're all ready for Andrew to get them to Linus... > I have all these: spi-at25-driver-is-for-eeprom-not-flash.patch spi-use-mutex-not-semaphore.patch spi-simplify-spi_sync-calling-convention.patch spi-use-simplified-spi_sync-calling-convention.patch # spi-initial-bf54x-spi-support.patch spi-bfin-spi-uses-portmux-calls.patch spi-spi_bfin-cleanups-error-handling.patch spi-spi_bfin-handles-spi_transfercs_change.patch spi-spi_bfin-dont-bypass-spi-framework.patch spi-spi_bfin-uses-platform-device-resources.patch spi-spi_bfin-uses-portmux-for-additional-busses.patch spi-spi_bfin-rearrange-portmux-calls.patch spi-spi_bfin-change-handling-of-communication-parameters.patch spi-spi_bfin-relocate-spin-waits.patch spi-spi_bfin-handle-multiple-spi_masters.patch spi-spi_bfin-bugfix-for-816-bit-word-sizes.patch spi-spi_bfin-update-handling-of-delay-after-deselect.patch spi-spi_bfin-resequence-dma-start-stop.patch # blackfin-spi-driver-use-cpu_relax-to-replace-continue-in-while-busywait.patch blackfin-spi-driver-use-void-__iomem-for-regs_base.patch blackfin-spi-driver-move-hard-coded-pin_req-to-board-file.patch blackfin-spi-driver-reconfigure-speed_hz-and-bits_per_word-in-each-spi-transfer.patch atmel_spi-throughput-improvement.patch atmel_spi-chain-dma-transfers.patch atmel_spi-fix-dmachain-oops-with-debug-enabled.patch queued for 2.6.25. If some of them need to be bumped up to 2.6.24: which ones and why? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: blackfin compile error
On Saturday 01 December 2007, Bryan Wu wrote: > On Dec 2, 2007 8:42 AM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > It seems commit 5d448dd50712ae42f8176b5bb8db4703bef6f0f5 was incomplete: > > > > <-- snip --> > > > > ... > > CC arch/blackfin/mach-bf537/boards/stamp.o > > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: > > error: unknown field 'pin_req' specified in initializer > > Yes, there is a SPI patch adding the field 'pin_req' in a Blackfin SPI > header file which is in -mm tree. > > David, could you please submit the Blackfin SPI update to mainline? So far as I know they're all ready for Andrew to get them to Linus... > > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: > > error: extra brace group at end of initializer > > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: > > error: (near initialization for 'bfin_spi0_info') > > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: > > warning: excess elements in struct initializer > > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: > > warning: (near initialization for 'bfin_spi0_info') > > make[2]: *** [arch/blackfin/mach-bf537/boards/stamp.o] Error 1 > > > > <-- snip --> > > > > cu > > Adrian > > > > -- > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Since sysfs_mount is static and used only in sysfs_init function, it could be just an automatic variable.
On Dec 2, 2007 12:48 PM, Greg KH <[EMAIL PROTECTED]> wrote:
...
> > and where is a detailed explaination on kern_mount? could someone give
> > some comments or documentation pointers on this?
>
> See the patches that Eric Biederman just posted to lkml for why this
> structure is a static pointer this way right now, it's in preparation
> for future patches.
I have checked commit 7d0c7d676cc066413e1583b5af9fba8011972d41 by Eric
W. Biederman,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7d0c7d676cc066413e1583b5af9fba8011972d41
which just make sysfs_mount from externally visible to static that
could be only used in one c file,
but I mean that the static variable is still on kernel bss section,
this consumes a pointer (4 or 8 bytes) memory,
through a grep from fs/sysfs/, it appears that the variable
sysfs_mount is only used in the sysfs_init function,
$ grep -RsInw sysfs_mount fs/sysfs/
fs/sysfs/mount.c:25:static struct vfsmount *sysfs_mount;
fs/sysfs/mount.c:101: sysfs_mount = kern_mount(_fs_type);
fs/sysfs/mount.c:102: if (IS_ERR(sysfs_mount)) {
fs/sysfs/mount.c:104: err = PTR_ERR(sysfs_mount);
fs/sysfs/mount.c:105: sysfs_mount = NULL;
we could mark this variable an automatic one, which scope is just in
this function, thus created and destroyed with the stack,
this approach does not consume a pointer on kernel bss section,
Why not do this?
--
Denis Cheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: blackfin compile error
On Dec 2, 2007 8:42 AM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > It seems commit 5d448dd50712ae42f8176b5bb8db4703bef6f0f5 was incomplete: > > <-- snip --> > > ... > CC arch/blackfin/mach-bf537/boards/stamp.o > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: > error: unknown field 'pin_req' specified in initializer Yes, there is a SPI patch adding the field 'pin_req' in a Blackfin SPI header file which is in -mm tree. David, could you please submit the Blackfin SPI update to mainline? > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: > error: extra brace group at end of initializer > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: > error: (near initialization for 'bfin_spi0_info') > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: > warning: excess elements in struct initializer > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: > warning: (near initialization for 'bfin_spi0_info') > make[2]: *** [arch/blackfin/mach-bf537/boards/stamp.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/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ACPI related Warning in 2.6.24-rc3-git2
Applied to ACPI tree.
Linus,
I reproduced this issue on my T61, and saw it go away w/ this patch.
I'll be sending you a pull request probably Sunday night w/ this
pach in it. But if you are in a hurry to cut rc4 before then,
consider this an Acked-by: Len Brown <[EMAIL PROTECTED]>
thanks,
-Len
On Thursday 29 November 2007 03:22, Zhao Yakui wrote:
> Subject: ACPI : Delete the IRQ operation in throttling controll via PTC
> >From : Zhao Yakui <[EMAIL PROTECTED]>
>
> The IRQ operation(enable/disable) should be avoided when throttling is
> controlled via PTC method. It is replaced by the migration of task.
>
> Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
>
> ---
> drivers/acpi/processor_throttling.c | 36
>
> 1 file changed, 28 insertions(+), 8 deletions(-)
>
> Index: linux-2.6.24-rc3-git3/drivers/acpi/processor_throttling.c
> ===
> --- linux-2.6.24-rc3-git3.orig/drivers/acpi/processor_throttling.c
> +++ linux-2.6.24-rc3-git3/drivers/acpi/processor_throttling.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -413,7 +414,7 @@ static int acpi_throttling_rdmsr(struct
> } else {
> msr_low = 0;
> msr_high = 0;
> - rdmsr_on_cpu(cpu, MSR_IA32_THERM_CONTROL,
> + rdmsr_safe(MSR_IA32_THERM_CONTROL,
> (u32 *)_low , (u32 *) _high);
> msr = (msr_high << 32) | msr_low;
> *value = (acpi_integer) msr;
> @@ -438,7 +439,7 @@ static int acpi_throttling_wrmsr(struct
> "HARDWARE addr space,NOT supported yet\n");
> } else {
> msr = value;
> - wrmsr_on_cpu(cpu, MSR_IA32_THERM_CONTROL,
> + wrmsr_safe(MSR_IA32_THERM_CONTROL,
> msr & 0x, msr >> 32);
> ret = 0;
> }
> @@ -572,21 +573,32 @@ static int acpi_processor_get_throttling
> return -ENODEV;
>
> pr->throttling.state = 0;
> - local_irq_disable();
> +
> value = 0;
> ret = acpi_read_throttling_status(pr, );
> if (ret >= 0) {
> state = acpi_get_throttling_state(pr, value);
> pr->throttling.state = state;
> }
> - local_irq_enable();
>
> return 0;
> }
>
> static int acpi_processor_get_throttling(struct acpi_processor *pr)
> {
> - return pr->throttling.acpi_processor_get_throttling(pr);
> + cpumask_t saved_mask;
> + int ret;
> +
> + /*
> + * Migrate task to the cpu pointed by pr.
> + */
> + saved_mask = current->cpus_allowed;
> + set_cpus_allowed(current, cpumask_of_cpu(pr->id));
> + ret = pr->throttling.acpi_processor_get_throttling(pr);
> + /* restore the previous state */
> + set_cpus_allowed(current, saved_mask);
> +
> + return ret;
> }
>
> static int acpi_processor_get_fadt_info(struct acpi_processor *pr)
> @@ -717,21 +729,29 @@ static int acpi_processor_set_throttling
> if (state < pr->throttling_platform_limit)
> return -EPERM;
>
> - local_irq_disable();
> value = 0;
> ret = acpi_get_throttling_value(pr, state, );
> if (ret >= 0) {
> acpi_write_throttling_state(pr, value);
> pr->throttling.state = state;
> }
> - local_irq_enable();
>
> return 0;
> }
>
> int acpi_processor_set_throttling(struct acpi_processor *pr, int state)
> {
> - return pr->throttling.acpi_processor_set_throttling(pr, state);
> + cpumask_t saved_mask;
> + int ret;
> + /*
> + * Migrate task to the cpu pointed by pr.
> + */
> + saved_mask = current->cpus_allowed;
> + set_cpus_allowed(current, cpumask_of_cpu(pr->id));
> + ret = pr->throttling.acpi_processor_set_throttling(pr, state);
> + /* restore the previous state */
> + set_cpus_allowed(current, saved_mask);
> + return ret;
> }
>
> int acpi_processor_get_throttling_info(struct acpi_processor *pr)
>
> On Wed, 2007-11-28 at 14:42 +0800, Pallipadi, Venkatesh wrote:
> > Yakui,
> >
> > Can you look at this. Seems to be coming from commit f79f06ab9f86
> > FixedHW support tries to read MSR with interrupts disabled.
> >
> > Thanks,
> > Venki
> >
> > >-Original Message-
> > >From: [EMAIL PROTECTED]
> > >[mailto:[EMAIL PROTECTED] On Behalf Of
> > >Rafael J. Wysocki
> > >Sent: Tuesday, November 27, 2007 7:37 AM
> > >To: Lukas Hejtmanek
> > >Cc: linux-kernel@vger.kernel.org; ACPI Devel Maling List; Len
> > >Brown; Alexey Starikovskiy
> > >Subject: Re: ACPI related Warning in 2.6.24-rc3-git2
> > >
> > >On Tuesday, 27 of November 2007, Lukas Hejtmanek wrote:
> > >> Hello,
> > >>
> > >> in recent kernel, I got the following warnings while
> > >booting. It's ACPI
> > >> related. Does anybode care? Lenovo ThinkPad T61 (6465CTO).
> > >
> > >Appropriate Ccs added.
> > >
Re: 2.6.23.9, make install doesn't work with grub anymore??
On Sat, 1 Dec 2007 20:51:14 -0500 Scott Noone <[EMAIL PROTECTED]> wrote: > > Hello, > > I downloaded the vanilla kernels 2.6.23.8 and 2.6.23.9 from > kernel.org. I unpacked them like I have every other kernel release. > I compiled the kernel successfully, did the make modules and make > modules_install with no problems. When I did the make install I am > told it Cannot find LILO. The message seems to come > from /usr/src/linux-2.6.23.9/arch/i386/boot/install.sh The script is > correct that I don't have lilo installed, I have used grub for quite > some time. I don't remember having this problem with older kernels, > sorry I don't remember one of the top of head. Did something change > or is: cp .config /usr/src/linux-2.6.23-9 make menuconfig make make > modules make modules_install make install no longer adequate to > compile and install a kernel? Hi, actually this isn't the fault of the kernel; the grub/lilo/etc stuff is done by a distro specific script that just gets called from make install... did you happen to change distros or update something like an initscripts or similar package recently? Greetings, Arjan van de Ven -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Since sysfs_mount is static and used only in sysfs_init function, it could be just an automatic variable.
On Sun, Dec 02, 2007 at 04:31:09AM +0800, rae l wrote: > --- > and I still have questions about this code: > 1. Why here kern_mount is needed? > Or the first time user space `mount -t sysfs` won't do that? > 2. If root executes many mounts to mount sysfs on /sys and many other places, > are there many instances of struct vfsmount those have only > mnt_mountpoint different? > > For most common case, mount a virtual filesystem(proc, sysfs, ...) on > multiple mounting point, > how to handle it more efficiently? > > and where is a detailed explaination on kern_mount? could someone give > some comments or documentation pointers on this? See the patches that Eric Biederman just posted to lkml for why this structure is a static pointer this way right now, it's in preparation for future patches. Hope this helps, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: namespace support requires network modules to say "GPL"
On Sat, 01 Dec 2007 22:34:09 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > Stephen Hemminger wrote: > > On Sat, 1 Dec 2007 11:17:36 -0800 > > Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > > >> Then init_net needs to be not GPL limited. Sorry, we need to allow > >> non GPL network drivers. There is a fine line between keeping the > >> binary seething masses from accessing random kernel functions, and allowing > >> reasonable (but still non GPL) things like ndiswrapper to use network > >> device interface. > >> > > I spoke too soon earlier, ndiswrapper builds and loads against current > > 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again > > I don't > > give a damn, but the enterprise distro vendors certainly care. > ... > > Naw, enterprise (or any other) distro vendors shouldn't have any issues here, > since they can just patch their kernels around any issues. > > But it looks like Eric has this one thought out well enough. So you are saying all this is not a problem, fine. Any affected parties can certainly lobby for themselves. But I suspect they all think the kernel community is a bunch of ... and will just ignore the problem. -- Stephen Hemminger <[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/
[PATCH] Remove superfluous checks for CONFIG_BLK_DEV_INITRD from initramfs.c.
Given that init/Makefile includes initramfs.c in the build only if
CONFIG_BLK_DEV_INITRD is defined, there seems to be no point checking
for it yet again.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
compile-tested on x86.
diff --git a/init/initramfs.c b/init/initramfs.c
index 1db02a0..d53fee8 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -503,7 +503,6 @@ static int __init retain_initrd_param(char *str)
__setup("retain_initrd", retain_initrd_param);
extern char __initramfs_start[], __initramfs_end[];
-#ifdef CONFIG_BLK_DEV_INITRD
#include
#include
@@ -539,15 +538,12 @@ skip:
initrd_end = 0;
}
-#endif
-
static int __init populate_rootfs(void)
{
char *err = unpack_to_rootfs(__initramfs_start,
__initramfs_end - __initramfs_start, 0);
if (err)
panic(err);
-#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start) {
#ifdef CONFIG_BLK_DEV_RAM
int fd;
@@ -579,7 +575,6 @@ static int __init populate_rootfs(void)
free_initrd();
#endif
}
-#endif
return 0;
}
rootfs_initcall(populate_rootfs);
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: + proc-fix-the-threaded-proc-self.patch added to -mm tree
"Albert Cahalan" <[EMAIL PROTECTED]> writes: >> >> >> This one is probably best: >> >> >> /proc/task -> 123/task/456 >> >> >> (with both numbers showing) >> >> > >> >> > this sounds good to me. If it's a symlink then there's not much other >> >> > choice because the thread PIDs do not even show up under /proc anymore. >> >> >> >> The name sounds good to me. >> >> I will see about writing the patch for this in a bit and sending >> it to Andrew. > > Nice. Actually I think I will call it /proc/current. That names seems to convey a little better what we are after. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: namespace support requires network modules to say "GPL"
Stephen Hemminger wrote: On Sat, 1 Dec 2007 11:17:36 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the binary seething masses from accessing random kernel functions, and allowing reasonable (but still non GPL) things like ndiswrapper to use network device interface. I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. ... Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] capabilities: introduce per-process capability bounding set (v10)
There is already a pam_cap module in the libcap2 package. Can we merge
this functionality?
I think it is a good idea.
However, this module already have a feature to modify inheritable
capability set.
How does it to be described in the "/etc/security/capability.conf"?
One idea is like a following convention:
# compatible configuration. We can omit "i:" at the head of line
cap_setfcap tak
# It drops any capabilities from b-set except for cap_net_raw and cap_fowner
b:cap_net_raw,cap_fownerymj
# It drops only cap_dac_override from b-set.
b:-cap_dac_override kaigai
# It drops only cap_sys_admin from b-set of any user within users group.
b:-cap_sys_admingroup:users
Thanks,
Cheers
Andrew
[EMAIL PROTECTED] wrote:
Quoting KaiGai Kohei ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
The capability bounding set is a set beyond which capabilities
cannot grow. Currently cap_bset is per-system. It can be
manipulated through sysctl, but only init can add capabilities.
Root can remove capabilities. By default it includes all caps
except CAP_SETPCAP.
Serge,
This feature makes me being interested in.
I think you intend to apply this feature for the primary process
of security container.
However, it is also worthwhile to apply when a session is starting up.
The following PAM module enables to drop capability bounding bit
specified by the fifth field in /etc/passwd entry.
This code is just an example now, but considerable feature.
build and install:
# gcc -Wall -c pam_cap_drop.c
# gcc -Wall -shared -Xlinker -x -o pam_cap_drop.so pam_cap_drop.o -lpam
# cp pam_cap_drop.so /lib/security
modify /etc/passwd as follows:
tak:x:1004:100:cap_drop=cap_net_raw,cap_chown:/home/tak:/bin/bash
^^
example:
[EMAIL PROTECTED] ~]$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.23 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.02 ms
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 1.023/1.130/1.237/0.107 ms
[EMAIL PROTECTED] ~]$ ssh [EMAIL PROTECTED]
[EMAIL PROTECTED]'s password:
Last login: Sat Dec 1 10:09:29 2007 from masu.myhome.cx
[EMAIL PROTECTED] ~]$ export LANG=C
[EMAIL PROTECTED] ~]$ ping 192.168.1.1
ping: icmp open socket: Operation not permitted
[EMAIL PROTECTED] ~]$ su
Password:
pam_cap_bset[6921]: user root does not have 'cap_drop=' property
[EMAIL PROTECTED] tak]# cat /proc/self/status | grep ^Cap
CapInh:
CapPrm: dffe
CapEff: dffe
[EMAIL PROTECTED] tak]#
Neat. A bigger-stick version of not adding the account to
group wheel. I'll use that.
Is there any reason not to have a separate /etc/login.capbounds
config file, though, so the account can still have a full name?
Did you only use that for convenience of proof of concept, or
is there another reason?
# BTW, I replaced the James's address in the Cc: list,
# because MTA does not accept it.
Thanks! I don't know what happened to my alias for him...
thanks,
-serge
--
KaiGai Kohei <[EMAIL PROTECTED]>
pam_cap_drop.c
/*
* pam_cap_drop.c module -- drop capabilities bounding set
*
* Copyright: 2007 KaiGai Kohei <[EMAIL PROTECTED]>
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifndef PR_CAPBSET_DROP
#define PR_CAPBSET_DROP 24
#endif
static char *captable[] = {
"cap_chown",
"cap_dac_override",
"cap_dac_read_search",
"cap_fowner",
"cap_fsetid",
"cap_kill",
"cap_setgid",
"cap_setuid",
"cap_setpcap",
"cap_linux_immutable",
"cap_net_bind_service",
"cap_net_broadcast",
"cap_net_admin",
"cap_net_raw",
"cap_ipc_lock",
"cap_ipc_owner",
"cap_sys_module",
"cap_sys_rawio",
"cap_sys_chroot",
"cap_sys_ptrace",
"cap_sys_pacct",
"cap_sys_admin",
"cap_sys_boot",
"cap_sys_nice",
"cap_sys_resource",
"cap_sys_time",
"cap_sys_tty_config",
"cap_mknod",
"cap_lease",
"cap_audit_write",
"cap_audit_control",
"cap_setfcap",
NULL,
};
PAM_EXTERN int
pam_sm_open_session(pam_handle_t *pamh, int flags,
int argc, const char **argv)
{
struct passwd *pwd;
char *pos, *buf;
char *username = NULL;
/* open system logger */
openlog("pam_cap_bset", LOG_PERROR | LOG_PID, LOG_AUTHPRIV);
/* get the unix username */
if (pam_get_item(pamh, PAM_USER, (void *) ) != PAM_SUCCESS ||
!username)
return PAM_USER_UNKNOWN;
/* get the passwd entry */
pwd = getpwnam(username);
if
2.6.24-rc3-mm2 - add-64-bit-capability-support-to-the-kernel
Question:
The patch does the semantic equivalent of:
-#define cap_clear(c) do { cap_t(c) = 0; } while(0)
-#define cap_set_full(c) do { cap_t(c) = ~0; } while(0)
+# define cap_clear(c) do { (c) = __cap_empty_set; } while (0)
+# define cap_set_full(c) do { (c) = __cap_full_set; } while (0)
+# define cap_set_init_eff(c) do { (c) = __cap_init_eff_set; } while (0)
Was it intentional, or an oversight, that this blows chunks in modules
that try to use cap_clear() or cap_set_full() because the __cap_*
symbols don't get an EXPORT_SYMBOL() attached to them?
pgp9qyKjq1W2c.pgp
Description: PGP signature
Re: 2.6.24-rc3-git6: Reported regressions from 2.6.23
On Saturday 01 December 2007, Rafael J. Wysocki 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
> Handled-By: Tejun Heo <[EMAIL PROTECTED]>
> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> Patch : http://lkml.org/lkml/2007/11/11/115
Tejun's rework of cable detection code which fixes the problem has
been just applied into "upstream" (not "upstream-fixes") so it is
destined for 2.6.25 (I wasn't on cc: BTW) and since I got no feedback
on my patch (below) which also happens to fix the regression, was
acked by Alan, tested by Thomas and has been in -mm for 3 weeks now
I assume that everybody is happy with it (Jeff/Tejun: you were also
on cc: when the patch was merged into -mm)...
Linus, please apply.
[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]>
Tested-by: "Thomas Lindroth" <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Tejun Heo <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ata/pata_amd.c |5 +++--
drivers/ata/pata_via.c |4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
Index: b/drivers/ata/pata_amd.c
===
--- a/drivers/ata/pata_amd.c
+++ b/drivers/ata/pata_amd.c
@@ -25,7 +25,7 @@
#include
#define DRV_NAME "pata_amd"
-#define DRV_VERSION "0.3.9"
+#define DRV_VERSION "0.3.10"
/**
* timing_setup- shared timing computation and load
@@ -115,7 +115,8 @@ static void timing_setup(struct ata_port
}
/* UDMA timing */
- pci_write_config_byte(pdev, offset + 0x10 + (3 - dn), t);
+ if (at.udma)
+ pci_write_config_byte(pdev, offset + 0x10 + (3 - dn), t);
}
/**
Index: b/drivers/ata/pata_via.c
===
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -63,7 +63,7 @@
#include
#define DRV_NAME "pata_via"
-#define DRV_VERSION "0.3.2"
+#define DRV_VERSION "0.3.3"
/*
* The following comes directly from Vojtech Pavlik's ide/pci/via82cxxx
@@ -296,7 +296,7 @@ static void via_do_set_mode(struct ata_p
}
/* Set UDMA unless device is not UDMA capable */
- if (udma_type) {
+ if (udma_type && t.udma) {
u8 cable80_status;
/* Get 80-wire cable detection bit */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix x86-32 early fixmap initialization.
"Yinghai Lu" <[EMAIL PROTECTED]> writes: > On Dec 1, 2007 5:34 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote: >> >> [EMAIL PROTECTED] writes: >> >> > hello, >> > >> > i've just noticed that the chunk in i386/kernel/head.S ended up in a >> > weird place, namely, it's not going to be executed as it's just after >> > a 'jmp 3f' and before startup_32_smp, probably not what you intended. >> > on a sidenote, the whole thing can be done in a single insn, like: >> > >> > movl $(swapper_pg_pmd - __PAGE_OFFSET + 0x067), (swapper_pg_dir - >> > __PAGE_OFFSET+ 4092) >> > >> > PS: your email address [EMAIL PROTECTED] in the commit seems to >> > be wrong as well. >> >> Yes. YH refresh one of my old patches and apparently got my email >> address wrong. >> >> Thanks for the reminder I thought we had fixed this problem a while ago. > > i sent fix to andrew and andi. but it seems they missed it. Well hopefully the new arch/x86 maintainers can pick up a simple bug fix. Hopefully this code has not bit-rotted yet. > BTW: how about your head32.c patch series. I think it is a wonderful idea ;) Right now I'm buried in the namespace work. I am seeing my todo list shrink visibly on that day by day, but it is still a mighty list. Hopefully that list will won't include any patches that just need refreshing and merging by the time 2.6.25 rolls around... Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix x86-32 early fixmap initialization.
On Dec 1, 2007 5:34 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] writes: > > > hello, > > > > i've just noticed that the chunk in i386/kernel/head.S ended up in a > > weird place, namely, it's not going to be executed as it's just after > > a 'jmp 3f' and before startup_32_smp, probably not what you intended. > > on a sidenote, the whole thing can be done in a single insn, like: > > > > movl $(swapper_pg_pmd - __PAGE_OFFSET + 0x067), (swapper_pg_dir - > > __PAGE_OFFSET+ 4092) > > > > PS: your email address [EMAIL PROTECTED] in the commit seems to > > be wrong as well. > > Yes. YH refresh one of my old patches and apparently got my email > address wrong. > > Thanks for the reminder I thought we had fixed this problem a while ago. i sent fix to andrew and andi. but it seems they missed it. BTW: how about your head32.c patch series. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: namespace support requires network modules to say "GPL"
Stephen Hemminger <[EMAIL PROTECTED]> writes: > On Sat, 1 Dec 2007 11:17:36 -0800 > Stephen Hemminger <[EMAIL PROTECTED]> wrote: > >> Then init_net needs to be not GPL limited. Sorry, we need to allow >> non GPL network drivers. There is a fine line between keeping the >> binary seething masses from accessing random kernel functions, and allowing >> reasonable (but still non GPL) things like ndiswrapper to use network >> device interface. >> > I spoke too soon earlier, ndiswrapper builds and loads against current > 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I > don't > give a damn, but the enterprise distro vendors certainly care. It looks like someone found a work around for vmware. As for proprietary VPN software, the one case that came of David Miller said we had sufficient alternatives in the kernel that he didn't care. We have to make a lot of changes to get the network namespaces complete. I don't have pity on any external code that breaks because they won't let me at their code. If it turns out the code that was broken was an unacknowledged derivative work and it can't be fixed I have even less pity on them. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Avoid overflows in kernel/time.c
Alan Cox wrote: Its visibile for people doing PAL media processing and TV sync work. Longer term we have high precision timers and tickless so for now we can jut do the HZ == 300 math in steps to avoid the overflow. Slower but in time it won't matter. Just use the patch... I don't think a dependency on bc will be a problem for anyone (but it should, indeed, be documented -- together with everything else we haven't documented yet.) -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23.9, make install doesn't work with grub anymore??
Hello, I downloaded the vanilla kernels 2.6.23.8 and 2.6.23.9 from kernel.org. I unpacked them like I have every other kernel release. I compiled the kernel successfully, did the make modules and make modules_install with no problems. When I did the make install I am told it Cannot find LILO. The message seems to come from /usr/src/linux-2.6.23.9/arch/i386/boot/install.sh The script is correct that I don't have lilo installed, I have used grub for quite some time. I don't remember having this problem with older kernels, sorry I don't remember one of the top of head. Did something change or is: cp .config /usr/src/linux-2.6.23-9 make menuconfig make make modules make modules_install make install no longer adequate to compile and install a kernel? Thanks, Scott _ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix x86-32 early fixmap initialization.
[EMAIL PROTECTED] writes: > hello, > > i've just noticed that the chunk in i386/kernel/head.S ended up in a > weird place, namely, it's not going to be executed as it's just after > a 'jmp 3f' and before startup_32_smp, probably not what you intended. > on a sidenote, the whole thing can be done in a single insn, like: > > movl $(swapper_pg_pmd - __PAGE_OFFSET + 0x067), (swapper_pg_dir - > __PAGE_OFFSET+ 4092) > > PS: your email address [EMAIL PROTECTED] in the commit seems to > be wrong as well. Yes. YH refresh one of my old patches and apparently got my email address wrong. Thanks for the reminder I thought we had fixed this problem a while ago. Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]> --- diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S index 374b7ec..ac0637a 100644 --- a/arch/x86/kernel/head_32.S +++ b/arch/x86/kernel/head_32.S @@ -193,6 +193,12 @@ default_entry: jb 10b movl %edi,(init_pg_tables_end - __PAGE_OFFSET) + /* Do an early initialization of the fixmap area */ + movl $(swapper_pg_dir - __PAGE_OFFSET), %edx + movl $(swapper_pg_pmd - __PAGE_OFFSET), %eax + addl $0x007, %eax /* 0x007 = PRESENT+RW+USER */ + movl %eax, 4092(%edx) + xorl %ebx,%ebx /* This is the boot CPU (BSP) */ jmp 3f /* @@ -208,12 +214,6 @@ default_entry: .section .init.text,"ax",@progbits #endif - /* Do an early initialization of the fixmap area */ - movl $(swapper_pg_dir - __PAGE_OFFSET), %edx - movl $(swapper_pg_pmd - __PAGE_OFFSET), %eax - addl $0x007, %eax /* 0x007 = PRESENT+RW+USER */ - movl %eax, 4092(%edx) - #ifdef CONFIG_SMP ENTRY(startup_32_smp) cld -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] capabilities: introduce per-process capability bounding set (v10)
Serge, Is there any reason not to have a separate /etc/login.capbounds config file, though, so the account can still have a full name? Did you only use that for convenience of proof of concept, or is there another reason? passwd(5) says the fifth field is optional and only used for informational purpose (like ulimit, umask). However, using any other separate config file is conservative and better. One candidate is "/etc/security/capability.conf" defined as the config file of pam_cap. Thanks, -- KaiGai Kohei <[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: namespace support requires network modules to say "GPL"
Jiri Slaby <[EMAIL PROTECTED]> writes: > On 12/02/2007 12:13 AM, Eric W. Biederman wrote: >> Mark Lord <[EMAIL PROTECTED]> writes: >>> Fine. But all of them want to call sk_alloc(), >> >> network drivers should be calling sk_alloc less then they should >> call dev_get_by_. Only protocols call sk_alloc. >> >>> and many want to do register_netdev(). >> >> I haven't even touched register_netdev. >> >>> So what should they be using there ? >> >> What are you having problems with? >> >> It is hard to answer specific questions without a context. > > VMware vmnet. With a quick glance in that direction it appears to the result of a design bug in vmnet that they call sk_alloc at all, and someone seems to have found a work around in vmnet for this situation. My gut feel is that vmware should just use tun or tap (whichever is the appropriate one), and be done with it. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 20000+ wake-ups/second in 2.6.24. Bug?
Hi, On Sunday 02 December 2007, Arjan van de Ven wrote in "Re: 2+ wake-ups/second in 2.6.24. Bug?": > > > Mark Lord <[EMAIL PROTECTED]> wrote: > > >> 2.6.23 did not have this problem. > > > actually we have reports of 2.6.23 having the exact same problem. > > > The thing is, "something" is causing the system to go into a state > > > where the cpu throws us right out of the C-state the kernel asks > > > for. Just as an Information - I see the same problem here, with an ubuntu 2.6.22 kernel. I did not report it so far, as I couldnt reliably reproduce it with an upstream kernel. Just as an additional datapoint (Lenovo T60 here). For me it happens only when using battery. Thats another reason I havent reported it so far - it only happened while on the road with work to do. If there is any testing needed - just say it. Greetings, Andres signature.asc Description: This is a digitally signed message part.
Re: namespace support requires network modules to say "GPL"
Mark Lord <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> Mark Lord <[EMAIL PROTECTED]> writes: >> >>> Arjan van de Ven wrote: On Sat, 01 Dec 2007 15:21:12 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > Eric W. Biederman wrote: >> Stephen Hemminger <[EMAIL PROTECTED]> writes: >> Sure. We keep the updated dev_get_by_ that takes a network >> namespace parameter. > .. > > And what should code be passing in when "# CONFIG_NET_NS is not set" ? network drivers probably really really don't want to call dev_get_by_XXX... >>> .. >>> >>> Fine. But all of them want to call sk_alloc(), >> >> network drivers should be calling sk_alloc less then they should >> call dev_get_by_. Only protocols call sk_alloc. > .. > > I think I saw some bridge code that calls it, too. > Regardless, it's EXPORT_SYMBOL(), but now unusable > due to the GPL-only symbol "init_net". > > Meanwhile, you are avoiding answering the question: What EXPORT_SYMBOL_GPL means is I don't have a clue how you can use this without being a derivative work of the linux kernel. I think that is true for init_net and I stand by that. It is a very internal symbol. Further the only case that I think might pass the derivative work test would be a network driver, and I am not affecting those. I also believe that since it isn't mandatory you get your struct net pointer by taking the address of a GPL only symbol that those interfaces can continue to be used. However I do suspect you are right that it may be more correct to realized that only a derivative work could possibly use those interfaces and tell 3rd parties that loud and clear. We also have the policy of not changing exports from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL. So making that such a change is difficult. > And what should code be passing in when "# CONFIG_NET_NS is not set" ? > .. > >>> and many want to do register_netdev(). >> >> I haven't even touched register_netdev. > .. > > Bull-pucky. Somebody did: > >> @@ -3361,6 +3595,8 @@ int register_netdevice(struct net_device *dev) >> >> /* When net_device's are persistent, this will be fatal. */ >> BUG_ON(dev->reg_state != NETREG_UNINITIALIZED); >> + BUG_ON(!dev->nd_net); >> + net = dev->nd_net; >> >> spin_lock_init(>queue_lock); >> spin_lock_init(>_xmit_lock); > .. > > That new BUG_ON() line complains if nd_net has not been initialized, > and the only thing I see drivers putting there is GPL-only "_net". Yes and alloc_netdev initializes it. All network drivers are required to call alloc_netdev. So register_netdev from a device driver perspective has not changed. Anything the above change breaks happens to be a broken network device driver. >>> So what should they be using there ? >> >> What are you having problems with? > .. > > Avoiding the question again there, too. No. I am saying that I don't see a problem. All of the real world problems that I actually know of are code bugs. I asked for a real world problem to see if there was something I was missing in my analysis. That isn't avoiding the problem that is trying to see if I was wrong. > I personally am not having problems with anything. > But I noticed the API change, and would like somebody to fix it. > Any of the three ways (or a fourth, if you've got one) might do. Honestly I think I have done the best I can with the knowledge and information that I have.I do not think dropping the GPL from the export of init_net makes sense. I think turning a NULL into init_net is a technical joke. That parameter is there because that is someplace where we need to pay attention to our network namespace. Which only leaves your first option of making more symbols EXPORT_SYMBOL_GPL as even interesting. That would seem to make some sense, given the attitudes and perceptions of the current network developers. However I'm not volunteering for that one as finishing up the network and pid namespaces already has my plate full. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
On Saturday 01 December 2007, Ingo Molnar wrote: > maybe, but we'd have to see how often this gets triggered. An OOM is > something that could happen in any overloaded system - while a hung task > is likely due to a kernel bug. What about a client using hard mounted NFS shares here? That shouldn't be killed by the OOM killer in that situation, should it? Am I missing sth.? Best Regards Ingo Oeser -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] drivers/cpufreq/cpufreq_stats.c section fix
cpufreq_stats_free_table() mustn't be __cpuexit since it's called by the
__cpuinit cpufreq_stat_cpu_callback().
This patch fixes the following section mismatch reported by
Chris Clayton:
<-- snip -->
...
WARNING: vmlinux.o(.init.text+0x143dd): Section mismatch: reference to
.exit.text:cpufreq_stats_free_table (between 'cpufreq_stat_cpu_callback' and
'cpufreq_stats_init')
...
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
b845706570b48f091f855c33cdb9979d7e83a424
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index 8a45d0f..1b8312b 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -164,7 +164,7 @@ freq_table_get_index(struct cpufreq_stats *stat, unsigned
int freq)
return -1;
}
-static void __cpuexit cpufreq_stats_free_table(unsigned int cpu)
+static void cpufreq_stats_free_table(unsigned int cpu)
{
struct cpufreq_stats *stat = cpufreq_stats_table[cpu];
struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86 intel_cacheinfo.c section fix
free_cache_attributes() must be __cpuinit since it calls the
__cpuinit cache_remove_shared_cpu_map().
This patch fixes the following section mismatch reported by
Chris Clayton:
<-- snip -->
...
WARNING: vmlinux.o(.text+0x90b6): Section mismatch: reference to
.init.text:cache_remove_shared_cpu_map (between 'free_cache_attributes' and
'show_level')
...
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
afa32c098aaa39826ec6c71e641908ea12287e48
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index 9921b01..606fe4d 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -497,7 +497,7 @@ static void __cpuinit cache_shared_cpu_map_setup(unsigned
int cpu, int index) {}
static void __cpuinit cache_remove_shared_cpu_map(unsigned int cpu, int index)
{}
#endif
-static void free_cache_attributes(unsigned int cpu)
+static void __cpuinit free_cache_attributes(unsigned int cpu)
{
int i;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
blackfin compile error
It seems commit 5d448dd50712ae42f8176b5bb8db4703bef6f0f5 was incomplete: <-- snip --> ... CC arch/blackfin/mach-bf537/boards/stamp.o /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: error: unknown field 'pin_req' specified in initializer /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: error: extra brace group at end of initializer /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: error: (near initialization for 'bfin_spi0_info') /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: warning: excess elements in struct initializer /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/blackfin/mach-bf537/boards/stamp.c:539: warning: (near initialization for 'bfin_spi0_info') make[2]: *** [arch/blackfin/mach-bf537/boards/stamp.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: namespace support requires network modules to say "GPL"
On Sat, 1 Dec 2007 11:17:36 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > Then init_net needs to be not GPL limited. Sorry, we need to allow > non GPL network drivers. There is a fine line between keeping the > binary seething masses from accessing random kernel functions, and allowing > reasonable (but still non GPL) things like ndiswrapper to use network > device interface. > I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. -- Stephen Hemminger <[EMAIL PROTECTED]> -- Stephen Hemminger <[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: 20000+ wake-ups/second in 2.6.24. Bug?
On Sat, 01 Dec 2007 18:55:48 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > Arjan van de Ven wrote: > > On Sat, 01 Dec 2007 18:43:39 -0500 > > Mark Lord <[EMAIL PROTECTED]> wrote: > > > >> Dagnabbit.. it's done it again.. went from 100-200 wakeups/sec > >> back up to 2+ wakeups/sec. This time *with* the powertop > >> patches in place. > >> > >> Somethings broken in there, but I don't know what. > >> Or how to make it happen on demand.. it's fine after rebooting > >> again. > >> > >> ??? > >> > >> At least now I know to look when I hear the fan turning on > >> when the system is otherwise supposed to be idle.. > >> > >> 2.6.23 did not have this problem. > > > > actually we have reports of 2.6.23 having the exact same problem. > > The thing is, "something" is causing the system to go into a state > > where the cpu throws us right out of the C-state the kernel asks > > for. > ... > > Ahh. Okay, this machine here did not have the problem on 2.6.23. > > > Some people have seen that not loading yenta at all will just make > > this not happen at all... > ... > > No yenta/cardbus here -- it's all PCIe. but.. is yenta loaded or built into the kernel? or is the config option off? Also, do you have a TI firewire bridge? (just asking the common patterns we've sort of kinda seen so far) > If you have any debug patches that could detect or help next time I > see it, then feel free to toss them this way. one thing to try (just as data collection) is to do lspci -vvxxx before it happens, and then again after it happens and then diff to see if something changed ;( (yes this is very crude; we've not been able to chase this one down at all so far). -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sym53c8xx2: incredible sloth after parity error / SCSI bus reset
About once a year I get a SCSI parity error on one of my systems (the only one with SCSI). I presume the cabling is substandard, but given my coordination deficits and the rarity of the errors I'd do far more damage replacing it than leaving it be. I had one of these today. The system (2.6.23.9) spotted the error, and seemingly recovered: Dec 1 12:53:40 loki warning: kernel: sym0: SCSI parity error detected: SCR1=132 DBC=5000 SBCL=0 Dec 1 12:53:40 loki warning: kernel: sym0:0: ERROR (81:0) (8-0-0) (10/9d/0) @ (mem c2800048:). Dec 1 12:53:40 loki warning: kernel: sym0: regdump: da 00 00 9d 47 10 00 0e 00 08 80 00 80 00 0f 0a d0 58 3c 01 02 ff ff ff. Dec 1 12:53:40 loki warning: kernel: sym0: SCSI BUS reset detected. Dec 1 12:53:40 loki notice: kernel: sym0: SCSI BUS has been reset. However, after that reset I/O to any device on that controller is *incredibly* slow. A monthly RAID check kicked off shortly afterwards and provided my first clue. Load average >15, and: md1 : active raid5 sda6[0] hdc5[3] sdb6[1] 76807296 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU] [>] check = 42.8% (16450780/38403648) finish=253.3min speed=1442K/sec 1442Kb/s is a bit less than I'd expect from a three-drive array with disks capable of 40Mb/s easily. /dev/sda: Timing buffered disk reads:8 MB in 3.50 seconds = 2.29 MB/sec A somewhat slower ATAPI disk on the same machine: /dev/hdc: Timing buffered disk reads: 110 MB in 3.05 seconds = 36.08 MB/sec So, um, what could cause this? Can I speed it up again other than by rebooting (which I'm just about to do, but it is annoying). -- `Some people don't think performance issues are "real bugs", and I think such people shouldn't be allowed to program.' --- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 20000+ wake-ups/second in 2.6.24. Bug?
On Sunday, 2 of December 2007, Mark Lord wrote: > Arjan van de Ven wrote: > > On Sat, 01 Dec 2007 18:43:39 -0500 > > Mark Lord <[EMAIL PROTECTED]> wrote: > > > >> Dagnabbit.. it's done it again.. went from 100-200 wakeups/sec > >> back up to 2+ wakeups/sec. This time *with* the powertop patches > >> in place. > >> > >> Somethings broken in there, but I don't know what. > >> Or how to make it happen on demand.. it's fine after rebooting again. > >> > >> ??? > >> > >> At least now I know to look when I hear the fan turning on > >> when the system is otherwise supposed to be idle.. > >> > >> 2.6.23 did not have this problem. > > > > actually we have reports of 2.6.23 having the exact same problem. > > The thing is, "something" is causing the system to go into a state > > where the cpu throws us right out of the C-state the kernel asks for. > ... > > Ahh. Okay, this machine here did not have the problem on 2.6.23. So on this particular machine it is a regression. I'm tempted to add it to the list of recent regressions in case it appears on someone else's system on which 2.6.23 works correctly. Objections? 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: [LIKELY_SPAM][git patches] net driver fixes
Jeff Garzik wrote: Notes: 1) Several of these are resends from the last submission. 2) That chelsio file mode change (644->755) is a bit annoying. Can git do chmod as a changeset by itself? Sorry for this. I had not noticed it. If any help, I just submitted a patch reverting the file mode changes. Cheers, Divy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] cxgb - revert file mode changes.
From: Divy Le Ray <[EMAIL PROTECTED]> revert inavertant file mode changes Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/chelsio/cxgb2.c |0 drivers/net/chelsio/pm3393.c |0 drivers/net/chelsio/sge.c|0 drivers/net/chelsio/sge.h|0 4 files changed, 0 insertions(+), 0 deletions(-) diff --git a/drivers/net/chelsio/cxgb2.c b/drivers/net/chelsio/cxgb2.c old mode 100755 new mode 100644 diff --git a/drivers/net/chelsio/pm3393.c b/drivers/net/chelsio/pm3393.c old mode 100755 new mode 100644 diff --git a/drivers/net/chelsio/sge.c b/drivers/net/chelsio/sge.c old mode 100755 new mode 100644 diff --git a/drivers/net/chelsio/sge.h b/drivers/net/chelsio/sge.h old mode 100755 new mode 100644 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 20000+ wake-ups/second in 2.6.24. Bug?
Arjan van de Ven wrote: On Sat, 01 Dec 2007 18:43:39 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: Dagnabbit.. it's done it again.. went from 100-200 wakeups/sec back up to 2+ wakeups/sec. This time *with* the powertop patches in place. Somethings broken in there, but I don't know what. Or how to make it happen on demand.. it's fine after rebooting again. ??? At least now I know to look when I hear the fan turning on when the system is otherwise supposed to be idle.. 2.6.23 did not have this problem. actually we have reports of 2.6.23 having the exact same problem. The thing is, "something" is causing the system to go into a state where the cpu throws us right out of the C-state the kernel asks for. ... Ahh. Okay, this machine here did not have the problem on 2.6.23. Some people have seen that not loading yenta at all will just make this not happen at all... ... No yenta/cardbus here -- it's all PCIe. If you have any debug patches that could detect or help next time I see it, then feel free to toss them this way. Cheers! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: namespace support requires network modules to say "GPL"
Eric W. Biederman wrote: Mark Lord <[EMAIL PROTECTED]> writes: Arjan van de Ven wrote: On Sat, 01 Dec 2007 15:21:12 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: Eric W. Biederman wrote: Stephen Hemminger <[EMAIL PROTECTED]> writes: Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. .. And what should code be passing in when "# CONFIG_NET_NS is not set" ? network drivers probably really really don't want to call dev_get_by_XXX... .. Fine. But all of them want to call sk_alloc(), network drivers should be calling sk_alloc less then they should call dev_get_by_. Only protocols call sk_alloc. .. I think I saw some bridge code that calls it, too. Regardless, it's EXPORT_SYMBOL(), but now unusable due to the GPL-only symbol "init_net". Meanwhile, you are avoiding answering the question: And what should code be passing in when "# CONFIG_NET_NS is not set" ? .. and many want to do register_netdev(). I haven't even touched register_netdev. .. Bull-pucky. Somebody did: @@ -3361,6 +3595,8 @@ int register_netdevice(struct net_device *dev) /* When net_device's are persistent, this will be fatal. */ BUG_ON(dev->reg_state != NETREG_UNINITIALIZED); + BUG_ON(!dev->nd_net); + net = dev->nd_net; spin_lock_init(>queue_lock); spin_lock_init(>_xmit_lock); .. That new BUG_ON() line complains if nd_net has not been initialized, and the only thing I see drivers putting there is GPL-only "_net". So what should they be using there ? What are you having problems with? .. Avoiding the question again there, too. I personally am not having problems with anything. But I noticed the API change, and would like somebody to fix it. Any of the three ways (or a fourth, if you've got one) might do. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 20000+ wake-ups/second in 2.6.24. Bug?
On Sat, 01 Dec 2007 18:43:39 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > > Dagnabbit.. it's done it again.. went from 100-200 wakeups/sec > back up to 2+ wakeups/sec. This time *with* the powertop patches > in place. > > Somethings broken in there, but I don't know what. > Or how to make it happen on demand.. it's fine after rebooting again. > > ??? > > At least now I know to look when I hear the fan turning on > when the system is otherwise supposed to be idle.. > > 2.6.23 did not have this problem. actually we have reports of 2.6.23 having the exact same problem. The thing is, "something" is causing the system to go into a state where the cpu throws us right out of the C-state the kernel asks for. Some people have seen that not loading yenta at all will just make this not happen at all... -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Strange 1-second pauses during Resume-from-RAM
On Sat, 1 December 2007 21:54:56 +0100, Ingo Molnar wrote: > * J??rn Engel <[EMAIL PROTECTED]> wrote: > > > > stopped custom tracer. > > BUG: spinlock recursion on CPU#0, sh/953 > > lock: c030f280, .magic: dead4ead, .owner: sh/953, .owner_cpu: 0 > > Pid: 953, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty #2 > > [] show_trace_log_lvl+0x35/0x54 > > [] show_trace+0x2c/0x2e > > [] dump_stack+0x84/0x8a > > [] spin_bug+0xa7/0xae > > [] _raw_spin_lock+0x45/0xfa > > [] _spin_lock_irqsave+0x68/0x7a > > [] pit_read+0x14/0x99 > > [] get_monotonic_cycles+0xf/0x2d > > ah. You should mark pit_read() function as notrace. PIT clocksource is > rare. (add the 'notrace' word to the function prototype) Hardly a change at all. Apart from some offsets, this dump is identical. stopped custom tracer. BUG: spinlock recursion on CPU#0, sh/954 lock: c030f280, .magic: dead4ead, .owner: sh/954, .owner_cpu: 0 Pid: 954, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty #3 [] show_trace_log_lvl+0x35/0x54 [] show_trace+0x2c/0x2e [] dump_stack+0x84/0x8a [] spin_bug+0xa7/0xae [] _raw_spin_lock+0x45/0xfa [] _spin_lock_irqsave+0x68/0x7a [] pit_read+0xf/0x91 [] get_monotonic_cycles+0xf/0x2d [] now+0x2a/0x7c [] trace+0x4d/0x1e8 [] __mcount+0x95/0xa6 [] mcount+0x14/0x18 [] lock_acquired+0xe/0x1d7 [] _spin_lock_irqsave+0x70/0x7a [] pit_read+0xf/0x91 [] update_wall_time+0x23/0x692 [] do_timer+0x24/0xb1 [] tick_periodic+0x49/0x84 [] tick_handle_periodic+0x22/0x73 [] timer_interrupt+0x4f/0x56 [] handle_IRQ_event+0x24/0x4f [] handle_edge_irq+0xb8/0x125 [] do_IRQ+0x89/0xa3 [] common_interrupt+0x23/0x28 [] mcount+0x14/0x18 [] sysctl_head_finish+0xc/0x33 [] proc_sys_write+0x96/0xa0 [] vfs_write+0xa6/0x14c [] sys_write+0x4c/0x70 [] syscall_call+0x7/0xb === Jörn -- Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. -- Howard Aiken quoted by Ken Iverson quoted by Jim Horning quoted by Raph Levien, 1979 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 x86/mm 6/6] x86-64 ia32 ptrace get/putreg32 current task
On Nov 29, 2007, at 2:44 PM, Ingo Molnar wrote: * Andi Kleen <[EMAIL PROTECTED]> wrote: For i386 iirc Jeremy/Zach did the benchmarking and they settled on %fs because it was faster for something (originally it was %gs too) yep. IIRC, some CPUs only optimize %fs because that's what Windows uses and leaves Linux with %gs out in the cold. I did measure some anomalies with the AMD K6+ (or something like that), in which %gs was faster than %fs. It was pretty much inexplicable, but also unique - all other processors I tested (which was a range from Pentium MMX to current) had identical performance. There's also a performance penalty for overlapping segment use, if the segment cache is single entry only with an additional optimization for NULL [which just hides the segment cache]. Some processors do perform slightly better with null selector loads than GDT/LDT ones, but it wasn't really noticeable for modern processors. The Intel architecture guy I asked about this said that it might be worth doing, but it would likely be swamped by a GDT cache miss. I looked at rearranging the kernel's GDT to pack all the kernel entry/exit entries into as few cachelines as possible, but it was surprisingly fiddley. But if it's good for unification we could switch that to %gs again on 32-bit. I was one of the people who advocated the use of the 'other' segment register, so that the hardware has less overlap, but clean and unified code trumps this concern. It shouldnt be an issue on reasonably modern CPUs anyway. Well, overall it should be fairly easy to make the two arches use their own segment registers with a simple #define. But things like ptrace and vm86 were tricky, though I guess the latter isn't an issue for 64-bit. I originally chose %gs for the kernel, partly in the hope that compiler support for TLS would be helpful in the kernel, though that doesn't seem like a good idea in retrospect. %gs for the sake of consistency would be reasonable, and wouldn't have a measurable downside. J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
20000+ wake-ups/second in 2.6.24. Bug?
Mark Lord wrote: Arjan van de Ven wrote: On Fri, 30 Nov 2007 22:31:17 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: ... Speaking of which.. what's with powertop on 2.6.24 ??? It's gone from 100-200 wakeups/sec to 2 wakeups/sec !!! ho hum.. Lenovo T61? I have some reports that that happens once in a while (but it's not limited to .24 and it's also real, it's not a powertop bug but it actually is waking up that much).. .. No, it's my hefty Dell Inspiron 9400. And I just figured out the powertop: it needed the kernel timers patch from the powertop site that was originally for 2.6.21.. ... Dagnabbit.. it's done it again.. went from 100-200 wakeups/sec back up to 2+ wakeups/sec. This time *with* the powertop patches in place. Somethings broken in there, but I don't know what. Or how to make it happen on demand.. it's fine after rebooting again. ??? At least now I know to look when I hear the fan turning on when the system is otherwise supposed to be idle.. 2.6.23 did not have this problem. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git patches] libata fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c| 28 +++
drivers/ata/libata-core.c |8 +++--
drivers/ata/libata-eh.c | 42 +++--
drivers/ata/pata_at32.c | 61 +++---
drivers/ata/pata_bf54x.c |7 +
drivers/ata/sata_mv.c | 64 ++--
6 files changed, 149 insertions(+), 61 deletions(-)
Alan Cox (1):
libata: Fix early use of port printk. (Was Re: ata4294967295: failed to
start port (errno=-19))
Kristoffer Nyborg Gregertsen (1):
Several fixes for the AVR32 PATA driver
Mark Lord (1):
sata_mv: Fix broken Marvell 7042 support.
Peter Missel (1):
libata: More IVB horkage from TSST
Peter Schwenke (1):
ata_piix: add more toshiba laptops to broken suspend list
Saeed Bishara (1):
sata_mv: fix compilation error when enabling DEBUG
Tejun Heo (1):
libata: report protocol and full CDB on error
sonic zhang (1):
Set proper ATA UDMA mode for bf548 according to system clock.
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 483269d..b538e1d 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -967,6 +967,13 @@ static int piix_broken_suspend(void)
},
},
{
+ .ident = "TECRA M3",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Tecra M3"),
+ },
+ },
+ {
.ident = "TECRA M5",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
@@ -981,6 +988,20 @@ static int piix_broken_suspend(void)
},
},
{
+ .ident = "TECRA A8",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TECRA A8"),
+ },
+ },
+ {
+ .ident = "Satellite R25",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Satellite R25"),
+ },
+ },
+ {
.ident = "Satellite U200",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
@@ -988,6 +1009,13 @@ static int piix_broken_suspend(void)
},
},
{
+ .ident = "Satellite U200",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "SATELLITE U200"),
+ },
+ },
+ {
.ident = "Satellite Pro U200",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 33f0627..b514a80 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4185,6 +4185,9 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Devices which get the IVB wrong */
{ "QUANTUM FIREBALLlct10 05", "A03.0900", ATA_HORKAGE_IVB, },
{ "TSSTcorp CDDVDW SH-S202J", "SB00", ATA_HORKAGE_IVB, },
+ { "TSSTcorp CDDVDW SH-S202J", "SB01", ATA_HORKAGE_IVB, },
+ { "TSSTcorp CDDVDW SH-S202N", "SB00", ATA_HORKAGE_IVB, },
+ { "TSSTcorp CDDVDW SH-S202N", "SB01", ATA_HORKAGE_IVB, },
/* End Marker */
{ }
@@ -6964,12 +6967,11 @@ int ata_host_start(struct ata_host *host)
if (ap->ops->port_start) {
rc = ap->ops->port_start(ap);
if (rc) {
- ata_port_printk(ap, KERN_ERR, "failed to "
- "start port (errno=%d)\n", rc);
+ if (rc != -ENODEV)
+ dev_printk(KERN_ERR, host->dev, "failed
to start port %d (errno=%d)\n", i, rc);
goto err_out;
}
}
-
ata_eh_freeze_port(ap);
}
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 0dac69d..e6605f0 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1850,30 +1850,54 @@ static void ata_eh_link_report(struct ata_link *link)
ehc->i.serror &
Re: [patch] ata: ahci: Enclosure Management via LED rev2
Kristen Carlson Accardi wrote: Enclosure Management via LED This patch implements Enclosure Management via the LED protocol as specified in AHCI specification. Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> --- This revision makes the change to the comment requested by Mark Lord, fixes some bugs in the bit shifting for writing the new led state, and implements a show function so that led status can be read as well as written. Overall looks pretty good, from a technical review perspective. Two worries: 1) exporting ata_scsi_find_dev(), and assuming a scsi device is attached. the latter can be fixed by a !NULL check (and should be), but its a bit of a layering violation since long term we want to make the SCSI simulator optional for all ATA devices. 2) vaguely related to #1, I'm not so sure the attributes should be implemented directly in ahci. if this __or something like it__ appears on non-Intel hardware, the code should be somewhere more generic. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
Just a little reminder ...
On Sun, 2 Dec 2007 00:34:03 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>
> static int __init of_add_fixed_phys(void)
> {
> struct device_node *np;
> const u32 *prop;
> struct fixed_phy_status status = {};
>
> while ((np = of_find_node_by_name(NULL, "ethernet"))) {
for_each_node_by_name(np, "ethernet") {
(this probably does what you want instead of finding just the first
ethernet over and over again. :-))
> data = of_get_property(np, "fixed-link", NULL);
> if (!data)
> continue;
>
> status.link = 1;
> status.duplex = data[1];
> status.speed = data[2];
>
> ret = fixed_phy_add(PHY_POLL, data[0], );
> if (ret)
> return ret;
if (ret) {
of_put_node(np);
retun ret;
}
> }
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpGkeKxDDA5m.pgp
Description: PGP signature
Re: [PATCH 0/3] cxgb - driver fixes.
Ben Greear wrote: Divy Le Ray wrote: Jeff, I'm submitting a patch series for inclusion in 2.6.24 for the cxgb driver. The patches are built against Linus'git tree. Here is a brief description: - Ensure that GSO skbs have enough headroom before encapsulating them, - Fix a crash in NAPI mode, - Fix statistics accounting and report. We ran pktgen overnight on 2.6.23 with patch 1 and 3 applied (patch 2 not needed on .23 it seems) and it was stable at about 1.5Gbps bi-directional using 1500 MTU sized frames. We'll run some more tests with user-space TCP & UDP today, but it looks good so far. Perhaps these patches should be considered for .23 stable as well? Thanks, Ben Yes, patches 1 and 3 could be considered for .22 and .23-stable, along with the previous fix: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7de6af0f23b25df8da9719ecae1916b669d0b03d Cheers, Divy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: namespace support requires network modules to say "GPL"
On 12/02/2007 12:13 AM, Eric W. Biederman wrote: > Mark Lord <[EMAIL PROTECTED]> writes: >> Fine. But all of them want to call sk_alloc(), > > network drivers should be calling sk_alloc less then they should > call dev_get_by_. Only protocols call sk_alloc. > >> and many want to do register_netdev(). > > I haven't even touched register_netdev. > >> So what should they be using there ? > > What are you having problems with? > > It is hard to answer specific questions without a context. VMware vmnet. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: namespace support requires network modules to say "GPL"
Mark Lord <[EMAIL PROTECTED]> writes: > Arjan van de Ven wrote: >> On Sat, 01 Dec 2007 15:21:12 -0500 >> Mark Lord <[EMAIL PROTECTED]> wrote: >> >>> Eric W. Biederman wrote: Stephen Hemminger <[EMAIL PROTECTED]> writes: Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. >>> .. >>> >>> And what should code be passing in when "# CONFIG_NET_NS is not set" ? >> >> network drivers probably really really don't want to call >> dev_get_by_XXX... > .. > > Fine. But all of them want to call sk_alloc(), network drivers should be calling sk_alloc less then they should call dev_get_by_. Only protocols call sk_alloc. > and many want to do register_netdev(). I haven't even touched register_netdev. > So what should they be using there ? What are you having problems with? It is hard to answer specific questions without a context. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Peculiar out-of-sync boot log lines
On Sat, 1 Dec 2007 22:59:35 +0100 Bartlomiej Zolnierkiewicz wrote:
> Thanks for reporting/debugging it guys!
>
> > Something in there needs to insert a '\n' before the "skipping word"
> > message.
> > Since it doesn't do that right now, the KERN_DEBUG string appears as "<7>"
>
> This seems like a good occasion to fix ide_dma_verbose() for good so... :)
>
> [ patch is against current Linus tree so might not apply to 2.6.23.9 ]
>
> [PATCH] ide: DMA reporting and validity checking fixes
>
> * ide_xfer_verbose() fixups:
> - beautify returned mode names
> - fix PIO5 reporting
> - make it return 'const char *'
>
> * Change printk() level from KERN_DEBUG to KERN_INFO in ide_find_dma_mode().
>
> * Add ide_id_dma_bug() helper based on ide_dma_verbose() to check for invalid
> DMA info in identify block.
>
> * Use ide_id_dma_bug() in ide_tune_dma() and ide_driveid_update().
>
> As a result DMA won't be tuned or will be disabled after tuning if device
> reports inconsistent info about enabled DMA mode (ide_dma_verbose() does the
> same checks while the IDE device is probed by ide-{cd,disk} device driver).
>
> * Since (id->capability & 1) && id->tDMA is a valid configuration handle
> it correctly in ide_id_dma_bug().
>
> * Remove no longer needed ide_dma_verbose().
>
> This patch should fix the following problem with out-of-sync IDE messages
> reported by Nick Warned:
>
>hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache<7>hdd:
>skipping word 93 validity check
> , UDMA(66)
>
> and later debugged by Mark Lord to be caused by:
>
> ide_dma_verbose()
> printk( ... "2048kB Cache");
> eighty_ninty_three()
> printk(KERN_DEBUG "%s: skipping word 93 validity check\n");
> ide_dma_verbose()
> printk(", UDMA(66)"
>
> Please note that as a result ide-{cd,disk} device drivers won't report the
> DMA speed used but this is intended since now DMA mode being used is always
> reported by IDE core code.
>
> Cc: Nick Warne <[EMAIL PROTECTED]>
> Cc: Mark Lord <[EMAIL PROTECTED]>
> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> ---
> drivers/ide/ide-cd.c |7 --
> drivers/ide/ide-disk.c |5
> drivers/ide/ide-dma.c | 57
> -
> drivers/ide/ide-iops.c |3 ++
> drivers/ide/ide-lib.c | 55 ---
> include/linux/ide.h|6 ++---
> 6 files changed, 51 insertions(+), 82 deletions(-)
>
> Index: b/drivers/ide/ide-cd.c
> ===
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -3049,12 +3049,7 @@ int ide_cdrom_probe_capabilities (ide_dr
> else
> printk(" drive");
>
> - printk(", %dkB Cache", be16_to_cpu(cap.buffer_size));
> -
> - if (drive->using_dma)
> - ide_dma_verbose(drive);
> -
> - printk("\n");
> + printk(", %dkB Cache\n", be16_to_cpu(cap.buffer_size));
Use
printk(KERN_CONT ...
so that someone won't try to add another KERN_* facility level to it.
(same for other continued printk calls in this patch)
>
> return nslots;
> }
> Index: b/drivers/ide/ide-disk.c
> ===
> --- a/drivers/ide/ide-disk.c
> +++ b/drivers/ide/ide-disk.c
> @@ -961,11 +961,8 @@ static void idedisk_setup (ide_drive_t *
> if (id->buf_size)
> printk (" w/%dKiB Cache", id->buf_size/2);
>
> - printk(", CHS=%d/%d/%d",
> + printk(", CHS=%d/%d/%d\n",
Ditto.
> drive->bios_cyl, drive->bios_head, drive->bios_sect);
> - if (drive->using_dma)
> - ide_dma_verbose(drive);
> - printk("\n");
>
> /* write cache enabled? */
> if ((id->csfo & 1) || (id->cfs_enable_1 & (1 << 5)))
> Index: b/include/linux/ide.h
> ===
> --- a/include/linux/ide.h
> +++ b/include/linux/ide.h
> @@ -1333,8 +1334,7 @@ static inline void ide_set_hwifdata (ide
> hwif->hwif_data = data;
> }
>
> -/* ide-lib.c */
> -extern char *ide_xfer_verbose(u8 xfer_rate);
> +const char *ide_xfer_verbose(u8);
> extern void ide_toggle_bounce(ide_drive_t *drive, int on);
> extern int ide_set_xfer_rate(ide_drive_t *drive, u8 rate);
Ideally function prototypes would include variable names, not just
types, as a helpful hint to readers of them.
---
~Randy
The Linux kernel requires that any needed documentation accompany all
changes requiring said documentation -- part of the source-code patch
must apply to the Documentation/ directory. [...]
To sum up: No undocumented changes.
-- Donnie Berkholz engages in some wishful thinking
Re: [PATCH] libata: Fix early use of port printk. (Was Re: ata4294967295: failed to start port (errno=-19))
Alan Cox wrote: On Fri, 30 Nov 2007 14:34:11 +0200 (EET) Meelis Roos <[EMAIL PROTECTED]> wrote: Can you stick a stack trace in at that point ? That would help diagnose it a great deal quicker. Finally done - found out hard way that BUG() is too bad and dump_st5ack() suits me better. Thanks. This should fix the real cause, and also allow for port start to fail politely with -ENODEV. Signed-off-by: Alan Cox <[EMAIL PROTECTED]> applied #upstream-fixes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/28] blk_end_request: changing ide normal caller (take 3)
On Saturday 01 December 2007, Kiyoshi Ueda wrote:
> This patch converts "normal" parts of ide to use blk_end_request().
>
> Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
> Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
> ---
> drivers/ide/ide-cd.c |6 +++---
> drivers/ide/ide-io.c | 17 ++---
> 2 files changed, 9 insertions(+), 14 deletions(-)
[...]
> Index: 2.6.24-rc3-mm2/drivers/ide/ide-io.c
> ===
> --- 2.6.24-rc3-mm2.orig/drivers/ide/ide-io.c
> +++ 2.6.24-rc3-mm2/drivers/ide/ide-io.c
> @@ -78,14 +78,9 @@ static int __ide_end_request(ide_drive_t
> ide_dma_on(drive);
> }
>
> - if (!end_that_request_chunk(rq, uptodate, nr_bytes)) {
> - add_disk_randomness(rq->rq_disk);
> - if (dequeue) {
> - if (!list_empty(>queuelist))
> - blkdev_dequeue_request(rq);
> + if (!__blk_end_request(rq, uptodate, nr_bytes)) {
> + if (dequeue)
> HWGROUP(drive)->rq = NULL;
> - }
> - end_that_request_last(rq, uptodate);
> ret = 0;
> }
Hmmm, this seems to change the old behavior (the request should
be dequeued from the queue only if 'dequeue' variable is set)
and AFAIR some error handling code (in ide-cd?) depends on the
old behavior so please revisit this patch.
Thanks,
Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 26/28] blk_end_request: changing ide-cd (take 3)
Hi,
On Saturday 01 December 2007, Kiyoshi Ueda wrote:
> This patch converts ide-cd (cdrom_newpc_intr()) to use blk_end_request().
>
> ide-cd (cdrom_newpc_intr()) has some tricky behaviors below which
> need to use blk_end_request_callback().
> Needs to:
> 1. call post_transform_command() to modify request contents
Seems like post_transform_command() call can be removed (patch below).
> 2. wait completing request until DRQ_STAT is cleared
Would be great if somebody convert cdrom_newpc_intr() to use scatterlists
also for PIO transfers (ide_pio_sector() in ide-taskfile.c should serve
as a good starting base to see how to do PIO transfers using scatterlists)
so we could get rid of partial request completions in cdrom_newpc_intr()
and just fully complete request when the transfer is done. Shouldn't be
difficult but I guess that we can live with blk_end_request_callback() for
the time being...
> after end_that_request_first() and before end_that_request_last().
>
> As for the second one, ide-cd will wait for the interrupt from device.
> So blk_end_request_callback() has to return without completing request
> even if no leftover in the request.
> ide-cd uses a dummy callback function, which just returns value '1',
> to tell blk_end_request_callback() about that.
>
> Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
> Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
[PATCH] ide-cd: remove dead post_transform_command()
post_transform_command() call in cdrom_newpc_intr() has no effect because
it is done after the request has already been fully completed (rq->bio and
rq->data are always NULL). It was verified to be true regardless whether
INQUIRY command is using DMA or PIO to transfer data (by using modified
Tejun Heo's test-shortsg.c utility and adding a few printk()-s to ide-cd).
This was uncovered thanks to the "blk_end_request: full I/O completion
handler (take 3)" patch series from Kiyoshi Ueda.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: Kiyoshi Ueda <[EMAIL PROTECTED]
Cc: Jun'ichi Nomura <[EMAIL PROTECTED]>
Cc: Tejun Heo <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
Kiyoshi: please rebase your patch on top of this one (I'll send
it to Linus in the next IDE update), should make your patch a bit
simpler.
Tejun: you had really good timing with posting test-shortsg.c
(it saved me some time coding user-space SG_IO tester), thanks!
drivers/ide/ide-cd.c | 28
1 file changed, 28 deletions(-)
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1650,31 +1650,6 @@ static int cdrom_write_check_ireason(ide
return 1;
}
-static void post_transform_command(struct request *req)
-{
- u8 *c = req->cmd;
- char *ibuf;
-
- if (!blk_pc_request(req))
- return;
-
- if (req->bio)
- ibuf = bio_data(req->bio);
- else
- ibuf = req->data;
-
- if (!ibuf)
- return;
-
- /*
-* set ansi-revision and response data as atapi
-*/
- if (c[0] == GPCMD_INQUIRY) {
- ibuf[2] |= 2;
- ibuf[3] = (ibuf[3] & 0xf0) | 2;
- }
-}
-
typedef void (xfer_func_t)(ide_drive_t *, void *, u32);
/*
@@ -1810,9 +1785,6 @@ static ide_startstop_t cdrom_newpc_intr(
return ide_started;
end_request:
- if (!rq->data_len)
- post_transform_command(rq);
-
spin_lock_irqsave(_lock, flags);
blkdev_dequeue_request(rq);
end_that_request_last(rq, 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: Peculiar out-of-sync boot log lines
Hi,
On Thursday 29 November 2007, Mark Lord wrote:
> Nick Warne wrote:
> > Hi all,
> >
> > 2.6.23.9
> >
> > I have noticed after applying Bart's patch to word93 blacklist my new
> > DVD drive:
> >
> > http://lkml.org/lkml/2007/10/23/475
> >
> > I see now in logs (look at the hdd line:
> >
> > [dmesg]
> > hdc: 39876480 sectors (20416 MB) w/2048KiB Cache, CHS=39560/16/63,
> > UDMA(66)
> > hdc: cache flushes not supported
> > hdc: hdc1
> > hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache<7>hdd:
> > skipping word 93 validity check
> > , UDMA(66)
> > Uniform CD-ROM driver Revision: 3.20
> >
> >
> > <7> ?? And the ", UDMA(66)" gets new lined, so in syslog it appears all
> > by itself:
> ...
>
> That's a minor bug with the patch.
>
> The code does this:
>
> ide_dma_verbose::printk( ... "2048kB Cache");
> eighty_ninty_three::printk(KERN_DEBUG "%s: skipping word 93 validity
> check\n");
> ide_dma_verbose::printk(", UDMA(66)"
Thanks for reporting/debugging it guys!
> Something in there needs to insert a '\n' before the "skipping word" message.
> Since it doesn't do that right now, the KERN_DEBUG string appears as "<7>"
This seems like a good occasion to fix ide_dma_verbose() for good so... :)
[ patch is against current Linus tree so might not apply to 2.6.23.9 ]
[PATCH] ide: DMA reporting and validity checking fixes
* ide_xfer_verbose() fixups:
- beautify returned mode names
- fix PIO5 reporting
- make it return 'const char *'
* Change printk() level from KERN_DEBUG to KERN_INFO in ide_find_dma_mode().
* Add ide_id_dma_bug() helper based on ide_dma_verbose() to check for invalid
DMA info in identify block.
* Use ide_id_dma_bug() in ide_tune_dma() and ide_driveid_update().
As a result DMA won't be tuned or will be disabled after tuning if device
reports inconsistent info about enabled DMA mode (ide_dma_verbose() does the
same checks while the IDE device is probed by ide-{cd,disk} device driver).
* Since (id->capability & 1) && id->tDMA is a valid configuration handle
it correctly in ide_id_dma_bug().
* Remove no longer needed ide_dma_verbose().
This patch should fix the following problem with out-of-sync IDE messages
reported by Nick Warned:
hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache<7>hdd:
skipping word 93 validity check
, UDMA(66)
and later debugged by Mark Lord to be caused by:
ide_dma_verbose()
printk( ... "2048kB Cache");
eighty_ninty_three()
printk(KERN_DEBUG "%s: skipping word 93 validity check\n");
ide_dma_verbose()
printk(", UDMA(66)"
Please note that as a result ide-{cd,disk} device drivers won't report the
DMA speed used but this is intended since now DMA mode being used is always
reported by IDE core code.
Cc: Nick Warne <[EMAIL PROTECTED]>
Cc: Mark Lord <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-cd.c |7 --
drivers/ide/ide-disk.c |5
drivers/ide/ide-dma.c | 57 -
drivers/ide/ide-iops.c |3 ++
drivers/ide/ide-lib.c | 55 ---
include/linux/ide.h|6 ++---
6 files changed, 51 insertions(+), 82 deletions(-)
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -3049,12 +3049,7 @@ int ide_cdrom_probe_capabilities (ide_dr
else
printk(" drive");
- printk(", %dkB Cache", be16_to_cpu(cap.buffer_size));
-
- if (drive->using_dma)
- ide_dma_verbose(drive);
-
- printk("\n");
+ printk(", %dkB Cache\n", be16_to_cpu(cap.buffer_size));
return nslots;
}
Index: b/drivers/ide/ide-disk.c
===
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -961,11 +961,8 @@ static void idedisk_setup (ide_drive_t *
if (id->buf_size)
printk (" w/%dKiB Cache", id->buf_size/2);
- printk(", CHS=%d/%d/%d",
+ printk(", CHS=%d/%d/%d\n",
drive->bios_cyl, drive->bios_head, drive->bios_sect);
- if (drive->using_dma)
- ide_dma_verbose(drive);
- printk("\n");
/* write cache enabled? */
if ((id->csfo & 1) || (id->cfs_enable_1 & (1 << 5)))
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -753,7 +753,7 @@ u8 ide_find_dma_mode(ide_drive_t *drive,
mode = XFER_MW_DMA_1;
}
- printk(KERN_DEBUG "%s: %s mode selected\n", drive->name,
+ printk(KERN_INFO "%s: %s mode selected\n", drive->name,
mode ? ide_xfer_verbose(mode) : "no DMA");
return min(mode, req_mode);
@@ -772,6
Re: PROBLEM: System Freeze on Particular workload with kernel 2.6.22.6
Hmm, I wonder if this had something to do with it: > [ 25.856573] VFS: Disk quotas dquot_6.5.1 Was the system still pingable? Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [libata] Set proper ATA UDMA mode for bf548 according to system clock.
sonic zhang wrote: UDMA Mode - Frequency compatibility UDMA5 - 100 MB/s - SCLK = 133 MHz UDMA4 - 66 MB/s- SCLK >= 80 MHz UDMA3 - 44.4 MB/s - SCLK >= 50 MHz UDMA2 - 33 MB/s- SCLK >= 40 MHz Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]> --- drivers/ata/pata_bf54x.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) applied #upstream-fixes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
On Sun, 2 Dec 2007 00:34:03 +0300 Anton Vorontsov wrote: > > If i understand your code correctly, you seem to rely on the fact > > that fixed_phy_add() is called before the fixed MDIO bus is scanned > > for devices. > > Yes, indeed. The other name of "fixed phys" are "platform phys" > or "platform MDIO bus" on which virtual PHYs are placed. > > That is, these phys supposed to be created by the platform setup > code (arch/). The rationale here is: we do hardware emulation, thus > to make drivers actually see that "hardware", we have to create it > early. well that was the intention but... The point is - as device is emulated, (nearly) everything is doable, and the only tradeoff to consider, is how far will we go with that emulation. IOW, PHYlib could be tricked to "do the right thing", and I thought about adding module flexibility... But thinking more about it, it seems that BSP-code-phy-creation just sucks less and is clear enough yet flexible. -- Sincerely, Vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
On Sat, 01 Dec 2007 16:59:52 -0500 Jeff Garzik wrote: > Vitaly Bordug wrote: > > With that patch fixed.c now fully emulates MDIO bus, thus no need > > to duplicate PHY layer functionality. That, in turn, drastically > > simplifies the code, and drops down line count. > > > > As an additional bonus, now there is no need to register MDIO bus > > for each PHY, all emulated PHYs placed on the platform fixed MDIO > > bus. There is also no more need to pre-allocate PHYs via .config > > option, this is all now handled dynamically. > > > > p.s. Don't even try to understand patch content! Better: apply patch > > and look into resulting drivers/net/phy/fixed.c. > > > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> > > what's the context of this patchset? 2.6.25? > Fine with it. > it's late for 2.6.24-rc, IMO. > > Do I have the latest version (sent Nov 26 @ 9:29am)? yes, that's it. -- Sincerely, Vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: namespace support requires network modules to say "GPL"
Arjan van de Ven wrote: On Sat, 01 Dec 2007 15:21:12 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: Eric W. Biederman wrote: Stephen Hemminger <[EMAIL PROTECTED]> writes: Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. .. And what should code be passing in when "# CONFIG_NET_NS is not set" ? network drivers probably really really don't want to call dev_get_by_XXX... .. Fine. But all of them want to call sk_alloc(), and many want to do register_netdev(). So what should they be using there ? And please STOP trimming the CC list. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: namespace support requires network modules to say "GPL"
Arjan van de Ven wrote: On Sat, 01 Dec 2007 15:21:12 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: Eric W. Biederman wrote: Stephen Hemminger <[EMAIL PROTECTED]> writes: Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. .. And what should code be passing in when "# CONFIG_NET_NS is not set" ? network drivers probably really really don't want to call dev_get_by_XXX... .. Fine. But all of them want to call sk_alloc(), and many want to do register_netdev(). So what should they be using there ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
Vitaly Bordug wrote: With that patch fixed.c now fully emulates MDIO bus, thus no need to duplicate PHY layer functionality. That, in turn, drastically simplifies the code, and drops down line count. As an additional bonus, now there is no need to register MDIO bus for each PHY, all emulated PHYs placed on the platform fixed MDIO bus. There is also no more need to pre-allocate PHYs via .config option, this is all now handled dynamically. p.s. Don't even try to understand patch content! Better: apply patch and look into resulting drivers/net/phy/fixed.c. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> what's the context of this patchset? 2.6.25? it's late for 2.6.24-rc, IMO. Do I have the latest version (sent Nov 26 @ 9:29am)? 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/
2.6.24-rc3-git6: Reported regressions from 2.6.23
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 : EHCI causes 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]> David Brownell <[EMAIL PROTECTED]> Alan Stern <[EMAIL PROTECTED]> Patch : Note: : the problem appears to heavily depend on hardware 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 : Richard Purdie <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=13493=view 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 : pdflush stuck in D state with v2.6.24-rc1-192-gef49c32 Submitter : Florin Iucha <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/10/28/65 http://bugzilla.kernel.org/show_bug.cgi?id=9291 Handled-By : Trond Myklebust <[EMAIL PROTECTED]> Fengguang Wu <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/11/1/417 Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object Submitter : Hans de Bruin <[EMAIL PROTECTED]> References : http://bugzilla.kernel.org/show_bug.cgi?id=9320 Handled-By : Robert Moore <[EMAIL PROTECTED]> Tejun Heo <[EMAIL PROTECTED]> Fu Michael <[EMAIL PROTECTED]> Patch : 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 Handled-By : Tejun Heo <[EMAIL PROTECTED]> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/11/11/115 Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always work on Lenovo X60s Submitter : Roland Dreier <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/11/8/255 http://bugzilla.kernel.org/show_bug.cgi?id=9332 Handled-By : Patch : Subject : system hangs after a few minutes Submitter : Marcus Better <[EMAIL PROTECTED]> References : http://bugzilla.kernel.org/show_bug.cgi?id=9335 Handled-By : Andrew Morton <[EMAIL PROTECTED]> Alan Stern <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=13762=view Subject : 2.6.24 regression: hibernation hangs on "Suspending console" in low-battery condition Submitter : Andrey Borzenkov <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/11/11/28 http://bugzilla.kernel.org/show_bug.cgi?id=9344 Handled-By : "Rafael J. Wysocki" <[EMAIL PROTECTED]> Alexey Starikovskiy <[EMAIL PROTECTED]> Patch : Note: Not reproducible with -rc3 Subject : 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading Submitter : Chris Friedhoff <[EMAIL PROTECTED]> References : http://lkml.org/lkml/2007/11/10/114 http://bugzilla.kernel.org/show_bug.cgi?id=9345 Handled-By : "Rafael J. Wysocki" <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=13651=view 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 : Len Brown <[EMAIL PROTECTED]> Tejun Heo <[EMAIL PROTECTED]> Patch : Subject : The keyboard doesn't work Submitter : Francois Valenduc <[EMAIL PROTECTED]> References :
Re: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
On Sat, Dec 01, 2007 at 02:48:54PM +0100, Jochen Friedrich wrote:
> Hi Vitaly,
>
> > With that patch fixed.c now fully emulates MDIO bus, thus no need
> > to duplicate PHY layer functionality. That, in turn, drastically
> > simplifies the code, and drops down line count.
> >
> > As an additional bonus, now there is no need to register MDIO bus
> > for each PHY, all emulated PHYs placed on the platform fixed MDIO bus.
> > There is also no more need to pre-allocate PHYs via .config option,
> > this is all now handled dynamically.
> >
> > p.s. Don't even try to understand patch content! Better: apply patch
> > and look into resulting drivers/net/phy/fixed.c.
> >
> If i understand your code correctly, you seem to rely on the fact
> that fixed_phy_add() is called before the fixed MDIO bus is scanned for
> devices.
Yes, indeed. The other name of "fixed phys" are "platform phys"
or "platform MDIO bus" on which virtual PHYs are placed.
That is, these phys supposed to be created by the platform setup
code (arch/). The rationale here is: we do hardware emulation, thus
to make drivers actually see that "hardware", we have to create it
early.
> I tried to add fixed-phy support to fs_enet, but the fixed phy is not
> found this way.
>
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1174,8 +1175,24 @@ static int __devinit find_phy(struct device_node *np,
> struct device_node *phynode, *mdionode;
> struct resource res;
> int ret = 0, len;
> + const u32 *data;
> + struct fixed_phy_status status = {};
> +
> + data = of_get_property(np, "fixed-link", NULL);
> + if (data) {
> + status.link = 1;
> + status.duplex = data[1];
> + status.speed = data[2];
> +
> + ret = fixed_phy_add(PHY_POLL, data[0], );
> + if (ret)
> + return ret;
> +
> + snprintf(fpi->bus_id, 16, PHY_ID_FMT, 0, *data);
> + return 0;
> + }
>
> - const u32 *data = of_get_property(np, "phy-handle", );
> + data = of_get_property(np, "phy-handle", );
> if (!data || len != 4)
> return -EINVAL;
^^ the correct solution is to implement arch_initcall function
which will create fixed PHYs, and then leave only
snprintf(fpi->bus_id, 16, PHY_ID_FMT, 0, *data); part in the
fs_enet's find_phy().
Try add something like this to the fsl_soc.c (compile untested):
- - - -
static int __init of_add_fixed_phys(void)
{
struct device_node *np;
const u32 *prop;
struct fixed_phy_status status = {};
while ((np = of_find_node_by_name(NULL, "ethernet"))) {
data = of_get_property(np, "fixed-link", NULL);
if (!data)
continue;
status.link = 1;
status.duplex = data[1];
status.speed = data[2];
ret = fixed_phy_add(PHY_POLL, data[0], );
if (ret)
return ret;
}
return 0;
}
arch_initcall(of_add_fixed_phys);
- - - -
And remove fixed_phy_add() from the fs_enet. This should work
nicely and also should be ideologically correct. ;-)
> How is this supposed to work for modules or for the
> PPC_CPM_NEW_BINDING mode where the device tree is no longer scanned
> during fs_soc initialization but during device initialization?
We should mark fixed.c as bool. Fake/virtual/fixed/platform PHYs
creation is architecture code anyway, can't be =m.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] GIT 1.5.3.7
The latest maintenance release GIT 1.5.3.7 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.3.7.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.3.7.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.3.7.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.3.7-1.$arch.rpm (RPM)
What's cooking for upcoming feature release v1.5.4 has been stablizing,
and hopefully this will be the last of v1.5.3 maintenance series.
By the way, if you are the package maintainer of git for a distro, or
the editor of an OSS oriented publication, and if you would like a copy
of release announcements, please let me know, so that I can add your
e-mail address to Bcc: on future announcement mails. Sorry, but I
cannot handle subscription requests from individuals.
GIT v1.5.3.7 Release Notes
==
Fixes since v1.5.3.6
* git-send-email added 8-bit contents to the payload without
marking it as 8-bit in a CTE header.
* "git-bundle create a.bndl HEAD" dereferenced the symref and
did not record the ref as 'HEAD'; this prevented a bundle
from being used as a normal source of git-clone.
* The code to reject nonsense command line of the form
"git-commit -a paths..." and "git-commit --interactive
paths..." were broken.
* Adding a signature that is not ASCII-only to an original
commit that is ASCII-only would make the result non-ASCII.
"git-format-patch -s" did not mark such a message correctly
with MIME encoding header.
* git-add sometimes did not mark the resulting index entry
stat-clean. This affected only cases when adding the
contents with the same length as the previously staged
contents, and the previous staging made the index entry
"racily clean".
* git-commit did not honor GIT_INDEX_FILE the user had in the
environment.
* When checking out a revision, git-checkout did not report where the
updated HEAD is if you happened to have a file called HEAD in the
work tree.
* "git-rev-list --objects" mishandled a tree that points at a
submodule.
* "git cvsimport" was not ready for packed refs that "git gc" can
produce and gave incorrect results.
* Many scripted Porcelains were confused when you happened to have a
file called "HEAD" in your work tree.
Also it contains updates to the user manual and documentation.
Changes since v1.5.3.6 are as follows:
Björn Steinbrink (3):
git-commit.sh: Fix usage checks regarding paths given when they do not
make sense
t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
git-commit: Add tests for invalid usage of -a/--interactive with paths
Brian Downing (2):
config: correct core.loosecompression documentation
config: clarify compression defaults
J. Bruce Fields (7):
git-remote.txt: fix example url
user-manual: mention "..." in "Generating diffs", etc.
Documentation: Fix references to deprecated commands
user-manual: define "branch" and "working tree" at start
user-manual: failed push to public repository
user-manual: clarify language about "modifying" old commits
user-manual: recovering from corruption
Jan Hudec (1):
Improve description of git-branch -d and -D in man page.
Jeff King (5):
send-email: add transfer encoding header with content-type
Add basic cvsimport tests
cvsimport: use rev-parse to support packed refs
cvsimport: miscellaneous packed-ref fixes
cvsimport: fix usage of cvsimport.module
Johannes Schindelin (2):
bundle create: keep symbolic refs' names instead of resolving them
Replace the word 'update-cache' by 'update-index' everywhere
Johannes Sixt (1):
t7003-filter-branch: Fix test of a failing --msg-filter.
Junio C Hamano (11):
format-patch -s: add MIME encoding header if signer's name requires so
test format-patch -s: make sure MIME content type is shown as needed
ce_match_stat, run_diff_files: use symbolic constants for readability
git-add: make the entry stat-clean after re-adding the same contents
t2200: test more cases of "add -u"
Make test scripts executable.
Fix sample pre-commit hook
git-checkout: describe detached head correctly
scripts: do not get confused with HEAD in work tree
Fix typo in t4008 test title
GIT 1.5.3.7
Linus Torvalds (1):
Fix rev-list when showing objects involving submodules
Matthieu Moy (1):
Doc fix for git-reflog: mention @{...} syntax, and in synopsys.
Rémi Vanicat (1):
Make GIT_INDEX_FILE apply to git-commit
Steffen Prohaska (1):
user-manual: Add section "Why bisecting merge commits can be harder ..."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Re: [PATCH 1/3] cxgb - fix T2 GSO
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> The patch ensures that a GSO skb has enough headroom to push an encapsulating cpl_tx_pkt_lso header. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- applied 1-3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] cops/atalk hung bootup with 2.6.23-rc4
> and a hung bootup. Config and bootlog attached. I guess the core problem > is that somehow the the cops driver got registered to IRQ5: > > [ 23.067416] lt0: cops at 0x240, IRQ 5, in Tangent mode > > is this an old ISA driver perhaps that should i exclude from this > randconfig testing? Its an ISA driver for localtalk so yes I would exclude 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: [Bugme-new] [Bug 9482] New: kernel GPF in 2.6.24 (g09f345da)
On 12/1/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > (switched to email - please respond via emailed reply-to-all, not via the > bugzilla web interface) > > On Sat, 1 Dec 2007 11:54:11 -0800 (PST) [EMAIL PROTECTED] wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=9482 > > > >Summary: kernel GPF in 2.6.24 (g09f345da) > >Product: Other > >Version: 2.5 > > KernelVersion: 2.6.24rc3 g09f345da > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Other > > AssignedTo: [EMAIL PROTECTED] > > ReportedBy: [EMAIL PROTECTED] > > > > > > Most recent kernel where this bug did not occur: 2.6.22.12 > > Distribution: openSUSE 10.3 > > Hardware Environment: Athlon XP 2200+ > > Software Environment: openSUSE 10.3 > > Problem Description: instant kernel GPF. > > > > Steps to reproduce:load module aoe (vanilla), type 'mkfs.ext3 > > /dev/etherd/e0.0', and the kernel GPFs. > > > > Will be attaching jpg of screen - sorry, no other way to capture GPF for me. > > > > http://bugzilla.kernel.org/attachment.cgi?id=13812=view > > Damn that's odd. General Protection Fault in > __set_page_dirty->__percpu_counter_add(). No sign of AOE in the trace. > > I assume that it is repeatable and that it doesn't occur with mkfs on > regular local disk drives? This works fine: mkfs.ext3 /dev/system/test a local LVM2-based logical volume mkfs.ext3 /dev/etherd/e0.0 ## Boom. -- Jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at kernel/resource.c:189 __release_resource
On Thu, 29 Nov 2007 16:40:37 -0700 Bjorn Helgaas <[EMAIL PROTECTED]> wrote: > > The corresponding PCI code in pci_device_suspend() does not do > any generic device disable or resource release. I don't know > why PNP disables the device on suspend. I glanced through the > ACPI spec but didn't see a requirement for it. Maybe Pierre [1] > remembers. > Afraid not. There was a reason for it, but my mind draws a blank as to what that was... I have a slight recollection of bad BIOS interaction during STR, but I'm not sure it was related to this specific patch. Rgds Pierre signature.asc Description: PGP signature
Re: m68k build failure
On Wed, 28 Nov 2007 13:34:02 +0100 (CET) Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > On Wed, 28 Nov 2007, Pierre Ossman wrote: > > > > Is there no directive we can stick in there that forces a reasonable > > alignment (e.g. alignment == sizeof(type)) independently of arch? > > We could use something like is used for compat_*. > E.g. compare compat_s64 in for x86 and powerpc. > Yeah, that could work. Have a header with stuff like this: typedef u16 __attribute__((aligned(2))) aligned_u16; typedef u32 __attribute__((aligned(4))) aligned_u32; and let all structures in mod_devicetable.h use those types. Now does anyone have the time to code and test this? Rgds Pierre signature.asc Description: PGP signature
Re: [BUG] Strange 1-second pauses during Resume-from-RAM
* J??rn Engel <[EMAIL PROTECTED]> wrote: > Almost. "-serial stdio" was missing. Much better now. > > stopped custom tracer. > BUG: spinlock recursion on CPU#0, sh/953 > lock: c030f280, .magic: dead4ead, .owner: sh/953, .owner_cpu: 0 > Pid: 953, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty #2 > [] show_trace_log_lvl+0x35/0x54 > [] show_trace+0x2c/0x2e > [] dump_stack+0x84/0x8a > [] spin_bug+0xa7/0xae > [] _raw_spin_lock+0x45/0xfa > [] _spin_lock_irqsave+0x68/0x7a > [] pit_read+0x14/0x99 > [] get_monotonic_cycles+0xf/0x2d ah. You should mark pit_read() function as notrace. PIT clocksource is rare. (add the 'notrace' word to the function prototype) 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: namespace support requires network modules to say "GPL"
Mark Lord <[EMAIL PROTECTED]> writes: >>> Can we get this resolved before 2.6.24 is released? Going back and forth >>> on API's is just needless frottage. >> >> Sure. We keep the updated dev_get_by_ that takes a network >> namespace parameter. > .. > > And what should code be passing in when "# CONFIG_NET_NS is not set" ? Mostly CONFIG_NET_NS is a define to keep us from exposing the feature to user space not to remove the code impact. People could not stand the look of the code that would actually allow us to compile everything out. So all of the struct net * fields remain when !CONFIG_NET_NS. Including the global variable init_net. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Strange 1-second pauses during Resume-from-RAM
On Sat, 1 December 2007 19:32:56 +0100, Ingo Molnar wrote: > * Jörn Engel <[EMAIL PROTECTED]> wrote: > > > I have to change my qemu setup a little to see the top of those > > dumps... > > btw., if you start qemu like this: > > qemu -cdrom ./cdrom.iso -hda ./hda.img -boot c -full-screen -kernel > ~/bzImage -append "root=/dev/hda1 earlyprintk=serial,ttyS0,9600 > console=tty console=ttyS0,9600 enforcing=0 debug" > > you'll get the inner kernel's serial console log to qemu's standard > output. Pretty useful for capturing kernel crashes. Almost. "-serial stdio" was missing. Much better now. stopped custom tracer. BUG: spinlock recursion on CPU#0, sh/953 lock: c030f280, .magic: dead4ead, .owner: sh/953, .owner_cpu: 0 Pid: 953, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty #2 [] show_trace_log_lvl+0x35/0x54 [] show_trace+0x2c/0x2e [] dump_stack+0x84/0x8a [] spin_bug+0xa7/0xae [] _raw_spin_lock+0x45/0xfa [] _spin_lock_irqsave+0x68/0x7a [] pit_read+0x14/0x99 [] get_monotonic_cycles+0xf/0x2d [] now+0x2a/0x7c [] trace+0x4d/0x1e8 [] __mcount+0x95/0xa6 [] mcount+0x14/0x18 [] lock_acquired+0xe/0x1d7 [] _spin_lock_irqsave+0x70/0x7a [] pit_read+0x14/0x99 [] update_wall_time+0x23/0x692 [] do_timer+0x24/0xb1 [] tick_periodic+0x49/0x84 [] tick_handle_periodic+0x22/0x73 [] timer_interrupt+0x4f/0x56 [] handle_IRQ_event+0x24/0x4f [] handle_edge_irq+0xb8/0x125 [] do_IRQ+0x89/0xa3 [] common_interrupt+0x23/0x28 [] vfs_write+0xa6/0x14c [] sys_write+0x4c/0x70 [] syscall_call+0x7/0xb === I assume you have the latency tracer working. If you could send me your config, I could do a manual config-bisect and see which part of mine causes the problem. Jörn -- Admonish your friends privately, but praise them openly. -- Publilius Syrus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Tokyo Electron SDIO controller (Ellen) support
On Sat, 01 Dec 2007 00:27:06 -0800 Vitaly Luban <[EMAIL PROTECTED]> wrote: > Kernel "pci_ids.h" file has data for that card missing. > > Also, Ellen needs some control bits flipped before it functions properly > as SDIO controller by the spec. > Should apply clenly to Linus and Drzeus trees. Please apply. > > Signed-off-by: Vitaly Luban <[EMAIL PROTECTED]> > > The illiteracy rates for hardware engineers must be through the roof. Nobody seems capable of reading specifications anymore... As for the patch, it's a big NAK at this point. Vendors who can't be bothered to follow the standard will have to wait for Ben's separation patches before they can be supported. Then they can have some voodoo front-end to handle their mistakes instead of turning sdhci.c into a collection of hacks and workarounds. Rgds Pierre signature.asc Description: PGP signature
Re: Executable file format, locating stack?
On Sat, 1 Dec 2007 10:09:28 -0800 "Joshua Hudson" <[EMAIL PROTECTED]> wrote: > Is there an executable file format that can specify things like where > the stack ends up? > Yes, I really do care. I want to put the stack at the top of virtual > address space rather than randomized. just set the personality with setarch if you don't want randomisation. Why is it that you can't cope with randomization? You'll have SOME randomziation no matter what because each glibc compile will have a slightly different footprint on the stack before your app gets to it, as do the various environment variables and kernel AT_ variables. -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Since sysfs_mount is static and used only in sysfs_init function, it could be just an automatic variable.
---
and I still have questions about this code:
1. Why here kern_mount is needed?
Or the first time user space `mount -t sysfs` won't do that?
2. If root executes many mounts to mount sysfs on /sys and many other places,
are there many instances of struct vfsmount those have only
mnt_mountpoint different?
For most common case, mount a virtual filesystem(proc, sysfs, ...) on
multiple mounting point,
how to handle it more efficiently?
and where is a detailed explaination on kern_mount? could someone give
some comments or documentation pointers on this?
diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
index 7416826..add0dda 100644
--- a/fs/sysfs/mount.c
+++ b/fs/sysfs/mount.c
@@ -22,7 +22,6 @@
/* Random magic number */
#define SYSFS_MAGIC 0x62656572
-static struct vfsmount *sysfs_mount;
struct super_block * sysfs_sb = NULL;
struct kmem_cache *sysfs_dir_cachep;
@@ -98,11 +97,10 @@ int __init sysfs_init(void)
err = register_filesystem(_fs_type);
if (!err) {
- sysfs_mount = kern_mount(_fs_type);
+ struct vfsmount *sysfs_mount = kern_mount(_fs_type);
if (IS_ERR(sysfs_mount)) {
printk(KERN_ERR "sysfs: could not mount!\n");
err = PTR_ERR(sysfs_mount);
- sysfs_mount = NULL;
unregister_filesystem(_fs_type);
goto out_err;
}
--
Denis Cheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: namespace support requires network modules to say "GPL"
On Sat, 01 Dec 2007 15:21:12 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > Eric W. Biederman wrote: > > Stephen Hemminger <[EMAIL PROTECTED]> writes: > > Sure. We keep the updated dev_get_by_ that takes a network > > namespace parameter. > .. > > And what should code be passing in when "# CONFIG_NET_NS is not set" ? network drivers probably really really don't want to call dev_get_by_XXX... in fact no NIC driver in drivers/net does so! Sounds like whatever driver you're looking at has a nasty bug in that it's using non-driver APIs... -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 9482] New: kernel GPF in 2.6.24 (g09f345da)
(switched to email - please respond via emailed reply-to-all, not via the bugzilla web interface) On Sat, 1 Dec 2007 11:54:11 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9482 > >Summary: kernel GPF in 2.6.24 (g09f345da) >Product: Other >Version: 2.5 > KernelVersion: 2.6.24rc3 g09f345da > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Most recent kernel where this bug did not occur: 2.6.22.12 > Distribution: openSUSE 10.3 > Hardware Environment: Athlon XP 2200+ > Software Environment: openSUSE 10.3 > Problem Description: instant kernel GPF. > > Steps to reproduce:load module aoe (vanilla), type 'mkfs.ext3 > /dev/etherd/e0.0', and the kernel GPFs. > > Will be attaching jpg of screen - sorry, no other way to capture GPF for me. > http://bugzilla.kernel.org/attachment.cgi?id=13812=view Damn that's odd. General Protection Fault in __set_page_dirty->__percpu_counter_add(). No sign of AOE in the trace. I assume that it is repeatable and that it doesn't occur with mkfs on regular local disk drives? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: namespace support requires network modules to say "GPL"
Eric W. Biederman wrote: Stephen Hemminger <[EMAIL PROTECTED]> writes: Actually, the whole mess would go away if the api for dev_get_by_ hadn't been changed in the namespace transition. IMHO the interface to dev_get_by_name() should not have added a namespace parameter, of the callers in the tree, only two use a different namespace. So it would have been better to to introduce dev_get_by_name_ns() with the extra parameter. As a general rule if you are calling dev_get_by_name and taking an _net parameter that means you code has not yet been converted to actually support network namespaces. Not everything can be safely changed at once so we take it by steps. When the code fully supports network namespaces practically nothing will take an _net parameter. The network namespace parameter will come in some form from userspace. Either from current or from the network socket. Except for boot time initialization I don't know of any cases using dev_get_by_ that won't need to be modified before the network namespace work is complete. I believe I mentioned that this getting the fully network namespace support was going to take a while and a bunch of patches at the outset. Can we get this resolved before 2.6.24 is released? Going back and forth on API's is just needless frottage. Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. .. And what should code be passing in when "# CONFIG_NET_NS is not set" ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: namespace support requires network modules to say "GPL"
Stephen Hemminger <[EMAIL PROTECTED]> writes: > Actually, the whole mess would go away if the api for dev_get_by_ hadn't > been changed in the namespace transition. IMHO the interface to > dev_get_by_name() > should not have added a namespace parameter, of the callers in the tree, only > two use a different namespace. So it would have been better to to introduce > dev_get_by_name_ns() with the extra parameter. As a general rule if you are calling dev_get_by_name and taking an _net parameter that means you code has not yet been converted to actually support network namespaces. Not everything can be safely changed at once so we take it by steps. When the code fully supports network namespaces practically nothing will take an _net parameter. The network namespace parameter will come in some form from userspace. Either from current or from the network socket. Except for boot time initialization I don't know of any cases using dev_get_by_ that won't need to be modified before the network namespace work is complete. I believe I mentioned that this getting the fully network namespace support was going to take a while and a bunch of patches at the outset. > Can we get this resolved before 2.6.24 is released? Going back and forth > on API's is just needless frottage. Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. Or is their some legitimate usage of it by out of tree code that I'm not aware of? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fedora's latest gcc produces unbootable kernels
On Sat, 01 Dec 2007 13:37:44 -0500 Bill Davidsen <[EMAIL PROTECTED]> wrote: > If you are referring to the "compat" RPMs, be aware that they use the > current headers, which is a good or bad thing depending on what you want > to do. If you want to build old software, you get to keep a down-rev > virtual machine to do it right :-( > Nah. The previous gcc package is the one shipped with Fedora 8. So I could just grab that one (plus cpp and libgomp) and downgrade. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.6.23.9 / P35 Chipset + WD 750GB Drives (reset port)
Justin Piszcz wrote: I am putting a new machine together and I have dual raptor raid 1 for the root, which works just fine under all stress tests. Then I have the WD 750 GiB drive (not RE2, desktop ones for ~150-160 on sale now adays): I ran the following: dd if=/dev/zero of=/dev/sdc dd if=/dev/zero of=/dev/sdd dd if=/dev/zero of=/dev/sde (as it is always a very good idea to do this with any new disk) And sometime along the way(?) (i had gone to sleep and let it run), this occurred: [42880.680144] ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x401 action 0x2 frozen [42880.680231] ata3.00: irq_stat 0x00400040, connection status changed [42880.680290] ata3.00: cmd ec/00:00:00:00:00/00:00:00:00:00/00 tag 0 cdb 0x0 data 512 in [42880.680292] res 40/00:ac:d8:64:54/00:00:57:00:00/40 Emask 0x10 (ATA bus error) [42881.841899] ata3: soft resetting port [42885.966320] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [42915.919042] ata3.00: qc timeout (cmd 0xec) [42915.919094] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5) [42915.919149] ata3.00: revalidation failed (errno=-5) [42915.919206] ata3: failed to recover some devices, retrying in 5 secs [42920.912458] ata3: hard resetting port [42926.411363] ata3: port is slow to respond, please be patient (Status 0x80) [42930.943080] ata3: COMRESET failed (errno=-16) [42930.943130] ata3: hard resetting port [42931.399628] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [42931.413523] ata3.00: configured for UDMA/133 [42931.413586] ata3: EH pending after completion, repeating EH (cnt=4) [42931.413655] ata3: EH complete [42931.413719] sd 2:0:0:0: [sdc] 1465149168 512-byte hardware sectors (750156 MB) [42931.413809] sd 2:0:0:0: [sdc] Write Protect is off [42931.413856] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [42931.413867] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Usually when I see this sort of thing with another box I have full of raptors, it was due to a bad raptor and I never saw it again after I replaced the disk that it happened on, but that was using the Intel P965 chipset. For this board, it is a Gigabyte GSP-P35-DS4 (Rev 2.0) and I have all of the drives (2 raptors, 3 750s connected to the Intel ICH9 Southbridge). I am going to do some further testing but does this indicate a bad drive? Bad cable? Bad connector? Could be any of the above. As you can see above, /dev/sdc stopped responding for a little bit and then the kernel reset the port. It looks like the first thing that happened is that the controller reported it lost the SATA link, and then the drive didn't respond until it was bashed with a few hard resets.. Why is this though? What is the likely root cause? Should I replace the drive? Obviously this is not normal and cannot be good at all, the idea is to put these drives in a RAID5 and if one is going to timeout that is going to cause the array to go degraded and thus be worthless in a raid5 configuration. Can anyone offer any insight here? Thank you, Justin. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: Kernel Development & Objective-C
Kyle Moffett wrote: In the kernel though, there are many codepaths where *every* *single* instruction counts; that could be a serious performance hit. Write *those* *codepaths* in *C* or *assembly*. But only after you manage to measure a difference compared to the object-oriented systems language. [I really doubt there are that many of these; syscall entry/dispatch/exit, interrupt dispatch, context switch, what else?] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development & Objective-C
Lennart Sorensen wrote: On Thu, Nov 29, 2007 at 12:14:16PM +, Ben Crowhurst wrote: Has Objective-C ever been considered for kernel development? Doesn't objective C essentially require a runtime to provide a lot of the features of the language? If it does (as I suspect) then it is totally unsiatable for kernel development. C also requires a (very minimal) runtime. And I don't see how having a runtime disqualifies a language from being usable in a kernel; the runtime is just one more library, either supplied by the compiler or by the kernel. Besides the kernel does a wonderful job doing object oriented design where apropriate using C without any of the stupidities added by the common OO languages Object orientation in C leaves much to be desired; see the huge number of void pointers and container_of()s in the kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc3-git4 build warnings
On Sat, Dec 01, 2007 at 07:49:46PM +, Chris Clayton wrote: > On Saturday 01 December 2007, Adrian Bunk wrote: > > On Thu, Nov 29, 2007 at 02:19:49PM +, Chris Clayton wrote: > > > Hi, > > > > > > I've just built 2.6.24-rc3-git4 and got the following two warnings. > > > > > > LD .tmp_vmlinux1 > > > KSYM .tmp_kallsyms1.S > > > AS .tmp_kallsyms1.o > > > LD .tmp_vmlinux2 > > > KSYM .tmp_kallsyms2.S > > > AS .tmp_kallsyms2.o > > > LD vmlinux.o > > > MODPOST vmlinux.o > > > WARNING: vmlinux.o(.text+0x90b6): Section mismatch: reference to > > > .init.text:cache_remove_shared_cpu_map (between 'free_cache_attributes' > > > and 'show_level') > > > WARNING: vmlinux.o(.init.text+0x143bd): Section mismatch: reference to > > > .exit.text:cpufreq_stats_free_table (between 'cpufreq_stat_cpu_callback' > > > and 'cpufreq_stats_init') > > >... > > > > You seem to be using gcc 3.3 or 3.4. > > Yes, it's 3.3.6. README in the top-level kernel source directory says "Make > sure you have at least gcc 3.2 available", so that should be OK, shouldn't > it? >... Yes, that's OK and 3.3.6 is a supported compiler for the kernel. > Chris 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: Kernel Development & Objective-C
Al Viro wrote: On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote: An vtable in C++ takes exactly the same space that the function table pointer present in every driver nowadays... and probably the virtual method call that C++ does itself with thing->do_something(with,this) like push thing push with push this call THING_vtable+indexof(do_something) // constants at compile time This is not what vtables are. Think for a minute - all codepaths arriving to that point in your code will pick the address to call from the same location. Either the contents of that location is constant (in which case you could bloody well call it directly in the first place) *or* it has to somehow be reassigned back and forth, according to the value of this. The former is dumb, the latter - outright insane. The contents of vtables is constant. The whole point of that thing is to deal with the situations where we _can't_ tell which derived class this ->do_something() is from; if we could tell which vtable it is at compile time, we wouldn't need to bother at all. It's a tradeoff - we pay the extra memory access (fetch vtable pointer, then fetch method from vtable) for not having to store a slew of method pointers in each instance of base class. But the extra memory access is very much there. It can be further optimized away if you have several method calls for the same object next to each other (then vtable can be picked once), but it's still done at runtime. True. C++ vtables have no performance advantage over C ->ops->function() calls. But they have no disadvantage either and they do offer many syntactic advantages (such as automatically casting the object type to the *correct* derived class. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: namespace support requires network modules to say "GPL"
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> On Sat, 01 Dec 2007 08:10:17 -0500
> Mark Lord <[EMAIL PROTECTED]> wrote:
>
>> > Now that we have network namespace support merged it is time to
>> > revisit the sysfs support so we can remove the dependency on !SYSFS.
>> ...
>>
>> Now that the namespace updates are part of 2.6.24,
>> there is a major inconsistency in network EXPORT_SYMBOLs.
>>
>> It used to be that an external network module could get away without
>> having to add a MODULE_LICENSE("GPL*") line to the source.
>>
>> In support of that, common networking functions (still) use EXPORT_SYMBOL()
>> rather than the more restrictive EXPORT_SYMBOL_GPL().
>>
>> Eg. register_netdev(), sk_alloc(), __dev_get_by_name().
>>
>> But now, none of those three are actually usable by default,
>> because they all require "init_net", which is EXPORT_SYMBOL_GPL().
Which alternative kernel does the above comment apply to?
> Then init_net needs to be not GPL limited. Sorry, we need to allow
> non GPL network drivers.
For the record network drivers should not be affected. As a practical
measure that just gets unmaintainable and it is unnecessary.
There are specific exceptions where network drivers mess with the userspace
interfaces where I do have some impact. However if you are messing
with our userspace interface especially with network namespaces in place
I don't see how it is possible for you to be anything other then a derivative
work, and something we need in tree to keep maintenance a manageable thing.
It should just be the core of the network stack that struct net has some
effect on.
> There is a fine line between keeping the
> binary seething masses from accessing random kernel functions, and allowing
> reasonable (but still non GPL) things like ndiswrapper to use network
> device interface.
Does ndiswrapper break? If so what dubious and unsupportable thing is
it doing?
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Freezer: Fix JFFS2 garbage collector freezing issue (was: Re: JFFS2 garbage collection threads not freezing?)
On Friday, 30 of November 2007, Pete MacKay wrote:
> We've ported from 2.6.18 to 2.6.24-rc3 on a pxa270-based machine and can
> no longer enter 'standby' or 'mem' states. I've stripped down the kernel
> and talked with the freezer maintainer and we believe the jffs2 garbage
> collection threads may not be calling try_to_freeze() or marking
> themselves properly. (We have two mounted jffs2 file systems - mtd2 and
> mtd3). The following is some cleaned-up output:
>
> Freezing remaining freezable tasks ...
> Freezing of tasks failed after 20.00 seconds (2 tasks refusing to freeze):
> taskPC stack pid father
> init D c0244b90 0 1 0
> kthreadd S c0244b90 0 2 0
> ksoftirqd/0 S c0244b90 0 3 2
> events/0 S c0244b90 0 4 2
> khelper S c0244b90 0 5 2
> kblockd/0 S c0244b90 051 2
> ksuspend_usbd D c0244b90 059 2
> khubd D c0244b90 064 2
> kseriod D c0244b90 067 2
> pdflush D c0244b90 090 2
> pdflush D c0244b90 091 2
> kswapd0 D c0244b90 092 2
> aio/0 S c0244b90 093 2
> mtdblockd S c0244b90 0 192 2
> udevd D c0244b90 0 619 1
> jffs2_gcd_mtd R running 0 1533 2
> jffs2_gcd_mtd R running 0 1598 2
> syslogd D c0244b90 0 2248 1
> klogd D c0244b90 0 2250 1
> hcid D c0244b90 0 2273 1
> sdpd D c0244b90 0 2277 1
> hidd D c0244b90 0 2281 1
> shD c0244b90 0 2292 1
> getty D c0244b90 0 2293 1
> echo R running 0 2303 2292
> jffs2_gcd_mtd2
> jffs2_gcd_mtd3
>
> Restarting tasks ... done.
I think that the appended patch is necessary to fix this problem.
Greetings,
Rafael
---
Subject: Freezer: Fix JFFS2 garbage collector freezing issue
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Fix breakage caused by commit d5d8c5976d6adeddb8208c240460411e2198b393
"freezer: do not send signals to kernel threads" in
jffs2_garbage_collect_thread() that assumed it would be sent signals
by the freezer.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Cc: Pete MacKay <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
---
fs/jffs2/background.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
Index: linux-2.6/fs/jffs2/background.c
===
--- linux-2.6.orig/fs/jffs2/background.c
+++ linux-2.6/fs/jffs2/background.c
@@ -103,15 +103,17 @@ static int jffs2_garbage_collect_thread(
get there first. */
yield();
+ /* If system suspend is in progress, go to the refrigerator and
+ start again when the suspend is done */
+ if (try_to_freeze())
+ goto again;
+
/* Put_super will send a SIGKILL and then wait on the sem.
*/
while (signal_pending(current)) {
siginfo_t info;
unsigned long signr;
- if (try_to_freeze())
- goto again;
-
signr = dequeue_signal_lock(current, >blocked,
);
switch(signr) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: namespace support requires network modules to say "GPL"
> Then change the license, explicitly and get it approved, forcing license > changes by technically subversive means is bad policy. It is like Euro > bureaucrats I don't need to - the licence has been the same since about 0.12 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-rc3-git4 build warnings
On Saturday 01 December 2007, Adrian Bunk wrote: > On Thu, Nov 29, 2007 at 02:19:49PM +, Chris Clayton wrote: > > Hi, > > > > I've just built 2.6.24-rc3-git4 and got the following two warnings. > > > > LD .tmp_vmlinux1 > > KSYM .tmp_kallsyms1.S > > AS .tmp_kallsyms1.o > > LD .tmp_vmlinux2 > > KSYM .tmp_kallsyms2.S > > AS .tmp_kallsyms2.o > > LD vmlinux.o > > MODPOST vmlinux.o > > WARNING: vmlinux.o(.text+0x90b6): Section mismatch: reference to > > .init.text:cache_remove_shared_cpu_map (between 'free_cache_attributes' > > and 'show_level') > > WARNING: vmlinux.o(.init.text+0x143bd): Section mismatch: reference to > > .exit.text:cpufreq_stats_free_table (between 'cpufreq_stat_cpu_callback' > > and 'cpufreq_stats_init') > >... > > You seem to be using gcc 3.3 or 3.4. > Yes, it's 3.3.6. README in the top-level kernel source directory says "Make sure you have at least gcc 3.2 available", so that should be OK, shouldn't it? > I'll send patches for these. > Thanks > > Chris > > cu > Adrian Chris -- Beer is proof that God loves us and wants us to be happy - Benjamin Franklin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: namespace support requires network modules to say "GPL"
On Sat, 1 Dec 2007 19:23:41 + Alan Cox <[EMAIL PROTECTED]> wrote: > > Then init_net needs to be not GPL limited. Sorry, we need to allow > > non GPL network drivers. There is a fine line between keeping the > > Why - they aren't exactly likely to be permissible by law Matter of debate in which there are several opinions. I don't like binary modules either, but don't feel qualified to render a legal opinion. > > > binary seething masses from accessing random kernel functions, and allowing > > reasonable (but still non GPL) things like ndiswrapper to use network > > device interface. > > Its up to the ndiswrapper authors how the licence their code, but they > should respect how we licence ours. Then change the license, explicitly and get it approved, forcing license changes by technically subversive means is bad policy. It is like Euro bureaucrats sneaking in software patents in regulations. If you want to have the debate and can get it resolved, then I support you. Actually, the whole mess would go away if the api for dev_get_by_ hadn't been changed in the namespace transition. IMHO the interface to dev_get_by_name() should not have added a namespace parameter, of the callers in the tree, only two use a different namespace. So it would have been better to to introduce dev_get_by_name_ns() with the extra parameter. Can we get this resolved before 2.6.24 is released? Going back and forth on API's is just needless frottage. -- Stephen Hemminger <[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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
* David Rientjes <[EMAIL PROTECTED]> wrote: > > this patch extends the soft-lockup detector to automatically detect > > hung TASK_UNINTERRUPTIBLE tasks. Such hung tasks are printed the > > following way: > > Wouldn't a natural extension of this feature be to mark these hung > TASK_UNINTERRUPTIBLE tasks with a new thread flag such as TIF_HUNG for > the purposes of the OOM killer? maybe, but we'd have to see how often this gets triggered. An OOM is something that could happen in any overloaded system - while a hung task is likely due to a kernel bug. 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-rc3-git4 build warnings
On Thu, Nov 29, 2007 at 02:19:49PM +, Chris Clayton wrote: > Hi, > > I've just built 2.6.24-rc3-git4 and got the following two warnings. > > LD .tmp_vmlinux1 > KSYM .tmp_kallsyms1.S > AS .tmp_kallsyms1.o > LD .tmp_vmlinux2 > KSYM .tmp_kallsyms2.S > AS .tmp_kallsyms2.o > LD vmlinux.o > MODPOST vmlinux.o > WARNING: vmlinux.o(.text+0x90b6): Section mismatch: reference to > .init.text:cache_remove_shared_cpu_map (between 'free_cache_attributes' and > 'show_level') > WARNING: vmlinux.o(.init.text+0x143bd): Section mismatch: reference to > .exit.text:cpufreq_stats_free_table (between 'cpufreq_stat_cpu_callback' and > 'cpufreq_stats_init') >... You seem to be using gcc 3.3 or 3.4. I'll send patches for these. > Chris cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.24-rc3-mm2 build failure pasemi-rng driver
On Wed, Nov 28, 2007 at 07:52:01PM +0530, Kamalesh Babulal wrote: > Hi Andrew, > > The kerne build fails, with message > > CC drivers/char/hw_random/pasemi-rng.o > drivers/char/hw_random/pasemi-rng.c: In function > ???pasemi_rng_data_present???: > drivers/char/hw_random/pasemi-rng.c:53: error: ???wait??? undeclared (first > use in this function) > drivers/char/hw_random/pasemi-rng.c:53: error: (Each undeclared identifier is > reported only once > drivers/char/hw_random/pasemi-rng.c:53: error: for each function it appears > in.) > drivers/char/hw_random/pasemi-rng.c: At top level: > drivers/char/hw_random/pasemi-rng.c:93: warning: initialization from > incompatible pointer type > make[3]: *** [drivers/char/hw_random/pasemi-rng.o] Error 1 > make[2]: *** [drivers/char/hw_random] Error 2 > make[1]: *** [drivers/char] Error 2 > make: *** [drivers] Error 2 > > Tested for build failure, only. Fix works. Sorry for the delay, it's been a crazy week with other stuff. > Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]> Acked-by: Olof Johansson <[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: namespace support requires network modules to say "GPL"
> Then init_net needs to be not GPL limited. Sorry, we need to allow > non GPL network drivers. There is a fine line between keeping the Why - they aren't exactly likely to be permissible by law > binary seething masses from accessing random kernel functions, and allowing > reasonable (but still non GPL) things like ndiswrapper to use network > device interface. Its up to the ndiswrapper authors how the licence their code, but they should respect how we licence ours. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: What can we do to get ready for memory controller merge in 2.6.25
On Sat, 1 Dec 2007 11:02:32 -0800 "Paul Menage" <[EMAIL PROTECTED]> wrote: > On Dec 1, 2007 10:36 AM, Rik van Riel <[EMAIL PROTECTED]> wrote: > > > > With the /proc/refaults info, we can measure how much extra > > memory each process group needs, if any. > > What's the status of that? It looks as though it would be better than > the "accessed in the last N seconds" metric that we've been playing > with, although it's possibly more intrusive? > > Would it be practical to keep a non-resident set for each cgroup? I have an implementation with a global array, but will have to change it over to a per-radix tree implementation (not that hard, with the slab reclaiming code) and per-cgroup reclaiming information. That way we can figure out per mapping, per cgroup or system wide reclaim info (though not all at the same time). > > As for how much memory a process group needs, at pageout time > > we can check the fraction of pages that are accessed. If 60% > > of the pages were recently accessed at pageout time and this > > process group is spending little or no time waiting for refaults, > > 40% of the pages are *not* recently accessed and we can probably > > reduce the amount of memory assigned to this group. > > It would probably be better to reduce its background-reclaim high > watermark than to reduce its limit. If you do the latter, you risk > triggering an OOM in the cgroup if it turns out that it did need all > that memory after all. I did mean the RSS limit, not a virtual memory limit. What exactly are all the terminologies you use that I need to be aware of? :) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: namespace support requires network modules to say "GPL"
On Sat, 01 Dec 2007 08:10:17 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
> > Now that we have network namespace support merged it is time to
> > revisit the sysfs support so we can remove the dependency on !SYSFS.
> ...
>
> Now that the namespace updates are part of 2.6.24,
> there is a major inconsistency in network EXPORT_SYMBOLs.
>
> It used to be that an external network module could get away without
> having to add a MODULE_LICENSE("GPL*") line to the source.
>
> In support of that, common networking functions (still) use EXPORT_SYMBOL()
> rather than the more restrictive EXPORT_SYMBOL_GPL().
>
> Eg. register_netdev(), sk_alloc(), __dev_get_by_name().
>
> But now, none of those three are actually usable by default,
> because they all require "init_net", which is EXPORT_SYMBOL_GPL().
>
Then init_net needs to be not GPL limited. Sorry, we need to allow
non GPL network drivers. There is a fine line between keeping the
binary seething masses from accessing random kernel functions, and allowing
reasonable (but still non GPL) things like ndiswrapper to use network
device interface.
--
Stephen Hemminger <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] capabilities: introduce per-process capability bounding set (v10)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There is already a pam_cap module in the libcap2 package. Can we merge
this functionality?
Cheers
Andrew
[EMAIL PROTECTED] wrote:
> Quoting KaiGai Kohei ([EMAIL PROTECTED]):
>> Serge E. Hallyn wrote:
>>> The capability bounding set is a set beyond which capabilities
>>> cannot grow. Currently cap_bset is per-system. It can be
>>> manipulated through sysctl, but only init can add capabilities.
>>> Root can remove capabilities. By default it includes all caps
>>> except CAP_SETPCAP.
>> Serge,
>>
>> This feature makes me being interested in.
>> I think you intend to apply this feature for the primary process
>> of security container.
>> However, it is also worthwhile to apply when a session is starting up.
>>
>> The following PAM module enables to drop capability bounding bit
>> specified by the fifth field in /etc/passwd entry.
>> This code is just an example now, but considerable feature.
>>
>> build and install:
>> # gcc -Wall -c pam_cap_drop.c
>> # gcc -Wall -shared -Xlinker -x -o pam_cap_drop.so pam_cap_drop.o -lpam
>> # cp pam_cap_drop.so /lib/security
>>
>> modify /etc/passwd as follows:
>>
>> tak:x:1004:100:cap_drop=cap_net_raw,cap_chown:/home/tak:/bin/bash
>>^^
>> example:
>> [EMAIL PROTECTED] ~]$ ping 192.168.1.1
>> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.23 ms
>> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.02 ms
>>
>> --- 192.168.1.1 ping statistics ---
>> 2 packets transmitted, 2 received, 0% packet loss, time 999ms
>> rtt min/avg/max/mdev = 1.023/1.130/1.237/0.107 ms
>>
>> [EMAIL PROTECTED] ~]$ ssh [EMAIL PROTECTED]
>> [EMAIL PROTECTED]'s password:
>> Last login: Sat Dec 1 10:09:29 2007 from masu.myhome.cx
>> [EMAIL PROTECTED] ~]$ export LANG=C
>> [EMAIL PROTECTED] ~]$ ping 192.168.1.1
>> ping: icmp open socket: Operation not permitted
>>
>> [EMAIL PROTECTED] ~]$ su
>> Password:
>> pam_cap_bset[6921]: user root does not have 'cap_drop=' property
>> [EMAIL PROTECTED] tak]# cat /proc/self/status | grep ^Cap
>> CapInh:
>> CapPrm: dffe
>> CapEff: dffe
>> [EMAIL PROTECTED] tak]#
>
> Neat. A bigger-stick version of not adding the account to
> group wheel. I'll use that.
>
> Is there any reason not to have a separate /etc/login.capbounds
> config file, though, so the account can still have a full name?
> Did you only use that for convenience of proof of concept, or
> is there another reason?
>
>> # BTW, I replaced the James's address in the Cc: list,
>> # because MTA does not accept it.
>
> Thanks! I don't know what happened to my alias for him...
>
> thanks,
> -serge
>
>> --
>> KaiGai Kohei <[EMAIL PROTECTED]>
>>
>>
>> pam_cap_drop.c
>>
>>
>> /*
>> * pam_cap_drop.c module -- drop capabilities bounding set
>> *
>> * Copyright: 2007 KaiGai Kohei <[EMAIL PROTECTED]>
>> */
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> #include
>>
>> #ifndef PR_CAPBSET_DROP
>> #define PR_CAPBSET_DROP 24
>> #endif
>>
>> static char *captable[] = {
>> "cap_chown",
>> "cap_dac_override",
>> "cap_dac_read_search",
>> "cap_fowner",
>> "cap_fsetid",
>> "cap_kill",
>> "cap_setgid",
>> "cap_setuid",
>> "cap_setpcap",
>> "cap_linux_immutable",
>> "cap_net_bind_service",
>> "cap_net_broadcast",
>> "cap_net_admin",
>> "cap_net_raw",
>> "cap_ipc_lock",
>> "cap_ipc_owner",
>> "cap_sys_module",
>> "cap_sys_rawio",
>> "cap_sys_chroot",
>> "cap_sys_ptrace",
>> "cap_sys_pacct",
>> "cap_sys_admin",
>> "cap_sys_boot",
>> "cap_sys_nice",
>> "cap_sys_resource",
>> "cap_sys_time",
>> "cap_sys_tty_config",
>> "cap_mknod",
>> "cap_lease",
>> "cap_audit_write",
>> "cap_audit_control",
>> "cap_setfcap",
>> NULL,
>> };
>>
>>
>> PAM_EXTERN int
>> pam_sm_open_session(pam_handle_t *pamh, int flags,
>> int argc, const char **argv)
>> {
>> struct passwd *pwd;
>> char *pos, *buf;
>> char *username = NULL;
>>
>> /* open system logger */
>> openlog("pam_cap_bset", LOG_PERROR | LOG_PID, LOG_AUTHPRIV);
>>
>> /* get the unix username */
>> if (pam_get_item(pamh, PAM_USER, (void *) ) != PAM_SUCCESS ||
>> !username)
>> return PAM_USER_UNKNOWN;
>>
>> /* get the passwd entry */
>> pwd = getpwnam(username);
>> if (!pwd)
>> return PAM_USER_UNKNOWN;
>>
>> /* Is there "cap_drop=" ? */
>> pos = strstr(pwd->pw_gecos, "cap_drop=");
>> if (pos) {
>> buf = strdup(pos + sizeof("cap_drop=") - 1);
>> if (!buf)
>> return PAM_SESSION_ERR;
>>
Re: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
On Sat, 01 Dec 2007 14:48:54 +0100
Jochen Friedrich wrote:
> Hi Vitaly,
>
> > With that patch fixed.c now fully emulates MDIO bus, thus no need
> > to duplicate PHY layer functionality. That, in turn, drastically
> > simplifies the code, and drops down line count.
> >
> > As an additional bonus, now there is no need to register MDIO bus
> > for each PHY, all emulated PHYs placed on the platform fixed MDIO
> > bus. There is also no more need to pre-allocate PHYs via .config
> > option, this is all now handled dynamically.
> >
> > p.s. Don't even try to understand patch content! Better: apply patch
> > and look into resulting drivers/net/phy/fixed.c.
> >
> If i understand your code correctly, you seem to rely on the fact
> that fixed_phy_add() is called before the fixed MDIO bus is scanned
> for devices. How is this supposed to work for modules or for the
> PPC_CPM_NEW_BINDING mode where the device tree is no longer scanned
> during fs_soc initialization but during device initialization?
>
Well, this is kind of known issue - to work it around for now, place PHY lib
after fs_enet in
Makefile. This way it works for me for _NEW_BINDING and mpc866ads.
> I tried to add fixed-phy support to fs_enet, but the fixed phy is not
> found this way.
>
The point is I have the code and it works now(for fs_enet etc.), but I need to
find the way for the fixed phy pinning to work in either order with phylib. If
you have ideas, please go ahead :)
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1174,8 +1175,24 @@ static int __devinit find_phy(struct
> device_node *np, struct device_node *phynode, *mdionode;
> struct resource res;
> int ret = 0, len;
> + const u32 *data;
> + struct fixed_phy_status status = {};
> +
> + data = of_get_property(np, "fixed-link", NULL);
> + if (data) {
> + status.link = 1;
> + status.duplex = data[1];
> + status.speed = data[2];
> +
> + ret = fixed_phy_add(PHY_POLL, data[0], );
> + if (ret)
> + return ret;
> +
> + snprintf(fpi->bus_id, 16, PHY_ID_FMT, 0, *data);
> + return 0;
> + }
>
> - const u32 *data = of_get_property(np, "phy-handle", );
> + data = of_get_property(np, "phy-handle", );
> if (!data || len != 4)
> return -EINVAL;
>
> Thanks,
> Jochen
--
Sincerely, Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: What can we do to get ready for memory controller merge in 2.6.25
On Dec 1, 2007 10:36 AM, Rik van Riel <[EMAIL PROTECTED]> wrote: > > With the /proc/refaults info, we can measure how much extra > memory each process group needs, if any. What's the status of that? It looks as though it would be better than the "accessed in the last N seconds" metric that we've been playing with, although it's possibly more intrusive? Would it be practical to keep a non-resident set for each cgroup? > > As for how much memory a process group needs, at pageout time > we can check the fraction of pages that are accessed. If 60% > of the pages were recently accessed at pageout time and this > process group is spending little or no time waiting for refaults, > 40% of the pages are *not* recently accessed and we can probably > reduce the amount of memory assigned to this group. It would probably be better to reduce its background-reclaim high watermark than to reduce its limit. If you do the latter, you risk triggering an OOM in the cgroup if it turns out that it did need all that memory after all. Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ufs: fix nexstep dir block size
This patch fixes regression, introduced since 2.6.16. NextStep variant of UFS as OpenStep uses directory block size equals to 1024. Without this change, ufs_check_page fails in many cases. Signed-off-by: Evgeniy Dushistov <[EMAIL PROTECTED]> Cc: Dave Bailey <[EMAIL PROTECTED]> --- diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c index 30f8c2b..e4263c1 100644 --- a/fs/ufs/dir.c +++ b/fs/ufs/dir.c @@ -179,7 +179,7 @@ bad_entry: goto fail; Eend: p = (struct ufs_dir_entry *)(kaddr + offs); - ufs_error (sb, "ext2_check_page", + ufs_error (sb, __FUNCTION__, "entry in directory #%lu spans the page boundary" "offset=%lu", dir->i_ino, (page->indexs_fmask = ~(1024 - 1); uspi->s_fshift = 10; uspi->s_sbsize = super_block_size = 2048; uspi->s_sbbase = 0; + uspi->s_dirblksize = 1024; flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_OLD | UFS_CG_OLD; if (!(sb->s_flags & MS_RDONLY)) { if (!silent) @@ -771,13 +771,13 @@ static int ufs_fill_super(struct super_block *sb, void *data, int silent) break; case UFS_MOUNT_UFSTYPE_NEXTSTEP_CD: - /*TODO: check may be we need set special dir block size?*/ UFSD("ufstype=nextstep-cd\n"); uspi->s_fsize = block_size = 2048; uspi->s_fmask = ~(2048 - 1); uspi->s_fshift = 11; uspi->s_sbsize = super_block_size = 2048; uspi->s_sbbase = 0; + uspi->s_dirblksize = 1024; flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_OLD | UFS_CG_OLD; if (!(sb->s_flags & MS_RDONLY)) { if (!silent) -- /Evgeniy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
On Sat, 1 Dec 2007, Ingo Molnar wrote: > this patch extends the soft-lockup detector to automatically > detect hung TASK_UNINTERRUPTIBLE tasks. Such hung tasks are > printed the following way: > Wouldn't a natural extension of this feature be to mark these hung TASK_UNINTERRUPTIBLE tasks with a new thread flag such as TIF_HUNG for the purposes of the OOM killer? Right now, the OOM killer will become a no-op when any candidate task that it scans through is found to have the TIF_MEMDIE flag when selecting a task to kill. So any hung task in this state could cause the OOM killer to infinitely loop. If lockdep could set_tsk_thread_flag(g, TIF_HUNG), this could be detected in the OOM killer and not only could we prevent the infinite looping but we could also clear TIF_MEMDIE and reduce the increased timeslice that the OOM killer gives to the tasks it kills. 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: What can we do to get ready for memory controller merge in 2.6.25
On Sat, 01 Dec 2007 15:20:29 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > > In our experience, users are not good at figuring out how much memory > > they really need. In general they tend to massively over-estimate > > their requirements. So we want some way to determine how much of its > > allocated memory a job is actively using, and how much could be thrown > > away or swapped out without bothering the job too much. > > One would prefer the kernel provides the mechanism and user space > provides the policy. The algorithms to assign limits can exist in user > space and be supported by a good set of statistics. With the /proc/refaults info, we can measure how much extra memory each process group needs, if any. As for how much memory a process group needs, at pageout time we can check the fraction of pages that are accessed. If 60% of the pages were recently accessed at pageout time and this process group is spending little or no time waiting for refaults, 40% of the pages are *not* recently accessed and we can probably reduce the amount of memory assigned to this group. Page cache that has only been accessed once can also be counted as "not recently accessed", since streaming file IO should not increase the working set of the process group. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
