Re: add support for AMD 17h/3xh HD Audio

2020-10-23 Thread Robert Nagy
On 23/10/20 10:24 +1100, Jonathan Gray wrote:
> On Thu, Oct 22, 2020 at 04:34:11PM +0200, Robert Nagy wrote:
> > The diff below makes azalia(4) work on my new shiny chromium build box:
> 
> You have a 17-31-00 epyc or threadripper?
> 
> This id also shows up on
> B550, Ryzen 9 3900X 17-71-00
> X570, Ryzen 5 3600 17-71-00
> 
> The other two 17h/3xh ids also show up on 17-71-00 machines.
> 
> It seems they are shared between 17-3x epyc/threadripper and
> 17-7x ryzen.  I am not aware of any public documents from AMD which
> list these devices.
> 
> It is surprising your diff would change anything more than dmesg
> text.

The codec change was needed to make azalia work, without that all audio
playback just hangs. The rest is indeed just dmesg text.

OpenBSD 6.8-current (GENERIC.MP) #10: Thu Oct 22 16:30:18 CEST 2020
rob...@nerd.hu:/sys/arch/amd64/compile/GENERIC.MP
real mem = 17077854208 (16286MB)
avail mem = 16545206272 (15778MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe6b60 (63 entries)
bios0: vendor American Megatrends Inc. version "0310" date 09/01/2020
bios0: ASUS PRIME B450M-A II
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT SSDT SSDT MCFG HPET UEFI WPBT 
IVRS PCCT SSDT CRAT CDIT SSDT
acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) 
GPP7(S4) GPP8(S4) X161(S4) GPP9(S4) X162(S4) GPPA(S4) GPPB(S4) GPPC(S4) 
GPPD(S4) GPPE(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 3800XT 8-Core Processor, 3893.24 MHz, 17-71-00
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 32MB 64b/line disabled L3 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: AMD Ryzen 7 3800XT 8-Core Processor, 3892.70 MHz, 17-71-00
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 32MB 64b/line disabled L3 cache
cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: AMD Ryzen 7 3800XT 8-Core Processor, 3892.70 MHz, 17-71-00
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 32MB 64b/line disabled L3 cache
cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: AMD Ryzen 7 3800XT 8-Core Processor, 3892.70 MHz, 17-71-00
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,A

add support for AMD 17h/3xh HD Audio

2020-10-22 Thread Robert Nagy
The diff below makes azalia(4) work on my new shiny chromium build box:

Index: dev/pci/azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.178
diff -u -p -u -r1.178 azalia_codec.c
--- dev/pci/azalia_codec.c  14 Oct 2019 02:04:35 -  1.178
+++ dev/pci/azalia_codec.c  22 Oct 2020 14:32:55 -
@@ -222,6 +222,10 @@ azalia_codec_init_vtbl(codec_t *this)
this->subid == 0x00a0106b)
this->qrks |= AZ_QRK_WID_OVREF50;
break;
+   case 0x10ec0887:
+   this->name = "Realtek ALC887";
+   this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
+   break;
case 0x10ec0888:
this->name = "Realtek ALC888";
this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
Index: dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1939
diff -u -p -u -r1.1939 pcidevs
--- dev/pci/pcidevs 7 Oct 2020 11:14:59 -   1.1939
+++ dev/pci/pcidevs 22 Oct 2020 14:32:56 -
@@ -751,6 +751,7 @@ product AMD 17_PCIE_4   0x1470  17h PCIE
 product AMD 17_PCIE_5  0x1471  17h PCIE
 product AMD 17_3X_RC   0x1480  17h/3xh Root Complex
 product AMD 17_3X_CCP  0x1486  17h/3xh Crypto
+product AMD 17_3X_HDA  0x1487  17h/3xh HD Audio
 product AMD 14_HB  0x1510  14h Host
 product AMD 14_PCIE_1  0x1512  14h PCIE
 product AMD 14_PCIE_2  0x1513  14h PCIE
Index: dev/pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1932
diff -u -p -u -r1.1932 pcidevs.h
--- dev/pci/pcidevs.h   7 Oct 2020 11:15:31 -   1.1932
+++ dev/pci/pcidevs.h   22 Oct 2020 14:32:58 -
@@ -756,6 +756,7 @@
 #definePCI_PRODUCT_AMD_17_PCIE_5   0x1471  /* 17h PCIE */
 #definePCI_PRODUCT_AMD_17_3X_RC0x1480  /* 17h/3xh Root 
Complex */
 #definePCI_PRODUCT_AMD_17_3X_CCP   0x1486  /* 17h/3xh 
Crypto */
+#definePCI_PRODUCT_AMD_17_3X_HDA   0x1487  /* 17h/3xh HD 
Audio */
 #definePCI_PRODUCT_AMD_14_HB   0x1510  /* 14h Host */
 #definePCI_PRODUCT_AMD_14_PCIE_1   0x1512  /* 14h PCIE */
 #definePCI_PRODUCT_AMD_14_PCIE_2   0x1513  /* 14h PCIE */
Index: dev/pci/pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1927
diff -u -p -u -r1.1927 pcidevs_data.h
--- dev/pci/pcidevs_data.h  7 Oct 2020 11:15:31 -   1.1927
+++ dev/pci/pcidevs_data.h  22 Oct 2020 14:32:59 -
@@ -1328,6 +1328,10 @@ static const struct pci_known_product pc
"17h/3xh Crypto",
},
{
+   PCI_VENDOR_AMD, PCI_PRODUCT_AMD_17_3X_HDA,
+   "17h/3xh HD Audio",
+   },
+   {
PCI_VENDOR_AMD, PCI_PRODUCT_AMD_14_HB,
"14h Host",
},



Re: userland clock_gettime proof of concept

2020-07-03 Thread Robert Nagy
On 02/07/20 00:31 +0100, Stuart Henderson wrote:
> running on 38 of these, btw.

been running with this on all my workstations and laptops and on 3 build
servers as well



Re: userland clock_gettime proof of concept

2020-06-24 Thread Robert Nagy
On 22/06/20 19:12 +0300, Paul Irofti wrote:
> New iteration:
> 
>   - ps_timekeep should not coredump, pointed by deraadt@
>   - set ps_timekeep to 0 before user uvm_map for randomization
>   - map timekeep before fixup. confirmed by naddy@ that it fixes NULL init
>   - initialize va. clarified by kettenis@
> 
> How's the magical max skew value research going? Do we have a value yet?
> 
> Paul

I think we should pick 100 for now and then we can adjust it later if needed.

Of course this depends on kettenis' lfence diff so that amd ryzen tsc is sane.



Re: lfence for rdtsc

2020-06-21 Thread Robert Nagy
it definitely got better:

cpu0: TSC skew=0 observed drift=0
cpu0: TSC skew=0 observed drift=0
cpu1: TSC skew=51 observed drift=0
cpu2: TSC skew=68 observed drift=0
cpu3: TSC skew=68 observed drift=0
cpu4: TSC skew=0 observed drift=0
cpu5: TSC skew=0 observed drift=0
cpu6: TSC skew=85 observed drift=0
cpu7: TSC skew=51 observed drift=0
cpu8: TSC skew=17 observed drift=0
cpu9: TSC skew=34 observed drift=0
cpu10: TSC skew=0 observed drift=0
cpu11: TSC skew=17 observed drift=0
cpu12: TSC skew=0 observed drift=0
cpu13: TSC skew=-51 observed drift=0
cpu14: TSC skew=-17 observed drift=0
cpu15: TSC skew=-17 observed drift=0



Re: userland clock_gettime proof of concept

2020-06-12 Thread Robert Nagy
On 11/06/20 20:10 +0200, Mark Kettenis wrote:
> > Date: Thu, 11 Jun 2020 19:38:48 +0200
> > From: Christian Weisgerber 
> > 
> > Theo de Raadt:
> > 
> > > The diff is growing complexity to support a future which wouldn't
> > > exist if attempts at *supporting all* architectures received priority.
> > 
> > Adding support for more archs is very simple, since you just need
> > to copy the corresponding get_timecounter function from the kernel.
> > 
> > Here's arm64.  I'm running a kernel and libc with this.
> > 
> > I can also provide alpha, powerpc, and sparc64, but I don't have
> > such machines.
> 
> Hope you didn't spend too much time on that, because I already
> mentioned that I had arm64 working earlier in the thread.
> 
> I've just fired up one of my sparc64 machines such that I can check
> how well the approach works for an architecture with two exported
> timecounters.

Then please share the patches so that it can be integrated into the
main diff so that when the time comes it can go in at one shot.

Also it would help to avoid duplicate work.



Re: userland clock_gettime proof of concept

2020-05-30 Thread Robert Nagy
On 30/05/20 10:40 +0200, Mark Kettenis wrote:
> > Date: Sat, 30 May 2020 10:32:15 +0200
> > From: Robert Nagy 
> > 
> > On 29/05/20 17:51 +0300, Paul Irofti wrote:
> > > On Fri, May 29, 2020 at 03:00:50PM +0200, Mark Kettenis wrote:
> > > > > Date: Fri, 29 May 2020 13:45:37 +0100
> > > > > From: Stuart Henderson 
> > > > > 
> > > > > On 2020/05/29 13:50, Paul Irofti wrote:
> > > > > > +struct __timekeep {
> > > > > > +   uint32_t major; /* version major number */
> > > > > > +   uint32_t minor; /* version minor number */
> > > > > > +
> > > > > > +   u_int64_t   th_scale;
> > > > > > +   unsigned intth_offset_count;
> > > > > > +   struct bintime  th_offset;
> > > > > > +   struct bintime  th_naptime;
> > > > > > +   struct bintime  th_boottime;
> > > > > > +   volatile unsigned int   th_generation;
> > > > > > +
> > > > > > +   unsigned inttc_user;
> > > > > > +   unsigned inttc_counter_mask;
> > > > > > +};
> > > > > 
> > > > > Ah good, you got rid of u_int, that was causing problems with port 
> > > > > builds.
> > > > 
> > > > That in itself is a problem.  This means  is the wrong place
> > > > for this struct.  We need to find a better place for this.
> > > > 
> > > > Since this is now closely linked to the timecounter stuff
> > > >  would be an obvious place.  Now that file has:
> > > > 
> > > > #ifndef _KERNEL
> > > > #error "no user-serviceable parts inside"
> > > > #endif
> > > > 
> > > > you could change that into
> > > > 
> > > > #if !defined(_KERNEL) && !defined(_LIBC)
> > > > #error "no user-serviceable parts inside"
> > > > #endif
> > > > 
> > > > and make sure you #define _LIBC brefore uncluding this file where it
> > > > is needed.  As few places as possible obviously.
> > > 
> > > Done. Also includes claudio@'s observation.
> > 
> > I think if there are no more header changes, this should be commited to
> > have wider testing. We are also just after tree unlock so it feels like
> > the right time, and since there is no library bump we can easily revert
> > if there is a need for that.
> 
> Not ready yet.
> 
> I also would like to see at least one non-amd64 platform supported
> before we settle on this approach.


Which one would you prefer? arm64?



Re: userland clock_gettime proof of concept

2020-05-30 Thread Robert Nagy
On 29/05/20 17:51 +0300, Paul Irofti wrote:
> On Fri, May 29, 2020 at 03:00:50PM +0200, Mark Kettenis wrote:
> > > Date: Fri, 29 May 2020 13:45:37 +0100
> > > From: Stuart Henderson 
> > > 
> > > On 2020/05/29 13:50, Paul Irofti wrote:
> > > > +struct __timekeep {
> > > > +   uint32_t major; /* version major number */
> > > > +   uint32_t minor; /* version minor number */
> > > > +
> > > > +   u_int64_t   th_scale;
> > > > +   unsigned intth_offset_count;
> > > > +   struct bintime  th_offset;
> > > > +   struct bintime  th_naptime;
> > > > +   struct bintime  th_boottime;
> > > > +   volatile unsigned int   th_generation;
> > > > +
> > > > +   unsigned inttc_user;
> > > > +   unsigned inttc_counter_mask;
> > > > +};
> > > 
> > > Ah good, you got rid of u_int, that was causing problems with port builds.
> > 
> > That in itself is a problem.  This means  is the wrong place
> > for this struct.  We need to find a better place for this.
> > 
> > Since this is now closely linked to the timecounter stuff
> >  would be an obvious place.  Now that file has:
> > 
> > #ifndef _KERNEL
> > #error "no user-serviceable parts inside"
> > #endif
> > 
> > you could change that into
> > 
> > #if !defined(_KERNEL) && !defined(_LIBC)
> > #error "no user-serviceable parts inside"
> > #endif
> > 
> > and make sure you #define _LIBC brefore uncluding this file where it
> > is needed.  As few places as possible obviously.
> 
> Done. Also includes claudio@'s observation.

I think if there are no more header changes, this should be commited to
have wider testing. We are also just after tree unlock so it feels like
the right time, and since there is no library bump we can easily revert
if there is a need for that.



Re: userland clock_gettime proof of concept

2020-05-16 Thread Robert Nagy
On 16/05/20 20:14 +0300, Paul Irofti wrote:
> Make sure you clean your /usr/share/relink directory before compiling
> and installing this! Robert's machine was picking up old objects and
> creating a broken library on every reboot becuase his directory was not
> clean.

It was actually an old .so inside libc obj dir. So better clean everything
and just do a make build :)



Re: userland clock_gettime proof of concept

2020-05-13 Thread Robert Nagy
On 13/05/20 17:05 +0200, Mark Kettenis wrote:
> > The update currently does the work of clock_gettime(), but it can
> > probably be changed to only update the timehands and move the logic
> > elsewhere. Note that if we expose only the timehands to userland, most
> > of the bintime functionality has to also be made available there. Or so
> > I think.
> 
> Unfortunately what you're doing here isn't good enough.  You're only
> exporting low-resolution versions of the clocks.  The equivalent of
> what Linux class CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE.
> And I'm fairly certain that isn't what the applications want.  Why
> else would they be calling clock_gettime() a gazillion times per
> second...


Most of the big programs use CLOCK_MONOTONIC.



Re: userland clock_gettime proof of concept

2020-05-13 Thread Robert Nagy
On 13/05/20 17:03 +0300, Paul Irofti wrote:
> Hi,
> 
> By far one of the most popular and frequently used system calls is
> clock_gettime(2). As a result the cost of kernel-userland transitions
> out weight the actual work, thus I am proposing we make the data
> available directly from userland without passing through a system call.
> 
> This has been a subject of discussion multiple times across the years
> and last I heard from it was at the p2k19 hackthon that I hosted in
> Bucharest where espie@ sent me a diff from one of his students(?). Being
> busy with organization I have not had the time to look at it and
> I am thus getting back to it just now due to robert@ prodding me again
> on the subject. The proposed diff is mine, not the student's.
> 
> 
> The technical bits. 
> 
> Please keep in mind that this is only proof of concept. I am looking for
> ways to improve the current diff. As it is, it requires a flag day
> because it makes use of ELF aux vectors to export the data from the
> kernel.
> 
> I have also played with exposing the data via separate ELF sections and
> with kbind-mmap alternatives. The frist also involves a flag day and is
> more intrusive in my opinion, and the second I could not get to work. I
> think that would be the less intrusive way of doing it, possibly without
> a flag day, so if anyone knows how, please let me know.
> 
> The supported clocks are just those that do not require process specific
> data. Those can also be handled later if this diff is decided to be a
> good thing.
> 
> Clock update inside the kernel is done at the end of tc_windup(). There
> might be better places to do it. Let me know where.
> 
> The update currently does the work of clock_gettime(), but it can
> probably be changed to only update the timehands and move the logic
> elsewhere. Note that if we expose only the timehands to userland, most
> of the bintime functionality has to also be made available there. Or so
> I think.
> 
> In userland, I wrapped the clock_gettime(2) syscall in libc. There, I
> search for the auxiliary vector and fetch the timespec data from it.
> As you can see in the diff, parts from the elf_exec header will have to
> be exposed to userland if we do it this way.
> 
> 
> Results.
> 
> To test this diff you need to do a full release(8). I have tested this
> with multiple programs. Test programs, base programs and packages. None
> the less, this diff touches many important areas of our tree and is
> very fragile. I also probably missed changing some parts that required
> change due to libc or elf changes.
> 
> If you see regressions, which you probably will, please let me know.
> 
> Here is a stress test from robert@:
> 
> robert@x202:/home/robert> time ./t && time ./t2
> 0m00.11s real 0m00.12s user 0m00.00s system
> 0m09.99s real 0m02.64s user 0m03.36s system
> t is clock_gettime() and t2 is SYS_clock_gettime()

I am in the middle of rebuilding the packages that should gain significant
speedup right now. That small test does 5 million calls to clock_gettime,
so it is a bit over-reaching but still it shows the difference.



Re: ld.so speedup (part 2)

2019-04-28 Thread Robert Nagy
On 28/04/19 12:01 +0200, Matthieu Herrb wrote:
> On Sun, Apr 28, 2019 at 08:55:16AM +0100, Stuart Henderson wrote:
> > > >> > On Sat, Apr 27, 2019 at 09:55:33PM +0800, Nathanael Rensen wrote:
> > > >> > > The diff below speeds up ld.so library intialisation where the
> > > >>dependency
> > > >> > > tree is broad and deep, such as samba's smbd which links over 100
> > > >>libraries.
> > 
> > Past experience with ld.so changes suggests it would be good to have
> > test reports from multiple arches, *especially* hppa.
> 
> The regress test seem to pass here on hppa.
> 
> -- 
> Matthieu Herrb
> 

This also fixes the component FLAVOR of chromium which uses a gazillion
shared objects. Awesome work!



Re: libunwind: fix register numbering on OpenBSD/i386 (again)

2018-10-31 Thread Robert Nagy
On 31/10/18 09:54 +0100, Patrick Wildt wrote:
> Hi,
> 
> during the libunwind update to 6.0 we lost a particular patchset that
> fixes register numbering for OpenBSD/i386, thus breaking exception
> handling on that platform.  Looks like no one noticed until now.
> 
> ok?
> 
> Patrick
> 
> diff --git a/lib/libunwind/include/libunwind.h 
> b/lib/libunwind/include/libunwind.h
> index 29cf62e4335..4ff0c01b4e2 100644
> --- a/lib/libunwind/include/libunwind.h
> +++ b/lib/libunwind/include/libunwind.h
> @@ -164,8 +164,13 @@ enum {
>UNW_X86_ECX = 1,
>UNW_X86_EDX = 2,
>UNW_X86_EBX = 3,
> +#ifdef __OpenBSD__
> +  UNW_X86_ESP = 4,
> +  UNW_X86_EBP = 5,
> +#else
>UNW_X86_EBP = 4,
>UNW_X86_ESP = 5,
> +#endif
>UNW_X86_ESI = 6,
>UNW_X86_EDI = 7
>  };
> 

I think kettenis told me to remove this because they fixed it elsewhere.



Re: unveil(2) for spamlogd(8)

2018-07-18 Thread Robert Nagy
Hi

I think you should call unveil before pledge, so that you don't
need to pledge unveil.
This will prevent futher calls to unveil.

On 18/07/18 12:59 +0100, Ricardo Mestre wrote:
> Hi,
> 
> Are there any brave souls out there with unveil(2) enabled already?
> 
> If yes please test this diff for spamlogd(8) which seems to only need rw
> access to the file PATH_SPAMD_DB and nothing else.
> 
> Not asking for OKs yet, but if the code pattern is correct can I start looking
> at other programs?
> 
> Sorry for my earlier email, my clock was WAY off.
> 
> Index: spamlogd.c
> ===
> RCS file: /cvs/src/libexec/spamlogd/spamlogd.c,v
> retrieving revision 1.27
> diff -u -p -u -r1.27 spamlogd.c
> --- spamlogd.c16 Mar 2016 14:47:04 -  1.27
> +++ spamlogd.c18 Jul 2018 11:46:59 -
> @@ -376,12 +376,15 @@ main(int argc, char **argv)
>   }
>  
>   if (syncsend) {
> - if (pledge("stdio rpath wpath inet flock", NULL) == -1)
> + if (pledge("stdio rpath wpath inet flock unveil", NULL) == -1)
>   err(1, "pledge");
>   } else {
> - if (pledge("stdio rpath wpath flock", NULL) == -1)
> + if (pledge("stdio rpath wpath flock unveil", NULL) == -1)
>   err(1, "pledge");
>   }
> +
> + if (unveil(PATH_SPAMD_DB, "rw") == -1)
> + err(1, "unveil");
>  
>   pcap_loop(hpcap, -1, phandler, NULL);
>  
> 



Re: mpii support for sas3.5 controllers

2018-06-17 Thread Robert Nagy
Hi

Obviously I am ok with this since it makes my controller work ;)

mpii0 at pci6 dev 0 function 0 "Symbios Logic MegaRAID SAS3408" rev 0x01: msi
scsibus3 at mpii0: 640 targets
st0 at scsibus3 targ 5 lun 0:  SCSI4 1/sequential 
removable naa.5000e111c457f001
ch0 at scsibus3 targ 5 lun 1:  SCSI3 8/changer 
removable t10.BDT_FlexStor_II_00DE64104018_LL0
ses0 at scsibus3 targ 8 lun 0:  SCSI4 13/enclosure 
services fixed naa.510600b00dbc1490

On 17/06/18 08:06 +1000, Jonathan Matthew wrote:
> This adds support for SAS3.5 controllers in mpii(4).
> 
> To get these working, I had to rearrange the initialisation code a bit.
> The new controllers don't like being hard reset, which means we have to call
> mpii_iocfacts() to determine whether soft reset is supported before calling
> mpii_init().
> 
> The changes look pretty innocuous but could break older controllers (though
> this is how the linux driver works), so it'd help if people could test those.
> I found a SAS3008 (Dell HBA330) on my desk and that still works.
> 
> These controllers also support nvme devices, but that will have to remain
> unimplemented for now.
> 
> 
> Index: mpiireg.h
> ===
> RCS file: /cvs/src/sys/dev/pci/mpiireg.h,v
> retrieving revision 1.12
> diff -u -p -u -p -r1.12 mpiireg.h
> --- mpiireg.h 16 Jan 2017 18:09:35 -  1.12
> +++ mpiireg.h 16 Jun 2018 21:55:19 -
> @@ -524,6 +524,7 @@ struct mpii_msg_portfacts_reply {
>  #define MPII_PORTFACTS_PORTTYPE_ISCSI(0x20)
>  #define MPII_PORTFACTS_PORTTYPE_SAS_PHYSICAL (0x30)
>  #define MPII_PORTFACTS_PORTTYPE_SAS_VIRTUAL  (0x31)
> +#define MPII_PORTFACTS_PORTTYPE_TRI_MODE (0x40)
>   u_int16_t   reserved6;
>  
>   u_int16_t   max_posted_cmd_buffers;
> Index: mpii.c
> ===
> RCS file: /cvs/src/sys/dev/pci/mpii.c,v
> retrieving revision 1.113
> diff -u -p -u -p -r1.113 mpii.c
> --- mpii.c12 Dec 2017 11:18:32 -  1.113
> +++ mpii.c16 Jun 2018 21:55:20 -
> @@ -431,7 +431,13 @@ static const struct pci_matchid mpii_dev
>   { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS3108_1 },
>   { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS3108_2 },
>   { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS3108_3 },
> - { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS3108_4 }
> + { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS3108_4 },
> + { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS3408 },
> + { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS3416 },
> + { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS3508 },
> + { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS3508_1 },
> + { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS3516 },
> + { PCI_VENDOR_SYMBIOS,   PCI_PRODUCT_SYMBIOS_SAS3516_1 }
>  };
>  
>  int
> @@ -492,13 +498,13 @@ mpii_attach(struct device *parent, struc
>   }
>   printf(": %s\n", pci_intr_string(sc->sc_pc, ih));
>  
> - if (mpii_init(sc) != 0) {
> - printf("%s: unable to initialize ioc\n", DEVNAME(sc));
> + if (mpii_iocfacts(sc) != 0) {
> + printf("%s: unable to get iocfacts\n", DEVNAME(sc));
>   goto unmap;
>   }
>  
> - if (mpii_iocfacts(sc) != 0) {
> - printf("%s: unable to get iocfacts\n", DEVNAME(sc));
> + if (mpii_init(sc) != 0) {
> + printf("%s: unable to initialize ioc\n", DEVNAME(sc));
>   goto unmap;
>   }
>  
> @@ -556,7 +562,8 @@ mpii_attach(struct device *parent, struc
>  
>   /* XXX bail on unsupported porttype? */
>   if ((sc->sc_porttype == MPII_PORTFACTS_PORTTYPE_SAS_PHYSICAL) ||
> - (sc->sc_porttype == MPII_PORTFACTS_PORTTYPE_SAS_VIRTUAL)) {
> + (sc->sc_porttype == MPII_PORTFACTS_PORTTYPE_SAS_VIRTUAL) ||
> + (sc->sc_porttype == MPII_PORTFACTS_PORTTYPE_TRI_MODE)) {
>   if (mpii_eventnotify(sc) != 0) {
>   printf("%s: unable to enable events\n", DEVNAME(sc));
>   goto free_queues;
> @@ -876,7 +883,8 @@ mpii_scsi_probe(struct scsi_link *link)
>   int flags;
>  
>   if ((sc->sc_porttype != MPII_PORTFACTS_PORTTYPE_SAS_PHYSICAL) &&
> - (sc->sc_porttype != MPII_PORTFACTS_PORTTYPE_SAS_VIRTUAL))
> + (sc->sc_porttype != MPII_PORTFACTS_PORTTYPE_SAS_VIRTUAL) &&
> + (sc->sc_porttype != MPII_PORTFACTS_PORTTYPE_TRI_MODE))
>   return (ENXIO);
>  
>   dev = sc->sc_devs[link->target];
> @@ -1261,12 +1269,16 @@ mpii_iocfacts(struct mpii_softc *sc)
>   if (ISSET(lemtoh32(_capabilities),
>   MPII_IOCFACTS_CAPABILITY_INTEGRATED_RAID))
>   SET(sc->sc_flags, MPII_F_RAID);
> + if (ISSET(lemtoh32(_capabilities),
> + MPII_IOCFACTS_CAPABILITY_EVENT_REPLAY))
> + sc->sc_ioc_event_replay = 1;
>  
>   sc->sc_max_cmds = MIN(lemtoh16(_credit),
>   

Re: [patch] config(8) and KARL usage

2018-01-17 Thread Robert Nagy
On 17/01/18 11:40 +0100, Martin Pieuchot wrote:
> Hello Sebastien,
> 
> On 17/01/18(Wed) 10:19, Sebastien Marie wrote:
> > [...] 
> > kernel modification is desirable in some cases, at least for disabling
> > ulpt(4) when using cups with USB printer.
> 
> Sorry to hijack your thread, but if somebody wants to fix this ulpt(4)
> problem permanently here's the plan:
> 
>  - Add the USBD_EXCLUSIVE_USE to usbd_open_pipe() in ulptopen().
>Actually this flag should be the default everywhere.  This should
>prevent open(2) on /dev/ulpt? to work if a userland driver is using
>your printer.
> 
>  - Do some plumbing between libusb/ugen(4)/usb(4) to make it possible
>to submit bulk transfer via /dev/usb?.  The logic in ugenopen()
>should also have the USBD_EXCLUSIVE_USE flag such that it will fail
>if the corresponding /dev/ultp? has already been opened.
> 
> That should be enough to have CUPS work with GENERIC kernels without
> having to disable anything.  I'm here to help/review diffs but since
> I don't have a printer myself, I can't do the work.
> 

Oh yes please.



Re: preliminary kabylake support for inteldrm

2017-09-26 Thread Robert Nagy

Hi

This is an updated diff for preliminary kabylake support for 6.2,
this needs extensive testing on all inteldrm variants.

This diff is also in snapshots now so please, test, test test!

Thank you

Index: sys/dev/pci/drm/i915_pciids.h
===
RCS file: /cvs/src/sys/dev/pci/drm/i915_pciids.h,v
retrieving revision 1.3
diff -u -p -u -r1.3 i915_pciids.h
--- sys/dev/pci/drm/i915_pciids.h   1 Jul 2017 16:14:10 -   1.3
+++ sys/dev/pci/drm/i915_pciids.h   26 Sep 2017 14:57:52 -
@@ -295,4 +295,40 @@
INTEL_VGA_DEVICE(0x5A84, info), /* APL HD Graphics 505 */ \
INTEL_VGA_DEVICE(0x5A85, info)  /* APL HD Graphics 500 */
 
+#define INTEL_KBL_GT1_IDS(info)\
+   INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
+   INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
+   INTEL_VGA_DEVICE(0x5917, info), /* DT  GT1.5 */ \
+   INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
+   INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
+   INTEL_VGA_DEVICE(0x5902, info), /* DT  GT1 */ \
+   INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
+   INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
+
+#define INTEL_KBL_GT2_IDS(info)\
+   INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
+   INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \
+   INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
+   INTEL_VGA_DEVICE(0x5912, info), /* DT  GT2 */ \
+   INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \
+   INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \
+   INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
+
+#define INTEL_KBL_GT3_IDS(info)\
+   INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
+   INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
+   INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
+
+#define INTEL_KBL_GT4_IDS(info)\
+   INTEL_VGA_DEVICE(0x5932, info), /* DT  GT4 */ \
+   INTEL_VGA_DEVICE(0x593B, info), /* Halo GT4 */ \
+   INTEL_VGA_DEVICE(0x593A, info), /* SRV GT4 */ \
+   INTEL_VGA_DEVICE(0x593D, info)  /* WKS GT4 */
+
+#define INTEL_KBL_IDS(info) \
+   INTEL_KBL_GT1_IDS(info), \
+   INTEL_KBL_GT2_IDS(info), \
+   INTEL_KBL_GT3_IDS(info), \
+   INTEL_KBL_GT4_IDS(info)
+
 #endif /* _I915_PCIIDS_H */
Index: sys/dev/pci/drm/i915/i915_devlist.h
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_devlist.h,v
retrieving revision 1.6
diff -u -p -u -r1.6 i915_devlist.h
--- sys/dev/pci/drm/i915/i915_devlist.h 6 Jul 2017 10:09:26 -   1.6
+++ sys/dev/pci/drm/i915/i915_devlist.h 26 Sep 2017 14:57:52 -
@@ -154,4 +154,26 @@ static const struct pci_matchid i915_dev
{ 0x8086, 0x1a85 },
{ 0x8086, 0x5a84 },
{ 0x8086, 0x5a85 },
+   { 0x8086, 0x5913 },
+   { 0x8086, 0x5915 },
+   { 0x8086, 0x5917 },
+   { 0x8086, 0x5906 },
+   { 0x8086, 0x590e },
+   { 0x8086, 0x5902 },
+   { 0x8086, 0x590b },
+   { 0x8086, 0x590a },
+   { 0x8086, 0x5916 },
+   { 0x8086, 0x5921 },
+   { 0x8086, 0x591e },
+   { 0x8086, 0x5912 },
+   { 0x8086, 0x591b },
+   { 0x8086, 0x591a },
+   { 0x8086, 0x591d },
+   { 0x8086, 0x5926 },
+   { 0x8086, 0x592b },
+   { 0x8086, 0x592a },
+   { 0x8086, 0x5932 },
+   { 0x8086, 0x593b },
+   { 0x8086, 0x593a },
+   { 0x8086, 0x593d },
 };
Index: sys/dev/pci/drm/i915/i915_dma.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_dma.c,v
retrieving revision 1.25
diff -u -p -u -r1.25 i915_dma.c
--- sys/dev/pci/drm/i915/i915_dma.c 1 Jul 2017 16:14:10 -   1.25
+++ sys/dev/pci/drm/i915/i915_dma.c 26 Sep 2017 14:57:52 -
@@ -712,7 +712,8 @@ static void gen9_sseu_info_init(struct d
 * supports EU power gating on devices with more than one EU
 * pair per subslice.
*/
-   info->has_slice_pg = (IS_SKYLAKE(dev) && (info->slice_total > 1));
+   info->has_slice_pg = ((IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) &&
+  (info->slice_total > 1));
info->has_subslice_pg = (IS_BROXTON(dev) && (info->subslice_total > 1));
info->has_eu_pg = (info->eu_per_subslice > 2);
 }
@@ -858,6 +859,37 @@ static void intel_device_info_runtime_in
DRM_INFO("Display fused off, disabling\n");
info->num_pipes = 0;
}
+   } else if (info->num_pipes > 0 && INTEL_INFO(dev)->gen == 9) {
+   u32 dfsm = I915_READ(SKL_DFSM);
+   u8 disabled_mask = 0;
+   bool invalid;
+   int num_bits;
+
+   if (dfsm & SKL_DFSM_PIPE_A_DISABLE)
+   disabled_mask |= BIT(PIPE_A);
+   if (dfsm & SKL_DFSM_PIPE_B_DISABLE)
+   disabled_mask |= BIT(PIPE_B);
+ 

preliminary kabylake support for inteldrm

2017-09-07 Thread Robert Nagy
Hi!

It turns out that the changes to get kabylake to work are quiet minimal so I 
took a
stab at it and backported all the relevant kabylake commits from linux-4.8.y to
our drm tree. I did not touch anything outside of dev/pci/drm/i915 on purprose,
so that the update work of kettenis@ is only touched minimally.
There are some not really needed changes but at least that syncs some code with
linux for the future as well.

I am sending this diff to tech@ so that we can get more tests. You can run this
with !kabylake as well to see if there is any regression.

Index: sys/dev/pci/drm/i915_pciids.h
===
RCS file: /cvs/src/sys/dev/pci/drm/i915_pciids.h,v
retrieving revision 1.3
diff -u -p -u -r1.3 i915_pciids.h
--- sys/dev/pci/drm/i915_pciids.h   1 Jul 2017 16:14:10 -   1.3
+++ sys/dev/pci/drm/i915_pciids.h   5 Sep 2017 22:50:05 -
@@ -295,4 +295,40 @@
INTEL_VGA_DEVICE(0x5A84, info), /* APL HD Graphics 505 */ \
INTEL_VGA_DEVICE(0x5A85, info)  /* APL HD Graphics 500 */
 
+#define INTEL_KBL_GT1_IDS(info)\
+   INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
+   INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
+   INTEL_VGA_DEVICE(0x5917, info), /* DT  GT1.5 */ \
+   INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
+   INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
+   INTEL_VGA_DEVICE(0x5902, info), /* DT  GT1 */ \
+   INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
+   INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
+
+#define INTEL_KBL_GT2_IDS(info)\
+   INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
+   INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \
+   INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
+   INTEL_VGA_DEVICE(0x5912, info), /* DT  GT2 */ \
+   INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \
+   INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \
+   INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
+
+#define INTEL_KBL_GT3_IDS(info)\
+   INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
+   INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
+   INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
+
+#define INTEL_KBL_GT4_IDS(info)\
+   INTEL_VGA_DEVICE(0x5932, info), /* DT  GT4 */ \
+   INTEL_VGA_DEVICE(0x593B, info), /* Halo GT4 */ \
+   INTEL_VGA_DEVICE(0x593A, info), /* SRV GT4 */ \
+   INTEL_VGA_DEVICE(0x593D, info)  /* WKS GT4 */
+
+#define INTEL_KBL_IDS(info) \
+   INTEL_KBL_GT1_IDS(info), \
+   INTEL_KBL_GT2_IDS(info), \
+   INTEL_KBL_GT3_IDS(info), \
+   INTEL_KBL_GT4_IDS(info)
+
 #endif /* _I915_PCIIDS_H */
Index: sys/dev/pci/drm/i915/i915_dma.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_dma.c,v
retrieving revision 1.25
diff -u -p -u -r1.25 i915_dma.c
--- sys/dev/pci/drm/i915/i915_dma.c 1 Jul 2017 16:14:10 -   1.25
+++ sys/dev/pci/drm/i915/i915_dma.c 5 Sep 2017 22:50:06 -
@@ -712,7 +712,8 @@ static void gen9_sseu_info_init(struct d
 * supports EU power gating on devices with more than one EU
 * pair per subslice.
*/
-   info->has_slice_pg = (IS_SKYLAKE(dev) && (info->slice_total > 1));
+   info->has_slice_pg = ((IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) &&
+  (info->slice_total > 1));
info->has_subslice_pg = (IS_BROXTON(dev) && (info->subslice_total > 1));
info->has_eu_pg = (info->eu_per_subslice > 2);
 }
@@ -858,6 +859,37 @@ static void intel_device_info_runtime_in
DRM_INFO("Display fused off, disabling\n");
info->num_pipes = 0;
}
+   } else if (info->num_pipes > 0 && INTEL_INFO(dev)->gen == 9) {
+   u32 dfsm = I915_READ(SKL_DFSM);
+   u8 disabled_mask = 0;
+   bool invalid;
+   int num_bits;
+
+   if (dfsm & SKL_DFSM_PIPE_A_DISABLE)
+   disabled_mask |= BIT(PIPE_A);
+   if (dfsm & SKL_DFSM_PIPE_B_DISABLE)
+   disabled_mask |= BIT(PIPE_B);
+   if (dfsm & SKL_DFSM_PIPE_C_DISABLE)
+   disabled_mask |= BIT(PIPE_C);
+
+   num_bits = hweight8(disabled_mask);
+
+   switch (disabled_mask) {
+   case BIT(PIPE_A):
+   case BIT(PIPE_B):
+   case BIT(PIPE_A) | BIT(PIPE_B):
+   case BIT(PIPE_A) | BIT(PIPE_C):
+   invalid = true;
+   break;
+   default:
+   invalid = false;
+   }
+
+   if (num_bits > info->num_pipes || invalid)
+   DRM_ERROR("invalid pipe fuse configuration: 0x%x\n",
+ disabled_mask);
+   else
+   info->num_pipes -= num_bits;
  

Re: mountd is immortal

2011-07-28 Thread Robert Nagy
It seems that SIGTERM is not enough for mountd, according to the code
SIGTERM only sends a RPCMNT_UMNTALL broadcast to the clients.
So I think what we should do in this case is to first send a SIGTERM to mountd,
and then SIGKILL it in rc_stop().

On (2011-07-28 09:46), David Coppa wrote:
 It doesn't want to die...
 
 Do you see this problem or is it just mine?
 Any clue?
 
 # /etc/rc.d/mountd start
 mountd(ok)
 # ps akuwwx|grep -v grep|grep mountd
 root 15715  0.0  0.0   616   368 ??  Ss 9:39AM0:00.00 /sbin/mountd
 # /etc/rc.d/nfsd start
 nfsd(ok)
 # ps akuwwx|grep -v grep|grep nfs
 root 11051  0.0  0.0   120   156 ??  S  9:39AM0:00.00 nfsd: 
 server (nfsd)
 root  9270  0.0  0.0   120   156 ??  S  9:39AM0:00.00 nfsd: 
 server (nfsd)
 root 10254  0.0  0.0   120   156 ??  S  9:39AM0:00.00 nfsd: 
 server (nfsd)
 root 20969  0.0  0.0   156   228 ??  Ss 9:39AM0:00.00 /sbin/nfsd 
 -tun 4
 root 17010  0.0  0.0   120   156 ??  S  9:39AM0:00.00 nfsd: 
 server (nfsd)
 # /etc/rc.d/nfsd stop
 nfsd(ok)
 # ps akuwwx|grep -v grep|grep nfs
 # time /etc/rc.d/mountd stop
 mountd(failed)
 0m30.32s real 0m0.00s user 0m0.01s system
 # ps akuwwx|grep -v grep|grep mountd
 root 15715  0.0  0.0   616   388 ??  Ss 9:39AM0:00.00 /sbin/mountd
 # pkill -f /sbin/mountd
 # ps akuwwx|grep -v grep|grep mountd
 root 15715  0.0  0.0   616   388 ??  Ss 9:39AM0:00.00 /sbin/mountd
 # pkill -9 -f /sbin/mountd
 # ps akuwwx|grep -v grep|grep mountd
 #



Re: mountd is immortal

2011-07-28 Thread Robert Nagy
On (2011-07-28 10:22), Antoine Jacoutot wrote:
 On Thu, 28 Jul 2011, David Coppa wrote:
 
  On Thu, 28 Jul 2011, Robert Nagy wrote:
  
   It seems that SIGTERM is not enough for mountd, according to the code
   SIGTERM only sends a RPCMNT_UMNTALL broadcast to the clients.
   So I think what we should do in this case is to first send a SIGTERM to 
   mountd,
   and then SIGKILL it in rc_stop().
  
  Something like this? the sleep is just paranoia, don't know if it's 
  useful...
 
 Why not use rc_post for SIGKILL?

Because rc_post() does not get called if rc_stop() fails and it does
because mountd does not die after the SIGTERM.



Re: mountd is immortal

2011-07-28 Thread Robert Nagy
On (2011-07-28 10:30), Ingo Schwarze wrote:
 Hi Antoine,
 
 Antoine Jacoutot wrote on Thu, Jul 28, 2011 at 10:22:56AM +0200:
  On Thu, 28 Jul 2011, David Coppa wrote:
  On Thu, 28 Jul 2011, Robert Nagy wrote:
  
  It seems that SIGTERM is not enough for mountd, according to the code
  SIGTERM only sends a RPCMNT_UMNTALL broadcast to the clients.
  So I think what we should do in this case is to first send a SIGTERM
  to mountd, and then SIGKILL it in rc_stop().
 
  Something like this? the sleep is just paranoia, don't know
  if it's useful...
 
  Why not use rc_post for SIGKILL?
 
 Because
 
   rc_do rc_wait stop || rc_exit failed
 
 is called before rc_post.
 
 When the daemon refuses to die, the post-mortem action will not
 even be attempted.
 
  Index: mountd
  ===
  RCS file: /cvs/src/etc/rc.d/mountd,v
  retrieving revision 1.1
  diff -u -p -r1.1 mountd
  --- mountd 8 Jul 2011 00:54:04 -   1.1
  +++ mountd 28 Jul 2011 08:15:37 -
  @@ -6,4 +6,10 @@ daemon=/sbin/mountd
   
   . /etc/rc.d/rc.subr
   
  +rc_stop() {
  +  pkill -f ^${pexp}
  +  sleep 1
  +  pkill -9 -f ^${pexp}
  +}
  +
   rc_cmd $1
 
 I worry more that fixed-time sleeps often prove to short,
 not so much that it might be useless, but i don't see a better
 option right now.  Sorry, I can't test or look in more detail
 right now.
 
 Yours,
   Ingo
 

I am not sure that we want to sleep or not. Theo what do you think?



Re: mountd is immortal

2011-07-28 Thread Robert Nagy
On (2011-07-28 11:17), Mark Kettenis wrote:
  Date: Thu, 28 Jul 2011 10:16:00 +0200
  From: David Coppa dco...@gmail.com
  
  On Thu, 28 Jul 2011, Robert Nagy wrote:
  
   It seems that SIGTERM is not enough for mountd, according to the code
   SIGTERM only sends a RPCMNT_UMNTALL broadcast to the clients.
   So I think what we should do in this case is to first send a SIGTERM to 
   mountd,
   and then SIGKILL it in rc_stop().
  
  Something like this? the sleep is just paranoia, don't know if it's 
  useful...
 
 Well, that sleep makes some sense at least; you want to give the
 daemon some time to clean up.  The question is whether a single second
 is enough for that...

Well mountd actually dies about 1.5-2 minutes after sending it a SIGTERM...



Thank you for making p2k9 possible!

2009-10-11 Thread Robert Nagy
Hello

p2k9 (the ports hackathon in Budapest) is on since Friday. People
are working on different things like GNOME, GCC4, BluRay support or
even ACPI.

I would like to thank everyone who donated money to the project because
the individual donors made it possible to organize this event.
So ... BIG THANKS GOES TO OUR USERS, to people supporting the project
even at these times.

I'd also like to thank NIIF and Sun Microsystems Hungary for lending
us a nice hackroom and hardware for the hackathon.