On Wed, Aug 30, 2023 at 02:07:53PM +0800, Kevin Lo wrote:
> nvme0 at pci3 dev 0 function 0 vendor "Phison", unknown product 0x5021 rev
> 0x01: intx, NVMe 1.4
> nvme0: TEAM TM8FPK500G, firmware ELFMB0.6, serial TPBF2210110040500017
>
> The diff below adds another Phison NVMe device id.
> ok?
they
nvme0 at pci3 dev 0 function 0 vendor "Phison", unknown product 0x5021 rev
0x01: intx, NVMe 1.4
nvme0: TEAM TM8FPK500G, firmware ELFMB0.6, serial TPBF2210110040500017
The diff below adds another Phison NVMe device id.
ok?
Index: sys/dev/pci/pcidevs
===
On Tue, Aug 29, 2023 at 09:15:41PM +0200, Mark Kettenis wrote:
>
> > Date: Tue, 29 Aug 2023 11:58:23 +0200
> > From: Mark Kettenis
> >
> > Upstreaming of the JH7110 PCIe device tree bindings isn't finished
> > yet, but it seems some progress has been made and things have been
> > reviewed by som
Hi Neel,
Neel Chauhan wrote on Tue, Aug 29, 2023 at 02:36:57PM -0700:
> On 2023-08-29 14:23, Theo Buehler wrote:
>> Neel Chauhan:
>>> + if (string[strlen(string) - 1] == '.')
>>> + buf[strlen(string) - 1] = '\0';
>> Careful with out-of-bounds accesses. What if string is "" ? Probably
On 2023-08-29 17:21, Ingo Schwarze wrote:
Hi Neel,
Neel Chauhan wrote on Tue, Aug 29, 2023 at 02:48:54PM -0700:
I have noticed a bug. When running "sysctl ." or "sysctl kern."
without
my other patch, I get an extra space between "name" and "in":
sysctl: top level name in . is invalid
Te
Hi Neel,
Neel Chauhan wrote on Tue, Aug 29, 2023 at 02:48:54PM -0700:
> I have noticed a bug. When running "sysctl ." or "sysctl kern." without
> my other patch, I get an extra space between "name" and "in":
>> sysctl: top level name in . is invalid
Technically, that message is correct. The
Hi,
I have noticed a bug. When running "sysctl ." or "sysctl kern." without
my other patch, I get an extra space between "name" and "in":
sysctl: top level name in . is invalid
It should be:
sysctl: top level name in . is invalid
I also have a patch.
What this patch does is if the top
On 2023-08-29 14:23, Theo Buehler wrote:
+ if (string[strlen(string) - 1] == '.')
+ buf[strlen(string) - 1] = '\0';
Careful with out-of-bounds accesses. What if string is "" ? Probably
easiest to do "len = strlen(string);" and if (len > 0 && ...).
Good catch!
Does this lo
> + if (string[strlen(string) - 1] == '.')
> + buf[strlen(string) - 1] = '\0';
Careful with out-of-bounds accesses. What if string is "" ? Probably
easiest to do "len = strlen(string);" and if (len > 0 && ...).
Hi,
I don't know if this is a big issue for you, but when
doing a `sysctl` call with a trailing period ("."),
like `sysctl kern.`, I get an error like this:
sysctl: second level name in kern. is invalid
On other systems, if I do `sysctl XX.`, I get all the
entries inside XX. We should fix it
Hi,
I tested your patch and it is a great improvement for me.
My vms are hanging reproducible without your fix.
Thank you
Florian
Am Di., 29. Aug. 2023 um 18:01 Uhr schrieb Dave Voutila :
>
> Dave Voutila writes:
>
> > mbuhl@ found an issue where the emulated virtio block device can
> > h
> Date: Tue, 29 Aug 2023 11:58:23 +0200
> From: Mark Kettenis
>
> Upstreaming of the JH7110 PCIe device tree bindings isn't finished
> yet, but it seems some progress has been made and things have been
> reviewed by some of the key people involved:
>
> https://patchwork.kernel.org/project/linu
Dave Voutila writes:
> mbuhl@ found an issue where the emulated virtio block device can
> hang. The tl;dr: the emulated pic never injects an interrupt and the
> vioblk(4) driver in the guest starves, waiting to be told to check the
> virtqueue.
>
> Flipping the bit in the i8259 using gdb causes
Upstreaming of the JH7110 PCIe device tree bindings isn't finished
yet, but it seems some progress has been made and things have been
reviewed by some of the key people involved:
https://patchwork.kernel.org/project/linux-pci/list/?series=779297
Here is a diff that adjusts the driver to the cur
On Mon, Aug 28, 2023 at 10:03:46PM +0200, Theo Buehler wrote:
> On Mon, Aug 28, 2023 at 09:18:40PM +0200, Marc Espie wrote:
> > On Mon, Aug 28, 2023 at 08:42:50PM +0200, Marc Espie wrote:
> > > Turns out the exec in cmd_exec.c has absolutely zero reason to be
> > > different from what engine does.
15 matches
Mail list logo