Re: FreeBSD-Update + Sendmail
On Wed, Aug 07, 2013 at 04:02:14PM +0100, Matthew Seaman wrote: > On 07/08/2013 15:19, Panagiotis Christias wrote: > > On Tue, Aug 06, 2013 at 10:43:49PM +0100, Matthew Seaman wrote: > >> On 06/08/2013 22:28, Thomas Laus wrote: > >>> I like the 'sendmail from ports' suggestion a little better. Going this > >>> route, I only need to make configuration changes to /etc/mail/mailer.conf > >>> once. All subsequent freebsd-update operations won't require rebuilding > >>> sendmail and it's tools. Any updates to the port version are covered by > >>> the > >>> normal port update system. Future updates to the port version only > >>> require a > >>> 'make restart' in the /etc/mail directory after reviewing my .mc file for > >>> any > >>> affected changes. > >> > >> If you're using the ports version of sendmail, a handy tip is to add > >> this to /etc/make.conf: > >> > >> SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf > >> MAKEMAP=/usr/local/sbin/makemap > >> > >> so you use a version of the sendmail M4 config bits that matches the > >> sendmail binary you're running, and you can use /etc/mail/Makefile to > >> generate and install the configs exactly as if you were using the base > >> system sendmail. > > > > > > Indeed, plus: > > > > SENDMAIL=/usr/local/sbin/sendmail > > > > And in /etc/rc.conf: > > > > sendmail_program="/usr/local/sbin/sendmail" > > /etc/mail/mailer.conf does that bit for you. Hm, you are right. -- Panagiotis J. ChristiasNetwork Management Center p.christ...@noc.ntua.grNational Technical Univ. of Athens, GREECE ___ 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-Update + Sendmail
On Tue, Aug 06, 2013 at 10:43:49PM +0100, Matthew Seaman wrote: > On 06/08/2013 22:28, Thomas Laus wrote: > > I like the 'sendmail from ports' suggestion a little better. Going this > > route, I only need to make configuration changes to /etc/mail/mailer.conf > > once. All subsequent freebsd-update operations won't require rebuilding > > sendmail and it's tools. Any updates to the port version are covered by > > the > > normal port update system. Future updates to the port version only require > > a > > 'make restart' in the /etc/mail directory after reviewing my .mc file for > > any > > affected changes. > > If you're using the ports version of sendmail, a handy tip is to add > this to /etc/make.conf: > > SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf > MAKEMAP=/usr/local/sbin/makemap > > so you use a version of the sendmail M4 config bits that matches the > sendmail binary you're running, and you can use /etc/mail/Makefile to > generate and install the configs exactly as if you were using the base > system sendmail. Indeed, plus: SENDMAIL=/usr/local/sbin/sendmail And in /etc/rc.conf: sendmail_program="/usr/local/sbin/sendmail" Regards, Panagiotis -- Panagiotis J. ChristiasNetwork Management Center p.christ...@noc.ntua.grNational Technical Univ. of Athens, GREECE ___ 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: Installing FreeBSD 9.1 amd64 on IBM x3550 M3
On Tue, Feb 12, 2013 at 09:54:25AM +0200, John Alex. wrote: > > On 02/12/2013 02:59 AM, kpn...@pobox.com wrote: > > On Mon, Feb 11, 2013 at 11:43:55AM -0800, Kevin Oberman wrote: > >> On Mon, Feb 11, 2013 at 9:58 AM, Panagiotis Christias > >> wrote: > >>> > >>> I suppose trying an 8.3 installation would be the easiest way to use MBR > >>> instead of GPT, right; > >> > >> That would do it, but 9.1 is perfectly happy doing MBR. It's just not > >> the default. > >> > >> Seems like many BIOSes assume that GPT=uEFI. Clearly this is silly, but... > >> > >> I know Lenovo laptops have this problem and it is VERY annoying. I run > >> FreeBSD on a GPT disk on my ThinkPad, but I have booteasy installed on > >> an MBR disk (which contains W7) and my BIOS is set to boot from that > >> disk.BootEasy then will boot up the GPT disk with FreeBSD. > > > > Doesn't GPT start with an MBR covering the entire disk? How feasible would > > it be to tweak that MBR so that a boot partition was listed in it? Say, a > > partition holding the root filesystem could be listed in both the GPT and > > MBR style. Then a disk could be booted with MBR or GPT at the whim of the > > firmware. > > > > I agree that this BIOS=MBR/UEFI=GPT assumption is pure rubbish. I've got > > machines with this documented restriction and I'd love a way around it. > > > > It is feasible, it's known as a hybrid MBR. On Linux I've accomplished > this using the gdisk utility, I don't know how it can be done on FreeBSD > though. I had to use this ugly solution in order to install windows 8 on > a GPT disk on a pc without UEFI support. Just for the record, I managed to install successfully 8.3 with the default options and 9.1 by selecting MBR instead of GPT during the initial disk patitioning. In both cases the system's UEFI/BIOS options were left untouched. Thanks for the help, Panagiotis -- Panagiotis J. ChristiasNetwork Management Center p.christ...@noc.ntua.grNational Technical Univ. of Athens, GREECE ___ 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: Installing FreeBSD 9.1 amd64 on IBM x3550 M3
On 11/2/2013 14:11, Erich Dollansky wrote: Hi, On Mon, 11 Feb 2013 13:23:53 +0200 Panagiotis Christias wrote: Hello, I'm trying to install FreeBSD 9.1 amd64 on an IBM x3550 M3 server. Installation went smoothly, RAID controller and network cards were successfully recognised. But, after the installation, the server fails to boot from disk. There were some posts, about two years ago, in this list implying that the problem lies in UEFI but I couldn't find any clear solution. I do not know if this is the same problem I face on my notebook but it currently does not boot when I use GPT. Can you give a MBR partitioned disk a try? My notebook was earlier booting from a GPT disk. I cannot remember why I used MBR for the new disk. Hello, I suppose trying an 8.3 installation would be the easiest way to use MBR instead of GPT, right; Thanks, Panagiotis -- Panagiotis J. ChristiasNetwork Management Center p.christ...@noc.ntua.grNational Technical Univ. of Athens, GREECE ___ 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"
Installing FreeBSD 9.1 amd64 on IBM x3550 M3
Hello, I'm trying to install FreeBSD 9.1 amd64 on an IBM x3550 M3 server. Installation went smoothly, RAID controller and network cards were successfully recognised. But, after the installation, the server fails to boot from disk. There were some posts, about two years ago, in this list implying that the problem lies in UEFI but I couldn't find any clear solution. Any suggestions would be greatly appreciated. Thanks, Panagiotis -- Panagiotis J. ChristiasNetwork Management Center p.christ...@noc.ntua.grNational Technical Univ. of Athens, GREECE ___ 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: Reducing the need to compile a custom kernel
On 10/2/2012 15:56, Alexander Leidinger wrote: Hi, during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options which are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? Hello, we are currently using on every server (in order to maintain a single custom kernel) the following options: IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT IPFIREWALL_FORWARD ROUTETABLES=n Soon, we will also add: IPSEC IPSEC_FILTERTUNNEL IPSEC_NAT_T crypto enc Finally, once we upgrade our jail setup VIMAGE will be also a must. Regards, Panagiotis -- Panagiotis J. ChristiasNetwork Management Center p.christ...@noc.ntua.grNational Technical Univ. of Athens, GREECE ___ 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"
USB kernel panic on 7.3-RELEASE amd64 during Dell PowerEdge 2950 DRAC reset
Hello, today we decided to add a new SSL certificate in the DRAC subsystem of one of our Dell PowerEdge 2950 III servers. During the final step of that procedure DRAC resets itself in order to load the new certificate. The result of DRAC's reset was a kernel panic of the 7.3-RELEASE amd64 that runs on that system. The panic messages seem to be USB related and are available at: http://noc.ntua.gr/~christia/2010-06-16_163545.png The memory dump completed successfully(?) but the subsequent kgdb backtrace failed with the following output: # kgdb /boot/kernel/kernel /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"... Cannot access memory at address 0x0 (kgdb) bt #0 0x in ?? () Cannot access memory at address 0x0 uname output: FreeBSD XX 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Fri Apr 9 22:50:50 EEST 2010 r...@xx:/usr/obj/usr/src/sys/CUSTOM amd64 /usr/src/sys/amd64/conf/CUSTOM contains just: include GENERIC ident CUSTOM options ROUTETABLES=4 options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD Latest /var/run/dmesg.boot is available at: http://noc.ntua.gr/~christia/dmesg.boot.2010-06-16_163545 I have not yet tried to reproduce the panic. Any advice to collect more useful debug info is welcome. Regards, Panagiotis ___ 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: 7.1/6.4 Release Status...
On Fri, Nov 28, 2008 at 02:52:30PM -0500, Ken Smith wrote: > > Sorry, as usual I've not been very good about status updates... > > As far as the 7.1-REL process goes two issues that got classified as > show-stoppers got worked out right around the time work on a security > advisory came along. Progress on both releases got unblocked at the > same time so some work has been done with 7.1 (some folks have already > noticed the branch was done) but we focused a bit more on finishing 6.4. > We expect to get the 7.1-RC1 builds started Sunday. If testing doesn't > turn up any more show-stoppers 7.1-RC2 will be done about 1.5 weeks > after RC1, and 7.1-REL will be done about 1.5 weeks after RC2. > > 6.4-RELEASE is done. Details here: > > http://www.freebsd.org/releases/6.4R/announce.html > > Thanks... Hello, previous releases used to have progress report pages in the FreeBSD main site that were really useful and informative, e.g.: http://www.freebsd.org/releases/7.0R/todo.html Are there any such pages for 7.1 and 6.4? Thank you for your efforts, Panagiotis -- Panagiotis J. ChristiasNetwork Management Center [EMAIL PROTECTED]National Technical Univ. of Athens, GREECE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7-STABLE, isp(4), QLE2462: panic & deadlocks
On Wed, Oct 15, 2008 at 08:54:53PM +0300, Panagiotis Christias wrote: > On Wed, Oct 15, 2008 at 09:44:15AM +0400, Oleg Sharoiko wrote: > > Hi! > > > > On Wed, 2008-10-15 at 01:23 +0300, Panagiotis Christias wrote: > > > > > However, when we connect them to the CX3-40, create and mount a new > > > partition and then do something as simple as "tar -C /san -xf ports.tgz" > > > the system panics and deadlocks. We have tried several FreeBSD versions > > > (6.3 i386/adm64, 7.0 i386/adm64, 7.1 i386/adm64 and lastly 7-STABLE i386 > > > - we also tried the latest 8-CURRENT snapshot but it panicked too soon). > > > The result is always the same; panic and deadlock. > > > > Try reducing the number of "tagged openings" with 'camcontrol tags' down > > to 46. If it doesn't work try reducing it further to 2. Also be advised > > that I've seen panics with geom_multipath in FreeBSD-7, unfortunately I > > had no time to test it in -current. > > > Hm.. that would probably explain the fact that I was unable to panic the > system when I had set the hint.isp.0.debug="0x1F" in /boot/device.hints. > > Currently I am stress testing the server with the tagged openings set to > 44 (first value tested). Until now there is no panic or deadlock. I am > trying concurrent tar extractions and rsync copies. The filesystem looks > ok till now according to fsck. I will let it write/copy/delete overnight > and tomorrow I will try different tagged opening values. > > Thank you for the hint! I am wondering what is the performance penalty > with decreased tagged openings. Also, is there anything else I could try > in order to get more useful debug output? I have at least three servers > that I could use for any kind of tests and I am willing to spend as much > time I can get to help solving the problem. > > Finally, the only output in the logs is: > > Expensive timeout(9) function: 0xc06f4210(0xc67e1200) 0.059422635 s > Expensive timeout(9) function: 0xc08d4fd0(0) 0.060676147 s > > I suppose that is related to the CAMDEBUG kernel config options. For the record, I have done many tests using several stressing tools in parallel, different FreeBSD versions (up to 7.1beta2), various filesystem configurations (plain ufs2 with softupdates, ufs2 and gjournal, zfs) and various tag openings values (down to 2). Regardless of the configuration, the system deadlocks, panics or the filesystem gets awfully corrupted within seconds, minutes or a few hours. The only configuration that seems to work without problems(?) but with a unacceptable *severe* performance penalty is when tag openings are set to minimum value of 2 (that is more or less same as disabling tagged command queueing at all). All tests ran using a 500 GB RAID5 LUN on an EMC Clariion CX340: da0 at isp0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-4 device da0: Serial Number CK200083100148 da0: 400.000MB/s transfers da0: Command Queueing Enabled da0: 512000MB (1048576000 512 byte sectors: 255H 63S/T 65270C) Previously, a Sun StorEdge T3 was tested which worked flawlessly but it had a 1 Gbps fibre channel interface, instead of a 4 Gbps that Clariion has, was recognized as a SCSI-3 device and had 2 tags openings (no surprise) by default: da1 at isp1 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 100.000MB/s transfers da1: 241724MB (495050752 512 byte sectors: 255H 63S/T 30815C) As I mentioned before, I am willing to spend time or/and provide access to the system for testing and debugging. Regards, Panagiotis -- Panagiotis J. ChristiasNetwork Management Center [EMAIL PROTECTED]National Technical Univ. of Athens, GREECE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qlogic qle2462 hba and freebsd stable on a dl360 g5
On Thu, Nov 13, 2008 at 12:22:11PM +0100, Claus Guttesen wrote: > Hi. > > I'm looking at a qlogic qle2462 hba for my dl360 g5. The thread > http://www.mail-archive.com/freebsd-stable@freebsd.org/msg99497.html > mentions a deadlock when system is loaded. Has this issue been > resolved? Are there other PCI Express hba's which are known to work > with freebsd stable and dl360 g5? Hello, no, the issue has not been resolved. The system still deadlocks regardless the value of tag openings (even when set to the minimum value of 2) and the filesystem gets corrupted or totally destroyed. I am still looking for a solution and willing to do any tests. Regards, Panagiotis -- Panagiotis J. ChristiasNetwork Management Center [EMAIL PROTECTED]National Technical Univ. of Athens, GREECE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7-STABLE, isp(4), QLE2462: panic & deadlocks
On Wed, Oct 15, 2008 at 09:44:15AM +0400, Oleg Sharoiko wrote: > Hi! > > On Wed, 2008-10-15 at 01:23 +0300, Panagiotis Christias wrote: > > > However, when we connect them to the CX3-40, create and mount a new > > partition and then do something as simple as "tar -C /san -xf ports.tgz" > > the system panics and deadlocks. We have tried several FreeBSD versions > > (6.3 i386/adm64, 7.0 i386/adm64, 7.1 i386/adm64 and lastly 7-STABLE i386 > > - we also tried the latest 8-CURRENT snapshot but it panicked too soon). > > The result is always the same; panic and deadlock. > > Try reducing the number of "tagged openings" with 'camcontrol tags' down > to 46. If it doesn't work try reducing it further to 2. Also be advised > that I've seen panics with geom_multipath in FreeBSD-7, unfortunately I > had no time to test it in -current. Hm.. that would probably explain the fact that I was unable to panic the system when I had set the hint.isp.0.debug="0x1F" in /boot/device.hints. Currently I am stress testing the server with the tagged openings set to 44 (first value tested). Until now there is no panic or deadlock. I am trying concurrent tar extractions and rsync copies. The filesystem looks ok till now according to fsck. I will let it write/copy/delete overnight and tomorrow I will try different tagged opening values. Thank you for the hint! I am wondering what is the performance penalty with decreased tagged openings. Also, is there anything else I could try in order to get more useful debug output? I have at least three servers that I could use for any kind of tests and I am willing to spend as much time I can get to help solving the problem. Finally, the only output in the logs is: Expensive timeout(9) function: 0xc06f4210(0xc67e1200) 0.059422635 s Expensive timeout(9) function: 0xc08d4fd0(0) 0.060676147 s I suppose that is related to the CAMDEBUG kernel config options. Regards, Panagiotis -- Panagiotis J. ChristiasNetwork Management Center [EMAIL PROTECTED]National Technical Univ. of Athens, GREECE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: amrd disk performance drop after running under high load
On Nov 11, 2007 7:26 PM, Alexey Popov <[EMAIL PROTECTED]> wrote: > Hi. > > Kris Kennaway wrote: > >>> In the "good" case you are getting a much higher interrupt rate but > >>> with the data you provided I can't tell where from. You need to run > >>> vmstat -i at regular intervals (e.g. every 10 seconds for a minute) > >>> during the "good" and "bad" times, since it only provides counters > >>> and an average rate over the uptime of the system. > >> > >> Now I'm running 10-process lighttpd and the problem became no so big. > >> > >> I collected interrupt stats and it shows no relation beetween > >> ionterrupts and slowdowns. Here is it: > >> http://83.167.98.162/gprof/intr-graph/ > >> > >> Also I have similiar statistics on mutex profiling and it shows > >> there's no problem in mutexes. > >> http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ > >> > >> I have no idea what else to check. > > > I don't know what this graph is showing me :) When precisely is the > > system behaving poorly? > Take a look at "Disk Load %" picture at > http://83.167.98.162/gprof/intr-graph/ > > At ~ 17:00, 03:00-04:00, 13:00-14:00, 00:30-01:30, 11:00-13:00 it shows > peaks of disk activity which really never happen. As I said in the > beginning of the thread in this "peak" moments disk becomes slow and > vmstat shows 100% disk load while performing < 10 tps. Other grafs at > this page shows that there's no relation to interrupts rate of amr or em > device. You advised me to check it. > > When I was using single-process lighttpd the problem was much harder as > you can see at http://83.167.98.162/gprof/graph/ . At first picture on > this page you can see disk load peaks at 18:00 and 15:00 which leaded to > decreasing network output because disk was too slow. > > Back in this thread we suspected UMA mutexes. In order to check it I > collected mutex profiling stats and draw graphs over time and they also > didn't show anything interesting. All mutex graphs were smooth while > disk load peaks. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ > > With best regards, > Alexey Popov Hello, what is your RAID controller configuration (read ahead/cache/write policy)? I have seen weird/bogus numbers (~100% busy) reported by systat -v when read ahead was enabled on LSI/amr controllers. Regards, Panagiotis Christias ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic on FreeBSD 6.0BETA1
On 8/9/05, Kris Kennaway <[EMAIL PROTECTED]> wrote: > On Wed, Aug 03, 2005 at 08:47:43AM -0400, Derrick Edwards wrote: > > ???Hi all, > > I decided to try and help with testing 6-BETA1, after updating sources and > > recompiling i get the following during boot up. I am tried booting without > > hyperthreading enabled in the bios and I still get the same panic. > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id =00 > > fault virtual address = 0x480008 > > fault code = supervisor read, page not present > > instruction pointer = 0x20:0xc06923cc > > stack pointer = 0x28:0xc10208ec > > > > Code segment = base 0x0, limit 0xf, type 0x1b > > ? ? ? ? ? ? ?= DPL 0, pres 1, def32 1, gran 1 > > > > processor eflags = interrupt enabled, resyne, IOPL = 0 > > current process = 0 (swapper) > > [thread pid 0tid0] > > Stopped at strlen+0x8: cmpb $0,0(%edx) > > > > I left all the debugging features in the current however, I am not sure > > exactly how to trace this problem. If someone could point me to any doc that > > would allow to provide more information that would ?be great. I updated my > > pen 400MHZ using the same procedures and all went well. Please help > > See the chapter on kernel debugging in the developers handbook. > > Kris > > P.S. I need to make a macro to type the answer to this FAQ. IMHO I think that the average FreeBSD user/fan could use some help when he/she deals with kernel panics/crashes/dumps/kgdb/kernel.debug etc. First step, the debug kernel and modules could be included in the base system. What is it, 50 to 60MB disk space? That should be no(?) problem. Being there and correctly built by "The Source" would be the first step for the average user (not the "I wrote the kernel" developer) to use them and provide correct, complete and thus useful feedback. The one that you developers ask for. Second step, the procedure of extracting the useful data from the crash dumps using the "wat doez diz program do?" kgdb program is not efficient to be left in hands of the average user. He/she is probably a great guy, afterall he/she is using FreeBSD and certainly willing to contribute but dealing with kgdb is too much to ask for. Except if he/she has the guidance of kernel developer through this mailing list or others. It is not an efficient way to investigate and report serious problems. I am wondering if possible to write some kgdb-wrapper scripts which would do the dirty job of analyzing the crash dump using kgdb and the proper command (backtrace, list xx, print yy, up nn, down mm, voodoo etc.). This procedure can be as detailed as needed or wanted. The results could be sent automatically (send-pr) to the FreeBSD Team. That way, every user would be able to easily send proper reports without mistakes or missing data and benefit the FreeBSD Project. Any thoughts? Panagiotis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Strange SCSI behavior after upgrading from 5.2.1 to 5.4 (and a panic)
Hello, on Thurday we upgraded one of our last 5.2.1 servers to 5.4. Tonight the server panicked, crashed and I had to power it off and on. Here are the logs before the panic: Jun 26 03:45:50 patroklos kernel: (da0:ahc0:0:0:0): lost device Jun 26 03:45:50 patroklos kernel: (da0:ahc0:0:0:0): Invalidating pack Jun 26 03:46:00 patroklos last message repeated 2 times Jun 26 03:46:06 patroklos kernel: initiate_write_filepage: already started Jun 26 03:46:07 patroklos last message repeated 9 times Jun 26 03:46:07 patroklos kernel: (da0:ahc0:0:0:0): READ(10). CDB: 28 0 72 f 16 0 0 0 80 0 Jun 26 03:46:07 patroklos kernel: (da0:ahc0:0:0:0): CAM Status: SCSI Status Error Jun 26 03:46:07 patroklos kernel: (da0:ahc0:0:0:0): SCSI Status: Check Condition Jun 26 03:46:07 patroklos kernel: (da0:ahc0:0:0:0): UNIT ATTENTION asc:29,0 Jun 26 03:46:07 patroklos kernel: (da0:ahc0:0:0:0): Power on, reset, or bus device reset occurred Jun 26 03:46:07 patroklos kernel: (da0:ahc0:0:0:0): Retries Exhausted Jun 26 03:46:07 patroklos kernel: (da0:ahc0:0:0:0): Invalidating pack Jun 26 03:46:31 patroklos kernel: initiate_write_filepage: already started Jun 26 03:46:43 patroklos kernel: panic: initiate_write_inodeblock_ufs2: already started As I said the machine could not recover from the panic so there ais no crashdump. The 5.4 version of the dmesg output is available at: http://noc.ntua.gr/~christia/tmp/dmesg-5.4.txt The 5.2.1 version of the dmesg output is available at: http://noc.ntua.gr/~christia/tmp/dmesg-5.2.1.txt da0 is an 1302GB external IDE to SCSI RAID (8x200GB IDE drives in RAID5 configuration and a SCSI U160 interface). FreeBSD 5.4 connects to da0 at 80MB/s (40.000MHz, offset 31, 16bit, Tagged Queueing Enabled), while FreeBSD 2.5.1 (and FreeBSD 5.3 - just tried to boot with the 5.3-RELEASE-i386-miniinst.iso) connects happily at 160MB/s (80.000MHz, offset 62, 16bit, Tagged Queueing Enabled) which is the transfer rate supported by the RAID device and the SCSI card (Adaptec 3960D Ultra160 SCSI adapter/aic7899). Any ideas what could be or where could be the problem? What has changed in 5.4? We had preserved the 5.2.1 system disks and after the crash we moved back to 5.2.1 until further notice. Now I'm thinking of trying 5.3 which seems to have the same behavior as 5.2.1 and will be still supported for a year or so. Thanks, Panagiotis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
