nvmm_x86_svm.c has same typos.
On Mon, Apr 14, 2025, 01:00 Taylor R Campbell wrote:
> Module Name:src
> Committed By: riastradh
> Date: Sun Apr 13 22:00:43 UTC 2025
>
> Modified Files:
> src/sys/dev/nvmm/x86: nvmm_x86_vmx.c
>
> Log Message:
> nvmm(4): Fix typos in commen
Hi Michael,
On 2025/04/12 21:00, Michael van Elst wrote:
On Sat, Apr 12, 2025 at 08:14:28PM +0900, Rin Okuyama wrote:
Hi Michael, thanks for kind review!
Hi rin,
PS
For ld_sdmmc.c, IIUC, check for ld_sdmmc_dump() yields
```
if (blkno + blkcnt - 1 > sc->sc_sf->csd.capacity)
return
On Sat, Apr 12, 2025 at 08:14:28PM +0900, Rin Okuyama wrote:
> Hi Michael, thanks for kind review!
Hi rin,
> PS
> For ld_sdmmc.c, IIUC, check for ld_sdmmc_dump() yields
>
> ```
> if (blkno + blkcnt - 1 > sc->sc_sf->csd.capacity)
> return EIO;
capacity is the block count, not the last bl
Hi Michael, thanks for kind review!
On 2025/04/12 19:01, Michael van Elst wrote:
On Sat, Apr 12, 2025 at 06:24:44PM +0900, Rin Okuyama wrote:
Hi!
I've made a draft patch to support dumping against > 2Gi blocks
for backends like nvme(4) or virtio(4).
Does it look reasonable to you?
Hi rin,
On Sat, Apr 12, 2025 at 02:42:33AM -0700, Paul Goyette wrote:
> Does this help kern/59153?
It avoids data loss and corruption in similar cases. The exact
condition in kern/59153 luckily didn't dump at all.
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.d
On Sat, Apr 12, 2025 at 06:24:44PM +0900, Rin Okuyama wrote:
> Hi!
>
> I've made a draft patch to support dumping against > 2Gi blocks
> for backends like nvme(4) or virtio(4).
>
> Does it look reasonable to you?
Hi rin,
> - if (blkno < 0 || blkno + nblk - 1 > INT_MAX)
> + if (blkno
Is this related to kern/59153?
On Sat, 12 Apr 2025, Rin Okuyama wrote:
Hi!
I've made a draft patch to support dumping against > 2Gi blocks
for backends like nvme(4) or virtio(4).
Does it look reasonable to you?
Thanks,
rin
On 2025/04/12 16:30, Michael van Elst wrote:
Module Name:src
Co
Does this help kern/59153?
On Sat, 12 Apr 2025, Michael van Elst wrote:
Module Name:src
Committed By: mlelstv
Date: Sat Apr 12 07:30:01 UTC 2025
Modified Files:
src/sys/dev: ld.c
Log Message:
ld sc_dump backend takes an 'int' as disk address, fail when the
disk address
Hi!
I've made a draft patch to support dumping against > 2Gi blocks
for backends like nvme(4) or virtio(4).
Does it look reasonable to you?
Thanks,
rin
On 2025/04/12 16:30, Michael van Elst wrote:
Module Name:src
Committed By: mlelstv
Date: Sat Apr 12 07:30:01 UTC 2025
Modifi
Hi,
On Tue, Mar 25, 2025 at 08:28:10PM +, Taylor R Campbell wrote:
> Thanks for taking a look at this! This change is not quite enough,
> though. There are two issues:
>
> 1. `#ifdef DIAGNOSTIC printf(...)' is almost always wrong. Generally,
>either:
>
>(a) the condition should be
> Module Name:src
> Committed By: hans
> Date: Sun Mar 23 12:07:24 UTC 2025
>
> Modified Files:
> src/sys/dev/usb: uts.c
>
> Log Message:
> uts(4): make sure the device is enabled before calling uhidev_close()
>
> This check was already there, but only enabled for DIAGNOS
On Tue, Mar 25, 2025 at 02:42:33 +, Michael Lorenz wrote:
> Module Name: src
> Committed By: macallan
> Date: Tue Mar 25 02:42:33 UTC 2025
>
> Modified Files:
> src/sys/dev/wsfont: files.wsfont wsfont.c
> Added Files:
> src/sys/dev/wsfont: Comic_Mono_13x22.h
>
> Log Mess
On Tue, Mar 25, 2025 at 06:42:38PM +1100, matthew green wrote:
> hm. does this really change anything?
You're right. I missed that the ums.c code is a bit different from
uts.c and doesn't suffer from the same panic-inducing problem.
> i've had a couple of crashes near here recently and i haven't
"Hans Rosenfeld" writes:
> Module Name: src
> Committed By: hans
> Date: Sun Mar 23 12:19:32 UTC 2025
>
> Modified Files:
> src/sys/dev/wscons: wsmouse.c
>
> Log Message:
> wsmouse(4): fix bogus DIAGNOSTIC checks
>
> Similar to wskbd(4), these checks should be done always, and the on
"Hans Rosenfeld" writes:
> Module Name: src
> Committed By: hans
> Date: Sun Mar 23 12:08:13 UTC 2025
>
> Modified Files:
> src/sys/dev/usb: ums.c
>
> Log Message:
> ums(4): make sure the device is enabled before calling uhidev_close()
>
> Same issue as in uts(4), his check was alrea
Yet again forgot to add: reviewed and approved by riastradh and bad. Thank you!
Also tested on the multiple VIA V-RAID devices (removing disks, mixing
different RAID arrays, two RAID controllers at the same motherboard
(both setup in ataraid(4) and disks removed or swapped), etc).
On Sun, Mar 16,
Should have mentioned in commit message that reviewed by bad and
riastradh. Sorry about that.
On Tue, Mar 11, 2025 at 6:51 PM Andrius Varanavicius wrote:
>
> Module Name:src
> Committed By: andvar
> Date: Tue Mar 11 16:51:31 UTC 2025
>
> Modified Files:
> src/sys/dev/ata:
On Tue, Mar 11, 2025 at 6:35 PM Andrius Varanavicius wrote:
>
> Module Name:src
> Committed By: andvar
> Date: Tue Mar 11 16:35:03 UTC 2025
>
> Modified Files:
> src/sys/dev/pci: viaide.c
>
> Log Message:
> viaide(4): check and add ATA RAID capability in via_sata_chip_map_n
> Module Name:src
> Committed By: joe
> Date: Tue Feb 25 02:10:13 UTC 2025
>
> Modified Files:
> src/sys/dev/pci: if_iavf.c
>
> Log Message:
> initialize post to 0
>
> this prevents the use of unitialized variable when we hit an error branch
> on the first attempt/iterati
> Module Name:src
> Committed By: joe
> Date: Sun Feb 16 15:56:06 UTC 2025
>
> Modified Files:
> src/sys/dev/hyperv: if_hvn.c
>
> Log Message:
> avoid buffer overflow when copying the ether header host into the ether vland
> header host
> on hyper-v
> [...]
> @@ -1697,7 +
On Sat, Nov 23, 2024 at 08:32:43PM -0800, T K Spindler (moof) wrote:
> On Sat, Nov 23, 2024 at 09:59:14PM +0100, Michael van Elst wrote:
> > On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote:
> >
> > > Alas, even with this change, on NetBSD 10 (haven't yet tried booting
> > > wit
On Sat, Nov 23, 2024 at 09:59:14PM +0100, Michael van Elst wrote:
> On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote:
>
> > Alas, even with this change, on NetBSD 10 (haven't yet tried booting
> > with -current), it's still insufficient for the disks on the same
> > target from
On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote:
> Alas, even with this change, on NetBSD 10 (haven't yet tried booting
> with -current), it's still insufficient for the disks on the same
> target from attaching except for the first one; they do still show
> up in `scsictl sd0
> Modified Files:
> src/sys/dev/scsipi: scsiconf.c
>
> Log Message:
> The code tried to limit number of LUNs per target to 3, but would
> only default to a single LUN when that limit is exceeded.
>
> With the limit removed, more LUNs will be attached (up to the limit
> imposed by the host a
On 2024/11/11 23:23, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Mon Nov 11 14:23:11 UTC 2024
>
> Modified Files:
> src/sys/dev/pci: pcidevs
>
> Log Message:
> Add many Brainboxes devices. Repoted in PR/kern 55824 by Cameron Williams.
s/55824/5882
My aplogies. I've removed scsipi_done_once and have commited your alternative
change.
I must have tried this earlier and made an error (not as you intended).
Best regards,
Nat
> Module Name:src
> Committed By: nat
> Date: Mon Oct 28 14:36:43 UTC 2024
>
> Modified Files:
> src/sys/dev/ic: ncr5380sbc.c
> src/sys/dev/scsipi: scsipi_base.c scsipiconf.h
>
> Log Message:
> Introduce scsipi_done_once.
>
> This allows for transfers to be sucess
On Wed, Aug 21, 2024 at 01:42:28AM -0700, John Nemeth wrote:
> } Log Message:
> } Add Areca ARC-1224
>
> I noticed that you mentioned newer Areca devices on icb. Is
> there a particular device that you're interested in. I have an
> updated version of arcmsr(4) that I've been meaning to clea
On Aug 20, 22:44, "Tom Spindler" wrote:
}
} Module Name: src
} Committed By: dogcow
} Date: Tue Aug 20 22:44:04 UTC 2024
}
} Modified Files:
} src/sys/dev/pci: pcidevs
}
} Log Message:
} Add Areca ARC-1224
Hi Tom,
I noticed that you mentioned newer Areca devices on icb. Is
> Module Name:src
> Committed By: riastradh
> Date: Sun Jun 30 16:35:19 UTC 2024
>
> Modified Files:
> src/sys/dev/usb: if_url.c
>
> Log Message:
> url(4): uint32_t for 32-bit hash so h>>31 becomes 0/1, not +1/-1.
That was supposed to read:
url(4): uint32_t for 32-bit ha
Thank you, too, for clarification!
rin
On 2024/06/13 5:10, Nick Hudson wrote:
Thanks for the fix.
The bug affects enable and disable in the all (-1) indexes case and
references out of bounds data.
Nick
On 12/06/2024 08:36, Rin Okuyama wrote:
Hmm, there was a confusion for my side.
This bug
Thanks for the fix.
The bug affects enable and disable in the all (-1) indexes case and
references out of bounds data.
Nick
On 12/06/2024 08:36, Rin Okuyama wrote:
Hmm, there was a confusion for my side.
This bug affected cases where
(1) index >= 1 is explicitly specified for
fdtbus_powerdom
Hmm, there was a confusion for my side.
This bug affected cases where
(1) index >= 1 is explicitly specified for
fdtbus_powerdomain_enable_index(),
as well as
(2) all indices are implicitly specified by
fdtbus_powerdomain_enable().
s/enable/disable/ functions were affected also.
Thanks,
rin
> 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 acpi_deregi
"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 -r
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 t
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 kerne
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.
Please
> 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 suggest
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 hos
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 va
> 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, dk
> 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 at
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 befor
> 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)
>
> KASSERT(mutex_owned(&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 though.
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 F
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 Message:
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 d
> 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
>> just
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 al
>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 dev
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.
>> http://mail-index.netbsd.org/so
> 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
> http://mail-i
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
> con
> 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 ce
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 n
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 kernel
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 wou
> >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 sw
>> 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 multique
"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 wa
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 wi
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:
>> src/sys/de
> 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 fix
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 statis
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.
Shouldn't
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 r
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 expe
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 a
> 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 change
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++ styl
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 i
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:
> if_wm
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 c
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 interrupts
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 "pktq_
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 s
> 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 wsmouse
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 src/sys/
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: file
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 traceba
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 bein
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.
I
1 - 100 of 1232 matches
Mail list logo
