Re: Versioning file system

[Theodore Tso]

On Mon, Jun 18, 2007 at 03:48:15PM -0700, Jeremy Allison wrote:
> Did you ever code up forkdepot ? Just wondering ?

There is a partial implementation lieing around somewhere, but there
were a number of problems we ran into that were discussed in the
slidedeck.  Basically, if the only program accessing the files
containing forks was the Samba program calling forkdepot library, it
worked fine.  But if there were other programs (or NFS servers) that
were potentially deleting files, moving files around, the things fell
apart fairly quickly.

> Just because I now agree with you that streams are
> a bad idea doesn't mean the pressure to support them
> in some way in Samba has gone away :-).

What, even with Winfs delaying Microsoft Longwait by years before
finally being flushed?  :-)

- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 4/6] ps3: Disk Storage Driver

[Geert Uytterhoeven]

On Mon, 18 Jun 2007, David Miller wrote:
> What I really care about is what will work transparently for existing
> userspace.  In particular, distribution installers and existing tools
> like fdisk.
> 
> When a slice it being exported, it's not being exported like that so
> that the client can just spam a disk label into it, it's for exporting
> one slice.  So we might want (using the scsi naming as an arbitrary
> example case) /dev/sda1 to be created but not /dev/sda
> 
> How exactly do you envision this kind of thing working?

How do distribution installers handle USB disks and memory cards? Some tend
to be partitioned, some don't.

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:+32 (0)2 700 8453 
Fax:  +32 (0)2 700 8622 
E-mail:   [EMAIL PROTECTED] 
Internet: http://www.sony-europe.com/

Sony Network and Software Technology Center Europe  
A division of Sony Service Centre (Europe) N.V. 
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium  
VAT BE 0413.825.160 · RPR Brussels  
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

Re: Versioning file system

[Theodore Tso]

On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
> The main difference appears to be the potential size.  Both extended
> attributes and forks allow for extra data that I neither want or need.
> But once the extra space is large enough to hide a rootkit in, it
> becomes a security problem instead of just something pointless.

The other difference is that you can't execute an extended attribute.

You can store kvm/qemu, a complete virtualization enviroment, shared
libraries, and other executables all inside a forks inside a file, and
then execute programs/rootkit out of said file fork(s).

As I mentioned in my LCA presentation, one system administrator
refused to upgrade beyond Solaris 8 because he thought forks were good
for nothing but letting system crackers hide rootkits that wouldn't be
detected by programs like tripwire.  The question then is why in the
world would we want to replicate Sun's mistakes?

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Char: istallion, init+locking fixes

[Jiri Slaby]

Ingo Korb napsal(a):
> Move brdp->iosize assignment in stli_initecp up a few lines to stop the
> driver from requesting an I/O region of length 0.
> 
> Remove spin_lock_irqsave/spin_unlock_irqrestore from __stli_sendcmd as
> all users of that function take the lock already.
> 
> Signed-off-by: Ingo Korb <[EMAIL PROTECTED]>
> ---
> One thing I dislike about this driver: It polls its cards every jiffy to
> look for new data. The cards are able to use interrupts (some of the
> drivers for other OSes use them), but as far as I know there is no open
> documentation. Unfortunately the DOS driver (probably easiest to
> analyze) also uses polling. =(
> 
> 
> diff --git a/drivers/char/istallion.c b/drivers/char/istallion.c
> index 7b279d1..0bc1c37 100644
> --- a/drivers/char/istallion.c
> +++ b/drivers/char/istallion.c
> @@ -2168,8 +2168,6 @@ static void __stli_sendcmd(struct stlibrd *brdp, struct 
> stliport *portp, unsigne
>   unsigned char __iomem *bits;
>   unsigned long flags;

Remove the flags and you will see the bug, you introduced ;).

> - spin_lock_irqsave(&brd_lock, flags);
> -
>   if (test_bit(ST_CMDING, &portp->state)) {
>   printk(KERN_ERR "STALLION: command already busy, cmd=%x!\n",
>   (int) cmd);
> @@ -2194,7 +2192,6 @@ static void __stli_sendcmd(struct stlibrd *brdp, struct 
> stliport *portp, unsigne
>   writeb(readb(bits) | portp->portbit, bits);
>   set_bit(ST_CMDING, &portp->state);
>   EBRDDISABLE(brdp);
> - spin_unlock_irqrestore(&brd_lock, flags);
>  }


regards,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] V4L: stk11xx, add a new webcam driver

[Jiri Slaby]

Oliver Neukum napsal(a):
> Am Freitag, 15. Juni 2007 schrieb Jiri Slaby:
>> +struct stk11xx_frame_buf {
>> +   void *data;
>> +   volatile int filled;
>> +   struct stk11xx_frame_buf *next;
>> +};
>> +
> 
> What's the "volatile" doing here?

removed (s/volatile/unsigned/), thanks,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/5] m68k 53c700 SCSI

[Geert Uytterhoeven]

Hi James,

On Sun, 17 Jun 2007, Geert Uytterhoeven wrote:
> These patches add support for m68k to the 53c700 SCSI core and introduce new
> drivers for various m68k hardware using this 53c700 SCSI core, to replace the
> just removed drivers using the old 53c7xx SCSI core.
> 
>   [1] [PATCH] 53c700 scsi: m68k support for the 53c700 SCSI core
>   [2] [PATCH] 53c700 scsi: m68k BVME6000 NCR53C710 SCSI
>   [3] [PATCH] 53c700 scsi: m68k MVME16x NCR53C710 SCSI
>   [4] [PATCH] 53c700 scsi: Amiga 4000T NCR53c710 SCSI
>   [5] [PATCH] 53c700 scsi: Amiga Zorro NCR53c710 SCSI
> 
> Please apply for 2.6.23. Thx!

Apparently I made some major mistakes when preparing these patches.
Here are the fixes.
---

Fixup m68k 53c700 drivers:
  - a4000t.c: Add missing include, needed in some configurations
  - bvme6000_scsi.c: Kill bogus opening brace
  - zorro7xx.c: Remove MODULE_DEVICE_TABLE, it should be part of another
patch

Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
 drivers/scsi/a4000t.c|1 +
 drivers/scsi/bvme6000_scsi.c |2 +-
 drivers/scsi/zorro7xx.c  |1 -
 3 files changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/scsi/a4000t.c
+++ b/drivers/scsi/a4000t.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- a/drivers/scsi/bvme6000_scsi.c
+++ b/drivers/scsi/bvme6000_scsi.c
@@ -112,7 +112,7 @@ static int __init bvme6000_scsi_init(voi
int err;
 
err = driver_register(&bvme6000_scsi_driver);
-   if (err) {
+   if (err)
return err;
 
bvme6000_scsi_device = platform_device_register_simple("bvme6000-scsi",
--- a/drivers/scsi/zorro7xx.c
+++ b/drivers/scsi/zorro7xx.c
@@ -65,7 +65,6 @@ static struct zorro_device_id zorro7xx_z
},
{ 0 }
 };
-MODULE_DEVICE_TABLE(zorro, zorro7xx_zorro_tbl);
 
 static int __devinit zorro7xx_init_one(struct zorro_dev *z,
   const struct zorro_device_id *ent)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] atmel_lcdfb: Fix STN LCD support

[Haavard Skinnemoen]

On Fri, 15 Jun 2007 10:50:12 +0200
Nicolas Ferre <[EMAIL PROTECTED]> wrote:

> From: Nicolas Ferre <[EMAIL PROTECTED]>
> 
> Fixes STN LCD support for the atmel_lcdfb framebuffer driver.
> 
> Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]>

Looks correct to me. Although...

> Index: b/drivers/video/Kconfig
> ===
> --- a/drivers/video/Kconfig   2007-05-14 11:02:16.0 +0200
> +++ b/drivers/video/Kconfig   2007-06-13 11:04:10.0 +0200
> @@ -701,6 +701,16 @@
> Say Y if you want to map Frame Buffer in internal SRAM. Say N if you 
> want
> to let frame buffer in external SDRAM.
>  
> +config FB_ATMEL_STN
> + bool "Use a STN display with AT91/AT32 LCD Controller"
> + depends on FB_ATMEL && ARCH_AT91SAM9261
> + default n
> + help
> +   Say Y if you want to connect a STN LCD display to the AT91/AT32 LCD
> +   Controller. Say N if you want to connect a TFT.
> +
> +   If unsure, say N.
> +

I don't think it's appropriate to include chip-specific options here.
This option will not affect the driver at all, it will only affect the
board-specific setup code, so IMO it should be under Platform-specific
options or something like that.

Also, the text says AT91/AT32 but it depends on one particular AT91
chip.

I haven't had a chance to test it since I don't have any STN displays
around, but I'll try forwarding it to someone who has.

Haavard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 a strange behavior of copy_to_user() in ioctl call

[Jiri Slaby]

News Letter napsal(a):
> Hi,
> 
> I need some help here to understand copy_to_user(). I encountered a
> strange copy_to_user() behavior when working on CentOS from Redhat
> (kernel version 2.6.9-22.ELsmp, x86_64 CPU).
> 
> For a kernel module, I wrote a ioctl call to allow user mode program
> to get some kernel data information. When a user program called the
> ioctl, most of the time the ioctl failed with EFAULT, failed at
> copy_to_user(). It succeeded a few times after a lot of running.
> 
> Failed message indicated copy_to_user() returned 3840 (which is
> exactly what is asked to copy, PAGE_SIZE-256). The printed value of
> the user pointer were identical for successful ioctl calls and failed
> ioctl calls. Some relevant details are at the end of this email. I
> tried with calloc(PAGE_SIZE, 1), static buffer and automatic variable
> on stack in user mode program. They gave the same result.
> 
> I appreciate any help.
> 
> Best,
> Jasper
> 
> The ioctl call structure is defined as follows,
> 
> struct ioctl_get_info
> {
>   ... /* some other information */
>   unsigned long user_pointer;
>   unsigned user_buffer_len;
>   unsigned returned_len;
>   ... /* some other information */
> };
> 
> Inside kernel module, a page is allocated with :
> 
> static unsigned char *test_page;
> 
> static init_test(void)
> {
>   test_page = __get_free_pages(GFP_KERNEL, 0);
>   if (!test_page)
>  /* some error handling */
> }
> 
> static int test_ioctl(struct inode * inode, struct file * filp,
> unsigned int cmd_in, unsigned long arg)
> {
>   struct ioctl_get_info igi;
>   unsigned size;
>   unsigned long remain;
> 
>  size = IOC_SIZE(cmd_in);
>  if (size != sizeof(igi))
>
> 
>  ... /* some sanity checking */
> 
>  if (!access_ok(VERIFY_READ, (char *)arg, size))
>  {
>  printk(KERN_INFO "...");
>  return -EFAULT;
>   }
> 
>   if (copy_from_user(&igi, (char *)arg, size) != 0)
>   {
>   printk(... ...)
>   return -EFAULT;
>   }
> 
>   if (!access_ok(VERIFY_WRITE, (char *)igi.user_pointer,
> igi.user_buffer_len))
>   {
>   printk(...);
>   return -EFAULT;
>   }
> 
>   size = PAGE_SIZE - 256;
>   if (size > igi.user_buffer_len)
>  size = igi.user_buffer_len;
>   printk("igi.user_pointer %p size %u\n", igi.user_pointer, size);

Weird. Are you sure, that previous access_ok doesn't fail with this 'size', not
the 'igi.user_buffer_len'? Anyway, you can remove these access_ok checks, since
they are provided by copy_from/to_user after debugging.

>   if ((remain = copy_to_user((char *)igi.user_pointer, page + 256,
> size)) != 0)
>   {
>  printk ("Failed to copy from user at %p remain %lu asked %u\n",
> igi.user_pointer, remain, asked);
> /* failed here */
>  return -EFAULT;
>   }
>igi.returned_len = size;
> 
>   /* copy other information */
> 
>   return 0;
> }

regards,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Versioning file system

[Jack Stone]

Kyle Moffett wrote:
> On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
>>> The question remains is where to implement versioning: directly in
>>> individual filesystems or in the vfs code so all filesystems can use it?
>>
>> Or not in the kernel at all.  I've been doing versioning of the types
>> I described for years with user space code and I don't remember
>> feeling that I compromised in order not to involve the kernel.
>>
>> Of course, if you want to do it with snapshots and COW, you'll have to
>> ask where in the kernel to put that, but that's not a file versioning
>> question; it's the larger snapshot question.
> 
> What I think would be particularly interesting in this domain is
> something similar in concept to GIT, except in a file-system:
>   1) Redundancy is easy, you just ensure that you have at least "N"
> distributed copies of each object, where "N" is some function of the
> object itself.
>   2) Network replication is easy, you look up objects based on the SHA-1
> stored in the parent directory entry and cache them where needed (IE:
> make the "N" function above dynamic based on frequency of access on a
> given computer).
>   3) Snapshots are easy and cheap; an RO snapshot is a tag and an RW
> snapshot is a branch.  These can be easily converted between.
>   4) Compression is easy; you can compress objects based on any
> arbitrary configurable criteria and the filesystem will record whether
> or not an object is compressed.  You can also compress differently when
> archiving objects to secondary storage.
>   5) Streaming fsck-like verification is easy; ensure the hash name
> field matches the actual hash of the object.
>   6) Fsck is easy since rollback is trivial, you can always revert to an
> older tree to boot and start up services before attempting resurrection
> of lost objects and trees in the background.
>   7) Multiple-drive or multiple-host storage pools are easy:  Think the
> git "alternates" file.
>   8) Network filesystem load-balancing is easy; SHA-1s are essentially
> random so you can just assign SHA-1 prefixes to different systems for
> data storage and your data is automatically split up.
> 
> 
> Other issues:
> 
> Q. How do you deal with block allocation?
> A. Same way other filesystems deal with block allocation. 
> Reference-counting gets tricky, especially across a network, but it's
> easy to play it safe with simple cross-network refcount-journalling. 
> Since the _only_ thing that needs journalling is the refcounts and
> block-free data, you need at most a megabyte or two of journal.  If in
> doubt, it's easy to play it safe and keep an extra refcount around for
> an in-the-background consistency check later on.  When networked-gitfs
> systems crash, you just assume they still have all the refcounts they
> had at the moment they died, and compare notes when they start back up
> again.  If a node has a cached copy of data on its local disk then it
> can just nonatomically increment the refcount for that object in its own
> RAM (ordered with respect to disk-flushes, of course) and tell its peers
> at some point.  A node should probably cache most of its working set on
> local disk for efficiency; it's trivially verified against updates from
> other nodes and provides an easy way to keep refcounts for such data. 
> If a node increments the refcount on such data and dies before getting
> that info out to its peers, then when it starts up again its peers will
> just be told that it has a "new" node with insufficient replication and
> they will clone it out again properly.  For networked
> refcount-increments you can do one of 2 things: (1) Tell at least X many
> peers and wait for them to sync the update out to disk, or (2) Get the
> object from any peer (at least one of whom hopefully has it in RAM) and
> save it to local disk with an increased refcount.
> 
> Q. How do you actually delete things?
> A. Just replace all the to-be-erased tree and commit objects before a
> specified point with "History erased" objects with their SHA-1's
> magically set to that of the erased objects.  If you want you may delete
> only the "tree" objects and leave the commits intact.  If you delete a
> whole linear segment of history then you can just use a single "History
> erased" commit object with its parent pointed to the object before the
> erased segment.  Probably needs some form of back-reference storage to
> make it efficient; not sure how expensive that would be.  This would
> allow making a bunch of snapshots and purging them logarithmically based
> on passage of time.  For instance, you might have snapshots of every 5
> minutes for the last hour, every 30 minutes for the last day, every 4
> hours for the last week, every day for the last month, once per week for
> the last year, once per month for the last 5 years, and once per year
> beyond that.
> 
> That's pretty impressive data-recovery resolution, and it accounts for
> only 200 unique commits after it's been running for 10

Re: [PATCH/RFC] oops and panic message logging to MTD

[Artem Bityutskiy]

On Mon, 2007-06-18 at 17:31 +0100, Richard Purdie wrote:
> +static int mtdoops_erase_block(struct mtd_info *mtd, int offset)
> +{
> + struct erase_info erase;
> + DECLARE_WAITQUEUE(wait, current);
> + wait_queue_head_t wait_q;
> + int ret;
> +
> + init_waitqueue_head(&wait_q);
> + erase.mtd = mtd;
> + erase.callback = mtdoops_erase_callback;
> + erase.addr = offset;
> + if (mtd->erasesize < OOPS_PAGE_SIZE)
> + erase.len = OOPS_PAGE_SIZE;

It seems to me that your code won't work if mtd->erasesize <
OOPS_PAGE_SIZE anyway, so this check should not be here I guess.


> + ret = mtd->read(mtd, cxt->nextpage * OOPS_PAGE_SIZE, 4,
> + &retlen, (u_char *) &count);
> + if ((retlen != 4) || (ret < 0)) {
> + printk(KERN_ERR "mtdoops: Read failure at %d (%d of 4 read)"
> + ", err %d.\n", cxt->nextpage * OOPS_PAGE_SIZE,
> + retlen, ret);
> + return 1;
> + }

mtd->read() returns -EUCLEAN in case of a correctable bit-flip, ignore
this error code here and elsewhere as well please.

> +static void mtdoops_prepare(struct mtdoops_context *cxt)
> +{
> + struct mtd_info *mtd = cxt->mtd;
> + int i = 0, j, ret, mod;
> +
> + /* We were unregistered */
> + if (!mtd)
> + return;
> +
> + mod = (cxt->nextpage * OOPS_PAGE_SIZE) % mtd->erasesize;
> + if (mod != 0) {
> + cxt->nextpage = cxt->nextpage + ((mtd->erasesize - mod) / 
> OOPS_PAGE_SIZE);
> + if (cxt->nextpage > cxt->oops_pages)
> + cxt->nextpage = 0;
> + }
> +
> + while (mtd->block_isbad &&
> + mtd->block_isbad(mtd, cxt->nextpage * OOPS_PAGE_SIZE)) {

Well, mtd->block_isbad() may return error, unlikely, bu still. You also
ignore the error at other places.

> +badblock:
> + printk(KERN_WARNING "mtdoops: Bad block at %08x\n",
> + cxt->nextpage * OOPS_PAGE_SIZE);
> + i++;
> + cxt->nextpage = cxt->nextpage + (mtd->erasesize / 
> OOPS_PAGE_SIZE);
> + if (cxt->nextpage > cxt->oops_pages)
> + cxt->nextpage = 0;
> + if (i == (cxt->oops_pages / (mtd->erasesize / OOPS_PAGE_SIZE))) 
> {
> + printk(KERN_ERR "mtdoops: All blocks bad!\n");
> + return;
> + }
> + }
> +
> + for (j = 0, ret = -1; (j < 3) && (ret < 0); j++)
> + ret = mtdoops_erase_block(mtd, cxt->nextpage * OOPS_PAGE_SIZE);

Ugh, why do you make it this difficult way instead of

for (all EBs) {
ret = erase()
if (ret == -EIO) {
markbad();
} else
return err;
}

> +
> + if (ret < 0) {
> + if (mtd->block_markbad)
> + mtd->block_markbad(mtd, cxt->nextpage * OOPS_PAGE_SIZE);
> + goto badblock;

Please, mark EB as bad only in case of -EIO. Also, do not ignore error
code of mtd->block_markbad()


Is it possible to re-structure the code and erase/check if EB is bad in
_one_ cycle (thus avoiding this goto which is difficult to understand)?

Surely all you want is to format the partition. So make a loop, skip bad
EBs and erase good ones. In case of erase failure (-EIO) mark the EB as
bad.

> +static int find_next_position(struct mtdoops_context *cxt)
> +{
> + struct mtd_info *mtd = cxt->mtd;
> + int page, maxpos = 0;
> + u32 count, maxcount = 0x;
> + size_t retlen;
> +
> + for (page = 0; page < cxt->oops_pages; page++) {
> + mtd->read(mtd, page * OOPS_PAGE_SIZE, 4, &retlen, (u_char *) 
> &count);

Please, check return code here.

-- 
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/

[PATCH] net: Make skb_seq_read unmap the last fragment

[Olaf Kirch]

From: Olaf Kirch <[EMAIL PROTECTED]>

Make skb_seq_read unmap the last fragment

Having walked through the entire skbuff, skb_seq_read would leave the
last fragment mapped.  As a consequence, the unwary caller would leak
kmaps, and proceed with preempt_count off by one. The only (kind of
non-intuitive) workaround is to use skb_seq_read_abort.

This patch makes sure skb_seq_read always unmaps frag_data after having
cycled through the skb's paged part.

Signed-off-by: [EMAIL PROTECTED]
---
 net/core/skbuff.c |5 +
 1 file changed, 5 insertions(+)

Index: build-2.6/net/core/skbuff.c
===
--- build-2.6.orig/net/core/skbuff.c
+++ build-2.6/net/core/skbuff.c
@@ -1706,6 +1706,11 @@ next_skb:
st->stepped_offset += frag->size;
}
 
+   if (st->frag_data) {
+   kunmap_skb_frag(st->frag_data);
+   st->frag_data = NULL;
+   }
+
if (st->cur_skb->next) {
st->cur_skb = st->cur_skb->next;
st->frag_idx = 0;

-- 
Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Quota netlink interface

[Jan Kara]

On Mon 18-06-07 12:01:03, Randy Dunlap wrote:
> On Mon, 18 Jun 2007 14:14:55 +0200 Jan Kara wrote:
> 
> >   Hello,
> > 
> >   I've written a patch implementing quota netlink interface. Whenever some
> > event happens (like user exceeding softlimit), a message is sent to
> > userpace. Then, in userspace we can decide what to do with the message -
> > print it to console, show a dialog or whatever... I've also written a new
> > daemon that listens to netlink and sends the received message to DBus and/or
> > to the console the user has last written to.
> >   If somebody is interested in trying it out, he can checkout latest
> > quota-tools CVS and I can provide him with the modified libnl providing
> > better support for generic netlink handling.
> 
> 
> +config QUOTA_NETLINK_INTERFACE
> + bool "Report quota messages through netlink interface"
> + depends on QUOTA
> + select NET
> + help
> +   If you say Y here, quota warnings (about exceeding softlimit, reaching
> +   hardlimit, etc.) will be reported through netlink interface. If 
> unsure,
> +   say Y.
> 
> 
> Using "select" is either evil or OK, but only OK for "library-type" code.
> It should never be used to pull in a complete subsystem like NET does
> (even though SCSI_NETLINK does this same thing, sadly).
  OK, I can make it 'depends on NET' instead. I guess it's no problem in
this case since whoever wants quota is going to have NET enabled.
  The problem I sometimes have with 'depends on' is that the option is
invisible until you have enabled all the dependencies so it's hard to
  a) find out that there exists and interesting feature (because it depends
on something you are not used to turn on).
  b) you know the feature exists but you have to dig in Kconfigs to find out
what you have to enable first...

  Maybe we could improve Kconfig to support other type of dependency that
shows you the option even if these dependencies are not satisfied (probably in
some other color) but allows you to only view help and unresolved
dependencies...

Honza
-- 
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Quota netlink interface

[Jiri Kosina]

On Tue, 19 Jun 2007, Jan Kara wrote:

>   OK, I can make it 'depends on NET' instead. I guess it's no problem in
> this case since whoever wants quota is going to have NET enabled.
>   The problem I sometimes have with 'depends on' is that the option is
> invisible until you have enabled all the dependencies so it's hard to
>   a) find out that there exists and interesting feature (because it depends
> on something you are not used to turn on).
>   b) you know the feature exists but you have to dig in Kconfigs to find out
> what you have to enable first...
>   Maybe we could improve Kconfig to support other type of dependency that
> shows you the option even if these dependencies are not satisfied (probably in
> some other color) but allows you to only view help and unresolved
> dependencies...

(added Roman to CC)

I'd really appreciate this feature for precisely the same reasons indeed. 
Roman, what do you think about it?

Thanks,

-- 
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 19, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> On Tuesday 19 June 2007 02:44:32 Alexandre Oliva wrote:
>> GPLv3 forbids tivoization, therefore developer has requirement for
>> tivoization in the license, therefore GPLv3 forbidding tivoization
>> is bad.

> However, my argument is straight logic, nothing "circular" about it.  :)
> Replacing "X" in my logic path above with "tivoization" and "license" 
> with "GPLv3", as you've done, does produce a valid chain of logic.  

Yes.  Isn't it funny though that tivoization became necessary as a
consequence of GPLv3 forbidding it?

> FWIW the Linux Kernel shouldn't be as homogeneous a population as it
> is.

Nah.  Communities tend to form around similar values.  Linus started
the community.

>> Wait a minute, these figures you made up are for the tivoized hardware
>> (no changes allowed to the GPLed software in it), or for the
>> non-tivoized hardware (changes allowed to the GPLed software in it)?

> Actually, any generic "TiVO"-like hardware - whether it is tivoized or not. 

So your claim is that a user's possibility to scratch her own itches
makes no difference whatsoever as to their amount of contributions she
is likely to make?

Am I the only one who thinks this is utter nonsense?

>> > those who will contribute them back: 38 (25%)

>> Regardless of what you meant, this is 38 developers *on top* of
>> however many the company pays to work on that, unless you're jumping
>> the gun and spoiling the multi-part argument.

> 38ppm is a fairly small amount, regardless.

Yes.  And your estimates are way too low too, FWIW.  Any reason why
you changed your mind as to the 10% before?

>> > What you are arguing is that people should abandon

>> I'm not arguing any such thing.  Where's any such argument above?

>> At this point, I'm only comparing a tivoized device with a
>> non-tivoized device.  Nothing but it.

> You've been making the argument the entire time you've been arguing that 
> the "anti-tivoization" language in the GPLv3 is necessary.

And then I decided that, since the argument wasn't getting through, I
had to break it into pieces.

The piece I've presented so far has no abandonment whatsoever.  It's a
comparison between two different situations, to evaluate which of them
brings more contributions from users, regardless of the contributions
from the vendor, that are assumed to be the same, since there's no
material difference as far as the vendor is concerned (as in, vendor
has no reason to tivoize)

So your arguments bear zero relationship with the piece I've
proposed.  Can you see that?



> I think I'd rather see a guaranteed increase of developers - even if
> it is only 10 - rather than hoping that the potential pool of 38
> actually follows through. Wouldn't you?

Yes.  How does this relate with the piece of the argument I've
proposed so far, or the whole argument I've posted before?

Answer: It doesn't.  At all.  You're just showing you didn't
understand the argument.  Which shows why I have to explain it piece
by piece.  Which suggests you shouldn't try to jump to conclusions.



Once again, now with clearer starting conditions (not intended to
match TiVo in any way, BTW; don't get into that distraction)


Vendor doesn't care about tivoizing, their business works the same
either way.

Vendor's employees will contribute the same, one way or another, so
their contributions are out of the equation.

Users get source code in either case, and they can modify it and share
it.  They're in no way stopped from becoming part of the community.


Given these conditions:

In a tivoized device, users will be unable to scratch their itches.
This doesn't stop them from contributing to the project, but they may
lack self-interest motivation to contribute, because they won't be
able to use their modifications in the device they own.

In a non-tivoized device, users can scratch their itches.  They can
contribute just as much as they would in a tivoized device, but since
they can use the changes they make to make their own devices work
better for them, this works as a motivator for them to make changes,
and perhaps to contribute them.  Therefore, they will tend to
contribute more.


Can you point out any flaw in this reasoning, or can we admit it as
true?

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 4/6] ps3: Disk Storage Driver

[Christoph Hellwig]

On Mon, Jun 18, 2007 at 11:07:31PM -0700, David Miller wrote:
> The main disk I/O block read and write is done using descriptors
> sent to the disk server.  SCSI pass-through is provided (optionally)
> so that disk analysis tools can do things like MODE_SENSE on the
> disk.

SG_IO can easily be implemented for block devices.  See cciss in
current mainline for an example.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mea culpa on the meaning of Tivoization

[Hans-Jürgen Koch]

Am Dienstag 19 Juni 2007 04:46 schrieb Alexandre Oliva:
> On Jun 18, 2007, Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
> 
> > Am Montag 18 Juni 2007 23:18 schrieb Alexandre Oliva:
> >> On Jun 18, 2007, Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
> >> 
> >> >> Vendor would be entitled to the benefit of the doubt as to the
> >> >> motivations in this case, so it would likely be unenforceable anyway.
> >> 
> >> > Right. If GPL v3 comes out, there'll probably be a new task for
> >> > hardware development engineers: How to find excuses for hardware that
> >> > prevents software modifications and how to conceal the true intent.
> >> 
> >> Yup.  And then GPLv4 will have to plug whatever holes they find to
> >> disrespect users' freedoms.  That's how I expect the game to be
> >> played.
> 
> > If you were right and it turned out that way, the whole GPL would
> > become so ridiculous that it won't have any of its intended effects.
> 
> How so?  The intended effects are to protect users' freedoms, by
> requiring them to be respected.  If we keep on plugging holes as they
> appear, it will keep close to achieving its intended effects.  

No. Credible licenses should be simple like physical laws. Newton's law
is expressed in terms of a single mathematical equation. That's why it's
still valid, and you still learn it at school although meanwhile people
know that there are limitations to it.

If you come up with a new version of a license every year, you will only
weaken it. Please note that quantum mechanics is _not_ such a hole-plugging
addition to Newton's law. It's a new simple physical law, expressed in terms
of a single simple mathematical equation that contains the old law as a
border case. If that were not the case, it would have never been accepted.

If you want a GPLv3, please make it simple and make it contain GPLv2 as
a border case. The current draft isn't like that.

> It's 
> earlier versions of the license that will get more and more distant
> from it.

No. GPLv2 is a simple set of rights and restrictions that's easy to
understand and therefore accepted by many courts all over the world.
I cannot see any danger for the code I put under it, at least none
that would be mitigated by GPLv3.

> 
> > As far as the kernel is concerned, I expect the game's played by
> > simply keeping GPLv2. And I like it that way.
> 
> Just think about it...  What if, today, some law passed, or some court
> decision came up, that rendered a significant defense provision of
> GPLv2 or GPLv3 ineffective?

The best way to prevent that is to make the license simple and easy to 
follow. If many important open source software developers have problems
with the wording of a license, lawyers and judges will have them, too.

> 
> GPLv4 could plug that, and anyone using GPLvN+ would be able to switch
> to it immediately.  This wouldn't revoke previous licenses, of course,
> but further developments could be made under the newer license, and at
> least those could still be defended, and, as time elapsed, earlier
> versions of the software would become less and less relevant, to the
> point that the holes in their license also become less and less
> relevant, until copyright finally expires and they enter the public
> domain.

Ah, now I get the point. Yes, that's one in favor of a complicated and
confusing license. You can lengthen court proceedings until copyright
expires...

> 
> 
> The distrust for the FSF led to this very short-sighted decision of
> painting the Linux community into a corner from which it is very
> unlikely to be able to ever leave, no matter how badly it turns out to
> be needed.  

I'm neither in a corner nor do I feel the need for a different license.
I've got some code in the kernel, and I've got it under GPLv2, and I'm
happy with it. It's the FSF that thinks I should see myself in a corner. 


> Let's just hope it never is, or that some influx of 
> long-sighted comes in 

Kernel programmers are short-sighted? What kind of arrogance is that?

> and introduces mechanisms for the license of 
> Linux to be patched, should this ever be needed.  

You know pretty well that Linus clearly said he would change the license
when _he_ thinks it's needed. The point is that _you_ want him to change
the license to support _your_ political ideas.

> I'm not even talking 
> about GPLv2+, there are many other ways to accomplish this, that I've
> already mentioned in another posting in another recent huge thread.
>

I partly read that "recent huge thread". Linus elaborated his point of 
view in detail, and I very much share his opinion.

Hans

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Daniel Hazelton]

On Tuesday 19 June 2007 04:04:52 Alexandre Oliva wrote:
> On Jun 19, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > On Tuesday 19 June 2007 02:44:32 Alexandre Oliva wrote:
> >> GPLv3 forbids tivoization, therefore developer has requirement for
> >> tivoization in the license, therefore GPLv3 forbidding tivoization
> >> is bad.
> >
> > However, my argument is straight logic, nothing "circular" about it.  :)
> > Replacing "X" in my logic path above with "tivoization" and "license"
> > with "GPLv3", as you've done, does produce a valid chain of logic.
>
> Yes.  Isn't it funny though that tivoization became necessary as a
> consequence of GPLv3 forbidding it?

-ELOGIC

It didn't become necessary as a result of the GPLv3 forbidding it. As I 
pointed out in text that was cut to keep the post short, there could be any 
number of reasons why "tivoization" is needed by the manufacturer. Other 
people have also pointed that out. This whole bit was to point out that you 
were inferring circular logic where none existed. 


> >> Wait a minute, these figures you made up are for the tivoized hardware
> >> (no changes allowed to the GPLed software in it), or for the
> >> non-tivoized hardware (changes allowed to the GPLed software in it)?
> >
> > Actually, any generic "TiVO"-like hardware - whether it is tivoized or
> > not.
>
> So your claim is that a user's possibility to scratch her own itches
> makes no difference whatsoever as to their amount of contributions she
> is likely to make?

Exactly.

> Am I the only one who thinks this is utter nonsense?
>
> >> > those who will contribute them back: 38 (25%)
> >>
> >> Regardless of what you meant, this is 38 developers *on top* of
> >> however many the company pays to work on that, unless you're jumping
> >> the gun and spoiling the multi-part argument.
> >
> > 38ppm is a fairly small amount, regardless.
>
> Yes.  And your estimates are way too low too, FWIW.  Any reason why
> you changed your mind as to the 10% before?

That 10% was, IIRC, a reference to the potential number of "Hackers" that 
would own a TiVO. On thinking about it I realized that the number of hackers 
owning a TiVO would be vanishingly small because of "tivoization". So in this 
new set of numbers I dropped it entirely.

... crap I am tempted to respond to nastily has been cut ...

> > I think I'd rather see a guaranteed increase of developers - even if
> > it is only 10 - rather than hoping that the potential pool of 38
> > actually follows through. Wouldn't you?
>
> Yes.  How does this relate with the piece of the argument I've
> proposed so far, or the whole argument I've posted before?
>
> Answer: It doesn't.  At all.  You're just showing you didn't
> understand the argument.  Which shows why I have to explain it piece
> by piece.  Which suggests you shouldn't try to jump to conclusions.

Wrong. Nobody here needs a "piece by piece" explanation. So, in the belief 
that you were intelligent enough to understand that, I was providing proof 
that refutes your argument entirely.

With a situation as complex as what exists you can't split the argument into 
two and claim that, since "Argument A" is true in the "split" argument that 
it is true when the argument isn't split. This holds true for almost all 
real-world situations.

Now, I am not enjoying the discussion anymore. I've asked once before - remove 
me from the CC list.

DRH


-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-mm 14/25] NTP: Move the cmos update code into ntp.c

[Franck Bui-Huu]

Hi Thomas,

Thomas Gleixner wrote:
> i386 and sparc64 have the identical code to update the cmos clock.
> Move it into kernel/time/ntp.c as there are other architectures
> coming along with the same requirements.
> 
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
> Cc: Chris Wright <[EMAIL PROTECTED]>
> Cc: Ingo Molnar <[EMAIL PROTECTED]>
> Cc: john stultz <[EMAIL PROTECTED]>
> Cc: David Miller <[EMAIL PROTECTED]>
> 
> ---
>  arch/i386/Kconfig  |4 +++
>  arch/i386/kernel/time.c|   50 +-
>  arch/sparc64/Kconfig   |4 +++
>  arch/sparc64/kernel/time.c |   53 +---
>  include/asm-i386/timer.h   |1 
>  include/linux/time.h   |2 +
>  kernel/time/ntp.c  |   59 
> ++---
>  7 files changed, 70 insertions(+), 103 deletions(-)
> 

[snip]

>  /* Kick start a stopped clock (procedure from the Sun NVRAM/hostid FAQ). */
> Index: linux-2.6.22-rc4-mm/include/linux/time.h
> ===
> --- linux-2.6.22-rc4-mm.orig/include/linux/time.h 2007-06-16 
> 12:10:21.0 +0200
> +++ linux-2.6.22-rc4-mm/include/linux/time.h  2007-06-16 12:10:24.0 
> +0200
> @@ -93,6 +93,8 @@ extern struct timespec wall_to_monotonic
>  extern seqlock_t xtime_lock __attribute__((weak));
>  
>  extern unsigned long read_persistent_clock(void);
> +extern int update_persistent_clock(struct timespec now);

I'm wondering if update_persistent_clock shouldn't be part of
"drivers/rtc/*" framework. Do you have any idea on how this
is going to be implemented on platforms that use this framework ?

> +extern int no_sync_cmos_clock __read_mostly;
>  void timekeeping_init(void);
>  
>  static inline unsigned long get_seconds(void)
> Index: linux-2.6.22-rc4-mm/kernel/time/ntp.c
> ===
> --- linux-2.6.22-rc4-mm.orig/kernel/time/ntp.c2007-06-16 
> 12:10:21.0 +0200
> +++ linux-2.6.22-rc4-mm/kernel/time/ntp.c 2007-06-16 12:10:24.0 
> +0200
> @@ -10,6 +10,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -187,12 +188,64 @@ u64 current_tick_length(void)
>   return tick_length;
>  }
>  
> +#ifdef CONFIG_GENERIC_CMOS_UPDATE
>  
> -void __attribute__ ((weak)) notify_arch_cmos_timer(void)
> +/* Disable the cmos update - used by virtualization and embedded */
> +int no_sync_cmos_clock  __read_mostly;
> +

[snip]

>  
> +static void notify_cmos_timer(void)
> +{
> + if (no_sync_cmos_clock)
> + mod_timer(&sync_cmos_timer, jiffies + 1);
> +}

Isn't the test condition wrong ? Shouldn't it be:

if (!no_sync_cmos_clock)
mod_timer(&sync_cmos_timer, jiffies + 1);

Thanks,

Franck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: v2.6.21.4-rt11

[Ingo Molnar]

* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:

> On Mon, Jun 18, 2007 at 08:46:03PM -0700, Christoph Lameter wrote:
> > @@ -2493,17 +2493,18 @@ static void idle_balance(int this_cpu, s
> > unsigned long next_balance = jiffies + 60 *  HZ;
> > 
> > for_each_domain(this_cpu, sd) {
> > -   if (sd->flags & SD_BALANCE_NEWIDLE) {
> > +   unsigned long interval;
> > +
> 
> Do we need a :
> 
>   if (!(sd->flags & SD_LOAD_BALANCE))
>   continue;
> 
> here?
> 
> Otherwise patch look good and fixes the problem Paul observed earlier.

great! I've applied the patch below (added your fix and cleaned it up a 
bit) and have released 2.6.21.5-rt17 with it.

Ingo

-->
From: Christoph Lameter <[EMAIL PROTECTED]>
Subject: [patch] sched: fix next_interval determination in idle_balance().

The intervals of domains that do not have SD_BALANCE_NEWIDLE must
be considered for the calculation of the time of the next balance.
Otherwise we may defer rebalancing forever.

Siddha also spotted that the conversion of the balance interval
to jiffies is missing. Fix that to.

From: Srivatsa Vaddagiri <[EMAIL PROTECTED]>

also continue the loop if !(sd->flags & SD_LOAD_BALANCE).

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 kernel/sched.c |   22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -2591,17 +2591,21 @@ static void idle_balance(int this_cpu, s
unsigned long next_balance = jiffies + HZ;
 
for_each_domain(this_cpu, sd) {
-   if (sd->flags & SD_BALANCE_NEWIDLE) {
+   unsigned long interval;
+
+   if (!(sd->flags & SD_LOAD_BALANCE))
+   continue;
+
+   if (sd->flags & SD_BALANCE_NEWIDLE)
/* If we've pulled tasks over stop searching: */
pulled_task = load_balance_newidle(this_cpu,
-   this_rq, sd);
-   if (time_after(next_balance,
- sd->last_balance + sd->balance_interval))
-   next_balance = sd->last_balance
-   + sd->balance_interval;
-   if (pulled_task)
-   break;
-   }
+   this_rq, sd);
+
+   interval = msecs_to_jiffies(sd->balance_interval);
+   if (time_after(next_balance, sd->last_balance + interval))
+   next_balance = sd->last_balance + interval;
+   if (pulled_task)
+   break;
}
if (pulled_task || time_after(jiffies, this_rq->next_balance)) {
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/RFC] oops and panic message logging to MTD

[Artem Bityutskiy]

On Mon, 2007-06-18 at 17:31 +0100, Richard Purdie wrote:
> +static int mtdoops_erase_block(struct mtd_info *mtd, int offset)
> +{
> + struct erase_info erase;
> + DECLARE_WAITQUEUE(wait, current);
> + wait_queue_head_t wait_q;
> + int ret;
> +
> + init_waitqueue_head(&wait_q);
> + erase.mtd = mtd;
> + erase.callback = mtdoops_erase_callback;
> + erase.addr = offset;
> + if (mtd->erasesize < OOPS_PAGE_SIZE)
> + erase.len = OOPS_PAGE_SIZE;
> + else
> + erase.len = mtd->erasesize;
> + erase.priv = (u_long)&wait_q;
> +
> + set_current_state(TASK_INTERRUPTIBLE);
> + add_wait_queue(&wait_q, &wait);
> +
> + ret = mtd->erase(mtd, &erase);
> + if (ret) {
> + set_current_state(TASK_RUNNING);
> + remove_wait_queue(&wait_q, &wait);
> + printk(KERN_WARNING "mtdoops: erase of region [0x%x, 0x%x] "
> +  "on \"%s\" failed\n",
> + erase.addr, erase.len, mtd->name);
> + return ret;
> + }
> +
> + schedule();  /* Wait for erase to finish. */
> + remove_wait_queue(&wait_q, &wait);
> +
> + return 0;
> +}

Also, could you please use wait_event_interruptible() instead of
set_current_state() which looks better (indeed, you have wait queue, so
use wq calls).

-- 
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/

xfs freeze/umount problem

[David Greaves]

David Chinner wrote:
> FWIW, I'm on record stating that "sync" is not sufficient to quiesce an XFS
> filesystem for a suspend/resume to work safely and have argued that the only
> safe thing to do is freeze the filesystem before suspend and thaw it after
> resume.

Whilst testing a potential bug in another thread I accidentally found that 
unmounting a filesystem that I'd just frozen would hang.


As the saying goes: "Well, duh!!"

I could eventually run an unfreeze but the mount was still hung. This lead to an 
unclean shutdown.


OK, it may not be bright but it seems like this shouldn't happen; umount should 
either unfreeze and work or fail ("Attempt to umount a frozen filesystem.") if 
the fs is frozen.


Is this a kernel bug/misfeature or a (u)mount one?
Suggestions as to the best place to report it if not in the cc's?

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Versioning file system

[Bron Gondwana]

On Mon, Jun 18, 2007 at 11:10:42PM -0400, Kyle Moffett wrote:
> On Jun 18, 2007, at 13:56:05, Bryan Henderson wrote:
>>> The question remains is where to implement versioning: directly in 
>>> individual filesystems or in the vfs code so all filesystems can use it?
>>
>> Or not in the kernel at all.  I've been doing versioning of the types I 
>> described for years with user space code and I don't remember feeling that 
>> I compromised in order not to involve the kernel.
>
> What I think would be particularly interesting in this domain is something 
> similar in concept to GIT, except in a file-system:

I've written a couple of user-space things very much like this - one
being a purely database (blobs in database, yeah I know) system for
managing medical data, where signatures and auditability were the most
important part of the system.  Performance really wasn't a
consideration.

The other one is my current job, FastMail - we have a virtual filesystem
which uses files stored by sha1 on ordainary filesystems for data
storage and a database for metadata (filename to sha1 mappings, mtime,
mimetype, directory structure, etc).

Multiple machine distribution is handled by a daemon on each machine
which can be asked to make sure the file gets sent out to every machine
that matches the prefix and will only return success once it's written
to at least one other machine.  Database replication is a different
beast.


It can work, but there's one big pain at the file level: no mmap.

If you don't want to support mmap it can work reasonably happily, though
you may want to keep your sha1 (or other digest) state as well as the
final digest so you can cheaply calculate the digest for a small append
without walking the entire file.  You may also want to keep state
checkpoints every so often along a big file so that truncates don't cost
too much to recalculate.

Luckily in a userspace VFS that's only accessed via FTP and DAV we can
support a limited set of operations (basically create, append, read,
delete)  You don't get that luxury for a general purpose filesystem, and
that's the problem.  There will always be particular usage patterns
(especially something that mmaps or seeks and touches all over the place
like a loopback mounted filesystem or a database file) that just dodn't
work for file-level sha1s.


It does have some lovely properties though.  I'd enjoy working in an
envionment that didn't look much like POSIX but had the strong
guarantees and auditability that addressing by sha1 buys you.

Bron.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 RT] Don't call mcount from vsyscall_fn's

[Ingo Molnar]

* Steven Rostedt <[EMAIL PROTECTED]> wrote:

> This bit me in the butt.
> 
> I couldn't understand why my init app was segfaulting, with a kernel 
> address, but a user RIP and RSP.  Well, the RIP I think was bogus, but 
> the kernel address was always the start of "mcount".  Looking deeper, 
> I printed out what was in the RSP (even though it was a user stack).  
> It ended up showing me that the calling address was from the VDSO 
> area. Looking even further, I found the offending culprit, which was 
> vread_hpet.
> 
> Looking at the assembly dump, I saw the vread_hpet was calling mcount, 
> but I could not see it in the code. Nor could I see it in hpet.i (-E 
> option of compiling).
> 
> Well, I guess Ingo is a magician when it comes to compiler tricks, and 
> has the mcount being called by "every!!" function, unless you add the 
> "notrace" option.
> 
> This patch adds the notrace to vsyscall_fn, so that we don't have user 
> land apps calling mcount and crashing!

doh - applied. Thanks!

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 0/6] s390 patches for 2.6.22

[Martin Schwidefsky]

Last s390 bug fix patches for 2.6.22.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/6] Missing blank when appending cio_ignore kernel parameter

[Martin Schwidefsky]

From: Michael Holzheu <[EMAIL PROTECTED]>

When appending the 'cio_ignore' kernel parameter to the command line, a blank
has to be inserted in order to separate 'cio_ignore' from the preceding kernel
parameters.

Signed-off-by: Michael Holzheu <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/kernel/setup.c |1 +
 1 file changed, 1 insertion(+)

Index: quilt-2.6/arch/s390/kernel/setup.c
===
--- quilt-2.6.orig/arch/s390/kernel/setup.c
+++ quilt-2.6/arch/s390/kernel/setup.c
@@ -300,6 +300,7 @@ static void __init setup_zfcpdump(unsign
else
sprintf(str, "cio_ignore=all,!0.0.%04x",
ipl_info.data.fcp.dev_id.devno);
+   strcat(COMMAND_LINE, " ");
strcat(COMMAND_LINE, str);
console_loglevel = 2;
 }

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 2/6] Fix zfcpdump header

[Martin Schwidefsky]

From: Michael Holzheu <[EMAIL PROTECTED]>

Added members for volume number and real memory size to header information.

Signed-off-by: Michael Holzheu <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/s390/char/zcore.c |3 +++
 1 file changed, 3 insertions(+)

Index: quilt-2.6/drivers/s390/char/zcore.c
===
--- quilt-2.6.orig/drivers/s390/char/zcore.c
+++ quilt-2.6/drivers/s390/char/zcore.c
@@ -267,7 +267,9 @@ struct zcore_header {
u64 tod;
cpuid_t cpu_id;
u32 arch_id;
+   u32 volnr;
u32 build_arch;
+   u64 rmem_size;
char pad2[4016];
 } __attribute__((packed,__aligned__(16)));
 
@@ -559,6 +561,7 @@ static void __init zcore_header_init(int
else
hdr->arch_id = DUMP_ARCH_S390;
hdr->mem_size = sys_info.mem_size;
+   hdr->rmem_size = sys_info.mem_size;
hdr->mem_end = sys_info.mem_size;
hdr->num_pages = sys_info.mem_size / PAGE_SIZE;
hdr->tod = get_clock();

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/6] Fix yet another two section mismatches.

[Martin Schwidefsky]

From: Heiko Carstens <[EMAIL PROTECTED]>

WARNING: arch/s390/kernel/built-in.o(.text+0xb92a):
 Section mismatch: reference to .init.text:start_secondary
 (between 'restart_addr' and 'stack_overflow')
WARNING: arch/s390/appldata/built-in.o(.data+0xdc):
 Section mismatch: reference to .init.text:
 (between 'appldata_nb' and 'appldata_timer_lock')

Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/appldata/appldata_base.c |5 ++---
 arch/s390/kernel/entry.S   |8 +++-
 arch/s390/kernel/entry64.S |8 +++-
 3 files changed, 16 insertions(+), 5 deletions(-)

Index: quilt-2.6/arch/s390/appldata/appldata_base.c
===
--- quilt-2.6.orig/arch/s390/appldata/appldata_base.c
+++ quilt-2.6/arch/s390/appldata/appldata_base.c
@@ -535,8 +535,7 @@ void appldata_unregister_ops(struct appl
 
 /*** init / exit */
 
-static void
-appldata_online_cpu(int cpu)
+static void __cpuinit appldata_online_cpu(int cpu)
 {
init_virt_timer(&per_cpu(appldata_timer, cpu));
per_cpu(appldata_timer, cpu).function = appldata_timer_function;
@@ -580,7 +579,7 @@ appldata_cpu_notify(struct notifier_bloc
return NOTIFY_OK;
 }
 
-static struct notifier_block appldata_nb = {
+static struct notifier_block __cpuinitdata appldata_nb = {
.notifier_call = appldata_cpu_notify,
 };
 
Index: quilt-2.6/arch/s390/kernel/entry64.S
===
--- quilt-2.6.orig/arch/s390/kernel/entry64.S
+++ quilt-2.6/arch/s390/kernel/entry64.S
@@ -745,10 +745,13 @@ mcck_return:
 #endif
lpswe   __LC_RETURN_MCCK_PSW# back to caller
 
-#ifdef CONFIG_SMP
 /*
  * Restart interruption handler, kick starter for additional CPUs
  */
+#ifdef CONFIG_SMP
+#ifndef CONFIG_HOTPLUG_CPU
+   .section .init.text,"ax"
+#endif
.globl restart_int_handler
 restart_int_handler:
lg  %r15,__LC_SAVE_AREA+120 # load ksp
@@ -759,6 +762,9 @@ restart_int_handler:
lmg %r6,%r15,__SF_GPRS(%r15) # load registers from clone
stosm   __SF_EMPTY(%r15),0x04   # now we can turn dat on
jg  start_secondary
+#ifndef CONFIG_HOTPLUG_CPU
+   .previous
+#endif
 #else
 /*
  * If we do not run with SMP enabled, let the new CPU crash ...
Index: quilt-2.6/arch/s390/kernel/entry.S
===
--- quilt-2.6.orig/arch/s390/kernel/entry.S
+++ quilt-2.6/arch/s390/kernel/entry.S
@@ -769,10 +769,13 @@ mcck_return:
 
RESTORE_ALL __LC_RETURN_MCCK_PSW,0
 
-#ifdef CONFIG_SMP
 /*
  * Restart interruption handler, kick starter for additional CPUs
  */
+#ifdef CONFIG_SMP
+#ifndef CONFIG_HOTPLUG_CPU
+   .section .init.text,"ax"
+#endif
.globl restart_int_handler
 restart_int_handler:
l   %r15,__LC_SAVE_AREA+60  # load ksp
@@ -785,6 +788,9 @@ restart_int_handler:
br  %r14# branch to start_secondary
 restart_addr:
.long   start_secondary
+#ifndef CONFIG_HOTPLUG_CPU
+   .previous
+#endif
 #else
 /*
  * If we do not run with SMP enabled, let the new CPU crash ...

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/6] Print list of modules on die().

[Martin Schwidefsky]

From: Heiko Carstens <[EMAIL PROTECTED]>

Print list of modules on die() like a lot of other architectures do.

Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/kernel/traps.c |1 +
 1 file changed, 1 insertion(+)

Index: quilt-2.6/arch/s390/kernel/traps.c
===
--- quilt-2.6.orig/arch/s390/kernel/traps.c
+++ quilt-2.6/arch/s390/kernel/traps.c
@@ -258,6 +258,7 @@ void die(const char * str, struct pt_reg
spin_lock_irq(&die_lock);
bust_spinlocks(1);
printk("%s: %04lx [#%d]\n", str, err & 0x, ++die_counter);
+   print_modules();
 show_regs(regs);
bust_spinlocks(0);
 spin_unlock_irq(&die_lock);

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/6] Move psw_set_key.

[Martin Schwidefsky]

From: Heiko Carstens <[EMAIL PROTECTED]>

Move psw_set_key() from ptrace.h to processor.h which is a more
suitable place for it. In addition the moves makes the function
invisible to user space.

Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/kernel/traps.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

Index: quilt-2.6/arch/s390/kernel/traps.c
===
--- quilt-2.6.orig/arch/s390/kernel/traps.c
+++ quilt-2.6/arch/s390/kernel/traps.c
@@ -253,20 +253,22 @@ void die(const char * str, struct pt_reg
 {
static int die_counter;
 
+   oops_enter();
debug_stop_all();
console_verbose();
spin_lock_irq(&die_lock);
bust_spinlocks(1);
printk("%s: %04lx [#%d]\n", str, err & 0x, ++die_counter);
print_modules();
-show_regs(regs);
+   show_regs(regs);
bust_spinlocks(0);
-spin_unlock_irq(&die_lock);
+   spin_unlock_irq(&die_lock);
if (in_interrupt())
panic("Fatal exception in interrupt");
if (panic_on_oops)
panic("Fatal exception: panic_on_oops");
-do_exit(SIGSEGV);
+   oops_exit();
+   do_exit(SIGSEGV);
 }
 
 static void inline

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/6] Add oops_enter()/oops_exit() calls to die().

[Martin Schwidefsky]

From: Heiko Carstens <[EMAIL PROTECTED]>

This is mainly to switch off all potentially debugging stuff that
won't report anything useful after an oops happened.
Besided that setting pause_on_oops will work too, but doesn't make
too much sense on s390.

Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 include/asm-s390/processor.h |5 +
 include/asm-s390/ptrace.h|9 +
 2 files changed, 6 insertions(+), 8 deletions(-)

Index: quilt-2.6/include/asm-s390/processor.h
===
--- quilt-2.6.orig/include/asm-s390/processor.h
+++ quilt-2.6/include/asm-s390/processor.h
@@ -216,6 +216,11 @@ static inline void cpu_relax(void)
barrier();
 }
 
+static inline void psw_set_key(unsigned int key)
+{
+   asm volatile("spka 0(%0)" : : "d" (key));
+}
+
 /*
  * Set PSW to specified value.
  */
Index: quilt-2.6/include/asm-s390/ptrace.h
===
--- quilt-2.6.orig/include/asm-s390/ptrace.h
+++ quilt-2.6/include/asm-s390/ptrace.h
@@ -470,14 +470,7 @@ struct user_regs_struct
 #define regs_return_value(regs)((regs)->gprs[2])
 #define profile_pc(regs) instruction_pointer(regs)
 extern void show_regs(struct pt_regs * regs);
-#endif
-
-static inline void
-psw_set_key(unsigned int key)
-{
-   asm volatile("spka 0(%0)" : : "d" (key));
-}
-
+#endif /* __KERNEL__ */
 #endif /* __ASSEMBLY__ */
 
 #endif /* _S390_PTRACE_H */

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/2] 2.6.22-rc4: known regressions with patches v3

[Paulo Pereira]

A Wednesday 13 June 2007 22:01:54, Alan Stern escreveu:
> On Wed, 13 Jun 2007, Greg KH wrote:
> > On Wed, Jun 13, 2007 at 09:58:05PM +0200, Michal Piotrowski wrote:
> > >  USB
> > >
> > >  Subject: list_add corruption. prev->next should be next
> > > (f7d28794), but was f0df8ed4 (prev=f0df8ed4) Kernel Bug at
> > > lib/list_debug.c:33 References :
> > > http://bugzilla.kernel.org/show_bug.cgi?id=8561
> > >  Submitter  : Paulo Pereira <[EMAIL PROTECTED]>
> > >  Handled-By : Alan Stern <[EMAIL PROTECTED]>
> > >  Patch  : http://bugzilla.kernel.org/show_bug.cgi?id=8561#c8
> > >  Status : patch was suggested
> >
> > I'm pretty sure this wasn't a "regression" and was always there, and
> > that the proposed patch did fix the solution, right Paulo and Alan?
>
> I'm also pretty sure that it's not a regression and that the patch
> should have fixed it.  But since Paolo hasn't replied to any of our
> queries, we can't be certain.
>
> Alan Stern

Hi, I'am writting for tell that the patch work well, I have Ktorrent working 
for 3 days and there is no Kernel Panic But I'am using Kernel 2.6.22-rc4 
with the patch that you send!!
Thank you, Paulo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Please pull git390 'for-linus' branch

[Martin Schwidefsky]

Please pull from 'for-linus' branch of

git://git390.osdl.marist.edu/pub/scm/linux-2.6.git for-linus

to receive the following updates:

 arch/s390/appldata/appldata_base.c |5 ++---
 arch/s390/kernel/entry.S   |8 +++-
 arch/s390/kernel/entry64.S |8 +++-
 arch/s390/kernel/setup.c   |1 +
 arch/s390/kernel/traps.c   |9 ++---
 drivers/s390/char/zcore.c  |3 +++
 include/asm-s390/processor.h   |5 +
 include/asm-s390/ptrace.h  |9 +
 8 files changed, 32 insertions(+), 16 deletions(-)

Heiko Carstens (4):
  [S390] Fix yet another two section mismatches.
  [S390] Print list of modules on die().
  [S390] Move psw_set_key.
  [S390] Add oops_enter()/oops_exit() calls to die().

Michael Holzheu (2):
  [S390] Missing blank when appending cio_ignore kernel parameter
  [S390] Fix zfcpdump header

diff --git a/arch/s390/appldata/appldata_base.c 
b/arch/s390/appldata/appldata_base.c
index 81a2b92..6ffbab7 100644
--- a/arch/s390/appldata/appldata_base.c
+++ b/arch/s390/appldata/appldata_base.c
@@ -535,8 +535,7 @@ void appldata_unregister_ops(struct appldata_ops *ops)
 
 /*** init / exit */
 
-static void
-appldata_online_cpu(int cpu)
+static void __cpuinit appldata_online_cpu(int cpu)
 {
init_virt_timer(&per_cpu(appldata_timer, cpu));
per_cpu(appldata_timer, cpu).function = appldata_timer_function;
@@ -580,7 +579,7 @@ appldata_cpu_notify(struct notifier_block *self,
return NOTIFY_OK;
 }
 
-static struct notifier_block appldata_nb = {
+static struct notifier_block __cpuinitdata appldata_nb = {
.notifier_call = appldata_cpu_notify,
 };
 
diff --git a/arch/s390/kernel/entry.S b/arch/s390/kernel/entry.S
index c8a2212..6234c69 100644
--- a/arch/s390/kernel/entry.S
+++ b/arch/s390/kernel/entry.S
@@ -769,10 +769,13 @@ mcck_return:
 
RESTORE_ALL __LC_RETURN_MCCK_PSW,0
 
-#ifdef CONFIG_SMP
 /*
  * Restart interruption handler, kick starter for additional CPUs
  */
+#ifdef CONFIG_SMP
+#ifndef CONFIG_HOTPLUG_CPU
+   .section .init.text,"ax"
+#endif
.globl restart_int_handler
 restart_int_handler:
l   %r15,__LC_SAVE_AREA+60  # load ksp
@@ -785,6 +788,9 @@ restart_int_handler:
br  %r14# branch to start_secondary
 restart_addr:
.long   start_secondary
+#ifndef CONFIG_HOTPLUG_CPU
+   .previous
+#endif
 #else
 /*
  * If we do not run with SMP enabled, let the new CPU crash ...
diff --git a/arch/s390/kernel/entry64.S b/arch/s390/kernel/entry64.S
index 93745fd..685f11f 100644
--- a/arch/s390/kernel/entry64.S
+++ b/arch/s390/kernel/entry64.S
@@ -745,10 +745,13 @@ mcck_return:
 #endif
lpswe   __LC_RETURN_MCCK_PSW# back to caller
 
-#ifdef CONFIG_SMP
 /*
  * Restart interruption handler, kick starter for additional CPUs
  */
+#ifdef CONFIG_SMP
+#ifndef CONFIG_HOTPLUG_CPU
+   .section .init.text,"ax"
+#endif
.globl restart_int_handler
 restart_int_handler:
lg  %r15,__LC_SAVE_AREA+120 # load ksp
@@ -759,6 +762,9 @@ restart_int_handler:
lmg %r6,%r15,__SF_GPRS(%r15) # load registers from clone
stosm   __SF_EMPTY(%r15),0x04   # now we can turn dat on
jg  start_secondary
+#ifndef CONFIG_HOTPLUG_CPU
+   .previous
+#endif
 #else
 /*
  * If we do not run with SMP enabled, let the new CPU crash ...
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 51d6309..7e1bfb9 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -300,6 +300,7 @@ static void __init setup_zfcpdump(unsigned int 
console_devno)
else
sprintf(str, "cio_ignore=all,!0.0.%04x",
ipl_info.data.fcp.dev_id.devno);
+   strcat(COMMAND_LINE, " ");
strcat(COMMAND_LINE, str);
console_loglevel = 2;
 }
diff --git a/arch/s390/kernel/traps.c b/arch/s390/kernel/traps.c
index cbfe730..ee9186f 100644
--- a/arch/s390/kernel/traps.c
+++ b/arch/s390/kernel/traps.c
@@ -253,19 +253,22 @@ void die(const char * str, struct pt_regs * regs, long 
err)
 {
static int die_counter;
 
+   oops_enter();
debug_stop_all();
console_verbose();
spin_lock_irq(&die_lock);
bust_spinlocks(1);
printk("%s: %04lx [#%d]\n", str, err & 0x, ++die_counter);
-show_regs(regs);
+   print_modules();
+   show_regs(regs);
bust_spinlocks(0);
-spin_unlock_irq(&die_lock);
+   spin_unlock_irq(&die_lock);
if (in_interrupt())
panic("Fatal exception in interrupt");
if (panic_on_oops)
panic("Fatal exception: panic_on_oops");
-do_exit(SIGSEGV);
+   oops_exit();
+   do_exit(SIGSEGV);
 }
 
 static void inline
diff --git a/drivers/s390/char/zcore.c b/drivers/s390/char/zcore.c
index 66eb068..4e711a9 100644
--- a/drivers/s390/ch

Re: [RFC/PATCH] Documentation of kernel messages

[holzheu]

On Mon, 2007-06-18 at 18:36 -0700, Arjan van de Ven wrote:
> On Mon, 2007-06-18 at 15:53 +0200, holzheu wrote:
> > On Mon, 2007-06-18 at 06:12 -0700, Arjan van de Ven wrote:
> > > On Mon, 2007-06-18 at 14:55 +0200, holzheu wrote:
> > > > Hi Gerrit,
> > > > 
> > > > The common thing of your and our approach is, that we need an ID to
> > > > identify a message either by:
> > > 
> > > 
> > > Maybe I am missing something big, but why is an ID needed?
> > > The message IS the ID right? That's the only thing that is robust
> > > against code moving about
> > 
> > Yes. As already discussed with Pavel, it is one option to use the format
> > string of the message as message ID. The disadvantage compared to
> > message IDs like hashes is, that format strings might be even less
> > unique than hashes 
> 
> if the hash comes from the string in the first place I have a hard time
> believing that.
> 

Just think of all messages containing %s, which can expand to every
possible string.

Michael

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kerneldoc fix in audit_core_dumps

[Henne]

From: Henrik Kretzschmar <[EMAIL PROTECTED]>

Fix parameter name in audit_core_dumps for kerneldoc.

Signed-off-by: Henrik Kretzschmar <[EMAIL PROTECTED]>

---

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index e36481e..028650c 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2040,7 +2040,7 @@ int __audit_signal_info(int sig, struct
 
 /**
  * audit_core_dumps - record information about processes that end abnormally
- * @sig: signal value
+ * @signr: signal value
  *
  * If a process ends with a core dump, something fishy is going on and we
  * should record the event for investigation.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kerneldoc fix in libata

[Henne]

From: Henrik Kretzschmar <[EMAIL PROTECTED]>

Fix parameter name from ata_dev_reread_id() in libata-core.c for kerneldoc.

Signed-off-by: Henrik Kretzschmar <[EMAIL PROTECTED]>

---

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 047eabd..88e2761 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3659,7 +3659,7 @@ static int ata_dev_same_device(struct at
 
 /**
  * ata_dev_reread_id - Re-read IDENTIFY data
- * @adev: target ATA device
+ * @dev: target ATA device
  * @readid_flags: read ID flags
  *
  * Re-read IDENTIFY page and make sure @dev is still attached to


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 -cfs] Fix cpu_load calculation error

[Ingo Molnar]

* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:

> Ingo/Dmitry,
>   I am resending the patch to fix cpu_load calculation error in 
> cfs v17, this time CCing lkml.

> v17 cpu_load calculation didn't take into account that a class's 
> delta_exec/fair may be stale because it could not get an opportunity 
> to run. This can lead to incorrect calculation of a class's load. This 
> patch removes load tracking from individual classes and instead 
> introduces a global per-cpu load tracking common to all classes in 
> kernel/sched.c itself.
> 
> Thanks to Dmitry for suggesting this idea.
> 
> Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>

thanks Srivatsa, i've applied this to the -v18 tree and everything's 
looking good so far!

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Selective system profiling

[John Sigler]

Hello everyone,

Here's my situation:

I'm pushing data in chunks of 1316 bytes to a PCI device at 38 Mbit/s.
In other words, I write 1316 bytes to the device every 277 microseconds.

I've noticed that the latency of this operation varies immensely. Most 
of the time it completes in 50-80 microseconds, but there are occasions 
when it takes several milliseconds (I've even logged 23 ms).


The pseudo-code looks like this:

  deadline = now;

  while ( 1 )
  {
deadline += 277 µs
sleep_until(deadline)
t0 = now;
write 1316 bytes to PCI device
t1 = now;
if (t1-t0 > 100 µs) scream & panic
  }

Relevant (?) information about the setup:

I'm running a PREEMPT_RT kernel with high-resolution timers.
(Specifically 2.6.20.7-rt8)
http://rt.wiki.kernel.org/index.php/Main_Page
HZ=100
The process is in SCHED_RR with priority 75.
The only "process" (?) with higher priority is posix_cpu_timer.
write() is implemented as an ioctl in the driver.
You might think that write() blocks when the buffers on the PCI board 
are full, but I am 99.9% sure that the buffers are never full.



Here's my question:

When my process comes back from a write operation, and I find that I 
have been blocked for more than X ms, can I call a function from a 
system profiler (oprofile perhaps?) to know exactly where in the kernel 
the CPU has been for the last X ms, and how much time has been spent in 
each function, either sleeping or doing something?


Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: v2.6.21.4-rt11

[Ingo Molnar]

* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:

> I believe the patch below is correct. With the patch applied, I could 
> not recreate the imbalance with rcutorture. Let me know whether you 
> still see the problem with this patch applied on any other machine.

thanks for tracking this down! I've applied Christoph's patch (with your 
suggested modification plus a few small cleanups).

I'm wondering, why did this trigger under CFS and not on mainline? 
Mainline seems to have a similar problem in idle_balance() too, or am i 
misreading it?

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] slob: poor man's NUMA support.

[Paul Mundt]

This adds preliminary NUMA support to SLOB, primarily aimed at systems
with small nodes (tested all the way down to a 128kB SRAM block), whether
asymmetric or otherwise.

We follow the same conventions as SLAB/SLUB, preferring current node
placement for new pages, or with explicit placement, if a node has been
specified. Presently on UP NUMA this has the side-effect of preferring
node#0 allocations (since numa_node_id() == 0, though this could be
reworked if we could hand off a pfn to determine node placement), so
single-CPU NUMA systems will want to place smaller nodes further out in
terms of node id. Once a page has been bound to a node (via explicit
node id typing), we only do block allocations from partial free pages
that have a matching node id in the page flags.

The current implementation does have some scalability problems, in that
all partial free pages are tracked in the global freelist (with
contention due to the single spinlock). However, these are things that
are being reworked for SMP scalability first, while things like per-node
freelists can easily be built on top of this sort of functionality once
it's been added.

More background can be found in:

http://marc.info/?l=linux-mm&m=118117916022379&w=2
http://marc.info/?l=linux-mm&m=118170446306199&w=2
http://marc.info/?l=linux-mm&m=118187859420048&w=2

and subsequent threads.

Acked-by: Christoph Lameter <[EMAIL PROTECTED]>
Acked-by: Matt Mackall <[EMAIL PROTECTED]>
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>

--

 include/linux/slab.h |  126 +++
 include/linux/slab_def.h |4 +
 include/linux/slob_def.h |   46 +
 include/linux/slub_def.h |6 +-
 mm/slob.c|   72 --
 5 files changed, 172 insertions(+), 82 deletions(-)

diff --git a/include/linux/slab.h b/include/linux/slab.h
index a015236..e0bedd0 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -44,7 +44,6 @@ struct kmem_cache *kmem_cache_create(const char *, size_t, 
size_t,
void (*)(void *, struct kmem_cache *, unsigned long));
 void kmem_cache_destroy(struct kmem_cache *);
 int kmem_cache_shrink(struct kmem_cache *);
-void *kmem_cache_alloc(struct kmem_cache *, gfp_t);
 void *kmem_cache_zalloc(struct kmem_cache *, gfp_t);
 void kmem_cache_free(struct kmem_cache *, void *);
 unsigned int kmem_cache_size(struct kmem_cache *);
@@ -63,16 +62,6 @@ int kmem_ptr_validate(struct kmem_cache *cachep, const void 
*ptr);
sizeof(struct __struct), __alignof__(struct __struct),\
(__flags), NULL, NULL)
 
-#ifdef CONFIG_NUMA
-extern void *kmem_cache_alloc_node(struct kmem_cache *, gfp_t flags, int node);
-#else
-static inline void *kmem_cache_alloc_node(struct kmem_cache *cachep,
-   gfp_t flags, int node)
-{
-   return kmem_cache_alloc(cachep, flags);
-}
-#endif
-
 /*
  * The largest kmalloc size supported by the slab allocators is
  * 32 megabyte (2^25) or the maximum allocatable page order if that is
@@ -91,7 +80,6 @@ static inline void *kmem_cache_alloc_node(struct kmem_cache 
*cachep,
 /*
  * Common kmalloc functions provided by all allocators
  */
-void *__kmalloc(size_t, gfp_t);
 void *__kzalloc(size_t, gfp_t);
 void * __must_check krealloc(const void *, size_t, gfp_t);
 void kfree(const void *);
@@ -102,40 +90,6 @@ size_t ksize(const void *);
  * @n: number of elements.
  * @size: element size.
  * @flags: the type of memory to allocate.
- */
-static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
-{
-   if (n != 0 && size > ULONG_MAX / n)
-   return NULL;
-   return __kzalloc(n * size, flags);
-}
-
-/*
- * Allocator specific definitions. These are mainly used to establish optimized
- * ways to convert kmalloc() calls to kmem_cache_alloc() invocations by 
selecting
- * the appropriate general cache at compile time.
- */
-
-#if defined(CONFIG_SLAB) || defined(CONFIG_SLUB)
-#ifdef CONFIG_SLUB
-#include 
-#else
-#include 
-#endif /* !CONFIG_SLUB */
-#else
-
-/*
- * Fallback definitions for an allocator not wanting to provide
- * its own optimized kmalloc definitions (like SLOB).
- */
-
-/**
- * kmalloc - allocate memory
- * @size: how many bytes of memory are required.
- * @flags: the type of memory to allocate.
- *
- * kmalloc is the normal method of allocating memory
- * in the kernel.
  *
  * The @flags argument may be one of:
  *
@@ -143,7 +97,7 @@ static inline void *kcalloc(size_t n, size_t size, gfp_t 
flags)
  *
  * %GFP_KERNEL - Allocate normal kernel ram.  May sleep.
  *
- * %GFP_ATOMIC - Allocation will not sleep.
+ * %GFP_ATOMIC - Allocation will not sleep.  May use emergency pools.
  *   For example, use this inside interrupt handlers.
  *
  * %GFP_HIGHUSER - Allocate pages from high memory.
@@ -152,18 +106,22 @@ static inline void *kcalloc(size_t n, size_t size, gfp_t 
flags)
  *
  * %GFP_NOFS - Do not make any fs cal

Re: [Linux-usb-users] Stable identification of identical USB hardware

[Kay Sievers]

On 6/18/07, Greg KH <[EMAIL PROTECTED]> wrote:

On Mon, Jun 18, 2007 at 08:35:35AM -0700, Joerg Pommnitz wrote:
> I want to be able to distinguish between two (or more) mostly
> identical USB serial devices. The devices in question are UMTS modems.
> AFAIK they are identical except for the SIM card and the point of
> attachment. Externally the cards are CardBus devices with an
> integrated USB host adapter. The actual UMTS device is (internally)
> connected to the USB host adapter.
>
> If I have to cardbus sockets, how do I get from what I know ("the card
> is in socket 0") to "I have to talk to ttyUSB2 to talk to the card"? I
> suspect I have to follow the thread from /sys/bus/pci to
> /sys/bus/usb/devices, but how exactly?

Walk up the "chain" of devices in sysfs and in udev.  The udev man pages
and documentation should show you how to do this.  If you have specific
questions about this, please ask them on the linux-hotplug-devel mailing
list.


This should create a symlink for the serial device in the first slot:
 KERNEL="ttyUSB*", SUBSYSTEMS=="pcmcia", KERNELS=="0.0",
SYMLINK+="serial-slot0"

You find the keys used with udevinfo. Here is an example for a PCMCIA
CF Memory card:
 udevinfo --attribute-walk --name hda4
 ...

 looking at device '/block/hda/hda4':
   KERNEL=="hda4"
   SUBSYSTEM=="block"
 ...

 looking at parent device '/devices/pci:00/:00:1e.0/:04:00.0/0.0':
   KERNELS=="0.0"
   SUBSYSTEMS=="pcmcia"
   DRIVERS=="ide-cs"
 ...

 looking at parent device '/devices/pci:00/:00:1e.0/:04:00.0':
   KERNELS==":04:00.0"
   SUBSYSTEMS=="pci"
   DRIVERS=="yenta_cardbus"
 ...

Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Versioning file system

[Martin Langhoff]

On 6/19/07, Kyle Moffett <[EMAIL PROTECTED]> wrote:

What I think would be particularly interesting in this domain is
something similar in concept to GIT, except in a file-system:


perhaps stating the blindingly obvious, but there was an early
implementation of a FUSE-based gitfs --
http://www.sfgoth.com/~mitch/linux/gitfs/

cheers,


martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Anders Larsen]

On 2007-06-18 21:50:12, Alexandre Oliva wrote:
> Given the ROM exception in GPLv3, I guess you could seal and
> anti-tamper it as much as you want, and leave the ROM at such a place
> in which it's easily replaceable but with signature checking and all
> such that the user doesn't install ROM that is not authorized by you.

Sorry, I didn't state the regulations requirement clearly enough:

The manufacturer must be able to _remotely_ update the device
firmware, so as I see it (IANAL), Tivoisation _is_ a requirement.

Cheers
 Anders
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Type error in drivers/input/tsdev.c?

[Fengwei Yin]

Hi,
In function tsdev_event() of drivers/input/tsdev.c,
conversion from usec to milisec is like:
   client->event[client->head].millisecs =
time.tv_usec / 100;
 ~~ should be 1000?

Regards
Yin, Fengwei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

[Pádraig Brady]

Vladislav Bolkhovitin wrote:
> 
> I would also suggest one more feature: support for block level
> de-duplication. I mean:
> 
> 1. Ability for Btrfs to have blocks in several files to point to the
> same block on disk
> 
> 2. Support for new syscall or IOCTL to de-duplicate as a single
> transaction two or more blocks on disk, i.e. link them to one of them
> and free others
> 
> 3. De-de-duplicate blocks on disk, i.e. copy them on write
> 
> I suppose that de-duplication itself would be done by some user space
> process that would scan files, determine blocks with the same data and
> then de-duplicate them by using syscall or IOCTL (2).
> 
> That would be very usable feature, which in most cases would allow to
> shrink occupied disk space on 50-90%.

Have you references for this number?
In my experience one gets a lot of benefit from
the much simpler process of "de-duplication" of files.

Note a checksum stored in file metadata,
that is automatically invalidated on write would
speed up user space file de duplification,
and rsync, etc

Pádraig.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fix signalfd interaction with thread-private signals

[Oleg Nesterov]

On 06/18, Linus Torvalds wrote:
>
> On Mon, 18 Jun 2007, Benjamin Herrenschmidt wrote:
> > On Sun, 2007-06-17 at 17:20 -0700, Davide Libenzi wrote:
> > >
> > > Andrew or Linus, did you get Ben's patch?
> > 
> > It might have been missed... I can resend later today.
> 
> I did indeed just miss it. I intended to apply it (and actually thought I 
> had), but I see it's still just an email in that long thread. 
> 
> (It's often a good idea to re-write the subject line and make it be that 
> standard "[PATCH] ..description..", because that just makes it show up 
> much better when I go through my unread emails.. Not that that is any 
> kind of *guarantee* that I won't miss it).
> 
> Anyway, no need to re-send, it's now *really* in my queue of things to 
> apply.

>From another message on this thread,

Davide Libenzi wrote:
>
> On Sun, 17 Jun 2007, Nicholas Miell wrote:
>
> > But there's still no way for multiple threads to read from a single
> > signalfd and get their own thread-specific signals in addition to
> > process-wide signals, right? I think this was agreed to be the least
> > surprising behavior.
>
> Multiple threads can wait on the signalfd. Each one will dequeue 
either
> its own private signals (tsk->pending) or the process shared ones
> (tsk->signal->shared_pending). This will be the behaviour once Ben's 
patch
> is applied.

The commited "Fix signalfd interaction with thread-private signals"
(commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
this.

We can do something like

int signalfd_dequeue_signal(struct task_struct *tsk, sigset_t *mask, 
siginfo_t *info)
{
if (tsk->tgid == current->tgid)
tsk = current;

return dequeue_signal(tsk, mask, info);
}

(still I can't understand why should we change signalfd).

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 5/6] Move psw_set_key.

[Paul Mundt]

On Tue, Jun 19, 2007 at 10:45:21AM +0200, Martin Schwidefsky wrote:
> From: Heiko Carstens <[EMAIL PROTECTED]>
> 
> Move psw_set_key() from ptrace.h to processor.h which is a more
> suitable place for it. In addition the moves makes the function
> invisible to user space.
> 
>  arch/s390/kernel/traps.c |8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 

On Tue, Jun 19, 2007 at 10:45:22AM +0200, Martin Schwidefsky wrote:
> From: Heiko Carstens <[EMAIL PROTECTED]>
> 
> This is mainly to switch off all potentially debugging stuff that
> won't report anything useful after an oops happened.
> Besided that setting pause_on_oops will work too, but doesn't make
> too much sense on s390.
> 
>  include/asm-s390/processor.h |5 +
>  include/asm-s390/ptrace.h|9 +
>  2 files changed, 6 insertions(+), 8 deletions(-)
> 
These changelog does not match the patch, they're reversed.. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sh fixes

[Paul Mundt]

Please pull from:

master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git

Which contains:

Kaz Kojima (1):
  sh: Fix restartable syscall arg5 clobbering.

Paul Mundt (2):
  sh: oops_enter()/oops_exit() in die().
  sh: Handle -ERESTART_RESTARTBLOCK for restartable syscalls.

 arch/sh/kernel/signal.c |9 ++---
 arch/sh/kernel/traps.c  |3 +++
 2 files changed, 9 insertions(+), 3 deletions(-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sh64 fixes

[Paul Mundt]

Please pull from:

master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh64-2.6.git

Which contains:

Paul Mundt (1):
  sh64: Handle -ERESTART_RESTARTBLOCK for restartable syscalls.

 arch/sh64/kernel/signal.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-lvm] 2.6.22-rc5 XFS fails after hibernate/resume

[David Greaves]

David Greaves wrote:

I'm going to have to do some more testing...

done



David Chinner wrote:

On Mon, Jun 18, 2007 at 08:49:34AM +0100, David Greaves wrote:

David Greaves wrote:
So doing:
xfs_freeze -f /scratch
sync
echo platform > /sys/power/disk
echo disk > /sys/power/state
# resume
xfs_freeze -u /scratch

Works (for now - more usage testing tonight)


Verrry interesting.

Good :)

Now, not so good :)



What you were seeing was an XFS shutdown occurring because the free space
btree was corrupted. IOWs, the process of suspend/resume has resulted
in either bad data being written to disk, the correct data not being
written to disk or the cached block being corrupted in memory.

That's the kind of thing I was suspecting, yes.

If you run xfs_check on the filesystem after it has shut down after a 
resume,
can you tell us if it reports on-disk corruption? Note: do not run 
xfs_repair
to check this - it does not check the free space btrees; instead it 
simply
rebuilds them from scratch. If xfs_check reports an error, then run 
xfs_repair

to fix it up.

OK, I can try this tonight...



This is on 2.6.22-rc5

So I hibernated last night and resumed this morning.
Before hibernating I froze and sync'ed. After resume I thawed it. (Sorry Dave)

Here are some photos of the screen during resume. This is not 100% reproducable 
- it seems to occur only if the system is shutdown for 30mins or so.


Tejun, I wonder if error handling during resume is problematic? I got the same 
errors in 2.6.21. I have never seen these (or any other libata) errors other 
than during resume.


http://www.dgreaves.com/pub/2.6.22-rc5-resume-failure.jpg
(hard to read, here's one from 2.6.21
http://www.dgreaves.com/pub/2.6.21-resume-failure.jpg

I _think_ I've only seen the xfs problem when a resume shows these errors.


Ok, to try and cause a problem I ran a make and got this back at once:
make: stat: Makefile: Input/output error
make: stat: clean: Input/output error
make: *** No rule to make target `clean'.  Stop.
make: stat: GNUmakefile: Input/output error
make: stat: makefile: Input/output error


I caught the first dmesg this time:

Filesystem "dm-0": XFS internal error xfs_btree_check_sblock at line 334 of file 
fs/xfs/xfs_btree.c.  Caller 0xc01b58e1

 [] show_trace_log_lvl+0x1a/0x30
 [] show_trace+0x12/0x20
 [] dump_stack+0x15/0x20
 [] xfs_error_report+0x4f/0x60
 [] xfs_btree_check_sblock+0x56/0xd0
 [] xfs_alloc_lookup+0x181/0x390
 [] xfs_alloc_lookup_le+0x16/0x20
 [] xfs_free_ag_extent+0x51/0x690
 [] xfs_free_extent+0xa4/0xc0
 [] xfs_bmap_finish+0x119/0x170
 [] xfs_itruncate_finish+0x23a/0x3a0
 [] xfs_inactive+0x482/0x500
 [] xfs_fs_clear_inode+0x34/0xa0
 [] clear_inode+0x57/0xe0
 [] generic_delete_inode+0xe5/0x110
 [] generic_drop_inode+0x167/0x1b0
 [] iput+0x5f/0x70
 [] do_unlinkat+0xdf/0x140
 [] sys_unlink+0x10/0x20
 [] syscall_call+0x7/0xb
 ===
xfs_force_shutdown(dm-0,0x8) called from line 4258 of file fs/xfs/xfs_bmap.c. 
Return address = 0xc021101e
Filesystem "dm-0": Corruption of in-memory data detected.  Shutting down 
filesystem: dm-0

Please umount the filesystem, and rectify the problem(s)

so I cd'ed out of /scratch and umounted.

I then tried the xfs_check.

haze:~# xfs_check /dev/video_vg/video_lv
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_check.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
haze:~# mount /scratch/
haze:~# umount /scratch/
haze:~# xfs_check /dev/video_vg/video_lv

Message from [EMAIL PROTECTED] at Tue Jun 19 08:47:30 2007 ...
haze kernel: Bad page state in process 'xfs_db'

Message from [EMAIL PROTECTED] at Tue Jun 19 08:47:30 2007 ...
haze kernel: page:c1767bc0 flags:0x80010008 mapping: mapcount:-64 
count:0

Message from [EMAIL PROTECTED] at Tue Jun 19 08:47:30 2007 ...
haze kernel: Trying to fix it up, but a reboot is needed

Message from [EMAIL PROTECTED] at Tue Jun 19 08:47:30 2007 ...
haze kernel: Backtrace:

Message from [EMAIL PROTECTED] at Tue Jun 19 08:47:30 2007 ...
haze kernel: Bad page state in process 'syslogd'

Message from [EMAIL PROTECTED] at Tue Jun 19 08:47:30 2007 ...
haze kernel: page:c1767cc0 flags:0x80010008 mapping: mapcount:-64 
count:0

Message from [EMAIL PROTECTED] at Tue Jun 19 08:47:30 2007 ...
haze kernel: Trying to fix it up, but a reboot is needed

Message from [EMAIL PROTECTED] at Tue Jun 19 08:47:30 2007 ...
haze kernel: Backtrace:

ugh. Try again
haze:~# xfs_check /dev/video_vg/video_lv
haze:~#

whilst running a top reported this as roughly the peak memory usage:
 8759 root  18   0  479m 474m  876 R  2.0 46.9   0:02.49 xfs_db
so it looks like it didn't run out of memory (machine has 1Gb).

Dave, I ran xfs_check -v... but 

Re: Type error in drivers/input/tsdev.c?

[Jiri Slaby]

Fengwei Yin napsal(a):
> Hi,
> In function tsdev_event() of drivers/input/tsdev.c,
> conversion from usec to milisec is like:
>client->event[client->head].millisecs =
> time.tv_usec / 100;
>  ~~ should be 1000?

Seems so. James CCed.

regards,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 5/6] Move psw_set_key.

[Heiko Carstens]

On Tue, Jun 19, 2007 at 11:12:00AM +0200, Bastian Blank wrote:
> On Tue, Jun 19, 2007 at 10:45:21AM +0200, Martin Schwidefsky wrote:
> > Move psw_set_key() from ptrace.h to processor.h which is a more
> > suitable place for it. In addition the moves makes the function
> > invisible to user space.
> 
> Hmm, this does not really describe the changes.

Yes.. you need to interchange descriptions for patches 5 & 6. Then it
might make sense ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [fuse-devel] FS block count, size and seek offset?

[Goswin von Brederlow]

"David Brown" <[EMAIL PROTECTED]> writes:

>> Why don't you use the existing fuse-unionfs?
>
> I thought about doing this but it would need to be modified somehow
> and even then my users would look to me to fix issues and I don't like
> trying to find hard bugs in other peoples code.
>
> Also, there's a lot of functionality that funionfs has but I don't
> need and the extra code would get in the way attempting to modify or
> debug issues.
>
> What I want is fairly specific and I've not seen anything out there to do it.
>
> Thanks,
> - David Brown

You can still read their code to see how they solved problems you
have.

MfG
Goswin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 5/6] Move psw_set_key.

[Bastian Blank]

On Tue, Jun 19, 2007 at 10:45:21AM +0200, Martin Schwidefsky wrote:
> Move psw_set_key() from ptrace.h to processor.h which is a more
> suitable place for it. In addition the moves makes the function
> invisible to user space.

Hmm, this does not really describe the changes.

Bastian

-- 
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-lvm] 2.6.22-rc5 XFS fails after hibernate/resume

[Tejun Heo]

Hello,

David Greaves wrote:
>> Good :)
> Now, not so good :)

Oh, crap.  :-)

> So I hibernated last night and resumed this morning.
> Before hibernating I froze and sync'ed. After resume I thawed it. (Sorry
> Dave)
> 
> Here are some photos of the screen during resume. This is not 100%
> reproducable - it seems to occur only if the system is shutdown for
> 30mins or so.
> 
> Tejun, I wonder if error handling during resume is problematic? I got
> the same errors in 2.6.21. I have never seen these (or any other libata)
> errors other than during resume.
> 
> http://www.dgreaves.com/pub/2.6.22-rc5-resume-failure.jpg
> (hard to read, here's one from 2.6.21
> http://www.dgreaves.com/pub/2.6.21-resume-failure.jpg

Your controller is repeatedly reporting PHY readiness changed exception.
 Are you reading the system image from the device attached to the first
SATA port?

> I _think_ I've only seen the xfs problem when a resume shows these errors.

The error handling itself tries very hard to ensure that there is no
data corruption in case of errors.  All commands which experience
exceptions are retried but if the drive itself is doing something
stupid, there's only so much the driver can do.

How reproducible is the problem?  Does the problem go away or occur more
often if you change the drive you write the memory image to?

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFC] oops and panic message logging to MTD

[Richard Purdie]

On Tue, 2007-06-19 at 10:55 +0300, Artem Bityutskiy wrote:
> On Mon, 2007-06-18 at 17:31 +0100, Richard Purdie wrote:
> > +   if (mtd->erasesize < OOPS_PAGE_SIZE)
> > +   erase.len = OOPS_PAGE_SIZE;
> 
> It seems to me that your code won't work if mtd->erasesize <
> OOPS_PAGE_SIZE anyway, so this check should not be here I guess.

Its just a sanity check...

> > +   ret = mtd->read(mtd, cxt->nextpage * OOPS_PAGE_SIZE, 4,
> > +   &retlen, (u_char *) &count);
> > +   if ((retlen != 4) || (ret < 0)) {
> > +   printk(KERN_ERR "mtdoops: Read failure at %d (%d of 4 read)"
> > +   ", err %d.\n", cxt->nextpage * OOPS_PAGE_SIZE,
> > +   retlen, ret);
> > +   return 1;
> > +   }
> 
> mtd->read() returns -EUCLEAN in case of a correctable bit-flip, ignore
> this error code here and elsewhere as well please.

ok.

> > +static void mtdoops_prepare(struct mtdoops_context *cxt)
> > +{
> > +   struct mtd_info *mtd = cxt->mtd;
> > +   int i = 0, j, ret, mod;
> > +
> > +   /* We were unregistered */
> > +   if (!mtd)
> > +   return;
> > +
> > +   mod = (cxt->nextpage * OOPS_PAGE_SIZE) % mtd->erasesize;
> > +   if (mod != 0) {
> > +   cxt->nextpage = cxt->nextpage + ((mtd->erasesize - mod) / 
> > OOPS_PAGE_SIZE);
> > +   if (cxt->nextpage > cxt->oops_pages)
> > +   cxt->nextpage = 0;
> > +   }
> > +
> > +   while (mtd->block_isbad &&
> > +   mtd->block_isbad(mtd, cxt->nextpage * OOPS_PAGE_SIZE)) {
> 
> Well, mtd->block_isbad() may return error, unlikely, bu still. You also
> ignore the error at other places.

Ignoring that is deliberate since it doesn't really matter if the block
is bad or we can't read from it, the action is the same...

> > +badblock:
> > +   printk(KERN_WARNING "mtdoops: Bad block at %08x\n",
> > +   cxt->nextpage * OOPS_PAGE_SIZE);
> > +   i++;
> > +   cxt->nextpage = cxt->nextpage + (mtd->erasesize / 
> > OOPS_PAGE_SIZE);
> > +   if (cxt->nextpage > cxt->oops_pages)
> > +   cxt->nextpage = 0;
> > +   if (i == (cxt->oops_pages / (mtd->erasesize / OOPS_PAGE_SIZE))) 
> > {
> > +   printk(KERN_ERR "mtdoops: All blocks bad!\n");
> > +   return;
> > +   }
> > +   }
> > +
> > +   for (j = 0, ret = -1; (j < 3) && (ret < 0); j++)
> > +   ret = mtdoops_erase_block(mtd, cxt->nextpage * OOPS_PAGE_SIZE);
> 
> Ugh, why do you make it this difficult way instead of
> 
> for (all EBs) {
> ret = erase()
> if (ret == -EIO) {
> markbad();
> } else
> return err;
> }

See below.

> > +
> > +   if (ret < 0) {
> > +   if (mtd->block_markbad)
> > +   mtd->block_markbad(mtd, cxt->nextpage * OOPS_PAGE_SIZE);
> > +   goto badblock;
> 
> Please, mark EB as bad only in case of -EIO. 

ok.

> Also, do not ignore error code of mtd->block_markbad()

All we can do is print a warning, the action will be the same...

> Is it possible to re-structure the code and erase/check if EB is bad in
> _one_ cycle (thus avoiding this goto which is difficult to understand)?
> 
> Surely all you want is to format the partition. So make a loop, skip bad
> EBs and erase good ones. In case of erase failure (-EIO) mark the EB as
> bad.

Its not a case of formatting the whole partition. The whole point of
this code is the following use case:

1. Device crashes
2. Device reboots
3. mtdoops partition has a log of why it crashed

If you erase the whole partition each time mtdoops loads, this won't
work so the code only finds the next block to use and erases that. It
keeps moving forwards until it finds that block.

I usually hate goto statements but in this case it simplifies the code a
lot (and it is on an error path). The alternative is a while loop with
several new variables, I tried it and it was more ugly/confusing...

> > +static int find_next_position(struct mtdoops_context *cxt)
> > +{
> > +   struct mtd_info *mtd = cxt->mtd;
> > +   int page, maxpos = 0;
> > +   u32 count, maxcount = 0x;
> > +   size_t retlen;
> > +
> > +   for (page = 0; page < cxt->oops_pages; page++) {
> > +   mtd->read(mtd, page * OOPS_PAGE_SIZE, 4, &retlen, (u_char *) 
> > &count);
> 
> Please, check return code here.

ok.

> Also, could you please use wait_event_interruptible() instead of
> set_current_state() which looks better (indeed, you have wait queue, 
> so use wq calls).

That piece of code is in keeping with the rest of the mtd erase handling
code. Looking through the various wq macros, I don't see any which help
particularly in this case...

Cheers,

Richard


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

[Vladislav Bolkhovitin]

Pádraig Brady wrote:

Vladislav Bolkhovitin wrote:


I would also suggest one more feature: support for block level
de-duplication. I mean:

1. Ability for Btrfs to have blocks in several files to point to the
same block on disk

2. Support for new syscall or IOCTL to de-duplicate as a single
transaction two or more blocks on disk, i.e. link them to one of them
and free others

3. De-de-duplicate blocks on disk, i.e. copy them on write

I suppose that de-duplication itself would be done by some user space
process that would scan files, determine blocks with the same data and
then de-duplicate them by using syscall or IOCTL (2).

That would be very usable feature, which in most cases would allow to
shrink occupied disk space on 50-90%.


Have you references for this number?


No, I've seen it somewhere and it well confirms with my own observations.


In my experience one gets a lot of benefit from
the much simpler process of "de-duplication" of files.


Yes, sure, de-duplication on files level brings its benefits, but on FS 
blocks level it would bring ever more benefits, because there are many 
more or less big files, which are different as a whole, but with a lot 
of the same blocks. Simple example of such files is UNIX-style mail 
boxes on a mail server.



Note a checksum stored in file metadata,
that is automatically invalidated on write would
speed up user space file de duplification,
and rsync, etc


Sure, file level deduplication is simpler to implement, but it is 
generally less powerful, than FS block level one. And seems it should 
not be hard to add the above (1)-(3) features in the existing Btrfs 
structure, especially on this stage, when the disk format isn't 
stabilized yet.



Pádraig.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH -mm take5 3/7] add interface for netconsole using sysfs

[Keiichi KII]

Hello Satyam,

First, I'm sorry I couldn't reply to your comments.
I'm so appreciate for your comments.

I will fix my patches following your advices.
But, I have some questions on the another patches. So, I want to ask you
some questions and answer your questions.


+static int miscdev_configured;


Is this really required? We just return with error if misc_register()
fails during module init time itself, so it's not really useful ever, is 
it?


You're right. It isn't required.

Thanks
--
Keiichi KII
NEC Corporation OSS Platform Development Division
E-mail: [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: [RFC][PATCH -mm take5 4/7] using symlink for the net_device

[Keiichi KII]

Hello Satyam,


Sorry, but we're not covering from the error condition fully here. Note
that later you merge the temporary modify_target_list entirely back
into the target_list ... which would still contain these erroneous
nodes. A full cleanup (kobject_unregister the entry, and then list_del
from modify_target_list) is required here, before continuing.


I will fix this. If the error occurs, I think so that we need to cleanup
completely.


+   strcpy(nt->np.dev_name, dev->name);


... you'll have move this up.



Why? I don't have opposition about moving this up, but I'm misplacing the abobe 
code?
or it isn't appropriate about coding style?

Thanks
--
Keiichi KII
NEC Corporation OSS Platform Development Division
E-mail: [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: [RFC][PATCH -mm take5 4/7] using symlink for the net_device

[Keiichi KII]

Hello Satyam,


and this is why we have to use the dual-list mechanism to react to the net
device rename. This isn't so obvious, a comment at the point where you
declare modify_target_list would be nice? (BTW temporary_list would be
a better name for that, IMO)


All right, my patches are short of comments. So, I will add comments 
to the ambiguous codes.



Ok, so reading through the code makes it obvious that this mutex is used
to protect against the following race:

Thread #1   Thread #2
=   =

[ NETDEV_CHANGENAME notifier ]  [ ioctl(NETCON_REMOVE_TARGET) ]

netconsole_event()
move from target_list to temp list
work on temp list
   kobject_unregister()
   -> release_target()
  -> remove_target()
move back to target_list

Which would mean a deleted/removed target added back => *boom*

But, the race still hasn't been closed properly!

You're taking the mutex only around "work on temp list" which is
insufficient, you need to ensure atomicity inside netconsole_event()
_completely_ like this (renaming netdev_change_sem to
netdev_changename_mtx):


After the target moves from target_list to temporary_list, 
the kobject_unregister() of possible raced target isn't called 
in ioctl(NETCON_REMOVE_TARGET) because the target_list doesn't contain 
the target .


I have the wrong idea?


+static char *make_netdev_class_name(char *netdev_name)
+{
+   char *name;
+
+   name = kasprintf(GFP_KERNEL, "net:%s", netdev_name);


Why the "net:" prefix in the filename?


Because I drew upon dev_change_name() method in net/core/dev.c.
The device_rename() in the above function makes use of same prefix 
related to netdev.



 static int setup_target_sysfs(struct netconsole_target *nt)
 {
+   int retval = 0;
+   char *name;
+
kobject_set_name(&nt->obj, "port%d", nt->id);
nt->obj.parent = &netconsole_miscdev.this_device->kobj;
nt->obj.ktype = &target_ktype;
-   return kobject_register(&nt->obj);
+   retval = kobject_register(&nt->obj);
+   name = make_netdev_class_name(nt->np.dev_name);
+   if (!name)
+   return -ENOMEM;


Just call kasprintf() directly, why the obfuscation?



I drew upon dev_change_name() method in net/core/dev.c.

Thanks
--
Keiichi KII
NEC Corporation OSS Platform Development Division
E-mail: [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: [RFC][PATCH -mm take5 6/7] add ioctls for adding/removing target

[Keiichi KII]

Hello Satyam,


*ugh*. I was wondering what a show-stopper this particular patch
was -- introduces a couple of ioctl()'s, exports a new structure to
userspace, adds a hitherto-unneeded header file, brings in
tty_struct/tty_operations and ends up adding so much complexity/
bloat to netconsole.c. Not only that, it must live together (and
side-by-side) with the sysfs interface also, because the two of them
do different things: sysfs to be able to modify target parameters at
run-time and the ioctl()'s to dynamically add/remove targets. We
can't really mkdir(2) or rmdir(2) in sysfs so the ioctl()'s are needed.

So may I suggest:

Just lose *both* the sysfs and ioctl() interfaces and use _configfs_.
It is *precisely* the thing you need in your driver here -- the ability
to create / destroy kernel objects (or config_items in configfs lingo)
from _userspace_ via simple mkdir(2) and rmdir(2). And configfs
makes changing multiple configurable parameters atomically trivial
too, via rename(2) ... not to mention a sysfs+ioctls -> configfs
conversion would help your patchset lose some weight too :-)


Stephen Hemminger previously advised me	about the user interface such as 
the following messages.



Some other speculations:
1. Would it be possible to add ioctl's to /dev/console? This would be more in
keeping with older Unix style model.

2. Using sysfs makes sense if there is a device object that exists to
   add the sysfs attributes to.

3. Procfs is handy for summary type tables.

4. Netlink does feel like overkill for this. Although newer generic netlink
   makes it easier.


So, I implemented ioctls to add/remove port like this patch on the tty driver.
But I'm going to search configfs. Thank you for you information.

Thanks
--
Keiichi KII
NEC Corporation OSS Platform Development Division
E-mail: [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 1/2] kprobes i386 quick fix mark-ro-data

[S. P. Prasanna]

On Mon, Jun 18, 2007 at 09:32:56PM +0200, Andi Kleen wrote:
> On Monday 18 June 2007 20:56:32 Andrew Morton wrote:
> > On Mon, 18 Jun 2007 14:44:57 -0400
> > Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> > 
> > > > I fancy it's done by the kprobe_page_fault handler, but I do not see
> > > > clearly how writing the breakpoint from arch_arm_kprobe() in
> > > > non-writeable memory is done.
> > > 
> > > Looks like it's not merged yet:
> > > 
> > > http://lkml.org/lkml/2007/6/7/2
> > > 
> > > This needs to go in before 2.6.22-final
> > 
> > Andi, I'll include the below two patches in the next batch, OK?
> 
> It won't work reliably unless some of the c_p_a() fixes get in first.
> 
> > 
> > 
> > 
> > +extern int kernel_text_is_ro;
> 
> No externs in .c files
Yes.
> 
> 
> I also don't like kernel_text_is_read_only() much, it would
> be better to just lookup_address() it and check the write flag.

Yes, I will look into this approach.
> 
> But for 2.6.22 as a quick fix it might be better to just
> make KPROBES dependent on !DEBUG_RODATA. That would be a one liner.
> 

Please find the quick fix as per your suggestion below.

Thanks
Prasanna

This patch is a quick fix to enable kprobes only if DEBUG_RODATA is
not configured. Since DEBUG_RODATA markes the kernel text pages as read-only.

Signed-off-by: Prasanna S P. <[EMAIL PROTECTED]>


 arch/i386/Kconfig |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff -puN arch/i386/Kconfig~kprobes-quick-fix-mark-ro-data-i386 
arch/i386/Kconfig
--- linux-2.6.22-rc5/arch/i386/Kconfig~kprobes-quick-fix-mark-ro-data-i386  
2007-06-19 14:55:31.0 +0530
+++ linux-2.6.22-rc5-prasanna/arch/i386/Kconfig 2007-06-19 14:55:31.0 
+0530
@@ -1212,6 +1212,8 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
+source "arch/i386/Kconfig.debug"
+
 menu "Instrumentation Support"
depends on EXPERIMENTAL
 
@@ -1219,7 +1221,7 @@ source "arch/i386/oprofile/Kconfig"
 
 config KPROBES
bool "Kprobes (EXPERIMENTAL)"
-   depends on KALLSYMS && EXPERIMENTAL && MODULES
+   depends on KALLSYMS && EXPERIMENTAL && MODULES && !DEBUG_RODATA
help
  Kprobes allows you to trap at almost any kernel address and
  execute a callback function.  register_kprobe() establishes
@@ -1228,8 +1230,6 @@ config KPROBES
  If in doubt, say "N".
 endmenu
 
-source "arch/i386/Kconfig.debug"
-
 source "security/Kconfig"
 
 source "crypto/Kconfig"

_
-- 
Prasanna S.P.
Linux Technology Center
India Software Labs, IBM Bangalore
Email: [EMAIL PROTECTED]
Ph: 91-80-41776329
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] kprobes x86_64 quick fix mark-ro-data

[S. P. Prasanna]

This patch is a quick fix for x86_64 to enable kprobes only if DEBUG_RODATA is
not configured. Since DEBUG_RODATA markes the kernel text pages as read-only.

Signed-off-by: Prasanna S P. <[EMAIL PROTECTED]>


 arch/x86_64/Kconfig |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff -puN arch/x86_64/Kconfig~kprobes-quick-fix-mark-ro-data-x86_64 
arch/x86_64/Kconfig
--- linux-2.6.22-rc5/arch/x86_64/Kconfig~kprobes-quick-fix-mark-ro-data-x86_64  
2007-06-19 14:55:56.0 +0530
+++ linux-2.6.22-rc5-prasanna/arch/x86_64/Kconfig   2007-06-19 
14:55:56.0 +0530
@@ -764,6 +764,8 @@ source "drivers/firmware/Kconfig"
 
 source fs/Kconfig
 
+source "arch/x86_64/Kconfig.debug"
+
 menu "Instrumentation Support"
 depends on EXPERIMENTAL
 
@@ -771,7 +773,7 @@ source "arch/x86_64/oprofile/Kconfig"
 
 config KPROBES
bool "Kprobes (EXPERIMENTAL)"
-   depends on KALLSYMS && EXPERIMENTAL && MODULES
+   depends on KALLSYMS && EXPERIMENTAL && MODULES && !DEBUG_RODATA
help
  Kprobes allows you to trap at almost any kernel address and
  execute a callback function.  register_kprobe() establishes
@@ -780,8 +782,6 @@ config KPROBES
  If in doubt, say "N".
 endmenu
 
-source "arch/x86_64/Kconfig.debug"
-
 source "security/Kconfig"
 
 source "crypto/Kconfig"

_
-- 
Prasanna S.P.
Linux Technology Center
India Software Labs, IBM Bangalore
Email: [EMAIL PROTECTED]
Ph: 91-80-41776329
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC: 2.6 patch] sound/pci/hda/patch_realtek.c: remove dead code

[Takashi Iwai]

At Fri, 15 Jun 2007 23:45:31 +0200,
Adrian Bunk wrote:
> 
> This patch removes dead code spotted by the Coverity checker.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

This appears to be a copy-and-paste error from other
auto-configuration code.  I fixed it on ALSA tree now so that it'll be
merged to the next mm...


thanks,

Takashi

> 
> ---
> 
>  sound/pci/hda/patch_realtek.c |7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> --- linux-2.6.22-rc4-mm2/sound/pci/hda/patch_realtek.c.old2007-06-15 
> 21:48:12.0 +0200
> +++ linux-2.6.22-rc4-mm2/sound/pci/hda/patch_realtek.c2007-06-15 
> 23:12:40.0 +0200
> @@ -10704,30 +10704,31 @@ static struct hda_verb alc662_init_verbs
>   /* Mixer elements: 0x18, 19, 1a, 1b, 1c, 1d, 14, 15, 16, 17, 0b */
>   /* Input mixer */
>   {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
>   {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)},
>   {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(2)},
>   {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(4)},
>   { }
>  };
>  
>  static struct hda_verb alc662_sue_init_verbs[] = {
>   {0x14, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN|ALC880_FRONT_EVENT},
>   {0x1b, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN|ALC880_HP_EVENT},
>  {}
>  };
>  
> +#if 0
>  /*
>   * generic initialization of ADC, input mixers and output mixers
>   */
>  static struct hda_verb alc662_auto_init_verbs[] = {
>   /*
>* Unmute ADC and set the default input to mic-in
>*/
>   {0x09, AC_VERB_SET_CONNECT_SEL, 0x00},
>   {0x09, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
>  
>   /* Unmute input amps (CD, Line In, Mic 1 & Mic 2) of the analog-loopback
>* mixer widget
>* Note: PASD motherboards uses the Line In 2 as the input for front
>* panel mic (mic 2)
>*/
> @@ -10755,30 +10756,31 @@ static struct hda_verb alc662_auto_init_
>   {0x04, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
>   {0x04, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)},
>  
>  
>   /* FIXME: use matrix-type input source selection */
>   /* Mixer elements: 0x18, 19, 1a, 1b, 1c, 1d, 14, 15, 16, 17, 0b */
>   /* Input mixer */
>   {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
>   {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)},
>   {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(2)},
>   /*{0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(3)},*/
>   {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(4)},
>  
>   { }
>  };
> +#endif  /*  0  */
>  
>  /* capture mixer elements */
>  static struct snd_kcontrol_new alc662_capture_mixer[] = {
>   HDA_CODEC_VOLUME("Capture Volume", 0x09, 0x0, HDA_INPUT),
>   HDA_CODEC_MUTE("Capture Switch", 0x09, 0x0, HDA_INPUT),
>   {
>   .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
>   /* The multiple "Capture Source" controls confuse alsamixer
>* So call somewhat different..
>* FIXME: the controls appear in the "playback" view!
>*/
>   /* .name = "Capture Source", */
>   .name = "Input Source",
>   .count = 1,
>   .info = alc882_mux_enum_info,
> @@ -11152,35 +11154,30 @@ static int alc662_parse_auto_config(stru
>   err = alc662_auto_create_analog_input_ctls(spec, &spec->autocfg);
>   if (err < 0)
>   return err;
>  
>   spec->multiout.max_channels = spec->multiout.num_dacs * 2;
>  
>   if (spec->autocfg.dig_out_pin)
>   spec->multiout.dig_out_nid = ALC880_DIGOUT_NID;
>  
>   if (spec->kctl_alloc)
>   spec->mixers[spec->num_mixers++] = spec->kctl_alloc;
>  
>   spec->num_mux_defs = 1;
>   spec->input_mux = &spec->private_imux;
>   
> - if (err < 0)
> - return err;
> - else if (err > 0)
> - /* hack - override the init verbs */
> - spec->init_verbs[0] = alc662_auto_init_verbs;
>   spec->mixers[spec->num_mixers] = alc662_capture_mixer;
>   spec->num_mixers++;
>   return err;
>  }
>  
>  /* additional initialization for auto-configuration model */
>  static void alc662_auto_init(struct hda_codec *codec)
>  {
>   alc662_auto_init_multi_out(codec);
>   alc662_auto_init_hp_out(codec);
>   alc662_auto_init_analog_input(codec);
>  }
>  
>  static int patch_alc662(struct hda_codec *codec)
>  {
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Johannes Stezenbach]

On Mon, Jun 18, 2007, Alexandre Oliva wrote:
> On Jun 18, 2007, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> 
> > Hm, you only talk about people who already use free software,
> > but I tried to make you aware of the importance of
> > _promoting_ free software, i.e. winning new people and
> > companies for the free software idea.
> 
> Aah, I see.  Indeed, I'd missed that aspect.  Sorry about that.
> 
> My take on it is that bringing free loaders in doesn't help us much,
> and bringing them in in a way that they don't learn the essential
> aspects of the community will hurt the community in the long run.
> 
> So they must become aware that respecting others' freedoms is not only
> the right thing to do, from a moral and ethical standpoint, but also
> that this is precisely what enables our community to thrive, and to
> enable everyone to get the best out of the software we cooperate to
> develop.

The keywords here are "learn" and "become aware": It's a process
which takes time, and which requires ongoing communication.

I argue that if you keep the free loaders out, you miss
the chance to communicate with and educate them.
Communication across borders doesn't work well, and you create
a border between the morally "good" and the "bad".

Of course you can't expect that every free loader will
learn and accept the free software philosopy, some just
won't. But to me that's acceptable, and the GPLv2, or indeed
Linus' tit-for-tat interpretation of the GPLv2, is IMHO
sufficient to protect my interests.

> Of course we might get some additional contributions here and there,
> but then more and more users would still be stuck, unable or limited
> in the ways and incentives they have to participate in our community.
> Permitting this is very short-sighted.  It might bring us apparent
> advantages in the short run, but the more such disrespects there are,
> the more there will be, and the fewer users will be able to become
> developers.  In the end, this may kill the whole process, in a tragedy
> of the commons.  In the article linked below, I argue this very point,
> comparing how the demand for respecting users' freedoms is what keeps
> the free-loaders away and makes the GPL the most cost-effective
> license for software development, compared with permissive licenses
> and non-Free licenses.  The very same arguments apply to a comparison
> between a license that permits tivoization and one that doesn't,
> because the latter is more likely to have more contributors to share
> the load, and both equally reduce the likelihood of unmergeable forks.
> http://www.lsd.ic.unicamp.br/~oliva/papers/free-software/BMind.pdf

I'm not arguing about the GPL, especially not against the GPLv2.

What I'm concerned about is that the language you use trying to
promote the GPLv3 is IMHO anti-promotion of free software.

I believe executives don't read licenses. What they'll read is
the random article about "GPLv3 to outlaw tivoization",
"FSF wants to keep free loaders away" etc.

What is more likely, that they'll go to www.gnu.org to read
and absorb the GNU philosopy in order to become an accepted
member of the free software community, or that they'll decide to
stick with their proprietary RTOS then?


Johannes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFC] oops and panic message logging to MTD

[Artem Bityutskiy]

On Tue, 2007-06-19 at 11:00 +0100, Richard Purdie wrote:
> On Tue, 2007-06-19 at 10:55 +0300, Artem Bityutskiy wrote:
> > On Mon, 2007-06-18 at 17:31 +0100, Richard Purdie wrote:
> > > + if (mtd->erasesize < OOPS_PAGE_SIZE)
> > > + erase.len = OOPS_PAGE_SIZE;
> > 
> > It seems to me that your code won't work if mtd->erasesize <
> > OOPS_PAGE_SIZE anyway, so this check should not be here I guess.
> 
> Its just a sanity check...

Then do this once in the "add" notifier.

> > Well, mtd->block_isbad() may return error, unlikely, bu still. You also
> > ignore the error at other places.
> 
> Ignoring that is deliberate since it doesn't really matter if the block
> is bad or we can't read from it, the action is the same...

No, bad EB is a perfectly legal thing and you should deal with it. Error
code means that something very bad and sever is going on and you have to
just refuse working with this device.

> > Also, do not ignore error code of mtd->block_markbad()
> 
> All we can do is print a warning, the action will be the same...

No, the action should be returning an error and refuse doing more work.

> > Also, could you please use wait_event_interruptible() instead of
> > set_current_state() which looks better (indeed, you have wait queue, 
> > so use wq calls).
> 
> That piece of code is in keeping with the rest of the mtd erase handling
> code. Looking through the various wq macros, I don't see any which help
> particularly in this case...

Well, it is matter of taste so I do not insist. But I think
wait_event_interruptible() is much nicer. Glance at drivers/ubi/io.c how
it looks.

-- 
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] atmel_serial: Fix break handling

[Ivan Kuten]

On Mon, 18 Jun 2007 11:33:54 +0100
Russell King wrote:

> On Mon, Jun 18, 2007 at 01:21:21PM +0300, Ivan Kuten wrote:
> > Hi Haavard,
> > 
> > I tried /dev/ttyAT3, break appeared but not the way I expected, after:
> > stty -F /dev/ttyAT3 brkint I get:
> > 
> > cat /proc/tty/driver/atmel_serial 
> > serinfo:1.0 driver revision:
> > 0: uart:ATMEL_SERIAL mmio:0xFEFFF200 irq:1 tx:0 rx:0 CTS|DSR|CD|RI
> > 1: uart:ATMEL_SERIAL mmio:0xFFFC irq:6 tx:0 rx:0 CTS|DSR|CD|RI  
> >
> > 2: uart:ATMEL_SERIAL mmio:0xFFFC4000 irq:7 tx:0 rx:0 RI 
> >
> > 3: uart:ATMEL_SERIAL mmio:0xFFFC8000 irq:8 tx:1530 rx:115 brk:1 
> > RTS|DTR|DSR|CD|RI
> > 4: uart:ATMEL_SERIAL mmio:0xFFFCC000 irq:9 tx:0 rx:0 DSR|CD|RI  
> > 
> > brk is 1 not depending on how many breaks was sent. May be I missunderstood
> > "break" meaning?
> > I use from minicom: Main Functions : send break.F . 
> 
> Note that if you want to use magic sysrq on ttyAT3, you need the kernel
> console on ttyAT3.  Since you successfully received one break event on
> ttyAT3, the next character should have caused a sysrq event.
> 

Yes, I added to kernel command line "console=ttyAT3,115200" . 

I do not receive brk event via minicom, break counter sets to 1 only if I issue
this command: stty -F /dev/ttyAT3 brkint 

Anyway I try to debug further to locate the problem.

BR,
Ivan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: v2.6.21.4-rt11

[Srivatsa Vaddagiri]

On Tue, Jun 19, 2007 at 11:04:30AM +0200, Ingo Molnar wrote:
> I'm wondering, why did this trigger under CFS and not on mainline? 

I thought Paul had seen the same problem with 2.6.21.5. I will try a
more recent mainline (2.6.22-rc5 maybe) after I get hold of the problem
machine and report later today.

If there is any difference, it should be because of the reported topology
by low-level platform code. In the problem case, each CPU was being reported
to be a separate node (CONFIG_NUMA enabled) which caused idle_balance()
to stop load-balance lookups at cpu/node level itself. 

> Mainline seems to have a similar problem in idle_balance() too, or am i 
> misreading it?

-- 
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: XFS internal error xfs_da_do_buf(2) at line 2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b00bd

[Marco Berizzi]

Marco Berizzi wrote:

> David Chinner wrote:
>
> > On Fri, Jun 08, 2007 at 03:59:39PM +0200, Marco Berizzi wrote:
> > > David Chinner wrote:
> > > > Where we saw signs of on disk directory corruption. Have you run
> > > > xfs_repair successfully on the filesystem since you reported
> > > > this?
> > >
> > > yes.
> > >
> > > > If you did clean up the error, does xfs_repair report the same
> sort
> > > > of error again?
> > >
> > > I have run xfs_repair this morning.
> > > Here is the report:
> >
> > 
> >
> > > > Have you run a 2.6.16-rcX or 2.6.17.[0-6] kernel since you last
> > > > reported this problem?
> > >
> > > No. I have run only 2.6.19.x and 2.6.21.x
> > >
> > > After the xfs_repair I have remounted the file system.
> > > After few hours linux has crashed with this message:
> > > BUG: at arch/i386/kernel/smp.c:546 smp_call_function()
> > > I have also the monitor bitmap.
> >
> > This is sounding like memory corruption is no corruption is being
> > found on disk by xfs_repair.  Have you run memtest86 on that box to
> > see if it's got bad memory?
>
> Yes. I have run memtest for one week:
> no errors.
> I have also changed the mother board,
> scsi controller and ram. Only the cpu
> and the 2 hot swap scsi disks were
> not replaced. IMHO this isn't an
> hardware problem, because the kernel
> with debugging options enabled didn't
> crash for a long time (>1 month). Just
> for record, at this moment this box is
> running 2.6.22-rc4 with no debug
> options enabled. I will keep you
> informed.
> Thanks everybody for the support.

Hi David,
on another system which is doing the
same task (openswan + squid), this
morning I have found the following
errors (2.6.21.5 after 4 days uptime).
The tricky thing is that always the
squid file cache filesystem is
corrupted. The same box with 2.6.20.x
and 2.6.21.x with 'Debug slab memory
allocations' enabled, never show any
errors for 1 month.

# dmesg
Linux version 2.6.21.5 ([EMAIL PROTECTED]) (gcc version 3.3.6) #1 Thu Jun 14
13:18:08 CEST 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start:  size: 0009f800 end:
0009f800 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 0009f800 size: 0800 end:
000a type: 2
copy_e820_map() start: 000f size: 0001 end:
0010 type: 2
copy_e820_map() start: 0010 size: 09f0 end:
0a00 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start:  size: 0001 end:
0001 type: 2
 BIOS-e820:  - 0009f800 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 0a00 (usable)
 BIOS-e820:  - 0001 (reserved)
160MB LOWMEM available.
Entering add_active_range(0, 0, 40960) 0 entries of 256 used
Zone PFN ranges:
  DMA 0 -4096
  Normal   4096 -   40960
early_node_map[1] active PFN ranges
0:0 -   40960
On node 0 totalpages: 40960
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 288 pages used for memmap
  Normal zone: 36576 pages, LIFO batch:7
DMI 2.1 present.
Allocating PCI resources starting at 1000 (gap: 0a00:f5ff)
Built 1 zonelists.  Total pages: 40640
Kernel command line: auto BOOT_IMAGE=Linux ro root=301
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to d000 (01141000)
Enabling fast FPU save and restore... done.
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Detected 267.302 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 159020k/163840k available (1945k kernel code, 4392k reserved,
609k data, 156k init, 0k highmem)
virtual kernel memory layout:
fixmap  : 0xfffb7000 - 0xf000   ( 288 kB)
vmalloc : 0xca80 - 0xfffb5000   ( 855 MB)
lowmem  : 0xc000 - 0xca00   ( 160 MB)
  .init : 0xc0382000 - 0xc03a9000   ( 156 kB)
  .data : 0xc02e667c - 0xc037eb94   ( 609 kB)
  .text : 0xc010 - 0xc02e667c   (1945 kB)
Checking if this processor honours the WP bit even in supervisor mode...
Ok.
Calibrating delay using timer specific routine.. 535.23 BogoMIPS
(lpj=1070464)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0183f9ff   
  
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: After all inits, caps: 0183f9ff   0040 
 
CPU: Intel Celeron (Covington) stepping 00
Checking 'hlt' instruction... OK.
ACPI: Core revision 20070126
ACPI Exception (tbxface-0618): AE_NO_ACPI_TABLES, While loading
namespace from ACPI tables [20070126]
ACPI: Unable to load th

Re: [PATCH/RFC] oops and panic message logging to MTD

[Richard Purdie]

On Tue, 2007-06-19 at 13:29 +0300, Artem Bityutskiy wrote:
> On Tue, 2007-06-19 at 11:00 +0100, Richard Purdie wrote:
> > > Well, mtd->block_isbad() may return error, unlikely, bu still. You also
> > > ignore the error at other places.
> > 
> > Ignoring that is deliberate since it doesn't really matter if the block
> > is bad or we can't read from it, the action is the same...
> 
> No, bad EB is a perfectly legal thing and you should deal with it.

The code does.

>  Error
> code means that something very bad and sever is going on and you have to
> just refuse working with this device.

In this case, it will just move on to the next EB. There is code to
handle no available EBs at which point it will refuse to work with the
device.

> > > Also, do not ignore error code of mtd->block_markbad()
> > 
> > All we can do is print a warning, the action will be the same...
> 
> No, the action should be returning an error and refuse doing more work.

It will refuse to do more work if no usable EB is available but it will
try others first. It can be assumed mtdoops will only be used with small
partitions so trying to find a usable EB before giving a fatal error
shouldn't have much of an impact on the system and might just let it
keep working in some strange error cases (and since its an error logger,
that is good).

> > > Also, could you please use wait_event_interruptible() instead of
> > > set_current_state() which looks better (indeed, you have wait queue, 
> > > so use wq calls).
> > 
> > That piece of code is in keeping with the rest of the mtd erase handling
> > code. Looking through the various wq macros, I don't see any which help
> > particularly in this case...
> 
> Well, it is matter of taste so I do not insist. But I think
> wait_event_interruptible() is much nicer. Glance at drivers/ubi/io.c how
> it looks.

I'll have a look.

Cheers,

Richard

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] I2C: TSL2550 support.

[Rodolfo Giometti]

Add support for Taos TSL2550 ambient light sensors.
(http://www.taosinc.com/product_detail.asp?cateid=4&proid=18).

Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
 drivers/i2c/chips/Kconfig   |   10 +
 drivers/i2c/chips/Makefile  |1 +
 drivers/i2c/chips/tsl2550.c |  427 +++
 3 files changed, 438 insertions(+), 0 deletions(-)
 create mode 100644 drivers/i2c/chips/tsl2550.c

diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index ea085a0..b59c013 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -124,4 +124,14 @@ config SENSORS_MAX6875
  This driver can also be built as a module.  If so, the module
  will be called max6875.
 
+config SENSORS_TSL2550
+   tristate "Taos TSL2550 ambient light sensor"
+   depends on I2C && EXPERIMENTAL
+   help
+ If you say yes here you get support for the Taos TSL2550
+ ambient light sensor.
+
+ This driver can also be built as a module.  If so, the module
+ will be called tsl2550.
+
 endmenu
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 779868e..1ef6a04 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o
 obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
 obj-$(CONFIG_TPS65010) += tps65010.o
+obj-$(CONFIG_SENSORS_TSL2550)  += tsl2550.o
 
 ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
 EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/i2c/chips/tsl2550.c b/drivers/i2c/chips/tsl2550.c
new file mode 100644
index 000..fd7f87c
--- /dev/null
+++ b/drivers/i2c/chips/tsl2550.c
@@ -0,0 +1,427 @@
+/*
+ *  tsl2550.c - Linux kernel modules for ambient light sensor
+ *
+ *  Copyright (C) 2007 Rodolfo Giometti <[EMAIL PROTECTED]>
+ *  Copyright (C) 2007 Eurotech S.p.A. <[EMAIL PROTECTED]>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TSL2550_DRV_NAME   "tsl2550"
+#define DRIVER_VERSION "1.1.0"
+
+/* --- Defines - */
+
+#define TSL2550_POWER_DOWN 0x00
+#define TSL2550_POWER_UP   0x03
+#define TSL2550_STANDARD_RANGE 0x18
+#define TSL2550_EXTENDED_RANGE 0x1d
+#define TSL2550_READ_ADC0  0x43
+#define TSL2550_READ_ADC1  0x83
+
+/* --- Structs - */
+
+struct tsl2550_data {
+   struct i2c_client *client;
+   struct mutex update_lock;
+
+   unsigned int power_state : 1;
+   unsigned int operating_mode : 1;
+};
+
+/* --- Management functions  */
+
+static int tsl2550_set_operating_mode(struct i2c_client *client, int mode)
+{
+   struct tsl2550_data *data = i2c_get_clientdata(client);
+   int ret;
+
+   mode = !!mode;
+   if (mode == data->operating_mode)
+   return 0;
+
+   if (mode == 0)
+   ret = i2c_smbus_write_byte(client, TSL2550_STANDARD_RANGE);
+   else 
+   ret = i2c_smbus_write_byte(client, TSL2550_EXTENDED_RANGE);
+
+   data->operating_mode = mode;
+
+   return ret;
+}
+
+static int tsl2550_set_power_state(struct i2c_client *client, int state)
+{
+   struct tsl2550_data *data = i2c_get_clientdata(client);
+   int ret;
+
+   state = !!state;
+   if (state == data->power_state)
+   return 0;
+
+   if (state == 0)
+   ret = i2c_smbus_write_byte(client, TSL2550_POWER_DOWN);
+   else {
+   ret = i2c_smbus_write_byte(client, TSL2550_POWER_UP);
+
+   /* On power up we should reset operating mode also... */
+   tsl2550_set_operating_mode(client, data->operating_mode);
+   }
+
+   data->power_state = state;
+
+   return ret;
+}
+
+static int tsl2550_get_adc_value(struct i2c_client *client, int channel)
+{
+   u8 cmd = channel == 0 ? TSL2550_READ_ADC0 : TSL2550_READ_ADC1;
+   unsigned long end;
+   int loop = 0, ret = 0;
+
+   /* Read ADC channel waiting at most 400ms (see data sheet for further
+ * info).
+  

Re: [PATCH/RFC] oops and panic message logging to MTD

[Artem Bityutskiy]

On Tue, 2007-06-19 at 11:52 +0100, Richard Purdie wrote:
> >  Error
> > code means that something very bad and sever is going on and you have to
> > just refuse working with this device.
> 
> In this case, it will just move on to the next EB. There is code to
> handle no available EBs at which point it will refuse to work with the
> device.

My point is that instead of moving you should return error. You cannot
keep working with this device just because something really bad
happened, you do not know what, and you cannot react accordingly because
you do not know how.

-- 
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: How to improve the quality of the kernel?

[Stefan Richter]

Natalie Protasevich wrote:
> On 6/18/07, Fortier,Vincent [Montreal] <[EMAIL PROTECTED]> wrote:
[...]
>> In the end plenty of statistics and hardware compatibility list
>> could be made.  For example, that would make my life easier knowing
>> what level of compatibility Linux can offer for old HP9000 K-boxes
>> that we still have running at the office and presumably get people
>> to contact to get help?
> 
> This is definitely something that can be done (and should) - well,
> especially having ability search by certain criteria - then all sorts
> of statistics and databases can be created.

Hardware Compatibility Lists/ Databases already exist, for driver
subsystems, for distributions...

Some issues with those databases are:

  - Users typically can only test one specific combination of a
hardware collection and software collection, at one or a few points
in time.

  - Users have difficulties or don't have the means to identify chip
revisions, used protocols etc.

  - The databases are typically not conceived to serve additional
purposes like bidirectional contact between developer and user.

These issues notwithstanding, these databases are already highly useful
both for endusers and for developers.  That's why they exist.

> Everything that helps  to find a way to work on a patch and to test
> easier should be done to make bug fixing easier and even possible.
> Often times the most knowledgeable people are not able to make quick
> fix just because there is no way to reproduce the case or get access
> to HW.

As has been mentioned elsewhere in the thread,

  - bug---hardware associations are sometimes difficult or impossible
to make.  For example, the x86-64 platform maintainers are bothered
with "x86-64 bugs" which turn out to be driver bugs on all
platforms.

(We want details descriptions of the hardware environment in a bug
report, but this means we must be able to handle the flood of
false positives in bug---hardware associations, i.e. successively
narrow down which parts of the hardware/software combo are actually
affected, and what other combinations could be affected too.)

  - Patch---hardware associations, especially for preemptive regression
tests, are virtually impossible to make.  Murphy says that the
regression will hit hardware which the patch submitter or forwarder
thought could never be affected by the patch.

Of course, /sensible/ patch---hardware associations are (1) to try out
fixes for known issues with a specific hardware, (2) to test that a
cleanup patch or refactoring patch or API changing patch to a driver of
very specific hardware ( = a single type or few types with little
variance) does not introduce regressions for this hardware.
-- 
Stefan Richter
-=-=-=== -==- =--==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Manu Abraham]

Johannes Stezenbach wrote:

> I argue that if you keep the free loaders out, you miss
> the chance to communicate with and educate them.
> Communication across borders doesn't work well, and you create
> a border between the morally "good" and the "bad".
> 
> Of course you can't expect that every free loader will
> learn and accept the free software philosopy, some just
> won't. But to me that's acceptable, and the GPLv2, or indeed
> Linus' tit-for-tat interpretation of the GPLv2, is IMHO
> sufficient to protect my interests.

Err .. when you say protection on one hand and on the other you state
it's hard to keep free loaders away, then don't you think that those 2
are two completely different things ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 5/6] Move psw_set_key.

[Martin Schwidefsky]

On Tue, 2007-06-19 at 11:34 +0200, Heiko Carstens wrote:
> > > Move psw_set_key() from ptrace.h to processor.h which is a more
> > > suitable place for it. In addition the moves makes the function
> > > invisible to user space.
> > 
> > Hmm, this does not really describe the changes.
> 
> Yes.. you need to interchange descriptions for patches 5 & 6. Then it
> might make sense ;)

Ahem, yes, oops.. sorry.

Fixed on git390.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-lvm] 2.6.22-rc5 XFS fails after hibernate/resume

[Rafael J. Wysocki]

On Tuesday, 19 June 2007 11:24, David Greaves wrote:
> David Greaves wrote:
> > I'm going to have to do some more testing...
> done
> 
> 
> > David Chinner wrote:
> >> On Mon, Jun 18, 2007 at 08:49:34AM +0100, David Greaves wrote:
> >>> David Greaves wrote:
> >>> So doing:
> >>> xfs_freeze -f /scratch
> >>> sync
> >>> echo platform > /sys/power/disk
> >>> echo disk > /sys/power/state
> >>> # resume
> >>> xfs_freeze -u /scratch
> >>>
> >>> Works (for now - more usage testing tonight)
> >>
> >> Verrry interesting.
> > Good :)
> Now, not so good :)
> 
> 
> >> What you were seeing was an XFS shutdown occurring because the free space
> >> btree was corrupted. IOWs, the process of suspend/resume has resulted
> >> in either bad data being written to disk, the correct data not being
> >> written to disk or the cached block being corrupted in memory.
> > That's the kind of thing I was suspecting, yes.
> > 
> >> If you run xfs_check on the filesystem after it has shut down after a 
> >> resume,
> >> can you tell us if it reports on-disk corruption? Note: do not run 
> >> xfs_repair
> >> to check this - it does not check the free space btrees; instead it 
> >> simply
> >> rebuilds them from scratch. If xfs_check reports an error, then run 
> >> xfs_repair
> >> to fix it up.
> > OK, I can try this tonight...
> 
> 
> This is on 2.6.22-rc5

Is the Tejun's patch

http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc5/patches/30-block-always-requeue-nonfs-requests-at-the-front.patch

applied on top of that?

Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Optional Beeping During Resume From Suspend To Ram.

[Nigel Cunningham]

Hi all

Here's what I have after today's work.

I haven't yet been able to test on x86, but can confirm that it works okay on 
x86_64. I'm currently working towards testing it on my old Omnibook. My P4 
desktop won't resume from suspend to ram at all, and hasn't produced any beeps.

I needed to move the BEEP invocation to after the data segment is reloaded, so 
that the test could access the variable. That was pretty tricky to find - no 
oops or anything bad prior, it just didn't beep when expected.

A couple of notes:

- I'd like to put the BEEP macro somewhere that can be shared by x86 32 and 64. 
If that's a good idea, any suggestions on where? Nothing occurs to me straight 
off.
- I've just switched from Evo to Kmail. Please let me know if there's any 
mangling of the patch.

Regards,

Nigel

 arch/i386/kernel/acpi/wakeup.S   |   29 -
 arch/x86_64/kernel/acpi/wakeup.S |   25 +
 include/linux/acpi.h |1 +
 kernel/power/main.c  |   23 +++
 4 files changed, 77 insertions(+), 1 deletion(-)
diff -ruNp 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S 
970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S
--- 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S   2007-06-19 
12:15:25.0 +1000
+++ 970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S   2007-06-19 
21:14:49.0 +1000
@@ -11,7 +11,22 @@
 #
 # If physical address of wakeup_code is 0x12345, BIOS should call us with
 # cs = 0x1234, eip = 0x05
-# 
+#
+
+#define BEEP \
+   inb $97, %al;   \
+   outb%al, $0x80; \
+   movb$3, %al;\
+   outb%al, $97;   \
+   outb%al, $0x80; \
+   movb$-74, %al;  \
+   outb%al, $67;   \
+   outb%al, $0x80; \
+   movb$-119, %al; \
+   outb%al, $66;   \
+   outb%al, $0x80; \
+   movb$15, %al;   \
+   outb%al, $66;
 
 ALIGN
.align  4096
@@ -31,6 +46,11 @@ wakeup_code:
movw%cs, %ax
movw%ax, %ds# Make ds:0 
point to wakeup_start
movw%ax, %ss
+
+   testl   $1, beep_flags - wakeup_code
+   jz  1f
+   BEEP
+1:
mov $(wakeup_stack - wakeup_code), %sp  # Private stack 
is needed for ASUS board
movw$0x0e00 + 'S', %fs:(0x12)
 
@@ -88,6 +108,10 @@ wakeup_code:
cmpl$0x12345678, %eax
jne bogus_real_magic
 
+   testl   $2, beep_flags - wakeup_code
+   jz  1f
+   BEEP
+1:
ljmpl   $__KERNEL_CS,$wakeup_pmode_return
 
 real_save_gdt: .word 0
@@ -98,6 +122,7 @@ real_save_cr4:   .long 0
 real_magic:.long 0
 video_mode:.long 0
 video_flags:   .long 0
+beep_flags:.long 0
 real_efer_save_restore:.long 0
 real_save_efer_edx:.long 0
 real_save_efer_eax:.long 0
@@ -261,6 +286,8 @@ ENTRY(acpi_copy_wakeup_routine)
movl%edx, video_mode - wakeup_start (%eax)
movlacpi_video_flags, %edx
movl%edx, video_flags - wakeup_start (%eax)
+   movls2ram_beep, %edx
+   movl%edx, beep_flags - wakeup_start (%eax)
movl$0x12345678, real_magic - wakeup_start (%eax)
movl$0x12345678, saved_magic
ret
diff -ruNp 970-str-beep.patch-old/arch/x86_64/kernel/acpi/wakeup.S 
970-str-beep.patch-new/arch/x86_64/kernel/acpi/wakeup.S
--- 970-str-beep.patch-old/arch/x86_64/kernel/acpi/wakeup.S 2007-06-19 
12:15:28.0 +1000
+++ 970-str-beep.patch-new/arch/x86_64/kernel/acpi/wakeup.S 2007-06-19 
21:14:49.0 +1000
@@ -16,6 +16,21 @@
 # cs = 0x1234, eip = 0x05
 #
 
+#define BEEP \
+   inb $97, %al;   \
+   outb%al, $0x80; \
+   movb$3, %al;\
+   outb%al, $97;   \
+   outb%al, $0x80; \
+   movb$-74, %al;  \
+   outb%al, $67;   \
+   outb%al, $0x80; \
+   movb$-119, %al; \
+   outb%al, $66;   \
+   outb%al, $0x80; \
+   movb$15, %al;   \
+   outb%al, $66;
+
 
 ALIGN
.align  16
@@ -33,6 +48,13 @@ wakeup_code:
movw%cs, %ax
movw%ax, %ds# Make ds:0 point to wakeup_start
movw%ax, %ss
+
+   # Data segment must be set up before we can see whether to beep.
+   testl   $1, beep_flags - wakeup_code
+   jz  1f
+   BEEP
+1:
+
# Private stack is needed for ASUS board
mov $(wakeup_stack - wakeup_code), %sp
 
@@ -229,6 +251,7 @@ gdt_48a:
.long   gdta - wakeup_code  # gdt base (relocated in later)

 real_magic:.quad 0
+beep_flags:.quad 0
 video_mode:.quad 0
 video_flags:   .quad 0
 
@@ -344,6 +367,8 @@ ENTRY(acpi_copy_wakeup_routine)
pushq   %rax
pushq   %rdx
 
+   movls

Re: [PATCH] I2C: TSL2550 support.

[Trilok Soni]

Hi Rodolfo,

On 6/19/07, Rodolfo Giometti <[EMAIL PROTECTED]> wrote:

Add support for Taos TSL2550 ambient light sensors.
(http://www.taosinc.com/product_detail.asp?cateid=4&proid=18).

Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
 drivers/i2c/chips/Kconfig   |   10 +
 drivers/i2c/chips/Makefile  |1 +
 drivers/i2c/chips/tsl2550.c |  427 +++
 3 files changed, 438 insertions(+), 0 deletions(-)
 create mode 100644 drivers/i2c/chips/tsl2550.c

diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index ea085a0..b59c013 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -124,4 +124,14 @@ config SENSORS_MAX6875
  This driver can also be built as a module.  If so, the module
  will be called max6875.

+config SENSORS_TSL2550
+   tristate "Taos TSL2550 ambient light sensor"
+   depends on I2C && EXPERIMENTAL
+   help
+ If you say yes here you get support for the Taos TSL2550
+ ambient light sensor.
+
+ This driver can also be built as a module.  If so, the module
+ will be called tsl2550.
+
 endmenu
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 779868e..1ef6a04 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o
 obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
 obj-$(CONFIG_TPS65010) += tps65010.o
+obj-$(CONFIG_SENSORS_TSL2550)  += tsl2550.o

 ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
 EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/i2c/chips/tsl2550.c b/drivers/i2c/chips/tsl2550.c
new file mode 100644
index 000..fd7f87c
--- /dev/null
+++ b/drivers/i2c/chips/tsl2550.c
@@ -0,0 +1,427 @@
+/*
+ *  tsl2550.c - Linux kernel modules for ambient light sensor
+ *
+ *  Copyright (C) 2007 Rodolfo Giometti <[EMAIL PROTECTED]>
+ *  Copyright (C) 2007 Eurotech S.p.A. <[EMAIL PROTECTED]>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TSL2550_DRV_NAME   "tsl2550"
+#define DRIVER_VERSION "1.1.0"
+
+/* --- Defines - */
+
+#define TSL2550_POWER_DOWN 0x00
+#define TSL2550_POWER_UP   0x03
+#define TSL2550_STANDARD_RANGE 0x18
+#define TSL2550_EXTENDED_RANGE 0x1d
+#define TSL2550_READ_ADC0  0x43
+#define TSL2550_READ_ADC1  0x83
+
+/* --- Structs - */
+
+struct tsl2550_data {
+   struct i2c_client *client;
+   struct mutex update_lock;
+
+   unsigned int power_state : 1;
+   unsigned int operating_mode : 1;
+};
+
+/* --- Management functions  */
+
+static int tsl2550_set_operating_mode(struct i2c_client *client, int mode)
+{
+   struct tsl2550_data *data = i2c_get_clientdata(client);
+   int ret;
+
+   mode = !!mode;
+   if (mode == data->operating_mode)
+   return 0;
+
+   if (mode == 0)
+   ret = i2c_smbus_write_byte(client, TSL2550_STANDARD_RANGE);
+   else
+   ret = i2c_smbus_write_byte(client, TSL2550_EXTENDED_RANGE);
+
+   data->operating_mode = mode;
+
+   return ret;
+}
+
+static int tsl2550_set_power_state(struct i2c_client *client, int state)
+{
+   struct tsl2550_data *data = i2c_get_clientdata(client);
+   int ret;
+
+   state = !!state;
+   if (state == data->power_state)
+   return 0;
+
+   if (state == 0)
+   ret = i2c_smbus_write_byte(client, TSL2550_POWER_DOWN);
+   else {
+   ret = i2c_smbus_write_byte(client, TSL2550_POWER_UP);
+
+   /* On power up we should reset operating mode also... */
+   tsl2550_set_operating_mode(client, data->operating_mode);
+   }
+
+   data->power_state = state;
+
+   return ret;
+}
+
+static int tsl2550_get_adc_value(struct i2c_client *client, int channel)
+{
+   u8 cmd = channel == 0 ? TSL2550_READ_ADC0 : TSL2550_READ_ADC1;
+   unsigned long end;
+   int loop = 0, ret = 0;
+
+   /* Read ADC channel waiting 

Re: [patch-mm 00/25] High resolution timer updates and x86_64 support - V2

[Valdis . Kletnieks]

On Mon, 18 Jun 2007 17:49:44 EDT, [EMAIL PROTECTED] said:

> A quick check shows that the keep_proc_acpi_power_around_001.patch from
> rc5-hrt will apply to rc4-mm2-hrt - I'll give that a try tonight and report
> back...

Confirming - I backported that patch from rc5-hrt to rc4-mm2-hrt, and
now powertop is reporting sane values again:

 PowerTOP version 1.7   (C) 2007 Intel Corporation

Cn  Avg residency (5s)  P-states (frequencies)
C0 (cpu running)(15.8%)
C10.0ms ( 0.0%) 2.00 Ghz 0.0%
C20.6ms ( 7.9%) 1.67 Ghz 0.0%
C30.7ms (76.3%) 1333 Mhz 0.0%
1000 Mhz   100.0%




pgpr5m3UAFi12.pgp
Description: PGP signature

Re: [PATCH] clarify the GPL version of contributions by Jesper Juhl in CREDITS

[Jesper Juhl]

On 18/06/07, Paul Mundt <[EMAIL PROTECTED]> wrote:

On Mon, Jun 18, 2007 at 02:33:02AM +0200, Jesper Juhl wrote:
> Just to make things clear in the light of recent discussions.
> Stuff I contribute to the Linux kernel are licensed under the terms of the
> GPL version 2.
>
> +D: All contributions are licensed under the terms of the GPL version 2.

I suspect this is the default for the vast majority of kernel developers.
Perhaps it's only worth special casing those that have an interest in
GPLv3, as the numbers are bound to be far lower -- if this sort of thing
is judged to be a good idea, that is (It's rather interesting to note
that the vast majority of GPLv3 advocates don't even have a single
changeset in the kernel, yet still feel that their input on kernel
licensing is somehow relevant or valid).


Explicitly marking the GPLv3 supporters would probably result in the
smaller set, but I just felt that it was important to make my own
position absolutely clear.

--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH] Documentation of kernel messages

[holzheu]

On Mon, 2007-06-18 at 18:36 -0700, Arjan van de Ven wrote:



> well surely the messages are caught by some userspace program,
> right? (like syslog).. that can do the lookup and make it all
> conveniently lookup-able and cross-referencable etc etc

Ok, I agree. Maybe that's really a good idea!

So what about the following proposal:

* Use printk format strings as message IDs
* Use kernel-doc (or similar mechanism) for message documentation
* Use Subsystem tag/component ID for each printk. This might be
  optional, but would make sense to get messages more unique.
* Implement a new tool (kmsg) to allow operators
  to access kernel message descriptions in a convenient way.

The kmsg tool will read the dmsg buffer together with the list of
documented printks, which has been created in the kernel build using
the format strings defined in the KMSG_DOC macros. It matches the known
format strings to the dmesg messages and informs the operator, for
which message he can get a description.

Something like:

>> kmsg
Linux version 2.6.9-42.0.3.ELsmp...

[] lp0 on fire

>> kmsg 
Desciption: your printer failed basic tests, you should check cabling

The  is generated by the kmsg tool and could be e.g. the hashes for
the matching format strings.

Michael

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mea culpa on the meaning of Tivoization

[Michael Poole]

Hans-Jürgen Koch writes:

> No. Credible licenses should be simple like physical laws. Newton's law
> is expressed in terms of a single mathematical equation. That's why it's
> still valid, and you still learn it at school although meanwhile people
> know that there are limitations to it.
>
> If you come up with a new version of a license every year, you will only
> weaken it. Please note that quantum mechanics is _not_ such a hole-plugging
> addition to Newton's law. It's a new simple physical law, expressed in terms
> of a single simple mathematical equation that contains the old law as a
> border case. If that were not the case, it would have never been accepted.

This is an excellent example of how engineers tend to mis-analyze
legal issues.  In law, neither simple wording nor interpretation is so
simple or so mechanical as the things engineers prefer to work with.

Take an example: "Thou shalt not kill".  Very clear, but also very
problematic in that it does not address military conquests (which were
apparently approved by that law's drafter), self-defense, or a number
of other cases.

There are always grey areas between what is explicitly addressed and
what is not.  Courts interpret laws and precedent in ways that make
life (and license or contract writing) more unpredictable.  Wishing
otherwise will not make a simple license unambiguous.  If those areas
of ambiguity are exploited enough, the perceived cost of having a hole
will exceed the perceived cost of plugging it.

Michael Poole
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Dumping the checksums in a module

[John Sigler]

Hello everyone,

As far as I understand (which is not very far), if I define
CONFIG_MODVERSIONS, then checksums for various functions (all exported
functions?) and various structures (which ones?) will be included inside
the kernel image, and written to Module.symvers. When an out-of-tree
module is built, it will *also* include these checksums.

How do I list ALL the checksums within a module?

$ /sbin/modinfo -V
module-init-tools version 3.2.2

$ uname -a
Linux venus 2.6.18.6 #1 PREEMPT Thu Feb 8 18:04:49 CET 2007 i686
pentium4 i386 GNU/Linux

$ /sbin/modinfo test.ko
filename:   test.ko
vermagic:   2.6.20.7-rt8 preempt mod_unload PENTIUMIII REGPARM
depends:
parm:   pConfig_file:charp
parm:   allocator_himem:An integer (int)
parm:   EnableIdleMode:An integer (int)
parm:   Board_ID:An integer (int)
parm:   Diagnostic:An integer (int)

$ hexdump -C test.ko | grep -A2 struct_
000752e0  17 98 07 0e 73 74 72 75  63 74 5f 6d 6f 64 75 6c
|struct_modul|
000752f0  65 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|e...|
00075300  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
||

I think this means that, in this module, the checksum for symbol
struct_module is 0x1798070e, right?

Is there a simpler way to list all the checksums?

Regards.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

[Chris Mason]

On Tue, Jun 19, 2007 at 10:11:13AM +0100, Pádraig Brady wrote:
> Vladislav Bolkhovitin wrote:
> > 
> > I would also suggest one more feature: support for block level
> > de-duplication. I mean:
> > 
> > 1. Ability for Btrfs to have blocks in several files to point to the
> > same block on disk
> > 
> > 2. Support for new syscall or IOCTL to de-duplicate as a single
> > transaction two or more blocks on disk, i.e. link them to one of them
> > and free others
> > 
> > 3. De-de-duplicate blocks on disk, i.e. copy them on write
> > 
> > I suppose that de-duplication itself would be done by some user space
> > process that would scan files, determine blocks with the same data and
> > then de-duplicate them by using syscall or IOCTL (2).
> > 
> > That would be very usable feature, which in most cases would allow to
> > shrink occupied disk space on 50-90%.
> 
> Have you references for this number?
> In my experience one gets a lot of benefit from
> the much simpler process of "de-duplication" of files.

Yes, I would expect simple hard links to be a better solution for this,
but the feature request is not that out of line.  I actually had plans
on implementing auto duplicate block reuse earlier in btrfs.

Snapshots already share duplicate blocks between files, and so all of
the reference counting needed to implement this already exists.
Snapshots are writable, and data mods are copy on write, and in general
things work.

But, to help fsck, the extent allocation tree has a back pointer to the
inode that owns an extent.  If you're doing snapshots, all of the owners
of the extent have the same inode number.   If you're sharing duplicate
blocks, the owners can have any inode number, and fsck becomes much more
complex.

In general, when I have to decide between fsck and a feature, I'm going
to pick fsck.  The features are much more fun, but fsck is one of the
main motivations for doing this work.

Thanks for the input,
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Final Notification.......Ref: L/200-26937

[ONLINE NOTIFICATION]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] I2C: TSL2550 support.

[Rodolfo Giometti]

Add support for Taos TSL2550 ambient light sensors.
(http://www.taosinc.com/product_detail.asp?cateid=4&proid=18).

Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
 drivers/i2c/chips/Kconfig   |   10 +
 drivers/i2c/chips/Makefile  |1 +
 drivers/i2c/chips/tsl2550.c |  449 +++
 3 files changed, 460 insertions(+), 0 deletions(-)
 create mode 100644 drivers/i2c/chips/tsl2550.c

diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index ea085a0..b59c013 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -124,4 +124,14 @@ config SENSORS_MAX6875
  This driver can also be built as a module.  If so, the module
  will be called max6875.
 
+config SENSORS_TSL2550
+   tristate "Taos TSL2550 ambient light sensor"
+   depends on I2C && EXPERIMENTAL
+   help
+ If you say yes here you get support for the Taos TSL2550
+ ambient light sensor.
+
+ This driver can also be built as a module.  If so, the module
+ will be called tsl2550.
+
 endmenu
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 779868e..1ef6a04 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o
 obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
 obj-$(CONFIG_TPS65010) += tps65010.o
+obj-$(CONFIG_SENSORS_TSL2550)  += tsl2550.o
 
 ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
 EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/i2c/chips/tsl2550.c b/drivers/i2c/chips/tsl2550.c
new file mode 100644
index 000..352538e
--- /dev/null
+++ b/drivers/i2c/chips/tsl2550.c
@@ -0,0 +1,449 @@
+/*
+ *  tsl2550.c - Linux kernel modules for ambient light sensor
+ *
+ *  Copyright (C) 2007 Rodolfo Giometti <[EMAIL PROTECTED]>
+ *  Copyright (C) 2007 Eurotech S.p.A. <[EMAIL PROTECTED]>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TSL2550_DRV_NAME   "tsl2550"
+#define DRIVER_VERSION "1.1.0"
+
+/*
+ * Defines
+ */
+
+#define TSL2550_POWER_DOWN 0x00
+#define TSL2550_POWER_UP   0x03
+#define TSL2550_STANDARD_RANGE 0x18
+#define TSL2550_EXTENDED_RANGE 0x1d
+#define TSL2550_READ_ADC0  0x43
+#define TSL2550_READ_ADC1  0x83
+
+/*
+ * Structs
+ */
+
+struct tsl2550_data {
+   struct i2c_client *client;
+   struct mutex update_lock;
+
+   unsigned int power_state : 1;
+   unsigned int operating_mode : 1;
+};
+
+/*
+ * Management functions
+ */
+
+static int tsl2550_set_operating_mode(struct i2c_client *client, int mode)
+{
+   struct tsl2550_data *data = i2c_get_clientdata(client);
+   int ret;
+
+   mode = !!mode;
+   if (mode == data->operating_mode)
+   return 0;
+
+   if (mode == 0)
+   ret = i2c_smbus_write_byte(client, TSL2550_STANDARD_RANGE);
+   else 
+   ret = i2c_smbus_write_byte(client, TSL2550_EXTENDED_RANGE);
+
+   data->operating_mode = mode;
+
+   return ret;
+}
+
+static int tsl2550_set_power_state(struct i2c_client *client, int state)
+{
+   struct tsl2550_data *data = i2c_get_clientdata(client);
+   int ret;
+
+   state = !!state;
+   if (state == data->power_state)
+   return 0;
+
+   if (state == 0)
+   ret = i2c_smbus_write_byte(client, TSL2550_POWER_DOWN);
+   else {
+   ret = i2c_smbus_write_byte(client, TSL2550_POWER_UP);
+
+   /* On power up we should reset operating mode also... */
+   tsl2550_set_operating_mode(client, data->operating_mode);
+   }
+
+   data->power_state = state;
+
+   return ret;
+}
+
+static int tsl2550_get_adc_value(struct i2c_client *client, int channel)
+{
+   u8 cmd = channel == 0 ? TSL2550_READ_ADC0 : TSL2550_READ_ADC1;
+   unsigned long end;
+   int loop = 0, ret = 0;
+
+   /*
+* Read ADC channel waiting at most 400ms (see data sheet for further
+ * info).
+* To avoid long busy wait we spin for few milliseconds then
+* start sleeping.
+*/
+   end = jiffies + msecs_to_jiffies(400);
+   

Re: [rtc-linux] RTC_CLASS is still considered as EXPERIMENTAL?

[Alessandro Zummo]

On Fri, 15 Jun 2007 20:19:59 +0200
Alessandro Zummo <[EMAIL PROTECTED]> wrote:

> On Sat, 16 Jun 2007 01:10:37 +0900 (JST)
> Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> 
> > 
> > The generic RTC subsystem was added to kernel 2.6.17 which was
> > released a years ago.  Since then, many drivers were added to the
> > subsystem without major API changes, I think.
> > 
> > It is mature enough to remove EXPERIMENTAL label from RTC_CLASS, isn't
> > it?
> 
>  I'd say yes, I will submit a patch. ty.

 RTC class is mature enough.

 Signed-off-by: Alessandro Zummo <[EMAIL PROTECTED]>


---
 drivers/rtc/Kconfig |1 -
 1 file changed, 1 deletion(-)

--- linux-i386.orig/drivers/rtc/Kconfig 2007-06-18 23:43:28.0 +0200
+++ linux-i386/drivers/rtc/Kconfig  2007-06-19 14:06:09.0 +0200
@@ -10,7 +10,6 @@ config RTC_LIB
 
 config RTC_CLASS
tristate "RTC class"
-   depends on EXPERIMENTAL
default n
select RTC_LIB
help
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fix signalfd interaction with thread-private signals

[Benjamin Herrenschmidt]

On Tue, 2007-06-19 at 13:14 +0400, Oleg Nesterov wrote:

> The commited "Fix signalfd interaction with thread-private signals"
> (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
> this.

Indeed, if you want what Davide described, you need to also change
signalfd side. The patch I did merely prevents another thread from
dequeuing somebody else private signals. As it stands, signalfd will
still try it... and only get the shared ones. It will not however get
the private signals of the caller if it is different from the context
associated with the signalfd.

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/

How do you allocate huge pages.

[Shaun Savage]

Hi

I am trying to allocate very large memory within the kernel. I want to
start by allocating one huge (4M) page and using that as buffer space.

How do you do this?

shaun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rtc-linux] Re: rtc_cmos: error after first write to wakealarm

[Alessandro Zummo]

On Fri, 15 Jun 2007 09:03:19 +0200
Tino Keitel <[EMAIL PROTECTED]> wrote:

> > > I have the following strange behaviour with rtc_cmos:
> > > 
> > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
> > > bash: echo: write error: Device or resource busy
> > > $ rmmod rtc_cmos
> > > $ modprobe rtc_cmos
> > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
> > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
> > > bash: echo: write error: Device or resource busy
> > > $
> > 
> > If the alarm has already been enabled, you cannot set the next alarm. 
> > You should disable first.
> 
> Ah, ok.
>   
> Where is the documentation that describes that I have to disable it
> first, and how to do this? A migration document for /proc/acpi/alarm   
> users would be nice, too.

 Well, I guess there is no documentation. Maybe we could add
 a dev_warn with an explicit message.


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] console UTF-8 fixes

[Egmont Koblinger]

Hi folks,

Recently my console UTF-8 patch went mainline. Here I send a very small
additinal patch that fixes two nasty issues and improves a third one,
namely:

1. My patch changed the behavior if a glyph is not found in the Unicode
   mapping table. Previously for Unicode values less than 256 or 512 the
   kernel tried to display the glyph from that position of the glyph table,
   which could lead to a different accented letter being displayed. I
   removed this fallback possibility and changed it to display the
   replacement symbol.

   As Behdad pointed out, some fonts (e.g. sun12x22 from the kbd package)
   lack Unicode mapping information, hence all you get is lots of question
   marks. Though theoretically it's actually a user-space bug (the font
   should be fixed), Behdad and I both believe that it'd be good to work
   around in the kernel by re-introducing the fallback solution for ASCII
   characters only. This sounds a quite reasonable decision, since all fonts
   ship the ASCII characters in the first 128 positions. This way users
   won't be surprised by lots of question marks just because s/he issued a
   not-so-perfectly parameterized setfont command. As this fallback is only
   re-introduced for code points below 128, you still won't see an accented
   letter replaced by another, but at least you'll always get the English
   letters right.

2. My patch introduced "question mark with inverted color attributes" as a
   last resort fallback glyph. Though it perfectly works on VGA console, on
   framebuffer you may end up with question marks that are highlighed but
   shouldn't be, and normal characters that are accidentally highlighed.
   This is caused by missing FLUSHes when changing the color attribute.

3. I've updated the table of double-width character based on Markus's
   updated version. Only ten new code poings (one interval) is added.


Please review and commit this patch... I'm afraid it might be too late, but
it would be nice to see it in 2.6.22 -- as this will be the first stable
release that introduces my work, and the first two issues addressed now are
regressions since 2.6.21.

Thanks,

Signed-off-by: Egmont Koblinger <[EMAIL PROTECTED]>

diff -Naur linux-2.6.22-rc5.orig/drivers/char/vt.c 
linux-2.6.22-rc5/drivers/char/vt.c
--- linux-2.6.22-rc5.orig/drivers/char/vt.c 2007-06-17 04:09:12.0 
+0200
+++ linux-2.6.22-rc5/drivers/char/vt.c  2007-06-19 13:49:55.0 +0200
@@ -1956,7 +1956,7 @@
 DEFINE_MUTEX(con_buf_mtx);
 
 /* is_double_width() is based on the wcwidth() implementation by
- * Markus Kuhn -- 2003-05-20 (Unicode 4.0)
+ * Markus Kuhn -- 2007-05-26 (Unicode 5.0)
  * Latest version: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
  */
 struct interval {
@@ -1988,8 +1988,8 @@
static const struct interval double_width[] = {
{ 0x1100, 0x115F }, { 0x2329, 0x232A }, { 0x2E80, 0x303E },
{ 0x3040, 0xA4CF }, { 0xAC00, 0xD7A3 }, { 0xF900, 0xFAFF },
-   { 0xFE30, 0xFE6F }, { 0xFF00, 0xFF60 }, { 0xFFE0, 0xFFE6 },
-   { 0x2, 0x2FFFD }, { 0x3, 0x3FFFD }
+   { 0xFE10, 0xFE19 }, { 0xFE30, 0xFE6F }, { 0xFF00, 0xFF60 },
+   { 0xFFE0, 0xFFE6 }, { 0x2, 0x2FFFD }, { 0x3, 0x3FFFD }
};
return bisearch(ucs, double_width,
sizeof(double_width) / sizeof(*double_width) - 1);
@@ -2187,9 +2187,12 @@
continue; /* nothing to display */
}
/* Glyph not found */
-   if (!(vc->vc_utf && !vc->vc_disp_ctrl) && !(c & 
~charmask)) {
+   if ((!(vc->vc_utf && !vc->vc_disp_ctrl) || c < 
128) && !(c & ~charmask)) {
/* In legacy mode use the glyph we get by a 
1:1 mapping.
-  This would make absolutely no sense with 
Unicode in mind. */
+  This would make absolutely no sense with 
Unicode in mind,
+  but do this for ASCII characters since a 
font may lack
+  Unicode mapping info and we don't want 
to end up with
+  having question marks only. */
tc = c;
} else {
/* Display U+FFFD. If it's not found, 
display an inverse question mark. */
@@ -2213,6 +2216,7 @@
} else {
vc_attr = ((vc->vc_attr) & 0x88) | 
(((vc->vc_attr) & 0x70) >> 4) | (((vc->vc_attr) & 0x07) << 4);
}
+   FLUSH
}
 
while (1) {
@@ -2246,6 +2250,10 @@
if (tc < 0) tc = ' ';
}
 
+   if (in

Re: How do you allocate huge pages.

[Matthias Kaehlcke]

El Tue, Jun 19, 2007 at 05:07:30AM -0700 Shaun Savage ha dit:
 
> I am trying to allocate very large memory within the kernel. I want to
> start by allocating one huge (4M) page and using that as buffer space.

possibly vmalloc() is what you're looking for, if it isn't really a
*page* of 4M, what afaik is impossible with a standard kernel.

vmalloc() allocates virtually contiguous memory, as opposed to
kmalloc() which allocates physically contiguous memory.

-- 
Matthias Kaehlcke
Linux Application Developer
Barcelona

 La libertad es como la mañana. Hay quienes esperan dormidos a que
   llegue, pero hay quienes desvelan y caminan la noche para alcanzarla
(Subcomandante Marcos)
 .''`.
using free software / Debian GNU/Linux | http://debian.org  : :'  :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4  `-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

mount-2.12r-ggk.tar.gz

[Andries.Brouwer]

The present situation of util-linux and mount is not quite clear to me.
On kernel.org under utils/util-linux nothing has happened for over a year,
and there is also an empty utils/util-linux-ng.

Anyway, Dirk Gerrits, René Gabriël and Peter Kooijmans sent me
a patch to add support for shared subtrees to the mount from
util-linux 2.12r, and I put up the result for ftp at
ftp://ftp.win.tue.nl/pub/linux-local/utils/mount/mount-2.12r-ggk.tar.gz

They remark that it feels like a kernel bug that --make-unbindable
is not reset by --make-private and suggest the patch

--- pnode.old   2007-04-17 12:53:11.0 +0200
+++ pnode.c 2007-04-17 13:22:03.0 +0200
@@ -83,6 +83,8 @@
mnt->mnt_master = NULL;
if (type == MS_UNBINDABLE)
mnt->mnt_flags |= MNT_UNBINDABLE;
+   else
+   mnt->mnt_flags &= ~MNT_UNBINDABLE;
}
 }

(with white-space damage - my cut&paste).

Without this patch one needs the detour "--make-shared; --make-private"
in order to reset the "unbindable" flag for a private tree.

Andries



[By the way, this shared subtree stuff is a bit messy,
and impossible to support correctly by mount without help
from the kernel. So far the shared/slave/unbindable status
of mounts is not visible in /proc/mounts or /proc/$$/mountstats.
The above mount makes a feeble attempt to record these flags
in /etc/mtab, but will fail in any nontrivial situation.]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/8] 2.6.22-rc3 perfmon2 : IBS implementation for AMD64

[Stephane Eranian]

Robert,

I applied this patch to my tree.
Thanks.

On Fri, Jun 15, 2007 at 06:57:30PM +0200, Robert Richter wrote:
> This patch implements Barcelona CPU detection.
> 
> Signed-off-by: Robert Richter <[EMAIL PROTECTED]>
> 
> Index: linux-2.6.22-rc3/arch/i386/perfmon/perfmon.c
> ===
> --- linux-2.6.22-rc3.orig/arch/i386/perfmon/perfmon.c
> +++ linux-2.6.22-rc3/arch/i386/perfmon/perfmon.c
> @@ -1059,6 +1059,7 @@ char *pfm_arch_get_pmu_module_name(void)
>   goto try_arch;
>   }
>   case 15:
> + case 16:
>   /* All Opteron processors */
>   if (cpu_data->x86_vendor == X86_VENDOR_AMD)
>   return "perfmon_k8";
> Index: linux-2.6.22-rc3/arch/x86_64/perfmon/perfmon_k8.c
> ===
> --- linux-2.6.22-rc3.orig/arch/x86_64/perfmon/perfmon_k8.c
> +++ linux-2.6.22-rc3/arch/x86_64/perfmon/perfmon_k8.c
> @@ -307,7 +307,12 @@ static int pfm_k8_probe_pmu(void)
>   return -1;
>   }
>  
> - if (current_cpu_data.x86 != 15) {
> + switch (current_cpu_data.x86) {
> + case 15:
> + case 16:
> + PFM_INFO("found family=%d", current_cpu_data.x86);
> + break;
> + default:
>   PFM_INFO("unsupported family=%d", current_cpu_data.x86);
>   return -1;
>   }
> 
> --
> AMD Saxony, Dresden, Germany
> Operating System Research Center
> email: [EMAIL PROTECTED]
> 
> 
> 

-- 

-Stephane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] Linux Kernel Tester’s Guide v0. 3-rc1

[Clemens Koller]

Hello, Michal, Rafael!

Good work!
Some (minor) comments below.

Michal Piotrowski schrieb:

Hi,

We are pleased to announce the availability of "Linux Kernel Tester's 
Guide" v0.3-rc1.


This short guide describes the basics of kernel testing. The handbook is 
divided into six chapters:


1 The kernel, patches, trees and compilation
 1.1 The kernel


I would prefer to use a -rc in the examples and not one of the
stable 2.6.x.y kernels.


 1.2 Patches
 1.3 Ketchup


I would prefer using git in the examples.
There is no such thing as "apt-get" in generic linux.


Any comments, suggestions and patches are welcome.


There is just too less time to test the kernel much in
detail. It would be fine to have the whole book as
./test-my-system-now-but-dont-ask-me.sh ;-)

Good luck,
--
Clemens Koller
__
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2/8] 2.6.22-rc3 perfmon2 : IBS implementation for AMD64

[Stephane Eranian]

Robert,

I applied this patch to my tree.
thanks.

On Fri, Jun 15, 2007 at 06:58:11PM +0200, Robert Richter wrote:
> Debug messages added for better debugging.
> 
> Signed-off-by: Robert Richter <[EMAIL PROTECTED]>
> 
> Index: linux-2.6.22-rc3/perfmon/perfmon_file.c
> ===
> --- linux-2.6.22-rc3.orig/perfmon/perfmon_file.c
> +++ linux-2.6.22-rc3/perfmon/perfmon_file.c
> @@ -192,6 +192,8 @@ static int pfm_mmap(struct file *file, s
>   unsigned long flags;
>   int ret;
>  
> + PFM_DBG("pfm_file_ops");
> +
>   ctx  = file->private_data;
>   size = (vma->vm_end - vma->vm_start);
>  
> @@ -332,6 +334,8 @@ static ssize_t pfm_read(struct file *fil
>   union pfarg_msg msg_buf;
>   int non_block, ret;
>  
> + PFM_DBG("pfm_file_ops");
> +
>   ctx = filp->private_data;
>   if (ctx == NULL) {
>   PFM_ERR("no ctx for pfm_read");
> @@ -375,6 +379,8 @@ static unsigned int pfm_poll(struct file
>   unsigned long flags;
>   unsigned int mask = 0;
>  
> + PFM_DBG("pfm_file_ops");
> +
>   if (filp->f_op != &pfm_file_ops) {
>   PFM_ERR("pfm_poll bad magic");
>   return 0;
> @@ -449,6 +455,8 @@ static int pfm_fasync(int fd, struct fil
>   struct pfm_context *ctx;
>   int ret;
>  
> + PFM_DBG("pfm_file_ops");
> +
>   ctx = filp->private_data;
>   if (ctx == NULL) {
>   PFM_ERR("pfm_fasync no ctx");
> @@ -611,6 +619,8 @@ static int pfm_close(struct inode *inode
>  {
>   struct pfm_context *ctx;
>  
> + PFM_DBG("pfm_file_ops");
> +
>   ctx = filp->private_data;
>   if (ctx == NULL) {
>   PFM_ERR("no ctx");
> @@ -621,6 +631,8 @@ static int pfm_close(struct inode *inode
>  
>  static int pfm_no_open(struct inode *irrelevant, struct file *dontcare)
>  {
> + PFM_DBG("pfm_file_ops");
> +
>   return -ENXIO;
>  }
>  
> @@ -637,6 +649,8 @@ static int pfm_flush(struct file *filp, 
>  {
>   struct pfm_context *ctx;
>  
> + PFM_DBG("pfm_file_ops");
> +
>   ctx = filp->private_data;
>   if (ctx == NULL) {
>   PFM_ERR("pfm_flush no ctx");
> Index: linux-2.6.22-rc3/perfmon/perfmon_syscalls.c
> ===
> --- linux-2.6.22-rc3.orig/perfmon/perfmon_syscalls.c
> +++ linux-2.6.22-rc3/perfmon/perfmon_syscalls.c
> @@ -403,6 +403,8 @@ asmlinkage long sys_pfm_create_context(s
>   void *fmt_arg = NULL;
>   int ret;
>  
> + PFM_DBG("syscall");
> +
>   if (atomic_read(&perfmon_disabled))
>   return -ENOSYS;
>  
> @@ -433,8 +435,12 @@ asmlinkage long sys_pfm_write_pmcs(int f
>   size_t sz;
>   int ret, fput_needed;
>  
> - if (count < 0 || count >= PFM_MAX_ARG_COUNT(ureq))
> + PFM_DBG("syscall");
> +
> + if (count < 0 || count >= PFM_MAX_ARG_COUNT(ureq)) {
> +PFM_DBG("invalid arg count %d", count);
>   return -EINVAL;
> + }
>  
>   sz = count*sizeof(*ureq);
>  
> @@ -475,6 +481,8 @@ asmlinkage long sys_pfm_write_pmcs(int f
>   kfree(fptr);
>  error:
>   fput_light(filp, fput_needed);
> + if (ret)
> + PFM_DBG("failed: errno=%d", -ret);
>  
>   return ret;
>  }
> @@ -490,6 +498,8 @@ asmlinkage long sys_pfm_write_pmds(int f
>   size_t sz;
>   int ret, fput_needed;
>  
> + PFM_DBG("syscall");
> +
>   if (count < 0 || count >= PFM_MAX_ARG_COUNT(ureq))
>   return -EINVAL;
>  
> @@ -543,6 +553,8 @@ asmlinkage long sys_pfm_read_pmds(int fd
>   size_t sz;
>   int ret, fput_needed;
>  
> + PFM_DBG("syscall");
> +
>   if (count < 0 || count >= PFM_MAX_ARG_COUNT(ureq))
>   return -EINVAL;
>  
> @@ -591,6 +603,8 @@ asmlinkage long sys_pfm_restart(int fd)
>   unsigned long flags;
>   int ret, fput_needed, complete_needed;
>  
> + PFM_DBG("syscall");
> +
>   filp = fget_light(fd, &fput_needed);
>   if (unlikely(filp == NULL)) {
>   PFM_DBG("invalid fd %d", fd);
> @@ -647,6 +661,8 @@ asmlinkage long sys_pfm_stop(int fd)
>   unsigned long flags;
>   int ret, fput_needed;
>  
> + PFM_DBG("syscall");
> +
>   filp = fget_light(fd, &fput_needed);
>   if (unlikely(filp == NULL)) {
>   PFM_DBG("invalid fd %d", fd);
> @@ -682,6 +698,8 @@ asmlinkage long sys_pfm_start(int fd, st
>   unsigned long flags;
>   int ret, fput_needed;
>  
> + PFM_DBG("syscall");
> +
>   filp = fget_light(fd, &fput_needed);
>   if (unlikely(filp == NULL)) {
>   PFM_DBG("invalid fd %d", fd);
> @@ -724,6 +742,8 @@ asmlinkage long sys_pfm_load_context(int
>   struct pfarg_load req;
>   int ret, fput_needed;
>  
> + PFM_DBG("syscall");
> +
>   if (copy_from_user(&req, ureq, sizeof(req)))
>   return -EFAULT;
>  
> @@ -792,6 +812,8 @@ asmlinkage long sys_pfm_unload_context(i
>   int is_system, can_release = 0

Re: [patch 3/8] 2.6.22-rc3 perfmon2 : IBS implementation for AMD64

[Stephane Eranian]

Robert,

Patch applied.
Thanks.

On Fri, Jun 15, 2007 at 06:58:49PM +0200, Robert Richter wrote:
> Minor changes (whitespace, comments, ...)
> 
> Signed-off-by: Robert Richter <[EMAIL PROTECTED]>
> 
> Index: linux-2.6.22-rc3/arch/x86_64/perfmon/perfmon_k8.c
> ===
> --- linux-2.6.22-rc3.orig/arch/x86_64/perfmon/perfmon_k8.c
> +++ linux-2.6.22-rc3/arch/x86_64/perfmon/perfmon_k8.c
> @@ -32,23 +32,29 @@ static int force_nmi;
>  MODULE_PARM_DESC(force_nmi, "bool: force use of NMI for PMU interrupt");
>  module_param(force_nmi, bool, 0600);
>  
> -static struct pfm_arch_pmu_info pfm_k8_pmu_info={
> +static struct pfm_arch_pmu_info pfm_k8_pmu_info = {
>   .pmc_addrs = {
> - {{MSR_K7_EVNTSEL0, 0}, 0, PFM_REGT_EN},
> - {{MSR_K7_EVNTSEL1, 0}, 1, PFM_REGT_EN},
> - {{MSR_K7_EVNTSEL2, 0}, 2, PFM_REGT_EN},
> - {{MSR_K7_EVNTSEL3, 0}, 3, PFM_REGT_EN},
> +/* pmc0  */  {{MSR_K7_EVNTSEL0, 0}, 0, PFM_REGT_EN},
> +/* pmc1  */  {{MSR_K7_EVNTSEL1, 0}, 1, PFM_REGT_EN},
> +/* pmc2  */  {{MSR_K7_EVNTSEL2, 0}, 2, PFM_REGT_EN},
> +/* pmc3  */  {{MSR_K7_EVNTSEL3, 0}, 3, PFM_REGT_EN},
>   },
>   .pmd_addrs = {
> - {{MSR_K7_PERFCTR0, 0}, 0, PFM_REGT_CTR},
> - {{MSR_K7_PERFCTR1, 0}, 0, PFM_REGT_CTR},
> - {{MSR_K7_PERFCTR2, 0}, 0, PFM_REGT_CTR},
> - {{MSR_K7_PERFCTR3, 0}, 0, PFM_REGT_CTR},
> +/* pmd0  */  {{MSR_K7_PERFCTR0, 0}, 0, PFM_REGT_CTR},
> +/* pmd1  */  {{MSR_K7_PERFCTR1, 0}, 0, PFM_REGT_CTR},
> +/* pmd2  */  {{MSR_K7_PERFCTR2, 0}, 0, PFM_REGT_CTR},
> +/* pmd3  */  {{MSR_K7_PERFCTR3, 0}, 0, PFM_REGT_CTR},
>   },
>   .pmu_style = PFM_X86_PMU_P6
>  };
>  
>  /*
> + * force Local APIC interrupt on overflow
> + */
> +#define PFM_K8_VAL   (1ULL<<20)
> +#define PFM_K8_NO64  (1ULL<<20)
> +
> +/*
>   * reserved bits must be zero
>   *
>   * - upper 32 bits are reserved
> @@ -59,12 +65,6 @@ static struct pfm_arch_pmu_info pfm_k8_p
>   | (1ULL<<20)\
>   | (1ULL<<21))
>  
> -/*
> - * force Local APIC interrupt on overflow
> - */
> -#define PFM_K8_VAL   (1ULL<<20)
> -#define PFM_K8_NO64  (1ULL<<20)
> -
>  static struct pfm_reg_desc pfm_k8_pmc_desc[]={
>  /* pmc0  */ PMC_D(PFM_REG_I64, "PERFSEL0", PFM_K8_VAL, PFM_K8_RSVD, 
> PFM_K8_NO64, MSR_K7_EVNTSEL0),
>  /* pmc1  */ PMC_D(PFM_REG_I64, "PERFSEL1", PFM_K8_VAL, PFM_K8_RSVD, 
> PFM_K8_NO64, MSR_K7_EVNTSEL1),
> @@ -73,11 +73,11 @@ static struct pfm_reg_desc pfm_k8_pmc_de
>  };
>  #define PFM_AMD_NUM_PMCS ARRAY_SIZE(pfm_k8_pmc_desc)
>  
> -static struct pfm_reg_desc pfm_k8_pmd_desc[]={
> -/* pmd0  */ PMD_D(PFM_REG_C, "PERFCTR0", MSR_K7_PERFCTR0),
> -/* pmd1  */ PMD_D(PFM_REG_C, "PERFCTR1", MSR_K7_PERFCTR1),
> -/* pmd2  */ PMD_D(PFM_REG_C, "PERFCTR2", MSR_K7_PERFCTR2),
> -/* pmd3  */ PMD_D(PFM_REG_C, "PERFCTR3", MSR_K7_PERFCTR3),
> +static struct pfm_reg_desc pfm_k8_pmd_desc[] = {
> +/* pmd0  */ PMD_D(PFM_REG_C,   "PERFCTR0",   MSR_K7_PERFCTR0),
> +/* pmd1  */ PMD_D(PFM_REG_C,   "PERFCTR1",   MSR_K7_PERFCTR1),
> +/* pmd2  */ PMD_D(PFM_REG_C,   "PERFCTR2",   MSR_K7_PERFCTR2),
> +/* pmd3  */ PMD_D(PFM_REG_C,   "PERFCTR3",   MSR_K7_PERFCTR3),
>  };
>  #define PFM_AMD_NUM_PMDS ARRAY_SIZE(pfm_k8_pmd_desc)
>  
> Index: linux-2.6.22-rc3/include/asm-i386/perfmon.h
> ===
> --- linux-2.6.22-rc3.orig/include/asm-i386/perfmon.h
> +++ linux-2.6.22-rc3/include/asm-i386/perfmon.h
> @@ -50,14 +50,14 @@
>  /*
>   * bitmask for reg_type
>   */
> -#define PFM_REGT_NA   0x00 /* not available */
> -#define PFM_REGT_EN   0x01 /* has enable bit (cleared on ctxsw) */
> -#define PFM_REGT_ESCR0x02 /* P4: ESCR */
> -#define PFM_REGT_CCCR0x04 /* P4: CCCR */
> -#define PFM_REGT_OTH  0x80 /* other type of register */
> -#define PFM_REGT_PEBS 0x10 /* PEBS related */
> -#define PFM_REGT_NOHT0x20 /* unavailable with HT */
> -#define PFM_REGT_CTR 0x40 /* counter */
> +#define PFM_REGT_NA  0x  /* not available */
> +#define PFM_REGT_EN  0x0001  /* has enable bit (cleared on ctxsw) */
> +#define PFM_REGT_ESCR0x0002  /* P4: ESCR */
> +#define PFM_REGT_CCCR0x0004  /* P4: CCCR */
> +#define PFM_REGT_PEBS0x0010  /* PEBS related */
> +#define PFM_REGT_NOHT0x0020  /* unavailable with HT */
> +#define PFM_REGT_CTR 0x0040  /* counter */
> +#define PFM_REGT_OTH 0x0080  /* other type of register */
>  
>  /*
>   * This design and the partitioning of resources for SMT (hyper threads)
> Index: linux-2.6.22-rc3/include/linux/perfmon_pmu.h
> ===
> --- linux-2.6.22-rc3.orig/include/linux/perfmon_pmu.h
> +++ linux-2.6.22-rc3/include/linux/perfmon_pmu.h
> @@ -69,7 +69,7 @@ struct pfm_reg_desc {
>  #define PFM_REG_C64  0x04  /* PMD: 64-bit virtualization */
>  #define PFM_RE

Re: This is [Re:] How to improve the quality of the kernel[?].

[Adrian Bunk]

On Tue, Jun 19, 2007 at 06:06:47AM +0200, Oleg Verych wrote:
> [Dear Debbug developers, i wish your ideas will be useful.]
> 
> * From: Linus Torvalds
> * Newsgroups: gmane.linux.kernel
> * Date: Mon, 18 Jun 2007 17:09:37 -0700 (PDT)
> >
> > On Mon, 18 Jun 2007, Martin Bligh wrote:
> >> 
> >> Sorry to be a wet blanket, but I've seen those sort of things
> >> before, and they just don't seem to work, especially in the
> >> environment we're in with such a massive diversity of hardware.
> >
> > I do agree. It _sounds_ like a great idea to try to control the flow of 
> > patches better,
> 
> There were some ideas, i will try to summarize:
> 
> * New Patches (or sets) need tracking, review, testing
> 
>   Zero (tracking) done by sending (To, or bcc) [RFC] patch to something
>   like [EMAIL PROTECTED] (like BTS now). Notifications will
>   be sent to intrested maintainers (if meta-information is ok) or testers
>   (see below)
> 
>   First is mostly done by maintainers or interested individuals.
>   Result is "Acked-by" and "Cc" entries in the next patch sent. Due to
>   lack of tracking this things are done manually, are generally in
>   trusted manner. But bad like <[EMAIL PROTECTED]>
>   sometimes happens.

The goal is to get all patches for a maintained subsystem submitted to 
Linus by the maintainer.

>   When patch in sent to this PTS, your lovely
>   checkpatch/check-whatever-crap-has-being-sent tools can be set up as
>   gatekeepers, thus making impossible stupid errors with MIME coding,
>   line wrapping, whatever style you've came up with now in checking
>   sent crap.

The -mm kernel already implements what your proposed PTS would do.

Plus it gives testers more or less all patches currently pending 
inclusion into Linus' tree in one kernel they can test.

The problem are more social problems like patches Andrew has never heard 
of before getting into Linus' tree during the merge window.

>...
> |-*- Feature Needed -*-
>   Addition, needed is hardware user tested have/had/used. Currently
>   ``reportbug'' tool includes packed specific and system specific
>   additions automaticly gathered and inserted to e-mail sent to BTS.
>   (e.g. )

The problem is that most problems don't occur on one well-defined 
kind of hardware - patches often break in exactly the areas the patch
author expected no problems in.

And in many cases a patch for a device driver was written due to a bug 
report - in such cases a tester with the hardware in question is already 
available.

>...
> > but in the end, it needs to also be easy and painfree to the people
> > involved, and also make sure that any added workflow doesn't require
> > even *more* load and expertise on the already often overworked 
> > maintainers..
> 
> Experienced BTS users and developers. Please, correct me if i'm wrong.
> At least e-mail part of Debian's BTS and whole idea of it is *exactly*
> what is needed. Bugzilla fans, you can still use you useless pet,
> because Debian developers have done things, to track and e-mail states
> of bugs: 
>...

"useless pet"?
Be serious.
How many open source projects use Bugzilla and how many use the Debian BTS?
And then start thinking about why the "useless pet" has so many more 
user...

The Debian BTS requires you to either write emails with control messages 
or generating control messages with external tools.

In Bugzilla the same works through a web interface.

I know both the Debian BTS and Bugzilla and although they are quite 
different they both are reasonable tools for their purpose.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 4/6] ps3: Disk Storage Driver

[Geert Uytterhoeven]

On Tue, 19 Jun 2007, Christoph Hellwig wrote:
> On Fri, Jun 15, 2007 at 01:39:23PM +0200, Geert Uytterhoeven wrote:
> > From: Geert Uytterhoeven <[EMAIL PROTECTED]>
> > 
> > Add a Disk Storage Driver for the PS3:
> >   - Implemented as a block device driver with a dynamic major
> >   - Disk names (and partitions) are of the format ps3d%c(%u)
> >   - Uses software scatter-gather with a 64 KiB bounce buffer as the 
> > hypervisor
> > doesn't support scatter-gather
> 
> Looks good to me.  Only nitpicks are:
> 
>  - ps3disk_priv should probably be an inline function instead of a macro

I used a macro because you can do

ps3disk_pri(dev) = ...;

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:+32 (0)2 700 8453 
Fax:  +32 (0)2 700 8622 
E-mail:   [EMAIL PROTECTED] 
Internet: http://www.sony-europe.com/

Sony Network and Software Technology Center Europe  
A division of Sony Service Centre (Europe) N.V. 
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium  
VAT BE 0413.825.160 · RPR Brussels  
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

Re: [PATCH 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.

[Thomas Renninger]

On Sun, 2007-06-17 at 19:49 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 17 Jun 2007, Thomas Renninger wrote:
> > Create __mod_acpi_device_table symbol for all acpi drivers.
> 
> thinkpad-acpi will autoload by DMI ids in 2.6.23, which is a much better
> solution for model-specific drivers like thinkpad-acpi than autoloading by
> HID, IMHO.
Yes, I saw some dmi udev strings on Kay's machine and for the thinkpad
module dmi autoloading is much better.
> model-specific drivers like thinkpad-acpi
Not in general, only if the driver provides additional functions and the
ACPI device does not appear on machines that need those additional
functions.
E.g. the asus driver AFAIK serves exactly the ACPI device it registers
for.

> Thus, I'd prefer if your patches did not make thinkpad-acpi autoload by HID.
It would not really hurt? At least thinkpad module is an acpi driver for
those two HIDs... But your are right, it's superfluous, here with
__mod_acpi_device_table symbol ripped out of thinkpad.ko.
Hmm, what do you think about splitting the Thinkpad driver into Hotkey,
PCI and rest? This one got a complicated beast...


Create __mod_acpi_device_table symbol for all acpi drivers.

modpost is going to use this one to create modules.alias

Hopefully thinkpad module still works.
IMO this one should get restructured and make use of acpi_bus_register_driver
and try to avoid to test for HIDs/CIDs for its own.

Signed-off-by: Thomas Renninger <[EMAIL PROTECTED]>

---
 drivers/acpi/ac.c   |9 +++--
 drivers/acpi/acpi_memhotplug.c  |8 +++-
 drivers/acpi/asus_acpi.c|   11 ---
 drivers/acpi/battery.c  |9 +++--
 drivers/acpi/button.c   |   10 +-
 drivers/acpi/container.c|   10 +-
 drivers/acpi/ec.c   |   15 +--
 drivers/acpi/fan.c  |8 +++-
 drivers/acpi/pci_link.c |9 +++--
 drivers/acpi/pci_root.c |9 +++--
 drivers/acpi/power.c|8 +++-
 drivers/acpi/processor_core.c   |8 +++-
 drivers/acpi/sbs.c  |9 +++--
 drivers/acpi/thermal.c  |8 +++-
 drivers/acpi/video.c|8 +++-
 drivers/char/hpet.c |8 +++-
 drivers/input/misc/atlas_btns.c |9 +++--
 drivers/misc/asus-laptop.c  |9 +++--
 drivers/misc/sony-laptop.c  |   21 +++--
 drivers/misc/thinkpad_acpi.c|   24 
 drivers/misc/thinkpad_acpi.h|2 +-
 21 files changed, 177 insertions(+), 35 deletions(-)

Index: linux-2.6.22-rc5/drivers/acpi/button.c
===
--- linux-2.6.22-rc5.orig/drivers/acpi/button.c
+++ linux-2.6.22-rc5/drivers/acpi/button.c
@@ -66,6 +66,14 @@ MODULE_AUTHOR("Paul Diefenbaugh");
 MODULE_DESCRIPTION("ACPI Button Driver");
 MODULE_LICENSE("GPL");
 
+static const struct acpi_device_id button_device_ids[] = {
+   {ACPI_BUTTON_HID_LID, 0},
+   {ACPI_BUTTON_HID_SLEEP, 0},
+   {ACPI_BUTTON_HID_POWER, 0},
+   {"", 0},
+};
+MODULE_DEVICE_TABLE(acpi, button_device_ids);
+
 static int acpi_button_add(struct acpi_device *device);
 static int acpi_button_remove(struct acpi_device *device, int type);
 static int acpi_button_info_open_fs(struct inode *inode, struct file *file);
@@ -74,7 +82,7 @@ static int acpi_button_state_open_fs(str
 static struct acpi_driver acpi_button_driver = {
.name = "button",
.class = ACPI_BUTTON_CLASS,
-   .ids = "button_power,button_sleep,PNP0C0D,PNP0C0C,PNP0C0E",
+   .ids = button_device_ids,
.ops = {
.add = acpi_button_add,
.remove = acpi_button_remove,
Index: linux-2.6.22-rc5/drivers/acpi/asus_acpi.c
===
--- linux-2.6.22-rc5.orig/drivers/acpi/asus_acpi.c
+++ linux-2.6.22-rc5/drivers/acpi/asus_acpi.c
@@ -56,7 +56,6 @@
 #define ACPI_HOTK_NAME  "Asus Laptop ACPI Extras Driver"
 #define ACPI_HOTK_CLASS "hotkey"
 #define ACPI_HOTK_DEVICE_NAME   "Hotkey"
-#define ACPI_HOTK_HID   "ATK0100"
 
 /*
  * Some events we use, same for all Asus
@@ -426,14 +425,20 @@ static struct acpi_table_header *asus_in
 static struct asus_hotk *hotk;
 
 /*
- * The hotkey driver declaration
+ * The hotkey driver and autoloading declaration
  */
 static int asus_hotk_add(struct acpi_device *device);
 static int asus_hotk_remove(struct acpi_device *device, int type);
+static const struct acpi_device_id asus_device_ids[] = {
+   {"ATK0100", 0},
+   {"", 0},
+};
+MODULE_DEVICE_TABLE(acpi, asus_device_ids);
+
 static struct acpi_driver asus_hotk_driver = {
.name = "asus_acpi",
.class = ACPI_HOTK_CLASS,
-   .ids = ACPI_HOTK_HID,
+   .ids = asus_device_ids,
.ops = {
.add = asus_hotk_add,
.remove = asus_hotk_remove,
Index: linux-2.6.22-rc5/drivers/acpi/fan.

Re: [PATCH 5/7] Introduce a means of compacting memory within a zone

[Yasunori Goto]

Hi Mel-san.
This is very interesting feature.

Now, I'm testing your patches.

> +static int isolate_migratepages(struct zone *zone,
> + struct compact_control *cc)
> +{
> + unsigned long high_pfn, low_pfn, end_pfn, start_pfn;

(snip)

> + /* Time to isolate some pages for migration */
> + spin_lock_irq(&zone->lru_lock);
> + for (; low_pfn < end_pfn; low_pfn++) {
> + if (!pfn_valid_within(low_pfn))
> + continue;
> +
> + /* Get the page and skip if free */
> + page = pfn_to_page(low_pfn);

I met panic at here on my tiger4.

I compiled with CONFIG_SPARSEMEM. So, CONFIG_HOLES_IN_ZONE is not set.
pfn_valid_within() returns 1 every time on this configuration.
(This config is for only virtual memmap)
But, my tiger4 box has memory holes in normal zone.

When it is changed to normal pfn_valid(), no panic occurs.

Hmmm.

Bye.
-- 
Yasunori Goto 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/