9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] nvme driver crashy on a shitty OEM drive
@ 2021-07-21  1:23 Lucas Francesco
  2021-07-21  7:57 ` hiro
  2021-07-21 16:43 ` cinap_lenrek
  0 siblings, 2 replies; 4+ messages in thread
From: Lucas Francesco @ 2021-07-21  1:23 UTC (permalink / raw)
  To: 9front

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

sup,

last week I bought a computer from lenovo
(http://sysinfo.9front.org/src/393/body), it's a "gamer" one because I
had huge a discount for that specific model, it came with an nvme
drive, long story short, 9front nvme driver stalls with it, and lenovo
ships a "broken"  controller SMI SM2262, this controller seems to be
so broken that it had multiple issues recorded on linux (eg
https://bugzilla.kernel.org/show_bug.cgi?id=202055), unfortunately
this nvme drive is shipped on almost all units of this model and  it
seems to be in some other lenovo laptop models here in south america
too

I was able to install 9front anyway(on another nvme, a decent one from
western digital), because somehow if I boot using an usb->sata adapter
to boot 9front communityvsinfra release iso I end up with a non-frozen
system, although the nvme driver does error there too, but it doesn't
crash. I can consistently boot 9front if I have hyperthreading on and
use the usb adapter just as a bootloader.

I found out that disabling/not building the sdnvme would make the
system boot fine from another nvme drive directly, so it was surely
related to the nvme driver, and even then I got the ahci and acpi
errors so that part seemed unrelated(I tried disabling acpi too).

so, after a lot of print statements I've found that the last message I
could print before the hang is around
http://code.9front.org/hg/plan9front/file/tip/sys/src/9/pc/sdnvme.c#l452

I'm clueless as to what I should do from this part onwards or what the
qcmd does. need help.

uramekus.

[-- Attachment #2: lspcidump --]
[-- Type: application/octet-stream, Size: 20947 bytes --]

[-- Attachment #3: dmesglog --]
[-- Type: application/octet-stream, Size: 89844 bytes --]

[-- Attachment #4: resultimage.jpg --]
[-- Type: image/jpeg, Size: 176318 bytes --]

[-- Attachment #5: debug.jpg --]
[-- Type: image/jpeg, Size: 194374 bytes --]

[-- Attachment #6: externaldisk.jpg --]
[-- Type: image/jpeg, Size: 117247 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9front] nvme driver crashy on a shitty OEM drive
  2021-07-21  1:23 [9front] nvme driver crashy on a shitty OEM drive Lucas Francesco
@ 2021-07-21  7:57 ` hiro
  2021-07-21 16:43 ` cinap_lenrek
  1 sibling, 0 replies; 4+ messages in thread
From: hiro @ 2021-07-21  7:57 UTC (permalink / raw)
  To: 9front

> I found out that disabling/not building the sdnvme would make the
> system boot fine from another nvme drive directly, so it was surely

how is that possible? is that nvme drive actually using sata secretly?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9front] nvme driver crashy on a shitty OEM drive
  2021-07-21  1:23 [9front] nvme driver crashy on a shitty OEM drive Lucas Francesco
  2021-07-21  7:57 ` hiro
@ 2021-07-21 16:43 ` cinap_lenrek
  2021-07-21 17:38   ` hiro
  1 sibling, 1 reply; 4+ messages in thread
From: cinap_lenrek @ 2021-07-21 16:43 UTC (permalink / raw)
  To: 9front

that linux thread hints on some physical layer issues... they'r trying
to reset the whole pci bus to force it to recover and tuning some timing
delay loops...

we do not have a pci error handler except generic machine check
handler, so we might just freeze up instead of seeing the errors
linux prints.

it is really odd, especially as it starts to not hang when you
boot with usb disk inserted.

it might well be a timing dependency right there.

for one, i'd suggest to take the ahci out of the equation by setting
*noahci=1 in 9boot > prompt before booting the kernel.

then maybe take a look at the linux quirk routine in detail.
(i have not dont yet).

--
cinap

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9front] nvme driver crashy on a shitty OEM drive
  2021-07-21 16:43 ` cinap_lenrek
@ 2021-07-21 17:38   ` hiro
  0 siblings, 0 replies; 4+ messages in thread
From: hiro @ 2021-07-21 17:38 UTC (permalink / raw)
  To: 9front

i generally wouldn't bother trying to understand linux quirks too
hard, they are often stupid and wrong, too.

i had problems with some nvme drives out of the box from the vendor on
the lenovo thinkcentre, and it didn't go away until today with an
up-to-date ubuntu either.

replacing the nvme drive to another brand clearly changes the
frequency of my pcie bus crashing the system.

you'll have to do it yourself. linux is misleading.

On 7/21/21, cinap_lenrek@felloff.net <cinap_lenrek@felloff.net> wrote:
> that linux thread hints on some physical layer issues... they'r trying
> to reset the whole pci bus to force it to recover and tuning some timing
> delay loops...
>
> we do not have a pci error handler except generic machine check
> handler, so we might just freeze up instead of seeing the errors
> linux prints.
>
> it is really odd, especially as it starts to not hang when you
> boot with usb disk inserted.
>
> it might well be a timing dependency right there.
>
> for one, i'd suggest to take the ahci out of the equation by setting
> *noahci=1 in 9boot > prompt before booting the kernel.
>
> then maybe take a look at the linux quirk routine in detail.
> (i have not dont yet).
>
> --
> cinap
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-07-21 17:44 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-21  1:23 [9front] nvme driver crashy on a shitty OEM drive Lucas Francesco
2021-07-21  7:57 ` hiro
2021-07-21 16:43 ` cinap_lenrek
2021-07-21 17:38   ` hiro

9front - general discussion about 9front

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/9front

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9front 9front/ http://inbox.vuxu.org/9front \
		9front@9front.org
	public-inbox-index 9front

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9front


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git