[Bug 219829] "systat -if 1" Peak has wrong display
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219829 o...@j.email.ne.jp changed: What|Removed |Added CC||o...@j.email.ne.jp --- Comment #4 from o...@j.email.ne.jp --- I also noticed that I see this happens when I bring down or restart wlan0. I prepared a fix for this at https://reviews.freebsd.org/D25226 . If you can try and report your result back, that will be nice. -- 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 247131] vm: Fix typos
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247131 --- Comment #3 from Sebastien Boisvert --- Hello Mark Johnston, Thank you for your feedback. Do you want me to do a much smaller v2 with only those real typos ? - on-the-fly (since in the same file it is written already on-the-fly elsewhere_ - backward-looking (no s) - enqueing -> enqueuing - xbusied -> busied (maybe xbusied means something, I don't know) - remove the mapping for kernel virtual memory (the word memory is missing) - If an error occurs while writing to swap (missing 'while') - any pending paging - valid block and ensure that all pending paging operations (any vs all) - least vs lowest - sqeeze -> squeeze - lets -> let's -- 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 247155] unbound-checkconf fails because default path /etc/unbound is hardcoded and FreeBSD uses /var/unbound instead
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247155 Bug ID: 247155 Summary: unbound-checkconf fails because default path /etc/unbound is hardcoded and FreeBSD uses /var/unbound instead Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: sblachm...@gmail.com unbound on FreeBSD seems unmaintained since 2 years, lots of bugs piling up :( So apparently nobody has bothered yet to update unbound-checkconf from using default /usr/local/etc/unbound after somebody decided that unbound on FreeBSD uses /var/unbound instead. For this reason unbound-checkconf fails unless one places a link from /etc/unbound to /var/unbound. Can somebody please correct the hard-coded path in unbound-checkconf.c, so one no longer needs to set a link as quick workaround? -- 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 247129] [PATCH] Fix some compiler warnings in netinet alias module
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247129 --- Comment #3 from nikethmur...@protonmail.com --- Created attachment 215431 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=215431=edit Alternate patch for sys/netinet/libalias/alias.c Thanks for looking at my patch and catching what I missed. I've updated the original patch to not drop updated values after function calls. As an alternate approach to this, I've attached a patch with a slightly different approach (alias.diff.2). I thought this change would make it easier to read. Please let me know what you think. -- 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 247129] [PATCH] Fix some compiler warnings in netinet alias module
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247129
--- Comment #2 from nikethmur...@protonmail.com ---
Comment on attachment 215410
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=215410
Patch for /sys/netinet/libalias/alias.c
Index: alias.c
===
--- alias.c (revision 361967)
+++ alias.c (working copy)
@@ -443,7 +443,8 @@
IcmpAliasIn(struct libalias *la, struct ip *pip)
{
struct icmp *ic;
- int dlen, iresult;
+ uint16_t dlen;
+ int iresult;
LIBALIAS_LOCK_ASSERT(la);
@@ -740,7 +741,7 @@
{
struct udphdr *ud;
struct alias_link *lnk;
- int dlen;
+ uint16_t dlen;
LIBALIAS_LOCK_ASSERT(la);
@@ -839,7 +840,8 @@
u_short dest_port;
u_short proxy_server_port;
int proxy_type;
- int dlen, error;
+ uint16_t dlen;
+ int error;
LIBALIAS_LOCK_ASSERT(la);
@@ -944,7 +946,7 @@
{
struct tcphdr *tc;
struct alias_link *lnk;
- int dlen;
+ uint16_t dlen;
LIBALIAS_LOCK_ASSERT(la);
@@ -1069,7 +1071,8 @@
static int
TcpAliasOut(struct libalias *la, struct ip *pip, int maxpacketsize, int
create)
{
- int dlen, proxy_type, error;
+ uint16_t dlen;
+ int proxy_type, error;
u_short dest_port;
u_short proxy_server_port;
struct in_addr dest_address;
@@ -1343,9 +1346,10 @@
static int
LibAliasInLocked(struct libalias *la, char *ptr, int maxpacketsize)
{
- struct in_addr alias_addr;
+ struct in_addr alias_addr,ip_dst;
struct ip *pip;
int iresult;
+ u_short ip_sum ;
if (la->packetAliasMode & PKT_ALIAS_REVERSE) {
la->packetAliasMode &= ~PKT_ALIAS_REVERSE;
@@ -1398,14 +1402,24 @@
error = find_handler(IN, IP, la, pip, );
if (error == 0)
iresult = PKT_ALIAS_OK;
- else
+ else {
+ ip_dst = pip->ip_dst;
+ ip_sum = pip->ip_sum;
iresult = ProtoAliasIn(la, pip->ip_src,
- >ip_dst, pip->ip_p, >ip_sum);
+ _dst, pip->ip_p, _sum);
+ pip->ip_dst = ip_dst;
+ pip->ip_sum = ip_sum;
+ }
}
break;
- default:
- iresult = ProtoAliasIn(la, pip->ip_src, >ip_dst,
- pip->ip_p, >ip_sum);
+ default: {
+ ip_dst = pip->ip_dst;
+ ip_sum = pip->ip_sum;
+ iresult = ProtoAliasIn(la, pip->ip_src, _dst,
+ pip->ip_p, _sum);
+ }
+ pip->ip_dst = ip_dst;
+ pip->ip_sum = ip_sum;
break;
}
@@ -1421,8 +1435,12 @@
}
}
} else {
- iresult = FragmentIn(la, pip->ip_src, >ip_dst, pip->ip_id,
- >ip_sum);
+ ip_dst = pip->ip_dst;
+ ip_sum = pip->ip_sum;
+ iresult = FragmentIn(la, pip->ip_src, _dst, pip->ip_id,
+ _sum);
+ pip->ip_dst = ip_dst;
+ pip->ip_sum = ip_sum;
}
getout:
@@ -1479,8 +1497,9 @@
)
{
int iresult;
- struct in_addr addr_save;
+ struct in_addr addr_save,ip_src;
struct ip *pip;
+ u_short ip_sum;
if (la->packetAliasMode & PKT_ALIAS_REVERSE) {
la->packetAliasMode &= ~PKT_ALIAS_REVERSE;
@@ -1555,18 +1574,33 @@
error = find_handler(OUT, IP, la, pip, );
if (error == 0)
iresult = PKT_ALIAS_OK;
- else
- iresult = ProtoAliasOut(la, >ip_src,
- pip->ip_dst, pip->ip_p, >ip_sum,
create);
+ else {
+ ip_src = pip->ip_src;
+ ip_sum = pip->ip_sum;
+ iresult = ProtoAliasOut(la, _src,
+ pip->ip_dst, pip->ip_p, _sum, create);
+ pip->ip_src = ip_src;
+ pip->ip_sum = ip_sum;
+ }
}
break;
- default:
- iresult = ProtoAliasOut(la, >ip_src,
- pip->ip_dst, pip->ip_p, >ip_sum, create);
+ default: {
+ ip_src = pip->ip_src;
+ ip_sum = pip->ip_sum;
+ iresult = ProtoAliasOut(la, _src,
+
[Bug 241600] Netmap libraries far out of sync with utilities
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241600 Mark Johnston changed: What|Removed |Added Resolution|--- |Overcome By Events Status|New |Closed --- Comment #3 from Mark Johnston --- Thanks Vincenzo. I will resolve this bug for now since in in-tree netmap is indeed being updated. Please re-open if there's something specific you can point to as missing from the in-tree version. -- 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 247153] emulators/virtualbox-ose-kmod System crash on VM resume after system upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247153 Bug ID: 247153 Summary: emulators/virtualbox-ose-kmod System crash on VM resume after system upgrade Product: Base System Version: 12.1-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: rkober...@gmail.com After I updated my 12-STABLE system yesterday I can no longer resume a paused VM (Windows7). I get a system crash. I rolled back to my previous version, r361980 but the VM shows "Powered off" and the system still crashes at some point in the VM boot. Full dumps available. Sue to all of the drm related stuff in hte backtrace, I am going to try backingupto a slightly earlier kernel and see if I can get the VM to boot. Both drm-fbsd12.0-kmod-4.16.g20200221 and virtualbox-ose-kmod-5.2.34 were rebuilt after the kernel build using PORTS_MODULE. Here is the backtrace from the first crash. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x105887000 fault code = supervisor write data, page not present instruction pointer = 0x20:0x82a93ce0 stack pointer = 0x28:0xfe004e780390 frame pointer = 0x28:0xfe004e7803f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2161 (VirtualBox) trap number = 12 WARNING !drm_modeset_is_locked(>mutex) failed at /usr/obj/usr/src/amd64.amd64/sys/GENERIC.4BSD/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-99da0ba/drivers/gpu/drm/drm_atomic_helper.c:577 #0 0x828df413 at linux_dump_stack+0x23 #1 0x828686bd at drm_atomic_helper_check_modeset+0xcd #2 0x827b135f at intel_atomic_check+0x1f #3 0x828666bb at drm_atomic_check_only+0x2ab #4 0x82866a63 at drm_atomic_commit+0x13 #5 0x82892a88 at restore_fbdev_mode_atomic+0x1c8 #6 0x8288edaa at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #7 0x828b4767 at vt_kms_postswitch+0x127 #8 0x80a21a7a at vt_window_switch+0x13a #9 0x80a1eaef at vtterm_cngrab+0x1f #10 0x80b54fc6 at cngrab+0x16 #11 0x80bb52d5 at vpanic+0xe5 #12 0x80bb51e3 at panic+0x43 #13 0x8107f331 at trap_fatal+0x391 #14 0x8107f38f at trap_pfault+0x4f #15 0x8107e9d6 at trap+0x286 #16 0x81058d48 at calltrap+0x8 #17 0x82a81867 at logo_update.ypos+0xcfe1b WARNING !drm_modeset_is_locked(>mutex) failed at /usr/obj/usr/src/amd64.amd64/sys/GENERIC.4BSD/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-99da0ba/drivers/gpu/drm/drm_atomic_helper.c:577 #0 0x828df413 at linux_dump_stack+0x23 #1 0x828686bd at drm_atomic_helper_check_modeset+0xcd #2 0x827b135f at intel_atomic_check+0x1f #3 0x828666bb at drm_atomic_check_only+0x2ab #4 0x82866a63 at drm_atomic_commit+0x13 #5 0x82892a88 at restore_fbdev_mode_atomic+0x1c8 #6 0x8288edaa at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #7 0x828b4767 at vt_kms_postswitch+0x127 #8 0x80a21a7a at vt_window_switch+0x13a #9 0x80a1eaef at vtterm_cngrab+0x1f #10 0x80b54fc6 at cngrab+0x16 #11 0x80bb52d5 at vpanic+0xe5 #12 0x80bb51e3 at panic+0x43 #13 0x8107f331 at trap_fatal+0x391 #14 0x8107f38f at trap_pfault+0x4f #15 0x8107e9d6 at trap+0x286 #16 0x81058d48 at calltrap+0x8 #17 0x82a81867 at logo_update.ypos+0xcfe1b WARNING !drm_modeset_is_locked(>mode_config.connection_mutex) failed at /usr/obj/usr/src/amd64.amd64/sys/GENERIC.4BSD/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-99da0ba/drivers/gpu/drm/drm_atomic_helper.c:622 #0 0x828df413 at linux_dump_stack+0x23 #1 0x82868840 at drm_atomic_helper_check_modeset+0x250 #2 0x827b135f at intel_atomic_check+0x1f #3 0x828666bb at drm_atomic_check_only+0x2ab #4 0x82866a63 at drm_atomic_commit+0x13 #5 0x82892a88 at restore_fbdev_mode_atomic+0x1c8 #6 0x8288edaa at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #7 0x828b4767 at vt_kms_postswitch+0x127 #8 0x80a21a7a at vt_window_switch+0x13a #9 0x80a1eaef at vtterm_cngrab+0x1f #10 0x80b54fc6 at cngrab+0x16 #11 0x80bb52d5 at vpanic+0xe5 #12 0x80bb51e3 at panic+0x43 #13 0x8107f331 at trap_fatal+0x391 #14 0x8107f38f at trap_pfault+0x4f 15 0x8107e9d6 at trap+0x286 #16 0x81058d48 at calltrap+0x8 #17 0x82a81867 at logo_update.ypos+0xcfe1b WARNING !drm_modeset_is_locked(>mutex) failed at
[Bug 247126] zgrep(1) does not handle -f FILE correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247126 Craig Leres changed: What|Removed |Added Attachment #215407|0 |1 is obsolete|| --- Comment #2 from Craig Leres --- Created attachment 215428 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=215428=edit revised patch I see now the wrapper script fails when the flags are not discrete: # Works % fgrep -we RELEASE /etc/motd FreeBSD 12.1-RELEASE-p3 GENERIC # Fails % zfgrep -we RELEASE /etc/motd grep: RELEASE: No such file or directory This updated patch takes advantage of the fact that "extra argument" flags must come last. It also lets "-e PATTERN" pass through to *grep with other flags instead of moving the pattern to the end. -- 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 239058] lex: input() returns EOF instead of 0 on end-of-file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239058 Jung-uk Kim changed: What|Removed |Added Assignee|b...@freebsd.org|j...@freebsd.org --- Comment #3 from Jung-uk Kim --- Okay, I'll update flex. -- 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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #191 from jyoun...@gmail.com --- (In reply to Henri Hennebert from comment #190) The write protection is inverted for me as well with the latest version on git: Inserting the card with the toggle switch in the locked position: [1292] rtsx0: Interrupt card inserted/removed [1292] rtsx0: Card present [1292] mmc0: on rtsx0 [1292] mmcsd0: 253MB at mmc0 50.0MHz/4bit/256-block Inserting the card with the toggle switch in the unlocked position: [1387] rtsx0: Interrupt card inserted/removed [1387] rtsx0: Card present [1387] mmc0: on rtsx0 [1387] mmcsd0: 253MB (read-only) at mmc0 50.0MHz/4bit/256-block Note I still need to apply the inversion in rtsx_is_card_present as well. -- 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 247131] vm: Fix typos
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247131 --- Comment #2 from Mark Johnston --- I'm not a big fan of this patch: the typos don't really hurt readability, and fixing them will pollute the commit history, making it harder to find the original commit that added a given line. The changes are also not really consistent. For example: - One change to swap_pager.c changes "SWAP" to "OBJT_SWAP", but leaves "DEFAULT" as-is. - One hunk changes one instance "type-stability" to "type stability" (why?), but that term appears in multiple places in sys/vm. - A couple of changes add a period to the end of a sentence, but leave the sentence uncapitalized. If we are going to churn the sources, the diff should fix as many problems as possible while not introducing inconsistencies. In general I'd prefer to see patches that rewrite comments to make them more useful, fixing typos as a side effect, or simply deleting self-evident comments like /* remove kernel mappings */ followed by a pmap_qremove() call. -- 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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #190 from Henri Hennebert --- (In reply to Sergey V. Dyatko from comment #189) 1. The suspend/resume is not yet implemented, so it is normal. 2. I will ask jyoun...@gmail.com to test the ro inversion. Thanks for our time. -- 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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #189 from Sergey V. Dyatko --- (In reply to Henri Hennebert from comment #188) well 2 notes: 1. after suspend/resume card detection doesn't work (it was reported before?) 2. card wasn't write protected but when I locked it (lock on sd card): Jun 10 18:51:33 laptop kernel: pci4: at device 0.0 (no driver attached) Jun 10 18:51:36 laptop kernel: rtsx0: mem 0xf210-0xf2100fff at device 0.0 on pci4 Jun 10 18:51:36 laptop kernel: rtsx0: Card present Jun 10 18:51:36 laptop kernel: mmc0: on rtsx0 Jun 10 18:51:40 laptop kernel: rtsx0: Controller timeout Jun 10 18:51:40 laptop kernel: rtsx0: Soft reset Jun 10 18:51:40 laptop kernel: rtsx0: Controller timeout Jun 10 18:51:40 laptop kernel: rtsx0: Soft reset Jun 10 18:51:42 laptop kernel: rtsx0: Controller timeout Jun 10 18:51:42 laptop kernel: rtsx0: Soft reset Jun 10 18:51:45 laptop kernel: rtsx0: Controller timeout Jun 10 18:51:45 laptop kernel: rtsx0: Soft reset Jun 10 18:51:48 laptop kernel: rtsx0: Controller timeout Jun 10 18:51:48 laptop kernel: rtsx0: Soft reset Jun 10 18:51:48 laptop kernel: rtsx0: Controller timeout Jun 10 18:51:48 laptop kernel: rtsx0: Soft reset Jun 10 18:51:51 laptop kernel: rtsx0: Controller timeout Jun 10 18:51:51 laptop kernel: rtsx0: Soft reset Jun 10 18:51:52 laptop kernel: rtsx0: Controller timeout Jun 10 18:51:52 laptop kernel: rtsx0: Soft reset Jun 10 18:51:52 laptop kernel: mmc0: CMD8 failed, RESULT: 1 Jun 10 18:51:52 laptop kernel: mmcsd0: 128MB at mmc0 50.0MHz/4bit/256-block I can mount it and copy files to sd-card, looks like in my case RO/RW should be inverted, as in attach/detach case -- 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 247129] [PATCH] Fix some compiler warnings in netinet alias module
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247129 Mark Johnston changed: What|Removed |Added Status|New |Open CC||ma...@freebsd.org --- Comment #1 from Mark Johnston --- - Please ensure that local variables are declared at the beginning of the function, per style(9). - FragmentIn() and ProtoAliasIn() may modify the destination address, and with your patch the modification is discarded. So I think the patch is incorrect. -- 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 247147] smsc driver VLAN packet reception does not work
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247147 Bug ID: 247147 Summary: smsc driver VLAN packet reception does not work Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: iz-rp...@hs-karlsruhe.de Hello, while setting up a service on a smsc driver based VLAN I discovered that the interface does not receive any VLAN tagged packet but is able to send such. The system with the smsc interface is a RPi 3B hardware. The other system is a standard desktop. Both systems are connected via a unmanaged switch and running CURRENT. The RPi is at r361822, the desktop at r361721. To reproduce the bug, I set up a VLAN 1510 with a IPv4 address 10.151.15.253/20 on the RPi 3B and 10.151.15.250/20 on the desktop. Then I pinged the base interface addresses vice versa. Which worked as expected. After that I pinged the VLAN IPv4 addresses. Which does not work. As you can see by the following tcpdump output, the desktop gets the ARP requests from the RPi 3B and generates ARP replys, but the RPi 3B does not get them. Experimenting with static ARP entries does not fix the problem as the ICMP echo (replys) were not printed by tcpdump. At the moment it looks to me like the VLAN transmit path in the smsc driver is fine while, while the VLAN reception path is not working. Meanwhile a colleague tried the same with his RPi 3B+ (muge driver) successfully. Because of that I think it is smsc related. Directly following are two screen(1) logs from the RPi 3B and from the desktop, to show what I have tried and what the results were. Regards, Ralf +++ On the RPi 3B +++ # ifconfig ue0 ue0: flags=8843 metric 0 mtu 1500 options=80009 ether b8:27:eb:ee:12:27 inet 192.168.178.30 netmask 0xff00 broadcast 192.168.178.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=23 # ifconfig ue0.1510 create vlan 1510 vlandev ue0 inet 10.151.15.253/20 # ifconfig ue0.1510 ue0.1510: flags=8843 metric 0 mtu 1500 options=8 ether b8:27:eb:ee:12:27 inet 10.151.15.253 netmask 0xf000 broadcast 10.151.15.255 groups: vlan vlan: 1510 vlanpcp: 0 parent interface: ue0 media: Ethernet autoselect (100baseTX ) status: active nd6 options=21 # ping -c3 192.168.178.20 PING 192.168.178.20 (192.168.178.20): 56 data bytes 64 bytes from 192.168.178.20: icmp_seq=0 ttl=64 time=1.583 ms 64 bytes from 192.168.178.20: icmp_seq=1 ttl=64 time=0.859 ms 64 bytes from 192.168.178.20: icmp_seq=2 ttl=64 time=0.724 ms --- 192.168.178.20 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.724/1.056/1.583/0.377 ms # ping -c3 10.151.15.250 PING 10.151.15.250 (10.151.15.250): 56 data bytes --- 10.151.15.250 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss # ping -c3 10.151.15.250 PING 10.151.15.250 (10.151.15.250): 56 data bytes --- 10.151.15.250 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss # (sleep 10; ping -c3 10.151.15.250 ) & tcpdump -i ue0.1510 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ue0.1510, link-type EN10MB (Ethernet), capture size 262144 bytes PING 10.151.15.250 (10.151.15.250): 56 data bytes 14:12:26.457851 ARP, Request who-has 10.151.15.250 tell 10.151.15.253, length 28 14:12:27.460115 ARP, Request who-has 10.151.15.250 tell 10.151.15.253, length 28 14:12:28.462050 ARP, Request who-has 10.151.15.250 tell 10.151.15.253, length 28 ^C 3 packets captured 3 packets received by filter 0 packets dropped by kernel # --- 10.151.15.250 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss # # arp -a ? (10.151.15.253) at b8:27:eb:ee:12:27 on ue0.1510 permanent [vlan] rpi3b.fritz.box (192.168.178.30) at b8:27:eb:ee:12:27 on ue0 permanent [ethernet] # --- On the RPi 3b --- +++ On the desktop +++ # ifconfig em0 em0: flags=8863 metric 0 mtu 1500 options=481249b ether 78:24:af:40:71:b7 inet 192.168.178.20 netmask 0xff00 broadcast 192.168.178.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=23 # ifconfig em0.1510 create vlan 1510 vlandev em0 inet 10.151.15.250/20 # ifconfig em0.1510 em0.1510: flags=8843 metric 0 mtu 1500 options=4000403 ether 78:24:af:40:71:b7 inet 10.151.15.250 netmask 0xf000 broadcast 10.151.15.255 groups: vlan vlan: 1510 vlanpcp: 0 parent interface: em0 media: Ethernet autoselect (100baseTX ) status: active nd6 options=21 # ping -c3 192.168.178.30 PING 192.168.178.30 (192.168.178.30): 56 data bytes 64 bytes from 192.168.178.30:
[Bug 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #188 from Henri Hennebert --- (In reply to Sergey V. Dyatko from comment #187) Save the timeout is it working? Is your card switch on read-only? -- 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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #187 from Sergey V. Dyatko --- (In reply to Henri Hennebert from comment #186) it is master + rtsx_is_card_present() patch: Jun 10 17:24:34 laptop kernel: rtsx0: mem 0xf210-0xf2100fff at device 0.0 on pci4 Jun 10 17:24:34 laptop kernel: rtsx0: Card present Jun 10 17:24:34 laptop kernel: mmc0: on rtsx0 Jun 10 17:24:42 laptop kernel: rtsx0: Controller timeout Jun 10 17:24:42 laptop kernel: rtsx0: Soft reset Jun 10 17:24:42 laptop kernel: rtsx0: Controller timeout Jun 10 17:24:42 laptop kernel: rtsx0: Soft reset Jun 10 17:24:42 laptop kernel: rtsx0: Controller timeout Jun 10 17:24:42 laptop kernel: rtsx0: Soft reset Jun 10 17:24:51 laptop kernel: rtsx0: Controller timeout Jun 10 17:24:51 laptop kernel: rtsx0: Soft reset Jun 10 17:24:51 laptop kernel: rtsx0: Controller timeout Jun 10 17:24:51 laptop kernel: rtsx0: Soft reset Jun 10 17:24:51 laptop kernel: rtsx0: Controller timeout Jun 10 17:24:51 laptop kernel: rtsx0: Soft reset Jun 10 17:24:51 laptop kernel: rtsx0: Controller timeout Jun 10 17:24:51 laptop kernel: rtsx0: Soft reset Jun 10 17:24:51 laptop kernel: rtsx0: Controller timeout Jun 10 17:24:51 laptop kernel: rtsx0: Soft reset Jun 10 17:24:51 laptop kernel: mmc0: CMD8 failed, RESULT: 1 Jun 10 17:24:51 laptop kernel: mmcsd0: 128MB (read-only) at mmc0 50.0MHz/4bit/256-block -- 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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #186 from Henri Hennebert --- After tagging the master branch I merge the tweak branch to master. So now use the only branch master. To access the master branch as of 2020-06-04 use the release with tag '2020-06-04'. -- 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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #185 from Henri Hennebert --- (In reply to Mario Lobo from comment #182) With my Acer Aspire E 15 E5-576-77W6 with RTL8411B I also encounter the same problem (timeout) from time to time during insert. But it is not easily reproduce. Moreover repeated insert/remove seems to allow a detection of the card. Thanks for your test! -- 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"
Teknoloji ve Algoritmik İşlemler: Yatırımın ve Aracı Kurumların Geleceği 2- Teoriden Uygulamaya Geçiş
TSPB Birlikte Eğitim Mesleki Gelişim Eğitimleri Blteni Daha İyi Grntlemek İin Tıklayın [http://track.powered-by-n-mailer.com/1100D2389707|01109990485b4d55f5b11034a73625947252|11105162|0110469|10012334.html]TSPB Birlikte Eğitim Mesleki Gelişim Eğitimleri "Teknoloji ve Algoritmik İşlemler: Yatırımın ve Aracı Kurumların Geleceği 2- Teoriden Uygulamaya Geiş" - Online Eğitim"Zoom"uygulaması zerinden gerekleştirilecektir. Eğitimin 25 kişilik kontenjanı bulunmaktadır. Başvurularını gerekleştirilen katılımcılara online eğitime giriş iin gerekli bilgiler iletilecektir. Online eğitime katılabilmek iin bilgisayarınıza "Zoom" uygulamasını yklemeniz gerekmektedir. Başvuru iin: www.tspb.org.tr [http://track.powered-by-n-mailer.com/1110L2389707|00105162|100122069|1100T.html] yelik ve başvurularınızla ilgili sorularınız iin: info@birlikteeğitim.org [mailto:info@birlikteeğitim.org] ve ya aşağıdaki telefon numarasından bize ulaşabilirsiniz. Eğitmen: Fırat Grler-6Zeka Eğitim Tarihi: 15 Haziran 2020 Eğitim Sresi: 1 Gn Ders Saati: 09:30-17:30 Eğitim creti: 200 TL (KDV dahil, kişi başı) Eğitim Yeri: Online Eğitim-Zoom Başvuru: www.tspb.org.tr [http://track.powered-by-n-mailer.com/0110L2389707|10115162|110022069|1010T.html] TSPB Birlikte Eğitim Bykdere Caddesi No: 173 1.Levent Plaza A Blok Kat4 Şişli-İstanbul Telefon: 0212 280 85 67 i...@birlikteegitim.org [mailto:i...@birlikteegitim.org] www.tspb.org.tr [http://track.powered-by-n-mailer.com/0011L2389707|11005162|11015892|1010T.html] Geen yıl gerekleştirilen teorik eğitim, geen yıl katılanların verdiği grşler doğrultusunda pratik rneklerle, yazılımlarla zenginleştirildi. Veri biliminin finans piyasalarına uygulanması, teoriden pratiğe Veri eşitleri: Byk veri, veriyi işleme hızı ve diğer maliyetler Phyton, Matlab, C# yazılım dillerinde uygulamalar Bulut ortamında algoritmaların alıştırılması Kolokasyondan alışan algoritmalar Yazılım dili bilmeyenler iin algoritmik işlemler 15 Haziran 2020 tarihinde "Teknoloji ve Algoritmik İşlemler: Yatırımın ve Aracı Kurumların Geleceği 2- Teoriden Uygulamaya Geiş" online eğitimimize bekliyoruz. EĞİTİM KONULARI Korona veri bilimini de herkese bulaştırdı: Lineer regresyonunu her tahmin modeline uygularsak ne olur? Algoritma mhendisliğine giriş: Derin ğrenme, yapay zeka, bilgisayarlı gr ve benzeri alanlardaki uygulamalar (teorik ilgiden pratik zmlere) Veri analizi: Veri olmadan algoritma olmaz. Farklı veriler algonuzu farklı sonulara gtrr. Veri eşitleri ve byklkleri ile ilgili rnekler: Temel analiz verisi, anlık veri, derinlikli veri, alım satım fiyatlarının ayrı modellenmesi, karşı taraf verisi, ITCH verisi Kendi verimizi oluşturalım: Fiyat zaman ilişkisine rnek. Trk hisse senetleri iin hacim dengesizlik barlarımızı oluşturalım. Phyton'da Borsa İstanbul verileriyle farklı veri barları oluşturma rneği l bariyer metodu: Oynaklık, byk sayılar kuralı, hata matrisi gibi istatistiki kavramların sistemin başarısına etkisi Borsa İstanbul verileriyle l bariyer metodunun uygulanma rneği Karşı taraf verisiyle hisse senetlerinde aracı kurum işlemlerini skorladık. Matlab programı zerinden kolokasyondaki sunucumuzda emir gnderdik. Bulut teknolojisiyle makine ğrenme yapısı nasıl kurulur? C# yazılım diliyle algoritmik işlem rnekleri- test ve gerek işlem incelemesiBu e-posta tarafınıza TSPB tarafından oluşturulan ye veritabanına kayıtlı olduğunuz iin gnderilmiştir.Beni bu listeden ıkar [http://track.powered-by-n-mailer.com/1000U2389707|00119990485b4d55f5b11034a73625947252|1000469|5162.html] ___ 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 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #184 from Henri Hennebert --- (In reply to Sergey V. Dyatko from comment #183) You encounter a read-only because I have added it in the tweak-RTS5229-RTS525A. I update the tweak-RTS5229-RTS525A branch. can you test if please. -- 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 247143] FEATURE IDEA: implement module_disable=YES in /boot/loader.conf file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247143 Bug ID: 247143 Summary: FEATURE IDEA: implement module_disable=YES in /boot/loader.conf file Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: verma...@interia.pl Currently many things are built into the kernel (like Bluetooth). The syntax module_load=YES loads module at system startup. Currently its not possible to disable (for example) Bluetooth because its compiled into the kernel without rebuilding it. Implementing module_disable=YES could/should allow disable a feature that is build into the kernel but one would not have to recompile the kernel (and lose the freebsd-update(8) updates). Just an idea ... Regards. -- 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 246311] [patch] procstat can't view current working directory (affects xfce4-terminal, linprocfs, ...)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246311 --- Comment #4 from Conrad Meyer --- I think you've identified the problem: don't set security.bsd.unprivileged_proc_debug if you want this functionality to work. The point of that sysctl is to disable functionality like this. -- 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 246311] [patch] procstat can't view current working directory (affects xfce4-terminal, linprocfs, ...)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246311 --- Comment #3 from Damjan Jovanovic --- (In reply to Mark Johnston from comment #2) xfce4-terminal runs child shells as the same user, but PGET_CANDEBUG doesn't allow reading even the same user's file descriptors when security.bsd.unprivileged_proc_debug=0. It really should be PGET_CANSEE, as you should be able to see your user's/group's processes and examine their file descriptors, like you can on Linux. -- 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"
