Michael.
Michael Schmitz - 01.07.18, 04:43:
> Am 30.06.18 um 19:49 schrieb Martin Steigerwald:
> > I am really inclined to point some AmigaOS 4 developers to this
> > discussion and just looked for an archive. Unfortunately there does
> > not appear to be a working o
jdow - 30.06.18, 08:47:
> Let's get everybody:
>
> On 20180629 22:26, Michael Schmitz wrote:
> > Joanne,
> >
> > Am 30.06.18 um 15:56 schrieb jdow:
> > As far as I can guess from the code, pb_Environment[3] (number
> > of
>
> heads)
>
> > and
Michael. Joanne.
I do think this discussion is slightly getting out of hand… so I suggest
to focus on what its up to the kernel to do and what is not. And to
focus only on what is up to the RDB parser, cause the patch is on
changing that. The RDB parser is not responsible for what any file
Whoa, my summary essay triggered digging even more accurately into that
matter. For some obscure reason I am even enjoying this. :)
jdow - 30.06.18, 05:56:
> On 20180629 18:31, Michael Schmitz wrote:> Joanne,
>
> > Am 30.06.18 um 12:57 schrieb jdow:
> >> On 20180629 17:44, Michael Schmitz
Beware: Essay ahead which proofs it to the point that there is no
overflow in RDB before 96 bits maximum value of sectors:
jdow - 29.06.18, 11:32:
> On 20180629 01:42, Michael Schmitz wrote:
> > Hi Geert,
> >
> > Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
> Do we really need the
Hi Michael.
Michael Schmitz - 29.06.18, 11:07:
> > But it's up to the person (which is not Linux) formatting the disk
> > to
> > not try to use
> > it on systems that cannot handle it, and may destroy it.
> >
> >>> Let me clarify: what exactly would the kernel option allow? When
> >>> to use
Hi,
Geert Uytterhoeven - 29.06.18, 10:51:
> On Fri, Jun 29, 2018 at 10:43 AM Michael Schmitz
wrote:
> > Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
> > >>> Do we really need the warning?
> > >>> Once the parsing is fixed doing 64-bit math, it does not matter
> > >>> for
> > >>> Linux
Hi Michael.
Michael Schmitz - 29.06.18, 10:42:
> Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
> >>> Do we really need the warning?
> >>> Once the parsing is fixed doing 64-bit math, it does not matter
> >>> for
> >>> Linux anymore.
> >>
> >> Well, irony of this is: In my case the RDB has
Hi Michael.
Probably I was right with not submitting a patch myself. I´d likely
would have been overwhelmed by the discussion and feedback :)
Michael Schmitz - 28.06.18, 06:58:
[…]
> >> In the interest of least surprises, we have to fix the 32 bit
> >> overflow (so we can even detect that it
Hi Geert.
Geert Uytterhoeven - 28.06.18, 08:45:
> On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz
wrote:
> > Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> > >>> And as stated in my other reply to the patch:
> > >>> partition needs 64 bit di
Hi Michael.
Michael Schmitz - 27.06.18, 22:13:
> On Wed, Jun 27, 2018 at 8:24 PM, Martin Steigerwald
wrote:
> > Thanks a lot again for your patch.
> >
> > schmitz...@gmail.com - 27.06.18, 03:24:
> >> + if (start_sect &
Thanks a lot again for your patch.
schmitz...@gmail.com - 27.06.18, 03:24:
> + if (start_sect > INT_MAX || nr_sects > INT_MAX
> + || (start_sect + nr_sects) > INT_MAX) {
> + pr_err("%s: Warning: RDB partition
> overflow!\n", +
for sector address and size (as expected by
> put_partition) to allow using such disks without danger of data
> corruption.
>
> This bug was reported originally in 2012 by Martin Steigerwald
> , and the fix was created by the RDB author,
> Joanne Dow . The patch had been di
Hello Ming.
Ming Lei - 18.04.18, 18:46:
> On Mon, Apr 16, 2018 at 03:12:30PM +0200, Martin Steigerwald wrote:
> > Ming Lei - 16.04.18, 02:45:
> > > On Sun, Apr 15, 2018 at 06:31:44PM +0200, Martin Steigerwald
wrote:
> > > > Hi Ming.
> > > >
> > &
Hi Jianchao.
jianchao.wang - 17.04.18, 16:34:
> On 04/17/2018 08:10 PM, Martin Steigerwald wrote:
> > For testing it I add it to 4.16.2 with the patches I have already?
>
> You could try to only apply this patch to have a test. :)
I tested 4.16.3 with just your patch (+ the
Hi Jianchao.
jianchao.wang - 17.04.18, 16:34:
> On 04/17/2018 08:10 PM, Martin Steigerwald wrote:
> > For testing it I add it to 4.16.2 with the patches I have already?
>
> You could try to only apply this patch to have a test.
Compiling now to have a test.
Thanks,
--
Martin
m>
> Cc: Tejun Heo <t...@kernel.org>
> Cc: Ming Lei <ming@redhat.com>
> Cc: Martin Steigerwald <mar...@lichtvoll.de>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jianchao Wang <jianchao.w.w...@oracle.com>
> ---
> block/blk-core.c | 4
> bloc
Ming Lei - 16.04.18, 02:45:
> On Sun, Apr 15, 2018 at 06:31:44PM +0200, Martin Steigerwald wrote:
> > Hi Ming.
> >
> > Ming Lei - 15.04.18, 17:43:
> > > Hi Jens,
> > >
> > > This two patches fixes the recently discussed race betwe
Hi Ming.
Ming Lei - 15.04.18, 17:43:
> Hi Jens,
>
> This two patches fixes the recently discussed race between completion
> and BLK_EH_RESET_TIMER.
>
> Israel & Martin, this one is a simpler fix on this issue and can
> cover the potencial hang of MQ_RQ_COMPLETE_IN_TIMEOUT request, could
> you
est handover between normal and
> > timeout paths, we'd need something similar. Otherwise, while we can
> > reduce the window, we can't get rid of it.
>
> (+Martin Steigerwald)
[…]
> Thank you for having shared this patch. It looks interesting to me.
> What I know about the blk-mq
Martin Steigerwald - 10.04.18, 20:43:
> Tejun Heo - 03.04.18, 00:04:
> > Request abortion is performed by overriding deadline to now and
> > scheduling timeout handling immediately. For the latter part, the
> > code was using mod_timer(timeout, 0) which can't guarantee th
Tejun Heo - 03.04.18, 00:04:
> Request abortion is performed by overriding deadline to now and
> scheduling timeout handling immediately. For the latter part, the
> code was using mod_timer(timeout, 0) which can't guarantee that the
> timer runs afterwards. Let's schedule the underlying work
Hans de Goede - 11.03.18, 15:37:
> Hi Martin,
>
> On 11-03-18 09:20, Martin Steigerwald wrote:
> > Hello.
> >
> > Since 4.16-rc4 (upgraded from 4.15.2 which worked) I have an issue
> > with SMART checks occassionally failing like this:
> >
> > smart
Ming Lei - 30.01.18, 02:24:
> > > SCSI_MQ is enabled on V3.17 firstly, but disabled at default. In
> > > V4.13-rc1, it is enabled at default, but later the patch is reverted
> > > in V4.13-rc7, and becomes disabled at default too.
> > >
> > > Now both the original reported PM issue(actually SCSI
Bart Van Assche - 10.10.17, 15:27:
> On Tue, 2017-10-10 at 09:57 +0200, Martin Steigerwald wrote:
>
> > Bart Van Assche - 09.10.17, 16:14:
> >
> > > The contexts from which a SCSI device can be quiesced or resumed are:
> > > [ ... ]
> >
&g
Bart Van Assche - 09.10.17, 16:14:
> The contexts from which a SCSI device can be quiesced or resumed are:
> * Writing into /sys/class/scsi_device/*/device/state.
> * SCSI parallel (SPI) domain validation.
> * The SCSI device power management methods. See also scsi_bus_pm_ops.
>
> It is essential
Hi Ming.
Ming Lei - 30.09.17, 14:12:
> Please consider this patchset for V4.15, and it fixes one
> kind of long-term I/O hang issue in either block legacy path
> or blk-mq.
>
> The current SCSI quiesce isn't safe and easy to trigger I/O deadlock.
Isn´t that material for -stable as well?
I´d
Ming Lei - 27.09.17, 16:27:
> On Wed, Sep 27, 2017 at 09:57:37AM +0200, Martin Steigerwald wrote:
> > Hi Ming.
> >
> > Ming Lei - 27.09.17, 13:48:
> > > Hi,
> > >
> > > The current SCSI quiesce isn't safe and easy to trigger I/O deadlock.
> >
Ming Lei - 25.09.17, 10:59:
> On Sun, Sep 24, 2017 at 07:33:00PM +0200, Martin Steigerwald wrote:
> > Ming Lei - 21.09.17, 06:17:
> > > On Wed, Sep 20, 2017 at 07:25:02PM +0200, Martin Steigerwald wrote:
> > > > Ming Lei - 28.08.17, 21:32:
> > > > > On
Ming Lei - 21.09.17, 06:17:
> On Wed, Sep 20, 2017 at 07:25:02PM +0200, Martin Steigerwald wrote:
> > Ming Lei - 28.08.17, 21:32:
> > > On Mon, Aug 28, 2017 at 03:10:35PM +0200, Martin Steigerwald wrote:
> > > > Ming Lei - 28.08.17, 20:58:
> > > >
Martin Steigerwald - 21.09.17, 09:30:
> Ming Lei - 21.09.17, 06:20:
> > On Mon, Aug 28, 2017 at 03:10:35PM +0200, Martin Steigerwald wrote:
> > > Ming Lei - 28.08.17, 20:58:
> > > > On Sun, Aug 27, 2017 at 09:43:52AM +0200, Oleksandr Natalenko wrote:
> > > &g
Ming Lei - 21.09.17, 06:20:
> On Mon, Aug 28, 2017 at 03:10:35PM +0200, Martin Steigerwald wrote:
> > Ming Lei - 28.08.17, 20:58:
> > > On Sun, Aug 27, 2017 at 09:43:52AM +0200, Oleksandr Natalenko wrote:
> > > > Hi.
> > > &g
Ming Lei - 28.08.17, 21:32:
> On Mon, Aug 28, 2017 at 03:10:35PM +0200, Martin Steigerwald wrote:
> > Ming Lei - 28.08.17, 20:58:
> > > On Sun, Aug 27, 2017 at 09:43:52AM +0200, Oleksandr Natalenko wrote:
> > > > Hi.
> > > >
> > > > Here is d
Ming Lei - 28.08.17, 20:58:
> On Sun, Aug 27, 2017 at 09:43:52AM +0200, Oleksandr Natalenko wrote:
> > Hi.
> >
> > Here is disk setup for QEMU VM:
> >
> > ===
> > [root@archmq ~]# smartctl -i /dev/sda
> > …
> > Device Model: QEMU HARDDISK
> > Serial Number:QM1
> > Firmware Version:
Wols Lists - 26.08.17, 18:17:
> On 26/08/17 12:19, Martin Steigerwald wrote:
> > Also… when a hang happened the mouse pointer was frozen, Ctrl-Alt-F1
> > didn´t
> > work and so on… so it may easily be a completely different issue.
> >
> > I did not see much point
Hello Oleksandr,
Oleksandr Natalenko - 26.08.17, 12:48:
> Quick update: reproduced on both v4.12.7 and v4.13.0-rc6.
>
> On sobota 26. srpna 2017 12:37:29 CEST Oleksandr Natalenko wrote:
[…]
> > I've re-checked this issue with 4.12.9, and it is still there.
[…]
> > On úterý 22. srpna 2017
36 matches
Mail list logo
