Re: Need help setting http headers using relayd (and httpd)
Hi again!
So, read the book as suggested, got relayd working, headers set, HTTP
methods blocked just like I wanted (on my "test" box). However, when
starting to use TLS-by-relayd rather than by httpd, it seems I lost OCSP
stapling support. Does relayd.conf understand a line like
tls ocsp "/etc/ssl/pejorative.andreasthulin.se.ocsp"
or are there other ways of resolving this?
Cheers,
Andreas
--- httpd.conf ---
# $OpenBSD: httpd.conf,v 1.14 2015/02/04 08:39:35 florian Exp $
# Made from /etc/examples/httpd.conf 2015-03-19
# --
# Include MIME types instead of the built-in ones
types {
include "/usr/share/misc/mime.types"
}
# pejorative.andreasthulin.se - HTTP
server "pejorative.andreasthulin.se" {
listen on * port 8080
block return 301 "https://$SERVER_NAME$REQUEST_URI";
log syslog
}
# pejorative.andreasthulin.se - HTTPS
server "pejorative.andreasthulin.se" {
hsts subdomains
listen on * tls port 8082
tls certificate "/etc/ssl/pejorative.andreasthulin.se.fullchain.pem"
tls key "/etc/ssl/private/pejorative.andreasthulin.se.key"
tls ocsp "/etc/ssl/pejorative.andreasthulin.se.ocsp"
root "/htdocs/andreasthulin.se"
location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
directory { index "index.php" }
log syslog
}
--- relayd.conf ---
# $OpenBSD: relayd.conf,v 1.3 2014/12/12 10:05:09 reyk Exp $
# /etc/relayd.conf 2017-10-12
table { 127.0.0.1 }
ext_ip = "192.168.1.40"
http protocol https {
tcp { nodelay, sack, socket buffer 65536, backlog 100 }
return error
block method CONNECT
block method DELETE
block method HEAD
block method OPTIONS
block method PUT
match response header remove "X-Powered-By"
match response header set "X-Bogus-Header" value "False"
match response header set "X-Frame-Options" value "deny"
match response header set "X-Content-Type-Options" value "nosniff"
match response header set "X-XSS-Protection" value "1; mode=block"
match response header append "Content-Security-Policy" value
"default-src 'none'"
match response header append "Content-Security-Policy" value
"script-src 'self'"
match response header append "Content-Security-Policy" value "style-src
'self'"
match response header append "Content-Security-Policy" value "img-src
'self'"
match response header append "Content-Security-Policy" value
"connect-src 'self'"
match response header append "Content-Security-Policy" value
"frame-ancestors 'none'"
}
relay "tlsforward" {
listen on $ext_ip port 4433 tls
protocol https
forward with tls to port 8082 mode loadbalance check tcp
}
fre 13 okt. 2017 kl 09:28 skrev Andreas Thulin :
> Thank you, I just bought the Kindle version. :-)
>
> BR, Andreas
> fre 13 okt. 2017 kl. 02:16 skrev Bryan Harris :
>
>> There is a book called relayd and httpd. I think it has what you need.
>>
>> V/r,
>> Bryan
>>
>>
>>
>> > On Oct 12, 2017, at 1:33 PM, Andreas Thulin
>> wrote:
>> >
>> > Hi!
>> >
>> > Before anything, thanks for yet another awesome OpenBSD release! I’ll
>> > extend my gratitude into the pockets of the Foundation and finally
>> donate
>> > this time.
>> >
>> > Then:
>> >
>> > I’m a relayd virgin. Consider all the following a lab exercise, I want
>> to
>> > learn and understand more.
>> >
>> > My target:
>> > Understanding how to score an A+ on the htbridge web server security
>> test.
>> > https://www.htbridge.com/websec/?id=BT1UmswV
>> >
>> > First objective:
>> > Set HTTP headers, such as
>> >
>> > CONTENT-SECURITY-POLICY
>> > X-CONTENT-TYPE-OPTIONS
>> > X-XSS-PROTECTION
>> >
>> > using relayd (since httpd can’t help out here).
>> >
>> > Assumptions etc:
>> > - I suppose only https traffic is in scope, since all http traffic is
>> > redirected to https.
>> > - Both httpd and relayd are (will be) run on the same 6.2 machine.
>> > - httpd runs just fine and scores an A+ on the htbridge TLS Server Test
>> > more or less out of the box. The web server test, however, was a
>> > disappointing F. :-)
>> >
>> > I’m only a mortal, so simply reading the relayd.conf man page and do
>> some
>> > trial-and-error has so far only made me go all CAPS. I seek examples (of
>> > something similar to the above use-case), a guide, turorial, or even a
>> > how-to to make this happen. I can learn all the config options and
>> settings
>> > afterwards, and keep tweaking and understanding.
>> >
>> > Anyone?
>> >
>> > Humbly,
>> > Andreas
>>
>
Re: Chrome crashes with 6.2 (Please update official download sites!)
On 10/26/17 13:26, Cág wrote: Federico Giannici wrote: Since I upgraded from OBSD 6.1 to 6.2 (amd64), at least half the time I launch Chrome it crashes (with a "use after free"). We had a discussion in the ports@ list a couple of days ago: https://marc.info/?t=15085986372&r=1&w=2 I installed the current snapshot package (chromium-61.0.3163.100p1.tgz) and it solved the problem! Now I can use chrome again... As this snapshot package will soon disappear for new ones with incompatible dependences, I think that it would be VERY useful for A LOT of people that this package be put in the official download sites. Thank you
Re: Chrome crashes with 6.2
On 10/26/17 14:26, Cág wrote: > Federico Giannici wrote: > >> Since I upgraded from OBSD 6.1 to 6.2 (amd64), at least half the time I >> launch Chrome it crashes (with a "use after free"). > > We had a discussion in the ports@ list a couple of days ago: > https://marc.info/?t=15085986372&r=1&w=2 Had these intermittent Chrome start-up crashes since at least OpenBSD 6.0, but now they seem to be gone with the latest package from -current (brazenly installed on 6.2, as suggested on ports@). Also an issue for Iridium (crashes about every 5 launches). By the way, on i386 Chrome has become unusable for me after updating to 6.2 (extensions crash on start, only simple pages such as openbsd.org load, but the rendering process associated with the tab still crashes after a few seconds). Also, netsurf on i386 crashes every time for me with 6.2, even with no saved settings. The errors look similar: netsurf-gtk(18043) in free(): use after free 0x831b7420 Will look into using sendbug(1) for the first time. If anyone wonders if there's still a usable (possibly full-blown) browser for i386, I'm running SeaMonkey and Iridium (the latter for some web apps, such as Google Music). Firefox has got too bloated, especially since 52.x builds (starting with 6.1) use multiple processes and GTK+ 3.x. In the end, a plea to the awesome maintainer(s) of the most usable Chromium BSD port: please consider Chrome/Iridium binary updates for -stable, as the amazing Landry Breuil builds for Firefox and Thunderbird since 6.1. Not sure many people know about these third-party updates, more at http://undeadly.org/cgi?action=article&sid=20170425173917. Shoutouts to the wonderful people of M:Tier too, I use their binary updates as well! Sadly, -current on amd64 is not an option for me, as I use OpenBSD for work too and need to run a custom Python runtime, only built for -release. And using -current on i386 (for my home router / AP / multimedia station) is too painful… Thanks for the great releases! ;-] signature.asc Description: OpenPGP digital signature
Re: mandoc output paper size
In article <20171026193138.ga41...@www.stare.cz> Jan Stary wrote: > > > > In the ps file generated by mandoc you should have this line: > > > > > > > > %%DocumentMedia: Default 595 841 0 () () > > > > > > > > Where 595 841 correspond to A4. If you set output paper to "letter" > > > > that line will say: > > > > > > > > %%DocumentMedia: Default 612 790 0 () () > > Yes. It seems that these are just _comments_ to the PS interpreter > and the "Default" is just an arbitrary given name, right? > (Sorry, I don't know the language.) So GV just shows that, > but it does not _determine_ the actual media size, right? > Looking at term_ps.c, mandoc writes "Default ... " for every paper size. > First of all, I'm just a user like you trying to figure out how things work. So, don't expect from me some deep analysis, for that Ingo is the right person. I answered you - based in what I intuitively observed - that mandoc honors the paper size, and explained you why I think so. I know about postcript language as much as you, as well as what gv takes in care to print the document on the screen, so first I grep in the ps file for 'a4|letter' strings and got nothing, then searching on the Internet I found the dots equivalence and repeated the search this time using '595 841|612 790'. I did the same with documents generated by GNU roff. I found the "comment" I mentioned in the other message, so I opened the ps file with vi(1), changed those numbers, and then I opened the modified file with gv. That's how I found out gv takes in care that "comment" to figure out physical page dimensions. As far as I understand postscript draws page contents using coordinates and using the postscript dot as unit (as Ingo explained). What gv does is just trying to figure out the best way to print the document on screen; when you select A4|Letter in the menu it only modifies the page, the rest of dimensions stay the same. Ingo will correct me if I'm wrong about this, we're talking specifically about how gv shows you the document in screen, it shouldn't affect how the document is printed on paper (what I *guess* gv does in this case is to send the postscript file "as is" to lpr or cups.) Finally, "default" means "default". :-) Perhaps (guessing again), since page size use is related to region settings, who designed postscript (hence gv) thought convenient to honor some wide system setting (based on locale?). > Jan > > Walter
Re: mandoc output paper size
On Oct 27 12:12:21, w...@roquesor.com wrote: > In article <20171026193138.ga41...@www.stare.cz> Jan Stary > wrote: > > > > > In the ps file generated by mandoc you should have this line: > > > > > > > > > > %%DocumentMedia: Default 595 841 0 () () > > > > > > > > > > Where 595 841 correspond to A4. If you set output paper to "letter" > > > > > that line will say: > > > > > > > > > > %%DocumentMedia: Default 612 790 0 () () > > > > Yes. It seems that these are just _comments_ to the PS interpreter > > and the "Default" is just an arbitrary given name, right? > > (Sorry, I don't know the language.) So GV just shows that, > > but it does not _determine_ the actual media size, right? > > Looking at term_ps.c, mandoc writes "Default ... " for every paper size. > > > > First of all, I'm just a user like you trying to figure out how things > work. So, don't expect from me some deep analysis, for that Ingo is the > right person. > > I answered you - based in what I intuitively observed - that mandoc > honors the paper size, and explained you why I think so. > > I know about postcript language as much as you, as well as what gv takes > in care to print the document on the screen, so first I grep in the > ps file for 'a4|letter' strings and got nothing, then searching on the > Internet I found the dots equivalence and repeated the search this time > using '595 841|612 790'. I did the same with documents generated by GNU > roff. I found the "comment" I mentioned in the other message, so > I opened the ps file with vi(1), changed those numbers, and then > I opened the modified file with gv. That's how I found out gv takes in > care that "comment" to figure out physical page dimensions. Apparently, it does not: the dimensions are given explicitly in e.g. "%%DocumentMedia: Default 595 841 0 () ()", and the "Default" could just as well be "Foobar", as Ingo explained. > Finally, "default" means "default". :-) Perhaps (guessing again), since > page size use is related to region settings, who designed postscript > (hence gv) thought convenient to honor some wide system setting (based > on locale?). With output paper set to A3, A4, A5 in man.conf, "man -Tps rm > rm.ps" will produce a PostScript file with the correct dimensions, calling all the formats "Default". A printer (such us my Minolta) will print them all on A4, although it does have A3 and A5 paper too. Changing the "%%DocumentMedia: Default ..." line manualy to "A3" or "A5" does not change that. I am not saying mandoc should write A3 or A4 or A5 instead of Default (it's the actual dimensions that matter), but perhaps such a DSC comment might help some appications. Apparently not GV, which just repeats the name, and not my Minolta, which prints on A4 anyway. Jan
Re: mandoc output paper size
In article <20171027104221.gd9...@www.stare.cz> Jan Stary wrote: > On Oct 27 12:12:21, w...@roquesor.com wrote: > > In article <20171026193138.ga41...@www.stare.cz> Jan Stary > > wrote: > > > > > > In the ps file generated by mandoc you should have this line: > > > > > > > > > > > > %%DocumentMedia: Default 595 841 0 () () > > > > > > > > > > > > Where 595 841 correspond to A4. If you set output paper to "letter" > > > > > > that line will say: > > > > > > > > > > > > %%DocumentMedia: Default 612 790 0 () () > > > > > > Yes. It seems that these are just _comments_ to the PS interpreter > > > and the "Default" is just an arbitrary given name, right? > > > (Sorry, I don't know the language.) So GV just shows that, > > > but it does not _determine_ the actual media size, right? > > > Looking at term_ps.c, mandoc writes "Default ... " for every paper size. > > > > > > > First of all, I'm just a user like you trying to figure out how things > > work. So, don't expect from me some deep analysis, for that Ingo is the > > right person. > > > > I answered you - based in what I intuitively observed - that mandoc > > honors the paper size, and explained you why I think so. > > > > I know about postcript language as much as you, as well as what gv takes > > in care to print the document on the screen, so first I grep in the > > ps file for 'a4|letter' strings and got nothing, then searching on the > > Internet I found the dots equivalence and repeated the search this time > > using '595 841|612 790'. I did the same with documents generated by GNU > > roff. I found the "comment" I mentioned in the other message, so > > I opened the ps file with vi(1), changed those numbers, and then > > I opened the modified file with gv. That's how I found out gv takes in > > care that "comment" to figure out physical page dimensions. > > Apparently, it does not: the dimensions are given explicitly in e.g. > "%%DocumentMedia: Default 595 841 0 () ()", and the "Default" > could just as well be "Foobar", as Ingo explained. > That's the "comment" we're talking about since the beginning of the thread, aren't we? As I told you what I modified to do the test was the numbers. > > Finally, "default" means "default". :-) Perhaps (guessing again), since > > page size use is related to region settings, who designed postscript > > (hence gv) thought convenient to honor some wide system setting (based > > on locale?). > > With output paper set to A3, A4, A5 in man.conf, "man -Tps rm > rm.ps" > will produce a PostScript file with the correct dimensions, > calling all the formats "Default". A printer (such us my Minolta) > will print them all on A4, although it does have A3 and A5 paper too. > Changing the "%%DocumentMedia: Default ..." line manualy to "A3" or "A5" > does not change that. > > I am not saying mandoc should write A3 or A4 or A5 instead of Default > (it's the actual dimensions that matter), but perhaps such a DSC comment > might help some appications. Apparently not GV, which just repeats the name, > and not my Minolta, which prints on A4 anyway. You know, too much people developing software without caring about what others did before. Who developed your Minolta software is not an exception. ;-) > > Jan > > Walter
Re: mandoc output paper size
Hi Walter, Walter Alejandro Iglesias wrote on Fri, Oct 27, 2017 at 12:12:21PM +0200: > First of all, I'm just a user like you trying to figure out > how things work. So am I. That's how it starts. I also read documentation, standards, and code at need, and start fixing them once i understand enough of them. > So, don't expect from me some deep analysis, for that Ingo > is the right person. Not really. I know a lot about mdoc(7), but almost nothing about PostScript, DSC, and PDF. Yours, Ingo
Re: mandoc output paper size
[ sending this particular one back to the list because it contains something useful for everyone and nothing private ] Hi Jan, Jan Stary wrote on Fri, Oct 27, 2017 at 12:46:00PM +0200: > I produced a PS output with "man -Tps rm > rm.ps", > with output paper set to a3, a4, and a5 in man.conf. > This results, respectively, in > > %%DocumentMedia: Default 841 1190 0 () () > %%DocumentMedia: Default 595 841 0 () () > %%DocumentMedia: Default 419 595 0 () () > > which apparently are the right dimensions. However, > the Minolta will print all of them on A4 paper, > although it does have a stash of A3 and A5 too. > > That's where I thought it might take a hint from the DSC comment, > if I changed the "Default" to "A3" or "A4" or "A5", or if mandoc(1) > itself put that in the DSC comments. I rewrote it manually before > each printing, but the Minolta still prints them all on an A4: That's interesting, but anecdotal. It is neither surprising that a specific printer selects paper as configured (in whichever way), as opposed to inspecting fikes it is sent; nor would it be surprising if other printers, or even the same one, or printer drivers on the print server, could be configured to inspect the contents of PostScript files to select paper. The trouble is, i just don't know what firmwares and softwares do, what they should do according to standards, and where to look for standards in this respect. Does anybody else know? > Hm, so I can remove man.conf altogether, > because even the default "letter" manpages > will get printed on A4, which is what I want. That's a bad idea. The purpose of the -Opaper= option is not to select paper, but to adjust the width and height that the document content will require, and the primary purpose of the DocumentMedia DSC instruction isn't selecting paper either. but to inform how the content was arranged. If you use -Opaper=letter, margins will be reasonable for letter size paper, but ugly for A4: Since letter paper is wider than A4 but not as tall, printing on A4 without -Opaper=a4 will usually result in an awkwardly narrow right margin and in wasted space at the bottom. Yours, Ingo
Re: Chrome crashes with 6.2 (Please update official download sites!)
Federico Giannici wrote: > As this snapshot package will soon disappear for new ones with incompatible > dependences, I think that it would be VERY useful for A LOT of people that > this package be put in the official download sites. They would have to wait for 6.3 or follow -current. -- caóc
Re: Chrome crashes with 6.2
Dumitru Mișu Moldovan wrote: > If anyone wonders if there's still a usable (possibly full-blown) > browser for i386, I'm running SeaMonkey and Iridium (the latter for some > web apps, such as Google Music). Firefox has got too bloated, > especially since 52.x builds (starting with 6.1) use multiple processes > and GTK+ 3.x. Iridium is based on Chromium, isn't it slow on an i386 too? I actually would rather see Pale Moon or GTK+2 Chromium (as a separate package/flavour). -- caóc
Re: Chrome crashes with 6.2
On 10/27/17 17:58, Cág wrote: > Dumitru Mișu Moldovan wrote: > >> If anyone wonders if there's still a usable (possibly full-blown) >> browser for i386, I'm running SeaMonkey and Iridium (the latter for some >> web apps, such as Google Music). Firefox has got too bloated, >> especially since 52.x builds (starting with 6.1) use multiple processes >> and GTK+ 3.x. > > Iridium is based on Chromium, isn't it slow on an i386 too? > > I actually would rather see Pale Moon or GTK+2 Chromium (as a separate > package/flavour). The i386 package of Chrome on 6.1 was slow, but reliable (once you got it started, as it crashed often when launched, as referenced in this thread). On 6.2 (both x86 arches), Chrome is even slower (because of GTK+ 3.x, I suppose) and completely unusable for me on i386, as said. Iridium on 6.2, on both arches, seems to be on par with Chrome from 6.1 (it's also built against GTK 2.x and perhaps a couple of versions ahead of it). For what it's worth, this is a reverse of a trend, up to 6.1 Chrome was getting more and more usable with every release on i386 (I think I've started using it in 5.8). Not complaining, the writing is on the wall for this arch. Just trying to get what life is left in some old but still usable hardware, fighting consumerism along the way. signature.asc Description: OpenPGP digital signature
Re: Chrome crashes with 6.2
> Iridium is based on Chromium, isn't it slow on an i386 too? > I actually would rather see Pale Moon or GTK+2 Chromium (as a separate > package/flavour). I've just tried Iridium, from UX it's basically Chromium from 6.1 - gtk2, none of that dreadfull new design - whoever thought that it was a good idea to add A LOT of space, make letters even smaller and of an almost indistinguishable from the background colour for my half-blind eyes. -- caóc
Re: Chrome crashes with 6.2
Cág writes: > I've just tried Iridium, from UX it's basically Chromium from 6.1 - > gtk2, none of that dreadfull new design - whoever thought that it was a > good idea to add A LOT of space, make letters even smaller and of an > almost indistinguishable from the background colour for my half-blind > eyes. I'm running chromium-61.0.3163.100 from packages, OpenBSD 6.2 release amd64. No crashes, no issues. Allan
pf integration with dhcpd
Howdy. On a 6.2-syspatch box, I wanted to start leveraging the pf integration dhcpd has with the * Abandoned * Changed * Leased tables. In pf, as a first step I added the table definitions: table persist table persist table persist and loaded the rules. Then added the respective flags to dhcpd via rcctl: -A dhcpd_abandoned -C dhcpd_changed -L dhcpd_leased em1 Restarted dhcpd (now noticed that there's a dhcpd: pf table handler process). I booted up some boxes and renewed some other dhcp leases to get some entries in the tables but when I attempted to print them out via pfctl nothing is in them. pfctl -t dhcpd_X -T show pfctl -vvsTables also shows 0 entries for those tables I guessing this is operator error on my part; Arethere any other items I need to do to get it working? Thanks in advance. +--+ Carlos
Re: pf integration with dhcpd
On Fri, Oct 27, 2017 at 2:48 PM, Carlos Cardenas wrote: > On a 6.2-syspatch box, I wanted to start leveraging the pf integration dhcpd > pfctl -t dhcpd_X -T show Do you see the current leases in "/var/db/dhcpd.leases"? A "reserved" address would not show up there, nor would it be placed in the leased table. Must truly be a dynamic lease.
Re: pf integration with dhcpd
On 10/27/17 12:04, Sonic wrote: On Fri, Oct 27, 2017 at 2:48 PM, Carlos Cardenas wrote: On a 6.2-syspatch box, I wanted to start leveraging the pf integration dhcpd pfctl -t dhcpd_X -T show Do you see the current leases in "/var/db/dhcpd.leases"? A "reserved" address would not show up there, nor would it be placed in the leased table. Must truly be a dynamic lease. That's what I thought...operator error. I was expecting entries to appear in tables for reserved addresses as well. Verified everything works (various tables being populated, entries being added/deleted) using dynamic leases. +--+ Carlos
Re: Chrome crashes with 6.2
> I've just tried Iridium, from UX it's basically Chromium from 6.1 - > The i386 package of Chrome on 6.1 was slow Folks, this is misc@ not ports@ or wishes@ !
Lenovo 110s Laptop - bug or unsupported hardware?
I decided to post this in misc because I am not sure if this a bug or unsupported hardware. It is a Lenovo 110s laptop. Apm works on this machine. Suspend and resume work on this machine. When running X, and doing things that require a lot of memory (open firefox and watch a youtube video + 3 or 4 more tabs + open evince and open a sizeable PDF was my test) this machine freezes, and the screen goes black. Sometimes this happens in 30 seconds, sometimes it takes 10 minutes or more. I also tested with Chrome and Midori, and got the same behavior. I also tested playing video locally and the results were the same. On a few occasions it crashed while not doing much, but for the most part if I keep memory usage low (i.e. use a text based browser, for example) it does not crash. DDB is opening in the background after the crash, but I cannot see it. I type ps, and trace, but they do not show up in the messages after rebooting. I have however been able to get several core dumps. They look identical to eachother, which leads me to believe it is the same problem happening in each crash. The above behavior is consistant across i3, Fvwm, and Cwm, with apmd enabled or no, across all flag settings of apm, and machdep.aperture=0, 1, and 2. Serial console is not an option on this machine but I have quite a collection of core dumps. Any advice on trouble shooting this further (or if it's unsupported hardware) would be appreciated. The below info was generated using a kernel built from GENERIC's config + makeoptions DEBUG="-g", built from the CURRENT tree on 10/26. GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd6.2". (gdb) file bsd.8 Reading symbols from /home/utilis/CRASH/102717/607pm/bsd.8...done. (gdb) target kvm bsd.8.core #0 0x8167c544 in dumpsys () at /usr/src/sys/arch/amd64/amd64/machdep.c:949 949 error = (*dump)(dumpdev, blkno, va, n); Current language: auto; currently minimal (gdb) where #0 0x8167c544 in dumpsys () at /usr/src/sys/arch/amd64/amd64/machdep.c:949 #1 0x8167bfea in boot (howto=0) at /usr/src/sys/arch/amd64/amd64/machdep.c:743 #2 0x813cccf5 in reboot (howto=Variable "howto" is not available. ) at /usr/src/sys/kern/kern_xxx.c:70 #3 0x81009f7e in db_boot_crash_cmd (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:790 #4 0x8100986d in db_command (last_cmdp=0x0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:303 #5 0x8100a331 in db_command_loop () at /usr/src/sys/ddb/db_command.c:703 #6 0x816694d4 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_trap.c:93 #7 0x812a75ca in db_ktrap (type=0, code=0, regs=0x0) at /usr/src/sys/arch/amd64/amd64/db_interface.c:152 #8 0x811c150c in trap (frame=0x0) at /usr/src/sys/arch/amd64/amd64/trap.c:188 #9 0x81618a25 in calltrap () #10 0x81405af0 in pmap_flush_cache (addr=18446603336235712512, len=Variable "len" is not available. ) at /usr/src/sys/arch/amd64/amd64/pmap.c:1288 #11 0x815b1a2b in gen8_ppgtt_clear_pte_range (vm=0x80994000, pdp=0x809941a0, start=Variable "start" is not available. ) at /usr/src/sys/dev/pci/drm/i915/i915_gem_gtt.c:394 #12 0x81068ae8 in __i915_vma_unbind (vma=0x156, wait=Variable "wait" is not available. ) at /usr/src/sys/dev/pci/drm/i915/i915_gem.c:3784 #13 0x8106aa3e in i915_gem_free_object (gem_obj=0x80dd16d0) at /usr/src/sys/dev/pci/drm/i915/i915_gem.c:3817 #14 0x81332741 in drm_gem_object_handle_unreference_unlocked (obj=0x156) at /usr/src/sys/dev/pci/drm/drm_gem.c:900 #15 0x81332626 in drm_gem_handle_delete (filp=0x1a7ec083, handle=3) at /usr/src/sys/dev/pci/drm/drm_gem.c:424 #16 0x8169da2c in drm_do_ioctl (dev=0x3, minor=Variable "minor" is not available. ) at /usr/src/sys/dev/pci/drm/drm_drv.c:859 #17 0x8169db2f in drmioctl (kdev=Variable "kdev" is not available. ) at /usr/src/sys/dev/pci/drm/drm_drv.c:886 #18 0x8172fc5e in VOP_IOCTL (vp=Variable "vp" is not available. ) at /usr/src/sys/kern/vfs_vops.c:259 #19 0x8101d99d in vn_ioctl (fp=0x80dd7c80, com=205, data=Variable "data" is not available. ) at /usr/src/sys/kern/vfs_vnops.c:487 #20 0x81479405 in sys_ioctl (p=0x80003020e028, v=0x3, retval=Variable "retval" is not available. ) at /usr/src/sys/kern/sys_generic.c:516 #21 0x811c1a2c in syscall (frame=0xcd) at syscall_mi.h:78 #22 0x8105f2db in Xsyscall () (gdb) # ps
