Hi tech@,
Add device IDs of the VIA VX900 chipset.
Attaching a dmesg from my HP t510 Thin Client.
Comments? OK?
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1851
diff -u -p -r1.1851
On Tue, Jun 05, 2018 at 10:04:52PM +1000, Jonathan Gray wrote:
> > VIA C7 CPUs support Enhanced SpeedStep, so reflect that in cpu.4.
> >
> > On the VIA C7 1.5Ghz:
> >
> > cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.51 GHz
> > cpu0:
> > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,APIC,SEP
On Sun, Jul 01, 2018 at 06:13:43PM +0200, Mark Kettenis wrote:
> Diff below actually enables acpi(4) on arm64. Mostly stubs for bits of code
> that isn't needed on hardware-reduced ACPI. But the functions have to be
> there for things to compile.
>
> This is enough to boot my MACCHIATOBin mult
On Sun, Jul 01, 2018 at 04:59:47PM +0200, Mark Kettenis wrote:
> Diff below moves the attach glue from acpi.c into acpi_machdep.c.
> Gets rid of an #ifdef and helps me avoid an ugly hack on arm64. There
> is some additional code duplication, but I think this is acceptable.
>
> ok?
>
ok mlarkin,
On Sun, Jul 01, 2018 at 04:38:35PM +0200, Mark Kettenis wrote:
> Since the ARM SBSA Generic UART is effectively a PL011 UART, the
> expectation is that most arm64 servers will actually have pluart(4) as
> their serial console instead of com(4). So we need a glue for
> acpi(4). This provides that
On Sun, Jul 01, 2018 at 02:15:04PM +0200, Mark Kettenis wrote:
> Diff below makes it possible to attach ahci(4) at acpi(4) as required by
> arm64 machines like the MACCHIATOBin and Overdrive 1000.
>
> ok?
>
ok mlarkin
>
> Index: dev/acpi/ahci_acpi.c
> ==
On Fri, Jun 29, 2018 at 04:21:17PM +0200, Alexander Bluhm wrote:
> The problem is that POSIX has signals that are sent to processes
> and signals sent to individual threads. Our kernel does not support
> this properly.
Well, not exactly. POSIX has synchronous and asynchronous signals. I.e.
SIGFPE
Diff below actually enables acpi(4) on arm64. Mostly stubs for bits of code
that isn't needed on hardware-reduced ACPI. But the functions have to be there
for things to compile.
This is enough to boot my MACCHIATOBin multi-user. A few more drivers
are coming, the crucial bit being pci(4) supp
On Sun, Jul 1, 2018 at 8:00 AM Mark Kettenis
wrote:
> Diff below moves the attach glue from acpi.c into acpi_machdep.c.
> Gets rid of an #ifdef and helps me avoid an ugly hack on arm64. There
> is some additional code duplication, but I think this is acceptable.
>
> ok?
>
Fewer ifdefs, yay. ok
Diff below moves the attach glue from acpi.c into acpi_machdep.c.
Gets rid of an #ifdef and helps me avoid an ugly hack on arm64. There
is some additional code duplication, but I think this is acceptable.
ok?
Index: arch/amd64/amd64/acpi_machdep.c
===
Since the ARM SBSA Generic UART is effectively a PL011 UART, the
expectation is that most arm64 servers will actually have pluart(4) as
their serial console instead of com(4). So we need a glue for
acpi(4). This provides that glue and moves the shared code from
dev/fdt to dev/ic.
ok?
P.S. This
Diff below makes it possible to attach ahci(4) at acpi(4) as required by
arm64 machines like the MACCHIATOBin and Overdrive 1000.
ok?
Index: dev/acpi/ahci_acpi.c
===
RCS file: dev/acpi/ahci_acpi.c
diff -N dev/acpi/ahci_acpi.c
--- /d
On 29/06/18(Fri) 16:21, Alexander Bluhm wrote:
> On Thu, Jun 28, 2018 at 01:54:29PM +0200, Martin Pieuchot wrote:
> > > It may happen that the worker thread is in the signal handler and
> > > also blocks the signals.
> >
> > Are you saying that the worker thread modified its mask itself, via
> > a
On 30/06/18(Sat) 23:47, David Bern wrote:
> > Note that your diff doesn't apply. You have tab vs spaces issues.
> Sorry about that, it seems like I need to setup a proper mail-client.
>
> > I don't understand what you're talking about. Can you give example of
> > the 3 scenarios you're talking a
14 matches
Mail list logo