Re: mariadb/percona cluster choices
Hi, On Sun, Jun 5, 2016 at 9:05 PM, Aristedes Maniatis <a...@ish.com.au> wrote: > Does anyone have recommendations or experience migrating away from MySQL > toward either MariaDB or Percona? > > I'm not looking for a discussion about the products themselves; there is > plenty on the internet to read about that. But I'm interested in stability > and support on FreeBSD. None of mysql, percona or mariadb have anything but > a fleeting reference to FreeBSD on their sites. And the FreeBSD ports > appear to have a roughly equal set of patches [1] [2] [3], so it doesn't > appear that any of them have upstreamed patches or perform their own > testing on FreeBSD. > > I'm looking to adopt Galera for clustering. Is there anything to recommend > one over the other with regard to stability on BSD? Do either of Maria I have tried Galera with MariaDB couple of months ago: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208109 Please let me know how it works if you try. thanks, Ganbold > or Percona have a stronger involvement with the FreeBSD community? I know > Oracle isn't big on community :-( > > > Cheers > Ari > > > > [1] > https://reviews.freebsd.org/diffusion/P/browse/head/databases/mysql57-server/files/ > [2] > https://reviews.freebsd.org/diffusion/P/browse/head/databases/percona56-server/files/ > [3] > https://reviews.freebsd.org/diffusion/P/browse/head/databases/mariadb101-server/files/ > > > -- > --> > Aristedes Maniatis > CEO, ish > https://www.ish.com.au > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Hacked - FreeBSD 7.1-Release
Squirrel wrote: I do have most of measure you've mentioned implemented. There is one website that is required to have register_global, which I have set on his directory/.htaccess to prevent site-wide. Currently, I'm in process of upgrading all my ports. Don't forget to check vulnerable php codes for SQL injection, LFI/RFI, problematic file uploads etc. Ganbold Thanks for info. -Original message- From: Matthew Seaman m.sea...@infracaninophile.co.uk Date: Thu, 10 Dec 2009 02:24:34 -0600 To: squir...@isot.com Subject: Re: Hacked - FreeBSD 7.1-Release Squirrel wrote: I've just finished the rtld patch. Now in process of regenerating all the keys and certs. Next will look into php. But far as rtld vulnerability, doesn't it require at least a local user account? Looking at all the authentication, there wasn't any authenticated session during the time frame. So I'm leaning more towards php 5.2.9, and checking all my ports. You don't necessarily need to have a login session (ie. recorded in wtmp) to exploit the rtld bug -- just control over some process and the ability to run commands through it. Although the rtld bug is only a local root compromise, since it is so simple to exploit it is a lot more dangerous than most, and in combination with just about any form of remote exploit it means your box get rooted. Upgrading PHP and all ports is a good move. portaudit(1) is a good idea but it doesn't necessarily address the direct route your attackers used_ My suspicions (in the absence of any detailed forensic examination of your machine) are that you are running some vulnerable PHP code. This may be part of a well known application, or it may be something locally written. In this case, I'd recommend a number of measures: * Run a security scanner like nikto (ports: security/nikto) against each of the websites on your server. Do this at regular intervals, and take action to fix any problems it discovers. * Make sure that you only grant the minimum necessary permissions on the filesystem to allow apache to run your applications. In general, everything under your doc root should be *readable* by uid www but not *writable* -- don't be seduced by the idea of making the webroot owned by www:www --- root:wheel is a much better idea, and files should be mode 644, directories mode 755 unless there's a good reason to have them otherwise. * Refuse to run any PHP application that requires you to have 'register_globals = YES' or to similarly poke enormous holes in security through php.ini. Any application developer that has not modified their code to use the $GLOBALS array by now is lazy and incompetent and their code is likely to have all sorts of other holes. * Similarly give your web application only the minimum necessary permissions it needs to access any databases. You'll frequently see instructions to do things like: 'GRANT ALL PRIVILEGES ON foo.* TO w...@localhost WITH GRANT OPTION;' This is way too much and should be trimmed down. Web apps rarely have any need to make schema changes, and creating other UIDs is right out, so 'GRANT SELECT,INSERT,UPDATE,DELETE ON foo.* TO w...@localhost' is a much more reasonable starting point. * Where a web application has a legitimate reason to want to write to the filesystem (eg. uploading files), preferably confine the write access to a separate directory tree outside the web root -- /tmp or /var/tmp aren't bad choices, but it might be better to create a specific location for a particular application. * Where a web application has an administrative mode preferably arrange to run this over HTTPS thus protecting any passwords from snooping. If the administrative mode needs to have generic read/write access to the web tree, then consider running it in a completely separate Apache instance with different user credentials than the generally accessible web server. Making the last point work with some arbitrary web application is frequently challenging, but usually at least possible by a combination of mod_rewrite and mod_proxy functions in the Apache config. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- I'm glad that I'm an American, I'm glad that I am free, But I wish I were a little doggy, And McGovern
Re: ZFS Panic
Cy Schubert wrote: I got this panic after issuing reboot(8). FreeBSD 7.1-STABLE FreeBSD 7.1-STABLE #0: Tue Feb 17 19:29:23 PST 2009 c...@cwsys:/export/obj/export/home/cy/test/test-stable7/sys/DEBUG i386 FreeBSD/i386 (bob) (ttyd0) login: Feb 17 21:22:56 bob reboot: rebooted by root Feb 17 21:22:56 bob syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 2 2 2 1 1 1 1 0 0 0 0 0 0 done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done All buffers synced. panic: insmntque() failed: error 16 cpuid = 0 KDB: enter: panic [thread pid 1086 tid 100090 ] Stopped at kdb_enter_why+0x3a: movl$0,kdb_why db bt Tracing pid 1086 tid 100090 td 0xc2bfd230 kdb_enter_why(c087ef4a,c087ef4a,c2b1b5b4,ebf8da58,0,...) at kdb_enter_why+0x3a panic(c2b1b5b4,10,c2b24a40,ebf8da64,c38e6000,...) at panic+0x136 gfs_file_create(84,c346d8a0,c342d5a0,c2b24a40,c346d8a0,...) at gfs_file_create+0x86 gfs_dir_create(84,c346d8a0,c342d5a0,c2b24a40,0,...) at gfs_dir_create+0x2c zfsctl_mknode_snapdir(c346d8a0,c2b1b54f,275,25d,c3419520,...) at zfsctl_mknode_snapdir+0x53 gfs_dir_lookup(c346d8a0,c2b21126,ebf8db74,c091521c,ebf8db38,...) at gfs_dir_lookup+0xd1 zfsctl_root_lookup(c346d8a0,c2b21126,ebf8db74,0,0,...) at zfsctl_root_lookup+0xdc zfsctl_umount_snapshots(c342d5a0,8,c3acb800,c3216844,0,...) at zfsctl_umount_snapshots+0x4e zfs_umount(c342d5a0,8,c2bfd230,c2bfd230,c088a687,...) at zfs_umount+0x53 dounmount(c342d5a0,8,c2bfd230,e26988ac,0,...) at dounmount+0x430 vfs_unmountall(c087ed87,0,c087edeb,128,0,...) at vfs_unmountall+0x4e boot(c090b5d0,0,c087edeb,ab,ebf8dd2c,...) at boot+0x44f reboot(c2bfd230,ebf8dcfc,4,c0885aef,c08c38a8,...) at reboot+0x4b syscall(ebf8dd38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x280bc947, esp = 0xbfbfeb7c, ebp = 0xbfbfebb8 --- db Forceably unmounting ZFS filesystems prior to issuing reboot(8) mitigates the panic. I have experienced ZFS related panic with RELEN_7 in November last year and got a fix from k...@. But I'm not quite sure whether yours and mine are the same case, but might help following patch (for /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_kobj.c and /usr/src/sys/cddl/compat/opensolaris/sys/vnode.h): http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046752.html Ganbold -- I was the best I ever had. -- Woody Allen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: lenovo t400 does not start 7.1
Harald Servat wrote: However, let me tell you what I've found now (I tried these options in the following order). ** a) I've started with option 2 (ACPI disabled) because I read somewhere that FreeBSD did not support Lenovo T400's ACPI. The system boots and freezes after showing (something related with Timecounters) md0: Preloaded image /boot/mfsroot 4194304 bytes at some address Trying to mount root from ufs:/dev/md0 b) When I chose option Safe mode (3, IIRC) Happens the same as a) c) I've tried with verbose logging (option 5, I think) The initialization dumps a lot of debugging information and after some time, it brings me the Choosing region screen. I didn't get further because I will not install the system right now (I have to prepare the backups first ;) ) I tried to use ScrollLock + RePag to look for the conflicting line found in a) or any suspicious message but it didn't work. I also tried with an holographic shell and the livefs without luck. d) I also tried option 1 (default boot) -- just in order to check. It also worked. Like c) but without debugging information. ** So, right now, it seems that the system allows me to begin the installation of FreeBSD 7.1 amd64 on the T400 but I'm scared due to the lack of functionality of options 2 and 3. This behavior is not normal, is it? Any thoughts about this? I'm using Integrated graphics right now, didn't try option 2,3. I have to find firewire cable to check whether there is something going on when booting with Discrete graphics. You can install FreeBSD with integrated graphics and configure network, ssh etc. and then later try to boot with Discrete graphics. As boot screen stops with |, and as kib@ suggests some time later you can check the machine from the network whether you can login to it via ssh. Also you can try to ping at that time. You can also observe hard disk activity light. If you can ping or ssh then I guess it means boot works and it loads kernel, but something is not allowing to display on the screen. Ganbold -- BACHELOR: A guy who is footloose and fiancee-free. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: lenovo t400 does not start 7.1
Harald Servat wrote: Hello, I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with correct SHA256 checksum), but I'm unable to start the system (Lenovo T400). The boot process starts fine, the BTX messages appear, the 7-option menu also appears, but when I hit enter (or when I choose start without ACPI or start in safe mode) the \ symbols starts spinning for a while and then freezes. I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of 8.0-CURRENT dated from December. And the result is the same for all of them. Does anyone have any idea on what can be happening? Or at least, how can I gather more information about this issue? Please try setting Integrated Graphics or Switchable Graphics mode on Display setting in BIOS. AFAICT it is known issue and FreeBSD doesn't boot when set to Discrete Graphics in BIOS. Ganbold Thank you. -- Too often I find that the volume of paper expands to fill the available briefcases. -- Governor Jerry Brown ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: lenovo t400 does not start 7.1
Ganbold wrote: Harald Servat wrote: Hello, I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with correct SHA256 checksum), but I'm unable to start the system (Lenovo T400). The boot process starts fine, the BTX messages appear, the 7-option menu also appears, but when I hit enter (or when I choose start without ACPI or start in safe mode) the \ symbols starts spinning for a while and then freezes. I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of 8.0-CURRENT dated from December. And the result is the same for all of them. Does anyone have any idea on what can be happening? Or at least, how can I gather more information about this issue? Please try setting Integrated Graphics or Switchable Graphics mode on Display setting in BIOS. AFAICT it is known issue and FreeBSD doesn't boot when set to Discrete Graphics in BIOS. Or maybe it boots but nothing shows on screen. Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: shutdown -p now crashes
Ganbold wrote:
(kgdb) p *fsrootvp
$3 = {v_type = VDIR, v_tag = 0xc0864e51 ufs, v_op = 0xc0926280,
v_data = 0xc3e5d000, v_mount = 0xc3e56b30, v_nmntvnodes = {tqe_next =
0xc3d119b4,
tqe_prev = 0xc3e56b98}, v_un = {vu_mount = 0x0, vu_socket = 0x0,
vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = {le_next
= 0x0,
le_prev = 0xc3d09da0}, v_hash = 2, v_cache_src = {lh_first = 0x0},
v_cache_dst = {tqh_first = 0x0, tqh_last = 0xc3d11af8}, v_dd = 0x0,
v_cstart = 0,
v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lk_object = {lo_name
= 0xc0864e51 ufs, lo_type = 0xc0864e51 ufs, lo_flags = 70844416,
lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness =
0x0}}, lk_interlock = 0xc0956510, lk_flags = 262208, lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_timo =
51, lk_lockholder = 0xc3b31d20, lk_newlock = 0x0}, v_interlock =
{lock_object = {
lo_name = 0xc086fb51 vnode interlock, lo_type = 0xc086fb51
vnode interlock, lo_flags = 16973824, lo_witness_data = {lod_list =
{stqe_next = 0x0},
lod_witness = 0x0}}, mtx_lock = 3283295520, mtx_recurse = 0},
v_vnlock = 0xc3d11b20, v_holdcnt = 2, v_usecount = 0, v_iflag = 0,
v_vflag = 1,
v_writecount = 0, v_freelist = {tqe_next = 0x0, tqe_prev = 0x0},
v_bufobj = {bo_mtx = 0xc3d11b50, bo_clean = {bv_hd = {tqh_first =
0xe3d02594,
tqh_last = 0xe3d025cc}, bv_root = 0xe3d02594, bv_cnt = 1},
bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xc3d11b9c}, bv_root
= 0x0,
bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xc091ae00,
bo_bsize = 16384, bo_object = 0xc106183c, bo_synclist = {le_next = 0x0,
le_prev = 0x0}, bo_private = 0xc3d11ac8, __bo_vnode =
0xc3d11ac8}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0}
(kgdb) p rootvnode
$4 = (struct vnode *) 0x0
(kgdb) p *rootvnode
Cannot access memory at address 0x0
(kgdb)
Konstantin,
I have tried your patch. It seems like it is working, tried shutdown -p
now
2 times and my RELENG_7 didn't crash after using zfs/geli external HDD
via USB.
Attached patches are for RELENG_7 (small modifications made in order to
apply to RELENG_7).
thanks a lot,
Ganbold
--
If you think education is expensive, try ignorance. -- Derek Bok,
president of Harvard
--- opensolaris_kobj.c~ 2008-04-17 09:23:29.0 +0800
+++ opensolaris_kobj.c 2008-11-24 14:28:01.0 +0800
@@ -67,17 +67,25 @@
kobj_open_file_vnode(const char *file)
{
struct thread *td = curthread;
+ struct filedesc *fd;
struct nameidata nd;
int error, flags;
- if (td-td_proc-p_fd-fd_rdir == NULL)
- td-td_proc-p_fd-fd_rdir = rootvnode;
- if (td-td_proc-p_fd-fd_cdir == NULL)
- td-td_proc-p_fd-fd_cdir = rootvnode;
+ fd = td-td_proc-p_fd;
+ FILEDESC_XLOCK(fd);
+ if (fd-fd_rdir == NULL) {
+ fd-fd_rdir = rootvnode;
+ vref(fd-fd_rdir);
+ }
+ if (fd-fd_cdir == NULL) {
+ fd-fd_cdir = rootvnode;
+ vref(fd-fd_cdir);
+ }
+ FILEDESC_XUNLOCK(fd);
flags = FREAD;
- NDINIT(nd, LOOKUP, NOFOLLOW, UIO_SYSSPACE, file, td);
- error = vn_open_cred(nd, flags, 0, td-td_ucred, NULL);
+ NDINIT(nd, LOOKUP, MPSAFE, UIO_SYSSPACE, file, td);
+ error = vn_open_cred(nd, flags, O_NOFOLLOW, td-td_ucred, NULL);
NDFREE(nd, NDF_ONLY_PNBUF);
if (error != 0)
return (NULL);
@@ -122,12 +130,15 @@
struct thread *td = curthread;
struct vattr va;
int error;
-
+ int vfslocked;
+
+ vfslocked = VFS_LOCK_GIANT(vp-v_mount);
vn_lock(vp, LK_SHARED | LK_RETRY, td);
error = VOP_GETATTR(vp, va, td-td_ucred, td);
VOP_UNLOCK(vp, 0, td);
if (error == 0)
*size = (uint64_t)va.va_size;
+ VFS_UNLOCK_GIANT(vfslocked);
return (error);
}
@@ -161,6 +172,7 @@
struct uio auio;
struct iovec aiov;
int error;
+ int vfslocked;
bzero(aiov, sizeof(aiov));
bzero(auio, sizeof(auio));
@@ -176,9 +188,11 @@
auio.uio_resid = size;
auio.uio_td = td;
+ vfslocked = VFS_LOCK_GIANT(vp-v_mount);
vn_lock(vp, LK_SHARED | LK_RETRY, td);
error = VOP_READ(vp, auio, IO_UNIT | IO_SYNC, td-td_ucred);
VOP_UNLOCK(vp, 0, td);
+ VFS_UNLOCK_GIANT(vfslocked);
return (error != 0 ? -1 : size - auio.uio_resid);
}
@@ -213,8 +227,11 @@
struct vnode *vp = file-ptr;
struct thread *td = curthread;
int flags = FREAD;
-
+ int vfslocked;
+
+ vfslocked = VFS_LOCK_GIANT(vp-v_mount);
vn_close(vp, flags, td-td_ucred, td);
+ VFS_UNLOCK_GIANT(vfslocked);
}
kmem_free(file, sizeof(*file));
}
--- vnode.h~2008-04-17 09:23:30.0 +0800
+++ vnode.h 2008-11-24 14:33:13.0 +0800
@@ -156,6 +156,7
Re: shutdown -p now crashes
Ganbold wrote: #3 0xc06ab8b3 in vput (vp=0xc3d11ac8) at /usr/src/sys/kern/vfs_subr.c:2202 #4 0xc06a69e6 in dounmount (mp=0xc3e59b30, flags=524288, td=0xc3b31d20) at /usr/src/sys/kern/vfs_mount.c:1288 #5 0xc06aa493 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2939 #6 0xc062b7f4 in boot (howto=16392) at /usr/src/sys/kern/kern_shutdown.c:400 #7 0xc062bc17 in reboot (td=0xc3b31d20, uap=0xeef55cfc) at /usr/src/sys/kern/kern_shutdown.c:172 #8 0xc08171f5 in syscall (frame=0xeef55d38) at /usr/src/sys/i386/i386/trap.c:1090 #9 0xc07fd710 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #10 0x0033 in ?? () (kgdb) .. I was able to reproduce the panic. I plugged in external ZFS/GELI HDD via USB and used 'zpool import' to import disk and did some 'ls' and then used 'zpool export' to umount disk. Then I detached the disk from desktop and tried to shutdown -p now. This way panic is reproduced 2 times. More info: daemon% uname -an FreeBSD daemon.micom.mng.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #8 r185085M: Thu Nov 20 12:50:33 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 daemon% 118. 118Writing entropy file: 118. 118Terminated 118. 118Nov 20 14:30:12 daemon syslogd: exiting on signal 15 rootvp 0xc3d11ac8 v_usecount 2 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,2,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8b6 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8c3 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 1 0 0 done All buffers synced. rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55ba8,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,c3b31d20,eef55ba8,...) at kdb_backtrace+0x29 vrele(c3d11ac8,2,eef55bf0,c3b31d20,0,...) at vrele+0x83 dounmount(c3e56b30,8,c3b31d20,e3b61aec,0,...) at dounmount+0x491 vfs_unmountall(c0869007,0,c086906b,117,eef55c50,...) at vfs_unmountall+0x33 boot(c3b31d20,8,0,fffe,c3b31d20,...) at boot+0x444 reboot(c3b31d20,eef55cfc,4,8048290,9e7c9054,...) at reboot+0x67 syscall(eef55d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050bb3, esp = 0xbfbfe8ec, ebp = 0xbfbfe9b8 --- panic: vput: negative ref cnt cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55b68,c062bd39,c08832ea,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08832ea,0,c086fac1,eef55b74,0,...) at kdb_backtrace+0x29 panic(c086fac1,eef55ba8,c06abcd0,c3d11ac8,eef55b90,...) at panic+0x119 vput(c3d11ac8,2,eef55bf0,c3b31d20,0,...) at vput+0xf3 dounmount(c3e56b30,8,c3b31d20,e3b61aec,0,...) at dounmount+0x4a6 vfs_unmountall(c0869007,0,c086906b,117,eef55c50,...) at vfs_unmountall+0x33 boot(c3b31d20,8,0,fffe,c3b31d20,...) at boot+0x444 reboot(c3b31d20,eef55cfc,4,8048290,9e7c9054,...) at reboot+0x67 syscall(eef55d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050bb3, esp = 0xbfbfe8ec, ebp = 0xbfbfe9b8 --- Uptime: 7m3s Physical memory: 1013 MB Dumping 54 MB: 39 23 7 (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc062ba67 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc062bd72 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc06ab8e3 in vput (vp=0xc3d11ac8) at /usr/src/sys/kern/vfs_subr.c:2211 #4 0xc06a69e6 in dounmount (mp=0xc3e56b30, flags=524288, td=0xc3b31d20) at /usr/src/sys/kern/vfs_mount.c:1288 #5 0xc06aa493 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2948 #6 0xc062b7f4 in boot (howto=16392) at /usr/src/sys/kern
Re: shutdown -p now crashes
Jeremy Chadwick wrote: On Thu, Nov 20, 2008 at 02:50:46PM +0800, Ganbold wrote: Ganbold wrote: #3 0xc06ab8b3 in vput (vp=0xc3d11ac8) at /usr/src/sys/kern/vfs_subr.c:2202 #4 0xc06a69e6 in dounmount (mp=0xc3e59b30, flags=524288, td=0xc3b31d20) at /usr/src/sys/kern/vfs_mount.c:1288 #5 0xc06aa493 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2939 #6 0xc062b7f4 in boot (howto=16392) at /usr/src/sys/kern/kern_shutdown.c:400 #7 0xc062bc17 in reboot (td=0xc3b31d20, uap=0xeef55cfc) at /usr/src/sys/kern/kern_shutdown.c:172 #8 0xc08171f5 in syscall (frame=0xeef55d38) at /usr/src/sys/i386/i386/trap.c:1090 #9 0xc07fd710 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #10 0x0033 in ?? () (kgdb) .. I was able to reproduce the panic. I plugged in external ZFS/GELI HDD via USB and used 'zpool import' to import disk and did some 'ls' and then used 'zpool export' to umount disk. Then I detached the disk from desktop and tried to shutdown -p now. This way panic is reproduced 2 times. Are we sure that the problem isn't the well-known do not yank a device out from underneathe the rest of the OS problem, e.g. removing removable devices while filesystems are still mounted? If so, this problem is very well-known, documented on my Wiki, and work is being done in CURRENT to fix it (official ETA is 2009/02). I see geli(8) has a detach option, which you might need to do after the zpool export, being as the GEOM provider is still attached to the USB HDD. I would recommend trying that first. Thanks for suggestion :) In my zfs_mount and zfs_umount scripts I have: zfs_mount.sh #!/bin/sh geli attach -k /root/da0.key /dev/da0s1e zpool import tank1 zpool import tank2 zfs_umount.sh #!/bin/sh zpool export tank1 zpool export tank2 geli detach da0s1e.eli I hope that answers what you meant :) Ganbold More info: daemon% uname -an FreeBSD daemon.micom.mng.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #8 r185085M: Thu Nov 20 12:50:33 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 daemon% 118. 118Writing entropy file: 118. 118Terminated 118. 118Nov 20 14:30:12 daemon syslogd: exiting on signal 15 rootvp 0xc3d11ac8 v_usecount 2 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,2,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8b6 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8c3 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 1 0 0 done All buffers synced. rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55ba8,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,c3b31d20,eef55ba8,...) at kdb_backtrace+0x29 vrele(c3d11ac8,2,eef55bf0,c3b31d20,0,...) at vrele+0x83 dounmount(c3e56b30,8,c3b31d20,e3b61aec,0,...) at dounmount+0x491 vfs_unmountall(c0869007,0,c086906b,117,eef55c50,...) at vfs_unmountall+0x33 boot(c3b31d20,8,0,fffe,c3b31d20,...) at boot+0x444 reboot(c3b31d20,eef55cfc,4,8048290,9e7c9054,...) at reboot+0x67 syscall(eef55d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050bb3, esp = 0xbfbfe8ec, ebp = 0xbfbfe9b8 --- panic: vput: negative ref cnt cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55b68,c062bd39,c08832ea,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08832ea,0,c086fac1,eef55b74,0,...) at kdb_backtrace+0x29 panic(c086fac1,eef55ba8,c06abcd0,c3d11ac8,eef55b90,...) at panic+0x119 vput(c3d11ac8,2,eef55bf0,c3b31d20,0,...) at vput+0xf3 dounmount(c3e56b30,8,c3b31d20,e3b61aec,0,...) at dounmount+0x4a6 vfs_unmountall(c0869007,0,c086906b
shutdown -p now crashes
Hi, Few hours ago I have updated my machine to latest RELENG_7. daemon% uname -an FreeBSD daemon.micom.mng.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #6: Tue Nov 18 02:05:57 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 daemon% When I try to issue command shutdown -p now, system paniced. ... (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc062ba67 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc062bd72 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc06ab8b3 in vput (vp=0xc3d11ac8) at /usr/src/sys/kern/vfs_subr.c:2202 #4 0xc06a69e6 in dounmount (mp=0xc3e59b30, flags=524288, td=0xc3b31d20) at /usr/src/sys/kern/vfs_mount.c:1288 #5 0xc06aa493 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2939 #6 0xc062b7f4 in boot (howto=16392) at /usr/src/sys/kern/kern_shutdown.c:400 #7 0xc062bc17 in reboot (td=0xc3b31d20, uap=0xeef55cfc) at /usr/src/sys/kern/kern_shutdown.c:172 #8 0xc08171f5 in syscall (frame=0xeef55d38) at /usr/src/sys/i386/i386/trap.c:1090 #9 0xc07fd710 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #10 0x0033 in ?? () (kgdb) ... Is this known issue? thanks, Ganbold -- Yeah, but you're taking the universe out of context. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFC of em/igb drivers
Jack Vogel wrote: I got the new drivers in Friday afternoon for those that don't see CVS messages. The igb driver is for 82575 and 82576 adapters, it has multiqueue support and MSIX, there will be more server type enhancements in that driver as I get the time. The em driver now will be client oriented, the latest hardware support however is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, that actually also has MSIX. This first released support for it will use 3 interrupt vectors, one for TX, one for RX, and Link. The hardware actually supports 5 vectors, so I am planning to add support for another RX and TX queue as my schedule allows. Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver provides init and an ioctl interface to use that facility, I hope we see software support follow on soon. This is an early announcement, I am not sure on exact dates for availability but they should be soon. As ever, issues and bugs should be sent to me. Cheers everyone! Jack Jack, I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: ... [EMAIL PROTECTED]:0:25:0:class=0x02 card=0x2800103c chip=0x104a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM Gigabit Network Connection' class = network subclass = ethernet ... # uname -an FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 11:12:34 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIREWALL i386 It has some problem, 1000baseTX connection status almost never goes to active in bridged mode, sometimes it goes to active but then immediately it goes to no carrier. (The other end is Cisco4507R, Gigabit Ethernet port) ... em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=198VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:0f:fe:82:23:db media: Ethernet 1000baseTX full-duplex (autoselect) status: no carrier ... Any idea how to solve this issue? thanks, Ganbold ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] -- Q: How many pre-med's does it take to change a lightbulb? A: Five: One to change the bulb and four to pull the ladder out from under him. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFC of em/igb drivers
Jeremy Chadwick wrote: On Fri, Jun 06, 2008 at 03:49:40PM +0800, Ganbold wrote: Jack Vogel wrote: I got the new drivers in Friday afternoon for those that don't see CVS messages. The igb driver is for 82575 and 82576 adapters, it has multiqueue support and MSIX, there will be more server type enhancements in that driver as I get the time. The em driver now will be client oriented, the latest hardware support however is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, that actually also has MSIX. This first released support for it will use 3 interrupt vectors, one for TX, one for RX, and Link. The hardware actually supports 5 vectors, so I am planning to add support for another RX and TX queue as my schedule allows. Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver provides init and an ioctl interface to use that facility, I hope we see software support follow on soon. This is an early announcement, I am not sure on exact dates for availability but they should be soon. As ever, issues and bugs should be sent to me. Cheers everyone! I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: ... [EMAIL PROTECTED]:0:25:0:class=0x02 card=0x2800103c chip=0x104a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM Gigabit Network Connection' class = network subclass = ethernet ... # uname -an FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 11:12:34 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIREWALL i386 It has some problem, 1000baseTX connection status almost never goes to active in bridged mode, sometimes it goes to active but then immediately it goes to no carrier. (The other end is Cisco4507R, Gigabit Ethernet port) ... em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=198VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:0f:fe:82:23:db media: Ethernet 1000baseTX full-duplex (autoselect) status: no carrier ... Any idea how to solve this issue? Have you tried disabling speed and duplex negotiation and explicitly stating speed and duplex like so? ifconfig_em0=... media 1000baseTX mediaopt full-duplex I tried it and it doesn't work. Cisco switches have a notorious history of not being friendly with non-Cisco hardware. Forcing duplex on both ends of the link (that means on both the host side, and the Cisco side!) usually fixes it. Tried too, doesn't work. Ganbold -- Life is too important to take seriously. -- Corky Siegel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fusefs-ntfs makes fatal trap/page fault in FreeBSD-7.0
More information: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address= 0x746e756f fault code= supervisor read, page not present instruction pointer= 0x20:0xc06d8f46 stack pointer= 0x28:0xe64189b0 frame pointer= 0x28:0xe64189b4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process= 843 (mount_fusefs) panic: from debugger cpuid = 0 KDB: stack backtrace: Uptime: 1m34s Physical memory: 1006 MB Dumping 56 MB: 41 25 9 #0 doadump () at pcpu.h:195 195pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:195 #1 0xc064f4fe in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc064f7bb in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0465d47 in db_panic (addr=Could not find the frame base for db_panic. ) at /usr/src/sys/ddb/db_command.c:433 #4 0xc0466735 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #5 0xc0467ea5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #6 0xc0676b06 in kdb_trap (type=12, code=0, tf=0xe6418970) at /usr/src/sys/kern/subr_kdb.c:502 #7 0xc085528f in trap_fatal (frame=0xe6418970, eva=1953396079) at /usr/src/sys/i386/i386/trap.c:890 #8 0xc08554b0 in trap_pfault (frame=0xe6418970, usermode=0, eva=1953396079) at /usr/src/sys/i386/i386/trap.c:812 #9 0xc0855e52 in trap (frame=0xe6418970) at /usr/src/sys/i386/i386/trap.c:490 #10 0xc083c36b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #11 0xc06d8f46 in strcmp (s1=0xc432044f fspath, s2=0x746e756f Address 0x746e756f out of bounds) at /usr/src/sys/libkern/strcmp.c:45 #12 0xc06c0865 in vfs_getopt (opts=0xc09bb700, name=0xc432044f fspath, buf=0x0, len=0x0) at /usr/src/sys/kern/vfs_mount.c:1869 #13 0xc4319380 in ?? () #14 0xc09bb700 in w_data () #15 0xc432044f in ?? () #16 0x in ?? () #17 0x in ?? () #18 0xc43df210 in ?? () #19 0xc43df210 in ?? () #20 0xc09b1db0 in w_lock_list_free () #21 0xc43df210 in ?? () #22 0xe6418a00 in ?? () #23 0x0246 in ?? () #24 0xc09b1db0 in w_lock_list_free () #25 0xe6418a1c in ?? () #26 0xc064279d in _mtx_unlock_spin_flags (m=0xc3e5707c, opts=-1002573296, file=0xc08d01ce /usr/src/sys/kern/vfs_mount.c, line=1001) at /usr/src/sys/kern/kern_mutex.c:246 #27 0xc06c34ad in vfs_donmount (td=0xc43df210, fsflags=0, fsoptions=0xc439c900) at /usr/src/sys/kern/vfs_mount.c:1007 #28 0xc06c47a2 in nmount (td=0xc43df210, uap=0xe6418cfc) at /usr/src/sys/kern/vfs_mount.c:416 #29 0xc0855783 in syscall (frame=0xe6418d38) at /usr/src/sys/i386/i386/trap.c:1035 #30 0xc083c3d0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #31 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Ganbold wrote: Hi, I'm having trouble mounting external NTFS hard drive using fusefs-ntfs port on Dell Latitude D620. devil# uname -an FreeBSD devil.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #3: Tue Feb 5 10:29:24 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 devil# pkg_info | grep fuse fusefs-kmod-0.3.9.p1_3 Kernel module for fuse fusefs-libs-2.7.2 FUSE allows filesystem implementation in userspace fusefs-ntfs-1.1120 Mount NTFS partitions (read/write) and disk images devil# kldload /usr/local/modules/fuse.ko devil# kldstat Id Refs AddressSize Name 1 23 0xc040 6df8b4 kernel 21 0xc0ae 14324snd_hda.ko 32 0xc0af5000 52a08sound.ko 42 0xc0b48000 10ebcdrm.ko 51 0xc0b59000 7184 i915.ko 61 0xc0b61000 6b314acpi.ko 72 0xc4005000 c000 ipfw.ko 81 0xc4035000 4000 ipdivert.ko 91 0xc406d000 22000linux.ko 113 0xc43dd000 3000 ucom.ko 121 0xc43e 3000 uftdi.ko 131 0xc43e5000 4000 uplcom.ko 141 0xc59aa000 e000 fuse.ko When I try to mount it, on serial console I see: .. umass0: Seagate FreeAgent Go, class 0/0, rev 2.00/0.00, addr 2 on uhub4 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Seagate FreeAgent Go 100F Fixed Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 1 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): ABORTED COMMAND asc:0,0 (da0:umass-sim0:0:0:0): No additional sense information (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 1 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): ABORTED COMMAND asc:0,0 (da0:umass-sim0:0:0:0): No additional sense information (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) GEOM_LABEL: Label
Re: panic: resource_list_release: resource entry is not busy in FreeBSD-7.0
More information: Unread portion of the kernel message buffer: panic: resource_list_release: resource entry is not busy cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c08c8071,e40bebb8,c064f78f,c08ec0ac,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ec0ac,0,c08c7b77,e40bebc4,0,...) at kdb_backtrace+0x29 panic(c08c7b77,3,10,0,c3c6ce40,...) at panic+0x10f resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at resource_list_release+0xc2 bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at bus_generic_rl_release_resource+0x77 bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at bus_release_resource+0x67 ath_pci_detach(c3c92e00,c3b41050,c095ba6c,970,4,...) at ath_pci_detach+0xb2 device_detach(c3c92e00,e40becac,e40becb0,c09aad30,0,...) at device_detach+0x8c cardbus_detach_card(c3c46100,c3b9c8b4,c091b0bc,1df,c09ad2a0,...) at cardbus_detach_card+0xcd cbb_event_thread(c3bb1000,e40bed38,c08c1af7,305,c3c40ab0,...) at cbb_event_thread+0x15a fork_exit(c0556c60,c3bb1000,e40bed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 24s Physical memory: 1006 MB Dumping 55 MB: 40 24 8 #0 doadump () at pcpu.h:195 195pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:195 #1 0xc064f4fe in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc064f7bb in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0465d47 in db_panic (addr=Could not find the frame base for db_panic. ) at /usr/src/sys/ddb/db_command.c:433 #4 0xc0466735 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #5 0xc0467ea5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 #6 0xc0676b06 in kdb_trap (type=3, code=0, tf=0xe40beb44) at /usr/src/sys/kern/subr_kdb.c:502 #7 0xc0855fcf in trap (frame=0xe40beb44) at /usr/src/sys/i386/i386/trap.c:648 #8 0xc083c36b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #9 0xc0676c82 in kdb_enter (msg=0xc08c5574 panic) at cpufunc.h:60 #10 0xc064f7a4 in panic (fmt=0xc08c7b77 resource_list_release: resource entry is not busy) at /usr/src/sys/kern/kern_shutdown.c:547 #11 0xc06733b2 in resource_list_release (rl=0xc3c96204, bus=0xc3c46100, child=0xc3c92e00, type=3, rid=16, res=0xc3c6ce00) at /usr/src/sys/kern/subr_bus.c:2768 #12 0xc06734a7 in bus_generic_rl_release_resource (dev=0xc3c46100, child=0xc3c92e00, type=3, rid=16, r=0xc3c6ce00) at /usr/src/sys/kern/subr_bus.c:3319 #13 0xc0673057 in bus_release_resource (dev=0xc3c92e00, type=3, rid=16, r=0xc3c6ce00) at bus_if.h:347 #14 0xc04aad92 in ath_pci_detach (dev=0xc3c92e00) at /usr/src/sys/dev/ath/if_ath_pci.c:223 #15 0xc067166c in device_detach (dev=0xc3c92e00) at device_if.h:212 #16 0xc04c3cdd in cardbus_detach_card (cbdev=0xc3c46100) at /usr/src/sys/dev/cardbus/cardbus.c:236 #17 0xc0556dba in cbb_event_thread (arg=0xc3bb1000) at card_if.h:95 #18 0xc06302e8 in fork_exit (callout=0xc0556c60 cbb_event_thread, arg=0xc3bb1000, frame=0xe40bed38) at /usr/src/sys/kern/kern_fork.c:781 #19 0xc083c3e0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) Ganbold wrote: Hi, I'm having trouble using Orinoco Silver a/b/g combo pcmcia card on Dell Latitude D620. It happens in following order: 1. First I reboot FreeBSD-7.0 laptop with Orinoco combo card plugged in. 2. Then when I try to unplug the card it panics. However after rebooting (without plugged in card) when I try to plug in and unplug the card everything is fine, no crash. System I have: devil# uname -an FreeBSD devil.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #3: Tue Feb 5 10:29:24 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 When panics, on the serial console it shows: .. ath0: Atheros 5212 mem 0x8800-0x8800 irq 18 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:20:a6:4f:bf:7d ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 .. Tue Feb 5 11:52:45 ULAT 2008 .. panic: resource_list_release: resource entry is not busy cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c08c8051,e40bebb8,c064f78f,c08ec063,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ec063,0,c08c7b57,e40bebc4,0,...) at kdb_backtrace+0x29 panic(c08c7b57,3,10,0,c3c6ce40,...) at panic+0x10f resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at resource_list_release+0xc2 bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at bus_generic_rl_release_resource+0x77 bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at bus_release_resource+0x67 ath_pci_detach(c3c92e00,c3b41050,c095ba2c,970,4,...) at ath_pci_detach+0xb2 device_detach(c3c92e00,e40becac,e40becb0,c09aacf0,0,...) at device_detach+0x8c cardbus_detach_card(c3c46100,c3b9c8b4,c091b07c,1df,c09ad260,...) at cardbus_detach_card
fusefs-ntfs makes fatal trap/page fault in FreeBSD-7.0
Hi, I'm having trouble mounting external NTFS hard drive using fusefs-ntfs port on Dell Latitude D620. devil# uname -an FreeBSD devil.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #3: Tue Feb 5 10:29:24 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 devil# pkg_info | grep fuse fusefs-kmod-0.3.9.p1_3 Kernel module for fuse fusefs-libs-2.7.2 FUSE allows filesystem implementation in userspace fusefs-ntfs-1.1120 Mount NTFS partitions (read/write) and disk images devil# kldload /usr/local/modules/fuse.ko devil# kldstat Id Refs AddressSize Name 1 23 0xc040 6df8b4 kernel 21 0xc0ae 14324snd_hda.ko 32 0xc0af5000 52a08sound.ko 42 0xc0b48000 10ebcdrm.ko 51 0xc0b59000 7184 i915.ko 61 0xc0b61000 6b314acpi.ko 72 0xc4005000 c000 ipfw.ko 81 0xc4035000 4000 ipdivert.ko 91 0xc406d000 22000linux.ko 113 0xc43dd000 3000 ucom.ko 121 0xc43e 3000 uftdi.ko 131 0xc43e5000 4000 uplcom.ko 141 0xc59aa000 e000 fuse.ko When I try to mount it, on serial console I see: ... umass0: Seagate FreeAgent Go, class 0/0, rev 2.00/0.00, addr 2 on uhub4 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Seagate FreeAgent Go 100F Fixed Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 1 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): ABORTED COMMAND asc:0,0 (da0:umass-sim0:0:0:0): No additional sense information (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 1 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): ABORTED COMMAND asc:0,0 (da0:umass-sim0:0:0:0): No additional sense information (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) GEOM_LABEL: Label for provider da0s1 is ntfs/FreeAgent Drive. GEOM_LABEL: Label ntfs/FreeAgent Drive removed. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address= 0x746e756f fault code= supervisor read, page not present instruction pointer= 0x20:0xc06d8f36 stack pointer= 0x28:0xe63d09b0 frame pointer= 0x28:0xe63d09b4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process= 19197 (mount_fusefs) [thread pid 19197 tid 100099 ] Stopped at strcmp+0x26:movzbl 0(%ecx),%eax db bt Tracing pid 19197 tid 100099 td 0xc4312210 strcmp(c59b644f,746e756f,c3e43934,2d,e63d0a8c,...) at strcmp+0x26 vfs_getopt(c09bb6c0,c59b644f,0,0,c4312210,...) at vfs_getopt+0x35 fuse_mount(c3e438b8,c4312210,c08d0185,3e9,0,...) at fuse_mount+0x70 vfs_donmount(48217080,c,e63d0c70,c48e4000,bfbfebb4,...) at vfs_donmount+0x13ad nmount(c4312210,e63d0cfc,c,e63d0d38,c095e6d0,...) at nmount+0xb2 syscall(e63d0d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x480ccb4b, esp = 0xbfbfe64c, ebp = 0xbfbfebc8 --- db trace Tracing pid 19197 tid 100099 td 0xc4312210 strcmp(c59b644f,746e756f,c3e43934,2d,e63d0a8c,...) at strcmp+0x26 vfs_getopt(c09bb6c0,c59b644f,0,0,c4312210,...) at vfs_getopt+0x35 fuse_mount(c3e438b8,c4312210,c08d0185,3e9,0,...) at fuse_mount+0x70 vfs_donmount(48217080,c,e63d0c70,c48e4000,bfbfebb4,...) at vfs_donmount+0x13ad nmount(c4312210,e63d0cfc,c,e63d0d38,c095e6d0,...) at nmount+0xb2 syscall(e63d0d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x480ccb4b, esp = 0xbfbfe64c, ebp = 0xbfbfebc8 --- db Any idea how to solve this problem? thanks, Ganbold -- Real computer scientists don't program in assembler. They don't write in anything less portable than a number two pencil. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: resource_list_release: resource entry is not busy in FreeBSD-7.0
Hi, I'm having trouble using Orinoco Silver a/b/g combo pcmcia card on Dell Latitude D620. It happens in following order: 1. First I reboot FreeBSD-7.0 laptop with Orinoco combo card plugged in. 2. Then when I try to unplug the card it panics. However after rebooting (without plugged in card) when I try to plug in and unplug the card everything is fine, no crash. System I have: devil# uname -an FreeBSD devil.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #3: Tue Feb 5 10:29:24 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 When panics, on the serial console it shows: ... ath0: Atheros 5212 mem 0x8800-0x8800 irq 18 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:20:a6:4f:bf:7d ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 ... Tue Feb 5 11:52:45 ULAT 2008 ... panic: resource_list_release: resource entry is not busy cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c08c8051,e40bebb8,c064f78f,c08ec063,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ec063,0,c08c7b57,e40bebc4,0,...) at kdb_backtrace+0x29 panic(c08c7b57,3,10,0,c3c6ce40,...) at panic+0x10f resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at resource_list_release+0xc2 bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at bus_generic_rl_release_resource+0x77 bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at bus_release_resource+0x67 ath_pci_detach(c3c92e00,c3b41050,c095ba2c,970,4,...) at ath_pci_detach+0xb2 device_detach(c3c92e00,e40becac,e40becb0,c09aacf0,0,...) at device_detach+0x8c cardbus_detach_card(c3c46100,c3b9c8b4,c091b07c,1df,c09ad260,...) at cardbus_detach_card+0xcd cbb_event_thread(c3bb1000,e40bed38,c08c1ad7,305,c3c40ab0,...) at cbb_event_thread+0x15a fork_exit(c0556c60,c3bb1000,e40bed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- KDB: enter: panic [thread pid 36 tid 100035 ] Stopped at kdb_enter+0x32: leave db bt Tracing pid 36 tid 100035 td 0xc3c2a210 kdb_enter(c08c5554,0,c08c7b57,e40bebc4,0,...) at kdb_enter+0x32 panic(c08c7b57,3,10,0,c3c6ce40,...) at panic+0x124 resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at resource_list_release+0xc2 bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at bus_generic_rl_release_resource+0x77 bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at bus_release_resource+0x67 ath_pci_detach(c3c92e00,c3b41050,c095ba2c,970,4,...) at ath_pci_detach+0xb2 device_detach(c3c92e00,e40becac,e40becb0,c09aacf0,0,...) at device_detach+0x8c cardbus_detach_card(c3c46100,c3b9c8b4,c091b07c,1df,c09ad260,...) at cardbus_detach_card+0xcd cbb_event_thread(c3bb1000,e40bed38,c08c1ad7,305,c3c40ab0,...) at cbb_event_thread+0x15a fork_exit(c0556c60,c3bb1000,e40bed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- db tr Tracing pid 36 tid 100035 td 0xc3c2a210 kdb_enter(c08c5554,0,c08c7b57,e40bebc4,0,...) at kdb_enter+0x32 panic(c08c7b57,3,10,0,c3c6ce40,...) at panic+0x124 resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at resource_list_release+0xc2 bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at bus_generic_rl_release_resource+0x77 bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at bus_release_resource+0x67 ath_pci_detach(c3c92e00,c3b41050,c095ba2c,970,4,...) at ath_pci_detach+0xb2 device_detach(c3c92e00,e40becac,e40becb0,c09aacf0,0,...) at device_detach+0x8c cardbus_detach_card(c3c46100,c3b9c8b4,c091b07c,1df,c09ad260,...) at cardbus_detach_card+0xcd cbb_event_thread(c3bb1000,e40bed38,c08c1ad7,305,c3c40ab0,...) at cbb_event_thread+0x15a fork_exit(c0556c60,c3bb1000,e40bed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- db Any idea how to solve this problem? thanks, Ganbold -- We have only two things to worry about: That things will never get back to normal, and that they already have. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
/dev/cuad0: Device busy
Hi, I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down daemon# uname -an FreeBSD daemon.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: Mon Jan 14 16:49:57 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 It seems like no other program is using serial port. How to check whether something is using serial port? Any idea? thanks, Ganbold -- If you think the problem is bad now, just wait until we've solved it. -- Arthur Kasspe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
Daniel O'Connor wrote: On Mon, 4 Feb 2008, Ganbold wrote: I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down What does fstat /dev/cuad0 say? It says: daemon# fstat /dev/cuad0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME daemon# Ganbold -- We'll have solar energy when the power companies develop a sunbeam meter. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/cuad0: Device busy
Jeremy Chadwick wrote: On Mon, Feb 04, 2008 at 12:53:58PM +0800, Ganbold wrote: Hi, I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down Does the same happen if you do `cu -l ttyd0 -s 9600`? It works and fstat shows: daemon# fstat /dev/cuad0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME daemon# fstat /dev/ttyd0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root cu 55743 /dev 41 crw--- ttyd0 rw /dev/ttyd0 root cu 55733 /dev 41 crw--- ttyd0 rw /dev/ttyd0 daemon# Is it expected behaviour? thanks, Ganbold How to check whether something is using serial port? Any idea? fstat should help here. -- Success is in the minds of Fools. -- William Wrenshaw, 1578 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testing: patch that helps Wine on 6.x
000c0 000b0 0008 (D) C:\Program Files\Macromedia\Dreamweaver 8\Dreamweaver.exe 000d0 00090 == daemon% Any idea how to resolve this issue? Will the patch on http://bugs.winehq.org/show_bug.cgi?id=4139 help to this issue? thanks in advance, Ganbold -- If it's worth doing, do it for money. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas Quinot wrote:
* Scott Long, 2007-04-27 :
Oh hell, I know exactly what the problem is! The opcode for a
TEST_UNIT_READY is 0x00. This is probably the command that is
generating the CHECK_CONDITION. The test for saved_cmd is entirely
bogus.
H. Looks like a very plausible culprit. Good catch Scott!
(I felt there had to be something wrong when I wrote that test,
incidentally, precisely because of TEST_UNIT_READY).
Nikolay, Ganbold, (and others), here's another patch against 1.42.2.3,
please let me know if it works for you.
Thomas.
Index: atapi-cam.c
===
RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.50
diff -u -r1.50 atapi-cam.c
--- atapi-cam.c 14 Mar 2007 01:59:00 - 1.50
+++ atapi-cam.c 27 Apr 2007 19:26:09 -
@@ -729,7 +743,7 @@
* issued a REQUEST SENSE automatically and that operation
* returned without error.
*/
- if (request-u.atapi.saved_cmd != 0 request-error == 0) {
+ if (request-u.atapi.sense.key != 0 request-error == 0) {
bcopy (request-u.atapi.sense, csio-sense_data,
sizeof(struct atapi_sense));
csio-ccb_h.status |= CAM_AUTOSNS_VALID;
}
Scott, Thomas, thank you very much for the effort fixing this problem.
k3b starts fine with this patch.
Ganbold
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas Quinot wrote: * Ganbold, 2007-04-25 : Description: With atapi-cam.c (rev 1.42.2.3) when running k3b application, system completely hangs on k3b splash screen and I had to use power button only to restart the machine. Extremely strange. I can't offer any definite solution at this point, since I have no idea how this change could cause a system to hang. Here are a few possible investigation ideas: * AFAIK k3b is just a front-end for command-line tools. You should determine what exact commands are spawned by k3b to identify which of these is causing the apparent hang; * it would also be useful to enable CAM debugging options (see man 4 cam, option CAMDEBUG, and flags CAM_DEBUG_TRACE and CAM_DEBUG_SUBTRACE) and to capture all console output up to the hang (for example using a serial console) * if Scott's hunch of an interrupt storm is correct, then this issue might be related to the DMA problem described under PR 103602, so it would be useful to try the last patch I sent on that PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=103602getpatch=12 * if all else fails, please let me know if the attached patch, which reverts part of rev. 1.42.2.3, changes anything. I tried your attached patch and the problem is still the same. System hangs when starts k3b. With atapi-cam.c rev. 1.42.2.2, k3b starts fine, system doesn't hang. For your information I have k3b normal startup messages with atapi-cam.c rev. 1.42.2.2. It might help to find the problem. devil# k3b Only one line in dcopserver file !: DCOPClient::attachInternal. Attach failed networkIdsList argument is NULL Only one line in dcopserver file !: DCOPClient::attachInternal. Attach failed networkIdsList argument is NULL kbuildsycoca running... devil# kdecore (KAction): WARNING: KActionCollection::KActionCollection( QObject *parent, const char *name, KInstance *instance ) k3b: (K3bCdrecordProgram) could not start /opt/schily/bin k3b: (K3bMkisofsProgram) could not start /opt/schily/bin k3b: (K3bCdrecordProgram) could not start /root/bin k3b: (K3bMkisofsProgram) could not start /root/bin k3b: (K3bExternalBinManager) Cdrecord 2.1 features: gracetime, overburn, cdtext, clone, tao, cuefile, xamix, plain-atapi, hacked-atapi, audio-stdin, burnfree k3b: (K3bExternalBinManager) 2 1 -1 seems to be cdrecord version = 1.11a02, using burnfree instead of burnproof k3b: (K3bExternalBinManager) seems to be cdrecord version = 1.11a31, support for Just Link via burnfree driveroption (BSDDeviceScan) number of matches 10 (BSDDeviceScan) add device /dev/cd0:1:0:0 (K3bDevice::Device) /dev/cd0: init() (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::ScsiCommand) transport command 12, length: 6 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: CD Mastering (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: CD Track At Once (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: CD-RW Media Write Support (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD Read (MMC5) (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD+R (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD+RW (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD+R Double Layer (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: DVD-R/-RW Write (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::Device) /dev/cd0 feature: Rigid Restricted Overwrite (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::ScsiCommand) transport command 46, length: 10 (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::openDevice) open device /dev/pass0 succeeded. (K3bDevice::ScsiCommand) transport command 5a, length: 10 (K3bDevice::ScsiCommand) transport command 5a, length: 10 (K3bDevice::Device) /dev/cd0: dataLen: 60 (K3bDevice::Device) /dev/cd0: checking for TAO (K3bDevice::ScsiCommand) transport command 55, length: 10 (K3bDevice::Device) /dev/cd0: checking for SAO (K3bDevice::ScsiCommand) transport command 55, length: 10 (K3bDevice::Device) /dev/cd0: checking for SAO_R96P (K3bDevice::ScsiCommand) transport command 55, length: 10 (K3bDevice::Device) /dev/cd0: checking for SAO_R96R (K3bDevice::ScsiCommand) transport command 55, length: 10 (K3bDevice
Re: kern/112119: system hangs when starts k3b on RELENG_6
Thomas Quinot wrote: * Ganbold, 2007-04-25 : Description: With atapi-cam.c (rev 1.42.2.3) when running k3b application, system completely hangs on k3b splash screen and I had to use power button only to restart the machine. Extremely strange. I can't offer any definite solution at this point, since I have no idea how this change could cause a system to hang. Here are a few possible investigation ideas: * AFAIK k3b is just a front-end for command-line tools. You should determine what exact commands are spawned by k3b to identify which of these is causing the apparent hang; * it would also be useful to enable CAM debugging options (see man 4 cam, option CAMDEBUG, and flags CAM_DEBUG_TRACE and CAM_DEBUG_SUBTRACE) and to capture all console output up to the hang (for example using a serial console) * if Scott's hunch of an interrupt storm is correct, then this issue might be related to the DMA problem described under PR 103602, so it would be useful to try the last patch I sent on that PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=103602getpatch=12 * if all else fails, please let me know if the attached patch, which reverts part of rev. 1.42.2.3, changes anything. I will try http://www.freebsd.org/cgi/query-pr.cgi?pr=103602getpatch=12 patch later today and let you know. thanks, Ganbold Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
k3b problem
Dear Thomas, Can you take a look at src/sys/dev/ata/atapi-cam.c,v 1.42.2.3? With this revision of atapi-cam.c k3b application hangs on splash screen and I had to use power button only to restart the machine. This is observed with RELENG_6 and recent k3b port. Other people had similar problems. k3b starts fine with atapi-cam.c Revision 1.42.2.2. thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kde-freebsd] problem hal - k3b ?
Beni wrote: On Friday 20 April 2007 03:55:56 Ganbold wrote: Michael Nottebrock wrote: I forwarded my mail to gnome@ (the HAL maintainers) after sending it and Joe Marcus Clarke from gnome@ had this to say on the issue: --- snip This should have been fixed a while ago by jylefort when he set the default device for ATAPI access to be the ATAPICAM device (as opposed to the ATA device). Assuming you have not undone that change, and are running the latest version of HAL, these panics should not be occurring. Even still, you're right that these are not HAL bugs, but rather an issue in the kernel. I use nautilus-cd-burner to burn CDs in GNOME, and I have never had such a panic on 6-STABLE. n-c-b uses cdrecord, cdrao, and dvd-utils under the covers to do the actual device work. Not sure what k3b is using, but maybe it diddles something it shouldn't. Joe --- snip Beni, Robert, Ganbold, are you all in fact running the latest version of the hal port and do you all have atapicam enabled in your kernel? If not, making sure of both might help avoiding the problem. I see. I know I have updated my system last Saturday (14th April 2007) and I think I updated both hal and kdelibs ports. I have atapicam enabled in kernel. Let me double check it this weekend and I will let you know. thanks, Ganbold Subject: Re: Fwd: Re: [kde-freebsd] problem hal - k3b ? From: Joe Marcus Clarke [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 12:49:26 -0400 To: Michael Nottebrock [EMAIL PROTECTED] To: Michael Nottebrock [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Michael Nottebrock wrote: I forgot to cc gnome@ on my reply. I don't think this is a HAL bug, but just FYI. Subject: Re: [kde-freebsd] problem hal - k3b ? From: Michael Nottebrock [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 18:12:46 +0200 To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: Beni [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] On Wednesday, 18. April 2007, Beni wrote: Hi List, I think I have a problem with hal(d) and k3b (version 1.0 from ports) : my whole system freezes when starting up k3b. I get the splash screen and then it all stops and a ctrl-alt-del is the only way out. Other people have reported kernel panics. It looks to me like k3b's device probing and hald's device probing at the same time manages to tickle a bug in ata(4). Ref: http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070753.htm l http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034486.html I'm afraid a true kernel hacker will have to inconvenince themselves with running k3b and hal in order to have this one fixed. FWIW, I haven't seen in happening on 5.5. This should have been fixed a while ago by jylefort when he set the default device for ATAPI access to be the ATAPICAM device (as opposed to the ATA device). Assuming you have not undone that change, and are running the latest version of HAL, these panics should not be occurring. Even still, you're right that these are not HAL bugs, but rather an issue in the kernel. I use nautilus-cd-burner to burn CDs in GNOME, and I have never had such a panic on 6-STABLE. n-c-b uses cdrecord, cdrao, and dvd-utils under the covers to do the actual device work. Not sure what k3b is using, but maybe it diddles something it shouldn't. Joe Could it all be related to this : http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034553.html and the solution from Shane Bell in http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034602.html : I believe the culprit is somewhere in a recent MFC to atapi-cam.c (rev 1.42.2.3) reverting to rev 1.42.2.2 fixes both the k3b system hangs and INQUIRY ILLEGAL REQUEST errors here. Most probably. I updated everything, including source and ports on April 22nd and the problem still exists. k3b hangs after loading splash screen and I had to use power button on my laptop to power down and up the system. I will try to revert rev 1.42.2.2 and see what will happen. Ganbold Beni. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kde-freebsd] problem hal - k3b ?
Michael Nottebrock wrote: On Wednesday, 18. April 2007, Beni wrote: Hi List, I think I have a problem with hal(d) and k3b (version 1.0 from ports) : my whole system freezes when starting up k3b. I get the splash screen and then it all stops and a ctrl-alt-del is the only way out. My problem is the same as Beni's. Splash screen appears and hangs. I have to press power button to turn off and on my laptop. Didn't try ctrl+alt+del though. Ganbold Other people have reported kernel panics. It looks to me like k3b's device probing and hald's device probing at the same time manages to tickle a bug in ata(4). Ref: http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070753.html http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034486.html I'm afraid a true kernel hacker will have to inconvenince themselves with running k3b and hal in order to have this one fixed. FWIW, I haven't seen in happening on 5.5. Cheers, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [kde-freebsd] problem hal - k3b ?
Michael Nottebrock wrote: I forwarded my mail to gnome@ (the HAL maintainers) after sending it and Joe Marcus Clarke from gnome@ had this to say on the issue: --- snip This should have been fixed a while ago by jylefort when he set the default device for ATAPI access to be the ATAPICAM device (as opposed to the ATA device). Assuming you have not undone that change, and are running the latest version of HAL, these panics should not be occurring. Even still, you're right that these are not HAL bugs, but rather an issue in the kernel. I use nautilus-cd-burner to burn CDs in GNOME, and I have never had such a panic on 6-STABLE. n-c-b uses cdrecord, cdrao, and dvd-utils under the covers to do the actual device work. Not sure what k3b is using, but maybe it diddles something it shouldn't. Joe --- snip Beni, Robert, Ganbold, are you all in fact running the latest version of the hal port and do you all have atapicam enabled in your kernel? If not, making sure of both might help avoiding the problem. I see. I know I have updated my system last Saturday (14th April 2007) and I think I updated both hal and kdelibs ports. I have atapicam enabled in kernel. Let me double check it this weekend and I will let you know. thanks, Ganbold Subject: Re: Fwd: Re: [kde-freebsd] problem hal - k3b ? From: Joe Marcus Clarke [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 12:49:26 -0400 To: Michael Nottebrock [EMAIL PROTECTED] To: Michael Nottebrock [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Michael Nottebrock wrote: I forgot to cc gnome@ on my reply. I don't think this is a HAL bug, but just FYI. Subject: Re: [kde-freebsd] problem hal - k3b ? From: Michael Nottebrock [EMAIL PROTECTED] Date: Thu, 19 Apr 2007 18:12:46 +0200 To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: Beni [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] On Wednesday, 18. April 2007, Beni wrote: Hi List, I think I have a problem with hal(d) and k3b (version 1.0 from ports) : my whole system freezes when starting up k3b. I get the splash screen and then it all stops and a ctrl-alt-del is the only way out. Other people have reported kernel panics. It looks to me like k3b's device probing and hald's device probing at the same time manages to tickle a bug in ata(4). Ref: http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070753.html http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034486.html I'm afraid a true kernel hacker will have to inconvenince themselves with running k3b and hal in order to have this one fixed. FWIW, I haven't seen in happening on 5.5. This should have been fixed a while ago by jylefort when he set the default device for ATAPI access to be the ATAPICAM device (as opposed to the ATA device). Assuming you have not undone that change, and are running the latest version of HAL, these panics should not be occurring. Even still, you're right that these are not HAL bugs, but rather an issue in the kernel. I use nautilus-cd-burner to burn CDs in GNOME, and I have never had such a panic on 6-STABLE. n-c-b uses cdrecord, cdrao, and dvd-utils under the covers to do the actual device work. Not sure what k3b is using, but maybe it diddles something it shouldn't. Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: K3B crashes kernel
Robert Marella wrote:
Good Afternoon
I have two systems running 6 stable that K3B is crashing the kernel.
All ports are up to date as of today. I have searched the archives and
google and the only the only reference is in current and looks exactly
like my problem.
http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070753.html
I experienced similar problem with updated k3b on recent RELENG_6 (March
31 2007).
Whenever I run k3b my system hangs and nothing works and I had
to press power button to turn off and turn on.
I have updated kdelibs, but problem still the same.
Ganbold
This dump will happen every time by just starting K3B.
FreeBSD p4.konav201.local 6.2-STABLE FreeBSD 6.2-STABLE #3:
Mon Apr 9 18:51:25 HST 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
I am not an expert with the debugging feature but here is what I have.
[EMAIL PROTECTED] /usr/obj/usr/src/sys/GENERIC sudo kgdb
kernel.debug /data/crash/vmcore.5 Password:
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode
threads: /usr/lib/libthread_db.so: Undefined symbol
ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free
Software Foundation, Inc. GDB is free software, covered by the GNU
General Public License, and you are welcome to change it and/or
distribute copies of it under certain conditions. Type show copying
to see the conditions. There is absolutely no warranty for GDB. Type
show warranty for details. This GDB was configured as
i386-marcel-freebsd.
Unread portion of the kernel message buffer:
acd1: FAILURE - MODE_SENSE_BIG ILLEGAL REQUEST asc=0x24 ascq=0x00
acd1: FAILURE - MODE_SENSE_BIG ILLEGAL REQUEST asc=0x24 ascq=0x00
acd1: FAILURE - MODE_SENSE_BIG ILLEGAL REQUEST asc=0x24 ascq=0x00
acd1: FAILURE - MODE_SENSE_BIG ILLEGAL REQUEST asc=0x24 ascq=0x00
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xbf8fdec0
fault code = supervisor write, protection violation
instruction pointer = 0x20:0xc04f8f15
stack pointer = 0x28:0xe53dfc28
frame pointer = 0x28:0xe53dfc5c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 33 (irq15: ata1)
trap number = 12
panic: page fault
Uptime: 21h0m51s
Dumping 2046 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 2047MB (523824 pages) 2031 2015 1999 1983 1967 1951 1935
1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711
1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487
1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263
1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039
1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767
751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479
463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191
175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc070b56c in boot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc070b8b9 in panic
(fmt=0xc09ed023 %s) at /usr/src/sys/kern/kern_shutdown.c:565 #3
0xc098b89c in trap_fatal (frame=0xe53dfbe8, eva=0)
at /usr/src/sys/i386/i386/trap.c:837 #4 0xc098b572 in trap_pfault
(frame=0xe53dfbe8, usermode=0, eva=3213876928)
at /usr/src/sys/i386/i386/trap.c:745 #5 0xc098b10d in trap (frame=
{tf_fs = 8, tf_es = -448987096, tf_ds = -1063714776, tf_edi =
-1081090368, tf_esi = -963745280, tf_ebp = -448922532, tf_isp =
-448922604, tf_ebx = 368, tf_edx = 368, tf_ecx = 9, tf_eax =
-1081090368, tf_trapno = 12, tf_err = 3, tf_eip = -1068527851, tf_cs =
32, tf_eflags = 66118, tf_esp = -963841088, tf_ss = 1})
at /usr/src/sys/i386/i386/trap.c:435 #6 0xc097569a in calltrap ()
at /usr/src/sys/i386/i386/exception.s:139 #7 0xc04f8f15 in
ata_pio_read (request=0xcc331b28, length=18) at cpufunc.h:229 #8
0xc04f7942 in ata_end_transaction (request=0xcc331b28)
at /usr/src/sys/dev/ata/ata-lowlevel.c:402 #9 0xc04e1af9 in
ata_interrupt (data=0xc68e6a00) at /usr/src/sys/dev/ata/ata-all.c:341
#10 0xc06f07f8 in ithread_execute_handlers (p=0xc6901860,
ie=0xc67a1580) at /usr/src/sys/kern/kern_intr.c:682 #11 0xc06f0966 in
ithread_loop (arg=0xc691e380) at /usr/src/sys/kern/kern_intr.c:765 #12
0xc06ef26f in fork_exit (callout=0xc06f08f0 ithread_loop,
arg=0xbf8fdec0, frame=0xbf8fdec0) at /usr/src/sys/kern/kern_fork.c:821
#13 0xc09756fc in fork_trampoline ()
at /usr/src/sys/i386/i386/exception.s:208
(kgdb)
If anything else is required of me, I would be happy to provide it.
Robert
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED
Re: application hangs in STABLE from time to time
Kris Kennaway wrote: On Fri, Nov 24, 2006 at 10:02:23AM +0800, Ganbold wrote: So do I have interrupt storms here and it is something related to bge? No, your interrupts look fine. What else should I check when application hangs again? The most important thing to know is what is the application doing when it hangs. Unfortunately none of the information you provided shows this. Next time use the -o wchan argument to ps to find out what state the process is blocked in. Ok, Here it is: 573 ?? Is 0:00.02 /usr/sbin/inetd -wW -C 60 78721 ?? I 0:00.01 /usr/local/Radiator-3.15/hooks/PSA ^ 78744 ?? Is 0:00.05 sshd: tsgan [priv] (sshd) 78747 ?? S 0:00.02 sshd: [EMAIL PROTECTED] (sshd) 591 v0 Is+0:00.00 /usr/libexec/getty Pc ttyv0 592 v1 Is+0:00.00 /usr/libexec/getty Pc ttyv1 593 v2 Is+0:00.00 /usr/libexec/getty Pc ttyv2 594 v3 Is+0:00.00 /usr/libexec/getty Pc ttyv3 595 v4 Is+0:00.00 /usr/libexec/getty Pc ttyv4 596 v5 Is+0:00.00 /usr/libexec/getty Pc ttyv5 597 v6 Is+0:00.00 /usr/libexec/getty Pc ttyv6 598 v7 Is+0:00.00 /usr/libexec/getty Pc ttyv7 16099 p0- I 20:29.05 perl /usr/local/Radiator-3.15/radiusd -log_file /var/log/radius/logfile -config_file /usr/local/Radiator-3.15/voip.cfg -pid_file / 78748 p0 Is 0:00.01 -sh (sh) 78750 p0 I 0:00.01 su 78751 p0 S 0:00.04 _su (csh) 78761 p0 R+ 0:00.00 ps ax voiprad#ps axHlwww|grep PSA 0 78721 16099 0 4 0 1696 1184 sbwait I ??0:00.01 /usr/local/Radiator-3.15/hooks/PSA voiprad# voiprad# voiprad# ps -o wchan WCHAN ttyin ttyin ttyin ttyin ttyin ttyin ttyin ttyin piperd wait pause - You can also use kgdb to find out where it is waiting in the kernel: kgdb /dev/mem /boot/kernel/kernel.symbols info threads find the thread corresponding to the process that is blocked thread tid bt Oh, I don't have kernel.symbols file, how to enable it? thanks, Ganbold Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: application hangs in STABLE from time to time
Kris, Kris Kennaway wrote: On Fri, Dec 01, 2006 at 01:02:33PM +0800, Ganbold wrote: Kris Kennaway wrote: On Fri, Nov 24, 2006 at 10:02:23AM +0800, Ganbold wrote: So do I have interrupt storms here and it is something related to bge? No, your interrupts look fine. What else should I check when application hangs again? The most important thing to know is what is the application doing when it hangs. Unfortunately none of the information you provided shows this. Next time use the -o wchan argument to ps to find out what state the process is blocked in. Ok, Here it is: 573 ?? Is 0:00.02 /usr/sbin/inetd -wW -C 60 78721 ?? I 0:00.01 /usr/local/Radiator-3.15/hooks/PSA ^ 78744 ?? Is 0:00.05 sshd: tsgan [priv] (sshd) 78747 ?? S 0:00.02 sshd: [EMAIL PROTECTED] (sshd) 591 v0 Is+0:00.00 /usr/libexec/getty Pc ttyv0 592 v1 Is+0:00.00 /usr/libexec/getty Pc ttyv1 593 v2 Is+0:00.00 /usr/libexec/getty Pc ttyv2 594 v3 Is+0:00.00 /usr/libexec/getty Pc ttyv3 595 v4 Is+0:00.00 /usr/libexec/getty Pc ttyv4 596 v5 Is+0:00.00 /usr/libexec/getty Pc ttyv5 597 v6 Is+0:00.00 /usr/libexec/getty Pc ttyv6 598 v7 Is+0:00.00 /usr/libexec/getty Pc ttyv7 16099 p0- I 20:29.05 perl /usr/local/Radiator-3.15/radiusd -log_file /var/log/radius/logfile -config_file /usr/local/Radiator-3.15/voip.cfg -pid_file / 78748 p0 Is 0:00.01 -sh (sh) 78750 p0 I 0:00.01 su 78751 p0 S 0:00.04 _su (csh) 78761 p0 R+ 0:00.00 ps ax voiprad#ps axHlwww|grep PSA 0 78721 16099 0 4 0 1696 1184 sbwait I ??0:00.01 /usr/local/Radiator-3.15/hooks/PSA voiprad# voiprad# voiprad# ps -o wchan WCHAN ttyin ttyin ttyin ttyin ttyin ttyin ttyin ttyin piperd wait pause - Well, I meant a more complete command than that one ;-) Fortunately it's also included in your previous output above (sbwait). This means that the process is waiting for network traffic (usually waiting for another local or remote process to send it data). So it's not obviously pointing to a problem. Remind me again how you know this isn't an application bug (sorry, I've forgotten context)? This application connects to remote mysql-4.0.x server and sends some queries and does some calculations and returns. I tried to run this application from console, and it works fine. It runs from radius server and it works fine serving user access requests except sometimes it hangs. It used to work fine on FreeBSD 5.2-STABLE before upgrading to RELENG-6. So I guess there is something else. You can also use kgdb to find out where it is waiting in the kernel: kgdb /dev/mem /boot/kernel/kernel.symbols info threads find the thread corresponding to the process that is blocked thread tid bt Oh, I don't have kernel.symbols file, how to enable it? It might be in your kernel compilation directory (possibly called kernel.debug). Otherwise, you'll have to build a new kernel and trigger the problem again. I tried with with kernel.debug without success: voiprad# kgdb /dev/mem /usr/obj/usr/src/sys/VOIPRAD/kernel.debug kgdb: bad namelist thanks, Ganbold kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
application hangs in STABLE from time to time
Hi, I have strange problem. I'm running radius server which in turn serves user requests by running application. The application connects to another host (mysql server) and gets data and do some calculations and return results. Application runs fine, but from time to time it hangs and I can see it using ps -ax command. So when application hangs radius can not serve user requests any more waiting the application to finish. Before updating from FreeBSD-5.2-STABLE to RELENG_6 it was working fine and I didn't observe such problem for 2 years. Since upgrading to RELENG_6 a couple of months ago this problem appeared. While application was hanging, I can log into the system. I can log into another mysql host which is the exactly same machine with more RAM. I checked mysql server's processlist by running 'mysql show processlist' and there wasn't any process running and locking the tables. I'm using mysql client/server-4.0.27 from ports. So do I have interrupt storms here and it is something related to bge? What else should I check when application hangs again? Here is dmesg, vmstat, ps outputs: http://www.mnbsd.org/ftp/rad_hang.txt thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 945GM graphics and mplayer
Marcus Alves Grando wrote: Eric Anholt wrote: On Mon, 2006-10-02 at 13:25 +0800, Ganbold wrote: Hi, http://marcus.grupos.com.br:8080/patch/agp_i810.c.patch Eric, Marcus, Good news, I updated gnome to 2.16.x (which means it updated xorg, i945GM support was included). So I can use your patch and mplayer can do full screen playing with -vo xv option. And yet no more strange mouse problem. thanks a lot, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 945GM graphics and mplayer
Marcus Alves Grando wrote: Eric Anholt wrote: On Mon, 2006-10-02 at 13:25 +0800, Ganbold wrote: Hi, http://marcus.grupos.com.br:8080/patch/agp_i810.c.patch Eric, Marcus, Any update on 945GM support patch? I tested Marcus's patch but problem still exists. Without loading acpi_video mouse pointer doesn't move or moves very lately/slowly. I can see highlighted applets in gnome panel. But pointer is still in the middle. But mplayer can use -vo xv for full screen playing. With acpi_video mplayer can only use sdl for full screen playing. I tried to apply Eric's patch but it didn't apply cleanly. I compared Marcus's and Eric's patch and it seemed to me almost the same. So after testing marcus's patch problem still exists. thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 945GM graphics and mplayer
Marcus Alves Grando wrote: Eric Anholt wrote: On Mon, 2006-10-02 at 13:25 +0800, Ganbold wrote: Hi, I have strange problem with my Dell Latitude D620 laptop which has 945GM chipset and onboard graphic card. I'm using September 30th RELENG_6. If I use acpi_video only, mplayer can only use sdl video output for full screen playing. If I use [EMAIL PROTECTED]'s i945 graphics support patch without using acpi_video, mplayer can use other video outputs for full screen playing but my mouse works in strange way, mouse pointer doesn't move, or moves very very slowly. I can see mouse goes over gnome applets (highlights) but I don't see pointer itself is moving. If I use mnag's patch and acpi_video together mplayer can use only sdl for full screen playing. OK, I think in reading your email, I'll substitute having acpi_video with not having AGP loaded. If you have acpi_video on RELENG_6, that prevents your AGP from loading afaik. So, if you have AGP loaded, you get a broken cursor, but playing XV works fine? Could you try the patch at http://people.freebsd.org/~anholt/agp-i945-4.diff instead? There were RELENG_6: http://marcus.grupos.com.br:8080/patch/agp_i810.c.patch Eric, Marcus, I tested Marcus's patch but problem still exists. Without loading acpi_video mouse pointer doesn't move or moves very lately/slowly. I can see highlighted applets in gnome panel. But pointer is still in the middle. But mplayer can use -vo xv for full screen playing. With acpi_video mplayer can only use sdl for full screen playing. I tried to apply Eric's patch but it didn't apply cleanly. I compared Marcus's and Eric's patch and it seemed to me almost the same. So after testing marcus's patch problem still exists. thanks, Ganbold Regards cases where the original patch (along with Linux's code) could get the aperture size wrong in my testing. But then, testing 3 versions of the code across 2-3 pieces of hardware and 2 OSes leaves me somewhat confused as to what I've really tested, so no guarantees :) Is this strange behavior related to ACPI or something else? Also when I'm not starting /etc/rc.d/moused before going to X I can't use mouse in X. Is this problem related to X or ACPI? X expects to use sysmouse by default. If you don't have moused providing mouse events, you won't get any. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 945GM graphics and mplayer
Marcus Alves Grando wrote: Eric Anholt wrote: On Mon, 2006-10-02 at 13:25 +0800, Ganbold wrote: Hi, I have strange problem with my Dell Latitude D620 laptop which has 945GM chipset and onboard graphic card. I'm using September 30th RELENG_6. If I use acpi_video only, mplayer can only use sdl video output for full screen playing. If I use [EMAIL PROTECTED]'s i945 graphics support patch without using acpi_video, mplayer can use other video outputs for full screen playing but my mouse works in strange way, mouse pointer doesn't move, or moves very very slowly. I can see mouse goes over gnome applets (highlights) but I don't see pointer itself is moving. If I use mnag's patch and acpi_video together mplayer can use only sdl for full screen playing. OK, I think in reading your email, I'll substitute having acpi_video with not having AGP loaded. If you have acpi_video on RELENG_6, that prevents your AGP from loading afaik. So, if you have AGP loaded, you get a broken cursor, but playing XV works fine? Could you try the patch at http://people.freebsd.org/~anholt/agp-i945-4.diff instead? There were RELENG_6: http://marcus.grupos.com.br:8080/patch/agp_i810.c.patch Eric, Marcus, who's patch should I try on RELENG_6? Anyway I'll try both in couple of days and let you know how it goes. thanks a lot, Ganbold Regards cases where the original patch (along with Linux's code) could get the aperture size wrong in my testing. But then, testing 3 versions of the code across 2-3 pieces of hardware and 2 OSes leaves me somewhat confused as to what I've really tested, so no guarantees :) Is this strange behavior related to ACPI or something else? Also when I'm not starting /etc/rc.d/moused before going to X I can't use mouse in X. Is this problem related to X or ACPI? X expects to use sysmouse by default. If you don't have moused providing mouse events, you won't get any. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 945GM graphics and mplayer
Eric Anholt wrote: On Mon, 2006-10-02 at 13:25 +0800, Ganbold wrote: Hi, I have strange problem with my Dell Latitude D620 laptop which has 945GM chipset and onboard graphic card. I'm using September 30th RELENG_6. If I use acpi_video only, mplayer can only use sdl video output for full screen playing. If I use [EMAIL PROTECTED]'s i945 graphics support patch without using acpi_video, mplayer can use other video outputs for full screen playing but my mouse works in strange way, mouse pointer doesn't move, or moves very very slowly. I can see mouse goes over gnome applets (highlights) but I don't see pointer itself is moving. If I use mnag's patch and acpi_video together mplayer can use only sdl for full screen playing. OK, I think in reading your email, I'll substitute having acpi_video with not having AGP loaded. If you have acpi_video on RELENG_6, that prevents your AGP from loading afaik. Oh, ok, I thought so. Some questions: Do I really need acpi_video? Can I use both AGP and acpi_video at the same time? Do I need to load i915 kernel module? So, if you have AGP loaded, you get a broken cursor, but playing XV works fine? Yes. Could you try the patch at http://people.freebsd.org/~anholt/agp-i945-4.diff instead? There were cases where the original patch (along with Linux's code) could get the aperture size wrong in my testing. But then, testing 3 versions of the code across 2-3 pieces of hardware and 2 OSes leaves me somewhat confused as to what I've really tested, so no guarantees :) Ok, I understand, I'll try your patch and let you know whether it solves the problem or not. Is this strange behavior related to ACPI or something else? Also when I'm not starting /etc/rc.d/moused before going to X I can't use mouse in X. Is this problem related to X or ACPI? X expects to use sysmouse by default. If you don't have moused providing mouse events, you won't get any. It is strange though I see mouse pointer in center of the screen, but it doesn't move. As I recall it was working without moused when I first installed FreeBSD-6.1-RELEASE. I'm not quite sure, I did several updates to RELENG_6 and somewhere July it didn't work without moused loaded beforehand. Maybe it is ACPI related problem, but it is only my opinion. thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
945GM graphics and mplayer
Hi, I have strange problem with my Dell Latitude D620 laptop which has 945GM chipset and onboard graphic card. I'm using September 30th RELENG_6. If I use acpi_video only, mplayer can only use sdl video output for full screen playing. If I use [EMAIL PROTECTED]'s i945 graphics support patch without using acpi_video, mplayer can use other video outputs for full screen playing but my mouse works in strange way, mouse pointer doesn't move, or moves very very slowly. I can see mouse goes over gnome applets (highlights) but I don't see pointer itself is moving. If I use mnag's patch and acpi_video together mplayer can use only sdl for full screen playing. Is this strange behavior related to ACPI or something else? Also when I'm not starting /etc/rc.d/moused before going to X I can't use mouse in X. Is this problem related to X or ACPI? thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd -- resolved
Robert Watson wrote: Dear all, I've just comitted a fix to syscalls.master and regenerated the remaining system call files, which should correct the auditctl: Invalid Argument error being returned by auditd. In short order, this fix should be on the cvsup mirrors -- please let me know if it resolves the problem you were experiencing. Hi, After installing and running auditd I don't see any log files for auditd: daemon# ls -l /var/audit/ total 0 -r--r- 1 root audit 0 Sep 18 14:23 20060918052316.20060918060339 -r--r- 1 root audit 0 Sep 18 15:03 20060918060339.not_terminated I have custom /etc/security/audit_control and audit_user files. daemon# more /etc/security/audit_control # # $P4: //depot/projects/trustedbsd/openbsm/etc/audit_control#3 $ # $FreeBSD: src/contrib/openbsm/etc/audit_control,v 1.2.2.1 2006/09/02 10:46:00 rwatson Exp $ # dir:/var/audit flags:all minfree:20 naflags:lo # # $P4: //depot/projects/trustedbsd/openbsm/etc/audit_user#3 $ # $FreeBSD: src/contrib/openbsm/etc/audit_user,v 1.2.2.1 2006/09/02 10:46:00 rwatson Exp $ # #root:lo:no root:all:no I'm bit confused here I thought auditd should log all activities, but I don't see any log files. Am I doing something wrong here or my understanding regarding auditd is wrong? thanks in advance, Ganbold Thanks, Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd -- resolved
Robert Watson wrote: On Mon, 18 Sep 2006, Ganbold wrote: # # $P4: //depot/projects/trustedbsd/openbsm/etc/audit_user#3 $ # $FreeBSD: src/contrib/openbsm/etc/audit_user,v 1.2.2.1 2006/09/02 10:46:00 rwatson Exp $ # #root:lo:no root:all:no I'm bit confused here I thought auditd should log all activities, but I don't see any log files. Am I doing something wrong here or my understanding regarding auditd is wrong? Your configuration looks right to me, and should be generating a ridiculous number of audit records. Could you try rebooting and logging in again? audit_user entries take effect only as of login, similar to /etc/group settings, etc. How are you logging into the system? This is my desktop system and I updated today to latest RELENG_6. daemon# uname -an FreeBSD daemon.micom.mng.net 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #6: Mon Sep 18 12:56:04 ULAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 I tried to restart several times auditd using /etc/rc.d/auditd script. daemon# /etc/rc.d/auditd restart Trigger sent. Starting auditd. daemon# /etc/rc.d/auditd restart Trigger sent. auditd already running? (pid=2065). daemon# /etc/rc.d/auditd restart Error sending trigger: Operation not supported by device Starting auditd. daemon# /etc/rc.d/auditd restart Trigger sent. auditd already running? (pid=2095). daemon# /etc/rc.d/auditd restart Error sending trigger: Operation not supported by device Starting auditd. daemon# /etc/rc.d/auditd restart Trigger sent. Starting auditd. daemon# ps ax | grep audit 10 ?? DL 0:00.00 [audit_worker] 2141 ?? Ss 0:00.01 /usr/sbin/auditd 2143 p3 RV 0:00.00 grep audit (csh) daemon# ps ax | grep audit 10 ?? DL 0:00.00 [audit_worker] 2141 ?? Ss 0:00.01 /usr/sbin/auditd Strange, there are still no logs in /var/audit dir :( Even tried to use your config, no success. However when I logged on to my desktop from console to itself (ssh -l tsgan localhost) it starts logging. But why it is not logging when I'm on console? On my local RELENG_6 system, with the recent auditctl(2) fix, I'm using the following global settings to audit programs run by authenticated users: dir:/var/audit flags:lo,+ex minfree:20 naflags:lo It seems to be working properly. User space login/logout auditing won't work in RELENG_6 until the MFC of Christian's recent tweaks to pipe preselection, which will occurr in a few days (and hence should appear in BETA2). I see. thanks, Ganbold Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd -- resolved
Robert Watson wrote: On Mon, 18 Sep 2006, Ganbold wrote: Strange, there are still no logs in /var/audit dir :( Even tried to use your config, no success. However when I logged on to my desktop from console to itself (ssh -l tsgan localhost) it starts logging. But why it is not logging when I'm on console? Are you using xdm/kdm/gdm/etc or /usr/bin/login? I'm not sure that the various GUI login managers associated with X11 ship with BSM support compiled in by default, although given that they also run on Solaris, it is likely they support it. Ok, I'm using gnome and gnome-terminal, and it is not logging. Probably gnome-terminal is not compiled with BSM support. Auditd logs when I go to console using ctrl+alt+f2 combination from X. Thanks for clarifying this. Ganbold Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd
Hi, I have FreeBSD-6.1-STABLE and auditd refuses to run. devil# uname -an FreeBSD devil.micom.mng.net 6.1-STABLE FreeBSD 6.1-STABLE #17: Wed Sep 6 18:16:49 ULAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 devil# /etc/rc.d/auditd restart Error sending trigger: Function not implemented Starting auditd. thanks, Ganbold Joerg Pernfuss wrote: On Wed, 6 Sep 2006 09:37:23 +0200 Cristiano Deana [EMAIL PROTECTED] wrote: Hi, i updated my system to -STABLE (FreeBSD mobile.deana.it 6.1-STABLE FreeBSD 6.1-STABLE #10: Wed Sep 6 08:20:43 CEST 2006) and followed instructions at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html but when i tried to start auditd i got: [...] files in /etc/security has not been modified. where i'm wrong? I reported the same issue to the [EMAIL PROTECTED] yesterday. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+current/freebsd-audit and http://docs.freebsd.org/cgi/getmsg.cgi?fetch=6967+0+current/freebsd-audit A full ktrace is linked in the second mail (if someone prefers truss, I have a trace with truss also). Regards, Jörg !DSPAM:44fe928d944981045827524! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
Pyun YongHyeon wrote:
On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote:
Hi,
Thanks a lot for your patch. Your patch fixes panic, however I still see
bge0: firmware handshake timed out
bge0: link state changed to DOWN
messages.
When I tried to use Oleg's if_bge.c, rev. 1.140 in STABLE buildkernel stops:
mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I-
-DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include
-I/usr/include -I/usr/obj/usr/src/sys/DEVIL
/usr/src/sys/modules/bge/../../dev/bge/if_bge.c
/usr/src/sys/modules/bge/../../dev/bge/if_bge.c:2570:35: macro
VLAN_INPUT_TAG requires 4 arguments, but only 3 given
mkdep: compile failed
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
mkdep: compile failed
*** Error code 1
2 errors
*** Error code 2
1 error
*** Error code 2
1 error
I see VLAN_INPUT_TAG is defined as VLAN_INPUT_TAG(_ifp, _m, _t,
_errcase) in if_vlan_var.h, rev v 1.21.2.2 with 4 arguments, however
new if_bge.c, rev. 1.140 uses 3 arguments.
Is it safe to use if_vlan_var.h, rev 1.24 and if_vlan.c, rev 1.114 only?
What other patches should I use?
When all these changes MFC to STABLE?
You should use VLAN_INPUT_TAG_NEW macro in RELENG_6.
Anyway, here is guess work for BCM5752(obtained from OpenBSD).
Because I don't have 5752 hardware I don't know whether it works or
not. The patch is for RELENG_6(You need brgphy(4) patch too).
Where can I get brgphy(4) patch for RELENG_6?
thanks,
Ganbold
thanks,
Ganbold
Pyun YongHyeon wrote:
I think your PHY was not recognized by brgphy(4). But I don't know it
fixes firmware handshake timed out issue you've seen.
Recently oleg fixed a long standing bug in bge(4). So you may also want
to merge the change.(See if_bge.c, rev. 1.140)
Patch generated against RELENG_6(compile tested only).
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.91.2.16
diff -u -r1.91.2.16 if_bge.c
--- if_bge.c10 Aug 2006 11:02:14 - 1.91.2.16
+++ if_bge.c30 Aug 2006 07:20:43 -
@@ -1007,9 +1007,26 @@
/* Set up the PCI DMA control register. */
if (sc-bge_pcie) {
/* PCI Express bus */
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0xf BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x2 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ uint32_t device_ctl;
+
+ /* alternative from Linux driver */
+#define DMA_CTRL_WRITE_PCIE_H20MARK_1280x0018
+#define DMA_CTRL_WRITE_PCIE_H20MARK_2560x0038
+
+ dma_rw_ctl = 0x7600; /* XXX XXX XXX */;
+ device_ctl = pci_read_config(sc-bge_dev,
+ BGE_PCI_CONF_DEV_CTRL, 4);
+ if ((device_ctl 0x00e0) 0) {
+ /*
+* This clause is exactly what the Broadcom-supplied
+* Linux does; but given overall register programming
+* by bge(4), this larger DMA-write watermark
+* value causes BCM5721 chips to totally wedge.
+*/
+ dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_256;
+ } else {
+ dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_128;
+ }
} else if (sc-bge_pcix) {
/* PCI-X bus */
if (BGE_IS_5714_FAMILY(sc)) {
@@ -1148,22 +1165,20 @@
CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_HIWAT, 10);
/* Enable buffer manager */
- if (!(BGE_IS_5705_OR_BEYOND(sc))) {
- CSR_WRITE_4(sc, BGE_BMAN_MODE,
- BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN);
+ CSR_WRITE_4(sc, BGE_BMAN_MODE,
+ BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN);
- /* Poll for buffer manager start indication */
- for (i = 0; i BGE_TIMEOUT; i++) {
- if (CSR_READ_4(sc, BGE_BMAN_MODE) BGE_BMANMODE_ENABLE)
- break;
- DELAY(10);
- }
+ /* Poll for buffer manager start indication */
+ for (i = 0; i BGE_TIMEOUT; i++) {
+ if (CSR_READ_4(sc, BGE_BMAN_MODE) BGE_BMANMODE_ENABLE)
+ break;
+ DELAY(10);
+ }
- if (i == BGE_TIMEOUT) {
- device_printf(sc-bge_dev,
- buffer manager failed to start\n);
- return (ENXIO);
- }
+ if (i == BGE_TIMEOUT) {
+ device_printf(sc-bge_dev,
+ buffer manager failed to start\n);
+ return (ENXIO);
}
/* Enable flow
Re: panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
Gleb, Pyun,
Gleb Smirnoff wrote:
Ganbold,
On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote:
G Thanks a lot for your patch. Your patch fixes panic, however I still see
G bge0: firmware handshake timed out
G bge0: link state changed to DOWN
G messages.
And yesterday delphij@ have sent me patch against firmware handshake timed
out.
It is attached. Can you please test it?
Applied delphij@'s patch and now bge0: firmware handshake timed out
message is gone. Previously there was applied Pyun's brgphy(4) patch.
Ganbold
Subject:
[PATCH FOR REVIEW] Broadcom BCM 5752 A02 firmware handshake timeout
From:
LI Xin [EMAIL PROTECTED]
Date:
Tue, 29 Aug 2006 14:39:31 +0800
To:
[EMAIL PROTECTED], [EMAIL PROTECTED]
To:
[EMAIL PROTECTED], [EMAIL PROTECTED]
Hi,
A colleague of mine has found that BCM 5752 A02 would get firmware
handshake timeout problem during the ifconfig stage. After some
investigation and comparing to the Linux driver I have the attached
patch make the problem disappear. Unfortunately I do not have
specification documentation from Broadcom so I can not say if that is a
real fix :-(
The patch was tested on Dell Latitude D820. The only problem remains is
that the -CURRENT kernel crashes if I did not explicitly set the media
and do a ifconfig bge0 up, with panic: invalid ife-ifm_data (0xa) in
mii_phy_setmedia. Backtrace is available upon request.
Cheers,
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.140
diff -u -r1.140 if_bge.c
--- if_bge.c24 Aug 2006 14:41:16 - 1.140
+++ if_bge.c29 Aug 2006 06:20:44 -
@@ -2313,6 +2313,13 @@
BGE_PCIMISCCTL_INDIRECT_ACCESS|BGE_PCIMISCCTL_MASK_PCI_INTR|
BGE_HIF_SWAP_OPTIONS|BGE_PCIMISCCTL_PCISTATE_RW, 4);
+ /* XXX: Broadcom Linux driver. */
+ if (sc-bge_asicrev == BGE_ASICREV_BCM5752 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM5755 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM5787) {
+ CSR_WRITE_4(sc, BGE_FASTBOOT_PC, 0x0);
+ }
+
reset = BGE_MISCCFG_RESET_CORE_CLOCKS|(651);
/* XXX: Broadcom Linux driver. */
Index: if_bgereg.h
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v
retrieving revision 1.52
diff -u -r1.52 if_bgereg.h
--- if_bgereg.h 23 Aug 2006 11:32:54 - 1.52
+++ if_bgereg.h 29 Aug 2006 06:32:31 -
@@ -1656,6 +1656,7 @@
#define BGE_EE_CTL 0x6840
#define BGE_MDI_CTL0x6844
#define BGE_EE_DELAY 0x6848
+#define BGE_FASTBOOT_PC0x6894
/* Mode control register */
#define BGE_MODECTL_INT_SNDCOAL_ONLY 0x0001
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
Gleb, Pyun,
I'm a kind of bit confused here whose patch to choose.
Can you guys enlighten me in this regard?
thanks,
Ganbold
Gleb Smirnoff wrote:
Pyun,
On Wed, Aug 30, 2006 at 04:30:25PM +0900, Pyun YongHyeon wrote:
P ===
P RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
P retrieving revision 1.91.2.16
P diff -u -r1.91.2.16 if_bge.c
P --- if_bge.c 10 Aug 2006 11:02:14 - 1.91.2.16
P +++ if_bge.c 30 Aug 2006 07:20:43 -
P @@ -1007,9 +1007,26 @@
P /* Set up the PCI DMA control register. */
P if (sc-bge_pcie) {
P /* PCI Express bus */
P - dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
P - (0xf BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
P - (0x2 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
P + uint32_t device_ctl;
P +
P + /* alternative from Linux driver */
P +#define DMA_CTRL_WRITE_PCIE_H20MARK_128 0x0018
P +#define DMA_CTRL_WRITE_PCIE_H20MARK_256 0x0038
P +
P + dma_rw_ctl = 0x7600; /* XXX XXX XXX */;
P + device_ctl = pci_read_config(sc-bge_dev,
P + BGE_PCI_CONF_DEV_CTRL, 4);
P + if ((device_ctl 0x00e0) 0) {
P + /*
P + * This clause is exactly what the Broadcom-supplied
P + * Linux does; but given overall register programming
P + * by bge(4), this larger DMA-write watermark
P + * value causes BCM5721 chips to totally wedge.
P + */
P + dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_256;
P + } else {
P + dma_rw_ctl |= BGE_PCIDMA_RWCTL_PCIE_WRITE_WATRMARK_128;
P + }
P } else if (sc-bge_pcix) {
My small penny into the discussion. I was working on reviewing the
difference in initializing the PCI DMA control register in Linux tg3.c
and in bge(4).
I was quite lost in this stuff, and so I asked for help from David
Christensen (davidch@). He has explained me all the differencies
in this register between chips and I have prepared the attached patch.
Since I have very small collection of bge(4) cards, I avoid to commit
it. May be I will commit it after 6.2-RELEASE if several people test it
on their cards and all is OK. And it will live unmerged in HEAD until
6.3-RELEASE.
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.139
diff -u -p -r1.139 if_bge.c
--- if_bge.c23 Aug 2006 11:32:54 - 1.139
+++ if_bge.c23 Aug 2006 15:18:22 -
@@ -1005,36 +1005,48 @@ bge_chipinit(struct bge_softc *sc)
BGE_MEMWIN_WRITE(sc, i, 0);
/* Set up the PCI DMA control register. */
+ dma_rw_ctl = BGE_PCIDMARWCTL_READ_CMD | BGE_PCIDMARWCTL_WRITE_CMD;
+
+ /* Bits 23, 22. */
+ if (sc-bge_asicrev == BGE_ASICREV_BCM5700 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM5701 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM5714)
+ dma_rw_ctl |= BGE_PCIDMARWCTL_ASRT_ALL_BE |
+ BGE_PCIDMARWCTL_USE_MRM;
+
+ /* DMA watermarks: bits 21 - 19, 18 - 16. */
if (sc-bge_flags BGE_FLAG_PCIE) {
- /* PCI Express bus */
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0xf BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x2 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ /*
+* DMA read watermark not used on PCI-E.
+* DMA write watermark set to 128 bytes.
+*/
+ dma_rw_ctl |= (3 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
} else if (sc-bge_flags BGE_FLAG_PCIX) {
- /* PCI-X bus */
- if (BGE_IS_5714_FAMILY(sc)) {
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD;
- dma_rw_ctl = ~BGE_PCIDMARWCTL_ONEDMA_ATONCE; /* XXX */
- /* XXX magic values, Broadcom-supplied Linux driver */
- if (sc-bge_asicrev == BGE_ASICREV_BCM5780)
-dma_rw_ctl |= (1 20) | (1 18) |
-BGE_PCIDMARWCTL_ONEDMA_ATONCE;
- else
- dma_rw_ctl |= (1 20) | (1 18) | (1 15);
-
- } else if (sc-bge_asicrev == BGE_ASICREV_BCM5704)
+ switch (sc-bge_asicrev) {
+ case BGE_ASICREV_BCM5780:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 20) | (1 18) |
+ BGE_PCIDMARWCTL_ONEDMA_ATONCE;
+ break;
+ case BGE_ASICREV_BCM5714:
+ case BGE_ASICREV_BCM5714_A0:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 20) | (1 18) |
+ BGE_PCIDMARWCTL_ONEDMA_ATONCE_LOCAL
Re: panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
Gleb Smirnoff wrote:
On Wed, Aug 30, 2006 at 05:26:07PM +0900, Ganbold wrote:
G Gleb, Pyun,
G
G I'm a kind of bit confused here whose patch to choose.
G Can you guys enlighten me in this regard?
Can you please merge them? You should take all the stuff that
prepares the dma_rw_ctl variable from my patch, and all the other
stuff from Pyun's patch.
Ok, here it is. Let me know if I did something wrong.
It also includes delphij@'s patch. Pyun's brgphy(4) patch is included too.
Ganbold
--- if_bge.c Thu Aug 10 20:02:14 2006
+++ /home/tsgan/bge/new/if_bge.c Wed Aug 30 18:41:39 2006
@@ -1005,36 +1005,48 @@
BGE_MEMWIN_WRITE(sc, i, 0);
/* Set up the PCI DMA control register. */
+ dma_rw_ctl = BGE_PCIDMARWCTL_READ_CMD | BGE_PCIDMARWCTL_WRITE_CMD;
+
+ /* Bits 23, 22. */
+ if (sc-bge_asicrev == BGE_ASICREV_BCM5700 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM5701 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM5714)
+ dma_rw_ctl |= BGE_PCIDMARWCTL_ASRT_ALL_BE |
+ BGE_PCIDMARWCTL_USE_MRM;
+
+ /* DMA watermarks: bits 21 - 19, 18 - 16. */
if (sc-bge_pcie) {
- /* PCI Express bus */
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0xf BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x2 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ /*
+ * DMA read watermark not used on PCI-E.
+ * DMA write watermark set to 128 bytes.
+ */
+ dma_rw_ctl |= (3 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
} else if (sc-bge_pcix) {
- /* PCI-X bus */
- if (BGE_IS_5714_FAMILY(sc)) {
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD;
- dma_rw_ctl = ~BGE_PCIDMARWCTL_ONEDMA_ATONCE; /* XXX */
- /* XXX magic values, Broadcom-supplied Linux driver */
- if (sc-bge_asicrev == BGE_ASICREV_BCM5780)
-dma_rw_ctl |= (1 20) | (1 18) |
-BGE_PCIDMARWCTL_ONEDMA_ATONCE;
- else
-dma_rw_ctl |= (1 20) | (1 18) | (1 15);
-
- } else if (sc-bge_asicrev == BGE_ASICREV_BCM5704)
+ switch (sc-bge_asicrev) {
+ case BGE_ASICREV_BCM5780:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 20) | (1 18) |
+ BGE_PCIDMARWCTL_ONEDMA_ATONCE;
+ break;
+ case BGE_ASICREV_BCM5714:
+ case BGE_ASICREV_BCM5714_A0:
+ /* XXX: Linux driver magic values. */
+ dma_rw_ctl |= (1 20) | (1 18) |
+ BGE_PCIDMARWCTL_ONEDMA_ATONCE_LOCAL;
+ break;
+ case BGE_ASICREV_BCM5704:
/*
* The 5704 uses a different encoding of read/write
- * watermarks.
+ * watermarks: 384 bytes for write and 1536 for read.
*/
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0x7 BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x3 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
- else
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0x3 BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x3 BGE_PCIDMARWCTL_WR_WAT_SHIFT) |
- (0x0F);
+ dma_rw_ctl |= (7 BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
+ (3 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ break;
+ default:
+ /* All other chips: 384 for write and read. */
+ dma_rw_ctl |= (3 BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
+ (3 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+ }
/*
* 5703 and 5704 need ONEDMA_AT_ONCE as a workaround
@@ -1047,18 +1059,20 @@
tmp = CSR_READ_4(sc, BGE_PCI_CLKCTL) 0x1f;
if (tmp == 0x6 || tmp == 0x7)
dma_rw_ctl |= BGE_PCIDMARWCTL_ONEDMA_ATONCE;
+
+ /* Set bit 23 to enable PCIX hw bug fix. */
+ dma_rw_ctl |= BGE_PCIDMARWCTL_ASRT_ALL_BE;
}
} else
- /* Conventional PCI bus */
- dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD |
- (0x7 BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
- (0x7 BGE_PCIDMARWCTL_WR_WAT_SHIFT) |
- (0x0F);
-
- if (sc-bge_asicrev == BGE_ASICREV_BCM5703 ||
- sc-bge_asicrev == BGE_ASICREV_BCM5704 ||
- sc-bge_asicrev == BGE_ASICREV_BCM5705)
- dma_rw_ctl = ~BGE_PCIDMARWCTL_MINDMA;
+ /* Conventional PCI bus: 1024 bytes for read and write. */
+ dma_rw_ctl |= (7 BGE_PCIDMARWCTL_RD_WAT_SHIFT) |
+ (7 BGE_PCIDMARWCTL_WR_WAT_SHIFT);
+
+ /* Set minimum DMA only for 5700 and 5701. */
+ if (sc-bge_asicrev == BGE_ASICREV_BCM5700 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM5701)
+ dma_rw_ctl |= 0xf;
+
pci_write_config(sc-bge_dev, BGE_PCI_DMA_RW_CTL, dma_rw_ctl, 4);
/*
@@ -1148,22 +1162,20 @@
CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_HIWAT, 10);
/* Enable buffer manager */
- if (!(BGE_IS_5705_OR_BEYOND(sc))) {
- CSR_WRITE_4(sc, BGE_BMAN_MODE,
- BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN);
+ CSR_WRITE_4(sc, BGE_BMAN_MODE,
+ BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN);
- /* Poll for buffer manager start indication */
- for (i = 0; i BGE_TIMEOUT; i++) {
- if (CSR_READ_4(sc, BGE_BMAN_MODE) BGE_BMANMODE_ENABLE)
-break;
- DELAY(10);
- }
+ /* Poll for buffer manager start indication */
+ for (i = 0; i BGE_TIMEOUT; i++) {
+ if (CSR_READ_4(sc, BGE_BMAN_MODE) BGE_BMANMODE_ENABLE)
+ break;
+ DELAY(10);
+ }
- if (i == BGE_TIMEOUT) {
- device_printf(sc-bge_dev,
- buffer manager failed to start\n);
- return (ENXIO);
- }
+ if (i == BGE_TIMEOUT) {
+ device_printf(sc-bge_dev
panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
,e4fd1d38,0,c05f9150,0,...) at sched_sync+0x1ed fork_exit(c05f9150,0,e4fd1d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4fd1d6c, ebp = 0 --- VOP_UNLOCK: 0xc4e962b8 is not locked but should be KDB: enter: lock violation [thread pid 46 tid 100042 ] Stopped at kdb_enter+0x2b: nop db c Rebooting... cpu_reset: Stopping other CPUs Where should I get patches for bge driver? Is there any fix for it? thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: invalid ife-ifm_data (0xa) in mii_phy_setmedia
Hi,
Thanks a lot for your patch. Your patch fixes panic, however I still see
bge0: firmware handshake timed out
bge0: link state changed to DOWN
messages.
When I tried to use Oleg's if_bge.c, rev. 1.140 in STABLE buildkernel stops:
mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I-
-DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include
-I/usr/include -I/usr/obj/usr/src/sys/DEVIL
/usr/src/sys/modules/bge/../../dev/bge/if_bge.c
/usr/src/sys/modules/bge/../../dev/bge/if_bge.c:2570:35: macro
VLAN_INPUT_TAG requires 4 arguments, but only 3 given
mkdep: compile failed
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
mkdep: compile failed
*** Error code 1
2 errors
*** Error code 2
1 error
*** Error code 2
1 error
I see VLAN_INPUT_TAG is defined as VLAN_INPUT_TAG(_ifp, _m, _t,
_errcase) in if_vlan_var.h, rev v 1.21.2.2 with 4 arguments, however
new if_bge.c, rev. 1.140 uses 3 arguments.
Is it safe to use if_vlan_var.h, rev 1.24 and if_vlan.c, rev 1.114 only?
What other patches should I use?
When all these changes MFC to STABLE?
thanks,
Ganbold
Pyun YongHyeon wrote:
I think your PHY was not recognized by brgphy(4). But I don't know it
fixes firmware handshake timed out issue you've seen.
Recently oleg fixed a long standing bug in bge(4). So you may also want
to merge the change.(See if_bge.c, rev. 1.140)
Patch generated against RELENG_6(compile tested only).
Index: miidevs
===
RCS file: /home/ncvs/src/sys/dev/mii/miidevs,v
retrieving revision 1.30.2.3
diff -u -r1.30.2.3 miidevs
--- miidevs 8 Aug 2006 07:51:21 - 1.30.2.3
+++ miidevs 30 Aug 2006 02:28:07 -
@@ -118,6 +118,7 @@
model xxBROADCOM BCM5400 0x0004 Broadcom 1000baseTX PHY
model xxBROADCOM BCM5401 0x0005 BCM5401 10/100/1000baseTX PHY
model xxBROADCOM BCM5411 0x0007 BCM5411 10/100/1000baseTX PHY
+model xxBROADCOM BCM5752 0x0010 BCM5752 10/100/1000baseTX PHY
model xxBROADCOM BCM5701 0x0011 BCM5701 10/100/1000baseTX PHY
model xxBROADCOM BCM5703 0x0016 BCM5703 10/100/1000baseTX PHY
model xxBROADCOM BCM5704 0x0019 BCM5704 10/100/1000baseTX PHY
Index: brgphy.c
===
RCS file: /home/ncvs/src/sys/dev/mii/brgphy.c,v
retrieving revision 1.34.2.6
diff -u -r1.34.2.6 brgphy.c
--- brgphy.c8 Aug 2006 04:37:18 - 1.34.2.6
+++ brgphy.c30 Aug 2006 02:28:07 -
@@ -126,6 +126,12 @@
}
if (MII_OUI(ma-mii_id1, ma-mii_id2) == MII_OUI_xxBROADCOM
+ MII_MODEL(ma-mii_id2) == MII_MODEL_xxBROADCOM_BCM5752) {
+ device_set_desc(dev, MII_STR_xxBROADCOM_BCM5752);
+ return(BUS_PROBE_DEFAULT);
+ }
+
+ if (MII_OUI(ma-mii_id1, ma-mii_id2) == MII_OUI_xxBROADCOM
MII_MODEL(ma-mii_id2) == MII_MODEL_xxBROADCOM_BCM5701) {
device_set_desc(dev, MII_STR_xxBROADCOM_BCM5701);
return(BUS_PROBE_DEFAULT);
@@ -665,6 +671,7 @@
bcm5704_load_dspcode(sc);
break;
case MII_MODEL_xxBROADCOM_BCM5750:
+ case MII_MODEL_xxBROADCOM_BCM5752:
case MII_MODEL_xxBROADCOM_BCM5714:
case MII_MODEL_xxBROADCOM_BCM5780:
case MII_MODEL_xxBROADCOM_BCM5706C:
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
boot problem with ACPI disabled
Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ndisgen generated module load causes page fault, missing functions
Hi, I have FreeBSD-6.1-STABLE dell D620 laptop with Dell Wireless 1490 802.11a/g Dual-band Mini Card (which seems like bcm4310). # uname -an FreeBSD devil.micom.mng.net 6.1-STABLE FreeBSD 6.1-STABLE #2: Fri Jul 21 13:50:53 ULAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 [EMAIL PROTECTED]:0:0:class=0x028000 card=0x00071028 chip=0x431214e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 UART' class= network When I try to load bcmwl5_sys.ko module (generated by ndisgen) system faults: no match for strrchr no match for MmFreeContiguousMemorySpecifyCache no match for MmAllocateContiguousMemorySpecifyCache no match for MmGetPhysicalAddress ndis0: Dell Wireless 1490 Dual Band WLAN Mini-Card mem 0xdfdfc000-0xdfdf irq 17 at device 0.0 on pci12 ndis0: NDIS API version: 5.1 ntoskrnl dummy called... Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1a fault code = supervisor read, page not present instruction pointer = 0x20:0xc530108f stack pointer = 0x28:0xe7209938 frame pointer = 0x28:0xe720994c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 559 (kldload) [thread pid 559 tid 100103 ] Stopped at 0xc530108f: cmpb0(%edi),%al db bt Tracing pid 559 tid 100103 td 0xc4e06a80 bcmwl5_sys_drv_data_start(c534e8f6,c52f9ddc,0,0,e7209980) at 0xc530108f bcmwl5_sys_drv_data_start(c4e2a000,c53d1000,c539d600,c53e2000,c4e2a000) at 0xc53070d3 bcmwl5_sys_drv_data_start(e7209ac8,c4e2a000,0,c53d1000,c539d600) at bcmwl5_sys_drv_data_start+0xe5d6 x86_stdcall_wrap_end(c521d000,0,c,0,0) at x86_stdcall_wrap_end+0x1e ndis_attach(c4bb9300,c4c305a0,5,13,4312) at ndis_attach+0x17c ndis_attach_pci(c4bb9300) at ndis_attach_pci+0x374 device_attach(c4bb9300,c4bb9300,c4bb9300,0,c4ba8700) at device_attach+0x58 device_probe_and_attach(c4bb9300,c4bb9300,c4ba8700) at device_probe_and_attach+0xc4 pci_driver_added(c4bba100,c5356244) at pci_driver_added+0xd1 devclass_add_driver(c4b08440,c5356244,c52df600,c535630c,c4c25070) at devclass_add_driver+0xb7 driver_module_handler(c52df600,0,c5356318,c0872440,0) at driver_module_handler+0x59 module_register_init(c535630c) at module_register_init+0x4b linker_file_sysinit(c51ece00,c51ece00,1,c51ece00,c4c25070) at linker_file_sysinit+0x7d linker_load_file(c4c25070,e7209ca0,400,0,c4bd9800) at linker_load_file+0xce linker_load_module(c4bd9800,0,0,0,e7209ccc) at linker_load_module+0xa3 kldload(c4e06a80,e7209d04,1,0,292) at kldload+0xeb syscall(3b,3b,3b,1,bfbfec88) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (304, FreeBSD ELF32, kldload), eip = 0x280bab77, esp = 0xbfbfebfc, ebp = 0xbfbfec38 --- db Did somebody successfully use ndisgen generated driver for Dell Wireless 1490 802.11a/g Dual-band Mini Card? thanks in advance, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
bcm4310 wireless in Dell lattitude D620
Hi, Does FreeBSD 6.1-STABLE/7.0-CURRENT support Broadcom bcm4310 uart wireless card natively? PCI prob under FreeBSD 6.1-RELEASE: [EMAIL PROTECTED]:0:0:class=0x028000 card=0x00071028 chip=0x431214e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 UART' class= network If not does anybody make it work by using ndiswrapper? thanks in advance, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
Pyun YongHyeon wrote: On Mon, May 08, 2006 at 01:15:54PM +0900, Ganbold wrote: Pyun, Pyun YongHyeon wrote: On Tue, Mar 28, 2006 at 04:22:15PM +0200, Wilko Bulte wrote: On Mon, Mar 27, 2006 at 07:48:46PM -0800, Clint Olsen wrote.. On Mar 28, Pyun YongHyeon wrote: and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. I'm still seeing the watchdog timeout on 5.5-PRERELEASE (uni-processor): Mar 22 14:47:04 belle kernel: sk0: watchdog timeout Mar 24 08:37:19 belle kernel: sk0: watchdog timeout Mar 27 04:09:15 belle kernel: sk0: watchdog timeout But at least the driver doesn't wedge the interface now. Yes, same here on 6.1-PRERELEASE: ch0: 10 slots, 1 drive, 1 picker, 0 portals sk0: watchdog timeout sk0: watchdog timeout Ok, here is a new patch that try to fix the watchdog timeout error. I don't know it will eradicate the bug as I don't see the watchdog error on my system. The patch borrowed Yukon specific register definition from Linux driver and adopted Yukon FIFO related operations from Linux. I don't know exact meaning of the registers(it's just guessing) but it seems it doesn't hurt on my system. You may have to download 4 files to build the driver. http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test2/if_skreg.h http://people.freebsd.org/~yongari/sk/sk_test2/xmaciireg.h http://people.freebsd.org/~yongari/sk/sk_test2/yukonreg.h I compiled new sk driver on 6.1-RC, however I couldn't get it work. When I load module I get: May 8 12:04:56 proxy kernel: skc0: Marvell Gigabit Ethernet port 0xcc00-0xccff mem 0xfe3fc000-0xfe3f irq 20 at device 3.0 on pci6 May 8 12:04:56 proxy kernel: skc0: unknown media type: 0x31 May 8 12:04:56 proxy kernel: device_attach: skc0 attach returned 6 FYI: Fix committed to HEAD. Thanks a lot. Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
Pyun,
I can not apply the patch cleanly on
http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c
What version of sk driver should I use?
Ganbold
Pyun YongHyeon wrote:
On Mon, May 08, 2006 at 02:25:48PM +0900, Ganbold wrote:
Pyun YongHyeon wrote:
On Mon, May 08, 2006 at 01:15:54PM +0900, Ganbold wrote:
Pyun,
...
Is this NIC supported by if_sk driver?
Hmm, It seems that the NIC is SysKonnect V2.0(SK98XX2) which is
supposed to work with sk(4). Did it ever work with sk(4)?
No, it is new server and it came with such additional NIC.
I see there is differences between sk(4) and Linux skge driver
in determining physical media type. It seems OpenBSD also
used Linux skge approach.
I'll try to take a look at linux/openbsd drivers.
How about attached one? It's not tested but it may help your
situation.
Ganbold
thanks,
Ganbold
--- if_sk.c.origThu May 4 10:27:39 2006
+++ if_sk.c Mon May 8 14:48:33 2006
@@ -1604,14 +1604,15 @@
}
} else {
if (sc_if-sk_phytype SK_PHYTYPE_MARV_COPPER
- sc-sk_pmd == IFM_1000_T) {
+ sc-sk_pmd != 'S') {
/* not initialized, punt */
sc_if-sk_phytype = SK_PHYTYPE_MARV_COPPER;
+ sc-sk_coppertype = 1;
}
sc_if-sk_phyaddr = SK_PHYADDR_MARV;
- if (sc-sk_pmd != IFM_1000_T sc-sk_pmd != IFM_1000_CX)
+ if (!(sc-sk_coppertype))
sc_if-sk_phytype = SK_PHYTYPE_MARV_FIBER;
}
@@ -1788,31 +1789,12 @@
}
/* Read and save physical media type */
- switch(sk_win_read_1(sc, SK_PMDTYPE)) {
- case SK_PMD_1000BASESX:
- sc-sk_pmd = IFM_1000_SX;
- break;
- case SK_PMD_1000BASELX:
- sc-sk_pmd = IFM_1000_LX;
- break;
- case SK_PMD_1000BASECX:
- sc-sk_pmd = IFM_1000_CX;
- break;
- case SK_PMD_1000BASETX:
- sc-sk_pmd = IFM_1000_T;
- break;
- default:
- if (SK_YUKON_FAMILY(sc-sk_type) (sk_win_read_1(sc, SK_EPROM1)
- 0xF) SK_PHYTYPE_MARV_COPPER) {
- /* not initialized, punt */
- sc-sk_pmd = IFM_1000_T;
- break;
- }
- device_printf(dev, unknown media type: 0x%x\n,
- sk_win_read_1(sc, SK_PMDTYPE));
- error = ENXIO;
- goto fail;
- }
+sc-sk_pmd = sk_win_read_1(sc, SK_PMDTYPE);
+
+if (sc-sk_pmd == 'T' || sc-sk_pmd == '1')
+sc-sk_coppertype = 1;
+else
+sc-sk_coppertype = 0;
/* Determine whether to name it with VPD PN or just make it up.
* Marvell Yukon VPD PN seems to freqently be bogus. */
@@ -3722,17 +3704,10 @@
phy = SK_GPHY_INT_POL_HI | SK_GPHY_DIS_FC | SK_GPHY_DIS_SLEEP |
SK_GPHY_ENA_XC | SK_GPHY_ANEG_ALL | SK_GPHY_ENA_PAUSE;
- switch(sc_if-sk_softc-sk_pmd) {
- case IFM_1000_SX:
- case IFM_1000_LX:
- phy |= SK_GPHY_FIBER;
- break;
-
- case IFM_1000_CX:
- case IFM_1000_T:
+ if (sc-sk_coppertype)
phy |= SK_GPHY_COPPER;
- break;
- }
+ else
+ phy |= SK_GPHY_FIBER;
SK_IF_WRITE_4(sc_if, 0, SK_GPHY_CTRL, phy | SK_GPHY_RESET_SET);
DELAY(1000);
--- if_skreg.h.orig Tue May 2 11:12:42 2006
+++ if_skreg.h Mon May 8 14:48:33 2006
@@ -1535,6 +1535,7 @@
u_int32_t sk_rboff; /* RAMbuffer offset */
u_int32_t sk_ramsize; /* amount of RAM on NIC */
u_int32_t sk_pmd; /* physical media type */
+ u_int32_t sk_coppertype;
u_int32_t sk_intrmask;
int sk_int_mod;
int sk_int_ticks;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:13:28PM +0900, Ganbold wrote: Pyun, I can not apply the patch cleanly on http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c What version of sk driver should I use? The patch was generated against HEAD. I see, but how can I MFC to RELENG_6? I can't build it on RELENG_6. thanks, Ganbold Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:51:55PM +0900, Ganbold wrote: Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:13:28PM +0900, Ganbold wrote: Pyun, I can not apply the patch cleanly on http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c What version of sk driver should I use? The patch was generated against HEAD. I see, but how can I MFC to RELENG_6? I can't build it on RELENG_6. Ok, copy the following files to /sys/dev/sk.(You may need to create the directory on 6.x.) From the files in http://people.freebsd.org/~yongari/sk/sk_test2/ if_sk.c -- /sys/dev/sk if_skreg.h -- /sys/dev/sk xmaciireg.h -- /sys/dev/sk yukonreg.h -- /sys/dev/sk And Makefile-- /sys/modules/sk Still can't compile. cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/sk/../../dev/sk/if_sk.c In file included from /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:130: @/dev/sk/if_skreg.h:995:15: no newline at end of file /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:146: error: elements of array `sk_devs' have incomplete type /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: excess elements in struct initializer /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: (near initialization for `sk_devs[0]') /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:149: warning: excess elements in struct initializer /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:149: warning: (near initialization for `sk_devs[0]') ... Ganbold thanks, Ganbold Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
re driver problem (RTL8169 chipset)
Hi, I'm having trouble to make my Netgear Gigabit PCI GA311 network card work in 1000baseTX in FreeBSD-6.1RC. It runs fine on 100baseTX mode with Cat5 cable, however it doesn't with Cat5e/Cat6 cabling in 100baseTX/1000baseTX mode. It simply says no carrier. The system also panics right after the boot when it is connected 100baseTX network. When I disconnect the cable the system boots fine. I will test more this card in couple of days and will try to get debug messages when panics. The card is based on Realtec 8169S chipset. [EMAIL PROTECTED]:12:0: class=0x02 card=0x311a1385 chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169 Gigabit Ethernet Adapter' class= network subclass = ethernet daemon# uname -an FreeBSD daemon.micom.mng.net 6.1-RC FreeBSD 6.1-RC #10: Wed May 3 18:03:26 ULAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAEMON i386 Is there any such known issues with re driver? thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re driver problem (RTL8169 chipset)
John-Mark Gurney wrote: Ganbold wrote this message on Mon, May 08, 2006 at 17:23 +0900: I'm having trouble to make my Netgear Gigabit PCI GA311 network card work in 1000baseTX in FreeBSD-6.1RC. It runs fine on 100baseTX mode with Cat5 cable, however it doesn't with Cat5e/Cat6 cabling in Does it work at 1000baseTX w/ Cat5 cabling? I thought Cat5 only supports 100baseTX and I didn't test 1000baseTX w/ Cat5. It is not working at 1000baseTX with Cat5e/Cat6 cabling. Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
Pyun YongHyeon wrote: On Mon, May 08, 2006 at 04:53:10PM +0900, Ganbold wrote: Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:51:55PM +0900, Ganbold wrote: Pyun YongHyeon wrote: On Mon, May 08, 2006 at 03:13:28PM +0900, Ganbold wrote: Pyun, I can not apply the patch cleanly on http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c What version of sk driver should I use? The patch was generated against HEAD. I see, but how can I MFC to RELENG_6? I can't build it on RELENG_6. Ok, copy the following files to /sys/dev/sk.(You may need to create the directory on 6.x.) From the files in http://people.freebsd.org/~yongari/sk/sk_test2/ if_sk.c -- /sys/dev/sk if_skreg.h -- /sys/dev/sk xmaciireg.h -- /sys/dev/sk yukonreg.h -- /sys/dev/sk And Makefile-- /sys/modules/sk Still can't compile. cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/sk/../../dev/sk/if_sk.c In file included from /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:130: @/dev/sk/if_skreg.h:995:15: no newline at end of file I can't understand. There *IS* a newline at the end of file. Checking with hd(1) shows a newline character. If it break it should also break HEAD tinderbox too. I think new line is not a problem. The problematic line says /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:146: error: elements of array `sk_devs' have incomplete type daemon# make Warning: Object directory not changed from original /usr/src/sys/modules/sk cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/sk/../../dev/sk/if_sk.c /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:146: error: elements of array `sk_devs' have incomplete type /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: excess elements in struct initializer ... Ganbold /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:146: error: elements of array `sk_devs' have incomplete type /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: excess elements in struct initializer /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:148: warning: (near initialization for `sk_devs[0]') /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:149: warning: excess elements in struct initializer /usr/src/sys/modules/sk/../../dev/sk/if_sk.c:149: warning: (near initialization for `sk_devs[0]') ... Ganbold thanks, Ganbold Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re driver problem (RTL8169 chipset)
John-Mark Gurney wrote: Ganbold wrote this message on Mon, May 08, 2006 at 17:35 +0900: John-Mark Gurney wrote: Ganbold wrote this message on Mon, May 08, 2006 at 17:23 +0900: I'm having trouble to make my Netgear Gigabit PCI GA311 network card work in 1000baseTX in FreeBSD-6.1RC. It runs fine on 100baseTX mode with Cat5 cable, however it doesn't with Cat5e/Cat6 cabling in Does it work at 1000baseTX w/ Cat5 cabling? I thought Cat5 only supports 100baseTX and I didn't test 1000baseTX w/ Cat5. Nope, 1000Base-T (no X) is speced for Cat5 cabling.. As per the 802.3 spec 40.1: 1000BASE-T signaling requires four pairs of Category 5 balanced cabling, as specified in ISO/IEC 11801:1995 and ANSI/EIA/TIA-568-A (1995) and tested for the additional performance parameters specified in 40.7 using testing procedures defined in proposed ANSI/TIA/EIA TSB95. Ok. It is not working at 1000baseTX with Cat5e/Cat6 cabling. It's wierd that it works at 100Base-TX w/ Cat5, but not w/ Cat5e... Is there differences in the cable length or something? Not much difference. Have you tried w/ just normal Cat5? Ok, I will test it again in couple of days and let you know. Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
Pyun, Pyun YongHyeon wrote: On Tue, Mar 28, 2006 at 04:22:15PM +0200, Wilko Bulte wrote: On Mon, Mar 27, 2006 at 07:48:46PM -0800, Clint Olsen wrote.. On Mar 28, Pyun YongHyeon wrote: and sparc64(SMP) and I never see above errors. The only issue known to me is occasional watchdog timeout error which I really want to fix. But the watchdog timeout error is hard to reproduce and I couldn't reproduce the error on my system. I'm still seeing the watchdog timeout on 5.5-PRERELEASE (uni-processor): Mar 22 14:47:04 belle kernel: sk0: watchdog timeout Mar 24 08:37:19 belle kernel: sk0: watchdog timeout Mar 27 04:09:15 belle kernel: sk0: watchdog timeout But at least the driver doesn't wedge the interface now. Yes, same here on 6.1-PRERELEASE: ch0: 10 slots, 1 drive, 1 picker, 0 portals sk0: watchdog timeout sk0: watchdog timeout Ok, here is a new patch that try to fix the watchdog timeout error. I don't know it will eradicate the bug as I don't see the watchdog error on my system. The patch borrowed Yukon specific register definition from Linux driver and adopted Yukon FIFO related operations from Linux. I don't know exact meaning of the registers(it's just guessing) but it seems it doesn't hurt on my system. You may have to download 4 files to build the driver. http://people.freebsd.org/~yongari/sk/sk_test2/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test2/if_skreg.h http://people.freebsd.org/~yongari/sk/sk_test2/xmaciireg.h http://people.freebsd.org/~yongari/sk/sk_test2/yukonreg.h I compiled new sk driver on 6.1-RC, however I couldn't get it work. When I load module I get: May 8 12:04:56 proxy kernel: skc0: Marvell Gigabit Ethernet port 0xcc00-0xccff mem 0xfe3fc000-0xfe3f irq 20 at device 3.0 on pci6 May 8 12:04:56 proxy kernel: skc0: unknown media type: 0x31 May 8 12:04:56 proxy kernel: device_attach: skc0 attach returned 6 Machine: FreeBSD 6.1-RC #1: Mon May 8 11:40:01 ULAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PROXY ACPI APIC Table: DELL PE1800 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2010NX,LM Logical CPUs per core: 2 real memory = 1073479680 (1023 MB) avail memory = 1041559552 (993 MB) ... pciconf -lv ... [EMAIL PROTECTED]:3:0: class=0x02 card=0x432011ab chip=0x432011ab rev=0x14 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8001/8003/8010 Gigabit Ethernet Controller with Integrated PHY (copper)' class= network subclass = ethernet ... Is this NIC supported by if_sk driver? thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new sk driver [was: nve timeout (and down) regression?]
Pyun YongHyeon wrote: On Mon, May 08, 2006 at 01:15:54PM +0900, Ganbold wrote: Pyun, ... Is this NIC supported by if_sk driver? Hmm, It seems that the NIC is SysKonnect V2.0(SK98XX2) which is supposed to work with sk(4). Did it ever work with sk(4)? No, it is new server and it came with such additional NIC. I see there is differences between sk(4) and Linux skge driver in determining physical media type. It seems OpenBSD also used Linux skge approach. I'll try to take a look at linux/openbsd drivers. Ganbold thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contigmalloc() lameness (Re: boot problem in HP Proliant ML370 G4)
Kris Kennaway wrote: On Mon, Apr 03, 2006 at 02:27:31PM +0900, Ganbold wrote: Kris Kennaway wrote: On Mon, Apr 03, 2006 at 12:56:57PM +0900, Ganbold wrote: Here is dmes.boot and pciconf output on FreeBSD-6.0-RELEASE. Boot takes 3-4 minutes after da0: 140014MB (286749488 512 byte sectors: 255H 63S/T 17849C) line and continues. I will try to upgrade again to 6.1-PRERELEASE later today. I did before and the problem still was there. The mpt driver calls contigmalloc in a way that takes ages to run because it was poorly rewritten some time ago. Scottl partially fixed it on 7.0 (after the problem became much worse there - it was taking over 40 minutes instead of 4) but the change is not complete enough to back-port yet. I see. Yes, it eventually becomes up after 3-4 minutes. However what annoying is every time I reboot/restart the server I have to manually press Enter key. How can I resolve this issue? Please explain what you mean: why do you have to manually press Enter? It is not booting, - appears on screen and waits forever. When I press Enter key on keyboard it starts booting. Ganbold Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contigmalloc() lameness (Re: boot problem in HP Proliant ML370 G4)
Kris Kennaway wrote: On Mon, Apr 03, 2006 at 03:15:54PM +0900, Ganbold wrote: Kris Kennaway wrote: On Mon, Apr 03, 2006 at 02:27:31PM +0900, Ganbold wrote: Kris Kennaway wrote: On Mon, Apr 03, 2006 at 12:56:57PM +0900, Ganbold wrote: Here is dmes.boot and pciconf output on FreeBSD-6.0-RELEASE. Boot takes 3-4 minutes after da0: 140014MB (286749488 512 byte sectors: 255H 63S/T 17849C) line and continues. I will try to upgrade again to 6.1-PRERELEASE later today. I did before and the problem still was there. The mpt driver calls contigmalloc in a way that takes ages to run because it was poorly rewritten some time ago. Scottl partially fixed it on 7.0 (after the problem became much worse there - it was taking over 40 minutes instead of 4) but the change is not complete enough to back-port yet. I see. Yes, it eventually becomes up after 3-4 minutes. However what annoying is every time I reboot/restart the server I have to manually press Enter key. How can I resolve this issue? Please explain what you mean: why do you have to manually press Enter? It is not booting, - appears on screen and waits forever. When I press Enter key on keyboard it starts booting. That's a completely separate issue. I don't know why it's happening though. Same problem exists under FreeBSD-6.1-PRERELEASE, machine is not booting, - appears on screen and waits forever. When I press Enter key on keyboard it starts booting. On CURRENT even worse, I tested yesterday's CURRENT, boot panics saying CPU class not configured. Ganbold Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: boot problem in HP Proliant ML370 G4
= '6700PXH PCI Express-to-PCI Express Bridge A' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:0:2: class=0x060400 card=0x0044 chip=0x032a8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = '6700PXH PCI Express-to-PCI Express Bridge B' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:3:0: class=0x01 card=0x00da0e11 chip=0x00301000 rev=0x08 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class= mass storage subclass = SCSI [EMAIL PROTECTED]:3:1: class=0x01 card=0x00da0e11 chip=0x00301000 rev=0x08 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class= mass storage subclass = SCSI [EMAIL PROTECTED]:3:0: class=0x02 card=0x00cb0e11 chip=0x16c714e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5703A3 NetXtreme Gigabit Ethernet' class= network subclass = ethernet [EMAIL PROTECTED]:3:0: class=0x03 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Rage XL PCI' class= display subclass = VGA [EMAIL PROTECTED]:4:0: class=0x088000 card=0xb2060e11 chip=0xb2030e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'iLo Integrated Lights Out Processor' class= base peripheral [EMAIL PROTECTED]:4:2: class=0x088000 card=0xb2060e11 chip=0xb2040e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'iLo Integrated Lights Out Processor' class= base peripheral Ganbold Matthew Jacob wrote: insufficient info On 3/30/06, Ganbold [EMAIL PROTECTED] wrote: Hi, I have strange problem when booting FreeBSD-6.x in HP Proliant ML370 G4. The problem is - appears on the screen and it never boots unless somebody hits the Enter key. Sometimes even PS2 keyboard doesn't respond during that time. Tried with USB keyboard, same problem. The machine has dual Xeon 3.2 GHz, 1GB of RAM and LSI Logic (mpt-5.0.5.20.00 bios) LSI1030-IT controller and one Compaq BD1468A4B5 146GB SCSI disk. It didn't even boot with WITNESS and INVARIANTS options, scrolls very fast and forever showing some SCSI stuffs. How to solve this problem? Does anybody have this kind of issues before? thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contigmalloc() lameness (Re: boot problem in HP Proliant ML370 G4)
Kris Kennaway wrote: On Mon, Apr 03, 2006 at 12:56:57PM +0900, Ganbold wrote: Here is dmes.boot and pciconf output on FreeBSD-6.0-RELEASE. Boot takes 3-4 minutes after da0: 140014MB (286749488 512 byte sectors: 255H 63S/T 17849C) line and continues. I will try to upgrade again to 6.1-PRERELEASE later today. I did before and the problem still was there. The mpt driver calls contigmalloc in a way that takes ages to run because it was poorly rewritten some time ago. Scottl partially fixed it on 7.0 (after the problem became much worse there - it was taking over 40 minutes instead of 4) but the change is not complete enough to back-port yet. I see. Yes, it eventually becomes up after 3-4 minutes. However what annoying is every time I reboot/restart the server I have to manually press Enter key. How can I resolve this issue? Is there any known solution? In any case I will try first RELENG_6 then CURRENT on this machine. thanks, Ganbold Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jail's not dying ... but not running either ...
Hi, I'm seeing this jail problem too in my FreeBSD-6.1-PRERELEASE. sensor# uname -an FreeBSD xxx.mng.net 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Thu Feb 2 17:00:42 ULAT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/xxx i386 # jls JID IP Address Hostname Path 6 202.179.x.x test.ub.mng.net /usr/local/public 3 202.179.x.x test.ub.mng.net /usr/local/public # pgrep -j 6 98354 32112 32104 32069 32055 32048 31924 # pgrep -j 3 # pkill -j 3 # jls JID IP Address Hostname Path 6 202.179.x.x test.ub.mng.net /usr/local/public 3 202.179.x.x test.ub.mng.net /usr/local/public # Ganbold Bjoern A. Zeeb wrote: On Thu, 30 Mar 2006, Marc G. Fournier wrote: Hi, Running RELENG_6, I started up a jail, killed it from within doing 'kill -TERM -1' like I've always done, but apparently that isn't the right way? .. So, what is keeping those 2 listed? see http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
boot problem in HP Proliant ML370 G4
Hi, I have strange problem when booting FreeBSD-6.x in HP Proliant ML370 G4. The problem is - appears on the screen and it never boots unless somebody hits the Enter key. Sometimes even PS2 keyboard doesn't respond during that time. Tried with USB keyboard, same problem. The machine has dual Xeon 3.2 GHz, 1GB of RAM and LSI Logic (mpt-5.0.5.20.00 bios) LSI1030-IT controller and one Compaq BD1468A4B5 146GB SCSI disk. It didn't even boot with WITNESS and INVARIANTS options, scrolls very fast and forever showing some SCSI stuffs. How to solve this problem? Does anybody have this kind of issues before? thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.0 on ASUS A8N-SLI motherboard
Hi, Are there any issues running FreeBSD 6.0-STABLE (i386 or amd64 version) on machine with ASUS A8N-SLI motherboard? It has NVIDIA RAID option in BIOS and the system has 4x250GB SATA disks. I would like to use its RAID feature if possible, otherwise I'll try gmirror. Please let me know if somebody has experience about it. thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Marvell/SysKonnect YukonII source code available
At 09:55 AM 1/25/2006, you wrote: On Tue, Jan 24, 2006 at 11:19:05AM +0100, Andre Oppermann wrote: Marvell/SysKonnect made the source code to the YukonII chips available today under a BSD license: http://people.freebsd.org/~andre/mykbsd60x86-8.12.1.3-src.tgz I haven't tested the driver yet and I don't know if it available directly from the their website already. Many thanks to Gerald and Frank at SysKonnect for working with us and making this possible! Yes, that's great news. Is there any chance to get a copy of data sheet for Yukon chips? I've tried hard to make Rx TCP/UDP checksum offload work but failed. ATM both Linux and OpenBSD use Rx IP checksum offload only but this driver enabled Rx checksum offload for TCP/UDP. So I guess there is somthing not listed in SK-NET Genesis data sheet. :-( Quick reading the source shows that this driver has the following issues. 1. Incomplete bus_dma(9) support. The driver uses BUS_SPACE_MAXADDR when it creates DMA tags which means its DMA supports any address without limitations. However, I'm sure Rx/Tx descriptors should reside in 4GB. So the driver wouldn't work on systems with 4GB memory. 2. Since the driver makes use of mbpool(9) it wouldn't work when bounce buffers are involved. In fact, I think the use of mbpool(9) is really bad as it lacks bus_dmamap_sync(9) operation. 3. Lack of ALTQ support. 4. The driver may not work on big-endian architectures. 5. The driver may not work on architectures with strict-alignment. Btw, new sk(4) is availabe at the following URL. Due to lack of documentation it doesn't support YukonII yet. http://people.freebsd.org/~yongari/sk/if_sk.c http://people.freebsd.org/~yongari/sk/if_skreg.h I'm still having sk0: watchdog timeout in my system and I'll try new sk driver. I will let you know if there is any issue. Ganbold -- Regards, Pyun YongHyeon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Marvell/SysKonnect YukonII source code available
At 09:55 AM 1/25/2006, you wrote: Btw, new sk(4) is availabe at the following URL. Due to lack of documentation it doesn't support YukonII yet. http://people.freebsd.org/~yongari/sk/if_sk.c http://people.freebsd.org/~yongari/sk/if_skreg.h Pyun, I'm confused, I got drivers dated back Jan 19, however above are dated Jan 17. And I'm still getting: Jan 24 15:30:40 gw kernel: sk0: watchdog timeout Jan 24 15:30:40 gw kernel: fxp0: device timeout errors. Ganbold -- Regards, Pyun YongHyeon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Marvell/SysKonnect YukonII source code available
At 10:27 AM 1/25/2006, you wrote: On Wed, Jan 25, 2006 at 10:15:11AM +0800, Ganbold wrote: At 09:55 AM 1/25/2006, you wrote: Btw, new sk(4) is availabe at the following URL. Due to lack of documentation it doesn't support YukonII yet. http://people.freebsd.org/~yongari/sk/if_sk.c http://people.freebsd.org/~yongari/sk/if_skreg.h Pyun, I'm confused, I got drivers dated back Jan 19, however above are dated Jan 17. And I'm still getting: Jan 24 15:30:40 gw kernel: sk0: watchdog timeout Jan 24 15:30:40 gw kernel: fxp0: device timeout errors. Ganbold Did you use expeimental code in http://people.freebsd.org/~yongari/sk/sk_test/ ? Yes. If the driver still emit watchdong timeout I have no idea atm. I've never met such errors but I suffered from mbuf cluster leak on CURRENT. I believe the leak comes from kernel not sk(4) as it also happens em(4) on i386 SMP. When you see the error would you check mbuf status with netstat(1)? Actually I can't because I'm connecting to this machine remotely and external NIC fxp also times out. Ganbold -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp0: device timeout and sk0: watchdog timeout problems, onboard pcn problem
At 06:08 PM 1/19/2006, you wrote: hi maybe a stupid hint but did you checked the TP cable and pin order? I often saw such problems when a gigabit connected to an older /10 HUB or when using incorrect pin orders on the cables or even to long cables I will ask person to check the cables. Appearently the sk down events are gone on my server with Pyun's patched drivers, did you checked if you compiled with them in the right place? I put sk drivers in /usr/src/sys/pci and compiled and installed kernel again. My servers are now almost 24h up with the new sk driver and none of them is having the problem any more until now. Until this I had crontab run ifconfig sk0 up all 10 minutes what helped me so long. ifconffig sk0 up might be the solution until I find the problem. On my SMP system when sk stopped it caused also watchdog timeout on all other NICs, on UP kernel not. This system is SMP system, so I guess that is why fxp is timing out too. Do you use interface polling? Check with vmstat -i because you may have overlapping IRQs and you cards may not support it. Look into the MB manual and see which pci slots are shared and don't use them or try another bios setting. What MB you are using? It is not using polling. I should ask the person to check the MB. gw# vmstat -i interrupt total rate irq1: atkbd0 188 0 irq6: fdc010 0 irq13: npx01 0 irq14: ata01 0 irq16: ahc0 ahc1 56984 41 irq18: skc0 ohci0 411469300 irq19: fxp0 104891 76 cpu0: timer 2738746 1997 cpu1: timer 2720830 1984 Total6033120 4400 you may try ifconfig fxp link0 to load its microcode which could help but in my opinion and experience the fxp cards are bad when using more than one and I through them all out but interesting is that they work well on until releng_5, btw the sk also works well on releng_5 Yes, I have at least several machines running FreeBSD-5.3 with 2 fxp cards and they seem to be OK. Also I have another 2 FreeBSD 6.0 machine with 2 fxp NIC and they are also fine. I tried onboard pcn card: [EMAIL PROTECTED]:9:0: class=0x02 card=0x20001014 chip=0x20001022 rev=0x36 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Am79C970/1/2/3/5/6 PCnet LANCE PCI Ethernet Controller' class= network subclass = ethernet However system crashes after connecting the cable. After reboot it is the same, crashes. Ganbold João ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp0: device timeout and sk0: watchdog timeout problems
I have same problem even after updating the sk code to the latest: Jan 19 12:58:53 gw kernel: fxp0: device timeout Jan 19 12:59:10 gw kernel: sk0: watchdog timeout Jan 19 12:59:10 gw kernel: sk0: link state changed to DOWN Jan 19 12:59:20 gw kernel: fxp0: device timeout Jan 19 12:59:52 gw kernel: fxp0: device timeout Jan 19 13:00:23 gw kernel: fxp0: device timeout Jan 19 13:00:29 gw kernel: sk0: watchdog timeout Jan 19 13:00:52 gw kernel: fxp0: device timeout Jan 19 13:01:05 gw kernel: sk0: watchdog timeout Ganbold At 10:36 AM 1/18/2006, you wrote: On Wed, Jan 18, 2006 at 10:28:43AM +0800, Ganbold wrote: At 09:55 AM 1/18/2006, you wrote: inet 127.0.0.1 netmask 0xff00 I used new if_sk codes from Pyun YongHyeon but after 2 days I got same problem device timeout. fxp is also timing out and I don't know why. Any idea? If sk(4) is the cause of problem fxp wouldn't be affected. I guess so. But fxp also times out almost at same time as sk does. Of course it's possible for sk(4) to corrupt kernel memory structure but the possibility is low. While fixing sk(4) I pushed sk(4) to the limit on sparc64. I never met such timeouts. atm I have no clue. How about updated sk(4)? http://people.freebsd.org/~yongari/sk/if_sk.c http://people.freebsd.org/~yongari/sk/if_skreg.h Is it new update? Because I used your update dated on Jan 12 2006. Is it newer than that? Yes. Disabling sk(4) remedy your issue? There is another on-board pcn NIC, I will try if problem exists with sk driver. Ok. Thank you. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp0: device timeout and sk0: watchdog timeout problems
Hi, At 03:16 PM 1/19/2006, you wrote: On Thu, Jan 19, 2006 at 02:14:13PM +0800, Ganbold wrote: I have same problem even after updating the sk code to the latest: Jan 19 12:58:53 gw kernel: fxp0: device timeout Jan 19 12:59:10 gw kernel: sk0: watchdog timeout Jan 19 12:59:10 gw kernel: sk0: link state changed to DOWN Does interface down and up help your situation? This server is located 370km from where I'm now. People there just reboot the server. It would be great to know what mwchan is used if your application was blocked. mwchan? Would you try another onboard NIC with fxp to narrow down the issue? Hard to say since it is on remote site. I could ask person there. Since it's hard to reproduce the problem on my system I need more information. Would you show me more information for your network configuration and how to reproduce it? This machine is doing NAT, ipfw and it has squid from ports. It seems like 3GB-9GB web traffic is going through per day. gw# ifconfig -a sk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=2bRXCSUM,TXCSUM,VLAN_MTU,JUMBO_MTU inet 175.176.1.11 netmask 0x broadcast 175.176.255.255 ether 00:11:95:e1:7d:16 media: Ethernet autoselect (1000baseTX full-duplex,flag0,flag1) status: active pcn0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 ether 00:06:29:50:e2:3c media: Ethernet autoselect (none) status: no carrier fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet x.x.x.x netmask 0xfff0 broadcast x.x.x.x ether 00:03:47:e0:64:3c media: Ethernet autoselect (100baseTX full-duplex) status: active Other onboard NIC is pcn: [EMAIL PROTECTED]:9:0: class=0x02 card=0x20001014 chip=0x20001022 rev=0x36 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Am79C970/1/2/3/5/6 PCnet LANCE PCI Ethernet Controller' class= network subclass = ethernet I heard this card also might have some problems, but I'm not sure. Correct me if I'm wrong. Ganbold -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
fxp0: device timeout and sk0: watchdog timeout problems
: type 16550A pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xc7fff,0xcd000-0xce7ff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec IP Filter: v4.1.8 initialized. Default = pass all, Logging = enabled ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, logging limited to 100 packets/ entry by default Waiting 5 seconds for SCSI devices to settle ses0 at ahc1 bus 0 target 14 lun 0 ses0: SDR GEM200 2 Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device da0 at ahc1 bus 0 target 0 lun 0 da0: IBM DPSS-318350M S96H Fixed Direct Access SCSI-3 device da0: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/da0s1a ifconfig output: sk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 175.176.1.11 netmask 0x broadcast 175.176.255.255 ether 00:11:95:e1:7d:16 media: Ethernet autoselect (1000baseTX full-duplex,flag0,flag1) status: active fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 202.72.245.xxx netmask 0xfff0 broadcast 202.72.245.xxx ether 00:03:47:e0:64:3c media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 I used new if_sk codes from Pyun YongHyeon but after 2 days I got same problem device timeout. fxp is also timing out and I don't know why. Any idea? thanks, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp0: device timeout and sk0: watchdog timeout problems
At 09:55 AM 1/18/2006, you wrote: inet 127.0.0.1 netmask 0xff00 I used new if_sk codes from Pyun YongHyeon but after 2 days I got same problem device timeout. fxp is also timing out and I don't know why. Any idea? If sk(4) is the cause of problem fxp wouldn't be affected. I guess so. But fxp also times out almost at same time as sk does. Of course it's possible for sk(4) to corrupt kernel memory structure but the possibility is low. While fixing sk(4) I pushed sk(4) to the limit on sparc64. I never met such timeouts. atm I have no clue. How about updated sk(4)? http://people.freebsd.org/~yongari/sk/if_sk.c http://people.freebsd.org/~yongari/sk/if_skreg.h Is it new update? Because I used your update dated on Jan 12 2006. Is it newer than that? Disabling sk(4) remedy your issue? There is another on-board pcn NIC, I will try if problem exists with sk driver. Ganbold. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
TFTP server problem
Hi Robert and all, I'm really sorry for my cross posting, I posted my problem a year ago and I'm still having trouble with tftp server. I switched to Windows tftp server like 3Com 3C daemon for a while and now I want to use tftp server on FreeBSD. I'm using FreeBSD 5.4-STABLE and I tested default tftp server in inetd.conf with options -s and -l. tftp dgram udp waitroot/usr/libexec/tftpd tftpd -s /tftpboot -l Tftp server hangs after some time (6-7 hours or less) and it seems like entire tftp server stops responding because audio files stopped playing. I would like to use tftp server for IVR with Cisco. I didn't try to use second client while it was not responding. What flags do you recommend in inetd.conf? How to debug tftpd? Is there any other tftp server which is good for IVR? tia, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
Hi, Since we are discussing AMD64 with 8GB RAM, I also would like to point my problem. I'm still looking for possibility to run FreeBSD 5.3-STABLE with more than 4GB RAM on Dual amd64 2.2GHz machine (IBM @server 325) with ServeRAID 6M (ips driver)). Right now I'm using only 4GB RAM and this server is in production. #uname -an FreeBSD publica.ub.mng.net 5.3-STABLE FreeBSD 5.3-STABLE #12: Mon Nov 22 12:04:57 ULAT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AMD amd64 As Scott said a few months ago, problem is below: The ips driver looks like it will fail under heavy load when more than 4GB of RAM is present. It tries to force busdma to not defer requests when the bounce page reserve is low, but that looks to be broken and will result in corrupted commands. Are the ips driver and bus_dma problems fixed yet in STABLE tree? Is it worth to try source update and see how it works? I'm afraid to do so, since it is production server. Please see my previous posts: http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-December/044325.html http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041003.html http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041005.html http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041013.html http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041015.html http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041094.html http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041112.html http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041164.html http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041258.html http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041554.html dmesg: http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041265.html thanks in advance, Ganbold ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
