Re: add intel 6235 support to iwn(4)
This fixes iwn(4) for me too. Where previously I would get "iwn0: fatal firmware error" I now get a working setup with: iwn0 at pci1 dev 0 function 0 "Intel Centrino Advanced-N 6030" rev 0x34: msi, MIMO 2T2R, MoW, address 88:53:2e:d9:dd:9d Full dmesg (including a boot with the previous kernel and the error I got) included at the end of this mail. Thanks Joshua and James, that fixes one of the remaining issues on my laptop. This e-mail sent via that iwn(4) ;) Paul 'WEiRD' de Weerd On Tue, Nov 13, 2012 at 09:02:24PM -0500, James Turner wrote: | I was actually able to add support myself with the following diff. | | -- | James Turner | ja...@calminferno.net | Index: if_iwn.c | === | RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v | retrieving revision 1.115 | diff -u -p if_iwn.c | --- if_iwn.c 11 Nov 2012 20:45:31 - 1.115 | +++ if_iwn.c 14 Nov 2012 02:00:52 - | @@ -639,7 +639,8 @@ iwn5000_attach(struct iwn_softc *sc, pci_product_id_t | break; | case IWN_HW_REV_TYPE_6005: | sc->limits = &iwn6000_sensitivity_limits; | - if (pid == PCI_PRODUCT_INTEL_WL_6235_1) { | + if (pid == PCI_PRODUCT_INTEL_WL_6235_1 || | + pid == PCI_PRODUCT_INTEL_WL_6030_2) { | sc->fwname = "iwn-6030"; | | /* XXX: The 6235 generates a fatal firmware error when | OpenBSD 5.2-current (GENERIC.MP) #0: Sun Nov 11 22:19:14 CET 2012 we...@banana.alm.weirdnet.nl:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8501063680 (8107MB) avail mem = 8252280832 (7869MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe6020 (18 entries) bios0: vendor INSYDE version "R1010H5" date 07/28/2011 bios0: Sony Corporation VPCZ23C5E acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP TCPA ASF! HPET APIC MCFG SLIC WDAT SSDT BOOT SSDT ASPT SSDT SSDT SSDT SSDT acpi0: wakeup devices EHC1(S3) EHC2(S3) HDEF(S0) WLAN(S0) RP01(S0) RMSC(S0) RP02(S0) NXUC(S3) RP03(S3) RLAN(S3) RP04(S3) RP07(S3) PEG0(S0) PEGP(S0) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2794.10 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2793.66 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2793.66 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2793.66 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP01) acpiprt2 at acpi0: bus 3 (RP02) acpiprt3 at acpi0: bus 4 (RP03) acpiprt4 at acpi0: bus 5 (RP04) acpiprt5 at acpi0: bus 8 (RP07) acpiprt6 at acpi0: bus -1 (PEG0) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpitz0 at acpi0: critical temperature is 98 degC acpibat0 at acpi0: BAT1 type Lion oem "Sony Corporation" acpibat1 at acpi0: BAT2 type Lion oem "Sony Corporation" acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB acpidock0 at acpi0: DOCK not docked (0) acpivideo0 at acpi0: DD01 acpivideo1 at acpi0: DD02 acpivideo2 at acpi0: DD03 acpivideo3 at acpi0: DD04 acpivideo4 at acpi0: DD05 acpivideo5 at acpi0: DD06 acpivideo6 at acpi0: DD07 acpivideo7 at acpi0: DD08 acpivideo8 at acpi0: GFX0 acpivout0 at acpivideo8: DD02 cpu0: Enhanced Speed
Re: add intel 6235 support to iwn(4)
I was actually able to add support myself with the following diff. -- James Turner ja...@calminferno.net Index: if_iwn.c === RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v retrieving revision 1.115 diff -u -p if_iwn.c --- if_iwn.c11 Nov 2012 20:45:31 - 1.115 +++ if_iwn.c14 Nov 2012 02:00:52 - @@ -639,7 +639,8 @@ iwn5000_attach(struct iwn_softc *sc, pci_product_id_t break; case IWN_HW_REV_TYPE_6005: sc->limits = &iwn6000_sensitivity_limits; - if (pid == PCI_PRODUCT_INTEL_WL_6235_1) { + if (pid == PCI_PRODUCT_INTEL_WL_6235_1 || + pid == PCI_PRODUCT_INTEL_WL_6030_2) { sc->fwname = "iwn-6030"; /* XXX: The 6235 generates a fatal firmware error when
Re: add intel 6235 support to iwn(4)
Does this happen to also add support for 6230? If not how hard would it be to add 6230 support now that 6235 is supported? I'd be happy to test diffs. -- James Turner ja...@calminferno.net
Re: Major dhclient(8) changes - no more dhclient-script
2012/11/9 Kenneth R Westerback > Those of you following -current or running very recent snaps may have > noticed a lot of changes to dhclient in the last couple of weeks. > > Aside from some major clean up, these changes revolve around the > elimination of the dhclient-script as both detrimental to sanity > and our ability to move forward to better network configuration > automation. > > So far a couple of uses for dhclient-script have been reported and > workarounds have to be developed for these scenarios. > > But now that most of the changes are committed we are very interested > in making sure that scenarios that lead people to modify dhclient-script > are identified sooner rather than later. > > So please test the new dhclient(8) in as many situations as possible > and report both 'noraml' bugs/regressions and problems you have not > been able to solve without dhclient-script. Thanks. > > Ken > > Is it possible to ignore route pushed by the server ? -- - () ascii ribbon campaign - against html e-mail /\
raw_usrreq - spl diff
Hello - I originally asked mikeb if splnet was needed in net/pfkey.c. He added onto my diff (which I have included below). I noticed route_usrreq from net/rtsock.c calls raw_usrreq protected by splsoftnet. I thought I'd send it to tech@ to possibly get more feedback. Here is the diff I am running with. I haven't had any regressions. Index: sys/net/pfkey.c === RCS file: /cvs/src/sys/net/pfkey.c,v retrieving revision 1.19 diff -N -u -p sys/net/pfkey.c --- sys/net/pfkey.c 20 Sep 2012 10:25:03 - 1.19 +++ sys/net/pfkey.c 11 Nov 2012 01:18:42 - @@ -198,15 +198,12 @@ static int pfkey_attach(struct socket *socket, struct mbuf *proto, struct proc *p) { int rval; - int s; if (!(socket->so_pcb = malloc(sizeof(struct rawcb), M_PCB, M_DONTWAIT | M_ZERO))) return (ENOMEM); - s = splnet(); rval = raw_usrreq(socket, PRU_ATTACH, NULL, proto, NULL, p); - splx(s); if (rval) goto ret; @@ -228,12 +225,10 @@ ret: static int pfkey_detach(struct socket *socket, struct proc *p) { - int rval, i, s; + int rval, i; rval = pfkey_versions[socket->so_proto->pr_protocol]->release(socket); - s = splnet(); i = raw_usrreq(socket, PRU_DETACH, NULL, NULL, NULL, p); - splx(s); if (!rval) rval = i; @@ -246,7 +241,6 @@ pfkey_usrreq(struct socket *socket, int req, struct mb struct mbuf *nam, struct mbuf *control, struct proc *p) { int rval; - int s; if ((socket->so_proto->pr_protocol > PFKEY_PROTOCOL_MAX) || (socket->so_proto->pr_protocol < 0) || @@ -261,9 +255,7 @@ pfkey_usrreq(struct socket *socket, int req, struct mb return (pfkey_detach(socket, p)); default: - s = splnet(); rval = raw_usrreq(socket, req, mbuf, nam, control, p); - splx(s); } return (rval); Index: sys/net/raw_usrreq.c === RCS file: /cvs/src/sys/net/raw_usrreq.c,v retrieving revision 1.14 diff -N -u -p sys/net/raw_usrreq.c --- sys/net/raw_usrreq.c11 Jan 2012 23:47:06 - 1.14 +++ sys/net/raw_usrreq.c11 Nov 2012 01:18:42 - @@ -151,7 +151,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m, { struct rawcb *rp = sotorawcb(so); int error = 0; - int len; + int len, s; if (req == PRU_CONTROL) return (EOPNOTSUPP); @@ -163,6 +163,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m, error = EINVAL; goto release; } + s = splsoftnet(); switch (req) { /* @@ -269,6 +270,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m, /* * stat: don't bother with a blocksize. */ + splx(s); return (0); /* @@ -276,6 +278,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m, */ case PRU_RCVOOB: case PRU_RCVD: + splx(s); return (EOPNOTSUPP); case PRU_LISTEN: @@ -308,6 +311,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m, panic("raw_usrreq"); } release: + splx(s); if (m != NULL) m_freem(m); return (error);
usr.bin/mail: use F_OK instead of 0 in access()
hi, use F_OK macro instead of 0 in access() when cheching by file existence. make de code easier to read. no funcional change. OK ? Index: cmd2.c === RCS file: /cvs/src/usr.bin/mail/cmd2.c,v retrieving revision 1.18 diff -u -p -r1.18 cmd2.c --- cmd2.c 6 Apr 2011 11:36:26 - 1.18 +++ cmd2.c 13 Nov 2012 18:54:35 - @@ -166,7 +166,7 @@ save1(char *str, int mark, char *cmd, st return(1); printf("\"%s\" ", file); fflush(stdout); - if (access(file, 0) >= 0) + if (access(file, F_OK) >= 0) disp = "[Appended]"; else disp = "[New file]";
Re: agp(4): release unbinded memory
> Date: Tue, 13 Nov 2012 16:15:59 +0100 > From: Martin Pieuchot > > On 13/11/12(Tue) 13:45, Mark Kettenis wrote: > > > Date: Tue, 13 Nov 2012 12:30:29 +0100 > > > From: Martin Pieuchot > > > > > > While experimenting with the agp(4) interface I found that if you > > > release the interface (AGPIOC_RELEASE) before closing its file > > > descriptor you'll end up with allocated but unbinded memory blocks. > > > > That behaviour is documented in agp(4). So if we change it, we should > > change the documentation as well. That said, the documentation also > > says that the AGPIOC_RELEASE ioctl doesn't unbind any allocated > > memory. And that doesn't seem to be true. > > > > > This behavior is due to the fact that the agp_release_helper() function > > > doesn't free the memory associated to each block and this is incoherent > > > with what it says it does: > > > > > > /* > > >* Clear out the aperture and free any > > >* outstanding memory blocks. > > >*/ > > >... > > > > > > So the diff below correct this by freeing all the memory block when > > > releasing the interface, this is what happens currently if you close > > > the file descriptor without releasing the interface. > > > > I;m not sure this is right. I think the idea here is that an > > application could release control to hand things over to drm, and > > later reacquire control. The comment in > > xenocara/xserver/hw/xfree86/os-support/bsd/bsd_agp.c:xf86ReleaseGART() > > suggests that this behaviour is desired. > > Fair enough, so here's a diff that removes the chunk of code unbinding > the memory block from the release routine. This makes the code match > what the manual says. > > Ok? Hmm, I think it currently pretty much a bug if a process calls AGPIOC_RELEASE while it still has stuff bound to the aperture as we don't restore the bindings when we resume. So I think we should keep the printf's and perhaps keep unbinding the memory as well. I'm not sure how much damage stale mappings can do during a suspend/resume cycle. It seems that the xf86-video-intel driver is the only userland code that actually uses /dev/agp (through the xserver interfaces). And because of the "FreeBSD hack" I mentioned in my previous mail, I don't think it actually ever invokes the AGPIOC_RELEASE ioctl after it starts using the GART. It's a great bloody mess :(. But fortunately that usage goes away as soon as we implement KMS. > Index: agp.c > === > RCS file: /cvs/src/sys/dev/pci/agp.c,v > retrieving revision 1.34 > diff -u -p -r1.34 agp.c > --- agp.c 26 Dec 2010 15:41:00 - 1.34 > +++ agp.c 13 Nov 2012 13:41:43 - > @@ -658,25 +678,13 @@ int > agp_release_helper(void *dev, enum agp_acquire_state state) > { > struct agp_softc *sc = (struct agp_softc *)dev; > - struct agp_memory* mem; > > if (sc->sc_state == AGP_ACQUIRE_FREE) > return (0); > > - if (sc->sc_state != state) > + if (sc->sc_state != state) > return (EBUSY); > > - /* > - * Clear out the aperture and free any > - * outstanding memory blocks. > - */ > - TAILQ_FOREACH(mem, &sc->sc_memory, am_link) { > - if (mem->am_is_bound) { > - printf("agp_release_helper: mem %d is bound\n", > - mem->am_id); > - agp_unbind_memory(sc, mem); > - } > - } > sc->sc_state = AGP_ACQUIRE_FREE; > return (0); > }
Re: agp(4): release unbinded memory
On 13/11/12(Tue) 13:45, Mark Kettenis wrote: > > Date: Tue, 13 Nov 2012 12:30:29 +0100 > > From: Martin Pieuchot > > > > While experimenting with the agp(4) interface I found that if you > > release the interface (AGPIOC_RELEASE) before closing its file > > descriptor you'll end up with allocated but unbinded memory blocks. > > That behaviour is documented in agp(4). So if we change it, we should > change the documentation as well. That said, the documentation also > says that the AGPIOC_RELEASE ioctl doesn't unbind any allocated > memory. And that doesn't seem to be true. > > > This behavior is due to the fact that the agp_release_helper() function > > doesn't free the memory associated to each block and this is incoherent > > with what it says it does: > > > > /* > > * Clear out the aperture and free any > > * outstanding memory blocks. > > */ > > ... > > > > So the diff below correct this by freeing all the memory block when > > releasing the interface, this is what happens currently if you close > > the file descriptor without releasing the interface. > > I;m not sure this is right. I think the idea here is that an > application could release control to hand things over to drm, and > later reacquire control. The comment in > xenocara/xserver/hw/xfree86/os-support/bsd/bsd_agp.c:xf86ReleaseGART() > suggests that this behaviour is desired. Fair enough, so here's a diff that removes the chunk of code unbinding the memory block from the release routine. This makes the code match what the manual says. Ok? Index: agp.c === RCS file: /cvs/src/sys/dev/pci/agp.c,v retrieving revision 1.34 diff -u -p -r1.34 agp.c --- agp.c 26 Dec 2010 15:41:00 - 1.34 +++ agp.c 13 Nov 2012 13:41:43 - @@ -658,25 +678,13 @@ int agp_release_helper(void *dev, enum agp_acquire_state state) { struct agp_softc *sc = (struct agp_softc *)dev; - struct agp_memory* mem; if (sc->sc_state == AGP_ACQUIRE_FREE) return (0); - if (sc->sc_state != state) + if (sc->sc_state != state) return (EBUSY); - /* -* Clear out the aperture and free any -* outstanding memory blocks. -*/ - TAILQ_FOREACH(mem, &sc->sc_memory, am_link) { - if (mem->am_is_bound) { - printf("agp_release_helper: mem %d is bound\n", - mem->am_id); - agp_unbind_memory(sc, mem); - } - } sc->sc_state = AGP_ACQUIRE_FREE; return (0); }
Re: Make cron supply valid RFC822 From: and To: headers
On Tue, Nov 13, 2012 at 03:14:06PM +0100, Alexander Hall wrote: > On 11/13/12 13:49, Christian Weisgerber wrote: > >Alexander Hall wrote: > > > >>Since I switched to SMTPD I noticed a few cron emails being marked as > >>spam by spamassassin, largely caused by the From: and To: headers not > >>containing a domain part. > >> > >>If I read RFC822 correctly, the domain part is not optional, and thus > >>we should append one, unless MAILTO already specifies one. > > > >This looks like a problem in smtpd. Sendmail and compatible MTAs > >have always fully qualified any incomplete addresses. > > Ok, no matter how we parse the rfc's, since old sendmail and friends > rewrites those headers, I guess it's already a de-facto standard, in > practice forcing us to make smtpd do it too. > > In the meantime, would the diff hurt anyone? Or is it just a lousy > workaround? > > /Alexander I believe sendmail has options to add a specific domain to unqualified names. I think you want the sendmail (like) mechanism here, not a specific one for cron only. -Otto
Re: Make cron supply valid RFC822 From: and To: headers
> Date: Tue, 13 Nov 2012 15:14:06 +0100 > From: Alexander Hall > > On 11/13/12 13:49, Christian Weisgerber wrote: > > Alexander Hall wrote: > > > >> Since I switched to SMTPD I noticed a few cron emails being marked as > >> spam by spamassassin, largely caused by the From: and To: headers not > >> containing a domain part. > >> > >> If I read RFC822 correctly, the domain part is not optional, and thus > >> we should append one, unless MAILTO already specifies one. > > > > This looks like a problem in smtpd. Sendmail and compatible MTAs > > have always fully qualified any incomplete addresses. > > Ok, no matter how we parse the rfc's, since old sendmail and friends > rewrites those headers, I guess it's already a de-facto standard, in > practice forcing us to make smtpd do it too. > > In the meantime, would the diff hurt anyone? Or is it just a lousy > workaround? It's just a lousy workaround ;).
Re: Make cron supply valid RFC822 From: and To: headers
On 11/13/12 13:49, Christian Weisgerber wrote: Alexander Hall wrote: Since I switched to SMTPD I noticed a few cron emails being marked as spam by spamassassin, largely caused by the From: and To: headers not containing a domain part. If I read RFC822 correctly, the domain part is not optional, and thus we should append one, unless MAILTO already specifies one. This looks like a problem in smtpd. Sendmail and compatible MTAs have always fully qualified any incomplete addresses. Ok, no matter how we parse the rfc's, since old sendmail and friends rewrites those headers, I guess it's already a de-facto standard, in practice forcing us to make smtpd do it too. In the meantime, would the diff hurt anyone? Or is it just a lousy workaround? /Alexander
Re: Make cron supply valid RFC822 From: and To: headers
Alexander Hall wrote: > Since I switched to SMTPD I noticed a few cron emails being marked as > spam by spamassassin, largely caused by the From: and To: headers not > containing a domain part. > > If I read RFC822 correctly, the domain part is not optional, and thus > we should append one, unless MAILTO already specifies one. This looks like a problem in smtpd. Sendmail and compatible MTAs have always fully qualified any incomplete addresses. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: agp(4): release unbinded memory
> Date: Tue, 13 Nov 2012 12:30:29 +0100 > From: Martin Pieuchot > > While experimenting with the agp(4) interface I found that if you > release the interface (AGPIOC_RELEASE) before closing its file > descriptor you'll end up with allocated but unbinded memory blocks. That behaviour is documented in agp(4). So if we change it, we should change the documentation as well. That said, the documentation also says that the AGPIOC_RELEASE ioctl doesn't unbind any allocated memory. And that doesn't seem to be true. > This behavior is due to the fact that the agp_release_helper() function > doesn't free the memory associated to each block and this is incoherent > with what it says it does: > > /* >* Clear out the aperture and free any >* outstanding memory blocks. >*/ >... > > So the diff below correct this by freeing all the memory block when > releasing the interface, this is what happens currently if you close > the file descriptor without releasing the interface. I;m not sure this is right. I think the idea here is that an application could release control to hand things over to drm, and later reacquire control. The comment in xenocara/xserver/hw/xfree86/os-support/bsd/bsd_agp.c:xf86ReleaseGART() suggests that this behaviour is desired.
agp(4): release unbinded memory
While experimenting with the agp(4) interface I found that if you release the interface (AGPIOC_RELEASE) before closing its file descriptor you'll end up with allocated but unbinded memory blocks. This behavior is due to the fact that the agp_release_helper() function doesn't free the memory associated to each block and this is incoherent with what it says it does: /* * Clear out the aperture and free any * outstanding memory blocks. */ ... So the diff below correct this by freeing all the memory block when releasing the interface, this is what happens currently if you close the file descriptor without releasing the interface. However it doesn't change the behavior of the interface that looks busted to me because we don't keep track of who allocated some memory block and end up unbindind and freeing everything. Ok? Index: agp.c === RCS file: /cvs/src/sys/dev/pci/agp.c,v retrieving revision 1.34 diff -u -p -r1.34 agp.c --- agp.c 26 Dec 2010 15:41:00 - 1.34 +++ agp.c 12 Nov 2012 18:20:48 - @@ -290,20 +310,13 @@ int agpclose(dev_t dev, int flags, int devtype, struct proc *p) { struct agp_softc *sc = agp_find_device(AGPUNIT(dev)); - struct agp_memory *mem; /* * Clear the GATT and force release on last close */ - if (sc->sc_state == AGP_ACQUIRE_USER) { - while ((mem = TAILQ_FIRST(&sc->sc_memory)) != 0) { - if (mem->am_is_bound) { - agp_unbind_memory(sc, mem); - } - agp_free_memory(sc, mem); - } + if (sc->sc_state == AGP_ACQUIRE_USER) agp_release_helper(sc, AGP_ACQUIRE_USER); - } + sc->sc_opened = 0; return (0); @@ -658,25 +671,26 @@ int agp_release_helper(void *dev, enum agp_acquire_state state) { struct agp_softc *sc = (struct agp_softc *)dev; - struct agp_memory* mem; + struct agp_memory *mem, *tmp; if (sc->sc_state == AGP_ACQUIRE_FREE) return (0); - if (sc->sc_state != state) + if (sc->sc_state != state) return (EBUSY); /* * Clear out the aperture and free any * outstanding memory blocks. */ - TAILQ_FOREACH(mem, &sc->sc_memory, am_link) { + TAILQ_FOREACH_SAFE(mem, &sc->sc_memory, am_link, tmp) { if (mem->am_is_bound) { - printf("agp_release_helper: mem %d is bound\n", - mem->am_id); + AGP_DPF("mem %d is bound\n", mem->am_id); agp_unbind_memory(sc, mem); } + agp_free_memory(sc, mem); } + sc->sc_state = AGP_ACQUIRE_FREE; return (0); }
Re: agp(4): agpmmap fix
> Date: Tue, 13 Nov 2012 11:55:07 +0100 > From: Martin Pieuchot > > After loosing some hairs trying to figure out where I screw up in > mmaping the AGP aperture, here's a trivial fix. > > Diff below corrects the first argument of the agpmmap() function that > should be a dev_t and not a pointer to the driver's descriptor. ok kettenis@ if you fix the spaces vs. tab issue. > Index: agp.c > === > RCS file: /cvs/src/sys/dev/pci/agp.c,v > retrieving revision 1.34 > diff -u -p -r1.34 agp.c > --- agp.c 26 Dec 2010 15:41:00 - 1.34 > +++ agp.c 12 Nov 2012 18:20:48 - > @@ -60,7 +60,7 @@ int agp_generic_free_memory(struct agp_s > void agp_attach(struct device *, struct device *, void *); > int agp_probe(struct device *, void *, void *); > int agpbusprint(void *, const char *); > -paddr_t agpmmap(void *, off_t, int); > +paddr_t agpmmap(dev_t, off_t, int); > int agpioctl(dev_t, u_long, caddr_t, int, struct proc *); > int agpopen(dev_t, int, int, struct proc *); > int agpclose(dev_t, int, int , struct proc *); > @@ -206,9 +206,12 @@ struct cfdriver agp_cd = { > }; > > paddr_t > -agpmmap(void *v, off_t off, int prot) > +agpmmap(dev_t dev, off_t off, int prot) > { > - struct agp_softc* sc = (struct agp_softc *)v; > + struct agp_softc *sc = agp_find_device(AGPUNIT(dev)); > + > +if (sc == NULL || sc->sc_chipc == NULL) > +return (-1); > > if (sc->sc_apaddr) {
agp(4): agpmmap fix
After loosing some hairs trying to figure out where I screw up in mmaping the AGP aperture, here's a trivial fix. Diff below corrects the first argument of the agpmmap() function that should be a dev_t and not a pointer to the driver's descriptor. Ok? Index: agp.c === RCS file: /cvs/src/sys/dev/pci/agp.c,v retrieving revision 1.34 diff -u -p -r1.34 agp.c --- agp.c 26 Dec 2010 15:41:00 - 1.34 +++ agp.c 12 Nov 2012 18:20:48 - @@ -60,7 +60,7 @@ int agp_generic_free_memory(struct agp_s void agp_attach(struct device *, struct device *, void *); intagp_probe(struct device *, void *, void *); intagpbusprint(void *, const char *); -paddr_tagpmmap(void *, off_t, int); +paddr_tagpmmap(dev_t, off_t, int); intagpioctl(dev_t, u_long, caddr_t, int, struct proc *); intagpopen(dev_t, int, int, struct proc *); intagpclose(dev_t, int, int , struct proc *); @@ -206,9 +206,12 @@ struct cfdriver agp_cd = { }; paddr_t -agpmmap(void *v, off_t off, int prot) +agpmmap(dev_t dev, off_t off, int prot) { - struct agp_softc* sc = (struct agp_softc *)v; + struct agp_softc *sc = agp_find_device(AGPUNIT(dev)); + +if (sc == NULL || sc->sc_chipc == NULL) +return (-1); if (sc->sc_apaddr) {
Make cron supply valid RFC822 From: and To: headers
Since I switched to SMTPD I noticed a few cron emails being marked as spam by spamassassin, largely caused by the From: and To: headers not containing a domain part. If I read RFC822 correctly, the domain part is not optional, and thus we should append one, unless MAILTO already specifies one. Historical reasons from the land of pre-smtp why I'm wrong? Comments? OK's? /Alexander (Indentation style sucks balls in there. I kept it up.) Index: do_command.c === RCS file: /data/openbsd/cvs/src/usr.sbin/cron/do_command.c,v retrieving revision 1.36 diff -u -p -r1.36 do_command.c --- do_command.c22 Aug 2011 19:32:42 - 1.36 +++ do_command.c13 Nov 2012 09:48:53 - @@ -412,8 +412,13 @@ child_process(entry *e, user *u) { perror(mailcmd); (void) _exit(EXIT_FAILURE); } - fprintf(mail, "From: root (Cron Daemon)\n"); - fprintf(mail, "To: %s\n", mailto); + fprintf(mail, "From: root@%s (Cron Daemon)\n", + hostname); + if (strchr(mailto, '@') == NULL) + fprintf(mail, "To: %s@%s\n", mailto, + hostname); + else + fprintf(mail, "To: %s\n", mailto); fprintf(mail, "Subject: Cron <%s@%s> %s\n", usernm, first_word(hostname, "."), e->cmd);
tree(3) inconsistencies
Hi tech@, I noticed RB_GENERATE_INTERNAL in src/sys/sys/tree.h puts brackets around the compare function cmp in RB_INSERT just like SPLAY_GENERATE_INTERNAL does. However, RB_FIND and RB_NFIND don't do this. Is there any reason we need (cmp) expressions at all? It prevents macros from being used in those places, which may speed up the generated implementations. Or would it be better to fix the code in RB_FIND and RB_NFIND? I've also thought about marking read-only elements const in *_FIND and similar functions. I've hit a warning in my code about stripping const off of the type there. Maybe that's paranoid, but I don't see a negative side effect. On a related note, the EXAMPLES section in src/share/man/man3/tree.3 is missing a semicolon at the end of RB_GENERATE. I can prepare a diff, but I wanted to ask first. Thanks, Franco