On Sun, Jul 24, 2022 at 02:16:23AM -0400, Daniel Dickman wrote:
>http://datasheets.chipdb.org/Rise/
>
>Quoting the data sheet from this link:
>
>“The CMPXCHG8B instruction is supported and always enabled on the Rise
>mP6 processor; however, the default CPUID function bit is set to
On Sun, Jul 24, 2022 at 02:25:02PM +1000, Jonathan Gray wrote:
> On Sat, Jul 23, 2022 at 02:13:27PM -0400, Daniel Dickman wrote:
> > The Rise mp6 was a short lived processor that was announced around 20+
> > years and didn't make it to market.
> >
> > I think we can delete the cpu identification
On Jul 24, 2022, at 12:25 AM, Jonathan Gray wrote:On Sat, Jul 23, 2022 at 02:13:27PM -0400, Daniel Dickman wrote:The Rise mp6 was a short lived processor that was announced around 20+ years and didn't make it to market.I think we can delete the cpu identification for this cpu at this point.ok?I a
include cpuid 0 string in dmesg for fw_update
Intel CPUs used to have brand strings such as
cpu0: Intel(R) Pentium(R) M processor 1200MHz ("GenuineIntel" 686-class) 1.20
GHz
cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.61 MHz, 06-3d-04
recent CPUs use
cpu0: 11th Gen Intel(R) Core(TM) i5-1
On Sat, Jul 23, 2022 at 02:13:27PM -0400, Daniel Dickman wrote:
> The Rise mp6 was a short lived processor that was announced around 20+
> years and didn't make it to market.
>
> I think we can delete the cpu identification for this cpu at this point.
>
> ok?
I am ok with removing it, but I thi
Okay, we did this for powerpc/macppc, on to powerpc64.
It's roughly the same problem as before:
- On powerpc64 we need to leave the DEC unmasked at or above
IPL_CLOCK.
- Currently we defer clock interrupt work to the next tick if a DEC
interrupt arrives when the CPU's priority level is at or
fine
Daniel Dickman wrote:
> The Rise mp6 was a short lived processor that was announced around 20+
> years and didn't make it to market.
>
> I think we can delete the cpu identification for this cpu at this point.
>
> ok?
>
> Index: i386/machdep.c
> =
On Sat, Jul 23, 2022 at 02:13:27PM -0400, Daniel Dickman wrote:
> The Rise mp6 was a short lived processor that was announced around 20+
> years and didn't make it to market.
>
> I think we can delete the cpu identification for this cpu at this point.
>
> ok?
ok mlarkin
>
> Index: i386/machdep.c
The Rise mp6 was a short lived processor that was announced around 20+
years and didn't make it to market.
I think we can delete the cpu identification for this cpu at this point.
ok?
Index: i386/machdep.c
===
RCS file: /cvs/src/sy
ok mvs@
> On 23 Jul 2022, at 03:15, Alexander Bluhm wrote:
>
> Hi,
>
> The IPv6 reassembly code looks MP safe. So we can run it in parallel.
> Note that ip_ours() runs with shared netlock, while ip_local() has
> exclusive netlock after queuing.
>
> ok?
>
> bluhm
>
> Index: netinet/ip_input.
ok mvs@
> On 22 Jul 2022, at 22:43, Alexander Bluhm wrote:
>
> Hi,
>
> During regress testing I found this bug.
>
> splassert: rip6_input: want 1 have 2
> Starting stack trace...
> rip6_input(1,2,d0c6b7ad,f57ff9fc) at rip6_input+0x166
> rip6_input(f57ffbfc,f57ffbe8,3a,18) at rip6_input+0x166
>
On Sat, Jul 23, 2022 at 02:16:16PM +0200, Moritz Buhl wrote:
> On Thu, Jul 21, 2022 at 10:25:09PM +0100, Jason McIntyre wrote:
> ...
> > it looks like the "set limit" text in pf.conf(5) might need some small
> > adjustments:
> >
> > - as well as the "anchors" limit, it does not document "pktdelay-
On Thu, Jul 21, 2022 at 10:25:09PM +0100, Jason McIntyre wrote:
...
> it looks like the "set limit" text in pf.conf(5) might need some small
> adjustments:
>
> - as well as the "anchors" limit, it does not document "pktdelay-pkts"
>
> - for entries where defaults are not documented, it is not cle
On Fri, Jul 22, 2022 at 09:43:02PM +0200, Alexander Bluhm wrote:
> Hi,
>
> During regress testing I found this bug.
>
> splassert: rip6_input: want 1 have 2
> Starting stack trace...
> rip6_input(1,2,d0c6b7ad,f57ff9fc) at rip6_input+0x166
> rip6_input(f57ffbfc,f57ffbe8,3a,18) at rip6_input+0x166
On Sat, Jul 23, 2022 at 11:06:13AM +0200, Florian Obser wrote:
> I just fixed the case where autoconf and temporary addresses stayed
> behind when the interface no longer has inet6 autoconf and inet6
> temporary.
> This deletes addresses when one removes the temporary or autoconf flag
> but the oth
On Sat, Jul 23, 2022 at 11:14:35AM +0200, Claudio Jeker wrote:
> Change the logic and name of bgpd_filternexthop(). This function applies
> the 'nexthop qualify via' config setting. Instead of telling if the route
> is filtered (true) or not (false) flip the logic around and rename the
> function t
Change the logic and name of bgpd_filternexthop(). This function applies
the 'nexthop qualify via' config setting. Instead of telling if the route
is filtered (true) or not (false) flip the logic around and rename the
function to bgpd_oknexthop(). Also flip the internal logic around to
simplify the
I just fixed the case where autoconf and temporary addresses stayed
behind when the interface no longer has inet6 autoconf and inet6
temporary.
This deletes addresses when one removes the temporary or autoconf flag
but the other one is still set.
OK?
(This needs rev 1.82 of engine.c to work corre
18 matches
Mail list logo
