Re: [PATCH RFC] libata: FUA updates

2007-02-20 Thread Tejun Heo
Robert Hancock wrote:
> This updates libata FUA support to be more more in line with reality.
> FUA support remains off by default.
> 
> Add a setting for the fua command-line parameter on libata which enables
> FUA only on NCQ-supporting disks.
> 
> Update the ata_dev_supports_fua function to remove the blacklisting of
> Maxtor BANC1G10 firmware, as there is no conclusive evidence it was ever
> needed.
> 
> Centralize all of the FUA on/off decisions in this function.
> 
> Bypass the checks for FUA command support bit for NCQ disks, since that
> bit only applies to non-NCQ FUA, and FUA is part of the spec for NCQ
> commands.
> 
> When queue depth is set by the user resulting in enabling/disabling
> NCQ, trigger a revalidate so that the FUA state will be rechecked,
> since disabling/enabling NCQ may also affect FUA support on some disks.
> 
> Add a controller flag to indicate it doesn't support FUA commands, and
> set this flag for Silicon Image 311x (since that one is known to have
> problems) as well as for ITE821x when in smart mode.
> 
> Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

Yeap, I like the clean up.  Just a few comments.

* s/if(/if (/

* The patch adds a number of trailing white spaces.  I suggest using git
or quilt for patch management.  They complain when they see such things.

I'm still not so sure about NCQ FUA.  I still think that separate opcode
for FUA ops is the right thing to do (tm), well, or the safer thing to
do (tm).  Regarding drives which support NCQ but not separate opcode for
FUA, unless many drives are like that, I don't think the loss is too
great.  Also, I'm more uncomfortable with trusting those drives doing
NCQ FUA properly.

Let's talk about this on the other thread.

Thanks.

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


Re: [RFC] split NAPI from network device.

2007-02-20 Thread David Miller
From: Divy Le Ray <[EMAIL PROTECTED]>
Date: Tue, 20 Feb 2007 23:39:55 -0800

> I applied the patch to test the chelsio drivers.
> The compilation of the forcedeth driver fails if CONFIG_FORCEDETH_NAPI 
> is not set.
> /opt/sources/linux-2.6/drivers/net/forcedeth.c: In function `nv_nic_irq':
> /opt/sources/linux-2.6/drivers/net/forcedeth.c:2866: error: structure 
> has no member named `weight'
> /opt/sources/linux-2.6/drivers/net/forcedeth.c: In function 
> `nv_nic_irq_optimized':
> /opt/sources/linux-2.6/drivers/net/forcedeth.c:2983: error: structure 
> has no member named `weight'
> /opt/sources/linux-2.6/drivers/net/forcedeth.c: In function `nv_nic_irq_rx':
> /opt/sources/linux-2.6/drivers/net/forcedeth.c:3177: error: structure 
> has no member named `weight'

Thanks for catching that, I'll fix this up.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] split NAPI from network device.

2007-02-20 Thread Divy Le Ray

David Miller wrote:

From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 13 Dec 2006 15:46:35 -0800

  

Split off NAPI part from network device, this patch is build tested
only! It breaks kernel API for network devices, and only three examples
are fixed (skge, sky2, and tg3).

1. Decomposition allows different NAPI <-> network device
   Some hardware has N devices for one IRQ, others like MSI-X
   want multiple receive's for one device.

2. Cleanup locking with netpoll

3. Change poll callback arguements and semantics

4. Make softnet_data static (only in dev.c)

Old:
dev->poll(dev, )
returns 1 or 0
requeu if returns 1

New:
napi->poll(napi, quota)
returns # of elements processed
requeue based on status

Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>



I rebuffed this patch against current 2.6.x GIT and fixed all of
the drivers.

  

Hi Dave,

I applied the patch to test the chelsio drivers.
The compilation of the forcedeth driver fails if CONFIG_FORCEDETH_NAPI 
is not set.

/opt/sources/linux-2.6/drivers/net/forcedeth.c: In function `nv_nic_irq':
/opt/sources/linux-2.6/drivers/net/forcedeth.c:2866: error: structure 
has no member named `weight'
/opt/sources/linux-2.6/drivers/net/forcedeth.c: In function 
`nv_nic_irq_optimized':
/opt/sources/linux-2.6/drivers/net/forcedeth.c:2983: error: structure 
has no member named `weight'

/opt/sources/linux-2.6/drivers/net/forcedeth.c: In function `nv_nic_irq_rx':
/opt/sources/linux-2.6/drivers/net/forcedeth.c:3177: error: structure 
has no member named `weight'


The compilation of the cxgb driver also fails if CONFIG_CHELSIO_T1_NAPI 
is not set, but it has nothing to do with your patch.

I'm looking into it.

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


Re: iwlwifi warnings

2007-02-20 Thread Randy Dunlap
On Tue, 20 Feb 2007 22:23:21 -0800 Stephen Hemminger wrote:

> BUilding with sparse shows lots of warnings.
> 
> 
> $ make C=1
> Checking kernel compatibility in:
> /lib/modules/2.6.20.1/source
>  * Kernel supports required features for 'tip' version.
> Building compatibility version in 'compatible/' directory:
> Copying compatible/ from origin/...done
> make -C /lib/modules/2.6.20.1/build M=/home/shemminger/src/iwlwifi-0.0.8 
> modules

[snip]

Good point(s).  Please try to use Documentation/SubmitChecklist,
as indicated in Andrew's -mm announcements (and copied in my sig below).

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


RE: SATA problems

2007-02-20 Thread Paul Rolland
Hi Marcus,

Could you give more details ? I'm stucked with a boot problem on a 
Asus P5W that also includes a Jmicron behind a Sata port on ICH8, and
the kernel boot goes timeout when probing it... I've been trying various
kernels,
including some patches from Tejun (Thanks !), but no luck to date...

Mind sharing your .config so that I can check if I missed something obvious ?

Regards,
Paul

Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator

--

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur 
"Some people dream of success... while others wake up and work hard at it" 

"I worry about my child and the Internet all the time, even though she's too 
young to have logged on yet. Here's what I worry about. I worry that 10 or 15 
years from now, she will come to me and say 'Daddy, where were you when they 
took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 
  

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Marcus Haebler
> Sent: Wednesday, February 21, 2007 7:24 AM
> To: Tejun Heo
> Cc: Pablo Sebastian Greco; linux-kernel@vger.kernel.org
> Subject: Re: SATA problems
> 
> Tejun,
> 
> I checked out the kernel 2.6.19 to 2.6.20 Changelog. Seems like you
> fixed a problem with the JMB363. The Asus P5B-Deluxe I am using has a
> JMB363 - besides an Intel ICH8R - with the SATA ports set to AHCI as
> well. Looks like that might have been the source of the problem in
> 2.6.19.
> 
> Thanks,
> 
> Marcus
> 
> On 2/21/07, Marcus Haebler <[EMAIL PROTECTED]> wrote:
> > Tejun,
> >
> > thanks. In preparation of your patch I installed a vanilla 2.6.20.1
> > kernel on my FC6
> > system. Amazingly the problem went away with the vanilla(!) 
> kernel and NCQ
> > is enabled at boot time (queue_depth is 31). I guess I should have
> > tried that kernel
> > earlier.
> >
> > The patches you sent earlier apply w/o problems against the 2.6.20.1
> > vanilla kernel
> > which is expected. I will test drive those patches tomorrow.
> >
> > BTW thanks for saving me the 'cat' on the 3 patches. ;)
> >
> > Thanks,
> >
> > Marcus
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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


[PATCH 1/2][IPX] Remove outdated information from Kconfig

2007-02-20 Thread Rolf Eike Beer
SPX was removed in early 2.5. How to connect to a Mac or the other OS isn't
hard to find out these days.

Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>

---
commit 0566e9a5f19ca9fe1982e2b4a89aff131cc6525b
tree 20b72b4e347a0ff926f82188bb296c2b3a8911f5
parent ce4e52a8be675c1724fa3af503ff1c75478ff2e8
author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 20 Feb 2007 19:43:37 +0100
committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 20 Feb 2007 19:43:37 +0100

 net/ipx/Kconfig |6 +-
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/net/ipx/Kconfig b/net/ipx/Kconfig
index 980a826..e9ad006 100644
--- a/net/ipx/Kconfig
+++ b/net/ipx/Kconfig
@@ -16,8 +16,7 @@ config IPX
  support", below.
 
  IPX is similar in scope to IP, while SPX, which runs on top of IPX,
- is similar to TCP. There is also experimental support for SPX in
- Linux (see "SPX networking", below).
+ is similar to TCP.
 
  To turn your Linux box into a fully featured NetWare file server and
  IPX router, say Y here and fetch either lwared from
@@ -26,9 +25,6 @@ config IPX
  information, read the IPX-HOWTO available from
  .
 
- General information about how to connect Linux, Windows machines and
- Macs is on the WWW at .
-
  The IPX driver would enlarge your kernel by about 16 KB. To compile
  this driver as a module, choose M here: the module will be called ipx.
  Unless you want to integrate your Linux box with a local Novell
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2][IPX] Remove ancient changelog

2007-02-20 Thread Rolf Eike Beer
[IPX] Remove ancient changelog

Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>

---
commit 6b8afc66b9d6893d3fa292b75769b58539836ff3
tree 9078513bb6727e61aee238da153d9b3358a1d817
parent 0566e9a5f19ca9fe1982e2b4a89aff131cc6525b
author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 20 Feb 2007 19:45:03 +0100
committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 20 Feb 2007 19:45:03 +0100

 net/ipx/ChangeLog |  101 -
 1 files changed, 0 insertions(+), 101 deletions(-)

diff --git a/net/ipx/ChangeLog b/net/ipx/ChangeLog
deleted file mode 100644
index 3b29763..000
--- a/net/ipx/ChangeLog
+++ /dev/null
@@ -1,101 +0,0 @@
- Revision 0.21:Uses the new generic socket option code.
-
- Revision 0.22:Gcc clean ups and drop out device registration. Use the
-   new multi-protocol edition of hard_header
-
- Revision 0.23: IPX /proc by Mark Evans. Adding a route will
-   will overwrite any existing route to the same network.
-
- Revision 0.24:Supports new /proc with no 4K limit
-
- Revision 0.25:Add ephemeral sockets, passive local network
-   identification, support for local net 0 and
-   multiple datalinks 
-
- Revision 0.26: Device drop kills IPX routes via it. (needed for module)
-
- Revision 0.27: Autobind 
-
- Revision 0.28: Small fix for multiple local networks 
-
- Revision 0.29: Assorted major errors removed 
-   Small correction to promisc mode error fix 
-   Asynchronous I/O support. Changed to use notifiers
-   and the newer packet_type stuff. Assorted major
-   fixes 
-
- Revision 0.30:Moved to net/ipx/...
-   Don't set address length on recvfrom that errors.
-   Incorrect verify_area.
-
- Revision 0.31:New sk_buffs. This still needs a lot of 
-   testing. 
-
- Revision 0.32: Using sock_alloc_send_skb, firewall hooks. 
-   Supports sendmsg/recvmsg
-
- Revision 0.33:Internal network support, routing changes, uses a
-   protocol private area for ipx data.
-
- Revision 0.34:Module support. 
-
- Revision 0.35: Checksum support. , hooked in by 
-   Handles WIN95 discovery packets 
-
- Revision 0.36:Internal bump up for 2.1
-
- Revision 0.37:Began adding POSIXisms.
-
- Revision 0.38: Asynchronous socket stuff made current.
-
- Revision 0.39: SPX interfaces
-
- Revision 0.40: Tiny SIOCGSTAMP fix ([EMAIL PROTECTED])
-
- Revision 0.41: 802.2TR removed ([EMAIL PROTECTED])
-   Fixed connecting to primary net,
-   Automatic binding on send & receive,
-   Martijn van Oosterhout <[EMAIL PROTECTED]>
-
- Revision 042:  Multithreading - use spinlocks and refcounting to
-   protect some structures: ipx_interface sock list, list
-   of ipx interfaces, etc. 
-   Bugfixes - do refcounting on net_devices, check function
-   results, etc. Thanks to davem and freitag for
-   suggestions and guidance.
-   Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>,
-   November, 2000
-
- Revision 043: Shared SKBs, don't mangle packets, some cleanups
-   Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>,
-   December, 2000
-
- Revision 044: Call ipxitf_hold on NETDEV_UP - acme
-
- Revision 045: fix PPROP routing bug - acme
-
- Revision 046: Further fixes to PPROP, ipxitf_create_internal was
-   doing an unneeded MOD_INC_USE_COUNT, implement
-   sysctl for ipx_pprop_broacasting, fix the ipx sysctl
-   handling, making it dynamic, some cleanups, thanks to
-   Petr Vandrovec for review and good suggestions. (acme)
-
- Revision 047: Cleanups, CodingStyle changes, move the ncp connection
-   hack out of line - acme
-
- Revision 048: Use sk->protinfo to store the pointer to IPX private
-   area, remove af_ipx from sk->protinfo and move ipx_opt
-   to include/net/ipx.h, use IPX_SK like DecNET, etc - acme
-
- Revision 049: SPX support dropped, see comment in ipx_create - acme
-
- Revision 050: Use seq_file for proc stuff, moving it to ipx_proc.c - acme
-
-Other fixes:
- 
- Protect the module by a MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT pair. Also, now
- usage count is managed this way:
- -Count one if the auto_interface mode is on
- -Count one per configured interface
- 
- Jacques Gelinas ([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 0/2] Remove outdated information from IPX

2007-02-20 Thread Rolf Eike Beer
Who cares about stuff describing what happened in early 2.5 days? Even worse 
is to reference Kconfig options removed back then. Go, rest in pieces.

Eike


pgpjdAVzZTifL.pgp
Description: PGP signature


Re: [2.6 patch] drivers/infiniband/hw/cxgb3/: possible cleanups

2007-02-20 Thread Roland Dreier
 > You could just remove the code instead of #if 0...

Steve, can you decide what the right thing to do with these changes is
and send me the result (or just tell me to apply Adrian's patch
as-is)?

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


Re: ata command timeout

2007-02-20 Thread Tejun Heo
Jeff Garzik wrote:
> Mark Lord wrote:
>> I don't believe that.  Command timeouts never happen on healthy systems,
>> unless we have a driver bug.  Okay, so I can imagine a pathological case
>> of a full queue (NCQ) with all 32 commands taking longer than usual due
>> to ECC retries in the firmware..
> 
> It's not quite so black and white.  There have definitely been interrupt
> delivery problems that cause command timeouts.  Also, Intel PIIX BMDMA
> (all standard PCI IDE, I think?) is defined to /not/ send an interrupt,
> when a DMA error occurs.  The driver is instructed to time out the
> transaction, and start recovery by deducing the state of things from the
> DMA status bits.
> 
> Nonetheless, I mostly agree with your statement.  The two most common
> causes of timeouts that I see are interrupt delivery problems, and
> driver bugs.

Oh.. well.  My experience is that it's much more common on SATA compared
to PATA.  SATA link seems to be one of the most vulnerable parts to
interference.  When PSU has the slightest of problem, SATA drives
timeout or give transmission problems.  System often survives brief
fluctuation in power input (e.g. when the compressor starts up) but SATA
link sometimes reports error after such event.

Or just buy a static generator and apply it to your computer case.
Generally system is perfectly okay with that but the SATA devices tend
to complain or timeout.

Those condition might not be considered too healthy in any server
environment but they do occur on cheap desktop environment.  I mean, a
lot of people are putting 10USD PSU into their desktop machines.

So, yeah, it might be a driver or other problem but if problem is very
intermittent, I tend to lean toward transient hardware problem and
that's primarily why I wanna make EH kick in and recover faster.

Thanks.

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


Re: [patch 1/2] sched: fix idle load balancing in softirqd context

2007-02-20 Thread Siddha, Suresh B
On Sat, Feb 17, 2007 at 09:42:16AM -0500, Steven Rostedt wrote:
> On Fri, 16 Feb 2007, Siddha, Suresh B wrote:
> > -   int cpu = smp_processor_id();
> > +   int cpu = smp_processor_id(), idle_at_tick = idle_cpu(cpu);
> > struct rq *rq = cpu_rq(cpu);
> >
> 
> But I would recommend that the idle_at_tick should be on a separate line.

Ok.

> I'll try to look deeper at your patches tomorrow. I've also found that I'm
> having some latency problems in -rt that I think might be related to
> migration.

There is one more issue, I have observed in -rt tree.

raise_softirq_irqoff() is unconditionally doing the wakeup_softirqd()
But unless the CONFIG_PREEMPT_SOFTIRQS is configured, do_softirq()
will process the softirq's like TIMER_SOFTIRQ and SCHED_SOFTIRQ in the
process context.  So it looks like we are unnecessarily waking the
softirqd's corresponding to those softirq's.

thanks,
suresh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-mm2 -- tifm/0/1919 is trying to release lock (>lock) at: [] tifm_7xx1_switch_media+0x2e9/0x326 [tifm_7xx1]

2007-02-20 Thread Miles Lane

Hello,

When I pull my SD card out of my laptop, I get the following:

tifm_7xx1: demand removing card from socket 3
=
[ BUG: bad unlock balance detected! ]
-
tifm/0/1919 is trying to release lock (>lock) at:
[] tifm_7xx1_switch_media+0x2e9/0x326 [tifm_7xx1]
but there are no more locks to release!

other info that might help us debug this:
no locks held by tifm/0/1919.

stack backtrace:
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] print_unlock_inbalance_bug+0xec/0xf9
[] lock_release+0x9b/0x17c
[] _spin_unlock_irqrestore+0x19/0x3c
[] tifm_7xx1_switch_media+0x2e9/0x326 [tifm_7xx1]
[] kthread+0xa3/0xcf
[] kernel_thread_helper+0x7/0x10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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(Experimental) 2/4] Revert changes to workqueue.c

2007-02-20 Thread Srivatsa Vaddagiri
On Tue, Feb 20, 2007 at 11:09:36PM +0300, Oleg Nesterov wrote:
> > Which caller are you referring to here? Maybe we can decide on the
> > option after we see the users of flush_workqueue() in DOWN_PREPARE.
> 
> mm/slab.c:cpuup_callback()

The cancel_rearming_delayed_work, if used as it is in cpuup_callback,
will require that we send DOWN_PREPARE before freeze_processes().

But ..I am wondering if we can avoid doing cancel_rearming_delayed_work
(and thus flush_workqueue) in CPU_DOWN_PREPARE of slab.c. Basically,

mm/slab.c:

CPU_DOWN_PREPARE:   /* All processes frozen now */
cancel_delayed_work(_cpu(reap_work, cpu).timer);
del_work(_cpu(reap_work, cpu).work);
break;


At the point of CPU_DOWN_PREPARE, keventd should be frozen and hence
del_work() is a matter of just deleting the work from cwq->worklist.


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


Re: SATA problems

2007-02-20 Thread Marcus Haebler

Tejun,

I checked out the kernel 2.6.19 to 2.6.20 Changelog. Seems like you
fixed a problem with the JMB363. The Asus P5B-Deluxe I am using has a
JMB363 - besides an Intel ICH8R - with the SATA ports set to AHCI as
well. Looks like that might have been the source of the problem in
2.6.19.

Thanks,

Marcus

On 2/21/07, Marcus Haebler <[EMAIL PROTECTED]> wrote:

Tejun,

thanks. In preparation of your patch I installed a vanilla 2.6.20.1
kernel on my FC6
system. Amazingly the problem went away with the vanilla(!) kernel and NCQ
is enabled at boot time (queue_depth is 31). I guess I should have
tried that kernel
earlier.

The patches you sent earlier apply w/o problems against the 2.6.20.1
vanilla kernel
which is expected. I will test drive those patches tomorrow.

BTW thanks for saving me the 'cat' on the 3 patches. ;)

Thanks,

Marcus

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


iwlwifi warnings

2007-02-20 Thread Stephen Hemminger

BUilding with sparse shows lots of warnings.


$ make C=1
Checking kernel compatibility in:
   /lib/modules/2.6.20.1/source
* Kernel supports required features for 'tip' version.
Building compatibility version in 'compatible/' directory:
Copying compatible/ from origin/...done
make -C /lib/modules/2.6.20.1/build M=/home/shemminger/src/iwlwifi-0.0.8 
modules

make[1]: Entering directory `/home/shemminger/kernel/linux-2.6.20.1'
 CHECK   /home/shemminger/src/iwlwifi-0.0.8/compatible/base.c
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:5:12: warning: 
function 'ipw_rate_scale_clear_window' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11352:12: warning: 
function 'ipw_collect_tx_data' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11480:12: warning: 
function 'ipw_convert_to_rate_index' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11665:12: warning: 
function 'ipw_convert_to_phy_index' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11677:30: warning: 
function 'ipw_get_lowest_rate' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11692:12: warning: 
function 'ipw_get_adjacent_rate' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:1522:11: warning: 
Using plain integer as NULL pointer
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:10004:16: warning: 
Using plain integer as NULL pointer

 CC [M]  /home/shemminger/src/iwlwifi-0.0.8/compatible/base.o
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c: In function 
$-1òøipw_rx_handleòù:
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8175: warning: 
unused variable $-1òøsleepòù
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8195: warning: 
unused variable $-1òøbeaconòù
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8227: warning: 
unused variable $-1òønotifòù
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8259: warning: 
unused variable $-1òønotifòù

/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c: At top level:
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:3889: warning: 
$-1òøipw_set_rxon_confòù defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:2523: warning: 
$-1òøipw_rate_ieee2indexòù defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:2577: warning: 
$-1òøipw_check_rx_config_cmdòù defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:3628: warning: 
$-1òøipw_setup_rxon_timingòù defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:6931: warning: 
$-1òøipw_send_qos_params_commandòù defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:7964: warning: 
$-1òøget_tx_fail_reasonòù defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8637: warning: 
$-1òøipw_get_rate_by_rssiòù defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:10371: warning: 
$-1òød_hw_scanòù defined but not used

 LD [M]  /home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.o
 Building modules, stage 2.
 MODPOST 1 modules
WARNING: "ieee80211_rx_irqsafe" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_register_hwmode" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_unregister_hw" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_scan_completed" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_get_hdrlen" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_tx_status" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "sta_info_get" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_rate_control_register" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_netif_oper" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_tx_status_irqsafe" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_get_hdrlen_from_skb" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_rate_control_unregister" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_register_hw" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_alloc_hw" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_free_hw" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "sta_info_put" 
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
 CC  

[ANNOUNCE] Guilt v0.20

2007-02-20 Thread Josef Sipek
Guilt v0.20 is available for download (once it mirrors out on kernel.org).

Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
queues-like functionality and interface to git.

Tarballs:
http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/

Git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git

 
Pretty much all the changes are related to the patchbomb and import-commit
scripts. They now take a range of commits in one of these formats:

  - one commit
  ..  - hash until head (excludes hash, includes head)
  ..  - until hash (includes hash)
  ..  - from hash to hash (inclusive)

Josef "Jeff" Sipek.


Changes since v0.19:

Brandon Philips (1):
  guilt: Silence command echoing for echos in Makefile

Josef 'Jeff' Sipek (7):
  import-commit: simple commit to patch importer
  munge_hash_range: Helper function
  patchbomb: Use munge_hash_range
  import-commit: Use munge_hash_range
  patchbomb: Don't ask for the intro email if sending only one patch
  Centralize pager determining code
  Guilt v0.20
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: no backlight on radeon after recent kernel "upgrade"s

2007-02-20 Thread Yaroslav Halchenko
I am sorry on the delay

> > On Sun, 18 Feb 2007 23:46:16 -0500 Yaroslav Halchenko <[EMAIL PROTECTED]> 
> > wrote:
> > > Since the most recent successful for me kernel 2.6.19-rc6-mm1, I've
> > > tried few times to build more recent snapshots and now finally
> > > 2.6.20-mm2. In all those cases I have a sad outcome -- kernel boots but
> > > >...<
> > Is 2.6.20 broken?  I assume the latest 2.6.20-gitN snapshot are failing..
-mm's have been failing since some time after .19-rc6-mm1. I believe
I've tried 2.6.19-mm? with the same luck

> It would be extremely useful to know which kernel versions you tested
> and which ones failed. There are a number of backlight changes which are
> just in 2.6.20-mm1 and -mm2 which it would be useful to rule out or
> identify as the cause.
I didn't mention 2.6.20-mm1 and got to see -mm2 so it is the one which
Iv'e tried, but, once again, I experienced the same issue with 19-mm?
kernels.

I built 2.6.20-mm2 without backlight support
$> grep BACKLIGH /boot/config-2.6.20-mm2 
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_RIVA_BACKLIGHT is not set
# CONFIG_FB_RADEON_BACKLIGHT is not set

that "eliminated" the problem. Also I can see the screen with pure
2.6.20 with backlight support (whatever it does since after
loading lcd, backlight modules, my /sys/class/{lcd,backlight} are empty):

*$> grep BACKLIGH /boot/config-2.6.20 
# CONFIG_FB_BACKLIGHT is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_BACKLIGHT_DEVICE=y


> Also, do you normally see files under /sys/class/lcd?
nope... after I load lcd module, no files under :-/ regardless either it
is mm or not. But there are files under /sys/class/backlight/ for mm2
compiled with backlight support (whenever the screen is dark as per my
original email)

-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]


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


Re: SATA problems

2007-02-20 Thread Marcus Haebler

Tejun,

thanks. In preparation of your patch I installed a vanilla 2.6.20.1
kernel on my FC6
system. Amazingly the problem went away with the vanilla(!) kernel and NCQ
is enabled at boot time (queue_depth is 31). I guess I should have
tried that kernel
earlier.

The patches you sent earlier apply w/o problems against the 2.6.20.1
vanilla kernel
which is expected. I will test drive those patches tomorrow.

BTW thanks for saving me the 'cat' on the 3 patches. ;)

Thanks,

Marcus

On 2/20/07, Tejun Heo <[EMAIL PROTECTED]> wrote:

Marcus Haebler wrote:
> thanks for the patches! I am on an Intel P965/ICH8R.

I see.  That can happen too.  There was a race window where in-flight
r/w command which left SCSI midlayer but pending on libata gets executed
in the wrong mode.  If possible, please verify that it doesn't happen
with the patches applied.  I'm attaching combined patch against v2.6.20.

Thanks.

--
tejun

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 667acd2..348cc02 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -308,9 +308,7 @@ int ata_build_rw_tf(struct ata_taskfile *tf, struct 
ata_device *dev,
tf->flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
tf->flags |= tf_flags;

-   if ((dev->flags & (ATA_DFLAG_PIO | ATA_DFLAG_NCQ_OFF |
-  ATA_DFLAG_NCQ)) == ATA_DFLAG_NCQ &&
-   likely(tag != ATA_TAG_INTERNAL)) {
+   if (ata_ncq_enabled(dev) && likely(tag != ATA_TAG_INTERNAL)) {
/* yay, NCQ */
if (!lba_48_ok(block, n_block))
return -ERANGE;
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 73902d3..ebb9185 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -945,29 +945,32 @@ int ata_scsi_change_queue_depth(struct scsi_device *sdev, 
int queue_depth)
struct ata_port *ap = ata_shost_to_port(sdev->host);
struct ata_device *dev;
unsigned long flags;
-   int max_depth;

-   if (queue_depth < 1)
+   if (queue_depth < 1 || queue_depth == sdev->queue_depth)
return sdev->queue_depth;

dev = ata_scsi_find_dev(ap, sdev);
if (!dev || !ata_dev_enabled(dev))
return sdev->queue_depth;

-   max_depth = min(sdev->host->can_queue, ata_id_queue_depth(dev->id));
-   max_depth = min(ATA_MAX_QUEUE - 1, max_depth);
-   if (queue_depth > max_depth)
-   queue_depth = max_depth;
-
-   scsi_adjust_queue_depth(sdev, MSG_SIMPLE_TAG, queue_depth);
-
+   /* NCQ enabled? */
spin_lock_irqsave(ap->lock, flags);
-   if (queue_depth > 1)
-   dev->flags &= ~ATA_DFLAG_NCQ_OFF;
-   else
+   dev->flags &= ~ATA_DFLAG_NCQ_OFF;
+   if (queue_depth == 1 || !ata_ncq_enabled(dev)) {
dev->flags |= ATA_DFLAG_NCQ_OFF;
+   queue_depth = 1;
+   }
spin_unlock_irqrestore(ap->lock, flags);

+   /* limit and apply queue depth */
+   queue_depth = min(queue_depth, sdev->host->can_queue);
+   queue_depth = min(queue_depth, ata_id_queue_depth(dev->id));
+   queue_depth = min(queue_depth, ATA_MAX_QUEUE - 1);
+
+   if (sdev->queue_depth == queue_depth)
+   return -EINVAL;
+
+   scsi_adjust_queue_depth(sdev, MSG_SIMPLE_TAG, queue_depth);
return queue_depth;
 }

@@ -1454,11 +1457,9 @@ static void ata_scsi_qc_complete(struct ata_queued_cmd 
*qc)
 static int ata_scmd_need_defer(struct ata_device *dev, int is_io)
 {
struct ata_port *ap = dev->ap;
+   int is_ncq = is_io && ata_ncq_enabled(dev);

-   if (!(dev->flags & ATA_DFLAG_NCQ))
-   return 0;
-
-   if (is_io) {
+   if (is_ncq) {
if (!ata_tag_valid(ap->active_tag))
return 0;
} else {
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 91bb8ce..4e4e365 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -1035,6 +1035,21 @@ static inline u8 ata_chk_status(struct ata_port *ap)
return ap->ops->check_status(ap);
 }

+/**
+ * ata_ncq_enabled - Test whether NCQ is enabled
+ * @dev: ATA device to test for
+ *
+ * LOCKING:
+ * spin_lock_irqsave(host lock)
+ *
+ * RETURNS:
+ * 1 if NCQ is enabled for @dev, 0 otherwise.
+ */
+static inline int ata_ncq_enabled(struct ata_device *dev)
+{
+   return (dev->flags & (ATA_DFLAG_PIO | ATA_DFLAG_NCQ_OFF |
+ ATA_DFLAG_NCQ)) == ATA_DFLAG_NCQ;
+}

 /**
  * ata_pause - Flush writes and pause 400 nanoseconds.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][patch 2.6.20-git16] mm: replicated pagecache

2007-02-20 Thread Nick Piggin
Hi,

This patch is getting a bit more stable now, if anyone wants to play with
it.

Nick
--

Page-based NUMA pagecache replication.

This is a scheme for page replication replicates read-only pagecache pages
opportunistically, at pagecache lookup time (at points where we know the
page is being looked up for read only).

The page will be replicated if it resides on a different node to what the
requesting CPU is on. Also, the original page must meet some conditions:
it must be clean, uptodate, not under writeback, and not have an elevated
refcount or filesystem private data. However it is allowed to be mapped
into pagetables.

Replication is done at the pagecache level, where a replicated pagecache
(inode,offset) key will have a special bit set in its radix-tree entry,
which tells us the entry points to a descriptor rather than a page.

This descriptor (struct pcache_desc) has another radix-tree which is keyed by
node. The pagecache gains an (optional) 3rd dimension!

Pagecache lookups which are not explicitly denoted as being read-only are
treaded as writes, and they collapse the replication before proceeding.
Writes into pagetables are caught by using the same mechanism as dirty page
throttling uses, and also collapse the replication.

After collapsing a replication, all process page tables are unmapped, so that
any processes mapping discarded pages will refault in the correct one.

/proc/vmstat has nr_repl_pages, which is the number of _additional_ pages
replicated, beyond the first.

Status:
- Use PG_replicated page flag rather than tagging the radix tree. Radix-tree
  code is now completely unchanged from upstream. We're very close to optimum
  performance in all fastpaths (eg. no extra radix-tree walks needed).

- Can now replicate S_ISREG and S_ISBLK pages with PagePrivate set. These
  guys should never get dirtied via the fs.

- Will promote a slave to be the new master when reclaiming the master. This
  Just transfer relevant flags, and only promote if !PagePrivate (reclaim
  has already taken care of this for us).

- Many more debug checks to catch violated invariants.

- Some more bugs fixed.

- Round-robin the replication source, rather than always copying from master.
  This should even out load on the interconnect.

- Lee showed that ~10s (1%) user time was cut off a kernel compile benchmark
  on his 4 node 16-way box.

Todo:
- find_get_page locking semantics are slightly changed. This doesn't appear
  to be a problem but I need to have a more thorough look.
- Would like to be able to control replication via userspace, and maybe
  even internally to the kernel.
- Ideally, reclaim might reclaim replicated pages preferentially, however
  I aim to be _minimally_ intrusive, and this conflicts with that.
- More correctness testing.
- Eventually, have to look at playing nicely with migration.
- radix-tree nodes start using up a large amount of memory. Try to improve.
  (eg. smaller tree, or don't load master immediately).

 include/linux/mm.h |6 
 include/linux/mm_types.h   |8 
 include/linux/mmzone.h |3 
 include/linux/page-flags.h |   17 +
 init/main.c|1 
 mm/Kconfig |   11 
 mm/Makefile|1 
 mm/filemap.c   |  105 ++--
 mm/internal.h  |   52 +++
 mm/memory.c|5 
 mm/page-writeback.c|5 
 mm/page_alloc.c|9 
 mm/replication.c   |  588 +
 mm/vmscan.c|7 
 mm/vmstat.c|3 
 15 files changed, 742 insertions(+), 79 deletions(-)

Index: linux-2.6/include/linux/mm_types.h
===
--- linux-2.6.orig/include/linux/mm_types.h
+++ linux-2.6/include/linux/mm_types.h
@@ -5,6 +5,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 struct address_space;
 
@@ -64,4 +66,10 @@ struct page {
 #endif /* WANT_PAGE_VIRTUAL */
 };
 
+struct pcache_desc {
+   struct page *master;
+   nodemask_t nodes_present;
+   struct radix_tree_root page_tree;
+};
+
 #endif /* _LINUX_MM_TYPES_H */
Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -592,16 +592,13 @@ void fastcall __lock_page_nosync(struct 
  * Is there a pagecache struct page at the given (mapping, offset) tuple?
  * If yes, increment its refcount and return it; if no, return NULL.
  */
-struct page * find_get_page(struct address_space *mapping, unsigned long 
offset)
+struct page *find_get_page(struct address_space *mapping, unsigned long offset)
 {
struct page *page;
 
read_lock_irq(>tree_lock);
page = radix_tree_lookup(>page_tree, offset);
-   if (page)
-   page_cache_get(page);
-   read_unlock_irq(>tree_lock);
-   return page;
+   return get_unreplicated_page(mapping, offset, page);
 }
 

Re: [-mm patch] UNION_FS must depend on SLAB

2007-02-20 Thread Josef Sipek
For the time being, I included it in unionfs.git. I wouldn't mind having
this dependency disappear.

Thanks,

Josef "Jeff" Sipek.

-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] fault injection: split up stacktrace filter Kconfig option

2007-02-20 Thread Dave Jones
On Wed, Feb 21, 2007 at 01:59:09AM +, Linux Kernel wrote:
 > Commit: 1df49008f4ddec9d4f6862b47ea5bdba82078aa4
 > Parent: 94412a96c4553255bda7a232a349059dd7543338
 > Author: Akinobu Mita <[EMAIL PROTECTED]>
 > AuthorDate: Tue Feb 20 13:57:56 2007 -0800
 > Committer:  Linus Torvalds <[EMAIL PROTECTED]>
 > CommitDate: Tue Feb 20 17:10:14 2007 -0800
 > 
 > [PATCH] fault injection: split up stacktrace filter Kconfig option
 > 
 > There is no prompt for CONFIG_STACKTRACE, so FAULT_INJECTION cannot be
 > selected without LOCKDEP enabled.  (found by Paolo 'Blaisorblade'
 > Giarrusso)
 > 
 > In order to fix such broken Kconfig dependency, this patch splits up the
 > stacktrace filter support for fault injection by new Kconfig option, 
 > which
 > enables to use fault injection on the architecture which doesn't have
 > general stacktrace support.

 ...

 > +config FAULT_INJECTION_STACKTRACE_FILTER
 > +bool "stacktrace filter for fault-injection capabilities"
 > +depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
 > +select STACKTRACE
 > +select FRAME_POINTER
 > +help
 > +  Provide stacktrace filter for fault-injection capabilities

This help text is pretty useless. It tells the person configuring
nothing about what a stacktrace filter is, or why it might be useful.
helptexts that just parrot the name of the option might as well not be there.

Dave

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


[PATCH] devpts: add fsnotify create event

2007-02-20 Thread Florin Malita
Currently, devpts doesn't generate an fsnotify event upon pts creation 
because the regular vfs paths aren't involved. Deallocation, on the 
other hand, correctly generates a nameremove event thanks to the 
d_delete() invocation in devpts_pty_kill().


This patch adds the missing fsnotify_create() trigger in devpts_pty_new().

Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---

fs/devpts/inode.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
index 643e57b..06ef9a2 100644
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -19,6 +19,7 @@ #include 
#include 
#include 
#include 
+#include 

#define DEVPTS_SUPER_MAGIC 0x1cd1

@@ -178,8 +179,10 @@ int devpts_pty_new(struct tty_struct *tt
inode->i_private = tty;

dentry = get_node(number);
-   if (!IS_ERR(dentry) && !dentry->d_inode)
+   if (!IS_ERR(dentry) && !dentry->d_inode) {
d_instantiate(dentry, inode);
+   fsnotify_create(devpts_root->d_inode, dentry);
+   }

mutex_unlock(_root->d_inode->i_mutex);



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


Re: [patch 5/6] mm: merge nopfn into fault

2007-02-20 Thread Nick Piggin
On Wed, Feb 21, 2007 at 05:50:31AM +0100, Nick Piggin wrote:
> Remove ->nopfn and reimplement the existing handlers with ->fault
> 
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

Dang, forgot to quilt refresh after fixing spufs compile.
--

Remove ->nopfn and reimplement the existing handlers with ->fault

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

 arch/powerpc/platforms/cell/spufs/file.c |   90 ---
 drivers/char/mspec.c |   29 ++---
 include/linux/mm.h   |8 --
 mm/memory.c  |   58 +--
 4 files changed, 71 insertions(+), 114 deletions(-)

Index: linux-2.6/drivers/char/mspec.c
===
--- linux-2.6.orig/drivers/char/mspec.c
+++ linux-2.6/drivers/char/mspec.c
@@ -182,24 +182,25 @@ mspec_close(struct vm_area_struct *vma)
 
 
 /*
- * mspec_nopfn
+ * mspec_fault
  *
  * Creates a mspec page and maps it to user space.
  */
-static unsigned long
-mspec_nopfn(struct vm_area_struct *vma, unsigned long address)
+static struct page *
+mspec_fault(struct fault_data *fdata)
 {
unsigned long paddr, maddr;
unsigned long pfn;
-   int index;
-   struct vma_data *vdata = vma->vm_private_data;
+   int index = fdata->pgoff;
+   struct vma_data *vdata = fdata->vma->vm_private_data;
 
-   index = (address - vma->vm_start) >> PAGE_SHIFT;
maddr = (volatile unsigned long) vdata->maddr[index];
if (maddr == 0) {
maddr = uncached_alloc_page(numa_node_id());
-   if (maddr == 0)
-   return NOPFN_OOM;
+   if (maddr == 0) {
+   fdata->type = VM_FAULT_OOM;
+   return NULL;
+   }
 
spin_lock(>lock);
if (vdata->maddr[index] == 0) {
@@ -219,13 +220,21 @@ mspec_nopfn(struct vm_area_struct *vma, 
 
pfn = paddr >> PAGE_SHIFT;
 
-   return pfn;
+   fdata->type = VM_FAULT_MINOR;
+   /*
+* vm_insert_pfn can fail with -EBUSY, but in that case it will
+* be because another thread has installed the pte first, so it
+* is no problem.
+*/
+   vm_insert_pfn(fdata->vma, fdata->address, pfn);
+
+   return NULL;
 }
 
 static struct vm_operations_struct mspec_vm_ops = {
.open = mspec_open,
.close = mspec_close,
-   .nopfn = mspec_nopfn
+   .fault = mspec_fault,
 };
 
 /*
Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -230,7 +230,6 @@ struct vm_operations_struct {
void (*close)(struct vm_area_struct * area);
struct page * (*fault)(struct vm_area_struct *vma, struct fault_data * 
fdata);
struct page * (*nopage)(struct vm_area_struct * area, unsigned long 
address, int *type);
-   unsigned long (*nopfn)(struct vm_area_struct * area, unsigned long 
address);
int (*populate)(struct vm_area_struct * area, unsigned long address, 
unsigned long len, pgprot_t prot, unsigned long pgoff, int nonblock);
 
/* notification that a previously read-only page is about to become
@@ -660,13 +659,6 @@ static inline int page_mapped(struct pag
 #define NOPAGE_OOM ((struct page *) (-1))
 
 /*
- * Error return values for the *_nopfn functions
- */
-#define NOPFN_SIGBUS   ((unsigned long) -1)
-#define NOPFN_OOM  ((unsigned long) -2)
-#define NOPFN_REFAULT  ((unsigned long) -3)
-
-/*
  * Different kinds of faults, as returned by handle_mm_fault().
  * Used to decide whether a process gets delivered SIGBUS or
  * just gets major/minor fault counters bumped up.
Index: linux-2.6/mm/memory.c
===
--- linux-2.6.orig/mm/memory.c
+++ linux-2.6/mm/memory.c
@@ -1288,6 +1288,11 @@ EXPORT_SYMBOL(vm_insert_page);
  *
  * This function should only be called from a vm_ops->fault handler, and
  * in that case the handler should return NULL.
+ *
+ * vma cannot be a COW mapping.
+ *
+ * As this is called only for pages that do not currently exist, we
+ * do not need to flush old virtual caches or the TLB.
  */
 int vm_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn)
@@ -2343,56 +2348,6 @@ static int do_nonlinear_fault(struct mm_
 }
 
 /*
- * do_no_pfn() tries to create a new page mapping for a page without
- * a struct_page backing it
- *
- * As this is called only for pages that do not currently exist, we
- * do not need to flush old virtual caches or the TLB.
- *
- * We enter with non-exclusive mmap_sem (to exclude vma changes,
- * but allow concurrent faults), and pte mapped but not yet locked.
- * We return with mmap_sem still held, but pte unmapped and unlocked.
- *
- * It is expected that the ->nopfn handler always returns the same pfn
- * for a 

[patch 6/6] mm: remove legacy cruft

2007-02-20 Thread Nick Piggin
Remove legacy filemap_nopage and all of the .populate API cruft.

This patch can be skipped if it will cause clashes in your tree, or you
disagree with removing these guys right now.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

 Documentation/feature-removal-schedule.txt |   18 --
 include/linux/mm.h |8 -
 mm/filemap.c   |  195 -
 mm/fremap.c|   71 +-
 mm/memory.c|   36 +
 5 files changed, 19 insertions(+), 309 deletions(-)

Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -230,8 +230,6 @@ struct vm_operations_struct {
void (*close)(struct vm_area_struct * area);
struct page * (*fault)(struct vm_area_struct *vma, struct fault_data * 
fdata);
struct page * (*nopage)(struct vm_area_struct * area, unsigned long 
address, int *type);
-   int (*populate)(struct vm_area_struct * area, unsigned long address, 
unsigned long len, pgprot_t prot, unsigned long pgoff, int nonblock);
-
/* notification that a previously read-only page is about to become
 * writable, if an error is returned it will cause a SIGBUS */
int (*page_mkwrite)(struct vm_area_struct *vma, struct page *page);
@@ -767,8 +765,6 @@ static inline void unmap_shared_mapping_
 
 extern int vmtruncate(struct inode * inode, loff_t offset);
 extern int vmtruncate_range(struct inode * inode, loff_t offset, loff_t end);
-extern int install_page(struct mm_struct *mm, struct vm_area_struct *vma, 
unsigned long addr, struct page *page, pgprot_t prot);
-extern int install_file_pte(struct mm_struct *mm, struct vm_area_struct *vma, 
unsigned long addr, unsigned long pgoff, pgprot_t prot);
 
 #ifdef CONFIG_MMU
 extern int __handle_mm_fault(struct mm_struct *mm,struct vm_area_struct *vma,
@@ -1084,10 +1080,6 @@ extern void truncate_inode_pages_range(s
 
 /* generic vm_area_ops exported for stackable file systems */
 extern struct page *filemap_fault(struct vm_area_struct *, struct fault_data 
*);
-extern struct page * __deprecated_for_modules filemap_nopage(
-   struct vm_area_struct *, unsigned long, int *);
-extern int __deprecated_for_modules filemap_populate(struct vm_area_struct *,
-   unsigned long, unsigned long, pgprot_t, unsigned long, int);
 
 /* mm/page-writeback.c */
 int write_one_page(struct page *page, int wait);
Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -1476,201 +1476,6 @@ page_not_uptodate:
 }
 EXPORT_SYMBOL(filemap_fault);
 
-/*
- * filemap_nopage and filemap_populate are legacy exports that are not used
- * in tree. Scheduled for removal.
- */
-struct page *filemap_nopage(struct vm_area_struct *area,
-   unsigned long address, int *type)
-{
-   struct page *page;
-   struct fault_data fdata;
-   fdata.address = address;
-   fdata.pgoff = ((address - area->vm_start) >> PAGE_CACHE_SHIFT)
-   + area->vm_pgoff;
-   fdata.flags = 0;
-
-   page = filemap_fault(area, );
-   if (type)
-   *type = fdata.type;
-
-   return page;
-}
-EXPORT_SYMBOL(filemap_nopage);
-
-static struct page * filemap_getpage(struct file *file, unsigned long pgoff,
-   int nonblock)
-{
-   struct address_space *mapping = file->f_mapping;
-   struct page *page;
-   int error;
-
-   /*
-* Do we have something in the page cache already?
-*/
-retry_find:
-   page = find_get_page(mapping, pgoff);
-   if (!page) {
-   if (nonblock)
-   return NULL;
-   goto no_cached_page;
-   }
-
-   /*
-* Ok, found a page in the page cache, now we need to check
-* that it's up-to-date.
-*/
-   if (!PageUptodate(page)) {
-   if (nonblock) {
-   page_cache_release(page);
-   return NULL;
-   }
-   goto page_not_uptodate;
-   }
-
-success:
-   /*
-* Found the page and have a reference on it.
-*/
-   mark_page_accessed(page);
-   return page;
-
-no_cached_page:
-   error = page_cache_read(file, pgoff);
-
-   /*
-* The page we want has now been added to the page cache.
-* In the unlikely event that someone removed it in the
-* meantime, we'll just come back here and read it again.
-*/
-   if (error >= 0)
-   goto retry_find;
-
-   /*
-* An error return from page_cache_read can result if the
-* system is low on memory, or a problem occurs while trying
-* to schedule I/O.
-*/
-  

Linux 2.6.21-rc1

2007-02-20 Thread Linus Torvalds

Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.

There's a lot of changes, as is usual for an -rc1 thing, but at least so 
far it would seem that 2.6.20 has been a good base, and I don't think we 
have anything *really* scary here.

The most interesting core change may be the dyntick/nohz one, where timer 
ticks will only happen when needed. It's been brewing for a _loong_ time, 
but it's in the standard kernel now as an option. 

But there's a ton of architecture updates (arm, mips, powerpc, x86, you 
name it), ACPI updates, and lots of driver work. And just a lot of 
cleanups.

Have fun,

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 4/6] mm: merge populate and nopage into fault (fixes nonlinear)

2007-02-20 Thread Nick Piggin
Nonlinear mappings are (AFAIKS) simply a virtual memory concept that
encodes the virtual address -> file offset differently from linear
mappings.

I can't see why the filesystem/pagecache code should need to know anything
about it, except for the fact that the ->nopage handler didn't quite pass
down enough information (ie. pgoff). But it is more logical to pass pgoff
rather than have the ->nopage function calculate it itself anyway. And
having the nopage handler install the pte itself is sort of nasty.

This patch introduces a new fault handler that replaces ->nopage and
->populate and (later) ->nopfn. Most of the old mechanism is still in place
so there is a lot of duplication and nice cleanups that can be removed if
everyone switches over.

The rationale for doing this in the first place is that nonlinear mappings
are subject to the pagefault vs invalidate/truncate race too, and it seemed
stupid to duplicate the synchronisation logic rather than just consolidate
the two.

After this patch, MAP_NONBLOCK no longer sets up ptes for pages present in
pagecache. Seems like a fringe functionality anyway.

NOPAGE_REFAULT is removed. This should be implemented with ->fault, and
no users have hit mainline yet.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

 Documentation/feature-removal-schedule.txt |   27 ++
 Documentation/filesystems/Locking  |2 
 fs/gfs2/ops_address.c  |2 
 fs/gfs2/ops_file.c |2 
 fs/gfs2/ops_vm.c   |   34 ---
 fs/ncpfs/mmap.c|   23 ++---
 fs/ocfs2/aops.c|2 
 fs/ocfs2/mmap.c|   17 +--
 fs/xfs/linux-2.6/xfs_file.c|   23 ++---
 include/linux/mm.h |   36 ++--
 ipc/shm.c  |2 
 mm/filemap.c   |   93 
 mm/filemap_xip.c   |   44 +
 mm/fremap.c|  105 ---
 mm/memory.c|  129 ++---
 mm/mmap.c  |8 -
 mm/nommu.c |3 
 mm/shmem.c |   80 -
 mm/truncate.c  |2 
 19 files changed, 371 insertions(+), 263 deletions(-)

Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -175,6 +175,7 @@ extern unsigned int kobjsize(const void 
 * In this case, do_no_page must
 * return with the page locked.
 */
+#define VM_CAN_NONLINEAR 0x1000/* Has ->fault & does nonlinear pages */
 
 #ifndef VM_STACK_DEFAULT_FLAGS /* arch can override this */
 #define VM_STACK_DEFAULT_FLAGS VM_DATA_DEFAULT_FLAGS
@@ -198,6 +199,26 @@ extern unsigned int kobjsize(const void 
  */
 extern pgprot_t protection_map[16];
 
+#define FAULT_FLAG_WRITE   0x01
+#define FAULT_FLAG_NONLINEAR   0x02
+
+/*
+ * fault_data is filled in the the pagefault handler and passed to the
+ * vma's ->fault function. That function is responsible for filling in
+ * 'type', which is the type of fault if a page is returned, or the type
+ * of error if NULL is returned.
+ *
+ * pgoff should be used in favour of address, if possible. If pgoff is
+ * used, one may set VM_CAN_NONLINEAR in the vma->vm_flags to get
+ * nonlinear mapping support.
+ */
+struct fault_data {
+   unsigned long address;
+   pgoff_t pgoff;
+   unsigned int flags;
+
+   int type;
+};
 
 /*
  * These are the virtual MM functions - opening of an area, closing and
@@ -207,6 +228,7 @@ extern pgprot_t protection_map[16];
 struct vm_operations_struct {
void (*open)(struct vm_area_struct * area);
void (*close)(struct vm_area_struct * area);
+   struct page * (*fault)(struct vm_area_struct *vma, struct fault_data * 
fdata);
struct page * (*nopage)(struct vm_area_struct * area, unsigned long 
address, int *type);
unsigned long (*nopfn)(struct vm_area_struct * area, unsigned long 
address);
int (*populate)(struct vm_area_struct * area, unsigned long address, 
unsigned long len, pgprot_t prot, unsigned long pgoff, int nonblock);
@@ -636,7 +658,6 @@ static inline int page_mapped(struct pag
  */
 #define NOPAGE_SIGBUS  (NULL)
 #define NOPAGE_OOM ((struct page *) (-1))
-#define NOPAGE_REFAULT ((struct page *) (-2))  /* Return to userspace, rerun */
 
 /*
  * Error return values for the *_nopfn functions
@@ -666,14 +687,13 @@ static inline int page_mapped(struct pag
 extern void show_free_areas(void);
 
 #ifdef CONFIG_SHMEM
-struct page *shmem_nopage(struct vm_area_struct *vma,
-   

[patch 3/6] mm: fix fault vs invalidate race for linear mappings

2007-02-20 Thread Nick Piggin
Fix the race between invalidate_inode_pages and do_no_page.

Andrea Arcangeli identified a subtle race between invalidation of
pages from pagecache with userspace mappings, and do_no_page.

The issue is that invalidation has to shoot down all mappings to the
page, before it can be discarded from the pagecache. Between shooting
down ptes to a particular page, and actually dropping the struct page
from the pagecache, do_no_page from any process might fault on that
page and establish a new mapping to the page just before it gets
discarded from the pagecache.

The most common case where such invalidation is used is in file
truncation. This case was catered for by doing a sort of open-coded
seqlock between the file's i_size, and its truncate_count.

Truncation will decrease i_size, then increment truncate_count before
unmapping userspace pages; do_no_page will read truncate_count, then
find the page if it is within i_size, and then check truncate_count
under the page table lock and back out and retry if it had
subsequently been changed (ptl will serialise against unmapping, and
ensure a potentially updated truncate_count is actually visible).

Complexity and documentation issues aside, the locking protocol fails
in the case where we would like to invalidate pagecache inside i_size.
do_no_page can come in anytime and filemap_nopage is not aware of the
invalidation in progress (as it is when it is outside i_size). The
end result is that dangling (->mapping == NULL) pages that appear to
be from a particular file may be mapped into userspace with nonsense
data. Valid mappings to the same place will see a different page.

Andrea implemented two working fixes, one using a real seqlock,
another using a page->flags bit. He also proposed using the page lock
in do_no_page, but that was initially considered too heavyweight.
However, it is not a global or per-file lock, and the page cacheline
is modified in do_no_page to increment _count and _mapcount anyway, so
a further modification should not be a large performance hit.
Scalability is not an issue.

This patch implements this latter approach. ->nopage implementations
return with the page locked if it is possible for their underlying
file to be invalidated (in that case, they must set a special vm_flags
bit to indicate so). do_no_page only unlocks the page after setting
up the mapping completely. invalidation is excluded because it holds
the page lock during invalidation of each page (and ensures that the
page is not mapped while holding the lock).

This also allows significant simplifications in do_no_page, because
we have the page locked in the right place in the pagecache from the
start.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

 fs/gfs2/ops_file.c  |2 
 fs/ncpfs/mmap.c |1 
 fs/ocfs2/mmap.c |1 
 fs/xfs/linux-2.6/xfs_file.c |1 
 include/linux/mm.h  |6 +
 ipc/shm.c   |1 
 mm/filemap.c|   53 ++--
 mm/memory.c |  138 +++-
 mm/shmem.c  |   11 ++-
 mm/truncate.c   |   10 +++
 10 files changed, 111 insertions(+), 113 deletions(-)

Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -170,6 +170,12 @@ extern unsigned int kobjsize(const void 
 #define VM_INSERTPAGE  0x0200  /* The vma has had "vm_insert_page()" 
done on it */
 #define VM_ALWAYSDUMP  0x0400  /* Always include in core dumps */
 
+#define VM_CAN_INVALIDATE 0x0800   /* The mapping may be invalidated,
+* eg. truncate or invalidate_inode_*.
+* In this case, do_no_page must
+* return with the page locked.
+*/
+
 #ifndef VM_STACK_DEFAULT_FLAGS /* arch can override this */
 #define VM_STACK_DEFAULT_FLAGS VM_DATA_DEFAULT_FLAGS
 #endif
Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -1329,9 +1329,10 @@ struct page *filemap_nopage(struct vm_ar
unsigned long size, pgoff;
int did_readaround = 0, majmin = VM_FAULT_MINOR;
 
+   BUG_ON(!(area->vm_flags & VM_CAN_INVALIDATE));
+
pgoff = ((address-area->vm_start) >> PAGE_CACHE_SHIFT) + area->vm_pgoff;
 
-retry_all:
size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
if (pgoff >= size)
goto outside_data_content;
@@ -1353,7 +1354,7 @@ retry_all:
 * Do we have something in the page cache already?
 */
 retry_find:
-   page = find_get_page(mapping, pgoff);
+   page = find_lock_page(mapping, pgoff);
if (!page) {
unsigned long ra_pages;
 
@@ -1387,7 

[patch 5/6] mm: merge nopfn into fault

2007-02-20 Thread Nick Piggin
Remove ->nopfn and reimplement the existing handlers with ->fault

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

 arch/powerpc/platforms/cell/spufs/file.c |   90 ---
 drivers/char/mspec.c |   29 ++---
 include/linux/mm.h   |8 --
 mm/memory.c  |   58 +--
 4 files changed, 71 insertions(+), 114 deletions(-)

Index: linux-2.6/drivers/char/mspec.c
===
--- linux-2.6.orig/drivers/char/mspec.c
+++ linux-2.6/drivers/char/mspec.c
@@ -182,24 +182,25 @@ mspec_close(struct vm_area_struct *vma)
 
 
 /*
- * mspec_nopfn
+ * mspec_fault
  *
  * Creates a mspec page and maps it to user space.
  */
-static unsigned long
-mspec_nopfn(struct vm_area_struct *vma, unsigned long address)
+static struct page *
+mspec_fault(struct fault_data *fdata)
 {
unsigned long paddr, maddr;
unsigned long pfn;
-   int index;
-   struct vma_data *vdata = vma->vm_private_data;
+   int index = fdata->pgoff;
+   struct vma_data *vdata = fdata->vma->vm_private_data;
 
-   index = (address - vma->vm_start) >> PAGE_SHIFT;
maddr = (volatile unsigned long) vdata->maddr[index];
if (maddr == 0) {
maddr = uncached_alloc_page(numa_node_id());
-   if (maddr == 0)
-   return NOPFN_OOM;
+   if (maddr == 0) {
+   fdata->type = VM_FAULT_OOM;
+   return NULL;
+   }
 
spin_lock(>lock);
if (vdata->maddr[index] == 0) {
@@ -219,13 +220,21 @@ mspec_nopfn(struct vm_area_struct *vma, 
 
pfn = paddr >> PAGE_SHIFT;
 
-   return pfn;
+   fdata->type = VM_FAULT_MINOR;
+   /*
+* vm_insert_pfn can fail with -EBUSY, but in that case it will
+* be because another thread has installed the pte first, so it
+* is no problem.
+*/
+   vm_insert_pfn(fdata->vma, fdata->address, pfn);
+
+   return NULL;
 }
 
 static struct vm_operations_struct mspec_vm_ops = {
.open = mspec_open,
.close = mspec_close,
-   .nopfn = mspec_nopfn
+   .fault = mspec_fault,
 };
 
 /*
Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -230,7 +230,6 @@ struct vm_operations_struct {
void (*close)(struct vm_area_struct * area);
struct page * (*fault)(struct vm_area_struct *vma, struct fault_data * 
fdata);
struct page * (*nopage)(struct vm_area_struct * area, unsigned long 
address, int *type);
-   unsigned long (*nopfn)(struct vm_area_struct * area, unsigned long 
address);
int (*populate)(struct vm_area_struct * area, unsigned long address, 
unsigned long len, pgprot_t prot, unsigned long pgoff, int nonblock);
 
/* notification that a previously read-only page is about to become
@@ -660,13 +659,6 @@ static inline int page_mapped(struct pag
 #define NOPAGE_OOM ((struct page *) (-1))
 
 /*
- * Error return values for the *_nopfn functions
- */
-#define NOPFN_SIGBUS   ((unsigned long) -1)
-#define NOPFN_OOM  ((unsigned long) -2)
-#define NOPFN_REFAULT  ((unsigned long) -3)
-
-/*
  * Different kinds of faults, as returned by handle_mm_fault().
  * Used to decide whether a process gets delivered SIGBUS or
  * just gets major/minor fault counters bumped up.
Index: linux-2.6/mm/memory.c
===
--- linux-2.6.orig/mm/memory.c
+++ linux-2.6/mm/memory.c
@@ -1288,6 +1288,11 @@ EXPORT_SYMBOL(vm_insert_page);
  *
  * This function should only be called from a vm_ops->fault handler, and
  * in that case the handler should return NULL.
+ *
+ * vma cannot be a COW mapping.
+ *
+ * As this is called only for pages that do not currently exist, we
+ * do not need to flush old virtual caches or the TLB.
  */
 int vm_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn)
@@ -2343,56 +2348,6 @@ static int do_nonlinear_fault(struct mm_
 }
 
 /*
- * do_no_pfn() tries to create a new page mapping for a page without
- * a struct_page backing it
- *
- * As this is called only for pages that do not currently exist, we
- * do not need to flush old virtual caches or the TLB.
- *
- * We enter with non-exclusive mmap_sem (to exclude vma changes,
- * but allow concurrent faults), and pte mapped but not yet locked.
- * We return with mmap_sem still held, but pte unmapped and unlocked.
- *
- * It is expected that the ->nopfn handler always returns the same pfn
- * for a given virtual mapping.
- *
- * Mark this `noinline' to prevent it from bloating the main pagefault code.
- */
-static noinline int do_no_pfn(struct mm_struct *mm, struct vm_area_struct *vma,
-unsigned long address, pte_t 

[patch 2/6] mm: simplify filemap_nopage

2007-02-20 Thread Nick Piggin
Identical block is duplicated twice: contrary to the comment, we have been
re-reading the page *twice* in filemap_nopage rather than once.

If any retry logic or anything is needed, it belongs in lower levels anyway.
Only retry once. Linus agrees.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

 mm/filemap.c |   24 
 1 file changed, 24 deletions(-)

Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -1448,30 +1448,6 @@ page_not_uptodate:
majmin = VM_FAULT_MAJOR;
count_vm_event(PGMAJFAULT);
}
-   lock_page(page);
-
-   /* Did it get unhashed while we waited for it? */
-   if (!page->mapping) {
-   unlock_page(page);
-   page_cache_release(page);
-   goto retry_all;
-   }
-
-   /* Did somebody else get it up-to-date? */
-   if (PageUptodate(page)) {
-   unlock_page(page);
-   goto success;
-   }
-
-   error = mapping->a_ops->readpage(file, page);
-   if (!error) {
-   wait_on_page_locked(page);
-   if (PageUptodate(page))
-   goto success;
-   } else if (error == AOP_TRUNCATED_PAGE) {
-   page_cache_release(page);
-   goto retry_find;
-   }
 
/*
 * Umm, take care of errors if the page isn't up-to-date.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[patch 1/6] mm: debug check for the fault vs invalidate race

2007-02-20 Thread Nick Piggin
Add a bugcheck for Andrea's pagefault vs invalidate race. This is triggerable
for both linear and nonlinear pages with a userspace test harness (using
direct IO and truncate, respectively).

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

 mm/filemap.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -120,6 +120,8 @@ void __remove_from_page_cache(struct pag
page->mapping = NULL;
mapping->nrpages--;
__dec_zone_page_state(page, NR_FILE_PAGES);
+
+   BUG_ON(page_mapped(page));
 }
 
 void remove_from_page_cache(struct page *page)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[patch 0/6] fault vs truncate/invalidate race fix

2007-02-20 Thread Nick Piggin
The following set of patches are based on current git.

These fix the fault vs invalidate and fault vs truncate_range race for
filemap_nopage mappings, plus those and fault vs truncate race for nonlinear
mappings.

These patches fix silent data corruption that we've had several people hitting
in SUSE kernels. Our kernels have similar patches to lock the page over page
fault, and no problem.

I've also got rid of the horrible populate API, and integrated nonlinear pages
properly with the page fault path.

Downside is that this adds one more vector through which the buffered write
deadlock can occur. However this is just a very tiny one (pte being unmapped
for reclaim), compared to all the other ways that deadlock can occur (unmap,
reclaim, truncate, invalidate). I doubt it will be noticable. At any rate, it
is better than data corruption.

I hope these can get merged (at least into -mm) soon.

Thanks,
Nick

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


Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

2007-02-20 Thread Juan Piernas Canovas

Hi Jörn,

On Tue, 20 Feb 2007, [utf-8] Jörn Engel wrote:


On Tue, 20 February 2007 00:57:50 +0100, Juan Piernas Canovas wrote:


Actually, the GC may become a problem when the number of free segments is
50% or less. If your LFS always guarantees, at least, 50% of free
"segments" (note that I am talking about segments, not free space), the
deadlock problem disappears, right? This is a quite naive solution, but it
works.


I don't see how you can guarantee 50% free segments.  Can you explain
that bit?
It is quite simple. If 50% of your segments are busy, and the other 50% 
are free, and the file system needs a new segment, the cleaner starts 
freeing some of busy ones. If the cleaner is unable to free one segment at 
least, your file system gets "full" (and it returns a nice ENOSPC error). 
This solution wastes the half of your storage device, but it is 
deadlock-free. Obviously, there are better approaches.





In a traditional LFS, with data and meta-data blocks, 50% of free segments
represents a huge amount of wasted disk space. But, in DualFS, 50% of free
segments in the meta-data device is not too much. In a typical Ext2,
or Ext3 file system, there are 20 data blocks for every meta-data block
(that is, meta-data blocks are 5% of the disk blocks used by files).
Since files are implemented in DualFS in the same way, we can suppose the
same ratio for DualFS (1).


This will work fairly well for most people.  It is possible to construct
metadata-heavy workloads, however.  Many large directories containing
symlinks or special files (char/block devices, sockets, fifos,
whiteouts) come to mind.  Most likely noone of your user will ever want
that, but a malicious attacker might.

Quotas, bigger meta-data device, cleverer cleaner,... there are 
solutions :)



The point of all the above is that you must improve the common case, and
manage the worst case correctly. And that is the idea behind DualFS :)


A fine principle to work with.  Surprisingly, what is the worst case for
you is the common case for LogFS, so maybe I'm more interested in it
than most people.  Or maybe I'm just more paranoid.



No, you are right. It is the common case for LogFS because it has data and 
meta-data blocks in the same address space, but that is not the case of 
DualFS. Anyway, I'm very interested in your work because any solution to 
the problem of the GC will be also applicable to DualFS. So, keep up with 
it. ;-)


Juan.
--
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es=index

*** Por favor, envíeme sus documentos en formato texto, HTML, PDF o PostScript 
:-) ***

[patch] mm: remove gcc workaround

2007-02-20 Thread Nick Piggin

Minimum gcc version is 3.2 now. However, with likely profiling, even
modern gcc versions cannot always eliminate the call.

Replace the placeholder functions with the more conventional empty static
inlines, which should be optimal for everyone.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

Index: linux-2.6/mm/memory.c
===
--- linux-2.6.orig/mm/memory.c
+++ linux-2.6/mm/memory.c
@@ -2539,12 +2539,6 @@ int __pud_alloc(struct mm_struct *mm, pg
spin_unlock(>page_table_lock);
return 0;
 }
-#else
-/* Workaround for gcc 2.96 */
-int __pud_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long address)
-{
-   return 0;
-}
 #endif /* __PAGETABLE_PUD_FOLDED */
 
 #ifndef __PAGETABLE_PMD_FOLDED
@@ -2573,12 +2567,6 @@ int __pmd_alloc(struct mm_struct *mm, pu
spin_unlock(>page_table_lock);
return 0;
 }
-#else
-/* Workaround for gcc 2.96 */
-int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address)
-{
-   return 0;
-}
 #endif /* __PAGETABLE_PMD_FOLDED */
 
 int make_pages_present(unsigned long addr, unsigned long end)
Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -855,8 +855,26 @@ static inline int vma_wants_writenotify(
 
 extern pte_t *FASTCALL(get_locked_pte(struct mm_struct *mm, unsigned long 
addr, spinlock_t **ptl));
 
+#ifdef __PAGETABLE_PUD_FOLDED
+static inline int __pud_alloc(struct mm_struct *mm, pgd_t *pgd,
+   unsigned long address)
+{
+   return 0;
+}
+#else
 int __pud_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long address);
+#endif
+
+#ifdef __PAGETABLE_PMD_FOLDED
+static inline int __pmd_alloc(struct mm_struct *mm, pud_t *pud,
+   unsigned long address)
+{
+   return 0;
+}
+#else
 int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address);
+#endif
+
 int __pte_alloc(struct mm_struct *mm, pmd_t *pmd, unsigned long address);
 int __pte_alloc_kernel(pmd_t *pmd, unsigned long address);
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: securityfs_create_dir strange comment

2007-02-20 Thread Greg KH
On Wed, Feb 21, 2007 at 12:45:40AM +0100, Jan Engelhardt wrote:
> 
> On Feb 20 2007 14:26, Greg KH wrote:
> >On Tue, Feb 20, 2007 at 03:18:49PM -0600, Serge E. Hallyn wrote:
> >> Quoting Jan Engelhardt ([EMAIL PROTECTED]):
> >> > Hello list,
> >> > 
> >> > 
> >> > in security/inode.c, the comment for securityfs_create_dir() reads:
> >> > 
> >> >  If securityfs is not enabled in the kernel, the value -ENODEV 
> >> >  will be returned.  It is not wise to check for this value, but 
> >> >  rather, check for NULL or !NULL instead as to eliminate the need 
> >> >  for #ifdef in the calling code.
> >> > 
> >> > What is the actual callee that can return NULL - and what should 
> >> > module_init() of a module return when securityfs_create_dir() returns 
> >> > NULL?
> >> 
> >> Hmm, this came from GregKH.  It does seem based on the code that
> >> checking for -ENODEV is necessary, so I don't understand the comment.
> >
> >If securityfs_create_dir() returns NULL, then something bad happened and
> >your code needs to properly recover from it.
> >
> >Other than that, I don't understand the issue here.
> 
> Consider:
> 
> static __init int mymodule_init(void)
> {
> struct dentry *de;
> de = securityfs_create_dir("foobar", NULL);
> 
> /* case 1 */
> if(IS_ERR(de))
> return PTR_ERR(de);
> 
> /* case 2 */
> if(de == NULL)
> return WHAT_HERE; /* -EIO? */
> }
> 
> There are two error cases. One: when the function gives us an error code.
> Two: When it returns NULL, without an error code. This looks bogus to me.
> What error is it, when there is no error? - And what should I return to
> modprobe in that case?

Try this instead:
if (!de)
return -ENOMEM;
if ((IS_ERR(de)) && (PTR_ERR(de) != -ENODEV))
return PTR_ERR(de);
return 0;

That should cover everything properly, right?

thanks,

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


Re: SATA problems

2007-02-20 Thread Tejun Heo
Marcus Haebler wrote:
> thanks for the patches! I am on an Intel P965/ICH8R.

I see.  That can happen too.  There was a race window where in-flight
r/w command which left SCSI midlayer but pending on libata gets executed
in the wrong mode.  If possible, please verify that it doesn't happen
with the patches applied.  I'm attaching combined patch against v2.6.20.

Thanks.

-- 
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 667acd2..348cc02 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -308,9 +308,7 @@ int ata_build_rw_tf(struct ata_taskfile *tf, struct 
ata_device *dev,
tf->flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
tf->flags |= tf_flags;
 
-   if ((dev->flags & (ATA_DFLAG_PIO | ATA_DFLAG_NCQ_OFF |
-  ATA_DFLAG_NCQ)) == ATA_DFLAG_NCQ &&
-   likely(tag != ATA_TAG_INTERNAL)) {
+   if (ata_ncq_enabled(dev) && likely(tag != ATA_TAG_INTERNAL)) {
/* yay, NCQ */
if (!lba_48_ok(block, n_block))
return -ERANGE;
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 73902d3..ebb9185 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -945,29 +945,32 @@ int ata_scsi_change_queue_depth(struct scsi_device *sdev, 
int queue_depth)
struct ata_port *ap = ata_shost_to_port(sdev->host);
struct ata_device *dev;
unsigned long flags;
-   int max_depth;
 
-   if (queue_depth < 1)
+   if (queue_depth < 1 || queue_depth == sdev->queue_depth)
return sdev->queue_depth;
 
dev = ata_scsi_find_dev(ap, sdev);
if (!dev || !ata_dev_enabled(dev))
return sdev->queue_depth;
 
-   max_depth = min(sdev->host->can_queue, ata_id_queue_depth(dev->id));
-   max_depth = min(ATA_MAX_QUEUE - 1, max_depth);
-   if (queue_depth > max_depth)
-   queue_depth = max_depth;
-
-   scsi_adjust_queue_depth(sdev, MSG_SIMPLE_TAG, queue_depth);
-
+   /* NCQ enabled? */
spin_lock_irqsave(ap->lock, flags);
-   if (queue_depth > 1)
-   dev->flags &= ~ATA_DFLAG_NCQ_OFF;
-   else
+   dev->flags &= ~ATA_DFLAG_NCQ_OFF;
+   if (queue_depth == 1 || !ata_ncq_enabled(dev)) {
dev->flags |= ATA_DFLAG_NCQ_OFF;
+   queue_depth = 1;
+   }
spin_unlock_irqrestore(ap->lock, flags);
 
+   /* limit and apply queue depth */
+   queue_depth = min(queue_depth, sdev->host->can_queue);
+   queue_depth = min(queue_depth, ata_id_queue_depth(dev->id));
+   queue_depth = min(queue_depth, ATA_MAX_QUEUE - 1);
+
+   if (sdev->queue_depth == queue_depth)
+   return -EINVAL;
+
+   scsi_adjust_queue_depth(sdev, MSG_SIMPLE_TAG, queue_depth);
return queue_depth;
 }
 
@@ -1454,11 +1457,9 @@ static void ata_scsi_qc_complete(struct ata_queued_cmd 
*qc)
 static int ata_scmd_need_defer(struct ata_device *dev, int is_io)
 {
struct ata_port *ap = dev->ap;
+   int is_ncq = is_io && ata_ncq_enabled(dev);
 
-   if (!(dev->flags & ATA_DFLAG_NCQ))
-   return 0;
-
-   if (is_io) {
+   if (is_ncq) {
if (!ata_tag_valid(ap->active_tag))
return 0;
} else {
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 91bb8ce..4e4e365 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -1035,6 +1035,21 @@ static inline u8 ata_chk_status(struct ata_port *ap)
return ap->ops->check_status(ap);
 }
 
+/**
+ * ata_ncq_enabled - Test whether NCQ is enabled
+ * @dev: ATA device to test for
+ *
+ * LOCKING:
+ * spin_lock_irqsave(host lock)
+ *
+ * RETURNS:
+ * 1 if NCQ is enabled for @dev, 0 otherwise.
+ */
+static inline int ata_ncq_enabled(struct ata_device *dev)
+{
+   return (dev->flags & (ATA_DFLAG_PIO | ATA_DFLAG_NCQ_OFF |
+ ATA_DFLAG_NCQ)) == ATA_DFLAG_NCQ;
+}
 
 /**
  * ata_pause - Flush writes and pause 400 nanoseconds.


Re: [Unionfs] Re: [-mm patch] UNION_FS must depend on SLAB

2007-02-20 Thread hooanon05

Josef Sipek:
> That's the only user of malloc_sizes. It is supposed to be an optimization -
> we get the smallest sized piece of memory even if we don't need all of it.
> This way we don't reallocate & memcpy needlessly.

How about exporting ksize to modules, and introduce a new function such
like this?
Of course, adding gfp_t to its parameter list make this function more generic.

void *kzrealloc(void *p, int nused, int new_sz)
{
void *q;

if (new_sz <= nused)
return p;
if (new_sz <= ksize(p)) {
memset(p + nused, 0, new_sz - nused);
return p;
}

q = kmalloc(new_sz, GFP_KERNEL);
if (unlikely(!q))
return NULL;
memcpy(q, p, nused);
memset(q + nused, 0, new_sz - nused);
kfree(p);
return q;
}


Junjiro Okajima
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sata_nv: kill old private BMDMA helper functions

2007-02-20 Thread Robert Hancock

sata_nv implemented its own copies of the BMDMA helper functions for ADMA,
since the ADMA BMDMA status registers are PIO while the other registers
are MMIO, and this was the only way to handle this previously. Now that
we have iomap support, the standard routines should just work, so use them.
The only thing we need to override as far as ADMA and BMDMA is the
post_internal_cmd callback, where we should only call ata_post_internal_cmd
if we are in port-register mode.

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

--- linux-2.6.20-git14edit/drivers/ata/sata_nv.c.before_cleanup 2007-02-20 
19:42:32.0 -0600
+++ linux-2.6.20-git14edit/drivers/ata/sata_nv.c2007-02-20 
19:45:44.0 -0600
@@ -255,10 +255,7 @@
static int nv_adma_port_resume(struct ata_port *ap);
static void nv_adma_error_handler(struct ata_port *ap);
static void nv_adma_host_stop(struct ata_host *host);
-static void nv_adma_bmdma_setup(struct ata_queued_cmd *qc);
-static void nv_adma_bmdma_start(struct ata_queued_cmd *qc);
-static void nv_adma_bmdma_stop(struct ata_queued_cmd *qc);
-static u8 nv_adma_bmdma_status(struct ata_port *ap);
+static void nv_adma_post_internal_cmd(struct ata_queued_cmd *qc);

enum nv_host_type
{
@@ -433,16 +430,16 @@
.exec_command   = ata_exec_command,
.check_status   = ata_check_status,
.dev_select = ata_std_dev_select,
-   .bmdma_setup= nv_adma_bmdma_setup,
-   .bmdma_start= nv_adma_bmdma_start,
-   .bmdma_stop = nv_adma_bmdma_stop,
-   .bmdma_status   = nv_adma_bmdma_status,
+   .bmdma_setup= ata_bmdma_setup,
+   .bmdma_start= ata_bmdma_start,
+   .bmdma_stop = ata_bmdma_stop,
+   .bmdma_status   = ata_bmdma_status,
.qc_prep= nv_adma_qc_prep,
.qc_issue   = nv_adma_qc_issue,
.freeze = nv_ck804_freeze,
.thaw   = nv_ck804_thaw,
.error_handler  = nv_adma_error_handler,
-   .post_internal_cmd  = nv_adma_bmdma_stop,
+   .post_internal_cmd  = nv_adma_post_internal_cmd,
.data_xfer  = ata_data_xfer,
.irq_handler= nv_adma_interrupt,
.irq_clear  = nv_adma_irq_clear,
@@ -899,73 +896,12 @@
iowrite8(ioread8(dma_stat_addr), dma_stat_addr);
}

-static void nv_adma_bmdma_setup(struct ata_queued_cmd *qc)
-{
-   struct ata_port *ap = qc->ap;
-   unsigned int rw = (qc->tf.flags & ATA_TFLAG_WRITE);
-   struct nv_adma_port_priv *pp = ap->private_data;
-   u8 dmactl;
-
-   if(!(pp->flags & NV_ADMA_PORT_REGISTER_MODE)) {
-   WARN_ON(1);
-   return;
-   }
-
-   /* load PRD table addr. */
-   iowrite32(ap->prd_dma, ap->ioaddr.bmdma_addr + ATA_DMA_TABLE_OFS);
-
-   /* specify data direction, triple-check start bit is clear */
-   dmactl = ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
-   dmactl &= ~(ATA_DMA_WR | ATA_DMA_START);
-   if (!rw)
-   dmactl |= ATA_DMA_WR;
-
-   iowrite8(dmactl, ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
-
-   /* issue r/w command */
-   ata_exec_command(ap, >tf);
-}
-
-static void nv_adma_bmdma_start(struct ata_queued_cmd *qc)
-{
-   struct ata_port *ap = qc->ap;
-   struct nv_adma_port_priv *pp = ap->private_data;
-   u8 dmactl;
-
-   if(!(pp->flags & NV_ADMA_PORT_REGISTER_MODE)) {
-   WARN_ON(1);
-   return;
-   }
-
-   /* start host DMA transaction */
-   dmactl = ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
-   iowrite8(dmactl | ATA_DMA_START,
-ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
-}
-
-static void nv_adma_bmdma_stop(struct ata_queued_cmd *qc)
+static void nv_adma_post_internal_cmd(struct ata_queued_cmd *qc)
{
-   struct ata_port *ap = qc->ap;
-   struct nv_adma_port_priv *pp = ap->private_data;
-
-   if(!(pp->flags & NV_ADMA_PORT_REGISTER_MODE))
-   return;
-
-   /* clear start/stop bit */
-   iowrite8(ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD) & ~ATA_DMA_START,
-ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
-
-   /* one-PIO-cycle guaranteed wait, per spec, for HDMA1:0 transition */
-   ata_altstatus(ap);/* dummy read */
-}
-
-static u8 nv_adma_bmdma_status(struct ata_port *ap)
-{
-   struct nv_adma_port_priv *pp = ap->private_data;
-
-   WARN_ON(!(pp->flags & NV_ADMA_PORT_REGISTER_MODE));
+   struct nv_adma_port_priv *pp = qc->ap->private_data;

-   return ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_STATUS);
+   if(pp->flags & NV_ADMA_PORT_REGISTER_MODE)
+   ata_bmdma_post_internal_cmd(qc);
}

static int nv_adma_port_start(struct ata_port *ap)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info 

Re: High CPU usage with sata_nv

2007-02-20 Thread Robert Hancock

Matthew Fredrickson wrote:
I have noticed something that might be related as well.  I am working on 
a device driver that would have periodic data errors due to 
exceptionally long interrupt handling latency.  I have come to the point 
that I suspect that it's the sata_nv driver, and now that we can't do 
the hdparm -u1 option for sata, it seems to be a bigger problem.


What kernel are you using? There were some complaints about latency 
problems (the ATA status register read taking a ridiculous amount of 
time to complete) on sata_nv previously, but 2.6.20 should eliminate 
that problem at least on nForce4 chipsets..


--
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: SLAB cache reaper on isolated cpus

2007-02-20 Thread Max Krasnyansky
Christoph Lameter wrote:
> On Tue, 20 Feb 2007, Max Krasnyansky wrote:
> 
>> Suppose I need to isolate a CPU. We already support at the scheduler and 
>> irq levels (irq affinity). But I want to go a bit further and avoid 
>> doing kernel work on isolated cpus as much as possible. For example I 
>> would not want to schedule work queues and stuff on them. Currently 
>> there are just a few users of the schedule_delayed_work_on(). cpufreq 
>> (don't care for isolation purposes), oprofile (same here) and slab. For 
>> the slab it'd be nice to run the reaper on some other CPU. But you're 
>> saying that locking depends on CPU pinning. Is there any other option 
>> besides disabling cache reap ? Is there a way for example to constraint 
>> the slabs on CPU X to not exceed N megs ?
> 
> There is no way to constrain the amount of slab work. In order to make the 
> above work we would have to disable the per cpu caches for a certain cpu. 
> Then there would be no need to run the cache reaper at all.
> 
> To some extend such functionality already exists. F.e. kmalloc_node() 
> already bypasses the per cpu caches (most of the time).  kmalloc_node will 
> have to take a spinlock on a shared cacheline on each invocation. kmalloc 
> does only touch per cpu data during regular operations. Thus kmalloc() is 
> much 
> faster than kmalloc_node() and the cachelines for kmalloc() can be kept in 
> the per cpu cache.
> 
> If we could disable all per cpu caches for certain cpus then you could 
> make this work. All slab OS interference would be off the processor.

Hmm. That's an idea. I'll play with it later today or tomorrow.

Thanks
Max

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] trivial type cast clean up for find_next_zero_bit

2007-02-20 Thread Ken Chen

clean up unneeded type cast by properly declare data type.

Signed-off-by: Ken Chen <[EMAIL PROTECTED]>


diff --git a/arch/i386/lib/bitops.c b/arch/i386/lib/bitops.c
index 97db385..afd0045 100644
--- a/arch/i386/lib/bitops.c
+++ b/arch/i386/lib/bitops.c
@@ -43,7 +43,7 @@ EXPORT_SYMBOL(find_next_bit);
 */
int find_next_zero_bit(const unsigned long *addr, int size, int offset)
{
-   unsigned long * p = ((unsigned long *) addr) + (offset >> 5);
+   const unsigned long *p = addr + (offset >> 5);
int set = 0, bit = offset & 31, res;

if (bit) {
@@ -64,7 +64,7 @@ int find_next_zero_bit(const unsigned lo
/*
 * No zero yet, search remaining full bytes for a zero
 */
-   res = find_first_zero_bit (p, size - 32 * (p - (unsigned long *) addr));
+   res = find_first_zero_bit(p, size - 32 * (p - addr));
return (offset + set + res);
}
EXPORT_SYMBOL(find_next_zero_bit);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: SATA problems

2007-02-20 Thread Tejun Heo
Pablo Sebastian Greco wrote:
> Tejun Heo wrote:
>> * Pablo, the bug you saw was bad interaction between blacklisted NCQ
>> device and dynamic queue depth adjustment.  Patches are submitted to fix
>> the problem.  Just drop the blacklist patch.  Your drives should work
>> fine in NCQ mode.  My gut feeling is that your problem is power related
>> from the beginning.
>>   
> I had the same problems with a new Power Supply, Now everything is ok
> with the old Power Supply and the new drives.

So, it was bad drives?  Are you using the same model or different ones?
 NCQ works okay now?

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


Re: 2.6.20-rc6 libata PATA ATAPI CDROM is not working

2007-02-20 Thread Ioan Ionita

On 2/11/07, Tejun Heo <[EMAIL PROTECTED]> wrote:

Please test the attached patch over 2.6.20.


No luck for me. I'm using pata_sis. Some error bits:

agpgart: Found an AGP 3.0 compliant device at :00:00.0.
agpgart: Putting AGP V3 device at :00:00.0 into 16x mode
agpgart: SiS delay workaround: giving bridge time to recover.
agpgart: Putting AGP V3 device at :01:00.0 into 16x mode
ata2.00: qc timeout (cmd 0xa0)
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: (BMDMA stat 0x24)
ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x28 data 4096 in
res 51/51:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
ata2: port is slow to respond, please be patient (Status 0xd0)
ata2: port failed to respond (30 secs, Status 0xd0)
ata2: soft resetting port
ata2.00: configured for UDMA/33
ata2: EH complete
ata2.00: qc timeout (cmd 0xa0)
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: (BMDMA stat 0x24)
ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x28 data 4096 in
res 51/51:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
ata2: port is slow to respond, please be patient (Status 0xd0)
ata2: port failed to respond (30 secs, Status 0xd0)
ata2: soft resetting port
ata2.00: configured for UDMA/33
ata2: EH complete
ata2.00: qc timeout (cmd 0xa0)
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: (BMDMA stat 0x24)
ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x28 data 4096 in
res 51/51:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
ata2: port is slow to respond, please be patient (Status 0xd0)


Compressed dmesg attached. Thanks.


dmesg.gz
Description: GNU Zip compressed data


Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

2007-02-20 Thread Bartlomiej Zolnierkiewicz

Hi,

On Wednesday 21 February 2007 03:13, Suleiman Souhlal wrote:
> 
> On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> >
> > On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:
> >> It can be changed via /proc/ide/hd?/settings.
> >
> > Why do we need to change IDE DMA timeout dynamically?
> 
> I've used it to test error recovery (for example).

Seems quite useable for developers but I would prefer not to
expose it in production kernels for end users.

> > BTW /proc/ide/hd?/settings is obsoleted
> 
> What's the preferred way of changing such settings, these days?

sysfs

ide.c:ide_dev_attrs[] for generic attributes valid for all devices

Thanks,
Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/3] Make the IDE DMA timeout modifiable

2007-02-20 Thread Suleiman Souhlal


On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:



On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:

It can be changed via /proc/ide/hd?/settings.


Why do we need to change IDE DMA timeout dynamically?


I've used it to test error recovery (for example).


BTW /proc/ide/hd?/settings is obsoleted


What's the preferred way of changing such settings, these days?

-- Suleiman


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


Re: [stable] [patch 00/50] -stable review

2007-02-20 Thread Michael Krufky
Greg KH wrote:
> Ok, I've now gotten all of these for .19 and .18.
> 
> If I've missed anything, please let me know.
> 
> thanks for your patience.

Looks good... Thank you, Greg.

Greg KH wrote:
> This will probably be the last release of the 2.6.19-stable series, so
> if there are patches that you feel should be applied to that tree,
> please let me know.

Normally, I would wait for a patch to appear in Linus' tree before I send it to 
-stable,
however, this patch can not wait.  Since 2.6.18-stable and 2.6.19-stable have 
their last
releases pending review, it is imperative that this final patch be added to the 
queue, if
possible.

This patch was recently submitted, and fixes many horrible, previously 
unexplained bugs of the
past.

Please queue this for the final 2.6.18 and 2.6.19 -stable releases, as well as 
for 2.6.20.1

Thank you,

Michael Krufky

---

dvbdev: fix illegal re-usage of fileoperations struct

From: Marcel Siegert <[EMAIL PROTECTED]>

 Arjan van de Ven <[EMAIL PROTECTED]> reported an illegal re-usage of the 
fileoperations struct
 if more than one dvb device(e.g. frontend) is present. this patch fixes this 
issue.
 it allocates a new fileoperations struct each time a device is registered and 
copies the default
 template fileops.

Signed-off-by: Marcel Siegert <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>

---
 linux/drivers/media/dvb/dvb-core/dvbdev.c |   13 +
 1 file changed, 13 insertions(+)

--- linux/drivers/media/dvb/dvb-core/dvbdev.c.orig
+++ linux/drivers/media/dvb/dvb-core/dvbdev.c
@@ -211,6 +211,8 @@
const struct dvb_device *template, void *priv, int type)
 {
struct dvb_device *dvbdev;
+   struct file_operations *dvbdevfops;
+
int id;
 
if (mutex_lock_interruptible(_register_lock))
@@ -230,12 +232,22 @@
return -ENOMEM;
}
 
+   dvbdevfops = kzalloc(sizeof(struct file_operations), GFP_KERNEL);
+
+   if (!dvbdevfops) {
+   kfree (dvbdev);
+   mutex_unlock(_register_lock);
+   return -ENOMEM;
+   }
+
memcpy(dvbdev, template, sizeof(struct dvb_device));
dvbdev->type = type;
dvbdev->id = id;
dvbdev->adapter = adap;
dvbdev->priv = priv;
+   dvbdev->fops = dvbdevfops;
 
+   memcpy(dvbdev->fops, template->fops, sizeof(struct file_operations));
dvbdev->fops->owner = adap->module;
 
list_add_tail (>list_head, >device_list);
@@ -263,6 +275,7 @@
dvbdev->type, dvbdev->id)));
 
list_del (>list_head);
+   kfree (dvbdev->fops);
kfree (dvbdev);
 }
 EXPORT_SYMBOL(dvb_unregister_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/


Re: [PATCH 2/3] Don't change transfer speed while requests are in flight

2007-02-20 Thread Bartlomiej Zolnierkiewicz

On Wednesday 21 February 2007 02:21, Suleiman Souhlal wrote:
> Use ide_wait_cmd() in ide_config_drive_speed() if the drive has been
> initialized and we're not in an interrupt, to avoid changing the
> xfer speed while requests are in flight.

Many devices have problems with SETFEATURES_XFER if the WIN_SETFEATURES
command is driven by IRQ so we must resort to the polling mode.
This also implies that ide_config_drive_speed() generally does its
job right and the problem lies in the higher layers.

set_using_dma() should queue special driver specific request (same goes
for some other options from /proc/ide/hdx/settings / ioctls).

I have a patch re-writting /proc/ide/hdx/settings so that there are
->get/->set methods for each setting.  This should help in designing
special driver request but I need some more time to sync the patch
with the recent IDE changes.  I will get back to you on this one.

Thanks,
Bart

> An easy way to trigger the problem is to dd the disk while doing
> while :; do hdparm -d 1 /dev/hdc> /dev/null; done
> 
> While there, remove some commented-out code.
> 
> Signed-off-by:Suleiman Souhlal <[EMAIL PROTECTED]>
> 
> ---
>  drivers/ide/ide-iops.c |   35 ---
>  1 files changed, 20 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
> index c67b3b1..35ab3af 100644
> --- a/drivers/ide/ide-iops.c
> +++ b/drivers/ide/ide-iops.c
> @@ -748,32 +748,36 @@ int ide_config_drive_speed (ide_drive_t 
>   int i, error= 1;
>   u8 stat;
>  
> -//   while (HWGROUP(drive)->busy)
> -//   msleep(50);
> + /*
> +  * Just use ide_wait_cmd() if the drive has been initialized and we
> +  * aren't in an interrupt handler, to avoid changing the xfer speed
> +  * while requests are in flight.
> +  *
> +  * If we are in an interrupt, it should be safe to issue
> +  * SETFEATURES manually, since there shouldn't be any requests in
> +  * flight.
> +  */
> + if (drive->queue != NULL && !in_interrupt()) {
> + error = ide_wait_cmd(drive, WIN_SETFEATURES, speed,
> + SETFEATURES_XFER, 0, NULL);
> + if (error) {
> + stat = hwif->INB(IDE_STATUS_REG);
> + ide_dump_status(drive, "set_drive_speed_status", stat);
> + return (error);
> + }
> + goto done;
> + }
>  
>  #ifdef CONFIG_BLK_DEV_IDEDMA
>   if (hwif->ide_dma_check) /* check if host supports DMA */
>   hwif->dma_host_off(drive);
>  #endif
>  
> - /*
> -  * Don't use ide_wait_cmd here - it will
> -  * attempt to set_geometry and recalibrate,
> -  * but for some reason these don't work at
> -  * this point (lost interrupt).
> -  */
>  /*
>   * Select the drive, and issue the SETFEATURES command
>   */
>   disable_irq_nosync(hwif->irq);
>   
> - /*
> -  *  FIXME: we race against the running IRQ here if
> -  *  this is called from non IRQ context. If we use
> -  *  disable_irq() we hang on the error path. Work
> -  *  is needed.
> -  */
> -  
>   udelay(1);
>   SELECT_DRIVE(drive);
>   SELECT_MASK(drive, 0);
> @@ -835,6 +839,7 @@ #ifdef CONFIG_BLK_DEV_IDEDMA
>   hwif->dma_off_quietly(drive);
>  #endif
>  
> +done:
>   switch(speed) {
>   case XFER_UDMA_7:   drive->id->dma_ultra |= 0x8080; break;
>   case XFER_UDMA_6:   drive->id->dma_ultra |= 0x4040; break;
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[patch 07/18] grow_buffers() infinite loop fix (CVE-2006-5757, CVE-2006-6060)

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Andrew Morton <[EMAIL PROTECTED]>

If grow_buffers() is for some reason passed a block number which wants to lie
outside the maximum-addressable pagecache range (PAGE_SIZE * 4G bytes) then it
will accidentally truncate `index' and will then instnatiate a page at the
wrong pagecache offset.  This causes __getblk_slow() to go into an infinite
loop.

This can happen with corrupted disks, or with software errors elsewhere.

Detect that, and handle it.

Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 fs/buffer.c |   21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/fs/buffer.c
+++ linux-2.6.18.7/fs/buffer.c
@@ -1179,8 +1179,21 @@ grow_buffers(struct block_device *bdev, 
} while ((size << sizebits) < PAGE_SIZE);
 
index = block >> sizebits;
-   block = index << sizebits;
 
+   /*
+* Check for a block which wants to lie outside our maximum possible
+* pagecache index.  (this comparison is done using sector_t types).
+*/
+   if (unlikely(index != block >> sizebits)) {
+   char b[BDEVNAME_SIZE];
+
+   printk(KERN_ERR "%s: requested out-of-range block %llu for "
+   "device %s\n",
+   __FUNCTION__, (unsigned long long)block,
+   bdevname(bdev, b));
+   return -EIO;
+   }
+   block = index << sizebits;
/* Create a page with the proper size buffers.. */
page = grow_dev_page(bdev, block, index, size);
if (!page)
@@ -1207,12 +1220,16 @@ __getblk_slow(struct block_device *bdev,
 
for (;;) {
struct buffer_head * bh;
+   int ret;
 
bh = __find_get_block(bdev, block, size);
if (bh)
return bh;
 
-   if (!grow_buffers(bdev, block, size))
+   ret = grow_buffers(bdev, block, size);
+   if (ret < 0)
+   return NULL;
+   if (ret == 0)
free_more_memory();
}
 }

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 08/18] hfs_fill_super returns success even if no root inode (CVE-2006-6056)

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Eric Sandeen <[EMAIL PROTECTED]>

http://kernelfun.blogspot.com/2006/11/mokb-14-11-2006-linux-26x-selinux.html

mount that image...
fs: filesystem was not cleanly unmounted, running fsck.hfs is recommended.  
mounting read-only.
hfs: get root inode failed.
BUG: unable to handle kernel NULL pointer dereference at virtual address 
0018
 printing eip
...
EIP is at superblock_doinit+0x21/0x767
...
 [] selinux_sb_kern_mount+0xc/0x4b
 [] vfs_kern_mount+0x99/0xf6
 [] do_kern_mount+0x2d/0x3e
 [] do_mount+0x5fa/0x66d
 [] sys_mount+0x77/0xae
 [] syscall_call+0x7/0xb
DWARF2 unwinder stuck at syscall_call+0x7/0xb

hfs_fill_super() returns success even if
  root_inode = hfs_iget(sb, _key->cat, );
or
  sb->s_root = d_alloc_root(root_inode);

fails.  This superblock finds its way to superblock_doinit() which does:

struct dentry *root = sb->s_root;
struct inode *inode = root->d_inode;

and boom.  Need to make sure the error cases return an error, I think.

[EMAIL PROTECTED]: return -ENOMEM on oom]
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Cc: Roman Zippel <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
Date: Thu, 16 Nov 2006 09:19:22 + (-0800)
Subject: [patch 08/18] [PATCH] hfs_fill_super returns success even if no root 
inode
X-Git-Tag: v2.6.19
X-Git-Url: 
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d6ddf55440833fd9404138026af246c51ebeef22

 fs/hfs/super.c |2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.18.7.orig/fs/hfs/super.c
+++ linux-2.6.18.7/fs/hfs/super.c
@@ -391,11 +391,13 @@ static int hfs_fill_super(struct super_b
hfs_find_exit();
goto bail_no_root;
}
+   res = -EINVAL;
root_inode = hfs_iget(sb, _key->cat, );
hfs_find_exit();
if (!root_inode)
goto bail_no_root;
 
+   res = -ENOMEM;
sb->s_root = d_alloc_root(root_inode);
if (!sb->s_root)
goto bail_iput;

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 15/18] V4L: fix ks0127 status flags

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Martin Samuelsson <[EMAIL PROTECTED]>

Or status flags together in DECODER_GET_STATUS instead of and-zapping them.

(cherry picked from commit 55d5440d4587454628a850ce26703639885af678)

Signed-off-by: Martin Samuelsson <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/video/ks0127.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.18.7.orig/drivers/media/video/ks0127.c
+++ linux-2.6.18.7/drivers/media/video/ks0127.c
@@ -712,13 +712,13 @@ static int ks0127_command(struct i2c_cli
*iarg = 0;
status = ks0127_read(ks, KS_STAT);
if (!(status & 0x20))/* NOVID not set */
-   *iarg = (*iarg & DECODER_STATUS_GOOD);
+   *iarg = (*iarg | DECODER_STATUS_GOOD);
if ((status & 0x01))  /* CLOCK set */
-   *iarg = (*iarg & DECODER_STATUS_COLOR);
+   *iarg = (*iarg | DECODER_STATUS_COLOR);
if ((status & 0x08))   /* PALDET set */
-   *iarg = (*iarg & DECODER_STATUS_PAL);
+   *iarg = (*iarg | DECODER_STATUS_PAL);
else
-   *iarg = (*iarg & DECODER_STATUS_NTSC);
+   *iarg = (*iarg | DECODER_STATUS_NTSC);
break;
 
//Catch any unknown command

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 11/18] v4l: cx2341x audio_properties is an u16, not u8

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Hans Verkuil <[EMAIL PROTECTED]>

This bug broke the MPEG audio mode controls.

(cherry picked from commit cb2c7b4927c8f376b7ba9557978d8c59ed472664)

Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 include/media/cx2341x.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/include/media/cx2341x.h
+++ linux-2.6.18.7/include/media/cx2341x.h
@@ -49,7 +49,7 @@ struct cx2341x_mpeg_params {
enum v4l2_mpeg_audio_mode_extension audio_mode_extension;
enum v4l2_mpeg_audio_emphasis audio_emphasis;
enum v4l2_mpeg_audio_crc audio_crc;
-   u8 audio_properties;
+   u16 audio_properties;
 
/* video */
enum v4l2_mpeg_video_encoding video_encoding;

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 17/18] V4L: buf_qbuf: fix videobuf_queue->stream corruption and lockup

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Oleg Nesterov <[EMAIL PROTECTED]>

We are doing ->buf_prepare(buf) before adding buf to q->stream list. This
means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer.

(cherry picked from commit 419dd8378dfa32985672ab7927b4bc827f33b332)

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/video/video-buf.c |1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.18.7.orig/drivers/media/video/video-buf.c
+++ linux-2.6.18.7/drivers/media/video/video-buf.c
@@ -695,6 +695,7 @@ videobuf_qbuf(struct videobuf_queue *q,
goto done;
}
if (buf->state == STATE_QUEUED ||
+   buf->state == STATE_PREPARED ||
buf->state == STATE_ACTIVE) {
dprintk(1,"qbuf: buffer is already queued or active.\n");
goto done;

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 18/18] x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: "Paolo 'Blaisorblade' Giarrusso" <[EMAIL PROTECTED]>

Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and
forced by binary compatibility. UML/32bit breaks because of this - since it is 
wise
enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host
kernels.

Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had:

   default:
return sys_ptrace(request, pid, addr, data);

Instead here we have:
case PTRACE_GET_THREAD_AREA:
case ...:
return sys_ptrace(request, pid, addr, data);

default:
return -EINVAL;

This change was a style change - when a case is added, it must be explicitly
tested this way. In this case, not enough testing was done.

Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 arch/x86_64/ia32/ptrace32.c |1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.18.7.orig/arch/x86_64/ia32/ptrace32.c
+++ linux-2.6.18.7/arch/x86_64/ia32/ptrace32.c
@@ -239,6 +239,7 @@ asmlinkage long sys32_ptrace(long reques
case PTRACE_SINGLESTEP:
case PTRACE_DETACH:
case PTRACE_SYSCALL:
+   case PTRACE_OLDSETOPTIONS:
case PTRACE_SETOPTIONS:
return sys_ptrace(request, pid, addr, data); 
 

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


[patch 16/18] V4L: tveeprom: autodetect LG TAPC G701D as tuner type 37

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Michael Krufky <[EMAIL PROTECTED]>

Autodetect LG TAPC G701D as tuner type 37, fixing
mis-detected tuners in some Hauppauge tv tuner cards.

Thanks to Adonis Papas, for pointing this out.

(cherry picked from commit 1323fbda1343f50f198bc8bd6d1d59c8b7fc45bf)

Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/video/tveeprom.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/media/video/tveeprom.c
+++ linux-2.6.18.7/drivers/media/video/tveeprom.c
@@ -184,7 +184,7 @@ hauppauge_tuner[] =
{ TUNER_ABSENT,"Thompson DTT757"},
/* 80-89 */
{ TUNER_ABSENT,"Philips FQ1216LME MK3"},
-   { TUNER_ABSENT,"LG TAPC G701D"},
+   { TUNER_LG_PAL_NEW_TAPC, "LG TAPC G701D"},
{ TUNER_LG_NTSC_NEW_TAPC, "LG TAPC H791F"},
{ TUNER_LG_PAL_NEW_TAPC, "TCL 2002MB 3"},
{ TUNER_LG_PAL_NEW_TAPC, "TCL 2002MI 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/


[patch 10/18] dvb-core: fix bug in CRC-32 checking on 64-bit systems

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Ang Way Chuang <[EMAIL PROTECTED]>

CRC-32 checking during ULE decapsulation always failed on x86_64 systems due
to the size of a variable used to store CRC. This bug was discovered on
Fedora Core 6 with kernel-2.6.18-1.2849. The i386 counterpart has no such
problem. This patch has been tested on 64-bit system as well as 32-bit system.

(cherry picked from commit dedcefb085fe98a1feaf63590fe2fc7e0ecb1987)

Signed-off-by: Ang Way Chuang <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/dvb/dvb-core/dvb_net.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/drivers/media/dvb/dvb-core/dvb_net.c
+++ linux-2.6.18.7/drivers/media/dvb/dvb-core/dvb_net.c
@@ -604,7 +604,7 @@ static void dvb_net_ule( struct net_devi
{ , sizeof utype },
{ priv->ule_skb->data, priv->ule_skb->len - 4 }
};
-   unsigned long ule_crc = ~0L, expected_crc;
+   u32 ule_crc = ~0L, expected_crc;
if (priv->ule_dbit) {
/* Set D-bit for CRC32 verification,
 * if it was set originally. */
@@ -617,7 +617,7 @@ static void dvb_net_ule( struct net_devi
   *((u8 *)priv->ule_skb->tail - 2) << 8 |
   *((u8 *)priv->ule_skb->tail - 1);
if (ule_crc != expected_crc) {
-   printk(KERN_WARNING "%lu: CRC32 check FAILED: 
%#lx / %#lx, SNDU len %d type %#x, ts_remain %d, next 2: %x.\n",
+   printk(KERN_WARNING "%lu: CRC32 check FAILED: 
%08x / %08x, SNDU len %d type %#x, ts_remain %d, next 2: %x.\n",
   priv->ts_count, ule_crc, expected_crc, 
priv->ule_sndu_len, priv->ule_sndu_type, ts_remain, ts_remain > 2 ? *(unsigned 
short *)from_where : 0);
 
 #ifdef ULE_DEBUG

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


[patch 14/18] V4L: Fix quickcam communicator driver for big endian architectures

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Grant Likely <[EMAIL PROTECTED]>

Host endianess does not affect the order that pixel rgb data comes
in from the quickcam (the values are bytes, not words or longs).  The
driver is erroniously swapping the order of rgb values for big endian
machines.  This patch is needed get the Quickcam communicator working
on big endian machines (tested on powerpc)

(cherry picked from commit c6d704c8c4453f05717ba88792f70f8babf95268)

Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/video/usbvideo/quickcam_messenger.h |   14 --
 1 file changed, 14 deletions(-)

--- linux-2.6.18.7.orig/drivers/media/video/usbvideo/quickcam_messenger.h
+++ linux-2.6.18.7/drivers/media/video/usbvideo/quickcam_messenger.h
@@ -35,27 +35,13 @@ struct rgb {
 };
 
 struct bayL0 {
-#ifdef __BIG_ENDIAN
-   u8 r;
-   u8 g;
-#elif __LITTLE_ENDIAN
u8 g;
u8 r;
-#else
-#error not byte order defined
-#endif
 };
 
 struct bayL1 {
-#ifdef __BIG_ENDIAN
-   u8 g;
-   u8 b;
-#elif __LITTLE_ENDIAN
u8 b;
u8 g;
-#else
-#error not byte order defined
-#endif
 };
 
 struct cam_size {

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


[patch 09/18] IB/mad: Fix race between cancel and receive completion

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Roland Dreier <[EMAIL PROTECTED]>

When ib_cancel_mad() is called, it puts the canceled send on a list
and schedules a "flushed" callback from process context.  However,
this leaves a window where a receive completion could be processed
before the send is fully flushed.

This is fine, except that ib_find_send_mad() will find the MAD and
return it to the receive processing, which results in the sender
getting both a successful receive and a "flushed" send completion for
the same request.  Understandably, this confuses the sender, which is
expecting only one of these two callbacks, and leads to grief such as
a use-after-free in IPoIB.

Fix this by changing ib_find_send_mad() to return a send struct only
if the status is still successful (and not "flushed").  The search of
the send_list already had this check, so this patch just adds the same
check to the search of the wait_list.

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---

---
 drivers/infiniband/core/mad.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/infiniband/core/mad.c
+++ linux-2.6.18.7/drivers/infiniband/core/mad.c
@@ -1750,7 +1750,7 @@ ib_find_send_mad(struct ib_mad_agent_pri
 */
(is_direct(wc->recv_buf.mad->mad_hdr.mgmt_class) ||
 rcv_has_same_gid(mad_agent_priv, wr, wc)))
-   return wr;
+   return (wr->status == IB_WC_SUCCESS) ? wr : NULL;
}
 
/*

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 06/18] i2c: fix broken ds1337 initialization

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Dirk Eibach <[EMAIL PROTECTED]>

On a custom board with ds1337 RTC I found that upgrade from 2.6.15 to
2.6.18 broke RTC support.

The main problem are changes to ds1337_init_client().
When a ds1337 recognizes a problem (e.g. power or clock failure) bit 7
in status register is set. This has to be reset by writing 0 to status
register. But since there are only 16 byte written to the chip and the
first byte is interpreted as an address, the status register (which is
the 16th) is never written.
The other problem is, that initializing all registers to zero is not
valid for day, date and month register. Funny enough this is checked by
ds1337_detect(), which depends on this values not being zero. So then
treated by ds1337_init_client() the ds1337 is not detected anymore,
whereas the failure bit in the status register is still set.

Broken by commit f9e8957937ebf60d22732a5ca9130f48a7603f60 (2.6.16-rc1,
2006-01-06). This fix is in Linus' tree since 2.6.20-rc1 (commit
763d9c046a2e511ec090a8986d3f85edf7448e7e).

Signed-off-by: Dirk Stieler <[EMAIL PROTECTED]>
Signed-off-by: Dirk Eibach <[EMAIL PROTECTED]>
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 drivers/i2c/chips/ds1337.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/i2c/chips/ds1337.c
+++ linux-2.6.18.7/drivers/i2c/chips/ds1337.c
@@ -347,13 +347,19 @@ static void ds1337_init_client(struct i2
 
if ((status & 0x80) || (control & 0x80)) {
/* RTC not running */
-   u8 buf[16];
+   u8 buf[1+16];   /* First byte is interpreted as address */
struct i2c_msg msg[1];
 
dev_dbg(>dev, "%s: RTC not running!\n", __FUNCTION__);
 
/* Initialize all, including STATUS and CONTROL to zero */
memset(buf, 0, sizeof(buf));
+
+   /* Write valid values in the date/time registers */
+   buf[1+DS1337_REG_DAY] = 1;
+   buf[1+DS1337_REG_DATE] = 1;
+   buf[1+DS1337_REG_MONTH] = 1;
+
msg[0].addr = client->addr;
msg[0].flags = 0;
msg[0].len = sizeof(buf);

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


[patch 13/18] V4L: cx88: Fix lockup on suspend

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Robert Hancock <[EMAIL PROTECTED]>

Suspending with the cx88xx module loaded causes the system to lock up
because the cx88_audio_thread kthread was missing a try_to_freeze()
call, which caused it to go into a tight loop and result in softlockup
when suspending. Fix that.

(cherry picked from commit a96afb3e9428f2e7463344f12dbc85faf08e2e09)

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/video/cx88/cx88-tvaudio.c |2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.18.7.orig/drivers/media/video/cx88/cx88-tvaudio.c
+++ linux-2.6.18.7/drivers/media/video/cx88/cx88-tvaudio.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -979,6 +980,7 @@ int cx88_audio_thread(void *data)
msleep_interruptible(1000);
if (kthread_should_stop())
break;
+   try_to_freeze();
 
/* just monitor the audio status for now ... */
memset(, 0, sizeof(t));

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 12/18] v4l: cx88: Fix leadtek_eeprom tagging

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Jean Delvare <[EMAIL PROTECTED]>

reference to .init.text: from .text between 'cx88_card_setup'
(at offset 0x68c) and 'cx88_risc_field'
Caused by leadtek_eeprom() being declared __devinit and called from
a non-devinit context.

(cherry picked from commit 69f7e75a9d45e5eaca16917a8d0dedf76149f13f)

Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/video/cx88/cx88-cards.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/media/video/cx88/cx88-cards.c
+++ linux-2.6.18.7/drivers/media/video/cx88/cx88-cards.c
@@ -1465,7 +1465,7 @@ const unsigned int cx88_idcount = ARRAY_
 /* --- */
 /* some leadtek specific stuff */
 
-static void __devinit leadtek_eeprom(struct cx88_core *core, u8 *eeprom_data)
+static void leadtek_eeprom(struct cx88_core *core, u8 *eeprom_data)
 {
/* This is just for the "Winfast 2000XP Expert" board ATM; I don't have 
data on
 * any others.

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 05/18] IB/srp: Fix FMR mapping for 32-bit kernels and addresses above 4G

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Roland Dreier <[EMAIL PROTECTED]>

struct srp_device.fmr_page_mask was unsigned long, which means that
the top part of addresses above 4G was being chopped off on 32-bit
architectures.  Of course nothing good happens when data from SRP
targets is DMAed to the wrong place.

Fix this by changing fmr_page_mask to u64, to match the addresses
actually used by IB devices.

Thanks to Brian Cain <[EMAIL PROTECTED]> and David McMillen
<[EMAIL PROTECTED]> for help diagnosing the bug and testing
the fix.

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/infiniband/ulp/srp/ib_srp.c |2 +-
 drivers/infiniband/ulp/srp/ib_srp.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/drivers/infiniband/ulp/srp/ib_srp.c
+++ linux-2.6.18.7/drivers/infiniband/ulp/srp/ib_srp.c
@@ -1851,7 +1851,7 @@ static void srp_add_one(struct ib_device
 */
srp_dev->fmr_page_shift = max(9, ffs(dev_attr->page_size_cap) - 1);
srp_dev->fmr_page_size  = 1 << srp_dev->fmr_page_shift;
-   srp_dev->fmr_page_mask  = ~((unsigned long) srp_dev->fmr_page_size - 1);
+   srp_dev->fmr_page_mask  = ~((u64) srp_dev->fmr_page_size - 1);
 
INIT_LIST_HEAD(_dev->dev_list);
 
--- linux-2.6.18.7.orig/drivers/infiniband/ulp/srp/ib_srp.h
+++ linux-2.6.18.7/drivers/infiniband/ulp/srp/ib_srp.h
@@ -87,7 +87,7 @@ struct srp_device {
struct ib_fmr_pool *fmr_pool;
int fmr_page_shift;
int fmr_page_size;
-   unsigned long   fmr_page_mask;
+   u64 fmr_page_mask;
 };
 
 struct srp_host {

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 02/18] bcm43xx: Fix for oops on ampdu status

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Michael Buesch <[EMAIL PROTECTED]>

If bcm43xx were to process an afterburner (ampdu) status response, Linux would 
oops. The
ampdu and intermediate status bits are properly named.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/net/wireless/bcm43xx/bcm43xx_main.c |8 +++-
 drivers/net/wireless/bcm43xx/bcm43xx_xmit.h |   10 ++
 2 files changed, 5 insertions(+), 13 deletions(-)

--- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1449,12 +1449,10 @@ static void handle_irq_transmit_status(s
 
bcm43xx_debugfs_log_txstat(bcm, );
 
-   if (stat.flags & BCM43xx_TXSTAT_FLAG_IGNORE)
+   if (stat.flags & BCM43xx_TXSTAT_FLAG_AMPDU)
+   continue;
+   if (stat.flags & BCM43xx_TXSTAT_FLAG_INTER)
continue;
-   if (!(stat.flags & BCM43xx_TXSTAT_FLAG_ACK)) {
-   //TODO: packet was not acked (was lost)
-   }
-   //TODO: There are more (unknown) flags to test. see 
bcm43xx_main.h
 
if (bcm43xx_using_pio(bcm))
bcm43xx_pio_handle_xmitstatus(bcm, );
--- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.h
+++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx_xmit.h
@@ -137,14 +137,8 @@ struct bcm43xx_xmitstatus {
u16 unknown; //FIXME
 };
 
-#define BCM43xx_TXSTAT_FLAG_ACK0x01
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x02
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x04
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x08
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x10
-#define BCM43xx_TXSTAT_FLAG_IGNORE 0x20
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x40
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x80
+#define BCM43xx_TXSTAT_FLAG_AMPDU  0x10
+#define BCM43xx_TXSTAT_FLAG_INTER  0x20
 
 u8 bcm43xx_plcp_get_ratecode_cck(const u8 bitrate);
 u8 bcm43xx_plcp_get_ratecode_ofdm(const u8 bitrate);

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 04/18] SCSI: add missing cdb clearing in scsi_execute()

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Tejun Heo <[EMAIL PROTECTED]>

Clear-garbage-after-CDB patch missed scsi_execute() and it causes some
ODDs (HL-DT-ST DVD-RAM GSA-H30N) choke during SCSI scan.  Note that
this patch is only for -stable.  There is another more reliable fix
for this problem proposed for devel tree.

http://thread.gmane.org/gmane.linux.ide/14605/focus=14605

Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Jens Axboe <[EMAIL PROTECTED]>
Cc: Douglas Gilbert <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/scsi/scsi_lib.c |1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.18.7.orig/drivers/scsi/scsi_lib.c
+++ linux-2.6.18.7/drivers/scsi/scsi_lib.c
@@ -191,6 +191,7 @@ int scsi_execute(struct scsi_device *sde
goto out;
 
req->cmd_len = COMMAND_SIZE(cmd[0]);
+   memset(req->cmd, 0, BLK_MAX_CDB); /* ATAPI hates garbage after CDB */
memcpy(req->cmd, cmd, req->cmd_len);
req->sense = sense;
req->sense_len = 0;

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


[patch 03/18] Dont leak NT bit into next task

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Andi Kleen <[EMAIL PROTECTED]>

SYSENTER can cause a NT to be set which might cause crashes on the IRET
in the next task.

Following similar i386 patch from Linus.

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
[backport from Chuck Ebbert]
Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 arch/x86_64/kernel/entry.S   |4 
 arch/x86_64/kernel/setup64.c |4 
 include/asm-x86_64/system.h  |5 +++--
 3 files changed, 11 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/arch/x86_64/kernel/entry.S
+++ linux-2.6.18.7/arch/x86_64/kernel/entry.S
@@ -146,6 +146,10 @@
 /* rdi:prev */ 
 ENTRY(ret_from_fork)
CFI_DEFAULT_STACK
+   push kernel_eflags(%rip)
+   CFI_ADJUST_CFA_OFFSET 4
+   popf# reset kernel eflags
+   CFI_ADJUST_CFA_OFFSET -4
call schedule_tail
GET_THREAD_INFO(%rcx)
testl $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT),threadinfo_flags(%rcx)
--- linux-2.6.18.7.orig/arch/x86_64/kernel/setup64.c
+++ linux-2.6.18.7/arch/x86_64/kernel/setup64.c
@@ -178,6 +178,8 @@ void __cpuinit check_efer(void)
 }   
 }
 
+unsigned long kernel_eflags;
+
 /*
  * cpu_init() initializes state that is per-CPU. Some data is already
  * initialized (naturally) in the bootstrap process, such as the GDT
@@ -290,4 +292,6 @@ void __cpuinit cpu_init (void)
set_debugreg(0UL, 7);
 
fpu_init(); 
+
+   raw_local_save_flags(kernel_eflags);
 }
--- linux-2.6.18.7.orig/include/asm-x86_64/system.h
+++ linux-2.6.18.7/include/asm-x86_64/system.h
@@ -14,12 +14,13 @@
 #define __RESTORE(reg,offset) "movq (14-" #offset ")*8(%%rsp),%%" #reg "\n\t"
 
 /* frame pointer must be last for get_wchan */
-#define SAVE_CONTEXT"pushq %%rbp ; movq %%rsi,%%rbp\n\t"
-#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
+#define SAVE_CONTEXT"pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
+#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
 
 #define __EXTRA_CLOBBER  \
,"rcx","rbx","rdx","r8","r9","r10","r11","r12","r13","r14","r15"
 
+/* Save restore flags to clear handle leaking NT */
 #define switch_to(prev,next,last) \
asm volatile(SAVE_CONTEXT   
\
 "movq %%rsp,%P[threadrsp](%[prev])\n\t" /* save RSP */ 
  \

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 00/18] 2.6.18-stable review

2007-02-20 Thread Greg KH
This is the start of the stable review cycle for the 2.6.18.8 release.

This will be the last release of the 2.6.18-stable series, so if there
are patches that you feel should be applied to that tree, please let me
know.

There are 18 patches in this series, all will be posted as a response to
this one.  If anyone has any issues with these being applied, please let
us know.  If anyone is a maintainer of the proper subsystem, and wants
to add a Signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the Cc:
line.  If you wish to be a reviewer, please email [EMAIL PROTECTED] to
add your name to the list.  If you want to be off the reviewer list,
also email us.

Responses should be made by Friday February 23 00:00 UTC.  Anything
received after that time might be too late.

The whole patch set can be downloaded at:
kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.18.8-rc1.gz

thanks,

the -stable release team
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 01/18] bcm43xx: Fix for oops on resume

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Larry Finger <[EMAIL PROTECTED]>

There is a kernel oops on bcm43xx when resuming due to an overly tight timeout 
loop.

Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/net/wireless/bcm43xx/bcm43xx.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -21,7 +21,7 @@
 #define PFXKBUILD_MODNAME ": "
 
 #define BCM43xx_SWITCH_CORE_MAX_RETRIES50
-#define BCM43xx_IRQWAIT_MAX_RETRIES50
+#define BCM43xx_IRQWAIT_MAX_RETRIES100
 
 #define BCM43xx_IO_SIZE8192
 

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 07/21] rtc-pcf8563: detect polarity of century bit automatically

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--

From: Atsushi Nemoto <[EMAIL PROTECTED]>

The usage of the century bit was inverted on 2.6.19 following to PCF8563's
description, but it was not match to usage suggested by RTC8564's
datasheet.  Anyway what MO_C=1 means can vary on each platform.  This patch
is to detect its polarity in get_datetime routine.  The default value of
c_polarity is 0 (MO_C=1 means 19xx) so that this patch does not change
current behavior even if get_datetime was not called before set_datetime.

Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
Cc: Jean-Baptiste Maneyrol <[EMAIL PROTECTED]>
Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Alessandro Zummo <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/rtc/rtc-pcf8563.c |   40 ++--
 1 file changed, 34 insertions(+), 6 deletions(-)

--- linux-2.6.19.4.orig/drivers/rtc/rtc-pcf8563.c
+++ linux-2.6.19.4/drivers/rtc/rtc-pcf8563.c
@@ -53,6 +53,25 @@ I2C_CLIENT_INSMOD;
 #define PCF8563_SC_LV  0x80 /* low voltage */
 #define PCF8563_MO_C   0x80 /* century */
 
+struct pcf8563 {
+   struct i2c_client client;
+   /*
+* The meaning of MO_C bit varies by the chip type.
+* From PCF8563 datasheet: this bit is toggled when the years
+* register overflows from 99 to 00
+*   0 indicates the century is 20xx
+*   1 indicates the century is 19xx
+* From RTC8564 datasheet: this bit indicates change of
+* century. When the year digit data overflows from 99 to 00,
+* this bit is set. By presetting it to 0 while still in the
+* 20th century, it will be set in year 2000, ...
+* There seems no reliable way to know how the system use this
+* bit.  So let's do it heuristically, assuming we are live in
+* 1970...2069.
+*/
+   int c_polarity; /* 0: MO_C=1 means 19xx, otherwise MO_C=1 means 20xx */
+};
+
 static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind);
 static int pcf8563_detach(struct i2c_client *client);
 
@@ -62,6 +81,7 @@ static int pcf8563_detach(struct i2c_cli
  */
 static int pcf8563_get_datetime(struct i2c_client *client, struct rtc_time *tm)
 {
+   struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
unsigned char buf[13] = { PCF8563_REG_ST1 };
 
struct i2c_msg msgs[] = {
@@ -94,8 +114,12 @@ static int pcf8563_get_datetime(struct i
tm->tm_mday = BCD2BIN(buf[PCF8563_REG_DM] & 0x3F);
tm->tm_wday = buf[PCF8563_REG_DW] & 0x07;
tm->tm_mon = BCD2BIN(buf[PCF8563_REG_MO] & 0x1F) - 1; /* rtc mn 1-12 */
-   tm->tm_year = BCD2BIN(buf[PCF8563_REG_YR])
-   + (buf[PCF8563_REG_MO] & PCF8563_MO_C ? 0 : 100);
+   tm->tm_year = BCD2BIN(buf[PCF8563_REG_YR]);
+   if (tm->tm_year < 70)
+   tm->tm_year += 100; /* assume we are in 1970...2069 */
+   /* detect the polarity heuristically. see note above. */
+   pcf8563->c_polarity = (buf[PCF8563_REG_MO] & PCF8563_MO_C) ?
+   (tm->tm_year >= 100) : (tm->tm_year < 100);
 
dev_dbg(>dev, "%s: tm is secs=%d, mins=%d, hours=%d, "
"mday=%d, mon=%d, year=%d, wday=%d\n",
@@ -114,6 +138,7 @@ static int pcf8563_get_datetime(struct i
 
 static int pcf8563_set_datetime(struct i2c_client *client, struct rtc_time *tm)
 {
+   struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
int i, err;
unsigned char buf[9];
 
@@ -135,7 +160,7 @@ static int pcf8563_set_datetime(struct i
 
/* year and century */
buf[PCF8563_REG_YR] = BIN2BCD(tm->tm_year % 100);
-   if (tm->tm_year < 100)
+   if (pcf8563->c_polarity ? (tm->tm_year >= 100) : (tm->tm_year < 100))
buf[PCF8563_REG_MO] |= PCF8563_MO_C;
 
buf[PCF8563_REG_DW] = tm->tm_wday & 0x07;
@@ -248,6 +273,7 @@ static struct i2c_driver pcf8563_driver 
 
 static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind)
 {
+   struct pcf8563 *pcf8563;
struct i2c_client *client;
struct rtc_device *rtc;
 
@@ -260,11 +286,12 @@ static int pcf8563_probe(struct i2c_adap
goto exit;
}
 
-   if (!(client = kzalloc(sizeof(struct i2c_client), GFP_KERNEL))) {
+   if (!(pcf8563 = kzalloc(sizeof(struct pcf8563), GFP_KERNEL))) {
err = -ENOMEM;
goto exit;
}
 
+   client = >client;
client->addr = address;
client->driver = _driver;
client->adapter = adapter;
@@ -301,7 +328,7 @@ exit_detach:
i2c_detach_client(client);
 
 exit_kfree:
-   kfree(client);
+   kfree(pcf8563);
 
 exit:
return err;
@@ -309,6 +336,7 @@ exit:
 
 static int pcf8563_detach(struct i2c_client *client)
 {
+   struct pcf8563 *pcf8563 = 

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

2007-02-20 Thread Bartlomiej Zolnierkiewicz

On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:
> It can be changed via /proc/ide/hd?/settings.

Why do we need to change IDE DMA timeout dynamically?

BTW /proc/ide/hd?/settings is obsoleted

> Signed-off-by:Ed Falk <[EMAIL PROTECTED]>
> 
> ---
>  drivers/ide/ide-dma.c |3 ++-
>  drivers/ide/ide.c |2 ++
>  include/linux/ide.h   |3 +++
>  3 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c
> index 08e7cd0..a8da725 100644
> --- a/drivers/ide/ide-dma.c
> +++ b/drivers/ide/ide-dma.c
> @@ -579,7 +579,8 @@ EXPORT_SYMBOL_GPL(ide_dma_setup);
>  static void ide_dma_exec_cmd(ide_drive_t *drive, u8 command)
>  {
>   /* issue cmd to drive */
> - ide_execute_command(drive, command, _dma_intr, 2*WAIT_CMD, 
> dma_timer_expiry);
> + ide_execute_command(drive, command, _dma_intr, drive->dma_timeout,
> + dma_timer_expiry);
>  }
>  
>  void ide_dma_start(ide_drive_t *drive)
> diff --git a/drivers/ide/ide.c b/drivers/ide/ide.c
> index b3c0818..ca841f2 100644
> --- a/drivers/ide/ide.c
> +++ b/drivers/ide/ide.c
> @@ -245,6 +245,7 @@ static void init_hwif_data(ide_hwif_t *h
>   drive->name[1]  = 'd';
>   drive->name[2]  = 'a' + (index * MAX_DRIVES) + 
> unit;
>   drive->max_failures = IDE_DEFAULT_MAX_FAILURES;
> + drive->dma_timeout  = WAIT_DMA;
>   drive->using_dma= 0;
>   drive->vdma = 0;
>   INIT_LIST_HEAD(>list);
> @@ -1197,6 +1198,7 @@ void ide_add_generic_settings (ide_drive
>   __ide_add_setting(drive,"init_speed",   SETTING_RW, 
> -1, -1,   
>   TYPE_BYTE,  0,  70, 1,  1,  
> >init_speed, NULL,   0);
>   __ide_add_setting(drive,"current_speed",SETTING_RW, 
> -1, -1,   
>   TYPE_BYTE,  0,  70, 1,  1,  
> >current_speed,  set_xfer_rate,  0);
>   __ide_add_setting(drive,"number",   SETTING_RW, 
> -1, -1,   
>   TYPE_BYTE,  0,  3,  1,  1,  
> >dn, NULL,   0);
> + __ide_add_setting(drive,"dma_timeout",  SETTING_RW, 
> -1, -1,   
>   TYPE_INT,   0,  20, 1,  1,  
> >dma_timeout,NULL,   0);
>  }
>  
>  /**
> diff --git a/include/linux/ide.h b/include/linux/ide.h
> index 79c0282..3861753 100644
> --- a/include/linux/ide.h
> +++ b/include/linux/ide.h
> @@ -183,6 +183,7 @@ #define WAIT_READY(5*HZ)  /* 5sec - som
>  #define WAIT_PIDENTIFY   (10*HZ) /* 10sec  - should be less than 3ms 
> (?), if all ATAPI CD is closed at boot */
>  #define WAIT_WORSTCASE   (30*HZ) /* 30sec  - worst case when spinning up 
> */
>  #define WAIT_CMD (10*HZ) /* 10sec  - maximum wait for an IRQ to happen */
> +#define WAIT_DMA (20*HZ) /* 20sec  - maximum wait for an IRQ to happen */
>  #define WAIT_MIN_SLEEP   (2*HZ/100)  /* 20msec - minimum sleep time 
> */
>  
>  /*
> @@ -638,6 +639,8 @@ typedef struct ide_drive_s {
>   unsigned intdrive_data; /* use by tuneproc/selectproc */
>   unsigned intfailures;   /* current failure count */
>   unsigned intmax_failures;   /* maximum allowed failure count */
> + int dma_timeout;/* number of jiffies to wait for a
> +   dma to complete */
>   u64 probed_capacity;/* initial reported media capacity 
> (ide-cd only currently) */
>  
>   u64 capacity64; /* total number of sectors */
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [MTD] CHIPS: oops in cfi_amdstd_sync

2007-02-20 Thread Vijay Sampath

From: Vijay Sampath <[EMAIL PROTECTED]>

The files cfi_cmdset_0002.c and cfi_cmdset_0020.c do not initialize
their wait queues like is done in cfi_cmdset_0001.c. This causes an
oops when the wait queue is accessed. I have copied the code from
cfi_cmdset_0001.c that is pertinent to initialization of the wait
queue.

Signed-off-by: Vijay Sampath <[EMAIL PROTECTED]>
---

diff -uprN -X linux-2.6.20.1-vanilla/Documentation/dontdiff
linux-2.6.20.1-vanilla/drivers/mtd/chips/cfi_cmdset_0002.c
linux-2.6/drivers/mtd/chips/cfi_cmdset_0002.c
--- linux-2.6.20.1-vanilla/drivers/mtd/chips/cfi_cmdset_0002.c  2007-02-20
17:01:57.0 -0800
+++ linux-2.6/drivers/mtd/chips/cfi_cmdset_0002.c   2007-02-20
17:05:23.0 -0800
@@ -359,6 +359,8 @@ struct mtd_info *cfi_cmdset_0002(struct
cfi->chips[i].word_write_time = 
1WordWriteTimeoutTyp;
cfi->chips[i].buffer_write_time = 
1BufWriteTimeoutTyp;
cfi->chips[i].erase_time = 1BlockEraseTimeoutTyp;
+   cfi->chips[i].ref_point_counter = 0;
+   init_waitqueue_head(&(cfi->chips[i].wq));
}

map->fldrv = _amdstd_chipdrv;
diff -uprN -X linux-2.6.20.1-vanilla/Documentation/dontdiff
linux-2.6.20.1-vanilla/drivers/mtd/chips/cfi_cmdset_0020.c
linux-2.6/drivers/mtd/chips/cfi_cmdset_0020.c
--- linux-2.6.20.1-vanilla/drivers/mtd/chips/cfi_cmdset_0020.c  2007-02-20
17:01:57.0 -0800
+++ linux-2.6/drivers/mtd/chips/cfi_cmdset_0020.c   2007-02-20
17:06:14.0 -0800
@@ -158,6 +158,8 @@ struct mtd_info *cfi_cmdset_0020(struct
cfi->chips[i].word_write_time = 128;
cfi->chips[i].buffer_write_time = 128;
cfi->chips[i].erase_time = 1024;
+   cfi->chips[i].ref_point_counter = 0;
+   init_waitqueue_head(&(cfi->chips[i].wq));
}

return cfi_staa_setup(map);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 12/21] bcm43xx: Fix for oops on resume

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--

There is a kernel oops on bcm43xx when resuming due to an overly tight timeout 
loop.

Signed-off-by: Larry Finger<[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/net/wireless/bcm43xx/bcm43xx.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.19.4.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ linux-2.6.19.4/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -21,7 +21,7 @@
 #define PFXKBUILD_MODNAME ": "
 
 #define BCM43xx_SWITCH_CORE_MAX_RETRIES50
-#define BCM43xx_IRQWAIT_MAX_RETRIES50
+#define BCM43xx_IRQWAIT_MAX_RETRIES100
 
 #define BCM43xx_IO_SIZE8192
 

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 13/21] bcm43xx: Fix for oops on ampdu status

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--

From: Michael Buesch <[EMAIL PROTECTED]>

If bcm43xx were to process an afterburner (ampdu) status response, Linux would 
oops. The
ampdu and intermediate status bits are properly named.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/net/wireless/bcm43xx/bcm43xx_main.c |8 +++-
 drivers/net/wireless/bcm43xx/bcm43xx_xmit.h |   10 ++
 2 files changed, 5 insertions(+), 13 deletions(-)

--- linux-2.6.19.4.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6.19.4/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1449,12 +1449,10 @@ static void handle_irq_transmit_status(s
 
bcm43xx_debugfs_log_txstat(bcm, );
 
-   if (stat.flags & BCM43xx_TXSTAT_FLAG_IGNORE)
+   if (stat.flags & BCM43xx_TXSTAT_FLAG_AMPDU)
+   continue;
+   if (stat.flags & BCM43xx_TXSTAT_FLAG_INTER)
continue;
-   if (!(stat.flags & BCM43xx_TXSTAT_FLAG_ACK)) {
-   //TODO: packet was not acked (was lost)
-   }
-   //TODO: There are more (unknown) flags to test. see 
bcm43xx_main.h
 
if (bcm43xx_using_pio(bcm))
bcm43xx_pio_handle_xmitstatus(bcm, );
--- linux-2.6.19.4.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.h
+++ linux-2.6.19.4/drivers/net/wireless/bcm43xx/bcm43xx_xmit.h
@@ -137,14 +137,8 @@ struct bcm43xx_xmitstatus {
u16 unknown; //FIXME
 };
 
-#define BCM43xx_TXSTAT_FLAG_ACK0x01
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x02
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x04
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x08
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x10
-#define BCM43xx_TXSTAT_FLAG_IGNORE 0x20
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x40
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x80
+#define BCM43xx_TXSTAT_FLAG_AMPDU  0x10
+#define BCM43xx_TXSTAT_FLAG_INTER  0x20
 
 u8 bcm43xx_plcp_get_ratecode_cck(const u8 bitrate);
 u8 bcm43xx_plcp_get_ratecode_ofdm(const u8 bitrate);

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 11/21] pata_amd: fix an obvious bug in cable detection

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--

80c test mask is at bits 18 and 19 of EIDE Controller Configuration
not 22 and 23.  Fix it.

Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>

---
 drivers/ata/pata_amd.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.19.4.orig/drivers/ata/pata_amd.c
+++ linux-2.6.19.4/drivers/ata/pata_amd.c
@@ -128,7 +128,7 @@ static void timing_setup(struct ata_port
 
 static int amd_pre_reset(struct ata_port *ap)
 {
-   static const u32 bitmask[2] = {0x03, 0xC0};
+   static const u32 bitmask[2] = {0x03, 0x0C};
static const struct pci_bits amd_enable_bits[] = {
{ 0x40, 1, 0x02, 0x02 },
{ 0x40, 1, 0x01, 0x01 }
@@ -247,7 +247,7 @@ static void amd133_set_dmamode(struct at
  */
 
 static int nv_pre_reset(struct ata_port *ap) {
-   static const u8 bitmask[2] = {0x03, 0xC0};
+   static const u8 bitmask[2] = {0x03, 0x0C};
static const struct pci_bits nv_enable_bits[] = {
{ 0x50, 1, 0x02, 0x02 },
{ 0x50, 1, 0x01, 0x01 }

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 09/21] x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--

Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and
forced by binary compatibility. UML/32bit breaks because of this - since it is 
wise
enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host
kernels.

Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had:

   default:
return sys_ptrace(request, pid, addr, data);

Instead here we have:
case PTRACE_GET_THREAD_AREA:
case ...:
return sys_ptrace(request, pid, addr, data);

default:
return -EINVAL;

This change was a style change - when a case is added, it must be explicitly
tested this way. In this case, not enough testing was done.

Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 arch/x86_64/ia32/ptrace32.c |1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.19.4.orig/arch/x86_64/ia32/ptrace32.c
+++ linux-2.6.19.4/arch/x86_64/ia32/ptrace32.c
@@ -243,6 +243,7 @@ asmlinkage long sys32_ptrace(long reques
case PTRACE_SINGLESTEP:
case PTRACE_DETACH:
case PTRACE_SYSCALL:
+   case PTRACE_OLDSETOPTIONS:
case PTRACE_SETOPTIONS:
case PTRACE_SET_THREAD_AREA:
case PTRACE_GET_THREAD_AREA:

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Don't change transfer speed while requests are in flight

2007-02-20 Thread Suleiman Souhlal
Use ide_wait_cmd() in ide_config_drive_speed() if the drive has been
initialized and we're not in an interrupt, to avoid changing the
xfer speed while requests are in flight.

An easy way to trigger the problem is to dd the disk while doing
while :; do hdparm -d 1 /dev/hdc> /dev/null; done

While there, remove some commented-out code.

Signed-off-by:  Suleiman Souhlal <[EMAIL PROTECTED]>

---
 drivers/ide/ide-iops.c |   35 ---
 1 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
index c67b3b1..35ab3af 100644
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -748,32 +748,36 @@ int ide_config_drive_speed (ide_drive_t 
int i, error= 1;
u8 stat;
 
-// while (HWGROUP(drive)->busy)
-// msleep(50);
+   /*
+* Just use ide_wait_cmd() if the drive has been initialized and we
+* aren't in an interrupt handler, to avoid changing the xfer speed
+* while requests are in flight.
+*
+* If we are in an interrupt, it should be safe to issue
+* SETFEATURES manually, since there shouldn't be any requests in
+* flight.
+*/
+   if (drive->queue != NULL && !in_interrupt()) {
+   error = ide_wait_cmd(drive, WIN_SETFEATURES, speed,
+   SETFEATURES_XFER, 0, NULL);
+   if (error) {
+   stat = hwif->INB(IDE_STATUS_REG);
+   ide_dump_status(drive, "set_drive_speed_status", stat);
+   return (error);
+   }
+   goto done;
+   }
 
 #ifdef CONFIG_BLK_DEV_IDEDMA
if (hwif->ide_dma_check) /* check if host supports DMA */
hwif->dma_host_off(drive);
 #endif
 
-   /*
-* Don't use ide_wait_cmd here - it will
-* attempt to set_geometry and recalibrate,
-* but for some reason these don't work at
-* this point (lost interrupt).
-*/
 /*
  * Select the drive, and issue the SETFEATURES command
  */
disable_irq_nosync(hwif->irq);

-   /*
-*  FIXME: we race against the running IRQ here if
-*  this is called from non IRQ context. If we use
-*  disable_irq() we hang on the error path. Work
-*  is needed.
-*/
-
udelay(1);
SELECT_DRIVE(drive);
SELECT_MASK(drive, 0);
@@ -835,6 +839,7 @@ #ifdef CONFIG_BLK_DEV_IDEDMA
hwif->dma_off_quietly(drive);
 #endif
 
+done:
switch(speed) {
case XFER_UDMA_7:   drive->id->dma_ultra |= 0x8080; break;
case XFER_UDMA_6:   drive->id->dma_ultra |= 0x4040; break;

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


[patch 17/21] Use different constraint for gcc < 4.1 in bitops.

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--

Use different constraint for gcc < 4.1 in bitops.h

+m is really correct for a RMW instruction, but some older gccs
error out. I finally gave in and ifdefed it.

This fixes compilation errors with some compiler version.

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 include/asm-x86_64/bitops.h |   34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

--- linux-2.6.19.4.orig/include/asm-x86_64/bitops.h
+++ linux-2.6.19.4/include/asm-x86_64/bitops.h
@@ -7,7 +7,13 @@
 
 #include 
 
-#define ADDR (*(volatile long *) addr)
+#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 1)
+/* Technically wrong, but this avoids compilation errors on some gcc
+   versions. */
+#define ADDR "=m" (*(volatile long *) addr)
+#else
+#define ADDR "+m" (*(volatile long *) addr)
+#endif
 
 /**
  * set_bit - Atomically set a bit in memory
@@ -23,7 +29,7 @@ static __inline__ void set_bit(int nr, v
 {
__asm__ __volatile__( LOCK_PREFIX
"btsl %1,%0"
-   :"+m" (ADDR)
+   :ADDR
:"dIr" (nr) : "memory");
 }
 
@@ -40,7 +46,7 @@ static __inline__ void __set_bit(int nr,
 {
__asm__ volatile(
"btsl %1,%0"
-   :"+m" (ADDR)
+   :ADDR
:"dIr" (nr) : "memory");
 }
 
@@ -58,7 +64,7 @@ static __inline__ void clear_bit(int nr,
 {
__asm__ __volatile__( LOCK_PREFIX
"btrl %1,%0"
-   :"+m" (ADDR)
+   :ADDR
:"dIr" (nr));
 }
 
@@ -66,7 +72,7 @@ static __inline__ void __clear_bit(int n
 {
__asm__ __volatile__(
"btrl %1,%0"
-   :"+m" (ADDR)
+   :ADDR
:"dIr" (nr));
 }
 
@@ -86,7 +92,7 @@ static __inline__ void __change_bit(int 
 {
__asm__ __volatile__(
"btcl %1,%0"
-   :"+m" (ADDR)
+   :ADDR
:"dIr" (nr));
 }
 
@@ -103,7 +109,7 @@ static __inline__ void change_bit(int nr
 {
__asm__ __volatile__( LOCK_PREFIX
"btcl %1,%0"
-   :"+m" (ADDR)
+   :ADDR
:"dIr" (nr));
 }
 
@@ -121,7 +127,7 @@ static __inline__ int test_and_set_bit(i
 
__asm__ __volatile__( LOCK_PREFIX
"btsl %2,%1\n\tsbbl %0,%0"
-   :"=r" (oldbit),"+m" (ADDR)
+   :"=r" (oldbit),ADDR
:"dIr" (nr) : "memory");
return oldbit;
 }
@@ -141,7 +147,7 @@ static __inline__ int __test_and_set_bit
 
__asm__(
"btsl %2,%1\n\tsbbl %0,%0"
-   :"=r" (oldbit),"+m" (ADDR)
+   :"=r" (oldbit),ADDR
:"dIr" (nr));
return oldbit;
 }
@@ -160,7 +166,7 @@ static __inline__ int test_and_clear_bit
 
__asm__ __volatile__( LOCK_PREFIX
"btrl %2,%1\n\tsbbl %0,%0"
-   :"=r" (oldbit),"+m" (ADDR)
+   :"=r" (oldbit),ADDR
:"dIr" (nr) : "memory");
return oldbit;
 }
@@ -180,7 +186,7 @@ static __inline__ int __test_and_clear_b
 
__asm__(
"btrl %2,%1\n\tsbbl %0,%0"
-   :"=r" (oldbit),"+m" (ADDR)
+   :"=r" (oldbit),ADDR
:"dIr" (nr));
return oldbit;
 }
@@ -192,7 +198,7 @@ static __inline__ int __test_and_change_
 
__asm__ __volatile__(
"btcl %2,%1\n\tsbbl %0,%0"
-   :"=r" (oldbit),"+m" (ADDR)
+   :"=r" (oldbit),ADDR
:"dIr" (nr) : "memory");
return oldbit;
 }
@@ -211,7 +217,7 @@ static __inline__ int test_and_change_bi
 
__asm__ __volatile__( LOCK_PREFIX
"btcl %2,%1\n\tsbbl %0,%0"
-   :"=r" (oldbit),"+m" (ADDR)
+   :"=r" (oldbit),ADDR
:"dIr" (nr) : "memory");
return oldbit;
 }
@@ -237,7 +243,7 @@ static __inline__ int variable_test_bit(
__asm__ __volatile__(
"btl %2,%1\n\tsbbl %0,%0"
:"=r" (oldbit)
-   :"m" (ADDR),"dIr" (nr));
+   :"m" (*(volatile long *)addr),"dIr" (nr));
return oldbit;
 }
 

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Use correct IDE error recovery

2007-02-20 Thread Suleiman Souhlal
IDE error recovery is using WIN_IDLEIMMEDIATE which was only valid for
IDE V1 and IDE V2.  Modern drives will not be able to recover using
this error handling.  The correct thing to do is issue a SRST followed
by a SET_FEATURES.

Signed-off-by:  Suleiman Souhlal <[EMAIL PROTECTED]>

---
 drivers/ide/ide-io.c   |   35 +++-
 drivers/ide/ide-iops.c |  105 
 include/linux/ide.h|2 +
 3 files changed, 88 insertions(+), 54 deletions(-)

diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
index c193553..2f05b4d 100644
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -519,21 +519,21 @@ static ide_startstop_t ide_ata_error(ide
if ((stat & DRQ_STAT) && rq_data_dir(rq) == READ && 
hwif->err_stops_fifo == 0)
try_to_flush_leftover_data(drive);
 
+   if (rq->errors >= ERROR_MAX || blk_noretry_request(rq)) {
+   ide_kill_rq(drive, rq);
+   return ide_stopped;
+   }
+
if (hwif->INB(IDE_STATUS_REG) & (BUSY_STAT|DRQ_STAT))
-   /* force an abort */
-   hwif->OUTB(WIN_IDLEIMMEDIATE, IDE_COMMAND_REG);
+   rq->errors |= ERROR_RESET;
 
-   if (rq->errors >= ERROR_MAX || blk_noretry_request(rq))
-   ide_kill_rq(drive, rq);
-   else {
-   if ((rq->errors & ERROR_RESET) == ERROR_RESET) {
-   ++rq->errors;
-   return ide_do_reset(drive);
-   }
-   if ((rq->errors & ERROR_RECAL) == ERROR_RECAL)
-   drive->special.b.recalibrate = 1;
+   if ((rq->errors & ERROR_RESET) == ERROR_RESET) {
++rq->errors;
+   return ide_do_reset(drive);
}
+
+   ++rq->errors;
+
return ide_stopped;
 }
 
@@ -586,6 +586,13 @@ EXPORT_SYMBOL_GPL(__ide_error);
  * both new-style (taskfile) and old style command handling here.
  * In the case of taskfile command handling there is work left to
  * do
+ * This used to send a idle immediate to the drive if the drive was
+ * busy or had drq set.  This violates the ATA spec (can only send IDLE
+ * immediate when drive is not busy) and really hoses up some drives.
+ * We've changed it to just do a SRST followed by a set features (set
+ * udma mode) it those cases.  This is what Western Digital recommends
+ * for error recovery and what Western Digital says Windows does.  It
+ * also does not violate the ATA spec as far as I can tell.
  */
  
 ide_startstop_t ide_error (ide_drive_t *drive, const char *msg, u8 stat)
@@ -1004,6 +1011,12 @@ #endif
goto kill_rq;
}
 
+   /* We reset the drive so we need to issue a SETFEATURES. */
+   if ((drive->current_speed == 0xff) &&
+   ((rq->cmd_type == REQ_TYPE_ATA_CMD) ||
+   (rq->cmd_type == REQ_TYPE_ATA_TASK)))
+   ide_config_drive_speed_irq(drive, drive->desired_speed);
+
block= rq->sector;
if (blk_fs_request(rq) &&
(drive->media == ide_disk || drive->media == ide_floppy)) {
diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
index 35ab3af..e0573cb 100644
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -731,6 +731,30 @@ #else
 #endif
 }
 
+static void ide_drive_speed_changed(ide_drive_t *drive, u8 speed)
+{
+   switch(speed) {
+   case XFER_UDMA_7:   drive->id->dma_ultra |= 0x8080; break;
+   case XFER_UDMA_6:   drive->id->dma_ultra |= 0x4040; break;
+   case XFER_UDMA_5:   drive->id->dma_ultra |= 0x2020; break;
+   case XFER_UDMA_4:   drive->id->dma_ultra |= 0x1010; break;
+   case XFER_UDMA_3:   drive->id->dma_ultra |= 0x0808; break;
+   case XFER_UDMA_2:   drive->id->dma_ultra |= 0x0404; break;
+   case XFER_UDMA_1:   drive->id->dma_ultra |= 0x0202; break;
+   case XFER_UDMA_0:   drive->id->dma_ultra |= 0x0101; break;
+   case XFER_MW_DMA_2: drive->id->dma_mword |= 0x0404; break;
+   case XFER_MW_DMA_1: drive->id->dma_mword |= 0x0202; break;
+   case XFER_MW_DMA_0: drive->id->dma_mword |= 0x0101; break;
+   case XFER_SW_DMA_2: drive->id->dma_1word |= 0x0404; break;
+   case XFER_SW_DMA_1: drive->id->dma_1word |= 0x0202; break;
+   case XFER_SW_DMA_0: drive->id->dma_1word |= 0x0101; break;
+   default: break;
+   }
+   if (!drive->init_speed)
+   drive->init_speed = speed;
+   drive->current_speed = speed;
+}
+
 /*
  * Similar to ide_wait_stat(), except it never calls ide_error internally.
  * This is a kludge to handle the new ide_config_drive_speed() function,
@@ -742,32 +766,12 @@ #endif
  *
  * const char *msg == consider adding for verbose errors.
  */
-int ide_config_drive_speed (ide_drive_t *drive, u8 speed)
+int ide_config_drive_speed_irq(ide_drive_t *drive, u8 speed)
 {
  

[PATCH 1/3] Make the IDE DMA timeout modifiable

2007-02-20 Thread Suleiman Souhlal
It can be changed via /proc/ide/hd?/settings.

Signed-off-by:  Ed Falk <[EMAIL PROTECTED]>

---
 drivers/ide/ide-dma.c |3 ++-
 drivers/ide/ide.c |2 ++
 include/linux/ide.h   |3 +++
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c
index 08e7cd0..a8da725 100644
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -579,7 +579,8 @@ EXPORT_SYMBOL_GPL(ide_dma_setup);
 static void ide_dma_exec_cmd(ide_drive_t *drive, u8 command)
 {
/* issue cmd to drive */
-   ide_execute_command(drive, command, _dma_intr, 2*WAIT_CMD, 
dma_timer_expiry);
+   ide_execute_command(drive, command, _dma_intr, drive->dma_timeout,
+   dma_timer_expiry);
 }
 
 void ide_dma_start(ide_drive_t *drive)
diff --git a/drivers/ide/ide.c b/drivers/ide/ide.c
index b3c0818..ca841f2 100644
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -245,6 +245,7 @@ static void init_hwif_data(ide_hwif_t *h
drive->name[1]  = 'd';
drive->name[2]  = 'a' + (index * MAX_DRIVES) + 
unit;
drive->max_failures = IDE_DEFAULT_MAX_FAILURES;
+   drive->dma_timeout  = WAIT_DMA;
drive->using_dma= 0;
drive->vdma = 0;
INIT_LIST_HEAD(>list);
@@ -1197,6 +1198,7 @@ void ide_add_generic_settings (ide_drive
__ide_add_setting(drive,"init_speed",   SETTING_RW, 
-1, -1, 
TYPE_BYTE,  0,  70, 1,  1,  
>init_speed, NULL,   0);
__ide_add_setting(drive,"current_speed",SETTING_RW, 
-1, -1, 
TYPE_BYTE,  0,  70, 1,  1,  
>current_speed,  set_xfer_rate,  0);
__ide_add_setting(drive,"number",   SETTING_RW, 
-1, -1, 
TYPE_BYTE,  0,  3,  1,  1,  
>dn, NULL,   0);
+   __ide_add_setting(drive,"dma_timeout",  SETTING_RW, 
-1, -1, 
TYPE_INT,   0,  20, 1,  1,  
>dma_timeout,NULL,   0);
 }
 
 /**
diff --git a/include/linux/ide.h b/include/linux/ide.h
index 79c0282..3861753 100644
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -183,6 +183,7 @@ #define WAIT_READY  (5*HZ)  /* 5sec - som
 #define WAIT_PIDENTIFY (10*HZ) /* 10sec  - should be less than 3ms (?), if all 
ATAPI CD is closed at boot */
 #define WAIT_WORSTCASE (30*HZ) /* 30sec  - worst case when spinning up */
 #define WAIT_CMD   (10*HZ) /* 10sec  - maximum wait for an IRQ to happen */
+#define WAIT_DMA   (20*HZ) /* 20sec  - maximum wait for an IRQ to happen */
 #define WAIT_MIN_SLEEP (2*HZ/100)  /* 20msec - minimum sleep time */
 
 /*
@@ -638,6 +639,8 @@ typedef struct ide_drive_s {
unsigned intdrive_data; /* use by tuneproc/selectproc */
unsigned intfailures;   /* current failure count */
unsigned intmax_failures;   /* maximum allowed failure count */
+   int dma_timeout;/* number of jiffies to wait for a
+ dma to complete */
u64 probed_capacity;/* initial reported media capacity 
(ide-cd only currently) */
 
u64 capacity64; /* total number of sectors */

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 18/21] prism54: correct assignment of DOT1XENABLE in WE-19 codepaths

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--

Correct assignment of DOT1XENABLE in WE-19 codepaths.
RX_UNENCRYPTED_EAPOL = 1 really means setting DOT1XENABLE _off_, and
vice versa.  The original WE-19 patch erroneously reversed that.  This
patch fixes association with unencrypted and WEP networks when using
wpa_supplicant.

It also adds two missing break statements that, left out, could result
in incorrect card configuration.

Applies to (I think) 2.6.19 and later.

Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/net/wireless/prism54/isl_ioctl.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- linux-2.6.19.4.orig/drivers/net/wireless/prism54/isl_ioctl.c
+++ linux-2.6.19.4/drivers/net/wireless/prism54/isl_ioctl.c
@@ -1395,11 +1395,16 @@ static int prism54_set_auth(struct net_d
break;
 
case IW_AUTH_RX_UNENCRYPTED_EAPOL:
-   dot1x = param->value ? 1 : 0;
+   /* dot1x should be the opposite of RX_UNENCRYPTED_EAPOL;
+* turn off dot1x when  allowing recepit of unencrypted eapol
+* frames, turn on dot1x when we disallow receipt
+*/
+   dot1x = param->value ? 0x00 : 0x01;
break;
 
case IW_AUTH_PRIVACY_INVOKED:
privinvoked = param->value ? 1 : 0;
+   break;
 
case IW_AUTH_DROP_UNENCRYPTED:
exunencrypt = param->value ? 1 : 0;
@@ -1589,6 +1594,7 @@ static int prism54_set_encodeext(struct 
}
key.type = DOT11_PRIV_TKIP;
key.length = KEY_SIZE_TKIP;
+   break;
default:
return -EINVAL;
}

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 16/21] usbaudio - Fix Oops with unconventional sample rates

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--


[PATCH] usbaudio - Fix Oops with unconventional sample rates

The patch fixes the memory corruption by the support of unconventional
sample rates.  Also, it avoids the too restrictive constraints if
any of usb descriptions contain continuous rates.

Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 sound/usb/usbaudio.c |   43 +--
 1 file changed, 25 insertions(+), 18 deletions(-)

--- linux-2.6.19.4.orig/sound/usb/usbaudio.c
+++ linux-2.6.19.4/sound/usb/usbaudio.c
@@ -186,6 +186,7 @@ struct snd_usb_substream {
u64 formats;/* format bitmasks (all or'ed) */
unsigned int num_formats;   /* number of supported audio 
formats (list) */
struct list_head fmt_list;  /* format list */
+   struct snd_pcm_hw_constraint_list rate_list;/* limited rates */
spinlock_t lock;
 
struct snd_urb_ops ops; /* callbacks (must be filled at init) */
@@ -1810,28 +1811,33 @@ static int check_hw_params_convention(st
 static int snd_usb_pcm_check_knot(struct snd_pcm_runtime *runtime,
  struct snd_usb_substream *subs)
 {
-   struct list_head *p;
-   struct snd_pcm_hw_constraint_list constraints_rates;
+   struct audioformat *fp;
+   int count = 0, needs_knot = 0;
int err;
 
-   list_for_each(p, >fmt_list) {
-   struct audioformat *fp;
-   fp = list_entry(p, struct audioformat, list);
-
-   if (!fp->needs_knot)
-   continue;
-
-   constraints_rates.count = fp->nr_rates;
-   constraints_rates.list = fp->rate_table;
-   constraints_rates.mask = 0;
-
-   err = snd_pcm_hw_constraint_list(runtime, 0,
-   SNDRV_PCM_HW_PARAM_RATE,
-   _rates);
+   list_for_each_entry(fp, >fmt_list, list) {
+   if (fp->rates & SNDRV_PCM_RATE_CONTINUOUS)
+   return 0;
+   count += fp->nr_rates;
+   if (fp->needs_knot)
+   needs_knot = 1;
+   }
+   if (!needs_knot)
+   return 0;
 
-   if (err < 0)
-   return err;
+   subs->rate_list.count = count;
+   subs->rate_list.list = kmalloc(sizeof(int) * count, GFP_KERNEL);
+   subs->rate_list.mask = 0;
+   count = 0;
+   list_for_each_entry(fp, >fmt_list, list) {
+   int i;
+   for (i = 0; i < fp->nr_rates; i++)
+   subs->rate_list.list[count++] = fp->rate_table[i];
}
+   err = snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
+>rate_list);
+   if (err < 0)
+   return err;
 
return 0;
 }
@@ -2231,6 +2237,7 @@ static void free_substream(struct snd_us
kfree(fp->rate_table);
kfree(fp);
}
+   kfree(subs->rate_list.list);
 }
 
 

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 21/21] knfsd: Fix a race in closing NFSd connections.

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
If you lose this race, it can iput a socket inode twice and you
get a BUG in fs/inode.c

When I added the option for user-space to close a socket,
I added some cruft to svc_delete_socket so that I could call
that function when closing a socket per user-space request.

This was the wrong thing to do.  I should have just set SK_CLOSE
and let normal mechanisms do the work.

Not only wrong, but buggy.  The locking is all wrong and it openned
up a race where-by a socket could be closed twice.

So this patch:
  Introduces svc_close_socket which sets SK_CLOSE then either leave
  the close up to a thread, or calls svc_delete_socket if it can
  get SK_BUSY.

  Adds a bias to sk_busy which is removed when SK_DEAD is set,
  This avoid races around shutting down the socket.

  Changes several 'spin_lock' to 'spin_lock_bh' where the _bh 
  was missing.

Bugzilla-url: http://bugzilla.kernel.org/show_bug.cgi?id=7916

Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


---
 include/linux/sunrpc/svcsock.h |2 -
 net/sunrpc/svc.c   |4 +--
 net/sunrpc/svcsock.c   |   52 +
 3 files changed, 41 insertions(+), 17 deletions(-)

--- linux-2.6.19.4.orig/include/linux/sunrpc/svcsock.h
+++ linux-2.6.19.4/include/linux/sunrpc/svcsock.h
@@ -63,7 +63,7 @@ struct svc_sock {
  * Function prototypes.
  */
 intsvc_makesock(struct svc_serv *, int, unsigned short);
-void   svc_delete_socket(struct svc_sock *);
+void   svc_close_socket(struct svc_sock *);
 intsvc_recv(struct svc_rqst *, long);
 intsvc_send(struct svc_rqst *);
 void   svc_drop(struct svc_rqst *);
--- linux-2.6.19.4.orig/net/sunrpc/svc.c
+++ linux-2.6.19.4/net/sunrpc/svc.c
@@ -387,7 +387,7 @@ svc_destroy(struct svc_serv *serv)
svsk = list_entry(serv->sv_tempsocks.next,
  struct svc_sock,
  sk_list);
-   svc_delete_socket(svsk);
+   svc_close_socket(svsk);
}
if (serv->sv_shutdown)
serv->sv_shutdown(serv);
@@ -396,7 +396,7 @@ svc_destroy(struct svc_serv *serv)
svsk = list_entry(serv->sv_permsocks.next,
  struct svc_sock,
  sk_list);
-   svc_delete_socket(svsk);
+   svc_close_socket(svsk);
}

cache_clean_deferred(serv);
--- linux-2.6.19.4.orig/net/sunrpc/svcsock.c
+++ linux-2.6.19.4/net/sunrpc/svcsock.c
@@ -61,6 +61,12 @@
  * after a clear, the socket must be read/accepted
  *  if this succeeds, it must be set again.
  * SK_CLOSE can set at any time. It is never cleared.
+ *  sk_inuse contains a bias of '1' until SK_DEAD is set.
+ * so when sk_inuse hits zero, we know the socket is dead
+ * and no-one is using it.
+ *  SK_DEAD can only be set while SK_BUSY is held which ensures
+ * no other thread will be using the socket or will try to
+ *set SK_DEAD.
  *
  */
 
@@ -69,6 +75,7 @@
 
 static struct svc_sock *svc_setup_socket(struct svc_serv *, struct socket *,
 int *errp, int pmap_reg);
+static voidsvc_delete_socket(struct svc_sock *svsk);
 static voidsvc_udp_data_ready(struct sock *, int);
 static int svc_udp_recvfrom(struct svc_rqst *);
 static int svc_udp_sendto(struct svc_rqst *);
@@ -299,8 +306,9 @@ void svc_reserve(struct svc_rqst *rqstp,
 static inline void
 svc_sock_put(struct svc_sock *svsk)
 {
-   if (atomic_dec_and_test(>sk_inuse) &&
-   test_bit(SK_DEAD, >sk_flags)) {
+   if (atomic_dec_and_test(>sk_inuse)) {
+   BUG_ON(! test_bit(SK_DEAD, >sk_flags));
+
dprintk("svc: releasing dead socket\n");
if (svsk->sk_sock->file)
sockfd_put(svsk->sk_sock);
@@ -490,7 +498,7 @@ svc_sock_names(char *buf, struct svc_ser
 
if (!serv)
return 0;
-   spin_lock(>sv_lock);
+   spin_lock_bh(>sv_lock);
list_for_each_entry(svsk, >sv_permsocks, sk_list) {
int onelen = one_sock_name(buf+len, svsk);
if (toclose && strcmp(toclose, buf+len) == 0)
@@ -498,12 +506,12 @@ svc_sock_names(char *buf, struct svc_ser
else
len += onelen;
}
-   spin_unlock(>sv_lock);
+   spin_unlock_bh(>sv_lock);
if (closesk)
/* Should unregister with portmap, but you cannot
 * unregister just one protocol...
 */
-   svc_delete_socket(closesk);
+   svc_close_socket(closesk);
else if (toclose)
return -ENOENT;
   

[patch 20/21] Keys: Fix key serial number collision handling

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: David Howells <[EMAIL PROTECTED]>

[PATCH] Keys: Fix key serial number collision handling

Fix the key serial number collision avoidance code in key_alloc_serial().

This didn't use to be so much of a problem as the key serial numbers were
allocated from a simple incremental counter, and it would have to go through
two billion keys before it could possibly encounter a collision.  However, now
that random numbers are used instead, collisions are much more likely.

This is fixed by finding a hole in the rbtree where the next unused serial
number ought to be and using that by going almost back to the top of the
insertion routine and redoing the insertion with the new serial number rather
than trying to be clever and attempting to work out the insertion point
pointer directly.

This fixes kernel BZ #7727.

Signed-off-by: David Howells <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 security/keys/key.c |   33 ++---
 1 file changed, 14 insertions(+), 19 deletions(-)

--- linux-2.6.19.4.orig/security/keys/key.c
+++ linux-2.6.19.4/security/keys/key.c
@@ -188,6 +188,7 @@ static inline void key_alloc_serial(stru
 
spin_lock(_serial_lock);
 
+attempt_insertion:
parent = NULL;
p = _serial_tree.rb_node;
 
@@ -202,39 +203,33 @@ static inline void key_alloc_serial(stru
else
goto serial_exists;
}
-   goto insert_here;
+
+   /* we've found a suitable hole - arrange for this key to occupy it */
+   rb_link_node(>serial_node, parent, p);
+   rb_insert_color(>serial_node, _serial_tree);
+
+   spin_unlock(_serial_lock);
+   return;
 
/* we found a key with the proposed serial number - walk the tree from
 * that point looking for the next unused serial number */
 serial_exists:
for (;;) {
key->serial++;
-   if (key->serial < 2)
-   key->serial = 2;
-
-   if (!rb_parent(parent))
-   p = _serial_tree.rb_node;
-   else if (rb_parent(parent)->rb_left == parent)
-   p = &(rb_parent(parent)->rb_left);
-   else
-   p = &(rb_parent(parent)->rb_right);
+   if (key->serial < 3) {
+   key->serial = 3;
+   goto attempt_insertion;
+   }
 
parent = rb_next(parent);
if (!parent)
-   break;
+   goto attempt_insertion;
 
xkey = rb_entry(parent, struct key, serial_node);
if (key->serial < xkey->serial)
-   goto insert_here;
+   goto attempt_insertion;
}
 
-   /* we've found a suitable hole - arrange for this key to occupy it */
-insert_here:
-   rb_link_node(>serial_node, parent, p);
-   rb_insert_color(>serial_node, _serial_tree);
-
-   spin_unlock(_serial_lock);
-
 } /* end key_alloc_serial() */
 
 /*/

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 19/21] net, 8139too.c: fix netpoll deadlock

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Ingo Molnar <[EMAIL PROTECTED]>

[PATCH] net, 8139too.c: fix netpoll deadlock

fix deadlock in the 8139too driver: poll handlers should never forcibly
enable local interrupts, because they might be used by netpoll/printk
from IRQ context.

  =
  [ INFO: inconsistent lock state ]
  2.6.19 #11
  -
  inconsistent {softirq-on-W} -> {in-softirq-W} usage.
  swapper/1 [HC0[0]:SC1[1]:HE1:SE0] takes:
   (>poll_lock){-+..}, at: [] net_rx_action+0x64/0x1de
  {softirq-on-W} state was registered at:
[] mark_lock+0x5b/0x39c
[] mark_held_locks+0x4b/0x68
[] trace_hardirqs_on+0x115/0x139
[] rtl8139_poll+0x3d7/0x3f4
[] netpoll_poll+0x82/0x32f
[] netpoll_send_skb+0xc9/0x12f
[] netpoll_send_udp+0x253/0x25b
[] write_msg+0x40/0x65
[] __call_console_drivers+0x45/0x51
[] _call_console_drivers+0x5d/0x61
[] release_console_sem+0x11f/0x1d8
[] register_console+0x1ac/0x1b3
[] init_netconsole+0x55/0x67
[] init+0x9a/0x24e
[] kernel_thread_helper+0x7/0x10
[] 0x
  irq event stamp: 819992
  hardirqs last  enabled at (819992): [] net_rx_action+0x39/0x1de
  hardirqs last disabled at (819991): [] net_rx_action+0x141/0x1de
  softirqs last  enabled at (817552): [] __do_softirq+0xa3/0xa8
  softirqs last disabled at (819987): [] do_softirq+0x5b/0xc9

  other info that might help us debug this:
  no locks held by swapper/1.

  stack backtrace:
   [] dump_trace+0x63/0x1e8
   [] show_trace_log_lvl+0x19/0x2e
   [] show_trace+0x12/0x14
   [] dump_stack+0x14/0x16
   [] print_usage_bug+0x23c/0x246
   [] mark_lock+0x108/0x39c
   [] __lock_acquire+0x361/0x9ed
   [] lock_acquire+0x56/0x72
   [] _spin_lock+0x35/0x42
   [] net_rx_action+0x64/0x1de
   [] __do_softirq+0x52/0xa8
   [] do_softirq+0x5b/0xc9
   [] irq_exit+0x3c/0x48
   [] do_IRQ+0xa4/0xbd
   [] common_interrupt+0x2e/0x34
   [] vprintk+0x2c0/0x309
   [] printk+0x1b/0x1d
   [] init+0x80/0x24e
   [] kernel_thread_helper+0x7/0x10
   ===

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/net/8139too.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- linux-2.6.19.4.orig/drivers/net/8139too.c
+++ linux-2.6.19.4/drivers/net/8139too.c
@@ -2129,14 +2129,15 @@ static int rtl8139_poll(struct net_devic
}
 
if (done) {
+   unsigned long flags;
/*
 * Order is important since data can get interrupted
 * again when we think we are done.
 */
-   local_irq_disable();
+   local_irq_save(flags);
RTL_W16_F(IntrMask, rtl8139_intr_mask);
__netif_rx_complete(dev);
-   local_irq_enable();
+   local_irq_restore(flags);
}
spin_unlock(>rx_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 14/21] usb-audio: work around wrong frequency in CM6501 descriptors

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--

[PATCH] usb-audio: work around wrong frequency in CM6501 descriptors

The C-Media CM6501 chip's descriptors say that altsetting 5 supports
48 kHz, but it actually plays at 96 kHz.

Signed-off-by: Clemens Ladisch <[EMAIL PROTECTED]>
Signed-off-by: Jaroslav Kysela <[EMAIL PROTECTED]>
Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 sound/usb/usbaudio.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- linux-2.6.19.4.orig/sound/usb/usbaudio.c
+++ linux-2.6.19.4/sound/usb/usbaudio.c
@@ -2471,7 +2471,13 @@ static int parse_audio_format_rates(stru
fp->nr_rates = nr_rates;
fp->rate_min = fp->rate_max = combine_triple([8]);
for (r = 0, idx = offset + 1; r < nr_rates; r++, idx += 3) {
-   unsigned int rate = fp->rate_table[r] = 
combine_triple([idx]);
+   unsigned int rate = combine_triple([idx]);
+   /* C-Media CM6501 mislabels its 96 kHz altsetting */
+   if (rate == 48000 && nr_rates == 1 &&
+   chip->usb_id == USB_ID(0x0d8c, 0x0201) &&
+   fp->altsetting == 5 && fp->maxpacksize == 392)
+   rate = 96000;
+   fp->rate_table[r] = rate;
if (rate < fp->rate_min)
fp->rate_min = rate;
else if (rate > fp->rate_max)

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 15/21] usbaudio - Fix Oops with broken usb descriptors

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
[PATCH] usbaudio - Fix Oops with broken usb descriptors

This is a patch for ALSA Bug #2724. Some webcams provide bogus
settings with no valid rates. With this patch those are skipped.

Signed-off-by: Gregor Jasny <[EMAIL PROTECTED]>
Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
Signed-off-by: Jaroslav Kysela <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 sound/usb/usbaudio.c |6 ++
 1 file changed, 6 insertions(+)

--- linux-2.6.19.4.orig/sound/usb/usbaudio.c
+++ linux-2.6.19.4/sound/usb/usbaudio.c
@@ -2456,6 +2456,7 @@ static int parse_audio_format_rates(stru
 * build the rate table and bitmap flags
 */
int r, idx, c;
+   unsigned int nonzero_rates = 0;
/* this table corresponds to the SNDRV_PCM_RATE_XXX bit */
static unsigned int conv_rates[] = {
5512, 8000, 11025, 16000, 22050, 32000, 44100, 48000,
@@ -2478,6 +2479,7 @@ static int parse_audio_format_rates(stru
fp->altsetting == 5 && fp->maxpacksize == 392)
rate = 96000;
fp->rate_table[r] = rate;
+   nonzero_rates |= rate;
if (rate < fp->rate_min)
fp->rate_min = rate;
else if (rate > fp->rate_max)
@@ -2493,6 +2495,10 @@ static int parse_audio_format_rates(stru
if (!found)
fp->needs_knot = 1;
}
+   if (!nonzero_rates) {
+   hwc_debug("All rates were zero. Skipping format!\n");
+   return -1;
+   }
if (fp->needs_knot)
fp->rates |= SNDRV_PCM_RATE_KNOT;
} else {

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 10/21] ide: fix drive side 80c cable check

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--

eighty_ninty_three() had word 93 validitity check but not the 80c bit
test itself (bit 12).  This increases the chance of incorrect wire
detection especially because host side cable detection is often
unreliable and we sometimes soley depend on drive side cable
detection.  Fix it.

Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Acked-by: Alan <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/ide/ide-iops.c |2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.19.4.orig/drivers/ide/ide-iops.c
+++ linux-2.6.19.4/drivers/ide/ide-iops.c
@@ -607,6 +607,8 @@ u8 eighty_ninty_three (ide_drive_t *driv
if(!(drive->id->hw_config & 0x4000))
return 0;
 #endif /* CONFIG_IDEDMA_IVB */
+   if (!(drive->id->hw_config & 0x2000))
+   return 0;
return 1;
 }
 

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 08/21] aio: fix buggy put_ioctx call in aio_complete - v2

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--

From: "Ken Chen" <[EMAIL PROTECTED]>

An AIO bug was reported that sleeping function is being called in softirq
context:

BUG: warning at kernel/mutex.c:132/__mutex_lock_common()
Call Trace:
 [] __mutex_lock_slowpath+0x640/0x6c0
 [] mutex_lock+0x20/0x40
 [] flush_workqueue+0xb0/0x1a0
 [] __put_ioctx+0xc0/0x240
 [] aio_complete+0x2f0/0x420
 [] finished_one_bio+0x200/0x2a0
 [] dio_bio_complete+0x1c0/0x200
 [] dio_bio_end_aio+0x60/0x80
 [] bio_endio+0x110/0x1c0
 [] __end_that_request_first+0x180/0xba0
 [] end_that_request_chunk+0x30/0x60
 [] scsi_end_request+0x50/0x300 [scsi_mod]
 [] scsi_io_completion+0x200/0x8a0 [scsi_mod]
 [] sd_rw_intr+0x330/0x860 [sd_mod]
 [] scsi_finish_command+0x100/0x1c0 [scsi_mod]
 [] scsi_softirq_done+0x230/0x300 [scsi_mod]
 [] blk_done_softirq+0x160/0x1c0
 [] __do_softirq+0x200/0x240
 [] do_softirq+0x70/0xc0

See report: http://marc.theaimsgroup.com/?l=linux-kernel=116599593200888=2

flush_workqueue() is not allowed to be called in the softirq context.
However, aio_complete() called from I/O interrupt can potentially call
put_ioctx with last ref count on ioctx and triggers bug.  It is simply
incorrect to perform ioctx freeing from aio_complete.

The bug is trigger-able from a race between io_destroy() and aio_complete().
A possible scenario:

cpu0   cpu1
io_destroy aio_complete
  wait_for_all_aios {__aio_put_req
 ... ctx->reqs_active--;
 if (!ctx->reqs_active)
return;
  }
  ...
  put_ioctx(ioctx)

 put_ioctx(ctx);
__put_ioctx
  bam! Bug trigger!

The real problem is that the condition check of ctx->reqs_active in
wait_for_all_aios() is incorrect that access to reqs_active is not
being properly protected by spin lock.

This patch adds that protective spin lock, and at the same time removes
all duplicate ref counting for each kiocb as reqs_active is already used
as a ref count for each active ioctx.  This also ensures that buggy call
to flush_workqueue() in softirq context is eliminated.

Signed-off-by: "Ken Chen" <[EMAIL PROTECTED]>
Cc: Zach Brown <[EMAIL PROTECTED]>
Cc: Suparna Bhattacharya <[EMAIL PROTECTED]>
Cc: Benjamin LaHaise <[EMAIL PROTECTED]>
Cc: Badari Pulavarty <[EMAIL PROTECTED]>
Acked-by: Jeff Moyer <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 fs/aio.c |   20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

--- linux-2.6.19.4.orig/fs/aio.c
+++ linux-2.6.19.4/fs/aio.c
@@ -298,17 +298,23 @@ static void wait_for_all_aios(struct kio
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
 
+   spin_lock_irq(>ctx_lock);
if (!ctx->reqs_active)
-   return;
+   goto out;
 
add_wait_queue(>wait, );
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
while (ctx->reqs_active) {
+   spin_unlock_irq(>ctx_lock);
schedule();
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+   spin_lock_irq(>ctx_lock);
}
__set_task_state(tsk, TASK_RUNNING);
remove_wait_queue(>wait, );
+
+out:
+   spin_unlock_irq(>ctx_lock);
 }
 
 /* wait_on_sync_kiocb:
@@ -425,7 +431,6 @@ static struct kiocb fastcall *__aio_get_
ring = kmap_atomic(ctx->ring_info.ring_pages[0], KM_USER0);
if (ctx->reqs_active < aio_ring_avail(>ring_info, ring)) {
list_add(>ki_list, >active_reqs);
-   get_ioctx(ctx);
ctx->reqs_active++;
okay = 1;
}
@@ -538,8 +543,6 @@ int fastcall aio_put_req(struct kiocb *r
spin_lock_irq(>ctx_lock);
ret = __aio_put_req(ctx, req);
spin_unlock_irq(>ctx_lock);
-   if (ret)
-   put_ioctx(ctx);
return ret;
 }
 
@@ -795,8 +798,7 @@ static int __aio_run_iocbs(struct kioctx
 */
iocb->ki_users++;   /* grab extra reference */
aio_run_iocb(iocb);
-   if (__aio_put_req(ctx, iocb))  /* drop extra ref */
-   put_ioctx(ctx);
+   __aio_put_req(ctx, iocb);
}
if (!list_empty(>run_list))
return 1;
@@ -1014,14 +1016,10 @@ put_rq:
/* everything turned out well, dispose of the aiocb. */
ret = __aio_put_req(ctx, iocb);
 
-   spin_unlock_irqrestore(>ctx_lock, flags);
-
if (waitqueue_active(>wait))
wake_up(>wait);
 
-   if (ret)
-   put_ioctx(ctx);
-
+   spin_unlock_irqrestore(>ctx_lock, flags);
return ret;
 }
 

--
-
To unsubscribe from this list: 

[patch 01/21] V4L: cx88: Fix lockup on suspend

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
Suspending with the cx88xx module loaded causes the system to lock up
because the cx88_audio_thread kthread was missing a try_to_freeze()
call, which caused it to go into a tight loop and result in softlockup
when suspending. Fix that.

(cherry picked from commit a96afb3e9428f2e7463344f12dbc85faf08e2e09)

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/video/cx88/cx88-tvaudio.c |2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.19.4.orig/drivers/media/video/cx88/cx88-tvaudio.c
+++ linux-2.6.19.4/drivers/media/video/cx88/cx88-tvaudio.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -974,6 +975,7 @@ int cx88_audio_thread(void *data)
msleep_interruptible(1000);
if (kthread_should_stop())
break;
+   try_to_freeze();
 
/* just monitor the audio status for now ... */
memset(, 0, sizeof(t));

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 04/21] V4L: tveeprom: autodetect LG TAPC G701D as tuner type 37

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
Autodetect LG TAPC G701D as tuner type 37, fixing
mis-detected tuners in some Hauppauge tv tuner cards.

Thanks to Adonis Papas, for pointing this out.

(cherry picked from commit 1323fbda1343f50f198bc8bd6d1d59c8b7fc45bf)

Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/video/tveeprom.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.19.4.orig/drivers/media/video/tveeprom.c
+++ linux-2.6.19.4/drivers/media/video/tveeprom.c
@@ -184,7 +184,7 @@ hauppauge_tuner[] =
{ TUNER_ABSENT,"Thompson DTT757"},
/* 80-89 */
{ TUNER_ABSENT,"Philips FQ1216LME MK3"},
-   { TUNER_ABSENT,"LG TAPC G701D"},
+   { TUNER_LG_PAL_NEW_TAPC, "LG TAPC G701D"},
{ TUNER_LG_NTSC_NEW_TAPC, "LG TAPC H791F"},
{ TUNER_LG_PAL_NEW_TAPC, "TCL 2002MB 3"},
{ TUNER_LG_PAL_NEW_TAPC, "TCL 2002MI 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/


[patch 03/21] V4L: fix ks0127 status flags

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
Or status flags together in DECODER_GET_STATUS instead of and-zapping them.

(cherry picked from commit 55d5440d4587454628a850ce26703639885af678)

Signed-off-by: Martin Samuelsson <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/video/ks0127.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.19.4.orig/drivers/media/video/ks0127.c
+++ linux-2.6.19.4/drivers/media/video/ks0127.c
@@ -712,13 +712,13 @@ static int ks0127_command(struct i2c_cli
*iarg = 0;
status = ks0127_read(ks, KS_STAT);
if (!(status & 0x20))/* NOVID not set */
-   *iarg = (*iarg & DECODER_STATUS_GOOD);
+   *iarg = (*iarg | DECODER_STATUS_GOOD);
if ((status & 0x01))  /* CLOCK set */
-   *iarg = (*iarg & DECODER_STATUS_COLOR);
+   *iarg = (*iarg | DECODER_STATUS_COLOR);
if ((status & 0x08))   /* PALDET set */
-   *iarg = (*iarg & DECODER_STATUS_PAL);
+   *iarg = (*iarg | DECODER_STATUS_PAL);
else
-   *iarg = (*iarg & DECODER_STATUS_NTSC);
+   *iarg = (*iarg | DECODER_STATUS_NTSC);
break;
 
//Catch any unknown command

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 06/21] net/smc911x: match up spin lock/unlock

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
From: Peter Korsgaard <[EMAIL PROTECTED]>

smc911x_phy_configure's error handling unconditionally unlocks the
spinlock even if it wasn't locked. Patch fixes it.

Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/net/smc911x.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- linux-2.6.19.4.orig/drivers/net/smc911x.c
+++ linux-2.6.19.4/drivers/net/smc911x.c
@@ -965,11 +965,11 @@ static void smc911x_phy_configure(void *
 * We should not be called if phy_type is zero.
 */
if (lp->phy_type == 0)
-goto smc911x_phy_configure_exit;
+goto smc911x_phy_configure_exit_nolock;
 
if (smc911x_phy_reset(dev, phyaddr)) {
printk("%s: PHY reset timed out\n", dev->name);
-   goto smc911x_phy_configure_exit;
+   goto smc911x_phy_configure_exit_nolock;
}
spin_lock_irqsave(>lock, flags);
 
@@ -1038,6 +1038,7 @@ static void smc911x_phy_configure(void *
 
 smc911x_phy_configure_exit:
spin_unlock_irqrestore(>lock, flags);
+smc911x_phy_configure_exit_nolock:
lp->work_pending = 0;
 }
 

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


[patch 05/21] V4L: buf_qbuf: fix videobuf_queue->stream corruption and lockup

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
We are doing ->buf_prepare(buf) before adding buf to q->stream list. This
means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer.

(cherry picked from commit 419dd8378dfa32985672ab7927b4bc827f33b332)

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/video/video-buf.c |1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.19.4.orig/drivers/media/video/video-buf.c
+++ linux-2.6.19.4/drivers/media/video/video-buf.c
@@ -700,6 +700,7 @@ videobuf_qbuf(struct videobuf_queue *q,
goto done;
}
if (buf->state == STATE_QUEUED ||
+   buf->state == STATE_PREPARED ||
buf->state == STATE_ACTIVE) {
dprintk(1,"qbuf: buffer is already queued or active.\n");
goto done;

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 00/21] 2.6.19-stable review

2007-02-20 Thread Greg KH
This is the start of the stable review cycle for the 2.6.19.5 release.

This will probably be the last release of the 2.6.19-stable series, so
if there are patches that you feel should be applied to that tree,
please let me know.

There are 21 patches in this series, all will be posted as a response to
this one.  If anyone has any issues with these being applied, please let
us know.  If anyone is a maintainer of the proper subsystem, and wants
to add a Signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the Cc:
line.  If you wish to be a reviewer, please email [EMAIL PROTECTED] to
add your name to the list.  If you want to be off the reviewer list,
also email us.

Responses should be made by Friday February 23 00:00 UTC.  Anything
received after that time might be too late.

The whole patch set can be downloaded at:
kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.19.5-rc1.gz

thanks,

the -stable release team
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 02/21] V4L: Fix quickcam communicator driver for big endian architectures

2007-02-20 Thread Greg KH
-stable review patch.  If anyone has any objections, please let us know.

--
Host endianess does not affect the order that pixel rgb data comes
in from the quickcam (the values are bytes, not words or longs).  The
driver is erroniously swapping the order of rgb values for big endian
machines.  This patch is needed get the Quickcam communicator working
on big endian machines (tested on powerpc)

(cherry picked from commit c6d704c8c4453f05717ba88792f70f8babf95268)

Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

---
 drivers/media/video/usbvideo/quickcam_messenger.h |   14 --
 1 file changed, 14 deletions(-)

--- linux-2.6.19.4.orig/drivers/media/video/usbvideo/quickcam_messenger.h
+++ linux-2.6.19.4/drivers/media/video/usbvideo/quickcam_messenger.h
@@ -35,27 +35,13 @@ struct rgb {
 };
 
 struct bayL0 {
-#ifdef __BIG_ENDIAN
-   u8 r;
-   u8 g;
-#elif __LITTLE_ENDIAN
u8 g;
u8 r;
-#else
-#error not byte order defined
-#endif
 };
 
 struct bayL1 {
-#ifdef __BIG_ENDIAN
-   u8 g;
-   u8 b;
-#elif __LITTLE_ENDIAN
u8 b;
u8 g;
-#else
-#error not byte order defined
-#endif
 };
 
 struct cam_size {

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


Re: [PATCH] deprecated/obsolete patch

2007-02-20 Thread Bartlomiej Zolnierkiewicz

On Wednesday 21 February 2007 00:20, Robert P. J. Day wrote:
> 
>   here's a slightly revised wording, if that makes it clearer:

I think that it does explain things better and I hope that some form
of consensus can be finally reached.

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


Re: IPV6 build failure 2.6.20-git1x

2007-02-20 Thread Sid Boyce

Neil Brown wrote:

On Wednesday February 21, [EMAIL PROTECTED] wrote:
  

x86_64 builds without errors on openSUSE 10.2.
x86 on openSUSE 10.3 Alpha1
 gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
# CONFIG_IPV6_MIP6 is not set
CONFIG_IPV6_SIT=m
# CONFIG_IPV6_TUNNEL is not set
CONFIG_IPV6_MULTIPLE_TABLES=y
# CONFIG_IPV6_SUBTREES is not set
CONFIG_IP6_NF_MATCH_IPV6HEADER=m

  LD  arch/i386/lib/built-in.o
  CC  arch/i386/lib/bitops.o
  AS  arch/i386/lib/checksum.o
  CC  arch/i386/lib/delay.o
  AS  arch/i386/lib/getuser.o
  CC  arch/i386/lib/memcpy.o
  CC  arch/i386/lib/mmx.o
  AS  arch/i386/lib/putuser.o
  AS  arch/i386/lib/semaphore.o
  CC  arch/i386/lib/strstr.o
  CC  arch/i386/lib/usercopy.o
  AR  arch/i386/lib/lib.a
  GEN .version
  CHK include/linux/compile.h
  UPD include/linux/compile.h
  CC  init/version.o
  LD  init/built-in.o
  LD  .tmp_vmlinux1
net/built-in.o: In function `svc_udp_recvfrom':
svcsock.c:(.text+0x91f9c): undefined reference to `__ipv6_addr_type'
make: *** [.tmp_vmlinux1] Error 1
:/usr/src/linux-2.6.20-git15



Yes, known.  I really should get onto that

Currently you cannot have IPV6=m and SUNRPC=y.  All other combinations
should work.

NeilBrown


  

Fixed thanks, on x86 SUNRPC was =y and on x86_64 was =m.
Regards
Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, 
Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks


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


Re: Kernel oops in 2.6.18.3 with RAID5

2007-02-20 Thread Andrew Robinson

Here is the full dmesg log of the crash:

iret exception:  [#1]
SMP
Modules linked in: ppdev lp button ac battery ipv6 dm_snapshot
dm_mirror dm_mod loop tsdev rtc psmouse parport_pc parport floppy
serio_raw pcspkr i2c_nforce2 snd_intel8x0 snd_ac97_codec snd_
ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc shpchp
pci_hotplug i2c_core nvidia_agp agpgart evdev ext3 jbd mbcache raid456
md_mod xor ide_cd cdrom ide_disk sd_mod generic 8139too
amd74xx ide_core sata_sil 8139cp mii sata_nv libata scsi_mod forcedeth
ehci_hcd ohci_hcd usbcore thermal processor fan
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 0216   (2.6.18-3-686 #1)
EIP is at copy_data+0xff/0x14b [raid456]
eax: ddcce000   ebx: 1000   ecx: 000f   edx: c1f71000
esi: ddccefc4   edi: c1f71fc4   ebp:    esp: dd261e4c
ds: 007b   es: 007b   ss: 0068
Process md0_raid5 (pid: 1115, ti=dd26 task=dd0ed550 task.ti=dd26)
Stack: c1f71000 ddb55460 c1e377a0  ddcce000 1000 c1f71000 
     dd20c388 c1e377a0 dd20c354 de95d96d 0c649510
   c0116d0a 06323c4f  dd20c384  c13c52e0 e000
Call Trace:
[] handle_stripe+0x10da/0x2075 [raid456]
[] find_busiest_group+0x177/0x46a
[] __wake_up+0x2a/0x3d
[] __release_stripe+0x10c/0x110 [raid456]
[] release_stripe+0x21/0x2e [raid456]
[] raid5d+0x10d/0x132 [raid456]
[] md_thread+0xd7/0xed [md_mod]
[] autoremove_wake_function+0x0/0x2d
[] md_thread+0x0/0xed [md_mod]
[] kthread+0xc2/0xef
[] kthread+0x0/0xef
[] kernel_thread_helper+0x5/0xb
Code: 8d 04 2f 01 4c 24 18 83 7c 24 0c 00 8b 54 24 18 8d 34 32 89 34
24 74 09 89 d9 89 c7 c1 e9 02 eb 0a 8b 3c 24 89 d9 89 c6 c1 e9 02 
a5 89 d9 83 e1 03 74 02 f3 a4 8b 44 24 18 ba 03 00
00 00 e8
EIP: [] copy_data+0xff/0x14b [raid456] SS:ESP 0068:dd261e4c
<6>note: md0_raid5[1115] exited with preempt_count 1

I was having instability with this machine before (slackware 10.1 with
2.6.10 kernel) while compiling code (especially the kernel). I just
rebuilt is as a debian box. It never died in the raid array code
before though, just in gcc.

I have tested the machine's ram with memtest86 (3 passes) and will
more thoroughly check it tonight. Besides bad RAM, does anyone have
any other ideas on what may be causing the issue?


On 2/20/07, Andrew Robinson wrote:

I can't seem to find sufficient information on what may have caused an
oops. I am running a debian machine using kernel 2.6.18.3. Here is
detailed information on the system:

debian etch
CPU: AMD athlon 2100+
kernel package: linux-image-2.6.18-3-686
raid5 array: 3 active, 1 spare on md0
raid fs: ext3
raid is physically across 2 on-board NVidia SATA ports and 2 ports
from a SATA controller card

I am at work, and this was a home computer. This is what I got from
syslog when in SSH before it died:

bserver kernel: iret exception:  [#1]
bserver kernel: SMP
bserver kernel: CPU:0
bserver kernel: EIP is at copy_data+0xff/0x14b [raid456]
bserver kernel: eax: ddcce000   ebx: 1000   ecx: 000f   edx: c1f71000
bserver kernel: esi: ddccefc4   edi: c1f71fc4   ebp:    esp: dd261e4c
bserver kernel: ds: 007b   es: 007b   ss: 0068
bserver kernel: Process md0_raid5 (pid: 1115, ti=dd26
task=dd0ed550 task.ti=dd26)
bserver kernel: Stack: c1f71000 ddb55460 c1e377a0  ddcce000
1000 c1f71000 
bserver kernel:   dd20c388 c1e377a0
dd20c354 de95d96d 0c649510
bserver kernel: c0116d0a 06323c4f  dd20c384
 c13c52e0 e000
bserver kernel: Call Trace:
bserver kernel: Code: 8d 04 2f 01 4c 24 18 83 7c 24 0c 00 8b 54 24 18
8d 34 32 89 34 24 74 09 89 d9 89 c7 c1 e9 02 eb 0a 8b 3c 24 89 d9 89
c6 c1 e9 02  a5 89 d9 83 e1 03 74 02 f3 a4 8b 44 24 18 ba 03 00 00
00 e8
bserver kernel: EIP: [] copy_data+0xff/0x14b [raid456]
SS:ESP 0068:dd261e4c

The only similar message chain that I could find was about 2.6.19 and
they recommended disabling preempting, but debian's 2.6.18.3 already
has that disabled by default.

Any ideas?

Thanks,
Andrew


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


Re: SATA problems

2007-02-20 Thread Marcus Haebler

Tejun,

thanks for the patches! I am on an Intel P965/ICH8R.

Best,

Marcus

On 2/20/07, Tejun Heo <[EMAIL PROTECTED]> wrote:

* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment.  Patches are submitted to fix
the problem.  Just drop the blacklist patch.  Your drives should work
fine in NCQ mode.  My gut feeling is that your problem is power related
from the beginning.

* Marcus, you're on via's ahci controller, right?  The problem you saw
was bad interaction between blacklisted NCQ _controller_ and dynamic
queue depth adjustment.  Patches submitted.

Thanks.

--
tejun


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


Re: [PATCH] fix handling of SIGCHILD from reaped child

2007-02-20 Thread KAMEZAWA Hiroyuki
On Tue, 20 Feb 2007 15:10:07 -0800 (PST)
Roland McGrath <[EMAIL PROTECTED]> wrote:

> I'm usually the stickler for anal POSIX compliance, but this is one thing
> that I did notice a while ago, realized Linux had never done it, and
> decided I didn't care.
> 
Okay, I don't think this is a big trouble.

> This is one of those parts of the standard that was originally written in a
> single-threaded process frame of mind, and was never amended or clarified
> later when multi-threaded semantics got well-specified in the standard.
> 
> It's clear what the requirement is trying to achieve.  It lets you have a
> SIGCHLD signal handler that calls wait, and be sure its call never blocks,
> as long as you block SIGCHLD while making any other wait calls.  But Linux
> has never done this even for single-threaded processes, so existing
> application code already has to cope with the race.  (Anyway, this
> guarantee is not all that helpful if you have more than one child and so
> might be running the handler once after SIGCHLD was generated more than
> once.  You can't just use WNOHANG in your handler because you aren't
> actually guaranteed that the zombie is ready already when you get the 
> SIGCHLD.)
> 
> This guarantee is not of any use when there might be other threads with
> SIGCHLD unblocked or other threads that call wait* functions (calls that
> draw from the same pool of PIDs anyway).  There can always be another
> thread that just dequeued the SIGCHLD but hasn't gotten into its handler
> yet, so clearing the pending SIGCHLD doesn't really cover it.
> 
> Unhelpful as it is the multithreaded context, I think it's clear that the
> standard's wording means "when SIGCHLD is blocked by the thread calling
> wait", but in fact as to being a guarantee it's only meaningful when
> SIGCHLD is blocked by all threads.  The mention of blocking the signal is
> only there to remind you that well-defined semantics about a "pending"
> signal only ever apply when the signal is blocked.  If any thread has it
> unblocked, then "pending" is an ephemeral condition not necessarily
> observable at all--as soon as you could say it's pending, some such thread
> might be handling it.
> 
> The "if there is another child available" test is rather ugly to do
> correctly now.  It would be less so if the children list moved into
> signal_struct and was just shared directly.  The most "correct" it can get
> is still not all that useful in a multithreaded context.  So I'm pretty
> ambivalent about bothering with this.
> 
Hmm, okay. It seems a good workaround to say "please use WNOHANG always in
your SIGCHLD handler's wait*() call" 

My only concerns is that LSB people say wait/waitpid meets SUSv3. 

Thanks,
-Kame

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


Re: IPV6 build failure 2.6.20-git1x

2007-02-20 Thread Neil Brown
On Wednesday February 21, [EMAIL PROTECTED] wrote:
> x86_64 builds without errors on openSUSE 10.2.
> x86 on openSUSE 10.3 Alpha1
>  gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)
> CONFIG_IPV6=m
> CONFIG_IPV6_PRIVACY=y
> CONFIG_IPV6_ROUTER_PREF=y
> CONFIG_IPV6_ROUTE_INFO=y
> # CONFIG_IPV6_MIP6 is not set
> CONFIG_IPV6_SIT=m
> # CONFIG_IPV6_TUNNEL is not set
> CONFIG_IPV6_MULTIPLE_TABLES=y
> # CONFIG_IPV6_SUBTREES is not set
> CONFIG_IP6_NF_MATCH_IPV6HEADER=m
> 
>   LD  arch/i386/lib/built-in.o
>   CC  arch/i386/lib/bitops.o
>   AS  arch/i386/lib/checksum.o
>   CC  arch/i386/lib/delay.o
>   AS  arch/i386/lib/getuser.o
>   CC  arch/i386/lib/memcpy.o
>   CC  arch/i386/lib/mmx.o
>   AS  arch/i386/lib/putuser.o
>   AS  arch/i386/lib/semaphore.o
>   CC  arch/i386/lib/strstr.o
>   CC  arch/i386/lib/usercopy.o
>   AR  arch/i386/lib/lib.a
>   GEN .version
>   CHK include/linux/compile.h
>   UPD include/linux/compile.h
>   CC  init/version.o
>   LD  init/built-in.o
>   LD  .tmp_vmlinux1
> net/built-in.o: In function `svc_udp_recvfrom':
> svcsock.c:(.text+0x91f9c): undefined reference to `__ipv6_addr_type'
> make: *** [.tmp_vmlinux1] Error 1
> :/usr/src/linux-2.6.20-git15

Yes, known.  I really should get onto that

Currently you cannot have IPV6=m and SUNRPC=y.  All other combinations
should work.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 handling of SIGCHILD from reaped child

2007-02-20 Thread KAMEZAWA Hiroyuki
On Tue, 20 Feb 2007 20:20:49 +0300
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> > > > +   clear_stale_sigchild(current, retval);
> > > 
> > > But we are not checking that SIGCHLD is blocked?
> > > 
> > I'm sorry if I don't read SUSv3 correctly. SUSv3 doesn't define how we 
> > should
> > do if SIGCHLD is not blocked.(so I don't check not-blocked case.)
> 
> Probably it is me who misunderstands SUSv3. Could you point me the reference
> to authoritative document? My understanding: if blocked AND wait() succeeds.
> 
I read this:
http://www.opengroup.org/onlinepubs/009695399/


> > IMHO, user's sig-child-handler is tend to call wait()/waitpid() and expects
> > successful return. So removing stale signal here may be good.
> 
> Yes. But sig-child-handler should do
> 
>   while (wait() >= 0)
>   
> 
> anyway, because SIGCHLD is not a realtime signal.
> 

Ah...it looks I should explation why I found this more.

A user (who is migrated from Solaris) met following situation.
==(single threaded program.)

pid1 = fork();
if (!pid1) {
do_something_forever();
}
set SIGCHLD handler here to catch pid1's error-exit

if (!pid2) {
do_something_in_shortterm();
}
Block SIGCHLD
ret = waitpid(pid2, hoge, hoge); // wait for pid2
UNBlock SIGCHLD
==

And SIGCHLD handler didn't use WNOHANG. 
I asked him to fix his program. He agreed.(So, no problem now.)

While our problem was fixed, it seems Linux doesn't meet spec.(SUSv3)
So I posted. 
But this is rare situation and this fix makes codes ugly


Thanks,
-Kame

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


IPV6 build failure 2.6.20-git1x

2007-02-20 Thread Sid Boyce

x86_64 builds without errors on openSUSE 10.2.
x86 on openSUSE 10.3 Alpha1
gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
# CONFIG_IPV6_MIP6 is not set
CONFIG_IPV6_SIT=m
# CONFIG_IPV6_TUNNEL is not set
CONFIG_IPV6_MULTIPLE_TABLES=y
# CONFIG_IPV6_SUBTREES is not set
CONFIG_IP6_NF_MATCH_IPV6HEADER=m

 LD  arch/i386/lib/built-in.o
 CC  arch/i386/lib/bitops.o
 AS  arch/i386/lib/checksum.o
 CC  arch/i386/lib/delay.o
 AS  arch/i386/lib/getuser.o
 CC  arch/i386/lib/memcpy.o
 CC  arch/i386/lib/mmx.o
 AS  arch/i386/lib/putuser.o
 AS  arch/i386/lib/semaphore.o
 CC  arch/i386/lib/strstr.o
 CC  arch/i386/lib/usercopy.o
 AR  arch/i386/lib/lib.a
 GEN .version
 CHK include/linux/compile.h
 UPD include/linux/compile.h
 CC  init/version.o
 LD  init/built-in.o
 LD  .tmp_vmlinux1
net/built-in.o: In function `svc_udp_recvfrom':
svcsock.c:(.text+0x91f9c): undefined reference to `__ipv6_addr_type'
make: *** [.tmp_vmlinux1] Error 1
:/usr/src/linux-2.6.20-git15

Regards
Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, 
Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks


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


  1   2   3   4   5   6   7   8   9   >