On 2021/1/15 16:50, kernel test robot wrote:
Hi Kefeng,
First bad commit (maybe != root cause):
Hi, the commit in patchset[1], which make riscv random build happier,
won't lead to the following problem.
I think the driver should fix the sparse error.
[1] https://lkml.org/lkml/2020/5/10/
On Fri, May 15, 2020 at 12:00:26PM -0700, Matthew Wilcox wrote:
> On Sat, May 16, 2020 at 02:20:38AM +0800, kbuild test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > head: 051e6b7e34b9bd24f46725f74994a4d3a653966e
> > commit: 06e85c7e9a
On Sat, May 16, 2020 at 02:20:38AM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 051e6b7e34b9bd24f46725f74994a4d3a653966e
> commit: 06e85c7e9a1c1356038936566fc23f7c0d363b96 asm-generic: fix unistd_32.h
> generation
On Tue, May 9, 2017 at 2:32 AM, kbuild test robot
wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 2d3e4866dea96b0506395b47bfefb234f2088dac
> commit: beba3a20bf90ce1b93e24592c3ebf0d0bb581bbe x86: switch to RAW_COPY_USER
> date: 6 weeks ago
>
On Fri, Oct 4, 2013 at 5:18 AM, Ewan Milne wrote:
> On Thu, 2013-10-03 at 13:48 -0700, Eric Seppanen wrote:
>> Do I/O timeouts and flush timeouts need to be independently adjusted?
>> If you're having trouble with slow operations, it seems likely to be
>> across the board.
>>
>> Flush timeout coul
x-kernel@vger.kernel.org;
> > de...@linuxdriverproject.org;
> > linux-s...@vger.kernel.org
> > Subject: Re: Drivers: scsi: FLUSH timeout
> >
> > On Thu, Oct 3, 2013 at 5:09 AM, Nicholas A. Bellinger
> > wrote:
> > >
> > > On Wed, 2013-10-02 at 18:29 +,
> -Original Message-
> From: Eric Seppanen [mailto:e...@purestorage.com]
> Sent: Thursday, October 03, 2013 1:49 PM
> To: Nicholas A. Bellinger
> Cc: KY Srinivasan; linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> linux-s...@vger.kernel.org
> Subje
On Thu, 2013-10-03 at 13:48 -0700, Eric Seppanen wrote:
> On Thu, Oct 3, 2013 at 5:09 AM, Nicholas A. Bellinger
> wrote:
> >
> > On Wed, 2013-10-02 at 18:29 +, KY Srinivasan wrote:
> > > Ideally, I want this to be adjustable like the way we can change the I/O
> > > timeout.
> > > Since that h
On Thu, Oct 3, 2013 at 5:09 AM, Nicholas A. Bellinger
wrote:
>
> On Wed, 2013-10-02 at 18:29 +, KY Srinivasan wrote:
> > Ideally, I want this to be adjustable like the way we can change the I/O
> > timeout.
> > Since that has been attempted earlier and rejected (not clear what the
> > reason
; oher...@suse.com;
> jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org
> Subject: Re: Drivers: scsi: FLUSH timeout
>
> On Wed, 2013-10-02 at 18:29 +, KY Srinivasan wrote:
> >
> > > -Original Message-
> > > From: geert.uytterh
Srinivasan
> > Cc: Mike Christie; Jack Wang; Greg KH; linux-kernel@vger.kernel.org;
> > de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com;
> > h...@infradead.org; linux-s...@vger.kernel.org
> > Subject: Re: Drivers: scsi: FLUSH timeout
> >
> &g
Srinivasan
> > Cc: Mike Christie; Jack Wang; Greg KH; linux-kernel@vger.kernel.org;
> > de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com;
> > h...@infradead.org; linux-s...@vger.kernel.org
> > Subject: Re: Drivers: scsi: FLUSH timeout
> >
> &g
r.kernel.org;
> de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com;
> h...@infradead.org; linux-s...@vger.kernel.org
> Subject: Re: Drivers: scsi: FLUSH timeout
>
> On Tue, Sep 24, 2013 at 11:53 PM, KY Srinivasan wrote:
> > I am not sure how that magic number was arrived
On Tue, Sep 24, 2013 at 11:53 PM, KY Srinivasan wrote:
> I am not sure how that magic number was arrived at (the 60HZ number). We want
> this to be little higher -
"60 * HZ" means "60 seconds".
> would there be any issues raising this to say 180 seconds. This is the value
> we currently have
parallels.com;
> h...@infradead.org; linux-s...@vger.kernel.org
> Subject: Re: Drivers: scsi: FLUSH timeout
>
> On 09/24/2013 07:35 AM, KY Srinivasan wrote:
> >
> >
> >> -Original Message-
> >> From: Jack Wang [mailto:xjtu...@gmail.com]
> >> Sent: Tuesda
ct.org;
>> oher...@suse.com; jbottom...@parallels.com; h...@infradead.org; linux-
>> s...@vger.kernel.org; Mike Christie
>> Subject: Re: Drivers: scsi: FLUSH timeout
>>
>> On 09/21/2013 07:24 AM, KY Srinivasan wrote:
>>>
>>>
>>>> ---
...@infradead.org; linux-
s...@vger.kernel.org; Mike Christie
Subject: Re: Drivers: scsi: FLUSH timeout
On 09/21/2013 07:24 AM, KY Srinivasan wrote:
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: Friday, September 20, 2013 1:32 PM
To: KY Srinivasan
Cc: linux
ad.org; linux-
> s...@vger.kernel.org; Mike Christie
> Subject: Re: Drivers: scsi: FLUSH timeout
>
> On 09/21/2013 07:24 AM, KY Srinivasan wrote:
> >
> >
> >> -Original Message-
> >> From: Greg KH [mailto:gre...@linuxfoundation.org]
> >> Sent: Fri
ct.org;
>> oher...@suse.com; jbottom...@parallels.com; h...@infradead.org; linux-
>> s...@vger.kernel.org
>> Subject: Re: Drivers: scsi: FLUSH timeout
>>
>> On Fri, Sep 20, 2013 at 12:32:27PM -0700, K. Y. Srinivasan wrote:
>>> The SD_FLUSH_TIMEOUT value is curr
ad.org; linux-
> s...@vger.kernel.org
> Subject: Re: Drivers: scsi: FLUSH timeout
>
> On Fri, Sep 20, 2013 at 12:32:27PM -0700, K. Y. Srinivasan wrote:
> > The SD_FLUSH_TIMEOUT value is currently hardcoded.
>
> Hardcoded where? Please, more context.
This is defined in scsi/sd.h:
I am thinking Srini meant in the sd_mod driver module.
#define SD_FLUSH_TIMEOUT (60 * HZ)
Laurence
On Fri, Sep 20, 2013 at 4:32 PM, Greg KH wrote:
> On Fri, Sep 20, 2013 at 12:32:27PM -0700, K. Y. Srinivasan wrote:
>> The SD_FLUSH_TIMEOUT value is currently hardcoded.
>
> Hardcoded where? Plea
On Fri, Sep 20, 2013 at 12:32:27PM -0700, K. Y. Srinivasan wrote:
> The SD_FLUSH_TIMEOUT value is currently hardcoded.
Hardcoded where? Please, more context.
> On our cloud, we sometimes hit this timeout. I was wondering if we
> could make this a module parameter. If this is acceptable, I can se
h...@infradead.org; linux-
> s...@vger.kernel.org
> Subject: Re: Drivers: scsi
>
> On Sat, 2012-11-03 at 09:40 -0700, K. Y. Srinivasan wrote:
> > Do we currently support dynamic re-sizing of LUNs. Hyper-V can
> > notify capacity change via sense data and I was wondering if th
On Sat, 2012-11-03 at 09:40 -0700, K. Y. Srinivasan wrote:
> Do we currently support dynamic re-sizing of LUNs. Hyper-V can
> notify capacity change via sense data and I was wondering if this
> is handled in the generic scsi code.
Depends what you mean by "dynamic". Experience shows that most use
h...@infradead.org; linux-
> s...@vger.kernel.org
> Subject: Re: Drivers: scsi
>
> On Wed, 2012-10-24 at 09:25 -0700, K. Y. Srinivasan wrote:
> > When the low level driver returns SCSI_MLQUEUE_DEVICE_BUSY,
> > how is the command retried; I suspect the retry is done after so
On Wed, 2012-10-24 at 09:25 -0700, K. Y. Srinivasan wrote:
> When the low level driver returns SCSI_MLQUEUE_DEVICE_BUSY,
> how is the command retried; I suspect the retry is done after some delay.
Delay depends mainly on I/O pressure and the unplug timer in the block
layer.
> Is this delay progra
Matthew Wilcox wrote:
> On Wed, Aug 22, 2007 at 06:15:14PM +0200, Gabriel C wrote:
>> advansys.c:(.init.text+0x38ea): undefined reference to `isa_register_driver'
>> I guess advansys_{init,exit} is missing some #ifdef's ..
>
> That's one conclusion. I prefer to think that the ISA support should
>
On Wed, Aug 22, 2007 at 06:15:14PM +0200, Gabriel C wrote:
> advansys.c:(.init.text+0x38ea): undefined reference to `isa_register_driver'
> I guess advansys_{init,exit} is missing some #ifdef's ..
That's one conclusion. I prefer to think that the ISA support should
behave the same as the PCI and
Matthew Wilcox wrote:
> On Sun, Jul 22, 2007 at 03:52:21PM +0200, Gabriel C wrote:
>> drivers/scsi/sym53c416.c: In function 'sym53c416_detect':
>> drivers/scsi/sym53c416.c:638: warning: the address of 'sym53c416' will
>> always evaluate as 'true'
>> drivers/scsi/sym53c416.c:644: warning: the addre
On Sun, Jul 22, 2007 at 03:52:21PM +0200, Gabriel C wrote:
> drivers/scsi/sym53c416.c: In function 'sym53c416_detect':
> drivers/scsi/sym53c416.c:638: warning: the address of 'sym53c416' will always
> evaluate as 'true'
> drivers/scsi/sym53c416.c:644: warning: the address of 'sym53c416_1' will
>
30 matches
Mail list logo
