Re: the vine package in pkgin is wine64?
On Fri, Nov 11, 2022 at 10:41:15PM +, r0ller wrote: > Running 32 bit win stuff does not work with that. I'm running 32-bit only WINE programs in a 32-bit NetBSD chroot (using sandboxctl). It works okay: https://washbear.neocities.org/wine-sandbox.html
Re: can not download IMAP messages with isync/mbsync
>> My guess is that the buffer you're testing with is near the top of >> the address space, within ~1GB of address 0x, and what >> you're seeing is due to wraparound. > Thanks for that analysis--address-wrapping was my first guess too, > but, I didn't have the time to confirm it: the 1GB was with a > standalone program; in mbsync itself, the range was much > smaller--less than 1MB even. I haven't confirmed it myself. I don't have an ARM machine running anything more recent than 4.0.1 (and that much only quite recently - I found my shark in storage and am only just getting it back in full operation). 4.0.1 appears to not even _have_ strnlen. But my reading of the assembly code I found in 9.1's /usr/src matches the behaviour you describe far too well for me to think it's entirely coincidence; I'm fairly fairly confident of my analysis. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: can not download IMAP messages with isync/mbsync
On Mon, 14 Nov 2022, Mouse wrote: My guess is that the buffer you're testing with is near the top of the address space, within ~1GB of address 0x, and what you're seeing is due to wraparound. Thanks for that analysis--address-wrapping was my first guess too, but, I didn't have the time to confirm it: the 1GB was with a standalone program; in mbsync itself, the range was much smaller--less than 1MB even. Also, - uint maxlen = UINT_MAX; + uint maxlen = sizeof(buf); if maxlen is passed unchanged to strnlen, I can't see how the original code isn't a bug; there's no point in using strnlen if you're pass a maxlen greater than the space remaining in the buffer your pointer points into. It _is_ passed as-is to strnlen(). I chose sizeof(buf) instead of UINT_MAX because `buf' seemed sized for the RFC-5322 recommended line-length limit of 998 octets. The 9.1 manpage for strnlen says The strnlen() function returns either the same result as strlen() or maxlen, whichever is smaller. which makes this a violation of its spec. Right, then Marko can file a PR so that this can be fixed a) either in the ARM assembly, or b) by NetBSD-ARM just using the C version like the other ports. Thx, -RVP
Re: noob Question: How to format a floppy on a USB floppy disk drive (on RPi 4) ?
On Mon, Nov 14, 2022 at 09:33:07AM -0800, Michael Cheponis wrote: > *# scsictl sd1 format/dev/rsd1: device had unknown status 4* Is there any other message (on console) ? There are 3 cases that produce a 'status 4': - "have short sense" (printed only with SCSI debugging) - "passthrough: adapter inconsistency" - "unknown error category %d from adapter" Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: apache parked processes using CPU
Jan Schaumann wrote: > PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND > 21048 nobody420 316M 14M parked 5:28 7.32% 7.32% httpd > 17677 nobody420 318M 14M parked 5:25 6.69% 6.69% httpd > 16398 nobody410 319M 17M parked18:53 5.03% 5.03% httpd > 829 nobody410 320M 18M parked18:59 4.83% 4.83% httpd > 21512 nobody420 322M 19M parked18:49 4.74% 4.74% httpd > 23308 nobody420 322M 19M parked18:51 1.61% 1.61% httpd > 0 root 1250 0K 20M vdrain11:44 0.00% 0.00% [system] > > This is new behavior that began without my having made > any changes to the system on which httpd has been > running for years without such problems. I still can't make neither heads nor tails out of this. I've chased a few dead ends, such as considering a filesystem problem on the disk that the content is served from: I had recently done some very heavy I/O on that disk with millions of files in very large directories, but there were no signs of filesystem corruption and serving content from a different disk didn't solve this. (I followed that trail only because it was literally the only thing that I could think of that had changed from when the problem started to occur.) Right now I'm looking at vmstat output, and noting an increase in page faults that seems to correlate with the httpd server becoming increasingly unresponsive. Restarting httpd brings that down, but I have no explanation as to why they started to happen so recently. Given that this is a virtual server, could it be a problem in the actual hardware or the virtualization layer, i.e., outside of what I can see on the system? I kinda feel like blaming some hardware... :-) -Jan
Re: noob Question: How to format a floppy on a USB floppy disk drive (on RPi 4) ?
*# scsictl sd1 format/dev/rsd1: device had unknown status 4* The dd trick seems to work only if the diskette is pre-formatted. great suggestions, thank you. I'll keep whacking at this. -Mike On Mon, Nov 14, 2022 at 9:11 AM Michael van Elst wrote: > michael.chepo...@gmail.com (Michael Cheponis) writes: > > >I would think 'fdformat' would work, but... > > >*arm64# ./fdformat -f /dev/rsd1 > >*fdformat: Device `/dev/rsd1' does not support floppy formatting: > >Inappropriate ioctl for device* > > > Try 'scsictl sd1 format'. > >
Re: noob Question: How to format a floppy on a USB floppy disk drive (on RPi 4) ?
michael.chepo...@gmail.com (Michael Cheponis) writes: >I would think 'fdformat' would work, but... >*arm64# ./fdformat -f /dev/rsd1 >*fdformat: Device `/dev/rsd1' does not support floppy formatting: >Inappropriate ioctl for device* Try 'scsictl sd1 format'.
Re: can not download IMAP messages with isync/mbsync
> Or is UINT_MAX not guaranteed to fit in size_t
I _think_ there is no guarantee that UINT_MAX fits in a size_t. But,
upthread, I see...
> Turn out, on ARM, strnlen(3) is written in assembly and this always
> returns `maxlen' for any value of `maxlen' > ~1GB.
Not quite.
I have a guest login on a 9.1 machine, and found the ARM strnlen there.
I am not an ARM expert, but I know it enough to, I think, find and
explain the bug.
My guess is that the buffer you're testing with is near the top of the
address space, within ~1GB of address 0x, and what you're
seeing is due to wraparound.
Here's the relevant code (from 9.1):
addsr5, r0, r1 /* get ptr to end of string */
mov r4, r1 /* save maxlen */
...
.Lmain_loop:
#ifdef STRNLEN
cmp r0, r5 /* gone too far? */
bge .Lmaxed_out /* yes, return maxlen */
#endif
(The code at .Lmaxed_out just returns maxlen, as the comment implies.)
Back-translating loosely into C, what we have here is
strnlen(const char *buf, int maxlen)
{
const char *end;
end = buf + maxlen;
...
while (1) {
if (buf > end)
return(maxlen);
...
}
}
This back-translation is, of course, broken from a C perspective, but
it's supposed to be illustrative, not precise. The bug: if buf+maxlen
overflows (at the machine-code level, on ARM32, buf, maxlen, and end
are each just 32-bit integers), then buf>end can be true right from the
start, terminating the loop (and returning maxlen) before it should.
The 9.1 manpage for strnlen says
The strnlen() function returns either the same result as strlen() or
maxlen, whichever is smaller.
which makes this a violation of its spec. The only way it could be
non-broken is if size_t's range and the address space layout
collaborate to ensure that string + maxlen can't wrap around. Since I
think both are 32-bit on (32-bit) ARM, this isn't so.
Also,
- uint maxlen = UINT_MAX;
+ uint maxlen = sizeof(buf);
if maxlen is passed unchanged to strnlen, I can't see how the original
code isn't a bug; there's no point in using strnlen if you're pass a
maxlen greater than the space remaining in the buffer your pointer
points into. I'd have to look at more of the surrounding code to be
sure, though. (It also depends on nonportable assumptions about the
relative sizes of uint and size_t, but that bug is concealed on 32-bit
NetBSD.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: can not download IMAP messages with isync/mbsync
On Mon, Nov 14, 2022 at 09:48:50AM -0500, Greg Troxel wrote: > That's why it is harder to meet the spec than it first seems. C > doesn't offer UB for such arguments, so it should be fixed. (I'm not > asking anyone to do the work - just to agree it's broken.) I am not sure it is broken, but how would you fix it? Effectively you could only detect the out of bounds maxlen and return the value of strlen() instead - but that sounds like a super stupid idea. Martin
Re: can not download IMAP messages with isync/mbsync
Martin Husemann writes: > On Mon, Nov 14, 2022 at 08:17:32AM -0500, Greg Troxel wrote: >> I am not arguing against fixing the code to be sane. I am just raising >> the other question about maybe strnlen needs fixing. > > "s + maxlen" (for most s) wraps around on 32bit architectures so the > typical implementation will notice the current char * being >= that > limit and claim we ran too far. That's why it is harder to meet the spec than it first seems. C doesn't offer UB for such arguments, so it should be fixed. (I'm not asking anyone to do the work - just to agree it's broken.) signature.asc Description: PGP signature
Re: can not download IMAP messages with isync/mbsync
On Mon, Nov 14, 2022 at 08:17:32AM -0500, Greg Troxel wrote: > I am not arguing against fixing the code to be sane. I am just raising > the other question about maybe strnlen needs fixing. "s + maxlen" (for most s) wraps around on 32bit architectures so the typical implementation will notice the current char * being >= that limit and claim we ran too far. Martin
Re: noob Question: How to format a floppy on a USB floppy disk drive (on RPi 4) ?
I found 2 old amd64 floppy images from 2.0. No idea why I still have these: -rwxr--r-- 1 andy andy 1474560 Nov 30 2004 boot1.fs -rwxr--r-- 1 andy andy 1474560 Nov 30 2004 boot2.fs Can you try writing a file of that size to one of those /dev/rsd files using dd? (The man page for fdformat says 2006, I'm surprised it's that new.) Andy
Re: can not download IMAP messages with isync/mbsync
Martin Husemann writes: > On Mon, Nov 14, 2022 at 01:22:54PM +0100, Marko Bauhardt wrote: >> I configured to not use the system strnlen as you suggested. this works fine. >> i'm able to fetch my mails. >> THX!! > > The patch is the better solution, the length passed to strnlen is > obviously bogus. Yes, it's crazy. But isn't strnlen failing to meet its specification? Or is UINT_MAX not guaranteed to fit in size_t and we're getting truncation? I am not arguing against fixing the code to be sane. I am just raising the other question about maybe strnlen needs fixing. signature.asc Description: PGP signature
Re: can not download IMAP messages with isync/mbsync
On Mon, Nov 14, 2022 at 01:22:54PM +0100, Marko Bauhardt wrote: > I configured to not use the system strnlen as you suggested. this works fine. > i'm able to fetch my mails. > THX!! The patch is the better solution, the length passed to strnlen is obviously bogus. Martin
Re: can not download IMAP messages with isync/mbsync
> RVP hat am 14.11.2022 08:46 CET geschrieben: hey rvp you are the greatest! awesome. > ...Turn out, on ARM, strnlen(3) is written in assembly > and this always returns `maxlen' for any value of `maxlen' > ~1GB. > The fix > is either: > > a) Configure isync-1.4.4 to _not_ use the system strnlen(). It will > then use its own implementation which seems to work fine. > > ``` > $ env ac_cv_func_strnlen=no ./configure ... > $ make > $ make install > ``` I configured to not use the system strnlen as you suggested. this works fine. i'm able to fetch my mails. THX!! I will cross post this to the isync-mailinglist to let the devs know what the actual issue is. thx marko
noob Question: How to format a floppy on a USB floppy disk drive (on RPi 4) ?
I would think 'fdformat' would work, but... *[ 1063553.609981] umass1 at uhub2 port 3 configuration 1 interface 0* *[ 1063553.612982] umass1: TEACV0.0 (0x0644) TEACV0.0 (0x), rev 1.10/2.00, addr 3* *[ 1063553.620984] umass1: using UFI over CBI with CCI* *[ 1063553.621985] atapibus0 at umass1: 2 targets* *[ 1063553.692011] sd1 at atapibus0 drive 0: disk removable* *[ 1063554.506165] sd1: 1440 KB, 80 cyl, 2 head, 18 sec, 512 bytes/sect x 2880 sectors* *# disklabel sd1 * *# /dev/rsd1:* *type: ATAPI* *disk: USB UF000x* *label: default label* *flags: removable* *bytes/sector: 512* *sectors/track: 18* *tracks/cylinder: 2* *sectors/cylinder: 36* *cylinders: 80* *total sectors: 2880* *rpm: 10240* *interleave: 1* *trackskew: 0* *cylinderskew: 0* *headswitch: 0 # microseconds* *track-to-track seek: 0 # microseconds* *drivedata: 0* *3 partitions:* *#sizeoffset fstype [fsize bsize cpg/sgs]* * a: 2880 0 4.2BSD 0 0 0 # (Cyl. 0 - 79)* * c: 2880 0 unused 0 0# (Cyl. 0 - 79)* *disklabel: boot block size 0* *disklabel: super block size 0* *arm64# ./fdformat -f /dev/rsd1 * *fdformat: Device `/dev/rsd1' does not support floppy formatting: Inappropriate ioctl for device* *arm64# ./fdformat -f /dev/rsd1a * *fdformat: Device `/dev/rsd1a' does not support floppy formatting: Inappropriate ioctl for device* *arm64# ./fdformat -f /dev/rsd1c * *fdformat: Device `/dev/rsd1c' does not support floppy formatting: Inappropriate ioctl for device* *arm64# ./fdformat -f /dev/rsd1e * *fdformat: Cannot open /dev/rsd1e: Device not configured* *NetBSD arm64 9.99.102 NetBSD 9.99.102 (MIKE64) #0: Wed Oct 26 22:54:20 UTC 2022 mac@arm64:/usr/obj/sys/arch/evbarm/compile/MIKE64 evbarm* (same as GENERIC64 but HZ=1000) mtools expects there to be a low-level format available from the OS. Thanks for any pointers here! The other thing is: if I format on a different machine, when reading / writing and some floppy HW error occurs, pretty much, the only way to 'clear' the error is to unplug the USB connector & plug it back in. The machine more or less 'hangs' if, e.g., a sector has gone bad. I know these questions are from a different era of computing, but, gosh, I do really like the backward compatibility of NetBSD. Thanks again, -Mike
