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 a

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 N

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

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 runn

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.1

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 (AGP

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

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 > >>con

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 >

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 optiona

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, unle

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 documente

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 assoc

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

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 ===

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. Hi

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