Error message is gone, so I assume it fixes the issue.
On Sun, Jul 26, 2020 at 8:22 AM Taylor R Campbell wrote:
>
> > Date: Fri, 24 Jul 2020 00:35:19 +0300
> > From: Andrius V
> >
> > > > Cool! Is it reproducible? You can trigger reading from the RNG with:
> > > >
> > > > sysctl
> Date: Fri, 24 Jul 2020 00:35:19 +0300
> From: Andrius V
>
> > > Cool! Is it reproducible? You can trigger reading from the RNG with:
> > >
> > > sysctl kern.entropy.gather=1
>
> Tested, no messages are triggered for amd64, but sysctl
> kern.entropy.gather value is always 0:
> sysctl -w
> > Cool! Is it reproducible? You can trigger reading from the RNG with:
> >
> > sysctl kern.entropy.gather=1
> >
Tested, no messages are triggered for amd64, but sysctl
kern.entropy.gather value is always 0:
sysctl -w kern.entropy.gather=1
kern.entropy.gather: 0 -> 1
For i386, same, no
On Wed, Jul 22, 2020 at 4:34 AM Taylor R Campbell wrote:
>
> Is there any documentation for the graphics hardware? Is hardware
> available on the market in the US? (Can you send me any?)
>
Seems like required graphics datasheets are available here:
https://www.x.org/docs/via/ and chipset
> Date: Wed, 22 Jul 2020 03:17:21 +0300
> From: Andrius V
>
> Not sure how useful to work on this though. Linux doesn't seem to have
> newer graphics IDs in VIA DRM driver too (possibly abandoned over new
> effort?). Currently Xorg server starts on VX900, but screen complains
> with "Input
On Tue, Jul 21, 2020 at 12:31 AM Taylor R Campbell wrote:
>
> > Date: Tue, 21 Jul 2020 00:16:16 +0300
> > From: Andrius V
> >
> > After a bit more investigation, yes, it is kassert (kernel diagnostic
> > assertion "viadrm_pci_ids[i].subvendor == PCI_ANY_ID" ), doesn't
> > matter amd64/i386.
>
>
On Sun, Jul 19, 2020 at 6:00 PM Taylor R Campbell
wrote:
>
> I guess we could do that. It's not really that useful -- the only
> application it's good for is in-kernel IPsec. OpenSSL should already
> be able to take advantage of the CPU support in userland -- no kernel
> driver needed.
>
> (I
> Date: Mon, 20 Jul 2020 21:31:20 +
> From: Taylor R Campbell
>
> > Date: Tue, 21 Jul 2020 00:16:16 +0300
> > From: Andrius V
> >
> > After a bit more investigation, yes, it is kassert (kernel diagnostic
> > assertion "viadrm_pci_ids[i].subvendor == PCI_ANY_ID" ), doesn't
> > matter
> Date: Tue, 21 Jul 2020 00:16:16 +0300
> From: Andrius V
>
> After a bit more investigation, yes, it is kassert (kernel diagnostic
> assertion "viadrm_pci_ids[i].subvendor == PCI_ANY_ID" ), doesn't
> matter amd64/i386.
Panic should be fixed in via_pci 1.3.
>The cause
On Mon, Jul 20, 2020 at 8:38 AM Taylor R Campbell wrote:
> >
> > I am planning to submit PR once I will retest the driver with the latest
> > images. Actually, it may not be amd64 specific after all. Crash happens
> > during boot on match function, likely newer graphics are unsupported and
> >
> Date: Mon, 20 Jul 2020 08:16:34 +0300
> From: Andrius V
>
> Considering it is limited usage isn't the kernel module actually more
> useful, since you can add it to boot config once you really need it?
> Unless, in-kernel functionality won't work with the kernel module for some
> reason.
> Date: Sun, 19 Jul 2020 14:16:25 +0300
> From: Andrius V
>
> I just noticed that padlock driver was made to compile on amd64
> recently. I believe it should be included in modules Makefile
> (/sys/modules/Makefile) as well (as per my git diff in previous
> messages).
I guess we could do that.
Hi,
I just noticed that padlock driver was made to compile on amd64
recently. I believe it should be included in modules Makefile
(/sys/modules/Makefile) as well (as per my git diff in previous
messages).
Index: sys/modules/Makefile
Hi,
I accidentally noticed that padlock engine is not included on AMD64
port (neither as module or built-in). Is there any reason it excluded
from it? The build currently fails because inline asm code is using
pushl, popl instructions in the code in via_padlock_cbc method, but
replacing them with
14 matches
Mail list logo
