Re: SSH login takes very long time...sometimes
Hi, > On Sun, 26 Feb 2006 22:56:32 +0200 > Rostislav Krasny <[EMAIL PROTECTED]> said: rosti> Could you please suggest a good rosti> comprehensive article on the Web about IPv4-mapped IPv6 addresses and rosti> their usage? You can find some documents by googling with `IPv4-mapped IPv6 address'. In addition, you should read RFC 4038: http://www.ietf.org/rfc/rfc4038.txt?number=4038 rosti> By the way, why you don't do the address type test in a rosti> daemon mode of ftpd? Because, ftpd(8) in daemon mode doesn't accept an IPv4 using an IPv4-mapped IPv6 address by issuing the IPV6_V6ONLY socket option. Please refer socksetup(). In inetd mode, enable/disable use of an IPv4-mapped IPv6 address is depending on how to configure inetd.conf. So, we need to pay attention to an IPv4-mapped IPv6 address in inetd mode. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
On Sun, Feb 26, 2006 at 09:19:35PM +0100, Dimitry Andric wrote: > > comconsole_speed= in /boot/loader.conf > > existing speed, if comconsole is already set by previous stage > > BOOT_COMCONSOLE_SPEED compile time default > > Well, the last item will simply never be hit, since there is ALWAYS a > previous stage, isn't there? The second case only applies if the previous stage has set the console to the comconsole. If your /boot.config is empty, and loader.conf has console="comconsole", the compile-time BOOT_COMCONSOLE_SPEED applies. -ed ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libc bug with nsswitch?
Uwe Laverenz wrote: Hi, there seems to be a problem with RELENG_6 in environments where nss_ldap is used for user- and group-lookups. The problem affects different ports that don't have very much in common, so I guess there might be a bug in FreeBSD's libc, because that's the place, where the name-sevices are handled (correct me if I'm wrong). Two examples that are reproduceable here on various machines: 1. emulators/linux_base-8: When nss_ldap is enabled in /etc/nsswitch.conf, the installation of the port fails: [snip] ... var/tmp/rpm-tmp.41237: line 11: /dev/null: No such file or directory var/tmp/rpm-tmp.41237: line 12: /dev/null: No such file or directory Assertion failed: (cfg->ldc_uris[__session.ls_current_uri] != NULL), function do_init, file ldap-nss.c, line 1245. Abort trap (core dumped) *** Error code 134 2. PHP4(5)/PEAR This was also reported by two other users, both are using nss_ldap but have PHP5 instead of PHP4. With nss_ldap enabled, the use of at least two php-modules (imagick, xslt) lead to a segmentation fault in php4, e.g. when trying to install an additional pear-module: ... A third example: My home workstation uses KDE and is also a Samba BDC. With ldap-enabled nsswitch.conf, if I click on the "/home" folder in Konqeror I get a message box "The process for the file protocol died unexpectedly", also in the starting terminal I get Assertion failed: (cfg->ldc_uris[__session.ls_current_uri] != NULL), function do _init, file ldap-nss.c, line 1245. kioslave: ### CRASH ## protocol = file pid = 72414 signal = 6 Identical to the above, everything is find without ldap in nsswitch.conf. Currently I'm on 6.1-PRERELEASE #0: Wed Feb 22. Per olof ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SSH login takes very long time...sometimes
On Mon, 27 Feb 2006 02:49:15 +0900 Hajimu UMEMOTO <[EMAIL PROTECTED]> wrote: > Hi, > > > On Sun, 26 Feb 2006 17:40:19 +0200 > > Rostislav Krasny <[EMAIL PROTECTED]> said: > > rosti> It will require to specify a virtual host for each address or to use > rosti> hostname with multiple addresses only once. Specifying a virtual host > by > rosti> a hostname and registering multiple hostname's addresses in /etc/hosts > rosti> should not be confusing, IMHO. If the addresses are already registered > rosti> on DNS, the work is even simpler. > > rosti> Even specifying virtual hosts by addresses should not be confusing, > rosti> because IPv4-mapped IPv6 address and the IPv4-mapped itself are > rosti> certainly not the same, although they are mapped each to other. Indeed, > rosti> someone could want to specify different virtual ftp hosts for IPv4 and > rosti> mapped to it IPv6 addresses. For example to use different motd, welcome > rosti> or statfile files. > > Then, you are already confused. > > rosti> When a remote address is an IPv4-mapped IPv6 address, why the local > IPv6 > rosti> address must be of the same type and cannot be any regular IPv6 > address? > > Because, the connection uses an IPv4 to communicate with each other. > There is two representation for one IPv4 address; native IPv4 address > and an IPv4-mapped IPv6 address. It is thorny thing. You may be right and I'm confused. I don't have much experience with IPv6. I just thought that any unicast IPv6 host, even IPv4-mapped IPv6 host, can communicate with any other unicast IPv6 host, including non-IPv4-mapped IPv6 host. Could you please suggest a good comprehensive article on the Web about IPv4-mapped IPv6 addresses and their usage? By the way, why you don't do the address type test in a daemon mode of ftpd? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
Ed Maste wrote: > So I suspect that the following happens when you boot: > > - your BIOS sets the serial port to 9600 Yes. > - boot0 does nothing with the serial pot I'm using 'dangerously dedicated' disks, so it's only boot[12] that is used. > - boot1/2 reads the -P in /boot.config and detects no keyboard, and > then sets the serial port to 9600 and the console to comconsole Indeed, I never got the "/boot.config: -P" message on the serial console before. Now I get it, using updated boot blocks. > - the loader detects that the serial port is enabled and is already > set to 9600 > Thus, I'm not surprised that you get a 9600 baud console without > an rc.conf setting. The thing that concerns me is your report that > the console does not run at 115200 even if /boot/loader.conf > contains comconsole_speed="115200". This turns out to be an error on my part, sorry to have you worried. :) I'd accidentally put "console_speed=115200" in loader.conf. With "comconsole_speed=115200" and 9600 baud boot blocks, it works okay, although you don't see any of the boot[12] messages, of course. That's why installing 115200 baud boot blocks is still the better solution for me; my BIOS doesn't have any possibility to set the COM port speeds... signature.asc Description: OpenPGP digital signature
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
Ian Dowse wrote: > The problem may be that your boot blocks were compiled with > BOOT_COMCONSOLE_SPEED set to 9600. Try reinstalling them with e.g. > `disklabel -B ad0s1' (make sure you get the right device name - > it should be the slice that you boot from). Argh, shouldn't have done this without thinking on a dangerously dedicated disk. :) But after recovering the partition table with fdisk, the new boot blocks work as expected, thanks. > Previously both /boot/loader and the boot blocks would override the > serial port speed according to BOOT_COMCONSOLE_SPEED, but I believe > that since the recent change, loader will assume that if the boot > blocks requested a serial console, then they will have already set > up the correct speed. Yes, so people should be urged to upgrade their boot blocks, in case of a non-binary upgrade. (I assume that a binary upgrade WILL install fresh boot blocks?) signature.asc Description: OpenPGP digital signature
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
Ed Maste wrote: >> Okay, but why did 4.x through 5.x through 6.x (these have all been on >> this particular machine) always boot with 115200 until now? :) > Because now the loader has new behaviour of using the existing speed > if the previous stage indicates a serial port is in use, instead > of blindly jamming in a compile-time setting. Fine, but please be aware that this new behaviour violates POLA, at least without a stern notice in UPDATING. :) My idea about hard coded defaults has always been that they are followed, not ignored... > comconsole_speed= in /boot/loader.conf > existing speed, if comconsole is already set by previous stage > BOOT_COMCONSOLE_SPEED compile time default Well, the last item will simply never be hit, since there is ALWAYS a previous stage, isn't there? So then you might as well remove the compile time default. Or at least make clear that the compile time default only applies to boot[12], and not the loader. >> Anyway, I also thought that installworld would take care of installing >> any updated boot blocks, if necessary. I'll manually install them and >> see what I end up with. > > It doesn't seem that way. They'll be placed in /boot, but not > in the mbr or slice I think. Indeed, as Ian explained. FYI, I've just installed new boot blocks with a configured BOOT_COMCONSOLE_SPEED, commented out the console= and comconsole_speed= entries in loader.conf, and this works as expected now. However, please keep in mind that this might hit non-binary upgraders who use serial consoles, e.g. people with remote boxes in faraway places. They should be warned to either upgrade their bootblocks manually, or set the speed directives in loader.conf. signature.asc Description: OpenPGP digital signature
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
Ian Dowse wrote:
>> Okay, but why did 4.x through 5.x through 6.x (these have all been on
>> this particular machine) always boot with 115200 until now? :)
> They probably used 9600 for the boot blocks, and then switched to
> 115200 when /boot/loader started, so you didn't notice. Now the
> settings from the boot blocks get used by /boot/loader.
Ah, but this still means that /boot/loader used to use a hardcoded
default specified in /etc/make.conf, and now it doesn't honor that anymore.
There should at least be a notice in UPDATING, e.g. "don't forget to set
comconsole_speed in your loader.conf, or your serial console won't work
anymore after upgrading." It would probably save some people a drive to
the colocation facility... ;)
> Boot blocks need to be installed manually - installworld installs
> the boot blocks as files in /boot/boot{1,2}, but when booting, it
> is the boot blocks in the first 8k of the slice that are used, not
> the /boot/boot{1,2} files.
Okay. I still think it would be wiser to just reinstall them during
installworld, just to be sure there's no incompatibilities...
signature.asc
Description: OpenPGP digital signature
Re: gmirror/disk problems!
On 10 feb 2006, at 07.15, Johan Ström wrote: Hi list! I've been experiencing problems earlier with gmirror (thread "Page fault, GEOM problem??"). My gmirror crashed, and the box compleatly froze. Now I got a new mobo, and it has been working great since (no crashes, and i get decent 40-50mb/s read/write instead of ~10-20). This morning i woke up to this: ... I could try to move the disks to my promise sata2 tx4 card i bought for the old mobo (which didnt have sata)... But i'd rather find the problem ;) Hope someone can help. Thanks Johan And now it happened again.. Feb 26 00:13:27 elfi kernel: subdisk4: detached Feb 26 00:13:27 elfi kernel: ad4: detached Feb 26 00:13:27 elfi kernel: unknown: TIMEOUT - READ_DMA retrying (1 retry left) LBA=11660623 Feb 26 00:13:27 elfi kernel: unknown: timeout waiting to issue command Feb 26 00:13:27 elfi kernel: unknown: error issueing READ_DMA command Feb 26 00:13:27 elfi kernel: GEOM_MIRROR: Device gm0s1: provider ad4s1 disconnected. Feb 26 00:13:27 elfi kernel: GEOM_MIRROR: Request failed (error=5). ad4s1[READ(offset=5970206720, length=16384)] Feb 26 00:13:27 elfi kernel: GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=5974401024, length=131072)] Feb 26 00:13:27 elfi kernel: GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=5976973312, length=131072)] Feb 26 00:13:27 elfi kernel: GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=5977153536, length=131072)] Feb 26 00:13:27 elfi kernel: GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=5977333760, length=131072)] Feb 26 00:13:27 elfi kernel: GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=5977530368, length=131072)] Feb 26 00:13:27 elfi kernel: GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=5977710592, length=131072)] Feb 26 00:13:27 elfi kernel: GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=5977907200, length=131072)] Feb 26 00:13:27 elfi kernel: GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=5978087424, length=131072)] Feb 26 00:13:27 elfi kernel: GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=5978939392, length=114688)] And then on reboot Feb 26 20:17:53 elfi kernel: ad4: 286188MB at ata2-master SATA150 Feb 26 20:17:53 elfi kernel: ad6: 286188MB at ata3-master SATA150 Feb 26 20:17:53 elfi kernel: GEOM_MIRROR: Device gm0s1 created (id=4118114647). Feb 26 20:17:53 elfi kernel: GEOM_MIRROR: Device gm0s1: provider ad4s1 detected. Feb 26 20:17:53 elfi kernel: GEOM_MIRROR: Device gm0s1: provider ad6s1 detected. Feb 26 20:17:53 elfi kernel: Root mount waiting for: GMIRROR Feb 26 20:17:53 elfi kernel: GEOM_MIRROR: Device gm0s1: provider ad6s1 activated. Feb 26 20:17:53 elfi kernel: GEOM_MIRROR: Device gm0s1: provider mirror/gm0s1 launched. Feb 26 20:17:53 elfi kernel: GEOM_MIRROR: Device gm0s1: rebuilding provider ad4s1. Rebuilding currently This problem have occured many times now.. Does anyone know why this happens? Is there some bug somewhere that needs to be haunted down?? In geom? in ata driver? This needs to be solved.. Johan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dmesg seg faults
My video card spits out rather weird messages to the kernel message buffer. This is only an annoyance, except it causes dmesg to seg fault. I have some very simple possible fixes at http://www.freebsd.org/cgi/query-pr.cgi?pr=93841 It is nothing crucial but it would be nice if a fix was submitted soonish. Stephen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SSH login takes very long time...sometimes
Hi, > On Sun, 26 Feb 2006 17:40:19 +0200 > Rostislav Krasny <[EMAIL PROTECTED]> said: rosti> It will require to specify a virtual host for each address or to use rosti> hostname with multiple addresses only once. Specifying a virtual host by rosti> a hostname and registering multiple hostname's addresses in /etc/hosts rosti> should not be confusing, IMHO. If the addresses are already registered rosti> on DNS, the work is even simpler. rosti> Even specifying virtual hosts by addresses should not be confusing, rosti> because IPv4-mapped IPv6 address and the IPv4-mapped itself are rosti> certainly not the same, although they are mapped each to other. Indeed, rosti> someone could want to specify different virtual ftp hosts for IPv4 and rosti> mapped to it IPv6 addresses. For example to use different motd, welcome rosti> or statfile files. Then, you are already confused. rosti> When a remote address is an IPv4-mapped IPv6 address, why the local IPv6 rosti> address must be of the same type and cannot be any regular IPv6 address? Because, the connection uses an IPv4 to communicate with each other. There is two representation for one IPv4 address; native IPv4 address and an IPv4-mapped IPv6 address. It is thorny thing. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SSH login takes very long time...sometimes
On Sun, 26 Feb 2006 09:45:34 +0900 Hajimu UMEMOTO <[EMAIL PROTECTED]> wrote: > Hi, > > > On Sun, 26 Feb 2006 01:46:30 +0200 > > Rostislav Krasny <[EMAIL PROTECTED]> said: > > rosti.bsd> As far as I understand the code of selecthost() it walks through > linked > rosti.bsd> lists of known virtual hosts and their addresses and compares the > rosti.bsd> addresses to a local address of connected socket. This way it > tries to > rosti.bsd> find - configuration of what virtual host should be used. There is > an > rosti.bsd> additional comparison that seems like a workaround for > misconfigured > rosti.bsd> virtual host that can be resolved only to IPv4 address and should > be > rosti.bsd> used on IPv4-mapped IPv6 address. If virtual hosts are properly > rosti.bsd> configured that hack is not needed, IMHO. > > If you nuke this workaround from both selecthost() and my patch, you > need to specify a native IPv4 address and/or an IPv4-mapped IPv6 > address into ftphosts appropriately. It will confuse users. So, it > is requierd. It will require to specify a virtual host for each address or to use hostname with multiple addresses only once. Specifying a virtual host by a hostname and registering multiple hostname's addresses in /etc/hosts should not be confusing, IMHO. If the addresses are already registered on DNS, the work is even simpler. Even specifying virtual hosts by addresses should not be confusing, because IPv4-mapped IPv6 address and the IPv4-mapped itself are certainly not the same, although they are mapped each to other. Indeed, someone could want to specify different virtual ftp hosts for IPv4 and mapped to it IPv6 addresses. For example to use different motd, welcome or statfile files. > rosti.bsd> Anyway selecthost() is called with local socket name and it checks > a > rosti.bsd> local address, while his_addr.su_sin6.sin6_addr is a remote > address. > rosti.bsd> Local and remote hosts have same address families but not same > rosti.bsd> addresses. > > The his_addr is referred to determine just an address family, here. > When a remote address is an IPv4-mapped IPv6 address, a local address > is as well. So, it should be okay. When a remote address is an IPv4-mapped IPv6 address, why the local IPv6 address must be of the same type and cannot be any regular IPv6 address? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.1-PR - bsdtar fails with bogus modification dates
Problem: Bogus modification dates cause tar/bsdtar 1.02.023 failure, gnutar works The files were created from old Macintosh files using netatalk. One file has a bogus modification date of Nov 16, 1913, which appears to cause "bsdtar" to fail: newserv# tar cvf /tmp/test.tar hpLaserJet456Installer.gz hpLaserJet456Installer.sit.gz a hpLaserJet456Installer.gzarchive_write_pax_header: 'x' header failed?! This can't happen. Create a tar archive using gnutar (compiled from GNU tar 1.15 sources from ftp.gnu.org): newserv# gnutar cvf /tmp/test.tar hpLaserJet456Installer.gz hpLaserJet456Installer.sit.gz hpLaserJet456Installer.gz hpLaserJet456Installer.sit.gz "touch" the files and force the modification dates to 2/26/2006: newserv# tar cvf /tmp/test.tar hpL* a hpLaserJet456Installer.gz a hpLaserJet456Installer.sit.gz Mike Squires ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfilter + bge strangeness
Darren, On Sun, Feb 26, 2006 at 12:16:05PM +, Darren Reed wrote: D> > Root of the problem is inside ipfilter - if driver use 'partial' (i.e. without D> > pseudo header) rx checksum offloading ipfilter fails to calculate checksum D> > correctly (it's using ip packet length (ip_fil_freebsd.c:1561) instead of D> > tcp/udp length). D> > This patch enables 'full' rxcsum offloading so ipfilter's bug should not be D> > triggered. D> D> I think what you're saying is that this is wrong: D> sum = in_pseudo(ip->ip_src.s_addr, ip->ip_dst.s_addr, D> htonl(m->m_pkthdr.csum_data + D> fin->fin_ip->ip_len + fin->fin_p)); D> D> And that "fin->fin_ip->ip_len" needs to be replaced by something D> that is like "ip_len - ip_hl - tcp/icmp/udp_hl" ? D> D> Just so that I understand the interactions here properly, is there D> a way to tell when FreeBSD will use partial checksums like it was D> before compare to now ? If the m->m_pkthdr.csum_flags field doesn't have the CSUM_PSEUDO_HDR flag, then the m->m_pkthdr.csum_data field contains partial checksum. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfilter + bge strangeness
On Tue, Jan 31, 2006 at 12:09:13PM +0300, Oleg Bulyzhin wrote: > > > Btw, until recent changes bge had txcsum (not rxcsum) only. > > > > > > As i can see there is no problem with checksum's at all (at least inside > > > bge driver). tcpdump reports bad checksum on outgoing packets due to > > > nature of tx checksum offloading: packet will get it's checksum calculated > > > right before it goes on wire (If you want to check tx checksum offloading > > > you should look on incoming packets on other end of wire). > > > > > > Looks like something is wrong inside ipfilter. Can you test with ipfilter > > > turned off (ipf -D or, if you using module, kld_unload ipl.ko)? > > > > With ipfilter disabled and rxcsum enabled all is well (also, with > > ipfilter and rxcsum enabled but just two rules to allow anything > > in/out it works fine too). > > > > The tcpdump output looks the same (see below). > > > > It is not a purely ipfilter thing i guess, since on an em interface > > on another box with txcsum/rxcsum on, there is no problem. It is > > something in the combination of bge and ipfilter, although that is > > as far as my speculation goes right now.. > > Could you please test attached patch? > > Root of the problem is inside ipfilter - if driver use 'partial' (i.e. without > pseudo header) rx checksum offloading ipfilter fails to calculate checksum > correctly (it's using ip packet length (ip_fil_freebsd.c:1561) instead of > tcp/udp length). > This patch enables 'full' rxcsum offloading so ipfilter's bug should not be > triggered. I think what you're saying is that this is wrong: sum = in_pseudo(ip->ip_src.s_addr, ip->ip_dst.s_addr, htonl(m->m_pkthdr.csum_data + fin->fin_ip->ip_len + fin->fin_p)); And that "fin->fin_ip->ip_len" needs to be replaced by something that is like "ip_len - ip_hl - tcp/icmp/udp_hl" ? Just so that I understand the interactions here properly, is there a way to tell when FreeBSD will use partial checksums like it was before compare to now ? Darren Darren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Søren!!!, Promise FastTrak TX2300 semphore timeouts, 6.1-BETA2
On Sun, Feb 26, 2006 at 03:55:56AM -0600, Nikolas Britton wrote.. > Nevermind, I followed my own advice, everything's working perfect now. > > 1. Removed promise and highpoint cards. > 2. Connected the primary drive to the onboard SATA controllor. > 3. Installed BETA2. > 4. cvsup'd new src, checked if sos's patches were in there, it was. so > he missed BETA2. Yes he did, known fact. -- Wilko Bulte [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: Søren!!!, Promise FastTrak TX2300 semph ore timeouts, 6.1-BETA2
Nevermind, I followed my own advice, everything's working perfect now. 1. Removed promise and highpoint cards. 2. Connected the primary drive to the onboard SATA controllor. 3. Installed BETA2. 4. cvsup'd new src, checked if sos's patches were in there, it was. so he missed BETA2. 5. rebuilt kernel. 6. reinstalled highpoint card to check if highpoint's drivers where compatable with 6.1, yes. 7. Removed the highpoint card. 8. edited /etc/fstab to change ad4 to ar0 9. disabled onboard SATA. 10. Installed promise card and reconnected drives, setup RAID1 from BIOS. 11. highpoint drivers: echo 'hptmv6_load="YES"' >> /boot/loader.conf 12. reinstalled highpoint card. 13. installed highpoint raid managment software. 14. ran build/install world/kern. On 2/25/06, Nikolas Britton <[EMAIL PROTECTED]> wrote: > I'm getting "ad(x): req=0xc(foobar) setfeatures set transfer mode > semphore timeout !! Danger Will Robinson !! after I installed BETA2 on > my server (Intel SE7210TP-E). I get the messages a few minutes after > the systems booted up, and then it deadlocks. > > I had to go to great length just to get BETA2 installed... If I tried > to install FreeBSD on ar0 sysinstall would just hang... I had to set > the two drives up (Seagate 80GB SATA w/NCQ) in JOBD mode, install > FreeBSD on ad4, reboot, edit /etc/fstab to point to ar0, and then set > the RAID up in the BIOS. > > I had this server working just fine with the ata-mk3n patch set in > 5.4, though I did see this error once before when I ran: > "nice -20 make -j2 buildworld > /usr/data/buildworld.log&". /usr/data > points to da0e, the highpoint RAID5 array (8 300GB Maxtor maxline III > drives) > --- > The other ata/disk problems I noticed with BETA2 is that FreeBSD > probes and sets up my HighPoint RocketRAID 2220 as ata3, ata4, ata5, > ata6, ata7, ata8, ata9, and ata10... FreeBSD shouldn't even touch > it... as the card needs highpoints drivers for it to work correctly, > when the drivers are install it will show up as a da device. I haven't > had a chance to install the drivers yet, so I just removed the card. > When I ran setup in verbose mode FreeBSD seemed to mix the promise > card and this card together as one device... I wasn't paying close > attention though. > > I also tried using the onboard Adaptec HostRAID but it shows up in > FreeBSD as ata20 and ata22 when I have the highpoint card is > installed, wtf! :-) > > http://groups.google.com/group/muc.lists.freebsd.current/browse_thread/thread/efd503b8311aecea/ > I saw your thread from the current mailling list that you might have > already fixed this, but I'm not sure if you MFC'd it in time for > BETA2, maybe I will try and reinstall FreeBSD in JOBD mode again and > then cvsup all the new src and rebuild world? > - > I could really use some help, This server has to be back online by 9am > monday morning... If I can't get 6.x working I'll have to wait until > this time next year to try again and thats no fun. > > Thanks... I'm going to bed now. > > > -- > BSD Podcasts @ http://bsdtalk.blogspot.com/ > -- BSD Podcasts @ http://bsdtalk.blogspot.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usbd / moused oddity
On Sun, Feb 26, 2006 at 12:32:05AM +, Gary Palmer wrote: > Mathieu Prevot wrote: > > >Hello, > > > >I remarked something I don't understand. I have a usb mouse, and if I > >just have usbd_enable="YES" and moused_enable="NO" in rc.conf I can have a > >functionnal mouse after boot. If I go to single-user mode from multi-user > >mode and then back to multi-user mode with ^d, I don't have the process > >moused. > >In the last case, I need to set moused_enable="YES" and > >moused_port="/dev/ums0". > > > >I use FreeBSD 6.1-PRERELEASE #32: Tue Feb 21 02:30:25 CET 2006 amd64 > > > > > > (Assuming you have up-to-date devd.conf and usbd.conf): On first boot > the kernel pushes a list of devices the kernel found to devd, including > your mouse which isn't attached to moused yet. devd fires up moused for > your mouse and life is happy. > > You take the system single user, and everything is killed off (including > devd, and moused). When you take the system multi-user again, devd is > restarted but the kernel has already pushed the list of devices out and > will only push new devices to devd, so moused will not be automatically > restarted. Thanks for the explanation Mathieu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nss_ldap problem
I use nss_ldap-1.239 and nss_ldap-1.244 on 5.4 and 6.0
I have a problem -- login success only if {CRYPT} mechanism used in
ldap database. Other services, authenticated in ldap, work fine
(pam_ldap, apache auth for example).
My configs:
/etc/pam.d/system
# auth
authsufficient pam_opie.so no_warn no_fake_prompts
authrequisite pam_opieaccess.so no_warn allow_local
authsufficient /usr/local/lib/pam_ldap.so no_warn
try_first_pass
authrequiredpam_unix.so no_warn try_first_pass
nullok
# account
account requiredpam_login_access.so
account required/usr/local/lib/pam_ldap.so
ignore_authinfo_unavail ignore_unknown_user
account requiredpam_unix.so
# session
session required/usr/local/lib/pam_mkhomedir.so skel=/etc/skel
umask=0077
session requiredpam_lastlog.so no_fail
# password
passwordsufficient /usr/local/lib/pam_ldap.so use_authtok
passwordrequiredpam_unix.so no_warn try_first_pass
/etc/nsswitch.conf
group: ldap files
hosts: files dns
networks: files
passwd: ldap files
shells: files
imap: ldap
/usr/local/etc/ldap.conf
uri ldaps://fbsd
base ou=users,o=oil-space
ldap_version 3
scope one
pam_filter objectClass=posixAccount
pam_login_attribute uid
pam_password md5
nss_base_passwd ou=users,o=oil-space?one
nss_base_shadow ou=users,o=oil-space?one
nss_base_group ou=groups,o=oil-space?one
ssl on
tls_cacertfile /usr/local/etc/ssl/cacert.pem
uname -rs && ls -l /usr/local/etc/nss_ldap.conf && pkg_info -Ix nss_ldap -x
pam_ldap
FreeBSD 5.4-STABLE
lrwxr-xr-x 1 root wheel 24 Feb 22 16:41 /usr/local/etc/nss_ldap.conf ->
/usr/local/etc/ldap.conf
nss_ldap-1.244 RFC 2307 NSS module
pam_ldap-1.8.0 A pam module for authenticating with LDAP
Is somebody have the same problems?
WBR
--
Dmitriy Kirhlarov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7247 ext.203 F:+7 495 105 7246 E:[EMAIL PROTECTED]
OILspace - The resource enriched - www.oilspace.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
