Radeon HD 4850 and drmRadeonCmdBuffer: -22.
Misc,
After patching pcidevs (included below) I was able to get the kernel to
recognize a Radeon HD 4850, however, attempts to run something that uses
GL result in the following errors:
$ xlock -nolock -mode random -modelist allgl
drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See
dmesg for more info.
>From dmesg:
error: [drm:pid20952:r300_emit_carefully_checked_packet0] *ERROR* Register 4e4c
failed check as flag=00
error: [drm:pid20952:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
I found a question about a similar card here:
http://marc.info/?l=openbsd-misc&m=129338059513546&w=2
The links seemed to indicate that there were some changes made to both
Linux and FreeBSD, and it would appear that those changes have already
been made to OpenBSD as well. Is there something else that I might be
missing? The card works fine, just no acceleration.
Also, I tried without RADEON_IS_MOBILITY (this isn't a laptop, but maybe
it actually uses the same code), but without it, the system locks up
hard and is completely unresponsive with dead video signal.
Is it going to be possible to get acceleration working with this? If so,
any pointers?
Here is a complete dmesg:
OpenBSD 4.8-stable (GENERIC.MP) #5: Wed Feb 23 23:42:51 MST 2011
r...@angmar.bradfordfamily.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz ("GenuineIntel" 686-class)
3.01 GHz
cpu0:
FPU,V86,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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
real mem = 3756552192 (3582MB)
avail mem = 3685130240 (3514MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/18/09, BIOS32 rev. 0 @ 0xfb990, SMBIOS
rev. 2.4 @ 0xf (72 entries)
bios0: vendor Phoenix Technologies, LTD version "ASUS P5N-E SLI ACPI BIOS
Revision 1406" date 11/18/2009
bios0: ASUSTeK Computer INC. P5N-E SLI
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP MCFG APIC SSDT
acpi0: wakeup devices HUB0(S5) XVRA(S5) XVRB(S5) XVRC(S5) XVRD(S5) UAR1(S5)
PS2M(S4) PS2K(S4) USB0(S4) USB2(S4) AZAD(S5) MMAC(S5) MMCI(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 333MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz ("GenuineIntel" 686-class)
3.01 GHz
cpu1:
FPU,V86,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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 4
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (HUB0)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpitz0 at acpi0: critical temperature 75 degC
acpibtn0 at acpi0: PWRB
aibs0 at acpi0
aibs0: FSIF: misformed package: 3/5, assume 5
bios0: ROM list: 0xc/0xfa00 0xd/0x8000! 0xd8000/0x2000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "NVIDIA C55 Host" rev 0xa2
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 0 function 1 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 0 function 2 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 0 function 3 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 0 function 4 not configured
"NVIDIA C55 Memory" rev 0xa2 at pci0 dev 0 function 5 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 0 function 6 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 0 function 7 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 1 function 0 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 1 function 1 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 1 function 2 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 1 function 3 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 1 function 4 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 1 function 5 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 1 function 6 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 2 function 0 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 2 function 1 not configured
"NVIDIA C55 Memory" rev 0xa1 at pci0 dev 2 function 2 not configured
ppb0 at pci0 dev 3 function 0 "NVIDIA C55 PCIE" rev 0xa1
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Mobility Radeon HD 4850" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 4 int 16 (irq 11)
drm0 at radeondrm0
azalia0 at pci1 dev 0 function 1 "ATI Radeon HD 48xx HD Audio" rev 0x00: apic 4
int 16 (irq 11)
azalia0: no supported codecs
azalia0: initialization failure, detaching
ppb1 at pci0 dev 7 function 0 "NVIDIA C55 PCIE" rev 0xa1
pci2 at ppb1 bus 2
jmb0 at pci2 dev 0 function 0 "JMicron JMB360
www.TopWebsites.vn
TrC"n trá»ng kCnh chC o quC= khC!ch vC thC nh tháºt xin lá»i nếu email nC y lC m phiá»n quC= khC!ch. ChC:ng tC4i xin Äược giá»i thiá»u Äến quC= khC!ch website www.topwebsites.vn , má»t website vC4 cC9ng hữu dụng cho viá»c lÆ°á»t net của quC= khC!ch. * Danh sC!ch của những trang web hC ng Äầu Viá»t Nam, HC ng Äầu Thế Giá»i Äược xếp hạng bá»i Google vC Alexa. * Danh sC!ch của những trang web Äược xếp hạng tá»t nhất, Äược xếp hạng bá»i Time, About.com, bestwebsites.org * Danh bạ 5000 web hC ng Äầu Viá»t Nam, theo thứ hạng truy cáºp vC theo lC#nh vá»±c. * CC4ng cụ tC,m kiếm websites hiá»u quả. TrC"n trá»ng cC!m Æ¡n vC chC:c quC= khC!ch lÆ°á»t net vui. Ban Quản Trá» www.TopWebsites.vn lie...@topwebsites.vn
Re: Minimally painful mail client for "rich" (spit!) messages
On Feb 09 17:56:59, Ingo Schwarze wrote: > text/html; /usr/bin/lynx -stdin -force_html -dump ; copiousoutput On Feb 09 10:59:54, Marco Peereboom wrote: > text/html; /usr/local/bin/links -dump '%s'; copiousoutput; description=HTML > Text; na metemplate=%s.html On Feb 09 23:12:27, Igor Zinovik wrote: > text/html ; lynx -force_html -assume_charset=koi8-r > -assume_unrec_charset=utf8 -dump %s ; copiousoutput; nametemplate=%s.html I have been using (variations of) these for years in my ~/.mailcap, which made mutt(1) launch lynx(1) on the html attachments. Since I upgraded to OpenBSD 4.8-current (GENERIC) #448: Fri Oct 22 09:43:05 MDT 2010 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC with mutt-1.5.21p0, it no longer works. (Should I take this to ports?) Trying to view a HTML attachment from the attachment menu results in the attachment being displayed by mutt's internal viewer. I stripped my ~/.mailcap to the minimum suggested by http://www.mutt.org/doc/manual/manual-5.html#ss5.3 text/html; lynx %s ; nametemplate=%s.html and even that does not work. It seems like my ~/.mailcap is ignored. (Copying to /etc/mailcap doesn't seem to make any difference.) Does anyone have a hint of what could be causing this? Thank you for your time. Jan
Re: OT: Risks of CAs (Re: Your web development opinions)
I think your guys are into elaborate schemes and totally forgetting low-level tech/social engineering attack. Remember that most people out there don't understand https, they will just see that little lock and think "I'm secure"... yeah, sure, from 3rd party. But it's so easy to set up a fake site, get some valid credentials from any CA that accepts it for money, and lure people in. Between OpenID, facebook, and heck, the fact that most people reuse the same password, you can harvest a lot of valid accounts on a lot of sites. And then the real fun begins.
Articoli della rubrica CRONACA ITALIA
[IMAGE] Se non sei ancora iscritto alla Newsletter di NanniMagazine clicca QUI < /TR> Facebook: Facebook Diventa Fan RSS: d Sottoscrivi gli RSS Newsletter Nr. 16 del 22 Febbraio 2011 Le altre rubriche: Cronaca Italia Carcere Giustizia e criminalita' Immigrazione Sicurezza [IMAGE] NanniMagazine h un periodico di informazione giornalistica di inchiesta che ha come obiettivo lapprofondimento della realt`, per quanto possibile, prendendo spunto dallattualit` e offrendo maggiori particolari rispetto a quelli citati da quotidiani, agenzie, blog, etc. Partendo da un fatto, la redazione, lo analizza, lo approfondisce e fornisce, a corredo, elementi descrittivi che tendono a completare il quadro di riferimento in cui il fatto h accaduto. La struttura editoriale h una realt` molto piccola che vive con pochi mezzi ma con molta passione, umilt` e un enorme impegno dei suoi collaboratori. GLI ULTIMI ARTICOLI PUBBLICATI NELLA RUBRICA: Italia [IMAGE] Carcere allo sbando: per il Lazio "h emergenza umanitaria" "Lavorare in carcere h sempre piy simile all'espiazione di una pena". La pesante denuncia arriva dalla Fp Cgil di Roma e Lazio, che nei giorni scorsi ha diffuso un dossier sulla drammatica situazione delle carceri laziali,... [IMAGE] Milleproroghe: tempi duri per i minorenni alla guida Arriva il foglio rosa per motorini e minicar. La novit` h contenuta nel decreto Milleproroghe che ha ricevuto il disco verde del Senato e che ora passa alla Camera per l'approvazione definitiva. PER GUIDARE MOTORINI E MINCAR NON BASTA... [IMAGE] Milleproroghe, scuole e docenti al vaglio degli ispettori Dalle graduatorie dei docenti precari alle ispezioni per valutare istituti e professori. Nelle maglie del decreto Milleproroghe, appena approvato al Senato, ci sono novit` che riguardano il mondo della scuola. Se il maxi-emendamento... [IMAGE] Manipolatori della mente: centinaia le vittime delle sette, in aumento i giovani La perversa fascinazione esercitata dalle sette continua ad intrappolare in Italia centinaia di persone ogni anno. Solo nel 2010 sono state 240mila le vittime, per la maggior parte uomini, adulti e appartenenti al ceto medio. Gli ultimi dati del... [IMAGE] Rom: dall'Ue la ricetta per l'inclusione Discriminazione sistematica, un livello intollerabile di esclusione e violazioni dei diritti umani. Con queste motivazioni la questione rom h arrivata in sede europea, dove nei giorni scorsi h stata adottata dalla commissione... [IMAGE] Fecondazione assistita: nel Milleproroghe spunta una misura a sorpresa ed h polemica Il Governo ficca il naso nella vita delle coppie sterili? Oppure la misura introdotta nel decreto Milleproroghe h, come la definisce il responsabile del Dicastero della Sanit`, Ferruccio Fazio, "un atto dovuto"? La legge 40,... [IMAGE] Universit`: la Gelmini e il 'carro attrezzi' contro i 'parcheggiati' Sono un esercito che nel 2010 ha sfiorato le 600mila unit`, in pratica un terzo della popolazione studentesca che raggiunge quota 1,7 milioni. Li chiamano ritardatari, indecisi, sfortunati. Per lo piy sono 'parcheggiati'... [IMAGE] Consulta, graduatorie prof precari: vince il merito H dall'anno scorso, ormai, che Maria Stella Gelmini non conosce periodi di tranquillit`. Sempre alle prese con problemi da risolvere e ostacoli da superare. Non bastavano gli atenei in rivolta contro la sua riforma e i ricercatori sul... [IMAGE] Rom: servizi sociali lontani da bambini e famiglie Le tragedie sono figlie di disorganizzazione e inadempienze. Le ultime drammatiche morti avvenute nel rogo di una baracca abitata da rom, a Roma, ripropongono problemi mai risolti sul capitolo nomadi. A cercare di sondarli ci ha provato una ricerca,... [IMAGE] Emergenza immigrati: Maroni se la prende con l'Ue Sono ore frenetiche per il governo e in particolare per Roberto Maroni, da una settimana circa alle prese con l'emergenza clandestini nordafricani. "I un esodo biblico come non se ne sono mai visti": sono queste le parole che ha... [IMAGE] Testamento biologico: la legge ai nastri di partenza alla Camera Sono passati due anni dalla morte di Eluana Englaro e in questi 24 mesi, scattati il 9 febbraio scorso, su un tema sensibile come quello del testamento biologico non sono stati fatti passi in avanti. Le polemiche che accompagnarono le ultime ore di... [IMAGE] Quell'arretrato che affligge anche la giustizia amministrativa Non c'h da innalzare i calici, ma neanche da strapparsi le vesti. In un Paese come l'Italia, alle prese con una macchina giudiziaria perennemente inceppata, il bilancio sostanzialmente 'positivo' della giustizia amministrativa per l'anno... Se ti piace questo progetto, se hai qualcosa da dire o da condividere puoi: inviare un articolo, uno studio, una ricerca Gli scritti possono essere gi` pubblicati oppure originali. Lo scritto va inviato, in formato word o rft, come allegato di posta elettronica all'indirizzo c...@nannieditore.it segnalare un evento NanniMagazine.it pu
Re: Minimally painful mail client for "rich" (spit!) messages
On Thu, Feb 24, 2011 at 10:11:22AM +0100, Jan Stary wrote:
> On Feb 09 17:56:59, Ingo Schwarze wrote:
> > text/html; /usr/bin/lynx -stdin -force_html -dump ; copiousoutput
>
> On Feb 09 10:59:54, Marco Peereboom wrote:
> > text/html; /usr/local/bin/links -dump '%s'; copiousoutput; description=HTML
> > Text; na metemplate=%s.html
>
> On Feb 09 23:12:27, Igor Zinovik wrote:
> > text/html ; lynx -force_html -assume_charset=koi8-r
> > -assume_unrec_charset=utf8 -dump %s ; copiousoutput; nametemplate=%s.html
> I have been using (variations of) these for years in my ~/.mailcap,
> which made mutt(1) launch lynx(1) on the html attachments. Since
> I upgraded to
>
> OpenBSD 4.8-current (GENERIC) #448: Fri Oct 22 09:43:05 MDT 2010
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
>
> with mutt-1.5.21p0, it no longer works.
> (Should I take this to ports?)
>
> Trying to view a HTML attachment from the attachment menu
> results in the attachment being displayed by mutt's internal
> viewer. I stripped my ~/.mailcap to the minimum suggested by
> http://www.mutt.org/doc/manual/manual-5.html#ss5.3
>
> text/html; lynx %s ; nametemplate=%s.html
>
> and even that does not work. It seems like my ~/.mailcap is ignored.
> (Copying to /etc/mailcap doesn't seem to make any difference.)
>
> Does anyone have a hint of what could be causing this?
text/html is usually in Mutt's auto_view list; auto_view stuff is
automatically piped through any viewer with "copiousoutput" set, whereas
non-"copiousoutput" entries are only used if you explicitly open it ('v'
-> select item -> 'm').
E.g. from my mailcap:
# Process HTML with firefox or w3m
text/html; firefox -a firefox -remote 'openurl(%s)' ; test=[ ! -z "$DISPLAY" ]
&& pgrep -xu `id -u` firefox-bin
text/html; firefox %s ; test=[ ! -z "$DISPLAY" ]
text/html; w3m %s ; nametemplate=%s.html
text/html; w3m -dump %s ; copiousoutput ; nametemplate=%s.html
When viewing HTML mail, it uses w3m -dump (auto_view, copiousoutput).
When opening ('m') HTML stuff, it uses:
* a running Firefox, if mutt is running under X and a running Firefox
is available;
* otherwise, a new Firefox, if mutt is running under X;
* otherwise, w3m.
Joachim
--
TFMotD: mkdep (1) - construct Makefile dependency list
http://www.joachimschipper.nl/
Re: Minimally painful mail client for "rich" (spit!) messages
On Thu, Feb 24, 2011 at 10:57:26AM +0100, Joachim Schipper wrote:
| > and even that does not work. It seems like my ~/.mailcap is ignored.
| > (Copying to /etc/mailcap doesn't seem to make any difference.)
| >
| > Does anyone have a hint of what could be causing this?
|
| text/html is usually in Mutt's auto_view list; auto_view stuff is
| automatically piped through any viewer with "copiousoutput" set, whereas
| non-"copiousoutput" entries are only used if you explicitly open it ('v'
| -> select item -> 'm').
See option implicit_autoview in muttrc(5). I personally prefer to
have "set implicit_autoview=no".
Paul 'WEiRD' de Weerd
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: network bandwith with em(4)
Le Wed, 23 Feb 2011 22:09:18 +0100, Manuel Guesdon a icrit : > >| Did you try to increase the number of descriptor? > >| #define EM_MAX_TXD 256 > >| #define EM_MAX_RXD 256 > >| > >| I've tried up to 2048 (and with MAX_INTS_PER_SEC = 16000) but it > >looks | worth. > > Thank you ! I'll investigate this ! As I said it is worth here. The load is increaded and I lose around 50 Mbits of bandwith. I was curious if you've made some tests on this.
pf rdr-to outgoing to local port issues
Hello, it's probably PEBKAC but I'm lost where is the problem. I try to redirect specific outgoing traffic to a local port, it doesn't work if 'set skip on lo' is used. I'm using i386 snapshot from Feb 11. Any idea? Thank you. jirib ** pf rules: set skip on lo pass# to establish keep-state pass out log(matches) quick inet proto tcp from any to 89.176.141.250 port = www rdr-to 127.0.0.1 port 8080 block in log on ! lo0 proto tcp to port 6000:6010 ** pfctl -vv -sr: @0 pass all flags S/SA keep state [ Evaluations: 1353 Packets: 16Bytes: 448 States: 1 ] [ Inserted: uid 0 pid 4256 State Creations: 8 ] @1 pass out log (matches) quick inet proto tcp from any to 89.176.141.250 port = www flags S/SA keep state rdr-to 127.0.0.1 port 8080 [ Evaluations: 1353 Packets: 5 Bytes: 320 States: 0 ] [ Inserted: uid 0 pid 4256 State Creations: 2 ] @2 block drop in log on ! lo0 proto tcp from any to any port 6000:6010 [ Evaluations: 1343 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 4256 State Creations: 0 ] ** tcpdump on pflog0: Feb 24 12:15:48.04 rule 1/(match) [uid 0, pid 4256] pass out on iwn0: [orig src 192.168.254.100:40695, dst 89.176.141.250:80] 192.168.254.100.40695 > 127.0.0.1.8080: S 3088363469:3088363469(0) win 16384 (DF) [tos 0x10] (ttl 64, id 50505, len 64, bad cksum 68bd! differs by ce92) ** tcpdump on lo0: 12:15:48.042235 192.168.254.100.40695 > 127.0.0.1.8080: S 3088363469:3088363469(0) win 16384 (DF) [tos 0x10] 12:15:48.042246 127.0.0.1.8080 > 192.168.254.100.40695: S 26525521:26525521(0) ack 3088363470 win 16384 (DF) 12:15:48.042252 192.168.254.100.40695 > 127.0.0.1.8080: R 3088363470:3088363470(0) win 0 (DF)
DVDs Didáticos de Língua Gestual, Primeiros Socorros (Infantis) e outros...
DVDs DidC!cticos www.cuidardobebe.com www.socorroinfantil.com www.linguagestual.com www.curso1socorros.com www.origamicurso.com InformaC'C5es gerais Se recebeu por engano ou deseja deixar de receber as newsletters de cursos da ValorVisual, Lda. envie-nos um email para ge...@valorvisual.pt, (do email que deseja que seja removido) com a palavra "remover" no assunto. Obrigado.
Re: OT: Risks of CAs (Re: Your web development opinions)
On Thu, 24 Feb 2011 10:16:36 +0100 Marc Espie wrote: > the fact that most people reuse the same password, You hear about that now said to be non existent security firm that was helping the fbi track down a support group of wkileaks called anonymous and ended up with all their email on wikileaks because the security firms bosses use the same pass on their email as found on their web CMS. "http://www.h-online.com/security/news/item/More-background-on-the-US-security-firm-break-in-1191797.html"; That made me chuckle. Atleast thanks to wikileaks, the fbi have had it drummed into them that data was insecure for crying out loud, they should stop pointing the finger outbound and get their house in order. Also sometimes seeing reactions to information without knowing why leads to horrible assumptions and reactions instead of the response "well I don't agree but I see why you did that." and "well that was obviously a corrupt individual or group" Sorry for changing the subject. >>I don't like having to trust dozens of CA and it's definitely not the best >>solution, but I don't see any alternative for this sort of thing. DNScurve/DNSSEC have been suggested, but how secure is the DNS infrastructure? I hate paying for ssl certs, just to get rid of the warnings.
Re: OT: Risks of CAs (Re: Your web development opinions)
I am going to point out another factor in my reasoning: Basically, there is no reason to assume that my self-signed certificate is any less secure than paying someone who is in a browsers root certificates. As a contractor in construction, one article I wrote for my potential customers is how to decide if you should do the work yourself `or hire someone else to do it. In this case, if I hire someone as a CA, I have just spent money. That comes straight out of my wages. I have to now earn this money back or not eat, pay rent, etc. If I self-sign, I now get to keep that money. In fact, I may now be able to spend additional time improving security on my websites and my programming. I could potentially end up improving users security by NOT having to earn back spent money. It is not my fault if some users are stupid. I actually spent some time making security details available to my users. If they care, they are now educated, if not, what can you do? Chris Bennett
Re: OT: Risks of CAs (Re: Your web development opinions)
On 02/24/2011 11:59 AM, Chris Bennett wrote: > I am going to point out another factor in my reasoning: > Basically, there is no reason to assume that my self-signed certificate is > any less secure than paying someone who is in a browsers root certificates. > > As a contractor in construction, one article I wrote for my potential > customers is how to decide if you should do the work yourself `or hire > someone else to do it. > > In this case, if I hire someone as a CA, I have just spent money. That comes > straight out of my wages. I have to now earn this money back or not eat, pay > rent, etc. > If I self-sign, I now get to keep that money. In fact, I may now be able to > spend additional time improving security on my websites and my programming. I > could potentially end up improving users security by NOT having to earn back > spent money. http://www.startssl.com/ Why pay if you can have one for free trusted by every major browser? Sure, the "class 2" ones are pay-for, but the free one works as well as a self-signed one (except for the "CA sells out like paypal" idea, which I admit is possible, though, in the US, the government can just push any CA to give them a valid cert anyway. > > It is not my fault if some users are stupid. I actually spent some time > making security details available to my users. If they care, they are now > educated, if not, what can you do? Nothing, educating is the only solution, if they don't care, it's their problem. > > Chris Bennett > -- Hugo Osvaldo Barrera
Re: OT: Risks of CAs (Re: Your web development opinions)
> http://www.startssl.com/ > Why pay if you can have one for free trusted by every major browser? > Sure, the "class 2" ones are pay-for, but the free one works as well as > a self-signed one (except for the "CA sells out like paypal" idea, which > I admit is possible, though, in the US, the government can just push any > CA to give them a valid cert anyway. > -- > Hugo Osvaldo Barrera > That's a seemingly good idea except that they don't return any attempt to get a certificate. So I gave up on them a long time ago.
Comixwall
Hello there, Someone use comixwall ? Please contact me Regards,
Re: OT: Risks of CAs (Re: Your web development opinions)
On 02/24/11 17:50, Chris Bennett wrote: >> http://www.startssl.com/ >> Why pay if you can have one for free trusted by every major browser? >> Sure, the "class 2" ones are pay-for, but the free one works as well as >> a self-signed one (except for the "CA sells out like paypal" idea, which >> I admit is possible, though, in the US, the government can just push any >> CA to give them a valid cert anyway. >> -- >> Hugo Osvaldo Barrera >> > > That's a seemingly good idea except that they don't return any attempt to get > a certificate. > So I gave up on them a long time ago. The free certs or the government? :-)
Re: OT: Risks of CAs (Re: Your web development opinions)
On 02/24/2011 01:50 PM, Chris Bennett wrote: >> http://www.startssl.com/ >> Why pay if you can have one for free trusted by every major browser? >> Sure, the "class 2" ones are pay-for, but the free one works as well as >> a self-signed one (except for the "CA sells out like paypal" idea, which >> I admit is possible, though, in the US, the government can just push any >> CA to give them a valid cert anyway. >> -- >> Hugo Osvaldo Barrera >> > > That's a seemingly good idea except that they don't return any attempt to get > a certificate. > So I gave up on them a long time ago. > I use their web interface to generate them. It gets stuck sometime, buy usually works. (Yeah, it's definitely not the best). -- Hugo Osvaldo Barrera
Re: uaudio
Jan Stary wrote: > I am currently using an M-Audio MobilePre (as kindly suggested > by Alexander Ratchov some months ago). It works fine and the > sound is very good. > > Now I consider upgrading to the new version of MobilePre > http://www.m-audio.com/products/en_us/MobilePre.html > which can do 24bit@96kHz (the one I have now does 16bit). > > I wonder what is the current status of 24bit support in uaudio, > or the audio subsystem in general. > > I vaguely remeber the E-mu USB family being mentioned a while ago. > www.emu.com/products/product.asp?category=610&subcategory=611&product=17511 > www.emu.com/products/product.asp?category=610&subcategory=611&product=15186 > www.emu.com/products/product.asp?category=610&subcategory=611&product=20347 > > Is anyone using those successfuly? Jacob? > > Thank you for your time > > Jan I believe this thread is still fairly accurate: http://marc.info/?l=openbsd-misc&m=128075138405615&w=2 Especially 24-bit processing by aucat seems experimental at this time: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/aucat/aparams.h?rev=1.11 I hope this helps.
Fw: Segue em anexo..
[IMAGE] 1 anexo(s) Documento-Relatorio.doc (148,4 KB) Segue em anexo o relatorio. tenha um bom dia.
Re: network bandwith with em(4)
W dniu 2011-02-24 12:11, Patrick Lamaiziere pisze: Le Wed, 23 Feb 2011 22:09:18 +0100, Manuel Guesdon a icrit : | Did you try to increase the number of descriptor? | #define EM_MAX_TXD 256 | #define EM_MAX_RXD 256 | | I've tried up to 2048 (and with MAX_INTS_PER_SEC = 16000) but it looks | worth. Thank you ! I'll investigate this ! As I said it is worth here. The load is increaded and I lose around 50 Mbits of bandwith. I was curious if you've made some tests on this. ok, so the conclusion might be, that if one want to have transfers bigger than 300mbit/s on em(4), one should tuning the em(4) driver source code? best regards, RLW
Re: Radeon HD 4850 and drmRadeonCmdBuffer: -22.
On Thu, Feb 24, 2011 at 3:09 AM, Andy Bradford wrote: > Misc, > > After patching pcidevs (included below) I was able to get the kernel to > recognize a Radeon HD 4850, however, attempts to run something that uses > GL result in the following errors: > > $ xlock -nolock -mode random -modelist allgl > drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info. > > From dmesg: > > error: [drm:pid20952:r300_emit_carefully_checked_packet0] *ERROR* Register 4e4c failed check as flag=00 > error: [drm:pid20952:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed > > I found a question about a similar card here: > > http://marc.info/?l=openbsd-misc&m=129338059513546&w=2 > > The links seemed to indicate that there were some changes made to both > Linux and FreeBSD, and it would appear that those changes have already > been made to OpenBSD as well. Is there something else that I might be > missing? The card works fine, just no acceleration. > > Also, I tried without RADEON_IS_MOBILITY (this isn't a laptop, but maybe > it actually uses the same code), but without it, the system locks up > hard and is completely unresponsive with dead video signal. Without this set, does it lock up every time or just sometimes? I'm experiencing intermittent lockups with my HD4870. It seems to happen more often when I've been in X, leave X, and then go back to X; although this is just a half-assed theory. > > Is it going to be possible to get acceleration working with this? If so, > any pointers? +1 > > Here is a complete dmesg:
BOLETÍN INFORMATIVO Nº 5
This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly.
Re: network bandwith with em(4)
On Wed, Feb 23, 2011 at 06:07:16PM +0100, Patrick Lamaiziere wrote: > I log the congestion counter (each 10s) and there are at max 3 or 4 > congestions per day. I don't think the bottleneck is pf. The congestion counter doesn't directly mean you have a bottleneck in PF; it's triggered by the IP input queue being full, and could indicate a bottleneck in other places as well, which PF tries to help out with by dropping packets earlier. > > Interface errors? > > Quite a lot. The output of `systat mbufs` is worth looking at, in particular the figure for LIVELOCKS, and the LWM/CWM figures for the interface(s) in question. If the livelocks value is very high, and the LWM/CWM numbers are very small, it is likely that the MCLGETI interface is protecting your system from being completly flattened by forcing the em card to drop packets (supported by your statement that the error rate is high). If it's bad enough MCLGETI will be so effective that the pf congestion counter will not get increment. You mentioned the following in your initial email: > #define MAX_INTS_PER_SEC8000 > > Do you think I can increase this value? The interrupt rate of the > machine is at max ~60% (top). Increasing this value will likely hurt you. 60% interrupt rate sounds about right to me for a firewall system that is running at full tilt; 100% interrupt is very bad, if your system spends all cycles servicing interrupts it will not do very much of anything useful. >dmesg: > em0 at pci5 dev 0 function 0 "Intel PRO/1000 QP (82571EB)" rev > 0x06: apic 1 int 13 (irq 14), address 00:15:17:ed:98:9d > > em4 at pci9 dev 0 function 0 "Intel PRO/1000 QP (82575GB)" rev 0x02: > apic 1 int 23 (irq 11), address 00:1b:21:38:e0:80 How about a _full_ dmesg, so someone can take a wild guess at what your machine is capable of? -Ryan
Confirmation d'Inscription : Liste de Diffusion - Zeitgeist
http://www.mailinglist.fr/img2/mails_piedspage/ml_logo.gif"; width="570" height="69" alt="MailingList.fr"> http://www.mailinglist.fr/img2/mails_piedspage/bg_tt_mail.gif);background-repeat:no-repeat;">http://www.mailinglist.fr/img2/fr/titre/tt_ml_confsub.gif"; style="margin-left:10px;" alt="Confirmation de votre abonnement à la liste de diffusion"> Bonjour, bienvenue sur Mailinglist.fr Zeitgeist vous propose de confirmer votre inscription à sa liste de diffusion gérée par le service Mailinglist.fr (afin de se prémunir contre le SPAM). En confirmant votre inscription, vous acceptez également de recevoir ou non les offres privilégiées de Mailinglist et ses partenaires (pas plus de 2 messages par semaine). Vous pourrez vous désinscrire à tout moment grâce à notre lien de désinscription présent en bas de chaque e-mail reçu. Pour confirmer votre inscription à la liste de diffusion, Zeitgeist merci de : [ http://www.mailinglist.fr/?action=confirmemail&sidmel=4d66ecfd07f043.7983975220110225004253"; style="color: #304556;">Cliquez_ici ] ou, copiez/collez le lien ci-dessous dans votre navigateur : http://www.mailinglist.fr/?action=confirmemail&sidmel=4d66ecfd07f043.7983975220110225004253 Le fait de s'inscrire implique que vous avez pris connaissance des CGU http://www.mailinglist.fr/?page=cgu_abonnes"; style="color: #304556;">Voir Si vous n'avez jamais voulu vous inscrire et que vous continuez à recevoir ce message, vous pouvez contacter le webmaster de cette liste à l'adresse suivante : mailto:francois_norman...@hotmail.com"; style="color: #304556;"> francois_norman...@hotmail.com L'équipe Mailinglist http://www.mailinglist.fr/img2/structure/bas_box.gif"; width="570" height="6">
Re: pf and altq setup
I posted on the pf mailing list originally, but the very aggresive spam
filter will not allow me to post a follow-up. I guess there are some pf
users on this list also :)
My original post can be found here:
http://marc.info/?l=openbsd-pf&m=129740086511664&w=2
Stuart Henderson wrote:
Basically don't use queues named "foo_in" and "foo_out", just use
a single name "foo", defined with "queue foo on $tdcif" and "queue
foo on $sirif". See the list archives for more; this has come up
several times.
If using separate names is wrong, why does the sample in the pf FAQ use
that method?
But I tried making this change, and many others. I could get either the
incoming or outgoing traffic to pass through the correct queues, but not
both at the same time.
The final version (so far) uses only pass out, and no pass in rules. I
also had to add "no state" to all the rules, to get the traffic through
the queues.
How much performance penalty do you get by not using states? The CPU of
the system is an 800MHz Via Ezra, so it should be fast enough I guess.
Is it possible to get it working with states?
The new config is included below.
And another question. How do you subscribe to this list? Every subscribe
request I have sent (to the address listed on benzedrine.cx), gets
rejected as spam...
Best regards,
Mikkel C. Simonsen
sirif="fxp0"
tdcif="fxp1"
table const {1.2.3.171, 1.2.3.164}
table const {1.2.3.165, 1.2.3.168}
table const {1.2.3.172}
table const {1.2.3.160/28}
table const {1.2.3.170, 1.2.3.164}
table const {1.2.3.162}
altq on $tdcif hfsc bandwidth 10.5Mb queue { voip_out, dns_out,
bulk_out, web_out, mail_out }
queue voip_out on $tdcif bandwidth 5% priority 7 qlimit 500 hfsc
(realtime 5%)
queue dns_out on $tdcif bandwidth 5% priority 6 qlimit 500 hfsc
(realtime 5%)
queue web_out on $tdcif bandwidth 40% priority 5 qlimit 500 hfsc
(realtime 30%)
queue mail_out on $tdcif bandwidth 25% priority 3 qlimit 500 hfsc
(upperlimit 50%)
queue bulk_out on $tdcif bandwidth 25% priority 4 qlimit 500 hfsc
(upperlimit 50% default)
altq on $sirif hfsc bandwidth 13.5Mb queue { voip_in, dns_in, bulk_in,
web_in, mail_in }
queue voip_in on $sirif bandwidth 4% priority 7 qlimit 500 hfsc
(realtime 4%)
queue dns_in on $sirif bandwidth 5% priority 6 qlimit 500 hfsc
(realtime 5%)
queue web_in on $sirif bandwidth 20% priority 5 qlimit 500 hfsc
(realtime 15%)
queue mail_in on $sirif bandwidth 41% priority 3 qlimit 500 hfsc
(upperlimit 50%)
queue bulk_in on $sirif bandwidth 30% priority 4 qlimit 500 hfsc
(upperlimit 50% default)
set skip on lo
set skip on rl0
# Trafik IND
pass in quick proto tcp from 2.105.54.144/29 to any port telnet queue
bulk_in
block in quick on $tdcif proto tcp to port smtp
block in quick on $tdcif proto tcp to port 500
block in quick on $tdcif proto tcp to port 275
block in quick on $tdcif proto tcp to any port telnet
block in quick on $tdcif proto tcp to any port 717
block in quick on $tdcif proto tcp from 89.104.217.210 to 1.2.3.165 port
smtp
pass out quick on $sirif proto udp from any to queue voip_in no state
pass out quick on $sirif proto { tcp, udp } from any to port
domain queue dns_in no state
pass out quick on $sirif proto tcp from any to port {80, 443}
queue web_in no state
pass out quick on $sirif proto tcp from any to queue mail_in no state
pass in quick queue bulk_in no state
# Trafik UD
pass out quick on $tdcif proto udp from to any queue voip_out no
state
pass out quick on $tdcif proto tcp from to any queue web_out no state
pass out quick on $tdcif from to any queue dns_out no state
pass out quick on $tdcif proto tcp from to any queue mail_out no
state
pass out quick queue bulk_out no state
amd64 build of HEAD from 02/24 6:30pm CST broke...
System installed from a 4.8-amd64 CD today, then cvs-update to HEAD less than an hour ago... cc -O2 -pipe -g -DL_ENDIAN -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DANSI_SOURCE -DNO_ERR -DNO_WINDOWS_BRAINDEATH -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_GOST -DOPENSSL_NO_HW_4758_CCA -DOPENSSL_NO_HW_AEP -DOPENSSL_NO_HW_ATALLA -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_HW_CSWIFT -DOPENSSL_NO_HW_NCIPHER -DOPENSSL_NO_HW_NURON -DOPENSSL_NO_HW_PADLOCK -DOPENSSL_NO_HW_SUREWARE -DOPENSSL_NO_HW_UBSEC -I/usr/src/lib/libssl/crypto/../src -I/usr/src/lib/libssl/crypto/../src/crypto -I/usr/src/lib/libssl/crypto/../src/crypto/asn1 -I/usr/src/lib/libssl/crypto/../src/crypto/evp -I/usr/src/lib/libssl/crypto/obj -DAES_ASM -DMD5_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DWHIRLPOOL_ASM -DOPENSSL_IA32_SSE2 -c /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c -o pqueue.o In file included from /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:67:31: error: openssl/pq_compat.h: No such file or directory In file included from /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:73: error: expected specifier-qualifier-list before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:80: error: expected ')' before 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:89: error: expected declaration specifiers or '...' before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:71: error: expected ')' before 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pitem_free': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:90: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_insert': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:125: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:129: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:134: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:143: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:144: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_pop': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:161: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: At top level: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:167: error: expected declaration specifiers or '...' before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_find': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:175: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:176: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: 'priority' undeclared (first use in this function) /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: (Each undeclared identifier is reported only once /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: for each function it appears in.) /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:186: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_next': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:233: error: 'pitem' has no member named 'next' *** Error code 1 Stop in /usr/src/lib/libssl/crypto (line 92 of /usr/share/mk/sys.mk). *** Error code 1 Stop in /usr/src/lib/libssl (line 48 of /usr/share/mk/bsd.subdir.mk). *** Error code 1 Stop in /usr/src/lib (line 48 of /usr/share/mk/bsd.subdir.mk). *** Error code 1 Stop in /usr/src (line 74 of Makefile). -- Ron McDowell San Antonio TX
Re: Radeon HD 4850 and drmRadeonCmdBuffer: -22.
Thus said Joe Snikeris on Thu, 24 Feb 2011 10:03:06 EST: > On Thu, Feb 24, 2011 at 3:09 AM, Andy Bradford > wrote: > > > > Also, I tried without RADEON_IS_MOBILITY (this isn't a laptop, but > > maybe it actually uses the same code), but without it, the system > > locks up hard and is completely unresponsive with dead video signal. > > Without this set, does it lock up every time or just sometimes? I'm > experiencing intermittent lockups with my HD4870. It seems to happen > more often when I've been in X, leave X, and then go back to X; > although this is just a half-assed theory. That's a good question. The first time it locked up it was enough for me and I put the option back in. It wasn't just the video card that locked up, the system was entirely locked up and unresponsive and required fsck after. You're more than welcome to add RADEON_IS_MOBILITY and see if your lock ups go away. I'm not sure which cards this is *supposed* to be set with. Andy
Re: amd64 build of HEAD from 02/24 6:30pm CST broke...
On 02/24/11 20:15, Ron McDowell wrote: > System installed from a 4.8-amd64 CD today, then cvs-update to HEAD less > than an hour ago... No, your process is broke. Please read FAQ5. The part you definitely violated is 5.3.2 Nick.
Re: network bandwith with em(4)
id like to reiterate ryans advice to have a look at the systat mbuf output. as he said, mclgeti will try to protect the host by restricting the number of packets placed on the rx rings. it turns out you dont need (or cant use) a lot of packets on the ring, so bumping the ring size is a useless tweak. mclgeti simply wont let you fill all those descriptors. if you were allowed to fill all 2048 entries on your modified rings, that would just mean you spend more time in the interrupt handler pulling packets off these rings and freeing them immediately because you have no time to process them. ie, increasing the ring size would actually slow down your forwarding rate if mclgeti was disabled. cheers, dlg On 25/02/2011, at 9:41 AM, Ryan McBride wrote: > On Wed, Feb 23, 2011 at 06:07:16PM +0100, Patrick Lamaiziere wrote: >> I log the congestion counter (each 10s) and there are at max 3 or 4 >> congestions per day. I don't think the bottleneck is pf. > > The congestion counter doesn't directly mean you have a bottleneck in > PF; it's triggered by the IP input queue being full, and could indicate > a bottleneck in other places as well, which PF tries to help out with by > dropping packets earlier. > > >>> Interface errors? >> >> Quite a lot. > > The output of `systat mbufs` is worth looking at, in particular the > figure for LIVELOCKS, and the LWM/CWM figures for the interface(s) in > question. > > If the livelocks value is very high, and the LWM/CWM numbers are very > small, it is likely that the MCLGETI interface is protecting your system > from being completly flattened by forcing the em card to drop packets > (supported by your statement that the error rate is high). If it's bad > enough MCLGETI will be so effective that the pf congestion counter will > not get increment. > > > You mentioned the following in your initial email: > >> #define MAX_INTS_PER_SEC8000 >> >> Do you think I can increase this value? The interrupt rate of the >> machine is at max ~60% (top). > > Increasing this value will likely hurt you. 60% interrupt rate sounds > about right to me for a firewall system that is running at full tilt; > 100% interrupt is very bad, if your system spends all cycles servicing > interrupts it will not do very much of anything useful. > > >> dmesg: >> em0 at pci5 dev 0 function 0 "Intel PRO/1000 QP (82571EB)" rev >> 0x06: apic 1 int 13 (irq 14), address 00:15:17:ed:98:9d >> >> em4 at pci9 dev 0 function 0 "Intel PRO/1000 QP (82575GB)" rev 0x02: >> apic 1 int 23 (irq 11), address 00:1b:21:38:e0:80 > > How about a _full_ dmesg, so someone can take a wild guess at what > your machine is capable of? > > -Ryan
Re: pf rdr-to outgoing to local port issues
> pass out log(matches) quick inet proto tcp from any to 89.176.141.250 port = > www rdr-to 127.0.0.1 port 8080 I think rdr-to is meant to be use on inbound rules.
Re: network bandwith with em(4)
>> We've got same problems (on a routeur, not a firewall). Increasing >> MAX_INTS_PER_SEC to 24000 increased bandwith and lowered packet loss. >> Our cards are "Intel PRO/1000 (82576)" and "Intel PRO/1000 FP >> (82576)". > >Did you try to increase the number of descriptor? >#define EM_MAX_TXD 256 >#define EM_MAX_RXD 256 > >I've tried up to 2048 (and with MAX_INTS_PER_SEC = 16000) but it looks >worth. Say you increase this. That means on a single interrupt, the handler could be forced to handle around 2000 packets. Nothing else will happen on the machine during that period. Can you say 'interrupt latency increase' boys and girls?
Could OpenBSD router benefit from Xeon CPU and Intel PRO/1000PT Quad combination?
Hi, I am testing various hardware processor, however I can't get one of each type, money is not endless. But I came across this statement for this Intel card: Intel. EXPI9404PTL PCI-E PRO/1000 PT Quad Port Low Profile Server Adapter "Additionally, the Intel PRO/1000 PT Quad Port Server Adapter enables Intel I/O Acceleration Technology (Intel I/OAT) for faster I/O processing on the new Dual-Core Intel Xeon processor-based servers." I try to dig this up more to see if that true hardware based, or if that's only with drivers from Intel on Windows servers only and it appear so far that I can't prove either way yet. Does anyone actually know if that true and if actually combining the two as said above would in fact provide better throughput? Meaning is that actually and really built-in the hardware of each device regardless or OS and the statement is valid and true? I am not buying that statement yet without drivers for the OS and most likely wouldn't be true in OpenBSD, but I would very much welcome to be wrong here! I never seriously consider Xeon processor for routers yet, certainly not multicore one for better performance. Not that it can't be used obviously, but I always go for higher clock speed oppose to core on the CPU and I don't see that changed anytime soon anyway for what I know. So far best results appear to always be from Pentium D type single core processors and Intel network cards. Could the above combination be true and actually provide better output in routing setup? Many thanks for your time on this if you actually know more, I would very much appreciate to know and truly understand this! So far I put that into the marketing side more then into true life experience. Best, Daniel
Re: amd64 build of HEAD from 02/24 6:30pm CST broke...
Nick Holland wrote: > On 02/24/11 20:15, Ron McDowell wrote: > >> System installed from a 4.8-amd64 CD today, then cvs-update to HEAD less >> than an hour ago... >> > > No, your process is broke. > Please read FAQ5. > The part you definitely violated is 5.3.2 > > Nick. > Thanks. Okay, I threw away that install [literally...it was a VMware image so deleted it and created a new one] and reloaded from the 4.9 amd64 snapshot install.iso: # uname -a OpenBSD currobsd.volente.us 4.9 GENERIC#470 amd64 and did a clean checkout with: cvs -d anon...@anoncvs3.usa.openbsd.org:/cvs checkout -rHEAD -P src and once again... cc -O2 -pipe -g -DL_ENDIAN -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DANSI_SOURCE -DNO_ERR -DNO_WINDOWS_BRAINDEATH -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_GOST -DOPENSSL_NO_HW_4758_CCA -DOPENSSL_NO_HW_AEP -DOPENSSL_NO_HW_ATALLA -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_HW_CSWIFT -DOPENSSL_NO_HW_NCIPHER -DOPENSSL_NO_HW_NURON -DOPENSSL_NO_HW_PADLOCK -DOPENSSL_NO_HW_SUREWARE -DOPENSSL_NO_HW_UBSEC -I/usr/src/lib/libssl/crypto/../src -I/usr/src/lib/libssl/crypto/../src/crypto -I/usr/src/lib/libssl/crypto/../src/crypto/asn1 -I/usr/src/lib/libssl/crypto/../src/crypto/evp -I/usr/src/lib/libssl/crypto/obj -DAES_ASM -DMD5_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DWHIRLPOOL_ASM -DOPENSSL_IA32_SSE2 -c /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c -o pqueue.o In file included from /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:67:31: error: openssl/pq_compat.h: No such file or directory In file included from /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:73: error: expected specifier-qualifier-list before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:80: error: expected ')' before 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:89: error: expected declaration specifiers or '...' before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:71: error: expected ')' before 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pitem_free': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:90: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_insert': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:125: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:129: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:134: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:143: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:144: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_pop': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:161: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: At top level: /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:167: error: expected declaration specifiers or '...' before 'PQ_64BIT' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_find': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:175: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:176: error: 'pitem' has no member named 'next' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: 'priority' undeclared (first use in this function) /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: (Each undeclared identifier is reported only once /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: for each function it appears in.) /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:186: error: 'pitem' has no member named 'priority' /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function 'pqueue_next': /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:233: error: 'pitem' has no member named 'next' *** Error code 1 Stop in /usr/src/lib/libssl/crypto (line 92 of /usr/share/mk/sys.mk)
Re: amd64 build of HEAD from 02/24 6:30pm CST broke...
On Fri, Feb 25, 2011 at 12:55:34AM -0600, Ron McDowell wrote: > Nick Holland wrote: > > On 02/24/11 20:15, Ron McDowell wrote: > > > >> System installed from a 4.8-amd64 CD today, then cvs-update to HEAD less > >> than an hour ago... > >> > > > > No, your process is broke. > > Please read FAQ5. > > The part you definitely violated is 5.3.2 > > > > Nick. > > > > Thanks. Okay, I threw away that install [literally...it was a VMware > image so deleted it and created a new one] and reloaded from the 4.9 > amd64 snapshot install.iso: > > # uname -a > OpenBSD currobsd.volente.us 4.9 GENERIC#470 amd64 > > and did a clean checkout with: > cvs -d anon...@anoncvs3.usa.openbsd.org:/cvs checkout -rHEAD -P src > > and once again... Different process error, so different build error. -Otto > > cc -O2 -pipe -g -DL_ENDIAN -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS > -DANSI_SOURCE -DNO_ERR -DNO_WINDOWS_BRAINDEATH -DOPENSSL_NO_IDEA > -DOPENSSL_NO_RC5 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_GOST > -DOPENSSL_NO_HW_4758_CCA -DOPENSSL_NO_HW_AEP -DOPENSSL_NO_HW_ATALLA > -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_HW_CSWIFT -DOPENSSL_NO_HW_NCIPHER > -DOPENSSL_NO_HW_NURON -DOPENSSL_NO_HW_PADLOCK -DOPENSSL_NO_HW_SUREWARE > -DOPENSSL_NO_HW_UBSEC -I/usr/src/lib/libssl/crypto/../src > -I/usr/src/lib/libssl/crypto/../src/crypto > -I/usr/src/lib/libssl/crypto/../src/crypto/asn1 > -I/usr/src/lib/libssl/crypto/../src/crypto/evp > -I/usr/src/lib/libssl/crypto/obj -DAES_ASM -DMD5_ASM -DSHA1_ASM > -DSHA256_ASM -DSHA512_ASM -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT > -DWHIRLPOOL_ASM -DOPENSSL_IA32_SSE2 -c > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c -o pqueue.o > In file included from > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:67:31: error: > openssl/pq_compat.h: No such file or directory > In file included from > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:73: error: > expected specifier-qualifier-list before 'PQ_64BIT' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:80: error: > expected ')' before 'priority' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:89: error: > expected declaration specifiers or '...' before 'PQ_64BIT' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:71: error: > expected ')' before 'priority' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function > 'pitem_free': > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:90: error: > 'pitem' has no member named 'priority' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function > 'pqueue_insert': > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:125: error: > 'pitem' has no member named 'next' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: > 'pitem' has no member named 'priority' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: > 'pitem' has no member named 'priority' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:129: error: > 'pitem' has no member named 'next' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:134: error: > 'pitem' has no member named 'next' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: > 'pitem' has no member named 'priority' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: > 'pitem' has no member named 'priority' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:143: error: > 'pitem' has no member named 'next' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:144: error: > 'pitem' has no member named 'next' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function > 'pqueue_pop': > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:161: error: > 'pitem' has no member named 'next' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: At top level: > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:167: error: > expected declaration specifiers or '...' before 'PQ_64BIT' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function > 'pqueue_find': > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:175: error: > 'pitem' has no member named 'next' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:176: error: > 'pitem' has no member named 'next' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: > 'pitem' has no member named 'priority' > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: > 'priority' undeclared (first use in this function) > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: > (Each undeclared identifier is reported only once > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: for > each function it appears in.) > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.
Re: amd64 build of HEAD from 02/24 6:30pm CST broke...
On Fri, Feb 25, 2011 at 08:28:42AM +0100, Otto Moerbeek wrote: > On Fri, Feb 25, 2011 at 12:55:34AM -0600, Ron McDowell wrote: > > > Nick Holland wrote: > > > On 02/24/11 20:15, Ron McDowell wrote: > > > > > >> System installed from a 4.8-amd64 CD today, then cvs-update to HEAD less > > >> than an hour ago... > > >> > > > > > > No, your process is broke. > > > Please read FAQ5. > > > The part you definitely violated is 5.3.2 > > > > > > Nick. > > > > > > > Thanks. Okay, I threw away that install [literally...it was a VMware > > image so deleted it and created a new one] and reloaded from the 4.9 > > amd64 snapshot install.iso: > > > > # uname -a > > OpenBSD currobsd.volente.us 4.9 GENERIC#470 amd64 > > > > and did a clean checkout with: > > cvs -d anon...@anoncvs3.usa.openbsd.org:/cvs checkout -rHEAD -P src > > > > and once again... > > Different process error, so different build error. Oops, it's the same errror, confused another build error report. Anyway, Look at the error message. You are missing a file. Did you install all sets? > > -Otto > > > > > cc -O2 -pipe -g -DL_ENDIAN -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS > > -DANSI_SOURCE -DNO_ERR -DNO_WINDOWS_BRAINDEATH -DOPENSSL_NO_IDEA > > -DOPENSSL_NO_RC5 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_GOST > > -DOPENSSL_NO_HW_4758_CCA -DOPENSSL_NO_HW_AEP -DOPENSSL_NO_HW_ATALLA > > -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_HW_CSWIFT -DOPENSSL_NO_HW_NCIPHER > > -DOPENSSL_NO_HW_NURON -DOPENSSL_NO_HW_PADLOCK -DOPENSSL_NO_HW_SUREWARE > > -DOPENSSL_NO_HW_UBSEC -I/usr/src/lib/libssl/crypto/../src > > -I/usr/src/lib/libssl/crypto/../src/crypto > > -I/usr/src/lib/libssl/crypto/../src/crypto/asn1 > > -I/usr/src/lib/libssl/crypto/../src/crypto/evp > > -I/usr/src/lib/libssl/crypto/obj -DAES_ASM -DMD5_ASM -DSHA1_ASM > > -DSHA256_ASM -DSHA512_ASM -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT > > -DWHIRLPOOL_ASM -DOPENSSL_IA32_SSE2 -c > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c -o pqueue.o > > In file included from > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:67:31: error: > > openssl/pq_compat.h: No such file or directory > > In file included from > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:73: error: > > expected specifier-qualifier-list before 'PQ_64BIT' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:80: error: > > expected ')' before 'priority' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:89: error: > > expected declaration specifiers or '...' before 'PQ_64BIT' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:71: error: > > expected ')' before 'priority' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function > > 'pitem_free': > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:90: error: > > 'pitem' has no member named 'priority' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function > > 'pqueue_insert': > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:125: error: > > 'pitem' has no member named 'next' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: > > 'pitem' has no member named 'priority' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: > > 'pitem' has no member named 'priority' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:129: error: > > 'pitem' has no member named 'next' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:134: error: > > 'pitem' has no member named 'next' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: > > 'pitem' has no member named 'priority' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: > > 'pitem' has no member named 'priority' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:143: error: > > 'pitem' has no member named 'next' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:144: error: > > 'pitem' has no member named 'next' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function > > 'pqueue_pop': > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:161: error: > > 'pitem' has no member named 'next' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: At top level: > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:167: error: > > expected declaration specifiers or '...' before 'PQ_64BIT' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function > > 'pqueue_find': > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:175: error: > > 'pitem' has no member named 'next' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:176: error: > > 'pitem' has no member named 'next' > > /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:178: error: > > 'pitem' has no member named 'priority'
Re: amd64 build of HEAD from 02/24 6:30pm CST broke...
Otto Moerbeek wrote: > On Fri, Feb 25, 2011 at 08:28:42AM +0100, Otto Moerbeek wrote: > > >> On Fri, Feb 25, 2011 at 12:55:34AM -0600, Ron McDowell wrote: >> >> >>> Nick Holland wrote: >>> On 02/24/11 20:15, Ron McDowell wrote: > System installed from a 4.8-amd64 CD today, then cvs-update to HEAD less > than an hour ago... > > No, your process is broke. Please read FAQ5. The part you definitely violated is 5.3.2 Nick. >>> Thanks. Okay, I threw away that install [literally...it was a VMware >>> image so deleted it and created a new one] and reloaded from the 4.9 >>> amd64 snapshot install.iso: >>> >>> # uname -a >>> OpenBSD currobsd.volente.us 4.9 GENERIC#470 amd64 >>> >>> and did a clean checkout with: >>> cvs -d anon...@anoncvs3.usa.openbsd.org:/cvs checkout -rHEAD -P src >>> >>> and once again... >>> >> Different process error, so different build error. >> > > Oops, it's the same errror, confused another build error report. > Anyway, Look at the error message. You are missing a file. Did you > install all sets? > All but bsd.mp --rcm > >> -Otto >> >> >>> cc -O2 -pipe -g -DL_ENDIAN -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS >>> -DANSI_SOURCE -DNO_ERR -DNO_WINDOWS_BRAINDEATH -DOPENSSL_NO_IDEA >>> -DOPENSSL_NO_RC5 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_GOST >>> -DOPENSSL_NO_HW_4758_CCA -DOPENSSL_NO_HW_AEP -DOPENSSL_NO_HW_ATALLA >>> -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_HW_CSWIFT -DOPENSSL_NO_HW_NCIPHER >>> -DOPENSSL_NO_HW_NURON -DOPENSSL_NO_HW_PADLOCK -DOPENSSL_NO_HW_SUREWARE >>> -DOPENSSL_NO_HW_UBSEC -I/usr/src/lib/libssl/crypto/../src >>> -I/usr/src/lib/libssl/crypto/../src/crypto >>> -I/usr/src/lib/libssl/crypto/../src/crypto/asn1 >>> -I/usr/src/lib/libssl/crypto/../src/crypto/evp >>> -I/usr/src/lib/libssl/crypto/obj -DAES_ASM -DMD5_ASM -DSHA1_ASM >>> -DSHA256_ASM -DSHA512_ASM -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT >>> -DWHIRLPOOL_ASM -DOPENSSL_IA32_SSE2 -c >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c -o pqueue.o >>> In file included from >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:67:31: error: >>> openssl/pq_compat.h: No such file or directory >>> In file included from >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:62: >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:73: error: >>> expected specifier-qualifier-list before 'PQ_64BIT' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:80: error: >>> expected ')' before 'priority' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.h:89: error: >>> expected declaration specifiers or '...' before 'PQ_64BIT' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:71: error: >>> expected ')' before 'priority' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function >>> 'pitem_free': >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:90: error: >>> 'pitem' has no member named 'priority' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function >>> 'pqueue_insert': >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:125: error: >>> 'pitem' has no member named 'next' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: >>> 'pitem' has no member named 'priority' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:127: error: >>> 'pitem' has no member named 'priority' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:129: error: >>> 'pitem' has no member named 'next' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:134: error: >>> 'pitem' has no member named 'next' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: >>> 'pitem' has no member named 'priority' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:139: error: >>> 'pitem' has no member named 'priority' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:143: error: >>> 'pitem' has no member named 'next' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:144: error: >>> 'pitem' has no member named 'next' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function >>> 'pqueue_pop': >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:161: error: >>> 'pitem' has no member named 'next' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: At top level: >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:167: error: >>> expected declaration specifiers or '...' before 'PQ_64BIT' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c: In function >>> 'pqueue_find': >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:175: error: >>> 'pitem' has no member named 'next' >>> /usr/src/lib/libssl/crypto/../src/crypto/pqueue/pqueue.c:176: error: >>> 'pitem' has no member name
