Re: sata sil3114 vs. certain seagate drives results in filesystem corruptions
On Mon, 2007-10-22 at 11:12 +0900, Tejun Heo wrote: > Helo, > > Soeren Sonnenburg wrote: > > I finally managed to find a *reproducible* setup and way to trigger > > random corruptions using a sata sil 3114 controller connected to 4 > > seagate drives > > > > port 1: ST3400832AS sda > > port 2: ST3400620AS sdb > > port 3: ST3750640AS sdc > > port 4: ST3750640AS sdd > > > > sda & sdb form md0 via a raid1 setup followed by an additional > > devicemapper layer ( root ). sdc and sdb are separate and also have an > > additional device mapper layer ( public ) and ( backups ). > > > > Now when I write large files of zeros to root(sda) and read the file > > back in it contains a few nonzero entries: > > > > # dd if=/dev/zero of=/foo bs=1M count=2000 > > # hexdump /foo > > 000 > > * > > 1GB random parts, within large blocks of zeroes> > > > > I can reliably trigger this on the md0 / devmapper-root setup when I > > write about 2GB of data (note that this machine has 1.5G of memory - and > > still 1GB is often enough to see this problem). Here it does not matter > > where in the filesystem I do these writes. > > Thanks. I'll try to reproduce the problem here. What's your motherboard? It is an asus a7v8x with a AMD Athlon(TM) XP 3000+ and admittingly almost completely filled pci slots (4 dvb cards, 1 with the sil3114; 1 empty; in the agp slot a radeon 9200). Nevertheless I would not expect the power supply to be the problem (it got replaced recently by a 500W one), enough cooling (it is winter in germany + several fans). > > Now promise_sata is converted to new EH, so I simply gave it a go, i.e. > > I attached ST3400832AS and ST3400620AS to the promise controller and > > rebooted and redid the experiments from above. > > > > No data corruptions whatsoever. I even ran the dd on all three devmapped > > mount points simultaneously with a size of 30GB each, still no > > corruption. However the error messages I've seen a year ago are back for > > the ST3400832AS and ST3400620AS attached to the promise controller (see > > below). > [--snip--] > > ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x100 action 0x2 > > ata1.00: port_status 0x2020 > > ata1.00: cmd 25/00:00:c0:b6:74/00:01:20:00:00/e0 tag 0 cdb 0x0 data 131072 > > in > > res 51/0c:00:c0:b6:74/0c:01:20:00:00/e0 Emask 0x10 (ATA bus error) > > ata1: soft resetting port > > Yeah, still the same. Your drives don't like the way promise controller > speaks to them (e.g. promise generates signals which are ) but now that > sata_promise has proper EH. It can recover from those errors. As long > as nothing worse happens, it should be okay. These errors only appear when I generate some stress (like with the dd). The machine is now up 2 days 8hrs and no further such warnings in the log. Soeren - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 free/used memory on Linux
Ravinandan Arakali (rarakali) wrote: > Hi Vaidy, > Thanks for clarifying several of my doubts. > > To answer your question about my intention, we currently have a > system with 2 GB RAM and I need to find out the actual used and > free memory so that we can decide if the same setup(applications, > tmpfs etc.) can run on another system with lesser memory. > > Is it correct to say that the "used" field "free -m" excluding > buffers/caches would give the correct idea of used memory > (I mean does it take care of shared memory, shared copies of > libraries etc.) ? I assume it does not include /dev/shm usage > since that's also a tmpfs partition ? Thats correct. The used excluding the buffer caches gives most of the memory used by the system. You have excludes _all_ file backed memory including shm. > > If so, then I can add the memory used by tmpfs partitions to > the above and get the total memory used ? > > For eg. if my "free -m" appears as below: > Linux(debug)# free -m > total used free sharedbuffers > cached > Mem: 2014984 1030 0 80 > 594 > -/+ buffers/cache:309 1705 > > Can I say that 309MB + 350 MB(size of tmpfs partitions including > /dev/shm) > is the used memory on my system ? Two problems with this logic: 1. all of tmpfs may not be really used. You are over committing. 2. You still miss the pages needed to map the program code. They are file backed too. Though this will be very less amount of memory compared to data and shared memory. Let me suggest a metric: 1. Take the used part excluding the buffers (309MB) in your case and add 'Mapped' and 'Dirty' from /proc/meminfo This may be better than adding tmpfs/shmdev size. 2. Once your system is running will all applications loaded, cleanup the pagecache (file data cached in memory) sync echo 1 > /proc/sys/vm/drop_caches The first sync will bring down 'Dirty' count and drop_caches will reclaim all 'not needed' file cache memory. Now if you use 'free' and take the used count _with_ the buffers and file cache, this will provide a realistic value. (Actually Free in /proc/meminfo) Do not exclude buffers they are _needed_ for optimum system operation. With the above figure you can probably add 10% or more memory as extra memory for file cache when the system is operating with full load. If you want to be sure of these experiments boot you system with less memory using mem=xxx kernel parameter and run some performance tests to ensure the degradation is under acceptable limits. --Vaidy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [2.6 patch] fix CONFIG_TUNER_TEA5761=m
On Sun, 21 Oct 2007, Michael Krufky wrote:
> Adrian Bunk wrote:
> > This patch fixes CONFIG_TUNER_TEA5761=m broken by
> > commit ca805d57cf5ea7482ed3da28653f30621249ee45.
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > ---
> >
> > drivers/media/video/tuner-core.c |6 --
> > 1 file changed, 6 deletions(-)
> >
> > 26336c30e76c37bda368a24b8b12978388a18cf3
> > diff --git a/drivers/media/video/tuner-core.c
> > b/drivers/media/video/tuner-core.c
> > index 9484308..1795b78 100644
> > --- a/drivers/media/video/tuner-core.c
> > +++ b/drivers/media/video/tuner-core.c
> > @@ -30,9 +30,7 @@
> >
> > /* standard i2c insmod options */
> > static unsigned short normal_i2c[] = {
> > -#ifdef CONFIG_TUNER_TEA5761
> > 0x10,
> > -#endif
> >
> ^^^ I believe that we want to keep these #ifdef's above... The removals
> below are fine.
Won't leaving in the call to tea5761_autodetection() when tea5761 is not
compiled in result in an undefined symbol error?
I think what we want to do put in the typical if(TEA5761 >= TUNER) include
tea5761
code in tuner logic that the rest of the selectable sub-driver use.
#if defined(CONFIG_TUNER_TEA5761) || (defined(CONFIG_TUNER_TEA5761_MODULE) &&
defined(MODULE))
Of course compiling TEA5761 lower than TUNER doesn't make any sense now
since the only thing that uses tea5761 is the tuner. But it's still
possible, you just end up with a tuner that doesn't support tea5761 and a
tea5761 module that isn't needed by anything.
>
>
> > 0x42, 0x43, 0x4a, 0x4b, /* tda8290 */
> > 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
> > 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
> > @@ -292,7 +290,6 @@ static void set_type(struct i2c_client *c, unsigned int
> > type,
> > }
> > t->mode_mask = T_RADIO;
> > break;
> > -#ifdef CONFIG_TUNER_TEA5761
> > case TUNER_TEA5761:
> > if (tea5761_attach(>fe, t->i2c.adapter, t->i2c.addr) ==
> > NULL) {
> > t->type = TUNER_ABSENT;
> > @@ -301,7 +298,6 @@ static void set_type(struct i2c_client *c, unsigned int
> > type,
> > }
> > t->mode_mask = T_RADIO;
> > break;
> > -#endif
> > case TUNER_PHILIPS_FMD1216ME_MK3:
> > buffer[0] = 0x0b;
> > buffer[1] = 0xdc;
> > @@ -594,7 +590,6 @@ static int tuner_attach(struct i2c_adapter *adap, int
> > addr, int kind)
> > /* autodetection code based on the i2c addr */
> > if (!no_autodetect) {
> > switch (addr) {
> > -#ifdef CONFIG_TUNER_TEA5761
> > case 0x10:
> > if (tea5761_autodetection(t->i2c.adapter, t->i2c.addr)
> > != EINVAL) {
> > t->type = TUNER_TEA5761;
> > @@ -606,7 +601,6 @@ static int tuner_attach(struct i2c_adapter *adap, int
> > addr, int kind)
> > goto register_client;
> > }
> > break;
> > -#endif
> > case 0x42:
> > case 0x43:
> > case 0x4a:
> >
> >
> Regards,
>
> Mike Krufky
>
> ___
> v4l-dvb-maintainer mailing list
> [EMAIL PROTECTED]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fs/partitions/check.c: add error handling for kobject_add
From: Borislav Petkov <[EMAIL PROTECTED]>
Add error handling to the kobject_add()-call and signal (the even highly
unlikely) error condition.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
--
diff --git a/fs/partitions/check.c b/fs/partitions/check.c
index 722e12e..5490e33 100644
--- a/fs/partitions/check.c
+++ b/fs/partitions/check.c
@@ -371,11 +371,12 @@ void delete_partition(struct gendisk *disk, int part)
void add_partition(struct gendisk *disk, int part, sector_t start, sector_t
len, int flags)
{
struct hd_struct *p;
+ int err = -EINVAL;
p = kzalloc(sizeof(*p), GFP_KERNEL);
if (!p)
return;
-
+
p->start_sect = start;
p->nr_sects = len;
p->partno = part;
@@ -390,7 +391,13 @@ void add_partition(struct gendisk *disk, int part,
sector_t start, sector_t len,
p->kobj.parent = >kobj;
p->kobj.ktype = _part;
kobject_init(>kobj);
- kobject_add(>kobj);
+
+ err = kobject_add(>kobj);
+ if (err) {
+ pr_err("%s: Error adding %s to sysfs\n", __FUNCTION__,
+ kobject_name(>kobj));
+ }
+
if (!disk->part_uevent_suppress)
kobject_uevent(>kobj, KOBJ_ADD);
sysfs_create_link(>kobj, _subsys.kobj, "subsystem");
--
Regards/Gruß,
Boris.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
On Mon, Oct 22, 2007 at 12:37:46PM +0800, WANG Cong wrote: > >Fallout continues; I've got a preliminary patch for it. Basically, we > >need to stop doing -U__i386__ et.al. > > > > Hi, Al. > > I applied your patch and recompiled the kernel. But it failed again. > ;( Details would be welcome... Notes: SMP on UML is no more; UML_NET_VDE depends on having some userland library installed. Aside of those two it ought to build. Build log on failing build would be nice, along with .config. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] INPUT/BF54x-KEYPAD driver: Remove useless line -errno returned by irq_request
On Thursday 18 October 2007, Bryan Wu wrote: > From: Michael Hennerich <[EMAIL PROTECTED]> > > Cc: Andrey Panin <[EMAIL PROTECTED]> > Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]> > Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> Applied, thank you Michael, Bryan. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Input updates for 2.6.24-rc0 (part 2)
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Changelog: - Anton Ekblad (1): Input: appletouch - apply idle reset logic to all touchpads Jerrold Jones (1): Input: usbtouchscreen - add support for GoTop tablet devices Michael Hennerich (1): Input: bf54x-keys - return real error when request_irq() fails Márton Németh (1): Input: i8042 - export i8042_command() Diffstat: drivers/input/keyboard/bf54x-keys.c|1 - drivers/input/mouse/appletouch.c | 25 --- drivers/input/serio/i8042.c|4 ++- drivers/input/serio/i8042.h| 22 - drivers/input/touchscreen/Kconfig |6 drivers/input/touchscreen/usbtouchscreen.c | 36 ++- include/linux/i8042.h | 35 +++ 7 files changed, 89 insertions(+), 40 deletions(-) create mode 100644 include/linux/i8042.h -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] return hidden bug
On Mon, Oct 22, 2007 at 01:42:09AM +, Rik van Riel wrote:
>
> BUG() will terminate the process that runs into it, so you can
> just remove the return alltogether. If BUG() is hit, the return
> will never be reached.
This is true in general. However, if someone builds the kernel
with CONFIG_BUG disabled then the return statement will make a
difference. Of course, if you're brave enough to have CONFIG_BUG
off then you can deal with the fall-out :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/4] Replace per-subsystem mutexes with get_online_cpus
On Sun, Oct 21, 2007 at 03:39:17PM +0400, Oleg Nesterov wrote:
> On 10/16, Gautham R Shenoy wrote:
> >
> > This patch converts the known per-subsystem cpu_hotplug mutexes to
> > get_online_cpus put_online_cpus.
> > It also eliminates the CPU_LOCK_ACQUIRE and CPU_LOCK_RELEASE hotplug
> > notification events.
>
> Personally, I like the changes in workqueue.c very much, a couple of
> minor nits below.
>
> > --- linux-2.6.23.orig/kernel/workqueue.c
> > +++ linux-2.6.23/kernel/workqueue.c
> > @@ -592,8 +592,6 @@ EXPORT_SYMBOL(schedule_delayed_work_on);
> > * Returns zero on success.
> > * Returns -ve errno on failure.
> > *
> > - * Appears to be racy against CPU hotplug.
> > - *
>
> see below,
>
> > * schedule_on_each_cpu() is very slow.
> > */
> > int schedule_on_each_cpu(work_func_t func)
> > @@ -605,7 +603,7 @@ int schedule_on_each_cpu(work_func_t fun
> > if (!works)
> > return -ENOMEM;
> >
> > - preempt_disable(); /* CPU hotplug */
> > + get_online_cpus(); /* CPU hotplug */
> > for_each_online_cpu(cpu) {
> > struct work_struct *work = per_cpu_ptr(works, cpu);
> >
> > @@ -613,7 +611,7 @@ int schedule_on_each_cpu(work_func_t fun
> > set_bit(WORK_STRUCT_PENDING, work_data_bits(work));
> > __queue_work(per_cpu_ptr(keventd_wq->cpu_wq, cpu), work);
> > }
> > - preempt_enable();
> > + put_online_cpus();
> > flush_workqueue(keventd_wq);
>
> Still racy. To kill the race, please move flush_workqueue() up, before
> put_online_cpus().
>
> > @@ -809,6 +809,7 @@ void destroy_workqueue(struct workqueue_
> > struct cpu_workqueue_struct *cwq;
> > int cpu;
> >
> > + get_online_cpus();
> > mutex_lock(_mutex);
> > list_del(>list);
> > mutex_unlock(_mutex);
> > @@ -817,6 +818,7 @@ void destroy_workqueue(struct workqueue_
> > cwq = per_cpu_ptr(wq->cpu_wq, cpu);
> > cleanup_workqueue_thread(cwq, cpu);
> > }
> > + put_online_cpus();
>
> Correct, but I'd suggest to do put_online_cpus() earlier, right after
> mutex_unlock(_mutex).
>
> > @@ -830,22 +832,17 @@ static int __devinit workqueue_cpu_callb
> > unsigned int cpu = (unsigned long)hcpu;
> > struct cpu_workqueue_struct *cwq;
> > struct workqueue_struct *wq;
> > + int ret = NOTIFY_OK;
> >
> > action &= ~CPU_TASKS_FROZEN;
> >
> > switch (action) {
> > - case CPU_LOCK_ACQUIRE:
> > - mutex_lock(_mutex);
> > - return NOTIFY_OK;
> > -
> > - case CPU_LOCK_RELEASE:
> > - mutex_unlock(_mutex);
> > - return NOTIFY_OK;
> >
>
> please remove this emtpy line
>
> > case CPU_UP_PREPARE:
> > cpu_set(cpu, cpu_populated_map);
> > }
> >
> > + mutex_lock(_mutex);
>
> We don't need workqueue_mutex here. With your patch workqueue_mutex protects
> list_head, nothing more. But all other callers (create/destroy) should take
> get_online_cpus() anyway. This means that we can convert workqueue_mutex to
> spinlock_t.
Thanks for the review!
Will code these changes up in the next version and post them
sometime soon.
>
> Oleg.
>
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/4] Rename lock_cpu_hotplug to get_online_cpus
> > > > Okay. But other than pseries_add_processor and pseries_remove_processor, > > are there any other places where we _change_ the cpu_present_map ? > > Other arch code e.g. ia64 changes it for add/remove also. But I fail > to see how it matters. > > > > I agree that we need some kind of synchronization for threads which > > read the cpu_present_map. But probably we can use a seperate mutex > > for that. > > That would be needless complexity. > > > > > The naming is a problem IMO for two reasons: > > > > > > - lock_cpu_hotplug() protects cpu_present_map as well as > > > cpu_online_map (sigh, I see that Documentation/cpu-hotplug.txt > > > disagrees with me, but my statement holds for powerpc, at least). > > > > > > - get_online_cpus() implies reference count semantics (as stated in > > > the changelog) but AFAICT it really has a reference count > > > implementation with read-write locking semantics. > > > > > > Hmm, I think there's another problem here. With your changes, code > > > which relies on the mutual exclusion behavior of lock_cpu_hotplug() > > > (such as pseries_add/remove_processor) will now be able to run > > > concurrently. Probably those functions should use > > > cpu_hotplug_begin/end instead. > > > > One of the primary reasons to move away from the mutex semantics for > > cpu-hotplug protection, was that there were a lot of places where > > lock_cpu_hotplug() was used for protecting local data structures too, > > when they had nothing to do with cpu-hotplug as such, and it resulted > > in a whole mess. It took people quite sometime to sort things out > > with the cpufreq subsystem. > > cpu_present_map isn't a "local data structure" any more than > cpu_online_map, and it is quite relevant to cpu hotplug. We have to > maintain the invariant that the set of cpus online is a subset of cpus > present. > > > Probably it would be a lot cleaner if we use get_online_cpus() for > > protection against cpu-hotplug and use specific mutexes for serializing > > accesses to local data structures. Thoughts? > > I don't feel like I'm getting through here. Let me restate. > > If I'm reading them correctly, these patches are changing the behavior > of lock_cpu_hotplug() from mutex-style locking to a kind of read-write > locking. I think that's fine, but the naming of the new API poorly > reflects its real behavior. Conversion of lock_cpu_hotplug() users > should be done with care. Most of them - those that need one of the > cpu maps to remain unchanged during a critical section - can be > considered readers. But a few (such as pseries_add_processor() and > pseries_remove_processor()) are writers, because they modify one of > the maps. > > So, why not: > > get_cpus_online -> cpumaps_read_lock > put_cpus_online -> cpumaps_read_unlock > cpu_hotplug_begin -> cpumaps_write_lock > cpu_hotplug_end -> cpumaps_write_unlock > > Or something similar? Hi Nathan, I totally see your point and agree with it. However, though the new implementation appears to have a read-write-semaphore behaviour it differs in following aspects: a) This implementation allows natural recursion of reads, just as in the case of preempt_count. This is not possible in case of a normal read-write lock because if you have something like the following in a timeline, R1 -- > R2--> W3 --> R1, where Ri is a read by a thread i and Wi is a write by a thread i, then thread1 will deadlock as it will be blocked behind W3, holding the semaphore. b) Regular Reader Writer semaphores are fair. As in if a new reader arrives when a writer is already present, the new reader waits until the writer in front of it finishes. But, in the new implementation, the new reader will proceed as long as the refcount is non-zero, and the writer will get to run only when the number of readers = 0. However, the readers which arrive when the writer is executing, will block until the writer is done. Because of these properties, the implementation is more similar to the refcounting, except that it allows the new bunch of readers to sleep during an ongoing write. Like you pointed out, since the code of pseries_add_processor and other places where the cpu_present_map is being changed during the runtime requires write protection, how if the cpu_hotplug_begin/cpu_hotplug_end support is made available outside cpu.c and appropriately named ? Personally I would propose the following names to reflect the behaviour, but if the community is okay with the word "lock" in the API's I don't have any problems renaming them to what you've suggested. /* * Api's which ensure that the cpu_present_map and the cpu_online_map * do not change while operating in a critical section. */ get_cpu_maps(); put_cpu_maps(); /* * Api's to serialize the updates to the cpu_present_map/cpu_online_map. */ cpu_map_update_begin(); cpu_map_update_done(); Thanks and Regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India.
Re: Interaction between Xen and XFS: stray RW mappings
On Monday 22 October 2007 14:28, dean gaudet wrote: > On Sun, 21 Oct 2007, Jeremy Fitzhardinge wrote: > > dean gaudet wrote: > > > On Mon, 15 Oct 2007, Nick Piggin wrote: > > >> Yes, as Dave said, vmap (more specifically: vunmap) is very expensive > > >> because it generally has to invalidate TLBs on all CPUs. > > > > > > why is that? ignoring 32-bit archs we have heaps of address space > > > available... couldn't the kernel just burn address space and delay > > > global TLB invalidate by some relatively long time (say 1 second)? > > > > Yes, that's precisely the problem. xfs does delay the unmap, leaving > > stray mappings, which upsets Xen. > > sounds like a bug in xen to me :) You could call it a bug I think. I don't know much about Xen though, whether or not it expects to be able to run an arbitrary OS kernel. Presumably, the hypervisor _could_ write protect and trap writes to *all* page table page mappings. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tristate and bool not enogh for Kconfig anymore
On Sun, 21 Oct 2007 20:14:16 -0700 Randy Dunlap wrote: > On Sun, 21 Oct 2007 17:47:48 -0700 Randy Dunlap wrote: > > > On Sun, 21 Oct 2007 23:03:13 +0200 Sam Ravnborg wrote: > > > > > On Sun, Oct 21, 2007 at 09:45:17AM -0700, Randy Dunlap wrote: > > > > > Is there any other way to specify that a functionality can only be > > > > > built > > > > > as a module, not built into the kernel? > > > > > > > > config FOO > > > > depends on BAR && m > > > > > > > > restricts FOO to module-only. > > > > > > > > > In my firsta attempts to post about these tests my post ended up not > > > > > on > > > > > the mailing list but as a reply to Sam Ravnborg only, apologies for > > > > > that... > > > > > > This is obviously the right solution. > > > Randy - we should document this somewhere together with more kconfig > > > tips'n'tricks. > > > > Agreed. > > So that's one tip or trick... or common idiom. > > > > A new document or do we extend kconfig-language? > > > > I don't see a need for a separate document. I would just extend > > kconfig-language. > > ~ > Another common idiom that we see (and sometimes have problems > with) is this: > > When B (module or subsystem) uses interfaces from A (module or > subsystem), A can be linked statically into the kernel image or > can be built as loadable module(s). This limits how B can be > built. If A is linked statically into the kernel image, B can be > built statically or as loadable module(s). However, if A is built > as loadable module(s), then B must be restricted to loadable > module(s) also. This can be expressed in kconfig language as: > > config B > depends on A = y || A = B > > > ~~~ > There's also a third issue: symbols that are specific to a > particular $arch, but they are in Kconfig files that are common > to all arches, so kconfig complains about symbol A refers to > unknown symbol B. (and I'm just writing this from memory, not > from testing it, so it could be off a bit.) One example of this > was PS3_PS3AV, as copied from an lkml email of 2007-feb-14: > > drivers/video/Kconfig:1604:warning: 'select' used by config symbol > 'FB_PS3' refer to undefined symbol 'PS3_PS3AV' > > Someone fixed this one by introducing an intermediate config symbol. > I didn't follow the details of that fix, but we see this problem > enough to warrant explaining how to handle it. E.g., recently > (from 2007-oct-14) on lkml: > > $ make oldconfig >/dev/null > drivers/macintosh/Kconfig:121:warning: 'select' used by config > symbol 'PMAC_APM_EMU' refers to undefined symbol 'APM_EMULATION' > > > > Adrian, do you know of other items that should be listed here? ~ Continuing with real-life kconfig fun, here's a fourth item that people need to be aware of. The construct: if ARCH_OMAP source "drivers/video/omap/Kconfig" endif does not prevent kconfig from reading drivers/video/omap/Kconfig. Instead, it make all config symbols in that file be dependent upon the ARCH_OMAP symbol. Adding a config symbol dependency like this is a common problem that causes config menus not to be displayed as they should be (not indented or not subordinate as expected). --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.
On Sun, Oct 21, 2007 at 04:43:46PM +0100, Al Viro wrote: >On Sun, Oct 21, 2007 at 09:20:32PM +0800, WANG Cong wrote: >> On Sun, Oct 21, 2007 at 09:08:48AM -0400, Jeff Dike wrote: >> >On Sun, Oct 21, 2007 at 07:48:54PM +0800, WANG Cong wrote: >> >> UML still doesn't build on 2.6.23-git16. >> >> >> >> Gcc threw out many errors, I put them in the web: >> >> http://wangcong.org/down/errors.txt >> > >> >Looks like either you need to run mrproper and try again, or maybe >> >fallout from the x86 merge, with include/asm-um/arch pointing to >> >include/asm-i386 instead of include/asm-x86. Although I though Al had >> >UML building in the presence of the x86 merge. >> > >> >> Hi, Jeff! >> >> I have tried `make mrproper' before `make ARCH=um', but it still >> failed. ;( > >Fallout continues; I've got a preliminary patch for it. Basically, we >need to stop doing -U__i386__ et.al. > Hi, Al. I applied your patch and recompiled the kernel. But it failed again. ;( Regards. WANG Cong - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interaction between Xen and XFS: stray RW mappings
On Sun, 21 Oct 2007, Jeremy Fitzhardinge wrote: > dean gaudet wrote: > > On Mon, 15 Oct 2007, Nick Piggin wrote: > > > > > >> Yes, as Dave said, vmap (more specifically: vunmap) is very expensive > >> because it generally has to invalidate TLBs on all CPUs. > >> > > > > why is that? ignoring 32-bit archs we have heaps of address space > > available... couldn't the kernel just burn address space and delay global > > TLB invalidate by some relatively long time (say 1 second)? > > > > Yes, that's precisely the problem. xfs does delay the unmap, leaving > stray mappings, which upsets Xen. sounds like a bug in xen to me :) -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] unlock before bug returns
On Mon, 22 Oct 2007 04:58:45 +0200
Roel Kluin <[EMAIL PROTECTED]> wrote:
> Roel Kluin wrote:
>
> > unlock before bug returns
>
> > if (cs >= GPMC_CS_NUM || !gpmc_cs_reserved(cs)) {
> > printk(KERN_ERR "Trying to free non-reserved GPMC
> > CS%d\n", cs);
> > - BUG();
> > spin_unlock(_mem_lock);
> > - return;
> > + BUG();
>
>
> should we bother to unlock before panicking, or is the unlock not
> required either?
BUG() kills the current process, but not the whole system.
Unlocking the lock means that the rest of the system has somewhat
of a chance of surviving. Not unlocking means a guaranteed hang
for the rest of the system, making a BUG() no better than panic.
Please keep the unlock.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] IPMI: fix comparison in demangle_device_id
From: Corey Minyard <[EMAIL PROTECTED]>
Coverity spotted some incorrect code in a recent change to the IPMI
driver; this patch make sure the data is really long enough to pull
the manufacturer id and product id out of a get device id message.
Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
Cc: Adrian Bunk <[EMAIL PROTECTED]>
Cc: Stian Jordet <[EMAIL PROTECTED]>
---
Index: linux-2.6.23/include/linux/ipmi_smi.h
===
--- linux-2.6.23.orig/include/linux/ipmi_smi.h
+++ linux-2.6.23/include/linux/ipmi_smi.h
@@ -173,7 +173,7 @@ static inline int ipmi_demangle_device_i
id->firmware_revision_2 = data[3];
id->ipmi_version = data[4];
id->additional_device_support = data[5];
- if (data_len >= 6) {
+ if (data_len >= 11) {
id->manufacturer_id = (data[6] | (data[7] << 8) |
(data[8] << 16));
id->product_id = data[9] | (data[10] << 8);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] procfs: fix kernel-doc param warnings
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix mnt_flush_task() misplaced kernel-doc.
Fix typos in some of the doc text.
Warning(linux-2.6.23-git17//fs/proc/base.c:2280): No description found for
parameter 'mnt'
Warning(linux-2.6.23-git17//fs/proc/base.c:2280): No description found for
parameter 'pid'
Warning(linux-2.6.23-git17//fs/proc/base.c:2280): No description found for
parameter 'tgid'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
fs/proc/base.c | 46 ++
1 file changed, 22 insertions(+), 24 deletions(-)
--- linux-2.6.23-git17.orig/fs/proc/base.c
+++ linux-2.6.23-git17/fs/proc/base.c
@@ -2255,27 +2255,6 @@ static const struct inode_operations pro
.setattr= proc_setattr,
};
-/**
- * proc_flush_task - Remove dcache entries for @task from the /proc dcache.
- *
- * @task: task that should be flushed.
- *
- * Looks in the dcache for
- * /proc/@pid
- * /proc/@tgid/task/@pid
- * if either directory is present flushes it and all of it'ts children
- * from the dcache.
- *
- * It is safe and reasonable to cache /proc entries for a task until
- * that task exits. After that they just clog up the dcache with
- * useless entries, possibly causing useful dcache entries to be
- * flushed instead. This routine is proved to flush those useless
- * dcache entries at process exit time.
- *
- * NOTE: This routine is just an optimization so it does not guarantee
- * that no dcache entries will exist at process exit time it
- * just makes it very unlikely that any will persist.
- */
static void proc_flush_task_mnt(struct vfsmount *mnt, pid_t pid, pid_t tgid)
{
struct dentry *dentry, *leader, *dir;
@@ -2322,10 +2301,29 @@ out:
return;
}
-/*
- * when flushing dentries from proc one need to flush them from global
+/**
+ * proc_flush_task - Remove dcache entries for @task from the /proc dcache.
+ * @task: task that should be flushed.
+ *
+ * When flushing dentries from proc, one needs to flush them from global
* proc (proc_mnt) and from all the namespaces' procs this task was seen
- * in. this call is supposed to make all this job.
+ * in. This call is supposed to do all of this job.
+ *
+ * Looks in the dcache for
+ * /proc/@pid
+ * /proc/@tgid/task/@pid
+ * if either directory is present flushes it and all of it'ts children
+ * from the dcache.
+ *
+ * It is safe and reasonable to cache /proc entries for a task until
+ * that task exits. After that they just clog up the dcache with
+ * useless entries, possibly causing useful dcache entries to be
+ * flushed instead. This routine is proved to flush those useless
+ * dcache entries at process exit time.
+ *
+ * NOTE: This routine is just an optimization so it does not guarantee
+ * that no dcache entries will exist at process exit time it
+ * just makes it very unlikely that any will persist.
*/
void proc_flush_task(struct task_struct *task)
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] auditsc: fix kernel-doc param warnings
From: Randy Dunlap <[EMAIL PROTECTED]> Fix kernel-doc for auditsc parameter changes. Warning(linux-2.6.23-git17//kernel/auditsc.c:1623): No description found for parameter 'dentry' Warning(linux-2.6.23-git17//kernel/auditsc.c:1666): No description found for parameter 'dentry' Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- kernel/auditsc.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-2.6.23-git17.orig/kernel/auditsc.c +++ linux-2.6.23-git17/kernel/auditsc.c @@ -1615,7 +1615,7 @@ static void audit_copy_inode(struct audi /** * audit_inode - store the inode and device from a lookup * @name: name being audited - * @inode: inode being audited + * @dentry: dentry being audited * * Called from fs/namei.c:path_lookup(). */ @@ -1650,7 +1650,7 @@ void __audit_inode(const char *name, con /** * audit_inode_child - collect inode info for created/removed objects * @dname: inode's dentry name - * @inode: inode being audited + * @dentry: dentry being audited * @parent: inode of dentry parent * * For syscalls that create or remove filesystem objects, audit_inode --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface
On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote: > Yes, I think Crispin has succinctly summed it up: irrevocably closing > the LSM prevents commercial customers from using security modules other > than that provided by their Linux distributor. Any "customer" using a security model other than provided by their Linux distributor instantly voided all support from that distro by doing that. So, since the support is gone, they can easily build their own kernels, with their own LSM interfaces, and get the exact same lack of support :) And, what are these "other LSM modules" you speak of that people rely on to run their businesses? > As Sarbanes-Oxley and > other regulatory laws require these customers to use "standard > kernels", the result is a rather dreary form of vendor lock-in, where the > security framework is coupled to the distribution. Wait, what? Since when does Sarbanes-Oxley decree that a company must use a "standard kernel"? And just exactly what defines such "standard kernel"? Can you point out where in that bill it requires such a thing? Totally confused, 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: [2.6 patch] ipmi_demangle_device_id(): remove dead code
Yes, it's a problem, but wrong fix. Thanks, I'll send a patch for it.
-corey
Adrian Bunk wrote:
This patch removes obviously dead code spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/ipmi_smi.h | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
--- linux-2.6/include/linux/ipmi_smi.h.old 2007-10-21 23:03:03.0
+0200
+++ linux-2.6/include/linux/ipmi_smi.h 2007-10-21 23:05:59.0 +0200
@@ -158,44 +158,38 @@ static inline int ipmi_demangle_device_i
if (data_len < 9)
return -EINVAL;
if (data[0] != IPMI_NETFN_APP_RESPONSE << 2 ||
data[1] != IPMI_GET_DEVICE_ID_CMD)
/* Strange, didn't get the response we expected. */
return -EINVAL;
if (data[2] != 0)
/* That's odd, it shouldn't be able to fail. */
return -EINVAL;
data += 3;
data_len -= 3;
id->device_id = data[0];
id->device_revision = data[1];
id->firmware_revision_1 = data[2];
id->firmware_revision_2 = data[3];
id->ipmi_version = data[4];
id->additional_device_support = data[5];
- if (data_len >= 6) {
- id->manufacturer_id = (data[6] | (data[7] << 8) |
- (data[8] << 16));
- id->product_id = data[9] | (data[10] << 8);
- } else {
- id->manufacturer_id = 0;
- id->product_id = 0;
- }
+ id->manufacturer_id = (data[6] | (data[7] << 8) | (data[8] << 16));
+ id->product_id = data[9] | (data[10] << 8);
if (data_len >= 15) {
memcpy(id->aux_firmware_revision, data+11, 4);
id->aux_firmware_revision_set = 1;
} else
id->aux_firmware_revision_set = 0;
return 0;
}
/* Add a low-level interface to the IPMI driver. Note that if the
interface doesn't know its slave address, it should pass in zero.
The low-level interface should not deliver any messages to the
upper layer until the start_processing() function in the handlers
is called, and the lower layer must get the interface from that
call. */
int ipmi_register_smi(struct ipmi_smi_handlers *handlers,
void *send_info,
struct ipmi_device_id*device_id,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 001] USB: Error handling bug fix for serial_open()
From: Richard Pearman <[EMAIL PROTECTED]> From: Greg Breen <[EMAIL PROTECTED]> When an error occurs in serial_open() ensure that port->tty and tty->driver_data are set to NULL, if previously assigned a value in the function. Signed-off-by: Richard S. Pearman <[EMAIL PROTECTED]> --- --- linux-2.6.17.1/drivers/usb/serial/usb-serial.c.origMon Oct 22 11:12:29 2007 +++ linux-2.6.17.1/drivers/usb/serial/usb-serial.cMon Oct 22 11:12:23 2007 @@ -230,6 +230,8 @@ bailout_module_put: module_put(serial->type->driver.owner); bailout_mutex_unlock: port->open_count = 0; +port->tty = NULL; +tty->driver_data = NULL; mutex_unlock(>mutex); bailout_kref_put: kref_put(>kref, destroy_serial); begin:vcard fn:Richard Pearman n:Pearman;Richard org:Intellect Australia;Embedded Systems Team adr:EIR Building, Technology Park, Bentley;;Suite 11 and 12, 1 Sarich Way;Perth;WA;6102;Australia email;internet:[EMAIL PROTECTED] title:Senior embedded systems engineer tel;work:+61 (08) 9472 2271 tel;fax:+61 (08) 9470 2584 x-mozilla-html:FALSE url:http://www.intellect.be version:2.1 end:vcard
Re: [PATCH] Bug fix for the s390 dcssblk driver
Heiko Carstens wrote:
> On Sat, Oct 20, 2007 at 01:24:34PM -0400, emist wrote:
>> Frans Pop wrote:
>>> emist wrote:
The following patch fixes and issue in the s390 dcssblk driver. The
issue is caused when an unsuccessful attempt is made in order to change
a segment's type through the device attribute file "shared". This causes
the driver to remove the device in question, removing with it the device
attribute which is currently handling the call. The result is a hang on
the driver as it removes memory from under its feet.
Not exactly sure if this explanation makes sense or its entirely
accurate. This is what I believe at this point from encountering and
fixing the error. Anyway here is the patch, hope it helps.
>>> Hi,
>>>
>>> If you don't get any reactions to your patch during the next few days, I
>>> suggest you resend it and then CC the [EMAIL PROTECTED] list and
>>> possibly also the maintainer at [EMAIL PROTECTED]
>>>
>>> In general you should always try to CC the relevant list/people as listed
>>> in
>>> the MAINTAINERS file and not just the linux-kernel list, both for patches
>>> and when reporting problems.
>>>
>>> Cheers,
>>> Frans Pop
>>>
>> Thanks Frans, I will do as you suggest.
>>
>> Have a good one,
>>
>> Igor H.
>
> Gerald or Carsten (cc'ed) should look into this.
> Thanks for reporting.
>
Hello,
I realized that I did not fix one of the cases where this bug manifests
in my last patch. Here is the complete patch to fix the issue. And this
time I cc'ed the relevant people.
Have a good one,
Igor H.
# This patch fixes a memory corruption bug in the s390 dcssblk driver.
# The bug occurs when an attempt to change the type of a segment
# returns an error. At this point the driver tries to remove the segment in
# question while some of the device's attributes are in use. This causes the
# driver to hang.
#
# questions/comments @ [EMAIL PROTECTED]
diff -urN linux-2.6.23.1/drivers/s390/block/dcssblk.c
linuxx/drivers/s390/block/dcssblk.c
--- linux-2.6.23.1/drivers/s390/block/dcssblk.c 2007-10-20 01:19:29.0
-0400
+++ linuxx/drivers/s390/block/dcssblk.c 2007-10-20 01:16:13.0 -0400
@@ -230,8 +230,15 @@
SEGMENT_SHARED);
if (rc < 0) {
BUG_ON(rc == -EINVAL);
- if (rc != -EAGAIN)
- goto removeseg;
+ if (rc != -EAGAIN){
+ PRINT_DEBUG
+ ("Could not reload segment %s in the
specified format, reloading\n",
+dev_info->segment_name);
+ rc = segment_modify_shared(dev_info->
+ segment_name,
+ SEGMENT_EXCLUSIVE);
+ goto out;
+ }
} else {
dev_info->is_shared = 1;
switch (dev_info->segment_type) {
@@ -253,8 +260,12 @@
SEGMENT_EXCLUSIVE);
if (rc < 0) {
BUG_ON(rc == -EINVAL);
- if (rc != -EAGAIN)
- goto removeseg;
+ if (rc != -EAGAIN){
+ PRINT_DEBUG("Could not reload segment %s in the
specified format, reloading\n",
+ dev_info->segment_name);
+ rc =
segment_modify_shared(dev_info->segment_name, SEGMENT_SHARED);
+ goto out;
+ }
} else {
dev_info->is_shared = 0;
set_disk_ro(dev_info->gd, 0);
Re: 2.6.23-mm1 - autofs broken
On Sat, 2007-10-20 at 01:13 -0400, Rik van Riel wrote: > On Thu, 11 Oct 2007 21:31:26 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > - I've been largely avoiding applying anything since rc8-mm2 in an > > attempt to stabilise things for the 2.6.23 merge. > > Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the > -mm kernel. > > Instead of mounting my home directory, I get these messages in > /var/log/messages: > > Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache > rwlock lock failed This is quite strange, normally it should never fail and, in all the time version 5 has been available the maximum number of read locks has never been exceeded. Is there anything unusual going on like a server down causing autofs to issue a number of mounts that are all waiting to time out? > Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error: 11 at > 65 in cache.c Mmm .. if this is a genuine autofs issue maybe I need to handle EAGAIN returns but that would mean blocking which probably isn't good and I'd rather not if we can avoid it. > > I am not sure if this is due to autofs changes or changes in some other > code that was merged. If you can think of any suspicious change that > I should test, please let me know. > Is there anything in the log, an autofs4 kernel trace perhaps? Ian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL Part #3] Blackfin arch bug fixing for merge window
Hi Linus,
Please pull from 'for-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/cooloney/blackfin-2.6.git
for-linus
to receive the following updates:
arch/blackfin/Makefile |4 ++--
arch/blackfin/kernel/setup.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
Bryan Wu (1):
Blackfin arch: use KBUILD_CFLAGS and KBUILD_AFLAGS in Makefile
Mike Frysinger (1):
Blackfin arch: Javier Herrer writes: fix building when icache and
dcache is disabled
diff --git a/arch/blackfin/Makefile b/arch/blackfin/Makefile
index 3c87291..f7cac7c 100644
--- a/arch/blackfin/Makefile
+++ b/arch/blackfin/Makefile
@@ -12,8 +12,8 @@ LDFLAGS_vmlinux := -X
OBJCOPYFLAGS := -O binary -R .note -R .comment -S
GZFLAGS := -9
-CFLAGS += $(call cc-option,-mno-fdpic)
-AFLAGS += $(call cc-option,-mno-fdpic)
+KBUILD_CFLAGS += $(call cc-option,-mno-fdpic)
+KBUILD_AFLAGS += $(call cc-option,-mno-fdpic)
CFLAGS_MODULE+= -mlong-calls
KALLSYMS += --symbol-prefix=_
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index 0e74644..f1b059e 100644
--- a/arch/blackfin/kernel/setup.c
+++ b/arch/blackfin/kernel/setup.c
@@ -501,7 +501,7 @@ EXPORT_SYMBOL(sclk_to_usecs);
unsigned long usecs_to_sclk(unsigned long usecs)
{
- return get_sclk() / (USEC_PER_SEC * (u64)usecs);
+ return (get_sclk() * (u64)usecs) / USEC_PER_SEC;
}
EXPORT_SYMBOL(usecs_to_sclk);
@@ -589,7 +589,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
#elif defined CONFIG_BFIN_WT
"wt"
#endif
- , 0);
+ "", 0);
seq_printf(m, "%s\n", cache);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] x86: add instrumentation menu
* Adrian Bunk ([EMAIL PROTECTED]) wrote: > It seems commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9 was incomplete > due to a clash with the x86 architecture merge. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > Yes, my own fix only dealt with i386 and x86_64 Kconfig, without fixing the x86 architecture. This patch seems good. Acked-by: Mathieu Desnoyers <[EMAIL PROTECTED]> > --- > > arch/i386/Kconfig |2 ++ > arch/x86/oprofile/Kconfig | 17 - > arch/x86_64/Kconfig |2 ++ > 3 files changed, 4 insertions(+), 17 deletions(-) > > e66850f5417ad721e75bf575b6ec49d7aec0af04 > diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig > index f6e44fc..9e8a74f 100644 > --- a/arch/i386/Kconfig > +++ b/arch/i386/Kconfig > @@ -1258,6 +1258,8 @@ source "drivers/Kconfig" > > source "fs/Kconfig" > > +source "kernel/Kconfig.instrumentation" > + > source "arch/i386/Kconfig.debug" > > source "security/Kconfig" > diff --git a/arch/x86/oprofile/Kconfig b/arch/x86/oprofile/Kconfig > deleted file mode 100644 > index d8a8408..000 > --- a/arch/x86/oprofile/Kconfig > +++ /dev/null > @@ -1,17 +0,0 @@ > -config PROFILING > - bool "Profiling support (EXPERIMENTAL)" > - help > - Say Y here to enable the extended profiling support mechanisms used > - by profilers such as OProfile. > - > - > -config OPROFILE > - tristate "OProfile system profiling (EXPERIMENTAL)" > - depends on PROFILING > - help > - OProfile is a profiling system capable of profiling the > - whole system, include the kernel, kernel modules, libraries, > - and applications. > - > - If unsure, say N. > - > diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig > index aab25f3..106d5d5 100644 > --- a/arch/x86_64/Kconfig > +++ b/arch/x86_64/Kconfig > @@ -801,6 +801,8 @@ source "drivers/firmware/Kconfig" > > source fs/Kconfig > > +source "kernel/Kconfig.instrumentation" > + > source "arch/x86_64/Kconfig.debug" > > source "security/Kconfig" > -- 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: Interaction between Xen and XFS: stray RW mappings
dean gaudet wrote: > On Mon, 15 Oct 2007, Nick Piggin wrote: > > >> Yes, as Dave said, vmap (more specifically: vunmap) is very expensive >> because it generally has to invalidate TLBs on all CPUs. >> > > why is that? ignoring 32-bit archs we have heaps of address space > available... couldn't the kernel just burn address space and delay global > TLB invalidate by some relatively long time (say 1 second)? > Yes, that's precisely the problem. xfs does delay the unmap, leaving stray mappings, which upsets Xen. 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: [2.6 patch] fix CONFIG_TUNER_TEA5761=m
Adrian Bunk wrote:
> This patch fixes CONFIG_TUNER_TEA5761=m broken by
> commit ca805d57cf5ea7482ed3da28653f30621249ee45.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> drivers/media/video/tuner-core.c |6 --
> 1 file changed, 6 deletions(-)
>
> 26336c30e76c37bda368a24b8b12978388a18cf3
> diff --git a/drivers/media/video/tuner-core.c
> b/drivers/media/video/tuner-core.c
> index 9484308..1795b78 100644
> --- a/drivers/media/video/tuner-core.c
> +++ b/drivers/media/video/tuner-core.c
> @@ -30,9 +30,7 @@
>
> /* standard i2c insmod options */
> static unsigned short normal_i2c[] = {
> -#ifdef CONFIG_TUNER_TEA5761
> 0x10,
> -#endif
>
^^^ I believe that we want to keep these #ifdef's above... The removals
below are fine.
> 0x42, 0x43, 0x4a, 0x4b, /* tda8290 */
> 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
> 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
> @@ -292,7 +290,6 @@ static void set_type(struct i2c_client *c, unsigned int
> type,
> }
> t->mode_mask = T_RADIO;
> break;
> -#ifdef CONFIG_TUNER_TEA5761
> case TUNER_TEA5761:
> if (tea5761_attach(>fe, t->i2c.adapter, t->i2c.addr) ==
> NULL) {
> t->type = TUNER_ABSENT;
> @@ -301,7 +298,6 @@ static void set_type(struct i2c_client *c, unsigned int
> type,
> }
> t->mode_mask = T_RADIO;
> break;
> -#endif
> case TUNER_PHILIPS_FMD1216ME_MK3:
> buffer[0] = 0x0b;
> buffer[1] = 0xdc;
> @@ -594,7 +590,6 @@ static int tuner_attach(struct i2c_adapter *adap, int
> addr, int kind)
> /* autodetection code based on the i2c addr */
> if (!no_autodetect) {
> switch (addr) {
> -#ifdef CONFIG_TUNER_TEA5761
> case 0x10:
> if (tea5761_autodetection(t->i2c.adapter, t->i2c.addr)
> != EINVAL) {
> t->type = TUNER_TEA5761;
> @@ -606,7 +601,6 @@ static int tuner_attach(struct i2c_adapter *adap, int
> addr, int kind)
> goto register_client;
> }
> break;
> -#endif
> case 0x42:
> case 0x43:
> case 0x4a:
>
>
Regards,
Mike Krufky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.4/2.6 local TCP connect oddity
On Sun, Oct 21, 2007 at 10:53:29PM +0200, Tal Kelrich wrote: > On Sun, 21 Oct 2007 19:29:02 +0200 > Willy Tarreau <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > On Sun, Oct 21, 2007 at 05:53:37PM +0200, Tal Kelrich wrote: > > > Hi, > > > > > > I've run into a problem where a process trying to connect to a local > > > port within the local port range eventually ends up connected to > > > itself, with source port = dest port. > > > > > > similar behavior can be gotten by running netcat as follows: > > > nc -p 1025 localhost 1025 > > > > > > I'm not really sure if that's a bug, but the original case was at > > > least unexpected. > > > > It is not a bug, it is caused by the "simultaneous connect" feature of > > TCP. Although rarely used, in TCP you can connect two clients > > together. They just have to exchange their SYN, SYN/ACK then ACK and > > bingo, they're connected. In fact, you found the easiest way to > > achieve it, by using the same port. To demonstrate the feature, I'm > > used to either temporarily block SYNs with iptables, or by unplugging > > the cable between two machines. > > > > Hi, > > It still seems confusing that a connect against localhost may > randomly succeed. > > Here's a better example, if somewhat violent. eventually succeeds. > (p=$((`cat /proc/sys/net/ipv4/ip_local_port_range|cut -f1`+1)); while > true ; do nc -v -v 127.0.0.1 $p ; done) Of course, for the same reason. If you reduce the ip_local_port_range, it will even succeed more often. This is because the source port is choosen before the first packet is sent, so when it is sent, it reaches a pending connection (itself). I can understand that it is confusing when you see it as a single connection, but try to imagine (or reproduce) with 2 machines, then translate that to the localhost with a single and same connection. You may even draw the exchanges on paper, an you will notice that "each end" of the connection gets its SYN-SYN/ACK-ACK sequence. You may also tcpdump on loopback if that helps. 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: Interaction between Xen and XFS: stray RW mappings
On Mon, 15 Oct 2007, Nick Piggin wrote: > Yes, as Dave said, vmap (more specifically: vunmap) is very expensive > because it generally has to invalidate TLBs on all CPUs. why is that? ignoring 32-bit archs we have heaps of address space available... couldn't the kernel just burn address space and delay global TLB invalidate by some relatively long time (say 1 second)? -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tristate and bool not enogh for Kconfig anymore
On Sun, 21 Oct 2007 17:47:48 -0700 Randy Dunlap wrote: > On Sun, 21 Oct 2007 23:03:13 +0200 Sam Ravnborg wrote: > > > On Sun, Oct 21, 2007 at 09:45:17AM -0700, Randy Dunlap wrote: > > > > Is there any other way to specify that a functionality can only be built > > > > as a module, not built into the kernel? > > > > > > config FOO > > > depends on BAR && m > > > > > > restricts FOO to module-only. > > > > > > > In my firsta attempts to post about these tests my post ended up not on > > > > the mailing list but as a reply to Sam Ravnborg only, apologies for > > > > that... > > > > This is obviously the right solution. > > Randy - we should document this somewhere together with more kconfig > > tips'n'tricks. > > Agreed. So that's one tip or trick... or common idiom. > > A new document or do we extend kconfig-language? > > I don't see a need for a separate document. I would just extend > kconfig-language. ~ Another common idiom that we see (and sometimes have problems with) is this: When B (module or subsystem) uses interfaces from A (module or subsystem), A can be linked statically into the kernel image or can be built as loadable module(s). This limits how B can be built. If A is linked statically into the kernel image, B can be built statically or as loadable module(s). However, if A is built as loadable module(s), then B must be restricted to loadable module(s) also. This can be expressed in kconfig language as: config B depends on A = y || A = B ~~~ There's also a third issue: symbols that are specific to a particular $arch, but they are in Kconfig files that are common to all arches, so kconfig complains about symbol A refers to unknown symbol B. (and I'm just writing this from memory, not from testing it, so it could be off a bit.) One example of this was PS3_PS3AV, as copied from an lkml email of 2007-feb-14: drivers/video/Kconfig:1604:warning: 'select' used by config symbol 'FB_PS3' refer to undefined symbol 'PS3_PS3AV' Someone fixed this one by introducing an intermediate config symbol. I didn't follow the details of that fix, but we see this problem enough to warrant explaining how to handle it. E.g., recently (from 2007-oct-14) on lkml: $ make oldconfig >/dev/null drivers/macintosh/Kconfig:121:warning: 'select' used by config symbol 'PMAC_APM_EMU' refers to undefined symbol 'APM_EMULATION' Adrian, do you know of other items that should be listed here? Thanks, --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23 - MacMini - snd-hda-intel stopped working
Ubuntu kernel 2.6.22-10 works fine - I get sound although volume control doesn't seem to work. With 2.6.23 (today's git actually) I get this error on loading snd-hda-intel - [ 672.830052] PCI: Setting latency timer of device :00:1b.0 to 64 [ 673.061586] hda_codec: STAC922x, Apple subsys_id=106b0800 [ 673.471059] ACPI: PCI interrupt for device :00:1b.0 disabled [ 673.471367] HDA Intel: probe of :00:1b.0 failed with error -16 Any ideas? Thanks Parag - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] return hidden bug
On Mon, 22 Oct 2007 03:53:30 +0200 Roel Kluin <[EMAIL PROTECTED]> wrote: > hidden bug returns > > Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> Acked-by: Rik van Riel <[EMAIL PROTECTED]> -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] unlock before bug returns
Roel Kluin wrote:
> unlock before bug returns
> if (cs >= GPMC_CS_NUM || !gpmc_cs_reserved(cs)) {
> printk(KERN_ERR "Trying to free non-reserved GPMC CS%d\n", cs);
> - BUG();
> spin_unlock(_mem_lock);
> - return;
> + BUG();
should we bother to unlock before panicking, or is the unlock not required
either?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] kill UDFFS_{DATE,VERSION}
Printing date and version of a driver makes sense if there's a
maintainer who's maintaining and using these, but printing ancient
version information only confuses users.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
fs/udf/super.c |3 +--
include/linux/udf_fs.h |3 ---
2 files changed, 1 insertion(+), 5 deletions(-)
2b021a6f76507cf43c80d726d35fd1979cc95c6c
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 4360c7a..64526c3 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -1542,9 +1542,8 @@ static int udf_fill_super(struct super_block *sb, void
*options, int silent)
if (!silent) {
kernel_timestamp ts;
udf_time_to_stamp(, UDF_SB_RECORDTIME(sb));
- udf_info("UDF %s (%s) Mounting volume '%s', "
+ udf_info("UDF: Mounting volume '%s', "
"timestamp %04u/%02u/%02u %02u:%02u (%x)\n",
-UDFFS_VERSION, UDFFS_DATE,
UDF_SB_VOLIDENT(sb), ts.year, ts.month, ts.day,
ts.hour, ts.minute,
ts.typeAndTimezone);
}
diff --git a/include/linux/udf_fs.h b/include/linux/udf_fs.h
index 36c684e..3116b03 100644
--- a/include/linux/udf_fs.h
+++ b/include/linux/udf_fs.h
@@ -32,9 +32,6 @@
#define UDF_PREALLOCATE
#define UDF_DEFAULT_PREALLOC_BLOCKS8
-#define UDFFS_DATE "2004/29/09"
-#define UDFFS_VERSION "0.9.8.1"
-
#undef UDFFS_DEBUG
#ifdef UDFFS_DEBUG
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] ipmi_demangle_device_id(): remove dead code
This patch removes obviously dead code spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/ipmi_smi.h | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
--- linux-2.6/include/linux/ipmi_smi.h.old 2007-10-21 23:03:03.0
+0200
+++ linux-2.6/include/linux/ipmi_smi.h 2007-10-21 23:05:59.0 +0200
@@ -158,44 +158,38 @@ static inline int ipmi_demangle_device_i
if (data_len < 9)
return -EINVAL;
if (data[0] != IPMI_NETFN_APP_RESPONSE << 2 ||
data[1] != IPMI_GET_DEVICE_ID_CMD)
/* Strange, didn't get the response we expected. */
return -EINVAL;
if (data[2] != 0)
/* That's odd, it shouldn't be able to fail. */
return -EINVAL;
data += 3;
data_len -= 3;
id->device_id = data[0];
id->device_revision = data[1];
id->firmware_revision_1 = data[2];
id->firmware_revision_2 = data[3];
id->ipmi_version = data[4];
id->additional_device_support = data[5];
- if (data_len >= 6) {
- id->manufacturer_id = (data[6] | (data[7] << 8) |
- (data[8] << 16));
- id->product_id = data[9] | (data[10] << 8);
- } else {
- id->manufacturer_id = 0;
- id->product_id = 0;
- }
+ id->manufacturer_id = (data[6] | (data[7] << 8) | (data[8] << 16));
+ id->product_id = data[9] | (data[10] << 8);
if (data_len >= 15) {
memcpy(id->aux_firmware_revision, data+11, 4);
id->aux_firmware_revision_set = 1;
} else
id->aux_firmware_revision_set = 0;
return 0;
}
/* Add a low-level interface to the IPMI driver. Note that if the
interface doesn't know its slave address, it should pass in zero.
The low-level interface should not deliver any messages to the
upper layer until the start_processing() function in the handlers
is called, and the lower layer must get the interface from that
call. */
int ipmi_register_smi(struct ipmi_smi_handlers *handlers,
void *send_info,
struct ipmi_device_id*device_id,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] fix CONFIG_TUNER_TEA5761=m
This patch fixes CONFIG_TUNER_TEA5761=m broken by
commit ca805d57cf5ea7482ed3da28653f30621249ee45.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/video/tuner-core.c |6 --
1 file changed, 6 deletions(-)
26336c30e76c37bda368a24b8b12978388a18cf3
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 9484308..1795b78 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -30,9 +30,7 @@
/* standard i2c insmod options */
static unsigned short normal_i2c[] = {
-#ifdef CONFIG_TUNER_TEA5761
0x10,
-#endif
0x42, 0x43, 0x4a, 0x4b, /* tda8290 */
0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
@@ -292,7 +290,6 @@ static void set_type(struct i2c_client *c, unsigned int
type,
}
t->mode_mask = T_RADIO;
break;
-#ifdef CONFIG_TUNER_TEA5761
case TUNER_TEA5761:
if (tea5761_attach(>fe, t->i2c.adapter, t->i2c.addr) ==
NULL) {
t->type = TUNER_ABSENT;
@@ -301,7 +298,6 @@ static void set_type(struct i2c_client *c, unsigned int
type,
}
t->mode_mask = T_RADIO;
break;
-#endif
case TUNER_PHILIPS_FMD1216ME_MK3:
buffer[0] = 0x0b;
buffer[1] = 0xdc;
@@ -594,7 +590,6 @@ static int tuner_attach(struct i2c_adapter *adap, int addr,
int kind)
/* autodetection code based on the i2c addr */
if (!no_autodetect) {
switch (addr) {
-#ifdef CONFIG_TUNER_TEA5761
case 0x10:
if (tea5761_autodetection(t->i2c.adapter, t->i2c.addr)
!= EINVAL) {
t->type = TUNER_TEA5761;
@@ -606,7 +601,6 @@ static int tuner_attach(struct i2c_adapter *adap, int addr,
int kind)
goto register_client;
}
break;
-#endif
case 0x42:
case 0x43:
case 0x4a:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] x86: add instrumentation menu
It seems commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9 was incomplete due to a clash with the x86 architecture merge. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- arch/i386/Kconfig |2 ++ arch/x86/oprofile/Kconfig | 17 - arch/x86_64/Kconfig |2 ++ 3 files changed, 4 insertions(+), 17 deletions(-) e66850f5417ad721e75bf575b6ec49d7aec0af04 diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig index f6e44fc..9e8a74f 100644 --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -1258,6 +1258,8 @@ source "drivers/Kconfig" source "fs/Kconfig" +source "kernel/Kconfig.instrumentation" + source "arch/i386/Kconfig.debug" source "security/Kconfig" diff --git a/arch/x86/oprofile/Kconfig b/arch/x86/oprofile/Kconfig deleted file mode 100644 index d8a8408..000 --- a/arch/x86/oprofile/Kconfig +++ /dev/null @@ -1,17 +0,0 @@ -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index aab25f3..106d5d5 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -801,6 +801,8 @@ source "drivers/firmware/Kconfig" source fs/Kconfig +source "kernel/Kconfig.instrumentation" + source "arch/x86_64/Kconfig.debug" source "security/Kconfig" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] sh64: fix dma_cache_sync() compilation
This patch fixes the following compile error caused by
commit 622a9edd919de98ef59571ae6c40c7458244e3f2:
<-- snip -->
...
CC init/main.o
In file included from
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/dma-mapping.h:52,
from
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/dmaengine.h:29,
from
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/skbuff.h:29,
from
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/netlink.h:155,
from
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/genetlink.h:4,
from
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/net/genetlink.h:4,
from
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/taskstats_kern.h:12,
from /home/bunk/linux/kernel-2.6/git/linux-2.6/init/main.c:46:
include2/asm/dma-mapping.h: In function 'dma_cache_sync':
include2/asm/dma-mapping.h:46: error: invalid operands to binary & (have 'void
*' and 'int')
make[2]: *** [init/main.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
e4e74353f092fa502d4c7e9c3c16a0d7a3bcf85e
diff --git a/include/asm-sh64/dma-mapping.h b/include/asm-sh64/dma-mapping.h
index e661857..e57f129 100644
--- a/include/asm-sh64/dma-mapping.h
+++ b/include/asm-sh64/dma-mapping.h
@@ -42,8 +42,9 @@ static inline void dma_free_coherent(struct device *dev,
size_t size,
static inline void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
enum dma_data_direction dir)
{
- unsigned long s = (unsigned long) vaddr & L1_CACHE_ALIGN_MASK;
- unsigned long e = (vaddr + size) & L1_CACHE_ALIGN_MASK;
+ unsigned long start = (unsigned long) vaddr;
+ unsigned long s = start & L1_CACHE_ALIGN_MASK;
+ unsigned long e = (start + size) & L1_CACHE_ALIGN_MASK;
for (; s <= e; s += L1_CACHE_BYTES)
asm volatile ("ocbp %0, 0" : : "r" (s));
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
char/cyclades.c: inconsequent NULL checking
The Coverity checker spotted the following inconsequent NULL checking in
drivers/char/cyclades.c:
<-- snip -->
...
static void cyz_handle_tx(struct cyclades_port *info,
struct BUF_CTRL __iomem *buf_ctrl)
{
struct cyclades_card *cinfo = info->card;
struct tty_struct *tty = info->tty;
...
if (tty == NULL)
goto ztxdone;
...
tty_wakeup(tty);
...
<-- snip -->
Nothing in cyz_handle_tx() seems to change "tty".
The "tty_wakeup(tty);" was added in commit
ebafeeff0fea029099e9952f233e0794106897a6.
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/
[PATCH] Include kernel/Kconfig.instrumentation in i386 and x86-64 Kconfig.
To get the kernel compiled with instrumentation turned on, I had to apply the patch below. It looks to me like x86 and x86-64 were just left out when the Kconfig.instrumentation file was created, but maybe I am misunderstanding how the x86/x86-64 merge is supposed to work. Soren Signed-off-by: Soren Sandmann <[EMAIL PROTECTED]> --- arch/i386/Kconfig |2 ++ arch/x86_64/Kconfig |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig index f6e44fc..b54a82d 100644 --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -1266,6 +1266,8 @@ source "crypto/Kconfig" source "lib/Kconfig" +source "kernel/Kconfig.instrumentation" + # # Use the generic interrupt handling code in kernel/irq/: # diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index aab25f3..a68865b 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -808,3 +808,5 @@ source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" + +source "kernel/Kconfig.instrumentation" -- 1.5.2.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/
[git pull] lguest: paravirt boot code
Hi Linus, First attempt at git, so please pull carefully. I've just put the three i386 boot changes in the repo for the moment. If this works I'll pile on the 44 lguest patches. git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-lguest.git Documentation/i386/boot.txt| 34 +++- arch/x86/boot/compressed/head_32.S | 15 ++- arch/x86/boot/compressed/misc_32.c |3 ++ arch/x86/boot/header.S |7 +- arch/x86/kernel/asm-offsets_32.c |7 + arch/x86/kernel/head_32.S | 44 +-- include/asm-x86/bootparam.h|9 +- include/linux/linkage.h|6 + 8 files changed, 116 insertions(+), 9 deletions(-) commit f160a3a39ba7a5ac03a0eb64c25d3751c342e0e7 Author: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Date: Mon Oct 22 10:56:19 2007 +1000 i386: paravirt boot sequence This patch uses the updated boot protocol to do paravirtualized boot. If the boot version is >= 2.07, then it will do two things: 1. Check the bootparams loadflags to see if we should reload the segment registers and clear interrupts. This is appropriate for normal native boot and some paravirtualized environments, but inapproprate for others. 2. Check the hardware architecture, and dispatch to the appropriate kernel entrypoint. If the bootloader doesn't set this, then we simply do the normal boot sequence. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> Acked-by: H. Peter Anvin <[EMAIL PROTECTED]> Cc: "Eric W. Biederman" <[EMAIL PROTECTED]> Cc: Vivek Goyal <[EMAIL PROTECTED]> Cc: James Bottomley <[EMAIL PROTECTED]> commit a706681568ed19f147ab78674388c5a0e6ab8c44 Author: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Date: Mon Oct 22 10:56:18 2007 +1000 add WEAK() for creating weak asm labels Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> Acked-by: H. Peter Anvin <[EMAIL PROTECTED]> commit 262ac2158778ac5937ae943d1d43f0adcff1a1d1 Author: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Date: Mon Oct 22 10:56:17 2007 +1000 update boot spec to 2.07 Proposed updates for version 2.07 of the boot protocol. This includes: load_flags.KEEP_SEGMENTS- flag to request/inhibit segment reloads hardware_subarch- what subarchitecture we're booting under hardware_subarch_data - per-architecture data The intention of these changes is to make booting a paravirtualized kernel work via the normal Linux boot protocol. The intention is that the bzImage payload can be a properly formed ELF file, so that the bootloader can use its ELF notes and Phdrs to get more metadata about the kernel and its requirements. The ELF file could be the uncompressed kernel vmlinux itself; it would only take small buildsystem changes to implement this. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> Acked-by: H. Peter Anvin <[EMAIL PROTECTED]> Cc: "Eric W. Biederman" <[EMAIL PROTECTED]> Cc: Vivek Goyal <[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] Add bluetooth support to toshiba-acpi driver
Jonathan McDowell wrote:
> This patch adds bluetooth support to the toshiba-acpi driver. I have
> tried to follow the same format for the /proc/acpi/toshiba/bluetooth
> file as followed in the thinkpad-acpi driver. In the long term the
> rfkill infrastructure looks like the way forward for this functionality,
> but at present it doesn't seem to be suitable.
>
Would it be possible (make sense) to add config option for that? There are
probably a bunch of older models out there that do not have BT at all (I am
owner of such one).
Thank you
-andrey
> Traditionally the userland "toshset" program would have been used to
> enable bluetooth, but this requires either CONFIG_TOSHIBA or a patched
> toshiba-acpi to emulate the /dev/toshiba device. Also toshset doesn't
> currently run in 64bit mode.
>
> Patch has been successfully tested on a Portégé R200 (in 32bit mode) and
> an R500 (in 64bit mode).
>
> Signed-Off-By: Jonathan McDowell <[EMAIL PROTECTED]>
>
> -
> --- drivers/acpi/toshiba_acpi.c.orig 2007-10-21 18:29:01.0 +0100
> +++ drivers/acpi/toshiba_acpi.c 2007-10-21 18:15:34.0 +0100
> @@ -33,7 +33,7 @@
> *
> */
>
> -#define TOSHIBA_ACPI_VERSION "0.18"
> +#define TOSHIBA_ACPI_VERSION "0.19"
> #define PROC_INTERFACE_VERSION 1
>
> #include
> @@ -55,6 +55,7 @@ MODULE_LICENSE("GPL");
> #define MY_ERR KERN_ERR MY_LOGPREFIX
> #define MY_NOTICE KERN_NOTICE MY_LOGPREFIX
> #define MY_INFO KERN_INFO MY_LOGPREFIX
> +#define strlencmp(a,b) (strncmp((a), (b), strlen(b)))
>
> /* Toshiba ACPI method paths */
> #define METHOD_LCD_BRIGHTNESS"\\_SB_.PCI0.VGA_.LCD_._BCM"
> @@ -90,6 +91,7 @@ MODULE_LICENSE("GPL");
> #define HCI_VIDEO_OUT0x001c
> #define HCI_HOTKEY_EVENT 0x001e
> #define HCI_LCD_BRIGHTNESS 0x002a
> +#define HCI_BLUETOOTH0x0056
>
> /* field definitions */
> #define HCI_LCD_BRIGHTNESS_BITS 3
> @@ -482,6 +484,129 @@ static unsigned long write_keys(const ch
> return count;
> }
>
> +static int toshiba_bluetooth_present(void)
> +{
> + u32 hci_result;
> + u32 value;
> +
> + hci_read1(HCI_BLUETOOTH, , _result);
> + if (hci_result == HCI_SUCCESS) {
> + return (value & 0x0f) == 0x0f;
> + } else
> + return -EFAULT;
> +}
> +
> +static int toshiba_bluetooth_get(void)
> +{
> + u32 in[HCI_WORDS];
> + u32 out[HCI_WORDS];
> + acpi_status status;
> +
> + in[0] = HCI_GET;
> + in[1] = HCI_BLUETOOTH;
> + in[2] = 0;
> + in[3] = 1;
> + status = hci_raw(in, out);
> + if (status != AE_OK) {
> + printk(MY_ERR "Error checking Bluetooth device status.\n");
> + return -EIO;
> + }
> +
> + /* 0x1 == switch on, 0x40 == attached, 0x80 == power on */
> + return (out[2] & 0xC1) == 0xC1;
> +}
> +
> +static int toshiba_bluetooth_set(int state)
> +{
> + u32 in[HCI_WORDS];
> + u32 out[HCI_WORDS];
> + acpi_status status;
> +
> + switch (state) {
> + case 0:
> + in[0] = HCI_SET;
> + in[1] = HCI_BLUETOOTH;
> + in[2] = 0;
> + in[3] = 0x40;
> + status = hci_raw(in, out);
> + if (status != AE_OK) {
> + printk(MY_ERR "Error detaching Bluetooth device.\n");
> + return -EIO;
> + }
> +
> + in[0] = HCI_SET;
> + in[1] = HCI_BLUETOOTH;
> + in[2] = 0;
> + in[3] = 0x80;
> + status = hci_raw(in, out);
> + if (status != AE_OK) {
> + printk(MY_ERR "Error deactivating Bluetooth device.\n");
> + return -EIO;
> + }
> + break;
> + case 1:
> + in[0] = HCI_SET;
> + in[1] = HCI_BLUETOOTH;
> + in[2] = 1;
> + in[3] = 0x80;
> + status = hci_raw(in, out);
> + if (status != AE_OK) {
> + printk(MY_ERR "Error activating Bluetooth device.\n");
> + return -EIO;
> + }
> +
> + in[0] = HCI_SET;
> + in[1] = HCI_BLUETOOTH;
> + in[2] = 1;
> + in[3] = 0x40;
> + status = hci_raw(in, out);
> + if (status != AE_OK) {
> + printk(MY_ERR "Error attaching Bluetooth device.\n");
> + return -EIO;
> + }
> + break;
> + default:
> + printk(MY_ERR "Unknown state for Bluetooth.\n");
> + };
> +
> + return 0;
> +}
> +
> +static char *read_bluetooth(char *p)
> +{
> + int value = toshiba_bluetooth_get();
> +
> + if (!toshiba_bluetooth_present()) {
> + p += sprintf(p, "status:\t\tnot supported\n");
> + } else if (value >= 0) {
> + p += sprintf(p, "status:\t\t%s\n",
> + value ? "enabled" : "disabled");
> + p
Re: LSM conversion to static interface
Yes, I think Crispin has succinctly summed it up: irrevocably closing the LSM prevents commercial customers from using security modules other than that provided by their Linux distributor. As Sarbanes-Oxley and other regulatory laws require these customers to use "standard kernels", the result is a rather dreary form of vendor lock-in, where the security framework is coupled to the distribution. Though it would require a somewhat undesirable complexity of CONFIG_ flags, it should be possible to construct flexibility enough for everyone to get what he wants. For example, it should be possible to configure kernels with a single security framework hard-linked, AND it should also be possible to configure kernels such that the default security framework could be completely replaced at boot time by another, be it out-of-tree module, or other. I agree entirely that preserving this form of freedom for the end user makes Linux a much stronger technology than not. For one thing, the consequences of closing LSM are fairly certain to irritate enterprise commercial customers, which is probably a sign that the technology has taken a wrong turn. Tommy F. Crispin Cowan <[EMAIL PROTECTED]> wrote: > So the net impact of this patch is: > >* It takes a deployment practice (static compiled-in security) that > is arguably good in many circumstances and makes it mandatory at > all times. >* It takes a development practice that is very convenient and > slightly risky, and forces you into the pessimal inconvenient > development practice at all times. >* It prevents enterprise users, and in fact anyone who isn't > comfortable compiling their own kernel, from ever trying out any > security module that their distro vendor of choice did not ship. > > This strikes me as a rather anti-choice position to take. It says that > because candy is bad for you, you only ever get to eat vegetables. I > don't understand why Linux would want to do this to its users. > > It doesn't hurt me or AppArmor. Since AppArmor is now shipping with > SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer > modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise > users. So I don't think I am being self-serving in arguing against this > patch. I just think it is bad for Linux. > > Crispin > > -- > Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ > Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"spurious completions during NCQ" with 2.6.23.1 and DVD Multi-Recorder on Thinkpad T61
Hi, Using the 2.6.23.1 kernel and Debian Etch on a Lenovo Thinkpad T61 7659A21, I am getting two weird errors, as follows: ata1.00: exception Emask 0x2 SAct 0x1c SErr 0x0 action 0x2 frozen ata1.00: spurious completions during NCQ issue=0x0 SAct=0x1c FIS=005040a1:0002 ata1.00: cmd 60/17:10:28:01:00/00:00:00:00:00/40 tag 2 cdb 0x0 data 11776 in res 50/00:30:bf:01:00/00:00:00:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/80:18:3f:01:00/00:00:00:00:00/40 tag 3 cdb 0x0 data 65536 in res 50/00:30:bf:01:00/00:00:00:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 60/30:20:bf:01:00/00:00:00:00:00/40 tag 4 cdb 0x0 data 24576 in res 50/00:30:bf:01:00/00:00:00:00:00/40 Emask 0x2 (HSM violation) ... irq 19: nobody cared (try booting with the "irqpoll" option) Call Trace: [] __report_bad_irq+0x1e/0x80 [] note_interrupt+0x29d/0x2e0 [] handle_fasteoi_irq+0xdd/0x110 [] call_softirq+0x1c/0x30 [] do_IRQ+0x7b/0x100 [] ret_from_intr+0x0/0xa handlers: [] (usb_hcd_irq+0x0/0x60) Disabling IRQ #19 I have tried booting with the irqpoll option, but this results in the automounter doing weird things with the optical drive. Specifically, it sporadically mounts an audio disc with weird negative-sized tracks, even if there is no disc inserted in the drive. Also, regardless of whether I boot with irqpoll or not, chrony frequently uses up 100% of one CPU. The chrony measurements.log, statistics.log and tracking.log all show normal activity (ie: a "normal" volume of entries, vis a vis chrony on other machines where CPU usage is normal). I don't know if this is related. Any clues? I have attached the following: 1. Kernel configuration 2. dmesg output 3. lspci output 4. chrony.conf (if it matters) Please cc me with replies, as I am not on the list. Thank you very much. Cheers! -- Federico Sevilla III F S 3 Consulting Inc. http://www.fs3.ph Linux version 2.6.23.1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Oct 19 01:01:42 PHT 2007 Command line: root=/dev/mapper/humanitas-root rw vga=871 BIOS-provided physical RAM map: BIOS-e820: - 0009d800 (usable) BIOS-e820: 0009d800 - 000a (reserved) BIOS-e820: 000d2000 - 000d4000 (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 3e6b (usable) BIOS-e820: 3e6b - 3e6cc000 (ACPI data) BIOS-e820: 3e6cc000 - 3e70 (ACPI NVS) BIOS-e820: 3e70 - 3f00 (reserved) BIOS-e820: f000 - f400 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fed0 - fed00400 (reserved) BIOS-e820: fed14000 - fed1a000 (reserved) BIOS-e820: fed1c000 - fed9 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff00 - 0001 (reserved) Entering add_active_range(0, 0, 157) 0 entries of 256 used Entering add_active_range(0, 256, 255664) 1 entries of 256 used end_pfn_map = 1048576 DMI present. ACPI: RSDP 000F68D0, 0024 (r2 LENOVO) ACPI: XSDT 3E6BB8FD, 0094 (r1 LENOVO TP-7L1210 LTP0) ACPI: FACP 3E6BBA00, 00F4 (r3 LENOVO TP-7L1210 LNVO1) ACPI Warning (tbfadt-0442): Optional field "Gpe1Block" has zero address or length: 102C/0 [20070126] ACPI: DSDT 3E6BBE0C, FD64 (r1 LENOVO TP-7L1210 MSFT 300) ACPI: FACS 3E6E4000, 0040 ACPI: SSDT 3E64, 0258 (r1 LENOVO TP-7L1210 MSFT 300) ACPI: ECDT 3E6CBB70, 0052 (r1 LENOVO TP-7L1210 LNVO1) ACPI: TCPA 3E6CBBC2, 0032 (r2 LENOVO TP-7L1210 LNVO1) ACPI: APIC 3E6CBBF4, 0068 (r1 LENOVO TP-7L1210 LNVO1) ACPI: MCFG 3E6CBC5C, 003C (r1 LENOVO TP-7L1210 LNVO1) ACPI: HPET 3E6CBC98, 0038 (r1 LENOVO TP-7L1210 LNVO1) ACPI: SLIC 3E6CBDF0, 0176 (r1 LENOVO TP-7L1210 LTP0) ACPI: BOOT 3E6CBF66, 0028 (r1 LENOVO TP-7L1210 LTP1) ACPI: ASF! 3E6CBF8E, 0072 (r16 LENOVO TP-7L1210 PTL 1) ACPI: SSDT 3E6E2697, 025F (r1 LENOVO TP-7L1210 INTL 20050513) ACPI: SSDT 3E6E28F6, 00A6 (r1 LENOVO TP-7L1210 INTL 20050513) ACPI: SSDT 3E6E299C, 04F7 (r1 LENOVO TP-7L1210 INTL 20050513) ACPI: SSDT 3E6E2E93, 01D8 (r1 LENOVO TP-7L1210 INTL 20050513) Entering add_active_range(0, 0, 157) 0 entries of 256 used Entering add_active_range(0, 256, 255664) 1 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 -> 157 0:
Re: sata sil3114 vs. certain seagate drives results in filesystem corruptions
Helo, Soeren Sonnenburg wrote: > I finally managed to find a *reproducible* setup and way to trigger > random corruptions using a sata sil 3114 controller connected to 4 > seagate drives > > port 1: ST3400832AS sda > port 2: ST3400620AS sdb > port 3: ST3750640AS sdc > port 4: ST3750640AS sdd > > sda & sdb form md0 via a raid1 setup followed by an additional > devicemapper layer ( root ). sdc and sdb are separate and also have an > additional device mapper layer ( public ) and ( backups ). > > Now when I write large files of zeros to root(sda) and read the file > back in it contains a few nonzero entries: > > # dd if=/dev/zero of=/foo bs=1M count=2000 > # hexdump /foo > 000 > * > 1GB random parts, within large blocks of zeroes> > > I can reliably trigger this on the md0 / devmapper-root setup when I > write about 2GB of data (note that this machine has 1.5G of memory - and > still 1GB is often enough to see this problem). Here it does not matter > where in the filesystem I do these writes. Thanks. I'll try to reproduce the problem here. What's your motherboard? > Now promise_sata is converted to new EH, so I simply gave it a go, i.e. > I attached ST3400832AS and ST3400620AS to the promise controller and > rebooted and redid the experiments from above. > > No data corruptions whatsoever. I even ran the dd on all three devmapped > mount points simultaneously with a size of 30GB each, still no > corruption. However the error messages I've seen a year ago are back for > the ST3400832AS and ST3400620AS attached to the promise controller (see > below). [--snip--] > ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x100 action 0x2 > ata1.00: port_status 0x2020 > ata1.00: cmd 25/00:00:c0:b6:74/00:01:20:00:00/e0 tag 0 cdb 0x0 data 131072 in > res 51/0c:00:c0:b6:74/0c:01:20:00:00/e0 Emask 0x10 (ATA bus error) > ata1: soft resetting port Yeah, still the same. Your drives don't like the way promise controller speaks to them (e.g. promise generates signals which are ) but now that sata_promise has proper EH. It can recover from those errors. As long as nothing worse happens, it should be okay. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] unlock before bug returns
I think the unlock should be before bugging?
--
unlock before bug returns
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5a4cc20..c910170 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -357,9 +357,8 @@ void gpmc_cs_free(int cs)
spin_lock(_mem_lock);
if (cs >= GPMC_CS_NUM || !gpmc_cs_reserved(cs)) {
printk(KERN_ERR "Trying to free non-reserved GPMC CS%d\n", cs);
- BUG();
spin_unlock(_mem_lock);
- return;
+ BUG();
}
gpmc_cs_disable_mem(cs);
release_resource(_cs_mem[cs]);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] rd: Use a private inode for backing storage
On Monday 22 October 2007 04:39, Eric W. Biederman wrote: > Nick Piggin <[EMAIL PROTECTED]> writes: > > On Sunday 21 October 2007 18:23, Eric W. Biederman wrote: > >> Christian Borntraeger <[EMAIL PROTECTED]> writes: > >> > >> Let me put it another way. Looking at /proc/slabinfo I can get > >> 37 buffer_heads per page. I can allocate 10% of memory in > >> buffer_heads before we start to reclaim them. So it requires just > >> over 3.7 buffer_heads on very page of low memory to even trigger > >> this case. That is a large 1k filesystem or a weird sized partition, > >> that we have written to directly. > > > > On a highmem machine it it could be relatively common. > > Possibly. But the same proportions still hold. 1k filesystems > are not the default these days and ramdisks are relatively uncommon. > The memory quantities involved are all low mem. You don't need 1K filesystems to have buffers attached though, of course. You can hit the limit with a 4K filesystem with less than 8GB in pagecache I'd say. > > You don't want to change that for a stable patch, however. > > It fixes the bug. > > No it avoids the bug which is something slightly different. > Further I contend that it is not obviously correct that there > are no other side effects (because it doesn't actually fix the > bug), and that makes it of dubious value for a backport. The bug in question isn't exactly that it uses buffercache for its backing store (although that's obviously rather hairy as well). It's this specific problem sequence. And it does fix the problem. > If I had to slap a patch on there at this point just implementing > an empty try_to_release_page (which disables try_to_free_buffers) > would be my choice. How is that better? Now you're making the exact same change for all filesystems that you didn't think was obviously correct for rd.c. > > I just don't think what you have is the proper fix. Calling > > into the core vfs and vm because right now it does something > > that works for you but is completely unrelated to what you > > are conceptually doing is not the right fix. > > I think there is a strong conceptual relation and other code > doing largely the same thing is already in the kernel (ramfs). Plus > my gut feel says shared code will make maintenance easier. ramfs is rather a different case. Filesystems intimately know about the pagecache. > You do have a point that the reuse may not be perfect and if that > is the case we need to watch out for the potential to mess things > up. > > So far I don't see any problems with the reuse. It's just wrong. I guess if you don't see that by now, then we have to just disagree. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sata_nv,ahci: add the ahci legacy mode support to sata_nv
Yes, link - http://lkml.org/lkml/2007/10/8/93 add the AHCI legacy support to sata_nv when IDE/RAID mode been set in SBIOS and Device IDs are not in ahci.c at this moment. To do so, when a new chipset come out and DIDs haven't been submited to LKML,user still can use ahci driver to handle it when setting AHCI mode in BIOS, using sata_nv when setting RAID/IDE in BIOS. For example, ahci driver in Fedora 7 doesn't include the DIDs of MCP78, so if you set the IDE/RAID mode in BIOS, os installation onto SATA drive will fail. But if Fedora 7 include this patch, installation will be successful. 2007/10/19, Jeff Garzik <[EMAIL PROTECTED]>: > peer chen wrote: > > Ok,I agree to use AHCI driver for our AHCI controllers no matter their > > class codes are IDE/RAID/AHCI. But for those new or upcoming AHCI > > controller which DIDs are not included in ahci.c and also IDE/RAID > > mode being set in BIOS, no driver will be loaded currently, so I hope > > the first patch http://lkml.org/lkml/2007/10/8/93 can be appied for > > this case. Any comments? > > hmmm is that the correct URL? That one updates sata_nv to support AHCI > controllers?. > > I would think you would want to add the RAID class code to ahci.c > instead? And just some regular PCI IDs? > >Jeff > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] return hidden bug
Rik van Riel wrote: > On Mon, 22 Oct 2007 03:05:05 +0200 > Roel Kluin <[EMAIL PROTECTED]> wrote: > >> return hidden bug >> >> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> >> >> diff --git a/arch/alpha/kernel/pci_iommu.c >> b/arch/alpha/kernel/pci_iommu.c index e1c4707..6a69425 100644 >> --- a/arch/alpha/kernel/pci_iommu.c >> +++ b/arch/alpha/kernel/pci_iommu.c >> @@ -365,8 +365,8 @@ pci_unmap_single(struct pci_dev *pdev, dma_addr_t >> dma_addr, size_t size, printk(KERN_ERR "Bogus pci_unmap_single: >> dma_addr %lx " " base %lx size %x\n", dma_addr, arena->dma_base, >> arena->size); >> -return; >> BUG(); >> +return; >> } >> >> npages = calc_npages((dma_addr & ~PAGE_MASK) + size); > > BUG() will terminate the process that runs into it, so you can > just remove the return alltogether. If BUG() is hit, the return > will never be reached. > --- hidden bug returns Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c index e1c4707..ca55c33 100644 --- a/arch/alpha/kernel/pci_iommu.c +++ b/arch/alpha/kernel/pci_iommu.c @@ -365,7 +365,6 @@ pci_unmap_single(struct pci_dev *pdev, dma_addr_t dma_addr, size_t size, printk(KERN_ERR "Bogus pci_unmap_single: dma_addr %lx " " base %lx size %x\n", dma_addr, arena->dma_base, arena->size); - return; BUG(); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] return hidden bug
On Mon, 22 Oct 2007 03:05:05 +0200 Roel Kluin <[EMAIL PROTECTED]> wrote: > return hidden bug > > Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> > > diff --git a/arch/alpha/kernel/pci_iommu.c > b/arch/alpha/kernel/pci_iommu.c index e1c4707..6a69425 100644 > --- a/arch/alpha/kernel/pci_iommu.c > +++ b/arch/alpha/kernel/pci_iommu.c > @@ -365,8 +365,8 @@ pci_unmap_single(struct pci_dev *pdev, dma_addr_t > dma_addr, size_t size, printk(KERN_ERR "Bogus pci_unmap_single: > dma_addr %lx " " base %lx size %x\n", dma_addr, arena->dma_base, > arena->size); > - return; > BUG(); > + return; > } > > npages = calc_npages((dma_addr & ~PAGE_MASK) + size); BUG() will terminate the process that runs into it, so you can just remove the return alltogether. If BUG() is hit, the return will never be reached. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] m68k: Use cc-cross-prefix (was: Re: [GI:wqT PULL] kbuild updates - second round)
On Sun, 21 Oct 2007, Geert Uytterhoeven wrote: > +ifneq ($(SUB_ARCH),$(ARCH)) > + ifeq ($(CROSS_COMPILE),) > +CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu- > m68k-linux-) I've not paid much attention to discussion over this (I tend to build natively, less stress :) ), so pardon my ignorance. Does the above make any difference for me when I use CROSS_COMPILE=m68k-unknown-linux-gnu-, or does it just detect m68k-linux-gnu- and m68k-linux-? -- kolla, that gentoo/m68k lunatic :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: LSM conversion to static interface
To discuss how LSM should work, it would have been really helpful if the OP had cc'd the LSM mailing list. I've cc'd the LSM list here ... Linus Torvalds wrote: > On Wed, 17 Oct 2007, Thomas Fricaccia wrote: > >> But then I noticed that, while the LSM would remain in existence, it was >> being closed to out-of-tree security frameworks. Yikes! Since then, >> I've been following the rush to put SMACK, TOMOYO and AppArmor >> "in-tree". >> > Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE > people were ok with it (AppArmor), but I'm with you - I applied it, but > I'm also perfectly willing to unapply it if there actually are valid > out-of-tree users that people push for not merging. > I did not speak up against this patch because it does not hurt AppArmor, and I was trying to reduce the amount of LKML flaming that I engage in :) but since you asked, IMHO this patch is extremely bad for Linux and bad for Linux users. The patch does have benefits, I just think those benefits are weak and unimportant. It prohibits dynamic loading of security modules (you must be compiled in) and prohibits unloading of security modules (because it is unsafe, and potentially insecure). What makes these benefits weak and unimportant is that you can have those benefits now without the patch by just writing your module that way: if you think that a security module should be compiled in and present when the kernel boots, and should never be unloaded. > For example, I do kind of see the point that a "real" security model might > want to be compiled-in, and not something you override from a module. Of > course, I'm personally trying to not use any modules at all, so I'm just > odd and contrary, so whatever.. > Why would you want to dynamically unload a module: because it is convenient for debugging. Ok, so it is unsafe, and sometimes wedges your kernel, which sometimes forces you to reboot. With this patch in place, it forces you to *always* reboot when you want to try a hack to the module. Why you would want to dynamically load a security module: because you are an enterprise user, required to use a specific build of a kernel, rather than compile your own kernel, but you also want to use (or even try out) a security module that your enterprise's vendor of choice has not chosen to bundle. In the current state, such a user can just go get a module and use it. With this patch, such a user is just screwed, they can't load and try the module without having to get into kernel building. So the net impact of this patch is: * It takes a deployment practice (static compiled-in security) that is arguably good in many circumstances and makes it mandatory at all times. * It takes a development practice that is very convenient and slightly risky, and forces you into the pessimal inconvenient development practice at all times. * It prevents enterprise users, and in fact anyone who isn't comfortable compiling their own kernel, from ever trying out any security module that their distro vendor of choice did not ship. This strikes me as a rather anti-choice position to take. It says that because candy is bad for you, you only ever get to eat vegetables. I don't understand why Linux would want to do this to its users. It doesn't hurt me or AppArmor. Since AppArmor is now shipping with SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise users. So I don't think I am being self-serving in arguing against this patch. I just think it is bad for Linux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] return hidden bug
return hidden bug Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c index e1c4707..6a69425 100644 --- a/arch/alpha/kernel/pci_iommu.c +++ b/arch/alpha/kernel/pci_iommu.c @@ -365,8 +365,8 @@ pci_unmap_single(struct pci_dev *pdev, dma_addr_t dma_addr, size_t size, printk(KERN_ERR "Bogus pci_unmap_single: dma_addr %lx " " base %lx size %x\n", dma_addr, arena->dma_base, arena->size); - return; BUG(); + return; } npages = calc_npages((dma_addr & ~PAGE_MASK) + size); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potential regression in -git15: can't resume stopped root shell?
On Sat, Oct 20, 2007 at 02:58:06PM -0400, Theodore Tso wrote: > I was testing 2.6.23-git15, and I'm noticing that if I su to root, then > suspend the root shell, and try continue it via "fg", it hangs. The ps > command reports: > > 15806 6386 19 0 4012 wait Ss pts/000:00:00 bash > 0 6444 19 0 1232 finish_stop T+ pts/000:00:00 /bin/su > -p > 0 6445 19 0 3696 finish_stop Tpts/000:00:00 bash > 15806 6571 19 0 776 pipe_waitS+ pts/100:00:00 grep > pts/0 > > This works under 2.6.23. I am running Ubuntu Gutsy running in a > gnome-terminal, with bash as my login shell. I can suspend a zsh or > bash shell where I haven't su'ed to root. But if the shell is started > using either su or sudo, when I try to resume it after suspending > using the "suspend" command via "fg", I get a hung shell. > > I haven't had time to bisect it yet, but I thought I'd throw it out > there in case this rings a bell with anybody... OK, I bisected, and it turns out to be a bug, but not a regression. Turns out the responsible commit is: commit b53767719b6cd8789392ea3e7e2eb7b8906898f0 Author: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Tue Oct 16 23:31:36 2007 -0700 Implement file posix capabilities Implement file posix capabilities. This allows programs to be given a subset of root's powers regardless of who runs them, without having to use setuid and giving the binary all of root's powers. Once I turned this up, I turned went back to -git15, and turned off CONFIG_SECURITY_FILE_CAPABILITIES, and the problem went away. Oh, well, I had wanted to try out file capabilities, which is why I had turned the option on, but being able to resume suspended root shells is more important. :-) Serge, can you take a look at this, please? Thanks!! - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tristate and bool not enogh for Kconfig anymore
On Sun, 21 Oct 2007 23:03:13 +0200 Sam Ravnborg wrote: > On Sun, Oct 21, 2007 at 09:45:17AM -0700, Randy Dunlap wrote: > > > Is there any other way to specify that a functionality can only be built > > > as a module, not built into the kernel? > > > > config FOO > > depends on BAR && m > > > > restricts FOO to module-only. > > > > > In my firsta attempts to post about these tests my post ended up not on > > > the mailing list but as a reply to Sam Ravnborg only, apologies for > > > that... > > This is obviously the right solution. > Randy - we should document this somewhere together with more kconfig > tips'n'tricks. Agreed. > A new document or do we extend kconfig-language? I don't see a need for a separate document. I would just extend kconfig-language. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/4] Rename lock_cpu_hotplug to get_online_cpus
Gautham R Shenoy wrote: > > Gautham R Shenoy wrote: > > > On Thu, Oct 18, 2007 at 03:22:21AM -0500, Nathan Lynch wrote: > > > > Gautham R Shenoy wrote: > > > > > > Gautham R Shenoy wrote: > > > > > > > Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel > > > > > > > and use > > > > > > > get_online_cpus and put_online_cpus instead as it highlights > > > > > > > the refcount semantics in these operations. > > > > > > > > > > > > Something other than "get_online_cpus", please? lock_cpu_hotplug() > > > > > > protects cpu_present_map as well as cpu_online_map. For example, > > > > > > some > > > > > > of the powerpc code modified in this patch is made a bit less clear > > > > > > because it is manipulating cpu_present_map, not cpu_online_map. > > > > > > > > > > A quick look at the code, and I am wondering why is lock_cpu_hotplug() > > > > > used there in the first place. It doesn't look like we require any > > > > > protection against cpus coming up/ going down in the code below, > > > > > since the cpu-hotplug operation doesn't affect the cpu_present_map. > > > > > > > > The locking is necessary. Changes to cpu_online_map and > > > > cpu_present_map must be serialized; otherwise you could end up trying > > > > to online a cpu as it is being removed (i.e. cleared from > > > > cpu_present_map). Online operations must check that a cpu is present > > > > before bringing it up (kernel/cpu.c): > > > > > > Fair enough! > > > > > > But we are not protecting the cpu_present_map here using > > > lock_cpu_hotplug(), now are we? > > > > Yes, we are. In addition to the above, updates to cpu_present_map > > have to be serialized. pseries_add_processor can be summed up as > > "find the first N unset bits in cpu_present_map and set them". That's > > not an atomic operation, so some kind of mutual exclusion is needed. > > > > Okay. But other than pseries_add_processor and pseries_remove_processor, > are there any other places where we _change_ the cpu_present_map ? Other arch code e.g. ia64 changes it for add/remove also. But I fail to see how it matters. > I agree that we need some kind of synchronization for threads which > read the cpu_present_map. But probably we can use a seperate mutex > for that. That would be needless complexity. > > The naming is a problem IMO for two reasons: > > > > - lock_cpu_hotplug() protects cpu_present_map as well as > > cpu_online_map (sigh, I see that Documentation/cpu-hotplug.txt > > disagrees with me, but my statement holds for powerpc, at least). > > > > - get_online_cpus() implies reference count semantics (as stated in > > the changelog) but AFAICT it really has a reference count > > implementation with read-write locking semantics. > > > > Hmm, I think there's another problem here. With your changes, code > > which relies on the mutual exclusion behavior of lock_cpu_hotplug() > > (such as pseries_add/remove_processor) will now be able to run > > concurrently. Probably those functions should use > > cpu_hotplug_begin/end instead. > > One of the primary reasons to move away from the mutex semantics for > cpu-hotplug protection, was that there were a lot of places where > lock_cpu_hotplug() was used for protecting local data structures too, > when they had nothing to do with cpu-hotplug as such, and it resulted > in a whole mess. It took people quite sometime to sort things out > with the cpufreq subsystem. cpu_present_map isn't a "local data structure" any more than cpu_online_map, and it is quite relevant to cpu hotplug. We have to maintain the invariant that the set of cpus online is a subset of cpus present. > Probably it would be a lot cleaner if we use get_online_cpus() for > protection against cpu-hotplug and use specific mutexes for serializing > accesses to local data structures. Thoughts? I don't feel like I'm getting through here. Let me restate. If I'm reading them correctly, these patches are changing the behavior of lock_cpu_hotplug() from mutex-style locking to a kind of read-write locking. I think that's fine, but the naming of the new API poorly reflects its real behavior. Conversion of lock_cpu_hotplug() users should be done with care. Most of them - those that need one of the cpu maps to remain unchanged during a critical section - can be considered readers. But a few (such as pseries_add_processor() and pseries_remove_processor()) are writers, because they modify one of the maps. So, why not: get_cpus_online -> cpumaps_read_lock put_cpus_online -> cpumaps_read_unlock cpu_hotplug_begin -> cpumaps_write_lock cpu_hotplug_end -> cpumaps_write_unlock Or something similar? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] rd: Use a private inode for backing storage
On Monday 22 October 2007 03:56, Eric W. Biederman wrote: > Nick Piggin <[EMAIL PROTECTED]> writes: > > OK, I missed that you set the new inode's aops to the ramdisk_aops > > rather than the bd_inode. Which doesn't make a lot of sense because > > you just have a lot of useless aops there now. > > Not totally useless as you have mentioned they are accessed by > the lru so we still need something there just not much. Well, the ones that are unused are totally useless ;) I would have expected them to be removed. > >> Frankly I suspect the whole > >> issue is to subtle and rare to make any backport make any sense. My > >> apologies Christian. > > > > It's a data corruption issue. I think it should be fixed. > > Of course it should be fixed. I just don't know if a backport > makes sense. The problem once understood is hard to trigger > and easy to avoid. I mean backported. That's just me though, I don't know the nuances of -stable releases. It could be that they rather not risk introducing something worse which would be fair enough. > >> Well those pages are only accessed through rd_blkdev_pagecache_IO > >> and rd_ioctl. > > > > Wrong. It will be via the LRU, will get ->writepage() called, > > block_invalidate_page, etc. And I guess also via sb->s_inodes, where > > drop_pagecache_sb might do stuff to it (although it probably escapes > > harm). But you're right that it isn't the obviously correct fix for > > the problem. > > Yes. We will be accessed via the LRU. Yes I knew that. OK it just didn't sound like it, seeing as you said that's the only way they are accessed. > The truth is > whatever we do we will be visible to the LRU. No. With my patch, nothing in the ramdisk code is visible to the LRU. Which is how it should be. > My preferences run > towards having something that is less of a special case then a new > potentially huge cache that is completely unaccounted for, that we > have to build and maintain all of the infrastructure for > independently. It's not a cache, and it's not unaccounted for. It's specified exactly with the rd sizing parameters. I don't know why you would say your patch is better in this regard. Your ramdisk backing store will be accounted as pagecache, which is completely wrong. > The ramdisk code doesn't seem interesting enough > long term to get people to do independent maintenance. > > With my patch we are on the road to being just like the ramdisk > for maintenance purposes code except having a different GFP mask. You can be using highmem, BTW. And technically it probably isn't correct to use GFP_USER. > > If you think it is a nice way to go, then I think you are > > blind ;) > > Well we each have different tastes. I think my patch > is a sane sensible small incremental step that does just what > is needed to fix the problem. It doesn't drag a lot of other > stuff into the problem like a rewrite would so we can easily verify > it. The small incremental step that fixes the problem is Christian's patch. > > It's horrible. And using truncate_inode_pages / grab_cache_page and > > new_inode is an incredible argument to save a few lines of code. You > > obviously didn't realise your so called private pages would get > > accessed via the LRU, for example. > > I did but but that is relatively minor. Using the pagecache this > way for this purpose is a well established idiom in the kernel > so I didn't figure I was introducing anything to hard to maintain. Where else is this an established idiom? > > This is making a relatively > > larger logical change than my patch, because now as well as having > > a separate buffer cache and backing store, you are also making the > > backing store pages visible to the VM. > > I am continuing to have the backing store pages visible to the VM, > and from that perspective it is a smaller change then where we are > today. It is smaller lines of code. It is a larger change. Because what you are doing is 2 things. You are firstly discontinuing the use of the buffer cache for the backing store, and secondly you are introducing a new backing store which registers an inode with the vfs and pages with the pagecache. My patch does the same thing without those two last questionable steps. You now have to treat those backing store pages as pagecache pages, and hope you have set the right flags and registered the right aops. > Not that we can truly hide pages from the VM. Any page you allocate is your private page. The problem is you're just sending them back to the VM again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] add new notifier function ,take2
On Thursday 18 October 2007 18:52, Takenori Nagano wrote: > Vivek Goyal wrote: > > > My stance is that _all_ the RAS tools (kdb, kgdb, nlkd, netdump, lkcd, > > > crash, kdump etc.) should be using a common interface that safely puts > > > the entire system in a stopped state and saves the state of each cpu. > > > Then each tool can do what it likes, instead of every RAS tool doing > > > its own thing and they all conflict with each other, which is why this > > > thread started. > > > > > > It is not the kernel's job to decide which RAS tool runs first, second > > > etc., it is the user's decision to set that policy. Different sites > > > will want different orders, some will say "go straight to kdump", other > > > sites will want to invoke a debugger first. Sites must be able to > > > define that policy, but we hard code the policy into the kernel. > > I agreed with him and I made new notifier function that users can change > the order. Priority value in notifier blocks are hardcoded. If users want > to change list order, they have to rebuild kernel. I think it is very > unhappy. Is it possible to use a single bit of common code and a single notifier for these things? Or is it too difficult? One thing I'd suggest is not to use debugfs, if it is going to be a useful end-user feature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in: Driver core: convert block from raw kobjects to core devices
On Sun, 21 Oct 2007, Kay Sievers wrote: > > [ 458.013133] scsi_disk_release: disk sda, kobj ce8be990, refcount before > > put_disk 2 > > [ 458.032420] scsi_device_dev_release: rq cd9b2000 > > Hmm, I still don't see this without the final put. Yes, I see your point. Suppose you try doing the exact same thing again, but this time un-comment the put_device() call so that the scsi_device does get released. I predict that the log will show your request_queue drops its reference to the gendisk structure _after_ the gendisk has been released. (If necessary I could send a patch with a printk at the crucial spot.) That would prove something is going wrong on your system. (BTW you don't need to include the log for when you plug in the USB drive; all that matters is what happens when you unplug it.) Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] block: Isolate the buffer cache in it's own mappings.
On Sun, Oct 21, 2007 at 02:24:46PM +1000, Nick Piggin wrote: > On Saturday 20 October 2007 07:27, Eric W. Biederman wrote: > > Currently only > > metadata is more or less in sync with the contents of /dev/hda1. > > It either is or it isn't, right? And it is, isn't it? (at least > for the common filesystems). It is not true for XFS - it's metadata is not in sync with /dev/ at all as all the cached metadata is kept in a different address space to the raw block device. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rt73usb: support for wireless in Kohjinsha subnotebook
Hi!
> This device is NOT a Ralink USB wifi adapter!
>
> Get the windows driver in this link and see for yourself.
> http://www.conitech.it/conitech/ita/risorse.asp?cod=CN402USB
> (ISSC W89C35 802.11bg WLAN USB Adapters (Native Wifi driver))
Thanks a lot. With some patches, I got driver from conitech.it to
compile and partly work on 2.6.23. I can now transmit packets but not
yet receive them.
(use Makefile.26 instead of Makefile)
Pavel
--- hal_142_o.ofic/linux/sysdef.h 2006-11-29 11:12:10.0 +0100
+++ hal_142_o/linux/sysdef.h2007-10-21 22:21:13.0 +0200
@@ -7,7 +7,7 @@
// The definition WB_LINUX is a keyword for this OS
//=
#define WB_LINUX
-#define WB_LINUX_WPA_PSK
+//#define WB_LINUX_WPA_PSK
//#define _WPA_PSK_DEBUG
//#define _IBSS_BEACON_SEQ_STICK_
Only in hal_142_o/linux: w35und.ko
Only in hal_142_o/linux: w35und.mod.c
--- hal_142_o.ofic/linux/wb35reg.c 2006-11-29 11:43:58.0 +0100
+++ hal_142_o/linux/wb35reg.c 2007-10-21 22:19:27.0 +0200
@@ -879,6 +879,7 @@
if( (pHwData->phy_type == RF_WB_242) ||
(pHwData->phy_type == RF_WB_242_1) ) // 20060619.5 Add
{
+ extern void phy_calibration_winbond(hw_data_t *phw_data, u32
frequency);
phy_calibration_winbond ( pHwData, 2412 ); // Sync operation
Wb35Reg_ReadSync( pHwData, 0x103c, );
Wb35Reg_ReadSync( pHwData, 0x1054, );
--- hal_142_o.ofic/linux/wbusb.c2006-11-29 11:02:54.0 +0100
+++ hal_142_o/linux/wbusb.c 2007-10-21 22:16:19.0 +0200
@@ -28,7 +28,6 @@
};
#else
static struct usb_driver wb35_driver = {
- .owner =THIS_MODULE,
.name = "w35und",
.probe =wb35_probe,
.disconnect = wb35_disconnect,
--- hal_142_o.ofic/wblinux.c2006-11-29 10:39:54.0 +0100
+++ hal_142_o/wblinux.c 2007-10-21 23:49:07.0 +0200
@@ -98,7 +98,8 @@
BufSize = pRxLayer1->BufferQueue[i].BufferSize;
BufAddr = pRxLayer1->BufferQueue[i].pBufferAddress;
//DataDmp(BufAddr, BufSize, 0);
- eth_copy_and_sum( skb, BufAddr, BufSize, 0 );
+ // eth_io_copy_and_sum( skb, BufAddr,
BufSize, 0 );
+ skb_copy_from_linear_data(skb, BufAddr, BufSize);
skb_put( skb, BufSize );
}
I wonder if I got skb_copy right...?
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/
[PATCH 1/9] Unionfs: security convert lsm into a static interface fix
From: Andrew Morton <[EMAIL PROTECTED]>
ERROR: "security_inode_permission" [fs/unionfs/unionfs.ko] undefined!
ERROR: "security_file_ioctl" [fs/unionfs/unionfs.ko] undefined!
Need these back.
Cc: "Serge E. Hallyn" <[EMAIL PROTECTED]>
Cc: Arjan van de Ven <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: James Morris <[EMAIL PROTECTED]>
Cc: Stephen Smalley <[EMAIL PROTECTED]>
Cc: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
security/security.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/security/security.c b/security/security.c
index 0e1f1f1..95a6733 100644
--- a/security/security.c
+++ b/security/security.c
@@ -409,6 +409,7 @@ int security_inode_permission(struct inode *inode, int
mask, struct nameidata *n
return 0;
return security_ops->inode_permission(inode, mask, nd);
}
+EXPORT_SYMBOL(security_inode_permission);
int security_inode_setattr(struct dentry *dentry, struct iattr *attr)
{
@@ -518,6 +519,7 @@ int security_file_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
{
return security_ops->file_ioctl(file, cmd, arg);
}
+EXPORT_SYMBOL(security_file_ioctl);
int security_file_mmap(struct file *file, unsigned long reqprot,
unsigned long prot, unsigned long flags,
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] Unionfs: remove for_writepages nfs workaround
This is no longer necessary since struct writeback_control no longer has a
fs_private field which lower file systems (esp. nfs) use. Plus, unionfs now
defines its own ->writepages method.
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/mmap.c | 39 ---
1 files changed, 0 insertions(+), 39 deletions(-)
diff --git a/fs/unionfs/mmap.c b/fs/unionfs/mmap.c
index b43557e..bed11c3 100644
--- a/fs/unionfs/mmap.c
+++ b/fs/unionfs/mmap.c
@@ -19,39 +19,6 @@
#include "union.h"
-/*
- * Unionfs doesn't implement ->writepages, which is OK with the VFS and
- * keeps our code simpler and smaller. Nevertheless, somehow, our own
- * ->writepage must be called so we can sync the upper pages with the lower
- * pages: otherwise data changed at the upper layer won't get written to the
- * lower layer.
- *
- * Some lower file systems (e.g., NFS) expect the VFS to call its writepages
- * only, which in turn will call generic_writepages and invoke each of the
- * lower file system's ->writepage. NFS in particular uses the
- * wbc->fs_private field in its nfs_writepage, which is set in its
- * nfs_writepages. So if we don't call the lower nfs_writepages first, then
- * NFS's nfs_writepage will dereference a NULL wbc->fs_private and cause an
- * OOPS. If, however, we implement a unionfs_writepages and then we do call
- * the lower nfs_writepages, then we "lose control" over the pages we're
- * trying to write to the lower file system: we won't be writing our own
- * new/modified data from the upper pages to the lower pages, and any
- * mmap-based changes are lost.
- *
- * This is a fundamental cache-coherency problem in Linux. The kernel isn't
- * able to support such stacking abstractions cleanly. One possible clean
- * way would be that a lower file system's ->writepage method have some sort
- * of a callback to validate if any upper pages for the same file+offset
- * exist and have newer content in them.
- *
- * This whole NULL ptr dereference is triggered at the lower file system
- * (NFS) because the wbc->for_writepages is set to 1. Therefore, to avoid
- * this NULL pointer dereference, we set this flag to 0 and restore it upon
- * exit. This probably means that we're slightly less efficient in writing
- * pages out, doing them one at a time, but at least we avoid the oops until
- * such day as Linux can better support address_space_ops in a stackable
- * fashion.
- */
static int unionfs_writepage(struct page *page, struct writeback_control *wbc)
{
int err = -EIO;
@@ -59,7 +26,6 @@ static int unionfs_writepage(struct page *page, struct
writeback_control *wbc)
struct inode *lower_inode;
struct page *lower_page;
char *kaddr, *lower_kaddr;
- int saved_for_writepages = wbc->for_writepages;
inode = page->mapping->host;
lower_inode = unionfs_lower_inode(inode);
@@ -101,14 +67,9 @@ static int unionfs_writepage(struct page *page, struct
writeback_control *wbc)
BUG_ON(!lower_inode->i_mapping->a_ops->writepage);
- /* workaround for some lower file systems: see big comment on top */
- if (wbc->for_writepages && !wbc->fs_private)
- wbc->for_writepages = 0;
-
/* call lower writepage (expects locked page) */
clear_page_dirty_for_io(lower_page); /* emulate VFS behavior */
err = lower_inode->i_mapping->a_ops->writepage(lower_page, wbc);
- wbc->for_writepages = saved_for_writepages; /* restore value */
/* b/c find_lock_page locked it and ->writepage unlocks on success */
if (err)
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] Unionfs: fix unionfs_setattr to handle ATTR_KILL_S*ID
From: Jeff Layton <[EMAIL PROTECTED]>
Don't allow unionfs_setattr to trip the BUG() in notify_change. Clear
ATTR_MODE if the either ATTR_KILL_S*ID is set. This also allows the
lower filesystem to interpret these bits in its own way.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
Cc: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/inode.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/fs/unionfs/inode.c b/fs/unionfs/inode.c
index 4e59ace..6ca52f4 100644
--- a/fs/unionfs/inode.c
+++ b/fs/unionfs/inode.c
@@ -1048,6 +1048,13 @@ static int unionfs_setattr(struct dentry *dentry, struct
iattr *ia)
bend = dbend(dentry);
inode = dentry->d_inode;
+ /*
+* mode change is for clearing setuid/setgid. Allow lower filesystem
+* to reinterpret it in its own way.
+*/
+ if (ia->ia_valid & (ATTR_KILL_SUID | ATTR_KILL_SGID))
+ ia->ia_valid &= ~ATTR_MODE;
+
for (bindex = bstart; (bindex <= bend) || (bindex == bstart);
bindex++) {
lower_dentry = unionfs_lower_dentry_idx(dentry, bindex);
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] Unionfs: support lower filesystems without writeback capability
Implement unionfs_writepages. As per
mm/filemap.c:__filemap_fdatawrite_range(), don't call our writepage if the
lower mapping has BDI_CAP_NO_WRITEBACK capability set.
Signed-off-by: Pekka J Enberg <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/mmap.c | 23 +++
fs/unionfs/union.h |1 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/fs/unionfs/mmap.c b/fs/unionfs/mmap.c
index 6440282..b43557e 100644
--- a/fs/unionfs/mmap.c
+++ b/fs/unionfs/mmap.c
@@ -144,6 +144,28 @@ out:
return err;
}
+static int unionfs_writepages(struct address_space *mapping,
+ struct writeback_control *wbc)
+{
+ int err = 0;
+ struct inode *lower_inode;
+ struct inode *inode;
+
+ inode = mapping->host;
+ lower_inode = unionfs_lower_inode(inode);
+ BUG_ON(!lower_inode);
+
+ if (!mapping_cap_writeback_dirty(lower_inode->i_mapping))
+ goto out;
+
+ /* Note: generic_writepages may return AOP_WRITEPAGE_ACTIVATE */
+ err = generic_writepages(mapping, wbc);
+ if (err == 0)
+ unionfs_copy_attr_times(inode);
+out:
+ return err;
+}
+
/*
* readpage is called from generic_page_read and the fault handler.
* If your file system uses generic_page_read for the read op, it
@@ -374,6 +396,7 @@ out:
struct address_space_operations unionfs_aops = {
.writepage = unionfs_writepage,
+ .writepages = unionfs_writepages,
.readpage = unionfs_readpage,
.prepare_write = unionfs_prepare_write,
.commit_write = unionfs_commit_write,
diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h
index 8eb2ee4..6333488 100644
--- a/fs/unionfs/union.h
+++ b/fs/unionfs/union.h
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] Unionfs: remove obsolete #define and comment
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]> --- include/linux/union_fs.h |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/include/linux/union_fs.h b/include/linux/union_fs.h index 7f8dcc3..d29318f 100644 --- a/include/linux/union_fs.h +++ b/include/linux/union_fs.h @@ -20,8 +20,5 @@ # define UNIONFS_IOCTL_INCGEN _IOR(0x15, 11, int) # define UNIONFS_IOCTL_QUERYFILE _IOR(0x15, 15, int) -/* We don't support normal remount, but unionctl uses it. */ -# define UNIONFS_REMOUNT_MAGIC 0x4a5a4380 - #endif /* _LINUX_UNIONFS_H */ -- 1.5.2.2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] Unionfs: slab api remove useless ctor parameter and reorder parameters
From: Andrew Morton <[EMAIL PROTECTED]>
fs/unionfs/super.c: In function 'unionfs_init_inode_cache':
fs/unionfs/super.c:874: warning: passing argument 5 of 'kmem_cache_create' from
incompatible pointer type
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Cc: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/super.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 515689d..7d28045 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -863,9 +863,9 @@ static void unionfs_destroy_inode(struct inode *inode)
}
/* unionfs inode cache constructor */
-static void init_once(void *v, struct kmem_cache *cachep, unsigned long flags)
+static void init_once(struct kmem_cache *cachep, void *obj)
{
- struct unionfs_inode_info *i = v;
+ struct unionfs_inode_info *i = obj;
inode_init_once(>vfs_inode);
}
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] Unionfs: convert a printk to pr_debug in release
This is mostly an informational message, not an error.
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/dentry.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index 6bab9d6..a3d7b6e 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -455,9 +455,9 @@ static void unionfs_d_release(struct dentry *dentry)
goto out;
} else if (dbstart(dentry) < 0) {
/* this is due to a failed lookup */
- printk(KERN_ERR "unionfs: dentry without lower "
- "dentries: %.*s\n",
- dentry->d_name.len, dentry->d_name.name);
+ pr_debug("unionfs: dentry without lower "
+"dentries: %.*s\n",
+dentry->d_name.len, dentry->d_name.name);
goto out_free;
}
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] Unionfs: don't bother validating dentry if it has no lower branches
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]> --- fs/unionfs/debug.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/fs/unionfs/debug.c b/fs/unionfs/debug.c index 68692d7..894bf7c 100644 --- a/fs/unionfs/debug.c +++ b/fs/unionfs/debug.c @@ -132,6 +132,9 @@ void __unionfs_check_dentry(const struct dentry *dentry, inode = dentry->d_inode; dstart = dbstart(dentry); dend = dbend(dentry); + /* don't check dentry/mnt if no lower branches */ + if (dstart < 0 && dend < 0) + goto check_inode; BUG_ON(dstart > dend); if (unlikely((dstart == -1 && dend != -1) || @@ -212,6 +215,7 @@ void __unionfs_check_dentry(const struct dentry *dentry, } } +check_inode: /* for inodes now */ if (!inode) return; -- 1.5.2.2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] Unionfs: don't printk trivial message upon normal rename-copyup
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/rename.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/unionfs/rename.c b/fs/unionfs/rename.c
index 91d41d4..1ab474f 100644
--- a/fs/unionfs/rename.c
+++ b/fs/unionfs/rename.c
@@ -40,10 +40,12 @@ static int __unionfs_rename(struct inode *old_dir, struct
dentry *old_dentry,
new_dentry, new_dentry->d_name.name,
bindex);
if (IS_ERR(lower_new_dentry)) {
- printk(KERN_ERR "unionfs: error creating directory "
- "tree for rename, bindex = %d, err = %ld\n",
- bindex, PTR_ERR(lower_new_dentry));
err = PTR_ERR(lower_new_dentry);
+ if (err == -EROFS)
+ goto out;
+ printk(KERN_ERR "unionfs: error creating directory "
+ "tree for rename, bindex=%d err=%d\n",
+ bindex, err);
goto out;
}
}
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL -mm] 0/9 Unionfs updates/cleanups/fixes
The following is a series of patches related to Unionfs. The main change
here is that unionfs now has its own ->writepages method.
These patches were tested (where appropriate) on Linus's 2.6.24 latest code
(as of v2.6.23-6623-g55b70a0), as well as the backports to
2.6.{23,22,21,20,19,18,9} on ext2/3/4, xfs, reiserfs, nfs2/3/4, jffs2,
ramfs, tmpfs, cramfs, and squashfs (where available). See
http://unionfs.filesystems.org/ to download backported unionfs code.
Please pull from the 'master' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/ezk/unionfs.git
to receive the following:
Andrew Morton (2):
Unionfs: security convert lsm into a static interface fix
Unionfs: slab api remove useless ctor parameter and reorder parameters
Erez Zadok (6):
Unionfs: support lower filesystems without writeback capability
Unionfs: don't printk trivial message upon normal rename-copyup
Unionfs: don't bother validating dentry if it has no lower branches
Unionfs: convert a printk to pr_debug in release
Unionfs: remove for_writepages nfs workaround
Unionfs: remove obsolete #define and comment
Jeff Layton (1):
Unionfs: fix unionfs_setattr to handle ATTR_KILL_S*ID
fs/unionfs/debug.c |4 +++
fs/unionfs/dentry.c |6 ++--
fs/unionfs/inode.c |7 +
fs/unionfs/mmap.c| 62 +--
fs/unionfs/rename.c |8 +++---
fs/unionfs/super.c |4 +--
fs/unionfs/union.h |1
include/linux/union_fs.h |3 --
security/security.c |2 +
9 files changed, 47 insertions(+), 50 deletions(-)
---
Erez Zadok
[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: Why are ipmi modules being loaded?
Frans Pop <[EMAIL PROTECTED]> writes: > $ cat /sys/bus/pci/devices/\:01\:00.4/class > 0x0c0701 > > The last is close, but still does not match the 0x0c0700 in modules.pcimap. > Is there some fuzzy matching going on there? The last byte (prog-if) is masked out: 0xff00. 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: atm: panic when loading clip 2nd time
From: Randy Dunlap <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 18:02:36 -0700 > From: Randy Dunlap <[EMAIL PROTECTED]> > > net/atm/clip.c crashes the kernel if it (module) is loaded, removed, > and then loaded again. Its exit call to neigh_table_clear() > should destroy the cache after freeing it. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Looks good to me, applied, thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] errors with assignments in if
Roel Kluin wrote: > I am not entirely certain about the third one: > > from fs/udf/udf_sb.h: > > #define UDF_SB_VAT(X) ( UDF_SB(X)->s_vat ) > > if it's the desired behavior then I think this should at least be changed to > > UDF_SB_VAT(sb) = udf_iget(sb, ino); > if (!(UDF_SB_VAT(sb))) On a second glance, I think it's the desired behavior. Use this patch instead. --- Errors with assignments in ifs Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c index d9af436..e6e85b7 100644 --- a/arch/arm/mach-omap2/clock.c +++ b/arch/arm/mach-omap2/clock.c @@ -651,7 +651,7 @@ static u32 omap2_get_clksel(u32 *div_sel, u32 *field_mask, break; case CM_SYSCLKOUT_SEL1: div_addr = (u32)_CLKOUT_CTRL; - if ((div_off == 3) || (div_off = 11)) + if ((div_off == 3) || (div_off == 11)) mask= 0x3; break; case CM_CORE_SEL1: diff --git a/drivers/isdn/hisax/elsa.c b/drivers/isdn/hisax/elsa.c index 948a9b2..ed610ed 100644 --- a/drivers/isdn/hisax/elsa.c +++ b/drivers/isdn/hisax/elsa.c @@ -883,7 +883,7 @@ setup_elsa_isa(struct IsdnCard *card) val += 'A' - 3; if (val == 'B' || val == 'C') val ^= 1; - if ((cs->subtyp == ELSA_PCFPRO) && (val = 'G')) + if ((cs->subtyp == ELSA_PCFPRO) && (val == 'G')) val = 'C'; printk(KERN_INFO "Elsa: %s found at %#lx Rev.:%c IRQ %d\n", - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Uartlite: speed up console output
From: Grant Likely <[EMAIL PROTECTED]>
Change the wait_tx routine to call cpu_relax() instead of udelay() to
reduce console output latency and test for the TXFULL bit instead of
TXEMPTY. That way the FIFO doesn't need to by 100% flushed before
writing the next character.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/serial/uartlite.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index dfef83f..a85f2d3 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -329,12 +329,14 @@ static struct uart_ops ulite_ops = {
static void ulite_console_wait_tx(struct uart_port *port)
{
int i;
+ u8 val;
- /* wait up to 10ms for the character(s) to be sent */
- for (i = 0; i < 1; i++) {
- if (readb(port->membase + ULITE_STATUS) & ULITE_STATUS_TXEMPTY)
+ /* Spin waiting for TX fifo to have space available */
+ for (i = 0; i < 10; i++) {
+ val = readb(port->membase + ULITE_STATUS);
+ if ((val & ULITE_STATUS_TXFULL) == 0)
break;
- udelay(1);
+ cpu_relax();
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface
On Sun, Oct 21, 2007 at 08:57:06AM +1000, James Morris wrote: > On Sat, 20 Oct 2007, Jan Engelhardt wrote: > > > >I'd like to note that I asked people who were actually affected, and had > > >examples of their real-world use to step forward and explain their use, > > >and that I explicitly mentioned that this is something we can easily > > >re-visit. > > > > I do have a pseudo LSM called "multiadm" at > > http://freshmeat.net/p/multiadm/ , quoting: > > Based on Linus' criteria, this appears to be a case for reverting the > static LSM patch. >... If you take it that strictly, the in-kernel root_plug LSM could have been considered enough reason for reverting... The interesting question is IMHO still: Were Greg and Jan the only people to write such LSMs, or how many non-abusive users that make sense as modules do really exist after 5 years? Either you can count such real-world users with your fingers or there's a reason why these modules didn't get included. IOW: Either the API has proven to not attract enough modular users or we are having a to-be-fixed problem with getting the LSMs submitted and included. > - James 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/
[PATCH] errors with assignments in if
I am not entirely certain about the third one:
from fs/udf/udf_sb.h:
#define UDF_SB_VAT(X) ( UDF_SB(X)->s_vat )
if it's the desired behavior then I think this should at least be changed to
UDF_SB_VAT(sb) = udf_iget(sb, ino);
if (!(UDF_SB_VAT(sb)))
---
Errors with assignments in ifs
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
---
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index d9af436..e6e85b7 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -651,7 +651,7 @@ static u32 omap2_get_clksel(u32 *div_sel, u32 *field_mask,
break;
case CM_SYSCLKOUT_SEL1:
div_addr = (u32)_CLKOUT_CTRL;
- if ((div_off == 3) || (div_off = 11))
+ if ((div_off == 3) || (div_off == 11))
mask= 0x3;
break;
case CM_CORE_SEL1:
diff --git a/drivers/isdn/hisax/elsa.c b/drivers/isdn/hisax/elsa.c
index 948a9b2..ed610ed 100644
--- a/drivers/isdn/hisax/elsa.c
+++ b/drivers/isdn/hisax/elsa.c
@@ -883,7 +883,7 @@ setup_elsa_isa(struct IsdnCard *card)
val += 'A' - 3;
if (val == 'B' || val == 'C')
val ^= 1;
- if ((cs->subtyp == ELSA_PCFPRO) && (val = 'G'))
+ if ((cs->subtyp == ELSA_PCFPRO) && (val == 'G'))
val = 'C';
printk(KERN_INFO
"Elsa: %s found at %#lx Rev.:%c IRQ %d\n",
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 4360c7a..353c9e8 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -1308,7 +1308,7 @@ static int udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
if (j == UDF_SB_NUMPARTS(sb))
return 1;
- if (!(UDF_SB_VAT(sb) = udf_iget(sb, ino)))
+ if (!(UDF_SB_VAT(sb) == udf_iget(sb, ino)))
return 1;
if (UDF_SB_PARTTYPE(sb, i) == UDF_VIRTUAL_MAP15) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: nfsv2 ref leak in 2.6.24?
In message <[EMAIL PROTECTED]>, Trond Myklebust writes: > > On Sat, 2007-10-20 at 17:35 -0400, Erez Zadok wrote: > > > Trond, I verified that w/ the above patch the problem is w/ nfs: the client > > leaves .nfsXXX files behind for every file unlinked while open. Let me know > > when you get a fix and I'll test it. > > Doh... Another typo. > > Trond > -- CUT HERE > From: Trond Myklebust <[EMAIL PROTECTED]> > Date: Sun, 21 Oct 2007 12:02:22 -0400 > NFS: Fix a typo in nfs_call_unlink() > > Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> > --- > > fs/nfs/unlink.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c > index ce558c2..233ad38 100644 > --- a/fs/nfs/unlink.c > +++ b/fs/nfs/unlink.c > @@ -171,7 +171,7 @@ static int nfs_call_unlink(struct dentry *dentry, struct > nfs_unlinkdata *data) > if (parent == NULL) > goto out_free; > dir = parent->d_inode; > - if (nfs_copy_dname(dentry, data) == 0) > + if (nfs_copy_dname(dentry, data) != 0) > goto out_dput; > /* Non-exclusive lock protects against concurrent lookup() calls */ > spin_lock(>i_lock); With this patch, all my nfs2/3/4 tests passed just fine. Thanks, Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interaction between Xen and XFS: stray RW mappings
On Mon, 2007-10-15 at 13:07 +0200, Andi Kleen wrote: > On Tue, Oct 16, 2007 at 12:56:46AM +1000, Nick Piggin wrote: > > Is this true even if you don't write through those old mappings? > > I think it happened for reads too. It is a little counter intuitive > because in theory the CPU doesn't need to write back non dirty lines, > but in the one case which took so long to debug exactly this happened > somehow. The problem exist also on ppc, and afaik, is due to the line being in the cache at all (either dirty (write) or not (read)), thus causing the snoop logic to hit, that is what's causing the problem vs. non cached accesses. Also, on some processors, the simple fact of having the page mapped can cause the CPU to prefetch from it even if it's not actually accessed (speculative prefetch can cross page boundaries if things are mapped). Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why are ipmi modules being loaded?
Hello! > Hmm, is lspci truncating the class code? > > > 01:00.4 Serial bus controller [0c07]: Intel Corporation 82573E KCS (Active > Management) [8086:108e] (rev 03) > > Because this smells like an IPMI-ish device. Yes, it is a IPMI class code, only older versions of lspci know nothing about it, so they at least show the base class (Serial bus controller) and then add the complete class ID in square brackets. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "How I need a drink, alcoholic in nature, after the tough chapters involving quantum mechanics!" = \pi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
H. Peter Anvin wrote: > Yeah, this is a VirtualBox problem. > > At this point, this is clearly a matter for innotek, not for the > mainstream kernel development community. Ok I will report that to Innotek , thanks for all the help and sorry for the noise. > > -hpa > Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem running a task in ring 2 on x86
Hi,
I'm trying to get a process to ring level 2 on IA-32 architecture.
Therefore I have patched the modify_ldt syscall in ldt.c to generate a
new ldt entry with rpl 2 (patch below).
Now my problem is how to get the code segment with rpl2, located in
the ldt at index 0,
loaded by a syscall, so that the application is running in ring 2
after return of that syscall.
Under kernel 2.0.x the following seemed to do this, if ptr is a
pointer to a userstack allocated with malloc:
asmlinkage int sys_set_rpl(long ptr) {
struct pt_regs *regs = (struct pt_regs *)
regs->cs = 0x6; /* first entry of ldt with rpl2 */
regs->ss = 0xE; /* 2. entry of ldt with rpl2 */
current->tss.ss2 = 0xE;
current->tss.esp2 = ptr;
return(0);
}
Now there is no tss per task and no hw context switch in the newer
kernels this isn't working in 2.6.
So if any of you have an idea to get a solution for that problem I
were very pleased.
I need this for an memory protection implementation in my bachelor thesis.
Thanks,
Michael
Here's the patch for modify_ldt:
diff -ru /usr/src/linux-2.6.22.5/arch/i386/kernel/ldt.c
arch/i386/kernel/ldt.c
--- /usr/src/linux-2.6.22.5/arch/i386/kernel/ldt.c 2007-08-23
01:23:54.0 +0200
+++ arch/i386/kernel/ldt.c 2007-10-21 22:29:12.0 +0200
@@ -172,7 +172,7 @@
return err;
}
-static int write_ldt(void __user * ptr, unsigned long bytecount, int
oldmode)
+static int write_ldt_mod(void __user * ptr, unsigned long bytecount,
int oldmode, int rpl)
{
struct mm_struct * mm = current->mm;
__u32 entry_1, entry_2;
@@ -214,6 +214,11 @@
entry_1 = LDT_entry_a(_info);
entry_2 = LDT_entry_b(_info);
+
+ /* modify the rpl from 3 to 2 */
+ if (rpl == 2)
+ entry_2 &= ~(1 << 14);
+
if (oldmode)
entry_2 &= ~(1 << 20);
@@ -228,6 +233,10 @@
return error;
}
+static int write_ldt(void __user * ptr, unsigned long bytecount, int
oldmode) {
+ return write_ldt_mod(ptr, bytecount, oldmode, 3);
+}
+
asmlinkage int sys_modify_ldt(int func, void __user *ptr, unsigned
long bytecount)
{
int ret = -ENOSYS;
@@ -245,6 +254,10 @@
case 0x11:
ret = write_ldt(ptr, bytecount, 0);
break;
+ /* create new ldt entry with rpl 2 */
+ case 4:
+ ret = write_ldt_mod(ptr, bytecount, 0, 2);
+ break;
}
return ret;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: Add a #include to the-linux-kernel.h and let us know if it helps. Does not help , now I get on top the other errors : /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/include/iprt/types.h:121: error: redefinition of typedef 'bool' /lib/modules/2.6.23-gcfa76f02/build/include/linux/types.h:33: error: previous declaration of 'bool' was here ... /* * C doesn't have bool. */ #ifndef __cplusplus # if defined(__GNUC__) # if defined(RT_OS_LINUX) && __GNUC__ < 3 typedef uint8_t bool; # else # if defined(RT_OS_DARWIN) && defined(_STDBOOL_H) #undef bool # endif typedef _Bool bool; <- line 121 # endif # else typedef unsigned char bool; # endif # ifndef true # define true (1) # endif # ifndef false # define false (0) # endif #endif Looking at include/iprt/types.h that has already #include . Yeah, this is a VirtualBox problem. At this point, this is clearly a matter for innotek, not for the mainstream kernel development community. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Sam Ravnborg wrote: > On Sun, Oct 21, 2007 at 12:15:48PM -0700, H. Peter Anvin wrote: >> Gabriel C wrote: > BITS_PER_LONG was originally set in : > > 39 #ifdef CONFIG_X86_32 > 40 # define BITS_PER_LONG 32 > 41 #else > 42 # define BITS_PER_LONG 64 > 43 #endif User land does not know anything about 'CONFIG_X86_32' right ? >> Wait... this is *user mode* code at this point? > No - it is a kernel module. > But what a messy codebase to look at... > >> Linux kernel headers aren't includable from user space without >> processing them through "make headers_install". >> >> However, from looking at the filenames in your list, it doesn't look >> like userspace code at all (although they're wrappered to the degree >> that it's somewhat hard to tell.) Thus, you're building a kernel >> module, not userland. >> >>> That is the problem. I've changed the headers virtualbox need from >>> >>> #ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. >>> >>> ( subarch headers includes are changed manually still but I think it is >>> the same problem ) >>> >>> Also all the headers got these defines with CONFIG_X86_32 does not work. >>> >>> ... >>> >>> #ifdef CONFIG_X86_32 >>> # include "foo_32.h" >>> #else >>> # include "foo_64.h" >>> #endif >>> >>> ... >>> >>> results in including both header files on my i686 box. >>> >>> I don't know what the right way is to fix that , define some who >>> CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? >> It sounds like something is seriously broken in your setup, or in the >> VirtualBox makefiles. From the looks of it, I would say the latter. > >>From the file "the-linux-kernel.h": > /* > * Include iprt/types.h to install the bool wrappers. > * Then use the linux bool type for all the stuff include here. > */ > #include > #define bool linux_bool > > And that file named "types.h" is not a kernel types.h - so we miss that > file. I guess it was pulled in by some other headerfile in the past. > > But I also notice that it latest source from VirtualBox the > line number for include of spinlock-h does not match. > > > This is most likely a combination of VirtualBox doing strange strange things > and some deep dependency missing in one of the headerfiles. > > Add a #include to the-linux-kernel.h and let us know if it > helps. Does not help , now I get on top the other errors : /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/include/iprt/types.h:121: error: redefinition of typedef 'bool' /lib/modules/2.6.23-gcfa76f02/build/include/linux/types.h:33: error: previous declaration of 'bool' was here ... /* * C doesn't have bool. */ #ifndef __cplusplus # if defined(__GNUC__) # if defined(RT_OS_LINUX) && __GNUC__ < 3 typedef uint8_t bool; # else # if defined(RT_OS_DARWIN) && defined(_STDBOOL_H) #undef bool # endif typedef _Bool bool; <- line 121 # endif # else typedef unsigned char bool; # endif # ifndef true # define true (1) # endif # ifndef false # define false (0) # endif #endif Looking at include/iprt/types.h that has already #include . > > Sam > Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] synchronize_irq needs a barrier
.../... > This patch (mostly written by Linus) fixes this by using spin > > locks instead of memory barries on the synchronize_irq() path. > > > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> > > Good for me. > > Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Hrm... not on yet. Herbert, care to resend, looks like it fell down the wrong hole in Linus mailbox :-) Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4/2.6 local TCP connect oddity
On Sun, 21 Oct 2007 19:29:02 +0200 Willy Tarreau <[EMAIL PROTECTED]> wrote: > Hi, > > On Sun, Oct 21, 2007 at 05:53:37PM +0200, Tal Kelrich wrote: > > Hi, > > > > I've run into a problem where a process trying to connect to a local > > port within the local port range eventually ends up connected to > > itself, with source port = dest port. > > > > similar behavior can be gotten by running netcat as follows: > > nc -p 1025 localhost 1025 > > > > I'm not really sure if that's a bug, but the original case was at > > least unexpected. > > It is not a bug, it is caused by the "simultaneous connect" feature of > TCP. Although rarely used, in TCP you can connect two clients > together. They just have to exchange their SYN, SYN/ACK then ACK and > bingo, they're connected. In fact, you found the easiest way to > achieve it, by using the same port. To demonstrate the feature, I'm > used to either temporarily block SYNs with iptables, or by unplugging > the cable between two machines. > Hi, It still seems confusing that a connect against localhost may randomly succeed. Here's a better example, if somewhat violent. eventually succeeds. (p=$((`cat /proc/sys/net/ipv4/ip_local_port_range|cut -f1`+1)); while true ; do nc -v -v 127.0.0.1 $p ; done) Regards, Tal -- Tal Kelrich PGP fingerprint: 3EDF FCC5 60BB 4729 AB2F CAE6 FEC1 9AAC 12B9 AA69 Key Available at: http://www.hasturkun.com/pub.txt We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why are ipmi modules being loaded?
On Sunday 21 October 2007, Dave Jones wrote: > On Sun, Oct 21, 2007 at 03:34:11PM +0200, Frans Pop wrote: > > AFAICT from modules.pcimap, ipmi_si should only be loaded for PCI ID > > [103c:121a] (which I don't have), or for devices with class c0700 > > (which I also don't have). > > Hmm, is lspci truncating the class code? > > > 01:00.4 Serial bus controller [0c07]: Intel Corporation 82573E KCS > > (Active Management) [8086:108e] (rev 03) Actually, these three look to be related (see also link below): 01:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 01:00.3 Serial controller: Intel Corporation Active Management Technology - SOL (rev 03) 01:00.4 Serial bus controller [0c07]: Intel Corporation 82573E KCS (Active Management) (rev 03) I did check the class files in /sys. For these devices those have: $ cat /sys/bus/pci/devices/\:01\:00.0/class 0x02 $ cat /sys/bus/pci/devices/\:01\:00.3/class 0x070002 $ cat /sys/bus/pci/devices/\:01\:00.4/class 0x0c0701 The last is close, but still does not match the 0x0c0700 in modules.pcimap. Is there some fuzzy matching going on there? > Because this smells like an IPMI-ish device. Hmm. Yes, guess it is -ish. It's documented in: http://download.intel.com/design/motherbd/cz/D1406801US.pdf (section 1.11.4) Looks like something that is only useful for remote management though and not for on-system management. Anyway, I've blacklisted the modules for now, but still feel that should not be necessary and there's an incorrect match happening. Thanks for the reply Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tristate and bool not enogh for Kconfig anymore
On Sun, Oct 21, 2007 at 09:45:17AM -0700, Randy Dunlap wrote: > > Is there any other way to specify that a functionality can only be built > > as a module, not built into the kernel? > > config FOO > depends on BAR && m > > restricts FOO to module-only. > > > In my firsta attempts to post about these tests my post ended up not on > > the mailing list but as a reply to Sam Ravnborg only, apologies for > > that... This is obviously the right solution. Randy - we should document this somewhere together with more kconfig tips'n'tricks. A new document or do we extend kconfig-language? 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: forcing write-back from FS - again
On Sun, 21 Oct 2007 23:19:41 +0300 Artem Bityutskiy <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > some time ago we were talking about doing write-back from inside a > file-system > (http://marc.info/?l=linux-kernel=119097117713616=2). You said that I'm > not > the only person who needs this, because the same thing is needed for delayed > allocation. > > The problem is that if we initiate write-back from prepare_write() and we are > having a dirty page lock, we deadlock in write_cache_pages() which tries to > lock the same page. > > You suggested to enhance struct writeback_control and put page that should be > skipped. > > ... > > but it does not dot actually work, because if we have two processes forcing > write-back from write_page(), they will mutually deadlock (A waits in > write_cache_pages() on a page B has locked, B waits on inode or page A has > locked). Yeah, I was just thinking that as I read this ;) > So this way is not ok, do you have any other ideas? > > We could mark page clean temporarily before doing write-back, and mark it > dirty > again, but this seems to be inefficient (although I'm not sure, need to dig > these functions deeper, but they _seem_ to traverse the radix tree and change > tags, so marking one page dirty may need to change many tags, but again, I > did > not really dig tis yet). > > I'd appreciate any suggestions. Thanks! We could just skip locked pages altogether in writeback. Perhaps in WB_SYNC_NONE mode, or perhaps add a new flag in writeback_control to select this behaviour. It _should_ be the case that the number of locked-and-dirty pages which writeback encounters is very small, so skipping locked pages during writeback-for-memory-flushing won't have any significant effect. The first step should be to add a new /proc/vmstat field to count these pages and then do broad testing (especially on blocksizehttp://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tristate and bool not enogh for Kconfig anymore
> config FOO > depends on BAR && m > > restricts FOO to module-only. Thanks alot! That really did the trick! With the following file: -8<--- config SCSI_QLA_FC tristate "QLogic QLA2XXX Fibre Channel Support" depends on PCI && SCSI && m select SCSI_FC_ATTRS select FW_LOADER ---help--- This qla2xxx driver supports all QLogic Fibre Channel PCI and PCIe host adapters. By default, firmware for the ISP parts will be loaded via the Firmware Loader interface. ISP Firmware Filename --- 21xx ql2100_fw.bin 22xx ql2200_fw.bin 2300, 2312, 6312 ql2300_fw.bin 2322, 6322ql2322_fw.bin 24xx ql2400_fw.bin Upon request, the driver caches the firmware image until the driver is unloaded. Firmware images can be retrieved from: ftp://ftp.qlogic.com/outgoing/linux/firmware/ -8<--- It is now only possible to compile the driver as a module. Best regards Henrik -- NOTE: Dear Outlook users: Please remove me from your address books. Read this article and you know why: http://newsforge.com/article.pl?sid=03/08/21/143258 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 free/used memory on Linux
Hi Vaidy, Thanks for clarifying several of my doubts. To answer your question about my intention, we currently have a system with 2 GB RAM and I need to find out the actual used and free memory so that we can decide if the same setup(applications, tmpfs etc.) can run on another system with lesser memory. Is it correct to say that the "used" field "free -m" excluding buffers/caches would give the correct idea of used memory (I mean does it take care of shared memory, shared copies of libraries etc.) ? I assume it does not include /dev/shm usage since that's also a tmpfs partition ? If so, then I can add the memory used by tmpfs partitions to the above and get the total memory used ? For eg. if my "free -m" appears as below: Linux(debug)# free -m total used free sharedbuffers cached Mem: 2014984 1030 0 80 594 -/+ buffers/cache:309 1705 Can I say that 309MB + 350 MB(size of tmpfs partitions including /dev/shm) is the used memory on my system ? Thanks, Ravi -Original Message- From: Vaidyanathan Srinivasan [mailto:[EMAIL PROTECTED] Sent: Sunday, October 21, 2007 12:01 PM To: Ravinandan Arakali (rarakali) Cc: Linux Kernel Subject: Re: Question about free/used memory on Linux Ravinandan Arakali (rarakali) wrote: > Hi kernel gurus, > I am trying to find out the memory that's used on my linux box. > I find that there are quite a few confusing metrics. How do I find out > the "true" used memory ? pagecache pages may be the reason for the confusion. Most free memory can be consumed under 'Cached' in /proc/meminfo Most of this memory is easily reclaimable and can be considered 'free'. However the cost of reclaim increases if the pages are memory mapped and/or dirty. Cached-Mapped-Dirty in /proc/meminfo can be seen as a easily freeable memory and can be added to the 'Free' in /proc/meminfo count What is your intention of finding free memory in the system? Linux kernel takes the best decision of using available RAM for file cache or applications code/data as and when needed. Ideally the 'Free' count will be a very low value on a heavily used system. If application needs more memory, then the kernel will shrink the caches and give the reclaimed memory to the application. > > 1. For eg. "free -m" shows free memory (excluding buffers/caches) as > 308 MB while I can see(from "df" output) that the the tmpfs partitions > take up about 400 MB. So, does "free -m" not consider the tmpfs > partitions ? Pages used from tmpfs should come under Mapped or Cached. They are not counted as free. > 2. I try to add up RSS field of all processes reported by "ps aux" > command. But is it true that this would be misleading in that, shared > memory used by, say 2 processes would show up twice here although > there's only one copy in memory. Also does this consider the fact that > there's only one copy of shared libraries ? > RSS is from each process point of view. If the page is present in RAM, it is counted. If the pages is shared, then it is counted in both process address space. > 3. I guess "free -m" and "top" commands use /proc/meminfo and hence > all these outputs are same ? Yes, all of them parse /proc/meminfo --Vaidy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
forcing write-back from FS - again
Hi Andrew,
some time ago we were talking about doing write-back from inside a file-system
(http://marc.info/?l=linux-kernel=119097117713616=2). You said that I'm not
the only person who needs this, because the same thing is needed for delayed
allocation.
The problem is that if we initiate write-back from prepare_write() and we are
having a dirty page lock, we deadlock in write_cache_pages() which tries to
lock the same page.
You suggested to enhance struct writeback_control and put page that should be
skipped.
I tried something like
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -61,6 +61,7 @@ struct writeback_control {
unsigned for_reclaim:1; /* Invoked from the page allocator */
unsigned for_writepages:1; /* This is a writepages() call */
unsigned range_cyclic:1;/* range_start is cyclic */
+ struct page *skip_pg; /* do not write this page back */
void *fs_private; /* For use by ->writepages() */
};
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -641,6 +641,9 @@ retry:
for (i = 0; i < nr_pages; i++) {
struct page *page = pvec.pages[i];
+ if (unlikely(page == wbc->skip_pg))
+ continue;
+
/*
* At this point we hold neither mapping->tree_lock nor
* lock on the page itself: the page may be truncated
but it does not dot actually work, because if we have two processes forcing
write-back from write_page(), they will mutually deadlock (A waits in
write_cache_pages() on a page B has locked, B waits on inode or page A has locked).
So this way is not ok, do you have any other ideas?
We could mark page clean temporarily before doing write-back, and mark it dirty
again, but this seems to be inefficient (although I'm not sure, need to dig
these functions deeper, but they _seem_ to traverse the radix tree and change
tags, so marking one page dirty may need to change many tags, but again, I did
not really dig tis yet).
I'd appreciate any suggestions. Thanks!
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] UUID: Time-based RFC 4122 UUID generator
On Sunday 21 October 2007, Theodore Tso wrote:
> On Sat, Oct 20, 2007 at 10:00:03PM +0200, Helge Deller wrote:
> > Additionally a mutex takes care of the proper locking against a mistaken
> > double creation of UUIDs for simultanious running processes.
>
> This is trickier to do in userspace, given that in userspace we have
> to worry about malicious code that might grab and hold the mutex for
> long periods of time. It is soluble, though.
Yes, userspace would need quite some overhead/syncronization/locking tricks to
get it right.
That's basically one of the reasons I prefer the in-kernel solution.
The other reason is, that due to reduced code size compared to user-space, it's
even a nice and clean solution for embedded devices.
> > + /* Determine clock sequence (max. 14 bit) */
> > + if (unlikely(!clock_seq_initialized)) {
> > + get_random_bytes(_seq, sizeof(clock_seq));
> > + clock_seq &= 0x3fff;
> > + clock_seq_started = clock_seq;
> > + clock_seq_initialized = 1;
>
> If you're really going to do this right, it should be possible to get
> and set the clock sequence from userspace, since the clock sequence is
> supposed to be retained across system bootups. Otherwise, it's
> possible for you to get really unlucky, and pick the same clock
> sequence number just at the same point that the clock gets changed.
> Not all that likely, granted, but technically it's good thing to do
> and required by RFC 4122.
Ok, I'll add that to the next version of the patch.
Do you have a suggestion how to realize that ?
I currently see two possibilities:
a) reading: userspace reads /proc/sys/kernel/random/uuid_time and parses/stores
the clock sequence number.
writing: just echo a value to /proc/sys/kernel/random/uuid_time, kernel
will use this value then as new clock sequence number.
b) add a new sysfs entry, e.g. /proc/sys/kernel/random/uuid_time_clockseq, to
read/write the current/new value
Possibility b) is probably the cleaner solution, although it adds some more
code.
What's your opinion ?
> I don't do this in the userspace library, but again that's because of
> the security issue of dealiing with multiple userids needing to update
> a file. (What we really need to do this right in userspace is the
> concept of lightweight privileged shared libraries, such as what
> Multics had.) So if that's going to be the justification to do this
> in the kernel, it should be possible to set/get the clock sequence
> number, so that in an init.d script, the clock sequence numer can be
> fetched at bootup and stored at shutdown. (Yeah, that still leaves
> open the possibility of how to handle an unclean shutdown. If you
> really wanted to be anal about guaranteeing that a clock sequence
> number was never reused, any time a clock sequence number is changed,
> a hal event could be sent that would cause a userspace helper script
> to sample the clock sequence and update the file.)
Yuk. If you really want, I'll add that hal event...
> > + /* Set the spatially unique node identifier */
> > +#ifdef CONFIG_NET
> > + read_lock(_base_lock);
> > + for_each_netdev(_net, d) {
> > + if (d->type == ARPHRD_ETHER && d->addr_len == ETH_ALEN
> > + && d != init_net.loopback_dev) {
> > + memcpy(_out[10], d->dev_addr, ETH_ALEN);
> > + netdev_found = 1;
> > + break;
> > + }
> > + }
> > + read_unlock(_base_lock);
> > +#endif
>
> This means you have to grab the dev_base_lock each time you generate a
> UUID.
Yes, IMHO this seems unavoidable.
Basically even the user-space implementation gets the lock. It's just indirect
and less efficient.
> In addition, since this code always grabs the first ethernet
> device in the list, if the list has changed --- for example, if
> someone inserts a PCMCIA wireless or ethernet card, or removes the
> card for power management reasons --- you could end up changing the
> MAC address and forcing a clock sequence bump even though it's not
> necessary. So there are a couple of things that we might do here.
Agreed.
> First of all, if we *know* that that a particular mac address is
> associated with a card which is hardwired to the machine, we're
> actually better off using it even if it is no longer present in the
> list. But aside from getting a userspace hint, I don't see a good way
> for us to implement this.
Me neither.
> What you probably should do, since you're keeping the MAC address
> around to compare if it changes, is to search the list to see if the
> MAC address is still on the list, and use it if it's there; and if it
> isn't, then you can use the first ethernet address found instead.
Yes, I'll do that in the next version of the patch.
> > + if (unlikely(!netdev_found)) {
> > + /* use bootid's nodeID if no network interface found */
>
> If CONFIG_NET is undefined, the netdev_found will always be false, so
> the unlikely()
Re: some kernel headers broken in current git ?
H. Peter Anvin wrote: > Gabriel C wrote: BITS_PER_LONG was originally set in : 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif >>> User land does not know anything about 'CONFIG_X86_32' right ? > > Wait... this is *user mode* code at this point? > > Linux kernel headers aren't includable from user space without > processing them through "make headers_install". > > However, from looking at the filenames in your list, it doesn't look > like userspace code at all (although they're wrappered to the degree > that it's somewhat hard to tell.) Thus, you're building a kernel > module, not userland. Hmm right is building an kernel modules. > >> That is the problem. I've changed the headers virtualbox need from >> >> #ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. >> >> ( subarch headers includes are changed manually still but I think it is the >> same problem ) >> >> Also all the headers got these defines with CONFIG_X86_32 does not work. >> >> ... >> >> #ifdef CONFIG_X86_32 >> # include "foo_32.h" >> #else >> # include "foo_64.h" >> #endif >> >> ... >> >> results in including both header files on my i686 box. >> >> I don't know what the right way is to fix that , define some who >> CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? > > It sounds like something is seriously broken in your setup, or in the > VirtualBox makefiles. From the looks of it, I would say the latter. > > It would help to see how gcc is invoked, but your email message doesn't > include any gcc invocations, and your "full error log" weblink is > broken, so it's hard to say. Sorry that box was down some hours I've tested some hardware. Here is a full build log , virtualbox build against cfa76f024f7c9e65169425804e5b32e71f66d0ee : http://194.231.229.228/virtualbox-build.log.tar.bz2 Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ext3 deadlock or Re: [2.6.23] tasks stuck in running state?
On Fri, 19 Oct 2007, Ray Lee wrote: > On 10/19/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > > On my main devel box, vanilla 2.6.23 on x86-64/Fedora-7, I'm seeing a > > certain behavior at least once a day. I'll start a kernel build (make > > -sj5 on this box), and it will "hang" in the following way: > > > > > 31003 ?S 0:04 sshd: [EMAIL PROTECTED]/0 > > > 31004 pts/0Ss 0:02 \_ -bash > > > 8280 pts/0S+ 0:00 \_ make ARCH=i386 -sj4 > > > 8690 pts/0Z+ 0:00 \_ [rm] > > > 8691 pts/0S+ 0:00 \_ /bin/sh -c cat > > > include/config/kernel.release 2> /dev/null > > > 8692 pts/0R+ 6:12 \_ cat > > > include/config/kernel.release > > > > Specifically, the symptom is a process, often a simple one like cat(1) > > or rm(1) or somewhere in check-headers, will stay in the running state, > > accumulating CPU time. > > > > If I Ctrl-C the build, and start over, the build will normally -not- get > > stuck at the same point, but proceed to chew through one of a bazillion > > allmodconfig builds. > > I *think* I'm seeing this with firefox under 2.6.23-rc6. I tried a > `killall -SIGSTOP firefox; killall -SIGCONT firefox` and when I looked > back it was back to life again, but that may have been a fluke. > Regardless, try that the next time it happens? Don't know if that's the same problem as above, but a few minutes ago my mail-server locked down completely. First pine froze, then more processes started freezing, then the system became unusable, ssh logins got stuck, USB- and ps/2 keyboards. I managed to get a trace with the "w" sysrq: SysRq : Show Blocked State taskPC stack pid father syslogd D c01275a3 0 2818 1 e8a1fe4c 0086 e8a1fe4c c01275a3 f7e9a200 0282 e8a1fe5c 00b5ce60 c1b05cc0 e8a1fe7c c030c8e7 e8a1ff30 c8d553c4 c0407348 c1b58b18 00b5ce60 c01277d0 c1b1ba90 c0407040 00da d5f806c0 e8a1fe84 c030c974 e8a1feb4 Call Trace: [] schedule_timeout+0x47/0xc0 [] schedule_timeout_uninterruptible+0x14/0x20 [] journal_stop+0xcb/0x270 [] journal_force_commit+0x1d/0x30 [] ext3_force_commit+0x25/0x30 [] ext3_write_inode+0x2c/0x40 [] __writeback_single_inode+0x30b/0x3e0 [] sync_inode+0x24/0x60 [] ext3_sync_file+0xc2/0xd0 [] do_fsync+0x60/0xa0 [] __do_fsync+0x28/0x40 [] sys_fsync+0xd/0x10 [] sysenter_past_esp+0x5f/0x85 === pine D c01275a3 0 6910 6243 d1f55e4c 00200082 c03c0e40 c01275a3 f7e42c80 00200282 d1f55e5c 00b5ce60 c1b05cc0 d1f55e7c c030c8e7 d1f55f30 c8d553d8 c1b58b18 c90a9e5c 00b5ce60 c01277d0 d8ae8a90 c0407040 00c3 d5f806c0 d1f55e84 c030c974 d1f55eb4 Call Trace: [] schedule_timeout+0x47/0xc0 [] schedule_timeout_uninterruptible+0x14/0x20 [] journal_stop+0xcb/0x270 [] journal_force_commit+0x1d/0x30 [] ext3_force_commit+0x25/0x30 [] ext3_write_inode+0x2c/0x40 [] __writeback_single_inode+0x30b/0x3e0 [] sync_inode+0x24/0x60 [] ext3_sync_file+0xc2/0xd0 [] do_fsync+0x60/0xa0 [] __do_fsync+0x28/0x40 [] sys_fsync+0xd/0x10 [] sysenter_past_esp+0x5f/0x85 === sendmail D c01275a3 0 7448 7446 c90a9e4c 0082 c03c0e40 c01275a3 f7e00580 0282 c90a9e5c 00b5ce60 c1b05cc0 c90a9e7c c030c8e7 c90a9f30 c8d553ec d1f55e5c c0407348 00b5ce60 c01277d0 d8ae8030 c0407040 004b d5f806c0 c90a9e84 c030c974 c90a9eb4 Call Trace: [] schedule_timeout+0x47/0xc0 [] schedule_timeout_uninterruptible+0x14/0x20 [] journal_stop+0xcb/0x270 [] journal_force_commit+0x1d/0x30 [] ext3_force_commit+0x25/0x30 [] ext3_write_inode+0x2c/0x40 [] __writeback_single_inode+0x30b/0x3e0 [] sync_inode+0x24/0x60 [] ext3_sync_file+0xc2/0xd0 [] do_fsync+0x60/0xa0 [] __do_fsync+0x28/0x40 [] sys_fsync+0xd/0x10 [] sysenter_past_esp+0x5f/0x85 === now you see why I wrote "ext3 deadlock." It's y VIA C7 system, running 2.6.23-rc9-g804b3f9a, no problems since 5 October, when the kernel has been built. No Oops / warnings in dmesg. Or has this been fixed since 23-rc9? Thanks Guennadi --- Guennadi Liakhovetski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why are ipmi modules being loaded?
On Sun, Oct 21, 2007 at 03:34:11PM +0200, Frans Pop wrote: > AFAICT from modules.pcimap, ipmi_si should only be loaded for PCI ID > [103c:121a] (which I don't have), or for devices with class c0700 (which I > also don't have). Hmm, is lspci truncating the class code? > 01:00.4 Serial bus controller [0c07]: Intel Corporation 82573E KCS (Active > Management) [8086:108e] (rev 03) Because this smells like an IPMI-ish device. Dave -- 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/
ISSC W89C35 802.11bg (was Re: rt73usb: support for wireless in Kohjinsha subnotebook)
Hi! > This device is NOT a Ralink USB wifi adapter! > > Get the windows driver in this link and see for yourself. > http://www.conitech.it/conitech/ita/risorse.asp?cod=CN402USB > (ISSC W89C35 802.11bg WLAN USB Adapters (Native Wifi driver)) You are right, sorry for confusion. Now, the strange part comes. They have linux sources on their web pages... for 2.6.9 and 2.6.11. If anyone ported them forward, please let me know, otherwise I'll take a look at porting them. 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: some kernel headers broken in current git ?
On Sun, Oct 21, 2007 at 12:15:48PM -0700, H. Peter Anvin wrote: > Gabriel C wrote: > >>>BITS_PER_LONG was originally set in : > >>> > >>> 39 #ifdef CONFIG_X86_32 > >>> 40 # define BITS_PER_LONG 32 > >>> 41 #else > >>> 42 # define BITS_PER_LONG 64 > >>> 43 #endif > >>User land does not know anything about 'CONFIG_X86_32' right ? > > Wait... this is *user mode* code at this point? No - it is a kernel module. But what a messy codebase to look at... > > Linux kernel headers aren't includable from user space without > processing them through "make headers_install". > > However, from looking at the filenames in your list, it doesn't look > like userspace code at all (although they're wrappered to the degree > that it's somewhat hard to tell.) Thus, you're building a kernel > module, not userland. > > >That is the problem. I've changed the headers virtualbox need from > > > >#ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. > > > >( subarch headers includes are changed manually still but I think it is > >the same problem ) > > > >Also all the headers got these defines with CONFIG_X86_32 does not work. > > > >... > > > >#ifdef CONFIG_X86_32 > ># include "foo_32.h" > >#else > ># include "foo_64.h" > >#endif > > > >... > > > >results in including both header files on my i686 box. > > > >I don't know what the right way is to fix that , define some who > >CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? > > It sounds like something is seriously broken in your setup, or in the > VirtualBox makefiles. From the looks of it, I would say the latter. >From the file "the-linux-kernel.h": /* * Include iprt/types.h to install the bool wrappers. * Then use the linux bool type for all the stuff include here. */ #include #define bool linux_bool And that file named "types.h" is not a kernel types.h - so we miss that file. I guess it was pulled in by some other headerfile in the past. But I also notice that it latest source from VirtualBox the line number for include of spinlock-h does not match. This is most likely a combination of VirtualBox doing strange strange things and some deep dependency missing in one of the headerfiles. Add a #include to the-linux-kernel.h and let us know if it helps. 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/
[HP6XX] - no init found (PATA issue?)
Greetings, i've got a new set of troubles, which I find hard to bugtrack. Partitions are detected properly but for some reason fails to boot. This problem arose after syncing with linux-2.6.git a week or so ago. Old userlands which have worked fine in the past doesn't anymore (the /bin/sh issue is somehow wrong). Ive noticed alot of libata problems, this one of them? Best wishes Kristoffer Ericson Linux version 2.6.23-g6a6ebaa2-dirty ([EMAIL PROTECTED]) (gcc version 3.4.5) #4 Sun Oct 21 21:41:45 PDT 2007 Booting machvec: hp6xx Node 0: start_pfn = 0xd000, low = 0xf000 Zone PFN ranges: Normal 53248 ->61440 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:53248 ->61440 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 Kernel command line: mem=32M root=/dev/sda2 console=ttySC1,115200 init=/bin/sh PID hash table entries: 128 (order: 7, 512 bytes) Using tmu for system timer Using 5.528 MHz high precision timer. Console: colour dummy device 80x25 Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Memory: 29132k/32768k available (2467k kernel code, 657k data, 84k init) Mount-cache hash table entries: 512 CPU: SH7729 net_namespace: 64 bytes NET: Registered protocol family 16 SCSI subsystem initialized DMA: Registering DMA API. DMA: Registering sh_dmac handler (4 channels). Time: SuperH clocksource has been installed. NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 1024 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 1024 bind 1024) TCP reno registered HD64461 configured at 0xb000 on irq 36(mapped into 64 to 79) HD64461: enabling PCMCIA devices Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Console: switching to colour frame buffer device 80x30 fb0: Hitachi HD64461 frame buffer device SuperH SCI(F) driver initialized sh-sci: ttySC0 at MMIO 0xfe80 (irq = 25) is a sci sh-sci: ttySC1 at MMIO 0xa4000150 (irq = 59) is a scif console [ttySC1] enabled sh-sci: ttySC2 at MMIO 0xa4000140 (irq = 55) is a irda loop: module loaded scsi0 : pata_platform ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77 ata1.00: CFA: Hitachi XX.V.3.5.0.0, Rev 0.00, max PIO4 ata1.00: 2002896 sectors, multi 0: LBA ata1.00: configured for PIO scsi 0:0:0:0: Direct-Access ATA Hitachi XX.V.3.5 Rev PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: [sda] Attached SCSI removable disk sd 0:0:0:0: Attached scsi generic sg0 type 0 hd64461_ss_init: pcmcia driver for hd64461 chipset started hd64461_init: request for irq 78 accepted hd64461_ss_init: init_socket returned with 0 hd64461_ss_init: setting socket device hd64461_ss_init: registering socket hd64461_sockets[0].socket input: HP Jornada 680 keyboard as /devices/platform/jornada680_kbd/input/input0 We have successfully registerd the keyboard driver input: HP Jornada 680 touchscreen as /devices/virtual/input/input1 sh-rtc sh-rtc: rtc core: registered sh as rtc0 TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 RPC: Registered udp transport module. RPC: Registered tcp transport module. ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation <[EMAIL PROTECTED]> sh-rtc sh-rtc: setting the system clock to 1999-01-01 00:01:27 (915148887) EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 84k freed Failed to execute /bin/sh. Attempting defaults... Kernel panic - not syncing: No init found. Try passing init= option to kernel. -- Kristoffer Ericson <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23] tasks stuck in running state?
From: Chuck Ebbert <[EMAIL PROTECTED]> Date: Sun, 21 Oct 2007 11:59:14 -0400 > IIRC -mm had something like this but it was buggy because we were > sending IPIs to each processor asking them to print their state. What's buggy about this? :-) That's exactly how it work(ed) on sparc64. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
