Re: fxp performance with POLLING
Pete French wrote: 1 megabit = 106 = 1,000,000 bits which is equal to 125,000 bytes. you are assuming eight bits per byte - but this is a serial line so you should use ten bits per byte instead. -pete. That was a rule of thumb in the heyday of async serial lines, which used a start and stop bit per byte. However, ethernet at 100Mbit is 4B5B coded at a 125mhz rate. So the raw synchronous data rate really is 12.5Mbytes/s. Minus the sync preamble of 8 bytes per packet and the mandatory inter-frame-gap of 12 bytes that's a physical layer rate of (12.5M * (1500/(1500+20))) or 12.34Mbyte/s. Even in the later days of modems this rule applied less and less, because the modulation schemes became synchronous. Joe Koberg joe_at_osoft_dot_us ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp performance with POLLING
Pete French wrote: However, ethernet at 100Mbit is 4B5B coded at a 125mhz rate. So the raw Errr, 4B5B *is* 10 bits per byte surely? ... Gig ether is mainly 8B10, as is Firewire, SATA, FibreChannel and a Mind you, it assumes that you know the real bit rate, which in the case of 100baseT is, as you say, actualy 125mbits/sec. You are right. It definitely is 10 bits per byte clocked at a higher rate. I guess the "100mbit/s" rate is so strongly associated with the technology that I glossed right over that. Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.4 RC1 locks up solid on first reboot
Jeremy Chadwick wrote: On Thu, Oct 23, 2008 at 06:27:45AM +0200, Milan Obuch wrote: I did not investigate on this issue too much, but there is an workaround - copy older /boot/loader over newer one. In my case, I am rebuilding whole I have experienced loader troubles in the past when using customized compiler options in /etc/make.conf . Rebuilding without compiler options fixed the issue. Joe Koberg joe at osoft dot us ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-STABLE amd64 kernel trap during boot-time device probe
Jeff Blank wrote: Hello, I posted this around 3 months ago and never received a response. the problem still occurs with 7.0-STABLE (csup on 20080301). I possibly incorrectly referred to it as a panic last time, when the problem was really a trap. I also receive "Fatal trap 12: page fault while in kernel mode" while trying to boot a HP Proliant DL580G3 from the 7.0-RELEASE amd64 disc1 CD. I can successfully boot with the verbose boot option from the boot CD, and I installed the system and got it all setup for ZFS root. At long as I booted verbose it worked. But now I have recompiled the kernel to include SCHED_ULE and a few options and I cannot avoid the "Fatal trap 12" It is annoying to troubleshoot on this machine because the BIOS takes 5 minutes finally get around to booting the OS after a reboot. But it has an iLO management controller that I might be able to arrange access to for anyone who has the skill to find/fix the issue. Joe Koberg joe at osoft dot us Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x258 fault code = supervisor read data, page not present instruction pointer = 0x8:0x8047aa7e stack pointer = 0x10:0xa0677b40 frame pointer = 0x10:0xa0677b60 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 = 23 (irq21: ohci0+) [thread pid 23 tid 100029 ] Stopped at 0x8047aa7e = _mtx_lock_sleep+0x4e: movl 0x258(%rcx),%esi db> === end panic === === no panic === [...] ums0: on uhub0 ums0: 5 buttons and Z dir. ukbd0: on uhub0 kbd2 at ukbd0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DMA limited to UDMA33, device found non-ATA66 cable acd0: DVDR at ata0-master UDMA33 ad4: 238475MB at ata2-master SATA300 ad8: 157066MB at ata4-master SATA300 ad10: 157066MB at ata5-master SATA300 ar0: 314133MB status: READY ar0: disk0 READY using ad8 at ata4-master ar0: disk1 READY using ad10 at ata5-master SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a [continue successful boot] === end no panic === - End forwarded message - ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HP ProLiant DL360 G5 success stories?
The iLO is a completely separate management processor with its own network port. It runs its own OS and has its own IP address. It runs an SSL webserver for access. The iLO is accessible over the network any time the machine is plugged into power. I am not sure about IPMI access to it. The "normal" iLO option will give you exact textual console screen output and keyboard control from the moment of power-on. It will also let you toggle power and hit the reset button. I believe it uses a java applet in the browser. The "advanced" iLO option, which is license-key-unlocked, also provides graphical remote console, and virtual media. You can upload a CD or floppy image and then boot the server from it. I suspect the compatibility issue appears here - the virtual media probably emulates USB mass storage, and the OS must be able to boot from it. It has full reporting of hardware state and management log details, and the "home page" is a big summary with any faults outlined in red. In this data center we probably have 1500 HP machines with iLO. I find it an effective and reliable remote access method. We definitely prefer it using it to our Avocent IP KVMs. Joe Koberg joe at osoft dot us Johan Ström wrote: First of all, nice with all these positive answers! Thank you all (without responding to each and every post:))! On Mar 12, 2008, at 12:35 PM, Pete French wrote: What I'm looking at is a DL360 G5, probably with one E5335 (quad 2.0) and 4G of RAM and 4x 146Gb SAS disks on the Smart Array P400i card. ... So.. Does anyone have any experience with this combo (DL360 G5 / P400i)? We have around 20 machines like that and they work beautifully. We run 7.0/amd64 on the machines now, but we have run 6.2/i386 in the past and that work fine - though you will only be able to use the first 3.5 gig of RAM. I don't have any plans on running i368, running amd64 on the supermicro box now without any problems (that I can relate to that at least). How long have you run 7.0 (before release)? From all the other responses it seems lots of ppl use 7.0 on these without any problems at all. Furthermore, anyone run 7.0 on this? Or should I still stick with We run 7.0 on these machines and it works fine - I always prefer 7.0 to 6.3 on SMP machines as it performs better. Also 7.0 works well with the iLO on these machines - I seem to recall when I installed 6.X that it didn't work too well and I had to use boot floppy images. I'd say go for 7.0 and amd64 if you can. This is where I'm a bit curious. What OS interaction does iLO do? That needs to be "compatible" i mean. On my current box I got a IPMI card that gives me (when its working..) SOL capabilities.. To what degree can I remote control with iLO? If I've understood correct, I get the exact console as on screen with kb access, over web/ssh/telnet. Is this working good? This is one of my important points for changing since its so crappy on my current box, and when the box is a couple of miles away its quite nice to have it working flawlessly.. iLO over internet? Possible, impossible? Encryption? (yes i know, not exactly freebsd related questions but.. ) Another thing, how is it with physical monitoring? Temperatures/fanspeeds/voltage? Thank you (all)! :) -- Johan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HP ProLiant DL360 G5 success stories?
Johan Ström wrote: But.. http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf seems to tell me that in basic mode I can only access BIOS (pre-OS) using the Remote Console feature, and that after POST I have to have the advanced licensed option? I don't do the purchasing and we get all Advanced iLO, so I will take your word for it. The older generations supported text console (i have a 360G2 that does so). We use the HP Management agents under Windows for all SNMP reporting so I can't comment on the reporting method under other OS's. Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS performance on 7.2-release/amd64 low compared to UFS2 + SoftUpdates
The difference in layout can easily explain a 2x difference in sequential transfer performance. I seriously doubt your disk is really getting 23K seeks/s done in the UFS case - 100/s sounds much more reasonable for real hardware. Perhaps the results of caching? Joe Koberg Dan Naumov wrote: I am wondering if the numbers I am seeing is something expected or is something broken somewhere. Output of bonnie -s 1024: on UFS2 + SoftUpdates: ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 1024 56431 94.5 88407 38.9 77357 53.3 64042 98.6 644511 98.6 23603.8 243.3 on ZFS: ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 1024 22591 53.7 45602 35.1 14770 13.2 45007 83.8 94595 28.0 102.2 1.2 atom# cat /boot/loader.conf vm.kmem_size="1024M" vm.kmem_size_max="1024M" vfs.zfs.arc_max="96M" The test isn't completely fair in that the test on UFS2 is done on a partition that resides on the first 16gb of a 2tb disk while the zfs test is done on the enormous 1,9tb zfs pool that comes after that partition (same disk). Can this difference in layout make up for the huge difference in performance or is there something else in play? The system is an Intel Atom 330 dualcore, 2gb ram, Western Digital Green 2tb disk. Also what would be another good way to get good numbers for comparing the performance of UFS2 vs ZFS on the same system. Sincerely, - Dan Naumov ___ 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: The need for initialising disks before use?
Antony Mawer wrote: Is it recommended/required to do something like: dd if=/dev/zero of=/dev/ad0 bs=1m before use to ensure the drive's sector remappings are all in place, before then doing a newfs? It seems logical to read the whole device first with "conv=noerror" to be sure the drive has encountered and noted any correctable or uncorrectable errors present. Only then write the entire drive, allowing it to remap any noted bad sectors. i.e.: # dd if=/dev/ad0 of=/dev/null bs=64k conv=noerror # dd if=/dev/zero of=/dev/ad0 bs=64k The problem is that when dd hits the first bad sector, the whole 64k block containing the sector will be skipped. There could be more bad sectors there... or none... If you hit errors I would re-read the affected area with "bs=512" to get down to sector granularity. I seem to recall a utility posted to a freebsd mailing list some time ago that worked like dd(1), but would "divide and conquer" a block that returned with a read error. Intent being to get the job done fast with large blocks but still copy every sector possible off a failing drive by reducing to sector-sized blocks if necessary Unfortunately I can't find it now. Joe Koberg joe at osoft dot us ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
secmgr wrote: No, I mean self corrupting raid5 sets during initialization. Discussed about 2-3 weeks ago. In the following message you seemed to claim that adding 64 sectors of slack to the beginning of the vinum partition fixed this problem, as I suggested. Did that fix it or not? The reason is empirically derived. When I created a 7 disk raid 5 set using "len 0" or all the space available, the raid set would be corrupt after initializing. Every time. When I reserved back that extra space, no corruption. (freebsd 4.10-p3) There was a thread on this a few days ago. jim Joe Koberg joe at osoft dot us ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PC card problems on 5.3-R: "CIS is too long -- truncating""pccard0:Orinoco Gold, SMC 2532W-B
I am using a Toshiba Tecra 730XCDT, a 150MHz Pentium laptop. It has a ToPIC 95B Cardbus controller. The BIOS can place the controller into "PCIC-compatible" or "Cardbus/16-bit" modes. In Cardbus mode, my 3com 3c3FE575CT 100mbit card works fine. However my two wireless cards, an Orinoco Gold and an SMC 2532W-B, give the following message upon insertion: CIS is too long -- truncating pccard0: card has no functions cbb0: PC Card card activation failed "pccardc dumpcis" says "0 slots found" In PCIC-compatible mode, FreeBSD does not recognize the card controller. The wi cards work OK under PCIC mode in NetBSD 1.6.2. The 3com card does not. NetBSD does not seem to work with them in cardbus mode. Thanks in advance for any help Joe Koberg joe at osoft dot us ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TIMEOUT - WRITE_DMA - A possible FIX! turn off ACPI
Zsolt Kúti wrote: My system produces these messages that I already know well from this list (as well ;): ad4: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=213249674 Like many people I was confronted with "TIMEOUT - READ_DMA" and "TIMEOUT - WRITE_DMA" errors on my drives. I was frustrated. But I found a workaround: Turning off ACPI. I just received a Highpoint RocketRaid 1640 controller, 2 Maxtor 300GB drives, and a Supermicro 5-drive SATA cage. I am testing this configuration for a storage server. I am using an old motherboard, DTK brand, Slot 1. 300A Celeron. Under a fresh install of 5.3-RELEASE I am unable to read or write both drives heavily at the same time. One drive alone seems to work OK. When I run dd blasting both drives with seqential IO, I get TIMEOUT - WRITE(READ)_DMA. Repeatably, within 15 seconds. However I got a good test before I installed 5.3-R, the box was running with 5.3-BETA. Only difference was I booted without ACPI. So I rebooted the freshly installed 5.3-R without ACPI, and It works! I can read at 50MB/s per drive concurrently (hitting PCI bus speed limit?), and write at 30MB/s per drive concurrently. No errors so far, and its been dd'ing for a half hour. I hope this report helps someone! Joe Koberg joe at osoft dot us dmesg: FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (307.84-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x660 Stepping = 0 Features=0x183f9ff real memory = 402587648 (383 MB) avail memory = 384270336 (366 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xb000-0xb01f irq 10 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM), rev 1.10/3.00, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. pci0: at device 7.3 (no driver attached) atapci1: port 0xc400-0xc4ff,0xc000-0xc003,0xbc00-0xbc07,0xb800-0xb803,0xb400-0xb407 irq 11 at device 17.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 atapci2: port 0xd800-0xd8ff,0xd400-0xd403,0xd000-0xd007,0xcc00-0xcc03,0xc800-0xc807 irq 11 at device 17.1 on pci0 ata4: channel #0 on atapci2 ata5: channel #1 on atapci2 dc0: port 0xdc00-0xdcff mem 0xec00-0xec0003ff irq 12 at device 18.0 on pci0 miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:04:5a:56:80:76 dc0: if_start running deferred for Giant dc0: [GIANT-LOCKED] pci0: at device 19.0 (no driver attached) cpu0 on motherboard orm0: at iomem 0xcc000-0xcdfff,0xc-0xc8fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 307842170 Hz quality 800 Timecounters tick every 10.000 msec ad0: 43979MB [89355/16/63] at ata0-master UDMA33 ad4: 286188MB [581463/16/63] at ata2-master UDMA133 ad6: 286188MB [581463/16/63] at ata3-master UDMA133 Mounting root from ufs:/dev/ad0s1a After these messages the two former cases result in FAILURE and finally in panic. Even background fsck cannot run without another panic, only single user mode can help. All these prevent using them on my HW. However B7, although displays the messages as well, works seemingly fine. For the time being this version is sufficent, but I'd like to know - if po
Re: gvinum or vinum in 5.3-STABLE
Aristedes Maniatis wrote: Sorry to butt in on your thread, but it seems relevant. I am having problems with gvinum under 5-STABLE and a RAID 0 array of two disks. The array works perfectly until reboot. Then, when the machine comes back up the plexes are marked as stale. Issuing these commands fixes the problem until the next reboot: Once the plexes are UP, issue a 'gvinum saveconfig'. Then try rebooting and see what happens. This has worked for me before with 5.3-R, and today with a recent 5.3-STABLE. Joe Koberg [EMAIL PROTECTED] gvinum setstate up storage.p0.s0 gvinum setstate up storage.p0.s1 Things I've tried: * Googling for answers * commenting out the fstab entry at boot and then manually mounting the partition after boot * inserting gvinum in /boot/loader.conf * copying the vinum script in /etc/rc.d/vinum and making a gvinum equivalent * trying to shutdown gvinum at shutdown time (but "gvinum stop" doesn't work) * fsck * rebuilding gvinum array Is there some shutdown procedure that should gracefully shutdown the RAID? There is a process which opens files on the RAID and runs continuously until shutdown. Could it be holding the RAID open too long and could this staleness? From what I can tell the staleness doesn't affect any data - everything is OK once brought up. Cheers Ari Maniatis On 14/02/2005, at 11:38 AM, Tristan wrote: Is gvinum ready for production use in a RAID5 config ? --> ish group pty ltd http://www.ish.com.au 7 Darghan St Glebe 2037 Australia phone +61 2 9660 1400 fax +61 2 9660 7400 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell hardware raid 0 (sas5ir) or gmirror?
Josef Karthauser wrote: On Mon, Jan 15, 2007 at 11:21:06AM +, Josef Karthauser wrote: I'm purchasing a new server, and was wondering what anyone thought about whether to pay extra for the SAS5IR card so I can RAID0 the two drives, or whether to just rely on gmirror. My worry about the former is that I can't seem to find management tools for controlling the hardware controller. What if one of the drives fails? How would I know? Of course I mean RAID1! J. I just bought two Dell PE-1950's to use as routers. They have LSI Logic PERC/5i's attached to 80GB SATA drives. I am pretty sure this is the same card used for SAS. One thing is for sure, the mfi(4) card and driver aren't shy! See below for examples of the kernel messages I get regularly. I am sure drive failure would be well noted. As to rebuilding on-line, I suspect a drive (hot-)swap will initiate the rebuild. There is a CLI tool (megarc) in ports/sysutils/megarc but I haven't tried to use it yet. All in all I would recommend the PERC/5i. Joe Koberg joe at osoft dot us Jan 7 06:41:41 fw2 kernel: mfi0: 316 (4278190093s/0x0008/0) - Battery Present Jan 7 06:41:41 fw2 kernel: mfi0: 317 (4278190110s/0x0004/0) - PD 08(e1/s255) event: Enclosure (SES) discovered on PD 08(e1/s255) Jan 7 06:41:41 fw2 kernel: mfi0: 318 (4278190110s/0x0002/0) - PD 08(e1/s255) event: Inserted: PD 08(e1/s255) Jan 7 06:41:41 fw2 kernel: mfi0: 319 (4278190110s/0x0002/0) - Type 29: Inserted: PD 08(e1/s255) Info: enclPd=08, scsiType=d, portMap=00, sasAddr=500180b04375a600, Jan 7 06:41:41 fw2 kernel: mfi0: 320 (4278190110s/0x0002/0) - PD 00(e1/s0) event: Inserted: PD 00(e1/s0) Jan 7 06:41:41 fw2 kernel: mfi0: 321 (4278190110s/0x0002/0) - Type 29: Inserted: PD 00(e1/s0) Info: enclPd=08, scsiType=0, portMap=01, sasAddr=1221, Jan 7 06:41:41 fw2 kernel: mfi0: 322 (4278190110s/0x0002/0) - PD 01(e1/s1) event: Inserted: PD 01(e1/s1) Jan 7 06:41:41 fw2 kernel: mfi0: 323 (4278190110s/0x0002/0) - Type 29: Inserted: PD 01(e1/s1) Info: enclPd=08, scsiType=0, portMap=02, sasAddr=12210100, Jan 7 06:41:41 fw2 kernel: mfi0: 325 (4278190110s/0x0001/0) - VD 00/0 event: Background Initialization started on VD 00/0 Jan 7 06:41:41 fw2 kernel: mfi0: 326 (221488579s/0x0020/0) - Adapter ticks 221488579 elapsed 30s: Time established as 01/07/07 12:36:19; (30 seconds since power on) Jan 7 06:41:41 fw2 kernel: mfi0: 330 (4278190080s/0x0020/0) - PCI 0x041028 0x0415 0x041028 0x041f03: Firmware initialization started (PCI ID 0015/1028/1f03/1028) Jan 7 06:41:41 fw2 kernel: mfi0: 331 (4278190080s/0x0020/0) - Type 18: Firmware version 1.00.02-0157 Jan 7 06:41:41 fw2 kernel: mfi0: 332 (4278190096s/0x0008/0) - Battery Present Jan 7 06:41:41 fw2 kernel: mfi0: 333 (4278190113s/0x0004/0) - PD 08(e1/s255) event: Enclosure (SES) discovered on PD 08(e1/s255) Jan 7 06:41:41 fw2 kernel: mfi0: 334 (4278190113s/0x0002/0) - PD 08(e1/s255) event: Inserted: PD 08(e1/s255) Jan 7 06:41:41 fw2 kernel: mfi0: 335 (4278190113s/0x0002/0) - Type 29: Inserted: PD 08(e1/s255) Info: enclPd=08, scsiType=d, portMap=00, sasAddr=500180b04375a600, Jan 7 06:41:41 fw2 kernel: mfi0: 336 (4278190113s/0x0002/0) - PD 00(e1/s0) event: Inserted: PD 00(e1/s0) Jan 7 06:41:41 fw2 kernel: mfi0: 337 (4278190113s/0x0002/0) - Type 29: Inserted: PD 00(e1/s0) Info: enclPd=08, scsiType=0, portMap=01, sasAddr=1221, Jan 7 06:41:41 fw2 kernel: mfi0: 338 (4278190113s/0x0002/0) - PD 01(e1/s1) event: Inserted: PD 01(e1/s1) Jan 7 06:41:41 fw2 kernel: mfi0: 339 (4278190113s/0x0002/0) - Type 29: Inserted: PD 01(e1/s1) Info: enclPd=08, scsiType=0, portMap=02, sasAddr=12210100, Jan 7 06:41:41 fw2 kernel: mfi0: 341 (4278190113s/0x0001/0) - VD 00/0 event: Background Initialization started on VD 00/0 Jan 7 06:41:41 fw2 kernel: mfi0: 342 (221488658s/0x0020/0) - Adapter ticks 221488658 elapsed 33s: Time established as 01/07/07 12:37:38; (33 seconds since power on) Jan 7 06:41:41 fw2 kernel: mfi0: 347 (221488716s/0x0008/0) - Battery temperature is normal Jan 7 06:41:41 fw2 kernel: mfi0: 348 (221488716s/0x0008/0) - Battery started charging Jan 7 06:41:41 fw2 kernel: mfi0: 349 (221488716s/0x0008/0) - Current capacity of the battery is above threshold Jan 7 06:41:41 fw2 kernel: mfi0: 350 (4278190080s/0x0020/0) - PCI 0x041028 0x0415 0x041028 0x041f03: Firmware initialization started (PCI ID 0015/1028/1f03/1028) Jan 7 06:41:41 fw2 kernel: mfi0: 351 (4278190080s/0x0020/0) - Type 18: Firmware version 1.00.02-0157 Jan 7 06:41:41 fw2 kernel: mfi0: 352 (4278190096s/0x0008/0) - Battery Present Jan 7 06:41:41 fw2 kernel: mfi0: 353 (4278190113s/0x0004/0) - PD 08(e1/s255) event: Enclosure (SES) discovered on PD 08(e1/s255) Jan 7 06:41:41 fw2 kernel: mfi0: 354 (4278190113s/0x0002/0) - PD 08(e1/s255) event: Inserted: PD 08(e1/s2
Re: ATA Woes.
Jon Simola wrote: On 7/19/05, Tony Byrne <[EMAIL PROTECTED]> wrote: I'm totally confused. I don't know enough about SMART to know whether I'm looking at real failing drives or some bug exposed by the interaction between drive firmware, hd controller and FreeBSD. What I've recently learned the hard way is that desktop drives have no place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives (which claim to be low-end server). I have to agree with this opinion, I recently had a WD1600JD SATA fail within a couple months of installation, and the warranty replacement failed within a week. First drive failed autodetection and made servo ticking noises. Second drive had many bad sectors. Add this to the pile of dead 3yr-old 40GB WD drives from all the workstations around here. I install SATA drives in duplicate and triplicate for this reason. Preferably in removable bays with a fan. I assume they're bad out of the box... I write them full of zeros with DD, then read it all back, then do it again. If I don't get read errors then I install them. Joe Koberg joe at osoft dot us ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
loader(8) crashing in 5.4, 5.3 loader works Dell Poweredge SC1425 nocona
I have a Dell Poweredge SC1425 server. I am running FreeBSD AMD64. I have been running 5.3-R on this machine since Feburary. I decided to go ahead and upgrade to 5.4. installkernel - OK reboot - OK mergemaster -p OK installworld - OK mergemaster - OK... reboot again CRASH... loader crashes with BTX Halted and instant reboot. Cannot read register dump because it disappears too fast. If I intercept boot with the spacebar right after hitting F1, and type in /boot/loader.old to get the 5.3 loader it works. I have since cvsupped to 5.4-p6 and rebuilt, with the same results - loader crashes. The system is working with the 5.3 loader copied over to /boot/loader. I would like to not have to worry about this the next time I upgrade. Ideas appreciated. Joe Koberg Open Software Services, LLC joe at osoft dot us dmesg: Copyright (c) 1992-2005 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.4-RELEASE-p6 #0: Fri Aug 5 02:35:53 CDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AFBSMP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2800.12-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x641d,MON,DS_CPL,CNTX-ID,CX16,> AMD Features=0x20100800 real memory = 5100273664 (4864 MB) avail memory = 4122259456 (3931 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 7 ioapic1: Changing APIC ID to 8 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 9 ioapic2: WARNING: intbase 64 != expected base 56 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 em0: port 0xecc0-0xecff mem 0xdfde-0xdfdf irq 32 at device 4.0 on pci2 em0: Ethernet address: 00:11:43:fd:4d:2b em0: Speed:N/A Duplex:N/A pci1: at device 0.1 (no driver attached) pcib3: at device 0.2 on pci1 pci3: on pcib3 pci1: at device 0.3 (no driver attached) uhci0: port 0xcce0-0xccff irq 16 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xccc0-0xccdf irq 19 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib4: at device 30.0 on pci0 pci4: on pcib4 em1: port 0xdcc0-0xdcff mem 0xdf9e-0xdf9f irq 20 at device 3.0 on pci4 em1: Ethernet address: 00:11:43:fd:4d:2c em1: Speed:N/A Duplex:N/A pci4: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atapci1: port 0xcc80-0xcc8f,0xcc98-0xcc9b,0xcca0-0xcca7,0xccb0-0xccb3,0xccb8-0xccbf irq 18 at device 31.2 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: at iomem 0xec000-0xe,0xc-0xcafff on isa0 atkbdc0: at port 0x64,0x60 on isa0 ppc0: cannot reserve I/O port range sc0: 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: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to accept, logging unlimited ad4: 76293MB [155009/16/63] at ata2-master SATA150 ad6: 76293MB [155009/16/63] at ata3-master SATA150 SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/gvinum/m_root WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted WARNING: /www was not properly dismounted WARNING: /svn was not properly dismounted em0: Link is up 100 Mbps Full Duplex make.conf: CFLAGS=-O -pipe MAKE_IDEA=YES NOPROFILE=true # added by use.perl 2005-02-11 14:33:12 PERL_VER=5.8.6 PERL_VERSION=5.8.6 CPUTYPE=nocona -r-xr-xr-x 1 root wheel 245760 Aug 5 02:39 loader -r-xr-xr-x 1 root wheel 241664 Aug 5 02:43 loader.new.notworking2 MD5 (loader) = c6089e00e
Re: newfs -v on vinum raid5 panics system (4.10-p3 RELEASE)
secmgr wrote: partition the same size as the slice (c=h), and then let the subdisks use the entire partition (len 0), the raid set is corrupted every time after initializing. This usually leads to a kernel panic during newfs. If I leave some amount free, (ie the subdisk only uses 8000mb of a 8675mb drive) no problem. If i'm RTFM'ing correctly, it looks like it should reserve 132kb per drive. I guess I assumed that would be automagically reserved, or if it's supposed to be, it's getting walked on. Next, I disklabel each drive (they're all identical) # /dev/da0s1c: #size offsetfstype [fsize bsize bps/cpg] c: 177678270unused0 0 # (Cyl.0 - 1105*) h: 177678270 vinum# (Cyl.0 - 1105*) I alway leave 64 sectors free at the beginning of the disk: h: 1776776364vinum# (Cyl.0 - 1105*) I think this is where the partition tables live, you are probably overwriting them when vinum writes its metadata. I think a normal UFS filesystem will leave 64 sectors of slack space at the beginning of the partition, but vinum may not. I may also be totally wrong. Joe Koberg joe at osoft dot us ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
