Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-09 Thread Alexandre Ratchov 
On Wed, Jun 02, 2021 at 11:15:59AM +0100, Raf Czlonka wrote:
> On Wed, Jun 02, 2021 at 09:52:36AM BST, Alexandre Ratchov wrote:
> > 
> > There's no hotplug support for audio (yet), so if you plug the USB
> > device while programs are using the internal device, you need to
> > manually tell sndiod to switch to it, ex:
> 
> Until then, hotplugd(8) seems to be working just fine for uaudio(4)
> devices, here.
> 
> The below is a stripped down version of my attach and detach scripts,
> - they differ here, BTW - but it should be enough to get it working
> on Peter's laptop.
> 
>   $ doas rcctl enable hotplugd
>   $ cat <<'EOF' | doas tee /etc/hotplug/attach /etc/hotplug/detach
>   #!/bin/sh
> 
>   DEVCLASS=$1
>   DEVNAME=$2
> 
>   case $DEVCLASS in
>   0)
>   case $DEVNAME in
>   uaudio*)
>   rcctl reload sndiod
>   ;;
>   esac
>   ;;
>   esac
>   EOF
>   $ doas rcctl start hotplugd
> 

I started using hotplugd as I tend to often swap devices. So I share
my recipe here, inspired by yours. I ended up with this script
/etc/hotplug/attach script:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#!/bin/sh   
 

DEVNAME=$2

case $DEVNAME in
audio[0-9])
sndioctl server.device=${DEVNAME#audio}
;;
esac
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

which just does what I need most of the time: whenever I plug a
device, sound goes there immediately.

I dropped the /etc/hotplug/detach script as it doesn't seem needed:

  - either the detached device is not in use and there's nothing to do

  - or the device is in use, in which case sndiod will see an
input/output error, close the device and migrate sound to another
one by itself (or disconnect clients if there's no usable device).

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-05 Thread Peter N. M. Hansteen 



On 6/4/21 11:28 PM, Peter N. M. Hansteen wrote:
> 
> 
> On 6/4/21 11:03 PM, Bryan Steele wrote:
>> It is likely what ratchov@ describes here, the microphone on these
>> newer machines is no longer internally connected to the HD Audio device,
>> but instead some new Intel "Smart Sound Technology (SST)" device.
>>
>> https://marc.info/?l=openbsd-misc=161700953329415=2
> 
> Ah, this does sound similar enough that by this time tomorrow (or
> actually a lot earlier) I will have tested a full duplex usb headset by
> Sennheiser which is available quite affordably for pickup within walking
> distance during business hours.
> 
> Thanks for your help, I'll report back when I have something, as usual :)

And I can report that this USB headset

Jun  5 14:15:53 zaida /bsd: uaudio0 at uhub1 port 1 configuration 1
interface 1 "Sennheiser Communications Sennheiser USB headset" rev
1.10/1.00 addr 4
Jun  5 14:15:53 zaida /bsd: uaudio0: class v1, full-speed, sync,
channels: 2 play, 1 rec, 8 ctls
Jun  5 14:15:53 zaida /bsd: audio1 at uaudio0
Jun  5 14:15:53 zaida /bsd: uhidev0 at uhub1 port 1 configuration 1
interface 3 "Sennheiser Communications Sennheiser USB headset" rev
1.10/1.00 addr 4
Jun  5 14:15:53 zaida /bsd: uhidev0: iclass 3/0
Jun  5 14:15:53 zaida /bsd: uhid0 at uhidev0: input=4, output=4, feature=0

works, my only nit was that the physical slider on the cable wart came
out of the package in the 'off' position and needed to be set to the
'on' position.

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-04 Thread Peter N. M. Hansteen 



On 6/4/21 11:03 PM, Bryan Steele wrote:
> It is likely what ratchov@ describes here, the microphone on these
> newer machines is no longer internally connected to the HD Audio device,
> but instead some new Intel "Smart Sound Technology (SST)" device.
> 
> https://marc.info/?l=openbsd-misc=161700953329415=2

Ah, this does sound similar enough that by this time tomorrow (or
actually a lot earlier) I will have tested a full duplex usb headset by
Sennheiser which is available quite affordably for pickup within walking
distance during business hours.

Thanks for your help, I'll report back when I have something, as usual :)

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-04 Thread Peter N. M. Hansteen 
One more oddity:
[Fri Jun 04 22:29:52] peter@zaida:~$ doas sysctl | grep record
kern.audio.record=1
kern.video.record=1
[Fri Jun 04 22:48:40] peter@zaida:~$ mixerctl -v
inputs.dac-0:1=126,126
outputs.spkr_source=dac-0:1  [ dac-0:1 ]
outputs.spkr_mute=off  [ off on ]
outputs.spkr_boost=off  [ off on ]
outputs.spkr_eapd=on  [ off on ]
outputs.master=126,126
outputs.master.mute=off  [ off on ]
outputs.master.slaves=dac-0:1,spkr  { dac-0:1 spkr }
record.enable=sysctl  [ off on sysctl ]

as in, mixerctl and sysctl disagree on whether kernel.audio.record is 0
or 1 on this machine.

Which of course explains the silent mic, but how to fix?

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-04 Thread Bryan Steele 
On Fri, Jun 04, 2021 at 10:51:47PM +0200, Peter N. M. Hansteen wrote:
> One more oddity:
> [Fri Jun 04 22:29:52] peter@zaida:~$ doas sysctl | grep record
> kern.audio.record=1
> kern.video.record=1
> [Fri Jun 04 22:48:40] peter@zaida:~$ mixerctl -v
> inputs.dac-0:1=126,126
> outputs.spkr_source=dac-0:1  [ dac-0:1 ]
> outputs.spkr_mute=off  [ off on ]
> outputs.spkr_boost=off  [ off on ]
> outputs.spkr_eapd=on  [ off on ]
> outputs.master=126,126
> outputs.master.mute=off  [ off on ]
> outputs.master.slaves=dac-0:1,spkr  { dac-0:1 spkr }
> record.enable=sysctl  [ off on sysctl ]
> 
> as in, mixerctl and sysctl disagree on whether kernel.audio.record is 0
> or 1 on this machine.
> 
> Which of course explains the silent mic, but how to fix?
> 
> All the best,
> Peter
> 
> -- 
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

No, that's not it, the mixerctl property 'record.enable' defaults to
'sysctl' which just means it defers to the global 'kern.audio.record'
setting.

https://man.openbsd.org/audio#DESCRIPTION

-Bryan.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-04 Thread Bryan Steele 
On Fri, Jun 04, 2021 at 10:06:27PM +0200, Peter N. M. Hansteen wrote:
> Further exploring the machine, trying to use the microphone it looks
> like we do not have sound input enabled:
> 
> [Fri Jun 04 22:01:28] peter@zaida:~$ doas sysctl | grep audio
> kern.audio.record=1
> 
> 
> Fri Jun 04 21:57:43] peter@zaida:~$ sndioctl input.level=1.0
> input.level: no such control
> [Fri Jun 04 21:58:05] peter@zaida:~$ man sndioctl
> [Fri Jun 04 21:58:31] peter@zaida:~$ sndioctl -d
> 032:output[0].level=0..255 (255)
> 033:output[1].level=0..255 (255)
> 034:output[0].mute=0..1 (0)
> 035:output[1].mute=0..1 (0)
> 037:server.device=0
> 036:server.device=1
> 023:chrome0.level=0..127 (127)
> 001:firefox0.level=0..127 (127)
> 011:firefox1.level=0..127 (127)
> 031:firefox2.level=0..127 (127)
> 024:vlc0.level=0..127 (108)
> 
> After enabling video recording with sysctl kern.video.record=1 the
> webcam works, but no audio input.
> 
> I may as usual be missing something obvious.
> 
> All the best,
> Peter
> 
> 
> -- 
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

It is likely what ratchov@ describes here, the microphone on these
newer machines is no longer internally connected to the HD Audio device,
but instead some new Intel "Smart Sound Technology (SST)" device.

https://marc.info/?l=openbsd-misc=161700953329415=2

-Bryan.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-02 Thread Peter N. M. Hansteen 



On 6/2/21 12:15 PM, Raf Czlonka wrote:
> On Wed, Jun 02, 2021 at 09:52:36AM BST, Alexandre Ratchov wrote:
>>
>> There's no hotplug support for audio (yet), so if you plug the USB
>> device while programs are using the internal device, you need to
>> manually tell sndiod to switch to it, ex:
> 
> Until then, hotplugd(8) seems to be working just fine for uaudio(4)
> devices, here.
> 
> The below is a stripped down version of my attach and detach scripts,
> - they differ here, BTW - but it should be enough to get it working
> on Peter's laptop.

I can confirm that this works after a simple cut to the two
scripts + chmod +x of same, followed by enabling and starting hotplugd.

Excellent, thanks!

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-02 Thread Peter N. M. Hansteen 
On 6/2/21 10:52 AM, Alexandre Ratchov wrote:
> sndiod_flags="-f rsnd/0 -F rsnd/1"

Yes, that worked. Excellent, thanks!

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-02 Thread Peter N. M. Hansteen 
Another intriguing detail - this machine does not have a headphone jack,
but comes with a USB-C to audio mini-jack adapter. When I plug in the
adapter, it is recognized

Jun  2 10:30:46 zaida /bsd: uaudio0 at uhub1 port 4 configuration 1
interface 1 "ESS Technology Asus USB DAC" rev 1.01/0.01 addr 4
Jun  2 10:30:46 zaida /bsd: uaudio0: class v1, full-speed, sync,
channels: 2 play, 1 rec, 4 ctls
Jun  2 10:30:46 zaida /bsd: audio1 at uaudio0
Jun  2 10:30:46 zaida /bsd: uhidev0 at uhub1 port 4 configuration 1
interface 3 "ESS Technology Asus USB DAC" rev 1.01/0.01 addr 4
Jun  2 10:30:46 zaida /bsd: uhidev0: iclass 3/0
Jun  2 10:30:46 zaida /bsd: uhid0 at uhidev0: input=1, output=0, feature=64

but audio output stays on the internal speaker.

Is there some (simple) tweak to enable switching audio outputs here?

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-02 Thread Alexandre Ratchov 
On Wed, Jun 02, 2021 at 11:15:59AM +0100, Raf Czlonka wrote:
> On Wed, Jun 02, 2021 at 09:52:36AM BST, Alexandre Ratchov wrote:
> > 
> > There's no hotplug support for audio (yet), so if you plug the USB
> > device while programs are using the internal device, you need to
> > manually tell sndiod to switch to it, ex:
> 
> Until then, hotplugd(8) seems to be working just fine for uaudio(4)
> devices, here.
> 
> The below is a stripped down version of my attach and detach scripts,
> - they differ here, BTW - but it should be enough to get it working
> on Peter's laptop.
> 
>   $ doas rcctl enable hotplugd
>   $ cat <<'EOF' | doas tee /etc/hotplug/attach /etc/hotplug/detach
>   #!/bin/sh
> 
>   DEVCLASS=$1
>   DEVNAME=$2
> 
>   case $DEVCLASS in
>   0)
>   case $DEVNAME in
>   uaudio*)
>   rcctl reload sndiod
>   ;;
>   esac
>   ;;
>   esac
>   EOF
>   $ doas rcctl start hotplugd
> 
> Regards,
> 

Neat. Thanks for the tip, I didn't think it could work this way!

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-02 Thread Raf Czlonka 
On Wed, Jun 02, 2021 at 09:52:36AM BST, Alexandre Ratchov wrote:
> 
> There's no hotplug support for audio (yet), so if you plug the USB
> device while programs are using the internal device, you need to
> manually tell sndiod to switch to it, ex:

Until then, hotplugd(8) seems to be working just fine for uaudio(4)
devices, here.

The below is a stripped down version of my attach and detach scripts,
- they differ here, BTW - but it should be enough to get it working
on Peter's laptop.

$ doas rcctl enable hotplugd
$ cat <<'EOF' | doas tee /etc/hotplug/attach /etc/hotplug/detach
#!/bin/sh

DEVCLASS=$1
DEVNAME=$2

case $DEVCLASS in
0)
case $DEVNAME in
uaudio*)
rcctl reload sndiod
;;
esac
;;
esac
EOF
$ doas rcctl start hotplugd

Regards,

Raf

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-02 Thread Alexandre Ratchov 
On Wed, Jun 02, 2021 at 10:38:23AM +0200, Peter N. M. Hansteen wrote:
> Another intriguing detail - this machine does not have a headphone jack,
> but comes with a USB-C to audio mini-jack adapter. When I plug in the
> adapter, it is recognized
> 
> Jun  2 10:30:46 zaida /bsd: uaudio0 at uhub1 port 4 configuration 1
> interface 1 "ESS Technology Asus USB DAC" rev 1.01/0.01 addr 4
> Jun  2 10:30:46 zaida /bsd: uaudio0: class v1, full-speed, sync,
> channels: 2 play, 1 rec, 4 ctls
> Jun  2 10:30:46 zaida /bsd: audio1 at uaudio0
> Jun  2 10:30:46 zaida /bsd: uhidev0 at uhub1 port 4 configuration 1
> interface 3 "ESS Technology Asus USB DAC" rev 1.01/0.01 addr 4
> Jun  2 10:30:46 zaida /bsd: uhidev0: iclass 3/0
> Jun  2 10:30:46 zaida /bsd: uhid0 at uhidev0: input=1, output=0, feature=64
> 
> but audio output stays on the internal speaker.
> 
> Is there some (simple) tweak to enable switching audio outputs here?
> 

Hi,

On this machine there seem to be two separate devices, with two
different drivers and with their own parameter set and their own
state. This is very different from analog headsets that only require
wires to be swapped.

You could try:

sndiod_flags="-f rsnd/0 -F rsnd/1"

This roughly means "Try to use rsnd/1 but if the latter is not there
use rsnd/0 instead".

If devices are compatible (they probably are), programs can seamlessly
be migrated from one device to another, so if you pull the USB cable,
audio should switch to internal speakers.

There's no hotplug support for audio (yet), so if you plug the USB
device while programs are using the internal device, you need to
manually tell sndiod to switch to it, ex:

sndioctl server.device=1

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-06-01 Thread Peter N. M. Hansteen 
On Tue, Jun 01, 2021 at 10:34:00AM +1000, Jonathan Gray wrote:
> > cpu0: 256KB 64b/line disabled L2 cache
> 
> the cpuid 0x8006 method of getting l2 cache information
> doesn't work here
> 
> > cpu0: smt 0, core 0, package 0
> > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 38MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
> 
> > cpu0: Enhanced SpeedStep 63762 MHz: speeds: 2701, 2700, 2600, 2500, 2300, 
> > 2100, 1900, 1700, 1600, 1400, 1200, 1100, 900, 700, 600, 400 MHz
> 
> the 8253/8254 timer on recent intel machines doesn't work as expected
> 
> that is why '63762 MHz' is claimed before tsc is used
> 
> same behaviour we saw on the earlier comet lake machines
> https://marc.info/?l=openbsd-bugs=160913944524804=2

I'll be more than happy to test stuff. As I said earlier, the machine now works
and is a lot better in almost all respects than its predecessor from 2017 (which
is still in the house but may be on its way elsewhere soon). I suspect this one
has a lot in common with what other people will be buying in the near future.

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-31 Thread Jonathan Gray 
On Mon, May 31, 2021 at 10:18:45PM +0200, Peter N. M. Hansteen wrote:
> All issues resolved with help from Bryan Steele, Jonathan Gray and
> Stefan Sperling.
> 
> dmesg, sendbug and pcidump output attached.
> 
> Thanks again for all your help!
> 
> All the best,
> Peter

> 
> OpenBSD 6.9-current (GENERIC.MP) #3: Mon May 31 21:28:27 CEST 2021
> 
> pe...@zaida.bsdly.net:/home/peter/localsrc/openbsd-src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16826920960 (16047MB)
> avail mem = 16300920832 (15545MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x5a605000 (94 entries)
> bios0: vendor American Megatrends International, LLC. version "UX393EA.302" 
> date 12/15/2020
> bios0: ASUSTeK COMPUTER INC. ZenBook UX393EA_UX393EA
> acpi0 at bios0: ACPI 6.2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP MCFG SSDT FIDT ECDT MSDM SSDT SSDT SSDT SSDT HPET 
> APIC SSDT NHLT LPIT SSDT DBGP DBG2 SSDT DMAR SSDT SSDT BGRT TPM2 PTDT WSMT 
> FPDT
> acpi0: wakeup devices PEGP(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4) XHCI(S3) 
> XDCI(S4) HDAS(S4) CNVW(S4) TXHC(S3) TDM0(S3) TRP0(S3) PXSX(S4) TRP1(S3) 
> PXSX(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xc000, bus 0-255
> acpiec0 at acpi0
> acpihpet0 at acpi0: 1920 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 63762.34 MHz, 06-8c-01
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 256KB 64b/line disabled L2 cache

the cpuid 0x8006 method of getting l2 cache information
doesn't work here

> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 38MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE

> cpu0: Enhanced SpeedStep 63762 MHz: speeds: 2701, 2700, 2600, 2500, 2300, 
> 2100, 1900, 1700, 1600, 1400, 1200, 1100, 900, 700, 600, 400 MHz

the 8253/8254 timer on recent intel machines doesn't work as expected

that is why '63762 MHz' is claimed before tsc is used

same behaviour we saw on the earlier comet lake machines
https://marc.info/?l=openbsd-bugs=160913944524804=2

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-29 Thread Jonathan Gray 
On Sat, May 29, 2021 at 05:34:50PM +0200, Peter N. M. Hansteen wrote:
> And just for completeness, git diff output follows attached along with
> fresh sendbug output.
> 
> All the best,
> Peter

moved slightly to keep it sorted

Index: sys/dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.261
diff -u -p -r1.261 azalia.c
--- sys/dev/pci/azalia.c19 May 2021 05:28:09 -  1.261
+++ sys/dev/pci/azalia.c30 May 2021 01:47:43 -
@@ -492,7 +492,8 @@ azalia_configure_pci(azalia_t *az)
 const struct pci_matchid azalia_pci_devices[] = {
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_200SERIES_U_HDA },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA },
-   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_400SERIES_CAVS }
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_400SERIES_CAVS },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_LP_HDA }
 };
 
 int

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-29 Thread Peter N. M. Hansteen 



On 5/29/21 4:25 PM, Bryan Steele wrote:
>> "Intel 500 Series HD Audio" rev 0x20 at pci0 dev 31 function 3 not configured
>> 
>>  0:31:3: Intel 500 Series HD Audio
>>  0x: Vendor ID: 8086, Product ID: a0c8
>>  0x0004: Command: , Status: 0010
>>  0x0008: Class: 04 (unknown), Subclass: 01 (unknown),
>>  Interface: 00, Revision: 20
> 
> The PCI subclass doesn't match for HD Audio so azalia(4) doesn't attach,
> subclass 01 is "vendor specific".
> 
> You could try adding something like this to azalia_pci_devices in
> azalia.c:491, it might work:
> 
>   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_LP_HDA },

That did the trick!

[Sat May 29 17:18:29] peter@zaida:~$ dmesg | grep azalia
azalia0 at pci0 dev 31 function 3 "Intel 500 Series HD Audio" rev 0x20: msi
azalia0: codecs: Realtek/0x0294, Intel/0x2812, using Realtek/0x0294
audio0 at azalia0

and I have audio, just tested with a video off nrk.no (the national
public broadcaster).

Thanks! This improves life one significant increment :)

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-29 Thread Bryan Steele 
On Sat, May 29, 2021 at 04:01:40PM +0200, Peter N. M. Hansteen wrote:

Hi,

> ...
>
> However, I have no sound at all in this laptop.
> 
> What is the most useful way forward in exploring the whys and
> contributing to fixing?
> 
> Fresh sendbug -P and pcidump -v output follows attached.
> 
> All the best,
> Peter
> 
> -- 
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

> "Intel 500 Series HD Audio" rev 0x20 at pci0 dev 31 function 3 not configured
> 
>  0:31:3: Intel 500 Series HD Audio
>   0x: Vendor ID: 8086, Product ID: a0c8
>   0x0004: Command: , Status: 0010
>   0x0008: Class: 04 (unknown), Subclass: 01 (unknown),
>   Interface: 00, Revision: 20

The PCI subclass doesn't match for HD Audio so azalia(4) doesn't attach,
subclass 01 is "vendor specific".

You could try adding something like this to azalia_pci_devices in
azalia.c:491, it might work:

  { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_LP_HDA },

-Bryan.

>   0x000c: BIST: 00, Header Type: 00, Latency Timer: 20,
>   Cache Line Size: 10
>   0x0010: BAR mem 64bit addr: 0x00603d188000/0x4000
>   0x0018: BAR empty ()
>   0x001c: BAR empty ()
>   0x0020: BAR mem 64bit addr: 0x00603d00/0x0010
>   0x0028: Cardbus CIS: 
>   0x002c: Subsystem Vendor ID: 1043 Product ID: 13e2
>   0x0030: Expansion ROM Base Address: 
>   0x0038: 
>   0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
>   0x0050: Capability 0x01: Power Management
>   State: D0
>   0x0080: Capability 0x09: Vendor Specific
>   0x0060: Capability 0x05: Message Signalled Interrupts (MSI)
>   Enabled: no
>   0x: a0c88086 0010 04010020 2010
>   0x0010: 3d188004 0060  
>   0x0020: 3d04 0060  13e21043
>   0x0030:  0050  01ff
>   0x0040:   00fb09ff 
>   0x0050: c0438001 0008  
>   0x0060: 0085   
>   0x0070: 00910010 1000 00102800 
>   0x0080: f0146009 01400010  000104a1
>   0x0090: 00280800   
>   0x00a0:    
>   0x00b0:    
>   0x00c0: 29020602 04806000 82a50c00 00030010
>   0x00d0: 02b50c00 00030010  
>   0x00e0:    
>   0x00f0:   01210fb5 
>

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-26 Thread Peter N. M. Hansteen 
On Tue, May 25, 2021 at 09:48:44PM -0400, Bryan Steele wrote:
> On Wed, May 26, 2021 at 02:51:53AM +0200, Peter N. M. Hansteen wrote:
> Intel 11th Gen "Intel Rapid Storage" device which is not supported.
> 
>   vendor "Intel", unknown product 0x09ab (class system subclass
>   miscellaneous, rev 0x00) at pci0 dev 29 function 0 not configured
> 
> There's documentation on ASUSs website about it for Windows as well.
> 
> https://www.asus.com/us/support/FAQ/1044458/
> 
> If you're lucky there may be an option in the BIOS to disable this
> and pass through the NMVe device.

You're right, there was such an option, so the installer now snees the NMVe
device. Unfortunately $DAYJOB things will eat the next few hours but I will
be back with more details when I have them, likely in the afternoon CEST.

In the meantime, thanks a lot for spotting this!

This makes it more likely than ever during the last few weeks I'll have
a *really* nice laptop for OpenBSD things soon :)

- Peter


-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-26 Thread Peter Nicolai Mathias Hansteen 


> 26. mai 2021 kl. 03:50 skrev Jonathan Gray :
> 
> On Wed, May 26, 2021 at 02:51:53AM +0200, Peter N. M. Hansteen wrote:
>> Somewhat encouraged by the last few weeks' adventure with ASUS
>> laptops (thanks, kettenis@!) I decided to try out an incrementally
>> higher range model, the Zenbook S.
>> 
>> The latest amd64 snapshot installer seemed to work fine until
>> it encountered the main storage in the unit, which the firmware
>> sees as
>> 
>> PCIE bus:0 Dev:E Func:0
>> Device type:  NVMe SSD (953.8GB)
>> Model name:   INTEL SSDOEKNV 010T8
>> 
>> But shows up in the installer kernel dmesg as only
>> 
>> sd0 at scsibus0 targ 1 lun 0: (Generic, STORAGE DEVICE, 0233), removable.
> 
> that appears to be something else on usb?
> 
> 'scsibus0 at umass0: 2 targets, initiator 0'
> from https://www.bsdly.net/~peter/20210525_233623.jpg 
> 
> 
> can you provide a dmesg and pcidump -v output?


dmesg at https://www.bsdly.net/~peter/dmesg_asus_zenbook_s_20210526a.txt 


pcidump -v https://www.bsdly.net/~peter/pcidump_-v_asus_zenbook_s_20210526a.txt 

(Which suffers from some of the same as the sendbug output in that after a 
while it appears to loop forever on an unknown capability, so I stopped it 
after reaching some 400+ megabytes)

All the best,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-26 Thread Jonathan Gray 
On Wed, May 26, 2021 at 11:50:36AM +1000, Jonathan Gray wrote:
> On Wed, May 26, 2021 at 02:51:53AM +0200, Peter N. M. Hansteen wrote:
> > Somewhat encouraged by the last few weeks' adventure with ASUS
> > laptops (thanks, kettenis@!) I decided to try out an incrementally
> > higher range model, the Zenbook S.
> > 
> > The latest amd64 snapshot installer seemed to work fine until
> > it encountered the main storage in the unit, which the firmware
> > sees as
> > 
> > PCIE bus:0 Dev:E Func:0
> >  Device type:  NVMe SSD (953.8GB)
> >  Model name:   INTEL SSDOEKNV 010T8
> > 
> > But shows up in the installer kernel dmesg as only
> > 
> > sd0 at scsibus0 targ 1 lun 0: (Generic, STORAGE DEVICE, 0233), removable.
> 
> that appears to be something else on usb?
> 
> 'scsibus0 at umass0: 2 targets, initiator 0'
> from https://www.bsdly.net/~peter/20210525_233623.jpg
> 
> can you provide a dmesg and pcidump -v output?
> 
> I didn't see an image that made it clear which cpu / inteldrm device
> this has.
> 
> > 
> > Installing to a removable USB device was a bit hit and miss, after a
> > bit of fiddling with boot -c and disable acpicpu* and disable iwx* in
> > response to the errors I got I did manage to get it to display its
> > full 3300x2200 in X, but the file system layout on the 16GB device I
> > used initially did not have space in /home to store the the entire
> > output of sendbug -P from the device.
> > 
> > The following shows the various panics and traces as best I could
> > capture them:
> > 
> > https://www.bsdly.net/~peter/20210525_223507.jpg
> > https://www.bsdly.net/~peter/20210525_223511.jpg
> > https://www.bsdly.net/~peter/20210525_233623.jpg
> > https://www.bsdly.net/~peter/20210525_235112.jpg
> 
> kernel: protection fault trap, code=0
> Stopped at pool_do_put+0xc9: movq 0x8(%rcx),%rcx
> 
> > https://www.bsdly.net/~peter/20210525_235137.jpg
> 
> kernel: protection fault trap, code=0
> pool_do_put()+0xc9 movq 0x8(%rcx),%rcx
> pool_put()+0x71
> process_zap()+0x14f
> dowait4()
> sys_wait4()
> syscall()
> 
> > https://www.bsdly.net/~peter/20210525_235449.jpg
> 
> panic: pool_do_get: procpl free list modified: ...
> db_enter()+0x10 popq %rbp
> panic()+0x12a
> pool_do_get()+0x321
> pool_get()+0x93
> fork1()+0x1b6
> syscall()+0x3b9
> 
> > https://www.bsdly.net/~peter/20210525_235502.jpg
> 
> as above with ps showing *init
> 
> > https://www.bsdly.net/~peter/20210525_235717.jpg
> 
> panic: pool_do_get: drmobj free list modified: ...
> panic: kernel diagnostic assertion "!_kernel_lock_held()" failed: file 
> "/usr/src/sys/uvm/uvm_map.c", line 2707
> db_enter()+0x10 popq %rbp
> panic()+0x12a
> __assert()+0x2b
> uvm_map_teardown()+0x23e
> uvmspace_free()+0x5a
> reaper()+0x14c
> 
> > https://www.bsdly.net/~peter/20210525_235739.jpg
> 
> as above with some ps output
> 
> > https://www.bsdly.net/~peter/20210525_235747.jpg
> 
> ps output
> 
> > https://www.bsdly.net/~peter/20210525_235753.jpg
> 
> ps output
> 
> > https://www.bsdly.net/~peter/20210525_235903.jpg
> 
> kernel: protection fault trap, code=0
> pool_do_put()+0xc9 movq 0x8(%rcx),%rcx
> pool_put()+0x71
> process_zap()+0x14f
> dowait4()+0x303
> sys_wait4()+0x5a
> syscall()+0x3b9
> 
> > https://www.bsdly.net/~peter/20210525_235914.jpg
> 
> above with ps output
> 
> > https://www.bsdly.net/~peter/20210526_015841.jpg
> 
> uvm_fault()
> kernel: page fault trap, code=0
> Stopped at i915_gem_object_pin_map+0x2a: testb $0x3,0(%rax)
> 
> > https://www.bsdly.net/~peter/20210526_015851.jpg
> 
> uvm_fault()
> kernel: page fault trap, code=0
> Stopped at i915_gem_object_pin_map+0x2a: testb $0x3,0(%rax)
> i915_gem_object_pin_map()+0x2a
> __execlists_context_alloc()+0x187
> __intel_context_do_pin()+0x15a
> i915_gem_do_execbuffer()
> i915_gem_execbuffer2_ioctl()+0x1cb
> drm_do_ioctl()+0x28c
> 
> > https://www.bsdly.net/~peter/20210526_015901.jpg
> 
> ps output *Xorg
> 
> > https://www.bsdly.net/~peter/20210526_015906.jpg
> 
> ps output
> 
> > https://www.bsdly.net/~peter/20210526_024111.jpg
> 
> uvm_fault()
> kernel: page fault trap, code=0
> Stopped at i915_gem_object_pin_map+0x2a: testb $0x3,0(%rax)
> i915_gem_object_pin_map()+0x2a
> __execlists_context_alloc()+0x187
> __intel_context_do_pin()+0x15a
> i915_gem_do_execbuffer()+0x2820
> i915_gem_execbuffer2_ioctl()+0x1cb
> drm_do_ioctl()+0x28c

some backported drm commits related to vma/pinning

drm/i915/gt: Prevent use of engine->wa_ctx after error
drm/i915: Fix mismatch between misplaced vma check and vma insert
drm/i915: Hold onto an explicit ref to i915_vma_work.pinned
drm/i915: Use the active reference on the vma while capturing

diff --git sys/dev/pci/drm/i915/gem/i915_gem_execbuffer.c 
sys/dev/pci/drm/i915/gem/i915_gem_execbuffer.c
index 971ed84f371..993c2b22f9f 100644
--- sys/dev/pci/drm/i915/gem/i915_gem_execbuffer.c
+++ sys/dev/pci/drm/i915/gem/i915_gem_execbuffer.c
@@ -365,7 +365,7 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2 
*entry,
return true;
 
if (!(flags &

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-25 Thread Peter N. M. Hansteen 
And finally I offer up 
https://www.bsdly.net/~peter/sendbug_-P_asus_zenbook_s_20210526.txt.zip

Offered here in compressed form only (and still weighing in at some 17.5M) 
since only
the first few kilobytes are likely of any value, it seems to descend into 
endless repetition
of

0x0100: Enhanced Capability 0x: Unknown

after that. Still offered in full up to the point where I Ctrl-C'd out of 
it'for completeness.

I hope this turns out userful in some way. The display itself makes me think 
this
is a keeper (if X runs without freeezing overnight that is).

All the best,
Peter


-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-25 Thread Peter N. M. Hansteen 
The sendbug under fine high resolution X still runs, here are dmesg and 
xdpyinfo output

- Peter 

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
name of display::0
version number:11.0
vendor string:The X.Org Foundation
vendor release number:1201
X.Org version: 1.20.10
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:32, LSBFirst, 32
image byte order:LSBFirst
number of supported pixmap formats:7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:minimum 8, maximum 255
focus:  window 0xcc, revert to Parent
number of extensions:28
BIG-REQUESTS
Composite
DAMAGE
DOUBLE-BUFFER
DPMS
DRI2
DRI3
GLX
Generic Event Extension
MIT-SCREEN-SAVER
MIT-SHM
Present
RANDR
RECORD
RENDER
SECURITY
SHAPE
SYNC
X-Resource
XC-MISC
XFIXES
XFree86-DGA
XFree86-VidModeExtension
XINERAMA
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number:0
number of screens:1

screen #0:
  dimensions:3300x2200 pixels (873x582 millimeters)
  resolution:96x96 dots per inch
  depths (7):24, 1, 4, 8, 15, 16, 32
  root window id:0x5d1
  depth of root window:24 planes
  number of colormaps:minimum 1, maximum 1
  default colormap:0x20
  default number of colormap cells:256
  preallocated pixels:black 0, white 16777215
  options:backing-store WHEN MAPPED, save-unders NO
  largest cursor:256x256
  current input event mask:0x58003d
KeyPressMask ButtonPressMask  ButtonReleaseMask
EnterWindowMask  LeaveWindowMask  SubstructureNotifyMask   
SubstructureRedirectMask PropertyChangeMask   
  number of visuals:450
  default visual id:  0x21
  visual:
visual id:0x21
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x22
class:DirectColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x411
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x412
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x413
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x414
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x415
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x416
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x417
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x418
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x419
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff,

ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-25 Thread Peter N. M. Hansteen 
Somewhat encouraged by the last few weeks' adventure with ASUS
laptops (thanks, kettenis@!) I decided to try out an incrementally
higher range model, the Zenbook S.

The latest amd64 snapshot installer seemed to work fine until
it encountered the main storage in the unit, which the firmware
sees as

PCIE bus:0 Dev:E Func:0
 Device type:  NVMe SSD (953.8GB)
 Model name:   INTEL SSDOEKNV 010T8

But shows up in the installer kernel dmesg as only

sd0 at scsibus0 targ 1 lun 0: (Generic, STORAGE DEVICE, 0233), removable.

Installing to a removable USB device was a bit hit and miss, after a
bit of fiddling with boot -c and disable acpicpu* and disable iwx* in
response to the errors I got I did manage to get it to display its
full 3300x2200 in X, but the file system layout on the 16GB device I
used initially did not have space in /home to store the the entire
output of sendbug -P from the device.

The following shows the various panics and traces as best I could
capture them:

https://www.bsdly.net/~peter/20210525_223507.jpg
https://www.bsdly.net/~peter/20210525_223511.jpg
https://www.bsdly.net/~peter/20210525_233623.jpg
https://www.bsdly.net/~peter/20210525_235112.jpg
https://www.bsdly.net/~peter/20210525_235137.jpg
https://www.bsdly.net/~peter/20210525_235449.jpg
https://www.bsdly.net/~peter/20210525_235502.jpg
https://www.bsdly.net/~peter/20210525_235717.jpg
https://www.bsdly.net/~peter/20210525_235739.jpg
https://www.bsdly.net/~peter/20210525_235747.jpg
https://www.bsdly.net/~peter/20210525_235753.jpg
https://www.bsdly.net/~peter/20210525_235903.jpg
https://www.bsdly.net/~peter/20210525_235914.jpg
https://www.bsdly.net/~peter/20210526_015841.jpg
https://www.bsdly.net/~peter/20210526_015851.jpg
https://www.bsdly.net/~peter/20210526_015901.jpg
https://www.bsdly.net/~peter/20210526_015906.jpg
https://www.bsdly.net/~peter/20210526_024111.jpg
https://www.bsdly.net/~peter/20210526_024123.jpg
https://www.bsdly.net/~peter/20210526_024128.jpg
https://www.bsdly.net/~peter/20210526_024312.jpg
https://www.bsdly.net/~peter/20210526_024322.jpg
https://www.bsdly.net/~peter/20210526_024335.jpg

I will make some more attempts at catching real sendbug
output after I have caught a bit of sleep.

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-25 Thread Jonathan Gray 
On Wed, May 26, 2021 at 02:51:53AM +0200, Peter N. M. Hansteen wrote:
> Somewhat encouraged by the last few weeks' adventure with ASUS
> laptops (thanks, kettenis@!) I decided to try out an incrementally
> higher range model, the Zenbook S.
> 
> The latest amd64 snapshot installer seemed to work fine until
> it encountered the main storage in the unit, which the firmware
> sees as
> 
> PCIE bus:0 Dev:E Func:0
>  Device type:  NVMe SSD (953.8GB)
>  Model name:   INTEL SSDOEKNV 010T8
> 
> But shows up in the installer kernel dmesg as only
> 
> sd0 at scsibus0 targ 1 lun 0: (Generic, STORAGE DEVICE, 0233), removable.

that appears to be something else on usb?

'scsibus0 at umass0: 2 targets, initiator 0'
from https://www.bsdly.net/~peter/20210525_233623.jpg

can you provide a dmesg and pcidump -v output?

I didn't see an image that made it clear which cpu / inteldrm device
this has.

> 
> Installing to a removable USB device was a bit hit and miss, after a
> bit of fiddling with boot -c and disable acpicpu* and disable iwx* in
> response to the errors I got I did manage to get it to display its
> full 3300x2200 in X, but the file system layout on the 16GB device I
> used initially did not have space in /home to store the the entire
> output of sendbug -P from the device.
> 
> The following shows the various panics and traces as best I could
> capture them:
> 
> https://www.bsdly.net/~peter/20210525_223507.jpg
> https://www.bsdly.net/~peter/20210525_223511.jpg
> https://www.bsdly.net/~peter/20210525_233623.jpg
> https://www.bsdly.net/~peter/20210525_235112.jpg

kernel: protection fault trap, code=0
Stopped at pool_do_put+0xc9: movq 0x8(%rcx),%rcx

> https://www.bsdly.net/~peter/20210525_235137.jpg

kernel: protection fault trap, code=0
pool_do_put()+0xc9 movq 0x8(%rcx),%rcx
pool_put()+0x71
process_zap()+0x14f
dowait4()
sys_wait4()
syscall()

> https://www.bsdly.net/~peter/20210525_235449.jpg

panic: pool_do_get: procpl free list modified: ...
db_enter()+0x10 popq %rbp
panic()+0x12a
pool_do_get()+0x321
pool_get()+0x93
fork1()+0x1b6
syscall()+0x3b9

> https://www.bsdly.net/~peter/20210525_235502.jpg

as above with ps showing *init

> https://www.bsdly.net/~peter/20210525_235717.jpg

panic: pool_do_get: drmobj free list modified: ...
panic: kernel diagnostic assertion "!_kernel_lock_held()" failed: file 
"/usr/src/sys/uvm/uvm_map.c", line 2707
db_enter()+0x10 popq %rbp
panic()+0x12a
__assert()+0x2b
uvm_map_teardown()+0x23e
uvmspace_free()+0x5a
reaper()+0x14c

> https://www.bsdly.net/~peter/20210525_235739.jpg

as above with some ps output

> https://www.bsdly.net/~peter/20210525_235747.jpg

ps output

> https://www.bsdly.net/~peter/20210525_235753.jpg

ps output

> https://www.bsdly.net/~peter/20210525_235903.jpg

kernel: protection fault trap, code=0
pool_do_put()+0xc9 movq 0x8(%rcx),%rcx
pool_put()+0x71
process_zap()+0x14f
dowait4()+0x303
sys_wait4()+0x5a
syscall()+0x3b9

> https://www.bsdly.net/~peter/20210525_235914.jpg

above with ps output

> https://www.bsdly.net/~peter/20210526_015841.jpg

uvm_fault()
kernel: page fault trap, code=0
Stopped at i915_gem_object_pin_map+0x2a: testb $0x3,0(%rax)

> https://www.bsdly.net/~peter/20210526_015851.jpg

uvm_fault()
kernel: page fault trap, code=0
Stopped at i915_gem_object_pin_map+0x2a: testb $0x3,0(%rax)
i915_gem_object_pin_map()+0x2a
__execlists_context_alloc()+0x187
__intel_context_do_pin()+0x15a
i915_gem_do_execbuffer()
i915_gem_execbuffer2_ioctl()+0x1cb
drm_do_ioctl()+0x28c

> https://www.bsdly.net/~peter/20210526_015901.jpg

ps output *Xorg

> https://www.bsdly.net/~peter/20210526_015906.jpg

ps output

> https://www.bsdly.net/~peter/20210526_024111.jpg

uvm_fault()
kernel: page fault trap, code=0
Stopped at i915_gem_object_pin_map+0x2a: testb $0x3,0(%rax)
i915_gem_object_pin_map()+0x2a
__execlists_context_alloc()+0x187
__intel_context_do_pin()+0x15a
i915_gem_do_execbuffer()+0x2820
i915_gem_execbuffer2_ioctl()+0x1cb
drm_do_ioctl()+0x28c

> https://www.bsdly.net/~peter/20210526_024123.jpg

ps output *Xorg

> https://www.bsdly.net/~peter/20210526_024128.jpg

ps output

> https://www.bsdly.net/~peter/20210526_024312.jpg

panic: pool_do_get: procpl free list modified: ...
db_enter()+0x10 popq %rbp
panic()+0x12a
pool_do_get()+0x321
pool_get()+0x93
fork1()+0x1b6
syscall()+0x3b9

> https://www.bsdly.net/~peter/20210526_024322.jpg

panic: pool_do_get: procpl free list modified: ...
db_enter()+0x10 popq %rbp
panic()+0x12a
pool_do_get()+0x321
pool_get()+0x93
fork1()+0x1b6
syscall()+0x3b9

> https://www.bsdly.net/~peter/20210526_024335.jpg

as above with ps

> 
> I will make some more attempts at catching real sendbug
> output after I have caught a bit of sleep.
> 
> All the best,
> Peter
> 
> -- 
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673

Re: ASUS ZenBook S: SSD unrecognized, possible new iwx variant

2021-05-25 Thread Bryan Steele 
On Wed, May 26, 2021 at 02:51:53AM +0200, Peter N. M. Hansteen wrote:
> Somewhat encouraged by the last few weeks' adventure with ASUS
> laptops (thanks, kettenis@!) I decided to try out an incrementally
> higher range model, the Zenbook S.
> 
> The latest amd64 snapshot installer seemed to work fine until
> it encountered the main storage in the unit, which the firmware
> sees as
> 
> PCIE bus:0 Dev:E Func:0
>  Device type:  NVMe SSD (953.8GB)
>  Model name:   INTEL SSDOEKNV 010T8
> 
> But shows up in the installer kernel dmesg as only
> 
> sd0 at scsibus0 targ 1 lun 0: (Generic, STORAGE DEVICE, 0233), removable.

That's not it your SSD, from your second mail.

  umass0 at uhub4 port 1 configuration 1 interface 0 "Generic USB Storage"
rev 2.00/2.33 addr 4
  umass0: using SCSI over Bulk-Only
  scsibus1 at umass0: 2 targets, initiator 0
  sd0 at scsibus1 targ 1 lun 0:  removable

I think it might actually be this, which has something to do with
Intel 11th Gen "Intel Rapid Storage" device which is not supported.

  vendor "Intel", unknown product 0x09ab (class system subclass
  miscellaneous, rev 0x00) at pci0 dev 29 function 0 not configured

There's documentation on ASUSs website about it for Windows as well.

https://www.asus.com/us/support/FAQ/1044458/

If you're lucky there may be an option in the BIOS to disable this
and pass through the NMVe device.

> Installing to a removable USB device was a bit hit and miss, after a
> bit of fiddling with boot -c and disable acpicpu* and disable iwx* in
> response to the errors I got I did manage to get it to display its
> full 3300x2200 in X, but the file system layout on the 16GB device I
> used initially did not have space in /home to store the the entire
> output of sendbug -P from the device.
> 
> The following shows the various panics and traces as best I could
> capture them:
> 
> https://www.bsdly.net/~peter/20210525_223507.jpg
> https://www.bsdly.net/~peter/20210525_223511.jpg
> https://www.bsdly.net/~peter/20210525_233623.jpg
> https://www.bsdly.net/~peter/20210525_235112.jpg
> https://www.bsdly.net/~peter/20210525_235137.jpg
> https://www.bsdly.net/~peter/20210525_235449.jpg
> https://www.bsdly.net/~peter/20210525_235502.jpg
> https://www.bsdly.net/~peter/20210525_235717.jpg
> https://www.bsdly.net/~peter/20210525_235739.jpg
> https://www.bsdly.net/~peter/20210525_235747.jpg
> https://www.bsdly.net/~peter/20210525_235753.jpg
> https://www.bsdly.net/~peter/20210525_235903.jpg
> https://www.bsdly.net/~peter/20210525_235914.jpg
> https://www.bsdly.net/~peter/20210526_015841.jpg
> https://www.bsdly.net/~peter/20210526_015851.jpg
> https://www.bsdly.net/~peter/20210526_015901.jpg
> https://www.bsdly.net/~peter/20210526_015906.jpg
> https://www.bsdly.net/~peter/20210526_024111.jpg
> https://www.bsdly.net/~peter/20210526_024123.jpg
> https://www.bsdly.net/~peter/20210526_024128.jpg
> https://www.bsdly.net/~peter/20210526_024312.jpg
> https://www.bsdly.net/~peter/20210526_024322.jpg
> https://www.bsdly.net/~peter/20210526_024335.jpg
> 
> I will make some more attempts at catching real sendbug
> output after I have caught a bit of sleep.
> 
> All the best,
> Peter
> 
> -- 
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
> 
>