Hi,
On Wed, Jun 12, 2019 at 06:55:28AM +0100, Maciej W. Rozycki wrote:
> On Tue, 11 Jun 2019, Aaro Koskinen wrote:
>
> > However, with your patch the "nobody cared" is never reached so all is
> > good. I tried 10 boots with the patch and all were successful. Without
> > the patch 8 out of 10
On Tue, 11 Jun 2019, Aaro Koskinen wrote:
> However, with your patch the "nobody cared" is never reached so all is
> good. I tried 10 boots with the patch and all were successful. Without
> the patch 8 out of 10 failed with the "nobody cared" warning.
I wouldn't call it "good", just less
Hi,
On Sun, May 26, 2019 at 06:19:00AM -0300, Alexandre Oliva wrote:
> On Mar 8, 2019, "Maciej W. Rozycki" wrote:
>
> > Anyway I meant: does `war_io_reorder_wmb' expand to `wmb' on your system?
>
> No, it expands to `barrier' on the yeeloong:
>
> CONFIG_CPU_LOONGSON2F=y
>
On Mar 8, 2019, "Maciej W. Rozycki" wrote:
> Anyway I meant: does `war_io_reorder_wmb' expand to `wmb' on your system?
No, it expands to `barrier' on the yeeloong:
CONFIG_CPU_LOONGSON2F=y
CONFIG_CPU_LOONGSON2F_WORKAROUNDS=y
CONFIG_CPU_LOONGSON2=y
CONFIG_SYS_HAS_CPU_LOONGSON2F=y
I've
On Thu, 7 Mar 2019, Alexandre Oliva wrote:
> > Does your platform use `war_io_reorder_wmb'?
>
> Err... I'm not sure I understand your question.
>
> It uses it in __BUILD_IOPORT_SINGLE within the expanded out function,
> given !barrier, but you already knew that.
>
> Did you mean to ask what
On Mar 7, 2019, "Maciej W. Rozycki" wrote:
> So this seems backwards to me, port I/O is supposed to be strongly
> ordered, so if removing the ordering guarantee "fixes" your problem, then
> there must be a second bottom here.
Well, it partially restores the earlier state, so the actual bug
On Mar 7, 2019, Aaro Koskinen wrote:
> Hi,
> On Thu, Mar 07, 2019 at 03:41:01AM -0300, Alexandre Oliva wrote:
>> On Feb 17, 2019, "Maciej W. Rozycki" wrote:
>>
>> > Is there an MMIO completion barrier missing there somewhere by any chance
>> > causing an IRQ that has been handled already to
Hi,
On Thu, Mar 07, 2019 at 03:41:01AM -0300, Alexandre Oliva wrote:
> On Feb 17, 2019, "Maciej W. Rozycki" wrote:
>
> > Is there an MMIO completion barrier missing there somewhere by any chance
> > causing an IRQ that has been handled already to be redelivered because an
> > MMIO write
Hi Alexandre,
I'm away on holiday and also connectivity is so-so here, so just a quick
reply.
> > Is there an MMIO completion barrier missing there somewhere by any chance
> > causing an IRQ that has been handled already to be redelivered because an
> > MMIO write meant to clear the IRQ at
On Feb 17, 2019, "Maciej W. Rozycki" wrote:
> Is there an MMIO completion barrier missing there somewhere by any chance
> causing an IRQ that has been handled already to be redelivered because an
> MMIO write meant to clear the IRQ at its origin at handler's completion
> has not reached its
On Sun, 17 Feb 2019, Alexandre Oliva wrote:
> That's a reasonable guess, but I don't think so. I do have PATA_AMD
> enabled as a module indeed, but it's not even loaded, much as I can
> tell, whereas PATA_CS5536 is built into the kernel image, and dmesg
> says:
>
> [4.46] scsi host0:
On Feb 17, 2019, Aaro Koskinen wrote:
> I tested few older kernels, and it seems that the spurious IRQ issue has
> been always there after switching to libata (commit 7ff7a5b1bfff). It has
> been unnoticed as the 10 irq limit wasn't reached during boot.
I see, thanks. That would probably
On Sun, Feb 17, 2019 at 01:59:26AM -0300, Alexandre Oliva wrote:
> On Feb 11, 2019, Aaro Koskinen wrote:
>
> > ATA (libata) CS5536 driver is having issues with spurious IRQs and often
> > disables IRQs completely during the boot. You should see a warning
> > in dmesg. This was the reason for
On Feb 11, 2019, Aaro Koskinen wrote:
> ATA (libata) CS5536 driver is having issues with spurious IRQs and often
> disables IRQs completely during the boot. You should see a warning
> in dmesg. This was the reason for slowness on my FuLoong mini-PC. A
> workaround is to switch to old IDE driver.
On Feb 11, 2019, Tom Li wrote:
> We've just identified and confirmed the source of the shutdown problem a
> few days ago on this mailing list.
> You can pick up the patch from:
> https://lore.kernel.org/lkml/20190207205812.ga11...@darkstar.musicnaut.iki.fi/
> A patch has been authored and
On Feb 11, 2019, Aaro Koskinen wrote:
> ATA (libata) CS5536 driver is having issues with spurious IRQs and often
> disables IRQs completely during the boot. You should see a warning
> in dmesg.
Yup, thanks, it shows up first thing during boot. I hadn't seen that
one in a while. Thanks.
--
> >
> > That doesn't seem to explain even a quiet boot up taking several times
> > longer than 4.19, and package installation over an ethernet connection
> > (thus not using the console) also taking several times longer.
>
> Maybe it's a slow disk?
>
> ATA (libata) CS5536 driver is having
Hi,
On Mon, Feb 11, 2019 at 08:38:00PM -0200, Alexandre Oliva wrote:
> On Feb 11, 2019, Tom Li wrote:
> >> and, more recently, a very slow system overall, that's been present since
> >> 4.20.
>
> > The mainline framebuffer driver doesn't have any hardware drawing, printing
> > even a single
On Feb 11, 2019, Tom Li wrote:
> What is the current link to your repository?
git://dev.lemote.com/linux-loongson-community.git
I use a different git URL to push stuff, so I wouldn't have noticed if
the above was gone, but I've just tried to git clone form the above and
it seems to remain
On Mon, Feb 11, 2019 at 10:13:00AM -0200, Alexandre Oliva wrote:
> On Feb 8, 2019, Tom Li wrote:
>
> > found Alexandre Oliva has stopped maintaining his tree
>
> ?!?
>
> I still merge and tag every one of Torvalds' and Greg KH's releases into
> the loongson-community tree, resolving trivial
On Feb 8, 2019, Tom Li wrote:
> found Alexandre Oliva has stopped maintaining his tree
?!?
I still merge and tag every one of Torvalds' and Greg KH's releases into
the loongson-community tree, resolving trivial conflicts and trying to
verify that it at least builds and passes a smoke test on
Hi Tom,
On Sat, Feb 09, 2019 at 06:11:33PM +0800, Tom Li wrote:
> > To address the particular quote you give from Dmitry Torokhov on the
> > yeeloong_hotkey driver - just because the driver as-is includes a bunch
> > of non-input related things doesn't mean that it should or has to. From
> > a
> To address the particular quote you give from Dmitry Torokhov on the
> yeeloong_hotkey driver - just because the driver as-is includes a bunch
> of non-input related things doesn't mean that it should or has to. From
> a look at the 2009 submission it seems to mix a bunch of policy into the
>
Hi Tom,
On Fri, Feb 08, 2019 at 04:30:39PM +0800, Tom Li wrote:
> Hello, Greg, Ralf, Paul, James, Alexandre and Huacai
>
> Many years ago when I was still in the middle scheool, I got a Loongson
> Yeeloong laptop to explore the world of non-x86 world, as Geert Uytterhoeven
> once said, there's
Hello, Greg, Ralf, Paul, James, Alexandre and Huacai
Many years ago when I was still in the middle scheool, I got a Loongson
Yeeloong laptop to explore the world of non-x86 world, as Geert Uytterhoeven
once said, there's lots of Linux beyond IA-32. At that time I've noticed there
was no platform
25 matches
Mail list logo
