[DragonFlyBSD - Bug #3319] (New) setproctitle() calls can change effect of later setproctitle() calls

[bugtracker-admin]

Issue #3319 has been reported by tonyc.


Bug #3319: setproctitle() calls can change effect of later setproctitle() calls
http://bugs.dragonflybsd.org/issues/3319

* Author: tonyc
* Status: New
* Priority: Normal
* Target version: 6.4
* Start date: 2022-06-30

The final setproctitle() call in the attached code results in different outputs 
from ps depending on the whether the earlier setproctitle() calls are present.

$ cc 19894.c && ./a.out 
x (a.out)
$ cc -DMANY 19894.c && ./a.out 
a.out: -x (a.out)
$ uname -a
DragonFly  6.2-RELEASE DragonFly v6.2.2-RELEASE #2: Thu Jun  9 22:53:25 EDT 
2022 
r...@www.shiningsilence.com:/usr/obj/home/justin/release/6_2/sys/X86_64_GENERIC 
 x86_64

This came up from new perl tests failing on DragonflyBSD.

---Files
19894.c (667 Bytes)


-- 
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 #745] (Closed) the evil interrupt stats monster is still around!

[bugtracker-admin]

Issue #745 has been updated by tuxillo.

Status changed from Feedback to Closed
Target version changed from Unverifiable to 6.4

Over a decade marked as Unverifiable.


Bug #745: the evil interrupt stats monster is still around!
http://bugs.dragonflybsd.org/issues/745#change-14392

* Author: corecode
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Category: Unverifiable
* Target version: 6.4

hey,

while doing the pkgsrc bulk build, I get weird numbers in top.  I am pretty 
sure this has something to do with the multitude of shell scripts being used as 
wrappers in pkgsrc.  command execution is also slower than I'd expect (for 
example wrapper execution).

load averages:  8.38,  7.96,  5.53 up 0+03:48:32  22:34:35
151 processes: 151 running
CPU0 states: 13.7% user,  0.0% nice, 27.5% system,  0.0% interrupt, 58.8% idle
CPU1 states: 21.4% user,  0.0% nice, 28.3% system,  0.0% interrupt, 50.4% idle
CPU2 states: 22.1% user,  0.0% nice, 22.9% system,  0.0% interrupt, 55.0% idle
CPU3 states: 34.7% user,  0.0% nice, 11.1% system, 42.0% interrupt, 12.2% idle
Mem: 71M Active, 509M Inact, 268M Wired, 199M Buf, 2665M Free
Swap:

  PID USERNAME PRI NICE  SIZERES STATE  C   TIME   WCPUCPU COMMAND
36155 root 227   0  3060K  2736K wait   2   0:00 36.82%  8.15% bmake
37456 root 229   0   828K   704K RUN1   0:00 16.14%  2.93% sh
37677 root 197   0  1576K  1216K wait   2   0:00 14.53%  2.64% bmake
40985 root 182   0   824K   700K RUN3   0:00 40.00%  1.95% sh
41135 root 193   0   820K   696K wait   1   0:00 39.00%  1.90% sh
37807 root 172   0   828K   704K wait   0   0:00  9.69%  1.76% sh
37310 root 157   0   792K   668K wait   0   0:00  9.15%  1.66% sh
37961 root 210   0  1600K  1240K wait   0   0:00 10.85%  1.51% bmake
40898 root 157   0   784K   660K wait   2   0:00 30.00%  1.46% sh
37563 root 227   0  1464K  1104K wait   1   0:00  5.92%  1.07% bmake
37391 root 168   0   788K   664K wait   0   0:00  4.84%  0.88% sh
37316 root 162   0  1668K  1296K wait   0   0:00  4.57%  0.83% bmake
40213 root 182   0  1216K  1092K wait   1   0:00 16.00%  0.78% sh
39756 root 229   0   824K   700K wait   0   0:00  2.05%  0.20% sh
23163 root 163   0  1444K  1084K wait   2   0:00  0.26%  0.15% bmake
  679 corecode 152   0  5948K  3116K select 0   0:05  0.00%  0.00% sshd
87928 corecode 152   0  2340K  1632K RUN0   0:03  0.00%  0.00% top
 5266 root 152   0  6548K  6120K kqread 0   0:02  0.00%  0.00% pbulk-build
 2346 root 152   0  2384K  2052K select 2   0:01  0.00%  0.00% screen-4.0.3
  672 corecode 152   0  5948K  3112K select 2   0:01  0.00%  0.00% sshd
 6357 corecode 152   0  5948K  3124K select 0   0:00  0.00%  0.00% sshd
83074 root 157   0  3236K  2908K wait   0   0:00  0.00%  0.00% bmake
61160 root 152   0  2340K  1632K CPU0   0   0:00  0.00%  0.00% top
84410 root 192   0  3152K  2828K wait   0   0:00  0.00%  0.00% bmake
60999 root 157   0  3388K  3072K wait   1   0:00  0.00%  0.00% bmake

that's what systat -vm tells:

   11 usersLoad  9.22  8.60  6.50  Jul 26 22:39

Mem:KBREALVIRTUAL VN PAGER  SWAP PAGER
Tot   Share  TotShareFree in  out in  out
Act   28560526067456 9252 2717488 count
All  8801328524  179343213480 pages
13651 zfod   Interrupts
Proc:r  p  d  s  wCsw  Trp  Sys  Int  Sof  Flt  16467 cow 556 total
10   45 727964259438586  475   6638986 284684 wire429 clk
70624 act  13 uhci0
21.6%Sys  12.8%Intr 30.8%User  0.0%Nice 34.8%Idl   524220 inact69 atapci1
||||||||||cache11 em0
===++ 2717552 freeata0
  daefr   irq19
Namei Name-cacheDir-cache   21446 prcfr34 irq21
Calls hits% hits% react
8174079364   97  1890 pdwake
  pdpgs
Disks   ad4   ad6  acd0   cd0 pass0   md0 intrn
KB/t   0.00 36.23  0.00  0.00  0.00  0.00  204096 buf
tps   034 0 0 0 01533 dirtybuf
MB/s   0.00  1.21  0.00  0.00  0.00  0.00  231015 desiredvnodes
% busy0 3 0 0 0 0   81881 numvnodes
 1602 freevnodes

cheers
  simon



-- 
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 #696] (Closed) IPSEC recommendation

[bugtracker-admin]

Issue #696 has been updated by tuxillo.

Category changed from Unverifiable to Kernel
Status changed from New to Closed
Target version changed from Unverifiable to 6.4

IPSEC was removed in commit:755d70b8f2c28b016b6c0330273e7daa38038f27


Bug #696: IPSEC recommendation
http://bugs.dragonflybsd.org/issues/696#change-14389

* Author: robin_carey5
* Status: Closed
* Priority: Low
* Assignee: tuxillo
* Category: Kernel
* Target version: 6.4

Not really a bug, more a recommendation:

For higher cryptography security you should make IPSEC
use my CipherPacket technique.

Source code for CipherPacket can be found at:

http://www.caesarion.org.uk

Sincerely,
R Carey.

  ___ 
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today 
http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html



-- 
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 #3305] (Closed) CBSD: Add NVMM support in DragonFly BSD

[bugtracker-admin]

Issue #3305 has been updated by tuxillo.

Status changed from In Progress to Closed

For now, this can be closed as confirmed with cbsd.


Bug #3305: CBSD: Add NVMM support in DragonFly BSD
http://bugs.dragonflybsd.org/issues/3305#change-14388

* Author: tuxillo
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Category: Feature request
* Target version: 6.4
* Start date: 2021-11-12

This is a tracking ticket for adding NVMM support in CBSD[1].

fn1. https://www.bsdstore.ru/en/



-- 
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 #3318] Segmenation fault when a process resumed with checkpt exits

[bugtracker-admin]

Issue #3318 has been updated by zabolekar.


tuxillo wrote in #note-1:

> We'll try t at least handle that case but we're also considering how useful 
> process checkpointing really is. If anybody has any feedback about it now it 
> would be the time to share it :-)

To clarify, I don't actually have a use for process checkpointing yet, this was 
my first time experimenting with it. It's just that sys_checkpoint/checkpt 
looks so nice and boilerplate-free compared to e.g. CRIU :)



Bug #3318: Segmenation fault when a process resumed with checkpt exits
http://bugs.dragonflybsd.org/issues/3318#change-14387

* Author: zabolekar
* Status: In Progress
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4
* Start date: 2022-06-12

DragonFly version: 6.2.1

Code example (error handling omitted for brevity):

#include 
#include 
#include 
#include 
 
void save(const char* filename)
{
int file = open(filename, O_RDWR|O_CREAT|O_TRUNC, 0666);
sys_checkpoint(CKPT_FREEZE, file, -1, -1);
close(file);
}
  
int main()
{
puts("a");
save("a.ckpt");
puts("b");
}


Expected output:


% gcc test.c -o test -Wall -Wextra
% ./test
a
b
% checkpt -r a.ckpt
b


Actual output:


% gcc test.c -o test -Wall -Wextra
% ./test
a
b
% checkpt -r a.ckpt
b
pid 1143 (test), uid 1001: exited on signal 11 (core dumped)
Segmentation fault (core dumped)


Backtrace with @gdb test test.core@:


#0  0x00080040400f in __tls_get_addr () from /libexec/ld-elf.so.2
#1  0x00080075648a in _thread_finalize () from /lib/libc.so.8
#2  0x000800756449 in exit () from /lib/libc.so.8
#3  0x004007b3 in _start ()


See also: https://lists.dragonflybsd.org/pipermail/users/2022-June/405002.html



-- 
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 #1921] we miss mlockall

[bugtracker-admin]

Issue #1921 has been updated by tuxillo.


Still pending of doing the the rlimit work, this is a reminder to myself.


Bug #1921: we miss mlockall
http://bugs.dragonflybsd.org/issues/1921#change-14386

* Author: alexh
* Status: In Progress
* Priority: Normal
* Assignee: tuxillo
* Category: VM subsystem
* Target version: 6.4

We don't have the mlockall/munlockall syscalls as documented in [1]. We have at 
least one tool in base that would benefit from it: cryptsetup. Hopefully 
someone 
more familiar with the VM system can implement it without much effort as we 
already have mlock/munlock.

Cheers,
Alex Hornung

[1]: http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html



-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by tuxillo.


Ok, we will have to check route(8) then, there might be a bug that needs fixing 
there.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14385

* Author: mneumann
* Status: In Progress
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)
clipboard-202206171102-blgae.png (66 KB)


-- 
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 #3318] (In Progress) Segmenation fault when a process resumed with checkpt exits

[bugtracker-admin]

Issue #3318 has been updated by tuxillo.

Status changed from New to In Progress
Assignee set to tuxillo
Target version set to 6.4

Back in the day we added two memory mappable devices (/dev/upmap and 
/dev/kpmap) which provide certain data from the kernel without the need of a 
system call. See commit:0adbcbd6bc12ddb.
One is per-thread and the other isn't.

The thing is that we need to add handling for the one which isn't per-thread, 
since sys_checkpoint(2) and checkpt(1) does not support threaded programs, as 
stated in the manpage:

>> Threaded programs cannot currently be checkpointed.  The program must be 
>> reduced to a single thread before it can be safely checkpointed.

See: https://man.dragonflybsd.org/?command=sys_checkpoint

We'll try t at least handle that case but we're also considering how useful 
process checkpointing really is. If anybody has any feedback about it now it 
would be the time to share it :-)


Bug #3318: Segmenation fault when a process resumed with checkpt exits
http://bugs.dragonflybsd.org/issues/3318#change-14384

* Author: zabolekar
* Status: In Progress
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4
* Start date: 2022-06-12

DragonFly version: 6.2.1

Code example (error handling omitted for brevity):

#include 
#include 
#include 
#include 
 
void save(const char* filename)
{
int file = open(filename, O_RDWR|O_CREAT|O_TRUNC, 0666);
sys_checkpoint(CKPT_FREEZE, file, -1, -1);
close(file);
}
  
int main()
{
puts("a");
save("a.ckpt");
puts("b");
}


Expected output:


% gcc test.c -o test -Wall -Wextra
% ./test
a
b
% checkpt -r a.ckpt
b


Actual output:


% gcc test.c -o test -Wall -Wextra
% ./test
a
b
% checkpt -r a.ckpt
b
pid 1143 (test), uid 1001: exited on signal 11 (core dumped)
Segmentation fault (core dumped)


Backtrace with @gdb test test.core@:


#0  0x00080040400f in __tls_get_addr () from /libexec/ld-elf.so.2
#1  0x00080075648a in _thread_finalize () from /lib/libc.so.8
#2  0x000800756449 in exit () from /lib/libc.so.8
#3  0x004007b3 in _start ()


See also: https://lists.dragonflybsd.org/pipermail/users/2022-June/405002.html



-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.

Assignee deleted (tuxillo)

debugged it further:


route add 172.31.1.1/32 -iface vtnet0


will result in:


add net 172.31.1.1: gateway vtnet0


while


route add 172.31.1.1 -iface vtnet0


will result in 


add host 172.31.1.1: gateway vtnet0



An IP with /32 doesn't really look like a network to me. Maybe something is 
going havoc in the kernel if a network with /32 is given?


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14383

* Author: mneumann
* Status: In Progress
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)
clipboard-202206171102-blgae.png (66 KB)


-- 
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 #3317] (In Progress) Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by tuxillo.

Status changed from New to In Progress
Assignee set to tuxillo

mneumann wrote in #note-19:
> "We" probably should :). I guess DragonFly uses a different "dhclient" than 
> FreeBSD, so diffing is not an option. Is "dhclient" going to be deprecated in 
> DragonFly, or why is there a working alterantive (dhcpcd)?

Yes, the idea is to permanently switch to dhcpcd and remove dhclient. dhclient 
comes from OpenBSD by the way.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14382

* Author: mneumann
* Status: In Progress
* Priority: Normal
* Assignee: tuxillo
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)
clipboard-202206171102-blgae.png (66 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.


Found the bug. So when I change:


route add 172.31.1.1/32 -iface vtnet0


to 


route add 172.31.1.1 -iface vtnet0


it works! Might be a parsing problem in `route`.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14381

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)
clipboard-202206171102-blgae.png (66 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.

File clipboard-202206171102-blgae.png added

There is `/sbin/dhclient-script` which is invoked with the following env 
variables set:

!clipboard-202206171102-blgae.png!

I could image that this script is doing something wrong.

The script is calling the following commands:


ifconfig vtnet0 inet 168.119.117.156 netmask 255.255.255.255 broadcast 
168.119.117.156
route add 172.31.1.1/32 -iface vtnet0
route add default 172.31.1.1



after afterwards one of the routes shows up scrabled, as in the original bug 
report.

I tried to enter exactly the same commands as dhclient-script produces, and 
voila I end up with the same scrabled route entry. So, it's not the fault of 
`dhclient`!!!


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14380

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)
clipboard-202206171102-blgae.png (66 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.


"We" probably should :). I guess DragonFly uses a different "dhclient" than 
FreeBSD, so diffing is not an option. Is "dhclient" going to be deprecated in 
DragonFly, or why is there a working alterantive (dhcpcd)?


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14379

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by tuxillo.


Nice!

The question is now, should we find out what's the problem with dhclient? 
Because it might be uncovering at the very least a _route(8)_ issue.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14378

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.


yes, 

dhcpcd_enable="YES"

alone works!



Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14377

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by tuxillo.


It seems to be related with our dhclient, it's definitely route related becuase 
if I use the config below in my rc.conf I'll get the bug you're reporting.


ifconfig_vtnet0="DHCP"


However, if I just use dhcpcd, all seems to work fine, can you please try it?


dhcpcd_enable="YES"





Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14376

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by tuxillo.


I didn't know DHCP was supposed to work, I'll give it a try and see what's up.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14375

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.


Hi tuxillo, 

1000x thanks!

With your snippet above, it works!
Now I can install things and maybe we can figure out why DHCP does not work 
properly.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14374

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by tuxillo.


Can you please try this in your rc.conf?


[...]


static_routes="hetzner default"
route_hetzner="172.31.1.1 -interface vtnet0"
route_default="default 172.31.1.1"
ifconfig_vtnet0="inet x.x.x.x netmask 255.255.255.255"
[...]




Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14373

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.


I'd like to setup the routes manually (not via dhclient), but I am strugging 
with it. This is what I do:


ifconfig vtnet0 inet 192.119.117.156 netmask 255.255.255.255 up
route add -interface 172.31.1.1 vtnet0
route add default 172.31.1.1



But, it's not showing "link#1" in the Gateway field for route 172.31.1.1 (it is 
initially empty, and later shows the MAC address) as it does when this route is 
added via `dhclient`. 

Not sure what I am doing wrong?


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14372

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.

File clipboard-202206140730-vzpkc.png added

This error message might be of interest:


rtsock: received more addr bits than sockaddrs.


!clipboard-202206140730-vzpkc.png!




Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14371

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)
clipboard-202206140730-vzpkc.png (302 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.


I also checked the integrity of the ISO image by doing an `dd if=/dev/cd0s0 
bs=2k | md5` and it is correct (d41d8...27e; 6.2.1).



Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14370

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.

File clipboard-202206140707-0biu1.png added

Some dmesg output:

!clipboard-202206140707-0biu1.png!



Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14369

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)
clipboard-202206140707-0biu1.png (326 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.


I have to correct myself. It's possible to mount a custom ISO. You just need to 
ask the support to do it (the dragonfly ISO is a custom ISO)


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14368

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)


-- 
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 #3318] (New) Segmenation fault when a process resumed with checkpt exits

[bugtracker-admin]

Issue #3318 has been reported by zabolekar.


Bug #3318: Segmenation fault when a process resumed with checkpt exits
http://bugs.dragonflybsd.org/issues/3318

* Author: zabolekar
* Status: New
* Priority: Normal
* Start date: 2022-06-12

DragonFly version: 6.2.1

Code example (error handling omitted for brevity):

#include 
#include 
#include 
#include 
 
void save(const char* filename)
{
int file = open(filename, O_RDWR|O_CREAT|O_TRUNC, 0666);
sys_checkpoint(CKPT_FREEZE, file, -1, -1);
close(file);
}
  
int main()
{
puts("a");
save("a.ckpt");
puts("b");
}


Expected output:


% gcc test.c -o test -Wall -Wextra
% ./test
a
b
% checkpt -r a.ckpt
b


Actual output:


% gcc test.c -o test -Wall -Wextra
% ./test
a
b
% checkpt -r a.ckpt
b
pid 1143 (test), uid 1001: exited on signal 11 (core dumped)
Segmentation fault (core dumped)


Backtrace with @gdb test test.core@:


#0  0x00080040400f in __tls_get_addr () from /libexec/ld-elf.so.2
#1  0x00080075648a in _thread_finalize () from /lib/libc.so.8
#2  0x000800756449 in exit () from /lib/libc.so.8
#3  0x004007b3 in _start ()


See also: https://lists.dragonflybsd.org/pipermail/users/2022-June/405002.html



-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.


No, it's not possible to mount a custom ISO image. But I asked the support, and 
~30 minutes later, they had the DragonFly (dfly-...) image uploaded and made 
available!!! Kudos.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14367

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by tuxillo.


Also, is it possible to mount a custom image from the Hetzner Cloud panel? I 
dont' see an option for that.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14366

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.


I will try to use `kgdb` at the weekend. Yes, I think it's KVM. The "garbage" 
changes when I remove the routes and add them again.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14365

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by tuxillo.


I wonder if those characters are garbage. Have you tried using kgdb to inspect 
the kernel structures? I don't know from the top of my head which ones are.
I'm assuing that's a KVM VM (since it's using vtnet)


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14364

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.


ah wait, no, I can't get `ping` to work. when I `route delete 172.31.1.1` and 
then `route add default 172.31.1.1` I have again two routes and one of them 
contains the strange characters in the Gateway column.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14363

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)


-- 
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 #3317] Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been updated by mneumann.


I can get `ping` to work when I flush the default route and add it again.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317#change-14362

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091711-dw2gp.png (69.3 KB)


-- 
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 #3317] (New) Network vtnet0 not working on Hetzner cloud

[bugtracker-admin]

Issue #3317 has been reported by mneumann.


Bug #3317: Network vtnet0 not working on Hetzner cloud
http://bugs.dragonflybsd.org/issues/3317

* Author: mneumann
* Status: New
* Priority: Normal
* Category: Networking
* Target version: 6.4
* Start date: 2022-06-09

After running `dhclient vtnet0`, I cannot ping anything except the default 
gateway (172.31.1.1).

`route show` shows two entries for the default route (172.31.1.1) and
one contains *very* strange characters:

!clipboard-202206091711-dw2gp.png!

(See the second line for 172.31.1.1...)

---Files
clipboard-202206091708-tazmu.png (138 KB)
clipboard-202206091711-dw2gp.png (69.3 KB)


-- 
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 #3316] hammer2_dirent_create() allows creating >1 dirents with the same name

[bugtracker-admin]

Issue #3316 has been updated by dillon.


The directory hash collision space does not guarantee name uniqueness, so the 
iterator is there on purpose to deal with hash collisions (names might be 
different, but key calculates to the same value).   Higher levels are 
responsible for ensuring that name duplication is disallowed.

There is a second reason here too... even though it isn't in the filesystem 
(yet), the multi-master quorum algorithm has to be able to synchronize valid 
entries even in the presence of invalid entries, so it is possible for two 
entries to exist on the media for the same filename where one has quorum and 
the other does not.  Temporarily (the one without quorum would eventually be 
deleted).

So I don't think this is a bug per-say.

-Matt


Bug #3316: hammer2_dirent_create() allows creating >1 dirents with the same name
http://bugs.dragonflybsd.org/issues/3316#change-14360

* Author: tkusumi
* Status: New
* Priority: Normal
* Target version: 6.4
* Start date: 2022-06-05

When creating a file/directory in HAMMER2, hammer2_dirent_create() scans lhc of 
a given name if a chain or ondisk blockref already exists. If it exists, the 
function assigns a different (incremented) lhc value. This ends up allowing two 
or more inodes with the same dirent name under the same directory.

Note that some (or many) filesystem implementation scans its parent directory 
contents and return EEXIST if the same name already exists.

In reality, VFS prevents this via name lookup and returns EEXIST before it 
reaches there. But if a program runs HAMMER2 without VFS on top of it, namely 
makefs(8), this can not be prevented.

In fact below diff creates an image containing two entities (different inode#, 
different blockref key, but same name and data) of each regular file in the 
source directory.
https://leaf.dragonflybsd.org/~tkusumi/diff/makefs_hammer2_dup_regfile.patch



-- 
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 #3316] (New) hammer2_dirent_create() allows creating >1 dirents with the same name

[bugtracker-admin]

Issue #3316 has been reported by tkusumi.


Bug #3316: hammer2_dirent_create() allows creating >1 dirents with the same name
http://bugs.dragonflybsd.org/issues/3316

* Author: tkusumi
* Status: New
* Priority: Normal
* Target version: 6.4
* Start date: 2022-06-05

When creating a file/directory in HAMMER2, hammer2_dirent_create() scans lhc of 
a given name if a chain or ondisk blockref already exists. If it exists, the 
function assigns a different (incremented) lhc value. This ends up allowing two 
or more inodes with the same dirent name under the same directory.

Note that some (or many) filesystem implementation scans its parent directory 
contents and return EEXIST if the same name already exists.

In reality, VFS prevents this via name lookup and returns EEXIST before it 
reaches there. But if a program runs HAMMER2 without VFS on top of it, namely 
makefs(8), this can not be prevented.

In fact below diff creates an image containing two entities (different inode#, 
different blockref key, but same name and data) of each regular file in the 
source directory.
https://leaf.dragonflybsd.org/~tkusumi/diff/makefs_hammer2_dup_regfile.patch



-- 
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 #933] (Closed) em(4) hardware error after ACPI suspend

[bugtracker-admin]

Issue #933 has been updated by tuxillo.

Description updated
Status changed from Feedback to Closed
% Done changed from 0 to 100

Although it may have worked at some point for some specific hardware, we don't 
support suspend/resume.


Bug #933: em(4) hardware error after ACPI suspend
http://bugs.dragonflybsd.org/issues/933#change-14357

* Author: matthias
* Status: Closed
* Priority: Normal
* Assignee: sepherosa
* Target version: 6.4

He,

since today I have an IBM Thinkpad T42 here.  The machine is equipped
with a em(4) NIC and a ath(4) wireless NIC.  After testing ACPI suspend
to RAM (state 3) which works flawlessly, I noticed some errors right
after the resume:

device_probe_and_attach: em0 attach returned 5
em0:  port
0x8000-0x803f mem 0xc020-0xc020,0xc022-0xc023 irq 11 at
device 1.0 on pci2
can't re-use a leaf (debug_info)!
can't re-use a leaf (stats)!
can't re-use a leaf (rx_int_delay)!
can't re-use a leaf (tx_int_delay)!
can't re-use a leaf (rx_abs_int_delay)!
can't re-use a leaf (tx_abs_int_delay)!
can't re-use a leaf (int_throttle_ceil)!
can't re-use a leaf (rxd)!
can't re-use a leaf (txd)!
em0: The EEPROM Checksum Is Not Valid
em0: Unable to initialize the hardware
device_probe_and_attach: em0 attach returned 5

Why does the EEPROM checksum changes during a suspend/resume cycle?  Is
it possible to suspend with this card?  This error also happens if I
unload the modules right before the suspend and load it again after
resume.

An error also happens with the ath(4).  If I don't unload the driver,
the card no longer gets an IP address from the DHCP server.
Loading/Unloading etc won't help.

A third error happens with USB stuff.  If I don't unload the USB module
I see a continuously stream of the following messages:

Jan 26 19:44:26 jupiter acpi: resumed at 20080126 19:44:26
Jan 26 19:44:27 jupiter kernel: uhub0: port 1 reset failed
Jan 26 19:44:27 jupiter kernel: uhub1: port 1 reset failed
Jan 26 19:44:27 jupiter kernel: uhub2: port 1 reset failed
Jan 26 19:44:28 jupiter kernel: uhub0: port 2 reset failed
Jan 26 19:44:28 jupiter kernel: uhub1: port 2 reset failed
Jan 26 19:44:28 jupiter kernel: uhub2: port 2 reset failed
Jan 26 19:44:30 jupiter kernel: uhub0: port 1 reset failed
Jan 26 19:44:30 jupiter kernel: uhub1: port 1 reset failed
Jan 26 19:44:30 jupiter kernel: uhub2: port 1 reset failed
[...]

Only rebooting the machine helps.  Append the relevant information:

DragonFly jupiter 1.11.0-DEVELOPMENT DragonFly 1.11.0-DEVELOPMENT #1:
Sat Jan 26 20:05:28 CET 2008

ath0@pci2:2:0:  class=0x02 card=0x833117ab chip=0x1014168c rev=0x01
hdr=0x00
vendor   = 'Atheros Communications Inc.'
device   = 'AR5212 Atheros AR5212 802.11abg wireless

em0@pci2:1:0:   class=0x02 card=0x05491014 chip=0x101e8086 rev=0x03
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82540EP Gigabit Ethernet Controller (Mobile)'

Regards

Matthias



-- 
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 #389] (Closed) modulate state

[bugtracker-admin]

Issue #389 has been updated by tuxillo.

Description updated
Category set to PF
Status changed from Feedback to Closed
Assignee set to bastyaelvtars

Although pf was updated, no feedback was provided.


Bug #389: modulate state
http://bugs.dragonflybsd.org/issues/389#change-14355

* Author: bastyaelvtars
* Status: Closed
* Priority: Normal
* Assignee: bastyaelvtars
* Category: PF
* Target version: 6.4

If I create a rule:
pass out quick on $iface proto tcp from any to any flags S/SA modulate state
the connections don't initiate. Replacing 'flags S/SA modulate state' to 
'keep state' salvages this.



-- 
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 #572] (Closed) Installer: no option to set geometry/corrupts partition table

[bugtracker-admin]

Issue #572 has been updated by tuxillo.

Description updated
Category set to installer
Status changed from In Progress to Closed
Assignee set to corecode
% Done changed from 0 to 100

Irrelevant as of today.


Bug #572: Installer: no option to set geometry/corrupts partition table
http://bugs.dragonflybsd.org/issues/572#change-14354

* Author: randux
* Status: Closed
* Priority: Normal
* Assignee: corecode
* Category: installer
* Target version: 6.4

Hi guys,

I installed the 1.8.0 release from the liveCD and it screwed up my 
partition table. How can I set the drive geometry so that the installer 
will use my c/h/s values instead of the (possibly incorrect) values said 
to be obtained from BIOS?

I noticed this problem in FreeBSD but it seems to have been mitigated by 
the installer offering a "G" option to set drive geometry around 6.1/6.2 
release, not sure exactly when.

I posted a question on the users list on Feb. 26 but hearing nothing 
(and wanting to install Dfly 1.8.0 release) I am posting here on bugs. 
Someone with a multiboot setup who doesn't track changes to his 
partition table can suffer loss of data because of this error. It could 
be a relatively serious problem, especially for newbies to multibooting 
as symptoms probably won't appear immediately, it will be difficult to 
diagnose.

Thanks,
Rand



-- 
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 #558] (Closed) ACPI and IRQ problems

[bugtracker-admin]

Issue #558 has been updated by tuxillo.

Description updated
Category set to Kernel
Status changed from Feedback to Closed
Assignee set to c.turner
% Done changed from 0 to 100

Ancient bug and no feedback was reported even tho it was stated there have been 
significant changes that could potentially fix the issues.


Bug #558: ACPI and IRQ problems
http://bugs.dragonflybsd.org/issues/558#change-14353

* Author: slynko
* Status: Closed
* Priority: Normal
* Assignee: c.turner
* Category: Kernel
* Target version: 6.4

Hi,

still have the same ACPI and IRQ problems on HEAD. ichsmb, cardbus and one usb
port doesn't work properly. Here is demsg messages below

Copyright (c) 2003, 2004, 2005, 2006, 2007 The DragonFly Project.
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
DragonFly 1.9.0-DEVELOPMENT #0: Wed Feb 14 15:34:06 MSK 2007
r...@elizabet.tronet.ru:/usr/obj/usr/src/sys/ELIZABET
TSC clock: 1690227876 Hz, i8254 clock: 1193179 Hz
CPU: Mobile Intel(R) Celeron(R) CPU 1.70GHz (1690.24-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf27  Stepping = 7
 
Features=0xbfebf9ff
  Features2=0x400
real memory  = 134217728 (131072K bytes)
avail memory = 122286080 (119420K bytes)
Preloaded elf kernel "/kernel" at 0xc056b000.
Preloaded elf module "/modules/vesa.ko" at 0xc056b288.
Preloaded elf module "/modules/if_ath.ko" at 0xc056b330.
ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
link_elf: symbol ieee80211_iterate_nodes undefined
link_elf_load_file: cannot load 'ath_rate' from filesystem this early
Preloaded elf module "/modules/wlan.ko" at 0xc056b3d8.
Preloaded elf module "/modules/snd_ich.ko" at 0xc056b5d4.
Preloaded elf module "/modules/sound.ko" at 0xc056b67c.
Preloaded elf module "/modules/usb.ko" at 0xc056b724.
Preloaded elf module "/modules/ums.ko" at 0xc056b7c8.
Preloaded elf module "/modules/radeon.ko" at 0xc056b86c.
Preloaded elf module "/modules/acpi.ko" at 0xc056b914.
netsmb_dev: loaded
Pentium Pro MTRR support enabled
md0: Malloc disk
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00fdf50
ACPI: RSDP @ 0x0xf7400/0x0014 (v  0 PTLTD )
ACPI: RSDT @ 0x0xfefa5dc/0x0030 (v  1   SONY   B0 0x20021203 PTL  
0x)
ACPI: FACP @ 0x0xfefee7d/0x0074 (v  1   SONY   B0 0x20021203 PTL  
0x0100)
ACPI: DSDT @ 0x0xfefa60c/0x4871 (v  1   SONY   B0 0x20021203 PTL  
0x010D)
ACPI: FACS @ 0x0xfefffc0/0x0040
ACPI: BOOT @ 0x0xfefeef1/0x0028 (v  1   SONY   B0 0x20021203 PTL  
0x0001)
ACPI: SSDT @ 0x0xfefef19/0x00E7 (v  1   SONY   B0 0x20021203 PTL  
0x0001)
npx0:  on motherboard
npx0: INT 16 interface
Using XMM optimized bcopy/copyin/copyout
acpi0:  on motherboard
Warning: ACPI is disabling APM's device.  You can't run both
can't fetch resources for \\_PR_.CPU0 - AE_TYPE
can't fetch resources for \\_TZ_.ATF0 - AE_TYPE
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
ACPI Error (evregion-0427): No handler for Region [ECR_] (0xc0c92578)
[EmbeddedControl] [20061109]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20061109]
ACPI Error (psparse-0638): Method parse/execution failed [\\_PR_.CPU0._CST]
(Node 0xc0c70b40), AE_NOT_EXIST
cpu0:  on acpi0
ACPI Error (evregion-0427): No handler for Region [ECR_] (0xc0c92578)
[EmbeddedControl] [20061109]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20061109]
ACPI Error (psparse-0638): Method parse/execution failed [\\_PR_.CPU0._CST]
(Node 0xc0c70b40), AE_NOT_EXIST
acpi_tz0:  on acpi0
acpi_lid0:  on acpi0
acpi_button0:  on acpi0
acpi_ec0:  port 0x66,0x62 on acpi0
acpi_cmbat0:  on acpi0
acpi_cmbat1:  on acpi0
acpi_acad0:  on acpi0
legacypci0 on motherboard
pcib0:  on legacypci0
pci0:  on pcib0
agp0:  mem 0xec00-0xefff at device 0.0
on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
drm0:  port 0x3000-0x30ff mem
0xe810-0xe810,0xf000-0xf7ff irq 9 at device 0.0 on pci1
info: [drm] AGP at 0xec00 64MB
info: [drm] Initialized radeon 1.8.0 20020828 on minor 0
uhci0:  port 0x1800-0x181f irq 9
at device 29.0 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: 2 ports with 2 removable, self powered
uhci1:  port 0x1820-0x183f irq 9
at device 29.1 on pci0
usb1:  on uhci1
usb1: USB revision 1.0
uhub1: 2 ports with 2 removable, self powered
intr 9 at 50001 > 5 hz, livelocked limit engaged!
ums0: Logitech USB RECEIVER, rev 1.10/25.10, addr 2, iclass 3/1
ums0: 16 buttons and Z dir.
uhci2:  port 0x1840-0x185f at
device 29.2 on pci0
uhci2: Could not allocate irq
device_probe_and_attach: uhci2 attach returned 6
pcib2:  at device 30.0 on pci0
pci2:  on pcib2
cbb0:  irq 3 at device 5.0 on pci2
cardbus0:  on cbb0
pccard0: <16-bit PCCard bus> on cbb0
cbb1:  at device 5.1 on pci2
cardbus1:  on cbb1
pccard1: 

[DragonFlyBSD - Bug #1864] (Closed) thr_umtx_wait: FAULT VALUE CHANGE X -> Y oncond 0x28340524

[bugtracker-admin]

Issue #1864 has been updated by tuxillo.

Description updated
Category set to Userland
Status changed from New to Closed
Assignee set to dillon
% Done changed from 0 to 100

The debugging message was removed in 
commit:696974900a518360ea4481af2e71d5f8a9628248


Bug #1864: thr_umtx_wait: FAULT VALUE CHANGE X -> Y oncond 0x28340524
http://bugs.dragonflybsd.org/issues/1864#change-14352

* Author: vsrinivas
* Status: Closed
* Priority: Normal
* Assignee: dillon
* Category: Userland
* Target version: 6.4

thr_umtx_wait: FAULT VALUE CHANGE 408 -> 409 oncond 0x28340524

or many variants thereof seem to be reported by a number of applications. This 
is 
reported by: 
http://grok.x12.su/source/xref/dragonfly/lib/libthread_xu/thread/thr_umtx.c#140,
 
inside _thr_umtx_wait.



-- 
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 #2519] (Closed) panic: assertion "_cache_lockstatus(ncp) == LK_EXCLUSIVE" failed

[bugtracker-admin]

Issue #2519 has been updated by tuxillo.

Description updated
Category set to Kernel
Status changed from In Progress to Closed
% Done changed from 0 to 100

Two fixes were made and no further reports of this problem.


Bug #2519: panic: assertion "_cache_lockstatus(ncp) == LK_EXCLUSIVE" failed
http://bugs.dragonflybsd.org/issues/2519#change-14351

* Author: ftigeot
* Status: Closed
* Priority: High
* Assignee: dillon
* Category: Kernel
* Target version: 6.4
* Start date: 2013-02-26

A 8-threads machine running a DragonFly 3.3 kernel as of 
055f352b3a3efb5048e8ec081c8bfe53db574e68
panics every few hours with the above assertion.

Complete panic string:
panic: assertion "_cache_lockstatus(ncp) == LK_EXCLUSIVE" failed in 
_cache_setvp at /usr/src/sys/kern/vfs_cache.c:1175

Core dumps are beeing uploaded to leaf:~ftigeot/crash.71



-- 
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 #2513] (Closed) Installer w/ UFS set subpartitions too big

[bugtracker-admin]

Issue #2513 has been updated by tuxillo.

Description updated
Category set to installer
Status changed from New to Closed
% Done changed from 0 to 100

No i386 anymore plus user reported success.


Bug #2513: Installer w/ UFS set subpartitions too big
http://bugs.dragonflybsd.org/issues/2513#change-14350

* Author: khindenburg
* Status: Closed
* Priority: Normal
* Assignee: swildner
* Category: installer
* Target version: 6.4
* Start date: 2013-02-17

Running Oracle VM VIrtualBox 4.2.6 on MacOSX + dfly-i386-3.2.2_REL.iso

Installing into entire disk + UFS + default sub-partitions - the following 
error popups (brevity):

The space allocated in subpartitions (13507) exceeds HD size (12355)

per IRC made bug report



-- 
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 #2505] (Closed) i386 buildkernel cc1: error: too many filenames given /usr/obj/usr/src/world_i386/usr/include: No such file or directory

[bugtracker-admin]

Issue #2505 has been updated by tuxillo.

Description updated
Category set to Userland
Status changed from In Progress to Closed
Assignee set to davshao

No i386 support anymore plus davshao reported success.


Bug #2505: i386  buildkernel cc1: error: too many filenames given 
/usr/obj/usr/src/world_i386/usr/include: No such file or directory
http://bugs.dragonflybsd.org/issues/2505#change-14348

* Author: davshao
* Status: Closed
* Priority: Normal
* Assignee: davshao
* Category: Userland
* Target version: 6.4
* Start date: 2013-02-03

On a i386 build updating from

commit e2a099cf1b1188b60aecc18de449444f7dca0f6a
Date:   Fri Feb 1 13:47:37 2013 -0800

kernel - Fix kernel panic caused by rename race

to

commit 6de060a4493ce25dda4287f3ab00041b698ba2b8
Date:   Sun Feb 3 13:32:01 2013 +0100

Unbreak world with NO_GCC44

with /etc/make.conf

CFLAGS+=-g
STRIP=


# make buildworld && make buildkernel

ends with an error:
===> bus/cam/cam
@ -> /usr/src/sys/bus/cam/cam/../../..
echo "#define SCSI_DELAY 15000" > opt_scsi.h
rm -f .depend
> .depend
mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I. -I@ 
-I/usr/obj/usr/src/sys/GENERIC -I/usr/obj/usr/src/sys/GENERIC/include 
-I@/../include -I/usr/obj/usr/src/world_i386/usr/include  -std=c99 -std=gnu99 
-std=c99  /usr/src/sys/bus/cam/cam/../cam.c 
/usr/src/sys/bus/cam/cam/../cam_periph.c 
/usr/src/sys/bus/cam/cam/../cam_queue.c /usr/src/sys/bus/cam/cam/../cam_sim.c 
/usr/src/sys/bus/cam/cam/../cam_xpt.c /usr/src/sys/bus/cam/cam/../cam_extend.c 
/usr/src/sys/bus/cam/cam/../scsi/scsi_all.c 
/usr/src/sys/bus/cam/cam/../scsi/scsi_cd.c 
/usr/src/sys/bus/cam/cam/../scsi/scsi_ch.c 
/usr/src/sys/bus/cam/cam/../scsi/scsi_da.c 
/usr/src/sys/bus/cam/cam/../scsi/scsi_pass.c 
/usr/src/sys/bus/cam/cam/../scsi/scsi_pt.c 
/usr/src/sys/bus/cam/cam/../scsi/scsi_sa.c 
/usr/src/sys/bus/cam/cam/../scsi/scsi_ses.c 
/usr/src/sys/bus/cam/cam/../scsi/scsi_targ_bh.c 
/usr/src/sys/bus/cam/cam/../scsi/scsi_target.c
cc1: error: too many filenames given.  Type cc1 --help for usage
cc1: fatal error: /usr/obj/usr/src/world_i386/usr/include: No such file or 
directory
compilation terminated.
cc1: error: too many filenames given.  Type cc1 --help for usage
cc1: fatal error: /usr/obj/usr/src/world_i386/usr/include: No such file or 
directory
compilation terminated.
cc1: error: too many filenames given.  Type cc1 --help for usage
cc1: fatal error: /usr/obj/usr/src/world_i386/usr/include: No such file or 
directory
compilation terminated.
cc1: error: too many filenames given.  Type cc1 --help for usage
cc1: fatal error: /usr/obj/usr/src/world_i386/usr/include: No such file or 
directory
compilation terminated.

...

cc1: fatal error: /usr/obj/usr/src/world_i386/usr/include: No such file or 
directory
compilation terminated.
mkdep: compile failed
*** Error code 1

Stop.
make: stopped in /usr/src/sys/bus/cam/cam
*** Error code 1

Stop.
make: stopped in /usr/src/sys/bus/cam
*** Error code 1

Stop.
make: stopped in /usr/src/sys/bus
*** Error code 1

Stop.
make: stopped in /usr/src/sys
*** Error code 1

Stop.
make: stopped in /usr/obj/usr/src/sys/GENERIC
*** Error code 1

Stop.
make: stopped in /usr/src
.CURDIR='/usr/src'
.OBJDIR='/usr/obj/usr/src'
.MAKE='make'
MAKE_VERSION='20121010'
LD_LIBRARY_PATH=''
MACHINE_ARCH='i386'
MACHINE='i386'
MAKEFILE='/usr/src/Makefile.inc1'
.TARGETS='buildkernel'
.ERROR_TARGET='buildkernel'
.ERROR_META_FILE=''
.MAKE.LEVEL='1'
.MAKE.MODE=''
*** Error code 1





-- 
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 #2402] (Closed) Showstopper panics for Release 3.2

[bugtracker-admin]

Issue #2402 has been updated by tuxillo.

Description updated
Category set to Other
Status changed from New to Closed
Assignee set to tuxillo

3.2 was released long ago.


Bug #2402: Showstopper panics for Release 3.2
http://bugs.dragonflybsd.org/issues/2402#change-14345

* Author: marino
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Category: Other
* Target version: 6.4
* Start date: 2012-08-15

This is the list of panics we've been accumulating.  It's particularly hard for 
i386 and UFS.
This is a good list of items to be fixed before next release.

#2296: panic: assertion "m->wire_count > 0" failed in pmap_unwire_pte at 
/usr/src/sys/platform/pc32/i386/pmap.c:1091
   core available (~marino/crash, ~thomas/crash
   (carried over from 3.0.1, 3.0.2, 3.0.3 showstopper lists)
#2364: panic: lockmgr: locking against myself
   core available (~marino/crash)
#2374: Panic where softdep_update_inodeblock() called bwrite() with a NULL 
buffer
   core available (~marino/crash) uploaded today
#2374: panic: flush_pagedep_deps: MKDIR_BODY
   core available (~marino/crash)
#2370: panic: ffs_valloc: dup alloc
   core available (~marino/crash)
#2350  panic: assertion "m->flags & PG_BUSY" failed in vm_page_protect at 
/usr/src/sys/vm/vm_page.h:532
   core available (~pavalos/crash)


Leftover from 3.0.3 showstopper:
#2353  panic: assertion "gd->gd_spinlocks_wr == 0" failed in bsd4_schedulerclock
   core available (~jaydg/crash)
#2388  panic: lockmgr: LK_RELEASE: no lock held
   No core.
#2399  Panic on lwkt_reltoken from vm_mmap
   core available (limited use)


Leftover from 3.0.1 showstopper:
#2284  panic: general protection fault (3.0 showstopper)
   core available on ylem/var/crash, request to put on leaf didn't happen 
(?)

Other panics:
#2352  panic: Bad link elm 0xffe0a3775670 next->prev != elm
   core available (~jaydg/crash)
#2369  panic: Bad link elm 0xffe07edf6068 next->prev != elm
   core available (~jaydg/crash)
#2355  panic: rtrequest1_msghandler: rtrequest table error was cpu4, err 17
   core available (~jaydg/crash)
#2083  panic: zone: entry not free
   core might be available
#2358  panic: hammer: insufficient undo FIFO space!
   NO CORE
#2345  panic: assertion "len <= nmp->nm_size" failed in nfs_writerpc_bio at 
   NO CORE
#2300  EHCI module unload panic
   Supposed core availble on request




-- 
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 #2410] (Closed) Placeholder for Bug Notes by Varialus

[bugtracker-admin]

Issue #2410 has been updated by tuxillo.

Description updated
Category set to Other
Status changed from New to Closed
Assignee set to tuxillo
% Done changed from 0 to 100

Enought time given :)


Bug #2410: Placeholder for Bug Notes by Varialus
http://bugs.dragonflybsd.org/issues/2410#change-14344

* Author: varialus
* Status: Closed
* Priority: Low
* Assignee: tuxillo
* Category: Other
* Target version: 6.4
* Start date: 2012-08-25

Please leave this issue open. It takes me a while to get bugs properly logged, 
but in the mean time I want the bug tracker to contain a reference to my list 
of outstanding issues and workarounds. Thanks!

http://www.dragonflybsd.org/varialus/



-- 
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 #2372] (Closed) segfault correct detection failure

[bugtracker-admin]

Issue #2372 has been updated by tuxillo.

Description updated
Category set to Other
Status changed from New to Closed
Assignee set to tuxillo

We no longer use pkgsrc but in dports we got:


$ sudo make -DBATCH test
===>  Testing for libsigsegv-2.14
Making check in src
Making check in tests
/usr/bin/make  check-TESTS
PASS: test-catch-segv1
PASS: test-catch-segv2
PASS: test-segv-dispatcher1
PASS: test-catch-stackoverflow1
PASS: test-catch-stackoverflow2

Testsuite summary for libsigsegv 2.14

# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Please send the following summary line via email to the main author
Bruno Haible  for inclusion into the list of
successfully tested platforms (see PORTING file).

libsigsegv: x86_64-portbld-dragonfly6.3 | yes | yes | 2.14

Then please type 'make install' to install the package.





Bug #2372: segfault correct detection failure
http://bugs.dragonflybsd.org/issues/2372#change-14343

* Author: marino
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Category: Other
* Target version: 6.4
* Start date: 2012-05-20

The package devel/libsigsegv fails its final diagnostic test on DragonFly.
For information, this does pass on FreeBSD 9.

To repeat:
> cd /usr/pkgsrc/devel/libsigsegv
> bmake
> cd ${WRKOBJDIR}/devel/libsigsegv/work/libsigsegv-2.10/
> gmake check

The output of the fifth test (out of five) should be:
| Starting recursion pass 1.
| Stack overflow 1 caught.
| Starting recursion pass 2.
| Stack overflow 2 caught.
| Segmentation violation correctly detected.
| Segmentation violation correctly detected.
| Test passed.
| PASS: stackoverflow2

The actual output is:
| Starting recursion pass 1.
| Stack overflow 1 caught.
| Starting recursion pass 2.
| Stack overflow 2 caught.
| Segmentation violation misdetected as stack overflow.
| Test passed.
| FAIL: stackoverflow2

The code of the test is here: 
http://fossies.org/dox/libsigsegv-2.10/stackoverflow2_8c_source.html

What seems to be happening is that when the stack is exhausted, accessing an 
illegal memory location triggers the stack overflow handler before the sigsegv 
handler.  I think it's a DragonFly bug.



-- 
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 #2204] (Closed) -Wl,--warn-common warnings

[bugtracker-admin]

Issue #2204 has been updated by tuxillo.

Description updated
Category set to Userland
Status changed from New to Closed
Assignee set to marino
% Done changed from 0 to 100

This was dealt with in:

commit:d66febebfcbe87509f4e19c8e51cc6a3a490996a
commit:a0ba0189b9089fb6630d9e0244b373af683cbe9c


Bug #2204: -Wl,--warn-common warnings
http://bugs.dragonflybsd.org/issues/2204#change-14342

* Author: sepherosa
* Status: Closed
* Priority: Normal
* Assignee: marino
* Category: Userland
* Target version: 6.4

I get following warning when linking programs w/ -W,--warn-common

/usr/lib/libc.so: warning: multiple common of `environ'
/usr/lib/crt1.o: warning: previous common is here

v2.13.0.285.g8db21-DEVELOPMENT

World is at the save git version as kernel

Best Regards,
sephe

-- 
Tomorrow Will Never Die



-- 
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 #2360] Wishlist: virtio driver import

[bugtracker-admin]

Issue #2360 has been updated by tuxillo.

Description updated
Category set to Feature request

None of the links in the description are available anymore.


Bug #2360: Wishlist: virtio driver import
http://bugs.dragonflybsd.org/issues/2360#change-14341

* Author: vsrinivas
* Status: In Progress
* Priority: Normal
* Category: Feature request
* Target version: 6.4
* Start date: 2012-05-02

Tim Bisson ported the FreeBSD virtio-bhyve drivers to DragonFly 
(https://github.com/bissont/virtio_bhyve). It'd be nice if we could import them 
into DragonFly. 

Status ===
I have started working on integration in the 'virtual' branch of my DragonFly 
tree:

https://github.com/vsrinivas/DragonFlyBSD/commits/virtual 

Todo:
x   1. Move drivers into appropriate location in source tree + rewrite makefiles




-- 
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 #2309] (Closed) Catch all ticket for Bugtracker problems

[bugtracker-admin]

Issue #2309 has been updated by tuxillo.

Description updated
Category set to Bugtracker
Status changed from New to Closed
% Done changed from 0 to 100


Bug #2309: Catch all ticket for Bugtracker problems
http://bugs.dragonflybsd.org/issues/2309#change-14340

* Author: tuxillo
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Category: Bugtracker
* Target version: 6.4
* Start date: 2012-02-19

Please register in this ticket every problem you encounter in the bugtracker.




-- 
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 #2333] (Closed) submit and this site are silently tied together

[bugtracker-admin]

Issue #2333 has been updated by tuxillo.

Status changed from Feedback to Closed

Back then when we had this, it was desirable to have submit@ opened, but since 
then we have had to even close the bugtracker registration process because of 
the spam.

I've verified that unknown users can't send mail, which is the desirable 
behavior now:


App 155841 output: MailHandler: ignoring email from unknown user 
[tuxi...@x.xxx]
App 155841 output: Completed 422 Unprocessable Entity in 9ms (ActiveRecord: 
3.2ms)


Closing this one.


Bug #2333: submit and this site are silently tied together
http://bugs.dragonflybsd.org/issues/2333#change-14339

* Author: justin
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Category: Bugtracker
* Target version: 6.4
* Start date: 2012-03-21

You apparently have to register on bugs.dragonflybsd.org before sending a 
successful email to sub...@dragonflybsd.org.  Submit@ should be open.

http://gitweb.dragonflybsd.org/ikiwiki.git/commitdiff/f89ae0997d3752212dbeb7c73b727ec6826c6ba0



-- 
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 #3028] (In Progress) installer: confusion of set/get disk encryption passphrase dialogs

[bugtracker-admin]

Issue #3028 has been updated by tuxillo.

File fn_get_passphrase.patch added
Status changed from New to In Progress
Assignee set to tuxillo

Maybe something like this would work? (Untested!!)


Bug #3028: installer: confusion of set/get disk encryption passphrase dialogs
http://bugs.dragonflybsd.org/issues/3028#change-14337

* Author: liweitianux
* Status: In Progress
* Priority: Normal
* Assignee: tuxillo
* Category: Other
* Target version: 6.4
* Start date: 2017-04-14

Currently, the *installer* uses the *same* dialog to "set" and "get" the 
passphrase for disk encryption, which causes some confusion, as well as a bit 
inconvenience.

The followings are the 2 cases to come across the confusing "get" passphrase 
dialog:

1. installation finished, begins to configure the system, which will ask the 
disk encryption passphrase;
2. boot into the LiveCD, and use it to "Configure an installed System" (see 
attached screenshots).

The corresponding code is at 
"usr.sbin/installer/dfuibe_installer/fn_configure.c" with the function 
"fn_get_passphrase()".  It may be better to create separate functions for the 
"set" and "get" passphrase dialogs, respectively.


Cheers,
Aly


---Files
dfly_4.8_encryption_passphrase.png (18.4 KB)
fn_get_passphrase.patch (5.56 KB)


-- 
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 #3017] (Closed) sbin/ipfw3/ipfw3.c:2519: redundant compare ?

[bugtracker-admin]

Issue #3017 has been updated by tuxillo.

Status changed from New to Closed
Assignee set to bycn82

Fixed in commit:992b3001a225605640debab1be6feab6e367bb5e


Bug #3017: sbin/ipfw3/ipfw3.c:2519: redundant compare ?
http://bugs.dragonflybsd.org/issues/3017#change-14336

* Author: dcb
* Status: Closed
* Priority: Normal
* Assignee: bycn82
* Target version: 6.4
* Start date: 2017-04-11

dragonfly/sbin/ipfw3/ipfw3.c:2519] -> [dragonfly/sbin/ipfw3/ipfw3.c:2519]: 
(style) Same expression on both sides of '||'.

if (!strncmp(*av, "show", strlen(*av)) ||
!strncmp(*av, "show", strlen(*av))) {




-- 
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 #3016] (Closed) sbin/hammer2/cmd_snapshot.c:113]: (error) Memory leak: xname

[bugtracker-admin]

Issue #3016 has been updated by tuxillo.

Status changed from New to Closed
Assignee set to tuxillo

It was removed in commit:f8a108fb1b0a6a6f4cd533e9fa0b110ef124160d


Bug #3016: sbin/hammer2/cmd_snapshot.c:113]: (error) Memory leak: xname
http://bugs.dragonflybsd.org/issues/3016#change-14335

* Author: dcb
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4
* Start date: 2017-04-11


$ fgrep xname dragonfly/sbin/hammer2/cmd_snapshot.c
char *xname;
xname = strdup("");
asprintf(, ".%s", strrchr(path, '/') + 1);
asprintf(, ".%s", path);
xname = strdup("");
 xname,
$


I don't see anywhere that xname is freed. Maybe this would be a good idea ?




-- 
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 #2982] (Closed) Failed compile due to fetch.h and MAXHOSTNAMELEN

[bugtracker-admin]

Issue #2982 has been updated by tuxillo.

Status changed from New to Closed
Assignee set to tuxillo

Just include @sys/param.h@ before including fetch.h, as you yourself mentioned 
:)
Closing this one!


Bug #2982: Failed compile due to fetch.h and MAXHOSTNAMELEN
http://bugs.dragonflybsd.org/issues/2982#change-14333

* Author: noloader
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4
* Start date: 2017-02-19

I'm trying to build pkgin for DragonFly. The compile is failing due to fetch.h 
and MAXHOSTNAMELEN (http://github.com/NetBSDfr/pkgin/issues/74):


$ make
gcc  -O -pipe-std=gnu99  -c main.c
In file included from pkgin.h:45:0,
 from main.c:33:
/usr/include/fetch.h:44:14: error: 'MAXHOSTNAMELEN' undeclared here (not in a 
function)
  char   host[MAXHOSTNAMELEN+1];
  ^
/usr/include/fetch.h:59:14: error: 'PATH_MAX' undeclared here (not in a 
function)
  char   name[PATH_MAX];
  ^



Looking at /usr/include/fetch.h, it does not include a header which defines 
MAXHOSTNAMELEN; and it does not define MAXHOSTNAMELEN itself:


$ cat fetch.h
...

#ifndef _FETCH_H_INCLUDED
#define _FETCH_H_INCLUDED

#define _LIBFETCH_VER "libfetch/2.0"

#define URL_SCHEMELEN 16
#define URL_USERLEN 256
#define URL_PWDLEN 256

struct url {
char scheme[URL_SCHEMELEN+1];
char user[URL_USERLEN+1];
char pwd[URL_PWDLEN+1];
char host[MAXHOSTNAMELEN+1];
int  port;
char*doc;
off_toffset;
size_t   length;
time_t   ims_time;
};
...



MAXHOSTNAMELEN is defined to 256 is a couple of other header files, but those 
headers are not picked up in fetch.h.

Looking at gethostname(3) (http://man.openbsd.org/gethostname.3), I can't tell 
if fetch.h is supposed to include  or . I'm guessing 
 would be a good choice.



-- 
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 #1476] (Closed) We miss fdatasync()

[bugtracker-admin]

Issue #1476 has been updated by tuxillo.

Category set to VFS subsystem
Status changed from In Progress to Closed
Assignee set to tkusumi

Added back in commit:74fa2560ac77f9db4a34b2a7c72450126fec4ed6


Bug #1476: We miss fdatasync()
http://bugs.dragonflybsd.org/issues/1476#change-14331

* Author: hasso
* Status: Closed
* Priority: Low
* Assignee: tkusumi
* Category: VFS subsystem
* Target version: 6.4

http://www.opengroup.org/onlinepubs/9699919799/functions/fdatasync.html



-- 
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 #3313] Can't boot from my live USB at all. The kernel loading process hangs.

[bugtracker-admin]

Το θέμα #3313 ενημερώθηκε από τον rempas.


daftaupe wrote in #note-1:
> Hello,
> 
> I'm usually creating the bootable medium with the following command. Please 
> make sure to use the .img file, not the iso if you are using a USB stick.
> In the following line, /dev/yourusbstick is to be determined when you insert 
> your USB stick, it can be usually determined by taking a look at the dmesg, 
> probably sd_ on Linux and da_ on FreeBSD for example.
> 
> [...]
> 
> I did it again last night and ended it up with a working bootable medium. I'd 
> say there's an issue with your method as /dev/mapper/ventoy appear in the log 
> file you uploaded.

Thank you for the info! I wanted to relpy earlier but I had some problems with 
log-in to my account and now I remembered about this and I went back and fixed 
them.
So, thank you for the reply after all these months, I decided that I'll wait 
for DragonFlyBSD to work with Ventoy (and if it ever does) or with a similar 
program. Having to
burn then format and only be allowed to use one ISO at a time is a no-go for me 
in 2022. Thanks for your time and I hope you understand. Good luck with your 
work on
DragonFlyBSD and I hope you can attract more people as the project seems to be 
the most promising OS project out there!


Bug #3313: Can't boot from my live USB at all. The kernel loading process hangs.
http://bugs.dragonflybsd.org/issues/3313#change-14330

* Συγγραφέας: rempas
* Κατάσταση: New
* Προτεραιότητα: Normal
* Στόχος έκδοσης: 6.4
* Εκκίνηση: 2022-02-12

Hello! I'm trying to install DargonFlyBSD on my hard drive (never installed in 
hardware before). And I'm facing some problems.

I have tried to create a bootable USB two ways. The first one is the classic 
"image burn" using "gnome-disks".
The second way and the one I'm more interested and would like to solve is using 
Ventoy (https://github.com/ventoy/Ventoy).

In both cases, I tried to boot from the USB and when it will try to load the 
kernel like it normally does, it will hang at some point.
I tried with the latest stable version of DragonFlyBSD (6.2.1) and the latest 
version of Ventoy (1.0.65). I will provide an image with
the latest info before the kernel loading process hangs.

Thanks and if you need more info, let me know!

---Αρχεία---
DragonFlyBSD_INSTALL_ERROR.jpg (3.74 MB)


-- 
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 #2304] (Closed) DFBSD v3.1.0.32.g4d37d - assertion "p" failed in in_pcbbind

[bugtracker-admin]

Issue #2304 has been updated by tuxillo.

Description updated
Status changed from Feedback to Closed
Assignee set to tuxillo

No feedback at the time, also we don't support i386 anymore.


Bug #2304: DFBSD v3.1.0.32.g4d37d - assertion "p" failed in in_pcbbind
http://bugs.dragonflybsd.org/issues/2304#change-14326

* Author: tuxillo
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4
* Start date: 2012-02-11

Hi,

Got the following panic on i386 after few days of uptime:

panic: assertion "p" failed in in_pcbbind at 
/home/source/dfbsd/sys/netinet/in_pcb.c:300
cpuid = 0
Trace beginning at frame 0xd6234c8c
panic(,0,c0706c58,d6234cc0,c0d69480) at panic+0x19e 0xc038d6a3
panic(c0706c58,c06e7e66,c06b2835,c073d438,12c) at panic+0x19e 0xc038d6a3
in_pcbbind(c5c11ce0,0,d6f40058,e0d,c0d46688) at in_pcbbind+0x60 0xc047e588
udp_send(da63ea18,0,c0d69480,c08220a0,d6234da0) at udp_send+0xf8 0xc0495b48
netmsg_service_loop(0,0,0,0,0) at netmsg_service_loop+0x73 0xc043ba2b
lwkt_exit() at lwkt_exit 0xc0399c5f
boot() called on cpu#0
Uptime: 18d20h10m59s
Physical memory: 2000 MB
Dumping 500 MB: 485 469 453 437 421 405 389 373 357 341 325 309 293 277 261 245 
229 213 197 181 165 149 133 117 101
85 69 53 37 21 5




#1  md_dumpsys (di=0xc0ce5fc0) at 
/home/source/dfbsd/sys/platform/pc32/i386/dump_machdep.c:264
#2  0xc038ce58 in dumpsys () at /home/source/dfbsd/sys/kern/kern_shutdown.c:925
#3  0xc038d46e in boot (howto=) at 
/home/source/dfbsd/sys/kern/kern_shutdown.c:387
#4  0xc038d6d7 in panic (fmt=0xc0706c58 "assertion \"%s\" failed in %s at 
%s:%u") at /home/source/dfbsd/sys/kern/kern_shutdown.c:831
#5  0xc047e588 in in_pcbbind (inp=0xc5c11ce0, nam=0x0, td=0xd6f40058) at 
/home/source/dfbsd/sys/netinet/in_pcb.c:300
#6  0xc0495b48 in udp_output (flags=, td=, 
dstaddr=, m=, inp=) at 
/home/source/dfbsd/sys/netinet/udp_usrreq.c:804
#7  udp_send (msg=0xda63ea18) at 
/home/source/dfbsd/sys/netinet/udp_usrreq.c:1261
#8  0xc043ba2b in netmsg_service_loop (arg=0x0) at 
/home/source/dfbsd/sys/net/netisr.c:307
#9  0xc0399c5f in lwkt_deschedule_self (td=Cannot access memory at address 0x8
) at /home/source/dfbsd/sys/kern/lwkt_thread.c:362


I have the core dump available on demand.

Cheers,
Antonio Huete



-- 
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 #1954] (Closed) installer creates /tmp/ as HAMMER pfs instead of tmpfs

[bugtracker-admin]

Issue #1954 has been updated by tuxillo.

Status changed from Feedback to Closed
Assignee set to tuxillo

As of commit:f9602a12d5f0345feed0941d0b9e3b4e1816a411, /tmp is tmpfs.


Bug #1954: installer creates /tmp/ as HAMMER pfs instead of tmpfs
http://bugs.dragonflybsd.org/issues/1954#change-14325

* Author: pavalos
* Status: Closed
* Priority: Low
* Assignee: tuxillo
* Target version: 6.4

Shouldn't we default to having /tmp/ as tmpfs instead of HAMMER?



-- 
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 #2273] (Closed) UFS panic on vkernel i386

[bugtracker-admin]

Issue #2273 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee set to tuxillo

No vkernel and no i386 support anymore.


Bug #2273: UFS panic on vkernel i386
http://bugs.dragonflybsd.org/issues/2273#change-14324

* Author: tuxillo
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4
* Start date: 2012-01-11

Hi,

While checking out pkgsrc repo with cvs, I hit this panic. It's a 10GB UFS 
filesystem, vkernel was SMP i386.

cvs checkout: Updating pkgsrc/multimedia/gst-plugins0.8-ogg
cvs checkout: Updating pkgsrc/multimedia/gst-plugins0.8-theora
cvs checkout: Updating pkgsrc/multimedia/gst-plugins0.8-xvid
mode = 041777, inum = 5, fs =
panic: ffs_valloc: dup alloc
cpuid = 0
Trace beginning at frame 0x585d3818
panic(,0,82f28ac,585d384c,5505b458) at 0x80ed57d
panic(82f28ac,43ff,5,507850d4,585d3a00) at 0x80ed57d
ffs_valloc(582993e0,41ed,54bcc330,585d3a00,508b7910) at 0x821b456
ufs_vnoperatespec(585d3a28,585d3a58,8160a81,585d3a28,8323a28) at 0x822f906
ufs_vnoperate(585d3a28,8323a28,5508cc08,5508cc08,81542fc) at 0x822e8a6
vop_old_mkdir(5508cc08,582993e0,585d3bd8,585d3a7c,585d3b2c) at 0x8160a81
vop_compat_nmkdir(585d3acc,585d3ac0,822e8a6,585d3acc,585d3b00) at 0x8149658
vop_defaultop(585d3acc,585d3b00,815fa95,585d3acc,8323b00) at 0x8147fe2
ufs_vnoperate(585d3acc,8323b00,5508cc08,575cd4b0,282e) at 0x822e8a6
vop_nmkdir(5508cc08,585d3c00,582993e0,585d3bd8,54bcc330) at 0x815fa95
kern_mkdir(585d3c00,1ff,0,0,5893b3c0) at 0x8158f67
sys_mkdir(585d3c7c,585d3c8c,8,585d3c8c,80f82b1) at 0x8159041
syscall2(585d3d40,4040,585d3cf0,10918ae9,0) at 0x82aace5
user_trap(585d3d40,1,585d3d40,5505b688,2847c360) at 0x82aaf59
go_user(585d3d38,0,0,7b,0) at 0x82ab457
Debugger("panic")

CPU0 stopping CPUs: 0x0002
 stopped
Stopped at  0x82a8226:  movb$0,0x84da794



-- 
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 #2079] (Closed) DFBSD v2.11.0.179.gc4383 - Panic upon tap removing

[bugtracker-admin]

Issue #2079 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee changed from 0 to tuxillo

tap(4) was reworked not long ago and removing tap devices does not crash.


Bug #2079: DFBSD v2.11.0.179.gc4383 - Panic upon tap removing
http://bugs.dragonflybsd.org/issues/2079#change-14320

* Author: tuxillo
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4

Hi,

Playing around with vknet(1) where some tap devices were created, I destroy one
of them with 'ifconfig tap0 destroy' and after some time I got the panic below.
I don't have a way to reproduce it yet, but I got a dump.

The core.txt file is here:
http://leaf.dragonflybsd.org/~tuxillo/archive/temp/core_ifq.6.txt

I will upload the core to leaf by request.

Cheers,
Antonio Huete



-- 
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 #2040] (Closed) kernel selection on installer cd is broken

[bugtracker-admin]

Issue #2040 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee changed from 0 to tuxillo

We no longer are able to select from UP or SMP kernels.




Bug #2040: kernel selection on installer cd is broken
http://bugs.dragonflybsd.org/issues/2040#change-14318

* Author: ftigeot
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4

The fred menu on the installer cd has two choices to select a smp or up kernel,
entries 'u' and 'm'

If one of these choices is selected, the lowest part of the screen is blanked
and a new fred menu appears, restarting the countdown to boot from the 
beginning.

Parts of the old fred menu are left in the top of the screen.

I have been told the kernel selection is really occuring, but the absence of any
meaningful message and the screen corruption lead to think the menu program has
crashed



-- 
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 #2034] (Closed) assertion: z->z_Magic == ZALLOC_SLAB_MAGIC in _slabfree

[bugtracker-admin]

Issue #2034 has been updated by tuxillo.

Status changed from New to Closed
Assignee set to tuxillo

We no longer use pkgsrc. Also, invoking vlc or tinyproxy does not trigger this 
anymore.


Bug #2034: assertion: z->z_Magic == ZALLOC_SLAB_MAGIC in _slabfree
http://bugs.dragonflybsd.org/issues/2034#change-14316

* Author: pavalos
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4

I'm receiving the following assertion when running vlc and tinyproxy:

assertion: z->z_Magic == ZALLOC_SLAB_MAGIC in _slabfree

My vlc was compiled with gcc 4.1.2, and my world is gcc 4.4.  vlc hits
this assertion very early, and only runs for a second or so.  Here's the
backtrace:


(gdb) bt
#0  0x2820efbf in kill () at kill.S:2
#1  0x281a1fcc in _raise (sig=6) at 
/usr/src/lib/libthread_xu/thread/thr_syscalls.c:438
#2  0x2828a88e in abort () at /usr/src/lib/libc/../libc/stdlib/abort.c:63
#3  0x2821ac39 in _mpanic (ctl=0x28290918 "assertion: %s in %s") at 
/usr/src/lib/libc/../libc/stdlib/nmalloc.c:1715
#4  0x2821b875 in _slabfree (ptr=, flags=, rbigp=0x0) at /usr/src/lib/libc/../libc/stdlib/nmalloc.c:1165
#5  0x2821bd7b in free (ptr=0x2abca1bc) at 
/usr/src/lib/libc/../libc/stdlib/nmalloc.c:774
#6  0x2ac85455 in operator delete (ptr=0x0)
at 
/usr/src/gnu/lib/gcc44/libstdc++/../../../usr.bin/cc44/cc_tools/../../../../contrib/gcc-4.4/libstdc++-v3/libsupc++/del_op.cc:44
#7  0x2ac19385 in __gnu_cxx::new_allocator::deallocate (this=0x2abca1bc, 
__a=...) at 
/usr/obj/usr/src/world_i386/usr/include/c++/4.4/ext/new_allocator.h:95
#8  std::basic_string, 
std::allocator >::_Rep::_M_destroy (this=0x2abca1bc, __a=...)
at /usr/obj/usr/src/world_i386/usr/include/c++/4.4/bits/basic_string.tcc:427
#9  0x2ac1ad87 in std::basic_string, 
std::allocator >::_Rep::_M_dispose (this=0x28346dd4, __res=5)
at /usr/obj/usr/src/world_i386/usr/include/c++/4.4/bits/basic_string.h:231
#10 std::basic_string, 
std::allocator >::reserve (this=0x28346dd4, __res=5)
at /usr/obj/usr/src/world_i386/usr/include/c++/4.4/bits/basic_string.tcc:489
#11 0x2ac1ae77 in std::basic_string, 
std::allocator >::append (this=0x28346dd4, __n=5, __c=0 L'\000')
at /usr/obj/usr/src/world_i386/usr/include/c++/4.4/bits/basic_string.tcc:289
#12 0x2ab3cd30 in std::basic_string, 
std::allocator >::resize (this=0x0, __n=5, __c=0 L'\000')
at /usr/obj/usr/src/world_i386/usr/include/c++/4.1/bits/basic_string.tcc:626
#13 0x2b2ff85c in TagLib::String::String(char const*, TagLib::String::Type) () 
from /usr/pkg/lib/libtag.so.1
#14 0x2b2ebb3a in __static_initialization_and_destruction_0 () from 
/usr/pkg/lib/libtag.so.1
#15 0x2b31b300 in __do_global_ctors_aux () from /usr/pkg/lib/libtag.so.1
#16 0x2b2d014a in _init () from /usr/pkg/lib/libtag.so.1
#17 0x2805289f in objlist_call_init (list=) at 
/usr/src/libexec/rtld-elf/rtld.c:1498
#18 0x280544bc in dlopen (name=0x283a0600 
"/usr/pkg/lib/vlc/plugins/meta_engine/libtaglib_plugin.so", mode=2) at 
/usr/src/libexec/rtld-elf/rtld.c:1865
#19 0x2813d3d9 in ?? () from /usr/pkg/lib/libvlccore.so.4
#20 0x283a0600 in ?? ()
#21 0x0002 in ?? ()
#22 0x in ?? ()
Current language:  auto
The current source language is "auto; currently asm".




I can't tell if this is a libstdc++, gcc44, or a nmalloc bug.

When I attempt to compile a new version of vlc from pkgsrc, it fails
hitting the same assertion when running lt-vlc-cache-gen as part of the
build process.  This also happens with gcc41.  The backtrace looks
similar:


(gdb) bt
#0  0x2820dfbf in kill () at kill.S:2
#1  0x2818cfcc in _raise (sig=6) at 
/usr/src/lib/libthread_xu/thread/thr_syscalls.c:438
#2  0x2828988e in abort () at /usr/src/lib/libc/../libc/stdlib/abort.c:63
#3  0x28219c39 in _mpanic (ctl=0x2828f918 "assertion: %s in %s") at 
/usr/src/lib/libc/../libc/stdlib/nmalloc.c:1715
#4  0x2821a875 in _slabfree (ptr=, flags=, rbigp=0x0) at /usr/src/lib/libc/../libc/stdlib/nmalloc.c:1165
#5  0x2821ad7b in free (ptr=0x2abd81bc) at 
/usr/src/lib/libc/../libc/stdlib/nmalloc.c:774
#6  0x2ac93455 in operator delete (ptr=0x0)
at 
/usr/src/gnu/lib/gcc44/libstdc++/../../../usr.bin/cc44/cc_tools/../../../../contrib/gcc-4.4/libstdc++-v3/libsupc++/del_op.cc:44
#7  0x2ac27385 in __gnu_cxx::new_allocator::deallocate (this=0x2abd81bc, 
__a=...) at 
/usr/obj/usr/src/world_i386/usr/include/c++/4.4/ext/new_allocator.h:95
#8  std::basic_string, 
std::allocator >::_Rep::_M_destroy (this=0x2abd81bc, __a=...)
at /usr/obj/usr/src/world_i386/usr/include/c++/4.4/bits/basic_string.tcc:427
#9  0x2ac28d87 in std::basic_string, 
std::allocator >::_Rep::_M_dispose (this=0x28346d94, __res=5)
at /usr/obj/usr/src/world_i386/usr/include/c++/4.4/bits/basic_string.h:231
#10 std::basic_string, 
std::allocator >::reserve (this=0x28346d94, __res=5)
at /usr/obj/usr/src/world_i386/usr/include/c++/4.4/bits/basic_string.tcc:489
#11 0x2ac28e77 in std::basic_string, 
std::allocator >::append 

[DragonFlyBSD - Bug #243] (Feedback) weird behavior in the shell

[bugtracker-admin]

Issue #243 has been updated by tuxillo.

Description updated
Status changed from New to Feedback
Assignee deleted (0)

In linux, tcsh:


debian:~# .
/usr/bin/.: Permission denied.


Any other shell I've tried other than csh does not show this behavior. Can this 
be closed?


Bug #243: weird behavior in the shell
http://bugs.dragonflybsd.org/issues/243#change-14314

* Author: swildner
* Status: Feedback
* Priority: Normal
* Target version: 6.4

Hi,

I'm not sure if this is a 'real' bug but I'm curious if anyone knows the 
cause. Check this:

zoot# echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/pkg/xorg/bin:/home/s/bin
zoot# pwd
/usr/src/sys/dev/disk/md
zoot# .
/usr/sbin/.: Permission denied.
zoot# cd /
zoot# .
/usr/sbin/.: Permission denied.

In other words: The strange thing is that whereever I type . on the csh 
prompt, I get the /usr/sbin/.: message regardless of what my current 
directory is.

On a Solaris system I get ".: Permission denied." which is what I'd 
expect rather.

So, can anyone enlighten me why DragonFly behaves like that?

Sascha



-- 
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 #1989] (Closed) Panic on reboot, DFly 2.8.2

[bugtracker-admin]

Issue #1989 has been updated by tuxillo.

Status changed from New to Closed
Assignee set to tuxillo

It is stated it was solved at the time.


Bug #1989: Panic on reboot, DFly 2.8.2
http://bugs.dragonflybsd.org/issues/1989#change-14313

* Author: dl
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4

Hi!

I have had my DFly [1] server running for almost 2 months, and after 
trying to reboot it, it panicked:

I let the memory dump to hd and ran kgdb:


root@pick:/var/crash# kgdb kern.2 vmcore.2
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

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-dragonfly".
For bug reporting instructions, please see:
...
Reading symbols from /var/crash/kern.2...done.

Unread portion of the kernel message buffer:

Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/ahci.ko...done.
Loaded symbols for /boot/kernel/ahci.ko
Reading symbols from /boot/kernel/ehci.ko...done.
Loaded symbols for /boot/kernel/ehci.ko
_get_mycpu (di=0x808d4a20) at ./machine/thread.h:73
73  __asm ("movq %%gs:globaldata,%0" : "=r" (gd) : "m"(__mycpu__dummy));
(kgdb) bt
#0  _get_mycpu (di=0x808d4a20) at ./machine/thread.h:73
#1  md_dumpsys (di=0x808d4a20)
 at /usr/src/sys/platform/pc64/x86_64/dump_machdep.c:262
#2  0x80363d26 in dumpsys () at 
/usr/src/sys/kern/kern_shutdown.c:881
#3  0x80364415 in boot (howto=-2004318071)
 at /usr/src/sys/kern/kern_shutdown.c:388
#4  0x803647e6 in panic (fmt=0x806287d4 "from debugger")
 at /usr/src/sys/kern/kern_shutdown.c:787
#5  0x801920d5 in db_panic (addr=, 
have_addr=0, count=0, modif=0x0) at /usr/src/sys/ddb/db_command.c:448
#6  0x8019278b in db_command () at /usr/src/sys/ddb/db_command.c:344
#7  db_command_loop () at /usr/src/sys/ddb/db_command.c:470
#8  0x80195551 in db_trap (type=,
 code=) at /usr/src/sys/ddb/db_trap.c:71
#9  0x805f39a0 in kdb_trap (type=3, code=0, regs=0xffe07cc6a6b8)
 at /usr/src/sys/platform/pc64/x86_64/db_interface.c:176
#10 0x805f9591 in trap (frame=0xffe07cc6a6b8)
 at /usr/src/sys/platform/pc64/x86_64/trap.c:706
#11 0x805f1f5e in calltrap ()
 at /usr/src/sys/platform/pc64/x86_64/exception.S:180
#12 0x805f3835 in breakpoint (msg=)
 at ./cpu/cpufunc.h:73
#13 Debugger (msg=)
4/db_interface.c:359
#14 0x803647df in panic (fmt=0x8061d2aa "assertion: %s 
in %s")
 at /usr/src/sys/kern/kern_shutdown.c:785
#15 0x80356288 in lf_destroy_range (range=)
 at /usr/src/sys/kern/kern_lockf.c:857
#16 0x80357052 in lf_setlock (lock=0xffe07bbe3240,
 owner=0xffe07b34b068, type=2, flags=, 
start=0, end=9223372036854775807) at /usr/src/sys/kern/kern_lockf.c:747
#17 0x8035728a in lf_advlock (ap=0xffe07cc6a9c8,
 lock=0xffe07bbe3240, size=)
 at /usr/src/sys/kern/kern_lockf.c:263
#18 0x80559c84 in hammer_vop_advlock (ap=0x809798b8)
 at /usr/src/sys/vfs/hammer/hammer_vnops.c:847
#19 0x803e1582 in vop_advlock (ops=0xffe0534277c0, vp=0x780,
 id=0x1 , op=0, fl=0x0, flags=-2137548576)
 at /usr/src/sys/kern/vfs_vopops.c:909
#20 0x80346fb4 in fdrop (fp=0xffe07b34b068)
 at /usr/src/sys/kern/kern_descrip.c:2418
#21 0x803472dd in closef (fp=0xffe07b34b068, 
p=0xffe052640070)
 at /usr/src/sys/kern/kern_descrip.c:2362
#22 0x80349c99 in kern_close (fd=3)
 at /usr/src/sys/kern/kern_descrip.c:857
#23 0x80349dac iat /usr/src/sys/kern/kern_descrip.c:816
#24 0x805f9df9 in syscall2 (frame=0xffe07cc6abf8)
 at /usr/src/sys/platform/pc64/x86_64/trap.c:1179
#25 0x805f219f in Xfast_syscall ()
 at /usr/src/sys/platform/pc64/x86_64/exception.S:313
#26 0x002b in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
n sys_close (uap=)

Any ideas what could have gone wrong?

For reference I put the memory dump temporarily online (~1GB BZIP2 + 
Kernel) here:
http://pick.xiqit.de/vmcore.2.bz2  ~988M
http://pick.xiqit.de/kern.2.bz2 ~14M

In case more information is needed, don't hesitate to contact me!

Thanks,
Damian

[1]: root@pick:/usr/pkg/share/httpd/htdocs# uname -a
DragonFly pick 2.8-RELEASE DragonFly v2.8.2.7.g0d8fd-RELEASE #3: Tue Nov 
  2 15:24:24 CET 2010 root@pick:/usr/obj/usr/src/sys/X86_64_GENERIC_SMP 
  x86_64



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your 

[DragonFlyBSD - Bug #2019] (Closed) panic: file desc: malloc limit exceeded

[bugtracker-admin]

Issue #2019 has been updated by tuxillo.

Status changed from New to Closed

Seems it was a problem with the KVM limit in i386. We no longer support i386.


Bug #2019: panic: file desc: malloc limit exceeded
http://bugs.dragonflybsd.org/issues/2019#change-14311

* Author: smag
* Status: Closed
* Priority: Normal
* Assignee: vsrinivas
* Target version: 6.4

I have a crontab entry set to run pkgsrc-update and src-update. Besides that, 
some WSGI process running with Gunicorn (http://gunicorn.org) proxied by nginx 
with access to pgsql. These are not very demanded, mainly testing webapps. It 
also hosts a SnapLogic (http://snaplogic.org/) server.

The core.txt file is attached.

info shows:


Dump header from device /dev/serno/0606J1FW203856.s1b
  Architecture: i386
  Architecture Version: 2
  Dump Length: 141434880B (134 MB)
  Blocksize: 512
  Dumptime: Thu Mar  3 19:21:54 2011
  Hostname: dragon.sebasmagri.com
  Magic: DragonFly Kern Dump
  Version String: DragonFly v2.9.1.747.gf7b29d-DEVELOPMENT #0: Mon Feb 21 
15:27:59 VET 2011
s...@dragon.sebasmagri.com:/usr/obj/usr/src/sys/GENERIC
  Panic String: file desc: malloc limit exceeded
  Dump Parity: 3394002437
  Bounds: 0
  Dump Status: good


My bandwidth is not very good, but I'm going to put the dumps available to 
fetch 
if it's needed. I'm also willing to help testing fixes.

---Files
core.txt (112 KB)


-- 
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 #2001] (Closed) kqueue - Firefox and thunderbird CPU usage

[bugtracker-admin]

Issue #2001 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee changed from 0 to tuxillo

No longer valid.


Bug #2001: kqueue - Firefox and thunderbird CPU usage
http://bugs.dragonflybsd.org/issues/2001#change-14309

* Author: tuxillo
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4

Hi,

Firefox -
During certain operations, such establishing a connection but not receiving a
reply I've noticed that estd raises the CPU frequency and puts it up to the max.
Taking a look at top I don't see anything obvious like xulrunner-bin process
using a lot of CPU.

In the mean time I ktrace'd xulrunner-bin and here's the result:

Total CALL lines in the ktrace.out:

[dfbsdx64] ~/@@0x0002368ec770> kdump -f ktrace.out | grep CALL | wc -l 
 1309637

Thunderbird 
I haven't been able to establish a relation on why this happens, neither I've
done a ktrace but I will try to do it next time it happens.


[dfbsdx64] ~/@@0x0002368ec770> kdump -f ktrace.out | grep CALL | grep poll |
wc -l
  315401


I don't know where the problem is yet. Some more information from other users
experiencing the same issue would be helpful, I guess. 

Cheers,
Antonio Huete



-- 
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 #2000] (Closed) ktrace -C loops forever

[bugtracker-admin]

Issue #2000 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee changed from 0 to tuxillo

Seems not anymore:


devbox# ktrace -C
devbox# ktrace -C
devbox# ktrace -C
devbox# 



Bug #2000: ktrace -C loops forever
http://bugs.dragonflybsd.org/issues/2000#change-14308

* Author: pavalos
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4

ktrace -C loops forever causing the kernel to die.

--Peter



-- 
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 #1991] (Closed) DFBSD v2.9.1.487.g9611ff - QEMU X84_64 not booting

[bugtracker-admin]

Issue #1991 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee changed from 0 to tuxillo

Since this bug was reported we even got a qemu accelerator working (nvmm) and 
everything seems to work perfectly fine.


Bug #1991: DFBSD  v2.9.1.487.g9611ff - QEMU X84_64 not booting
http://bugs.dragonflybsd.org/issues/1991#change-14307

* Author: tuxillo
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4

Hi,

As of commit 9611ff202d0d7da4619ba35d27fa1116cccef60a (x86_64 intr: Support upto
192 IDT entries in ipl and intr vector asm code), qemu-system-x86_64 cannot boot
and panics to DDB with message:

"kernel trap 12 with interrupts disabled"

/home/source/dfbsd/sys/platform/pc64/icu/icu_vector.s:168
/home/source/dfbsd/sys/kern/kern_intr.c:330
/home/source/dfbsd/sys/platform/pc64/isa/clock.c:1107
/home/source/dfbsd/sys/kern/kern_cputimer.c:438
/home/source/dfbsd/sys/kern/init_main.c:258

See the panic here: http://www.imgpaste.com/i/nytcm.png

Cheers,
Antonio Huete



-- 
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 #1983] (Closed) Moving pkg_radd, pkg_search config to different location

[bugtracker-admin]

Issue #1983 has been updated by tuxillo.

Status changed from New to Closed
Assignee set to tuxillo

We no longer use pkgsrc by default.


Bug #1983: Moving pkg_radd, pkg_search config to different location
http://bugs.dragonflybsd.org/issues/1983#change-14306

* Author: justin
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4

For configuring pkg_radd/pkg_search, how about /usr/pkg/etc/mk.conf
instead of /etc/settings.conf or /etc/pkg_radd.conf.  We create mk.conf
automatically anyway, so it will normally exist.

Putting the config for pkg_radd and pkg_search there makes sense in that
other pkgsrc config options go there.  The default values would still work
as expected, even if mk.conf did not exist.

Also, this puts it in a place where it will integrate with the bin-install
target if a user wants to change it.  I don't want to have to set the same
variable in multiple places to get the desired results.



diff --git a/Makefile_upgrade.inc b/Makefile_upgrade.inc
index 71fcfbe..88d330d 100644
--- a/Makefile_upgrade.inc
+++ b/Makefile_upgrade.inc
@@ -1586,4 +1586,3 @@ TO_REMOVE+=/usr/share/man/man4/i386/ndis.4.gz
 TO_REMOVE+=/usr/sbin/ndiscvt
 TO_REMOVE+=/usr/share/man/cat8/ndiscvt.8.gz
 TO_REMOVE+=/usr/share/man/man8/ndiscvt.8.gz
-TO_REMOVE+=/etc/settings.conf
diff --git a/etc/pkg_radd.conf b/etc/pkg_radd.conf
deleted file mode 100644
index e9682b6..000
--- a/etc/pkg_radd.conf
+++ /dev/null
@@ -1,9 +0,0 @@
-# This config file controls where pkg_radd looks for pkgsrc binaries.
-# The example here is the default.
-# Consult the dragonflybsd.org website for a list of mirrors.
-# The path should lead to a directory containing the architectures,
-# like 'i386' and x86_64.  The correct arch and DragonFly version is
-# automatically appended to the path by pkg_radd.
-#
-# BINPKG_BASE=http://mirror-master.dragonflybsd.org/packages
-#
diff --git a/usr.bin/pkg_radd/pkg_radd.1 b/usr.bin/pkg_radd/pkg_radd.1
index a6d5300..c2c33ae 100644
--- a/usr.bin/pkg_radd/pkg_radd.1
+++ b/usr.bin/pkg_radd/pkg_radd.1
@@ -47,11 +47,11 @@ variable to the
 default
 .Xr pkgsrc 7
 binary package server or uses the global
-.Pa /etc/pkg_radd.conf
+.Pa /usr/pkg/etc/mk.conf
 config file to calculate
 .Ev PKG_PATH .
 In
-.Pa /etc/pkg_radd.conf ,
+.Pa /usr/pkg/etc/mk.conf ,
 set
 .Ev BINPKG_BASE
 to your favorite binary packages mirror URL to allow
@@ -87,7 +87,7 @@ If you add the following line
 .Dl "BINPKG_BASE=http://mirror-master.dragonflybsd.org/packages;
 .Pp
 to
-.Pa /etc/pkg_radd.conf ,
+.Pa /usr/pkg/etc/mk.conf ,
 .Nm
 fetches packages from the main
 .Dx
diff --git a/usr.bin/pkg_radd/pkg_radd.sh b/usr.bin/pkg_radd/pkg_radd.sh
index 10d903c..ef44806 100644
--- a/usr.bin/pkg_radd/pkg_radd.sh
+++ b/usr.bin/pkg_radd/pkg_radd.sh
@@ -31,7 +31,8 @@

 osver=`uname -r | awk -F - '{ print $1; }'`
 cpuver=`uname -p | awk -F - '{ print $1; }'`
-[ -f /etc/pkg_radd.conf ] && . /etc/pkg_radd.conf
+[ -f /etc/settings.conf ] && . /etc/settings.conf # deprecated
+[ -f /usr/pkg/etc/mk.conf ] && . /usr/pkg/etc/mk.conf
 : ${BINPKG_BASE:=http://mirror-master.dragonflybsd.org/packages}
 : ${BINPKG_SITES:=$BINPKG_BASE/$cpuver/DragonFly-$osver/stable}
 : ${PKG_PATH:=$BINPKG_SITES/All}
diff --git a/usr.bin/pkg_search/pkg_search.sh
b/usr.bin/pkg_search/pkg_search.sh
index 31e5df8..dc905a2 100644
--- a/usr.bin/pkg_search/pkg_search.sh
+++ b/usr.bin/pkg_search/pkg_search.sh
@@ -39,7 +39,8 @@ set_binpkg_sites() {
 UNAME=`uname -s`
 osver=`uname -r | awk -F - '{ print $1; }'`
 cpuver=`uname -p | awk -F - '{ print $1; }'`
-[ -f /etc/settings.conf ] && . /etc/settings.conf
+[ -f /etc/settings.conf ] && . /etc/settings.conf # deprecated
+[ -f /usr/pkg/etc/mk.conf ] && . /usr/pkg/etc/mk.conf
 set_binpkg_sites

 NO_INDEX=0





-- 
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 #1854] (Closed) Bugs while using encrypted HAMMER root fs

[bugtracker-admin]

Issue #1854 has been updated by tuxillo.

Status changed from New to Closed
Assignee set to tuxillo

Assuming the mentioned commit fixes the problem.


Bug #1854: Bugs while using encrypted HAMMER root fs
http://bugs.dragonflybsd.org/issues/1854#change-14304

* Author: matthias
* Status: Closed
* Priority: High
* Assignee: tuxillo
* Target version: 6.4

Moin,

I installed a recent master (2.7.3.1095.g4cdde1) on my old IBM Thinkpad T42 and 
I installed the system on an encrypted HAMMER root volume.
While installing packages and using X I made some observations:

* After a crash, the "loader" in the initial ramdisk is no longer able to load 
the real init.  It displays all HAMMER related messages about an unclean file 
system and stops right after "recovery complete".  I can move the cursor and 
panic the system, but nothing else happens. Rebooting the live CD and mounting 
the partition fixes the problem.

* The systems tends to freeze regularly during heavy disk activity.  No crash 
dump, no messages, just everything stops working.  Not sure if thats related to 
the crypto stuff ...

Anybody an idea whats going on?

Cheers

Matthias



-- 
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 #1950] (Closed) socket panic

[bugtracker-admin]

Issue #1950 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee changed from 0 to tuxillo

We no longer support i386.


Bug #1950: socket panic
http://bugs.dragonflybsd.org/issues/1950#change-14299

* Author: pavalos
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4

Got a page fault panic today on my laptop.

Files can be fetched from:
http://www.theshell.com/~pavalos/crash/crash6.tar.xz

--Peter


(kgdb) bt
#0  _get_mycpu (di=0xc049ed20) at ./machine/thread.h:83
#1  md_dumpsys (di=0xc049ed20) at 
/usr/src/sys/platform/pc32/i386/dump_machdep.c:263
#2  0xc01ac98e in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:881
#3  0xc01acf4e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:388
#4  0xc01ad1f5 in panic (fmt=0xc03dd634 "%s") at 
/usr/src/sys/kern/kern_shutdown.c:787
#5  0xc039f022 in trap_fatal (frame=0xd6f3ac94, eva=)
at /usr/src/sys/platform/pc32/i386/trap.c:1116
#6  0xc039f130 in trap_pfault (frame=0xd6f3ac94, usermode=0, eva=51)
at /usr/src/sys/platform/pc32/i386/trap.c:1018
#7  0xc039f69c in trap (frame=0xd6f3ac94)
at /usr/src/sys/platform/pc32/i386/trap.c:705
#8  0xc0387b47 in calltrap () at /usr/src/sys/platform/pc32/i386/exception.s:785
#9  0xc01999d0 in knote (list=0xd993de64, hint=0)
at /usr/src/sys/kern/kern_event.c:1303
#10 0xc01ea6cd in sowakeup (so=0xd993de00, ssb=0xd993de4c)
at /usr/src/sys/kern/uipc_socket2.c:499
#11 0xc01ef5d8 in uipc_send (msg=0xde077b50) at 
/usr/src/sys/kern/uipc_usrreq.c:493
#12 0xc0228637 in netmsg_service_loop (arg=0x0) at /usr/src/sys/net/netisr.c:294
#13 0xc01b6117 in lwkt_deschedule_self (td=Cannot access memory at address 0x8
) at /usr/src/sys/kern/lwkt_thread.c:272
Backtrace stopped: previous frame inner to this frame (corrupt stack?)




-- 
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 #1955] (Closed) sowakeup panic

[bugtracker-admin]

Issue #1955 has been updated by tuxillo.

Category set to Kernel
Status changed from New to Closed
Assignee set to tuxillo

We no longer support i386.


Bug #1955: sowakeup panic
http://bugs.dragonflybsd.org/issues/1955#change-14298

* Author: pavalos
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Category: Kernel
* Target version: 6.4

I finally got a crash dump for this machine that's been panicing over
the past few months.  Looks like a networking issue.  Files can be
downloaded at:

http://www.theshell.com/~pavalos/crash/ylem-crash0.tar.xz


panic: page fault

(kgdb) #0  _get_mycpu (di=0xc03ef960) at ./machine/thread.h:83
#1  md_dumpsys (di=0xc03ef960)
at /usr/src/sys/platform/pc32/i386/dump_machdep.c:263
#2  0xc019e6c5 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:881
#3  0xc019ec85 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:388
#4  0xc019ef5d in panic (fmt=0xc0360fd7 "%s")
at /usr/src/sys/kern/kern_shutdown.c:787
#5  0xc032e1fb in trap_fatal (frame=0xd9d33bc0, eva=)
at /usr/src/sys/platform/pc32/i386/trap.c:1125
#6  0xc032e309 in trap_pfault (frame=0xd9d33bc0, usermode=0, eva=4147)
at /usr/src/sys/platform/pc32/i386/trap.c:1026
#7  0xc032edf5 in trap (frame=0xd9d33bc0)
at /usr/src/sys/platform/pc32/i386/trap.c:707
#8  0xc0317f77 in calltrap ()
at /usr/src/sys/platform/pc32/i386/exception.s:785
#9  0xc018afc0 in knote (list=0xf236e364, hint=0)
at /usr/src/sys/kern/kern_event.c:1301
#10 0xc01de0c3 in sowakeup (so=0xf236e300, ssb=0xf236e34c)
at /usr/src/sys/kern/uipc_socket2.c:499
#11 0xc0240bbc in udp_input (mp=0xd9d33cb8, offp=0xd9d33cb4, proto=17)
at /usr/src/sys/netinet/udp_usrreq.c:520
#12 0xc022efc6 in transport_processing_oncpu (m=0x0, hlen=20, ip=0xf655d010)
at /usr/src/sys/netinet/ip_input.c:394
#13 0xc022ff8d in ip_input (m=0xf5537200)
at /usr/src/sys/netinet/ip_input.c:959
#14 0xc022ffb5 in ip_input_handler (msg=0xf553721c)
at /usr/src/sys/netinet/ip_input.c:415
#15 0xc022031f in netmsg_service_loop (arg=0x0)
at /usr/src/sys/net/netisr.c:294
#16 0xc01a8a1e in lwkt_deschedule_self (td=Cannot access memory at address 0x8
)
at /usr/src/sys/kern/lwkt_thread.c:258
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


--Peter



-- 
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 #3314] (New) Bring virtio_console(4) from FreeBSD

[bugtracker-admin]

Issue #3314 has been reported by tuxillo.


Bug #3314: Bring virtio_console(4) from FreeBSD
http://bugs.dragonflybsd.org/issues/3314

* Author: tuxillo
* Status: New
* Priority: Normal
* Assignee: tuxillo
* Category: Driver
* Target version: 6.4
* Start date: 2022-05-29

Bring virtio_console(4) from FreeBSD. It should help with qemu-guest-agent and 
probably other things I am not aware of yet.

Once I have patches to test, I'll post them here.

References:
https://www.freebsd.org/cgi/man.cgi?query=virtio_console=4
https://github.com/aborche/qemu-guest-agent



-- 
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 #3305] (In Progress) CBSD: Add NVMM support in DragonFly BSD

[bugtracker-admin]

Issue #3305 has been updated by tuxillo.

Status changed from New to In Progress

Not sure if there are more outstanding points to make CBSD support in DFly 
better, will find out and, if there aren't, I'll close it.


Bug #3305: CBSD: Add NVMM support in DragonFly BSD
http://bugs.dragonflybsd.org/issues/3305#change-14296

* Author: tuxillo
* Status: In Progress
* Priority: Normal
* Assignee: tuxillo
* Category: Feature request
* Target version: 6.4
* Start date: 2021-11-12

This is a tracking ticket for adding NVMM support in CBSD[1].

fn1. https://www.bsdstore.ru/en/



-- 
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 #3306] Add description support for ifconfig(8)

[bugtracker-admin]

Issue #3306 has been updated by tuxillo.


@dillon, I've gone ahead and pushed the modified version from aly to the repo. 
The buffer to set the description is allocated with M_ZERO so I thought it was 
good enough. @aly, thanks I've pushed the patch with your mods.


Bug #3306: Add description support for ifconfig(8)
http://bugs.dragonflybsd.org/issues/3306#change-14295

* Author: tuxillo
* Status: Closed
* Priority: Normal
* Category: Userland
* Target version: 6.4
* Start date: 2021-11-12



Is there a chance the 'ifconfig NIC description XXX' functionality
will sync with the FreeBSD ? This is a fairly popular option.


# ifconfig vlan1 description vm1-vlan
ifconfig: description: bad value


OpenBSD also has a similar capability[1], as NetBSD as well[2]

Thanks!
__

fn1. https://man.openbsd.org/ifconfig.8

fn2. https://man.netbsd.org/ifconfig.8


---Files
01-if-descr.patch (11.7 KB)
01-if-descr.aly.diff (11.8 KB)


-- 
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 #3306] (Closed) Add description support for ifconfig(8)

[bugtracker-admin]

Issue #3306 has been updated by tuxillo.

Status changed from In Progress to Closed
% Done changed from 50 to 100

Applied in changeset 
commit:dragonflybsd|f6994c54d4ef3b530f323130b6d2a46ec6805672.


Bug #3306: Add description support for ifconfig(8)
http://bugs.dragonflybsd.org/issues/3306#change-14294

* Author: tuxillo
* Status: Closed
* Priority: Normal
* Category: Userland
* Target version: 6.4
* Start date: 2021-11-12



Is there a chance the 'ifconfig NIC description XXX' functionality
will sync with the FreeBSD ? This is a fairly popular option.


# ifconfig vlan1 description vm1-vlan
ifconfig: description: bad value


OpenBSD also has a similar capability[1], as NetBSD as well[2]

Thanks!
__

fn1. https://man.openbsd.org/ifconfig.8

fn2. https://man.netbsd.org/ifconfig.8


---Files
01-if-descr.patch (11.7 KB)
01-if-descr.aly.diff (11.8 KB)


-- 
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 #1921] we miss mlockall

[bugtracker-admin]

Issue #1921 has been updated by tuxillo.


Initial work commited in commit:c936cb6f


Bug #1921: we miss mlockall
http://bugs.dragonflybsd.org/issues/1921#change-14293

* Author: alexh
* Status: In Progress
* Priority: Normal
* Assignee: tuxillo
* Category: VM subsystem
* Target version: 6.4

We don't have the mlockall/munlockall syscalls as documented in [1]. We have at 
least one tool in base that would benefit from it: cryptsetup. Hopefully 
someone 
more familiar with the VM system can implement it without much effort as we 
already have mlock/munlock.

Cheers,
Alex Hornung

[1]: http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html



-- 
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 #1938] (Closed) vkernel pc32 stalls on boot w/ 1CPU

[bugtracker-admin]

Issue #1938 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee deleted (0)

vkernels are no supported anymore or at least until somebody is able to do the 
big changes they need. Also, pc32 was removed long ago.


Bug #1938: vkernel pc32 stalls on boot w/ 1CPU
http://bugs.dragonflybsd.org/issues/1938#change-14292

* Author: vsrinivas
* Status: Closed
* Priority: Normal
* Target version: 6.4

Hi,

Building a vkernel with the latest sources and running it on leaf stalls if
there is 1 virtual CPU at 'tryroot vkd0s0a'; 2+ CPUs works.

-- vs



-- 
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 #1929] (Closed) Panic on nightly build system

[bugtracker-admin]

Ticket #1929 wurde aktualisiert von tuxillo.

Beschreibung aktualisiert
Status wurde von New zu Closed geändert
Zugewiesen an 0 wurde gelöscht

i386 is no longer supported, also not enough information to reproduce the issue.


Bug #1929: Panic on nightly build system
http://bugs.dragonflybsd.org/issues/1929#change-14291

* Autor: lentferj
* Status: Closed
* Priorität: Normal
* Zielversion: 6.4

dfbench.lan.net dumped core - see /var/crash/vmcore.5

Sat Dec  4 10:27:01 CET 2010

Version String: DragonFly v2.9.1.168.gb8d29-DEVELOPMENT #51: Sat Dec 4 
04:37:37 CET 2010 r...@dfbench.lan.net:/usr/obj/usr/src/sys/GENERIC_SMP

panic: from debugger

GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

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 "i386-dragonfly".
For bug reporting instructions, please see:
...
Reading symbols from /boot/kernel/kernel...done.

Unread portion of the kernel message buffer:
panic: td_critcount is/would-go negative! 0xcf8f3ed8 -1
mp_lock = ; cpuid = 0
Trace beginning at frame 0xcfccab08
panic() at panic+0x174
panic(c0624e4c,cf8f3ed8,,cfccab40,c032759b) at panic+0x174
lwkt_remove_tdallq(cfccabf0,c035fdcd,c069a7e0,c069a7e0,1b32) at 
lwkt_remove_tdallq
crit_exit_wrapper(c069a7e0,c069a7e0) at crit_exit_wrapper+0x1c
kern_sendfile(cf78e2b8,8,0,0,1b32) at kern_sendfile+0x391
sys_sendfile(cfccacf0,1e81,0,c06933cc,202) at sys_sendfile+0x1c4
syscall2(cfccad40) at syscall2+0x2b0
Xint0x80_syscall() at Xint0x80_syscall+0x36
Debugger("panic")

CPU0 stopping CPUs: 0x0002
  stopped
panic: from debugger
mp_lock = ; cpuid = 0
boot() called on cpu#0
Uptime: 1h44m39s
Physical memory: 759 MB
Dumping 78 MB: 63 47 31 15

Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/ahci.ko...done.
Loaded symbols for /boot/kernel/ahci.ko
Reading symbols from /boot/kernel/ehci.ko...done.
Loaded symbols for /boot/kernel/ehci.ko
_get_mycpu (di=0xc0704300) at ./machine/thread.h:83
83  __asm ("movl %%fs:globaldata,%0" : "=r" (gd) : "m"(__mycpu__dummy));
(kgdb) #0  _get_mycpu (di=0xc0704300) at ./machine/thread.h:83
#1  md_dumpsys (di=0xc0704300)
 at /usr/src/sys/platform/pc32/i386/dump_machdep.c:263
#2  0xc031dede in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:882
#3  0xc031e49e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:388
#4  0xc031e776 in panic (fmt=0xc05cbab5 "from debugger")
 at /usr/src/sys/kern/kern_shutdown.c:788
#5  0xc017bc09 in db_panic (addr=-1068086144, have_addr=0, count=-1,
 modif=0xcfcca9bc "") at /usr/src/sys/ddb/db_command.c:448
#6  0xc017c27e in db_command () at /usr/src/sys/ddb/db_command.c:344
#7  db_command_loop () at /usr/src/sys/ddb/db_command.c:470
#8  0xc017e910 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71
#9  0xc0564e84 in kdb_trap (type=3, code=0, regs=0xcfccaab8)
 at /usr/src/sys/platform/pc32/i386/db_interface.c:152
#10 0xc057e797 in trap (frame=0xcfccaab8)
 at /usr/src/sys/platform/pc32/i386/trap.c:831
#11 0xc0566207 in calltrap ()
 at /usr/src/sys/platform/pc32/i386/exception.s:785
#12 0xc0564c80 in breakpoint (msg=0xc05e408c "panic") at ./cpu/cpufunc.h:73
#13 Debugger (msg=0xc05e408c "panic")
 at /usr/src/sys/platform/pc32/i386/db_interface.c:334
#14 0xc031e76d in panic (
 fmt=0xc0624e4c "td_critcount is/would-go negative! %p %d")
 at /usr/src/sys/kern/kern_shutdown.c:786
#15 0xc0326e81 in crit_panic () at /usr/src/sys/kern/lwkt_thread.c:1712
#16 0xc032759b in _crit_exit_noyield () at /usr/src/sys/sys/thread2.h:174
#17 _crit_exit_quick () at /usr/src/sys/sys/thread2.h:182
#18 _crit_exit () at /usr/src/sys/sys/thread2.h:190
#19 crit_exit_wrapper () at /usr/src/sys/kern/lwkt_thread.c:1702
#20 0xc035fdcd in kern_sendfile (vp=0xcf78e2b8, sfd=8, offset=0, 
nbytes=6962,
 mheader=0xcfb29200, sbytes=0xcfccac34, flags=0)
 at /usr/src/sys/kern/uipc_syscalls.c:1659
#21 0xc0360661 in sys_sendfile (uap=0xcfccacf0)
 at /usr/src/sys/kern/uipc_syscalls.c:1513
#22 0xc057eecb in syscall2 (frame=0xcfccad40)
 at /usr/src/sys/platform/pc32/i386/trap.c:1336
#23 0xc05662b6 in Xint0x80_syscall ()
 at /usr/src/sys/platform/pc32/i386/exception.s:876
#24 0x001f in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(kgdb) (kgdb)
Token   flags  collisions owner  stallpc
pmap_token  0x  0 not held
dev_token   0x  0 not held
vm_token0x   5497 not held
vmspace_token   0x  0 not held
kvm_token   0x  0 not held
proc_token  

[DragonFlyBSD - Bug #1912] (Closed) diskless vkernel: corrupted files after "pkg_admin check"

[bugtracker-admin]

Issue #1912 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee deleted (0)

vkernels are not supported and probably won't be for a long time, if ever.


Bug #1912: diskless vkernel: corrupted files after "pkg_admin check"
http://bugs.dragonflybsd.org/issues/1912#change-14290

* Author: rumcic
* Status: Closed
* Priority: Normal
* Target version: 6.4

After pkg_admin check is run (part of daily cronjobs) many files get corrupted
(/var/db/pkg, /etc, probably other dirs affected as well).
All the files are still there and the same size, but e.g. cat outputs nothing
while with vi, many "^@" can be seen instead of the expected content.

It seems this happens only on tmpfs mounts, while files on the nfs mount do not
seem to be affected at all.
Have been trying to repeat the behaviour on a physical box, but was unable to
repeat it, it seems only vkernels are affected by this.
-- 
Please do not CC me, since I already receive everything from these MLs.

Regards,
Rumko



-- 
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 #1925] (Closed) hammer: Missing volume (No header)

[bugtracker-admin]

Issue #1925 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee deleted (0)

The first issue seems that was solved at the time this was reported. With 
regards to the second issue, apparently it was a typo while mounting the 
fileystem where the 'b' partition was specified instead of the 'd' one.


Bug #1925: hammer: Missing volume (No header)
http://bugs.dragonflybsd.org/issues/1925#change-14289

* Author: peur.neu
* Status: Closed
* Priority: Normal
* Target version: 6.4

Had a crash as usual using xorg i915 driver while switching to text console.
i915 xorg driver works fantastic. console crashes.
after the crash this is the result on a fresh system.

foo# mount_hammer -o ro /dev/ad2s1b /media/R1
hammer_mount: Missing volume, cannot mount /dev/ad2s1b
(No header)

using.
foo# uname -a
DragonFlyBSD 2.8.2 (i386)

using DF 2.8.2 (x86_64) seems not to happen.

the other hammer functions on x64 work flawless on a full 100Gb drive.



-- 
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 #1921] (In Progress) we miss mlockall

[bugtracker-admin]

Issue #1921 has been updated by tuxillo.

Description updated
Category set to VM subsystem
Status changed from New to In Progress
Assignee changed from 0 to tuxillo
Priority changed from Low to Normal

We do have @mlockall(2)@ but only _MCL_FUTURE_ is currently supported. 
_MCL_CURRENT_ still needs work to be done.



Bug #1921: we miss mlockall
http://bugs.dragonflybsd.org/issues/1921#change-14288

* Author: alexh
* Status: In Progress
* Priority: Normal
* Assignee: tuxillo
* Category: VM subsystem
* Target version: 6.4

We don't have the mlockall/munlockall syscalls as documented in [1]. We have at 
least one tool in base that would benefit from it: cryptsetup. Hopefully 
someone 
more familiar with the VM system can implement it without much effort as we 
already have mlock/munlock.

Cheers,
Alex Hornung

[1]: http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html



-- 
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 #1887] (Closed) System freezes with syscons screen saver on and a high CPU load

[bugtracker-admin]

Issue #1887 has been updated by tuxillo.

Status changed from Feedback to Closed

Hey, thanks for replying :-)

Closing.


Bug #1887: System freezes with syscons screen saver on and a high CPU load
http://bugs.dragonflybsd.org/issues/1887#change-14286

* Author: steve
* Status: Closed
* Priority: Normal
* Target version: 6.4

Hi,

I'm running v2.9.0.68.g57eab-DEVELOPMENT on an M4A78L motherboard with a Phenom 
II 955 (quad core 3.2 GHz), however this has been happening for a while but 
it's only now that I've pinned down the circumstances.

If I have the logo-saver running and displayed on the console then anything 
that generates a high CPU load (make -j 8 buildworld in an ssh session from 
another box does nicely) will lock the system up solid when the logo reaches a 
certain point near the top right hand side.
Once locked the system is completely unresponsive to network or keyboard, only 
a reset or power cycle will unlock it. Without the logo_saver running the 
system is as
solid as a rock.



-- 
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 #1887] System freezes with syscons screen saver on and a high CPU load

[bugtracker-admin]

Issue #1887 has been updated by steve.


Hi,

This happened over eleven years ago on hardware that has long since
vanished. It has very probably been inadvertently fixed over the years.
It's certainly not worth any effort now.

On Sun, 15 May 2022 12:46:52 -0700
bugtracker-ad...@leaf.dragonflybsd.org wrote:

> Issue #1887 has been updated by tuxillo.
> 
> Subject changed from System freeze - with logo_saver and high CPU load to
> System freezes with syscons screen saver on and a high CPU load Status
> changed from New to Feedback
> 
> Could not reproduce it, am I missing something? I tried in a VM, I loaded
> the module, set a timeout and started a buildworld. The logo was bumping
> in the sides of the emulated screen and buildworld finished successfully.
> 
> We could probably remove the screen savers altogether. I'll leave this
> opened just in case anybody has something to say.
> 
> 
> Bug #1887: System freezes with syscons screen saver on and a high CPU load
> http://bugs.dragonflybsd.org/issues/1887#change-14283
> 
> * Author: steve
> * Status: Feedback
> * Priority: Normal
> * Target version: 6.4
> 
> Hi,
> 
> I'm running v2.9.0.68.g57eab-DEVELOPMENT on an M4A78L motherboard with a
> Phenom II 955 (quad core 3.2 GHz), however this has been happening for a
> while but it's only now that I've pinned down the circumstances.
> 
> If I have the logo-saver running and displayed on the console then
> anything that generates a high CPU load (make -j 8 buildworld in an ssh
> session from another box does nicely) will lock the system up solid when
> the logo reaches a certain point near the top right hand side. Once
> locked the system is completely unresponsive to network or keyboard, only
> a reset or power cycle will unlock it. Without the logo_saver running the
> system is as solid as a rock.
> 
> 
> 


-- 
Steve O'Hara-Smith 


Bug #1887: System freezes with syscons screen saver on and a high CPU load
http://bugs.dragonflybsd.org/issues/1887#change-14284

* Author: steve
* Status: Feedback
* Priority: Normal
* Target version: 6.4

Hi,

I'm running v2.9.0.68.g57eab-DEVELOPMENT on an M4A78L motherboard with a Phenom 
II 955 (quad core 3.2 GHz), however this has been happening for a while but 
it's only now that I've pinned down the circumstances.

If I have the logo-saver running and displayed on the console then anything 
that generates a high CPU load (make -j 8 buildworld in an ssh session from 
another box does nicely) will lock the system up solid when the logo reaches a 
certain point near the top right hand side.
Once locked the system is completely unresponsive to network or keyboard, only 
a reset or power cycle will unlock it. Without the logo_saver running the 
system is as
solid as a rock.



-- 
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 #1887] (Feedback) System freezes with syscons screen saver on and a high CPU load

[bugtracker-admin]

Issue #1887 has been updated by tuxillo.

Subject changed from System freeze - with logo_saver and high CPU load to 
System freezes with syscons screen saver on and a high CPU load
Status changed from New to Feedback

Could not reproduce it, am I missing something? I tried in a VM, I loaded the 
module, set a timeout and started a buildworld. The logo was bumping in the 
sides of the emulated screen and buildworld finished successfully.

We could probably remove the screen savers altogether. I'll leave this opened 
just in case anybody has something to say.


Bug #1887: System freezes with syscons screen saver on and a high CPU load
http://bugs.dragonflybsd.org/issues/1887#change-14283

* Author: steve
* Status: Feedback
* Priority: Normal
* Target version: 6.4

Hi,

I'm running v2.9.0.68.g57eab-DEVELOPMENT on an M4A78L motherboard with a Phenom 
II 955 (quad core 3.2 GHz), however this has been happening for a while but 
it's only now that I've pinned down the circumstances.

If I have the logo-saver running and displayed on the console then anything 
that generates a high CPU load (make -j 8 buildworld in an ssh session from 
another box does nicely) will lock the system up solid when the logo reaches a 
certain point near the top right hand side.
Once locked the system is completely unresponsive to network or keyboard, only 
a reset or power cycle will unlock it. Without the logo_saver running the 
system is as
solid as a rock.



-- 
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 #1880] (Closed) hal and dbus daemons enabled turn machine in to unbootable

[bugtracker-admin]

Issue #1880 has been updated by tuxillo.

Status changed from New to Closed

HAL is deprecated for 12 years now. D-Bus it's being used without issues in 
modern DragonFly BSD releases via dports, we no longer use pkgsrc either.


Bug #1880: hal and dbus daemons enabled turn machine in to unbootable
http://bugs.dragonflybsd.org/issues/1880#change-14281

* Author: bodie
* Status: Closed
* Priority: Normal
* Target version: 6.4

I installed couple of packages with pkgin from 2010Q2 (Island mirror). Between 
them were hal and dbus daemon.


> ls -l /usr/local/etc/rc.d
total 1
-r-xr-xr-x  1 root  wheel  506 Oct 18 19:50 dbus
-r-xr-xr-x  1 root  wheel  329 Oct 18 20:20 hal
> 
> cat /etc/rc.conf

# -- BEGIN DragonFly BSD Installer automatically generated configuration  -- #
# -- Written on Mon Oct 18 10:59:26 2010 -- #
dumpdev="/dev/serno/0001.s1b"
# -- END of DragonFly BSD Installer automatically generated configuration -- #

# -- BEGIN DragonFly BSD Installer automatically generated configuration  -- #
# -- Written on Mon Oct 18 11:59:34 2010 -- #
hostname="dfly.localdomain"
ifconfig_lnc0="DHCP"
# -- END of DragonFly BSD Installer automatically generated configuration -- #

dbus_enable="YES"
hal_enable="YES"
> 
> kldstat
Id Refs AddressSize Name
 19 0xc010 7390c0   kernel
 21 0xc083a000 23c28linux.ko
 31 0xc085e000 6b28 snd_es137x.ko
 42 0xc0865000 2297csound.ko
 51 0xc0888000 6ca7cacpi.ko
 61 0xc08f5000 11b7cahci.ko
 71 0xc0907000 9334 ehci.ko
> 

> sysctl kern.version
kern.version: DragonFly 2.7-DEVELOPMENT #0: Fri Oct 15 04:09:14 UTC 2010
r...@avalon.theshell.com:/usr/obj/usr/src/sys/GENERIC

> 


When I try to boot with that configuration my vm will become crazy and after 
start of hal it shows bunch of these messages which never ends so I need to 
reset that vm, go into safe mode and remove hal from start up.


Oct 18 20:00:25 dfly kernel: ata1: FAILURE - oversized DMA transfer attempt
69632 > 65536
Oct 18 20:00:25 dfly kernel: acd0: setting up DMA failed


> pkg_info hal
Information for hal-0.5.11nb27:

Comment:
FreeDesktop hardware abstraction layer

Requires:
libvolume_id>=0.81.0
GConf>=2.12.1nb1
glib2>=2.14.3
dbus>=0.91
expat>=2.0.0nb1
dbus-glib>=0.71
pciids>=20061026
usbids>=20081118
policykit>=0.9
hal-info>=20081022

Required by:
pulseaudio-0.9.21nb3


> pkg_info dbus
Information for dbus-1.2.4.6:

Comment:
Message bus system

Requires:
libX11>=1.1
gettext-lib>=0.14.5
expat>=2.0.0nb1

Required by:
dbus-glib-0.88
policykit-0.9nb7
GConf-2.28.1
hal-0.5.11nb27
consolekit-0.3.0nb4
pulseaudio-0.9.21nb3



It's in VMware Player 3.1.2 on Windows XP SP3.



-- 
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 #1877] Freeze during 1st hammer cleanup after new install

[bugtracker-admin]

Issue #1877 has been updated by tuxillo.

Description updated
Assignee deleted (0)
Target version changed from 6.4 to Unverifiable

Not enough information to setup a test in order to reproduce it.


Bug #1877: Freeze during 1st hammer cleanup after new install
http://bugs.dragonflybsd.org/issues/1877#change-14279

* Author: elekktretterr
* Status: New
* Priority: Normal
* Target version: Unverifiable

I just installed latest master, and I was in the process of installing
some pkgsrc packages when I decided to run hammer cleanup. And everything
hung (no panic) during recopy procedure on /usr.

This laptop runs an SMP(2 cores) kernel and has 1.5GB RAM. Sorry, no core
dump.

Petr



-- 
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 #1832] (Closed) page fault panic

[bugtracker-admin]

Issue #1832 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee deleted (0)

Information is too vague to be able to setup a test enviroment to see if the 
issue can be reproduced.


Bug #1832: page fault panic
http://bugs.dragonflybsd.org/issues/1832#change-14277

* Author: eocallaghan
* Status: Closed
* Priority: High
* Target version: 6.4

While running stress2 tests over night, udp & tty..

I awoke to find the following dump on my leaf account;

http://leaf.dragonflybsd.org/~evocallaghan/page_fault.7z

Sorry, no test case.. I don't really understand this dump.

Cheers,
Edward.



-- 
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 #1862] (Rejected) Multicast needs to be made MPSAFE without mp_lock

[bugtracker-admin]

Issue #1862 has been updated by tuxillo.

Description updated
Status changed from New to Rejected
Assignee deleted (0)

Whatever that needs fixing, it will be done in #1856, closing.


Bug #1862: Multicast needs to be made MPSAFE without mp_lock
http://bugs.dragonflybsd.org/issues/1862#change-14276

* Author: eocallaghan
* Status: Rejected
* Priority: Normal
* Target version: 6.4

See http://bugs.dragonflybsd.org/issue1856 for background.

ip_output() needs to properly locked or rewritten it looks very messy.



-- 
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 #1816] (Closed) p->cc can go negative in libpcap

[bugtracker-admin]

Issue #1816 has been updated by tuxillo.

Description updated
Status changed from New to Closed
% Done changed from 0 to 100

Already fixed some 12 years ago in this commit:

https://github.com/the-tcpdump-group/libpcap/commit/b26d8d2aa849c8021cdfa872901e82fb469460ef

We have a version that has the fix.




Bug #1816: p->cc can go negative in libpcap
http://bugs.dragonflybsd.org/issues/1816#change-14273

* Author: guy
* Status: Closed
* Priority: Normal
* Assignee: sjg
* Target version: 6.4

In pcap_read_bpf(), ep is set based on the return value of read(), but read() 
from a BPF device doesn't necessarily return a value that's a multiple of the 
alignment value for BPF_WORDALIGN(). However, whenever we increment bp, we 
round up the increment value by a value rounded up by BPF_WORDALIGN(), so we 
could increment bp past ep after processing the last packet in the buffer.

This can be reproduced by running a program that opens a capture device with a 
timeout of 0, in a loop, calls pcap_dispatch() with a cnt argument of 1, and 
reports when it returns a value of 0. The timeout of 0 means that the read() 
that libpcap does shouldn't return until there's packet data, so a timeout 
won't cause pcap_dispatch() to return 0. Do a large amount of network data 
transfer, to fill up the BPF bucket; notice that, on occasion, the program will 
report that pcap_dispatch() returns 0.

See the attached patch, which also fixes a case where, if you break out of the 
packet read loop due to a pcap_breakloop() call, p->bp isn't advanced and p->cc 
isn't reduced.

---Files
patch.txt (1.18 KB)


-- 
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 #1769] panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in tcp_callout_active

[bugtracker-admin]

Issue #1769 has been updated by tuxillo.

Description updated
Target version changed from 6.4 to Unverifiable

Core dumps for i386, which is no longer supported. Also, note enough 
information on how to reproduce it, moving to unverifiable.


Bug #1769: panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in 
tcp_callout_active
http://bugs.dragonflybsd.org/issues/1769#change-14272

* Author: pavalos
* Status: New
* Priority: Normal
* Assignee: sjg
* Target version: Unverifiable


panic: assertion: _tp->tt_msg->tt_cpuid == mycpuid in tcp_callout_active
mp_lock = 0001; cpuid = 1
Trace beginning at frame 0xd82db9b8
panic() at panic+0x14f
panic(c037a20a,c03a4300,c036edf8,e100,0) at panic+0x14f
tcp_output(e3462208,e6b7e000) at tcp_output+0xe9a
tcp_input(e6b7e000,14,6) at tcp_input+0x3d63
transport_processing_oncpu(14,0,0,0,0) at transport_processing_oncpu+0x95
ip_input(e6b7e000) at ip_input+0xf11
ip_input_handler(e6b7e018) at ip_input_handler+0xe
netisr_run(2,e6b7e000) at netisr_run+0xdf
ether_demux_oncpu(d7e2c000,e6b7e000) at ether_demux_oncpu+0x37c
ether_input_oncpu(d7e2c000,e6b7e000) at ether_input_oncpu+0x138
ether_input_handler(e6b7e018) at ether_input_handler+0x102
netmsg_service(e6b7e018,1,0,1,ff8083d4) at netmsg_service+0x9d
tcpmsg_service_loop(0,0,0,0,0) at tcpmsg_service_loop+0x43
lwkt_exit() at lwkt_exit
boot() called on cpu#1
Uptime: 14d22h16m8s
Physical memory: 2043 MB
Dumping 487 MB: 472 456 440 424 408 392 376 360 344 328 312 296 280 264 248 232 
216 200 184 168 152 136 120 104 88 72 56 40 24 8

_get_mycpu (di=0xc0466b60) at ./machine/thread.h:83
83  __asm ("movl %%fs:globaldata,%0" : "=r" (gd) : "m"(__mycpu__dummy));





ylem:/var/crash# uname -a
DragonFly ylem.theshell.com 2.7-DEVELOPMENT DragonFly 
v2.7.3.8.g3219b-DEVELOPMENT #28: Fri May  7 09:16:10 HST 2010 
r...@ylem.theshell.com:/usr/obj/usr/src/sys/YLEM  i386




This happened twice while switching back and forth between lighttpd
and nginx.  Kernel and cores being uploaded to
leaf:~pavalos/crash/*30 and *31

--Peter



-- 
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 #1826] panic during boot: assertion so->so_port ... in tcp_input

[bugtracker-admin]

Issue #1826 has been updated by tuxillo.

Description updated
Assignee deleted (0)
Target version changed from 6.4 to Unverifiable

Core dumps no longer available, not enough information. Moving to unverifiable.


Bug #1826: panic during boot: assertion so->so_port ... in tcp_input
http://bugs.dragonflybsd.org/issues/1826#change-14271

* Author: ftigeot
* Status: New
* Priority: Normal
* Target version: Unverifiable

The last kernel panics during boot.
Additionally, function names were replaced by random ascii characters:


Mounting NFS filesystems:
panic: assertion: so->so_port == >td_msgport in tcp_input
mp_lock = ; cpuid = 0
Trace beginning at frame 0xfffe2f2d9750
[random ascii junk]() at [random ascii junk]() + 0x239
[...]
à�äiչ
[...]
Debugger("panic")


This particular kernel was built with the SOCKBUF_DEBUG and MBUF_DEBUG
options.

Coredump files are at the usual place:
http://www.wolfpond.org/crash.dfly/



-- 
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 #1808] (Closed) tmpfs doesn't mount automatically after reboot

[bugtracker-admin]

Issue #1808 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee changed from 0 to tuxillo

Cannot reproduce:


root@dev03:~ # cat /boot/loader.conf  
vfs.root.mountfrom="ufs:vbd0s1d"
tmpfs_load="YES"
root@dev03:~ # mount /tmp 
root@dev03:~ #

root@dev03:~ # umount /tmp 
root@dev03:~ # mount /tmp 
tmpfs   2674M 0B  2674M 0q/tmp
root@dev03:~ # df -hT /tmp
Filesystem  TypeSize   Used  Avail Capacity  Mounted on
tmpfs   tmpfs  2674M 0B  2674M 0q/tmp
root@dev03:~ #  





Bug #1808: tmpfs doesn't mount automatically after reboot
http://bugs.dragonflybsd.org/issues/1808#change-14269

* Author: charles.rapenne
* Status: Closed
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4

Hello

I'm using tmpfs for the /tmp directory on my laptop,
but everytime it boots, it does not mount /tmp.

I added the following line in /etc/fstab

@tmpfs   /tmp  tmpfs   rw,mode=777,size=1G 0 0@

and

@tmpfs_load="YES"@ in /boot/loader.conf

When I want to mount it manually, I get this message:

@#mount /tmp
tmpfs: vfsload(tmpfs): File exists@

If I kldunload tmpfs && kldload tmpfs, I can mount it correctly !

If I unload the kernel module then I reboot, it'll mount /tmp.

I'm using a custom kernel with SMP support (I only uncommented the
line about SMP) with DragonFly 2.7.3

I'm not familiar with mailing-lists, I hope I'm using it correctly and
I gave you enought informations too.

I'm also about to start a project of auto-benchmarking to find
regressions every day (like phoronix do with Linux),
but I'll tell you more about this if it works !



-- 
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 #1806] (Closed) DFBSD 2.7.3 - mbuf exhausted while rsync to a NFS

[bugtracker-admin]

Issue #1806 has been updated by tuxillo.

Status changed from New to Closed
% Done changed from 0 to 100

Unable to reproduce this issue, hence closing.

h3. Evidence

*SERVER*


root@dev01:/usr/src # sysctl hw.physmem 
hw.physmem: 500301824

root@dev01:/usr/src # cat /etc/exports  
/usr -alldirs -maproot=root: -network 10.0.0.0/24



* Have been monitoring the mbuf usage, it's really low during the copy.
* No errors in dmesg.


*CLIENT*


root@dev03:~ # df -h /usr/src 
FilesystemSize   Used  Avail Capacity  Mounted on
10.0.0.101:/usr/src  44.5G  11.0G  33.5G25q/usr/src

root@dev03:~ # rsync -aP --delete /usr/src /mnt/target/usr/ 
sending incremental file list

root@dev03:~ # diff -urN /usr/src /mnt/target/usr/src
load: 0.00  cmd: diff 798 [running] 0.08u 1.36s 7q 3916k
root@dev03:~ #  



* Repeated the copy multiple times.
* Even compared the directories with diff and rsync.


Bug #1806: DFBSD 2.7.3 - mbuf exhausted while rsync to a NFS
http://bugs.dragonflybsd.org/issues/1806#change-14268

* Author: tuxillo
* Status: Closed
* Priority: Normal
* Target version: 6.4

I got two virtual machines running DFBSD. One is KVM (512MB mem) and the other
one is under VMware (1024MB).

kvm is the NFS server which is exporting /usr like this:
@/usr -alldirs -maproot=root: -network @

>From the vmware I mount it, and start copying the repo using rsync:

@# rsync -av -progress /usr/src /mnt/target/usr/@

After a while the following warning appears in the kvm (NFS server):
Warning, objcache(mbuf): Exhausted!


# netstat -m
9056/9056 mbufs in use (current/max):
134/4528 mbuf clusters in use (current/max)
  9190 mbufs and mbuf clusters allocated to data
2532 Kbytes allocated to network (22% of mb_map in use)
163 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines



In the client part the copy stops:


dfbsd/.git/objects/pack/pack-eb16b18282ea58f39f353cb1c7e4786cfa544159.pack
24084480  10%4.10MB/s0:00:48
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken
pipe (32)
rsync: write failed on
"/mnt/remote/dfbsd/.git/objects/pack/pack-eb16b18282ea58f39f353cb1c7e4786cfa544159.pack":
RPC struct is bad (72)
rsync error: error in file IO (code 11) at receiver.c(302) [receiver=3.0.7]
[sender] io timeout after 30 seconds -- exiting
rsync error: timeout in data send/receive (code 30) at io.c(140) [sender=3.0.7]
[vmware] /usr/src>
 

And I can't even ssh from outside the kvm machine:

% ssh 192.168.3.100
antonioh@192.168.3.100's password: 
Timeout, server not responding.
%




-- 
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 #1597] (Closed) panic: assertion: parent != NULL in hammer_cursor_removed_node (v2.5.1.187.gc1543-DEV, X86_64)

[bugtracker-admin]

Issue #1597 has been updated by tuxillo.

Status changed from In Progress to Closed

Confirmed by dillon that it can be closed.


Bug #1597: panic: assertion: parent != NULL in hammer_cursor_removed_node 
(v2.5.1.187.gc1543-DEV, X86_64)
http://bugs.dragonflybsd.org/issues/1597#change-14267

* Author: saifikhan
* Status: Closed
* Priority: Normal
* Assignee: dillon
* Category: Kernel
* Target version: 6.4

Hi:

After about 8 hrs of uptime on the X86_64 build, the system had
an assertion failure.

@ assertion: parent != NULL in hammer_cursor_removed_node@

'uname -a'


DragonFly 2.5.1-DEVELOPMENT DragonFly v2.5.1.187.gc1543-DEVELOPMENT #0: 
Fri Nov  6 23:57:32 IST 2009 
r...@amd64x2.datasynergy.org:/usr/obj/usr/src/sys/SYNERGYOS  
x86_64


After reboot, i ran kgdb and here is the trace (using gdb 7.0)


Script started on Sun Nov  8 04:10:42 2009
# kgdb kernel.0 vmcore.0
GNU gdb (GDB) 7.0
This GDB was configured as "x86_64-dragonfly".
Reading symbols from /var/crash/kernel.0...done.

Unread portion of the kernel message buffer:
panic: assertion: parent != NULL in hammer_cursor_removed_node
mp_lock = 0001; cpuid = 1
Trace beginning at frame 0xca5ad198
?H?]?L?e?L?m?L?u???UH??ATSI[() at ?H?]?L?e?L?m?L?u???UH??ATSI[+0x1f7
?H?]?L?e?L?m?L?u???UH??ATSI[() at ?H?]?L?e?L?m?L?u???UH??ATSI[+0x1f7
?() at ?+0x38
H??I??I???
() at H??I??I???
+0x165
H??I??I???
() at H??I??I???
+0x14b
() at +0x203
??? H
??() at ???  H
??+0x3ff
??I??I??H??H() at ??I??I??H??H+0x3b6
??UH?() at ??UH?+0x1fd
?;u?$;t H?@hH??u??E?() at ?;u?$;t H?@hH??u??E?+0x2d
?>???() at ?>???+0x3e
@L?wH?E@???() at @L?wH?E@???+0x110
() at +0x486
f%() at f%+0x1f
??+_?H??@?>=() at ??+_?H??@?>=+0x372
??6() at ??6+0xb3
Debugger("panic")

CPU1 stopping CPUs: 0x0001
 stopped
oops, ran out of processes early!
panic: from debugger
mp_lock = 0001; cpuid = 1
boot() called on cpu#1
Uptime: 2h43m37s

dumping to dev ad4s1b, blockno 4456960
dump 1919 1918 1917 1916 1915 1914 1913 1912 1911 1910 1909 1908 1907 1906 1905 
1904 1903 1902 1901 1900 1899 1898 1897 1896 1895 1894 1893 1892 1891 1890 1889 
1888 1887 1886 1885 1884 1883 1882 1881 1880 1879 1878 1877 1876 1875 1874 1873 
1872 1871 1870 1869 1868 1867 1866 1865 1864 1863 1862 1861 1860 1859 1858 1857 
1856 1855 1854 1853 1852 1851 1850 1849 1848 1847 1846 1845 1844 1843 1842 1841 
1840 1839 1838 1837 1836 1835 1834 1833 1832 1831 1830 1829 1828 1827 1826 1825 
1824 1823 1822 1821 1820 1819 1818 1817 1816 1815 1814 1813 1812 1811 1810 1809 
1808 1807 1806 1805 1804 1803 1802 1801 1800 1799 1798 1797 1796 1795 1794 1793 
1792 1791 1790 1789 1788 1787 1786 1785 1784 1783 1782 1781 1780 1779 1778 1777 
1776 1775 1774 1773 1772 1771 1770 1769 1768 1767 1766 1765 1764 1763 1762 1761 
1760 1759 1758 1757 1756 1755 1754 1753 1752 1751 1750 1749 1748 1747 1746 1745 
1744 1743 1742 1741 1740 1739 1738 1737 1736 1735 1734 1733 1732 1731 1730 1729 
1728 1727 1726 1725 1724 1723!
  1722 1721 1720 1719 1718 1717 1716 1715 1714 1713 1712 1711 1710 1709 1708 
1707 1706 1705 1704 1703 1702 1701 1700 1699 1698 1697 1696 1695 1694 1693 1692 
1691 1690 1689 1688 1687 1686 1685 1684 1683 1682 1681 1680 1679 1678 1677 1676 
1675 1674 1673 1672 1671 1670 1669 1668 1667 1666 1665 1664 1663 1662 1661 1660 
1659 1658 1657 1656 1655 1654 1653 1652 1651 1650 1649 1648 1647 1646 1645 1644 
1643 1642 1641 1640 1639 1638 1637 1636 1635 1634 1633 1632 1631 1630 1629 1628 
1627 1626 1625 1624 1623 1622 1621 1620 1619 1618 1617 1616 1615 1614 1613 1612 
1611 1610 1609 1608 1607 1606 1605 1604 1603 1602 1601 1600 1599 1598 1597 1596 
1595 1594 1593 1592 1591 1590 1589 1588 1587 1586 1585 1584 1583 1582 1581 1580 
1579 1578 1577 1576 1575 1574 1573 1572 1571 1570 1569 1568 1567 1566 1565 1564 
1563 1562 1561 1560 1559 1558 1557 1556 1555 1554 1553 1552 1551 1550 1549 1548 
1547 1546 1545 1544 1543 1542 1541 1540 1539 1538 1537 1536 1535 1534 1533 1532 
1531 1530 1529 1528 1527 1526 15!
 25 1524 1523 1522 1521 1520 1519 1518 1517 1516 1515 1514 1513!
  1512 1511 1510 1509 1508 1507 1506 1505 1504 1503 1502 1501 1500 1499 1498 
1497 1496 1495 1494 1493 1492 1491 1490 1489 1488 1487 1486 1485 1484 1483 1482 
1481 1480 1479 1478 1477 1476 1475 1474 1473 1472 1471 1470 1469 1468 1467 1466 
1465 1464 1463 1462 1461 1460 1459 1458 1457 1456 1455 1454 1453 1452 1451 1450 
1449 1448 1447 1446 1445 1444 1443 1442 1441 1440 1439 1438 1437 1436 1435 1434 
1433 1432 1431 1430 1429 1428 1427 1426 1425 1424 1423 1422 1421 1420 1419 1418 
1417 1416 1415 1414 1413 1412 1411 1410 1409 1408 1407 1406 1405 1404 1403 1402 
1401 1400 1399 1398 1397 1396 1395 1394 1393 1392 1391 1390 1389 1388 1387 1386 
1385 1384 1383 1382 1381 1380 1379 1378 1377 1376 1375 1374 1373 1372 1371 1370 
1369 1368 1367 1366 1365 1364 1363 1362 1361 1360 1359 1358 1357 1356 1355 1354 
1353 1352 1351 1350 1349 1348 1347 1346 1345 1344 1343 1342 1341 

[DragonFlyBSD - Bug #582] (Closed) PF states bug

[bugtracker-admin]

Issue #582 has been updated by tuxillo.

Status changed from New to Closed
Assignee deleted (0)

PF has been updated at least twice since this was reported and additional work 
has been done on top of it, too. Closing this issue.
Please report it on a new issue if it still happens in newer versions of dfly.


Bug #582: PF states bug
http://bugs.dragonflybsd.org/issues/582#change-14265

* Author: bastyaelvtars
* Status: Closed
* Priority: High
* Target version: 6.4

Running 1.8.0 here and when I flush the state table in PF (pfctl -F state) then 
no new state entries get created or at least no program can show them, there 
are always 0 states (of coursee there had been thousands of them before 
flushing).



-- 
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 #1597] (In Progress) panic: assertion: parent != NULL in hammer_cursor_removed_node (v2.5.1.187.gc1543-DEV, X86_64)

[bugtracker-admin]

Issue #1597 has been updated by tuxillo.

Category set to Kernel
Status changed from New to In Progress
Assignee set to dillon
% Done changed from 0 to 100

Mentioned patche was commited, commit:901ba05cd0e7874977a4a937d1b2f9a76ffb9c2d


commit 901ba05cd0e7874977a4a937d1b2f9a76ffb9c2d
Author: Matthew Dillon 
Date:   Sat Dec 12 10:50:22 2009 -0800

HAMMER VFS - Fix incorrect hammer_cursor_removed_node() call in 
btree_remove()

* hammer_cursor_removed_node() was being called on the wrong node.  This
  fixes a parent != NULL assertion later on.

* There is still at least one known issue where btree_iterate can panic
  due to a cursor tracking issue that has not yet been located.




Bug #1597: panic: assertion: parent != NULL in hammer_cursor_removed_node 
(v2.5.1.187.gc1543-DEV, X86_64)
http://bugs.dragonflybsd.org/issues/1597#change-14264

* Author: saifikhan
* Status: In Progress
* Priority: Normal
* Assignee: dillon
* Category: Kernel
* Target version: 6.4

Hi:

After about 8 hrs of uptime on the X86_64 build, the system had
an assertion failure.

@ assertion: parent != NULL in hammer_cursor_removed_node@

'uname -a'


DragonFly 2.5.1-DEVELOPMENT DragonFly v2.5.1.187.gc1543-DEVELOPMENT #0: 
Fri Nov  6 23:57:32 IST 2009 
r...@amd64x2.datasynergy.org:/usr/obj/usr/src/sys/SYNERGYOS  
x86_64


After reboot, i ran kgdb and here is the trace (using gdb 7.0)


Script started on Sun Nov  8 04:10:42 2009
# kgdb kernel.0 vmcore.0
GNU gdb (GDB) 7.0
This GDB was configured as "x86_64-dragonfly".
Reading symbols from /var/crash/kernel.0...done.

Unread portion of the kernel message buffer:
panic: assertion: parent != NULL in hammer_cursor_removed_node
mp_lock = 0001; cpuid = 1
Trace beginning at frame 0xca5ad198
?H?]?L?e?L?m?L?u???UH??ATSI[() at ?H?]?L?e?L?m?L?u???UH??ATSI[+0x1f7
?H?]?L?e?L?m?L?u???UH??ATSI[() at ?H?]?L?e?L?m?L?u???UH??ATSI[+0x1f7
?() at ?+0x38
H??I??I???
() at H??I??I???
+0x165
H??I??I???
() at H??I??I???
+0x14b
() at +0x203
??? H
??() at ???  H
??+0x3ff
??I??I??H??H() at ??I??I??H??H+0x3b6
??UH?() at ??UH?+0x1fd
?;u?$;t H?@hH??u??E?() at ?;u?$;t H?@hH??u??E?+0x2d
?>???() at ?>???+0x3e
@L?wH?E@???() at @L?wH?E@???+0x110
() at +0x486
f%() at f%+0x1f
??+_?H??@?>=() at ??+_?H??@?>=+0x372
??6() at ??6+0xb3
Debugger("panic")

CPU1 stopping CPUs: 0x0001
 stopped
oops, ran out of processes early!
panic: from debugger
mp_lock = 0001; cpuid = 1
boot() called on cpu#1
Uptime: 2h43m37s

dumping to dev ad4s1b, blockno 4456960
dump 1919 1918 1917 1916 1915 1914 1913 1912 1911 1910 1909 1908 1907 1906 1905 
1904 1903 1902 1901 1900 1899 1898 1897 1896 1895 1894 1893 1892 1891 1890 1889 
1888 1887 1886 1885 1884 1883 1882 1881 1880 1879 1878 1877 1876 1875 1874 1873 
1872 1871 1870 1869 1868 1867 1866 1865 1864 1863 1862 1861 1860 1859 1858 1857 
1856 1855 1854 1853 1852 1851 1850 1849 1848 1847 1846 1845 1844 1843 1842 1841 
1840 1839 1838 1837 1836 1835 1834 1833 1832 1831 1830 1829 1828 1827 1826 1825 
1824 1823 1822 1821 1820 1819 1818 1817 1816 1815 1814 1813 1812 1811 1810 1809 
1808 1807 1806 1805 1804 1803 1802 1801 1800 1799 1798 1797 1796 1795 1794 1793 
1792 1791 1790 1789 1788 1787 1786 1785 1784 1783 1782 1781 1780 1779 1778 1777 
1776 1775 1774 1773 1772 1771 1770 1769 1768 1767 1766 1765 1764 1763 1762 1761 
1760 1759 1758 1757 1756 1755 1754 1753 1752 1751 1750 1749 1748 1747 1746 1745 
1744 1743 1742 1741 1740 1739 1738 1737 1736 1735 1734 1733 1732 1731 1730 1729 
1728 1727 1726 1725 1724 1723!
  1722 1721 1720 1719 1718 1717 1716 1715 1714 1713 1712 1711 1710 1709 1708 
1707 1706 1705 1704 1703 1702 1701 1700 1699 1698 1697 1696 1695 1694 1693 1692 
1691 1690 1689 1688 1687 1686 1685 1684 1683 1682 1681 1680 1679 1678 1677 1676 
1675 1674 1673 1672 1671 1670 1669 1668 1667 1666 1665 1664 1663 1662 1661 1660 
1659 1658 1657 1656 1655 1654 1653 1652 1651 1650 1649 1648 1647 1646 1645 1644 
1643 1642 1641 1640 1639 1638 1637 1636 1635 1634 1633 1632 1631 1630 1629 1628 
1627 1626 1625 1624 1623 1622 1621 1620 1619 1618 1617 1616 1615 1614 1613 1612 
1611 1610 1609 1608 1607 1606 1605 1604 1603 1602 1601 1600 1599 1598 1597 1596 
1595 1594 1593 1592 1591 1590 1589 1588 1587 1586 1585 1584 1583 1582 1581 1580 
1579 1578 1577 1576 1575 1574 1573 1572 1571 1570 1569 1568 1567 1566 1565 1564 
1563 1562 1561 1560 1559 1558 1557 1556 1555 1554 1553 1552 1551 1550 1549 1548 
1547 1546 1545 1544 1543 1542 1541 1540 1539 1538 1537 1536 1535 1534 1533 1532 
1531 1530 1529 1528 1527 1526 15!
 25 1524 1523 1522 1521 1520 1519 1518 1517 1516 1515 1514 1513!
  1512 1511 1510 1509 1508 1507 1506 1505 1504 1503 1502 1501 1500 1499 1498 
1497 1496 1495 1494 1493 1492 1491 1490 1489 1488 1487 1486 1485 1484 1483 1482 
1481 1480 1479 1478 1477 1476 1475 1474 1473 1472 1471 1470 1469 1468 1467 1466 
1465 1464 1463 1462 1461 1460 1459 1458 

[DragonFlyBSD - Bug #1477] (Closed) A lib/udev-compatible interface should eventually be created

[bugtracker-admin]

Issue #1477 has been updated by tuxillo.

Description updated
Status changed from New to Closed
Assignee changed from 0 to alexh
% Done changed from 0 to 100

We have udev(8) since commit:2e7bf158f373428dba2c765c927f14d9e94f00a4, 
commit:3a3826b3871c8c2f480bcba820c6da8f86700143



Bug #1477: A lib/udev-compatible interface should eventually be created
http://bugs.dragonflybsd.org/issues/1477#change-14262

* Author: hasso
* Status: Closed
* Priority: Low
* Assignee: alexh
* Target version: 6.4

sysutils/hal builds and very basic stuff is there, but it lacks support for 
many devices. Some of it could be pulled in from FreeBSD ports maybe, but one 
of most important points - support for storage - must be written from scartch 
probably.

Now with devd hal could be much more useful than it was for now.



-- 
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 #1727] (Feedback) CD boot panic (2.6.1) (usb?)

[bugtracker-admin]

Issue #1727 has been updated by tuxillo.

Description updated
Status changed from New to Feedback
Assignee deleted (0)
Target version changed from 6.4 to Unverifiable


Bug #1727: CD boot panic (2.6.1) (usb?)
http://bugs.dragonflybsd.org/issues/1727#change-14259

* Author: kiril
* Status: Feedback
* Priority: Normal
* Target version: Unverifiable

dfly Live CD 2.6.1 panics on boot. logging a bug report with photos attached 
as per SW's request. booting with ehci does not make any difference.

please let me know if a .zip it not an acceptable format.

---Files
dfly-boot.zip (271 KB)


-- 
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 #1593] (Feedback) panic: assertion: ccb == ap->ap_err_ccb in ahci_put_err_ccb

[bugtracker-admin]

Issue #1593 has been updated by tuxillo.

Description updated
Category set to Kernel
Status changed from New to Feedback
Assignee changed from 0 to ftigeot
Target version changed from 6.4 to Unverifiable

Moving this to unverifiable, @ftigeot please if you think you can test it again 
let us know.


Bug #1593: panic: assertion: ccb == ap->ap_err_ccb in ahci_put_err_ccb
http://bugs.dragonflybsd.org/issues/1593#change-14258

* Author: ftigeot
* Status: Feedback
* Priority: Normal
* Assignee: ftigeot
* Category: Kernel
* Target version: Unverifiable

This panic occurs when trying to read a defective SATA hard drive with ahci.

On the same machine, when using the nata disk driver (by disabling ahci in
BIOS), the disk is still unreadable with READ_DMA errors but the kernel does
not panic.

System is DragonFly 2.4.1 running on a Core 2 Duo machine with an Intel ICH9
SATA chipset.

The mainboard is a Supermicro X7SBL-LN2:
http://www.supermicro.com/products/motherboard/Xeon3000/3200/X7SBL-LN2.cfm

gzipped kernel and core file are available here:
http://www.wolfpond.org/crash.dfly/



-- 
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 #1397] (Feedback) jobs -l output inconsistency when called from script

[bugtracker-admin]

Issue #1397 has been updated by tuxillo.

Status changed from New to Feedback
Assignee set to tuxillo
% Done changed from 0 to 90

The @jobs(1)@ utility calls whatever builtin the current shell uses, or it is 
directly bypassed by the shell itself, example:


$ cat /usr/bin/jobs 
#!/bin/sh
# $FreeBSD: src/usr.bin/alias/generic.sh,v 1.2 2005/10/24 22:32:19 cperciva Exp 
$
# $DragonFly: src/usr.bin/alias/generic.sh,v 1.3 2007/08/05 16:09:50 pavalos 
Exp $
# This file is in the public domain.
builtin ${0##*/} ${1+"$@"}


And in every shell:


$ tcsh
$ which jobs
jobs: shell built-in command.
$ sh
$ which jobs
/usr/bin/jobs
$ bash
$ which jobs
/usr/bin/jobs



Now if you run the testjobs.sh in different shells, you might get different 
results, bash and sh behaving the same way:


$ sh testjobs.sh 
[1] + 814254 Running  
$ csh testjobs.sh 
[1] 814260
[1]  + 814260 Running   sleep 30


Even in Solaris there is a @@ with the job listing, so I'd 
rather have not output at all.

If further comments are needed, let us know, otherwise we will close this issue.


Bug #1397: jobs -l output inconsistency when called from script
http://bugs.dragonflybsd.org/issues/1397#change-14257

* Author: Anonymous
* Status: Feedback
* Priority: Normal
* Assignee: tuxillo
* Target version: 6.4

Salute.

The jobs(1) utility gives different output when called from a script and when
from an interactive shell.


[beket@voyager ~] cat testjobs.sh
#!/bin/sh
sleep 30 &
jobs -l
[beket@voyager ~] sh testjobs.sh 
[1] + 10005 Running   
[beket@voyager ~] sleep 30 &
[1] 10006
[beket@voyager ~] jobs -l
[1]+ 10006 Running sleep 30 &
[beket@voyager ~] 


It is not clear whether the jobs(1) should work at all inside a script. POSIX
says that since it doesn't fall into the 'special' built-in category a new
environment (subshell?) would be created upon its invocation. Even this is true,
the jobs aren't specific to the shell environment, so they should be visible to
jobs(1). And in any case, the command should either print nothing or print all
the fields.

NetBSD 5.0:

$ sh testjobs.sh 
[1] + 27159 Running   sleep 30


SunOS 5.10:

tuxillo@solaris$ /usr/xpg4/bin/sh testjobs.sh 
[1] + 11754  Running 


FreeBSD: same as us. (kindly reported by vstemen at #dragonflybsd).

Any thoughts ?

Best regards,
Stathis



-- 
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