Re: bsd.rd from snapshot not booting on x220
On Mon, Jul 27, 2015 at 08:11:08AM -0400, Josh Grosse wrote: On 2015-07-26 11:07, Bryan C. Everly wrote: Josh, Any recommendations on what diagnostic information we could gather from Patrik or Daniel to better track this down? It's possible that verbose kernel messages may provide further insight. See FAQ 5.10. Thanks for the tip. I tried booting with boot bsd.rd -c and setting the verbose option mentioned at http://www.openbsd.org/faq/faq5.html#VerboseBoot in the UKC prompt. However, once the boot stalls no kernel messages are outputted until the boot eventually continues. Since there are so many lines outputted by the kernel I can not get hold of the complete dmesg on the next boot (the X220 is one of those machines where the dmesg buffer is not cleared between reboots and this is how I have been able to share it with the list) Here is the final part leading up to the hang in case someone finds it interesting: === uhub5 at uhub1 port 1 vendor 0x8087 product 0x0024 rev 2.00/0.00 addr 2 probing for uhub* uhub probe returned 0 probing for uhidev* uhidev probe returned 0 probing for umass* umass probe returned 0 probing for aue* aue probe returned 0 probing for axe* axe probe returned 0 probing for axen* axen probe returned 0 probing for smsc* smsc probe returned 0 probing for cue* cue probe returned 0 probing for kue* kue probe returned 0 probing for cdce* cdce probe returned 0 probing for mos* mos probe returned 0 probing for udav* udav probe returned 0 probing for upl* upl probe returned 0 probing for ugl* ugl probe returned 0 probing for url* url probe returned 0 probing for wi* wi probe returned 0 probing for atu* atu probe returned 0 probing for ural* ural probe returned 0 probing for rum* rum probe returned 0 probing for run* run probe returned 0 probing for zyd* zyd probe returned 0 probing for upgt* upgt probe returned 0 probing for urtw* urtw probe returned 0 probing for urtwn* urtwn probe returned 0 probing for rsu* rsu probe returned 0 probing for otus* otus probe returned 0 probing for uath* uath probe returned 0 probing for athn* athn probe returned 0 no winning probe probing for uhub* uhub probe returned 0 probing for uhidev* uhidev probe returned 0 probing for umass* umass probe returned 0 probing for aue* aue probe returned 0 probing for axe* axe probe returned 0 probing for axen* axen probe returned 0 probing for smsc* smsc probe returned 0 probing for cue* cue probe returned 0 probing for kue* kue probe returned 0 probing for cdce* cdce probe returned 0 probing for mos* mos probe returned 0 probing for udav* udav probe returned 0 probing for upl* upl probe returned 0 probing for ugl* ugl probe returned 0 probing for url* url probe returned 0 probing for wi* wi probe returned 0 probing for atu* atu probe returned 0 probing for ural* ural probe returned 0 probing for rum* rum probe returned 0 probing for run* run probe returned 0 probing for zyd* zyd probe returned 0 probing for upgt* upgt probe returned 0 probing for urtw* urtw probe returned 0 probing for urtwn* urtwn probe returned 0 probing for rsu* rsu probe returned 0 probing for otus* otus probe returned 0 probing for uath* uath probe returned 0 probing for athn* athn probe returned 0 no winning probe probing for uhub* uhub probe returned 0 probing for uhidev* uhidev probe returned 0 probing for umass* umass probe returned 0 probing for aue* aue probe returned 0 probing for axe* axe probe returned 0 probing for axen* axen probe returned 0 probing for smsc* smsc probe returned 0 probing for cue* cue probe returned 0 probing for kue* kue probe returned 0 probing for cdce* cdce probe returned 0 probing for mos* mos probe returned 0 probing for udav* udav probe returned 0 probing for upl* upl probe returned 0 probing for ugl* ugl probe returned 0 probing for url* url probe returned 0 probing for wi* wi probe returned 0 probing for atu* atu probe returned 0 probing for ural* ural probe returned 0 probing for rum* rum probe returned 0 probing for run* run probe returned 0 probing for zyd* zyd probe returned 0 probing for upgt* upgt probe returned 0 probing for urtw* urtw probe returned 0 probing for urtwn* urtwn probe returned 0 probing for rsu* rsu probe returned 0 probing for otus* otus probe returned 0 probing for uath* uath probe returned 0 probing for athn* athn probe returned 0 no winning probe probing for uhub* uhub probe returned 0 probing for uhidev* uhidev probe returned 0 probing for umass* umass probe returned 0 probing for aue* aue probe returned 0 probing for axe* axe probe returned 0 probing for axen* axen probe returned 0 probing for smsc* smsc probe returned 0 probing for cue* cue probe returned 0 probing for kue* kue probe returned 0 probing for cdce* cdce probe returned 0 probing for mos* mos probe returned 0
Re: weird logic that I can't understand is it a bug?
Ugh. never mind I seem to be coming from a tunnel to delta. Really really sorry. -peter On 08/01/15 18:39, Peter J. Philipp wrote: I have a network at home. Host delta has the IP 192.168.180.33 and host alpha has the IP 192.168.1.127. When I put these pf rules on host delta I would expect the packet to drop and log to pflog0. On delta: # pfctl -srules block return all pass all flags S/SA block return in on ! lo0 proto tcp from any to any port 6000:6010 block drop log on vio0 inet proto tcp from 192.168.0.0/18 to 127.0.0.1 port = block drop log on vio0 inet proto tcp from 192.168.1.0/24 to 127.0.0.1 port = 2223 block drop log on vio0 inet proto tcp from 192.168.179.10 to 127.0.0.1 port = 2224 block drop log on vio0 inet proto tcp from 192.168.0.0/18 to 192.168.180.33 port = block drop log on vio0 inet proto tcp from 192.168.1.0/24 to 192.168.180.33 port = 2223 block drop log on vio0 inet proto tcp from 192.168.179.10 to 192.168.180.33 port = 2224 On alpha: alpha$ telnet delta Trying 192.168.180.33... telnet: connect to address 192.168.180.33: Connection refused alpha$ telnet delta 2223 Trying 192.168.180.33... telnet: connect to address 192.168.180.33: Connection refused alpha$ telnet delta 2224 Trying 192.168.180.33... telnet: connect to address 192.168.180.33: Connection refused I would have expected a timeout on ports , and 2223 but it didn't happen and no log but the counter increased on the particular delta rules: @6 block drop log on vio0 inet proto tcp from 192.168.0.0/18 to 192.168.180.33 port = [ Evaluations: 3 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 12241 State Creations: 0 ] @7 block drop log on vio0 inet proto tcp from 192.168.1.0/24 to 192.168.180.33 port = 2223 [ Evaluations: 3 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 12241 State Creations: 0 ] @8 block drop log on vio0 inet proto tcp from 192.168.179.10 to 192.168.180.33 port = 2224 [ Evaluations: 3 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 12241 State Creations: 0 ] Let's take a look at 192.168.0.0/18, ipcalc says this: alpha# ipcalc 192.168.0.0/18 address : 192.168.0.0 netmask : 255.255.192.0 (0xc000) network : 192.168.0.0 /18 broadcast : 192.168.63.255 host min : 192.168.0.1 host max : 192.168.63.254 hosts/net : 16382 so alpha is in the 192.168.0.0/18 range, but it's not catching. When I negate that rule though and it says: block drop log on vio0 inet proto tcp from ! 192.168.0.0/18 to 192.168.180.33 port = block drop log on vio0 inet proto tcp from ! 192.168.1.0/24 to 192.168.180.33 port = 2223 I get this on alpha: alpha$ telnet delta Trying 192.168.180.33... ^C alpha$ telnet delta 2223 Trying 192.168.180.33... ^C I get the wanted timeout, but the logic is wrong. Tested on OpenBSD 5.7 and OpenBSD 5.8. If I'm wrong here please be gentle with the cluebat. Cheers, -peter
Re: panic: no appropriate pool
On 07/31/15 11:22, Mike Belopuhov wrote: On Fri, Jul 31, 2015 at 10:57 -0400, RD Thrush wrote: Synopsis: panic in sys/net/pf_lb.c Category: kernel Environment: System : OpenBSD 5.8 Details : OpenBSD 5.8 (GENERIC) #1047: Thu Jul 30 23:24:48 MDT 2015 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC Architecture: OpenBSD.i386 Machine : i386 Description: Repeatable crash after a few minutes with Jul 28,29 and 30 snapshots. Crashes w/ Jul 30 sp and mp snapshots w/ kern.pool_debug set to 0/1. The ddb transcript containing the following commands is appended: trace ps show registers show malloc show proc show uvmexp callout ps /w ps /a show bcstats show all pools show all pools /a show extents boot sync Please note that usbdevs and pcidump were done w/ the Jun 22 snapshot. acpi doesn't exist on this soekris 5501. How-To-Repeat: Install recent snapshot, sysmerge, reboot and wait a few minutes. Fix: Reboot with Jun 22 sp snapshot. According to cvs, the panic diagnostic was added Jul 20 to src/sys/net/pf_lb.c. Can you please try this diff. diff --git sys/net/pf_lb.c sys/net/pf_lb.c index 4e8d0cd..2c36b45 100644 --- sys/net/pf_lb.c +++ sys/net/pf_lb.c @@ -866,14 +866,13 @@ pf_postprocess_addr(struct pf_state *cur) } /* check for appropriate pool */ + memset(rpool, 0, sizeof(rpool)); if (nr-rdr.addr.type != PF_ADDR_NONE) rpool = nr-rdr; else if (nr-nat.addr.type != PF_ADDR_NONE) rpool = nr-nat; else if (nr-route.addr.type != PF_ADDR_NONE) rpool = nr-route; - else - panic(no appropriate pool); if (((rpool.opts PF_POOL_TYPEMASK) != PF_POOL_LEASTSTATES)) return (0); The patch ran without panic for 20+ hours. I wondered about the removal of the panic() statement so I tried another kernel that added the memset() but kept the panic() statement, as follows: cvs diff -u /usr/src/sys/net/pf_lb.c Index: /usr/src/sys/net/pf_lb.c === RCS file: /cvs/OpenBSD/src/sys/net/pf_lb.c,v retrieving revision 1.48 diff -u -p -u -r1.48 pf_lb.c --- /usr/src/sys/net/pf_lb.c20 Jul 2015 18:42:08 - 1.48 +++ /usr/src/sys/net/pf_lb.c1 Aug 2015 14:31:07 - @@ -866,6 +866,7 @@ pf_postprocess_addr(struct pf_state *cur } /* check for appropriate pool */ + memset(rpool, 0, sizeof(rpool)); if (nr-rdr.addr.type != PF_ADDR_NONE) rpool = nr-rdr; else if (nr-nat.addr.type != PF_ADDR_NONE) That kernel panic'd as before with no appropriate pool. Was the Jul 20 cvs commit (panic addition) incorrect? If not, it appears the memset() addition didn't fix the panic. I was able to take a crash dump with the above change and have attached a gdb transcript. The stack is apparently damaged in the pf_postprocess_addr() function; however, I'm over my head at this point. How may I help further troubleshoot? obsd32:i386/tmp 3sudo gdb 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 i386-unknown-openbsd5.8. (gdb) file bsd.gdb Reading symbols from /usr/obj/i386/tmp/bsd.gdb...done. (gdb) target kvm bsd.1.core #0 0xd0557a78 in boot (howto=0) at ../../../../arch/i386/i386/machdep.c:2637 2637dumpsys(); (gdb) where #0 0xd0557a78 in boot (howto=0) at ../../../../arch/i386/i386/machdep.c:2637 #1 0xd03bafff in reboot (howto=0) at ../../../../kern/kern_xxx.c:69 #2 0xd037f462 in db_boot_crash_cmd (addr=Could not find the frame base for db_boot_crash_cmd. ) at ../../../../ddb/db_command.c:730 #3 0xd037fb44 in db_command (last_cmdp=0x0, cmd_table=0xd0b22dc0) at ../../../../ddb/db_command.c:260 #4 0xd037fd8f in db_command_loop () at ../../../../ddb/db_command.c:643 #5 0xd0383f5a in db_trap (type=1, code=0) at ../../../../ddb/db_trap.c:94 #6 0xd0553e8c in kdb_trap (type=1, code=0, regs=0xf5233d8c) at ../../../../arch/i386/i386/db_interface.c:157 #7 0xd0565aa5 in trap (frame=0xf5233d8c) at ../../../../arch/i386/i386/trap.c:189 #8 0xd0200b12 in calltrap () #9 0xd0553c07 in Debugger () at ../../../../arch/i386/i386/db_interface.c:359 #10 0xd03c9741 in panic (fmt=0xd09a51d1 no appropriate pool) at ../../../../kern/subr_prf.c:214 #11 0xd03701ef in pf_postprocess_addr (cur=Variable cur is not available. ) at ../../../../net/pf_lb.c:877 #12
weird logic that I can't understand is it a bug?
I have a network at home. Host delta has the IP 192.168.180.33 and host alpha has the IP 192.168.1.127. When I put these pf rules on host delta I would expect the packet to drop and log to pflog0. On delta: # pfctl -srules block return all pass all flags S/SA block return in on ! lo0 proto tcp from any to any port 6000:6010 block drop log on vio0 inet proto tcp from 192.168.0.0/18 to 127.0.0.1 port = block drop log on vio0 inet proto tcp from 192.168.1.0/24 to 127.0.0.1 port = 2223 block drop log on vio0 inet proto tcp from 192.168.179.10 to 127.0.0.1 port = 2224 block drop log on vio0 inet proto tcp from 192.168.0.0/18 to 192.168.180.33 port = block drop log on vio0 inet proto tcp from 192.168.1.0/24 to 192.168.180.33 port = 2223 block drop log on vio0 inet proto tcp from 192.168.179.10 to 192.168.180.33 port = 2224 On alpha: alpha$ telnet delta Trying 192.168.180.33... telnet: connect to address 192.168.180.33: Connection refused alpha$ telnet delta 2223 Trying 192.168.180.33... telnet: connect to address 192.168.180.33: Connection refused alpha$ telnet delta 2224 Trying 192.168.180.33... telnet: connect to address 192.168.180.33: Connection refused I would have expected a timeout on ports , and 2223 but it didn't happen and no log but the counter increased on the particular delta rules: @6 block drop log on vio0 inet proto tcp from 192.168.0.0/18 to 192.168.180.33 port = [ Evaluations: 3 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 12241 State Creations: 0 ] @7 block drop log on vio0 inet proto tcp from 192.168.1.0/24 to 192.168.180.33 port = 2223 [ Evaluations: 3 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 12241 State Creations: 0 ] @8 block drop log on vio0 inet proto tcp from 192.168.179.10 to 192.168.180.33 port = 2224 [ Evaluations: 3 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 12241 State Creations: 0 ] Let's take a look at 192.168.0.0/18, ipcalc says this: alpha# ipcalc 192.168.0.0/18 address : 192.168.0.0 netmask : 255.255.192.0 (0xc000) network : 192.168.0.0 /18 broadcast : 192.168.63.255 host min : 192.168.0.1 host max : 192.168.63.254 hosts/net : 16382 so alpha is in the 192.168.0.0/18 range, but it's not catching. When I negate that rule though and it says: block drop log on vio0 inet proto tcp from ! 192.168.0.0/18 to 192.168.180.33 port = block drop log on vio0 inet proto tcp from ! 192.168.1.0/24 to 192.168.180.33 port = 2223 I get this on alpha: alpha$ telnet delta Trying 192.168.180.33... ^C alpha$ telnet delta 2223 Trying 192.168.180.33... ^C I get the wanted timeout, but the logic is wrong. Tested on OpenBSD 5.7 and OpenBSD 5.8. If I'm wrong here please be gentle with the cluebat. Cheers, -peter
Re: panic: no appropriate pool
On Sat, Aug 01, 2015 at 08:46:00PM +0200, Mike Belopuhov wrote: On 1 August 2015 at 19:20, RD Thrush openbsd-t...@thrush.com wrote: The patch ran without panic for 20+ hours. Thanks for testing! I wondered about the removal of the panic() statement so I tried another kernel that added the memset() but kept the panic() statement, as follows: [snip] That kernel panic'd as before with no appropriate pool. Well of course. Not all rules are rdr/nat/route-to. Was the Jul 20 cvs commit (panic addition) incorrect? It has served it's purpose well: it has found this bug. But panic'ing here in general is of course incorrect. If not, it appears the memset() addition didn't fix the panic. It did, clearly. You can run your setup again (-: I was able to take a crash dump with the above change and have attached a gdb transcript. The stack is apparently damaged in the pf_postprocess_addr() function; however, I'm over my head at this point. How may I help further troubleshoot? You're slightly overanalyzing here: panic has caught the unhandled case, but it's not needed per se. The code directly after the panic assumes rpool is set. Something is clearly wrong in the pf code if this triggers. Without a pf.conf it is hard to guess as to why this triggers...
Re: panic: no appropriate pool
On 1 August 2015 at 19:20, RD Thrush openbsd-t...@thrush.com wrote: The patch ran without panic for 20+ hours. Thanks for testing! I wondered about the removal of the panic() statement so I tried another kernel that added the memset() but kept the panic() statement, as follows: [snip] That kernel panic'd as before with no appropriate pool. Well of course. Not all rules are rdr/nat/route-to. Was the Jul 20 cvs commit (panic addition) incorrect? It has served it's purpose well: it has found this bug. But panic'ing here in general is of course incorrect. If not, it appears the memset() addition didn't fix the panic. It did, clearly. You can run your setup again (-: I was able to take a crash dump with the above change and have attached a gdb transcript. The stack is apparently damaged in the pf_postprocess_addr() function; however, I'm over my head at this point. How may I help further troubleshoot? You're slightly overanalyzing here: panic has caught the unhandled case, but it's not needed per se.
Re: panic: no appropriate pool
On 08/01/15 14:46, Mike Belopuhov wrote: On 1 August 2015 at 19:20, RD Thrush openbsd-t...@thrush.com wrote: The patch ran without panic for 20+ hours. Thanks for testing! I wondered about the removal of the panic() statement so I tried another kernel that added the memset() but kept the panic() statement, as follows: [snip] That kernel panic'd as before with no appropriate pool. Well of course. Not all rules are rdr/nat/route-to. Was the Jul 20 cvs commit (panic addition) incorrect? It has served it's purpose well: it has found this bug. But panic'ing here in general is of course incorrect. Fair enough. I'll run with your patch until a snapshot includes it. If not, it appears the memset() addition didn't fix the panic. It did, clearly. You can run your setup again (-: I was able to take a crash dump with the above change and have attached a gdb transcript. The stack is apparently damaged in the pf_postprocess_addr() function; however, I'm over my head at this point. How may I help further troubleshoot? You're slightly overanalyzing here: panic has caught the unhandled case, but it's not needed per se. Thanks for the explanation.
problem to install OpenBSD 5.7 on iMAC G5 (1.6Ghz)
Hello, I can't install OpenBSD on iMac G5, when I booted on cd with the command : boot cd:,ofwboot \5.7\macppc\bsd.rd The boot started and stopped quickly with the message : Loading ELF OpenBSD/macppc BOOT 1.3 boot cannot open /ht/pci@5/ata-6/disk@0:/etc/random.seed: No such file or directory booting /ht/pci@5/ata-6/disk@0:\5.7\macppc\bsd.rd: open /ht/pci@5/ata-6/disk@0:\5.7\macppc\bsd.rd: No such file or directory failed(2). will try /bsd Turning timeout off. boot The acces path is invalid, the correct access path is /ht/pci@5/ata-6/disk@0:2, I tried an USB install and had the same problem. I tried to boot with boot /ht/pci@5/ata-6/disk@0:2,ofwboot \5.7\macppc\bsd.rd command, and the result was the same. Do you have a solution, please ? Thanks. Laurent Masson
Re: problem to install OpenBSD 5.7 on iMAC G5 (1.6Ghz)
I have an old slot loader imac I had a problem installing to eons ago, not the same machine but it's also macppc. I chalked it up to lack of sufficient RTFM and buried it in a closet somewhere. I don't at all remember what the issue was and I don't believe it'll even attempt to boot off USB but I can crank out a 5.7 CD and give that install a go again tomorrowish. On 8/1/15, Laurent Masson l.mas...@laposte.net wrote: Hello, I can't install OpenBSD on iMac G5, when I booted on cd with the command : boot cd:,ofwboot \5.7\macppc\bsd.rd The boot started and stopped quickly with the message : Loading ELF OpenBSD/macppc BOOT 1.3 boot cannot open /ht/pci@5/ata-6/disk@0:/etc/random.seed: No such file or directory booting /ht/pci@5/ata-6/disk@0:\5.7\macppc\bsd.rd: open /ht/pci@5/ata-6/disk@0:\5.7\macppc\bsd.rd: No such file or directory failed(2). will try /bsd Turning timeout off. boot The acces path is invalid, the correct access path is /ht/pci@5/ata-6/disk@0:2, I tried an USB install and had the same problem. I tried to boot with boot /ht/pci@5/ata-6/disk@0:2,ofwboot \5.7\macppc\bsd.rd command, and the result was the same. Do you have a solution, please ? Thanks. Laurent Masson
