[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 == &curthread->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 1340

[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 145

[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