[DragonFlyBSD - Bug #2441] rtorrent downloads broken, possibly related to recent mmap work
Issue #2441 has been updated by t_dfbsd. I updated to v3.7.1.297.g4890e-DEVELOPMENT and with pmap_mmu_optimize set to 1 I'm still seeing this issue. Bug #2441: rtorrent downloads broken, possibly related to recent mmap work http://bugs.dragonflybsd.org/issues/2441#change-11689 * Author: t_dfbsd * Status: New * Priority: Normal * Assignee: * Category: * Target version: Running DragonFly v3.3.0.165.gdc43b7-DEVELOPMENT, x86-64 Since upgrading to recent master, rtorrent downloads have been frequently failing with the message hash check on download completion found bad chunks. I've never that message from rtorrent before. I tried setting machdep.pmap_mmu_optimize=0 and the failures stopped. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2573] Dell Studio 14z: install fails
Issue #2573 has been reported by t_dfbsd. Bug #2573: Dell Studio 14z: install fails http://bugs.dragonflybsd.org/issues/2573 Author: t_dfbsd Status: New Priority: Normal Assignee: Category: Target version: I attempted to install the DF 3.4.2 (non-GUI image) from a USB thumb drive on a Dell Studio 14z (model 1440) laptop. It doesn't complete the boot process. FreeBSD 9 boots successfully (attached is the dmesg from FreeBSD). I see these messages: . hpt27xx: no controller detected CAM: Configuring 4 busses xpt: func=0x80281817 arg=0 (repeated 4 times) Giving up, interrupt routing is probably hosed Mounting root from ufs:da8s1a no disk named 'da8s1a' setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2533] re0: watchdog timeouts, network loss
Issue #2533 has been updated by t_dfbsd. I reverted the patch 3 days ago, updated to 19fe0477806ae874bdfcbed56e0e7437cb609aa0, and haven't seen any watchdog timeouts since Bug #2533: re0: watchdog timeouts, network loss http://bugs.dragonflybsd.org/issues/2533 Author: t_dfbsd Status: New Priority: High Assignee: Category: Target version: I've seen these lately: kernel: re0: watchdog timeout and the box loses network connectivity. I started getting them after updating to DragonFly v3.3.0.1365.g972077-DEVELOPMENT -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2533] re0: watchdog timeouts, network loss
Issue #2533 has been updated by t_dfbsd. I just saw a watchdog timeout with the patch in place. This is with master d88b9605be186eb2c93c4f2683c997a128758b5a Bug #2533: re0: watchdog timeouts, network loss http://bugs.dragonflybsd.org/issues/2533 Author: t_dfbsd Status: New Priority: High Assignee: Category: Target version: I've seen these lately: kernel: re0: watchdog timeout and the box loses network connectivity. I started getting them after updating to DragonFly v3.3.0.1365.g972077-DEVELOPMENT -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2533] re0: watchdog timeouts, network loss
Issue #2533 has been updated by t_dfbsd. No problem. I'd be happy to test another patch if you decide to revisit this at some point. Bug #2533: re0: watchdog timeouts, network loss http://bugs.dragonflybsd.org/issues/2533 Author: t_dfbsd Status: New Priority: High Assignee: Category: Target version: I've seen these lately: kernel: re0: watchdog timeout and the box loses network connectivity. I started getting them after updating to DragonFly v3.3.0.1365.g972077-DEVELOPMENT -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2533] re0: watchdog timeouts, network loss
Issue #2533 has been updated by t_dfbsd. It looks like this setting did the trick, thanks! Should I keep it in place and close this ticket? Bug #2533: re0: watchdog timeouts, network loss http://bugs.dragonflybsd.org/issues/2533 Author: t_dfbsd Status: New Priority: High Assignee: Category: Target version: I've seen these lately: kernel: re0: watchdog timeout and the box loses network connectivity. I started getting them after updating to DragonFly v3.3.0.1365.g972077-DEVELOPMENT -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2533] re0: watchdog timeouts, network loss
Issue #2533 has been updated by t_dfbsd. Thanks, and so far so good. I'll give it a few more days, but it looks like this stopped the watchdog errors. Bug #2533: re0: watchdog timeouts, network loss http://bugs.dragonflybsd.org/issues/2533 Author: t_dfbsd Status: New Priority: High Assignee: Category: Target version: I've seen these lately: kernel: re0: watchdog timeout and the box loses network connectivity. I started getting them after updating to DragonFly v3.3.0.1365.g972077-DEVELOPMENT -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2532] games/hack: permissions
Issue #2532 has been reported by t_dfbsd. Bug #2532: games/hack: permissions http://bugs.dragonflybsd.org/issues/2532 Author: t_dfbsd Status: New Priority: Normal Assignee: Category: Target version: I get this when I try to run hack as non-root: perm: Permission denied Cannot link safelock to perm It seems you don't have write permission here. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2533] re0: watchdog timeouts, network loss
Issue #2533 has been updated by t_dfbsd. Some lines from dmesg: re0: RealTek 8111/8168 PCIe Gigabit Ethernet port 0xee00-0xeeff mem 0xfdff8000-0xfdffbfff,0xfdfff000-0xfdff irq 18 at device 0.0 on pci3 re0: Hardware rev. 0x2800; MAC ver. 0x2a; PCI-E 125MHz miibus0: MII bus on re0 Bug #2533: re0: watchdog timeouts, network loss http://bugs.dragonflybsd.org/issues/2533 Author: t_dfbsd Status: New Priority: High Assignee: Category: Target version: I've seen these lately: kernel: re0: watchdog timeout and the box loses network connectivity. I started getting them after updating to DragonFly v3.3.0.1365.g972077-DEVELOPMENT -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2365] (Closed) Hammer pfs-destroy and prune-everything can cause network loss
Issue #2365 has been updated by t_dfbsd. Status changed from New to Closed After a good bit of testing, I'm ready to declare this resolved. Again, as of approximately one month ago this was still very much an issue, so some recent commit or combination of commits must have fixed it. Bug #2365: Hammer pfs-destroy and prune-everything can cause network loss http://bugs.dragonflybsd.org/issues/2365 Author: t_dfbsd Status: Closed Priority: Normal Assignee: Category: Target version: Fairly consistently, when I run hammer prune-everything, at some point in the process my ssh session will stop and not recover and the machine becomes unavailable on the network. It eventually returns to normal and I can reconnect to it. Today, I ran a hammer pfs-destroy on a 1.3TB pfs and the same thing happened. While the network was out, it was putting these messages in the log: swap_pager: indefinite wait buffer: offset: 6489661440, size: 4096 swap_pager: indefinite wait buffer: offset: 23187279872, size: 4096 swap_pager: indefinite wait buffer: offset: 6642294784, size: 4096 swap_pager: indefinite wait buffer: offset: 6536355840, size: 4096 swap_pager: indefinite wait buffer: offset: 6500122624, size: 4096 swap_pager: indefinite wait buffer: offset: 6489661440, size: 4096 swap_pager: indefinite wait buffer: offset: 6725648384, size: 4096 swap_pager: indefinite wait buffer: offset: 23187279872, size: 4096 swap_pager: indefinite wait buffer: offset: 6642294784, size: 4096 swap_pager: indefinite wait buffer: offset: 6536355840, size: 4096 swap_pager: indefinite wait buffer: offset: 6500122624, size: 4096 swap_pager: indefinite wait buffer: offset: 861982720, size: 4096 swap_pager: indefinite wait buffer: offset: 6489661440, size: 4096 swap_pager: indefinite wait buffer: offset: 6725648384, size: 4096 swap_pager: indefinite wait buffer: offset: 23187279872, size: 4096 swap_pager: indefinite wait buffer: offset: 6642294784, size: 4096 swap_pager: indefinite wait buffer: offset: 1027108864, size: 4096 swap_pager: indefinite wait buffer: offset: 6536355840, size: 4096 swap_pager: indefinite wait buffer: offset: 6500122624, size: 4096 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2365] Hammer pfs-destroy and prune-everything can cause network loss
Issue #2365 has been updated by t_dfbsd. As recent as one month ago, this was still a problem. In fact, it happened very consistently with hammer prune-everything. Tonight, I ran it twice and network connections to the box didn't drop. Could recent commits have fixed this? Bug #2365: Hammer pfs-destroy and prune-everything can cause network loss http://bugs.dragonflybsd.org/issues/2365 Author: t_dfbsd Status: New Priority: Normal Assignee: Category: Target version: Fairly consistently, when I run hammer prune-everything, at some point in the process my ssh session will stop and not recover and the machine becomes unavailable on the network. It eventually returns to normal and I can reconnect to it. Today, I ran a hammer pfs-destroy on a 1.3TB pfs and the same thing happened. While the network was out, it was putting these messages in the log: swap_pager: indefinite wait buffer: offset: 6489661440, size: 4096 swap_pager: indefinite wait buffer: offset: 23187279872, size: 4096 swap_pager: indefinite wait buffer: offset: 6642294784, size: 4096 swap_pager: indefinite wait buffer: offset: 6536355840, size: 4096 swap_pager: indefinite wait buffer: offset: 6500122624, size: 4096 swap_pager: indefinite wait buffer: offset: 6489661440, size: 4096 swap_pager: indefinite wait buffer: offset: 6725648384, size: 4096 swap_pager: indefinite wait buffer: offset: 23187279872, size: 4096 swap_pager: indefinite wait buffer: offset: 6642294784, size: 4096 swap_pager: indefinite wait buffer: offset: 6536355840, size: 4096 swap_pager: indefinite wait buffer: offset: 6500122624, size: 4096 swap_pager: indefinite wait buffer: offset: 861982720, size: 4096 swap_pager: indefinite wait buffer: offset: 6489661440, size: 4096 swap_pager: indefinite wait buffer: offset: 6725648384, size: 4096 swap_pager: indefinite wait buffer: offset: 23187279872, size: 4096 swap_pager: indefinite wait buffer: offset: 6642294784, size: 4096 swap_pager: indefinite wait buffer: offset: 1027108864, size: 4096 swap_pager: indefinite wait buffer: offset: 6536355840, size: 4096 swap_pager: indefinite wait buffer: offset: 6500122624, size: 4096 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2441] rtorrent downloads broken, possibly related to recent mmap work
Issue #2441 has been reported by Tim Darby. Bug #2441: rtorrent downloads broken, possibly related to recent mmap work http://bugs.dragonflybsd.org/issues/2441 Author: Tim Darby Status: New Priority: Normal Assignee: Category: Target version: Running DragonFly v3.3.0.165.gdc43b7-DEVELOPMENT, x86-64 Since upgrading to recent master, rtorrent downloads have been frequently failing with the message hash check on download completion found bad chunks. I've never that message from rtorrent before. I tried setting machdep.pmap_mmu_optimize=0 and the failures stopped. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
[DragonFlyBSD - Bug #2437] rtorrent crashes with large number of connections
Issue #2437 has been updated by Tim Darby. I think you're right, but it's an improvement and I don't know what a real fix would be. Bug #2437: rtorrent crashes with large number of connections http://bugs.dragonflybsd.org/issues/2437 Author: Tim Darby Status: Feedback Priority: Normal Assignee: Category: Target version: When I build libtorrent from pkgsrc with kqueue support, it crashes quickly if there are a large number of connections (doesn't happen with select polling). The error message is PollKQueue::modify() error: Bad file descriptor. After some Googling, I found this FreeBSD patch which fixes the problem in my limited testing so far: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net-p2p/libtorrent/files/patch-src_torrent_poll__kqueue.cc Can someone get this into pkgsrc for DF? -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
