DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082023-02-08T23:53:40ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3343 (Closed): New cookie_* functions in stdio.h should be guarded by somethinghttps://bugs.dragonflybsd.org/issues/33432023-02-08T23:53:40Zdavshao
<p>fopencookie(3): Add a wrapper around funopen(3)<br />commit a765cedf26cef470ba7deee42c365f0221690a1a<br />Date: Sat Feb 4 14:54:20 2023 +0100</p>
<p>changed /usr/include/stdio.h to add</p>
<p><ins>typedef ssize_t (cookie_read_function_t)(void *, char *, size_t);<br />+typedef ssize_t (cookie_write_function_t)(void *, const char *, size_t);<br />+typedef int (cookie_seek_function_t)(void *, off64_t *, int);<br />+typedef int (cookie_close_function_t)(void *);<br />+typedef struct {<br /></ins> cookie_read_function_t *read;<br />+ cookie_write_function_t *write;<br />+ cookie_seek_function_t *seek;<br />+ cookie_close_function_t *close;<br />+} cookie_io_functions_t;<br />+FILE *fopencookie(void *, const char *, cookie_io_functions_t);</p>
<p>These new functions are guarded by nothing, yet ssize_t has a definition<br />in the same header file guarded by something. Trying to build say png,<br />the compile is confused about ssize_t, among other things. For now, moving</p>
<p>#endif /* __BSD_VISIBLE */</p>
<p>to cover the new functions and structs allows png to build, but I<br />cannot guarantee other packages will regard this as sufficient.</p> DragonFlyBSD - Bug #3325 (Closed): Revert sys/vfs/hammer2: Properly set rdonly flag for PFShttps://bugs.dragonflybsd.org/issues/33252022-09-10T18:20:37Zdavshao
<p>After <br />sys/vfs/hammer2: Properly set rdonly flag for PFS<br />commit 5f5122fa2471887600e87e29917d577f65d73a05<br />Date: Wed Sep 7 00:11:28 2022 -0700</p>
<p>the system boots but there are read(only) errors reported with ttys not created, dhcp not working, etc.<br />Bisected to this particular commit.</p>
<p>Maybe unusual these days, I am using grub2 to boot from an ssd (not nvme) formatted mbr.</p>
<p>Here is the /etc/fstab:</p>
<ol>
<li>Device Mountpoint FStype Options Dump Pass#<br />/dev/serno/2017E29D5A8C.s1a /boot ufs rw 2 2<br />/dev/serno/2017E29D5A8C.s1b none swap sw 0 0<br />/dev/serno/2017E29D5A8C.s1d / hammer2 rw 1 1<br />/build/usr.obj /usr/obj null rw 0 0<br />/build/var.crash /var/crash null rw 0 0<br />/build/var.cache /var/cache null rw 0 0<br />/build/var.spool /var/spool null rw 0 0<br />/build/var.log /var/log null rw 0 0<br />/build/var.tmp /var/tmp null rw 0 0<br />tmpfs /tmp tmpfs rw 0 0<br />proc /proc procfs rw 0 0</li>
</ol>
<p>$ uname -a<br />DragonFly xxxxxx 6.3-DEVELOPMENT DragonFly v6.3.0.196.g64e301-DEVELOPMENT #0: Sat Sep 10 10:28:47 PDT 2022 xxxxxx@xxxxxx:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64</p> DragonFlyBSD - Submit #3244 (Resolved): Additional Intel I219-LM and I219-V Ethernet PCI device n...https://bugs.dragonflybsd.org/issues/32442020-08-19T03:06:01Zdavshao
<p>NetBSD current sys/dev/pci/pcidevs.h has additional PCI device numbers for Intel I219-LM and Intel I219-V Ethernet. Simply adding these numbers has been verified to enable em0 on an Asus Prime H470-Plus mATX motherboard for I219-V11 0x0D4D. Also NetBSD current had no problem activating its wm0 Ethernet device for this motherboard.</p>
<p>Note that Phoronix had an article "DragonFlyBSD vs. FreeBSD vs. Ubuntu 20.04 On Intel's Core i9 10900K Comet Lake" that noted on-board Ethernet was not functional on either FreeBSD 12 or DragonFly BSD, and that claimed that even for Linux, 5.6 or later was required. That claim may be incorrect for at least obtaining some minimal functionality on DragonFly for very little effort.</p>
<p>Attached is a patch adding the numbers from NetBSD. The naming of the devices using "CNP", which I believe is an abbreviation for previous generation codename Cannon Point chipsets, is arguably incorrect; however, I was unable to locate any code name at all for current series 400 Intel chipsets. In any case, for at least one device, the Cannon Point handler appears to work unchanged.</p> DragonFlyBSD - Submit #3145 (Closed): Update libelf to FreeBSD 12 current and build as base libra...https://bugs.dragonflybsd.org/issues/31452018-09-04T06:55:37Zdavshao
<p>DragonFly dports graphics/mesa-dri has</p>
<p><code>LIB_DEPENDS+= libelf.so:devel/libelf</code></p>
<p>FreeBSD links with its own base libelf and does not use ports devel/libelf.<br />FreeBSD is right in its approach. ports devel/libelf and base libelf are<br />different code bases. Ports or pkgsrc devel/libelf appears to have problems<br />with modern mesa. This can be seen using some Radeon graphics cards where<br />Firefox with<br /><code>user_pref("layers.acceleration.force-enabled", true);</code><br />results in a completely black window when trying to start Firefox with<br />something like<br /><code>LD_PRELOAD=/usr/local/lib/libGL.so firefox &</code><br />What is notable about this patch is just how little the result will<br />differ from FreeBSD 12 current's version.</p> DragonFlyBSD - Submit #3031 (Closed): Update drm/radeon to Linux 4.7.10 as much as possiblehttps://bugs.dragonflybsd.org/issues/30312017-04-27T04:00:18Zdavshao
<p>Sometimes one must go backwards before one can go forwards. The attached patch updates drm/radeon to Linux 4.7.10 as much as possible, with the obvious exception of patches related to dma_fence, reservation objects, dma_buf, prime, DisplayPort MST, and interval trees. In particular, because I do not have DisplayPort hardware to test, I expect complete breakage.</p>
<p>When I want decent font display without corruption on a CAICOS Sapphire Radeon HD6450 card, I use in a hacked version of pkgsrc for mesa 17 in /usr/pkg/share/X11/xorg.conf.d a 20-glamor.conf file resembling:</p>
<pre>
Section "Module"
Load "dri2"
Load "glamoregl"
EndSection
Section "Device"
Identifier "Radeon Graphics"
Driver "radeon"
Option "AccelMethod" "glamor"
Option "ShadowPrimary" "on"
EndSection
</pre>
<p>Take out the Option "ShadowPrimary" "on" and there are quite visible artifacts, but I am still able to fire up firefox using</p>
<p><code>LD_PRELOAD=/usr/pkg/lib/libGL.so firefox &</code></p>
<p>with layers acceleration forced to get some sort of display in WebGL Water:</p>
<p><a class="external" href="http://madebyevan.com/webgl-water/">http://madebyevan.com/webgl-water/</a></p>
<p>The patch is radeon47fast.patch generated by git format patch. Also attached is a diff between drm/radeon after the patch compared to Linux 4.7.10's. radeon_4_07.diff shows exactly what is left to be done.</p>
<p>The patch seems to apply cleanly up through at least</p>
<pre>
commit f30091155bf042c3e2934ca63573dabebe30f556
Date: Mon Apr 24 19:22:39 2017 +0200
<fcntl.h>: Add some missing defines (required by POSIX).
</pre> DragonFlyBSD - Submit #3026 (Resolved): Patch to enable HDMI audio for Gigabyte Radeon R7 240https://bugs.dragonflybsd.org/issues/30262017-04-13T01:27:10Zdavshao
<p>In a years old thread</p>
<p>amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)</p>
<p><a class="external" href="https://lists.freebsd.org/pipermail/freebsd-current/2010-July/018764.html">https://lists.freebsd.org/pipermail/freebsd-current/2010-July/018764.html</a></p>
<p>Andriy Gapon suggested the following patches to enable HDMI audio for<br />an ATI/AMD video card. But at that time the original poster was not<br />able to actually get the sound device to properly attach.</p>
<p>Well these patches DO work for DragonFly, at least using a custom kernel<br />starting from master sometime in the last couple of weeks with<br />radeon audio patches from Linux 4.7.10 (adding radeon_audio.c and radeon_audio.h<br />and updating everything related).</p>
<p>I startx using xfce4 and a custom version of pkgsrc with mesa 17, xorg server 19.3</p>
<ol>
<li>kldload snd_hda</li>
</ol>
<p>Read the end of dmesg:</p>
<p>[drm] Initialized radeon 2.40.0 20080528<br />hdac0: <Intel Panther Point HDA Controller> mem 0xf7f10000-0xf7f13fff irq 22 at device 27.0 on pci0<br />hdac0: link ctrl 0x800<br />hdac0: disable nosnoop<br />hdac1: <ATI (0xaab0) HDA Controller> mem 0xf7e60000-0xf7e63fff irq 17 at device 0.1 on pci2<br />hdac1: link ctrl 0x2800<br />hdac1: disable nosnoop<br />hdacc0: <VIA VT1708S_0 HDA CODEC> at cad 0 on hdac0<br />hdaa0: <VIA VT1708S_0 Audio Function Group> at nid 1 on hdacc0<br />hdacc1: <ATI R6xx HDA CODEC> at cad 0 on hdac1<br />hdaa1: <ATI R6xx Audio Function Group> at nid 1 on hdacc1<br />pcm0: <VIA VT1708S_0 (Analog 7.1+HP/2.0)> at nid 28,34,25,35,29 and 26,30,27 on hdaa0<br />pcm1: <VIA VT1708S_0 (Digital)> at nid 32 on hdaa0<br />pcm2: <VIA VT1708S_0 (Rear-panel Digital)> at nid 33 on hdaa0<br />pcm3: <ATI R6xx (HDMI)> at nid 3 on hdaa1</p>
<ol>
<li>sysctl hw.snd.default_unit=3<br />hw.snd.default_unit: 0 -> 3</li>
</ol>
<p>fire up firefox, go to youtube and listen to whatever.</p>
<p>The following patches are safer for DragonFly because by default<br />no sound drivers are loaded. Original poster actually had<br />kernel crashes because on his version of FreeBSD sound drivers<br />were automatically loaded. Also there was a claim at the time,<br />least if the initial value of corb_size was 0, that Linux actually does<br />do some default assumption of 256.</p>
<p>diff --git a/sys/dev/sound/pci/hda/hdac.c b/sys/dev/sound/pci/hda/hdac.c<br />index d63843a10f..2178243f88 100644<br />--- a/sys/dev/sound/pci/hda/hdac.c<br />+<ins>+ b/sys/dev/sound/pci/hda/hdac.c<br /><code>@ -488,7 +488,15 </code>@ hdac_get_capabilities(struct hdac_softc *sc)<br /> else {<br /> device_printf(sc->dev, "%s: Invalid corb size (%x)\n",<br /> <i>func</i>, corbsize);<br />- return (ENXIO);<br /></ins> if (1) {<br />+ device_printf(sc->dev, "Resetting corb size to 256\n");<br />+ sc->corb_size = 256;<br />+ corbsize =<br />+ HDAC_CORBSIZE_CORBSIZE(HDAC_CORBSIZE_CORBSIZE_256);<br />+ HDAC_WRITE_1(&sc->mem, HDAC_CORBSIZE, corbsize);<br />+ }<br />+ else<br />+ return (ENXIO);<br /> }</p>
<pre><code>rirbsize = HDAC_READ_1(&sc->mem, HDAC_RIRBSIZE);<br /><code>@ -504,7 +512,15 </code>@ hdac_get_capabilities(struct hdac_softc *sc)<br /> else {<br /> device_printf(sc->dev, "%s: Invalid rirb size (%x)\n",<br /> <i>func</i>, rirbsize);<br />- return (ENXIO);<br />+ if (1) {<br />+ device_printf(sc->dev, "Resetting rirb size to 256\n");<br />+ sc->rirb_size = 256;<br />+ rirbsize =<br />+ HDAC_RIRBSIZE_RIRBSIZE(HDAC_RIRBSIZE_RIRBSIZE_256);<br />+ HDAC_WRITE_1(&sc->mem, HDAC_RIRBSIZE, rirbsize);<br />+ }<br />+ else<br />+ return (ENXIO);<br /> }</code></pre>
<pre><code>HDA_BOOTVERBOSE(<br /><code>@ -1211,6 +1227,8 </code>@ hdac_attach(device_t dev)<br /> if (result != 0)<br /> goto hdac_attach_fail;</code></pre>
<p>+ hdac_reset(sc, 1);<br />+<br /> /* Get Capabilities */<br /> result = hdac_get_capabilities(sc);<br /> if (result != 0)</p> DragonFlyBSD - Bug #2994 (New): Intermittent boot hangs after git: hammer - HAMMER Version 7https://bugs.dragonflybsd.org/issues/29942017-03-28T18:44:52Zdavshao
<p>Bisected to git: hammer - HAMMER Version 7<br />commit 4c09d9c4fd910651904ede280ad90a4abf3fc5d7<br />Date: Fri Mar 17 14:06:24 2017 -0700</p>
<pre><code>hammer - HAMMER Version 7</code></pre>
<p>intermittent boot hangs stopping at</p>
<p>ums0: <Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/20.00, addr 5> on usb<br />ums0: 3 buttons and [XYX] coordinates ID=0<br />no B_DEVMAGIC (bootdev=0)</p>
<p>Boot proceeds normally when using verbose option which is why I can attach<br />the verbose dmesg.</p>
<p>The machine uses a refurbished Asus P8H77-V motherboard with several<br />internal hard drives with different OSes using legacy BIOS.</p>
<p>$ hammer info<br />Volume identification<br /> Label ROOT<br /> No. Volumes 1<br /> HAMMER Volumes /dev/serno/WD-WMAYP5624974.s3d<br /> Root Volume /dev/serno/WD-WMAYP5624974.s3d<br /> FSID 9d8141cd-c974-11e5-9ccd-bd5ff4499104<br /> HAMMER Version 6<br />Big-block information<br /> Total 29669<br /> Used 9119 (30.74%)<br /> Reserved 70 (0.24%)<br /> Free 20480 (69.03%)<br />Space information<br /> No. Inodes 856028<br /> Total size 232G (248881610752 bytes)<br /> Used 71G (30.74%)<br /> Reserved 560M (0.24%)<br /> Free 160G (69.03%)<br />PFS information<br /> PFS# Mode Snaps<br /> 0 MASTER 0 (root PFS)</p> DragonFlyBSD - Submit #2985 (Closed): Move drm linux_*.c files to subdirectory drm/linuxhttps://bugs.dragonflybsd.org/issues/29852017-03-22T00:47:50Zdavshao
<p>This patch moves the linux_*.c files under sys/dev/drm to their own<br />sub-directory sys/dev/drm/linux.</p>
<p>The idea is that eventually someone might want to import files<br />from FreeBSD linuxkpi. Though at some point the obvious question<br />is should these files and others added be turned into their own<br />separate module that can be used by drivers other than<br />the drm graphics ones, similar to what FreeBSD does with linuxkpi.</p>
<p>I don't really care where these files are moved: I just want them<br />moved somewhere to have their own separate identity.</p> DragonFlyBSD - Bug #2964 (Resolved): make upgrade REMOVE_OPENSSL_FILES=yes incompatible with make...https://bugs.dragonflybsd.org/issues/29642016-11-02T20:57:53Zdavshao
<p>On DragonFly master, for a previous recent build, if one does</p>
<p>make upgrade REMOVE_OPENSSL_FILES=yes</p>
<p>then updates to the latest master source, then</p>
<p>cd /usr/obj<br />mv usr usr.old<br />cd /usr/src<br />make buildworld</p>
<p>there seems a good chance one will encounter an error, really fast, such as:</p>
<p>===> bin/cpdup (bootstrap-tools)<br />/usr/obj/usr/src/btools_x86_64/usr/src/bin/cpdup created for /usr/src/bin/cpdup<br />rm -f .depend</p>
<blockquote>
<p>.depend</p>
</blockquote>
<p>mkdep -f .depend -a -std=gnu99 /usr/src/bin/cpdup/cpdup.c /usr/src/bin/cpdup/hcproto.c /usr/src/bin/cpdup/hclink.c /usr/src/bin/cpdup/misc.c /usr/src/bin/cpdup/fsmid.c /usr/src/bin/cpdup/md5.c<br />In file included from /usr/include/md5.h:41:0,<br /> from /usr/src/bin/cpdup/cpdup.h:28,<br /> from /usr/src/bin/cpdup/cpdup.c:58:<br />/usr/include/sys/md5.h:45:25: fatal error: openssl/md5.h: No such file or directory<br />compilation terminated.</p>
<p>It seems to me that cpdup.c includes "cpdup.h" which in turn includes <md5.h> if NOMD5 is undefined,<br />which in turn includes <sys/md5.h>, which in turn includes <openssl/md5.h>,<br />which after make upgrade REMOVE_OPENSSL_FILES doesn't exist anymore.</p> DragonFlyBSD - Bug #2961 (Closed): undefined reference to 'pthread_cancel' building multimedia/ff...https://bugs.dragonflybsd.org/issues/29612016-10-27T04:34:01Zdavshao
<p>I am classifying the following as a master source regression and not a dports issue because multimedia/ffmpegthumbnailer was building until yesterday without issue in a hacked version of pkgsrc I have been using. Some change from October 25 breaks building both on pkgsrc and dports.</p>
<p>To demonstrate the problem using dports, update to master source through:</p>
<p>commit 62a4e7957a736b4de38938b02fa7eb9b45bc5d0d<br />Date: Tue Oct 25 23:04:45 2016 +0200</p>
<pre><code>if_iwm - Switch arguments from iwm_node* to iwm_vap* in if_iwm_power.c.</code></pre>
<p>Now build dports git, xorg, xfce4 from scratch using:</p>
<p>make clean && make NO_DIALOG=yes install clean</p>
<p>Now try building for multimedia/ffmpegthumbnailer. I would guess one would obtain an error similar to:</p>
<p>CMake Warning:<br /> Manually-specified variables were not used by the project:</p>
<pre><code>CMAKE_CXX_FLAGS_DEBUG<br /> CMAKE_C_FLAGS_DEBUG<br /> CMAKE_C_FLAGS_RELEASE<br /> CMAKE_MODULE_LINKER_FLAGS<br /> THREADS_HAVE_PTHREAD_ARG</code></pre>
<p>...</p>
<p>--- ffmpegthumbnailer ---<br />[ 83%] Linking CXX executable ffmpegthumbnailer<br />/usr/local/bin/cmake -E cmake_link_script CMakeFiles/ffmpegthumbnailer.dir/link.txt --verbose=1<br />/usr/bin/c++ -pipe -g -O2 -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -std=c++11 -pipe -g -O2 -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include CMakeFiles/ffmpegthumbnailer.dir/main.cpp.o -o ffmpegthumbnailer libffmpegthumbnailer.so.4.11.0 /usr/local/lib/libavformat.so /usr/local/lib/libavcodec.so /usr/local/lib/libavutil.so /usr/local/lib/libswscale.so /usr/local/lib/libjpeg.so /usr/local/lib/libpng.so -lz -Wl,-rpath,/usr/obj/dports/multimedia/ffmpegthumbnailer/.build:/usr/local/lib <br />libffmpegthumbnailer.so.4.11.0: error: undefined reference to 'pthread_cancel'<br />collect2: error: ld returned 1 exit status</p>
<p>The /etc/make.conf I used is a simple:</p>
<ol>
<li>cat /etc/make.conf<br />CFLAGS+=-g<br />STRIP=</li>
</ol>
<p>WITH_PKGNG=yes<br />DISABLE_VULNERABILITIES=yes</p>
<p>WITH_VIM_OPTIONS=yes</p> DragonFlyBSD - Bug #2927 (Closed): e2a21467e1 Updates to show "4.7" and other changes to major he...https://bugs.dragonflybsd.org/issues/29272016-07-21T01:46:35Zdavshao
<p>commit 5d920ec6b97613f06aba4a09bfb91413b1fd93c3 Fix excessive ipiq recursion (2)<br />does not correct the problem I have observed on at least two machines that</p>
<p>make -j7 buildworld</p>
<p>locks up the machine. (When using make buildworld I move /usr/obj/usr to start the build from scratch.) On one machine there seems to be a reproducible lock up at</p>
<p>sh /usr/src/tools/install.sh -o root -g wheel -m 555 lto1 /usr/obj/usr/src/ctools_x86_64_x86_64/usr/libexec/gcc50</p>
<p>Changes to major headers should be temporarily suspended until this problem is resolved, because I have observed that even</p>
<p>make quickworld</p>
<p>can fail to complete without lockup. Someone using UFS as their filesystem may experience quite substantial filesystem corruption after a lockup. By limiting changes to major headers, this gives the greatest chance of a successful make quickworld when this problem is finally resolved.</p> DragonFlyBSD - Bug #2737 (Closed): i386 drm_bufs.c:259:2 '%lx' offset type 'resource_size_t'https://bugs.dragonflybsd.org/issues/27372014-11-18T16:19:09Zdavshao
<p>i386 GENERIC kernel compilation fails with</p>
<p>/usr/src/sys/dev/drm/drm/../drm_bufs.c: In function 'drm_addmap':<br />/usr/src/sys/dev/drm/drm/../drm_bufs.c:259:2: error: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'resource_size_t' [-Werror=format]<br />cc1: all warnings being treated as errors</p>
<p>Argument offset is type resource_size_t which appears to be vm_paddr_t and thus __unit64_t.</p>
<p>A patch similar to the below fixes compilation problems on i386:</p>
<p>diff --git a/sys/dev/drm/drm_bufs.c b/sys/dev/drm/drm_bufs.c<br />index 575dbcf..7c66ea8 100644<br />--- a/sys/dev/drm/drm_bufs.c<br />+++ b/sys/dev/drm/drm_bufs.c<br /><code>@ -256,7 +256,7 </code>@ int drm_addmap(struct drm_device * dev, resource_size_t offset,<br /> done:<br /> /* Jumped to, with lock held, when a kernel map is found. */</p>
<p>- DRM_DEBUG("Added map %d 0x%lx/0x%lx\n", map->type, map->offset,<br />+ DRM_DEBUG("Added map %d 0x%lx/0x%lx\n", map->type, (unsigned long)map->offset,<br /> map->size);</p>
<pre><code>*map_ptr = map;</code></pre> DragonFlyBSD - Bug #2640 (Closed): cp -R kernel does not boot on two older pure i386 PCshttps://bugs.dragonflybsd.org/issues/26402014-02-17T04:26:22Zdavshao
<p>On a Pentium 4 PC, Asus P4B266 motherboard, and on a Lenovo Ideapad Intel Atom N270, both pure i386 and with 1GB of RAM, copying a kernel from /boot such as<br />cp -R kernel kernel.good<br />does not result in a bootable kernel. Booting fails at the loader prompt with:</p>
<p>can't load 'kernel'<br />boot: no bootable kernel</p>
<p>cd-ing into /boot/kernel.old boots properly.</p>
<p>The same cp-ing procedure results in bootable kernels even running i386 on 64-bit machines or even i386 in Vmware Fusion on a 64-bit Macbook.</p>
<p>Booting is done from Ubuntu LTS 12.04 grub2. The original installations date back to early 2010.</p>
<p>Examination using</p>
<p>ls -loa</p>
<p>shows no unusual flags or permissions in /boot. But an obvious question is should the schg flag be temporarily removed from /boot/kernel/kernel when copying?</p>
<p>Also, should there be a symbolic link of kernel.BOOTP -> kernel in directory /boot/kernel?</p> DragonFlyBSD - Bug #2505 (Closed): i386 buildkernel cc1: error: too many filenames given /usr/ob...https://bugs.dragonflybsd.org/issues/25052013-02-04T07:12:36Zdavshao
<p>On a i386 build updating from</p>
<p>commit e2a099cf1b1188b60aecc18de449444f7dca0f6a<br />Date: Fri Feb 1 13:47:37 2013 -0800</p>
<pre><code>kernel - Fix kernel panic caused by rename race</code></pre>
<p>to</p>
<p>commit 6de060a4493ce25dda4287f3ab00041b698ba2b8<br />Date: Sun Feb 3 13:32:01 2013 +0100</p>
<pre><code>Unbreak world with NO_GCC44</code></pre>
<p>with /etc/make.conf</p>
<p>CFLAGS+=-g<br />STRIP=</p>
<ol>
<li>make buildworld && make buildkernel</li>
</ol>
<p>ends with an error:<br />===> bus/cam/cam<br />@ -> /usr/src/sys/bus/cam/cam/../../..<br />echo "#define SCSI_DELAY 15000" > opt_scsi.h<br />rm -f .depend</p>
<blockquote>
<p>.depend</p>
</blockquote>
<p>mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I. -I@ -I/usr/obj/usr/src/sys/GENERIC -I/usr/obj/usr/src/sys/GENERIC/include -I@/../include -I/usr/obj/usr/src/world_i386/usr/include -std=c99 -std=gnu99 -std=c99 /usr/src/sys/bus/cam/cam/../cam.c /usr/src/sys/bus/cam/cam/../cam_periph.c /usr/src/sys/bus/cam/cam/../cam_queue.c /usr/src/sys/bus/cam/cam/../cam_sim.c /usr/src/sys/bus/cam/cam/../cam_xpt.c /usr/src/sys/bus/cam/cam/../cam_extend.c /usr/src/sys/bus/cam/cam/../scsi/scsi_all.c /usr/src/sys/bus/cam/cam/../scsi/scsi_cd.c /usr/src/sys/bus/cam/cam/../scsi/scsi_ch.c /usr/src/sys/bus/cam/cam/../scsi/scsi_da.c /usr/src/sys/bus/cam/cam/../scsi/scsi_pass.c /usr/src/sys/bus/cam/cam/../scsi/scsi_pt.c /usr/src/sys/bus/cam/cam/../scsi/scsi_sa.c /usr/src/sys/bus/cam/cam/../scsi/scsi_ses.c /usr/src/sys/bus/cam/cam/../scsi/scsi_targ_bh.c /usr/src/sys/bus/cam/cam/../scsi/scsi_target.c<br />cc1: error: too many filenames given. Type cc1 --help for usage<br />cc1: fatal error: /usr/obj/usr/src/world_i386/usr/include: No such file or directory<br />compilation terminated.<br />cc1: error: too many filenames given. Type cc1 --help for usage<br />cc1: fatal error: /usr/obj/usr/src/world_i386/usr/include: No such file or directory<br />compilation terminated.<br />cc1: error: too many filenames given. Type cc1 --help for usage<br />cc1: fatal error: /usr/obj/usr/src/world_i386/usr/include: No such file or directory<br />compilation terminated.<br />cc1: error: too many filenames given. Type cc1 --help for usage<br />cc1: fatal error: /usr/obj/usr/src/world_i386/usr/include: No such file or directory<br />compilation terminated.</p>
<p>...</p>
cc1: fatal error: /usr/obj/usr/src/world_i386/usr/include: No such file or directory<br />compilation terminated.<br />mkdep: compile failed
<ul>
<li>Error code 1</li>
</ul>
Stop.<br />make: stopped in /usr/src/sys/bus/cam/cam
<ul>
<li>Error code 1</li>
</ul>
Stop.<br />make: stopped in /usr/src/sys/bus/cam
<ul>
<li>Error code 1</li>
</ul>
Stop.<br />make: stopped in /usr/src/sys/bus
<ul>
<li>Error code 1</li>
</ul>
Stop.<br />make: stopped in /usr/src/sys
<ul>
<li>Error code 1</li>
</ul>
Stop.<br />make: stopped in /usr/obj/usr/src/sys/GENERIC
<ul>
<li>Error code 1</li>
</ul>
Stop.<br />make: stopped in /usr/src<br />.CURDIR='/usr/src'<br />.OBJDIR='/usr/obj/usr/src'<br />.MAKE='make'<br />MAKE_VERSION='20121010'<br />LD_LIBRARY_PATH=''<br />MACHINE_ARCH='i386'<br />MACHINE='i386'<br />MAKEFILE='/usr/src/Makefile.inc1'<br />.TARGETS='buildkernel'<br />.ERROR_TARGET='buildkernel'<br />.ERROR_META_FILE=''<br />.MAKE.LEVEL='1'<br />.MAKE.MODE=''
<ul>
<li>Error code 1</li>
</ul> DragonFlyBSD - Bug #2414 (In Progress): Lenovo S10 acpi freeze (not new)https://bugs.dragonflybsd.org/issues/24142012-08-28T22:58:55Zdavshao
<p>The Lenovo S10 is a netbook that apparently uses an Intel 945 express chipset.<br />I can't say any recent update has broken booting when acpi is enabled: acpi has never functioned for DragonFly.</p>
<p>Using master through 859bc3f7658630c523bbad944a2b95089f48de46 tcp: RFC3517bis is now officially RFC6675</p>
<p>Locks up after booting with acpi enabled at:</p>
<p>cryptosoft0: <software crypto> [attached!] on motherboard<br />acpi0.nexus0.root0<br />acpi0: <LENOVO CB-01> [tentative on motherboard]<br />ndepotmags=6 x mag_cap=22 for Acpi-Namespace<br />ndepotmags=6 x mag_cap=22 for Acpi-State<br />ndepotmags=6 x mag_cap=22 for Acpi-Parse<br />ndepotmags=6 x mag_cap=22 for Acpi-ParseExt<br />ndepotmags=6 x mag_cap=22 for Acpi-Operand<br />IOAPIC: irq9, gsi 9 edge/high -> level/low</p>
<p>Here are some pieces from dmesg after booting with acpi disabled:</p>
<p>ACPI SDT: RSDP not in EBDA<br />ACPI SDT: RSDP in BIOS mem<br />ACPI FADT: SCI irq 9, level/low<br />MPTABLE: warning duplicated PCI int entry for bus 0, dev 29, pin 0<br />MPTABLE: warning duplicated PCI int entry for bus 0, dev 31, pin 1<br />MPTABLE: warning duplicated PCI int entry for bus 0, dev 31, pin 1<br />...<br />CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.02-MHz 686-class CPU)<br /> Origin = "GenuineIntel" Id = 0x106c2 Stepping = 2<br /> Features=0xbfe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE><br /> Features2=0x40c39d<SSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE><br /> AMD Features=0x100000<NX><br /> AMD Features2=0x1<LAHF><br />...<br />ACPI MADT: LAPIC address 0xfee00000, flags 0x1<br />ACPI MADT: BSP apic id 0<br />ACPI MADT: cpu id 0, apic id 0<br />ACPI MADT: cpu id 1, apic id 1<br />lapic: divisor index 0, frequency 66500312 Hz<br />SMP: CPU0 apic_initialize():<br /> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff<br />SMP: Waiting APs LAPIC initialization<br />SMP: CPU1 apic_initialize():<br /> lint0: 0x00010000 lint1: 0x00010400 TPR: 0x00000000 SVR: 0x000001ff<br />ACPI MADT: warning invalid intsrc irq 9 trig, level<br />ACPI MADT: IOAPIC addr 0xfec00000, apic id 2, gsi base 0<br />ACPI MADT: INTSRC irq 0 <del>> gsi 2 edge/high<br />...<br />IOAPIC: irq 9, gsi 9 -> cpu0 (sci)<br />IOAPIC: irq 9 -> gsi 9 edge/high<br />...<br />IOAPIC: legacy irq max 24<br />...<br />ELCR Found. ISA IRQs programmed as:<br /> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15<br /> E E E L E L E E E E L L E E E E<br />MPTABLE: 0:28 INTA -> IOAPIC 0.17<br />MPTABLE: 0:27 INTA -> IOAPIC 0.22<br />MPTABLE: 0:29 INTB -> IOAPIC 0.19<br />MPTABLE: 0:2 INTA -> IOAPIC 0.16<br />MPTABLE: 0:28 INTB -> IOAPIC 0.16<br />MPTABLE: 0:28 INTC -> IOAPIC 0.18<br />MPTABLE: 0:29 INTA -> IOAPIC 0.23<br />MPTABLE: 0:29 INTC -> IOAPIC 0.18<br />MPTABLE: 0:29 INTD -> IOAPIC 0.16<br />MPTABLE: 0:31 INTB -> IOAPIC 0.19<br />MPTABLE: 2:0 INTA -> IOAPIC 0.16<br />...<br />BITS within APICID: logical_CPU_bits: 1; core_bits: 0<br />CPU Topology: cores_per_chip: 1; threads_per_core: 2; chips_per_package: 1;<br />Start scheduler helpers on cpus:<br /> cpu0 - HyperThreading available. Core siblings: cpu0 cpu1 <br /> cpu1 - HyperThreading available. Core siblings: cpu0 cpu1 <br />start dummy scheduler helpers on cpus: 0 1<br />...<br />IOAPIC: rman cpu0 0 - 1<br />IOAPIC: rman cpu0 3 - 95<br />IOAPIC: rman cpu0 97 - 191<br />IOAPIC: rman cpu1 24 - 95<br />IOAPIC: rman cpu1 97 - 191<br />npx0.nexus0.root0<br />npx0: <math processor> [tentative] on motherboard<br />npx0: INT 16 interface<br />Using XMM optimized bcopy/copyin/copyout<br />npx0: <math processor> [attached!] on motherboard<br />cryptosoft0.nexus0.root0<br />cryptosoft0: <software crypto> [tentative] on motherboard<br />crypto: assign cryptosoft0 driver id 0, flags 234881024<br />crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0<br />...<br />crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0<br />cryptosoft0: <software crypto> [attached!] on motherboard<br />pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fa04<br />pci_open(1a): mode1res=0x80000000 (0x80000000)<br />pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27ac8086)<br />pcibios: BIOS version 3.00<br />$PIR: checksum failed!<br />pcib0.legacy0.nexus0.root0<br />pcib0: <MPTABLE Host-PCI bridge> [tentative] pcibus 0 on motherboard<br />pci0.pcib0.legacy0.nexus0.root0<br />pci0: <PCI bus> [tentative] on pcib0<br />pci0: domain=0, physical bus=0<br />found</del>> vendor=0x8086, dev=0x27ac, revid=0x03<br /> domain=0, bus=0, slot=0, func=0<br /> class=06-00-00, hdrtype=0x00, mfdev=0<br /> cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords)<br /> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)<br />found-> vendor=0x8086, dev=0x27ae, revid=0x03<br /> domain=0, bus=0, slot=2, func=0<br />...<br />agp0: <Intel 945GME SVGA controller> [attached!] on vgapci0<br />...<br />usb0: <Intel 82801G (ICH7) USB controller> [tentative] on uhci0</p>