Re: unknown USB vendor
On Fri, 24 May 2024 11:51:49 +0200 Mizsei Zoltán wrote: > Probably https://wikidevi.wi-cat.ru/AMPAK_AP6212 > > Peter J. Philipp írta 2024. máj.. 24, P-n 11:39 órakor: > > Hi, > > > > I got a "are you a human?" on google so I switched to qwant.com for > > searching > > but the search is not as good. I'm looking for the USB vendor of > > this USB > > vendor id. 0x02d0, and the device id is 0xa9a6. Afaict this is a > > ure(4) > > device with a builtin usb hub. But there is no other markings on > > the outside, related to manufacturer. It does not get detected by > > default on an April > > kernel code. It does have a micro-USB cable for the raspberry pi > > zero 2 that > > I wanted to use this with. > > > > Anyone have any details on these vendor and device id's? > > > > Best Regards, > > -pjp > > > > -- > > ** all info about me: lynx https://callpeter.tel, dig loc > > delphinusdns.org ** > From an RPI 4 dmesg: ... bwfm0 at sdmmc0 function 1 manufacturer 0x02d0, product 0xa9a6 at sdmmc0 ...
Re: Sudden reboot every 5-10 minutes on latest snapshot
Alexandre Ratchov wrote: > On Fri, May 24, 2024 at 09:04:29PM +, Ali Farzanrad wrote: > > Alexandre Ratchov wrote: > > > On Fri, May 24, 2024 at 04:30:52PM +, Ali Farzanrad wrote: > > > > Hi again, > > > > > > > > During my tests it seems that this version of kernel works fine: > > > > > > > > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 19:30" -P src > > > > > > > > But this version of kernel will cause sudden reboots without any kernel > > > > panic or message after 5-60 minutes in my Minisforum UM790: > > > > > > > > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 20:00" -P src > > > > > > > > After investigation I found this patch could fix my problem: > > > > > > > > Index: azalia.c > > > > === > > > > RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v > > > > diff -u -p -r1.287 azalia.c > > > > --- azalia.c17 May 2024 19:43:45 - 1.287 > > > > +++ azalia.c24 May 2024 16:26:38 - > > > > @@ -557,6 +557,16 @@ azalia_pci_attach(struct device *parent, > > > > azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg); > > > > } > > > > > > > > + /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */ > > > > + if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) { > > > > + switch (PCI_PRODUCT(sc->pciid)) { > > > > + case PCI_PRODUCT_AMD_17_HDA: > > > > + case PCI_PRODUCT_AMD_17_1X_HDA: > > > > + case PCI_PRODUCT_AMD_HUDSON2_HDA: > > > > + pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED; > > > > + } > > > > + } > > > > + > > > > /* interrupt */ > > > > if (pci_intr_map_msi(pa, &ih) && pci_intr_map(pa, &ih)) { > > > > printf(": can't map interrupt\n"); > > > > > > > > However it breaks my front 3.5mm audio port and I should use my > > > > USB-to-3.5mm audio port adapter again. > > > > > > > > How may I investigate more? > > > > > > > > > > could you confirm that the system reboots only while you're using the > > > azalia device? > > > > I disabled sndiod, and unplugged my USB-to-3.5mm audio adapter and also > > unplugged front 3.5mm audio port, then reboot my OpenBSD and waited on > > xenodm login screen for few minutes; most of the time it reboots in > > less than 10 minutes... without any interaction from me, or playing > > anything... > > > > Could you disable the azalia driver and redo your test? reboot, then > on the boot(8) prompt type "boot -c", then "disable azalia", then > "quit". I have another problem here. My USB keyboard works great in BOOTX64.EFI but will not work on kernel config. I created /etc/bsd.re-config file and rebooted my system twice to disable azalia and then checked if it is disabled using config(8) and dmesg(8). Even when azalia is disabled my system gets sudden reboots. First sudden reboot was just after playing a music; but next 2 reboots was happened without playing anything. > Then, just do your regular stuff and see if the system reboots.
Re: Sudden reboot every 5-10 minutes on latest snapshot
Ali Farzanrad wrote: > Alexandre Ratchov wrote: > > On Fri, May 24, 2024 at 09:04:29PM +, Ali Farzanrad wrote: > > > Alexandre Ratchov wrote: > > > > On Fri, May 24, 2024 at 04:30:52PM +, Ali Farzanrad wrote: > > > > > Hi again, > > > > > > > > > > During my tests it seems that this version of kernel works fine: > > > > > > > > > > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 19:30" -P src > > > > > > > > > > But this version of kernel will cause sudden reboots without any > > > > > kernel > > > > > panic or message after 5-60 minutes in my Minisforum UM790: > > > > > > > > > > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 20:00" -P src > > > > > > > > > > After investigation I found this patch could fix my problem: > > > > > > > > > > Index: azalia.c > > > > > === > > > > > RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v > > > > > diff -u -p -r1.287 azalia.c > > > > > --- azalia.c 17 May 2024 19:43:45 - 1.287 > > > > > +++ azalia.c 24 May 2024 16:26:38 - > > > > > @@ -557,6 +557,16 @@ azalia_pci_attach(struct device *parent, > > > > > azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg); > > > > > } > > > > > > > > > > + /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */ > > > > > + if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) { > > > > > + switch (PCI_PRODUCT(sc->pciid)) { > > > > > + case PCI_PRODUCT_AMD_17_HDA: > > > > > + case PCI_PRODUCT_AMD_17_1X_HDA: > > > > > + case PCI_PRODUCT_AMD_HUDSON2_HDA: > > > > > + pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED; > > > > > + } > > > > > + } > > > > > + > > > > > /* interrupt */ > > > > > if (pci_intr_map_msi(pa, &ih) && pci_intr_map(pa, &ih)) { > > > > > printf(": can't map interrupt\n"); > > > > > > > > > > However it breaks my front 3.5mm audio port and I should use my > > > > > USB-to-3.5mm audio port adapter again. > > > > > > > > > > How may I investigate more? > > > > > > > > > > > > > could you confirm that the system reboots only while you're using the > > > > azalia device? > > > > > > I disabled sndiod, and unplugged my USB-to-3.5mm audio adapter and also > > > unplugged front 3.5mm audio port, then reboot my OpenBSD and waited on > > > xenodm login screen for few minutes; most of the time it reboots in > > > less than 10 minutes... without any interaction from me, or playing > > > anything... > > > > > > > Could you disable the azalia driver and redo your test? reboot, then > > on the boot(8) prompt type "boot -c", then "disable azalia", then > > "quit". > > I have another problem here. My USB keyboard works great in BOOTX64.EFI > but will not work on kernel config. > > I created /etc/bsd.re-config file and rebooted my system twice to > disable azalia and then checked if it is disabled using config(8) and > dmesg(8). > > Even when azalia is disabled my system gets sudden reboots. > First sudden reboot was just after playing a music; but next 2 reboots > was happened without playing anything. > > > Then, just do your regular stuff and see if the system reboots. I tested again with my patch. When azalia is disabled, it suddenly reboots after few minutes, without playing anything. When azalia is enabled, it lives.
Re: nginx + php = system() not working?
I tried a few things with nginx not in chroot; but got permission errors. The message provided no clue as to which file/directory might be causing it; so eventually I gave up. After some brainstorming; we decided to run inside chroot; use php functions other than system() and use a cron job to do the work that is outside chroot. Now a new issue; nginx does not start during boot; yet does start manually - why? The following commands were issued immediately after boot. # cat /etc/rc.conf.local nginx_flags="" pkg_scripts=php83_fpm # /etc/rc.d/nginx start nginx(ok) On Fri, May 17, 2024 at 10:19 AM Souji Thenria wrote: > On Fri May 17, 2024 at 2:56 PM BST, F Bax wrote: > > In /etc/rc.conf.local - I changed nginx_flags="-u -p /home/Testing" > > (home directory of a real user). > > reboot system and now browser is refused connection > > This site can’t be reached 192.168.1.131 refused to connect. > > Neither /var/www/logs/{access|error}.log is changed. > > What else needs to change? > > Can you verify that nginx is running? > You may have an error in your configuration. You can check the nginx > configuration using nginx -t. > > Another issue might be that nginx is still running as www and doesn't > have access to /home/Testing. > > Regards, > Souji >
Re: 7.5 install crashes on "entry point at 0x1001000" HP Elitebook 840 G10
On Sat, May 25, 2024 at 07:51:31AM +0200, Comète wrote: > Hello, > > This is a link to a screenshot, I can't copy/paste at this step: > > https://ibb.co/tpr8zBz > > Thanks a lot ! > > Comete > looks fine. probably our choice of physaddr conflicting with something from efi. > Le 24 mai 2024 20:38:45 GMT+02:00, Mike Larkin a écrit : > >On Fri, May 24, 2024 at 06:59:24AM +, Comète wrote: > >> Thanks Sven, > >> > >> I can't install OpenBDS because I get the error when trying to boot the > >> install image. > >> > >> Comete > >> > > > >At the boot> prompt, can you show what "mach mem" prints? > > > >Thanks > > > >-ml > > > >> 24 mai 2024 07:48 "Sven Wolf" a écrit: > >> > >> > Hi, > >> > > >> > I had a silimar issue on a Lenovo V130. > >> > For this machine I needed to remove the amdgpu driver in the kernel. > >> > > >> > See also: > >> > https://marc.info/?l=openbsd-misc&m=160232897421774&w=2 > >> > https://marc.info/?l=openbsd-tech&m=160383074317608&w=2 > >> > > >> > Do you get the error "entry point at 0x1001000" also with the bsd.rd > >> > kernel or only after you > >> > installed the system with the bsd.mp/bsd.sp kernel? > >> > > >> > Best regards, > >> > Sven > >> > > >> > On 5/23/24 22:40, Comète wrote: > >> > > >> >> Hello, > >> >> I tried to install OpenBSD 7.5 on a new HP Elitebook 840 G10 (UEFI > >> >> capable only) without success. > >> >> It is stuck at boot on "entry point at 0x1001000". > >> >> Even retried after a BIOS upgrade but no luck either. > >> >> I tried with a snapshot install too with the same result. > >> >> I post here what lspci returns from a debian bookworm: > >> >> 00:00.0 Host bridge: Intel Corporation Device a706 > >> >> 00:02.0 VGA compatible controller: Intel Corporation Raptor Lake-P > >> >> [Iris Xe Graphics] (rev 04) > >> >> 00:04.0 Signal processing controller: Intel Corporation Raptor Lake > >> >> Dynamic Platform and Thermal > >> >> Framework Processor Participant > >> >> 00:06.0 PCI bridge: Intel Corporation Raptor Lake PCIe 4.0 Graphics Port > >> >> 00:06.2 PCI bridge: Intel Corporation Device a73d > >> >> 00:07.0 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI > >> >> Express Root Port > >> >> 00:07.2 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI > >> >> Express Root Port > >> >> 00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator > >> >> module > >> >> 00:0a.0 Signal processing controller: Intel Corporation Raptor Lake > >> >> Crashlog and Telemetry (rev 01) > >> >> 00:0d.0 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 > >> >> USB Controller > >> >> 00:0d.2 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 > >> >> NHI > >> >> 00:0d.3 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 > >> >> NHI > >> >> 00:14.0 USB controller: Intel Corporation Alder Lake PCH USB 3.2 xHCI > >> >> Host Controller (rev 01) > >> >> 00:14.2 RAM memory: Intel Corporation Alder Lake PCH Shared SRAM (rev > >> >> 01) > >> >> 00:14.3 Network controller: Intel Corporation Raptor Lake PCH CNVi WiFi > >> >> (rev 01) > >> >> 00:15.0 Serial bus controller: Intel Corporation Alder Lake PCH Serial > >> >> IO I2C Controller #0 (rev > >> >> 01) > >> >> 00:16.0 Communication controller: Intel Corporation Alder Lake PCH HECI > >> >> Controller (rev 01) > >> >> 00:16.3 Serial controller: Intel Corporation Alder Lake AMT SOL > >> >> Redirection (rev 01) > >> >> 00:1c.0 PCI bridge: Intel Corporation Alder Lake PCH-P PCI Express Root > >> >> Port #9 (rev 01) > >> >> 00:1e.0 Communication controller: Intel Corporation Alder Lake PCH UART > >> >> #0 (rev 01) > >> >> 00:1e.2 Serial bus controller: Intel Corporation Alder Lake SPI > >> >> Controller (rev 01) > >> >> 00:1f.0 ISA bridge: Intel Corporation Raptor Lake LPC/eSPI Controller > >> >> (rev 01) > >> >> 00:1f.3 Multimedia audio controller: Intel Corporation Raptor > >> >> Lake-P/U/H cAVS (rev 01) > >> >> 00:1f.4 SMBus: Intel Corporation Alder Lake PCH-P SMBus Host Controller > >> >> (rev 01) > >> >> 00:1f.5 Serial bus controller: Intel Corporation Alder Lake-P PCH SPI > >> >> Controller (rev 01) > >> >> 02:00.0 Non-Volatile memory controller: SK hynix BC901 NVMe Solid State > >> >> Drive (DRAM-less) (rev 03) > >> >> 57:00.0 Wireless controller [0d40]: Intel Corporation XMM7560 LTE > >> >> Advanced Pro Modem (rev 01) > >> >>> Thanks for your help. > >> >> Comete > >> > > -- > Envoyé de mon téléphone. Excusez la brièveté. >
feedback on nsh running on OpenBSD
Folks if any of you are using nsh on OpenBSD and you have any feedback likes or dislikes would be glad to hear of them, I will try to incorporate any feedback in the course on nsh in BSDCan or in the manual page for nsh Thanks -- Kindest regards, Tom Smyth.
Re: wifi
On 2024-05-24, Gustavo Rios wrote: > --b1957806193be4bf > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Is there plan to add support ? Can't say for sure what somebody might like to work on, but from reading posts from people using these on other OS (which aren't very positive) I wouldn't think this is worth the trouble. I'd suggest looking for an iwm or iwx card in the same form factor (which shouldn't be expensive) and try swapping it.
Re: nginx + php = system() not working?
On 25/05/2024 17:51, F Bax wrote: I tried a few things with nginx not in chroot; but got permission errors. The message provided no clue as to which file/directory might be causing it; so eventually I gave up. After some brainstorming; we decided to run inside chroot; use php functions other than system() and use a cron job to do the work that is outside chroot. Now a new issue; nginx does not start during boot; yet does start manually - why? The following commands were issued immediately after boot. # cat /etc/rc.conf.local nginx_flags="" pkg_scripts=php83_fpm # /etc/rc.d/nginx start You forgot to run rcctl enable nginx so that nginx is added to the pkg_scripts= line. Only system daemons can be enabled by adding them as $daemon_flags= in /etc/rc.conf.local . Package daemons must be explicitely added to pkg_scripts= . Cheers, Noth nginx(ok) On Fri, May 17, 2024 at 10:19 AM Souji Thenria wrote: On Fri May 17, 2024 at 2:56 PM BST, F Bax wrote: > In /etc/rc.conf.local - I changed nginx_flags="-u -p /home/Testing" > (home directory of a real user). > reboot system and now browser is refused connection > This site can’t be reached 192.168.1.131 refused to connect. > Neither /var/www/logs/{access|error}.log is changed. > What else needs to change? Can you verify that nginx is running? You may have an error in your configuration. You can check the nginx configuration using nginx -t. Another issue might be that nginx is still running as www and doesn't have access to /home/Testing. Regards, Souji
Re: Sudden reboot every 5-10 minutes on latest snapshot
On Sat, May 25, 2024 at 12:06:39PM +, Ali Farzanrad wrote: > Ali Farzanrad wrote: > > Alexandre Ratchov wrote: > > > On Fri, May 24, 2024 at 09:04:29PM +, Ali Farzanrad wrote: > > > > Alexandre Ratchov wrote: > > > > > On Fri, May 24, 2024 at 04:30:52PM +, Ali Farzanrad wrote: [...] > > I have another problem here. My USB keyboard works great in BOOTX64.EFI > > but will not work on kernel config. > > > > I created /etc/bsd.re-config file and rebooted my system twice to > > disable azalia and then checked if it is disabled using config(8) and > > dmesg(8). > > > > Even when azalia is disabled my system gets sudden reboots. > > First sudden reboot was just after playing a music; but next 2 reboots > > was happened without playing anything. > > > > > Then, just do your regular stuff and see if the system reboots. > > I tested again with my patch. When azalia is disabled, it suddenly > reboots after few minutes, without playing anything. When azalia is > enabled, it lives. > This looks to me like you are chasing down a new rabbit hole every time I open one of your emails. I'd suggest you take a step back from all the stuff you seem to be trying without having a firm grasp on how to observe or report reproducibility. Have you tried out sthen@'s advice to check old kernels + snapshots[1]? I may have missed your response to this. You wrote that you rarely got the issue prior 17-May-2024? If that *is correct*, then you should be able to bisect using the snapshot archive around what date things change. I am highlighting *is correct* above because your issue seems to be unpredictable enough that a few minutes of testing don't mean anything. I suggest you try to find a *clear difference*, meaning between a snapshot where no reboot happens for ideally a whole day of use, and the next one where it clearly happens very quickly (and reproducible at least a second or third time). Your reports also make me wonder how much customization you are running. You've mentioned at least compiling custom kernels and setting bsd.re-config. It's easy to find yourself in virtually unsolvable scenarios by configuring too much. It might be best to try a clean install, ideally without activating xenodm/X11. [1] https://marc.info/?l=openbsd-misc&m=171646884302309&w=2
Re: Sudden reboot every 5-10 minutes on latest snapshot
On Sat, May 25, 2024 at 09:13:56AM +, Ali Farzanrad wrote: > > Even when azalia is disabled my system gets sudden reboots. > First sudden reboot was just after playing a music; but next 2 reboots > was happened without playing anything. > This suggests the reboots are not directly caused by the azalia's msi vs old-style interrupts. I'd suggest that you find and old enough snapshot (or release) that used to work reliably on this machine and make sure it still works reliably with the old software version. Not just an hour, use it few days for real work. This would confirm that the hardware is still OK. Take few quick notes of what devices are involved, how the machine is used, etc. Save the dmesg. If this isn't a hardware problem, then grab a new snapshot and try to understand what changed, compare the dmesg, compare the usage pattern etc. Possibly start bissecting the kernel until you find the change that causes the reboots. HTH