Re: NForce4 ide problems?
Hi, On 4/20/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > You might want to post that Oops message if you want someone to try and > fix it. > Ok see it below. > Also, from your dmesg output I see that you are loading the NVIDIA module > NVRM: loading NVIDIA Linux x86_64 NVIDIA Kernel Module 1.0-7174 Tue Mar > 22 06:45:40 PST 2005 > You may want to try /not/ loading that module and then reproduce the > kernel panic and then post that Oops or panic message instead. > Ok this message was taken without loading nvidia module. I get this just after hdparm command on /dev/hda : CPU 0: Machine Check Exception: 4 Bank 4: b2070f0f TSC 1cb2201501c Kernel panic - not syncing : Machine check Any help is appreciated. Regards, ismail -- Time is what you make of it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hpt366: HPT372N rev 2 controller fix
A particular revision of the HPT372N oopses hpt366 consistently. It's a
regression caused by Alan's changes in 2.6.9 to support the HPT372N using
only PLL timings. The driver works correctly in prior versions, where the the
PCI clock is used instead. This patch restores that behaviour for this
particular revision.
More info:
http://www.ussg.iu.edu/hypermail/linux/kernel/0410.0/0958.html
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135515
Please CC replies to me.
-Albert
--
Prediction is very difficult, especially of the future.
-- Niels Bohr
--- hpt366.c.orig 2004-11-20 17:13:52.28036 -0500
+++ hpt366.c 2005-04-21 00:40:38.686009488 -0400
@@ -802,6 +802,9 @@
if((did == 4 && rid == 6) || (did == 5 && rid > 1))
is_372n = 1;
+ /* Check for a HPT372 rev 2, which is a special 372N */
+ if(did == 5 && rid == 2)
+ is_372n = 2;
}
/*
@@ -845,7 +848,25 @@
printk(KERN_INFO "FREQ: %d PLL: %d\n", freq, pll);
- /* We always use the pll not the PCI clock on 372N */
+ /* We always use the pll not the PCI clock on 372N,
+ * except for the 372 rev 2, which works fine with 372A
+ * timings, and needs pci_set_drvdata().
+ */
+ if(is_372n == 2)
+ {
+ if (pll == F_LOW_PCI_33) {
+pci_set_drvdata(dev, (void *) thirty_three_base_hpt372);
+printk("HPT37X: HPT372 rev 2 detected, using 33MHz PCI clock\n");
+ } else if (pll == F_LOW_PCI_40) {
+/* Unsupported */
+ } else if (pll == F_LOW_PCI_50) {
+pci_set_drvdata(dev, (void *) fifty_base_hpt372);
+printk("HPT37X: HPT372 rev 2 detected, using 50MHz PCI clock\n");
+ } else {
+pci_set_drvdata(dev, (void *) sixty_six_base_hpt372);
+printk("HPT37X: HPT372 rev 2 detected, using 66MHz PCI clock\n");
+ }
+ }
}
else
{
pgpFbXK1o7rB7.pgp
Description: PGP signature
Re: [patch] inotify for 2.6.12-rc3.
On Thu, 2005-04-21 at 01:13 -0400, Robert Love wrote:
> Live from linux.conf.au, below is inotify against 2.6.12-rc3.
G'day mates! By popular request!
Cheers,
Robert Love
Send an event on xattr change. Just use the existing metadata change event,
IN_ATTRIB, instead of adding a new event. While here, do not wrap
dnotify_flush(), no need.
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
fs/open.c|2 +-
fs/xattr.c |5 -
include/linux/fsnotify.h | 18 ++
3 files changed, 15 insertions(+), 10 deletions(-)
diff -urN linux-2.6.12-rc3-inotify-0.22-2/fs/open.c linux/fs/open.c
--- linux-2.6.12-rc3-inotify-0.22-2/fs/open.c 2005-04-21 01:13:17.0
-0400
+++ linux/fs/open.c 2005-04-21 01:17:27.0 -0400
@@ -1000,7 +1000,7 @@
retval = err;
}
- fsnotify_flush(filp, id);
+ dnotify_flush(filp, id);
locks_remove_posix(filp, id);
fput(filp);
return retval;
diff -urN linux-2.6.12-rc3-inotify-0.22-2/fs/xattr.c linux/fs/xattr.c
--- linux-2.6.12-rc3-inotify-0.22-2/fs/xattr.c 2005-04-21 01:13:17.0
-0400
+++ linux/fs/xattr.c2005-04-21 01:24:24.0 -0400
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
/*
@@ -57,8 +58,10 @@
if (error)
goto out;
error = d->d_inode->i_op->setxattr(d, kname, kvalue, size,
flags);
- if (!error)
+ if (!error) {
+ fsnotify_xattr(d);
security_inode_post_setxattr(d, kname, kvalue, size,
flags);
+ }
out:
up(>d_inode->i_sem);
}
diff -urN linux-2.6.12-rc3-inotify-0.22-2/include/linux/fsnotify.h
linux/include/linux/fsnotify.h
--- linux-2.6.12-rc3-inotify-0.22-2/include/linux/fsnotify.h2005-04-21
01:13:20.0 -0400
+++ linux/include/linux/fsnotify.h 2005-04-21 01:23:06.0 -0400
@@ -131,6 +131,16 @@
}
/*
+ * fsnotify_xattr - extended attributes were changed
+ */
+static inline void fsnotify_xattr(struct dentry *dentry)
+{
+ inotify_dentry_parent_queue_event(dentry, IN_ATTRIB, 0,
+ dentry->d_name.name);
+ inotify_inode_queue_event(dentry->d_inode, IN_ATTRIB, 0, NULL);
+}
+
+/*
* fsnotify_change - notify_change event. file was modified and/or metadata
* was changed.
*/
@@ -177,14 +187,6 @@
}
}
-/*
- * fsnotify_flush - flush time!
- */
-static inline void fsnotify_flush(struct file *filp, fl_owner_t id)
-{
- dnotify_flush(filp, id);
-}
-
#ifdef CONFIG_INOTIFY /* inotify helpers */
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] inotify for 2.6.12-rc3.
Live from linux.conf.au, below is inotify against 2.6.12-rc3.
Cheers,
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says "the filesystem that the item
you were watching is on was unmounted."
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
Documentation/filesystems/inotify.txt | 81 ++
fs/Kconfig| 13
fs/Makefile |1
fs/attr.c | 33 -
fs/compat.c | 12
fs/file_table.c |3
fs/inode.c|6
fs/inotify.c | 961 ++
fs/namei.c| 30 -
fs/open.c |6
fs/read_write.c | 15
include/linux/fs.h|6
include/linux/fsnotify.h | 228
include/linux/inotify.h | 111 +++
include/linux/sched.h |4
kernel/user.c |4
16 files changed, 1458 insertions(+), 56 deletions(-)
diff -urN linux-2.6.12-rc3/Documentation/filesystems/inotify.txt
linux/Documentation/filesystems/inotify.txt
--- linux-2.6.12-rc3/Documentation/filesystems/inotify.txt 1969-12-31
19:00:00.0 -0500
+++ linux/Documentation/filesystems/inotify.txt 2005-04-21 00:56:28.0
-0400
@@ -0,0 +1,81 @@
+ inotify
+a powerful yet simple file change notification system
+
+
+
+Document started 15 Mar 2005 by Robert Love <[EMAIL PROTECTED]>
+
+(i) User Interface
+
+Inotify is controlled by a device node, /dev/inotify. If you do not use udev,
+this device may need to be created manually. First step, open it
+
+ int dev_fd = open ("/dev/inotify", O_RDONLY);
+
+Change events are managed by "watches". A watch is an (object,mask) pair where
+the object is a file or directory and the mask is a bitmask of one or more
+inotify events that the application wishes to receive. See
+for valid events. A watch is referenced by a watch descriptor, or wd.
+
+Watches are added via a file descriptor.
+
+Watches on a directory will return events on any files inside of the directory.
+
+Adding a watch is simple,
+
+ /* 'wd' represents the watch on fd with mask */
+ struct inotify_request req = { fd, mask };
+ int wd = ioctl (dev_fd, INOTIFY_WATCH, );
+
+You can add a large number of files via something like
+
+ for each file to watch {
+ struct inotify_request req;
+ int file_fd;
+
+ file_fd = open (file, O_RDONLY);
+ if (fd < 0) {
+ perror ("open");
+ break;
+ }
+
+ req.fd = file_fd;
+ req.mask = mask;
+
+ wd = ioctl (dev_fd, INOTIFY_WATCH, );
+
+ close (fd);
+ }
+
+You can update an existing watch in the same manner, by passing in a new mask.
+
+An existing watch is removed via the INOTIFY_IGNORE ioctl, for example
+
+ ioctl (dev_fd, INOTIFY_IGNORE, wd);
+
+Events are provided in the form of an inotify_event structure that is read(2)
+from /dev/inotify. The filename is of dynamic length and follows the struct.
+It is of size len. The filename is padded with null bytes to ensure proper
+alignment. This padding is reflected in len.
+
+You can slurp multiple events by passing a large buffer, for example
+
+ size_t len = read (fd, buf, BUF_LEN);
+
+Will return as many events as are available and fit in BUF_LEN.
+
+/dev/inotify is also select() and poll() able.
+
+You can find the size of the current event queue via the FIONREAD ioctl.
+
+All watches are destroyed and cleaned up on close.
+
+
+(ii) Internal Kernel Implementation
+
+Each open inotify device is associated with an inotify_device structure.
+
+Each watch is associated with an inotify_watch
[2.6 patch] fs/aio.c: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
fs/aio.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
--- linux-2.6.12-rc2-mm3-full/fs/aio.c.old 2005-04-20 23:03:19.0
+0200
+++ linux-2.6.12-rc2-mm3-full/fs/aio.c 2005-04-20 23:05:56.0 +0200
@@ -40,8 +40,8 @@
#define dprintk(x...) do { ; } while (0)
#endif
-long aio_run = 0; /* for testing only */
-long aio_wakeups = 0; /* for testing only */
+static long aio_run = 0; /* for testing only */
+static long aio_wakeups = 0; /* for testing only */
/*-- sysctl variables*/
atomic_t aio_nr = ATOMIC_INIT(0); /* current system wide number of aio
requests */
@@ -58,7 +58,7 @@
static DECLARE_WORK(fput_work, aio_fput_routine, NULL);
static DEFINE_SPINLOCK(fput_lock);
-LIST_HEAD(fput_head);
+static LIST_HEAD(fput_head);
static void aio_kick_handler(void *);
@@ -290,7 +290,7 @@
spin_unlock_irq(>ctx_lock);
}
-void wait_for_all_aios(struct kioctx *ctx)
+static void wait_for_all_aios(struct kioctx *ctx)
{
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
@@ -592,7 +592,7 @@
* Comments: Called with ctx->ctx_lock held. This nests
* task_lock instead ctx_lock.
*/
-void unuse_mm(struct mm_struct *mm)
+static void unuse_mm(struct mm_struct *mm)
{
struct task_struct *tsk = current;
@@ -879,7 +879,7 @@
* and if required activate the aio work queue to process
* it
*/
-void queue_kicked_iocb(struct kiocb *iocb)
+static void queue_kicked_iocb(struct kiocb *iocb)
{
struct kioctx *ctx = iocb->ki_ctx;
unsigned long flags;
@@ -1401,7 +1401,7 @@
* Performs the initial checks and aio retry method
* setup for the kiocb at the time of io submission.
*/
-ssize_t aio_setup_iocb(struct kiocb *kiocb)
+static ssize_t aio_setup_iocb(struct kiocb *kiocb)
{
struct file *file = kiocb->ki_filp;
ssize_t ret = 0;
@@ -1470,7 +1470,8 @@
* because this callback isn't used for wait queues which
* are nested inside ioctx lock (i.e. ctx->wait)
*/
-int aio_wake_function(wait_queue_t *wait, unsigned mode, int sync, void *key)
+static int aio_wake_function(wait_queue_t *wait, unsigned mode,
+int sync, void *key)
{
struct kiocb *iocb = container_of(wait, struct kiocb, ki_wait);
@@ -1620,7 +1621,8 @@
* Finds a given iocb for cancellation.
* MUST be called with ctx->ctx_lock held.
*/
-struct kiocb *lookup_kiocb(struct kioctx *ctx, struct iocb __user *iocb, u32
key)
+static struct kiocb *lookup_kiocb(struct kioctx *ctx, struct iocb __user *iocb,
+ u32 key)
{
struct list_head *pos;
/* TODO: use a hash or array, this sucks. */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fs/afs/file.c: make a struct static
This patch makes a needlessly global struct static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.12-rc2-mm3-full/fs/afs/file.c.old 2005-04-20 23:01:48.0
+0200
+++ linux-2.6.12-rc2-mm3-full/fs/afs/file.c 2005-04-20 23:02:00.0
+0200
@@ -62,7 +62,7 @@
.invalidatepage = afs_file_invalidatepage,
};
-struct vm_operations_struct afs_fs_vm_operations = {
+static struct vm_operations_struct afs_fs_vm_operations = {
.nopage = filemap_nopage,
.populate = filemap_populate,
#ifdef CONFIG_AFS_FSCACHE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/ide/pci/sis5513.c: section fixes
These three functions are referenced from the __devinitdata
sis5513_chipset.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/ide/pci/sis5513.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.12-rc3/drivers/ide/pci/sis5513.c.old 2005-04-21
04:26:36.0 +0200
+++ linux-2.6.12-rc3/drivers/ide/pci/sis5513.c 2005-04-21 04:27:32.0
+0200
@@ -726,7 +726,7 @@
*/
/* Chip detection and general config */
-static unsigned int __init init_chipset_sis5513 (struct pci_dev *dev, const
char *name)
+static unsigned int __devinit init_chipset_sis5513 (struct pci_dev *dev, const
char *name)
{
struct pci_dev *host;
int i = 0;
@@ -879,7 +879,7 @@
return 0;
}
-static unsigned int __init ata66_sis5513 (ide_hwif_t *hwif)
+static unsigned int __devinit ata66_sis5513 (ide_hwif_t *hwif)
{
u8 ata66 = 0;
@@ -897,7 +897,7 @@
return ata66;
}
-static void __init init_hwif_sis5513 (ide_hwif_t *hwif)
+static void __devinit init_hwif_sis5513 (ide_hwif_t *hwif)
{
hwif->autodma = 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/
Git-commits mailing list feed.
As of some time in the fairly near future, the [EMAIL PROTECTED] mailing list will be carrying real commits from Linus' live git repository, instead of just testing patches. Have fun. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.12-rc3 fails compile -- aic7xxx_osm.c
On Wed, Apr 20, 2005 at 10:08:27PM -0400, Pete Clements wrote: > FYI: [snip] In case anyone hits this problem but misses my post to the main "Re: Linux 2.6.12-rc3" thread, the fix is here: http://marc.theaimsgroup.com/?l=linux-scsi=111391769011616=2 -Barry K. Nathan <[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: Linux 2.6.12-rc3
Linux 2.6.12-rc3 is still missing the following compile fixes: [PATCH] fix ultrastor.c compile error http://marc.theaimsgroup.com/?l=linux-scsi=111391774018717=2 [PATCH] fix aic7xxx_osm.c compile failure (gcc 2.95.x only) http://marc.theaimsgroup.com/?l=linux-scsi=111391769011616=2 [linux-usb-devel] Re: [PATCH] fix microtek.c compile failure http://marc.theaimsgroup.com/?l=linux-usb-devel=111391865311903=2 Another LKML poster (who I added to CC on this message) already hit the aic7xxx compile failure with 2.6.12-rc3... -Barry K. Nathan <[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] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]
On Wed, 2005-04-20 at 22:58 -0400, Steven Rostedt wrote:
> I looked into the problem that jdavis had and found that the conversion
> of the timeval_to_jiffies was off by one.
>
> To convert tv.tv_sec = 0, tv.tv_usec = 1 to jiffies, you come up
> with an answer of 11 (assuming 1000 HZ).
>
OK, this bothered me that this patch seems to work, since the comments
around the USEC_ROUND seem to make sense. So I looked more closely into
this.
Is 11 jiffies correct for 10ms? Since the the USEC_CONVERSION contains
a TICK_NSEC which is suppose to (I believe) convert the number of CPU
ticks to nanoseconds. Since ticks don't map nicely to nanoseconds there
can be a discrepancy for the actual time. But this doesn't explain why
the patch changes everything into the desired result, assuming that
10 ms == 10 jiffies.
Maybe there's too much rounding going on. I'll have to take a deeper
look into this, but feel free to look yourselves! I'm going to bed.
I've attached my userland program if you want to play around with the
numbers.
> Here's the patch:
>
> --- ./include/linux/jiffies.h.orig2005-04-20 22:30:34.0 -0400
> +++ ./include/linux/jiffies.h 2005-04-20 22:39:42.0 -0400
> @@ -231,7 +231,7 @@
> * in jiffies (albit scaled), it is nothing but the bits we will shift
> * off.
> */
> -#define USEC_ROUND (u64)(((u64)1 << USEC_JIFFIE_SC) - 1)
> +#define USEC_ROUND (u64)(((u64)1 << (USEC_JIFFIE_SC - 1)))
> /*
> * The maximum jiffie value is (MAX_INT >> 1). Here we translate that
> * into seconds. The 64-bit case will overflow if we are not careful,
-- Steve
#include
#include
#include
typedef unsigned long long u64;
#define HZ 1000
#ifndef div_long_long_rem
#define div_long_long_rem(dividend,divisor,remainder) \
({ \
u64 result = dividend;\
*remainder = do_div(result,divisor); \
result; \
})
#endif
# define CLOCK_TICK_RATE 1193182 /* Underlying HZ */
#define NSEC_PER_SEC (10L)
#define NSEC_PER_USEC (1000L)
/*
* The following defines establish the engineering parameters of the PLL
* model. The HZ variable establishes the timer interrupt frequency, 100 Hz
* for the SunOS kernel, 256 Hz for the Ultrix kernel and 1024 Hz for the
* OSF/1 kernel. The SHIFT_HZ define expresses the same value as the
* nearest power of two in order to avoid hardware multiply operations.
*/
#if HZ >= 12 && HZ < 24
# define SHIFT_HZ 4
#elif HZ >= 24 && HZ < 48
# define SHIFT_HZ 5
#elif HZ >= 48 && HZ < 96
# define SHIFT_HZ 6
#elif HZ >= 96 && HZ < 192
# define SHIFT_HZ 7
#elif HZ >= 192 && HZ < 384
# define SHIFT_HZ 8
#elif HZ >= 384 && HZ < 768
# define SHIFT_HZ 9
#elif HZ >= 768 && HZ < 1536
# define SHIFT_HZ 10
#else
# error You lose.
#endif
/* LATCH is used in the interval timer and ftape setup. */
#define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ) /* For divider */
/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, the we can
* improve accuracy by shifting LSH bits, hence calculating:
* (NOM << LSH) / DEN
* This however means trouble for large NOM, because (NOM << LSH) may no
* longer fit in 32 bits. The following way of calculating this gives us
* some slack, under the following conditions:
* - (NOM / DEN) fits in (32 - LSH) bits.
* - (NOM % DEN) fits in (32 - LSH) bits.
*/
#define SH_DIV(NOM,DEN,LSH) ( ((NOM / DEN) << LSH)\
+ (((NOM % DEN) << LSH) + DEN / 2) / DEN)
/* HZ is the requested value. ACTHZ is actual HZ ("<< 8" is for accuracy) */
#define ACTHZ (SH_DIV (CLOCK_TICK_RATE, LATCH, 8))
/* TICK_NSEC is the time between ticks in nsec assuming real ACTHZ */
#define TICK_NSEC (SH_DIV (100UL * 1000, ACTHZ, 8))
/* TICK_USEC is the time between ticks in usec assuming fake USER_HZ */
#define TICK_USEC ((100UL + USER_HZ/2) / USER_HZ)
/* TICK_USEC_TO_NSEC is the time between ticks in nsec assuming real ACTHZ and */
/* a value TUSEC for TICK_USEC (can be set bij adjtimex) */
#define TICK_USEC_TO_NSEC(TUSEC) (SH_DIV (TUSEC * USER_HZ * 1000, ACTHZ, 8))
/* some arch's have a small-data section that can be accessed register-relative
* but that can only take up to, say, 4-byte variables. jiffies being part of
* an 8-byte variable may not be correctly accessed unless we force the issue
*/
#define __jiffy_data __attribute__((section(".data")))
/*
* The 64-bit value is not volatile - you MUST NOT read it
* without sampling the sequence number in xtime_lock.
* get_jiffies_64() will do this for you as appropriate.
*/
extern u64 __jiffy_data jiffies_64;
extern unsigned long volatile __jiffy_data jiffies;
#if (BITS_PER_LONG < 64)
u64 get_jiffies_64(void);
#else
static inline u64 get_jiffies_64(void)
{
return (u64)jiffies;
}
#endif
/*
* These inlines deal with timer wrapping correctly. You are
* strongly encouraged to use them
* 1. Because people otherwise forget
* 2. Because if the timer wrap changes in future you won't have to
* alter your driver code.
*
*
Re: [PATCH 4/6]cpu state clean after hot remove
On Tue, 2005-04-12 at 13:31, Li Shaohua wrote:
> @@ -1052,7 +1086,7 @@ static void __init smp_boot_cpus(unsigne
> if (max_cpus <= cpucount+1)
> continue;
>
> - if (do_boot_cpu(apicid))
> + if ((cpu = alloc_cpu_id() > 0) && do_boot_cpu(apicid, cpu))
> printk("CPU #%d not responding - cannot use it.\n",
> apicid);
> else
Oops, there is a typo in the patch. Andrew, please apply below patch
against above patch. Sorry for the inconvenience.
Thanks,
Shaohua
---
linux-2.6.11-root/arch/i386/kernel/smpboot.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/i386/kernel/smpboot.c~smpboot arch/i386/kernel/smpboot.c
--- linux-2.6.11/arch/i386/kernel/smpboot.c~smpboot 2005-04-21
11:27:53.913041424 +0800
+++ linux-2.6.11-root/arch/i386/kernel/smpboot.c2005-04-21
11:28:44.103411328 +0800
@@ -1166,7 +1166,7 @@ static void __init smp_boot_cpus(unsigne
if (max_cpus <= cpucount+1)
continue;
- if ((cpu = alloc_cpu_id() > 0) && do_boot_cpu(apicid, cpu))
+ if (((cpu = alloc_cpu_id()) <= 0) || do_boot_cpu(apicid, cpu))
printk("CPU #%d not responding - cannot use it.\n",
apicid);
else
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
Troy Benjegerdes wrote: Someone (aka Tospin, infinicon, and Amasso) should probably post a patch adding '#define VM_REGISTERD 0x0100', and some extensions to something like 'madvise' to set pages to be registered. My preference is said patch will also allow a way for the kernel to reclaim registered memory from an application under memory pressure. I don't know if VM_REGISTERED is a good idea or not, but it should be absolutely impossible for the kernel to reclaim "registered" (aka pinned) memory, no matter what. For RDMA services (such as Infiniband, iWARP, etc), it's normal for non-root processes to pin hundreds of megabytes of memory, and that memory better be locked to those physical pages until the application deregisters them. If kernel really thinks it needs to unpin those pages, then at the very least it should kill the process, and the syslog better have a very clear message indicating why. That way, the application doesn't continue thinking that everything's still going to work. If those pages become unpinned, the applications are going to experience serious data corruption. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alsa es1371's joystick functionality broken in 2.6.11-mm4
On Wednesday 20 April 2005 10:29 pm, Dmitry Torokhov wrote: > Ok... I know that sidewinder needs its timeouts increased to about 6ms to > work with 2.6. Have you tried OSS driver - to make sure that layer above > the soundcard works? Well, thats what I've been thinking thats screwing me. Because I've been using ALSA since my 2.4.x days (I switched over to 2.6 and 2.6.1), and I know my analog joystick works with ALSA and 2.6 (I just don't know when the bug appeared) and I've also upgraded my ALSA userland over the years. Infact, I'm almost convinced that the ALSA userland is causing the bug. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpDbDzler9i4.pgp Description: PGP signature
[PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]
I looked into the problem that jdavis had and found that the conversion of the timeval_to_jiffies was off by one. To convert tv.tv_sec = 0, tv.tv_usec = 1 to jiffies, you come up with an answer of 11 (assuming 1000 HZ). Here's the patch: --- ./include/linux/jiffies.h.orig 2005-04-20 22:30:34.0 -0400 +++ ./include/linux/jiffies.h 2005-04-20 22:39:42.0 -0400 @@ -231,7 +231,7 @@ * in jiffies (albit scaled), it is nothing but the bits we will shift * off. */ -#define USEC_ROUND (u64)(((u64)1 << USEC_JIFFIE_SC) - 1) +#define USEC_ROUND (u64)(((u64)1 << (USEC_JIFFIE_SC - 1))) /* * The maximum jiffie value is (MAX_INT >> 1). Here we translate that * into seconds. The 64-bit case will overflow if we are not careful, I wrote a user program that copies all of the jiffies.h and shows the output of the conversion. Without this patch you get: usec=1 jiffies = 11 usec=10010 jiffies = 11 usec=10020 jiffies = 11 . . . usec=10980 jiffies = 11 usec=10990 jiffies = 11 usec=11000 jiffies = 12 With the patch, you get: usec=1 jiffies = 10 usec=10010 jiffies = 10 usec=10020 jiffies = 10 . . . usec=10480 jiffies = 10 usec=10490 jiffies = 10 usec=10500 jiffies = 11 usec=10510 jiffies = 11 . . . usec=10990 jiffies = 11 usec=11000 jiffies = 11 Which I believe is the more desired result. I've kept jdavis original email to show where this was discovered. -- Steve On Fri, 2005-04-08 at 10:39 -0700, [EMAIL PROTECTED] wrote: > > Hello, > > I've created a pretty straight forward timer using setitimer, and noticed > some odd differences between 2.4 and 2.6, I wonder if I could get a > clarification if this is the way it should work, or if I should continue to > try to "fix" it. > > I create a RealTime Thread( SCHED_FIFO, maxPriority-1 ) (also tried > SCHED_RR) ... > > that creates a timer ...setitimer( ITIMER_REAL, SIGALRM) with a 10 milli > period. (I've also tried timer_create with CLOCK_REALTIME and SIGRTMIN) > > and then the thread does a sem_wait() on a semaphore. > > the signal handler does a sem_post() . > > > on 2.4.X the (idle) worst case latency is ~40 microseconds, > on 2.6.X the (idle) latency is about the same plus 1 tick of the scheduler > ~1000 micro seconds... Always.. Every time. > So to work around this on 2.6 I simply subtract 1 millisecond from my timer > as a fudge factor and everything works as expected. > > I've tried compiling various kernels (2.6.9, 2.6.11) with kernel pre-empting > on, etc.. > > Is this the correct behavior? If so I'm curious who is using up the extra > Tick? > Does the asynch signal handler use up the whole tick even though it only has > to sem_post()? > > I am not subscribed to the list, so I would appreciate a CC. > Thanks, > -JD > - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/net/skfp/: fix LITTLE_ENDIAN
On Wed, 20 Apr 2005 04:17:08 +0200 Adrian Bunk wrote: | This patch fixes the LITTLE_ENDIAN #define. and a function prototype. | Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> | | --- | | drivers/net/skfp/h/osdef1st.h |2 ++ | drivers/net/skfp/smt.c|2 +- | 2 files changed, 3 insertions(+), 1 deletion(-) | | --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/h/osdef1st.h.old 2005-04-20 01:22:21.0 +0200 | +++ linux-2.6.12-rc2-mm3-full/drivers/net/skfp/h/osdef1st.h 2005-04-20 01:23:55.0 +0200 | @@ -20,6 +20,8 @@ | // HWM (HardWare Module) Definitions | // --- | | +#include | + | #ifdef __LITTLE_ENDIAN | #define LITTLE_ENDIAN | #else | --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/smt.c.old 2005-04-20 01:26:34.0 +0200 | +++ linux-2.6.12-rc2-mm3-full/drivers/net/skfp/smt.c 2005-04-20 01:26:22.0 +0200 | @@ -86,7 +86,7 @@ | static void smt_send_sif_operation(struct s_smc *smc, struct fddi_addr *dest, | u_long tid, int local); | #ifdef LITTLE_ENDIAN | -static void smt_string_swap(void); | +static void smt_string_swap(char *data, const char *format, int len); | #endif | static void smt_add_frame_len(SMbuf *mb, int len); | static void smt_fill_una(struct s_smc *smc, struct smt_p_una *una); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 scsi-misc-2.6 03/05] scsi: make scsi_queue_insert() use blk_requeue_request()
Hello, James.
This is the modified patch with the comment (slightly modified).
With this patch, the next patch in this patchset complains about line
offset but it's okay.
Thanks.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: scsi-reqfn-export/drivers/scsi/scsi_lib.c
===
--- scsi-reqfn-export.orig/drivers/scsi/scsi_lib.c 2005-04-21
11:33:13.0 +0900
+++ scsi-reqfn-export/drivers/scsi/scsi_lib.c 2005-04-21 11:39:17.0
+0900
@@ -96,6 +96,8 @@ int scsi_insert_special_req(struct scsi_
return 0;
}
+static void scsi_run_queue(struct request_queue *q);
+
/*
* Function:scsi_queue_insert()
*
@@ -119,6 +121,8 @@ int scsi_queue_insert(struct scsi_cmnd *
{
struct Scsi_Host *host = cmd->device->host;
struct scsi_device *device = cmd->device;
+ struct request_queue *q = device->request_queue;
+ unsigned long flags;
SCSI_LOG_MLQUEUE(1,
printk("Inserting command %p into mlqueue\n", cmd));
@@ -154,17 +158,22 @@ int scsi_queue_insert(struct scsi_cmnd *
scsi_device_unbusy(device);
/*
-* Insert this command at the head of the queue for it's device.
-* It will go before all other commands that are already in the queue.
+* Requeue this command. It will go before all other commands
+* that are already in the queue.
*
* NOTE: there is magic here about the way the queue is plugged if
* we have no outstanding commands.
*
-* Although this *doesn't* plug the queue, it does call the request
+* Although we *don't* plug the queue, we call the request
* function. The SCSI request function detects the blocked condition
* and plugs the queue appropriately.
-*/
- blk_insert_request(device->request_queue, cmd->request, 1, cmd, 1);
+ */
+ spin_lock_irqsave(q->queue_lock, flags);
+ blk_requeue_request(q, cmd->request);
+ spin_unlock_irqrestore(q->queue_lock, flags);
+
+ scsi_run_queue(q);
+
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: [PATCH scsi-misc-2.6 03/05] scsi: make scsi_queue_insert() use blk_requeue_request()
James Bottomley wrote: > On Thu, 2005-04-21 at 09:20 +0900, Tejun Heo wrote: > >> Hello, James. >> >>James Bottomley wrote: >> >>>On Wed, 2005-04-20 at 08:15 +0900, Tejun Heo wrote: >>> >>> -* Insert this command at the head of the queue for it's device. -* It will go before all other commands that are already in the queue. -* -* NOTE: there is magic here about the way the queue is plugged if -* we have no outstanding commands. -* -* Although this *doesn't* plug the queue, it does call the request -* function. The SCSI request function detects the blocked condition -* and plugs the queue appropriately. >>> >>> >>>This comment still looks appropriate to me ... why do you want to remove >>>it? >>> >> >> Well, the thing is that we don't really care what exactly happens to >>the queue or how the queue is plugged or not. All we need to do are to >>requeue the request and kick the queue in the ass. Hmmm, maybe I should >>keep the comment about how the request will be put at the head of the >>queue, but the second part about plugging doesn't really belong here, I >>think. > > > Really? We do care greatly. If you requeue with no other outstanding > commands to the device, the block queue will never restart unless it's > plugged, and the device will hang. The comment is explaining how this > happens. > Yes, you're right. My point was that that's scsi_run_queue()'s business. We don't need to comment that deep when we're requeueing a request. After we put a request on a queue, we kick the queue. It's the queue running function's responsibility to determine whether to run the request right away or to defer processing (and thus plug). I wasn't saying that the eventual plugging isn't necessary, but that the comment is sort of excessive. Anyways, if you think the comment is necessary, I don't feel strong against it. I'll rewrite above comment to fit the new code and repost this patch soon. > >> Yes, that will be more efficient but I don't think it would make >>any >>noticeable difference. IMO, universally using scsi_run_queue() to >>kick >>scsi request queues is better than mixing blk_run_queue() and >>scsi_run_queue() for probably unnoticeable optimization. If we start >>to >>mix'em, we need to rationalize why specific one is chosen in specific >>places and that's just unnecessary. > > > Fair enough. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] prism54 oops on cardbus card removal
Apr 21 11:13:33 gaston kernel: [233990.968209] PCI: Enabling device 0001:11:00.0 ( -> 0002) Apr 21 11:13:37 gaston kernel: [233995.162668] eth3: resetting device... Apr 21 11:13:37 gaston kernel: [233995.162699] eth3: uploading firmware... Apr 21 11:13:37 gaston kernel: [233995.331330] eth3: firmware version: 1.0.4.3 Apr 21 11:13:37 gaston kernel: [233995.331420] eth3: firmware upload complete Apr 21 11:13:38 gaston kernel: [233995.566992] eth3: interface reset complete Apr 21 12:16:53 gaston kernel: [237791.796994] eth3: hot unplug detected Apr 21 12:16:53 gaston kernel: [237791.797007] eth3: removing device Apr 21 12:16:53 gaston kernel: [237791.797023] eth3: islpci_close () Apr 21 12:16:53 gaston kernel: [237791.876915] eth3: timeout waiting for mgmt response 1000, triggering device Apr 21 12:17:48 gaston kernel: [237791.976919] remove@/devices/pci0001:10/0001:10:1a.0/0001:11:00.0: timeout waiting for mgmt response 900, triggering device Apr 21 12:17:48 gaston kernel: [237846.858624] Oops: kernel access of bad area, sig: 11 [#1] Apr 21 12:17:48 gaston kernel: [237846.858644] NIP: C29AE8A0 LR: C29AE548 SP: BFFCDE00 REGS: bffcdd50 TRAP: 0300 Not tainted Apr 21 12:17:49 gaston kernel: [237846.858656] MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 Apr 21 12:17:49 gaston kernel: [237846.858664] DAR: , DSISR: 4200 Apr 21 12:17:49 gaston kernel: [237846.858673] TASK = bffc0b70[3] 'events/0' THREAD: bffcc000 Apr 21 12:17:49 gaston kernel: [237846.858680] Last syscall: 120 Apr 21 12:17:49 gaston kernel: [237846.858685] GPR00: C29AE548 BFFCDE00 BFFC0B70 BF499D60 803E0FD0 Apr 21 12:17:49 gaston kernel: [237846.858706] GPR08: 803E137C 0002 BEE29E7C BFFCDD00 432E7FAE Apr 21 12:17:49 gaston kernel: [237846.858725] GPR16: 1713 BFFCDE40 BFFCDE98 Apr 21 12:17:49 gaston kernel: [237846.858744] GPR24: FF92 1713 86818DCC 86818A20 Apr 21 12:17:49 gaston kernel: [237846.858765] NIP [c29ae8a0] isl38xx_trigger_device+0x190/0x1c4 [prism54] Apr 21 12:17:49 gaston kernel: [237846.858813] LR [c29ae548] islpci_mgt_transaction+0x1b8/0x1d4 [prism54] Apr 21 12:17:49 gaston kernel: [237846.858837] Call trace: Apr 21 12:17:49 gaston kernel: [237846.858843] [c29ae548] islpci_mgt_transaction+0x1b8/0x1d4 [prism54] Apr 21 12:17:49 gaston kernel: [237846.858867] [c29b4ce8] mgt_get_request+0x274/0x2ec [prism54] Apr 21 12:17:49 gaston kernel: [237846.858894] [c29aed30] prism54_update_stats+0x74/0x164 [prism54] Apr 21 12:17:49 gaston kernel: [237846.858918] [80031018] worker_thread+0x17c/0x21c Apr 21 12:17:49 gaston kernel: [237846.858936] [80035f40] kthread+0xb8/0xc0 Apr 21 12:17:49 gaston kernel: [237846.858947] [8000738c] kernel_thread+0x44/0x60 -- Benjamin Herrenschmidt <[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: alsa es1371's joystick functionality broken in 2.6.11-mm4
On Wednesday 20 April 2005 21:21, Patrick McFarland wrote: > On Wednesday 20 April 2005 10:12 pm, Dmitry Torokhov wrote: > > On Wednesday 20 April 2005 20:42, Patrick McFarland wrote: > > > On Wednesday 20 April 2005 12:47 am, Patrick McFarland wrote: > > > > I just tested 2.6.6, it seems to be broken too. I wonder if this > > > > actually is a kernel issue, I should have found a working kernel by > > > > now. I'll continue to 2.6.5. > > > > > > I just tried 2.6.5 and 2.6.4. No go. Only 3 kernels left. > > > > Are you testing with sidewinder? > > I test both my analog and sidewinders. Not that it matters, my analog is the > one I had first, I only got the sidewinder recently. > Ok... I know that sidewinder needs its timeouts increased to about 6ms to work with 2.6. Have you tried OSS driver - to make sure that layer above the soundcard works? -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alsa es1371's joystick functionality broken in 2.6.11-mm4
On Wednesday 20 April 2005 10:12 pm, Dmitry Torokhov wrote: > On Wednesday 20 April 2005 20:42, Patrick McFarland wrote: > > On Wednesday 20 April 2005 12:47 am, Patrick McFarland wrote: > > > I just tested 2.6.6, it seems to be broken too. I wonder if this > > > actually is a kernel issue, I should have found a working kernel by > > > now. I'll continue to 2.6.5. > > > > I just tried 2.6.5 and 2.6.4. No go. Only 3 kernels left. > > Are you testing with sidewinder? I test both my analog and sidewinders. Not that it matters, my analog is the one I had first, I only got the sidewinder recently. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpNoA6bGfyxy.pgp Description: PGP signature
Re: [PATCH] hfsplus: add an option to force r/w mount
On 20 Apr 2005 at 22h04, Roman Zippel wrote: Hi, > > for some reason yet unknown, fsck.hfsplus doesn't correctly set the > > HFSPLUS_VOL_UNMNT flag here. > > If fsck doesn't mark it clean, there must be a reason By the way, the reason is that this stupid utility opens the device read-only (hence it can't fix nothing). from hfsplusutils/libhfsp/src/fscheck.c: result = fscheck_volume_open(, device, HFSP_MODE_RDONLY); Seeing that it has been untouched since 2002, I guess it'll be hard to get it fixed. Or maybe it's just me being idiot and I should use another fsck ? -- Colin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
On Mon, Apr 18, 2005 at 10:07:12PM +0200, Bernhard Fischer wrote: > On Mon, Apr 18, 2005 at 09:40:40PM +0200, Arjan van de Ven wrote: > >On Mon, 2005-04-18 at 11:25 -0500, Timur Tabi wrote: > >> Arjan van de Ven wrote: > >> > >> > this is a myth; linux is free to move the page about in physical memory > >> > even if it's mlock()ed!! > darn, yes, this is true. > I know people who introduced > #define VM_RESERVED 0x0008 /* Don't unmap it from swap_out > */ Someone (aka Tospin, infinicon, and Amasso) should probably post a patch adding '#define VM_REGISTERD 0x0100', and some extensions to something like 'madvise' to set pages to be registered. My preference is said patch will also allow a way for the kernel to reclaim registered memory from an application under memory pressure. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 scsi-misc-2.6 03/05] scsi: make scsi_queue_insert() use blk_requeue_request()
On Thu, 2005-04-21 at 09:20 +0900, Tejun Heo wrote: > Hello, James. > > James Bottomley wrote: > > On Wed, 2005-04-20 at 08:15 +0900, Tejun Heo wrote: > > > >>-* Insert this command at the head of the queue for it's device. > >>-* It will go before all other commands that are already in the queue. > >>-* > >>-* NOTE: there is magic here about the way the queue is plugged if > >>-* we have no outstanding commands. > >>-* > >>-* Although this *doesn't* plug the queue, it does call the request > >>-* function. The SCSI request function detects the blocked condition > >>-* and plugs the queue appropriately. > > > > > > This comment still looks appropriate to me ... why do you want to remove > > it? > > > > Well, the thing is that we don't really care what exactly happens to > the queue or how the queue is plugged or not. All we need to do are to > requeue the request and kick the queue in the ass. Hmmm, maybe I should > keep the comment about how the request will be put at the head of the > queue, but the second part about plugging doesn't really belong here, I > think. Really? We do care greatly. If you requeue with no other outstanding commands to the device, the block queue will never restart unless it's plugged, and the device will hang. The comment is explaining how this happens. > Yes, that will be more efficient but I don't think it would make > any > noticeable difference. IMO, universally using scsi_run_queue() to > kick > scsi request queues is better than mixing blk_run_queue() and > scsi_run_queue() for probably unnoticeable optimization. If we start > to > mix'em, we need to rationalize why specific one is chosen in specific > places and that's just unnecessary. Fair enough. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alsa es1371's joystick functionality broken in 2.6.11-mm4
On Wednesday 20 April 2005 20:42, Patrick McFarland wrote: > On Wednesday 20 April 2005 12:47 am, Patrick McFarland wrote: > > I just tested 2.6.6, it seems to be broken too. I wonder if this actually > > is a kernel issue, I should have found a working kernel by now. I'll > > continue to 2.6.5. > > I just tried 2.6.5 and 2.6.4. No go. Only 3 kernels left. > Are you testing with sidewinder? -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.12-rc3 fails compile -- aic7xxx_osm.c
FYI: CC drivers/scsi/aic7xxx/aic7xxx_osm.o drivers/scsi/aic7xxx/aic7xxx_osm.c: In function `ahc_linux_init': drivers/scsi/aic7xxx/aic7xxx_osm.c:3608: parse error before `int' drivers/scsi/aic7xxx/aic7xxx_osm.c:3609: `rc' undeclared (first use in this function) drivers/scsi/aic7xxx/aic7xxx_osm.c:3609: (Each undeclared identifier is reported only once drivers/scsi/aic7xxx/aic7xxx_osm.c:3609: for each function it appears in.) drivers/scsi/aic7xxx/aic7xxx_osm.c: At top level: drivers/scsi/aic7xxx/aic7xxx_osm.c:744: warning: `ahc_linux_detect' defined but not used make[3]: *** [drivers/scsi/aic7xxx/aic7xxx_osm.o] Error 1 make[2]: *** [drivers/scsi/aic7xxx] Error 2 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 -- Pete Clements - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 2.6.12-rc3
Patrick McFarland wrote: On Wednesday 20 April 2005 09:09 pm, Alejandro Bonilla wrote: Why is kb not used anymore? What happened? Linus decided that keyboards are out, and voice activation is in. Remember to use a high quality microphone! Ohh _G_ Is that Why!? I thought it was cause there were some problems with 2 guys and a non-free Software? James gave me what I needed to know. ;-) Thanks. And I really hope that Linus can find a way to do things better for him and everyone else. Hopefully someone can create an SCM as nice and good as I read BK was... Sorry for invoking this old topic. - Alejandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alsa es1371's joystick functionality broken in 2.6.11-mm4
On Wednesday 20 April 2005 12:47 am, Patrick McFarland wrote: > I just tested 2.6.6, it seems to be broken too. I wonder if this actually > is a kernel issue, I should have found a working kernel by now. I'll > continue to 2.6.5. I just tried 2.6.5 and 2.6.4. No go. Only 3 kernels left. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpr6v9XlFNS2.pgp Description: PGP signature
Re: Linux 2.6.12-rc3
On Wednesday 20 April 2005 09:09 pm, Alejandro Bonilla wrote: > Why is kb not used anymore? What happened? Linus decided that keyboards are out, and voice activation is in. Remember to use a high quality microphone! -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpA1nFX5rQ0f.pgp Description: PGP signature
Re: [PATCH] hfsplus: add an option to force r/w mount
On 20 Apr 2005 at 22h04, Roman Zippel wrote: Hi, > Hi, > > On Wed, 20 Apr 2005, Colin Leroy wrote: > > > for some reason yet unknown, fsck.hfsplus doesn't correctly set the > > HFSPLUS_VOL_UNMNT flag here. > > If fsck doesn't mark it clean, there must be a reason and that also > means you shouldn't mount it writable. that's what i thought too, but adding debug printf() to it, i see that it marks it clean at the end. However that doesn't seem to effectively land on the disc. imho the patch has an interest anyway... -- Colin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 2.6.12-rc3
Have a look through the mail archives and try "Bitkeeper and Linux" in google, lets just say its been interesting. -- James Purser http://ksit.dynalias.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: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
On Wed, 2005-04-20 at 10:55 -0600, jmerkey wrote: > > For 3Ware, you need to chage the queue depths, and you will see > dramatically improved performance. 3Ware can take requests > a lot faster than Linux pushes them out. Try changing this instead, you > won't be going to sleep all the time waiting on the read/write > request queues to get "unstarved". > > > /linux/include/linux/blkdev.h > > //#define BLKDEV_MIN_RQ 4 > //#define BLKDEV_MAX_RQ 128 /* Default maximum */ > #define BLKDEV_MIN_RQ 4096 > #define BLKDEV_MAX_RQ 8192 /* Default maximum */ > BTW, don't do this. BLKDEV_MIN_RQ sets the size of the mempool reserved requests and will only get slightly used in low memory conditions, so most memory will probably be wasted. Just change /sys/block/xxx/queue/nr_requests Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 3/4] squashfs: (void*)ify squashfs_get_cached_block
Jörn
--
It's just what we asked for, but not what we want!
-- anonymous
Signed-off-by: Jörn Engel <[EMAIL PROTECTED]>
---
fs/squashfs/inode.c| 58 -
fs/squashfs/squashfs.h |2 -
2 files changed, 30 insertions(+), 30 deletions(-)
--- linux-2.6.12-rc2cow/fs/squashfs/inode.c~squashfs_cu32005-04-20
16:34:43.619956672 +0200
+++ linux-2.6.12-rc2cow/fs/squashfs/inode.c 2005-04-20 16:40:47.498638704
+0200
@@ -280,7 +280,7 @@ read_failure:
}
-int squashfs_get_cached_block(struct super_block *s, char *buffer,
+int squashfs_get_cached_block(struct super_block *s, void *buffer,
unsigned int block, unsigned int offset,
int length, unsigned int *next_block,
unsigned int *next_offset)
@@ -399,14 +399,14 @@ static int get_fragment_location(struct
if (msBlk->swap) {
squashfs_fragment_entry sfragment_entry;
- if (!squashfs_get_cached_block(s, (char *) _entry,
+ if (!squashfs_get_cached_block(s, _entry,
start_block, offset,
sizeof(sfragment_entry), _block,
))
return 0;
SQUASHFS_SWAP_FRAGMENT_ENTRY(_entry, _entry);
} else
- if (!squashfs_get_cached_block(s, (char *) _entry,
+ if (!squashfs_get_cached_block(s, _entry,
start_block, offset,
sizeof(fragment_entry), _block,
))
@@ -549,14 +549,14 @@ static struct inode *squashfs_iget(struc
if (msBlk->swap) {
squashfs_base_inode_header sinodeb;
- if (!squashfs_get_cached_block(s, (char *) , block,
+ if (!squashfs_get_cached_block(s, , block,
offset, sizeof(sinodeb), _block,
_offset))
goto failed_read;
SQUASHFS_SWAP_BASE_INODE_HEADER(, ,
sizeof(sinodeb));
} else
- if (!squashfs_get_cached_block(s, (char *) , block,
+ if (!squashfs_get_cached_block(s, , block,
offset, sizeof(inodeb), _block,
_offset))
goto failed_read;
@@ -569,7 +569,7 @@ static struct inode *squashfs_iget(struc
if (msBlk->swap) {
squashfs_reg_inode_header sinodep;
- if (!squashfs_get_cached_block(s, (char *)
+ if (!squashfs_get_cached_block(s,
, block, offset,
sizeof(sinodep), _block,
_offset))
@@ -577,7 +577,7 @@ static struct inode *squashfs_iget(struc
SQUASHFS_SWAP_REG_INODE_HEADER(,
);
} else
- if (!squashfs_get_cached_block(s, (char *)
+ if (!squashfs_get_cached_block(s,
, block, offset,
sizeof(inodep), _block,
_offset))
@@ -624,7 +624,7 @@ static struct inode *squashfs_iget(struc
if (msBlk->swap) {
squashfs_dir_inode_header sinodep;
- if (!squashfs_get_cached_block(s, (char *)
+ if (!squashfs_get_cached_block(s,
, block, offset,
sizeof(sinodep), _block,
_offset))
@@ -632,7 +632,7 @@ static struct inode *squashfs_iget(struc
SQUASHFS_SWAP_DIR_INODE_HEADER(,
);
} else
- if (!squashfs_get_cached_block(s, (char *)
+ if (!squashfs_get_cached_block(s,
, block, offset,
sizeof(inodep), _block,
_offset))
@@ -664,7 +664,7 @@ static struct inode *squashfs_iget(struc
if (msBlk->swap) {
squashfs_ldir_inode_header sinodep;
- if (!squashfs_get_cached_block(s, (char *)
+ if
[PATCH 4/4] squashfs: (void*)ify squashfs_read_data
Jörn
--
Anything that can go wrong, will.
-- Finagle's Law
Signed-off-by: Jörn Engel <[EMAIL PROTECTED]>
---
fs/squashfs/inode.c| 11 +--
fs/squashfs/squashfs.h |2 +-
2 files changed, 6 insertions(+), 7 deletions(-)
--- linux-2.6.12-rc2cow/fs/squashfs/inode.c~squashfs_cu42005-04-20
16:40:47.498638704 +0200
+++ linux-2.6.12-rc2cow/fs/squashfs/inode.c 2005-04-20 22:44:04.723347592
+0200
@@ -172,7 +172,7 @@ static struct buffer_head *get_block_len
}
-unsigned int squashfs_read_data(struct super_block *s, char *buffer,
+unsigned int squashfs_read_data(struct super_block *s, void *buffer,
unsigned int index, unsigned int length,
unsigned int *next_index)
{
@@ -324,7 +324,6 @@ int squashfs_get_cached_block(struct sup
if (msBlk->block_cache[i].block ==
SQUASHFS_INVALID_BLK) {
if (!(msBlk->block_cache[i].data =
- (unsigned char *)
kmalloc(SQUASHFS_METADATA_SIZE,
GFP_KERNEL))) {
ERROR("Failed to allocate cache"
@@ -854,7 +853,7 @@ static int squashfs_fill_super(struct su
init_waitqueue_head(>waitq);
init_waitqueue_head(>fragment_wait_queue);
- if (!squashfs_read_data(s, (char *) sBlk, SQUASHFS_START,
+ if (!squashfs_read_data(s, sBlk, SQUASHFS_START,
sizeof(squashfs_super_block) |
SQUASHFS_COMPRESSED_BIT_BLOCK, NULL)) {
SERROR("unable to read superblock\n");
@@ -955,7 +954,7 @@ static int squashfs_fill_super(struct su
if (msBlk->swap) {
squashfs_uid suid[sBlk->no_uids + sBlk->no_guids];
- if (!squashfs_read_data(s, (char *) , sBlk->uid_start,
+ if (!squashfs_read_data(s, , sBlk->uid_start,
((sBlk->no_uids + sBlk->no_guids) *
sizeof(squashfs_uid)) |
SQUASHFS_COMPRESSED_BIT_BLOCK, NULL)) {
@@ -966,7 +965,7 @@ static int squashfs_fill_super(struct su
SQUASHFS_SWAP_DATA(msBlk->uid, suid, (sBlk->no_uids +
sBlk->no_guids), (sizeof(squashfs_uid) * 8));
} else
- if (!squashfs_read_data(s, (char *) msBlk->uid, sBlk->uid_start,
+ if (!squashfs_read_data(s, msBlk->uid, sBlk->uid_start,
((sBlk->no_uids + sBlk->no_guids) *
sizeof(squashfs_uid)) |
SQUASHFS_COMPRESSED_BIT_BLOCK, NULL)) {
@@ -1001,7 +1000,7 @@ static int squashfs_fill_super(struct su
}
if (SQUASHFS_FRAGMENT_INDEX_BYTES(sBlk->fragments) &&
- !squashfs_read_data(s, (char *)
+ !squashfs_read_data(s,
msBlk->fragment_index,
sBlk->fragment_table_start,
SQUASHFS_FRAGMENT_INDEX_BYTES
--- linux-2.6.12-rc2cow/fs/squashfs/squashfs.h~squashfs_cu4 2005-04-20
16:37:15.900806464 +0200
+++ linux-2.6.12-rc2cow/fs/squashfs/squashfs.h 2005-04-20 22:42:45.917327928
+0200
@@ -37,7 +37,7 @@
#define WARNING(s, args...)printk(KERN_WARNING "SQUASHFS: "s, ## args)
-extern unsigned int squashfs_read_data(struct super_block *s, char *buffer,
+extern unsigned int squashfs_read_data(struct super_block *s, void *buffer,
unsigned int index, unsigned int length,
unsigned int *next_index);
extern int squashfs_get_cached_block(struct super_block *s, void *buffer,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] squashfs: kmalloc (less stack, less casts)
Jörn
--
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
-- M.A. Jackson
Signed-off-by: Jörn Engel <[EMAIL PROTECTED]>
---
fs/squashfs/inode.c | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
--- linux-2.6.12-rc2cow/fs/squashfs/inode.c~squashfs_cu22005-04-20
08:11:10.0 +0200
+++ linux-2.6.12-rc2cow/fs/squashfs/inode.c 2005-04-20 16:34:43.619956672
+0200
@@ -1453,11 +1453,14 @@ static int squashfs_readdir(struct file
next_offset = SQUASHFS_I(i)->offset, length = 0, dirs_read = 0,
dir_count;
squashfs_dir_header dirh;
- char buffer[sizeof(squashfs_dir_entry) + SQUASHFS_NAME_LEN + 1];
- squashfs_dir_entry *dire = (squashfs_dir_entry *) buffer;
+ squashfs_dir_entry *dire;
TRACE("Entered squashfs_readdir [%x:%x]\n", next_block, next_offset);
+ dire = kmalloc(sizeof(*dire) + SQUASHFS_NAME_LEN + 1, GFP_KERNEL);
+ if (!dire)
+ return -ENOMEM;
+
length = get_dir_index_using_offset(i->i_sb, _block, _offset,
SQUASHFS_I(i)->u.s2.directory_index_start,
SQUASHFS_I(i)->u.s2.directory_index_offset,
@@ -1533,6 +1536,7 @@ static int squashfs_readdir(struct file
squashfs_filetype_table[dire->type])
< 0) {
TRACE("Filldir returned less than 0\n");
+ kfree(dire);
return dirs_read;
}
file->f_pos = length;
@@ -1540,11 +1544,13 @@ static int squashfs_readdir(struct file
}
}
+ kfree(dire);
return dirs_read;
failed_read:
ERROR("Unable to read directory block [%x:%x]\n", next_block,
next_offset);
+ kfree(dire);
return 0;
}
@@ -1562,12 +1568,15 @@ static struct dentry *squashfs_lookup(st
next_offset = SQUASHFS_I(i)->offset, length = 0,
dir_count;
squashfs_dir_header dirh;
- char buffer[sizeof(squashfs_dir_entry) + SQUASHFS_NAME_LEN];
- squashfs_dir_entry *dire = (squashfs_dir_entry *) buffer;
+ squashfs_dir_entry *dire;
int sorted = sBlk->s_major == 2 && sBlk->s_minor >= 1;
TRACE("Entered squashfs_lookup [%x:%x]\n", next_block, next_offset);
+ dire = kmalloc(sizeof(*dire) + SQUASHFS_NAME_LEN + 1, GFP_KERNEL);
+ if (!dire)
+ return ERR_PTR(-ENOMEM);
+
length = get_dir_index_using_name(i->i_sb, _block, _offset,
SQUASHFS_I(i)->u.s2.directory_index_start,
SQUASHFS_I(i)->u.s2.directory_index_offset,
@@ -1645,7 +1654,8 @@ static struct dentry *squashfs_lookup(st
exit_loop:
d_add(dentry, inode);
- return ERR_PTR(0);
+ kfree(dire);
+ return NULL;
failed_read:
ERROR("Unable to read directory block [%x:%x]\n", next_block,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 2.6.12-rc3
Linus Torvalds wrote: Ok, you know what the subject line means by now, but this release is a bit different from the usual ones, for obvious reasons. It's the first in a _long_ time that I've done without using BK, and it's the first one ever that has been built up completely with "git". It's available both as a patch (against 2.6.11) and as a tar-ball, and for non-BK users the biggest difference is probably that the ChangeLog format has changed a bit. And it will probably continue to evolve, since I don't have my "release-script" tools set up for the new setup, so this release was done largely manually with some ad-hoc scripting to get the ChangeLog information etc out of git. For BK users, I hope we can get a BK tree that tracks this set up soon, and it should hopefully not be too disruptive either. Excuse me for being so uninformed, poor reader and so on... Why is kb not used anymore? What happened? Thanks for the time, - Alejandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] remove some usesless casts
On Wed, 20 April 2005 21:51:15 +0100, Phillip Lougher wrote: > Jörn Engel wrote: > > >Your definition of _unnecessary_ casts may differ from mine. > >Basically, every cast is unnecessary, except for maybe one or two - if > >that many. > > Well we agree to differ then. In my experience casts are sometimes > necessary, and are often less clumsy than the alternatives (such as > unions). This is probably a generational thing, the fashion today is to > make languages much more strongly typechecked than before. I never claimed to replace the casts with unions. ;) Jörn -- Homo Sapiens is a goal, not a description. -- unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.12-rc3
Ok, you know what the subject line means by now, but this release is a bit different from the usual ones, for obvious reasons. It's the first in a _long_ time that I've done without using BK, and it's the first one ever that has been built up completely with "git". It's available both as a patch (against 2.6.11) and as a tar-ball, and for non-BK users the biggest difference is probably that the ChangeLog format has changed a bit. And it will probably continue to evolve, since I don't have my "release-script" tools set up for the new setup, so this release was done largely manually with some ad-hoc scripting to get the ChangeLog information etc out of git. For BK users, I hope we can get a BK tree that tracks this set up soon, and it should hopefully not be too disruptive either. And for the crazy people, the git archive on kernel.org is up and running under /pub/scm/linux/kernel/git/torvalds/linux-2.6.git. For the adventurous of you, the name of the 2.6.12-rc3 release is a very nice and readable: a2755a80f40e5794ddc20e00f781af9d6320fafb and eventually I'll try to make sure that I actually accompany all releases with the SHA1 git name of the release signed with a digital signature. One of the tools I don't have set up yet is the old "shortlog" script, so I did this really hacky conversion. You don't want to know, but let's say that I'm re-aquainting myself with 'sed' after a long time ;). But if some lines look like they got hacked up in the middle, rest assured that that's exactly what happened, and the long log should have the rest ... Linus Changes since 2.6.12-rc2: Adrian Bunk: [PATCH] MAINTAINERS: remove obsolete ACP/MWAVE MODEM entry [PATCH] let SOUND_AD1889 depend on PCI Alan Stern: [PATCH] USB: USB API documentation modification Alexander Nyberg: [PATCH] swsusp: SMP fix Andi Kleen: [PATCH] x86-64/i386: Revert cpuinfo siblings behaviour back to 2.6.10 [PATCH] x86-64: Fix BUG() [PATCH] x86_64: Add acpi_skip_timer_override option [PATCH] x86_64: Always use CPUID 8008 to figure out MTRR address space size [PATCH] x86_64: Call do_notify_resume unconditionally in entry.S [PATCH] x86_64: Correct wrong comment in local.h [PATCH] x86_64: Don't assume future AMD CPUs have K8 compatible performance counters [PATCH] x86_64: Dump stack and prevent recursion on early fault [PATCH] x86_64: Final support for AMD dual core [PATCH] x86_64: Fix a small missing schedule race [PATCH] x86_64: Fix interaction of single stepping with debuggers [PATCH] x86_64: Handle programs that set TF in user space using popf while single stepping [PATCH] x86_64: Keep only a single debug notifier chain [PATCH] x86_64: Make IRDA devices are not really ISA devices not depend on CONFIG_ISA [PATCH] x86_64: Make kernel math errors a die() now [PATCH] x86_64: Minor microoptimization in syscall entry slow path [PATCH] x86_64: Port over e820 gap detection from i386 [PATCH] x86_64: Regularize exception stack handling [PATCH] x86_64: Remove duplicated syscall entry. [PATCH] x86_64: Remove excessive stack allocation in MCE code with large NR_CPUS [PATCH] x86_64: Remove unused macro in preempt support [PATCH] x86_64: Rename the extended cpuid level field [PATCH] x86_64: Rewrite exception stack backtracing [PATCH] x86_64: Some fixes for single step handling [PATCH] x86_64: Support constantly ticking TSCs [PATCH] x86_64: Switch SMP bootup over to new CPU hotplug state machine [PATCH] x86_64: Use a VMA for the 32bit vsyscall [PATCH] x86_64: Use a common function to find code segment bases [PATCH] x86_64: Use the e820 hole to map the IOMMU/AGP aperture [PATCH] x86_64: Use the extended RIP MSR for machine check reporting if available. [PATCH] x86_64: add support for Intel dual-core detection and displaying [PATCH] x86_64: clean up ptrace single-stepping [PATCH] x86_64: disable interrupts during SMP bogomips checking Andrea Arcangeli: [PATCH] oom-killer disable for iscsi/lvm2/multipath userland critical sections Andrew Morton: [PATCH] Fix acl Oops [PATCH] USB: usb_cdc build fix [PATCH] USB: usbnet printk warning fix [PATCH] arm: add comment about dma_supported() [PATCH] arm: add comment about max_low_pfn/max_pfn [PATCH] arm: fix SIGBUS handling [PATCH] arm: fix help text for ixdp465 [PATCH] end_buffer_write_sync() avoid pointless assignments [PATCH] fix Bug 4395: modprobe bttv freezes the computer [PATCH] jbd dirty buffer leak fix [PATCH] vmscan: pageout(): remove unneeded test [PATCH] x86_64 show_stack(): call touch_nmi_watchdog Anton Blanchard: [PATCH] ppc64: remove -fno-omit-frame-pointer Arnaldo Carvalho de Melo: [PATCH] net: don't call kmem_cache_create with a spinlock held [SOCK]: on failure free the sock from the right place Artem B. Bityuckiy:
Re: Kernel page table and module text
> > > I want to find where each module is loaded in memory by traversing the > > module list . Once I have the address and the size of the module, I > > want to read the bytes in memory of the module and hash it to check > > it's integrity. > > JFTR: This may work against random memory corruption, but it will fail for > detecting attacks. Thats all I use my code for, dumb government regulation says you have to check for random memory corruption in text segments.. written back in the old 8-bit controller + EEPROM days ... Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][MTHCA] fix sparc build WAS: Re: [openib-general] [PATCH][RFC][3/4] IB: userspace verbs mthca changes
On Wed, 20 Apr 2005 17:37:11 -0700 Tom Duffy <[EMAIL PROTECTED]> wrote: > This breaks building on sparc64: ... > This is ugly, but fixes the build. Perhaps sparc needs > pgprot_noncached() to be a noop? No, it should actually do something, like so: include/asm-sparc64/pgtable.h: af9bf175a223cf44310293287d50302e0fd3f9e9 --- a/include/asm-sparc64/pgtable.h +++ b/include/asm-sparc64/pgtable.h @@ -416,6 +416,11 @@ extern int io_remap_pfn_range(struct vm_ unsigned long pfn, unsigned long size, pgprot_t prot); +/* Clear virtual and physical cachability, set side-effect bit. */ +#define pgprot_noncached(prot) \ + (__pgprot((pgprot_val(prot) & ~(_PAGE_CP | _PAGE_CV)) | \ +_PAGE_E)) + /* * For sparc32&64, the pfn in io_remap_pfn_range() carries in * its high 4 bits. These macros/functions put it there or get it from there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][MTHCA] fix sparc build WAS: Re: [openib-general] [PATCH][RFC][3/4] IB: userspace verbs mthca changes
On Mon, 2005-04-04 at 15:09 -0700, Roland Dreier wrote:
> @@ -574,6 +836,22 @@
> return 0;
> }
>
> +static int mthca_mmap_uar(struct ib_ucontext *context,
> + struct vm_area_struct *vma)
> +{
> + if (vma->vm_end - vma->vm_start != PAGE_SIZE)
> + return -EINVAL;
> +
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> +
> + if (remap_pfn_range(vma, vma->vm_start,
> + to_mucontext(context)->uar.pfn,
> + PAGE_SIZE, vma->vm_page_prot))
> + return -EAGAIN;
> +
> + return 0;
> +}
> +
This breaks building on sparc64:
CC [M] drivers/infiniband/hw/mthca/mthca_provider.o
/build1/tduffy/openib-work/linux-2.6.11-openib/drivers/infiniband/hw/mthca/mthca_provider.c:
In function `mthca_mmap_uar':
/build1/tduffy/openib-work/linux-2.6.11-openib/drivers/infiniband/hw/mthca/mthca_provider.c:352:
warning: implicit declaration of function `pgprot_noncached'
/build1/tduffy/openib-work/linux-2.6.11-openib/drivers/infiniband/hw/mthca/mthca_provider.c:352:
error: incompatible types in assignment
make[3]: *** [drivers/infiniband/hw/mthca/mthca_provider.o] Error 1
make[2]: *** [drivers/infiniband/hw/mthca] Error 2
make[1]: *** [_module_drivers/infiniband] Error 2
make: *** [_all] Error 2
This is ugly, but fixes the build. Perhaps sparc needs
pgprot_noncached() to be a noop?
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: linux-2.6.11-openib/drivers/infiniband/hw/mthca/mthca_provider.c
===
--- linux-2.6.11-openib/drivers/infiniband/hw/mthca/mthca_provider.c
(revision 2202)
+++ linux-2.6.11-openib/drivers/infiniband/hw/mthca/mthca_provider.c
(working copy)
@@ -349,7 +349,9 @@ static int mthca_mmap_uar(struct ib_ucon
if (vma->vm_end - vma->vm_start != PAGE_SIZE)
return -EINVAL;
+#ifdef pgprot_noncached
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+#endif
if (remap_pfn_range(vma, vma->vm_start,
to_mucontext(context)->uar.pfn,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 scsi-misc-2.6 03/05] scsi: make scsi_queue_insert() use blk_requeue_request()
Hello, James. James Bottomley wrote: On Wed, 2005-04-20 at 08:15 +0900, Tejun Heo wrote: - * Insert this command at the head of the queue for it's device. - * It will go before all other commands that are already in the queue. - * - * NOTE: there is magic here about the way the queue is plugged if - * we have no outstanding commands. - * - * Although this *doesn't* plug the queue, it does call the request - * function. The SCSI request function detects the blocked condition - * and plugs the queue appropriately. This comment still looks appropriate to me ... why do you want to remove it? Well, the thing is that we don't really care what exactly happens to the queue or how the queue is plugged or not. All we need to do are to requeue the request and kick the queue in the ass. Hmmm, maybe I should keep the comment about how the request will be put at the head of the queue, but the second part about plugging doesn't really belong here, I think. +* Requeue the command. */ - blk_insert_request(device->request_queue, cmd->request, 1, cmd, 1); + spin_lock_irqsave(q->queue_lock, flags); + blk_requeue_request(q, cmd->request); + spin_unlock_irqrestore(q->queue_lock, flags); + + scsi_run_queue(q); Really, wouldn't it be much more efficient simply to call blk_run_queue ()? since the blocked flags were set above, that's pretty much what scsi_run_queue() collapses to. Yes, that will be more efficient but I don't think it would make any noticeable difference. IMO, universally using scsi_run_queue() to kick scsi request queues is better than mixing blk_run_queue() and scsi_run_queue() for probably unnoticeable optimization. If we start to mix'em, we need to rationalize why specific one is chosen in specific places and that's just unnecessary. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] nameing reserved pages [1/3]
Hi!
Pavel Machek wrote:
~
missing e?
Oh, it's typo :(. thanks!
+ Reserved_At_Boot,
+ Max_Reserved_Types,
+ Page_Invalid = 0xff
+};
You certainly use unusual naming convention here. Could we get
reserved_at_boot instead? (I.e. all lowercase).
Okay.
+static inline void set_page_reserved(struct page *page, unsigned char type)
+{
Make it enum page_type type.
I'll do.
Thanks
-- Kame <[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] drivers/ieee1394/: remove unneeded EXPORT_SYMBOL's
Adrian Bunk wrote: On Wed, Apr 20, 2005 at 04:32:24PM -0400, Dan Dennedy wrote: Based upon my experience of several years on this project there is only one external kernel module project we need to consider because that developer has been involved and voiced requirements. That is Arne Caspari's (The Imaging Source) DFG/1394 driver. The ideal solution would be to get this driver included in the kernel. Are there any reasons against including it? Arne stated his reasons: http://marc.theaimsgroup.com/?m=110361846312128 (BTW, does Arne have commit access to the linux1394 repo yet?) I vote to remove external symbols not used by the Linux1394.org modules or the module at http://sourceforge.net/projects/video-2-1394/ Of course, I may be voted down, but I ask the others to be realistic about what we are arguing for (i.e. just being defensive?) and consider the fact that there are valid reasons for their removal. Yes, there are. (Although one of the reasons -- size of the kernel -- is in effect neglectible.) So let's see if further opinions are coming in at the lists now. Then let's decide how to manage removal of the stuff. The DFG/1394 driver requires hpsb_read and hpsb_write. Are there any Linux1394.org modules that are not in 2.6.12-rc2-mm3? No. -- 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: 2.6.12-rc2-mm3 pciehp regression
On Wednesday, April 20, 2005 12:50 PM, Tom Duffy wrote: > > The errors I encountered were: > > Reading all physical volumes. This may take a while... > > Umount /sys failed: 16 > > mount: error 6 mounting ext3 > > mount: error 2 mounting none > > Switching to new root > > Switchroot: mount failed 22 > > umount /initrd/dev failed: 2 > > > > I also encountered issue you & others discussed in the thread on > > "Re: Heads up on 2.6.12-rc1 and later" if I used SCSI drive. > > > > Can you send me the config file you used successfully on your > > system? > > You will need to boot the system UP (not SMP). There is a problem > with modules loading too fast that causes the initrd to fail. This doesn't help on my system. I tried both ways: using boot option with nosmp, and rebuilding kernel with SMP off in config file. Using nosmp, I got: IOAPIC [0]: Invalid reference to IRQ 0 . . audit() initialized ide 1 : id1 1 : ports already in use, skipping and system halted Rebuilding kernel with SMP off in config file, I got: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Thanks, Dely - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] rename "---help---" to "help" in Kconfig files
On Thu, Apr 21, 2005 at 12:06:11AM +0200, Jesper Juhl wrote: >... > Why does it do this? : There are two reasons for doing this; > 1) Consistency. out of ~4000 help entries in 134 Kconfig files, 747 of > those entries use "---help---" as the keyword, the rest use just "help". > So the users of "---help---" are clearly a minority and by renaming them > we make things consistent. - I hate inconsistency. :-) > 2) By not using two different "keywords" I assume it will be posible to > speed up kbuilds handling of Kconfig files slightly. That goal is not > accomplished by this patch, but this patch is a prerequisite for making > that change later. >... I'd be surprised if the second reason had a measurable effect, but I like this patch for the first reason. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH scsi-misc-2.6 03/05] scsi: make scsi_queue_insert() use blk_requeue_request()
On Wed, 2005-04-20 at 08:15 +0900, Tejun Heo wrote: > - * Insert this command at the head of the queue for it's device. > - * It will go before all other commands that are already in the queue. > - * > - * NOTE: there is magic here about the way the queue is plugged if > - * we have no outstanding commands. > - * > - * Although this *doesn't* plug the queue, it does call the request > - * function. The SCSI request function detects the blocked condition > - * and plugs the queue appropriately. This comment still looks appropriate to me ... why do you want to remove it? > + * Requeue the command. >*/ > - blk_insert_request(device->request_queue, cmd->request, 1, cmd, 1); > + spin_lock_irqsave(q->queue_lock, flags); > + blk_requeue_request(q, cmd->request); > + spin_unlock_irqrestore(q->queue_lock, flags); > + > + scsi_run_queue(q); Really, wouldn't it be much more efficient simply to call blk_run_queue ()? since the blocked flags were set above, that's pretty much what scsi_run_queue() collapses to. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nVidia stuff again
> But *that's* the point people keep ignoring: the specs for programming > the hardware, in some cases, reveals details about the hardware's > implementation that nVidia does *not* want to release (in addition to > suggesting their software tricks). Why is it that people *assume* that > just the programming docs tells a person nothing about the hardware? We > already know that knowing the registers of a card and what those > registers do tells you implicit information about the card's design and > also reveals implicit information about the design of software that > works with the card. How complex the card's registers and programming > interface is determines how much you can infer, and the more RISC like > or simple the card is and the more that is handled in the driver, the > more obviously the design can be inferred just from the programming > specs. I think the programming specs for a 3D graphics card can tell you very little about it, the R200 specs are very good but I doubt anyone would have a clue how to design the internals of the card just from looking at them, and now that GPUs are getting more like CPUs in terms of shaders and programming languages the specs are getting less and less useful to tell what is actually going on The main reasons they don't like open source is from where I'm standing, their IP lawyers and probably not being able to do sneaky hacks in the driver because people can see them.. Dave. > > The aic7xxx chips are a perfect example of this exact same thing. If > you know how to program the registers on that card, then you know almost > everything about the hardware. It's that simple (and that's a big part > of what makes it very fast, lots of room for driver optimizations and > enhanced feature support). > > -- > Doug Ledford <[EMAIL PROTECTED]> > http://people.redhat.com/dledford > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message 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/
x86_64: Bug in new out of line put_user()
The new out of line put_user() assembly on x86_64 changes %rcx without telling GCC about it causing things like: http://bugme.osdl.org/show_bug.cgi?id=4515 See to it that %rcx is not changed (made it consistent with get_user()). Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]> Index: test/arch/x86_64/lib/getuser.S === --- test.orig/arch/x86_64/lib/getuser.S 2005-04-20 23:55:35.0 +0200 +++ test/arch/x86_64/lib/getuser.S 2005-04-21 00:54:16.0 +0200 @@ -78,9 +78,9 @@ __get_user_8: GET_THREAD_INFO(%r8) addq $7,%rcx - jc bad_get_user + jc 40f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_get_user + jae 40f subq$7,%rcx 4: movq (%rcx),%rdx xorl %eax,%eax Index: test/arch/x86_64/lib/putuser.S === --- test.orig/arch/x86_64/lib/putuser.S 2005-04-21 00:50:24.0 +0200 +++ test/arch/x86_64/lib/putuser.S 2005-04-21 01:02:15.0 +0200 @@ -46,36 +46,45 @@ __put_user_2: GET_THREAD_INFO(%r8) addq $1,%rcx - jc bad_put_user + jc 20f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_put_user -2: movw %dx,-1(%rcx) + jae 20f +2: decq %rcx + movw %dx,(%rcx) xorl %eax,%eax ret +20:decq %rcx + jmp bad_put_user .p2align 4 .globl __put_user_4 __put_user_4: GET_THREAD_INFO(%r8) addq $3,%rcx - jc bad_put_user + jc 30f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_put_user -3: movl %edx,-3(%rcx) + jae 30f +3: subq $3,%rcx + movl %edx,(%rcx) xorl %eax,%eax ret +30:subq $3,%rcx + jmp bad_put_user .p2align 4 .globl __put_user_8 __put_user_8: GET_THREAD_INFO(%r8) addq $7,%rcx - jc bad_put_user + jc 40f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_put_user -4: movq %rdx,-7(%rcx) + jae 40f +4: subq $7,%rcx + movq %rdx,(%rcx) xorl %eax,%eax ret +40:subq $7,%rcx + jmp bad_put_user bad_put_user: movq $(-EFAULT),%rax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 scsi-misc-2.6 01/05] scsi: make blk layer set REQ_SOFTBARRIER when a request is dispatched
Hello, guys. Jens Axboe wrote: On Wed, Apr 20 2005, Nick Piggin wrote: Jens Axboe wrote: On Wed, Apr 20 2005, Nick Piggin wrote: I guess this could be one use of 'reordering' after a requeue. Yeah, or perhaps the io scheduler might determine that a request has higher prio than a requeued one. I'm not sure what semantics to place I guess this is possible. It is often only a single request that is on the dispatch list though, so I don't know if it would make sense to reorder it by priority again. Depends entirely on the io scheduler. CFQ may put several on the dispatch list. on soft-barrier, I've always taken it to mean 'maintain ordering if convenient' where the hard-barrier must be followed. I've thought it was SOFTBARRIER ensures the device driver (and hardware?) sees the request in this order, and HARDBARRIER ensures it reaches stable storage in this order. Not exactly sure why you would want a softbarrier and not a hardbarrier. Maybe for special commands. It is the cleaner interpretation. CFQ marks requests as requeued internally and gives preference to them for reissue, but it may return another first (actually, I think it even checks for ->requeued on dispatch sort, so it wont right now). I'm not sure this would need a REQ_SOFTBARRIER either though, really. Your basic io scheduler framework - ie. a FIFO dispatch list which can have requests requeued on the front models pretty well what the block layer needs of the elevator. Considering all requeues and all elv_next_request but not dequeued requests would have this REQ_SOFTBARRIER bit set, any other model that theoretically would allow reordering would degenerate to this dispatch list behaviour, right? Not sure I follow this - I don't want REQ_SOFTBARRIER set automatically on elv_next_request() return, it should only happen on requeues. REQ_STARTED implies that you should not pass this request, since the io scheduler is required to return this request again until dequeue is called. But the result is the same, correct. OK - but I'm wondering would it ever make sense to do it any other way? I would have thought no, in which case we can document that requests seen by 'elv_next_request', and those requeued back into the device will not be reordered, and so Tejun does not need to set REQ_SOFTBARRIER. But I'm not so sure now... it isn't really that big a deal ;) So whatever you're happy with is fine. Sorry for the nose. It's not noise, it would be nice to have this entirely documented so that there isn't any confusion on what is guaranteed vs what currently happens in most places. But I don't want to document that they are never reordered. For requeues it make sense to maintain ordering in most cases, but it also may make sense to reorder for higher priority io. If the driver does _not_ want a particular request reordered for data integrity reasons, then that needs to be explicitly specified. So, I guess this is settled now. James, what do you think about the rest of this patchset? If you're okay, I think we can proceed merging as there doesn't seem to be any issue left. Do we put this into the SCSI tree? Or separate out blk and SCSI changes? Once we're done merging this patchset, I'll regenerate & repost the reqfn reimpl patchset. Thanks a lot. :-) -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Booting from USB with initrd
Cheers! Everythings up and running now. It had nothing to do with the kernel and all to do with a wrong word in syslinux.cfg. I had the wrong default set so it defaulted to running the kernel without options. Which is no good idea when booting an initrd =) Thanks for the help anyhow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] rename "---help---" to "help" in Kconfig files
Ok, I'll admit right up front that this is probably slightly controversial, and most certainly slightly silly as well, and my reasons for doing this may not be the best in the world, but let me try and explain the reasons for this patch. What does it do? : It renames all instances of "---help---" to simply "help" in all of the Kconfig files. Why does it do this? : There are two reasons for doing this; 1) Consistency. out of ~4000 help entries in 134 Kconfig files, 747 of those entries use "---help---" as the keyword, the rest use just "help". So the users of "---help---" are clearly a minority and by renaming them we make things consistent. - I hate inconsistency. :-) 2) By not using two different "keywords" I assume it will be posible to speed up kbuilds handling of Kconfig files slightly. That goal is not accomplished by this patch, but this patch is a prerequisite for making that change later. Now I think I can already guess some of the arguments against this; a) this diff will clutter up the change history for those files. True, it will, but Kconfig files see releatively few changes so this shouldn't be a big deal. b) This doesn't improve anything for the users of the Kconfig files. Again true, it will not, but if it leads to a slightly faster kbuild that /will/ benefit users if only ever so slightly). Anyway, I made the patch, if it makes sense to the powers that be, then feel free to apply it, if not, then don't apply it and the world moves on :) No need to make a big fuzz about it... Since this patch is fairly huge (~250Kb) I've not included it inline, but you can find it at http://www.linuxtux.org/~juhl/kernel_patches/Kconfig-help-rewrite.patch Here's the diffstat : arch/alpha/Kconfig | 12 +-- arch/arm/Kconfig | 10 +- arch/arm/mach-clps711x/Kconfig |2 arch/arm/mach-footbridge/Kconfig |2 arch/arm26/Kconfig |2 arch/cris/arch-v10/drivers/Kconfig |4 - arch/h8300/Kconfig |6 - arch/i386/Kconfig| 30 arch/i386/kernel/cpu/cpufreq/Kconfig |4 - arch/ia64/Kconfig|2 arch/m32r/Kconfig|4 - arch/m68k/Kconfig| 18 ++--- arch/m68knommu/Kconfig |8 +- arch/mips/Kconfig| 12 +-- arch/parisc/Kconfig |4 - arch/ppc/Kconfig | 26 +++ arch/ppc64/Kconfig |6 - arch/s390/Kconfig|4 - arch/sh/Kconfig |8 +- arch/sh/cchips/Kconfig |4 - arch/sparc/Kconfig | 14 ++-- arch/sparc64/Kconfig | 18 ++--- arch/um/Kconfig |2 arch/x86_64/Kconfig |8 +- drivers/acpi/Kconfig | 14 ++-- drivers/atm/Kconfig | 16 ++-- drivers/base/Kconfig |2 drivers/block/Kconfig| 24 +++--- drivers/block/paride/Kconfig |8 +- drivers/cdrom/Kconfig| 20 ++--- drivers/char/Kconfig | 50 +++--- drivers/char/agp/Kconfig |6 - drivers/char/ftape/Kconfig | 18 ++--- drivers/char/tpm/Kconfig |6 - drivers/char/watchdog/Kconfig| 34 - drivers/eisa/Kconfig |8 +- drivers/fc4/Kconfig |4 - drivers/i2c/Kconfig |2 drivers/ide/Kconfig | 36 +- drivers/infiniband/Kconfig |2 drivers/infiniband/hw/mthca/Kconfig |4 - drivers/infiniband/ulp/ipoib/Kconfig |6 - drivers/input/Kconfig| 12 +-- drivers/input/gameport/Kconfig |2 drivers/input/joystick/Kconfig |6 - drivers/input/mouse/Kconfig |4 - drivers/input/serio/Kconfig | 12 +-- drivers/isdn/Kconfig |4 - drivers/isdn/hisax/Kconfig |2 drivers/macintosh/Kconfig|2 drivers/md/Kconfig | 28 drivers/media/Kconfig|2 drivers/media/dvb/Kconfig|2 drivers/media/radio/Kconfig | 30 drivers/media/video/Kconfig | 28 drivers/message/fusion/Kconfig |6 - drivers/message/i2o/Kconfig |2 drivers/misc/Kconfig |2 drivers/mtd/Kconfig | 16 ++-- drivers/mtd/chips/Kconfig|2 drivers/mtd/devices/Kconfig | 10 +- drivers/mtd/nand/Kconfig |2 drivers/net/Kconfig | 122 +-- drivers/net/appletalk/Kconfig|2 drivers/net/arcnet/Kconfig |8 +- drivers/net/hamradio/Kconfig | 16 ++-- drivers/net/irda/Kconfig
Re: [PATCH] remove some usesless casts
Jörn Engel wrote: Your definition of _unnecessary_ casts may differ from mine. Basically, every cast is unnecessary, except for maybe one or two - if that many. Well we agree to differ then. In my experience casts are sometimes necessary, and are often less clumsy than the alternatives (such as unions). This is probably a generational thing, the fashion today is to make languages much more strongly typechecked than before. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Disk output lockup amd64 nforce4 device-mapper 2.6.12_rc2
During heavy io-load a lockup occurs that appears to prevent any disk
output from taking place. fs is reiserfs on two device-mapper mirrored
200G maxtor disks. After the lockup occurs you can to things like 'ls',
but echo > test.txt will hang.
A typical workload producing the error is doing:
rsync of large (1GB) over 100Mbit ethernet
simultaneous compilation / gunzip
I've disabled preemption, and tried with and without acpi enabled, with
and without smp support (it was smp by default so i switched it off).
Also tried with another nic (rtl8139) since i got an nv_stop_tx:
TransmitterStatus remained busy<6> in the logs. I also tried 2.6.11.7
with the same result.
This produces the lockup after 10-40 minutes. I've got a complete log
from alt-sysreq-T if anyone wants to look at it. The following is a dump
for the bash and kmirrord process when trying echo > test.txt.
The output for kmirrord is included because it's exactly as specified
below both before and after echo > test.txt is invoked, this looked
peculiar to me.
Later runs showed what was to my eyes similar results, some callpaths
weren't exactly the same, but kmirrord was somewhere in mempool_alloc
and the bash process was in do_journal_end, whatever that means :)
bash D c238e000 0 6529 6381 (NOTLB)
81003dfc1bd8 0086
810001b6ba60
6db6db6db6db6db7 801acc46
810001b6ba98 81003d8c27e0
27cd 805a61c0
Call Trace:
{__d_lookup+358} {queue_log_writer+115}
{default_wake_function+0}
{do_journal_end+604}
{search_by_entry_key+50}
{do_journal_begin_r+77}
{do_journal_begin_r+575}
{journal_begin+204}
{reiserfs_create+183}
{vfs_create+188}
{open_namei+454}
{filp_open+39}
{get_unused_fd+223}
{getname+138}
{sys_open+76}
{system_call+126}
kmirrord/0 D 81003f1bccd8 0 978 9 1731 977 (L-TLB)
81003f931ab8 0046
0200 8016a2d6
810036d18e80 0001
00733f931c30 81003f8d4030
952e 810036cf67e0
Call Trace:
{cache_alloc_refill+1222}
{io_schedule+15}
{mempool_alloc+707} {bvec_get_page+0}
{autoremove_wake_function+0}
{autoremove_wake_function+0}
{__rh_alloc+44}
{rh_inc_pending+67}
{do_work+2955}
{do_work+3000}
{thread_return+0}
{do_work+0}
{worker_thread+715}
{default_wake_function+0}
{default_wake_function+0}
{worker_thread+0}
{kthread+205} {keventd_create_kthread+0}
{child_rip+8} {keventd_create_kthread+0}
{kthread+0}
{child_rip+0}
/Mikael Andersson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fortuna
On Tue, Apr 19, 2005 at 04:31:47AM +, David Wagner wrote: > Theodore Ts'o wrote: > >For one, /dev/urandom and /dev/random don't use the same pool > >(anymore). They used to, a long time ago, but certainly as of the > >writing of the paper this was no longer true. This invalidates the > >entire last paragraph of Section 5.3. > > Ok, you're right, this is a serious flaw, and one that I overlooked. > Thanks for elaborating. (By the way, has anyone contacted to let them > know about these two errors? Should I?) I don't know of anyone who has contacted the authors yet. I haven't had the time, since I'm currently travelling at the moment. > I see three remaining criticisms from their Section 5.3: > 1) Due to the way the documentation describes /dev/random, many >programmers will choose /dev/random by default. This default >seems inappropriate and unfortunate. > 2) There is a widespread perception that /dev/urandom's security is >unproven and /dev/random's is proven. This perception is wrong. >On a related topic, it is "not at all clear" that /dev/random provides >information-theoretic security. > 3) Other designs place less stress on the entropy estimator, and >thus are more tolerant to failures of entropy estimation. A failure >in the entropy estimator seems more likely than a failure in the >cryptographic algorithms. > These three criticisms look right to me. /dev/urandom is a cryptographic RNG, which is seeded from RNG. /dev/random uses a very similar cryptographic RNG, but it uses large pool to collect entropy, and uses an entropy estimator to limit the amount of data that can be extracted from the rng. If the entropy estimator fails, /dev/random degrades to a cryptographic RNG. So it is not a disaster, whereas the approach described in this paper (which uses a non-cryptographic extractor) would seem to me to be *more* prone to catastrophically failure if the entropy estimator fails than /dev/random. As to whether or not applications should be using /dev/random or /dev/urandom, /dev/random is no worse than /dev/urandom, as long as the application doesn't mind blocking when the entropy levels are too low. In practice, most of the time this situation doesn't arise since the appropriate way of using /dev/random is only to extract a small amount of entropy when needed to generate long-term keys, or when seeding a userspace cryptographic RNG for session keys. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] remove some usesless casts
On Wed, 20 April 2005 16:20:10 +0100, Phillip Lougher wrote: > Jörn Engel wrote: > >Squashfs is extremely cast-happy. This patch makes it less so. > > Thanks for the patch. Unnecessary casts were one of the things > mentioned when I submitted the patches to the LKML, and therefore I > suspect most of them have been already fixed (but I will apply your > patch to check). Your definition of _unnecessary_ casts may differ from mine. Basically, every cast is unnecessary, except for maybe one or two - if that many. > I will send revised patches to the LKML soon, most of the issues raised > by the comments have been fixed, the current delay is being caused by > the 4GB limit re-work. There are three more patches in my queue, which I'll send after first coffee or so. After those I'll ignore squashfs for a while (until you send current code or so). Jörn -- The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: video drivers, agp, mtrr, and write-combining
On Wed, Apr 20, 2005 at 02:12:38PM -0700, Alice Corbin wrote: > I've noticed that some, though no all, video drivers add their video memory > to MTRR as 'write-combining' if both MTRR and AGP are configured in. > > Is there a reason that all video drivers don't do this? Is it all would > benefit from write-combining memory, but that some simply haven't been > updated to take advantage of it? Or could write-combining actually be > detrimental to some video drivers? Either the drivers dont do it (for whatever reason), or the system doesnt have any spare MTRRs, or the system has broken WC MTRRs. Got a specific example of a failing system ? > (And if the former, would it make > more sense to do the mtrr_add in a central location, say agpgart?) It *could*, though it's not always straight-forward. Here's an example of one awkward situation.. Matrox G550: Prefetchable memory behind bridge: f800-f9ff (31MB) As MTRRs need to be a power-of-2, thats non-fun. An NVIDIA GeForce256 -- Prefetchable memory behind bridge: d000-d7ff (127MB) Ok, looks like a pattern but some systems with onboard gfx do this.. Prefetchable memory behind bridge: d800-dc0f (64MB) There also exist some AGP cards which don't seem to use AGP features, and have their range listed as fff0-000f, which means "I have no RAM" iirc. The heuristics to get all this right would likely be a real mess, so I feel its better to do it in the gfx card specific driver. An even better solution would be to get PAT support into the kernel so we can forget MTRRs ever existed. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: writev to scsi disks
On Wed, 2005-04-20 at 08:01 -0700, Dheeraj Pandey wrote: > I was wondering if I did a simple writev to a SCSI disk, does it take > the sg path to the device? I am guessing sg (REQ_SPECIAL) is only > true for character devices (and ioctl's) and not block devices. ? I think you misunderstand how writev works. It's design is to take a list of scattered buffers in a user program and consolidate them into a single write. This (in the current implementation) is a separate entity from the block level Scatter Gather. If by sg write path, if you mean scatter-gather write path, then yes, that single write would be split up again into a sg list based on the device parameters if you mean does the writev sg list control where on the disk the data ends up, then no, if you use a disk device as a simple file, writev consolidates all writes to the current file position. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
video drivers, agp, mtrr, and write-combining
I have a silly question. I've noticed that some, though no all, video drivers add their video memory to MTRR as 'write-combining' if both MTRR and AGP are configured in. Is there a reason that all video drivers don't do this? Is it all would benefit from write-combining memory, but that some simply haven't been updated to take advantage of it? Or could write-combining actually be detrimental to some video drivers? (And if the former, would it make more sense to do the mtrr_add in a central location, say agpgart?) Ali - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] nameing reserved pages [1/3]
Hi!
> inline functions for naming pages.
> -- Kame
>
> Adding page_type definitions and funcs for naming reserved pages.
>
> Reserved page's information is stored into page->private.
>
> This is a weak naming method and anyone can overwrite it.
>
> This information is used in /dev/memstate in following patch.
>
> Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
>
>
> ---
>
> linux-2.6.12-rc2-kamezawa/include/linux/mm.h | 31
> +++
> 1 files changed, 31 insertions(+)
>
> diff -puN include/linux/mm.h~name_reserved include/linux/mm.h
> --- linux-2.6.12-rc2/include/linux/mm.h~name_reserved 2005-04-20
> 09:37:48.0 +0900
> +++ linux-2.6.12-rc2-kamezawa/include/linux/mm.h 2005-04-20
> 10:38:01.0 +0900
> @@ -348,6 +348,37 @@ static inline void put_page(struct page
> #endif /* CONFIG_HUGETLB_PAGE */
>
> /*
> + * Type of Pages. This is used in /dev/memstate.
> + * value range is 0-255.
> + */
> +enum page_type {
> + Page_Common = 0,
> + Min_Reserved_Types = 1,
> + Rserved_Unknwon = 1,
~
missing e?
> + Reserved_At_Boot,
> + Max_Reserved_Types,
> + Page_Invalid = 0xff
> +};
You certainly use unusual naming convention here. Could we get
reserved_at_boot instead? (I.e. all lowercase).
> +/*
> + * Basically, page->private has no meaning without PG_private.
> + * Here, we use page->private for PG_reserved pages to record type of a page.
> + * Because a page is reserved, anyone will not modify page->private.
> + * When it is freed, page->private will be overwritten by some code.
> + */
> +static inline void set_page_reserved(struct page *page, unsigned char type)
> +{
Make it enum page_type type.
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: more git updates..
[EMAIL PROTECTED] (H. Peter Anvin) wrote on 11.04.05 in <[EMAIL PROTECTED]>: > Followup to: <[EMAIL PROTECTED]> > By author:Christopher Li <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > There is one problem though. How about the SHA1 hash collision? > > Even the chance is very remote, you don't want to lose some data do due > > to "software" error. I think it is OK that no handle that > > case right now. On the other hand, it will be nice to detect that > > and give out a big error message if it really happens. > > > > If you're actually worried about it, it'd be better to just use a > different hash, like one of the SHA-2's (probably a better choice > anyway), instead of SHA-1. How could that help? *Every* hash has hash collisions. It's an unavoidable result of using less bits than the original data has. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/ieee1394/: remove unneeded EXPORT_SYMBOL's
On Wed, Apr 20, 2005 at 04:32:24PM -0400, Dan Dennedy wrote: >... > Based upon my experience of several years on this project there is only > one external kernel module project we need to consider because that > developer has been involved and voiced requirements. That is Arne > Caspari's (The Imaging Source) DFG/1394 driver. The ideal solution would be to get this driver included in the kernel. Are there any reasons against including it? > I vote to remove external symbols not used by the Linux1394.org modules > or the module at http://sourceforge.net/projects/video-2-1394/ > Of course, I may be voted down, but I ask the others to be realistic > about what we are arguing for (i.e. just being defensive?) and consider > the fact that there are valid reasons for their removal. The DFG/1394 driver requires hpsb_read and hpsb_write. Are there any Linux1394.org modules that are not in 2.6.12-rc2-mm3? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/ieee1394/: remove unneeded EXPORT_SYMBOL's
On Wed, 2005-04-20 at 18:31 +0200, Stefan Richter wrote: > Arjan van de Ven wrote: > > On Wed, 2005-04-20 at 00:00 +0200, Stefan Richter wrote: > >>There are users (though not in "the" kernel at the moment) > > nor for the last 5 months... how long will it be ? > > Have there been problems with the API during the past 5 months, except > that several kernel trees are using some parts of the API? (We are > actually speaking about two APIs of the ieee1394 framework.) > > Which problems are solved by this patch? Do they outweigh the problems > it creates? The latter have been discussed. Dismissing them as Other > People's Problems does not nullify them. > > Where is the agreed-upon, published plan for removal of features in > ieee1394? Of course, there is none. In an unofficial capacity, there is just the opinion and votes of the subsystem maintainers, extended team (e.g., Stefan and me), and kernel maintainers (Linus, Andrew, and Marcello). The users are represented by the subsystem maintainers and extended team. So, Arjan's opinion does not matter except to offer some voice of reason. I think I was first to raise objection upon the initial submission some months back, and then I just observed the dialog. There are technical merits for removal of the external symbols that I accept. I also accept that we have no way of maintaining any sort of stable subsystem for external projects we are not aware of or who are not communicating with us about their requirements (it goes beyond just a stable interface). Based upon my experience of several years on this project there is only one external kernel module project we need to consider because that developer has been involved and voiced requirements. That is Arne Caspari's (The Imaging Source) DFG/1394 driver. I vote to remove external symbols not used by the Linux1394.org modules or the module at http://sourceforge.net/projects/video-2-1394/ Of course, I may be voted down, but I ask the others to be realistic about what we are arguing for (i.e. just being defensive?) and consider the fact that there are valid reasons for their removal. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] hfsplus: add an option to force r/w mount
Hi, On Wed, 20 Apr 2005, Colin Leroy wrote: > for some reason yet unknown, fsck.hfsplus doesn't correctly set the > HFSPLUS_VOL_UNMNT flag here. If fsck doesn't mark it clean, there must be a reason and that also means you shouldn't mount it writable. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rename rw_verify_area() to rw_access_ok()
On Wed, 20 Apr 2005, Marcelo Tosatti wrote: > On Sun, Apr 17, 2005 at 11:50:35PM +0200, Jesper Juhl wrote: > > verify_area() will soon be dead and gone, replaced by access_ok(), thus > > the function named rw_verify_area() is badly named and should be renamed. > > This patch renames rw_verify_area to rw_access_ok which seems more > > appropriate (it also updates all callers of the functions as well as > > references to it in comments). > > Not that I care too much, but, rw_verify_area() has nothing to do with > verify_area/access_ok functions. > right, access_ok deals with memory, rw_verify_area deals with files, but both serve a similar purpose - validating access to a region. That's why I thought it would make sense to have them named similarly (as they used to be). > I dont see real need to rename this function. > Perhaps I went a tad too far, or perhaps I misunderstood the point of rw_verify_area(), that's certainly a possibility. In any case, it's no big deal, I just thought it was the logical thing to do - I'll leave it in Andrews capable hands to decide. Thank you for commenting. -- Jesper Juhl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
Burst is good. There's another window in the SCSI layer that limits to bursts of 128 sector runs (this seems to be the behavior on 3Ware). I've never changed this, but increasing the max number of SCSI requests at this layer may help. The bursty behavior is good, BTW. Jeff Andreas Hirstius wrote: I was curious if your patch would change the write rate because I see only ~550MB/s (continuous) which is about a factor two away from the capabilities of the disks. ... and got this behaviour (with and without my other patch): (with single "dd if=/dev/zero of=testxx bs=65536 count=15 &" or several of them in parallel on an XFS fs) "vmstat 1" output 0 0 0 28416 37888 1577836800 0 0 8485 3043 0 0 0 100 6 0 0 22144 37952 1578592000 0 12356 7695 2029 0 61 0 39 7 0 0 20864 38016 1578585600 324 1722240 8046 4159 0 100 0 0 7 0 0 20864 38016 1578476800 0 1261440 8391 5222 0 100 0 0 7 0 0 25984 38016 1578150400 0 2003456 8372 5038 0 100 0 0 0 6 0 22784 38016 1578150400 0 2826624 8397 8423 0 93 7 0 0 0 0 21632 38016 1578368000 0 147840 8572 12114 0 9 17 74 0 0 0 21632 38016 1578368000 052 8586 5185 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 8588 5412 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 8580 5372 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 7840 5590 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 8587 5321 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 8569 5575 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 8550 5157 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 7963 5640 0 0 0 100 0 0 0 21632 38016 1578368000 032 8583 4434 0 0 0 100 7 0 0 20800 38016 1578476800 0 7424 8404 3638 0 15 0 85 8 0 0 20864 38016 1578694400 0 688768 7357 3221 0 100 0 0 8 0 0 20736 28544 1579424000 0 1978560 8376 4897 0 100 0 0 7 0 0 22208 20736 1579878400 0 1385088 8367 4984 0 100 0 0 6 0 0 22144 6848 158126720056 1291904 8377 4815 0 100 0 0 0 0 0 50240 6848 1580940800 304 3136 8556 5088 1 26 0 74 0 0 0 50304 6848 1580940800 0 0 8572 5181 0 0 0 100 The average rate here is again pretty close to 550MB/s, it just writes the blocks in "bursts"... Andreas jmerkey wrote: For 3Ware, you need to chage the queue depths, and you will see dramatically improved performance. 3Ware can take requests a lot faster than Linux pushes them out. Try changing this instead, you won't be going to sleep all the time waiting on the read/write request queues to get "unstarved". /linux/include/linux/blkdev.h //#define BLKDEV_MIN_RQ 4 //#define BLKDEV_MAX_RQ 128 /* Default maximum */ #define BLKDEV_MIN_RQ 4096 #define BLKDEV_MAX_RQ 8192 /* Default maximum */ Jeff Andreas Hirstius wrote: Hi, We have a rx4640 with 3x 3Ware 9500 SATA controllers and 24x WD740GD HDD in a software RAID0 configuration (using md). With kernel 2.6.11 the read performance on the md is reduced by a factor of 20 (!!) compared to previous kernels. The write rate to the md doesn't change!! (it actually improves a bit). The config for the kernels are basically identical. Here is some vmstat output: kernel 2.6.9: ~1GB/s read procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy wa id 1 1 0 12672 6592 15914112 0 0 1081344 56 15719 1583 0 11 14 74 1 0 0 12672 6592 15915200 0 0 1130496 0 15996 1626 0 11 14 74 0 1 0 12672 6592 15914112 0 0 1081344 0 15891 1570 0 11 14 74 0 1 0 12480 6592 15914112 0 0 1081344 0 15855 1537 0 11 14 74 1 0 0 12416 6592 15914112 0 0 1130496 0 16006 1586 0 12 14 74 kernel 2.6.11: ~55MB/s read procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy wa id 1 1 0 24448 37568 15905984 0 0 56934 0 5166 1862 0 1 24 75 0 1 0 20672 37568 15909248 0 0 57280 0 5168 1871 0 1 24 75 0 1 0 22848 37568 15907072 0 0 57306 0 5173 1874 0 1 24 75 0 1 0 25664 37568 15903808 0 0 57190 0 5171 1870 0 1 24 75 0 1 0 21952 37568 15908160 0 0 57267 0 5168 1871 0 1 24 75 Because the filesystem might have an impact on the measurement, "dd" on /dev/md0 was used to get information about the performance. This also opens the possibility to test with block sizes larger than the page size. And it appears that the performance with kernel 2.6.11 is closely related to the block size. For example if the block size is exactly a multiple (>2) of the page size the performance is back to ~1.1GB/s. The general behaviour is a bit more complicated: 1. bs <= 1.5 * ps : ~27-57MB/s (differs with ps) 2. bs > 1.5 * ps && bs < 2 * ps : rate increases to max.
Re: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
* Pavel Machek <[EMAIL PROTECTED]> [050419 14:10]: > Hi! > > > The machine is a Pentium M 2.00 GHz, supporting C0-C4 processor power > > states. > > The machine run at 2.00 GHz all the time. > .. > > _passing bm_history=0x (default) to processor module:_ > > > > Average current the last 470 seconds: *1986mA* (also measured better > > values ~1800, does battery level play a role?!?) > > Probably yes. If voltage changes, 2000mA means different ammount of power. Thomas, thanks for doing all the stats and patches to squeeze some real power savings out of this! :) We should display both average mA and average Watts with pmstats. BTW, I've posted Thomas' version of pmstats as pmstats-0.2.gz to muru.com also. > > (cmp. > > ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_) > > > > > > _passing bm_history=0xFF to processor module:_ > > > > Average current the last 190 seconds: *1757mA* > > (cmp. > > ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/1000_HZ_bm_history_FF) > > (Usage count could be bogus, as some invokations could not succeed > > if bm has currently been active). > > Ok. > > > idle_ms == 100, bm_promote_bs == 30 > > Average current the last 80 seconds: *1466mA* > > (cmp. > > ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine/tony_dyn_tick_processor_idle_100_bm_30) > > Very nice indeed. That seems like ~5W saved, right? That might give > you one more hour of battery life Depending on your battery capacity. But looking at the average Watts on the first 8 lines of the two stats above: 1000_HZ_bm_history_: (21.43 + 23.32 + 23.32 + 21.71 + 21.71 + 23.84 + 23.84 + 22.62) / 8 = 22.724W tony_dyn_tick_processor_idle_100_bm_30: (16.07 + 16.07 + 16.00 + 16.00 + 16.08 + 16.08 + 16.29 + 16.29) / 8 = 16.11W And then comparing these two: 22.72 / 16.11 = 1.4103 So according to my calculations this should provide about 1.4 times longer battery life compared to what you were getting earlier... That is assuming system is mostly idle, of course. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] rename rw_verify_area() to rw_access_ok()
On Sun, Apr 17, 2005 at 11:50:35PM +0200, Jesper Juhl wrote: > verify_area() will soon be dead and gone, replaced by access_ok(), thus > the function named rw_verify_area() is badly named and should be renamed. > This patch renames rw_verify_area to rw_access_ok which seems more > appropriate (it also updates all callers of the functions as well as > references to it in comments). Not that I care too much, but, rw_verify_area() has nothing to do with verify_area/access_ok functions. I dont see real need to rename this function. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Mike Waychison <[EMAIL PROTECTED]> wrote:
> Consider the following pseudo example:
>
> main():
> chdir("/");
> fd = open(".", O_RDONLY);
> clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
>
> cloned_func:
> fchdir(fd);
> chdir("..");
>
> if main is run within a chroot where it's "/" is on the same vfsmount as
> it's "..", then the application can step out of the chroot using clone(2).
>
> Note: using chdir in a vfsmount outside of your namespace works, however
> you won't be able to walk off that vfsmount (to its parent or children).
IMO the '..' file descriptor should be attached to it's chroot domain.
This should avoid all chroot-escapes, even with fd-passing etc.
I wonder why nobody thought of that. Either it's too obvious or too stupid.
--
Funny quotes:
7. You have the right to remain silent. Anything you say will be misquoted,
then used against you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.12-rc2-mm3 pciehp regression
On Wed, 2005-04-20 at 11:56 -0700, Sy, Dely L wrote: > On Friday, April 15, 2005 12:48 PM, Tom Duffy wrote: > > From: "Sy, Dely L" <[EMAIL PROTECTED]> > > > Thanks for reporting this. I'll look into it. Which was the last > > > kernel you tested on your hw and worked for you? > > > That is a good question. I think it was a 2.6.11 kernel. It was > > definately before express was moved to a different directory, > > whenever that occured. > > Tom, > > I was not able to duplicate this problem on my system yet for I have > trouble in getting my system booted up on 2.6.12-rc2-mm3. I did some > back-tracking and found that the boot problem occurred also with > 2.6.12-rc2-mm2 & 2.6.12-rc2-mm3, and on two systems using IDE as boot > drive. The config file I used worked fine on 2.6.11.7. I tried > different config file without success. > > The errors I encountered were: > Reading all physical volumes. This may take a while... > Umount /sys failed: 16 > mount: error 6 mounting ext3 > mount: error 2 mounting none > Switching to new root > Switchroot: mount failed 22 > umount /initrd/dev failed: 2 > > I also encountered issue you & others discussed in the thread on > "Re: Heads up on 2.6.12-rc1 and later" if I used SCSI drive. > > Can you send me the config file you used successfully on your > system? You will need to boot the system UP (not SMP). There is a problem with modules loading too fast that causes the initrd to fail. -tduffy signature.asc Description: This is a digitally signed message part
Re: NForce4 ide problems?
On Wed, 20 Apr 2005, ismail dönmez wrote:
> Hi all,
> I recently bought an Asus A8N-SLI mobo and an AMD 3500+ CPU for my
> system but my ide drive seems to have some problems with them. Here is
> what I get at boot :
>
> hda: 156368016 sectors (80060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
> hda: cache flushes supported
> /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 {
> DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> ide: failed opcode was: unknown
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> ide: failed opcode was: unknown
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> ide: failed opcode was: unknown
>
> First I thought it was bad ide cable ( because I wasn't using the one
> that came with mobo ) so I tried with the brand new cable coming with
> mobo and same error happened. Also trying to do something like :
> hdparm -m16 -c -u1 -d1 -Xudma2 /dev/hda
> results in a cpu exception thrown and a kernel panic after that. Full
You might want to post that Oops message if you want someone to try and
fix it.
Also, from your dmesg output I see that you are loading the NVIDIA module
NVRM: loading NVIDIA Linux x86_64 NVIDIA Kernel Module 1.0-7174 Tue Mar 22
06:45:40 PST 2005
You may want to try /not/ loading that module and then reproduce the
kernel panic and then post that Oops or panic message instead.
--
Jesper Juhl
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] procfs privacy: tasks/processes lookup
Lorenzo Hernández GarcĂa-Hierro schrieb: > This patch restricts non-root users to view only their own processes. You may also want to have a look at the patches I submitted over the last few weeks that restricted some file permissions in /proc// and the comments I received. Regards, 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: [2.6 patch] drivers/ieee1394/: remove unneeded EXPORT_SYMBOL's
On Wed, 2005-04-20 at 19:09 +0200, Stefan Richter wrote: > Arjan van de Ven wrote: > > If nothing is using an api > > Check the archive. I don't care and in fact ignore external drivers that don't ever want to get upstream. If there is a driver that wants this surely it wants to go upstream soonish ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.12-rc2] aoe [5/6]: add firmware version to info in sysfs
"Randy.Dunlap" <[EMAIL PROTECTED]> writes:
...
> so something like 'firmware-version' would be appreciated
> (for the sysfs filename).
Fair enough. This patch follows and depends on the fifth patch of the
six.
use a more explicit filename for sysfs firmware version info
Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]>
diff -urNp a-exp/linux/drivers/block/aoe/aoeblk.c
b-exp/linux/drivers/block/aoe/aoeblk.c
--- a-exp/linux/drivers/block/aoe/aoeblk.c 2005-04-20 15:09:13.0
-0400
+++ b-exp/linux/drivers/block/aoe/aoeblk.c 2005-04-20 15:09:13.0
-0400
@@ -58,7 +58,7 @@ static struct disk_attribute disk_attr_n
.show = aoedisk_show_netif
};
static struct disk_attribute disk_attr_fwver = {
- .attr = {.name = "fwver", .mode = S_IRUGO },
+ .attr = {.name = "firmware-version", .mode = S_IRUGO },
.show = aoedisk_show_fwver
};
@@ -76,7 +76,7 @@ aoedisk_rm_sysfs(struct aoedev *d)
sysfs_remove_link(>gd->kobj, "state");
sysfs_remove_link(>gd->kobj, "mac");
sysfs_remove_link(>gd->kobj, "netif");
- sysfs_remove_link(>gd->kobj, "fwver");
+ sysfs_remove_link(>gd->kobj, "firmware-version");
}
static int
--
Ed L Cashin <[EMAIL PROTECTED]>
Re: [Lse-tech] Re: [RFC PATCH] Dynamic sched domains aka Isolated cpusets
Earlier, I wrote to Dinakar: > What are your invariants, and how can you assure yourself and us > that your code preserves these invariants? I repeat that question. === On my first reading of your example, I see the following. It is sinking into my dense skull more than it had before that your patch changes the meaning of the cpuset field 'cpus_allowed', to only include the cpus not in isolated children. However there are other uses of the 'cpus_allowed' field in the cpuset code that are not changed, and comments and documentation describing this field that are not changed. I suspect this is an incomplete change. You don't actually state it that I noticed, but the main point of your example seems to be that you support incrementally moving individual cpus between cpusets, without the constraint that both cpusets be in the same subset of the partition (the same isolation group). So you can move a cpu in and out of an isolated group without tearing down the group down first, only to rebuild it after. To do this, you've added new semantics to some of the operations to write the 'cpus' special file of a cpuset, if and only if that cpuset is marked isolated, which involves changing some other masks. These new semantics are something along the lines of "adding a cpu here implies removing it from there. This presumably allows you to move cpus in or out of or between an isolated cpuset, while preserving the essential properties of a partition - that it is a disjoint covering. > He removes cpus 4-5 from batch and adds them to cint Could you spell out the exact steps the user would take, for this part of your example? What does the user do, what does the kernel do in response, and what state the cpusets end up in, after each action of the user? === So far, to be honest, I am finding your patch to be rather frustrating. Perhaps the essential reason is this. The interface that cpusets presents in the cpuset file system, mounted at /dev/cpuset, is not in my intentions primarily a human interface. It is primarily a programmatic interface. As such, there is a high premium on clarity of design, consistency of behaviour and absence of side affects. Each operation should do one thing, clearly defined, changing only what is operated on, preserving clearly spelled out invariants. If it takes three steps instead of one to accomplish a typical task, that's fine. The programs that layer on top of /dev/cpuset don't mind doing three things to get one thing done. But such programs are a pain in the backside to program correctly if the affects of each operation are not clearly defined, not focused on the obvious object being operated on, or not precisely consistent with an overriding model. This patch seems to add side affects and the change the meanings of things, doing so with the most minimum of mention in the description, without clearly and consistently spelling out the new mental model, and without uniformly changing all uses, comments and documentation to fit the new model. This cpuset facility is also a less commonly used kernel facility, and changes to cpusets, outside of a few key hooks in the scheduler and allocator, are not performance critical. This means that there is a premium in keeping the kernel code minimal, leaving as many details as practical to userland. This patch seems to increase the kernel text size, for an ia64 SN2 build using gcc 3.2.3 of a 2.6.12-rc1-mm4 tree I had at hand, _just_ for the cpuset.c changes, from 23071 bytes to 28999. That's over a 25% per-cent increase in the kernel text size of the file kernel/cpuset.o, just for this feature. That's too much, in my view. I don't know yet if the ability to move cpus between isolated sched domains without tearing them down and rebuilding them, is a critical feature for you or not. You have not been clear on what are the essential requirements of this feature. I don't even know for sure yet that this is the one key feature in your view that separates your proposal from the variations I explored. But if this is for you the critical feature that your proposal has, and mine lack, then I'd like to see if there is a way to do it without implicit side affects, without messing with the semantics of what's there now, and with significantly fewer bytes of kernel text space. And I'd like to see if we can have uniform and precisely spelled out semantics, in the code, comments and documentation, with any changes to the current semantics made everywhere, uniformly. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.12-rc2-mm3 pciehp regression
On Friday, April 15, 2005 12:48 PM, Tom Duffy wrote: > From: "Sy, Dely L" <[EMAIL PROTECTED]> > > Thanks for reporting this. I'll look into it. Which was the last > > kernel you tested on your hw and worked for you? > That is a good question. I think it was a 2.6.11 kernel. It was > definately before express was moved to a different directory, > whenever that occured. Tom, I was not able to duplicate this problem on my system yet for I have trouble in getting my system booted up on 2.6.12-rc2-mm3. I did some back-tracking and found that the boot problem occurred also with 2.6.12-rc2-mm2 & 2.6.12-rc2-mm3, and on two systems using IDE as boot drive. The config file I used worked fine on 2.6.11.7. I tried different config file without success. The errors I encountered were: Reading all physical volumes. This may take a while... Umount /sys failed: 16 mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root Switchroot: mount failed 22 umount /initrd/dev failed: 2 I also encountered issue you & others discussed in the thread on "Re: Heads up on 2.6.12-rc1 and later" if I used SCSI drive. Can you send me the config file you used successfully on your system? Thanks, Dely - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] nameing reserved pages [0/3]
On Wed, 2005-04-20 at 14:34 +0200, Arjan van de Ven wrote: > On Wed, 2005-04-20 at 21:02 +0900, KAMEZAWA Hiroyuki wrote: > > Hi, > > > > There are several types of PG_reserved pages, > > (a) Memory Hole > > (b) Used by Kernel > > (c) Set by drivers > > (d) Isorated by MCA > > (e) used by perfmon > > etc > > > > I think it's useful to distinguish many types of PG_reserved pages. > > I'm not so sure about this. at all. Neither am I, that's why I hoped somebody would figure out something better :) > > For example, Memory Hotplug can ignore (a). > > Memory Hotplug can also use page_is_ram(). It uses this, to some degree, internally. But, things like the e820 table don't get updated as memory hotplugs occur. This should a way to give more fine-grained information about what pages are availabe as RAM at any point in time. kdump would need something like this to figure out which pages inside of /dev/mem are actually valid to dump. Here was another approach that used /proc files: http://lkml.org/lkml/2005/3/24/11 > /dev/memstate really looks like a bad idea to me as well... I rather > have less than more /dev/*mem* Any other ideas? -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NForce4 ide problems?
FWIW problem happens way before any driver is loaded ( i.e nVidia ) so
this is not a such problem.
On 4/20/05, ismail dönmez <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I recently bought an Asus A8N-SLI mobo and an AMD 3500+ CPU for my
> system but my ide drive seems to have some problems with them. Here is
> what I get at boot :
>
>
> hda: 156368016 sectors (80060 MB) w/2048KiB Cache, CHS=16383/255/63,
> UDMA(100)
> hda: cache flushes supported
> /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 {
> DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> ide: failed opcode was: unknown
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> ide: failed opcode was: unknown
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> ide: failed opcode was: unknown
>
>
> First I thought it was bad ide cable ( because I wasn't using the one
> that came with mobo ) so I tried with the brand new cable coming with
> mobo and same error happened. Also trying to do something like :
>
> hdparm -m16 -c -u1 -d1 -Xudma2 /dev/hda
>
> results in a cpu exception thrown and a kernel panic after that. Full
> dmesg log is attached. I appreciate any help/comments.
>
> P.S: I tried with kernel 2.6.10 and 2.6.12-rc2 and same problems happen
>
> Regards,
> ismail
>
>
> --
> Time is what you make of it
>
>
--
Time is what you make of it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux with disabled interrupts
On Wed, 20 Apr 2005, Francesco Oppedisano wrote: Hi, i'd like to know how much time does linux kernel run with disabled interrupts. So i would like to remap the instructions capable of disabling interrupt to other ones which count how much this time is... Does already exist a patch or tool capable to give me a magnitude order of the time spent by the kernel with disables interrupts? In uniprocessor systems, can i state that the only instruction capable of disabling interrupts is cli? How do you propose to "remap" the CLI instruction? The kernel isn't going to trap on this perfectly legal instruction in kernel mode. Also, interrupts can be disabled by masking them off in the controller(s) so there are many ways that any/all interrupts can be disabled. Thank u very much Francesco Oppedisano - Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
I was curious if your patch would change the write rate because I see only ~550MB/s (continuous) which is about a factor two away from the capabilities of the disks. ... and got this behaviour (with and without my other patch): (with single "dd if=/dev/zero of=testxx bs=65536 count=15 &" or several of them in parallel on an XFS fs) "vmstat 1" output 0 0 0 28416 37888 1577836800 0 0 8485 3043 0 0 0 100 6 0 0 22144 37952 1578592000 0 12356 7695 2029 0 61 0 39 7 0 0 20864 38016 1578585600 324 1722240 8046 4159 0 100 0 0 7 0 0 20864 38016 1578476800 0 1261440 8391 5222 0 100 0 0 7 0 0 25984 38016 1578150400 0 2003456 8372 5038 0 100 0 0 0 6 0 22784 38016 1578150400 0 2826624 8397 8423 0 93 7 0 0 0 0 21632 38016 1578368000 0 147840 8572 12114 0 9 17 74 0 0 0 21632 38016 1578368000 052 8586 5185 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 8588 5412 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 8580 5372 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 7840 5590 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 8587 5321 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 8569 5575 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 8550 5157 0 0 0 100 0 0 0 21632 38016 1578368000 0 0 7963 5640 0 0 0 100 0 0 0 21632 38016 1578368000 032 8583 4434 0 0 0 100 7 0 0 20800 38016 1578476800 0 7424 8404 3638 0 15 0 85 8 0 0 20864 38016 1578694400 0 688768 7357 3221 0 100 0 0 8 0 0 20736 28544 1579424000 0 1978560 8376 4897 0 100 0 0 7 0 0 22208 20736 1579878400 0 1385088 8367 4984 0 100 0 0 6 0 0 22144 6848 158126720056 1291904 8377 4815 0 100 0 0 0 0 0 50240 6848 1580940800 304 3136 8556 5088 1 26 0 74 0 0 0 50304 6848 1580940800 0 0 8572 5181 0 0 0 100 The average rate here is again pretty close to 550MB/s, it just writes the blocks in "bursts"... Andreas jmerkey wrote: For 3Ware, you need to chage the queue depths, and you will see dramatically improved performance. 3Ware can take requests a lot faster than Linux pushes them out. Try changing this instead, you won't be going to sleep all the time waiting on the read/write request queues to get "unstarved". /linux/include/linux/blkdev.h //#define BLKDEV_MIN_RQ 4 //#define BLKDEV_MAX_RQ 128 /* Default maximum */ #define BLKDEV_MIN_RQ 4096 #define BLKDEV_MAX_RQ 8192 /* Default maximum */ Jeff Andreas Hirstius wrote: Hi, We have a rx4640 with 3x 3Ware 9500 SATA controllers and 24x WD740GD HDD in a software RAID0 configuration (using md). With kernel 2.6.11 the read performance on the md is reduced by a factor of 20 (!!) compared to previous kernels. The write rate to the md doesn't change!! (it actually improves a bit). The config for the kernels are basically identical. Here is some vmstat output: kernel 2.6.9: ~1GB/s read procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy wa id 1 1 0 12672 6592 15914112 0 0 1081344 56 15719 1583 0 11 14 74 1 0 0 12672 6592 15915200 0 0 1130496 0 15996 1626 0 11 14 74 0 1 0 12672 6592 15914112 0 0 1081344 0 15891 1570 0 11 14 74 0 1 0 12480 6592 15914112 0 0 1081344 0 15855 1537 0 11 14 74 1 0 0 12416 6592 15914112 0 0 1130496 0 16006 1586 0 12 14 74 kernel 2.6.11: ~55MB/s read procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy wa id 1 1 0 24448 37568 15905984 0 0 56934 0 5166 1862 0 1 24 75 0 1 0 20672 37568 15909248 0 0 57280 0 5168 1871 0 1 24 75 0 1 0 22848 37568 15907072 0 0 57306 0 5173 1874 0 1 24 75 0 1 0 25664 37568 15903808 0 0 57190 0 5171 1870 0 1 24 75 0 1 0 21952 37568 15908160 0 0 57267 0 5168 1871 0 1 24 75 Because the filesystem might have an impact on the measurement, "dd" on /dev/md0 was used to get information about the performance. This also opens the possibility to test with block sizes larger than the page size. And it appears that the performance with kernel 2.6.11 is closely related to the block size. For example if the block size is exactly a multiple (>2) of the page size the performance is back to ~1.1GB/s. The general behaviour is a bit more complicated: 1. bs <= 1.5 * ps : ~27-57MB/s (differs with ps) 2. bs > 1.5 * ps && bs < 2 * ps : rate increases to max. rate 3. bs = n * ps ; (n >= 2) : ~1.1GB/s (== max. rate) 4. bs > n * ps && bs < ~(n+0.5) * ps ; (n > 2) : ~27-70MB/s (differs with ps) 5. bs > ~(n+0.5) * ps && bs < (n+1) * ps ; (n > 2) : increasing rate in several, more or less, distinct steps (e.g. 1/3 of max. rate and then 2/3 of max rate for 64k
Re: linux with disabled interrupts
On Wed, 2005-04-20 at 18:05 +, Francesco Oppedisano wrote: > Hi, > i'd like to know how much time does linux kernel run with disabled > interrupts. So i would like to remap the instructions capable of > disabling interrupt to other ones which count how much this time is... > Does already exist a patch or tool capable to give me a magnitude > order of the time spent by the kernel with disables interrupts? http://people.redhat.com/mingo/realtime-preempt Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 stuff again
On Thu, 2005-04-14 at 16:01 +0200, Helge Hafting wrote: > instead of keeping them secret for no > good reason. But *that's* the point people keep ignoring: the specs for programming the hardware, in some cases, reveals details about the hardware's implementation that nVidia does *not* want to release (in addition to suggesting their software tricks). Why is it that people *assume* that just the programming docs tells a person nothing about the hardware? We already know that knowing the registers of a card and what those registers do tells you implicit information about the card's design and also reveals implicit information about the design of software that works with the card. How complex the card's registers and programming interface is determines how much you can infer, and the more RISC like or simple the card is and the more that is handled in the driver, the more obviously the design can be inferred just from the programming specs. The aic7xxx chips are a perfect example of this exact same thing. If you know how to program the registers on that card, then you know almost everything about the hardware. It's that simple (and that's a big part of what makes it very fast, lots of room for driver optimizations and enhanced feature support). -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-dvb-maintainer] [2.6 patch] drivers/media/dvb/: possible cleanups
On Tue, Apr 19, 2005 at 02:43:08AM +0200, Adrian Bunk wrote: > This patch contains the following possible cleanups: > - make needlessly global code static > - #if 0 the following unused global functions: > - dibusb/dvb-dibusb-usb.c: dibusb_set_streaming_mode > - frontends/mt352.c: mt352_read > - ttpci/av7110_hw.c: av7110_reset_arm > - ttpci/av7110_hw.c: av7110_send_ci_cmd > - remove the following unneeded EXPORT_SYMBOL: > - frontends/mt352.c: mt352_read > > Please review which of these changes do make sense. I'll apply this patch to linuxtv.org CVS. Most cleanups look fine, except the dibusb driver has been superseded by a generalized dvb-usb driver. mt352_read() can be dropped completely. Thanks, Johannes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux with disabled interrupts
Hi, i'd like to know how much time does linux kernel run with disabled interrupts. So i would like to remap the instructions capable of disabling interrupt to other ones which count how much this time is... Does already exist a patch or tool capable to give me a magnitude order of the time spent by the kernel with disables interrupts? In uniprocessor systems, can i state that the only instruction capable of disabling interrupts is cli? Thank u very much Francesco Oppedisano - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
Just tried it, but the performance problem remains :-(
(actually, why should it change? This part of the code didn't change so
much between 2.6.10-bk6 and -bk7...)
Andreas
jmerkey wrote:
For 3Ware, you need to chage the queue depths, and you will see
dramatically improved performance. 3Ware can take requests
a lot faster than Linux pushes them out. Try changing this instead,
you won't be going to sleep all the time waiting on the read/write
request queues to get "unstarved".
/linux/include/linux/blkdev.h
//#define BLKDEV_MIN_RQ 4
//#define BLKDEV_MAX_RQ 128 /* Default maximum */
#define BLKDEV_MIN_RQ 4096
#define BLKDEV_MAX_RQ 8192 /* Default maximum */
Jeff
Andreas Hirstius wrote:
Hi,
We have a rx4640 with 3x 3Ware 9500 SATA controllers and 24x WD740GD
HDD in a software RAID0 configuration (using md).
With kernel 2.6.11 the read performance on the md is reduced by a
factor of 20 (!!) compared to previous kernels.
The write rate to the md doesn't change!! (it actually improves a bit).
The config for the kernels are basically identical.
Here is some vmstat output:
kernel 2.6.9: ~1GB/s read
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
1 1 0 12672 6592 15914112 0 0 1081344 56 15719 1583 0 11 14 74
1 0 0 12672 6592 15915200 0 0 1130496 0 15996 1626 0 11 14 74
0 1 0 12672 6592 15914112 0 0 1081344 0 15891 1570 0 11 14 74
0 1 0 12480 6592 15914112 0 0 1081344 0 15855 1537 0 11 14 74
1 0 0 12416 6592 15914112 0 0 1130496 0 16006 1586 0 12 14 74
kernel 2.6.11: ~55MB/s read
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
1 1 0 24448 37568 15905984 0 0 56934 0 5166 1862 0 1 24 75
0 1 0 20672 37568 15909248 0 0 57280 0 5168 1871 0 1 24 75
0 1 0 22848 37568 15907072 0 0 57306 0 5173 1874 0 1 24 75
0 1 0 25664 37568 15903808 0 0 57190 0 5171 1870 0 1 24 75
0 1 0 21952 37568 15908160 0 0 57267 0 5168 1871 0 1 24 75
Because the filesystem might have an impact on the measurement, "dd"
on /dev/md0
was used to get information about the performance. This also opens
the possibility to test with block sizes larger than the page size.
And it appears that the performance with kernel 2.6.11 is closely
related to the block size.
For example if the block size is exactly a multiple (>2) of the page
size the performance is back to ~1.1GB/s.
The general behaviour is a bit more complicated:
1. bs <= 1.5 * ps : ~27-57MB/s (differs with ps)
2. bs > 1.5 * ps && bs < 2 * ps : rate increases to max. rate
3. bs = n * ps ; (n >= 2) : ~1.1GB/s (== max. rate)
4. bs > n * ps && bs < ~(n+0.5) * ps ; (n > 2) : ~27-70MB/s (differs
with ps)
5. bs > ~(n+0.5) * ps && bs < (n+1) * ps ; (n > 2) : increasing rate
in several, more or
less, distinct steps (e.g. 1/3 of max. rate and then 2/3 of max rate
for 64k pages)
I've tested all four possible page sizes on Itanium (4k, 8k, 16k and
64k) and the pattern is always the same!!
With kernel 2.6.9 (any kernel before 2.6.10-bk6) the read rate is
always at ~1.1GB/s,
independent of the block size.
This simple patch solves the problem, but I have no idea of possible
side-effects ...
--- linux-2.6.12-rc2_orig/mm/filemap.c 2005-04-04 18:40:05.0
+0200
+++ linux-2.6.12-rc2/mm/filemap.c 2005-04-20 10:27:42.0 +0200
@@ -719,7 +719,7 @@
index = *ppos >> PAGE_CACHE_SHIFT;
next_index = index;
prev_index = ra.prev_page;
- last_index = (*ppos + desc->count + PAGE_CACHE_SIZE-1) >>
PAGE_CACHE_SHIFT;
+ last_index = (*ppos + desc->count + PAGE_CACHE_SIZE) >>
PAGE_CACHE_SHIFT;
offset = *ppos & ~PAGE_CACHE_MASK;
isize = i_size_read(inode);
--- linux-2.6.12-rc2_orig/mm/readahead.c 2005-04-04
18:40:05.0 +0200
+++ linux-2.6.12-rc2/mm/readahead.c 2005-04-20 18:37:04.0 +0200
@@ -70,7 +70,7 @@
*/
static unsigned long get_init_ra_size(unsigned long size, unsigned
long max)
{
- unsigned long newsize = roundup_pow_of_two(size);
+ unsigned long newsize = size;
if (newsize <= max / 64)
newsize = newsize * newsize;
In order to keep this mail short, I've created a webpage that
contains all the detailed information and some plots:
http://www.cern.ch/openlab-debugging/raid
Regards,
Andreas Hirstius
-
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
the body of a message 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: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
For 3Ware, you need to chage the queue depths, and you will see
dramatically improved performance. 3Ware can take requests
a lot faster than Linux pushes them out. Try changing this instead, you
won't be going to sleep all the time waiting on the read/write
request queues to get "unstarved".
/linux/include/linux/blkdev.h
//#define BLKDEV_MIN_RQ 4
//#define BLKDEV_MAX_RQ 128 /* Default maximum */
#define BLKDEV_MIN_RQ 4096
#define BLKDEV_MAX_RQ 8192 /* Default maximum */
Jeff
Andreas Hirstius wrote:
Hi,
We have a rx4640 with 3x 3Ware 9500 SATA controllers and 24x WD740GD
HDD in a software RAID0 configuration (using md).
With kernel 2.6.11 the read performance on the md is reduced by a
factor of 20 (!!) compared to previous kernels.
The write rate to the md doesn't change!! (it actually improves a bit).
The config for the kernels are basically identical.
Here is some vmstat output:
kernel 2.6.9: ~1GB/s read
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
1 1 0 12672 6592 15914112 0 0 1081344 56 15719 1583 0 11 14 74
1 0 0 12672 6592 15915200 0 0 1130496 0 15996 1626 0 11 14 74
0 1 0 12672 6592 15914112 0 0 1081344 0 15891 1570 0 11 14 74
0 1 0 12480 6592 15914112 0 0 1081344 0 15855 1537 0 11 14 74
1 0 0 12416 6592 15914112 0 0 1130496 0 16006 1586 0 12 14 74
kernel 2.6.11: ~55MB/s read
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
1 1 0 24448 37568 15905984 0 0 56934 0 5166 1862 0 1 24 75
0 1 0 20672 37568 15909248 0 0 57280 0 5168 1871 0 1 24 75
0 1 0 22848 37568 15907072 0 0 57306 0 5173 1874 0 1 24 75
0 1 0 25664 37568 15903808 0 0 57190 0 5171 1870 0 1 24 75
0 1 0 21952 37568 15908160 0 0 57267 0 5168 1871 0 1 24 75
Because the filesystem might have an impact on the measurement, "dd"
on /dev/md0
was used to get information about the performance. This also opens the
possibility to test with block sizes larger than the page size.
And it appears that the performance with kernel 2.6.11 is closely
related to the block size.
For example if the block size is exactly a multiple (>2) of the page
size the performance is back to ~1.1GB/s.
The general behaviour is a bit more complicated:
1. bs <= 1.5 * ps : ~27-57MB/s (differs with ps)
2. bs > 1.5 * ps && bs < 2 * ps : rate increases to max. rate
3. bs = n * ps ; (n >= 2) : ~1.1GB/s (== max. rate)
4. bs > n * ps && bs < ~(n+0.5) * ps ; (n > 2) : ~27-70MB/s (differs
with ps)
5. bs > ~(n+0.5) * ps && bs < (n+1) * ps ; (n > 2) : increasing rate
in several, more or
less, distinct steps (e.g. 1/3 of max. rate and then 2/3 of max rate
for 64k pages)
I've tested all four possible page sizes on Itanium (4k, 8k, 16k and
64k) and the pattern is always the same!!
With kernel 2.6.9 (any kernel before 2.6.10-bk6) the read rate is
always at ~1.1GB/s,
independent of the block size.
This simple patch solves the problem, but I have no idea of possible
side-effects ...
--- linux-2.6.12-rc2_orig/mm/filemap.c 2005-04-04 18:40:05.0
+0200
+++ linux-2.6.12-rc2/mm/filemap.c 2005-04-20 10:27:42.0 +0200
@@ -719,7 +719,7 @@
index = *ppos >> PAGE_CACHE_SHIFT;
next_index = index;
prev_index = ra.prev_page;
- last_index = (*ppos + desc->count + PAGE_CACHE_SIZE-1) >>
PAGE_CACHE_SHIFT;
+ last_index = (*ppos + desc->count + PAGE_CACHE_SIZE) >>
PAGE_CACHE_SHIFT;
offset = *ppos & ~PAGE_CACHE_MASK;
isize = i_size_read(inode);
--- linux-2.6.12-rc2_orig/mm/readahead.c 2005-04-04 18:40:05.0
+0200
+++ linux-2.6.12-rc2/mm/readahead.c 2005-04-20 18:37:04.0 +0200
@@ -70,7 +70,7 @@
*/
static unsigned long get_init_ra_size(unsigned long size, unsigned
long max)
{
- unsigned long newsize = roundup_pow_of_two(size);
+ unsigned long newsize = size;
if (newsize <= max / 64)
newsize = newsize * newsize;
In order to keep this mail short, I've created a webpage that contains
all the detailed information and some plots:
http://www.cern.ch/openlab-debugging/raid
Regards,
Andreas Hirstius
-
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
the body of a message 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/
[PATCH] tty races
There are a couple of tty race conditions, which lead to inconsistent tty
reference counting and tty layer oopses.
The first is a tty_open vs. tty_close race in drivers/char/tty.io.c.
Basically, from the time that the tty->count is deemed to be 1 and that we
are going to free it to the time that TTY_CLOSING bit is set, needs to be
atomic with respect to the manipulation of tty->count in init_dev(). This
atomicity was previously guarded by the BKL. However, this is no longer
true with the addition of a down() call in the middle of the
release_dev()'s atomic path. So either the down() needs to be moved
outside the atomic patch or dropped. I would vote for simply dropping it
as i don't see why it is necessary.
The second race is tty_open vs. tty_open. This race I've seen when the
virtual console is the tty driver. In con_open(), vc_allocate() is called
if the tty->count is 1. However, this check of the tty->count is not
guarded by the 'tty_sem'. Thus, it is possible for con_open(), to never
see the tty->count as 1, and thus never call vc_allocate(). This leads to
a NULL filp->private_data, and an oops.
The test case below reproduces these problems, and the patch fixes it. The
test case uses /dev/tty9, which is generally restricted to root for
open(). It may be able to exploit these races using pseudo terminals,
although i wasn't able to. A previous report of this issue, with an oops
trace was: http://www.ussg.iu.edu/hypermail/linux/kernel/0503.2/0017.html
thanks,
-Jason
--- linux/drivers/char/tty_io.c.bak
+++ linux/drivers/char/tty_io.c
@@ -1596,14 +1596,9 @@ static void release_dev(struct file * fi
* each iteration we avoid any problems.
*/
while (1) {
- /* Guard against races with tty->count changes elsewhere and
- opens on /dev/tty */
-
- down(_sem);
tty_closing = tty->count <= 1;
o_tty_closing = o_tty &&
(o_tty->count <= (pty_master ? 1 : 0));
- up(_sem);
do_sleep = 0;
if (tty_closing) {
@@ -1640,7 +1635,6 @@ static void release_dev(struct file * fi
* block, so it's safe to proceed with closing.
*/
- down(_sem);
if (pty_master) {
if (--o_tty->count < 0) {
printk(KERN_WARNING "release_dev: bad pty slave count "
@@ -1654,7 +1648,6 @@ static void release_dev(struct file * fi
tty->count, tty_name(tty, buf));
tty->count = 0;
}
- up(_sem);
/*
* We've decremented tty->count, so we need to remove this file
@@ -1844,9 +1837,10 @@ retry_open:
}
got_driver:
retval = init_dev(driver, index, );
- up(_sem);
- if (retval)
+ if (retval) {
+ up(_sem);
return retval;
+ }
filp->private_data = tty;
file_move(filp, >tty_files);
@@ -1863,6 +1857,7 @@ got_driver:
else
retval = -ENODEV;
}
+ up(_sem);
filp->f_flags = saved_flags;
if (!retval && test_bit(TTY_EXCLUSIVE, >flags) &&
!capable(CAP_SYS_ADMIN))
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define NTHREADS 300
void *thread_function();
int open_fail_num;
int open_success;
int
main(int argc, char *argv[])
{
int i, j;
pthread_t thread_id[NTHREADS];
for(;;) {
for(i=0; i < NTHREADS; i++) {
pthread_create(_id[i], NULL, _function,
NULL);
}
for(j=0; j < NTHREADS; j++) {
pthread_join(thread_id[j], NULL);
}
printf("open failures: %i\n", open_fail_num);
printf("open success: %i\n", open_success);
}
}
void *thread_function()
{
int fd;
time_t t;
int val;
int ret;
fd = open("/dev/tty9", O_RDWR);
val = 0;
//call an ioctl
ret = ioctl(fd, KDGETMODE, );
if (ret != 0) {
perror("ioctl error\n");
}
if (fd < 0) {
open_fail_num++;
} else {
open_success++;
}
/* just waste some random time */
t = (time((time_t *)0) &31L) << 6;
while (t-- > 0)
(void)time((time_t *)0);
close(fd);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
Hi,
We have a rx4640 with 3x 3Ware 9500 SATA controllers and 24x WD740GD HDD
in a software RAID0 configuration (using md).
With kernel 2.6.11 the read performance on the md is reduced by a factor
of 20 (!!) compared to previous kernels.
The write rate to the md doesn't change!! (it actually improves a bit).
The config for the kernels are basically identical.
Here is some vmstat output:
kernel 2.6.9: ~1GB/s read
procs memory swap io
system cpu
r b swpd free buff cache si sobibo incs us sy wa id
1 1 0 12672 6592 1591411200 108134456 15719 1583 0 11 14 74
1 0 0 12672 6592 1591520000 1130496 0 15996 1626 0 11 14 74
0 1 0 12672 6592 1591411200 1081344 0 15891 1570 0 11 14 74
0 1 0 12480 6592 1591411200 1081344 0 15855 1537 0 11 14 74
1 0 0 12416 6592 1591411200 1130496 0 16006 1586 0 12 14 74
kernel 2.6.11: ~55MB/s read
procs memory swap io
system cpu
r b swpd free buff cache si sobibo incs us sy wa id
1 1 0 24448 37568 1590598400 56934 0 5166 1862 0 1 24 75
0 1 0 20672 37568 1590924800 57280 0 5168 1871 0 1 24 75
0 1 0 22848 37568 1590707200 57306 0 5173 1874 0 1 24 75
0 1 0 25664 37568 1590380800 57190 0 5171 1870 0 1 24 75
0 1 0 21952 37568 1590816000 57267 0 5168 1871 0 1 24 75
Because the filesystem might have an impact on the measurement, "dd" on /dev/md0
was used to get information about the performance.
This also opens the possibility to test with block sizes larger than the page size.
And it appears that the performance with kernel 2.6.11 is closely
related to the block size.
For example if the block size is exactly a multiple (>2) of the page
size the performance is back to ~1.1GB/s.
The general behaviour is a bit more complicated:
1. bs <= 1.5 * ps : ~27-57MB/s (differs with ps)
2. bs > 1.5 * ps && bs < 2 * ps : rate increases to max. rate
3. bs = n * ps ; (n >= 2) : ~1.1GB/s (== max. rate)
4. bs > n * ps && bs < ~(n+0.5) * ps ; (n > 2) : ~27-70MB/s (differs
with ps)
5. bs > ~(n+0.5) * ps && bs < (n+1) * ps ; (n > 2) : increasing rate
in several, more or
less, distinct steps (e.g. 1/3 of max. rate and then 2/3 of max
rate for 64k pages)
I've tested all four possible page sizes on Itanium (4k, 8k, 16k and 64k) and the pattern is
always the same!!
With kernel 2.6.9 (any kernel before 2.6.10-bk6) the read rate is always at
~1.1GB/s,
independent of the block size.
This simple patch solves the problem, but I have no idea of possible
side-effects ...
--- linux-2.6.12-rc2_orig/mm/filemap.c 2005-04-04 18:40:05.0 +0200
+++ linux-2.6.12-rc2/mm/filemap.c 2005-04-20 10:27:42.0 +0200
@@ -719,7 +719,7 @@
index = *ppos >> PAGE_CACHE_SHIFT;
next_index = index;
prev_index = ra.prev_page;
- last_index = (*ppos + desc->count + PAGE_CACHE_SIZE-1) >>
PAGE_CACHE_SHIFT;
+ last_index = (*ppos + desc->count + PAGE_CACHE_SIZE) >>
PAGE_CACHE_SHIFT;
offset = *ppos & ~PAGE_CACHE_MASK;
isize = i_size_read(inode);
--- linux-2.6.12-rc2_orig/mm/readahead.c2005-04-04 18:40:05.0
+0200
+++ linux-2.6.12-rc2/mm/readahead.c 2005-04-20 18:37:04.0 +0200
@@ -70,7 +70,7 @@
*/
static unsigned long get_init_ra_size(unsigned long size, unsigned long max)
{
- unsigned long newsize = roundup_pow_of_two(size);
+ unsigned long newsize = size;
if (newsize <= max / 64)
newsize = newsize * newsize;
In order to keep this mail short, I've created a webpage that contains
all the detailed information and some plots:
http://www.cern.ch/openlab-debugging/raid
Regards,
Andreas Hirstius
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel page table and module text
Allison <[EMAIL PROTECTED]> wrote: > I want to find where each module is loaded in memory by traversing the > module list . Once I have the address and the size of the module, I > want to read the bytes in memory of the module and hash it to check > it's integrity. JFTR: This may work against random memory corruption, but it will fail for detecting attacks. -- Top 100 things you don't want the sysadmin to say: 54. Uh huh.."nu -k $USER".. no problemsure thing... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.12-rc2] aoe [5/6]: add firmware version to info in sysfs
| add firmware version to info in sysfs
|
| +static struct disk_attribute disk_attr_fwver = {
| + .attr = {.name = "fwver", .mode = S_IRUGO },
| + .show = aoedisk_show_fwver
| +};
| @@ -64,6 +76,7 @@ aoedisk_rm_sysfs(struct aoedev *d)
| sysfs_remove_link(>gd->kobj, "state");
| sysfs_remove_link(>gd->kobj, "mac");
| sysfs_remove_link(>gd->kobj, "netif");
| + sysfs_remove_link(>gd->kobj, "fwver");
It's a good thing that you spelled out "firmware version"
for me.
Just seeing 'fwver' provided these comments from others:
n vwls s bd (well, it does have 'e'; maybe it shouldn't :)
friends fwver
fw is firewire
so something like 'firmware-version' would be appreciated
(for the sysfs filename).
Thanks,
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] unregister_node() for hotplug use
On Wed, Apr 20, 2005 at 09:07:44PM +0900, Keiichiro Tokunaga wrote:
> This is to add a generic function 'unregister_node()'.
> It is used to remove objects of a node going away for
> hotplug. If CONFIG_HOTPLUG=y, it becomes available.
> This is against 2.6.12-rc2-mm3.
Please CC: this kind of stuff to the driver core maintainer, otherwise
it can get dropped...
Anyway, comments below:
> diff -puN drivers/base/node.c~numa_hp_base drivers/base/node.c
> --- linux-2.6.12-rc2-mm3/drivers/base/node.c~numa_hp_base 2005-04-14
> 20:49:37.0 +0900
> +++ linux-2.6.12-rc2-mm3-kei/drivers/base/node.c 2005-04-14
> 20:49:37.0 +0900
> @@ -136,7 +136,7 @@ static SYSDEV_ATTR(distance, S_IRUGO, no
> *
> * Initialize and register the node device.
> */
> -int __init register_node(struct node *node, int num, struct node *parent)
> +int __devinit register_node(struct node *node, int num, struct node *parent)
> {
> int error;
>
> @@ -145,6 +145,9 @@ int __init register_node(struct node *no
> error = sysdev_register(>sysdev);
>
> if (!error){
> + /*
> + * If you add new object here, delete it when unregistering.
> + */
Comment really isn't needed.
> +/*
> + * unregister_node - Remove objects of a node going away from sysfs.
> + * @node - node going away
> + *
> + * This is used only for hotplug.
> + */
If you are going to create function comments, at least use the proper
kerneldoc format.
> +#ifdef CONFIG_HOTPLUG
You don't provide function prototype for when CONFIG_HOTPLUG is not
enabled.
> +void unregister_node(struct node *node)
> +{
> + if (node == NULL)
> + return;
How can this happen?
> +
> + sysdev_remove_file(>sysdev, _cpumap);
> + sysdev_remove_file(>sysdev, _meminfo);
> + sysdev_remove_file(>sysdev, _numastat);
> + sysdev_remove_file(>sysdev, _distance);
> +
> + sysdev_unregister(>sysdev);
> +}
> +EXPORT_SYMBOL(register_node);
> +EXPORT_SYMBOL(unregister_node);
All of sysfs and the driver core are EXPORT_SYMBOL_GPL(). Please follow
that convention.
> +#endif /* CONFIG_HOTPLUG */
>
> -int __init register_node_type(void)
> +static int __init register_node_type(void)
Are you sure no one calls this?
> {
> return sysdev_class_register(_class);
> }
> diff -puN include/linux/node.h~numa_hp_base include/linux/node.h
> --- linux-2.6.12-rc2-mm3/include/linux/node.h~numa_hp_base2005-04-14
> 20:49:37.0 +0900
> +++ linux-2.6.12-rc2-mm3-kei/include/linux/node.h 2005-04-14
> 20:49:37.0 +0900
> @@ -21,12 +21,16 @@
>
> #include
> #include
> +#include
Why?
>
> struct node {
> struct sys_device sysdev;
> };
>
> -extern int register_node(struct node *, int, struct node *);
> +extern int __devinit register_node(struct node *, int, struct node *);
__devinit is not needed on a function prototype.
> +#ifdef CONFIG_HOTPLUG
> +extern void unregister_node(struct node *node);
> +#endif
Not needed for a function prototype.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.12-rc2] aoe [1/6]: improve allowed interfaces configuration
On Wed, 20 Apr 2005 13:02:12 -0400 Ed L Cashin wrote:
Just a nit/typo:
| +modprobe aoe_iflist="eth1 eth3"
| static char aoe_iflist[IFLISTSZ];
| +module_param_string(aoe_iflist, aoe_iflist, IFLISTSZ, 0600);
| +MODULE_PARM_DESC(aoe_iflist, " aoe_iflist=\"dev1 [dev2 ...]\n");
No leading space (" aoe_iflist=") and put a trailing \" in it:
+MODULE_PARM_DESC(aoe_iflist, "aoe_iflist=\"dev1 [dev2 ...]\"\n");
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.12-rc2] aoe [1/6]: improve allowed interfaces configuration
"Randy.Dunlap" <[EMAIL PROTECTED]> writes:
> On Wed, 20 Apr 2005 13:02:12 -0400 Ed L Cashin wrote:
>
> Just a nit/typo:
>
> | +modprobe aoe_iflist="eth1 eth3"
>
> | static char aoe_iflist[IFLISTSZ];
> | +module_param_string(aoe_iflist, aoe_iflist, IFLISTSZ, 0600);
> | +MODULE_PARM_DESC(aoe_iflist, " aoe_iflist=\"dev1 [dev2 ...]\n");
>
> No leading space (" aoe_iflist=") and put a trailing \" in it:
>
> +MODULE_PARM_DESC(aoe_iflist, "aoe_iflist=\"dev1 [dev2 ...]\"\n");
Thanks for catching that.
improve allowed interfaces configuration
Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]>
diff -uprN a/Documentation/aoe/aoe.txt b/Documentation/aoe/aoe.txt
--- a/Documentation/aoe/aoe.txt 2005-04-20 11:40:55.0 -0400
+++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400
@@ -33,6 +33,9 @@ USING DEVICE NODES
"cat /dev/etherd/err" blocks, waiting for error diagnostic output,
like any retransmitted packets.
+ The /dev/etherd/interfaces special file is obsoleted by the
+ aoe_iflist boot option and module option (and its sysfs entry
+ described in the next section).
"echo eth2 eth4 > /dev/etherd/interfaces" tells the aoe driver to
limit ATA over Ethernet traffic to eth2 and eth4. AoE traffic from
untrusted networks should be ignored as a matter of security.
@@ -89,3 +92,24 @@ USING SYSFS
e4.7eth1 up
e4.8eth1 up
e4.9eth1 up
+
+ When the aoe driver is a module, use
+ /sys/module/aoe/parameters/aoe_iflist instead of
+ /dev/etherd/interfaces to limit AoE traffic to the network
+ interfaces in the given whitespace-separated list. Unlike the old
+ character device, the sysfs entry can be read from as well as
+ written to.
+
+ It's helpful to trigger discovery after setting the list of allowed
+ interfaces. If your distro provides an aoe-discover script, you can
+ use that. Otherwise, you can directly use the /dev/etherd/discover
+ file described above.
+
+DRIVER OPTIONS
+
+ There is a boot option for the built-in aoe driver and a
+ corresponding module parameter, aoe_iflist. Without this option,
+ all network interfaces may be used for ATA over Ethernet. Here is a
+ usage example for the module parameter.
+
+modprobe aoe_iflist="eth1 eth3"
diff -uprN a/drivers/block/aoe/aoenet.c b/drivers/block/aoe/aoenet.c
--- a/drivers/block/aoe/aoenet.c2005-04-20 11:41:18.0 -0400
+++ b/drivers/block/aoe/aoenet.c2005-04-20 11:42:20.0 -0400
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include "aoe.h"
#define NECODES 5
@@ -26,6 +27,19 @@ enum {
};
static char aoe_iflist[IFLISTSZ];
+module_param_string(aoe_iflist, aoe_iflist, IFLISTSZ, 0600);
+MODULE_PARM_DESC(aoe_iflist, "aoe_iflist=\"dev1 [dev2 ...]\"\n");
+
+#ifndef MODULE
+static int __init aoe_iflist_setup(char *str)
+{
+ strncpy(aoe_iflist, str, IFLISTSZ);
+ aoe_iflist[IFLISTSZ - 1] = '\0';
+ return 1;
+}
+
+__setup("aoe_iflist=", aoe_iflist_setup);
+#endif
int
is_aoe_netif(struct net_device *ifp)
@@ -36,7 +50,8 @@ is_aoe_netif(struct net_device *ifp)
if (aoe_iflist[0] == '\0')
return 1;
- for (p = aoe_iflist; *p; p = q + strspn(q, WHITESPACE)) {
+ p = aoe_iflist + strspn(aoe_iflist, WHITESPACE);
+ for (; *p; p = q + strspn(q, WHITESPACE)) {
q = p + strcspn(p, WHITESPACE);
if (q != p)
len = q - p;
--
Ed L Cashin <[EMAIL PROTECTED]>
Re: [RFC][PATCH] nameing reserved pages [0/3]
On Wed, 2005-04-20 at 16:30 +0200, Arjan van de Ven wrote: > Why do you want this exported to userspace? There is absolutely no way > you can get this exported race free without shutting the VM down, and > without being race free this information has absolutely no meaning !! > (and when you shut the VM down you really shouldn't depend on userspace > anymore either) The two cases where this is expected to be used are not concerned with races. The first is when a memory remove operation occurs. It first looks at the hotplug area, and removes all the pages that it can from the allocator. Then, it sets about migrating all of the other pages that are being used for things like page cache or anonymous memory. After that, the question sometimes remains why particular pages can't be removed. Kame's patch is an attempt to help figure that out. That's one reason I suggested having an individual device file for each of the memory areas that get added or removed. It would keep the confusion to a minimum, and you'd be more sure that what you were looking at was information only for the memory area that is *almost* removed. I don't know what state the system is in when the kdump folks want to read this information. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12-rc2] aoe [4/6]: allow multiple aoe devices to have the same mac
allow multiple aoe devices to have the same mac
Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]>
diff -u b/drivers/block/aoe/aoedev.c b/drivers/block/aoe/aoedev.c
--- b/drivers/block/aoe/aoedev.c2005-04-20 11:42:18.0 -0400
+++ b/drivers/block/aoe/aoedev.c2005-04-20 11:42:22.0 -0400
@@ -109,25 +109,22 @@
spin_lock_irqsave(_lock, flags);
for (d=devlist; d; d=d->next)
- if (d->sysminor == sysminor
- || memcmp(d->addr, addr, sizeof d->addr) == 0)
+ if (d->sysminor == sysminor)
break;
if (d == NULL && (d = aoedev_newdev(bufcnt)) == NULL) {
spin_unlock_irqrestore(_lock, flags);
printk(KERN_INFO "aoe: aoedev_set: aoedev_newdev failure.\n");
return NULL;
- }
+ } /* if newdev, (d->flags & DEVFL_UP) == 0 for below */
spin_unlock_irqrestore(_lock, flags);
spin_lock_irqsave(>lock, flags);
d->ifp = ifp;
-
- if (d->sysminor != sysminor
- || (d->flags & DEVFL_UP) == 0) {
+ memcpy(d->addr, addr, sizeof d->addr);
+ if ((d->flags & DEVFL_UP) == 0) {
aoedev_downdev(d); /* flushes outstanding frames */
- memcpy(d->addr, addr, sizeof d->addr);
d->sysminor = sysminor;
d->aoemajor = AOEMAJOR(sysminor);
d->aoeminor = AOEMINOR(sysminor);
--
Ed L. Cashin <[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: GPL violation by CorAccess?
Hi! > > I have seen a device by CorAccess which apparently uses Linux and didn't > > find > > anything that would suggest it complies to GPL, though I had access to the > > complete shipping package. Does anyone know about known cause of violation > > by > > this company or should I investigate further? > > Well what is the case if you use unmodified GPL code, do you still have > to provide sources to the end user if you give them binaries? I would > guess yes, but IANAL. > > As far as I can tell their system is a geode GX1 so runs standard x86 > software. Maybe they didn't have to modify any of the linux kernel to > run what they needed. Their applications are their business of course. > It looks like they use QT as the gui toolkit, which I don't off hand > know the current license conditions of. Then there is the web browser > and such, which has it's own license conditions. Of course for all I > know their user manual has an offer of sending a CD with the sources if > you ask. Does anyone actually have their product that could check for > that? QT is GPLed, IIRC. Not LGPL-ed, meaning you can't link it with proprietary application without license from trolltech. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [discuss] [Patch] X86_64 TASK_SIZE cleanup
Hi Andi, What is your comment on this patch? Here is another example bug this patch will fix. The following piece of code will get a success mmap even if compiled with -m32. int *p; p = mmap((void *)(0xE000UL), 0x1UL, PROT_READ|PROT_WRITE, MAP_FIXED|MAP_PRIVATE|MAP_ANON, 0, 0); I believe there are other kind of corner case bugs around mm and fs. e.g in mremap and munmap. Those bugs will be fixed by this patch. Zou Nan hai > -Original Message- > From: Zou, Nanhai > Sent: Tuesday, April 19, 2005 12:37 AM > To: 'Andi Kleen' > Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, Suresh B > Subject: RE: [discuss] [Patch] X86_64 TASK_SIZE cleanup > > > When a 32bit program is mapping a lot of hugepage vm_areas, > hugetlb_get_unmapped_area may search beyond 4G, then the program will get a > SIGFAULT instead of an errno of ENOMEM. > This patch will fix that. > I believe there are other inconsistent cases in generic code like mm and fs. > > Zou Nan hai > > > -Original Message- > > From: Andi Kleen [mailto:[EMAIL PROTECTED] > > Sent: Monday, April 18, 2005 5:06 PM > > To: Zou, Nanhai > > Cc: [EMAIL PROTECTED]; Andi Kleen; linux-kernel@vger.kernel.org; Siddha, > > Suresh B > > Subject: Re: [discuss] [Patch] X86_64 TASK_SIZE cleanup > > > > On Sat, Apr 16, 2005 at 09:34:25AM +0800, Zou, Nanhai wrote: > > > > > > Hi, > > >This patch will clean up the X86_64 compatibility mode TASK_SIZE > > > define thus fix some bugs found in X86_64 compatibility mode program. > > > > Fix what bugs exactly? Please a detailed description. > > > > -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12-rc2] aoe [6/6]: update version number to 10
update version number to 10 Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]> --- b/drivers/block/aoe/aoe.h 2005-04-20 11:42:19.0 -0400 +++ b/drivers/block/aoe/aoe.h 2005-04-20 11:42:22.0 -0400 @@ -1,5 +1,5 @@ /* Copyright (c) 2004 Coraid, Inc. See COPYING for GPL terms. */ -#define VERSION "6" +#define VERSION "10" #define AOE_MAJOR 152 #define DEVICE_NAME "aoe" -- Ed L. Cashin <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12-rc2] aoe [5/6]: add firmware version to info in sysfs
add firmware version to info in sysfs
Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]>
diff -uprN a/drivers/block/aoe/aoeblk.c b/drivers/block/aoe/aoeblk.c
--- a/drivers/block/aoe/aoeblk.c2005-04-20 11:41:18.0 -0400
+++ b/drivers/block/aoe/aoeblk.c2005-04-20 11:42:23.0 -0400
@@ -37,6 +37,13 @@ static ssize_t aoedisk_show_netif(struct
return snprintf(page, PAGE_SIZE, "%s\n", d->ifp->name);
}
+/* firmware version */
+static ssize_t aoedisk_show_fwver(struct gendisk * disk, char *page)
+{
+ struct aoedev *d = disk->private_data;
+
+ return snprintf(page, PAGE_SIZE, "0x%04x\n", (unsigned int) d->fw_ver);
+}
static struct disk_attribute disk_attr_state = {
.attr = {.name = "state", .mode = S_IRUGO },
@@ -50,6 +57,10 @@ static struct disk_attribute disk_attr_n
.attr = {.name = "netif", .mode = S_IRUGO },
.show = aoedisk_show_netif
};
+static struct disk_attribute disk_attr_fwver = {
+ .attr = {.name = "fwver", .mode = S_IRUGO },
+ .show = aoedisk_show_fwver
+};
static void
aoedisk_add_sysfs(struct aoedev *d)
@@ -57,6 +68,7 @@ aoedisk_add_sysfs(struct aoedev *d)
sysfs_create_file(>gd->kobj, _attr_state.attr);
sysfs_create_file(>gd->kobj, _attr_mac.attr);
sysfs_create_file(>gd->kobj, _attr_netif.attr);
+ sysfs_create_file(>gd->kobj, _attr_fwver.attr);
}
void
aoedisk_rm_sysfs(struct aoedev *d)
@@ -64,6 +76,7 @@ aoedisk_rm_sysfs(struct aoedev *d)
sysfs_remove_link(>gd->kobj, "state");
sysfs_remove_link(>gd->kobj, "mac");
sysfs_remove_link(>gd->kobj, "netif");
+ sysfs_remove_link(>gd->kobj, "fwver");
}
static int
--
Ed L. Cashin <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12-rc2] aoe [3/6]: update the documentation to mention aoetools
update the documentation to mention aoetools Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]> diff -uprN a/Documentation/aoe/aoe.txt b/Documentation/aoe/aoe.txt --- a/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400 +++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:21.0 -0400 @@ -4,6 +4,16 @@ The EtherDrive (R) HOWTO for users of 2. It has many tips and hints! +The aoetools are userland programs that are designed to work with this +driver. The aoetools are on sourceforge. + + http://aoetools.sourceforge.net/ + +The scripts in this Documentation/aoe directory are intended to +document the use of the driver and are not necessary if you install +the aoetools. + + CREATING DEVICE NODES Users of udev should find the block device nodes created @@ -33,19 +43,17 @@ USING DEVICE NODES "cat /dev/etherd/err" blocks, waiting for error diagnostic output, like any retransmitted packets. - The /dev/etherd/interfaces special file is obsoleted by the - aoe_iflist boot option and module option (and its sysfs entry - described in the next section). "echo eth2 eth4 > /dev/etherd/interfaces" tells the aoe driver to limit ATA over Ethernet traffic to eth2 and eth4. AoE traffic from - untrusted networks should be ignored as a matter of security. + untrusted networks should be ignored as a matter of security. See + also the aoe_iflist driver option described below. "echo > /dev/etherd/discover" tells the driver to find out what AoE devices are available. These character devices may disappear and be replaced by sysfs - counterparts, so distribution maintainers are encouraged to create - scripts that use these devices. + counterparts. Using the commands in aoetools insulates users from + these implementation details. The block devices are named like this: @@ -69,7 +77,8 @@ USING SYSFS through which we are communicating with the remote AoE device. There is a script in this directory that formats this information - in a convenient way. + in a convenient way. Users with aoetools can use the aoe-stat + command. [EMAIL PROTECTED] root# sh Documentation/aoe/status.sh e10.0eth3 up @@ -101,9 +110,9 @@ USING SYSFS written to. It's helpful to trigger discovery after setting the list of allowed - interfaces. If your distro provides an aoe-discover script, you can - use that. Otherwise, you can directly use the /dev/etherd/discover - file described above. + interfaces. The aoetools package provides an aoe-discover script + for this purpose. You can also directly use the + /dev/etherd/discover special file described above. DRIVER OPTIONS -- Ed L. Cashin <[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/
