On Fri, Sep 18, 2020 at 03:59:05PM -0500, Scott Cheloha wrote:
>
> [...]
>
> - An HH:MM:SS format uptime is useful in top(1). It's also more
> visually consistent with the local timestamp printed on the line
> above it, so it is easier to read at a glance.
>
> - The variable printing of
On Mon, Aug 08, 2022 at 01:03:13AM +0300, Vitaliy Makkoveev wrote:
> > I prefer the first idiom. If there is an error, do something. We
> > should not change the style in opposite direction. This will prevent
> > consistency.
> >
>
> I???m not entirely understand you. When we have something
> On 7 Aug 2022, at 23:18, Alexander Bluhm wrote:
>
> On Sun, Aug 07, 2022 at 03:53:27AM +0300, Vitaliy Makkoveev wrote:
>> Please note, the `so_pcb' can't be NULL. We nullify it only on dead
>> socket, which should not be passed to (*pr_userreq)(). The newly created
>> socket has `so_pcb'
On Sun, Aug 07, 2022 at 03:53:27AM +0300, Vitaliy Makkoveev wrote:
> Please note, the `so_pcb' can't be NULL. We nullify it only on dead
> socket, which should not be passed to (*pr_userreq)(). The newly created
> socket has `so_pcb' set to NULL only until we pass it to (*pr_attach)()
> and we
Hi,
Sometimes I see "re0: watchdog timeout" message on my amd64 PC.
bios0: ASRock A88M-G/3.1
cpu0: AMD A10-7860K Radeon R7, 12 Compute Cores 4C+8G, 3593.88 MHz
re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E
(note: re0 is not A88M-G on-board controller, added PCIe board)
On Sun, Jul 31, 2022 at 01:28:18PM -0500, Scott Cheloha wrote:
> Apparently mips64, i.e. octeon and loongson, has the same problem as
> powerpc/macppc and powerpc64. The timer interrupt is normally only
> logically masked, not physically masked in the hardware, when we're
> running at or above
I'm not sure httpd(8) handles correctly when the fastcgi application
(e.g. slowcgi) closes the connection prematurely.
To verify it, I'm playing with three simple CGI scripts running under
slowcgi with a very low timeout (-t2). The scripts test "hangs"
(which slowcgi turns into hard
