Problem with transfering system to new disk.
Running system FreeBSD 6.2, attaching new disk (WD 750GB SATA RE3) map it thru Sysinstall and rsync old system to it. Now trying to boot from new disk: system boots well to "Choose what to boot" screen (eg 1. normal 2 acpi disable 3. safe 4. single etc), after that system continuously keep printing some strange strings like "csh=4583" can`t really read it cause it`s too fast, system don`t react to C-C C-X or even CTRL ALT DEL. So, the question what is it... and how to fix it. ___ 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: 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: HEADS UP: More CAM fixes.
Hi Scott
Unfortunately, it did not.
On Tuesday 17 February 2009, Scott Long wrote:
> Did the patch help?
>
> Scott
>
>
> Eugene Mitrofanov wrote:
> > 7.1-STABLE FreeBSD 7.1-STABLE #3: Tue Feb 17 14:58:42
> > a...@pci0:3:3:0: class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01
> > hdr=0x00
> > vendor = 'Adaptec (Formerly: Distributed Processing Technology
> > (DPT))'
> > device = 'Raptor SmartRAID Controller'
> > class = mass storage
> > subclass = RAID
> >
> > root:# camcontrol tags da0
> > (pass0:asr0:0:0:0): device openings: 1
> >
> > -
> >
> > 6.2-STABLE FreeBSD 6.2-STABLE #1: Mon Oct 15 16:53:04
> >
> > a...@pci3:3:0: class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01
> > hdr=0x00
> > vendor = 'Adaptec (Formerly: Distributed Processing Technology
> > (DPT))'
> > device = 'Raptor SmartRAID Controller'
> >
> > class = mass storage
> >
> > subclass = RAID
> >
> >
> > root:# camcontrol tags da0
> > (pass0:asr0:0:0:0): device openings: 255
> >
> >
> > On Monday 16 February 2009, Scott Long wrote:
> >> FWI. I need lots of testing on this. Only real SCSI controllers,
> >> please, not RAID controllers (except for MPT-SCSI with integrated
> >> mirroring). So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc,
> >> users, please try this and get back to me. The patch should apply
> >> to FreeBSD 7 as well. FreeBSD 6 is only affected by this problem
> >> when CAM_NEW_TRAN_CODE is enabled.
> >>
> >> Scott
> >>
> >>
> >> Original Message
> >> Subject: svn commit: r188671 - head/sys/cam
> >> Date: Mon, 16 Feb 2009 14:57:15 + (UTC)
> >> From: Scott Long
> >> To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
> >> svn-src-h...@freebsd.org
> >>
> >> Author: scottl
> >> Date: Mon Feb 16 14:57:15 2009
> >> New Revision: 188671
> >> URL: http://svn.freebsd.org/changeset/base/188671
> >>
> >> Log:
> >>Fix parallel SCSI negotiation in the CAM_NEW_TRAN_CODE world order.
> >>Overzealous sanity checks were locking the sync_rate and offset
values
> > to
> >>zero, thanks to a twisty maze of recursive code.
> >>
> >> Modified:
> >>head/sys/cam/cam_xpt.c
> >>
> >> Modified: head/sys/cam/cam_xpt.c
> >>
> >
==
> >> --- head/sys/cam/cam_xpt.c Mon Feb 16 14:38:52 2009(r188670)
> >> +++ head/sys/cam/cam_xpt.c Mon Feb 16 14:57:15 2009(r188671)
> >> @@ -6679,9 +6679,7 @@ xpt_set_transfer_settings(struct ccb_tra
> >>if (((device->flags & CAM_DEV_INQUIRY_DATA_VALID) != 0
> >> && (inq_data->flags & SID_Sync) == 0
> >> && cts->type == CTS_TYPE_CURRENT_SETTINGS)
> >> - || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)
> >> - || (spi->sync_offset == 0)
> >> - || (spi->sync_period == 0)) {
> >> + || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)) {
> >>/* Force async */
> >>spi->sync_period = 0;
> >>spi->sync_offset = 0;
> >> @@ -6729,7 +6727,8 @@ xpt_set_transfer_settings(struct ccb_tra
> >>if (spi->bus_width == 0)
> >>spi->ppr_options = 0;
> >>
> >> - if ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0) {
> >> + if ((spi->valid & CTS_SPI_VALID_DISC)
> >> + && ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0)) {
> >>/*
> >> * Can't tag queue without disconnection.
> >> */
> >> ___
> >> 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"
> >>
> >>
> >
> >
> >
>
>
--
EMIT-RIPN, EVM7-RIPE
___
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"
ZFS Panic
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. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org e**(i*pi)+1=0 ___ 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"
unionfs panic in 7.1
Hi, I've found an reproducable panic in unionfs on 7.1-R. /usr/src/sys/fs/unionfs/union_subr.c is: $FreeBSD: src/sys/fs/unionfs/union_subr.c,v 1.92.2.7.2.2 2008/12/15 03:58:55 daichi Exp $ kgdb output is below. kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 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 "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: stack pointer = 0x10:0xb0e1a8b0 frame pointer = 0x10:0xb0e1a8d0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 72036 (make) panic: from debugger cpuid = 0 Uptime: 49m32s Physical memory: 2034 MB Dumping 441 MB: 426 410 394 378 362 346 330 314 298 282 266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 Reading symbols from /boot/kernel/if_tap.ko...Reading symbols from / boot/kernel/if_tap.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_tap.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from / boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from / boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from / boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/smb.ko...Reading symbols from /boot/ kernel/smb.ko.symbols...done. done. Loaded symbols for /boot/kernel/smb.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from / boot/kernel/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from / boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from / boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/ kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/if_bridge.ko...Reading symbols from / boot/kernel/if_bridge.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_bridge.ko Reading symbols from /boot/kernel/bridgestp.ko...Reading symbols from / boot/kernel/bridgestp.ko.symbols...done. done. Loaded symbols for /boot/kernel/bridgestp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /boot/kernel/radeon.ko...Reading symbols from / boot/kernel/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/ kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from / boot/kernel/unionfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/unionfs.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from / boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x804c70a8 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:418 #2 0x804c750c in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0x801c1707 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:446 #4 0x801c1d6f in db_command (last_cmdp=0x80aa6448, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413 #5 0x801c1f80 in db_command_loop () at /usr/src/sys/ddb/ db_command.c:466 #6 0x801c3b69 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:228 #7 0x804f3955 in kdb_trap (type=12, code=0, tf=0xb0e1a800) at /usr/src/sys/kern/subr_kdb.c:524 #8 0x807a3180 in trap_fatal (frame=0xb0e1a800, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:759 #9 0x807a3554 in trap_pfault (frame=0xb0e1a800, usermode=0) at /
7-stable kernel not compiling: nlm_prot_impl.c "undefined reference to `nfs_*"
With up to date sources buildworld completes, but kernel fails here: linking kernel.debug nlm_advlock.o(.text+0x11a8): In function `nlm_advlock_internal': /data/src/sys/nlm/nlm_advlock.c:225: undefined reference to `nfs_vinvalbuf' nlm_advlock.o(.text+0x1243):/data/src/sys/nlm/nlm_advlock.c:236: undefined reference to `nfs_ticks' nlm_prot_impl.o(.text+0x2af1): In function `nlm_syscall': /data/src/sys/nlm/nlm_prot_impl.c:1543: undefined reference to `nfs_advlock_p' nlm_prot_impl.o(.text+0x2af7):/data/src/sys/nlm/nlm_prot_impl.c:1544: undefined reference to `nfs_advlock_p' nlm_prot_impl.o(.text+0x2b01):/data/src/sys/nlm/nlm_prot_impl.c:1545: undefined reference to `nfs_reclaim_p' nlm_prot_impl.o(.text+0x2b07):/data/src/sys/nlm/nlm_prot_impl.c:1546: undefined reference to `nfs_reclaim_p' nlm_prot_impl.o(.text+0x2b1f):/data/src/sys/nlm/nlm_prot_impl.c:1551: undefined reference to `nfs_advlock_p' nlm_prot_impl.o(.text+0x2b25):/data/src/sys/nlm/nlm_prot_impl.c:1552: undefined reference to `nfs_reclaim_p' *** Error code 1 Stop in /usr/local/obj/data/src/sys/HOME. *** Error code 1 -- This .signature sanitized for your protection ___ 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: Big problems with 7.1 locking up :-(
At 05:38 PM 1/29/2009, Robert Watson wrote: On Fri, 9 Jan 2009, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. So the last two days I have been round upgrading all our servers, knowing that I had run the system stably on identical hardware for some time. For those following this other than Pete, who I've been in private correspondence with: it seems that he is running into two different deadlocks in the routing code. One of them (at least) is triggered by a lock order problem relating to the processing of ICMP redirects -- uncommon in most configurations, but quite a few on his network, which triggers quickly under load. Kip Macy has corrected at least one (both?) problems in head, and plans to MFC the fixes in the near future. We'll follow up further once the fixes are merged, and if any further problems transpire. Hi Robert, Do you have any other details about these issues ? Were the fixes ever MFC'd ---Mike ___ 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: HEADS UP: Major CAM performance regression
This is also the case with 7.0-RELEASE on areca. We have a machine here which literally grinds to a half every time we run our rrd updates, so may be a good test case here if we can fix that ;-) Regards Steve - Original Message - From: "Mike Tancsa" To: "Scott Long" ; "FreeBSD Current" ; "FreeBSD Stable" Sent: Tuesday, February 17, 2009 11:06 PM Subject: Re: HEADS UP: Major CAM performance regression At 05:55 AM 2/13/2009, Scott Long wrote: If, instead, it reports a value of '1', you are likely affected. Note that it may be normal for USB memory devices to report a low number. Also, many legacy SCSI disks, and devices that are not disks, may also be expected to report a low number. Hi Scott, I tested with the patch on my areca controller, and it still reports 1 post patch. (On RELENG_6, it shows 255 with the same controller) ---Mike ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: FreeBSD 7.1 crashing on shutdown, halt etc.
I've got a similar problem here with source code csuped today. kgdb output: Unread portion of the kernel message buffer: <118>Feb 17 20:59:17 frameshift syslogd: exiting on signal 15 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...1 1 0 0 0 done All buffers synced. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor write, page not present instruction pointer = 0x20:0xc54cd387 stack pointer = 0x28:0xe9b73a60 frame pointer = 0x28:0xe9b73a7c 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 = 1238 (halt) trap number = 12 panic: page fault cpuid = 0 Uptime: 40s Physical memory: 1387 MB Dumping 92 MB: 77 61 45 29 13 Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/modules/bcmwl5_sys.ko...done. Loaded symbols for /boot/modules/bcmwl5_sys.ko Reading symbols from /boot/kernel/ndis.ko...Reading symbols from /boot/kernel/ndis.ko.symbols...done. done. Loaded symbols for /boot/kernel/ndis.ko Reading symbols from /boot/kernel/if_ndis.ko...Reading symbols from /boot/kernel/if_ndis.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_ndis.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/modules/sdmmc.ko...done. Loaded symbols for /boot/modules/sdmmc.ko Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtraceall.ko Reading symbols from /boot/kernel/cyclic.ko...Reading symbols from /boot/kernel/cyclic.ko.symbols...done. done. Loaded symbols for /boot/kernel/cyclic.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from /boot/kernel/dtrace.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtrace.ko Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtmalloc.ko Reading symbols from /boot/kernel/fbt.ko...Reading symbols from /boot/kernel/fbt.ko.symbols...done. done. Loaded symbols for /boot/kernel/fbt.ko Reading symbols from /boot/kernel/sdt.ko...Reading symbols from /boot/kernel/sdt.ko.symbols...done. done. Loaded symbols for /boot/kernel/sdt.ko Reading symbols from /boot/kernel/systrace.ko...Reading symbols from /boot/kernel/systrace.ko.symbols...done. done. Loaded symbols for /boot/kernel/systrace.ko Reading symbols from /boot/kernel/profile.ko...Reading symbols from /boot/kernel/profile.ko.symbols...done. done. Loaded symbols for /boot/kernel/profile.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:196 #1 0xc079de57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc079e129 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0ac070c in trap_fatal (frame=0xe9b73a20, eva=12) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0ac0990 in trap_pfault (frame=0xe9b73a20, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0ac13dc in trap (frame=0xe9b73a20) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0aa70db in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc54cd387 in gfs_dir_create () from /boot/kernel/zfs.ko Previous frame inner to this frame (corrupt stack?) -- Cezary Morga "The Bible
Re: HEADS UP: Major CAM performance regression
At 05:55 AM 2/13/2009, Scott Long wrote: If, instead, it reports a value of '1', you are likely affected. Note that it may be normal for USB memory devices to report a low number. Also, many legacy SCSI disks, and devices that are not disks, may also be expected to report a low number. Hi Scott, I tested with the patch on my areca controller, and it still reports 1 post patch. (On RELENG_6, it shows 255 with the same controller) ---Mike ___ 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: Error compiling FreeBSD-Stable with MFC'ed iconv locking
On Saturday 14 February 2009 8:04:45 am Jens Rehsack wrote: > Hi John, > > after I updated my system (-STABLE) I received following compilation error > while building the kernel (having ICONV built in): > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona > -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 > --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror > /usr/src/sys/libkern/iconv.c > /usr/src/sys/libkern/iconv.c: In function 'iconv_mod_unload': > /usr/src/sys/libkern/iconv.c:92: error: 'curthread' undeclared (first use in > this function) > /usr/src/sys/libkern/iconv.c:92: error: (Each undeclared identifier is > reported only once > /usr/src/sys/libkern/iconv.c:92: error: for each function it appears in.) > /usr/src/sys/libkern/iconv.c: In function 'iconv_sysctl_add': > /usr/src/sys/libkern/iconv.c:401: error: 'curthread' undeclared (first use > in this function) > /usr/src/sys/libkern/iconv.c: In function 'iconv_converter_handler': > /usr/src/sys/libkern/iconv.c:452: error: 'curthread' undeclared (first use > in this function) > > I applied following patch - and it works: > --- sys/sys/sx.h.orig 2009-02-14 12:56:11.0 + > +++ sys/sys/sx.h 2009-02-14 12:57:33.0 + > @@ -35,6 +35,7 @@ > #include > #include > #include > +#include > > #ifdef _KERNEL > #include > > Google didn't find anything so I thought I mail this quickly. The most recent commit to to include in the _KERNEL section should fix this. -- John Baldwin ___ 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: HEADS UP: Major CAM performance regression
At 02:57 AM 2/17/2009, Luigi Rizzo wrote: On Sat, Feb 14, 2009 at 07:33:25AM -0700, Scott Long wrote: ... > >I'll try your suggestion if you have one. > > I don't have a magic universal testing suite in my back pocket, sorry. > You need to look at your expected workload and develop tests to simulate > it. When I do testing during driver development, I try a lot of > different parallel, sequential, large i/o, and small i/o combinations. i just committed a port sysutils/fio that perhaps can help testing IO performance with various patterns. Hi, Do you have any suggestions as to what tests to run with fio ? Am I right in assuming that the Areca is hit by this bug ? 0[releng7]# camcontrol tags da0 (pass0:arcmsr0:0:0:0): device openings: 1 0[releng7]# ---Mike ___ 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: Booting 7.1-STABLE on supermicro 5015-MF (PDSMI+)
Krassimir Slavchev wrote, on 2/17/2009 8:48 AM: > It boots 7.1-RELEASE from the CDROM just fine but when boots from an IDE > disk it crashes right after loading the kernel: > > http://mnemonic.bulinfo.net/~krassi/crash/supermicro_crash.jpg > > Booting from the USB produces exactly the same crash. I know that the > BIOS of this board is buggy although it is latest. > I am curious why it boots from the CDROM but cannot boots from the IDE > disk. I just disconnect the CDROM and connect the IDE disk. The same IDE > disk boots fine on other hardware. I have tried with 7.1-PRERELEASE > which is 2-3 months older than 7.1-RELEASE and it crashes in same way. I see from the phot that you're running a custom kernel. What's different between that kernel and GENERIC? Data point: I'm running 7.1-RELEASE, installed from CD, on a PDSMI+ board, but I am booting from SATA. This may help to rule out possible non-IDE issues. I'm tracking with freebsd-update(8), but there have been no kernel updates yet. It's a fresh install with no kernel or sysctl tuning, and hasn't taken any load yet. $ uptime 10:02AM up 10 days, 18:50, 1 user, load averages: 0.00, 0.00, 0.00 $ uname -a FreeBSD dragonfly.acsalaska.net 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 $ cat /var/run/dmesg.boot Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2394.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x2010 AMD Features2=0x1 Cores per package: 2 real memory = 3756916736 (3582 MB) avail memory = 3672895488 (3502 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.0 on pci0 pci9: on pcib2 pcib3: at device 0.0 on pci9 pci10: on pcib3 pcib4: irq 17 at device 28.4 on pci0 pci13: on pcib4 em0: port 0x4000-0x401f mem 0xe020-0xe021 irq 16 at device 0.0 on pci13 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:8d:30:74 pcib5: irq 16 at device 28.5 on pci0 pci14: on pcib5 em1: port 0x5000-0x501f mem 0xe030-0xe031 irq 17 at device 0.0 on pci14 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:30:48:8d:30:75 uhci0: port 0x3000-0x301f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3020-0x303f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xe000-0xe3ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib6: at device 30.0 on pci0 pci15: on pcib6 vgapci0: port 0x6000-0x60ff mem 0xe800-0xefff,0xe040-0xe040 irq 16 at device 0.0 on pci15 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xe400-0xe7ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 sio0: <16550A-compatible COM por
Re: HEADS UP: More CAM fixes.
Bruce Evans wrote: On Tue, 17 Feb 2009, Gary Jennejohn wrote: I tested this with an Adaptec 29160. I saw no real improvement in performance, but also no regressions. I suspect that the old disk I had attached just didn't have enough performance reserves to show an improvement. My test scenario was buildworld. Since /usr/src and /usr/obj were both on the one disk it got a pretty good workout. low AMD64 X2 (2.5 GHz) with 4GB of RAM. Buildworld hardly uses the disk at all. It reads and writes a few hundred MB. Ideally the i/o should go at disk speeds of 50-200MB/S and thus take between 20 and 5 seconds. In practice, it will take a few more seconds. physically but perhaps even less virtually due to parallelism. Bruce Yes, on modern machines, buildworld is bound almost completely by disk latency, and not at all by disk or controller bandwidth. Scott ___ 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: HEADS UP: More CAM fixes.
On Tue, 17 Feb 2009, Gary Jennejohn wrote: I tested this with an Adaptec 29160. I saw no real improvement in performance, but also no regressions. I suspect that the old disk I had attached just didn't have enough performance reserves to show an improvement. My test scenario was buildworld. Since /usr/src and /usr/obj were both on the one disk it got a pretty good workout. low AMD64 X2 (2.5 GHz) with 4GB of RAM. Buildworld hardly uses the disk at all. It reads and writes a few hundred MB. Ideally the i/o should go at disk speeds of 50-200MB/S and thus take between 20 and 5 seconds. In practice, it will take a few more seconds. physically but perhaps even less virtually due to parallelism. Bruce ___ 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"
Booting 7.1-STABLE on supermicro 5015-MF (PDSMI+)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello All, It boots 7.1-RELEASE from the CDROM just fine but when boots from an IDE disk it crashes right after loading the kernel: http://mnemonic.bulinfo.net/~krassi/crash/supermicro_crash.jpg Booting from the USB produces exactly the same crash. I know that the BIOS of this board is buggy although it is latest. I am curious why it boots from the CDROM but cannot boots from the IDE disk. I just disconnect the CDROM and connect the IDE disk. The same IDE disk boots fine on other hardware. I have tried with 7.1-PRERELEASE which is 2-3 months older than 7.1-RELEASE and it crashes in same way. Any ideas what may be wrong? Best regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJmvhkxJBWvpalMpkRAmsAAJ4wh51lvt+nxllhCt69szOusEspuwCfU7ew TemmPRvVnGp68byH0I4d9lI= =Md6S -END PGP SIGNATURE- ___ 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"
FreeBSD 7.1 crashing on shutdown, halt etc.
Hi. My system is crashing when I log out (using gdm). I had posted to gnome but was just advised to post to x11, posted to x11 and was told this is a kernel bug. Many thanks for any all of your assistance. Backtrace is provided below. Some system info: FreeBSD pc-racine1.mcmaster.ca 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Mon Feb 16 12:06:34 EST 2009 root at pc-racine1.mcmaster.ca:/usr/ obj/usr/src/sys/OPTIPLEX i386 Backtrace follows: 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: <118>. <118>Shutting down local daemons: <118>. <118>Writing entropy file: <118>. <118>. <118>Feb 16 12:54:07 pc-racine1 syslogd: exiting on signal 15 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07b0564 stack pointer = 0x28:0xe7b89af8 frame pointer = 0x28:0xe7b89b10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 3 current process = 967 (Xorg) trap number = 12 panic: page fault cpuid = 0 Uptime: 45s Physical memory: 2025 MB Dumping 105 MB: 90 74 58 42 26 10 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/ kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from / boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from / boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/i915.ko...Reading symbols from /boot/ kernel/i915.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/ kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:196 #1 0xc07be607 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:418 #2 0xc07be8d9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0ad0aec in trap_fatal (frame=0xe7b89ab8, eva=392) at /usr/src/ sys/i386/i386/trap.c:939 #4 0xc0ad0d70 in trap_pfault (frame=0xe7b89ab8, usermode=0, eva=392) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0ad172c in trap (frame=0xe7b89ab8) at /usr/src/sys/i386/i386/ trap.c:530 #6 0xc0ab759b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc07b0564 in _mtx_lock_sleep (m=0xc52b5cc0, tid=3314965792, opts=0, file=0xc5a60953 "/usr/src/sys/modules/drm/i915/../../../dev/ drm/i915_irq.c", line=118) at /usr/src/sys/kern/kern_mutex.c:339 #8 0xc07b0a02 in _mtx_lock_flags (m=0xc52b5cc0, opts=0, file=0xc5a60953 "/usr/src/sys/modules/drm/i915/../../../dev/drm/ i915_irq.c", line=118) at /usr/src/sys/kern/kern_mutex.c:186 #9 0xc5a5f403 in i915_irq_wait (kdev=0xc562a700, cmd=Variable "cmd" is not available. ) at /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_irq.c:117 #10 0xc5a6aa4a in drm_ioctl (kdev=0xc562a700, cmd=2147771461, data=0xc52bfc60 "\025\006", flags=67, p=0xc5965d20) at /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:911 #11 0xc07832a7 in giant_ioctl (dev=0xc562a700, cmd=2147771461, data=0xc52bfc60 "\025\006", fflag=67, td=0xc5965d20) at /usr/src/sys/ kern/kern_conf.c:408 #12 0xc074d4b7 in devfs_ioctl_f (fp=0xc5a2f474, com=2147771461, data=0xc52bfc60, cred=0xc5508e00, td=0xc5965d20) at /usr/src/sys/fs/ devfs/devfs_vnops.c:595 #13 0xc07f5565 in kern_ioctl (td=0xc5965d20, fd=9, com=2147771461, data=0xc52bfc60 "\025\006") at file.h:268 #14 0xc07f56c4 in ioctl (td=0xc5965d20, uap=0xe7b89cfc) at /usr/src/ sys/kern/sys_generic.c:570 #15 0xc0ad10c5 in syscall (frame=0xe7b89d38) at /usr/src/sys/i386/i386/ trap.c:1090 #16 0xc0ab7600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/ exception.s:255 #17 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit Professor J. S. Racine Phone: (905) 525 9140 x 23825 Department of EconomicsFAX:(905) 521-8232 McMaster Universitye-mail: racinej at mcmaster.ca 1280 Main St. W.,Hamilton, URL: http://www.economics.mcmaster.ca/racine/ Ontario, Canada. L8S 4M4 ___ freebsd-stable
Re: HEADS UP: More CAM fixes.
Did the patch help?
Scott
Eugene Mitrofanov wrote:
7.1-STABLE FreeBSD 7.1-STABLE #3: Tue Feb 17 14:58:42
a...@pci0:3:3:0: class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01
hdr=0x00
vendor = 'Adaptec (Formerly: Distributed Processing Technology
(DPT))'
device = 'Raptor SmartRAID Controller'
class = mass storage
subclass = RAID
root:# camcontrol tags da0
(pass0:asr0:0:0:0): device openings: 1
-
6.2-STABLE FreeBSD 6.2-STABLE #1: Mon Oct 15 16:53:04
a...@pci3:3:0: class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01
hdr=0x00
vendor = 'Adaptec (Formerly: Distributed Processing Technology
(DPT))'
device = 'Raptor SmartRAID Controller'
class = mass storage
subclass = RAID
root:# camcontrol tags da0
(pass0:asr0:0:0:0): device openings: 255
On Monday 16 February 2009, Scott Long wrote:
FWI. I need lots of testing on this. Only real SCSI controllers,
please, not RAID controllers (except for MPT-SCSI with integrated
mirroring). So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc,
users, please try this and get back to me. The patch should apply
to FreeBSD 7 as well. FreeBSD 6 is only affected by this problem
when CAM_NEW_TRAN_CODE is enabled.
Scott
Original Message
Subject: svn commit: r188671 - head/sys/cam
Date: Mon, 16 Feb 2009 14:57:15 + (UTC)
From: Scott Long
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org
Author: scottl
Date: Mon Feb 16 14:57:15 2009
New Revision: 188671
URL: http://svn.freebsd.org/changeset/base/188671
Log:
Fix parallel SCSI negotiation in the CAM_NEW_TRAN_CODE world order.
Overzealous sanity checks were locking the sync_rate and offset values
to
zero, thanks to a twisty maze of recursive code.
Modified:
head/sys/cam/cam_xpt.c
Modified: head/sys/cam/cam_xpt.c
==
--- head/sys/cam/cam_xpt.c Mon Feb 16 14:38:52 2009(r188670)
+++ head/sys/cam/cam_xpt.c Mon Feb 16 14:57:15 2009(r188671)
@@ -6679,9 +6679,7 @@ xpt_set_transfer_settings(struct ccb_tra
if (((device->flags & CAM_DEV_INQUIRY_DATA_VALID) != 0
&& (inq_data->flags & SID_Sync) == 0
&& cts->type == CTS_TYPE_CURRENT_SETTINGS)
-|| ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)
-|| (spi->sync_offset == 0)
-|| (spi->sync_period == 0)) {
+|| ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)) {
/* Force async */
spi->sync_period = 0;
spi->sync_offset = 0;
@@ -6729,7 +6727,8 @@ xpt_set_transfer_settings(struct ccb_tra
if (spi->bus_width == 0)
spi->ppr_options = 0;
- if ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0) {
+ if ((spi->valid & CTS_SPI_VALID_DISC)
+&& ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0)) {
/*
* Can't tag queue without disconnection.
*/
___
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"
___
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: HEADS UP: More CAM fixes.
On Mon, 16 Feb 2009 08:09:35 -0700 Scott Long wrote: > FWI. I need lots of testing on this. Only real SCSI controllers, > please, not RAID controllers (except for MPT-SCSI with integrated > mirroring). So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc, > users, please try this and get back to me. The patch should apply > to FreeBSD 7 as well. FreeBSD 6 is only affected by this problem > when CAM_NEW_TRAN_CODE is enabled. > I tested this with an Adaptec 29160. I saw no real improvement in performance, but also no regressions. I suspect that the old disk I had attached just didn't have enough performance reserves to show an improvement. My test scenario was buildworld. Since /usr/src and /usr/obj were both on the one disk it got a pretty good workout. AMD64 X2 (2.5 GHz) with 4GB of RAM. BTW under a very fresh 8.0-current. --- Gary Jennejohn ___ 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: HEADS UP: More CAM fixes.
7.1-STABLE FreeBSD 7.1-STABLE #3: Tue Feb 17 14:58:42
a...@pci0:3:3:0: class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01
hdr=0x00
vendor = 'Adaptec (Formerly: Distributed Processing Technology
(DPT))'
device = 'Raptor SmartRAID Controller'
class = mass storage
subclass = RAID
root:# camcontrol tags da0
(pass0:asr0:0:0:0): device openings: 1
-
6.2-STABLE FreeBSD 6.2-STABLE #1: Mon Oct 15 16:53:04
a...@pci3:3:0: class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01
hdr=0x00
vendor = 'Adaptec (Formerly: Distributed Processing Technology
(DPT))'
device = 'Raptor SmartRAID Controller'
class = mass storage
subclass = RAID
root:# camcontrol tags da0
(pass0:asr0:0:0:0): device openings: 255
On Monday 16 February 2009, Scott Long wrote:
> FWI. I need lots of testing on this. Only real SCSI controllers,
> please, not RAID controllers (except for MPT-SCSI with integrated
> mirroring). So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc,
> users, please try this and get back to me. The patch should apply
> to FreeBSD 7 as well. FreeBSD 6 is only affected by this problem
> when CAM_NEW_TRAN_CODE is enabled.
>
> Scott
>
>
> Original Message
> Subject: svn commit: r188671 - head/sys/cam
> Date: Mon, 16 Feb 2009 14:57:15 + (UTC)
> From: Scott Long
> To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
> svn-src-h...@freebsd.org
>
> Author: scottl
> Date: Mon Feb 16 14:57:15 2009
> New Revision: 188671
> URL: http://svn.freebsd.org/changeset/base/188671
>
> Log:
>Fix parallel SCSI negotiation in the CAM_NEW_TRAN_CODE world order.
>Overzealous sanity checks were locking the sync_rate and offset values
to
>zero, thanks to a twisty maze of recursive code.
>
> Modified:
>head/sys/cam/cam_xpt.c
>
> Modified: head/sys/cam/cam_xpt.c
>
==
> --- head/sys/cam/cam_xpt.cMon Feb 16 14:38:52 2009(r188670)
> +++ head/sys/cam/cam_xpt.cMon Feb 16 14:57:15 2009(r188671)
> @@ -6679,9 +6679,7 @@ xpt_set_transfer_settings(struct ccb_tra
> if (((device->flags & CAM_DEV_INQUIRY_DATA_VALID) != 0
> && (inq_data->flags & SID_Sync) == 0
> && cts->type == CTS_TYPE_CURRENT_SETTINGS)
> - || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)
> - || (spi->sync_offset == 0)
> - || (spi->sync_period == 0)) {
> + || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)) {
> /* Force async */
> spi->sync_period = 0;
> spi->sync_offset = 0;
> @@ -6729,7 +6727,8 @@ xpt_set_transfer_settings(struct ccb_tra
> if (spi->bus_width == 0)
> spi->ppr_options = 0;
>
> - if ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0) {
> + if ((spi->valid & CTS_SPI_VALID_DISC)
> + && ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0)) {
> /*
>* Can't tag queue without disconnection.
>*/
> ___
> 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"
>
>
--
EMIT-RIPN, EVM7-RIPE
___
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: zfs crashes with nfs and snapshots
On Mon, 16 Feb 2009 19:43:00 +0200 Jaakko Heinonen wrote about Re: zfs crashes with nfs and snapshots: JH> > Ok, I will upgrade to 7.1-stable asap. The client was Linux 2.6.25, JH> > I cannot say if it uses readdirplus and if I could disable that (the JH> > manpage says nothing about it at all, but I will look into that JH> > further). JH> -o nordirplus mount option should disable it on Linux. Thanks. I missed that when first looking into the manpage (probably because it's written in UPPERCASE :-). cu Gerrit ___ 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"
