Re: [PATCH] Use more gcc extensions in the Linux headers
On Mar 10 2007 16:19, Nigel Cunningham wrote:
On Fri, 2007-03-09 at 23:03 -0500, [EMAIL PROTECTED] wrote:
On Sat, 10 Mar 2007 09:57:32 +1100, Rusty Russell said:
+/* GCC is awesome. */
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0])
\
+ sizeof(typeof(int[1 - 2*!!__builtin_types_compatible_p(typeof(arr), \
typeof(arr[0]))]))*0)
-/* GCC is awesome. */
+/* GCC leaves me speechless. */
A speechless Rusty would be horrible. That said, it would be nice if the
comment was something more like the normal Rusty pearl of wisdom. I
understand the first part, but have no idea was + sizeof(typeof(int[
does...
IOCCC entry candidate.
Simple. !!__builtin_types_compatible_p, as it sounds, will return 1 if
both types are compatible. If they are, then '1-2*!!_builtin..' will
produce -1, then - surprisingly - sizeof(typeof(int[-1])) seems strange to
me and should throw the error.
If the types are not compatible, compat_p returns 0. !! will turn it into
0. 2* will turn it into 0. 1-0 is 1. sizeof(typeof(int[1])) is valid, and
*0 will compile it away.
So in case they _ARE_ compatible, we get the compile error, as far as I
can see it. There's a ! too much in the !!_builtin line. Now we know why
such patches are dangerous.
What's more, a test program does not even fail when the types are
incompatible. (Or it's also wrong):
#include stdio.h
struct foo {
int x, y, z;
};
struct bar {
const char *fol;
};
#define c(x, y) \
sizeof(typeof(int[1 - \
2*!!__builtin_types_compatible_p(typeof(x), typeof(y))]))
int main(void)
{
printf(%d\n, c(struct foo *, struct bar *));
printf(%d\n, c(int*, int*));
}
Both printf()s throw a compile time error.
Jan
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory
Hi, It looks like 2.6.20.2 is still doing Bad Things in /sys. Cheers, Chris BUG: unable to handle kernel paging request at virtual address 6b6b6d6b printing eip: c01300ff *pde = Oops: 0002 [#1] PREEMPT SMP Modules linked in: radeon drm pwc eeprom cpufreq_ondemand p4_clockmod speedstep_lib nfsd exportfs ipv6 autofs4 nfs lockd sunrpc af_packet firmware_class binfmt_misc video thermal processor fan button ac lp parport_pc parport nvram video1394 raw1394 eth1394 snd_usb_audio compat_ioctl32 videodev v4l2_common snd_usb_lib v4l1_compat sd_mod sg snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_seq_dummy ohci1394 snd_seq_oss snd_seq_midi_event ieee1394 snd_seq ehci_hcd sata_sil snd_pcm_oss snd_mixer_oss libata snd_pcm uhci_hcd e1000 serio_raw scsi_mod snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep pcspkr psmouse snd soundcore e7xxx_edac edac_mc ide_cd cdrom i2c_i801 i2c_core intel_agp agpgart usbcore ext3 jbd CPU:1 EIP:0060:[c01300ff]Not tainted VLI EFLAGS: 00010202 (2.6.20.2 #1) EIP is at module_put+0x20/0x52 eax: 6b6b6d6b ebx: 6b6b6b6b ecx: 0001 edx: e7a01000 esi: edb7e4e4 edi: 6b6b6b6b ebp: e79fd50c esp: e7a01f58 ds: 007b es: 007b ss: 0068 Process udevd (pid: 9656, ti=e7a01000 task=f7a46030 task.ti=e7a01000) Stack: eba628a0 c0183a1e 0010 ed570870 e7a641d0 c0151263 f7ff2208 ed570870 f745b678 ed570870 c014eda0 0003 0003 f745b678 f745b6f8 c014fd99 0003 0007 0003 e7a01000 c0102bde Call Trace: [c0183a1e] sysfs_release+0x2d/0x4c [c0151263] __fput+0x96/0x13c [c014eda0] filp_close+0x51/0x58 [c014fd99] sys_close+0x70/0xa7 [c0102bde] sysenter_past_esp+0x5f/0x85 [c0270033] __sched_text_start+0x613/0x971 === Code: 00 89 f0 83 c4 0c 5b 5e 5f 5d c3 53 89 c3 85 c0 74 49 b8 01 00 00 00 e8 77 49 fe ff e8 0f 5b 07 00 c1 e0 07 8d 84 18 80 01 00 00 ff 08 83 3b 02 75 0b 8b 83 88 05 00 00 e8 c1 45 fe ff b8 01 00 EIP: [c01300ff] module_put+0x20/0x52 SS:ESP 0068:e7a01f58 6note: udevd[9656] exited with preempt_count 1 BUG: scheduling while atomic: udevd/0x1001/9656 [c026fa76] __sched_text_start+0x56/0x971 [c01a45de] vsnprintf+0x44e/0x48c [c0123af4] atomic_notifier_call_chain+0x40/0x46 [c010dc9c] nmi_watchdog_tick+0x5e/0x1ee [c01123ba] __wake_up_locked+0x1f/0x21 [c0114b05] __cond_resched+0x12/0x2c [c0270995] cond_resched+0x26/0x31 [c01404e2] unmap_vmas+0x3d3/0x4df [c0142d05] exit_mmap+0x7e/0x10a [c0116bcb] mmput+0x1d/0x78 [c011b316] do_exit+0x1b2/0x6d8 [c011007b] sys_vm86+0x95/0x21d [c0104107] die+0x1f2/0x217 [c0111812] do_page_fault+0x442/0x510 [c01113d0] do_page_fault+0x0/0x510 [c02723bc] error_code+0x7c/0x84 [c01300ff] module_put+0x20/0x52 [c0183a1e] sysfs_release+0x2d/0x4c [c0151263] __fput+0x96/0x13c [c014eda0] filp_close+0x51/0x58 [c014fd99] sys_close+0x70/0xa7 [c0102bde] sysenter_past_esp+0x5f/0x85 [c0270033] __sched_text_start+0x613/0x971 === ___ What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use attribute groups in struct device_type
On 3/10/07, Greg KH [EMAIL PROTECTED] wrote: On Sat, Mar 10, 2007 at 02:12:04AM -0500, Dmitry Torokhov wrote: On Saturday 10 March 2007 01:55, Greg KH wrote: On Fri, Mar 09, 2007 at 10:54:43PM -0800, Greg KH wrote: On Sat, Mar 10, 2007 at 01:37:34AM -0500, Dmitry Torokhov wrote: Greg, Please consider applying the patch below. It switches struct device_type to using attribute groups which os more flexible. I am using it in my input class_device - device conversion (which is 99% done btw). Argh, I never sent you my version of that, did I? Very sorry about that, I was working on fixing up the device namespace issue first, which isn't done yet :( Anyway, my patch that did that is below, feel free to use it or not if you want. I looked through -mm and the latest git and there does not seem to be any users of struct device_type yet... Yes, the input patch below uses it and I have a block-device patch from Kay in my tree that Andrew doesn't pull from (as it's usually really messed up and I know to hide this kind of breakage from him...) Oops, that patch didn't use it, this follow-on patch from Kay uses them. Ok, so input portion in your tree does not use type-attrs so we don't have a conflict here. Unless my patch messes up Kay's blockdev patch badly I'd like you to accept it. Input uses 3 attribute groups and I don't want to open-code their creation/removal. I'll take your patch and see if it messes up Kay's. If it does, I'm sure he will fix it up for me later :) Sure, no problem. I like Dmitry's change. Kay - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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: Make nenuconfig does not save parameters.
[Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300] | Here's the problem: | 1. Unpack the kernel sources, run make menuconfig. | 2. Mark the necessary options. | 3. Pick Save an alternate configuration file, enter a filename (e.g. /root/kernelcfg) | 4. Pick Exit. | -5. Configurator exits without saving. If type make bzImage, it builtd all the default options. | | And there's no .config file in kernel root directory, so i have to move there my kernelcfg and | rename it. | | If i just run make menuconfig, then pick Exit, then it asks Save kernel configuration?. | | This happens starting from kernel 2.6.20 till 2.6.20.2 | Slackware-current. | PC: Athlon-XP 2000+, 256 MB RAM. | Linux wolf 2.6.20.2 #1 SMP PREEMPT Sat Mar 10 15:41:42 MSK 2007 i686 athlon-4 i386 GNU/Linux | -- | Faith manages. Let us time to review... :) Cyrill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
imm module issues
Hi, I've compiled the 2.6.20.2 kernel today (I took the SuSE HEAD kernel instead of the vanilla one) and I'm having issues with the imm module. I still use a ZIP drive here for small backups and the imm module worked flawless on kernel 2.6.18.8 but with kernel 2.6.20.2 I get error messages that the device is offline even if the device is switched on and has a ZIP disk inside of it. This is what I get from dmesg (Sorry for posting this here if it's the wrong place, but I wasn't sure if I should report this to Novell's bugzilla because I'm using the SuSE head kernel which is not officially supported) imm: Version 2.05 (for Linux 2.4.0) imm: Found device at ID 6, Attempting to use EPP 32 bit imm: Communication established at 0x378 with ID 6 using EPP 32 bit scsi1 : Iomega VPI2 (imm) interface scsi 1:0:6:0: Direct-Access IOMEGA ZIP 250 L.58 PQ: 0 ANSI: 2 sd 1:0:6:0: scsi: Device offlined - not ready after error recovery sd 1:0:6:0: rejecting I/O to offline device sd 1:0:6:0: rejecting I/O to offline device sd 1:0:6:0: rejecting I/O to offline device sd 1:0:6:0: rejecting I/O to offline device sda : READ CAPACITY failed. sda : status=0, message=00, host=1, driver=00 sda : sense not available. sd 1:0:6:0: rejecting I/O to offline device sda: Write Protect is off sda: Mode Sense: 00 00 00 00 sd 1:0:6:0: rejecting I/O to offline device sda: asking for cache data failed sda: assuming drive cache: write through sd 1:0:6:0: Attached scsi removable disk sda sd 1:0:6:0: Attached scsi generic sg0 type 0 -- go openSUSE go! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: _proxy_pda still makes linking modules fail
On Thu, Mar 08, 2007 at 01:57:59AM +0100, Marcin 'Qrczak' Kowalczyk wrote: This is linux-2.6.20.1 with lots of patches from PLD Linux (I believe the patches don't affect the issue), compiled with gcc-4.1.2 and binutils-2.17.50.0.12 on x86. ... Please test a plain 2.6.20 from ftp.kernel.org. If it fails, please send your .config . cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use more gcc extensions in the Linux headers
Jan Engelhardt [EMAIL PROTECTED] writes: So in case they _ARE_ compatible, we get the compile error, as far as I can see it. There's a ! too much in the !!_builtin line. The error case is when the types are compatible. That means that the argument is in fact _not_ an array. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kref refcounting breakage in mainline
On Wed, 2007-03-07 at 06:39 +0100, Mike Galbraith wrote:
On Tue, 2007-03-06 at 13:04 -0800, Greg KH wrote:
On Tue, Mar 06, 2007 at 06:43:22AM +0100, Mike Galbraith wrote:
On Mon, 2007-03-05 at 16:25 -0800, Greg KH wrote:
Mike, I've reverted this patch, and I don't see any references leaking.
And, as your patch released the reference on the driver, and the
module_add_driver() call would not grab a reference to the driver, only
the module kobject, I don't see what you were trying to fix with this
patch.
Do you have a test case that this fixes?
What it fixed for me was the hard hang reported below.
http://lkml.org/lkml/2007/2/16/96
What specific module are you trying to unload that causes the hang? I
think it might just be a problem with that module, and not with all
others.
It's ipmi_si that's hanging, waits for completion that never comes.
So, I'm going to revert your patch and work to try to find the real
cause of this problem.
Yeah, my stab at it seems busted. I'll take another poke at it to see
if I can find out why (post 725522b5453dd680412f2b6463a988e4fd148757)
I'm left with a reference.
Ok, stab #2.
My reference count woes stem from module_remove_driver() not removing
the link created in module_add_driver(). With the below, my box boots
fine. Since I obviously know spit about driver layer glue, I'll just
call this one a diagnostic, and head for the hills :)
--- linux-2.6.20-rc3/kernel/module.c.org2007-03-10 15:16:47.0
+0100
+++ linux-2.6.20-rc3/kernel/module.c2007-03-10 15:43:09.0 +0100
@@ -2411,14 +2411,28 @@ void module_remove_driver(struct device_
return;
sysfs_remove_link(drv-kobj, module);
- if (drv-owner drv-owner-mkobj.drivers_dir) {
- driver_name = make_driver_name(drv);
- if (driver_name) {
- sysfs_remove_link(drv-owner-mkobj.drivers_dir,
+ driver_name = make_driver_name(drv);
+ if (!driver_name)
+ return;
+ if (drv-owner drv-owner-mkobj.drivers_dir)
+ sysfs_remove_link(drv-owner-mkobj.drivers_dir,
driver_name);
- kfree(driver_name);
- }
+ else if (drv-mod_name) {
+ struct module_kobject *mk;
+ struct kobject *mkobj;
+
+ /* Lookup built-in module entry in /sys/modules */
+ mkobj = kset_find_obj(module_subsys.kset, drv-mod_name);
+ if (!mkobj)
+ goto out_free;
+ mk = container_of(mkobj, struct module_kobject, kobj);
+ module_create_drivers_dir(mk);
+ sysfs_remove_link(mk-drivers_dir, driver_name);
+ /* Release reference taken via lookup */
+ kobject_put(mkobj);
}
+out_free:
+ kfree(driver_name);
}
EXPORT_SYMBOL(module_remove_driver);
#endif
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: question about periodic clocks
Thomas Gleixner wrote: Good point. I never thought about that and we set the period in the clock event device itself. You are right, the clockevents layer should hand over the period either with the set_mode call or seperately. Probably with the set_mode call, as it is needed exactly there and we don't want to have a if (dev-mode == XXX) check in set_next_event(). I look into this. So, in the meantime, the period is 1/HZ? I also have a question about clockevent cpumasks. I was using the lapic clockevent as a model, but as I understand it there's a lapic per CPU, which explains why it registers a clockevent per cpu with that cpu alone in the cpumask. The Xen timer is a bit different; I guess more like hpet. There's a single (virtual-)machine-wide timer, which is owned by the last cpu with programmed it; ie, that cpu is the one which gets the resulting event interrupt. Does this mean I should register a single clockevent device with a cpumask of CPU_MASK_ALL? Or should I constrain it to a single cpu? There's a comment in hpet.c saying * Start hpet with the boot cpu mask and make it * global after the IO_APIC has been initialized. but I don't see any place where the hpet cpumask is updated. Thanks, J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] hotplug cpu: migrate a task within its cpuset
Hi-
Ingo Molnar wrote:
* Cliff Wickman [EMAIL PROTECTED] wrote:
With this patch, migrate the task to:
1) to any cpu on the same node as the disabled cpu, which is both online
and among that task's cpus_allowed
2) to any online cpu within the task's cpuset
3) to any cpu which is both online and among that task's cpus_allowed
Diffed against 2.6.21-rc3 (Andrew's current top of tree)
looks good to me.
Acked-by: Ingo Molnar [EMAIL PROTECTED]
+ /* try to stay on the same cpuset */
+ if (dest_cpu == NR_CPUS) {
+ p-cpus_allowed = cpuset_cpus_allowed(p);
+ dest_cpu = any_online_cpu(p-cpus_allowed);
+ }
what's the practical effect of this - when moving the last CPU offline
from a node you got jobs migrated to really alien nodes? Thus i think we
should queue this up for v2.6.21 too, correct? It's a NOP on systems
that do not set up cpusets, so it's low-risk.
See my earlier reply to this patch. Calling cpuset_cpus_allowed
(which takes a mutex) here is a bug, since move_task_off_dead_cpu must
be called with interrupts disabled.
btw., unrelated to your patch, there's this bit right after the code
above:
/* No more Mr. Nice Guy. */
if (dest_cpu == NR_CPUS) {
rq = task_rq_lock(p, flags);
cpus_setall(p-cpus_allowed);
dest_cpu = any_online_cpu(p-cpus_allowed);
out of consistency, shouldnt the cpus_setall() rather be:
p-cpus_allowed = cpu_possible_map;
? It shouldnt make any real difference but it looks more consistent.
The default value of cpus_allowed is CPU_MASK_ALL, I thought -- at
least that's what we set init's to early on. Though, as you say, it
shouldn't make any difference.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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/9] signalfd/timerfd v1 - signalfd core ...
Davide Libenzi wrote:
+int signalfd_deliver(struct sighand_struct *sighand, int sig,
+ struct siginfo *info)
+{
+ int nsig = 0;
+ struct list_head *pos;
+ struct signalfd_ctx *ctx;
+
+ list_for_each(pos, sighand-sfdlist) {
+ ctx = list_entry(pos, struct signalfd_ctx, lnk);
list_for_each_entry()
+ /*
+ * We use a negative signal value as a way to broadcast that the
+ * sighand has been orphaned, so that we can notify all the
+ * listeners about this. Remeber the ctx-sigmask is inverted,
+ * so if the user is interested in a signal, that corresponding
+ * bit will be zero.
+ */
+ if (sig 0 || !sigismember(ctx-sigmask, sig)) {
+ __wake_up_locked(ctx-wqh,
+ TASK_UNINTERRUPTIBLE |
TASK_INTERRUPTIBLE);
wake_up_locked(ctx-wqh)
+asmlinkage long sys_signalfd(int ufd, sigset_t __user *user_mask, size_t
sizemask)
+{
[...snip...]
+ if (ufd == -1) {
+ error = -ENOMEM;
+ ctx = kmem_cache_alloc(signalfd_ctx_cachep, GFP_KERNEL);
+ if (!ctx)
+ goto err_exit;
+
+ init_waitqueue_head(ctx-wqh);
+ ctx-sigmask = sigmask;
+ ctx-tsk = current;
+ get_task_struct(current);
+
+ /*
+ * We also increment the sighand count to make sure
+ * it doesn't go away from us in poll() when the task
+ * exits (which can happen if the fd is passed to
+ * another process with unix domain sockets.
+ *
+ * This also guarantees that an execve() will reallocate
+ * the signal state, and thus avoids security concerns
+ * with a untrusted process that passes off the signal
+ * queue fd to another, and then does a suid execve.
+ */
+ ctx-sighand = current-sighand;
+ atomic_inc(ctx-sighand-count);
I personally don't like this. de_thread() was/is the source of numerous
problems, and this patch adds yet another subtle dependency. The usage of
private __cleanup_sighand() is not good per se, imho.
Also, this is not so flexible, we can't take S_ISUID into account. It seems
logical to preserve ctx after a normal exec.
I think, we don't need signalfd_ctx-sighand at all, please see below.
+ } else {
+ error = -EBADF;
+ file = fget(ufd);
+ if (!file)
+ goto err_exit;
+ ctx = file-private_data;
+ error = -EINVAL;
+ if (file-f_op != signalfd_fops) {
+ fput(file);
+ goto err_exit;
+ }
+ spin_lock_irq(ctx-sighand-siglock);
+ ctx-sigmask = sigmask;
+ spin_unlock_irq(ctx-sighand-siglock);
+ wake_up(ctx-wqh);
Race with signalfd_read()-__add_wait_queue().
+static unsigned int signalfd_poll(struct file *file, poll_table *wait)
+{
+ struct signalfd_ctx *ctx = file-private_data;
+ struct sighand_struct *sighand = ctx-sighand;
+ unsigned int events = 0;
+ unsigned long flags;
+
+ poll_wait(file, ctx-wqh, wait);
+
+ spin_lock_irqsave(sighand-siglock, flags);
+ /*
+ * Let the caller get a POLLIN in this case, ala socket recv() when
+ * the peer disconnect. The check for the changed sighand must be
+ * done before calling next_signal(), since if sighand changed, a call
+ * to next_signal() would crash. It'd be possible to avoid grabbing a
+ * lock by incrementing the tsk-signal count like we do with the
+ * tsk-sighand, but the code in __exit_signal() assumes that the
+ * tsk-signal can be freed only there, and this would require
+ * some code restructuring that I'm living out at this time.
+ */
+ if (sighand != ctx-tsk-sighand || ctx-tsk-signal == NULL ||
We don't need ctx-tsk-signal == NULL. tsk-signal == NULL (when checked
under -siglock) implies tsk-sighand == NULL. This is covered by the first
sighand != ctx-tsk-sighand check.
+static ssize_t signalfd_read(struct file *file, char *buf, size_t count,
+ loff_t *ppos)
+{
[...snip...]
+ for (;;) {
+ if (sighand != ctx-tsk-sighand) {
+ /*
+ * Let the caller read zero byte, ala socket
recv()
+ * when the peer disconnect. This test must be
done
+ * before doing a dequeue_signal(), because if
the
+ * task's sighand changed, a dequeue_signal()
is going
+ * to crash (tsk-signal is set to NULL).
+ */
+
pciehp: Cannot get control of hotplug hardware
Ever since I started playing with suspend I started turning on PCI Hot Plug support since then I have been seeing messages like whats below from dmesg I'm not exactly sure how this actually impacts me if it does at all. I just thought it didn't look exactly right so I wanted to inquire about it. Does anyone know what is going on here? -Ryan pci_hotplug: PCI Hot Plug PCI Core version: 0.5 acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 decode_hpp: Could not get hotplug parameters. Use defaults pciehp: HPC vendor_id 8086 device_id 27d0 ss_vid 0 ss_did 0 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 pciehp: Cannot get control of hotplug hardware for pci :00:1c.0 pciehp: HPC vendor_id 8086 device_id 27d2 ss_vid 0 ss_did 0 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 pciehp: Cannot get control of hotplug hardware for pci :00:1c.1 pciehp: HPC vendor_id 8086 device_id 27d4 ss_vid 0 ss_did 0 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 pciehp: Cannot get control of hotplug hardware for pci :00:1c.2 pciehp: HPC vendor_id 8086 device_id 27d6 ss_vid 0 ss_did 0 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 pciehp: Cannot get control of hotplug hardware for pci :00:1c.3 pciehp: HPC vendor_id 8086 device_id 27e0 ss_vid 0 ss_did 0 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 pciehp: Cannot get control of hotplug hardware for pci :00:1c.4 pciehp: HPC vendor_id 8086 device_id 27e2 ss_vid 0 ss_did 0 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 pciehp: Cannot get control of hotplug hardware for pci :00:1c.5 pciehp: PCI Express Hot Plug Controller Driver version: 0.4 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kref refcounting breakage in mainline
P.S. forgot to include diagnostic log. Kobject c0644890 is the source of my woes. Printk's come below WARN_ON(is_ipmi_si_kobj). Post-tinker log is huge, and probably not interesting. [ 30.397160] kobject ipmi_devintf: registering. parent: NULL, set: module [ 30.404033] kobject_uevent_env [ 30.407098] fill_kobj_path: path = '/module/ipmi_devintf' [ 30.412524] BUG: at lib/kobject.c:448 kobject_get() [ 30.417402] [c0105086] show_trace_log_lvl+0x1a/0x30 [ 30.422564] [c01057b2] show_trace+0x12/0x14 [ 30.427031] [c0105856] dump_stack+0x16/0x18 [ 30.431501] [c02d3c2b] kobject_get+0x66/0x87 [ 30.436056] [c02d3f1e] kobject_shadow_add+0x10/0x1e8 [ 30.441312] [c02d4100] kobject_add+0xa/0xc [ 30.445695] [c06804c0] kernel_param_sysfs_setup+0x4d/0x7f [ 30.451376] [c068067a] param_sysfs_init+0x188/0x1c3 [ 30.456538] [c06725bc] init+0x144/0x26c [ 30.460661] [c0104cfb] kernel_thread_helper+0x7/0x1c [ 30.465907] === [ 30.469486] get: c18f65c0 count after get is 2 [ 30.473927] kobject ipmi_si: registering. parent: NULL, set: module [ 30.480372] kobject_uevent_env [ 30.483430] fill_kobj_path: path = '/module/ipmi_si' .. [ 73.266556] bus platform: add driver ipmi [ 73.278013] kobject ipmi: registering. parent: NULL, set: drivers [ 73.291847] kobject_uevent_env [ 73.302358] fill_kobj_path: path = '/bus/platform/drivers/ipmi' [ 73.315943] ipmi message handler version 39.1 [ 73.327839] ipmi device interface [ 73.338524] device class 'ipmi': registering [ 73.350158] subsystem ipmi: registering [ 73.361309] kobject ipmi: registering. parent: NULL, set: class [ 73.374841] bus platform: add driver ipmi_si [ 73.386442] BUG: at lib/kobject.c:448 kobject_get() [ 73.398617] [c0105086] show_trace_log_lvl+0x1a/0x30 [ 73.411079] [c01057b2] show_trace+0x12/0x14 [ 73.422780] [c0105856] dump_stack+0x16/0x18 [ 73.434324] [c02d3c2b] kobject_get+0x66/0x87 [ 73.445860] [c02d3f1e] kobject_shadow_add+0x10/0x1e8 [ 73.458088] [c02d4100] kobject_add+0xa/0xc [ 73.469286] [c02d4248] kobject_register+0x22/0xb3 [ 73.480986] [c035a13e] bus_add_driver+0x77/0x1ae [ 73.492592] [c035b109] driver_register+0x54/0x84 [ 73.504101] [c034c486] init_ipmi_si+0x4d/0x829 [ 73.515335] [c06725bc] init+0x144/0x26c [ 73.525822] [c0104cfb] kernel_thread_helper+0x7/0x1c [ 73.537452] === [ 73.547290] get: c064475c count after get is 2 [ 73.557969] kobject ipmi_si: registering. parent: NULL, set: drivers [ 73.570825] kobject_uevent_env [ 73.580011] fill_kobj_path: path = '/bus/platform/drivers/ipmi_si' [ 73.592622] BUG: at lib/kobject.c:242 kobject_register() [ 73.604312] [c0105086] show_trace_log_lvl+0x1a/0x30 [ 73.615822] [c01057b2] show_trace+0x12/0x14 [ 73.626551] [c0105856] dump_stack+0x16/0x18 [ 73.637211] [c02d429f] kobject_register+0x79/0xb3 [ 73.648325] [c035a13e] bus_add_driver+0x77/0x1ae [ 73.659297] [c035b109] driver_register+0x54/0x84 [ 73.670164] [c034c486] init_ipmi_si+0x4d/0x829 [ 73.680756] [c06725bc] init+0x144/0x26c [ 73.690699] [c0104cfb] kernel_thread_helper+0x7/0x1c [ 73.701854] === [ 73.711295] register: c064475c count now is 2 error 0 [ 73.722218] BUG: at lib/kobject.c:448 kobject_get() [ 73.732911] [c0105086] show_trace_log_lvl+0x1a/0x30 [ 73.743927] [c01057b2] show_trace+0x12/0x14 [ 73.754112] [c0105856] dump_stack+0x16/0x18 [ 73.764253] [c02d3c2b] kobject_get+0x66/0x87 [ 73.774532] [c035b157] get_driver+0x11/0x18 [ 73.784725] [c035b194] driver_create_file+0xf/0x32 [ 73.795559] [c035a221] bus_add_driver+0x15a/0x1ae [ 73.806343] [c035b109] driver_register+0x54/0x84 [ 73.817055] [c034c486] init_ipmi_si+0x4d/0x829 [ 73.827595] [c06725bc] init+0x144/0x26c [ 73.837468] [c0104cfb] kernel_thread_helper+0x7/0x1c [ 73.848544] === [ 73.857932] get: c064475c count after get is 3 [ 73.868223] BUG: at lib/kobject.c:494 kobject_put() [ 73.878943] [c0105086] show_trace_log_lvl+0x1a/0x30 [ 73.890019] [c01057b2] show_trace+0x12/0x14 [ 73.900239] [c0105856] dump_stack+0x16/0x18 [ 73.910294] [c02d3ae7] kobject_put+0x69/0x82 [ 73.920304] [c035b144] put_driver+0xb/0xd [ 73.929909] [c035b1b0] driver_create_file+0x2b/0x32 [ 73.940362] [c035a221] bus_add_driver+0x15a/0x1ae [ 73.950686] [c035b109] driver_register+0x54/0x84 [ 73.960966] [c034c486] init_ipmi_si+0x4d/0x829 [ 73.971055] [c06725bc] init+0x144/0x26c [ 73.980478] [c0104cfb] kernel_thread_helper+0x7/0x1c [ 73.991119] === [ 74.50] put: c064475c count before put is 3 [ 74.010026] BUG: at lib/kobject.c:448 kobject_get() [ 74.020367] [c0105086] show_trace_log_lvl+0x1a/0x30 [ 74.031011] [c01057b2] show_trace+0x12/0x14 [ 74.040867] [c0105856] dump_stack+0x16/0x18 [ 74.050602] [c02d3c2b] kobject_get+0x66/0x87 [ 74.060353] [c035b157] get_driver+0x11/0x18 [
Re: 2.6.21-rc3-mm1
On Fri, Mar 09, 2007 at 06:18:51PM -0800, Andrew Morton wrote:
On Thu, 08 Mar 2007 21:50:29 +0100 Michal Piotrowski [EMAIL PROTECTED]
wrote:
Andrew Morton napisał(a):
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc3-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm1/
cpu_hotplug (AutoTest) hangs at this
=
[ INFO: possible recursive locking detected ]
2.6.21-rc3-mm1 #2
-
sh/7213 is trying to acquire lock:
(sched_hotcpu_mutex){--..}, at: [c033883a] mutex_lock+0x1c/0x1f
but task is already holding lock:
(sched_hotcpu_mutex){--..}, at: [c033883a] mutex_lock+0x1c/0x1f
other info that might help us debug this:
4 locks held by sh/7213:
#0: (cpu_add_remove_lock){--..}, at: [c033883a] mutex_lock+0x1c/0x1f
#1: (sched_hotcpu_mutex){--..}, at: [c033883a] mutex_lock+0x1c/0x1f
#2: (cache_chain_mutex){--..}, at: [c033883a] mutex_lock+0x1c/0x1f
#3: (workqueue_mutex){--..}, at: [c033883a] mutex_lock+0x1c/0x1f
That's pretty useless, isn't it? We need to know the mutex_lock() caller
here.
stack backtrace
[c0105256] show_trace_log_lvl+0x1a/0x2f
[c010597b] show_trace+0x12/0x14
[c0105a3d] dump_stack+0x16/0x18
[c013fc73] __lock_acquire+0x1aa/0xceb
[c014082d] lock_acquire+0x79/0x93
[c03385dc] __mutex_lock_slowpath+0x107/0x349
[c033883a] mutex_lock+0x1c/0x1f
[c011d924] sched_getaffinity+0x14/0x91
[c015796d] __synchronize_sched+0x11/0x5f
[c011d257] detach_destroy_domains+0x2c/0x30
[c011fc1a] update_sched_domains+0x27/0x3a
[c012fe7a] notifier_call_chain+0x2b/0x4a
[c012fec6] __raw_notifier_call_chain+0x19/0x1e
[c0145756] _cpu_down+0x70/0x282
[c014598e] cpu_down+0x26/0x38
[c0272714] store_online+0x27/0x5a
[c026f610] sysdev_store+0x20/0x25
[c01b7a8e] sysfs_write_file+0xc1/0xe9
[c0180052] vfs_write+0xd1/0x15a
[c0180682] sys_write+0x3d/0x72
[c0104270] syscall_call+0x7/0xb
l *0xc033883a
0xc033883a is in mutex_lock (/mnt/md0/devel/linux-mm/kernel/mutex.c:92).
87 /*
88 * The locking fastpath is the 1-0 transition from
89 * 'unlocked' into 'locked' state.
90 */
91 __mutex_fastpath_lock(lock-count, __mutex_lock_slowpath);
92 }
93
94 EXPORT_SYMBOL(mutex_lock);
95
96 static void fastcall noinline __sched
I didn't test other -mm's with this test.
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc3-mm1/console.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc3-mm1/mm-config
I can't immediately spot the bug. Probably it's caused by rcu-preempt's
changes to synchronize_sched(): that function now does a heap more than it
used to, including taking sched_hotcpu_muex.
So, what to do about this. Paul, I'm thinking that I should drop
rcu-preempt for now - I don't think we ended up being able to identify any
particular benefit which it brings to current mainline, and I suspect that
things will become simpler if/when we start using the process freezer for
CPU hotplug.
It certainly makes sense for Michal to try backing out rcu-preempt using
your broken-out list of patches. If that makes the problem go away,
then I would certainly have a hard time arguing with you. We are working
on getting measurements showing benefit of rcu-preempt, but aren't there
yet.
Thanx, Paul
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Make nenuconfig does not save parameters.
[Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300]
| Here's the problem:
| 1. Unpack the kernel sources, run make menuconfig.
| 2. Mark the necessary options.
| 3. Pick Save an alternate configuration file, enter a filename (e.g.
/root/kernelcfg)
| 4. Pick Exit.
| -5. Configurator exits without saving. If type make bzImage, it builtd all
the default options.
|
| And there's no .config file in kernel root directory, so i have to move
there my kernelcfg and
| rename it.
|
| If i just run make menuconfig, then pick Exit, then it asks Save kernel
configuration?.
|
| This happens starting from kernel 2.6.20 till 2.6.20.2
| Slackware-current.
| PC: Athlon-XP 2000+, 256 MB RAM.
| Linux wolf 2.6.20.2 #1 SMP PREEMPT Sat Mar 10 15:41:42 MSK 2007 i686 athlon-4
i386 GNU/Linux
| --
| Faith manages.
| -
|
Hi, Vladimir
here is the patch to resolve your problem. Test it and write me the
results...
Cyrill
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 664fe29..98836b6 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -432,8 +432,7 @@ int conf_write(const char *name)
use_timestamp ? # : ,
use_timestamp ? ctime(now) : );
- if (!conf_get_changed())
- sym_clear_all_valid();
+ sym_clear_all_valid();
menu = rootmenu.list;
while (menu) {
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 3f9a132..ea32df8 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -840,8 +840,11 @@ static void conf_save(void)
case 0:
if (!dialog_input_result[0])
return;
- if (!conf_write(dialog_input_result))
+ res = conf_get_changed(); /* temporary used */
+ if (!conf_write(dialog_input_result)) {
+ sym_set_change_count(res);
return;
+ }
show_textbox(NULL, _(Can't create file! Probably a
nonexistent directory.), 5, 60);
break;
case 1:
Re: question about periodic clocks
On Sat, 2007-03-10 at 07:50 -0800, Jeremy Fitzhardinge wrote: Thomas Gleixner wrote: Good point. I never thought about that and we set the period in the clock event device itself. You are right, the clockevents layer should hand over the period either with the set_mode call or seperately. Probably with the set_mode call, as it is needed exactly there and we don't want to have a if (dev-mode == XXX) check in set_next_event(). I look into this. So, in the meantime, the period is 1/HZ? Yep. I also have a question about clockevent cpumasks. I was using the lapic clockevent as a model, but as I understand it there's a lapic per CPU, which explains why it registers a clockevent per cpu with that cpu alone in the cpumask. The Xen timer is a bit different; I guess more like hpet. There's a single (virtual-)machine-wide timer, which is owned by the last cpu with programmed it; ie, that cpu is the one which gets the resulting event interrupt. Does this mean I should register a single clockevent device with a cpumask of CPU_MASK_ALL? Or should I constrain it to a single cpu? Uuurg. That's ugly. clockevents expect a per CPU timer especially for dynamic ticks. If you cannot provide a per cpu timer, then you probably need to use the broadcast trick. Register a primary clocksource (as PIT/HPET) and register per CPU dummy clocksources with CLOCK_EVT_FEAT_DUMMY set - we use the same trick, when the lapic timer is broken. The clockevents code then uses PIT/HPET as the primary tick source and broadcasts the periodic tick to the other CPUs. In that case the dyntick / highres features are disabled. We did some experiments to support multiple CPUs with one timer for hres/dyntick but it does not scale and it is so ugly that it is not worth the trouble. It works for the lapic stops in C3 case, as we have a well defined point (right before going into the deep power state) where we can rearm the global clock event device. As we are idle at that point anyway there is not much penalty, but I really dont want to do that in an active system. There's a comment in hpet.c saying * Start hpet with the boot cpu mask and make it * global after the IO_APIC has been initialized. but I don't see any place where the hpet cpumask is updated. I wanted to do that in the first place, but never bothered. In an UP environment it does not matter. On a sane SMP box (where we do not have the local APIC stops in C3 problem) the HPET (analogous PIT) is switched off for ever. In the case of LAPIC stops in C3 the HPET(PIT) is used as a broadcast fallback. That means before we go into C3 we arm the HPET/PIT for the earliest to expire lapic event of all CPUs. In that case it does not matter, whether HPET/PIT is pinned to CPU#0 or anything else. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How soon is soon? MCP55 NCQ support on Linux...
Zoltan Boszormenyi wrote: Hi, I have seen your message in LKML archive: http://marc.theaimsgroup.com/?l=linux-kernelm=116046278930988w=2 It's dated 2006.10.10 and states that a patch to support NCQ on MCP55/MCP61 under Linux is coming soon. Now it's five months later and I would like to ask when will it be supported? Especially when this seems to be the last NVidia chipset that has NCQ but isn't supported under Linux. Thanks in advance, Zoltán Böszörményi It's a good question, I haven't heard anything about this either. Even documentation to allow others to implement it would be useful, although there may be some kind of IP issues that prevent public release of the specs, as I assume has prevented this with the nForce4 ADMA controllers. I'm not sure what the story is with MCP51 either.. apparently the Windows driver NCQ support for that chipset was late in coming but I think it does have it now too.. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Make nenuconfig does not save parameters.
On Mar 10 2007 19:06, Cyrill Gorcunov wrote: [Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300] | Here's the problem: | 1. Unpack the kernel sources, run make menuconfig. | 2. Mark the necessary options. | 3. Pick Save an alternate configuration file, enter a filename (e.g. /root/kernelcfg) | 4. Pick Exit. | -5. Configurator exits without saving. If type make bzImage, it builtd all the default options. Well, you already saved explicitly and did not make any further changes after that, so it won't ask again on exit (perhaps all Office Suites do the same). In fact, if you do exactly that, menuconfig assumes you do not intend to build a kernel (since you did not save to .config). Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question about periodic clocks
Thomas Gleixner wrote: Uuurg. That's ugly. clockevents expect a per CPU timer especially for dynamic ticks. If you cannot provide a per cpu timer, then you probably need to use the broadcast trick. Ah, apologies, I'm wrong about this. I misread the Xen code; the timers are per-vcpu, but as an implementation detail within the hypervisor it keeps track of which real cpu is managing that timer. But logically the timers are per-vcpu. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Make nenuconfig does not save parameters.
[Jan Engelhardt - Sat, Mar 10, 2007 at 05:26:03PM +0100] | | On Mar 10 2007 19:06, Cyrill Gorcunov wrote: | [Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300] | | Here's the problem: | | 1. Unpack the kernel sources, run make menuconfig. | | 2. Mark the necessary options. | | 3. Pick Save an alternate configuration file, enter a filename (e.g. /root/kernelcfg) | | 4. Pick Exit. | | -5. Configurator exits without saving. If type make bzImage, it builtd all the default options. | | Well, you already saved explicitly and did not make any further changes | after that, so it won't ask again on exit (perhaps all Office Suites do | the same). In fact, if you do exactly that, menuconfig assumes you do not | intend to build a kernel (since you did not save to .config). | | | Jan | -- | Hi, Jan so you think that is a normal behaviour? I mean sould we leave all as it is? Cyrill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler)
William Lee Irwin III wrote: William Lee Irwin III wrote: A useful exercise may also be enumerating your expectations and having those who actually work with the code describe how well those are actually met. On Sat, Mar 10, 2007 at 08:34:25AM +0300, Al Boldi wrote: A runtime configurable framework that allows for dynamically extensible schedulers. PlugSched seems to be a good start. Last I checked there were limits to runtime configurability centering around only supporting a compiled-in set of scheduling drivers, unless Peter's taken it the rest of the way without my noticing. It's unclear what you have in mind in terms of dynamic extensibility. My only guess would be pluggable scheduling policy/class support for individual schedulers in addition to plugging the individual schedulers, except I'm rather certain that Williams' code doesn't do anything with modules. Correct, it doesn't, yet. But do you think that PlugSched has the basic infrastructure in place to support this, or would it require a complete redesign/rewrite. Thanks! -- Al - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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: Make nenuconfig does not save parameters.
On Mar 10 2007 19:35, Cyrill Gorcunov wrote: [Jan Engelhardt - Sat, Mar 10, 2007 at 05:26:03PM +0100] | On Mar 10 2007 19:06, Cyrill Gorcunov wrote: | [Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300] | | Here's the problem: | | 1. Unpack the kernel sources, run make menuconfig. | | 2. Mark the necessary options. | | 3. Pick Save an alternate configuration file, enter a filename (e.g. /root/kernelcfg) | | 4. Pick Exit. | | -5. Configurator exits without saving. If type make bzImage, it builtd all the default options. | | Well, you already saved explicitly and did not make any further changes | after that, so it won't ask again on exit (perhaps all Office Suites do | the same). In fact, if you do exactly that, menuconfig assumes you do not | intend to build a kernel (since you did not save to .config). Hi, Jan so you think that is a normal behaviour? I mean sould we leave all as it is? Yes. If you want to save your current configuration to two files, save it twice: Save an alternate configuration file - /root/kernelcfg Save an alternate configuration file - just enter, use .config Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Make nenuconfig does not save parameters.
On Mar 10 2007 19:46, Vladimir wrote: On Mar 10 2007 19:06, Cyrill Gorcunov wrote: [Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300] | Here's the problem: | 1. Unpack the kernel sources, run make menuconfig. | 2. Mark the necessary options. | 3. Pick Save an alternate configuration file, enter a filename (e.g. /root/kernelcfg) | 4. Pick Exit. | -5. Configurator exits without saving. If type make bzImage, it builtd all the default options. Well, you already saved explicitly and did not make any further changes after that, so it won't ask again on exit (perhaps all Office Suites do the same). In fact, if you do exactly that, menuconfig assumes you do not intend to build a kernel (since you did not save to .config). Hm Do i have to Save an alternate configuration file to .config manually? The configurator used to do that automatically when i pick Exit. I think that was reasonable. Anyway, the patch Cyrill sent me works all right. If you make some changes and do not call 'save an alternate config file', it will ask you on exit. If you make no changes at all, a .config won't get written - true. But then, the defconfig will be used anyway. All is fine. Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RSDL-mm 0/6] Rotating Staircase DeadLine scheduler for -mm
Le dimanche 11 mars 2007 à 01:03 +1100, Con Kolivas a écrit : On Saturday 10 March 2007 22:49, Nicolas Mailhot wrote: Oops ⇒ http://bugzilla.kernel.org/show_bug.cgi?id=8166 Thanks very much. I can't get your config to boot on qemu, but could you please try this debugging patch? It's not a patch you can really run the machine with but might find where the problem occurs. Specifically I'm looking for the warning MISSING STATIC BIT in your case. http://ck.kolivas.org/patches/crap/sched-rsdl-0.28-stuff.patch I attached a screenshot of the patched kernel boot -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [PATCH] Use more gcc extensions in the Linux headers
On Mar 10 2007 16:18, Andreas Schwab wrote: Jan Engelhardt [EMAIL PROTECTED] writes: So in case they _ARE_ compatible, we get the compile error, as far as I can see it. There's a ! too much in the !!_builtin line. The error case is when the types are compatible. That means that the argument is in fact _not_ an array. That one should go in as a comment for that macro. Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] hotplug cpu: migrate a task within its cpuset
* Nathan Lynch [EMAIL PROTECTED] wrote:
+ /* try to stay on the same cpuset */
+ if (dest_cpu == NR_CPUS) {
+ p-cpus_allowed = cpuset_cpus_allowed(p);
+ dest_cpu = any_online_cpu(p-cpus_allowed);
+ }
what's the practical effect of this - when moving the last CPU offline
from a node you got jobs migrated to really alien nodes? Thus i think we
should queue this up for v2.6.21 too, correct? It's a NOP on systems
that do not set up cpusets, so it's low-risk.
See my earlier reply to this patch. Calling cpuset_cpus_allowed
(which takes a mutex) here is a bug, since move_task_off_dead_cpu must
be called with interrupts disabled.
ouch. i only checked the !CONFIG_CPUSET case :-/ It's a really bad idea
to have any locking there indeed. The name itself suggests some atomic
action.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
BUG: Killing and reviving files with USB disks
Hello LKML, BUG: Killing and reviving files with USB disks This is a reproducible demonstration of the problem initially reported in my previous e-mail, titled PROBLEM: 'bio too big device' after moving to a USB disk (http://lkml.org/lkml/2007/3/7/657) Given that my previous e-mail appears to have been ignored in its entirety, it's probably a good idea to send in this reproducible demonstration of the problem, with a more dramatic headline. Summary: 01. Create LVM volume; initialize dm-crypt; initialize reiserfs; mount 02. Populate the disk with files; sync; flush caches 03. Confirm that the files are still readable and non-corrupt (sha1sum) 04. Migrate logical volume to USB disk; sync; flush caches 05. Confirm that ALL PREVIOUSLY VERIFIED FILES ARE CORRUPT, spewing I/O errors 06. Observe bio too big device dm-0 (256 240) messages in dmesg 07. Run reiserfsck to check for corruptions -- none. 08. Migrate logical volume back to SATA disk; sync; flush caches 09. Confirm that files are readable and non-corrupt again 10. Clean up Meet the characters: * /dev/sda: The protagonist, my old SATA disk. * /dev/sda5: the LVM partition on the old disk. * /dev/sdb: The antagonist, my new offending USB disk; whole disk is used as an LVM physical volume. * /dev/primary: LVM volume group 'primary' consisting of /dev/sdb and /dev/sda5 * /dev/primary/punchbag: LVM volume 'punchbag' for demonstration purposes. * /dev/mapper/crypt-punchbag: The dm-crypt decrypted loopback device. And their accessories: * Linux non 2.6.19-gentoo-r6 #1 Wed Feb 28 20:55:24 EET 2007 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux * USB disk 120GB Western Digital, model 00UE-00KVT0 (according to udev), serial DEF10CD7F64C * Older SATA disk 200GB Seagate 7200.7, model ST3200822AS * Motherboard Asus A8N5X, nForce4 chipset * Offending file system: reiserfs v3.6, mounted with noatime,barrier=flush * dm-crypt using aes-256 with cbc-essiv:sha256; using assembly-optimized AES on x86_64 (CONFIG_CRYPTO_AES_X86_64) * Test partition is 68 extents times 16MiB = 1088 MiB large (that's the largest I could allocate while remaining in one segment -- otherwise lvmove wouldn't move the partition back to /dev/sda5 after defragmenting it.) * LVM utilities version: 2.02.17 (2006-12-14) * LVM library version: 1.02.12 (2006-10-13) * LVM driver version: 4.10.0 * cryptsetup-luks 1.0.4 (user space interface to dm-crypt) Let the play begin: [non]# pvdisplay /dev/sda5 --- Physical volume --- PV Name /dev/sda5 VG Name primary PV Size 145.83 GB / not usable 2.73 MB Allocatable yes PE Size (KByte) 16384 Total PE 9333 Free PE 117 Allocated PE 9216 PV UUID YdrDuL-jw5z-J0SA-EEKU-NOC4-6gGR-T90YCA [non]# pvdisplay /dev/sdb --- Physical volume --- PV Name /dev/sdb VG Name primary PV Size 111.79 GB / not usable 9.46 MB Allocatable yes PE Size (KByte) 16384 Total PE 7154 Free PE 7129 Allocated PE 25 PV UUID nE8C5L-lfI1-VNgs-Q7ei-1Zz3-GeGT-UNhH4p [non]# lvcreate -n punchbag --extents 68 primary /dev/sda5 Logical volume punchbag created [non]# lvs --segments -o +devices LV VG Attr #Str Type SSize Devices [...] punchbag primary -wi-a-1 linear 1.06G /dev/sda5(0) [...] [non]# cryptsetup luksFormat /dev/primary/punchbag -c aes-cbc-essiv:sha256 -h sha1 [...] Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Command successful. [non]# cryptsetup luksOpen /dev/primary/punchbag crypt-punchbag Enter LUKS passphrase: key slot 0 unlocked. Command successful. [non]# mkfs.reiserfs /dev/mapper/crypt-punchbag [...] Guessing about desired format.. Kernel 2.6.19-gentoo-r6 is running. Format 3.6 with standard journal Count of blocks on the device: 343920 Number of blocks consumed by mkreiserfs formatting process: 8222 Blocksize: 4096 Hash function used to sort names: r5 Journal Size 8193 blocks (first block 18) Journal Max transaction length 1024 inode generation number: 0 UUID: c1857208-5090-49dd-9163-9fb002d96a88 ATTENTION: YOU SHOULD REBOOT AFTER FDISK! ALL DATA WILL BE LOST ON '/dev/mapper/crypt-punchbag'! Continue (y/n):y Initializing journal - 0%20%40%60%80%100% Syncing..ok [...] ReiserFS is successfully created on /dev/mapper/crypt-punchbag. [non]# mkdir /mnt/punchbag [non]# mount /dev/mapper/crypt-punchbag /mnt/punchbag -o noatime,barrier=flush [non]# cp -r ~marti/mp3 /mnt/punchbag [... yes, these are legal mp3s ;)] cp: writing `/mnt/punchbag/mp3/...': No space left on device ^C [non]# sync [non]# echo 3 /proc/sys/vm/drop_caches [non]# cd /mnt/punchbag/mp3/mr\ Epic\ -\ Sideways [non]# sha1sum -c *.sha1 mr Epic - Sideways - 01. Down Low.flac: OK mr Epic - Sideways - 02. Blue Days.flac: OK mr Epic - Sideways - 03.
Re: 2.6.21-rc3-mm1 RSDL results
Con == Con Kolivas [EMAIL PROTECTED] writes: Con It's sad that sched_yield is still in our graphics card drivers ... I just did a recursive grep(1) on my mirror of the freedesktop git repos for sched_yield. This only checked the master branches as I did not bother to script up something to clone each, check out all branches in turn, and grep(1) each possibility. The output is just: :; grep -r sched_yield FDO/xorg FDO/xorg/xserver/hw/kdrive/via/viadraw.c: sched_yield(); FDO/xorg/driver/xf86-video-glint/src/pm2_video.c:if (sync) /* sched_yield? */ Is there something else I should grep(1) for? If not, it looks as if sched_yield(2) has been evicted from the drivers. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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/9] signalfd/timerfd v1 - signalfd core ...
On Sat, 10 Mar 2007, Oleg Nesterov wrote:
Davide Libenzi wrote:
+int signalfd_deliver(struct sighand_struct *sighand, int sig,
+struct siginfo *info)
+{
+ int nsig = 0;
+ struct list_head *pos;
+ struct signalfd_ctx *ctx;
+
+ list_for_each(pos, sighand-sfdlist) {
+ ctx = list_entry(pos, struct signalfd_ctx, lnk);
list_for_each_entry()
Will do, thx!
+ /*
+* We use a negative signal value as a way to broadcast that the
+* sighand has been orphaned, so that we can notify all the
+* listeners about this. Remeber the ctx-sigmask is inverted,
+* so if the user is interested in a signal, that corresponding
+* bit will be zero.
+*/
+ if (sig 0 || !sigismember(ctx-sigmask, sig)) {
+ __wake_up_locked(ctx-wqh,
+TASK_UNINTERRUPTIBLE |
TASK_INTERRUPTIBLE);
wake_up_locked(ctx-wqh)
Yeah, will do.
+ ctx-sighand = current-sighand;
+ atomic_inc(ctx-sighand-count);
I personally don't like this. de_thread() was/is the source of numerous
problems, and this patch adds yet another subtle dependency. The usage of
private __cleanup_sighand() is not good per se, imho.
This we agree ...
Also, this is not so flexible, we can't take S_ISUID into account. It seems
logical to preserve ctx after a normal exec.
This, not really. I'm not sure we want to leak this out of an exec.
+ spin_lock_irq(ctx-sighand-siglock);
+ ctx-sigmask = sigmask;
+ spin_unlock_irq(ctx-sighand-siglock);
+ wake_up(ctx-wqh);
Race with signalfd_read()-__add_wait_queue().
Ack.
+ if (sighand != ctx-tsk-sighand || ctx-tsk-signal == NULL ||
We don't need ctx-tsk-signal == NULL. tsk-signal == NULL (when checked
under -siglock) implies tsk-sighand == NULL. This is covered by the first
sighand != ctx-tsk-sighand check.
Extra check, due to rely less on the exit_signal code.
+ __remove_wait_queue(ctx-wqh, wait);
+ set_current_state(TASK_RUNNING);
We don't need mb() here.
Ack.
+void signal_fill_info(struct siginfo *dinfo, int sig, struct siginfo
*sinfo)
+{
+ switch ((unsigned long) sinfo) {
+ case (unsigned long) SEND_SIG_NOINFO:
+ dinfo-si_signo = sig;
+ dinfo-si_errno = 0;
+ dinfo-si_code = SI_USER;
+ dinfo-si_pid = current-pid;
+ dinfo-si_uid = current-uid;
+ break;
+ case (unsigned long) SEND_SIG_PRIV:
+ dinfo-si_signo = sig;
+ dinfo-si_errno = 0;
+ dinfo-si_code = SI_KERNEL;
+ dinfo-si_pid = 0;
+ dinfo-si_uid = 0;
+ break;
+ default:
+ copy_siginfo(dinfo, sinfo);
+ }
+}
This change seems unneeded?
Yes, it leaked out from the version of signalfd that had its own queue.
I'd suggest to remove signalfd_ctx-sighand. de_thread()/exit_signal() call
signalfd_exit_task(struct sighand_struct *sighand)
{
list_for_each_entry_safe(ctx, sighand-sfdlist)
if (ctx-tsk == current) {
wake_up_locked(ctx-wqh);
list_del_init(ctx-lnk);
}
}
signalfd_read()/signalfd_poll use
static struct sighand_struct *ctx_try_to_lock(struct signalfd_ctx *ctx,
flags)
{
struct sighand_struct *ret;
rcu_read_lock();
ret = lock_task_sighand(ctx-task);
rcu_read_unlock();
if (ret list_empty(ctx-lnk)) {
unlock_task_sighand(ctx-task);
ret = NULL;
}
return ret;
}
instead of spin_lock_irq(ctx-sighand) + if (ctx-sighand !=
ctx-tsk-sighand).
Possible?
Note that signalfd_exit_task() is generic, could be used in another context,
de_thread() can avoid the call if !suid.
I think it looks good to me. Will give it a spin today.
How about CONFIG_SIGNALFD, btw?
Yes, I was already planning it.
Davide, could you please cc me? I am not subscribed to lkml, noticed the new
version by accident.
Will do, thx!
- Davide
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: irda rmmod lockdep trace.
Hi Dave,
On Thu, Mar 08, 2007 at 05:54:36PM -0500, Dave Jones wrote:
modprobe irda ; rmmod irda in 2.6.21rc3 gets me the spew below..
Well it seems that we call __irias_delete_object() from hashbin_delete(). Then
__irias_delete_object() calls itself hashbin_delete() again. We're trying to
get the lock recursively.
I'll try to fix that soon, thanks for the report.
Cheers,
Samuel.
Dave
NET: Registered protocol family 23
NET: Unregistered protocol family 23
=
[ INFO: possible recursive locking detected ]
2.6.20-1.2966.fc7 #1
-
rmmod/16712 is trying to acquire lock:
(hashbin-hb_spinlock){}, at: [884bf476]
hashbin_delete+0x29/0x94 [irda]
but task is already holding lock:
(hashbin-hb_spinlock){}, at: [884bf476]
hashbin_delete+0x29/0x94 [irda]
other info that might help us debug this:
1 lock held by rmmod/16712:
#0: (hashbin-hb_spinlock){}, at: [884bf476]
hashbin_delete+0x29/0x94 [irda]
stack backtrace:
Call Trace:
[802a303b] __lock_acquire+0x151/0xbc4
[884c1517] :irda:__irias_delete_attrib+0x0/0x31
[802a3ea4] lock_acquire+0x4c/0x65
[884bf476] :irda:hashbin_delete+0x29/0x94
[80264011] _spin_lock_irqsave+0x2c/0x3c
[884bf476] :irda:hashbin_delete+0x29/0x94
[884c1918] :irda:__irias_delete_object+0x0/0x39
[884c193d] :irda:__irias_delete_object+0x25/0x39
[884bf48d] :irda:hashbin_delete+0x40/0x94
[884c5e3a] :irda:iriap_cleanup+0x36/0x38
[884c5fd6] :irda:irda_cleanup+0x29/0x3a
[802aa1e1] sys_delete_module+0x199/0x1ca
[8026ce36] syscall_trace_enter+0x9a/0x9f
[8025c2b5] tracesys+0xdc/0xe1
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix sparc TIF_USEDFPU flag atomicity
* William Lee Irwin III ([EMAIL PROTECTED]) wrote: On Sat, 10 Mar 2007 00:26:46 -0800, William Lee Irwin III [EMAIL PROTECTED] wrote: Oh dear. Could we bit a bit more idiomatic here? For instance, something like: On Sat, Mar 10, 2007 at 12:29:44AM -0800, David Miller wrote: Ok I pulled the sparc32 patch back out until there is some consensus here :) It's just a minor touch-up. If Mathieu is okay with it, I'd rather leave him as the author and just send along an Acked-by: with it. I'm not terribly attached to it, either. I just choked on my soda when I saw set_ti_thread_flag(task_thread_info(fpt), TI_USEDFPU) etc. go by. (Which reminds me, I really need to figure out how to consolidate the UP and SMP cases for all this.) -- wli Hello, William's implementation is indeed neater than mine. So the consensus goes to his patch as far as I'm concerned. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] dvb-core: Fix several locking related problems.
Em Sáb, 2007-03-10 às 02:49 +0100, Johannes Stezenbach escreveu: On Sun, Mar 04, 2007 at 05:45:54PM +, Simon Arlott wrote: Fix several instances of dvb-core functions using mutex_lock_interruptible and returning -ERESTARTSYS where the calling function will either never retry or never check the return value. These cause a race condition with dvb_dmxdev_filter_free and dvb_dvr_release, both of which are filesystem release functions whose return value is ignored and will never be retried. When this happens it becomes impossible to open dvr0 again (-EBUSY) since it has not been released properly. Signed-off-by: Simon Arlott [EMAIL PROTECTED] Acked-By: Johannes Stezenbach [EMAIL PROTECTED] I can't test this but to me it looks good. Mauro, could you please pick it up and keep it in the linuxtv.org repository for a while for testing? Done. Thanks, Johannes. -- Cheers, Mauro - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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: Make nenuconfig does not save parameters.
[Jan Engelhardt - Sat, Mar 10, 2007 at 05:50:56PM +0100] | On Mar 10 2007 19:46, Vladimir wrote: | On Mar 10 2007 19:06, Cyrill Gorcunov wrote: | [Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300] | | Here's the problem: | | 1. Unpack the kernel sources, run make menuconfig. | | 2. Mark the necessary options. | | 3. Pick Save an alternate configuration file, enter a filename (e.g. /root/kernelcfg) | | 4. Pick Exit. | | -5. Configurator exits without saving. If type make bzImage, it builtd all the default | options. | | Well, you already saved explicitly and did not make any further | changes after that, so it won't ask again on exit (perhaps all Office | Suites do the same). In fact, if you do exactly that, menuconfig | assumes you do not intend to build a kernel (since you did not save | to .config). | | Hm Do i have to Save an alternate configuration file to .config | manually? The configurator used to do that automatically when i pick | Exit. I think that was reasonable. Anyway, the patch Cyrill sent me | works all right. | | If you make some changes and do not call 'save an alternate config | file', it will ask you on exit. | | If you make no changes at all, a .config won't get written - true. But | then, the defconfig will be used anyway. | | All is fine. | | | Jan Jan lets see to the following scenario: 1) I've taken a pure Linux kernel (no .config at all) 2) I started menuconfig, made a few changes and saved the file to .config1 as alternate 3) Then I made some additional changes 4) Then I'm getting out of menuconfig and of course Save configuration..? question is raising. Ok, I'm selecting Yes and as result new configuration will be written to the .config file. All works as it should be... ...but as you mentoined in your message perhaps all Office Suites do the same - no, Office do not the same. The only question I have (and it could resolve all our problems) - what an alternate config file is: - just a snapshot of a config tree at moment of its writting - _working_ file to which configurator should write parameters your comments? P.S. Excuse for poor eng. grammar Cyrill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RSDL v0.28 for 2.6.20
Con Kolivas wrote: Here is an update for RSDL to version 0.28 Full patch: http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched-rsdl-0.28.patch Series: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/ The patch to get you from 0.26 to 0.28: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26-0.28.patch A similar patch and directories will be made for 2.6.21-rc3 without further announcement doesn't apply against 2.6.20.2: patch -p1 ~/2.6.20-sched-rsdl-0.28.patch --dry-run patching file include/linux/list.h patching file fs/proc/array.c patching file fs/pipe.c patching file include/linux/sched.h patching file include/asm-generic/bitops/sched.h patching file include/asm-s390/bitops.h patching file kernel/sched.c Hunk #41 FAILED at 3531. 1 out of 62 hunks FAILED -- saving rejects to file kernel/sched.c.rej patching file include/linux/init_task.h patching file Documentation/sched-design.txt Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RSDL v0.28 for 2.6.20 - backport to 2.6.18.8
Hi all, Here is an update for RSDL to version 0.28 Full patch: http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched- rsdl-0.28.patch Series: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/ The patch to get you from 0.26 to 0.28: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched- rsdl-0.26-0.28.patch A similar patch and directories will be made for 2.6.21-rc3 without further announcement First of all, thanx Con for this nice piece of code. I've been trying in the last few days to backport this new scheduler to a 2.6.18 kernel. After a lot of efforts I have finally been able to compile and run a RSDL patched 2.6.18.8 kernel on a x86_64 arch and actually my test PC booted 2-3 seconds faster with it compared to a vanilla 2.6.18.8 kernel. This patch includes a few other patches from 2.6.19+ kernel: PATCH 1: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=co mmit;h=ece8a684c75df215320b4155944979e3f78c5c93 PATCH 2: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=co mmit;h=08c183f31bdbb709f177f6d3110d5f288ea33933 PATCH 3: The patch to get you from 0.26 to 0.28: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26- 0.28.patch There might also be other small pieces of code comming from a 2.6.19+ kernel. Due to the project I'm currently working on, this will, in the next few weeks, help me out comparing heavy loads on a Debian Sarge/Etch 32/64 platform. Suggestions on benchmark tools would greatly be appreciated. Duno if this will be helpfull for anybody but I tought it would be nice to give it back to the lkml community. - vin sched-rsdl-0.26-backport-kernel-2.6.18.patch.gz Description: sched-rsdl-0.26-backport-kernel-2.6.18.patch.gz
Re: 2.6.21-rc3-mm1 RSDL results
Con Kolivas wrote: On Saturday 10 March 2007 05:07, Mark Lord wrote: Mmm.. when it's good, it's *really* good. My desktop feels snappier and all of that. .. But when it's bad, it stinks. Like when a make -j2 kernel rebuild is happening in a background window And that's bad. When you say it stinks is it more than 3 times slower? It should be precisely 3 times slower under that load (although low cpu using things like audio wont be affected by running 3 times slower). If it feels like much more than that much slower, there is a bug there somewhere. Scrolling windows is incredibly jerkey, and very very sluggish when images are involved (eg. a large web page in firefox). As another reader suggested, how does it run with the compile 'niced'? How does it perform with make (without a -j number). Yes, it behaves itself when the make -j2 is nice'd. This is on a Pentium-M 760 single-core, w/2GB SDRAM (notebook). What HZ are you running? Are you running a Beryl desktop? HZ==1000, NO_HZ, Kubunutu Dapper Drake distro, ATI X300 open-source X.org driver. Cheers - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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: Make nenuconfig does not save parameters.
On Mar 10 2007 20:50, Cyrill Gorcunov wrote: lets see to the following scenario: 1) I've taken a pure Linux kernel (no .config at all) 2) I started menuconfig, made a few changes and saved the file to .config1 as alternate 3) Then I made some additional changes 4) Then I'm getting out of menuconfig and of course Save configuration..? question is raising. Ok, I'm selecting Yes and as result new configuration will be written to the .config file. All works as it should be... ...but as you mentoined in your message perhaps all Office Suites do the same - no, Office do not the same. 1) I start a new document 2) add some text, save as it to config1.txt 3) make more text 4) choose File,Exit - prompts me to save (perhaps not to .config, but instead config1.txt, but at least, it prompts me, and gives me the choice to go back into menuconfig and save it under a different name). So what I just wanted to make clear is that you don't lose any changes without explicitly saying Don't Save. The only question I have (and it could resolve all our problems) - what an alternate config file is: - just a snapshot of a config tree at moment of its writting - _working_ file to which configurator should write parameters your comments? Whether the 'working config file path' should change when you do 'Save as Alternate' or not, is a menuconfig axiom. Ask Sam Ravnborg if you want it changed :-) [ I see where you are going. I am not biased to either because I usually only use it to save to .config. ] Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Make nenuconfig does not save parameters.
[Jan Engelhardt - Sat, Mar 10, 2007 at 07:23:41PM +0100] | | On Mar 10 2007 20:50, Cyrill Gorcunov wrote: | | lets see to the following scenario: | | 1) I've taken a pure Linux kernel (no .config at all) | 2) I started menuconfig, made a few changes and saved the file | to .config1 as alternate | 3) Then I made some additional changes | 4) Then I'm getting out of menuconfig and of course Save | configuration..? question is raising. Ok, I'm selecting | Yes and as result new configuration will be written to the .config | file. All works as it should be... | | ...but as you mentoined in your message perhaps all Office Suites do | the same - no, Office do not the same. | | | 1) I start a new document | 2) add some text, save as it to config1.txt | 3) make more text | 4) choose File,Exit - prompts me to save | | (perhaps not to .config, but instead config1.txt, but at least, it prompts and there you hit the problem to the eye - when you're working with text document you always know in *which* file you're now. So if you've saved alternate config - _keep his name in mind_ - that's what menuconfig tell us... | me, and gives me the choice to go back into menuconfig and save it under a | different name). So what I just wanted to make clear is that you don't | lose any changes without explicitly saying Don't Save. | | The only question I have (and it could resolve all our problems) - what an | alternate config file is: | | - just a snapshot of a config tree at moment of its writting | - _working_ file to which configurator should write parameters | | your comments? | | Whether the 'working config file path' should change when you do | 'Save as Alternate' or not, is a menuconfig axiom. Ask Sam Ravnborg | if you want it changed :-) | | [ I see where you are going. I am not biased to either because I usually | only use it to save to .config. ] | | | | Jan | -- | Actually, I always work with only .config file too... and the reason I wrote you is Vladimir's mail... so either menuconfig does not work as expected or users does not expect a such behaviour of menuconfig. Cyrill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] proc: maps protection
On Fri, Mar 09, 2007 at 09:01:41PM -0800, Arjan van de Ven wrote:
I just don't know what it will break - we're changing things so that user A
cannot monitor user B's memory maps. I feel that it's sure to break
various people's fancy custom system activity monitoring/logging setups,
and the sort of users who will be affected are, alas, the sort of people
who won't run a kernel with this change in it for another couple of years
yet.
except if they run RHEL or FC kernels, in which case they already have
that change
Right, this is a gentler version of just slapping 0400 perms on the
maps files, which already has the same effect. I think tightening this
bit of security is worth some possible breakage.
Do we actually need to disable the whole interface? If all you're
concerned about is the pathname then perhaps the knob could cause that
pathname to be replaced with hidden. That'll cause things to
break less seriously and still allows somewhat useful info to be gathered.
the problem part is that you can see EXACLTY where glibc is loaded in
memory, which effectively defeats address space randomization for
local users
Right; and since the maps are loaded in a specific order, just dropping
the filename isn't going to help in protecting the ASLR. e.g. I can get
apache's library list from its ELF, and it's very easy to line that up
with the maps file even if the filenames are missing.
Here's another revision, with both the can ptrace and the global /proc
knob; and I'll beg for defaulting the knob to on. :)
Signed-off-by: Kees Cook [EMAIL PROTECTED]
---
fs/proc/base.c |3 +++
fs/proc/internal.h |2 ++
fs/proc/task_mmu.c | 16 +++-
fs/proc/task_nommu.c |6 ++
include/linux/sysctl.h |1 +
kernel/sysctl.c|9 +
6 files changed, 36 insertions(+), 1 deletion(-)
---
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 1a979ea..9b6e731 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -123,6 +123,9 @@ struct pid_entry {
NULL, proc_info_file_operations, \
{ .proc_read = proc_##OTYPE } )
+int maps_protect = 1;
+EXPORT_SYMBOL(maps_protect);
+
static struct fs_struct *get_fs_struct(struct task_struct *task)
{
struct fs_struct *fs;
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 987c773..596d925 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -31,6 +31,8 @@ do { \
extern int nommu_vma_show(struct seq_file *, struct vm_area_struct *);
#endif
+extern int maps_protect;
+
extern void create_seq_entry(char *name, mode_t mode, const struct
file_operations *f);
extern int proc_exe_link(struct inode *, struct dentry **, struct vfsmount **);
extern int proc_tid_stat(struct task_struct *, char *);
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 55ade0d..2e43c12 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -134,6 +134,9 @@ static int show_map_internal(struct seq_file *m, void *v,
struct mem_size_stats
dev_t dev = 0;
int len;
+ if (maps_protect !ptrace_may_attach(task))
+ return -EACCES;
+
if (file) {
struct inode *inode = vma-vm_file-f_path.dentry-d_inode;
dev = inode-i_sb-s_dev;
@@ -444,11 +447,22 @@ struct file_operations proc_maps_operations = {
#ifdef CONFIG_NUMA
extern int show_numa_map(struct seq_file *m, void *v);
+static int show_numa_map_checked(struct seq_file *m, void *v)
+{
+ struct proc_maps_private *priv = m-private;
+ struct task_struct *task = priv-task;
+
+ if (maps_protect !ptrace_may_attach(task))
+ return -EACCES;
+
+ return show_numa_map(m, v);
+}
+
static struct seq_operations proc_pid_numa_maps_op = {
.start = m_start,
.next = m_next,
.stop = m_stop,
-.show = show_numa_map
+.show = show_numa_map_checked
};
static int numa_maps_open(struct inode *inode, struct file *file)
diff --git a/fs/proc/task_nommu.c b/fs/proc/task_nommu.c
index fcc5caf..fb36c6a 100644
--- a/fs/proc/task_nommu.c
+++ b/fs/proc/task_nommu.c
@@ -143,6 +143,12 @@ out:
static int show_map(struct seq_file *m, void *_vml)
{
struct vm_list_struct *vml = _vml;
+ struct proc_maps_private *priv = m-private;
+ struct task_struct *task = priv-task;
+
+ if (maps_protect !ptrace_may_attach(task))
+ return -EACCES;
+
return nommu_vma_show(m, vml-vma);
}
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 81480e6..743d63d 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -160,6 +160,7 @@ enum
KERN_MAX_LOCK_DEPTH=74,
KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered */
+ KERN_MAPS_PROTECT=77, /* int: whether we protect
Re: PROBLEM: Make nenuconfig does not save parameters.
On Mar 10 2007 21:50, Cyrill Gorcunov wrote: Actually, I always work with only .config file too... and the reason I wrote you is Vladimir's mail... so either menuconfig does not work as expected or users does not expect a such behaviour of menuconfig. The latter. Though this behavior has been there since... I think since menuconfig came into existence. It goes way back to 2.4 and 2.2. Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[SOUND] hda_intel: build fix
CC [M] sound/pci/hda/hda_intel.o
sound/pci/hda/hda_intel.c:1508: error: position_fix_list causes a section type
conflict
Gcc like its __devinitdata readable not const, it seems. An alternative
fix would be to remove the __devinitdata attribute but that would result
in slight runtime bloat.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index b9a8e23..63b6854 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1505,7 +1505,7 @@ static int azx_dev_free(struct snd_device *device)
/*
* white/black-listing for position_fix
*/
-static const struct snd_pci_quirk position_fix_list[] __devinitdata = {
+static struct snd_pci_quirk position_fix_list[] __devinitdata = {
SND_PCI_QUIRK(0x1028, 0x01cc, Dell D820, POS_FIX_NONE),
{}
};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RSDL v0.28 for 2.6.20
On Sat, Mar 10, 2007 at 01:09:35PM -0500, Stephen Clark wrote: Con Kolivas wrote: Here is an update for RSDL to version 0.28 Full patch: http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched-rsdl-0.28.patch Series: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/ The patch to get you from 0.26 to 0.28: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26-0.28.patch A similar patch and directories will be made for 2.6.21-rc3 without further announcement doesn't apply against 2.6.20.2: patch -p1 ~/2.6.20-sched-rsdl-0.28.patch --dry-run patching file include/linux/list.h patching file fs/proc/array.c patching file fs/pipe.c patching file include/linux/sched.h patching file include/asm-generic/bitops/sched.h patching file include/asm-s390/bitops.h patching file kernel/sched.c Hunk #41 FAILED at 3531. 1 out of 62 hunks FAILED -- saving rejects to file kernel/sched.c.rej patching file include/linux/init_task.h patching file Documentation/sched-design.txt It is easier to apply 2.6.20.2 on top of 2.6.20+RSDL. The .2 patch is a one-liner that you can easily fix by hand, and I'm not even certain that it is still required : --- ./kernel/sched.c.orig 2007-03-10 13:03:51 +0100 +++ ./kernel/sched.c2007-03-10 13:08:02 +0100 @@ -3544,7 +3544,7 @@ next = list_entry(queue-next, struct task_struct, run_list); } - if (dependent_sleeper(cpu, rq, next)) + if (rq-nr_running == 1 dependent_sleeper(cpu, rq, next)) next = rq-idle; switch_tasks: if (next == rq-idle) BTW, Con, I think that you should base your work on 2.6.20.[23] and not 2.6.20 next time, due to this conflict. It will get wider adoption. Regards, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bitbanging i2c bus driver using the GPIO API
On Fri, 9 Mar 2007 11:30:12 -0800, David Brownell wrote: --- a/include/linux/i2c-id.h +++ b/include/linux/i2c-id.h @@ -194,6 +194,7 @@ #define I2C_HW_B_EM28XX0x01001f /* em28xx video capture cards */ #define I2C_HW_B_CX2341X 0x010020 /* Conexant CX2341X MPEG encoder cards */ #define I2C_HW_B_INTELFB 0x010021 /* intel framebuffer driver */ +#define I2C_HW_B_GPIO 0x010022 /* Generic GPIO-based driver */ It'd be nice to completely abolish those IDs, starting by not adding new ones. Especially, not adding unused ones! I'm confident that we'll be able to get rid of the I2C device driver IDs pretty soon thanks to your new i2c-core model, but I'm not sure if we'll be able to get rid of I2C adapter drivers IDs that quickly. But I agree with you, please let's not add new unused IDs. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: refcounting drivers' data structures used in sysfs buffers
On Fri, 9 Mar 2007, Oliver Neukum wrote: Am Freitag, 9. März 2007 21:08 schrieb Alan Stern: After some more thought, I basically agree with what Oliver wrote originally. sysfs_dirent is indeed the logical place to store the kref pointer. However it needs to be used during open and release, not during OK. read, write, and poll. Another point, which Oliver didn't think of, is that the kref pointer needs to be passed to the driver as an argument in the show() and store() method calls. Why? What's wrong with simply calling kref_get/put? It's the same old problem: the race between unbind and sysfs I/O. What good does holding a reference to the private data structure do if the show/store method gets called after the driver has been unbound from the device? dev_get_drvdata() will no longer provide a valid pointer to the private data, so the method will have no way to access it. Hence the method needs another argument. (BTW, the sysfs core would actually need more than a kref. It would also need a pointer to a release routine -- the kref contains only the atomic counter. The more you think about it, the more complicated this approach becomes.) Finally, there's added complexity in each driver which wants to use the new facility. The module_exit routine will need to be smart enough to block until all the private data structures have been released. usb-storage does something like that now; it's kind of ugly (although it could be improved if appropriate support were added to the core kernel). If we up the module count for every bound device, all device attributes should be gone before we ever get that far. Not quite right. However, since every open sysfs file holds a module reference, if the driver's module_exit has been called then there can be no open sysfs files, hence no private data still pinned. Thus this isn't a problem at all. But never mind all the above. I'm going to post another message on this thread in which I argue that Oliver's original approach was a good one and should not have been reverted. The specific problem identified by Hugh Dickins can be fixed in the way Dmitry first suggested, by doing the real operation from a workqueue routine. Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[SOUND] ice1712: build fixes
CC [M] sound/pci/ice1712/ice1712.o
sound/pci/ice1712/ice1712.c:290: error: snd_ice1712_mixer_digmix_route_ac97
causes a section type conflict
sound/pci/ice1712/ice1712.c:1630: error: snd_ice1712_eeprom causes a section
type conflict
sound/pci/ice1712/ice1712.c:1894: error: snd_ice1712_pro_internal_clock causes
a section type conflict
sound/pci/ice1712/ice1712.c:1965: error: snd_ice1712_pro_internal_clock_default
causes a section type conflict
sound/pci/ice1712/ice1712.c:2004: error: snd_ice1712_pro_rate_locking causes a
section type conflict
sound/pci/ice1712/ice1712.c:2043: error: snd_ice1712_pro_rate_reset causes a
section type conflict
sound/pci/ice1712/ice1712.c:2210: error: snd_ice1712_mixer_pro_analog_route
causes a section type conflict
sound/pci/ice1712/ice1712.c:2218: error: snd_ice1712_mixer_pro_spdif_route
causes a section type conflict
sound/pci/ice1712/ice1712.c:2260: error: snd_ice1712_mixer_pro_volume_rate
causes a section type conflict
sound/pci/ice1712/ice1712.c:2293: error: snd_ice1712_mixer_pro_peak causes a
section type conflict
sound/pci/ice1712/ice1712.c:1666: error: snd_ice1712_spdif_default causes a
section type conflict
sound/pci/ice1712/ice1712.c:1717: error: snd_ice1712_spdif_maskc causes a
section type conflict
sound/pci/ice1712/ice1712.c:1726: error: snd_ice1712_spdif_maskp causes a
section type conflict
sound/pci/ice1712/ice1712.c:1753: error: snd_ice1712_spdif_stream causes a
section type conflict
Gcc like its __devinitdata readable not const, it seems. An alternative
fix would be to remove the __devinitdata attribute but that would result
in slight runtime bloat.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
diff --git a/sound/pci/ice1712/delta.c b/sound/pci/ice1712/delta.c
index 3eeb36c..a48140b 100644
--- a/sound/pci/ice1712/delta.c
+++ b/sound/pci/ice1712/delta.c
@@ -735,7 +735,7 @@ static int __devinit snd_ice1712_delta_add_controls(struct
snd_ice1712 *ice)
/* entry point */
-const struct snd_ice1712_card_info snd_ice1712_delta_cards[] __devinitdata = {
+struct snd_ice1712_card_info snd_ice1712_delta_cards[] __devinitdata = {
{
.subvendor = ICE1712_SUBDEVICE_DELTA1010,
.name = M Audio Delta 1010,
diff --git a/sound/pci/ice1712/delta.h b/sound/pci/ice1712/delta.h
index e65d669..746ebde 100644
--- a/sound/pci/ice1712/delta.h
+++ b/sound/pci/ice1712/delta.h
@@ -46,7 +46,7 @@
#define ICE1712_SUBDEVICE_MEDIASTATION 0x694c0100
/* entry point */
-extern const struct snd_ice1712_card_info snd_ice1712_delta_cards[];
+extern struct snd_ice1712_card_info snd_ice1712_delta_cards[];
/*
diff --git a/sound/pci/ice1712/ews.c b/sound/pci/ice1712/ews.c
index 9b7ff30..467fd01 100644
--- a/sound/pci/ice1712/ews.c
+++ b/sound/pci/ice1712/ews.c
@@ -989,7 +989,7 @@ static int __devinit snd_ice1712_ews_add_controls(struct
snd_ice1712 *ice)
/* entry point */
-const struct snd_ice1712_card_info snd_ice1712_ews_cards[] __devinitdata = {
+struct snd_ice1712_card_info snd_ice1712_ews_cards[] __devinitdata = {
{
.subvendor = ICE1712_SUBDEVICE_EWX2496,
.name = TerraTec EWX24/96,
diff --git a/sound/pci/ice1712/ews.h b/sound/pci/ice1712/ews.h
index df449b4..a12a0b0 100644
--- a/sound/pci/ice1712/ews.h
+++ b/sound/pci/ice1712/ews.h
@@ -40,7 +40,7 @@
#define ICE1712_SUBDEVICE_PHASE88 0x3b155111
/* entry point */
-extern const struct snd_ice1712_card_info snd_ice1712_ews_cards[];
+extern struct snd_ice1712_card_info snd_ice1712_ews_cards[];
/* TerraTec EWX 24/96 configuration definitions */
diff --git a/sound/pci/ice1712/hoontech.c b/sound/pci/ice1712/hoontech.c
index df97313..8193450 100644
--- a/sound/pci/ice1712/hoontech.c
+++ b/sound/pci/ice1712/hoontech.c
@@ -298,7 +298,7 @@ static int __devinit snd_ice1712_ez8_init(struct
snd_ice1712 *ice)
/* entry point */
-const struct snd_ice1712_card_info snd_ice1712_hoontech_cards[] __devinitdata
= {
+struct snd_ice1712_card_info snd_ice1712_hoontech_cards[] __devinitdata = {
{
.subvendor = ICE1712_SUBDEVICE_STDSP24,
.name = Hoontech SoundTrack Audio DSP24,
diff --git a/sound/pci/ice1712/hoontech.h b/sound/pci/ice1712/hoontech.h
index b62d6e4..1ee538b 100644
--- a/sound/pci/ice1712/hoontech.h
+++ b/sound/pci/ice1712/hoontech.h
@@ -35,7 +35,7 @@
#define ICE1712_SUBDEVICE_STDSP24_MEDIA7_1 0x16141217 /* Hoontech ST
Audio DSP24 Media 7.1 */
#define ICE1712_SUBDEVICE_EVENT_EZ80x00010001 /* A dummy id
for EZ8 */
-extern const struct snd_ice1712_card_info snd_ice1712_hoontech_cards[];
+extern struct snd_ice1712_card_info snd_ice1712_hoontech_cards[];
/* Hoontech SoundTrack Audio DSP 24 GPIO definitions */
diff --git a/sound/pci/ice1712/ice1712.c b/sound/pci/ice1712/ice1712.c
index 830a1bb..23d1419 100644
--- a/sound/pci/ice1712/ice1712.c
+++ b/sound/pci/ice1712/ice1712.c
@@ -287,7 +287,7 @@ static int snd_ice1712_digmix_route_ac97_put(struct
Re: [SOUND] ice1712: build fixes
On Sat, Mar 10, 2007 at 07:26:41PM +, Ralf Baechle wrote: Whops, please ignore this one, I send the wrong file. Ralf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler)
William Lee Irwin III wrote: Last I checked there were limits to runtime configurability centering around only supporting a compiled-in set of scheduling drivers, unless Peter's taken it the rest of the way without my noticing. It's unclear what you have in mind in terms of dynamic extensibility. My only guess would be pluggable scheduling policy/class support for individual schedulers in addition to plugging the individual schedulers, except I'm rather certain that Williams' code doesn't do anything with modules. On Sat, Mar 10, 2007 at 07:47:11PM +0300, Al Boldi wrote: Correct, it doesn't, yet. But do you think that PlugSched has the basic infrastructure in place to support this, or would it require a complete redesign/rewrite. The piece I got done was just representing schedulers as driver-like affairs (which, embarrassingly enough, needed lots of bugfixing), and everyone's just been running with that and boot-time switching ever since. Runtime switching (to module-loaded schedulers or otherwise) needs a lot of hotplug-esque work. Scheduler class support, pluggable or otherwise, needs per-scheduler abstracting things out along the same lines as what was originally done for the overall schedulers surrounding enqueueing and dequeueing so the scheduler itself only plucks tasks out of and stuffs tasks into some sort of abstracted-out queue or set of queues, though I did try to break things down at a low enough level where they'd be plausible for more than just the one driver (never distributed) I used to test the design. I dumped the entire project long before ever getting to where modules entered the picture, and have never touched modules otherwise, so I'm not entirely sure what other issues would come up with those after the smoke clears from runtime switching. I don't plan on doing anything here myself, since the boot-time switching etc. is likely already considered offensive enough. The next time something comes up that bears a risk of positioning me against the kernel's political winds, I'll just rm it or not write it at all instead of leaving code around (or worse yet, passing it around) to be taken up by others. It just leaves a lot of embarrassed explaining to do when it resurfaces years later, or otherwise leaves a rather bad taste in my mouth when NIH'd years later like other things not mentioned here (VM code kept quiet similarly to plugsched) and everyone approves so long as it didn't come from me. -- wli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 nForce MCP61 support to i2c-nforce2
Hi Petr, On Sat, 10 Mar 2007 09:00:03 +0100, Petr Vandrovec wrote: Hello, patch below adds support for nVidia's SMBus adapter present on Gateway's GT5414E motherboard (ECS's MCP61 PM-AM). Patch is for current Linus's git tree. We already have a patch doing exactly this in -mm: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/broken-out/jdelvare-i2c-i2c-nforce2-add-mcp61-mcp65-support.patch 00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2) Subsystem: Elitegroup Computer Systems Unknown device 2601 Flags: 66MHz, fast devsel, IRQ 10 I/O ports at fc00 [size=64] I/O ports at 1c00 [size=64] I/O ports at f400 [size=64] Capabilities: [44] Power Management version 2 BTW, note how the MCP61 has not 2 but 3 64-byte I/O areas declared. The previous chips used BAR 4 and 5, this new one additionally uses BAR 0. Without documentation it's hard to be sure this is a 3rd SMBus channel, but it sure looks so. Maybe you'll want to hack the i2c-nforce2 driver a bit to confirm or infirm this theory. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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: Make nenuconfig does not save parameters.
[Jan Engelhardt - Sat, Mar 10, 2007 at 08:04:38PM +0100] | | On Mar 10 2007 21:50, Cyrill Gorcunov wrote: | | Actually, I always work with only .config file too... and the reason I | wrote you is Vladimir's mail... so either menuconfig does not work as | expected or users does not expect a such behaviour of menuconfig. | | The latter. Though this behavior has been there since... I think since | menuconfig came into existence. It goes way back to 2.4 and 2.2. | | | Jan | -- | Thanks for mail. The topic is closed :) Cyrill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[SOUND] ice1712: build fixes
CC [M] sound/pci/ice1712/ice1712.o
sound/pci/ice1712/ice1712.c:290: error: snd_ice1712_mixer_digmix_route_ac97
causes a section type conflict
sound/pci/ice1712/ice1712.c:1630: error: snd_ice1712_eeprom causes a section
type conflict
sound/pci/ice1712/ice1712.c:1894: error: snd_ice1712_pro_internal_clock causes
a section type conflict
sound/pci/ice1712/ice1712.c:1965: error: snd_ice1712_pro_internal_clock_default
causes a section type conflict
sound/pci/ice1712/ice1712.c:2004: error: snd_ice1712_pro_rate_locking causes a
section type conflict
sound/pci/ice1712/ice1712.c:2043: error: snd_ice1712_pro_rate_reset causes a
section type conflict
sound/pci/ice1712/ice1712.c:2210: error: snd_ice1712_mixer_pro_analog_route
causes a section type conflict
sound/pci/ice1712/ice1712.c:2218: error: snd_ice1712_mixer_pro_spdif_route
causes a section type conflict
sound/pci/ice1712/ice1712.c:2260: error: snd_ice1712_mixer_pro_volume_rate
causes a section type conflict
sound/pci/ice1712/ice1712.c:2293: error: snd_ice1712_mixer_pro_peak causes a
section type conflict
sound/pci/ice1712/ice1712.c:1666: error: snd_ice1712_spdif_default causes a
section type conflict
sound/pci/ice1712/ice1712.c:1717: error: snd_ice1712_spdif_maskc causes a
section type conflict
sound/pci/ice1712/ice1712.c:1726: error: snd_ice1712_spdif_maskp causes a
section type conflict
sound/pci/ice1712/ice1712.c:1753: error: snd_ice1712_spdif_stream causes a
section type conflict
Gcc like its __devinitdata readable not const, it seems. An alternative
fix would be to remove the __devinitdata attribute but that would result
in slight runtime bloat.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
---
Take 2, the complete version of the patch.
diff --git a/sound/pci/ice1712/delta.c b/sound/pci/ice1712/delta.c
index 3eeb36c..af65980 100644
--- a/sound/pci/ice1712/delta.c
+++ b/sound/pci/ice1712/delta.c
@@ -416,7 +416,7 @@ static int
snd_ice1712_delta1010lt_wordclock_status_get(struct snd_kcontrol *kco
return 0;
}
-static const struct snd_kcontrol_new snd_ice1712_delta1010lt_wordclock_status
__devinitdata =
+static struct snd_kcontrol_new snd_ice1712_delta1010lt_wordclock_status
__devinitdata =
{
.access = (SNDRV_CTL_ELEM_ACCESS_READ),
.iface =SNDRV_CTL_ELEM_IFACE_MIXER,
@@ -429,7 +429,7 @@ static const struct snd_kcontrol_new
snd_ice1712_delta1010lt_wordclock_status __
* initialize the chips on M-Audio cards
*/
-static const struct snd_akm4xxx akm_audiophile __devinitdata = {
+static struct snd_akm4xxx akm_audiophile __devinitdata = {
.type = SND_AK4528,
.num_adcs = 2,
.num_dacs = 2,
@@ -438,7 +438,7 @@ static const struct snd_akm4xxx akm_audiophile
__devinitdata = {
}
};
-static const struct snd_ak4xxx_private akm_audiophile_priv __devinitdata = {
+static struct snd_ak4xxx_private akm_audiophile_priv __devinitdata = {
.caddr = 2,
.cif = 0,
.data_mask = ICE1712_DELTA_AP_DOUT,
@@ -450,7 +450,7 @@ static const struct snd_ak4xxx_private akm_audiophile_priv
__devinitdata = {
.mask_flags = 0,
};
-static const struct snd_akm4xxx akm_delta410 __devinitdata = {
+static struct snd_akm4xxx akm_delta410 __devinitdata = {
.type = SND_AK4529,
.num_adcs = 2,
.num_dacs = 8,
@@ -459,7 +459,7 @@ static const struct snd_akm4xxx akm_delta410 __devinitdata
= {
}
};
-static const struct snd_ak4xxx_private akm_delta410_priv __devinitdata = {
+static struct snd_ak4xxx_private akm_delta410_priv __devinitdata = {
.caddr = 0,
.cif = 0,
.data_mask = ICE1712_DELTA_AP_DOUT,
@@ -471,7 +471,7 @@ static const struct snd_ak4xxx_private akm_delta410_priv
__devinitdata = {
.mask_flags = 0,
};
-static const struct snd_akm4xxx akm_delta1010lt __devinitdata = {
+static struct snd_akm4xxx akm_delta1010lt __devinitdata = {
.type = SND_AK4524,
.num_adcs = 8,
.num_dacs = 8,
@@ -481,7 +481,7 @@ static const struct snd_akm4xxx akm_delta1010lt
__devinitdata = {
}
};
-static const struct snd_ak4xxx_private akm_delta1010lt_priv __devinitdata = {
+static struct snd_ak4xxx_private akm_delta1010lt_priv __devinitdata = {
.caddr = 2,
.cif = 0, /* the default level of the CIF pin from AK4524 */
.data_mask = ICE1712_DELTA_1010LT_DOUT,
@@ -493,7 +493,7 @@ static const struct snd_ak4xxx_private akm_delta1010lt_priv
__devinitdata = {
.mask_flags = 0,
};
-static const struct snd_akm4xxx akm_delta44 __devinitdata = {
+static struct snd_akm4xxx akm_delta44 __devinitdata = {
.type = SND_AK4524,
.num_adcs = 4,
.num_dacs = 4,
@@ -503,7 +503,7 @@ static const struct snd_akm4xxx akm_delta44 __devinitdata =
{
}
};
-static const struct snd_ak4xxx_private akm_delta44_priv __devinitdata = {
+static struct snd_ak4xxx_private akm_delta44_priv __devinitdata = {
.caddr = 2,
.cif = 0, /* the default
Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...
On Fri, 2007-03-09 at 23:36 -0800, Davide Libenzi wrote: On Fri, 9 Mar 2007, Nicholas Miell wrote: On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote: On Fri, 9 Mar 2007, Nicholas Miell wrote: So extend the existing POSIX timer API to deliver expiry events via a fd. It'll be out of standard as timerfd is, w/out code savings. Look at the code and tell me what could be saved. Prolly the ten lines of the timer callback. Lines that you'll have to drop inside the current posix timer layer. Better leave standards alone, especially like in this case, when the savings are not there. OK, here's a more formal listing of my objections to the introduction of timerfd in this form: A) It is a new general-purpose ABI intended for wide-scale usage, and thus must be maintained forever. Yup B) It is less functional than the existing ABIs -- modulo their delivery via signals only limitation, which can be corrected (and has been already in other operating systems). Less functional? Please, do tell me ... Try reading the timer_create man page. In short, you're limited to a single clock, so you can't set timers based on wall-clock time (subject to NTP correction), monotomic time (not subject to NTP, will not ever go backwards or skip ticks), the high-res versions of the previous two clocks, per-thread or per-process CPU usage time, or any other clocks that may get introduced in the future. In addition, you've introduced an entirely new incompatible API that probably doesn't fit easily into existing software that already uses POSIX timers. C) Being an entirely new creation that completely ignores past work in this area, it has no hope of ever getting into POSIX. which means D) At some point in time, Linux is going to get the POSIX version (in whatever form it takes), making this new ABI useless dead weight (see point A). Adding parameters/fields to a standard is going to create even more confusion than a new *single* function. And the code to cross-link the timerfd and the current posix timers is going to end up in being more complex than the current one. Yes, but the standard explicitly allows you to do this. Furthermore, if you work within the existing framework, you can lobby for the inclusion of your API in the next version of POSIX. Simplicity of the code is only a virtue if you don't have to do the exact same thing again with a different interface later while keeping the maintenance burden of the existing proprietary (and, thus, unpopular) interface. -- Nicholas Miell [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 v2] Bitbanging i2c bus driver using the GPIO API
Hi Haavard,
On Sat, 10 Mar 2007 14:13:28 +0100, Haavard Skinnemoen wrote:
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.
To use, include something similar to the following in the
board-specific setup code:
#include linux/i2c-gpio.h
static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
};
static struct platform_device i2c_gpio_device = {
.name = i2c-gpio,
.id = 0,
.dev= {
.platform_data = i2c_gpio_data,
},
};
Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go.
I like the idea very much. Would this let us get rid of i2c-ixp2000?
i2c-ixp4xx? scx200_i2c? Other drivers?
drivers/i2c/busses/Kconfig|8 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-gpio.c | 211
+
include/linux/i2c-gpio.h | 30 ++
4 files changed, 250 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
This support is also available as a module. If so, the module
will be called i2c-elektor.
+config I2C_GPIO
+ tristate GPIO-based bitbanging i2c driver
+ depends on I2C GENERIC_GPIO
+ select I2C_ALGOBIT
+ help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
config I2C_HYDRA
tristate CHRP Apple Hydra Mac I/O I2C interface
depends on I2C PCI PPC_CHRP EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_ELEKTOR)+= i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o
obj-$(CONFIG_I2C_I801) += i2c-i801.o
obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..423db0a
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,211 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2006 Atmel Corporation
I'm told we're in year 2007 ;)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/i2c.h
+#include linux/i2c-algo-bit.h
+#include linux/i2c-gpio.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+
+#include asm/gpio.h
+
+/* Toggle SDA by changing the direction of the pin */
+static void i2c_gpio_setsda_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata-sda_pin);
+ else {
+ gpio_direction_output(pdata-sda_pin);
+ gpio_set_value(pdata-sda_pin, 0);
+ }
+}
+
+/*
+ * Toggle SDA by changing the output value of the pin. This is only
+ * valid for pins configured as open drain (i.e. setting the value
+ * high effectively turns off the output driver.)
+ */
+static void i2c_gpio_setsda_val(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ gpio_set_value(pdata-sda_pin, state);
+}
+
+/* Toggle SCL by changing the direction of the pin. */
+static void i2c_gpio_setscl_dir(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ if (state)
+ gpio_direction_input(pdata-scl_pin);
+ else {
+ gpio_direction_output(pdata-scl_pin);
+ gpio_set_value(pdata-scl_pin, 0);
+ }
+}
+
+/*
+ * Toggle SCL by changing the output value of the pin. This is used
+ * for pins that are configured as open drain and for output-only
+ * pins. The latter case will break the i2c protocol, but it will
+ * often work in practice.
+ */
+static void i2c_gpio_setscl_val(void *data, int state)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ gpio_set_value(pdata-scl_pin, state);
+}
+
+int i2c_gpio_getsda(void *data)
+{
+ struct i2c_gpio_platform_data *pdata = data;
+
+ return gpio_get_value(pdata-sda_pin);
+}
What value will you get if the SDA pin is open-drain
Re: [PATCH] Use more gcc extensions in the Linux headers
On Fri, 9 Mar 2007, Linus Torvalds wrote: On Fri, 9 Mar 2007, Christoph Hellwig wrote: Well, since Rusty's macro was hoddible *anyway*, I don't think I'd apply it as-is. Breaking icc for something that ugly and not-very-important simply makes no sense. There are better ways to do this. For one, you could (and should!) abstract these kinds of things out, rather than put them in another macro that really does something totally different. Then, the macro could have become #define ARRAY_SIZE (sizeof_expression + 0*error_if_not_array) /* Error if X is a pointer, 0 otherwise */ #define ERROR_IF_POINTER(x) \ sizeof(int[-__builtin_types_compatible_p(typeof(x), typeof(x[0]))]) /* Warning (div by zero) if x is a pointer, 0 otherwise */ #define WARN_IF_POINTER(x) \ (0/!__builtin_types_compatible_p(typeof(x), typeof(x[0]))) The gcc docs say __builtin_types_compatible_p returns 1 or 0, so the !! isn't necessary. And my gcc at least returns 0 for sizeof(int[0]). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...
On Sat, 10 Mar 2007, Nicholas Miell wrote: Try reading the timer_create man page. In short, you're limited to a single clock, so you can't set timers based on wall-clock time (subject to NTP correction), monotomic time (not subject to NTP, will not ever go backwards or skip ticks), the high-res versions of the previous two clocks, per-thread or per-process CPU usage time, or any other clocks that may get introduced in the future. One timer per fd yes. So? The real-time and monotonic selection can be added. If you look at the posix timers code, that's a bunch of code over the real meat of it, that is hrtimer.c. The timerfd interface goes straight to that, without adding yet another meaning to the sigevent structure, and yet another case inside the posix timers trigger functions. That will be as unstandard as timerfd is, and even more, since you cannot use that interface and hope to be portable in any case. On top of that, handing over files to the posix timers will creates problems with references kept around. The timerfd code is just a *really* thin layer (if you exclude the includes, the structure definitions and the fd setup code, there's basically *nothing*) over hrtimer.c and does not mess up with other kernel code in any way, and offers the same functionalities. I'd like to keep it that way. - Davide - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc suspend regression: sysfs deadlock
[For the start of this thread, see http://marc.theaimsgroup.com/?l=linux-kernelm=117320893726621w=2.] On Wed, 7 Mar 2007, Linus Torvalds wrote: So you just pointed to *another* data structure that apparently violates the you MUST use refcounting rule. What is it with you people? It's really simple. Data structures must be refcounted if you can reach them two different ways. If you don't use refcounting, then you'd better make sure that the data can be reached only one way (for example, by *not* exposing it for sysfs). It really *is* that simple. Read the CodingStyle rules. Linus's analysis is correct as far as it goes, but it misses some very important points. The _real_ problem here, which nobody has pointed out so far, is not device removal or driver unloading. It is driver unbinding -- with its consequent issue of access rights. When a driver is unbound from a device, when should the driver stop trying to access that device? The obvious answer is that it must stop before its release() method returns. Otherwise the device might get bound to another driver and we would have both drivers trying to talk to it at the same time. In other words, when a driver unbinds from a device, it loses its right to access that device. Same goes for any device-related data structures that weren't created by the driver itself. When you realize this, it becomes obvious that the driver faces a synchronization problem. All its entry points must be synchronized with release(), to avoid races. So there actually are two things a driver has to worry about: The lifetime of its private data structures (which can be solved using refcounts as Linus advocated); The race between release() and other activities (which cannot be solved by refcounts but needs a true synchronization technique, such as a mutex). No doubt some of this sounds familiar; the race between open() and disconnect() for char device drivers is one we have faced many times and not always solved perfectly. Also note that this is a fundamental problem, affecting many facilities in addition to sysfs. One way to solve these problems is to put all the responsibility on the driver. Make it refcount its data structures and use mutexes. This is not very attractive for several reasons: _Lots_ of drivers are affected. Pretty much any driver which registers a char device or a sysfs attribute file. _Lots_ of code would need to be changed, adding considerable bloat. Every show()/store() method would need to acquire a mutex, and many would need to be passed an additional argument, requiring a change in the sysfs API. (I can explain why in a follow-up email if anyone is interested.) Most importantly, doing all the refcounting and mutual exclusion correctly is quite hard. It's amazingly easy to make mistakes in these areas. The chances of getting it right while changing multiple functions in every single driver are infinitesimal. Another approach is to put all the responsibility on the core subsystems that handle driver registration. They should enforce rigidly two principles: No driver callbacks occur after unregistration and its prerequisite, Unregistration is mutually exclusive with driver callbacks. (This is exactly what Oliver's original patch did for sysfs.) The number of core subsystems affected is much smaller than the total number of drivers. Sysfs, debugfs, the char device subsystem, maybe a few others. Drivers would no longer have to worry about doing their own synchronization or refcounts. It would be guaranteed that a private data structure would never be accessed from sysfs after device_remove_file() returned, so the structure could safely and easily be deallocated as part of release(). At the expense of complicating a few central subsystems, we could simplify a lot of drivers. I think this is a worthwhile tradeoff. It does have a small disadvantage; it means that an entry point would deadlock if it tried to unregister itself. (The example which started this whole thread was sdev_store_delete() in the SCSI core. Writing to that attribute unregisters the device to which it belongs.) Clearly the actual unregistration would have to performed separately in a workqueue. I think the number of places where this occurs is pretty small. It's true that this approach goes against the general philosophy used elsewhere in the kernel. Refcounting without synchronization is the general rule. However unbinding is a special case. Normally with refcounting, it doesn't matter when a driver tries to read or write a data structure. So long as the driver still holds a reference, the data will be there and the access will be okay. But not with unbinding! After unbinding, the data will still be there but it might be owned by
Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...
On Sat, 2007-03-10 at 12:41 -0800, Davide Libenzi wrote: On Sat, 10 Mar 2007, Nicholas Miell wrote: Try reading the timer_create man page. In short, you're limited to a single clock, so you can't set timers based on wall-clock time (subject to NTP correction), monotomic time (not subject to NTP, will not ever go backwards or skip ticks), the high-res versions of the previous two clocks, per-thread or per-process CPU usage time, or any other clocks that may get introduced in the future. One timer per fd yes. So? I never complained about one timer per fd (although, now that you mention it, that would get a bit excessive if you have thousands of outstanding timers). The real-time and monotonic selection can be added. IOW, the timerfd patch is not suitable for inclusion as-is. (While you're at it, you should probably add a flags argument for future expansion.) If you look at the posix timers code, that's a bunch of code over the real meat of it, that is hrtimer.c. The timerfd interface goes straight to that, without adding yet another meaning to the sigevent structure, That's what the sigevent structure is for -- to describe how events should be signaled to userspace, whether by signal delivery, thread creation, or queuing to event completion ports. If if you think extending it would be bad, I can show you the line in POSIX where it encourages the contrary. and yet another case inside the posix timers trigger functions. That will be as unstandard as timerfd is, and even more, since you cannot use that interface and hope to be portable in any case. If Linux were to do a wholesale theft of the Solaris interface (warts and all), you'd be portable (and, now that I think of it, more efficient). Two major unixes using the same interface would probably make it a shoe-in for the next POSIX, too. (c.f. openat(2) and friends) On top of that, handing over files to the posix timers will creates problems with references kept around. The timerfd code is just a *really* thin layer (if you exclude the includes, the structure definitions and the fd setup code, there's basically *nothing*) over hrtimer.c and does not mess up with other kernel code in any way, and offers the same functionalities. I'd like to keep it that way. -- Nicholas Miell [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: Remove unused header file.
Delete the apparently unused header file arch/arm/mach-s3c2410/bast.h. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- diff --git a/arch/arm/mach-s3c2410/bast.h b/arch/arm/mach-s3c2410/bast.h deleted file mode 100644 index e985437..000 --- a/arch/arm/mach-s3c2410/bast.h +++ /dev/null @@ -1,2 +0,0 @@ -/* linux/arch/arm/mach-s3c2410/bast.h -extern void bast_init_irq(void); -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] M68K: Delete unused header file.
Delete the apparently unused header file arch/m68k/atari/atasound.h. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- diff --git a/arch/m68k/atari/atasound.h b/arch/m68k/atari/atasound.h deleted file mode 100644 index 1362762..000 --- a/arch/m68k/atari/atasound.h +++ /dev/null @@ -1,33 +0,0 @@ -/* - * Minor numbers for the sound driver. - * - * Unfortunately Creative called the codec chip of SB as a DSP. For this - * reason the /dev/dsp is reserved for digitized audio use. There is a - * device for true DSP processors but it will be called something else. - * In v3.0 it's /dev/sndproc but this could be a temporary solution. - */ - -#define SND_NDEVS 256 /* Number of supported devices */ -#define SND_DEV_CTL0 /* Control port /dev/mixer */ -#define SND_DEV_SEQ1 /* Sequencer output /dev/sequencer (FM - synthesizer and MIDI output) */ -#define SND_DEV_MIDIN 2 /* Raw midi access */ -#define SND_DEV_DSP3 /* Digitized voice /dev/dsp */ -#define SND_DEV_AUDIO 4 /* Sparc compatible /dev/audio */ -#define SND_DEV_DSP16 5 /* Like /dev/dsp but 16 bits/sample */ -#define SND_DEV_STATUS 6 /* /dev/sndstat */ -/* #7 not in use now. Was in 2.4. Free for use after v3.0. */ -#define SND_DEV_SEQ2 8 /* /dev/sequencer, level 2 interface */ -#define SND_DEV_SNDPROC 9 /* /dev/sndproc for programmable devices */ -#define SND_DEV_PSSSND_DEV_SNDPROC - -#define DSP_DEFAULT_SPEED 8000 - -#define ON 1 -#define OFF0 - -#define MAX_AUDIO_DEV 5 -#define MAX_MIXER_DEV 2 -#define MAX_SYNTH_DEV 3 -#define MAX_MIDI_DEV 6 -#define MAX_TIMER_DEV 3 -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PPC: Delete unused header file.
Delete apparently unused header file arch/powerpc/platforms/83xx/mpc834x_itx.h. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.h b/arch/powerpc/platforms/83xx/mpc834x_itx.h deleted file mode 100644 index 174ca4e..000 --- a/arch/powerpc/platforms/83xx/mpc834x_itx.h +++ /dev/null @@ -1,23 +0,0 @@ -/* - * arch/powerpc/platforms/83xx/mpc834x_itx.h - * - * MPC834X ITX common board definitions - * - * Maintainer: Kumar Gala [EMAIL PROTECTED] - * - * 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; either version 2 of the License, or (at your - * option) any later version. - * - */ - -#ifndef __MACH_MPC83XX_ITX_H__ -#define __MACH_MPC83XX_ITX_H__ - -#define PIRQA MPC83xx_IRQ_EXT4 -#define PIRQB MPC83xx_IRQ_EXT5 -#define PIRQC MPC83xx_IRQ_EXT6 -#define PIRQD MPC83xx_IRQ_EXT7 - -#endif /* __MACH_MPC83XX_ITX_H__ */ -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PPC: Delete unused header file.
Delete apparently unused header file arch/ppc/syslib/cpc710.h. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- diff --git a/arch/ppc/syslib/cpc710.h b/arch/ppc/syslib/cpc710.h deleted file mode 100644 index 5299bf8..000 --- a/arch/ppc/syslib/cpc710.h +++ /dev/null @@ -1,81 +0,0 @@ -/* - * Definitions for the IBM CPC710 PCI Host Bridge - * - * Author: Matt Porter [EMAIL PROTECTED] - * - * 2001 (c) MontaVista, Software, Inc. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed as is without any warranty of any kind, whether express - * or implied. - */ - -#ifndef __PPC_PLATFORMS_CPC710_H -#define __PPC_PLATFORMS_CPC710_H - -/* General bridge and memory controller registers */ -#define PIDR 0xff08 -#defineCNFR0xff0c -#defineRSTR0xff10 -#define UCTL 0xff001000 -#defineMPSR0xff001010 -#defineSIOC0xff001020 -#defineABCNTL 0xff001030 -#define SRST 0xff001040 -#defineERRC0xff001050 -#defineSESR0xff001060 -#defineSEAR0xff001070 -#defineSIOC1 0xff001090 -#definePGCHP 0xff001100 -#defineGPDIR 0xff001130 -#defineGPOUT 0xff001150 -#defineATAS0xff001160 -#defineAVDG0xff001170 -#defineMCCR0xff001200 -#defineMESR0xff001220 -#defineMEAR0xff001230 -#defineMCER0 0xff001300 -#defineMCER1 0xff001310 -#defineMCER2 0xff001320 -#defineMCER3 0xff001330 -#defineMCER4 0xff001340 -#defineMCER5 0xff001350 -#defineMCER6 0xff001360 -#defineMCER7 0xff001370 - -/* - * PCI32/64 configuration registers - * Given as offsets from their - * respective physical segment BAR - */ -#define PIBAR 0x000f7800 -#define PMBAR 0x000f7810 -#define MSIZE 0x000f7f40 -#define IOSIZE 0x000f7f60 -#define SMBAR 0x000f7f80 -#define SIBAR 0x000f7fc0 -#define PSSIZE 0x000f8100 -#define PPSIZE 0x000f8110 -#define BARPS 0x000f8120 -#define BARPP 0x000f8130 -#define PSBAR 0x000f8140 -#define PPBAR 0x000f8150 -#define BPMDLK 0x000f8200 /* Bottom of Peripheral Memory Space */ -#define TPMDLK 0x000f8210 /* Top of Peripheral Memory Space */ -#define BIODLK 0x000f8220 /* Bottom of Peripheral I/O Space */ -#define TIODLK 0x000f8230 /* Top of Perioheral I/O Space */ -#define DLKCTRL0x000f8240 /* Deadlock control */ -#define DLKDEV 0x000f8250 /* Deadlock device */ - -/* System standard configuration registers space */ -#defineDCR 0xff20 -#defineDID 0xff24 -#defineBAR 0xff200018 - -/* Device specific configuration space */ -#definePCIENB 0xff201000 - -/* Configuration space registers */ -#define CPC710_BUS_NUMBER 0x40 -#define CPC710_SUB_BUS_NUMBER 0x41 - -#endif /* __PPC_PLATFORMS_CPC710_H */ -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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: Make nenuconfig does not save parameters.
On Sat, Mar 10, 2007 at 07:23:41PM +0100, Jan Engelhardt wrote: Whether the 'working config file path' should change when you do 'Save as Alternate' or not, is a menuconfig axiom. Ask Sam Ravnborg if you want it changed :-) Current behaviour is not logical but on the other hand I do not see a big need to make it so. It seems that people very seldom uses save alternate anyway. But patches are welcome. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] USER-MODE LINUX: Delete unused header file.
Delete the apparently unused header file arch/um/kernel/tt/include/mode_kern-tt.h. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- this one i'm not so sure about as there is a header file named mode_kern_tt.h, and those names are uncomfortably similar. diff --git a/arch/um/kernel/tt/include/mode_kern-tt.h b/arch/um/kernel/tt/include/mode_kern-tt.h deleted file mode 100644 index 2a35b15..000 --- a/arch/um/kernel/tt/include/mode_kern-tt.h +++ /dev/null @@ -1,52 +0,0 @@ -/* - * Copyright (C) 2002 Jeff Dike ([EMAIL PROTECTED]) - * Licensed under the GPL - */ - -#ifndef __TT_MODE_KERN_H__ -#define __TT_MODE_KERN_H__ - -#include linux/sched.h -#include asm/page.h -#include asm/ptrace.h -#include asm/uaccess.h - -extern void switch_to_tt(void *prev, void *next); -extern void flush_thread_tt(void); -extern void start_thread_tt(struct pt_regs *regs, unsigned long eip, - unsigned long esp); -extern int copy_thread_tt(int nr, unsigned long clone_flags, unsigned long sp, - unsigned long stack_top, struct task_struct *p, - struct pt_regs *regs); -extern void release_thread_tt(struct task_struct *task); -extern void initial_thread_cb_tt(void (*proc)(void *), void *arg); -extern void init_idle_tt(void); -extern void flush_tlb_kernel_range_tt(unsigned long start, unsigned long end); -extern void flush_tlb_kernel_vm_tt(void); -extern void __flush_tlb_one_tt(unsigned long addr); -extern void flush_tlb_range_tt(struct vm_area_struct *vma, - unsigned long start, unsigned long end); -extern void flush_tlb_mm_tt(struct mm_struct *mm); -extern void force_flush_all_tt(void); -extern long execute_syscall_tt(void *r); -extern void before_mem_tt(unsigned long brk_start); -extern unsigned long set_task_sizes_tt(int arg, unsigned long *host_size_out, - unsigned long *task_size_out); -extern int start_uml_tt(void); -extern int external_pid_tt(struct task_struct *task); -extern int thread_pid_tt(struct task_struct *task); - -#define kmem_end_tt (host_task_size - ABOVE_KMEM) - -#endif - -/* - * 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: - */ -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Delete unused header file.
Delete apparently unused header file drivers/char/digi.h.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
not sure who the proper maintainer is on this one.
diff --git a/drivers/char/digi.h b/drivers/char/digi.h
deleted file mode 100644
index 19df0e8..000
--- a/drivers/char/digi.h
+++ /dev/null
@@ -1,71 +0,0 @@
-/* Definitions for DigiBoard ditty(1) command. */
-
-#if !defined(TIOCMODG)
-#defineTIOCMODG(('d'8) | 250)/* get modem
ctrl state */
-#defineTIOCMODS(('d'8) | 251)/* set modem
ctrl state */
-#endif
-
-#if !defined(TIOCMSET)
-#defineTIOCMSET(('d'8) | 252)/* set modem
ctrl state */
-#defineTIOCMGET(('d'8) | 253)/* set modem
ctrl state */
-#endif
-
-#if !defined(TIOCMBIC)
-#defineTIOCMBIC(('d'8) | 254)/* set modem
ctrl state */
-#defineTIOCMBIS(('d'8) | 255)/* set modem
ctrl state */
-#endif
-
-#if !defined(TIOCSDTR)
-#defineTIOCSDTR(('e'8) | 0) /* set DTR
*/
-#defineTIOCCDTR(('e'8) | 1) /* clear DTR
*/
-#endif
-
-/
- * Ioctl command arguments for DIGI parameters.
- /
-#define DIGI_GETA (('e'8) | 94) /* Read params */
-
-#define DIGI_SETA (('e'8) | 95) /* Set params */
-#define DIGI_SETAW (('e'8) | 96) /* Drain set params */
-#define DIGI_SETAF (('e'8) | 97) /* Drain, flush set params */
-
-#defineDIGI_GETFLOW(('e'8) | 99) /* Get startc/stopc
flow */
- /* control characters*/
-#defineDIGI_SETFLOW(('e'8) | 100)/* Set
startc/stopc flow */
- /* control characters*/
-#defineDIGI_GETAFLOW (('e'8) | 101)/* Get Aux.
startc/stopc */
- /* flow control chars*/
-#defineDIGI_SETAFLOW (('e'8) | 102)/* Set Aux.
startc/stopc */
- /* flow control chars*/
-
-struct digiflow_struct {
- unsigned char startc; /* flow cntl start char
*/
- unsigned char stopc; /* flow cntl stop char
*/
-};
-
-typedef struct digiflow_struct digiflow_t;
-
-
-/
- * Values for digi_flags
- /
-#define DIGI_IXON 0x0001 /* Handle IXON in the FEP */
-#define DIGI_FAST 0x0002 /* Fast baud rates */
-#define RTSPACE0x0004 /* RTS input flow control
*/
-#define CTSPACE0x0008 /* CTS output flow control
*/
-#define DSRPACE0x0010 /* DSR output flow control
*/
-#define DCDPACE0x0020 /* DCD output flow control
*/
-#define DTRPACE0x0040 /* DTR input flow control
*/
-#define DIGI_FORCEDCD 0x0100 /* Force carrier*/
-#defineDIGI_ALTPIN 0x0200 /* Alternate RJ-45 pin config
*/
-#defineDIGI_AIXON 0x0400 /* Aux flow control in fep
*/
-
-
-/
- * Structure used with ioctl commands for DIGI parameters.
- /
-struct digi_struct {
- unsigned short digi_flags; /* Flags (see above)*/
-};
-
-typedef struct digi_struct digi_t;
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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: Make nenuconfig does not save parameters.
On Mar 10 2007 22:27, Sam Ravnborg wrote: On Sat, Mar 10, 2007 at 07:23:41PM +0100, Jan Engelhardt wrote: Whether the 'working config file path' should change when you do 'Save as Alternate' or not, is a menuconfig axiom. Ask Sam Ravnborg if you want it changed :-) Current behaviour is not logical but on the other hand I do not see a big need to make it so. It seems that people very seldom uses save alternate anyway. But patches are welcome. ^_^ The patch has already been posted, has not it? Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] DRM: Delete unused header file.
Delete apparently unused header file drivers/char/drm/via_mm.h.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
diff --git a/drivers/char/drm/via_mm.h b/drivers/char/drm/via_mm.h
deleted file mode 100644
index d57efda..000
--- a/drivers/char/drm/via_mm.h
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * Copyright 1998-2003 VIA Technologies, Inc. All Rights Reserved.
- * Copyright 2001-2003 S3 Graphics, Inc. All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the Software),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sub license,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * VIA, S3 GRAPHICS, AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- */
-#ifndef _via_drm_mm_h_
-#define _via_drm_mm_h_
-
-typedef struct {
- unsigned int context;
- unsigned int size;
- unsigned long offset;
- unsigned long free;
-} drm_via_mm_t;
-
-typedef struct {
- unsigned int size;
- unsigned long handle;
- void *virtual;
-} drm_via_dma_t;
-
-#endif
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 6/9] signalfd/timerfd v1 - timerfd core ...
On Sat, 10 Mar 2007, Nicholas Miell wrote: That's what the sigevent structure is for -- to describe how events should be signaled to userspace, whether by signal delivery, thread creation, or queuing to event completion ports. If if you think extending it would be bad, I can show you the line in POSIX where it encourages the contrary. I'm sorry, but by pointing to the POSIX timer stuff, you're just making your argument weaker. POSIX timers are a horrible crock and over-designed to be a union of everything that has ever been done. Nasty. We had tons of bugs in the original setup because they were so damn nasty. I'd rather look at just about *anything* else for good design than from some of the abortions that are posix-timers. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/20] 2.6.20-stable review
Greg KH wrote: On Fri, Mar 09, 2007 at 10:16:03PM -0800, Greg KH wrote: This is the start of the stable review cycle for the 2.6.20.3 release. Oh, the rolled up patch is at: kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.20.3-rc1.gz You mean: kernel.org/pub/linux/kernel/v2.6/incr/patch-2.6.20.3-rc1.gz ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Fix VMI and COMPAT_VDSO for 2.6.21
Ingo Molnar wrote: makes sense. We can do Jan's relocatable-COMPAT_VDSO thing in v2.6.22, but for v2.6.21 that's way too intrusive. Agree. I think we can clean up some of the strange build magic though, by adding boot time ELF magic instead. We'll see which works out better. Zach - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 00/20] 2.6.20-stable review
On Sat, Mar 10, 2007 at 04:43:57PM -0500, Chuck Ebbert wrote: Greg KH wrote: On Fri, Mar 09, 2007 at 10:16:03PM -0800, Greg KH wrote: This is the start of the stable review cycle for the 2.6.20.3 release. Oh, the rolled up patch is at: kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.20.3-rc1.gz You mean: kernel.org/pub/linux/kernel/v2.6/incr/patch-2.6.20.3-rc1.gz ? Oops, I put it in the wrong directory, sorry about that. I've now moved it to the testing/ subdir. 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: [ck] Re: RSDL v0.28 for 2.6.20
On 3/10/07, Willy Tarreau [EMAIL PROTECTED] wrote: BTW, Con, I think that you should base your work on 2.6.20.[23] and not 2.6.20 next time, due to this conflict. It will get wider adoption. Maybe I'm naive, but I find this hard to understand -- 2.6.20.2 didn't exist when Con published his patch. (Con published it ~12 hours before the release of 2.6.20.2, from what I can tell.) How can he base his work on something that didn't yet exist? (And it applied cleanly to 2.6.20.1, the latest when he published it.) That said, being able to easily apply it to the latest stable kernel would probably increase adoption, yes. I will agree with that much. -- ~Mike - Just the crazy copy cat. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...
On Sat, 2007-03-10 at 13:44 -0800, Linus Torvalds wrote: On Sat, 10 Mar 2007, Nicholas Miell wrote: That's what the sigevent structure is for -- to describe how events should be signaled to userspace, whether by signal delivery, thread creation, or queuing to event completion ports. If if you think extending it would be bad, I can show you the line in POSIX where it encourages the contrary. I'm sorry, but by pointing to the POSIX timer stuff, you're just making your argument weaker. POSIX timers are a horrible crock and over-designed to be a union of everything that has ever been done. Nasty. We had tons of bugs in the original setup because they were so damn nasty. Care to elaborate on why they're a horrible crock? And are the bugs fixed? If so, why replace them? They work now. I'd rather look at just about *anything* else for good design than from some of the abortions that are posix-timers. Linus -- Nicholas Miell [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MPT FUSION: Delete unused header files.
Delete apparently unused header files.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
drivers/message/fusion/lsi/mpi_inb.h| 221 --
drivers/message/fusion/lsi/mpi_log_fc.h | 89
2 files changed, 310 deletions(-)
diff --git a/drivers/message/fusion/lsi/mpi_inb.h
b/drivers/message/fusion/lsi/mpi_inb.h
deleted file mode 100644
index ff16730..000
--- a/drivers/message/fusion/lsi/mpi_inb.h
+++ /dev/null
@@ -1,221 +0,0 @@
-/*
- * Copyright (c) 2003-2004 LSI Logic Corporation.
- *
- *
- * Name: mpi_inb.h
- * Title: MPI Inband structures and definitions
- * Creation Date: September 30, 2003
- *
- *mpi_inb.h Version: 01.05.01
- *
- * Version History
- * ---
- *
- * Date Version Description
- * --
- * 05-11-04 01.03.01 Original release.
- * 08-19-04 01.05.01 Original release for MPI v1.5.
- * --
- */
-
-#ifndef MPI_INB_H
-#define MPI_INB_H
-
-/**
-*
-*I n b a n dM e s s a g e s
-*
-***/
-
-
-//
-/* Inband Buffer Post Request */
-//
-
-typedef struct _MSG_INBAND_BUFFER_POST_REQUEST
-{
-U8 Reserved1; /* 00h */
-U8 BufferCount;/* 01h */
-U8 ChainOffset;/* 02h */
-U8 Function; /* 03h */
-U16 Reserved2; /* 04h */
-U8 Reserved3; /* 06h */
-U8 MsgFlags; /* 07h */
-U32 MsgContext; /* 08h */
-U32 Reserved4; /* 0Ch */
-SGE_TRANS_SIMPLE_UNION SGL;/* 10h */
-} MSG_INBAND_BUFFER_POST_REQUEST, MPI_POINTER
PTR_MSG_INBAND_BUFFER_POST_REQUEST,
- MpiInbandBufferPostRequest_t , MPI_POINTER pMpiInbandBufferPostRequest_t;
-
-
-typedef struct _WWN_FC_FORMAT
-{
-U64 NodeName; /* 00h */
-U64 PortName; /* 08h */
-} WWN_FC_FORMAT, MPI_POINTER PTR_WWN_FC_FORMAT,
- WwnFcFormat_t, MPI_POINTER pWwnFcFormat_t;
-
-typedef struct _WWN_SAS_FORMAT
-{
-U64 WorldWideID;/* 00h */
-U32 Reserved1; /* 08h */
-U32 Reserved2; /* 0Ch */
-} WWN_SAS_FORMAT, MPI_POINTER PTR_WWN_SAS_FORMAT,
- WwnSasFormat_t, MPI_POINTER pWwnSasFormat_t;
-
-typedef union _WWN_INBAND_FORMAT
-{
-WWN_FC_FORMAT Fc;
-WWN_SAS_FORMAT Sas;
-} WWN_INBAND_FORMAT, MPI_POINTER PTR_WWN_INBAND_FORMAT,
- WwnInbandFormat, MPI_POINTER pWwnInbandFormat;
-
-
-/* Inband Buffer Post reply message */
-
-typedef struct _MSG_INBAND_BUFFER_POST_REPLY
-{
-U16 Reserved1; /* 00h */
-U8 MsgLength; /* 02h */
-U8 Function; /* 03h */
-U16 Reserved2; /* 04h */
-U8 Reserved3; /* 06h */
-U8 MsgFlags; /* 07h */
-U32 MsgContext; /* 08h */
-U16 Reserved4; /* 0Ch */
-U16 IOCStatus; /* 0Eh */
-U32 IOCLogInfo; /* 10h */
-U32 TransferLength; /* 14h */
-U32 TransactionContext; /* 18h */
-WWN_INBAND_FORMAT Wwn;/* 1Ch */
-U32 IOCIdentifier[4]; /* 2Ch */
-} MSG_INBAND_BUFFER_POST_REPLY, MPI_POINTER PTR_MSG_INBAND_BUFFER_POST_REPLY,
- MpiInbandBufferPostReply_t, MPI_POINTER pMpiInbandBufferPostReply_t;
-
-
-//
-/* Inband Send Request */
-//
-
-typedef struct _MSG_INBAND_SEND_REQUEST
-{
-U16 Reserved1; /* 00h */
-U8 ChainOffset;/* 02h */
-U8 Function; /* 03h */
-U16 Reserved2; /* 04h */
-U8 Reserved3; /* 06h */
-U8 MsgFlags; /* 07h */
-U32 MsgContext; /* 08h */
-U32 Reserved4; /* 0Ch */
-WWN_INBAND_FORMAT
[PATCH] I2O: Delete unused header file.
Delete apparently unused header file.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
diff --git a/drivers/message/i2o/i2o_lan.h b/drivers/message/i2o/i2o_lan.h
deleted file mode 100644
index 6502b81..000
--- a/drivers/message/i2o/i2o_lan.h
+++ /dev/null
@@ -1,159 +0,0 @@
-/*
- * i2o_lan.h I2O LAN Class definitions
- *
- * I2O LAN CLASS OSM May 26th 2000
- *
- * (C) Copyright 1999, 2000 University of Helsinki,
- * Department of Computer Science
- *
- * This code is still under development / test.
- *
- * Author: Auvo Häkkinen [EMAIL PROTECTED]
- * Juha Sievänen [EMAIL PROTECTED]
- * Taneli Vähäkangas [EMAIL PROTECTED]
- */
-
-#ifndef _I2O_LAN_H
-#define _I2O_LAN_H
-
-/* Default values for tunable parameters first */
-
-#define I2O_LAN_MAX_BUCKETS_OUT 96
-#define I2O_LAN_BUCKET_THRESH 18 /* 9 buckets in one message */
-#define I2O_LAN_RX_COPYBREAK 200
-#define I2O_LAN_TX_TIMEOUT (1*HZ)
-#define I2O_LAN_TX_BATCH_MODE 2 /* 2=automatic, 1=on, 0=off */
-#define I2O_LAN_EVENT_MASK 0 /* 0=None, 0xFFC2=All */
-
-/* LAN types */
-#define I2O_LAN_ETHERNET 0x0030
-#define I2O_LAN_100VG 0x0040
-#define I2O_LAN_TR 0x0050
-#define I2O_LAN_FDDI 0x0060
-#define I2O_LAN_FIBRE_CHANNEL 0x0070
-#define I2O_LAN_UNKNOWN0x
-
-/* Connector types */
-
-/* Ethernet */
-#define I2O_LAN_AUI(I2O_LAN_ETHERNET 4) + 0x0001
-#define I2O_LAN_10BASE5(I2O_LAN_ETHERNET 4) + 0x0002
-#define I2O_LAN_FIORL (I2O_LAN_ETHERNET 4) + 0x0003
-#define I2O_LAN_10BASE2(I2O_LAN_ETHERNET 4) + 0x0004
-#define I2O_LAN_10BROAD36 (I2O_LAN_ETHERNET 4) + 0x0005
-#define I2O_LAN_10BASE_T (I2O_LAN_ETHERNET 4) + 0x0006
-#define I2O_LAN_10BASE_FP (I2O_LAN_ETHERNET 4) + 0x0007
-#define I2O_LAN_10BASE_FB (I2O_LAN_ETHERNET 4) + 0x0008
-#define I2O_LAN_10BASE_FL (I2O_LAN_ETHERNET 4) + 0x0009
-#define I2O_LAN_100BASE_TX (I2O_LAN_ETHERNET 4) + 0x000A
-#define I2O_LAN_100BASE_FX (I2O_LAN_ETHERNET 4) + 0x000B
-#define I2O_LAN_100BASE_T4 (I2O_LAN_ETHERNET 4) + 0x000C
-#define I2O_LAN_1000BASE_SX(I2O_LAN_ETHERNET 4) + 0x000D
-#define I2O_LAN_1000BASE_LX(I2O_LAN_ETHERNET 4) + 0x000E
-#define I2O_LAN_1000BASE_CX(I2O_LAN_ETHERNET 4) + 0x000F
-#define I2O_LAN_1000BASE_T (I2O_LAN_ETHERNET 4) + 0x0010
-
-/* AnyLAN */
-#define I2O_LAN_100VG_ETHERNET (I2O_LAN_100VG 4) + 0x0001
-#define I2O_LAN_100VG_TR (I2O_LAN_100VG 4) + 0x0002
-
-/* Token Ring */
-#define I2O_LAN_4MBIT (I2O_LAN_TR 4) + 0x0001
-#define I2O_LAN_16MBIT (I2O_LAN_TR 4) + 0x0002
-
-/* FDDI */
-#define I2O_LAN_125MBAUD (I2O_LAN_FDDI 4) + 0x0001
-
-/* Fibre Channel */
-#define I2O_LAN_POINT_POINT(I2O_LAN_FIBRE_CHANNEL 4) + 0x0001
-#define I2O_LAN_ARB_LOOP (I2O_LAN_FIBRE_CHANNEL 4) + 0x0002
-#define I2O_LAN_PUBLIC_LOOP(I2O_LAN_FIBRE_CHANNEL 4) + 0x0003
-#define I2O_LAN_FABRIC (I2O_LAN_FIBRE_CHANNEL 4) + 0x0004
-
-#define I2O_LAN_EMULATION 0x0F00
-#define I2O_LAN_OTHER 0x0F01
-#define I2O_LAN_DEFAULT0x
-
-/* LAN class functions */
-
-#define LAN_PACKET_SEND0x3B
-#define LAN_SDU_SEND 0x3D
-#define LAN_RECEIVE_POST 0x3E
-#define LAN_RESET 0x35
-#define LAN_SUSPEND0x37
-
-/* LAN DetailedStatusCode defines */
-#define I2O_LAN_DSC_SUCCESS0x00
-#define I2O_LAN_DSC_DEVICE_FAILURE 0x01
-#define I2O_LAN_DSC_DESTINATION_NOT_FOUND 0x02
-#defineI2O_LAN_DSC_TRANSMIT_ERROR 0x03
-#define I2O_LAN_DSC_TRANSMIT_ABORTED 0x04
-#define I2O_LAN_DSC_RECEIVE_ERROR 0x05
-#define I2O_LAN_DSC_RECEIVE_ABORTED0x06
-#define I2O_LAN_DSC_DMA_ERROR 0x07
-#define I2O_LAN_DSC_BAD_PACKET_DETECTED0x08
-#define I2O_LAN_DSC_OUT_OF_MEMORY 0x09
-#define I2O_LAN_DSC_BUCKET_OVERRUN 0x0A
-#define I2O_LAN_DSC_IOP_INTERNAL_ERROR 0x0B
-#define I2O_LAN_DSC_CANCELED 0x0C
-#define I2O_LAN_DSC_INVALID_TRANSACTION_CONTEXT0x0D
-#define I2O_LAN_DSC_DEST_ADDRESS_DETECTED 0x0E
-#define I2O_LAN_DSC_DEST_ADDRESS_OMITTED 0x0F
-#define I2O_LAN_DSC_PARTIAL_PACKET_RETURNED0x10
-#define I2O_LAN_DSC_SUSPENDED 0x11
-
-struct i2o_packet_info {
- u32 offset:24;
- u32 flags:8;
- u32 len:24;
- u32 status:8;
-};
-
-struct i2o_bucket_descriptor {
- u32 context;/* FIXME: 64bit support */
- struct i2o_packet_info packet_info[1];
-};
-
-/* Event Indicator Mask Flags for LAN OSM */
-
-#define
[PATCH] Remove unused header file.
Remove apparently unused header file drivers/net/chelsio/vsc8244_reg.h. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- not sure who the maintainer is here. diff --git a/drivers/net/chelsio/vsc8244_reg.h b/drivers/net/chelsio/vsc8244_reg.h deleted file mode 100644 index d3c1829..000 --- a/drivers/net/chelsio/vsc8244_reg.h +++ /dev/null @@ -1,172 +0,0 @@ -/* $Date: 2005/11/23 16:28:53 $ $RCSfile: vsc8244_reg.h,v $ $Revision: 1.1 $ */ -#ifndef CHELSIO_MV8E1XXX_H -#define CHELSIO_MV8E1XXX_H - -#ifndef BMCR_SPEED1000 -# define BMCR_SPEED1000 0x40 -#endif - -#ifndef ADVERTISE_PAUSE -# define ADVERTISE_PAUSE 0x400 -#endif -#ifndef ADVERTISE_PAUSE_ASYM -# define ADVERTISE_PAUSE_ASYM 0x800 -#endif - -/* Gigabit MII registers */ -#define MII_GBMR 1 /* 1000Base-T mode register */ -#define MII_GBCR 9 /* 1000Base-T control register */ -#define MII_GBSR 10 /* 1000Base-T status register */ - -/* 1000Base-T control register fields */ -#define GBCR_ADV_1000HALF 0x100 -#define GBCR_ADV_1000FULL 0x200 -#define GBCR_PREFER_MASTER0x400 -#define GBCR_MANUAL_AS_MASTER 0x800 -#define GBCR_MANUAL_CONFIG_ENABLE 0x1000 - -/* 1000Base-T status register fields */ -#define GBSR_LP_1000HALF 0x400 -#define GBSR_LP_1000FULL 0x800 -#define GBSR_REMOTE_OK0x1000 -#define GBSR_LOCAL_OK 0x2000 -#define GBSR_LOCAL_MASTER 0x4000 -#define GBSR_MASTER_FAULT 0x8000 - -/* Vitesse PHY interrupt status bits. */ -#if 0 -#define VSC8244_INTR_JABBER 0x0001 -#define VSC8244_INTR_POLARITY_CHNG 0x0002 -#define VSC8244_INTR_ENG_DETECT_CHNG 0x0010 -#define VSC8244_INTR_DOWNSHIFT 0x0020 -#define VSC8244_INTR_MDI_XOVER_CHNG 0x0040 -#define VSC8244_INTR_FIFO_OVER_UNDER 0x0080 -#define VSC8244_INTR_FALSE_CARRIER 0x0100 -#define VSC8244_INTR_SYMBOL_ERROR0x0200 -#define VSC8244_INTR_LINK_CHNG 0x0400 -#define VSC8244_INTR_AUTONEG_DONE0x0800 -#define VSC8244_INTR_PAGE_RECV 0x1000 -#define VSC8244_INTR_DUPLEX_CHNG 0x2000 -#define VSC8244_INTR_SPEED_CHNG 0x4000 -#define VSC8244_INTR_AUTONEG_ERR 0x8000 -#else -//#define VSC8244_INTR_JABBER 0x0001 -//#define VSC8244_INTR_POLARITY_CHNG 0x0002 -//#define VSC8244_INTR_BIT20x0004 -//#define VSC8244_INTR_BIT30x0008 -#define VSC8244_INTR_RX_ERR 0x0001 -#define VSC8244_INTR_MASTER_SLAVE0x0002 -#define VSC8244_INTR_CABLE_IMPAIRED 0x0004 -#define VSC8244_INTR_FALSE_CARRIER 0x0008 -//#define VSC8244_INTR_ENG_DETECT_CHNG 0x0010 -//#define VSC8244_INTR_DOWNSHIFT 0x0020 -//#define VSC8244_INTR_MDI_XOVER_CHNG 0x0040 -//#define VSC8244_INTR_FIFO_OVER_UNDER 0x0080 -#define VSC8244_INTR_BIT40x0010 -#define VSC8244_INTR_FIFO_RX 0x0020 -#define VSC8244_INTR_FIFO_OVER_UNDER 0x0040 -#define VSC8244_INTR_LOCK_LOST 0x0080 -//#define VSC8244_INTR_FALSE_CARRIER 0x0100 -//#define VSC8244_INTR_SYMBOL_ERROR0x0200 -//#define VSC8244_INTR_LINK_CHNG 0x0400 -//#define VSC8244_INTR_AUTONEG_DONE0x0800 -#define VSC8244_INTR_SYMBOL_ERROR0x0100 -#define VSC8244_INTR_ENG_DETECT_CHNG 0x0200 -#define VSC8244_INTR_AUTONEG_DONE0x0400 -#define VSC8244_INTR_AUTONEG_ERR 0x0800 -//#define VSC8244_INTR_PAGE_RECV 0x1000 -//#define VSC8244_INTR_DUPLEX_CHNG 0x2000 -//#define VSC8244_INTR_SPEED_CHNG 0x4000 -//#define VSC8244_INTR_AUTONEG_ERR 0x8000 -#define VSC8244_INTR_DUPLEX_CHNG 0x1000 -#define VSC8244_INTR_LINK_CHNG 0x2000 -#define VSC8244_INTR_SPEED_CHNG 0x4000 -#define VSC8244_INTR_STATUS 0x8000 -#endif - - -/* Vitesse PHY specific registers. */ -#define VSC8244_SPECIFIC_CNTRL_REGISTER 16 -#define VSC8244_SPECIFIC_STATUS_REGISTER 0x1c -#define VSC8244_INTERRUPT_ENABLE_REGISTER 0x19 -#define VSC8244_INTERRUPT_STATUS_REGISTER 0x1a -#define VSC8244_EXT_PHY_SPECIFIC_CNTRL_REGISTER 20 -#define VSC8244_RECV_ERR_CNTR_REGISTER21 -#define VSC8244_RES_REGISTER 22 -#define VSC8244_GLOBAL_STATUS_REGISTER23 -#define VSC8244_LED_CONTROL_REGISTER 24 -#define VSC8244_MANUAL_LED_OVERRIDE_REGISTER 25 -#define VSC8244_EXT_PHY_SPECIFIC_CNTRL_2_REGISTER 26 -#define VSC8244_EXT_PHY_SPECIFIC_STATUS_REGISTER 27 -#define VSC8244_VIRTUAL_CABLE_TESTER_REGISTER 28 -#define VSC8244_EXTENDED_ADDR_REGISTER29 -#define VSC8244_EXTENDED_REGISTER 30 - -/* PHY specific control register fields */ -#define S_PSCR_MDI_XOVER_MODE5 -#define M_PSCR_MDI_XOVER_MODE0x3 -#define V_PSCR_MDI_XOVER_MODE(x) ((x) S_PSCR_MDI_XOVER_MODE) -#define G_PSCR_MDI_XOVER_MODE(x) (((x) S_PSCR_MDI_XOVER_MODE) M_PSCR_MDI_XOVER_MODE) - -/* Extended PHY specific control register fields */ -#define S_DOWNSHIFT_ENABLE 8 -#define V_DOWNSHIFT_ENABLE (1 S_DOWNSHIFT_ENABLE) - -#define S_DOWNSHIFT_CNT9 -#define M_DOWNSHIFT_CNT0x7 -#define
[PATCH] SYSKONNECT: Delete unused header file.
Delete apparently unused header file drivers/net/skfp/h/lnkstat.h.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
diff --git a/drivers/net/skfp/h/lnkstat.h b/drivers/net/skfp/h/lnkstat.h
deleted file mode 100644
index c73dcd9..000
--- a/drivers/net/skfp/h/lnkstat.h
+++ /dev/null
@@ -1,84 +0,0 @@
-/**
- *
- * (C)Copyright 1998,1999 SysKonnect,
- * a business unit of Schneider Koch Co. Datensysteme GmbH.
- *
- * 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; either version 2 of the License, or
- * (at your option) any later version.
- *
- * The information in this file is provided AS IS without warranty.
- *
-
**/
-
-/*
- * Definition of the Error Log Structure
- * This structure will be copied into the Error Log buffer
- * during the NDIS General Request ReadErrorLog by the MAC Driver
- */
-
-struct s_error_log {
-
- /*
-* place holder for token ring adapter error log (zeros)
-*/
- u_char reserved_0 ;/* byte 0 inside Error Log */
- u_char reserved_1 ;/* byte 1 */
- u_char reserved_2 ;/* byte 2 */
- u_char reserved_3 ;/* byte 3 */
- u_char reserved_4 ;/* byte 4 */
- u_char reserved_5 ;/* byte 5 */
- u_char reserved_6 ;/* byte 6 */
- u_char reserved_7 ;/* byte 7 */
- u_char reserved_8 ;/* byte 8 */
- u_char reserved_9 ;/* byte 9 */
- u_char reserved_10 ; /* byte 10 */
- u_char reserved_11 ; /* byte 11 */
- u_char reserved_12 ; /* byte 12 */
- u_char reserved_13 ; /* byte 13 */
-
- /*
-* FDDI link statistics
-*/
-/*
- * smt error low
- */
-#define SMT_ERL_AEB(115) /* A elast. buffer */
-#define SMT_ERL_BLC(114) /* B link error condition */
-#define SMT_ERL_ALC(113) /* A link error condition */
-#define SMT_ERL_NCC(112) /* not copied condition */
-#define SMT_ERL_FEC(111) /* frame error condition */
-
-/*
- * smt event low
- */
-#define SMT_EVL_NCE(15)
-
- u_short smt_error_low ; /* byte 14/15 */
- u_short smt_error_high ;/* byte 16/17 */
- u_short smt_event_low ; /* byte 18/19 */
- u_short smt_event_high ;/* byte 20/21 */
- u_short connection_policy_violation ; /* byte 22/23 */
- u_short port_event ;/* byte 24/25 */
- u_short set_count_low ; /* byte 26/27 */
- u_short set_count_high ;/* byte 28/29 */
- u_short aci_id_code ; /* byte 30/31 */
- u_short purge_frame_counter ; /* byte 32/33 */
-
- /*
-* CMT and RMT state machines
-*/
- u_short ecm_state ; /* byte 34/35 */
- u_short pcm_a_state ; /* byte 36/37 */
- u_short pcm_b_state ; /* byte 38/39 */
- u_short cfm_state ; /* byte 40/41 */
- u_short rmt_state ; /* byte 42/43 */
-
- u_short not_used[30] ; /* byte 44-103 */
-
- u_short ucode_version_level ; /* byte 104/105 */
-
- u_short not_used_1 ;/* byte 106/107 */
- u_short not_used_2 ;/* byte 108/109 */
-} ;
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.28 for 2.6.20
On Sat, Mar 10, 2007 at 04:56:57PM -0500, michael chang wrote: On 3/10/07, Willy Tarreau [EMAIL PROTECTED] wrote: BTW, Con, I think that you should base your work on 2.6.20.[23] and not 2.6.20 next time, due to this conflict. It will get wider adoption. ^^ Maybe I'm naive, but I find this hard to understand -- 2.6.20.2 didn't exist when Con published his patch. (Con published it ~12 hours before the release of 2.6.20.2, from what I can tell.) How can he base his work on something that didn't yet exist? (And it applied cleanly to 2.6.20.1, the latest when he published it.) You see the words I have underlined ? next time. I know for sure he published it before 2.6.20.2, but now that it is out, I suggested that Con rebases his work on this version for new releases. Regards, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] LANMEDIA: Delete unused header file.
Delete apparently unused header file
drivers/net/wan/lmc/lmc_media.h.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
not sure who maintainer is here.
diff --git a/drivers/net/wan/lmc/lmc_media.h b/drivers/net/wan/lmc/lmc_media.h
deleted file mode 100644
index ddcc004..000
--- a/drivers/net/wan/lmc/lmc_media.h
+++ /dev/null
@@ -1,65 +0,0 @@
-#ifndef _LMC_MEDIA_H_
-#define _LMC_MEDIA_H_
-
-lmc_media_t lmc_ds3_media = {
- lmc_ds3_init,/* special media init stuff */
- lmc_ds3_default, /* reset to default state */
- lmc_ds3_set_status, /* reset status to state provided */
- lmc_dummy_set_1, /* set clock source */
- lmc_dummy_set2_1,/* set line speed */
- lmc_ds3_set_100ft, /* set cable length */
- lmc_ds3_set_scram, /* set scrambler */
- lmc_ds3_get_link_status, /* get link status */
- lmc_dummy_set_1, /* set link status */
- lmc_ds3_set_crc_length, /* set CRC length */
- lmc_dummy_set_1, /* set T1 or E1 circuit type */
- lmc_ds3_watchdog
-};
-
-lmc_media_t lmc_hssi_media = {
- lmc_hssi_init, /* special media init stuff */
- lmc_hssi_default,/* reset to default state */
- lmc_hssi_set_status, /* reset status to state provided */
- lmc_hssi_set_clock, /* set clock source */
- lmc_dummy_set2_1,/* set line speed */
- lmc_dummy_set_1, /* set cable length */
- lmc_dummy_set_1, /* set scrambler */
- lmc_hssi_get_link_status,/* get link status */
- lmc_hssi_set_link_status,/* set link status */
- lmc_hssi_set_crc_length, /* set CRC length */
- lmc_dummy_set_1, /* set T1 or E1 circuit type */
- lmc_hssi_watchdog
-};
-
-lmc_media_t lmc_ssi_media = { lmc_ssi_init,/* special media init stuff */
- lmc_ssi_default, /* reset to default state */
- lmc_ssi_set_status, /* reset status to state provided */
- lmc_ssi_set_clock, /* set clock source */
- lmc_ssi_set_speed, /* set line speed */
- lmc_dummy_set_1, /* set cable length */
- lmc_dummy_set_1, /* set scrambler */
- lmc_ssi_get_link_status, /* get link status */
- lmc_ssi_set_link_status, /* set link status */
- lmc_ssi_set_crc_length, /* set CRC length */
- lmc_dummy_set_1, /* set T1 or E1 circuit type */
- lmc_ssi_watchdog
-};
-
-lmc_media_t lmc_t1_media = {
- lmc_t1_init, /* special media init stuff */
- lmc_t1_default, /* reset to default state */
- lmc_t1_set_status, /* reset status to state provided */
- lmc_t1_set_clock,/* set clock source */
- lmc_dummy_set2_1,/* set line speed */
- lmc_dummy_set_1, /* set cable length */
- lmc_dummy_set_1, /* set scrambler */
- lmc_t1_get_link_status, /* get link status */
- lmc_dummy_set_1, /* set link status */
- lmc_t1_set_crc_length, /* set CRC length */
- lmc_t1_set_circuit_type, /* set T1 or E1 circuit type */
- lmc_t1_watchdog
-};
-
-
-#endif
-
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Suspend to disk bug 2.6.21-rc2-git1
Hi! I'm not sure what version did exacly caused susped to disk problems but anyway, in 2.6.21-rc2-git1, suspend to disk breaks ACPI. ACPI events do not even emit ACPI interrupts. Suspend to ram works nicely. Is 2.6.21-latest better? There were many problems in suspend area, hopefully they are slowly being fixed... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] SCSI: Delete unused header file.
Delete apparently unused header file drivers/scsi/pci2000.h. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- diff --git a/drivers/scsi/pci2000.h b/drivers/scsi/pci2000.h deleted file mode 100644 index 0ebd8ce..000 --- a/drivers/scsi/pci2000.h +++ /dev/null @@ -1,197 +0,0 @@ -/ - * Perceptive Solutions, Inc. PCI-2000 device driver for Linux. - * - * pci2000.h - Linux Host Driver for PCI-2000 IntelliCache SCSI Adapters - * - * Copyright (c) 1997-1999 Perceptive Solutions, Inc. - * All Rights Reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that redistributions of source - * code retain the above copyright notice and this comment without - * modification. - * - * Technical updates and product information at: - * http://www.psidisk.com - * - * Please send questions, comments, bug reports to: - * [EMAIL PROTECTED] Technical Support - * - / -#ifndef _PCI2000_H -#define _PCI2000_H - -#include linux/types.h - -#ifndefPSI_EIDE_SCSIOP -#definePSI_EIDE_SCSIOP 1 - -#defineLINUXVERSION(v,p,s)(((v)16) + ((p)8) + (s)) - -// -/* definition of standard data types */ -// -#defineCHARchar -#defineUCHAR unsigned char -#defineSHORT short -#defineUSHORT unsigned short -#defineBOOLlong -#defineLONGlong -#defineULONG unsigned long -#defineVOIDvoid - -typedefCHAR*PCHAR; -typedefUCHAR *PUCHAR; -typedefSHORT *PSHORT; -typedefUSHORT *PUSHORT; -typedefBOOL*PBOOL; -typedefLONG*PLONG; -typedefULONG *PULONG; -typedefVOID*PVOID; - - -// -/* Misc. macros */ -// -#define ANY2SCSI(up, p)\ -((UCHAR *)up)[0] = (((ULONG)(p)) 8);\ -((UCHAR *)up)[1] = ((ULONG)(p)); - -#define SCSI2LONG(up) \ -( (((long)*(((UCHAR *)up))) 16) \ -+ (((long)(((UCHAR *)up)[1])) 8)\ -+ ((long)(((UCHAR *)up)[2])) ) - -#define XANY2SCSI(up, p) \ -((UCHAR *)up)[0] = ((long)(p)) 24; \ -((UCHAR *)up)[1] = ((long)(p)) 16; \ -((UCHAR *)up)[2] = ((long)(p)) 8; \ -((UCHAR *)up)[3] = ((long)(p)); - -#define XSCSI2LONG(up) \ -( (((long)(((UCHAR *)up)[0])) 24) \ -+ (((long)(((UCHAR *)up)[1])) 16) \ -+ (((long)(((UCHAR *)up)[2])) 8) \ -+ ((long)(((UCHAR *)up)[3])) ) - -// -/* SCSI CDB operation codes*/ -// -#define SCSIOP_TEST_UNIT_READY 0x00 -#define SCSIOP_REZERO_UNIT 0x01 -#define SCSIOP_REWIND 0x01 -#define SCSIOP_REQUEST_BLOCK_ADDR 0x02 -#define SCSIOP_REQUEST_SENSE 0x03 -#define SCSIOP_FORMAT_UNIT 0x04 -#define SCSIOP_READ_BLOCK_LIMITS 0x05 -#define SCSIOP_REASSIGN_BLOCKS 0x07 -#define SCSIOP_READ6 0x08 -#define SCSIOP_RECEIVE 0x08 -#define SCSIOP_WRITE6 0x0A -#define SCSIOP_PRINT 0x0A -#define SCSIOP_SEND0x0A -#define SCSIOP_SEEK6 0x0B -#define SCSIOP_TRACK_SELECT0x0B -#define SCSIOP_SLEW_PRINT 0x0B -#define SCSIOP_SEEK_BLOCK 0x0C -#define SCSIOP_PARTITION 0x0D -#define SCSIOP_READ_REVERSE0x0F -#define SCSIOP_WRITE_FILEMARKS 0x10 -#define SCSIOP_FLUSH_BUFFER0x10 -#define SCSIOP_SPACE 0x11 -#define SCSIOP_INQUIRY 0x12 -#define SCSIOP_VERIFY6 0x13 -#define SCSIOP_RECOVER_BUF_DATA0x14 -#define SCSIOP_MODE_SELECT 0x15 -#define SCSIOP_RESERVE_UNIT0x16 -#define SCSIOP_RELEASE_UNIT0x17 -#define SCSIOP_COPY0x18 -#define SCSIOP_ERASE 0x19 -#define SCSIOP_MODE_SENSE 0x1A -#define SCSIOP_START_STOP_UNIT 0x1B -#define SCSIOP_STOP_PRINT 0x1B -#define SCSIOP_LOAD_UNLOAD 0x1B -#define SCSIOP_RECEIVE_DIAGNOSTIC 0x1C -#define SCSIOP_SEND_DIAGNOSTIC 0x1D -#define
[PATCH] CRIS: Delete unused header file.
Delete apparently unused header file drivers/serial/crisv10.h.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
diff --git a/drivers/serial/crisv10.h b/drivers/serial/crisv10.h
deleted file mode 100644
index 4a23340..000
--- a/drivers/serial/crisv10.h
+++ /dev/null
@@ -1,136 +0,0 @@
-/*
- * serial.h: Arch-dep definitions for the Etrax100 serial driver.
- *
- * Copyright (C) 1998, 1999, 2000 Axis Communications AB
- */
-
-#ifndef _ETRAX_SERIAL_H
-#define _ETRAX_SERIAL_H
-
-#include linux/circ_buf.h
-#include asm/termios.h
-
-/* Software state per channel */
-
-#ifdef __KERNEL__
-/*
- * This is our internal structure for each serial port's state.
- *
- * Many fields are paralleled by the structure used by the serial_struct
- * structure.
- *
- * For definitions of the flags field, see tty.h
- */
-
-#define SERIAL_RECV_DESCRIPTORS 8
-
-struct etrax_recv_buffer {
- struct etrax_recv_buffer *next;
- unsigned short length;
- unsigned char error;
- unsigned char pad;
-
- unsigned char buffer[0];
-};
-
-struct e100_serial {
- int baud;
- volatile u8 *port; /* R_SERIALx_CTRL */
- u32 irq; /* bitnr in R_IRQ_MASK2 for dmaX_descr */
-
- /* Output registers */
- volatile u8 *oclrintradr; /* adr to R_DMA_CHx_CLR_INTR */
- volatile u32*ofirstadr; /* adr to R_DMA_CHx_FIRST */
- volatile u8 *ocmdadr; /* adr to R_DMA_CHx_CMD */
- const volatile u8 *ostatusadr; /* adr to R_DMA_CHx_STATUS */
-
- /* Input registers */
- volatile u8 *iclrintradr; /* adr to R_DMA_CHx_CLR_INTR */
- volatile u32*ifirstadr; /* adr to R_DMA_CHx_FIRST */
- volatile u8 *icmdadr; /* adr to R_DMA_CHx_CMD */
- volatile u32*idescradr; /* adr to R_DMA_CHx_DESCR */
-
- int flags; /* defined in tty.h */
-
- u8 rx_ctrl; /* shadow for R_SERIALx_REC_CTRL */
- u8 tx_ctrl; /* shadow for R_SERIALx_TR_CTRL */
- u8 iseteop; /* bit number for R_SET_EOP for the
input dma */
- int enabled; /* Set to 1 if the port is enabled in
HW config */
-
- u8 dma_out_enabled:1; /* Set to 1 if DMA should be used */
- u8 dma_in_enabled:1; /* Set to 1 if DMA should be used */
-
- /* end of fields defined in rs_table[] in .c-file */
- u8 uses_dma_in; /* Set to 1 if DMA is used */
- u8 uses_dma_out; /* Set to 1 if DMA is used */
- u8 forced_eop; /* a fifo eop has been forced */
- int baud_base; /* For special baudrates */
- int custom_divisor; /* For special baudrates */
- struct etrax_dma_descr tr_descr;
- struct etrax_dma_descr rec_descr[SERIAL_RECV_DESCRIPTORS];
- int cur_rec_descr;
-
- volatile inttr_running; /* 1 if output is running */
-
- struct tty_struct *tty;
- int read_status_mask;
- int ignore_status_mask;
- int x_char; /* xon/xoff character */
- int close_delay;
- unsigned short closing_wait;
- unsigned short closing_wait2;
- unsigned long event;
- unsigned long last_active;
- int line;
- int type; /* PORT_ETRAX */
- int count; /* # of fd on device */
- int blocked_open; /* # of blocked opens */
- struct circ_buf xmit;
- struct etrax_recv_buffer *first_recv_buffer;
- struct etrax_recv_buffer *last_recv_buffer;
- unsigned intrecv_cnt;
- unsigned intmax_recv_cnt;
-
- struct work_struct work;
- struct async_icount icount; /* error-statistics etc.*/
- struct ktermios normal_termios;
- struct ktermios callout_termios;
-#ifdef DECLARE_WAITQUEUE
- wait_queue_head_t open_wait;
- wait_queue_head_t close_wait;
-#else
- struct wait_queue *open_wait;
- struct wait_queue *close_wait;
-#endif
-
- unsigned long char_time_usec; /* The time for 1 char,
in usecs */
- unsigned long flush_time_usec; /* How often we should
flush */
- unsigned long last_tx_active_usec; /* Last tx usec in the
jiffies */
- unsigned long last_tx_active; /* Last tx time in
jiffies */
- unsigned long last_rx_active_usec; /* Last rx usec in the
jiffies */
- unsigned long last_rx_active; /* Last rx time in
jiffies */
-
-
[PATCH] swsusp: Fix resume error path in platform mode
From: Rafael J. Wysocki [EMAIL PROTECTED]
If swsusp is using the platform mode during the resume and the image cannot be
read, the platform mode should be switched off before software_resume() returns.
Make it happen.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
---
kernel/power/disk.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.21-rc3/kernel/power/disk.c
===
--- linux-2.6.21-rc3.orig/kernel/power/disk.c
+++ linux-2.6.21-rc3/kernel/power/disk.c
@@ -260,6 +260,7 @@ static int software_resume(void)
error = swsusp_read();
if (error) {
swsusp_free();
+ platform_finish();
goto Thaw;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] rtc: Add RTC class driver for the Maxim MAX6900
From: Dale Farnsworth [EMAIL PROTECTED]
Signed-off-by: Dale Farnsworth.org [EMAIL PROTECTED]
---
drivers/rtc/Kconfig | 10 +
drivers/rtc/Makefile |1
drivers/rtc/rtc-max6900.c | 312
3 files changed, 323 insertions(+)
Index: linux-2.6-powerpc-df/drivers/rtc/Kconfig
===
--- linux-2.6-powerpc-df.orig/drivers/rtc/Kconfig
+++ linux-2.6-powerpc-df/drivers/rtc/Kconfig
@@ -334,6 +334,16 @@ config RTC_DRV_TEST
This driver can also be built as a module. If so, the module
will be called rtc-test.
+config RTC_DRV_MAX6900
+ tristate Maxim 6900
+ depends on RTC_CLASS I2C
+ help
+ If you say yes here you will get support for the
+ Maxim MAX6900 I2C RTC chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-max6900.
+
config RTC_DRV_MAX6902
tristate Maxim 6902
depends on RTC_CLASS SPI
Index: linux-2.6-powerpc-df/drivers/rtc/Makefile
===
--- linux-2.6-powerpc-df.orig/drivers/rtc/Makefile
+++ linux-2.6-powerpc-df/drivers/rtc/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_RTC_DRV_EP93XX) += rtc-ep93
obj-$(CONFIG_RTC_DRV_SA1100) += rtc-sa1100.o
obj-$(CONFIG_RTC_DRV_VR41XX) += rtc-vr41xx.o
obj-$(CONFIG_RTC_DRV_PL031)+= rtc-pl031.o
+obj-$(CONFIG_RTC_DRV_MAX6900) += rtc-max6900.o
obj-$(CONFIG_RTC_DRV_MAX6902) += rtc-max6902.o
obj-$(CONFIG_RTC_DRV_V3020)+= rtc-v3020.o
obj-$(CONFIG_RTC_DRV_AT91RM9200)+= rtc-at91rm9200.o
Index: linux-2.6-powerpc-df/drivers/rtc/rtc-max6900.c
===
--- /dev/null
+++ linux-2.6-powerpc-df/drivers/rtc/rtc-max6900.c
@@ -0,0 +1,312 @@
+/*
+ * rtc class driver for the Maxim MAX6900 chip
+ *
+ * Author: Dale Farnsworth [EMAIL PROTECTED]
+ *
+ * based on previously existing rtc class drivers
+ *
+ * 2007 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed as is without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include linux/module.h
+#include linux/i2c.h
+#include linux/bcd.h
+#include linux/rtc.h
+#include linux/delay.h
+
+#define DRV_NAME max6900
+#define DRV_VERSION 0.1
+
+/*
+ * register indices
+ */
+#define MAX6900_REG_SC 0 /* seconds 00-59 */
+#define MAX6900_REG_MN 1 /* minutes 00-59 */
+#define MAX6900_REG_HR 2 /* hours00-23 */
+#define MAX6900_REG_DT 3 /* day of month 00-31 */
+#define MAX6900_REG_MO 4 /* month01-12 */
+#define MAX6900_REG_DW 5 /* day of week 1-7 */
+#define MAX6900_REG_YR 6 /* year 00-99 */
+#define MAX6900_REG_CT 7 /* control */
+#define MAX6900_REG_LEN8
+
+#define MAX6900_REG_CT_WP (1 7)/* Write Protect */
+
+/*
+ * register read/write commands
+ */
+#define MAX6900_REG_CONTROL_WRITE 0x8e
+#define MAX6900_REG_BURST_READ 0xbf
+#define MAX6900_REG_BURST_WRITE0xbe
+#define MAX6900_REG_RESERVED_READ 0x96
+
+#define MAX6900_IDLE_TIME_AFTER_WRITE 3 /* specification says 2.5 mS */
+
+#define MAX6900_I2C_ADDR 0xa0
+
+static unsigned short normal_i2c[] = {
+ MAX6900_I2C_ADDR 1,
+ I2C_CLIENT_END
+};
+
+I2C_CLIENT_INSMOD; /* defines addr_data */
+
+static int max6900_probe(struct i2c_adapter *adapter, int addr, int kind);
+
+static int max6900_i2c_read_regs(struct i2c_client *client, u8 *buf)
+{
+ u8 reg_addr[1] = { MAX6900_REG_BURST_READ };
+ struct i2c_msg msgs[2] = {
+ {
+ client-addr,
+ 0, /* write */
+ sizeof(reg_addr),
+ reg_addr
+ },
+ {
+ client-addr,
+ I2C_M_RD,
+ MAX6900_REG_LEN,
+ buf
+ }
+ };
+ int rc;
+
+ rc = i2c_transfer(client-adapter, msgs, ARRAY_SIZE(msgs));
+ if (rc != ARRAY_SIZE(msgs)) {
+ dev_err(client-dev, %s: register read failed\n,
+ __FUNCTION__);
+ return -EIO;
+ }
+ return 0;
+}
+
+static int max6900_i2c_write_regs(struct i2c_client *client, u8 const *buf)
+{
+ u8 i2c_buf[MAX6900_REG_LEN + 1] = { MAX6900_REG_BURST_WRITE };
+ struct i2c_msg msgs[1] = {
+ {
+ client-addr,
+ 0, /* write */
+ MAX6900_REG_LEN + 1,
+ i2c_buf
+ }
+ };
+ int rc;
+
+
Re: [PATCH] Software Suspend: Fix suspend when console is in VT_AUTO/KD_GRAPHICS mode
Hi! ...how does qpe know when to repaint the screen, anyway? QPE doesn't need to repaint the screen after wake-up - the framebuffer memory is retained so the PXA270 lcd controller simply displays what was last on the screen when it is re-enabled. That probably means QPE is broken on machines that do not preserve framebuffer over suspend :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.28 for 2.6.20
On 3/10/07, Willy Tarreau [EMAIL PROTECTED] wrote: On Sat, Mar 10, 2007 at 04:56:57PM -0500, michael chang wrote: On 3/10/07, Willy Tarreau [EMAIL PROTECTED] wrote: BTW, Con, I think that you should base your work on 2.6.20.[23] and not 2.6.20 next time, due to this conflict. It will get wider adoption. ^^ Maybe I'm naive, but I find this hard to understand -- 2.6.20.2 didn't exist when Con published his patch. (Con published it ~12 hours before the release of 2.6.20.2, from what I can tell.) How can he base his work on something that didn't yet exist? (And it applied cleanly to 2.6.20.1, the latest when he published it.) You see the words I have underlined ? next time. I know for sure he published it before 2.6.20.2, but now that it is out, I suggested that Con rebases his work on this version for new releases. Oh. That's my mistake, then. That makes sense. To me, it sounded like you were implying he was supposed to base it on 2.6.20.2 in advance, for some reason. *sigh* -- ~Mike - Just the crazy copy cat. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Delete unused header file.
Delete apparently unused header file include/linux/elfnote.h.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
not sure who's responsible for this.
diff --git a/include/linux/elfnote.h b/include/linux/elfnote.h
deleted file mode 100644
index 67396db..000
--- a/include/linux/elfnote.h
+++ /dev/null
@@ -1,90 +0,0 @@
-#ifndef _LINUX_ELFNOTE_H
-#define _LINUX_ELFNOTE_H
-/*
- * Helper macros to generate ELF Note structures, which are put into a
- * PT_NOTE segment of the final vmlinux image. These are useful for
- * including name-value pairs of metadata into the kernel binary (or
- * modules?) for use by external programs.
- *
- * Each note has three parts: a name, a type and a desc. The name is
- * intended to distinguish the note's originator, so it would be a
- * company, project, subsystem, etc; it must be in a suitable form for
- * use in a section name. The type is an integer which is used to tag
- * the data, and is considered to be within the name namespace (so
- * FooCo's type 42 is distinct from BarProj's type 42). The
- * desc field is the actual data. There are no constraints on the
- * desc field's contents, though typically they're fairly small.
- *
- * All notes from a given NAME are put into a section named
- * .note.NAME. When the kernel image is finally linked, all the notes
- * are packed into a single .notes section, which is mapped into the
- * PT_NOTE segment. Because notes for a given name are grouped into
- * the same section, they'll all be adjacent the output file.
- *
- * This file defines macros for both C and assembler use. Their
- * syntax is slightly different, but they're semantically similar.
- *
- * See the ELF specification for more detail about ELF notes.
- */
-
-#ifdef __ASSEMBLER__
-/*
- * Generate a structure with the same shape as Elf{32,64}_Nhdr (which
- * turn out to be the same size and shape), followed by the name and
- * desc data with appropriate padding. The 'desctype' argument is the
- * assembler pseudo op defining the type of the data e.g. .asciz while
- * 'descdata' is the data itself e.g. hello, world.
- *
- * e.g. ELFNOTE(XYZCo, 42, .asciz, forty-two)
- * ELFNOTE(XYZCo, 12, .long, 0xdeadbeef)
- */
-#define ELFNOTE(name, type, desctype, descdata)\
-.pushsection .note.name; \
- .align 4 ; \
- .long 2f - 1f/* namesz */; \
- .long 4f - 3f/* descsz */; \
- .long type ; \
-1:.asciz name; \
-2:.align 4 ; \
-3:desctype descdata; \
-4:.align 4 ; \
-.popsection;
-#else /* !__ASSEMBLER__ */
-#include linux/elf.h
-/*
- * Use an anonymous structure which matches the shape of
- * Elf{32,64}_Nhdr, but includes the name and desc data. The size and
- * type of name and desc depend on the macro arguments. name must
- * be a literal string, and desc must be passed by value. You may
- * only define one note per line, since __LINE__ is used to generate
- * unique symbols.
- */
-#define _ELFNOTE_PASTE(a,b)a##b
-#define _ELFNOTE(size, name, unique, type, desc) \
- static const struct { \
- struct elf##size##_note _nhdr; \
- unsigned char _name[sizeof(name)] \
- __attribute__((aligned(sizeof(Elf##size##_Word; \
- typeof(desc) _desc \
-
__attribute__((aligned(sizeof(Elf##size##_Word; \
- } _ELFNOTE_PASTE(_note_, unique)\
- __attribute_used__ \
- __attribute__((section(.note. name), \
- aligned(sizeof(Elf##size##_Word)), \
- unused)) = { \
- { \
- sizeof(name), \
- sizeof(desc), \
- type, \
- }, \
- name, \
- desc\
- }
-#define ELFNOTE(size, name, type, desc)\
- _ELFNOTE(size, name, __LINE__, type, desc)
-
-#define ELFNOTE32(name, type, desc) ELFNOTE(32, name, type, desc)
-#define ELFNOTE64(name, type, desc) ELFNOTE(64, name, type, desc)
-#endif /* __ASSEMBLER__ */
-
-#endif /* _LINUX_ELFNOTE_H */
--
Re: [PATCH] Software Suspend: Fix suspend when console is in VT_AUTO/KD_GRAPHICS mode
Hi1
It should explain why it is okay to proceed when we can't change to
text console.
See updated comment in attached patch. It's really up to the caller to
decide what to do if we can't switch the console - currently all callers
ignore the return code so I assume that it's okay to proceed anyway.
Ok, I guess the patch is right thing to do after all. Fix issues
below, append a changelog, and send a patch to lmkl, cc Andrew Morton
and me. Oh and you have my ACK.
Pavel
Signed-off-by: Andrew Johnson [EMAIL PROTECTED]
---
diff -rup linux-2.6.20.1/drivers/char/vt.c linux/drivers/char/vt.c
--- linux-2.6.20.1/drivers/char/vt.c 2007-02-19 22:34:32.0 -0800
+++ linux/drivers/char/vt.c 2007-03-09 15:48:29.0 -0800
@@ -2188,10 +2188,30 @@ static void console_callback(struct work
release_console_sem();
}
-void set_console(int nr)
+extern char vt_dont_switch;
+
+int set_console(int nr)
{
+ struct vc_data *vc = vc_cons[fg_console].d;
+
+ if(!vc_cons_allocated(nr) || vt_dont_switch ||
there should be space between if and (.
diff -rup linux-2.6.20.1/drivers/char/vt_ioctl.c
linux/drivers/char/vt_ioctl.c
--- linux-2.6.20.1/drivers/char/vt_ioctl.c2007-02-19 22:34:32.0
-0800
+++ linux/drivers/char/vt_ioctl.c 2007-03-08 14:15:41.0
And your mailer still wordwraps.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...
On Sat, 10 Mar 2007, Nicholas Miell wrote: I never complained about one timer per fd (although, now that you mention it, that would get a bit excessive if you have thousands of outstanding timers). Right, of course. The real-time and monotonic selection can be added. IOW, the timerfd patch is not suitable for inclusion as-is. (While you're at it, you should probably add a flags argument for future expansion.) That's already in. If you look at the posix timers code, that's a bunch of code over the real meat of it, that is hrtimer.c. The timerfd interface goes straight to that, without adding yet another meaning to the sigevent structure, That's what the sigevent structure is for -- to describe how events should be signaled to userspace, whether by signal delivery, thread creation, or queuing to event completion ports. If if you think extending it would be bad, I can show you the line in POSIX where it encourages the contrary. I'm sorry, I already explained you that linking the two (files and posix timers) is going to create more troubles than it actually solves. The timerfd code provides the same functionality, with zero intrusion in existing code, and basically zero code (once if you remove the usual fd creation/cleanup). The code of adding posix timers support would be *all* the existing one (that is already a thin wrapper that calls hrtimer.c support - like posix timers do), plus adding more crud into the posix timers code, plus adding file references handling. If *you* want to do that, I can open you a door into the timerfd. - Davide - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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][RSDL-mm 0/6] Rotating Staircase DeadLine scheduler for -mm
On Sunday 11 March 2007 03:53, Nicolas Mailhot wrote: Le dimanche 11 mars 2007 à 01:03 +1100, Con Kolivas a écrit : On Saturday 10 March 2007 22:49, Nicolas Mailhot wrote: Oops ⇒ http://bugzilla.kernel.org/show_bug.cgi?id=8166 Thanks very much. I can't get your config to boot on qemu, but could you please try this debugging patch? It's not a patch you can really run the machine with but might find where the problem occurs. Specifically I'm looking for the warning MISSING STATIC BIT in your case. http://ck.kolivas.org/patches/crap/sched-rsdl-0.28-stuff.patch I attached a screenshot of the patched kernel boot Thanks. Darn the debugging didn't catch anything. Did you see any BUG during the boot earlier than that screenshot? Probably not. If you have the time I would appreciate you testing 2.6.20 with the rsdl 0.28 patch for it with a config as close to this -mm2 one as possible. http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched-rsdl-0.28.patch and see if the bug recurs please? Thanks! -- -ck - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 6/9] signalfd/timerfd v1 - timerfd core ...
On Sat, 10 Mar 2007, Nicholas Miell wrote: Care to elaborate on why they're a horrible crock? It's a *classic* case of an interface that tries to do everything under the sun. Here's a clue: look at any system call that takes a union as part of its arguments. Count them. I think we have two: - struct siginfo - struct sigevent and they are both broken horrible interfaces where the data structures depend on various flags. It's just not the UNIX system call way. And none of it really makes sense if you already have a file descriptor, since at that point you know what the notification mechanism is. I'd actually much rather do POSIX timers the other way around: associate a generic notification mechanism with the file descriptor, and then implement posix_timer_create() on top of timerfd. Now THAT sounds like a clean unix-like interface (everything is a file) and would imply that you'd be able to do the same kind of notification for any file descriptor, not just timers. But posix timers as they are done now are just an abomination. They are not unix-like at all. And are the bugs fixed? If so, why replace them? They work now. .. but the reason for the bugs was largely a very baroque interface, which didn't get fixed (because it's specified by the standard). I'd rather have straightforward interfaces. The timerfd() one lookedalot more straightforward than posix timers. (That said, using struct itimerspec might be a good idea. That would also obviate the need for TFD_TIMER_SEQ, since an itimerspec automatically has both base and incremental parts). 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: PROBLEM: Make nenuconfig does not save parameters.
On Sat, Mar 10, 2007 at 10:34:41PM +0100, Jan Engelhardt wrote: On Mar 10 2007 22:27, Sam Ravnborg wrote: On Sat, Mar 10, 2007 at 07:23:41PM +0100, Jan Engelhardt wrote: Whether the 'working config file path' should change when you do 'Save as Alternate' or not, is a menuconfig axiom. Ask Sam Ravnborg if you want it changed :-) Current behaviour is not logical but on the other hand I do not see a big need to make it so. It seems that people very seldom uses save alternate anyway. But patches are welcome. ^_^ The patch has already been posted, has not it? No. Either we keep current behaviour or we change to the normal behaviour with a Save as... as know from all other programs. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem: cat /dev/my_ttyS0 is not blocked
On Saturday 10 March 2007 13:16, Mockern wrote: I have a problem with cat /dev/my_ttyS0 (see strace output below). cat function is not blocked. I don't understand why it is not stopped at read(0, __ and terminated? Thank you Because /dev/my_ttyS0 is probaly a null file. Please show output of 'ls -l /dev/*ttyS*' -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3-mm1 RSDL results
On Sunday 11 March 2007 04:01, James Cloos wrote: Con == Con Kolivas [EMAIL PROTECTED] writes: Con It's sad that sched_yield is still in our graphics card drivers ... I just did a recursive grep(1) on my mirror of the freedesktop git repos for sched_yield. This only checked the master branches as I did not bother to script up something to clone each, check out all branches in turn, and grep(1) each possibility. The output is just: :; grep -r sched_yield FDO/xorg FDO/xorg/xserver/hw/kdrive/via/viadraw.c: sched_yield(); FDO/xorg/driver/xf86-video-glint/src/pm2_video.c:if (sync) /* sched_yield? */ Is there something else I should grep(1) for? If not, it looks as if sched_yield(2) has been evicted from the drivers. See: http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/r200/r200_ioctl.c?revision=1.37view=markup -- -ck - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Configuration generic drivers at runtime
Hi everybody, I'm writing a Linux driver for USB Video Class (UVC) devices. Before submitting it to the kernel, there are still a few rough corners I'd like to polish. Comments would be appreciated for the following one. The UVC spec defines a way for device vendors to provide extensions to the standard through so-called extension units, identified by a GUID (Globally Unique IDentifier). An extension unit can define any number of controls (think of controls as simple parameters such as brightness, zoom, pan/tilt, shutter speed, ...). Devices advertise in their USB descriptors the extension units they support, along with the controls that are supported in each extension unit. To access those extension units from user-space, the UVC driver will offer two methods. One of them will map the controls defined by extension units to V4L2 controls. The question that arises is how to define and store those mappings. And obvious solution would be to have an ever growing array in the driver, storing control information for all possible extension units ever defined by webcam vendors. While this is quite straightforward, it might not be the most usable solution for device vendors who wouldn't want debug controls to be included in the kernel by default, or who wouldn't want to submit new control definitions for inclusion in the kernel (with the implied delay) every time a new device comes out. Another solution would be to introduce a way to define controls and mappings at runtime. Mappings would be stored in test-based user-space configuration files, distributed by vendors. A small user-space utility would add them through a few ioctls. This obviously raises some security concerns (regarding which users will be allowed to add mappings, or how many of them they can add). I would like comments regarding the second solution. Is this something that is likely to be accepted in the mainline kernel ? I don't know of any other Linux driver implementing such kind of dynamic runtime configuration. Best regards, Laurent Pinchart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3-mm1 RSDL results
On Sunday 11 March 2007 05:21, Mark Lord wrote: Con Kolivas wrote: On Saturday 10 March 2007 05:07, Mark Lord wrote: Mmm.. when it's good, it's *really* good. My desktop feels snappier and all of that. .. But when it's bad, it stinks. Like when a make -j2 kernel rebuild is happening in a background window And that's bad. When you say it stinks is it more than 3 times slower? It should be precisely 3 times slower under that load (although low cpu using things like audio wont be affected by running 3 times slower). If it feels like much more than that much slower, there is a bug there somewhere. Scrolling windows is incredibly jerkey, and very very sluggish when images are involved (eg. a large web page in firefox). As another reader suggested, how does it run with the compile 'niced'? How does it perform with make (without a -j number). Yes, it behaves itself when the make -j2 is nice'd. This is on a Pentium-M 760 single-core, w/2GB SDRAM (notebook). What HZ are you running? Are you running a Beryl desktop? HZ==1000, NO_HZ, Kubunutu Dapper Drake distro, ATI X300 open-source X.org driver. Can you try the new version of RSDL. Assuming it doesn't oops on you it has some accounting bugfixes which may have been biting you. Thanks -- -ck - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3-mm1 RSDL results
On Sunday 11 March 2007 10:34, Con Kolivas wrote: On Sunday 11 March 2007 05:21, Mark Lord wrote: Con Kolivas wrote: On Saturday 10 March 2007 05:07, Mark Lord wrote: Mmm.. when it's good, it's *really* good. My desktop feels snappier and all of that. .. But when it's bad, it stinks. Like when a make -j2 kernel rebuild is happening in a background window And that's bad. When you say it stinks is it more than 3 times slower? It should be precisely 3 times slower under that load (although low cpu using things like audio wont be affected by running 3 times slower). If it feels like much more than that much slower, there is a bug there somewhere. Scrolling windows is incredibly jerkey, and very very sluggish when images are involved (eg. a large web page in firefox). As another reader suggested, how does it run with the compile 'niced'? How does it perform with make (without a -j number). Yes, it behaves itself when the make -j2 is nice'd. This is on a Pentium-M 760 single-core, w/2GB SDRAM (notebook). What HZ are you running? Are you running a Beryl desktop? HZ==1000, NO_HZ, Kubunutu Dapper Drake distro, ATI X300 open-source X.org driver. Can you try the new version of RSDL. Assuming it doesn't oops on you it has some accounting bugfixes which may have been biting you. Oh I just checked the mesa repo for that driver as well. It seems the r300 drivers have sched_yield in them as well, but not all components. You may be getting bitten by this too. http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/r300/radeon_ioctl.c?revision=1.14view=markup I don't really know what the radeon and other models are so I'm not sure if it applies to your hardware; I just did a random search through the r300 directory. -- -ck - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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: Make nenuconfig does not save parameters.
On Mar 10 2007 23:45, Sam Ravnborg wrote: On Sat, Mar 10, 2007 at 07:23:41PM +0100, Jan Engelhardt wrote: Whether the 'working config file path' should change when you do 'Save as Alternate' or not, is a menuconfig axiom. Ask Sam Ravnborg if you want it changed :-) Current behaviour is not logical but on the other hand I do not see a big need to make it so. It seems that people very seldom uses save alternate anyway. But patches are welcome. ^_^ The patch has already been posted, has not it? No. http://lkml.org/lkml/2007/3/10/163 ? Not that I have tried it personally. Either we keep current behaviour or we change to the normal behaviour with a Save as... as know from all other programs. Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RSDL v0.28 for 2.6.20
On Sunday 11 March 2007 06:11, Willy Tarreau wrote: On Sat, Mar 10, 2007 at 01:09:35PM -0500, Stephen Clark wrote: Con Kolivas wrote: Here is an update for RSDL to version 0.28 Full patch: http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched-rsdl-0.28. patch Series: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/ The patch to get you from 0.26 to 0.28: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26- 0.28.patch A similar patch and directories will be made for 2.6.21-rc3 without further announcement doesn't apply against 2.6.20.2: patch -p1 ~/2.6.20-sched-rsdl-0.28.patch --dry-run patching file include/linux/list.h patching file fs/proc/array.c patching file fs/pipe.c patching file include/linux/sched.h patching file include/asm-generic/bitops/sched.h patching file include/asm-s390/bitops.h patching file kernel/sched.c Hunk #41 FAILED at 3531. 1 out of 62 hunks FAILED -- saving rejects to file kernel/sched.c.rej patching file include/linux/init_task.h patching file Documentation/sched-design.txt It is easier to apply 2.6.20.2 on top of 2.6.20+RSDL. The .2 patch is a one-liner that you can easily fix by hand, and I'm not even certain that it is still required : --- ./kernel/sched.c.orig 2007-03-10 13:03:51 +0100 +++ ./kernel/sched.c 2007-03-10 13:08:02 +0100 @@ -3544,7 +3544,7 @@ next = list_entry(queue-next, struct task_struct, run_list); } - if (dependent_sleeper(cpu, rq, next)) + if (rq-nr_running == 1 dependent_sleeper(cpu, rq, next)) next = rq-idle; switch_tasks: if (next == rq-idle) BTW, Con, I think that you should base your work on 2.6.20.[23] and not 2.6.20 next time, due to this conflict. It will get wider adoption. Gotcha. This bugfix for 2.6.20.2 was controversial anyway so it probably wont hurt if you dont apply it. Has anyone had any trouble with RSDL on the stable kernels (ie not -mm)? -- -ck - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 rsdl fix for 0.28
Here's a big bugfix for sched rsdl 0.28
---
kernel/sched.c |7 +++
1 file changed, 7 insertions(+)
Index: linux-2.6.21-rc3-mm2/kernel/sched.c
===
--- linux-2.6.21-rc3-mm2.orig/kernel/sched.c2007-03-11 11:04:38.0
+1100
+++ linux-2.6.21-rc3-mm2/kernel/sched.c 2007-03-11 11:05:46.0 +1100
@@ -3328,6 +3328,13 @@ static inline void rotate_runqueue_prior
int new_prio_level, remaining_quota = rq_quota(rq, rq-prio_level);
struct prio_array *array = rq-active;
+ /*
+* Make sure we don't have tasks still on the active array that
+* haven't run due to not preempting (merging or smp balancing)
+*/
+ if (find_next_bit(rq-dyn_bitmap, MAX_PRIO, MAX_RT_PRIO)
+ rq-prio_level)
+ return;
if (rq-prio_level MAX_PRIO - 2) {
/* Major rotation required */
struct prio_array *new_queue = rq-expired;
--
-ck
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] MMC: Clean up low voltage range handling
Clean up the handling of low voltage MMC cards.
The latest MMC and SD specs both agree that the low
voltage range is defined as 1.65-1.95V and is signified
by bit 7 in the OCR. An old Sandisk spec implied that
bits 7-0 represented voltages below 2.0V in 1V increments,
and the code was accordingly written with that expectation.
This confusion meant that host drivers attempting to support
the typical low voltage (1.8V) would set the wrong bits in
the host OCR mask (usually bits 5 and 6) resulting in the
the low voltage mode never being used.
This change switches the code to conform to the specs and
fixes the SDHCI driver. It also removes the explicit
defines for the host vdd and updates the SDHCI driver
to convert the bit number back to the mask value
for comparisons. Having only a single set of defines
ensures there's nothing to get out of sync.
Signed-off-by: Philip Langdale [EMAIL PROTECTED]
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index c87ce56..74ebd97 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -317,6 +317,24 @@ static u32 mmc_select_voltage(struct mmc
{
int bit;
+ /*
+* Sanity check the voltages that the card claims to
+* support.
+*/
+ if (ocr 0x7F) {
+ printk(%s: card claims to support voltages below
+ the defined range. These will be ignored.\n,
+ mmc_hostname(host));
+ ocr = ~0x7F;
+ }
+
+ if (host-mode == MMC_MODE_SD (ocr MMC_VDD_165_195)) {
+ printk(%s: SD card claims to support the incompletely
+ defined 'low voltage range'. This will be ignored.\n,
+ mmc_hostname(host));
+ ocr = ~MMC_VDD_165_195;
+ }
+
ocr = host-ocr_avail;
bit = ffs(ocr);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 86d0957..a80c043 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -668,20 +668,16 @@ static void sdhci_set_power(struct sdhci
pwr = SDHCI_POWER_ON;
- switch (power) {
- case MMC_VDD_170:
- case MMC_VDD_180:
- case MMC_VDD_190:
+ switch (1 power) {
+ case MMC_VDD_165_195:
pwr |= SDHCI_POWER_180;
break;
- case MMC_VDD_290:
- case MMC_VDD_300:
- case MMC_VDD_310:
+ case MMC_VDD_29_30:
+ case MMC_VDD_30_31:
pwr |= SDHCI_POWER_300;
break;
- case MMC_VDD_320:
- case MMC_VDD_330:
- case MMC_VDD_340:
+ case MMC_VDD_32_33:
+ case MMC_VDD_33_34:
pwr |= SDHCI_POWER_330;
break;
default:
@@ -1293,7 +1289,7 @@ static int __devinit sdhci_probe_slot(st
if (caps SDHCI_CAN_VDD_300)
mmc-ocr_avail |= MMC_VDD_29_30|MMC_VDD_30_31;
if (caps SDHCI_CAN_VDD_180)
- mmc-ocr_avail |= MMC_VDD_17_18|MMC_VDD_18_19;
+ mmc-ocr_avail |= MMC_VDD_165_195;
if (mmc-ocr_avail == 0) {
printk(KERN_ERR %s: Hardware doesn't report any
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 43bf6a5..89dbb91 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -16,30 +16,7 @@ struct mmc_ios {
unsigned intclock; /* clock rate */
unsigned short vdd;
-#defineMMC_VDD_150 0
-#defineMMC_VDD_155 1
-#defineMMC_VDD_160 2
-#defineMMC_VDD_165 3
-#defineMMC_VDD_170 4
-#defineMMC_VDD_180 5
-#defineMMC_VDD_190 6
-#defineMMC_VDD_200 7
-#defineMMC_VDD_210 8
-#defineMMC_VDD_220 9
-#defineMMC_VDD_230 10
-#defineMMC_VDD_240 11
-#defineMMC_VDD_250 12
-#defineMMC_VDD_260 13
-#defineMMC_VDD_270 14
-#defineMMC_VDD_280 15
-#defineMMC_VDD_290 16
-#defineMMC_VDD_300 17
-#defineMMC_VDD_310 18
-#defineMMC_VDD_320 19
-#defineMMC_VDD_330 20
-#defineMMC_VDD_340 21
-#defineMMC_VDD_350 22
-#defineMMC_VDD_360 23
+/* vdd stores the bit number of the selected voltage range from protocol.h */
unsigned char bus_mode; /* command output mode */
@@ -88,14 +65,7 @@ struct mmc_host {
unsigned intf_max;
u32 ocr_avail;
-#define MMC_VDD_145_1500x0001 /* VDD voltage 1.45 -
1.50 */
-#define MMC_VDD_150_1550x0002 /* VDD voltage 1.50 -
1.55 */
-#define MMC_VDD_155_1600x0004 /* VDD voltage 1.55 -
1.60 */
-#define MMC_VDD_160_1650x0008 /* VDD voltage 1.60 -
1.65 */
-#define MMC_VDD_165_1700x0010 /* VDD voltage 1.65 -
1.70 */
-#define
Re: [PATCH] proc: maps protection
On Sat, 10 Mar 2007 10:33:41 -0800 Kees Cook [EMAIL PROTECTED] wrote: Here's another revision, with both the can ptrace and the global /proc knob; We'd be needing a changelog for that. Please update the procfs documentation. Does the patch also cover /proc/pid/smaps? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
