rpcbind compilation problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It appears that SVN rev 203972 added this .. @@ -185,6 +178,8 @@ addrmerge(struct netbuf *caller, char *s if (ifsa == NULL || ifsa->sa_family != hint_sa->sa_family || !(ifap->ifa_flags & IFF_UP)) continue; + if (!addr_is_bound(ifsa)) + continue; if (!(ifap->ifa_flags & IFF_LOOPBACK) && !listen_addr(ifsa)) continue; .. which breaks the compilation as there is no prototype for addr_is_bound(), imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkt7LpMACgkQQv9rrgRC1JKMAgCfcg359BXTEnXIbkzKydnrZGbN 5bYAoJ5XbrMtNlHfWJ9nxKkxEz2QTtUG =FOvd -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Virtualbox
On Wed, February 24, 2010 10:38, Bernhard Froehlich wrote: > I've got the new patch from Alexander Eichner now. It's currently untested > on newer kernels so could someone please test it on an affected kernel? > > http://pastebin.ca/1808177 > (linefeeds from the patch are dos so beware!) > > beat@ has already commited it to our vbox testing repository so you can > get the virtualbox 3.1.4 port with the new patch included from: I grabbed it from SVN and it works just fine here - thanks! imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Error 127.0.0.1: no route to host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/09/10 21:00, Doug Barton wrote: > On 03/09/10 12:14, Li, Qing wrote: >> This error was caused by my commit r204902 from yesterday. >> >> Please try patch at >> >> http://people.freebsd.org/~qingli/route.h.diff > > This doesn't appear to be committed yet, is it still the best fix? Even with this patch, I can't ping the ipv4 address at the other end of an openvpn tunnel :-( imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuXjkAACgkQQv9rrgRC1JLSgwCeP1DbEdkiI4tLyteNhHS4q1yM u4YAn0qdGCZLPDRsiRWlXRzyG1Wl4wlA =L4+B -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Error 127.0.0.1: no route to host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/10 12:18, Li, Qing wrote: > Could you please provide me with more information, such as your > ifconfig and netstat output? What's the error message? With or without r204902, I do not see any difference in ifconfig or netstat output. Addresses and routes are added as normal. Without the route.h patch, I can't ping 127.0.0.1 or the local or remote address of the OpenVPN tunnel (on tap0). In fact, you can't even build OpenVPN from ports as it'll fail its self-test. With the route.h patch, I can ping all local addresses but not the far end of the tunnel. Backing out r204902 restores normal operation of the tunnel. > Asking the obvious question, you updated to r204902? FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r204949M: Wed Mar 10 07:22:22 EST 2010 The 'M' signifies only that I've added my Nikon camera to the usbdev list and added aquirk for it, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuYA0cACgkQQv9rrgRC1JL0bgCgqte+e7snRtr9uA/u0q5XaYLm OvoAn0o6Att5R8I2da8HyNiZnDCT/NHQ =BW8c -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
sys/dev/siba/siba_core.c fails compilation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If compiling -current without debugging enabled, this module fails with
a warning about unused variables (warnings treated as errors).
The attached patch allows compilation to proceed although I'm not
convinced that it's entirely correct (duplicate evaluation of
device_get_ivars()),
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkuYO2QACgkQQv9rrgRC1JIuOQCfYzduyb55+itgjs7tLu4Y0EzE
u5oAoLu66AManNJuzvHl/B7eBECOVHfB
=wo8h
-END PGP SIGNATURE-
Index: sys/dev/siba/siba_core.c
===
--- sys/dev/siba/siba_core.c (revision 204990)
+++ sys/dev/siba/siba_core.c (working copy)
@@ -2031,11 +2031,8 @@
uint32_t
siba_dma_translation(device_t dev)
{
- struct siba_dev_softc *sd = device_get_ivars(dev);
- struct siba_softc *siba = sd->sd_bus;
-
- KASSERT(siba->siba_type == SIBA_TYPE_PCI,
- ("unsupported bustype %d\n", siba->siba_type));
+ KASSERT(device_get_ivars(dev)->sd_bus->siba_type == SIBA_TYPE_PCI,
+ ("unsupported bustype %d\n", device_get_ivars(dev)->sd_bus->siba_type));
return (SIBA_PCI_DMA);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Error 127.0.0.1: no route to host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/10 05:52, Li, Qing wrote: >I spent some time looking into the issue and found the problem >is the if_tap interface turns out to be one of those interfaces >that claims to be of IFT_ETHER type, but does not touch the >"if_link_state" variable. [ .. ] >Please try the new patch at > > http://people.freebsd.org/~qingli/ecmp-tap.diff > >Let me know how it works out for you. This solves all the noted issues - thanks! imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuY/BAACgkQQv9rrgRC1JLoxACeLApgw4GJzTpukzV4AHzp9ffm 4XwAn1GbXEojETUiXgAze7hIfgNcJSDF =5iWa -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic @r205276 (Fatal trap 12: page fault while in kernel mode)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/18/10 09:35, David Wolfskill wrote: > On first reboot after building & installing; yesterday (@r205249) was OK: [ .. ] > --- trap 0xc, eip = 0xc08853d6, esp = 0xc1420bb0, ebp = 0xc1420bd0 --- > _mtx_lock_flags(f000ff53,0,c0cd0df2,9a2,0,...) at _mtx_lock_flags+0x46 > zone_alloc_item(c0d9b5fc,c0cd12d4,c0cd11fb,c15ba000,c1420c88,...) at > zone_alloc_item+0x33 > hash_alloc(c15ba008,c0cd12d4,c0cd11fb,10,df,...) at hash_alloc+0x54 > keg_ctor(c15ba000,80,c1420c88,2,c1420c88,...) at keg_ctor+0x234 > zone_alloc_item(c0f7d380,180,c1420c88,c0d9b5fc,2000,...) at > zone_alloc_item+0x176 > zone_ctor(c0f7d380,180,c1420cd8,2,c0cd33f3,...) at zone_ctor+0x1d2 > uma_startup(c158b000,30,7ff6,3,c158b000,...) at uma_startup+0x1db > vm_page_startup(c15bb000,a,c1420d88,c084f0b6,0,...) at vm_page_startup+0x1d0 > vm_mem_init(0,141ec00,141ec00,141e000,1425000,...) at vm_mem_init+0x18 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > db> I suspect SVN 205266 (cache-line-size padding) has something to do with this but I'm still in the process of rebuilding with this change backed out .. imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuiL4kACgkQQv9rrgRC1JL5lQCeNyquBrUROs5vLw628/5pmXeF 09IAnjx2XyyQH/GuuGXB3R7CwtSZcWOf =wgGB -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic @r205276 (Fatal trap 12: page fault while in kernel mode)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/18/10 18:15, K. Macy wrote: > On Thu, Mar 18, 2010 at 1:38 PM, K. Macy wrote: I have the same panic. I'll try to revert 205266. >>> >>> Yes, 205266 is the culprit. >> >> Try updating. I've made the change a no-op until I can track the problem >> down. > > Do you all have either out-of-tree modules or modules that you did not > re-build when re-compiling your kernel? I did 'rm -rf /usr/obj/*' prior to building the kernel, rebuilt fusefs-kmod and all virtualbox modules as I didn't know what, if anything, may have been dependent on the knowledge of the kernel's structures, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuiq+oACgkQQv9rrgRC1JKDkgCfQqWTnLP8b63zEr+z5f9KfiVA 7eIAnR3guDIEY54VwPMA+TL0l6kUFyoi =B+08 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/22/10 17:27, Xin LI wrote: > Just a heads-up that zlib in base system (libz) has been updated to > 1.2.4. We tried to keep -HEAD as close as possible to the vendor > version, but there is some changes in its internal data structure, and > we did not use versioned symbols in the past, making shared library > version bump unavoidable. This breaks most (if not all) of the QT4-dependent ports for the lack of a definition of "off64_t". Adding .. /* * This is hard-configured for FreeBSD. */ #include #define z_off_t off_t #define off64_t off_t <- #ifndef _FILE_OFFSET_BITS #define _FILE_OFFSET_BITS 64 #endif .. to /usr/include/zconf.h seems to resolve this breakage, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuuK08ACgkQQv9rrgRC1JLsIwCeKKG6GT60PzaB1loO78R2S9Rr B10An3N/a8h6AZsHGQyoJQ5XBZgpFXP0 =9z9H -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Enabling AHCI on ICH7M
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My laptop manufacturer decided not to have AHCI included in the BIOS for this device, so I've been looking at what needs to happen in order to make this work. On this device, the BIOS doesn't even initialize BAR(5), so I need to start at that point .. from the Intel specs, it seemed fairly straight-forward: Give the AHCI sub-system a chunk of memory by initializing BAR(5), tell the PCI bridge(s) about it, reset the various config bits to flip from legacy to AHCI mode and leave the rest to what already exists in the ata-intel driver. My question, however, relates to the choice of memory: Can I simply call contigmalloc() to get a chunk of memory space whose physical address I can get with vtophys and leave the mapping for the PCI bridge to the existing call to bus_alloc_resource_any()? Is there a better method of finding some "free" physical space into which to put the ICH7M AHCI registers? imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAku6hhQACgkQQv9rrgRC1JJ9TgCghkR8j9xy2MbSNW1LSRMhzX6h AdAAnR6Ctnvyng4W9qRbP0vtM352SYSo =t6V3 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN rev 206755 breakage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The revision labeled:
SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo
Add another ICH7M chipset that works.
.. is incorrect and will cause some laptops to not boot.
Of the following identifiers:
{0x27c48086, 0x00, "Intel ICH7M", 0},
.. is the ICH7M in legacy and/or combined mode, i.e. *not* AHCI
{0x27c58086, 0x00, "Intel ICH7M", 0},
.. is the *same* chipset in AHCI mode,
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkvKKW4ACgkQQv9rrgRC1JIMUQCeKmCz2USYE2SSyb1X5f6tes7G
DtsAoKkjFHhlPdESsziKO92LCaxK6EI5
=JAg8
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN rev 206755 breakage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/10 18:05, Rui Paulo wrote: > On 17 Apr 2010, at 22:34, Michael Butler wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> The revision labeled: >> >> SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo >> >> Add another ICH7M chipset that works. >> >> .. is incorrect and will cause some laptops to not boot. > > So, in AHCI mode it doesn't find the disks? No - the driver fails to attach (ENXIO). I'm looking into which resource(s) it either couldn't allocate or gain control. The BIOS on my Toshiba does not initialize BAR(5) and, in the most general case, combined mode (MAP.SMS=0b, MAP.MV=10b) is required as the hard-drive is SATA but the DVD+RW is PATA :-( imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvKMloACgkQQv9rrgRC1JJ4FACdHxDzzfGIwBS4XEnfPWGCs2Qb wSsAoJAV6q/b16joC9MylPS8ZbT2JB/b =IeOp -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SPOOFED: Re: SVN rev 206755 breakage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/18/10 01:57, Alexander Motin wrote: > More important probably would be `pciconf -lvcb`. > > Intel controllers after ICH6 change both ID and set of resources, > depending on AHCI enabled in BIOS. There is separate set of IDs for > controllers with AHCI enabled. As I can see, Linux handles ID 0x27c4 as > non-AHCI SATA. If for some reason this ID could be used for both modes > (I have doubts), we may try to set AHCI_Q_NOFORCE flag to make driver > check PCI class/subclass, if it is correct there. > atap...@pci0:0:31:2:class=0x010180 card=0xff101179 chip=0x27c48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled bar [20] = type I/O Port, range 32, base 0x18b0, size 16, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 When AHCI is enabled, the device ID changes to 0x27c5. In this case, the probe succeeds but, since MSE is not set, the allocation of memory-IO space to BAR(5) is futile and the reset fails since it addresses undecoded space. Thus the attach fails, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvLCyoACgkQQv9rrgRC1JK3UQCfXG1K3B7kOo35koBWdTohYt7/ qygAoM0kn0ZSYeD5P0Hu7kr3ci+otV3m =sk9Y -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN rev 206755 breakage
On 04/19/10 02:30, Alexander Motin wrote:
> Rui Paulo wrote:
>> On 18 Apr 2010, at 14:05, Alexander Motin wrote:
>>> Most of AHCI controllers could also work as usual PCI ATA, but not every
>>> PCI ATA could work as AHCI. It would be nice to compare `pciconf -lvbc`
>>> output in both working (Rui) and not working (Michael) cases.
>>
>> ah...@pci0:0:31:2: class=0x01018f card=0x72708086 chip=0x27c48086 rev=0x02
>> hdr=0x00
>> vendor = 'Intel Corporation'
>> device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller'
>> class = mass storage
>> subclass = ATA
>
>^^^
> It doesn't report itself as AHCI.
>
>> bar [10] = type I/O Port, range 32, base 0x20d8, size 8, enabled
>> bar [14] = type I/O Port, range 32, base 0x20fc, size 4, enabled
>> bar [18] = type I/O Port, range 32, base 0x20d0, size 8, enabled
>> bar [1c] = type I/O Port, range 32, base 0x20f8, size 4, enabled
>> bar [20] = type I/O Port, range 32, base 0x2020, size 16, enabled
>> bar [24] = type Memory, range 32, base 0x90445000, size 1024, enabled
>
> This resource (BAR(5)) is absent on Michael's system. It is needed to
> work in AHCI mode, but not required for legacy PCI ATA. Probably some
> kind of BIOS magic in your case makes it appear in this mode with this
> chip ID.
More for my own amusement than anything, I came up with an _horrible_
patch to force my ICH7M into AHCI mode (attached). It has two issues:
1) I haven't figured out how to automagically determine which
address(es) I can use without colliding with anything else. Simply
letting bus_allocate_any() decide where to point BAR(5) doesn't appear
to work. I suspect I have to dig through the SMAP stuff to find out what
the BIOS has already claimed and use something outside of those ranges.
2) Since my laptop has both a SATA drive and a PATA DVD-R/W, the
manufacturer commissioned a BIOS which brings the ICH7M up in "combined
mode" with D31-F1 completely disabled. Since it can't (per Intel spec)
be re-enabled without a "platform reset", flipping into AHCI mode
effectively removes the DVD.
However - on the "up side", I now get NCQ ;-)
ahci0: port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18b0-0x18bf
at device 31.2 on pci0
ahci0: BAR(5): 0xf0d44400 AHCI_CAP: 0xdf12ff03 PI: 0x1
pcib0: matched entry for 0.31.INTB
pcib0: slot 31 INTB hardwired to IRQ 19
ahci0: [MPSAFE]
ahci0: [ITHREAD]
ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier supported
ahci0: Caps: 64bit NCQ MPS SS ALP AL CLO 1.5Gbps PM PMD SSC PSC
32cmd 4ports
ahci0: Caps2:
ahcich0: at channel 0 on ahci0
ahcich0: [MPSAFE]
ahcich0: [ITHREAD]
ahcich0: Caps:
[ .. ]
ada0 at ahcich0 bus 0 scbus1 target 0 lun 0
ada0: ATA-8 SATA 2.x device
ada0: Serial Number K82BT89256VDGEOM: new disk ada0
ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C)
*** sys/dev/ahci/ahci.c.origSat Apr 24 21:36:42 2010
--- sys/dev/ahci/ahci.c Sun Apr 25 21:30:57 2010
***
*** 126,131
--- 126,132
{0x26838086, 0x00, "Intel ESB2",0},
{0x27c18086, 0x00, "Intel ICH7",0},
{0x27c38086, 0x00, "Intel ICH7",0},
+ {0x27c48086, 0x00, "Intel ICH7M", 0},
{0x27c58086, 0x00, "Intel ICH7M", 0},
{0x27c68086, 0x00, "Intel ICH7M", 0},
{0x28218086, 0x00, "Intel ICH8",0},
***
*** 321,331
--- 322,353
ctlr->quirks = ahci_ids[i].quirks;
resource_int_value(device_get_name(dev),
device_get_unit(dev), "ccc", &ctlr->ccc);
+
+ #define AHCI_MEM_HACK 0xF0D44400 /* 0xf0d443ff is the last used by
others on Toshiba A105 */
+
+ /* Need to set the SCRAE bit and ensure SCRD not set */
+ pci_write_config(dev, 0x94, (pci_read_config(dev, 0x94, 4) | 0x200) &
~0x4000, 4);
+ /* enable MSE */
+ pci_write_config(dev, 0x4, (pci_read_config(dev, 0x4, 2) | 2), 2);
+ pci_write_config(dev, 0x24, AHCI_MEM_HACK, 4);
+ pci_write_config(dev, 0x90, 0x40, 1); /* AHCI + non-combined */
+
+ /* allocate a free memory window for BAR(5) */
+ ctlr->r_rid = PCIR_BAR(5);
+ bus_set_resource(dev, SYS_RES_MEMORY, ctlr->r_rid, AHCI_MEM_HACK,
0x400);
+
/* if we have a memory BAR(5) we are likely on an AHCI part */
ctlr->r_rid = PCIR_BAR(5);
if (!(ctlr->r_mem = bus_alloc_resource_any(dev, SYS_RES_MEMORY,
&ctlr->r_rid, RF_ACTIVE)))
return ENXIO;
+
+ /* enable ICH7M ports in AHCI space */
+ ATA_OUTL(ctlr->r_mem, AHCI_PI, ATA_INL(ctlr->r_mem, AHCI_PI) | 5);
+ #if 0
+ device_printf(dev, "BAR(5): 0x%lx AHCI_CAP: 0x%lx PI: 0x%lx\n",
(unsigned long)pci_read_config(dev, 0x24, 4),
+ (unsigned long)ATA_INL(ctlr->r_mem, 0), (unsigned
long)ATA_INL(ctlr->r_mem, AHCI_PI));
+ #end
Re: Panic @r207433: "System call fork returning with the following locks held"
On 04/30/10 18:33, K. Macy wrote: > How much memory do you have? I haven't been checking code in without > testing it, but clearly my system behaves a bit differently. > > Please try 207452. Building this now although .. > On Fri, Apr 30, 2010 at 2:42 PM, Manfred Antar wrote: >> At 02:21 PM 4/30/2010, K. Macy wrote: >>> On Fri, Apr 30, 2010 at 12:38 PM, K. Macy wrote: > Sadly, it doesn't do it for me .. lockd start-up causes a panic on a > "sleeping thread". Do I need to do a buildworld as well as kernel? > We're calling vm_pageout_flush with the page queue lock held in vm_object_page_collect_flush. I'll have a fix in soon. >>> >>> Please try updating to 207451 .. mine worked with this in place. For reference, 4GB RAM of which only 2990MB is usable on a Toshiba A105 laptop :-( imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
softupdate with journal panic
While updating sysutils/coreutils port on -current as of this morning (SVN r211550), I noted a panic during the directory rename config test. I disabled the journal and the test succeeded without a panic. Abbreviated core.txt is attached, imb toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.4 Sat Aug 21 13:27:54 EDT 2010 FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRENT #22 r211550M: Sat Aug 21 07:49:50 EDT 2010 r...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] 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-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x20:0xc08da5c5 stack pointer = 0x28:0xe8d65870 frame pointer = 0x28:0xe8d65878 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 49855 (conftest) trap number = 12 panic: page fault cpuid = 1 Uptime: 4h35m14s Physical memory: 3049 MB Dumping 305 MB: 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc066b627 in boot (howto=260) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:416 #2 0xc066ba18 in panic (fmt=0x104 ) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:590 #3 0xc098a5cf in trap_fatal (frame=0xe8d65830, eva=40) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:941 #4 0xc098a939 in trap_pfault (frame=0xe8d65830, usermode=0, eva=24) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:854 #5 0xc098adc7 in trap (frame=0xe8d65830) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:529 #6 0xc097363c in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:166 #7 0xc08da5c5 in free_jremref (jremref=0x0) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:3569 #8 0xc08e4ef3 in cancel_diradd (dap=0xce4d1e40, dirrem=0xcba243c0, jremref=0x0, dotremref=0xc9c0d440, dotdotremref=0x0) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:6774 #9 0xc08e514f in newdirrem (bp=0xda12ecec, dp=0xc9c0d440, ip=0xcd20a32c, isrmdir=1, prevdirremp=0xe8d65914) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:7197 #10 0xc08e560b in softdep_setup_directory_change (bp=0xda12ecec, dp=0xcd354a6c, ip=0xcd20a32c, newinum=10389760, isrmdir=1) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:7263 #11 0xc08f8c76 in ufs_dirrewrite (dp=0xcd354a6c, oip=0xcd20a32c, newinum=10389760, newtype=4, isrmdir=1) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_lookup.c:1304 #12 0xc0904757 in ufs_rename (ap=0xe8d65be8) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_vnops.c:1429 #13 0xc09a7287 in VOP_RENAME_APV (vop=0xc0ab7720, a=0xe8d65be8) at vnode_if.c:1474 #14 0xc070daeb in kern_renameat (td=0xc7117b00, oldfd=-100, old=0x8048511 , newfd=-100, new=0x8048505 , pathseg=UIO_USERSPACE) at vnode_if.h:636 #15 0xc070db51 in kern_rename (td=0xc7117b00, from=0x8048511 , to=0x8048505 , pathseg=UIO_USERSPACE) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:3574 #16 0xc070db7c in rename (td=0xc7117b00, uap=0xe8d65cec) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:3551 #17 0xc06a93c7 in syscallenter (td=0xc7117b00, sa=0xe8d65ce4) at /usr/home/imb/svn/head/sys/kern/subr_trap.c:319 #18 0xc098a99c in syscall (frame=0xe8d65d28) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1056 #19 0xc09736a1 in Xint0x80_syscall () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:264 #20 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sleep/Lenovo SL410
On 08/23/10 21:49, Matt wrote: > Please note atrtc0 error in dmesg? [ .. ] > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > atrtc0: [FILTER] I get this on a Toshiba A105 but it doesn't seem to hurt anything, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: softupdate with journal panic
On 08/23/10 17:12, Kostik Belousov wrote:
> On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote:
>> On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote:
>>> While updating sysutils/coreutils port on -current as of this morning
>>> (SVN r211550), I noted a panic during the directory rename config test.
>>>
>>
>> Your problem seems identical to this report:
>>
>> http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC
>>
> I believe that dotdotremref in this case is legitimately NULL. With this
> assumption, the following patch would help.
Confirmed - with the patch below, it works as expected; thanks!
imb
>
> diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c
> index b666c0f..65e5255 100644
> --- a/sys/ufs/ffs/ffs_softdep.c
> +++ b/sys/ufs/ffs/ffs_softdep.c
> @@ -6770,7 +6794,8 @@ cancel_diradd(dap, dirrem, jremref, dotremref,
> dotdotremref)
> mkdir->md_jaddref = NULL;
> if (mkdir->md_state & MKDIR_PARENT) {
> if (cancel_jaddref(jaddref, NULL,
> - &dirrem->dm_jwork) == 0) {
> + &dirrem->dm_jwork) == 0 &&
> + dotdotremref != NULL) {
> free_jremref(dotdotremref);
> dotdotremref = NULL;
> }
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r212281 breaks KDE
For the last week, on and off, I've been looking for something that caused KDE to be horridly unstable, i.e. machine freezes with and without a core-dump. Removing r212281 (and r212282) restores that stability. Is there a race condition that this update exposes by reducing lock strength? The most common failure with this code included produces a back-trace similar to the one attached, imb toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.0 Sat Sep 11 15:33:22 EDT 2010 FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRENT #5 r212466M: Sat Sep 11 10:10:59 EDT 2010 r...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] 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-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x22c fault code = supervisor read, page not present instruction pointer = 0x20:0xc066705a stack pointer = 0x28:0xe944b7f8 frame pointer = 0x28:0xe944b810 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1938 (kdeinit4) trap number = 12 panic: page fault cpuid = 0 Uptime: 2m33s Physical memory: 3049 MB Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc06760f7 in boot (howto=260) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:416 #2 0xc06764e8 in panic (fmt=0x104 ) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:590 #3 0xc09950ff in trap_fatal (frame=0xe944b7b8, eva=40) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:980 #4 0xc0995469 in trap_pfault (frame=0xe944b7b8, usermode=0, eva=556) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:893 #5 0xc09958f7 in trap (frame=0xe944b7b8) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:568 #6 0xc097e16c in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:168 #7 0xc066705a in _mtx_lock_sleep (m=0xc81c26e8, tid=3343885696, opts=0, file=0x0, line=0) at /usr/home/imb/svn/head/sys/kern/kern_mutex.c:369 #8 0xc09385d8 in vnode_create_vobject (vp=0xc825a330, isize=512, td=0xc74fa580) at /usr/home/imb/svn/head/sys/vm/vnode_pager.c:111 #9 0xc0904751 in ufs_lookup_ino (vdp=0xc825a330, vpp=0xe944bb40, cnp=0xe944bb54, dd_ino=0x0) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_lookup.c:260 #10 0xc0905370 in ufs_lookup (ap=0xe944b97c) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_lookup.c:215 #11 0xc06f9cc6 in vfs_cache_lookup (ap=0xe944ba08) at vnode_if.h:80 #12 0xc09b2811 in VOP_LOOKUP_APV (vop=0xc0ac7480, a=0xe944ba08) at vnode_if.c:123 #13 0xc0700e89 in lookup (ndp=0xe944bb28) at vnode_if.h:54 #14 0xc070218c in namei (ndp=0xe944bb28) at /usr/home/imb/svn/head/sys/kern/vfs_lookup.c:268 #15 0xc0711513 in kern_statat_vnhook (td=0xc74fa580, flag=0, fd=-100, path=0x2b2aa050 , pathseg=UIO_USERSPACE, sbp=0xe944bbe4, hook=0) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2352 #16 0xc07116b7 in kern_statat (td=0xc74fa580, flag=0, fd=-100, path=0x2b2aa050 , pathseg=UIO_USERSPACE, sbp=0xe944bbe4) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2333 #17 0xc07117db in kern_stat (td=0xc74fa580, path=0x2b2aa050 , pathseg=UIO_USERSPACE, sbp=0xe944bbe4) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2325 #18 0xc071186f in stat (td=0xc74fa580, uap=0xe944bcec) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2294 #19 0xc06b4087 in syscallenter (td=0xc74fa580, sa=0xe944bce4) at /usr/home/imb/svn/head/sys/kern/subr_trap.c:319 #20 0xc09954cc in syscall (frame=0xe944bd28) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1095 #21 0xc097e1d1 in Xint0x80_syscall () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:266 #22 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ___ freebsd-curr
Re: r212281 breaks KDE
On 09/12/10 12:19, Kostik Belousov wrote: > On Sun, Sep 12, 2010 at 10:42:57AM -0400, Michael Butler wrote: >> >> Removing r212281 (and r212282) restores that stability. Is there a race >> condition that this update exposes by reducing lock strength? [ .. ] > Does the following change make any difference to you ? It made it worse :-( "Frozen" just as X tries to take over the display, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
something missing from r215781? (if_igb)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seems there are a couple of defines missing from an e1000_hw.h ===> igb (all) [ .. snip .. ] /usr/home/imb/svn/head/sys/modules/igb/../../dev/e1000/if_igb.c:142: error: 'E1000_DEV_ID_DH89XXCC_SERDES' undeclared here (not in a function) /usr/home/imb/svn/head/sys/modules/igb/../../dev/e1000/if_igb.c:143: error: 'E1000_DEV_ID_DH89XXCC_SGMII' undeclared here (not in a function) *** Error code 1 1 error -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzsWX4ACgkQQv9rrgRC1JLk8ACbB6TesvKtbbHL55qyFTBIEYYf 3zUAoKEx2CJSWoYh/gp+XAvA+9uWaGZL =DHTC -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on amd64/amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/26/10 19:00, FreeBSD Tinderbox wrote: [ .. ] > cc1: warnings being treated as errors > /src/sys/dev/ichwd/ichwd.c: In function 'ichwd_attach': > /src/sys/dev/ichwd/ichwd.c:526: warning: implicit declaration of function > 'ich_read_tco_2' > /src/sys/dev/ichwd/ichwd.c:526: warning: nested extern declaration of > 'ich_read_tco_2' > *** Error code 1 This should likely be changed to 'ichwd_read_tco_2' imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzwTZsACgkQQv9rrgRC1JJ9AgCfTHDoDq9jOJ8iUPV6X7Y0KOMu XWAAn1BdwIWvjXJDmm+rcbrtMo153anE =ll7Z -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
kern_sysctl.c compilation failure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Seems that 'treat warnings as errors' snags on this .. patch attached,
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAkz0B/YACgkQQv9rrgRC1JKLBgCeNhKn2W6Z2XFN/zt70PbFhKbP
eHcAoIwI0Iz0g5TmU/pjbnG8zlcY6a1y
=a/KQ
-END PGP SIGNATURE-
*** src/sys/kern/kern_sysctl.c~ Mon Nov 29 14:02:22 2010
--- src/sys/kern/kern_sysctl.c Mon Nov 29 14:32:56 2010
***
*** 845,851
sysctl_sysctl_name2oid(SYSCTL_HANDLER_ARGS)
{
char *p;
! int error, oid[CTL_MAXNAME], len;
struct sysctl_oid *op = 0;
if (!req->newlen)
--- 845,851
sysctl_sysctl_name2oid(SYSCTL_HANDLER_ARGS)
{
char *p;
! int error, oid[CTL_MAXNAME], len = 0;
struct sysctl_oid *op = 0;
if (!req->newlen)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kern_sysctl.c compilation failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/10 15:25, Matthew Fleming wrote: > On Mon, Nov 29, 2010 at 12:07 PM, Michael Butler > wrote: > Seems that 'treat warnings as errors' snags on this .. patch attached, > >> Which compiler are you using? I didn't have any trouble with this >> file on a make universe last night... > >> There's nothing wrong with the patch; I'd just like to understand why >> you see an error and I do not. gcc complains of 'len' being used uninitialized after SVN r216059, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEUEARECAAYFAkz0DykACgkQQv9rrgRC1JLWNQCY/ZlpeKnLBH80N4X/ENSbqLqo bQCgqFld9e7+eK2sntXzOcqe5y8e2j0= =NiUc -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How a full fsck screwed up my SU+J filesystem
On 12/01/10 19:30, Kirk McKusick wrote:
[ .. snip .. ]
>
> Thanks all: Garrett for the report, Peter for the way to reproduce
> the problem, and Kostik for a fix. I have copied Jeff so that he can
> confirm that Kostik's fix is the appropriate thing to do. And I will
> take a look at fsck to see if I can make it a bit more paranoid about
> removing .sujournal.
>
> Kirk McKusick
There's another case that SU+J fails and the patch has not yet been
committed .. specifically, when configure tries to do a directory rename
test .. as below ..
I am uncertain but it seems that 'dump -L' exhibits a similar behaviour
.. completely hung on me at 1am this morning :-(
imb
Original Message
Subject: Re: softupdate with journal panic
Date: Tue, 24 Aug 2010 00:12:57 +0300
From: Kostik Belousov
To: Peter Holm
CC: Michael Butler ,Jeff Roberson
, curr...@freebsd.org
On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote:
> On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote:
> > While updating sysutils/coreutils port on -current as of this morning
> > (SVN r211550), I noted a panic during the directory rename config test.
> >
>
> Your problem seems identical to this report:
>
>
http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC
>
I believe that dotdotremref in this case is legitimately NULL. With this
assumption, the following patch would help.
*** src/sys/ufs/ffs/ffs_softdep.c~ Fri Aug 20 18:10:34 2010
--- src/sys/ufs/ffs/ffs_softdep.c Mon Aug 23 22:14:48 2010
***
*** 6770,6776
mkdir->md_jaddref = NULL;
if (mkdir->md_state & MKDIR_PARENT) {
if (cancel_jaddref(jaddref, NULL,
! &dirrem->dm_jwork) == 0) {
free_jremref(dotdotremref);
dotdotremref = NULL;
}
--- 6770,6777
mkdir->md_jaddref = NULL;
if (mkdir->md_state & MKDIR_PARENT) {
if (cancel_jaddref(jaddref, NULL,
! &dirrem->dm_jwork) == 0 &&
! dotdotremref != NULL) {
free_jremref(dotdotremref);
dotdotremref = NULL;
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lock-up with CPU busy at r217145; seems OK now at r217189
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/11 12:57, David Wolfskill wrote: > As usual, I have been tracking, building, & booting head daily on my > laptop for a while. > > Yesterday, having built head at r217090, I had updated to r217145, > built, and booted it OK. (I then booted from my stable/8 slice for the > rest of the day, as usual.) > > This morning, I updated to r217189, but on 3 out of 3 attempts to > perform "make -j4 buildworld" while running head at r217145, the > machine became unresponsive (while the fans were at top speed and > the screen remained lit). I have DDB in the kernel config, but was > unable to break to the debugger. I too have been seeing *really* odd things - dump randomly stops in the middle of a backup, automoc4 spawns a child during a KDE-4 build which turns into a zombie but is never seen to return and the build stalls - weird :-( Having checked out and built SVN revision 217202 - I'll try again .. imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0qAEgACgkQQv9rrgRC1JL9xwCgyHO8V8EE2wEXYpVifE4WjWve h/oAnjmJgG8GzJTF9v/mQxR3q+VllWZ7 =mMUo -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AHCI on ICH7
On 01/12/11 05:50, Anton Yuzhaninov wrote:
> Is it possible to get AHCI working on this controller:
>
> atap...@pci0:0:31:2:class=0x01018f card=0x72101462 chip=0x27c08086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage
> Controller'
> class = mass storage
> subclass = ATA
> bar [10] = type I/O Port, range 32, base 0xe880, size 8, enabled
> bar [14] = type I/O Port, range 32, base 0xe800, size 4, enabled
> bar [18] = type I/O Port, range 32, base 0xe480, size 8, enabled
> bar [1c] = type I/O Port, range 32, base 0xe400, size 4, enabled
> bar [20] = type I/O Port, range 32, base 0xe080, size 16, enabled
> cap 01[70] = powerspec 2 supports D0 D3 current D0
>
> BIOS show that AHCI 1.0 supported.
>
> I tried this patch with no success:
>
> --- sys/dev/ahci/ahci.c (revision 217301)
> +++ sys/dev/ahci/ahci.c (working copy)
> @@ -129,6 +129,7 @@
> {0x26838086, 0x00, "Intel ESB2",0},
> {0x27c18086, 0x00, "Intel ICH7",0},
> {0x27c38086, 0x00, "Intel ICH7",0},
> + {0x27c08086, 0x00, "Intel ICH7",0},
> {0x27c58086, 0x00, "Intel ICH7M", 0},
> {0x27c68086, 0x00, "Intel ICH7M", 0},
> {0x28218086, 0x00, "Intel ICH8",0},
Since this series is also supported in the ata-intel driver ..
{ ATA_I82801GB, 0, 0, 1, ATA_UDMA5, "ICH7" },
{ ATA_I82801GB_S1, 0, 0, 0, ATA_SA300, "ICH7" },
{ ATA_I82801GB_R1, 0, 0, 0, ATA_SA300, "ICH7" },
{ ATA_I82801GB_AH, 0, INTEL_AHCI, 0, ATA_SA300, "ICH7" },
{ ATA_I82801GBM_S1, 0, 0, 0, ATA_SA150, "ICH7M" },
{ ATA_I82801GBM_R1, 0, 0, 0, ATA_SA150, "ICH7M" },
{ ATA_I82801GBM_AH, 0, INTEL_AHCI, 0, ATA_SA150, "ICH7M" },
.. and it seems that PCIR_BAR(5) is already set as I/O, you could try
adding the INTEL_AHCI attribute to the entry for "ATA_I82801GB_S1",
which matches your chip-id and see what happens.
I have not tried this - please make sure you have a full backup first!
imb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AHCI on ICH7
On 01/12/11 10:44, Alexander Motin wrote:
[ .. snip .. ]
> PCIR_BAR(5) is not set in this case, only 0-4. It won't help.
Ugh! My bad .. the only other option is to adjust the entry in ahci.c
for that chip-id, find a suitably "free" memory window and do something
like the attached patch (set 'AHCI_MEM_HACK' to the base of whatever
window you can allocate).
I use this on a Toshiba A-105 laptop but, in the process, I lose the
ability to talk to the PATA DVD-drive (the reason why the manufacturer
set compatibility mode in the BIOS).
On the other hand it gets me the (huge!) benefits of NCQ ;-)
imb
*** src/sys/dev/ahci/ahci.c Sat May 22 12:07:12 2010
--- src/sys/dev/ahci/ahci.c-patched Sat May 22 08:10:36 2010
***
*** 129,134
--- 129,135
{0x26838086, 0x00, "Intel ESB2",0},
{0x27c18086, 0x00, "Intel ICH7",0},
{0x27c38086, 0x00, "Intel ICH7",0},
+ {0x27c48086, 0x00, "Intel ICH7M", 0},
{0x27c58086, 0x00, "Intel ICH7M", 0},
{0x27c68086, 0x00, "Intel ICH7M", 0},
{0x28218086, 0x00, "Intel ICH8",0},
***
*** 324,334
--- 325,353
ctlr->quirks = ahci_ids[i].quirks;
resource_int_value(device_get_name(dev),
device_get_unit(dev), "ccc", &ctlr->ccc);
+
+ #define AHCI_MEM_HACK 0xF0D44400 /* 0xf0d443ff is the last used by
others on Toshiba A105 */
+
+ /* Need to set the SCRAE bit and ensure SCRD not set */
+ pci_write_config(dev, 0x94, (pci_read_config(dev, 0x94, 4) | 0x200) &
~0x4000, 4);
+ /* enable MSE */
+ pci_write_config(dev, 0x4, (pci_read_config(dev, 0x4, 2) | 2), 2);
+ pci_write_config(dev, 0x24, AHCI_MEM_HACK, 4);
+ pci_write_config(dev, 0x90, 0x40, 1); /* AHCI + non-combined */
+
+ /* allocate a free memory window for BAR(5) */
+ ctlr->r_rid = PCIR_BAR(5);
+ bus_set_resource(dev, SYS_RES_MEMORY, ctlr->r_rid, AHCI_MEM_HACK,
0x400);
+
/* if we have a memory BAR(5) we are likely on an AHCI part */
ctlr->r_rid = PCIR_BAR(5);
if (!(ctlr->r_mem = bus_alloc_resource_any(dev, SYS_RES_MEMORY,
&ctlr->r_rid, RF_ACTIVE)))
return ENXIO;
+
+ /* enable ICH7M ports in AHCI space */
+ ATA_OUTL(ctlr->r_mem, AHCI_PI, ATA_INL(ctlr->r_mem, AHCI_PI) | 5);
+
/* Setup our own memory management for channels. */
ctlr->sc_iomem.rm_start = rman_get_start(ctlr->r_mem);
ctlr->sc_iomem.rm_end = rman_get_end(ctlr->r_mem);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
if_ether.c (svn revision 217315) breakage on i386
cc1: warnings being treated as errors /usr/home/imb/svn/head/sys/netinet/if_ether.c: In function 'in_arpinput': /usr/home/imb/svn/head/sys/netinet/if_ether.c:540: warning: format '%ld' expects type 'long int', but argument 3 has type 'unsigned int' *** Error code 1 .. where "unsigned int" is actually a "sizeof(struct in_addr)", imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
cosmetic nit in mmc.c
In the process of making the sdhci driver work with my laptop, I noted a cosmetic issue where the SD card's serial number is not correctly reported (it's always zero). Possible patch attached, imb Index: mmc.c === --- mmc.c (revision 217480) +++ mmc.c (working copy) @@ -749,7 +749,10 @@ uint32_t retval = bits[i] >> shift; if (size + shift > 32) retval |= bits[i - 1] << (32 - shift); - return (retval & ((1 << size) - 1)); +if (size < 32) + return (retval & ((1 << size) - 1)); + else + return (retval); } static void ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpi_resource bug?
On 02/14/11 10:29, Matthew Fleming wrote: >>> 1) should the length of the bcopy() be changed to either respect >>> res->Length or the actual length of the ACPI_RESOURCE_DATA for the >>> type? >> >> It should just use res->Length: > > Is there a guarantee that res->Length is <= sizeof(ACPI_RESOURCE) ? I don't know if it's related or a different bug .. If I run 'acpidump -t', I get a core-dump and .. [ .. snip .. ] /* MCFG: Length=60, Revision=1, Checksum=74, OEMID=INTEL, OEM Table ID=CALISTGA, OEM Revision=0x604, Creator ID=LOHR, Creator Revision=0x5a Base Address=0xe000 Segment Group=0x Start Bus=0 End Bus=255 */ /* TCPA: Length=50, Revision=1, Checksum=153, OEMID=PTLTD, OEM Table ID=CALISTGA, OEM Revision=0x604, Creator ID= PTL, Creator Revision=0x1 Class 0 Base Address 0x0 Length 65536 -268370093 0xc3e200f053ff00f053ff00f054ff00f0de9100f0 [] ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
rename on socket fails :-(
Just upgraded my mail-server to -current only to be greated by: Feb 18 16:26:00 mail authdaemond: modules="authpam", daemons=5 Feb 18 16:26:00 mail authdaemond: Installing libauthpam Feb 18 16:26:00 mail authdaemond: Installation complete: authpam Feb 18 16:26:00 mail authdaemond: /var/run/authdaemond/socket: Cross-device link Essentially, authdaemond creates /var/run/authdaemond/socket.tmp and then tries to rename it to the above. In releng7_4, this worked, on -current, it doesn't. What broke it? This is on a normal UFS2 + soft-updates file-system :-( imb pgpOcGMZOhYcE.pgp Description: PGP signature
Re: rename on socket fails :-(
On Sat, Feb 19, 2011 at 12:11:09AM +0200, Kostik Belousov wrote:
> On Fri, Feb 18, 2011 at 04:53:30PM -0500, michael butler wrote:
> > Just upgraded my mail-server to -current only to be greated by:
> >
> > Feb 18 16:26:00 mail authdaemond: modules="authpam", daemons=5
> > Feb 18 16:26:00 mail authdaemond: Installing libauthpam
> > Feb 18 16:26:00 mail authdaemond: Installation complete: authpam
> > Feb 18 16:26:00 mail authdaemond: /var/run/authdaemond/socket: Cross-device
> > link
> >
> > Essentially, authdaemond creates /var/run/authdaemond/socket.tmp and then
> > tries to rename it to the above. In releng7_4, this worked, on -current, it
> > doesn't. What broke it? This is on a normal UFS2 + soft-updates file-system
> > :-(
>
> Are you sure that /var/run/authdaemond/socket.tmp is
> renamed to /var/run/authdaemond/socket ? Can you show the
> ktrace/kdump output ?
The relevant section of ktrace.out is:
10905 authdaemond.bin CALL unlink(0xbfbfeadc)
10905 authdaemond.bin NAMI "/var/run/authdaemond/socket.tmp"
10905 authdaemond.bin RET unlink 0
10905 authdaemond.bin CALL bind(0x5,0xbfbfeada,0x6a)
10905 authdaemond.bin STRU struct sockaddr { AF_LOCAL,
/var/run/authdaemond/socket.tmp }
10905 authdaemond.bin NAMI "/var/run/authdaemond/socket.tmp"
10905 authdaemond.bin RET bind 0
10905 authdaemond.bin CALL listen(0x5,0x80)
10905 authdaemond.bin RET listen 0
10905 authdaemond.bin CALL
chmod(0xbfbfeadc,0x1ff)
10905 authdaemond.bin NAMI "/var/run/authdaemond/socket.tmp"
10905 authdaemond.bin RET chmod 0
10905 authdaemond.bin CALL rename(0xbfbfeadc,0x804b1c1)
10905 authdaemond.bin NAMI "/var/run/authdaemond/socket.tmp"
10905 authdaemond.bin NAMI "/var/run/authdaemond/socket"
10905 authdaemond.bin RET rename -1 errno 18 Cross-device link
I also made sure that the relevant components were properly linked against
the -current shared libs ..
imb@mail:/usr/local/libexec/courier-authlib> ldd authdaemond
authdaemond:
libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x2809a000)
libcourierauthcommon.so =>
/usr/local/lib/courier-authlib/libcourierauthcommon.so (0x280a2000)
libcourierauth.so =>
/usr/local/lib/courier-authlib/libcourierauth.so (0x280a6000)
libc.so.7 => /lib/libc.so.7 (0x280b1000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x281cb000)
imb@mail:/usr/local/libexec/courier-authlib> ldd
/usr/local/lib/courier-authlib/libcourierauth.so
/usr/local/lib/courier-authlib/libcourierauth.so:
libc.so.7 => /lib/libc.so.7 (0x2809a000)
imb@mail:/usr/local/libexec/courier-authlib> ldd
/usr/local/lib/courier-authlib/libcourierauthcommon.so
/usr/local/lib/courier-authlib/libcourierauthcommon.so:
libcourierauth.so =>
/usr/local/lib/courier-authlib/libcourierauth.so (0x281c5000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x281d)
libc.so.7 => /lib/libc.so.7 (0x2809a000)
imb@mail:/usr/local/libexec/courier-authlib> ldd /usr/local/lib/libltdl.so.7
/usr/local/lib/libltdl.so.7:
libc.so.7 => /lib/libc.so.7 (0x2809a000)
pgpIickAMoMiC.pgp
Description: PGP signature
Re: rename on socket fails :-(
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/18/11 18:22, Kostik Belousov wrote:
>
> The patch below fixed the bug for the test extracted from your kdump.
>
> diff --git a/sys/ufs/ufs/ufs_vnops.c b/sys/ufs/ufs/ufs_vnops.c
> index 084971e..34b1758 100644
> --- a/sys/ufs/ufs/ufs_vnops.c
> +++ b/sys/ufs/ufs/ufs_vnops.c
> @@ -1295,7 +1295,9 @@ relock:
> newparent = tdp->i_number;
> doingdirectory = 1;
> }
> - if (fvp->v_mountedhere != NULL || (tvp && tvp->v_mountedhere != NULL)) {
> + if ((fvp->v_type == VDIR && fvp->v_mountedhere != NULL) ||
> + (tvp != NULL && tvp->v_type == VDIR &&
> + tvp->v_mountedhere != NULL)) {
> error = EXDEV;
> goto unlockout;
> }
To confirm - this fixes the issue - thanks!
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAk1fHKMACgkQQv9rrgRC1JKt+ACgv6Cx9NVZapjDn0bMUskLs7jM
ym8An0YIQKWY0dcJ12qX9zV4c6ePzgD+
=JQxR
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Fwd: [head tinderbox] failure on .. SCTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Original Message Subject: [head tinderbox] failure on ia64/ia64 Date: Sat, 26 Feb 2011 18:55:22 GMT From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , >>> stage 3.2: building everything [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' [ .. snip .. ] While it's likely that this is not what the author intended, the attached patch will allow the kernel to be built, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1ph1wACgkQQv9rrgRC1JJ0kACfYcM/p4w/MoLLcxWENoeih8VN d60AnRmrl6AnWT59/vwQD9LzIN/1nJJx =CxgS -END PGP SIGNATURE- Index: sys/netinet/sctp.h === --- sys/netinet/sctp.h (revision 219070) +++ sys/netinet/sctp.h (working copy) @@ -42,6 +42,8 @@ #define SCTP_PACKED __attribute__((packed)) +#define SCTP_HAS_RTTCC 1 + /* * SCTP protocol - RFC2960. */ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ and "mount" reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/30/10 19:54, Ivan Voras wrote: > Shouldn't SU+J be visible in the output of "mount" somehow? I've just > enabled it on a root file system of a machine and while tunefs and > dumpfs report both soft-updates and SUJ are enabled (after reboot), the > "mount" command only shows "soft-updates". Alternative question: how to > verify is it active on a live file system? tunefs -p works even when the file-system is mounted in multi-user mode, e.g. i...@toshi:/home/imb> tunefs -p / tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f)16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwC/dQACgkQQv9rrgRC1JKzagCgiviuFD/uTunc5bYQvkjvnT0j p1IAn3OJ8af8W4Jjj34cZVUyX4EMDk32 =cw0I -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on ia64/ia64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/10/10 19:11, FreeBSD Tinderbox wrote:
> cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc
> -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src
> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
> -finline-limit=15000 --param inline-unit-growth=100 --param
> large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13
> -mfixed-range=f32-f127 -fpic -ffreestanding -Werror
> /src/sys/net80211/ieee80211_sta.c
> /src/sys/net80211/ieee80211_sta.c: In function 'sta_input':
> /src/sys/net80211/ieee80211_sta.c:587: error: expected ')' before '!' token
> *** Error code 1
I *think* this is supposed to be ..
if (HAS_SEQ(type) && !IEEE80211_IS_MULTICAST(wh->i_addr1)) {
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkwRdRsACgkQQv9rrgRC1JLQ9ACfVPINlwHR8g0hXt0wenp5esfj
FooAnidIAWqJr9fJ3wQ8nhtEZtj9d0VG
=errN
-END PGP SIGNATURE-
*** /usr/src/sys/net80211/ieee80211_sta.c~ Thu Jun 10 17:53:24 2010
--- /usr/src/sys/net80211/ieee80211_sta.c Thu Jun 10 19:15:42 2010
***
*** 584,590
}
IEEE80211_RSSI_LPF(ni->ni_avgrssi, rssi);
ni->ni_noise = nf;
! if (HAS_SEQ(type) !IEEE80211_IS_MULTICAST(wh->i_addr1)) {
uint8_t tid = ieee80211_gettid(wh);
if (IEEE80211_QOS_HAS_SEQ(wh) &&
TID_TO_WME_AC(tid) >= WME_AC_VI)
--- 584,590
}
IEEE80211_RSSI_LPF(ni->ni_avgrssi, rssi);
ni->ni_noise = nf;
! if (HAS_SEQ(type) && !IEEE80211_IS_MULTICAST(wh->i_addr1)) {
uint8_t tid = ieee80211_gettid(wh);
if (IEEE80211_QOS_HAS_SEQ(wh) &&
TID_TO_WME_AC(tid) >= WME_AC_VI)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: making dependencies breaks between r210462 and r210495?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/26/10 09:55, David Wolfskill wrote: > This is for GENERIC i386 kernel, running on head at r210462, sources > updated to r210495: [ .. ] > ===> usr.bin/kdump (depend) > sh /usr/src/usr.bin/kdump/mkioctls /usr/obj/usr/src/tmp/usr/include > ioctl.c > sh /usr/src/usr.bin/kdump/mksubr /usr/obj/usr/src/tmp/usr/include > > kdump_subr.c > :1:31: error: altq/altq.h:#define: No such file or directory This was a breakage in the new BSD grep .. 1) update your sources 2) cd /usr/src/usr.bin/grep 3) make clean all install 4) reattempt buildworld/buildkernel imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxNoB4ACgkQQv9rrgRC1JKK3QCeNh8jjA/AfMqoyX0e10cLu+iW cPEAn15ZvW0F+3hbPoUU9CRF2SEg0fgg =axny -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
k3b causing system freeze/panic
I have a custom kernel for my laptop which uses ATA_CAM rather than the
now aging ATA driver ..
In the case that the kernel compilation options KDB and DDB are enabled,
k3b will simply freeze. Without them, I managed to catch this panic:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0xbfbea376
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc04d96d7
stack pointer = 0x28:0xe6a92be4
frame pointer = 0x28:0xe6a92c10
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (irq15: ata1)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 3m18s
Physical memory: 3049 MB
Dumping 212 MB: 197 181 165 149 133 117 101 85 69 53 37 21 5
Reading symbols from /boot/modules/vboxdrv.ko...done.
Loaded symbols for /boot/modules/vboxdrv.ko
Reading symbols from /boot/modules/vboxnetflt.ko...done.
Loaded symbols for /boot/modules/vboxnetflt.ko
Reading symbols from /boot/modules/vboxnetadp.ko...done.
Loaded symbols for /boot/modules/vboxnetadp.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
#0 doadump () at pcpu.h:231
231 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:231
#1 0xc067bbe7 in boot (howto=260) at
/usr/home/imb/svn/head/sys/kern/kern_shutdown.c:416
#2 0xc067bff7 in panic (fmt=0x104 ) at
/usr/home/imb/svn/head/sys/kern/kern_shutdown.c:590
#3 0xc0998a1a in trap_fatal (frame=0xe6a92ba4, eva=40) at
/usr/home/imb/svn/head/sys/i386/i386/trap.c:945
#4 0xc0998d7f in trap_pfault (frame=0xe6a92ba4, usermode=0,
eva=3216941942) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:858
#5 0xc0999207 in trap (frame=0xe6a92ba4) at
/usr/home/imb/svn/head/sys/i386/i386/trap.c:533
#6 0xc09819ac in calltrap () at
/usr/home/imb/svn/head/sys/i386/i386/exception.s:166
#7 0xc04d96d7 in ata_pio_read (request=0xc7037424, length=18) at
cpufunc.h:217
#8 0xc04dae8f in ata_end_transaction (request=0xc7037424) at
/usr/home/imb/svn/head/sys/dev/ata/ata-lowlevel.c:392
#9 0xc04d70da in ata_interrupt_locked (data=Variable "data" is not
available.
) at /usr/home/imb/svn/head/sys/dev/ata/ata-all.c:548
#10 0xc04d7142 in ata_interrupt (data=0xc64b5400) at
/usr/home/imb/svn/head/sys/dev/ata/ata-all.c:512
#11 0xc065476a in intr_event_execute_handlers (p=0xc618b7f8,
ie=0xc61d3d00) at /usr/home/imb/svn/head/sys/kern/kern_intr.c:1220
#12 0xc0655e8d in ithread_loop (arg=0xc64bb4c0) at
/usr/home/imb/svn/head/sys/kern/kern_intr.c:1233
#13 0xc065236d in fork_exit (callout=0xc0655e27 ,
arg=0xc64bb4c0, frame=0xe6a92d28) at
/usr/home/imb/svn/head/sys/kern/kern_fork.c:843
#14 0xc0981a24 in fork_trampoline () at
/usr/home/imb/svn/head/sys/i386/i386/exception.s:273
It seems that, since this was an interrupt service of some form,
dropping into KDB isn't working .. however, by the time we get to
ata_pio_read something has gone awry with the buffer address in the
request ..
(kgdb) up 7
(kgdb) info args
request = (struct ata_request *) 0xc7037424
length = 18
(kgdb) print *request
$1 = {dev = 0x0, parent = 0xc6450700, unit = 0, u = {ata = {command = 3
'\003', feature = 0, count = 18, lba = 0}, atapi = {
ccb =
"\003\020\000\000\022\000\000\000\000\000\000\000\000\000\000", sense =
{error = 0 '\0', segment = 0 '\0', key = 0 '\0', cmd_info = 0,
sense_length = 0 '\0', cmd_specific_info = 0, asc = 0 '\0', ascq
= 0 '\0', replaceable_unit_code = 0 '\0', specific = 0 '\0', specific1 =
0 '\0',
specific2 = 0 '\0'}, saved_cmd = 0 '\0'}}, bytecount = 18,
transfersize = 18,
data = 0xbfbea376 , <--***
tag = 0, flags = 8,
dma = 0x0, status = 88 'X', error = 0 '\0', donecount = 0, result = 0,
callback = 0, done = {sema_mtx = {lock_object = {lo_name = 0x0, lo_flags
= 0, lo_data = 0,
lo_witness = 0x0}, mtx_lock = 0}, sema_cv = {cv_description =
0x0, cv_waiters = 0}, sema_waiters = 0, sema_value = 0}, retries = 0,
timeout = 30,
callout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0,
tqe_prev = 0xda0cd670}}, c_time = 227742, c_arg = 0xc7037424,
c_func = 0xc04dcf74 , c_lock = 0xc64b5574, c_flags =
22, c_cpu = 0}, task = {ta_running = 0x0, ta_link = {stqe_next = 0x0},
ta_pending = 0,
ta_priority = 0, ta_func = 0, ta_context = 0x0}, bio = 0x0, this =
0, composite = 0x0, driver = 0x0, chain = {tqe_next = 0x0, tqe_prev =
0x0}, ccb = 0xc6f7a000}
(kgdb) up 2
#9 0xc04d70da in ata_interrupt_locked (data=Variable "data" is not
available.
) at /usr/home/imb/svn/head/sys/dev/ata/ata-all.c:548
548 if (ch->hw.end_transaction(request) == ATA_OP_FINISHED) {
Current language: auto; currently c
(kgdb) print *ch
$3 = {dev = 0xc6450700, unit = 1, attached = 1, r_io = {{res =
0xc62d8ac0, offset = 0}, {res = 0xc62d8ac0, offset = 1}, {
Re: k3b causing system freeze/panic
On 07/28/10 04:27, Andriy Gapon wrote: > You do realize that ATA_CAM just (well, mostly) introduces a wrapper around > the > "now aging ATA driver" ? > No magic pixie dust to fix the bugs in it, but perhaps more ways to expose > them. Sadly, I still haven't been able to identify where the buffer address in the request structure is one of: left unset, gets lost or corrupted :-( Happens with k3b-kde4 too. I am assuming that this is as a consequence of the ATA_CAM code-path. I don't recall ever having this issue prior to switching disk names to "ada" from "ad", imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: k3b causing system freeze/panic
On 08/01/10 23:03, I wrote: > Sadly, I still haven't been able to identify where the buffer address in > the request structure is one of: left unset, gets lost or corrupted :-( > > Happens with k3b-kde4 too. I am assuming that this is as a consequence > of the ATA_CAM code-path. I don't recall ever having this issue prior to > switching disk names to "ada" from "ad", I can confirm this behaviour - switching back to the "ad" device and using atapicam to access the DVD works correctly. My only conclusion is that it's a regression in the ATA_CAM code-path, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
On 8/29/18 7:40 PM, John Baldwin wrote: > On 8/29/18 4:20 PM, Ian FREISLICH wrote: >> Hi >> >> I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP >> at line 84. My system is UP so I'm not compiling an SMP kernel. >> >> /usr/src/sys/x86/x86/intr_machdep.c:176:2: error: use of undeclared >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? >> interrupt_sorted = mallocarray(num_io_irqs, >> sizeof(*interrupt_sorted), >> ^~~~ >> interrupt_sources >> /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources' >> declared here >> static struct intsrc **interrupt_sources; >> ^ >> /usr/src/sys/x86/x86/intr_machdep.c:176:54: error: use of undeclared >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? >> interrupt_sorted = mallocarray(num_io_irqs, >> sizeof(*interrupt_sorted), > > Probably just needs #ifdef SMP around the mallocarray(). I'll test locallyon > a UP kernel config. > I see another problem after using Ian's workaround of moving the #ifdef SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) machine with only 512MB of RAM: Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
On 8/31/18 1:28 AM, Konstantin Belousov wrote: > On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: [ .. snip .. ] >> I see another problem after using Ian's workaround of moving the #ifdef >> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) >> machine with only 512MB of RAM: >> >> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed > > What is the kernel revision for "now". What was the previous revision > where the kstack allocation failures did not happen. > > Also, what is the workload ? Sorry for the delay. Any version at or after SVN r338360 would either a) not boot at all or b) crash shortly after boot with a swarm of messages as above. It was stable before that. Unfortunately, this machine is remote and, being as old as it is, has no remote console facility. 'nextboot' has been my savior ;-) It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces, local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a router/firewall with few actual applications running. As another data point, I manually reversed both SVN r338360 and r338415 (a related change) and it is now stable running at SVN r338520, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
On 9/8/18 3:43 PM, Konstantin Belousov wrote: > On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote: >> On 8/31/18 1:28 AM, Konstantin Belousov wrote: >>> On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: >> >> [ .. snip .. ] >> >>>> I see another problem after using Ian's workaround of moving the #ifdef >>>> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) >>>> machine with only 512MB of RAM: >>>> >>>> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed >>>> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed >>>> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed >>>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >>>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >>>> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed >>> >>> What is the kernel revision for "now". What was the previous revision >>> where the kstack allocation failures did not happen. >>> >>> Also, what is the workload ? >> >> Sorry for the delay. Any version at or after SVN r338360 would either a) >> not boot at all or b) crash shortly after boot with a swarm of messages >> as above. It was stable before that. >> >> Unfortunately, this machine is remote and, being as old as it is, has no >> remote console facility. 'nextboot' has been my savior ;-) >> >> It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces, >> local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an >> OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a >> router/firewall with few actual applications running. >> >> As another data point, I manually reversed both SVN r338360 and r338415 >> (a related change) and it is now stable running at SVN r338520, > > It is very unprobable. I do not see how could r338360 affect KVA allocation. > Double-check that you booted right kernels. > FreeBSD sarah.protected-networks.net 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #14 r338520M: Thu Sep 6 21:35:31 EDT 2018 'svn diff' reports the only changes being the two reversals I noted above, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: udp6: Page fault panics
On 9/15/18 8:04 PM, Larry Rosenman wrote: > I've got 2 of these: > > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0x7c > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80631428 > stack pointer = 0x28:0xfe00ca17c440 > frame pointer = 0x28:0xfe00ca17c480 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 1225 (isc-worker0003) > trap number = 12 > panic: page fault > cpuid = 4 > time = 1537050918 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00ca17c0f0 > vpanic() at vpanic+0x1a3/frame 0xfe00ca17c150 > panic() at panic+0x43/frame 0xfe00ca17c1b0 > trap_fatal() at trap_fatal+0x35f/frame 0xfe00ca17c200 > trap_pfault() at trap_pfault+0x49/frame 0xfe00ca17c260 > trap() at trap+0x2ba/frame 0xfe00ca17c370 > calltrap() at calltrap+0x8/frame 0xfe00ca17c370 > --- trap 0xc, rip = 0x80631428, rsp = 0xfe00ca17c440, rbp = > 0xfe00ca17c480 --- > selectroute() at selectroute+0x198/frame 0xfe00ca17c480 > in6_selectroute_fib() at in6_selectroute_fib+0xf/frame 0xfe00ca17c4a0 > ip6_output() at ip6_output+0xfd7/frame 0xfe00ca17c710 > udp6_send() at udp6_send+0x720/frame 0xfe00ca17c8d0 > sosend_dgram() at sosend_dgram+0x346/frame 0xfe00ca17c930 > kern_sendit() at kern_sendit+0x201/frame 0xfe00ca17c9d0 > sendit() at sendit+0x19e/frame 0xfe00ca17ca20 > sys_sendmsg() at sys_sendmsg+0x61/frame 0xfe00ca17ca80 > amd64_syscall() at amd64_syscall+0x272/frame 0xfe00ca17cbb0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00ca17cbb0 > --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x800be5a9a, rsp = > 0x7fffdf9fa468, rbp = 0x7fffdf9fa4a0 -- > - > Uptime: 35s [ .. snip .. ] This is likely another instance of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230950 I had similar, seemingly random panics on a nameserver I run and the only workaround I have so far is to revert SVNs r338257 and r338306 :-( imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
On 9/10/18 1:20 PM, John Baldwin wrote: > On 9/8/18 1:44 PM, Michael Butler wrote: >> On 9/8/18 3:43 PM, Konstantin Belousov wrote: >>> On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote: >>>> On 8/31/18 1:28 AM, Konstantin Belousov wrote: >>>>> On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: >>>> >>>> [ .. snip .. ] >>>> >>>>>> I see another problem after using Ian's workaround of moving the #ifdef >>>>>> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) >>>>>> machine with only 512MB of RAM: >>>>>> >>>>>> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed >>>>>> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed >>>>>> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed >>>>>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >>>>>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >>>>>> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed >>>>> >>>>> What is the kernel revision for "now". What was the previous revision >>>>> where the kstack allocation failures did not happen. >>>>> >>>>> Also, what is the workload ? >>>> >>>> Sorry for the delay. Any version at or after SVN r338360 would either a) >>>> not boot at all or b) crash shortly after boot with a swarm of messages >>>> as above. It was stable before that. >>>> >>>> Unfortunately, this machine is remote and, being as old as it is, has no >>>> remote console facility. 'nextboot' has been my savior ;-) >>>> >>>> It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces, >>>> local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an >>>> OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a >>>> router/firewall with few actual applications running. >>>> >>>> As another data point, I manually reversed both SVN r338360 and r338415 >>>> (a related change) and it is now stable running at SVN r338520, >>> >>> It is very unprobable. I do not see how could r338360 affect KVA >>> allocation. >>> Double-check that you booted right kernels. >>> >> >> FreeBSD sarah.protected-networks.net 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #14 >> r338520M: Thu Sep 6 21:35:31 EDT 2018 >> >> 'svn diff' reports the only changes being the two reversals I noted above, > > Can you get the output of 'x num_io_irqs' at the DDB prompt after the > panic? > SVN r338725 fixed this - thanks! :-) imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: udp6: Page fault panics
On 9/17/18 4:17 AM, Andrey V. Elsukov wrote:
> On 16.09.2018 03:04, Larry Rosenman wrote:
>> vpanic() at vpanic+0x1a3/frame 0xfe00ca17c150
>> panic() at panic+0x43/frame 0xfe00ca17c1b0
>> trap_fatal() at trap_fatal+0x35f/frame 0xfe00ca17c200
>> trap_pfault() at trap_pfault+0x49/frame 0xfe00ca17c260
>> trap() at trap+0x2ba/frame 0xfe00ca17c370
>> calltrap() at calltrap+0x8/frame 0xfe00ca17c370
>> --- trap 0xc, rip = 0x80631428, rsp = 0xfe00ca17c440, rbp =
>> 0xfe00ca17c480 ---
>> selectroute() at selectroute+0x198/frame 0xfe00ca17c480
>> in6_selectroute_fib() at in6_selectroute_fib+0xf/frame 0xfe00ca17c4a0
>> ip6_output() at ip6_output+0xfd7/frame 0xfe00ca17c710
>
> (kgdb) l *selectroute+0x198
> 0x80de14c8 is in selectroute
> (/home/devel/freebsd/base/head/sys/netinet6/in6_src.c:736).
> 731* Use a cached route if it exists and is valid, else try to
> allocate
> 732* a new one. Note that we should check the address family of
> the
> 733* cached destination, in case of sharing the cache with IPv4.
> 734*/
> 735 if (ro) {
> 736 if (ro->ro_rt &&
> 737 (!(ro->ro_rt->rt_flags & RTF_UP) ||
> 738((struct sockaddr *)(&ro->ro_dst))->sa_family !=
> AF_INET6 ||
> 739
> !IN6_ARE_ADDR_EQUAL(&satosin6(&ro->ro_dst)->sin6_addr,
> 740dst))) {
>
>> calltrap() at calltrap+0x8/frame 0xfe00c9d863e0
>> --- trap 0xc, rip = 0x80636b2b, rsp = 0xfe00c9d864b0, rbp =
>> 0xfe00c9d86710 ---
>> ip6_output() at ip6_output+0xeeb/frame 0xfe00c9d86710
>> udp6_send() at udp6_send+0x720/frame 0xfe00c9d868d0
> (kgdb) l *ip6_output+0xeeb
> 0x80de75bb is in ip6_output
> (/home/devel/freebsd/base/head/sys/netinet6/ip6_output.c:531).
> 526*/
> 527 if (inp) {
> 528 ro->ro_dst.sin6_family = AF_INET6;
> 529 RT_VALIDATE((struct route *)ro, &inp->inp_rt_cookie,
> fibnum);
> 530 }
> 531 if (ro->ro_rt && fwd_tag == NULL && (ro->ro_rt->rt_flags &
> RTF_UP) &&
> 532 ro->ro_dst.sin6_family == AF_INET6 &&
> 533 IN6_ARE_ADDR_EQUAL(&ro->ro_dst.sin6_addr, &ip6->ip6_dst)) {
> 534 rt = ro->ro_rt;
> 535 ifp = ro->ro_rt->rt_ifp;
>
> It looks like Ryan's assumption is correct and panics happen due to
> several threads use the same PCB and then route cache invalidation happens.
> https://lists.freebsd.org/pipermail/freebsd-net/2018-September/051563.html
>
> But IPv6 path also needs similar patch.
>
I can confirm that SVN r338804 resolves this issue,
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r339216 breaks ssh to i386 devices
With an i386 system, ssh sessions to the updated sshd fail with: sshd[28771]: fatal: mm_getpwnamallow: receive get struct passwd failed [preauth] This is reproducible on both real hardware and in a VM running an i386 build, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r339216 breaks ssh to i386 devices
On 10/9/18 1:43 PM, Marek Zarychta wrote: > W dniu 09.10.2018 o 01:28, Dag-Erling Smørgrav pisze: >> Please try the attached patch. I expect it to fix i386. If it also >> fixes arm32, all the better, although I don't quite see why it would. > > I have connected serial console to affected box and upgraded system from > patched sources. I am sorry to say that this patch doesn't solve the > issue for 32-bit ARM (RPi2). Still sshd terminates session with the > error "fatal: mm_getpwnamallow: receive get struct passwd failed [preauth]". > My experience is similar - there maybe another 32/64-bit issue :-( imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r339216 breaks ssh to i386 devices
On 10/9/18 3:18 PM, Dag-Erling Smørgrav wrote: > Michael Butler writes: >> Marek Zarychta writes: >>> I have connected serial console to affected box and upgraded system >>> from patched sources. I am sorry to say that this patch doesn't >>> solve the issue for 32-bit ARM (RPi2). Still sshd terminates session >>> with the error "fatal: mm_getpwnamallow: receive get struct passwd >>> failed [preauth]". >> My experience is similar - there maybe another 32/64-bit issue :-( > > Correct, there is a size_t being passed as as an u64 as well. That > explains why arm32 was broken too, and not just i386. The quick fix is > to replace size_t with u_int64_t in sshbuf_get_passwd(), on line 513 of > sshbuf-getput-basic.c (with my previous patch applied). I have a full > patch in the pipeline. I can confirm that SVN r339263 solves this for me - thanks! imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: OpenSSL 1.1.1 in 12.0
On 10/9/18 5:34 PM, Glen Barber wrote: > OpenSSL has been updated to version 1.1.1 as of r339270. > > It is important to rebuild third-party packages before running: > > # make -C /usr/src delete-old && make -C /usr/src delete-old-libs > > Thank you for your patience while this work was in progress, and thank > you to all involved for their hard work in getting things ready for this > update. So far, I've found two ports that will no longer build. They are: net-mgmt/net-snmp security/opencryptoki I simply chose those that were linked to /usr/lib/libssl.so.8 where the openssl update creates libssl.so.9. There may be more I haven't found yet, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: OpenSSL 1.1.1 in 12.0
On 10/9/18 11:14 PM, Michael Butler wrote: > On 10/9/18 5:34 PM, Glen Barber wrote: >> OpenSSL has been updated to version 1.1.1 as of r339270. >> >> It is important to rebuild third-party packages before running: >> >> # make -C /usr/src delete-old && make -C /usr/src delete-old-libs >> >> Thank you for your patience while this work was in progress, and thank >> you to all involved for their hard work in getting things ready for this >> update. > > So far, I've found two ports that will no longer build. They are: > > net-mgmt/net-snmp > security/opencryptoki > > I simply chose those that were linked to /usr/lib/libssl.so.8 where the > openssl update creates libssl.so.9. There may be more I haven't found yet, add multimedia/ffmpeg to this list .. imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
-current build failure after SVN r340130
===> libexec/dma/dma-mbox-create (all)
Building
/usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/capsicum_helpers.h:161:1:
error: all paths through this function will call itself
[-Werror,-Winfinite-recursion]
{
^
1 error generated.
*** [dma-mbox-create.o] Error code 1
make[5]: stopped in /usr/src/libexec/dma/dma-mbox-create
The broken function seems to call itself .. ??
static __inline int
caph_fcntls_limit(int fd, uint32_t fcntlrights)
{
if (caph_fcntls_limit(fd, fcntlrights) < 0 && errno != ENOSYS)
return (-1);
return (0);
}
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -current build failure after SVN r340130
Confirmed to be fixed by SVN r340134 - thanks!
On 11/4/18 1:50 PM, Michael Butler wrote:
> ===> libexec/dma/dma-mbox-create (all)
> Building
> /usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
> In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/capsicum_helpers.h:161:1:
> error: all paths through this function will call itself
> [-Werror,-Winfinite-recursion]
> {
> ^
> 1 error generated.
> *** [dma-mbox-create.o] Error code 1
>
> make[5]: stopped in /usr/src/libexec/dma/dma-mbox-create
>
> The broken function seems to call itself .. ??
>
> static __inline int
> caph_fcntls_limit(int fd, uint32_t fcntlrights)
> {
>
> if (caph_fcntls_limit(fd, fcntlrights) < 0 && errno != ENOSYS)
> return (-1);
>
> return (0);
> }
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
building release images broken?
Any clues as to what's broken here? I'm trying to build a CD and/or DVD image. My tree is at SVN r340525. -- >>> Kernel build for GENERIC completed on Sat Nov 17 22:19:48 UTC 2018 -- make -C /usr/src/release obj make -C /usr/src/release ftp cdrom dvdrom memstick.img mini-memstick.img `ftp' is up to date. sh /usr/src/release/amd64/mkisoimages.sh -b 13_0_CURRENT_amd64_CD disc1.iso disc1 200+0 records in 200+0 records out 819200 bytes transferred in 0.003692 secs (221856674 bytes/sec) newfs_msdos: cannot get number of sectors per track: Operation not supported newfs_msdos: cannot get number of heads: Operation not supported /dev/md0: 1557 sectors in 1557 FAT12 clusters (512 bytes/cluster) BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512 Sectors=1600 Media=0xf8 FATsecs=5 SecPerTrack=63 Heads=1 HiddenSecs=0 mkdir: efi: File exists *** Error code 1 Stop. make[1]: stopped in /usr/src/release *** Error code 1 Stop. make: stopped in /usr/src/release ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
building release images broken?
On 11/17/18 5:35 PM, Michael Butler wrote: > Any clues as to what's broken here? I'm trying to build a CD and/or DVD > image. > > My tree is at SVN r340525. > > -- >>>> Kernel build for GENERIC completed on Sat Nov 17 22:19:48 UTC 2018 > -- > make -C /usr/src/release obj > make -C /usr/src/release ftp cdrom dvdrom memstick.img mini-memstick.img > `ftp' is up to date. > sh /usr/src/release/amd64/mkisoimages.sh -b 13_0_CURRENT_amd64_CD > disc1.iso disc1 > 200+0 records in > 200+0 records out > 819200 bytes transferred in 0.003692 secs (221856674 bytes/sec) > newfs_msdos: cannot get number of sectors per track: Operation not supported > newfs_msdos: cannot get number of heads: Operation not supported > /dev/md0: 1557 sectors in 1557 FAT12 clusters (512 bytes/cluster) > BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512 > Sectors=1600 Media=0xf8 FATsecs=5 SecPerTrack=63 Heads=1 HiddenSecs=0 > mkdir: efi: File exists > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src/release > *** Error code 1 > > Stop. > make: stopped in /usr/src/release Answering my own question .. seems there's one 'mkdir' without the '-p' option .. this fixes it .. *** release/amd64/mkisoimages.sh~ Mon Oct 22 16:41:26 2018 --- release/amd64/mkisoimages.shSun Nov 18 11:42:09 2018 *** *** 46,52 dd if=/dev/zero of=efiboot.img bs=4k count=200 device=`mdconfig -a -t vnode -f efiboot.img` newfs_msdos -F 12 -m 0xf8 /dev/$device ! mkdir efi mount -t msdosfs /dev/$device efi mkdir -p efi/efi/boot cp -p "$BASEBITSDIR/boot/loader.efi" efi/efi/boot/bootx64.efi --- 46,52 dd if=/dev/zero of=efiboot.img bs=4k count=200 device=`mdconfig -a -t vnode -f efiboot.img` newfs_msdos -F 12 -m 0xf8 /dev/$device ! mkdir -p efi mount -t msdosfs /dev/$device efi mkdir -p efi/efi/boot cp -p "$BASEBITSDIR/boot/loader.efi" efi/efi/boot/bootx64.efi ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
kernel panic in wireless-related sysctl walk
With 'device iwn' and all the related wireless bits compiled into a custom kernel for a laptop, executing 'sysctl -a' yields a kernel panic of the form .. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x809bf22c stack pointer = 0x28:0xfe0097fb7660 frame pointer = 0x28:0xfe0097fb7670 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 11053 (sysctl) trap number = 12 panic: page fault cpuid = 1 time = 1547129798 Uptime: 3d10h27m14s Dumping 3840 out of 16258 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% [ .. ] (kgdb) #0 doadump (textdump=) at pcpu.h:230 #1 0x808704eb in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0x80870920 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:877 #3 0x80870753 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:804 #4 0x80c63b5b in trap_fatal (frame=0xfe0097fb75a0, eva=8) at /usr/src/sys/amd64/amd64/trap.c:929 #5 0x80c63f10 in trap_pfault (frame=0xfe0097fb75a0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:839 #6 0x80c632be in trap (frame=0xfe0097fb75a0) at /usr/src/sys/amd64/amd64/trap.c:441 #7 0x80c40535 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #8 0x809bf22c in amrr_node_stats (ni=0xfe008cf83000, s=0xfe0097fb76f0) at /usr/src/sys/net80211/ieee80211_amrr.c:464 #9 0x809ef9f4 in ieee80211_ratectl_sysctl_stats_node_iter ( arg=0xfe0097fb76f0, ni=0xfe008cf83000) at ieee80211_ratectl.h:170 #10 0x809e42b0 in ieee80211_iterate_nodes_vap ( nt=, vap=, f=0x809ef9b0 , arg=0xfe0097fb76f0) at /usr/src/sys/net80211/ieee80211_node.c:2558 #11 0x809ef941 in ieee80211_ratectl_sysctl_stats ( oidp=, arg1=, arg2=, req=) at /usr/src/sys/net80211/ieee80211_ratectl.c:99 #12 0x8087f8ab in sysctl_root_handler_locked (oid=0xf80016697d00, arg1=0xf80007bef000, arg2=0, req=0xfe0097fb7840, tracker=0xfe0097fb77b8) at /usr/src/sys/kern/kern_sysctl.c:166 #13 0x8087ef4f in sysctl_root (arg1=0xf80007bef000, arg2=0, req=0xfe0097fb7840) at /usr/src/sys/kern/kern_sysctl.c:2080 #14 0x8087f5ca in userland_sysctl (td=0xf80007d96000, name=0xfe0097fb7900, namelen=4, old=, oldlenp=, inkernel=, new=0x0, newlen=0, retval=0xfe0097fb7968, flags=0) at /usr/src/sys/kern/kern_sysctl.c:2175 #15 0x8087f40f in sys___sysctl (td=0xf80007d96000, uap=0xf80007d963c0) at /usr/src/sys/kern/kern_sysctl.c:2110 #16 0x80c64742 in amd64_syscall (td=0xf80007d96000, traced=0) at subr_syscall.c:135 #17 0x80c40e1d in fast_syscall_common () at /usr/src/sys/amd64/amd64/exception.S:504 What other data should I capture to assist in identifying and resolving this? imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r342962 breaks i386 kernel build
As below: Building /usr/obj/usr/src/i386.i386/sys/SARAH/kern_thr.o Building /usr/obj/usr/src/i386.i386/sys/SARAH/kern_thread.o --- kern_thread.o --- /usr/src/sys/kern/kern_thread.c:105:1: error: static_assert failed "struct thread KBI td_frame" _Static_assert(offsetof(struct thread, td_frame) == 0x2e8, ^ ~~ /usr/src/sys/kern/kern_thread.c:107:1: error: static_assert failed "struct thread KBI td_emuldata" _Static_assert(offsetof(struct thread, td_emuldata) == 0x334, ^ ~ 2 errors generated. *** [kern_thread.o] Error code 1 imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel panic in wireless-related sysctl walk
On 1/12/19 5:12 AM, O. Hartmann wrote: > Am Thu, 10 Jan 2019 22:22:05 +0100 > "O. Hartmann" schrieb: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 > >> Am Thu, 10 Jan 2019 12:02:15 -0800 >> Cy Schubert schrieb: > >>> I'm not able to reproduce this at the moment. I can confirm that SVN r342966 fixes it for me - thanks! imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r345102 breaks drm-current-kmod
As below .. --- drm_atomic_helper.o --- In file included from /usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/drivers/gpu/drm/drm_atomic_helper.c:28: In file included from /usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/include/drm/drmP.h:139: /usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/drivers/gpu/drm/drm_os_freebsd.h:124:9: error: 'IS_ALIGNED' macro redefined [-Werror,-Wmacro-redefined] #define IS_ALIGNED(x, y)(((x) & ((y) - 1)) == 0) ^ /usr/src/sys/compat/linuxkpi/common/include/linux/kernel.h:133:9: note: previous definition is here #define IS_ALIGNED(x, a)(((x) & ((__typeof(x))(a) - 1)) == 0) ^ --- drm_atomic.o --- In file included from /usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/drivers/gpu/drm/drm_atomic.c:29: In file included from /usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/include/drm/drmP.h:139: /usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/drivers/gpu/drm/drm_os_freebsd.h:124:9: error: 'IS_ALIGNED' macro redefined [-Werror,-Wmacro-redefined] #define IS_ALIGNED(x, y)(((x) & ((y) - 1)) == 0) ^ /usr/src/sys/compat/linuxkpi/common/include/linux/kernel.h:133:9: note: previous definition is here #define IS_ALIGNED(x, a)(((x) & ((__typeof(x))(a) - 1)) == 0) ^ --- drm_atomic_helper.o --- 1 error generated. *** [drm_atomic_helper.o] Error code 1 make[3]: stopped in /usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/drm imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r345236 fails to account for lib32 build pieces
buildworld fails with .. --- cddl/lib__L --- Building /usr/obj/usr/src/amd64.amd64/obj-lib32/cddl/lib/libzpool/vdev_initialize.o --- lib__L --- Building /usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libsm/fscanf.o Building /usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libsm/fseek.o --- all_subdir_lib/libomp --- --- kmp_runtime.pico --- /usr/src/contrib/openmp/runtime/src/kmp_runtime.cpp:8130:2: error: "Unknown or unsupported OS" #error "Unknown or unsupported OS" ^ 1 error generated. *** [kmp_runtime.pico] Error code 1 make[5]: stopped in /usr/src/lib/libomp .ERROR_TARGET='kmp_runtime.pico' imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r345675 breaks kernel build with fuse
As below .. an unused variable when KASSERT is not enabled .. Building /usr/obj/usr/src/amd64.amd64/sys/TOSHI/fuse_ipc.o --- fuse_ipc.o --- /usr/src/sys/fs/fuse/fuse_ipc.c:223:22: error: unused variable 'ftick' [-Werror,-Wunused-variable] struct fuse_ticket *ftick = mem; ^ 1 error generated. *** [fuse_ipc.o] Error code 1 imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r345859: libxo broke netstat?
Something changed in libxo that causes 'netstat -i' to segfault as below: imb@toshi:/usr/src/usr.bin/netstat> lldb /usr/obj/usr/src/amd64.amd64/usr.bin/netstat/netstat (lldb) target create "/usr/obj/usr/src/amd64.amd64/usr.bin/netstat/netstat" Current executable set to '/usr/obj/usr/src/amd64.amd64/usr.bin/netstat/netstat' (x86_64). (lldb) run -i Process 65948 launching Process 65948 launched: '/usr/obj/usr/src/amd64.amd64/usr.bin/netstat/netstat' (x86_64) NameMtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Process 65948 stopped * thread #1, name = 'netstat', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x0008002987ad libxo.so.0`___lldb_unnamed_symbol30$$libxo.so.0 + 669 libxo.so.0`___lldb_unnamed_symbol30$$libxo.so.0: -> 0x8002987ad <+669>: movsbl (%r12), %eax 0x8002987b2 <+674>: movslq %eax, %rbx 0x8002987b5 <+677>: movq 0xac04(%rip), %r13 0x8002987bc <+684>: testl %eax, %eax (lldb) bt * thread #1, name = 'netstat', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) * frame #0: 0x0008002987ad libxo.so.0`___lldb_unnamed_symbol30$$libxo.so.0 + 669 frame #1: 0x000800294e09 libxo.so.0`___lldb_unnamed_symbol24$$libxo.so.0 + 1401 frame #2: 0x000800293b91 libxo.so.0`___lldb_unnamed_symbol22$$libxo.so.0 + 609 frame #3: 0x000800293df0 libxo.so.0`xo_emit + 256 frame #4: 0x00212dc5 netstat`intpr + 1669 frame #5: 0x00217ecf netstat`main + 2431 frame #6: 0x0021210f netstat`__fini_array_end + 271 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r346025: ZFS filesystems do not mount anymore
On 2019-04-09 09:30, O. Hartmann wrote: > On Tue, 9 Apr 2019 10:42:47 +0200 (CEST) > Trond Endrestøl wrote: > >> On Tue, 9 Apr 2019 10:06+0200, Trond Endrestøl wrote: >> >>> On Mon, 8 Apr 2019 19:58+0200, O. Hartmann wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, after a bunch of updates this weekend, mounting ZFS filesystems on CURRENT r346025 doesn't work anymore at boot time when ZFS is built-in-kernel. zfs_enable="YES" is set in /etc/rc.conf. After the system has booted, mounting all ZFS filesystems via "zfs mount -a" operates as expected and all filesystems are available as usual. >>> >>> I blame r346017: >>> >>> Trying to mount root from zfs:zroot/ROOT/20190409-r346017 [] >>> Setting hostuuid: 7b624d1c-4bc3-e2cb-4ac2-6487a4b4774c. >>> Setting hostid: 0xf9071336. >>> interface zfsctrl.1 already present in the KLD 'kernel'! >>> linker_load_file: /boot/kernel/zfs.ko - unsupported file type >>> kldload: an error occurred while loading module zfs. Please check dmesg(8) >>> for more details. /etc/rc: WARNING: Unable to load kernel module zfs >>> Starting file system checks: >>> Mounting local filesystems:. >>> interface zfsctrl.1 already present in the KLD 'kernel'! >>> linker_load_file: /boot/kernel/zfs.ko - unsupported file type >>> kldload: an error occurred while loading module zfs. Please check dmesg(8) >>> for more details. /etc/rc: WARNING: Unable to load kernel module zfs >>> interface zfsctrl.1 already present in the KLD 'kernel'! >>> linker_load_file: /boot/kernel/zfs.ko - unsupported file type >>> kldload: an error occurred while loading module zfs. Please check dmesg(8) >>> for more details. /etc/rc: WARNING: Unable to load kernel module zfs >>> ELF ldconfig path: /lib /usr/lib /usr/lib/compat >>> 32-bit compatibility ldconfig path: /usr/lib32 >>> >>> [...] >>> >>> Creating and/or trimming log files. >>> Starting syslogd. >>> Apr 9 09:48:32 freebsd-head-zfs syslogd: /var/log/security: >>> No such file or directory Setting date via ntp. >>> 9 Apr 09:48:38 ntpdate[1073]: step time server 2001:W:X:Y::Z offset >>> -0.992370 sec No core dumps found. >>> Clearing /tmp (X related). >>> Updating motd:. >>> Mounting late filesystems:mount: /usr/compat/linux: No such file or >>> directory mount: /usr/compat/linux: No such file or directory >>> mount: /usr/compat/linux: No such file or directory >>> mount: /usr/compat/linux: No such file or directory >>> . >>> Mounting /etc/fstab filesystems failed, startup aborted >>> ERROR: ABORTING BOOT (sending SIGTERM to parent)! >>> Enter full pathname of shell or RETURN for /bin/sh: >>> root@freebsd-head-zfs:/ # zfs mount -av >>> root@freebsd-head-zfs:/ # mount -al >>> root@freebsd-head-zfs:/ # exit >>> Setting hostuuid: 7b624d1c-4bc3-e2cb-4ac2-6487a4b4774c. >>> Setting hostid: 0xf9071336. >>> interface zfsctrl.1 already present in the KLD 'kernel'! >>> linker_load_file: /boot/kernel/zfs.ko - unsupported file type >>> kldload: an error occurred while loading module zfs. Please check dmesg(8) >>> for more details. /etc/rc: WARNING: Unable to load kernel module zfs >>> Fast boot: skipping disk checks. >>> Mounting local filesystems:. >>> interface zfsctrl.1 already present in the KLD 'kernel'! >>> linker_load_file: /boot/kernel/zfs.ko - unsupported file type >>> kldload: an error occurred while loading module zfs. Please check dmesg(8) >>> for more details. /etc/rc: WARNING: Unable to load kernel module zfs >>> interface zfsctrl.1 already present in the KLD 'kernel'! >>> linker_load_file: /boot/kernel/zfs.ko - unsupported file type >>> kldload: an error occurred while loading module zfs. Please check dmesg(8) >>> for more details. /etc/rc: WARNING: Unable to load kernel module zfs >>> ELF ldconfig >>> path: /lib /usr/lib /usr/lib/compat /usr/local/lib >>> /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg >>> /usr/local/lib/perl5/5.28/mach/CORE >>> 32-bit compatibility ldconfig path: /usr/lib32 >>> >>> [...] >> >> At a later point, this happens: >> >> Starting syslogd. >> usage: protect [-i] command >>protect [-cdi] -g pgrp | -p pid >> Setting date via ntp. >> >> It looks like syslogd is no longer protected against the OOM killer. >> >>> Once I manually mount the remaining filesystems, multiuser boot >>> proceeds as expected. My kernel has options ZFS, and the boot scripts >>> doesn't account for this scenario. >> >> > > Hello, > > thank you for investigating! I think you're correct. I was wondering how this > change could make it into the tree with this kind of impact. > > Maybe filing a PR would be fine? > I just confirmed that the change at SVN r346017 after 'mergemaster -U' yields a (ZFS-based) system which can only be brought into normal service through: a single-user boot mount -a mount -u -o rw / zfs mount -a Reverting this change restores normal operation at start-up. ZFS is also compiled into the kernel on my system,
SVN r346316 breaks build
There seems to be a missing include here? ===> usr.bin/strings (obj,all,install) Building /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/strings/strings.o /usr/src/contrib/elftoolchain/strings/strings.c:198:55: error: use of undeclared identifier 'FA_OPEN' fa = fileargs_init(argc, argv, O_RDONLY, 0, &rights, FA_OPEN); ^ 1 error generated. *** [strings.o] Error code 1 make[3]: stopped in /usr/src/usr.bin/strings imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r346316 breaks build
On 2019-04-17 20:45, Ed Maste wrote: > On Wed, 17 Apr 2019 at 17:31, Michael Butler > wrote: >> >> There seems to be a missing include here? >> >> ===> usr.bin/strings (obj,all,install) >> Building >> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/strings/strings.o >> /usr/src/contrib/elftoolchain/strings/strings.c:198:55: error: use of >> undeclared identifier 'FA_OPEN' >> fa = fileargs_init(argc, argv, O_RDONLY, 0, &rights, FA_OPEN); > > I can't reproduce this and the CI builds > (https://ci.freebsd.org/tinderbox) are all passing, although this was > reported privately to me by others so something's up. What is the > FreeBSD version on your build host? > This is a native build on current. It fails with or without removing /usr/obj/*. Sean Eric Fagan (sef) pointed me to the fact that cap_fileargs.h is not updated as part of the bootstrap-tools target. As I don't understand how that target is built or configured, I successfully worked around it by doing (on my amd64 host) .. cp -p /usr/src/lib/libcasper/services/cap_fileargs/cap_fileargs.h \ /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/casper/ cp -p /usr/src/lib/libcasper/services/cap_fileargs/cap_fileargs.h \ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/casper/ cp -p /usr/src/lib/libcasper/services/cap_fileargs/cap_fileargs.h \ /usr/include/casper/ imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r346645 breaks build of DRM drivers
The removal of dma_mask (around line 105) in /usr/src/sys/compat/linuxkpi/common/include/linux/device.h breaks the DRM loadable modules :-( As follows .. --- amdgpu_amdkfd.o --- /usr/ports/graphics/drm-current-kmod/work/kms-drm-068d6be/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:284:37: error: no member named 'dma_mask' in 'struct device' uint64_t address_mask = adev->dev->dma_mask ? ~*adev->dev->dma_mask : ~ ^ /usr/ports/graphics/drm-current-kmod/work/kms-drm-068d6be/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:284:61: error: no member named 'dma_mask' in 'struct device' uint64_t address_mask = adev->dev->dma_mask ? ~*adev->dev->dma_mask : ~ ^ 2 errors generated. imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r346700 breaks build
Seems that the lib32 piece (on amd64) is now broken; as follows: --- realinstall_subdir_lib/libbe --- --- _libinstall --- install: /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/lib/: No such file or directory *** [_libinstall] Error code 71 make[5]: stopped in /usr/src/lib/libbe .ERROR_TARGET='_libinstall' .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libbe/_libinstall.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libbe.a /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32/; sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libbe_p.a /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32/; sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 -S libbe.so.1 /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/lib/; sh /usr/src/tools/install.sh -l rs -o root -g wheel -m 755 /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/lib/libbe.so.1 /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32/libbe.so; -chflags noschg /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32/libbe.so.1; rm -f /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32/libbe.so.1;' .CURDIR='/usr/src/lib/libbe' .MAKE='make' .OBJDIR='/usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libbe' .TARGETS='install' DESTDIR='/usr/obj/usr/src/amd64.amd64/obj-lib32/tmp' LD_LIBRARY_PATH='' MACHINE='i386' MACHINE_ARCH='i386' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20181221' PATH='/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/usr/src/amd64.amd64/obj-lib32' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/lib/libbe/Makefile /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.lib.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/lib/libbe/../Makefile.inc /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/lib/libbe' 1 error Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
at SVN r347375, terminating/restarting openvpn on tap causes panic
Seems there's a lock or tuntap issue after recent changes. Restarting openvpn (configured to use /dev/tap) yields a panic as follows: (kgdb) bt #0 doadump () at src/sys/amd64/include/pcpu.h:241 #1 0x808393c8 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:470 #2 0x80839826 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:896 #3 0x80839663 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:823 #4 0x80c31686 in trap_fatal (frame=0xfe0072b14510, eva=156) at /usr/src/sys/amd64/amd64/trap.c:946 #5 0x80c31a39 in trap_pfault (frame=0xfe0072b14510, usermode=0) at src/sys/amd64/include/cpufunc.h:423 #6 0x80c30dbe in trap (frame=0xfe0072b14510) at /usr/src/sys/amd64/amd64/trap.c:441 #7 0x80c0d295 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #8 0x80a15387 in ip_output (m=, opt=, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at /usr/src/sys/netinet/ip_output.c:362 #9 0x809ffeb4 in igmp_intr (m=) at /usr/src/sys/netinet/igmp.c:3455 #10 0x80975a1f in netisr_dispatch_src (proto=2, source=, m=) at /usr/src/sys/net/netisr.c:1122 #11 0x809fe08a in igmp_fasttimo () at /usr/src/sys/netinet/igmp.c:496 #12 0x808c5854 in pffasttimo (arg=) at /usr/src/sys/kern/uipc_domain.c:521 #13 0x80853df3 in softclock_call_cc (c=0x813f7f48, cc=0x814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731 #14 0x808542b9 in softclock (arg=0x814c9ac0) at /usr/src/sys/kern/kern_timeout.c:869 #15 0x807fd0c4 in ithread_loop (arg=) at /usr/src/sys/kern/kern_intr.c:1129 #16 0x807f9f33 in fork_exit (callout=0x807fcef0 , arg=0xf80002620100, frame=0xfe0072b14ac0) at /usr/src/sys/kern/kern_fork.c:1058 #17 0x80c0e28e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:995 #18 0x in ?? () imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: at SVN r347375, terminating/restarting openvpn on tap causes panic
On 2019-05-09 09:07, Kyle Evans wrote: > On Thu, May 9, 2019 at 7:24 AM Michael Butler > wrote: >> >> Seems there's a lock or tuntap issue after recent changes. Restarting >> openvpn (configured to use /dev/tap) yields a panic as follows: >> > > Ah, I knew I was forgetting something. =( Give this a shot: > https://people.freebsd.org/~kevans/etherdetach.diff Sorry - same result, (kgdb) bt #0 doadump () at src/sys/amd64/include/pcpu.h:241 #1 0x808393c8 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:470 #2 0x80839826 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:896 #3 0x80839663 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:823 #4 0x80c318a6 in trap_fatal (frame=0xfe0072b14510, eva=156) at /usr/src/sys/amd64/amd64/trap.c:946 #5 0x80c31c59 in trap_pfault (frame=0xfe0072b14510, usermode=0) at src/sys/amd64/include/cpufunc.h:423 #6 0x80c30fde in trap (frame=0xfe0072b14510) at /usr/src/sys/amd64/amd64/trap.c:441 #7 0x80c0d4b5 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #8 0x80a15377 in ip_output (m=, opt=, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at /usr/src/sys/netinet/ip_output.c:362 #9 0x809ffea4 in igmp_intr (m=) at /usr/src/sys/netinet/igmp.c:3455 #10 0x80975a0f in netisr_dispatch_src (proto=2, source=, m=) at /usr/src/sys/net/netisr.c:1122 #11 0x809fe07a in igmp_fasttimo () at /usr/src/sys/netinet/igmp.c:496 #12 0x808c5854 in pffasttimo (arg=) at /usr/src/sys/kern/uipc_domain.c:521 #13 0x80853df3 in softclock_call_cc (c=0x813f7f48, cc=0x814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731 #14 0x808542b9 in softclock (arg=0x814c9ac0) at /usr/src/sys/kern/kern_timeout.c:869 #15 0x807fd0c4 in ithread_loop (arg=) at /usr/src/sys/kern/kern_intr.c:1129 #16 0x807f9f33 in fork_exit (callout=0x807fcef0 , arg=0xf800025f10a0, frame=0xfe0072b14ac0) at /usr/src/sys/kern/kern_fork.c:1058 #17 0x80c0e4ae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:995 #18 0x in ?? () imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Danish FreeBSD Developer hates jews collectively
On 2019-05-09 14:03, ossobser...@redchan.it wrote: > Background: Apparently a FreeBSD developer, a viking looking fellow, Further miscellaneous dribble elided .. This has no place on this mailing list. Take your hate someplace else, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: at SVN r347375, terminating/restarting openvpn on tap causes panic
On 2019-05-09 14:22, Gleb Smirnoff wrote:
> Michael,
>
> On Thu, May 09, 2019 at 10:25:37AM -0500, Kyle Evans wrote:
> K> > #0 doadump () at src/sys/amd64/include/pcpu.h:241
> K> > #1 0x808393c8 in kern_reboot (howto=260) at
> K> > /usr/src/sys/kern/kern_shutdown.c:470
> K> > #2 0x80839826 in vpanic (fmt=, ap= K> > optimized out>) at /usr/src/sys/kern/kern_shutdown.c:896
> K> > #3 0x80839663 in panic (fmt=) at
> K> > /usr/src/sys/kern/kern_shutdown.c:823
> K> > #4 0x80c318a6 in trap_fatal (frame=0xfe0072b14510, eva=156)
> K> > at /usr/src/sys/amd64/amd64/trap.c:946
> K> > #5 0x80c31c59 in trap_pfault (frame=0xfe0072b14510,
> K> > usermode=0) at src/sys/amd64/include/cpufunc.h:423
> K> > #6 0x80c30fde in trap (frame=0xfe0072b14510) at
> K> > /usr/src/sys/amd64/amd64/trap.c:441
> K> > #7 0x80c0d4b5 in calltrap () at
> K> > /usr/src/sys/amd64/amd64/exception.S:232
> K> > #8 0x80a15377 in ip_output (m=, opt= K> > optimized out>, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at
> K> > /usr/src/sys/netinet/ip_output.c:362
> K> > #9 0x809ffea4 in igmp_intr (m=) at
> K> > /usr/src/sys/netinet/igmp.c:3455
> K> > #10 0x80975a0f in netisr_dispatch_src (proto=2, source= K> > optimized out>, m=) at
> /usr/src/sys/net/netisr.c:1122
> K> > #11 0x809fe07a in igmp_fasttimo () at
> K> > /usr/src/sys/netinet/igmp.c:496
> K> > #12 0x808c5854 in pffasttimo (arg=) at
> K> > /usr/src/sys/kern/uipc_domain.c:521
> K> > #13 0x80853df3 in softclock_call_cc (c=0x813f7f48,
> K> > cc=0x814c9ac0, direct=0) at /usr/src/sys/kern/kern_timeout.c:731
> K> > #14 0x808542b9 in softclock (arg=0x814c9ac0) at
> K> > /usr/src/sys/kern/kern_timeout.c:869
> K> > #15 0x807fd0c4 in ithread_loop (arg=) at
> K> > /usr/src/sys/kern/kern_intr.c:1129
> K> > #16 0x807f9f33 in fork_exit (callout=0x807fcef0
> K> > , arg=0xf800025f10a0, frame=0xfe0072b14ac0) at
> K> > /usr/src/sys/kern/kern_fork.c:1058
> K> > #17 0x80c0e4ae in fork_trampoline () at
> K> > /usr/src/sys/amd64/amd64/exception.S:995
> K> > #18 0x in ?? ()
> K> >
> K>
> K> Ah, I misread your backtrace (and forgot the proper tap detachment
> K> from my previous patch, so that's fixed/committed anyways). CC'ing
> K> Gleb for further triage as committer of r347375 that touched things in
> K> this path.
>
> Michael, can you please dump a core and look at it in kgdb? Line 362 in
> ip_output() really belongs to part that had minimal change with r347375.
> So I need more details. Can you please print out in kgdb the following
> variables: imo, ifp, ia?
>
This was a backtrace from kgdb. From frame 8, I see ..
(kgdb) frame 8
#8 0x80a15377 in ip_output (m=, opt=, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at
/usr/src/sys/netinet/ip_output.c:362
362 IFP_TO_IA(ifp, ia, &in_ifa_tracker);
(kgdb) print imo
$1 = (struct ip_moptions *) 0xfe0072b14780
(kgdb) print ifp
$2 = (struct ifnet *) 0xf8000411
(kgdb) print ia
$3 =
(kgdb) print *imo
$4 = {imo_multicast_ifp = 0xf8000411, imo_multicast_addr =
{s_addr = 1924220944}, imo_multicast_vif = 18446744073709551615,
imo_multicast_ttl = 1 '\001', imo_multicast_loop = 0 '\0',
imo_num_memberships = 15350, imo_max_memberships = 63489,
imo_membership = 0xf80002c10d00, imo_mfilters = 0xf80002c10d00,
imo_epoch_ctx = {data = 0xfe0072b147b0}}
(kgdb) print *ifp
$5 = {if_link = {cstqe_next = 0x0}, if_clones = {le_next = 0x0, le_prev
= 0xf800040f9728}, if_groups = {cstqh_first = 0xf80002878d60,
cstqh_last = 0xf80002878d38},
if_alloctype = 6 '\006', if_numa_domain = 255 '�', if_softc =
0xf80004197300, if_llsoftc = 0x0, if_l2com = 0xf800040fe800,
if_dname = 0x80e0bd14 "tap", if_dunit = 0,
if_index = 4, if_index_reserved = 0, if_xname = 0xf80004110058
"tap0", if_description = 0x0, if_flags = 34818, if_drv_flags = 0,
if_capabilities = 524288, if_capenable = 524288,
if_linkmib = 0x0, if_linkmiblen = 0, if_refcount = 1, if_type = 6
'\006', if_addrlen = 6 '\006', if_hdrlen = 14 '\016', if_link_state = 1
'\001', if_mtu = 1500, if_metric = 0,
if_baudrate = 1000, if_hwassist = 0, if_epoch = 10, if_lastchange
= {tv_sec = 1557408022, tv_usec = 929504}, if_snd = {ifq_head = 0x0,
ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 50,
ifq_mtx = {lock_object = {lo_name = 0xf80004110058 "tap0",
lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0},
ifq_drv_head = 0x0, ifq_drv_tail = 0x0,
ifq_drv_len = 0, ifq_drv_maxlen = 0, altq_type = 0, altq_flags = 0,
altq_disc = 0x0, altq_ifp = 0xf8000411, altq_enqueue = 0,
altq_dequeue = 0, altq_request = 0,
altq_clfier = 0x0, altq_classify = 0, altq_tbr = 0x0, altq_cdnr =
0x0}, if_linktask = {ta_link = {stqe_next = 0x0}, ta_pending = 0,
ta_priority = 0,
ta_func = 0x809494e0 , ta_contex
Re: at SVN r347375, terminating/restarting openvpn on tap causes panic
On 2019-05-09 14:38, Gleb Smirnoff wrote: > On Thu, May 09, 2019 at 02:32:44PM -0400, Michael Butler wrote: > M> (kgdb) frame 8 > M> #8 0x80a15377 in ip_output (m=, opt= M> optimized out>, ro=0x0, flags=0, imo=0xfe0072b14780, inp=0x0) at > M> /usr/src/sys/netinet/ip_output.c:362 > M> 362 IFP_TO_IA(ifp, ia, &in_ifa_tracker); > M> (kgdb) print imo > M> $1 = (struct ip_moptions *) 0xfe0072b14780 > M> (kgdb) print ifp > M> $2 = (struct ifnet *) 0xf8000411 > M> (kgdb) print ia > M> $3 = > ... > > This all looks good. > > Can you please traverse the 'in_ifaddrhead' linked list? To close the loop on this - it's now fixed by SVN r347466, Thanks! imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Heads up for breaking drm update.
On 2019-05-19 23:21, Johannes Lundberg wrote: > > On 5/19/19 7:36 PM, Steve Kargl wrote: >> On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote: >>> LinuxKPI in base have received a lot of updates recently for Linux 5.0, >>> a couple of them will break drm-current-kmod. So, as of r347973 you will >>> need drm-current-kmod 4.16.g20190519. Ports have been updated and new >>> packages should be available shortly. >>> >> If drm-current-kmod is broken, should I venture to ask >> about drm-stable-kmod and drm-legacy-kmod? > > That's a very good question. Maybe I should have included more > information regarding what's not affected. The last series of commits > have been to LinuxKPI in -CURRENT. As such: > > drm-kmod: Meta port, not relevant > drm-current-kmod: See original message > drm-fbsd11.2-kmod: Not affected by changes in -CURRENT > drm-fbsd12.0-kmod: Not affected by changes in -CURRENT > drm-legacy-kmod: Not affected by changes in LinuxKPI > > drm-stable-kmod does not exist anymore. Stable drm kmod ports for other > than -CURRENT are more or less frozen in separate branches where they > only receive bug fixes (drm-fbsdxxx-kmod). > > Hope that answers your questions. It should also be noted that drm-current now has a new dependency on lindebugfs. It won't load without it :-( imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r350713 breaks non-debug kernel builds
As follows ..
--- kern_sysctl.o ---
/usr/src/sys/kern/kern_sysctl.c:1623:19: error: use of undeclared
identifier 'kdb_active'
if (arg2 == 0 || kdb_active) {
^
1 error generated.
*** [kern_sysctl.o] Error code 1
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r351457 breaks drm-current
As follows .. Building /usr/obj/usr/src/amd64.amd64/sys/TOSHI/modules/usr/local/sys/modules/drm-current-kmod/linuxkpi/linux_compat.o --- linux_compat.o --- In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_compat.c:5: ./machine/md_var.h:61:34: error: declaration of 'struct pcpu' will not be visible outside of this function [-Werror,-Wvisibility] voidamd64_bsp_pcpu_init1(struct pcpu *pc); ^ ./machine/md_var.h:63:32: error: declaration of 'struct pcpu' will not be visible outside of this function [-Werror,-Wvisibility] voidamd64_bsp_ist_init(struct pcpu *pc); ^ imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r351457 breaks drm-current
On 2019-08-24 14:04, Konstantin Belousov wrote: > On Sat, Aug 24, 2019 at 11:02:20AM -0600, Warner Losh wrote: >> forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure >> that's the right fix. > More correct way to fix it is to include sys/pcpu.h before machine/md_var.h, > same as all in-tree consumers of the header do, apparently. > > But another question is why the driver needs md_var.h, there are no > externally usable definitions there. There are uses of other variables from machine/md_var.h, notably cpu_feature, in linux_compat.c. Including sys/pcpu.h allows the build to continue .. as in .. *** linuxkpi/gplv2/src/linux_compat.c~ Wed Aug 7 14:36:56 2019 --- linuxkpi/gplv2/src/linux_compat.c Sat Aug 24 18:58:08 2019 *** *** 2,7 --- 2,8 #include #if defined(__i386__) || defined(__amd64__) #include + #include #include #endif #include Locally, I've put this patch into graphics/drm-current-kmod/files so I don't trip over it on subsequent builds, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r351457 breaks drm-current
On 2019-08-24 19:09, Michael Butler wrote: > On 2019-08-24 14:04, Konstantin Belousov wrote: >> On Sat, Aug 24, 2019 at 11:02:20AM -0600, Warner Losh wrote: >>> forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure >>> that's the right fix. >> More correct way to fix it is to include sys/pcpu.h before machine/md_var.h, >> same as all in-tree consumers of the header do, apparently. >> >> But another question is why the driver needs md_var.h, there are no >> externally usable definitions there. > > There are uses of other variables from machine/md_var.h, notably > cpu_feature, in linux_compat.c. > > Including sys/pcpu.h allows the build to continue .. as in .. > > *** linuxkpi/gplv2/src/linux_compat.c~ Wed Aug 7 14:36:56 2019 > --- linuxkpi/gplv2/src/linux_compat.c Sat Aug 24 18:58:08 2019 > *** > *** 2,7 > --- 2,8 > #include > #if defined(__i386__) || defined(__amd64__) > #include > + #include > #include > #endif > #include > > Locally, I've put this patch into graphics/drm-current-kmod/files so I > don't trip over it on subsequent builds, This is now resolved in-tree by ports SVN r510009 - thanks to all, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ses no longer attaches
On 2019-08-27 19:15, Niclas Zeising wrote: > On 2019-08-28 00:38, Alexander Motin wrote: >> Hi. >> >> On 27.08.2019 18:03, Niclas Zeising wrote: >>> I have an issue where the ses driver no longer attaches. Last known >>> good version was r351188, r351544 is broken. In that interval, >>> something happened. I haven't had time to bisect yet. >> >> I would appreciate some details, like dmesg, error messages, etc. On my >> test systems I see no problems. >> > > Hi! > I did some more digging. r351355 is ok, while r351356 is bad. This is > Warner's (CC:d) commit to add RST support to nvme, however, I'm using a > ssd drive connected to ahci. > > What happens is that the ses driver doesn't attach to the AHCI SGPIO > enclosure. This is on a laptop with an ssd (not an nvme) drive. I have > the same issue on another computer as well. On the broken kernel, > sesutil status complains about "No SES devices found", on the working > kernel it reports "ok". I can confirm this behaviour (haven't checked versioning) .. working kernel yields .. Aug 20 17:40:06 toshi kernel: ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 Aug 20 17:40:06 toshi kernel: ses0: SEMB S-E-S 2.00 device Aug 20 17:40:06 toshi kernel: ses0: SEMB SES Device Aug 20 17:40:06 toshi kernel: ses0: ada0,pass0 in 'Slot 00', SATA Slot: scbus0 target 0 Aug 20 17:40:06 toshi kernel: ses0: ada1,pass1 in 'Slot 01', SATA Slot: scbus1 target 0 [ .. other stuff .. ] Aug 20 17:40:06 toshi kernel: ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 Aug 20 17:40:06 toshi kernel: ses0: SEMB S-E-S 2.00 device Aug 20 17:40:06 toshi kernel: ses0: SEMB SES Device Aug 20 17:40:06 toshi kernel: ses0: ada0,pass0 in 'Slot 00', SATA Slot: scbus0 target 0 Aug 20 17:40:06 toshi kernel: ses0: ada1,pass1 in 'Slot 01', SATA Slot: scbus1 target 0 .. non working reports .. Aug 27 11:06:28 toshi kernel: ahciem0: at channel 2147483647 on ahci0 Aug 27 11:06:28 toshi kernel: device_attach: ahciem0 attach returned 6 imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ses no longer attaches
On 2019-08-27 19:41, Michael Butler wrote: > On 2019-08-27 19:15, Niclas Zeising wrote: >> On 2019-08-28 00:38, Alexander Motin wrote: >>> Hi. >>> >>> On 27.08.2019 18:03, Niclas Zeising wrote: >>>> I have an issue where the ses driver no longer attaches. Last known >>>> good version was r351188, r351544 is broken. In that interval, >>>> something happened. I haven't had time to bisect yet. >>> >>> I would appreciate some details, like dmesg, error messages, etc. On my >>> test systems I see no problems. >>> >> >> Hi! >> I did some more digging. r351355 is ok, while r351356 is bad. This is >> Warner's (CC:d) commit to add RST support to nvme, however, I'm using a >> ssd drive connected to ahci. >> >> What happens is that the ses driver doesn't attach to the AHCI SGPIO >> enclosure. This is on a laptop with an ssd (not an nvme) drive. I have >> the same issue on another computer as well. On the broken kernel, >> sesutil status complains about "No SES devices found", on the working >> kernel it reports "ok". > > I can confirm this behaviour (haven't checked versioning) .. working > kernel yields .. > > Aug 20 17:40:06 toshi kernel: ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 > Aug 20 17:40:06 toshi kernel: ses0: > SEMB S-E-S 2.00 device > Aug 20 17:40:06 toshi kernel: ses0: SEMB SES Device > Aug 20 17:40:06 toshi kernel: ses0: ada0,pass0 in 'Slot 00', SATA Slot: > scbus0 target 0 > Aug 20 17:40:06 toshi kernel: ses0: ada1,pass1 in 'Slot 01', SATA Slot: > scbus1 target 0 Should have been .. Aug 20 17:40:06 toshi kernel: ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported Aug 20 17:40:06 toshi kernel: ahcich0: at channel 0 on ahci0 Aug 20 17:40:06 toshi kernel: ahcich1: at channel 1 on ahci0 Aug 20 17:40:06 toshi kernel: ahcich4: at channel 4 on ahci0 Aug 20 17:40:06 toshi kernel: ahcich5: at channel 5 on ahci0 Aug 20 17:40:06 toshi kernel: ahciem0: on ahci0 > > [ .. other stuff .. ] > > Aug 20 17:40:06 toshi kernel: ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 > Aug 20 17:40:06 toshi kernel: ses0: > SEMB S-E-S 2.00 device > Aug 20 17:40:06 toshi kernel: ses0: SEMB SES Device > Aug 20 17:40:06 toshi kernel: ses0: ada0,pass0 in 'Slot 00', SATA Slot: > scbus0 target 0 > Aug 20 17:40:06 toshi kernel: ses0: ada1,pass1 in 'Slot 01', SATA Slot: > scbus1 target 0 > > .. non working reports .. > > Aug 27 11:06:28 toshi kernel: ahciem0: bridge> at channel 2147483647 on ahci0 > Aug 27 11:06:28 toshi kernel: device_attach: ahciem0 attach returned 6 > > imb > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fusefs & ntfs-3g
On 9/8/19 7:09 PM, Alan Somers wrote: > On Sun, Sep 8, 2019 at 5:00 PM Clay Daniels Jr. > wrote: > >> I want to view my Windows C: drive on ata0p4. >> This is what I have: >> FreeBSD bsd13 13.0-CURRENT FreeBSD 13.0-CURRENT r351901 GENERIC amd64 >> clay@bsd13:~ % pkg info -r fusefs-libs >> fusefs-libs-2.9.9: >> clay@bsd13:~ % pkg info -r fusefs-libs3 >> fusefs-libs3-3.6.2: >> clay@bsd13:~ % cat /boot/loader.conf >> hw.syscons.disable=1 >> fusefs_load="YES" >> clay@bsd13:~ % kldstat >> Id Refs AddressSize Name >> 1 72 0x8020 2336f80 kernel >> 21 0x8253800027990 fusefs.ko >> 31 0x8272 2519c4 amdgpu.ko >> 42 0x8297200077bd0 drm.ko >> 55 0x829ea00012470 linuxkpi.ko >> 63 0x829fd00012f30 linuxkpi_gplv2.ko >> 72 0x82a1 8e0 lindebugfs.ko >> 81 0x82a11000 f281 ttm.ko >> 91 0x82a21000 23f7 radeon_kabini_pfp_bin.ko >> 101 0x82a24000 23f5 radeon_kabini_me_bin.ko >> 111 0x82a27000 23f5 radeon_kabini_ce_bin.ko >> 121 0x82a2a000 43f7 radeon_kabini_mec_bin.ko >> 131 0x82a2f000 2a77 radeon_kabini_rlc_bin.ko >> 141 0x82a32000 12e9 radeon_kabini_sdma_bin.ko >> 151 0x82a34000 12eb radeon_kabini_sdma1_bin.ko >> 161 0x82a3600038ea7 radeon_kabini_uvd_bin.ko >> 171 0x82a6f00018c47 radeon_kabini_vce_bin.ko >> 181 0x82a88000 2538 intpm.ko >> 191 0x82a8b000 a50 smbus.ko >> 201 0x82a8c000 1820 uhid.ko >> 211 0x82a8e000 2928 ums.ko >> 221 0x82a91000 1b00 wmt.ko >> 231 0x82a93000 acf mac_ntpd.ko >> 241 0x82a94000 a9f8 tmpfs.ko >> >> clay@bsd13:~ % pkg info fusefs-ntfs-2017.3.23 >> fusefs-ntfs-2017.3.23 >> Name : fusefs-ntfs >> Version: 2017.3.23 >> Installed on : Sun Sep 8 17:24:36 2019 CDT >> Origin : sysutils/fusefs-ntfs >> Architecture : FreeBSD:13:amd64 >> Prefix : /usr/local >> Categories : sysutils >> Licenses : GPLv2+ >> Maintainer : free...@dussan.org >> WWW: https://www.tuxera.com/community/open-source-ntfs-3g/ >> Comment: Mount NTFS partitions (read/write) and disk images >> Options: >> DOCS : on >> LOCK : on >> UBLIO : on >> Shared Libs required: >> libfuse.so.2 >> libuuid.so.1 >> libublio.so.1 >> Shared Libs provided: >> libntfs-3g.so.88 >> Annotations: >> FreeBSD_version: 1300044 >> repo_type : binary >> repository : FreeBSD >> Flat size : 1.93MiB >> Description: >> The ntfs-3g driver is an open source, freely available read/write NTFS >> driver, which provides safe and fast handling of the Windows XP, Windows >> Server 2003, Windows 2000, Windows Vista, Windows Server 2008, Windows 7 >> and Windows 8 NTFS file systems. Almost the full POSIX filesystem >> functionality is supported, the major exceptions are changing the file >> ownerships and the access rights. >> >> root@bsd13:/home/clay # ntfs-3g -o default_permissons /dev/ada0p4 /mnt >> * Windows is hibernated, refused to mount. >> The disk contains an unclean file system (0, 0). >> Metadata kept in Windows cache, refused to mount. >> Falling back to read-only mount because the NTFS partition is in an unsafe >> state. Please resume and shutdown Windows fully (no hibernation >> or fast restarting. >> >> I'm having a roadblock here. Maybe someone knows the answer. >> > > I'm assuming that you already ascertained that the Windows file system was > in fact clean? If so, then this sounds like a problem with fusefs-ntfs, > not with fuse in general. I've CC'd its maintainer. He may be able to > help you. > -Alan Windows-10 has a changed default; it does the equivalent of hibernation to facilitate "fast start". ntfs-3g won't touch a partition for writing in that mode :-( If I recall correctly, there is a setting you must change from in Windows under control panel -> system -> power and sleep. From there you should be able to disable the "fast start" option and, after shutting down, ntfs-3g will allow a read/write mount, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
rc.d/linux runs unconditionally
In rc.d/sysvipc we see ..
name="sysvipc"
desc="Load SysV IPC modules"
rcvar="sysvipc_enable"
start_cmd="${name}_start"
.. so it won't try to run without explicitly setting sysvipc_enable in
/etc/rc.conf.
However in rc.d/linux, we have only ..
name="linux"
desc="Enable Linux ABI"
start_cmd="${name}_start"
.. which causes it to try to load the linux modules unconditionally
even when I don't want them,
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r353480 now mandates kernel option VIMAGE
sys/net/route.c will no longer compile when VIMAGE is removed from the kernel, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r353868 breaks net/intel-em-kmod
The removal of these KPIs yields: link_elf_obj: symbol if_multiaddr_array undefined linker_load_file: /boot/modules/if_em_updated.ko - unsupported file type imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r353868 breaks net/intel-em-kmod
On 10/24/19 1:56 PM, Gleb Smirnoff wrote: > On Thu, Oct 24, 2019 at 11:12:10AM -0400, Michael Butler wrote: > M> The removal of these KPIs yields: > M> > M> link_elf_obj: symbol if_multiaddr_array undefined > M> linker_load_file: /boot/modules/if_em_updated.ko - unsupported file type > > What's the reason to keep these outside of the tree drivers? AFAIU, they > are maintained by the same team that maintains in-tree drivers. Cced them. For some reason, the default in-kernel driver doesn't play nicely with VirtualBox especially when attempting to bridge the host and client. I have not explored why it works with NAT but not bridge, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r354253 breaks buildworld
Something missing from SVN r354253? Building /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue ld: error: undefined symbol: lz4_init >>> referenced by spa_misc.c:2066 (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2066) >>> spa_misc.o:(spa_init) in archive /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a ld: error: undefined symbol: lz4_fini >>> referenced by spa_misc.c:2096 (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2096) >>> spa_misc.o:(spa_fini) in archive /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a cpp: error: linker command failed with exit code 1 (use -v to see invocation) *** [rescue] Error code 1 make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue .ERROR_TARGET='rescue' .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose curdirOk=yes' _ERROR_CMD='cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -march=ivybridge -std=gnu99 -Wno-format-zero-length-Qunused-arguments -static -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo sleep.lo stty.lo sync.lo test.lo csh.lo camcontrol.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo savecore.lo shutdown.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo ccdconfig.lo ping6.lo rtsol.lo ipf.lo routed.lo rtquery.lo bectl.lo zfs.lo zpool.lo bsdlabel.lo fdisk.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo less.lo xz.lo zstd.lo tar.lo nc.lo vi.lo id.lo iscsictl.lo zdb.lo chroot.lo chown.lo iscsid.lo /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/amd64.amd64/rescue/rescue/../librescue/system.o -lcrypt -ledit -ljail -lkvm -lelf -ll -ltermcapw -lutil -lxo -l80211 -lalias -lcam -lncursesw -ldevstat -lipsec -llzma -lavl -lzpool -lzfs_core -lzfs -lnvpair -lpthread -luutil -lumem -lbe -lgeom -lbsdxml -lkiconv -lmt -lsbuf -lufs -lz -lbz2 -lprivatezstd -larchive -lcrypto -lmd -lm;' .CURDIR='/usr/obj/usr/src/amd64.amd64/rescue/rescue' imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r354253 breaks buildworld
On 11/2/19 5:15 PM, Toomas Soome wrote:
> Should be fixed by r354265.
The problem has moved .. now the kernel won't build ..
Building /usr/obj/usr/src/amd64.amd64/sys/VM01/avl.o
Building /usr/obj/usr/src/amd64.amd64/sys/VM01/lz4.o
--- lz4.o ---
cc: error: no such file or directory:
'/usr/src/sys/cddl/contrib/opensolaris/lz4/lz4.c'
cc: error: no input files
*** [lz4.o] Error code 1
That's brought in by sys/conf/files as follows ..
imb@vm01:/sys/conf> grep lz4 *
files:cddl/contrib/opensolaris/lz4/lz4.c
optional zfs compile-with "${ZFS_C}"
kern.pre.mk:ZFS_CFLAGS+=-I$S/cddl/contrib/opensolaris/common/lz4
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
make release with i386 target now fails
I'm sure I did this yesterday without a failure; any hints as to what broke/how to fix it? imb ===> tests/sys/cddl/zfs/tests/threadsappend (all) ===> tests/sys/cddl/zfs/tests/truncate (all) ===> usr.sbin/amd/libamu (all) ===> usr.sbin/audit (all) ===> tests/sys/cddl/zfs/tests/txg_integrity (all) ===> tests/sys/cddl/zfs/tests/userquota (all) --- xdr_func_%undef.c --- *** [xdr_func_%undef.c] Error code 1 make[5]: *** xdr_func_%undef.c removed make[5]: stopped in /usr/local/release-builds/i386/usr/src/usr.sbin/amd/libamu .ERROR_TARGET='xdr_func_%undef.c' .ERROR_META_FILE='/usr/local/release-builds/i386/tmp/obj/usr/local/release-builds/i386/usr/src/amd64.amd64/usr.sbin/amd/libamu/xdr_func_%undef.c.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes' _ERROR_CMD='unifdef -x1 -DHAVE_XDR_ATTRSTAT -DHAVE_XDR_CREATEARGS -DHAVE_XDR_DIRLIST -DHAVE_XDR_DIROPARGS -DHAVE_XDR_DIROPOKRES -DHAVE_XDR_DIROPRES -DHAVE_XDR_DIRPATH -DHAVE_XDR_ENTRY -DHAVE_XDR_EXPORTNODE -DHAVE_XDR_EXPORTS -DHAVE_XDR_FATTR -DHAVE_XDR_FHANDLE -DHAVE_XDR_FHSTATUS -DHAVE_XDR_FILENAME -DHAVE_XDR_FTYPE -DHAVE_XDR_GROUPNODE -DHAVE_XDR_GROUPS -DHAVE_XDR_LINKARGS -DHAVE_XDR_MOUNTBODY -DHAVE_XDR_MOUNTLIST -DHAVE_XDR_NAME -DHAVE_XDR_NFS_FH -DHAVE_XDR_NFSCOOKIE -DHAVE_XDR_NFSPATH -DHAVE_XDR_NFSSTAT -DHAVE_XDR_NFSTIME -DHAVE_XDR_POINTER -DHAVE_XDR_READARGS -DHAVE_XDR_READDIRARGS -DHAVE_XDR_READDIRRES -DHAVE_XDR_READLINKRES -DHAVE_XDR_READOKRES -DHAVE_XDR_READRES -DHAVE_XDR_RENAMEARGS -DHAVE_XDR_SATTR -DHAVE_XDR_SATTRARGS -DHAVE_XDR_STATFSOKRES -DHAVE_XDR_STATFSRES -DHAVE_XDR_SYMLINKARGS -DHAVE_XDR_WRITEARGS -DHAVE_XDR_U_INT64_T -o xdr_func_%undef.c /usr/local/release-builds/i386/usr/src/contrib/amd/libamu/xdr_func.c;' ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r354896 breaks build
The no-relax flag can't be used on all architectures .. Building /usr/obj/usr/src/amd64.amd64/usr.sbin/jail/jail --- jail --- ld: error: unknown argument '--no-relax' cc: error: linker command failed with exit code 1 (use -v to see invocation) --- all_subdir_usr.sbin/portsnap --- --- all_subdir_usr.sbin/portsnap/make_index --- ===> usr.sbin/portsnap/make_index (all) --- all_subdir_usr.sbin/jail --- *** [jail] Error code 1 imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r272273 breaks 'dump'
It seems that the strptime changes broke the recognition of /etc/dumpdates. Last night's level 2 dump turned into a level 0: DUMP: Date of this level 2 dump: Mon Sep 29 00:10:26 2014 DUMP: Unknown intermediate format in /etc/dumpdates, line 1 DUMP: Unknown intermediate format in /etc/dumpdates, line 1 DUMP: Unknown intermediate format in /etc/dumpdates, line 1 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/ada0s3a (/) to standard output DUMP: mapping (Pass I) [regular files] imb signature.asc Description: OpenPGP digital signature
SVN r273381/2 breaks world
>From an empty obj tree on the second pass through, I get .. --- tblgen --- c++ -O2 -pipe -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -Wno-c++11-extensions -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o tblgen AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst.o CTagsEmitter.o CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenInstruction.o CodeGenMapTable.o CodeGenRegisters.o CodeGenSchedule.o CodeGenTarget.o DAGISelEmitter.o DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o DFAPacketizerEmitter.o DisassemblerEmitter.o FastISelEmitter.o FixedLenDecoderEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o OptParserEmitter.o PseudoLoweringEmitter.o RegisterInfoEmitter.o SetTheory.o SubtargetEmitter.o TGValueTypes.o TableGen.o X86DisassemblerTables.o X86ModRMFilters.o X86RecognizableInstr.o /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmtablegen/libllvmtablegen.a /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmsupport/libllvmsupport.a -lncursesw -legacy /usr/lib/libc++.a(cxxrt_stdexcept.o):(.rodata+0x1c0): multiple definition of `typeinfo for std::bad_array_new_length' /usr/lib/libc++.a(new.o):(.rodata+0x90): first defined here /usr/lib/libc++.a(cxxrt_stdexcept.o):(.rodata+0x1a0): multiple definition of `typeinfo name for std::bad_array_new_length' /usr/lib/libc++.a(new.o):(.rodata+0x70): first defined here /usr/lib/libc++.a(cxxrt_stdexcept.o):(.rodata+0xc0): multiple definition of `vtable for std::bad_array_new_length' /usr/lib/libc++.a(new.o):(.rodata+0x10): first defined here c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [tblgen] Error code 1 make[3]: stopped in /usr/src/usr.bin/clang/tblgen 1 error Recompiling and reinstalling libc++ doesn't change anything, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r273734 breaks i386 compilation
The updates to dd cause this on an i386 .. ===> bin/dd (all) cc -O2 -pipe -march=pentium4 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/bin/dd/args.c /usr/src/bin/dd/args.c:192:43: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "bs must be between 1 and %jd", SSIZE_MAX); ~~~ ^ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fff /* max value for an int */ ^~ /usr/src/bin/dd/args.c:201:44: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "cbs must be between 1 and %jd", SSIZE_MAX); ~~~ ^ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fff /* max value for an int */ ^~ /usr/src/bin/dd/args.c:221:46: error: format specifies type 'uintmax_t' (aka 'unsigned long long') but the argument has type 'unsigned int' [-Werror,-Wformat] errx(1, "files must be between 1 and %ju", SIZE_MAX); ~~~ ^~~~ %u /usr/obj/usr/src/tmp/usr/include/x86/_stdint.h:180:18: note: expanded from macro 'SIZE_MAX' #define SIZE_MAXUINT32_MAX ^~ /usr/obj/usr/src/tmp/usr/include/x86/_stdint.h:82:20: note: expanded from macro 'UINT32_MAX' #define UINT32_MAX 0xU ^~~ /usr/src/bin/dd/args.c:241:45: error: format specifies type 'uintmax_t' (aka 'unsigned long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "ibs must be between 1 and %ju", SSIZE_MAX); ~~~ ^ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fff /* max value for an int */ ^~ /usr/src/bin/dd/args.c:259:45: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "obs must be between 1 and %jd", SSIZE_MAX); ~~~ ^ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fff /* max value for an int */ ^~ 5 errors generated. *** Error code 1 Stop. make[4]: stopped in /usr/src/bin/dd *** Error code 1 signature.asc Descrip
SVN r377448 breaks net-snmp on -current
Apparently, there was some 'magic' to accessing these sysctls: libtool: link: cc -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -O2 -pipe -march=pentium4 -I/usr/local/include -I/include -D_WANT_IFADDR -fstack-protector -fno-strict-aliasing -Ufreebsd11 -Dfreebsd11=freebsd11 -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/usr/local/lib/perl5/5.18/mach/CORE -o .libs/snmpd .libs/snmpd.o -Wl,-R/usr/local/lib/perl5/5.18/mach/CORE -L/usr/lib -L/lib ./.libs/libnetsnmpagent.so -L/usr/local/lib -L/usr/local/lib/perl5/5.18/mach/CORE ./.libs/libnetsnmpmibs.so /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/agent/.libs/libnetsnmpagent.so /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/snmplib/.libs/libnetsnmp.so ../snmplib/.libs/libnetsnmp.so -lpkg -lwrap -lperl -lcrypt -lutil -lelf -lssp_nonshared -lm -lkvm -ldevstat -lcrypto -pthread -Wl,-rpath -Wl,/usr/local/lib ./.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp_stat' ./.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp6_stat' ./.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp6_msg_stat' ./.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp_msg_stat' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 imb signature.asc Description: OpenPGP digital signature
Re: SVN r377448 breaks net-snmp on -current
On 01/19/15 14:53, O. Hartmann wrote: > Am Mon, 19 Jan 2015 14:40:09 -0500 > Michael Butler schrieb: > >> Apparently, there was some 'magic' to accessing these sysctls: [ .. snip .. ] >> ./.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp_stat' >> ./.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp6_stat' >> ./.libs/libnetsnmpmibs.so: undefined reference to >> `sysctl_read_icmp6_msg_stat' >> ./.libs/libnetsnmpmibs.so: undefined reference to >> `sysctl_read_icmp_msg_stat' >> cc: error: linker command failed with exit code 1 (use -v to see invocation) >> *** Error code 1 > > Me, too here. I just filed a PR: Bug 196904 - net-mgmt/net-snmp: undefined > reference to > `sysctl_read_XX > > oh > I note an attempt at fixing this in r377525 but I still see build failures :-( imb signature.asc Description: OpenPGP digital signature
Re: r278328: fails to build kernel due to /usr/src/sys/kern/subr_bus.c: undefined reference to `memchr'
On 02/06/15 15:06, O. Hartmann wrote: > Recent sources seem to fail in buildkernel with > > [...] > --- kernel --- > linking kernel > subr_bus.o: In function `devctl2_ioctl': > /usr/src/sys/kern/subr_bus.c:(.text+0x6284): undefined reference to `memchr' > *** [kernel] Error code 1 It seems that this function in libkern was conditionally compiled. You might try this: *** sys/conf/files~ Sat Jan 31 10:44:44 2015 --- sys/conf/files Fri Feb 6 17:05:37 2015 *** *** 3193,3199 libkern/murmur3_32.c standard libkern/mcount.c optional profiling-routine libkern/memcchr.c standard ! libkern/memchr.c optional fdt | gdb libkern/memcmp.c standard libkern/memmem.c optional gdb libkern/qsort.c standard --- 3193,3199 libkern/murmur3_32.c standard libkern/mcount.c optional profiling-routine libkern/memcchr.c standard ! libkern/memchr.c standard libkern/memcmp.c standard libkern/memmem.c optional gdb libkern/qsort.c standard signature.asc Description: OpenPGP digital signature
SVN r278414 is incorrect
SVN r278414 causes a 'buildworld' to fail. The fix is attached, imb signature.asc Description: OpenPGP digital signature
Re: SVN r278414 is incorrect
On 02/08/15 18:01, Michael Butler wrote: > SVN r278414 causes a 'buildworld' to fail. > > The fix is attached, > > imb > *** lib/libedit/readline.c~ Sun Feb 8 17:32:41 2015 --- lib/libedit/readline.c Sun Feb 8 17:55:32 2015 *** *** 395,403 char *buf; static int used_event_hook; - if (line == NULL) - return 0; - if (e == NULL || h == NULL) rl_initialize(); --- 395,400 *** *** 1358,1363 --- 1355,1363 HistEvent ev; int curr_num; + if (line == NULL) + return 0; + if (h == NULL || e == NULL) rl_initialize(); signature.asc Description: OpenPGP digital signature
Re: SVN r278414 is incorrect
On 02/08/15 18:03, Michael Butler wrote: > On 02/08/15 18:01, Michael Butler wrote: >> SVN r278414 causes a 'buildworld' to fail. >> >> The fix is attached, >> >> imb Index: lib/libedit/readline.c === --- lib/libedit/readline.c (revision 278418) +++ lib/libedit/readline.c (working copy) @@ -395,9 +395,6 @@ char *buf; static int used_event_hook; - if (line == NULL) - return 0; - if (e == NULL || h == NULL) rl_initialize(); @@ -1443,6 +1440,9 @@ HistEvent ev; int curr_num; + if (line == NULL) + return 0; + if (h == NULL || e == NULL) rl_initialize(); ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN r279031 breaks net-snmp
It seems that net-snmp wants struct ifaddr and now fails on -CURRENT with: libtool: compile: cc -I../../include -I. -I../../agent -I../../agent/mibgroup -I../../snmplib -I/usr/include -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -O2 -pipe -march=core2 -I/usr/local/include -I/include -D_WANT_IFADDR -fstack-protector -fno-strict-aliasing -std=c99 -Ufreebsd11 -Dfreebsd11=freebsd11 -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/usr/local/lib/perl5/5.18/mach/CORE -c mibII/ipv6.c -fPIC -DPIC -o mibII/.libs/ipv6.o mibII/ipv6.c:806:20: warning: returning 'char *' from a function with result type 'u_char *' (aka 'unsigned char *') converts between pointers to integer types with different sign [-Wpointer-sign] return p; ^ mibII/ipv6.c:848:29: error: variable has incomplete type 'struct ifaddr' struct ifaddr ifaddr; ^ /usr/include/net/if_var.h:89:24: note: forward declaration of 'struct ifaddr' TAILQ_HEAD(ifaddrhead, ifaddr); /* instantiation is preserved in the list */ ^ /usr/include/sys/queue.h:493:9: note: expanded from macro 'TAILQ_HEAD' struct type *tqh_first; /* first element */ \ ^ 1 warning and 1 error generated. *** Error code 1 Stop. make[4]: stopped in /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/agent/mibgroup *** Error code 1 signature.asc Description: OpenPGP digital signature
Fwd: SVN r379206 breaks www/webkit-gtk3
Any ideas on this would be helpful: Forwarded Message Subject: SVN r379206 breaks www/webkit-gtk3 Date: Thu, 19 Feb 2015 08:13:21 -0500 From: Michael Butler To: k...@freebsd.org The most recent update to webkit-gtk3 breaks on -CURRENT as follows: CXX Source/WTF/wtf/text/libWTF_la-WTFString.lo CXX Source/WTF/wtf/threads/libWTF_la-BinarySemaphore.lo CXX Source/WTF/wtf/unicode/libWTF_la-CollatorDefault.lo CXX Source/WTF/wtf/unicode/libWTF_la-UTF8.lo CXX Source/WTF/wtf/unicode/icu/libWTF_la-CollatorICU.lo GEN DerivedSources/WebCore/InspectorWebBackendDispatchers.cpp CXXLDlibWTF.la CXXLDPrograms/LLIntOffsetsExtractor /usr/bin/ld:./.libs/libWTF.a: file format not recognized; treating as linker script /usr/bin/ld:./.libs/libWTF.a:1: syntax error c++: error: linker command failed with exit code 1 (use -v to see invocation) GNUmakefile:40539: recipe for target 'Programs/LLIntOffsetsExtractor' failed gmake[2]: *** [Programs/LLIntOffsetsExtractor] Error 1 gmake[2]: Leaving directory '/usr/ports/www/webkit-gtk3/work/webkitgtk-2.4.8' ===> Compilation failed unexpectedly. imb signature.asc Description: OpenPGP digital signature
