[-mm patch] USB: make dev_attr_authorized_default static
On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote: ... Changes since 2.6.22-rc6-mm1: ... +gregkh-usb-usb-add-the-concept-of-default-authorization-to-usb-hosts.patch ... USB tree updates ... dev_attr_authorized_default can become static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- --- linux-2.6.23-rc1-mm1/drivers/usb/core/hcd.c.old 2007-07-26 21:50:30.0 +0200 +++ linux-2.6.23-rc1-mm1/drivers/usb/core/hcd.c 2007-07-26 21:50:45.0 +0200 @@ -717,9 +717,9 @@ return result; } -DEVICE_ATTR(authorized_default, 0644, - usb_host_authorized_default_show, - usb_host_authorized_default_store); +static DEVICE_ATTR(authorized_default, 0644, + usb_host_authorized_default_show, + usb_host_authorized_default_store); /* Group all the USB bus attributes */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] backlight: make 2 structs static
This patch makes two needlessly global structs static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/video/backlight/backlight.c |2 +-
drivers/video/backlight/lcd.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.23-rc1-mm1/drivers/video/backlight/backlight.c.old
2007-07-26 21:56:23.0 +0200
+++ linux-2.6.23-rc1-mm1/drivers/video/backlight/backlight.c2007-07-26
21:56:31.0 +0200
@@ -164,7 +164,7 @@
return rc;
}
-struct class *backlight_class;
+static struct class *backlight_class;
static void bl_device_release(struct device *dev)
{
--- linux-2.6.23-rc1-mm1/drivers/video/backlight/lcd.c.old 2007-07-26
21:57:40.0 +0200
+++ linux-2.6.23-rc1-mm1/drivers/video/backlight/lcd.c 2007-07-26
22:18:23.0 +0200
@@ -149,7 +149,7 @@
return sprintf(buf, %d\n, ld-props.max_contrast);
}
-struct class *lcd_class;
+static struct class *lcd_class;
static void lcd_device_release(struct device *dev)
{
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] security/ cleanups
This patch contains the following cleanups that are now possible:
- remove the unused security_operations-inode_xattr_getsuffix
- remove the no longer used security_operations-unregister_security
- remove some no longer required exit code
- remove a bunch of no longer used exports
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/usb/core/usb.c |1
fs/exec.c|2 -
include/linux/security.h | 15 --
kernel/capability.c |4 --
mm/mmap.c|2 -
mm/nommu.c |1
security/commoncap.c | 21 --
security/dummy.c | 12
security/inode.c |8 -
security/security.c | 58 ---
security/selinux/hooks.c | 20 -
11 files changed, 1 insertion(+), 143 deletions(-)
--- linux-2.6.23-rc1-mm1/include/linux/security.h.old 2007-07-26
03:03:21.0 +0200
+++ linux-2.6.23-rc1-mm1/include/linux/security.h 2007-07-26
03:08:11.0 +0200
@@ -1136,10 +1136,6 @@ struct request_sock;
* allow module stacking.
* @name contains the name of the security module being stacked.
* @ops contains a pointer to the struct security_operations of the module
to stack.
- * @unregister_security:
- * remove a stacked module.
- * @name contains the name of the security module being unstacked.
- * @ops contains a pointer to the struct security_operations of the module
to unstack.
*
* @secid_to_secctx:
* Convert secid to security context.
@@ -1235,7 +1231,6 @@ struct security_operations {
int (*inode_getxattr) (struct dentry *dentry, char *name);
int (*inode_listxattr) (struct dentry *dentry);
int (*inode_removexattr) (struct dentry *dentry, char *name);
- const char *(*inode_xattr_getsuffix) (void);
int (*inode_getsecurity)(const struct inode *inode, const char *name,
void *buffer, size_t size, int err);
int (*inode_setsecurity)(struct inode *inode, const char *name, const
void *value, size_t size, int flags);
int (*inode_listsecurity)(struct inode *inode, char *buffer, size_t
buffer_size);
@@ -1325,8 +1320,6 @@ struct security_operations {
/* allow module stacking */
int (*register_security) (const char *name,
struct security_operations *ops);
- int (*unregister_security) (const char *name,
- struct security_operations *ops);
void (*d_instantiate) (struct dentry *dentry, struct inode *inode);
@@ -1407,9 +1400,7 @@ struct security_operations {
/* prototypes */
extern int security_init (void);
extern int register_security (struct security_operations *ops);
-extern int unregister_security (struct security_operations *ops);
extern int mod_reg_security(const char *name, struct security_operations
*ops);
-extern int mod_unreg_security (const char *name, struct security_operations
*ops);
extern struct dentry *securityfs_create_file(const char *name, mode_t mode,
struct dentry *parent, void *data,
const struct file_operations
*fops);
@@ -1490,7 +1481,6 @@ void security_inode_post_setxattr(struct
int security_inode_getxattr(struct dentry *dentry, char *name);
int security_inode_listxattr(struct dentry *dentry);
int security_inode_removexattr(struct dentry *dentry, char *name);
-const char *security_inode_xattr_getsuffix(void);
int security_inode_getsecurity(const struct inode *inode, const char *name,
void *buffer, size_t size, int err);
int security_inode_setsecurity(struct inode *inode, const char *name, const
void *value, size_t size, int flags);
int security_inode_listsecurity(struct inode *inode, char *buffer, size_t
buffer_size);
@@ -1879,11 +1869,6 @@ static inline int security_inode_removex
return cap_inode_removexattr(dentry, name);
}
-static inline const char *security_inode_xattr_getsuffix (void)
-{
- return NULL ;
-}
-
static inline int security_inode_getsecurity(const struct inode *inode, const
char *name, void *buffer, size_t size, int err)
{
return -EOPNOTSUPP;
--- linux-2.6.23-rc1-mm1/security/security.c.old2007-07-26
03:03:33.0 +0200
+++ linux-2.6.23-rc1-mm1/security/security.c2007-07-27 22:24:41.0
+0200
@@ -71,8 +71,7 @@ int __init security_init(void)
*
* This function is to allow a security module to register itself with the
* kernel security subsystem. Some rudimentary checking is done on the @ops
- * value passed to this function. A call to unregister_security() should be
- * done to remove this security_options structure from the kernel.
+ * value passed to this function.
*
* If there is already a security module registered with the kernel,
* an error will be returned. Otherwise 0 is returned on success.
@@ -94,31 +93,6 @@ int
[2.6.23 regression fix] acpi_ec_remove(): fix use-after-free
This patch fixes an obvious use-after-free introduced by
commit 837012ede14a8fc088be3682c964da7fc6af026b.
Spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6.23-rc1-mm1/drivers/acpi/ec.c.old 2007-07-28 07:59:49.0
+0200
+++ linux-2.6.23-rc1-mm1/drivers/acpi/ec.c 2007-07-28 08:00:25.0
+0200
@@ -730,14 +730,14 @@
static int acpi_ec_remove(struct acpi_device *device, int type)
{
struct acpi_ec *ec;
- struct acpi_ec_query_handler *handler;
+ struct acpi_ec_query_handler *handler, *tmp;
if (!device)
return -EINVAL;
ec = acpi_driver_data(device);
mutex_lock(ec-lock);
- list_for_each_entry(handler, ec-list, node) {
+ list_for_each_entry_safe(handler, tmp, ec-list, node) {
list_del(handler-node);
kfree(handler);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] unexport pm_power_off_prepare
This patch removes the unused EXPORT_SYMBOL(pm_power_off_prepare).
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6.23-rc1-mm1/kernel/sys.c.old 2007-07-28 07:38:45.0
+0200
+++ linux-2.6.23-rc1-mm1/kernel/sys.c 2007-07-28 07:38:59.0 +0200
@@ -104,7 +104,6 @@ EXPORT_SYMBOL(cad_pid);
*/
void (*pm_power_off_prepare)(void);
-EXPORT_SYMBOL(pm_power_off_prepare);
static int set_one_prio(struct task_struct *p, int niceval, int error)
{
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] BLOCK=n , LGUEST=m/y compile error
Hi Rusty,
Lguest should depend on BLOCK too , without BLOCK set I get this error:
...
drivers/block/lguest_blk.c: In function 'end_entire_request':
drivers/block/lguest_blk.c:80: error: implicit declaration of function
'end_that_request_first'
drivers/block/lguest_blk.c:80: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:82: error: implicit declaration of function
'add_disk_randomness'
drivers/block/lguest_blk.c:82: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:83: error: implicit declaration of function
'blkdev_dequeue_request'
drivers/block/lguest_blk.c:84: error: implicit declaration of function
'end_that_request_last'
drivers/block/lguest_blk.c: In function 'lgb_irq':
drivers/block/lguest_blk.c:128: error: implicit declaration of function
'blk_start_queue'
drivers/block/lguest_blk.c:128: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c: In function 'req_to_dma':
drivers/block/lguest_blk.c:148: error: implicit declaration of function
'rq_for_each_bio'
drivers/block/lguest_blk.c:148: error: expected ';' before '{' token
drivers/block/lguest_blk.c:145: warning: unused variable 'idx'
drivers/block/lguest_blk.c:145: warning: unused variable 'i'
drivers/block/lguest_blk.c: In function 'setup_req':
drivers/block/lguest_blk.c:185: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c: In function 'do_write':
drivers/block/lguest_blk.c:202: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c: In function 'do_read':
drivers/block/lguest_blk.c:215: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c: In function 'do_lgb_request':
drivers/block/lguest_blk.c:234: error: implicit declaration of function
'elv_next_request'
drivers/block/lguest_blk.c:234: warning: assignment makes pointer from integer
without a cast
drivers/block/lguest_blk.c:239: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:246: error: implicit declaration of function
'blk_fs_request'
drivers/block/lguest_blk.c:247: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:248: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:253: error: implicit declaration of function
'rq_data_dir'
drivers/block/lguest_blk.c:260: error: implicit declaration of function
'blk_stop_queue'
drivers/block/lguest_blk.c: In function 'lguestblk_probe':
drivers/block/lguest_blk.c:304: error: implicit declaration of function
'register_blkdev'
drivers/block/lguest_blk.c:313: error: implicit declaration of function
'alloc_disk'
drivers/block/lguest_blk.c:313: warning: assignment makes pointer from integer
without a cast
drivers/block/lguest_blk.c:322: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:322: error: implicit declaration of function
'blk_init_queue'
drivers/block/lguest_blk.c:323: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:335: error: implicit declaration of function
'blk_queue_max_hw_segments'
drivers/block/lguest_blk.c:335: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:341: error: implicit declaration of function
'blk_queue_segment_boundary'
drivers/block/lguest_blk.c:341: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:349: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:360: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:373: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:374: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:375: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:376: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:378: error: implicit declaration of function
'set_capacity'
drivers/block/lguest_blk.c:379: error: implicit declaration of function
'add_disk'
drivers/block/lguest_blk.c:382: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:392: error: implicit declaration of function
'blk_cleanup_queue'
drivers/block/lguest_blk.c:392: error: dereferencing pointer to incomplete type
drivers/block/lguest_blk.c:394: error: implicit declaration of function
'put_disk'
drivers/block/lguest_blk.c:396: error: implicit declaration of function
'unregister_blkdev'
make[2]: *** [drivers/block/lguest_blk.o] Error 1
make[1]: *** [drivers/block] Error 2
Signed-off-by: Gabriel Craciunescu [EMAIL PROTECTED]
---
Documentation/lguest/lguest.txt |1 +
drivers/lguest/Kconfig |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/lguest/lguest.txt b/Documentation/lguest/lguest.txt
index 821617b..4e7408c 100644
--- a/Documentation/lguest/lguest.txt
+++ b/Documentation/lguest/lguest.txt
@@ -33,6 +33,7 @@ Running Lguest:
CONFIG_EXPERIMENTAL=y (Prompt for development and/or
Re: Linus 2.6.23-rc1
On Sonntag, 29. Juli 2007, Kasper Sandberg wrote: On Sun, 2007-07-29 at 01:41 +0200, Volker Armin Hemmann wrote: Hi, I never tried Con's patchset, for two reasons: I tried his 2.4 patches ones, and I never saw any improvements. So when people were reporting huge improvements with his SD scheduler, I compared that with the reports of huge improvements with his 2.4 kernel patches. Well thats a reason if there ever were one... yes, it is. The fans claimed once lots of stuff that was not true for me. So why believing them 'now'? ... The second: too many patches. I only would have tried one or two, but the ck-patchset is a lot bigger.. and I am a little bit uneasy about that. so use only the scheduler? nobody forces you to do many things.. but which one is needed? http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.22/2.6.22-ck1/patches/ six patches who start with 'sched-' and which one is needed? and which is not? Can I only use sched-staircase-deadline-cpu-scheduler.patch or do I need the others too? Better than old vanilla yes, but than SD? well, you should give it a try. see above. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nvidia installer DIW with 2.6.23-rc1
On Jul 29 2007 10:57, Gene Heskett wrote: /tmp/selfgz9678/NVIDIA-Linux-x86-100.14.11-pkg1/usr/src/nv/nv.c: In function ‘nvidia_init_module’: /tmp/selfgz9678/NVIDIA-Linux-x86-100.14.11-pkg1/usr/src/nv/nv.c:1326: error: too many arguments to function ‘kmem_cache_create’ Is this a known problem? Do I need to report it to nvidia somehow? Well, you do not *need* to report it, just as you do not need to report kernel oopses or Windows crashes. They'll eventually stumble upon that themselves It looks to me like it may be their problem, and I have submitted it, but if anyone has a better idea, please advise. System is FC6, uptodate as of yesterday. Better idea? Fix the source until they have a fix. It seems to be just an extra argument to kmem_cache_create that got removed. Jan --
[2.6 patch] parisc: extern inline - static inline
extern inline will have different semantics with gcc 4.3,
and static inline is correct here.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
arch/parisc/lib/memcpy.c |4 ++--
include/asm-parisc/io.h|2 +-
include/asm-parisc/pci.h |2 +-
include/asm-parisc/pgtable.h | 32
include/asm-parisc/prefetch.h |4 ++--
include/asm-parisc/semaphore.h | 10 +-
include/asm-parisc/tlbflush.h |3 +--
7 files changed, 28 insertions(+), 29 deletions(-)
--- linux-2.6.14-rc5-mm1-full/arch/parisc/lib/memcpy.c.old 2005-10-30
01:58:43.0 +0200
+++ linux-2.6.14-rc5-mm1-full/arch/parisc/lib/memcpy.c 2005-10-30
01:59:11.0 +0200
@@ -158,12 +158,12 @@
#define stw(_s,_t,_o,_a,_e)def_store_insn(stw,r,_s,_t,_o,_a,_e)
#ifdef CONFIG_PREFETCH
-extern inline void prefetch_src(const void *addr)
+static inline void prefetch_src(const void *addr)
{
__asm__(ldw 0( s_space ,%0), %%r0 : : r (addr));
}
-extern inline void prefetch_dst(const void *addr)
+static inline void prefetch_dst(const void *addr)
{
__asm__(ldd 0( d_space ,%0), %%r0 : : r (addr));
}
--- linux-2.6.14-rc5-mm1-full/include/asm-parisc/pci.h.old 2005-10-30
01:59:57.0 +0200
+++ linux-2.6.14-rc5-mm1-full/include/asm-parisc/pci.h 2005-10-30
02:00:01.0 +0200
@@ -193,7 +193,7 @@
extern void pcibios_register_hba(struct pci_hba_data *);
extern void pcibios_set_master(struct pci_dev *);
#else
-extern inline void pcibios_register_hba(struct pci_hba_data *x)
+static inline void pcibios_register_hba(struct pci_hba_data *x)
{
}
#endif
--- linux-2.6.14-rc5-mm1-full/include/asm-parisc/semaphore.h.old
2005-10-30 02:00:45.0 +0200
+++ linux-2.6.14-rc5-mm1-full/include/asm-parisc/semaphore.h2005-10-30
02:00:51.0 +0200
@@ -58,7 +58,7 @@
#define DECLARE_MUTEX(name) __DECLARE_SEMAPHORE_GENERIC(name,1)
#define DECLARE_MUTEX_LOCKED(name) __DECLARE_SEMAPHORE_GENERIC(name,0)
-extern inline void sema_init (struct semaphore *sem, int val)
+static inline void sema_init (struct semaphore *sem, int val)
{
*sem = (struct semaphore)__SEMAPHORE_INITIALIZER((*sem),val);
}
@@ -86,7 +86,7 @@
* interrupts while we're messing with the semaphore. Sorry.
*/
-extern __inline__ void down(struct semaphore * sem)
+static inline void down(struct semaphore * sem)
{
might_sleep();
spin_lock_irq(sem-sentry);
@@ -98,7 +98,7 @@
spin_unlock_irq(sem-sentry);
}
-extern __inline__ int down_interruptible(struct semaphore * sem)
+static inline int down_interruptible(struct semaphore * sem)
{
int ret = 0;
might_sleep();
@@ -116,3 +116,3 @@
*/
-extern __inline__ int down_trylock(struct semaphore * sem)
+static inline int down_trylock(struct semaphore * sem)
{
@@ -132,3 +132,3 @@
*/
-extern __inline__ void up(struct semaphore * sem)
+static inline void up(struct semaphore * sem)
{
--- linux-2.6.14-rc5-mm1-full/include/asm-parisc/tlbflush.h.old 2005-10-30
02:01:00.0 +0200
+++ linux-2.6.14-rc5-mm1-full/include/asm-parisc/tlbflush.h 2005-10-30
02:01:06.0 +0200
@@ -42,7 +42,7 @@
#endif
}
-extern __inline__ void flush_tlb_pgtables(struct mm_struct *mm, unsigned long
start, unsigned long end)
+static inline void flush_tlb_pgtables(struct mm_struct *mm, unsigned long
start, unsigned long end)
{
}
--- linux-2.6.18-rc4-mm1/include/asm-parisc/io.h.old2006-08-13
23:08:01.0 +0200
+++ linux-2.6.18-rc4-mm1/include/asm-parisc/io.h2006-08-13
23:08:15.0 +0200
@@ -128,7 +128,7 @@
/* Most machines react poorly to I/O-space being cacheable... Instead let's
* define ioremap() in terms of ioremap_nocache().
*/
-extern inline void __iomem * ioremap(unsigned long offset, unsigned long size)
+static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
{
return __ioremap(offset, size, _PAGE_NO_CACHE);
}
--- linux-2.6.18-rc4-mm1/include/asm-parisc/prefetch.h.old 2006-08-13
23:08:25.0 +0200
+++ linux-2.6.18-rc4-mm1/include/asm-parisc/prefetch.h 2006-08-13
23:08:34.0 +0200
@@ -19,7 +19,7 @@
#ifdef CONFIG_PREFETCH
#define ARCH_HAS_PREFETCH
-extern inline void prefetch(const void *addr)
+static inline void prefetch(const void *addr)
{
__asm__(ldw 0(%0), %%r0 : : r (addr));
}
@@ -27,7 +27,7 @@
/* LDD is a PA2.0 addition. */
#ifdef CONFIG_PA20
#define ARCH_HAS_PREFETCHW
-extern inline void prefetchw(const void *addr)
+static inline void prefetchw(const void *addr)
{
__asm__(ldd 0(%0), %%r0 : : r (addr));
}
--- linux-2.6.23-rc1-mm1/include/asm-parisc/pgtable.h.old 2007-07-28
17:18:19.0 +0200
+++ linux-2.6.23-rc1-mm1/include/asm-parisc/pgtable.h 2007-07-28
17:18:40.0 +0200
@@ -325,27 +325,27 @@ static inline void pgd_clear(pgd_t *pgd)
* setup: the pgd is never bad, and a pmd always exists (as it's folded
* into the pgd
Re: request for patches: showing mount options
[cc trim on purpose, just autofs interest here] On Jul 28 2007 14:45, Ian Kent wrote: Oh .. sorry, I wasn't paying enough attention. But now might be a good time to propose the removal of autofs and rename autofs4 to autofs. I would need to provide some way to map autofs4 module load requests to autofs for backward compatibility but haven't thought about that yet. You could use EXPORT_SYMBOL in autofs.ko that autofs4.ko uses. Or write an autofs4.c that does try_module_get(autofs) on _init. Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb-serial: Fix edgeport regression on non-EPiC devices
Fix serious regression on non-EPiC edgeport usb-serial devices. Baud
rate and MCR/LCR registers are not being written on these models due
to apparent copy-n-paste errors introduced with EPiC support.
Failure reported by Nick Pasich [EMAIL PROTECTED].
Signed-off-by: Adam Kropelin [EMAIL PROTECTED]
--
Assuming this is a right and proper fix, it should go in the -stable
tree ASAP.
--- linux-2.6.22.1/drivers/usb/serial/io_edgeport.c 2007-07-10
14:56:30.0 -0400
+++ linux-2.6.22.1.new/drivers/usb/serial/io_edgeport.c 2007-07-29
09:45:18.0 -0400
@@ -2366,9 +2366,8 @@
int status;
unsigned char number = edge_port-port-number -
edge_port-port-serial-minor;
- if ((!edge_serial-is_epic) ||
- ((edge_serial-is_epic)
-(!edge_serial-epic_descriptor.Supports.IOSPSetBaudRate))) {
+ if (edge_serial-is_epic
+ !edge_serial-epic_descriptor.Supports.IOSPSetBaudRate) {
dbg(SendCmdWriteBaudRate - NOT Setting baud rate for port =
%d, baud = %d,
edge_port-port-number, baudRate);
return 0;
@@ -2461,18 +2460,16 @@
dbg(%s - write to %s register 0x%02x, (regNum == MCR) ? MCR :
LCR, __FUNCTION__, regValue);
- if ((!edge_serial-is_epic) ||
- ((edge_serial-is_epic)
-(!edge_serial-epic_descriptor.Supports.IOSPWriteMCR)
-(regNum == MCR))) {
+ if (edge_serial-is_epic
+ !edge_serial-epic_descriptor.Supports.IOSPWriteMCR
+ regNum == MCR) {
dbg(SendCmdWriteUartReg - Not writing to MCR Register);
return 0;
}
- if ((!edge_serial-is_epic) ||
- ((edge_serial-is_epic)
-(!edge_serial-epic_descriptor.Supports.IOSPWriteLCR)
-(regNum == LCR))) {
+ if (edge_serial-is_epic
+ !edge_serial-epic_descriptor.Supports.IOSPWriteLCR
+ regNum == LCR) {
dbg (SendCmdWriteUartReg - Not writing to LCR Register);
return 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: Linus 2.6.23-rc1
hi Kasper, * Kasper Sandberg [EMAIL PROTECTED] wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. And this is despite many patches he sent me to try and tweak it. [...] hey, i thought you vanished from the face of the earth :-) The last email i got from you was more than 2 months ago, where you said that you'll try the latest CFS version as soon as possible but that you were busy with work. I sent 2 more emails to you about new CFS versions but then stopped pestering you directly - work _does_ take precedence over games =B-) CFS v14, v15, v16, v17, v18 and v19 was released meanwhile, CFS v20 went upstream, there were no 3D related CFS regressions open for quite some time and because i never heard back from you i assumed everything's peachy. In any case i'm glad you found the time to try CFS again, so please let me know in what way it regresses. In your most recent emails you did not indicate what specific problem you are having (and you did not reply to my last emails from May) - are your old regression reports against CFS v13 from May still true as of v2.6.23-rc1? If they are, could you please indicate which specific report of yours describes it best and send me (or upload to some webspace) the specific .config you are using on your box, and the cfs-debug-info.sh snapshot taken when you are running your game. (make sure you have CONFIG_SCHED_DEBUG=y enabled, for highest quality debug output) You can pick the script up from: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh Giving us that info would help us immensely with tracking down any CFS problem you might still be having. Or, if you feel adventurous enough to look into the internals of the kernel (which, considering your offer to take up SD maintenance, you must be ;-), here's my kernel latency tracer: http://people.redhat.com/mingo/latency-tracing-patches/ ( see: latency-tracer-v2.6.23-rc1-combo.patch ) the simplest way to use it is to enable CONFIG_WAKEUP_TIMING, to set /proc/sys/kernel/preempt_max_latency back to 0 (after bootup) and to thus measure raw worst-case scheduler latencies - if you regularly see the kernel report above say 1000 usecs latencies to the syslog, on a PREEMPT kernel then there's definitely something foul going on. For example, that's how i found an audio playback latency problem in an early version of CFS: (sshd-14614|#1): new 5 us maximum-latency wakeup. ( ogg123-6603 |#1): new 6 us maximum-latency wakeup. ( ogg123-6608 |#1): new 6 us maximum-latency wakeup. (sshd-14614|#1): new 10 us maximum-latency wakeup. ( ogg123-6607 |#0): new 15 us maximum-latency wakeup. (events/0-9|#0): new 789 us maximum-latency wakeup. ( ogg123-6603 |#0): new 2566 us maximum-latency wakeup. that 2.5 msecs latency in the ogg123 task was definitely the sign of a kernel bug. If plain WAKEUP_TIMING does not show anything suspicious, you can use the latency tracer in more advanced ways as well to trace the whole system and figure out the precise cause of your game latencies - i'll be glad to help with that if no simpler measure helps. [see trace-it.c for some of those details.] [...] As far as im concerned, i may be forced to unofficially maintain SD for my own systems(allthough lots in the gaming community is bound to be interrested, as it does make games lots better) i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] Thanks, Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/vmstat.c: cleanups
This patch contains the following cleanups:
- make the needlessly global setup_vmstat() static
- remove the unused refresh_vm_stats()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Christoph Lameter [EMAIL PROTECTED]
---
This patch has been sent on:
- 9 Jul 2007
mm/vmstat.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
--- linux-2.6.22-rc6-mm1/mm/vmstat.c.old2007-07-05 16:54:39.0
+0200
+++ linux-2.6.22-rc6-mm1/mm/vmstat.c2007-07-08 22:27:26.0 +0200
@@ -353,23 +353,6 @@
}
}
-static void __refresh_cpu_vm_stats(void *dummy)
-{
- refresh_cpu_vm_stats(smp_processor_id());
-}
-
-/*
- * Consolidate all counters.
- *
- * Note that the result is less inaccurate but still inaccurate
- * if concurrent processes are allowed to run.
- */
-void refresh_vm_stats(void)
-{
- on_each_cpu(__refresh_cpu_vm_stats, NULL, 0, 1);
-}
-EXPORT_SYMBOL(refresh_vm_stats);
-
#endif
#ifdef CONFIG_NUMA
@@ -957,7 +940,7 @@
static struct notifier_block __cpuinitdata vmstat_notifier =
{ vmstat_cpuup_callback, NULL, 0 };
-int __init setup_vmstat(void)
+static int __init setup_vmstat(void)
{
int cpu;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] fs/afs/: possible cleanups
This patch contains the following possible cleanups:
- make the following needlessly global functions static:
- rxrpc.c: afs_send_pages()
- vlocation.c: afs_vlocation_queue_for_updates()
- write.c: afs_writepages_region()
- make the following needlessly global variables static:
- mntpt.c: afs_mntpt_expiry_timeout
- proc.c: afs_vlocation_states[]
- server.c: afs_server_timeout
- vlocation.c: afs_vlocation_timeout
- vlocation.c: afs_vlocation_update_timeout
- #if 0 the following unused function:
- cell.c: afs_get_cell_maybe()
- #if 0 the following unused variables:
- callback.c: afs_vnode_update_timeout
- cmservice.c: struct afs_cm_workqueue
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: David Howells [EMAIL PROTECTED]
---
This patch has been sent on:
- 5 Jun 2007
fs/afs/callback.c |2 ++
fs/afs/cell.c |2 ++
fs/afs/cmservice.c |2 ++
fs/afs/internal.h |1 -
fs/afs/mntpt.c |2 +-
fs/afs/proc.c |2 +-
fs/afs/rxrpc.c |3 ++-
fs/afs/server.c|2 +-
fs/afs/vlocation.c |6 +++---
fs/afs/write.c |6 +++---
10 files changed, 17 insertions(+), 11 deletions(-)
--- linux-2.6.22-rc3-mm1/fs/afs/callback.c.old 2007-06-05 21:45:34.0
+0200
+++ linux-2.6.22-rc3-mm1/fs/afs/callback.c 2007-06-05 21:46:40.0
+0200
@@ -20,7 +20,9 @@
#include linux/sched.h
#include internal.h
+#if 0
unsigned afs_vnode_update_timeout = 10;
+#endif /* 0 */
#define afs_breakring_space(server) \
CIRC_SPACE((server)-cb_break_head, (server)-cb_break_tail,\
--- linux-2.6.22-rc3-mm1/fs/afs/cell.c.old 2007-06-05 21:47:20.0
+0200
+++ linux-2.6.22-rc3-mm1/fs/afs/cell.c 2007-06-05 21:47:39.0 +0200
@@ -265,6 +265,7 @@
return cell;
}
+#if 0
/*
* try and get a cell record
*/
@@ -280,6 +281,7 @@
write_unlock(afs_cells_lock);
return cell;
}
+#endif /* 0 */
/*
* destroy a cell record
--- linux-2.6.22-rc3-mm1/fs/afs/cmservice.c.old 2007-06-05 21:48:06.0
+0200
+++ linux-2.6.22-rc3-mm1/fs/afs/cmservice.c 2007-06-05 21:48:19.0
+0200
@@ -16,7 +16,9 @@
#include internal.h
#include afs_cm.h
+#if 0
struct workqueue_struct *afs_cm_workqueue;
+#endif /* 0 */
static int afs_deliver_cb_init_call_back_state(struct afs_call *,
struct sk_buff *, bool);
--- linux-2.6.22-rc3-mm1/fs/afs/internal.h.old 2007-06-05 21:48:48.0
+0200
+++ linux-2.6.22-rc3-mm1/fs/afs/internal.h 2007-06-05 21:48:55.0
+0200
@@ -570,7 +570,6 @@
*/
extern const struct inode_operations afs_mntpt_inode_operations;
extern const struct file_operations afs_mntpt_file_operations;
-extern unsigned long afs_mntpt_expiry_timeout;
extern int afs_mntpt_check_symlink(struct afs_vnode *, struct key *);
extern void afs_mntpt_kill_timer(void);
--- linux-2.6.22-rc3-mm1/fs/afs/mntpt.c.old 2007-06-05 21:49:03.0
+0200
+++ linux-2.6.22-rc3-mm1/fs/afs/mntpt.c 2007-06-05 21:49:11.0 +0200
@@ -42,7 +42,7 @@
static LIST_HEAD(afs_vfsmounts);
static DECLARE_DELAYED_WORK(afs_mntpt_expiry_timer,
afs_mntpt_expiry_timed_out);
-unsigned long afs_mntpt_expiry_timeout = 10 * 60;
+static unsigned long afs_mntpt_expiry_timeout = 10 * 60;
/*
* check a symbolic link to see whether it actually encodes a mountpoint
--- linux-2.6.22-rc3-mm1/fs/afs/proc.c.old 2007-06-05 21:49:35.0
+0200
+++ linux-2.6.22-rc3-mm1/fs/afs/proc.c 2007-06-05 21:49:43.0 +0200
@@ -513,7 +513,7 @@
up_read(cell-vl_sem);
}
-const char afs_vlocation_states[][4] = {
+static const char afs_vlocation_states[][4] = {
[AFS_VL_NEW]= New,
[AFS_VL_CREATING] = Crt,
[AFS_VL_VALID] = Val,
--- linux-2.6.22-rc3-mm1/fs/afs/rxrpc.c.old 2007-06-05 21:50:05.0
+0200
+++ linux-2.6.22-rc3-mm1/fs/afs/rxrpc.c 2007-06-05 21:50:19.0 +0200
@@ -239,7 +239,8 @@
/*
* attach the data from a bunch of pages on an inode to a call
*/
-int afs_send_pages(struct afs_call *call, struct msghdr *msg, struct kvec *iov)
+static int afs_send_pages(struct afs_call *call, struct msghdr *msg,
+ struct kvec *iov)
{
struct page *pages[8];
unsigned count, n, loop, offset, to;
--- linux-2.6.22-rc3-mm1/fs/afs/server.c.old2007-06-05 21:50:45.0
+0200
+++ linux-2.6.22-rc3-mm1/fs/afs/server.c2007-06-05 21:50:52.0
+0200
@@ -13,7 +13,7 @@
#include linux/slab.h
#include internal.h
-unsigned afs_server_timeout = 10; /* server timeout in seconds */
+static unsigned afs_server_timeout = 10; /* server timeout in seconds */
static void afs_reap_server(struct work_struct *);
--- linux-2.6.22-rc3-mm1/fs/afs/vlocation.c.old 2007-06-05 21:51:17.0
+0200
+++ linux-2.6.22-rc3-mm1/fs/afs/vlocation.c 2007-06-05 21:51:55.0
+0200
@@ -15,8 +15,8 @@
[RFC: 2.6 patch] allow disabling DNOTIFY without EMBEDDED
This patch allows disabling DNOTIFY with CONFIG_EMBEDDED=n. I'm currently running a kernel with dnotify disabled and I haven't run into any problem. Is there any popular application left that breaks without dnotify support in the kernel? Note that this patch does not remove dnotify support, it still defaults to y, and the help text recommends enabling it. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- This patch has been sent on: - 1 Jul 2007 - 22 Jun 2007 --- linux-2.6.22-rc4-mm2/fs/Kconfig.old 2007-06-21 18:25:20.0 +0200 +++ linux-2.6.22-rc4-mm2/fs/Kconfig 2007-06-21 18:25:54.0 +0200 @@ -585,17 +585,17 @@ depends on XFS_QUOTA || QUOTA default y config DNOTIFY - bool Dnotify support if EMBEDDED + bool Dnotify support default y help Dnotify is a directory-based per-fd file change notification system that uses signals to communicate events to user-space. There exist superior alternatives, but some applications may still rely on dnotify. - Because of this, if unsure, say Y. + If unsure, say Y. config AUTOFS_FS tristate Kernel automounter support help - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] i386: no need to make enable_cpu_hotplug a variable
As long as there's no write access to this variable there's no reason
to let gcc check it at runtime.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch has been sent on:
- 6 Jul 2007
arch/i386/kernel/topology.c |2 --
include/asm-i386/cpu.h |2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
--- linux-2.6.22-rc6-mm1/include/asm-i386/cpu.h.old 2007-07-04
20:29:25.0 +0200
+++ linux-2.6.22-rc6-mm1/include/asm-i386/cpu.h 2007-07-04 20:36:33.0
+0200
@@ -13,7 +13,7 @@
extern int arch_register_cpu(int num);
#ifdef CONFIG_HOTPLUG_CPU
extern void arch_unregister_cpu(int);
-extern int enable_cpu_hotplug;
+#define enable_cpu_hotplug 1
#else
#define enable_cpu_hotplug 0
#endif
--- linux-2.6.22-rc6-mm1/arch/i386/kernel/topology.c.old2007-07-04
20:30:12.0 +0200
+++ linux-2.6.22-rc6-mm1/arch/i386/kernel/topology.c2007-07-04
20:35:56.0 +0200
@@ -51,8 +51,6 @@
}
#ifdef CONFIG_HOTPLUG_CPU
-int enable_cpu_hotplug = 1;
-
void arch_unregister_cpu(int num) {
return unregister_cpu(cpu_devices[num].cpu);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] lib/ioremap.c should #include linux/io.h
Every file should include the headers containing the prototypes for its global functions (in this case ioremap_page_range()). Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Acked-by: Haavard Skinnemoen [EMAIL PROTECTED] --- This patch has been sent on: - 6 Jul 2007 --- linux-2.6.22-rc6-mm1/lib/ioremap.c.old 2007-07-03 05:02:10.0 +0200 +++ linux-2.6.22-rc6-mm1/lib/ioremap.c 2007-07-03 05:02:22.0 +0200 @@ -8,6 +8,7 @@ #include linux/vmalloc.h #include linux/mm.h #include linux/sched.h +#include linux/io.h #include asm/cacheflush.h #include asm/pgtable.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/
[2.6 patch] kernel/audit.c: change the exports to EXPORT_SYMBOL_GPL
This patch changes some completely unused audit exports from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL. They are still completely unused, but hopefully some of the theoretical code that might use it will appear in the kernel in the near future... Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Acked-by: Steve Grubb [EMAIL PROTECTED] --- This patch has been sent on: - 11 Dec 2006 --- linux-2.6.19-mm1/kernel/audit.c.old 2006-12-11 20:13:54.0 +0100 +++ linux-2.6.19-mm1/kernel/audit.c 2006-12-11 20:14:19.0 +0100 @@ -1209,7 +1209,7 @@ } } -EXPORT_SYMBOL(audit_log_start); -EXPORT_SYMBOL(audit_log_end); -EXPORT_SYMBOL(audit_log_format); -EXPORT_SYMBOL(audit_log); +EXPORT_SYMBOL_GPL(audit_log_start); +EXPORT_SYMBOL_GPL(audit_log_end); +EXPORT_SYMBOL_GPL(audit_log_format); +EXPORT_SYMBOL_GPL(audit_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/
[2.6 patch] arch/i386/mm/discontig.c: make some variables static
This patch makes some needlessly global variables static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- This patch has been sent on: - 6 Jul 2007 arch/i386/mm/discontig.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --- linux-2.6.22-rc6-mm1/arch/i386/mm/discontig.c.old 2007-07-05 15:59:32.0 +0200 +++ linux-2.6.22-rc6-mm1/arch/i386/mm/discontig.c 2007-07-05 16:02:47.0 +0200 @@ -103,14 +103,14 @@ #define LARGE_PAGE_BYTES (PTRS_PER_PTE * PAGE_SIZE) -unsigned long node_remap_start_pfn[MAX_NUMNODES]; +static unsigned long node_remap_start_pfn[MAX_NUMNODES]; unsigned long node_remap_size[MAX_NUMNODES]; -unsigned long node_remap_offset[MAX_NUMNODES]; -void *node_remap_start_vaddr[MAX_NUMNODES]; +static unsigned long node_remap_offset[MAX_NUMNODES]; +static void *node_remap_start_vaddr[MAX_NUMNODES]; void set_pmd_pfn(unsigned long vaddr, unsigned long pfn, pgprot_t flags); -void *node_remap_end_vaddr[MAX_NUMNODES]; -void *node_remap_alloc_vaddr[MAX_NUMNODES]; +static void *node_remap_end_vaddr[MAX_NUMNODES]; +static void *node_remap_alloc_vaddr[MAX_NUMNODES]; static unsigned long kva_start_pfn; static unsigned long kva_pages; /* - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] ipc/shm.c: make 2 functions static
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch has been sent on:
- 6 Jul 2007
ipc/shm.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- linux-2.6.22-rc6-mm1/ipc/shm.c.old 2007-07-05 16:08:24.0 +0200
+++ linux-2.6.22-rc6-mm1/ipc/shm.c 2007-07-05 16:08:44.0 +0200
@@ -234,7 +234,7 @@
}
#ifdef CONFIG_NUMA
-int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
+static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
struct file *file = vma-vm_file;
struct shm_file_data *sfd = shm_file_data(file);
@@ -244,7 +244,8 @@
return err;
}
-struct mempolicy *shm_get_policy(struct vm_area_struct *vma, unsigned long
addr)
+static struct mempolicy *shm_get_policy(struct vm_area_struct *vma,
+ unsigned long addr)
{
struct file *file = vma-vm_file;
struct shm_file_data *sfd = shm_file_data(file);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] kernel/sched.c: make code static
This patch makes the following needlessly global code static:
- arch_reinit_sched_domains()
- struct attr_sched_mc_power_savings
- struct attr_sched_smt_power_savings
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch has been sent on:
- 6 Jul 2007
include/linux/cpu.h |2 -
kernel/sched.c | 46 ++--
2 files changed, 23 insertions(+), 25 deletions(-)
--- linux-2.6.22-rc6-mm1/include/linux/cpu.h.old2007-07-05
16:13:11.0 +0200
+++ linux-2.6.22-rc6-mm1/include/linux/cpu.h2007-07-05 16:18:03.0
+0200
@@ -41,8 +41,6 @@
extern int cpu_add_sysdev_attr_group(struct attribute_group *attrs);
extern void cpu_remove_sysdev_attr_group(struct attribute_group *attrs);
-extern struct sysdev_attribute attr_sched_mc_power_savings;
-extern struct sysdev_attribute attr_sched_smt_power_savings;
extern int sched_create_sysfs_power_savings_entries(struct sysdev_class *cls);
#ifdef CONFIG_HOTPLUG_CPU
--- linux-2.6.22-rc6-mm1/kernel/sched.c.old 2007-07-05 16:11:34.0
+0200
+++ linux-2.6.22-rc6-mm1/kernel/sched.c 2007-07-05 16:30:40.0 +0200
@@ -6127,7 +6127,7 @@
}
#if defined(CONFIG_SCHED_MC) || defined(CONFIG_SCHED_SMT)
-int arch_reinit_sched_domains(void)
+static int arch_reinit_sched_domains(void)
{
int err;
@@ -6156,24 +6156,6 @@
return ret ? ret : count;
}
-int sched_create_sysfs_power_savings_entries(struct sysdev_class *cls)
-{
- int err = 0;
-
-#ifdef CONFIG_SCHED_SMT
- if (smt_capable())
- err = sysfs_create_file(cls-kset.kobj,
- attr_sched_smt_power_savings.attr);
-#endif
-#ifdef CONFIG_SCHED_MC
- if (!err mc_capable())
- err = sysfs_create_file(cls-kset.kobj,
- attr_sched_mc_power_savings.attr);
-#endif
- return err;
-}
-#endif
-
#ifdef CONFIG_SCHED_MC
static ssize_t sched_mc_power_savings_show(struct sys_device *dev, char *page)
{
@@ -6184,8 +6166,8 @@
{
return sched_power_savings_store(buf, count, 0);
}
-SYSDEV_ATTR(sched_mc_power_savings, 0644, sched_mc_power_savings_show,
- sched_mc_power_savings_store);
+static SYSDEV_ATTR(sched_mc_power_savings, 0644, sched_mc_power_savings_show,
+ sched_mc_power_savings_store);
#endif
#ifdef CONFIG_SCHED_SMT
@@ -6198,8 +6180,26 @@
{
return sched_power_savings_store(buf, count, 1);
}
-SYSDEV_ATTR(sched_smt_power_savings, 0644, sched_smt_power_savings_show,
- sched_smt_power_savings_store);
+static SYSDEV_ATTR(sched_smt_power_savings, 0644, sched_smt_power_savings_show,
+ sched_smt_power_savings_store);
+#endif
+
+int sched_create_sysfs_power_savings_entries(struct sysdev_class *cls)
+{
+ int err = 0;
+
+#ifdef CONFIG_SCHED_SMT
+ if (smt_capable())
+ err = sysfs_create_file(cls-kset.kobj,
+ attr_sched_smt_power_savings.attr);
+#endif
+#ifdef CONFIG_SCHED_MC
+ if (!err mc_capable())
+ err = sysfs_create_file(cls-kset.kobj,
+ attr_sched_mc_power_savings.attr);
+#endif
+ return err;
+}
#endif
/*
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/shmem.c: make 3 functions static
This patch makes three needlessly global functions static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch has been sent on:
- 6 Jul 2007
include/linux/mm.h | 15 ---
mm/shmem.c | 10 +-
2 files changed, 5 insertions(+), 20 deletions(-)
--- linux-2.6.22-rc6-mm1/include/linux/mm.h.old 2007-07-05 17:03:26.0
+0200
+++ linux-2.6.22-rc6-mm1/include/linux/mm.h 2007-07-05 17:03:45.0
+0200
@@ -707,9 +707,6 @@
extern void show_free_areas(void);
#ifdef CONFIG_SHMEM
-int shmem_set_policy(struct vm_area_struct *vma, struct mempolicy *new);
-struct mempolicy *shmem_get_policy(struct vm_area_struct *vma,
- unsigned long addr);
int shmem_lock(struct file *file, int lock, struct user_struct *user);
#else
static inline int shmem_lock(struct file *file, int lock,
@@ -717,18 +714,6 @@
{
return 0;
}
-
-static inline int shmem_set_policy(struct vm_area_struct *vma,
- struct mempolicy *new)
-{
- return 0;
-}
-
-static inline struct mempolicy *shmem_get_policy(struct vm_area_struct *vma,
-unsigned long addr)
-{
- return NULL;
-}
#endif
struct file *shmem_file_setup(char *name, loff_t size, unsigned long flags);
--- linux-2.6.22-rc6-mm1/mm/shmem.c.old 2007-07-05 17:04:00.0 +0200
+++ linux-2.6.22-rc6-mm1/mm/shmem.c 2007-07-05 17:06:27.0 +0200
@@ -1025,8 +1025,8 @@
return page;
}
-struct page *shmem_swapin(struct shmem_inode_info *info, swp_entry_t entry,
- unsigned long idx)
+static struct page *shmem_swapin(struct shmem_inode_info *info,
+swp_entry_t entry, unsigned long idx)
{
struct shared_policy *p = info-policy;
int i, num;
@@ -1335,14 +1335,14 @@
}
#ifdef CONFIG_NUMA
-int shmem_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
+static int shmem_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
struct inode *i = vma-vm_file-f_path.dentry-d_inode;
return mpol_set_shared_policy(SHMEM_I(i)-policy, vma, new);
}
-struct mempolicy *
-shmem_get_policy(struct vm_area_struct *vma, unsigned long addr)
+static struct mempolicy *shmem_get_policy(struct vm_area_struct *vma,
+ unsigned long addr)
{
struct inode *i = vma-vm_file-f_path.dentry-d_inode;
unsigned long idx;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/migrate.c: cleanups
This patch contains the following cleanups:
- every file should include the headers containing the prototypes for
its global functions
- make the needlessly global putback_lru_pages() static
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Christoph Lameter [EMAIL PROTECTED]
---
This patch has been sent on:
- 6 Jul 2007
include/linux/migrate.h |2 --
mm/migrate.c|3 ++-
2 files changed, 2 insertions(+), 3 deletions(-)
--- linux-2.6.22-rc6-mm1/include/linux/migrate.h.old2007-07-05
17:10:01.0 +0200
+++ linux-2.6.22-rc6-mm1/include/linux/migrate.h2007-07-05
17:10:10.0 +0200
@@ -26,7 +26,6 @@
}
extern int isolate_lru_page(struct page *p, struct list_head *pagelist);
-extern int putback_lru_pages(struct list_head *l);
extern int migrate_page(struct address_space *,
struct page *, struct page *);
extern int migrate_pages(struct list_head *l, new_page_t x, unsigned long);
@@ -44,7 +43,6 @@
static inline int isolate_lru_page(struct page *p, struct list_head *list)
{ return -ENOSYS; }
-static inline int putback_lru_pages(struct list_head *l) { return 0; }
static inline int migrate_pages(struct list_head *l, new_page_t x,
unsigned long private) { return -ENOSYS; }
--- linux-2.6.22-rc6-mm1/mm/migrate.c.old 2007-07-05 17:10:16.0
+0200
+++ linux-2.6.22-rc6-mm1/mm/migrate.c 2007-07-05 17:11:43.0 +0200
@@ -28,6 +28,7 @@
#include linux/mempolicy.h
#include linux/vmalloc.h
#include linux/security.h
+#include linux/syscalls.h
#include internal.h
@@ -101,7 +102,7 @@
*
* returns the number of pages put back.
*/
-int putback_lru_pages(struct list_head *l)
+static int putback_lru_pages(struct list_head *l)
{
struct page *page;
struct page *page2;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/mempolicy.c: cleanups
This patch contains the following cleanups:
- every file should include the headers containing the prototypes for
its global functions
- make the follosing needlessly global functions static:
- migrate_to_node()
- do_mbind()
- sp_alloc()
- mpol_rebind_policy()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Christoph Lameter [EMAIL PROTECTED]
---
This patch has been sent on:
- 6 Jul 2007
include/linux/mempolicy.h |6 --
mm/mempolicy.c| 25 -
2 files changed, 16 insertions(+), 15 deletions(-)
--- linux-2.6.22-rc6-mm1/include/linux/mempolicy.h.old 2007-07-05
17:16:55.0 +0200
+++ linux-2.6.22-rc6-mm1/include/linux/mempolicy.h 2007-07-05
17:17:05.0 +0200
@@ -143,7 +143,6 @@
extern void numa_default_policy(void);
extern void numa_policy_init(void);
-extern void mpol_rebind_policy(struct mempolicy *pol, const nodemask_t *new);
extern void mpol_rebind_task(struct task_struct *tsk,
const nodemask_t *new);
extern void mpol_rebind_mm(struct mm_struct *mm, nodemask_t *new);
@@ -225,11 +224,6 @@
{
}
-static inline void mpol_rebind_policy(struct mempolicy *pol,
- const nodemask_t *new)
-{
-}
-
static inline void mpol_rebind_task(struct task_struct *tsk,
const nodemask_t *new)
{
--- linux-2.6.22-rc6-mm1/mm/mempolicy.c.old 2007-07-05 17:14:16.0
+0200
+++ linux-2.6.22-rc6-mm1/mm/mempolicy.c 2007-07-05 17:22:17.0 +0200
@@ -89,6 +89,7 @@
#include linux/migrate.h
#include linux/rmap.h
#include linux/security.h
+#include linux/syscalls.h
#include asm/tlbflush.h
#include asm/uaccess.h
@@ -110,6 +111,9 @@
.policy = MPOL_DEFAULT,
};
+static void mpol_rebind_policy(struct mempolicy *pol,
+ const nodemask_t *newmask);
+
/* Do sanity checking on a policy */
static int mpol_check_policy(int mode, nodemask_t *nodes)
{
@@ -459,7 +463,7 @@
}
/* Set the process memory policy */
-long do_set_mempolicy(int mode, nodemask_t *nodes)
+static long do_set_mempolicy(int mode, nodemask_t *nodes)
{
struct mempolicy *new;
@@ -519,8 +523,8 @@
}
/* Retrieve NUMA policy */
-long do_get_mempolicy(int *policy, nodemask_t *nmask,
- unsigned long addr, unsigned long flags)
+static long do_get_mempolicy(int *policy, nodemask_t *nmask,
+unsigned long addr, unsigned long flags)
{
int err;
struct mm_struct *mm = current-mm;
@@ -601,7 +605,8 @@
* Migrate pages from one node to a target node.
* Returns error or the number of pages not migrated.
*/
-int migrate_to_node(struct mm_struct *mm, int source, int dest, int flags)
+static int migrate_to_node(struct mm_struct *mm, int source, int dest,
+ int flags)
{
nodemask_t nmask;
LIST_HEAD(pagelist);
@@ -732,8 +737,9 @@
}
#endif
-long do_mbind(unsigned long start, unsigned long len,
- unsigned long mode, nodemask_t *nmask, unsigned long flags)
+static long do_mbind(unsigned long start, unsigned long len,
+unsigned long mode, nodemask_t *nmask,
+unsigned long flags)
{
struct vm_area_struct *vma;
struct mm_struct *mm = current-mm;
@@ -1466,8 +1472,8 @@
kmem_cache_free(sn_cache, n);
}
-struct sp_node *
-sp_alloc(unsigned long start, unsigned long end, struct mempolicy *pol)
+static struct sp_node *sp_alloc(unsigned long start, unsigned long end,
+ struct mempolicy *pol)
{
struct sp_node *n = kmem_cache_alloc(sn_cache, GFP_KERNEL);
@@ -1645,7 +1651,8 @@
}
/* Migrate a policy to a different set of nodes */
-void mpol_rebind_policy(struct mempolicy *pol, const nodemask_t *newmask)
+static void mpol_rebind_policy(struct mempolicy *pol,
+ const nodemask_t *newmask)
{
nodemask_t *mpolmask;
nodemask_t tmp;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] mm/: remove unused exports
This patch removes the following unused EXPORT_SYMBOL's:
- migrate.c: migrate_page
- mmap.c: get_unmapped_area
- nommu.c: get_unmapped_area
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch has been sent on:
- 13 Jul 2007
mm/migrate.c |1 -
mm/mmap.c|2 --
mm/nommu.c |2 --
3 files changed, 5 deletions(-)
--- linux-2.6.22-rc6-mm1/mm/migrate.c.old 2007-07-12 03:15:05.0
+0200
+++ linux-2.6.22-rc6-mm1/mm/migrate.c 2007-07-12 03:15:15.0 +0200
@@ -426,7 +426,6 @@
migrate_page_copy(newpage, page);
return 0;
}
-EXPORT_SYMBOL(migrate_page);
#ifdef CONFIG_BLOCK
/*
--- linux-2.6.22-rc6-mm1/mm/mmap.c.old 2007-07-12 03:20:19.0 +0200
+++ linux-2.6.22-rc6-mm1/mm/mmap.c 2007-07-12 03:20:33.0 +0200
@@ -1408,8 +1408,6 @@
return addr;
}
-EXPORT_SYMBOL(get_unmapped_area);
-
/* Look up the first VMA which satisfies addr vm_end, NULL if none. */
struct vm_area_struct * find_vma(struct mm_struct * mm, unsigned long addr)
{
--- linux-2.6.22-rc6-mm1/mm/nommu.c.old 2007-07-12 03:20:41.0 +0200
+++ linux-2.6.22-rc6-mm1/mm/nommu.c 2007-07-12 03:20:57.0 +0200
@@ -1232,3 +1232,2 @@
}
-EXPORT_SYMBOL(get_unmapped_area);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] drivers/scsi/constants.c: make 2 functions static
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch has been sent on:
- 24 Mar 2007
drivers/scsi/constants.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.21-rc4-mm1/drivers/scsi/constants.c.old 2007-03-23
23:26:39.0 +0100
+++ linux-2.6.21-rc4-mm1/drivers/scsi/constants.c 2007-03-23
23:26:55.0 +0100
@@ -1235,7 +1235,7 @@
}
EXPORT_SYMBOL(scsi_print_sense_hdr);
-void
+static void
scsi_decode_sense_buffer(const unsigned char *sense_buffer, int sense_len,
struct scsi_sense_hdr *sshdr)
{
@@ -1258,7 +1258,7 @@
}
}
-void
+static void
scsi_decode_sense_extras(const unsigned char *sense_buffer, int sense_len,
struct scsi_sense_hdr *sshdr)
{
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] remove fs/jffs2/ioctl.c
fs/jffs2/ioctl.c is already for so long in the might be used later
state that I doubt it will ever be actually used...
And if it will ever be used, reverting this patch will be trivial.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
fs/jffs2/Makefile |2 +-
fs/jffs2/dir.c |1 -
fs/jffs2/file.c |1 -
fs/jffs2/ioctl.c| 21 -
fs/jffs2/os-linux.h |3 ---
5 files changed, 1 insertion(+), 27 deletions(-)
--- linux-2.6.14-rc5-mm1-full/fs/jffs2/os-linux.h.old 2005-11-01
20:28:24.0 +0100
+++ linux-2.6.14-rc5-mm1-full/fs/jffs2/os-linux.h 2005-11-01
20:28:31.0 +0100
@@ -147,9 +147,6 @@
int jffs2_fsync(struct file *, struct dentry *, int);
int jffs2_do_readpage_unlock (struct inode *inode, struct page *pg);
-/* ioctl.c */
-int jffs2_ioctl(struct inode *, struct file *, unsigned int, unsigned long);
-
/* symlink.c */
extern struct inode_operations jffs2_symlink_inode_operations;
--- linux-2.6.14-rc5-mm1-full/fs/jffs2/dir.c.old2005-11-01
20:28:39.0 +0100
+++ linux-2.6.14-rc5-mm1-full/fs/jffs2/dir.c2005-11-01 20:28:43.0
+0100
@@ -41,7 +41,6 @@
{
.read = generic_read_dir,
.readdir = jffs2_readdir,
- .ioctl =jffs2_ioctl,
.fsync =jffs2_fsync
};
--- linux-2.6.14-rc5-mm1-full/fs/jffs2/Makefile.old 2005-11-01
20:31:23.0 +0100
+++ linux-2.6.14-rc5-mm1-full/fs/jffs2/Makefile 2005-11-01 20:31:41.0
+0100
@@ -6,7 +6,7 @@
obj-$(CONFIG_JFFS2_FS) += jffs2.o
-jffs2-y:= compr.o dir.o file.o ioctl.o nodelist.o malloc.o
+jffs2-y:= compr.o dir.o file.o nodelist.o malloc.o
jffs2-y+= read.o nodemgmt.o readinode.o write.o scan.o gc.o
jffs2-y+= symlink.o build.o erase.o background.o fs.o writev.o
jffs2-y+= super.o
--- linux-2.6.19-rc6-mm1/fs/jffs2/file.c.old2006-11-26 05:55:29.0
+0100
+++ linux-2.6.19-rc6-mm1/fs/jffs2/file.c2006-11-26 05:53:06.0
+0100
@@ -46,5 +46,4 @@
.write =do_sync_write,
.aio_write =generic_file_aio_write,
- .ioctl =jffs2_ioctl,
.mmap = generic_file_readonly_mmap,
.fsync =jffs2_fsync,
--- linux-2.6.23-rc1-mm1/fs/jffs2/ioctl.c 2007-07-09 01:32:17.0
+0200
+++ /dev/null 2006-09-19 00:45:31.0 +0200
@@ -1,21 +0,0 @@
-/*
- * JFFS2 -- Journalling Flash File System, Version 2.
- *
- * Copyright © 2001-2007 Red Hat, Inc.
- *
- * Created by David Woodhouse [EMAIL PROTECTED]
- *
- * For licensing information, see the file 'LICENCE' in this directory.
- *
- */
-
-#include linux/fs.h
-
-int jffs2_ioctl(struct inode *inode, struct file *filp, unsigned int cmd,
- unsigned long arg)
-{
- /* Later, this will provide for lsattr.jffs2 and chattr.jffs2, which
- will include compression support etc. */
- return -ENOTTY;
-}
-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Reading a bad sector does not report failure as 'read error' but hangs PC with 'Machine Check Exception'
Last night I discovered a problem in my RAID5 array
and finally after a lot of tests I narrowed it down to
a bad sector on one of the hard disks and some goofy
kernels.
I just yesterday build a new PC using an existing
array of 5 disks in RAID 5. I did build the array with
only 4 out of 5 disks in the system but the rebuild
processes stopped over and over again apparently at
the same position. At last I found out that the
harddisk at the first SATA port had developed some bad
sectors which made the kernel stop completely when it
tried to read that sector with the following error on
the screen:
HARDWARE ERROR
CPU 0: Machine Check Exception: 4 Bank 4:
b2070f0f
TSC b7d4a144d0
This is not a software problem!
Run through mcelog --ascii to decode and contact your
hardware vendor
Kernel panic - not syncing: Machine check
Googling around made me check memory, upgrade the BIOS
and things like that but now i DO think that this IS a
software problem, which is in the linux kernel.
I was running the standard 2.6.20-16 kernel series
from Ubuntu Feisty Fawn (using the generic and server
built) and I built my own 2.6.22.1 but the problem
still persisted. When copying manually with dd_rescue
I was not able to copy past the bad sector or the MCE
error reappeared. Only when using the standard Ubuntu
Edgy Eft kernel (2.6.17-12-server) the problem went
away completely and the syslog was filled with normal
lines like:
Jul 28 22:58:26 mediaserver kernel: [ 6562.446868]
ata2: error=0x40 { UncorrectableError }
Jul 28 22:58:26 mediaserver kernel: [ 6562.446875] sd
1:0:0:0: SCSI error: return code = 0x802
Jul 28 22:58:26 mediaserver kernel: [ 6562.446880]
Additional sense: Unrecovered read error - auto
reallocate failed
Jul 28 22:58:26 mediaserver kernel: [ 6562.446887]
end_request: I/O error, dev sda, sector 205534870
So in the end I was able to copy my stuff off the bad
harddisk to a new disk (losing some bytes because of
my already dirty RAID5 array) but I do think this is a
kernel bug or at least strange behavior as an old
kernel is willing to continue operation on something
'minor' as a bad sector. In the end when I will start
scrubbing the drive array overnight a simple bad
sector on the array will take down the complete system
instead of just continuing with 1 faulty drive in the
array!
Some information about the hardware:
AMD Athlon 64 3000+
Asus A8N-E Deluxe motherboard
1 GB RAM
4 Seagate 7200.9 drives on the NVIDIA SATA controller
(sda ... sdd)
2 WD drives on the IDE controller (hda, hdc)
Running Feisty Fawn 64 bit Server edition
Faulty drive is /dev/sda and on thus on the first SATA
port. Changing this to a different port on the
motherboard gives the same lockup. There is also a SIL
3114 controller on the motherboard but I have not
tried to dd_rescue with the faulty drive on that
controller to see if it locks up the kernel.
Regards,
Hendrik van den Boogaard
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] include/linux/Kbuild: remove duplicate entries
This patch removes three headers from header-y that were also listed as unifdef-y. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- include/linux/Kbuild |3 --- 1 file changed, 3 deletions(-) --- linux-2.6.23-rc1-mm1/include/linux/Kbuild.old 2007-07-28 17:15:01.0 +0200 +++ linux-2.6.23-rc1-mm1/include/linux/Kbuild 2007-07-28 17:15:25.0 +0200 @@ -78,7 +78,6 @@ header-y += if_arcnet.h header-y += if_bonding.h header-y += if_cablemodem.h header-y += if_fc.h -header-y += if_fddi.h header-y += if.h header-y += if_hippi.h header-y += if_infiniband.h @@ -121,7 +120,6 @@ header-y += nl80211.h header-y += oom.h header-y += param.h header-y += pci_regs.h -header-y += personality.h header-y += pfkeyv2.h header-y += pg.h header-y += phantom.h @@ -159,7 +157,6 @@ header-y += video_decoder.h header-y += video_encoder.h header-y += videotext.h header-y += vt.h -header-y += wireless.h header-y += x25.h unifdef-y += acct.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/
2.6.23-rc1-mm1 compile error in function `acpi_pci_choose_state':
drivers/built-in.o: In function `acpi_pci_choose_state': pci-acpi.c:(.text+0xdccf): undefined reference to `acpi_pm_device_sleep_state' drivers/built-in.o: In function `pnpacpi_suspend': core.c:(.text+0x35a7c): undefined reference to `acpi_pm_device_sleep_state' Config file attached. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc1-mm1 # Sun Jul 29 09:14:48 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_NR_QUICK=2 CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CONTAINERS is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_CONTAINER_NS is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_TICK_ONESHOT is not set CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_NR_CPUS=2 CONFIG_PHYSICAL_ALIGN=0x20 # CONFIG_HOTPLUG_CPU is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y # CONFIG_X86_MCE_AMD is not set # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_START=0x20 # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y CONFIG_GENERIC_PENDING_IRQ=y # # Power management options # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set CONFIG_ACPI=y CONFIG_ACPI_PROCFS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_FAN is not set # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=y
Re: [Linux-usb-users] [REGRESSION] 2.6.23-rc1: uhci_hcd. irq 4: nobody cared
On Sun, 29 Jul 2007, Mark Hindley wrote: Hi, I have just tried 2.6.23-rc1 on my Acer Aspire 1350. On boot I get the following error as the uhci_hcd module is loaded: Jul 28 18:23:20 mercury kernel: ACPI: PCI Interrupt :00:10.0[A] - Link [LNKA] - GSI 4 (level, low) - IRQ 4 Jul 28 18:23:20 mercury kernel: uhci_hcd :00:10.0: UHCI Host Controller Jul 28 18:23:20 mercury kernel: uhci_hcd :00:10.0: new USB bus registered, assigned bus number 2 Jul 28 18:23:20 mercury kernel: irq 4: nobody cared (try booting with the irqpoll option) Did it work okay with older kernels? What does /proc/interrupts say in both 2.6.23-rc1 and in a working kernel? Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 7/29/07, Rene Herman [EMAIL PROTECTED] wrote: On 07/29/2007 04:58 PM, Ray Lee wrote: On 7/29/07, Rene Herman [EMAIL PROTECTED] wrote: Right over my head. Why does log-structure help anything? Log structured disk layouts allow for better placement of writeout, so that you cn eliminate most or all seeks. Seeks are the enemy when trying to get full disk bandwidth. google on log structured disk layout, or somesuch, for details. I understand what log structure is generally, but how does it help swapin? Look at the swap out case first. Right now, when swapping out the kernel places whatever it can wherever it can inside the swap space. The closer you are to filling your swap space, the more likely that those swapped out blocks will be all over place, rather than in one nice chunk. Contrast that with a log structured scheme, where the writeout happens to sequential spaces on the drive instead of scattered about. So, at some point when the system needs to fault those blocks that back in, it now has a linear span of sectors to read instead of asking the drive to bounce over twenty tracks for a hundred blocks. So, it eliminates the seeks. My laptop drive can read (huh, how odd, it got slower, need to retest in single user mode), hmm, let's go with about 25 MB/s. If we ask for a single block from each track, though, that'll drop to 4k * (1 second / seek time) which is about a megabyte a second if we're lucky enough to read from consecutive tracks. Even worse if it's not. Seeks are the enemy any time you need to hit the drive for anything, be it swapping or optimizing a database. Ray - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ttyS1: LSR safety check engaged! - misidentification?
Hi all, Ever since Kernel 2.6.21(rc) or so I'm plagued with this message, disabling my serial ports that have been working perfectly from 2.6.14 till that day (and are still doing so, given that I continuously remove the code from the source). Actually I cannot blame the code, but it seems that on both of my laptops the LSR is actually not readable. So, is there any plan to remove that piece of code again, or at least change it so it can be disabled conditionally? Regards, Christian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] unexport fb_prepare_logo
The logo code is not and should not be used by modules. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- --- linux-2.6.23-rc1-mm1/drivers/video/fbmem.c.old 2007-07-28 07:48:45.0 +0200 +++ linux-2.6.23-rc1-mm1/drivers/video/fbmem.c 2007-07-28 07:49:09.0 +0200 @@ -1653,7 +1653,6 @@ EXPORT_SYMBOL(register_framebuffer); EXPORT_SYMBOL(unregister_framebuffer); EXPORT_SYMBOL(num_registered_fb); EXPORT_SYMBOL(registered_fb); -EXPORT_SYMBOL(fb_prepare_logo); EXPORT_SYMBOL(fb_show_logo); EXPORT_SYMBOL(fb_set_var); EXPORT_SYMBOL(fb_blank); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
acpi_battery_add(): use-after-free
The Coverity checker spotted the following use-after-free in
acpi_battery_add():
-- snip --
...
static int acpi_battery_add(struct acpi_device *device)
{
...
if (result) {
acpi_battery_remove_fs(device);
kfree(battery);
}
mutex_unlock(battery-mutex);
...
-- snip --
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] drivers/scsi/scsi_error.c should #include scsi_transport_api.h
Every file should #include the headers containing the prototypes for its global functions (in this case for scsi_schedule_eh()). Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- --- linux-2.6.23-rc1-mm1/drivers/scsi/scsi_error.c.old 2007-07-28 17:10:48.0 +0200 +++ linux-2.6.23-rc1-mm1/drivers/scsi/scsi_error.c 2007-07-28 17:10:51.0 +0200 @@ -37,6 +37,7 @@ #include scsi_priv.h #include scsi_logging.h +#include scsi_transport_api.h #define SENSE_TIMEOUT (10*HZ) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] export v4l2_int_device_{,un}register
On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
...
Changes since 2.6.22-rc6-mm1:
...
git-dvb.patch
...
git trees
...
This patch fixes the following build error:
-- snip --
...
MODPOST 2135 modules
ERROR: v4l2_int_device_register [drivers/media/video/tcm825x.ko] undefined!
ERROR: v4l2_int_device_unregister [drivers/media/video/tcm825x.ko] undefined!
make[2]: *** [__modpost] Error 1
-- snip --
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/media/video/v4l2-int-device.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.23-rc1-mm1/drivers/media/video/v4l2-int-device.c.old
2007-07-27 14:03:33.0 +0200
+++ linux-2.6.23-rc1-mm1/drivers/media/video/v4l2-int-device.c 2007-07-27
14:04:03.0 +0200
@@ -101,6 +101,7 @@
return 0;
}
+EXPORT_SYMBOL_GPL(v4l2_int_device_register);
void v4l2_int_device_unregister(struct v4l2_int_device *d)
{
@@ -114,6 +115,7 @@
}
mutex_unlock(mutex);
}
+EXPORT_SYMBOL_GPL(v4l2_int_device_unregister);
/* Adapted from search_extable in extable.c. */
static v4l2_int_ioctl_func *find_ioctl(struct v4l2_int_slave *slave, int cmd,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] kernel/pid.c: remove unused exports
On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
...
Changes since 2.6.22-rc6-mm1:
...
+pid-namespaces-define-is_global_init-and-is_container_init.patch
...
pid namespaces
...
This patch removes two unused exports.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
kernel/pid.c |2 --
1 file changed, 2 deletions(-)
--- linux-2.6.23-rc1-mm1/kernel/pid.c.old 2007-07-28 07:31:12.0
+0200
+++ linux-2.6.23-rc1-mm1/kernel/pid.c 2007-07-28 07:31:23.0 +0200
@@ -69,13 +69,11 @@ struct pid_namespace init_pid_ns = {
.last_pid = 0,
.child_reaper = init_task
};
-EXPORT_SYMBOL(init_pid_ns);
int is_global_init(struct task_struct *tsk)
{
return tsk == init_pid_ns.child_reaper;
}
-EXPORT_SYMBOL(is_global_init);
/*
* Note: disable interrupts while the pidmap_lock is held as an
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] kernel/printk.c: make 2 variables static
On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
...
Changes since 2.6.22-rc6-mm1:
...
+slow-down-printk-during-boot.patch
...
Misc
...
This patch makes two needlessly global variables static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6.23-rc1-mm1/kernel/printk.c.old2007-07-26 22:40:09.0
+0200
+++ linux-2.6.23-rc1-mm1/kernel/printk.c2007-07-26 22:40:50.0
+0200
@@ -166,8 +166,8 @@
#ifdef CONFIG_BOOT_PRINTK_DELAY
-unsigned int boot_delay; /* msecs delay after each printk during bootup */
-unsigned long long printk_delay_msec; /* per msec, based on boot_delay */
+static unsigned int boot_delay; /* msecs delay after each printk during bootup
*/
+static unsigned long long printk_delay_msec; /* per msec, based on boot_delay
*/
static int __init boot_delay_setup(char *str)
{
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] drivers/usb/serial/sierra.c: make 3 functions static
This patch makes three needlessly global functions static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/usb/serial/sierra.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- linux-2.6.23-rc1-mm1/drivers/usb/serial/sierra.c.old2007-07-26
21:52:27.0 +0200
+++ linux-2.6.23-rc1-mm1/drivers/usb/serial/sierra.c2007-07-26
21:53:20.0 +0200
@@ -45,7 +45,7 @@
DEVICE_INSTALLER = 2,
};
-int sierra_set_power_state(struct usb_device *udev, __u16 swiState)
+static int sierra_set_power_state(struct usb_device *udev, __u16 swiState)
{
int result;
dev_dbg(udev-dev, %s, SET POWER STATE);
@@ -60,7 +60,7 @@
return result;
}
-int sierra_set_ms_mode(struct usb_device *udev, __u16 eSocMode)
+static int sierra_set_ms_mode(struct usb_device *udev, __u16 eSocMode)
{
int result;
dev_dbg(udev-dev, %s, DEVICE MODE SWITCH);
@@ -75,7 +75,8 @@
return result;
}
-int sierra_probe(struct usb_interface *iface, const struct usb_device_id *id)
+static int sierra_probe(struct usb_interface *iface,
+ const struct usb_device_id *id)
{
int result;
struct usb_device *udev;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How can we make page replacement smarter
Alan Cox wrote: Files are different. File content tends to be grouped in large related chunks, both logically in the file and on disk. Generally there is a lot more file data on a system than what fits in memory. Binary paging patterns don't always look like that unfortunately although I suspect we might want to be weighing towards paging out R/O file mapped pages earlier simply because they are bigger linear chunks A properly implemented use-once algorithm should be able to filter out the spatial locality of reference pages from the temporal locality of reference ones, though... -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 07/29/2007 04:58 PM, Ray Lee wrote: On 7/29/07, Rene Herman [EMAIL PROTECTED] wrote: On 07/29/2007 03:12 PM, Alan Cox wrote: More radically if anyone wants to do real researchy type work - how about log structured swap with a cleaner ? Right over my head. Why does log-structure help anything? Log structured disk layouts allow for better placement of writeout, so that you cn eliminate most or all seeks. Seeks are the enemy when trying to get full disk bandwidth. google on log structured disk layout, or somesuch, for details. I understand what log structure is generally, but how does it help swapin? 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/
[2.6 patch] make nf_ct_ipv6_skip_exthdr() static
nf_ct_ipv6_skip_exthdr() can now become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
include/net/netfilter/ipv6/nf_conntrack_ipv6.h |3 ---
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c |4 ++--
2 files changed, 2 insertions(+), 5 deletions(-)
--- linux-2.6.23-rc1-mm1/include/net/netfilter/ipv6/nf_conntrack_ipv6.h.old
2007-07-26 20:17:47.0 +0200
+++ linux-2.6.23-rc1-mm1/include/net/netfilter/ipv6/nf_conntrack_ipv6.h
2007-07-26 20:17:53.0 +0200
@@ -7,9 +7,6 @@
extern struct nf_conntrack_l4proto nf_conntrack_l4proto_udp6;
extern struct nf_conntrack_l4proto nf_conntrack_l4proto_icmpv6;
-extern int nf_ct_ipv6_skip_exthdr(const struct sk_buff *skb, int start,
- u8 *nexthdrp, int len);
-
extern int nf_ct_frag6_init(void);
extern void nf_ct_frag6_cleanup(void);
extern struct sk_buff *nf_ct_frag6_gather(struct sk_buff *skb);
--- linux-2.6.23-rc1-mm1/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c.old
2007-07-26 20:18:03.0 +0200
+++ linux-2.6.23-rc1-mm1/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c
2007-07-26 20:18:27.0 +0200
@@ -86,8 +86,8 @@
*- Note also special handling of AUTH header. Thanks to IPsec wizards.
*/
-int nf_ct_ipv6_skip_exthdr(const struct sk_buff *skb, int start, u8 *nexthdrp,
- int len)
+static int nf_ct_ipv6_skip_exthdr(const struct sk_buff *skb, int start,
+ u8 *nexthdrp, int len)
{
u8 nexthdr = *nexthdrp;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] make pktgen.c:get_ipsec_sa() static and non-inline
Non-static inline code usually doesn't makes sense.
In this case making is static and non-inline is the correct solution.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6.23-rc1-mm1/net/core/pktgen.c.old 2007-07-26 20:12:01.0
+0200
+++ linux-2.6.23-rc1-mm1/net/core/pktgen.c 2007-07-26 20:12:13.0
+0200
@@ -2156,8 +2156,7 @@
/* If there was already an IPSEC SA, we keep it as is, else
* we go look for it ...
*/
-inline
-void get_ipsec_sa(struct pktgen_dev *pkt_dev, int flow)
+static void get_ipsec_sa(struct pktgen_dev *pkt_dev, int flow)
{
struct xfrm_state *x = pkt_dev-flows[flow].x;
if (!x) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Reading a bad sector does not report failure as 'read error' but hangs PC with 'Machine Check Exception'
Hendrik . wrote: Last night I discovered a problem in my RAID5 array and finally after a lot of tests I narrowed it down to a bad sector on one of the hard disks and some goofy kernels. I just yesterday build a new PC using an existing array of 5 disks in RAID 5. I did build the array with only 4 out of 5 disks in the system but the rebuild processes stopped over and over again apparently at the same position. At last I found out that the harddisk at the first SATA port had developed some bad sectors which made the kernel stop completely when it tried to read that sector with the following error on the screen: HARDWARE ERROR CPU 0: Machine Check Exception: 4 Bank 4: b2070f0f TSC b7d4a144d0 This is not a software problem! Run through mcelog --ascii to decode and contact your hardware vendor Kernel panic - not syncing: Machine check You should run this through mcelog as it suggests and see what it shows. The kernel should be handling this properly, unless the drive problem is causing the controller to do something bad. Note that kernels 2.6.20 and later use ADMA mode on the nForce4 SATA controller whereas previous versions used it essentially like a PATA controller, so it is not surprising that the behavior is different. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 07/29/2007 05:20 PM, Ray Lee wrote: I understand what log structure is generally, but how does it help swapin? Look at the swap out case first. Right now, when swapping out the kernel places whatever it can wherever it can inside the swap space. The closer you are to filling your swap space, the more likely that those swapped out blocks will be all over place, rather than in one nice chunk. Contrast that with a log structured scheme, where the writeout happens to sequential spaces on the drive instead of scattered about. This seems to be now fixing the different problem of swap-space filling up. I'm quite willing to for now assume I've got plenty free. So, at some point when the system needs to fault those blocks that back in, it now has a linear span of sectors to read instead of asking the drive to bounce over twenty tracks for a hundred blocks. Moreover though -- what I know about log structure is that generally it optimises for write (swapout) and might make read (swapin) worse due to fragmentation that wouldn't happen with a regular fs structure. I guess that cleaner that Alan mentioned might be involved there -- I don't know how/what it would be doing. So, it eliminates the seeks. My laptop drive can read (huh, how odd, it got slower, need to retest in single user mode), hmm, let's go with about 25 MB/s. If we ask for a single block from each track, though, that'll drop to 4k * (1 second / seek time) which is about a megabyte a second if we're lucky enough to read from consecutive tracks. Even worse if it's not. Seeks are the enemy any time you need to hit the drive for anything, be it swapping or optimizing a database. I am very aware of the costs of seeks (on current magnetic media). 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: IRQF_DISABLED problem
David Miller wrote: From: Arjan van de Ven [EMAIL PROTECTED] Date: Fri, 27 Jul 2007 13:11:56 -0700 On Thu, 2007-07-26 at 16:17 -0700, Linus Torvalds wrote: On Thu, 26 Jul 2007, Linus Torvalds wrote: (c) one IRQF_DISABLED means that everything runs disabled. This is quite possibly buggy. (Side note: I'm not claiming this (or it's mirror image (d)) is really any better/worse than the current behaviour from a theoretical standpoint, but at least the current behaviour is _tested_, which makes it better in practice. So if we want to change this, I think we want to change it to something that is _obviously_ better). my personal preference would actually be to just never enable interrupts. It's the fastest solution obviously, the most friendly on stack and.. well simplest. Drivers no longer need to play some of the games that they do today. And while there is an argument that this may introduce a bit of latency... I'm not really convinced. If you have a chirpy serial controller with only a 1 byte fifo, even a quite reasonable interrupt handler can cause receive characters to get lost if you disable interrupts during the entirety of it's execution. It really is needed. And it's just plain rude to disable interrupts when it isn't absolutely necessary. Does anyone really use those serial controllers with no FIFO anymore? They've never been reliable for remotely high speeds.. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
Hi Eugene, Eugene Teo [2007-07-29 21:03 +0800]: Also, it is probably good to think how we can drop privileges while piping the core dump output to an external program. A malicious user can potentially use it as a possible backdoor since anything that is executed by |program will be executed with root privileges. It was my understanding that apport already did this. I haven't looked at apport yet, but are you talking about the userspace portion of apport or the kernel changes in the Ubuntu kernel? Similarly to Neil's patches, the Ubuntu kernel calls the userspace helper as root, too. Apport drops privileges to the target process as soon as possible (there are a few things it needs to do before, like opening an fd to the crash file in /var/crash/ if that is only writeable by root). Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
Re: 2.6.23-rc1-mm1 compile error in function `acpi_pci_choose_state':
Berck E. Nash wrote: drivers/built-in.o: In function `acpi_pci_choose_state': pci-acpi.c:(.text+0xdccf): undefined reference to `acpi_pm_device_sleep_state' drivers/built-in.o: In function `pnpacpi_suspend': core.c:(.text+0x35a7c): undefined reference to `acpi_pm_device_sleep_state' This patch should fix it : http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/hot-fixes/acpi-revert-d-states-branch-from-jun-17-to-jun-19-for-2623-rc1-mm1.patch - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nvidia installer DIW with 2.6.23-rc1
Jan Engelhardt wrote: On Jul 29 2007 10:57, Gene Heskett wrote: /tmp/selfgz9678/NVIDIA-Linux-x86-100.14.11-pkg1/usr/src/nv/nv.c: In function ‘nvidia_init_module’: /tmp/selfgz9678/NVIDIA-Linux-x86-100.14.11-pkg1/usr/src/nv/nv.c:1326: error: too many arguments to function ‘kmem_cache_create’ ... Fix the source until they have a fix. It seems to be just an extra argument to kmem_cache_create that got removed. Gene, the last argument to kmem_cache_create has been removed. It should be a simple matter to delete it from the caller, since it already was unsupported by the callees in previous kernels. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=20c2df83d25c6a95affe6157a4c9cac4cf5ffaac http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=mm/slab.c;h=bde271c001ba33ef1f61dd0f563f74d319cd1f0e;hp=c3feeaab387537ef00aa2085b4f54f6d7e4abca0 -- Stefan Richter -=-=-=== -=== ===-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 7/29/07, Rene Herman [EMAIL PROTECTED] wrote: On 07/29/2007 05:20 PM, Ray Lee wrote: This seems to be now fixing the different problem of swap-space filling up. I'm quite willing to for now assume I've got plenty free. I was trying to point out that currently, as an example, memory that is linear in a process' space could be fragmented on disk when swapped out. That's today. Under a log-structured scheme, one could set it up such that something that was linear in RAM could be swapped out linearly on the drive, minimizing seeks on writeout, which will naturally minimize seeks on swap in of that same data. So, at some point when the system needs to fault those blocks that back in, it now has a linear span of sectors to read instead of asking the drive to bounce over twenty tracks for a hundred blocks. Moreover though -- what I know about log structure is that generally it optimises for write (swapout) and might make read (swapin) worse due to fragmentation that wouldn't happen with a regular fs structure. It looks like I'm not doing a very good job of explaining this, I'm afraid. Suffice it to say that a log structured swap would give optimization options that we don't have today. I guess that cleaner that Alan mentioned might be involved there -- I don't know how/what it would be doing. Then you should google on `log structured filesystem (primer OR introduction)` and read a few of the links that pop up. You might find it interesting. I am very aware of the costs of seeks (on current magnetic media). Then perhaps you can just take it on faith -- log structured layouts are designed to help minimize seeks, read and write. Ray - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] make kernel/power/main.c:suspend_enter() static
On Sunday, 29 July 2007 16:57, Adrian Bunk wrote:
suspend_enter() can now become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
Acked-by: Rafael J. Wysocki [EMAIL PROTECTED]
kernel/power/main.c |2 +-
kernel/power/power.h |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.23-rc1-mm1/kernel/power/power.h.old 2007-07-26
14:49:29.0 +0200
+++ linux-2.6.23-rc1-mm1/kernel/power/power.h 2007-07-26 14:49:36.0
+0200
@@ -177,7 +177,6 @@
unsigned int, char *);
/* kernel/power/main.c */
-extern int suspend_enter(suspend_state_t state);
extern int suspend_devices_and_enter(suspend_state_t state);
extern struct blocking_notifier_head pm_chain_head;
--- linux-2.6.23-rc1-mm1/kernel/power/main.c.old 2007-07-26
14:49:44.0 +0200
+++ linux-2.6.23-rc1-mm1/kernel/power/main.c 2007-07-26 14:50:05.0
+0200
@@ -120,7 +120,7 @@
*
* This function should be called after devices have been suspended.
*/
-int suspend_enter(suspend_state_t state)
+static int suspend_enter(suspend_state_t state)
{
int error = 0;
--
Premature optimization is the root of all evil. - Donald Knuth
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [2.6 patch] make abituguru3_read_increment_offset() static
Adrian Bunk wrote:
abituguru3_read_increment_offset() can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Looks good, good catch.
Acked-by: Hans de Goede [EMAIL PROTECTED]
---
--- linux-2.6.23-rc1-mm1/drivers/hwmon/abituguru3.c.old 2007-07-26
08:56:33.0 +0200
+++ linux-2.6.23-rc1-mm1/drivers/hwmon/abituguru3.c 2007-07-26
08:57:00.0 +0200
@@ -691,8 +691,9 @@
/* Sensor settings are stored 1 byte per offset with the bytes
placed add consecutive offsets. */
-int abituguru3_read_increment_offset(struct abituguru3_data *data, u8 bank,
- u8 offset, u8 count, u8 *buf, int offset_count)
+static int abituguru3_read_increment_offset(struct abituguru3_data *data,
+ u8 bank, u8 offset, u8 count,
+ u8 *buf, int offset_count)
{
int i, x;
___
lm-sensors mailing list
[EMAIL PROTECTED]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: TCP SACK issue, hung connection, tcpdump included
On Sun, Jul 29, 2007 at 12:28:04PM +0300, Ilpo Järvinen wrote:
(...)
Limitation for 48 byte segments? You have to be kidding... :-) But yes,
it seems that one of the directions is dropping packets for some reason
though I would not assume MTU limitation... Or did you mean some other
segment?
No, I was talking about the 1448 bytes segments. But in fact I don't
believe it much because the SACKs are always retransmitted just afterwards.
Ah, but it's ACKed correctly right below it...:
[...snip...]
09:21:39.490740 IP SERVER.ssh CLIENT.50727: P 18200:18464(264) ack
2991
win 2728 nop,nop,timestamp 7692910 81727
09:21:39.490775 IP CLIENT.50727 SERVER.ssh: . ack 18464 win 378
nop,nop,timestamp 81755 7692910
09:21:39.860245 IP SERVER.ssh CLIENT.50727: . 12408:13856(1448) ack
2991
win 2728 nop,nop,timestamp 7693293 81749
...segment below snd_una arrived = snd_una remains 18464, receiver
generates a duplicate ACK:
09:21:39.860302 IP CLIENT.50727 SERVER.ssh: . ack 18464 win 378
nop,nop,timestamp 81847 7692910,nop,nop,sack sack 1
{12408:13856}
The cumulative ACK field of it covers _everything_ below 18464 (i.e., it
ACKs them), including the 1448 bytes in 12408:13856... In addition, the
SACK block is DSACK information [RFC2883] telling explicitly the address
of the received duplicate block. However, if this ACK doesn't reach the
SERVER TCP, RTO is triggered and the first not yet cumulatively ACKed
segment is retransmitted (I guess cumulative ACKs up to 12408 arrived
without problems to the SERVER):
Oh yes, you're damn right. I did not notice that the ACK was higher than
the SACK, I'm more used to read traces with absolute rather than relative
seq/acks.
So I agree, it is this ACK which is lost between client and server,
reinforcing the supposition about the location of the capture (client side).
[...snip...]
BTW, some information are missing. It would have been better if the trace
had been read with tcpdump -Svv. We would have got seq numbers and ttl.
Also, we do not know if there's a firewall between both sides. Sometimes,
some IDS identify attacks in crypted traffic and kill connections. It
might have been the case here, with the connection closed one way on an
intermediate firewall.
Yeah, firewall or some other issue, I'd say it's quite unlikely a bug in
TCP because behavior to both directions indicate client - sender
blackhole independently of each other...
It would also be possible that something stupid between both ends simply
drops packets with the SACK option set. Also something which sometimes
happen is that some firewalls automatically translate sequence numbers
but not necessarily SACK values, which could pretty well lead to this
packet being received but ignored on the server side.
I'm pretty sure that the same trace taken on the server side will reveal
the reason for the problem.
Willy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] ac97/ac97_codec.c: make 2 functions stacic
Hello,
Fix sparc64 warnings.
sound/pci/ac97/ac97_patch.h:86: warning: 'snd_ac97_restore_status' declared
'static' but never defined
sound/pci/ac97/ac97_patch.h:87: warning: 'snd_ac97_restore_iec958' declared
'static' but never defined
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
sound/pci/ac97/ac97_codec.c | 93823 - 93837 (+14 bytes)
sound/pci/ac97/ac97_codec.o | 341841 - 341841 (0 bytes)
sound/pci/ac97/ac97_codec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.23-rc1-mm1-a/sound/pci/ac97/ac97_codec.c 2007-07-26
13:07:39.0 +0200
+++ linux-2.6.23-rc1-mm1-b/sound/pci/ac97/ac97_codec.c 2007-07-29
17:53:23.0 +0200
@@ -2436,7 +2436,7 @@ EXPORT_SYMBOL(snd_ac97_suspend);
/*
* restore ac97 status
*/
-void snd_ac97_restore_status(struct snd_ac97 *ac97)
+static void snd_ac97_restore_status(struct snd_ac97 *ac97)
{
int i;
@@ -2457,7 +2457,7 @@ void snd_ac97_restore_status(struct snd_
/*
* restore IEC958 status
*/
-void snd_ac97_restore_iec958(struct snd_ac97 *ac97)
+static void snd_ac97_restore_iec958(struct snd_ac97 *ac97)
{
if (ac97-ext_id AC97_EI_SPDIF) {
if (ac97-regs[AC97_EXTENDED_STATUS] AC97_EA_SPDIF) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 compilation for non CONFIG_HOTPLUG case
Hello.
Niklaus Giger wrote:
Fixes compilation issues for embedded boards which do not support HOTPLUG
Signed-off-by: Niklaus Giger [EMAIL PROTECTED]
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 3599ab2..a09bfc8 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -24,7 +24,9 @@
#include base.h
#include power/power.h
+#ifdef CONFIG_HOTPLUG
extern const char *kobject_actions[];
+#endif
No need for #ifdef around extern declarations.
int (*platform_notify)(struct device * dev) = NULL;
int (*platform_notify_remove)(struct device * dev) = NULL;
@@ -306,11 +308,13 @@ static ssize_t store_uevent(struct device *dev, struct
device_attribute *attr,
const char *buf, size_t count)
{
size_t len = count;
+#ifdef CONFIG_HOTPLUG
enum kobject_action action;
-
+#endif
Please don't remove newline between the declaration block and the code.
if (len buf[len-1] == '\n')
len--;
+#ifdef CONFIG_HOTPLUG
for (action = 0; action KOBJ_MAX; action++) {
if (strncmp(kobject_actions[action], buf, len) != 0)
continue;
@@ -319,11 +323,14 @@ static ssize_t store_uevent(struct device *dev, struct
device_attribute *attr,
kobject_uevent(dev-kobj, action);
goto out;
Grr... cleanup style abuse -- ISO a mere return they used goto. :-/
}
+#endif
dev_err(dev, uevent: unsupported action-string; this will
be ignored in a future kernel version\n);
kobject_uevent(dev-kobj, KOBJ_ADD);
+#ifdef CONFIG_HOTPLUG
out:
+#endif
Well, #ifdef'ing out label seems too much.
return count;
}
WBR, Sergei
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Reading a bad sector does not report failure as 'read error' but hangs PC with 'Machine Check Exception'
HARDWARE ERROR CPU 0: Machine Check Exception: 4 Bank 4: b2070f0f TSC b7d4a144d0 This is not a software problem! Run through mcelog --ascii to decode and contact your hardware vendor Kernel panic - not syncing: Machine check You should run this through mcelog as it suggests and see what it shows. The kernel should be handling this properly, unless the drive problem is causing the controller to do something bad. Note that kernels 2.6.20 and later use ADMA mode on the nForce4 SATA controller whereas previous versions used it essentially like a PATA controller, so it is not surprising that the behavior is different. How can I do this? I have installed mcelog but I cannot run it after the MCE error because the whole PC hangs. If I try it after a reboot with 'mcelog --k8 --ascii' or whatever parameter, there is no output at all. If I try to redirect the output to the syslog, nothing is in there because the computer stopped working and did not save the log anymore. Isn't it strange to say that the controller does something bad if there is just a bad sector on the drive that is reported and handled correctly in an older kernel (I have confirmed a bad sector on the drive using the Seatools software from Seagate)? In my opinion a kernel should not stop responding at all with a bad sector on the disk. I cannot change the controller's behavior and did all the updates there are to make in function, but the problem is introduced using the newer kernel series. Perhaps nobody has tried accessing a bad SATA drive before, to simulate such an error? If it helps I could try a different type of motherboard to see what happens there? (Asus M2NPV-VM) Regards, Hendrik Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TCP SACK issue, hung connection, tcpdump included
On Sun, 29 Jul 2007, Willy Tarreau wrote: On Sun, Jul 29, 2007 at 12:28:04PM +0300, Ilpo Järvinen wrote: [...snip...] BTW, some information are missing. It would have been better if the trace had been read with tcpdump -Svv. We would have got seq numbers and ttl. Also, we do not know if there's a firewall between both sides. Sometimes, some IDS identify attacks in crypted traffic and kill connections. It might have been the case here, with the connection closed one way on an intermediate firewall. Yeah, firewall or some other issue, I'd say it's quite unlikely a bug in TCP because behavior to both directions indicate client - sender blackhole independently of each other... It would also be possible that something stupid between both ends simply drops packets with the SACK option set. Also something which sometimes happen is that some firewalls automatically translate sequence numbers but not necessarily SACK values, which could pretty well lead to this packet being received but ignored on the server side. ...One can toggle those off with /proc/sys/net/ipv4/tcp_dsack but I suspect DSACKs are not the cause because these retransmissions neither are making it through (there are many of them also earlier in the log, just quoted the easiest ones :-) ): 09:36:44.335591 IP CLIENT.50727 SERVER.ssh: P 2991:3039(48) ack 18464 win 378 nop,nop,timestamp 800227942 7692910 09:38:44.351950 IP CLIENT.50727 SERVER.ssh: P 2991:3039(48) ack 18464 win 378 nop,nop,timestamp 800257942 7692910 09:40:44.368172 IP CLIENT.50727 SERVER.ssh: P 2991:3039(48) ack 18464 win 378 nop,nop,timestamp 800287943 7692910 ...there are no SACKs involved in them, yet no cumulative ACK ever arrives from SERVER... -- i.
Re: [Linux-usb-users] [REGRESSION] 2.6.23-rc1: uhci_hcd. irq 4: nobody cared
On Sun, Jul 29, 2007 at 11:19:47AM -0400, Alan Stern wrote: On Sun, 29 Jul 2007, Mark Hindley wrote: Hi, I have just tried 2.6.23-rc1 on my Acer Aspire 1350. On boot I get the following error as the uhci_hcd module is loaded: Jul 28 18:23:20 mercury kernel: ACPI: PCI Interrupt :00:10.0[A] - Link [LNKA] - GSI 4 (level, low) - IRQ 4 Jul 28 18:23:20 mercury kernel: uhci_hcd :00:10.0: UHCI Host Controller Jul 28 18:23:20 mercury kernel: uhci_hcd :00:10.0: new USB bus registered, assigned bus number 2 Jul 28 18:23:20 mercury kernel: irq 4: nobody cared (try booting with the irqpoll option) Did it work okay with older kernels? What does /proc/interrupts say in both 2.6.23-rc1 and in a working kernel? No boot error with 2.6.22.1. On 2.6.22.1: CPU0 0: 12312XT-PIC-XTtimer 1:286XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 4:434XT-PIC-XTuhci_hcd:usb2, [EMAIL PROTECTED]::01:00.0 5: 2000XT-PIC-XTyenta, uhci_hcd:usb3, wifi0 6: 3XT-PIC-XTfloppy 7: 3XT-PIC-XTparport0 8: 4XT-PIC-XTrtc 9: 0XT-PIC-XTuhci_hcd:usb4, VIA82XX-MODEM, VIA8233 10:843XT-PIC-XTacpi 11: 0XT-PIC-XTehci_hcd:usb1 12:123XT-PIC-XTi8042 14: 10951XT-PIC-XTide0 15: 53XT-PIC-XTide1 NMI:770 LOC: 120091 ERR: 0 MIS: 0 On 2.6.23-rc1: CPU0 0: 8616XT-PIC-XTtimer 1:183XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 4: 8233XT-PIC-XTuhci_hcd:usb1, [EMAIL PROTECTED]::01:00.0 5: 4948XT-PIC-XTuhci_hcd:usb2, yenta, wifi0 6: 3XT-PIC-XTfloppy 7: 22XT-PIC-XTparport0 8: 4XT-PIC-XTrtc 9: 0XT-PIC-XTuhci_hcd:usb3, VIA82XX-MODEM, VIA8233 10:854XT-PIC-XTacpi 11: 0XT-PIC-XTehci_hcd:usb4 12:123XT-PIC-XTi8042 14: 12202XT-PIC-XTide0 15: 53XT-PIC-XTide1 NMI:809 LOC: 150284 ERR: 1 MIS: 0 Mark - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/bluetooth/hci_ldisc.c: fix possible NULL dereferences
Hi Eugene,
Commit 22ad42033b7d2b3d7928fba9f89d1c7f8a3c9581 did not completely fix all
the possible NULL dereferences. Besides hci_uart_close(), we also need to
make sure that hdev is valid before calling hci_{unregister,free}_dev().
I don't see any issue. Without HCI_UART_PROTO_SET, the hdev will never
be registered. So no need to protect it twice.
Regards
Marcel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] kernel/printk.c: make 2 variables static
On Sun, 29 Jul 2007 16:59:18 +0200 Adrian Bunk wrote:
On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
...
Changes since 2.6.22-rc6-mm1:
...
+slow-down-printk-during-boot.patch
...
Misc
...
This patch makes two needlessly global variables static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Aye. Thanks.
---
--- linux-2.6.23-rc1-mm1/kernel/printk.c.old 2007-07-26 22:40:09.0
+0200
+++ linux-2.6.23-rc1-mm1/kernel/printk.c 2007-07-26 22:40:50.0
+0200
@@ -166,8 +166,8 @@
#ifdef CONFIG_BOOT_PRINTK_DELAY
-unsigned int boot_delay; /* msecs delay after each printk during bootup */
-unsigned long long printk_delay_msec; /* per msec, based on boot_delay */
+static unsigned int boot_delay; /* msecs delay after each printk during
bootup */
+static unsigned long long printk_delay_msec; /* per msec, based on
boot_delay */
static int __init boot_delay_setup(char *str)
{
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] unexport pm_power_off_prepare
On Sunday, 29 July 2007 16:59, Adrian Bunk wrote:
This patch removes the unused EXPORT_SYMBOL(pm_power_off_prepare).
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
--- linux-2.6.23-rc1-mm1/kernel/sys.c.old 2007-07-28 07:38:45.0
+0200
+++ linux-2.6.23-rc1-mm1/kernel/sys.c 2007-07-28 07:38:59.0 +0200
@@ -104,7 +104,6 @@ EXPORT_SYMBOL(cad_pid);
*/
void (*pm_power_off_prepare)(void);
-EXPORT_SYMBOL(pm_power_off_prepare);
static int set_one_prio(struct task_struct *p, int niceval, int error)
{
--
Premature optimization is the root of all evil. - Donald Knuth
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/base/power/: make 2 functions static
On Sunday, 29 July 2007 16:56, Adrian Bunk wrote:
suspend_device() and resume_device() can now become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
Acked-by: Rafael J. Wysocki [EMAIL PROTECTED]
drivers/base/power/power.h |6 --
drivers/base/power/resume.c |2 +-
drivers/base/power/suspend.c |2 +-
3 files changed, 2 insertions(+), 8 deletions(-)
--- linux-2.6.23-rc1-mm1/drivers/base/power/power.h.old 2007-07-26
05:14:12.0 +0200
+++ linux-2.6.23-rc1-mm1/drivers/base/power/power.h 2007-07-26
05:15:49.0 +0200
@@ -55,12 +55,6 @@
extern void dpm_resume(void);
extern void dpm_power_up(void);
-extern int resume_device(struct device *);
-
-/*
- * suspend.c
- */
-extern int suspend_device(struct device *, pm_message_t);
#else /* CONFIG_PM */
--- linux-2.6.23-rc1-mm1/drivers/base/power/resume.c.old 2007-07-26
05:14:28.0 +0200
+++ linux-2.6.23-rc1-mm1/drivers/base/power/resume.c 2007-07-26
05:14:39.0 +0200
@@ -20,7 +20,7 @@
*
*/
-int resume_device(struct device * dev)
+static int resume_device(struct device * dev)
{
int error = 0;
--- linux-2.6.23-rc1-mm1/drivers/base/power/suspend.c.old 2007-07-26
05:16:00.0 +0200
+++ linux-2.6.23-rc1-mm1/drivers/base/power/suspend.c 2007-07-26
05:16:17.0 +0200
@@ -54,7 +54,7 @@
* @state: Power state device is entering.
*/
-int suspend_device(struct device * dev, pm_message_t state)
+static int suspend_device(struct device * dev, pm_message_t state)
{
int error = 0;
--
Premature optimization is the root of all evil. - Donald Knuth
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
checkpatch.pl false positive on exported pointers
WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable #563: FILE: drivers/scsi/iioc34x/iioc34x_sas.c:58: +EXPORT_SYMBOL(iioc34x_transport_template); drivers/scsi/iioc34x/iioc34x_sas.c:57 struct scsi_transport_template *iioc34x_transport_template; EXPORT_SYMBOL(iioc34x_transport_template); I suspect the script wants: EXPORT_SYMBOL(*iioc34x_transport_template); ...but that does not compile. Thanks, Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 07/29/2007 06:04 PM, Ray Lee wrote: I am very aware of the costs of seeks (on current magnetic media). Then perhaps you can just take it on faith -- log structured layouts are designed to help minimize seeks, read and write. I am particularly bad at faith. Let's take that stupid program that I posted: http://lkml.org/lkml/2007/7/25/85 You push it out before you hit enter, it's written out to swap, at whatever speed. How should it be layed out so that it's swapped in most efficiently after hitting enter? Reading bigger chunks would quite obviously help, but the layout? The program is not a real-world issue and if you do not consider it a useful boundary condition either (okay I guess), how would log structured swap help if I just assume I have plenty of free swap to begin with? 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: [PATCH 01/10] Task Containers(V11): Basic task container framework
On 7/26/07, YAMAMOTO Takashi [EMAIL PROTECTED] wrote:
+Other fields in the container_subsys object include:
+- hierarchy: an index indicating which hierarchy, if any, this
+ subsystem is currently attached to. If this is -1, then the
+ subsystem is not attached to any hierarchy, and all tasks should be
+ considered to be members of the subsystem's top_container. It should
+ be initialized to -1.
stale info?
Yes, I think so. I really need to do a proper pass over
Documentation/containers.txt one more time following a bunch of recent
changes.
+struct container {
+ struct containerfs_root *root;
+ struct container *top_container;
+};
can cont-top_container be different from than cont-root.top_container?
No, I guess it can't. And there are only a couple of places using
cont-top_container now, so I should probably remove it.
Thanks,
Paul
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal
Hi Andrew,
poll() returns -EINTR if a signal is pending.
EINTR is a bad choice: it means that poll returns to user space if the
task is stopped by SIGSTOP/SIGCONT or by the freezer.
select() and ppoll() both use ERESTARTNOHAND, this avoids a return to
user space for signals that are handled by the kernel.
The patch switches poll() to ERESTARTNOHAND.
Tested with FC6. Patch against 2.6.23-rc1-mm1.
Signed-off-by: Manfred Spraul [EMAIL PROTECTED]
--- 2.6/fs/select.c 2007-07-28 20:31:51.0 +0200
+++ build-2.6/fs/select.c 2007-07-28 21:21:52.0 +0200
@@ -621,7 +621,7 @@ static int do_poll(unsigned int nfds, s
if (!count) {
count = wait-error;
if (signal_pending(current))
- count = -EINTR;
+ count = -ERESTARTNOHAND;
}
if (count || !*timeout)
break;
@@ -774,7 +774,7 @@ asmlinkage long sys_ppoll(struct pollfd
ret = do_sys_poll(ufds, nfds, timeout);
/* We can restart this syscall, usually */
- if (ret == -EINTR) {
+ if (ret == -ERESTARTNOHAND) {
/*
* Don't restore the signal mask yet. Let do_signal() deliver
* the signal on the way back to userspace, before the signal
@@ -785,7 +785,6 @@ asmlinkage long sys_ppoll(struct pollfd
sizeof(sigsaved));
set_thread_flag(TIF_RESTORE_SIGMASK);
}
- ret = -ERESTARTNOHAND;
} else if (sigmask)
sigprocmask(SIG_SETMASK, sigsaved, NULL);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Kasper Sandberg [EMAIL PROTECTED] wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. [...] here's an update: checking whether Wine could be a factor in your problem i just tested latest CFS against latest SD with a 3D game running under Wine: v2.6.22-ck1 versus v2.6.22-cfsv19 (to get the most comparable kernel), using Quake 3 Arena Demo under Wine (0.9.41). Here are the results in a pretty graph: http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg or, in text: 2.6.22-ck1 2.6.22-cfs-v19 quake + 0 loops | 41 fpsquake + 0 loops | 41 fps quake + 1 loop | 3 fpsquake + 1 loop | 41 fps quake + 2 loops | 2 fpsquake + 2 loops | 32 fps quake + 3 loops | 1 fpsquake + 3 loops | 24 fps quake + 4 loops | 0 fpsquake + 4 loops | 20 fps quake + 5 loops | 0 fpsquake + 5 loops | 16 fps Quake3-under-Wine behavior under SD/-ck: framerate breaks down massively during any kind of load. The game is completely unusable with 1 CPU loop running already! Quake3-under-Wine behavior under CFS: framerate goes down gently with load, gameplay remains smooth. Framerate is still pretty acceptable and the game is playable even with a 500% CPU overload. The graph looks good and the framerate reduction goes roughly along the expected 1/n 'fairness curve' - so it all looks pretty healthy. [Note: quake3 keeps its fully 41 fps even with 1 competing loop running on the CPU due to sleeper fairness.] [ i've re-tested this using other SD and ck versions and other CFS versions such as v2.6.23-rc1 and the results are the same. To get the fps result i started a simple game scene: Single Player / Q3DM1 / I Can Win, turned on the fps display of Quake3, and did not move the player at all, just looked at the framerate that is displayed. (i also tried other scenes and other gameplay sections and they all behave consistently with the above results.) The system was otherwise completely idle. While i trust these numbers take them with a grain of salt, i'm obviously not neutral in this thing :-) ] so Kasper, i'll definitely need your help in tracking down your 3D smoothness problem under CFS. I have the feeling that it could be some odd factor that only hits your system, and once we've tracked that down there will be a simple solution that does not affect the totality of the scheduler. So far only you have reported any 3D game smoothness problem against recent CFS versions. (all 3D feedback has been positive, and that includes a number of gamers as well. Most of the 3D smoothness problems were fixed in CFS v13..v15 and it has not been reported to have regressed since then.) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix compilation for non CONFIG_HOTPLUG case
This problem is already fixed in -mm . http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/broken-out/gregkh-driver-kobject-fix-link-error-when-config_hotplug-is-disabled.patch Regards, Gabriel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 7/29/07, Rene Herman [EMAIL PROTECTED] wrote: On 07/29/2007 06:04 PM, Ray Lee wrote: I am very aware of the costs of seeks (on current magnetic media). Then perhaps you can just take it on faith -- log structured layouts are designed to help minimize seeks, read and write. I am particularly bad at faith. Let's take that stupid program that I posted: You only think you are :-). I'm sure there are lots of things you have faith in. Gravity, for example :-). The program is not a real-world issue and if you do not consider it a useful boundary condition either (okay I guess), how would log structured swap help if I just assume I have plenty of free swap to begin with? Is that generally the case on your systems? Every linux system I've run, regardless of RAM, has always pushed things out to swap. And once there's something already in swap, you now have a packing problem when you want to swap something else out. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: commit 7e92b4fc34 - x86, serial: convert legacy COM ports to platform devices - broke my serial console
On Jul 27, 2007, at 17:05:30, Jeff Garzik wrote: Bjorn Helgaas wrote: And couldn't we use udev to associate a fixed name with a MAC address? Then the user could use the same persistent name, regardless of the order in which the driver found the devices. I don't know about udev, but people are definitely using fixed names based on MAC address for ethernet devices already: nameif(8) and /etc/mactab, iftab(5) and ifrename(8). I was doing that for a while, but now Debian and RedHat and most other modern distros have a udev rules file called something like: / etc/udev/rules.d/z30-persistent-net-generator.rules Under Debian it generates a file /etc/udev/rules.d/z25-persistent-net.rules which automatically renames net devices based on their mac address. The persistent-net-generator takes the current name and MAC and stuffs them in an appropriate file. So really once you've booted with the network card in, all you have to do is modify the persistent- net.rules file to change the name of your NIC and rerun udevtrigger. I've gotten into the habit of using descriptive names lately (7 chars is the most that ifconfig will show without truncating, and it seems to be unable to properly sort/display/operate-on longer ones). For example, my Debian firewall box has: world: Connection to the cable modem switch: Connection to my VLAN-capable switch main0: Primary VLAN on my switch. main1: A local gigabit switch for connections to a couple other systems main: A bridge of main0 and main1 which is used as the primary LAN interface hbeat: Dedicated NIC for Linux-HA (HeartBeat) debian: A Debian netinst net-boot VLAN with support for PXE and OpenFirmware radius: A VLAN used by my wireless AP for radius traffic wifi: A VLAN used for private wireless traffic Most of those interfaces are virtual and created by custom /etc/ network/if-pre-up.d/* scripts, but you can see the world, switch, main1, and hbeat interfaces are actual physical interfaces. Such naming (with appropriate comments in /etc/network/ interfaces) vastly eases the management of a box with a shitton of interfaces. The fact that ifconfig has some outstanding bugs with big interface names is mostly irrelevant since I use the iproute2 tool (ip) to do almost all administration. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TCP SACK issue, hung connection, tcpdump included
This is a reproducible problem (would take me between 30 mins and a day
to reproduce it). Please feel free to provide me with tcpdump options
to be sure I include to get the information you need.
I've been informed there is no firewall at all, the only firewalling
that takes place is the local Linux netfilter, I've never audited the
kit at the SERVER end to know for sure.
I have run a tcpdump from the server side before now (not for the
tcpdump I enclosed) when try to diagnose the problem in the first place
and the triplet of packets:
09:28:11.331256 IP SERVER.ssh CLIENT.50727: . 12408:13856(1448) ack 2991 win 2728
nop,nop,timestamp 8084763 81749
09:28:11.331354 IP CLIENT.50727 SERVER.ssh: . ack 18464 win 378
nop,nop,timestamp 800099704 7692910,nop,nop,sack sack 1 {12408:13856}
09:28:44.286495 IP CLIENT.50727 SERVER.ssh: P 2991:3039(48) ack 18464 win 378
nop,nop,timestamp 800107942 7692910
That keeps repeating from that point in was observable at both sides.
No checksum errors have ever been shown on any tcpdump I saw.
The dump I posted was the first dump I was able to reliably reproduce
(observing from the CLIENT end), I'm pretty sure given some time
tomorrow I could create you 2 dumps of the same session (the view from
each end). Looking a little more at the dump today I see that at time
index 09:21:39.860245 to server sends data from seq 12408:13856 again.
Here is a snippet that backs up a little more around the time the
trouble starts, as SERVER send sequence 12408 seems to be the problem
maybe I need to illustrate what happened when that sequence was first sent.
Excuse my understanding if it seems a bit limited. SACK is only used
when segments are dropped and from inspecting the dump I can't spot
where a lost segment occurs. My main question is why does the CLIENT
ack data 12408:13856 and beyond all the way up to 18464 (@
09:21:39.490775) and then start to SACK {12408:13856} (@ 09:21:39.860302) ?
Does this mean the client is the buggy end for going back on data it has
already acked cleanly, that would be my interpretation of events.
Enclosed should be a tcpdump with -vvS of the same session as before
observing from the client side.
I hope I've answered all the points raised in this thread.
Darryl
09:12:13.444999 IP (tos 0x0, ttl 64, id 56883, offset 0, flags [DF], proto 6,
length: 60) CLIENT.50727 SERVER.ssh: S [tcp sum ok] 2919512080:2919512080(0)
win 5840 mss 1460,sackOK,timestamp 799860259 0,nop,wscale 7
09:12:13.535643 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto 6,
length: 60) SERVER.ssh CLIENT.50727: S [tcp sum ok] 492909547:492909547(0)
ack 2919512081 win 5792 mss 1460,sackOK,timestamp 7126976 799860259,nop,wscale
2
09:12:13.535717 IP (tos 0x0, ttl 64, id 56884, offset 0, flags [DF], proto 6,
length: 52) CLIENT.50727 SERVER.ssh: . [tcp sum ok] 2919512081:2919512081(0)
ack 492909548 win 46 nop,nop,timestamp 799860282 7126976
09:12:13.665481 IP (tos 0x0, ttl 50, id 62454, offset 0, flags [DF], proto 6,
length: 75) SERVER.ssh CLIENT.50727: P [tcp sum ok] 492909548:492909571(23)
ack 2919512081 win 1448 nop,nop,timestamp 7127074 799860282
09:12:13.665895 IP (tos 0x0, ttl 64, id 56885, offset 0, flags [DF], proto 6,
length: 52) CLIENT.50727 SERVER.ssh: . [tcp sum ok] 2919512081:2919512081(0)
ack 492909571 win 46 nop,nop,timestamp 799860314 7127074
09:12:13.666044 IP (tos 0x0, ttl 64, id 56886, offset 0, flags [DF], proto 6,
length: 74) CLIENT.50727 SERVER.ssh: P [tcp sum ok] 2919512081:2919512103(22)
ack 492909571 win 46 nop,nop,timestamp 799860314 7127074
09:12:13.776318 IP (tos 0x0, ttl 50, id 62456, offset 0, flags [DF], proto 6,
length: 52) SERVER.ssh CLIENT.50727: . [tcp sum ok] 492909571:492909571(0)
ack 2919512103 win 1448 nop,nop,timestamp 7127216 799860314
09:12:13.776438 IP (tos 0x0, ttl 64, id 56887, offset 0, flags [DF], proto 6,
length: 692) CLIENT.50727 SERVER.ssh: P [tcp sum ok]
2919512103:2919512743(640) ack 492909571 win 46 nop,nop,timestamp 799860342
7127216
09:12:13.780319 IP (tos 0x0, ttl 50, id 62458, offset 0, flags [DF], proto 6,
length: 692) SERVER.ssh CLIENT.50727: P [tcp sum ok] 492909571:492910211(640)
ack 2919512103 win 1448 nop,nop,timestamp 7127218 799860314
09:12:13.823098 IP (tos 0x0, ttl 64, id 56888, offset 0, flags [DF], proto 6,
length: 52) CLIENT.50727 SERVER.ssh: . [tcp sum ok] 2919512743:2919512743(0)
ack 492910211 win 56 nop,nop,timestamp 799860353 7127218
09:12:13.927103 IP (tos 0x0, ttl 50, id 62460, offset 0, flags [DF], proto 6,
length: 52) SERVER.ssh CLIENT.50727: . [tcp sum ok] 492910211:492910211(0)
ack 2919512743 win 1768 nop,nop,timestamp 7127367 799860342
09:12:13.927174 IP (tos 0x0, ttl 64, id 56889, offset 0, flags [DF], proto 6,
length: 76) CLIENT.50727 SERVER.ssh: P [tcp sum ok] 2919512743:2919512767(24)
ack 492910211 win 56 nop,nop,timestamp 799860379 7127367
09:12:14.016977 IP (tos 0x0, ttl 50, id 62462, offset 0, flags
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 07/29/2007 07:19 PM, Ray Lee wrote: The program is not a real-world issue and if you do not consider it a useful boundary condition either (okay I guess), how would log structured swap help if I just assume I have plenty of free swap to begin with? Is that generally the case on your systems? Every linux system I've run, regardless of RAM, has always pushed things out to swap. For me, it is generally the case yes. We are still discussing this in the context of desktop machines and their problems with being slow as things have been swapped out and generally I expect a desktop to have plenty of swap which it's not regularly going to fillup significantly since then the machine's unworkably slow as a desktop anyway. And once there's something already in swap, you now have a packing problem when you want to swap something else out. Once we're crammed, it gets to be a different situation yes. As far as I'm concerned that's for another thread though. I'm spending too much time on LKML as it is... 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] sched: yield debugging
Tim,
* Tim Chen [EMAIL PROTECTED] wrote:
Ingo,
Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1. Benchmark
was run on a 2 socket Core2 machine.
thanks for testing and reporting this!
The change in scheduler treatment of sched_yield could play a part in
changing Volanomark behavior.
Could you try the patch below? It does not change the default behavior
of yield but introduces 2 other yield strategies which you can activate
runtime (if CONFIG_SCHED_DEBUG=y) via:
# default one:
echo 0 /proc/sys/kernel/sched_yield_bug_workaround
# always queues the current task next to the next task:
echo 1 /proc/sys/kernel/sched_yield_bug_workaround
# NOP:
echo 2 /proc/sys/kernel/sched_yield_bug_workaround
does variant '1' improve Java's VolanoMark performance perhaps?
i'm also wondering, which JDK is this, and where does Java make use of
sys_sched_yield()? It's a voefully badly defined (and thus unreliable)
system call, IMO Java should stop using it ASAP and use a saner locking
model.
thanks,
Ingo
---
Subject: sched: yield debugging
From: Ingo Molnar [EMAIL PROTECTED]
introduce various sched_yield implementations:
# default one:
echo 0 /proc/sys/kernel/sched_yield_bug_workaround
# always queues the current task next to the next task:
echo 1 /proc/sys/kernel/sched_yield_bug_workaround
# NOP:
echo 2 /proc/sys/kernel/sched_yield_bug_workaround
tunability depends on CONFIG_SCHED_DEBUG=y.
Not-yet-signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
include/linux/sched.h |1
kernel/sched_fair.c | 71 +-
kernel/sysctl.c |8 +
3 files changed, 74 insertions(+), 6 deletions(-)
Index: linux/include/linux/sched.h
===
--- linux.orig/include/linux/sched.h
+++ linux/include/linux/sched.h
@@ -1401,6 +1401,7 @@ extern unsigned int sysctl_sched_wakeup_
extern unsigned int sysctl_sched_batch_wakeup_granularity;
extern unsigned int sysctl_sched_stat_granularity;
extern unsigned int sysctl_sched_runtime_limit;
+extern unsigned int sysctl_sched_yield_bug_workaround;
extern unsigned int sysctl_sched_child_runs_first;
extern unsigned int sysctl_sched_features;
Index: linux/kernel/sched_fair.c
===
--- linux.orig/kernel/sched_fair.c
+++ linux/kernel/sched_fair.c
@@ -62,6 +62,16 @@ unsigned int sysctl_sched_stat_granulari
unsigned int sysctl_sched_runtime_limit __read_mostly;
/*
+ * sys_sched_yield workaround switch.
+ *
+ * This option switches the yield implementation of the
+ * old scheduler back on.
+ */
+unsigned int sysctl_sched_yield_bug_workaround __read_mostly = 0;
+
+EXPORT_SYMBOL_GPL(sysctl_sched_yield_bug_workaround);
+
+/*
* Debugging: various feature bits
*/
enum {
@@ -834,14 +844,63 @@ dequeue_task_fair(struct rq *rq, struct
static void yield_task_fair(struct rq *rq, struct task_struct *p)
{
struct cfs_rq *cfs_rq = task_cfs_rq(p);
+ struct rb_node *curr, *next, *first;
+ struct task_struct *p_next;
u64 now = __rq_clock(rq);
+ s64 yield_key;
- /*
-* Dequeue and enqueue the task to update its
-* position within the tree:
-*/
- dequeue_entity(cfs_rq, p-se, 0, now);
- enqueue_entity(cfs_rq, p-se, 0, now);
+
+ switch (sysctl_sched_yield_bug_workaround) {
+ default:
+ /*
+* Dequeue and enqueue the task to update its
+* position within the tree:
+*/
+ dequeue_entity(cfs_rq, p-se, 0, now);
+ enqueue_entity(cfs_rq, p-se, 0, now);
+ break;
+ case 1:
+ curr = p-se.run_node;
+ first = first_fair(cfs_rq);
+ /*
+* Move this task to the second place in the tree:
+*/
+ if (unlikely(curr != first)) {
+ next = first;
+ } else {
+ next = rb_next(curr);
+ /*
+* We were the last one already - nothing to do, return
+* and reschedule:
+*/
+ if (unlikely(!next))
+ return;
+ }
+
+ p_next = rb_entry(next, struct task_struct, se.run_node);
+ /*
+* Minimally necessary key value to be the second in the tree:
+*/
+ yield_key = p_next-se.fair_key + (int)sysctl_sched_granularity;
+
+ dequeue_entity(cfs_rq, p-se, 0, now);
+
+ /*
+* Only update the key if we need to move more backwards
+* than the minimally necessary position to be the second:
+*/
+ if (p-se.fair_key yield_key)
+
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
Is that generally the case on your systems? Every linux system I've run, regardless of RAM, has always pushed things out to swap. For me, it is generally the case yes. We are still discussing this in the context of desktop machines and their problems with being slow as things have been swapped out and generally I expect a desktop to have plenty of swap which it's not regularly going to fillup significantly since then the machine's unworkably slow as a desktop anyway. A simple log optimises writeout (which is latency critical) and can otherwise stall an enitre system. In a log you can also have multiple copies of the same page on disk easily, some stale - so you can write out chunks of data that are not all them removed from memory, just so you get them back more easily if you then do (and I guess you'd mark them accordingly) The second element is a cleaner - something to go around removing stuff from the log that is needed when the disks are idle - and also to repack data in nice linear chunks. So instead of using the empty disk time for page-in you use it for packing data and optimising future paging. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] ppc: chipsfb.c build fix for CONFIG_PM
Hello, This patch fixes the following build error on powerpc: CC drivers/video/chipsfb.o drivers/video/chipsfb.c: In function 'chipsfb_pci_suspend': drivers/video/chipsfb.c:461: error: 'PM_SUSPEND_MEM' undeclared (first use in this function) drivers/video/chipsfb.c:461: error: (Each undeclared identifier is reported only once drivers/video/chipsfb.c:461: error: for each function it appears in.) make[2]: *** [drivers/video/chipsfb.o] Blad 1 make[1]: *** [drivers/video] Blad 2 make: *** [drivers] Blad 2 Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED] drivers/video/chipsfb.c | 12751 - 12804 (+53 bytes) drivers/video/chipsfb.o | - 112880 ( bytes) drivers/video/chipsfb.c |5 + 1 file changed, 5 insertions(+) --- linux-2.6.23-rc1-mm1-a/drivers/video/chipsfb.c 2007-07-26 13:07:41.0 +0200 +++ linux-2.6.23-rc1-mm1-b/drivers/video/chipsfb.c 2007-07-29 19:34:15.0 +0200 @@ -27,6 +27,11 @@ #include linux/init.h #include linux/pci.h #include linux/console.h + +#ifdef CONFIG_PM +#include linux/suspend.h +#endif + #include asm/io.h #ifdef CONFIG_PMAC_BACKLIGHT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 7/29/07, Rene Herman [EMAIL PROTECTED] wrote: On 07/29/2007 07:19 PM, Ray Lee wrote: For me, it is generally the case yes. We are still discussing this in the context of desktop machines and their problems with being slow as things have been swapped out and generally I expect a desktop to have plenty of swap which it's not regularly going to fillup significantly since then the machine's unworkably slow as a desktop anyway. Shrug Well, that doesn't match my systems. My laptop has 400MB in swap: [EMAIL PROTECTED]:~$ free total used free sharedbuffers cached Mem:894208 883920 10288 0 3044 163224 -/+ buffers/cache: 717652 176556 Swap: 1116476 393132 723344 And once there's something already in swap, you now have a packing problem when you want to swap something else out. Once we're crammed, it gets to be a different situation yes. As far as I'm concerned that's for another thread though. I'm spending too much time on LKML as it is... No, it's not even when crammed. It's just when there are holes. mm/swapfile.c does try to cluster things, but doesn't work too hard at it as we don't want to spend all our time looking for a perfect fit that may not exist. Ray - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: commit 7e92b4fc34 - x86, serial: convert legacy COM ports to platform devices - broke my serial console
On Fri, Jul 27, 2007 at 12:16:59PM -0600, Bjorn Helgaas wrote: For example, 8250_pnp could have rules like COM1 should always be ttyS0 or a port at 0x3f8 should always be ttyS0. In which case register via the legacy ports first, and then register PNP ports. If the PNP ports correspond with legacy ports, they will re-use those slots. So, if we register 0x3f8 first (which ends up as ttyS0), followed by 0x2f8 (ttyS1) and then PNP tries to register a port at 0x2f8 then 0x3f8, you'll still end up with 0x3f8 being ttyS0 and 0x2f8 as ttyS1. That doesn't help with Yinghai's PCI root ordering issue, of course. But I hope that can be addressed with udev, because there's not so much need for a persistent kernel name. If that's not enough, can you explain more about the problem? However, aren't PNP serial ports attached to separate PNP devices? If so, udev can work it out already - they just need to look at the backing device associated with the serial port. For legacy ports that'll be serial8250.0. For PNP, it'll be some PNP device. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Reboot Dreamcast under software control
In the light of more up to date technical information I have
discovered there is a register at physical address 0x005F6890 on the
Dreamcast that if written a magic number (0x7611) will force a
reboot under software control.
Presumably a better option than the current catch-all mechanism.
Signed-off by: Adrian McMenamin [EMAIL PROTECTED]
diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c
index 6334a4c..6f5e9e4 100644
--- a/arch/sh/kernel/process.c
+++ b/arch/sh/kernel/process.c
@@ -97,6 +97,11 @@ void cpu_idle(void)
void machine_restart(char * __unused)
{
+
+#ifdef CONFIG_SH_DREAMCAST
+ /*reboot the Dreamcast under software control*/
+ writel(0x7611, 0xA05F6890);
+#endif
/* SR.BL=1 and invoke address error to let CPU reset (manual reset) */
asm volatile(ldc %0, sr\n\t
mov.l @%1, %0 : : r (0x1000), r (0x8001));
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ACPI on Averatec 2370
I have an Averatec 2370 laptop with the nVidia MCP51. With kernel 2.6.20 I had no issues with ACPI however with 2.6.21 and higher the kernel will hang on boot until I press the suspend button or the power button in which case the kernel wakes up and finishes the boot process. Including the following support only causes the issue: [*] ACPI Support What I mean by that is every ACPI option has been deactivated and only ACPI support checked. The boot process with 2.6.21 and higher hangs at the point where the Scheduler is being registered. io scheduler cfq registered (default) If I allow it to sit there it never comes back to life and finishes booting. If I press the power or suspend button it will finish booting as expected. I've scoured google for quite a while but cannot find any relevant information pertaining to this issue. For now I've disabled ACPI altogether. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [PATCH] USB Pegasus driver - avoid a potential NULL pointer dereference.
On Sun, 29 Jul 2007, Oliver Neukum wrote:
Am Sonntag 29 Juli 2007 schrieb Jesper Juhl:
On 29/07/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hi,
On 7/29/07, Jesper Juhl [EMAIL PROTECTED] wrote:
Hello,
This patch makes sure we don't dereference a NULL pointer in
drivers/net/usb/pegasus.c::write_bulk_callback() in the initial
struct net_device *net = pegasus-net; assignment.
The existing code checks if 'pegasus' is NULL and bails out if
it is, so we better not touch that pointer until after that check.
[...]
Is it really possible that we're called into this function with
urb-context == NULL? If not, I'd suggest let's just get rid of
the check itself, instead.
I'm not sure. I am not very familiar with this code. I just figured
that moving the assignment is potentially a little safer and it is
certainly no worse than the current code, so that's a safe and
potentially benneficial change. Removing the check may be safe but I'm
not certain enough to make that call...
pegasus == NULL there would be a kernel bug. Silently ignoring
it, like the code now wants to do is bad. As the oops has never been
reported, I figure turning it into an explicit debugging test is overkill,
so removal seems to be the best option.
Ok, thanks. Updated patch below.
[PATCH] pegasus: Remove bogus checks in urb-complete() callbacks
urb-complete() callbacks registered in drivers/net/usb/pegasus.c needlessly
check for urb-context != NULL, but that is not possible (the only way that
can be possible would be a kernel bug elsewhere, and these checks would
simply end up hiding that). So let's remove the bogus checks.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
drivers/net/usb/pegasus.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index a05fd97..439ef9f 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -770,9 +770,6 @@ static void write_bulk_callback(struct urb *urb)
pegasus_t *pegasus = urb-context;
struct net_device *net = pegasus-net;
- if (!pegasus)
- return;
-
if (!netif_device_present(net) || !netif_running(net))
return;
@@ -805,13 +802,9 @@ static void write_bulk_callback(struct urb *urb)
static void intr_callback(struct urb *urb)
{
pegasus_t *pegasus = urb-context;
- struct net_device *net;
+ struct net_device *net = pegasus-net;
int status;
- if (!pegasus)
- return;
- net = pegasus-net;
-
switch (urb-status) {
case 0:
break;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI on Averatec 2370
Frank Hale wrote: [ added linux-acpi to CC ] I have an Averatec 2370 laptop with the nVidia MCP51. With kernel 2.6.20 I had no issues with ACPI however with 2.6.21 and higher the kernel will hang on boot until I press the suspend button or the power button in which case the kernel wakes up and finishes the boot process. Including the following support only causes the issue: [*] ACPI Support What I mean by that is every ACPI option has been deactivated and only ACPI support checked. The boot process with 2.6.21 and higher hangs at the point where the Scheduler is being registered. io scheduler cfq registered (default) If I allow it to sit there it never comes back to life and finishes booting. If I press the power or suspend button it will finish booting as expected. I've scoured google for quite a while but cannot find any relevant information pertaining to this issue. For now I've disabled ACPI altogether. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sb1000: prevent a potential NULL pointer dereference in sb1000_dev_ioctl()
On Sun, 29 Jul 2007, Domen Puncer wrote: On 29/07/07 00:02 +0200, Jesper Juhl wrote: Hi, Here's a small patch, prompted by a find by the Coverity checker, that removes a potential NULL pointer dereference from drivers/net/sb1000.c::sb1000_dev_ioctl(). The checker spotted that we do a NULL test of 'dev', yet we dereference the pointer prior to that check. This patch simply moves the dereference after the NULL test. But... it can't be called without a valid 'dev', no? A quick 'grep do_ioctl net/' confirms that all calls are in the form of 'dev-do_ioctl(dev, ...'. Yup, I think so too ... @@ -991,11 +991,13 @@ static int sb1000_dev_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) short PID[4]; int ioaddr[2], status, frequency; unsigned int stats[5]; - struct sb1000_private *lp = netdev_priv(dev); + struct sb1000_private *lp; if (!(dev dev-flags IFF_UP)) return -ENODEV; I think we could get rid of the !dev check itself. Actually, the IFF_UP check /also/ looks suspect to me for two reasons: (1) I remember Stephen Hemminger once telling me dev-flags is legacy and unsafe, and one of the netif_xxx() functions be used instead, and, (2) I wonder if we really require the interface to be up and *running* when we do this ioctl. Updated patch below. [PATCH] sb1000: Remove bogus checks In net_device-do_ioctl() of the sb1000 driver (sb1000_dev_ioctl): (1) !dev condition is always false -- this function cannot be called with NULL net_device. (2) !(dev-flags IFF_UP) is bogus because the functions of this ioctl can (and should) be allowed even when the interface is not up and running. So let's remove these checks. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Cc: Jesper Juhl [EMAIL PROTECTED] Cc: Domen Puncer [EMAIL PROTECTED] --- drivers/net/sb1000.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/net/sb1000.c b/drivers/net/sb1000.c index 1de3eec..f60fe98 100644 --- a/drivers/net/sb1000.c +++ b/drivers/net/sb1000.c @@ -993,9 +993,6 @@ static int sb1000_dev_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) unsigned int stats[5]; struct sb1000_private *lp = netdev_priv(dev); - if (!(dev dev-flags IFF_UP)) - return -ENODEV; - ioaddr[0] = dev-base_addr; /* mem_start holds the second I/O address */ ioaddr[1] = dev-mem_start; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. If I tried to rewrite a kernel subsystem - should I ever happen to dig that deep into kernel matters - while I actually know that someone already spent countless hours on exactly rewriting the exact same subsystem, I think I would have told that other developer about it as soon as I started coding on it. And if it just was a Hi Con, I reconsidered the scheduling ideas again you brought to the Linux kernel world. Instead of using your scheduler tough I like to try to write a new one with fairness in mind, cause I think this, this and this can be improved upon. I would like to hear your ideas about that as soon as possible and would like you to contribute your ideas and also code, where you see hit. You can find the git / bazaar / whatever repository where I do my developments at: someurl. Regards, Ingo I believe that Ingo did not meant any bad at all. I think its just the way he works, he likes to have code before saying anything. But still I believe before I'd go about replacing someone else code completely I would inform that developer beforehand, even if it then turns out not to be feasible at all. No need to anounce it to the world already, but I would have informed that developer. And aside from that there has been communication before and after this event that IMHO could have been better. And thats not only targetted at Ingo. A view this whole issue as everyone who was involved in it, actually was involved in it and has his share in its outcome. So everyone has a great chance to learn something out of it. (That includes me of course, too.) Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Fwd: [PATCH] Reboot Dreamcast under software control
Apologies. I meant to cc: this to the lists first time round and
appear to have bcc'ed it instead.
-- Forwarded message --
From: Adrian McMenamin [EMAIL PROTECTED]
Date: 29-Jul-2007 19:04
Subject: [PATCH] Reboot Dreamcast under software control
To: [EMAIL PROTECTED]
In the light of more up to date technical information I have
discovered there is a register at physical address 0x005F6890 on the
Dreamcast that if written a magic number (0x7611) will force a
reboot under software control.
Presumably a better option than the current catch-all mechanism.
Signed-off by: Adrian McMenamin [EMAIL PROTECTED]
diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c
index 6334a4c..6f5e9e4 100644
--- a/arch/sh/kernel/process.c
+++ b/arch/sh/kernel/process.c
@@ -97,6 +97,11 @@ void cpu_idle(void)
void machine_restart(char * __unused)
{
+
+#ifdef CONFIG_SH_DREAMCAST
+ /*reboot the Dreamcast under software control*/
+ writel(0x7611, 0xA05F6890);
+#endif
/* SR.BL=1 and invoke address error to let CPU reset (manual reset) */
asm volatile(ldc %0, sr\n\t
mov.l @%1, %0 : : r (0x1000), r (0x8001));
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Sparc32 not working:2.6.23-rc1 (git commit 1e4dcd22efa7d24f637ab2ea3a77dd65774eb005)
On Sun, 29 Jul 2007, Krzysztof Helt wrote: On Sun, 29 Jul 2007 00:21:06 +0100 (BST) Mark Fortescue [EMAIL PROTECTED] wrote: Hi Krzysztof, There have been lots of changes to the DMA system (git bisect is not viable form my working 2.6.22 kernel as the dma changes kill the build for over half the posible commits to check). It could be a side effect of these changes. It is not DMA I suppose. It does not happen in any specific place. It is easy to trigger by loading and unloading the sunlance module, but it hangs linux in other places (init process, console login). It happens only in SMP. If it happens in the sunlance module it happens in sparc_lance_probe_one() (in probing function). I thought it is due to openprom accesses so I commented them out (and put hardcoded values there). No real change. It is always in the probe_one method before any DMA is started. Sometimes it drops me to the prom prompt. I am not very experienced so I was able only to find (ctrace) that the prompt was called in the method spwin_bad_ustack_from_kernel() which got there from mna_handler (misaligned access) through kernel_unaligned_trap(). I don't know which function triggered the unaligned access. The %o register values sent to the kernel_unaligned_trap() are outside addresses from System.map and outside addresses of loaded (or just loaded the sunlance) modules. This is where I need help. How can I find where the misaligned access happened? The is a memory corruption issue on Sparc32 - sun4c (I am going to try and track it done over the next few days). It sounds like it may affect more than just sun4c issue. Try going back to v2.6.22 and then appling f61698e6489f229f9fcfe29e68f228389a772993 - memset.S error, 196bffa5dc3181897bd32e41415ec0db8dbab5e7 - entry.S delay loops, f3c681c028846bd5d39f563909409832a295ca69 - Serial Console Locking (My last working kernel is v2.6.22 Commit eb6bf6bfb580afaf1e1a1d30cba17a078530cf4 with the first of the above two patches applied and some additional ones that fix verious sun partition/UFS filing sustem issues). I am going to try to cherry pick a set of commits to see if I can't get a better idear of where the memory corruption on sun4c is coming from. Build problems sue to the DMA changes make git bisecting un-usable untill I have found out which patches fix the DMA build issues. Regards, Krzysztof - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Diego Calleja: This time it was Con being the Mindcraft catalyst. But he's on *our* side and he got beat down by the Linux kernel community. That's the tragedy here. He was beaten down by the very people he was trying to help out and support. It should have been handled better. Get real: I don't the linux development has always been friendly. The idea of a GNU-hippie community where everybody is good and helps others and shares their pots is what the Sun bloggers seem to think that opensolaris should resemble, but it doesn't matches the real world. Actually I have seen friendly communities around Linux and free software. Like the KDE project, the ck patchset mailing list community, the TuxOnIce aka suspend2 community, the SGI XFS community, the Bazaar community, quite some parts of the Debian community just to name a few. So I know that it can be different. I know that its inaccurate to talk about the whole Linux kernel community. I had quite friendly contacts with core Linux developers like with Ingo (yes, with Ingo!;-) or Greg Kroah-Hartman. So what would be wrong with looking at how this worked out and why and how it would be possible to avoid loosing a talented developer? -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: nvidia installer DIW with 2.6.23-rc1
On Sun, 29 Jul 2007 10:57:33 -0400 Gene Heskett [EMAIL PROTECTED] wrote: Greetings; I got around to building the 2.6.23-rc1 tree, updated to yesterday with git from the linus tree. The build was fairly clean, but when I rebooted to it, the latest nvidia installer fails, with these messages: I know it's off topic here, but this will help people. When that happens, check their forum. Chances are someone has posted, and the nvidia developers have answered with a patch, code snippet, quick instructions to get it to compile or advice to try a beta driver if applicable. To build nvidia kernel module failed in kernel-2.6.23-0.41.rc0.git14.fc8 http://www.nvnews.net/vbulletin/showthread.php?t=95296 Mike Houston - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Hi Martin, On Sun, 29 Jul 2007, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. If I tried to rewrite a kernel subsystem - should I ever happen to dig that deep into kernel matters - while I actually know that someone already spent countless hours on exactly rewriting the exact same subsystem, I think I would have told that other developer about it as soon as I started coding on it. And if it just was a Hi Con, I reconsidered the scheduling ideas again you brought to the Linux kernel world. Instead of using your scheduler tough I like to try to write a new one with fairness in mind, cause I think this, this and this can be improved upon. I would like to hear your ideas about that as soon as possible and would like you to contribute your ideas and also code, where you see hit. You can find the git / bazaar / whatever repository where I do my developments at: someurl. Regards, Ingo Sending out the code (and early enough, 48 hours /is/ early enough) *is* the normal (and good) way to do exactly the communication you described above, IMHO. I believe that Ingo did not meant any bad at all. I think its just the way he works, he likes to have code before saying anything. But still I believe before I'd go about replacing someone else code completely I would inform that developer beforehand, even if it then turns out not to be feasible at all. No need to anounce it to the world already, but I would have informed that developer. IMHO, what you're suggesting is: (1) not the way development normally happens in Linux, and, (2) not the way it /should/ happen, either. If there's something (subsystem, any code big or small) I think I can do better or have an idea for, I /should/ be able to just hack on it a bit and then send it out so everybody can comment on it. Why should I be forced to dance/discuss around with some other people, when the faster and more effective way would be just present the code/patch that I have in my mind as an RFC? See, Martin, in the end it's not about developer A vs developer B. It's about making the kernel the best out there -- that's what the users want, anyway. Yes, I fully understand (and have said so earlier myself) that there's a very important social aspect to development on such projects, but it's best if developer B understands that this is the way things do (and should) happen and adapt to it. [ It's not like I've been around for long, however, but the above is still my opinion, fwiw. ] Satyam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 regression caused by typo in lm90.c
Hi:
On 7/26/2007, Guillaume Chazarain [EMAIL PROTECTED] wrote:
diff -r 4cad6fced1a8 drivers/hwmon/lm90.c
--- a/drivers/hwmon/lm90.c Thu Jul 26 13:44:58 2007 -0700
+++ b/drivers/hwmon/lm90.c Tue Jul 24 00:02:52 2007 +0200
@@ -585,7 +585,7 @@ static int lm90_detect(struct i2c_adapte
* those of the man_id register.
*/
if (chip_id == man_id
- (address == 0x4F || address == 0x4D)
+ (address == 0x4C || address == 0x4D)
(reg_config1 0x1F) == (man_id 0x0F)
reg_convrate = 0x09) {
kind = max6657;
* Jean Delvare [EMAIL PROTECTED] [2007-07-27 10:07:45 +0200]:
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[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: [2.6 patch] kernel/audit.c: change the exports to EXPORT_SYMBOL_GPL
On Sun, 2007-07-29 at 17:02 +0200, Adrian Bunk wrote: This patch changes some completely unused audit exports from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL. They are still completely unused, but hopefully some of the theoretical code that might use it will appear in the kernel in the near future... \ at least make them _UNUSED_ so that people can select to not have these take up space... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reading a bad sector does not report failure as 'read error' but hangs PC with 'Machine Check Exception'
Probably a similar problem is described in the linux-ide mailing list a while ago: http://www.opensubscriber.com/message/[EMAIL PROTECTED]/6490911.html Argh. I'm seeing a show stopper bug on sata_nv here. ata_exec_internal is MCE-ing on the READ_NATIVE_MAX_EXT command on both i386 and amd64, with top of Linus' tree + this patch. :( Oddly, the command at least executes and doesn't MCE (but it's not at all happy either) if I use ATA_PROT_PIO. I wonder if ATA_PROT_NODATA is buggered on this sata_nv chip (Asus A8N-E). At least it is a similar motherboard that is used (however I have explicitly have the A8N-E Deluxe edition). I try not to repair my SATA disk for now with the Seatools, so if there is some testing to be done, I can run it with the bad disk. Regards, Hendrik Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] sb1000: prevent a potential NULL pointer dereference in sb1000_dev_ioctl()
On Sunday 29 July 2007 20:34:46 Satyam Sharma wrote: (2) !(dev-flags IFF_UP) is bogus because the functions of this ioctl can (and should) be allowed even when the interface is not up and running. Are you _sure_? This function does poke with the device hardware. It might return crap or even machinecheck when not initialized. Hardware is probably powered down, if not IFF_UP. (I don't know if that's the case here, though). drivers/net/sb1000.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/net/sb1000.c b/drivers/net/sb1000.c index 1de3eec..f60fe98 100644 --- a/drivers/net/sb1000.c +++ b/drivers/net/sb1000.c @@ -993,9 +993,6 @@ static int sb1000_dev_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) unsigned int stats[5]; struct sb1000_private *lp = netdev_priv(dev); - if (!(dev dev-flags IFF_UP)) - return -ENODEV; - -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [2.6 patch] make abituguru3_read_increment_offset() static
Hi:
* Hans de Goede [EMAIL PROTECTED] [2007-07-29 18:08:46 +0200]:
Adrian Bunk wrote:
abituguru3_read_increment_offset() can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Looks good, good catch.
Acked-by: Hans de Goede [EMAIL PROTECTED]
---
--- linux-2.6.23-rc1-mm1/drivers/hwmon/abituguru3.c.old 2007-07-26
08:56:33.0 +0200
+++ linux-2.6.23-rc1-mm1/drivers/hwmon/abituguru3.c 2007-07-26
08:57:00.0 +0200
@@ -691,8 +691,9 @@
/* Sensor settings are stored 1 byte per offset with the bytes
placed add consecutive offsets. */
-int abituguru3_read_increment_offset(struct abituguru3_data *data, u8
bank,
-u8 offset, u8 count, u8 *buf, int offset_count)
+static int abituguru3_read_increment_offset(struct abituguru3_data *data,
+u8 bank, u8 offset, u8 count,
+u8 *buf, int offset_count)
{
int i, x;
Applied to hwmon-2.6.git/testing, thanks.
--
Mark M. Hoffman
[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] sb1000: prevent a potential NULL pointer dereference in sb1000_dev_ioctl()
Hi Michael, On Sun, 29 Jul 2007, Michael Buesch wrote: On Sunday 29 July 2007 20:34:46 Satyam Sharma wrote: (2) !(dev-flags IFF_UP) is bogus because the functions of this ioctl can (and should) be allowed even when the interface is not up and running. Are you _sure_? This function does poke with the device hardware. It might return crap or even machinecheck when not initialized. Hardware is probably powered down, if not IFF_UP. (I don't know if that's the case here, though). IFF_UP checks if the _interface_ is up -- the hardware / card could still be powered up, but the interface down (ifconfing eth0 down or ip link set eth0 down). Probably what we want here is netif_device_present()? -- I think that should return true only when the *device* itself is up (as in powered) but the interface itself could be down ... Let's wait for comments from the netdev people Cc:'ed here, in that case. drivers/net/sb1000.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/net/sb1000.c b/drivers/net/sb1000.c index 1de3eec..f60fe98 100644 --- a/drivers/net/sb1000.c +++ b/drivers/net/sb1000.c @@ -993,9 +993,6 @@ static int sb1000_dev_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) unsigned int stats[5]; struct sb1000_private *lp = netdev_priv(dev); - if (!(dev dev-flags IFF_UP)) - return -ENODEV; - Satyam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI on Averatec 2370
Frank, can you try a non-SMP build with ACPI and see if you still have the problem? I certainly will, I never tried it without it so now I am curious. Thanks a bunch! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 07/29/2007 07:52 PM, Ray Lee wrote: Shrug Well, that doesn't match my systems. My laptop has 400MB in swap: Which in your case is slightly more than 1/3 of available swap space. Quite a lot for a desktop indeed. And if it's more than a few percent fragmented, please fix current swapout instead of log structuring it. 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: ACPI on Averatec 2370
On Sun, 29 Jul 2007, Gabriel C wrote: Frank Hale wrote: [ added linux-acpi to CC ] I have an Averatec 2370 laptop with the nVidia MCP51. With kernel 2.6.20 I had no issues with ACPI however with 2.6.21 and higher the kernel will hang on boot until I press the suspend button or the power button in which case the kernel wakes up and finishes the boot process. Including the following support only causes the issue: [*] ACPI Support What I mean by that is every ACPI option has been deactivated and only ACPI support checked. The boot process with 2.6.21 and higher hangs at the point where the Scheduler is being registered. io scheduler cfq registered (default) If I allow it to sit there it never comes back to life and finishes booting. If I press the power or suspend button it will finish booting as expected. I've scoured google for quite a while but cannot find any relevant information pertaining to this issue. For now I've disabled ACPI altogether. Hi Frank et al. Same laptop (well 2371 actually - same hardware though), same issue. In my testing I've determined that SMP is influential on it hanging up. Building my same config with SMP disabled causes the hang to go away. Same with the Slackware 12 default kernels, 2.6.21.5 is OK, 2.6.21.5-smp hangs. Frank, can you try a non-SMP build with ACPI and see if you still have the problem? I've tried so many different option combos I don't remember if I've done one with SMP and w/o ACPI but I'll try that sometime today. Haven't tried ACPI debugging yet either so we'll see if that shows anything. Maybe we can narrow it down to something with ACPI and SMP. Cheers, -- Cal Peake - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] pci_ids: additional NFORCE MCP61 devices
This patch adds the following 7 Nforce devices: - LPC Bridge (MCP61_LPC_BRG) - Memory Controller (MCP61_MC1) - High Definition Audio (MCP61_HDA) - USB Controller (MCP61_OHCI) - USB Controller (MCP61_EHCI) - PCI bridge (MCP61_PCI_BRG) - Memory Controller (MCP61_MC2) to the pci_ids.h file. Signed-off-by: Indrek Kruusa [EMAIL PROTECTED] lspci output on Gigabyte GA-M61SME-S2 (GF6100/NF405) can be seen from [1],[2] thanks, Indrek __ [1] http://www.hot.ee/bzmeez/nv_mcp61_lspci-n.txt [2] http://www.hot.ee/bzmeez/nv_mcp61_lspci-vv.txt diff -pur linux-2.6.git1/include/linux/pci_ids.h linux-2.6_p/include/linux/pci_ids.h --- linux-2.6.git1/include/linux/pci_ids.h 2007-07-29 20:48:28.0 +0300 +++ linux-2.6_p/include/linux/pci_ids.h 2007-07-29 20:54:21.0 +0300 @@ -1206,13 +1206,20 @@ #define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_1100 0x034E #define PCI_DEVICE_ID_NVIDIA_NVENET_14 0x0372 #define PCI_DEVICE_ID_NVIDIA_NVENET_15 0x0373 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_LPC_BRG 0x03E0 #define PCI_DEVICE_ID_NVIDIA_NVENET_16 0x03E5 #define PCI_DEVICE_ID_NVIDIA_NVENET_17 0x03E6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA 0x03E7 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC1 0x03EA #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SMBUS0x03EB #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE 0x03EC #define PCI_DEVICE_ID_NVIDIA_NVENET_18 0x03EE #define PCI_DEVICE_ID_NVIDIA_NVENET_19 0x03EF +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_HDA 0x03F0 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_OHCI 0x03F1 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_EHCI 0x03F2 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_PCI_BRG 0x03F3 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC2 0x03F5 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2 0x03F6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3 0x03F7 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_SMBUS0x0446 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
