Dell R7615 kernel protection fault
Hi all, I've installed latest snapshot with uefi on Dell R7615 with AMD EPYC 9554P, with some NVMe disks on BOSS-N1 adapter and with Samsung NVMe disks directly connected to backplane and installation was fast and without any problems. But after that machine panics with this message https://kosjenka.srce.hr/~hrvoje/openbsd/r7615-ddb1.jpg I can't do anything with keyboard and I've tried over ipmi console but I can't get it to work. BOSS-N1 is in raid1 https://kosjenka.srce.hr/~hrvoje/openbsd/r7615-ramdisk1.jpg Samsung NVMe connected to backplane https://kosjenka.srce.hr/~hrvoje/openbsd/r7615-ramdisk2.jpg I will try somehow to get console output
clockintr: replace CL_RNDSTAT with global variable "statclock_is_randomized"
I'm going to break the big statclock() patch on tech@ into smaller
chunks that are easier to review.
The goal here is to move control of statclock() out of the clock
interrupt subsystem and transform it into a client of that subsystem.
I think we can do this in four parts. Part 3 is the most complex.
1. Replace the CL_RNDSTAT flag with a new global variable,
"statclock_is_randomized".
2. Add clockintr_advance_random() to the public sys/clockintr.h API
so statclock() can use it.
3. Merge the contents of clockintr_statclock() into statclock(); make
statclock() a real callback function that reschedules itself and
transparently handles multiple expirations.
4. Move control of the statclock clockintr handle from the clock
interrupt subsystem to the scheduler.
Attached is a patch for step 1.
In order to isolate the statclock() from the clock interrupt subsystem
we need to replace the CL_RNDSTAT flag with something equivalent.
This patch adds a new global variable, "statclock_is_randomized", to
kern_clock.c and prototypes it in sys/systm.h. All CL_RNDSTAT checks
are replaced with "statclock_is_randomized" checks and instead of
passing CL_RNDSTAT to clockintr_init() we set "statclock_is_randomized".
ok?
Index: kern/kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.116
diff -u -p -r1.116 kern_clock.c
--- kern/kern_clock.c 9 Sep 2023 18:19:03 - 1.116
+++ kern/kern_clock.c 9 Sep 2023 19:03:13 -
@@ -86,6 +86,8 @@ int ticks = INT_MAX - (15 * 60 * HZ);
/* Don't force early wrap around, triggers bug in inteldrm */
volatile unsigned long jiffies;
+int statclock_is_randomized; /* [I] fixed or pseudorandom period? */
+
/*
* Initialize clock frequencies and start both clocks running.
*/
Index: kern/kern_clockintr.c
===
RCS file: /cvs/src/sys/kern/kern_clockintr.c,v
retrieving revision 1.45
diff -u -p -r1.45 kern_clockintr.c
--- kern/kern_clockintr.c 9 Sep 2023 17:07:59 - 1.45
+++ kern/kern_clockintr.c 9 Sep 2023 19:03:13 -
@@ -167,7 +167,7 @@ clockintr_cpu_init(const struct intrcloc
* We can always advance the statclock. There is no reason to
* stagger a randomized statclock.
*/
- if (!ISSET(clockintr_flags, CL_RNDSTAT)) {
+ if (!statclock_is_randomized) {
if (cq->cq_statclock->cl_expiration == 0) {
clockintr_stagger(cq->cq_statclock, statclock_avg,
multiplier, MAXCPUS);
@@ -466,7 +466,7 @@ clockintr_statclock(struct clockintr *cl
{
uint64_t count, i;
- if (ISSET(clockintr_flags, CL_RNDSTAT)) {
+ if (statclock_is_randomized) {
count = clockintr_advance_random(cl, statclock_min,
statclock_mask);
} else {
Index: sys/clockintr.h
===
RCS file: /cvs/src/sys/sys/clockintr.h,v
retrieving revision 1.12
diff -u -p -r1.12 clockintr.h
--- sys/clockintr.h 6 Sep 2023 02:33:18 - 1.12
+++ sys/clockintr.h 9 Sep 2023 19:03:14 -
@@ -114,8 +114,7 @@ struct clockintr_queue {
#define CL_STATE_MASK 0x0001
/* Global behavior flags. */
-#define CL_RNDSTAT 0x8000 /* randomized statclock */
-#define CL_FLAG_MASK 0x8000
+#define CL_FLAG_MASK 0x
void clockintr_cpu_init(const struct intrclock *);
int clockintr_dispatch(void *);
Index: sys/systm.h
===
RCS file: /cvs/src/sys/sys/systm.h,v
retrieving revision 1.165
diff -u -p -r1.165 systm.h
--- sys/systm.h 23 Aug 2023 01:55:45 - 1.165
+++ sys/systm.h 9 Sep 2023 19:03:14 -
@@ -234,6 +234,7 @@ int tstohz(const struct timespec *);
void realitexpire(void *);
extern uint32_t hardclock_period;
+extern int statclock_is_randomized;
struct clockframe;
void hardclock(struct clockframe *);
Index: arch/amd64/amd64/lapic.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/lapic.c,v
retrieving revision 1.69
diff -u -p -r1.69 lapic.c
--- arch/amd64/amd64/lapic.c23 Aug 2023 01:55:46 - 1.69
+++ arch/amd64/amd64/lapic.c9 Sep 2023 19:03:14 -
@@ -498,7 +498,8 @@ lapic_initclocks(void)
stathz = hz;
profhz = stathz * 10;
- clockintr_init(CL_RNDSTAT);
+ statclock_is_randomized = 1;
+ clockintr_init(0);
}
Index: arch/arm64/dev/agtimer.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/agtimer.c,v
retrieving revision 1.26
diff -u -p -r1.26 agtimer.c
--- arch/arm64/dev/agtimer.c23 Aug 2023 01:55:46 - 1.26
+++ arch/arm64/dev/agtimer.c9 Sep 2023 19:03:14 -
@@ -293,7 +293,8 @@
Re: [OpenSMTPD] Setting personal mailserver
Sagar Acharya wrote in : |Thanks Peter, your comments were very helpful and I made some progress | |I have currently hosted server at 587. I have also set | |_submission._tcp.humaaraartha.in. SRV | |records which point to 587. However, I think such a thing is not impleme\ |nted by default to be detected by mailservers, perhaps, SMTPD. | |Is such a check on other ports in case 25 connection is not established \ |implemented? Submission is for mail-user-agents, whereas SMTP is for mail-transfer-agents. Having said that, for yourself you can do whatever you want, but you cannot expect that the SMTP servers of the world play nicely with it. That is: if you relay your own mail and that of all computers of your own to one SMTP server, which then sends those emails out to the world, then you can configure all your computers to relay to a specific port, and drive the SMTP server on that. But the world will respond to your :25. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
[OpenSMTPD] Setting personal mailserver
Thanks Peter, your comments were very helpful and I made some progress I have currently hosted server at 587. I have also set _submission._tcp.humaaraartha.in. SRV records which point to 587. However, I think such a thing is not implemented by default to be detected by mailservers, perhaps, SMTPD. Is such a check on other ports in case 25 connection is not established implemented? Thanking you Sagar Acharya https://humaaraartha.in 8 Sept 2023, 16:27 by pe...@bsdly.net: > On Fri, Sep 08, 2023 at 11:35:37AM +0200, Sagar Acharya wrote: > >> Requesting a feature at OpenSMTPD. >> Date: 8 Sept 2023, 14:50 >> From: sagaracha...@tutanota.com >> To: b...@opensmtpd.org >> Subject: FWD: Re: Setting personal mailserver >> >> >> > I request a feature from all the devs. >> > >> > This would enable users of smtpd to host an email server at any port >> > instead of standard 25. >> > > Unless I read the smtpd.conf man page very wrong > (https://man.openbsd.org/smtpd.conf) > it is possible, but not recommended, to set up to listen on ports other than > the standard ones. > > To put it bluntly, what you need is not a new smtpd feature. What you need is > for you to > take the advice given on the opensmptd mailing list: Read the literature > others have pointed > you at, and please consider one or more of the alternative approaches that > have been > suggested to you. > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > https://bsdly.blogspot.com/ https://www.bsdly.net/ https://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. >
SK-Hynix NVMe PE8000
Hi all,
in attachment you can find diff to add SK-Hynix NVMe to pcidevs
before diff
Sep 9 08:44:28 alt-vpn1 /bsd: nvme0 at pci13 dev 0 function 0 vendor
"SK hynix", unknown product 0x2839 rev 0x21: msix, NVMe 1.3
Sep 9 08:44:28 alt-vpn1 /bsd: nvme0: Dell DC NVMe PE8010 RI U.2 960GB,
firmware 1.2.0, serial SJC2N4257I34R2Q19
Sep 9 08:44:28 alt-vpn1 /bsd: scsibus2 at nvme0: 17 targets, initiator 0
after diff
Sep 9 08:51:20 alt-vpn1 /bsd: nvme0 at pci13 dev 0 function 0 "SK hynix
PE8000 NVMe" rev 0x21: msix, NVMe 1.3
Sep 9 08:51:20 alt-vpn1 /bsd: nvme0: Dell DC NVMe PE8010 RI U.2 960GB,
firmware 1.2.0, serial SJC2N4257I34R2Q19
Sep 9 08:51:20 alt-vpn1 /bsd: scsibus2 at nvme0: 17 targets, initiator 0
129:0:0: SK hynix unknown
0x: Vendor ID: 1c5c, Product ID: 2839
0x0004: Command: 0147, Status: 0010
0x0008: Class: 01 Mass Storage, Subclass: 08 NVM,
Interface: 02, Revision: 21
0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
Cache Line Size: 00
0x0010: BAR mem 64bit addr: 0xbf70/0x8000
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS:
0x002c: Subsystem Vendor ID: 1028 Product ID: 2144
0x0030: Expansion ROM Base Address:
0x0038:
0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
0x0080: Capability 0x01: Power Management
State: D0
0x00b0: Capability 0x11: Extended Message Signalled Interrupts
(MSI-X)
Enabled: yes; table size 257 (BAR 0:12288)
0x00c0: Capability 0x10: PCI Express
Max Payload Size: 256 / 512 bytes
Max Read Request Size: 512 bytes
Link Speed: 8.0 / 16.0 GT/s
Link Width: x4 / x4
0x0100: Enhanced Capability 0x01: Advanced Error Reporting
0x0150: Enhanced Capability 0x03: Device Serial Number
Serial Number: 5ddc2935ff2ee4ac
0x0160: Enhanced Capability 0x04: Power Budgeting
0x0300: Enhanced Capability 0x19: Secondary PCIe Capability
0x0400: Enhanced Capability 0x0b: Vendor-Specific
0x0910: Enhanced Capability 0x25: Data Link Feature
0x0920: Enhanced Capability 0x27: Lane Margining at the Receiver
0x09c0: Enhanced Capability 0x26: Physical Layer 16.0 GT/s
from pci.ids
1c5c SK hynix
2839 PE8000 Series NVMe Solid State Drive
1028 2144 DC NVMe PE8010 RI U.2 960GB
Should I in diff somehow match
Subsystem Vendor ID: 1028 Product ID: 2144 ?Index: pcidevs
===
RCS file: /home/cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2050
diff -u -p -u -p -r1.2050 pcidevs
--- pcidevs 7 Sep 2023 02:11:26 - 1.2050
+++ pcidevs 9 Sep 2023 06:40:44 -
@@ -8875,6 +8875,7 @@ product SIS 966_HDA 0x7502 966 HD Audio
/* SK hynix products */
product SKHYNIX SSD0x1327 BC501 NVMe
+product SKHYNIX NVMe 0x2839 PE8000 NVMe
/* SMC products */
product SMC 83C170 0x0005 83C170
Index: pcidevs.h
===
RCS file: /home/cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.2044
diff -u -p -u -p -r1.2044 pcidevs.h
--- pcidevs.h 7 Sep 2023 02:12:07 - 1.2044
+++ pcidevs.h 9 Sep 2023 06:41:03 -
@@ -2,7 +2,7 @@
* THIS FILE AUTOMATICALLY GENERATED. DO NOT EDIT.
*
* generated from:
- * OpenBSD: pcidevs,v 1.2049 2023/09/07 01:41:09 jsg Exp
+ * OpenBSD: pcidevs,v 1.2050 2023/09/07 02:11:26 daniel Exp
*/
/* $NetBSD: pcidevs,v 1.30 1997/06/24 06:20:24 thorpej Exp $ */
@@ -8880,6 +8880,7 @@
/* SK hynix products */
#definePCI_PRODUCT_SKHYNIX_SSD 0x1327 /* BC501 NVMe */
+#definePCI_PRODUCT_SKHYNIX_NVMe0x2839 /* PE8000 NVMe
*/
/* SMC products */
#definePCI_PRODUCT_SMC_83C170 0x0005 /* 83C170 */
Index: pcidevs_data.h
===
RCS file: /home/cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.2039
diff -u -p -u -p -r1.2039 pcidevs_data.h
--- pcidevs_data.h 7 Sep 2023 02:12:07 - 1.2039
+++ pcidevs_data.h 9 Sep 2023 06:41:03 -
@@ -2,7 +2,7 @@
* THIS FILE AUTOMATICALLY GENERATED. DO NOT EDIT.
*
* generated from:
- * OpenBSD: pcidevs,v 1.2049 2023/09/07 01:41:09 jsg Exp
+ * OpenBSD: pcidevs,v 1.2050 2023/09/07 02:11:26 daniel Exp
*/
/* $NetBSD: pcidevs,v 1.30 1997/06/24 06:20:24 thorpej Exp $ */
@@ -31906,6 +31906,10 @@ static const struct pci_known_product pc
{
PCI_VENDOR_SKHYNIX, PCI_PRODUCT_SKHYNIX_SSD,
"BC501 NVMe",
+ },
+ {
+
Re: Correct TP-LINK bluetooth ID
On Sat, Sep 09, 2023 at 03:37:49PM +0800, Kevin Lo wrote:
> On Sat, Sep 09, 2023 at 03:16:08PM +0800, Kevin Lo wrote:
> >
> > On Sep 7 Douglas Silva reported this bug:
> >
> > https://marc.info/?l=openbsd-bugs=169407574511323=2
> >
> > The product id of the tp-link ub500 is 0x0604 which uses the RTL8761BUV
> > chip.
> > The diff below corrects TP-LINK bluetooth ID.
> > ok?
>
> Forgot to remove it in ure(4). Here's the revised diff, ok?
ok jsg@
>
> Index: sys/dev/usb/if_ure.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
> retrieving revision 1.32
> diff -u -p -u -p -r1.32 if_ure.c
> --- sys/dev/usb/if_ure.c 6 May 2023 08:07:10 - 1.32
> +++ sys/dev/usb/if_ure.c 9 Sep 2023 07:34:54 -
> @@ -126,7 +126,6 @@ const struct usb_devno ure_devs[] = {
> { USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_EU300 },
> { USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_RTL8152B_1 },
> { USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_RTL8152B_2 },
> - { USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_RTL8153 },
> { USB_VENDOR_TRENDNET, USB_PRODUCT_TRENDNET_RTL8156 },
> { USB_VENDOR_TTL, USB_PRODUCT_TTL_RTL8153 },
> { USB_VENDOR_TWINHEAD, USB_PRODUCT_TWINHEAD_RTL8153B },
> Index: sys/dev/usb/usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.758
> diff -u -p -u -p -r1.758 usbdevs
> --- sys/dev/usb/usbdevs 12 Aug 2023 20:43:49 - 1.758
> +++ sys/dev/usb/usbdevs 9 Sep 2023 07:34:54 -
> @@ -4478,7 +4478,7 @@ product TPLINK RTL8188EUS 0x010c RTL8188
> product TPLINK EU300 0x0601 EU300
> product TPLINK RTL8152B_10x0602 RTL8152B
> product TPLINK RTL8152B_20x0603 RTL8152B
> -product TPLINK RTL8153 0x0604 RTL8153
> +product TPLINK UB500 0x0604 UB500
>
> /* Trek Technology products */
> product TREK THUMBDRIVE 0x ThumbDrive
>
>
Re: Correct TP-LINK bluetooth ID
On Sat, Sep 09, 2023 at 03:16:08PM +0800, Kevin Lo wrote:
>
> On Sep 7 Douglas Silva reported this bug:
>
> https://marc.info/?l=openbsd-bugs=169407574511323=2
>
> The product id of the tp-link ub500 is 0x0604 which uses the RTL8761BUV chip.
> The diff below corrects TP-LINK bluetooth ID.
> ok?
Forgot to remove it in ure(4). Here's the revised diff, ok?
Index: sys/dev/usb/if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.32
diff -u -p -u -p -r1.32 if_ure.c
--- sys/dev/usb/if_ure.c6 May 2023 08:07:10 - 1.32
+++ sys/dev/usb/if_ure.c9 Sep 2023 07:34:54 -
@@ -126,7 +126,6 @@ const struct usb_devno ure_devs[] = {
{ USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_EU300 },
{ USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_RTL8152B_1 },
{ USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_RTL8152B_2 },
- { USB_VENDOR_TPLINK, USB_PRODUCT_TPLINK_RTL8153 },
{ USB_VENDOR_TRENDNET, USB_PRODUCT_TRENDNET_RTL8156 },
{ USB_VENDOR_TTL, USB_PRODUCT_TTL_RTL8153 },
{ USB_VENDOR_TWINHEAD, USB_PRODUCT_TWINHEAD_RTL8153B },
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.758
diff -u -p -u -p -r1.758 usbdevs
--- sys/dev/usb/usbdevs 12 Aug 2023 20:43:49 - 1.758
+++ sys/dev/usb/usbdevs 9 Sep 2023 07:34:54 -
@@ -4478,7 +4478,7 @@ product TPLINK RTL8188EUS 0x010c RTL8188
product TPLINK EU300 0x0601 EU300
product TPLINK RTL8152B_1 0x0602 RTL8152B
product TPLINK RTL8152B_2 0x0603 RTL8152B
-product TPLINK RTL8153 0x0604 RTL8153
+product TPLINK UB500 0x0604 UB500
/* Trek Technology products */
product TREK THUMBDRIVE0x ThumbDrive
Correct TP-LINK bluetooth ID
On Sep 7 Douglas Silva reported this bug: https://marc.info/?l=openbsd-bugs=169407574511323=2 The product id of the tp-link ub500 is 0x0604 which uses the RTL8761BUV chip. The diff below corrects TP-LINK bluetooth ID. ok? Index: sys/dev/usb/usbdevs === RCS file: /cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.758 diff -u -p -u -p -r1.758 usbdevs --- sys/dev/usb/usbdevs 12 Aug 2023 20:43:49 - 1.758 +++ sys/dev/usb/usbdevs 9 Sep 2023 07:03:23 - @@ -4478,7 +4478,7 @@ product TPLINK RTL8188EUS 0x010c RTL8188 product TPLINK EU300 0x0601 EU300 product TPLINK RTL8152B_1 0x0602 RTL8152B product TPLINK RTL8152B_2 0x0603 RTL8152B -product TPLINK RTL8153 0x0604 RTL8153 +product TPLINK UB500 0x0604 UB500 /* Trek Technology products */ product TREK THUMBDRIVE0x ThumbDrive
