[Bug 224426] fetch -i runs in an endless loop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224426 --- Comment #2 from Wolfram Schneider --- (In reply to Zak from comment #1) The manpage says: HTTP only If this is still try, then I expect a fatal error: HTTPS not supported for -i -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224426] fetch -i runs in an endless loop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224426 Wolfram Schneider changed: What|Removed |Added Status|New |Open -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224426] fetch -i runs in an endless loop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224426 --- Comment #3 from Wolfram Schneider --- (In reply to Wolfram Schneider from comment #2) s/try/true/ -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224426] fetch -i runs in an endless loop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224426 --- Comment #4 from Wolfram Schneider --- It is a little bit more complicated than I thought. Some websites run in an endless loop, others not: endless loop: fetch -a -o index.html -i index.html https://www.nytimes.com fetch -a -o index.html -i index.html https://www.washingtonpost.com fetch -a -o index.html -i index.html https://www.freebsd.org fetch -a -o index.html -i index.html https://www.fsf.org/ fetch -a -o index.html -i index.html https://www.openbsd.org no endless loop: fetch -a -o index.html -i index.html https://www.apple.com fetch -a -o index.html -i index.html https://duckduckgo.com fetch -a -o index.html -i index.html https://www.google.com fetch -a -o index.html -i index.html https://www.theguardian.com -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224426] fetch -i runs in an endless loop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224426 --- Comment #5 from Zak --- (In reply to Wolfram Schneider from comment #4) Is the inconsistent looping behaviour present with my patch applied? I'm not at a proper computer so I can't check right now. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224529] The talk protocol depends on struct osockaddr which should be kernel-only
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224529 Bug ID: 224529 Summary: The talk protocol depends on struct osockaddr which should be kernel-only Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Keywords: easy Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: bro...@freebsd.org The talkd protocol defined in include/protocols/talkd.h uses the struct osockaddr definition from sys/socket.h. It should define it's own type so struct osockaddr can be removed from non-kernel use. The support for systems where sockaddr is the same as osockaddr in the talk program should also be removed since we don't need our tools to run on 4.3BSD. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224426] fetch -i runs in an endless loop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224426 Heqing Yan changed: What|Removed |Added CC||scottie...@gmail.com --- Comment #6 from Heqing Yan --- (In reply to Wolfram Schneider from comment #4) (In reply to Zak from comment #5) I applied Zak's patch and cannot reproduce it. Did you test Zak's patch? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224532] Remove resident count from procfs map
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224532 Bug ID: 224532 Summary: Remove resident count from procfs map Product: Base System Version: 11.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: glenn.weinb...@intel.com CC: ema...@freebsd.org, k...@freebsd.org procfs_map does a very naive resident count, which for huge unbacked virtual spaces takes essentially forever. Instead of trying to fix this (see bug 188911), the resident count field should be deprecated and always be set to 0. Linux procfs does not return resident counts. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224536] FLUSHCACHE48 AHCI Timeouts on SMR Drives
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224536 Bug ID: 224536 Summary: FLUSHCACHE48 AHCI Timeouts on SMR Drives Product: Base System Version: 11.1-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: ilge...@yahoo.it Hi! Starting from this thread: https://forums.freenas.org/index.php?threads/a-long-journey-to-solve-cam-status-command-timeout-issues.59549/ I had hard times troubleshooting this issue on FreeNAS with 4 x ST8000AS0002 Drives. It seems that drives increase latency over time and exceed the AHCI (hardcoded?) 31000 msec timeout. It will be great if FreeBSD could support these new SMR drives without disabling cache flushing on ZFS. Thanks, Fabio -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224536] FLUSHCACHE48 AHCI Timeouts on SMR Drives
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224536 fabiob changed: What|Removed |Added URL||https://forums.freenas.org/ ||index.php?threads/a-long-jo ||urney-to-solve-cam-status-c ||ommand-timeout-issues.59549 ||/#post-422291 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
