msdosfs destroys files upon opening them
I thought this was a problem of Gimp, but the trace shows that it does read only operation. Since PRs currently don't work, I will link you to the original PR for Gimp: http://bugzilla.gnome.org/show_bug.cgi?id=376687 I still have the files and the traces and am willing to give them to anyone who cares. Almost forgot: FreeBSD mobileKamikaze.norad 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Sat Nov 11 18:44:31 CET 2006 [EMAIL PROTECTED]:/usr/obj/TPR40-6/i386/usr/src/sys/TPR40-6 i386 gimp-2.2.13_2,1 /dev/ad0s4 on /mnt/msdos/vault (msdosfs, local) Thanks to everyone who takes a look at this. I hope this will be fixed before the 6.2 Release. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: deadlock in zoneli state on 6.2-PRERELEASE
On Friday, 24 November 2006 at 11:11:48 +0800, LI Xin wrote: Nikolay Pavlov wrote: On Thursday, 23 November 2006 at 20:24:15 +0800, [EMAIL PROTECTED] wrote: Hi, On Wed, 22 Nov 2006 21:55:49 +0200, Nikolay Pavlov [EMAIL PROTECTED] wrote: Hi. It seems i have a deadlock on 6.2-PRERELEASE. This is squid server in accelerator mode. I can easily trigger it with a high rate of requests. Squid is locked on some zoneli state, i am not sure what it is. Also i can't KILL proccess even with SIGKILL. In addition one of sshd proccess is locked too. Would you please update to the latest RELENG_6 and apply this patch: http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround to see if things gets improved? Thanks in advance! Cheers, Well. This patch works quite ambiguous for me. Under heavy load this box become unresponseble via network. System is mostly idle. Squid is locked in zoneli. Another panic. Guys do i need some additional debug options or this info is enough. I am asking because this panic is easily reproduceable for me. [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ACCEL# kgdb kernel.debug /var/crash/vmcore.4 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: lock order reversal: (sleepable after non-sleepable) 1st 0xca21567c so_snd (so_snd) @ /usr/src/sys/netinet/tcp_output.c:253 2nd 0xc070bd84 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 KDB: stack backtrace: kdb_backtrace(,c071ccb0,c071c210,c06e5c4c,c0758f18,...) at kdb_backtrace+0x29 witness_checkorder(c070bd84,9,c06be56c,c02,c070d2c4,0,c06aab25,9f) at witness_checkorder+0x4cd _sx_xlock(c070bd84,c06be56c,c02) at _sx_xlock+0x2c _vm_map_lock_read(c070bd40,c06be56c,c02,184637d,c92796b0,...) at _vm_map_lock_read+0x37 vm_map_lookup(f48a29d0,0,1,f48a29d4,f48a29c4,f48a29c8,f48a29ab,f48a29ac) at vm_map_lookup+0x28 vm_fault(c070bd40,0,1,0,c927aa80,...) at vm_fault+0x65 trap_pfault(f48a2a98,0,c) at trap_pfault+0xee trap(8,c06b0028,f48a0028,1,0,...) at trap+0x325 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc053ea34, esp = 0xf48a2ad8, ebp = 0xf48a2ae4 --- m_copydata(0,,1,d0020d74,c1040468,...) at m_copydata+0x28 tcp_output(d21c5570) at tcp_output+0x9af tcp_input(d0020d00,14,e9,93935ce,0,...) at tcp_input+0x24a2 ip_input(d0020d00) at ip_input+0x561 netisr_processqueue(c075a6d8) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_execute_handlers(c9279648,c92c3400) at ithread_execute_handlers+0xce ithread_loop(c92436a0,f48a2d38,c070db20,0,c06a818a,...) at ithread_loop+0x4e fork_exit(c04f76d4,c92436a0,f48a2d38) at fork_exit+0x61 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xf48a2d6c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc053ea34 stack pointer = 0x28:0xf48a2ad8 frame pointer = 0x28:0xf48a2ae4 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 = 13 (swi1: net) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(100,c927aa80,28,f48a2a98,c,...) at kdb_backtrace+0x29 panic(c069b8a1,c06c5f2c,0,f,c927d69b,...) at panic+0xa8 trap_fatal(f48a2a98,c,c927aa80,c070bd40,0,...) at trap_fatal+0x2a6 trap_pfault(f48a2a98,0,c) at trap_pfault+0x187 trap(8,c06b0028,f48a0028,1,0,...) at trap+0x325 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc053ea34, esp = 0xf48a2ad8, ebp = 0xf48a2ae4 --- m_copydata(0,,1,d0020d74,c1040468,...) at m_copydata+0x28 tcp_output(d21c5570) at tcp_output+0x9af tcp_input(d0020d00,14,e9,93935ce,0,...) at tcp_input+0x24a2 ip_input(d0020d00) at ip_input+0x561 netisr_processqueue(c075a6d8) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_execute_handlers(c9279648,c92c3400) at ithread_execute_handlers+0xce ithread_loop(c92436a0,f48a2d38,c070db20,0,c06a818a,...) at ithread_loop+0x4e fork_exit(c04f76d4,c92436a0,f48a2d38) at fork_exit+0x61 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xf48a2d6c, ebp = 0 --- Uptime: 25m13s Dumping 3967 MB (3 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 3966MB (1015280 pages) 3950 3934 3918 3902 3886 3870 3854 3838 3822 3806 3790 3774 3758 3742 3726 3710 3694 3678
Re: UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824, MOKB-03-11-2006, CVE-2006-5679
Scott Long wrote: Kevin Oberman wrote: Date: Fri, 24 Nov 2006 15:58:39 -0700 From: Scott Long [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] David Malone wrote: These two bugs are shown for FreeBSD only and I guess, Solaris and other BSDs still use UFS. Are they more robust against this exploit or type of exploit? I don't know of a concerted effort by anyone to improve UFS in this way. I would guess that the odd bug would have been resolved, but no large scale work. David. Another thing to keep in mind is that filesystem mounting is only available to the super-user. If a feature came along such as automatically mounting USB drives, these bugs would indeed be critical. But for now, they are not. Not on the base system, but Gnome 2.16 with hald running will mount a removable device automatically. The standard configuration of Gnome runs hald. Allowing user mounts of removable media is even formalized by the addition of /media to hier(7). I'm not sure this should simply be treated as not being significant. Would it be possible to restrict Gnome to only auto-mounting msdos and cd9660 filesystems? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Sorry, if my question may sound heretic, but wouldn't it be more sophisticated solving the problem instead of disabling everything what could trigger the bug? Look, on many desktop systems, USB backup drives become very common, even eSATA backup solutions. I try to use those convenienc things eithe in lab or at home on my private machine. Mounting the file system is done via amd() and automatically as the file system gets accessed via its link point. Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824, MOKB-03-11-2006, CVE-2006-5679
On Saturday 25 November 2006 13:20, O. Hartmann wrote: Sorry, if my question may sound heretic, but wouldn't it be more sophisticated solving the problem instead of disabling everything what could trigger the bug? Look, on many desktop systems, USB backup drives become very common, even eSATA backup solutions. I try to use those convenienc things eithe in lab or at home on my private machine. Mounting the file system is done via amd() and automatically as the file system gets accessed via its link point. Accessing external (and possibly hostile) media should not be done in kernel, because 1) the system may panic and 2) the system may be compromised. When the storage driver runs in usermode and has only the user's privileges, we have much better security by design. AFAIK fuse (http://fuse4bsd.creo.hu) is an attempt to implement this. Regards, Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824, MOKB-03-11-2006, CVE-2006-5679
O. Hartmann wrote: Scott Long wrote: Kevin Oberman wrote: Date: Fri, 24 Nov 2006 15:58:39 -0700 From: Scott Long [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] David Malone wrote: These two bugs are shown for FreeBSD only and I guess, Solaris and other BSDs still use UFS. Are they more robust against this exploit or type of exploit? I don't know of a concerted effort by anyone to improve UFS in this way. I would guess that the odd bug would have been resolved, but no large scale work. David. Another thing to keep in mind is that filesystem mounting is only available to the super-user. If a feature came along such as automatically mounting USB drives, these bugs would indeed be critical. But for now, they are not. Not on the base system, but Gnome 2.16 with hald running will mount a removable device automatically. The standard configuration of Gnome runs hald. Allowing user mounts of removable media is even formalized by the addition of /media to hier(7). I'm not sure this should simply be treated as not being significant. Would it be possible to restrict Gnome to only auto-mounting msdos and cd9660 filesystems? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Sorry, if my question may sound heretic, but wouldn't it be more sophisticated solving the problem instead of disabling everything what could trigger the bug? Yup. Who do you have in mind to do it? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems unmounting/fssyncking extern UFS filesystem
A while ago since now I receive kernel messages like this in FreeBSD 6.2-PRE/AMD64: fsync: giving up on dirty 0xff000362c7c0: tag devfs, type VCHR usecount 1, writecount 0, refcount 325 mountedhere 0xff00504d8400 flags () v_object 0xff00013c80e0 ref 0 pages 1286 lock type devfs: EXCL (count 1) by thread 0xff0050287260 (pid 14109) dev ufs/BACKUP Filesystem is an external USB attached SATA HD, ohci() driven (due to ehci() is not working stable and properly on FreeBSD 6.2). Filesystem is mounted via amd() and there via the'script' option in amd() due to problems of the amd() mounting process recognizing UFS filesystems. After 30 seconds of inactivity the filesystems gets dismounted. This worked quite well in the past, but now I see this kernel error messages. Before doing a PR, I would like to serious ask whether this is an issue or not. Regards, Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
g_vfs_done():acd0[READ(offset=32768, length=2048)]error = 5
I receive this error message although no DVD/CD is in drive and this is
obviously CD/DVD drive related.
DVD/CD is mounted via amd() and there via 'script' option (doing mount
via command, not autorecognition of filesystem). See attached config files.
If this is an serious error (it appeared late in the 6.2 source/cvsup
and never seen before), please tell me, I'll then do a PR.
/etc/amd.cd
cdrom type:=program;fs:=${autodir}/${key};\
mount:=/sbin/mount mount ${fs};\
unmount:=/sbin/umount umount ${fs}
# GLOBAL OPTIONS SECTION
[ global ]
auto_dir = /.amd_mnt
log_file = /var/log/amd.log
pid_file = /var/run/amd.pid
plock = yes
restart_mounts =yes
normalize_hostnames = no
selectors_on_default = yes
print_version = no
log_options = fatal
map_type = file
search_path =/etc
fully_qualified_hosts = yes
#show_statfs_entries = yes
nfs_proto = tcp
unmount_on_exit =yes
plock = yes
dismount_interval = 15
cache_duration = 15
# MAP SECTIONS
[ /mnt/cdrom ]
map_name = amd.cd
[ /mnt/usb ]
map_name = amd.usb
[ /mnt/ext ]
map_name = amd.ext
--
O. Hartmann
Freie Universitaet Berlin
Institut fuer Geowissenschaften
Fernerkundung der Erde und Planeten
Malteser-Str. 74 - 100/Haus D
D-12249 Berlin
Tel.: +49 (0) 30 838 70 508
FAX: +49 (0) 30 838 70 837
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824, MOKB-03-11-2006, CVE-2006-5679
Scott Long wrote: O. Hartmann wrote: Scott Long wrote: Kevin Oberman wrote: Date: Fri, 24 Nov 2006 15:58:39 -0700 From: Scott Long [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] David Malone wrote: These two bugs are shown for FreeBSD only and I guess, Solaris and other BSDs still use UFS. Are they more robust against this exploit or type of exploit? I don't know of a concerted effort by anyone to improve UFS in this way. I would guess that the odd bug would have been resolved, but no large scale work. David. Another thing to keep in mind is that filesystem mounting is only available to the super-user. If a feature came along such as automatically mounting USB drives, these bugs would indeed be critical. But for now, they are not. Not on the base system, but Gnome 2.16 with hald running will mount a removable device automatically. The standard configuration of Gnome runs hald. Allowing user mounts of removable media is even formalized by the addition of /media to hier(7). I'm not sure this should simply be treated as not being significant. Would it be possible to restrict Gnome to only auto-mounting msdos and cd9660 filesystems? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Sorry, if my question may sound heretic, but wouldn't it be more sophisticated solving the problem instead of disabling everything what could trigger the bug? Yup. Who do you have in mind to do it? Scott Well, this is a good question :-( I would like to do it if the following prerequisites would be applicable: I'm familiar with OS development (no) I'm familiar with C, very close to driver layer and UFS (no) I'm willing to work for a OpenSource project (yes, of course, I use FreeBSD in scientific environment now for more than 10 years) On the other hand, Scott, where are all the Kernel developer has been gone to? Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems unmounting/fssyncking extern UFS filesystem
On Sat, Nov 25, 2006 at 05:08:03PM +0100, O. Hartmann wrote: A while ago since now I receive kernel messages like this in FreeBSD 6.2-PRE/AMD64: fsync: giving up on dirty 0xff000362c7c0: tag devfs, type VCHR usecount 1, writecount 0, refcount 325 mountedhere 0xff00504d8400 flags () v_object 0xff00013c80e0 ref 0 pages 1286 lock type devfs: EXCL (count 1) by thread 0xff0050287260 (pid 14109) dev ufs/BACKUP Filesystem is an external USB attached SATA HD, ohci() driven (due to ehci() is not working stable and properly on FreeBSD 6.2). The external USB harddisk I'm using works fine with ehci (VIA VT6202 USB 2.0 controller) on 6.2-PRERELEASE amd64: Controller /dev/usb4: addr 1: high speed, self powered, config 1, EHCI root hub(0x), VIA(0x), rev 1.00 port 1 powered port 2 addr 2: high speed, power 100 mA, config 1, Mass Storage Device(0x3507), Prolific Technology Inc.(0x067b), rev 1.00 Filesystem is mounted via amd() and there via the'script' option in amd() due to problems of the amd() mounting process recognizing UFS filesystems. After 30 seconds of inactivity the filesystems gets dismounted. This worked quite well in the past, but now I see this kernel error messages. The only problems I ever had wer with the firewire interface, not USB. But I don't use amd, and I'm using GEOM_ELI encyption. If amd doesn't work well with ufs, would using glabel be a workaround? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpxtu85cyukL.pgp Description: PGP signature
Re: UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824, MOKB-03-11-2006, CVE-2006-5679
On Sat, Nov 25, 2006 at 05:30:49PM +0100, O. Hartmann wrote: On the other hand, Scott, where are all the Kernel developer has been gone to? There is this minor task called a release cycle in process at the moment. That is where all the developer attention to -stable is going right now. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.2-PRE panic
On Fri, 24 Nov 2006, Eugene Grosbein wrote: On Fri, Nov 24, 2006 at 02:18:22PM +, Robert Watson wrote: Is there an open PR on this problem currently? I'm in the process of reviewing my outstanding network PRs for 6.2 and I'm having trouble tracking down all the pieces of this report. Has GNATS been fixed? I mean its search (by ID or single line fields). Apparently the mirror of the GNATS database on the web server had become corrupted; Ken Smith has apparently fixed this, and it looks like the database is now up-to-date again. Give it a try? 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: deadlock in zoneli state on 6.2-PRERELEASE
Nikolay Pavlov wrote: On Friday, 24 November 2006 at 11:11:48 +0800, LI Xin wrote: Nikolay Pavlov wrote: On Thursday, 23 November 2006 at 20:24:15 +0800, [EMAIL PROTECTED] wrote: Hi, On Wed, 22 Nov 2006 21:55:49 +0200, Nikolay Pavlov [EMAIL PROTECTED] wrote: Hi. It seems i have a deadlock on 6.2-PRERELEASE. This is squid server in accelerator mode. I can easily trigger it with a high rate of requests. Squid is locked on some zoneli state, i am not sure what it is. Also i can't KILL proccess even with SIGKILL. In addition one of sshd proccess is locked too. Would you please update to the latest RELENG_6 and apply this patch: http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround to see if things gets improved? Thanks in advance! Cheers, Well. This patch works quite ambiguous for me. Under heavy load this box become unresponseble via network. System is mostly idle. Squid is locked in zoneli. Another panic. Guys do i need some additional debug options or this info is enough. I am asking because this panic is easily reproduceable for me. I think these stuff is enough. By the way, which scheduler do you use? [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ACCEL# kgdb kernel.debug /var/crash/vmcore.4 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: lock order reversal: (sleepable after non-sleepable) 1st 0xca21567c so_snd (so_snd) @ /usr/src/sys/netinet/tcp_output.c:253 2nd 0xc070bd84 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 KDB: stack backtrace: kdb_backtrace(,c071ccb0,c071c210,c06e5c4c,c0758f18,...) at kdb_backtrace+0x29 witness_checkorder(c070bd84,9,c06be56c,c02,c070d2c4,0,c06aab25,9f) at witness_checkorder+0x4cd _sx_xlock(c070bd84,c06be56c,c02) at _sx_xlock+0x2c _vm_map_lock_read(c070bd40,c06be56c,c02,184637d,c92796b0,...) at _vm_map_lock_read+0x37 vm_map_lookup(f48a29d0,0,1,f48a29d4,f48a29c4,f48a29c8,f48a29ab,f48a29ac) at vm_map_lookup+0x28 vm_fault(c070bd40,0,1,0,c927aa80,...) at vm_fault+0x65 trap_pfault(f48a2a98,0,c) at trap_pfault+0xee trap(8,c06b0028,f48a0028,1,0,...) at trap+0x325 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc053ea34, esp = 0xf48a2ad8, ebp = 0xf48a2ae4 --- m_copydata(0,,1,d0020d74,c1040468,...) at m_copydata+0x28 tcp_output(d21c5570) at tcp_output+0x9af tcp_input(d0020d00,14,e9,93935ce,0,...) at tcp_input+0x24a2 ip_input(d0020d00) at ip_input+0x561 netisr_processqueue(c075a6d8) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_execute_handlers(c9279648,c92c3400) at ithread_execute_handlers+0xce ithread_loop(c92436a0,f48a2d38,c070db20,0,c06a818a,...) at ithread_loop+0x4e fork_exit(c04f76d4,c92436a0,f48a2d38) at fork_exit+0x61 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xf48a2d6c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc053ea34 stack pointer = 0x28:0xf48a2ad8 frame pointer = 0x28:0xf48a2ae4 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 = 13 (swi1: net) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(100,c927aa80,28,f48a2a98,c,...) at kdb_backtrace+0x29 panic(c069b8a1,c06c5f2c,0,f,c927d69b,...) at panic+0xa8 trap_fatal(f48a2a98,c,c927aa80,c070bd40,0,...) at trap_fatal+0x2a6 trap_pfault(f48a2a98,0,c) at trap_pfault+0x187 trap(8,c06b0028,f48a0028,1,0,...) at trap+0x325 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc053ea34, esp = 0xf48a2ad8, ebp = 0xf48a2ae4 --- m_copydata(0,,1,d0020d74,c1040468,...) at m_copydata+0x28 tcp_output(d21c5570) at tcp_output+0x9af tcp_input(d0020d00,14,e9,93935ce,0,...) at tcp_input+0x24a2 ip_input(d0020d00) at ip_input+0x561 netisr_processqueue(c075a6d8) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_execute_handlers(c9279648,c92c3400) at ithread_execute_handlers+0xce ithread_loop(c92436a0,f48a2d38,c070db20,0,c06a818a,...) at ithread_loop+0x4e fork_exit(c04f76d4,c92436a0,f48a2d38) at fork_exit+0x61 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xf48a2d6c, ebp = 0 --- Uptime: 25m13s Dumping 3967 MB (3 chunks)
6.2-RC: Problem with SATA on ASUS Vintage AH-3
Hi, When I try to boot the FreeBSD 6.2-RC kernel as of today on an ASUS Vintage AH-3 system (Athlon XP 3000+), I get a similar error message to that described in this thread: http://www.mail-archive.com/freebsd-questions@freebsd.org/msg150224.html ... i.e. atapci2: AHCI controller reset failure. I do not see this problem with 6.1-RELEASE. As the root disk for this machine is SATA, this means I cannot boot 6.2. The onboard controller is an AcerLabs M5287. A JMicron card is in the machine's single PCI-e slot which is why the onboard SATA is numbered atapci2. ATA_STATIC_ID is enabled in my kernel configuration. There is nothing connected to the JMicron card; it is detected successfully under both 6.1 and 6.2. I've attached the kernel config and a dmesg of a successful 6.1 boot. For some reason I can't get loader-time serial console to work on this machine, so regrettably can't provide a full 6.2-RC1 dmesg. Thanks for any help you can provide. Regards, BMS # # $Id$ # # Configuration for ASUS Vintage amd64 # machine amd64 cpu HAMMER ident ANGLEPOISE maxusers0 makeoptions KERNEL=kernel # Disable non-optimal GCC builtin functions makeoptions CONF_CFLAGS=-fno-builtin # Additional roll-ins makeoptions FDC_PCCARD=0#do not build pcmcia floppy support # Kernel Debugging options makeoptions DEBUG=-g#Build kernel with full symbols options INCLUDE_CONFIG_FILE #Include this file in kernel options ADAPTIVE_GIANT options KDB options KDB_TRACE #backtrace on ddb entry options GDB options DDB #Enable the kernel debugger options KTRACE #ktrace(1) support # # Only build the following modules # makeoptions MODULES_OVERRIDE=nmdm nfsclient nfsserver an speaker bridge if_gre if_disc if_faith if_gif if_tun if_sl if_ppp if_stf if_tap if_vlan ubsa ucom uvisor udbp udf uhid ukbd ulpt uscanner ums umass umodem uplcom uvscom uftdi sound/driver/ich sound/sound procfs linprocfs md vpo plip ppi lpt splash/bmp splash/pcx dummynet crypto cryptodev rndtest aio libiconv cbb cardbus exca pccard libmchain ntfs syscons/blank syscons/daemon syscons/logo fdc wlan rc4 ugen firewire firewire/sbp firewire/fwe firewire/fwip firewire/sbp_targ usb msdosfs drm/drm drm/i915 fxp ath ath_rate_amrr ath_hal netgraph/bluetooth/bluetooth netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/h4 netgraph/bluetooth/ubt netgraph/bluetooth/ubtbcmfw smbfs # Process Scheduler options SCHED_4BSD #Use the non-experimental scheduler options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions # system personalities options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options COMPAT_FREEBSD5 #Compatible with FreeBSD5 options COMPAT_IA32 options COMPAT_LINUX32 # SYSV extensions options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores # IP networking options INET#InterNETworking options INET6 #IPv6 communications protocols options ZERO_COPY_SOCKETS #enable zero copy socket code # Disk geometry (GEOM) subsystem options GEOM_MBR#i386 MBRs options GEOM_BSD#BSD disklabels options GEOM_VOL#get volume names from FFS superblock options GEOM_BDE#GEOM disk encryption #optionsGEOM_GPT# this panics kernel don't know why # FFS options options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories # Are these actually needed, for UFS2? options UFS_ACL #Support for access control lists options UFS_EXTATTR options UFS_EXTATTR_AUTOSTART # Other FS options options MD_ROOT #MD is a potential root device options CD9660 #ISO 9660 Filesystem options PSEUDOFS#Pseudo-filesystem framework options PROCFS #Process filesystem (requires PSEUDOFS) device io device mem # Commodity buses device isa device pci device agp device acpi device atpic # CAM API (SCSI high-level layer) device scbus device ch device da device sa device cd device ses device pt device targ device targbh device pass options
Re: deadlock in zoneli state on 6.2-PRERELEASE
On Sunday, 26 November 2006 at 2:13:33 +0800, LI Xin wrote: Nikolay Pavlov wrote: On Friday, 24 November 2006 at 11:11:48 +0800, LI Xin wrote: Nikolay Pavlov wrote: On Thursday, 23 November 2006 at 20:24:15 +0800, [EMAIL PROTECTED] wrote: Hi, On Wed, 22 Nov 2006 21:55:49 +0200, Nikolay Pavlov [EMAIL PROTECTED] wrote: Hi. It seems i have a deadlock on 6.2-PRERELEASE. This is squid server in accelerator mode. I can easily trigger it with a high rate of requests. Squid is locked on some zoneli state, i am not sure what it is. Also i can't KILL proccess even with SIGKILL. In addition one of sshd proccess is locked too. Would you please update to the latest RELENG_6 and apply this patch: http://people.freebsd.org/~delphij/misc/patch-zonelimit-workaround to see if things gets improved? Thanks in advance! Cheers, Well. This patch works quite ambiguous for me. Under heavy load this box become unresponseble via network. System is mostly idle. Squid is locked in zoneli. Another panic. Guys do i need some additional debug options or this info is enough. I am asking because this panic is easily reproduceable for me. I think these stuff is enough. By the way, which scheduler do you use? 4BSD [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ACCEL# kgdb kernel.debug /var/crash/vmcore.4 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: lock order reversal: (sleepable after non-sleepable) 1st 0xca21567c so_snd (so_snd) @ /usr/src/sys/netinet/tcp_output.c:253 2nd 0xc070bd84 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 KDB: stack backtrace: kdb_backtrace(,c071ccb0,c071c210,c06e5c4c,c0758f18,...) at kdb_backtrace+0x29 witness_checkorder(c070bd84,9,c06be56c,c02,c070d2c4,0,c06aab25,9f) at witness_checkorder+0x4cd _sx_xlock(c070bd84,c06be56c,c02) at _sx_xlock+0x2c _vm_map_lock_read(c070bd40,c06be56c,c02,184637d,c92796b0,...) at _vm_map_lock_read+0x37 vm_map_lookup(f48a29d0,0,1,f48a29d4,f48a29c4,f48a29c8,f48a29ab,f48a29ac) at vm_map_lookup+0x28 vm_fault(c070bd40,0,1,0,c927aa80,...) at vm_fault+0x65 trap_pfault(f48a2a98,0,c) at trap_pfault+0xee trap(8,c06b0028,f48a0028,1,0,...) at trap+0x325 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc053ea34, esp = 0xf48a2ad8, ebp = 0xf48a2ae4 --- m_copydata(0,,1,d0020d74,c1040468,...) at m_copydata+0x28 tcp_output(d21c5570) at tcp_output+0x9af tcp_input(d0020d00,14,e9,93935ce,0,...) at tcp_input+0x24a2 ip_input(d0020d00) at ip_input+0x561 netisr_processqueue(c075a6d8) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_execute_handlers(c9279648,c92c3400) at ithread_execute_handlers+0xce ithread_loop(c92436a0,f48a2d38,c070db20,0,c06a818a,...) at ithread_loop+0x4e fork_exit(c04f76d4,c92436a0,f48a2d38) at fork_exit+0x61 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xf48a2d6c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc053ea34 stack pointer = 0x28:0xf48a2ad8 frame pointer = 0x28:0xf48a2ae4 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 = 13 (swi1: net) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(100,c927aa80,28,f48a2a98,c,...) at kdb_backtrace+0x29 panic(c069b8a1,c06c5f2c,0,f,c927d69b,...) at panic+0xa8 trap_fatal(f48a2a98,c,c927aa80,c070bd40,0,...) at trap_fatal+0x2a6 trap_pfault(f48a2a98,0,c) at trap_pfault+0x187 trap(8,c06b0028,f48a0028,1,0,...) at trap+0x325 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc053ea34, esp = 0xf48a2ad8, ebp = 0xf48a2ae4 --- m_copydata(0,,1,d0020d74,c1040468,...) at m_copydata+0x28 tcp_output(d21c5570) at tcp_output+0x9af tcp_input(d0020d00,14,e9,93935ce,0,...) at tcp_input+0x24a2 ip_input(d0020d00) at ip_input+0x561 netisr_processqueue(c075a6d8) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_execute_handlers(c9279648,c92c3400) at ithread_execute_handlers+0xce ithread_loop(c92436a0,f48a2d38,c070db20,0,c06a818a,...) at ithread_loop+0x4e
kernel panic(trap 18) on 5.5 and 6.2 with compact flash adapter
Hi, I have problems with both FreeBSD 6.2 and FreeBSD 5.5 when attach CF adapter(IDE) with 1GB flash card(kingston). Card is not recognized on FreeBSD here is part of dmesg. -- from dmesg (freebsd 5.5) -- ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default ad0: FAILURE - SETFEATURES ENABLE RCACHE status=51READY,DSC,ERROR error=4ABORTED ad0: 977MB Hitachi XX.V.3.5.0.0/Rev 0.00 [1987/16/63] at ata0-master PIO4 On the same position - exactly after IPFW output, both kernels GENERIC (6.1) and custom build (6.2 prerelease) went into kernel panic (trap 18) (sorry I can't provide dump output). When I remove CF adapter all works fine. On the same machine I boot Ubuntu and don't have these problems. If someone can help I will try to give more information. -- There are no answers, only cross references. Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.5-RELEASE-p8 #0: Sat Nov 25 19:02:53 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SUNRISE Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3700+ (2210.20-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20f71 Stepping = 1 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe050NX,AMIE,LM,DSP,3DNow! real memory = 536805376 (511 MB) avail memory = 513318912 (489 MB) ACPI APIC Table: Nvidia AWRDACPI ioapic0 Version 1.1 irqs 0-23 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: Nvidia AWRDACPI on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 ACPI link \\_SB_.PCI0.APC3 has invalid initial irq 3, ignoring ACPI link \\_SB_.PCI0.APC2 has invalid initial irq 5, ignoring pci0: ACPI PCI bus on pcib0 pci0: memory at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 pci0: serial bus, SMBus at device 1.1 (no driver attached) ohci0: OHCI (generic) USB controller mem 0xfe02f000-0xfe02 irq 22 at device 2.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered pci0: serial bus, USB at device 2.1 (no driver attached) atapci0: nVidia nForce4 UDMA133 controller port 0xe000-0xe00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 6.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atapci1: GENERIC ATA controller port 0xcc00-0xcc0f,0xb70-0xb73,0x970-0x977,0xbf0-0xbf3,0x9f0-0x9f7 irq 20 at device 7.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 atapci2: GENERIC ATA controller port 0xb800-0xb80f,0xb60-0xb63,0x960-0x967,0xbe0-0xbe3,0x9e0-0x9e7 irq 22 at device 8.0 on pci0 ata4: channel #0 on atapci2 ata5: channel #1 on atapci2 pcib1: ACPI PCI-PCI bridge at device 9.0 on pci0 pci1: ACPI PCI bus on pcib1 ed0: NE2000 PCI Ethernet (ProLAN) port 0xac00-0xac1f irq 17 at device 7.0 on pci1 ed0: Ethernet address: 48:54:e8:2b:97:b9 ed0: if_start running deferred for Giant ed0: type NE2000 (16 bit) pci0: bridge at device 10.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 11.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 12.0 on pci0 pci3: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 13.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 14.0 on pci0 pci5: ACPI PCI bus on pcib5 pci5: display, VGA at device 0.0 (no driver attached) acpi_tz0: Thermal Zone on acpi0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: Standard parallel printer port port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 orm0: ISA Option ROM at iomem 0xd-0xd3fff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic
Re: SunFire X4100 MPT Issues 6.2 RC1
On Nov 23, 2006, at 2:16 PM, Matthew Jacob wrote: [i'm on vacation now] Hmm- I thought I put in code so you should only see one of those. I'll check this out when I get back next week. Thanks for your help. One thing to note is that the firmware and BIOS of the unit was upgraded to try and fix another problem and because of this, the unit will not boot directly from the controller. I don't think this is your problem so if anybody has any thoughts on what path I should take on trying to get this fixed, I would be much appreciated. Here is the output from the console: BTX loader 1.00 BTX version is 1.01 Consoles: internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 612kB/4060704kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Thu Nov 16 01:32:15 UTC 2006) int=000d err=001a efl=00030287 eip=290f eax=140a ebx=0b40 ecx= edx=cf00 esi=0d1c edi=0001 ebp=0206 esp=0200 cs=cf00 ds=9a00 es=9a00fs= gs= ss=9a00 cs:eip=cc 68 32 06 ff 34 e8 db-fc 83 c4 04 89 46 fe 5f 5e c9 c3 55 8b ec 1e 33-c0 8e d8 a0 75 04 3c 00 ss:esp=1c 0d 02 00 00 00 34 02-32 46 1c 0d 00 00 00 14 00 00 00 00 01 00 00 00-1c 0d 02 00 00 00 00 00 BTX halted The unit boots find from the network. I guess I get to see if I can downgrade the firmware but I am not having much luck finding previous images. -- Dave ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SunFire X4100 MPT Issues 6.2 RC1
On Sat, Nov 25, 2006 at 09:49:13PM -0600, Dave wrote: The unit boots find from the network. I guess I get to see if I can downgrade the firmware but I am not having much luck finding previous images. Have you tried talking to Sun about this? The problem really does sound like it's with the BIOS not supporting the ability to boot off of an external controller. This would be something Sun would have to address, would it not? Also, for what it's worth, I have a couple Intel boards which also exhibit the same issue (re: can't boot off of an external controller). The solution I went with was to use the onboard SATA controller instead of my Promise controller. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
