On Wed, Feb 20 2008, Mike Miller wrote:
> Patch 1 of 1
>
> This patch hopefully fixes all the brokeness in my last submission. It
> compiles cleanly with tape support on or off. I added a couple of #ifdef's
> and removed the broken macro definition. The #ifdef's made it unneccesary.
> It also repl
James, somewhere between 2.6.25-rc1 and -rc2 this new warning appeared, care
to give the locking a quick once-over here?
drivers/scsi/lpfc/lpfc_sli.c:645:1: warning: context imbalance in
'lpfc_sli_hbqbuf_fill_hbqs' - wrong count at exit
Full log available if you want it.
Harvey
-
To unsubscrib
A similar change went into the SAS/SATL layer I support
shortly after I posted the version which you forked off.
The git date of the commit is: Tue Feb 7 22:14:54 2006 -0800.
BTW, the problem you're "debugging" may require a protocol
trace and a sequencer update by Adaptec.
Luben
--- On Wed,
On Wed, 2008-02-20 at 22:55 +, Russell King wrote:
> On Wed, Feb 20, 2008 at 09:26:55PM +, ian wrote:
> >
> > On Wed, 2008-02-20 at 20:10 +0100, Andi Kleen wrote:
> > > Is there a time frame on when will this happen? Will you be ready
> > > for the .26 merge window?
> >
> > I think the bi
On Wed, Feb 20, 2008 at 09:26:55PM +, ian wrote:
>
> On Wed, 2008-02-20 at 20:10 +0100, Andi Kleen wrote:
> > Is there a time frame on when will this happen? Will you be ready
> > for the .26 merge window?
>
> I think the big sticking point now is getting the generic clock
> interface merged
Patch 1 of 1
This patch hopefully fixes all the brokeness in my last submission. It
compiles cleanly with tape support on or off. I added a couple of #ifdef's
and removed the broken macro definition. The #ifdef's made it unneccesary.
It also replaces create_proc_read_entry with proc_create.
This
On Wed, 2008-02-20 at 20:10 +0100, Andi Kleen wrote:
> ian wrote:
> > On Wed, 2008-02-20 at 18:49 +0100, Andi Kleen wrote:
> >>> So ... it's been 4 months. Any new users merged?
> >> At least dmam_declare_coherent_memory is completely unused as of
> >> 2.6.25-rc* I plan to remove these.
> >
> >
Finding these in my syslog when testing 2.6.25-rc2{,-mm1} with
CONFIG_ENABLE_WARN_DEPRECATED=y:
<4>[5.312173] Driver 'sd' needs updating - please use bus_type methods
<4>[ 20.028800] Driver 'sr' needs updating - please use bus_type methods
<6>[ 22.849626] st: Version 20080117, fixed bufs
This patch (as1036) causes the SCSI midlayer to take into account the
residue value provided by some low-level drivers. There's at least
one situation (USB mass storage with the Bulk-only transport) where
the specification states that it is permissible for a device to
indicate some of the data was
On Wed, 20 Feb 2008, John LLOYD wrote:
>
>
> > On Mon, 4 Feb 2008, James Bottomley wrote:
> >
> > >
> > > On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote:
...
> > > > > This does still occur with 2.6.22; with a blank tape in my HP
> DDS-4 drive:
> > > > >
> > > > > $ tar tzvf /dev/ns
On Wed, 2008-02-20 at 11:10 -0700, Matthew Wilcox wrote:
> There is no need to allocate this memory atomically. There is no problem
> with sleeping during a bus scan, and it's actually causing problems
> for libata.
This bit is fine.
> Also remove the GFP_DMA flag. If it's needed, the block la
On Wed, 20 Feb 2008, Andrew Buehler wrote:
> In other words: I don't think that's likely to be practical in the
> present instance. If you have reason to believe otherwise (past positive
> experience with Novell, for instance), I'd be glad to hear it.
Greg KH may be able to help in that respect.
ian wrote:
> On Wed, 2008-02-20 at 18:49 +0100, Andi Kleen wrote:
>>> So ... it's been 4 months. Any new users merged?
>> At least dmam_declare_coherent_memory is completely unused as of
>> 2.6.25-rc* I plan to remove these.
>
> Please do not.
Do you use dma_declare_* or dmam_declare_*. The firs
On Wed, 2008-02-20 at 18:49 +0100, Andi Kleen wrote:
> >
> > So ... it's been 4 months. Any new users merged?
>
> At least dmam_declare_coherent_memory is completely unused as of
> 2.6.25-rc* I plan to remove these.
Please do not.
Dmitry and I are still working on getting the users of this in
Sorry, $SUBJECT should have read 'gfp_mask' instead of 'gfp_flags'.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On 2/20/2008 12:15 PM, Alan Stern wrote:
On Wed, 20 Feb 2008, Andrew Buehler wrote:
Hmm. One thing which just sprang to mind, in the stab-in-the-dark
category: in 2.6.24.2, launching the program on some machines gave
warnings along the lines of "this program is using a deprecated
ioctl, pleas
scsi_init_io() is already passed a gfp_mask, so we should use that
instead of an explicit GFP_ATOMIC
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f243fc3..b81170d 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scs
Am Tuesday, den 19 February hub James Bottomley folgendes in die Tasten:
> On Wed, 2008-02-20 at 04:17 +0100, Maximilian Wilhelm wrote:
> > Am Wednesday, den 20 February hub Krzysztof Oledzki folgendes in die Tasten:
> > > >What's the topology this thing is connected to?
> > > It is a Dell-1950II
There is no need to allocate this memory atomically. There is no problem
with sleeping during a bus scan, and it's actually causing problems
for libata.
Also remove the GFP_DMA flag. If it's needed, the block layer will
bounce-buffer it.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff
On Wednesday 20 February 2008 18:14:09 Matthew Wilcox wrote:
> On Wed, Oct 31, 2007 at 09:03:24PM +, ian wrote:
> > I'd like to ask that this not happen - there are several users of this
> > code in the handhelds.org tree, which we hope will merge into mainline.
> > this code is _essential_ to
> On Mon, 4 Feb 2008, James Bottomley wrote:
>
> >
> > On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote:
> > > On Mon, Feb 04, 2008 at 03:22:06PM +0100, maximilian attems wrote:
> > >
> > > (Added Bart to CC)
> > >
> > > > hello borislav,
> > > >
...
> > > > This does still occur wit
On Wed, 20 Feb 2008, Andrew Buehler wrote:
> > What do you mean by "does not see the drive"?
>
> Its detect-hardware-and-report mode shows a HD size of 0 (which is what
> it has showed in cases where the kernel has not detected the drive), its
> detect-partitions-and-report mode shows no partitio
On Wed, Oct 31, 2007 at 09:03:24PM +, ian wrote:
> I'd like to ask that this not happen - there are several users of this
> code in the handhelds.org tree, which we hope will merge into mainline.
> this code is _essential_ to allow support of these devices.
So ... it's been 4 months. Any new
(I suspect that some of the existing CC:s can now be dropped, and others
might need to be added if indeed this is worth discussing on kernel
lists at all, but I don't know what the protocol on that is so I have
left all of them in for the moment.)
On 2/20/2008 10:50 AM, Alan Stern wrote:
On Tue
On Wed, 2008-02-20 at 13:29 +, Daniel Drake wrote:
> arcmsr_iop_message_xfer() is called from atomic context under the
> queuecommand scsi_host_template handler. James Bottomley pointed out
> that the current GFP_KERNEL|GFP_DMA flags are wrong: firstly we are in
> atomic context, secondly this
On Wed, 2008-02-20 at 17:54 +0800, Keith Hopkins wrote:
> On 02/20/2008 11:48 AM, James Bottomley wrote:
> > On Tue, 2008-02-19 at 10:22 -0600, James Bottomley wrote:
> >> I'll see if I can come up with patches to fix this ... or at least
> >> mitigate the problems it causes.
> >
> > Darrick's wor
The libsas error handler has two fairly fatal bugs
1. scsi_sas_task_done calls scsi_eh_finish_cmd() too early. This
happens if the task completes after it has been aborted but before
the error handler starts up. Because scsi_eh_finish_cmd()
decrements host_failed and adds the task to th
On Tue, 19 Feb 2008, Andrew Buehler wrote:
> With those two problems out of the way, what is left is the hard-drive
> issue, and that is also halfway fixed by enabling ACPI. Specifically, it
> is "fixed" in that the kernel sees the hard drive and I can mount it,
> but it is not fixed in that the p
arcmsr_iop_message_xfer() is called from atomic context under the
queuecommand scsi_host_template handler. James Bottomley pointed out
that the current GFP_KERNEL|GFP_DMA flags are wrong: firstly we are in
atomic context, secondly this memory is not used for DMA.
Also removed some unneeded casts.
On 02/20/2008 11:48 AM, James Bottomley wrote:
> On Tue, 2008-02-19 at 10:22 -0600, James Bottomley wrote:
>> I'll see if I can come up with patches to fix this ... or at least
>> mitigate the problems it causes.
>
> Darrick's working on the ascb sequencer use after free problem.
>
> I looked int
On Feb 20, 2008 8:34 AM, Erez Zilber <[EMAIL PROTECTED]> wrote:
> Bart Van Assche wrote:
> > Or: data sent during the first burst is not transferred via one-sided
> > remote memory reads or writes but via two-sided send/receive
> > operations. At least on my setup, these operations are as fast as
>
31 matches
Mail list logo
