Re: ttycreate from FreeBSD equivalent
I think your process is difficult because it is backwards. Probably easier to take the closest openbsd driver, start removing wrong-device-specific parts from it and put your own device specific parts into it. It will difficult to ensure your driver-independent pieces are correct if you are picking them one by one out of other code. jon@elytron.openbsd.amsterdam wrote: > Thanks for your reply. Yes, I'm using ttymalloc but I'm having a > hard time telling where the terminal has attached to. For context, > I'm working on adding support for a certain cardbus 3g modem. For > a while I considered using puc at cardbus but it seems both the > interrupt handling and the non standard terminal sequences warrant > a full separate driver. I wondered if attaching com at this new > device would make sense, but at the moment I'm taking the linux > approach of implementing it's own tty code. > > At the moment I can initialize the card and process interrups, just > need to figure out the tty bits. Here is the freebsd driver I'm > using as reference (was also work in progress) > > http://web.archive.org/web/20080327050955/http://bsd.vwsoft.com/3g/nozomi/nozomi.c > > also, https://marc.info/?l=openbsd-tech&m=166127896828617&w=2 >
pf(4) drops valid IGMP/MLD messages
Hello,
the issue has been discovered and analyzed by Luca di Gregorio
on bugs@ [1]. The thread [1] covers all details. People who
wish to read brief summary can skip to Luca's email [2].
To wrap it up the current handling IGMP/MLD messages in pf(4)
is exact opposite. I failed to translate English words from
RFC standards into correct C code. Patch below are two one-liners
which make multicast for IPv4/IPv6 to work again with pf(4) enabled.
Let me quote Luca's summary for IPv6 here:
If the IP Destination Address is multicast, then the TTL
should be 1.
If the IP Destination Address is not multicast, then
no restrictions on TTL.
and Luca's summary for IPv4:
If the IP Destination Address is 224.0.0.0/4, then the TTL
should be 1.
If the IP Destination Address is not 224.0.0.0/4, then no
restrictions on TTL.
As I've said all details and references to RFCs can be found
in Luca's emails on bugs@ [1].
Diff below to fix IGMP/MLD handling has been essentially proposed
by Luca [3]. OK to commit?
thanks and
regards
sashan
[1] https://marc.info/?t=16771405962&r=1&w=2
[2] https://marc.info/?l=openbsd-bugs&m=167727244015783&w=2
[3] https://marc.info/?l=openbsd-bugs&m=167722460220004&w=2
8<---8<---8<--8<
diff --git a/sys/net/pf.c b/sys/net/pf.c
index 8cb1326a160..c328109026c 100644
--- a/sys/net/pf.c
+++ b/sys/net/pf.c
@@ -6847,7 +6847,7 @@ pf_walk_header(struct pf_pdesc *pd, struct ip *h, u_short
*reason)
/* IGMP packets have router alert options, allow them */
if (pd->proto == IPPROTO_IGMP) {
/* According to RFC 1112 ttl must be set to 1. */
- if ((h->ip_ttl != 1) || !IN_MULTICAST(h->ip_dst.s_addr)) {
+ if ((h->ip_ttl != 1) && IN_MULTICAST(h->ip_dst.s_addr)) {
DPFPRINTF(LOG_NOTICE, "Invalid IGMP");
REASON_SET(reason, PFRES_IPOPTIONS);
return (PF_DROP);
@@ -7101,8 +7101,8 @@ pf_walk_header6(struct pf_pdesc *pd, struct ip6_hdr *h,
u_short *reason)
* missing then MLD message is invalid and
* should be discarded.
*/
- if ((h->ip6_hlim != 1) ||
- !IN6_IS_ADDR_LINKLOCAL(&h->ip6_src)) {
+ if ((h->ip6_hlim != 1) &&
+ IN6_IS_ADDR_LINKLOCAL(&h->ip6_src)) {
DPFPRINTF(LOG_NOTICE, "Invalid MLD");
REASON_SET(reason, PFRES_IPOPTIONS);
return (PF_DROP);
atactl: Update common SMART attribute names
The last times the attribute names were updated were 14 and 21 years ago.
Modern drives, especially SSDs, get a lot of Unknown columns from the
'readattr' command.
Attributes were coalesced from smartmontools, NetBSD's atactl, and Wikipedia's
citations. Manufacturer-specific attributes and overrides were not attempted,
as that's an imprecise art probably better left to smartmontools.
Thanks for your time.
Brian Conway
RCE Software, LLC
diff --git sbin/atactl/atactl.c sbin/atactl/atactl.c
index aaba61502..c4a1d20d5 100644
--- sbin/atactl/atactl.c
+++ sbin/atactl/atactl.c
@@ -309,6 +309,28 @@ struct valinfo ibm_attr_names[] = {
{ 11, "Calibration Retry Count" },
{ 12, "Device Power Cycle Count" },
{ 13, "Soft Read Error Rate" },
+ { 100, "Erase/Program Cycles" },
+ { 103, "Translation Table Rebuild" },
+ { 160, "Uncorrectable Error Count" },
+ { 170, "Reserved Block Count" },
+ { 171, "Program Fail Count" },
+ { 172, "Erase Fail Count" },
+ { 173, "Wear Worst Case Erase Count" },
+ { 174, "Power-Off Retract Count" },
+ { 175, "Program Fail Count" },
+ { 176, "Erase Fail Count" },
+ { 177, "Wear Leveling Count" },
+ { 178, "Used Reserved Block Count" },
+ { 179, "Used Reserved Block Count Total" },
+ { 180, "Unused Reserved Block Count Total" },
+ { 181, "Program Fail Count Total" },
+ { 182, "Erase Fail Count" },
+ { 183, "Runtime Bad Block" },
+ { 184, "End-to-End error" },
+ { 185, "Head Stability" },
+ { 186, "Induced Op-Vibration Detection" },
+ { 187, "Reported Uncorrectable Errors" },
+ { 188, "Command Timeout" },
{ 189, "High Fly Writes" },
{ 190, "Airflow Temperature" },
{ 191, "G-Sense Error Rate" },
@@ -341,8 +363,15 @@ struct valinfo ibm_attr_names[] = {
{ 228, "Power-Off Retract Count" },
{ 230, "GMR Head Amplitude" },
{ 231, "Temperature" },
+ { 232, "Available reserved space" },
+ { 233, "Media wearout indicator" },
+ { 235, "Power-Off Retract Count" },
{ 240, "Head Flying Hours" },
+ { 241, "Total LBAs Written" },
+ { 242, "Total LBAs Read" },
+ { 249, "NAND Writes (1GB)" },
{ 250, "Read Error Retry Rate" },
+ { 254, "Free Fall Sensor" },
{ 0, NULL },
};
Re: ttycreate from FreeBSD equivalent
Thanks for your reply. Yes, I'm using ttymalloc but I'm having a hard time telling where the terminal has attached to. For context, I'm working on adding support for a certain cardbus 3g modem. For a while I considered using puc at cardbus but it seems both the interrupt handling and the non standard terminal sequences warrant a full separate driver. I wondered if attaching com at this new device would make sense, but at the moment I'm taking the linux approach of implementing it's own tty code. At the moment I can initialize the card and process interrups, just need to figure out the tty bits. Here is the freebsd driver I'm using as reference (was also work in progress) http://web.archive.org/web/20080327050955/http://bsd.vwsoft.com/3g/nozomi/nozomi.c also, https://marc.info/?l=openbsd-tech&m=166127896828617&w=2
cwm: don't draw colors with alpha
Hello, When using a compositor within cwm, some programs (like chrome and firefox) get a percentage of transparency applied to their border, while others (like xterm) don't. This diff fixes that by explicitly setting the alpha channel value for each color to 0x. (If someone wants transparency on their window borders, this boldly assumes they want it uniform across all applications... which could be achieved with a fancier compositor than xcompmgr). Worthwhile? diff --git app/cwm/conf.c app/cwm/conf.c index 6459aa18f..ab6c161bd 100644 --- app/cwm/conf.c +++ app/cwm/conf.c @@ -505,6 +505,9 @@ conf_screen(struct screen_ctx *sc) } } + for (i = 0; i < CWM_COLOR_NITEMS; i++) + sc->xftcolor[i].color.alpha = 0x; + conf_grab_kbd(sc->rootwin); } -- mw
Re: Fix broken UTF-8 decoding
On Sat, Feb 25, 2023 at 08:29:54PM +0100, Steffen Nurpmeso wrote: > Crystal Kolipe wrote in > : > |Currently it is not possible to use unicode codepoints > 0xFF on the \ > |console, > |because our UTF-8 decoding logic is badly broken. > | > |The code in question is in wsemul_subr.c, wsemul_getchar(). > | > |The problem is that we calculate the number of bytes in a multi-byte > |sequence by just looking at the high bits in turn: > ... > |This is wrong, for several reasons. > > Just to note there are also holes, UTF-8 sequences are not > necessarily well-formed (per se -- maybe they are when you control > their generation, of course). It is actually a real mess Well, I did elude to further issues in my original post: Crystal Kolipe wrote: > The UTF-8 decoder still needs more work done on it to reject invalid > sequences such as over long encodings and the UTF-16 surrogates. If people would rather wait to change this until I can fix the other issues in the UTF-8 decoder then fine, but with what we've got in the tree at the moment, it's not possible to use characters beyond 0xFF. So the only use that we can make of unicode is to display the existing 'extended ASCII' characters using UTF-8 sequences instead of single character 8-bit ones. With the patch I provided, it should be possible to add glyphs for non-latin scripts, mathematical symbols, etc. That in turn allows people to test userland applications with other character sets, etc, highlight and fix any issues in those applications. And note that this doesn't add any bloat to the kernel, because all of the functionality needed to do this is already in there, (apart from the relevant font, obviously).
Re: Fix broken UTF-8 decoding
Crystal Kolipe wrote in
:
|Currently it is not possible to use unicode codepoints > 0xFF on the \
|console,
|because our UTF-8 decoding logic is badly broken.
|
|The code in question is in wsemul_subr.c, wsemul_getchar().
|
|The problem is that we calculate the number of bytes in a multi-byte
|sequence by just looking at the high bits in turn:
...
|This is wrong, for several reasons.
Just to note there are also holes, UTF-8 sequences are not
necessarily well-formed (per se -- maybe they are when you control
their generation, of course). It is actually a real mess:
if(LIKELY(x <= 0x7Fu))
c = x;
/* 0xF8, but Unicode guarantees maximum of 0x10u -> F4 8F BF BF.
* Unicode 9.0, 3.9, UTF-8, Table 3-7. Well-Formed UTF-8 Byte Sequences
*/
else if(LIKELY(x > 0xC0u && x <= 0xF4u)){
if(LIKELY(x < 0xE0u)){
if(UNLIKELY(l < 1))
goto jenobuf;
--l;
c = (x &= 0x1Fu);
}else if(LIKELY(x < 0xF0u)){
if(UNLIKELY(l < 2))
goto jenobuf;
l -= 2;
x1 = x;
c = (x &= 0x0Fu);
/* Second byte constraints */
x = S(u8,*cp++);
switch(x1){
case 0xE0u:
if(UNLIKELY(x < 0xA0u || x > 0xBFu))
goto jerr;
break;
case 0xEDu:
if(UNLIKELY(x < 0x80u || x > 0x9Fu))
goto jerr;
break;
default:
if(UNLIKELY((x & 0xC0u) != 0x80u))
goto jerr;
break;
}
c <<= 6;
c |= (x &= 0x3Fu);
}else{
if(UNLIKELY(l < 3))
goto jenobuf;
l -= 3;
x1 = x;
c = (x &= 0x07u);
/* Third byte constraints */
x = S(u8,*cp++);
switch(x1){
case 0xF0u:
if(UNLIKELY(x < 0x90u || x > 0xBFu))
goto jerr;
break;
case 0xF4u:
if(UNLIKELY((x & 0xF0u) != 0x80u)) /* 80..8F */
goto jerr;
break;
default:
if(UNLIKELY((x & 0xC0u) != 0x80u))
goto jerr;
break;
}
c <<= 6;
c |= (x &= 0x3Fu);
x = S(u8,*cp++);
if(UNLIKELY((x & 0xC0u) != 0x80u))
goto jerr;
c <<= 6;
c |= (x &= 0x3Fu);
}
x = S(u8,*cp++);
if(UNLIKELY((x & 0xC0u) != 0x80u))
goto jerr;
c <<= 6;
c |= x & 0x3Fu;
}else
goto jerr;
--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)
Fix broken UTF-8 decoding
Currently it is not possible to use unicode codepoints > 0xFF on the console,
because our UTF-8 decoding logic is badly broken.
The code in question is in wsemul_subr.c, wsemul_getchar().
The problem is that we calculate the number of bytes in a multi-byte
sequence by just looking at the high bits in turn:
if (frag & 0x20) {
frag &= ~0x20;
mbleft++;
}
if (frag & 0x10) {
frag &= ~0x10;
mbleft++;
}
if (frag & 0x08) {
frag &= ~0x08;
mbleft++;
}
if (frag & 0x04) {
frag &= ~0x04;
mbleft++;
}
This is wrong, for several reasons.
Firstly, since about 20 years ago, the maximum number of bytes in a UTF-8
sequence has been four, so we shouldn't be checking 0x08 and 0x04, (or rather
we should only check that 0x08 is 0 when 0x10 is 1 to indicate a four-byte
sequence.
Secondly, the check for 0x10 should only be performed when 0x20 is also set.
By chance, the current logic successfully decodes UTF-8 encodings of unicode
codepoints 0x80 - 0xFF, because these don't touch bits 2-4 of the first byte.
However, to use console fonts with more than 256 characters we need this
fixed. I created a font with an extra glyph at position 0x100, and am able to
use it once I had applied the attached patch.
The UTF-8 decoder still needs more work done on it to reject invalid
sequences such as over long encodings and the UTF-16 surrogates.
But it would be nice to get at least this fix in as it is trivial and allows
further experimentation with UTF-8 on the console using fonts with more than
256 glyphs.
I'll do a more detailed write-up about this at some time, but since I've
already had questions off-list about "why OpenBSD doesn't support more than
256 characters in a font", since I started posting the console patches, I
thought it would be good to get this patch out there.
--- wsemul_subr.c.dist Fri Oct 18 19:06:41 2013
+++ wsemul_subr.c Sat Feb 25 13:58:00 2023
@@ -125,20 +125,11 @@
if (frag & 0x20) {
frag &= ~0x20;
mbleft++;
+ if (frag & 0x10) {
+ frag &= ~0x10;
+ mbleft++;
+ }
}
- if (frag & 0x10) {
- frag &= ~0x10;
- mbleft++;
- }
- if (frag & 0x08) {
- frag &= ~0x08;
- mbleft++;
- }
- if (frag & 0x04) {
- frag &= ~0x04;
- mbleft++;
- }
-
tmpchar = frag;
}
}
Re: ttycreate from FreeBSD equivalent
On 2023/02/25 11:32, jon@elytron.openbsd.amsterdam wrote: > Hello, I'm in the process of adapting a driver from freebsd to > openbsd. I was wondering what I should use in place of a call like > ttycreate(tmptty, TS_CALLOUT, "N%r", i); > > any hints appreciated, tmptty is a struct tty from /sys/kern/tty.c > (openbsd) Probably something involving ttymalloc. That must be rather old FreeBSD code I think? They don't sem to have used ttycreate for a long time either.
ttycreate from FreeBSD equivalent
Hello, I'm in the process of adapting a driver from freebsd to openbsd. I was wondering what I should use in place of a call like ttycreate(tmptty, TS_CALLOUT, "N%r", i); any hints appreciated, tmptty is a struct tty from /sys/kern/tty.c (openbsd)
Re: iwx(4) -77 firmware diff for testing
Hi Stefan, thanks for your work. I also can confirm your patch. Thanks, Sven On 2/24/23 10:36, Mikhail wrote: On Wed, Feb 22, 2023 at 03:31:28PM +0100, Stefan Sperling wrote: Below is my work-in-progress diff to update iwx(4) to latest firmware. Every system tracking -current should already have the new -77 firmware images. The new images contain security fixes of (to me) unknown severity. Unfortunately there have been quite a number of firmware API changes since our last upgrade and it took me quite some time to get all the required new bits in place and arrive at an operational state. While testing please enable additional debug output with: ifconfig iwx0 debug To activate it at boot time: echo debug >> /etc/hostname.iwx0 There are some known issue with occasional firmware errors. My devices eventually manage to connect and work regardless. If you see a firmware error in dmesg please include the extra information shown in dmesg after enabling the debugging mode as above. This information is hidden by default and the driver will only print "fatal firmware error" to dmesg without more context, but the extra context is needed for debugging. If you hit an error which looks like this: iwx0: firmware parse error 22, section type 19 iwx0: failed to load init firmware Then you will need to increase this constant in if_iwxvar.h until you get past the error: #define IWX_UCODE_SECT_MAX 56 It will probably just need a +1 or +2. It is possible to find the required maximum by parsing all the firmware files, but I haven't gotten around to that yet. Tested and known to work with occasional firmware errors on: iwx0 at pci2 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix iwx0: hw rev 0x340, fw 77.f92b5fed.0 iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x00, msix iwx0: hw rev 0x350, fw 77.f92b5fed.0, iwx0 at pci4 dev 0 function 0 "Intel Wi-Fi 6 AX210" rev 0x1a, msix iwx0: hw rev 0x420, fw 77.f92b5fed.0, pnvm dbd9582f, iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x20, msix iwx0: hw rev 0x350, fw 77.f92b5fed.0, address X iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX211" rev 0x01, msix iwx0: hw rev 0x370, fw 77.f92b5fed.0, pnvm dbd9582f, address X Working fine. AX211 required IWX_UCODE_SECT_MAX 57 to start. Tested with usual activity and iperf3 --bidir overnight. iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x01, msix iwx0: hw rev 0x350, fw 77.f92b5fed.0
