RE: Binary Drivers

[David Schwartz]

> Two of the specific arguments I've heard are (a) that the board (and
> its hardware interfaces that the documentation would describe) involve
> IP licensed from a third party, which the board manufacturer does not
> have a legal right to disclose,

If they can't disclose it, they can't sell it. If they can't sell it, it's
fraud to tell someone that they can buy it. If a contract with a third party
limits your ability to sell something to someone, you have to *tell* *them*
that they do not get all of the rights of ownership because you don't own
some of them and hence can't transfer them.

If I can't tell you what you're buying, I can't sell it to you. It's really
that simple. I might be able to make some kind of agreement with you that's
something like a sale, but it is not a normal sale and you are not buying
the expected type of ownership. To claim it's a sale is fraud.

> or (b) that there is, in fact, no
> suitable documentation, because the boards are developed somewhat
> fluidly and the driver is developed directly from low-level knowledge
> that simply isn't written down in a form suitable for passing on.

You can't sell something that doesn't exist. If you sell a car even though
you can't explain how anyone could drive it, that's fraud. A person who buys
something is entitled to be told how to operate it and make it work (and not
just the one way you think they should use it, they have the right to use it
any way they want if the transaction is a normal sale including all rights).
If you can't tell them that, then they are not actually buying all of the
thing.

> If you're building products with no expectation of supporting outside
> driver developers, both of those are quite possible.

And they're both quite fraudulent. You cannot both sell something and keep
its construction a secret. A person who owns something has a right to be
told what they're buying. If you are only selling some of the rights that
normally come with buying something, you cannot claim you are selling it
free and clear.

As I said before, this same thing used to happen with cell phones. I bought
a Primeco phone, fully believing that I fully owned it. However, Primeco
refused to tell me the code to unlock the phone, demanding $200 to do so.
That's simply fraud -- if I fully own the phone, free and clear, they have
no right to sell access to it to me. You can't sell the car and then charge
for the keys.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] MAINTAINERS - email addr change for Eric Moore

[Eric Moore]

Update to maintainers list.
My employer has changed the domain from lsil to lsi.

Eric

diff -uarpN b/MAINTAINERS a/MAINTAINERS
--- b/MAINTAINERS   2006-12-13 18:14:23.0 -0700
+++ a/MAINTAINERS   2006-12-22 23:00:21.0 -0700
@@ -1919,9 +1919,9 @@ S:Maintained
 
 LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
 P: Eric Moore
-M: [EMAIL PROTECTED]
-M: [EMAIL PROTECTED]
-L: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
 L: linux-scsi@vger.kernel.org
 W: http://www.lsilogic.com/support
 S: Supported
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Section mismatch on current git head

[Len Brown]

> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:acpi_sci_flags from .text between 'acpi_sci_ioapic_setup' (at 
> offset 0xc010e020) and 'acpi_unmap_lsapic'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:acpi_sci_flags from .text between 'acpi_sci_ioapic_setup' (at 
> offset 0xc010e04a) and 'acpi_unmap_lsapic'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.text:mp_override_legacy_irq from .text between 
> 'acpi_sci_ioapic_setup' (at offset 0xc010e062) and 'acpi_unmap_lsapic'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:acpi_sci_override_gsi from .text between 
> 'acpi_sci_ioapic_setup' (at offset 0xc010e068) and 'acpi_unmap_lsapic'

The acpi_sci_ioapic_setup ones should go away with the patch below, but do no 
harm in the mean-time.
cheers,
-Len

commit 0351a612f7a46995c28d4ef6189229b5d1dfc6c3
Author: Len Brown <[EMAIL PROTECTED]>
Date:   Thu Dec 21 01:29:59 2006 -0500

ACPI: fix section mis-match build warning

Dunno why this pops out in only in the allmodconfig build.
Though the warning is accurate, all the callers of the flagged
non __init function are __init, this is not a functional change.

WARNING: vmlinux - Section mismatch: reference to .init.data:acpi_sci_flags 
from .text between 'acpi_sci_ioapic_setup' (at offset 0xc010f0a
6) and 'acpi_gsi_to_irq'
   WARNING: vmlinux 
- Section mismatch: reference to .init.text:mp_override_legacy_irq from .text 
between 'acpi_sci_ioapic_setup' (at offset 0
xc010f0de) and 'acpi_gsi_to_irq'
   WARNING: vmlinux 
- Section mismatch: reference to .init.data:acpi_sci_override_gsi from .text 
between 'acpi_sci_ioapic_setup' (at offset 0x
c010f0e4) and 'acpi_gsi_to_irq'

Signed-off-by: Len Brown <[EMAIL PROTECTED]>

diff --git a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c
index c8f96cf..45cffbf 100644
--- a/arch/i386/kernel/acpi/boot.c
+++ b/arch/i386/kernel/acpi/boot.c
@@ -333,7 +333,7 @@ acpi_parse_ioapic(acpi_table_entry_header * header, const 
unsigned long end)
 /*
  * Parse Interrupt Source Override for the ACPI SCI
  */
-static void acpi_sci_ioapic_setup(u32 gsi, u16 polarity, u16 trigger)
+static void __init acpi_sci_ioapic_setup(u32 gsi, u16 polarity, u16 trigger)
 {
if (trigger == 0)   /* compatible SCI trigger is level */
trigger = 3;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] delayed allocation for ext4

[David Chinner]

On Fri, Dec 22, 2006 at 11:20:08PM +0300, Alex Tomas wrote:
> 
> Good day,
> 
> probably the previous set of patches (including mballoc/lg)
> is too large. so, I reworked delayed allocation a bit so
> that it can be used on top of regular balloc, though it
> still can be used with extents-enabled files only.
> 
> this time series contains just 3 patches:
> 
>  - booked-page-flag.patch
>adds PG_booked bit to page->flags. it's used in delayed
>allocation to mark space is already reserved for page
>(including possible metadata)

So that mean's we'll have 2 separate mechanisms for marking
pages as delalloc. XFS uses the BH_delay flag to indicate
that a buffer (block) attached to the page is using delalloc.

FWIW, how does this mechanism deal with block size < page size?
Don't you have to track delalloc on a block basis rather than
a page basis?

>  - ext4-block-reservation.patch
>this is scalable free space management. every time we
>delay allocation of some page, a space (including metadata)
>should be reserved
> 
>  - ext4-delayed-allocation.patch
>delayed allocation itself, enabled by "delalloc" mount option.
>extents support is also required. currently it works only
>with blocksize=pagesize.

Ah, that's why you can get away with a page flag - you've ignored
the partial page delay state problem. Any plans to use the
existing method in the future so we will be able to use ext4 delalloc
on machines with a page size larger than 4k?

Cheers,

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

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

[Christoph Anton Mitterer]

John A Chaves wrote:
> I didn't need to run a specific test for this.  The normal workload of the
> machine approximates a continuous selftest for almost the last year.
>
> Large files (4-12GB is typical) are being continuously packed and unpacked
> with gzip and bzip2.  Statistical analysis of the datasets is followed by
> verification of the data, sometimes using diff, or md5sum, or python
> scripts using numarray to mmap 2GB chunks at a time.  The machine
> often goes for days with a load level of 20+ and 32GB RAM + another 32GB
> swap in use.  It would be very unlikely for data corruption to go unnoticed.
>
> When I first got the machine I did have some problems with disks being
> dropped from the RAID and occasional log messages implicating the IOMMU.
> But that was with kernel 2.6.16.?, Kernels since 2.6.17 haven't had any
> problem.
>   
Ah thanks for that info,.. as far as I can tell,.. this "testing
environment" should have found any corruptions I there had been any.

So I think we could take this as our first working system where the
issue don't occur although we would expect it...

Chris.
begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
email;internet:[EMAIL PROTECTED]
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems

[Nikolai Joukov]

> > 3. A known ideal solution for this problem is sharing of the cached pages
> >between file systems.  We attempted to do it for Tracefs but the
> >resulting code is not beautiful and is potentially racy:
> >
> >Unfortunately, for fan-out file systems this solution requires even
> >more support from the OS.  However, this is what most OSs do
> >(including BSD and Windows) but unfortunately not Linux :-(
>
> VFS-hooks seem to be the cleanest solution not only for a stacked-fs, but
> also for many other situations.  It's rather sad that linux hasn't seen the
> light yet.

Jeff Sipek just got his proposal for a paper/discussion topic accepted to
the Linux Storage and Filesystems workshop, co-located with FAST.  The
topic for discussion will be what "surgery" the Linux kernel needs to
support stackable file systems properly.  I hope it is an indicator that
the situation with support of the stackable file systems in Linux may
improve soon.

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

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

[John A Chaves]

On Friday 22 December 2006 20:04, Christoph Anton Mitterer wrote:
> This brings me to:
> Chris Wedgwood wrote:
> > Does anyone have an amd64 with an nforce4 chipset and >4GB that does
> > NOT have this problem? If so it might be worth chasing the BIOS
> > vendors to see what errata they are dealing with.
> John Chaves replied and claimed that he wouldn't suffer from that
> problem (I've CC'ed him to this post).
> You can read his message at the bottom of this post.
> @ John: Could you please tell us in detail how you've tested your system?

I didn't need to run a specific test for this.  The normal workload of the
machine approximates a continuous selftest for almost the last year.

Large files (4-12GB is typical) are being continuously packed and unpacked
with gzip and bzip2.  Statistical analysis of the datasets is followed by
verification of the data, sometimes using diff, or md5sum, or python
scripts using numarray to mmap 2GB chunks at a time.  The machine
often goes for days with a load level of 20+ and 32GB RAM + another 32GB
swap in use.  It would be very unlikely for data corruption to go unnoticed.

When I first got the machine I did have some problems with disks being
dropped from the RAID and occasional log messages implicating the IOMMU.
But that was with kernel 2.6.16.?, Kernels since 2.6.17 haven't had any
problem.

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

Re: 2.6.19-rt14 slowdown compared to 2.6.19

[K.R. Foley]

Chen, Tim C wrote:
> Ingo,
>  
> We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19 
> kernel and noticed several slowdowns.  The test machine is a 2 socket
> woodcrest machine with your default configuration.
>  
> Netperf TCP Streaming was slower by 40% ( 1 server and 1 client 
> each bound to separate cpu cores on different socket, network
> loopback mode was used).  
> 
> Volanomark was slower by 80% (Server and Clients communicate with 
> network loopback mode. Idle time goes from 1% to 60%)
> 
> Re-Aim7 was slower by 40% (idle time goes from 0% to 20%)
> 
> Wonder if you have any suggestions on what could cause the slowdown.  
> We've tried disabling CONFIG_NO_HZ and it didn't help much.
>
> Thanks.
> 
> Tim

Take a look at this. Not sure if this is the same problem but it looks
like a candidate. I can definitely say that some latencies I have seen
in my recent testing have gone away in the last few versions
2.6.20-rc1-rt{3,4}.

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

Re: 2.6.19-rt14 slowdown compared to 2.6.19

[K.R. Foley]

Chen, Tim C wrote:
> Ingo,
>  
> We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19 
> kernel and noticed several slowdowns.  The test machine is a 2 socket
> woodcrest machine with your default configuration.
>  
> Netperf TCP Streaming was slower by 40% ( 1 server and 1 client 
> each bound to separate cpu cores on different socket, network
> loopback mode was used).  
> 
> Volanomark was slower by 80% (Server and Clients communicate with 
> network loopback mode. Idle time goes from 1% to 60%)
> 
> Re-Aim7 was slower by 40% (idle time goes from 0% to 20%)
> 
> Wonder if you have any suggestions on what could cause the slowdown.  
> We've tried disabling CONFIG_NO_HZ and it didn't help much.
>
> Thanks.
> 
> Tim

Take a look at this. Not sure if this is the same problem but it looks
like a candidate. I can definitely say that some latencies I have seen
in my recent testing have gone away in the last few versions
2.6.20-rc1-rt{3,4}.

Sorry I missed the URL first time around.
http://marc.theaimsgroup.com/?l=linux-kernel=116670388527349=2

-- 
kr

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

Re: [GIT PATCH] ACPI patches for 2.6.20-rc1

[Len Brown]

On Thursday 21 December 2006 02:58, Linus Torvalds wrote:
> 
> On Wed, 20 Dec 2006, Len Brown wrote:
> > 
> > please pull from: 
> 
> Is this really all obvious bug-fixes? There seems to be a lot of 
> development there that simply isn't appropriate after an -rc1 any more.
> 
> I want 2.6.20 to be stable, and one of the things I'm doing is to be 
> strict about the merge window.

Yes, I recommend pulling this tree now.
While there is a fair amount of text changed, the functional changes
here are actually quite small, and have been in -mm for a long time --
some of them already shipping in distros before being upstream.

Yes, there is a fair amount of fluffy cleanup here -- seems there is
never a good time in the release cycle to do them, but as andrew says,
we're in this for the long term, so we do have to do them some time.
I don't see any big risks in them so it seems appropriate to push after rc1.

Note that there is a much larger body of ACPI changes in flight
that I have excluded from this pull request and are waiting for 2.6.21.

thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Fix kmalloc flags used in ext3 with an active journal handle

[Suzuki]

Jan Kara wrote:

On Tue, 19 Dec 2006 18:22:03 -0800
Suzuki <[EMAIL PROTECTED]> wrote:



Andrew Morton wrote:


On Tue, 19 Dec 2006 17:58:12 -0800
Suzuki <[EMAIL PROTECTED]> wrote:




* Fix the kmalloc flags used from within ext3, when we have an active journal 
handle

If we do a kmalloc with GFP_KERNEL on system running low on memory, 
with an active journal handle, we might end up in cleaning up the fs cache 
flushing dirty inodes for some other filesystem. This would cause hitting a 
J_ASSERT() in :



The change might be needed (haven't looked at it yet).  But I'd like to see
the full BUG trace, please.  To see the callchain.


Here is the call trace which was hit by one of our test teams. This was
from fs/ext3/xattr.c. While looking for similar calls I found the others
described in the patch.

Assertion failure in journal_start() at fs/jbd/transaction.c:274: "handle-
>h_transaction->t_journal == journal"
kernel BUG at fs/jbd/transaction.c:274!
illegal operation: 0001 [#1]
CPU:0Not tainted (2.6.5-7.282-s390x SLES9_SP3_BRANCH-20061031152356)
Process dbench (pid: 14070, task: 025617f0, ksp: 01057630)
Krnl PSW : 07018000 08837b38 (journal_start+0x90/0x15c
[jbd])
Krnl GPRS:  00507fc0 002b
01056d80
   08837b36 2885 08841da6

   001bfaa0 03483d08 0002
07a8bda0
   08833000 088a7d08 08837b36
01056e80
Krnl Code: 00 00 58 10 b0 0c a7 1a 00 01 b9 04 00 2b 50 10 b0 0c e3 40
Call Trace:
 [<088a30fc>] ext3_journal_start+0x8c/0xa4 [ext3]
 [<08896822>] ext3_dirty_inode+0x3a/0xe0 [ext3]
 [<001ca362>] __mark_inode_dirty+0x1ae/0x1c8
 [<001bfaa0>] iput+0xbc/0xf0
 [<001bdcca>] prune_dcache+0x29e/0x584
 [<001bdfe4>] shrink_dcache_memory+0x34/0x54
 [<0017b100>] shrink_slab+0x15c/0x250
 [<0017b6e4>] try_to_free_pages+0x1c0/0x2a4
 [<00170276>] __alloc_pages+0x2ba/0x4e0
 [<0017059a>] __get_free_pages+0x4e/0x8c
 [<00174ea2>] cache_alloc_refill+0x2a6/0x868
 [<00175540>] __kmalloc+0xdc/0xe0
 [<088a4e62>] ext3_xattr_set_handle+0x114a/0x174c [ext3]
 [<088a54e4>] ext3_xattr_set+0x80/0xd0 [ext3]
 [<088a6312>] ext3_xattr_user_set+0xce/0xe4 [ext3]
 [<088a5f1e>] ext3_setxattr+0x17e/0x18c [ext3]
 [<001c88e6>] setxattr+0x14a/0x234
 [<001c8a80>] sys_fsetxattr+0xb0/0x110
 [<0011fc10>] sysc_noemu+0x10/0x16


How did we get from iput() into __mark_inode_dirty()?  I can't see it in
mainline, nor in 2.6.5 which you appear to be using...


  Hmm, I think it could happen at least via quota code (but then I would expect
to see some entry in the backtrace about it).


You are right. I hit the problem on SuSE kernel.

void iput(struct inode *inode)
{
if (inode) {
struct super_operations *op = inode->i_sb->s_op;

if (inode->i_state == I_CLEAR)
BUG();

if (inode->i_state & I_DIRTY_DELAYED)
mark_inode_dirty_sync(inode); <---

I jumped in too early :(. Sorry for that.


Thanks
-Suzuki



Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.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: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

> > On kernel 2.6.20-rc1, ftp (get or put) stops
> > during file-transfer.
> > 
> > Client: ftp-0.17-33.fc6  (192.168.1.1)
> > Server: vsftpd-2.0.5-8   (192.168.1.3)
> > 

This problem happens on kernel-2.6.19-git4 or later.
but does _not_ happen on kernel-2.6.19-git3.

So this problem is introduced to kernel-2.6.19-git4.


I tried the Marvell 88E8001(skge) and Realtek 8139(8139too),
the same problem happens.

I think this is not a network-card-driver problem.

Thanks!
 
Best Regards
Komuro
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] change WARN_ON back to "BUG: at ..."

[Steven Rostedt]

On Fri, 2006-12-22 at 12:04 -0800, Andrew Morton wrote:
> I've always felt that it is wrong (or at least misleading) that WARN_ON
> prints "BUG".  It would have been better if it had said "WARNING", and only
> BUG_ON says "BUG".
> 
> But lots of people have now written downstream log-parsing tools which
> might break due to this change, so I'm inclined to go with Ingo's patch,
> and restore the old (il)logic.

>From hearing what Ingo has to say about this, it seems that calling it
WARING was wrong in the first place.

BUG (and BUG_ON) are really fatal bugs.  Meaning that if you continue,
you will corrupt the system.

WARN_ON is still a BUG, but we know enough about it that we can just
cripple the system so that it doesn't break anything.  But keeps the
system running so that someone can either read the logs, and perhaps, if
it happens to a developer, be able to do some more diagnostics.

But really, the WARN_ON should only be used when the system did
something that is as bad as a BUG, but you don't need to crash the
system since you can prevent data from being corrupted.  But you want to
flag this so that it can be fixed. Since it really is a BUG!  Calling
BUG_ON while the user is in X is really hopeless, since they may never
know why their system just crashed.

The kernel already prints out "warning" for other things that are not
bugs. Usually a warning means that something might not be compatible.
Or something might degrade performance.  Or you have buggy hardware.
But a "warning" doesn't usually mean a kernel BUG.  WARN_ON on the other
hand should only be used where the cause of the WARN_ON was due to a bug
in the kernel, hence, the word "BUG" should be used.

At least with the -rt patch, we get reports of a BUG happening where it
was from a WARN_ON, and this is a Good Thing(TM).  I can foresee users
ignoring a warning message if that's all they see, and they don't
realize that something has been crippled, and the system is unstable.

Sometimes a WARN_ON can be a cause of a later BUG.  And since the BUG
output has a "cut here" we may not get the output of the true bug.
Users are much more apt to report messages of BUG than WARNING.  So, I
totally agree with Ingo, we need people to see these as BUGs, and report
them whenever they happen. Because when it comes down to it, the warning
is about a bug.

-- Steve

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

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

[Christoph Anton Mitterer]

Hi my friends

It became a little bit silent about this issue... any new ideas or results?



Karsten Weiss wrote:
> BTW: Did someone already open an official bug at
> http://bugzilla.kernel.org ?
Karsten, did you already file a bug?



I told the whole issue to the Debian people which are about to release
etch and suggested them to use iommu=soft by default.
This brings me to:
Chris Wedgwood wrote:
> Does anyone have an amd64 with an nforce4 chipset and >4GB that does
> NOT have this problem? If so it might be worth chasing the BIOS
> vendors to see what errata they are dealing with.
John Chaves replied and claimed that he wouldn't suffer from that
problem (I've CC'ed him to this post).
You can read his message at the bottom of this post.
@ John: Could you please tell us in detail how you've tested your system?



Muli told us some information about the iommu options (when he
discuessed Karstens patch) has anybody made tests with the other iommu
options?



Ok and what does it all come down to? We still don't know the exact
reason...
Perhaps a kernel bug, a Opteron and/or Chipset bug,.. and perhaps there
are even some BIOSes that solve the issue...

For the kernel-bug reason,... who is the responsible developer for the
relevant code? Can we contact him to read our threads and perhaps review
the code?

Is anyone able (or wants to try) to inform AMD and/or Nvidia about the
issue (perhaps with pointing to that thread).

Someone might even try to contact some board vendors (some of us seem to
have Tyan boards). Although I'm in contact with the German support Team
of Tyan, I wasn't very successful with the US team... perhaps they have
other ideas.

Last but not least if we don't find a solution what should we do?
In my opinion at least the following:
1) Inform other OS communities (*BSD) and point the to our thread. Some
of you claimed that Windows wouldn't use the hwiommu at all so I think
we don't have to contact big evil.
2) Contact the major Linux Distributions (I've already did it for
Debian) and inform them about the potential issue and pointing them to
this thread (where one can find all the relevant information, I think)
3) Workaround for the kernel:
I have to less knowledge to know exactly what to do but I remember there
are other fixes for mainboard flaws and buggy chipsets in the kernel
(e.g. the RZ1000 or something like this in the "old" IDE driver)...
Perhaps someone (who knows what to do ;-) ) could write some code that
automatically uses iommu=soft,... but then we have the question: In
which case :-( . I imagine that the AMD users who don't suffer from this
issue would like to continue using their hwiommus..


What I'm currently plan to do:
1) If know one else is willing to try contacting AMD/Nvidia,.. I'd try
again.
2) I told you that I'm going to test the whole issue in the Leibniz
Supercomputing Centre where I work as student...
This is a little bit delayed (organisational problems :-) )
Anyway,... I'm not only going to test it on our Linux Cluster but also
some Sun Fire's (whe have mny of them ;-) ). According to my
boss they have nvidia chipsets... (He is probably contacting Sun for the
issue).



So much for now.

Best wishes,
Chris.


John Chaves message:
Here's another data point in case it helps.
The following system does *not* have the data corruption issue.

Motherboard: Iwill DK88 
Chipset: NVIDIA nForce4 Professional 2200
CPUs: Two Dual Core AMD Opteron(tm) Processor 280
Memory: 32GB
Disks: Four 500GB SATA in linux RAID1 over RAID0 setup
Kernel: 2.6.18

This system is a workhorse with extreme disk I/O of huge files,
and the nature of the work done would have revealed data
corruption pretty quickly.

FWIW,
John Chaves

His lspic:
:00:00.0 Memory controller: nVidia Corporation CK804 Memory
Controller (rev a3)
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: [44] #08 [01e0]
Capabilities: [e0] #08 [a801]

:00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
Subsystem: nVidia Corporation: Unknown device cb84
Flags: bus master, 66MHz, fast devsel, latency 0

:00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
Subsystem: nVidia Corporation: Unknown device cb84
Flags: 66MHz, fast devsel, IRQ 9
I/O ports at d400 [size=32]
I/O ports at 4c00 [size=64]
I/O ports at 4c40 [size=64]
Capabilities: [44] Power Management version 2

:00:02.0 USB Controller: nVidia Corporation CK804 USB Controller
(rev a2) (prog-if 10 [OHCI])
Subsystem: nVidia Corporation: Unknown device cb84
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 209
Memory at feafc000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2

:00:02.1 USB Controller: nVidia Corporation CK804 USB Controller
(rev a3) (prog-if 20 [EHCI])
Subsystem: nVidia Corporation: Unknown device cb84
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 193
Memory at feafdc00 (32-bit, non-prefetchable) [size=256]

Re: moxa serial driver testing

[Jiri Slaby]

[EMAIL PROTECTED] wrote:
> Hi Jiri,
> 
> I've figured out that both old and new mxser drivers have two similar
> problems:
> 
> 1. When there are data coming to a port, sometimes opening of the port
>entirely locks the box. This is quite reproducible. Any idea what's
>wrong and how can I help to debug it?

Could you test the patch below, if something changes?

---

 drivers/char/mxser_new.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/char/mxser_new.c b/drivers/char/mxser_new.c
index a2bca5d..c0af201 100644
--- a/drivers/char/mxser_new.c
+++ b/drivers/char/mxser_new.c
@@ -2268,6 +2268,8 @@ static irqreturn_t mxser_interrupt(int irq, void *dev_id)
if (bits & irqbits)
continue;
port = >ports[i];
+   if (!(port->flags & ASYNC_INITIALIZED))
+   continue;
 
int_cnt = 0;
do {
@@ -2320,9 +2322,9 @@ static irqreturn_t mxser_interrupt(int irq, void *dev_id)
if (status & UART_LSR_THRE)
mxser_transmit_chars(port);
}
-   } while (int_cnt++ < MXSER_ISR_PASS_LIMIT);
+   } while (int_cnt++ < 256);
}
-   if (pass_counter++ > MXSER_ISR_PASS_LIMIT)
+   if (pass_counter++ > 64)
break;  /* Prevent infinite loops */
}
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] CIFS won't link

[Randy Dunlap]

On Sat, 23 Dec 2006 14:21:48 +1300 Ian McDonald wrote:

> In commit fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9
> test_clear_page_dirty was removed a couple of days ago.
> 
> Now when I try and build I get this:
> WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!
> 
> This is caused by line 1248 of fs/cifs/file.c
>   if (PageWriteback(page) ||
>   !test_clear_page_dirty(page)) {
> 
> This isn't my area of expertise so I'm not providing a fix as I'm sure
> I'll get it wrong!
> 
> My apologies if people have already fixed as I'm not on all the relevant 
> lists.

Linus posted an (untested) patch for this about 10 minutes ago.
Is this something that you can test? (see below)


---
On Fri, 22 Dec 2006, Jean Delvare wrote:
> 
> The approach seems quite broken to me, the users should have been fixed
> _before_ removing the function, so as to avoid compilation failures.
> These are a pain for testers, and break git bisect too. Grmbl.

This needed to be fixed, and quite frankly, things don't get fixed nearly 
as quickly if you don't just break them first. And there really were just 
two filesystems that got broken, cifs being one of them.

I just can't test it.

> Now that it's done... Steve, can you please take a look and provide a
> patch so that cifs builds again?

CIFS _should_ be using "clear_page_dirty_for_io()" in that place, and that 
will fix the build. However, the reason I didn't just do that myself is 
that I can't test the end result, and for the life of me, I can't see 
where CIFS does the "end_page_writeback()" that it needs to do at IO 
completion time.

And the thing that confuses me about that, is that if CIFS doesn't do 
"end_page_writeback()", then it was already broken before - because when 
the VM calls "->writepage()" the clear_page_dirty_for_io() will have been 
done by the VM, and it needs that "end_page_writeback()" so that the 
system can know when the IO is done.

I _suspect_ that those "unlock_page()" calls should be accompanied by a 
"end_page_writeback()" call, and that the proper patch MAY look something 
like the appended, but I worry about having missed something really 
subtle. Maybe there's a end_page_writeback() somewhere else.

And if there isn't, I wonder if shared mappings have _ever_ worked on 
CIFS? And if so, how? That writeback bit thing isn't new per se.

So this may or may not fix it. If you can test it (_including_ with some 
dirty shared mmap-on-mmap action, please - just call me kinky), I'll 
commit it. But I need somebody who actually uses this to test it.

Linus

---
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 0f05cab..4f0472d 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1245,7 +1245,7 @@ retry:
wait_on_page_writeback(page);
 
if (PageWriteback(page) ||
-   !test_clear_page_dirty(page)) {
+   !clear_page_dirty_for_io(page)) {
unlock_page(page);
break;
}
@@ -1253,6 +1253,7 @@ retry:
if (page_offset(page) >= mapping->host->i_size) {
done = 1;
unlock_page(page);
+   end_page_writeback(page);
break;
}
 
@@ -1316,6 +1317,7 @@ retry:
SetPageError(page);
kunmap(page);
unlock_page(page);
+   end_page_writeback(page);
page_cache_release(page);
}
if ((wbc->nr_to_write -= n_iov) <= 0)
@@ -1356,7 +1358,8 @@ static int cifs_writepage(struct page* page, struct 
writeback_control *wbc)
rc = cifs_partialpagewrite(page, 0, PAGE_CACHE_SIZE);
SetPageUptodate(page); /* BB add check for error and Clearuptodate? */
unlock_page(page);
-   page_cache_release(page);   
+   end_page_writeback(page);
+   page_cache_release(page);
FreeXid(xid);
return rc;
 }
-

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

[BUG] CIFS won't link

[Ian McDonald]

In commit fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9
test_clear_page_dirty was removed a couple of days ago.

Now when I try and build I get this:
WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!

This is caused by line 1248 of fs/cifs/file.c
if (PageWriteback(page) ||
!test_clear_page_dirty(page)) {

This isn't my area of expertise so I'm not providing a fix as I'm sure
I'll get it wrong!

My apologies if people have already fixed as I'm not on all the relevant lists.

Regards,

Ian
--
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arch/i386/pci/mmconfig.c tlb flush fix

[OGAWA Hirofumi]

We use the fixmap for accessing pci config space in pci_mmcfg_read/write().
The problem is in pci_exp_set_dev_base(). It is caching a last
accessed address to avoid calling set_fixmap_nocache() whenever
pci_mmcfg_read/write() is used.

static inline void pci_exp_set_dev_base(int bus, int devfn)
{
u32 dev_base = base | (bus << 20) | (devfn << 12);
if (dev_base != mmcfg_last_accessed_device) {
mmcfg_last_accessed_device = dev_base;
set_fixmap_nocache(FIX_PCIE_MCFG, dev_base);
}
}

cpu0cpu1
  ---
pci_mmcfg_read("device-A")
pci_exp_set_dev_base()
set_fixmap_nocache()
  pci_mmcfg_read("device-B")
  pci_exp_set_dev_base()
  set_fixmap_nocache()
pci_mmcfg_read("device-B")
pci_exp_set_dev_base()
/* doesn't flush tlb */

But if cpus accessed the above order, the second pci_mmcfg_read() on
cpu0 doesn't flush the TLB, because "mmcfg_last_accessed_device" is
device-B.  So, second pci_mmcfg_read() on cpu0 accesses a device-A via
a previous TLB cache. This problem became the cause of several strange
behavior.

This patches fixes this situation by adds "mmcfg_last_accessed_cpu" check.

Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---

 arch/i386/pci/mmconfig.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff -puN arch/i386/pci/mmconfig.c~i386-mmconfig-flush arch/i386/pci/mmconfig.c
--- linux-2.6/arch/i386/pci/mmconfig.c~i386-mmconfig-flush  2006-10-06 
08:38:33.0 +0900
+++ linux-2.6-hirofumi/arch/i386/pci/mmconfig.c 2006-10-06 08:38:33.0 
+0900
@@ -26,6 +26,7 @@
 
 /* The base address of the last MMCONFIG device accessed */
 static u32 mmcfg_last_accessed_device;
+static int mmcfg_last_accessed_cpu;
 
 static DECLARE_BITMAP(fallback_slots, MAX_CHECK_BUS*32);
 
@@ -73,8 +74,11 @@ static u32 get_base_addr(unsigned int se
 static void pci_exp_set_dev_base(unsigned int base, int bus, int devfn)
 {
u32 dev_base = base | (bus << 20) | (devfn << 12);
-   if (dev_base != mmcfg_last_accessed_device) {
+   int cpu = smp_processor_id();
+   if (dev_base != mmcfg_last_accessed_device ||
+   cpu != mmcfg_last_accessed_cpu) {
mmcfg_last_accessed_device = dev_base;
+   mmcfg_last_accessed_cpu = cpu;
set_fixmap_nocache(FIX_PCIE_MCFG, dev_base);
}
 }
_

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

[PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address

[OGAWA Hirofumi]

Current -mm's mmconfig has some problems of remapped range.

a) In the case of broken MCFG tables on Asus etc., we need to remap
256M range, but currently only remap 1M.

b) The base address always corresponds to bus number 0, but currently
we are assuming it corresponds to start bus number.

This patch fixes the above problems.

Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---

 arch/x86_64/pci/mmconfig.c |   48 -
 1 file changed, 35 insertions(+), 13 deletions(-)

diff -puN arch/x86_64/pci/mmconfig.c~pci-mmconfig-ioremap-range-fix 
arch/x86_64/pci/mmconfig.c
--- linux-2.6/arch/x86_64/pci/mmconfig.c~pci-mmconfig-ioremap-range-fix 
2006-12-23 08:52:15.0 +0900
+++ linux-2.6-hirofumi/arch/x86_64/pci/mmconfig.c   2006-12-23 
09:35:37.0 +0900
@@ -24,6 +24,39 @@ struct mmcfg_virt {
 };
 static struct mmcfg_virt *pci_mmcfg_virt;
 
+static inline int mcfg_broken(void)
+{
+   struct acpi_table_mcfg_config *cfg = _mmcfg_config[0];
+
+   /* Handle more broken MCFG tables on Asus etc.
+  They only contain a single entry for bus 0-0. Assume
+  this applies to all busses. */
+   if (pci_mmcfg_config_num == 1 &&
+   cfg->pci_segment_group_number == 0 &&
+   (cfg->start_bus_number | cfg->end_bus_number) == 0)
+   return 1;
+   return 0;
+}
+
+static void __iomem *mcfg_ioremap(struct acpi_table_mcfg_config *cfg)
+{
+   void __iomem *addr;
+   u32 size;
+
+   if (mcfg_broken())
+   size = 256 << 20;
+   else
+   size = (cfg->end_bus_number + 1) << 20;
+
+   addr = ioremap_nocache(cfg->base_address, size);
+   if (addr) {
+   printk(KERN_INFO "PCI: Using MMCONFIG at %x - %x\n",
+  cfg->base_address,
+  cfg->base_address + size - 1);
+   }
+   return addr;
+}
+
 static char __iomem *get_virt(unsigned int seg, unsigned bus)
 {
int cfg_num = -1;
@@ -41,13 +74,7 @@ static char __iomem *get_virt(unsigned i
return pci_mmcfg_virt[cfg_num].virt;
}
 
-   /* Handle more broken MCFG tables on Asus etc.
-  They only contain a single entry for bus 0-0. Assume
-  this applies to all busses. */
-   cfg = _mmcfg_config[0];
-   if (pci_mmcfg_config_num == 1 &&
-   cfg->pci_segment_group_number == 0 &&
-   (cfg->start_bus_number | cfg->end_bus_number) == 0)
+   if (mcfg_broken())
return pci_mmcfg_virt[0].virt;
 
/* Fall back to type 0 */
@@ -139,19 +166,14 @@ int __init pci_mmcfg_arch_init(void)
}
 
for (i = 0; i < pci_mmcfg_config_num; ++i) {
-   u32 size = (pci_mmcfg_config[0].end_bus_number - 
pci_mmcfg_config[0].start_bus_number + 1) << 20;
pci_mmcfg_virt[i].cfg = _mmcfg_config[i];
-   pci_mmcfg_virt[i].virt = 
ioremap_nocache(pci_mmcfg_config[i].base_address,
-size);
+   pci_mmcfg_virt[i].virt = mcfg_ioremap(_mmcfg_config[i]);
if (!pci_mmcfg_virt[i].virt) {
printk(KERN_ERR "PCI: Cannot map mmconfig aperture for "
"segment %d\n",
   pci_mmcfg_config[i].pci_segment_group_number);
return 0;
}
-   printk(KERN_INFO "PCI: Using MMCONFIG at %x-%x\n",
-  pci_mmcfg_config[i].base_address,
-  pci_mmcfg_config[i].base_address + size - 1);
}
 
raw_pci_ops = _mmcfg;
_

-- 
OGAWA Hirofumi <[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: moxa serial driver testing

[Jiri Slaby]

Jiri Slaby wrote:
> [EMAIL PROTECTED] wrote:
>> Hi Jiri,
>>
>> I've figured out that both old and new mxser drivers have two similar
>> problems:
>>
>> 1. When there are data coming to a port, sometimes opening of the port
>>entirely locks the box. This is quite reproducible. Any idea what's
>>wrong and how can I help to debug it?
> 
> Please enable

BTW. Does sysrq-keys work in such situation for you? I'll appreciate if you was
able to grab sysrq-t output, when it happens.

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: 2.6.19-rt14 slowdown compared to 2.6.19

[Daniel Walker]

On Fri, 2006-12-22 at 13:39 -0800, Chen, Tim C wrote:

> Wonder if you have any suggestions on what could cause the slowdown.  
> We've tried disabling CONFIG_NO_HZ and it didn't help much.

Did you compare PREEMPT_RT with vanilla PREEMPT ? Or one version of
PREEMPT_RT vs. another ?

Daniel

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

Re: WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!

[Linus Torvalds]

On Fri, 22 Dec 2006, Jean Delvare wrote:
> 
> The approach seems quite broken to me, the users should have been fixed
> _before_ removing the function, so as to avoid compilation failures.
> These are a pain for testers, and break git bisect too. Grmbl.

This needed to be fixed, and quite frankly, things don't get fixed nearly 
as quickly if you don't just break them first. And there really were just 
two filesystems that got broken, cifs being one of them.

I just can't test it.

> Now that it's done... Steve, can you please take a look and provide a
> patch so that cifs builds again?

CIFS _should_ be using "clear_page_dirty_for_io()" in that place, and that 
will fix the build. However, the reason I didn't just do that myself is 
that I can't test the end result, and for the life of me, I can't see 
where CIFS does the "end_page_writeback()" that it needs to do at IO 
completion time.

And the thing that confuses me about that, is that if CIFS doesn't do 
"end_page_writeback()", then it was already broken before - because when 
the VM calls "->writepage()" the clear_page_dirty_for_io() will have been 
done by the VM, and it needs that "end_page_writeback()" so that the 
system can know when the IO is done.

I _suspect_ that those "unlock_page()" calls should be accompanied by a 
"end_page_writeback()" call, and that the proper patch MAY look something 
like the appended, but I worry about having missed something really 
subtle. Maybe there's a end_page_writeback() somewhere else.

And if there isn't, I wonder if shared mappings have _ever_ worked on 
CIFS? And if so, how? That writeback bit thing isn't new per se.

So this may or may not fix it. If you can test it (_including_ with some 
dirty shared mmap-on-mmap action, please - just call me kinky), I'll 
commit it. But I need somebody who actually uses this to test it.

Linus

---
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 0f05cab..4f0472d 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1245,7 +1245,7 @@ retry:
wait_on_page_writeback(page);
 
if (PageWriteback(page) ||
-   !test_clear_page_dirty(page)) {
+   !clear_page_dirty_for_io(page)) {
unlock_page(page);
break;
}
@@ -1253,6 +1253,7 @@ retry:
if (page_offset(page) >= mapping->host->i_size) {
done = 1;
unlock_page(page);
+   end_page_writeback(page);
break;
}
 
@@ -1316,6 +1317,7 @@ retry:
SetPageError(page);
kunmap(page);
unlock_page(page);
+   end_page_writeback(page);
page_cache_release(page);
}
if ((wbc->nr_to_write -= n_iov) <= 0)
@@ -1356,7 +1358,8 @@ static int cifs_writepage(struct page* page, struct 
writeback_control *wbc)
rc = cifs_partialpagewrite(page, 0, PAGE_CACHE_SIZE);
SetPageUptodate(page); /* BB add check for error and Clearuptodate? */
unlock_page(page);
-   page_cache_release(page);   
+   end_page_writeback(page);
+   page_cache_release(page);
FreeXid(xid);
return rc;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [NFS] Kernel BUG

[Rudy Zijlstra]

Peter Zijlstra wrote:


On Fri, 2006-12-22 at 12:59 +0100, Rudy Zijlstra wrote:
 


Hi,

I have a system where whenever i trigger a ongoing consistent NFS load i 
get the following kernel BUG:


--
kernel BUG at mm/truncate.c:311!
   



Lotsa changes there:
try these:
http://client.linux-nfs.org/Linux-2.6.x/2.6.19/linux-2.6.19-NFS_ALL.dif

And:
 http://lkml.org/lkml/2006/12/19/279

 

Thanks, i have now a 2.6.19.1 patched with the above NFS_ALL patchset 
running under load since about 17:00 and still going strong. So seems to 
have solved the problem!


Also, performance seems to have significantly increased. I am testing 
this with MythTv with the storage over NFS. With HD LiveTV (which  is 
what i use to test this), this translates into about 43Mbps total load, 
from almost 15Mbps video stream which is present 3x on the ethernet:

1/ from card to NFS disk
2/ read from NFS disk
3/ stream to viewer app.

Doing this with HD streams before the patch set resulted in regular 
picture hickups. No hickups visible anymore (that i have seen, i have 
not been present all this time).


Regards,

Rudy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Rename FIELD_SIZEOF to MEMBER_SIZE and use in source tree.

[Gene Heskett]

On Friday 22 December 2006 18:21, Jan Engelhardt wrote:
>>  Rename the macro FIELD_SIZEOF() in include/linux/kernel.h to
>>MEMBER_SIZE(), and make a number of replacements in the source tree
>>where that macro simplified the code.
>
>Looks sane. (Random thought: SIZEOF_MEMBER())
>
Lets not go there, spamassassin already has enough trouble with variations 
on that theme...
>
>   -`J'

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Rewrite unnecessary duplicated code to use FIELD_SIZEOF().

[Jan Engelhardt]

On Dec 22 2006 09:43, Robert P. J. Day wrote:
>
>that's the name as it *already* existed in kernel.h.  however, since
>no one was actually using it yet, it's a piece of cake to give it a
>better name.  either FIELD_SIZE or MEMBER_SIZE would work just fine.

I 'd go for MEMBER_SIZE. (Compare the proportion of literature that uses
'struct members' and 'struct fields'. On another note,
Regular ("agricultural/geometrical") meaning: Feld (ger.) <-> field
informatics: Feld <-> array)


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

Re: [PATCH] Rename FIELD_SIZEOF to MEMBER_SIZE and use in source tree.

[Jan Engelhardt]

>
>  Rename the macro FIELD_SIZEOF() in include/linux/kernel.h to
>MEMBER_SIZE(), and make a number of replacements in the source tree
>where that macro simplified the code.

Looks sane. (Random thought: SIZEOF_MEMBER())


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

Re: Binary Drivers

[Nikolaos D. Bougalis]

Robert Hancock wrote:

Nikolaos D. Bougalis wrote:
Manufacturers design product as they see fit and offer it on the 
market; I don't see nVidia or ATI thugs twisting your arm behind you 
as you walk down the aisle of Fry's Electronics saying "buy this nice 
card we made or I'll break your arm."


If you need high-performance 3D they might as well be, as realistically 
ATI and NVIDIA are the only providers of high-performance video for the 
consumer market. Nobody else makes anything that competes, not even 
onboard video chipsets like Intel, SiS, etc.


	My point was that nowadays most manufacturers, as a matter of course, do not 
provide full details on how the hardware is programmed, and there appears to 
be no significant market for high-performance 3D graphics with an open 
specification.


	I do not like owning a space heater with nifty DVI outputs, and that is a 
fact I take into account when I make a purchasing decision for graphics cards 
I will be using with Linux.


	But I realize that ultimately, companies respond to markets, and not idealism 
and know that ACME Hardware will publish the specs for their rocket-shoes when 
the piece of the Linux rocket-shoe pie becomes lucrative enough. And because I 
do, I try to change the market and educate consumers -- not browbeat companies 
or turn the piece into a crumble by limiting what consumers can do.


-n

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

[PATCH 3/3] Char: mxser_new, remove useless spinlock

[Jiri Slaby]

mxser_new, remove useless spinlock

gm_lock is useless, since ISA is configured at init time and there it's
serialized.

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

---
commit 5f93193574c932263132e3262853be671e9d1642
tree 94693e221836fd7234e290b9911757357889a580
parent 04a4dbf03a9fdc4c53282ab7e1db146389140c3b
author Jiri Slaby <[EMAIL PROTECTED]> Fri, 22 Dec 2006 23:04:17 +0059
committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 22 Dec 2006 23:04:17 +0059

 drivers/char/mxser_new.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/char/mxser_new.c b/drivers/char/mxser_new.c
index 2f173e9..103f0b5 100644
--- a/drivers/char/mxser_new.c
+++ b/drivers/char/mxser_new.c
@@ -313,7 +313,6 @@ static int mxvar_diagflag;
 static unsigned char mxser_msr[MXSER_PORTS + 1];
 static struct mxser_mon_ext mon_data_ext;
 static int mxser_set_baud_method[MXSER_PORTS + 1];
-static spinlock_t gm_lock;
 
 #ifdef CONFIG_PCI
 static int __devinit CheckIsMoxaMust(int io)
@@ -1377,7 +1376,6 @@ static int __init mxser_program_mode(int port)
 {
int id, i, j, n;
 
-   spin_lock(_lock);
outb(0, port);
outb(0, port);
outb(0, port);
@@ -1385,7 +1383,6 @@ static int __init mxser_program_mode(int port)
(void)inb(port);
outb(0, port);
(void)inb(port);
-   spin_unlock(_lock);
 
id = inb(port + 1) & 0x1F;
if ((id != C168_ASIC_ID) &&
@@ -2684,7 +2681,6 @@ static int __init mxser_module_init(void)
mxvar_sdriver = alloc_tty_driver(MXSER_PORTS + 1);
if (!mxvar_sdriver)
return -ENOMEM;
-   spin_lock_init(_lock);
 
printk(KERN_INFO "MOXA Smartio/Industio family driver version %s\n",
MXSER_VERSION);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] Char: mxser_new, mark init functions

[Jiri Slaby]

mxser_new, mark init functions

Mark some funcions with __init and __devinit.

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

---
commit 04a4dbf03a9fdc4c53282ab7e1db146389140c3b
tree 916cdef3d0f3acb58de8b96db6e83c11c3f0613c
parent e3a36e41f423af467a95221598fd5754a8fb4032
author Jiri Slaby <[EMAIL PROTECTED]> Fri, 22 Dec 2006 22:56:33 +0059
committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 22 Dec 2006 22:56:33 +0059

 drivers/char/mxser_new.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/char/mxser_new.c b/drivers/char/mxser_new.c
index 1bb030b..2f173e9 100644
--- a/drivers/char/mxser_new.c
+++ b/drivers/char/mxser_new.c
@@ -316,7 +316,7 @@ static int mxser_set_baud_method[MXSER_PORTS + 1];
 static spinlock_t gm_lock;
 
 #ifdef CONFIG_PCI
-static int CheckIsMoxaMust(int io)
+static int __devinit CheckIsMoxaMust(int io)
 {
u8 oldmcr, hwid;
int i;
@@ -1373,7 +1373,7 @@ static int mxser_tiocmset(struct tty_struct *tty, struct 
file *file,
return 0;
 }
 
-static int mxser_program_mode(int port)
+static int __init mxser_program_mode(int port)
 {
int id, i, j, n;
 
@@ -1410,7 +1410,7 @@ static int mxser_program_mode(int port)
return id;
 }
 
-static void mxser_normal_mode(int port)
+static void __init mxser_normal_mode(int port)
 {
int i, n;
 
@@ -1443,7 +1443,7 @@ static void mxser_normal_mode(int port)
 #define EN0_PORT   0x010   /* Rcv missed frame error counter RD */
 #define ENC_PAGE0  0x000   /* Select page 0 of chip registers   */
 #define ENC_PAGE3  0x0C0   /* Select page 3 of chip registers   */
-static int mxser_read_register(int port, unsigned short *regs)
+static int __init mxser_read_register(int port, unsigned short *regs)
 {
int i, k, value, id;
unsigned int j;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] Char: mxser, fix oops when removing opened

[Jiri Slaby]

mxser, fix oops when removing opened

tty_driver->owner is not set, so if somebody remove mxser_module, it might
oops (and doesn't tell the user: no way, it's in use). Set the .owner value.

Cc: <[EMAIL PROTECTED]>
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

---
commit e3a36e41f423af467a95221598fd5754a8fb4032
tree b78cc8a59cb41f27781d115e285c447cf913a889
parent 5df5a993999b94d728cedfa669eba2b0b58e16d7
author Jiri Slaby <[EMAIL PROTECTED]> Fri, 22 Dec 2006 22:48:24 +0059
committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 22 Dec 2006 22:48:24 +0059

 drivers/char/mxser.c |1 +
 drivers/char/mxser_new.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/char/mxser.c b/drivers/char/mxser.c
index c063359..83f604b 100644
--- a/drivers/char/mxser.c
+++ b/drivers/char/mxser.c
@@ -717,6 +717,7 @@ static int mxser_init(void)
 
/* Initialize the tty_driver structure */
memset(mxvar_sdriver, 0, sizeof(struct tty_driver));
+   mxvar_sdriver->owner = THIS_MODULE;
mxvar_sdriver->magic = TTY_DRIVER_MAGIC;
mxvar_sdriver->name = "ttyMI";
mxvar_sdriver->major = ttymajor;
diff --git a/drivers/char/mxser_new.c b/drivers/char/mxser_new.c
index cd989dc..1bb030b 100644
--- a/drivers/char/mxser_new.c
+++ b/drivers/char/mxser_new.c
@@ -2690,6 +2690,7 @@ static int __init mxser_module_init(void)
MXSER_VERSION);
 
/* Initialize the tty_driver structure */
+   mxvar_sdriver->owner = THIS_MODULE;
mxvar_sdriver->magic = TTY_DRIVER_MAGIC;
mxvar_sdriver->name = "ttyMI";
mxvar_sdriver->major = ttymajor;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Eric W. Biederman]

Jean Delvare <[EMAIL PROTECTED]> writes:

> Hi Vivek,
>
> On Fri, 22 Dec 2006 16:10:56 +0530, Vivek Goyal wrote:
>> Another odd thing is that "file vmlinux.bin" shows following.
>> 
>> vmlinux.bin: Sendmail frozen configuration - version
> \015\024\322\216\356\222X\2306\032H\220\303\270\006\007\003
>> 
>> I am not sure what does it mean. I had expected it to be a data blob.
>> 
>> "vmlinux.bin: data"
>
> The file command uses heuristics to attempt to identify files. Here a
> random sequence of bytes was simply misinterpreted as something
> completely different. You can tell from the version string which is
> totally broken. So, "file" could be improved to avoid this false
> positive, but that's about it.
>
> Now, what's still relevant is that my vmlinux.bin starts with a
> binary sequence which differs from all other vmlinux.bin files around.
> So it's a hint that it is corrupted, although a deeper analysis will be
> required to figure out how and why.

A simple analysis says vmlinux.bin is created by the linker.  So we
can probably look at why vmlinux.bin gets generated strangely.

I know I touched that path a little bit in my patch.

Eric

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

Re: Patch "i386: Relocatable kernel support" causes instant reboot

[Jean Delvare]

Hi Vivek,

On Fri, 22 Dec 2006 16:10:56 +0530, Vivek Goyal wrote:
> Another odd thing is that "file vmlinux.bin" shows following.
> 
> vmlinux.bin: Sendmail frozen configuration  - version 
> \015\024\322\216\356\222X\2306\032H\220\303\270\006\007\003
> 
> I am not sure what does it mean. I had expected it to be a data blob.
> 
> "vmlinux.bin: data"

The file command uses heuristics to attempt to identify files. Here a
random sequence of bytes was simply misinterpreted as something
completely different. You can tell from the version string which is
totally broken. So, "file" could be improved to avoid this false
positive, but that's about it.

Now, what's still relevant is that my vmlinux.bin starts with a
binary sequence which differs from all other vmlinux.bin files around.
So it's a hint that it is corrupted, although a deeper analysis will be
required to figure out how and why.

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

Re: Binary Drivers

[Scott Preece]

On 12/22/06, Wolfgang Draxinger <[EMAIL PROTECTED]> wrote:

Am Freitag, 22. Dezember 2006 20:22 schrieb Rok Markovic:
> Hi!
>
> Maybe this does not belong to this thread, but I am wondering why
> manufactorers doesn't want to release specifications about drivers

You're not alone, I think everybody who knows, how things in a
computer work shares this view.

---

Two of the specific arguments I've heard are (a) that the board (and
its hardware interfaces that the documentation would describe) involve
IP licensed from a third party, which the board manufacturer does not
have a legal right to disclose, or (b) that there is, in fact, no
suitable documentation, because the boards are developed somewhat
fluidly and the driver is developed directly from low-level knowledge
that simply isn't written down in a form suitable for passing on.

If you're building products with no expectation of supporting outside
driver developers, both of those are quite possible.

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

Re: [patch 2.6.20-rc1 3/6] input: ads7846 more compatible with hwmon

[David Brownell]

On Friday 22 December 2006 12:26 pm, Dmitry Torokhov wrote:
> On 12/22/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > Be more compatible with the hwmon framework:
> >
> >  - Hook up to hwmon
> > * show sensor attrubites only if hwmon is present
> > * otherwise be just a touchscreen
> >  - Report voltages per hwmon convention
> > * measure in millivolts
> > * voltages are named in[0-8]_input (ugh)
> > * for 7846 chips, properly range-adjust vBATT/in1_input
> 
> There are too many #ifdefs. Please consider creating
> ads7846_[un]register_hwmon() and use them in
> ads7846_probe()/ads7846_remove().

Did that.


> Split hwmon related attributes into 
> a separate attribute group and move everything in #ifdef CONFIG_HWMON
> block.

Done.
 
> > + *
> > + * FIXME make external vREF_mV be a module option, and use that as 
> > needed...
> >  */
> > +static const unsigned vREF_mV = 2500;
> >
> 
> Why don't you make it mdule option right away?

Mostly because that was a least-work-to-sync-up kind of patch.  ;)

Did that too.  The updated patch is appended.  The other three patches still
work fine, but obviously the line numbers changed so you should ingore those
patch warnings (64 lines of offset).

Note that this fixes a glitch with HWMON=m, which now constrains this driver
to be a module too.

- Dave

CUT HERE
Be more compatible with the hwmon framework:

 - Hook up to hwmon
 * show sensor attributes only if hwmon is present
 * ... and the board's reference voltage is known
 * otherwise be just a touchscreen
 - Report voltages per hwmon convention
 * measure in millivolts
 * voltages are named in[0-8]_input (ugh)
 * for 7846 chips, properly range-adjust vBATT/in1_input

Battery measurements help during recharge monitoring.  On OSK/Mistral,
the measured voltage agreed with a multimeter to several decimal places.
 
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
UPDATED per feedback from Dmitry, and to fix a HWMON dependency glitch

 drivers/input/touchscreen/Kconfig   |9 -
 drivers/input/touchscreen/ads7846.c |  299 +---
 2 files changed, 220 insertions(+), 88 deletions(-)

Index: osk/drivers/input/touchscreen/Kconfig
===
--- osk.orig/drivers/input/touchscreen/Kconfig  2006-12-22 11:08:09.0 
-0800
+++ osk/drivers/input/touchscreen/Kconfig   2006-12-22 13:55:13.0 
-0800
@@ -12,12 +12,17 @@ menuconfig INPUT_TOUCHSCREEN
 if INPUT_TOUCHSCREEN
 
 config TOUCHSCREEN_ADS7846
-   tristate "ADS 7846 based touchscreens"
+   tristate "ADS 7846/7843 based touchscreens"
depends on SPI_MASTER
+   depends on HWMON = n || HWMON
help
  Say Y here if you have a touchscreen interface using the
- ADS7846 controller, and your board-specific initialization
+ ADS7846 or ADS7843 controller, and your board-specific setup
  code includes that in its table of SPI devices.
+ 
+ If HWMON is selected, and the driver is told the reference voltage
+ on your board, you will also get hwmon interfaces for the voltage
+ (and on ads7846, temperature) sensors of this chip.
 
  If unsure, say N (but it's safe to say "Y").
 
Index: osk/drivers/input/touchscreen/ads7846.c
===
--- osk.orig/drivers/input/touchscreen/ads7846.c2006-12-22 
11:08:43.0 -0800
+++ osk/drivers/input/touchscreen/ads7846.c 2006-12-22 13:58:09.0 
-0800
@@ -17,8 +17,9 @@
  *  it under the terms of the GNU General Public License version 2 as
  *  published by the Free Software Foundation.
  */
-#include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -77,6 +78,7 @@ struct ads7846 {
 
struct spi_device   *spi;
struct attribute_group  *attr_group;
+   struct class_device *hwmon;
u16 model;
u16 vref_delay_usecs;
u16 x_plate_ohms;
@@ -169,7 +171,12 @@ struct ads7846 {
 
 /*
  * Non-touchscreen sensors only use single-ended conversions.
+ * The range is GND..vREF. The ads7843 and ads7835 must use external vREF;
+ * ads7846 lets that pin be unconnected, to use internal vREF.
  */
+static unsigned vREF_mV;
+module_param(vREF_mV, uint, 0);
+MODULE_PARM_DESC(vREF_mV, "external vREF voltage, in milliVolts");
 
 struct ser_req {
u8  ref_on;
@@ -197,50 +204,55 @@ static int ads7846_read12_ser(struct dev
struct ser_req  *req = kzalloc(sizeof *req, GFP_KERNEL);
int status;
int sample;
-   int i;
+   int use_internal;
 
if (!req)
return -ENOMEM;
 
spi_message_init(>msg);
 
-   /* activate reference, so it has time to 

Re: Binary Drivers

[Wolfgang Draxinger]

Am Freitag, 22. Dezember 2006 20:22 schrieb Rok Markovic:
> Hi!
>
> Maybe this does not belong to this thread, but I am wondering why
> manufactorers doesn't want to release specifications about drivers.
> They have decided to develop some hardware for, let say 3D
> accelaration. Now they are selling hardware and users are buying
> hardware. Users are not buying hardware because they want to run
> mighty drivers, they want to use hardware.

You're not alone, I think everybody who knows, how things in a 
computer work shares this view.

> 1. Why they do not reveal spec. if user allready bought hardware,
> though they give driver for free but not specs.
>
> 2. Who can contribute if they reveal specifications (how to use
> hardware) ?
>
>
> Can anyone answer does questions?

A few years ago I had some closer contact with a driver developer of a 
well known consumer HW manufacturer hunting down some nasty bugs I 
discovered and developed workarounds for. From him I know, that most 
developers and engineers would have no problem to disclose the 
hardware specifications. The real hinderers are legal affairs and - 
suprisingly - marketing departments; with little more knowledge about 
the internals of their products, for them _everything_ created within 
the company is considered as not to be leaked, valuable information 
by them.

Wolfgang Draxinger


pgpUhtyAleUgG.pgp
Description: PGP signature

Re: [PATCH 1/5] Update Documentation/pci.txt

[Stefan Richter]

> On Mon, 18 Dec 2006 00:11:33 -0700 Grant Grundler wrote:
...
>> +4.1 Stop IRQs on the device
>> +~~~
>> +How to do this is chip/device specific. If it's not done, it opens
>> +the possibility of a "screaming interrupt" if (and only if)
>> +the IRQ is shared with another device.
>> +
>> +When the shared IRQ handler is "unhoooked", the remaining devices
   ^^^
-> unhooked

...
>> +11. MMIO Space and "Write Posting"
>> +~~
>> +Converting a driver from using I/O Port space to using MMIO space
>> +often requires some additional changes. Specifically, "write posting"
>> +needs to be handled. Many drivers (e.g. tg3, acenic, sym53c8xx_2)
>> +already do. I/O Port space guarantees write transactions reach the PCI
> 
>already do this.
> 
>> +device before the CPU can continue. Writes to MMIO space allow to CPU
   ^^
>> +continue before the transaction reaches the PCI device. HW weenies
   ^
-> allow the CPU to continue

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

[PATCH] pci/probe: fix macro that confuses kernel-doc

[Randy Dunlap]

From: Randy Dunlap <[EMAIL PROTECTED]>

Don't have macros between a function's kernel-doc block and
the function definition.  This is not valid for kernel-doc.

Warning(/var/linsrc/linux-2.6.20-rc1-git8//drivers/pci/probe.c:653): No 
description found for parameter 'IORESOURCE_PCI_FIXED'

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 drivers/pci/probe.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- linux-2.6.20-rc1-git8.orig/drivers/pci/probe.c
+++ linux-2.6.20-rc1-git8/drivers/pci/probe.c
@@ -639,6 +639,8 @@ static void pci_read_irq(struct pci_dev 
dev->irq = irq;
 }
 
+#define LEGACY_IO_RESOURCE (IORESOURCE_IO | IORESOURCE_PCI_FIXED)
+
 /**
  * pci_setup_device - fill in class and map information of a device
  * @dev: the device structure to fill
@@ -649,9 +651,6 @@ static void pci_read_irq(struct pci_dev 
  * Returns 0 on success and -1 if unknown type of device (not normal, bridge
  * or CardBus).
  */
-
-#define LEGACY_IO_RESOURCE (IORESOURCE_IO | IORESOURCE_PCI_FIXED)
-
 static int pci_setup_device(struct pci_dev * dev)
 {
u32 class;


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

Re: omap compilation fixes

[Pavel Machek]

Hi!

> > This is not yet complete set. set_map() is missing in latest kernels.
> > 
> > Fix DECLARE_WORK()-change-related compilation problems. Please apply,
> >
> > --- a/drivers/mmc/omap.c
> > +++ b/drivers/mmc/omap.c
> > @@ -2,7 +2,7 @@
> >   *  linux/drivers/media/mmc/omap.c
> >   *
> >   *  Copyright (C) 2004 Nokia Corporation
> > - *  Written by Tuukka Tikkanen and Juha Yrjölä<[EMAIL PROTECTED]>
> > + *  Written by Tuukka Tikkanen and Juha Yrjölä <[EMAIL PROTECTED]>
> >   *  Misc hacks here and there by Tony Lindgren <[EMAIL PROTECTED]>
> >   *  Other hacks (DMA, SD, etc) by David Brownell
> >   *
> 
> I already applied similar fixes to linux-omap for the workqueue changes,
> so I only applied the MMC typo fix above.

I thought I got pretty recent -git:

omap git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git

...should I use another tree?

Aha, I did another pull now and it seems to be better... no, it is
not:

Recovering from a previously interrupted fetch...
Fetching pack (head and objects)...
Fetching tags...
Missing tag v2.6.20-rc1...
Generating pack...
Done counting 1 objects.
Deltifying 1 objects.
 100% (1/1) done
Total 1, written 1 (delta 0), reused 1 (delta 0)
Unpacking 1 objects
 100% (1/1) done
Up to date.

Applying changes...
Branch already fully merged.

Plus it still does not compile:

  LD  vmlinux
arch/arm/plat-omap/built-in.o(.text+0xd470): In function
`exmap_set_armmmu':
: undefined reference to `set_pte'
arch/arm/plat-omap/built-in.o(.text+0xd56c): In function
`exmap_set_armmmu':
: undefined reference to `set_pte'
make: *** [vmlinux] Error 1

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix some ARM builds due to HID brokenness

[Jiri Kosina]

On Fri, 22 Dec 2006, Russell King wrote:

> The new location for HID is extremely annoying:

Hi Russell,

well, the location itself was a subject to various discussions. At the 
end, drivers/hid won against drivers/input/hid, because, as Marcel 
correctly pointed out, in case of embedded systems there might be a need 
to have an abstraction for non-input devices and then we don't want to 
bundle it to tightly to input. There is no such implementation yet, but 
moving this code around is quite painful, so we don't want to do it more 
than once.

> 1. the help text implies that you need to enable it for any
>keyboard or mouse attached to the system.  This is not
>correct.

This help text has been there for ages, it was duplicated from previous 
help text from usb hid implementation, but you are right that the wording 
might confuse someone. Will change it eventually, thanks.

> 2. it defaults to 'y'.  When you have input deselected, this
>causes the kernel to fail to link:
> Fix the second problem by making it depend on INPUT.
> Signed-off-by: Russell King <[EMAIL PROTECTED]>

Applied, thanks.

-- 
Jiri Kosina
SUSE 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/

2.6.19-rt14 slowdown compared to 2.6.19

[Chen, Tim C]

Ingo,
 
We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19 
kernel and noticed several slowdowns.  The test machine is a 2 socket
woodcrest machine with your default configuration.
 
Netperf TCP Streaming was slower by 40% ( 1 server and 1 client 
each bound to separate cpu cores on different socket, network
loopback mode was used).  

Volanomark was slower by 80% (Server and Clients communicate with 
network loopback mode. Idle time goes from 1% to 60%)

Re-Aim7 was slower by 40% (idle time goes from 0% to 20%)

Wonder if you have any suggestions on what could cause the slowdown.  
We've tried disabling CONFIG_NO_HZ and it didn't help much.

Thanks.

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

evading ulimits

[John Richard Moser]

I've set up some stuff on my box where /etc/security/limits.conf
contains the following:

@users  softnproc   3072
@users  hardnproc   4096

I'm in group users, and a simple fork bomb is easily quashed by this:

[EMAIL PROTECTED]:~$ :(){ :|:; };:
bash: fork: Resource temporarily unavailable
Terminated

Oddly enough, trying this again and again yields the same results; but,
I can kill the box (eventually; about 1 minute in I managed to `/exec
killall -9 bash` from x-chat, since I couldn't get a new shell open)
with the below:

[EMAIL PROTECTED]:~$ :(){ :|:|:; };:

How exactly does the ulimit work?  Why do I seem to be able to evade
limits on maximum number of processes by doing a bigger fork bomb?  I
would have thought that the above would have terminated much sooner,
since it was spawning x^3 processes instead of x^2 for iteration x and
should have hit 4096 a lot sooner.


-- 
We will enslave their women, eat their children and rape their
cattle!
 -- Bosc, Evil alien overlord from the fifth dimension
Anti-Spam:  https://bugzilla.mozilla.org/show_bug.cgi?id=229686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!

[Jean Delvare]

On Fri, 22 Dec 2006 15:28:45 +0100, Thomas Meyer wrote:
> Again current git head:
> 
> I guess this should be fixed by someone!
> 
> WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!
> make[1]: *** [__modpost] Fehler 1
> make: *** [modules] Fehler 2

This is caused by this commit:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9

>From the log message:
"Some filesystems need to be fixed up for this: CIFS, FUSE, JFS,
ReiserFS, XFS all use the old confusing functions, and will be fixed
separately in subsequent commits (with some of them just removing the
offending logic, and others using clear_page_dirty_for_io())."

The approach seems quite broken to me, the users should have been fixed
_before_ removing the function, so as to avoid compilation failures.
These are a pain for testers, and break git bisect too. Grmbl.

Now that it's done... Steve, can you please take a look and provide a
patch so that cifs builds again?

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

Re: Binary Drivers

[Robert Hancock]

Nikolaos D. Bougalis wrote:
Manufacturers design product as they see fit and offer it on the 
market; I don't see nVidia or ATI thugs twisting your arm behind you as 
you walk down the aisle of Fry's Electronics saying "buy this nice card 
we made or I'll break your arm."


If you need high-performance 3D they might as well be, as realistically 
ATI and NVIDIA are the only providers of high-performance video for the 
consumer market. Nobody else makes anything that competes, not even 
onboard video chipsets like Intel, SiS, etc.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

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

Re: omap compilation fixes

[Tony Lindgren]

* Pavel Machek <[EMAIL PROTECTED]> [061222 02:55]:
> Hi!
> 
> This is not yet complete set. set_map() is missing in latest kernels.
> 
> Fix DECLARE_WORK()-change-related compilation problems. Please apply,
>
> --- a/drivers/mmc/omap.c
> +++ b/drivers/mmc/omap.c
> @@ -2,7 +2,7 @@
>   *  linux/drivers/media/mmc/omap.c
>   *
>   *  Copyright (C) 2004 Nokia Corporation
> - *  Written by Tuukka Tikkanen and Juha Yrjölä<[EMAIL PROTECTED]>
> + *  Written by Tuukka Tikkanen and Juha Yrjölä <[EMAIL PROTECTED]>
>   *  Misc hacks here and there by Tony Lindgren <[EMAIL PROTECTED]>
>   *  Other hacks (DMA, SD, etc) by David Brownell
>   *

I already applied similar fixes to linux-omap for the workqueue changes,
so I only applied the MMC typo fix above.

Regards,

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

[RFC] ext4-block-reservation.patch

[Alex Tomas]

Index: linux-2.6.20-rc1/include/linux/ext4_fs.h
===
--- linux-2.6.20-rc1.orig/include/linux/ext4_fs.h   2006-12-14 
04:14:23.0 +0300
+++ linux-2.6.20-rc1/include/linux/ext4_fs.h2006-12-22 20:21:12.0 
+0300
@@ -201,6 +201,7 @@ struct ext4_group_desc
 #define EXT4_STATE_JDATA   0x0001 /* journaled data exists */
 #define EXT4_STATE_NEW 0x0002 /* inode is newly created */
 #define EXT4_STATE_XATTR   0x0004 /* has in-inode xattrs */
+#define EXT4_STATE_BLOCKS_RESERVED 0x0008 /* blocks reserved */
 
 /* Used to pass group descriptor data when online resize is done */
 struct ext4_new_group_input {
@@ -808,6 +809,10 @@ extern struct ext4_group_desc * ext4_get
 extern int ext4_should_retry_alloc(struct super_block *sb, int *retries);
 extern void ext4_init_block_alloc_info(struct inode *);
 extern void ext4_rsv_window_add(struct super_block *sb, struct 
ext4_reserve_window_node *rsv);
+int ext4_reserve_init(struct super_block *sb);
+void ext4_reserve_release(struct super_block *sb);
+void ext4_release_blocks(struct super_block *sb, int blocks);
+int ext4_reserve_blocks(struct super_block *sb, int blocks);
 
 /* dir.c */
 extern int ext4_check_dir_entry(const char *, struct inode *,
Index: linux-2.6.20-rc1/include/linux/ext4_fs_sb.h
===
--- linux-2.6.20-rc1.orig/include/linux/ext4_fs_sb.h2006-12-14 
04:14:23.0 +0300
+++ linux-2.6.20-rc1/include/linux/ext4_fs_sb.h 2006-12-22 20:20:10.0 
+0300
@@ -24,6 +24,8 @@
 #endif
 #include 
 
+struct ext4_reservation_slot;
+
 /*
  * third extended-fs super-block data in memory
  */
@@ -65,6 +67,9 @@ struct ext4_sb_info {
struct rb_root s_rsv_window_root;
struct ext4_reserve_window_node s_rsv_window_head;
 
+   /* global reservation structures */
+   struct ext4_reservation_slot *s_reservation_slots;
+
/* Journaling */
struct inode * s_journal_inode;
struct journal_s * s_journal;
Index: linux-2.6.20-rc1/fs/ext4/super.c
===
--- linux-2.6.20-rc1.orig/fs/ext4/super.c   2006-12-14 04:14:23.0 
+0300
+++ linux-2.6.20-rc1/fs/ext4/super.c2006-12-22 20:20:10.0 +0300
@@ -439,6 +439,7 @@ static void ext4_put_super (struct super
struct ext4_super_block *es = sbi->s_es;
int i;
 
+   ext4_reserve_release(sb);
ext4_ext_release(sb);
ext4_xattr_put_super(sb);
jbd2_journal_destroy(sbi->s_journal);
@@ -1867,6 +1868,7 @@ static int ext4_fill_super (struct super
"writeback");
 
ext4_ext_init(sb);
+   ext4_reserve_init(sb);
 
lock_kernel();
return 0;
Index: linux-2.6.20-rc1/fs/ext4/balloc.c
===
--- linux-2.6.20-rc1.orig/fs/ext4/balloc.c  2006-12-14 04:14:23.0 
+0300
+++ linux-2.6.20-rc1/fs/ext4/balloc.c   2006-12-22 20:32:11.0 +0300
@@ -630,8 +630,10 @@ void ext4_free_blocks(handle_t *handle, 
return;
}
ext4_free_blocks_sb(handle, sb, block, count, _freed_blocks);
-   if (dquot_freed_blocks)
+   if (dquot_freed_blocks) {
+   ext4_release_blocks(sb, dquot_freed_blocks);
DQUOT_FREE_BLOCK(inode, dquot_freed_blocks);
+   }
return;
 }
 
@@ -1440,7 +1442,7 @@ ext4_fsblk_t ext4_new_blocks(handle_t *h
struct ext4_sb_info *sbi;
struct ext4_reserve_window_node *my_rsv = NULL;
struct ext4_block_alloc_info *block_i;
-   unsigned short windowsz = 0;
+   unsigned short windowsz = 0, reserved = 0;
 #ifdef EXT4FS_DEBUG
static int goal_hits, goal_attempts;
 #endif
@@ -1462,6 +1464,13 @@ ext4_fsblk_t ext4_new_blocks(handle_t *h
return 0;
}
 
+   if (!(EXT4_I(inode)->i_state & EXT4_STATE_BLOCKS_RESERVED)) {
+   *errp = ext4_reserve_blocks(sb, num);
+   if (*errp)
+   return 0;
+   reserved = num;
+   }
+
sbi = EXT4_SB(sb);
es = EXT4_SB(sb)->s_es;
ext4_debug("goal=%lu.\n", goal);
@@ -1674,8 +1683,11 @@ out:
/*
 * Undo the block allocation
 */
-   if (!performed_allocation)
+   if (!performed_allocation) {
DQUOT_FREE_BLOCK(inode, *count);
+   if (reserved)
+   ext4_release_blocks(sb, reserved);
+   }
brelse(bitmap_bh);
return 0;
 }
@@ -1834,3 +1846,161 @@ unsigned long ext4_bg_num_gdb(struct sup
return ext4_bg_num_gdb_meta(sb,group);
 
 }
+
+/*
+ * reservation.c contains routines to reserve blocks.
+ * we need this for delayed allocation, otherwise we
+ * could meet -ENOSPC at flush time
+ */
+
+/*
+ * as ->commit_write() where we're going to reserve
+ * 

[RFC] ext4-delayed-allocation.patch

[Alex Tomas]

Index: linux-2.6.20-rc1/include/linux/ext4_fs_i.h
===
--- linux-2.6.20-rc1.orig/include/linux/ext4_fs_i.h 2006-12-14 
04:14:23.0 +0300
+++ linux-2.6.20-rc1/include/linux/ext4_fs_i.h  2006-12-22 22:56:04.0 
+0300
@@ -153,6 +153,11 @@ struct ext4_inode_info {
 
unsigned long i_ext_generation;
struct ext4_ext_cache i_cached_extent;
+
+   __u32 i_blocks_reserved;
+   __u32 i_md_reserved;
+   spinlock_t i_wb_reserved_lock;  /* to protect i_md_reserved */
+   atomic_t i_wb_writers;
 };
 
 #endif /* _LINUX_EXT4_FS_I */
Index: linux-2.6.20-rc1/include/linux/ext4_fs.h
===
--- linux-2.6.20-rc1.orig/include/linux/ext4_fs.h   2006-12-22 
22:56:03.0 +0300
+++ linux-2.6.20-rc1/include/linux/ext4_fs.h2006-12-22 22:56:04.0 
+0300
@@ -401,6 +401,7 @@ struct ext4_inode {
 #define EXT4_MOUNT_USRQUOTA0x10 /* "old" user quota */
 #define EXT4_MOUNT_GRPQUOTA0x20 /* "old" group quota */
 #define EXT4_MOUNT_EXTENTS 0x40 /* Extents support */
+#define EXT4_MOUNT_DELAYED_ALLOC   0x100/* Delayed allocation support 
*/
 
 /* Compatibility, for having both ext2_fs.h and ext4_fs.h included at once */
 #ifndef _LINUX_EXT2_FS_H
@@ -994,6 +995,18 @@ ext4_get_blocks_wrap(handle_t *handle, s
 }
 
 
+/* writeback.c */
+extern int ext4_wb_writepages(struct address_space *, struct writeback_control 
*);
+extern int ext4_wb_prepare_write(struct file *file, struct page *page,
+ unsigned from, unsigned to);
+extern int ext4_wb_commit_write(struct file *, struct page *, unsigned, 
unsigned);
+extern int ext4_wb_writepage(struct page *, struct writeback_control *);
+extern void ext4_wb_invalidatepage(struct page *, unsigned long);
+extern int ext4_wb_releasepage(struct page *, gfp_t);
+extern int ext4_wb_block_truncate_page(handle_t *, struct page *, struct 
address_space *, loff_t);
+extern void ext4_wb_init(struct super_block *);
+extern void ext4_wb_release(struct super_block *);
+
 #endif /* __KERNEL__ */
 
 #endif /* _LINUX_EXT4_FS_H */
Index: linux-2.6.20-rc1/include/linux/ext4_fs_sb.h
===
--- linux-2.6.20-rc1.orig/include/linux/ext4_fs_sb.h2006-12-22 
22:56:03.0 +0300
+++ linux-2.6.20-rc1/include/linux/ext4_fs_sb.h 2006-12-22 22:56:04.0 
+0300
@@ -94,6 +94,17 @@ struct ext4_sb_info {
unsigned long s_ext_blocks;
unsigned long s_ext_extents;
 #endif
+
+   atomic_t s_wb_congested;
+   atomic_t s_wb_single_pages;
+   atomic_t s_wb_collisions_sp;
+   atomic_t s_wb_allocated;
+   atomic_t s_wb_reqs;
+   atomic_t s_wb_nr_to_write;
+   atomic_t s_wb_collisions;
+   atomic_t s_wb_blocks;
+   atomic_t s_wb_extents;
+   atomic_t s_wb_dropped;
 };
 
 #endif /* _LINUX_EXT4_FS_SB */
Index: linux-2.6.20-rc1/include/linux/ext4_fs_extents.h
===
--- linux-2.6.20-rc1.orig/include/linux/ext4_fs_extents.h   2006-12-14 
04:14:23.0 +0300
+++ linux-2.6.20-rc1/include/linux/ext4_fs_extents.h2006-12-22 
22:56:04.0 +0300
@@ -193,6 +193,7 @@ extern int ext4_ext_calc_credits_for_ins
 extern int ext4_ext_insert_extent(handle_t *, struct inode *, struct 
ext4_ext_path *, struct ext4_extent *);
 extern int ext4_ext_walk_space(struct inode *, unsigned long, unsigned long, 
ext_prepare_callback, void *);
 extern struct ext4_ext_path * ext4_ext_find_extent(struct inode *, int, struct 
ext4_ext_path *);
+int ext4_ext_calc_metadata_amount(struct inode *inode, int blocks);
 
 #endif /* _LINUX_EXT4_EXTENTS */
 
Index: linux-2.6.20-rc1/fs/ext4/super.c
===
--- linux-2.6.20-rc1.orig/fs/ext4/super.c   2006-12-22 22:56:03.0 
+0300
+++ linux-2.6.20-rc1/fs/ext4/super.c2006-12-22 22:56:04.0 +0300
@@ -439,6 +439,7 @@ static void ext4_put_super (struct super
struct ext4_super_block *es = sbi->s_es;
int i;
 
+   ext4_wb_release(sb);
ext4_reserve_release(sb);
ext4_ext_release(sb);
ext4_xattr_put_super(sb);
@@ -506,6 +507,13 @@ static struct inode *ext4_alloc_inode(st
ei->i_block_alloc_info = NULL;
ei->vfs_inode.i_version = 1;
memset(>i_cached_extent, 0, sizeof(struct ext4_ext_cache));
+
+   /* FIXME: these wb-related fields could be initialized once */
+   ei->i_blocks_reserved = 0;
+   ei->i_md_reserved = 0;
+   atomic_set(>i_wb_writers, 0);
+   spin_lock_init(>i_wb_reserved_lock);
+
return >vfs_inode;
 }
 
@@ -729,7 +737,7 @@ enum {
Opt_usrjquota, Opt_grpjquota, Opt_offusrjquota, Opt_offgrpjquota,
Opt_jqfmt_vfsold, Opt_jqfmt_vfsv0, Opt_quota, Opt_noquota,
Opt_ignore, 

[RFC] booked-page-flag.patch

[Alex Tomas]

Index: linux-2.6.20-rc1/include/linux/page-flags.h
===
--- linux-2.6.20-rc1.orig/include/linux/page-flags.h2006-12-14 
04:14:23.0 +0300
+++ linux-2.6.20-rc1/include/linux/page-flags.h 2006-12-22 20:05:31.0 
+0300
@@ -90,6 +90,7 @@
 #define PG_reclaim 17  /* To be reclaimed asap */
 #define PG_nosave_free 18  /* Used for system suspend/resume */
 #define PG_buddy   19  /* Page is free, on buddy lists */
+#define PG_booked  20  /* Has blocks reserved on-disk */
 
 
 #if (BITS_PER_LONG > 32)
@@ -230,6 +231,10 @@ static inline void SetPageUptodate(struc
 #define SetPageMappedToDisk(page) set_bit(PG_mappedtodisk, &(page)->flags)
 #define ClearPageMappedToDisk(page) clear_bit(PG_mappedtodisk, &(page)->flags)
 
+#define PageBooked(page)   test_bit(PG_booked, &(page)->flags)
+#define SetPageBooked(page)set_bit(PG_booked, &(page)->flags)
+#define ClearPageBooked(page)  clear_bit(PG_booked, &(page)->flags)
+
 #define PageReclaim(page)  test_bit(PG_reclaim, &(page)->flags)
 #define SetPageReclaim(page)   set_bit(PG_reclaim, &(page)->flags)
 #define ClearPageReclaim(page) clear_bit(PG_reclaim, &(page)->flags)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] delayed allocation for ext4

[Alex Tomas]

Good day,

probably the previous set of patches (including mballoc/lg)
is too large. so, I reworked delayed allocation a bit so
that it can be used on top of regular balloc, though it
still can be used with extents-enabled files only.

this time series contains just 3 patches:

 - booked-page-flag.patch
   adds PG_booked bit to page->flags. it's used in delayed
   allocation to mark space is already reserved for page
   (including possible metadata)

 - ext4-block-reservation.patch
   this is scalable free space management. every time we
   delay allocation of some page, a space (including metadata)
   should be reserved

 - ext4-delayed-allocation.patch
   delayed allocation itself, enabled by "delalloc" mount option.
   extents support is also required. currently it works only
   with blocksize=pagesize.


all the patches can be used in 
ftp://ftp.clusterfs.com/pub/people/alex/2.6.20-rc1/

the series passed basic tests like dd/dbench/fsx.

any comments/questions are very welcome.

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

Re: parse-boot-parameter-error.patch breaks UML

[Andrew Morton]

On Fri, 22 Dec 2006 15:53:38 -0500
Jeff Dike <[EMAIL PROTECTED]> wrote:

> >From the changelog:
> 
>   Say a boot parameter is "xxx", if you give a string "xxxy", then the
>   boot parameter's corresponding function is executed.
> 
> UML has parameters such as "ubda=" which are matched by
> __setup("ubd", ubd_setup), which hits the "error" case this patch now
> outlaws.
> 

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

Re: [PATCH 2.6.20-rc1] xfrm: Algorithm lookup using .compat name

[Herbert Xu]

On Fri, Dec 22, 2006 at 05:26:43PM +0100, Martin Willi wrote:
> Installing an IPsec SA using old algorithm names (.compat) does not work
> if the algorithm is not already loaded. When not using the PF_KEY
> interface, algorithms are not preloaded in xfrm_probe_algs() and
> installing a IPsec SA fails.

Good catch.  Thanks Martin!
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: two architectures,same source tree

[Randy Dunlap]

On Fri, 22 Dec 2006 21:45:26 +0100 Bodo Eggert wrote:

> Jörn Engel <[EMAIL PROTECTED]> wrote:
> > On Wed, 20 December 2006 20:32:20 +0200, Yakov Lerner wrote:
> 
> >> Is it easily possible to build two architectures in
> >> the same source tree (so that intermediate fles
> >> and resut files do not interfere ) ?
> > 
> > I'd try something like this:
> > make O=../foo ARCH=foo
> > make O=../bar ARCH=bar
> > 
> > But as I'm lazy I'll leave the debugging to you. :)
> 
> IIRC You'll have to specify ARCH= on each make call, but O= is saved in
> ../foo/Makefile.

Hm, top-level README file says:

   Please note: If the 'O=output/dir' option is used then it must be
   used for all invocations of make.


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

parse-boot-parameter-error.patch breaks UML

[Jeff Dike]

>From the changelog:

Say a boot parameter is "xxx", if you give a string "xxxy", then the
boot parameter's corresponding function is executed.

UML has parameters such as "ubda=" which are matched by
__setup("ubd", ubd_setup), which hits the "error" case this patch now
outlaws.

Jeff

-- 
Work email - jdike at linux dot intel dot 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: two architectures,same source tree

[Bodo Eggert]

Jörn Engel <[EMAIL PROTECTED]> wrote:
> On Wed, 20 December 2006 20:32:20 +0200, Yakov Lerner wrote:

>> Is it easily possible to build two architectures in
>> the same source tree (so that intermediate fles
>> and resut files do not interfere ) ?
> 
> I'd try something like this:
> make O=../foo ARCH=foo
> make O=../bar ARCH=bar
> 
> But as I'm lazy I'll leave the debugging to you. :)

IIRC You'll have to specify ARCH= on each make call, but O= is saved in
../foo/Makefile.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

http://david.woodhou.se/why-not-spf.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: Possible race condition in usb-serial.c

[J]

> No, this is a fundamental problem. You don't
> refcount
> a pointer, you refcount a data structure.
> But this is insufficient. We need to make 
> sure the pointer points to valid memory.

I understand. But a typical definition of ref-count 
requires the count in the data structure to be
equal to the number of outstanding pointers to this
data structure.
Every time we create a new pointer, the ref count
should be incremented. When pointer is erased, count
is decremented. 
This is what I meant as "ref counting a pointer".
If we follow this rule, then each pointer will
always point to a valid memory.

So, if we apply ref counting rules consistently,
then each pointer in serial_table should be
ref counted. This will completely break the current
code, which erases serial_table from destroy_serial,
which is called only when the ref count goes to 0,
which will never happen if serial_table is ref
counted.
However, this can be fixed if usb_serial_disconnect
will erase pointers in serial_table before
calling usb_serial_put.

Now, I am not yet 100% convinced that ref counting
will, indeed, work. Atomics are known to have
problems on SMP CPUs, which can reorder operations.
But I would not discard atomics yet.
Global mutex is go ugly.

John


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.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.6.20-rc1 6/6] input: ads7846 directly senses PENUP state

[David Brownell]

On Friday 22 December 2006 12:35 pm, Dmitry Torokhov wrote:
> On 12/22/06, David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > +static void ads7846_report_pen_state(struct ads7846 *ts, int down)
> > +{
> > +   struct input_dev*input_dev = ts->input;
> > +
> > +   input_report_key(input_dev, BTN_TOUCH, down);
> > +   if (!down)
> > +   input_report_abs(input_dev, ABS_PRESSURE, 0);
> > +#ifdef VERBOSE
> > +   pr_debug("%s: %s\n", ts->spi->dev.bus_id, down ? "DOWN" : "UP");
> > +#endif
> > +}
> > +
> > +static void ads7846_report_pen_position(struct ads7846 *ts, int x, int y,
> > +   int pressure)
> > +{
> > +   struct input_dev*input_dev = ts->input;
> > +
> > +   input_report_abs(input_dev, ABS_X, x);
> > +   input_report_abs(input_dev, ABS_Y, y);
> > +   input_report_abs(input_dev, ABS_PRESSURE, pressure);
> > +
> > +#ifdef VERBOSE
> > +   pr_debug("%s: %d/%d/%d\n", ts->spi->dev.bus_id, x, y, pressure);
> > +#endif
> > +}
> > +
> > +static void ads7846_sync_events(struct ads7846 *ts)
> > +{
> > +   struct input_dev*input_dev = ts->input;
> > +
> > +   input_sync(input_dev);
> > +}
> 
> I think these helpers just obfuscate the code, just call
> input_report_*() and input_sync() drectly like you used to do.

Fair enough, I had a similar thought.  Imre, could you do that update?


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

Re: [patch 2.6.20-rc1 6/6] input: ads7846 directly senses PENUP state

[Dmitry Torokhov]

On 12/22/06, David Brownell <[EMAIL PROTECTED]> wrote:


+static void ads7846_report_pen_state(struct ads7846 *ts, int down)
+{
+   struct input_dev*input_dev = ts->input;
+
+   input_report_key(input_dev, BTN_TOUCH, down);
+   if (!down)
+   input_report_abs(input_dev, ABS_PRESSURE, 0);
+#ifdef VERBOSE
+   pr_debug("%s: %s\n", ts->spi->dev.bus_id, down ? "DOWN" : "UP");
+#endif
+}
+
+static void ads7846_report_pen_position(struct ads7846 *ts, int x, int y,
+   int pressure)
+{
+   struct input_dev*input_dev = ts->input;
+
+   input_report_abs(input_dev, ABS_X, x);
+   input_report_abs(input_dev, ABS_Y, y);
+   input_report_abs(input_dev, ABS_PRESSURE, pressure);
+
+#ifdef VERBOSE
+   pr_debug("%s: %d/%d/%d\n", ts->spi->dev.bus_id, x, y, pressure);
+#endif
+}
+
+static void ads7846_sync_events(struct ads7846 *ts)
+{
+   struct input_dev*input_dev = ts->input;
+
+   input_sync(input_dev);
+}


I think these helpers just obfuscate the code, just call
input_report_*() and input_sync() drectly like you used to do.

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

Re: [patch 2.6.20-rc1 3/6] input: ads7846 more compatible with hwmon

[Dmitry Torokhov]

On 12/22/06, David Brownell <[EMAIL PROTECTED]> wrote:

Be more compatible with the hwmon framework:

 - Hook up to hwmon
* show sensor attrubites only if hwmon is present
* otherwise be just a touchscreen
 - Report voltages per hwmon convention
* measure in millivolts
* voltages are named in[0-8]_input (ugh)
* for 7846 chips, properly range-adjust vBATT/in1_input


There are too many #ifdefs. Please consider creating
ads7846_[un]register_hwmon() and use them in
ads7846_probe()/ads7846_remove(). Split hwmon related attributes into
a separate attribute group and move everything in #ifdef CONFIG_HWMON
block.


+ *
+ * FIXME make external vREF_mV be a module option, and use that as needed...
 */
+static const unsigned vREF_mV = 2500;



Why don't you make it mdule option right away?

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

Re: [PATCH] input/spi: add ads7843 support to ads7846 touchscreen driver

[Dmitry Torokhov]

On 12/22/06, David Brownell <[EMAIL PROTECTED]> wrote:

On Thursday 21 December 2006 5:08 am, Nicolas Ferre wrote:

> > Let me try to sort out the mess with those updates, and ask you to refresh
> > this ads7843 support against that more-current ads7846 code.
>
> Ok, let me know when you have a newer code. I will try to adapt my
> ads7843 support then.

I just sent these updates to LKML ... though the address I had for Dmitry
sees to have gone bad, I do see all six patches in the list archives.



I changed my ISP. Please use either:

[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

The last one may go bad if I ever change ISP again but I intend to
keep the first 2 indefinitely.

I'll fish the patches from LKML.

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

Re: [PATCH] input/spi: add ads7843 support to ads7846 touchscreen driver

[David Brownell]

On Thursday 21 December 2006 6:40 am, Nicolas Ferre wrote:
> Nicolas Ferre a écrit :
> >>> As the SPI underlying code behaves quite differently from a 
> >>> controller driver to another whan not having a tx_buf filled,
> >>> I have add a zerroed buffer to give to the spi layer while
> >>> receiving data. 
> >>
> >> You must be working with a buggy controller driver then.  That part of
> >> this patch should never be needed.  It's expected that rx-only transfers
> >> will omit a tx buf; all controller drivers must handle that case.
> > 
> > I said that because it is true that most of spi controller drivers 
> > manage rx only transactions filling the tx buffer with zerros but the 
> > spi_s3c24xx.c driver seems to fill with ones (line 177 hw_txbyte())
> > 
> > Anyway, I will check in our controller driver to sort this out.
> 
> I dug a bit into this.

I always like to see followup on such issues.  :)


> Well, in the atmel_spi driver code, we use previous rx buffer if we do 
> not provide a tx_buf (as it is said that in struct spi_transfer 
> comments,  "If the transmit buffer is null, undefined data will be 
> shifted out while filling rx_buf").

That seems like a reasonable approach.  If it's undefined, the only
reasons I can think of to not use the rx buffer are that:

 (a) the cachelines might not be managed correctly during DMA ...
 i.e. to defend against a bug in the controller driver; and
 (b) that writing such _defined_ data would be a "covert channel"
 in the security sense.

Now, (a) is just a bug to fix, and in most cases (b) won't be an
issue since even if the system with that driver is being evaluated
at a level where such channels matter, the hardware hooked up via
SPI will probably already be trusted.  (Unless the system allows
thing like MMC or SD cards...)  However, see below.


> So, the touchscreen controller sees sometimes a "start" condition (bit 7 
> of a control byte). It then takes the control byte and sets trash bits 
> as a configuration.

Actually, now that I look at it I see that the docs for both the
ads7846 and the ads7843 show that DIN/MOSI should be zero/low
after the command is given, while reading DOUT/MISO.

Which means that the real issue here is that the driver was wrong
in the first place to not explicitly write zeroes while it's reading
back that data.

The testing I've done with it involved two controller drivers which
do happen to interpret "undefined" as "write zeros":  omap_uwire,
which I'm guessing does so in hardware (MicroWire is half duplex),
and pxa2xx_spi, which explicitly writes zeros (null_writer).


> I ran into those troubles and add a zerroed buffer as tx.
> 
> Do you think that shifting zerros out when a tx_buf is not specified is 
> the desired behavior ?

I'm leaning towards a "yes" there -- changing the spec for spi_transfer.

The alternative would seem to mean teaching the SPI interface about
two different kinds of "rx only" transfers, one with "must tx zero"
semantics and the other with "tx data doesn't matter" (and security
audits would define it anyway, to avoid covert channels).  And I can't
easily justify that.

For now, I'd suggest you update the atmel_spi driver so that it shifts
zeroes in that case; can't hurt (too much).  And I'll forward the issue
to the SPI list.  If nobody there objects, I'll send patches to update
the spec for spi_transfer, and the s3c driver.

- Dave

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

Re: [patch] change WARN_ON back to "BUG: at ..."

[Andrew Morton]

I've always felt that it is wrong (or at least misleading) that WARN_ON
prints "BUG".  It would have been better if it had said "WARNING", and only
BUG_ON says "BUG".

But lots of people have now written downstream log-parsing tools which
might break due to this change, so I'm inclined to go with Ingo's patch,
and restore the old (il)logic.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Relay CPU Hotplug support

[Gautham R Shenoy]

On Fri, Dec 22, 2006 at 02:44:58AM -0800, Andrew Morton wrote:
> On Fri, 22 Dec 2006 16:07:24 +0530
> Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> 
> > While we are at this per-subsystem cpuhotplug "locking", here's a
> > proposal that might put an end to the workqueue deadlock woes.
> 
> Oleg is working on some patches which will permit us to cancel or wait upon
> a particular work_struct, rather than upon all pending work_structs.
>

Oh! I was refering to the other set of workqueue deadlock woes. The
ones caused when subsystems (like cpufreq) try to create/destroy
workqueue from the cpuhotplug callback path. 

Creation/destruction of workqueue requires us to take workqueue_mutex,
which would have already been taken during CPU_LOCK_ACQUIRE.

More often than not, the cpu hotplug protection that we need
is while accessing either cpu_online_map OR one of it's persubsystem
mirrors like policy->cpus. 
So it makes more sense to have all the persubsystem 
mutexes held only during the cpu-hotplug operation (i.e stop_machine_run
and __cpu_up) and release them immediately after sending notifications to
update the persubsystem online_cpu map.

Thanks and Regards
gautham.
-- 
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Possible race condition in usb-serial.c

[Oliver Neukum]

Am Freitag, 22. Dezember 2006 20:08 schrieb J:
> > This problem will need some deeper surgery probably
> > involving
> > removal of the refcounting.
> 
> Refcounting may be OK if used consistently. 
> It is not OK when some pointers are ref-counted, 
> but other (in serial_table) are not (like it is
> in the current version).

No, this is a fundamental problem. You don't refcount
a pointer, you refcount a data structure. But this is
insufficient. We need to make sure the pointer points to valid
memory.
The problem with the current scheme is that serial_table
needs a lock. It needs to be taken in four places
- disconnect()
- open()
- probe()
- read_proc()

Refcounting solves only the race between disconnect() and close()
There's little use in a second locking mechanism if you use it
only in a minority of occasions.
Refcounting is a great idea if the number of references follows
a clear up -> maximum -> down -> free scheme, like for
skbs, etc..

> 
> As for the deeper surgery, what do you think about my
> earlier suggestion to start by rewriting
> usb_serial_probe
> to fully initialize usb_serial before it is added to 
> serial_table? 

Good suggestion. However, if done right, we'd go for a spin lock.

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

Re: omap compilation fixes

[Tony Lindgren]

Hi,

* Russell King <[EMAIL PROTECTED]> [061222 03:51]:
> On Fri, Dec 22, 2006 at 01:35:31PM +0200, Komal Shah wrote:
> > On 12/22/06, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > >Hi!
> > >
> > >This is not yet complete set. set_map() is missing in latest kernels.
> > >
> > >Fix DECLARE_WORK()-change-related compilation problems. Please apply,
> > >
> > >Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
> > >
> > 
> > Please check linux-omap-open-source mailing list. Some of the build
> > breakage patches are already posted regarding to latest kernel sync
> > up.
> > 
> > http://linux.omap.com/pipermail/linux-omap-open-source
> 
> There are a set of omap patches in the patch system, but they were too
> late for me to merge within the 2 week window - there were additional
> delays caused by the accidental attempt to merge the silly ATAG_BOARD
> stuff which I had previously refused.
> 
> Tony needs to either create a git tree containing strictly just fixes
> suitable for -rc kernels, or submit them as individual patches.

Yeah, I'll put together a set of fixes shortly, and will keep the
larger merge set for post 2.6.20.

Regards,

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

Re: moxa serial driver testing

[Jiri Slaby]

[EMAIL PROTECTED] wrote:
> Hi Jiri,
> 
> I've figured out that both old and new mxser drivers have two similar
> problems:
> 
> 1. When there are data coming to a port, sometimes opening of the port
>entirely locks the box. This is quite reproducible. Any idea what's
>wrong and how can I help to debug it?

Please enable
* Lock debugging: prove locking correctness
* Lock dependency engine debugging
at Kernel hacking->Kernel debugging

> 2. Another, less important problem, is that if a port is open by some
>application and I rmmod the mxser (or mxser-new) module, kernel
>oopses and gets unstable ("xjterm" is the process that keeps the port
>open):

I'll look into that.

> Couldn't unregister MOXA Smartio/Industio family serial driver
> BUG: unable to handle kernel paging request at virtual address f0fe60be
>  printing eip:
> f0fe60be
> *pde = 3fc04067
> *pte = 
> Oops:  [#1]
> SMP 
> Modules linked in: nvidia agpgart ipv6 nfs lockd nfs_acl sunrpc dm_mod
> sr_mod sbp2 ieee1394 ide_generic ide_disk e1000 snd_hda_intel
> snd_hda_codec psmouse i2c_i801 mousedev snd_pcm_oss snd_mixer_oss
> serio_raw i2c_core tsdev 8250_pnp pcspkr parport_pc evdev snd_pcm
> 8250_pci parport snd_timer rtc floppy snd soundcore snd_page_alloc ext3
> jbd mbcache sd_mod usb_storage usbhid ide_cd cdrom uhci_hcd ata_piix
> libata usbcore piix scsi_mod generic ide_core skge thermal processor fan
> CPU:0
> EIP:0060:[]Tainted: P  VLI
> EFLAGS: 00210246   (2.6.17-2-686 #1) 
> EIP is at 0xf0fe60be
> eax: ebc8c800   ebx: ebc8c800   ecx:    edx: efe4e400
> esi:    edi: e2877a80   ebp: ebc8c80c   esp: d924dbf8
> ds: 007b   es: 007b   ss: 0068
> Process xjterm (pid: 11884, threadinfo=d924c000 task=e6835a90)
> Stack: b01f550c 00123fc3 ebc8c800 b01f5418 e2877a80 b01f170a  
>  
>0020 e2877a80 d924de98 d924dea8 b0162749 d924dfb0 080e8de0 
> 080e8df8 
>d924de98 d924de98  0003 d924deb0 0002  
> d924de98 
> Call Trace:
>   normal_poll+0xf4/0x119   normal_poll+0x0/0x119
>   tty_poll+0x48/0x60   do_sys_poll+0x1af/0x342
>   __pollwait+0x0/0xb2   default_wake_function+0x0/0xc
>   default_wake_function+0x0/0xc   
> default_wake_function+0x0/0xc
>   default_wake_function+0x0/0xc   _nv002668rm+0x26/0x2c 
> [nvidia]
>   __alloc_pages+0x4e/0x267   activate_task+0x5a/0xa0
>   __activate_task+0x17/0x1d   try_to_wake_up+0x319/0x323
>   activate_task+0x5a/0xa0   __activate_task+0x17/0x1d
>   try_to_wake_up+0x319/0x323   __wake_up_common+0x2f/0x53
>   __wake_up+0x2a/0x3d   sock_def_readable+0x31/0x5b
>   unix_stream_sendmsg+0x200/0x2c4   
> do_sock_write+0xa3/0xaa
>   sock_aio_write+0x53/0x61   do_sync_write+0xb8/0xf3
>   autoremove_wake_function+0x0/0x2d   unix_ioctl+0x8b/0x93
>   sock_ioctl+0x193/0x1b5   sock_ioctl+0x0/0x1b5
>   do_ioctl+0x1c/0x5d   vfs_ioctl+0x24a/0x25c
>   sys_poll+0x44/0x47   sysenter_past_esp+0x54/0x75
> Code:  Bad EIP value.
> EIP: [] 0xf0fe60be SS:ESP 0068:d924dbf8
>  
> Note: I'm running Debian kernel 2.6.17.2 but I've seen the same problem
> on 2.6.16.x. Didn't try more recent kernels though. CPU is
> hyper-threaded Pentium-4.

thanks for the report,
-- 
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: Binary Drivers

[Rok Markovic]

Hi!

Maybe this does not belong to this thread, but I am wondering why
manufactorers doesn't want to release specifications about drivers.
They have decided to develop some hardware for, let say 3D accelaration.
Now they are selling hardware and users are buying hardware. Users are
not buying hardware because they want to run mighty drivers, they want
to use hardware.

1. Why they do not reveal spec. if user allready bought hardware, though
   they give driver for free but not specs.

2. Who can contribute if they reveal specifications (how to use hardware) ?


Can anyone answer does questions?

PS: I am not talking about NVIDIA and ATI, but let's say intel and
2700G multimedia accelerator IC. They sell IC without specifications
how to use it!?


Cheers,
Rok Markovic

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

Re: [dm-devel] Re: [RFC PATCH 2/8] rqbased-dm: add block layer hook

[Kiyoshi Ueda]

Hi Mike,

On Fri, 22 Dec 2006 01:18:44 -0600, Mike Christie <[EMAIL PROTECTED]> wrote:
> > In addition to the suggested approach, what do you think about
> > adding a new flag to req->cmd_flags which lets the end_io() handler
> > not to return bio to upper layer?
> > It will be useful for multipathing and can be done even within
> > the current __end_that_request_first().
> > For example,
> > 
> > static int __end_that_request_first()
> > {
> > .
> > error = 0;
> > if (end_io_error(uptodate))
> > error = !uptodate ? -EIO : uptodate;
> > .
> > if (error && (req->cmd_flags & "NEW_FLAG"))
> > return 0; /* Tell the driver to call end_that_request_last() */
> > 
> > total_types = bio_nbytes = 0;
> > while ((bio = req->bio) != NULL) {
> > . /* process of finishing bios */
> > }
> > .
> > }
> > 
> 
> Who would call end_that_request_first with the new flag set? The scsi
> layer or multipath layer?

Multipath layer sets the new flag.
SCSI layer of an underlying device calls __end_that_request_first()
for a cloned request.  And original bios which were issued to a dm
device will be completed through the cloned request when no error
occurs on the clone.  When an error occurs, the completion process of
the bios are skipped.

Thanks,
Kiyoshi Ueda

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

[Randy Dunlap]

On Mon, 18 Dec 2006 00:11:33 -0700 Grant Grundler wrote:

> Full version of pci.txt (v6 is 677 lines):
>   http://www.parisc-linux.org/~grundler/Documentation/pci.txt-06
> 
> I've appended patch v6 (823 lines!) and commit log entry is below.
> 
> 
> 
> diff --git a/Documentation/pci.txt b/Documentation/pci.txt
> index 2b395e4..dce829e 100644
> --- a/Documentation/pci.txt
> +++ b/Documentation/pci.txt
> @@ -1,147 +1,235 @@
> -  How To Write Linux PCI Drivers
>  
> -by Martin Mares <[EMAIL PROTECTED]> on 07-Feb-2000
> + How To Write Linux PCI Drivers
> +
> + by Martin Mares <[EMAIL PROTECTED]> on 07-Feb-2000
> + updatedby Grant Grundler <[EMAIL PROTECTED]> on 17-Dec-2006

updated by
>  
> 

> +pci_register_driver() leaves most of the probing for devices to
> +the PCI layer and supports online insertion/removal of devices [thus
> +supporting PCI, hot-pluggable PCI and CardBus in a single driver].

ExpressCard ?

> +pci_register_driver() call requires passing in a table of function
> +calls and thus dictates the high level structure of a driver.

s/calls/pointers/ ?

> +
> +Once the driver knows about a PCI device and takes ownership, the
> +driver generally needs to perform the following initialization:
>  
>   Enable the device
> - Access device configuration space
> - Discover resources (addresses and IRQ numbers) provided by the device
> - Allocate these resources
> - Communicate with the device
> + request MMIO/IOP resources
> + set the DMA mask size (for both coherent and streaming DMA)
> + allocate and initialize shared control data (pci_allocate_coherent())
> + Access device configuration space (if needed)
> + register IRQ handler (request_irq())
> + Initialize non-PCI (ie LAN/SCSI/etc parts of the chip)
> + enable DMA/processing engines.

Please capitalize the first word of each list item.
(i.e., be consistent)

> +When done using the device, and perhaps the module needs to be unloaded,
> +the driver needs to take the follow steps:
> + disable the device from generating IRQs
> + release the IRQ (free_irq())
> + stop all DMA activity
> + release DMA buffers (both streaming and coherent)
> + unregister from other subsystems (e.g. scsi or netdev)
> + release MMIO/IOP resources
>   Disable the device

Be consistent.

> +1. pci_register_driver() call
> +~
> +PCI device drivers call pci_register_driver() during their
> +initialization with a pointer to a structure describing the driver
> +(struct pci_driver):
> +
> + field name  Description
> + --  --
> + shutdownHook into reboot_notifier_list (kernel/sys.c).
> + Intended to stop any idling DMA operations.
> + Useful for enabling wake-on-lan (NIC) or change

s/change/changing/ or /to change/

> + the power state of a device before reboot.
> + e.g. drivers/net/e100.c.
> +
> + multithread_probe   Enable multi-threaded probe/scan. Driver is
> + required to provide it's own locking/syncronization

s/it's/its/
s/syncronization/synchronization/

> + for init operations if this is enabled.
> +
> +
> +The ID table is an array of struct pci_device_id entries ending with an
> +all-zero entry.  Each entry consists of:
> +
> + vendor,device   Vendor and device ID to match (or PCI_ANY_ID)
>  
>   subvendor,  Subsystem vendor and device ID to match (or PCI_ANY_ID)
> + subdevice,
> +
>  
>  
> +
> +1.1 "Marks" for driver functions/data

Markers, Attributes, Tags ?  (I prefer Attributes.)

> +
>  Please mark the initialization and cleanup functions where appropriate
>  (the corresponding macros are defined in ):
>  
>  
> +2. How to find PCI devices manually
> +~~~
> +
> +A manual search may be performed using the following constructs:
>  
>  Searching by vendor and device ID:
>  
> - struct pci_dev *dev = NULL;
> - while (dev = pci_get_device(VENDOR_ID, DEVICE_ID, dev))
> + structpci_dev *dev = NULL;

missing some spaces:

struct pci_dev

> + while(dev = pci_get_device(VENDOR_ID, DEVICE_ID, dev))

while (

>   configure_device(dev);
>  
> +3. Device Initialization Steps
> +~~
> +
> +As noted in the introduction, most PCI drivers need the following steps
> +for device initialization:
>  
> -   If you want to use the PCI Memory-Write-Invalidate transaction,
> + Enable the device
> + request MMIO/IOP resources
> + set the DMA mask size (for both coherent and streaming DMA)
> + allocate and initialize shared control data (pci_allocate_coherent())
> + Access 

Re: [Bug 7505] Linux-2.6.18 fails to boot on AMD64 machine

[Stefano Takekawa]

> I am pretty sure the i386 tree has the same problem but I haven't checked yet.
> Anyway: the panic is just a way of noticing. The bug is that irq's are enabled
> before the irq controller is set up.

A very similar i386 linux installation works fine on my laptop, but that
i386 kernel never had problem.

-- 
Stefano Takekawa
[EMAIL PROTECTED]

Frank:  And why do days get longer in the summer?
Ernest: Because heat makes things expand!


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] input/spi: add ads7843 support to ads7846 touchscreen driver

[David Brownell]

On Thursday 21 December 2006 5:08 am, Nicolas Ferre wrote:
 
> > Let me try to sort out the mess with those updates, and ask you to refresh
> > this ads7843 support against that more-current ads7846 code.
> 
> Ok, let me know when you have a newer code. I will try to adapt my
> ads7843 support then.

I just sent these updates to LKML ... though the address I had for Dmitry
sees to have gone bad, I do see all six patches in the list archives.

Now it's your turn.  :)

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

[patch 2.6.20-rc1 5/6] input: ads7846 forces SPI mode 1

[David Brownell]

From: Imre Deak <[EMAIL PROTECTED]>
Date:  Fri May 26 16:30:10 2006 -0700

Input: ads7846: select correct SPI mode

Talk to ADS7846 chip using SPI mode 1, which is what the chip
supports:  writes on falling clock edge, reads on rising.

Signed-off-by: Imre Deak <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>

Index: osk/drivers/input/touchscreen/ads7846.c
===
--- osk.orig/drivers/input/touchscreen/ads7846.c2006-12-22 
11:08:45.0 -0800
+++ osk/drivers/input/touchscreen/ads7846.c 2006-12-22 11:08:46.0 
-0800
@@ -773,6 +773,10 @@ static int __devinit ads7846_probe(struc
 * may not.  So we stick to very-portable 8 bit words, both RX and TX.
 */
spi->bits_per_word = 8;
+   spi->mode = SPI_MODE_1;
+   err = spi_setup(spi);
+   if (err < 0)
+   return err;
 
ts = kzalloc(sizeof(struct ads7846), GFP_KERNEL);
input_dev = input_allocate_device();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc1 4/6] input: ads7836 users hrtimer

[David Brownell]

From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Mon Jul 3 21:34:16 2006 +0300

Input: ads7846: switch to hrtimer

Use hrtimer instead of the normal timer, since it provides better
sampling resolution. This will:

 - avoid a problem where we have a 1 jiffy poll period and
   dynamic tick on
 - utilize high resolution HW clocks when they are added to
   the hrtimer framework

Signed-off-by: Imre Deak <[EMAIL PROTECTED]>
Signed-off-by: Juha Yrjola <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>

Index: osk/drivers/input/touchscreen/ads7846.c
===
--- osk.orig/drivers/input/touchscreen/ads7846.c2006-12-22 
11:08:44.0 -0800
+++ osk/drivers/input/touchscreen/ads7846.c 2006-12-22 11:08:45.0 
-0800
@@ -55,7 +55,8 @@
  * files.
  */
 
-#defineTS_POLL_PERIOD  msecs_to_jiffies(10)
+#define TS_POLL_DELAY  (1 * 100)   /* ns delay before the first sample */
+#define TS_POLL_PERIOD (5 * 100)   /* ns delay between samples */
 
 /* this driver doesn't aim at the peak continuous sample rate */
 #defineSAMPLE_BITS (8 /*cmd*/ + 16 /*sample*/ + 2 /* before, after 
*/)
@@ -101,7 +102,7 @@ struct ads7846 {
u16 debounce_rep;
 
spinlock_t  lock;
-   struct timer_list   timer;  /* P: lock */
+   struct hrtimer  timer;
unsignedpendown:1;  /* P: lock */
unsignedpending:1;  /* P: lock */
 // FIXME remove "irq_disabled"
@@ -470,10 +471,12 @@ static void ads7846_rx(void *ads)
Rt = 0;
 
/* Sample found inconsistent by debouncing or pressure is beyond
-   * the maximum. Don't report it to user space, repeat at least
-   * once more the measurement */
+* the maximum. Don't report it to user space, repeat at least
+* once more the measurement
+*/
if (ts->tc.ignore || Rt > ts->pressure_max) {
-   mod_timer(>timer, jiffies + TS_POLL_PERIOD);
+   hrtimer_start(>timer, ktime_set(0, TS_POLL_PERIOD),
+ HRTIMER_REL);
return;
}
 
@@ -515,7 +518,7 @@ static void ads7846_rx(void *ads)
spin_lock_irqsave(>lock, flags);
 
ts->pendown = (Rt != 0);
-   mod_timer(>timer, jiffies + TS_POLL_PERIOD);
+   hrtimer_start(>timer, ktime_set(0, TS_POLL_PERIOD), HRTIMER_REL);
 
spin_unlock_irqrestore(>lock, flags);
 }
@@ -606,9 +609,9 @@ static void ads7846_rx_val(void *ads)
status);
 }
 
-static void ads7846_timer(unsigned long handle)
+static int ads7846_timer(struct hrtimer *handle)
 {
-   struct ads7846  *ts = (void *)handle;
+   struct ads7846  *ts = container_of(handle, struct ads7846, timer);
int status = 0;
 
spin_lock_irq(>lock);
@@ -630,6 +633,7 @@ static void ads7846_timer(unsigned long 
}
 
spin_unlock_irq(>lock);
+   return HRTIMER_NORESTART;
 }
 
 static irqreturn_t ads7846_irq(int irq, void *handle)
@@ -648,7 +652,8 @@ static irqreturn_t ads7846_irq(int irq, 
ts->irq_disabled = 1;
disable_irq(ts->spi->irq);
ts->pending = 1;
-   mod_timer(>timer, jiffies);
+   hrtimer_start(>timer, ktime_set(0, TS_POLL_DELAY),
+   HRTIMER_REL);
}
}
spin_unlock_irqrestore(>lock, flags);
@@ -790,8 +795,7 @@ static int __devinit ads7846_probe(struc
ts->spi = spi;
ts->input = input_dev;
 
-   init_timer(>timer);
-   ts->timer.data = (unsigned long) ts;
+   hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_REL);
ts->timer.function = ads7846_timer;
 
spin_lock_init(>lock);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 2.6.20-rc1 3/6] input: ads7846 more compatible with hwmon

[David Brownell]

Be more compatible with the hwmon framework:

 - Hook up to hwmon
 * show sensor attrubites only if hwmon is present
 * otherwise be just a touchscreen
 - Report voltages per hwmon convention
 * measure in millivolts
 * voltages are named in[0-8]_input (ugh)
 * for 7846 chips, properly range-adjust vBATT/in1_input

Battery measurements help during recharge monitoring.  On OSK/Mistral,
the measured voltage agreed with a multimeter to several decimal places.
 
Signed-off-by: David Brownell <[EMAIL PROTECTED]>

Index: osk/drivers/input/touchscreen/Kconfig
===
--- osk.orig/drivers/input/touchscreen/Kconfig  2006-12-22 11:08:09.0 
-0800
+++ osk/drivers/input/touchscreen/Kconfig   2006-12-22 11:08:44.0 
-0800
@@ -12,12 +12,15 @@ menuconfig INPUT_TOUCHSCREEN
 if INPUT_TOUCHSCREEN
 
 config TOUCHSCREEN_ADS7846
-   tristate "ADS 7846 based touchscreens"
+   tristate "ADS 7846/7843 based touchscreens"
depends on SPI_MASTER
help
  Say Y here if you have a touchscreen interface using the
- ADS7846 controller, and your board-specific initialization
+ ADS7846 or ADS7843 controller, and your board-specific setup
  code includes that in its table of SPI devices.
+ 
+ If HWMON is selected, you will also get hwmon interfaces for
+ the voltage (and for ads7846, temperature) sensors on this chip.
 
  If unsure, say N (but it's safe to say "Y").
 
Index: osk/drivers/input/touchscreen/ads7846.c
===
--- osk.orig/drivers/input/touchscreen/ads7846.c2006-12-22 
11:08:43.0 -0800
+++ osk/drivers/input/touchscreen/ads7846.c 2006-12-22 11:08:44.0 
-0800
@@ -17,8 +17,9 @@
  *  it under the terms of the GNU General Public License version 2 as
  *  published by the Free Software Foundation.
  */
-#include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -77,6 +78,7 @@ struct ads7846 {
 
struct spi_device   *spi;
struct attribute_group  *attr_group;
+   struct class_device *hwmon;
u16 model;
u16 vref_delay_usecs;
u16 x_plate_ohms;
@@ -169,7 +171,12 @@ struct ads7846 {
 
 /*
  * Non-touchscreen sensors only use single-ended conversions.
+ * The range is GND..vREF. The ads7843 and ads7835 must use external vREF;
+ * ads7846 lets that pin be unconnected, to use internal vREF.
+ *
+ * FIXME make external vREF_mV be a module option, and use that as needed...
  */
+static const unsigned vREF_mV = 2500;
 
 struct ser_req {
u8  ref_on;
@@ -197,50 +204,55 @@ static int ads7846_read12_ser(struct dev
struct ser_req  *req = kzalloc(sizeof *req, GFP_KERNEL);
int status;
int sample;
-   int i;
+   int use_internal;
 
if (!req)
return -ENOMEM;
 
spi_message_init(>msg);
 
-   /* activate reference, so it has time to settle; */
-   req->ref_on = REF_ON;
-   req->xfer[0].tx_buf = >ref_on;
-   req->xfer[0].len = 1;
-   req->xfer[1].rx_buf = >scratch;
-   req->xfer[1].len = 2;
+   /* FIXME boards with ads7846 might use external vref instead ... */
+   use_internal = (ts->model == 7846);
 
-   /*
-* for external VREF, 0 usec (and assume it's always on);
-* for 1uF, use 800 usec;
-* no cap, 100 usec.
-*/
-   req->xfer[1].delay_usecs = ts->vref_delay_usecs;
+   /* maybe turn on internal vREF, and let it settle */
+   if (use_internal) {
+   req->ref_on = REF_ON;
+   req->xfer[0].tx_buf = >ref_on;
+   req->xfer[0].len = 1;
+   spi_message_add_tail(>xfer[0], >msg);
+
+   req->xfer[1].rx_buf = >scratch;
+   req->xfer[1].len = 2;
+
+   /* for 1uF, settle for 800 usec; no cap, 100 usec.  */
+   req->xfer[1].delay_usecs = ts->vref_delay_usecs;
+   spi_message_add_tail(>xfer[1], >msg);
+   }
 
/* take sample */
req->command = (u8) command;
req->xfer[2].tx_buf = >command;
req->xfer[2].len = 1;
+   spi_message_add_tail(>xfer[2], >msg);
+
req->xfer[3].rx_buf = >sample;
req->xfer[3].len = 2;
+   spi_message_add_tail(>xfer[3], >msg);
 
/* REVISIT:  take a few more samples, and compare ... */
 
-   /* turn off reference */
-   req->ref_off = REF_OFF;
-   req->xfer[4].tx_buf = >ref_off;
-   req->xfer[4].len = 1;
-   req->xfer[5].rx_buf = >scratch;
-   req->xfer[5].len = 2;
-
-   CS_CHANGE(req->xfer[5]);
+   /* maybe off internal vREF */
+   if (use_internal) {
+   req->ref_off = REF_OFF;
+   

[patch 2.6.20-rc1 1/6] input: ads7846 pluggable conditioning filters

[David Brownell]

From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Mon Jul 3 21:36:53 2006 +0300

Input: ads7846: pluggable filtering logic

Some LCDs like the LS041Y3 require a customized filtering
logic for reliable readings, so make the filtering function
replacable through platform specific hooks.

Signed-off-by: Imre Deak <[EMAIL PROTECTED]>
Signed-off-by: Juha Yrjola <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>

Index: osk/include/linux/spi/ads7846.h
===
--- osk.orig/include/linux/spi/ads7846.h2006-12-22 11:08:16.0 
-0800
+++ osk/include/linux/spi/ads7846.h 2006-12-22 11:08:41.0 -0800
@@ -5,6 +5,12 @@
  *
  * It's OK if the min/max values are zero.
  */
+enum ads7846_filter {
+   ADS7846_FILTER_OK,
+   ADS7846_FILTER_REPEAT,
+   ADS7846_FILTER_IGNORE,
+};
+
 struct ads7846_platform_data {
u16 model;  /* 7843, 7845, 7846. */
u16 vref_delay_usecs;   /* 0 for external vref; etc */
@@ -21,5 +27,9 @@ struct ads7846_platform_data {
u16 debounce_rep;   /* additional consecutive good readings
 * required after the first two */
int (*get_pendown_state)(void);
+   int (*filter_init)  (struct ads7846_platform_data *pdata,
+void **filter_data);
+   int (*filter)   (void *filter_data, int data_idx, int *val);
+   void(*filter_cleanup)(void *filter_data);
 };
 
Index: osk/drivers/input/touchscreen/ads7846.c
===
--- osk.orig/drivers/input/touchscreen/ads7846.c2006-12-22 
11:08:16.0 -0800
+++ osk/drivers/input/touchscreen/ads7846.c 2006-12-22 11:08:41.0 
-0800
@@ -63,11 +63,11 @@ struct ts_event {
/* For portability, we can't read 12 bit values using SPI (which
 * would make the controller deliver them as native byteorder u16
 * with msbs zeroed).  Instead, we read them as two 8-bit values,
-* which need byteswapping then range adjustment.
+* *** WHICH NEED BYTESWAPPING *** and range adjustment.
 */
-   __be16 x;
-   __be16 y;
-   __be16 z1, z2;
+   u16 x;
+   u16 y;
+   u16 z1, z2;
intignore;
 };
 
@@ -106,6 +106,9 @@ struct ads7846 {
unsignedirq_disabled:1; /* P: lock */
unsigneddisabled:1;
 
+   int (*filter)(void *data, int data_idx, int *val);
+   void*filter_data;
+   void(*filter_cleanup)(void *data);
int (*get_pendown_state)(void);
 };
 
@@ -379,13 +382,13 @@ static void ads7846_rx(void *ads)
u16 x, y, z1, z2;
unsigned long   flags;
 
-   /* adjust:  on-wire is a must-ignore bit, a BE12 value, then padding;
-* built from two 8 bit values written msb-first.
+   /* ads7846_rx_val() did in-place conversion (including byteswap) from
+* on-the-wire format as part of debouncing to get stable readings.
 */
-   x = (be16_to_cpu(ts->tc.x) >> 3) & 0x0fff;
-   y = (be16_to_cpu(ts->tc.y) >> 3) & 0x0fff;
-   z1 = (be16_to_cpu(ts->tc.z1) >> 3) & 0x0fff;
-   z2 = (be16_to_cpu(ts->tc.z2) >> 3) & 0x0fff;
+   x = ts->tc.x;
+   y = ts->tc.y;
+   z1 = ts->tc.z1;
+   z2 = ts->tc.z2;
 
/* range filtering */
if (x == MAX_12BIT)
@@ -453,50 +456,85 @@ static void ads7846_rx(void *ads)
spin_unlock_irqrestore(>lock, flags);
 }
 
-static void ads7846_debounce(void *ads)
+static int ads7846_debounce(void *ads, int data_idx, int *val)
 {
struct ads7846  *ts = ads;
-   struct spi_message  *m;
-   struct spi_transfer *t;
-   int val;
-   int status;
 
-   m = >msg[ts->msg_idx];
-   t = list_entry(m->transfers.prev, struct spi_transfer, transfer_list);
-   val = (be16_to_cpu(*(__be16 *)t->rx_buf) >> 3) & 0x0fff;
-   if (!ts->read_cnt || (abs(ts->last_read - val) > ts->debounce_tol)) {
+   if (!ts->read_cnt || (abs(ts->last_read - *val) > ts->debounce_tol)) {
+   /* Start over collecting consistent readings. */
+   ts->read_rep = 0;
/* Repeat it, if this was the first read or the read
 * wasn't consistent enough. */
if (ts->read_cnt < ts->debounce_max) {
-   ts->last_read = val;
+   ts->last_read = *val;
ts->read_cnt++;
+   return ADS7846_FILTER_REPEAT;
} else {
/* Maximum number of debouncing reached and still
 * not enough number of consistent readings. Abort
 

[patch 2.6.20-rc1 2/6] input: ads7846 optionally leaves vREF on

[David Brownell]

From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Mon Jul 3 21:40:10 2006 +0300

Input ads7846: optionally leave Vref on during differential measurements

On some LCDs leaving the Vref on provides much better readings.

Signed-off-by: Jarkko Oikarinen <[EMAIL PROTECTED]>
Signed-off-by: Imre Deak <[EMAIL PROTECTED]>
Signed-off-by: Juha Yrjola <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>

Index: osk/include/linux/spi/ads7846.h
===
--- osk.orig/include/linux/spi/ads7846.h2006-12-22 11:08:41.0 
-0800
+++ osk/include/linux/spi/ads7846.h 2006-12-22 11:08:43.0 -0800
@@ -14,6 +14,8 @@ enum ads7846_filter {
 struct ads7846_platform_data {
u16 model;  /* 7843, 7845, 7846. */
u16 vref_delay_usecs;   /* 0 for external vref; etc */
+   int keep_vref_on : 1;   /* set to keep vref on for differential
+* measurements as well */
u16 x_plate_ohms;
u16 y_plate_ohms;
 
Index: osk/drivers/input/touchscreen/ads7846.c
===
--- osk.orig/drivers/input/touchscreen/ads7846.c2006-12-22 
11:08:41.0 -0800
+++ osk/drivers/input/touchscreen/ads7846.c 2006-12-22 11:08:43.0 
-0800
@@ -145,15 +145,16 @@ struct ads7846 {
 #defineMAX_12BIT   ((1<<12)-1)
 
 /* leave ADC powered up (disables penirq) between differential samples */
-#defineREAD_12BIT_DFR(x) (ADS_START | ADS_A2A1A0_d_ ## x \
-   | ADS_12_BIT | ADS_DFR)
+#defineREAD_12BIT_DFR(x, adc, vref) (ADS_START | ADS_A2A1A0_d_ ## x \
+   | ADS_12_BIT | ADS_DFR | \
+   (adc ? ADS_PD10_ADC_ON : 0) | (vref ? ADS_PD10_REF_ON : 0))
 
-#defineREAD_Y  (READ_12BIT_DFR(y)  | ADS_PD10_ADC_ON)
-#defineREAD_Z1 (READ_12BIT_DFR(z1) | ADS_PD10_ADC_ON)
-#defineREAD_Z2 (READ_12BIT_DFR(z2) | ADS_PD10_ADC_ON)
+#defineREAD_Y(vref)(READ_12BIT_DFR(y,  1, vref))
+#defineREAD_Z1(vref)   (READ_12BIT_DFR(z1, 1, vref))
+#defineREAD_Z2(vref)   (READ_12BIT_DFR(z2, 1, vref))
 
-#defineREAD_X  (READ_12BIT_DFR(x)  | ADS_PD10_ADC_ON)
-#definePWRDOWN (READ_12BIT_DFR(y)  | ADS_PD10_PDOWN)   /* LAST */
+#defineREAD_X(vref)(READ_12BIT_DFR(x,  1, vref))
+#definePWRDOWN (READ_12BIT_DFR(y,  0, 0))  /* LAST */
 
 /* single-ended samples need to first power up reference voltage;
  * we leave both ADC and VREF powered
@@ -161,8 +162,8 @@ struct ads7846 {
 #defineREAD_12BIT_SER(x) (ADS_START | ADS_A2A1A0_ ## x \
| ADS_12_BIT | ADS_SER)
 
-#defineREF_ON  (READ_12BIT_DFR(x) | ADS_PD10_ALL_ON)
-#defineREF_OFF (READ_12BIT_DFR(y) | ADS_PD10_PDOWN)
+#defineREF_ON  (READ_12BIT_DFR(x, 1, 1))
+#defineREF_OFF (READ_12BIT_DFR(y, 0, 0))
 
 /*--*/
 
@@ -670,6 +671,7 @@ static int __devinit ads7846_probe(struc
struct ads7846_platform_data*pdata = spi->dev.platform_data;
struct spi_message  *m;
struct spi_transfer *x;
+   int vref;
int err;
 
if (!spi->irq) {
@@ -767,6 +769,8 @@ static int __devinit ads7846_probe(struc
input_set_abs_params(input_dev, ABS_PRESSURE,
pdata->pressure_min, pdata->pressure_max, 0, 0);
 
+   vref = pdata->keep_vref_on;
+
/* set up the transfers to read touchscreen state; this assumes we
 * use formula #2 for pressure, not #3.
 */
@@ -776,7 +780,7 @@ static int __devinit ads7846_probe(struc
spi_message_init(m);
 
/* y- still on; turn on only y+ (and ADC) */
-   ts->read_y = READ_Y;
+   ts->read_y = READ_Y(vref);
x->tx_buf = >read_y;
x->len = 1;
spi_message_add_tail(x, m);
@@ -794,7 +798,7 @@ static int __devinit ads7846_probe(struc
 
/* turn y- off, x+ on, then leave in lowpower */
x++;
-   ts->read_x = READ_X;
+   ts->read_x = READ_X(vref);
x->tx_buf = >read_x;
x->len = 1;
spi_message_add_tail(x, m);
@@ -813,7 +817,7 @@ static int __devinit ads7846_probe(struc
spi_message_init(m);
 
x++;
-   ts->read_z1 = READ_Z1;
+   ts->read_z1 = READ_Z1(vref);
x->tx_buf = >read_z1;
x->len = 1;
spi_message_add_tail(x, m);
@@ -830,7 +834,7 @@ static int __devinit ads7846_probe(struc
spi_message_init(m);
 
x++;
-   ts->read_z2 = READ_Z2;
+   ts->read_z2 = READ_Z2(vref);
x->tx_buf = >read_z2;
x->len = 1;
spi_message_add_tail(x, m);
-
To unsubscribe from this list: send the line 

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

[Martin Michlmayr]

* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-22 14:25]:
> >  and it failed.
> Since you are on ARM you might want to try with the page_mkclean_one
> cleanup patch too.

I've already tried it and it didn't work.  I just tried it again
together with Linus' patch and the two from Andrew and it still fails.
(For reference, the patch is attached.)
-- 
Martin Michlmayr
http://www.cyrius.com/
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2834,7 +2834,7 @@ int try_to_free_buffers(struct page *pag
int ret = 0;
 
BUG_ON(!PageLocked(page));
-   if (PageWriteback(page))
+   if (PageDirty(page) || PageWriteback(page))
return 0;
 
if (mapping == NULL) {  /* can this still happen? */
@@ -2845,22 +2845,6 @@ int try_to_free_buffers(struct page *pag
spin_lock(>private_lock);
ret = drop_buffers(page, _to_free);
spin_unlock(>private_lock);
-   if (ret) {
-   /*
-* If the filesystem writes its buffers by hand (eg ext3)
-* then we can have clean buffers against a dirty page.  We
-* clean the page here; otherwise later reattachment of buffers
-* could encounter a non-uptodate page, which is unresolvable.
-* This only applies in the rare case where try_to_free_buffers
-* succeeds but the page is not freed.
-*
-* Also, during truncate, discard_buffer will have marked all
-* the page's buffers clean.  We discover that here and clean
-* the page also.
-*/
-   if (test_clear_page_dirty(page))
-   task_io_account_cancelled_write(PAGE_CACHE_SIZE);
-   }
 out:
if (buffers_to_free) {
struct buffer_head *bh = buffers_to_free;
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index ed2c223..4f4cd13 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -176,7 +176,7 @@ static int hugetlbfs_commit_write(struct
 
 static void truncate_huge_page(struct page *page)
 {
-   clear_page_dirty(page);
+   cancel_dirty_page(page, /* No IO accounting for huge pages? */0);
ClearPageUptodate(page);
remove_from_page_cache(page);
put_page(page);
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 4830a3b..350878a 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -253,15 +253,11 @@ #define ClearPageUncached(page)   clear_bi
 
 struct page;   /* forward declaration */
 
-int test_clear_page_dirty(struct page *page);
+extern void cancel_dirty_page(struct page *page, unsigned int account_size);
+
 int test_clear_page_writeback(struct page *page);
 int test_set_page_writeback(struct page *page);
 
-static inline void clear_page_dirty(struct page *page)
-{
-   test_clear_page_dirty(page);
-}
-
 static inline void set_page_writeback(struct page *page)
 {
test_set_page_writeback(page);
diff --git a/mm/memory.c b/mm/memory.c
index c00bac6..79cecab 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1842,6 +1842,33 @@ void unmap_mapping_range(struct address_
 }
 EXPORT_SYMBOL(unmap_mapping_range);
 
+static void check_last_page(struct address_space *mapping, loff_t size)
+{
+   pgoff_t index;
+   unsigned int offset;
+   struct page *page;
+
+   if (!mapping)
+   return;
+   offset = size & ~PAGE_MASK;
+   if (!offset)
+   return;
+   index = size >> PAGE_SHIFT;
+   page = find_lock_page(mapping, index);
+   if (page) {
+   unsigned int check = 0;
+   unsigned char *kaddr = kmap_atomic(page, KM_USER0);
+   do {
+   check += kaddr[offset++];
+   } while (offset < PAGE_SIZE);
+   kunmap_atomic(kaddr,KM_USER0);
+   unlock_page(page);
+   page_cache_release(page);
+   if (check)
+   printk("%s: BADNESS: truncate check %u\n", 
current->comm, check);
+   }
+}
+
 /**
  * vmtruncate - unmap mappings "freed" by truncate() syscall
  * @inode: inode of the file used
@@ -1875,6 +1902,7 @@ do_expand:
goto out_sig;
if (offset > inode->i_sb->s_maxbytes)
goto out_big;
+   check_last_page(mapping, inode->i_size);
i_size_write(inode, offset);
 
 out_truncate:
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 237107c..b3a198c 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -845,38 +845,6 @@ int set_page_dirty_lock(struct page *pag
 EXPORT_SYMBOL(set_page_dirty_lock);
 
 /*
- * Clear a page's dirty flag, while caring for dirty memory accounting. 
- * Returns true if the page was previously dirty.
- */
-int test_clear_page_dirty(struct page *page)
-{
-   struct address_space *mapping = page_mapping(page);
-   unsigned long flags;
-
-   if (!mapping)
-   return 

[patch 2.6.20-rc1 0/6] input: ads7846 touchscreen driver updates

[David Brownell]

Following this are six patches that bring the ads7846 driver up to
date with respect to the patches in the Linux-OMAP tree.  There was
some unfortunate divergence, but the need for that is gone (now that
issues with the omap_uwire SPI controller driver are resolved).

 - allow pluggable lcd-specific input conditioning filters
 - optionally leave vREF on for board-specific sample improvement
 - be more compatible with hwmon framework
 - switch to hrtimer
 - force use of SPI mode 1
 - use explicit detection of penup signal (gpio) state

Most of this came from Nokia work, ISTR for better N770 support.

That patch for PENUP handling should also be useful for the ads7843
updates being provided by Atmel.


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

2.6.20-rc1-git8 fails to build - another "clear_page_dirty' problem

[Larry Finger]

The latest git pull from Linus's git tree fails to build. The error message is

fs/built-in.o: In function `reiserfs_cut_from_item':
: undefined reference to `clear_page_dirty'
make: *** [.tmp_vmlinux1] Error 1

It seems that reiserfs needs to be updated to match the changes in dirty page 
handling.

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

Re: [Bug 7505] Linux-2.6.18 fails to boot on AMD64 machine

[Andrew Morton]

On Fri, 22 Dec 2006 15:16:55 +0100
Ard -kwaak- van Breemen <[EMAIL PROTECTED]> wrote:

> On Fri, Dec 22, 2006 at 03:00:59PM +0100, Ard -kwaak- van Breemen wrote:
> > 262 if (!irqs_disabled()) printk(__FILE__ "%s(): blaat: 
> > interrupts were enabled [EMAIL PROTECTED]",__FUNCTION__,__LINE__);
> > 263 
> > 264 ide_init_hwif_ports(, ide_default_io_base(index), 0, 
> > >irq);
> --^^^
> which does a if (pci_find_device(PCI_ANY_ID, PCI_ANY_ID,
> in include/asm-i386/ide.h
> 
> which should be really the part that does the irq enabling.

doh, I missed down_read():

--- a/lib/rwsem-spinlock.c~down_write-preserve-local-irqs
+++ a/lib/rwsem-spinlock.c
@@ -129,13 +129,14 @@ void fastcall __sched __down_read(struct
 {
struct rwsem_waiter waiter;
struct task_struct *tsk;
+   unsigned long flags;
 
-   spin_lock_irq(>wait_lock);
+   spin_lock_irqsave(>wait_lock, flags);
 
if (sem->activity >= 0 && list_empty(>wait_list)) {
/* granted */
sem->activity++;
-   spin_unlock_irq(>wait_lock);
+   spin_unlock_irqrestore(>wait_lock, flags);
goto out;
}
 
@@ -150,7 +151,7 @@ void fastcall __sched __down_read(struct
list_add_tail(, >wait_list);
 
/* we don't need to touch the semaphore struct anymore */
-   spin_unlock_irq(>wait_lock);
+   spin_unlock_irqrestore(>wait_lock, flags);
 
/* wait to be given the lock */
for (;;) {
@@ -195,13 +196,14 @@ void fastcall __sched __down_write_neste
 {
struct rwsem_waiter waiter;
struct task_struct *tsk;
+   unsigned long flags;
 
-   spin_lock_irq(>wait_lock);
+   spin_lock_irqsave(>wait_lock, flags);
 
if (sem->activity == 0 && list_empty(>wait_list)) {
/* granted */
sem->activity = -1;
-   spin_unlock_irq(>wait_lock);
+   spin_unlock_irqrestore(>wait_lock, flags);
goto out;
}
 
@@ -216,7 +218,7 @@ void fastcall __sched __down_write_neste
list_add_tail(, >wait_list);
 
/* we don't need to touch the semaphore struct anymore */
-   spin_unlock_irq(>wait_lock);
+   spin_unlock_irqrestore(>wait_lock, flags);
 
/* wait to be given the lock */
for (;;) {
_

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

Re: Possible race condition in usb-serial.c

[J]

> This problem will need some deeper surgery probably
> involving
> removal of the refcounting.

Refcounting may be OK if used consistently. 
It is not OK when some pointers are ref-counted, 
but other (in serial_table) are not (like it is
in the current version).

As for the deeper surgery, what do you think about my
earlier suggestion to start by rewriting
usb_serial_probe
to fully initialize usb_serial before it is added to 
serial_table? 

So, instead of the current:
1. create_serial
...
2. mutex_lock(_lock);
3. get_free_serial (which inserts serial to
serial_table)
...
4. initializes serial
5. mutex_unlock(_lock);

we will get:

1. create_serial
2. initializes serial

3. add_serial_toserial_table  (with internal mutex
lock if needed)

Similar approach should be used in other places to
minimize the code executed under the mutex.

John

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.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.6.19] mmc: Add support for SDHC cards

[Philip Langdale]

Philip Langdale wrote:
> Hi all,
> 
> Thanks to the generous donation of an SDHC card by John Gilmore, and the
> surprisingly enlightened decision by the SD Card Association to publish
> useful specs, I've been able to bash out support for SDHC. The changes
> are not too profound:

So I sent that with the wrong From: address (damn you thunderbird!). Please
reply to my personal address (this one) and not my work one. :-)

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

Re: [powerpc] Fix bogus BUG_ON() in in hugetlb_get_unmapped_area()

[Segher Boessenkool]

+   if (len > TASK_SIZE)
+   return -ENOMEM;


Shouldn't that be addr+len instead?  The check looks incomplete
otherwise.  And you meant ">=" I guess?


No.  Have a look at the other hugetlb_get_unmapped_area()
implementations.  Because this is in the get_unmapped_area() path,
'addr' is just a hint,


Ah I missed this vital piece of information, thanks for the
explanation.  Care putting in a code comment pointing this out?


so checking addr+len would give bogus
failures.  This test is, I believe, essentially an optimization - if
it fails, we're never going to find a suitable addr, so we might as
well give up now.


Yes, it all makes sense now.


-   /* Paranoia, caller should have dealt with this */
-   BUG_ON((addr + len) > 0x1UL);
-


Any real reason to remove the paranoia check?  If it's trivially
always satisfied, the compiler will get rid of it for you :-)


Yes - this is the very bug on which was causing crashes - the "caller
should have dealt with this" comment is wrong.  The test has been
moved into htlb_check_hinted_area() and now simply fails (and so falls
back to searching for a suitable address), rather than BUG()ing.


Yep.

Cheers,


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.19] mmc: Add support for SDHC cards

[Philip Langdale]

Hi all,

Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:

i) Add a card flag indicating the card uses block level addressing and check
it in the block driver. As we never took advantage of byte-level addressing,
this simply involves skipping the block -> byte translation when sending 
commands.

ii) The layout of the CSD is changed - a set of fields are discarded to make 
space
for a larger C_SIZE. We did not reference any of the discarded fields except 
those
related to the C_SIZE.

iii) Read and write timeouts are fixed values and not calculated from CSD 
values.

iv) Before invoking SEND_APP_OP_COND, we must invoke the new SEND_IF_COND to 
inform
the card we support SDHC.

I've done some basic read and write tests and everything seems to work fine but 
one
should obviously use caution in case it eats your data.

Addendum: Similar spec changes were introduced by the MMC Association in 
version 4.2
to switch to block addressing. We do not have access to the 4.2 spec or even a 
change
summary as we did for 3 -> 4. My guess as to what's changed looks something 
like the
following:

i) A new field is added to the ext_csd to store the capacity that cannot be 
described
using existing csd fields.

ii) A new field is added to the ext_csd to indicate the need for block 
addressing.

iii) A new write-only field is added to the ext_csd which has to be toggled to 
tell the
card that the host supports block-addressing. But perhaps compatibility 
requires that
a new command be used like for SDHC...

If someone has access to the spec and can shed some light on the subject in a 
legal way,
please let us know. Of course, I don't think there are any MMC HC cards on the 
market
yet, but one was announced last month.

--phil

Signed-off-by: Philipl Langdale <[EMAIL PROTECTED]>
---

 drivers/mmc/mmc.c|   40 +++-
 drivers/mmc/mmc_block.c  |4 +++-
 include/linux/mmc/card.h |3 +++
 include/linux/mmc/mmc.h  |1 +
 include/linux/mmc/protocol.h |   13 -
 5 files changed, 54 insertions(+), 7 deletions(-)

diff -urN linux-2.6.19/drivers/mmc/mmc_block.c 
linux-2.6.19-sdhc/drivers/mmc/mmc_block.c
--- linux-2.6.19/drivers/mmc/mmc_block.c2006-12-21 20:29:49.0 
-0800
+++ linux-2.6.19-sdhc/drivers/mmc/mmc_block.c   2006-12-22 08:42:56.0 
-0800
@@ -237,7 +237,9 @@
brq.mrq.cmd = 
brq.mrq.data = 

-   brq.cmd.arg = req->sector << 9;
+   brq.cmd.arg = req->sector;
+   if (!mmc_card_blockaddr(card))
+   brq.cmd.arg <<= 9;
brq.cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
brq.data.blksz = 1 << md->block_bits;
brq.data.blocks = req->nr_sectors >> (md->block_bits - 9);
diff -urN linux-2.6.19/drivers/mmc/mmc.c linux-2.6.19-sdhc/drivers/mmc/mmc.c
--- linux-2.6.19/drivers/mmc/mmc.c  2006-12-21 20:29:49.0 -0800
+++ linux-2.6.19-sdhc/drivers/mmc/mmc.c 2006-12-22 09:57:41.0 -0800
@@ -289,7 +289,10 @@
else
limit_us = 10;

-   if (timeout_us > limit_us) {
+   /*
+* SDHC cards always use these fixed values.
+*/
+   if (timeout_us > limit_us || mmc_card_blockaddr(card)) {
data->timeout_ns = limit_us * 1000;
data->timeout_clks = 0;
}
@@ -588,12 +591,15 @@

if (mmc_card_sd(card)) {
csd_struct = UNSTUFF_BITS(resp, 126, 2);
-   if (csd_struct != 0) {
+   if (csd_struct != 0 && csd_struct != 1) {
printk("%s: unrecognised CSD structure version %d\n",
mmc_hostname(card->host), csd_struct);
mmc_card_set_bad(card);
return;
}
+   if (csd_struct == 1) {
+   mmc_card_set_blockaddr(card);
+   }

m = UNSTUFF_BITS(resp, 115, 4);
e = UNSTUFF_BITS(resp, 112, 3);
@@ -605,9 +611,14 @@
csd->max_dtr  = tran_exp[e] * tran_mant[m];
csd->cmdclass = UNSTUFF_BITS(resp, 84, 12);

-   e = UNSTUFF_BITS(resp, 47, 3);
-   m = UNSTUFF_BITS(resp, 62, 12);
-   csd->capacity = (1 + m) << (e + 2);
+   if (csd_struct == 0) {
+   e = UNSTUFF_BITS(resp, 47, 3);
+   m = UNSTUFF_BITS(resp, 62, 12);
+   csd->capacity = (1 + m) << (e + 2);
+   } else if (csd_struct == 1) {
+   m = UNSTUFF_BITS(resp, 48, 22);
+   csd->capacity = (1 + m) << 

Re: [Bug 7505] Linux-2.6.18 fails to boot on AMD64 machine

[Ard -kwaak- van Breemen]

Hello,
On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
> I couldn't reproduce it on my EM64T machine. I instrumented function 
> start_kernel and
> didn't find irq was enabled before calling init_IRQ. It'll be better if the 
> reporter could
> instrument function start_kernel to capture which function enables irq.

I can confirm this is a *GENERIC* X86_64 problem:

Kernel command line: console=tty0 console=ttyS0,115200 hdb=noprobe root=/dev/md0
init/main.c start_kernel(): interrupts were [EMAIL PROTECTED]
ide_setup: hdb=noprobe
init/main.c start_kernel(): interrupts were [EMAIL PROTECTED]
...
start_kernel(): bug: interrupts were enabled early

This is on a dell 1950 with a core 2 duo processors.

You have to have ide compiled in, and set ide options to get the irq's enabled,
and then have a setup which will have an irq pending before the irq controller
get's initialized to get the panic. The dell1950 does not panic, the kernel
merely warns.

I am pretty sure the i386 tree has the same problem but I haven't checked yet.
Anyway: the panic is just a way of noticing. The bug is that irq's are enabled
before the irq controller is set up.

But to make the ide_setup/irq bug go away, I think it might be an acceptable
solution to just disable the irq's again after the parse_args, and just to wait
until the SATA tree takes over the IDE tree.

-- 
program signature;
begin  { telegraaf.com
} writeln("<[EMAIL PROTECTED]> TEM2");
end
.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH -mm 0/5] proposal for dynamic configurable netconsole

[Stephen Hemminger]

On Fri, 22 Dec 2006 21:01:09 +0900
Keiichi KII <[EMAIL PROTECTED]> wrote:

> From: Keiichi KII <[EMAIL PROTECTED]>
> 
> The netconsole is a very useful module for collecting kernel message under
> certain circumstances(e.g. disk logging fails, serial port is unavailable).
> 
> But current netconsole is not flexible. For example, if you want to change ip
> address for logging agent, in the case of built-in netconsole, you can't 
> change
> config except for changing boot parameter and rebooting your system, or in the
> case of module netconsole, you need to reload netconsole module.

If netconsole is a module, you should be able to remove it and reload
with different parameters.

> So, I propose the following extended features for netconsole.
> 
> 1) support for multiple logging agents.
> 2) add interface to access each parameter of netconsole
>using sysfs.
> 
> This patch is for linux-2.6.20-rc1-mm1 and is divided to each function.
> Your comments are very welcome.

Rather than extending the existing kludge with module parameter, to
sysfs. I would rather see a better API for this. Please build think
about doing a better API with a basic set of ioctl's. Some additional
things:
- shouldn't just be IPV4 specific, should handle IPV6 as well
- shouldn't specify MAC address, it can do network discovery/arp to
  find that when adding addresses
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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]: x86-64 system crashes when no memory populating Node 0

[James Puthukattukaran]

I have a 4 socket AMD Operton system. The 2.6.18 kernel I have crashes 
when there is no memory in node0.


--James


diff -uNr linux-2.6.18-orig/arch/x86_64/kernel/aperture.c 
linux-2.6.18-new/arch/x86_64/kernel/aperture.c
--- linux-2.6.18-orig/arch/x86_64/kernel/aperture.c 2006-09-19 
23:42:06.0 -0400
+++ linux-2.6.18-new/arch/x86_64/kernel/aperture.c  2006-12-20 
19:43:42.0 -0500

@@ -38,7 +38,6 @@

static u32 __init allocate_aperture(void)
{
-   pg_data_t *nd0 = NODE_DATA(0);
   u32 aper_size;
   void *p;

@@ -52,12 +51,13 @@
* Unfortunately we cannot move it up because that would make the
* IOMMU useless.
*/
-   p = __alloc_bootmem_node(nd0, aper_size, aper_size, 0);
+
+   p = __alloc_bootmem(aper_size, aper_size, 0);
   if (!p || __pa(p)+aper_size > 0x) {
   printk("Cannot allocate aperture memory hole (%p,%uK)\n",
  p, aper_size>>10);
   if (p)
-   free_bootmem_node(nd0, __pa(p), aper_size);
+   free_bootmem(__pa(p), aper_size);
   return 0;
   }
   printk("Mapping aperture over %d KB of RAM @ %lx\n",

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

Re: Possible race condition in usb-serial.c

[Oliver Neukum]

Am Mittwoch, 20. Dezember 2006 23:24 schrieb J:
> > Could you test the attached patch against 2.6?
> 
> Alas, I only have an old 2.4 right now.
> May be I will install 2.6 later (in few weeks).
> Currently I am just trying to read 2.6 code with my
> eyes.
> 
> I studied the patch, which you sent.
> I don't see obvious errors, but, in my opinion, it is
> not completely perfect.

Please disregard the patch. I overlooked serial_read_proc().
This problem will need some deeper surgery probably involving
removal of the refcounting.

But not during Christmas.

Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] interrupt endpoint support for keyspan USB-to-serial

[Rainer Weikusat]

From: Rainer Weikusat <[EMAIL PROTECTED]>

At least the Keyspan USA-19HS USB-to-serial converter supports
two different configurations, one where the input endpoints
have interrupt transfer type and one where they are bulk endpoints.
The default configuration uses the interrupt input endpoints.
The keyspan driver, OTOH, assumes that the device has only bulk
endpoints (all URBs are initialized by calling usb_fill_bulk_urb
in keyspan.c/ keyspan_setup_urb). This causes the interval field
of the input URBs to have a value of zero instead of one, which
'accidentally' worked with Linux at least up to 2.6.17.11 but
stopped to with 2.6.18, which changed the code handling URBs for
interrupt endpoints. The patch below modifies to driver to
initialize its input URBs either as interrupt or as bulk URBs,
depending on the transfertype contained in the associated endpoint
descriptor (only tested with the default configuration) enabling
the driver to again receive data from the serial converter.

Signed-off-by: Rainer Weikusat <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.19.1.orig/drivers/usb/serial/keyspan.c 
linux-2.6.19.1/drivers/usb/serial/keyspan.c
--- linux-2.6.19.1.orig/drivers/usb/serial/keyspan.c2006-12-22 
18:28:09.0 +0100
+++ linux-2.6.19.1/drivers/usb/serial/keyspan.c 2006-12-22 18:52:15.0 
+0100
@@ -95,6 +95,7 @@
 */
 
 
+#include 
 #include 
 #include 
 #include 
@@ -1275,11 +1276,35 @@ static int keyspan_fake_startup (struct 
 }
 
 /* Helper functions used by keyspan_setup_urbs */
+static struct usb_endpoint_descriptor const *
+find_ep_desc_for(struct usb_serial const *serial, int endpoint)
+{
+   struct usb_host_interface const *setting;
+   struct usb_endpoint_descriptor const *ep_desc;
+   int n;
+
+   setting = serial->interface->cur_altsetting;
+   n = setting->desc.bNumEndpoints - 1;
+   do
+   ep_desc = >endpoint[n].desc;
+   while (ep_desc->bEndpointAddress != endpoint && --n >= 0);
+
+   if (unlikely(n == -1)) {
+   printk(KERN_ERR "no endpoint descriptor found\n");
+   BUG();
+   }
+
+   dbg("%s - found endpoint descriptor @ %p", __func__, ep_desc);
+   return ep_desc;
+}
+
 static struct urb *keyspan_setup_urb (struct usb_serial *serial, int endpoint,
  int dir, void *ctx, char *buf, int len,
  void (*callback)(struct urb *))
 {
+   struct usb_endpoint_descriptor const *ep_desc;
struct urb *urb;
+   unsigned ep_type;
 
if (endpoint == -1)
return NULL;/* endpoint not needed */
@@ -1290,11 +1315,33 @@ static struct urb *keyspan_setup_urb (st
dbg ("%s - alloc for endpoint %d failed.", __FUNCTION__, 
endpoint);
return NULL;
}
+   
+   ep_desc = find_ep_desc_for(serial, endpoint);
+   ep_type = ep_desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK;
+   switch (ep_type) {
+   case USB_ENDPOINT_XFER_INT:
+   dbg("%s - filling urb %p for int endpoint",
+   __func__, urb);
+   
+   usb_fill_int_urb(urb, serial->dev,
+usb_sndintpipe(serial->dev, endpoint) | dir,
+buf, len, callback, ctx,
+ep_desc->bInterval);
+   break;
+
+   case USB_ENDPOINT_XFER_BULK:
+   dbg("%s - filling urb %p for bulk endpoint",
+   __func__, urb);
+   
+   usb_fill_bulk_urb(urb, serial->dev,
+ usb_sndbulkpipe(serial->dev, endpoint) | dir,
+ buf, len, callback, ctx);
+   break;
 
-   /* Fill URB using supplied data. */
-   usb_fill_bulk_urb(urb, serial->dev,
- usb_sndbulkpipe(serial->dev, endpoint) | dir,
- buf, len, callback, ctx);
+   default:
+   printk(KERN_ERR "unexpected endpoint type %d", ep_type);
+   BUG();
+   }
 
return urb;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] acpi: Remove procfs from bay

[Kristen Carlson Accardi]

On Fri, 22 Dec 2006 11:43:55 +
Pavel Machek <[EMAIL PROTECTED]> wrote:

> Hi!
> 
> > Remove the procfs related code from the bay driver.
> > 
> > Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
> 
> This changes userland interface... how many apps will it break?
> 
>   Pavel
> 
> -- 
> Thanks for all the (sleeping) penguins.
> 

None - this code was never upstream - always just in -mm.

Kristen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

[Linus Torvalds]

On Fri, 22 Dec 2006, Peter Zijlstra wrote:
> 
> fix page_mkclean_one()
> 
>  - add flush_cache_page() for all those virtual indexed cache
>architectures.

I think the flush_cache_page() should be after we've actually flushed it 
from the TLB and re-inserted it (this is one reason why I did the 
"ptep_exchange()" version of this). Otherwise somebody can still write to 
the page _after_ the cache flush..

>  - handle s390.

Yeah, that looks like the proper way to handle that.

That said, it looks like we still see corruption. You may not, but Martin 
and Andrei still report problems, even with all the patches (including the 
last one from Andrew that avoids "dirty" going negative under some 
circumstances, and explains the "slow and/or never completed" case that 
Gordon and Martin saw).

The good news is that I think the code now is cleaner and more 
understandable. The bad news is that nothing we've ever tried seems to 
have fixed the _problem_.

And I don't think it's page_mkclean(). Especially not since the ARM people 
are seeing this under UP without PREEMPT. In that kind of schenario, the 
only possible races tend to be from things that actually block: 
"set_page_dirty()" (which blocks on IO in balancing), memory allocations, 
and obviously doing actual IO.

And it's not a virtual cache problem, since others see it on x86.

Of course, since it's quite possibly two different issues, maybe the 
virtual cache flush is required in order to force write-back to memory 
(which in turn is required for the DMA for the actual write!). So the ARM 
issue certainly could be due to the flush_cache_page() thing...

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

[PATCH 1/1] - Altix: ACPI _PRT support

[John Keller]

Provide ACPI _PRT support for SN Altix systems.

The SN Altix platform does not conform to the 
IOSAPIC IRQ routing model, so a new acpi_irq_model
(ACPI_IRQ_MODEL_PLATFORM) has been defined. The SN
platform specific code sets acpi_irq_model to
this new value, and keys off of it in acpi_register_gsi()
to avoid the iosapic code path.

Signed-off-by: John Keller <[EMAIL PROTECTED]>
---

To avoid future regression/backward compatibilty issues
when _PRT support is added to our PROM, we'd like to
see this pushed into 2.6.20, if at all possible.


 arch/ia64/kernel/acpi.c|3 +++
 arch/ia64/sn/kernel/io_acpi_init.c |3 +++
 drivers/acpi/bus.c |3 +++
 include/linux/acpi.h   |1 +
 4 files changed, 10 insertions(+)


Index: linux/arch/ia64/kernel/acpi.c
===
--- linux.orig/arch/ia64/kernel/acpi.c  2006-10-24 02:38:54.0 -0500
+++ linux/arch/ia64/kernel/acpi.c   2006-12-22 10:54:36.930343639 -0600
@@ -590,6 +590,9 @@ void __init acpi_numa_arch_fixup(void)
  */
 int acpi_register_gsi(u32 gsi, int triggering, int polarity)
 {
+   if (acpi_irq_model == ACPI_IRQ_MODEL_PLATFORM)
+   return gsi;
+
if (has_8259 && gsi < 16)
return isa_irq_to_vector(gsi);
 
Index: linux/arch/ia64/sn/kernel/io_acpi_init.c
===
--- linux.orig/arch/ia64/sn/kernel/io_acpi_init.c   2006-12-21 
00:51:59.0 -0600
+++ linux/arch/ia64/sn/kernel/io_acpi_init.c2006-12-22 10:53:45.504213484 
-0600
@@ -223,6 +223,9 @@ sn_io_acpi_init(void)
u64 result;
s64 status;
 
+   /* SN Altix does not follow the IOSAPIC IRQ routing model */
+   acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
+
acpi_bus_register_driver(_sn_hubdev_driver);
status = sal_ioif_init();
if (status || result)
Index: linux/drivers/acpi/bus.c
===
--- linux.orig/drivers/acpi/bus.c   2006-08-28 20:40:10.0 -0500
+++ linux/drivers/acpi/bus.c2006-12-22 10:52:32.155474439 -0600
@@ -561,6 +561,9 @@ static int __init acpi_bus_init_irq(void
case ACPI_IRQ_MODEL_IOSAPIC:
message = "IOSAPIC";
break;
+   case ACPI_IRQ_MODEL_PLATFORM:
+   message = "platform specific model";
+   break;
default:
printk(KERN_WARNING PREFIX "Unknown interrupt routing model\n");
return -ENODEV;
Index: linux/include/linux/acpi.h
===
--- linux.orig/include/linux/acpi.h 2006-10-24 02:38:54.0 -0500
+++ linux/include/linux/acpi.h  2006-12-22 10:52:53.337997675 -0600
@@ -47,6 +47,7 @@ enum acpi_irq_model_id {
ACPI_IRQ_MODEL_PIC = 0,
ACPI_IRQ_MODEL_IOAPIC,
ACPI_IRQ_MODEL_IOSAPIC,
+   ACPI_IRQ_MODEL_PLATFORM,
ACPI_IRQ_MODEL_COUNT
 };
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Section mismatch on current git head

[Randy Dunlap]

On Fri, 22 Dec 2006 15:24:41 +0100 Thomas Meyer wrote:

> Hello.
> 
> What kind of problem is this:
> 1.) the one that should be fixed, but also can be ignored or
> 2.) the one that have to be fixed and ignorance is a bad idea?
> 

Is this with CONFIG_RELOCATABLE=y?
There were some patches posted to address section mismatches
with that config option.  I suppose that they will be in the
next -mm release (?), so this needs to be retested with
those patches applied.

> WARNING: vmlinux - Section mismatch: reference to .init.data:boot_params 
> from .text between '_text' (at offset 0xc0100029) and 'startup_32_smp'
> WARNING: vmlinux - Section mismatch: reference to .init.data:boot_params 
> from .text between '_text' (at offset 0xc0100037) and 'startup_32_smp'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:init_pg_tables_end from .text between '_text' (at offset 
> 0xc0100099) and 'startup_32_smp'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'checkCPUtype' (at offset 
> 0xc0100126) and 'is486'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'checkCPUtype' (at offset 
> 0xc0100130) and 'is486'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'checkCPUtype' (at offset 
> 0xc010014f) and 'is486'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'checkCPUtype' (at offset 
> 0xc0100160) and 'is486'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'checkCPUtype' (at offset 
> 0xc0100166) and 'is486'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'checkCPUtype' (at offset 
> 0xc010016c) and 'is486'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'checkCPUtype' (at offset 
> 0xc0100172) and 'is486'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'checkCPUtype' (at offset 
> 0xc0100188) and 'is486'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'checkCPUtype' (at offset 
> 0xc0100192) and 'is486'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'checkCPUtype' (at offset 
> 0xc010019b) and 'is486'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'checkCPUtype' (at offset 
> 0xc01001a1) and 'is486'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'check_x87' (at offset 
> 0xc010021b) and 'setup_pda'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.data:new_cpu_data from .text between 'check_x87' (at offset 
> 0xc010023a) and 'setup_pda'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.text:start_kernel from .text between 'is386' (at offset 
> 0xc0100215) and 'check_x87'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.text:smp_prepare_cpus from .text between 'init' (at offset 
> 0xc01003db) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.text:migration_init from .text between 'init' (at offset 
> 0xc01003e0) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.text:spawn_ksoftirqd from .text between 'init' (at offset 
> 0xc01003e5) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.text:smp_cpus_done from .text between 'init' (at offset 
> 0xc0100459) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.text:sched_init_smp from .text between 'init' (at offset 
> 0xc010045e) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.text:cpuset_init_smp from .text between 'init' (at offset 
> 0xc0100463) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.text:usermodehelper_init from .text between 'init' (at offset 
> 0xc010046d) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to .init.text:driver_init 
> from .text between 'init' (at offset 0xc0100472) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to .init.text:sysctl_init 
> from .text between 'init' (at offset 0xc0100477) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to .init.data: from .text 
> between 'init' (at offset 0xc010048c) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to .init.data: from .text 
> between 'init' (at offset 0xc01004ca) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.text:prepare_namespace from .text between 'init' (at offset 
> 0xc010058d) and 'rest_init'
> WARNING: vmlinux - Section mismatch: reference to 
> .init.text:efi_set_rtc_mmss from .text between 'sync_cmos_clock' (at 
> offset 0xc0105987) and 'get_cmos_time'
> WARNING: vmlinux - Section mismatch: 

Re: [PATCH] Rename FIELD_SIZEOF to MEMBER_SIZE and use in source tree.

[Robert P. J. Day]

On Fri, 22 Dec 2006, Randy Dunlap wrote:

> On Fri, 22 Dec 2006 10:34:09 -0500 (EST) Robert P. J. Day wrote:
>
> >
> >   Rename the macro FIELD_SIZEOF() in include/linux/kernel.h to
> > MEMBER_SIZE(), and make a number of replacements in the source tree
> > where that macro simplified the code.
>
> Hi,
>
> Your CodingStyle ch. 17 additions also need to be updated
> if/when they are merged (since they refer to FIELD_SIZEOF()).
> Did Andrew add that to -mm?  I don't recall.

yes, that went in already.  re-reading christopher's recent posting,
he seems fairly convinced that that macro should be called either
SIZEOF_FIELD or FIELD_SIZE.  i'm happy with either choice, so someone
else can make the decision and i'll go with it.

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

bcm43xx from 2.6.20-rc1-mm1 on HPC nx6325 (x86_64)

[Larry Finger]

I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on
an HPC nx6325, with no luck, so far, although I'm using a firmware that has
been reported to work with these boxes
(http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29).

The driver loads and seems to operate the hardware to some extent, but there
seems to be a problem with interrupts. Namely, the chip doesn't seem to
generate any.
Raphael J. Wysocki wrote:

> Right after a fresh 'modprobe bcm43xx' I get the following messages in dmesg:

> bcm43xx driver
> ACPI: PCI Interrupt :30:00.0[A] -> GSI 18 (level, low) -> IRQ 18
> PCI: Setting latency timer of device :30:00.0 to 64
> bcm43xx: Chip ID 0x4311, rev 0x1
> bcm43xx: Number of cores: 4
> bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243
> bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243
> bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243
> bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243
> bcm43xx: PHY connected
> bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8
> bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
> bcm43xx: Radio turned off
> bcm43xx: Radio turned off
> PM: Adding info for No Bus:eth1
> printk: 3 messages suppressed.
> SoftMAC: ASSERTION FAILED (0) at: > 
net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate()

>
> but, strangely enough, eth1 does not appear, but eth2 appears instead:
>

Usually the problem generates an oops, but I think your problem is due to the changes in the work 
struct in 2.6.20-rc1. There is a fix in the pipeline, but it has not propagated through the system.


You should apply the work_struct2 patch attached. If your computer has a switch to kill the RF, you 
may also wish to apply the radio_hwenable patch, which should cause the radio LED to be turned on.


The selection of eth2 rather than eth1 is probably due to the rules in 
/etc/udev/rules.d/30-net_persistent_names.rules. When I boot a softmac version, my bcm43xx device is 
wlan0, but when I boot the d80211 version, it is eth1. I have a second bcm43xx card, which becomes 
eth2 under softmac.


Larry
From: Ulrich Kunitz <[EMAIL PROTECTED]>

The signature of work functions changed recently from a context
pointer to the work structure pointer. This caused a problem in
the ieee80211softmac code, because the ieee80211softmac_assox_work
function has  been called directly with a parameter explicitly
casted to (void*). This compiled correctly but resulted in a
softlock, because mutex_lock was called with the wrong memory
address. The patch fixes the problem. Another issue was a wrong
call of the schedule_work function. Softmac works again and this
fixes the problem I mentioned earlier in the zd1211rw rx tasklet
patch. The patch is against Linus' tree (commit af1713e0).

Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---

John,

This patch should be pushed upstream to 2.6.20. At the moment, the work
struct changes have not yet propagated to wireless-2.6. When they do,
it will be needed there as well.

Larry

 net/ieee80211/softmac/ieee80211softmac_assoc.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c 
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index eec1a1d..a824852 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -167,7 +167,7 @@ static void
 ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type, 
void *context)
 {
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
-   ieee80211softmac_assoc_work((void*)mac);
+   ieee80211softmac_assoc_work(>associnfo.work.work);
 }
 
 static void
@@ -177,7 +177,7 @@ ieee80211softmac_assoc_notify_auth(struc
 
switch (event_type) {
case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
-   ieee80211softmac_assoc_work((void*)mac);
+   ieee80211softmac_assoc_work(>associnfo.work.work);
break;
case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT:

Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2441,6 +2441,9 @@ static int bcm43xx_chip_init(struct bcm4
if (err)
goto err_gpio_cleanup;
bcm43xx_radio_turn_on(bcm);
+   bcm->radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
+   printk(KERN_INFO PFX "Radio %s by hardware\n",
+   (bcm->radio_hw_enable == 0) ? "disabled" : "enabled");
 
bcm43xx_write16(bcm, 0x03E6, 0x);
err = bcm43xx_phy_init(bcm);
@@ -3172,9 +3175,24 @@ static void bcm43xx_periodic_every30sec(
 
 static void 

Re: 2.6.19 file content corruption on ext3

[Linus Torvalds]

On Mon, 18 Dec 2006, Gene Heskett wrote:
>
> What about the mm/rmap.c one liner, in or out?

The one that just removes the "pte_mkclean()"? That's definitely out, it 
was just a test-patch to verify that the pte dirty bits seemed to matter 
at all (and they do).

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

Re: [RFC PATCH 1/8] rqbased-dm: allow blk_get_request() to be called from interrupt context

[Jens Axboe]

On Fri, Dec 22 2006, Christoph Hellwig wrote:
> On Wed, Dec 20, 2006 at 12:50:02PM -0500, Kiyoshi Ueda wrote:
> > Because I'd like to use blk_get_request() in q->request_fn()
> > which can be called from interrupt context like below:
> >   scsi_io_completion -> scsi_end_request -> scsi_next_command
> >   -> scsi_run_queue -> blk_run_queue -> q->request_fn
> 
> > Or request should not be allocated in q->request_fn() anyway?
> > Do you have any other ideas?
> 
> The right long-term fix is to make sure request_fn is only ever called
> from process context.  This means moving retry handling to a thread instead
> of a softirq, but this will need careful performance testing and tweaking.

It's a lot more than just retry handling. Most driver reinvoke queueing
from the completion handling, so basically most of the time request_fn
is run from either softirq (like SCSI) or interrupt context (like IDE).

-- 
Jens Axboe

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

Re: [PATCH] Rename FIELD_SIZEOF to MEMBER_SIZE and use in source tree.

[Randy Dunlap]

On Fri, 22 Dec 2006 10:34:09 -0500 (EST) Robert P. J. Day wrote:

> 
>   Rename the macro FIELD_SIZEOF() in include/linux/kernel.h to
> MEMBER_SIZE(), and make a number of replacements in the source tree
> where that macro simplified the code.

Hi,

Your CodingStyle ch. 17 additions also need to be updated
if/when they are merged (since they refer to FIELD_SIZEOF()).
Did Andrew add that to -mm?  I don't recall.

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

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

[Martin Michlmayr]

* Gordon Farquharson <[EMAIL PROTECTED]> [2006-12-22 08:30]:
> Based on the kernel gurus current knowledge of the problem, would
> you expect the corruption to occur at the same point in a file, or
> is it possible that the corruption could occur at different points
> on successive Debian installer attempts on a UP, non PREEMPT system?

Seems like it can occur anywhere.  In fact, some people see apt
problems because of filesystem corruption on the NSLU2 after they have
already installe Debian.  I've only seen this once myself and failed
many times to find a reproducible situation.
-- 
Martin Michlmayr
http://www.cyrius.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/

Question about the io_context of I/O scheduler

[Roy Lee]

Hi,

I'm currently tracing the I/O path of the kernel (2.6.19 release)

for the I/O scheduler, as far I as know, io_context is currently based on
per-process basis.
so, when an user process issued an I/O, the request generated in the kernel 
will be associated to the io_context of the "current" process, right?

but, isn't there some request generated in the kernel code which is not
relevant to the I/O pattern of the "current" user process?
for example, when the request generated to handle the page fault
or the kernel is paging out other process' pages due to memory pressure.

is this an issue or did I miss something?


thanks in advance for clearifying this.

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

[PATCH] Fix some ARM builds due to HID brokenness

[Russell King]

The new location for HID is extremely annoying:

1. the help text implies that you need to enable it for any
   keyboard or mouse attached to the system.  This is not
   correct.

2. it defaults to 'y'.  When you have input deselected, this
   causes the kernel to fail to link:

drivers/built-in.o: In function `usb_hidinput_input_event':
hid-input.c:(.text+0x55054): undefined reference to `input_ff_event'
drivers/built-in.o: In function `hidinput_hid_event':
hid-input.c:(.text+0x6446c): undefined reference to `input_event'
hid-input.c:(.text+0x644f8): undefined reference to `input_event'
hid-input.c:(.text+0x64550): undefined reference to `input_event'
hid-input.c:(.text+0x64590): undefined reference to `input_event'
hid-input.c:(.text+0x645b8): undefined reference to `input_event'
drivers/built-in.o: In function `hidinput_disconnect':
hid-input.c:(.text+0x64624): undefined reference to `input_unregister_device'
drivers/built-in.o: In function `hidinput_report_event':
hid-input.c:(.text+0x64670): undefined reference to `input_event'
drivers/built-in.o: In function `hidinput_connect':
hid-input.c:(.text+0x64824): undefined reference to `input_allocate_device'
hid-input.c:(.text+0x675e0): undefined reference to `input_register_device'
hid-input.c:(.text+0x67698): undefined reference to `input_free_device'
hid-input.c:(.text+0x676b8): undefined reference to `input_register_device'
make: *** [.tmp_vmlinux1] Error 1

Fix the second problem by making it depend on INPUT.  The first
problem is left as an exercise for the HID maintainers to solve.

Signed-off-by: Russell King <[EMAIL PROTECTED]>

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 96d4a0b..1ccc222 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -6,6 +6,7 @@ menu "HID Devices"
 
 config HID
tristate "Generic HID support"
+   depends on INPUT
default y
---help---
  Say Y here if you want generic HID support to connect keyboards,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Marc Haber]

On Sat, Dec 16, 2006 at 06:43:10PM +, Martin Michlmayr wrote:
> * Marc Haber <[EMAIL PROTECTED]> [2006-12-09 10:26]:
> > Unfortunately, I am lacking the knowledge needed to do this in an
> > informed way. I am neither familiar enough with git nor do I possess
> > the necessary C powers.
> 
> I wonder if what you're seein is related to
> http://lkml.org/lkml/2006/12/16/73
> 
> You said that you don't see any corruption with 2.6.18.  Can you try
> to apply the patch from
> http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d08b3851da41d0ee60851f2c75b118e1f7a5fc89
> to 2.6.18 to see if the corruption shows up?

Since I am no longer seeing the issue after easing the memory load, I
doubt that this would make sense.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/