Re: CVS commit: src/sys/dev/pci

2021-02-01 Thread J. Hannken-Illjes
> 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

Re: CVS commit: src/sys/dev/pci

2021-01-26 Thread Reinoud Zandijk
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

Re: CVS commit: src/sys/dev/pci

2021-01-26 Thread Rin Okuyama
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@

Re: CVS commit: src/sys/dev/pci

2021-01-25 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/dev/pci

2021-01-24 Thread Martin Husemann
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

Re: CVS commit: src/sys/dev/pci

2021-01-24 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/dev/pci

2021-01-24 Thread Martin Husemann
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

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Christos Zoulas
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

re: CVS commit: src/sys/dev/pci

2021-01-23 Thread matthew green
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

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Christos Zoulas
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

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Taylor R Campbell
> 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

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Christos Zoulas
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

re: CVS commit: src/sys/dev/pci

2021-01-23 Thread matthew green
"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

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Christos Zoulas
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?

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Christos Zoulas
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,

Re: CVS commit: src/sys/dev/pci

2021-01-22 Thread Reinoud Zandijk
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

Re: CVS commit: src/sys/dev/pci

2021-01-22 Thread Nick Hudson
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)); +

Re: CVS commit: src/sys/dev/pci

2021-01-21 Thread Christos Zoulas
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

re: CVS commit: src/sys/dev/pci

2021-01-21 Thread matthew green
> +#ifndef _LP64 _LP64 is a terrible way to make this choice. heaps of our 32 bit platforms implement the _8 variants. .mrg.

Re: CVS commit: src/sys/dev/pci

2021-01-21 Thread Christos Zoulas
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()

Re: CVS commit: src/sys/dev

2021-01-21 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/dev

2021-01-21 Thread Martin Husemann
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

Re: CVS commit: src/sys/dev/wscons

2021-01-17 Thread Jared McNeill
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:

re: CVS commit: src/sys/dev/acpi

2021-01-15 Thread matthew green
"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

Re: CVS commit: src/sys/dev/pci/ixgbe

2020-12-10 Thread SAITOH Masanobu
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

Re: CVS commit: src/sys/dev/wsfb

2020-10-21 Thread Rin Okuyama
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

Re: CVS commit: src/sys/dev/wsfb

2020-10-21 Thread Michael
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 >

Re: CVS commit: src/sys/dev/wsfb

2020-10-18 Thread Rin Okuyama
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

Re: CVS commit: src/sys/dev/wsfb

2020-10-18 Thread Jared McNeill
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 cause performance regressions on such

Re: CVS commit: src/sys/dev/pci

2020-10-16 Thread SAITOH Masanobu
On 2020/10/16 14:53, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Fri Oct 16 05:53:40 UTC 2020 Modified Files: src/sys/dev/pci: if_wm.c Log Message: Fixes a problem that the attach function reported "wm_gmii_setup_phytype: Unknown PHY model.

Re: CVS commit: src/sys/dev/pci

2020-10-12 Thread Michael
Hello, On Sun, 11 Oct 2020 21:41:57 + "Julian Coleman" wrote: > Module Name: src > Committed By: jdc > Date: Sun Oct 11 21:41:57 UTC 2020 > > Modified Files: > src/sys/dev/pci: radeonfb.c > > Log Message: ... > don't ignore the bottom 200 lines of the display (for no

Re: CVS commit: src/sys/dev/fdt

2020-10-02 Thread Rin Okuyama
On 2020/10/02 22:42, Jonathan A. Kollasch wrote: On Sun, Jul 21, 2019 at 03:57:24PM +, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Sun Jul 21 15:57:24 UTC 2019 Modified Files: src/sys/dev/fdt: dw_apb_uart.c Log Message: The device cannot recognize

Re: CVS commit: src/sys/dev/fdt

2020-10-02 Thread Jonathan A. Kollasch
On Sun, Jul 21, 2019 at 03:57:24PM +, Rin Okuyama wrote: > Module Name: src > Committed By: rin > Date: Sun Jul 21 15:57:24 UTC 2019 > > Modified Files: > src/sys/dev/fdt: dw_apb_uart.c > > Log Message: > The device cannot recognize break signal. Use + (five plus signs) as

Re: CVS commit: src/sys/dev/scsipi

2020-09-19 Thread Kimmo Suominen
I don't think this should be reverted, because LUN 0 must exist, but if there is no device on it, it will report "NOT PRESENT". We do not want the scan to stop in this case, but it should continue with other LUNs (such as those found through REPORT LUNS in the future). Kind regards, + Kimmo On

Re: CVS commit: src/sys/dev/mii (PR/kern 55538)

2020-08-27 Thread Frank Kardel
Hi Martin ! That is strange - I didn't expect that, especially as the previous code was wrong with respect to state tracking. Can you check whether the addresses do not have the DEtACHED flag? You could try the dtrace script from the PR - it shows a little bit what is going on. There was also

Re: CVS commit: src/sys/dev/mii (PR/kern 55538)

2020-08-27 Thread Martin Husemann
On Mon, Aug 24, 2020 at 12:46:04PM +, Frank Kardel wrote: > Module Name: src > Committed By: kardel > Date: Mon Aug 24 12:46:04 UTC 2020 > > Modified Files: > src/sys/dev/mii: mii_physubr.c > > Log Message: > Keep the change check invariant intact. The previous code could miss

Re: CVS commit: src/sys/dev/mii

2020-08-03 Thread Valery Ushakov
On Tue, Aug 04, 2020 at 07:12:54 +0300, Valery Ushakov wrote: > On Tue, Aug 04, 2020 at 12:50:11 +0900, SAITOH Masanobu wrote: > > > On 2020/08/03 23:00, Valeriy E. Ushakov wrote: > > > Module Name: src > > > Committed By: uwe > > > Date: Mon Aug 3 14:00:41 UTC 2020 > > >

Re: CVS commit: src/sys/dev/mii

2020-08-03 Thread SAITOH Masanobu
On 2020/08/04 12:50, SAITOH Masanobu wrote: Hi. On 2020/08/03 23:00, Valeriy E. Ushakov wrote: Module Name:    src Committed By:    uwe Date:    Mon Aug  3 14:00:41 UTC 2020 Modified Files: src/sys/dev/mii: miidevs_data.h Log Message: mii_knowndevs[] is de facto const, define it as

Re: CVS commit: src/sys/dev/mii

2020-08-03 Thread Valery Ushakov
On Tue, Aug 04, 2020 at 12:50:11 +0900, SAITOH Masanobu wrote: > On 2020/08/03 23:00, Valeriy E. Ushakov wrote: > > Module Name:src > > Committed By: uwe > > Date: Mon Aug 3 14:00:41 UTC 2020 > > > > Modified Files: > > src/sys/dev/mii: miidevs_data.h > > > >

Re: CVS commit: src/sys/dev/mii

2020-08-03 Thread SAITOH Masanobu
Hi. On 2020/08/03 23:00, Valeriy E. Ushakov wrote: Module Name:src Committed By: uwe Date: Mon Aug 3 14:00:41 UTC 2020 Modified Files: src/sys/dev/mii: miidevs_data.h Log Message: mii_knowndevs[] is de facto const, define it as such. To generate a diff of this

re: CVS commit: src/sys/dev

2020-07-28 Thread matthew green
"Jaromir Dolecek" writes: > Module Name: src > Committed By: jdolecek > Date: Tue Jul 28 09:36:05 UTC 2020 > > Modified Files: > src/sys/dev/ic: nvmevar.h > src/sys/dev/pci: nvme_pci.c > > Log Message: > add a quirk to disable MSI, and enable it for Intel SSD DC P4500 > >

Re: CVS commit: src/sys/dev/pci

2020-07-17 Thread Jaromír Doleček
One of the things which need to be done is calling the if_ioctl always with the IFNET_LOCK() held. Right now it sometimes is, and other times it is not, so it's not possible to rely on it and KASSERT(). As for bnx(4) I did just some basic fixes around making it work with MSI(-X), since I don't

Re: CVS commit: src/sys/dev/pci

2020-07-17 Thread Jason Thorpe
> On Jul 17, 2020, at 3:50 PM, matthew green wrote: > > any chance you can look at NET_MPSAFE here etc? :) I have a bunch of local changes for this in one of my trees, and I hope to get back to it after netbsd-10 branches. -- thorpej

re: CVS commit: src/sys/dev/pci

2020-07-17 Thread matthew green
"Jaromir Dolecek" writes: > Module Name: src > Committed By: jdolecek > Date: Fri Jul 17 09:48:21 UTC 2020 > > Modified Files: > src/sys/dev/pci: if_bnx.c > > Log Message: > re-enable MSI/MSI-X, the TX timeouts were caused by the IFF_OACTIVE handling, > which was fixed in previous

Re: CVS commit: src/sys/dev/i2c

2020-07-12 Thread Kimmo Suominen
Hi Michael, Perhaps your commit missed some changes? The code no longer compiles. Cheers, + Kimmo /p/netbsd/cvs/src/sys/dev/i2c/dbcool.c: In function 'dbcool_attach': /p/netbsd/cvs/src/sys/dev/i2c/dbcool.c:778:4: error: 'struct dbcool_softc' has no member named 'sc_prop' sc->sc_prop =

Re: CVS commit: src/sys/dev/scsipi

2020-07-11 Thread Kimmo Suominen
On Sun, Jul 12, 2020 at 12:05:37AM +0700, Robert Elz wrote: > Just to make things clear here, the LUN you're talking about is not > the scsi unit number (which is what I think Martin was referring to) > but a sub-device number within a single scsi ID. Right? Correct. I should have written "SCSI

Re: CVS commit: src/sys/dev/scsipi

2020-07-11 Thread Robert Elz
Date:Sat, 11 Jul 2020 18:24:51 +0300 From:Kimmo Suominen Message-ID: <20200711152451.ga1...@homeworld.netbsd.org> | On Sat, Jul 11, 2020 at 05:00:02PM +0200, Martin Husemann wrote: | > I don't understand the change. When was this broken? This has always worked

Re: CVS commit: src/sys/dev/scsipi

2020-07-11 Thread Martin Husemann
On Sat, Jul 11, 2020 at 06:24:51PM +0300, Kimmo Suominen wrote: > I think all real SCSI hardware I've had has always just only had LUN 0, > and each disk has been on its own SCSI ID (target). Yes, I confused ID and LUN here - just ignore me. Martin

Re: CVS commit: src/sys/dev/scsipi

2020-07-11 Thread Kimmo Suominen
On Sat, Jul 11, 2020 at 05:00:02PM +0200, Martin Husemann wrote: > I don't understand the change. When was this broken? This has always worked > for me e.g. with the sd0 at LUN 3 and the controller at 6 or 7. I think all real SCSI hardware I've had has always just only had LUN 0, and each disk

Re: CVS commit: src/sys/dev/scsipi

2020-07-11 Thread Martin Husemann
On Sat, Jul 11, 2020 at 05:57:46PM +0300, Kimmo Suominen wrote: > On Sat, Jul 11, 2020 at 05:47:34PM +0300, Jukka Ruohonen wrote: > > I'd reckon a pullup to NetBSD 9 would be in order? > > Yes, I was just waiting to be able to link to mail-index. I had > already checked that the patch applies

Re: CVS commit: src/sys/dev/scsipi

2020-07-11 Thread Kimmo Suominen
On Sat, Jul 11, 2020 at 05:47:34PM +0300, Jukka Ruohonen wrote: > I'd reckon a pullup to NetBSD 9 would be in order? Yes, I was just waiting to be able to link to mail-index. I had already checked that the patch applies cleanly to both netbsd-9 and netbsd-8.

Re: CVS commit: src/sys/dev/scsipi

2020-07-11 Thread Jukka Ruohonen
On Sat, Jul 11, 2020 at 02:31:46PM +, Kimmo Suominen wrote: > Use case 2: A Linode boot profile with multiple disks results in > the first disk ("sda") on LUN 1, while the second disk ("sdb") is > on LUN 0, each on their own bus. As Linode is quite popular, and supposedly uses a rather

re: CVS commit: src/sys/dev/ofw

2020-06-27 Thread matthew green
"Martin Husemann" writes: > Module Name: src > Committed By: martin > Date: Fri Jun 26 10:14:32 UTC 2020 > > Modified Files: > src/sys/dev/ofw: ofw_subr.c > > Log Message: > Remove !cold KASSERT - it does not compile on all kernels, and it is not the > right thing to test for

Re: CVS commit: src/sys/dev/ic

2020-06-25 Thread Christos Zoulas
In article <18083.1593053...@splode.eterna.com.au>, matthew green wrote: >"Jaromir Dolecek" writes: >> Module Name: src >> Committed By:jdolecek >> Date:Wed Jun 24 19:55:25 UTC 2020 >> >> Modified Files: >> src/sys/dev/ic: ibm561.c >> >> Log Message: >> avoid

re: CVS commit: src/sys/dev/ic

2020-06-24 Thread matthew green
"Jaromir Dolecek" writes: > Module Name: src > Committed By: jdolecek > Date: Wed Jun 24 19:55:25 UTC 2020 > > Modified Files: > src/sys/dev/ic: ibm561.c > > Log Message: > avoid allocating almost 5k struct ibm561data on stack in ibm561_cninit(); > it's too early for kmem_alloc(),

Re: CVS commit: src/sys/dev/acpi

2020-06-23 Thread Jukka Ruohonen
On Mon, Jun 22, 2020 at 04:14:18PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Mon Jun 22 16:14:18 UTC 2020 > > Modified Files: > src/sys/dev/acpi: acpi.c > > Log Message: > Fix memory leak. Found by kLSan. > + > + default: > +

Re: CVS commit: src/sys/dev/acpi

2020-06-07 Thread Nick Hudson
On 10/08/2018 18:11, Taylor R Campbell wrote: Module Name:src Committed By: riastradh Date: Fri Aug 10 17:11:56 UTC 2018 Modified Files: src/sys/dev/acpi: acpi_bat.c Log Message: Don't hold up boot: defer acpibat(4) inquiry until threads are running. ok jmcneill@

Re: [virtio] Re: CVS commit: src/sys/dev/pci

2020-05-31 Thread Maxime Villard
Le 01/06/2020 à 03:23, Shoichi Yamaguchi a écrit : Hi, On Wed, May 27, 2020 at 8:47 PM Shoichi Yamaguchi wrote: I modified virtio(4) not to allocate unused memory. I guess it fixes the issue. Could you check this? I confirmed your closing the report on syzbot.

Re: [virtio] Re: CVS commit: src/sys/dev/pci

2020-05-31 Thread Shoichi Yamaguchi
Hi, On Wed, May 27, 2020 at 8:47 PM Shoichi Yamaguchi wrote: > > I modified virtio(4) not to allocate unused memory. > I guess it fixes the issue. > > Could you check this? I confirmed your closing the report on syzbot.

Re: CVS commit: src/sys/dev

2020-05-30 Thread Alexander Nasonov
Jaromir Dolecek wrote: > Index: src/sys/dev/ic/bwfmvar.h > diff -u src/sys/dev/ic/bwfmvar.h:1.9 src/sys/dev/ic/bwfmvar.h:1.10 > --- src/sys/dev/ic/bwfmvar.h:1.9 Sat May 30 13:41:58 2020 > +++ src/sys/dev/ic/bwfmvar.h Sat May 30 15:55:47 2020 > @@ -1,4 +1,4 @@ > -/* $NetBSD: bwfmvar.h,v 1.9

Re: CVS commit: src/sys/dev/audio

2020-05-30 Thread nia
On Sat, May 30, 2020 at 09:48:36PM +0900, Tetsuya Isaki wrote: > I will do it on next weekend. > > Thanks, > --- > Tetsuya Isaki Thank you.

Re: CVS commit: src/sys/dev/audio

2020-05-30 Thread Tetsuya Isaki
At Fri, 29 May 2020 12:32:39 +, nia wrote: > OK... Can you request a pullup to ensure resuming with a stream > playing doesn't panic on 9.1? I will do it on next weekend. Thanks, --- Tetsuya Isaki

Re: CVS commit: src/sys/dev/audio

2020-05-29 Thread nia
OK... Can you request a pullup to ensure resuming with a stream playing doesn't panic on 9.1? Playing audio is very distorted on resume, but that can be resolved by killing the streams...

Re: CVS commit: src/sys/dev/audio

2020-05-28 Thread Tetsuya Isaki
At Wed, 27 May 2020 13:19:22 +, nia wrote: > I think this is because audio_rmixer_start is used unguarded > in audio_open (it doesn't check for the sc_rbusy flag). > This isn't the case for pmixer. > > So, if the audio device is opened for recording for the > first time after system

Re: CVS commit: src/sys/dev/usb

2020-05-27 Thread Paul Goyette
On Wed, 27 May 2020, Taylor R Campbell wrote: Not really, because we just need to know whether usb_once_init has been run. OK, great! Now, should we use something other than RUN_ONCE, which can both set up and tear down? Sure, that might be better in principle, but there probably aren't

Re: CVS commit: src/sys/dev/usb

2020-05-27 Thread Taylor R Campbell
> Date: Wed, 27 May 2020 05:28:41 -0700 (PDT) > From: Paul Goyette > > Do you also need to decrement the number of busses when one is > detached? Not really, because we just need to know whether usb_once_init has been run. Now, should we use something other than RUN_ONCE, which can both set up

Re: CVS commit: src/sys/dev/audio

2020-05-27 Thread nia
On Wed, May 27, 2020 at 09:46:04PM +0900, Tetsuya Isaki wrote: > Why are playback and recording asymmetric? > > Thanks, I think this is because audio_rmixer_start is used unguarded in audio_open (it doesn't check for the sc_rbusy flag). This isn't the case for pmixer. So, if the audio device

Re: CVS commit: src/sys/dev/audio

2020-05-27 Thread Tetsuya Isaki
nia, At Tue, 26 May 2020 15:20:16 +, Nia Alarie wrote: > Module Name: src > Committed By: nia > Date: Tue May 26 15:20:16 UTC 2020 > > Modified Files: > src/sys/dev/audio: audio.c > > Log Message: > audio: Only restart recording mixer on resume if it's already been started >

Re: CVS commit: src/sys/dev/usb

2020-05-27 Thread Paul Goyette
Do you also need to decrement the number of busses when one is detached? On Wed, 27 May 2020, Nick Hudson wrote: Module Name:src Committed By: skrll Date: Wed May 27 07:17:45 UTC 2020 Modified Files: src/sys/dev/usb: usb.c Log Message: Don't allow open of /dev/usb if

Re: [virtio] Re: CVS commit: src/sys/dev/pci

2020-05-27 Thread Shoichi Yamaguchi
Hi, On Wed, May 27, 2020 at 2:20 AM Maxime Villard wrote: > > Hi, > I don't know if this is related to your changes, but kMSan detected one uninit > variable in virtio 3h ago: > > https://syzkaller.appspot.com/text?tag=CrashReport=12084ef610 > > [ 153.4370851] panic: MSan:

[virtio] Re: CVS commit: src/sys/dev/pci

2020-05-26 Thread Maxime Villard
Hi, I don't know if this is related to your changes, but kMSan detected one uninit variable in virtio 3h ago: https://syzkaller.appspot.com/text?tag=CrashReport=12084ef610 [ 153.4370851] panic: MSan: Uninitialized Kmem Memory From virtio_pci_setup_interrupts() [

Re: CVS commit: src/sys/dev/pci

2020-05-20 Thread Sevan Janiyan
On 20/05/2020 21:18, Sevan Janiyan wrote: > Bump rcs tag which was missed in r1.9 That should've been r1.10 Sevan

Re: Freeze or panic during boot was: Re: CVS commit: src/sys/dev/ata

2020-05-02 Thread David Brownlee
On Sat, 2 May 2020, 20:10 Jason Thorpe, wrote: > > > On May 1, 2020, at 1:07 PM, Ryo ONODERA wrote: > > > > Hi, > > > > Have you missed this thread? > > > > If the problem requires more time to investigate, > > could you consider to revert ata change for a while? > > > > Thank you. > > I backed

Re: Freeze or panic during boot was: Re: CVS commit: src/sys/dev/ata

2020-05-02 Thread Jason Thorpe
> On May 1, 2020, at 1:07 PM, Ryo ONODERA wrote: > > Hi, > > Have you missed this thread? > > If the problem requires more time to investigate, > could you consider to revert ata change for a while? > > Thank you. I backed it out, but would appreciate some help tracking down the issue

Freeze or panic during boot was: Re: CVS commit: src/sys/dev/ata

2020-05-01 Thread Ryo ONODERA
Hi, Have you missed this thread? If the problem requires more time to investigate, could you consider to revert ata change for a while? Thank you. Alexander Nasonov writes: > David Brownlee wrote: >> Just another data point - seeing this same panic on a T480 with the >> latest kernel from

Re: CVS commit: src/sys/dev/ata

2020-05-01 Thread David Brownlee
Plus to confirm reverting just this commit from today's github copy of current (d5b32e03eac8b05d38a143ee0ec615efb2233201) boots fine on the T480 Thanks On Thu, 30 Apr 2020 at 00:12, Alexander Nasonov wrote: > > David Brownlee wrote: > > Just another data point - seeing this same panic on a T480

Re: CVS commit: src/sys/dev/ata

2020-04-29 Thread Alexander Nasonov
David Brownlee wrote: > Just another data point - seeing this same panic on a T480 with the > latest kernel from nyftp Same problem on T470. -- Alex

Re: CVS commit: src/sys/dev/ata

2020-04-29 Thread David Brownlee
Just another data point - seeing this same panic on a T480 with the latest kernel from nyftp

Re: CVS commit: src/sys/dev/ata

2020-04-27 Thread Ryo ONODERA
Ryo ONODERA writes: > Hi, > > After this commit, NetBSD/amd64-current on my HP Spectre x360 > freezes after acpiacad0 detection (before ld0 detection). > Reverting this commit in latest tree fixes my freeze problem. > > Could you take a look at my problem? > > Thank you. > > === === === > cpu7:

Re: CVS commit: src/sys/dev/ata

2020-04-27 Thread Ryo ONODERA
Hi, After this commit, NetBSD/amd64-current on my HP Spectre x360 freezes after acpiacad0 detection (before ld0 detection). Reverting this commit in latest tree fixes my freeze problem. Could you take a look at my problem? Thank you. === === === cpu7: CPU max freq 40 Hz cpu7: TSC freq

[disk changes] CVS commit: src/sys/dev/dkwedge

2020-04-13 Thread Maxime Villard
> Module Name:src > Committed By: jdolecek > Date: Sat Apr 11 16:00:34 UTC 2020 > > Modified Files: > src/sys/dev/dkwedge: dkwedge_apple.c dkwedge_bsdlabel.c dkwedge_gpt.c > dkwedge_mbr.c dkwedge_rdb.c It appears that since your recent changes, there is a

Re: CVS commit: src/sys/dev/usb

2020-04-02 Thread sc dying
On Thu, Apr 2, 2020 at 8:37 PM Nick Hudson wrote: > > Module Name:src > Committed By: skrll > Date: Thu Apr 2 11:37:23 UTC 2020 > > Modified Files: > src/sys/dev/usb: xhci.c xhcivar.h > > Log Message: > Reduce the memory footprint by allocating a ring per endpoint/pipe on

Re: CVS commit: src/sys/dev/ic

2020-03-23 Thread SAITOH Masanobu
On 2020/03/24 12:45, SAITOH Masanobu wrote: > Module Name: src > Committed By: msaitoh > Date: Tue Mar 24 03:45:26 UTC 2020 > > Modified Files: > src/sys/dev/ic: spdmem.c spdmemvar.h > > Log Message: > - Define some new parameters of DDR3 SPD ROM. > - Use fine timebase parameters

Re: CVS commit: src/sys/dev/usb

2020-03-23 Thread Maxime Villard
Le 23/03/2020 à 04:07, Roy Marples a écrit : > On 22/03/2020 08:30, Maxime Villard wrote: >> Overall "From OpenBSD" is a redflag for buggy and vulnerable code.. > > We should be above this, no software is perfect, not even ours. > > Roy You seem to be confusing one-off defects and structural

Re: CVS commit: src/sys/dev/usb

2020-03-22 Thread Roy Marples
On 22/03/2020 08:30, Maxime Villard wrote: Overall "From OpenBSD" is a redflag for buggy and vulnerable code.. We should be above this, no software is perfect, not even ours. Roy

Re: CVS commit: src/sys/dev/usb

2020-03-22 Thread Maxime Villard
Le 19/03/2020 à 08:49, Pierre Pronchery a écrit : > Module Name: src > Committed By: khorben > Date: Thu Mar 19 07:49:29 UTC 2020 > > Modified Files: > src/sys/dev/usb: if_umb.c > > Log Message: > When there is no network around the state timeout fires over and over again. >

Re: CVS commit: src/sys/dev/usb

2020-03-18 Thread Nick Hudson
On 18/03/2020 11:33, Robert Elz wrote: > Module Name: src > Committed By: kre > Date: Wed Mar 18 11:33:32 UTC 2020 > > Modified Files: > src/sys/dev/usb: if_aue.c > > Log Message: > This was still not correct,. USB_DEBUG is what mattered, not AUE_DEBUG, > the two are orthogonal.

Re: CVS commit: src/sys/dev/usb

2020-03-17 Thread Robert Elz
Date:Tue, 17 Mar 2020 22:58:24 -0400 From:"Christos Zoulas" Message-ID: <20200318025824.93b28f...@cvs.netbsd.org> | Log Message: | define un (pointed out by kre@) The reason I didn't suggest that change, is that now un is unused when USB_DEBUG is not defined.

Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Christos Zoulas
In article <20200314143238.gr5...@pony.stderr.spb.ru>, Valery Ushakov wrote: >How is is affected by the decision to change (or not) 0x%x to %#x? > This was in response to the statement: ... with a bit of patience might have been less drastic and as effective. christos

Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Valery Ushakov
On Sat, Mar 14, 2020 at 10:27:27 -0400, Christos Zoulas wrote: > > I don't belive that "if". It's like claiming you got rid of a stain > > on a wallpaper after you demolish a wall (not load-bearing, > > fortunately) and have to put it back and put new wallpaper. :) Get rid > > of the stain,

Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Christos Zoulas
> I don't belive that "if". It's like claiming you got rid of a stain > on a wallpaper after you demolish a wall (not load-bearing, > fortunately) and have to put it back and put new wallpaper. :) Get rid > of the stain, sure; but may be looking closely with a bit of patience > might have been

Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Valery Ushakov
On Sat, Mar 14, 2020 at 09:57:36 -0400, Christos Zoulas wrote: > > Even for the ones without the widths specified. E.g. I personally > > prefer zero printed as 0x0, not as 0, so I assume that when people > > choose either one that reflects their preference. Why mess with it? > > It's all so

Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Christos Zoulas
> Even for the ones without the widths specified. E.g. I personally > prefer zero printed as 0x0, not as 0, so I assume that when people > choose either one that reflects their preference. Why mess with it? > It's all so unnecessary. Yes, now we are discussing cosmetics (if 0 should be printed

re: CVS commit: src/sys/dev/usb

2020-03-14 Thread matthew green
> As I wrote in a follow up email, it changes formatting b/c you didn't > change field widths and IMO using %# with a field width is mostly > trouble to begin with. It's not the first time someone tries to do > this without actually understanding the consequences of the change. > Please, can we

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Valery Ushakov
On Fri, Mar 13, 2020 at 22:26:05 -0400, Christos Zoulas wrote: > > On Mar 13, 2020, at 10:25 PM, Valery Ushakov wrote: > > > > As I wrote in a follow up email, it changes formatting b/c you didn't > > change field widths and IMO using %# with a field width is mostly > > trouble to begin with.

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Christos Zoulas
> On Mar 13, 2020, at 10:25 PM, Valery Ushakov wrote: > > As I wrote in a follow up email, it changes formatting b/c you didn't > change field widths and IMO using %# with a field width is mostly > trouble to begin with. It's not the first time someone tries to do > this without actually

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Valery Ushakov
On Fri, Mar 13, 2020 at 22:15:31 -0400, Christos Zoulas wrote: > > This was not a part of the PR and is completely cosmetic (surely it > > supports plain %x if it does support %#x). Why was this necessary? > > (I know I would be quite miffed if someone made a change like that to > > my code). >

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Christos Zoulas
> This was not a part of the PR and is completely cosmetic (surely it > supports plain %x if it does support %#x). Why was this necessary? > (I know I would be quite miffed if someone made a change like that to > my code). Yes, that %x formatting change was not part of the PR, but I only

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Valery Ushakov
On Fri, Mar 13, 2020 at 17:09:14 -0700, Paul Goyette wrote: > On Sat, 14 Mar 2020, Valery Ushakov wrote: > > > On Fri, Mar 13, 2020 at 14:17:42 -0400, Christos Zoulas wrote: > > > > > Log Message: > > > PR/55068: sc.dying: Fix printf formats: > > [...] > > > - 0x% -> %# > > > > This was not a

  1   2   3   4   5   6   7   8   9   10   >