Re: Why Are You NOT Using FreeBSD ?
Hi all, Am 01.06.2012 um 14:03 schrieb Mehmet Erol Sanliturk: [...] If you are NOT using FreeBSD for any area or some areas , would you please list those areas with most important first to least important last ? We are using two FreeBSD-Servers as a SAMBA-Server and as a plot-server, partly using the Linux-ABI. Both servers are rock solid (HP ProLiant). But I'm not brave enough to run an ORACLE Database-Server under FreeBSD. For a corporate database server I need official vendor support for that platform and therefor I have to use RedHat or SuSE. It's really a pity. I'm using FreeBSD since version 2.05 and was never disappointed. Best regards Matthias -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany)
NFS-Locking problems
Hello, I want to remind to the kern/132934-PR. Are we the only ones that have Problems with the NFS-Locking? I try every week the latest -STABLE code but nothing changed so far. Are there any chances to get NFS-locking working with HP-UX 11.11 machines again with 7.2-RELEASE? Greetings - Matthew -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany)
Re: NFS-Locking problem with 6.4/7.1-RELEASE
Hi Garret, Am 19.01.2009 um 22:29 schrieb Garrett Cooper: What OS and what NFS version are the HP-UX servers running? The OS is HP-UX 11.11 a.k.a HP-UX 11iv1. NFS-Version is NFSV3 (of course ;-) via TCP Have you checked /var/log/messages on the clients and on the server for helpful messages? No, I'll look tomorrow. I tested today against 7.1-STABLE (of today) but no change in behaviour so far. In the meantime I found PR kern/130628 and that could be the problem here too. I started 'wireshark' on the NFS-server today and it showed endless requests from the client to release a lock and equally endless error-replies... At least I would expect that an error like that in kern/130628 would look like what I observed today - but I may fail. Thanks for your reply - Matthew -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany)
NFS-Locking problem with 6.4/7.1-RELEASE
Hello, I operate two FreeBSD-Servers in a Windows- and HP-UX Environment. One is a SAMBA-Server as a gateway between the Windows and the Unix world, the other is NFS-Server for the HP-UX 11i v1 Workstations. Both are HP ProLiants DL380 with additional external disks on SmartRAID Controllers. Since the HP-UX Workstations and their disks are becoming quite old, I started to move the home-directories to the FreeBSD Server, wich worked with 6.3-RELEASE quite good so far. Brave as I am, I updated the servers to 6.4 RELEASE and since then the users on the HP-UX machines with the homedirs on the FreeBSD-Server were locked... :-( I tried to find out what was happening and this are my results: When a user logs in on a HP-UX machine, his '.profile' file is opened and read/executed, but it seems, that it cannot be closed any more. So if the last line in the '.profile' is echo foo bar you *can* see foo bar on the screen, but then nothing happens any more, the machine is locked. I recorded such a session with 'tcpdump' and looked at the dump... the only noticeable things are *Bursts* of NLM V4 CANCEL_MSGes on the same filehandle. Eg: V4 CANCEL_MSG Call FH:0x644201fe svid: pos:0-0 This line is repeated 7 times with various values for 'svid'. I'm no NFS specialist at all, so I cannot tell you more :-/ But I can supply the dump (if needed), it's 92KB, so the size should not be a problem... BTW: I tried this with and without kernel support for NFS-Locking - no difference. I also tried the new replacement server with FreeBSD 7.1- RELEASE: Just the same problems, with and without kernel support. I hope someone is willing to work on that issue... As mentioned, a new, non-productive server is available in the moment, so tests are easily possible. TIA Matthew -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany)
Re: removing external usb hdd without unmounting causes reboot?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Am 20.07.2007 um 08:16 schrieb Christian Walther: [...] It's a pity that FreeBSD can't handle these situations. Since no one here on this list has enough money to get development on the road, maybe we could try collecting money? Everyone interested in seeing this issue fixed offers the amount of money he/she likes to spend... I guess for a Summer of Code project this issue would be to big to fix, wouldn't it? Especially if I think about software RAID it's really a show-stopper. I remember a stress-test of *vinum* (without the g) years ago when I pulled the plug on one of the disks of a RAID5-plex... Obviously there's no change at all concerning this problem. - -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFGoTatf1BNcN37Cl8RAmTRAJ99PXwWaHxUq4I8P++hcMhpL5PSlwCgg5/R 9gy1Gj2+JYTRB5OvGOWFDF4= =XVsv -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Junk Pointer Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chuck, Am 23.08.2006 um 21:25 schrieb Chuck Swiger: Sure your hardware is OK? Try running memtest86 or a hardware diagnostic from your vendor, and double-check your fans PSU... Yes, I'm sure! Tried it today on my Laptop - same error! I think it's *very* unlikely, that two machines have exactly the same HW problems... Matthew - -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE7bjwf1BNcN37Cl8RAs8cAJ9PSb9M2hZPnqgxiLOb5fD3LEowcACfcAJv wUMB28fWj92KLQUxB5Gd2k0= =DJYs -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Junk Pointer Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I compiled net/krb5 today on my 6.1-STABLE machine. As I tried to initialize Kerberos with '/usr/local/bin/kinit User@Domain I got the following error: kinit in free(): error: junk pointer, too high to make sense Abort trap: 6 (core dumped) The same programs on my FreeBSD 5.5-RELEASE server run OK without such an error. 'smbd' died with the same error later on... This is a severe problem since I have to use MIT-Kerberos to connect to our AD-Domain... Is there something I can do to avoid this problem? Matthew - -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFE7KW3f1BNcN37Cl8RAl3fAJsEtqiV7ttVyUruuEkWsZ130kyV0QCdHF7N BkxAziq+7G6A/WtnSZkQNjo= =FElW -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Junk Pointer Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chuck, Am 23.08.2006 um 21:25 schrieb Chuck Swiger: Sure your hardware is OK? Try running memtest86 or a hardware diagnostic from your vendor, and double-check your fans PSU... Hmm, I fear I'm never sure... But I'll try to compile krb5 on my laptop - a different machine, which should not have the same memory problems... - -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFE7LJif1BNcN37Cl8RAim+AJ9GJunF0IbmK/GY7IYP8HJEQjXIqgCePLeq hozJGAlpjr1EQGKe8bQw6Tk= =1FCe -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quality of FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Bruce A. Mah wrote: I know the developers don't hear it often enough, but thanks for all you=20 do. I'm not a programmer, and I currently don't have the funds to=20 donate to the project, but you do have my heartfelt thanks for still=20 turning out my favorite OS. You're welcome, and I'm sure I speak for at least a few other developers when I say that you'd be surprised how valuable a donation of a few kind words can be. I'm following this thread from the start on. To add a few kind words I may report that I have three FreeBSD-5 servers (COMPAQ/HP ProLiant) up'n running for quite some time now (starting with 5.2.1!) and they act very well!! Mainly NFS and Samba servers, so their focus lies on filesystem space. To be honest, I was a bit astonished how many people obviously use ATA-Disks in a fileserver environment. I just read an article in the german iX-Magazine where the author emphasizes (once again!) that ATA disks are *not* designed for 24*7 use (with the exception of WDs Raptor). Considered the weak definitions in the so called ATA- standard, I can't imagine for me personal to use ATA-disks for more than more or less temporary storage. Especially if I earn money with the server in question I always heard the urgent recommendation to use SCSI-disk. If I compare the value of the data with the cost of a SCSI subsystem, there are no questions any more... Some special kind words go to Soren Schmidt here. I never understood how one person could voluntary dive into this shark basin of ATA. There are no merits to earn and there seem to be always many special combinations of hardware, which don't work. A well thought out standard should avoid exactly that! So Hats off to Soren for his work and his boundless ability to suffer with the many complaints. So I stay with the old FreeBSD behaviour to use proven technology[TM] and let the cheap toys for the Linux-kiddies. It remains true: You get what you pay for! - -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC6zSnf1BNcN37Cl8RAnd0AJ9enOmZ1VcCLNG3CqTuwE5iHtSnJwCcCEAQ 5d1lAHQdhkMxyCDzj8E8xv4= =arDg -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic in 6-BETA1 during mount
additional info, let me know. If someone has ideas to solve this bug I'm ready to test/try out. -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quality of FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Robert, Am 21.07.2005 um 13:00 schrieb Robert Watson: Have you tried, and do you plan to try, our 6.0 test releases before 6.0-RELEASE goes out the door? Specifically, on the hardware you know you're having problems with 5.4 on? Yes, I did - see the thread mpt + gvinum on 6.0-BETA. But I'm a bit disappointed, that until now there's not *one* reply on my report. It's new hardware, which doesn't even boot with 5.3/5.4-RELEASE (but with 5.2.1 :-) and probably a more popular Server (FUJITSU-SIEMENS RX300 S2)... what was my fault here? Should I post to -current instead? - -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC3+wAf1BNcN37Cl8RAkgOAJ9uNrNXRdoQbn8CGKGnlp6e0+aTLwCdFrzU MkbX3dKcLQhI0B2wgEN6j7w= =Iaju -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mpt + gvinum on 6.0-BETA (boot -v)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.07.2005 um 15:45 schrieb Matthias Schuendehuette: I tried 6.0-BETA on one of our FUJITSU-SIEMENS RX300 S2 servers and it seems that I have problems with the disk subsystem, even after Scotts major overhaul of the mpt drivers... I'm not able to post detailed dmesg output in the moment (IMHO there isn't anything to notice, mpt0 and mpt1 are attached without any errors) but the symtoms are: - - very slow write performace: 'dd if=/dev/zero of=/dev/da0s2 bs=512 count=32768' reports a throughput of 80 k(!)Bytes/s. Read performance is somewhat better, 'dd' reports here about 2 MB/s... better, but not what I would expect from a RAID1 with two U320 SCSI- disks (Seagate BTW). If I try to 'boot -v', the system ends up in an endless loop with the following messages: Jul 18 11:52:37 blnn204x syslogd: kernel boot file is /boot/kernel/ kernel Jul 18 11:52:37 blnn204x kernel: fset 0x00 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus:0 Jul 18 11:52:37 blnn204x kernel: TargetID0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x0200 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength0x1000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6]08 04 12 9f 08 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63bf3000 FlagsLength=0xd1001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x00 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus:0 Jul 18 11:52:37 blnn204x kernel: TargetID0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x0200 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength0x0800 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6]08 06 4e 7b 04 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63af6000 FlagsLength=0xd1000800 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus:0 Jul 18 11:52:37 blnn204x kernel: TargetID0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x0200 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength0x4000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6]08 06 99 7f 20 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63bc2000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63be3000 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab040: Addr=0x7d745048 NxtChnO=0x0 Flgs=0x30 Len=0x10 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab048: Addr=0x63aa4000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab050: Addr=0x63be5000 FlagsLength=0xd1001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus:0 Jul 18 11:52:37 blnn204x kernel: TargetID0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x0200 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength0x0001 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6]08 04 65 1f 80 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63cef000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63c3 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab040: Addr=0x7d745048 NxtChnO=0x0 Flgs=0x30 Len=0x58 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab048: Addr=0x63fb1000
Re: mpt + gvinum on 6.0-BETA (dmesg)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.07.2005 um 15:45 schrieb Matthias Schuendehuette: I tried 6.0-BETA on one of our FUJITSU-SIEMENS RX300 S2 servers and it seems that I have problems with the disk subsystem, even after Scotts major overhaul of the mpt drivers... I'm not able to post detailed dmesg output in the moment (IMHO there isn't anything to notice, mpt0 and mpt1 are attached without any errors) but the symtoms are: - - very slow write performace: 'dd if=/dev/zero of=/dev/da0s2 bs=512 count=32768' reports a throughput of 80 k(!)Bytes/s. Read performance is somewhat better, 'dd' reports here about 2 MB/s... better, but not what I would expect from a RAID1 with two U320 SCSI- disks (Seagate BTW). [...] Here the promised 'dmesg'-output: Jul 18 11:54:41 blnn204x syslogd: kernel boot file is /boot/kernel/ kernel Jul 18 11:54:41 blnn204x kernel: Copyright (c) 1992-2005 The FreeBSD Project. Jul 18 11:54:41 blnn204x kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 18 11:54:41 blnn204x kernel: The Regents of the University of California. All rights reserved. Jul 18 11:54:41 blnn204x kernel: FreeBSD 6.0-BETA #0: Thu Jul 14 10:13:50 CEST 2005 Jul 18 11:54:41 blnn204x kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BLNN204X Jul 18 11:54:41 blnn204x kernel: ACPI APIC Table: PTLTD APIC Jul 18 11:54:41 blnn204x kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Jul 18 11:54:41 blnn204x kernel: CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2800.11-MHz 686-class CPU) Jul 18 11:54:41 blnn204x kernel: Origin = GenuineIntel Id = 0xf41 Stepping = 1 Jul 18 11:54:41 blnn204x kernel: Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR, PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Jul 18 11:54:41 blnn204x kernel: Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 Jul 18 11:54:41 blnn204x kernel: AMD Features=0x2010NX,LM Jul 18 11:54:41 blnn204x kernel: real memory = 2146959360 (2047 MB) Jul 18 11:54:41 blnn204x kernel: avail memory = 2096025600 (1998 MB) Jul 18 11:54:41 blnn204x kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Jul 18 11:54:41 blnn204x kernel: cpu0 (BSP): APIC ID: 0 Jul 18 11:54:41 blnn204x kernel: cpu1 (AP): APIC ID: 6 Jul 18 11:54:41 blnn204x kernel: ioapic0 Version 2.0 irqs 0-23 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic1 Version 2.0 irqs 24-47 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic2 Version 2.0 irqs 48-71 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic3 Version 2.0 irqs 72-95 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic4 Version 2.0 irqs 96-119 on motherboard Jul 18 11:54:41 blnn204x kernel: npx0: [FAST] Jul 18 11:54:41 blnn204x kernel: npx0: math processor on motherboard Jul 18 11:54:41 blnn204x kernel: npx0: INT 16 interface Jul 18 11:54:41 blnn204x kernel: acpi0: PTLTD XSDT on motherboard Jul 18 11:54:41 blnn204x kernel: acpi0: Power Button (fixed) Jul 18 11:54:41 blnn204x kernel: pci_link0: ACPI PCI Link LNKA irq 11 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link1: ACPI PCI Link LNKB irq 9 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link2: ACPI PCI Link LNKC irq 5 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link3: ACPI PCI Link LNKD irq 10 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link4: ACPI PCI Link LNKE on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link5: ACPI PCI Link LNKF on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link6: ACPI PCI Link LNKG on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link7: ACPI PCI Link LNKH irq 9 on acpi0 Jul 18 11:54:41 blnn204x kernel: Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Jul 18 11:54:41 blnn204x kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0xf008- 0xf00b on acpi0 Jul 18 11:54:41 blnn204x kernel: cpu0: ACPI CPU on acpi0 Jul 18 11:54:41 blnn204x kernel: cpu1: ACPI CPU on acpi0 Jul 18 11:54:41 blnn204x kernel: acpi_button0: Power Button on acpi0 Jul 18 11:54:41 blnn204x kernel: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 Jul 18 11:54:41 blnn204x kernel: pci0: ACPI PCI bus on pcib0 Jul 18 11:54:41 blnn204x kernel: pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 Jul 18 11:54:41 blnn204x kernel: pci1: ACPI PCI bus on pcib1 Jul 18 11:54:41 blnn204x kernel: pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 Jul 18 11:54:41 blnn204x kernel: pci2: ACPI PCI bus on pcib2 Jul 18 11:54:41 blnn204x kernel: mpt0: LSILogic 1030 Ultra4 Adapter port 0x3000-0x30ff mem 0xde11-0xde11,0xde10-0xde10 irq 24 at device 8.0 on pci2 Jul 18 11:54:41 blnn204x kernel: mpt0: [GIANT-LOCKED] Jul 18 11:54:41 blnn204x kernel: mpt0: MPI Version=1.2.14.0 Jul 18 11:54:41 blnn204x kernel: mpt0: Unhandled Event Notify Frame. Event 0xa. Jul 18 11:54:41 blnn204x kernel: mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE ) Jul 18 11:54:41
mpt + gvinum on 6.0-BETA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I tried 6.0-BETA on one of our FUJITSU-SIEMENS RX300 S2 servers and it seems that I have problems with the disk subsystem, even after Scotts major overhaul of the mpt drivers... I'm not able to post detailed dmesg output in the moment (IMHO there isn't anything to notice, mpt0 and mpt1 are attached without any errors) but the symtoms are: - - very slow write performace: 'dd if=/dev/zero of=/dev/da0s2 bs=512 count=32768' reports a throughput of 80 k(!)Bytes/s. Read performance is somewhat better, 'dd' reports here about 2 MB/s... better, but not what I would expect from a RAID1 with two U320 SCSI-disks (Seagate BTW). - - 'gvinum' has its problems too with this RAID Volume: I *can* create a gvinum-drive on /dev/da0s2, but it remains 'down'. I can't 'start' it and after a reboot, the gvinum-drive has gone and gvinum is absolutely clean again. This seems not to be a problem of gvinum, as it works perfectly under 6.0-BETA on my personal machine (Athlon-XP 2000, ahc-controller, FUJITSU SCSI disk). Still to mention: The RX300 has two Xeon CPUs and 2Gig RAM. It runs with a stripped down kernel, based on GENERIC *without* all that WITTNESS and INVARIANTS stuff. /etc/malloc.conf is linked to 'aj' - that's all that I know of debugging options in CURRENT kernels... The questions I have: The LSI 1040 RAID-Controller is absolutely new to me, I did configure a RAID1 Volume, synchronized it and that's all. Is there anything to tweak besides the default config of that controller? What additional informations do you need? I should be able to supply them on monday... But there's not too much time to test, this machine should become a Windoze printserver in about two or three weeks... It seems to me that the HP DL380 is still the better machine... :-/ - -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC174af1BNcN37Cl8RAtvcAKCDwcuIA7XusCCX80N6b4LmN0JRKwCfbvA+ VSfudFkdO3UHmOqpVR18obU= =Vzw8 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amd(8) on port 631?? [SOLVED]
Hi Sean, Am Sonntag, 13. März 2005 05:33 schrieb Sean Winn: On 13/03/2005, at 10:00 AM, Matthias Schuendehuette wrote: Hi, since the last system update today (5.4-PRERELEASE) the automountdaemon amd(8) grabs port tcp/631 which prevents cupsd(8) from starting which in turn prevents smbd(8)/SAMBA from starting. AMD allocates a random reserved port (1024) - it just hits on 631 in this case. Try changing the sysctls: net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 (those are the default on my 5.4-PRE/i386 box) Thanks a lot. I set net.inet.ip.portrange.lowlast=599 in /etc/sysctl.conf and now amd(8) picks port 890 ... Somtimes randomness is really funny - I don't think that there's something to understand... Anyway - Problem solved! Thanks a lot again! Matt -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
amd(8) on port 631??
Hi, since the last system update today (5.4-PRERELEASE) the automountdaemon amd(8) grabs port tcp/631 which prevents cupsd(8) from starting which in turn prevents smbd(8)/SAMBA from starting. How come? Have I overlooked something? -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [SOLVED] ABI broken for 5.4-PRERELEASE?
Hi Scott, Thanks for you reply. Am Freitag, 4. März 2005 06:10 schrieb Scott Long: Matthias Schuendehuette wrote: The error message is: xsysinfo: undefined symbol: _nfiles I had the belief, that this does not happen within a major release of FreeBSD... isn't it? This looks like an accident. John Baldwin committed a fix to RELENG_5 a few hours ago, so if you can update and retest, it would be appreciated. Yes, you're right! I re-cvsupped the sources and voila - xsysinfo(1) works again. Obviously I met the right moment[TM] with my last update... :-/ ...never mind. Note the xsysinfo gropes around in KVM, which is highly fragile. Most of the information that it's looking for is available via sysctl's, which are a lot more stable and reliable. It would be nice if xsysinfo was changed to use these instead. I looked at the sources, but did not get the basic understanding - at least not instantly. In the moment i try to improove gvinum together with le. There are still some areas where gvinum can't be called 'fail-save' - as I experienced last weekend... Anyway - thanks a lot again! Problem solved. -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ABI broken for 5.4-PRERELEASE?
Hi, yesterday (MAR02,2005) I updated to 5.4-PRERELEASE. Since then, 'xsysinfo-1.4a' doesn't run anymore. The error message is: xsysinfo: undefined symbol: _nfiles I had the belief, that this does not happen within a major release of FreeBSD... isn't it? -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: (g)vinum with 5.3
Am Freitag, 11. Februar 2005 13:05 schrieb Henning Kropp: [...] drive a device /dev/ad0s1e drive b device /dev/ad1s1c //has changed to s1c drive c device /dev/ad2s1c / -- volume myvolume plex org concat // I mist to post that the last time, sry! sd length 3214325K drive a sd length 3242353K drive b sd length 3214243K drive c //size dont matter here [...] root# bsdlabel /dev/ad2s1c # /dev/ad2s1c: 8 partitions: size offsetfstype [fsize bsize bps/cpg] c: 78172227 634.2BSD 2048 16384 28552 # raw part, don't edit partition c: partition extends past end of unit bsdlabel: partition c is not marked as unused! bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities Both have an offset of 63, which is the default I think. But still bsdlabel is not very happy with both. I sry but I cant tell why. If anybody could I'll be happy to know. Did you read what bsdlabel(8) told you? The # raw part, don't edit behind the 'c'-data for instance? This is not meant as a joke... really: *don't edit*! According to the bsdlabel(8) man-page (hint, hint! :-), the 'c'-partition stands for the whole disk or slice resp. and has to have the type 'unused' and an offset of 0. It must not be used at all! The 'a'-partition of the boot disk is used for the root filesystem and any 'b' partitions are generally used for swap space. So it's save to use partitions 'd'-'h' for filesystems, additionally partition 'a' on non-boot disks. Please read the bsdlabel(8) man-page *and* the FreeBSD Handbook, Chapter 16.3 *before* you label your disk. But what happens when either try to run vinum or gvinum is: vinum easily runs with this configuration but as the system reboots it panics saying: panic: umount. dangling vnode As I mentioned already: You *must* start classic-vinum *after* the main filesystems are already mounted. That is either you do it manually (e.g. once for backup purposes) or you modify the 'vinum'-script in /etc/rc.d so that it is executed after... I would try after LOGIN. You must not load classic-vinum via /boot/loader.conf. You also have to modify the (classic-) vinum-filesystems in /etc/fstab so that they are not mounted automaticly ( option 'noauto'). See the fstab(5) man-page for details. Because all of this I always mounted classic-vinum filesystems manually under FreeBSD-5... :-) I was told that this is to vfs_mount.c and geom_dev.c and a downgrade to vfs_mount.c 1.27 and geom_de.c 1.75 would make the thing work again. This is because the new versions together cant deal with every config, for example it cant work with mine. How can I either downgrade or rewrite my config?? (Maybe Mathias has written his PR) I never tried this way... Of course I tried to use gvinum right from the start. But with the config gvinum tells me, that drive a (dev/ad0s1e, by now mounted with /usr) is already known. Well, dont know what gvinum is tying to tell me here. What?! Did you mount it? Or is it still mentioned in /etc/fstab but not mounted any more... If you *did* mount /dev/ad0s1e as /usr you should start from the beginning reading the vinum(8) man-page as well as Chapter 17 of the handbook. Then there's a basic misunderstanding how (g)vinum should be configured... You can mount /dev/(g)vinum/myvolume but not any of the drive partitions! I surely appreciate any help. Thanks! -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: (g)vinum with 5.3
Hi Henning, Am Mittwoch, 9. Februar 2005 11:16 schrieb Henning Kropp: [...] The result I at boot time is a screen continuously printing out: GEOM_VINUM: plex request failed for gvinum/plex/myvolume.p Does anybody know where to start from here? There are some points to check: a) Is this a RAID-5 Volume under 5.3-RELEASE? - Upgrade to 5-STABLE! gvinum RAID-5 is known *not* to work under 5.3-RELEASE. The error was fixed during the freeze of the source tree for 5.3-RELEASE, so it was committed shortly ( 1 week or so) *after* the release was built. b) Check your vinum partitions with bsdlabel. In your case: bsdlabel /dev/ad0s1e bsdlabel /dev/ad1s1d bsdlabel /dev/ad2s1d Check if any of the vinum-type partitions have an offset of 0 (zero). Partitions with an offset of 0 are known *not* to work with GEOM_vinum. I consider this a feature and not a bug, because with gvinum you can use whole disks or slices without the need of BSD- or DOS-partitiontables. The back side of this is, that gvimum *must* be able to distinguish a BSD-Partition from a DOS-Slice, which is not the case if the BSD-Partition has an offset of 0. The partition type is not evaluated by gvinum at all, because it doesn't need one. If that's the case, you're in trouble. Suck the data on tape and rebuild your volume with gvinum on partitions with an offset of 16 (the default). I had all these problems during my migration to gvinum but no more... ...but im using SCSI-Disks only, so the whole ATA-Stuff is possibly a further source of trouble. Any errors from this direction? All disk are masters? Parralel- or S-ATA? Besides: You *can* use classic-vinum under FreeBSD-5 if you hold vinum until the system has come up and the main partitions are mounted. If all these points don't leed to an solution, perhaps contact Lukas Ertl ([EMAIL PROTECTED]) directly, which is the maintainer of gvinum... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
load values
Hi, I updated my system (5-STABLE) just today and now I get extraordinary load-values: 'top' says (e.g.): load averages: 443.73, 36.47, 60.50 I haven't running 400 processes at all! The man page for GETLOADAVG(3) says: The getloadavg() function returns the number of processes in the system run queue averaged over various periods of time. So - what's going on here? -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: load values [SOLVED]
Hello, Am Samstag, 5. Februar 2005 21:06 schrieb Dominique Goncalves: I have had the same problem exactly today. Re cvsup your src tree and rebuild kernel and world solved this problem. Yes, indeed. Thanks a lot! -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ 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 and vinum upgrade #2
Am Montag, 20. Dezember 2004 00:04 schrieb Nikolaj Hansen: [...] The whole problem is, I cannot mount any thing without doing it this way. The reason for this is, as you pointed out , that my disk setup is different than the norm: $ sudo bsdlabel da1s1 Password: # /dev/da1s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 51200004.2BSD 2048 16384 32008 b: 1228535 512000 swap c: 177678270unused0 0 # raw part... h: 16027292 1740535 vinum Both sides of the mirror are made like this. This disk setup seems to me perfectly legal. Your vinum-partition has an offset of 1740535 which is != 0, that's all that I meant. Of cause I _really_ want to keep the data on the disks. Is there an easy way to fix the disks for geom_vinum compability, or do they need to be rebuilt from the ground up? I don't know any hints any more, sorry. I send a pointer to [EMAIL PROTECTED], which is the creator of geom_vinum, because he follows -current and not -stable AFAIK. -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 and vinum upgrade #2
Am Sonntag, 19. Dezember 2004 07:12 schrieb Nikolaj Hansen:
I gave the 5.3 upgrade another swing. Now the situation is:
$ uname -a
FreeBSD sauron.barnabas.dk 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Sat
Dec 18 18:39:09 CET 2004
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/KERNEL_5_3 i386
Perhaps you better upgrade to RELENG_5 (5.3-STABLE). I'm not aware of
any reasons against that in the moment and, besides others, gvinum was
improoved since 5.3-RELEASE. But that's your decision...
I think I am understanding a little more of this now. In order to use
my scsi / ATA setup, I need to use the geom_vinum.ko *and* the
vinum.ko modules?
Oh no! Don't do that!
If you switch to the new geom_vinum, all you *should* need is:
geom_vinum_load=YES in /boot/loader.conf
Please comment out (or remove) the vinum*-lines in loader.conf!
Additionally you have to change all the entries in /etc/fstab to
/dev/gvinum/volume_name /mount_point
(Note the *g*vinum in the device path)
But for the first test, you better comment out these lines and try to
mount the volumes manually...
[...]
Is this correct? I suppose the ATA drives should be mounted on the
new /dev/gvinum/* and the scsi drives on the /dev/vinum/*?
No! As stated above, *all* should now be handled by geom_vinum.
[...]
As I wrote earlier the above loader.conf is not working. If I leave
out the load of the old vinum driver it does not seem to be possible
to mount the scsi drives. If I leave out the geom_vinum a mount of a
drive causes a kernel panic.
You *can* use the old classic vinum, but it only works if you start
classic-vinum *after* the system has come up. You cannot start
classic-vinum at boottime with loader.conf, at least it doesn't work
for me ('dangling vnode'-panic...).
Before you switch to geom_vinum, you should check your partitions as
already mentioned in an earlier mail...
Try a 'bsdlabel /dev/da1s1' and see, if your vinum-partition does *not*
start at an offset of 0.
On my disk, it looks as follows:
8 partitions:
#size offsetfstype [fsize bsize bps/cpg]
a: 4226709 16 vinum
c: 42267250unused0 0 # raw part...
So here the vinum partition starts at an offset of 16 and therefor is 16
blocks smaller than the whole disk ('c'-partition). That's ok.
If it *would* read like that:
8 partitions:
#size offsetfstype [fsize bsize bps/cpg]
a: 42267250 vinum
c: 42267250unused0 0 # raw part...
it would not work with geom_vinum!
The background is, that with geom_vinum you don't need any
vinum-partitions any more, further it is possible to use the whole disk
(or slice) *without* any BSD partitions. But in the latter case above
(with 0-offset), geom_vinum can't distinguish between the whole slice
and the 'a'-partition. This did lead to an error (I did not try this
with a recent geom_vinum). Anyway, you better spend these 16 blocks
offset to be sure IMHO ...
It would be nice if any of you would comment on the above config.
I hope it's a bit more clear now...
Perhaps I am ignorant, but it seems to me it would have been easier
to make the regular vinum diver handle geom drives in place of making
a new kernel object? Or perhaps theres a technical reason for not
doing so?
Exactly that's the case. If you have to use a completly different
infrastructure below, it's obviously more easy to start from scratch...
--
Ciao/BSD - Matthias
Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany)
PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 and vinum upgrade #2
Am Samstag, 18. Dezember 2004 20:52 schrieb Nikolaj Hansen: [...] I think I have to disagree calling muliple drives on a disk uncommon. In fact, I think I remember that being the way it was demonstrated in an old version of the handbook. Here is my current setup after rolling back to FreeBSD 5.2.1: 3 drives: D elben State: up /dev/da1s1h\ A: 0/7825 MB (0%) D donau State: up /dev/da0s1h \ A: 0/7825 MB (0%) D spree State: up /dev/ad4a A: 3/114473 MB (0%) [...] As far as I can tell, the new 5.3 release makes this disk configuration invalid? If yes, is that a permanent decision, or something that will change in near future say 5.4? If not I have a major problem here :-( I don't undestand your excitement... :-) You have three (vinum) drives on three seperate (physical) disks. On these drives are several concat-plexes. Nothing here violates the requirements for the GEOM-based vinum, if your old vinum-type partitions don't start with an offest of 0 (zero) within the slice (da0/da1) or disk (ad0) respectively. *If* that's the case (i.e. Offset of 0 for the vinum partitions), you have a problem indeed but otherwise I would not expect any problems. -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 and vinum upgrade #2
Am Samstag, 18. Dezember 2004 23:35 schrieb Paul Mather: The biggest problem you'll have is if your system suffers the ATA TIMEOUT - WRITE_DMA woe that bedevils some of us under 5.3. When that happens, your mirror will be knocked into a degraded state (half of your mirrored plexes will be marked down) even though the drive is okay. Unfortunately, without setstate being implemented in gvinum to mark the drive as up, thereby allowing you to issue gvinum starts for the downed plexes, there's little more you can do to get the failed drive recognised as being in the up state other than to reboot. [...] 'gvinum setstate' was MFCed from -current together with 'gvinum checkpatity' and 'gvinum rebuildparity' a week ago or so... So that should make it easier to handle these ATA-Problems... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gvinum again?
Hi, Am Montag, 15. November 2004 18:25 schrieb Paul Mather: [...] I don't know if growfs is 100% robust enough yet to provide the other important ingredient to a true LVM storage management system a la the logical volume manager on AIX or AdvFS on Tru64, say. Yes, it is. I use (g)vinum primarily as a LVM with concat plexes on ProLiant Servers with SmartRAID-Controllers, so mirroring and/or RAID5 is done in hardware. The extension of filesystems on concat plexes works (simply) as advertised... :-) At least *I* had no problems so far. -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gvinum again?
Hi, Am Montag, 15. November 2004 19:41 schrieb Paul Mather: On Mon, 2004-11-15 at 19:33 +0100, Matthias Schuendehuette wrote: The extension of filesystems on concat plexes works (simply) as advertised... :-) At least *I* had no problems so far. That's encouraging to hear! Can you shrink volumes and filesystems like you can on, say, AdvFS under Tru64? That would be really nice. No, look at the growfs(8) man-page... But, honestly, my users are only *extending* their space desires... BTW my operating system too :-) So, I never had the need to shrink a filesystem. Only that of Windows if I want to install FreeBSD additionally :-) -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] 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 ?
Hello, Am Mittwoch, 10. November 2004 22:31 schrieben Sie: ok, your instructions worked like a charm. So i'm running my nice 4 member SCSI gvinum raid5 array (with softupdates turned on), and it's zipping along. Fine! :-) Now I need to test just how robust this is. Ouhh... ;-) camcontrol is too nice. I want to test a more real world failure. I'm running dbench and just pull one of the drives. My expectation is that I should see a minor pause, and then the array continue in some slower, degraded mode. That was mine too... What I get is a kernel trap 12 (boom!). I reboot, and it will not mount the degraded set till I replace the drive. I turned off softupdates, and had the same thing happen. Is this a bogus test? Is it reasonable to expect that a scsi drive failure should of been tolerated w/o crashing? No, of course not. I have more or less the same problems here. Once I came so far as to delete the crashed subdisk but when I tried to delete the (not existing anymore) vinumdrive, my kernel also crashed... Well, to be honest, I once tried to pull the plug on one of my disks with 'classic' vinum and I got a kernel panic as well. OK, this happened a few years ago and I never tried that again... I'm not sure if this is a problem of (g)vinum or if FreeBSD has other problems in this area. And we all have to consider that gvinum is in a relatively early development phase (IMHO) - it is basically working, that is, it's possible to continue an existing 'classic' vinum installation with gvinum but it's still not fully functional in all depth. But I think, there's all the potential to get there. I have the impression that Lukas is *very* interested in his baby and I have a good overall feeling so far. But he's the only one developing gvinum AFAIK... And - my primary interest is the LVM functionality of (g)vinum. IMHO if you *really* have valuable data to protect, you can afford a hardware RAID-controller (*and* a tape drive :-). Anything else is wrong economy. But the current disk layout possibilities with up to four slices and at max 28 BSD-partitions are far to inflexible for todays large disks. So from this point of view I'm already fairly happy with gvinum as it is today. Which doesn't mean that I'm not trying to help to get gvinum to the place and state where it deserves to be... :-) -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] 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 ?
Am Sonntag, 7. November 2004 06:30 schrieb secmgr: On Sat, 2004-11-06 at 04:16, Matthias Schuendehuette wrote: Did you try to simply 'start' the plex? This works for initialisation of a newly created RAID5-Plex as well as for recalculating parity informations on a degraded RAID5-Plex. I did a gvinum start. No, that's not what I meant. 'gvinum start' loads the kernel module which in turn searches for vinum-GEOMs and loads the configuration data. It doesn't change the state of any gvinum item. Try 'gvinum start plex-name' or within gvinum(8): gvinum start plexname This (as far as I investigated :-) a) initializes a newly created RAID5-plexor b) recalculates parity informations on a degraded RAID5-plex with a new replaced subdisk. So, a 'gvinum start raid5.p0' initializes my RAID5-plex if newly created. You can monitor the initialization process with subsequent 'gvinum list' commands. If you degrade a RAID5-plex with 'camcontrol stop diskname' (in case of SCSI-Disks) and 'repair' it afterwards with 'camcontrol start diskname', the 'gvinum start raid5.p0' (my volume here is called 'raid5') command recalculates the parity and revives the subdisk which was on disk diskname. -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] 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 ?
Am Mittwoch, 3. November 2004 21:27 schrieb secmgr: Just ran into this myself. I had a perfectly happy raid 5 plex under 5.3 RC1. I upgrade to RC2, and the whole plex goes stale. I deleted everything from the volume on down (except for the drives), and tried to recreate the vol/plex/sd's. gvinum creates them, but they come back (like the undead) as stale and unusable (just like they were before). I'm finding commands documented (in help), but unimplemented (checkparity? init?). Did you try to simply 'start' the plex? This works for initialisation of a newly created RAID5-Plex as well as for recalculating parity informations on a degraded RAID5-Plex. It's that simple (at least for me on 5-STABLE) but admittedly undocumented. -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F pgptKVpJvEOEJ.pgp Description: PGP signature
Re: freebsd 5.3 have any problem with vinum ?
Am Mittwoch, 3. November 2004 21:27 schrieb secmgr: I hate to sound like a whiney baby, but WTF is going on? It feels like vinum from 4.x has basicly been abandoned (short of crashes with no workaround), and gvinum ain't near ready for primetime. If you mean the 'dangling vnode'-problem with vinum-classic: Try to start 'classic' vinum *after* the system has come up. Either manually or perhaps with a script in /usr/local/etc/rc.d. This works for me until now under 5-STABLE (a.k.a. RELENG_5). -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F pgpme8ARVpsD3.pgp Description: PGP signature
Re: Software raid 1 on root partition?
Excuse me if I step in here... Gerhard Sittig wrote: The trick is to load a kernel with software RAID support even before you have a root filesystem with your kernel and modules on it. :) This is not different between Linux and FreeBSD. Putting everything you need to boot into a ramdisk and loading it with your favourite boot manager is the solution. Ahm... where's the beef? I.e. where does this RAM-Disk Image come from? It's safe to *read* from one of the two disks, but what I don't understand is: Asume there are 4 disks: disk #1+#3 are RAID1 for -STABLE, disk #2+#4 are for -current. I want to boot -stable, so I try to load the RAM-Disk Image from disk #1 - but it's crashed. How do I know what disk to use next? Please answer per Mail too, I'm reading this list via docs.freebsd.org -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 4.6-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ATA Atapi 4.6 Release
Hello all, I haven't read the whole thread so far, but... I would encourage some posters to cool down a bit. There are only a few types of ATA-Disks that support Tagged Queuing and they all work with Write Cache nearly as fast as with WC+TQ. I made some comparison (admittedly with a SCSI-Disk :-) between TQ and WC and I found out, that, when copying the whole ports-tree f.i., TQ and WC have nearly the same performance gain and TQ+WC adds another 10% performance... so, no big deal IMHO. Of course, safety is another point, and I prefer TQ over WC exactly because of this! But - to be honest - I prefer SCSI over ATA because of this ;-) So, in the end I think it's a at least possible decision to release 4.6 with ATA 'as is'. It's switched off by default and shouldn't frustrate any new users. It should be stated clearly and 'loud', that ATA Tagged Queuing in not working on many chipsets and that the situation is expected to improve during 4.6-STABLE. And BTW: I don't think that it's helpful to focus on that ATA TQ-Issue so hard and to imply (at least between the lines of some postings) that Soren's driver is all crap. It's obviously the best driver we *have* and obviously the most knowledgeable ATA-Programmer who's working for 'our' FreeBSD and we should appreciate that. -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.6-RC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ATA-tags broken on STABLE (long!)
}
(kgdb) up
#8 0xc01356b7 in ata_getparam (atadev=0xc114c72c, command=236)
at /usr/src/sys/dev/ata/ata-all.c:428
(kgdb) list
423 struct ata_params *ata_parm;
424 int retry = 0;
425
426 /* apparently some devices needs this repeated */
427 do {
428 if (ata_command(atadev, command, 0, 0, 0, ATA_WAIT_INTR)) {
429 ata_prtdev(atadev, %s identify failed\n,
430command == ATA_C_ATAPI_IDENTIFY ? ATAPI : ATA);
431 return -1;
432 }
(kgdb) up
#9 0xc013637e in ata_reinit (ch=0xc114c700)
at /usr/src/sys/dev/ata/ata-all.c:845
(kgdb) list
840 printf(\n);
841 #if NATADISK 0
842 if (newdev ATA_ATA_MASTER !ch-device[MASTER].driver)
843 ad_attach(ch-device[MASTER]);
844 else if (ch-devices ATA_ATA_MASTER \
ch-device[MASTER].driver) {
845 ata_getparam(ch-device[MASTER], ATA_C_ATA_IDENTIFY);
846 ad_reinit(ch-device[MASTER]);
847 }
848 if (newdev ATA_ATA_SLAVE !ch-device[SLAVE].driver)
849 ad_attach(ch-device[SLAVE]);
(kgdb) up
#10 0xc013e2ba in ad_timeout (request=0xc11d2600)
at /usr/src/sys/dev/ata/ata-disk.c:893
(kgdb) list
888 request-bp-b_flags |= B_ERROR;
889 devstat_end_transaction_buf(adp-stats, request-bp);
890 biodone(request-bp);
891 ad_free(request);
892 }
893 ata_reinit(adp-device-channel);
894 }
895
896 void
897 ad_reinit(struct ata_device *atadev)
(kgdb) up
#11 0xc018858d in softclock () at /usr/src/sys/kern/kern_timeout.c:131
(kgdb) list
126 } else {
127 c-c_flags =
128 (c-c_flags ~CALLOUT_PENDING);
129 }
130 splx(s);
131 c_func(c_arg);
132 s = splhigh();
133 steps = 0;
134 c = nextsoftcheck;
135 }
(kgdb) quit
Hope that helps
--
Ciao/BSD - Matthias
Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany)
Powered by FreeBSD 4.5-STABLE
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
isp-device broken in 4.5-PRERELEASE
Hello, something's broken with the isp-device (ISDN syncPPP network device). The last working kernel was of dec 8, 2001. I found the problem after my next update at dec 15, 2001. Until today, the 'isdnd' worked with the old kernel of dec 8, but now the new userland doesn't fit anymore. THANK GOD my old modem is still working! :-) What I found out so far: It seems nothing to do with the files in src/sys/i4b that changed between dec 8 and dec 15. I downloaded the files in question via CVSweb and built another kernel but the problems still remain. After that, i played around with 'ping -n' and 'tcpdump -n' and found, that the sppp-part works fine (authentication succeeds), even the ICMP-packets are going forth and back (the dial-out process is triggered and i can see the packets in the tcpdump output) but obviously they never reach the ping process again. 'ping -n 194.64.64.23' reports: PING 194.64.64.23 (194.64.64.23): 56 data bytes ^C --- 194.64.64.23 ping statistics --- 6 packets transmitted, 0 packets received, 100% packet loss but the 'tcpdump -n -i isp0' shows: 22:19:41.194471 IP 88: 213.73.67.35 194.64.64.23: icmp: echo request 22:19:41.258523 IP 88: 194.64.64.23 213.73.67.35: icmp: echo reply (DF) 22:19:41.258790 IP 88: 194.64.64.23 213.73.67.35: icmp: echo reply (DF) 22:19:42.202641 IP 88: 213.73.67.35 194.64.64.23: icmp: echo request 22:19:42.264898 IP 88: 194.64.64.23 213.73.67.35: icmp: echo reply (DF) 22:19:42.265110 IP 88: 194.64.64.23 213.73.67.35: icmp: echo reply (DF) [...] I already mailed with hm on that, but he has no ideas. I also don't believe that an error is in the i4b subsystem (see above). And I'm not the only one with these problems, in the german bsd-newsgroup are at least two other persons with exactly the same problems... Please have a look on that issue. If I can do any further testing, I'll do it ASAP. Ciao/BSD - Matthias -- *** * Matthias Schuendehuette [EMAIL PROTECTED] * * Solmsstrasse 44 * * D-10961 BerlinEngineering Systems Support and Operation * * Germany (Powered by FreeBSD 4.4-STABLE) * *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Showstopper in 4.4-RC1 (SCSI)
Hi, On 19-Aug-01 Matthias Schuendehuette wrote: there's a showstopper in 4.4-RC1 as of Sat, 18th Aug, around 18:00 UTC: My machine stopps booting after submitting the SCSI-Reset command to both of my 'sym'-Controllers. Just for information: This was *not* the PCI-Problem (which came soon afterwards) but a problem with the onboard USB-device (VIA KT133/686B). I had disabled the USB device since I started using my actual motherboard (EPOX 8KTA2). A few days ago, I enabled the USB device to see if it was recognized by FreeBSD but I missed to *enable* an IRQ for the USB-Device. This produced the boot hang. The last messages from 'boot -v' (which I used far too late, excuse me...) I could see was: Device configuration finished. device combination doesn't support shared irq0 intr_connect(irq0) failed, result=-1 After I saw this message I remembered the USB device and disabled it at once - FreeBSD booted again! Further tests led to the missing/disabled IRQ for the USB device. FreeBSD 4.4-RC now - boots again - probes all PCI devices :-) - recognizes USB as well as ACPI - operates all ISDN devices again (thank you, Hellmuth!) - works like a charm! :-))) Ciao/BSD - Matthias -- Matthias Schuendehuette [EMAIL PROTECTED] Solmsstrasse 44 Date: 23-Aug-01 D-10961 Berlin Time: 21:37:06 This message was sent by XFMail + FreeBSD 4.4-RC -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
vinum(?) strange behaviour (4.4-PRE)
Hello, I see some strange behaviour of (not necessarily) vinum on my machine: When returning to multiuser mode after a shutdown to single user mode I get a page fault after vinum has updated its tables from the array disks. This is absolutely reproducable. I'm not shure if it's a 4.4-PRE Issue, but at least, it happens now. Can anybody confirm this? BTW: I have my /usr/obj on a vinum RAID5-volume and it works perfectly stable! Only this shutdown-restart sequence is in the moment an absolute No-No Ciao/BSD - Matthias -- Matthias Schuendehuette [EMAIL PROTECTED] Solmsstrasse 44 Date: 15-Aug-01 D-10961 Berlin Time: 22:00:55 This message was sent by XFMail + FreeBSD 4.4-PRERELEASE -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
