[PATCH 3/3] x86-64: make flush_tlb_kernel_range() a static inline function
The following change was checked into 'warnings' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
commit b1c9131343597967d8fcc042f59e4ed36ea2855f
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed Jul 18 01:47:39 2007 -0400
[X86-64] make flush_tlb_kernel_range() a static inline function
On x86-64, without this change, the following warning is emitted
mm/vmalloc.c: In function ‘unmap_kernel_range’:
mm/vmalloc.c:75: warning: unused variable ‘start’
because, x86-64, flush_tlb_kernel_range(start,end) evaluates down to
flush_tlb_all(void) in a macro.
Avoid this warning by implementing x86-64's flush_tlb_kernel_range() as
a type-safe static inline, rather than a macro.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
include/asm-x86_64/tlbflush.h |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
b1c9131343597967d8fcc042f59e4ed36ea2855f
diff --git a/include/asm-x86_64/tlbflush.h b/include/asm-x86_64/tlbflush.h
index 8516225..a82464c 100644
--- a/include/asm-x86_64/tlbflush.h
+++ b/include/asm-x86_64/tlbflush.h
@@ -92,7 +92,11 @@ static inline void flush_tlb_range(struct vm_area_struct *
vma, unsigned long st
#endif
-#define flush_tlb_kernel_range(start, end) flush_tlb_all()
+static inline void flush_tlb_kernel_range(unsigned long start,
+ unsigned long end)
+{
+ flush_tlb_all();
+}
static inline void flush_tlb_pgtables(struct mm_struct *mm,
unsigned long start, unsigned long end)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] drivers/video/aty/radeon_base: fix radeonfb_pci_register() err handling
The following change was checked into 'warnings' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
commit 61470a24062de01853fb922ec4a81dcd1c0ba1d0
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed Jul 18 01:43:05 2007 -0400
drivers/video/aty/radeon_base: fix radeonfb_pci_register() err handling
* silence warnings by handling failure of sysfs_create_bin_file()
* fix leak-on-error if register_framebuffer() fails, and sysfs is active
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/video/aty/radeon_base.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
61470a24062de01853fb922ec4a81dcd1c0ba1d0
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 47ca62f..5a5458b 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -2326,10 +2326,16 @@ static int __devinit radeonfb_pci_register (struct
pci_dev *pdev,
radeon_check_modes(rinfo, mode_option);
/* Register some sysfs stuff (should be done better) */
- if (rinfo->mon1_EDID)
- sysfs_create_bin_file(>pdev->dev.kobj, _attr);
- if (rinfo->mon2_EDID)
- sysfs_create_bin_file(>pdev->dev.kobj, _attr);
+ if (rinfo->mon1_EDID) {
+ ret = sysfs_create_bin_file(>pdev->dev.kobj,_attr);
+ if (ret)
+ goto err_unmap_fb;
+ }
+ if (rinfo->mon2_EDID) {
+ ret = sysfs_create_bin_file(>pdev->dev.kobj,_attr);
+ if (ret)
+ goto err_free_mon1;
+ }
/* save current mode regs before we switch into the new one
* so we can restore this upon __exit
@@ -2353,7 +2359,7 @@ static int __devinit radeonfb_pci_register (struct
pci_dev *pdev,
if (ret < 0) {
printk (KERN_ERR "radeonfb (%s): could not register
framebuffer\n",
pci_name(rinfo->pdev));
- goto err_unmap_fb;
+ goto err_free_mon2;
}
#ifdef CONFIG_MTRR
@@ -2372,6 +2378,13 @@ static int __devinit radeonfb_pci_register (struct
pci_dev *pdev,
RTRACE("radeonfb_pci_register END\n");
return 0;
+
+err_free_mon2:
+ if (rinfo->mon2_EDID)
+ sysfs_remove_bin_file(>pdev->dev.kobj, _attr);
+err_free_mon1:
+ if (rinfo->mon1_EDID)
+ sysfs_remove_bin_file(>pdev->dev.kobj, _attr);
err_unmap_fb:
iounmap(rinfo->fb_base);
err_unmap_rom:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] drivers/base/core: improve device_add() error handling, fix bugs
The following change was checked into 'warnings' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
commit 5330916f5a11d8b7def46a6b3e14a831684032f5
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed Jul 18 01:41:29 2007 -0400
drivers/base/core: improve device_add() error handling, fix bugs
* silence several warnings by handling sysfs_create_link() failure
* re-order some operations in error handling, to precisely reverse
the order of operations, i.e. unwind properly.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/base/core.c | 46 ++
1 file changed, 30 insertions(+), 16 deletions(-)
5330916f5a11d8b7def46a6b3e14a831684032f5
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0455aa7..f26c005 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -698,16 +698,26 @@ int device_add(struct device *dev)
}
if (dev->class) {
- sysfs_create_link(>kobj, >class->subsys.kobj,
- "subsystem");
+ error = sysfs_create_link(>kobj, >class->subsys.kobj,
+ "subsystem");
+ if (error)
+ goto ClassSubsysError;
+
/* If this is not a "fake" compatible device, then create the
* symlink from the class to the device. */
- if (dev->kobj.parent != >class->subsys.kobj)
- sysfs_create_link(>class->subsys.kobj,
- >kobj, dev->bus_id);
+ if (dev->kobj.parent != >class->subsys.kobj) {
+ error = sysfs_create_link(>class->subsys.kobj,
+ >kobj, dev->bus_id);
+ if (error)
+ goto ClassDevLinkError;
+ }
+
if (parent) {
- sysfs_create_link(>kobj, >parent->kobj,
- "device");
+ error = sysfs_create_link(>kobj,>parent->kobj,
+ "device");
+ if (error)
+ goto ParentDevLinkError;
+
#ifdef CONFIG_SYSFS_DEPRECATED
class_name = make_class_name(dev->class->name,
>kobj);
@@ -755,16 +765,7 @@ int device_add(struct device *dev)
BUS_NOTIFY_DEL_DEVICE, dev);
device_remove_attrs(dev);
AttrsError:
- if (MAJOR(dev->devt))
- device_remove_file(dev, _attr);
-
if (dev->class) {
- sysfs_remove_link(>kobj, "subsystem");
- /* If this is not a "fake" compatible device, remove the
-* symlink from the class to the device. */
- if (dev->kobj.parent != >class->subsys.kobj)
- sysfs_remove_link(>class->subsys.kobj,
- dev->bus_id);
if (parent) {
#ifdef CONFIG_SYSFS_DEPRECATED
char *class_name = make_class_name(dev->class->name,
@@ -776,7 +777,20 @@ int device_add(struct device *dev)
#endif
sysfs_remove_link(>kobj, "device");
}
+
+ ParentDevLinkError:
+ /* If this is not a "fake" compatible device, remove the
+* symlink from the class to the device. */
+ if (dev->kobj.parent != >class->subsys.kobj)
+ sysfs_remove_link(>class->subsys.kobj,
+ dev->bus_id);
+
+ ClassDevLinkError:
+ sysfs_remove_link(>kobj, "subsystem");
}
+ ClassSubsysError:
+ if (MAJOR(dev->devt))
+ device_remove_file(dev, _attr);
ueventattrError:
device_remove_file(dev, _attr);
attrError:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: oops with 2.6.22.1 - bad magic number for tty struct
John Stoffel napsal(a): > Zdenek> I get kernel oopses when I run powertop on my old BP6 SMP dual > Zdenek> Celeron board. > > Zdenek> In case more details are needed - send me a replay. > > Since it's tainted with a proprietary module, we can't do anything > here. Please re-create the oops without that module and we'll be able > to help. maybe... > Zdenek> The machine with problem is - > Zdenek> 2xCPU400MHz Celerons running at 450MHz (stable - compiles kernel > Zdenek> without any problems, thought it takes more than hour nowadays :(...) > Zdenek> 512MB RAM > Zdenek> 120&30GB Hard drivers (all should be visible in the boot log that > Zdenek> follows oops trace) > Zdenek> In Bp6 bios - PnP enabled, Serial ports disabled. > Zdenek> Atheros WiFi driver is used - but this shall hopefully not influence > Zdenek> this problem. > > Zdenek> bye > > Zdenek> Zdenek > > > Zdenek> Jul 16 21:16:35 bad magic number for tty struct (136:3) in tty_poll Hmm, pts tty struct broken 4 minutes before the oops? Is it reproducible? > Zdenek> Jul 16 21:20:56 BUG: unable to handle kernel NULL pointer dereference > Zdenek> at virtual address 007c > Zdenek> Jul 16 21:20:56 printing eip: > Zdenek> Jul 16 21:20:56 c0260c23 > Zdenek> Jul 16 21:20:56 *pde = > Zdenek> Jul 16 21:20:56 Oops: [#1] > Zdenek> Jul 16 21:20:56 PREEMPT SMP > Zdenek> Jul 16 21:20:56 Modules linked in: cpufreq_stats freq_table mga drm > Zdenek> binfmt_misc autofs4 nfsd exportfs lockd sunrpc thermal fan button > Zdenek> processor ac battery ipv6 iptable_filter ip_tables x_tables fuse > Zdenek> dm_snapshot dm_mirror dm_mod w83781d hwmon_vid hwmon tuner tvaudio > Zdenek> snd_emu10k1 wlan_scan_sta snd_rawmidi ath_rate_sample snd_ac97_codec > Zdenek> ac97_bus bttv video_buf firmware_class snd_bt87x ir_common snd_pcm_oss > Zdenek> snd_mixer_oss compat_ioctl32 i2c_algo_bit snd_pcm btcx_risc > Zdenek> snd_util_mem tveeprom videodev snd_hwdep 8139too snd_timer uhci_hcd > Zdenek> v4l2_common v4l1_compat mii floppy emu10k1_gp snd_page_alloc ath_pci > Zdenek> wlan ath_hal(P) pata_hpt366 libata i2c_piix4 snd intel_agp soundcore > Zdenek> rtc usbcore gameport i2c_core scsi_mod agpgart evdev > Zdenek> Jul 16 21:20:56 CPU:0 > Zdenek> Jul 16 21:20:56 EIP:0060:[]Tainted: P VLI > Zdenek> Jul 16 21:20:56 EFLAGS: 00010046 (2.6.22.1 #1) > Zdenek> Jul 16 21:20:56 EIP is at tty_devnum+0x3/0x20 > Zdenek> Jul 16 21:20:56 eax: d7b3f800 ebx: d7b0c030 ecx: edx: > > Zdenek> Jul 16 21:20:56 esi: cf9ac000 edi: df1aa7c0 ebp: d7b0c030 esp: > c94a3db8 > Zdenek> Jul 16 21:20:56 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Zdenek> Jul 16 21:20:56 Process top (pid: 6260, ti=c94a2000 task=c9a5ba90 > Zdenek> task.ti=c94a2000) > Zdenek> Jul 16 21:20:56 Stack: c01adca0 c0186934 df00ce0c c94a3e08 c017e42d > Zdenek> c7c0200b 0101 01c5a71f > Zdenek> Jul 16 21:20:56c94a3e44 dffcbf20 c01f5340 dffce6b8 c94a3e38 > Zdenek> c0186934 c66b7b8c c94a3e38 > Zdenek> Jul 16 21:20:56c017e42d c7c02006 0001 01c5a71f > Zdenek> 0004 c7c0200b dffcbf20 > Zdenek> Jul 16 21:20:56 Call Trace: > Zdenek> Jul 16 21:20:56 [] do_task_stat+0x120/0x9a0 > Zdenek> Jul 16 21:20:56 [] dput+0x94/0x130 > Zdenek> Jul 16 21:20:56 [] __link_path_walk+0xacd/0xc80 > Zdenek> Jul 16 21:20:56 [] ext3_permission+0x0/0x10 > Zdenek> Jul 16 21:20:56 [] dput+0x94/0x130 > Zdenek> Jul 16 21:20:56 [] __link_path_walk+0xacd/0xc80 > Zdenek> Jul 16 21:20:56 [] mntput_no_expire+0x13/0x60 > Zdenek> Jul 16 21:20:56 [] link_path_walk+0x65/0xc0 > Zdenek> Jul 16 21:20:56 [] _spin_unlock+0x5/0x20 > Zdenek> Jul 16 21:20:56 [] get_unused_fd+0xa3/0xc0 > Zdenek> Jul 16 21:20:56 [] do_path_lookup+0x78/0x1c0 > Zdenek> Jul 16 21:20:56 [] file_move+0x1c/0x60 > Zdenek> Jul 16 21:20:56 [] __alloc_pages+0x4f/0x300 > Zdenek> Jul 16 21:20:56 [] nameidata_to_filp+0x35/0x40 > Zdenek> Jul 16 21:20:56 [] proc_info_read+0x87/0xc0 > Zdenek> Jul 16 21:20:56 [] vfs_read+0xa1/0x130 > Zdenek> Jul 16 21:20:56 [] proc_info_read+0x0/0xc0 > Zdenek> Jul 16 21:20:56 [] sys_read+0x41/0x70 > Zdenek> Jul 16 21:20:56 [] syscall_call+0x7/0xb > Zdenek> Jul 16 21:20:56 === > Zdenek> Jul 16 21:20:56 Code: 2c 01 00 00 8b 4a 54 89 88 30 01 00 00 8b 4a 58 > Zdenek> 89 88 34 01 00 00 8b 52 5c 89 90 38 01 00 00 c3 90 8d b4 26 00 00 00 > Zdenek> 00 8b 48 04 <8b> 51 7c c1 e2 14 0b 91 80 00 00 00 8b 48 08 01 ca 89 d0 > Zdenek> c3 89 > Zdenek> Jul 16 21:20:56 EIP: [] tty_devnum+0x3/0x20 SS:ESP > 0068:c94a3db8 -- Jiri Slaby ([EMAIL PROTECTED]) Faculty of Informatics, Masaryk University - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops while modprobing phy fixed module
Okay, successfully reproduced here. Will hunt down. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add nid sanity on alloc_pages_node
On Wed, 18 Jul 2007 05:49:50 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]> wrote: > > With your patch, I have reproduced the panic: > > That is... surprising to me. To me also. I'd like to double-check the code which Joe actually tested, please - have a sneaking suspicion that the 2.6.22 version of that function was tested ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Containers: css_put() dilemma
On Wed, Jul 18, 2007 at 11:00:39AM +0530, Balbir Singh wrote: > Thinking out loud again, can we add can_destory() callbacks? I remember suggesting such a callback long before : http://marc.info/?l=linux-kernel=117576241131788=2 -- Regards, vatsa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Containers: css_put() dilemma
Balbir Singh wrote: > Paul (??) Menage wrote: >> On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote: >>> without too much knowledge of each other. BTW, what are the semantics >>> of css_put() is it expected to free the container/run the release agent >>> when the reference count of the container_subsys_state drops to zero? >>> >> If you css_put() the last reference on a subsystem state object and >> the associated container is marked as notify_on_release, then >> check_for_release() is called which does a more full check of whether >> the container is releasable. If it is, a workqueue task is scheduled >> to run the userspace release agent, which can then do anything it >> wants, including potentially deleting the empty container. >> > > Ok.. so my problem still remains, how do I get a non-blocking atomic > reference increment/decrement routine, that would prevent my > container from being deleted? > > I don't find cpusets using css_put(). I was hoping that we could > alter css_* would provide the functionality I need. > > Thinking out loud again, can we add can_destory() callbacks? -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] appletouch powersaving - please apply for 2.6.23-rc1 take #3
On Tue, 2007-07-17 at 21:48 -0400, Dmitry Torokhov wrote: > On Tuesday 17 July 2007 14:16, Soeren Sonnenburg wrote: > > On Tue, 2007-07-17 at 11:01 -0400, Dmitry Torokhov wrote: > [...] > > > How many boxes did you try this patch on? > > > > Mine plus 1 other. However please note that Matthews patch has been > > (which is what this patch is based on) is in the mactel-patches > > repository for quite some time now and that the not-yet-cleanup up > > variant of this patch was posted to mactel-devel... > > > > So the modeswitch part should work... > > > > OK, can I please get signed-off-bys for the latest version so I can > apply it? They are the same as in the initial patch: Signed-off-by: Soeren Sonnenburg <[EMAIL PROTECTED]> Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> Soeren -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] sysfs: make sysfs_init_inode() static
With sysfs_fill_super() converted to use sysfs_get_inode(), there is
no user of sysfs_init_inode() outside of fs/sysfs/inode.c. Make it
static.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
fs/sysfs/inode.c |2 +-
fs/sysfs/sysfs.h |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
Index: work/fs/sysfs/inode.c
===
--- work.orig/fs/sysfs/inode.c
+++ work/fs/sysfs/inode.c
@@ -133,7 +133,7 @@ static inline void set_inode_attr(struct
*/
static struct lock_class_key sysfs_inode_imutex_key;
-void sysfs_init_inode(struct sysfs_dirent *sd, struct inode *inode)
+static void sysfs_init_inode(struct sysfs_dirent *sd, struct inode *inode)
{
inode->i_blocks = 0;
inode->i_mapping->a_ops = _aops;
Index: work/fs/sysfs/sysfs.h
===
--- work.orig/fs/sysfs/sysfs.h
+++ work/fs/sysfs/sysfs.h
@@ -71,7 +71,6 @@ extern void sysfs_remove_one(struct sysf
extern int sysfs_addrm_finish(struct sysfs_addrm_cxt *acxt);
extern void sysfs_delete_inode(struct inode *inode);
-extern void sysfs_init_inode(struct sysfs_dirent *sd, struct inode *inode);
extern struct inode * sysfs_get_inode(struct sysfs_dirent *sd);
extern void sysfs_instantiate(struct dentry *dentry, struct inode *inode);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sysfs: fix sysfs root inode nlink accounting
While making sysfs indoes hashed, sysfs root inode was left out. Now
that nlink accounting depends on the inode being on the hash, sysfs
root inode nlink isn't adjusted properly.
Put sysfs root inode on the inode hash by allocating it using
sysfs_get_inode() like other sysfs inodes. While at it, massage
comments a bit.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
fs/sysfs/mount.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: work/fs/sysfs/mount.c
===
--- work.orig/fs/sysfs/mount.c
+++ work/fs/sysfs/mount.c
@@ -43,19 +43,19 @@ static int sysfs_fill_super(struct super
sb->s_time_gran = 1;
sysfs_sb = sb;
- inode = new_inode(sysfs_sb);
+ /* get root inode, initialize and unlock it */
+ inode = sysfs_get_inode(_root);
if (!inode) {
pr_debug("sysfs: could not get root inode\n");
return -ENOMEM;
}
- sysfs_init_inode(_root, inode);
-
inode->i_op = _dir_inode_operations;
inode->i_fop = _dir_operations;
- /* directory inodes start off with i_nlink == 2 (for "." entry) */
- inc_nlink(inode);
+ inc_nlink(inode); /* directory, account for "." */
+ unlock_new_inode(inode);
+ /* instantiate and link root dentry */
root = d_alloc_root(inode);
if (!root) {
pr_debug("%s: could not get root dentry!\n",__FUNCTION__);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] More input updates for post-2.6.22
Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for input subsystem. Changelog: - Dmitry Torokhov (3): Input: add driver for Fujitsu serial touchscreens Input: i8042 - give more trust to PNP data on i386 Input: document intended meaning of KEY_SWITCHVIDEOMODE Jan Kratochvil (1): Input: xpad - add support for leds on xbox 360 pad Pavel Emelianov (1): Input: switch to using seq_list_xxx helpers Semih Hazar (2): Input: ads7846 - introduce sample settling delay Input: ads7846 - re-check pendown status before reporting events Diffstat: drivers/input/input.c | 29 + drivers/input/joystick/Kconfig |7 + drivers/input/joystick/xpad.c | 190 +--- drivers/input/serio/i8042-x86ia64io.h | 36 +- drivers/input/touchscreen/Kconfig | 13 ++ drivers/input/touchscreen/Makefile |1 + drivers/input/touchscreen/ads7846.c| 80 +- drivers/input/touchscreen/fujitsu_ts.c | 189 +++ include/linux/input.h |3 +- include/linux/serio.h |1 + include/linux/spi/ads7846.h| 14 +++ 11 files changed, 487 insertions(+), 76 deletions(-) create mode 100644 drivers/input/touchscreen/fujitsu_ts.c -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ofa-general] Further 2.6.23 merge plans...
>I think this is an important question. If we merge the local SA >stuff, then are we creating a problem for dealing with QoS? Yes - I do believe that merging PR caching and QoS together will be difficult. I don't think the problems are insurmountable, but I can't say that I have a definite solution for how to deal with this. My current thoughts are that the purpose of the cache is to increase SA scalability on large clusters. We've seen issues running MPI, trying to establish all-to-all connections, on our 256 node cluster. (With 4 processes per node, this results in about 500,000+ PR queries hitting the SA.) The SA was swamped with work, and it wasn't trying to enforce QoS requirements across the cluster. I just don't see how an SA that is already having trouble scaling to this number of nodes will be able to perform the additional task of providing QoS across the cluster. It may be that, at least initially, an administrator may need to select between enabling PR caching or QoS. >Are we going to have to revert the local SA stuff once the QoS stuff is >available? In the best case, the local SA will need enhancements added to the base support. In the worst case, a user would have to choose between QoS or PR caching. If all users choose QoS, then it would make sense to remove the local SA. >Or is there at least a sketch of a plan on how to handle this? This is only a rough idea, and it depends on how the QoS is implemented. The idea is to create a local QoS module on each node. The local QoS modules would be programmed with basic QoS information. For example, which types of queries to handle locally, versus which ones to forward to the SA. Locally handled queries would return PRs based on some QoS mapping table. (I haven't looked into any details of this.) Ideally, local QoS modules would be programmed by a QoS master. This would require a new vendor-specific protocol, but would allow for a simple distributed QoS manager. We will have a better idea of the issues and possible solutions once the QoS spec is released, and we can hold discussions on it. I will be working more details on QoS enhancements starting in the next couple of weeks. - Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Documentation fix devres.txt: lib/iomap.c -> lib/devres.c
Brandon Philips wrote: > Signed-off-by: Brandon Philips <[EMAIL PROTECTED]> Acked-by: Tejun Heo <[EMAIL PROTECTED]> -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches 1/2] warnings: attack valid cases spotted by warnings
On Tue, 17 Jul 2007, Roland Dreier wrote: > > > Anyway, here's a totally untested cleanup that compiles but probably > > doesn't work, because I didn't check that I did the right thing with all > > the pointer arithmetic (ie when I change "wqe" to a real structure pointer > > instead of just a "void *", maybe I left some pointer arithmetic around > > that expected it to work as a byte pointer, but now really works on the > > whole structure size instead). > > Given that you took the time to do this, I'll get the patch into a > working state and apply it. And maybe split it into reviewable chunks > while I'm at it ;) Hey, I appreciate it, but I really do have to warn you that I did this all blind, and just meant for it to be a "I think this kind of direction is more productive" thing. I'm not going to guarantee that it works at all. I spent more time than I really wanted to on actually making sure the end result even compiles (quite often, I'm perfectly happy to just send out pseudo-code to indicate what I think should be done), but maybe I shouldn't have done that, just so that nobody thinks that the patch is necessarily going to *work*. In other words, it's a totally mindless cleanup and re-factorization. It *may* work, but quite frankly, I did it just for that one email, and spent the absolutly minimum possible time thinking about it. As a result, I really think it needs some serious looking over. I also think that my new "handle_raddr_seg()" function could itself be split up into subfunctions along the "switch()" subcases. So not only wasn't it meant to be guaranteed correct, but it wasn't even meant to be seen as the best possible final situation: it could be - and should be - factored out even more (and the same goes for a lot of the other functions in that file that I didn't really look at, just glance and notice that they have some of the same problem patterns). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation fix devres.txt: lib/iomap.c -> lib/devres.c
Signed-off-by: Brandon Philips <[EMAIL PROTECTED]> --- Documentation/driver-model/devres.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 6c8d8f2..8569072 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -207,7 +207,7 @@ responsibility. This is usually non-issue because bus ops and resource allocations already do the job. For an example of single-instance devres type, read pcim_iomap_table() -in lib/iomap.c. +in lib/devres.c. All devres interface functions can be called without context if the right gfp mask is given. -- 1.5.3.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
compile error if CONFIG_BLOCK not enabled related to linux/ide.h include
M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] We get the following compile error if CONFIG_BLOCK isn't enabled: CC arch/powerpc/kernel/setup_32.o In file included from arch/powerpc/kernel/setup_32.c:14: include/linux/ide.h:558: error: expected specifier-qualifier-list before 'request_queue_t' include/linux/ide.h:696: warning: 'struct request' declared inside parameter list include/linux/ide.h:696: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/ide.h:820: warning: 'struct request' declared inside parameter list include/linux/ide.h:853: error: field 'wrq' has incomplete type include/linux/ide.h:1205: error: expected ')' before '*' token make[1]: *** [arch/powerpc/kernel/setup_32.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 What I'm trying to figure out is if include/linux/ide.h should be wrapped in a #if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE) or if there is some other desired way to handle this. This seems to stem from the fact that include/linux/blkdev.h is wrapped in a CONFIG_BLOCK and thus request_queue_t isn't always defined. - k - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: attempting to open a VT from elsewhere and take raw keyboard input
Yes I know that X does it; I'm trying to write a new windowing system
which also does that, and the question is how they did it. I would
have expected if I just open /dev/tty1, set raw mode, and set some
termios flags I'd get every key press and release; and it would be my
choice whether to use blocking or non-blocking I/O.
On 7/17/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
On Jul 17 2007 01:51, Shawn Rutledge wrote:
>
> I'm messing around with framebuffer graphics stuff and trying to write
> a keyboard driver similar to the one in X, which will allow you to
> start up the graphics system from any tty (not just a virtual
> console),
right, I can start X these days over SSH (either init5 or startx)
> find an available VT, switch to that VT,
X does that automatically ('regular' X, not considering Xdmcp or such)
> and then take input from the physically attached keyboard rather
> than necessarily
X does that too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add nid sanity on alloc_pages_node
On Wed, 18 Jul 2007, Joe Jin wrote:
>
> With your patch, I have reproduced the panic:
That is... surprising to me. (I hadn't been able to reproduce it with
or without the patches: maybe I just need to try harder.) Please post
your gcc --version, and the disassembly (objdump -d) output for
alloc_fresh_huge_page.
Or can someone else make sense of this - Oleg? To me it still seems
that nid_lock can only be irrelevant (doesn't even provide a compiler
barrier between prev_nid and nid transactions).
You remark lower down
> From your patch, if we dont the lock, the race condition maybe occur
> at next_node().
but I don't see how (if next_node were a macro which evaluates its
args more than once, perhaps, but that doesn't seem to be the case).
Thanks a lot,
Hugh
>
> Unable to handle kernel paging request at 186a RIP:
> [] __alloc_pages+0x2f/0x2c3
> PGD 72595067 PUD 72594067 PMD 0
> Oops: [1] SMP
> CPU 0
> Modules linked in: xt_tcpudp iptable_filter ip_tables x_tables
> cpufreq_ondemand dm_mirror dm_multipath dm_mod video sbs button battery
> backlight ac snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss
> snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
> sg snd_timer shpchp snd soundcore tg3 i2c_i801 piix i2c_core snd_page_alloc
> ide_cd cdrom serio_raw ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd
> ohci_hcd uhci_hcd
> Pid: 3996, comm: sh Not tainted 2.6.22 #9
> RIP: 0010:[] [] __alloc_pages+0x2f/0x2c3
> RSP: 0018:810071563e48 EFLAGS: 00010246
> RAX: RBX: 00e8d4a51000 RCX:
> RDX: 810071563fd8 RSI: 0009 RDI: 000242d2
> RBP: 000242d2 R08: R09: 00043a01
> R10: 81e88000 R11: 81072a02 R12: 1862
> R13: 810070c74ea0 R14: 0009 R15: 2adc51042000
> FS: 2adc4db3ddb0() GS:81312000() knlGS:
> CS: 0010 DS: ES: CR0: 8005003b
> CR2: 186a CR3: 7d963000 CR4: 06e0
> Process sh (pid: 3996, threadinfo 810071562000, task 810070c74ea0)
> Stack: 001242d2 81e88000 810070e76710 812e31e0
> 00e8d4a51000 810077d11b00
> 000e 810071563f50 2adc51042000 81071a67
> Call Trace:
> [] alloc_fresh_huge_page+0x98/0xe7
> [] hugetlb_sysctl_handler+0x14/0xf1
> [] proc_sys_write+0x7c/0xa6
> [] vfs_write+0xad/0x156
> [] sys_write+0x45/0x6e
> [] tracesys+0xdc/0xe1
>
>
> Code: 49 83 7c 24 08 00 75 0e 48 c7 44 24 08 00 00 00 00 e9 6a 02
> RIP [] __alloc_pages+0x2f/0x2c3
> RSP
> CR2: 186a
>
> >From your patch, if we dont the lock, the race condition maybe occur at
> next_node().
>
> On 2007-07-17 21:35, Hugh Dickins wrote:
> > On Tue, 17 Jul 2007, Andrew Morton wrote:
> > >
> > > Given that we've now gone and added deliberate-but-we-hope-benign
> > > races into this code, an elaborate comment which explains and justifies
> > > it all is pretty much obligatory, IMO.
> >
> > [PATCH] Remove nid_lock from alloc_fresh_huge_page
> >
> > The fix to that race in alloc_fresh_huge_page() which could give an illegal
> > node ID did not need nid_lock at all: the fix was to replace static int nid
> > by static int prev_nid and do the work on local int nid. nid_lock did make
> > sure that racers strictly roundrobin the nodes, but that's not something we
> > need to enforce strictly. Kill nid_lock.
> >
> > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
> > ---
> > mm/hugetlb.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > --- 2.6.22-git9/mm/hugetlb.c2007-07-17 20:29:33.0 +0100
> > +++ linux/mm/hugetlb.c 2007-07-17 21:29:58.0 +0100
> > @@ -107,15 +107,19 @@ static int alloc_fresh_huge_page(void)
> > {
> > static int prev_nid;
> > struct page *page;
> > - static DEFINE_SPINLOCK(nid_lock);
> > int nid;
> >
> > - spin_lock(_lock);
> > + /*
> > +* Copy static prev_nid to local nid, work on that, then copy it
> > +* back to prev_nid afterwards: otherwise there's a window in which
> > +* a racer might pass invalid nid MAX_NUMNODES to alloc_pages_node.
> > +* But we don't need to use a spin_lock here: it really doesn't
> > +* matter if occasionally a racer chooses the same nid as we do.
> > +*/
> > nid = next_node(prev_nid, node_online_map);
> > if (nid == MAX_NUMNODES)
> > nid = first_node(node_online_map);
> > prev_nid = nid;
> > - spin_unlock(_lock);
> >
> > page = alloc_pages_node(nid, htlb_alloc_mask|__GFP_COMP|__GFP_NOWARN,
> > HUGETLB_PAGE_ORDER);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
[PATCH] Mark sparc and sparc64 as not having virt_to_bus
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/sparc/Kconfig |3 +++
arch/sparc64/Kconfig |3 +++
include/asm-sparc64/io.h |5 -
3 files changed, 6 insertions(+), 5 deletions(-)
This is part of a rash attempt to make allmodconfig builds work for sparc
and sparc64 :-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 73df711..603d83a 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -21,6 +21,9 @@ config GENERIC_ISA_DMA
bool
default y
+config ARCH_NO_VIRT_TO_BUS
+ def_bool y
+
source "init/Kconfig"
menu "General machine setup"
diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig
index b84b6af..df6ee71 100644
--- a/arch/sparc64/Kconfig
+++ b/arch/sparc64/Kconfig
@@ -62,6 +62,9 @@ config AUDIT_ARCH
bool
default y
+config ARCH_NO_VIRT_TO_BUS
+ def_bool y
+
choice
prompt "Kernel page size"
default SPARC64_PAGE_SIZE_8KB
diff --git a/include/asm-sparc64/io.h b/include/asm-sparc64/io.h
index ad595b6..9565a89 100644
--- a/include/asm-sparc64/io.h
+++ b/include/asm-sparc64/io.h
@@ -14,11 +14,6 @@
#define __SLOW_DOWN_IO do { } while (0)
#define SLOW_DOWN_IO do { } while (0)
-extern unsigned long virt_to_bus_not_defined_use_pci_map(volatile void *addr);
-#define virt_to_bus virt_to_bus_not_defined_use_pci_map
-extern unsigned long bus_to_virt_not_defined_use_pci_map(volatile void *addr);
-#define bus_to_virt bus_to_virt_not_defined_use_pci_map
-
/* BIO layer definitions. */
extern unsigned long kern_base, kern_size;
#define page_to_phys(page) (page_to_pfn(page) << PAGE_SHIFT)
--
1.5.2.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: [PATCH] Optimize struct task_delay_info
On Wed, 2007-07-11 at 17:16 +0530, Balbir Singh wrote: > Zhang, Yanmin wrote: > > struct task_delay_info is used by per process block I/O delay statistics > > feature which is useful in kernel. This struct is not optimized. > > > > My patch against kernel 2.6.22 shrinks it a half. > > > > 1) Delete blkio_start and blkio_end. As the collection happens in > > io_schedule and io_schedule_timeout, we use local variables to > > replace them; > > 2) Delete lock. The change to the protected data has no nested cases. > > In addition, the result is for performance data collection, so it’s > > unnecessary to add such lock. > > 3) Delete flags. It just has one value. Use the most significant bit of > > blkio_delay (64 bits) to mark it.. > > > > > > Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]> > > Hi, Yanmin, > > Did you see any particular performance issues with the delay accounting > patches? Is the patch tested; could you please provide test results? It's hard to find an appropriate benchmark to test it. Anyway, I used sysbench to test it on my x86_64 machine. My machine has 16 logical cpu, dual-core+hyperThread. memory is 8GB and disk is one SATA. I tested both sequence and rand. 1) seq read/write:use command line: echo "3">/proc/sys/vm/drop_caches; sysbench --test=fileio --file-test-mode=seqrewr --num-threads=32 --file-total-size=1500M --max-requests=15 --max-time=3000 run; Run the command for 20 times and get average result: Without patch: 49.7511Mb/sec With patch: 51.6557Mb/sec Improvement: 3.8% 2) Rand read/write:use command line: echo "3">/proc/sys/vm/drop_caches; sysbench --test=fileio --file-test-mode=rndrw --num-threads=32 --file-total-size=800M --max-requests=15000 --max-time=3000 run; Run the command for 10 times and get average result: Without patch: 7.25657Mb/sec With patch: 7.35052Mb/sec Improvement: 1.3% I didn't use application to read the delay accounting info. If I did, I guess the improvement is better. > > Meanwhile, I'll review these patches and I am correcting Shailabh's id > to his new email id. Thanks. Yanmin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Containers: css_put() dilemma
Paul (??) Menage wrote: > On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote: >> without too much knowledge of each other. BTW, what are the semantics >> of css_put() is it expected to free the container/run the release agent >> when the reference count of the container_subsys_state drops to zero? >> > > If you css_put() the last reference on a subsystem state object and > the associated container is marked as notify_on_release, then > check_for_release() is called which does a more full check of whether > the container is releasable. If it is, a workqueue task is scheduled > to run the userspace release agent, which can then do anything it > wants, including potentially deleting the empty container. > Ok.. so my problem still remains, how do I get a non-blocking atomic reference increment/decrement routine, that would prevent my container from being deleted? I don't find cpusets using css_put(). I was hoping that we could alter css_* would provide the functionality I need. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
init_mm locking
Another things I stumbled on lately when toying with some mm rework on powerpc, is the lack of any locking when manipulating init_mm page tables. We don't use the pte_lockptr (well, we don't know where the pmd comes from here, we can't toy around with that struct page), but we don't use anything else either. Granted, we shouldn't manipulate kernel PTEs racily in the sense that we only touch them when mapping or when unmapping and those two things shouldn't race... except that while remove_vm_area takes the vmlinux lock while calling unmap_vm_areas, there are a couple of callers of it that don't, and we never seem to have any lock around map_vm_area. That means that while the allocation mechanism ensures somewhat that we won't be accessing the same area both ways, we don't provide any ordering/barriers for the PTE accesses to those, and I can well imagine unlikely scenarii like: CPU A CPU B map_vm_area set_pte_at unmap_vm_area ptep_get_and_clear (CPU B immediately unmapping what CPU A just mapped) Where the store of CPU A's set_pte_at will end up after the ptep_get_and_clear(). Granted, I have never seen a real life case of it, but I'm a little bit annoyed that we have a set of PTE accessors that aren't protected by a lock of any sort (not even preemption) here. Should't we at least take a sem or maybe use init_mm's PTL for that ? Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] UP: smp_call_function_single() must warn on irqs_disabled()
On Wed, 18 Jul 2007, Satyam Sharma wrote: > On Wed, 18 Jul 2007, Al Viro wrote: > > > On Wed, Jul 18, 2007 at 01:24:46AM +0200, Uwe Kleine-Konig wrote: > > > [...] > > > a52b1752c07 introduces usage of the WARN_ON macro in , but > > > doesn't pull in . ( is not enough, at least > > > for arm, because WARN_ON uses printk there.) > > > > > > The obvious options are: > > > > > > 1) include in , maybe conditioned by !SMP > > > 2) include in all includers of > > > 3) remove the WARN_ONs introduced by a52b1752c07. > > > [...] > > > > 4) turn the sucker into macro > > > I think that warning is incorrect anyway ... and I'm to blame > for that. What happened is that I had earlier (month or two back, > _before_ the recent change in smp_call_function_single() semantics) > submitted a patch that put an unconditional WARN_ON(1) in this > function for UP -- in those days, both the smp_call_function* > variants were illegal on the current CPU itself. > ( http://lkml.org/lkml/2007/6/7/262 ) > > Then recently, Andi / Avi proposed the new semantics for > smp_call_function_single() to allow it to just execute the given > function on current CPU as well -- smp_call_function() semantics > were left unchanged, so as not to break stuff like smp_send_stop(). > > I think I got confused and recommended the (cpuid != 0) warning, > but I don't really think it is necessary with new semantics -- > sorry about this, Avi. > > OTOH, the function _should_ include a WARN_ON, but for a different > condition -- irqs_disabled(), as explained in changelog below. But on third thoughts, we shouldn't be executing that function locally for UP if cpuid != 0 anyway, so my earlier suggestion wasn't really erroneous ... perhaps *both* those warnings are required (well, the irqs_disabled() one definitely is, at least). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches 1/2] warnings: attack valid cases spotted by warnings
> Quite frankly, I don't quite understand where you get those enormous balls > you have, that you can then talk about how ugly it is to just add a "= 0" > that shuts up a compiler warning. That's the _least_ ugly part of the > whole damn function! The clanking when I walk annoys people in the office too... But you're right. It is stupid of me to make such a big deal about this. My excuse is that I've seen those warnings so many times and actually given them more thought than they deserve, and I really felt that Jeff's change makes the admittedly already ugly code a tiny little bit worse. > Anyway, here's a totally untested cleanup that compiles but probably > doesn't work, because I didn't check that I did the right thing with all > the pointer arithmetic (ie when I change "wqe" to a real structure pointer > instead of just a "void *", maybe I left some pointer arithmetic around > that expected it to work as a byte pointer, but now really works on the > whole structure size instead). Given that you took the time to do this, I'll get the patch into a working state and apply it. And maybe split it into reviewable chunks while I'm at it ;) Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernation considerations
On Wed, 18 Jul 2007, Matthew Garrett wrote: On Tue, Jul 17, 2007 at 08:19:32AM -0700, [EMAIL PROTECTED] wrote: On Tue, 17 Jul 2007, Matthew Garrett wrote: Powering off rather than using S4 means you lose most wakeup device support. That would be a functional regression compared to the current code. only if the kexec isn't able to initialize those devices. If you aren't using ACPI, you probably don't know how to. the current kexec patch to allow you to move back to the original kernel requires ACPI be disabled to work. that states pretty strongly that kexec isn't dependant on ACPI to initialize devices. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches 1/2] warnings: attack valid cases spotted by warnings
On Tue, 17 Jul 2007, Roland Dreier wrote:
>
> I think this patch (on top of the previous one) actually makes the
> code clearer
Quite frankly, calling this "making the code clearer" is a bit ridiculous.
That code still is absolute *crap* from a readability angle. It doesn't
follow any sane coding standards, and certainly not the most important
ones ("keep the function small", "don't have tons of local variables"),
and it has absolutely ridiculously ugly casts that get repeated over and
over and over again.
Quite frankly, I don't quite understand where you get those enormous balls
you have, that you can then talk about how ugly it is to just add a "= 0"
that shuts up a compiler warning. That's the _least_ ugly part of the
whole damn function!
So rather than sending out that idiotic patch, look at that code for five
seconds, and ponder whether it really needs to be that ugly.
Here's a few things that you could *really* do to make it somewhat more
readable:
- make that whole "switch()" statement from hell another function
entirely, and have it return the size of the thing, so that you don't
need to have
wqe += xxx
size += xxx / 16;
repeated fifty times (and so that it's also obvious that the
always matches).
- make each switch case actually call a small function with the argument
cast to the right pointer type, so that you need *one* cast per case,
rather than a handful.
End result? More readable source code, with functions that are 20 lines
long (or less), rather than 200 lines of spagetti-coding.
And you know what? That's actually more important than 16 bytes of object
code, although looking at the size of the infiniband code, I *seriously*
doubt any infiniband person has ever cared about object code size in their
life. That thing is not for weak machines or stomachs.
The warnign (and fixing it up) is the _least_ of the problems in that
code, methinks.
Anyway, here's a totally untested cleanup that compiles but probably
doesn't work, because I didn't check that I did the right thing with all
the pointer arithmetic (ie when I change "wqe" to a real structure pointer
instead of just a "void *", maybe I left some pointer arithmetic around
that expected it to work as a byte pointer, but now really works on the
whole structure size instead).
So this patch is NOT meant to be applied, but it is meant to teach people
how things like this should be done. They should *not* be one big function
with lots of case statements. They should be lots of small functions!
Linus
---
drivers/infiniband/hw/mthca/mthca_qp.c | 236 ---
1 files changed, 122 insertions(+), 114 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c
b/drivers/infiniband/hw/mthca/mthca_qp.c
index 11f1d99..74da9bc 100644
--- a/drivers/infiniband/hw/mthca/mthca_qp.c
+++ b/drivers/infiniband/hw/mthca/mthca_qp.c
@@ -1578,6 +1578,113 @@ static inline int mthca_wq_overflow(struct mthca_wq
*wq, int nreq,
return cur + nreq >= wq->max;
}
+static int handle_next_seg(struct ib_send_wr *wr, struct mthca_next_seg * wqe)
+{
+ wqe->nda_op = 0;
+ wqe->ee_nds = 0;
+ wqe->flags =((wr->send_flags & IB_SEND_SIGNALED) ?
+cpu_to_be32(MTHCA_NEXT_CQ_UPDATE) : 0) |
+ ((wr->send_flags & IB_SEND_SOLICITED) ?
+cpu_to_be32(MTHCA_NEXT_SOLICIT) : 0) |
+ cpu_to_be32(1);
+
+ if (wr->opcode == IB_WR_SEND_WITH_IMM ||
+ wr->opcode == IB_WR_RDMA_WRITE_WITH_IMM)
+ wqe->imm = wr->imm_data;
+
+ return sizeof(struct mthca_next_seg);
+}
+
+static int handle_raddr_seg(struct mthca_dev *dev, struct mthca_qp *qp, struct
ib_send_wr *wr,
+ struct mthca_raddr_seg *wqe, int ind)
+{
+ switch (qp->transport) {
+ case RC:
+ switch (wr->opcode) {
+ case IB_WR_ATOMIC_CMP_AND_SWP:
+ case IB_WR_ATOMIC_FETCH_AND_ADD: {
+ struct mthca_atomic_seg *atomic;
+
+ wqe->raddr = cpu_to_be64(wr->wr.atomic.remote_addr);
+ wqe->rkey = cpu_to_be32(wr->wr.atomic.rkey);
+ wqe->reserved = 0;
+
+ atomic = (struct mthca_atomic_seg *) (wqe+1);
+
+ if (wr->opcode == IB_WR_ATOMIC_CMP_AND_SWP) {
+ atomic->swap_add =
cpu_to_be64(wr->wr.atomic.swap);
+ atomic->compare =
cpu_to_be64(wr->wr.atomic.compare_add);
+ } else {
+ atomic->swap_add =
cpu_to_be64(wr->wr.atomic.compare_add);
+ atomic->compare = 0;
+ }
+
+ return sizeof (struct mthca_raddr_seg) +
+ sizeof (struct mthca_atomic_seg);
+ }
+
+ case
[PATCH] UP: smp_call_function_single() must warn on irqs_disabled()
On Wed, 18 Jul 2007, Al Viro wrote:
> On Wed, Jul 18, 2007 at 01:24:46AM +0200, Uwe Kleine-Konig wrote:
> > [...]
> > a52b1752c07 introduces usage of the WARN_ON macro in , but
> > doesn't pull in . ( is not enough, at least
> > for arm, because WARN_ON uses printk there.)
> >
> > The obvious options are:
> >
> > 1) include in , maybe conditioned by !SMP
> > 2) include in all includers of
> > 3) remove the WARN_ONs introduced by a52b1752c07.
> > [...]
>
> 4) turn the sucker into macro
I think that warning is incorrect anyway ... and I'm to blame
for that. What happened is that I had earlier (month or two back,
_before_ the recent change in smp_call_function_single() semantics)
submitted a patch that put an unconditional WARN_ON(1) in this
function for UP -- in those days, both the smp_call_function*
variants were illegal on the current CPU itself.
( http://lkml.org/lkml/2007/6/7/262 )
Then recently, Andi / Avi proposed the new semantics for
smp_call_function_single() to allow it to just execute the given
function on current CPU as well -- smp_call_function() semantics
were left unchanged, so as not to break stuff like smp_send_stop().
I think I got confused and recommended the (cpuid != 0) warning,
but I don't really think it is necessary with new semantics --
sorry about this, Avi.
OTOH, the function _should_ include a WARN_ON, but for a different
condition -- irqs_disabled(), as explained in changelog below.
I'd be grateful if someone could apply this, Cc:'ing Andi too.
Satyam
---
[PATCH] UP: smp_call_function_single() must warn on irqs_disabled()
Because:
(1) smp_call_function_single() semantics dictate that.
(2) That makes UP behaviour similar to SMP case (implementations
of smp_call_function_single() in all the archs do this).
(3) We use the unconditional non-save/restore-flags versions of
local_irq_disable/enable just below this, so it's a bug to
call this function with IRQs disabled anyway.
Also remove the cpuid != 0 warning that I had erroneously
suggested to Avi earlier (sorry!)
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Avi Kivity <[EMAIL PROTECTED]>
---
include/linux/smp.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 259a13c..016dab5 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -101,7 +101,7 @@ static inline void smp_send_reschedule(int cpu) { }
#define smp_prepare_boot_cpu() do {} while (0)
#define smp_call_function_single(cpuid, func, info, retry, wait) \
({ \
- WARN_ON(cpuid != 0);\
+ WARN_ON(irqs_disabled()); \
local_irq_disable();\
(func)(info); \
local_irq_enable(); \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
CONFIG_IDE_PROC_FS: /sys is not full replacement of /proc
May be I miss something obvious but most information that was available in /proc/ide is missing under /sys. At the very least, Mandriva hardware detection expects /proc/ide/hdX/model; nothing close is under /sys. Are there any plans to extend IDE /sys interface to provide full range of information from /proc? Alternatively I appreciate description (or pointer to thereof) how to get information that was available under /proc/ide without /proc/ide :) Thank you -andrey signature.asc Description: This is a digitally signed message part.
Re: [git patches 1/2] warnings: attack valid cases spotted by warnings
Roland Dreier wrote:
In this case the code is basically
u32 x;
for (n = 0; cond; ++n) {
...
if (!n)
x = something;
...
}
if (n) {
...
use(x);
...
}
and gcc still warns...
Interestingly, the above accurately describes a common code pattern
matching code which caused gcc to emit the uninit'd-var warnings.
For the record I think initializating 'f0' to zero is safer for the
reasons Linus gave, and in addition, f0 is or'd with a value written to
a hardware register, which means things should go awry (if they go) in a
semi-predictable manner.
According to the assembly language produced, sure it is larger -- by one
(per function) MOV that is adjacent to other initializations, making it
highly likely the initializations are all streamed together. I doubt
one MOV per function will make a huge difference, considering the peace
of mind it buys.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Further 2.6.23 merge plans...
> > But to be fair, it will be difficult to enable both QoS and local PR > > caching. To me, this would be the strongest reason against using it. > > However, QoS places additional burden on the SA, which will make scaling > > even more challenging. > > my understanding is that the local sa does a path-query where all the fields > except for the SGID are wildcard-ed. This means we expect the result to be a > table of all the paths from this port to every other port on the fabrics for > every pkey which this port is a member of etc, correct? > > How do you plug here the QoS concept of SID in the path query? are you > expecting the SA to realize what are all the services for which this port is > a "member"? does the proposed definision for QoS management at the SA > defines "services per gids" isn't it "what SL to user per Service"? Or, thanks for rescuing this post. I think this is an important question. If we merge the local SA stuff, then are we creating a problem for dealing with QoS? Are we going to have to revert the local SA stuff once the QoS stuff is available? Or is there at least a sketch of a plan on how to handle this? - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] fs: Add romfs version 2
On 7/18/07, Matt Mackall <[EMAIL PROTECTED]> wrote: > > * Adds new derivative of romfs filesystem (rom2fs) with > > block aligned regular file data to bring performance > > parity with ext2/3. This is about 225% of the read > > speed of the existing romfs. Doesn't that make these filesystems much bigger? By, on average, .5k per file? Or, if I'm understanding things correctly, ~1k? Yes, my experience has been that it has been almost chillingly close to .5k per regular file increase in partition size. I know in applications in which size is utterly critical this may be slightly unattractive, but in cases where romfs is chosen for its byte reproducibility and read-only nature the size/performance tradeoff is fairly advantageous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches 1/2] warnings: attack valid cases spotted by warnings
> > So setting a variable to something meaningless (guaranteeing that a
> > garbage value is used in case of a bug) just to shut up a warning makes
> > no sense -- it's no safer than leaving the code as is.
>
> Wrong.
>
> It's safer for two reasons:
> - now everybody will see the *same* behaviour
> - the "meaningless value" is guaranteed to not be a security leak
>
> but the whole "shut up bogus warnings" is the best reason.
>
> So it *is* safer than leaving the code as-is.
OK, fair enough. What I said wasn't quite right, but in my case I
think neither of your reasons really applies, since the uninitialized
variable would be written into some hardware control block, so the
effect would probably still be random even if the value is the same
and the information leak doesn't really matter.
Anyway, I think that in this case it's not too hard to show that the
variable really can't be used uninitialized, so I prefer the smaller
generated code from uninitialized_var() (plus a comment explaining why
that's safe).
> Of course, usually the best approach is to rewrite the code to be simpler,
> so that even gcc sees that something is obviously initialized. Sadly,
> people seldom do the right thing, and sometimes gcc just blows incredibly
> hard.
In this case the code is basically
u32 x;
for (n = 0; cond; ++n) {
...
if (!n)
x = something;
...
}
if (n) {
...
use(x);
...
}
and gcc still warns...
- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sysfs root link count broken in 2.6.22-git5
Hello, Sorry about late response. -EWASPUBLICHOLIDAY. That's something I've broken apparently. Will fix soon. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][DOC]hpet.txt broken link fix
On 7/11/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: Dave Young wrote: > Hi, randy > > how about remove the spec links in the header files as well. > > Subject: > Remove document links in hpet header files. > > Signed-off-by: Dave Young <[EMAIL PROTECTED]> Agreed. Acked-by: Randy Dunlap <[EMAIL PROTECTED]> > --- > include/asm-i386/hpet.h |6 -- > include/asm-x86_64/hpet.h |6 -- > 2 files changed, 12 deletions(-) > > diff -pur linux/include/asm-i386/hpet.h linux.new/include/asm-i386/hpet.h > --- linux/include/asm-i386/hpet.h 2007-07-11 11:15:42.0 + > +++ linux.new/include/asm-i386/hpet.h 2007-07-11 11:16:51.0 + > @@ -28,12 +28,6 @@ > > #include > > -/* > - * Documentation on HPET can be found at: > - * http://www.intel.com/ial/home/sp/pcmmspec.htm > - * ftp://download.intel.com/ial/home/sp/mmts098.pdf > - */ > - > #define HPET_MMAP_SIZE 1024 > > #define HPET_ID 0x000 > diff -pur linux/include/asm-x86_64/hpet.h linux.new/include/asm-x86_64/hpet.h > --- linux/include/asm-x86_64/hpet.h 2007-07-11 11:16:07.0 + > +++ linux.new/include/asm-x86_64/hpet.h 2007-07-11 11:17:03.0 + > @@ -1,12 +1,6 @@ > #ifndef _ASM_X8664_HPET_H > #define _ASM_X8664_HPET_H 1 > > -/* > - * Documentation on HPET can be found at: > - * http://www.intel.com/ial/home/sp/pcmmspec.htm > - * ftp://download.intel.com/ial/home/sp/mmts098.pdf > - */ > - > #define HPET_MMAP_SIZE 1024 > > #define HPET_ID 0x000 Hi, This patch seems to be missed. Regards dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches 1/2] warnings: attack valid cases spotted by warnings
On Tue, 17 Jul 2007, Roland Dreier wrote: > > So setting a variable to something meaningless (guaranteeing that a > garbage value is used in case of a bug) just to shut up a warning makes > no sense -- it's no safer than leaving the code as is. Wrong. It's safer for two reasons: - now everybody will see the *same* behaviour - the "meaningless value" is guaranteed to not be a security leak but the whole "shut up bogus warnings" is the best reason. So it *is* safer than leaving the code as-is. Of course, usually the best approach is to rewrite the code to be simpler, so that even gcc sees that something is obviously initialized. Sadly, people seldom do the right thing, and sometimes gcc just blows incredibly hard. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches 1/2] warnings: attack valid cases spotted by warnings
I think this patch (on top of the previous one) actually makes the
code clearer, and also makes it smaller:
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-41 (-41)
function old new delta
mthca_tavor_post_send 13441335 -9
mthca_tavor_post_receive 792 776 -16
mthca_arbel_post_send 14811465 -16
So I'll test this a bit and probably merge it.
---
diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c
b/drivers/infiniband/hw/mthca/mthca_qp.c
index 0e9ef24..186bade 100644
--- a/drivers/infiniband/hw/mthca/mthca_qp.c
+++ b/drivers/infiniband/hw/mthca/mthca_qp.c
@@ -1590,13 +1590,14 @@ int mthca_tavor_post_send(struct ib_qp *ibqp, struct
ib_send_wr *wr,
int nreq;
int i;
int size;
- int size0 = 0;
/*
-* f0 is only used if nreq != 0, and f0 will be initialized
-* the first time through the main loop, since size0 == 0 the
-* first time through. So nreq cannot become non-zero without
-* initializing f0, and f0 is in fact never used uninitialized.
+* f0 and size0 are only used if nreq != 0, and they will
+* always be initialized the first time through the main loop
+* before nreq is incremented. So nreq cannot become non-zero
+* without initializing f0 and size0, and they are in fact
+* never used uninitialized.
*/
+ int uninitialized_var(size0);
u32 uninitialized_var(f0);
int ind;
u8 op0 = 0;
@@ -1774,11 +1775,11 @@ int mthca_tavor_post_send(struct ib_qp *ibqp, struct
ib_send_wr *wr,
mthca_opcode[wr->opcode]);
wmb();
((struct mthca_next_seg *) prev_wqe)->ee_nds =
- cpu_to_be32((size0 ? 0 : MTHCA_NEXT_DBD) | size |
+ cpu_to_be32((nreq ? 0 : MTHCA_NEXT_DBD) | size |
((wr->send_flags & IB_SEND_FENCE) ?
MTHCA_NEXT_FENCE : 0));
- if (!size0) {
+ if (!nreq) {
size0 = size;
op0 = mthca_opcode[wr->opcode];
f0= wr->send_flags & IB_SEND_FENCE ?
@@ -1828,7 +1829,14 @@ int mthca_tavor_post_receive(struct ib_qp *ibqp, struct
ib_recv_wr *wr,
int nreq;
int i;
int size;
- int size0 = 0;
+ /*
+* size0 is only used if nreq != 0, and it will always be
+* initialized the first time through the main loop before
+* nreq is incremented. So nreq cannot become non-zero
+* without initializing size0, and it is in fact never used
+* uninitialized.
+*/
+ int uninitialized_var(size0);
int ind;
void *wqe;
void *prev_wqe;
@@ -1887,7 +1895,7 @@ int mthca_tavor_post_receive(struct ib_qp *ibqp, struct
ib_recv_wr *wr,
((struct mthca_next_seg *) prev_wqe)->ee_nds =
cpu_to_be32(MTHCA_NEXT_DBD | size);
- if (!size0)
+ if (!nreq)
size0 = size;
++ind;
@@ -1909,7 +1917,6 @@ int mthca_tavor_post_receive(struct ib_qp *ibqp, struct
ib_recv_wr *wr,
qp->rq.next_ind = ind;
qp->rq.head += MTHCA_TAVOR_MAX_WQES_PER_RECV_DB;
- size0 = 0;
}
}
@@ -1951,13 +1958,14 @@ int mthca_arbel_post_send(struct ib_qp *ibqp, struct
ib_send_wr *wr,
int nreq;
int i;
int size;
- int size0 = 0;
/*
-* f0 is only used if nreq != 0, and f0 will be initialized
-* the first time through the main loop, since size0 == 0 the
-* first time through. So nreq cannot become non-zero without
-* initializing f0, and f0 is in fact never used uninitialized.
+* f0 and size0 are only used if nreq != 0, and they will
+* always be initialized the first time through the main loop
+* before nreq is incremented. So nreq cannot become non-zero
+* without initializing f0 and size0, and they are in fact
+* never used uninitialized.
*/
+ int uninitialized_var(size0);
u32 uninitialized_var(f0);
int ind;
u8 op0 = 0;
@@ -1978,7 +1986,6 @@ int mthca_arbel_post_send(struct ib_qp *ibqp, struct
ib_send_wr *wr,
doorbell[1] = cpu_to_be32((qp->qpn << 8) | size0);
qp->sq.head += MTHCA_ARBEL_MAX_WQES_PER_SEND_DB;
- size0 = 0;
/*
* Make sure that descriptors are written before
@@ -2163,7 +2170,7 @@ int mthca_arbel_post_send(struct ib_qp *ibqp, struct
ib_send_wr *wr,
((wr->send_flags & IB_SEND_FENCE) ?
[PATCH 3/3] [net/core] move __dev_addr_discard adjacent to dev_addr_discard for readability
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
net/core/dev.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 17c9cbd..6357f54 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2715,20 +2715,6 @@ int __dev_addr_add(struct dev_addr_list **list, int
*count,
return 0;
}
-static void __dev_addr_discard(struct dev_addr_list **list)
-{
- struct dev_addr_list *tmp;
-
- while (*list != NULL) {
- tmp = *list;
- *list = tmp->next;
- if (tmp->da_users > tmp->da_gusers)
- printk("__dev_addr_discard: address leakage! "
- "da_users=%d\n", tmp->da_users);
- kfree(tmp);
- }
-}
-
/**
* dev_unicast_delete - Release secondary unicast address.
* @dev: device
@@ -2777,6 +2763,20 @@ int dev_unicast_add(struct net_device *dev, void *addr,
int alen)
}
EXPORT_SYMBOL(dev_unicast_add);
+static void __dev_addr_discard(struct dev_addr_list **list)
+{
+ struct dev_addr_list *tmp;
+
+ while (*list != NULL) {
+ tmp = *list;
+ *list = tmp->next;
+ if (tmp->da_users > tmp->da_gusers)
+ printk("__dev_addr_discard: address leakage! "
+ "da_users=%d\n", tmp->da_users);
+ kfree(tmp);
+ }
+}
+
static void dev_addr_discard(struct net_device *dev)
{
netif_tx_lock_bh(dev);
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] [net/core] merge dev_unicast_discard and dev_mc_discard into one
this two functions could share the dev->_xmit_lock acquired context.
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
net/core/dev.c | 16
1 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 3ba63aa..17c9cbd 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2777,23 +2777,16 @@ int dev_unicast_add(struct net_device *dev, void *addr,
int alen)
}
EXPORT_SYMBOL(dev_unicast_add);
-static void dev_unicast_discard(struct net_device *dev)
+static void dev_addr_discard(struct net_device *dev)
{
netif_tx_lock_bh(dev);
+
__dev_addr_discard(>uc_list);
dev->uc_count = 0;
- netif_tx_unlock_bh(dev);
-}
-/*
- * Discard multicast list when a device is downed
- */
-
-static void dev_mc_discard(struct net_device *dev)
-{
- netif_tx_lock_bh(dev);
__dev_addr_discard(>mc_list);
dev->mc_count = 0;
+
netif_tx_unlock_bh(dev);
}
@@ -3751,8 +3744,7 @@ void unregister_netdevice(struct net_device *dev)
/*
* Flush the unicast and multicast chains
*/
- dev_unicast_discard(dev);
- dev_mc_discard(dev);
+ dev_addr_discard(dev);
if (dev->uninit)
dev->uninit(dev);
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] [net/core] move dev_mc_discard from dev_mcast.c to dev.c
Because this function is only called by unregister_netdevice,
this moving could make this non-global function static,
and also remove its declaration in netdevice.h;
Any further, function __dev_addr_discard is also just called by
dev_mc_discard and dev_unicast_discard, keeping this two functions
both in one c file could make __dev_addr_discard also static
and remove its declaration in netdevice.h;
Futhermore, the sequential call to dev_unicast_discard and then
dev_mc_discard in unregister_netdevice have a similar mechanism that:
(netif_tx_lock_bh / __dev_addr_discard / netif_tx_unlock_bh),
they should merged into one to eliminate duplicates in acquiring and
releasing the dev->_xmit_lock, this would be done in my following patch.
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
include/linux/netdevice.h |2 --
net/core/dev.c| 14 +-
net/core/dev_mcast.c | 12
3 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index da7a13c..9820ca1 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1098,10 +1098,8 @@ extern int dev_mc_delete(struct net_device
*dev, void *addr, int alen, int all
extern int dev_mc_add(struct net_device *dev, void *addr, int
alen, int newonly);
extern int dev_mc_sync(struct net_device *to, struct net_device
*from);
extern voiddev_mc_unsync(struct net_device *to, struct net_device
*from);
-extern voiddev_mc_discard(struct net_device *dev);
extern int __dev_addr_delete(struct dev_addr_list **list, int
*count, void *addr, int alen, int all);
extern int __dev_addr_add(struct dev_addr_list **list, int *count,
void *addr, int alen, int newonly);
-extern void__dev_addr_discard(struct dev_addr_list **list);
extern voiddev_set_promiscuity(struct net_device *dev, int inc);
extern voiddev_set_allmulti(struct net_device *dev, int inc);
extern voidnetdev_state_change(struct net_device *dev);
diff --git a/net/core/dev.c b/net/core/dev.c
index 13a0d9f..3ba63aa 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2715,7 +2715,7 @@ int __dev_addr_add(struct dev_addr_list **list, int
*count,
return 0;
}
-void __dev_addr_discard(struct dev_addr_list **list)
+static void __dev_addr_discard(struct dev_addr_list **list)
{
struct dev_addr_list *tmp;
@@ -2785,6 +2785,18 @@ static void dev_unicast_discard(struct net_device *dev)
netif_tx_unlock_bh(dev);
}
+/*
+ * Discard multicast list when a device is downed
+ */
+
+static void dev_mc_discard(struct net_device *dev)
+{
+ netif_tx_lock_bh(dev);
+ __dev_addr_discard(>mc_list);
+ dev->mc_count = 0;
+ netif_tx_unlock_bh(dev);
+}
+
unsigned dev_get_flags(const struct net_device *dev)
{
unsigned flags;
diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
index 235a2a8..99aece1 100644
--- a/net/core/dev_mcast.c
+++ b/net/core/dev_mcast.c
@@ -177,18 +177,6 @@ void dev_mc_unsync(struct net_device *to, struct
net_device *from)
}
EXPORT_SYMBOL(dev_mc_unsync);
-/*
- * Discard multicast list when a device is downed
- */
-
-void dev_mc_discard(struct net_device *dev)
-{
- netif_tx_lock_bh(dev);
- __dev_addr_discard(>mc_list);
- dev->mc_count = 0;
- netif_tx_unlock_bh(dev);
-}
-
#ifdef CONFIG_PROC_FS
static void *dev_mc_seq_start(struct seq_file *seq, loff_t *pos)
{
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches 1/2] warnings: attack valid cases spotted by warnings
> I don't buy that performance argument, in this case. You are already
> dirtying the same cacheline with other variable initializations.
>
> Like I noted in the changeset description (hey, this is precisely why
> I included it, so that we could have this discussion), IMO the flow of
> control makes it not only impossible for the compiler to understand
> the full value range of 'f0', but also difficult for humans as well.
>
> I could perhaps understand initializing the variable to some poison
> value rather than zero, but IMO the code is stronger with f0 set to a
> sane value.
The more I think about it, the less sense initializing f0 to 0 makes.
The whole problem with an uninitialized variable is that a random
value from the stack might be used. So setting a variable to
something meaningless (guaranteeing that a garbage value is used in
case of a bug) just to shut up a warning makes no sense -- it's no
safer than leaving the code as is. uninitialized_var() gets rid of
the warning, saves a little text and instruction cache, and documents
things better.
(BTW, I agree the code is a little confusing as written. I think
things could be cleaned up and made more efficient by getting rid of
the initialization of size0 too -- I'll look at doing that)
Anyway, I queued this up for my next merge with Linus:
commit 6d7d080e9f7cd535a8821efd3835c5cfa5223ab6
Author: Roland Dreier <[EMAIL PROTECTED]>
Date: Tue Jul 17 19:30:51 2007 -0700
IB/mthca: Use uninitialized_var() for f0
Commit 9db48926 ("drivers/infiniband/hw/mthca/mthca_qp: kill uninit'd
var warning") added "= 0" to the declarations of f0 to shut up gcc
warnings. However, there's no point in making the code bigger by
initializing f0 to a random value just to get rid of a warning;
setting f0 to 0 is no safer than just using uninitialized_var(), which
documents the situation better and gives smaller code too. For example,
on x86_64:
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-16 (-16)
function old new delta
mthca_tavor_post_send 13521344 -8
mthca_arbel_post_send 14891481 -8
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c
b/drivers/infiniband/hw/mthca/mthca_qp.c
index 11f1d99..0e9ef24 100644
--- a/drivers/infiniband/hw/mthca/mthca_qp.c
+++ b/drivers/infiniband/hw/mthca/mthca_qp.c
@@ -1591,7 +1591,13 @@ int mthca_tavor_post_send(struct ib_qp *ibqp, struct
ib_send_wr *wr,
int i;
int size;
int size0 = 0;
- u32 f0 = 0;
+ /*
+* f0 is only used if nreq != 0, and f0 will be initialized
+* the first time through the main loop, since size0 == 0 the
+* first time through. So nreq cannot become non-zero without
+* initializing f0, and f0 is in fact never used uninitialized.
+*/
+ u32 uninitialized_var(f0);
int ind;
u8 op0 = 0;
@@ -1946,7 +1952,13 @@ int mthca_arbel_post_send(struct ib_qp *ibqp, struct
ib_send_wr *wr,
int i;
int size;
int size0 = 0;
- u32 f0 = 0;
+ /*
+* f0 is only used if nreq != 0, and f0 will be initialized
+* the first time through the main loop, since size0 == 0 the
+* first time through. So nreq cannot become non-zero without
+* initializing f0, and f0 is in fact never used uninitialized.
+*/
+ u32 uninitialized_var(f0);
int ind;
u8 op0 = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
On 07/17/2007 01:27 AM, Matt Mackall wrote:
Larger soft pages waste tremendous amounts of memory (mostly in page
cache) for minimal benefit on, say, the typical desktop. While there
are workloads where it's a win, it's probably on a small percentage of
machines.
So it's absolutely no help in fixing our order-1 allocation problem
because we don't want to force large pages on people.
I was just now looking at how much space is in fact wasted in pagecache for
various pagesizes by running the attached dumb little program from a few
selected directories (heavy stack recursion, never mind).
Well, hmmm. This is on a (compiled) git tree:
[EMAIL PROTECTED]:~/src/linux/local$ pageslack
total : 447350347
4k : 67738037 (15%)
8k : 147814837 (33%)
16k : 324614581 (72%)
32k : 724629941 (161%)
64k : 1592785333 (356%)
Nicely constant factor 2.2 instead of the 2 one would expect but oh well. On
a collection of larger files the percentages obviously drop. This is on a
directory of ogg vorbis files:
[EMAIL PROTECTED]:/mnt/ogg/.../... # pageslack
total : 70817974
4k : 26442 (0%)
8k : 67402 (0%)
16k : 124746 (0%)
32k : 288586 (0%)
64k : 419658 (0%)
The "typical desktop" is presented by neither I guess but does involve audio
and (much larger still) video and bloody huge browser apps.
Not too sure then that 8K wouldn't be something I'd want, given fewer
pagefaults and all that...
Rene.
/* gcc -W -Wall -o pageslack pageslack.c */
#include
#include
#include
#include
#include
#include
#include
#define PAGE_SIZE (1UL << PAGE_SHIFT)
#define PAGE_MASK (~(PAGE_SIZE - 1))
unsigned long long total;
unsigned long long slack[5];
void do_dir(const char *name)
{
DIR *dir;
struct dirent *ent;
dir = opendir(name);
if (!dir) {
perror("opendir");
exit(EXIT_FAILURE);
}
while ((ent = readdir(dir))) {
struct stat buf;
char path[PATH_MAX];
if (!strcmp(ent->d_name, "."))
continue;
if (!strcmp(ent->d_name, ".."))
continue;
sprintf(path, "%s/%s", name, ent->d_name);
if (stat(path, )) {
perror("stat");
exit(EXIT_FAILURE);
}
if (S_ISDIR(buf.st_mode)) {
do_dir(path);
continue;
}
if (S_ISREG(buf.st_mode)) {
int i;
for (i = 0; i < 5; i++) {
unsigned long PAGE_SHIFT = 12 + i;
slack[i] += (PAGE_SIZE - (buf.st_size %
PAGE_SIZE)) % PAGE_SIZE;
}
total += buf.st_size;
}
}
if (closedir(dir)) {
perror("closedir");
exit(EXIT_FAILURE);
}
}
int main(void)
{
do_dir(".");
printf("total\t: %llu\n", total);
printf(" 4k\t: %llu (%llu%%)\n", slack[0], (100 * slack[0]) / total);
printf(" 8k\t: %llu (%llu%%)\n", slack[1], (100 * slack[1]) / total);
printf("16k\t: %llu (%llu%%)\n", slack[2], (100 * slack[2]) / total);
printf("32k\t: %llu (%llu%%)\n", slack[3], (100 * slack[3]) / total);
printf("64k\t: %llu (%llu%%)\n", slack[4], (100 * slack[4]) / total);
return EXIT_SUCCESS;
}
Re: [PATCH] Re: 2.6.22-git ppc build failure
On Wed, 18 Jul 2007, Tony Breeds wrote: > > On Tue, Jul 17, 2007 at 06:44:26PM -0700, Linus Torvalds wrote: > > > Thanks. I assume this has been boot-tested too, and everything else from > > the PCI merge was ok? > > *cough* umm the boot test fails. I'll look harder at the merge, and > provide a better patch. Ok, thanks. Maybe it's the merge, and maybe it's one of the sides. You might want to double-check that both parents are ok before you look too closely at the merge itself. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 2.6.22-git ppc build failure
On Tue, Jul 17, 2007 at 06:44:26PM -0700, Linus Torvalds wrote: > Thanks. I assume this has been boot-tested too, and everything else from > the PCI merge was ok? *cough* umm the boot test fails. I'll look harder at the merge, and provide a better patch. Yours Tony linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/ Jan 28 - Feb 02 2008 The Australian Linux Technical Conference! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernation considerations
On Tue, Jul 17, 2007 at 08:19:32AM -0700, [EMAIL PROTECTED] wrote: > On Tue, 17 Jul 2007, Matthew Garrett wrote: > >Powering off rather than using S4 means you lose most wakeup device > >support. That would be a functional regression compared to the current > >code. > > only if the kexec isn't able to initialize those devices. If you aren't using ACPI, you probably don't know how to. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] SELinux Netlabel updates
On Tuesday 17 July 2007 8:24:55 pm Linus Torvalds wrote: > On Tue, 17 Jul 2007, James Morris wrote: > > These are updated Netlabel/SELinux changes from Paul, reworked so that > > they don't break userspace. Michal says they work for him. Please apply > > for 2.6.23. > > They don't work AT ALL for me: > > security/selinux/ss/sidtab.o: In function `netlbl_enabled': > sidtab.c:(.text+0x0): multiple definition of `netlbl_enabled' > security/selinux/ss/ebitmap.o:ebitmap.c:(.text+0x0): first defined here > > Tssk. > > That dummy "netlbl_enabled()" should be "static inline", methinks. > > Also, that file has two blocks after each other of > > #ifdef CONFIG_NETLABEL > .. > #else > .. > #endif > > #ifdef CONFIG_NETLABEL > .. > #else > .. > #endif > > which might as well be cleaned up at the same time (and might have avoided > this bug, since then the people involved would have seen the _correct_ > example in the first version) Oh my. I'll fix this and get another version out to James and Michal tomorrow morning; I have to spend the rest of the night smacking myself in the forehead. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
Sasa Ostrouska wrote: I want to ask one question about a custom resolution in the console. I have a Sony Vaio Laptop VGN-SZ2VP/X, the screen resolution is 1280x800, now I'm using the vga=773 which is an 1024x768 but this is ugly as I get a border of about 2-3cm on one the sides of the screen. So is there a way that I set the 1280x800 resolution at boot time ? I don't think vesafb can do what you want. However, uvesafb probably can. http://dev.gentoo.org/~spock/projects/uvesafb/ 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] appletouch powersaving - please apply for 2.6.23-rc1 take #3
On Tuesday 17 July 2007 14:16, Soeren Sonnenburg wrote:
> On Tue, 2007-07-17 at 11:01 -0400, Dmitry Torokhov wrote:
> > Hi,
> >
> > On 7/17/07, Soeren Sonnenburg <[EMAIL PROTECTED]> wrote:
> > >
> > > err_free_buffer:
> > > @@ -656,6 +699,7 @@ static void atp_disconnect(struct usb_interface
> > > *iface)
> > >
> > >usb_set_intfdata(iface, NULL);
> > >if (dev) {
> > > + cancel_work_sync(>work);
> > >usb_kill_urb(dev->urb);
> > >input_unregister_device(dev->input);
> > >usb_buffer_free(dev->udev, dev->datalen,
> > >
> >
> > This should go into atp_close() and I think you need to do
> > cancel_work_sync after calling usb_kill_urb() otherwise you risk it
> > being submitted while you gettingto kill the urb.
>
> good catch. modified patch accordingly+attached.
>
> > How many boxes did you try this patch on?
>
> Mine plus 1 other. However please note that Matthews patch has been
> (which is what this patch is based on) is in the mactel-patches
> repository for quite some time now and that the not-yet-cleanup up
> variant of this patch was posted to mactel-devel...
>
> So the modeswitch part should work...
>
OK, can I please get signed-off-bys for the latest version so I can
apply it?
Thanks!
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 2.6.22-git ppc build failure
On Wed, 18 Jul 2007, Tony Breeds wrote: > > Fix compile failure in arch/powerpc/kernel/pci-common.c Thanks. I assume this has been boot-tested too, and everything else from the PCI merge was ok? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add nid sanity on alloc_pages_node
With your patch, I have reproduced the panic:
Unable to handle kernel paging request at 186a RIP:
[] __alloc_pages+0x2f/0x2c3
PGD 72595067 PUD 72594067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: xt_tcpudp iptable_filter ip_tables x_tables cpufreq_ondemand
dm_mirror dm_multipath dm_mod video sbs button battery backlight ac
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm sg
snd_timer shpchp snd soundcore tg3 i2c_i801 piix i2c_core snd_page_alloc ide_cd
cdrom serio_raw ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd
uhci_hcd
Pid: 3996, comm: sh Not tainted 2.6.22 #9
RIP: 0010:[] [] __alloc_pages+0x2f/0x2c3
RSP: 0018:810071563e48 EFLAGS: 00010246
RAX: RBX: 00e8d4a51000 RCX:
RDX: 810071563fd8 RSI: 0009 RDI: 000242d2
RBP: 000242d2 R08: R09: 00043a01
R10: 81e88000 R11: 81072a02 R12: 1862
R13: 810070c74ea0 R14: 0009 R15: 2adc51042000
FS: 2adc4db3ddb0() GS:81312000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 186a CR3: 7d963000 CR4: 06e0
Process sh (pid: 3996, threadinfo 810071562000, task 810070c74ea0)
Stack: 001242d2 81e88000 810070e76710 812e31e0
00e8d4a51000 810077d11b00
000e 810071563f50 2adc51042000 81071a67
Call Trace:
[] alloc_fresh_huge_page+0x98/0xe7
[] hugetlb_sysctl_handler+0x14/0xf1
[] proc_sys_write+0x7c/0xa6
[] vfs_write+0xad/0x156
[] sys_write+0x45/0x6e
[] tracesys+0xdc/0xe1
Code: 49 83 7c 24 08 00 75 0e 48 c7 44 24 08 00 00 00 00 e9 6a 02
RIP [] __alloc_pages+0x2f/0x2c3
RSP
CR2: 186a
>From your patch, if we dont the lock, the race condition maybe occur at
next_node().
On 2007-07-17 21:35, Hugh Dickins wrote:
> On Tue, 17 Jul 2007, Andrew Morton wrote:
> >
> > Given that we've now gone and added deliberate-but-we-hope-benign
> > races into this code, an elaborate comment which explains and justifies
> > it all is pretty much obligatory, IMO.
>
> [PATCH] Remove nid_lock from alloc_fresh_huge_page
>
> The fix to that race in alloc_fresh_huge_page() which could give an illegal
> node ID did not need nid_lock at all: the fix was to replace static int nid
> by static int prev_nid and do the work on local int nid. nid_lock did make
> sure that racers strictly roundrobin the nodes, but that's not something we
> need to enforce strictly. Kill nid_lock.
>
> Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
> ---
> mm/hugetlb.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> --- 2.6.22-git9/mm/hugetlb.c 2007-07-17 20:29:33.0 +0100
> +++ linux/mm/hugetlb.c2007-07-17 21:29:58.0 +0100
> @@ -107,15 +107,19 @@ static int alloc_fresh_huge_page(void)
> {
> static int prev_nid;
> struct page *page;
> - static DEFINE_SPINLOCK(nid_lock);
> int nid;
>
> - spin_lock(_lock);
> + /*
> + * Copy static prev_nid to local nid, work on that, then copy it
> + * back to prev_nid afterwards: otherwise there's a window in which
> + * a racer might pass invalid nid MAX_NUMNODES to alloc_pages_node.
> + * But we don't need to use a spin_lock here: it really doesn't
> + * matter if occasionally a racer chooses the same nid as we do.
> + */
> nid = next_node(prev_nid, node_online_map);
> if (nid == MAX_NUMNODES)
> nid = first_node(node_online_map);
> prev_nid = nid;
> - spin_unlock(_lock);
>
> page = alloc_pages_node(nid, htlb_alloc_mask|__GFP_COMP|__GFP_NOWARN,
> HUGETLB_PAGE_ORDER);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Geode GX framebuffer driver: Arcom vs. AMD
On 14/07/07 17:05 -0400, Andrew Paprocki wrote: > Tony, > > Do you have the patch working already? I'd love to try this out in the > meantime on the LX system I am developing with at the moment. I'm > assuming you worked this into the existing Arcom framework (gxfb) and > pulled the necessary pieces from the AMD code? Actually no. There was enough extra stuff in the lxfb par structure that I just made it its own driver. The other two Geode drivers really try to be more generic then they should be. There is probably code that can be shared between the three, but the core is just different enough that the drivers shouldn't be merged together. > Also, question for AMD/Jordan.. Is AMD going to provide any > support/patches for the existing gxfb and this new lxfb? (Maybe > perhaps an AMD supported DirectFB driver? :)) You asked two different questions. Yes, we plan to support the gxfb and lxfb code in the kernel for the foreseeable future. No, we are not going to support any additional graphics engines beyond the kernel framebuffer driver and the X driver. Sorry. > If anyone else is interested, I'll get around to making a patch of the > work I just did to bring the original AMD 2.6.11 framebuffer & > Cimarron fully up to date with the 2.6.22 tree. If AMD is going to > continue to maintain their own driver, this will allow the use of an > up-to-date kernel. I don't believe we're going to continue maintaining that driver for new kernels when the lxfb goes into the kernel. I now really regret using Cimarron for that previous driver - that was a combination of laziness on my part, and a general naivity by AMD as to how the kernel works. We soon realized what should have been obvious from the start - a massive processor specific HAL to support two drivers just doesn't belong in the kernel. Thats why we never sent it up, and thats why we wrote the new lxfb driver. Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patches for REALLY TINY 386 kernels
Jonathan Campbell <[EMAIL PROTECTED]> writes: > I wrote a set of patches out of concern that even if you compile a 386 > kernel a lot of code irrelevent to legacy machines still > remains. Things like the Pentium TSC register, DMI information, ESCD > parsing, and the use of CPUID do not apply to these machines, but > looking at System.map you can see they're still there. I'm afraid a lot of this, like the CPUID changes, are fairly pointless because they are __cpuinit code anyways. This means (unless you compiled a kernel with CPU hotplug support enabled) it will be all freed after boot. > Already with these patches I can compile a zImage kernel that is 450kb > large (890kb decompressed) The important part is not how big the vmlinux is, but how much memory is actually used after boot. I expect concentrating some of the dynamic data structures would be more fruitful in fact. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix leaks on /proc/{*/sched,sched_debug,timer_list,timer_stats}
* Andrew Morton ([EMAIL PROTECTED]) wrote: > Sorry, but I can't be bothered splitting it up. Greg, Chris: please just > apply the bits which apply and drop the other bits if that's OK. Yup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] CFS scheduler, -v19
Ingo Molnar wrote: * Ian Kent <[EMAIL PROTECTED]> wrote: ah! It passes in a low-res time source into a high-res time interface (pthread_cond_timedwait()). Could you change the time(NULL) + 1 to time(NULL) + 2, or change it to: gettimeofday(, NULL); wait.tv_sec++; OK, I'm with you, hi-res timer. But even so, how is the time in the past after adding a second. Is it because I'm not setting tv_nsec when it's close to a second boundary, and hence your recommendation above? yeah, it looks a bit suspicious: you create a +1 second timeout out of a 1 second resolution timesource. I dont yet understand the failure mode though that results in that looping and in the 30% CPU time use - do you understand it perhaps? (and automount is still functional while this is happening, correct?) Can't say, I have automount running because I get it by default, but I have nothing using at on my test machine. Why is it looping so fast when there are no mount points defined? If the config changes there's no requirement to notice right away, is there? -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 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] Pass nr_wake2 to futex_wake_op
On Tue, 17 Jul 2007 13:31:29 +0200 Andreas Schwab <[EMAIL PROTECTED]> wrote: > The fourth argument of sys_futex is ignored when op == FUTEX_WAKE_OP, > but futex_wake_op expects it as its nr_wake2 parameter. > > The only user of this operation in glibc is always passing 1, so this > bug had no consequences so far. > > Signed-off-by: Andreas Schwab <[EMAIL PROTECTED]> > > --- > kernel/futex.c |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > --- linux-2.6.22.orig/kernel/futex.c 2007-07-02 00:40:44.0 +0200 > +++ linux-2.6.22/kernel/futex.c 2007-07-07 15:56:42.0 +0200 > @@ -2061,8 +2061,10 @@ asmlinkage long sys_futex(u32 __user *ua > } > /* >* requeue parameter in 'utime' if cmd == FUTEX_REQUEUE. > + * number of waiters to wake in 'utime' if cmd == FUTEX_WAKE_OP. >*/ > - if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE) > + if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE || > + cmd == FUTEX_WAKE_OP) > val2 = (u32) (unsigned long) utime; > > return do_futex(uaddr, op, val, tp, uaddr2, val2, val3); > So if an application or glibc _does_ start passing in non-1 values, it will malfunction on earlier kernels? So that userspace code would need to have a test for the kernel version, I assume? All a bit of a hassle. Still, I'd propose that this change (if the thus-far-silent cc'ees agree with it?) go into 2.6.22.x at least. If it gets accepted into 2.6.22.x then applications (or glibc) will need to test for kernels as far back as 2.6.22. Really they would need to test for the correct value of x in 2.6.22.x, but I don't know if glibc is set up for that. Thoughts? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Re: 2.6.22-git ppc build failure
On Tue, Jul 17, 2007 at 11:04:57AM -0700, Bret Towe wrote:
> this is off my g4 mac mini
> latest git as of when this email was sent
> config file attached
Hi Bret,
the patch below will fix it.
From: Tony Breeds <[EMAIL PROTECTED]>
Fix compile failure in arch/powerpc/kernel/pci-common.c
CC arch/powerpc/kernel/pci-common.o
arch/powerpc/kernel/pci-common.c:160: error: conflicting types for
'pcibios_add_platform_entries'
include/linux/pci.h:889: error: previous declaration of
'pcibios_add_platform_entries' was here
Fallout from the powerpc merge (489de30259e667d7bc47da9da44a0270b050cd97).
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci-common.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Index: working/arch/powerpc/kernel/pci-common.c
===
--- working.orig/arch/powerpc/kernel/pci-common.c 2007-07-18
10:34:55.0 +1000
+++ working/arch/powerpc/kernel/pci-common.c2007-07-18 10:39:19.0
+1000
@@ -156,11 +156,14 @@ static DEVICE_ATTR(devspec, S_IRUGO, pci
#endif /* CONFIG_PPC_OF */
/* Add sysfs properties */
-void pcibios_add_platform_entries(struct pci_dev *pdev)
+int pcibios_add_platform_entries(struct pci_dev *pdev)
{
#ifdef CONFIG_PPC_OF
- device_create_file(>dev, _attr_devspec);
+ return device_create_file(>dev, _attr_devspec);
+#else
+ return 0;
#endif /* CONFIG_PPC_OF */
+
}
char __init *pcibios_setup(char *str)
Yours Tony
linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 leaks on /proc/{*/sched,sched_debug,timer_list,timer_stats}
On Tue, 17 Jul 2007 14:36:10 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > > > On every open/close one struct seq_operations leaks. > > Kudos to /proc/slab_allocators. > > > > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> > > ouch ... > > Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > > -stable material too, as far as timer_info/stats goes. So I have a patch which will not fully apply to -stable. Sorry, but I can't be bothered splitting it up. Greg, Chris: please just apply the bits which apply and drop the other bits if that's OK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] AFS: Fix file locking
On Tue, 17 Jul 2007 13:47:32 +0100
David Howells <[EMAIL PROTECTED]> wrote:
> + if (type == AFS_LOCK_READ &&
> + vnode->flags & (1 << AFS_VNODE_READLOCKED)) {
Here we use
vnode->flags & (1 << foo)
> + set_bit(AFS_VNODE_LOCKING, >flags);
and elsewhere we use set_bit(foo, >flags) and clear_bit()
This is a bit strange. Does the open-coded bit-test have any performance
benefit on any architecture? Not on x86 at least, afaik.
Please consider converting all that stuff to test_bit() sometime. It sure
would look a lot better.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23 compile failure - slab/slob interspanking
On Wed, Jul 18, 2007 at 09:18:36AM +0900, Paul Mundt wrote: > On Tue, Jul 17, 2007 at 10:00:08PM +0200, Jan Engelhardt wrote: > > 81cda6626178cd55297831296ba8ecedbfd8b52d is first bad commit > > commit 81cda6626178cd55297831296ba8ecedbfd8b52d > > Author: Christoph Lameter <[EMAIL PROTECTED]> > > Date: Tue Jul 17 04:03:29 2007 -0700 > > > > Slab allocators: Cleanup zeroing allocations > > > > It becomes now easy to support the zeroing allocs with generic inline > > functions in slab.h. Provide inline definitions to allow the continued > > use of > > kzalloc, kmem_cache_zalloc etc but remove other definitions of zeroing > > functions from the slab allocators and util.c. > > > > Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > This fixes it for me with your .config: > > slob: Kill off duplicate kzalloc() definition. > > With the slab zeroing allocations cleanups Christoph stubbed in a generic > kzalloc(), which was missed on SLOB. Follow the SLAB/SLUB changes and > kill off the __kzalloc() wrapper that SLOB was using. Looks fine to me. > Reported-by: Jan Engelhardt <[EMAIL PROTECTED]> > Signed-off-by: Paul Mundt <[EMAIL PROTECTED]> Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] SELinux Netlabel updates
On Wed, 18 Jul 2007, Michal Piotrowski wrote:
>
> Once again I tested both patches, build log shows only this
You clearly didn't test them with CONFIG_NETLABEL set to off, or you have
a buggy compiler.
You had
int netlbl_enabled(void)
{
return 0;
}
in a header file.
Now think for a moment what happens when that header file gets included
multiple times from different C files?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 37/44] xen: add virtual network device driver
Rusty Russell wrote: > The default function points to the internal stats... > Right you are. 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/
Re: [PATCH 0/2] SELinux Netlabel updates
Linus Torvalds pisze: > > On Tue, 17 Jul 2007, James Morris wrote: >> These are updated Netlabel/SELinux changes from Paul, reworked so that >> they don't break userspace. Michal says they work for him. Please apply >> for 2.6.23. > > They don't work AT ALL for me: > > security/selinux/ss/sidtab.o: In function `netlbl_enabled': > sidtab.c:(.text+0x0): multiple definition of `netlbl_enabled' > security/selinux/ss/ebitmap.o:ebitmap.c:(.text+0x0): first defined here > > Tssk. Once again I tested both patches, build log shows only this Root device is (8, 1) Setup is 10264 bytes (padded to 10752 bytes). System is 2040 kB WARNING: vmlinux(.text+0xc1001183): Section mismatch: reference to .init.text:start_kernel (between 'is386' and 'check_x87') WARNING: vmlinux(.text+0xc126dafb): Section mismatch: reference to .init.text: (between 'rest_init' and 'kthreadd_setup') WARNING: vmlinux(.text+0xc1271a3b): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext') WARNING: vmlinux(.text+0xc1271a48): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext') WARNING: vmlinux(.text+0xc1271a54): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext') WARNING: vmlinux(.text+0xc1271a60): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext') WARNING: vmlinux(.text+0xc126dc11): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'alloc_node_mem_ map' and 'zone_wait_table_init') WARNING: vmlinux(.text+0xc126dc9b): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'zone_wait_table _init' and '__sched_text_start') WARNING: vmlinux(.text+0xc1272252): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext') gcc --version gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12) > > That dummy "netlbl_enabled()" should be "static inline", methinks. > > Also, that file has two blocks after each other of > > #ifdef CONFIG_NETLABEL > .. > #else > .. > #endif > > #ifdef CONFIG_NETLABEL > .. > #else > .. > #endif > > which might as well be cleaned up at the same time (and might have avoided > this bug, since then the people involved would have seen the _correct_ > example in the first version) > > Please fix up and ask me to pull again. Preferably by actually fixing up > the commit itself, so that we don't unnecessarily have revisions that > don't even compile and thus potentially screw up git-bisect attempts. > > Linus > Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23 compile failure - slab/slob interspanking
On Wed, 18 Jul 2007 09:18:36 +0900
Paul Mundt <[EMAIL PROTECTED]> wrote:
> --- a/include/linux/slob_def.h
> +++ b/include/linux/slob_def.h
> @@ -33,14 +33,4 @@ static inline void *__kmalloc(size_t size, gfp_t flags)
> return kmalloc(size, flags);
> }
>
> -/**
> - * kzalloc - allocate memory. The memory is set to zero.
> - * @size: how many bytes of memory are required.
> - * @flags: the type of memory to allocate (see kcalloc).
> - */
> -static inline void *kzalloc(size_t size, gfp_t flags)
> -{
> - return __kzalloc(size, flags);
> -}
yeah, that might well have got lost somewhere in the past month's mayhem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote: On Tuesday, 17 July 2007 14:48, Huang, Ying wrote: On Tue, 2007-07-17 at 01:13 -0700, [EMAIL PROTECTED] wrote: however, since the resume designed for ACPI won't work would the following approach work 1. boot one kernel 2. setup a kexec the same way you would for hibernate 3. kexec to the new kernel 4. overwrite the memory of the first kernel 5. kexec 'back' to the main kernel that has now been overwritten by what was saved? as part of this question, when you do a kexec, how does the kernel that you are doing the kexec to know what to run next? For kernel in 3 that do kexec, the devices and CPU state are saved into memory before executing the new kernel. So when jumping back, the control will continue from kexec point. If the memory image of main kernel is restored from disk, the devices and CPU state in memory is restored too. Before jumping back in 5, the devices are put in the known state, after jumping back, the devices and CPU state is restored. If the "kexec -j" is used to trigger the kexec in 3, the system will continue with "kexec -j" exiting with exit code 0. it needs to do some initialization first before it starts running normal things, and at that point it the move back doesn't look for init like a normal kernel boot (or the system would effectivly boot instead of picking up where it left off) I think the early initialization can be done in a initramfs. At that point, the resume image can be checked, the next step depends on the result of checking. is this 'restart point' flexible enough that either the pre-hibernate kerenl or the small hibernate kernel could tell the pre-hibernate kernel to go into suspend-to-ram mode before doing anything else? It is possible for hibernate kernel to pass information back to pre-hibernate kernel. For example, the information can be passed in jump buffer page. I think it would be reasonable to have a protocol defined for passing this information, so that it's independent of the kernel version etc. At this point it looks like we have the following communication nessasary between the two kernels 1. the original kernel needs to create a map of what memory to backup this could be either a bitmap, or a series of address:blockcount pairs. in either case the result could be sizeable, so it's probably best to define a standard location to find the type and address of the data. 2. the new kernel needs to tell the old kernel which 'restart point' to use. this could be a simple jump table. the list that has been suggested so far is A. restore (the default) B. suspend-to-ram C. ACPI suspend-to-disk (S4 mode) since both kernels have access to the other kernel's memory the data could be stored in either kernel's address space, but my initial thought is that it's cleaner to store this in the original kernel's space and have the second kernel find it there. I don't have the knowledge to create either of these interfaces, let alone the pull to get them implmented in the kernel. could I ask that one of you consider makeing a patch that implements at least #1 (the memory map) it sounds as if these kexec-back patches plus makeing the memory map available would allow for a ACPI-free hibernate mode with no other modifications. I'd like to try experimenting with this, but without the memory map it sounds as if things will croak when I try to do this. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block/bsg.c
[ James, please remeber to cc: linux-ide on IDE patches, thanks. ]
On Wednesday 18 July 2007, Jeff Garzik wrote:
> James Bottomley wrote:
> > @@ -1052,9 +1054,10 @@ int generic_ide_ioctl(ide_drive_t *drive, struct
> > file *file, struct block_device
> > int err, (*setfunc)(ide_drive_t *, int);
> > u8 *val;
> >
> > - err = scsi_cmd_ioctl(file, bdev->bd_disk->queue, bdev->bd_disk, cmd, p);
> > - if (err != -ENOTTY)
> > - return err;
> > + switch (cmd) {
> > + case SG_IO:
> > + return scsi_cmd_ioctl(file, bdev->bd_disk->queue,
> > bdev->bd_disk, cmd, p);
> > + }
> >
> > switch (cmd) {
> > case HDIO_GET_32BIT:val = >io_32bit; goto read_val;
>
>
> At that point you might as well use an 'if'.
>
> But overall -- agreed. ACK.
James/Jeff thanks for following the issue but NAK. ;)
Causes regression wrt ide-floppy CDROMEJECT/CDROMCLOSETRAY support when
compared to 2.6.22 and SG_IO is not supported by ide-{disk,scsi,tape}.
Luckily Linus has already fixed the issue properly.
BTW cmd == 1 IOCTL is not defined/used by IDE driver.
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 0/2] SELinux Netlabel updates
On Tue, 17 Jul 2007, James Morris wrote: > > These are updated Netlabel/SELinux changes from Paul, reworked so that > they don't break userspace. Michal says they work for him. Please apply > for 2.6.23. They don't work AT ALL for me: security/selinux/ss/sidtab.o: In function `netlbl_enabled': sidtab.c:(.text+0x0): multiple definition of `netlbl_enabled' security/selinux/ss/ebitmap.o:ebitmap.c:(.text+0x0): first defined here Tssk. That dummy "netlbl_enabled()" should be "static inline", methinks. Also, that file has two blocks after each other of #ifdef CONFIG_NETLABEL .. #else .. #endif #ifdef CONFIG_NETLABEL .. #else .. #endif which might as well be cleaned up at the same time (and might have avoided this bug, since then the people involved would have seen the _correct_ example in the first version) Please fix up and ask me to pull again. Preferably by actually fixing up the commit itself, so that we don't unnecessarily have revisions that don't even compile and thus potentially screw up git-bisect attempts. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
On 07/18/2007 01:39 AM, Jesper Juhl wrote: On 17/07/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote: At hch's suggestion I rewrote the separate IRQ stack configurability patch into one making IRQ stacks mandatory and unconfigurable, and hence enabled with 8K stacks. For what it's worth, that sounds good to me - like something that we would want merged. Yes, seperate IRQ stacks make eminent sense in their own right. Andrea Arcangeli's current thread on soft pages: http://lkml.org/lkml/2007/7/6/346 is also interesting though in the context of 1-page stacks. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block/bsg.c
From: James Bottomley <[EMAIL PROTECTED]>
Subject: Re: block/bsg.c
Date: Tue, 17 Jul 2007 13:53:54 -0500
> On Tue, 2007-07-17 at 12:19 +0200, Jens Axboe wrote:
> > > > Since Linus is happily snoring by now, could you test and see if the
> > > > tree works for you?
> > >
> > > It works for me. I'll submit some minor patches against your bsg
> > > branch to scsi-ml. Can you push them together?
> >
> > Certainly, I'll pull them into the bsg branch.
>
> While you're at it, here's a patch to separate BSG and SCSI again (so
> SCSI can be built modular). The way I did it was simply to move the
> SCSI specific logic into SCSI. When you come up with a generic way to
> register the bsg requiring drivers, then we can move it out again.
Thanks, looks nice.
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -714,6 +714,7 @@ static int attr_add(struct device *dev, struct
> device_attribute *attr)
> int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> {
> int error, i;
> + struct request_queue *rq = sdev->request_queue;
>
> if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
> return error;
> @@ -733,6 +734,16 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> /* take a reference for the sdev_classdev; this is
>* released by the sdev_class .release */
> get_device(>sdev_gendev);
> +
> + if (rq->kobj.parent)
> + error = bsg_register_queue(rq, kobject_name(rq->kobj.parent));
> + else
> + error = bsg_register_queue(rq,
> kobject_name(>sdev_gendev.kobj));
> + if (error) {
> + sdev_printk(KERN_INFO, sdev, "Failed to register bsg queue\n");
> + goto out;
Needs more cleanup here?
We might just ignore the error here since it's not fatal not to create
a bsg device, I guess.
I updated the patch against the latest code (which has just be merged
to Linus's tree).
diff --git a/block/Kconfig b/block/Kconfig
index 0768741..93adf61 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -53,7 +53,7 @@ endif # BLOCK
config BLK_DEV_BSG
bool "Block layer SG support v4 (EXPERIMENTAL)"
- depends on (SCSI=y) && EXPERIMENTAL
+ depends on EXPERIMENTAL
---help---
Saying Y here will enable generic SG (SCSI generic) v4 support
for any block device.
diff --git a/block/bsg.c b/block/bsg.c
index baa04e7..4e0be1b 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -1009,29 +1009,6 @@ err:
}
EXPORT_SYMBOL_GPL(bsg_register_queue);
-static int bsg_add(struct class_device *cl_dev, struct class_interface
*cl_intf)
-{
- int ret;
- struct scsi_device *sdp = to_scsi_device(cl_dev->dev);
- struct request_queue *rq = sdp->request_queue;
-
- if (rq->kobj.parent)
- ret = bsg_register_queue(rq, kobject_name(rq->kobj.parent));
- else
- ret = bsg_register_queue(rq,
kobject_name(>sdev_gendev.kobj));
- return ret;
-}
-
-static void bsg_remove(struct class_device *cl_dev, struct class_interface
*cl_intf)
-{
- bsg_unregister_queue(to_scsi_device(cl_dev->dev)->request_queue);
-}
-
-static struct class_interface bsg_intf = {
- .add= bsg_add,
- .remove = bsg_remove,
-};
-
static struct cdev bsg_cdev = {
.kobj = {.name = "bsg", },
.owner = THIS_MODULE,
@@ -1069,16 +1046,9 @@ static int __init bsg_init(void)
if (ret)
goto unregister_chrdev;
- ret = scsi_register_interface(_intf);
- if (ret)
- goto remove_cdev;
-
printk(KERN_INFO BSG_DESCRIPTION " version " BSG_VERSION
" loaded (major %d)\n", bsg_major);
return 0;
-remove_cdev:
- printk(KERN_ERR "bsg: failed register scsi interface %d\n", ret);
- cdev_del(_cdev);
unregister_chrdev:
unregister_chrdev_region(MKDEV(bsg_major, 0), BSG_MAX_DEVS);
destroy_bsg_class:
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index ed72086..9ebd215 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -714,6 +714,7 @@ static int attr_add(struct device *dev,
int scsi_sysfs_add_sdev(struct scsi_device *sdev)
{
int error, i;
+ struct request_queue *rq = sdev->request_queue;
if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
return error;
@@ -733,6 +734,15 @@ int scsi_sysfs_add_sdev(struct scsi_devi
/* take a reference for the sdev_classdev; this is
* released by the sdev_class .release */
get_device(>sdev_gendev);
+
+ if (rq->kobj.parent)
+ error = bsg_register_queue(rq, kobject_name(rq->kobj.parent));
+ else
+ error = bsg_register_queue(rq,
kobject_name(>sdev_gendev.kobj));
+
+ if (error)
+ sdev_printk(KERN_INFO, sdev, "Failed to register bsg queue\n");
+
if (sdev->host->hostt->sdev_attrs) {
for (i = 0; sdev->host->hostt->sdev_attrs[i];
Occational lockups during boot with post 2.6.22 kernels
Current -git kernels sometimes lock up on my computer during boot. I guess it happens about 10-20% of the time. I first saw this maybe a week ago, but never with kernels <= 2.6.22. The last reported info on the console is that named is started. SysRq-T still works and reports the non-sleeping tasks below. My guess is that wpa_supplicant and events/0 deadlock and later the named thread also hangs when it needs a deadlocked resource. I'm using the bcm43xx driver. No lockdep errors are reported before the lockup. Earlier during boot the kernel reports: Good, all 218 testcases passed! | SysRq-T output: === events/0 D 0001 0 5 2 dfe0fe64 0092 935ee27c 0001 c0345e48 935ee27c 0001 c0462fc0 0001 dcab5040 dcd44de4 dcd44da4 0246 dfe0cb90 dfe0fea0 c0345df6 0002 c0346026 dcd44dd0 dcd44dd0 dcd44dd0 dfe0cb90 Call Trace: [] __mutex_lock_slowpath+0xb2/0x2c6 [] mutex_lock+0x1c/0x1f [] ieee80211softmac_assoc_work+0x24/0x51b [ieee80211softmac] [] ieee80211softmac_assoc_notify_scan+0x13/0x15 [ieee80211softmac] [] ieee80211softmac_notify_callback+0x41/0x7a [ieee80211softmac] [] run_workqueue+0xbb/0x13d [] worker_thread+0x9a/0xf9 [] kthread+0x36/0x58 [] kernel_thread_helper+0x7/0x10 === klogd R running 0 2771 1 wpa_supplican D 0001 0 2806 1 dc309d7c 00200082 935ecce6 0001 c0138e84 935ecce6 0001 00200046 dc309dbc dcab5040 dc309db8 dc309dbc dc309db8 dcd44fd4 dc309da0 c0344f98 0001 dcfdd350 c01186cc dc309de4 dc309de4 dff61740 dcd44fd4 dc309df0 Call Trace: [] wait_for_completion+0x91/0xc8 [] flush_cpu_workqueue+0x47/0x6f [] flush_workqueue+0x1c/0x1f [] flush_scheduled_work+0xd/0xf [] ieee80211softmac_wx_set_essid+0x144/0x188 [ieee80211softmac] [] ioctl_standard_call+0x16b/0x350 [] wext_handle_ioctl+0x35b/0x3e5 [] dev_ioctl+0x322/0x33d [] sock_ioctl+0xba/0x1d8 [] do_ioctl+0x22/0x71 [] vfs_ioctl+0x55/0x28a [] sys_ioctl+0x33/0x51 [] sysenter_past_esp+0x5f/0x99 === named D 0001 0 2836 2834 dbdc5e70 00200082 960324f3 0001 c0345e48 960324f3 0001 c0462fc0 0001 dd0d6300 c0454e20 c0454de0 00200246 c1694fd0 dbdc5eac c0345df6 0002 c0346026 c0454e0c c0454e0c c0454e0c c1694fd0 Call Trace: [] __mutex_lock_slowpath+0xb2/0x2c6 [] mutex_lock+0x1c/0x1f [] rtnl_lock+0xd/0xf [] dev_ioctl+0xb2/0x33d [] sock_ioctl+0xba/0x1d8 [] do_ioctl+0x22/0x71 [] vfs_ioctl+0x55/0x28a [] sys_ioctl+0x33/0x51 [] sysenter_past_esp+0x5f/0x99 -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23 compile failure - slab/slob interspanking
On Tue, Jul 17, 2007 at 10:00:08PM +0200, Jan Engelhardt wrote:
> 81cda6626178cd55297831296ba8ecedbfd8b52d is first bad commit
> commit 81cda6626178cd55297831296ba8ecedbfd8b52d
> Author: Christoph Lameter <[EMAIL PROTECTED]>
> Date: Tue Jul 17 04:03:29 2007 -0700
>
> Slab allocators: Cleanup zeroing allocations
>
> It becomes now easy to support the zeroing allocs with generic inline
> functions in slab.h. Provide inline definitions to allow the continued
> use of
> kzalloc, kmem_cache_zalloc etc but remove other definitions of zeroing
> functions from the slab allocators and util.c.
>
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
>
This fixes it for me with your .config:
slob: Kill off duplicate kzalloc() definition.
With the slab zeroing allocations cleanups Christoph stubbed in a generic
kzalloc(), which was missed on SLOB. Follow the SLAB/SLUB changes and
kill off the __kzalloc() wrapper that SLOB was using.
Reported-by: Jan Engelhardt <[EMAIL PROTECTED]>
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
--
include/linux/slob_def.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/linux/slob_def.h b/include/linux/slob_def.h
index a2daf2d..59a3fa4 100644
--- a/include/linux/slob_def.h
+++ b/include/linux/slob_def.h
@@ -33,14 +33,4 @@ static inline void *__kmalloc(size_t size, gfp_t flags)
return kmalloc(size, flags);
}
-/**
- * kzalloc - allocate memory. The memory is set to zero.
- * @size: how many bytes of memory are required.
- * @flags: the type of memory to allocate (see kcalloc).
- */
-static inline void *kzalloc(size_t size, gfp_t flags)
-{
- return __kzalloc(size, flags);
-}
-
#endif /* __LINUX_SLOB_DEF_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
> I can't speak for Fedora, but RHEL disables XFS in their kernel likely > because it is known to cause problems with 4K stacks. -was- - the SGI folks submitted patches to deal with some gcc problems with stack usage. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
On Mon, 16 Jul 2007 16:15:28 -0700 "Ray Lee" <[EMAIL PROTECTED]> wrote: > On 7/16/07, Rene Herman <[EMAIL PROTECTED]> wrote: > > Yes but it's also an argument that the 4K stacks don't make the _current_ > > situation without CONFIG_4KSTACKS selected worse and given that you trust > > that current situation, that leaves you without your argument :-) > > Heh :-). No, it's not a question of trust. First and foremost, it's > that there are still users who say that they can crash a current > 4k+interrupt stacks kernel, while the 8k without interrupt stacks is > fine. You forgot "most of the time". Its statistically less likely, which merely means its evilly hard to debug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] smp_call_function_single() should be a macro on UP
On Wed, 18 Jul 2007, Ben Dooks wrote: > > This has broken _all_ ARM builds, due to using WARN_ON() > in this header. I think Al's patch already fixes that, since now it's back to being a macro, and thus the whole WARN_ON() is only visible where the macro is _used_, not in the header itself. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Resend][PATCH 1/9] ACPI: Implement the set_target() callback from pm_ops
On Tue, 17 Jul 2007 22:40:06 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> In the future some drivers may need to use ACPI to determine the low power
> states in which to place their devices, but to provide the drivers with this
> information the ACPI core needs to know what sleep state the system is going
> to
> enter. Namely, the device's state should not be too high power for given
> system
> sleep state and, if the device is supposed to be able to wake up the system,
> its
> state should not be too low power for the wake up to be possible). For this
> purpose, the ACPI core needs to implement the set_target() method in 'struct
> pm_ops' and store the target system sleep state passed by the PM core in a
> variable.
>
Len, I can add this to the to-send-to-Len queue, but it would be more
convenient at this end if you were to ack it and I'll send it in.
Preferences?
>
> Index: linux-2.6.22-git5/drivers/acpi/sleep/main.c
> ===
> --- linux-2.6.22-git5.orig/drivers/acpi/sleep/main.c
> +++ linux-2.6.22-git5/drivers/acpi/sleep/main.c
> @@ -34,34 +34,54 @@ static u32 acpi_suspend_states[] = {
>
> static int init_8259A_after_S1;
>
> +extern int acpi_sleep_prepare(u32 acpi_state);
> +extern void acpi_power_off(void);
weep. Please don't do this.
checkpatch will detect this error. Please check patches with checkpatch.
(Full patch reproduced below for the benefit of the newly-added linux-acpi
cc):
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
In the future some drivers may need to use ACPI to determine the low power
states in which to place their devices, but to provide the drivers with this
information the ACPI core needs to know what sleep state the system is going to
enter. Namely, the device's state should not be too high power for given system
sleep state and, if the device is supposed to be able to wake up the system, its
state should not be too low power for the wake up to be possible). For this
purpose, the ACPI core needs to implement the set_target() method in 'struct
pm_ops' and store the target system sleep state passed by the PM core in a
variable.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
drivers/acpi/sleep/main.c | 84 --
1 file changed, 52 insertions(+), 32 deletions(-)
Index: linux-2.6.22-git5/drivers/acpi/sleep/main.c
===
--- linux-2.6.22-git5.orig/drivers/acpi/sleep/main.c
+++ linux-2.6.22-git5/drivers/acpi/sleep/main.c
@@ -34,34 +34,54 @@ static u32 acpi_suspend_states[] = {
static int init_8259A_after_S1;
+extern int acpi_sleep_prepare(u32 acpi_state);
+extern void acpi_power_off(void);
+
+static u32 acpi_target_sleep_state = ACPI_STATE_S0;
+
+/**
+ * acpi_pm_set_target - Set the target system sleep state to the state
+ * associated with given @pm_state, if supported.
+ */
+
+static int acpi_pm_set_target(suspend_state_t pm_state)
+{
+ u32 acpi_state = acpi_suspend_states[pm_state];
+ int error = 0;
+
+ if (sleep_states[acpi_state]) {
+ acpi_target_sleep_state = acpi_state;
+ } else {
+ printk(KERN_ERR "ACPI does not support this state: %d\n",
+ pm_state);
+ error = -ENOSYS;
+ }
+ return error;
+}
+
/**
* acpi_pm_prepare - Do preliminary suspend work.
- * @pm_state: suspend state we're entering.
+ * @pm_state: ignored
*
- * Make sure we support the state. If we do, and we need it, set the
- * firmware waking vector and do arch-specific nastiness to get the
- * wakeup code to the waking vector.
+ * If necessary, set the firmware waking vector and do arch-specific
+ * nastiness to get the wakeup code to the waking vector.
*/
-extern int acpi_sleep_prepare(u32 acpi_state);
-extern void acpi_power_off(void);
-
static int acpi_pm_prepare(suspend_state_t pm_state)
{
- u32 acpi_state = acpi_suspend_states[pm_state];
+ int error = acpi_sleep_prepare(acpi_target_sleep_state);
- if (!sleep_states[acpi_state]) {
- printk("acpi_pm_prepare does not support %d \n", pm_state);
- return -EPERM;
- }
- return acpi_sleep_prepare(acpi_state);
+ if (error)
+ acpi_target_sleep_state = ACPI_STATE_S0;
+
+ return error;
}
/**
* acpi_pm_enter - Actually enter a sleep state.
- * @pm_state: State we're entering.
+ * @pm_state: ignored
*
- * Flush caches and go to sleep. For STR or STD, we have to call
+ * Flush caches and go to sleep. For STR or S2, we have to call
* arch-specific assembly, which in turn call acpi_enter_sleep_state().
* It's unfortunate, but it works. Please fix if you're feeling
Re: [PATCH] posix-timer: fix deletion race
On Tue, 17 Jul 2007, Jeremy Katz wrote:
On Tue, 17 Jul 2007, Thomas Gleixner wrote:
With 2.6.14 or with current mainline ?
I haven't been keeping notes quite as studiously as I should have been, but
this just occurred with 2.6.22.1 + the hrt6 patch + your proposed fix:
Scratch that. I had infrastructure problems, and ended up using the wrong
build.
This is with the patch (and 2.6.22.1 and hrt6):
[ cut here ]
Kernel BUG at c0125adb [verbose debug info unavailable]
invalid opcode: [#1]
SMP
Modules linked in:
CPU:3
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.22.1-WR1.4aq_cgl #2)
EIP is at sigqueue_free+0x23/0x72
eax: ebx: f6eaf1a8 ecx: f6d4b888 edx: 0202
esi: f73e2ba8 edi: ebp: f7c7bf8c esp: f7c7bf84
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process hrtm_test (pid: 15340, ti=f7c7b000 task=f6c0f030 task.ti=f7c7b000)
Stack: 0202 f73e2ba8 f7c7bf9c c012c941 f73e2ba8 02fb f7c7bfb0
c012d1c0
0286 02fb f7c7b000 c01027ca 02fb 466afff4
08064190
ae8d43c8 0107 007b c010007b
0107
Call Trace:
[] show_trace_log_lvl+0x1a/0x30
[] show_stack_log_lvl+0x8d/0xaa
[] show_registers+0x1cd/0x2cb
[] die+0x113/0x207
[] do_trap+0x8f/0xc6
[] do_invalid_op+0x88/0x92
[] error_code+0x72/0x78
[] release_posix_timer+0x1b/0x7a
[] sys_timer_delete+0xd7/0x10c
[] syscall_call+0x7/0xb
===
Code: 74 04 83 48 08 01 5d c3 55 89 e5 56 53 89 c3 8b 40 08 a8 01 74 15 39
1b 75 15 83 e0 fe 89 43 08 89 d8 e8 1d ec ff ff 5b 5e 5d c3 <0f> 0b eb fe
64 a1 00 c0 4a c0 8b b0 50 04 00 00 b8 00 1e 46 c0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] smp_call_function_single() should be a macro on UP
On Wed, Jul 18, 2007 at 12:54:17AM +0100, Ben Dooks wrote: > This has broken _all_ ARM builds, due to using WARN_ON() > in this header. Warn on needs and this is > needs to make it compile cleanly on ARM > which is unfortuantely what we where trying to avoid in > the first place? > > This patch fixes the compile on ARM, but moves the > includes out of the CONFIG_SMP block. Which "this" are you refering to? Original introduction of inline or switch to a macro on top of it? FWIW, with "turn to macro" all arm builds I have here pass fine. Please, check if current Linus' tree (already with that patch) works for you; I very much object to pulling more includes in there, that way lies a lot of breakage. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 6/6] drivers edac add to edac docs
From: Doug Thompson <[EMAIL PROTECTED]> Updated the EDAC kernel documentation Signed-off-by: Doug Thompson <[EMAIL PROTECTED]> --- edac.txt | 192 ++- 1 file changed, 165 insertions(+), 27 deletions(-) Index: linux-2.6.22-rc6-mm1/Documentation/drivers/edac/edac.txt === --- linux-2.6.22-rc6-mm1.orig/Documentation/drivers/edac/edac.txt +++ linux-2.6.22-rc6-mm1/Documentation/drivers/edac/edac.txt @@ -2,22 +2,42 @@ EDAC - Error Detection And Correction -Written by Doug Thompson <[EMAIL PROTECTED]> +Written by Doug Thompson <[EMAIL PROTECTED]> 7 Dec 2005 +17 Jul 2007Updated -EDAC was written by: - Thayne Harbaugh, - modified by Dave Peterson, Doug Thompson, et al, - from the bluesmoke.sourceforge.net project. +EDAC is maintained and written by: + Doug Thompson, Dave Jiang, Dave Peterson et al, + original author: Thayne Harbaugh, + +Contact: + website:bluesmoke.sourceforge.net + mailing list: [EMAIL PROTECTED] + +"bluesmoke" was the name for this device driver when it was "out-of-tree" +and maintained at sourceforge.net. When it was pushed into 2.6.16 for the +first time, it was renamed to 'EDAC'. + +The bluesmoke project at sourceforge.net is now utilized as a 'staging area' +for EDAC development, before it is sent upstream to kernel.org + +At the bluesmoke/EDAC project site, is a series of quilt patches against +recent kernels, stored in a SVN respository. For easier downloading, there +is also a tarball snapshot available. EDAC PURPOSE The 'edac' kernel module goal is to detect and report errors that occur -within the computer system. In the initial release, memory Correctable Errors -(CE) and Uncorrectable Errors (UE) are the primary errors being harvested. +within the computer system running under linux. + +MEMORY + +In the initial release, memory Correctable Errors (CE) and Uncorrectable +Errors (UE) are the primary errors being harvested. These types of errors +are harvested by the 'edac_mc' class of device. Detecting CE events, then harvesting those events and reporting them, CAN be a predictor of future UE events. With CE events, the system can @@ -25,9 +45,27 @@ continue to operate, but with less safet proactive part replacement of memory DIMMs exhibiting CEs can reduce the likelihood of the dreaded UE events and system 'panics'. +NON-MEMORY + +A new feature for EDAC, the edac_device class of device, was added in +the 2.6.23 version of the kernel. + +This new device type allows for non-memory type of ECC hardware detectors +to have their states harvested and presented to userspace via the sysfs +interface. + +Some architectures have ECC detectors for L1, L2 and L3 caches, along with DMA +engines, fabric switches, main data path switches, interconnections, +and various other hardware data paths. If the hardware reports it, then +a edac_device device probably can be constructed to harvest and present +that to userspace. + + +PCI BUS SCANNING In addition, PCI Bus Parity and SERR Errors are scanned for on PCI devices in order to determine if errors are occurring on data transfers. + The presence of PCI Parity errors must be examined with a grain of salt. There are several add-in adapters that do NOT follow the PCI specification with regards to Parity generation and reporting. The specification says @@ -35,11 +73,17 @@ the vendor should tie the parity status to generate parity. Some vendors do not do this, and thus the parity bit can "float" giving false positives. -[There are patches in the kernel queue which will allow for storage of -quirks of PCI devices reporting false parity positives. The 2.6.18 -kernel should have those patches included. When that becomes available, -then EDAC will be patched to utilize that information to "skip" such -devices.] +In the kernel there is a pci device attribute located in sysfs that is +checked by the EDAC PCI scanning code. If that attribute is set, +PCI parity/error scannining is skipped for that device. The attribute +is: + + broken_parity_status + +as is located in /sys/devices/pci/:XX:YY.Z directorys for +PCI devices. + +FUTURE HARDWARE SCANNING EDAC will have future error detectors that will be integrated with EDAC or added to it, in the following list: @@ -57,13 +101,14 @@ and the like. EDAC VERSIONING -EDAC is composed of a "core" module (edac_mc.ko) and several Memory +EDAC is composed of a "core" module (edac_core.ko) and several Memory Controller (MC) driver modules. On a given system, the CORE is loaded and one MC driver will be loaded. Both the CORE and -the MC driver have individual versions that reflect current release -level of their respective modules.
Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
On 07/18/2007 01:19 AM, Bodo Eggert wrote: Please post a list of things you have designed, so I can avoid them. - The ability to read - The ability to understand You're doing a hell of a job already. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 5/6] drivers edac fix edac_device sysfs corner case bug
From: Doug Thompson <[EMAIL PROTECTED]>
Some simple fixes to properly reference counter values from
the block attribute level of edac_device objects. Properly
sequencing the array pointer was added, resulting in correct
identification of block level attributes from their base
class functions.
Added more verbose debug statement for event tracking.
Also during some corner testing, found a bug in the store/show sequence
of operations for the block attribute/controls management.
An old intermediate structure for 'blocks' was still in the
processing pipeline. This patch removes that old structure
and correctly utilizes the new struct edac_dev_sysfs_block_attribute
for passing control from the sysfs to the low level store/show
function of the edac driver.
Now the proper kobj pointer to passed downward to the store/show
functions.
Signed-off-by: Doug Thompson <[EMAIL PROTECTED]>
---
Index: linux-2.6.22-rc6-mm1/drivers/edac/edac_core.h
===
--- linux-2.6.22-rc6-mm1.orig/drivers/edac/edac_core.h
+++ linux-2.6.22-rc6-mm1/drivers/edac/edac_core.h
@@ -485,7 +485,16 @@ struct edac_dev_sysfs_attribute {
};
/* edac_dev_sysfs_block_attribute structure
+ *
* used in leaf 'block' nodes for adding controls/attributes
+ *
+ * each block in each instance of the containing control structure
+ * can have an array of the following. The show and store functions
+ * will be filled in with the show/store function in the
+ * low level driver.
+ *
+ * The 'value' field will be the actual value field used for
+ * counting
*/
struct edac_dev_sysfs_block_attribute {
struct attribute attr;
@@ -494,8 +503,6 @@ struct edac_dev_sysfs_block_attribute {
const char *, size_t);
struct edac_device_block *block;
- /* low driver use */
- void *arg;
unsigned int value;
};
Index: linux-2.6.22-rc6-mm1/drivers/edac/edac_device.c
===
--- linux-2.6.22-rc6-mm1.orig/drivers/edac/edac_device.c
+++ linux-2.6.22-rc6-mm1/drivers/edac/edac_device.c
@@ -83,7 +83,7 @@ struct edac_device_ctl_info *edac_device
void *pvt;
int err;
- debugf1("%s() instances=%d blocks=%d\n",
+ debugf4("%s() instances=%d blocks=%d\n",
__func__, nr_instances, nr_blocks);
/* Calculate the size of memory we need to allocate AND
@@ -158,6 +158,9 @@ struct edac_device_ctl_info *edac_device
/* Name of this edac device */
snprintf(dev_ctl->name,sizeof(dev_ctl->name),"%s",edac_device_name);
+ debugf4("%s() edac_dev=%p next after end=%p\n",
+ __func__, dev_ctl, pvt + sz_private );
+
/* Initialize every Instance */
for (instance = 0; instance < nr_instances; instance++) {
inst = _inst[instance];
@@ -177,8 +180,10 @@ struct edac_device_ctl_info *edac_device
snprintf(blk->name, sizeof(blk->name),
"%s%d", edac_block_name, block+offset_value);
- debugf1("%s() instance=%d block=%d name=%s\n",
- __func__, instance, block, blk->name);
+ debugf4("%s() instance=%d inst_p=%p block=#%d "
+ "block_p=%p name='%s'\n",
+ __func__, instance, inst, block,
+ blk, blk->name);
/* if there are NO attributes OR no attribute pointer
* then continue on to next block iteration
@@ -191,20 +196,32 @@ struct edac_device_ctl_info *edac_device
attrib_p = _attrib[block*nr_instances*nr_attrib];
blk->block_attributes = attrib_p;
+ debugf4("%s() THIS BLOCK_ATTRIB=%p\n",
+ __func__, blk->block_attributes);
+
/* Initialize every user specified attribute in this
* block with the data the caller passed in
+* Each block gets its own copy of pointers,
+* and its unique 'value'
*/
for (attr = 0; attr < nr_attrib; attr++) {
attrib = _p[attr];
- attrib->attr = attrib_spec->attr;
- attrib->show = attrib_spec->show;
- attrib->store = attrib_spec->store;
-
- /* up reference this block */
- attrib->block = blk;
- /* bump the attrib_spec */
- attrib_spec++;
+ /* populate the unique per attrib
+* with the code pointers and info
+*/
+
[PATCH 3/6] drivers edac new i82975x driver
From: Ranganathan Desikan <[EMAIL PROTECTED]> New EDAC driver for the i82975x memory controller chipset Used on ASUS motherboards Signed-off-by: [EMAIL PROTECTED] Signed-off-by: Ranganathan Desikan <[EMAIL PROTECTED]> Signed-off-by: Doug Thompson <[EMAIL PROTECTED]> --- Kconfig|7 Makefile |1 i82975x_edac.c | 667 + 3 files changed, 675 insertions(+) Index: linux-2.6.22-rc6-mm1/drivers/edac/i82975x_edac.c === --- /dev/null +++ linux-2.6.22-rc6-mm1/drivers/edac/i82975x_edac.c @@ -0,0 +1,667 @@ +/* + * Intel 82975X Memory Controller kernel module + * (C) 2007 aCarLab (India) Pvt. Ltd. (http://acarlab.com) + * (C) 2007 jetzbroadband (http://jetzbroadband.com) + * This file may be distributed under the terms of the + * GNU General Public License. + * + * Written by Arvind R. + * Copied from i82875p_edac.c source: + */ + +#include +#include +#include +#include +#include + +#include "edac_core.h" + +#define I82975X_REVISION " Ver: 1.0.0 " __DATE__ +#define EDAC_MOD_STR "i82975x_edac" + +#define i82975x_printk(level, fmt, arg...) \ + edac_printk(level, "i82975x", fmt, ##arg) + +#define i82975x_mc_printk(mci, level, fmt, arg...) \ + edac_mc_chipset_printk(mci, level, "i82975x", fmt, ##arg) + +#ifndef PCI_DEVICE_ID_INTEL_82975_0 +#define PCI_DEVICE_ID_INTEL_82975_00x277c +#endif /* PCI_DEVICE_ID_INTEL_82975_0 */ + +#define I82975X_NR_CSROWS(nr_chans)(8/(nr_chans)) + +/* Intel 82975X register addresses - device 0 function 0 - DRAM Controller */ +#define I82975X_EAP0x58/* Dram Error Address Pointer (32b) +* +* 31:7 128 byte cache-line address +* 6:1 reserved +* 0 0: CH0; 1: CH1 +*/ + +#define I82975X_DERRSYN0x5c/* Dram Error SYNdrome (8b) +* +* 7:0 DRAM ECC Syndrome +*/ + +#define I82975X_DES0x5d/* Dram ERRor DeSTination (8b) +* 0h:Processor Memory Reads +* 1h:7h reserved +* More - See Page 65 of Intel DocSheet. +*/ + +#define I82975X_ERRSTS 0xc8/* Error Status Register (16b) +* +* 15:12 reserved +* 11Thermal Sensor Event +* 10reserved +* 9non-DRAM lock error (ndlock) +* 8Refresh Timeout +* 7:2 reserved +* 1ECC UE (multibit DRAM error) +* 0ECC CE (singlebit DRAM error) +*/ + +/* Error Reporting is supported by 3 mechanisms: + 1. DMI SERR generation ( ERRCMD ) + 2. SMI DMI generation ( SMICMD ) + 3. SCI DMI generation ( SCICMD ) +NOTE: Only ONE of the three must be enabled +*/ +#define I82975X_ERRCMD 0xca/* Error Command (16b) +* +* 15:12 reserved +* 11Thermal Sensor Event +* 10reserved +* 9non-DRAM lock error (ndlock) +* 8Refresh Timeout +* 7:2 reserved +* 1ECC UE (multibit DRAM error) +* 0ECC CE (singlebit DRAM error) +*/ + +#define I82975X_SMICMD 0xcc/* Error Command (16b) +* +* 15:2 reserved +* 1ECC UE (multibit DRAM error) +* 0ECC CE (singlebit DRAM error) +*/ + +#define I82975X_SCICMD 0xce/* Error Command (16b) +* +* 15:2 reserved +* 1ECC UE (multibit DRAM error) +* 0ECC CE (singlebit DRAM error) +*/ + +#define I82975X_XEAP 0xfc/*
[PATCH 4/6] drivers edac add to maintainers new info
From: Douglas Thompson <[EMAIL PROTECTED]> Update maintainer information on edac components Signed-off-by: Doug Thompson <[EMAIL PROTECTED]> --- MAINTAINERS | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) Index: linux-2.6.22-rc6-mm1/MAINTAINERS === --- linux-2.6.22-rc6-mm1.orig/MAINTAINERS +++ linux-2.6.22-rc6-mm1/MAINTAINERS @@ -1352,21 +1352,23 @@ S: Supported EDAC-CORE P: Doug Thompson -M: [EMAIL PROTECTED] +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: bluesmoke.sourceforge.net S: Supported EDAC-E752X P: Mark Gross +P: Doug Thompson M: [EMAIL PROTECTED] +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: bluesmoke.sourceforge.net S: Maintained EDAC-E7XXX P: Doug Thompson -M: [EMAIL PROTECTED] +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: bluesmoke.sourceforge.net S: Maintained @@ -1387,7 +1389,23 @@ S: Maintained EDAC-I5000 P: Doug Thompson -M: [EMAIL PROTECTED] +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: bluesmoke.sourceforge.net +S: Maintained + +EDAC-I82975X +P: Ranganathan Desikan +P: Arvind R. +M: [EMAIL PROTECTED] +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: bluesmoke.sourceforge.net +S: Maintained + +EDAC-PASEMI +P: Egor Martovetsky +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: bluesmoke.sourceforge.net S: Maintained - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] drivers edac fix workq reset deadlock
From: Doug Thompson <[EMAIL PROTECTED]>
Fix mutex locking deadlock on the device controller linked list.
Was calling a lock then a function that could call the same lock.
Moved the cancel workq function to outside the lock
Added some short circuit logic in the workq code
Added comments of description
Code tidying
Signed-off-by: Doug Thompson <[EMAIL PROTECTED]>
---
Index: linux-2.6.22-rc6-mm1/drivers/edac/edac_device.c
===
--- linux-2.6.22-rc6-mm1.orig/drivers/edac/edac_device.c
+++ linux-2.6.22-rc6-mm1/drivers/edac/edac_device.c
@@ -32,7 +32,9 @@
#include "edac_core.h"
#include "edac_module.h"
-/* lock to memory controller's control array 'edac_device_list' */
+/* lock for the list: 'edac_device_list', manipulation of this list
+ * is protected by the 'device_ctls_mutex' lock
+ */
static DEFINE_MUTEX(device_ctls_mutex);
static struct list_head edac_device_list = LIST_HEAD_INIT(edac_device_list);
@@ -386,6 +388,14 @@ EXPORT_SYMBOL_GPL(edac_device_find);
/*
* edac_device_workq_function
* performs the operation scheduled by a workq request
+ *
+ * this workq is embedded within an edac_device_ctl_info
+ * structure, that needs to be polled for possible error events.
+ *
+ * This operation is to acquire the list mutex lock
+ * (thus preventing insertation or deletion)
+ * and then call the device's poll function IFF this device is
+ * running polled and there is a poll function defined.
*/
static void edac_device_workq_function(struct work_struct *work_req)
{
@@ -403,8 +413,17 @@ static void edac_device_workq_function(s
mutex_unlock(_ctls_mutex);
- /* Reschedule */
- queue_delayed_work(edac_workqueue, _dev->work, edac_dev->delay);
+ /* Reschedule the workq for the next time period to start again
+* if the number of msec is for 1 sec, then adjust to the next
+* whole one second to save timers fireing all over the period
+* between integral seconds
+*/
+ if (edac_dev->poll_msec == 1000)
+ queue_delayed_work(edac_workqueue, _dev->work,
+ round_jiffies(edac_dev->delay));
+ else
+ queue_delayed_work(edac_workqueue, _dev->work,
+ edac_dev->delay);
}
/*
@@ -417,11 +436,26 @@ void edac_device_workq_setup(struct edac
{
debugf0("%s()\n", __func__);
+ /* take the arg 'msec' and set it into the control structure
+* to used in the time period calculation
+* then calc the number of jiffies that represents
+*/
edac_dev->poll_msec = msec;
- edac_dev->delay = msecs_to_jiffies(msec); /* Calc delay jiffies */
+ edac_dev->delay = msecs_to_jiffies(msec);
INIT_DELAYED_WORK(_dev->work, edac_device_workq_function);
- queue_delayed_work(edac_workqueue, _dev->work, edac_dev->delay);
+
+ /* optimize here for the 1 second case, which will be normal value, to
+* fire ON the 1 second time event. This helps reduce all sorts of
+* timers firing on sub-second basis, while they are happy
+* to fire together on the 1 second exactly
+*/
+ if (edac_dev->poll_msec == 1000)
+ queue_delayed_work(edac_workqueue, _dev->work,
+ round_jiffies(edac_dev->delay));
+ else
+ queue_delayed_work(edac_workqueue, _dev->work,
+ edac_dev->delay);
}
/*
@@ -441,16 +475,20 @@ void edac_device_workq_teardown(struct e
/*
* edac_device_reset_delay_period
+ *
+ * need to stop any outstanding workq queued up at this time
+ * because we will be resetting the sleep time.
+ * Then restart the workq on the new delay
*/
-
void edac_device_reset_delay_period(struct edac_device_ctl_info *edac_dev,
unsigned long value)
{
- mutex_lock(_ctls_mutex);
-
- /* cancel the current workq request */
+ /* cancel the current workq request, without the mutex lock */
edac_device_workq_teardown(edac_dev);
+ /* acquire the mutex before doing the workq setup */
+ mutex_lock(_ctls_mutex);
+
/* restart the workq request, with new delay value */
edac_device_workq_setup(edac_dev, value);
Index: linux-2.6.22-rc6-mm1/drivers/edac/edac_mc.c
===
--- linux-2.6.22-rc6-mm1.orig/drivers/edac/edac_mc.c
+++ linux-2.6.22-rc6-mm1/drivers/edac/edac_mc.c
@@ -258,6 +258,12 @@ static void edac_mc_workq_function(struc
mutex_lock(_ctls_mutex);
+ /* if this control struct has movd to offline state, we are done */
+ if (mci->op_state == OP_OFFLINE) {
+ mutex_unlock(_ctls_mutex);
+ return;
+ }
+
/* Only poll controllers that are running polled and have a check */
if
[PATCH 0/6] drivers edac tidying-fix-deadlock-sysfs-docs
From: Doug Thompson <[EMAIL PROTECTED]> This EDAC patch set was applied against: 2.6.22-rc6-mm1 6 Patches in this set 1) tidying EXPORT_SYMBOL to EXPORT_SYMBOL_GPL modes, plus blank line removal 2) workq reset deadlock fix. Moved teardown outside of critical section 3) new i82975x driver for ASUS motherboards submitted. 4) EDAC MAINTAINERs updated for new entries, etc 5) found an old internal EDAC structure that was incorrect in the processing of block leaf attributes. Amazing it hadn't faulted, just gave bad data. Removed that, and replaced with the correct structure from edac_core.h Then refactored code to utilize this structure. Error occurred in leaf control/attribute presentation to user 6) Enhanced the EDAC documentation to reflect updated status of EDAC including the 'edac_device' class of device, which supports non-memory type of ECC hardware detectors. Signed-off-by: Doug Thompson <[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 1/6] drivers edac code tidying on export-gpl
From: Doug Thompson <[EMAIL PROTECTED]>
Change EXPORT_SYMBOLs to EXPORT_SYMBOLS_GPL
Tidy changes: blank lines, inline removal, add comment
Signed-off-by: Doug Thompson <[EMAIL PROTECTED]>
---
Index: linux-2.6.22-rc6-mm1/drivers/edac/edac_stub.c
===
--- linux-2.6.22-rc6-mm1.orig/drivers/edac/edac_stub.c
+++ linux-2.6.22-rc6-mm1/drivers/edac/edac_stub.c
@@ -15,30 +15,32 @@
#include
int edac_op_state = EDAC_OPSTATE_INVAL;
-EXPORT_SYMBOL(edac_op_state);
+EXPORT_SYMBOL_GPL(edac_op_state);
atomic_t edac_handlers = ATOMIC_INIT(0);
-EXPORT_SYMBOL(edac_handlers);
+EXPORT_SYMBOL_GPL(edac_handlers);
int edac_err_assert = 0;
-EXPORT_SYMBOL(edac_err_assert);
+EXPORT_SYMBOL_GPL(edac_err_assert);
-inline int edac_handler_set(void)
+/*
+ * called to determine if there is an EDAC driver interested in
+ * knowing an event (such as NMI) occurred
+ */
+int edac_handler_set(void)
{
if (edac_op_state == EDAC_OPSTATE_POLL)
return 0;
return atomic_read(_handlers);
}
-
-EXPORT_SYMBOL(edac_handler_set);
+EXPORT_SYMBOL_GPL(edac_handler_set);
/*
* handler for NMI type of interrupts to assert error
*/
-inline void edac_atomic_assert_error(void)
+void edac_atomic_assert_error(void)
{
edac_err_assert++;
}
-
-EXPORT_SYMBOL(edac_atomic_assert_error);
+EXPORT_SYMBOL_GPL(edac_atomic_assert_error);
Index: linux-2.6.22-rc6-mm1/drivers/edac/edac_module.c
===
--- linux-2.6.22-rc6-mm1.orig/drivers/edac/edac_module.c
+++ linux-2.6.22-rc6-mm1/drivers/edac/edac_module.c
@@ -1,12 +1,13 @@
/*
* edac_module.c
*
- * (C) 2007 www.douglaskthompson.com
+ * (C) 2007 www.softwarebitmaker.com
+ *
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without any
* warranty of any kind, whether express or implied.
*
- * Author: Doug Thompson <[EMAIL PROTECTED]>
+ * Author: Doug Thompson <[EMAIL PROTECTED]>
*
*/
#include
@@ -14,7 +15,7 @@
#include "edac_core.h"
#include "edac_module.h"
-#define EDAC_MC_VERSION "Ver: 2.0.5 " __DATE__
+#define EDAC_VERSION "Ver: 2.1.0 " __DATE__
#ifdef CONFIG_EDAC_DEBUG
/* Values of 0 to 4 will generate output */
@@ -141,7 +142,7 @@ static int __init edac_init(void)
{
int err = 0;
- edac_printk(KERN_INFO, EDAC_MC, EDAC_MC_VERSION "\n");
+ edac_printk(KERN_INFO, EDAC_MC, EDAC_VERSION "\n");
/*
* Harvest and clear any boot/initialization PCI parity errors
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] smp_call_function_single() should be a macro on UP
On Tue, Jul 17, 2007 at 02:40:42PM -0700, David Miller wrote: > From: Al Viro <[EMAIL PROTECTED]> > Date: Tue, 17 Jul 2007 22:29:46 +0100 > > > ... or we end up with header include order problems from hell. > > E.g. on m68k this is 100% fatal - local_irq_enable() there > > wants preempt_count(), which wants task_struct fields, which > > we won't have when we are in smp.h pulled from sched.h. > > > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > > Acked-by: David S. Miller <[EMAIL PROTECTED]> > > I was going to fix the sparc64/UP build fallout by > adding linux/kernel.h include to linux/smp.h but that > definitely would not handle this m68k case at all. This has broken _all_ ARM builds, due to using WARN_ON() in this header. Warn on needs and this is needs to make it compile cleanly on ARM which is unfortuantely what we where trying to avoid in the first place? This patch fixes the compile on ARM, but moves the includes out of the CONFIG_SMP block. diff -urpN -X linux-2.6.22-git9/Documentation/dontdiff linux-2.6.22-git9/include/linux/smp.h linux-2.6.22-git9-fix1/include/linux/smp.h --- linux-2.6.22-git9/include/linux/smp.h 2007-07-18 00:40:45.0 +0100 +++ linux-2.6.22-git9-fix1/include/linux/smp.h 2007-07-18 00:43:24.0 +0100 @@ -7,15 +7,17 @@ */ #include +#include +#include + #include +#include extern void cpu_idle(void); #ifdef CONFIG_SMP #include -#include -#include #include #include -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a52b1752c07 broke !SMP: error: implicit declaration of function `WARN_ON'
On Wed, Jul 18, 2007 at 01:24:46AM +0200, Uwe Kleine-K?nig wrote: > Hello, > > kernel/timer.c (and some others as arch/arm/kernel/irq.c) include > , but not > > a52b1752c07 introduces usage of the WARN_ON macro in , but > doesn't pull in . ( is not enough, at least > for arm, because WARN_ON uses printk there.) > > The obvious options are: > > 1) include in , maybe conditioned by !SMP > 2) include in all includers of > 3) remove the WARN_ONs introduced by a52b1752c07. > > WARN_ON is used in an inline function that isn't used in every file > including , so maybe updating the compiler might make > the effort for 2) smaller!? (I'm using gcc 3.4.4) 4) turn the sucker into macro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.21.5-rt19 (sched_getaffinity?)
On Tue, 2007-07-17 at 22:12 +0200, Ingo Molnar wrote: > * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > > > On Tue, 2007-07-17 at 21:32 +0200, Ingo Molnar wrote: > > > * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > > > > > > > I do get flash 9 (I know, not the best example) and tomboy to hang as > > > > reported by one of my Planet CCRMA users - flash 9 tested working on > > > > stock fedora 7 kernel - and both seem to hang in the same system call: > > > > > > > > sched_getaffinity(3528, 32, > > > > > > > > Full output of strace attached for both cases. > > > > > > hm, that's weird. Is it completely unkillable at that time? Could you do > > > a few things: enable CONFIG_PROVE_LOCKING (lockdep), and also try to get > > > a full task state dump via: > > > > > > echo t > /proc/sysrq-trigger > > > > Trace attached... the process stays in D state no matter what. > > hm, seems to be related to: > > Jul 17 12:51:18 localhost kernel: sched-powersa D [f0aaf930] 0005 6584 > 3420 3407 > > which blocks the cpu-hotplug mutex: > > Jul 17 12:51:18 localhost kernel: Call Trace: > Jul 17 12:51:18 localhost kernel: [] schedule+0xe0/0xfa > Jul 17 12:51:18 localhost kernel: [] rt_mutex_slowlock+0x164/0x20b > Jul 17 12:51:18 localhost kernel: [] rt_mutex_lock+0x3c/0x3f > Jul 17 12:51:18 localhost kernel: [] sched_getaffinity+0x14/0x94 > Jul 17 12:51:18 localhost kernel: [] __synchronize_sched+0xd/0x5a > Jul 17 12:51:18 localhost kernel: [] > arch_reinit_sched_domains+0x18/0x33 > Jul 17 12:51:18 localhost kernel: [] > sched_power_savings_store+0x3c/0x49 > Jul 17 12:51:18 localhost kernel: [] sysdev_class_store+0x1e/0x22 > Jul 17 12:51:18 localhost kernel: [] sysfs_write_file+0xa3/0xc6 > Jul 17 12:51:18 localhost kernel: [] vfs_write+0xa8/0x154 > Jul 17 12:51:18 localhost kernel: [] sys_write+0x41/0x67 > Jul 17 12:51:18 localhost kernel: [] syscall_call+0x7/0xb > > and firefox blocks on the same mutex too: > > Jul 17 12:51:18 localhost kernel: firefox-bin D [efc44670] 0012 6368 > 4388 1 > Jul 17 12:51:18 localhost kernel: Call Trace: > Jul 17 12:51:18 localhost kernel: [] schedule+0xe0/0xfa > Jul 17 12:51:18 localhost kernel: [] rt_mutex_slowlock+0x164/0x20b > Jul 17 12:51:18 localhost kernel: [] rt_mutex_lock+0x3c/0x3f > Jul 17 12:51:18 localhost kernel: [] sched_getaffinity+0x14/0x94 > Jul 17 12:51:18 localhost kernel: [] > sys_sched_getaffinity+0x1f/0x41 > Jul 17 12:51:18 localhost kernel: [] syscall_call+0x7/0xb > Jul 17 12:51:18 localhost kernel: [] 0xb7f0f410 > > does lockdep pinpoint anything? Lots of stuff, and at the end the lock report for the problem. Hopefully some of this will help... I have attached the whole bootup sequence as logged in /var/log/messages. -- Fernando trace3.txt.gz Description: GNU Zip compressed data
[PATCH 2/2] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel
From: Paul Moore <[EMAIL PROTECTED]>
These changes will make NetLabel behave like labeled IPsec where there is
an access check for both labeled and unlabeled packets as well as
providing the ability to restrict domains to receiving only labeled
packets when NetLabel is in use. The changes to the policy are straight
forward with the following necessary to receive labeled traffic (with
SECINITSID_NETMSG defined as "netlabel_peer_t"):
allow mydom_t netlabel_peer_t:{ tcp_socket udp_socket rawip_socket } recvfrom;
The policy for unlabeled traffic would be:
allow mydom_t unlabeled_t:{ tcp_socket udp_socket rawip_socket } recvfrom;
These policy changes, as well as more general NetLabel support, are
included in the latest SELinux Reference Policy release 20070629 or later.
Users who make use of NetLabel are strongly encouraged to upgrade their
policy to avoid network problems.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
Signed-off-by: James Morris <[EMAIL PROTECTED]>
---
security/selinux/hooks.c| 21 +++--
security/selinux/netlabel.c | 41 -
2 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 78c3f98..aff8f46 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3129,17 +3129,19 @@ static int selinux_parse_skb(struct sk_buff *skb,
struct avc_audit_data *ad,
/**
* selinux_skb_extlbl_sid - Determine the external label of a packet
* @skb: the packet
- * @base_sid: the SELinux SID to use as a context for MLS only external labels
* @sid: the packet's SID
*
* Description:
* Check the various different forms of external packet labeling and determine
- * the external SID for the packet.
+ * the external SID for the packet. If only one form of external labeling is
+ * present then it is used, if both labeled IPsec and NetLabel labels are
+ * present then the SELinux type information is taken from the labeled IPsec
+ * SA and the MLS sensitivity label information is taken from the NetLabel
+ * security attributes. This bit of "magic" is done in the call to
+ * selinux_netlbl_skbuff_getsid().
*
*/
-static void selinux_skb_extlbl_sid(struct sk_buff *skb,
- u32 base_sid,
- u32 *sid)
+static void selinux_skb_extlbl_sid(struct sk_buff *skb, u32 *sid)
{
u32 xfrm_sid;
u32 nlbl_sid;
@@ -3147,10 +3149,9 @@ static void selinux_skb_extlbl_sid(struct sk_buff *skb,
selinux_skb_xfrm_sid(skb, _sid);
if (selinux_netlbl_skbuff_getsid(skb,
(xfrm_sid == SECSID_NULL ?
- base_sid : xfrm_sid),
+ SECINITSID_NETMSG : xfrm_sid),
_sid) != 0)
nlbl_sid = SECSID_NULL;
-
*sid = (nlbl_sid == SECSID_NULL ? xfrm_sid : nlbl_sid);
}
@@ -3695,7 +3696,7 @@ static int selinux_socket_getpeersec_dgram(struct socket
*sock, struct sk_buff *
if (sock && sock->sk->sk_family == PF_UNIX)
selinux_get_inode_sid(SOCK_INODE(sock), _secid);
else if (skb)
- selinux_skb_extlbl_sid(skb, SECINITSID_UNLABELED, _secid);
+ selinux_skb_extlbl_sid(skb, _secid);
if (peer_secid == SECSID_NULL)
err = -EINVAL;
@@ -3756,7 +3757,7 @@ static int selinux_inet_conn_request(struct sock *sk,
struct sk_buff *skb,
u32 newsid;
u32 peersid;
- selinux_skb_extlbl_sid(skb, SECINITSID_UNLABELED, );
+ selinux_skb_extlbl_sid(skb, );
if (peersid == SECSID_NULL) {
req->secid = sksec->sid;
req->peer_secid = SECSID_NULL;
@@ -3794,7 +3795,7 @@ static void selinux_inet_conn_established(struct sock *sk,
{
struct sk_security_struct *sksec = sk->sk_security;
- selinux_skb_extlbl_sid(skb, SECINITSID_UNLABELED, >peer_sid);
+ selinux_skb_extlbl_sid(skb, >peer_sid);
}
static void selinux_req_classify_flow(const struct request_sock *req,
diff --git a/security/selinux/netlabel.c b/security/selinux/netlabel.c
index ed9155b..051b14c 100644
--- a/security/selinux/netlabel.c
+++ b/security/selinux/netlabel.c
@@ -163,9 +163,7 @@ int selinux_netlbl_skbuff_getsid(struct sk_buff *skb, u32
base_sid, u32 *sid)
netlbl_secattr_init();
rc = netlbl_skbuff_getattr(skb, );
if (rc == 0 && secattr.flags != NETLBL_SECATTR_NONE)
- rc = security_netlbl_secattr_to_sid(,
- base_sid,
- sid);
+ rc = security_netlbl_secattr_to_sid(, base_sid, sid);
else
*sid = SECSID_NULL;
netlbl_secattr_destroy();
@@ -203,7 +201,7 @@ void selinux_netlbl_sock_graft(struct sock *sk, struct
socket *sock)
if
[PATCH 1/2] SELinux: enable dynamic activation/deactivation of NetLabel/SELinux enforcement
From: Paul Moore <[EMAIL PROTECTED]>
Create a new NetLabel KAPI interface, netlbl_enabled(), which reports on
the current runtime status of NetLabel based on the existing
configuration. LSMs that make use of NetLabel, i.e. SELinux, can use this
new function to determine if they should perform NetLabel access checks.
This patch changes the NetLabel/SELinux glue code such that SELinux only
enforces NetLabel related access checks when netlbl_enabled() returns
true.
At present NetLabel is considered to be enabled when there is at least one
labeled protocol configuration present. The result is that by default
NetLabel is considered to be disabled, however, as soon as an
administrator configured a CIPSO DOI definition NetLabel is enabled and
SELinux starts enforcing NetLabel related access controls - including
unlabeled packet controls.
This patch should resolve the issue reported by Michal Piotrowski here:
* http://lkml.org/lkml/2007/7/12/362
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
Signed-off-by: James Morris <[EMAIL PROTECTED]>
---
include/net/netlabel.h |6 +++
net/netlabel/netlabel_cipso_v4.c |5 +++
net/netlabel/netlabel_kapi.c | 21
net/netlabel/netlabel_mgmt.c | 65 ++
net/netlabel/netlabel_mgmt.h |5 +++
security/selinux/netlabel.c |8 +
6 files changed, 110 insertions(+), 0 deletions(-)
diff --git a/include/net/netlabel.h b/include/net/netlabel.h
index 9b7d6f2..5d2bcad 100644
--- a/include/net/netlabel.h
+++ b/include/net/netlabel.h
@@ -332,6 +332,7 @@ static inline int netlbl_secattr_catmap_setrng(
*/
#ifdef CONFIG_NETLABEL
+int netlbl_enabled(void);
int netlbl_sock_setattr(struct sock *sk,
const struct netlbl_lsm_secattr *secattr);
int netlbl_sock_getattr(struct sock *sk,
@@ -340,6 +341,11 @@ int netlbl_skbuff_getattr(const struct sk_buff *skb,
struct netlbl_lsm_secattr *secattr);
void netlbl_skbuff_err(struct sk_buff *skb, int error);
#else
+int netlbl_enabled(void)
+{
+ return 0;
+}
+
static inline int netlbl_sock_setattr(struct sock *sk,
const struct netlbl_lsm_secattr *secattr)
{
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index 24b660f..c060e3f 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -41,6 +41,7 @@
#include "netlabel_user.h"
#include "netlabel_cipso_v4.h"
+#include "netlabel_mgmt.h"
/* Argument struct for cipso_v4_doi_walk() */
struct netlbl_cipsov4_doiwalk_arg {
@@ -419,6 +420,8 @@ static int netlbl_cipsov4_add(struct sk_buff *skb, struct
genl_info *info)
ret_val = netlbl_cipsov4_add_pass(info);
break;
}
+ if (ret_val == 0)
+ netlbl_mgmt_protocount_inc();
audit_buf = netlbl_audit_start_common(AUDIT_MAC_CIPSOV4_ADD,
_info);
@@ -694,6 +697,8 @@ static int netlbl_cipsov4_remove(struct sk_buff *skb,
struct genl_info *info)
ret_val = cipso_v4_doi_remove(doi,
_info,
netlbl_cipsov4_doi_free);
+ if (ret_val == 0)
+ netlbl_mgmt_protocount_dec();
audit_buf = netlbl_audit_start_common(AUDIT_MAC_CIPSOV4_DEL,
_info);
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index b165712..50195e2 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -38,6 +38,7 @@
#include "netlabel_domainhash.h"
#include "netlabel_unlabeled.h"
#include "netlabel_user.h"
+#include "netlabel_mgmt.h"
/*
* Security Attribute Functions
@@ -245,6 +246,26 @@ int netlbl_secattr_catmap_setrng(struct
netlbl_lsm_secattr_catmap *catmap,
*/
/**
+ * netlbl_enabled - Determine if the NetLabel subsystem is enabled
+ *
+ * Description:
+ * The LSM can use this function to determine if it should use NetLabel
+ * security attributes in it's enforcement mechanism. Currently, NetLabel is
+ * considered to be enabled when it's configuration contains a valid setup for
+ * at least one labeled protocol (i.e. NetLabel can understand incoming
+ * labeled packets of at least one type); otherwise NetLabel is considered to
+ * be disabled.
+ *
+ */
+int netlbl_enabled(void)
+{
+ /* At some point we probably want to expose this mechanism to the
+* user as well so that admins can toggle NetLabel regardless of
+* the configuration */
+ return (netlbl_mgmt_protocount_value() > 0 ? 1 : 0);
+}
+
+/**
* netlbl_socket_setattr - Label a socket using the correct protocol
* @sk: the socket to label
* @secattr: the security attributes
diff --git a/net/netlabel/netlabel_mgmt.c b/net/netlabel/netlabel_mgmt.c
index e00fc21..5315dac 100644
--- a/net/netlabel/netlabel_mgmt.c
+++
[PATCH 0/2] SELinux Netlabel updates
Hi Linus, These are updated Netlabel/SELinux changes from Paul, reworked so that they don't break userspace. Michal says they work for him. Please apply for 2.6.23. The following changes since commit 489de30259e667d7bc47da9da44a0270b050cd97: Linus Torvalds (1): Merge branch 'merge' of git://git.kernel.org/.../paulus/powerpc are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-linus Paul Moore (2): SELinux: enable dynamic activation/deactivation of NetLabel/SELinux enforcement SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel include/net/netlabel.h |6 +++ net/netlabel/netlabel_cipso_v4.c |5 +++ net/netlabel/netlabel_kapi.c | 21 net/netlabel/netlabel_mgmt.c | 65 ++ net/netlabel/netlabel_mgmt.h |5 +++ security/selinux/hooks.c | 21 ++-- security/selinux/netlabel.c | 49 7 files changed, 141 insertions(+), 31 deletions(-) -- James Morris <[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][RFC] 4K stacks default, not a debug thing any more...?
On Tue, 2007-07-17 at 10:45 -0400, John Stoffel wrote: > utz> I have to recompile the fedora kernel rpms (fc6, f7) with 8k > utz> stacks on my i686 server. It's using NFS -> XFS -> DM -> MD > utz> (raid1) -> IDE disks. With 4k stacks it crash (hang) within > utz> minutes after using NFS. With 8k stacks it's rock solid. No > utz> crashes within months. > > Does it give any useful information when it does crash? > No, sorry. Nearly always it lock up so hard that even sysrq didn't work anymore. Most times the console was blanked. If not, there was a line with "do_irq" or something like that (if i remember correctly). A few times it continuous oopsing (scrolling like mad). I think it's just a stack overflow. Knowing that XFS + long IO stack have problems with 4k stacks. And i have zero crashes with the recompiled 8k stack kernels. (All kernel are the fedora ones). Btw: In the past the server runs on slightly different hardware and without raid1 (NFS -> XFS -> DM -> IDE disk). It runs with 4k stacks. I had a few crashes, but i blame the hardware for it. I don't want to make tests with the server. It's my main data storage and i don't want to risk it. > Can you make > a simple test case using ram disks instead of IDE disks and then > building upon that? Sorry, i don't think i can do this. My other computer, which i can use for tests, is x86_64 based. And IFAIK the problem on the XFS side has something to do with looking for freespace on many AGs. So maybe a bigger and filled filesystem is needed. And 50GB ram disks are out of question. utz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 37/44] xen: add virtual network device driver
On Tue, 2007-07-17 at 07:28 -0700, Jeremy Fitzhardinge wrote:
> Stephen Hemminger wrote:
> >> +struct netfront_info {
> >> + struct list_head list;
> >> + struct net_device *netdev;
> >> +
> >> + struct net_device_stats stats;
> >>
> >
> > There is now a net_device_stats element inside net_device on
> > 2.6.21 or later.
> >
>
> Ah, OK. Should I just do a s/stats/netdev->stats/? Is there a generic
> get_stats routine as well?
The default function points to the internal stats...
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation of kernel messages (Summary)
On Tue, 17 Jul 2007 12:06:56 -0400, rob wrote: > On Sunday 15 July 2007 12:46:42 pm Tsugikazu Shibata wrote: > > On Sat, 14 Jul 2007 22:12:35 -0400, rob wrote: > > > On Friday 13 July 2007 9:46:59 pm Tsugikazu Shibata wrote: > > > > > > How about adding; > > > > > > kernel-doc-nano-HOWTO.txt > > > > > > > > > > The problem is, the generated htmdocs are in english. This file is > > > > > about how to generate (and author) English documentation that won't > > > > > be translated. What's the point of translating the instructions if > > > > > the result won't be translated? > > > > > > > > People (who even in non-native) would better to know and read it such > > > > htmldocs because there are good and important documents even in > > > > English. I thought that translation of this file may help. > > > > > > The english version of htmldocs is generated from the source code.If > > > translating remotely current versions of htmldocs into other languages > > > was feasible, then the english version wouldn't need to be in the source > > > code in the first place. > > > > > > Translating a document _about_ htmldocs boils down to "Dear non-english > > > speaker: here's something you can't read, nor can you update it either > > > except though your language maintainer." > > > > No, kernel-doc-nano-HOWTO includes explanation of tools to extract the > > document, format of extractable document in source files and so on. > > I thought this file would help non-native people, how to extract or add > > in-kernel extractable documents. > > Which will be in english, so why can't the instructions on how to do it be in > english too? > > > I understand that these tools will generate English documents but > > that's OK. > > Then the instructions how to do it in english should be ok too. If they > can't > read the instructions, they won't be able to read the result. It seems my explanation was not enough. We (like me, usually not using English) can read English but it takes more time than you (and any natives). So, reading large document takes huge amount of time. In case of htmldocs, it is actually large and developer may give up before start. I thought that if some part (like how to do it) are translated into his/her familiar language, he/she may not give it up. Yes, it may not be. Another viewpoint is that if he/she need to modify some interface and it may need to change some part of extractable document, this file includes, "How to add extractable documentation to your source files". It will be some help as well. Yes, He/she should write English and it may take long time but hopefully the translation result would push his/her back. > > Such large volume of documents are not easy to translate > > into other languages. > > "Here's how to get a result that will be useless to you." > > Why? What's the point? I'm not seeing it. > > Rob > -- > "One of my most productive days was throwing away 1000 lines of code." > - Ken Thompson. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [GIT PULL][RESEND #2] KVM Updates for 2.6.23-rc1
Hi; 18 Tem 2007 Çar tarihinde, Anthony Liguori şunları yazmıştı: > Can you reproduce without the appArmor patchset? Tomorrow i'll also try with vanilla one but just for records same patchset worked without a problem until latest kvm merge :) Cheers -- S.Çağlar Onur <[EMAIL PROTECTED]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! signature.asc Description: This is a digitally signed message part.
Re: [kvm-devel] [GIT PULL][RESEND #2] KVM Updates for 2.6.23-rc1
S.Çağlar Onur wrote: Hi; 17 Tem 2007 Sal tarihinde, Avi Kivity şunları yazmıştı: I fixed the issue with the previous patchset. Please provide further feedback, or pull from: git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git for-linus This contains kvm updates for the 2.6.23 merge window, including After that commit (+appArmor patchset) any guest image hangs the system completely as soon as started with kvm-29 userspace. Guest images works with "qemu-kvm -hda X.img -m 512 -no-kvm" works as expected Can you reproduce without the appArmor patchset? Regards, Anthony Liguori I cannot provide any more information for now causes system freezes at all and netconsole not works with ipw3945 (netconsole: eth1 doesn't support polling, aborting) but tomorrow i'll try with cable. If needed you can find .config and dmesg from [1], if anything else needed please just say it... [1] http://cekirdek.pardus.org.tr/~caglar/kvm/ Cheers - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kvm-devel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
On 17/07/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote: At some point in the past, I wrote: >> If at some point one of the pro-4k stacks crowd can prove that all >> code paths are safe, or introduce another viable alternative (such as >> Matt's idea for extending the stack dynamically), then removing the 8k >> stacks option makes sense. On Mon, Jul 16, 2007 at 11:54:38PM +0100, Alan Cox wrote: > Any x86-32 path unsafe with 4K stacks is almost certainly unsafe with 8K > stacks because the 8K stacks do not have seperate IRQ stack paths, so you > have the same space but split. It might be less predictable on 8K stacks > but it isn't absent. At hch's suggestion I rewrote the separate IRQ stack configurability patch into one making IRQ stacks mandatory and unconfigurable, and hence enabled with 8K stacks. For what it's worth, that sounds good to me - like something that we would want merged. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block/bsg.c
James Bottomley wrote:
@@ -1052,9 +1054,10 @@ int generic_ide_ioctl(ide_drive_t *drive, struct file
*file, struct block_device
int err, (*setfunc)(ide_drive_t *, int);
u8 *val;
- err = scsi_cmd_ioctl(file, bdev->bd_disk->queue, bdev->bd_disk, cmd, p);
- if (err != -ENOTTY)
- return err;
+ switch (cmd) {
+ case SG_IO:
+ return scsi_cmd_ioctl(file, bdev->bd_disk->queue,
bdev->bd_disk, cmd, p);
+ }
switch (cmd) {
case HDIO_GET_32BIT:val = >io_32bit; goto read_val;
At that point you might as well use an 'if'.
But overall -- agreed. ACK.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
> 1) It all can be reduced to 4K + 4K by asuming all IRQ happen on one CPU. no it's separate stacks for soft and hard irqs, so it's really 4+4+4 another angle is that while correctness rules, userspace correctness rules as well. If you can't fork enough threads for what you need the machine for, why have the machine in the first place? -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.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: [PATCH] Use tty_schedule in VT code.
O> In that case, we might as well just always do the scheduled_delayed_work() > with a zero timeout as per the earlier patch. I'd still like to know who > *cares*, though? Why not leave it at 1? I don't think it really matters too much on modern systems so long as we keep the flush_to_ldisc out of IRQ context. Historically we tried to batch the ldisc processing but I doubt any modern box cares too much - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] change SysRq keycode for systems without SysRq key
Andrew Morton ha scritto:
> Seems harmless enough ;)
>
> Could you please send in a suitable update to Documentation/sysrq.txt?
sorry, I should have written a few lines here...
issue solved (sorry for not CCing here, I'm shy ((: ) resulting in no
need for a patch, just the need of a recent kernel and a userspace program.
I report here the full discussion I had with Linus Torvalds, Dmitry
Torokhov (CCed to linux-input list):
> this patch adds an entry in Kconfig after 'config MAGIC_SYSRQ' which
> asks for a different keycode (replacing also KEY_SYSRQ with
> CONFIG_MAGIC_SYSRQ_KEYCODE in char/keyboard.c)
>
> Federico
Quite frankly, I think that if we want to make something like this
configurable, it should be dynamic, not compiled-in. So that the same
kernel image can be used with different keyboards.
Linus
>>> (I can imagine it could be done via a /proc/sysrq-keycode virtual file,
>>> but that's just one possibility)
>>>
>>> So, this should turn into a feature request...
>>> would you accept feature requests? ( :
>>>
>>> Federico
>>
>> Well, this is totally untested, and I won't guarantee that this
works at
>> all, but this is how to generally do these kinds of things..
>>
>> Linus
>>
>> ---
>> drivers/char/keyboard.c |6 +-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
>> index 90965b4..e21f52b 100644
>> --- a/drivers/char/keyboard.c
>> +++ b/drivers/char/keyboard.c
>> @@ -157,6 +157,10 @@ static int sysrq_alt_use;
>> #endif
>> static int sysrq_alt;
>>
>> +static int sysrq_key = KEY_SYSRQ;
>> +module_param_named(sysrq_key, sysrq_key, uint, 0644);
>> +MODULE_PARM_DESC(sysrq_key, "The keycode to be used for sysrq");
>> +
>> /*
>> * Translation of scancodes to keycodes. We set them on only the first
>> * keyboard in the list that accepts the scancode and keycode.
>> @@ -1139,7 +1143,7 @@ static void kbd_keycode(unsigned int keycode,
int down, int hw_raw)
>> printk(KERN_WARNING "keyboard.c: can't emulate
rawmode for keycode %d\n", keycode);
>>
>> #ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
>> -if (keycode == KEY_SYSRQ && (sysrq_down || (down == 1 &&
sysrq_alt))) {
>> +if (keycode == sysrq_key && (sysrq_down || (down == 1 &&
sysrq_alt))) {
>> if (!sysrq_down) {
>> sysrq_down = down;
>> sysrq_alt_use = sysrq_alt;
>>
>
> YAY! it works great.
> tried with:
> # echo 183 > /sys/module/keyboard/parameters/sysrq_key
> but also keyboard.sys_rq=183 on the command line should work; I'll
> discover that on next reboot.
Yes, please do verify.
> thank you, Linus!
You're welcome.
> (now that this has done in the proper way, is this patch going to be
> merged in the tree?)
I'm certainly ok with it, but I guess it's more up to Dmitry. If he ack's
it, I can just commit it.
Dmitry? Any reason not to do this?
Linus
---
On 7/17/07, federico ferri <[EMAIL PROTECTED]> wrote:
> Dmitry Torokhov ha scritto:
> >> Dmitry? Any reason not to do this?
> >>
> >
> > Recent kernels have the ability to remap keymap for USB keyboards via
> > EVIOCSKEYCODE ioctl (we allowed 0adjusting keymaps on PS/2 keyboards
> > for a long time). So instead of having the new parameter redefining
> > SysRq keycode Frederico can remap one of the keys on his keyboard to
> > generate KEY_SYSRQ. This way SysRq should still work if he plugs in
> > another USB keyboard that has SysRq key or a PS/2 keyboard.
>
> would setkeycodes still just work for PS2 keyboards?
> I upgraded to newer kbd-1.13 package (kernel 2.6.21), and while trying
> to change sysrq keycode still I get the old error:
>
> KDSETKEYCODE: No such device
> failed to set scancode 38b7 to keycode 84
>
> which I reported on gentoo a long time ago:
> http://bugs.gentoo.org/show_bug.cgi?id=97388
>
> (it doesn't use EVIOCSKEYCODE)
> maybe I'm not picking up the right program?
>
EVIOCSKEYCODE support for HID (USB) went in in 2.6.22-rc1.
There is keyfuzz utility you can use to play with keymaps for a
particular device:
http://0pointer.de/lennart/projects/keyfuzz/
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
