[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)



On Mon, Jul 10, 2023 at 4:14 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
> Hi all,
>
> I don't have much idea on firmware, so I don't know if firmware update
> is possible
> for that system.
>
> @Huacai, is it acceptable to revert MRRS/MPS workaround patch all MIPS based
> Loongson system? Or leave a cmdline option to configure workaround type?
Contact the machine provider to get new firmwares?

Huacai
>
> Thanks
> - Jiaxun
>
> 在 2023/7/8 18:11, Aurelien Jarno 写道:
> > Hi,
> >
> > On 2023-06-24 11:46, Aurelien Jarno wrote:
> >> Hi,
> >>
> >> On 2023-06-19 09:37, Huacai Chen wrote:
> >>> On Sun, Jun 18, 2023 at 5:24 PM Aurelien Jarno <aurel32@debian.org> wrote:
> >>>> Hi,
> >>>>
> >>>> On 2023-05-07 19:22, Jiaxun Yang wrote:
> >>>>>
> >>>>>> 2023年5月6日 01:58,YunQiang Su <wzssyqa@gmail.com> 写道:
> >>>>>>
> >>>>>> Aurelien Jarno <aurel32@debian.org> 于2023年5月6日周六 04:30写道:
> >>>>>>> Source: linux
> >>>>>>> Version: 5.10.178-3
> >>>>>>> Severity: important
> >>>>>>> X-Debbugs-Cc: dsa@debian.org, debian-mips@lists.debian.org, syq@debian.org
> >>>>>>>
> >>>>>>> Following the point release, the buildd mipsel-osuosl-03.d.o does not
> >>>>>>> boot anymore, with errors in the AHCI controller:
> >>>>>>>
> >>>>>>> [   35.912147] ata4.00: exception Emask 0x0 SAct 0x20000000 SErr 0x0 action 0x6 frozen
> >>>>>>> [   35.919769] ata4.00: failed command: WRITE FPDMA QUEUED
> >>>>>>> [   35.924968] ata4.00: cmd 61/20:e8:00:f0:e1/00:00:00:00:00/40 tag 29 ncq dma 16384 out
> >>>>>>> [   35.924968]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> >>>>>>> [   35.940097] ata4.00: status: { DRDY }
> >>>>>>> [   35.943743] ata4: hard resetting link
> >>>>>>>
> >>>>>>> While that initially looks like a hardware issue, it appears that
> >>>>>>> reverting the kernel to 5.10.162-1 (from 5.10.178-3) fixes the issue.
> >>>>>>> Strangely mipsel.osuosl-05.d.o, which seems to be similar hardware (CPU,
> >>>>>>> motherboard and SATA drive), does not exhibit the same issue.
> >>>>>>>
> >>>>>> Maybe the different firmwares are used for them...
> >>>>>> CCed Huacai and Jiaxun.
> >>>>> I’m unable to reproduce on my side. Perhaps different hardware.
> >>>>> Is it possible to bisect Kernel on that machine to see of reverting that two commits do help?
> >>>> I have bisected the issue and I confirm the intuition from Cyril. The
> >>>> first bad commit is 654ae539254d10042869fdc77ad04c09e7eff1fd. Reverting
> >>>> both commits (they are linked) indeed fixes the issue.
> >>> Seems a firmware bug, latest firmware should configure a suitable MRRS.
> >> Ok, thanks for the feedback. Given it's not a kernel bug, I am closing
> >> it.
> >>
> >> That said, can someone please send us the procedure to upgrade the
> >> firmware on this machine, so that we can continue using it as a buildd?
> > Any news about that? We need to be able to run the latest stable kernel
> > on the build daemon.
> >
> > Thanks,
> > Aurelien
> >
>


Reply to: