Re: __memcpy_chk family of functions
On Tue, 21 May 2024, Dag-Erling Smørgrav wrote: Marcin Cieslak writes: I think this (useful) change should go into the future release notes as a new feature. Which change? https://reviews.freebsd.org/D32306 Import _FORTIFY_SOURCE implementation from NetBSD which introduced _memcpy_chk and friends to our libc.
Re: __memcpy_chk family of functions
On Tue, May 21, 2024 at 12:16 AM Dag-Erling Smørgrav wrote: The purpose of UPDATING is to document changes that break backward compatibility, i.e. running old binaries on a newer world. happened here is that you tried to run newer binaries on an older world, On Tue, 21 May 2024, Warner Losh wrote: Also, our forward compatibility guarantees are extremely weak. Just for clarification: I am not complaining about my breakage. It was my stunt and it didn't work out, I got punished by sitting there and waiting for llvm to compile. I think this (useful) change should go into the future release notes as a new feature. Where and how should this be documented? Shall FreeBSD_version be bumped for this one? For example, when libsys got introduced, we could learn about this from the UPDATING file. I do not want UPDATING to be come unreadable or a copy of git log, though. Marcin
__memcpy_chk family of functions
Hello, I have updated some binary packages using pkg(8) but neglected to rebuild the world and my favourite web browsers no longer started complaining about the undefined symbol __memcpy_chk@FBSD_1.8 Would that be a good idea to add that information to the Handbook and possible bump FreeBSD_version and add this info to UPDATING? I fully accept that running -CURRENT as a daily driver leads to surprises like this, but it took me a bit long to figure out which change has caused this [1]. I was also thinking, would that be ok to add the synopsis of _memcpy_chk and other functions to the relevant memcpy(3) etc. manpages? Only when viewing the diff I found out I could learn about those from ssp(3). Thanks for keeping FreeBSD alive, Marcin [1] spoiler alert: https://reviews.freebsd.org/D32306
Re: fix WARNING pid 24503 (uhsoctl): ioctl sign-extension ioctl ffffffff8044692b
On Fri, 2 Nov 2018, Hans Petter Selasky wrote: > On 11/2/18 5:24 PM, Enji Cooper (yaneurabeya) wrote: > > signed ioctl value warnings > > in uhsoctl(). > > Here you go: > > https://svnweb.freebsd.org/changeset/base/340089 Thanks! Marcin smime.p7s Description: S/MIME Cryptographic Signature
fix WARNING pid 24503 (uhsoctl): ioctl sign-extension ioctl ffffffff8044692b
The following patch seems to fix the signed ioctl value warnings
in uhsoctl().
The code is the same in the current and stable branches.
Marcin
Index: usr.sbin/uhsoctl/uhsoctl.c
===
--- usr.sbin/uhsoctl/uhsoctl.c (revision 339406)
+++ usr.sbin/uhsoctl/uhsoctl.c (working copy)
@@ -360,7 +360,7 @@
/* Add/remove IP address from an interface */
static int
-ifaddr_ad(int d, const char *ifnam, struct sockaddr *sa, struct sockaddr *mask)
+ifaddr_ad(unsigned long d, const char *ifnam, struct sockaddr *sa, struct
sockaddr *mask)
{
struct ifaliasreq req;
int fd, error;
smime.p7s
Description: S/MIME Cryptographic Signature
Re: savecore: BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276
On Wed, 24 Oct 2018, John Baldwin wrote: > On 10/23/18 10:58 AM, Marcin Cieslak wrote: > > This GDB was configured as "amd64-marcel-freebsd"...BFD: > > /boot/kernel/kernel: invalid relocation type 37 > > BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > > /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276 > > > > The kernel has been built on 11.1 with LD=/usr/bin/ld.lld > > > > Is this something that matters at all? > > It is not something that is likely to be fixed. If you pkg install gdb from > ports, is the kgdb it includes able to examine the crash dump? Not really (using 8.2 from ports): # /usr/local/bin/kgdb82 -n 5 /usr/obj/usr/src/sys/GENERIC/kernel.debug GNU gdb (GDB) 8.2 [GDB v8.2 for FreeBSD] Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd11.1". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/obj/usr/src/sys/GENERIC/kernel.debug...done. thread.c:93: internal-error: struct thread_info *inferior_thread(): Assertion `tp' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) With regular base kgdb I can open it but I can't get any backtrace or anything: Cannot access memory at address 0x0 (kgdb) info reg rax0x0 0 rbx0x0 0 rcx0x0 0 rdx0x0 0 rsi0x0 0 rdi0x0 0 rbp0x0 0x0 rsp0x0 0x0 r8 0x0 0 r9 0x0 0 r100x0 0 r110x0 0 r120x0 0 r130x0 0 r140x0 0 r150x0 0 rip0x0 0 eflags 0x0 0 cs 0x0 0 ss 0x0 0 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 What should I try next? at what stage is bfd involved in the savecore process? Marcin smime.p7s Description: S/MIME Cryptographic Signature
savecore: BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276
Hello, I have a freshly built 12.0-ALPHA10 (r339406) and the kernel panicked at some point (another mail coming on that). I have a full dump partition enabled, but during savecore quite lot BFD assertion messages appear: Tue Oct 23 18:45:53 CEST 2018 FreeBSD radziecki 12.0-ALPHA10 FreeBSD 12.0-ALPHA10 r339406 GENERIC amd64 panic: 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 "amd64-marcel-freebsd"...BFD: /boot/kernel/kernel: invalid relocation type 37 BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276 The kernel has been built on 11.1 with LD=/usr/bin/ld.lld Is this something that matters at all? Marcin smime.p7s Description: S/MIME Cryptographic Signature
Re: gptzfsboot: "ZFS: i/o error - all block copies unavailable" after crash (r297629)
On Sat, 30 Apr 2016, Marcin Cieslak wrote: > (original report: > https://lists.freebsd.org/pipermail/freebsd-virtualization/2016-April/004362.html) > > I am running r298620 as dom0 under Xen, for debugging > some Xen-related crashes. (...) > After a crash, the bootblocks complain on boot > > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > > Can't find /boot/zfsloader > > FreeBSD/x86 boot > Default: zroot:/boot/kernel/kernel > boot: > ZFS: i/o error - all block copies unavailable > After bisecting with /usr/src/lib/libstand and /usr/src/sys/boot it looks that it was r297629 that broke this: r297629 | allanjude | 2016-04-06 23:21:44 + (Wed, 06 Apr 2016) | 13 lines Fix GELIBoot support for GELI sector size is > 512 Add support for 4k sector GELI encrypted partitions to the bootloader This is the default created by the installer Because the IV is different for each sector, and the XTS tweak carries forward you can not decrypt a partial sector if the starting offset is not 0 Make boot2 and the loader read in 4k aligned chunks Reviewed by:ed, oshogbo Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D5820 I am not using geli, and my sectors are 512 bytes. Marcin ___ 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"
gptzfsboot: "ZFS: i/o error - all block copies unavailable" after crash
(original report: https://lists.freebsd.org/pipermail/freebsd-virtualization/2016-April/004362.html) I am running r298620 as dom0 under Xen, for debugging some Xen-related crashes. Two drives, ada0 and ada1 in a mirror configuration (swap via gmirror): =>34 5860533101 ada0 GPT (2.7T) 341024 1 freebsd-boot (512K) 1058 4194304 2 freebsd-swap (2.0G) 4195362 5856337773 3 freebsd-zfs (2.7T) pool: zroot state: ONLINE scan: scrub repaired 0 in 0h7m with 0 errors on Mon Apr 25 19:22:30 2016 config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 ada1p3 ONLINE 0 0 0 After a crash, the bootblocks complain on boot ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable Can't find /boot/zfsloader FreeBSD/x86 boot Default: zroot:/boot/kernel/kernel boot: ZFS: i/o error - all block copies unavailable (...) When I boot a rescue system (10.3) via PXE I can import the pool without any problems (using "zpool import -R /mnt zroot"). Installing 10.3 /boot/gptzfsboot in the ada0p1/ada1p1 boot blocks makes the problem go away - I can crash the system as many times I like and the next boot works fine. Just restoring -current /boot/gptzfsboot does not usually help. Marcin ___ 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: Dual booting FreeBSD and Win95
On Thu, 9 Apr 2015, Slawa Olhovchenkov wrote: On Wed, Apr 08, 2015 at 03:30:41PM -0400, Ryan Stone wrote: I've been playing around with trying to set one only slice as active to make the loader boot it, but it appears that doesn't actually work. boot0cfg would cover half of the use case (switching from FreeBSD back to Win95), but I'm not sure how I could do the original switch from Win95 to FreeBSD. For this you must use any fdisk-like dos utility can change active partiton mark. Sorry, I am currently don't have neir Win95 or DOS for advice and/or test. As I remember this utilitys must be exist. We have a bunch of cool tools in ftp://ftp.freebsd.org/pub/FreeBSD/tools/ like bootinst.exe, alternative boot managers etc. etc. //Marcin ___ 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: Dual booting FreeBSD and Win95
On Wed, 8 Apr 2015, Ryan Stone wrote: No, this isn't a late April Fools joke. :( We've discussed just switching hard drives, but we really want to shoot for a 100% automated process. Anybody have any ideas? I guess due to hardware interfacing virtualization is not an option? I've seen some testing equipment running Win98 only because it allows direct access to serial ports, not exposing some kind of virtual device driver. //arcin ___ 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: Dual booting FreeBSD and Win95
On Wed, 8 Apr 2015, Slawa Olhovchenkov wrote: On Wed, Apr 08, 2015 at 03:30:41PM -0400, Ryan Stone wrote: 4. (optional) create windows95 boot.ini for fail back load FreeBSD http://support.microsoft.com/en-us/kb/157992 I think boot.ini comes with ntldr, and Win95/98 started DOS-like.. //Marcin ___ 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: Bazaaring the cathedral (Lowering the Barrier to Entry)
On Wed, 1 Apr 2015, Eitan Adler wrote: Hi all, One of the key reasons for the lack of people is the high barrier of entry to joining the FreeBSD project. While every modern project uses git (usually hosted on github), As much as I love github - please try to go to http://github.com/freebsd/freebsd-ports and try to view history of one particular port. Example task I am facing right now: I need to compile iojs 1.0.4 using older version of FreeBSD port. Github web interface says to me: Sorry, this commit history is taking too long to generate. Refresh the page to try again, or view this history locally using the following command: git log master -- www/iojs/Makefile Sure one might argue every ports should be a separate repository and we should use git submodules. No, thank you. Our wiki and code review tools are in an even worse position than our repository. In order to contribute you need to send an email to clusteradm@ and hope they deem you worthy enough of access. The bug tracking system is in a better shape but isn't perfect: while any user can create an account, their privileges are limited: they can't help close out bad PRs, reclassify good ones, or do other generally useful work. I am pretty frustrated I can't login to Phabricator without @freebsd.org address. This is something that should be addressed _ReallySoonNow_ I don't follow FreeBSD intrastructure discussions but I don't understand while we jumed from gnats onto bugzilla instead of going straight to Phabricator Maniphest. Also from my Phabricator experience it is still a bit better suited for svn-centralized model than git (although it supports git as well). Today I hope we turn ourselves from the cathedral into a truly open and democratic project! I'd love to have a Phabricator account but despite using FreeBSD since I think version 2.1 and contributing very little I never aspired to get a commit bit. //Marcin ___ 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: default pager (csh)
On Thu, 19 Feb 2015, RW wrote: On Wed, 18 Feb 2015 19:16:59 -0600 Mike Karels wrote: Trivia: the version of more on BSD systems actually is derived from less, not the original version of more. Actually, more is less Fortunately we don't set LESSOPEN by default like some (most?) Linux distributions. http://seclists.org/oss-sec/2014/q4/769 Maybe this feature should even be disabled when in more mode. //Marcin ___ 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: Bug-report of sorts...
On Fri, 30 Jan 2015, Poul-Henning Kamp wrote: But the point is I never get to the webpage, local_unbound just doesn't seem to be able to resolve anything through the DHCP appointed server, despite the fact that dig(1) does so just fine. I kind of got used to having to restart local_unbound after wifi/ipsec failures on my network, but I think I am going straight to the rootservers and I don't have anything captive. Something got negatively cached for too long? //Marcin ___ 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: DigitalOcean offers VMs with FreeBSD!
On Fri, 16 Jan 2015, Jamie Landeg-Jones wrote: Bernhard Fröhlich de...@bluelife.at wrote: I don't know what's unusual with the DO virtualisation, but vultr just works like a normal server (though they do restrict to virtio devices where applicable rather than emulated harware) They use Avahi for autodisovery of the IPv4 link layer address to further boostrap the configuration. Unfortuately avahi-autoipd seems to needs lots of dependencies, including gobject-introspection. bsd-cloudinit is written in Python and they use it to get a proper IPv4 addresses. This configuration gets sucked into rc. On Fri, 16 Jan 2015, Nikolay Denev wrote: On Fri, Jan 16, 2015 at 7:13 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote: Beware that they (DO) do not at all grok ipv6. They hand out /124s, or something equally silly. My DO instance has /64 and I have no problems with using ipv6 to login. It's /64 formally here, but I am told only to use 16 (sixteen) addresses :2000 ... :200f Sounds like neighbour discovery scalability issues? //Marcin ___ 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: DigitalOcean offers VMs with FreeBSD!
On Thu, 15 Jan 2015, Bryan Venteicher wrote: On Thu, Jan 15, 2015 at 9:44 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Jan 15, 2015 at 06:28:23PM +0300, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15.01.2015 14:29, Lev Serebryakov wrote: https://www.digitalocean.com/company/blog/presenting-freebsd-how-we-made-it-happen/ I didn't see this news on mailing lists :) But here are some thread about FreeBSD is way slower than Linux in these virtual installations https://news.ycombinator.com/item?id=487 May be IOPS quotation? Can you test with dd and custom kernel with MAXPHYS=1048576 ? What's the value of kern.timecounter.hardware? It will likely be either HPET or ACPI which means there is an VM exit whenever the guest reads from the emulated timecounter hardware. That's why I have some WIP to add support for KVMCLOCK [1]. I hope to merge those changes to HEAD in a week and STABLE shortly after. sysctl kern.timecounter.hardware kern.timecounter.hardware: HPET ___ 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: DigitalOcean offers VMs with FreeBSD!
On Thu, 15 Jan 2015, Slawa Olhovchenkov wrote: On Thu, Jan 15, 2015 at 06:28:23PM +0300, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15.01.2015 14:29, Lev Serebryakov wrote: https://www.digitalocean.com/company/blog/presenting-freebsd-how-we-made-it-happen/ I didn't see this news on mailing lists :) But here are some thread about FreeBSD is way slower than Linux in these virtual installations https://news.ycombinator.com/item?id=487 May be IOPS quotation? Can you test with dd and custom kernel with MAXPHYS=1048576 ? By default, root is mounted with sync option: time dd if=/dev/zero of=/tmp/test bs=64k count=16k 16384+0 records in 16384+0 records out 1073741824 bytes transferred in 57.605991 secs (18639412 bytes/sec) 0.023u 6.128s 0:57.61 10.6% 25+172k 7+81916io 3pf+0w sudo mount -o nosync -u / mount /dev/gpt/rootfs on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) time dd if=/dev/zero of=/tmp/test bs=64k count=16k 16384+0 records in 16384+0 records out 1073741824 bytes transferred in 5.135908 secs (209065631 bytes/sec) 0.016u 2.274s 0:05.16 44.1% 24+169k 8+8193io 0pf+0w //Marcin ___ 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: Compiling Xen on FreeBSD using clang ...
On Sun, 19 Oct 2014, Matthew Grooms wrote: All, As most of you are probably aware, Roger at Citrix RD has been doing some incredible work to bring PVH domU/dom0 support to FreeBSD. There has also been an effort by other Xen developers to get the software to compile using clang. While most of these attempts appear to be on Linux platforms targeting arm processors, the FreeBSD version of binutils is quite a bit older. Clang still can't parse all of the assembly that Xen requires, so unfortunately the -no-integrated-as option has to be used in several cases. Which brings me to my question, is there a way to ask clang to use the ports version of binutils when -no-integrated-as is passed to clang? The version of 'as' in base fails to compile such as ... /tmp/misc-bf1339.s: Assembler messages: /tmp/misc-bf1339.s:375: Error: unknown pseudo-op: `.cfi_sections' I have recently managed to compile Xen (4.5 unstable from git master) using few patches in the source code (I posted them to xen-devel@, most of them are almost the same as some earlier work by Julien Grall). I have used clang version 3.5.0 (trunk) from ports just for the .code16 support, other than that clang 3.4.1 was fine. Xen kernel compiled this way even boots successfully and starts Debian dom0. This command was used to compile with 3.4.1 (without hvmloader): env CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib gmake clang=y CC=clang-devel HOSTCC=clang-devel CONFIG_SEABIOS=y CONFIG_HVMLOADER=n SEABIOS_PATH=$HOME/qemu/bios.bin-1.7.5 CONFIG_QEMU=n $@ //Marcin ___ 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: Compiling Xen on FreeBSD using clang ...
On Sun, 19 Oct 2014, Matthew Grooms wrote:
Thanks for that. I hope the Xen devs can get the yajl and signed int patches
committed. Those were the only C level code changes I ran into and would
clean up the build significantly for clang users. Tho only other knit was the
...
register unsigned long sp asm(rsp);
... assembly but maybe that compiles with 3.5 as well?
I am still getting this:
/home/saper/sw/xen/xen/include/asm/current.h:30:33: error: variable
'sp' is uninitialized when used here [-Werror,-Wuninitialized]
return (struct cpu_info *)((sp ~(STACK_SIZE-1)) + STACK_...
^~
/home/saper/sw/xen/xen/include/asm/current.h:28:30: note: initialize
the variable 'sp' to silence this warning
register unsigned long sp asm(rsp);
^
= 0
1 error generated.
Do you have a link to your patch set? I sifted through the ones posted by
Julien and I probably saw most of yours as well. My goal was to get as much
as possible to compile with the existing system compiler so I didn't try
3.5.0. Maybe that's a better bet.
It would be also really good to integrate with qemu from ports
and not compile our own version again.
My patches are attached, hopefully the mailing list
will accept them.
//MarcinFrom a2253431f4df4dc09e8817467996ec6c6fc47614 Mon Sep 17 00:00:00 2001
From: Marcin Cieslak sa...@saper.info
Date: Wed, 24 Sep 2014 12:00:54 +
Subject: [PATCH 10/10] No QEMU for now
---
tools/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/Makefile b/tools/Makefile
index b6476c9..833b8fa 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -24,8 +24,8 @@ SUBDIRS-$(CONFIG_Linux) += libvchan
# do not recurse in to a dir we are about to delete
ifneq $(MAKECMDGOALS) distclean
-SUBDIRS-$(CONFIG_QEMU_TRAD) += qemu-xen-traditional-dir
-SUBDIRS-$(CONFIG_QEMU_XEN) += qemu-xen-dir
+# SUBDIRS-$(CONFIG_QEMU_TRAD) += qemu-xen-traditional-dir
+# SUBDIRS-$(CONFIG_QEMU_XEN) += qemu-xen-dir
endif
SUBDIRS-y += xenpmd
--
2.0.2
From e37a8a1070b77c44f66507d5f49e332787325609 Mon Sep 17 00:00:00 2001
From: Marcin Cieslak sa...@saper.info
Date: Wed, 24 Sep 2014 12:49:17 +
Subject: [PATCH 09/10] Add -Wno-initializer-overrides for clang
Signed-off-by: Marcin Cieslak sa...@saper.info
---
Config.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/Config.mk b/Config.mk
index 015b90b..aa0ca73 100644
--- a/Config.mk
+++ b/Config.mk
@@ -194,6 +194,7 @@ CFLAGS += -Wall -Wstrict-prototypes
# and is over-zealous with the printf format lint
# and is a bit too fierce about unused return values
CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value
+CFLAGS-$(clang) += -Wno-initializer-overrides
$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
$(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
--
2.0.2
From c84cc99dcf9365b713031f0135c56b477df5824b Mon Sep 17 00:00:00 2001
From: Marcin Cieslak sa...@saper.info
Date: Wed, 24 Sep 2014 12:06:25 +
Subject: [PATCH 08/10] variable 'rc' is used uninitialized whenever 'if'
condition is false
Signed-off-by: Marcin Cieslak sa...@saper.info
---
tools/libxl/libxl_dom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ce0c4ac..d98838a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -2020,7 +2020,7 @@ int libxl_userdata_unlink(libxl_ctx *ctx, uint32_t domid,
const char *userdata_userid)
{
GC_INIT(ctx);
-int rc;
+int rc = 0;
libxl__domain_userdata_lock *lock;
const char *filename;
--
2.0.2
From c468fd7e6228f2820ef8f4ede7432313354730f0 Mon Sep 17 00:00:00 2001
From: Marcin Cieslak sa...@saper.info
Date: Sat, 13 Sep 2014 18:35:52 +
Subject: [PATCH 07/10] clang: sizeof(type) must not have
__attribute__(aligned)
Signed-off-by: Marcin Cieslak sa...@saper.info
---
tools/include/xen-foreign/mkheader.py | 41 ++-
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/tools/include/xen-foreign/mkheader.py
b/tools/include/xen-foreign/mkheader.py
index 0504cb8..80a8404 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -16,13 +16,23 @@ inttypes = {};
header = {};
footer = {};
+def convertint(arch, t, aligned=False):
+ nt = inttypes[arch][t]
+ attr =
+ if type(nt) is type(()):
+ (attr, nt) = nt
+ if not aligned:
+ attr =
+ print sys.stderr, %s(%d) - %s %s % (t, aligned, attr, nt)
+ return %s %s % (nt, attr) # Order is important due to re.sub done
twice
+
#arm
inttypes[arm32] = {
unsigned long : __danger_unsigned_long_on_arm32,
long : __danger_long_on_arm32,
-xen_pfn_t : __align8__ uint64_t,
-xen_ulong_t : __align8__ uint64_t,
-uint64_t
Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
On Sat, 27 Sep 2014, O. Hartmann wrote: Am Sat, 20 Sep 2014 09:21:34 -0500 Just for the record. Another box, running as a server with CURRENT on-top of a Intel(R) Core(TM) i3-3220 CPU with Ivy-Bridge HD2500 graphics, crashes/blanks screen when going into graphics mode with vt() (having kernel modules drm2 and i915kms already loaded via loader.conf). Seems to be a known problem. Can you try to start X without having i915kms loaded by the third stage loader? This workaround works for me (i915kms gets loaded by X) //Marcin ___ 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: Teach vidcontrol(1) and vt(4) to restore default font
On Sat, 13 Sep 2014, Benjamin Kaduk wrote: On Sat, 13 Sep 2014, Marcin Cieslak wrote: Hello, I tried loading gallant.fnt which I did not like and I was wondering how to come back to the nice default font. There does not seem to be the way to do this, so please find below a simple patch to add this functionality. It adds a new ioctl PIO_VDFFONT to the vt(4) driver. I hope I got the reference counting on the vt_font_default structure right. With this patch applied, vidcontrol -f restores the built-in font. Can you please submit this to our bug tracker so it doesn't get lost? https://bugs.freebsd.org/submit Sure, it lives under https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193910 now. //Marcin ___ 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: resource_list_alloc: resource entry is busy
On Fri, 12 Sep 2014, Kevin Oberman wrote: On Fri, Sep 12, 2014 at 1:57 PM, Marcin Cieslak sa...@saper.info wrote: Please note I originally loaded i915.ko, not i915kms.ko Unfortunately, kldunload i915kms makes my screen blank and probably crashes the system (disk activity stops after a short while and there is no response to the keyboard input). //Marcin That explains most of it. You need i915kms. It is conflicting with i915 which already has the IRQ allocated. The black screen is expected. Once KMS starts talking to the graphics system, syscons can no longer talk to the display, so you get a black screen. To have a working display, you must enable vt(4). Add kern.vty=vt to /boot/loader.conf to enable vt(4) which will keep the display alive. Yes, I do have kern.vty=vt enabled in the loader and without i915kms loaded my system boots correctly. I can load i915kms later per hand or when starting X, but it does not work with bootloader. I think it's a known problem as of September 2nd as stated on the http://wiki.freebsd.org/Newcons page. (My machine is Sony VAIO SZ5MN). //Marcin ___ 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
Teach vidcontrol(1) and vt(4) to restore default font
Hello,
I tried loading gallant.fnt which I did not
like and I was wondering how to come back to
the nice default font.
There does not seem to be the way to do this,
so please find below a simple patch to add
this functionality.
It adds a new ioctl PIO_VDFFONT to the vt(4)
driver. I hope I got the reference counting
on the vt_font_default structure right.
With this patch applied, vidcontrol -f restores
the built-in font.
//Marcin
Index: sys/dev/vt/vt_core.c
===
--- sys/dev/vt/vt_core.c(wersja 271197)
+++ sys/dev/vt/vt_core.c(kopia robocza)
@@ -1948,6 +1948,10 @@
vtfont_unref(vf);
return (error);
}
+ case PIO_VDFTFONT: {
+ error = vt_change_font(vw, vt_font_default);
+ return (error);
+ }
case GIO_SCRNMAP: {
scrmap_t *sm = (scrmap_t *)data;
Index: sys/sys/consio.h
===
--- sys/sys/consio.h(wersja 271197)
+++ sys/sys/consio.h(kopia robocza)
@@ -239,6 +239,7 @@
#define GIO_FONT8x16 _IOR('c', 69, fnt16_t)
#define PIO_VFONT _IOW('c', 70, vfnt_t)
#define GIO_VFONT _IOR('c', 71, vfnt_t)
+#define PIO_VDFTFONT _IO('c', 72)
/* get video mode information */
struct colors {
Index: usr.sbin/vidcontrol/vidcontrol.1
===
--- usr.sbin/vidcontrol/vidcontrol.1(wersja 271197)
+++ usr.sbin/vidcontrol/vidcontrol.1(kopia robocza)
@@ -26,9 +26,11 @@
.Op Fl c Ar appearance
.Oo
.Fl f
+.Oo
.Op Ar size
.Ar file
.Oc
+.Oc
.Op Fl g Ar geometry
.Op Fl h Ar size
.Op Fl i Cm adapter | mode
@@ -136,8 +138,10 @@
Print out current output screen map.
.It Xo
.Fl f
+.Oo
.Op Ar size
.Ar file
+.Oc
.Xc
Load font
.Ar file
@@ -158,6 +162,14 @@
.Nm
will try to guess it from the size of font file.
.Pp
+When using
+.Xr vt 4
+both
+.Ar size
+and
+.Ar font
+can be omitted, and the default font will be loaded.
+.Pp
Note that older video cards, such as MDA and CGA, do not support
software font.
See also
Index: usr.sbin/vidcontrol/vidcontrol.c
===
--- usr.sbin/vidcontrol/vidcontrol.c(wersja 271197)
+++ usr.sbin/vidcontrol/vidcontrol.c(kopia robocza)
@@ -197,7 +197,7 @@
{
if (vt4_mode)
fprintf(stderr, %s\n%s\n%s\n%s\n%s\n,
-usage: vidcontrol [-CHPpx] [-b color] [-c appearance] [-f [size] file],
+usage: vidcontrol [-CHPpx] [-b color] [-c appearance] [-f [[size] file]],
[-g geometry] [-h size] [-i adapter | mode],
[-M char] [-m on | off] [-r foreground background],
[-S on | off] [-s number] [-T xterm | cons25] [-t N | off],
@@ -409,6 +409,19 @@
return (t);
}
+/*
+ * Set the default vt font.
+ */
+
+static void
+load_default_vt4font(void)
+{
+ if (ioctl(0, PIO_VDFTFONT) == -1) {
+ revert();
+ errc(1, errno, loading default vt font);
+ }
+}
+
static int
load_vt4font(FILE *f)
{
@@ -1328,7 +1341,7 @@
dumpopt = DUMP_FBF;
termmode = NULL;
if (vt4_mode)
- opts = b:Cc:f:g:h:Hi:M:m:pPr:S:s:T:t:x;
+ opts = b:Cc:fg:h:Hi:M:m:pPr:S:s:T:t:x;
else
opts = b:Cc:df:g:h:Hi:l:LM:m:pPr:S:s:T:t:x;
@@ -1349,15 +1362,23 @@
print_scrnmap();
break;
case 'f':
- type = optarg;
- font = nextarg(argc, argv, optind, 'f', 0);
+ optarg = nextarg(argc, argv, optind, 'f', 0);
+ if (optarg != NULL) {
+ font = nextarg(argc, argv, optind, 'f', 0);
- if (font == NULL) {
- type = NULL;
- font = optarg;
+ if (font == NULL) {
+ type = NULL;
+ font = optarg;
+ } else
+ type = optarg;
+
+ load_font(type, font);
+ } else {
+ if (!vt4_mode)
+ usage(); /* Switch syscons to ROM? */
+
+load_default_vt4font();
}
-
- load_font(type, font);
break;
case 'g':
if (sscanf(optarg, %dx%d,
___
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: resource_list_alloc: resource entry is busy
On Wed, 10 Sep 2014, John Baldwin wrote: On Wednesday, September 10, 2014 12:45:08 PM Marcin Cieslak wrote: On my CURRENT as of 6 Sep (r271197): What I did was that: - kldload i915 - startx During X server start I get the following: #10 0x808c2947 in resource_list_alloc (rl=value optimized out, bus=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/kern/subr_bus.c:3304 #11 0x8061ddae in pci_alloc_resource (dev=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/dev/pci/pci.c:4604 #12 0x808c4420 in bus_alloc_resource (dev=0xf800026d8800, type=1, rid=0x811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #13 0x80626092 in vga_pci_alloc_resource (dev=0xf800026d8800, child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0, end=value optimized out, count=18446744071580876744, flags=value optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318 Can you load the core dump in kgdb and run 'f 13' and 'p *rid'? Sure, here it goes: (kgdb) f 13 #13 0x80626092 in vga_pci_alloc_resource ( dev=0xf800026d8800, child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0, end=value optimized out, count=18446744071580876744, flags=value optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318 318 return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); Current language: auto; currently minimal (kgdb) p *rid $1 = 0 //Marcin ___ 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: resource_list_alloc: resource entry is busy
On Fri, 12 Sep 2014, John Baldwin wrote: at /usr/src/sys/dev/pci/vga_pci.c:318 318 return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); Current language: auto; currently minimal (kgdb) p *rid $1 = 0 Hmm, type 1 is SYS_RES_IRQ. IRQ resources should not be marked reserved. Oh, some other child of vgapci has already allocated the IRQ. That seems odd. Can you get 'devinfo -r' output before you kldload i915kms and again after doing the kldload? (No need to run startx) Please note I originally loaded i915.ko, not i915kms.ko Full output of the devinfo -r attached (no modules, w/i915 and w/i915kms), snippets: pcib0 I/O ports: 0xcf8-0xcff pci0 PCI domain 0 bus numbers: 0 hostb0 vgapci0 I/O ports: 0x1800-0x1807 I/O memory addresses: 0xd000-0xdfff 0xf830-0xf837 0xf840-0xf843 agp0 I/O memory addresses: 0x8000-0x8fff acpi_video0 vgapci1 I/O memory addresses: 0xf838-0xf83f With i915.ko loaded: pcib0 I/O ports: 0xcf8-0xcff pci0 PCI domain 0 bus numbers: 0 hostb0 vgapci0 Interrupt request lines: 16 I/O ports: 0x1800-0x1807 I/O memory addresses: 0xd000-0xdfff 0xf830-0xf837 0xf840-0xf843 agp0 I/O memory addresses: 0x8000-0x8fff acpi_video0 drm0 vgapci1 I/O memory addresses: 0xf838-0xf83f with i915kms.ko loaded: pcib0 I/O ports: 0xcf8-0xcff pci0 PCI domain 0 bus numbers: 0 hostb0 vgapci0 Interrupt request lines: 16 I/O ports: 0x1800-0x1807 I/O memory addresses: 0xd000-0xdfff 0xf830-0xf837 0xf840-0xf843 agp0 I/O memory addresses: 0x8000-0x8fff acpi_video0 drmn0 intel_iicbb0 iicbb0 iicbus0 iicsmb0 smbus0 smb0 iic0 intel_gmbus0 iicbus1 iicsmb1 smbus1 smb1 iic1 intel_iicbb1 iicbb1 iicbus2 iicsmb2 smbus2 smb2 iic2 intel_gmbus1 iicbus3 iicsmb3 smbus3 smb3 iic3 intel_iicbb2 iicbb2 iicbus4 iicsmb4 smbus4 smb4 iic4 intel_gmbus2 iicbus5 iicsmb5 smbus5 smb5 iic5 intel_iicbb3 iicbb3 iicbus6 iicsmb6 smbus6 smb6 iic6 intel_gmbus3 iicbus7 iicsmb7 smbus7 smb7 iic7 intel_iicbb4 iicbb4 iicbus8 iicsmb8 smbus8 smb8 iic8 intel_gmbus4 iicbus9 iicsmb9 smbus9 smb9 iic9 intel_iicbb5 iicbb5 iicbus10 iicsmb10 smbus10 smb10 iic10 intel_gmbus5 iicbus11 iicsmb11 smbus11 smb11 iic11 intel_iicbb6 iicbb6 iicbus12 iicsmb12 smbus12 smb12 iic12 intel_gmbus6 iicbus13 iicsmb13 smbus13 smb13 iic13 intel_iicbb7 iicbb7 iicbus14 iicsmb14 smbus14 smb14 iic14 intel_gmbus7 iicbus15 iicsmb15 smbus15 smb15 iic15 fbd0 vgapci1
Re: panic: resource_list_alloc: resource entry is busy
On Fri, 12 Sep 2014, John Baldwin wrote: Please note I originally loaded i915.ko, not i915kms.ko Oh, that is probably your problem. X loaded i915kms automatically and i915 and i915kms do not get along. i915 had already allocated the IRQ when i915kms tried to alloc the same IRQ causing the issue. Would that be possible to fail with EBUSY or something instead of panic? //Marcin ___ 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
panic: resource_list_alloc: resource entry is busy
On my CURRENT as of 6 Sep (r271197): What I did was that: - kldload i915 - startx During X server start I get the following: #10 0x808c2947 in resource_list_alloc (rl=value optimized out, bus=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/kern/subr_bus.c:3304 #11 0x8061ddae in pci_alloc_resource (dev=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/dev/pci/pci.c:4604 #12 0x808c4420 in bus_alloc_resource (dev=0xf800026d8800, type=1, rid=0x811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #13 0x80626092 in vga_pci_alloc_resource (dev=0xf800026d8800, child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0, end=value optimized out, count=18446744071580876744, flags=value optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318 #14 0x808c4420 in bus_alloc_resource (dev=0xf800026d7300, type=1, rid=0x811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #15 0x81e94f73 in drm_attach (kdev=0xf800026d7300, idlist=value optimized out) at bus.h:416 #16 0x808c202f in device_attach (dev=0xf800026d7300) at device_if.h:180 #17 0x808c34c9 in bus_generic_driver_added (dev=value optimized out, driver=value optimized out) at /usr/src/sys/kern/subr_bus.c:2792 #18 0x808c022a in devclass_driver_added (dc=0xf80002504a80, driver=0x81e714c0) at bus_if.h:204 #19 0x808c018c in devclass_add_driver (dc=0xf80002504a80, driver=0x81e714c0, pass=value optimized out, dcp=value optimized out) at /usr/src/sys/kern/subr_bus.c:1136 #20 0x80873a12 in module_register_init (arg=0x81e714a8) at /usr/src/sys/kern/kern_module.c:123 #21 0x80866f24 in linker_load_module (kldname=value optimized out, modname=0xf80002407400 i915kms, parent=0x0, verinfo=0x0, lfpp=0xfe0096d05a80) at /usr/src/sys/kern/kern_linker.c:224 #22 0x80868a18 in kern_kldload (td=value optimized out, file=value optimized out, fileid=0xfe0096d05ac4) at /usr/src/sys/kern/kern_linker.c:1029 #23 0x80868b5b in sys_kldload (td=0xf80008911490, uap=value optimized out) at /usr/src/sys/kern/kern_linker.c:1055 X -version: X.Org X Server 1.12.4 Release Date: 2012-08-27 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 11.0-CURRENT amd64 Current Operating System: FreeBSD radziecki.saper.info 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r271197M: Sat Sep 6 19:19:12 CEST 2014 r...@radziecki.saper.info:/usr/obj/usr/src/sys/VAIO amd64 Build Date: 04 September 2014 01:06:53AM Devices: vgapci0@pci0:0:2:0: class=0x03 card=0x81e6104d chip=0x27a28086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x81e6104d chip=0x27a68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller' class = display (this laptop also has a possbility to switch to NVidia card on boot, not tested yet with this kernel). Kernel: # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # add support for the raster text mode # vt is the new video console driver device vt device vt_vga device vt_efifb device agp # support several AGP chipsets Loader: kern.vty=vt By the way, how do I get a nicer FB console during boot (not just after starting X)? I have difficulty getting back to the console text printed when it was vga (in 640x480x16 mode) - no more output shown on the hires console (I've had tail -f somelog) running on the text console 0 when starting X from another window. //Marcin ___ 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: Time to kill fdc ?
Poul-Henning Kamp p...@phk.freebsd.dk wrote: I tried to read a floppy disk yesterday. When was the last time anybody tried that with a FreeBSD release ? Based on my brief experiments yesterday, 6.X is the last release where accessing floppy disks carry less than a 10% risk of a panic. Unless somebody fixes the fdc driver to work in -current, I intend to dust of my axe and cut it from the tree later this spring. Yes, I did try at the time 9 was current (to make fancy DOS floppies for BIOS for the old machine). I remember I only had an issue with PCMCIA-attached floppy drive (that uses fdc(4) afair), which didn't work then (but I am user I used those long time ago). Maybe the issue you are seeing is similar to my PCMCIA-based floppy problem - I'd be happy to have it fixed for recovery of old boxes. (Will test -current on my ancient box tomorrow) //Marcin ___ 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: RFC: removal of share/doc/{papers,psd,smm,usd} in 2 months
Ulrich Spörlein u...@freebsd.org wrote: Hi all, those roff sources have been very naughty and will be removed from the tree by the end of the year. Most of those papers are severely out of date and provide no more use to the system. They can probably also be found online using a search engine of your choice. Should people feel strongly about them, we might be able to move them over to the doc repository. I am using them quite often and I am very fond of having them locally (useful when working disconnected). I am very often reading the sendmail guide - it's good, up-to-date and explains many dark corners. Recently I found the XDR/RPC docs very useful, as I was porting some software using it and I didn't have too much knowledge about the subject. I used the ffs paper at least twice when fixing a very badly corrupted filesystem (had to use clri and similar commands to bring it back into shape). At those times, you don't want to google around. It is ok to remove stuff that is horribly obsolete and there is no chance to get it updated; but then it should be reviewed. //Marcin ___ 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
Regression: panic in camq_remove when plugging in Huawei IDEOS phone
Hello,
I got this crash in -CURRENT (r241671) when plugging in
Huawei IDEOS Android mobile phone via USB.
#10 0x802ab7a7 in heap_down (queue_array=0xfe0002f29878,
index=Variable index is not available.
)
at /usr/src/sys/cam/cam_queue.c:357
#11 0x802ab86e in camq_remove (queue=0xfe0002e9f880,
index=49453168) at /usr/src/sys/cam/cam_queue.c:185
#12 0x802b0bf3 in xpt_run_dev_sendq (bus=0xfe0002e98d00)
at cam_queue.h:210
---Type return to continue, or q return to quit---
#13 0x802b150f in camisr_runqueue (V_queue=Variable V_queue is not
available.
)
at /usr/src/sys/cam/cam_xpt.c:5117
#14 0x802b171a in camisr (dummy=Variable dummy is not available.
) at /usr/src/sys/cam/cam_xpt.c:5017
#15 0x80767fab in intr_event_execute_handlers (p=Variable p is not
available.
)
at /usr/src/sys/kern/kern_intr.c:1272
#16 0x8076967f in ithread_loop (arg=0xfe00024b48c0)
at /usr/src/sys/kern/kern_intr.c:1285
Some randomly collected data from the dump file:
#11 0x802ab86e in camq_remove (queue=0xfe0002e9f880,
index=49453168) at /usr/src/sys/cam/cam_queue.c:185
185 heap_down(queue-queue_array, index, queue-entries -
1);
(kgdb) print queue
$3 = (struct camq *) 0xfe0002e9f880
(kgdb) print *queue
$4 = {queue_array = 0xfe0002f29878, array_size = 5, entries = 1,
generation = 28, qfrozen_cnt = {0, 0, 0, 0, 0}}
(kgdb) print *queue-queue_array
$5 = (cam_pinfo *) 0x0
(kgdb) print queue-queue_array
$6 = (cam_pinfo **) 0xfe0002f29878
(kgdb) print queue-queue_array[0]
$7 = (cam_pinfo *) 0x0
(kgdb) print queue-queue_array[1]
$8 = (cam_pinfo *) 0xfe0002d24800
I have a full core dump so I can poke around more.
It did work when the machine was running a ca. 1 year old 9-something
system.
//Marcin
___
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: IPv6 tunnel problem
Mattia Rossi mro...@swin.edu.au wrote: fxp0 and em0 Can you show us what does ifconfig say on your interfaces? There are few parameters for the ICMPv6 Neighbor Discovery Protocol that might be needed: ifconfig em0 inet6 accept_rtadv Those are nicely documented in ifconfig(8). This is usually handled by the /etc/rc.d/* stuff IF you have a current version of /etc/rc.conf settings. (They changed a bit in the meantime). //Marcin ___ 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: IPv6 tunnel problem
Mattia Rossi mro...@swin.edu.au wrote: I have accept_rtadv enabled if it's not a router. See my post. I think I have a similar setup (only using sixxs-aiccu). Since my machine is a gateway to the outside IPv6 world (via www.sixxs.net) I am not accepting router adverisements there, but I'm running rtadvd and sending them to other hosts on the LAN: nd6 options=21PERFORMNUD,AUTO_LINKLOCAL ifconfig with tunnel up is: ifconfig bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:0d:9d:51:d4:7e inet 136.186.229.112 netmask 0xff00 broadcast xxx.xxx.xxx.xxx inet6 fe80:::::%bge0 prefixlen 64 scopeid 0x5 inet6 ::::: prefixlen 64 duplicated ** what's up here? nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active Why is this address duplicated? If this machine *is* the gateway to the outside IPv6 world, should *not* it be accepting rtadv and have a global IPv6 address configured statically tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1280 options=8LINKSTATE inet6 fe80:::::%tun0 prefixlen 64 scopeid 0x9 inet6 :::: -- :::: prefixlen 128 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL ** Does ifconfig tun0 inet6 -ifdisabled help? I don't know why gateway6 (I don't use this software) leaves it as IFDISABLED This is /etc/rc.conf from my tunnel gateway machine (two tunnels, tun0 and tun1) - it runs a few-month-old -CURRENT: ipv6_gateway_enable=YES rtadvd_enable=YES # Internal WLAN rtadvd_interfaces=wlan0 ifconfig_wlan0_ipv6=inet6 a::::1/64 # Tunnel via tun0 is configured automatically by aiccu # and has NO /etc/rc.conf entry at all # Tunnel via tun1 is configured statically (it serves only some networks) ifconfig_tun1_ipv6=inet6 a:::8000::1 //Marcin ___ 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: ipv6 / rtadv problem
Daniel O'Connor docon...@gsoft.com.au wrote: On 29/03/2011, at 8:29, Daniel O'Connor wrote: On 29/03/2011, at 1:37, Sergey Kandaurov wrote: 1) ipv6_enable is obsolete in HEAD, see UPDATING. Ahh UPDATING, of course, thanks :) 2) Normally hosts ignore rtadv packets if ipv6_gateway_enable is also set (as per rfc4861). All you need is something like ifconfig_em0_ipv6=inet6 accept_rtadv Great, it works! I spoke a little too soon, I could not connect to a remote host until I did some pings, eg.. maarsy-acq:~telnet -NK6 ipv6.google.com 80 Trying 2404:6800:8004::68... ^C maarsy-acq:~ping6 metatron PING6(56=40+8+8 bytes) 2001:44b8:7c07:5581:225:90ff:fe32:91e -- 2001:44b8:7c07:5581:204:61ff:fe79:276f 16 bytes from 2001:44b8:7c07:5581:204:61ff:fe79:276f, icmp_seq=0 hlim=64 time=0.507 ms 16 bytes from 2001:44b8:7c07:5581:204:61ff:fe79:276f, icmp_seq=1 hlim=64 time=0.247 ms ^C --- metatron.gsoft.com.au ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.247/0.377/0.507/0.130 ms Are you having this problem when talking to other v6 in the same LAN? How does your netstat -rnf inet6 look like? Can you reach metatron.gsoft.com.au from your gateway? //Marcin ___ 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: tun(4) in -CURRENT: No buffer space available - race condition patch
John Baldwin j...@freebsd.org wrote: On Thursday, September 16, 2010 9:02:23 am Marcin Cieslak wrote: Dnia 15.09.2010 John Baldwin j...@freebsd.org napisał/a: On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: Output queue of tun(4) gets full after some time when sending lots of data. I have been observing this on -CURRENT at least since March this year. Looks like it's a race condition (same in tun(4) and tap(4)), the following patch seems to address the issue: This is a good find. I actually went through these drivers a bit further and have a bit of a larger patch to extend the locking some. Would you care to test it? Do you think those drivers could be taken out of Giant after this change? I think that networking code path (via if_start etc.) is not using Giant at all, only cdevsw routines are. Am I right? Oh, yes. I've updated the patch to remove D_NEEDGIANT. I just want to report back that may tun(4) tunnel has been rock-solid since I applied the patch. Didn't have a chance to test tap(4) and it won't happen for another week or so - I hope somebody else jumps in the meantime. Thank you! //Marcin ___ 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: DHCP server in base
M. Warner Losh i...@bsdimp.com wrote: : I agree but like Aleksandr said, almost 70% of dhcp code is already in : base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea : to keep some parts in the ports tree and move out from the base. Yea. I agree too. Just because BIND was EOLd in 6 isn't a great argument against dhcp server. Most of the code is there anyway, and it isn't evolving as fast as BIND. It would be very convenient to have this particular thing in the base, and we shouldn't be too dogmatic about never having any new 3rd party things in the base. After all, we just added more compression utilities to the base, and nobody said a peep. This is analogous: we have good opportunity to integrate into the system, and users benefit from that integration. As a road-warrior consultant I really value having things like bootpd, tftpd, bootparamd and similar software always there. Many times I wished dhcpd was there, too. Another typical use - FreeBSD makes a good small network router out of the box (PPP, NAT, ipfw, WLAN AP, DNS are there, dhcpd - missing). I am not sure about the whole modularization goal - I think the relatively monolythic nature is one of the FreeBSD's merits. For example, it's good to have NFSv4, Kerberos and required userland daemons packaged in the base. I don't want to have those done separately in a modular way (although Heimdal we have is older then what their current trunk is). We got stuck on connecting Linux boxes via NFSv4 to Solaris and BSD because one of the userland modules in Linux was terribly out of date and authenticating the user w/Kerberos was not possible. As we build a more complex networking landscape with VIMAGE and friends I think that the benefits of better integration of dhcpd in the base system (rc.d, rc.conf...) may outweigh its costs (maintenance, bloat, etc.). //Marcin ___ 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: tun(4) in -CURRENT: No buffer space available - race condition patch
John Baldwin j...@freebsd.org wrote: Oh, yes. I've updated the patch to remove D_NEEDGIANT. So far (last 24 hours) my tun(4) with your patch was very stable. I am updating it to remove D_NEEDGIANT. Thank you! //Marcin ___ 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: tun(4) in -CURRENT: No buffer space available - race condition patch
Dnia 15.09.2010 John Baldwin j...@freebsd.org napisał/a: On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: Output queue of tun(4) gets full after some time when sending lots of data. I have been observing this on -CURRENT at least since March this year. Looks like it's a race condition (same in tun(4) and tap(4)), the following patch seems to address the issue: This is a good find. I actually went through these drivers a bit further and have a bit of a larger patch to extend the locking some. Would you care to test it? Do you think those drivers could be taken out of Giant after this change? I think that networking code path (via if_start etc.) is not using Giant at all, only cdevsw routines are. Am I right? //Marcin ___ 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: tun(4) in -CURRENT: No buffer space available - race condition patch
Dnia 15.09.2010 John Baldwin j...@freebsd.org napisał/a: On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: Output queue of tun(4) gets full after some time when sending lots of data. I have been observing this on -CURRENT at least since March this year. Looks like it's a race condition (same in tun(4) and tap(4)), the following patch seems to address the issue: This is a good find. I actually went through these drivers a bit further and have a bit of a larger patch to extend the locking some. Would you care to test it? Sure, I am installing it right now (for if_tun right now). There are also a LORs during tunclose (I always get one of them when closing the tunnel): ---8-- lock order reversal: 1st 0xc24db8c8 rtentry (rtentry) @ /usr/src/sys/net/route.c:370 2nd 0xc2472a04 if_afdata (if_afdata) @ /usr/src/sys/netinet6/scope6.c:417 KDB: stack backtrace: db_trace_self_wrapper(c0a4b284,cce14714,c0723185,c0715b2b,c0a4d1f8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0715b2b,c0a4d1f8,c0c4f308,c21186e8,cce1476c,...) at kdb_backtrace+0x29 _witness_debugger(c0a4d1f8,c2472a04,c0a539ec,c211dfe0,c0a63771,...) at _witness_debugger+0x25 witness_checkorder(c2472a04,9,c0a63771,1a1,0,...) at witness_checkorder+0x6aa _rw_wlock(c2472a04,c0a63771,1a1,0,c2472a04,...) at _rw_wlock+0x38 in6_setscope(cce148c4,c2472800,0,cce147fc,cce147e0,...) at in6_setscope+0x30 in6_purgeaddr(c2539600,0,0,c211e048,c2362364,...) at in6_purgeaddr+0x4af if_purgeaddrs(c2472800,2,0,1cd,c24ab4c0,...) at if_purgeaddrs+0xb0 tunclose(c24d1000,3,2000,c23622c0,1,...) at tunclose+0x197 giant_close(c24d1000,3,2000,c23622c0,c23622c0,...) at giant_close+0x6e devfs_close(cce14a78,cce14a9c,c07785fb,c0aae500,cce14a78,...) at devfs_close+0x2a9 VOP_CLOSE_APV(c0aae500,cce14a78,c0a532d0,12d,c0af0160,...) at VOP_CLOSE_APV+0x42 vn_close(c24ccaa0,3,c2160c80,c23622c0,c23622c0,...) at vn_close+0xdb vn_closefile(c24bc0e0,c23622c0,c24bc0e0,0,cce14b28,...) at vn_closefile+0xe4 devfs_close_f(c24bc0e0,c23622c0,3,0,c24bc0e0,...) at devfs_close_f+0x2b _fdrop(c24bc0e0,c23622c0,cce14b5c,c072327c,0,...) at _fdrop+0x43 closef(c24bc0e0,c23622c0,721,71e,c2362364,...) at closef+0x277 fdfree(c23622c0,0,c0a4549c,107,8000,...) at fdfree+0x3ba exit1(c23622c0,0,cce14c7c,c071da4a,c23622c0,...) at exit1+0x465 sys_exit(c23622c0,cce14cec,stray irq7 c06a7bac,1,0,...) at sys_exit+0x1d syscallenter(c23622c0,cce14ce4,c06d6stray irq7 d5d,c0cae934,8,...) at syscallenter+0x25a syscall(cce14d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (1, FreeBSD ELF32, sys_exit), eipstray irq7 = 0x28128acf, esp = 0xbfbfed80, ebp = 0xbfbfed8c --- ^Ctun0: link state changed to DOWN ---8-- lock order reversal: 1st 0xc24db8c8 rtentrystray irq7 (rtentry) @ /usr/src/sys/net/route.c:370 2nd 0xc2482604 if_afdata (if_afdata) @ /usr/src/sys/netinet6/scope6.c:417 KDB: stack backtrace: db_trace_self_wrapper(c0a4912e,cce16714,c0723105,c0715aab,c0a4b0a2,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0715aab,c0a4b0a2,c0c4cb58,c21176e8,cce1676c,...) at kdb_backtrace+0x29 _witness_debugger(c0a4b0a2,c2482604,c0a51896,c211cfe0,c0a6137e,...) at _witness_debugger+0x25 witness_checkorder(c2482604,9,c0a6137e,1a1,0,...) at witness_checkorder+0x6aa _rw_wlock(c2482604,c0a613stray irq7 7e,1a1,c0793997,c2482604,...) at _rw_wlock+0x38 in6_setscope(cce168c4,c2482400,0,cce167fc,cce167e0,...) at in6_setscope+0x30 in6_purgeaddr(c253e000,0,0,c211d048,c2361364,...) at in6_purgeaddr+0x4af if_purgeaddrs(c2482400,2,0,1cd,c24aa5c0,...) at if_purgeaddrs+0xb0 tunclose(c2539a00,3,2000,c23612c0,1,...) at tunclose+0x136 giant_close(c2539a00,3,2000,c23612c0,c23612c0,...) at giant_close+0x6e devfs_close(cce16a78,cce16a9c,c077857b,c0aac0e0,cce16a78,...) at devfs_close+0x2a9 VOP_CLOSE_APV(c0aac0e0,cce16a78,c0a5117a,12d,c0aedac0,...) at VOP_CLOSE_APV+0x42 vn_close(c25d2770,3,c215fc80,c23612c0,c0b10180,...) at vn_close+0xdb vn_closefile(c24bba10,c23612c0,c24bba10,0,cce16b28,...) at vn_closefile+0xe4 devfs_close_f(c24bba10,c23612c0,3,0,c24bba10,...) at devfs_close_f+0x2b _fdrop(c24bba10,c23612c0,cce16b5c,c07231fc,0,...) at _fdrop+0x43 closef(c24bba10,c23612c0,721,71e,c2361364,...) at closef+0x277 fdfree(c23612c0,0,c0a43346,107,c2361364,...) at fdfree+0x3ba exit1(c23612c0,0,cce16c7c,c071d9ca,c23612c0,...) at exit1+0x465 sys_exit(c23612c0,cce16cec,28087460,1,0,...) at sys_exit+0x1d syscallenter(c23612c0,cce16ce4,c09a564e,c23612c0,cce16d28,...) at syscallenter+0x25a syscall(cce16d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x28128acf, esp = 0xbfbfed80, ebp = 0xbfbfed8c --- tun0: link state changed to DOWN ---8-- --Marcin ___ freebsd-current
tun(4) in -CURRENT: No buffer space available - race condition patch
Output queue of tun(4) gets full after some time when sending lots of data.
I have been observing this on -CURRENT at least since March this year.
Looks like it's a race condition (same in tun(4) and tap(4)),
the following patch seems to address the issue:
Index: if_tap.c
===
--- if_tap.c(revision 212217)
+++ if_tap.c(working copy)
@@ -881,8 +881,7 @@
mtx_lock(tp-tap_mtx);
tp-tap_flags |= TAP_RWAIT;
- mtx_unlock(tp-tap_mtx);
- error = tsleep(tp,PCATCH|(PZERO+1),taprd,0);
+ error = mtx_sleep(tp, tp-tap_mtx,
PDROP|PCATCH|(PZERO+1), taprd, 0);
if (error)
return (error);
}
Index: if_tun.c
===
--- if_tun.c(revision 212217)
+++ if_tun.c(working copy)
@@ -836,8 +836,7 @@
}
mtx_lock(tp-tun_mtx);
tp-tun_flags |= TUN_RWAIT;
- mtx_unlock(tp-tun_mtx);
- if ((error = tsleep(tp, PCATCH | (PZERO + 1),
+ if ((error = mtx_sleep(tp, tp-tun_mtx, PDROP | PCATCH
| (PZERO + 1),
tunread, 0)) != 0) {
splx(s);
return (error);
--Marcin
___
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: [PATCH] Use MACHINE_ARCH for boot loader
Dnia 27.08.2010 John Baldwin j...@freebsd.org napisał/a: On Thursday, August 26, 2010 8:50:01 pm Xin LI wrote: Hi, The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and FreeBSD/amd64 on amd64. Comments welcome! I'll commit it in by the weekend if there is no objection on this. As others have noted, the 'x86' is on purpose, and I would rather it continue to do that rather than this change. Not sure about it, the loader and boot block are 32-bit code, aren't they? (That actually made me to hack some patches to make ficl 64-bit, but that's another story). So I think i386 is better designation for pure 32-bit code I think. -- Marcin Cieslak // sa...@saper.info ___ 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: Our aging base system heimdal
(from the freebsd-current mailing list)
Dnia 06.06.2010 b. f. bf1...@googlemail.com napisał/a:
Is anybody planning to update the base system heimdal, which has been
largely untouched since May 2008? In addition to the many other
bug-fixes and improvements in the current version 1.3.3 (see, for
example:
I decided to give it a try. My first steup is to make it compile on
FreeBSD. As you know, as of recently FreeBSD-current has no utmp.h
I have hacked up a small patch to fix this:
--- appl/ftp/ftpd/logwtmp.c 2010-05-26 23:53:13.0 +0200
+++ appl/ftp/ftpd/logwtmp.c 2010-06-12 22:32:57.373647840 +0200
@@ -104,16 +104,16 @@
static void
ftpd_logwtmp_wtmp(char *line, char *name, char *host)
{
+#ifdef HAVE_UTMP_H
static int init = 0;
static int fd;
-#ifdef WTMPX_FILE
-static int fdx;
-#endif
struct utmp ut;
-#ifdef WTMPX_FILE
+#endif
+#ifdef HAVE_UTMPX_H
struct utmpx utx;
#endif
+#ifdef HAVE_UTMP_H
memset(ut, 0, sizeof(struct utmp));
#ifdef HAVE_STRUCT_UTMP_UT_TYPE
if(name[0])
@@ -130,8 +130,9 @@
strncpy(ut.ut_host, host, sizeof(ut.ut_host));
#endif
ut.ut_time = time(NULL);
+#endif
-#ifdef WTMPX_FILE
+#ifdef HAVE_UTMPX_H
strncpy(utx.ut_line, line, sizeof(utx.ut_line));
strncpy(utx.ut_user, name, sizeof(utx.ut_user));
strncpy(utx.ut_host, host, sizeof(utx.ut_host));
@@ -140,6 +141,7 @@
if (utx.ut_syslen sizeof(utx.ut_host))
utx.ut_syslen = sizeof(utx.ut_host);
#endif
+#endif
{
struct timeval tv;
@@ -152,21 +154,18 @@
utx.ut_type = USER_PROCESS;
else
utx.ut_type = DEAD_PROCESS;
-#endif
+#ifdef HAVE_UTMPX_H
+ pututxline(utx);
+#else
if(!init){
fd = open(WTMP_FILE, O_WRONLY|O_APPEND, 0);
-#ifdef WTMPX_FILE
- fdx = open(WTMPX_FILE, O_WRONLY|O_APPEND, 0);
-#endif
init = 1;
}
if(fd = 0) {
write(fd, ut, sizeof(struct utmp)); /* XXX */
-#ifdef WTMPX_FILE
- write(fdx, utx, sizeof(struct utmpx));
-#endif
}
+#endif
}
#endif /* !HAVE_ASL_H */
--
Marcin Cieslak // sa...@saper.info
___
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
State of tun(4) in -CURRENT? No buffer space available
Hello, I'm running r203753 (i386) for some time on my IPv6 router. This box uses net/sixxs-aiccu to establish an IPv6 tunnel to one of the SixXS POPs. Unfortunately, tun(4) interface exhibits strange behaviour: after some traffic burst (like opening a ncurses application via ssh) the interface stops delivering packets. I manually restart the sixxs-aiccu utility and then it usually works, sometimes for few packets only, sometimes for minutes or hours. When the link is mostly idle (e.g. overnight) it stays up. aiccu (when stopped with SIGQUIT) exhibits three threads, One of them is the tunnel watchdog thread (probably unreladed). The other one waits from the data encapsulated via IPv4: [Switching to thread 1 (Thread 28240ec0 (LWP 100074))]#0 0x2814c797 in recvfrom () from /lib/libc.so.7 (gdb) bt #0 0x2814c797 in recvfrom () from /lib/libc.so.7 #1 0x280a04d1 in recvfrom () from /lib/libthr.so.3 #2 0x0804fee3 in ayiya_writer (arg=0x2822c300) at ../common/ayiya.c:177 #3 0x2809e244 in pthread_getprio () from /lib/libthr.so.3 #4 0x in ?? () ayiya.c:177: n = recvfrom(ayiya_socket-socket, (char *)buf, sizeof (buf), 0, (struct sockaddr *)ci, cl); Third thread is waiting for packets from tun(4): [Switching to thread 2 (Thread 28241140 (LWP 100053))]#0 0x28194869 in read () from /lib/libc.so.7 (gdb) bt #0 0x28194869 in read () from /lib/libc.so.7 #1 0x280a0576 in read () from /lib/libthr.so.3 #2 0x0804a2fa in tun_reader (arg=0x8055944) at ../common/tun.c:185 #3 0x2809e244 in pthread_getprio () from /lib/libthr.so.3 #4 0x in ?? () tun.c:185: n = read(tun_fd, buf, sizeof(buf)); When the tunnel is hung ping6 packets to the other tunnel end do not go out and after a while: ping6: sendmsg: No buffer space available IPv4 connectivity to the tunnel provider is fine, (ping over IPv4 to the tunnel destination works fine), I didn't notice any intermittent connectivity failures that could cause this. Packets neither come in or come out (checked looking using some other IPv6 on the network as I don't control the other end of the tunnel). I know there has been updates to the tun(4) code since r203753, but a friend of mine doing the same on his box with kernel as of April 13th has the same problem. Any ideas what's wrong? --Marcin ___ 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: ZFS DEADLKRES - AHCI blocks on ICH7M
Dnia 08.04.2010 Attilio Rao atti...@freebsd.org napisał/a: This may be a false positive. May you please try the following patch and report if you can fix it does fix it or not?: http://www.freebsd.org/~attilio/Sandvine/deadlkres/deadlkres-blessed.diff Thanks for your help. I have applied this patch and I am still getting the deadlock (today it was after 1802544 ticks). But there is more: I am running r203753 on one of those AHCI disabled by default laptops (Sony VGN-SZ5MN/B). I have reset the BIOS completely (by removing the CMOS battery for a moment) and it seemingly fixed the problem. I have tested this and I found out: - in ATA emulation mode things are fine. /etc/periodic/daily completes normally. - in AHCI mode /etc/periodic/daily hangs on any disk operation even dumping core is impossible from the ddb(4). I have re-enabled AHCI again and tested with your patch: /etc/periodic/daily and svnsync running in parallel hanged after some longer time and deadlkres kicked in. I presume deadlkres is properly detecting threads that hanged waiting for the disk response. This laptop has the ICH7M controller (in ATA emulation mode): atapci0: Intel ICH7 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] atapci1: Intel ICH7M SATA150 controller port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xf8644400-0xf86447ff irq 22 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: ATA channel 0 on atapci1 ata2: [ITHREAD] ata3: ATA channel 1 on atapci1 ata3: [ITHREAD] in AHCI mode it says: atapci0: Intel ICH7 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ahci0: Intel ICH7M AHCI SATA controller port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xf8644400-0xf86447ff irq 22 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier not supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: AHCI channel at channel 2 on ahci0 ahcich1: [ITHREAD] I am using this in the kernel config: device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering device ahci -- Marcin Cieslak // sa...@saper.info ___ 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
lor freebsd zfs mount
r203753, amd64, while booting (mount filesystems):: lock order reversal: 1st 0xff00096c4098 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1058 2nd 0xff000973f9f8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xd43 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 vget() at vget+0x6e devfs_allocv() at devfs_allocv+0xee devfs_root() at devfs_root+0x41 vfs_donmount() at vfs_donmount+0xfa8 nmount() at nmount+0x74 syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007ac37c, rsp = 0x7fffdd28, rbp = 0x800a06048 --- --Marcin ___ 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
LOR: if_wpi.c
r203753, amd64 lock order reversal: 1st 0xff80003ad018 wpi0_com_lock (wpi0_com_lock) @ /usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:1292 2nd 0xff00034f4010 wpi0 (network driver) @ /usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:2069 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea _mtx_lock_flags() at _mtx_lock_flags+0x68 wpi_raw_xmit() at wpi_raw_xmit+0x68 ieee80211_send_mgmt() at ieee80211_send_mgmt+0x49c sta_newstate() at sta_newstate+0x42b wpi_newstate() at wpi_newstate+0xe3 ieee80211_newstate_cb() at ieee80211_newstate_cb+0xac taskqueue_run() at taskqueue_run+0x90 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8000183d30, rbp = 0 --- --Marcin ___ 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
ZFS DEADLKRES
My r203753 amd64 laptop falls into the deadlock situation every night while running periodic daily script. I am pretty certain this is related to ZFS. I have enabled DEADLKRES in the kernel. I even have a separate dump partition (not used for swap). Indeed, the kernel deadlock detector gets triggered during the periodic run, but I get I/O error when calling doadump() from DDB. Dumping works properly when DDB is invoked with keyboard escape. What's the best way to troubleshoot this deadlock? Should I try to transcribe alltrace output? -- Marcin Cieslak // sa...@saper.info ___ 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: WEIRD! div() broken on -CURRENT?
Andy Sparrow ([EMAIL PROTECTED]) napisa(a): Hmm, I've been running GATOS binary modules built for Linux to provide XV support for an ATI Mobility Pro LY for some time (at least 6-8 months and some 4-5 different experimental versions so far, all have worked great): Btw. GATOS compiles from source fine for me (I use extracted X server port for that). I use driver compiled from GATOS CVS two months ago fine on my VAIO FX-604 without any problems. -- Marcin Cieslak // [EMAIL PROTECTED] msg49352/pgp0.pgp Description: PGP signature
Re: Device permissions with DEVFS
What's wrong with having /etc/minor_perm et consortes a la Solaris? With sensible kernel defaults to allow booting without your favourite root partition. -- Marcin Cieslak // [EMAIL PROTECTED] msg46925/pgp0.pgp Description: PGP signature
Re: fdisk -BI ob clean disk broken - but 1.64 works
On my system, FreeBSD 5.0-CURRENT #1: Mon Nov 4 21:00:50 CET 2002 fdisk ceased to work after a recent upgrade. It used to work fine under GEOMized kernel with both internal ATA disks and external IDE drive attached via fireware or USB (tested both). I had to switch to non-GEOM kernel (my disklabels give my warnings), updated everything, and fdisk ceased to work. I reverted fdisk.c to 1.64 (used to be 1.66) and now fdisk works fine again (with a non-GEOM kernel). Disk layouts below. Another question, can I geomize existing disk? I keep getting disklabel warnings about mismatched partitions and slices. -- Marcin Cieslak // [EMAIL PROTECTED] *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=2432 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=2432 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) start 63, size 14474502 (7067 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 900/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 14474565, size 4192965 (2047 Meg), flag 80 (active) beg: cyl 901/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 18667530, size 20402550 (9962 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 4 is: UNUSED *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=7297 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=7297 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) start 63, size 6136641 (2996 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 381/ head 252/ sector 63 The data for partition 2 is: sysid 14 (0x0e),(Primary 'big' DOS (= 32MB, LBA)) start 6136704, size 2087568 (1019 Meg), flag 0 beg: cyl 381/ head 253/ sector 1; end: cyl 511/ head 238/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 8224272, size 4450320 (2173 Meg), flag 80 (active) beg: cyl 511/ head 239/ sector 1; end: cyl 788/ head 243/ sector 63 The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 12674592, size 41930343 (20473 Meg), flag 80 (active) beg: cyl 788/ head 244/ sector 1; end: cyl 1023/ head 254/ sector 63 msg46136/pgp0.pgp Description: PGP signature
Re: What is user uucp good for?
Kris Kennaway ([EMAIL PROTECTED]) napisa(a): On Sat, Nov 02, 2002 at 04:11:39PM +1030, Greg 'groggy' Lehey wrote: A number of base system utilities and ports still use it for access to the serial port devices (which are owned by the uucp user). Really, the uucp user is now misnamed and should be called something like Let's leave it like it is. Maybe future generations will wonder what it is named after similarly to GCOS field in passwd today :-) -- Marcin Cieslak // [EMAIL PROTECTED] msg46137/pgp0.pgp Description: PGP signature
Re: ttys patch - any objections?
Are old-style non-F11, F12 keyboards still working with FreeBSD? -- Marcin Cieslak // [EMAIL PROTECTED] msg43424/pgp0.pgp Description: PGP signature
