[PATCH 2.6.11] fix call kobject_get_path() with zero kobject argument in drivers/base/class.c
The attached patch fix call kobject_get_path() with zero kobject argument.
This situation take place for example in unexpected disconnection of USB
devices such as GPRS modem.
(in my case it is Motorola C350 mobile phone modem)
Mar 6 00:55:52 toshiba kernel: 6usb 2-1: USB disconnect, address 4
Mar 6 00:55:53 toshiba kernel: 1Unable to handle kernel NULL pointer
dereference at virtual address
Mar 6 00:55:53 toshiba kernel: printing eip:
Mar 6 00:55:53 toshiba kernel: c0255299
Mar 6 00:55:53 toshiba kernel: *pde =
Mar 6 00:55:53 toshiba kernel: Oops: [#1]
Mar 6 00:55:53 toshiba kernel: PREEMPT
Mar 6 00:55:53 toshiba kernel: Modules linked in: ppp_deflate zlib_deflate
bsd_comp ppp_async crc_ccitt ppp_generic slhc i
pt_REJECT ipt_LOG iptable_filter ipt_MASQUERADE iptable_nat ip_conntrack
ip_tables pktcdvd snd_pcm_oss snd_mixer_oss rtc pcs
pkr usbhid intel_agp intelfb uhci_hcd ehci_hcd i8xx_tco 8250_pci 8250
serial_core snd_intel8x0m eepro100 mii evdev pcmcia ye
nta_socket rsrc_nonstatic pcmcia_core nls_koi8_r ntfs cdc_acm usb_storage
usbkbd usbmouse usbcore msr cpuid sg sd_mod scsi_m
od dummy ide_cd cdrom snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd
soundcore snd_page_alloc agpgart
Mar 6 00:55:53 toshiba kernel: CPU:0
Mar 6 00:55:53 toshiba kernel: EIP:0060:[c0255299]Not tainted VLI
Mar 6 00:55:53 toshiba kernel: EFLAGS: 00010246 (2.6.11)
Mar 6 00:55:53 toshiba kernel: EIP is at get_kobj_path_length+0x29/0x50
Mar 6 00:55:53 toshiba kernel: eax: ebx: ecx:
edx:
Mar 6 00:55:53 toshiba kernel: esi: 0001 edi: ebp: d4397d9c
esp: d4397d8c
Mar 6 00:55:53 toshiba kernel: ds: 007b es: 007b ss: 0068
Mar 6 00:55:53 toshiba kernel: Process pppd (pid: 6057, threadinfo=d4396000
task=d432da20)
Mar 6 00:55:53 toshiba kernel: Stack: dedf5bb8 00d0 dedf5b94 d6dfa298
d4397db8 c0255339 d4397dc4 dedf5bb8
Mar 6 00:55:53 toshiba kernel:c041f708 dedf5b94 d6dfa298 d4397dfc
c02bc68f 0286 fffd
Mar 6 00:55:53 toshiba kernel: 21ac27d7 de53d829 c039d8ab
c041f720 d6dfa90c
Mar 6 00:55:53 toshiba kernel: Call Trace:
Mar 6 00:55:53 toshiba kernel: [c0103e3a] show_stack+0x7a/0x90
Mar 6 00:55:53 toshiba kernel: [c0103fb9] show_registers+0x149/0x1b0
Mar 6 00:55:53 toshiba kernel: [c01041ad] die+0xdd/0x170
Mar 6 00:55:53 toshiba kernel: [c01157aa] do_page_fault+0x30a/0x65a
Mar 6 00:55:53 toshiba kernel: [c0103abf] error_code+0x2b/0x30
Mar 6 00:55:53 toshiba kernel: [c0255339] kobject_get_path+0x19/0x60
Mar 6 00:55:53 toshiba kernel: [c02bc68f] class_hotplug+0x6f/0x160
Mar 6 00:55:53 toshiba kernel: [c0255ec4] kobject_hotplug+0x1b4/0x2c0
Mar 6 00:55:53 toshiba kernel: [c0255660] kobject_del+0x10/0x20
Mar 6 00:55:53 toshiba kernel: [c02bcab2] class_device_del+0x92/0xc0
Mar 6 00:55:53 toshiba kernel: [c02bcaeb] class_device_unregister+0xb/0x20
Mar 6 00:55:53 toshiba kernel: [dfc795bc] acm_tty_close+0x14c/0x160
[cdc_acm]
Mar 6 00:55:53 toshiba kernel: [c029f6a2] release_dev+0x7f2/0x810
Mar 6 00:55:53 toshiba kernel: [c029fb12] tty_release+0x12/0x20
Mar 6 00:55:53 toshiba kernel: [c0156c9b] __fput+0x12b/0x140
Mar 6 00:55:53 toshiba kernel: [c01554cf] filp_close+0x4f/0x80
Mar 6 00:55:53 toshiba kernel: [c010300f] syscall_call+0x7/0xb
Mar 6 00:55:53 toshiba kernel: Code: 00 00 55 ba ff ff ff ff 89 e5 57 56 be 01
00 00 00 53 83 ec 04 31 db 89 45 f0 90 8d b
4 26 00 00 00 00 8b 45 f0 89 d1 8b 38 89 d8 f2 ae f7 d1 49 8b 45 f0 8d 74 31
01 8b 40 24 89 45 f0 85 c0 75
--
Regards, JustMan.
Signed-Off-By: Serge A. Suchkov [EMAIL PROTECTED]
diff -uNrp linux-2.6.11/drivers/base/class.orig.c
linux-2.6.11/drivers/base/class.c
--- linux-2.6.11/drivers/base/class.orig.c 2005-03-10 02:14:58.0
+0300
+++ linux-2.6.11/drivers/base/class.c 2005-03-10 02:15:06.0 +0300
@@ -307,12 +307,17 @@ static int class_hotplug(struct kset *ks
if (class_dev-dev) {
/* add physical device, backing this device */
struct device *dev = class_dev-dev;
- char *path = kobject_get_path(dev-kobj, GFP_KERNEL);
+ char zero_kobj[sizeof(struct kobject)]={0};
+ char *path;
+
+ if(!memcmp(zero_kobj,dev-kobj,sizeof(struct kobject))) {
- add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size,
- length, PHYSDEVPATH=%s, path);
- kfree(path);
+ path = kobject_get_path(dev-kobj, GFP_KERNEL);
+ add_hotplug_env_var(envp, num_envp, i, buffer,
buffer_size,
+ length, PHYSDEVPATH=%s, path);
+ kfree(path);
+ }
/* add bus name of physical device */
if (dev-bus)
add_hotplug_env_var(envp, num_envp, i,
-
To
Re: [PATCH] make st seekable again
Alan Cox [EMAIL PROTECTED] wrote: On Maw, 2005-03-08 at 17:25, Linux Kernel Mailing List wrote: ChangeSet 1.2030, 2005/03/08 09:25:05-08:00, [EMAIL PROTECTED] [PATCH] make st seekable again Apparently `tar' errors out if it cannot perform lseek() against a tape. Work around that in-kernel. Unfortunately this isn't a good idea. Allowing tar to read the tape position makes sense, allowing it to zero the position might but you have to do major surgery on the driver first because 1.It doesn't use ppos 2.It doesn't do locking on the ppos at all Also allowing apps to randomly seek and report ok when they are backing up to tape and might really need to see the error is not what I'd call stable, professional or quality code. Can the lseek be restricted to seek from 0 to 0 (or even * to 0 aka rewind)? This would re-enable tar and probably other applications depending on this API while not giving them false positives. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] class_simple: pass dev_t to the class core
ChangeSet 1.2041, 2005/03/09 09:33:17-08:00, [EMAIL PROTECTED]
[PATCH] class_simple: pass dev_t to the class core
Signed-off-by: Kay Sievers [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/base/class_simple.c | 21 ++---
1 files changed, 2 insertions(+), 19 deletions(-)
diff -Nru a/drivers/base/class_simple.c b/drivers/base/class_simple.c
--- a/drivers/base/class_simple.c 2005-03-09 16:29:41 -08:00
+++ b/drivers/base/class_simple.c 2005-03-09 16:29:41 -08:00
@@ -10,18 +10,15 @@
#include linux/config.h
#include linux/device.h
-#include linux/kdev_t.h
#include linux/err.h
struct class_simple {
- struct class_device_attribute attr;
struct class class;
};
#define to_class_simple(d) container_of(d, struct class_simple, class)
struct simple_dev {
struct list_head node;
- dev_t dev;
struct class_device class_dev;
};
#define to_simple_dev(d) container_of(d, struct simple_dev, class_dev)
@@ -35,12 +32,6 @@
kfree(s_dev);
}
-static ssize_t show_dev(struct class_device *class_dev, char *buf)
-{
- struct simple_dev *s_dev = to_simple_dev(class_dev);
- return print_dev_t(buf, s_dev-dev);
-}
-
static void class_simple_release(struct class *class)
{
struct class_simple *cs = to_class_simple(class);
@@ -75,12 +66,6 @@
cs-class.class_release = class_simple_release;
cs-class.release = release_simple_dev;
- cs-attr.attr.name = dev;
- cs-attr.attr.mode = S_IRUGO;
- cs-attr.attr.owner = owner;
- cs-attr.show = show_dev;
- cs-attr.store = NULL;
-
retval = class_register(cs-class);
if (retval)
goto error;
@@ -143,7 +128,7 @@
}
memset(s_dev, 0x00, sizeof(*s_dev));
- s_dev-dev = dev;
+ s_dev-class_dev.devt = dev;
s_dev-class_dev.dev = device;
s_dev-class_dev.class = cs-class;
@@ -154,8 +139,6 @@
if (retval)
goto error;
- class_device_create_file(s_dev-class_dev, cs-attr);
-
spin_lock(simple_dev_list_lock);
list_add(s_dev-node, simple_dev_list);
spin_unlock(simple_dev_list_lock);
@@ -200,7 +183,7 @@
spin_lock(simple_dev_list_lock);
list_for_each_entry(s_dev, simple_dev_list, node) {
- if (s_dev-dev == dev) {
+ if (s_dev-class_dev.devt == dev) {
found = 1;
break;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] aoe: drivers/block/aoe/aoechr.c cleanups
ChangeSet 1.2040, 2005/03/09 10:22:12-08:00, [EMAIL PROTECTED]
[PATCH] aoe: drivers/block/aoe/aoechr.c cleanups
Adrian Bunk [EMAIL PROTECTED] writes:
This patch contains the following cleanups:
- make the needlessly global struct aoe_fops static
- #if 0 the unused global function aoechr_hdump
Thanks for the patch. The original patch leaves the prototype for
aoechr_hdump in aoe.h, but since this function is just for debugging,
it seems better to just take both prototype and definition out.
remove aoechr_hdump
make aoe_fops static
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Ed L. Cashin [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/block/aoe/aoe.h|1 -
drivers/block/aoe/aoechr.c | 37 +
2 files changed, 1 insertion(+), 37 deletions(-)
diff -Nru a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h
--- a/drivers/block/aoe/aoe.h 2005-03-09 16:15:39 -08:00
+++ b/drivers/block/aoe/aoe.h 2005-03-09 16:15:39 -08:00
@@ -143,7 +143,6 @@
int aoechr_init(void);
void aoechr_exit(void);
void aoechr_error(char *);
-void aoechr_hdump(char *, int len);
void aoecmd_work(struct aoedev *d);
void aoecmd_cfg(ushort, unsigned char);
diff -Nru a/drivers/block/aoe/aoechr.c b/drivers/block/aoe/aoechr.c
--- a/drivers/block/aoe/aoechr.c2005-03-09 16:15:39 -08:00
+++ b/drivers/block/aoe/aoechr.c2005-03-09 16:15:39 -08:00
@@ -99,41 +99,6 @@
up(emsgs_sema);
}
-#define PERLINE 16
-void
-aoechr_hdump(char *buf, int n)
-{
- int bufsiz;
- char *fbuf;
- int linelen;
- char *p, *e, *fp;
-
- bufsiz = n * 3; /* 2 hex digits and a space */
- bufsiz += n / PERLINE + 1; /* the newline characters */
- bufsiz += 1;/* the final '\0' */
-
- fbuf = kmalloc(bufsiz, GFP_ATOMIC);
- if (!fbuf) {
- printk(KERN_INFO
- %s: cannot allocate memory\n,
- __FUNCTION__);
- return;
- }
-
- for (p = buf; n = 0;) {
- linelen = n PERLINE ? PERLINE : n;
- n -= linelen;
-
- fp = fbuf;
- for (e=p+linelen; pe; p++)
- fp += sprintf(fp, %2.2X , *p 255);
- sprintf(fp, \n);
- aoechr_error(fbuf);
- }
-
- kfree(fbuf);
-}
-
static ssize_t
aoechr_write(struct file *filp, const char __user *buf, size_t cnt, loff_t
*offp)
{
@@ -233,7 +198,7 @@
}
}
-struct file_operations aoe_fops = {
+static struct file_operations aoe_fops = {
.write = aoechr_write,
.read = aoechr_read,
.open = aoechr_open,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] Add 2.4.x cpufreq /proc and sysctl interface removal feature-removal-schedule
ChangeSet 1.2036, 2005/03/09 09:31:40-08:00, [EMAIL PROTECTED] [PATCH] Add 2.4.x cpufreq /proc and sysctl interface removal feature-removal-schedule Add 2.4.x cpufreq /proc and sysctl interface removal to the feature-removal-schedule. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] Documentation/feature-removal-schedule.txt |9 + 1 files changed, 9 insertions(+) diff -Nru a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt --- a/Documentation/feature-removal-schedule.txt2005-03-09 16:30:16 -08:00 +++ b/Documentation/feature-removal-schedule.txt2005-03-09 16:30:16 -08:00 @@ -15,3 +15,12 @@ against the LSB, and can be replaced by using udev. Who: Greg Kroah-Hartman [EMAIL PROTECTED] +--- + +What: /proc/sys/cpu and the sysctl interface to cpufreq (2.4.x interfaces) +When: January 2005 +Files: drivers/cpufreq/: cpufreq_userspace.c, proc_intf.c + function calls throughout the kernel tree +Why: Deprecated, has been replaced/superseded by (what?) +Who: Dominik Brodowski [EMAIL PROTECTED] + - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/15] ptwalk: pagetable walker cleanup
On Wed, 2005-03-09 at 17:02 -0800, David S. Miller wrote:
On Thu, 10 Mar 2005 11:39:44 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
There are some other bugs introduced by set_pte_at() caused by latent
bugs in the PTE walkers that 'drop' part of the address along the way,
notably the vmalloc.c ones are bogus, thus breaking ppc/ppc64 in subtle
ways. Before I send patches, I'd rather check if it's not all fixed by
your patches first :)
Ben, I fixed vmalloc and the other cases when I pushed the set_pte_at()
changes to Linus. Here is the changeset that fixes them, and it's certainly
in Linus's tree:
Yah, but look at the cruft in arch/ppc64/mm/init.c, specifically,
unmap_im_area_{pte,pmd,pud,..} ...
I'll fix it.
Ben.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Direct io on block device has performance regression on 2.6.x kernel
For people who is dying to see some q-tool profile, here is one. It's not a vanilla 2.6.9 kernel, but with patches in raw device to get around the DIO performance problem. - Ken Flat profile of CPU_CYCLES in hist#0: Each histogram sample counts as 255.337u seconds % time self cumul calls self/call tot/call name 5.08 1.92 1.92 - - - schedule 4.64 0.62 2.54 - - - __ia64_readw_relaxed 4.03 0.54 3.08 - - - _stext 3.03 0.41 3.49 - - - qla2x00_queuecommand 2.73 0.37 3.86 - - - qla2x00_start_scsi 1.92 0.26 4.12 - - - __mod_timer 1.78 0.24 4.36 - - - scsi_request_fn 1.68 0.23 4.58 - - - __copy_user 1.45 0.20 4.78 - - - raw_file_rw 1.30 0.17 4.95 - - - kmem_cache_alloc 1.29 0.17 5.12 - - - mempool_alloc 1.29 0.17 5.30 - - - follow_hugetlb_page 1.19 0.16 5.46 - - - generic_make_request 1.14 0.15 5.61 - - - qla2x00_next 1.06 0.14 5.75 - - - memset 1.03 0.14 5.89 - - - raw_file_aio_rw 1.01 0.14 6.03 - - - e1000_clean 0.93 0.13 6.15 - - - scsi_get_command 0.93 0.12 6.28 - - - sd_init_command 0.87 0.12 6.39 - - - __make_request 0.87 0.12 6.51 - - - __aio_get_req 0.81 0.11 6.62 - - - qla2300_intr_handler 0.77 0.10 6.72 - - - put_io_context 0.75 0.10 6.82 - - - qla2x00_process_completed_request 0.74 0.10 6.92 - - - e1000_intr 0.73 0.10 7.02 - - - get_request 0.72 0.10 7.12 - - - rse_clear_invalid 0.70 0.09 7.21 - - - aio_read_evt 0.70 0.09 7.31 - - - e1000_xmit_frame 0.70 0.09 7.40 - - - __bio_add_page 0.69 0.09 7.49 - - - qla2x00_process_response_queue 0.69 0.09 7.58 - - - vfs_read 0.69 0.09 7.68 - - - break_fault 0.67 0.09 7.77 - - - scsi_dispatch_cmd 0.66 0.09 7.86 - - - try_to_wake_up 0.64 0.09 7.94 - - - blk_queue_start_tag 0.63 0.08 8.03 - - - sys_pread64 0.62 0.08 8.11 - - - alt_dtlb_miss 0.60 0.08 8.19 - - - ia64_spinlock_contention 0.57 0.08 8.27 - - - skb_release_data 0.55 0.07 8.34 - - - scsi_prep_fn 0.53 0.07 8.41 - - - tcp_sendmsg 0.52 0.07 8.48 - - - internal_add_timer 0.51 0.07 8.55 - - - drive_stat_acct 0.51 0.07 8.62 - - - tcp_transmit_skb 0.50 0.07 8.69 - - - task_rq_lock 0.49 0.07 8.75 - - - get_user_pages 0.48 0.06 8.82 - - - tcp_rcv_established 0.47 0.06 8.88 - - - kmem_cache_free 0.47 0.06 8.94 - - - save_switch_stack 0.46 0.06 9.00 - - - del_timer 0.46 0.06 9.07 - - - aio_pread 0.45 0.06 9.13 - - - bio_alloc 0.44 0.06 9.19 - - - finish_task_switch 0.44 0.06 9.25 - - - ip_queue_xmit 0.43 0.06 9.30 - - - move_tasks 0.42 0.06 9.36 - - - lock_sock 0.40 0.05 9.41 - - - elv_queue_empty 0.40 0.05 9.47 - - - bio_add_page 0.39 0.05 9.52 - - - try_atomic_semop 0.38 0.05 9.57 - - - qla2x00_done 0.38 0.05 9.62 - - - tcp_recvmsg 0.37 0.05 9.67 - - - put_page 0.37 0.05 9.72 - - - elv_next_request 0.36 0.05 9.77 -
RE: Direct io on block device has performance regression on 2.6.x kernel
Andrew Morton wrote on Wednesday, March 09, 2005 5:34 PM What are these percentages? Total CPU time? The direct-io stuff doesn't look too bad. It's surprising that tweaking the direct-io submission code makes much difference. Percentage is relative to total kernel time. There are three DIO functions showed up in the profile: __blockdev_direct_IO4.97% dio_bio_end_io 2.70% dio_bio_complete1.20% hm. __blockdev_direct_IO() doesn't actually do much. I assume your damn compiler went and inlined direct_io_worker() on us. We are using gcc version 3.4.3. I suppose I can finger point gcc ? :-P - Ken - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Direct io on block device has performance regression on 2.6.x kernel
Andrew Morton wrote on Wednesday, March 09, 2005 2:45 PM Did you generate a kernel profile? Top 40 kernel hot functions, percentage is normalized to kernel utilization. _spin_unlock_irqrestore23.54% _spin_unlock_irq 19.27% Cripes. Is that with CONFIG_PREEMPT? If so, and if you disable CONFIG_PREEMPT, this cost should be accounting the the spin_unlock() caller and we can see who the culprit is. Perhaps dio-bio_lock. CONFIG_PREEMPT is off. Sorry for all the confusion, I probably shouldn't post the first profile to confuse people. See 2nd profile that I posted earlier (copied here again). scsi_request_fn 7.54% finish_task_switch 6.25% __blockdev_direct_IO4.97% __make_request 3.87% scsi_end_request3.54% dio_bio_end_io 2.70% follow_hugetlb_page 2.39% __wake_up 2.37% aio_complete1.82% kmem_cache_alloc1.68% __mod_timer 1.63% e1000_clean 1.57% __generic_file_aio_read 1.42% mempool_alloc 1.37% put_page1.35% e1000_intr 1.31% schedule1.25% dio_bio_complete1.20% scsi_device_unbusy 1.07% kmem_cache_free 1.06% __copy_user 1.04% scsi_dispatch_cmd 1.04% __end_that_request_first1.04% generic_make_request1.02% kfree 0.94% __aio_get_req 0.93% sys_pread64 0.83% get_request 0.79% put_io_context 0.76% dnotify_parent 0.73% vfs_read0.73% update_atime0.73% finished_one_bio0.63% generic_file_aio_write_nolock 0.63% scsi_put_command0.62% break_fault 0.62% e1000_xmit_frame0.62% aio_read_evt0.59% scsi_io_completion 0.59% inode_times_differ 0.58% - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.2
Bill Davidsen [EMAIL PROTECTED] wrote: I think you need both x.y.z=x.y.z.N and x.y.z.N-1=x.y.z.N patches. My systems which are following the -stable will just need the most recent, but doing x.y.z-1=x.y.z.N gets really ugly for higher values of N. bzcat ../patch-2.6.nn.[0-9].*|patch -p1 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: current linus bk, error mounting root
On Wed, 9 Mar 2005 22:09:26 +0100, Jens Axboe [EMAIL PROTECTED] wrote: probably not worth the bother, looks like barrier problems. get the serial console running instead and send the full output, I'll take a look in the morning. serial console boot output attached. -- Jens Axboe -- Jon Smirl [EMAIL PROTECTED] Linux version 2.6.11-bk5 ([EMAIL PROTECTED]) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #3 SMP Wed Mar 9 18:36:46 EST 2005 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3ff74000 (usable) BIOS-e820: 3ff74000 - 3ff76000 (ACPI NVS) BIOS-e820: 3ff76000 - 3ff97000 (ACPI data) BIOS-e820: 3ff97000 - 4000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fecf - fecf1000 (reserved) BIOS-e820: fed2 - fed9 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000fe710 DMI 2.3 present. ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:2 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:bec0) Built 1 zonelists Kernel command line: ro root=LABEL=/ console=ttyS0 Initializing CPU#0 CPU 0 irqstacks, hard=c03b3000 soft=c03b1000 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 2793.222 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1034896k/1048016k available (1576k kernel code, 12396k reserved, 963k data, 188k init, 130512k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Security Framework v1.0.0 initialized Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09 per-CPU timeslice cutoff: 1462.56 usecs. task migration cache decay timeout: 2 msecs. Booting processor 1/1 eip 3000 CPU 1 irqstacks, hard=c03b4000 soft=c03b2000 Initializing CPU#1 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel P4/Xeon Extended MCE MSRs (12) available CPU1: Thermal monitoring enabled CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09 Total of 2 processors activated (11091.96 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=-1 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs checking if image is initramfs... it is Freeing initrd memory: 318k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfba5e, last bus=2 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050211 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 7 9 10 11 12 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 15) SCSI subsystem initialized PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report Simple
[PATCH] tpm_msc-build-fix
ChangeSet 1.2037, 2005/03/09 10:12:56-08:00, [EMAIL PROTECTED]
[PATCH] tpm_msc-build-fix
With older gcc's:
drivers/char/tpm/tpm_nsc.c:238: unknown field `fops' specified in initializer
drivers/char/tpm/tpm_nsc.c:238: warning: missing braces around initializer
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/char/tpm/tpm_nsc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff -Nru a/drivers/char/tpm/tpm_nsc.c b/drivers/char/tpm/tpm_nsc.c
--- a/drivers/char/tpm/tpm_nsc.c2005-03-09 16:40:12 -08:00
+++ b/drivers/char/tpm/tpm_nsc.c2005-03-09 16:40:12 -08:00
@@ -235,7 +235,8 @@
.req_complete_mask = NSC_STATUS_OBF,
.req_complete_val = NSC_STATUS_OBF,
.base = TPM_NSC_BASE,
- .miscdev.fops = nsc_ops,
+ .miscdev = { .fops = nsc_ops, },
+
};
static int __devinit tpm_nsc_init(struct pci_dev *pci_dev,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: class driver pass dev_t to the class core
ChangeSet 1.2043, 2005/03/09 09:51:50-08:00, [EMAIL PROTECTED]
[PATCH] i2c: class driver pass dev_t to the class core
Signed-off-by: Kay Sievers [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/i2c/i2c-dev.c |9 +
1 files changed, 1 insertion(+), 8 deletions(-)
diff -Nru a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
--- a/drivers/i2c/i2c-dev.c 2005-03-09 16:29:27 -08:00
+++ b/drivers/i2c/i2c-dev.c 2005-03-09 16:29:27 -08:00
@@ -108,13 +108,6 @@
spin_unlock(i2c_dev_array_lock);
}
-static ssize_t show_dev(struct class_device *class_dev, char *buf)
-{
- struct i2c_dev *i2c_dev = to_i2c_dev(class_dev);
- return print_dev_t(buf, MKDEV(I2C_MAJOR, i2c_dev-minor));
-}
-static CLASS_DEVICE_ATTR(dev, S_IRUGO, show_dev, NULL);
-
static ssize_t show_adapter_name(struct class_device *class_dev, char *buf)
{
struct i2c_dev *i2c_dev = to_i2c_dev(class_dev);
@@ -451,11 +444,11 @@
else
i2c_dev-class_dev.dev = adap-dev.parent;
i2c_dev-class_dev.class = i2c_dev_class;
+ i2c_dev-class_dev.devt = MKDEV(I2C_MAJOR, i2c_dev-minor);
snprintf(i2c_dev-class_dev.class_id, BUS_ID_SIZE, i2c-%d,
i2c_dev-minor);
retval = class_device_register(i2c_dev-class_dev);
if (retval)
goto error;
- class_device_create_file(i2c_dev-class_dev, class_device_attr_dev);
class_device_create_file(i2c_dev-class_dev, class_device_attr_name);
return 0;
error:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: link(2) and symlinks
On Wed, Mar 09, 2005 at 03:14:36PM -0800, Nick Stoughton wrote: On Linux, the link() system call does not dereference symbolic links This behavior does not conform to POSIX Most Unix implementations behave in the manner specified by POSIX. One notable exception is Solaris 8 (I don't know about later Solarises). Would a patch to provide POSIX conforming behavior under some conditional case (e.g. if /proc/sys/posix has value 1) ever be accepted? It sounds like a bad idea to have name resolution semantics dependent upon some external variable. The result would be that nobody could be sure anymore what the link() system call will do. (Also, POSIX does not describe the kernel interface - it describes a C interface. It would be possible for a libc to arrange that a different link() routine was used. Use of personality(2) does not sound like a good idea.) ((Maybe it would be beter to change POSIX here. Submit a defect report and make the result of hard-linking to a symlink unspecified. Since Linux and Solaris are non-POSIX here, programmers of portable programs cannot rely on POSIX anyway. Moreover, the Linux/Solaris behaviour sounds entirely reasonable, preferable in fact above the POSIX behaviour.)) Andries - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BK PATCH] debugfs fixes for 2.6.11
Hi, Here are two debugfs fixes. They have been in the -mm releases for a while. Please pull from: bk://kernel.bkbits.net/gregkh/linux/2.6.11/debugfs Individual patches will follow, sent to the linux-kernel list. thanks, greg k-h fs/debugfs/file.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) - Greg Kroah-Hartman: o debugfs: fix bool built-in type o debufs: make built in types add a \n to their output - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.6.11- sym53c8xx Broken on pp64
Seems with 2.6.11 the sym53c8xx kernel module incorrectly identifies the cache being misconfigured on a p630 (ppc64, POWER4+). 2.6.9 correctly brings up this adaptor as does AIX with absolutely no indication of a misconfigured cache. Doing a simple diff I see ALOT of changes between 2.6.9 and 2.6.11 pertaining to this module. Any ideas? O - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Exuberant ctags can tag files names too
Exuberant ctags can tag file names too. I find this extremely useful when browsing kernel source, and so would like to share it with everyone. (You can now type :tag oprof.c for example, and jump to the file with that name.) I previously sent a patch which naively just appended an --extra=+f to the ctags line. Here's a much smarter patch that works by first querrying if ctags is exuberant, and if so, whether the --extra functionality is available before adding the line. Please apply. Signed-off-by: John Kacur [EMAIL PROTECTED] --- Makefile.orig 2005-03-08 23:34:16.0 -0500 +++ Makefile2005-03-09 20:25:06.710159432 -0500 @@ -1167,12 +1167,13 @@ cmd_TAGS = $(all-sources) | etags - # Exuberant ctags works better with -I - +# Exuberant ctags can tag file names with --extra=+f quiet_cmd_tags = MAKE $@ define cmd_tags rm -f $@; \ - CTAGSF=`ctags --version | grep -i exuberant /dev/null echo -I __initdata,__exitdata,EXPORT_SYMBOL,EXPORT_SYMBOL_GPL`; \ - $(all-sources) | xargs ctags $$CTAGSF -a + CTAGSF=`ctags --version | grep -iq exuberant echo -I __initdata,__exitdata,EXPORT_SYMBOL,EXPORT_SYMBOL_GPL`; \ + CTAGSF_EXTRA=`ctags --version | grep -iq exuberant ctags --help | grep -q \--extra echo --extra=+f`; \ + $(all-sources) | xargs ctags $$CTAGSF -a $$CTAGSF_EXTRA endef TAGS: FORCE This second patch is a trivial spelling correction. Please apply Signed-off-by: John Kacur [EMAIL PROTECTED] --- Makefile.orig 2005-03-08 23:34:16.0 -0500 +++ Makefile2005-03-09 20:26:29.063639800 -0500 @@ -18,7 +18,7 @@ # # Most importantly: sub-Makefiles should only ever modify files in # their own directory. If in some directory we have a dependency on -# a file in another dir (which doesn't happen often, but it's of +# a file in another dir (which doesn't happen often, but it's often # unavoidable when linking the built-in.o targets which finally # turn into vmlinux), we will call a sub make in that other dir, and # after that we are sure that everything which is in that other dir Kai, your e-mail address which I found in the list is different than the one listed in the MAINTAINERS file. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(no subject)
subscribe linux-kernel end - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] unified spinlock initialization arch/um/drivers/port_kern.c
On Wed, 9 Mar 2005, linux-os wrote: We need to retain the spin_lock_init(lock) because not all spin-locks are allocated at compile-time. They might be allocated from kmalloc() on startup, probably in a structure, along with other so-called global data. Not to worry my good man, it's not going anywhere. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Direct io on block device has performance regression on 2.6.x kernel
Chen, Kenneth W wrote on Wednesday, March 09, 2005 5:45 PM Andrew Morton wrote on Wednesday, March 09, 2005 5:34 PM What are these percentages? Total CPU time? The direct-io stuff doesn't look too bad. It's surprising that tweaking the direct-io submission code makes much difference. Percentage is relative to total kernel time. There are three DIO functions showed up in the profile: __blockdev_direct_IO 4.97% dio_bio_end_io2.70% dio_bio_complete 1.20% For the sake of comparison, let's look at the effect of performance patch on raw device, in place of the above three functions, we now have two: raw_file_rw 1.59% raw_file_aio_rw 1.19% A total saving of 6.09% (4.97+2.70+1.20 -1.59-1.19). That's only counting the cpu cycles. We have tons of other data showing significant kernel path length reduction with the performance patch. Cache misses reduced across the entire 3 level cache hierarchy, that's a secondary effect can not be ignored since kernel is also competing cache resource with application. - Ken - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 2.4.x cpufreq /proc and sysctl interface removal feature-removal-schedule
On Wed, Mar 09, 2005 at 04:34:38PM -0800, Greg KH wrote: ChangeSet 1.2036, 2005/03/09 09:31:40-08:00, [EMAIL PROTECTED] [PATCH] Add 2.4.x cpufreq /proc and sysctl interface removal feature-removal-schedule Add 2.4.x cpufreq /proc and sysctl interface removal to the feature-removal-schedule. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] Documentation/feature-removal-schedule.txt |9 + 1 files changed, 9 insertions(+) diff -Nru a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt --- a/Documentation/feature-removal-schedule.txt 2005-03-09 16:30:16 -08:00 +++ b/Documentation/feature-removal-schedule.txt 2005-03-09 16:30:16 -08:00 @@ -15,3 +15,12 @@ against the LSB, and can be replaced by using udev. Who:Greg Kroah-Hartman [EMAIL PROTECTED] +--- + +What: /proc/sys/cpu and the sysctl interface to cpufreq (2.4.x interfaces) +When: January 2005 You're about 2 months too late 8-) Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PPC64] Allow emulation of mfpvr on ppc64 kernel
Andrew, please apply.
Allow userspace programs on ppc64 to use the (privileged) mfpvr
instruction to determine the processor type. At the moment it
emulates the instruction to provide the real PVR value, though it
could be made to lie in future if for some reason we wish to restrict
what CPU features userspace uses.
If nothing else this means that some existing ppc32 applications will
now run on a 64-bit kernel (the 32-bit kernel has long supported this
emulation). It will also be necessary for ppc64 perfctr support,
where userspace requires finer-grained cpu type information than the
kernel in order to correctly program the performance monitor control
registers.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: working-2.6/arch/ppc64/kernel/traps.c
===
--- working-2.6.orig/arch/ppc64/kernel/traps.c 2005-03-06 07:08:24.0
+1100
+++ working-2.6/arch/ppc64/kernel/traps.c 2005-03-10 13:05:25.0
+1100
@@ -279,6 +279,9 @@
* fault. Return zero on success.
*/
+#define INST_MFSPR_PVR 0x7c1f42a6
+#define INST_MFSPR_PVR_MASK0xfc1f
+
#define INST_DCBA 0x7c0005ec
#define INST_DCBA_MASK 0x7c0007fe
@@ -297,6 +300,15 @@
if (get_user(instword, (unsigned int __user *)(regs-nip)))
return -EFAULT;
+ /* Emulate the mfspr rD, PVR. */
+ if ((instword INST_MFSPR_PVR_MASK) == INST_MFSPR_PVR) {
+ unsigned int rd;
+
+ rd = (instword 21) 0x1f;
+ regs-gpr[rd] = mfspr(SPRN_PVR);
+ return 0;
+ }
+
/* Emulating the dcba insn is just a no-op. */
if ((instword INST_DCBA_MASK) == INST_DCBA) {
static int warned;
@@ -390,11 +402,6 @@
if (regs-msr 0x10) {
/* IEEE FP exception */
parse_fpe(regs);
-
- } else if (regs-msr 0x4) {
- /* Privileged instruction */
- _exception(SIGILL, regs, ILL_PRVOPC, regs-nip);
-
} else if (regs-msr 0x2) {
/* trap exception */
@@ -411,7 +418,7 @@
_exception(SIGTRAP, regs, TRAP_BRKPT, regs-nip);
} else {
- /* Illegal instruction; try to emulate it. */
+ /* Privileged or illegal instruction; try to emulate it. */
switch (emulate_instruction(regs)) {
case 0:
regs-nip += 4;
@@ -423,7 +430,12 @@
break;
default:
- _exception(SIGILL, regs, ILL_ILLOPC, regs-nip);
+ if (regs-msr 0x4)
+ /* priveleged */
+ _exception(SIGILL, regs, ILL_PRVOPC, regs-nip);
+ else
+ /* illegal */
+ _exception(SIGILL, regs, ILL_ILLOPC, regs-nip);
break;
}
}
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_
| _around_!
http://www.ozlabs.org/people/dgibson
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.11- sym53c8xx Broken on pp64
On Wed, 2005-03-09 at 19:51 -0600, Omkhar Arasaratnam wrote: Seems with 2.6.11 the sym53c8xx kernel module incorrectly identifies the cache being misconfigured on a p630 (ppc64, POWER4+). 2.6.9 correctly brings up this adaptor as does AIX with absolutely no indication of a misconfigured cache. Doing a simple diff I see ALOT of changes between 2.6.9 and 2.6.11 pertaining to this module. Any ideas? Are you sure it's plain 2.6.11 and not some bk clone of after 2.6.11 was released ? I just found a bug in the ppc64 ioremap code that got triggered by the set_pte_at() patch that went into bk after 2.6.11 and that triggers exactly that error, but I couldn't see anything wrong in 2.6.11 proper. BTW, Linus: Any chance you ever change something to version or extraversion in bk just after a release ? I know I already ask and it degenerated into a flamefest, and I don't know if that is specifically the case now, but I keep getting report of people saying I have a bug in 2.6.xx while in fact, they have some kind of bk clone of sometime after 2.6.xx... Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Direct io on block device has performance regression on 2.6.x kernel
Chen, Kenneth W [EMAIL PROTECTED] wrote: Andrew Morton wrote on Wednesday, March 09, 2005 2:45 PM Did you generate a kernel profile? Top 40 kernel hot functions, percentage is normalized to kernel utilization. _spin_unlock_irqrestore 23.54% _spin_unlock_irq19.27% Cripes. Is that with CONFIG_PREEMPT? If so, and if you disable CONFIG_PREEMPT, this cost should be accounting the the spin_unlock() caller and we can see who the culprit is. Perhaps dio-bio_lock. CONFIG_PREEMPT is off. Sorry for all the confusion, I probably shouldn't post the first profile to confuse people. See 2nd profile that I posted earlier (copied here again). scsi_request_fn 7.54% finish_task_switch 6.25% __blockdev_direct_IO 4.97% __make_request 3.87% scsi_end_request 3.54% dio_bio_end_io 2.70% follow_hugetlb_page 2.39% __wake_up2.37% aio_complete 1.82% What are these percentages? Total CPU time? The direct-io stuff doesn't look too bad. It's surprising that tweaking the direct-io submission code makes much difference. hm. __blockdev_direct_IO() doesn't actually do much. I assume your damn compiler went and inlined direct_io_worker() on us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Direct io on block device has performance regression on 2.6.x kernel
Chen, Kenneth W [EMAIL PROTECTED] wrote: This is all real: real benchmark running on real hardware, with real result showing large performance regression. Nothing synthetic here. Ken, could you *please* be more complete, more organized and more specific? What does 1/3 of the total benchmark performance regression mean? One third of 0.1% isn't very impressive. You haven't told us anything at all about the magnitude of this regression. Where does the rest of the regression come from? How much system time? User time? All that stuff. And yes, it is all worth pursuing, the two patches on raw device recuperate 1/3 of the total benchmark performance regression. The patch needs a fair bit of work, and if it still provides useful gains when it's complete I guess could make sense as some database special-case. But the first thing to do is to work out where the cycles are going to. Also, I'm rather peeved that we're hearing about this regression now rather than two years ago. And mystified as to why yours is the only group which has reported it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.11- sym53c8xx Broken on pp64
On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote: BTW, Linus: Any chance you ever change something to version or extraversion in bk just after a release ? I know I already ask and it degenerated into a flamefest, and I don't know if that is specifically the case now, but I keep getting report of people saying I have a bug in 2.6.xx while in fact, they have some kind of bk clone of sometime after 2.6.xx... The answer is the same: I'd still like to have somebody (preferably Sam) who is comfortable with all the build scripts get a revision-control- specific version at build-time, so that BK users would get the top-of-tree key value, and other people could get some CVS revision or something. I don't want to tag things just randomly, especially as it would be very error-prone (read: I'd forget). A script that looks at the top revision, and if it's not a tag, takes the key value and appends it to the build version seems to be The Right Thing (tm). I have this dim memory that Sam might even have had some early trials, but maybe thats just wishful thinking.. Sam? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] driver core: Separate platform device name from platform device number
ChangeSet 1.2038, 2005/03/09 09:32:19-08:00, [EMAIL PROTECTED] [PATCH] driver core: Separate platform device name from platform device number Separate platform device name from platform device number such that names ending with numbers aren't confusing. Signed-off-by: Russell King [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] drivers/base/platform.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Nru a/drivers/base/platform.c b/drivers/base/platform.c --- a/drivers/base/platform.c 2005-03-09 16:30:02 -08:00 +++ b/drivers/base/platform.c 2005-03-09 16:30:02 -08:00 @@ -131,7 +131,7 @@ pdev-dev.bus = platform_bus_type; if (pdev-id != -1) - snprintf(pdev-dev.bus_id, BUS_ID_SIZE, %s%u, pdev-name, pdev-id); + snprintf(pdev-dev.bus_id, BUS_ID_SIZE, %s.%u, pdev-name, pdev-id); else strlcpy(pdev-dev.bus_id, pdev-name, BUS_ID_SIZE); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Kobject: remove some unneeded exports
ChangeSet 1.2035, 2005/03/09 09:31:21-08:00, [EMAIL PROTECTED] [PATCH] Kobject: remove some unneeded exports kobject_get_path and kobject_rename are only used by the sysfs core code and not aren't really driver-ish code. Remove the unused exports Signed-off-by: Arjan van de Ven [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] lib/kobject.c |2 -- 1 files changed, 2 deletions(-) diff -Nru a/lib/kobject.c b/lib/kobject.c --- a/lib/kobject.c 2005-03-09 16:30:23 -08:00 +++ b/lib/kobject.c 2005-03-09 16:30:23 -08:00 @@ -524,7 +524,6 @@ } } -EXPORT_SYMBOL(kobject_get_path); EXPORT_SYMBOL(kobject_init); EXPORT_SYMBOL(kobject_register); EXPORT_SYMBOL(kobject_unregister); @@ -532,7 +531,6 @@ EXPORT_SYMBOL(kobject_put); EXPORT_SYMBOL(kobject_add); EXPORT_SYMBOL(kobject_del); -EXPORT_SYMBOL(kobject_rename); EXPORT_SYMBOL(kset_register); EXPORT_SYMBOL(kset_unregister); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] class core: export MAJOR/MINOR to the hotplug env
ChangeSet 1.2039, 2005/03/09 09:32:38-08:00, [EMAIL PROTECTED]
[PATCH] class core: export MAJOR/MINOR to the hotplug env
Move the creation of the sysfs dev file of a class device into the
driver core. The struct class_device contains a dev_t value now. If set,
the driver core will create the dev file containing the major/minor
numbers automatically.
Signed-off-by: Kay Sievers [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/base/class.c | 39 +--
include/linux/device.h |1 +
2 files changed, 30 insertions(+), 10 deletions(-)
diff -Nru a/drivers/base/class.c b/drivers/base/class.c
--- a/drivers/base/class.c 2005-03-09 16:29:55 -08:00
+++ b/drivers/base/class.c 2005-03-09 16:29:55 -08:00
@@ -15,6 +15,7 @@
#include linux/module.h
#include linux/init.h
#include linux/string.h
+#include linux/kdev_t.h
#include base.h
#define to_class_attr(_attr) container_of(_attr, struct class_attribute, attr)
@@ -298,9 +299,9 @@
int num_envp, char *buffer, int buffer_size)
{
struct class_device *class_dev = to_class_dev(kobj);
- int retval = 0;
int i = 0;
int length = 0;
+ int retval = 0;
pr_debug(%s - name = %s\n, __FUNCTION__, class_dev-class_id);
@@ -313,26 +314,34 @@
length, PHYSDEVPATH=%s, path);
kfree(path);
- /* add bus name of physical device */
if (dev-bus)
add_hotplug_env_var(envp, num_envp, i,
buffer, buffer_size, length,
PHYSDEVBUS=%s, dev-bus-name);
- /* add driver name of physical device */
if (dev-driver)
add_hotplug_env_var(envp, num_envp, i,
buffer, buffer_size, length,
PHYSDEVDRIVER=%s,
dev-driver-name);
-
- /* terminate, set to next free slot, shrink available space */
- envp[i] = NULL;
- envp = envp[i];
- num_envp -= i;
- buffer = buffer[length];
- buffer_size -= length;
}
+ if (MAJOR(class_dev-devt)) {
+ add_hotplug_env_var(envp, num_envp, i,
+ buffer, buffer_size, length,
+ MAJOR=%u, MAJOR(class_dev-devt));
+
+ add_hotplug_env_var(envp, num_envp, i,
+ buffer, buffer_size, length,
+ MINOR=%u, MINOR(class_dev-devt));
+ }
+
+ /* terminate, set to next free slot, shrink available space */
+ envp[i] = NULL;
+ envp = envp[i];
+ num_envp -= i;
+ buffer = buffer[length];
+ buffer_size -= length;
+
if (class_dev-class-hotplug) {
/* have the bus specific function add its stuff */
retval = class_dev-class-hotplug (class_dev, envp, num_envp,
@@ -388,6 +397,12 @@
}
}
+static ssize_t show_dev(struct class_device *class_dev, char *buf)
+{
+ return print_dev_t(buf, class_dev-devt);
+}
+static CLASS_DEVICE_ATTR(dev, S_IRUGO, show_dev, NULL);
+
void class_device_initialize(struct class_device *class_dev)
{
kobj_set_kset_s(class_dev, class_obj_subsys);
@@ -432,6 +447,10 @@
class_intf-add(class_dev);
up_write(parent-subsys.rwsem);
}
+
+ if (MAJOR(class_dev-devt))
+ class_device_create_file(class_dev, class_device_attr_dev);
+
class_device_add_attrs(class_dev);
class_device_dev_link(class_dev);
class_device_driver_link(class_dev);
diff -Nru a/include/linux/device.h b/include/linux/device.h
--- a/include/linux/device.h2005-03-09 16:29:55 -08:00
+++ b/include/linux/device.h2005-03-09 16:29:55 -08:00
@@ -184,6 +184,7 @@
struct kobject kobj;
struct class* class;/* required */
+ dev_t devt; /* dev_t, creates the sysfs
dev */
struct device * dev; /* not necessary, but nice to
have */
void* class_data; /* class-specific data */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] Driver core: add bus symlink to class/block devices
ChangeSet 1.2046, 2005/03/09 09:52:48-08:00, [EMAIL PROTECTED]
[PATCH] Driver core: add bus symlink to class/block devices
On Tue, Feb 15, 2005 at 09:53:44PM +0100, Kay Sievers wrote:
Add a bus symlink to the class and block devices, just like the driver
and device links. This may be a huge speed gain for e.g. udev to determine
the bus value of a device, as we currently need to do a brute-force scan in
/sys/bus/* to find this value.
Hmm, while playing around with it, I think we should create the bus
link on the physical device on not on the class device.
Also the current driver link at the class device should be removed,
cause class devices don't have a driver. Block devices never had this
misleading symlink.
From the class device we point with the device link to the physical
device, and only the physical device should have the driver and the
bus link, as it represents the real relationship.
Signed-off-by: Kay Sievers [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/base/bus.c |2 ++
drivers/base/class.c | 36 +---
2 files changed, 7 insertions(+), 31 deletions(-)
diff -Nru a/drivers/base/bus.c b/drivers/base/bus.c
--- a/drivers/base/bus.c2005-03-09 16:29:06 -08:00
+++ b/drivers/base/bus.c2005-03-09 16:29:06 -08:00
@@ -465,6 +465,7 @@
up_write(dev-bus-subsys.rwsem);
device_add_attrs(bus, dev);
sysfs_create_link(bus-devices.kobj, dev-kobj, dev-bus_id);
+ sysfs_create_link(dev-kobj, dev-bus-subsys.kset.kobj,
bus);
}
return error;
}
@@ -481,6 +482,7 @@
void bus_remove_device(struct device * dev)
{
if (dev-bus) {
+ sysfs_remove_link(dev-kobj, bus);
sysfs_remove_link(dev-bus-devices.kobj, dev-bus_id);
device_remove_attrs(dev-bus, dev);
down_write(dev-bus-subsys.rwsem);
diff -Nru a/drivers/base/class.c b/drivers/base/class.c
--- a/drivers/base/class.c 2005-03-09 16:29:06 -08:00
+++ b/drivers/base/class.c 2005-03-09 16:29:06 -08:00
@@ -196,33 +196,6 @@
sysfs_remove_bin_file(class_dev-kobj, attr);
}
-static int class_device_dev_link(struct class_device * class_dev)
-{
- if (class_dev-dev)
- return sysfs_create_link(class_dev-kobj,
-class_dev-dev-kobj, device);
- return 0;
-}
-
-static void class_device_dev_unlink(struct class_device * class_dev)
-{
- sysfs_remove_link(class_dev-kobj, device);
-}
-
-static int class_device_driver_link(struct class_device * class_dev)
-{
- if ((class_dev-dev) (class_dev-dev-driver))
- return sysfs_create_link(class_dev-kobj,
-class_dev-dev-driver-kobj,
driver);
- return 0;
-}
-
-static void class_device_driver_unlink(struct class_device * class_dev)
-{
- sysfs_remove_link(class_dev-kobj, driver);
-}
-
-
static ssize_t
class_device_attr_show(struct kobject * kobj, struct attribute * attr,
char * buf)
@@ -452,8 +425,9 @@
class_device_create_file(class_dev, class_device_attr_dev);
class_device_add_attrs(class_dev);
- class_device_dev_link(class_dev);
- class_device_driver_link(class_dev);
+ if (class_dev-dev)
+ sysfs_create_link(class_dev-kobj,
+ class_dev-dev-kobj, device);
register_done:
if (error parent)
@@ -482,8 +456,8 @@
up_write(parent-subsys.rwsem);
}
- class_device_dev_unlink(class_dev);
- class_device_driver_unlink(class_dev);
+ if (class_dev-dev)
+ sysfs_remove_link(class_dev-kobj, device);
class_device_remove_attrs(class_dev);
kobject_del(class_dev-kobj);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
bk commits and dates
While we are at such requests ... When you pull from one of the trees, like netdev, the commit messages are sent to the bk commit list with the original date stamp of the patch in the netdev tree. For example, if Jeff commited a patch from somebody in his netdev tree 3 weeks ago, and you pull Jeff's tree today, we'll get all the commit messages today, but dated from 3 weeks ago. That means that in my mailing list archive, where my mailer sorts them by date, I can't say, for example, everything that is before the 2.6.11 tag release was in 2.6.11. It's also difficult to spot new stuffs as they can arrive with dates weeks ago, and thus show up in places I will not look for. I don't know if I'm the only one to have a problem with that, but it would be nice if it was possible, when you pull a bk tree, to have the commit messages for the csets in that tree be dated from the day you pulled, and not the day when they went in the source tree. Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sysdev: remove the rwsem usage from this subsystem.
ChangeSet 1.2054, 2005/03/09 15:39:09-08:00, [EMAIL PROTECTED]
[PATCH] sysdev: remove the rwsem usage from this subsystem.
If further finer grained locking is needed, we can add a lock to the
sysdev_class to
lock the class drivers list. But if you do that, remember the global list also
is still
there and needs to be protected. That's why I went with a simple lock for
everything.
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/base/sys.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff -Nru a/drivers/base/sys.c b/drivers/base/sys.c
--- a/drivers/base/sys.c2005-03-09 16:28:10 -08:00
+++ b/drivers/base/sys.c2005-03-09 16:28:10 -08:00
@@ -103,6 +103,7 @@
static LIST_HEAD(sysdev_drivers);
+static DECLARE_MUTEX(sysdev_drivers_lock);
/**
* sysdev_driver_register - Register auxillary driver
@@ -119,7 +120,7 @@
int sysdev_driver_register(struct sysdev_class * cls,
struct sysdev_driver * drv)
{
- down_write(system_subsys.rwsem);
+ down(sysdev_drivers_lock);
if (cls kset_get(cls-kset)) {
list_add_tail(drv-entry, cls-drivers);
@@ -131,7 +132,7 @@
}
} else
list_add_tail(drv-entry, sysdev_drivers);
- up_write(system_subsys.rwsem);
+ up(sysdev_drivers_lock);
return 0;
}
@@ -144,7 +145,7 @@
void sysdev_driver_unregister(struct sysdev_class * cls,
struct sysdev_driver * drv)
{
- down_write(system_subsys.rwsem);
+ down(sysdev_drivers_lock);
list_del_init(drv-entry);
if (cls) {
if (drv-remove) {
@@ -154,7 +155,7 @@
}
kset_put(cls-kset);
}
- up_write(system_subsys.rwsem);
+ up(sysdev_drivers_lock);
}
EXPORT_SYMBOL_GPL(sysdev_driver_register);
@@ -193,7 +194,7 @@
if (!error) {
struct sysdev_driver * drv;
- down_write(system_subsys.rwsem);
+ down(sysdev_drivers_lock);
/* Generic notification is implicit, because it's that
* code that should have called us.
*/
@@ -209,7 +210,7 @@
if (drv-add)
drv-add(sysdev);
}
- up_write(system_subsys.rwsem);
+ up(sysdev_drivers_lock);
}
return error;
}
@@ -218,7 +219,7 @@
{
struct sysdev_driver * drv;
- down_write(system_subsys.rwsem);
+ down(sysdev_drivers_lock);
list_for_each_entry(drv, sysdev_drivers, entry) {
if (drv-remove)
drv-remove(sysdev);
@@ -228,7 +229,7 @@
if (drv-remove)
drv-remove(sysdev);
}
- up_write(system_subsys.rwsem);
+ up(sysdev_drivers_lock);
kobject_unregister(sysdev-kobj);
}
@@ -255,7 +256,7 @@
pr_debug(Shutting Down System Devices\n);
- down_write(system_subsys.rwsem);
+ down(sysdev_drivers_lock);
list_for_each_entry_reverse(cls, system_subsys.kset.list,
kset.kobj.entry) {
struct sys_device * sysdev;
@@ -284,7 +285,7 @@
cls-shutdown(sysdev);
}
}
- up_write(system_subsys.rwsem);
+ up(sysdev_drivers_lock);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] sysdev: make system_subsys static as no one else needs access to it.
ChangeSet 1.2049, 2005/03/09 09:59:49-08:00, [EMAIL PROTECTED]
[PATCH] sysdev: make system_subsys static as no one else needs access to it.
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/base/sys.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Nru a/drivers/base/sys.c b/drivers/base/sys.c
--- a/drivers/base/sys.c2005-03-09 16:28:45 -08:00
+++ b/drivers/base/sys.c2005-03-09 16:28:45 -08:00
@@ -79,7 +79,7 @@
/*
* declare system_subsys
*/
-decl_subsys(system, ktype_sysdev, NULL);
+static decl_subsys(system, ktype_sysdev, NULL);
int sysdev_class_register(struct sysdev_class * cls)
{
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] cpufreq 2.4 interface removal schedule
ChangeSet 1.2037, 2005/03/09 09:32:00-08:00, [EMAIL PROTECTED] [PATCH] cpufreq 2.4 interface removal schedule Even though these 2.4. interfaces are already gone in Dave Jones' cpufreq bitkeeper tree, here's a patch which properly announces it in Documentation/feature-removal-schedule.txt: Add meaningful content concerning the removal of deprecated interfaces to the cpufreq core. Signed-off-by: Dominik Brodowski [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] Documentation/feature-removal-schedule.txt | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff -Nru a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt --- a/Documentation/feature-removal-schedule.txt2005-03-09 16:30:09 -08:00 +++ b/Documentation/feature-removal-schedule.txt2005-03-09 16:30:09 -08:00 @@ -17,10 +17,18 @@ --- -What: /proc/sys/cpu and the sysctl interface to cpufreq (2.4.x interfaces) +What: /proc/sys/cpu/*, sysctl and /proc/cpufreq interfaces to cpufreq (2.4.x interfaces) When: January 2005 Files: drivers/cpufreq/: cpufreq_userspace.c, proc_intf.c - function calls throughout the kernel tree -Why: Deprecated, has been replaced/superseded by (what?) +Why: /proc/sys/cpu/* has been deprecated since inclusion of cpufreq into + the main kernel tree. It bloats /proc/ unnecessarily and doesn't work + well with the governor-based design of cpufreq. + /proc/cpufreq/* has also been deprecated for a long time and was only + meant for usage during 2.5. until the new sysfs-based interface became + ready. It has an inconsistent interface which doesn't work well with + userspace setting the frequency. The output from /proc/cpufreq/* can + be emulated using cpufreq-info --proc (cpufrequtils). + Both interfaces are superseded by the cpufreq interface in + /sys/devices/system/cpu/cpu%n/cpufreq/. Who: Dominik Brodowski [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with PPPD on dialup with 2.6.11-bk1 and later; 2.6.11 is OK
Today at 04:57:37 pm, I wrote: Earlier today, I reported PPPD fails on recent 2.6.11-bk. I've narrowed the problem down to between 2.6.11 and 2.6.11-bk1. I get this with 2.6.11-bk1: (two attempts) Mar 9 16:34:32 spc pppd[1142]: pppd 2.4.1 started by steven, uid 501 Mar 9 16:34:32 spc pppd[1142]: Using interface ppp0 Mar 9 16:34:32 spc pppd[1142]: Connect: ppp0 -- /dev/ttyS1 Mar 9 16:34:56 spc pppd[1142]: Hangup (SIGHUP) Mar 9 16:34:56 spc pppd[1142]: Modem hangup Mar 9 16:34:56 spc pppd[1142]: Connection terminated. Mar 9 16:34:56 spc pppd[1142]: Exit. Searching lkml archive, I found: http://marc.theaimsgroup.com/?l=linux-kernelm=111031501416334w=2 I also found that reverting that patch made the problem go away for 2.6.11-bk1. The bookmarkable link for this changeset is here: http://linus.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]|[EMAIL PROTECTED] Stephen Hemminger also wrote: (Someting's busted with serial in 2.6.11 latest) Some checkin since 2.6.11 has caused the serial driver to drop characters. Console output is chopped and messages are garbled. Even the shell prompt gets truncated. Hope this helps, Steven - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] aoe status.sh: handle sysfs not in /etc/mtab
ChangeSet 1.2039, 2005/03/09 10:21:52-08:00, [EMAIL PROTECTED]
[PATCH] aoe status.sh: handle sysfs not in /etc/mtab
Suse 9.1 Pro doesn't put /sys in /etc/mtab. This patch makes the
example aoe status.sh script work when sysfs is mounted but `mount`
doesn't mention sysfs.
aoe status.sh: handle sysfs not in /etc/mtab
Signed-off-by: Ed L. Cashin [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
Documentation/aoe/status.sh |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff -Nru a/Documentation/aoe/status.sh b/Documentation/aoe/status.sh
--- a/Documentation/aoe/status.sh 2005-03-09 16:15:46 -08:00
+++ b/Documentation/aoe/status.sh 2005-03-09 16:15:46 -08:00
@@ -4,10 +4,13 @@
set -e
format=%8s\t%8s\t%8s\n
me=`basename $0`
+sysd=${sysfs_dir:-/sys}
# printf $format device mac netif state
-test -z `mount | grep sysfs` {
+# Suse 9.1 Pro doesn't put /sys in /etc/mtab
+#test -z `mount | grep sysfs` {
+test ! -d $sysd/block {
echo $me Error: sysfs is not mounted 12
exit 1
}
@@ -16,7 +19,7 @@
exit 1
}
-for d in `ls -d /sys/block/etherd* 2/dev/null | grep -v p` end; do
+for d in `ls -d $sysd/block/etherd* 2/dev/null | grep -v p` end; do
# maybe ls comes up empty, so we use end
test $d = end continue
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
Lars Marowsky-Bree wrote: On 2005-03-08T22:25:29, Alex Aizman [EMAIL PROTECTED] wrote: There's (or at least was up until today) an ongoing discussion on our mailing list at http://groups-beta.google.com/group/open-iscsi. The short and long of it: the problem can be solved, and it will. Couple simple things we already do: mlockall() to keep the daemon un-swapped, and also looking into potential dependency created by syslog (there's one for 2.4 kernel, not sure if this is an issue for 2.6). BTW, to get around the very same issues, heartbeat does much the same: lock itself into memory, reserve a couple of pages more to spare on stack heap, run at soft-realtime priority. Heartbeat is good for reliability, etc. WRT getting paged-out - non-deterministic (things depend on time), right? syslog(), however, sucks. It does. We went down the path of using our non-blocking IPC library to have all our various components log to ha_logd, which then logs to syslog() or writes to disk or wherever. Found ha_logd under http://linux-ha.org. The latter is extemely interesting in the longer term. In the short term, there's quite a bit of information on this site, need time. That works well in our current development series, and if you want to share code, you can either rip it off (Open Source, we love ya ;) or we can spin off these parts into a sub-package for you to depend on... If it's not a big deal :-) let's do the sub-package option. The sfnet is a learning experience; it is by no means a proof that it cannot be done. I'd also argue that it MUST be done, because the current way of Oh, it's somehow related to block stuff, must be in kernel leads down to hell. We better figure out good ways around it ;-) Yes, it MUST be done. Sincerely, Lars Marowsky-Brée [EMAIL PROTECTED] Alex - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Add TPM hardware enablement driver
ChangeSet 1.2035, 2005/03/09 10:12:19-08:00, [EMAIL PROTECTED] [PATCH] Add TPM hardware enablement driver This patch is a device driver to enable new hardware. The new hardware is the TPM chip as described by specifications at http://www.trustedcomputinggroup.org. The TPM chip will enable you to use hardware to securely store and protect your keys and personal data. To use the chip according to the specification, you will need the Trusted Software Stack (TSS) of which an implementation for Linux is available at: http://sourceforge.net/projects/trousers. Signed-off-by: Leendert van Doorn [EMAIL PROTECTED] Signed-off-by: Reiner Sailer [EMAIL PROTECTED] Signed-off-by: Dave Safford [EMAIL PROTECTED] Signed-off-by: Kylene Hall [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] drivers/char/Kconfig |2 drivers/char/Makefile|2 drivers/char/tpm/Kconfig | 39 ++ drivers/char/tpm/Makefile|7 drivers/char/tpm/tpm.c | 697 +++ drivers/char/tpm/tpm.h | 92 + drivers/char/tpm/tpm_atmel.c | 216 + drivers/char/tpm/tpm_nsc.c | 372 ++ include/linux/pci_ids.h |1 9 files changed, 1427 insertions(+), 1 deletion(-) diff -Nru a/drivers/char/Kconfig b/drivers/char/Kconfig --- a/drivers/char/Kconfig 2005-03-09 16:40:26 -08:00 +++ b/drivers/char/Kconfig 2005-03-09 16:40:26 -08:00 @@ -995,5 +995,7 @@ The mmtimer device allows direct userspace access to the Altix system timer. +source drivers/char/tpm/Kconfig + endmenu diff -Nru a/drivers/char/Makefile b/drivers/char/Makefile --- a/drivers/char/Makefile 2005-03-09 16:40:26 -08:00 +++ b/drivers/char/Makefile 2005-03-09 16:40:26 -08:00 @@ -89,7 +89,7 @@ obj-$(CONFIG_IPMI_HANDLER) += ipmi/ obj-$(CONFIG_HANGCHECK_TIMER) += hangcheck-timer.o - +obj-$(CONFIG_TCG_TPM) += tpm/ # Files generated that shall be removed upon make clean clean-files := consolemap_deftbl.c defkeymap.c qtronixmap.c diff -Nru a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/char/tpm/Kconfig 2005-03-09 16:40:26 -08:00 @@ -0,0 +1,39 @@ +# +# TPM device configuration +# + +menu TPM devices + +config TCG_TPM + tristate TPM Hardware Support + depends on EXPERIMENTAL + ---help--- + If you have a TPM security chip in your system, which + implements the Trusted Computing Group's specification, + say Yes and it will be accessible from within Linux. For + more information see http://www.trustedcomputinggroup.org. + An implementation of the Trusted Software Stack (TSS), the + userspace enablement piece of the specification, can be + obtained at: http://sourceforge.net/projects/trousers. To + compile this driver as a module, choose M here; the module + will be called tpm. If unsure, say N. + +config TCG_NSC + tristate National Semiconductor TPM Interface + depends on TCG_TPM + ---help--- + If you have a TPM security chip from National Semicondutor + say Yes and it will be accessible from within Linux. To + compile this driver as a module, choose M here; the module + will be called tpm_nsc. + +config TCG_ATMEL + tristate Atmel TPM Interface + depends on TCG_TPM + ---help--- + If you have a TPM security chip from Atmel say Yes and it + will be accessible from within Linux. To compile this driver + as a module, choose M here; the module will be called tpm_atmel. + +endmenu + diff -Nru a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/char/tpm/Makefile 2005-03-09 16:40:26 -08:00 @@ -0,0 +1,7 @@ +# +# Makefile for the kernel tpm device drivers. +# +obj-$(CONFIG_TCG_TPM) += tpm.o +obj-$(CONFIG_TCG_NSC) += tpm_nsc.o +obj-$(CONFIG_TCG_ATMEL) += tpm_atmel.o + diff -Nru a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/char/tpm/tpm.c2005-03-09 16:40:26 -08:00 @@ -0,0 +1,697 @@ +/* + * Copyright (C) 2004 IBM Corporation + * + * Authors: + * Leendert van Doorn [EMAIL PROTECTED] + * Dave Safford [EMAIL PROTECTED] + * Reiner Sailer [EMAIL PROTECTED] + * Kylene Hall [EMAIL PROTECTED] + * + * Maintained by: [EMAIL PROTECTED] + * + * Device driver for TCG/TCPA TPM (trusted platform module). + * Specifications at www.trustedcomputinggroup.org + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation, version 2 of the + * License. + * + * Note, the TPM chip is not interrupt driven (only polling) + * and can have very long timeouts (minutes!). Hence the unusual + * calls to schedule_timeout. + * + */ + +#include
[PATCH] Reduce cacheline bouncing in cpu_idle_wait
Andi noted that during normal runtime cpu_idle_map is bounced around a
lot, and occassionally at a higher frequency than the timer interrupt
wakeup which we normally exit pm_idle from. So switch to a percpu
variable. Andi i didn't move things to the slow path because it would
involve adding scheduler code to wakeup the idle thread on the cpus we're
waiting for.
arch/i386/kernel/process.c | 28
arch/ia64/kernel/process.c | 39 +--
arch/x86_64/kernel/process.c | 38 +-
3 files changed, 70 insertions(+), 35 deletions(-)
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.11-mm2/arch/i386/kernel/process.c
===
RCS file: /home/cvsroot/linux-2.6.11-mm2/arch/i386/kernel/process.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 process.c
--- linux-2.6.11-mm2/arch/i386/kernel/process.c 8 Mar 2005 13:53:27 -
1.1.1.1
+++ linux-2.6.11-mm2/arch/i386/kernel/process.c 10 Mar 2005 02:02:33 -
@@ -78,7 +78,7 @@ unsigned long thread_saved_pc(struct tas
* Powermanagement idle function, if any..
*/
void (*pm_idle)(void);
-static cpumask_t cpu_idle_map;
+static DEFINE_PER_CPU(unsigned int, cpu_idle_state);
void disable_hlt(void)
{
@@ -185,9 +185,10 @@ void cpu_idle (void)
while (1) {
while (!need_resched()) {
void (*idle)(void);
-
- if (cpu_isset(cpu, cpu_idle_map))
- cpu_clear(cpu, cpu_idle_map);
+
+ if (__get_cpu_var(cpu_idle_state))
+ __get_cpu_var(cpu_idle_state) = 0;
+
rmb();
idle = pm_idle;
@@ -206,16 +207,27 @@ void cpu_idle (void)
void cpu_idle_wait(void)
{
- int cpu;
+ unsigned int cpu, this_cpu = get_cpu();
cpumask_t map;
- for_each_online_cpu(cpu)
- cpu_set(cpu, cpu_idle_map);
+ set_cpus_allowed(current, cpumask_of_cpu(this_cpu));
+ put_cpu();
+
+ for_each_online_cpu(cpu) {
+ per_cpu(cpu_idle_state, cpu) = 1;
+ cpu_set(cpu, map);
+ }
+
+ __get_cpu_var(cpu_idle_state) = 0;
wmb();
do {
ssleep(1);
- cpus_and(map, cpu_idle_map, cpu_online_map);
+ for_each_online_cpu(cpu) {
+ if (cpu_isset(cpu, map) !per_cpu(cpu_idle_state,
cpu))
+ cpu_clear(cpu, map);
+ }
+ cpus_and(map, map, cpu_online_map);
} while (!cpus_empty(map));
}
EXPORT_SYMBOL_GPL(cpu_idle_wait);
Index: linux-2.6.11-mm2/arch/ia64/kernel/process.c
===
RCS file: /home/cvsroot/linux-2.6.11-mm2/arch/ia64/kernel/process.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 process.c
--- linux-2.6.11-mm2/arch/ia64/kernel/process.c 8 Mar 2005 13:53:34 -
1.1.1.1
+++ linux-2.6.11-mm2/arch/ia64/kernel/process.c 10 Mar 2005 01:22:49 -
@@ -49,7 +49,7 @@
#include sigframe.h
void (*ia64_mark_idle)(int);
-static cpumask_t cpu_idle_map;
+static DEFINE_PER_CPU(unsigned int, cpu_idle_map);
unsigned long boot_option_idle_override = 0;
EXPORT_SYMBOL(boot_option_idle_override);
@@ -229,20 +229,30 @@ static inline void play_dead(void)
}
#endif /* CONFIG_HOTPLUG_CPU */
-
void cpu_idle_wait(void)
{
-int cpu;
-cpumask_t map;
+ unsigned int cpu, this_cpu = get_cpu();
+ cpumask_t map;
+
+ set_cpus_allowed(current, cpumask_of_cpu(this_cpu));
+ put_cpu();
-for_each_online_cpu(cpu)
-cpu_set(cpu, cpu_idle_map);
+ for_each_online_cpu(cpu) {
+ per_cpu(cpu_idle_state, cpu) = 1;
+ cpu_set(cpu, map);
+ }
-wmb();
-do {
-ssleep(1);
-cpus_and(map, cpu_idle_map, cpu_online_map);
-} while (!cpus_empty(map));
+ __get_cpu_var(cpu_idle_state) = 0;
+
+ wmb();
+ do {
+ ssleep(1);
+ for_each_online_cpu(cpu) {
+ if (cpu_isset(cpu, map) !per_cpu(cpu_idle_state,
cpu))
+ cpu_clear(cpu, map);
+ }
+ cpus_and(map, map, cpu_online_map);
+ } while (!cpus_empty(map));
}
EXPORT_SYMBOL_GPL(cpu_idle_wait);
@@ -261,12 +271,13 @@ cpu_idle (void)
while (!need_resched()) {
void (*idle)(void);
+ if (__get_cpu_var(cpu_idle_state))
+ __get_cpu_var(cpu_idle_state) = 0;
+
+ rmb();
if (mark_idle)
(*mark_idle)(1);
-
[PATCH] tpm-build-fix
ChangeSet 1.2039, 2005/03/09 10:13:34-08:00, [EMAIL PROTECTED] [PATCH] tpm-build-fix drivers/char/tpm/tpm.c: In function `show_pcrs': drivers/char/tpm/tpm.c:228: warning: passing arg 1 of `tpm_transmit' from incompatible pointer type drivers/char/tpm/tpm.c:238: warning: passing arg 1 of `tpm_transmit' from incompatible pointer type Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] drivers/char/tpm/tpm.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Nru a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c --- a/drivers/char/tpm/tpm.c2005-03-09 16:39:58 -08:00 +++ b/drivers/char/tpm/tpm.c2005-03-09 16:39:58 -08:00 @@ -219,7 +219,7 @@ int i, j, index, num_pcrs; char *str = buf; - struct tpm_chp *chip = + struct tpm_chip *chip = pci_get_drvdata(container_of(dev, struct pci_dev, dev)); if (chip == NULL) return -ENODEV; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BK PATCH] Add TPM driver support for 2.6.11
Hi, Here are a few changesets that add support for TPM drivers. These patches have all been in the -mm releases for a while now. Please pull from: bk://kernel.bkbits.net/gregkh/linux/2.6.11/tpm Individual patches will follow, sent to the linux-kernel list. thanks, greg k-h drivers/char/Kconfig |2 drivers/char/Makefile|2 drivers/char/tpm/Kconfig | 39 ++ drivers/char/tpm/Makefile|7 drivers/char/tpm/tpm.c | 715 ++- drivers/char/tpm/tpm.h | 92 + drivers/char/tpm/tpm_atmel.c | 218 + drivers/char/tpm/tpm_nsc.c | 375 ++ include/linux/pci_ids.h |1 9 files changed, 1439 insertions(+), 12 deletions(-) - kjhall:us.ibm.com: o tpm: fix cause of SMP stack traces o Add TPM hardware enablement driver Andrew Morton: o tpm-build-fix o tpm_atmel build fix o tpm_msc-build-fix - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.2
On Thu, Mar 10, 2005 at 02:46:29AM +0100, Bodo Eggert wrote: Bill Davidsen [EMAIL PROTECTED] wrote: I think you need both x.y.z=x.y.z.N and x.y.z.N-1=x.y.z.N patches. My systems which are following the -stable will just need the most recent, but doing x.y.z-1=x.y.z.N gets really ugly for higher values of N. bzcat ../patch-2.6.nn.[0-9].*|patch -p1 You left out the steps where you fetch them and verify their signatures. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.11- sym53c8xx Broken on pp64
Benjamin Herrenschmidt wrote: Are you sure it's plain 2.6.11 and not some bk clone of after 2.6.11 was released ? Ben - I am in the process of downloading a clean tarball from kernel.org to be 100% certain. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] floppy.c: pass physical device to device registration
ChangeSet 1.2047, 2005/03/09 09:53:08-08:00, [EMAIL PROTECTED]
[PATCH] floppy.c: pass physical device to device registration
With this patch the floppy driver creates the usual symlink in sysfs to
the physical device backing the block device:
$tree /sys/block/
/sys/block/
|-- fd0
| |-- dev
| |-- device - ../../devices/platform/floppy0
...
Signed-off-by: Kay Sievers [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/block/floppy.c | 19 ++-
1 files changed, 6 insertions(+), 13 deletions(-)
diff -Nru a/drivers/block/floppy.c b/drivers/block/floppy.c
--- a/drivers/block/floppy.c2005-03-09 16:28:59 -08:00
+++ b/drivers/block/floppy.c2005-03-09 16:28:59 -08:00
@@ -4370,6 +4370,10 @@
goto out_flush_work;
}
+ err = platform_device_register(floppy_device);
+ if (err)
+ goto out_flush_work;
+
for (drive = 0; drive N_DRIVE; drive++) {
if (!(allowed_drive_mask (1 drive)))
continue;
@@ -4379,23 +4383,12 @@
disks[drive]-private_data = (void *)(long)drive;
disks[drive]-queue = floppy_queue;
disks[drive]-flags |= GENHD_FL_REMOVABLE;
+ disks[drive]-driverfs_dev = floppy_device.dev;
add_disk(disks[drive]);
}
- err = platform_device_register(floppy_device);
- if (err)
- goto out_del_disk;
-
return 0;
-out_del_disk:
- for (drive = 0; drive N_DRIVE; drive++) {
- if (!(allowed_drive_mask (1 drive)))
- continue;
- if (fdc_state[FDC(drive)].version == FDC_NONE)
- continue;
- del_gendisk(disks[drive]);
- }
out_flush_work:
flush_scheduled_work();
if (usage_count)
@@ -4600,7 +4593,6 @@
int drive;
init_completion(device_release);
- platform_device_unregister(floppy_device);
blk_unregister_region(MKDEV(FLOPPY_MAJOR, 0), 256);
unregister_blkdev(FLOPPY_MAJOR, fd);
@@ -4614,6 +4606,7 @@
}
put_disk(disks[drive]);
}
+ platform_device_unregister(floppy_device);
devfs_remove(floppy);
del_timer_sync(fd_timeout);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] debufs: make built in types add a \n to their output
ChangeSet 1.2033, 2005/03/09 15:24:07-08:00, [EMAIL PROTECTED] [PATCH] debufs: make built in types add a \n to their output Thanks to Alessandro Rubini [EMAIL PROTECTED] for pointing this out. Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] fs/debugfs/file.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Nru a/fs/debugfs/file.c b/fs/debugfs/file.c --- a/fs/debugfs/file.c 2005-03-09 16:23:09 -08:00 +++ b/fs/debugfs/file.c 2005-03-09 16:23:09 -08:00 @@ -52,7 +52,7 @@ char buf[32]; \ type *val = file-private_data; \ \ - snprintf(buf, sizeof(buf), format, *val); \ + snprintf(buf, sizeof(buf), format \n, *val); \ return simple_read_from_buffer(user_buf, count, ppos, buf, strlen(buf));\ } \ static ssize_t write_file_##type(struct file *file, const char __user *user_buf,\ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BK PATCH] Add Superhighway bus support for 2.6.11
Hi, Here is one changeset that adds superhighway bus support to the 2.6.11 kernel. It has been in the -mm releases for a while. Please pull from: bk://kernel.bkbits.net/gregkh/linux/2.6.11/sh Individual patches will follow, sent to the linux-kernel list. thanks, greg k-h drivers/sh/Makefile |6 drivers/sh/superhyway/Makefile |7 + drivers/sh/superhyway/superhyway-sysfs.c | 45 ++ drivers/sh/superhyway/superhyway.c | 201 +++ include/linux/superhyway.h | 79 5 files changed, 338 insertions(+) - Paul Mundt: o Add SuperHyway bus subsystem - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block core: export MAJOR/MINOR to the hotplug env
ChangeSet 1.2040, 2005/03/09 09:32:58-08:00, [EMAIL PROTECTED]
[PATCH] block core: export MAJOR/MINOR to the hotplug env
Signed-off-by: Kay Sievers [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/block/genhd.c | 53 --
1 files changed, 34 insertions(+), 19 deletions(-)
diff -Nru a/drivers/block/genhd.c b/drivers/block/genhd.c
--- a/drivers/block/genhd.c 2005-03-09 16:29:48 -08:00
+++ b/drivers/block/genhd.c 2005-03-09 16:29:48 -08:00
@@ -430,42 +430,57 @@
static int block_hotplug(struct kset *kset, struct kobject *kobj, char **envp,
int num_envp, char *buffer, int buffer_size)
{
- struct device *dev = NULL;
struct kobj_type *ktype = get_ktype(kobj);
+ struct device *physdev;
+ struct gendisk *disk;
+ struct hd_struct *part;
int length = 0;
int i = 0;
- /* get physical device backing disk or partition */
if (ktype == ktype_block) {
- struct gendisk *disk = container_of(kobj, struct gendisk, kobj);
- dev = disk-driverfs_dev;
+ disk = container_of(kobj, struct gendisk, kobj);
+ add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size,
+ length, MINOR=%u, disk-first_minor);
} else if (ktype == ktype_part) {
- struct gendisk *disk = container_of(kobj-parent, struct
gendisk, kobj);
- dev = disk-driverfs_dev;
- }
-
- if (dev) {
- /* add physical device, backing this device */
- char *path = kobject_get_path(dev-kobj, GFP_KERNEL);
+ disk = container_of(kobj-parent, struct gendisk, kobj);
+ part = container_of(kobj, struct hd_struct, kobj);
+ add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size,
+ length, MINOR=%u,
+ disk-first_minor + part-partno);
+ } else
+ return 0;
+
+ add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size, length,
+ MAJOR=%u, disk-major);
+
+ /* add physical device, backing this device */
+ physdev = disk-driverfs_dev;
+ if (physdev) {
+ char *path = kobject_get_path(physdev-kobj, GFP_KERNEL);
add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size,
length, PHYSDEVPATH=%s, path);
kfree(path);
- /* add bus name of physical device */
- if (dev-bus)
+ if (physdev-bus)
add_hotplug_env_var(envp, num_envp, i,
buffer, buffer_size, length,
- PHYSDEVBUS=%s, dev-bus-name);
+ PHYSDEVBUS=%s,
+ physdev-bus-name);
- /* add driver name of physical device */
- if (dev-driver)
+ if (physdev-driver)
add_hotplug_env_var(envp, num_envp, i,
buffer, buffer_size, length,
- PHYSDEVDRIVER=%s,
dev-driver-name);
-
- envp[i] = NULL;
+ PHYSDEVDRIVER=%s,
+ physdev-driver-name);
}
+
+ /* terminate, set to next free slot, shrink available space */
+ envp[i] = NULL;
+ envp = envp[i];
+ num_envp -= i;
+ buffer = buffer[length];
+ buffer_size -= length;
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] class: add a semaphore to struct class, and use that instead of the subsystem rwsem.
ChangeSet 1.2055, 2005/03/09 15:41:29-08:00, [EMAIL PROTECTED]
[PATCH] class: add a semaphore to struct class, and use that instead of the
subsystem rwsem.
This moves us away from using the rwsem, although recursive adds and removes of
class devices
is not yet possible (nor is it really known if it even is needed.) So this
simple change is
done instead.
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/base/class.c | 23 +++
include/linux/device.h |2 +-
2 files changed, 12 insertions(+), 13 deletions(-)
diff -Nru a/drivers/base/class.c b/drivers/base/class.c
--- a/drivers/base/class.c 2005-03-09 16:28:04 -08:00
+++ b/drivers/base/class.c 2005-03-09 16:28:04 -08:00
@@ -140,6 +140,7 @@
INIT_LIST_HEAD(cls-children);
INIT_LIST_HEAD(cls-interfaces);
+ init_MUTEX(cls-sem);
error = kobject_set_name(cls-subsys.kset.kobj, %s, cls-name);
if (error)
return error;
@@ -413,12 +414,12 @@
/* now take care of our own registration */
if (parent) {
- down_write(parent-subsys.rwsem);
+ down(parent-sem);
list_add_tail(class_dev-node, parent-children);
list_for_each_entry(class_intf, parent-interfaces, node)
if (class_intf-add)
class_intf-add(class_dev);
- up_write(parent-subsys.rwsem);
+ up(parent-sem);
}
if (MAJOR(class_dev-devt))
@@ -448,12 +449,12 @@
struct class_interface * class_intf;
if (parent) {
- down_write(parent-subsys.rwsem);
+ down(parent-sem);
list_del_init(class_dev-node);
list_for_each_entry(class_intf, parent-interfaces, node)
if (class_intf-remove)
class_intf-remove(class_dev);
- up_write(parent-subsys.rwsem);
+ up(parent-sem);
}
if (class_dev-dev)
@@ -509,8 +510,8 @@
int class_interface_register(struct class_interface *class_intf)
{
- struct class * parent;
- struct class_device * class_dev;
+ struct class *parent;
+ struct class_device *class_dev;
if (!class_intf || !class_intf-class)
return -ENODEV;
@@ -519,14 +520,13 @@
if (!parent)
return -EINVAL;
- down_write(parent-subsys.rwsem);
+ down(parent-sem);
list_add_tail(class_intf-node, parent-interfaces);
-
if (class_intf-add) {
list_for_each_entry(class_dev, parent-children, node)
class_intf-add(class_dev);
}
- up_write(parent-subsys.rwsem);
+ up(parent-sem);
return 0;
}
@@ -539,14 +539,13 @@
if (!parent)
return;
- down_write(parent-subsys.rwsem);
+ down(parent-sem);
list_del_init(class_intf-node);
-
if (class_intf-remove) {
list_for_each_entry(class_dev, parent-children, node)
class_intf-remove(class_dev);
}
- up_write(parent-subsys.rwsem);
+ up(parent-sem);
class_put(parent);
}
diff -Nru a/include/linux/device.h b/include/linux/device.h
--- a/include/linux/device.h2005-03-09 16:28:04 -08:00
+++ b/include/linux/device.h2005-03-09 16:28:04 -08:00
@@ -15,7 +15,6 @@
#include linux/ioport.h
#include linux/kobject.h
#include linux/list.h
-#include linux/spinlock.h
#include linux/types.h
#include linux/module.h
#include linux/pm.h
@@ -148,6 +147,7 @@
struct subsystemsubsys;
struct list_headchildren;
struct list_headinterfaces;
+ struct semaphoresem;/* locks both the children and
interfaces lists */
struct class_attribute * class_attrs;
struct class_device_attribute * class_dev_attrs;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] aoe: fail IO on disk errors
ChangeSet 1.2038, 2005/03/09 10:21:33-08:00, [EMAIL PROTECTED]
[PATCH] aoe: fail IO on disk errors
This patch makes disk errors fail the IO instead of getting logged and
ignored.
Fail IO on disk errors
Signed-off-by: Ed L. Cashin [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/block/aoe/aoecmd.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff -Nru a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
--- a/drivers/block/aoe/aoecmd.c2005-03-09 16:15:53 -08:00
+++ b/drivers/block/aoe/aoecmd.c2005-03-09 16:15:53 -08:00
@@ -416,7 +416,9 @@
if (ahin-cmdstat 0xa9) { /* these bits cleared on success */
printk(KERN_CRIT aoe: aoecmd_ata_rsp: ata error cmd=%2.2Xh
- stat=%2.2Xh\n, ahout-cmdstat, ahin-cmdstat);
+ stat=%2.2Xh from e%ld.%ld\n,
+ ahout-cmdstat, ahin-cmdstat,
+ d-aoemajor, d-aoeminor);
if (buf)
buf-flags |= BUFFL_FAIL;
} else {
@@ -458,8 +460,8 @@
if (buf) {
buf-nframesout -= 1;
if (buf-nframesout == 0 buf-resid == 0) {
- n = !(buf-flags BUFFL_FAIL);
- bio_endio(buf-bio, buf-bio-bi_size, 0);
+ n = (buf-flags BUFFL_FAIL) ? -EIO : 0;
+ bio_endio(buf-bio, buf-bio-bi_size, n);
mempool_free(buf, d-bufpool);
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] Add SuperHyway bus subsystem
ChangeSet 1.2027.3.1, 2005/03/09 12:14:18-08:00, [EMAIL PROTECTED]
[PATCH] Add SuperHyway bus subsystem
Signed-off-by: Paul Mundt [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/sh/Makefile |6
drivers/sh/superhyway/Makefile |7 +
drivers/sh/superhyway/superhyway-sysfs.c | 45 ++
drivers/sh/superhyway/superhyway.c | 201 +++
include/linux/superhyway.h | 79
5 files changed, 338 insertions(+)
diff -Nru a/drivers/sh/Makefile b/drivers/sh/Makefile
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/sh/Makefile 2005-03-09 16:36:31 -08:00
@@ -0,0 +1,6 @@
+#
+# Makefile for the SuperH specific drivers.
+#
+
+obj-$(CONFIG_SUPERHYWAY) += superhyway/
+
diff -Nru a/drivers/sh/superhyway/Makefile b/drivers/sh/superhyway/Makefile
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/sh/superhyway/Makefile2005-03-09 16:36:31 -08:00
@@ -0,0 +1,7 @@
+#
+# Makefile for the SuperHyway bus drivers.
+#
+
+obj-$(CONFIG_SUPERHYWAY) += superhyway.o
+obj-$(CONFIG_SYSFS)+= superhyway-sysfs.o
+
diff -Nru a/drivers/sh/superhyway/superhyway-sysfs.c
b/drivers/sh/superhyway/superhyway-sysfs.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/sh/superhyway/superhyway-sysfs.c 2005-03-09 16:36:31 -08:00
@@ -0,0 +1,45 @@
+/*
+ * drivers/sh/superhyway/superhyway-sysfs.c
+ *
+ * SuperHyway Bus sysfs interface
+ *
+ * Copyright (C) 2004, 2005 Paul Mundt [EMAIL PROTECTED]
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+#include linux/kernel.h
+#include linux/device.h
+#include linux/types.h
+#include linux/superhyway.h
+
+#define superhyway_ro_attr(name, fmt, field) \
+static ssize_t name##_show(struct device *dev, char *buf) \
+{ \
+ struct superhyway_device *s = to_superhyway_device(dev);\
+ return sprintf(buf, fmt, s-field); \
+}
+
+/* VCR flags */
+superhyway_ro_attr(perr_flags, 0x%02x\n, vcr.perr_flags);
+superhyway_ro_attr(merr_flags, 0x%02x\n, vcr.merr_flags);
+superhyway_ro_attr(mod_vers, 0x%04x\n, vcr.mod_vers);
+superhyway_ro_attr(mod_id, 0x%04x\n, vcr.mod_id);
+superhyway_ro_attr(bot_mb, 0x%02x\n, vcr.bot_mb);
+superhyway_ro_attr(top_mb, 0x%02x\n, vcr.top_mb);
+
+/* Misc */
+superhyway_ro_attr(resource, 0x%08lx\n, resource.start);
+
+struct device_attribute superhyway_dev_attrs[] = {
+ __ATTR_RO(perr_flags),
+ __ATTR_RO(merr_flags),
+ __ATTR_RO(mod_vers),
+ __ATTR_RO(mod_id),
+ __ATTR_RO(bot_mb),
+ __ATTR_RO(top_mb),
+ __ATTR_RO(resource),
+ __ATTR_NULL,
+};
+
diff -Nru a/drivers/sh/superhyway/superhyway.c
b/drivers/sh/superhyway/superhyway.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/sh/superhyway/superhyway.c2005-03-09 16:36:31 -08:00
@@ -0,0 +1,201 @@
+/*
+ * drivers/sh/superhyway/superhyway.c
+ *
+ * SuperHyway Bus Driver
+ *
+ * Copyright (C) 2004, 2005 Paul Mundt [EMAIL PROTECTED]
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+#include linux/kernel.h
+#include linux/device.h
+#include linux/init.h
+#include linux/module.h
+#include linux/types.h
+#include linux/list.h
+#include linux/superhyway.h
+
+static int superhyway_devices;
+
+static struct device superhyway_bus_device = {
+ .bus_id = superhyway,
+};
+
+static void superhyway_device_release(struct device *dev)
+{
+ kfree(to_superhyway_device(dev));
+}
+
+/**
+ * superhyway_add_device - Add a SuperHyway module
+ * @mod_id: Module ID (taken from MODULE.VCR.MOD_ID).
+ * @base: Physical address where module is mapped.
+ * @vcr: VCR value.
+ *
+ * This is responsible for adding a new SuperHyway module. This sets up a new
+ * struct superhyway_device for the module being added. Each one of @mod_id,
+ * @base, and @vcr are registered with the new device for further use
+ * elsewhere.
+ *
+ * Devices are initially added in the order that they are scanned (from the
+ * top-down of the memory map), and are assigned an ID based on the order that
+ * they are added. Any manual addition of a module will thus get the ID after
+ * the devices already discovered regardless of where it resides in memory.
+ *
+ * Further work can and should be done in superhyway_scan_bus(), to be sure
+ * that any new modules are properly discovered and subsequently registered.
+ */
+int superhyway_add_device(unsigned int mod_id, unsigned long base,
+ unsigned long long vcr)
+{
+ struct superhyway_device *dev;
+
+ dev = kmalloc(sizeof(struct superhyway_device), GFP_KERNEL);
+
Re: [PATCH 1/2] No-exec support for ppc64
On Tue, Mar 08, 2005 at 05:08:26PM -0600, Jake Moilanen wrote: No-exec base and user space support for PPC64. Hi, a couple of comments below. -Olof @@ -786,6 +786,7 @@ int hash_huge_page(struct mm_struct *mm, pte_t old_pte, new_pte; unsigned long hpteflags, prpn; long slot; + int is_exec; int err = 1; spin_lock(mm-page_table_lock); @@ -796,6 +797,10 @@ int hash_huge_page(struct mm_struct *mm, va = (vsid 28) | (ea 0x0fff); vpn = va HPAGE_SHIFT; + is_exec = access _PAGE_EXEC; + if (unlikely(is_exec !(pte_val(*ptep) _PAGE_EXEC))) + goto out; You only use is_exec this one time, you can probably skip it and just add the mask in the if statement. @@ -898,6 +908,7 @@ repeat: err = 0; out: + spin_unlock(mm-page_table_lock); Whitespace change diff -puN include/asm-ppc64/pgtable.h~nx-user-ppc64 include/asm-ppc64/pgtable.h --- linux-2.6-bk/include/asm-ppc64/pgtable.h~nx-user-ppc642005-03-08 16:08:54 -06:00 +++ linux-2.6-bk-moilanen/include/asm-ppc64/pgtable.h 2005-03-08 16:08:54 -06:00 @@ -82,14 +82,14 @@ #define _PAGE_PRESENT0x0001 /* software: pte contains a translation */ #define _PAGE_USER 0x0002 /* matches one of the PP bits */ #define _PAGE_FILE 0x0002 /* (!present only) software: pte holds file offset */ -#define _PAGE_RW 0x0004 /* software: user write access allowed */ +#define _PAGE_EXEC 0x0004 /* No execute on POWER4 and newer (we invert) */ Good to see the comment there, I remember we talked about that earlier. It can be somewhat confusing. :-) #define _PAGE_GUARDED0x0008 #define _PAGE_COHERENT 0x0010 /* M: enforce memory coherence (SMP systems) */ #define _PAGE_NO_CACHE 0x0020 /* I: cache inhibit */ #define _PAGE_WRITETHRU 0x0040 /* W: cache write-through */ #define _PAGE_DIRTY 0x0080 /* C: page changed */ #define _PAGE_ACCESSED 0x0100 /* R: page referenced */ -#define _PAGE_EXEC 0x0200 /* software: i-cache coherence required */ +#define _PAGE_RW 0x0200 /* software: user write access allowed */ #define _PAGE_HASHPTE0x0400 /* software: pte has an associated HPTE */ #define _PAGE_BUSY 0x0800 /* software: PTE hash are busy */ #define _PAGE_SECONDARY 0x8000 /* software: HPTE is in secondary group */ @@ -100,7 +100,7 @@ /* PAGE_MASK gives the right answer below, but only by accident */ /* It should be preserving the high 48 bits and then specifically */ /* preserving _PAGE_SECONDARY | _PAGE_GROUP_IX */ -#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_HPTEFLAGS) +#define _PAGE_CHG_MASK (_PAGE_GUARDED | _PAGE_COHERENT | _PAGE_NO_CACHE | _PAGE_WRITETHRU | _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_HPTEFLAGS | PAGE_MASK) Can you break it into 80 columns with \ ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] No-exec support for ppc64
Hi,
On Tue, Mar 08, 2005 at 05:13:26PM -0600, Jake Moilanen wrote:
diff -puN arch/ppc64/mm/hash_utils.c~nx-kernel-ppc64
arch/ppc64/mm/hash_utils.c
--- linux-2.6-bk/arch/ppc64/mm/hash_utils.c~nx-kernel-ppc64 2005-03-08
16:08:57 -06:00
+++ linux-2.6-bk-moilanen/arch/ppc64/mm/hash_utils.c 2005-03-08 16:08:57
-06:00
@@ -89,12 +90,23 @@ static inline void loop_forever(void)
;
}
+int is_kernel_text(unsigned long addr)
+{
+ if (addr = (unsigned long)_stext addr (unsigned long)__init_end)
+ return 1;
+
+ return 0;
+}
This is used in two files, but never declared extern in the second file
(iSeries_setup.c). Should it go in a header file as a static inline
instead?
There also seems to be a local static is_kernel_text() in kallsyms that
overlaps (but it's not identical). Removing that redundancy can be taken
care of as a janitorial patch outside of the noexec stuff.
-Olof
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bk commits and dates
On Thu, 10 Mar 2005, Benjamin Herrenschmidt wrote: I don't know if I'm the only one to have a problem with that, but it would be nice if it was possible, when you pull a bk tree, to have the commit messages for the csets in that tree be dated from the day you pulled, and not the day when they went in the source tree. Nope, that's against how BK works. It's really distributed, so my tree has no special meaning, and as such the fact that I pull has no meaning either - it doesn't trigger as anything special. The only thing that ends up being special is when it hits the public tree which has the trigger to send out the emails. IOW, the date of the _email_ is special (in that it says when a commit hit the public tree), not not the commits changesets themselves. Now, if James trigger scripts set the date of the email by the date of the commit, that sounds like a misfeature, but you'd better talk to James, not me, since he's the one doing that part.. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] videodev: pass dev_t to the class core
ChangeSet 1.2044, 2005/03/09 09:52:10-08:00, [EMAIL PROTECTED]
[PATCH] videodev: pass dev_t to the class core
Signed-off-by: Kay Sievers [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/media/video/videodev.c | 11 +--
1 files changed, 1 insertion(+), 10 deletions(-)
diff -Nru a/drivers/media/video/videodev.c b/drivers/media/video/videodev.c
--- a/drivers/media/video/videodev.c2005-03-09 16:29:20 -08:00
+++ b/drivers/media/video/videodev.c2005-03-09 16:29:20 -08:00
@@ -46,15 +46,7 @@
return sprintf(buf,%.*s\n,(int)sizeof(vfd-name),vfd-name);
}
-static ssize_t show_dev(struct class_device *cd, char *buf)
-{
- struct video_device *vfd = container_of(cd, struct video_device,
class_dev);
- dev_t dev = MKDEV(VIDEO_MAJOR, vfd-minor);
- return print_dev_t(buf,dev);
-}
-
static CLASS_DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
-static CLASS_DEVICE_ATTR(dev, S_IRUGO, show_dev, NULL);
struct video_device *video_device_alloc(void)
{
@@ -347,12 +339,11 @@
if (vfd-dev)
vfd-class_dev.dev = vfd-dev;
vfd-class_dev.class = video_class;
+ vfd-class_dev.devt = MKDEV(VIDEO_MAJOR, vfd-minor);
strlcpy(vfd-class_dev.class_id, vfd-devfs_name + 4, BUS_ID_SIZE);
class_device_register(vfd-class_dev);
class_device_create_file(vfd-class_dev,
class_device_attr_name);
- class_device_create_file(vfd-class_dev,
-class_device_attr_dev);
#if 1 /* needed until all drivers are fixed */
if (!vfd-release)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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-fbdev-devel] [announce 0/7] fbsplash - The Framebuffer Splash
Christoph Hellwig wrote: On Wed, Mar 09, 2005 at 12:38:42PM +0100, Pavel Machek wrote: Fbsplash - The Framebuffer Splash - is a feature that allows displaying images in the background of consoles that use fbcon. The project is partially descended from bootsplash. What are you trying to do exactly? I really don't see the point of this patch. At least some Debians, While there might be a kernel-patch-bootsplash package in Debian none of the shipped binary kernels use this. The standard Ubuntu kernel does. Regards, sebas -- http://vizZzion.org | GPG Key ID: 9119 0EF9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - One is not superior merely because one sees the world as odious. - Chateaubriand (1768-1848) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.11- sym53c8xx Broken on pp64
Omkhar Arasaratnam wrote: Benjamin Herrenschmidt wrote: Are you sure it's plain 2.6.11 and not some bk clone of after 2.6.11 was released ? Ben - I am in the process of downloading a clean tarball from kernel.org to be 100% certain. I confirmed that this occurs with the 2.6.11 code straight from kernel.org Here is an error from the bringup: sym0: No NVRAM, ID 7, Fast-80 LVD, parity checking CACHE TEST FAILED: DMA error (dstat=0xa0) .sym0: CACHE INCORRECTLY CONFIGURED sym0: giving up ... ideas? Omkhar - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] aoe: update documentation for udev users
ChangeSet 1.2037, 2005/03/09 10:21:15-08:00, [EMAIL PROTECTED] [PATCH] aoe: update documentation for udev users Bodo Eggert [EMAIL PROTECTED] writes: Ed L Cashin [EMAIL PROTECTED] wrote: +if=A0test=A0-z=A0$conf;=A0then +=A0=A0=A0=A0=A0=A0=A0=A0conf=3D`find=A0/etc=A0-type=A0f=A0-name=A0udev= .conf=A02=A0/dev/null` +fi +if=A0test=A0-z=A0$conf=A0||=A0test=A0!=A0-r=A0$conf;=A0then +=A0=A0=A0=A0=A0=A0=A0=A0echo=A0$me=A0Error:=A0could=A0not=A0find=A0rea= dable=A0udev.conf=A0in=A0/etc=A012 +=A0=A0=A0=A0=A0=A0=A0=A0exit=A01 +fi This will fail and print --- bash: test: etc/udev.conf: binary operator expected --- if there is more than one udev.conf. Fix: Always put quotes around variables. Thanks. With the changes below, it still will complain if it finds more than one udev.conf, but only if /etc/udev/udev.conf doesn't exist. Quote all shell variables, and use /etc/udev/udev.conf if available. Signed-off-by: Ed L. Cashin [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] Documentation/aoe/udev-install.sh | 14 +- 1 files changed, 9 insertions(+), 5 deletions(-) diff -Nru a/Documentation/aoe/udev-install.sh b/Documentation/aoe/udev-install.sh --- a/Documentation/aoe/udev-install.sh 2005-03-09 16:16:00 -08:00 +++ b/Documentation/aoe/udev-install.sh 2005-03-09 16:16:00 -08:00 @@ -8,11 +8,15 @@ # (or environment can specify where to find udev.conf) # if test -z $conf; then - conf=`find /etc -type f -name udev.conf 2 /dev/null` -fi -if test -z $conf || test ! -r $conf; then - echo $me Error: could not find readable udev.conf in /etc 12 - exit 1 + if test -r /etc/udev/udev.conf; then + conf=/etc/udev/udev.conf + else + conf=`find /etc -type f -name udev.conf 2 /dev/null` + if test -z $conf || test ! -r $conf; then + echo $me Error: no udev.conf found 12 + exit 1 + fi + fi fi # find the directory where udev rules are stored, often - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bk commits and dates
Two's company ... On Thu, 10 Mar 2005 13:41, Benjamin Herrenschmidt wrote: While we are at such requests ... When you pull from one of the trees, like netdev, the commit messages are sent to the bk commit list with the original date stamp of the patch in the netdev tree. For example, if Jeff commited a patch from somebody in his netdev tree 3 weeks ago, and you pull Jeff's tree today, we'll get all the commit messages today, but dated from 3 weeks ago. That means that in my mailing list archive, where my mailer sorts them by date, I can't say, for example, everything that is before the 2.6.11 tag release was in 2.6.11. It's also difficult to spot new stuffs as they can arrive with dates weeks ago, and thus show up in places I will not look for. I don't know if I'm the only one to have a problem with that, but it would be nice if it was possible, when you pull a bk tree, to have the commit messages for the csets in that tree be dated from the day you pulled, and not the day when they went in the source tree. Ben. pgpdo08LaFdfw.pgp Description: PGP signature
RE: Direct io on block device has performance regression on 2.6.x kernel
Andrew Morton wrote Wednesday, March 09, 2005 6:26 PM What does 1/3 of the total benchmark performance regression mean? One third of 0.1% isn't very impressive. You haven't told us anything at all about the magnitude of this regression. 2.6.9 kernel is 6% slower compare to distributor's 2.4 kernel (RHEL3). Roughly 2% came from storage driver (I'm not allowed to say anything beyond that, there is a fix though). 2% came from DIO. The rest of 2% is still unaccounted for. We don't know where. How much system time? User time? All that stuff. 20.5% in the kernel, 79.5% in user space. But the first thing to do is to work out where the cycles are going to. You've seen the profile. That's where all the cycle went. Also, I'm rather peeved that we're hearing about this regression now rather than two years ago. And mystified as to why yours is the only group which has reported it. 2.6.X kernel has never been faster than the 2.4 kernel (RHEL3). At one point of time, around 2.6.2, the gap is pretty close, at around 1%, but still slower. Around 2.6.5, we found global plug list is causing huge lock contention on 32-way numa box. That got fixed in 2.6.7. Then comes 2.6.8 which took a big dip at close to 20% regression. Then we fixed 17% regression in the scheduler (fixed with cache_decay_tick). 2.6.9 is the last one we measured and it is 6% slower. It's a constant moving target, a wild goose to chase. I don't know why other people have not reported the problem, perhaps they haven't got a chance to run transaction processing db workload on 2.6 kernel. Perhaps they have not compared, perhaps they are working on the same problem. I just don't know. - Ken - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] tpm_atmel build fix
ChangeSet 1.2038, 2005/03/09 10:13:15-08:00, [EMAIL PROTECTED]
[PATCH] tpm_atmel build fix
drivers/char/tpm/tpm_atmel.c:131: unknown field `fops' specified in initializer
drivers/char/tpm/tpm_atmel.c:131: warning: missing braces around initializer
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/char/tpm/tpm_atmel.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Nru a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
--- a/drivers/char/tpm/tpm_atmel.c 2005-03-09 16:40:05 -08:00
+++ b/drivers/char/tpm/tpm_atmel.c 2005-03-09 16:40:05 -08:00
@@ -128,7 +128,7 @@
.req_complete_mask = ATML_STATUS_BUSY | ATML_STATUS_DATA_AVAIL,
.req_complete_val = ATML_STATUS_DATA_AVAIL,
.base = TPM_ATML_BASE,
- .miscdev.fops = atmel_ops,
+ .miscdev = { .fops = atmel_ops, },
};
static int __devinit tpm_atml_init(struct pci_dev *pci_dev,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bk commits and dates
On Thu, 10 Mar 2005 13:41:59 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: I don't know if I'm the only one to have a problem with that, but it would be nice if it was possible, when you pull a bk tree, to have the commit messages for the csets in that tree be dated from the day you pulled, and not the day when they went in the source tree. When I'm working, I just do bk csets after I pull from Linus's tree to review what went in since the last time I pulled. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.11- sym53c8xx Broken on pp64
On Wed, 9 Mar 2005, Omkhar Arasaratnam wrote: I confirmed that this occurs with the 2.6.11 code straight from kernel.org Here is an error from the bringup: So if 2.6.9 works, and 2.6.11 does not, can you check 2.6.10? And perhaps hunt it down even more, to a -rc release? sym0: No NVRAM, ID 7, Fast-80 LVD, parity checking CACHE TEST FAILED: DMA error (dstat=0xa0) .sym0: CACHE INCORRECTLY CONFIGURED sym0: giving up ... There are certainly sym changes in there too since 2.6.9, let's see if James or Willy have any suggestions. It might not be ppc64-specific. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Slowdown on 3000 socket-machines tracked down
Christian Schmid wrote: Yes, 2.6.11. I have tuned max_backlog and some other TCP and networking related settings to give more buffers etc to networking tasks. I have not tried any significant disk-IO while doing these tests. I finally got my systems set up so I can run my WAN emulator at full 1Gbps: I am getting right at 986Mbps throughput with 30ms round-trip latency (15ms in both directions). So, latency does not seem to be the problem either. I think the problem can be narrowed down to: 1) Non-optimal kernel network tunings on your server. I used all the default-settings on 2.6.11 Here are my settings. Hopefully it will be clear what I'm talking about..yell if you need details. Please note that I explicitly set the send buffers to 128k and the rcv to 16k in my test so the min and max socket queue lengths do not matter here. my $dflt_tx_queue_len = 2000; # Ethernet driver transmit-queue length. Might be worth making # it bigger for GigE nics. my $netdev_max_backlog = 5000; # Maximum number of packets, queued on the INPUT side, when # the interface receives pkts faster than it can process them. my $wmem_max = 4096000; # Write memory buffer. This is probably fine for any setup, # and could be smaller (256000) for 5Mbps connections. my $wmem_default = 128000; # Write memory buffer. This is probably fine for any setup, # and could be smaller (256000) for 5Mbps connections. my $rmem_max = 8096000; # Receive memory (packet) buffer. If you are running # lots of very fast traffic, # you may want to make this larger if you are running over # fast, high-latency networks. # For 5Mbps of traffic, 512000 should be fine. my $rmem_default = 128000; # Receive memory (packet) buffer. # If this is not 1, then the tcp_* settings below will not be applied. my $modify_tcp_settings = 1; # See the kernel documentation: Documentation/networking/ip-sysctl.txt my $tcp_rmem_min = 4096; my $tcp_rmem_default = 256000; # TCP specific receive memory pool size. my $tcp_rmem_max = 3000; # TCP specific receive memory pool size. my $tcp_wmem_min = 4096; my $tcp_wmem_default = 256000; # TCP specific write memory pool size. my $tcp_wmem_max = 3000; # TCP specific write memory pool size. my $tcp_mem_lo = 2000; # Below here there is no memory pressure. my $tcp_mem_pressure = 3000; # Can use up to 30MB for TCP buffers. my $tcp_mem_high = 6000; # Can use up to 60MB for TCP buffers. 2) Disk-IO (my disk is small and slow compared to a 'real' server, not sure I can really test this side of things, and I have not tried as of yet.) This doesnt explain the speed-up when I change lower_zone_protection from 0 to 1024. It also doesnt explain the slowdown on 2.6.11 compared to 2.6.10 Disk-IO uses buffers, so a change here could easily starve the rest of your system. I'm just saying I can't reliably test this. To be honest, my machines are already throwing allocation failures in the ethernet drivers and I've had the OOM killer kill my main process several times. So, my machines are running right at their memory limit, even w/out any disk IO. 3) Your clients have much more latency and/or don't have enough bandwidth to fully load your server. Since you didn't answer before: I assume you do not have a reliable test bed and are just hoping that enough clients connect to do your benchmarking. Yes I just wait until they connect. On the graph it only takes about 2 minutes until 3000 sockets are created again. But, you could get unlucky and have 3000 people on a shitty dialup connection connect to you. That does not make it easy to reliably test the system. 4) There is something strange with sendfile and/or your application's coding. I am not doing more than calling sendfile. There is nothing one can do wrong. My suggestion would be to eliminate these variables by coming up with a repeatable test bed, alternative traffic generators, WAN/Network emulators for latency, etc. The problem still is that 1) it speeds up immediately when lower_zone_protection is raised to 1024. This proves it is NOT a disk-bottleneck. And second: it got much worse with 2.6.11 and lower_zone_protection disappeared on 2.6.11 So, maybe a VM problem? That would be a good place to focus since I think we can be fairly certain it isn't a problem in just the networking code. Otherwise, my tests would show lower bandwidth. Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Slowdown on 3000 socket-machines tracked down
So, maybe a VM problem? That would be a good place to focus since I think we can be fairly certain it isn't a problem in just the networking code. Otherwise, my tests would show lower bandwidth. Thanks to your tests I am really sure that its no network-code problem anymore. But what I THINK it is: The network is allocating buffers dynamically and if the vm doesnt provide that buffers fast enough, it locks as well. Addendum: If I throttle to 100 MBit it doesnt slow-down even with 5000 sockets. What do you think? I think its about having to free cache more quicker than possible. But then, why is CPU still at 30%? Might there be some limit per cyclus? For example if that cleaner wakes up every 10 ms and cleans max X pages, it would explain an artificial limit. Chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.10 - direct-io async short read bug
On Wed, 2005-03-09 at 14:39, Andrew Morton wrote: Badari Pulavarty [EMAIL PROTECTED] wrote: On Wed, 2005-03-09 at 11:53, Andrew Morton wrote: Suparna Bhattacharya [EMAIL PROTECTED] wrote: Solaris, which does forcedirectio as a mount option, actually will do buffered I/O on the trailing part. Consider it like a bounce buffer. That way they don't DMA the trailing data and succeed the I/O. The I/O returns actual bytes till EOF, just like read(2) is supposed to. Either this or a fully DMA'd number 4 is really what we should do. If security can only be solved via a bounce buffer, who cares? If the user created themselves a non-aligned file to open O_DIRECT, that's their problem if the last part-sector is negligably slower. If writes/truncates take care of zeroing out the rest of the sector on disk, might we still be OK without having to do the bounce buffer thing ? We can probably rely on the rest of the sector outside i_size being zeroed anyway. Because if it contains non-zero gunk then the fs already has a problem, and the user can get at that gunk with an expanding truncate and mmap() anyway. Rest of the sector or rest of the block ? The filesystem-sized block (1i_blkbits) which straddles i_size should have zeroes outside i_size. There's one situation where it might not be zeroed out, and that's when the final page is mapped MAP_SHARED and the application modifies that page outside i_size while writeout is actually in flight. We can't do much about that. Are you implying that, we already do this, so there is no problem reading beyond EOF to user buffer ? Or we need to zero out the userbuffer beyond EOF ? It should be acceptable to assume that the final (1i_blkbits) block of the file contains zeroes outside i_size. And if it doesn't contain those zeroes, well, applications are able to read that data already. Although I wouldn't count that as a security hole: that data is something which an application wrote there while writing the file, rather than being left-over uncontrolled stuff. Well, in that case - the original patch sent out is good enough to fix the problem. All the original patch did was after completing the IO, truncated the size to filesize. The problem is only with the last block in the file. If the file ends in the middle of the block, we go ahead and read till the end of the block. I was trying to address that issue. But, if the block is already zeroed, just truncating the size after the IO is complete should be good enough. Thanks, Badari - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] USB: move usb core to use class_simple instead of it's own class functions.
ChangeSet 1.2051, 2005/03/09 12:17:18-08:00, [EMAIL PROTECTED]
[PATCH] USB: move usb core to use class_simple instead of it's own class
functions.
This is needed if the class code is going to be made easier to use, and it
makes the code
smaller and easier to understand.
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/usb/core/file.c | 55
1 files changed, 19 insertions(+), 36 deletions(-)
diff -Nru a/drivers/usb/core/file.c b/drivers/usb/core/file.c
--- a/drivers/usb/core/file.c 2005-03-09 16:28:31 -08:00
+++ b/drivers/usb/core/file.c 2005-03-09 16:28:31 -08:00
@@ -66,16 +66,7 @@
.open = usb_open,
};
-static void release_usb_class_dev(struct class_device *class_dev)
-{
- dbg(%s - %s, __FUNCTION__, class_dev-class_id);
- kfree(class_dev);
-}
-
-static struct class usb_class = {
- .name = usb,
- .release= release_usb_class_dev,
-};
+static struct class_simple *usb_class;
int usb_major_init(void)
{
@@ -87,9 +78,9 @@
goto out;
}
- error = class_register(usb_class);
- if (error) {
- err(class_register failed for usb devices);
+ usb_class = class_simple_create(THIS_MODULE, usb);
+ if (IS_ERR(usb_class)) {
+ err(class_simple_create failed for usb devices);
unregister_chrdev(USB_MAJOR, usb);
goto out;
}
@@ -102,7 +93,7 @@
void usb_major_cleanup(void)
{
- class_unregister(usb_class);
+ class_simple_destroy(usb_class);
devfs_remove(usb);
unregister_chrdev(USB_MAJOR, usb);
}
@@ -134,7 +125,6 @@
int minor_base = class_driver-minor_base;
int minor = 0;
char name[BUS_ID_SIZE];
- struct class_device *class_dev;
char *temp;
#ifdef CONFIG_USB_DYNAMIC_MINORS
@@ -174,22 +164,18 @@
devfs_mk_cdev(MKDEV(USB_MAJOR, minor), class_driver-mode, name);
/* create a usb class device for this usb interface */
- class_dev = kmalloc(sizeof(*class_dev), GFP_KERNEL);
- if (class_dev) {
- memset(class_dev, 0x00, sizeof(struct class_device));
- class_dev-devt = MKDEV(USB_MAJOR, minor);
- class_dev-class = usb_class;
- class_dev-dev = intf-dev;
-
- temp = strrchr(name, '/');
- if (temp (temp[1] != 0x00))
- ++temp;
- else
- temp = name;
- snprintf(class_dev-class_id, BUS_ID_SIZE, %s, temp);
- class_set_devdata(class_dev, (void *)(long)intf-minor);
- class_device_register(class_dev);
- intf-class_dev = class_dev;
+ temp = strrchr(name, '/');
+ if (temp (temp[1] != 0x00))
+ ++temp;
+ else
+ temp = name;
+ intf-class_dev = class_simple_device_add(usb_class, MKDEV(USB_MAJOR,
minor), intf-dev, %s, temp);
+ if (IS_ERR(intf-class_dev)) {
+ spin_lock (minor_lock);
+ usb_minors[intf-minor] = NULL;
+ spin_unlock (minor_lock);
+ devfs_remove (name);
+ retval = PTR_ERR(intf-class_dev);
}
exit:
return retval;
@@ -232,11 +218,8 @@
snprintf(name, BUS_ID_SIZE, class_driver-name, intf-minor -
minor_base);
devfs_remove (name);
-
- if (intf-class_dev) {
- class_device_unregister(intf-class_dev);
- intf-class_dev = NULL;
- }
+ class_simple_device_remove(MKDEV(USB_MAJOR, intf-minor));
+ intf-class_dev = NULL;
intf-minor = -1;
}
EXPORT_SYMBOL(usb_deregister_dev);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/15] ptwalk: pagetable walker cleanup
On Wed, 2005-03-09 at 22:05 +, Hugh Dickins wrote: Here's a cleanup of the pagetable walkers, in common and i386 code, based on 2.6.11-bk5. Mainly to make them all go the same simpler way, so they're easier to follow with less room for error; but also to reduce the code size and speed it up a little. These are janitorial changes, other arches may follow whenever it suits them. .../... Do you have them on HTTP somewhere ? Apparently, a few of the 15 patches didn't make it to me. There are some other bugs introduced by set_pte_at() caused by latent bugs in the PTE walkers that 'drop' part of the address along the way, notably the vmalloc.c ones are bogus, thus breaking ppc/ppc64 in subtle ways. Before I send patches, I'd rather check if it's not all fixed by your patches first :) Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] UML - Remove build dependency on perl
To quote .config into config.c for building the result into the code, use sed
instead of perl, as requested by one embedded UML user (which notes that
perl is a big requirement, while busybox provides sed which is used in this
patch).
I've tested that there are only cosmethical differences in the produced
config.c file, which don't change at all the result (i.e. a is replaced by
a at the beginning, which is non-significant).
Reported by, and initial patch provided by, Rob Landley.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
Index: linux-2.6.11/arch/um/kernel/Makefile
===
--- linux-2.6.11.orig/arch/um/kernel/Makefile 2005-03-08 20:17:35.0
-0500
+++ linux-2.6.11/arch/um/kernel/Makefile2005-03-08 22:19:21.0
-0500
@@ -4,7 +4,7 @@
#
extra-y := vmlinux.lds
-clean-files := vmlinux.lds.S
+clean-files := vmlinux.lds.S config.tmp
obj-y = checksum.o config.o exec_kern.o exitcode.o \
helper.o init_task.o irq.o irq_user.o ksyms.o main.o mem.o mem_user.o \
@@ -34,11 +34,25 @@
$(USER_OBJS) : %.o: %.c
$(CC) $(USER_CFLAGS) $(CFLAGS_$(notdir $@)) -c -o $@ $
-QUOTE = 'my $$config=`cat $(TOPDIR)/.config`; $$config =~ s//\\/g ; $$config
=~ s/\n/\\n\n/g ; while(STDIN) { $$_ =~ s/CONFIG/$$config/; print $$_ }'
+targets += config.c
-quiet_cmd_quote = QUOTE $@
-cmd_quote = $(PERL) -e $(QUOTE) $ $@
+# Be careful with the below Sed code - sed is pitfall-rich!
+# We use sed to lower build requirements, for embedded builders for instance.
-targets += config.c
-$(obj)/config.c : $(src)/config.c.in $(TOPDIR)/.config FORCE
- $(call if_changed,quote)
+$(obj)/config.tmp: $(objtree)/.config FORCE
+ $(call if_changed,quote1)
+
+quiet_cmd_quote1 = QUOTE $@
+ cmd_quote1 = sed -e 's//\\/g' -e 's/^//' -e 's/$$/\\n/' \
+ $ $@
+
+$(obj)/config.c: $(src)/config.c.in $(obj)/config.tmp FORCE
+ $(call if_changed,quote2)
+
+quiet_cmd_quote2 = QUOTE $@
+ cmd_quote2 = sed -e '/CONFIG/{' \
+ -e 's/CONFIG\;//'\
+ -e 'r $(obj)/config.tmp' \
+ -e 'a\;' \
+ -e '}' \
+ $ $@
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 TPM hardware enablement driver
Greg KH wrote:
diff -Nru a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/char/tpm/tpm.c 2005-03-09 16:40:26 -08:00
@@ -0,0 +1,697 @@
+/*
+ * Copyright (C) 2004 IBM Corporation
+ *
+ * Authors:
+ * Leendert van Doorn [EMAIL PROTECTED]
+ * Dave Safford [EMAIL PROTECTED]
+ * Reiner Sailer [EMAIL PROTECTED]
+ * Kylene Hall [EMAIL PROTECTED]
+ *
+ * Maintained by: [EMAIL PROTECTED]
+ *
+ * Device driver for TCG/TCPA TPM (trusted platform module).
+ * Specifications at www.trustedcomputinggroup.org
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ * Note, the TPM chip is not interrupt driven (only polling)
+ * and can have very long timeouts (minutes!). Hence the unusual
+ * calls to schedule_timeout.
+ *
+ */
+
+#include linux/sched.h
+#include linux/poll.h
+#include linux/spinlock.h
+#include tpm.h
+
+#define TPM_MINOR 224 /* officially assigned */
+
+#define TPM_BUFSIZE 2048
+
+/* PCI configuration addresses */
+#define PCI_GEN_PMCON_1 0xA0
+#define PCI_GEN1_DEC 0xE4
+#define PCI_LPC_EN 0xE6
+#define PCI_GEN2_DEC 0xEC
enums preferred to #defines, as these provide more type information, and
are more visible in a debugger.
+static LIST_HEAD(tpm_chip_list);
+static spinlock_t driver_lock = SPIN_LOCK_UNLOCKED;
+static int dev_mask[32];
don't use '32', create a constant and use that constant instead.
+static void user_reader_timeout(unsigned long ptr)
+{
+ struct tpm_chip *chip = (struct tpm_chip *) ptr;
+
+ down(chip-buffer_mutex);
+ atomic_set(chip-data_pending, 0);
+ memset(chip-data_buffer, 0, TPM_BUFSIZE);
+ up(chip-buffer_mutex);
+}
+
+void tpm_time_expired(unsigned long ptr)
+{
+ int *exp = (int *) ptr;
+ *exp = 1;
+}
+
+EXPORT_SYMBOL_GPL(tpm_time_expired);
+
+/*
+ * Initialize the LPC bus and enable the TPM ports
+ */
+int tpm_lpc_bus_init(struct pci_dev *pci_dev, u16 base)
+{
+ u32 lpcenable, tmp;
+ int is_lpcm = 0;
+
+ switch (pci_dev-vendor) {
+ case PCI_VENDOR_ID_INTEL:
+ switch (pci_dev-device) {
+ case PCI_DEVICE_ID_INTEL_82801CA_12:
+ case PCI_DEVICE_ID_INTEL_82801DB_12:
+ is_lpcm = 1;
+ break;
+ }
+ /* init ICH (enable LPC) */
+ pci_read_config_dword(pci_dev, PCI_GEN1_DEC, lpcenable);
+ lpcenable |= 0x2000;
+ pci_write_config_dword(pci_dev, PCI_GEN1_DEC, lpcenable);
+
+ if (is_lpcm) {
+ pci_read_config_dword(pci_dev, PCI_GEN1_DEC,
+ lpcenable);
+ if ((lpcenable 0x2000) == 0) {
+ dev_err(pci_dev-dev,
+ cannot enable LPC\n);
+ return -ENODEV;
+ }
+ }
+
+ /* initialize TPM registers */
+ pci_read_config_dword(pci_dev, PCI_GEN2_DEC, tmp);
+
+ if (!is_lpcm)
+ tmp = (tmp 0x) | (base 0xFFF0);
+ else
+ tmp =
+ (tmp 0x) | (base 0xFFF0) |
+ 0x0001;
+
+ pci_write_config_dword(pci_dev, PCI_GEN2_DEC, tmp);
+
+ if (is_lpcm) {
+ pci_read_config_dword(pci_dev, PCI_GEN_PMCON_1,
+ tmp);
+ tmp |= 0x0004; /* enable CLKRUN */
+ pci_write_config_dword(pci_dev, PCI_GEN_PMCON_1,
+ tmp);
+ }
+ tpm_write_index(0x0D, 0x55);/* unlock 4F */
+ tpm_write_index(0x0A, 0x00);/* int disable */
+ tpm_write_index(0x08, base);/* base addr lo */
+ tpm_write_index(0x09, (base 0xFF00) 8); /* base addr hi */
+ tpm_write_index(0x0D, 0xAA);/* lock 4F */
please define symbol names for the TPM registers
+ break;
+ case PCI_VENDOR_ID_AMD:
+ /* nothing yet */
+ break;
+ }
+
+ return 0;
+}
+
+EXPORT_SYMBOL_GPL(tpm_lpc_bus_init);
+
+/*
+ * Internal kernel interface to transmit TPM commands
+ */
+static ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
+ size_t bufsiz)
+{
+ ssize_t len;
+ u32 count;
+ __be32 *native_size;
+
+ native_size = (__force __be32 *) (buf + 2);
+ count = be32_to_cpu(*native_size);
+
+ if (count == 0)
+ return -ENODATA;
+ if (count bufsiz) {
+ dev_err(chip-pci_dev-dev,
+
Re: Direct io on block device has performance regression on 2.6.x kernel
David Lang [EMAIL PROTECTED] wrote: (I've seen a 50% performance hit on 2.4 with just a thousand or two threads compared to 2.6) Was that 2.4 kernel a vendor kernel with the O(1) scheduler? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sched_setscheduler and pids/threads
Hi all, I'm a bit confused over 2.6 threading with respects to real time scheduling settings... In 2.6 all my threads appear as a single PID, if I use chrt -p pid will it set the scheduling priority for my main thread or for all threads in the application? Can I used the thread IDs from /proc/pid/task/ to chrt the other threads in my app to different priorities? Thanks, Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Direct io on block device has performance regression on 2.6.x kernel
Chen, Kenneth W [EMAIL PROTECTED] wrote: Andrew Morton wrote Wednesday, March 09, 2005 6:26 PM What does 1/3 of the total benchmark performance regression mean? One third of 0.1% isn't very impressive. You haven't told us anything at all about the magnitude of this regression. 2.6.9 kernel is 6% slower compare to distributor's 2.4 kernel (RHEL3). Roughly 2% came from storage driver (I'm not allowed to say anything beyond that, there is a fix though). The codepaths are indeed longer in 2.6. 2% came from DIO. hm, that's not a lot. Once you redo that patch to use aops and to work with O_DIRECT, the paths will get a little deeper, but not much. We really should do this so that O_DIRECT works, and in case someone has gone and mmapped the blockdev. Fine-grained alignment is probably too hard, and it should fall back to __blockdev_direct_IO(). Does it do the right thing with a request which is non-page-aligned, but 512-byte aligned? readv and writev? 2% is pretty thin :( The rest of 2% is still unaccounted for. We don't know where. General cache replacement, perhaps. 9MB is a big cache though. ... Around 2.6.5, we found global plug list is causing huge lock contention on 32-way numa box. That got fixed in 2.6.7. Then comes 2.6.8 which took a big dip at close to 20% regression. Then we fixed 17% regression in the scheduler (fixed with cache_decay_tick). 2.6.9 is the last one we measured and it is 6% slower. It's a constant moving target, a wild goose to chase. OK. Seems that the 2.4 O(1) scheduler got it right for that machine. haven't got a chance to run transaction processing db workload on 2.6 kernel. Perhaps they have not compared, perhaps they are working on the same problem. I just don't know. Maybe there are other factors which drown these little things out: architecture improvements, choice of architecture, driver changes, etc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Direct io on block device has performance regression on 2.6.x kernel
On Wed, 9 Mar 2005, Chen, Kenneth W wrote: Also, I'm rather peeved that we're hearing about this regression now rather than two years ago. And mystified as to why yours is the only group which has reported it. 2.6.X kernel has never been faster than the 2.4 kernel (RHEL3). At one point of time, around 2.6.2, the gap is pretty close, at around 1%, but still slower. Around 2.6.5, we found global plug list is causing huge lock contention on 32-way numa box. That got fixed in 2.6.7. Then comes 2.6.8 which took a big dip at close to 20% regression. Then we fixed 17% regression in the scheduler (fixed with cache_decay_tick). 2.6.9 is the last one we measured and it is 6% slower. It's a constant moving target, a wild goose to chase. I don't know why other people have not reported the problem, perhaps they haven't got a chance to run transaction processing db workload on 2.6 kernel. Perhaps they have not compared, perhaps they are working on the same problem. I just don't know. Also the 2.6 kernel is Soo much better in the case where you have many threads (even if they are all completely idle) that that improvement may be masking the regression that Ken is reporting (I've seen a 50% performance hit on 2.4 with just a thousand or two threads compared to 2.6). let's face it, a typical linux box today starts up a LOT of stuff that will never get used, but will count as an idle thread. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Direct io on block device has performance regression on 2.6.xkernel
On Wed, 9 Mar 2005, Andrew Morton wrote: David Lang [EMAIL PROTECTED] wrote: (I've seen a 50% performance hit on 2.4 with just a thousand or two threads compared to 2.6) Was that 2.4 kernel a vendor kernel with the O(1) scheduler? no, a kernel.org kernel. the 2.6 kernel is so much faster for this workload that I switched for this app and never looked back. I found that if I had 5000 or so idle tasks 2.4 performcane would drop to about a quarter of 2.6 (with the CPU system time being the limiting factor) David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 7/9] UML - Speed up tlb flushing
This patch optimizes tlb flushing in a couple of ways to reduce the number
of system calls made to the host in order to update an address space.
Operations are collected, and adjacent ones which can be merged, are. This
includes consecutive munmaps, mprotects with the same permissions, and mmaps
with the same backing file and permissions and linear in the file.
Second, the munmaps that always preceded mmaps are now done instead of mmap if
necessary.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
Index: linux-2.6.11/arch/um/include/tlb.h
===
--- linux-2.6.11.orig/arch/um/include/tlb.h 2005-03-08 20:17:35.0
-0500
+++ linux-2.6.11/arch/um/include/tlb.h 2005-03-08 22:22:23.0 -0500
@@ -6,9 +6,48 @@
#ifndef __TLB_H__
#define __TLB_H__
+#include um_mmu.h
+
+struct host_vm_op {
+ enum { MMAP, MUNMAP, MPROTECT } type;
+ union {
+ struct {
+ unsigned long addr;
+ unsigned long len;
+ unsigned int r:1;
+ unsigned int w:1;
+ unsigned int x:1;
+ int fd;
+ __u64 offset;
+ } mmap;
+ struct {
+ unsigned long addr;
+ unsigned long len;
+ } munmap;
+ struct {
+ unsigned long addr;
+ unsigned long len;
+ unsigned int r:1;
+ unsigned int w:1;
+ unsigned int x:1;
+ } mprotect;
+ } u;
+};
+
extern void mprotect_kernel_vm(int w);
extern void force_flush_all(void);
+extern int add_mmap(unsigned long virt, unsigned long phys, unsigned long len,
+ int r, int w, int x, struct host_vm_op *ops, int index,
+ int last_filled, int data,
+ void (*do_ops)(int, struct host_vm_op *, int));
+extern int add_munmap(unsigned long addr, unsigned long len,
+ struct host_vm_op *ops, int index, int last_filled,
+ int data, void (*do_ops)(int, struct host_vm_op *, int));
+extern int add_mprotect(unsigned long addr, unsigned long len, int r, int w,
+ int x, struct host_vm_op *ops, int index,
+ int last_filled, int data,
+ void (*do_ops)(int, struct host_vm_op *, int));
#endif
/*
Index: linux-2.6.11/arch/um/kernel/skas/include/skas.h
===
--- linux-2.6.11.orig/arch/um/kernel/skas/include/skas.h2005-03-08
20:17:35.0 -0500
+++ linux-2.6.11/arch/um/kernel/skas/include/skas.h 2005-03-08
22:22:23.0 -0500
@@ -22,11 +22,11 @@
extern void remove_sigstack(void);
extern void new_thread_handler(int sig);
extern void handle_syscall(union uml_pt_regs *regs);
-extern void map(int fd, unsigned long virt, unsigned long phys,
- unsigned long len, int r, int w, int x);
-extern int unmap(int fd, void *addr, int len);
+extern void map(int fd, unsigned long virt, unsigned long len, int r, int w,
+ int x, int phys_fd, unsigned long long offset);
+extern int unmap(int fd, void *addr, unsigned long len);
extern int protect(int fd, unsigned long addr, unsigned long len,
- int r, int w, int x, int must_succeed);
+ int r, int w, int x);
extern void user_signal(int sig, union uml_pt_regs *regs);
extern int new_mm(int from);
extern void start_userspace(int cpu);
Index: linux-2.6.11/arch/um/kernel/skas/mem_user.c
===
--- linux-2.6.11.orig/arch/um/kernel/skas/mem_user.c2005-03-08
21:56:38.0 -0500
+++ linux-2.6.11/arch/um/kernel/skas/mem_user.c 2005-03-08 22:22:23.0
-0500
@@ -11,16 +11,14 @@
#include os.h
#include proc_mm.h
-void map(int fd, unsigned long virt, unsigned long phys, unsigned long len,
-int r, int w, int x)
+void map(int fd, unsigned long virt, unsigned long len, int r, int w,
+int x, int phys_fd, unsigned long long offset)
{
struct proc_mm_op map;
- __u64 offset;
- int prot, n, phys_fd;
+ int prot, n;
prot = (r ? PROT_READ : 0) | (w ? PROT_WRITE : 0) |
(x ? PROT_EXEC : 0);
- phys_fd = phys_mapping(phys, offset);
map = ((struct proc_mm_op) { .op= MM_MMAP,
.u =
@@ -38,7 +36,7 @@
printk(map : /proc/mm map failed, err = %d\n, -n);
}
-int unmap(int fd, void *addr, int len)
+int unmap(int fd, void *addr, unsigned long len)
{
struct proc_mm_op unmap;
int n;
Index: linux-2.6.11/arch/um/kernel/skas/tlb.c
===
---
[PATCH 5/9] UML - change semaphores to completions
From: Esben Nielsen simlo at phys au dk
One of the problems was use of direct architecture specific semaphores
(which doesn't work under PREEMPT_REALTIME) and in places where a quick
(maybe too quick) look at the code told me that completions ought to be
used. Therefore I changed two semaphores to completions which compiled
fine. I have tried the change on 2.6.11-rc2, and it seemed to work, but I
have not tested it heavily.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
Index: linux-2.6.11/arch/um/drivers/port_kern.c
===
--- linux-2.6.11.orig/arch/um/drivers/port_kern.c 2005-03-08
20:17:34.0 -0500
+++ linux-2.6.11/arch/um/drivers/port_kern.c2005-03-08 22:16:48.0
-0500
@@ -25,7 +25,7 @@
struct list_head list;
atomic_t wait_count;
int has_connection;
- struct semaphore sem;
+ struct completion done;
int port;
int fd;
spinlock_t lock;
@@ -68,7 +68,7 @@
conn-fd = fd;
list_add(conn-list, conn-port-connections);
- up(conn-port-sem);
+ complete(conn-port-done);
return(IRQ_HANDLED);
}
@@ -197,13 +197,14 @@
{ .list = LIST_HEAD_INIT(port-list),
.wait_count = ATOMIC_INIT(0),
.has_connection = 0,
- .sem = __SEMAPHORE_INITIALIZER(port-sem,
- 0),
.lock = SPIN_LOCK_UNLOCKED,
.port = port_num,
.fd = fd,
.pending = LIST_HEAD_INIT(port-pending),
.connections = LIST_HEAD_INIT(port-connections) });
+
+ init_completion(port-done),
+
list_add(port-list, ports);
found:
@@ -237,7 +238,7 @@
atomic_inc(port-wait_count);
while(1){
fd = -ERESTARTSYS;
- if(down_interruptible(port-sem))
+if(wait_for_completion_interruptible(port-done))
goto out;
spin_lock(port-lock);
@@ -308,14 +309,3 @@
}
__uml_exitcall(free_port);
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only. This must remain at the end
- * of the file.
- * ---
- * Local variables:
- * c-file-style: linux
- * End:
- */
Index: linux-2.6.11/arch/um/drivers/xterm_kern.c
===
--- linux-2.6.11.orig/arch/um/drivers/xterm_kern.c 2005-03-08
20:17:34.0 -0500
+++ linux-2.6.11/arch/um/drivers/xterm_kern.c 2005-03-08 22:16:48.0
-0500
@@ -16,7 +16,7 @@
#include xterm.h
struct xterm_wait {
- struct semaphore sem;
+ struct completion ready;
int fd;
int pid;
int new_fd;
@@ -32,7 +32,7 @@
return(IRQ_NONE);
xterm-new_fd = fd;
- up(xterm-sem);
+ complete(xterm-ready);
return(IRQ_HANDLED);
}
@@ -49,10 +49,10 @@
/* This is a locked semaphore... */
*data = ((struct xterm_wait)
- { .sem = __SEMAPHORE_INITIALIZER(data-sem, 0),
- .fd = socket,
+ { .fd = socket,
.pid = -1,
.new_fd = -1 });
+ init_completion(data-ready);
err = um_request_irq(XTERM_IRQ, socket, IRQ_READ, xterm_interrupt,
SA_INTERRUPT | SA_SHIRQ | SA_SAMPLE_RANDOM,
@@ -68,7 +68,7 @@
*
* XXX Note, if the xterm doesn't work for some reason (eg. DISPLAY
* isn't set) this will hang... */
- down(data-sem);
+ wait_for_completion(data-ready);
free_irq_by_irq_and_dev(XTERM_IRQ, data);
free_irq(XTERM_IRQ, data);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
3/3 swsusp: enable resume from initrd
Hi!
From: [EMAIL PROTECTED]
When using a fully modularized kernel it is necessary to activate
resume manually as the device node might not be available during
kernel init.
This patch implements a new sysfs attribute '/sys/power/resume' which
allows for manual activation of software resume. When read from it
prints the configured resume device in 'major:minor' format. When
written to it expects a device in 'major:minor' format. This device
is then checked for a suspended image and resume is started if a valid
image is found. The original functionality is left in place.
It should be used from initramfs, or with care.
Please apply,
Pavel
Signed-off-by: Hannes Reinecke [EMAIL PROTECTED]
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
--- linux.middle/include/linux/suspend.h2005-02-14 14:14:21.0
+0100
+++ linux/include/linux/suspend.h 2005-03-03 13:23:17.0 +0100
@@ -35,6 +35,8 @@
#define SUSPEND_PD_PAGES(x) (((x)*sizeof(struct pbe))/PAGE_SIZE+1)
+
+extern dev_t swsusp_resume_device;
/* mm/vmscan.c */
extern int shrink_mem(void);
--- linux.middle/init/do_mounts.c 2005-02-03 22:28:15.0 +0100
+++ linux/init/do_mounts.c 2005-03-03 13:23:17.0 +0100
@@ -53,7 +53,7 @@
__setup(ro, readonly);
__setup(rw, readwrite);
-static dev_t __init try_name(char *name, int part)
+static dev_t try_name(char *name, int part)
{
char path[64];
char buf[32];
@@ -135,7 +135,7 @@
* is mounted on rootfs /sys.
*/
-dev_t __init name_to_dev_t(char *name)
+dev_t name_to_dev_t(char *name)
{
char s[32];
char *p;
--- linux.middle/kernel/power/disk.c2005-03-02 00:22:49.0 +0100
+++ linux/kernel/power/disk.c 2005-03-04 10:15:46.0 +0100
@@ -16,7 +18,6 @@
#include linux/device.h
#include linux/delay.h
#include linux/fs.h
-#include linux/device.h
#include power.h
@@ -25,13 +26,16 @@
extern int swsusp_suspend(void);
extern int swsusp_write(void);
+extern int swsusp_check(void);
extern int swsusp_read(void);
+extern void swsusp_close(void);
extern int swsusp_resume(void);
extern int swsusp_free(void);
static int noresume = 0;
char resume_file[256] = CONFIG_PM_STD_PARTITION;
+dev_t swsusp_resume_device;
/**
* power_down - Shut machine down for hibernate.
@@ -123,45 +127,54 @@
}
-static int prepare(void)
+static int prepare_processes(void)
{
int error;
pm_prepare_console();
sys_sync();
+
if (freeze_processes()) {
error = -EBUSY;
- goto Thaw;
+ return error;
}
if (pm_disk_mode == PM_DISK_PLATFORM) {
if (pm_ops pm_ops-prepare) {
if ((error = pm_ops-prepare(PM_SUSPEND_DISK)))
- goto Thaw;
+ return error;
}
}
/* Free memory before shutting down devices. */
free_some_memory();
+ return 0;
+}
+
+static void unprepare_processes(void)
+{
+ enable_nonboot_cpus();
+ thaw_processes();
+ pm_restore_console();
+}
+
+static int prepare_devices(void)
+{
+ int error;
+
disable_nonboot_cpus();
if ((error = device_suspend(PMSG_FREEZE))) {
printk(Some devices failed to suspend\n);
- goto Finish;
+ platform_finish();
+ enable_nonboot_cpus();
+ return error;
}
return 0;
- Finish:
- platform_finish();
- Thaw:
- enable_nonboot_cpus();
- thaw_processes();
- pm_restore_console();
- return error;
}
-
/**
* pm_suspend_disk - The granpappy of power management.
*
@@ -175,8 +188,15 @@
{
int error;
- if ((error = prepare()))
+ error = prepare_processes();
+ if (!error) {
+ error = prepare_devices();
+ }
+
+ if (error) {
+ unprepare_processes();
return error;
+ }
pr_debug(PM: Attempting to suspend to disk.\n);
if (pm_disk_mode == PM_DISK_FIRMWARE)
@@ -225,14 +245,26 @@
return 0;
}
+ pr_debug(PM: Checking swsusp image.\n);
+
+ if ((error = swsusp_check()))
+ goto Done;
+
+ pr_debug(PM: Preparing processes for restore.\n);
+
+ if ((error = prepare_processes())) {
+ swsusp_close();
+ goto Cleanup;
+ }
+
pr_debug(PM: Reading swsusp image.\n);
if ((error = swsusp_read()))
- goto Done;
+ goto Cleanup;
- pr_debug(PM: Preparing system for restore.\n);
+ pr_debug(PM: Preparing devices for restore.\n);
- if ((error = prepare()))
+ if ((error = prepare_devices()))
goto Free;
barrier();
@@ -244,6 +276,8 @@
finish();
Free:
RE: [ANNOUNCE][PATCH 2.6.11 2/3] megaraid_sas: Announcing new mod ule for LSI Logic's SAS based MegaRAID controllers
Even for kernels with a 64bit dma_addr_t you can get 32bit dma addresses only. As a start check whether the pci_set_dma_mask for the 64bit mask failed - in that case you can always use 32bit SGLs. Please help me understand: If dma_addr_t is 64 bit, I will get 64bit addresses in scatterlist regardless the outcome of pci_set_dma_mask, won't I? These addresses may have valid or null high addresses. My idea was to have 32(64) bit SGLs for 32(64) bit dma_addr_t. Thanks, Sreenivas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.2
On Wed, Mar 09, 2005 at 01:06:31PM -0800, Matt Mackall wrote: On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote: And to further test this whole -stable system, I've released 2.6.11.2. It contains one patch, which is already in the -bk tree, and came from the security team (hence the lack of the longer review cycle). It's available now in the normal kernel.org places: kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz which is a patch against the 2.6.11.1 release. Argh! @*#$!!! If consensus arrives that this patch should be against the 2.6.11 tree, it will be done that way in the future. Consensus arrived back when 2.6.8.1 came out. It did? So, what was it agreed to be? Any pointers to that agreement? Please, folks, there are automated tools that know about kernel release numbering and so on. Said tools broke with 2.6.11.1 because it wasn't in the same place that 2.6.8.1 was and now this breaks with all precedent by being an interdiff along a branch. 2.6.11.1 is now in the proper place, sorry for any inconvience that caused. This happened yesterday. Fixing it in the future is too #*$%* late because you've now turned it into a special case. No, I can always respin the patch, and re-release it if it's a problem. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Direct io on block device has performance regression on 2.6.x kernel
On Wednesday, March 9, 2005 3:23 pm, Andi Kleen wrote: Chen, Kenneth W [EMAIL PROTECTED] writes: Just to clarify here, these data need to be taken at grain of salt. A high count in _spin_unlock_* functions do not automatically points to lock contention. It's one of the blind spot syndrome with timer based profile on ia64. There are some lock contentions in 2.6 kernel that we are staring at. Please do not misinterpret the number here. Why don't you use oprofileÂ? It uses NMIs and can profile inside interrupt disabled sections. Oh, and there are other ways of doing interrupt off profiling by using the PMU. q-tools can do this I think. Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched_setscheduler and pids/threads
On Thu, 2005-03-10 at 15:12 +1100, Dave Airlie wrote: In 2.6 all my threads appear as a single PID,if I use chrt -p pid will it set the scheduling priority for my main thread or for all threads in the application? For just the main thread (or the thread of whatever PID you give). You need to set the PID of each thread individually. The everything appears as a single PID is just an elaborate parlor trick. Wool pulled over your eyes. Can I used the thread IDs from /proc/pid/task/ to chrt the other threads in my app to different priorities? You can use the PID's in /proc/pid/task/, yes. Or you can just set the PID of the main thread before it starts other threads, or use chrt to launch the program, or use chrt to set the PID of a shell script that starts the application: Scheduler properties are inherited. Best, Robert Love - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Direct io on block device has performance regression on 2.6.x kernel
On Wed, 09 Mar 2005, Chen, Kenneth W wrote: Andrew Morton wrote Wednesday, March 09, 2005 6:26 PM What does 1/3 of the total benchmark performance regression mean? One third of 0.1% isn't very impressive. You haven't told us anything at all about the magnitude of this regression. 2.6.9 kernel is 6% slower compare to distributor's 2.4 kernel (RHEL3). Roughly 2% came from storage driver (I'm not allowed to say anything beyond that, there is a fix though). Ok now, that statement piqued my interest -- since looking through a previous email it seems you are using the qla2xxx driver. Care to elaborate? Regards, Andrew Vasquez - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Slowdown on 3000 socket-machines tracked down
Christian Schmid wrote: H can you try to following just to exclude some theories: Run it with 4000 sockets and then do the following on the server-machine: dd if=/dev/zero of=file1 bs=1M count=1024 dd if=/dev/zero of=file2 bs=1M count=1024 dd if=/dev/zero of=file3 bs=1M count=1024 cat file1 /dev/zero cat file2 /dev/zero cat file3 /dev/zero I THINK it might have something to do with caching-pressure or so. See if there is a slow-down on the sending if the page-cache gets full and has to be cleared again. You are running 2.6.11? Yes, 2.6.11. I have tuned max_backlog and some other TCP and networking related settings to give more buffers etc to networking tasks. I have not tried any significant disk-IO while doing these tests. I finally got my systems set up so I can run my WAN emulator at full 1Gbps: I am getting right at 986Mbps throughput with 30ms round-trip latency (15ms in both directions). So, latency does not seem to be the problem either. I think the problem can be narrowed down to: 1) Non-optimal kernel network tunings on your server. 2) Disk-IO (my disk is small and slow compared to a 'real' server, not sure I can really test this side of things, and I have not tried as of yet.) 3) Your clients have much more latency and/or don't have enough bandwidth to fully load your server. Since you didn't answer before: I assume you do not have a reliable test bed and are just hoping that enough clients connect to do your benchmarking. 4) There is something strange with sendfile and/or your application's coding. My suggestion would be to eliminate these variables by coming up with a repeatable test bed, alternative traffic generators, WAN/Network emulators for latency, etc. Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Direct io on block device has performance regression on 2.6.x kernel
On Wednesday, March 9, 2005 3:23 pm, Andi Kleen wrote:
Chen, Kenneth W [EMAIL PROTECTED] writes:
Just to clarify here, these data need to be taken at grain of salt. A
high count in _spin_unlock_* functions do not automatically points to
lock contention. It's one of the blind spot syndrome with timer based
profile on ia64. There are some lock contentions in 2.6 kernel that
we are staring at. Please do not misinterpret the number here.
Why don't you use oprofileÂ? It uses NMIs and can profile inside
interrupt disabled sections.
That was oprofile output, but on ia64, 'NMI's are maskable due to the way irq
disabling works. Here's a very hackish patch that changes the kernel to use
cr.tpr instead of psr.i for interrupt control. Making oprofile use real ia64
NMIs is left as an exercise for the reader :)
Jesse
= arch/ia64/Kconfig.debug 1.2 vs edited =
--- 1.2/arch/ia64/Kconfig.debug 2005-01-07 16:15:52 -08:00
+++ edited/arch/ia64/Kconfig.debug 2005-02-28 10:07:27 -08:00
@@ -56,6 +56,15 @@
and restore instructions. It's useful for tracking down spinlock
problems, but slow! If you're unsure, select N.
+config IA64_ALLOW_NMI
+ bool Allow non-maskable interrupts
+ help
+ The normal ia64 irq enable/disable code prevents even non-maskable
+ interrupts from occuring, which can be a problem for kernel
+ debuggers, watchdogs, and profilers. Say Y here if you're interested
+ in NMIs and don't mind the small performance penalty this option
+ imposes.
+
config SYSVIPC_COMPAT
bool
depends on COMPAT SYSVIPC
= arch/ia64/kernel/head.S 1.31 vs edited =
--- 1.31/arch/ia64/kernel/head.S2005-01-28 15:50:13 -08:00
+++ edited/arch/ia64/kernel/head.S 2005-03-01 13:17:51 -08:00
@@ -59,6 +59,14 @@
.save rp, r0// terminate unwind chain with a NULL rp
.body
+#ifdef CONFIG_IA64_ALLOW_NMI // disable interrupts initially (re-enabled in
start_kernel())
+ mov r16=116
+ ;;
+ mov cr.tpr=r16
+ ;;
+ srlz.d
+ ;;
+#endif
rsm psr.i | psr.ic
;;
srlz.i
@@ -129,8 +137,8 @@
/*
* Switch into virtual mode:
*/
- movl
r16=(IA64_PSR_IT|IA64_PSR_IC|IA64_PSR_DT|IA64_PSR_RT|IA64_PSR_DFH|IA64_PSR_BN \
- |IA64_PSR_DI)
+ movl
r16=(IA64_PSR_IT|IA64_PSR_IC|IA64_PSR_I|IA64_PSR_DT|IA64_PSR_RT|IA64_PSR_DFH|\
+ IA64_PSR_BN|IA64_PSR_DI)
;;
mov cr.ipsr=r16
movl r17=1f
= arch/ia64/kernel/irq_ia64.c 1.25 vs edited =
--- 1.25/arch/ia64/kernel/irq_ia64.c2005-01-22 15:54:49 -08:00
+++ edited/arch/ia64/kernel/irq_ia64.c 2005-03-01 12:50:18 -08:00
@@ -103,8 +103,6 @@
void
ia64_handle_irq (ia64_vector vector, struct pt_regs *regs)
{
- unsigned long saved_tpr;
-
#if IRQ_DEBUG
{
unsigned long bsp, sp;
@@ -135,17 +133,9 @@
}
#endif /* IRQ_DEBUG */
- /*
-* Always set TPR to limit maximum interrupt nesting depth to
-* 16 (without this, it would be ~240, which could easily lead
-* to kernel stack overflows).
-*/
irq_enter();
- saved_tpr = ia64_getreg(_IA64_REG_CR_TPR);
- ia64_srlz_d();
while (vector != IA64_SPURIOUS_INT_VECTOR) {
if (!IS_RESCHEDULE(vector)) {
- ia64_setreg(_IA64_REG_CR_TPR, vector);
ia64_srlz_d();
__do_IRQ(local_vector_to_irq(vector), regs);
@@ -154,7 +144,6 @@
* Disable interrupts and send EOI:
*/
local_irq_disable();
- ia64_setreg(_IA64_REG_CR_TPR, saved_tpr);
}
ia64_eoi();
vector = ia64_get_ivr();
@@ -165,6 +154,7 @@
* come through until ia64_eoi() has been done.
*/
irq_exit();
+ local_irq_enable();
}
#ifdef CONFIG_HOTPLUG_CPU
= include/asm-ia64/hw_irq.h 1.15 vs edited =
--- 1.15/include/asm-ia64/hw_irq.h 2005-01-22 15:54:52 -08:00
+++ edited/include/asm-ia64/hw_irq.h2005-03-01 13:01:03 -08:00
@@ -36,6 +36,10 @@
#define AUTO_ASSIGN-1
+#define IA64_NMI_VECTOR0x02/* NMI (note that this
can be
+ masked if psr.i or psr.ic
+ are cleared) */
+
#define IA64_SPURIOUS_INT_VECTOR 0x0f
/*
= include/asm-ia64/system.h 1.48 vs edited =
--- 1.48/include/asm-ia64/system.h 2005-01-04 18:48:18 -08:00
+++ edited/include/asm-ia64/system.h2005-03-01 15:28:23 -08:00
@@ -107,12 +107,61 @@
#define safe_halt() ia64_pal_halt_light()/* PAL_HALT_LIGHT */
+/* For spinlocks etc */
+#ifdef CONFIG_IA64_ALLOW_NMI
+
+#define IA64_TPR_MMI_BIT (116)
+
+#define
[PATCH 3/9] UML - Hardware random number generator
This implements a hardware random number generator for UML which attaches
itself to the host's /dev/random.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
Index: linux-2.6.11/arch/um/Kconfig_char
===
--- linux-2.6.11.orig/arch/um/Kconfig_char 2005-03-08 20:13:55.0
-0500
+++ linux-2.6.11/arch/um/Kconfig_char 2005-03-08 20:22:24.0 -0500
@@ -190,5 +190,19 @@
tristate
default UML_SOUND
+config UML_RANDOM
+ tristate Hardware random number generator
+ help
+ This option enables UML's hardware random number generator. It
+ attaches itself to the host's /dev/random, supplying as much entropy
+ as the host has, rather than the small amount the UML gets from its
+ own drivers. It registers itself as a standard hardware random number
+ generator, major 10, minor 183, and the canonical device name is
+ /dev/hwrng.
+ The way to make use of this is to install the rng-tools package
+ (check your distro, or download from
+ http://sourceforge.net/projects/gkernel/). rngd periodically reads
+ /dev/hwrng and injects the entropy into /dev/random.
+
endmenu
Index: linux-2.6.11/arch/um/defconfig
===
--- linux-2.6.11.orig/arch/um/defconfig 2005-03-08 20:13:55.0 -0500
+++ linux-2.6.11/arch/um/defconfig 2005-03-08 20:22:24.0 -0500
@@ -111,6 +111,7 @@
CONFIG_UML_SOUND=m
CONFIG_SOUND=m
CONFIG_HOSTAUDIO=m
+CONFIG_UML_RANDOM=y
#
# Block devices
Index: linux-2.6.11/arch/um/drivers/Makefile
===
--- linux-2.6.11.orig/arch/um/drivers/Makefile 2005-03-08 20:17:34.0
-0500
+++ linux-2.6.11/arch/um/drivers/Makefile 2005-03-08 20:22:24.0
-0500
@@ -3,7 +3,7 @@
# Licensed under the GPL
#
-CHAN_OBJS := chan_kern.o chan_user.o line.o
+CHAN_OBJS := chan_kern.o chan_user.o line.o
# pcap is broken in 2.5 because kbuild doesn't allow pcap.a to be linked
# in to pcap.o
@@ -41,7 +41,7 @@
obj-$(CONFIG_XTERM_CHAN) += xterm.o xterm_kern.o
obj-$(CONFIG_UML_WATCHDOG) += harddog.o
obj-$(CONFIG_BLK_DEV_COW_COMMON) += cow_user.o
-
+obj-$(CONFIG_UML_RANDOM) += random.o
USER_SINGLE_OBJS = $(foreach f,$(patsubst %.o,%,$(obj-y)
$(obj-m)),$($(f)-objs))
Index: linux-2.6.11/arch/um/drivers/random.c
===
--- linux-2.6.11.orig/arch/um/drivers/random.c 2003-09-15 09:40:47.0
-0400
+++ linux-2.6.11/arch/um/drivers/random.c 2005-03-08 20:22:24.0
-0500
@@ -0,0 +1,122 @@
+/* Much of this ripped from hw_random.c */
+
+#include linux/module.h
+#include linux/fs.h
+#include linux/miscdevice.h
+#include linux/delay.h
+#include asm/uaccess.h
+#include os.h
+
+/*
+ * core module and version information
+ */
+#define RNG_VERSION 1.0.0
+#define RNG_MODULE_NAME random
+#define RNG_DRIVER_NAME RNG_MODULE_NAME virtual driver RNG_VERSION
+#define PFX RNG_MODULE_NAME :
+
+#define RNG_MISCDEV_MINOR 183 /* official */
+
+static int random_fd = -1;
+
+static int rng_dev_open (struct inode *inode, struct file *filp)
+{
+ /* enforce read-only access to this chrdev */
+ if ((filp-f_mode FMODE_READ) == 0)
+ return -EINVAL;
+ if (filp-f_mode FMODE_WRITE)
+ return -EINVAL;
+
+ return 0;
+}
+
+static ssize_t rng_dev_read (struct file *filp, char __user *buf, size_t size,
+ loff_t * offp)
+{
+u32 data;
+int n, ret = 0, have_data;
+
+while(size){
+n = os_read_file(random_fd, data, sizeof(data));
+if(n 0){
+have_data = n;
+while (have_data size) {
+if (put_user((u8)data, buf++)) {
+ret = ret ? : -EFAULT;
+break;
+}
+size--;
+ret++;
+have_data--;
+data=8;
+}
+}
+else if(n == -EAGAIN){
+if (filp-f_flags O_NONBLOCK)
+return ret ? : -EAGAIN;
+
+if(need_resched()){
+current-state = TASK_INTERRUPTIBLE;
+schedule_timeout(1);
+}
+}
+else return n;
+ if (signal_pending (current))
+ return ret ? : -ERESTARTSYS;
+ }
+ return ret;
+}
+
+static struct file_operations rng_chrdev_ops = {
+ .owner = THIS_MODULE,
+ .open = rng_dev_open,
+ .read
Re: [2.6 patch] drivers/net/sunhme.c: make a struct static
On Sat, 19 Feb 2005 09:36:18 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: This patch makes a needlessly global struct static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Applied, thanks Adrian. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] unified spinlock initialization arch/um/drivers/port_kern.c
On Wed, Mar 09, 2005 at 08:52:24PM +0100, Blaisorblade wrote: On Wednesday 09 March 2005 18:12, Russell King wrote: On Wed, Mar 09, 2005 at 10:42:33AM +0100, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Cc: user-mode-linux-devel@lists.sourceforge.net, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Unify the spinlock initialization as far as possible. Are you sure this is really the best option in this instance? Sometimes, static data initialisation is more efficient than code-based manual initialisation, especially when the memory is written to anyway. Agreed, theoretically, but this was done for multiple reasons globally, for instance as a preparation to Ingo Molnar's preemption patches. There was mention of this on lwn.net about this: http://lwn.net/Articles/108719/ Was this announced on linux-kernel as well? I don't remember seeing it. I'm not convinced about the practicality of converting all static initialisations to code-based initialisations though - I can see that the number of initialisation functions scattered throughout the kernel is going to increase dramatically to achieve this. With a 2.4 to 2.6 kernel bloat already on the order of 140% for similar functionality, I can only see the kernel getting more and more bloated _for the same feature level_ because we're trying to add more features to the kernel. I'm not entirely convinced that is an all round sane approach. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Direct io on block device has performance regression on 2.6.x kernel
Chen, Kenneth W [EMAIL PROTECTED] wrote: Did you generate a kernel profile? Top 40 kernel hot functions, percentage is normalized to kernel utilization. _spin_unlock_irqrestore 23.54% _spin_unlock_irq 19.27% Cripes. Is that with CONFIG_PREEMPT? If so, and if you disable CONFIG_PREEMPT, this cost should be accounting the the spin_unlock() caller and we can see who the culprit is. Perhaps dio-bio_lock. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.10 - direct-io async short read bug
Badari Pulavarty [EMAIL PROTECTED] wrote: On Wed, 2005-03-09 at 11:53, Andrew Morton wrote: Suparna Bhattacharya [EMAIL PROTECTED] wrote: Solaris, which does forcedirectio as a mount option, actually will do buffered I/O on the trailing part. Consider it like a bounce buffer. That way they don't DMA the trailing data and succeed the I/O. The I/O returns actual bytes till EOF, just like read(2) is supposed to. Either this or a fully DMA'd number 4 is really what we should do. If security can only be solved via a bounce buffer, who cares? If the user created themselves a non-aligned file to open O_DIRECT, that's their problem if the last part-sector is negligably slower. If writes/truncates take care of zeroing out the rest of the sector on disk, might we still be OK without having to do the bounce buffer thing ? We can probably rely on the rest of the sector outside i_size being zeroed anyway. Because if it contains non-zero gunk then the fs already has a problem, and the user can get at that gunk with an expanding truncate and mmap() anyway. Rest of the sector or rest of the block ? The filesystem-sized block (1i_blkbits) which straddles i_size should have zeroes outside i_size. There's one situation where it might not be zeroed out, and that's when the final page is mapped MAP_SHARED and the application modifies that page outside i_size while writeout is actually in flight. We can't do much about that. Are you implying that, we already do this, so there is no problem reading beyond EOF to user buffer ? Or we need to zero out the userbuffer beyond EOF ? It should be acceptable to assume that the final (1i_blkbits) block of the file contains zeroes outside i_size. And if it doesn't contain those zeroes, well, applications are able to read that data already. Although I wouldn't count that as a security hole: that data is something which an application wrote there while writing the file, rather than being left-over uncontrolled stuff. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] resync ATI PCI idents into base kernel
On Mer, 2005-03-09 at 22:00, Christoph Hellwig wrote: Which is? That's you're so special you don't need to care about the workflow the ordinary humans have created? I don't see the connection between your comment and the thread sorry. If I send it all to Andrew what will happen. Andrew can either break it into zillions of pieces and everyone will say But why do we need this or apply it. You might want to ask why so many new drivers don't bother using pci_ids.h, I'd venture to say its a defensive mechanism against broken process. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-ac1
On Mer, 2005-03-09 at 22:22, CaT wrote: Argh! Ok. I guess I shouldn't've just bought the card based on this driver then so that I could better debug my problems with my promise cards. 8( Its good hardware. It does lots of neat things providing you run -ac anyway. The raid1 performance is very good and it can do hotplug IDE transparently in hardware raid modes. Its a good solid little controller. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sata_sil Seagate HD solution
Hi all, I recently bought a computer with a Silicon Image 3512 SATA chipset and a 200GB Seagate ST320082 hard drive without knowledge that these two pieces of hardware don't play nicely. However, I called Seagate tech support and they told me that upgrading my bios would fix the problem. Fortunately my motherboard's manufacturer posted an upgrade 2-3 days after I learned of the fix. I upgraded my motherboard's bios which updated the Silicon Image RAID bios to 4.3.53. That seems to have solved the incompatibility problem. I've had yet to have a crash during intense drive usage while running with the MOD15 bug blacklist off. Those poor souls that have a hard disk in the sata_sil blacklist, if you're willing to risk it, try upgrading your bios, comment out your hard drive from the black list and see if you're able to run at full speed without the drive hanging. John Yau - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] Re: Query: Kdump: Core Image ELF Format
On Wed, 2005-03-09 at 07:17 -0700, Eric W. Biederman wrote: Vivek Goyal [EMAIL PROTECTED] writes: On Tue, 2005-03-08 at 11:00 -0700, Eric W. Biederman wrote: That sounds good. But we loose the advantage of doing limited debugging with gdb. Crash (or other analysis tools) will still take considerable amount of time before before they are fully ready and tested. How about giving user the flexibility to choose. What I mean is introducing a command line option in kexec-tools to choose between ELF32 and ELF64 headers. For the users who are not using PAE systems, they can very well go with ELF32 headers and do the debugging using gdb. This also requires, setting the kernel virtual addresses while preparing the headers. KVA for linearly mapped region is known in advance and can be filled at header creation time and gdb can directly operate upon this region. I have no problems decorating the ELF header you are generating in user space with virtual addresses assuming we can reliably get that information. And before a kernel crashes looks like a reasonable time to ask that question. I don't currently see where you could derive that information. I want to fill the virtual addresses of linearly mapped region. That is physical addresses from 0 to MAXMEM (896 MB) are mapped by kernel at virtual addresses PAGE_OFFSET to (PAGE_OFFSET + MAXMEM). Values of PAGE_OFFSET and MAXMEM are already known and hard-coded. I think I used the terminology kernel virtual address and that is adding to the confusion. Kernel virtual addresses are not necessarily linearly mapped. What I meant was kernel logical addresses whose associated physical addresses differ only by a constant offset. Beyond that I prefer a little command line tool that will do the ELF64 to ELF32 conversion and possibly add in the kva mapping to make the core dump usable with gdb. Doing it in a separate tool means it is the developer who is doing the analysis who cares not the user who is capturing the system core dump. But I do agree that it a use case worth solving. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch] resume PIT
[PATCH] resume PIT for x86_64
Signed-off-by: Luming Yu [EMAIL PROTECTED]
diff -BruN 0/arch/x86_64/kernel/i8259.c 1/arch/x86_64/kernel/i8259.c
--- 0/arch/x86_64/kernel/i8259.c2005-03-07 23:29:42.0 +0800
+++ 1/arch/x86_64/kernel/i8259.c2005-03-09 12:53:10.0 +0800
@@ -477,6 +477,7 @@
void call_function_interrupt(void);
void invalidate_interrupt(void);
void thermal_interrupt(void);
+void i8254_timer_resume(void);
static void setup_timer(void)
{
@@ -493,6 +494,11 @@
return 0;
}
+void i8254_timer_resume(void)
+{
+ setup_timer();
+}
+
static struct sysdev_class timer_sysclass = {
set_kset_name(timer),
.resume = timer_resume,
diff -BruN 0/arch/x86_64/kernel/time.c 1/arch/x86_64/kernel/time.c
--- 0/arch/x86_64/kernel/time.c 2005-03-07 23:32:23.0 +0800
+++ 1/arch/x86_64/kernel/time.c 2005-03-09 12:53:10.0 +0800
@@ -46,7 +46,7 @@
#ifdef CONFIG_CPU_FREQ
static void cpufreq_delayed_get(void);
#endif
-
+extern void i8254_timer_resume(void);
extern int using_apic_timer;
DEFINE_SPINLOCK(rtc_lock);
@@ -980,6 +980,8 @@
if (vxtime.hpet_address)
hpet_reenable();
+ else
+ i8254_timer_resume();
sec = ctime + clock_cmos_diff;
write_seqlock_irqsave(xtime_lock,flags);
i8254.patch
Description: Binary data
Re: [PATCH] Add 2.4.x cpufreq /proc and sysctl interface removal feature-removal-schedule
On Wed, Mar 09, 2005 at 04:34:38PM -0800, Greg KH wrote: ChangeSet 1.2036, 2005/03/09 09:31:40-08:00, [EMAIL PROTECTED] [PATCH] Add 2.4.x cpufreq /proc and sysctl interface removal feature-removal-schedule Add 2.4.x cpufreq /proc and sysctl interface removal to the feature-removal-schedule. [PATCH] cpufreq 2.4 interface removal schedule Even though these 2.4. interfaces are already gone in Dave Jones' cpufreq bitkeeper tree, here's a patch which properly announces it in Documentation/feature-removal-schedule.txt: Both already _were_ in Linus' tree; the entry got removed along with the cpufreq 2.4. interface. So please do not re-add this entry. Dominik - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.11- sym53c8xx Broken on pp64
Linus Torvalds wrote: There are certainly sym changes in there too since 2.6.9, let's see if James or Willy have any suggestions. It might not be ppc64-specific. Linus I have tried with 2.6.10, this appears to fail as well. Unfortunately I don't have console access right now so I will have confirm the message in the am. I'll start bisecting patches once we confirm. Omkhar - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
1/3 swsusp: use non-contiguous memory on resume
Hi! The following patch is designed to fix a problem in the current implementation of swsusp in mainline kernels. Namely, swsusp uses an array of page backup entries (aka pagedir) to store pointers to memory pages that must be saved during suspend and restored during resume. Unfortunately, the pagedir has to be located in a contiguous chunk of memory and it sometimes turns out that an 8-order or even 9-order allocation is needed for this purpose. It sometimes is impossible to get such an allocation and swsusp may fail during either suspend or resume due to the lack of memory, although theoretically there is enough free memory for it to succeed. Moreover, swsusp is more likely to fail for this reason during resume, which means that it may fail during resume after a successful suspend (this actually has happened for some people, including me :-)) and this, potentially, may lead to the loss of data. The problem is fixed by replacing the pagedir with a linklist so that high-order memory allocations are avoided (the patches make swsusp use only 0-order allocations). Unfortunately this means that it's necessary to change assembly routines used to restore the image after it's been loaded from swap so that they walk the list instead of walking the array. This patch makes swsusp allocate only individual pages during resume. it contains the necessary changes to the assembly routines etc. for i386 and x86-64. Please apply, Pavel Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Signed-off-by: Pavel Machek [EMAIL PROTECTED] diff -Nru linux-2.6.11-a/arch/i386/kernel/asm-offsets.c linux-2.6.11-b/arch/i386/kernel/asm-offsets.c --- linux-2.6.11-a/arch/i386/kernel/asm-offsets.c 2005-03-02 08:38:00.0 +0100 +++ linux-2.6.11-b/arch/i386/kernel/asm-offsets.c 2005-03-04 20:14:01.0 +0100 @@ -7,6 +7,7 @@ #include linux/sched.h #include linux/signal.h #include linux/personality.h +#include linux/suspend.h #include asm/ucontext.h #include sigframe.h #include asm/fixmap.h @@ -56,6 +57,11 @@ OFFSET(EXEC_DOMAIN_handler, exec_domain, handler); OFFSET(RT_SIGFRAME_sigcontext, rt_sigframe, uc.uc_mcontext); + BLANK(); + + OFFSET(pbe_address, pbe, address); + OFFSET(pbe_orig_address, pbe, orig_address); + OFFSET(pbe_next, pbe, next); /* Offset from the sysenter stack to tss.esp0 */ DEFINE(TSS_sysenter_esp0, offsetof(struct tss_struct, esp0) - diff -Nru linux-2.6.11-a/arch/i386/power/swsusp.S linux-2.6.11-b/arch/i386/power/swsusp.S --- linux-2.6.11-a/arch/i386/power/swsusp.S 2005-03-02 08:38:37.0 +0100 +++ linux-2.6.11-b/arch/i386/power/swsusp.S 2005-03-04 20:14:01.0 +0100 @@ -12,6 +12,7 @@ #include linux/linkage.h #include asm/segment.h #include asm/page.h +#include asm/asm_offsets.h .text @@ -28,28 +29,28 @@ ret ENTRY(swsusp_arch_resume) - movl $swsusp_pg_dir-__PAGE_OFFSET,%ecx - movl %ecx,%cr3 + movl$swsusp_pg_dir-__PAGE_OFFSET, %ecx + movl%ecx, %cr3 - movlpagedir_nosave, %ebx - xorl%eax, %eax - xorl%edx, %edx + movlpagedir_nosave, %edx .p2align 4,,7 copy_loop: - movl4(%ebx,%edx),%edi - movl(%ebx,%edx),%esi + testl %edx, %edx + jz done + + movlpbe_address(%edx), %esi + movlpbe_orig_address(%edx), %edi movl$1024, %ecx rep movsl - incl%eax - addl$16, %edx - cmplnr_copy_pages,%eax - jb copy_loop + movlpbe_next(%edx), %edx + jmp copy_loop .p2align 4,,7 +done: movl saved_context_esp, %esp movl saved_context_ebp, %ebp movl saved_context_ebx, %ebx diff -Nru linux-2.6.11-a/arch/x86_64/kernel/asm-offsets.c linux-2.6.11-b/arch/x86_64/kernel/asm-offsets.c --- linux-2.6.11-a/arch/x86_64/kernel/asm-offsets.c 2005-03-02 08:38:10.0 +0100 +++ linux-2.6.11-b/arch/x86_64/kernel/asm-offsets.c 2005-03-04 20:14:01.0 +0100 @@ -62,8 +62,8 @@ offsetof (struct rt_sigframe32, uc.uc_mcontext)); BLANK(); #endif - DEFINE(SIZEOF_PBE, sizeof(struct pbe)); DEFINE(pbe_address, offsetof(struct pbe, address)); DEFINE(pbe_orig_address, offsetof(struct pbe, orig_address)); + DEFINE(pbe_next, offsetof(struct pbe, next)); return 0; } diff -Nru linux-2.6.11-a/arch/x86_64/kernel/suspend_asm.S linux-2.6.11-b/arch/x86_64/kernel/suspend_asm.S --- linux-2.6.11-a/arch/x86_64/kernel/suspend_asm.S 2005-03-02 08:38:26.0 +0100 +++ linux-2.6.11-b/arch/x86_64/kernel/suspend_asm.S 2005-03-04 20:14:01.0 +0100 @@ -54,16 +54,10 @@ movq%rax, %cr4; # turn PGE back on movqpagedir_nosave(%rip), %rdx - /* compute the limit */ - movlnr_copy_pages(%rip), %eax -
Re: [patch] drm missing memset can crash X server..
* Dave Airlie ([EMAIL PROTECTED]) wrote: Egbert Eich reported a bug 2673 on bugs.freedesktop.org and tracked it down to a missing memset in the setversion ioctl, this causes X server crashes... From: Egbert Eich [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] Thanks, queued to -stable. -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] cciss: per disk queue support
This patch adds per disk queue functionality. It seems that the 2.6 kernel
expects a queue per disk. If you have multiple logical drives on a controller
all of the queues actually point back to the same queue. If a drive is deleted
it blows us out of the water.
We hold the lock during any queue operations and have added what we call a
fair-enough algorithm to prevent starving out any drive.
Please consider this for inclusion.
Signed-off-by: Mike Miller [EMAIL PROTECTED]
cciss.c | 52
cciss.h |5 +
2 files changed, 53 insertions(+), 4 deletions(-)
diff -burNp lx2611-p002/drivers/block/cciss.c lx2611-p003/drivers/block/cciss.c
--- lx2611-p002/drivers/block/cciss.c 2005-03-08 16:50:47.149175280 -0600
+++ lx2611-p003/drivers/block/cciss.c 2005-03-08 17:17:50.148441888 -0600
@@ -2090,6 +2090,9 @@ static void do_cciss_request(request_que
drive_info_struct *drv;
int i, dir;
+ /* We call start_io here in case there is a command waiting on the
+* queue that has not been sent.
+ */
if (blk_queue_plugged(q))
goto startio;
@@ -2178,6 +2181,9 @@ queue:
full:
blk_stop_queue(q);
startio:
+ /* We will already have the driver lock here so not need
+* to lock it.
+ */
start_io(h);
}
@@ -2187,7 +2193,8 @@ static irqreturn_t do_cciss_intr(int irq
CommandList_struct *c;
unsigned long flags;
__u32 a, a1;
-
+ int j;
+ int start_queue = h-next_to_run;
/* Is this interrupt for us? */
if (( h-access.intr_pending(h) == 0) || (h-interrupts_enabled == 0))
@@ -2234,13 +2241,50 @@ static irqreturn_t do_cciss_intr(int irq
}
}
- /*
-* See if we can queue up some more IO
+ /* check to see if we have maxed out the number of commands that can
+* be placed on the queue. If so then exit. We do this check here
+* in case the interrupt we serviced was from an ioctl and did not
+* free any new commands.
*/
- blk_start_queue(h-queue);
+ if ((find_first_zero_bit(h-cmd_pool_bits, NR_CMDS)) == NR_CMDS)
+ goto cleanup;
+
+ /* We have room on the queue for more commands. Now we need to queue
+* them up. We will also keep track of the next queue to run so
+* that every queue gets a chance to be started first.
+ */
+ for (j=0; j NWD; j++){
+ int curr_queue = (start_queue + j) % NWD;
+ /* make sure the disk has been added and the drive is real
+* because this can be called from the middle of init_one.
+ */
+ if(!(h-gendisk[curr_queue]-queue) ||
+ !(h-drv[curr_queue].heads))
+ continue;
+ blk_start_queue(h-gendisk[curr_queue]-queue);
+
+ /* check to see if we have maxed out the number of commands
+* that can be placed on the queue.
+ */
+ if ((find_first_zero_bit(h-cmd_pool_bits, NR_CMDS)) == NR_CMDS)
+ {
+ if (curr_queue == start_queue){
+ h-next_to_run = (start_queue + 1) % NWD;
+ goto cleanup;
+ } else {
+ h-next_to_run = curr_queue;
+ goto cleanup;
+ }
+ } else {
+ curr_queue = (curr_queue + 1) % NWD;
+ }
+ }
+
+cleanup:
spin_unlock_irqrestore(CCISS_LOCK(h-ctlr), flags);
return IRQ_HANDLED;
}
+
/*
* We cannot read the structure directly, for portablity we must use
* the io functions.
Files lx2611-p002/drivers/block/.cciss.c.rej.swp and
lx2611-p003/drivers/block/.cciss.c.rej.swp differ
diff -burNp lx2611-p002/drivers/block/cciss.h lx2611-p003/drivers/block/cciss.h
--- lx2611-p002/drivers/block/cciss.h 2005-03-08 16:50:47.150175128 -0600
+++ lx2611-p003/drivers/block/cciss.h 2005-03-08 17:03:04.279114496 -0600
@@ -84,6 +84,11 @@ struct ctlr_info
int nr_frees;
int busy_configuring;
+ /* This element holds the zero based queue number of the last
+* queue to be started. It is used for fairness.
+ */
+ int next_to_run;
+
// Disk structures we need to pass back
struct gendisk *gendisk[NWD];
#ifdef CONFIG_CISS_SCSI_TAPE
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] cciss: new controller support
This patch adds support for 2 new SAS controllers due out this summer.
It also bumps the version to 2.6.6.
Please consider this for inclusion.
Signed-off-by: Mike Miller [EMAIL PROTECTED]
Documentation/cciss.txt |2 ++
drivers/block/cciss.c | 14 ++
include/linux/pci_ids.h |1 +
3 files changed, 13 insertions(+), 4 deletions(-)
---
diff -burNp lx2611.orig/Documentation/cciss.txt
lx2611-266/Documentation/cciss.txt
--- lx2611.orig/Documentation/cciss.txt 2005-03-03 13:48:36.0 -0600
+++ lx2611-266/Documentation/cciss.txt 2005-03-08 16:39:12.097839144 -0600
@@ -15,6 +15,8 @@ This driver is known to work with the fo
* SA 6400 U320 Expansion Module
* SA 6i
* SA P600
+ * SA P800
+ * SA E400
If nodes are not already created in the /dev/cciss directory, run as root:
diff -burNp lx2611.orig/drivers/block/cciss.c lx2611-266/drivers/block/cciss.c
--- lx2611.orig/drivers/block/cciss.c 2005-03-03 13:48:46.0 -0600
+++ lx2611-266/drivers/block/cciss.c2005-03-08 16:39:01.650427392 -0600
@@ -46,14 +46,14 @@
#include linux/completion.h
#define CCISS_DRIVER_VERSION(maj,min,submin) ((maj16)|(min8)|(submin))
-#define DRIVER_NAME HP CISS Driver (v 2.6.4)
-#define DRIVER_VERSION CCISS_DRIVER_VERSION(2,6,4)
+#define DRIVER_NAME HP CISS Driver (v 2.6.6)
+#define DRIVER_VERSION CCISS_DRIVER_VERSION(2,6,6)
/* Embedded module documentation macros - see modules.h */
MODULE_AUTHOR(Hewlett-Packard Company);
-MODULE_DESCRIPTION(Driver for HP Controller SA5xxx SA6xxx version 2.6.4);
+MODULE_DESCRIPTION(Driver for HP Controller SA5xxx SA6xxx version 2.6.6);
MODULE_SUPPORTED_DEVICE(HP SA5i SA5i+ SA532 SA5300 SA5312 SA641 SA642 SA6400
-SA6i P600);
+SA6i P600 P800 E400);
MODULE_LICENSE(GPL);
#include cciss_cmd.h
@@ -82,6 +82,10 @@ const struct pci_device_id cciss_pci_dev
0x0E11, 0x4091, 0, 0, 0},
{ PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSA,
0x103C, 0x3225, 0, 0, 0},
+ { PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSB,
+ 0x103c, 0x3223, 0, 0, 0},
+ { PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSB,
+ 0x103c, 0x3231, 0, 0, 0},
{0,}
};
MODULE_DEVICE_TABLE(pci, cciss_pci_device_id);
@@ -103,6 +107,8 @@ static struct board_type products[] = {
{ 0x409D0E11, Smart Array 6400 EM, SA5_access},
{ 0x40910E11, Smart Array 6i, SA5_access},
{ 0x3225103C, Smart Array P600, SA5_access},
+ { 0x3223103C, Smart Array P800, SA5_access},
+ { 0x3231103C, Smart Array E400, SA5_access},
};
/* How long to wait (in millesconds) for board to go into simple mode */
diff -burNp lx2611.orig/include/linux/pci_ids.h
lx2611-266/include/linux/pci_ids.h
--- lx2611.orig/include/linux/pci_ids.h 2005-03-03 13:49:02.0 -0600
+++ lx2611-266/include/linux/pci_ids.h 2005-03-08 14:16:59.050059584 -0600
@@ -696,6 +696,7 @@
#define PCI_DEVICE_ID_HP_DIVA_EVEREST 0x1282
#define PCI_DEVICE_ID_HP_DIVA_AUX 0x1290
#define PCI_DEVICE_ID_HP_CISSA 0x3220
+#define PCI_DEVICE_ID_HP_CISSB 0x3230
#define PCI_VENDOR_ID_PCTECH 0x1042
#define PCI_DEVICE_ID_PCTECH_RZ10000x1000
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
