Re: a question about kernel copy userspace data
2007/3/29, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
hello ,
i am programming a trial firewall based on netfilter ,which needs the module to
access the data of user space ,so i use copy_from_user() but it can't work ,the
code(simple test code) is like this:
---user space program-
#include
#include
You forgot to #include , because you used 'strcat' below.
int main(int argc ,char *argv[]) {
char para[100]="insmod test.ko ";
int c=24;
unsigned int point=&c;
Bad code. 'unsigned int' is _not_ enough to hold a pointer on 64-bit
machines. Try 'unsigned long' please.
printf("%u\n",point);
char b[11]="00"; /*convert the unsigned to chars */
int j=10;
int siz=0;
while(point>0) {
b[--j]=point%10+48;
point=point/10;
siz++;
}
char ips[30]="point=";
strcat(ips,&b[10-siz]);
strcat(para,ips);
puts(para);
system("make");
system(para);
return 0;
}
Why don't you try to use a shell/Perl/Python script instead? C is
_not_ good at this.
---kernel module---
#include
#include
#include
#include
MODULE_LICENSE("Dual BSD/GPL");
static unsigned int *point;
module_param(point, uint , S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP);
MODULE_PARM_DESC(point, "the pointer of user space");
static unsigned int
linuxmag_hook(unsigned int hook, struct sk_buff **pskb,
const struct net_device *indev, const
struct net_device *outdev, int
(*okfn)(struct sk_buff *))
{
printk("world\n");
printk(" %u\n",point);
int *b;
b=kmalloc(sizeof(int),GFP_KERNEL);
Please ALWAYS check the return value of 'kmalloc'.
ps. What prevents you to define an 'int' instead of defining a pointer
first then alloc memory?
copy_from_user(b,(int *)point,sizeof(int));
printk("user space's value=%u\n",*b);
}
static struct nf_hook_ops linuxmag_ops
= { .hook = linuxmag_hook,
.owner = THIS_MODULE,
.pf = PF_INET,
.hooknum = NF_IP_LOCAL_OUT,
.priority = NF_IP_PRI_FILTER-1
};
static int __init init(void)
{
return nf_register_hook(&linuxmag_ops);
}
static void __exit fini(void)
{
nf_unregister_hook(&linuxmag_ops);
}
module_init(init);
module_exit(fini);
i check the /var/log/messages.
the user space's value is 0
not the right value 24 which i defined in main().
this question puzzled me for a few days,and i am a fresh man about kernel.is
there anyone can help me?
any answer would be appreciated very much .
--
So Dark The Con Of Man.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On 3/28/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Wed, 28 Mar 2007 13:55:54 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > My laptop (HP dv1240us) is always showing that my laptop is plugged > into AC power, even when it is running off of the battery. When I > plug into the AC after running on the battery, the machine immediately > locks up. Also, the laptop lid button isn't working -- pressing it > doesn't trigger a suspend. OK, thanks. If you have time, could you please test 2.6.21-rc5 + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/origin.patch + ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/git-acpi.patch which will allow us to eliminate any non-acpi patches. Okay, I tested with those patches and got the same problems with the resulting build. I can't reproduce the hang on plugging in the AC with either 2.6.21-rc5-mm2 or the build with the patches you sent. The other problems are 100% reproducible. I have some new details: 1. Power always shows up as plugged in to AC. 2. The lid button is non-operational for initiating a suspend. 3. Suspending from the Gnome shutdown menu works. Afterwards, the lid button works for resuming from suspend. 4. If I suspend, resume and then try to shutdown; when I see the message "The machine will now halt" the power does not shut off. That is, the various buttons on my laptop stay lit up. I am forced to shutdown by holding down the power button for five seconds. I hope this helps, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)
On Thu, 29 Mar 2007 01:00:45 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > On 3/28/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Wed, 28 Mar 2007 13:55:54 -0700 > > "Miles Lane" <[EMAIL PROTECTED]> wrote: > > > > > My laptop (HP dv1240us) is always showing that my laptop is plugged > > > into AC power, even when it is running off of the battery. When I > > > plug into the AC after running on the battery, the machine immediately > > > locks up. Also, the laptop lid button isn't working -- pressing it > > > doesn't trigger a suspend. > > > > OK, thanks. > > > > If you have time, could you please test > > > > 2.6.21-rc5 + > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/origin.patch > > + > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/git-acpi.patch > > which will allow us to eliminate any non-acpi patches. > > Okay, I tested with those patches and got the same problems with the > resulting build. > I can't reproduce the hang on plugging in the AC with either > 2.6.21-rc5-mm2 or the > build with the patches you sent. The other problems are 100% reproducible. > I have some new details: > > 1. Power always shows up as plugged in to AC. > 2. The lid button is non-operational for initiating a suspend. > 3. Suspending from the Gnome shutdown menu works. Afterwards, the > lid button works for resuming from suspend. > 4. If I suspend, resume and then try to shutdown; when I see the > message "The machine will now halt" the power does not shut off. That > is, the various buttons on my laptop stay lit up. I am forced to > shutdown by holding down the power button for five seconds. > Thanks. So we can conclude that all these problems are due to changes in 2.6.21-rc5-mm2's git-acpi.patch? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: staircase deadline misc fixes
Rereading to make sure I wasn't unclear anywhere... On Thu, 2007-03-29 at 07:50 +0200, Mike Galbraith wrote: > > I don't see what a < 95% load really means. Egad. Here I'm pondering the numbers and light load as I'm typing, and my fingers (seemingly independent when mind wanders off) typed < 95% as in not fully committed, instead of "light". -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: cifs causes BUG: soft lockup detected on CPU
Anyone? I am new here, excuse me if format is wrong. Please assist with this problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Valentin Zaharov Sent: Wednesday, March 28, 2007 8:36 PM To: linux-kernel@vger.kernel.org Subject: cifs causes BUG: soft lockup detected on CPU Hi, We have continous problem with server freezes. We are using cifs mounts on apache powered web servers with content located on Win2k3 server. Servers freeze from time to time, producing following error just before freeze: Mar 26 21:50:37 UFR2 kernel: CIFS VFS: cifs_strtoUCS: char2uni returned -22 Mar 26 21:51:45 UFR2 last message repeated 55 times Mar 26 21:52:49 UFR2 last message repeated 30 times Mar 26 21:54:16 UFR2 last message repeated 10 times Mar 26 21:56:13 UFR2 last message repeated 20 times Mar 26 21:58:34 UFR2 last message repeated 75 times Mar 26 21:59:43 UFR2 last message repeated 30 times Mar 26 22:01:02 UFR2 last message repeated 30 times Mar 26 22:02:04 UFR2 last message repeated 30 times Mar 26 22:03:08 UFR2 last message repeated 50 times Mar 26 22:04:27 UFR2 last message repeated 10 times Mar 26 22:05:59 UFR2 last message repeated 20 times Mar 26 22:07:10 UFR2 last message repeated 20 times Mar 26 22:29:00 UFR2 last message repeated 64 times Mar 27 00:47:40 UFR2 last message repeated 15 times Mar 27 01:42:41 UFR2 last message repeated 95 times Mar 27 02:15:57 UFR2 last message repeated 90 times Mar 27 02:27:13 UFR2 last message repeated 45 times Mar 27 03:14:08 UFR2 last message repeated 95 times Mar 27 04:26:10 UFR2 last message repeated 2 times Mar 27 06:11:35 UFR2 last message repeated 45 times Mar 27 06:20:20 UFR2 last message repeated 15 times Mar 27 06:20:20 UFR2 last message repeated 12 times Mar 27 06:27:53 UFR2 kernel: BUG: soft lockup detected on CPU#3! Mar 27 06:27:53 UFR2 kernel: [] softlockup_tick+0x9e/0xac Mar 27 06:27:53 UFR2 kernel: [] update_process_times+0x3b/0x5e Mar 27 06:27:53 UFR2 kernel: [] smp_apic_timer_interrupt+0x6c/0x7a Mar 27 06:27:53 UFR2 kernel: [] apic_timer_interrupt+0x28/0x30 Mar 27 06:27:53 UFR2 kernel: [] generic_fillattr+0x75/0xa8 Mar 27 06:27:53 UFR2 kernel: [] cifs_getattr+0x1e/0x2b [cifs] Mar 27 06:27:53 UFR2 kernel: [] cifs_getattr+0x0/0x2b [cifs] Mar 27 06:27:53 UFR2 kernel: [] vfs_getattr+0x21/0x30 Mar 27 06:27:53 UFR2 kernel: [] vfs_fstat+0x22/0x31 Mar 27 06:27:53 UFR2 kernel: [] sys_fstat64+0xf/0x23 Mar 27 06:27:53 UFR2 kernel: [] sys_open+0x1a/0x1c Mar 27 06:27:53 UFR2 kernel: [] sysenter_past_esp+0x5d/0x81 Mar 27 06:27:53 UFR2 kernel: [] xdr_xcode_array2+0x307/0x506 Mar 27 06:27:53 UFR2 kernel: === Mar 27 06:27:54 UFR2 kernel: BUG: soft lockup detected on CPU#0! Mar 27 06:27:54 UFR2 kernel: [] softlockup_tick+0x9e/0xac Mar 27 06:27:54 UFR2 kernel: [] update_process_times+0x3b/0x5e Mar 27 06:27:54 UFR2 kernel: [] smp_apic_timer_interrupt+0x6c/0x7a Mar 27 06:27:54 UFR2 kernel: [] apic_timer_interrupt+0x28/0x30 Mar 27 06:27:54 UFR2 kernel: [] generic_fillattr+0x69/0xa8 Mar 27 06:27:54 UFR2 kernel: [] cifs_getattr+0x1e/0x2b [cifs] Mar 27 06:27:54 UFR2 kernel: [] cifs_getattr+0x0/0x2b [cifs] Mar 27 06:27:54 UFR2 kernel: [] vfs_getattr+0x21/0x30 Mar 27 06:27:54 UFR2 kernel: [] vfs_fstat+0x22/0x31 Mar 27 06:27:54 UFR2 kernel: [] sys_fstat64+0xf/0x23 Mar 27 06:27:54 UFR2 kernel: [] sys_open+0x1a/0x1c Mar 27 06:27:54 UFR2 kernel: [] sysenter_past_esp+0x5d/0x81 Mar 27 06:27:54 UFR2 kernel: === /etc/fstab \\filer\sites /mnt/filer cifs credentials=/root/domain.pass,domain=WEBDOM,port=139,rw,directio,nomapch ars,noserverino,nobrl,ui d=apache,gid=apache,iocharset=utf8,dir_mode=0755,file_mode=0755 0 0 Please advise, Valentin Zaharov System Department NetVision Ltd. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] max_loop limit, loop.c final working version
This is a diff from Ken Chen, who sent it to me a week ago and received
the claimed prize $256. I think it's partially based on Jan's code,
while if fixes the bug Jan mentioned (as far as I know).
It does the following:
- allocate loop dynamically on the fly
- allocate one more (spare) loop each time,
so losetup and mount tools can work correctly
- doesn't need any module parameters
Unfortunately 'mount' and 'losetup' binaries are hardcoded to stop
searching for free loop device after the minor num 255, so one have to
use a workaround in order to use more loops with 'mount':
$ losetup /dev/loop1000 file
$ mount /dev/loop1000 /mntpnt
I hope these binaries will be fixed soon.
Tomas M
slax.org
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 6b5b642..7db2c38 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -77,9 +77,8 @@ #include
#include
-static int max_loop = 8;
-static struct loop_device *loop_dev;
-static struct gendisk **disks;
+static LIST_HEAD(loop_devices);
+static DEFINE_SPINLOCK(loop_devices_lock);
/*
* Transfer functions
@@ -183,7 +182,7 @@ figure_loop_size(struct loop_device *lo)
if (unlikely((loff_t)x != size))
return -EFBIG;
- set_capacity(disks[lo->lo_number], x);
+ set_capacity(lo->lo_disk, x);
return 0;
}
@@ -812,7 +811,7 @@ static int loop_set_fd(struct loop_devic
lo->lo_queue->queuedata = lo;
lo->lo_queue->unplug_fn = loop_unplug;
- set_capacity(disks[lo->lo_number], size);
+ set_capacity(lo->lo_disk, size);
bd_set_size(bdev, size << 9);
set_blocksize(bdev, lo_blocksize);
@@ -832,7 +831,7 @@ out_clr:
lo->lo_device = NULL;
lo->lo_backing_file = NULL;
lo->lo_flags = 0;
- set_capacity(disks[lo->lo_number], 0);
+ set_capacity(lo->lo_disk, 0);
invalidate_bdev(bdev, 0);
bd_set_size(bdev, 0);
mapping_set_gfp_mask(mapping, lo->old_gfp_mask);
@@ -918,7 +917,7 @@ static int loop_clr_fd(struct loop_devic
memset(lo->lo_crypt_name, 0, LO_NAME_SIZE);
memset(lo->lo_file_name, 0, LO_NAME_SIZE);
invalidate_bdev(bdev, 0);
- set_capacity(disks[lo->lo_number], 0);
+ set_capacity(lo->lo_disk, 0);
bd_set_size(bdev, 0);
mapping_set_gfp_mask(filp->f_mapping, gfp);
lo->lo_state = Lo_unbound;
@@ -1322,6 +1321,23 @@ static long lo_compat_ioctl(struct file
}
#endif
+static struct loop_device *loop_find_dev(int number)
+{
+ struct loop_device *lo;
+ int found = 0;
+
+ spin_lock(&loop_devices_lock);
+ list_for_each_entry(lo, &loop_devices, lo_list) {
+ if (lo->lo_number == number) {
+ found = 1;
+ break;
+ }
+ }
+ spin_unlock(&loop_devices_lock);
+ return found ? lo : NULL;
+}
+
+static struct loop_device *loop_init_one(int i);
static int lo_open(struct inode *inode, struct file *file)
{
struct loop_device *lo = inode->i_bdev->bd_disk->private_data;
@@ -1330,6 +1346,9 @@ static int lo_open(struct inode *inode,
lo->lo_refcnt++;
mutex_unlock(&lo->lo_ctl_mutex);
+ if (!loop_find_dev(lo->lo_number + 1))
+ loop_init_one(lo->lo_number + 1);
+
return 0;
}
@@ -1357,8 +1376,6 @@ #endif
/*
* And now the modules code and kernel interface.
*/
-module_param(max_loop, int, 0);
-MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
MODULE_LICENSE("GPL");
MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);
@@ -1383,7 +1400,7 @@ int loop_unregister_transfer(int number)
xfer_funcs[n] = NULL;
- for (lo = &loop_dev[0]; lo < &loop_dev[max_loop]; lo++) {
+ list_for_each_entry(lo, &loop_devices, lo_list) {
mutex_lock(&lo->lo_ctl_mutex);
if (lo->lo_encryption == xfer)
@@ -1398,102 +1415,104 @@ int loop_unregister_transfer(int number)
EXPORT_SYMBOL(loop_register_transfer);
EXPORT_SYMBOL(loop_unregister_transfer);
-static int __init loop_init(void)
+static struct loop_device *loop_init_one(int i)
{
- int i;
+ struct loop_device *lo;
+ struct gendisk *disk;
- if (max_loop < 1 || max_loop > 256) {
- printk(KERN_WARNING "loop: invalid max_loop (must be between"
-" 1 and 256), using default (8)\n");
- max_loop = 8;
- }
+ lo = kzalloc(sizeof(*lo), GFP_KERNEL);
+ if (!lo)
+ goto out;
- if (register_blkdev(LOOP_MAJOR, "loop"))
- return -EIO;
+ lo->lo_queue = blk_alloc_queue(GFP_KERNEL);
+ if (!lo->lo_queue)
+ goto out_free_dev;
+
+ disk = lo->lo_disk = alloc_disk(1);
+ if (!disk)
+ goto out_free_queue;
+
+ mutex_init(&lo->lo_ctl_mutex);
+ lo->lo_number = i;
+ lo->lo_thread = NULL;
+ init_waitqueue_head(&lo->lo_event);
+ spin_lock_init(&lo->lo_lock);
+ disk->major = LOOP_MAJOR;
+ disk->first_minor = i;
+ disk->fops = &lo_fops;
+ disk->private_data = lo;
+ disk->queue = lo->lo_queue;
+ sprintf(disk->disk_name, "loop%d", i);
+ add_disk(disk);
+ spin_lock(&loop_devices_lock);
+ list_add_tail(&lo->lo_list, &loop_devices);
+ spin_unlock(&loop_devices_lock);
+ return lo;
+
+out_free_queue:
+ blk_cleanup_queue(lo->lo_queue);
+out_free_dev:
+ kfree(lo);
+out:
+ return ERR_PTR(-ENOMEM);
+}
- loop_dev = kmalloc(max_loop * sizeof(struct loop_device), GFP_KERNEL);
- if
Re: [PATCH 13/21] MSI: Do MSI masking in the arch code
On Wed, 2007-03-28 at 00:39 -0600, Eric W. Biederman wrote: > Michael Ellerman <[EMAIL PROTECTED]> writes: > > > It's an arch detail whether MSI irqs need to be masked using the PCI > > MSI registers. > > Agreed. It isn't an arch detail that they need to be unmasked in > the pci configuration space. > > I assume this patch is motivated just to make arch support easier > and not for RTAS compatibility reason. > > > This changes behaviour in that previously we unconditionally masked > > all MSIs, eventhough we only ever enable one, whereas now we only > > mask the irqs we're using. > > > > To be super paranoid I have the archs mask the irq before they write > > the msi message, just in case the device doesn't respect the MSI enable > > bit or MSI is already enabled or something else crazy. > > > > For MSI-X this might mean we mask the already masked MSI-X on the device, > > but that should be harmless. > > I don't think this patch really makes sense. I think we should mask > all possible vectors for msi and msi-x initially in the generic code > and then unmask them. > > If we were trying to support Dave Miller's example of hypervisors > that don't let us touch the msi registers I think there would be a > point. As it is I think this just makes the code more brittle. The main motivation was to have the arch in control of as much direct register writing as possible. Even though our HV does allow us to write to config space, it's not obviously safe for Linux to be flipping bits and also calling the HV to configure things. What's worse, I don't have hardware that supports the mask bits, so I can't test it. I also thought this would save me from having custom MSI irq_chips for the powerpc backends. But I think I need them now anyway, so I guess that's not a concern. So I guess we'll drop this one, although I might try and tidy up the implementation of "mask all MSIs" in msi_capability_init() as another patch. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: cifs causes BUG: soft lockup detected on CPU
On Wed, 28 Mar 2007 20:35:55 +0200 "Valentin Zaharov" <[EMAIL PROTECTED]> wrote: > Hi, > > We have continous problem with server freezes. We are using cifs mounts > on apache powered web servers with content located on Win2k3 server. > Servers freeze from time to time, producing following error just before > freeze: > > Mar 26 21:50:37 UFR2 kernel: CIFS VFS: cifs_strtoUCS: char2uni returned > -22 Mar 26 21:51:45 UFR2 last message repeated 55 times Mar 26 21:52:49 > UFR2 last message repeated 30 times Mar 26 21:54:16 UFR2 last message > repeated 10 times Mar 26 21:56:13 UFR2 last message repeated 20 times > Mar 26 21:58:34 UFR2 last message repeated 75 times Mar 26 21:59:43 UFR2 > last message repeated 30 times Mar 26 22:01:02 UFR2 last message > repeated 30 times Mar 26 22:02:04 UFR2 last message repeated 30 times > Mar 26 22:03:08 UFR2 last message repeated 50 times Mar 26 22:04:27 UFR2 > last message repeated 10 times Mar 26 22:05:59 UFR2 last message > repeated 20 times Mar 26 22:07:10 UFR2 last message repeated 20 times > Mar 26 22:29:00 UFR2 last message repeated 64 times Mar 27 00:47:40 UFR2 > last message repeated 15 times Mar 27 01:42:41 UFR2 last message > repeated 95 times Mar 27 02:15:57 UFR2 last message repeated 90 times > Mar 27 02:27:13 UFR2 last message repeated 45 times Mar 27 03:14:08 UFR2 > last message repeated 95 times Mar 27 04:26:10 UFR2 last message > repeated 2 times Mar 27 06:11:35 UFR2 last message repeated 45 times Mar > 27 06:20:20 UFR2 last message repeated 15 times Mar 27 06:20:20 UFR2 > last message repeated 12 times Mar 27 06:27:53 UFR2 kernel: BUG: soft > lockup detected on CPU#3! > Mar 27 06:27:53 UFR2 kernel: [] softlockup_tick+0x9e/0xac Mar > 27 06:27:53 UFR2 kernel: [] update_process_times+0x3b/0x5e > Mar 27 06:27:53 UFR2 kernel: [] > smp_apic_timer_interrupt+0x6c/0x7a > Mar 27 06:27:53 UFR2 kernel: [] > apic_timer_interrupt+0x28/0x30 Mar 27 06:27:53 UFR2 kernel: > [] generic_fillattr+0x75/0xa8 Mar 27 06:27:53 UFR2 kernel: > [] cifs_getattr+0x1e/0x2b [cifs] Mar 27 06:27:53 UFR2 kernel: > [] cifs_getattr+0x0/0x2b [cifs] Mar 27 06:27:53 UFR2 kernel: > [] vfs_getattr+0x21/0x30 Mar 27 06:27:53 UFR2 kernel: > [] vfs_fstat+0x22/0x31 Mar 27 06:27:53 UFR2 kernel: > [] sys_fstat64+0xf/0x23 Mar 27 06:27:53 UFR2 kernel: > [] sys_open+0x1a/0x1c Mar 27 06:27:53 UFR2 kernel: > [] sysenter_past_esp+0x5d/0x81 Mar 27 06:27:53 UFR2 kernel: > [] xdr_xcode_array2+0x307/0x506 Mar 27 06:27:53 UFR2 kernel: You didn't tell us what kernel version you're running. Hanging in generic_fillattr: i_size_read() got stuck. This is because CIFS doesn't correctly hold i_mutex across i_size_write(). Steve, where are we up to with the fixes for that? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch -mm 0/3] uevent_suppress handling.
Hi, following up on the firmware loading problems in 2.6.21-rc4-mm1, I've been looking into uevent_suppress and using it in the firmware class. As an added bonus, I also managed to suppress some unwanted uevents on s390. Works for me on i386 (the firmware stuff) and on s390 (the subchannel stuff). Patches are against 2.6.21-rc5-mm1. [1/3] Driver core: suppress uevents via filter. [2/3] Driver core: switch firmware_class to uevent_suppress. [3/3] s390: cio: Delay uevents for subchannels. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch -mm 1/3] Driver core: suppress uevents via filter.
From: Cornelia Huck <[EMAIL PROTECTED]>
Suppress uevents for devices if uevent_suppress is set via
dev_uevent_filter(). This makes the driver core suppress all device
uevents, not just the add event in device_add().
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
---
drivers/base/core.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
--- linux-2.6.21-rc5-mm1.orig/drivers/base/core.c
+++ linux-2.6.21-rc5-mm1/drivers/base/core.c
@@ -134,6 +134,8 @@ static int dev_uevent_filter(struct kset
if (ktype == &ktype_device) {
struct device *dev = to_dev(kobj);
+ if (dev->uevent_suppress)
+ return 0;
if (dev->bus)
return 1;
if (dev->class)
@@ -689,8 +691,7 @@ int device_add(struct device *dev)
goto PMError;
if ((error = bus_add_device(dev)))
goto BusError;
- if (!dev->uevent_suppress)
- kobject_uevent(&dev->kobj, KOBJ_ADD);
+ kobject_uevent(&dev->kobj, KOBJ_ADD);
bus_attach_device(dev);
if (parent)
klist_add_tail(&dev->knode_parent, &parent->klist_children);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch -mm 3/3] s390: cio: Delay uevents for subchannels.
From: Cornelia Huck <[EMAIL PROTECTED]>
We often have the situation that we register a subchannel and start
device recognition, only to find out that the device is not usable
after all, which triggers an unregister of the subchannel. This often
happens on hundreds of subchannels on a LPAR, leading to a storm of
events which aren't of any use. Therefore, use uevent_suppress to
delay the KOBJ_ADD uevent for a subchannel until we know that its
ccw_device is to be registered.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
---
drivers/s390/cio/css.c|9 +
drivers/s390/cio/device.c |6 ++
2 files changed, 15 insertions(+)
--- linux-2.6.21-rc5-mm1.orig/drivers/s390/cio/device.c
+++ linux-2.6.21-rc5-mm1/drivers/s390/cio/device.c
@@ -903,6 +903,12 @@ io_subchannel_register(struct work_struc
}
goto out;
}
+ /*
+* Now we know this subchannel will stay, we can throw
+* our delayed uevent.
+*/
+ sch->dev.uevent_suppress = 0;
+ kobject_uevent(&sch->dev.kobj, KOBJ_ADD);
/* make it known to the system */
ret = ccw_device_register(cdev);
if (ret) {
--- linux-2.6.21-rc5-mm1.orig/drivers/s390/cio/css.c
+++ linux-2.6.21-rc5-mm1/drivers/s390/cio/css.c
@@ -135,6 +135,15 @@ css_register_subchannel(struct subchanne
sch->dev.bus = &css_bus_type;
sch->dev.release = &css_subchannel_release;
sch->dev.groups = subch_attr_groups;
+ /*
+* We don't want to generate uevents for I/O subchannels that don't
+* have a working ccw device behind them since they will be
+* unregistered before they can be used anyway, so we delay the add
+* uevent until after device recognition was successful.
+*/
+ if (!cio_is_console(sch->schid))
+ /* Console is special, no need to suppress. */
+ sch->dev.uevent_suppress = 1;
css_get_ssd_info(sch);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch -mm 2/3] Driver core: switch firmware_class to uevent_suppress.
From: Cornelia Huck <[EMAIL PROTECTED]>
Use uevent_suppress instead of returning an error code in
firmware_uevent(). Get rid of the now unneeded FW_STATUS_READY
and FW_STATUS_READY_NOHOTPLUG.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
---
drivers/base/firmware_class.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
--- linux-2.6.21-rc5-mm1.orig/drivers/base/firmware_class.c
+++ linux-2.6.21-rc5-mm1/drivers/base/firmware_class.c
@@ -31,8 +31,6 @@ enum {
FW_STATUS_LOADING,
FW_STATUS_DONE,
FW_STATUS_ABORT,
- FW_STATUS_READY,
- FW_STATUS_READY_NOHOTPLUG,
};
static int loading_timeout = 60; /* In seconds */
@@ -96,9 +94,6 @@ static int firmware_uevent(struct device
struct firmware_priv *fw_priv = dev_get_drvdata(dev);
int i = 0, len = 0;
- if (!test_bit(FW_STATUS_READY, &fw_priv->status))
- return -ENODEV;
-
if (add_uevent_var(envp, num_envp, &i, buffer, buffer_size, &len,
"FIRMWARE=%s", fw_priv->fw_id))
return -ENOMEM;
@@ -333,6 +328,7 @@ static int fw_register_device(struct dev
f_dev->parent = device;
f_dev->class = &firmware_class;
dev_set_drvdata(f_dev, fw_priv);
+ f_dev->uevent_suppress = 1;
retval = device_register(f_dev);
if (retval) {
printk(KERN_ERR "%s: device_register failed\n",
@@ -382,9 +378,7 @@ static int fw_setup_device(struct firmwa
}
if (uevent)
-set_bit(FW_STATUS_READY, &fw_priv->status);
-else
-set_bit(FW_STATUS_READY_NOHOTPLUG, &fw_priv->status);
+ f_dev->uevent_suppress = 0;
*dev_p = f_dev;
goto out;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: cifs causes BUG: soft lockup detected on CPU
Thanks for your response! I've tried different kernel versions. Right now iam using generic 2.6.9-42 on one machine and 2.6.20.1 on another one. I also tried various distributions ( Suse, CentOS, RHEL4 ) - not sure it is relevant. Tried installing latest cifs modules, tried changing CIFSMaxBufSize to 15000, without luck. Freezes are totally random - sometimes they happen 2-4 times a day, sometimes it can take 2 weeks. Running cifs in debug mode gave following output right before crash ( should it come handy ): Feb 16 22:12:16 UFR2 kernel: fs/cifs/transport.c: Sending smb of length 178 Feb 16 22:12:16 UFR2 kernel: fs/cifs/connect.c: rfc1002 length 0x6b) Feb 16 22:12:16 UFR2 kernel: fs/cifs/file.c: inode unchanged on server Feb 16 22:12:16 UFR2 kernel: fs/cifs/inode.c: Getting info on \nv322600\www.newbyte.co.il\www\calculator.php Feb 16 22:12:16 UFR2 kernel: fs/cifs/inode.c: Old time 191743705 Feb 16 22:12:17 UFR2 kernel: fs/cifs/inode.c: New time 191743712 Feb 16 22:12:17 UFR2 kernel: fs/cifs/inode.c: File inode Feb 16 22:12:17 UFR2 kernel: fs/cifs/file.c: Exclusive Oplock granted on inode ec3d5830 Feb 16 22:12:17 UFR2 kernel: fs/cifs/file.c: CIFS VFS: leaving cifs_open (xid = 199733193) rc = 0 Feb 16 22:12:17 UFR2 kernel: fs/cifs/file.c: CIFS VFS: in cifs_user_read as Xid: 199733194 with uid: 501 Feb 16 22:12:17 UFR2 kernel: fs/cifs/cifssmb.c: Reading 8192 bytes on fid 16426 Feb 16 22:12:17 UFR2 kernel: fs/cifs/transport.c: For smb_command 46 Feb 16 22:12:17 UFR2 kernel: fs/cifs/transport.c: Sending smb: total_len 63 Feb 16 22:12:17 UFR2 kernel: fs/cifs/connect.c: rfc1002 length 0x203f) Feb 16 22:12:17 UFR2 kernel: fs/cifs/file.c: CIFS VFS: leaving cifs_user_read (xid = 199733194) rc = 0 Feb 16 22:12:17 UFR2 kernel: fs/cifs/file.c: CIFS VFS: in cifs_user_read as Xid: 199733195 with uid: 501 Feb 16 22:12:17 UFR2 kernel: fs/cifs/cifssmb.c: Reading 8192 bytes on fid 16426 Feb 16 22:12:17 UFR2 kernel: fs/cifs/transport.c: For smb_command 46 Feb 16 22:12:17 UFR2 kernel: fs/cifs/transport.c: Sending smb: total_len 63 Feb 16 22:12:17 UFR2 kernel: fs/cifs/connect.c: rfc1002 length 0x203f) Feb 16 22:12:17 UFR2 kernel: fs/cifs/file.c: CIFS VFS: leaving cifs_user_read (xid = 199733195) rc = 0 Feb 16 22:12:17 UFR2 kernel: fs/cifs/file.c: CIFS VFS: in cifs_user_read as Xid: 199733196 with uid: 501 Feb 16 22:12:17 UFR2 kernel: fs/cifs/cifssmb.c: Reading 8192 bytes on fid 16426 Feb 16 22:12:17 UFR2 kernel: fs/cifs/transport.c: For smb_command 46 Feb 16 22:12:17 UFR2 kernel: fs/cifs/transport.c: Sending smb: total_len 63 Feb 16 22:12:17 UFR2 kernel: fs/cifs/connect.c: rfc1002 length 0x42b) Feb 16 22:12:17 UFR2 kernel: fs/cifs/cifssmb.c: Reading 7188 bytes on fid 16426 Feb 16 22:12:17 UFR2 kernel: fs/cifs/transport.c: For smb_command 46 Feb 16 22:12:17 UFR2 kernel: fs/cifs/transport.c: Sending smb: total_len 63 Feb 16 22:12:17 UFR2 kernel: fs/cifs/connect.c: rfc1002 length 0x3f) Feb 16 22:12:17 UFR2 kernel: fs/cifs/misc.c: Null buffer passed s/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 199733299 with uid: 501 Feb 16 22:12:17 UFR2 kernel: fs/cifs/inode.c: Revalidate: inode 0xf5ecad2c count 1 dentry: 0xf5ec1f50 d_time 0 jiffies 191744725 Feb 16 22:12:17 UFR2 kernel: fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 199733299) rc = 0 Feb 16 22:12:17 UFR2 kernel: fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 199733300 with uid: 501 Feb 16 22:12:17 UFR2 kernel: fs/cifs/inode.c: Revalidate: \nv9707 inode 0xee752060 count 1 dentry: 0xcb8f3604 d_time 191744714 jiffies 191744725 Feb 16 22:12:17 UFR2 kernel: fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 199733300) rc = 0 Feb 16 22:12:17 UFR2 kernel: fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 199733301 with uid: 501 Feb 16 22:12:17 UFR2 kernel: fs/cifs/inode.c: Revalidate: \nv9707 inode 0xee752060 count 1 dentry: 0xcb8f3604 d_time 191744714 jiffies 191744725 Let me know if you need more information -Original Message- From: Andrew Morton [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 10:55 AM To: Valentin Zaharov Cc: linux-kernel@vger.kernel.org; Steven French Subject: Re: cifs causes BUG: soft lockup detected on CPU On Wed, 28 Mar 2007 20:35:55 +0200 "Valentin Zaharov" <[EMAIL PROTECTED]> wrote: > Hi, > > We have continous problem with server freezes. We are using cifs > mounts on apache powered web servers with content located on Win2k3 server. > Servers freeze from time to time, producing following error just > before > freeze: > > Mar 26 21:50:37 UFR2 kernel: CIFS VFS: cifs_strtoUCS: char2uni > returned > -22 Mar 26 21:51:45 UFR2 last message repeated 55 times Mar 26 > 21:52:49 > UFR2 last message repeated 30 times Mar 26 21:54:16 UFR2 last message > repeated 10 times Mar 26 21:56:13 UFR2 last message repeated 20 times > Mar 26 21:58:34 UFR2 last message repeated 75 times Mar 26 21:59:43 > UFR2 last message repeated 30 times Mar 26 22:01:02 UFR2 last message
Re: cifs causes BUG: soft lockup detected on CPU
On Thu, 29 Mar 2007 11:13:04 +0200 "Valentin Zaharov" <[EMAIL PROTECTED]> wrote:
> I've tried different kernel versions.
> Right now iam using generic 2.6.9-42 on one machine and 2.6.20.1 on
> another one.
> I also tried various distributions ( Suse, CentOS, RHEL4 ) - not sure it
> is relevant.
> Tried installing latest cifs modules, tried changing CIFSMaxBufSize to
> 15000, without luck.
> Freezes are totally random - sometimes they happen 2-4 times a day,
> sometimes it can take 2 weeks.
Yeah, it's a relatively recently known-bug, I'm afraid.
Probably this will keep you out of trouble until it gets fixed
for real:
--- a/include/linux/fs.h~a
+++ a/include/linux/fs.h
@@ -627,25 +627,7 @@ extern void inode_double_unlock(struct i
*/
static inline loff_t i_size_read(const struct inode *inode)
{
-#if BITS_PER_LONG==32 && defined(CONFIG_SMP)
- loff_t i_size;
- unsigned int seq;
-
- do {
- seq = read_seqcount_begin(&inode->i_size_seqcount);
- i_size = inode->i_size;
- } while (read_seqcount_retry(&inode->i_size_seqcount, seq));
- return i_size;
-#elif BITS_PER_LONG==32 && defined(CONFIG_PREEMPT)
- loff_t i_size;
-
- preempt_disable();
- i_size = inode->i_size;
- preempt_enable();
- return i_size;
-#else
return inode->i_size;
-#endif
}
/*
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix dependency generation
Commit 2e3646e51b2d6415549b310655df63e7e0d7a080 changed the way
the split config tree is built, but failed to also adjust fixdep
accordingly - if changing a config option from or to m, files
referencing the respective CONFIG_..._MODULE (but not the
corresponding CONFIG_...) didn't get rebuilt.
Once at it, also eliminate false dependencies due to use of
...CONFIG_... identifiers.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5/scripts/basic/fixdep.c 2007-02-04 19:44:54.0
+0100
+++ 2.6.21-rc5-fixdep-mod/scripts/basic/fixdep.c2007-03-29
11:11:10.0 +0200
@@ -29,8 +29,7 @@
* option which is mentioned in any of the listed prequisites.
*
* To be exact, split-include populates a tree in include/config/,
- * e.g. include/config/his/driver.h, which contains the #define/#undef
- * for the CONFIG_HIS_DRIVER option.
+ * e.g. include/config/his/driver.h, consiting of empty files.
*
* So if the user changes his CONFIG_HIS_DRIVER option, only the objects
* which depend on "include/linux/config/his/driver.h" will be rebuilt,
@@ -223,7 +222,7 @@ void use_config(char *m, int slen)
void parse_config_file(char *map, size_t len)
{
int *end = (int *) (map + len);
- /* start at +1, so that p can never be < map */
+ /* start at +1, so that p can never be <= map */
int *m = (int *) map + 1;
char *p, *q;
@@ -235,6 +234,8 @@ void parse_config_file(char *map, size_t
continue;
conf:
if (p > map + len - 7)
+ break;
+ if (isalnum(p[-1]) || p[-1] == '_')
continue;
if (memcmp(p, "CONFIG_", 7))
continue;
@@ -245,6 +246,8 @@ void parse_config_file(char *map, size_t
continue;
found:
+ if (!memcmp(q - 7, "_MODULE", 7))
+ q -= 7;
use_config(p+7, q-p-7);
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Corrupt XFS -Filesystems on new Hardware and Kernel
> Oliver Joa wrote: > >>eason or another, xfs has detected a corrupted on-disk inode format > >>which it cannot recognize, and shuts down. > > Oh, one other thing that may not apply in your case, but may. > Does your SATA disk support write caching? Does it support > something called a barrier function? (not real clear on all > the ways this can go wrong, but I believe barriers are supposed > to guarantee previous data has been fixed on disk (not in write > cache). If the SATA controller issues a reset, it may very well > purge the write cache. Theoretically, I can think of a _possibility_, > that the reset disk would purge the write cache and the barrier > indicator would tell xfs to resume writing. From a recent thread > on the xfs list, it would appear this could be a "bad" thing (like > crossing the streams ala "ghostbusters", but in a data-integrity > context). As far as I can remember, barrier does not mean that data is fixed on disk. It is only a command that forces all the writes before the barrier to be performed before all the writes after the barrier. So this is more an ordering restriction than a data integrity thing... Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: cifs causes BUG: soft lockup detected on CPU
I get this error when try to apply the patch:
patch -p1 < cifs.patch
patching file include/linux/fs.h
patch: malformed patch at line 26: /*
Am I missing something or patch is bad?
Thanks in advance
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 29, 2007 11:22 AM
To: Valentin Zaharov
Cc: linux-kernel@vger.kernel.org; Steven French
Subject: Re: cifs causes BUG: soft lockup detected on CPU
On Thu, 29 Mar 2007 11:13:04 +0200 "Valentin Zaharov"
<[EMAIL PROTECTED]> wrote:
> I've tried different kernel versions.
> Right now iam using generic 2.6.9-42 on one machine and 2.6.20.1 on
> another one.
> I also tried various distributions ( Suse, CentOS, RHEL4 ) - not sure
> it is relevant.
> Tried installing latest cifs modules, tried changing CIFSMaxBufSize to
> 15000, without luck.
> Freezes are totally random - sometimes they happen 2-4 times a day,
> sometimes it can take 2 weeks.
Yeah, it's a relatively recently known-bug, I'm afraid.
Probably this will keep you out of trouble until it gets fixed for real:
--- a/include/linux/fs.h~a
+++ a/include/linux/fs.h
@@ -627,25 +627,7 @@ extern void inode_double_unlock(struct i
*/
static inline loff_t i_size_read(const struct inode *inode) { -#if
BITS_PER_LONG==32 && defined(CONFIG_SMP)
- loff_t i_size;
- unsigned int seq;
-
- do {
- seq = read_seqcount_begin(&inode->i_size_seqcount);
- i_size = inode->i_size;
- } while (read_seqcount_retry(&inode->i_size_seqcount, seq));
- return i_size;
-#elif BITS_PER_LONG==32 && defined(CONFIG_PREEMPT)
- loff_t i_size;
-
- preempt_disable();
- i_size = inode->i_size;
- preempt_enable();
- return i_size;
-#else
return inode->i_size;
-#endif
}
/*
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: tighten kernel image page access rights
On Thursday 29 March 2007 09:17, Jan Beulich wrote: > >>> Andi Kleen <[EMAIL PROTECTED]> 28.03.07 21:07 >>> > > > >> +#ifdef CONFIG_HOTPLUG_CPU > >> + /* It must still be possible to apply SMP alternatives. */ > >> + if (num_possible_cpus() <= 1) > > > >It would be better to temporarily change the pages where the alternatives > >are applied while that is done and keep it otherwise ro > > I had considered that, but not done so due to the larger resulting patch. > Are you okay with doing this as a follow-up step? Yes. I tried to apply the original patch, but gots lots of rejects. Can you please resubmit that one against the latest firstfloor tree? -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/
Student Project Ideas
Hi all, I've been hacking on the Linux kernel all semester for my OS: Internals class. We are given full autonomy in picking our final programming project and I would love for mine to be /useful/ for the Linux kernel and not just a theoretical exorcise. If anybody has any bug fixes or features maybe they never got around to, and would be suitable for this situation, I would love to hear about them. Thanks in advance, Russ Meyerriecks University of Alabama in Huntsville - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Student Project Ideas
Russ Meyerriecks wrote: Hi all, I've been hacking on the Linux kernel all semester for my OS: Internals class. We are given full autonomy in picking our final programming project and I would love for mine to be /useful/ for the Linux kernel and not just a theoretical exorcise. If anybody has any bug fixes or features maybe they never got around to, and would be suitable for this situation, I would love to hear about them. Take a look at: http://janitor.kernelnewbies.org/ Here you can find many things nobody got around to. Things like coding style and patch submission is also documented here. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Student Project Ideas
2007/3/29, Russ Meyerriecks <[EMAIL PROTECTED]>: Hi all, I've been hacking on the Linux kernel all semester for my OS: Internals class. We are given full autonomy in picking our final programming project and I would love for mine to be /useful/ for the Linux kernel and not just a theoretical exorcise. If anybody has any bug fixes or features maybe they never got around to, and would be suitable for this situation, I would love to hear about them. First, I think you can read the book named "Kernel Projects for Linux". It's a good book although it's outdated. Second, in fact, I am also a college student and also want to find a suitable and real task in linux kernel for me to work on. KJ doesn't help much. ;-p And I am wondering why linux kernel didn't attend Google Summer of Code? Andrew, I hear you are in Google now. Can you tell me the reason? Thanks very much! Have fun! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ignore vgacon if hardware not present
On Thu, Mar 29, 2007 at 05:46:48PM +1000, Rusty Russell wrote: > (Did this fall through the cracks? I don't see it in -mm. It's > standalone, and saves some silly code in lguest and presumably others). Normally it should go to some some console maintainer? Ok I can add it. -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 -mm] blackfin arch fix bug bf561 rev ID are 8-bit
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/kernel/setup.c|3 +++
include/asm-blackfin/mach-bf561/bf561.h |2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index b494f73..96ee2fa 100644
--- a/arch/blackfin/kernel/setup.c
+++ b/arch/blackfin/kernel/setup.c
@@ -117,6 +117,9 @@ static u_int get_dsp_rev_id(void)
{
u_int id;
id = bfin_read_DSPID() & 0x;
+#if defined(CONFIG_BF561)
+ id>>=8;
+#endif
return id;
}
diff --git a/include/asm-blackfin/mach-bf561/bf561.h
b/include/asm-blackfin/mach-bf561/bf561.h
index cd90a1c..ded1796 100644
--- a/include/asm-blackfin/mach-bf561/bf561.h
+++ b/include/asm-blackfin/mach-bf561/bf561.h
@@ -30,7 +30,7 @@
#ifndef __MACH_BF561_H__
#define __MACH_BF561_H__
-#define SUPPORTED_DSPID0x300
+#define SUPPORTED_DSPID0x3
#define OFFSET_(x) ((x) & 0x)
#define L1_ISRAM 0xFFA0
--
1.5.0.5
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64 irq: keep consistent for changing IRQ0_VECTOR from 0x20 to 0x30
> --- > From: Yinghai Lu <[EMAIL PROTECTED]> > Subject: x86_64 irq: Fix comments after changing IRQ0_VECTOR from 0x20 to 0x30 applied thanks -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] fix amd64-agp aperture validation
On Thursday 29 March 2007 09:58, Jan Beulich wrote: > Under CONFIG_DISCONTIGMEM, assuming that a !pfn_valid() implies all > subsequent pfn-s are also invalid is wrong. Thus replace this by > explicitly checking against the E820 map. Applied thanks. -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] blackfin arch fix stamp537 ISP1716 IRQ setting bug
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/mach-bf537/boards/stamp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
b/arch/blackfin/mach-bf537/boards/stamp.c
index 0f90ff9..a4219df 100644
--- a/arch/blackfin/mach-bf537/boards/stamp.c
+++ b/arch/blackfin/mach-bf537/boards/stamp.c
@@ -68,7 +68,7 @@ static struct resource bfin_isp1761_resources[] = {
[1] = {
.start = ISP1761_IRQ,
.end= ISP1761_IRQ,
- .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+ .flags = IORESOURCE_IRQ,
},
};
--
1.5.0.5
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] blackfin arch fix bug prevent warning in case BF531 is target
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/kernel/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index 96ee2fa..ce51882 100644
--- a/arch/blackfin/kernel/setup.c
+++ b/arch/blackfin/kernel/setup.c
@@ -571,7 +571,7 @@ static void __init generate_cpl_tables(void)
* rootfs size, there can be overlapping memory areas.
*/
- if (as_1m) {
+ if (as_1m && i!=L1I_MEM && i!=L1D_MEM) {
#ifdef CONFIG_MTD_UCLINUX
if (i == SDRAM_RAM_MTD) {
if ((cplb_data[SDRAM_KERN].end + 1) >
cplb_data[SDRAM_RAM_MTD].start)
--
1.5.0.5
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blackfin arch fix stamp537 ISP1716 IRQ setting bug
Sorry for word wrap. this one is ok.
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/mach-bf537/boards/stamp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
b/arch/blackfin/mach-bf537/boards/stamp.c
index 0f90ff9..a4219df 100644
--- a/arch/blackfin/mach-bf537/boards/stamp.c
+++ b/arch/blackfin/mach-bf537/boards/stamp.c
@@ -68,7 +68,7 @@ static struct resource bfin_isp1761_resources[] = {
[1] = {
.start = ISP1761_IRQ,
.end= ISP1761_IRQ,
- .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+ .flags = IORESOURCE_IRQ,
},
};
--
1.5.0.5
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] coredump: add an interface to control the core dump routine
Hi! > I have discussed with my colleagues why you say "ugly" against my > procfs interface, then I noticed I may have misunderstood what you said. > Is the reason for saying "ugly" two interfaces, i.e. preexisting ulimit > (get/setrlimit) and my proc entry, exist to control core file size? Yes. > > Plus, what you are doing can be done in userspace using google > > coredumper. > > I think that the needs differ between userland core dumper user and > in-kernel core dumper user. Pros and cons also differ. > > Some of people (such as system admins, distro vendors, etc) need > highly reliable core dumper because they don't want to experience > same failures again and they don't hope that another failure is > caused by core dumping. Userland core dumper is useful because > it is relatively easy to be customized, but its reliability highly > depends on the application programs. Fix userland core dumper to be reliable, then. > If the stack for signal handlers is not set up carefully, if the > data used by userland core dumper has been destroyed, if > coredump_omit_anon_shared flag has been overwritten by bad data, > or if the address of functions have been destroyed, the userland > core dumper may fail to dump. So in-kernel solutoin is required > by enterprise users. It should be possible to dump from separate process. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC: 2.6 patch] fix ISDN_CAPI<->ISDN_DIVAS
On Sat, 24 Mar 2007, Adrian Bunk wrote: > On Sat, Mar 24, 2007 at 02:49:42PM +0100, Armin Schindler wrote: > > On Sat, 24 Mar 2007, Adrian Bunk wrote: > > > Randy Dunlap reported in kernel Bugzilla #8241 the following compile > > > error with CONFIG_ISDN_CAPI=m, CONFIG_ISDN_DIVAS=y: > > > > > > <-- snip --> > > > > > > ... > > > WARNING: "DIVA_DIDD_Read" [drivers/isdn/hardware/eicon/divacapi.ko] > > > undefined! > > > WARNING: "DIVA_DIDD_Read" [drivers/isdn/hardware/eicon/diva_mnt.ko] > > > undefined! > > > WARNING: "DIVA_DIDD_Read" [drivers/isdn/hardware/eicon/diva_idi.ko] > > > undefined! > > > WARNING: "proc_net_eicon" [drivers/isdn/hardware/eicon/diva_idi.ko] > > > undefined! > > > make[1]: *** [__modpost] Error 1 > > > > > > <-- snip --> > > > > > > > > > Kconfig contains the following strange thing: > > > > > > menu "Active Eicon DIVA Server cards" > > > depends on NET && ISDN && ISDN_CAPI!=n > > > > > > > > > It seems that except for ISDN_DIVAS_DIVACAPI (that already has a proper > > > dependency), nothing here actually requires ISDN_CAPI? > > > > Not quite true. Yes, the base modules for the divas driver do not require > > ISDN_CAPI, but without ISDN_CAPI it doesn't make any sense. > > Let me try to understand this: > > Does it make sense to have CONFIG_ISDN_DIVAS=y, CONFIG_ISDN_CAPI=m? Yes, this is possible. DIVAS itself does not depend on CAPI. > And do CONFIG_ISDN_DIVAS=y/m, CONFIG_ISDN_DIVAS_DIVACAPI=n > configurations make sense? Yes, but for only for experts who want to use the DIVAS own API without CAPI. > If not, what about: > - let ISDN_DIVAS depend on ISDN_CAPI and > - enable ISDN_DIVAS_DIVACAPI unconditionally (and perhaps even build > it into the divas module)? That would not be correct. > > The patch below (go into /hardware even for non ISDN_CAPI) is wrong. The > > subdir /hardware was created for new drivers using CAPI. So it is correct to > > go there when ISDN_CAPI != n only. > > > > I don't understand the warnings above. The symbols are exported by divas > > modules, so why is it causing warnings? There have been no change in the > > divas modules for this. Any change in the kernel module creation structure > > which may causing this? > > These aren't warnings, these are errors. > > Due to > obj-$(CONFIG_ISDN_CAPI)+= hardware/ > > hardware/ isn't visited with CONFIG_ISDN_CAPI=m when building vmlinux. > > This means the modules were built, but the static code they were using > wasn't linkd into the kernel. > > This might not have occured before since CONFIG_ISDN_CAPI=m, > CONFIG_ISDN_DIVAS=y is an unusual configuration. I see. So for DIVAS the line obj-$(CONFIG_ISDN_CAPI)+= hardware/ causes the trouble, because all hardware/ driver are meant to be CAPI drivers... In that case we should change hardware/eicon/ as you proposed: > - let ISDN_DIVAS depend on ISDN_CAPI and So the solution might be just to change menu "Active Eicon DIVA Server cards" depends on NET && ISDN && ISDN_CAPI!=n to menu "Active Eicon DIVA Server cards" depends on NET && ISDN && ISDN_CAPI in drivers/isdn/hardware/eicon/Kconfig right? Armin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ignore vgacon if hardware not present
On Thu, 2007-03-29 at 12:36 +0200, Andi Kleen wrote:
> On Thu, Mar 29, 2007 at 05:46:48PM +1000, Rusty Russell wrote:
> > (Did this fall through the cracks? I don't see it in -mm. It's
> > standalone, and saves some silly code in lguest and presumably others).
>
> Normally it should go to some some console maintainer?
Hmm, but who?
> Ok I can add it.
Thanks. While you're in a patch-applying mood, how about this?
Cheers,
Rusty.
==
Use X86_EFLAGS_IF in irqflags.h.
Move X86_EFLAGS_IF et al out to a new header: processor-flags.h, so we
can include it from irqflags.h and use it in raw_irqs_disabled_flags().
As a side-effect, we could now use these flags in .S files.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
include/asm-i386/irqflags.h|3 ++-
include/asm-i386/processor-flags.h | 26 ++
include/asm-i386/processor.h | 22 +-
3 files changed, 29 insertions(+), 22 deletions(-)
===
--- /dev/null
+++ b/include/asm-i386/processor-flags.h
@@ -0,0 +1,26 @@
+#ifndef __ASM_I386_PROCESSOR_FLAGS_H
+#define __ASM_I386_PROCESSOR_FLAGS_H
+/* Various flags defined: can be included from assembler. */
+
+/*
+ * EFLAGS bits
+ */
+#define X86_EFLAGS_CF 0x0001 /* Carry Flag */
+#define X86_EFLAGS_PF 0x0004 /* Parity Flag */
+#define X86_EFLAGS_AF 0x0010 /* Auxillary carry Flag */
+#define X86_EFLAGS_ZF 0x0040 /* Zero Flag */
+#define X86_EFLAGS_SF 0x0080 /* Sign Flag */
+#define X86_EFLAGS_TF 0x0100 /* Trap Flag */
+#define X86_EFLAGS_IF 0x0200 /* Interrupt Flag */
+#define X86_EFLAGS_DF 0x0400 /* Direction Flag */
+#define X86_EFLAGS_OF 0x0800 /* Overflow Flag */
+#define X86_EFLAGS_IOPL0x3000 /* IOPL mask */
+#define X86_EFLAGS_NT 0x4000 /* Nested Task */
+#define X86_EFLAGS_RF 0x0001 /* Resume Flag */
+#define X86_EFLAGS_VM 0x0002 /* Virtual Mode */
+#define X86_EFLAGS_AC 0x0004 /* Alignment Check */
+#define X86_EFLAGS_VIF 0x0008 /* Virtual Interrupt Flag */
+#define X86_EFLAGS_VIP 0x0010 /* Virtual Interrupt Pending */
+#define X86_EFLAGS_ID 0x0020 /* CPUID detection flag */
+
+#endif /* __ASM_I386_PROCESSOR_FLAGS_H */
===
--- a/include/asm-i386/irqflags.h
+++ b/include/asm-i386/irqflags.h
@@ -9,6 +9,7 @@
*/
#ifndef _ASM_IRQFLAGS_H
#define _ASM_IRQFLAGS_H
+#include
#ifndef __ASSEMBLY__
static inline unsigned long native_save_fl(void)
@@ -119,7 +120,7 @@ static inline unsigned long __raw_local_
static inline int raw_irqs_disabled_flags(unsigned long flags)
{
- return !(flags & (1 << 9));
+ return !(flags & X86_EFLAGS_IF);
}
static inline int raw_irqs_disabled(void)
===
--- a/include/asm-i386/processor.h
+++ b/include/asm-i386/processor.h
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
/* flag for disabling the tsc */
extern int tsc_disable;
@@ -125,27 +126,6 @@ extern void detect_ht(struct cpuinfo_x86
#else
static inline void detect_ht(struct cpuinfo_x86 *c) {}
#endif
-
-/*
- * EFLAGS bits
- */
-#define X86_EFLAGS_CF 0x0001 /* Carry Flag */
-#define X86_EFLAGS_PF 0x0004 /* Parity Flag */
-#define X86_EFLAGS_AF 0x0010 /* Auxillary carry Flag */
-#define X86_EFLAGS_ZF 0x0040 /* Zero Flag */
-#define X86_EFLAGS_SF 0x0080 /* Sign Flag */
-#define X86_EFLAGS_TF 0x0100 /* Trap Flag */
-#define X86_EFLAGS_IF 0x0200 /* Interrupt Flag */
-#define X86_EFLAGS_DF 0x0400 /* Direction Flag */
-#define X86_EFLAGS_OF 0x0800 /* Overflow Flag */
-#define X86_EFLAGS_IOPL0x3000 /* IOPL mask */
-#define X86_EFLAGS_NT 0x4000 /* Nested Task */
-#define X86_EFLAGS_RF 0x0001 /* Resume Flag */
-#define X86_EFLAGS_VM 0x0002 /* Virtual Mode */
-#define X86_EFLAGS_AC 0x0004 /* Alignment Check */
-#define X86_EFLAGS_VIF 0x0008 /* Virtual Interrupt Flag */
-#define X86_EFLAGS_VIP 0x0010 /* Virtual Interrupt Pending */
-#define X86_EFLAGS_ID 0x0020 /* CPUID detection flag */
static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Corrupt XFS -Filesystems on new Hardware and Kernel
On Thu, Mar 29 2007, Jan Kara wrote: > > Oliver Joa wrote: > > >>eason or another, xfs has detected a corrupted on-disk inode format > > >>which it cannot recognize, and shuts down. > > > > Oh, one other thing that may not apply in your case, but may. > > Does your SATA disk support write caching? Does it support > > something called a barrier function? (not real clear on all > > the ways this can go wrong, but I believe barriers are supposed > > to guarantee previous data has been fixed on disk (not in write > > cache). If the SATA controller issues a reset, it may very well > > purge the write cache. Theoretically, I can think of a _possibility_, > > that the reset disk would purge the write cache and the barrier > > indicator would tell xfs to resume writing. From a recent thread > > on the xfs list, it would appear this could be a "bad" thing (like > > crossing the streams ala "ghostbusters", but in a data-integrity > > context). > As far as I can remember, barrier does not mean that data is fixed on > disk. It is only a command that forces all the writes before the barrier > to be performed before all the writes after the barrier. So this is more > an ordering restriction than a data integrity thing... A barrier write guarentees both data before barrier is on disk, as well as the barrier itself when completion is signalled. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[test] hackbench.c interactivity results: vanilla versus SD/RSDL
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > * Con Kolivas <[EMAIL PROTECTED]> wrote: > > > I'm cautiously optimistic that we're at the thin edge of the bugfix > > wedge now. [...] > and the numbers he posted: > > http://marc.info/?l=linux-kernel&m=117448900626028&w=2 > > his test conclusion was that under CPU load, RSDL (SD) generally does > not hold up to mainline's interactivity. Today i've done some hackbench.c (which is similar to VolanoMark) interactivity testing on SD-latest (v0.37), doing "hackbench 10", "hackbench 50" and "hackbench 100" runs, comparing it to vanilla+Mike's-task-promotion-patch. Performance --- performance was largely comparable, within noise: the vanilla scheduler was slightly (~5%) better at "hackbench 10", SD and vanilla was within noise on "hackbench 50" and "hackbench 100" runs. (I think vanilla's better results might be due to the longer timeslices vanilla can give out - SD has to operate via short timeslices, by design.) Shell interactivity --- The vanilla scheduler kept the shell completely usable during all tests: 'ls' output was instantaneous and characters could be typed without delay. The SD/RSDL scheduler kept the shell barely usable during the hackbench 10 test, and it was completely unusable during the hackbench 50 and 100 tests. A simple 'ls' took 2-3 seconds to complete (up to 6 seconds at times) and the shell printed characters in a very laggy way. 'vi' was totally unusable, etc. etc. [ i've also re-tested this with RSDL 0.34, and there interactivity got better although it still didnt match that of the vanilla scheduler's interactivity. So this is a definitive SD regression. ] [ A quick guess: could SD's substandard interactivity in this test be due to the SMP migration logic inconsistencies Mike noticed? This is an SMP system and the hackbench workload is very scheduling intense and tasks are frequently queued from one CPU to another. ] Conclusion -- i consider this a must-fix item as SD badly misbehaves under this workload. Test environment details the test system is a 2GHz Athlon64 dual-core box. All tests were running on default nice 0 levels. All tests were done 10 times on a totally idle test-system. Mike's patch is the one that improves vanilla scheduler's anti-starvation code: http://marc.info/?l=linux-kernel&m=117507110922009&w=2 ( Mike's patch does not make a measurable performance difference in hackbench, nor does it make a visible interactivity difference for this workload, but since i think Mike's patch improves the vanilla scheduler i included it in the test for completeness, so that both variants of interactivity code are at the 'bleeding edge'. ) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
Adrian Bunk wrote: On Wed, Mar 28, 2007 at 04:26:05AM +0100, Sid Boyce wrote: Eric W. Biederman wrote: Sid Boyce <[EMAIL PROTECTED]> writes: This is what I've got so far on the first boot, I shall have to check the manpage for git-bisect again to see if there is anything else to be added, nothing enlightening seen so far - further reboots to be done. I'm a little confused at what I am seeing below. Normally what happens is that after a kernel compile and test. You call "git-bisect bad" or "git-bisect good" and then git-bisect picks the next kernel to test. Then you compile and test that one. It looks like you called git-bisect bad several times in a row without testing Eric This is the procedure I followed. <-- snip --> # install git and cogito on your computer # clone Linus' tree: cg-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git # start bisecting: cd linux-2.6 git bisect start git bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b git bisect good ac98695d6c1508b724f246f38ce57fb4e3cec356 # start round cp /path/to/.config . make oldconfig make # install kernel, check whether it's good or bad, then: git bisect [bad|good] I built and installed the kernel downloaded using "cg-clone", booted it up and ran "git bisect bad". I'm also somewhat confused as the first failing kernel is 2.6.20-git11, the Makefile says the kernel got with cg-clone is actually 2.6.21-rc4 and it built as 2.6.20-g208367ee. Regards Sid. barrabas:/usr/src/GIT/linux-2.6 # git bisect bad Bisecting: 22 revisions left to test after this [3fc605a2aa38899c12180ca311f1eeb61a6d867e] knfsd: allow the server to provide a gid list when using AUTH_UNIX authentication rrabas:/usr/src/GIT/linux-2.6 # git bisect bad ... I think I got your problem: After rebooting, you do "git bisect [bad|good]" *once*. Then recompile the kernel from the current tree, reboot, and again *once* "git bisect [bad|good]". etc. cu Adrian If I boot up on 2.6.20-git10 and run "git bisect bad", "git bisect good v2.6.20-git10" or "git bisect bad v2.6.20-git11", it says it's not a git repo. I am still no clearer what's required. If I do "cg-clone" I get 2.6.21-rc5. The previous one got me 2.6.21-rc4. The manpages and the tutorials I've looked at are quite cryptic and the commands do not produce the expected results. As indicated above, I followed the instructions bullet by bullet without any clear understanding of the tools. 1) Ran the commands as above,cg-clone; git start; git bisect bad ;git bisect good I presume. 2) 2.6.20-git10 is the last good kernel. 3) 2.6.20-git11 and later are all bad. 4) I do cg-clone which gives a kernel whose Makefile is 2.6.21-rc4 (or whatever is current). 5) I get a kernel named 2.6.20-g208367e after make - rebooted and it fails the same way as 2.6.20-git11. 6) ran "git bisect bad". Looking through the directories after cg-clone barrabas:/ftp/mar07/GIT/linux-2.6 # ls .git/refs/tags/ v2.6.11 v2.6.12-rc5 v2.6.13-rc4 v2.6.14-rc2 v2.6.15-rc2 v2.6.16 v2.6.16-rc6 v2.6.17-rc5 v2.6.18-rc4 v2.6.19-rc2 v2.6.20-rc1 v2.6.20-rc7 v2.6.11-tree v2.6.12-rc6 v2.6.13-rc5 v2.6.14-rc3 v2.6.15-rc3 v2.6.16-rc1 v2.6.17 v2.6.17-rc6 v2.6.18-rc5 v2.6.19-rc3 v2.6.20-rc2 v2.6.21-rc1 v2.6.12 v2.6.13 v2.6.13-rc6 v2.6.14-rc4 v2.6.15-rc4 v2.6.16-rc2 v2.6.17-rc1 v2.6.18 v2.6.18-rc6 v2.6.19-rc4 v2.6.20-rc3 v2.6.21-rc2 v2.6.12-rc2 v2.6.13-rc1 v2.6.13-rc7 v2.6.14-rc5 v2.6.15-rc5 v2.6.16-rc3 v2.6.17-rc2 v2.6.18-rc1 v2.6.18-rc7 v2.6.19-rc5 v2.6.20-rc4 v2.6.21-rc3 v2.6.12-rc3 v2.6.13-rc2 v2.6.14 v2.6.15 v2.6.15-rc6 v2.6.16-rc4 v2.6.17-rc3 v2.6.18-rc2 v2.6.19 v2.6.19-rc6 v2.6.20-rc5 v2.6.21-rc4 v2.6.12-rc4 v2.6.13-rc3 v2.6.14-rc1 v2.6.15-rc1 v2.6.15-rc7 v2.6.16-rc5 v2.6.17-rc4 v2.6.18-rc3 v2.6.19-rc1 v2.6.20 v2.6.20-rc6 v2.6.21-rc5 barrabas:/ftp/mar07/GIT/linux-2.6 # ls .git/refs/bisect/ bad good-ac98695d6c1508b724f246f38ce57fb4e3cec356 barrabas:/ftp/mar07/GIT/linux-2.6 # ls .git/refs/heads/ bisect master origin barrabas:/ftp/mar07/GIT/linux-2.6 # less .git/refs/heads/bisect 208367eeec8d6f6fcee1a0672af2149aeee7b658 barrabas:/ftp/mar07/GIT/linux-2.6 # ls .git/branches/ barrabas:/ftp/mar07/GIT/linux-2.6 # ls arch COPYING crypto drivers .gitinclude ipc kernel .mailmap Makefile net REPORTING-BUGS security usr block CREDITS Documentation fs .gitignore init Kbuild lib MAINTAINERS mmREADME scripts sound # less BISECT_LOG git-bisect start # bad: [86a71dbd3e81e8870d0f0e56b87875f57e58222b] sysctl: hide the sysctl proc inodes from selinux git-bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b # good: [ac98695d6c1508b724f246f38ce57fb4e3cec356] Merge branch 'master' of /home/trondmy/kernel/linu
Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
Eric W. Biederman wrote:
Sid I think I have found the problem. Could you try the following patch.
I believe I accidentally switched the sense of a test
diff --git a/kernel/exit.c b/kernel/exit.c
index f132349..b55ed4c 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -790,7 +790,7 @@ static void exit_notify(struct task_struct *tsk)
pgrp = task_pgrp(tsk);
if ((task_pgrp(t) != pgrp) &&
- (task_session(t) != task_session(tsk)) &&
+ (task_session(t) == task_session(tsk)) &&
will_become_orphaned_pgrp(pgrp, tsk) &&
has_stopped_jobs(pgrp)) {
__kill_pgrp_info(SIGHUP, SEND_SIG_PRIV, pgrp);
AOK I shall apply to 2.6.21-rc5-git4 and test.
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist,
Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for deferrable timers (respun-Mar28)
> ondemand is the biggest offender and the patch below reduces the number of > interrupts by 50% or more (depending on HZ) on different test systems here. Cool! > Yes. There are quite a few other timers inside kernel that can be > migrated. I will use timer_stats and track others and send in the patches > soon. Longer term it might make sense to even expose this as a option to user space. Maybe as a new timer in setitimer()? This might safe power with "wiggling desktop applets" too. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for deferrable timers (respun-Mar28)
On Mar 29, 2007, at 07:41:12, Andi Kleen wrote: ondemand is the biggest offender and the patch below reduces the number of interrupts by 50% or more (depending on HZ) on different test systems here. Cool! Yes. There are quite a few other timers inside kernel that can be migrated. I will use timer_stats and track others and send in the patches soon. Longer term it might make sense to even expose this as a option to user space. Maybe as a new timer in setitimer()? This might safe power with "wiggling desktop applets" too. Might also be useful to add an extra option to "top" to reduce the polling frequency if the system is otherwise idle. A fixed 30-sec timer and a deferrable 1-sec timer or somesuch? Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for deferrable timers (respun-Mar28)
> Might also be useful to add an extra option to "top" to reduce the > polling frequency if the system is otherwise idle. A fixed 30-sec > timer and a deferrable 1-sec timer or somesuch? Hmm, i think the current implementation is per CPU. top really would like to have one that applies to all CPUs though. Thinking about it for sane user space semantics it would probably need a global implementation anyways. Perhaps it could use the same infrastructure as RCU does to handle this? -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.21-rc5] nicksched v33
This contains fixes for a bug that could cause too much latency with non-zero
niced processes, as well as fixes so that it SMP balancing actually works now
(the v32 forward port on top of smpnice was buggy).
X should be reniced to -10 for best results.
/proc/sys/kernel/base_timeslice can be reduced if the default (large) timeslice
is causing interactivity problems.
--
SUSE Labs, Novell Inc.
Index: linux-2.6/fs/proc/array.c
===
--- linux-2.6.orig/fs/proc/array.c 2007-03-29 19:45:08.0 +1000
+++ linux-2.6/fs/proc/array.c 2007-03-29 19:46:08.0 +1000
@@ -165,7 +165,13 @@ static inline char * task_state(struct t
rcu_read_lock();
buffer += sprintf(buffer,
"State:\t%s\n"
- "SleepAVG:\t%lu%%\n"
+ "timeslice:\t%d\n"
+ "usedslice:\t%d\n"
+ "arrayseq:\t%lu\n"
+ "staticprio:\t%u\n"
+ "prio:\t%u\n"
+ "sleep_time:\t%lu\n"
+ "total_time:\t%lu\n"
"Tgid:\t%d\n"
"Pid:\t%d\n"
"PPid:\t%d\n"
@@ -173,7 +179,9 @@ static inline char * task_state(struct t
"Uid:\t%d\t%d\t%d\t%d\n"
"Gid:\t%d\t%d\t%d\t%d\n",
get_task_state(p),
- (p->sleep_avg/1024)*100/(102000/1024),
+ get_task_timeslice(p), p->used_slice, p->array_sequence,
+ p->static_prio, p->prio,
+ p->sleep_time, p->total_time,
p->tgid, p->pid,
pid_alive(p) ? rcu_dereference(p->real_parent)->tgid : 0,
pid_alive(p) && p->ptrace ? rcu_dereference(p->parent)->pid : 0,
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h2007-03-29 19:45:08.0
+1000
+++ linux-2.6/include/linux/sched.h 2007-03-29 19:52:33.0 +1000
@@ -523,7 +523,7 @@ struct signal_struct {
#define MAX_USER_RT_PRIO 100
#define MAX_RT_PRIOMAX_USER_RT_PRIO
-#define MAX_PRIO (MAX_RT_PRIO + 40)
+#define MAX_PRIO (MAX_RT_PRIO + 59)
#define rt_prio(prio) unlikely((prio) < MAX_RT_PRIO)
#define rt_task(p) rt_prio((p)->prio)
@@ -788,24 +788,16 @@ struct mempolicy;
struct pipe_inode_info;
struct uts_namespace;
-enum sleep_type {
- SLEEP_NORMAL,
- SLEEP_NONINTERACTIVE,
- SLEEP_INTERACTIVE,
- SLEEP_INTERRUPTED,
-};
-
struct prio_array;
struct task_struct {
volatile long state;/* -1 unrunnable, 0 runnable, >0 stopped */
struct thread_info *thread_info;
atomic_t usage;
+ int lock_depth; /* BKL lock depth */
unsigned long flags;/* per process flags, defined below */
unsigned long ptrace;
- int lock_depth; /* BKL lock depth */
-
#ifdef CONFIG_SMP
#ifdef __ARCH_WANT_UNLOCKED_CTXSW
int oncpu;
@@ -813,27 +805,29 @@ struct task_struct {
#endif
int load_weight;/* for niceness load balancing purposes */
int prio, static_prio, normal_prio;
+ int used_slice, over_slice;
struct list_head run_list;
struct prio_array *array;
+ unsigned long array_sequence;
- unsigned short ioprio;
-#ifdef CONFIG_BLK_DEV_IO_TRACE
- unsigned int btrace_seq;
-#endif
- unsigned long sleep_avg;
unsigned long long timestamp, last_ran;
unsigned long long sched_time; /* sched_clock time spent running */
- enum sleep_type sleep_type;
+ unsigned long total_time, sleep_time;
+
+ struct list_head tasks;
+ struct mm_struct *mm, *active_mm;
unsigned long policy;
cpumask_t cpus_allowed;
- unsigned int time_slice, first_time_slice;
#if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
struct sched_info sched_info;
#endif
- struct list_head tasks;
+ unsigned short ioprio;
+#ifdef CONFIG_BLK_DEV_IO_TRACE
+ unsigned int btrace_seq;
+#endif
/*
* ptrace_list/ptrace_children forms the list of my children
* that were stolen by a ptracer.
@@ -841,8 +835,6 @@ struct task_struct {
struct list_head ptrace_children;
struct list_head ptrace_list;
- struct mm_struct *mm, *active_mm;
-
/* task state */
struct linux_binfmt *binfmt;
long exit_state;
@@ -1199,6 +1191,8 @@ extern unsigned long long sched_clock(vo
extern unsigned long long
current_sched_time(const struct task_struct *current_task);
+extern int get_task_timeslice(struct task_struct *t);
+
/* sched_exec is called by processes performing an exec */
#ifdef CONFIG_SMP
extern void sched_exec(void);
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c 2007-03-29
[PATCH] x86: tighten kernel image page access rights (re-diff against firstfloor tree)
On x86-64, kernel memory freed after init can be entirely unmapped instead
of just getting 'poisoned' by overwriting with a debug pattern.
On i386 and x86-64 (under CONFIG_DEBUG_RODATA), kernel text and bug table
can also be write-protected.
(Not sure what the symbol 'stext' is good for; can it be removed?)
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5-ff/arch/i386/kernel/vmlinux.lds.S 2007-03-29
13:35:48.0 +0200
+++ 2.6.21-rc5-ff-x86-init-page-attribs/arch/i386/kernel/vmlinux.lds.S
2007-03-21 12:29:00.0 +0100
@@ -61,8 +61,6 @@ SECTIONS
__stop___ex_table = .;
}
- RODATA
-
BUG_TABLE
. = ALIGN(4);
@@ -72,6 +70,8 @@ SECTIONS
__tracedata_end = .;
}
+ RODATA
+
/* writeable */
. = ALIGN(4096);
.data : AT(ADDR(.data) - LOAD_OFFSET) { /* Data */
--- linux-2.6.21-rc5-ff/arch/i386/mm/init.c 2007-03-29 13:37:04.0
+0200
+++ 2.6.21-rc5-ff-x86-init-page-attribs/arch/i386/mm/init.c 2007-03-21
12:29:00.0 +0100
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -751,13 +752,25 @@ static int noinline do_test_wp_bit(void)
void mark_rodata_ro(void)
{
- unsigned long addr = (unsigned long)__start_rodata;
+ unsigned long start = PFN_ALIGN(_text);
+ unsigned long size = PFN_ALIGN(_etext) - start;
- for (; addr < (unsigned long)__end_rodata; addr += PAGE_SIZE)
- change_page_attr(virt_to_page(addr), 1, PAGE_KERNEL_RO);
-
- printk("Write protecting the kernel read-only data: %uk\n",
- (__end_rodata - __start_rodata) >> 10);
+#ifdef CONFIG_HOTPLUG_CPU
+ /* It must still be possible to apply SMP alternatives. */
+ if (num_possible_cpus() <= 1)
+#endif
+ {
+ change_page_attr(virt_to_page(start),
+size >> PAGE_SHIFT, PAGE_KERNEL_RX);
+ printk("Write protecting the kernel text: %luk\n", size >> 10);
+ }
+
+ start += size;
+ size = (unsigned long)__end_rodata - start;
+ change_page_attr(virt_to_page(start),
+size >> PAGE_SHIFT, PAGE_KERNEL_RO);
+ printk("Write protecting the kernel read-only data: %luk\n",
+ size >> 10);
/*
* change_page_attr() requires a global_flush_tlb() call after it.
@@ -781,7 +794,7 @@ void free_init_pages(char *what, unsigne
__free_page(page);
totalram_pages++;
}
- printk(KERN_INFO "Freeing %s: %ldk freed\n", what, (end - begin) >> 10);
+ printk(KERN_INFO "Freeing %s: %luk freed\n", what, (end - begin) >> 10);
}
void free_initmem(void)
--- linux-2.6.21-rc5-ff/arch/x86_64/kernel/head.S 2007-03-29
13:37:04.0 +0200
+++ 2.6.21-rc5-ff-x86-init-page-attribs/arch/x86_64/kernel/head.S
2007-03-21 12:29:00.0 +0100
@@ -280,7 +280,6 @@ early_idt_ripmsg:
.balign PAGE_SIZE
ENTRY(stext)
-ENTRY(_stext)
#define NEXT_PAGE(name) \
.balign PAGE_SIZE; \
--- linux-2.6.21-rc5-ff/arch/x86_64/kernel/vmlinux.lds.S2007-03-29
13:37:03.0 +0200
+++ 2.6.21-rc5-ff-x86-init-page-attribs/arch/x86_64/kernel/vmlinux.lds.S
2007-03-21 12:29:00.0 +0100
@@ -29,6 +29,7 @@ SECTIONS
.text : AT(ADDR(.text) - LOAD_OFFSET) {
/* First the code that has to be first for bootstrapping */
*(.bootstrap.text)
+ _stext = .;
/* Then all the functions that are "hot" in profiles, to group them
onto the same hugetlb entry */
#include "functionlist"
@@ -50,10 +51,10 @@ SECTIONS
__ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) { *(__ex_table) }
__stop___ex_table = .;
- RODATA
-
BUG_TABLE
+ RODATA
+
. = ALIGN(PAGE_SIZE);/* Align data segment to page size boundary */
/* Data */
.data : AT(ADDR(.data) - LOAD_OFFSET) {
--- linux-2.6.21-rc5-ff/arch/x86_64/mm/init.c 2007-03-29 13:37:04.0
+0200
+++ 2.6.21-rc5-ff-x86-init-page-attribs/arch/x86_64/mm/init.c 2007-03-29
13:48:18.0 +0200
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -569,21 +570,23 @@ void free_init_pages(char *what, unsigne
if (begin >= end)
return;
- printk(KERN_INFO "Freeing %s: %ldk freed\n", what, (end - begin) >> 10);
+ printk(KERN_INFO "Freeing %s: %luk freed\n", what, (end - begin) >> 10);
for (addr = begin; addr < end; addr += PAGE_SIZE) {
struct page *page = pfn_to_page(addr >> PAGE_SHIFT);
ClearPageReserved(page);
init_page_count(page);
memset(page_address(page), POISON_FREE_INITMEM, PAGE_SIZE);
+ if (addr >= __START_KERNEL_map)
+ change_page_attr_addr(addr, 1, __pgprot(0));
__free_page(page);
totalram_pages++;
Re: [v4l-dvb-maintainer] [2.6 patch] drivers/media/video/bt8xx/bttv-cards.c: fix off-by-one
Hi Adrian,
Em Seg, 2007-03-26 às 06:08 +0200, Adrian Bunk escreveu:
> This patch fixes an off-by-one error spotted by the Coverity checker.
Thanks for pointing us about this. Instead of your patch, however, it is
better to replace all magic numbers at for on all gpiomask stuff. This
will avoid future troubles if this array have any changes on its size.
I'm enclosing a patch doing this fix.
Cheers,
Mauro
Changeset: 5476
From: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Commiter: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Date: Wed Mar 28 22:37:20 2007 -0300
Subject: Fix gpiomux array size
there were several "magic" for loops, addressing gpiomux array size (4).
Adrian Bunk showed that one of the loops were wrong, going from 0 to 4.
This patch provides the right fix for this trouble, by using ARRAY_SIZE
on all places where we have a for loop using gpiomux.
Thanks to Adrian Bunk <[EMAIL PROTECTED]> for pointing me about this trouble.
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
---
diff -upNr oldtree/drivers/media/video/bt8xx/bttv-cards.c linux/drivers/media/video/bt8xx/bttv-cards.c
--- oldtree/drivers/media/video/bt8xx/bttv-cards.c 2007-03-29 09:00:15.0 -0300
+++ linux/drivers/media/video/bt8xx/bttv-cards.c 2007-03-29 09:00:12.0 -0300
@@ -2970,20 +2970,20 @@ void __devinit bttv_idcard(struct bttv *
if (UNSET != audiomux[0]) {
gpiobits = 0;
- for (i = 0; i < 4; i++) {
+ for (i = 0; i < ARRAY_SIZE(bttv_tvcards->gpiomux); i++) {
bttv_tvcards[btv->c.type].gpiomux[i] = audiomux[i];
gpiobits |= audiomux[i];
}
} else {
gpiobits = audioall;
- for (i = 0; i < 4; i++) {
+ for (i = 0; i < ARRAY_SIZE(bttv_tvcards->gpiomux); i++) {
bttv_tvcards[btv->c.type].gpiomux[i] = audioall;
}
}
bttv_tvcards[btv->c.type].gpiomask = (UNSET != gpiomask) ? gpiomask : gpiobits;
printk(KERN_INFO "bttv%d: gpio config override: mask=0x%x, mux=",
btv->c.nr,bttv_tvcards[btv->c.type].gpiomask);
- for (i = 0; i < 5; i++) {
+ for (i = 0; i < ARRAY_SIZE(bttv_tvcards->gpiomux); i++) {
printk("%s0x%x", i ? "," : "", bttv_tvcards[btv->c.type].gpiomux[i]);
}
printk("\n");
Re: [PATCH] ignore vgacon if hardware not present
On Thu, Mar 29, 2007 at 09:06:57PM +1000, Rusty Russell wrote: > On Thu, 2007-03-29 at 12:36 +0200, Andi Kleen wrote: > > On Thu, Mar 29, 2007 at 05:46:48PM +1000, Rusty Russell wrote: > > > (Did this fall through the cracks? I don't see it in -mm. It's > > > standalone, and saves some silly code in lguest and presumably others). > > > > Normally it should go to some some console maintainer? > > Hmm, but who? > > > Ok I can add it. > > Thanks. While you're in a patch-applying mood, how about this? Ok. Can you do it for x86-64 too? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux page cache issue?
Hello, > Now I want to explain the problem that leads me to explore the Linux > disk cache management. This is actually from my project. In a file > system I am working on, two files may have different inodes, but share > the same data blocks. Of course additional block-level reference > counting and copy-on-write mechanisms are needed to prevent operations > on one file from disrupting the other file. But the point is, the two > files share the same data blocks. > > I hope that consequential reads to the two files can benefit from disk > cache, since they have the same data blocks. But I noticed that Linux > splits disk buffer cache into many small parts and associate a file's > data with its mapping object. Linux determines whether a data page is > cached or not by lookup the file's mapping radix tree. So this is a > per-file radix tree. This design obviously makes each tree smaller and > faster to look up. But this design eliminates the possibility of > sharing disk cache across two files. For example, if a process reads > file 2 right after file 1 (both file 1 and 2 share the same data block > set). Even if the data blocks are already loaded in memory, but they > can only be located via file 1's mapping object. When Linux reads file > 2, it still think the data is not present in memory. So the process > still needs to load the data from disk again. Actually, there is one inode - the device inode - whose mapping can contain all the blocks of the filesystem. That is basically the radix tree you are looking for. ext3 for example uses it for accessing its metadata (indirect blocks etc.). But you have to be really careful to avoid aliasing issues and such when you'd like to map copies of those pages into mappings of several different inodes (BTW ext3cow filesystem may be interesting for you www.ext3cow.com). Honza > On 3/28/07, Dave Kleikamp <[EMAIL PROTECTED]> wrote: > >On Wed, 2007-03-28 at 02:45 -0400, Xin Zhao wrote: > >> Hi, > >> > >> If a Linux process opens and reads a file A, then it closes the file. > >> Will Linux keep the file A's data in cache for a while in case another > >> process opens and reads the same in a short time? I think that is what > >> I heard before. > > > >Yes. > > > >> But after I digged into the kernel code, I am confused. > >> > >> When a process closes the file A, iput() will be called, which in turn > >> calls the follows two functions: > >> iput_final()->generic_drop_inode() > > > >A comment from the top of fs/dcache.c: > > > >/* > > * Notes on the allocation strategy: > > * > > * The dcache is a master of the icache - whenever a dcache entry > > * exists, the inode will always exist. "iput()" is done either when > > * the dcache entry is deleted or garbage collected. > > */ > > > >Basically, as long a a dentry is present, iput_final won't be called on > >the inode. > > > >> But from the following calling chain, we can see that file close will > >> eventually lead to evict and free all cached pages. Actually in > >> truncate_complete_page(), the pages will be freed. This seems to > >> imply that Linux has to re-read the same data from disk even if > >> another process B read the same file right after process A closes the > >> file. That does not make sense to me. > >> > >> /***calling chain ***/ > >> generic_delete_inode/generic_forget_inode()-> > >> truncate_inode_pages()->truncate_inode_pages_range()-> > >> truncate_complete_page()->remove_from_page_cache()-> > >> __remove_from_page_cache()->radix_tree_delete() > >> > >> Am I missing something? Can someone please provide some advise? > >> > >> Thanks a lot > >> -x > > > >Shaggy > >-- > >David Kleikamp > >IBM Linux Technology Center > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Interface for the new fallocate() system call
Hello, We need to come up with the best possible layout of arguments for the fallocate() system call. Various architectures have different requirements for how the arguments should look like. Since the mail chain has become huge, here is the summary of various inputs received so far. Platform: s390 -- s390 prefers following layout: int fallocate(int fd, loff_t offset, loff_t len, int mode) For details on why and how "int, int, loff_t, loff_t" is a problem on s390, please see Heiko's mail on 16th March. Here is the link: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg133595.html Platform: ppc, arm -- ppc (32 bit) has a problem with "int, loff_t, loff_t, int" layout, since this will result in a pad between fd and offset, making seven arguments total - which is not supported by ppc32. It supports only 6 arguments. Thus the desired layout by ppc32 is: int fallocate(int fd, int mode, loff_t offset, loff_t len) Even ARM prefers above kind of layout. For details please see the definition of sys_arm_sync_file_range(). Option of loff_t => high u32 + low u32 -- Matthew and Russell have suggested another option of breaking each "loff_t" into two "u32"s. This will result in 6 arguments in total. Following think that this is a good alternative: Matthew Wilcox, Russell King, Heiko Carstens Following do not like this idea: Chris Wedgwood What are your thoughts on this ? What layout should we finalize on ? Perhaps, since sync_file_range() system call has similar arguments, we can take hint from the challenges faced on implementing it on various architectures, and decide. Please suggest. Thanks! -- Regards, Amit Arora - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Software RAID (non-preempt) server blocking question. (2.6.20.4)
On Thu, 29 Mar 2007, Neil Brown wrote: On Tuesday March 27, [EMAIL PROTECTED] wrote: I ran a check on my SW RAID devices this morning. However, when I did so, I had a few lftp sessions open pulling files. After I executed the check, the lftp processes entered 'D' state and I could do 'nothing' in the process until the check finished. Is this normal? Should a check block all I/O to the device and put the processes writing to a particular device in 'D' state until it is finished? No, that shouldn't happen. The 'check' should notice any other disk activity and slow down if anything else is happening on the device. Did the check run to completion? And if so, did the 'lftp' start working normally again? Yes it did and the lftp did start working normally again. Did you look at "cat /proc/mdstat" ?? What sort of speed was the check running at? Around 44MB/s. I do use the following optimization, perhaps a bad idea if I want other processes to 'stay alive'? echo "Setting minimum resync speed to 200MB/s..." echo "This improves the resync speed from 2.1MB/s to 44MB/s" echo 20 > /sys/block/md0/md/sync_speed_min echo 20 > /sys/block/md1/md/sync_speed_min echo 20 > /sys/block/md2/md/sync_speed_min echo 20 > /sys/block/md3/md/sync_speed_min echo 20 > /sys/block/md4/md/sync_speed_min NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Software RAID (non-preempt) server blocking question. (2.6.20.4)
On Thu, 29 Mar 2007, Henrique de Moraes Holschuh wrote: On Thu, 29 Mar 2007, Justin Piszcz wrote: Did you look at "cat /proc/mdstat" ?? What sort of speed was the check running at? Around 44MB/s. I do use the following optimization, perhaps a bad idea if I want other processes to 'stay alive'? echo "Setting minimum resync speed to 200MB/s..." echo "This improves the resync speed from 2.1MB/s to 44MB/s" echo 20 > /sys/block/md0/md/sync_speed_min echo 20 > /sys/block/md1/md/sync_speed_min echo 20 > /sys/block/md2/md/sync_speed_min echo 20 > /sys/block/md3/md/sync_speed_min echo 20 > /sys/block/md4/md/sync_speed_min md RAID1 resync reacts *extremely* badly to CFQ. Just a data point, you may want to check on it. Might mean other RAID types also get screwed, and also that md "check" is also disturbed by CFQ (or disturbs CFQ, whatever). I reverted everything here to non-CFQ while the RAID did its resync (which fixed all issues immediately), and we went back to 2.6.16.x later for other reasons. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh I am using the AS scheduler; not CFQ. $ find /sys 2>/dev/null|grep -i scheduler|xargs -n1 cat noop [anticipatory] noop [anticipatory] noop [anticipatory] noop [anticipatory] noop [anticipatory] noop [anticipatory] noop [anticipatory] noop [anticipatory] noop [anticipatory] noop [anticipatory] noop [anticipatory] noop [anticipatory] Justin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Software RAID (non-preempt) server blocking question. (2.6.20.4)
On Thu, 29 Mar 2007, Justin Piszcz wrote: > >Did you look at "cat /proc/mdstat" ?? What sort of speed was the check > >running at? > Around 44MB/s. > > I do use the following optimization, perhaps a bad idea if I want other > processes to 'stay alive'? > > echo "Setting minimum resync speed to 200MB/s..." > echo "This improves the resync speed from 2.1MB/s to 44MB/s" > echo 20 > /sys/block/md0/md/sync_speed_min > echo 20 > /sys/block/md1/md/sync_speed_min > echo 20 > /sys/block/md2/md/sync_speed_min > echo 20 > /sys/block/md3/md/sync_speed_min > echo 20 > /sys/block/md4/md/sync_speed_min md RAID1 resync reacts *extremely* badly to CFQ. Just a data point, you may want to check on it. Might mean other RAID types also get screwed, and also that md "check" is also disturbed by CFQ (or disturbs CFQ, whatever). I reverted everything here to non-CFQ while the RAID did its resync (which fixed all issues immediately), and we went back to 2.6.16.x later for other reasons. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: tighten kernel image page access rights (re-diff against firstfloor tree)
On Thursday 29 March 2007 14:01, Jan Beulich wrote: > On x86-64, kernel memory freed after init can be entirely unmapped instead > of just getting 'poisoned' by overwriting with a debug pattern. > > On i386 and x86-64 (under CONFIG_DEBUG_RODATA), kernel text and bug table > can also be write-protected. > > (Not sure what the symbol 'stext' is good for; can it be removed?) I see you remove it already Added thanks -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/
2.6.21-rc5-rt4 inconsistent lock state
Hi,
artsd during kde start triggered this
=
[ INFO: inconsistent lock state ]
[ 2.6.21-rc5-rt4 #4
-
inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
artsd/3454 [HC1[1]:SC0[0]:HE0:SE1] takes:
((raw_spinlock_t *)(&lock->wait_lock)){+-..}, at: []
rt_spin_lock_slowlock+0x29/0x1b4
{hardirq-on-W} state was registered at:
[] mark_lock+0x73/0x4a9
[] mark_held_locks+0x52/0x6f
[] trace_hardirqs_on+0x116/0x162
[] __spin_unlock_irqrestore+0x54/0x70
[] task_blocks_on_rt_mutex+0x1d6/0x226
[] rt_spin_lock_slowlock+0xcf/0x1b4
[] rt_spin_lock+0x13/0x4b
[] wait_for_completion+0x2e/0xab
[] set_cpus_allowed+0x88/0xab
[] measure_one+0xab/0x184
[] build_sched_domains+0x5b1/0xc19
[] arch_init_sched_domains+0x25/0x27
[] sched_init_smp+0x1c/0x6a
[] init+0x121/0x361
[] kernel_thread_helper+0x7/0x10
[] 0x
irq event stamp: 116668
hardirqs last enabled at (116667): []
__spin_unlock_irqrestore+0x54/0x70
hardirqs last disabled at (116668): [] apic_timer_interrupt+0x29/0x38
softirqs last enabled at (0): [] copy_process+0x542/0x1440
softirqs last disabled at (0): [<>] 0x0
l *0xc0358d1f
0xc0358d1f is in rt_spin_lock_slowlock (kernel/rtmutex.c:640).
635 unsigned long saved_state, state, flags;
636
637 debug_rt_mutex_init_waiter(&waiter);
638 waiter.task = NULL;
639
640 spin_lock_irqsave(&lock->wait_lock, flags);
641 init_lists(lock);
642
643 /* Try to acquire the lock again: */
644 if (try_to_take_rt_mutex(lock)) {
l *0xc035a616
0xc035a616 is in __spin_unlock_irqrestore (include/asm/irqflags.h:33).
28 return flags;
29 }
30
31 static inline void raw_local_irq_restore(unsigned long flags)
32 {
33 __asm__ __volatile__(
34 "pushl %0 ; popfl"
35 : /* no output */
36 :"g" (flags)
37 :"memory", "cc"
l *0xc0104de9
0xc0104de9 is at include/asm/bitops.h:246.
241 static int test_bit(int nr, const volatile void * addr);
242 #endif
243
244 static __always_inline int constant_test_bit(int nr, const volatile
unsigned long *addr)
245 {
246 return ((1UL << (nr & 31)) & (addr[nr >> 5])) != 0;
247 }
248
249 static inline int variable_test_bit(int nr, const volatile unsigned
long * addr)
250 {
l *0xc0123b51
0xc0123b51 is in copy_process (kernel/fork.c:1129).
1124p->hardirq_enable_ip = 0;
1125p->hardirq_enable_event = 0;
1126p->hardirq_disable_ip = _THIS_IP_;
1127p->hardirq_disable_event = 0;
1128p->softirqs_enabled = 1;
1129p->softirq_enable_ip = _THIS_IP_;
1130p->softirq_enable_event = 0;
1131p->softirq_disable_ip = 0;
1132p->softirq_disable_event = 0;
1133p->hardirq_context = 0;
other info that might help us debug this:
1 lock held by artsd/3454:
#0: (&tu->tread_sem){--..}, at: [] snd_timer_user_ioctl+0x618/0xb0d
[snd_timer]
stack backtrace:
[] dump_trace+0x78/0x21a
[] show_trace_log_lvl+0x35/0x54
[] show_trace+0x2c/0x2e
[] dump_stack+0x29/0x2b
[] print_usage_bug+0x14d/0x157
[] mark_lock+0xb0/0x4a9
[] __lock_acquire+0x3cf/0xc36
[] lock_acquire+0x6e/0x86
[] __spin_lock_irqsave+0x55/0x65
[] rt_spin_lock_slowlock+0x29/0x1b4
[] rt_spin_lock+0x13/0x4b
[] serial8250_console_write+0x4e/0x155
[] __call_console_drivers+0x73/0x88
[] _call_console_drivers+0x74/0x7a
[] release_console_sem+0x11e/0x1ad
[] vprintk+0x2dc/0x32b
[] printk+0x20/0x22
[] task_running_tick+0x401/0x450
[] scheduler_tick+0x188/0x1e3
[] update_process_times+0x40/0x6d
[] tick_sched_timer+0x76/0xb6
[] hrtimer_interrupt+0x15d/0x205
[] smp_apic_timer_interrupt+0x94/0xa7
[] apic_timer_interrupt+0x33/0x38
[] __spin_unlock_irqrestore+0x56/0x70
[] rt_mutex_adjust_prio+0x31/0x37
[] rt_spin_lock_slowunlock+0x6d/0x73
[] rt_spin_unlock+0x2f/0x35
[] kfree+0x9d/0xa5
[] snd_timer_user_ioctl+0x6c1/0xb0d [snd_timer]
[] do_ioctl+0x32/0x7f
[] vfs_ioctl+0x291/0x2a4
[] sys_ioctl+0x60/0x79
[] syscall_call+0x7/0xb
[] 0xb7f28410
===
---
| preempt count: 00010001 ]
| 1-level deep critical section nesting:
.. [] __spin_lock_irqsave+0x23/0x65
.[] .. ( <= rt_spin_lock_slowlock+0x29/0x1b4)
l *0xc035a0da
0xc035a0da is in __spin_lock_irqsave (kernel/spinlock.c:122).
117 {
118 unsigned long flags;
119
120 local_irq_save(flags);
121 preempt_disable();
122 spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
123 /*
124 * On lockdep we dont want the hand-coded irq-enable of
125 * _raw_spin_lock_flags() code, because lockdep assumes
126 * that interrupts are not re-enabled during lock-acquire:
l *0xc0358d1f
0xc0
Re: [PATCH] blackfin arch fix stamp537 ISP1716 IRQ setting bug
On Thu, Mar 29, 2007 at 06:47:32PM +0800, Wu, Bryan wrote:
> diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
> b/arch/blackfin/mach-bf537/boards/stamp.c
> index 0f90ff9..a4219df 100644
> --- a/arch/blackfin/mach-bf537/boards/stamp.c
> +++ b/arch/blackfin/mach-bf537/boards/stamp.c
> @@ -68,7 +68,7 @@ static struct resource bfin_isp1761_resources[] = {
> [1] = {
> .start = ISP1761_IRQ,
> .end= ISP1761_IRQ,
> - .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
> + .flags = IORESOURCE_IRQ,
> },
> };
>
So you've left the logic for set_irq_type(), yes? In that case, this
looks fine.
I'd add an Acked-by, but it probably doesn't matter :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: tty OOPS (Re: 2.6.21-rc5-mm2)
On Wed, Mar 28, 2007 at 01:07:56PM -0700, Andrew Morton wrote: > On Wed, 28 Mar 2007 22:56:32 +0400 > Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > > > On Wed, Mar 28, 2007 at 10:38:14PM +0400, Alexey Dobriyan wrote: > > > On Wed, Mar 28, 2007 at 08:04:46PM +0200, Andreas Mohr wrote: > > > > [unrelated maintainers removed, Alexey added] > > > > > > > > On Wed, Mar 28, 2007 at 07:45:24PM +0200, Andreas Mohr wrote: > > > > > Hi, > > > > > > > > > > just wanted to add that when analyzing the backtrace I found the > > > > > comment > > > > > at drivers/char/vt.c/con_close() to be VERY suspicious... > > > > > (need to take tty_mutex to prevent concurrent thread tty access). > > > > > This might just be what happened here despite trying to protect > > > > > against it. > > > > > > > > OK, can we assume that one of > > > > > > > > +protect-tty-drivers-list-with-tty_mutex.patch > > > > +tty-minor-merge-correction.patch > > > > +tty-in-tiocsctty-when-we-steal-a-tty-hang-it-up-fix.patch > > > > > > > > is responsible / not implemented fully? > > > > > > #2 is just comment removal. > > > > > > I may state the obvious, but __iget() in sysfs_drop_dentry() gets NULL > > > inode and you aren't failing on spin_lock one line above because of UP > > > without spinlock debugging. > > > > The only suspicious new patch in -rc5-mm1 to me is > > fix-sysfs-reclaim-crash.patch which removes "sd->s_dentry = NULL;". Note > > that whole sysfs_drop_dentry() is NOP if ->s_dentry is NULL. > > > > Could you try to revert it? > > > > Alexey, who knows very little about sysfs internals > > cc's added. > > > Also added is the sad little missive I sent to the USB guys last night, > which is similar-looking: > > > > Begin forwarded message: > > Date: Wed, 28 Mar 2007 00:34:45 -0700 > From: Andrew Morton <[EMAIL PROTECTED]> > To: linux-usb-devel@lists.sourceforge.net > Subject: usb/sysfs oops in 2.6.21-rc5-mm1 > > > > I think the connector wasn't pushed in terribly well, so there might have > been some contact bounce. > > > [15813.836000] ipw2200: Firmware error detected. Restarting. > [17200.268000] hub 2-0:1.0: port 1 disabled by hub (EMI?), re-enabling... > [17200.268000] usb 2-1: USB disconnect, address 4 > [17200.268000] BUG: unable to handle kernel NULL pointer dereference at > virtual address 0024 > [17200.268000] printing eip: > [17200.268000] c016e447 > [17200.268000] *pde = > [17200.268000] Oops: [#1] > [17200.268000] last sysfs file: block/sr0/size > [17200.268000] Modules linked in: udf i915 drm ipw2200 sonypi ipv6 autofs4 > hidp l2cap sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 > xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables > cpufreq_ondemand video sbs button battery asus_acpi ac nvram hci_usb > bluetooth ieee80211 ohci1394 ieee1394 joydev ieee80211_crypt snd_hda_intel > snd_hda_codec ehci_hcd uhci_hcd sg snd_seq_dummy snd_seq_oss > snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm > snd_timer snd sr_mod cdrom piix soundcore i2c_i801 snd_page_alloc i2c_core > pcspkr generic ext3 jbd ide_disk ide_core > [17200.268000] CPU:0 > [17200.268000] EIP:0060:[]Not tainted VLI > [17200.268000] EFLAGS: 00010246 (2.6.21-rc5-mm1 #1) > [17200.268000] EIP is at __iget+0x3/0x48 > [17200.268000] eax: ebx: ecx: edx: c8a90514 > [17200.268000] esi: c8a90514 edi: ebp: c8cea5e4 esp: c210fe5c > [17200.268000] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 > [17200.268000] Process khubd (pid: 155, ti=c210e000 task=c209b6f0 > task.ti=c210e000) > [17200.268000] Stack: c2493a14 c0192933 c8cea5e8 c0338373 c0338373 c8cea5e4 > c0192a90 c889ba24 > [17200.268000]c033836f c8a90514 c8cea58c c889ba08 c8556a40 df8918c0 > c24e6418 c0230d46 > [17200.268000]c889ba08 c889ba08 c0230dd8 c889ba08 c889ba00 df8918c0 > c24e6418 c0230ffa > [17200.268000] Call Trace: > [17200.268000] [] sysfs_drop_dentry+0x2b/0xc3 > [17200.268000] [] sysfs_hash_and_remove+0x86/0x12c > [17200.268000] [] device_remove_file+0x19/0x25 > [17200.268000] [] device_del+0x26/0x240 > [17200.268000] [] device_unregister+0x8/0x10 > [17200.268000] [] usb_remove_ep_files+0x4d/0x60 > [17200.268000] [] usb_new_device+0x199/0x1ab > [17200.268000] [] usb_remove_sysfs_intf_files+0x1e/0x43 > [17200.268000] [] usb_disable_device+0x55/0xbb > [17200.268000] [] usb_disconnect+0x87/0x100 > [17200.268000] [] hub_thread+0x361/0xa70 > [17200.268000] [] d_lookup+0x16/0x31 > [17200.268000] [] __wake_up_common+0x31/0x4f > [17200.268000] [] autoremove_wake_function+0x0/0x35 > [17200.268000] [] hub_thread+0x0/0xa70 > [17200.268000] [] kthread+0xa0/0xc9 > [17200.268000] [] kthread+0x0/0xc9 > [17200.268000] [] kernel_thread_helper+0x7/0x10 > [17200.268000] === > [17200.268000] Code: 00 00 00 89 d8 81 ce 00 02 00 00 e8 3e ba 01 00 8b 43 20 > 31 c9 89 f2 89 04 24 89 d8 e8 19 25 01 00
Re: [ck] Re: [PATCH] sched: staircase deadline misc fixes
On 3/29/07, Mike Galbraith <[EMAIL PROTECTED]> wrote: Rereading to make sure I wasn't unclear anywhere... On Thu, 2007-03-29 at 07:50 +0200, Mike Galbraith wrote: > > I don't see what a < 95% load really means. Egad. Here I'm pondering the numbers and light load as I'm typing, and my fingers (seemingly independent when mind wanders off) typed < 95% as in not fully committed, instead of "light". While I don't know the _exact_ figure for this, my hunch is that a good ballpark figure is anything that is not a heavy load (less than 4, perhaps even lower, maybe <0.75 or <2?) and that is not a "niced" load. -- -- Michael Chang ~Just the crazy copy cat~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] i386: add command line option "local_apic_timer_c2_ok"
Len Brown <[EMAIL PROTECTED]> writes: > On an Intel processor, it seems that the safe and simple route > is if the system exports C2 or deeper, don't use the LAPIC timer. > (which is what 2.6.21-rc5 is doing as of this moment) > We may be able to white-list some systems over time. On AMD it is the same, except that there seems to be at least one system that does C2 like things while only exporting C1. That is why i proposed to check for a battery too -- if there is one always disable it too. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB: on suspend to ram/disk all usb devices are replugged
Maxim Levitsky wrote: Hi, I noticed that after suspend/resume cycle all my usb devices are unplugged/replugged by uhci driver. While it is not that big problem to me, that can be a real problem if a device is a flash card with mounted file-system, because disappeared device will cause file-system corruption. Mmm.. this sounds really bad -- I wonder what happens if the rootfs is on USB ? With older kernels, things just "worked" this way. Has it now been broken ?? -ml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] i386: add command line option "local_apic_timer_c2_ok"
Linus Torvalds <[EMAIL PROTECTED]> writes: > On Tue, 27 Mar 2007, Len Brown wrote: > > > > I think the only fool-proof way to do this automatically is to > > Why not just take the known-good CPUID signature? I didn't think we could reliably distingush mobile cpus with C2+ versus desktop CPUs without it. Or rather you would need a table for each new CPU revision Intel/AMD put out. That would be probably quite nightmarish to maintain. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/21] MSI: Do MSI masking in the arch code
Michael Ellerman <[EMAIL PROTECTED]> writes: > > The main motivation was to have the arch in control of as much direct > register writing as possible. Even though our HV does allow us to write > to config space, it's not obviously safe for Linux to be flipping bits > and also calling the HV to configure things. What's worse, I don't have > hardware that supports the mask bits, so I can't test it. I agree that there are limits here, on what we can feed into a hypervisor and not confuse it. Mostly my thinking is to assume someone has been scribbling with the msi capability before we got there and to place everything in a know good state and not assume that device reset has already done the work for us. Since we aren't the pci device reset we can choose the defaults that make sense for us. Worse case we can just put the capability in the state that pci device reset would have put it in. > I also thought this would save me from having custom MSI irq_chips for > the powerpc backends. But I think I need them now anyway, so I guess > that's not a concern. Well we could still do the basic setup in arch_setup_msi_irq so I don't think it has ever been an irq_chips style operations. > So I guess we'll drop this one, although I might try and tidy up the > implementation of "mask all MSIs" in msi_capability_init() as another > patch. I have no problem with that. The msix version of this still needs to be written as well. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
staircase deadline 0.36 backport 2.6.18.8 and 2.6.19.7
Hi all, Backports of the staircase deadline cpu scheduler for 2.6.18.8 and 2.6.19.7 kernels are available at http://linux-dev.qc.ec.gc.ca/. Also, Debian Etch 4.0 kernels for both i686 and x86_64 are available. Fedora Core 6 kernels might also be available later today/tomorrow. Both patches looks quite stable. I've been able to fix the 2.6.19 backport by reversing this patch: "[PATCH] move_task_off_dead_cpu() should be called with disabled ints" (see http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=co mmit;h=054b9108e01ef27e2e6b32b4226abb6024626f06). I don't know if this bug (see http://linux-dev.qc.ec.gc.ca/kernel/debian/etch/x86_64/2.6.19/bug-2.6.19 .7-rsdl-033.jpg) can also affect a Vanilla 2.6.19.7 kernel or even the actual mainline? Duno if it would be worth investigating a bit further? Although, here is a top of a 2.6.19.7 + SD 0.36 patch in action while building 3 kernels at once and running a glxgears in foreground: top - 12:39:39 up 17 min, 2 users, load average: 5.84, 4.37, 2.20 Tasks: 162 total, 5 running, 157 sleeping, 0 stopped, 0 zombie Cpu0 : 87.0%us, 13.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 88.4%us, 11.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2059940k total, 1249476k used, 810464k free, 137112k buffers Swap: 1959888k total,0k used, 1959888k free, 620552k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 15970 root 33 0 45016 36m 4520 R 18 1.8 0:00.54 cc1 16025 root 1 0 40904 32m R 18 1.6 0:00.53 cc1 16015 root 33 0 40620 32m 4496 R 17 1.6 0:00.52 cc1 13401 th0ma7 1 0 42356 9420 6700 R6 0.5 1:16.13 glxgears 16589 root 1 0 3756 400 192 S1 0.0 0:01.04 faked-sysv 5012 root 5 0 91208 46m 7200 S0 2.3 0:11.57 Xorg Note that my KDE session/firefox/kontact/etc. was still pretty responsive! Vincent Fortier Informatique Environnement Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: tighten kernel image page access rights (re-diff against firstfloor tree)
>>> Andi Kleen <[EMAIL PROTECTED]> 29.03.07 14:22 >>> >On Thursday 29 March 2007 14:01, Jan Beulich wrote: >> On x86-64, kernel memory freed after init can be entirely unmapped instead >> of just getting 'poisoned' by overwriting with a debug pattern. >> >> On i386 and x86-64 (under CONFIG_DEBUG_RODATA), kernel text and bug table >> can also be write-protected. >> >> (Not sure what the symbol 'stext' is good for; can it be removed?) > >I see you remove it already I don't think I do - I just move _stext (on x86-64), but leave stext alone. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: tighten kernel image page access rights (re-diff against firstfloor tree)
On Thursday 29 March 2007 15:49, Jan Beulich wrote: > >>> Andi Kleen <[EMAIL PROTECTED]> 29.03.07 14:22 >>> > >On Thursday 29 March 2007 14:01, Jan Beulich wrote: > >> On x86-64, kernel memory freed after init can be entirely unmapped instead > >> of just getting 'poisoned' by overwriting with a debug pattern. > >> > >> On i386 and x86-64 (under CONFIG_DEBUG_RODATA), kernel text and bug table > >> can also be write-protected. > >> > >> (Not sure what the symbol 'stext' is good for; can it be removed?) > > > >I see you remove it already > > I don't think I do - I just move _stext (on x86-64), but leave stext alone. Ok i removed it now -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: max_loop limit
Tomas M wrote: 255 loop devices are insufficient? What kind of scenario do you have in mind? Thank you very much for replying. In 1981, Bill Gates said that 64KB of memory is enough for everybody. And you know how much RAM do you have right now. :) Actually, I believe the number was 640k, the quote included the phrase "should be," the available memory on the IBM PC. And this was after IBM decided to put the video adapter in memory at 640k, Intel decided to provide only 1MB of address space on the 8086, and was in the context of mainframes of the day, some of which could only address 1MB. And having run clients with three users on an XT with just that 640kB and UNIX, I don't think he was wrong about the memory for that time, just the O/S. BTW: anyone got a copy of PC/IX (SysIII for XT) around? I'd love to run that in a VM just for the comparison. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix file specification in comments
Many files include the filename at the beginning, serveral used a wrong one. Signed-off-by: Uwe Kleine-König <[EMAIL PROTECTED]> --- This is a follow up to f30c2269544bffc7bf1b0d7c0abe5be1be83b8cb. This patch was generated with the same program as the former patch. arch/arm/mach-s3c2410/sleep.S |2 +- arch/arm/plat-s3c24xx/sleep.S |2 +- arch/i386/kernel/cpu/mcheck/therm_throt.c |2 +- arch/powerpc/platforms/8xx/mpc86xads_setup.c |2 +- arch/powerpc/platforms/8xx/mpc885ads_setup.c |2 +- arch/ppc/platforms/mpc866ads_setup.c |2 +- arch/ppc/syslib/ipic.c|2 +- arch/sh/boards/se/7751/setup.c|2 +- arch/sh/kernel/cpu/sh3/entry.S|2 +- arch/sh/kernel/cpu/sh4a/clock-sh73180.c |2 +- arch/sh/kernel/cpu/sh4a/clock-sh7343.c|2 +- arch/sh/kernel/cpu/sh4a/clock-sh7770.c|2 +- arch/sh/kernel/cpu/sh4a/clock-sh7780.c|2 +- arch/sh/kernel/vsyscall/vsyscall.c|2 +- arch/um/include/sysdep-i386/archsetjmp.h |2 +- arch/um/include/sysdep-x86_64/archsetjmp.h|2 +- arch/xtensa/kernel/pci-dma.c |2 +- drivers/leds/leds-h1940.c |2 +- drivers/video/console/softcursor.c|2 +- fs/jbd/checkpoint.c |2 +- fs/jbd/recovery.c |2 +- fs/jbd/revoke.c |2 +- fs/jbd/transaction.c |2 +- fs/jbd2/checkpoint.c |2 +- fs/jbd2/recovery.c|2 +- fs/jbd2/revoke.c |2 +- fs/jbd2/transaction.c |2 +- include/asm-arm/arch-iop32x/glantank.h|2 +- include/asm-arm/arch-iop32x/n2100.h |2 +- include/asm-arm/arch-s3c2410/regs-power.h |2 +- include/asm-arm/arch-s3c2410/regs-s3c2443-clock.h |2 +- include/asm-arm/arch-s3c2410/regs-watchdog.h |2 +- include/asm-arm/arch-s3c2410/udc.h|2 +- include/asm-sh/edosk7705.h|2 +- include/asm-sh/snapgear.h |2 +- include/asm-xtensa/platform-iss/simcall.h |2 +- include/linux/generic_acl.h |2 +- sound/soc/pxa/pxa2xx-ac97.h |2 +- sound/soc/pxa/pxa2xx-i2s.h|2 +- 39 files changed, 39 insertions(+), 39 deletions(-) diff --git a/arch/arm/mach-s3c2410/sleep.S b/arch/arm/mach-s3c2410/sleep.S index 637aaba..d1eeed2 100644 --- a/arch/arm/mach-s3c2410/sleep.S +++ b/arch/arm/mach-s3c2410/sleep.S @@ -1,4 +1,4 @@ -/* linux/arch/arm/mach-s3c2410/s3c2410-sleep.S +/* linux/arch/arm/mach-s3c2410/sleep.S * * Copyright (c) 2004 Simtec Electronics * Ben Dooks <[EMAIL PROTECTED]> diff --git a/arch/arm/plat-s3c24xx/sleep.S b/arch/arm/plat-s3c24xx/sleep.S index 435349d..7b7ae79 100644 --- a/arch/arm/plat-s3c24xx/sleep.S +++ b/arch/arm/plat-s3c24xx/sleep.S @@ -1,4 +1,4 @@ -/* linux/arch/arm/mach-s3c2410/sleep.S +/* linux/arch/arm/plat-s3c24xx/sleep.S * * Copyright (c) 2004 Simtec Electronics * Ben Dooks <[EMAIL PROTECTED]> diff --git a/arch/i386/kernel/cpu/mcheck/therm_throt.c b/arch/i386/kernel/cpu/mcheck/therm_throt.c index 065005c..2f28540 100644 --- a/arch/i386/kernel/cpu/mcheck/therm_throt.c +++ b/arch/i386/kernel/cpu/mcheck/therm_throt.c @@ -1,5 +1,5 @@ /* - * linux/arch/i386/kerne/cpu/mcheck/therm_throt.c + * linux/arch/i386/kernel/cpu/mcheck/therm_throt.c * * Thermal throttle event support code (such as syslog messaging and rate * limiting) that was factored out from x86_64 (mce_intel.c) and i386 (p4.c). diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c b/arch/powerpc/platforms/8xx/mpc86xads_setup.c index ef52ce7..652b665 100644 --- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c +++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c @@ -1,4 +1,4 @@ -/*arch/ppc/platforms/mpc86xads-setup.c +/*arch/powerpc/platforms/8xx/mpc86xads_setup.c * * Platform setup for the Freescale mpc86xads board * diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c index c5fefdf..42aef56 100644 --- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c +++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c @@ -1,4 +1,4 @@ -/*arch/ppc/platforms/mpc885ads-setup.c +/*arch/powerpc/platforms/8xx/mpc885ads_setup.c * * Platform setup for the Freescale mpc885ads board * diff --git a/arch/ppc/platforms/mpc866ads_setup.c b/arch/ppc/platforms/mpc866ads_setup.c index 5b05d4b..2542a42 100644 --- a/arch/ppc/platforms/mpc866ads_setup.c +++ b/arch/ppc/platforms/mpc866ads_setup.c @@ -1,4 +1,4 @@ -/*arch/ppc/platforms/mpc866ads-setup.c
Re: max_loop limit
roland wrote: partitions on loop or device-mapper devices ? you can use kpartx tool for this. bryn m. reeves told me, that it's probably poissible to create udev rules that will automatically create partition maps when a new loop device is setup, which is better than adding partitioning logig into dm-loop for example. It is certainly possible to create a partitionable RAID device from a loop device. Should be possible to use nbd as well, but I can't seem to get nbd to work on 2.6.21-rc (my working system runs 2.6.17). example: kpartx -a /dev/mapper/loop0 # ls /dev/mapper/loop0* /dev/mapper/loop0 /dev/mapper/loop0p1 /dev/mapper/loop0p2 /dev/mapper/loop0p3 i have seen a patch for loop.c doing this, though. search the archives for this regards roland On Thu, Mar 22, 2007 at 02:33:14PM +, Al Viro wrote: Correction: current ABI is crap. To set the thing up you need to open it and issue an ioctl. Which is a bloody bad idea, for obvious reasons... Agreed. What would be a right way? Global device ala ptmx/tun/tap? New syscall? Something else? OG. - ] -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20.3-rt8 - DMA suffers excessive delay periodically
Lee Revell wrote: John wrote: Would someone know how to disable SMM in this BIOS? There's no generic way. I understand. Would someone know how to disable SMM in the VIA Pro133T chipset (VT82C596B south bridge). What I/O ports do I need to write to, and what values should I write to these ports? Try disabling USB keyboard emulation and any unused peripherals. I have disabled everything I could find in the BIOS. Serial and parallel ports, USB, integrated sound, APM, ACPI, booting from exotic hardware or from the network. To no avail :-( Also google "RTAI disable SMM". I see that they have a Linux kernel module to disable SMM in Intel chipsets. But I didn't see the equivalent for VIA chipsets. Is this a laptop? They are plagued with SMM problems... No it is an "indutrial" motherboard. Although I don't know what makes it "industrial". One would really hope that such a device would be designed for machine control and similar RT apps and thus free of SMM... Indeed... I wonder if VIA thinks their old chipsets were industrial-grade. Regards. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions
Hello.
Maxim wrote:
---
This adds support of suspend/resume on i386 for HPET
The part after usually "---" gets cut off, the patch description and
signoff should actially *precede* it.
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..7c67780 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
[...]
+static __init int hpet_register_sysfs(void)
+{
+ int err;
+
+ if (!is_hpet_capable())
+ return 0;
+
+ err = sysdev_class_register(&hpet_class);
+
+ if (!err) {
+ sysdev_register(&hpet_device);
+ if (err)
+ sysdev_class_unregister(&hpet_class);
This doesn't make sense, err will always be 0. Perhaps you actually
intended to check the result of sysdev_register()?
+ }
+
+ return err;
+}
+
+device_initcall(hpet_register_sysfs);
+
+#endif
WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions
On Thursday 29 March 2007 15:20:27 Sergei Shtylyov wrote:
> Hello.
>
> Maxim wrote:
>
> > ---
> > This adds support of suspend/resume on i386 for HPET
>
>The part after usually "---" gets cut off, the patch description and
> signoff should actially *precede* it.
>
> > Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
>
> > diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
> > index 0fd9fba..7c67780 100644
> > --- a/arch/i386/kernel/hpet.c
> > +++ b/arch/i386/kernel/hpet.c
> [...]
> > +static __init int hpet_register_sysfs(void)
> > +{
> > + int err;
> > +
> > + if (!is_hpet_capable())
> > + return 0;
> > +
> > + err = sysdev_class_register(&hpet_class);
> > +
> > + if (!err) {
> > + sysdev_register(&hpet_device);
> > + if (err)
> > + sysdev_class_unregister(&hpet_class);
>
> This doesn't make sense, err will always be 0. Perhaps you actually
> intended to check the result of sysdev_register()?
>
> > + }
> > +
> > + return err;
> > +}
> > +
> > +device_initcall(hpet_register_sysfs);
> > +
> > +#endif
>
> WBR, Sergei
>
Hi,
Big thanks for pointing this out,
I will resend that updated patch.
Best regards,
Maxim Levitsky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 v2] Add suspend/resume for HPET
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
---
arch/i386/kernel/hpet.c | 68 +++
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..7c67780 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -3,6 +3,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -310,6 +312,7 @@ int __init hpet_enable(void)
out_nohpet:
iounmap(hpet_virt_address);
hpet_virt_address = NULL;
+ boot_hpet_disable = 1;
return 0;
}
@@ -524,3 +527,68 @@ irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
#endif
+
+
+/*
+ * Suspend/resume part
+ */
+
+#ifdef CONFIG_PM
+
+static int hpet_suspend(struct sys_device *sys_device, pm_message_t state)
+{
+ unsigned long cfg = hpet_readl(HPET_CFG);
+
+ cfg &= ~(HPET_CFG_ENABLE|HPET_CFG_LEGACY);
+ hpet_writel(cfg, HPET_CFG);
+
+ return 0;
+}
+
+static int hpet_resume(struct sys_device *sys_device)
+{
+ unsigned int id;
+
+ hpet_start_counter();
+
+ id = hpet_readl(HPET_ID);
+
+ if (id & HPET_ID_LEGSUP)
+ hpet_enable_int();
+
+ return 0;
+}
+
+static struct sysdev_class hpet_class = {
+ set_kset_name("hpet"),
+ .suspend= hpet_suspend,
+ .resume = hpet_resume,
+};
+
+static struct sys_device hpet_device = {
+ .id = 0,
+ .cls= &hpet_class,
+};
+
+
+static __init int hpet_register_sysfs(void)
+{
+ int err;
+
+ if (!is_hpet_capable())
+ return 0;
+
+ err = sysdev_class_register(&hpet_class);
+
+ if (!err) {
+ err = sysdev_register(&hpet_device);
+ if (err)
+ sysdev_class_unregister(&hpet_class);
+ }
+
+ return err;
+}
+
+device_initcall(hpet_register_sysfs);
+
+#endif
--
1.4.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] the scheduled eepro100 removal
Sounds sane to me. My overall opinion on eepro100 removal is that we're not there yet. Rare problem cases remain where e100 fails but eepro100 works, and it's older drivers so its low priority for everybody. Needs to happen, though... It seems that several Tyan Opteron base system that were using IPMI add on card. the IPMI card share intel 100Mhz nic onboard. you need to use eepro100 instead of e100 otherwise the e100 will shutdown OOB (out of Band) connection for IPMI when shut down the OS. I find it hard to believe that something as common as IPMI in conjunction with the IPMI technology wasn't tested in Intel's lab. From my experience with Intel Server boards, onboard IPMI (all offered versions) and e100/e1000 NICs, I've never ever experienced any problems operating the BMC over the NIC. Also, I don't quite understand you point about the "IPMI card sharing the 100Mbit/s NIC" onboard? What exactly is shared? Best regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver fixes
Guennadi Liakhovetski wrote: Jeff, might be worth getting the sk_buff leak fix in ppp from http://www.spinics.net/lists/netdev/msg27706.html in 2.6.21 too? Don't know how important it is for stable. It was present in 2.6.18 too. Can you resend the patch to me, please? Easier for the system to apply than the URL... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ehea: removing unused functionality
Jan-Bernd Themann wrote: This patch includes: - removal of unused fields in structs - ethtool statistics cleanup - removes unsed functionality from send path Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]> --- This patch applies on top of the netdev upstream branch for 2.6.22 drivers/net/ehea/ehea.h | 25 ++--- drivers/net/ehea/ehea_ethtool.c | 111 ++-- drivers/net/ehea/ehea_main.c| 55 +++ drivers/net/ehea/ehea_qmr.h |2 4 files changed, 69 insertions(+), 124 deletions(-) applied to #upstream - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT] e100 driver on ARM
On Thu, Mar 29, 2007 at 01:17:38AM -0400, David Acker wrote: > I have a pxa255 based system with PCI added to it. The e100 would have > memory corruption in its receive buffers detected by slab debugging > unless I put in the patch to use the S-bit. > > Here is a link to the patch posting: > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/broken-out/git-netdev-all.patch > Search for e100.c. > > http://www-gatago.com/linux/kernel/15457063.html - This discussion seems > to hit the issue. > > There appears to be a race on the cache line where the EL bit and the > next packet info live. In my case the hardware appeared to write to a > free packet. The S-bit seems to make the hardware stop and spin on the > bit, while the EL bit seems to let the hardware try to use that packet. > > This race would occur less often when the receive buffer chain is always > refilled before the hardware can use them up. On our 400 Mhz Xscale, we > can use up all 256 buffers if the PCI bus has another busy device on it. > In our case it is an 802.11g miniPCI card and our software was routing > all ethernet packets to the wireless interface and vice versa while TCP > streams were running accross these connections. Which PCI host controller are you using with the PXA255? We tried using a PXA255 based system with a PCI controller a couple of years ago and have to change to a different cpu in the end due to the PCI controller simply not being valid PCI. The PXA255 wasn't designed for PCI, and I get the impression that non of the PCI companion chips for it do a good enough job to actually add it correctly. -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3/6] 2.6.21-rc4: known regressions
On 3/29/07, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote: > Quoting Maxim <[EMAIL PROTECTED]>: > The patch below is a temporally fix, until > clock-events and clocksources will get proper suspend/resume > hooks: Bingo! I confirmed that it suspend/resume disk/ram all works on my X60s with CONFIG_HPET_TIMER=y and CONFIG_NO_HZ unset. But suspend to disk still hang with CONFIG_NO_HZ=y no matter what setting CONFIG_HPET_TIMER is set to. Thanks, Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC] HID bus design overview.
On Thu, 29 Mar 2007, Li Yu wrote: > The last word is a question, what's the future of hiddev? It will merge > into hidraw later? I think so, but can't sure. Hi Li, no, it won't, it doesn't provide compatible interface for purpose. hiddev has currently the following drawbacks: - USB-transport specific - uses in-kernel HID parser to parse reports and fill in usages and values. This is usually not what authors of the userspace drivers for HID devices want - the devices often have quirks or behave in a strange way, and making workarounds is more complicated when kernel parser operates on the received reports - only a few applications use it (acupsd, nut, hid2hcianything else?). All other drivers rather use libhid, which is built on top of libusb, in order to be able to receive and send really raw HID reports, and parse them on their own. This is however also USB-transport specific The purpose of hidraw is to provide the applications the same functionality they are having when using libhid/libusb, but in a transport-independent way, as it is hooked to generic HID layer, which works as a 'proxy' for different transports that use it. -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
Tino Keitel wrote: On Mon, Mar 26, 2007 at 17:15:53 -0400, Alan Stern wrote: [...] The lack of messages from the iPod seems to indicate that the hub isn't working right. You could try plugging the iPod into a different hub or directly into the computer. Or maybe into a different port of that hub. Uh, I think I found the reason for the strange behaviour at shutdown/suspend. When I unload the usblp module, then the iPod is recognized. And that's not the case with 2.6.20? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-rc5: swsusp: Not enough free memory
On Thursday, 29 March 2007 09:44, Jiri Slaby wrote:
> Hi,
>
> I'm getting this while trying to swsups the machine in -rc5, -rc4 is fine:
>
> Disabling non-boot CPUs
> CPU 1 is now offline
> SMP alternatives: switching to UP code
> CPU1 is down
> swsusp: critical section:
> swsusp: Need to copy 131380 pages
> swsusp: Not enough free memory
> Error -12 suspending
> Enabling non-boot CPUs ...
>
> # cat /sys/power/resume
> 8:6
> # cat /proc/swaps
> FilenameTypeSizeUsed
> Priority
> /dev/sda6 partition 1004020 0 -1
>
> Any other info needed?
Beats me. There were no changes that could result in such a thing between
-rc4 and -rc5, at least not in the swsusp department.
Could you please try to bisect?
> BTW. is this OK on resume?
> PM: Writing back config space on device :02:00.0 at offset 1 (was 16,
> w
> iting 12)
> pnp: Failed to activate device 00:04.
> pnp: Failed to activate device 00:05.
> usbdev5.3_ep00: PM: resume from 0, parent 5-4 still 2
>
> # ll /sys/bus/pnp/devices/00\:0{4,5}/driver
> lrwxrwxrwx 1 root root 0 2007-03-29 09:16 /sys/bus/pnp/devices/00:04/driver
> -> ../../../bus/pnp/drivers/i8042 kbd
> lrwxrwxrwx 1 root root 0 2007-03-29 09:16 /sys/bus/pnp/devices/00:05/driver
> -> ../../../bus/pnp/drivers/i8042 aux
Well, I don't think so.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5: swsusp: Not enough free memory
Rafael J. Wysocki napsal(a):
> On Thursday, 29 March 2007 09:44, Jiri Slaby wrote:
>> Hi,
>>
>> I'm getting this while trying to swsups the machine in -rc5, -rc4 is fine:
>>
>> Disabling non-boot CPUs
>> CPU 1 is now offline
>> SMP alternatives: switching to UP code
>> CPU1 is down
>> swsusp: critical section:
>> swsusp: Need to copy 131380 pages
>> swsusp: Not enough free memory
>> Error -12 suspending
>> Enabling non-boot CPUs ...
>>
>> # cat /sys/power/resume
>> 8:6
>> # cat /proc/swaps
>> FilenameTypeSizeUsed
>> Priority
>> /dev/sda6 partition 1004020 0 -1
>>
>> Any other info needed?
>
> Beats me. There were no changes that could result in such a thing between
> -rc4 and -rc5, at least not in the swsusp department.
>
> Could you please try to bisect?
Yes, I will.
>> BTW. is this OK on resume?
>> PM: Writing back config space on device :02:00.0 at offset 1 (was
>> 16, w
>> iting 12)
>> pnp: Failed to activate device 00:04.
>> pnp: Failed to activate device 00:05.
>> usbdev5.3_ep00: PM: resume from 0, parent 5-4 still 2
>>
>> # ll /sys/bus/pnp/devices/00\:0{4,5}/driver
>> lrwxrwxrwx 1 root root 0 2007-03-29 09:16 /sys/bus/pnp/devices/00:04/driver
>> -> ../../../bus/pnp/drivers/i8042 kbd
>> lrwxrwxrwx 1 root root 0 2007-03-29 09:16 /sys/bus/pnp/devices/00:05/driver
>> -> ../../../bus/pnp/drivers/i8042 aux
>
> Well, I don't think so.
(This is probably not a regression, it's in -rc4 too.)
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
Hnus <[EMAIL PROTECTED]> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc() with size zero
Stephane Eranian wrote: Hi, On Sun, Mar 25, 2007 at 06:30:34PM +0200, Folkert van Heusden wrote: I'd say "feature", glibc's malloc also returns an address on malloc(0). This is implementation defined-the standard allows for return of either null or an address. Entirely for entertainment: AIX (5.3) returns NULL, IRIX returns a valid address. That's interesting, so many different behaviors! Personally, I still prefer when malloc(0) returns zero because it makes it easier to catch errors. Exactly, the address returned is not really useful, the improved error checking is useful. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] i386: add command line option "local_apic_timer_c2_ok"
> > If we really care about using the LAPIC timer on systems with deeper
> > than C1 support, the only alternative seems to be to test
> > if it actually works or not at boot and run-time.
> > Otherwise, we wait for future hardware with guaranteed
> > not to break under any (BIOS) conditions ships, and check for that.
> >
> > Based on what I read of the HP nx6325 where the LAPIC timer
> > is breaking C1, AMD is in the same boat.
>
> The nx6325 (Turion 64 X2) exports only C1.
> I'm not sure how the conclusion was drawn that it has
> a broken lapic timer as reflected in the "nolapic_timer" patch:
If both cores goes into C1 at the same time, the chipset
can move the processor into a C3 like state called C1e.
> + /*
> +* BIOS exports only C1 state, but uses deeper power
> +* modes behind the kernels back.
> +*/
> + .callback = lapic_check_broken_bios,
> + .ident = "HP nx6325",
> + .matches = {
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP
> Compaq nx6325"),
> + },
> +},
>
> But if this is true, then I don't know how to determine on
> an AMD system if the LAPIC timer is guaranteed to work --
> even for systems with just C1.
>
> Jordan, William, can you clarify?
For K7 and K8 through and including revision E, the LAPIC
timer is guaranteed to work in C1.
For K8 revisions F and G, and for upcoming family 0x10 and
0x11 parts, if either bit in MSRC001_0055[28:27] is set,
C1e is enabled and the LAPIC timer cannot be trusted in
C1.
AMD can craft a patch to sort this out as soon as we have
an idea what the framework is going to look like.
-Mark Langsdorf
Operating Systems Research Center
AMD, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cifs causes BUG: soft lockup detected on CPU
This should be fixed in 2.6.21 as of 2/26. The fix was http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3677db10a635a39f63ea509f8f0056d95589ff90 Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com Andrew Morton <[EMAIL PROTECTED]> wrote on 03/29/2007 03:54:57 AM: > On Wed, 28 Mar 2007 20:35:55 +0200 "Valentin Zaharov" > <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > We have continous problem with server freezes. We are using cifs mounts > > on apache powered web servers with content located on Win2k3 server. > > Servers freeze from time to time, producing following error just before > > freeze: > > > > Mar 26 21:50:37 UFR2 kernel: CIFS VFS: cifs_strtoUCS: char2uni returned > > -22 Mar 26 21:51:45 UFR2 last message repeated 55 times Mar 26 21:52:49 > > UFR2 last message repeated 30 times Mar 26 21:54:16 UFR2 last message > > repeated 10 times Mar 26 21:56:13 UFR2 last message repeated 20 times > > Mar 26 21:58:34 UFR2 last message repeated 75 times Mar 26 21:59:43 UFR2 > > last message repeated 30 times Mar 26 22:01:02 UFR2 last message > > repeated 30 times Mar 26 22:02:04 UFR2 last message repeated 30 times > > Mar 26 22:03:08 UFR2 last message repeated 50 times Mar 26 22:04:27 UFR2 > > last message repeated 10 times Mar 26 22:05:59 UFR2 last message > > repeated 20 times Mar 26 22:07:10 UFR2 last message repeated 20 times > > Mar 26 22:29:00 UFR2 last message repeated 64 times Mar 27 00:47:40 UFR2 > > last message repeated 15 times Mar 27 01:42:41 UFR2 last message > > repeated 95 times Mar 27 02:15:57 UFR2 last message repeated 90 times > > Mar 27 02:27:13 UFR2 last message repeated 45 times Mar 27 03:14:08 UFR2 > > last message repeated 95 times Mar 27 04:26:10 UFR2 last message > > repeated 2 times Mar 27 06:11:35 UFR2 last message repeated 45 times Mar > > 27 06:20:20 UFR2 last message repeated 15 times Mar 27 06:20:20 UFR2 > > last message repeated 12 times Mar 27 06:27:53 UFR2 kernel: BUG: soft > > lockup detected on CPU#3! > > Mar 27 06:27:53 UFR2 kernel: [] softlockup_tick+0x9e/0xac Mar > > 27 06:27:53 UFR2 kernel: [] update_process_times+0x3b/0x5e > > Mar 27 06:27:53 UFR2 kernel: [] > > smp_apic_timer_interrupt+0x6c/0x7a > > Mar 27 06:27:53 UFR2 kernel: [] > > apic_timer_interrupt+0x28/0x30 Mar 27 06:27:53 UFR2 kernel: > > [] generic_fillattr+0x75/0xa8 Mar 27 06:27:53 UFR2 kernel: > > [] cifs_getattr+0x1e/0x2b [cifs] Mar 27 06:27:53 UFR2 kernel: > > [] cifs_getattr+0x0/0x2b [cifs] Mar 27 06:27:53 UFR2 kernel: > > [] vfs_getattr+0x21/0x30 Mar 27 06:27:53 UFR2 kernel: > > [] vfs_fstat+0x22/0x31 Mar 27 06:27:53 UFR2 kernel: > > [] sys_fstat64+0xf/0x23 Mar 27 06:27:53 UFR2 kernel: > > [] sys_open+0x1a/0x1c Mar 27 06:27:53 UFR2 kernel: > > [] sysenter_past_esp+0x5d/0x81 Mar 27 06:27:53 UFR2 kernel: > > [] xdr_xcode_array2+0x307/0x506 Mar 27 06:27:53 UFR2 kernel: > > You didn't tell us what kernel version you're running. > > Hanging in generic_fillattr: i_size_read() got stuck. This is because CIFS > doesn't correctly hold i_mutex across i_size_write(). > > Steve, where are we up to with the fixes for that? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix dependency generation
On Thu, 29 Mar 2007 10:27:14 +0100 Jan Beulich wrote:
> Commit 2e3646e51b2d6415549b310655df63e7e0d7a080 changed the way
> the split config tree is built, but failed to also adjust fixdep
> accordingly - if changing a config option from or to m, files
> referencing the respective CONFIG_..._MODULE (but not the
> corresponding CONFIG_...) didn't get rebuilt.
>
> Once at it, also eliminate false dependencies due to use of
> ...CONFIG_... identifiers.
>
> Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
>
> --- linux-2.6.21-rc5/scripts/basic/fixdep.c 2007-02-04 19:44:54.0
> +0100
> +++ 2.6.21-rc5-fixdep-mod/scripts/basic/fixdep.c 2007-03-29
> 11:11:10.0 +0200
> @@ -29,8 +29,7 @@
> * option which is mentioned in any of the listed prequisites.
> *
> * To be exact, split-include populates a tree in include/config/,
> - * e.g. include/config/his/driver.h, which contains the #define/#undef
> - * for the CONFIG_HIS_DRIVER option.
I don't see why you deleted the line above.
> + * e.g. include/config/his/driver.h, consiting of empty files.
consisting
> *
> * So if the user changes his CONFIG_HIS_DRIVER option, only the objects
> * which depend on "include/linux/config/his/driver.h" will be rebuilt,
> @@ -223,7 +222,7 @@ void use_config(char *m, int slen)
> void parse_config_file(char *map, size_t len)
> {
> int *end = (int *) (map + len);
> - /* start at +1, so that p can never be < map */
> + /* start at +1, so that p can never be <= map */
> int *m = (int *) map + 1;
> char *p, *q;
>
> @@ -235,6 +234,8 @@ void parse_config_file(char *map, size_t
> continue;
> conf:
> if (p > map + len - 7)
> + break;
> + if (isalnum(p[-1]) || p[-1] == '_')
> continue;
> if (memcmp(p, "CONFIG_", 7))
> continue;
> @@ -245,6 +246,8 @@ void parse_config_file(char *map, size_t
> continue;
>
> found:
> + if (!memcmp(q - 7, "_MODULE", 7))
> + q -= 7;
> use_config(p+7, q-p-7);
> }
> }
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: cifs causes BUG: soft lockup detected on CPU
Thanks a lot, I will try to update to latest kernel version and see if it helps. -Original Message- From: Steven French [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 5:06 PM To: Andrew Morton Cc: Valentin Zaharov; linux-kernel@vger.kernel.org Subject: Re: cifs causes BUG: soft lockup detected on CPU This should be fixed in 2.6.21 as of 2/26. The fix was http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=3677db10a635a39f63ea509f8f0056d95589ff90 Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com Andrew Morton <[EMAIL PROTECTED]> wrote on 03/29/2007 03:54:57 AM: > On Wed, 28 Mar 2007 20:35:55 +0200 "Valentin Zaharov" > <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > We have continous problem with server freezes. We are using cifs mounts > > on apache powered web servers with content located on Win2k3 server. > > Servers freeze from time to time, producing following error just before > > freeze: > > > > Mar 26 21:50:37 UFR2 kernel: CIFS VFS: cifs_strtoUCS: char2uni returned > > -22 Mar 26 21:51:45 UFR2 last message repeated 55 times Mar 26 21:52:49 > > UFR2 last message repeated 30 times Mar 26 21:54:16 UFR2 last message > > repeated 10 times Mar 26 21:56:13 UFR2 last message repeated 20 times > > Mar 26 21:58:34 UFR2 last message repeated 75 times Mar 26 21:59:43 UFR2 > > last message repeated 30 times Mar 26 22:01:02 UFR2 last message > > repeated 30 times Mar 26 22:02:04 UFR2 last message repeated 30 times > > Mar 26 22:03:08 UFR2 last message repeated 50 times Mar 26 22:04:27 UFR2 > > last message repeated 10 times Mar 26 22:05:59 UFR2 last message > > repeated 20 times Mar 26 22:07:10 UFR2 last message repeated 20 times > > Mar 26 22:29:00 UFR2 last message repeated 64 times Mar 27 00:47:40 UFR2 > > last message repeated 15 times Mar 27 01:42:41 UFR2 last message > > repeated 95 times Mar 27 02:15:57 UFR2 last message repeated 90 times > > Mar 27 02:27:13 UFR2 last message repeated 45 times Mar 27 03:14:08 UFR2 > > last message repeated 95 times Mar 27 04:26:10 UFR2 last message > > repeated 2 times Mar 27 06:11:35 UFR2 last message repeated 45 times Mar > > 27 06:20:20 UFR2 last message repeated 15 times Mar 27 06:20:20 UFR2 > > last message repeated 12 times Mar 27 06:27:53 UFR2 kernel: BUG: soft > > lockup detected on CPU#3! > > Mar 27 06:27:53 UFR2 kernel: [] softlockup_tick+0x9e/0xac Mar > > 27 06:27:53 UFR2 kernel: [] update_process_times+0x3b/0x5e > > Mar 27 06:27:53 UFR2 kernel: [] > > smp_apic_timer_interrupt+0x6c/0x7a > > Mar 27 06:27:53 UFR2 kernel: [] > > apic_timer_interrupt+0x28/0x30 Mar 27 06:27:53 UFR2 kernel: > > [] generic_fillattr+0x75/0xa8 Mar 27 06:27:53 UFR2 kernel: > > [] cifs_getattr+0x1e/0x2b [cifs] Mar 27 06:27:53 UFR2 kernel: > > [] cifs_getattr+0x0/0x2b [cifs] Mar 27 06:27:53 UFR2 kernel: > > [] vfs_getattr+0x21/0x30 Mar 27 06:27:53 UFR2 kernel: > > [] vfs_fstat+0x22/0x31 Mar 27 06:27:53 UFR2 kernel: > > [] sys_fstat64+0xf/0x23 Mar 27 06:27:53 UFR2 kernel: > > [] sys_open+0x1a/0x1c Mar 27 06:27:53 UFR2 kernel: > > [] sysenter_past_esp+0x5d/0x81 Mar 27 06:27:53 UFR2 kernel: > > [] xdr_xcode_array2+0x307/0x506 Mar 27 06:27:53 UFR2 kernel: > > You didn't tell us what kernel version you're running. > > Hanging in generic_fillattr: i_size_read() got stuck. This is because CIFS > doesn't correctly hold i_mutex across i_size_write(). > > Steve, where are we up to with the fixes for that? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] i386: add command line option "local_apic_timer_c2_ok"
"Langsdorf, Mark" <[EMAIL PROTECTED]> writes: > > > If we really care about using the LAPIC timer on systems with deeper > > > than C1 support, the only alternative seems to be to test > > > if it actually works or not at boot and run-time. > > > Otherwise, we wait for future hardware with guaranteed > > > not to break under any (BIOS) conditions ships, and check for that. > > > > > > Based on what I read of the HP nx6325 where the LAPIC timer > > > is breaking C1, AMD is in the same boat. > > > > The nx6325 (Turion 64 X2) exports only C1. > > I'm not sure how the conclusion was drawn that it has > > a broken lapic timer as reflected in the "nolapic_timer" patch: > > If both cores goes into C1 at the same time, the chipset > can move the processor into a C3 like state called C1e. ... and that seems to break the local APIC timer. > AMD can craft a patch to sort this out as soon as we have > an idea what the framework is going to look like. Just a snippet to detect it would be great. Then the dmi scan could be removed and replaced with that. This would be a 2.6.21 candidate imho over the DMI hack. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB: on suspend to ram/disk all usb devices are replugged
On Thu, 29 Mar 2007, Mark Lord wrote: > Maxim Levitsky wrote: > > Hi, > > I noticed that after suspend/resume cycle all my usb devices are > > unplugged/replugged by uhci driver. > > While it is not that big problem to me, that can be a real problem if a > > device is a flash card with mounted > > file-system, because disappeared device will cause file-system corruption. > > Mmm.. this sounds really bad -- I wonder what happens if the rootfs is on USB > ? The system crashes as soon as it resumes. As you might expect. > With older kernels, things just "worked" this way. Has it now been broken ?? No; it has never worked. Your memory of how older kernels behaved is wrong. Alan Stern P.S.: Help is on the way. I will soon submit a patch to help improve the situation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB: on suspend to ram/disk all usb devices are replugged
Alan Stern wrote: On Thu, 29 Mar 2007, Mark Lord wrote: Mmm.. this sounds really bad -- I wonder what happens if the rootfs is on USB ? The system crashes as soon as it resumes. As you might expect. With older kernels, things just "worked" this way. Has it now been broken ?? No; it has never worked. Your memory of how older kernels behaved is wrong. Ah. Perhaps my Kubuntu system was using a FreeBSD kernel under the hood back then. It really did work for me, back about 2 years ago when last attempted. But then suspend/resume (RAM) has always worked here on every notebook I've ever used -- apparently not the norm for others. I just expect more. P.S.: Help is on the way. I will soon submit a patch to help improve the situation. That would be very good to see. -ml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix dependency generation
>>> Randy Dunlap <[EMAIL PROTECTED]> 29.03.07 17:39 >>> >> --- linux-2.6.21-rc5/scripts/basic/fixdep.c 2007-02-04 19:44:54.0 >> +0100 >> +++ 2.6.21-rc5-fixdep-mod/scripts/basic/fixdep.c 2007-03-29 >> 11:11:10.0 +0200 >> @@ -29,8 +29,7 @@ >> * option which is mentioned in any of the listed prequisites. >> * >> * To be exact, split-include populates a tree in include/config/, >> - * e.g. include/config/his/driver.h, which contains the #define/#undef >> - * for the CONFIG_HIS_DRIVER option. > >I don't see why you deleted the line above. Because it is no longer true. These files are empty as of 2.6.18. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[QUESTION] check for mem in slab
Hi list,
in file mm/slab.c and routine kmem_cache_init() I found there
is no checking for allocated memory on line:
/* 4) Replace the bootstrap head arrays */
{
struct array_cache *ptr;
ptr = kmalloc(sizeof(struct arraycache_init), GFP_KERNEL);
--> no check for ptr == NULL <--
local_irq_disable();
BUG_ON(cpu_cache_get(&cache_cache) != &initarray_cache.cache);
memcpy(ptr, cpu_cache_get(&cache_cache),
sizeof(struct arraycache_init));
...
is that OK? or it's a bug?
Cyrill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21-rc1 and 2.6.21-rc2 kwin dies silently
Sid Boyce wrote:
Eric W. Biederman wrote:
Sid I think I have found the problem. Could you try the following
patch. I believe I accidentally switched the sense of a test
diff --git a/kernel/exit.c b/kernel/exit.c
index f132349..b55ed4c 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -790,7 +790,7 @@ static void exit_notify(struct task_struct *tsk)
pgrp = task_pgrp(tsk);
if ((task_pgrp(t) != pgrp) &&
-(task_session(t) != task_session(tsk)) &&
+(task_session(t) == task_session(tsk)) &&
will_become_orphaned_pgrp(pgrp, tsk) &&
has_stopped_jobs(pgrp)) {
__kill_pgrp_info(SIGHUP, SEND_SIG_PRIV, pgrp);
AOK I shall apply to 2.6.21-rc5-git4 and test.
Regards
Sid.
Thanks, the patch works - tested on 2.6.21-rc5-git4.
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Student Project Ideas
Russ Meyerriecks wrote: > If anybody has any bug fixes or features maybe they never got > around to, http://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED has 1504 hits right now. > and would be suitable for this situation, This may be a problem. -- 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: [PATCH] fix dependency generation
On Thu, 29 Mar 2007 17:06:24 +0100 Jan Beulich wrote: > >>> Randy Dunlap <[EMAIL PROTECTED]> 29.03.07 17:39 >>> > >> --- linux-2.6.21-rc5/scripts/basic/fixdep.c2007-02-04 > >> 19:44:54.0 +0100 > >> +++ 2.6.21-rc5-fixdep-mod/scripts/basic/fixdep.c 2007-03-29 > >> 11:11:10.0 +0200 > >> @@ -29,8 +29,7 @@ > >> * option which is mentioned in any of the listed prequisites. > >> * > >> * To be exact, split-include populates a tree in include/config/, > >> - * e.g. include/config/his/driver.h, which contains the #define/#undef > >> - * for the CONFIG_HIS_DRIVER option. > > > >I don't see why you deleted the line above. > > Because it is no longer true. These files are empty as of 2.6.18. We seem to be talking about different lines above. Yes, the files are empty, but they are named based on the CONFIG_symbol name, which is what I was trying to get at. So how about a comment like this: * To be exact, split-include populates a tree in include/config/, * e.g., include/config/sysctl/syscall.h, * for the CONFIG_SYSCTL_SYSCALL option, when that option * is enabled (=y or =m). --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v2] Fixes and cleanups for earlyprintk aka boot console.
On 15-Mar-07, John Stoffel wrote: > Would this explain why recent version of GDM don't find the keyboard > properly when you boot with a kernel command line of: > >kernel ... console=tty0 console=ttyS1,96008N1 > > until you stop and restart GDM? This was filed under Debian bug > #406457 (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406457) > and I could never figure it out until I removed my serial console line > at one point. Try changing the order of the console= parameters: kernel ... console=ttyS1,96008N1 console=tty0 Some time ago I understood what this does. Nowadays I can only remember that this makes both the serial console and directly attached screen/keyboard console work most of the time. FWIW, tty0 becomes the so-called "preferred console". -- Olaf Dabrunz (od/odabrunz), SUSE Linux Products GmbH, Nürnberg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix 82875 PCI setup
From: John Feeney <[EMAIL PROTECTED]>
The 82875 EDAC driver enables an otherwise-hidden PCI device, but
doesn't register it as a PCI device properly. Therefore, the device
list in /proc/bus/pci/devices is different than the tree in
/sys/bus/pci. This usually manifests as the X server failing to start,
since it expects the two lists to be consistent.
Signed-off-by: Adam Jackson <[EMAIL PROTECTED]>
--- linux-2.6.18.noarch/drivers/edac/i82875p_edac.c~
+++ linux-2.6.18.noarch/drivers/edac/i82875p_edac.c
@@ -261,10 +261,6 @@ static void i82875p_check(struct mem_ctl
i82875p_process_error_info(mci, &info, 1);
}
-#ifdef CONFIG_PROC_FS
-extern int pci_proc_attach_device(struct pci_dev *);
-#endif
-
/* Return 0 on success or 1 on failure. */
static int i82875p_setup_overfl_dev(struct pci_dev *pdev,
struct pci_dev **ovrfl_pdev, void __iomem **ovrfl_window)
@@ -287,17 +283,12 @@ static int i82875p_setup_overfl_dev(stru
if (dev == NULL)
return 1;
+
+ pci_bus_add_device(dev);
}
*ovrfl_pdev = dev;
-#ifdef CONFIG_PROC_FS
- if ((dev->procent == NULL) && pci_proc_attach_device(dev)) {
- i82875p_printk(KERN_ERR, "%s(): Failed to attach overflow "
- "device\n", __func__);
- return 1;
- }
-#endif /* CONFIG_PROC_FS */
if (pci_enable_device(dev)) {
i82875p_printk(KERN_ERR, "%s(): Failed to enable overflow "
"device\n", __func__);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
apm platform device cleanup
In checking a "make allmodconfig" I noticed that the apm device (arch/i386/kernel/apm.c) is still using the old pm_send_all setup - I know the fix is to add suspend/resume hooks but the apm code hasn't been touched since 2002 and isn't using the new device API (it doesn't even register, AFAICT, a platform_device struct) Beyond needing to add that, are there any suggestions ? DRH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.21-rc5] MSI: read-flush MSI-X table (rev 2)
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks they're disabled,
and in interrupts being sent to stale vectors after rebalancing.
This patch performs a read flush after writes to the MSI-X table for
mask/unmask and rebalancing operations.
This patch has been validated with (unreleased) network hardware which
uses MSI-X.
Revised with input from Eric Biederman.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c
linux-2.6.21-rc5/arch/i386/kernel/io_apic.c
--- linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c 2007-03-28
10:05:22.0 -0700
+++ linux-2.6.21-rc5/arch/i386/kernel/io_apic.c 2007-03-28 10:19:14.0
-0700
@@ -2584,6 +2584,7 @@ static void set_msi_irq_affinity(unsigne
msg.address_lo |= MSI_ADDR_DEST_ID(dest);
write_msi_msg(irq, &msg);
+ msix_flush_writes(irq);
irq_desc[irq].affinity = mask;
}
#endif /* CONFIG_SMP */
diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/ia64/kernel/msi_ia64.c
linux-2.6.21-rc5/arch/ia64/kernel/msi_ia64.c
--- linux-2.6.21-rc5-clean/arch/ia64/kernel/msi_ia64.c 2007-03-28
10:05:22.0 -0700
+++ linux-2.6.21-rc5/arch/ia64/kernel/msi_ia64.c2007-03-28
09:34:27.0 -0700
@@ -60,6 +60,7 @@ static void ia64_set_msi_irq_affinity(un
msg.address_lo = addr;
write_msi_msg(irq, &msg);
+ msix_flush_writes(irq);
irq_desc[irq].affinity = cpu_mask;
}
#endif /* CONFIG_SMP */
diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/ia64/sn/kernel/msi_sn.c
linux-2.6.21-rc5/arch/ia64/sn/kernel/msi_sn.c
--- linux-2.6.21-rc5-clean/arch/ia64/sn/kernel/msi_sn.c 2007-03-28
10:05:22.0 -0700
+++ linux-2.6.21-rc5/arch/ia64/sn/kernel/msi_sn.c 2007-03-28
09:34:06.0 -0700
@@ -204,6 +204,7 @@ static void sn_set_msi_irq_affinity(unsi
msg.address_lo = (u32)(bus_addr & 0x);
write_msi_msg(irq, &msg);
+ msix_flush_writes(irq);
irq_desc[irq].affinity = cpu_mask;
}
#endif /* CONFIG_SMP */
diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/x86_64/kernel/io_apic.c
linux-2.6.21-rc5/arch/x86_64/kernel/io_apic.c
--- linux-2.6.21-rc5-clean/arch/x86_64/kernel/io_apic.c 2007-03-28
10:05:22.0 -0700
+++ linux-2.6.21-rc5/arch/x86_64/kernel/io_apic.c 2007-03-28
10:18:52.0 -0700
@@ -1956,6 +1956,7 @@ static void set_msi_irq_affinity(unsigne
msg.address_lo |= MSI_ADDR_DEST_ID(dest);
write_msi_msg(irq, &msg);
+ msix_flush_writes(irq);
irq_desc[irq].affinity = mask;
}
#endif /* CONFIG_SMP */
diff -urpN -X dontdiff linux-2.6.21-rc5-clean/drivers/pci/msi.c
linux-2.6.21-rc5/drivers/pci/msi.c
--- linux-2.6.21-rc5-clean/drivers/pci/msi.c2007-03-28 10:05:24.0
-0700
+++ linux-2.6.21-rc5/drivers/pci/msi.c 2007-03-28 09:21:34.0 -0700
@@ -68,6 +68,29 @@ static void msix_set_enable(struct pci_d
}
}
+void msix_flush_writes(unsigned int irq)
+{
+ struct msi_desc *entry;
+
+ entry = get_irq_msi(irq);
+ BUG_ON(!entry || !entry->dev);
+ switch (entry->msi_attrib.type) {
+ case PCI_CAP_ID_MSI:
+ /* nothing to do */
+ break;
+ case PCI_CAP_ID_MSIX:
+ {
+ int offset = entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
+ PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET;
+ readl(entry->mask_base + offset);
+ break;
+ }
+ default:
+ BUG();
+ break;
+ }
+}
+
static void msi_set_mask_bit(unsigned int irq, int flag)
{
struct msi_desc *entry;
@@ -186,11 +209,13 @@ void write_msi_msg(unsigned int irq, str
void mask_msi_irq(unsigned int irq)
{
msi_set_mask_bit(irq, 1);
+ msix_flush_writes(irq);
}
void unmask_msi_irq(unsigned int irq)
{
msi_set_mask_bit(irq, 0);
+ msix_flush_writes(irq);
}
static int msi_free_irq(struct pci_dev* dev, int irq);
diff -urpN -X dontdiff linux-2.6.21-rc5-clean/include/linux/msi.h
linux-2.6.21-rc5/include/linux/msi.h
--- linux-2.6.21-rc5-clean/include/linux/msi.h 2007-03-28 10:05:25.0
-0700
+++ linux-2.6.21-rc5/include/linux/msi.h2007-03-28 09:21:51.0
-0700
@@ -12,6 +12,7 @@ extern void mask_msi_irq(unsigned int ir
extern void unmask_msi_irq(unsigned int irq);
extern void read_msi_msg(unsigned int irq, struct msi_msg *msg);
extern void write_msi_msg(unsigned int irq, struct msi_msg *msg);
+extern void msix_flush_writes(unsigned int irq);
struct msi_desc {
struct {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More major
Re: 2.6.21-rc5-mm2
On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/ > > > - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU > scheduler has been added. make allyesconfig - didn't give me a clean build :( (not crucial for me to get it right -- but FYI). Thanks, Badari CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h CC drivers/net/e100.o LD drivers/net/wireless/built-in.o CC drivers/net/epic100.o CC drivers/net/sis190.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_chip_switch_radio_on' CC drivers/net/sis900.o drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_dma_tx_suspend' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_dma_tx_suspend' changed from 141 in drivers/net/wireless/bcm43xx/built-in.o to 108 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_tail' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_pio_tx_resume' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_pio_tx_resume' changed from 101 in drivers/net/wireless/bcm43xx/built-in.o to 89 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_phy_xmitpower' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_phy_xmitpower' changed from 1312 in drivers/net/wireless/bcm43xx/built-in.o to 1126 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_chip_disable_hwint' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_shm_write16' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_shm_write16' changed from 127 in drivers/net/wireless/bcm43xx/built-in.o to 218 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_usb_tx' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_raw_phy_unlock' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here ld: Warning: size of symbol `bcm43xx_raw_phy_unlock' changed from 238 in drivers/net/wireless/bcm43xx/built-in.o to 168 in drivers/net/wireless/mac80211/built-in.o drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_switch_radio_off' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `bcm43xx_dmacontroller_base' drivers/net/wireless/bcm43xx/built-in.o:drivers/net/wireless/bcm43xx/bcm43xx_main.c:696: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43xx_main.c:398: multiple definition of `zd_chip_control_leds' drivers/net/wireless/zd1211rw/built-in.o:drivers/net/wireless/zd1211rw/zd_chip.c:89: first defined here drivers/net/wireless/mac80211/built-in.o: In function `bcm43xx_conf_tx': drivers/net/wireless/mac80211/bcm43xx/bcm43x
utrace, RCU and ia64
Hi, Roland, Andrew. Something really sick is going on with combination of utrace, RCU and ia64. Below are quickly reproducable oops happenning on 8-way SMP, my lame-o attempts to decode it, and test program itself. I checked 2.6.21-rc5 which was OK, 2.6.21-rc5 + linux-2.6.21-current-utrace.patch which was bad, and 2.6.21-rc5-mm1 which was also bad. Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b6b expl_ptratt[4391]: Oops 11012296146944 [1] Modules linked in: autofs4 hidp rfcomm l2cap bluetooth sunrpc 8021q bridge ipv6 xt_length ipt_ttl xt_tcpmss iptable_mangle iptable_filter xt_multiport xt_limit ipt_tos ipt_REJECT ip_tables x_tables vfat fat button parport_pc lp parport sg e100 e1000 mii shpchp ide_cd cdrom dm_snapshot dm_zero dm_mirror dm_mod mptsas mptscsih mptbase scsi_transport_sas sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 4391, CPU 4, comm: expl_ptratt psr : 121008026018 ifs : 8389 ip : []Not tainted ip is at __rcu_process_callbacks+0x3e1/0x660 unat: pfs : 0389 rsc : 0003 rnat: bsps: pr : 00555965 ldrs: ccv : fpsr: 0009804c0270033f csd : ssd : b0 : a001000948a0 b6 : a001000d9ee0 b7 : a00100010080 f6 : 1003e6b6b6b6b6b6b6b6b f7 : 1003e0334 f8 : 1003e1680 f9 : 1003e1680 f10 : 1003e0048 f11 : 1003e0050 r1 : a00100d130a0 r2 : 0003 r3 : 0001 r8 : e00468054028 r9 : e00468054000 r10 : 0004 r11 : a0010095a880 r12 : e00467bcfc30 r13 : e00467bc8000 r14 : e004681452e8 r15 : e00107f77940 r16 : e00107f77978 r17 : 0002 r18 : 000a r19 : e00467bc8c34 r20 : 0020 r21 : e00108bb2cac r22 : e00108a8cdc8 r23 : 0002 r24 : e00165d8 r25 : 6b6b6b6b6b6b6b6b r26 : e00108bb2cc0 r27 : 0002 r28 : 0002 r29 : 4000 r30 : 4000 r31 : 0011 Call Trace: [] show_stack+0x40/0xa0 sp=e00467bcf7c0 bsp=e00467bc9040 [] show_regs+0x840/0x880 sp=e00467bcf990 bsp=e00467bc8fe0 [] die+0x1c0/0x2a0 sp=e00467bcf990 bsp=e00467bc8f98 [] ia64_do_page_fault+0x8d0/0xa00 sp=e00467bcf9b0 bsp=e00467bc8f48 [] ia64_leave_kernel+0x0/0x280 sp=e00467bcfa60 bsp=e00467bc8f48 [] __rcu_process_callbacks+0x3e0/0x660 sp=e00467bcfc30 bsp=e00467bc8f00 [] rcu_process_callbacks+0x40/0xa0 sp=e00467bcfc30 bsp=e00467bc8ee0 [] tasklet_action+0x1d0/0x340 sp=e00467bcfc30 bsp=e00467bc8eb8 [] __do_softirq+0xf0/0x240 sp=e00467bcfc30 bsp=e00467bc8e40 [] do_softirq+0x70/0xc0 sp=e00467bcfc30 bsp=e00467bc8dd8 [] irq_exit+0x80/0xa0 sp=e00467bcfc30 bsp=e00467bc8dc0 [] ia64_handle_irq+0x250/0x280 sp=e00467bcfc30 bsp=e00467bc8d90 [] ia64_leave_kernel+0x0/0x280 sp=e00467bcfc30 bsp=e00467bc8d90 [] _spin_unlock_irqrestore+0x40/0x80 sp=e00467bcfe00 bsp=e00467bc8d60 [] wait_task_inactive+0x90/0x120 sp=e00467bcfe00 bsp=e00467bc8d38 [] sys_ptrace+0x890/0x1180 sp=e00467bcfe10 bsp=e00467bc8cb0 [] ia64_trace_syscall+0xd0/0x110 sp=e00467bcfe30 bsp=e00467bc8cb0 [] __start_ivt_text+0x00010620/0x400 sp=e00467bd bsp=e00467bc8cb0 Kernel panic - not syncing: Aiee, killing interrupt handler! - a001000944a0 <__rcu_process_callbacks>: ... a00100094830: nop.m 0x0 a00100094836: cmp.eq p8,p9=0,r39;;# while (list) a0010009483c: nop.i 0x0 a00100094840: (p09) mov r35=1 a00100094846: nop.m 0x0 a0010009484c: (p09) br.cond.dptk.few a001000948e0 <__rcu_process_callbacks+0x440> a00100094850: nop.m 0x0 a00100094856: nop.i 0x0 a0010009485c: br.few a00100094ae0 <__rcu_process_callbacks+0x640> a00100094860: nop.m 0x0 a00100094866: ld8 r34=[r14],8 # r34 = next = list->next # r14 = &list->func a0010009486c: nop.i 0x0;; a00100094870: lfetch [r34]
Re: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table (rev 2)
Mitch Williams <[EMAIL PROTECTED]> writes:
> This patch fixes a kernel bug which is triggered when using the
> irqbalance daemon with MSI-X hardware.
>
> Because both MSI-X interrupt messages and MSI-X table writes are posted,
> it's possible for them to cross while in-flight. This results in
> interrupts being received long after the kernel thinks they're disabled,
> and in interrupts being sent to stale vectors after rebalancing.
>
> This patch performs a read flush after writes to the MSI-X table for
> mask/unmask and rebalancing operations.
>
> This patch has been validated with (unreleased) network hardware which
> uses MSI-X.
>
> Revised with input from Eric Biederman.
Do we still need the flush the set affinity routines?
Shouldn't flush in mask and unmask should now be enough?
>
> Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
>
> diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c
> linux-2.6.21-rc5/arch/i386/kernel/io_apic.c
> --- linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c 2007-03-28
> 10:05:22.0 -0700
> +++ linux-2.6.21-rc5/arch/i386/kernel/io_apic.c 2007-03-28 10:19:14.0
> -0700
> @@ -2584,6 +2584,7 @@ static void set_msi_irq_affinity(unsigne
> msg.address_lo |= MSI_ADDR_DEST_ID(dest);
>
> write_msi_msg(irq, &msg);
> + msix_flush_writes(irq);
> irq_desc[irq].affinity = mask;
> }
> #endif /* CONFIG_SMP */
> diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/ia64/kernel/msi_ia64.c
> linux-2.6.21-rc5/arch/ia64/kernel/msi_ia64.c
> --- linux-2.6.21-rc5-clean/arch/ia64/kernel/msi_ia64.c 2007-03-28
> 10:05:22.0 -0700
> +++ linux-2.6.21-rc5/arch/ia64/kernel/msi_ia64.c 2007-03-28 09:34:27.0
> -0700
> @@ -60,6 +60,7 @@ static void ia64_set_msi_irq_affinity(un
> msg.address_lo = addr;
>
> write_msi_msg(irq, &msg);
> + msix_flush_writes(irq);
> irq_desc[irq].affinity = cpu_mask;
> }
> #endif /* CONFIG_SMP */
> diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/ia64/sn/kernel/msi_sn.c
> linux-2.6.21-rc5/arch/ia64/sn/kernel/msi_sn.c
> --- linux-2.6.21-rc5-clean/arch/ia64/sn/kernel/msi_sn.c 2007-03-28
> 10:05:22.0 -0700
> +++ linux-2.6.21-rc5/arch/ia64/sn/kernel/msi_sn.c 2007-03-28
> 09:34:06.0
> -0700
> @@ -204,6 +204,7 @@ static void sn_set_msi_irq_affinity(unsi
> msg.address_lo = (u32)(bus_addr & 0x);
>
> write_msi_msg(irq, &msg);
> + msix_flush_writes(irq);
> irq_desc[irq].affinity = cpu_mask;
> }
> #endif /* CONFIG_SMP */
> diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/x86_64/kernel/io_apic.c
> linux-2.6.21-rc5/arch/x86_64/kernel/io_apic.c
> --- linux-2.6.21-rc5-clean/arch/x86_64/kernel/io_apic.c 2007-03-28
> 10:05:22.0 -0700
> +++ linux-2.6.21-rc5/arch/x86_64/kernel/io_apic.c 2007-03-28
> 10:18:52.0
> -0700
> @@ -1956,6 +1956,7 @@ static void set_msi_irq_affinity(unsigne
> msg.address_lo |= MSI_ADDR_DEST_ID(dest);
>
> write_msi_msg(irq, &msg);
> + msix_flush_writes(irq);
> irq_desc[irq].affinity = mask;
> }
> #endif /* CONFIG_SMP */
> diff -urpN -X dontdiff linux-2.6.21-rc5-clean/drivers/pci/msi.c
> linux-2.6.21-rc5/drivers/pci/msi.c
> --- linux-2.6.21-rc5-clean/drivers/pci/msi.c 2007-03-28 10:05:24.0
> -0700
> +++ linux-2.6.21-rc5/drivers/pci/msi.c2007-03-28 09:21:34.0
> -0700
> @@ -68,6 +68,29 @@ static void msix_set_enable(struct pci_d
> }
> }
>
> +void msix_flush_writes(unsigned int irq)
> +{
> + struct msi_desc *entry;
> +
> + entry = get_irq_msi(irq);
> + BUG_ON(!entry || !entry->dev);
> + switch (entry->msi_attrib.type) {
> + case PCI_CAP_ID_MSI:
> + /* nothing to do */
> + break;
> + case PCI_CAP_ID_MSIX:
> + {
> + int offset = entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
> + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET;
> + readl(entry->mask_base + offset);
> + break;
> + }
> + default:
> + BUG();
> + break;
> + }
> +}
> +
> static void msi_set_mask_bit(unsigned int irq, int flag)
> {
> struct msi_desc *entry;
> @@ -186,11 +209,13 @@ void write_msi_msg(unsigned int irq, str
> void mask_msi_irq(unsigned int irq)
> {
> msi_set_mask_bit(irq, 1);
> + msix_flush_writes(irq);
> }
>
> void unmask_msi_irq(unsigned int irq)
> {
> msi_set_mask_bit(irq, 0);
> + msix_flush_writes(irq);
> }
>
> static int msi_free_irq(struct pci_dev* dev, int irq);
> diff -urpN -X dontdiff linux-2.6.21-rc5-clean/include/linux/msi.h
> linux-2.6.21-rc5/include/linux/msi.h
> --- linux-2.6.21-rc5-clean/include/linux/msi.h 2007-03-28 10:05:25.0
> -0700
> +++ linux-2.6.21-rc5/include/linux/msi.h 2007-03-28 09:21:51.0 -0700
> @@ -12,6 +12,7 @@ extern void mask_msi_irq(unsigned int ir
> extern void unmask_msi_irq(unsigned int irq);
> extern void read_msi_msg(unsigned int irq, struct
Re: [PATCH] fix amd64-agp aperture validation
On Thu, Mar 29, 2007 at 08:58:00AM +0100, Jan Beulich wrote:
> Under CONFIG_DISCONTIGMEM, assuming that a !pfn_valid() implies all
> subsequent pfn-s are also invalid is wrong. Thus replace this by
> explicitly checking against the E820 map.
>
> Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
> Acked-by: Mark Langsdorf <[EMAIL PROTECTED]>
>
> --- linux-2.6.21-rc5/drivers/char/agp/amd64-agp.c 2007-03-26
> 15:20:14.0 +0200
> +++ 2.6.21-rc5-amd64-agp/drivers/char/agp/amd64-agp.c 2007-03-28
> 15:20:49.0 +0200
> @@ -14,6 +14,7 @@
> #include
> #include
> #include /* PAGE_SIZE */
> +#include
> #include
> #include "agp.h"
>
> @@ -259,7 +260,6 @@ static const struct agp_bridge_driver am
> /* Some basic sanity checks for the aperture. */
> static int __devinit aperture_valid(u64 aper, u32 size)
> {
> - u32 pfn, c;
> if (aper == 0) {
> printk(KERN_ERR PFX "No aperture\n");
> return 0;
> @@ -272,14 +272,9 @@ static int __devinit aperture_valid(u64
> printk(KERN_ERR PFX "Aperture out of bounds\n");
> return 0;
> }
> - pfn = aper >> PAGE_SHIFT;
> - for (c = 0; c < size/PAGE_SIZE; c++) {
> - if (!pfn_valid(pfn + c))
> - break;
> - if (!PageReserved(pfn_to_page(pfn + c))) {
> - printk(KERN_ERR PFX "Aperture pointing to RAM\n");
> - return 0;
> - }
> + if (e820_any_mapped(aper, aper + size, E820_RAM)) {
> + printk(KERN_ERR PFX "Aperture pointing to RAM\n");
> + return 0;
> }
This pretty much duplicates the checking done in
arch/x86-64/kernel/aperture.c:aperture_valid(), with slight variations
(e.g., 32MB vs. 64MB aperture size). Should these two functions be
consolidated?
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux page cache issue?
Hi Jan, Many thanks for your kind reply. I know we can use device inode's radix tree to achieve the same goal. The only downside could be: First, by default, Linux will not add the data pages into that radix tree. Only when a file is opened in O_DIRECT, the data pages will be put into dev's radix tree. Moreover, if the partition is big, I am not sure whether the lookup overhead is an issue. So it might need some optimization. Can you elaborate more about the aliasing issues mentioned in your email? I do have some mechanisms to handle the following situation: suppose two files share same data blocks. Now two processes open the two files separately. If one process writes a file, the other file will be affected. Is this the aliasing issue you referred to? Thanks, xin On 3/29/07, Jan Kara <[EMAIL PROTECTED]> wrote: Hello, > Now I want to explain the problem that leads me to explore the Linux > disk cache management. This is actually from my project. In a file > system I am working on, two files may have different inodes, but share > the same data blocks. Of course additional block-level reference > counting and copy-on-write mechanisms are needed to prevent operations > on one file from disrupting the other file. But the point is, the two > files share the same data blocks. > > I hope that consequential reads to the two files can benefit from disk > cache, since they have the same data blocks. But I noticed that Linux > splits disk buffer cache into many small parts and associate a file's > data with its mapping object. Linux determines whether a data page is > cached or not by lookup the file's mapping radix tree. So this is a > per-file radix tree. This design obviously makes each tree smaller and > faster to look up. But this design eliminates the possibility of > sharing disk cache across two files. For example, if a process reads > file 2 right after file 1 (both file 1 and 2 share the same data block > set). Even if the data blocks are already loaded in memory, but they > can only be located via file 1's mapping object. When Linux reads file > 2, it still think the data is not present in memory. So the process > still needs to load the data from disk again. Actually, there is one inode - the device inode - whose mapping can contain all the blocks of the filesystem. That is basically the radix tree you are looking for. ext3 for example uses it for accessing its metadata (indirect blocks etc.). But you have to be really careful to avoid aliasing issues and such when you'd like to map copies of those pages into mappings of several different inodes (BTW ext3cow filesystem may be interesting for you www.ext3cow.com). Honza > On 3/28/07, Dave Kleikamp <[EMAIL PROTECTED]> wrote: > >On Wed, 2007-03-28 at 02:45 -0400, Xin Zhao wrote: > >> Hi, > >> > >> If a Linux process opens and reads a file A, then it closes the file. > >> Will Linux keep the file A's data in cache for a while in case another > >> process opens and reads the same in a short time? I think that is what > >> I heard before. > > > >Yes. > > > >> But after I digged into the kernel code, I am confused. > >> > >> When a process closes the file A, iput() will be called, which in turn > >> calls the follows two functions: > >> iput_final()->generic_drop_inode() > > > >A comment from the top of fs/dcache.c: > > > >/* > > * Notes on the allocation strategy: > > * > > * The dcache is a master of the icache - whenever a dcache entry > > * exists, the inode will always exist. "iput()" is done either when > > * the dcache entry is deleted or garbage collected. > > */ > > > >Basically, as long a a dentry is present, iput_final won't be called on > >the inode. > > > >> But from the following calling chain, we can see that file close will > >> eventually lead to evict and free all cached pages. Actually in > >> truncate_complete_page(), the pages will be freed. This seems to > >> imply that Linux has to re-read the same data from disk even if > >> another process B read the same file right after process A closes the > >> file. That does not make sense to me. > >> > >> /***calling chain ***/ > >> generic_delete_inode/generic_forget_inode()-> > >> truncate_inode_pages()->truncate_inode_pages_range()-> > >> truncate_complete_page()->remove_from_page_cache()-> > >> __remove_from_page_cache()->radix_tree_delete() > >> > >> Am I missing something? Can someone please provide some advise? > >> > >> Thanks a lot > >> -x > > > >Shaggy > >-- > >David Kleikamp > >IBM Linux Technology Center > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAI
Re: [Bug 8255] Frequency Scaling not working properly using powernow-k7
Dave, [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8255 Okay. I tracked down the problem with git. Here is what is the submission that causes the problem: solaris linux-git # git bisect good 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e is first bad commit commit 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e Author: Dave Jones <[EMAIL PROTECTED]> Date: Wed Nov 22 20:42:01 2006 -0500 [PATCH] Correct bound checking from the value returned from _PPC method. The above commit seems to be the culprit behind this 2.6.19 regression, which is still present as of 2.6.21-rc3 (so it's not the earlier issue found by Ingo). Any ideas? Thanks, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interface for the new fallocate() system call
On Thu, Mar 29, 2007 at 05:21:26PM +0530, Amit K. Arora wrote: >int fallocate(int fd, loff_t offset, loff_t len, int mode) Right now there are only two possible values for mode --- it's not clear what additional values there will be in the future. How about two syscalls? If we decide later on we need something more complicated we can revisit this and *THEN* add another system call which may end up being a superset of the other two. I know that sounds somewhat icky but: * it's fairly simple * we get nice argument handling on all arches by dropping u32 mode (don't we?) * syscalls don't really cost a lot to keep about, they do cost in terms on maintenance though, but in this case i don't see it being all that much of a problem * IMO badly/over designed syscalls are going to be a bigger problem long term Given that *NO* single fs in mainline right now can *reliably* use this functionality for a while maybe whatever solution people come up with next should sit in -mm for a while? At least that gives people exposure to it and a chance to make some changes as once it's merged to mainline it's pretty hard to change. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions
On Thu, 29 Mar 2007, Maxim wrote:
> On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
> >
> > (Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not
> > to use the HPET, and set hpet_virt_address to NULL?)
>
> This is done here
>
> out_nohpet:
> iounmap(hpet_virt_address);
> hpet_virt_address = NULL;
No, that only clears hpet_virt_address, and thus makes all subsequent
"hpet_readl()" and "hpet_writel()" calls oops.
But it doesn't actually *tell* anybody that the HPET is disabled, so if
you later on do
if (is_hpet_capable()) {
time = hpet_readl(..);
..
you will just Oops!
So as far as I can see, even with your latest patch, if hpet_enable()
fails (and triggers the "goto out_nohpet" cases), you'll just oops
immediately when you try to suspend/resume the HPET.
THAT was what I meant - when we clear hpet_virt_address, we should also
tell all potential subsequent users that the HPET is not there!
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
