Re: chsh corrupts /etc/pwd.db
> On Aug 21, 2019, at 2:55 PM, Alan Somers wrote: > > Today I tried to use chsh to change my shell from bash to fish. The > command completed successfully, but new logins continued to use bash! > Investigating, I discovered that /etc/pwd.db and /etc/spwd.db seem to > contain 3-4 entries per user. One of those still refers to my old Berkeley DB files can only have a single index, so users are stored three times, once by username, once by uid, and once by line number. So that isn’t corruption. > shell. Worse, if I try using chsh again, it fails with an "entry > inconsistent" error, and I have to restore the password files from > backup. Has anybody seen something like this before? This is just a > single system, with no NIS or LDAP. You shouldn’t need to restore the files. You should be able to just regenerate the *.db files from the master.passwd file: /usr/sbin/pwd_mkdb -p /etc/master.passwd Unless, of course your master.passwd file was damaged. But the *.db files are really just caches for faster access to user data. The real master file is master.passwd. The ch* tools typically just change master.passwd, and then call pwd_mkdb to rebuild the *.db files. Tom ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: /dev/led soekris 6501.
>> >> How come there is no support for “ready" and “error" leds on the soekris >> 6501 even though it seems fairly easy to control them? >> > > a) perhaps no developer have that board? > b) nobody has written the necessary code to do so? > c) There is no generally accepted meaning for what “ready” or “error” LEDs might mean in FreeBSD, so implementing a driver for these LEDs may be a solution in a search of a problem. Tom ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ping from web application
On Aug 18, 2015, at 7:15 AM, Lowell Gilbert freebsd-stable-lo...@be-well.ilk.org wrote: Marko Cupać marko.cu...@mimar.rs writes: I use web applicaton (net-mgmt/phpipam) which should have the ability to check hosts' availability via ping. I can even specify path to ping executable. This functionality does not work on FreeBSD by default, and suggested workaround is to set setuid bit on /sbin/ping. I don't like to modify permissions of base files. Is there an alternative solution? e.g. a port? In what way does ping(8) not work? A look at its error output should tell you what the problem is. Additionally, the standard permissions on /sbin/ping *are* suid root. It certainly won't work if you've changed that, so just change it back. And yes, there are other ping programs present, including some with pretty graphical web page UIs. But there's no reason that PHP should have trouble calling /sbin/ping. It is a pretty standard issue: only apps running as root can send ICMP directly, as ping does. PHP runs in Apache, and to prevent security issues with privilege escalation setuid programs are forced to run as an unprivileged user. I would check to see how “fping” in Nagios solved this issue. Tom ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ver 4.2 won't allow save because it can't see 2.2T disk drive
- SDH Admin ad...@stardothosting.com wrote: I need to patch this until I can update the system, any pointers to where (if there is one) to get the patch for this, and installation instructions. What is the 2.2T disk formatted as? Can you give more details on your hardware (storage device and the 4.2 server), as well as posting your dmesg output. In this case, it is pretty clear the the 2.2TB disk is mounted on NFS. And the OP said it was a StorageVault, so that means it is a WAFL filesystem, which is meaningless here. Is it really FreeBSD 4.2? Anyways, it doesn't really matter what df reports. If df is folding some of the 64bit values in negative numbers, it is no issue really. But if the StorageVault is returning errors when files are created or written to, then that is probably a configuration issue. NFS is a client-server filesystem. So df on NFS just queries the StorageVault for the info, and displays it. The NFS client doesn't shutdown, because the filesystem appear to be full, or have negative capacity. Tom ___ 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: lagg(4) and failover
- Brian A. Seklecki [EMAIL PROTECTED] wrote: On Sun, 2008-12-07 at 08:03 +1100, Peter Jeremy wrote: On 2008-Dec-05 07:34:21 -0500, Brian A. Seklecki [EMAIL PROTECTED] wrote: Well ... name a price for the development; HA L1/L2 is a feature the community would gladly sponsor the development of. net/ifstated covers at least some of this. I was thinking something like a heartbeat protocol could work well w/o LACP hacking on mid-range switches. I think that's how Dell does it with the RHEL crap for Broadcom. Send multicast packets on both an active/standby link. If either node discontinues to see the others packets, some admin-configurable logic promotes (Metric/Bias/Weighting). I don't know if that is such a great idea, as that would only test the switch that you are connected to. The Linux bonding driver supports probing the default gateway. Now, it uses ARP for this (probably because the ARP who-has code is also in the kernel and easily accessible), which also not so great, as a ARP who-has is a broadcast. So if you have lots of servers on the LAN using the bonding driver, you get a lot of broadcast traffic. ICMP echo-request would be a better approach, but my take on this, is that the echo-request/reply handling code would have to be written, so this hasn't been done yet. But ultimately, gateway probing is the best, as not only does it verify the directly connected switch, but also that you can get from that switch to the outside world. lagg is ultimately a problem as a high-availability solution since most switches do not support multi-switch 802.3ad yet, and most probably never well. So you are limited to a single switch. So 802.3ad is good only for aggregation, and not for high availability. So an active-standby system with probing is the way to go for high-availability. It seems that FreeBSD has most of the components of this already. ng_one2many was a possible base for this. ~BAS -- Brian A. Seklecki [EMAIL PROTECTED] Collaborative Fusion, Inc. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAUSE support for Ethernet interfaces ?
- Kurt Jaeger [EMAIL PROTECTED] wrote: Hi! I'm researching the topic of PAUSE counters (receiving side) for FreeBSD systems. That's a sort of flow control with ethernet, see e.g.: http://www.techfest.com/networking/lan/ethernet3.htm#3.2.1 Cisco switches seem to receive and count them, which helps to find short-term (seconds) overloaded links. Can FreeBSD 6.x or 7.x handle PAUSE frames, at least receiving them ? FreeBSD does not send PAUSE frames, but most of the NICs out there will process received PAUSE frames. However ethernet flow control is mainly useful on the switches anyways. Switches these day (*) have small buffers (sometimes just a shared 3MB buffer for 24 ports). If several ports send too much to a single port at the same time, the switch could run out of buffer space in milliseconds and start dropping frames, so the switch will use flow control to get the transmitting ports to slow down, and let the buffer drain. Slowing down the senders with ethernet flow control results in better performance than letting some frames drop, and force a timeout and retransmit. Of course, deeper buffers would be even better. Servers have large buffers, and mostly use TCP, which also implements flow control. So not much of a problem usually. I don't know if you could tell much by counting PAUSE frames though. You won't know the destination port that was congested, just the port(s) that were generating the traffic, that the switch told to slow down. Tom (*) I remember when some 10/100 switches had 1MB of buffer space per port. They don't make them anymore. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dual Core Xeon / i386 install w/ more than 4gb of RAM
- Alfred Perlstein [EMAIL PROTECTED] wrote: Does anyone have any alternative solutions that would provide a more reliable environment other than PAE? Besideds PAE some people have mentioned running an amd64 system. One thing to consider is that PAE in 6-stable (6.3 and beyond) is considered very stable, so if you can't make the jump to amd64 system because you'd have to recompile too much, you might have luck updating sources to 6-stable and trying that kernel, then installing 6.3 userland. Is PAE really that stable? I thought it was fairly unpolished, mainly because PAE is seen as a weak kludge implemented by Intel because they all thought we would all be using Itanium's by now. Intel reversed their folly pretty quickly, adopted the x86-64 extensions as-is from AMD, and pushed them onto every piece of silicon they make. I also really don't know how anyone would properly use 16GB of RAM under PAE anyways? Each process is going to limited to just under 4GB. The kernel memory space can't be bigger than 4GB either, so forget about a huge disk cache. And is there some really stability fear about FreeBSD on x86-64? Seems just the same as i386. good luck, -Alfred Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41
- Primeroz lists [EMAIL PROTECTED] wrote: Hi all, we are experiencing repeated crash on a Dell PowerEdge 2950 (rev 1 or 2). FBSD release is 6.2-RELEASE-p5 , AMD64. 2xXeon QuadCore and 8G of Ram. MySQL Version is 5.0.41 with following configuration settings: set-variable= key_buffer=768M set-variable= table_cache=800 set-variable= sort_buffer=24M set-variable= myisam_sort_buffer_size=256M set-variable= record_buffer=16M set-variable= max_allowed_packet=10M set-variable= thread_stack=128K set-variable= join_buffer=512M set-variable= max_heap_table_size=256M set-variable= max_connections=300 set-variable= tmp_table_size=384M set-variable= query_cache_size=402653184 set-variable= query_cache_limit=134217728 set-variable= read_rnd_buffer_size=10M set-variable= ft_min_word_len=1 pid-file= /var/db/mysqld.pid tmpdir = /var/tmp ft_stopword_file = '' set-variable= thread_cache_size=80 set-variable= myisam_stats_method=nulls_equal Also, myslq is not really well tuned. The query cache is a kludge. It is helpful, if you have stupid application that issues the same query over and over again, even though the database has not changed. If you don't have this problem, it just adds overhead. And quite a lot, if it is big. Generally, the query cache should be 20 to 100M at most, if not disabled. If you have a smart web application (anything using memcached), the query cache should just be turned off. It will actually be faster. You should give us much storage as possible to the database engine, for it cache actual data, not query results. It is weird that you are apparently are heavily using Innodb, but you have just set various myiasam values? Here is something useful: http://www.joyeur.com/2007/09/25/quick-wins-with-mysql Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: zfs problems
- Alexandre Biancalana [EMAIL PROTECTED] wrote: On 1/29/08, ZsUM ZsUM [EMAIL PROTECTED] wrote: *Dump header from device /dev/ad4s1b Architecture: amd64 Architecture Version: 2 Dump Length: 253394944B (241 MB) Blocksize: 512 Dumptime: Sun Jan 20 23:51:58 2008 Hostname: Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-RC1 #0: Mon Dec 24 10:10:07 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Panic String: solaris assert: sm-sm_space == space (0x1686d4800 == 0x1686d3800), file: /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 357 Dump Parity: 4000765979 Bounds: 0 Dump Status: good * The minidump is avaible if it nececery. If anybody know the solution, or can give me any advice how to fix it, than please sent me by e-mail. Restore your data from backup, you lost the filesystem. ___ Maybe, maybe not. I know that one of the ZFS releases had a bug in the free space map. This would also cause panics on OpenSolaris. This problem is apparently recoverable. The above panic references a Solaris panic in sm_space, which could be the space map. See this: http://www.joyeur.com/2008/01/22/bingodisk-and-strongspace-what-happened I'm not clear about which version of ZFS code is in FreeBSD, and whether the free space map bug is present there or not. Does anyone know which ZFS is in FreeBSD? Anyways, if you really need the data, it might be possible to boot the newest version of OpenSolaris, and let it repair your filesystem. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: zfs problems
- Hugo Silva [EMAIL PROTECTED] wrote: I'm not clear about which version of ZFS code is in FreeBSD, and whether the free space map bug is present there or not. Does anyone know which ZFS is in FreeBSD? Anyways, if you really need the data, it might be possible to boot the newest version of OpenSolaris, and let it repair your filesystem. Tom ___ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6 That doesn't really help, as that is the filesystem version, not the version of the OpenSolaris code, used in FreeBSD. The most recent OpenSolaris has patched the free space map bug. It is possible that FreeBSD does not have this yet. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -net or kernel: where does this belong?
- Per olof Ljungmark [EMAIL PROTECTED] wrote:
Posted on -questions but got no response, trying -current and -stable
as
well. Sorry for the cross-post but I'm getting kind of desperate...
...
Since quite a while I have had problems with {CURRENT|RELENG_7} SMP
machines that lock up when accessed from a remote location over a vpn
(ipsec) link and sees a ICMP_REDIRECT.
...
Unfortunately, the How To Repeat description is rather ... thin.
How do you have IPSec configured? Are you accessing the server remotely via
ssh within the VPN tunnel, or any remote access?
Tom
___
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.0-BETA2 Available
- Ladislav Bodnar [EMAIL PROTECTED] wrote: On Sunday 04 November 2007, Ken Smith wrote: The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA2 will be provided via the freebsd-stable list when available. These release announcements seem to be shorter and shorter with every release. Is there a changelog to see what has changed since BETA1? If so, would you please consider linking to it in future announcements? Thanks a lot :-) I recommend reading the FreeBSD quarterly reports. They have a better overview of what is going on each version. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Closed Port, Need to Reopen
- Squirrel [EMAIL PROTECTED] wrote: For some reason, my port 1645 is closed on FreeBSD 6.2. I have all the firewall disabled, but it's not allowing me access the port 1645. How do you manually open this port? I can't seem to find at google. You also need to have something listening on that port for it to be open. 1645 is (old) RADIUS, which operates over UDP, which means you can't test with telnet either. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2vmcores with identical backtraces - any idea ?
I believe that d6832000 is a physical memory address, so then this likely
indicates you have bad RAM.
Are you using ECC memory? Probably not, s you should probably boot a
memtest86 image, and run it overnight. Maybe longer, as the failures happen
days apart.
- Daniel Dvořák [EMAIL PROTECTED] wrote:
Hi all,
do you have any idea what is happen to my pc ?
Bye
Dan
# kgdb kernel.debug /var/crash/vmcore.15
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so:
Unde
fined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
panic: vm_fault: fault on nofault entry, addr: d6832000
Uptime: 5d5h46m4s
Physical memory: 503 MB
Dumping 152 MB: 137 121 105 89 73 57 41 25 9
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc057a2e3 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#2 0xc057a596 in panic (
fmt=0xc07f17f7 vm_fault: fault on nofault entry, addr: %lx)
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc0716d09 in vm_fault (map=0xc104b000, vaddr=3598917632,
fault_type=1 '\001', fault_flags=0) at
/usr/src/sys/vm/vm_fault.c:279
#4 0xc078f11c in trap_pfault (frame=0xd4488bf8, usermode=0,
eva=3598917632)
at /usr/src/sys/i386/i386/trap.c:734
#5 0xc078edc1 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1016695512, tf_esi
=
-696049
666, tf_ebp = -733442940, tf_isp = -733443036, tf_ebx = -969673472,
tf_edx =
0,
tf_ecx = 182, tf_eax = -320645846, tf_trapno = 12, tf_err = 0, tf_eip
=
-1065823
138, tf_cs = 32, tf_eflags = 66070, tf_esp = 52482, tf_ss = 2048})
at /usr/src/sys/i386/i386/trap.c:435
#6 0xc077cb0a in calltrap () at
/usr/src/sys/i386/i386/exception.s:139
#7 0xc078d45e in generic_bcopy () at
/usr/src/sys/i386/i386/support.s:489
Previous frame inner to this frame (corrupt stack?)
(kgdb) quit
# kgdb kernel.debug /var/crash/vmcore.16
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so:
Unde
fined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
panic: vm_fault: fault on nofault entry, addr: d6832000
Uptime: 14h11m10s
Physical memory: 503 MB
Dumping 82 MB: 67 51 35 19 3
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc057a2e3 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#2 0xc057a596 in panic (
fmt=0xc07f17f7 vm_fault: fault on nofault entry, addr: %lx)
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc0716d09 in vm_fault (map=0xc104b000, vaddr=3598917632,
fault_type=1 '\001', fault_flags=0) at
/usr/src/sys/vm/vm_fault.c:279
#4 0xc078f11c in trap_pfault (frame=0xd4488bf8, usermode=0,
eva=3598917632)
at /usr/src/sys/i386/i386/trap.c:734
#5 0xc078edc1 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1017089892, tf_esi
=
-696049
666, tf_ebp = -733442940, tf_isp = -733443036, tf_ebx = -1017265664,
tf_edx =
0,
tf_ecx = 473, tf_eax = -321040226, tf_trapno = 12, tf_err = 0, tf_eip
=
-106582
3138, tf_cs = 32, tf_eflags = 590358, tf_esp = 26617, tf_ss = 2048})
at /usr/src/sys/i386/i386/trap.c:435
#6 0xc077cb0a in calltrap () at
/usr/src/sys/i386/i386/exception.s:139
#7 0xc078d45e in generic_bcopy () at
Re: A little story of failed raid5 (3ware 8000 series)
- Artem Kuchin [EMAIL PROTECTED] wrote: ... But i don't understand how and why it happened. ONly 6 hours ago (a night before) all those files were backed up fine w/o any read error. And now, right after replacing the driver and starting rebuild it said that there are bad sectors all over those file. How come? What happened to you was an extremely common occurrence. You had a disk develop a media failure sometime ago, but the controller never detected it, because that particular bad area was not read. Your backups worked because they never touched this portion of the disk (ex. empty space, meta data, etc). And then another drive developed a electronics failure, which is instantly detected, putting the array into a degraded mode. When you did a rebuild onto a replace drive, the controller discovered that there was a second failed disk, and this is unrecoverable. RAID, of any level, isn't magic. It is important to understand how it works, an realize that drives can passive fail. BTW, if you were using RAID1 or RAID10, you would likely have had the same problem (well, RAID10 can survive _some_ double-disk failures). RAID6 is the only RAID level that can survive failure of any two disks. The real solution is RAID scrubbing: a low level background process that reads every sector of every disk. All of the real RAID systems do this (usually scheduled weekly, or every other week). Most 3ware RAID card don't have this feature. So rather than not using RAID5 or RAID6 again, you should just not use 3ware anymore. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A little story of failed raid5 (3ware 8000 series)
- Martin Nilsson [EMAIL PROTECTED] wrote: That is what patrol read is intended to detect before it is a problem. In a RAID5 array the checksums are only used when reconstructing data, if you have a bad block in a checksum sector it will not be detected until a drive have failed and you try to rebuild the array, unfortunately at that time it is too late... Beware that OS software solutions like diskcheckd will not find this as it only reads the data, not the checksums, it must be done on the controller. This isn't really accurate. First of all, if the RAID controller isn't confirming checksums before giving the data to the OS, what is the checksum for exactly? It is supposed to be for detecting data corruption, so if the card isn't using the checksum, its kinda of useless. I know some RAID systems do fake their checksums, as they don't actually validate data against the checksums during normal reads because they don't have the processing power. I'd stay away from these type of systems (cough ... Blue Arc ... cough). Second, most RAID systems don't use their own checksums anymore. Netapp is quite famous for their ZCS (zone checksum) drives, and still uses a variation of this technology on their newer systems (which are using 512 sectors). But most RAID vendors just rely on the drives own error detection and correction systems (hamming code based usually, which is actually pretty solid). I'm pretty sure that that 3ware doesn't use any checksums. However, in this particular case, validating checksums would have been unhelpful, since the disk was unreadable. diskcheckd would have detected this issue. It would probably have prevented the problem, if it had been running previously. ZFS is also a good option. It has file level checksumming. ZFS never trusts the disks, and is super paranoid. And ZFS can do background scrubbing too. I can't wait for ZFS in FreeBSD 7, because ZFS in software is going to 10 x better than anything 3ware has. Regards, Martin Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A little story of failed raid5 (3ware 8000 series)
- David Schwartz [EMAIL PROTECTED] wrote: It is supposed to be for detecting data corruption, so if the card isn't using the checksum, its kinda of useless. You are confused. Checking for data corruption is done, by checking if the *DATA* is corrupt. This does not require looking at the RAID5 checksum since the data has its own data checksum. No, not really. You are just referring to parity as checksums. They are different. Many RAID systems have checksums in addition to parity. For example, Netapp ZCS disks. ... However, in this particular case, validating checksums would have been unhelpful, since the disk was unreadable. diskcheckd would have detected this issue. It would probably have prevented the problem, if it had been running previously. No, it would have saved him. The problem was he lost a drive, and checksums *ON* *OTHER* *DRIVES* were unreadable. Quite possibly they had been unreabable for months, but were never checked, since they are only *needed* to reconstruct the data. Which is what I said? The data on the other disks is unreadable. It doesn't really matter what parity or data was on those sectors. Yes, diskcheckd would only read data sectors. ZFS is also a good option. It has file level checksumming. ZFS never trusts the disks, and is super paranoid. And ZFS can do background scrubbing too. I can't wait for ZFS in FreeBSD 7, because ZFS in software is going to 10 x better than anything 3ware has. That wouuld not have helped him one bit. When the drive failed, the RAID 5 checksums on the other drives still would not have been scrubbed. The RAID 5 checksum (technically an XOR) is only needed to recover the RAID 5 array if a drive (or sector) fails. Ok, you should probably not refer to RAID5 parity as checksums. They are different. Some RAID systems have both. And some do not. ZFS checksums the file level data, which is independent from any RAID5 parity. And yes a media scan would have helped. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: large RAID volume partition strategy
- Clayton Milos [EMAIL PROTECTED] wrote: If you goal is speed and obviously as little possibility of a fail (RAID6+spare) then RAID6 is the wrong way to go... RAID6's read speeds are great but the write speeds are not. If you want awesome performance and reliability the real way to go is RAID10 (or more correctly RAID 0+1). RAID6 has better reliability than RAID10, because in RAID6, you can survive the failure of _any_ two disks. In RAID10, double disks failures are only survivable if specific disks fail (alternates). In RAID10 sets this is a problem. So: * Reliability and space: RAID6 * Performance: RAID10 And the performance issues on RAID5/6 on writing is directly proportional to the quality of your controller. Good controllers can do partial stripe updates, and other optimizations to avoid having to read data back before writing anything. A simple minded RAID controller which has to read the entire strip back, writes are 1/3 slower than reads. Any good controller should be about 75% of read the speed. And RAID5+0 and RAID6+1 are also good options. And make sure your controller can do RAID scrubbing. The chances of a fatal failure on an array can be greatly minimized with RAID scrubing. None of the cheap controllers can do this. ZFS can do it though. ZFS software RAID is almost always better than a cheaper hardware RAID, though maybe not fully mature in FreeBSD 7. RAID6 also minimizes the risk of double disk failures. Big huge disks are almost always the wrong choice for databases though. You will never be able to fill the disk up before you hit the IOPS limit per each spindle. A 15K SAS disk has at least twice the IOPS of a 7K SATA disk. And while adding another bank to your RAID0 array doubles your IOPS in theory, it isn't exactly a linear increase. You need the IOPS, it is better to start with faster disks. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HOW TO: Enabling root on a new server?
- Michael Williams [EMAIL PROTECTED] wrote: No, I don't necessarily need Plesk; although we will be selling hosting. It simply came with the default configuration for the server. My plan is to manage most everything from the Unix shell. I just figured I might find a morsel inside Plesk somewhere for enabling root access. FYI, logging in as admin didn't work. Any other suggestions? You are probably better off just asking the hosting company for the password. You need the root password, and you need to have an account that is a member of the wheel group (use groups when you ssh to see if your account is ok). They might have flagged you as a newbie, and think you are better off inside the padded confines of Plesk. I work at a hosting company, and a whole bunch of our dedicated server customers are in over their heads with their servers as it is. Given that you asked for Plesk, and are now asking for root, they are probably has made them worried that the next call from you will be that you deleted /etc, and your server won't boot anymore. If you are planning to do any admin via ssh with root, you will not want Plesk. Plesk manages all of your software installs. Plesk includes Plesk specific versions of Apache, PHP, and MySQL. All patches and updates can only come from SWSoft, or the Plesk universe will crash. And Plesk ties you to a specific FreeBSD version too. Plesk versions lag big time for FreeBSD. But on the other hand, it is big GUI thing, and people like it. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mysql frequently crash on 6.2
- Albert Wong [EMAIL PROTECTED] wrote: key_buffer = 32M key_buffer has the most influence over the performance of MyISAM database. You should increase it as much as possible. On a dedicated 2GB server, 1GB is good. But it only helps, if you actually have indexes. There is no point is increasing it bigger than the size of your indexes (*.MYI files). But if you can hold all of the indexes in RAM, everything gets really, really fast. BTW, I agree with the other comments about the MySQL query cache. It is more of a work around for two problems: * A poorly indexed database, so that queries that return small results don't use an index, so caching the results is required. * Dumb applications that send the same query over and over again, even though the database has not changed. Some e-mail servers do this. A query cache should be small (5MB or less), if you use it at all. And you should never cache large results (there is an option that sets the size threshold). But I use MySQL 5.0 on several FreeBSD 6 systems, and they are moderately busy (250 q/s 450 q/s), and it works ok. MyISAM is the problem, and I need to switch to InnoDB. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD DNS Resolver Issues?
- Mark Andrews [EMAIL PROTECTED] wrote: It's a broken load balancer which is returning the parent's SOA record for queries for mail.wtplaw.com. Named correctly rejects this as a garbage response. It also appears to only responds to A/ queries. As for Solaris' host it may/may not be making queries. Mark Does anyone know what load balancer product this is? Since it is using DNS, I assume is one of these global slb things that tries to do clever things with DNS (ie. 3 second TTL). There do seem to be a lot of half-baked products out there that appear to work, but don't really. But in case, it is not clear whether they set it up properly, or whether it is just broken. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xen Dom0, are we making progress?
- Nikolas Britton [EMAIL PROTECTED] wrote: What about implementing something like DragonFly BSD virtual kernels? Matthew Dillon talks about it in is bsdtalk interview: http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk098.mp3 It seems very similar to User Mode Linux, rather than a true VM environment. http://user-mode-linux.sourceforge.net/ Each DragonFlyBSD vkernel runs as a process. I don't know why this is even interesting, for anything but kernel developers. Improving BSD jails to the same level as Solaris Containers (Solaris Containers are Solaris Zones with resource control), would widely useful for many BSD users. In VM environment, like Xen, each VM has its own kernel and possibly different OS. Xen has managed to get a lot of people interested in their VM environment, so there are a lot of OSes that support the Xen architecture. And for those that don't there is early support for booting them by using virtual features in newer CPUs (ex. Windows). Microsoft has joined the Xen bandwagon, even though the core is all open source, as they are threatened in the enterprise space by the VMWare juggernaut, and their Virtual Server/Virtual PC product is so bland, no one cares. UML has been available for longer than Xen, but Xen already outperforms it. I don't see a lot of future in the virtual kernel concept. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interface re0
- Eilko Bos [EMAIL PROTECTED] wrote: ... I still see this message: re0: RealTek 8169SB/8110SB Single-chip Gigabit Ethernet port 0xb800-0xb8ff mem 0xf700-0xf7ff irq 11 at device 15.0 on pci0 re0: MII without any phy! device_attach: re0 attach returned 6 Does anybody have an idea how this can be fixed? This is my complete ... Well, MII, stands for media-independent-interface. Since there are many different types of ethernet media, the idea was to develop a standard hardware interface for the media chip (which is called the PHY). Then you can can connect any media chip to any controller chip, and you'd have a NIC. Apparently, your card claims to have use a MII, but when the driver probes the MII, it does not find a PHY. But your NIC might not actually use the MII, and might have the PHY function directly incorporated in the NIC (the Single-chip reference is a hint). I recommend you do a rebose boot (which will print the PCI id of the card), and attach it to a PR. Perhaps the re maintainer can hack the driver for a special exception for your NIC. But em cards (Intel Pro1000GT Desktop) cards are very cheap, and do work. Why buy RealTek? RealTek has been outputting overly simplistic hardware since the beginning. If there was a corner that could be cut when building a NIC, a RealTek engineer thought of it first. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Progress installing on IBM LS21 Blade machine
- Ivan Voras [EMAIL PROTECTED] wrote: First, things that don't work: * 64-bit kernels. With or without ACPI, on 6-stable or on 7-current, kernels in AMD64 mode don't finish booting, or in the best case boot but can't run SMP (they don't find additional CPUs, but mptable information is correct - see previous posts). There's even a sort-of regression in 7-current: while 6-stable without ACPI boots but finds only one CPU, 7-current kernel hangs with or without ACPI, either during USB bus' detection or just after parallel port detection (which is obviously not present on blades but still detected...). The one thing about IBM blades, is that the various controllers for all kinds of IO devices may exist, but are simply not wired. FreeBSD is quite picky (or stupid) about device probing. If it finds a device, it basically demands that it works. It would be great if drivers could simply bail, if the devices were there, but didn't work, rather than just hanging. You can disable the parallel port device from the boot prompt. The same goes for any other phantom hardware that FreeBSD can't grok. * One irritating umass device. It seems that there's an embedded umass (USB mass storage) device in the blade or blade center which is listed in device tree but doesn't respond to any probes, thus hanging the boot process for upto 15 minutes until all timeouts expire. First time this happened I almost gave up and pronounced it a lost cause, but it appears to be a harmless (if irritating) timeout issue. I've built a kernel without umass support, but that means I also lost the built-in CD/DVD drive in the chasis. The umass device might exist, sometimes. This might be part of the remote CD and floppy support. So when you use the remote console to map your local floppy or CD or ISO to the blade, the remote console software makes the device appear as a umass device to the blade. I bet if you used the remote console, and had it share your local floppy to the device, the FreeBSD install would pass. But a 15 minute timeout for a USB device to respond is insane. 10 seconds would be more realistic. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems installing JDK 1.5
- Juergen Nickelsen [EMAIL PROTECTED] wrote: ... But indeed I was ignorant of the diablo port. What is the relation between these two ports anyway? I do not really get the difference, in spite of http://www.freebsdfoundation.org/downloads/java.shtml. ... There are some license restrictions on distribution of jdk binaries. In order to be distributable, jdk binaries need to pass Sun's test suite (TCK). So the Diablo binary passes, and is distributation. The port, is just source, and does not require testing. A binary built from the port may or may not pass, depending on the current state of development. There can be regressions as things change in the OS, and linked in packages. The jdk has a fair number of dependencies, so it is pretty easy to blow-up a jdk build. Some of the developers on the FreeBSD java list have the TCK, and can tell if you if the port would pass the TCK. And you should really be asking about this on the FreeBSD java list, as they are constantly making changes to the port, and dependencies. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable on Blade server
- Marko Lerota [EMAIL PROTECTED] wrote: Martin [EMAIL PROTECTED] writes: We're 100% FreeBSD-only and i was looking to buy IBM blade servers: can anyone reccomend any of them? models? particular hw/firmware/misc If you use FreeBSD don't look upon IBM blades at all. I've installed few freebsd 5.4 on IBM HS20 blades. If you need console, the only way to get there is through java web interface that sucks, brakes and crashes constantly. Because the keyboard is not supported you have to use it. Everything else also sucked. We had two blade chassis with 28 blade servers and I have never been so frustrated like I was with them and IBM people that did not solve our problem. FreeBSD gets confused on IBM BladeCenter's and attaches to the PS/2 controller, while the actual keyboard is on USB. This is also a problem on many desktop systems, where users only have a USB keyboard. Anyways, FreeBSD is slowly growing a working keyboard mux, so FreeBSD will attach to all available keyboard controllers, and accept input for any attached keyboards. Linux and Windows have this ability already. In the mean time, it is possible to use device hints, and convince FreeBSD to attach the USB keyboard only. I quite like the IBM BladeCenter's. Way better than Dell blades for sure. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some days, it doesn't pay to upgrade ...
- Marc G. Fournier [EMAIL PROTECTED] wrote: Feb 27 04:32:49 mars uptimec: The server requested that we do a new login Feb 27 04:33:00 mars kernel: maxproc limit exceeded by uid 0, please see tuning(7) and login.conf(5). Feb 27 04:33:10 mars kernel: maxproc limit exceeded by uid 60, please see tuning(7) and login.conf(5). Stupid question: why isn't there some mechanism that prevents new processes from starting up, instead of locking up the whole server? I'm not asking for ... Isn't that what is happening? When maxproc is hit, new processes can't be created. It is harmless, except for the uid that exceeded its process limit. I think the hang is some side-effect. Either because init can't fork a process, therefore there is nothing to login to. Did you try ping the system from remote to really see whether it was a solid hang? Or did you just pound on the keyboard? Or it is just a deadlock. That would be a bug. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: php apache2 config
- Matthew Herzog [EMAIL PROTECTED] wrote: When I load a file named php4.info I can see all my php build information. If I change that same file's name to phpinfo.php, I get a premature end of script headers error. The file contains this text only: ?php phpinfo(); ? and is owned by apache. This posting does not seem FreeBSD related, or even contain a question. I guess you want to fix your PHP install. It appears that your configuration is incorrect. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror disks vs partitions
- Vulpes Velox [EMAIL PROTECTED] wrote: On Thu, 18 Jan 2007 10:15:56 +0900 Adrian Chadd [EMAIL PROTECTED] wrote: On 17/01/07, Andrew Pantyukhin [EMAIL PROTECTED] wrote: [...after reading the slashdotter's piece of wisdom...] Yes, but that's the kind of functionality I have always expected to be present in software raid solutions. I hope I'll live to see this implemented in geom. That made my eyes bleed. Bring on ZFS and its method of managing JBODs. I second that. I have been way less than impressed with software raid and LVM on linux. ... But LVM by itself is a good volume manager. The block level snapshot ability is especially good. LVM can actually notify dependent filesystems so that they flush all data, when the block level snapshot is created. ext3 does not support filesystem based snapshots (like ufs2 does), but LVM snapshots are better than most filesystem snapshots. ZFS is clearly better than LVM+ext3, and is really the only option for really big filesystems right now. ufs2 doesn't support journaling, and background fsck isn't a complete replacement for journalling. ext3 is stable but doesn't really scale well, or have leading performance, and doesn't really work on FreeBSD anyways. XFS is virtually unsupported, as SGI laid off all their filesystem developers when they went into chapter 11, and ReiserFS, besides having some dodgy reliability issues, the head of development is currently in jail for suspicion of murder. So besides, being the best, ZFS is nearly the only choice for really big filesystems. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failover-HA-Setup
- Mark Saad [EMAIL PROTECTED] wrote: Ivan Voras wrote: Dmitriy Kirhlarov wrote: On Wed, Jan 17, 2007 at 03:20:32PM +0100, Richard Verwayen wrote: Oh, should I have mentioned that it is a shared SCSI-Storage in between? You can use gmirror(8) with ggated(8). I think his problem is that you can't have two machines RW mounting the same device (doesn't matter if it's FC, ggate or other...). So when one machine fails, the other must mount the file system and THEN start daemons... This is kind of a side topic but does anyone know of a on disk clustered file system for FreeBSD; like OCFS2 or GFS . Both which would allow you to have more then one box attached read / write to the same scsi or fc storage array ? I don't believe there are any. Additionally, I don't believe any of the clustered file systems would be usable for a database backend. Because the application does not know that another instance is also updating, so you would have to start only one instance at a time. So the locking overhead of a clustered filesystem isn't worth it for databases. -- Mark Saad [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: panic: bus_dmamap_load_mbuf_sg still there
I have a Soekris board, so I'm interested. What's the PR number for the bug? How frequently does it occur? It is good to log all of the details to the PR. - Andrea Campi [EMAIL PROTECTED] wrote: Hi, this panic has been reported a few times in the past, both by me and other people; I just updated my Soekris box to 6.2-RC2 and it's still happening. panic: bus_dmamap_load_mbuf_sg: no mbuf packet header! KDB: stack backtrace: panic(c06128c3,c060f93c,c055b9af,c0db804e,c0db803e,...) at panic+0xef bus_dmamap_load_mbuf_sg(c0d18e00,0,c0db8000,c0d627d8,c0d627b8,1) at bus_dmamap_load_mbuf_sg+0x4ec ath_start(c0d55000,35000,36,0,c100,...) at ath_start+0x26f ether_output_frame(c0d55000,c0fee600,c106,0,1,...) at ether_output_frame+0x226 ether_output(c0d55000,c0fee600,c56f6bb0,c0feb840) at ether_output+0x2de ip_output(c0fee600,0,c56f6bac,1,0,0) at ip_output+0xaad ip_forward(c0cf9648,c56f6c78,c04e14dd,c066ca40,1,...) at ip_forward+0x120 ip_input(c0fee600,18,c0673378,c56f6cec,c0541fd7,...) at ip_input+0x8d5 netisr_processqueue(c0d12240,c0cef400,0,c56f6d0c,c04bd93b,...) at netisr_processqueue+0x13 swi_net(0,c0cef438,c0cfaa80,c04bd740,c0cf9648,...) at swi_net+0x97 ithread_loop(c0ce8750,c56f6d38,c0ce8750,c04bd740,0,...) at ithread_loop+0x1fb fork_exit(c04bd740,c0ce8750,c56f6d38) at fork_exit+0x83 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc56f6d6c, ebp = 0 --- KDB: enter: panic [thread pid 13 tid 13 ] Stopped at kdb_enter+0x2c: leal0(%esi),%esi It has been suggested that it may be pf-related, but I don't have a clue on how to go about digging more info out. Any idea? Bye, Andrea -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ 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: Possibility for FreeBSD 4.11 Extended Support
But kernel panic issues are being fixed right up to the last minute in the 6.2 release train (these and em and socket change issues are probably what has delayed the final 6.2). There is a lot of work getting done, but clearly a lot of work to do. I wonder if this is an area where the Foundation can do something. FreeBSD needs someone to troubleshoot all of the panics and LOR issues. Bug hunting is no fun (for most), and no one is going to do it. Actually, I raised hell when the decision was made to release 6.1 when it was KNOWN that there were bugs. ISTR that the response was we gotta ship and can't be bothered to hold up the schedule to fix bugs. I admit that at that point I pretty much gave up. ... First of all, knowing their are bugs, and finding bugs are not the same. Just because you know you can cause a panic under some circumstance, does not translate into a fix. It might take 2 to 3 weeks of work to find the cause of that panic. But this is the problem, everyone just bails out when they see a bug. As I stated, almost no one is really looking for bugs. There are lists of bugs all over the place. But where are the back traces? Where is the analysis? But instead, more postings to the mailing list. Unless more people start trying to re-create these panics, and post usable data to the lists. It is not insane that releases are being made (like 6.1) with some known panic conditions. It is insane that this situation just generates more content-free e-mails to the mailing lists. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824, MOKB-03-11-2006, CVE-2006-5679
- O. Hartmann [EMAIL PROTECTED] wrote: Is for these UFS bugs in FreeBSD since 6.1 a fix uderway? See: http://projects.info-pull.com/mokb/ MOKB-08-11-2006,CVE-2006-5824, MOKB-03-11-2006,CVE-2006-5679 Probably not. In both cases a crafted filesystem is mounted to trigger crash. Garbage in, garbage out. It is hardly exploitable, since only root can mount filesystems. And only root could craft a bogus filesystem to crash the kernel. If you are root, reboot is a far faster way to crash the system. What the MOKB people seem to leave out, is: do their crafted filesystems pass a fsck -f? If fsck says the filesystem is good, then the kernel should not crash. But I suspect that fsck -f would fix the filesystem. (BTW, -f is mandatory as I suspect that these crafted filesystems would have the clean flag set). If fsck -f fixes the filesystem, then both of these bugs are bogus. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824, MOKB-03-11-2006, CVE-2006-5679
- O. Hartmann [EMAIL PROTECTED] wrote: These two bugs are shown for FreeBSD only and I guess, Solaris and other BSDs still use UFS. Are they more robust against this exploit or type of exploit? On the other hand, if these shown bugs aren't as serious as claimed be the mentioned page, it sounds more like 'look, we also found on FreeBSD something strange, not even on Linux'. But it is good to know and be aware of. Regards, Oliver The two bugs shown are for FreeBSD, but the site (http://projects.info-pull.com/mokb/) lists at least three filesystem bugs for Linux too. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration of NVRAM drives mismatch for error on dell server
- Ajit Mittal [EMAIL PROTECTED] wrote: Actully one of the server has raid with 4 drives. We by mistake removed them from the server without labelling them Now when we boot then get the error Configuration of NVRam drives mismatch for HA-0(normal mismatch) What i think is that hard drives has some id given by raid controller and also saves thsi information in its bios(NVRAM).Which are mismatch bcoz of the hard drives are not at the right spot. Ajit So you know what the problem is, and you know what caused it. I guess you are asking for a solution? This isn't FreeBSD related. And don't you say what kind of RAID controller you are using. But likely there is a Load RAID config from disks option, or something like it. I would probably call Dell support and confirm, before risk trashing your data. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pls.which.way.to.go?
I would upgrade to 5.5 first. Then it's up to you, but waiting for 6.3 is probably not a bad idea, before going further up the hill to 6.x. Please don't top-post. And I disagree. He should go straight to 6.2. If he's going to go to the trouble of upgrading, he should go straight to the latest, most stable release, which is (or shortly will be) 6.2. I agree. On a new server, go straight to 6.2. The only reason to go to 5.5, is if you must to a make world upgrade on an existing server. You'd want to avoid upgrade pain, when possible. Additionally, 6.x is the only release getting any improvement. 6.2 seems to have particular issues with NICs right about now, as the timer code was changes and some of the drivers need some work. But it is not released yet either. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Installing FreeBSD 6.0 on IBM BladeCenter HS20 - IT WORKS!
Axel, Hi, I was reading your post in regards to installing FreeBSD on the BladeCenter that you made to freebsd-stable. I've also been trying installing FreeBSD on the BladeCenter. During my installs, it hangs during the SCSI disk probes (Waiting for SCSI disks to settle). That should only take 5 seconds, but it sits there for a long time. I have some questions: 1. Disabling acpi. What happens for you if acpi is not disabled? I never tried this, and I'm not sure if this fixes anything or not. What did it do for you? 2. Keyboard. Have you tried BETA4? I think the new kbdmux stuff will mean that the keyboard does not need to be disabled. 3. ispfw. I tried both with and without the firmware. I didn't make any difference. It would still hang. What kind of storage are you installing onto? I'm working with an IBM DS400 (aka T600). Tom Samplonius Uniserve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing FreeBSD 6.0 on IBM BladeCenter HS20 - IT WORKS!
On Tue, 28 Mar 2006, Guy Helmer wrote: Tom Samplonius wrote: Axel, Hi, I was reading your post in regards to installing FreeBSD on the BladeCenter that you made to freebsd-stable. I've also been trying installing FreeBSD on the BladeCenter. During my installs, it hangs during the SCSI disk probes (Waiting for SCSI disks to settle). That should only take 5 seconds, but it sits there for a long time. I have some questions: 1. Disabling acpi. What happens for you if acpi is not disabled? I never tried this, and I'm not sure if this fixes anything or not. What did it do for you? 2. Keyboard. Have you tried BETA4? I think the new kbdmux stuff will mean that the keyboard does not need to be disabled. 3. ispfw. I tried both with and without the firmware. I didn't make any difference. It would still hang. What kind of storage are you installing onto? I'm working with an IBM DS400 (aka T600). If these are the same blades as the Intel SBX82 blades, then the code that drains the keyboard interface at boot time will cause the system to hang if the ps/2 keyboard (atkbdc?) isn't disabled. Devon H. O'Dell just sent me a list of his PRs yesterday (via the freebsd-amd64 list) that resolve this problem and several others: IBM HS20 (dual Xeon) blades are basically the same as the Intel SBX82. I've implemented a fix for this utilizing ACPI reboots. Please apply kern/94939 and tell me if shutdown(8) with -r or reboot(8) works for you. My suspicion is that it will. That could be a problem, if the HS20 FreeBSD install receipe is to disable ACPI, since they won't have ACPI either. I'm going to retry an HS20 install soon, and see if disabling ACPI fixes the Waiting for SCSI disks to settle hang that I get right now. The problem that I'm getting has some similarites to the ips0 SCSI problem (discussed on freebsd-scsi) which appears like it could be interrupt storm caused by miss-routed and/or mis-initialized interrupts caused by a ACPI issue. In which case the isp and bge drivers on a HS20 could having the same problem. Also, you may be interested in kern/94822, as FreeBSD won't hang on start-up attaching atkbd(4). If you're working on Intel SBX82 blades, specifically, kern/94833 and bin/94815 may also be interesting to you. I don't have this problem actually. I guess if the atkbd is disabled, there is also no issue? Maybe these would be helpful for you, also. Guy -- Guy Helmer, Ph.D. Principal System Architect Palisade Systems, Inc. Tom Samplonius VP of Technology Uniserve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII first official patches - please test!
On Thu, 10 Feb 2005 14:41:10 +0100, Søren Schmidt [EMAIL PROTECTED] wrote: Freddie Cash wrote: New version that fixes known problems so far etc now available: Just curious if this includes support for new chipsets or not. Not a big deal if it doesn't, just curious. I've got a Toshiba laptop that, unfortunately, uses the ATI IGP/IXP chipset, which only gets detected as UDMA33 (which is fine for my uses, so I'm not complaining). If this is supported, I'd be more than willing to lose ATAPICAM support to use it. :) Its not (yet) as I dont have any such HW here yet. I would like to get involved in adding some support. I've looked over the Linux 2.4 patch to add support for the ATI RS300 chipset (I've added the link to the PR on this issue). Most of the patch is adding feature display stuff, and the key bits are pretty small. But where do the chipset specifiic interfaces in FreeBSD reside? Can you provide any advice? Also, do you want a ATI RS300 chipset based system? Would an ASUS Pundit-R barebones unit (just a case and mb) be sufficent? -- -Søren Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
SATA/UDMA100 support on ATI RS300 chipset?
I have an ASUS Pundit-R chassis with an integrated ATI RS300 based motherboard. The IDE controller is detected but only as a generic controller: atapci0: GENERIC ATA controller port 0xff00-0xff0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 20.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 acd0: CDROM ASUS CD-S500/A/V2.1H at ata0-slave UDMA33 ad2: 114473MB ST3120026AS/3.18 [232581/16/63] at ata1-master UDMA33 ... The above Seagate hard drive is connected to the SATA connection, but is probed as UDMA33. Performance is poor (about 15MB/s read). I've also tried a PATA Seagate drive connected to the PATA connector, which was also probed as UDMA33, and performance was much better (about 30MB/s read). Here is the pciconf output for the IDE controller: host# pciconf -vl ... [EMAIL PROTECTED]:20:1: class=0x01018a card=0x81081043 chip=0x43491002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc.' device = '??? ATA Controller' class= mass storage subclass = ATA ... I believe that this controller requires explicit support. Anyone know anything about IDE on the ATI RS300? The SMBus interface is also doesn't attach: [EMAIL PROTECTED]:20:0:class=0x0c0500 card=0x81081043 chip=0x43531002 rev=0x18 hdr=0x00 vendor = 'ATI Technologies Inc.' device = '??? SMBus Controller' class= serial bus subclass = SMBus I think SMBus is quite standardized, so this might be as easy an adding an id? [EMAIL PROTECTED]:12:1:class=0x050100 card=0x05101524 chip=0x05101524 rev=0x00 hdr=0x00 vendor = 'ENE Technology Inc' device = '??? PCI Memory Card Reader Controller' class= memory subclass = flash I thought that a PCI based memory card reader would be fairly standard, but I guess most people use USB based readers. This is a 4-in-1 reader/writer for MMC/SD/MemoryStick/xD. Anyone heard of these two controllers before? Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA/UDMA100 support on ATI RS300 chipset?
On Wed, 05 Jan 2005 15:33:48 -0700, secmgr [EMAIL PROTECTED] wrote: That would be ASUS who would have embedded the 3COM chip. probably special order, which is why it didn't report back something recognized. The ATI chipset is pretty new vs the more tried and known nVIDIA/SiS/VIA/AMD [South|North]bridges and the Intel hubs Running current can be exciting. Since you seem to have networking covered, you may want to look at a SATA pci card thats known to freebsd. In theory, the box has two slots. jim The 3com chip is not recognized, since it very new. It is mostly used in laptops. SATA drives attached to the ATI RS300 works fine in 5.3-RELEASE, except that FreeBSD detects the disk as UDMA33, and performance isn't good. PATA disks have better performance on the Pundit-R, even though they are also detected as UDMA33. In fact, I wonder if PATA disks are actually operating at UDMA66 or UDMA100, but FreeBSD doesn't know this, as it it is treating the ATI controller as a generic ATA controller. The reason why I suspect this, is that my PATA disk can do 30MB/s read, and I don't think it is possible to get 30MB/s through a UDMA33 connection, especially with the ATA/IDE overhead. The question I have is, can I trick FreeBSD by adding the device ids for the ATI chipset, at least for IDE? It appears that all of the nVIDIA/SiS/VIA/AMD [South|North]bridges are fairly similar as far as the drivers are concerned. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
