> Module Name:src
> Committed By: christos
> Date: Fri Apr 26 18:19:18 UTC 2024
>
> Modified Files:
> src/sys/dev/acpi: acpi_bat.c
>
> Log Message:
> PR/58201: Malte Dehling: re-order sysmon initialization before acpi
> registration, to avoid needing to call to
"Nick Hudson" writes:
> Module Name: src
> Committed By: skrll
> Date: Tue Dec 19 07:05:36 UTC 2023
>
> Modified Files:
> src/sys/dev/usb: if_axen.c
>
> Log Message:
> Add support for AX88179A. From sc.dying on current-users.
>
>
> To generate a diff of this commit:
> cvs rdiff -u
On 2023/10/12 14:50, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Thu Oct 12 05:50:56 UTC 2023
>
> Modified Files:
> src/sys/dev/pci/ixgbe: ixgbe.c
>
> Log Message:
> ixg(4): Don't print wrong error message about ixgbe_num_queues.
>
> Don't override
On 2023-10-15 17.06, Joerg Sonnenberger wrote:
On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote:
Module Name:src
Committed By: oster
Date: Sun Oct 15 22:36:53 UTC 2023
Modified Files:
src/sys/dev/pci/igc: if_igc.c
Log Message:
Fix build of the MODULAR
On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote:
> Module Name: src
> Committed By: oster
> Date: Sun Oct 15 22:36:53 UTC 2023
>
> Modified Files:
> src/sys/dev/pci/igc: if_igc.c
>
> Log Message:
> Fix build of the MODULAR kernel, which explicitly excludes vlans.
> Date: Thu, 10 Aug 2023 17:42:35 +0900
> From: Kengo NAKAHARA
>
> Could you tell me how you test this fix for future reference?
I asked skrll@ to boot a VM with vmxnet3 and hammer on it with a
combination of:
1. dhcp
2. host$ nc -l 54321 /dev/null
guest$ nc host 54321 /dev/null
3. for i in
Hi,
On 2023/08/10 18:07, Nick Hudson wrote:
On 10/08/2023 09:42, Kengo NAKAHARA wrote:
Hi,
Could you tell me how you test this fix for future reference?
He didn't - I did. :)
Taylor suggested running with network traffic and doing ifconfig
down/up. To generate network traffic Taylor
On 10/08/2023 09:42, Kengo NAKAHARA wrote:
Hi,
Could you tell me how you test this fix for future reference?
He didn't - I did. :)
Taylor suggested running with network traffic and doing ifconfig
down/up. To generate network traffic Taylor suggested
host$ nc -l 54321 /dev/null
guest$ nc
Hi,
Could you tell me how you test this fix for future reference?
Thanks,
On 2023/08/10 17:24, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Thu Aug 10 08:24:45 UTC 2023
Modified Files:
src/sys/dev/pci: if_vmx.c
Log Message:
vmxnet(4): Fix
> Date: Tue, 11 Apr 2023 21:50:49 +0200
> From: Michael van Elst
>
> On Wed, Apr 12, 2023 at 01:10:40AM +0700, Robert Elz wrote:
> >
> > | In that state then decrementing dk_rawopens beyond zero will make
> > | dklastclose do the right thing: nothing.
> >
> > Except that if that happens,
> Module Name:src
> Committed By: mlelstv
> Date: Mon Apr 10 15:26:57 UTC 2023
>
> Modified Files:
> src/sys/dev/usb: uvideo.c uvideoreg.h
>
> Log Message:
> Better descriptor parsing.
How is it better? What problems does it fix?
> Add sanity check if no default format
On Wed, Apr 12, 2023 at 01:10:40AM +0700, Robert Elz wrote:
>
> | In that state then decrementing dk_rawopens beyond zero will make
> | dklastclose do the right thing: nothing.
>
> Except that if that happens, dk_rawopens will be left == ~0 and the next
> open attempt will then increment it,
Date:Tue, 11 Apr 2023 17:21:17 +0200
From:Michael van Elst
Message-ID:
| In that state then decrementing dk_rawopens beyond zero will make
| dklastclose do the right thing: nothing.
Except that if that happens, dk_rawopens will be left == ~0 and the next
open
On Tue, Apr 11, 2023 at 09:07:49AM +, Taylor R Campbell wrote:
>
> (a) how we can legitimately enter a state where the assertions are
> violated, and
dklastclose is called when the close operation ends in no more openers.
There is nothing that guarantees that any open was successful
> Module Name:src
> Committed By: mlelstv
> Date: Tue Sep 27 17:04:52 UTC 2022
>
> Modified Files:
> src/sys/dev/dkwedge: dk.c
>
> Log Message:
> Remove bogus assertions.
>
> @@ -1221,8 +1221,6 @@ dklastclose(struct dkwedge_softc *sc)
>
>
Date:Tue, 24 Jan 2023 14:51:03 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| Once we add them older kernels will break,
I doubt that they'd break any kernels - curses using programs using
these sequences with an old kernel might break
On Tue, 24 Jan 2023 at 14:51, Christos Zoulas wrote:
>
> In article ,
> Valery Ushakov wrote:
> >On Wed, Jan 18, 2023 at 12:02:17 -0500, Christos Zoulas wrote:
> >
> >> Module Name: src
> >> Committed By:christos
> >> Date:Wed Jan 18 17:02:17 UTC 2023
> >>
> >> Modified
In article ,
Valery Ushakov wrote:
>On Wed, Jan 18, 2023 at 12:02:17 -0500, Christos Zoulas wrote:
>
>> Module Name: src
>> Committed By:christos
>> Date:Wed Jan 18 17:02:17 UTC 2023
>>
>> Modified Files:
>> src/sys/dev/wscons: wsemul_vt100_subr.c
>>
>> Log
On Wed, Jan 18, 2023 at 12:02:17 -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Jan 18 17:02:17 UTC 2023
>
> Modified Files:
> src/sys/dev/wscons: wsemul_vt100_subr.c
>
> Log Message:
> Add rin, indn, vpa, hpa, and cbt terminfo capabilities
Taylor R Campbell writes:
[snip]
> The issue here isn't the duration of the delay -- just the mechanism.
> Sleeping for 35ms with kpause(9) is fine, but busy-waiting on the CPU
> for 35ms with delay(9) is not (unless HZ is set to something absurdly
> low like 10 instead of the usual 100, but I
> Date: Wed, 23 Nov 2022 01:42:13 -0500
> From: Brad Spencer
>
> Simon Burge writes:
>
> > + delay(35000);
> >
> > This will spin for 35 milliseconds (per sensor read if I read this
> > correctly). Can you please look at using kpause(9) for this delay?
> > See some other i2c drivers for
Simon Burge writes:
> Hi Brad,
>
>> Module Name: src
>> Committed By:brad
>> Date:Tue Nov 22 19:40:31 UTC 2022
>>
>> Modified Files:
>>
>> src/sys/dev/i2c: bmx280.c
>>
>> Log Message:
>>
>> Read the datasheet more closely and put in some delays. The chip will
>>
Hi Brad,
> Module Name: src
> Committed By: brad
> Date: Tue Nov 22 19:40:31 UTC 2022
>
> Modified Files:
>
> src/sys/dev/i2c: bmx280.c
>
> Log Message:
>
> Read the datasheet more closely and put in some delays. The chip will
> just return junk if the wait is not long enough to
>I think this is a bug in your device tree because the KASSERT was
>intentional:
>
> - In the ACPI case, we probe for CPU PMU support before calling
>armv8_pmu_init.
> - In the FDT case, the PMU attaches to a node described in the device
>tree.
>
>So if you hit this KASSERT, AFAICT it
I think this is a bug in your device tree because the KASSERT was
intentional:
- In the ACPI case, we probe for CPU PMU support before calling
armv8_pmu_init.
- In the FDT case, the PMU attaches to a node described in the device
tree.
So if you hit this KASSERT, AFAICT it means your
On 2022/10/04 19:22, Taylor R Campbell wrote:
>> Date: Tue, 4 Oct 2022 17:16:35 +0900
>> From: Masanobu SAITOH
>>
>> Before reverting changes, one of my machine which use serial console
>> didn't print the Copyright message.
>>
>> Revert two revert commit, i.e.
>>
> Date: Tue, 4 Oct 2022 17:16:35 +0900
> From: Masanobu SAITOH
>
> Before reverting changes, one of my machine which use serial console
> didn't print the Copyright message.
>
> Revert two revert commit, i.e.
> http://mail-index.netbsd.org/source-changes/2022/10/04/msg141389.html
>
Hi.
On 2022/10/04 16:24, Ryo ONODERA wrote:
> Hi,
>
> Taylor R Campbell writes:
>
>>> Date: Tue, 04 Oct 2022 15:53:58 +0900
>>> From: Ryo ONODERA
>>>
>>> With this patch, it works fine for me.
>>> There is no stall after genfb(4).
>>> And I do not find any other problem so far.
>>
>> Thanks!
Hi,
Taylor R Campbell writes:
>> Date: Tue, 04 Oct 2022 15:53:58 +0900
>> From: Ryo ONODERA
>>
>> With this patch, it works fine for me.
>> There is no stall after genfb(4).
>> And I do not find any other problem so far.
>
> Thanks! There probably is another problem which is that kernel
>
> Date: Tue, 04 Oct 2022 15:53:58 +0900
> From: Ryo ONODERA
>
> With this patch, it works fine for me.
> There is no stall after genfb(4).
> And I do not find any other problem so far.
Thanks! There probably is another problem which is that kernel
console printfs might stop appearing after a
Hi,
Taylor R Campbell writes:
>> Date: Tue, 04 Oct 2022 12:12:15 +0900
>> From: Ryo ONODERA
>>
>> "Taylor R Campbell" writes:
>>
>> > console(4), constty(4): Rip off the kernel lock.
>>
>> After introduction of MP-safe console/constty, my kernel stopped
>> just after genfb(4) detection.
>>
> Date: Tue, 04 Oct 2022 12:12:15 +0900
> From: Ryo ONODERA
>
> "Taylor R Campbell" writes:
>
> > console(4), constty(4): Rip off the kernel lock.
>
> After introduction of MP-safe console/constty, my kernel stopped
> just after genfb(4) detection.
> LOCKDEBUG, DIAGNOSTIC, DEBUG options does
Hi,
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Mon Oct 3 19:57:25 UTC 2022
>
> Modified Files:
> src/sys/dev: cons.c
>
> Log Message:
> console(4), constty(4): Rip off the kernel lock.
After introduction of MP-safe console/constty, my
Hi,
On 21/09/2022 08:56, matthew green wrote:
this asserts for me. perhaps ryo@ didn't have LOCKDEBUG?
I had LOCKDEBUG on, but not DEBUG.
https://nxr.netbsd.org/xref/src/sys/sys/systm.h#760
I see that adding options DEBUG does indeed cause a panic with
ASSERT_SLEEPABLE()...
ah! that
> >this asserts for me. perhaps ryo@ didn't have LOCKDEBUG?
>
> I had LOCKDEBUG on, but not DEBUG.
> https://nxr.netbsd.org/xref/src/sys/sys/systm.h#760
> I see that adding options DEBUG does indeed cause a panic with
> ASSERT_SLEEPABLE()...
ah! that would explain it. nick asked me to test
>> Module Name: src
>> Committed By:skrll
>> Date:Fri Sep 16 03:55:53 UTC 2022
>>
>> Modified Files:
>> src/sys/dev/pci: if_aq.c
>>
>> Log Message:
>> Some MP improvements
>>
>> - Remove use of IFF_OACTIVE
>>
>> - Remove use of if_timer and provide an MP safe
"Nick Hudson" writes:
> Module Name: src
> Committed By: skrll
> Date: Fri Sep 16 03:55:53 UTC 2022
>
> Modified Files:
> src/sys/dev/pci: if_aq.c
>
> Log Message:
> Some MP improvements
>
> - Remove use of IFF_OACTIVE
>
> - Remove use of if_timer and provide an MP safe multiqueue
Hi Taylor,
Thanks for updating NVMM! Would it be a good idea to sync our code with
DragonBSDs? AFAICS they kept the code compiling for NetBSD too. To have a
common code base?
With regards,
Reinoud
On Tue, Sep 13, 2022 at 08:10:04PM +, Taylor R Campbell wrote:
> Module Name: src
> Committed
On 03/08/2022 07:26, Kengo NAKAHARA wrote:
Hi,
On 2022/08/03 14:23, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Wed Aug 3 05:23:30 UTC 2022
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Add some KASSERTs around the locking protocol.
Discussed
Hi,
On 2022/08/03 14:23, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed Aug 3 05:23:30 UTC 2022
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Add some KASSERTs around the locking protocol.
Discussed with msaitoh@, knakahara@ and riastradh@
Oops, never mind, I hadn't yet seen the follow-up revert.
> On Aug 1, 2022, at 8:29 AM, Jason Thorpe wrote:
>
>
>
>> On Aug 1, 2022, at 12:34 AM, Michael van Elst wrote:
>>
>> Module Name: src
>> Committed By: mlelstv
>> Date: Mon Aug 1 07:34:28 UTC 2022
>>
>> Modified Files:
>>
> On Aug 1, 2022, at 12:34 AM, Michael van Elst wrote:
>
> Module Name: src
> Committed By: mlelstv
> Date: Mon Aug 1 07:34:28 UTC 2022
>
> Modified Files:
> src/sys/dev/ic: ahcisata_core.c bcmgenet.c nslm7x.c nvmereg.h nvmevar.h
>rtl8169.c tulip.c tulipreg.h
>
> Log Message:
> Also
Hi.
On 2022/07/22 23:22, Hisashi T Fujinaka wrote:
> On Fri, 22 Jul 2022, SAITOH Masanobu wrote:
>
>> Module Name: src
>> Committed By: msaitoh
>> Date: Fri Jul 22 05:23:50 UTC 2022
>>
>> Modified Files:
>> src/sys/dev/pci: if_wm.c if_wmreg.h
>>
>> Log Message:
>> Add more
On Fri, 22 Jul 2022, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Fri Jul 22 05:23:50 UTC 2022
Modified Files:
src/sys/dev/pci: if_wm.c if_wmreg.h
Log Message:
Add more statistics countes.
- Add many statics counters that the chip has.
On Sat, 9 Jul 2022, matthew green wrote:
"Paul Goyette" writes:
Module Name:src
Committed By: pgoyette
Date: Fri Jul 8 17:32:19 UTC 2022
Modified Files:
src/sys/dev/pci: nvme_pci.c
Log Message:
devsw_ok needs to survive across invocations of nvme_modcmd() so
allocate
"Paul Goyette" writes:
> Module Name: src
> Committed By: pgoyette
> Date: Fri Jul 8 17:32:19 UTC 2022
>
> Modified Files:
> src/sys/dev/pci: nvme_pci.c
>
> Log Message:
> devsw_ok needs to survive across invocations of nvme_modcmd() so
> allocate it statically.
>
> Should address
Hi,
On 2022/05/14 19:44, Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Sat May 14 19:44:37 UTC 2022
>
> Modified Files:
> src/sys/dev/usb: xhci.c
>
> Log Message:
> xhci(4): Handle race between software abort and hardware stall.
xhci_abortx is
On 2022/05/21 19:27, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sat May 21 10:27:30 UTC 2022
Modified Files:
src/sys/dev/marvell: if_mvgbe.c
Log Message:
m_freem() *after* bus_dmamap_sync() and bus_dmamap_load() for
that mbuf. This is mandatory for some
> On 16. Apr 2022, at 18:40, Andrius Varanavicius wrote:
>
> Module Name: src
> Committed By: andvar
> Date: Sat Apr 16 16:40:54 UTC 2022
>
> Modified Files:
> src/sys/dev/raidframe: rf_netbsdkintf.c
>
> Log Message:
> Fix mistake in error branch locking caused by previous
On Sun, Feb 27, 2022 at 11:50:15AM +0100, Martin Husemann wrote:
> On Sun, Feb 27, 2022 at 12:04:58AM +0100, Joerg Sonnenberger wrote:
> > Personally, I prefer the use of the C extension in cases like this. The
> > "portable" version is less readable...
>
> I would prefer the type correct C++
On Sun, Feb 27, 2022 at 12:04:58AM +0100, Joerg Sonnenberger wrote:
> Personally, I prefer the use of the C extension in cases like this. The
> "portable" version is less readable...
I would prefer the type correct C++ style variant (and making lint deal
with it, if it doesn't yet). At least gcc
Am Sat, Feb 26, 2022 at 03:04:40PM + schrieb Roland Illig:
> Module Name: src
> Committed By: rillig
> Date: Sat Feb 26 15:04:40 UTC 2022
>
> Modified Files:
> src/sys/dev/pci: if_wm.c
>
> Log Message:
> if_wm.c: fix value return from void function
>
> lint complained:
>
Should fix PR 56650
> Module Name: src
> Committed By: macallan
> Date: Fri Jan 21 21:00:26 UTC 2022
>
> Modified Files:
> src/sys/dev/fdt: fdt_port.c
>
> Log Message:
> when enumerating ports and endpoints treat missing 'reg' properties as zero
> ok jmcneill:
> Looking at Linux.
On 23/12/2021 17:05, Juergen Hannken-Illjes wrote:
Module Name:src
Committed By: hannken
Date: Thu Dec 23 17:05:49 UTC 2021
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Keep constants 32 bit, why does __BIT() return uintmax_t?
PRIxBIT is available
Nick
On 26/11/2021 13:24, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Fri Nov 26 13:24:28 UTC 2021
Modified Files:
src/sys/dev/tprof: tprof_armv7.c tprof_armv8.c
Log Message:
declare xc
Thanks!
Nick
>Module Name: src
>Committed By: macallan
>Date: Sat Oct 30 05:37:39 UTC 2021
>
>Modified Files:
> src/sys/dev/sbus: mgx.c mgxreg.h
>
>Log Message:
>actually mmap() the blitter registers when asked to, while there do some
>magic number reduction
>
>
>To generate a diff of this
On Thu, Oct 21, 2021 at 05:32:28AM +, Shoichi YAMAGUCHI wrote:
> Module Name: src
> Committed By: yamaguchi
> Date: Thu Oct 21 05:32:27 UTC 2021
>
> Modified Files:
> src/sys/dev/pci: virtio.c virtio_pci.c virtiovar.h
>
> Log Message:
> divide setup routine of virtio
Hi,
Thank you for your quick commit!
Thanks,
On 2021/10/18 17:15, Juergen Hannken-Illjes wrote:
Module Name:src
Committed By: hannken
Date: Mon Oct 18 08:15:00 UTC 2021
Modified Files:
src/sys/dev/pci: xmm7360.c
Log Message:
Use a local static variable to hold
On Sun, Oct 10, 2021 at 10:44:03PM +0900, Izumi Tsutsui wrote:
> > Module Name:src
> > Committed By: nia
> > Date: Tue Sep 28 06:14:28 UTC 2021
> >
> > Modified Files:
> > src/sys/dev/wscons: wsconsio.h wsmouse.c wsmousevar.h
> >
> > Log Message:
> > wsmouse: add
> Module Name: src
> Committed By: nia
> Date: Tue Sep 28 06:14:28 UTC 2021
>
> Modified Files:
> src/sys/dev/wscons: wsconsio.h wsmouse.c wsmousevar.h
>
> Log Message:
> wsmouse: add support for "precision scrolling" events and (GET|SET)PARAMS
Could you please also update
On 15/07/2021 04:25, Tohru Nishimura wrote:
Module Name:src
Committed By: nisimura
Date: Thu Jul 15 03:25:50 UTC 2021
Modified Files:
src/sys/dev/usb: if_mue.c uchcom.c
Log Message:
explanation typo
To generate a diff of this commit:
cvs rdiff -u -r1.60 -r1.61
On 2021/06/16 19:23, Rin Okuyama wrote:
On 2021/06/16 18:15, Taylor R Campbell wrote:
Date: Wed, 16 Jun 2021 17:38:26 +0900
From: Rin Okuyama
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed:
On 2021/06/16 18:15, Taylor R Campbell wrote:
Date: Wed, 16 Jun 2021 17:38:26 +0900
From: Rin Okuyama
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
"/usr/src/sys/dev/pad/pad.c", line 214
> Date: Wed, 16 Jun 2021 17:38:26 +0900
> From: Rin Okuyama
>
> KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
> [...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
> "/usr/src/sys/dev/pad/pad.c", line 214
Can you share `ident netbsd | grep
Hi,
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
# cd /usr/tests/usr.bin/mixerctl && atf-run
...
tc-start: ..., nflag
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
"/usr/src/sys/dev/pad/pad.c", line 214
[...] cpu0: Begin
On Wed, 9 Jun 2021, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Wed Jun 9 23:22:51 UTC 2021
Modified Files:
src/sys/dev: dev_verbose.h
Log Message:
Use the localcount(9)-based module_hook mechanism to prevent the verbose
modules' code and data
On 2021/06/08 16:09, nia wrote:
On Tue, Jun 01, 2021 at 09:12:24PM +, Taylor R Campbell wrote:
audio(4): Set AUMODE_PLAY/RECORD only if asked _and_ supported.
If one is requested and _not_ supported, fail; otherwise we might
enter audio_write with a null play track and crash on KASSERT.
On Tue, Jun 01, 2021 at 09:12:24PM +, Taylor R Campbell wrote:
> audio(4): Set AUMODE_PLAY/RECORD only if asked _and_ supported.
>
> If one is requested and _not_ supported, fail; otherwise we might
> enter audio_write with a null play track and crash on KASSERT.
It looks like this is an
On Sat, 24 Apr 2021, Robert Elz wrote:
Date:Sat, 24 Apr 2021 00:15:37 +
From:"Michael Lorenz"
Message-ID: <20210424001537.c5c83f...@cvs.netbsd.org>
| add an ioctl() to get a list of fonts currently available via wsfont
It seems to me it would be useful for that
Oh, I see from your code change to wsfontload.c that you intended
for the fi_numentries field to get copied out, it just doesn't seem
to happen.
I also see that the addr==NULL case happens if malloc() (in wsfontload.c)
failed - going ahead with the ioctl() in that case seems like a mistake,
Date:Sat, 24 Apr 2021 00:15:37 +
From:"Michael Lorenz"
Message-ID: <20210424001537.c5c83f...@cvs.netbsd.org>
| add an ioctl() to get a list of fonts currently available via wsfont
It seems to me it would be useful for that ioctl to copyout()
the fi_numentries
> On 12. Jul 2020, at 21:05, Jaromir Dolecek wrote:
>
> Module Name: src
> Committed By: jdolecek
> Date: Sun Jul 12 19:05:32 UTC 2020
>
> Modified Files:
> src/sys/dev/pci: if_bnx.c if_bnxvar.h
>
> Log Message:
> enable MSI/MSI-X if supported by adapter
>
> tested MSI-X with
On Tue, Jan 26, 2021 at 05:51:42PM +0900, Rin Okuyama wrote:
> Hi,
> This seems not correct for me. Is the attached patch OK with you?
Well you spotted a bug indeed int he freeing section. I'll fix and commit it.
Thanks for reporting.
Reinoud
signature.asc
Description: PGP signature
Hi,
On 2021/01/25 0:33, Reinoud Zandijk wrote:
Module Name:src
Committed By: reinoud
Date: Sun Jan 24 15:33:02 UTC 2021
Modified Files:
src/sys/dev/pci: virtio_pci.c
Log Message:
On error unmap the pci_mapreg_map()d regions using bus_space_unmap() as
suggested by jak@
> On Jan 24, 2021, at 10:20 PM, Martin Husemann wrote:
>
>> I kept getting a ?static after non-static declaration? error when building
>> for aarch64.
>
> I guess that was with outdated arm/include/bus_funcs.h and
> sys/bus_proto.h (or where was the previous declaration)?
I did a “cvs
On Sun, Jan 24, 2021 at 09:45:14PM -0800, Jason Thorpe wrote:
>
> > On Jan 24, 2021, at 9:37 PM, Martin Husemann wrote:
> >
> > While I don't care for names, I would like to understand fallout in
> > details before hiding it - what exactly did not compile correctly?
> > At least the affected
> On Jan 24, 2021, at 9:37 PM, Martin Husemann wrote:
>
> While I don't care for names, I would like to understand fallout in
> details before hiding it - what exactly did not compile correctly?
> At least the affected arm kernels worked for me in the state directly
> before your commit.
I
On Sun, Jan 24, 2021 at 03:34:08PM +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Sun Jan 24 15:34:08 UTC 2021
>
> Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
> Log Message:
> Redefining bus_space functions in drivers is a bad idea, and we
> On Jan 23, 2021, at 5:40 PM, Christos Zoulas wrote:
>
>> it's a bad example. someone might copy it into another
>> driver that _doesn't_ work with this version, but may seem
>> to fix a build error.
>>
>> that's why i wanted to wrap the usage to make it clear if
>> someone were to copy it
In article <17141.1611452...@splode.eterna.com.au>,
matthew green wrote:
>Christos Zoulas writes:
>> In article <20210123230600.52be160...@jupiter.mumble.net>,
>> Taylor R Campbell wrote:
>> >
>> >Conversely, how do you know whether this hacked-up implementation
>> >which tears the write into
Christos Zoulas writes:
> In article <20210123230600.52be160...@jupiter.mumble.net>,
> Taylor R Campbell wrote:
> >
> >Conversely, how do you know whether this hacked-up implementation
> >which tears the write into two will actually work? Maybe it works for
> >virtio but there are likely other
In article <20210123230600.52be160...@jupiter.mumble.net>,
Taylor R Campbell wrote:
>
>Conversely, how do you know whether this hacked-up implementation
>which tears the write into two will actually work? Maybe it works for
>virtio but there are likely other devices out there for which it will
> Date: Sat, 23 Jan 2021 22:59:22 - (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> In article <23974.1611441...@splode.eterna.com.au>,
> matthew green wrote:
> >this seems dangerous to me. we don't define it on
> >some platforms because we can't, so having it faked
> >out here
In article <23974.1611441...@splode.eterna.com.au>,
matthew green wrote:
>"Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Jan 23 20:00:19 UTC 2021
>>
>> Modified Files:
>> src/sys/dev/pci: virtio_pci.c
>>
>> Log Message:
>> Provide
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sat Jan 23 20:00:19 UTC 2021
>
> Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
> Log Message:
> Provide a generic bus_space_write_8 function that is bi-endian.
this seems dangerous to me. we don't
In article ,
Reinoud Zandijk wrote:
>On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote:
>> > +#ifndef _LP64
>>
>> _LP64 is a terrible way to make this choice.
>>
>> heaps of our 32 bit platforms implement the _8 variants.
>
>Can't we then just make sure they have the 8 bit variant?
In article ,
Nick Hudson wrote:
>On 22/01/2021 04:48, Christos Zoulas wrote:
>> +#if _QUAD_HIGHWORD
>> +bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x));
>> +bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32));
>> +#else
>> +bus_space_write_4(iot, ioh,
On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote:
> > +#ifndef _LP64
>
> _LP64 is a terrible way to make this choice.
>
> heaps of our 32 bit platforms implement the _8 variants.
Can't we then just make sure they have the 8 bit variant? and set a define if
its atomic or not?
This
On 22/01/2021 04:48, Christos Zoulas wrote:
+#if _QUAD_HIGHWORD
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x));
+ bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32));
+#else
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value >> 32));
+
In article <27744.1611294...@splode.eterna.com.au>,
matthew green wrote:
>> +#ifndef _LP64
>
>_LP64 is a terrible way to make this choice.
>
>heaps of our 32 bit platforms implement the _8 variants.
Let's add a _HAVE_ variable then?
christos
> +#ifndef _LP64
_LP64 is a terrible way to make this choice.
heaps of our 32 bit platforms implement the _8 variants.
.mrg.
In article <20210121204833.9ebcff...@cvs.netbsd.org>,
Reinoud Zandijk wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: reinoud
>Date: Thu Jan 21 20:48:33 UTC 2021
>
>Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
>Log Message:
>Remove dependency on bus_space_write_8()
> On Jan 21, 2021, at 12:00 AM, Martin Husemann
> wrote:
>
> On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote:
>> Module Name: src
>> Committed By:reinoud
>> Date:Wed Jan 20 19:46:48 UTC 2021
>>
> [..]
>> Log Message:
>> Add VirtIO PCI v1.0 attachments
On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote:
> Module Name: src
> Committed By: reinoud
> Date: Wed Jan 20 19:46:48 UTC 2021
>
[..]
> Log Message:
> Add VirtIO PCI v1.0 attachments and fix the drivers affected.
>
> * virtio on sparc64 attaches but is it not
The change isn't wrong, but I booted the wrong kernel and it does not fix
the aarch64 issue I am seeing.
On Sun, 17 Jan 2021, Jared D. McNeill wrote:
Module Name:src
Committed By: jmcneill
Date: Sun Jan 17 15:13:15 UTC 2021
Modified Files:
src/sys/dev/wscons:
"Jason R Thorpe" writes:
> Module Name: src
> Committed By: thorpej
> Date: Sat Jan 16 01:23:04 UTC 2021
>
> Modified Files:
> src/sys/dev/acpi: tpm_acpi.c
>
> Log Message:
> Match PNP0C31 as a TPM 1.2 device. Works on my ThinkPad X260, and
> eliminates the last of the devices that
On 2020/12/11 14:01, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Fri Dec 11 05:01:19 UTC 2020
Modified Files:
src/sys/dev/pci/ixgbe: ixgbe.c ixgbe_type.h
Log Message:
Don't use EIMC_OTHER bit because it's read only other than 82598.
Documents
Hi,
On 2020/10/21 15:42, Michael wrote:
Hello,
On Sun, 18 Oct 2020 11:54:21 +
"Rin Okuyama" wrote:
Module Name:src
Committed By: rin
Date: Sun Oct 18 11:54:21 UTC 2020
Modified Files:
src/sys/dev/wsfb: genfb.c
Log Message:
For WSDISPLAYIO_GET_FBINFO ioctl, set
Hello,
On Sun, 18 Oct 2020 11:54:21 +
"Rin Okuyama" wrote:
> Module Name: src
> Committed By: rin
> Date: Sun Oct 18 11:54:21 UTC 2020
>
> Modified Files:
> src/sys/dev/wsfb: genfb.c
>
> Log Message:
> For WSDISPLAYIO_GET_FBINFO ioctl, set WSFB_VRAM_IS_RAM to fbi_flags
>
On 2020/10/18 21:18, Jared McNeill wrote:
I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you get
when you mmap the device. When shadow FB is used, that is generally only used
for rasops and mmap bypasses the shadow and uses device memory directly. So I
think this could
1 - 100 of 1055 matches
Mail list logo
