regarding it.
Please apply, thanks.
Applied to for-4.2/drivers, thanks.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
If you are targeting the next release
and don't depend on existing block changes, then your base should be
4.0. If you are dependent on changes in the block tree, the block tree
should be your base.
--
Jens Axboe
___
Linuxppc-dev mailing list
44
>> --- a/drivers/block/ps3vram.c
>> +++ b/drivers/block/ps3vram.c
>> @@ -1,5 +1,5 @@
>> /*
>> - * ps3vram - Use extra PS3 video ram as MTD block device.
>> + * ps3vram - Use extra PS3 video ram as block device.
>> *
>> * Copyright 2009 Sony Corp
ly support merging on REQ_TYPE_FS already, so how is the above
making it any different? In general, NOMERGE being set or not should not
make a difference. It's only a hint that we need not check further if we
should be merging on this request, since we already tried it once, found
we&#x
On 11/25/2015 12:10 PM, Hannes Reinecke wrote:
On 11/25/2015 06:56 PM, Jens Axboe wrote:
On 11/25/2015 02:04 AM, Hannes Reinecke wrote:
On 11/20/2015 04:28 PM, Ewan Milne wrote:
On Fri, 2015-11-20 at 15:55 +0100, Hannes Reinecke wrote:
Can't we have a joint effort here?
I've been
le I started a KVM right after a fresh boot. The machine
paniced even before that, so I hit this twice today.
Update to the tree as-of yesterday (or today) and it should work.
25364a9e54fb8296 doesn't include the latest block fixes that were sent
in yesterday, that should fix it. You nee
88] Modules linked in:
> [ 35.485311] CPU: 113 PID: 3973 Comm: io_uring_regist Not tainted
> 5.1.0-rc3-00012-g40b114779944 #1
> [ 35.486712] Hardware name: linux,dummy-virt (DT)
> [ 35.487450] pstate: 2045 (nzCv daif +PAN -UAO)
> [ 35.488228] pc : link_pwq+0x10/0x60
> [ 35.488794] lr : apply_wqattrs_commit+0xe0/0x118
> [ 35.489550] sp : 17e2bbc0
Huh, this looks odd, it's crashing inside the wq setup.
--
Jens Axboe
On 4/3/19 9:19 AM, Will Deacon wrote:
> Hi Jens,
>
> On Wed, Apr 03, 2019 at 07:49:26AM -0600, Jens Axboe wrote:
>> On 4/3/19 5:11 AM, Will Deacon wrote:
>>> will@autoplooker:~/liburing/test$ ./io_uring_register
>>> RELIMIT_MEMLOCK: 67108864 (67108864)
>>&
On 4/3/19 9:49 AM, Will Deacon wrote:
> On Wed, Apr 03, 2019 at 09:39:52AM -0600, Jens Axboe wrote:
>> On 4/3/19 9:19 AM, Will Deacon wrote:
>>> On Wed, Apr 03, 2019 at 07:49:26AM -0600, Jens Axboe wrote:
>>>> On 4/3/19 5:11 AM, Will Deacon wrote:
>>
On 10/30/19 4:49 PM, John Hubbard wrote:
> Convert fs/io_uring to use the new pin_user_pages() call, which sets
> FOLL_PIN. Setting FOLL_PIN is now required for code that requires
> tracking of pinned pages, and therefore for any code that calls
> put_user_page().
Reviewed-by
user_pages() to pin_user_pages().
>
> Reviewed-by: Jan Kara
> Signed-off-by: John Hubbard
You dropped my reviewed-by now... Given the file, you'd probably want
to keep that.
--
Jens Axboe
/io_uring.c b/fs/io_uring.c
index 2c2e8c25da01..745eb005fefe 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -69,6 +69,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include
--
Jens Axboe
On 11/29/19 8:14 AM, Christophe Leroy wrote:
Le 29/11/2019 à 17:04, Jens Axboe a écrit :
On 11/29/19 6:53 AM, Christophe Leroy wrote:
CC fs/io_uring.o
fs/io_uring.c: In function ‘loop_rw_iter’:
fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’
[-Werror=implicit
On 11/29/19 10:07 AM, Pavel Begunkov wrote:
On 29/11/2019 20:16, Jens Axboe wrote:
On 11/29/19 8:14 AM, Christophe Leroy wrote:
Reverting commit 311ae9e159d8 ("io_uring: fix dead-hung for non-iter
fixed rw") clears the failure.
Most likely an #include is missing.
Huh weird how
w them out.
>
> A short status yields the following _outdated_ 00-INDEX files, first
> counter is files listed in 00-INDEX but missing in the directory, last
> is files present but not listed in 00-INDEX.
For the block related bits:
Reviewed-by: Jens Axboe
--
Jens Axboe
t doesn't boot any more, bisect points at one of:
>>>
>>> cef6f55a9fb4 Mike Snitzer dm table: require that request-based DM
>>> be layered on blk-mq devices
>>> 953923c09fe8 Mike Snitzer dm: rename DM_TYPE_MQ_REQUEST_BASED to
>>> DM
gt; Signed-off-by: Anshuman Khandual
>
> For the 'ixgbe' driver changes.
>
> Acked-by: Jeff Kirsher
Lost the original, but for mtip32xx:
Acked-by: Jens Axboe
--
Jens Axboe
s/block/ps3vram.c: In function ‘ps3vram_probe’:
> drivers/block/ps3vram.c:770:23: warning: format ‘%lu’ expects argument
> of type ‘long unsigned int’, but argument 4 has type ‘sector_t {aka long long
> unsigned int}’ [-Wformat=]
>
> Fix this by using "%llu" instead.
Applied, thanks.
--
Jens Axboe
On 12/30/18 10:44 PM, Finn Thain wrote:
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Finn Thain
Applied, thanks.
--
Jens Axboe
ase method.
Applied, thanks.
--
Jens Axboe
> request_irq() error path. Move the memset() to fix this bug.
>
> BTW, the request_irq() failure for the left mediabay floppy (fd1) is not
> a regression. I don't know why it happens. The right media bay floppy
> (fd0) works fine however.
Applied, thanks.
--
Jens Axboe
dm driver is involved. An
>> important fix
>> for the dm driver went upstream recently, namely d37753540568 ("dm: Use
>> kzalloc
>> for all structs with embedded biosets/mempools"). Can you double check
>> whether
>> that commit it present in your tree?
On 6/7/18 8:45 AM, Jens Axboe wrote:
> On 6/7/18 4:37 AM, vrbagal1 wrote:
>> On 2018-06-07 13:12, Bart Van Assche wrote:
>>> On Thu, 2018-06-07 at 12:56 +0530, Venkat Rao B wrote:
>>>> On Thursday 07 June 2018 12:46 PM, Bart Van Assche wrote:
>>>>> On T
On 6/18/18 1:33 AM, Michael Ellerman wrote:
> Tejun Heo writes:
> ...
>> Jens Axboe (10):
>> libata: introduce notion of separate hardware tags
>> libata: convert core and drivers to ->hw_tag usage
>> libata: bump ->qc_active t
On 6/19/18 1:29 AM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 6/18/18 1:33 AM, Michael Ellerman wrote:
>>> Tejun Heo writes:
>>> ...
>>>> Jens Axboe (10):
>>>> libata: introduce notion of separate hardware tags
>>&g
On 6/19/18 1:29 AM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 6/18/18 1:33 AM, Michael Ellerman wrote:
>>> Tejun Heo writes:
>>> ...
>>>> Jens Axboe (10):
>>>> libata: introduce notion of separate hardware tags
>>&g
On 6/19/18 5:35 PM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 6/19/18 1:29 AM, Michael Ellerman wrote:
>>> Jens Axboe writes:
>>>> On 6/18/18 1:33 AM, Michael Ellerman wrote:
>>>>> Tejun Heo writes:
>>>>> ...
>>>&
r, mempool_alloc_slab,
mempool_free_slab, (void *) kc);
}
diff --git a/mm/mempool.c b/mm/mempool.c
index b54f2c20e5e0..060f44acd0df 100644
--- a/mm/mempool.c
+++ b/mm/mempool.c
@@ -508,7 +508,9 @@ EXPORT_SYMBOL(mempool_alloc_slab);
void mempool_free_slab(void *element, void *pool_data)
{
struct kmem_cache *mem = pool_data;
- kmem_cache_free(mem, element);
+
+ if (!WARN_ON(!mem))
+ kmem_cache_free(mem, element);
}
EXPORT_SYMBOL(mempool_free_slab);
--
Jens Axboe
e afaik with two of these on the motherboard,
> and populate both hotswap bays with a floppy drive (the machine ships
> only with one), so nobody cares...
>
> While at it, add a little fix to clear up stale interrupts when loading
> the driver or plugging
On 03/08/2012 05:28 AM, Stephen Rothwell wrote:
> It would probably be easiest if all these patches were merged via the
> powerpc tree to eliminate any dependencies between them. Their impact on
> generic code is very small.
Go ahead, no point in doing otherwise.
--
J
offset += size;
> flush_kernel_dcache_page(bvec->bv_page);
> - bvec_kunmap_irq(bvec, &flags);
> + bvec_kunmap_irq(buf, &flags);
> i++;
> }
> }
Thanks applied, that bug is all too common.
--
Jens Axboe
On 2010-10-16 21:39, Geert Uytterhoeven wrote:
> On Mon, Oct 11, 2010 at 21:42, Jens Axboe wrote:
>> On 2010-10-11 21:13, Dan Carpenter wrote:
>>> This should pass "buf" to bvec_kunmap_irq() instead of "bv". The api is
>>> like kmap_atomic(
> ps3nvram from .29 and merge the new one in .30 ?
It's an isolated driver for a special purpose platform, I would have
zero problems merging it :-)
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ed\n", op);
err = 0;
out:
bio_endio(bio, err);
}
I just typed it here, so if it doesn't compile you get to keep the
pieces :-)
Since ps3 is very RAM limited, I didn't bother with any highmem mapping
for the bio, since I gather that isn't an issue on that plat
On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> Hi Jens,
>
> On Thu, 5 Mar 2009, Jens Axboe wrote:
> > On Wed, Mar 04 2009, Geert Uytterhoeven wrote:
> > > Below is the rewrite of the PS3 Video RAM Storage Driver as a plain block
> > > device, as requested
On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> On Thu, 5 Mar 2009, Jens Axboe wrote:
> > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > On Thu, 5 Mar 2009, Jens Axboe wrote:
> > > > On Wed, Mar 04 2009, Geert Uytterhoeven wrote:
> > > > > Belo
On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> On Fri, 6 Mar 2009, Jens Axboe wrote:
> > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > But then I noticed ps3vram_make_request() may be called concurrently,
> > > so I had to add a mutex to avoid data corruption.
On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> On Fri, 6 Mar 2009, Jens Axboe wrote:
> > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > But
this patch, but you may want to consider that for a future
patch.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> On Fri, 6 Mar 2009, Jens Axboe wrote:
> > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > &
On Mon, Mar 09 2009, Jens Axboe wrote:
> On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > >
On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> On Mon, 9 Mar 2009, Jens Axboe wrote:
> > On Mon, Mar 09 2009, Jens Axboe wrote:
> > > On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > >
type of timeout checking from scsi to block is a useful generalisation.
>
> I will revert it from next-20090327 as well as it is still in the
> for-next branch of the block tree.
I'll update for-next, sorry about that. I had dropped it from
for-2.6.30, but forgot to update akpm/next branches.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
added your three
patches, thanks Geert.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
d6cf7b40] c0129f74 .do_sync_read+0xcc/0x130
> [c000d6cf7ce0] c012af44 .vfs_read+0xd0/0x1bc
> [c000d6cf7d80] c012b138 .SyS_read+0x58/0xa0
> [c000d6cf7e30] c00084ac syscall_exit+0x0/0x40
Just ran into t
On Thu, Apr 09 2009, Jens Axboe wrote:
> On Thu, Apr 09 2009, Sachin Sant wrote:
> > I had Next 09 booted on a powerpc box and was compiling a kernel.
> > That's when i ran into this oops.
> >
> > Unable to handle kernel paging request for data at address 0x00
cements, then an endless
> splurge of hda error messages - sorry, I'm not being helpful, other
> worries...
It's the media event notification that goes crazy. Try and comment out
this line:
drive->dev_flags |= IDE_DFLAG_MEDIA_CHANGED;
in drivers/ide/ide-cd.c:cdrom_saw_media_change() and see if it boots.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
r+0x1c/0x30
>> [c00109b4fe30] [c00085b4] syscall_exit+0x0/0x40
>> Instruction dump:
>> eb41ffd0 7c0803a6 eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 ebe1fff8 4e800020
>> 3800 7c691b78 980d0214 800d0008<7d601829> 2c0b 40c20010 7c00192d
>> Oops: Weird page fault, sig: 11 [#2]
>>
>> Pls let me know if this back trace would help in analyzing further.
>> Meanwhile I shall do a git bisect and send the inputs.
>>
>> Thanks
>> Divya
>>
>>
>>
> Hi All,
>
> From the git bisect,seems like the commit
> 57439f878afafefad8836ebf5c49da2a0a746105 is the corrupt for the above
> issue.
CC'ing Nick and Al.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
want to
> > serialize based on the list being empty or not.
>
> Leaving that one (and the next one) out for now until Jens Ack them.
You can add my acked-by, this one is trivial and a good addition.
>
> Cheers,
> Ben.
>
> > Signed-off-by: Geert Uytterhoeven
> >
uantities are unsigned, but there -is-
> truncation happening here).
Should be safe to just make it -1UL now.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
pplying patches for the next release before that
happens. I'll try to remember to pick this one up for 6.7.
--
Jens Axboe
versions.
>
> PowerPC/pseries versions of these functions provide read/write access
> to SED Opal keys in the PLPKS keystore.
>
> The SED block driver has been modified to read the SED Opal
> keystore to populate a key in the SED Opal keyring. Changes to the
> SED Opal key will be written to the SED Opal keystore.
Applied for 6.7, thanks.
--
Jens Axboe
"), I see the following crash when
> booting some distribution configurations, such as OpenSUSE's [1] (the
> rootfs is available at [2] if necessary):
I'll drop the series for now - I didn't push out the main branch just
yet as I don't publish the block next tree until at least at -rc2 time,
so it's just in a private branch for now.
--
Jens Axboe
On 10/17/23 9:09 AM, Greg Joyce wrote:
>
> Hi Jens,
>
> I've addressed all the comments/issues on v7 of the patchset and
> haven't received any feedback on v8. Is there anything else that you'd
> like to see before this can be included?
Let's give it another shot!
--
Jens Axboe
ck:sed-opal: SED Opal keystore
commit: 96ff37ceb203426b1bcebbae42399686110b0130
[2/3] block: sed-opal: keystore access for SED Opal keys
commit: 5dd339722f5f612f349b068e8da6d6710fd0e460
[3/3] powerpc/pseries: PLPKS SED Opal keystore support
commit: ec8cf230ceccfcc2bd29990c2902be168a92dee4
Best regards,
--
Jens Axboe
rigger was in no way related to where the actual bug was.
I ran this on the vm I have access to, and it survived 2x500 iterations.
Happy to call that good:
Tested-by: Jens Axboe
--
Jens Axboe
OPAL_DISCOVERY
commit: 9fb10726ecc5145550180aec4fd0adf0a7b1d634
[2/3] block: sed-opal: Implement IOC_OPAL_REVERT_LSP
commit: 5c82efc1aee8eb0919aa67a0d2559de5a326bd7c
[3/3] block: sed-opal: keyring support for SED keys
commit: 3bfeb61256643281ac4be5b8a57e9d9da3db4335
Best regards,
--
Jens Axboe
as to why you'd rebase to an old kernel rather than a 6.4-rc at
least?
Please resend one that is current.
--
Jens Axboe
from strlcpy with unused retval to strscpy
commit: e55e1b4831563e5766f88fa821f5bfac0d6c298c
Best regards,
--
Jens Axboe
based on Sean's suggestion.
>
> Signed-off-by: Christian Brauner
>
> Changes in v2:
> - further simplify helpers
> - Link to v1:
> https://lore.kernel.org/r/20230713-vfs-eventfd-signal-v1-0-7fda6c5d2...@kernel.org
Only oddity I spotted was the kerneldoc, which someone else alr
only used by bio_split_to_limits.
>
>
Applied, thanks!
[1/1] ps3vram: remove bio splitting
commit: 2192a93eb4ac63eeb37ec5ec5cfa0db92ded5e3c
Best regards,
--
Jens Axboe
owerpc? I've tried
any mix of isync()/mb and making the flush_dcache_page() unconditionally
done in the filemap read/write helpers, and it still falls flat on its
face with the offload to an IO thread.
I must clearly be missing something here, which is why I'm emailing the
powerpc Gods for help :-)
--
Jens Axboe
On 3/24/23 1:27?AM, Christophe Leroy wrote:
> Hi,
>
> Le 23/03/2023 ? 19:54, Jens Axboe a ?crit :
>> Hi,
>>
>> I got a report sent to me from mariadb, in where 5.10.158 works fine and
>> 5.10.162 is broken. And in fact, current 6.3-rc also fails the test
>&g
On 3/24/23 6:15 PM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 3/24/23 1:27?AM, Christophe Leroy wrote:
>>> Le 23/03/2023 ? 19:54, Jens Axboe a ?crit :
>>>> I got a report sent to me from mariadb, in where 5.10.158 works fine and
>>>> 5.10.162 i
On 3/24/23 6:42?PM, Michael Ellerman wrote:
> Jens Axboe writes:
>> Hi,
>
> Hi Jens,
>
> Thanks for the report.
>
>> I got a report sent to me from mariadb, in where 5.10.158 works fine and
>> 5.10.162 is broken. And in fact, current 6.3-rc also fails the
portant here,
so just pick -EINVAL.
Signed-off-by: Jens Axboe
diff --git a/arch/powerpc/kernel/ptrace/ptrace-view.c
b/arch/powerpc/kernel/ptrace/ptrace-view.c
index 2087a785f05f..80b699dd0d7f 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-view.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-view.c
On 3/26/23 10:22?PM, Nicholas Piggin wrote:
> On Sat Mar 25, 2023 at 11:20 AM AEST, Jens Axboe wrote:
>> On 3/24/23 7:15?PM, Jens Axboe wrote:
>>>> Are there any CONFIG options I'd need to trip this?
>>>
>>> I don't think you need any special CONF
On 3/27/23 12:36?AM, Nicholas Piggin wrote:
> On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>> from my (arguably very short) checking is not commonly done for other
>> archs. This is fine, excep
On 3/27/23 7:54?AM, Michael Ellerman wrote:
> "Nicholas Piggin" writes:
>> On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
>>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>>> from my (arguably very short) checking is not commo
hatever CPU they got created on seemingly
fixes the issue too. This does not mean that each worker will process
work on the CPU on which it was queued, just that each worker will
remain on whatever CPU it originally got created on.
Puzzling...
Note that it is indeed quite possible that this isn't a ppc issue at
all, just shows on ppc. It could be page cache related, or it could even
be a bug in mariadb itself.
--
Jens Axboe
On 3/28/23 5:32?AM, Michael Ellerman wrote:
> Jens Axboe writes:
>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>> from my (arguably very short) checking is not commonly done for other
>> archs. This is fine, except when PF_IO_WORKER's have be
On 3/28/23 6:51?AM, Michael Ellerman wrote:
> Jens Axboe writes:
>>>> Can the queueing cause the creation of an IO thread (if one does not
>>>> exist, or all blocked?)
>>>
>>> Yep
>>>
>>> Since writing this email, I've gone th
ack_r, false);
+ iov_r = iovec_from_user(rvec, riovcnt, UIO_FASTIOV, iovstack_r,
+ in_compat_syscall());
if (IS_ERR(iov_r)) {
rc = PTR_ERR(iov_r);
goto free_iov_l;
--
Jens Axboe
On 10/26/20 6:05 PM, Al Viro wrote:
> On Mon, Oct 26, 2020 at 05:56:11PM -0600, Jens Axboe wrote:
>> On 10/26/20 4:55 PM, Kyle Huey wrote:
>>> A test program from the rr[0] test suite, vm_readv_writev[1], no
>>> longer works on 5.10-rc1 when compiled as a 32 bit binary a
Wire up TIF_NOTIFY_SIGNAL handling for powerpc.
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jens Axboe
---
5.11 has support queued up for TIF_NOTIFY_SIGNAL, see this posting
for details:
https://lore.kernel.org/io-uring/20201026203230.386348-1-ax...@kernel.dk/
As part of that work, I&#
On 10/29/20 6:48 PM, Michael Ellerman wrote:
> Jens Axboe writes:
>> Wire up TIF_NOTIFY_SIGNAL handling for powerpc.
>>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Jens Axboe
>> ---
>>
>> 5.11 has support queued up for TIF_NOTIFY_SIGNAL,
ers/cdrom/viocd.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Jens, can this go in through the powerpc tree?
Certainly
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
2fa0 409e0018 7caa4215
> 396b0001 418200cc 424000b8 4bdc <79691f24> 7d296214 e9690018 2fab
It's odd stuff. Could you perhaps try and add some printks to
block/cfq-iosched.c:call_for_each_cic(), like dumping the 'nr' return
from radix_tree_gang_lookup() a
On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> On Sun, 17 Feb 2008 20:29:13 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > It's odd stuff. Could you perhaps try and add some printks to
> > block/cfq-iosched.c:call_for_each_cic(), like dumping the 'nr&#x
On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> On Tue, 19 Feb 2008 09:58:38 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
> > > when I inserted printk here
> > > ==
> > > for (i = 0; i < nr; i++)
> > > func(ioc, cics[i]);
> > &g
On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> On Tue, 19 Feb 2008 09:36:34 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> > > On Sun, 17 Feb 2008 20:29:13 +0100
> > > Jens Axboe <[EMAIL PROTECTED]>
On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> On Tue, 19 Feb 2008 09:36:34 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> > > On Sun, 17 Feb 2008 20:29:13 +0100
> > > Jens Axboe <[EMAIL PROTECTED]>
On Thu, Feb 21 2008, Andrew Morton wrote:
> On Tue, 19 Feb 2008 09:36:34 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > But I think the radix 'scan over entire tree' is a bit fragile.
>
> eek, it had better not be. Was this an error in the caller? Hope so.
2007 -0700
> Merge branch 'upstream-linus' of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
>
> > git log drivers/scsi/scsi_lib.c
> commit a3bec5c5aea0da263111c4d8f8eabc1f8560d7bf
> Author: Jens Axboe <[EMAIL PROTECTED]>
iniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2':
> drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has
> no member named 'page'
Thanks a lot Olof, applied both fixups!
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
c: In function 'ehca_set_pagebuf_user2':
> drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has
> no member named 'page'
>
>
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
>
>
> ---
>
> On Tue,
/asm/dma-mapping.h: In function 'dma_sync_sg_for_cpu':
> include/asm/dma-mapping.h:331: error: 'struct scatterlist' has no member
> named 'page'
>
> drivers/scsi/ps3rom.c: In function 'fetch_to_dev_buffer':
> drivers/scsi/ps3rom.c:150: error
On Tue, Oct 23 2007, Dale Farnsworth wrote:
>
> Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
> ---
> include/asm-powerpc/dma-mapping.h | 10 +-
> 1 files changed, 5 insertions(+), 5 deletions(-)
Should already be merged in Linus' cur
t, can you resend the
> parts that didn't already get fixed?
>
> As is, the patch won't apply for me, since it touches many different parts
> and some of them are fixed.
Looks like just the mmc and xtensa bits, I've merged those up.
--
Jens Axboe
x27;s hardly readable (taken with my
> crappy cell phone)
I lost track - which kernel are you booting? This looks like something
that should be fixed, did you try 2.6.24-rc1?
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Wed, Oct 24 2007, Johannes Berg wrote:
> On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote:
>
> > I lost track - which kernel are you booting? This looks like something
> > that should be fixed, did you try 2.6.24-rc1?
>
> No, it came out after I pulled, I was on v2.
patch to Philip, as he's the one who pointed
> out to me what the fix is.
Oops, added for swift inclusion.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
is to exclude the
> non-userspace-visible contents of bsg.h with #ifdef CONFIG_BLOCK, not
> to declare things that we've tried to make sure specifically aren't
> declared.
I agree, I'll pass your fix on.
--
Jens Axboe
___
Linux
queue_dma_alignment(queue, dev->blk_size-1);
> blk_queue_hardsect_size(queue, dev->blk_size);
>
> - blk_queue_issue_flush_fn(queue, ps3disk_issue_flush);
> blk_queue_ordered(queue, QUEUE_ORDERED_DRAIN_FLUSH,
> ps3disk_prepare_flush);
Thanks! The patch is corr
gister_blkdev(ace_major, "xsysace");
> > > + err_blk:
> >
> > labels should be indented zero or one space, but not more.
>
> scripts/Lindent does this. Originally, I *didn't* have my labels
> indented. :-) Does Lind
On Tue, Oct 02 2007, Benjamin Herrenschmidt wrote:
>
> On Mon, 2007-10-01 at 13:59 +0200, Jens Axboe wrote:
> > On Sun, Sep 30 2007, Grant Likely wrote:
> > > On 9/30/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > > > On Sun, Sep 30, 2007
On Wed, Oct 03 2007, Grant Likely wrote:
> Jens,
>
> Here are some more Sysace patches based on comments received on the
> first series and a run through sparse. Can you please queue them up
> for 2.6.24?
Applied all 3, looked fine to me.
the detection of the CD/DVD/BD-ROM driver,
> The others are triggered by me running hdparm.
>
> Was this intentional?
Nope, not intential to me at least. I'll check up on it.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
gt; drivers/char/viocons.c |2 +-
> drivers/char/viotape.c |2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> Jens, I assume that this is trivial enough that it can be sent via the
> powerpc tree.
Of course :-)
--
Jens Axboe
e_cpus':
> arch/powerpc/kernel/machine_kexec_64.c:175: error: too many arguments to
> function 'smp_call_function'
>
> I applied the patch below.
Thanks Stephen, I've verified that the patch is correct!
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
1 - 100 of 172 matches
Mail list logo
