[solved] NFS upgrade 5.2.1->5.4 "+cd: not found"
On Wed, 01 Jun 2005 18:42:29 +0400 Boris Samorodov wrote:
> Hi!
> Seems to me that it's like a FAQ, but can't find an answer. Upgrade
> from 5.2.1 to 5.4 via NFS:
> On nfs server:
> 1. buildkernel
> On host:
> 1. mount_nfs /usr/src
> 2. mount_nfs /usr/obj
> 3. installkernel
> 4. mergemaster -p
>
> 5. make installworld
> -
> mkdir -p /tmp/install.aCiGkcCk
>
> for prog in [ awk cap_mkdb cat chflags chmod chown date echo egrep find grep
> >
> +cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386
> CPUTY>
> +cd: not found
>
> *** Error code 127
>
>
>
> Stop in /usr/src.
>
> *** Error code 1
>
>
>
> Stop in /usr/src.
>
> -
> It is the result of "{_+_}cd" at Makefile.inc1. Neighter UPDATING nore
> google helped me. Maybe you? ;-)
I did a manual install almost every directory at /usr/src and finally
make installworld succedded. It seems to me that usr.sbin did the
trick.
WBR
--
bsam
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kadmin (heimdal port) ignores the ldap backend
Boris Samorodov wrote: I removed temporally all /usr/lib/libkadm5srv* libraries and as results kadmin was forced to load /usr/local libraries, but I get the same problem :-( again kadmin doesn't use ldap and fallback to database files. From your dump: 58516 kadmin CALL access(0x28079000,0) 58516 kadmin NAMI "/usr/lib/libhdb.so.7" 58516 kadmin RET access 0 58516 kadmin CALL open(0x28076040,0,0xbfbfebcc) 58516 kadmin NAMI "/usr/lib/libhdb.so.7" 58516 kadmin RET open 3 58516 kadmin CALL fstat(0x3,0xbfbfebcc) 58516 kadmin RET fstat 0 58516 kadmin CALL read(0x3,0x28070c40,0x1000) 58516 kadmin GIO fd 3 read 4096 bytes Thus kadmin is using the system libhdb. The port version shuold be at /usr/local/lib. Effectively /usr/lib/libhdb.so.7 was the cause of the problem. Thank you Boris. I'd like to ask what is the proper way of treat with this conflict? is it unavoidable? is there any solution? Also it'd be interesting if a warning was printed by the port install script advising the consequences of enable "LDAP backend" in the heimdal port. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kadmin (heimdal port) ignores the ldap backend
On Fri, 03 Jun 2005 11:41:30 +0200 fandino wrote: > Boris Samorodov wrote: > >>I removed temporally all /usr/lib/libkadm5srv* libraries and as results > >>kadmin was forced to load /usr/local libraries, but I get the same > >>problem :-( > > > >>again kadmin doesn't use ldap and fallback to database files. > > From your dump: > > 58516 kadmin CALL access(0x28079000,0) > > 58516 kadmin NAMI "/usr/lib/libhdb.so.7" > > 58516 kadmin RET access 0 > > 58516 kadmin CALL open(0x28076040,0,0xbfbfebcc) > > 58516 kadmin NAMI "/usr/lib/libhdb.so.7" > > 58516 kadmin RET open 3 > > 58516 kadmin CALL fstat(0x3,0xbfbfebcc) > > 58516 kadmin RET fstat 0 > > 58516 kadmin CALL read(0x3,0x28070c40,0x1000) > > 58516 kadmin GIO fd 3 read 4096 bytes > > Thus kadmin is using the system libhdb. The port version shuold be > > at > > /usr/local/lib. > Effectively /usr/lib/libhdb.so.7 was the cause of the problem. Thank you > Boris. You are welcome. > I'd like to ask what is the proper way of treat with this conflict? So do I. > is it unavoidable? The same. > is there any solution? I already gave you a skeleton of the wrapping script for kadmin with search-order changed for libraries. IMO it's the most effective way at the matter. Does someone know the right solution? > Also it'd be interesting if a warning was printed by the port install script > advising the consequences of enable "LDAP backend" in the heimdal port. Please, do send-pr with your suggestion. WBR -- bsam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: filesystems not properly unmounted
yuval levy <[EMAIL PROTECTED]> wrote: > In my opinion, an O/S that can not handle the most > popular file systems is handicapped in a world of > increasing diversity. Please excuse me jumping in here, but ext2/ext3 is certainly _not_ one of the most popular file systems for most members of this mailing list. Personally, I have used the ext2fs driver for exactly one reason: to migrate data from Linux to FreeBSD on machines which are being converted from the Dark Side. And that requires mounting the file system just once (read-only), copying the data, then umount it, followed by newfs. There's no need to even think about shutting down while the ext2fs is still mounted. I'd recommend against mounting any ext2/ext3 file systems permanently for sharing data between Linux and FreeBSD. There are better ways to do that. (The best way, of course, is getting rid of Linux in the first place.) Best regards Oliver PS: For what it's worth, the most popular filesystems for me are UFS/UFS2, NFS, ISO9660, UDF, and maybe FAT. No more. I guess for the majority of computer users the most popular filesystems are NTFS, ISO9660, FAT and maybe HFS, and they don't even know what "ext2" is. :-) -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "FreeBSD is Yoda, Linux is Luke Skywalker" -- Daniel C. Sobral ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Cialis - the next to the Guiness' book?!..
Who does one have to lobby to get an old fashion "bounty" for spammers heads? On Fri, 3 Jun 2005, Jimmy wrote: Big savings on brand name drugs. http://vtpc.8nbjcrq15iqgc9q.foliolateda.com If love is the answer, could you rephrase the question? Character is much easier kept than recovered. Coolidge is dead How could they tell? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DELL PowerEdge 2850 and FreeBSD 5.4
I have numerous Dell 1850s all with 4gigs of ram and SCSI in mirror 1 raid. I feel I must of been very lucky because I have never had a single problem with these machines, 1 of them is under severe load. I setup these machines in a different way then most people. Because I run the machines in a remote hosting complex I order the Dell machines to the hosting complex and get the 'remote smart hands' to put the server in the my rack, enable the serial via bios then get them to plug in a serial cable into its single serial port and get them to drop in a i386 FreeBSD install disk so I can install remotely. They use a generic kernel and have usbd_enable="YES" set. I have one 1850 thats got an uptime of 125 days and thats only since I last rebooted it. Maybe because the USB ports have never really been used I have had better luck? Mike David Barnett wrote: Gary, I'm fighting the same battle on two new 2850's and two 1850's; "Interrupt storm detected on "irq18:uhci2"; throttling interrupt source". These machines have 2GB of ram and I using the i386 5.4Rel. version. This happens right after the reboot at the end of an install from CD. I've chosen to install "all", and bring up the ethernet interface. When I get the message, the machine is unresponsive to keyboard input or pings; basically frozen. I also tried 5.3 Rel. with the same results. From searching the lists I concluded disabling USB might be worth trying, so I did that in the BIOS. I'm still getting the same message and freeze. How are you disabling USB? It seems that has worked for you. One tidbit, they have the DRAC 4/I remote access controller cards in them, but I have no reason to believe they're involved at this point. Oh, and firmware is current throughout. Thanks for any hints. Dave Barnett Gary Schrock wrote: At 05:05 AM 6/1/2005, you wrote: I have checked on the DELL site for any updates to the BIOS/Firmware and the 2 PE2850's are running the latest versions. BIOS A02 Dell Backplane Firmware, v.1.00, A00 Dell BMC Firmware, v.1.23, A03 LSI Logic Perc 4e/Di, v.516A, A01 Both machines have the same symptoms or the reboots at random times. I have now disabled the USB via rc.conf to see if the reboots still occur. On one machine I shall drop the PAE kernel and see if that increases the stability We've been running a 2850 with dual processors for a while now, although we're only running 2G of ram. I'm also running the i386 verson of freebsd instead of amd64 (since I couldn't decide whether I'd really gain anything by running that version, especially with my low ram amount). We did initially have a problem with our add-on perc4 controller, but that was obviously a problem with that controller, but after that was resolved, the only issue I've had with it is the usb interrupt storms. Since we don't use usb on that system, I've just completely disabled it. After that, it's run flawlessly for about 6 months now. Regards Danny -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vinny Abello Sent: 01 June 2005 05:10 To: Danny Cooper Cc: freebsd-stable@freebsd.org Subject: RE: DELL PowerEdge 2850 and FreeBSD 5.4 What BIOS revision are you running in your 2850? Make sure all your firmware is up to date. I had problems with an slightly older Dell 2650 trying to install FreeBSD until I flashed the latest RAID controller firmware. If this doesn't help, try running some diagnostics on the hardware. Dell has some pretty extensive utilities. I think you can boot a Dell diagnostic CD you download from their web site. It's possible you have bad RAM. At 11:50 AM 5/31/2005, Danny Cooper wrote: >With the kernel I removed all non-required devices > >Firewire, usb all the NIC's except em and removed all RAID and SCSI >controllers to make sure nothing would interfere. > >I tried to boot with the AMD64 CD but with no success, the machine just >hangs when it tries to load the CD, still trying to work out a solution to >the problem, but it just seems these DELL 2850 machines are for Windows or >RedHat!!! > >DC > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Claus Guttesen >Sent: 31 May 2005 16:15 >To: Danny Cooper >Cc: freebsd-stable@freebsd.org >Subject: Re: DELL PowerEdge 2850 and FreeBSD 5.4 > > > I have installed FreeBSD 5.4 RELEASE and upgraded to -STABLE on a DELL > > PE2850. > > > > FreeBSD 5.4-STABLE #1: Wed May 25 23:43:12 BST 2005 > > CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3192.22-MHz 686-class CPU) > > real memory = 5100273664 (4864 MB) > > avail memory = 4189892608 (3995 MB) > > MPTable: > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 6 > > amr0: Firmware 516A, BIOS H418, 256MB RAM > > > > I have disabled ACPI HTT and enabled PAE to make the whole system memory > > available. > > > > However the problem I have is the system can crash at a
Re: kadmin (heimdal port) ignores the ldap backend
I believe you have to set NO_KERBEROS in /etc/make.conf. Then rebuild & install the FreeBSD sources in /usr/src. Then after the installworld, you'll need to go to the /usr/lib directory and move/remove all libs that are older than the date of the install. NOTE: I would also do a second installworld, after removing the libraries. Just incase something was removed that wasn't supposed to be removed. Then install the KERBEROS hemidal port. Scot On 6/3/05, Boris Samorodov <[EMAIL PROTECTED]> wrote: > On Fri, 03 Jun 2005 11:41:30 +0200 fandino wrote: > > > Boris Samorodov wrote: > > >>I removed temporally all /usr/lib/libkadm5srv* libraries and as results > > >>kadmin was forced to load /usr/local libraries, but I get the same > > >>problem :-( > > > > > >>again kadmin doesn't use ldap and fallback to database files. > > > From your dump: > > > 58516 kadmin CALL access(0x28079000,0) > > > 58516 kadmin NAMI "/usr/lib/libhdb.so.7" > > > 58516 kadmin RET access 0 > > > 58516 kadmin CALL open(0x28076040,0,0xbfbfebcc) > > > 58516 kadmin NAMI "/usr/lib/libhdb.so.7" > > > 58516 kadmin RET open 3 > > > 58516 kadmin CALL fstat(0x3,0xbfbfebcc) > > > 58516 kadmin RET fstat 0 > > > 58516 kadmin CALL read(0x3,0x28070c40,0x1000) > > > 58516 kadmin GIO fd 3 read 4096 bytes > > > Thus kadmin is using the system libhdb. The port version shuold be > > > at > > > /usr/local/lib. > > > Effectively /usr/lib/libhdb.so.7 was the cause of the problem. Thank you > Boris. > > You are welcome. > > > I'd like to ask what is the proper way of treat with this conflict? > > So do I. > > > is it unavoidable? > > The same. > > > is there any solution? > > I already gave you a skeleton of the wrapping script for kadmin with > search-order changed for libraries. IMO it's the most effective way at > the matter. > > Does someone know the right solution? > > > Also it'd be interesting if a warning was printed by the port install > script > > advising the consequences of enable "LDAP backend" in the heimdal port. > > Please, do send-pr with your suggestion. > > > WBR > -- > bsam > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: filesystems not properly unmounted [OT]
> Personally, I have used the ext2fs driver for exactly one > reason: to migrate data from Linux to FreeBSD on machines > which are being converted from the Dark Side. And that I do not seed the need of insult other OS. Even worse if the other OS is open source (as linux). With this attitude we are NOT going to change anything. Linux has its _really_ good points. Windows too (altough personally I hate windows/microsoft, I must admit windows' advanteges). I do NOT pretend to start a flameware. I am just reflecting. Maxi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kadmin (heimdal port) ignores the ldap backend
Hi, Scot! Thank you for your answer, 'cause I've been thinking nobody is interested at the matter. On Fri, 3 Jun 2005 11:47:52 -0500 Scot Hetzel wrote: > I believe you have to set NO_KERBEROS in /etc/make.conf. Then rebuild > & install the FreeBSD sources in /usr/src. Then after the > installworld, you'll need to go to the /usr/lib directory and > move/remove all libs that are older than the date of the install. > NOTE: I would also do a second installworld, after removing the > libraries. Just incase something was removed that wasn't supposed to > be removed. > Then install the KERBEROS hemidal port. Hmm. And what about kerbesized applications (i.e. sshd) from the base system which I'd like to use with kerberos authentication? WBR -- bsam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kadmin (heimdal port) ignores the ldap backend
On 6/3/05, Boris Samorodov <[EMAIL PROTECTED]> wrote:
> > I believe you have to set NO_KERBEROS in /etc/make.conf. Then rebuild
> > & install the FreeBSD sources in /usr/src. Then after the
> > installworld, you'll need to go to the /usr/lib directory and
> > move/remove all libs that are older than the date of the install.
>
> > NOTE: I would also do a second installworld, after removing the
> > libraries. Just incase something was removed that wasn't supposed to
> > be removed.
>
> > Then install the KERBEROS hemidal port.
>
> Hmm. And what about kerbesized applications (i.e. sshd) from the base
> system which I'd like to use with kerberos authentication?
>
looks like you would have to install them from ports, unless you
hacked the sources to use KERBEROS installed from the port.
src/secure/usr.bin/ssh/Makefile
src/lib/libtelnet/Makefile
src/lib/libpam/modules/modules.inc
NOTE: there may be others
You would have to change the files to check if the hemdial libraries
are installed:
.if (defined(HEIMDAL_HOME) && exists(${HEIMDAL_HOME}/lib/libkrb5.so) )
|| !defined(NO_KERBEROS)
NOTE: you may also need to set LDFLAGS+=-L${HEIMDAL_HOME}/lib
And see if it compiles.
Scot
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RAID-1 as back-up
Dear list, I would like to use RAID-1 as a back-up solution. If one of the disk breaks I would like my server to continue to run from the other disk. I have followed the mailing list for a while and read some howtos, but I'm not sure if this is possible (without doing all kinds of tricks when the accidents happens - removing meta data and so on). In addition, I thought, gvinum was the way to go, but hasn't there been some problems with it (reported here lately)? I'm running 5.3 - what do you recommend - gvinum, ccd, others? What is the definitive howto for the recommend solution. Thx for your time. Regards, Hans ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RAID-1 as back-up
On Sat, Jun 04, 2005 at 12:26:20AM +0200, Hans F. Nordhaug wrote: > Dear list, > > I would like to use RAID-1 as a back-up solution. If one of the disk > breaks I would like my server to continue to run from the other disk. > I have followed the mailing list for a while and read some howtos, > but I'm not sure if this is possible (without doing all kinds of tricks > when the accidents happens - removing meta data and so on). In > addition, I thought, gvinum was the way to go, but hasn't there been > some problems with it (reported here lately)? I'm running 5.3 - what > do you recommend - gvinum, ccd, others? What is the definitive howto for > the recommend solution. Thx for your time. > > Regards, > Hans I do this using gmirror; I run a two-disk Raid1 system for normal operaton, and back up to a third device which a CRON job attaches and detaches nightly to image the system. The detached disk is removed, so it will not be detected as a valid device on boot. If the online mirror breaks (either disk) the other continues on its merry way. In a catastrophe where the system scribbles on BOTH disks, the other volume can be booted manually and with a bit of effort (couple of command-line entries from single user mode) brought online as a single device. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RAID-1 as back-up
Hans F. Nordhaug on 2005-06-04 00:26:20 +0200: > I would like to use RAID-1 as a back-up solution. If one of the disk > breaks I would like my server to continue to run from the other > disk. Just as fair warning, you should not rely on RAID as a 'backup' like you would rely on writing to removable media and storing off-site. If someone cracks your computer and you want to go back to known good snapshot, you're out of luck; if you accidently overwrite something, RAID won't help you. > I'm running 5.3 - what do you recommend - gvinum, ccd, others? What > is the definitive howto for the recommend solution. You should use gmirror. There's an excellent guide - http://people.freebsd.org/~rse/mirror/. I've been using gmirror for about half a year and have had no problems. pgpxpx0468PZt.pgp Description: PGP signature
Re: RAID-1 as back-up
On Fri, Jun 03, 2005 at 06:36:34PM -0400, Alec Berryman wrote: > Hans F. Nordhaug on 2005-06-04 00:26:20 +0200: > > > I would like to use RAID-1 as a back-up solution. If one of the disk > > breaks I would like my server to continue to run from the other > > disk. > > Just as fair warning, you should not rely on RAID as a 'backup' like > you would rely on writing to removable media and storing off-site. If > someone cracks your computer and you want to go back to known good > snapshot, you're out of luck; if you accidently overwrite something, > RAID won't help you. That depends. You can use a third volume in a RAID1 system to image to nightly under automatic control and detach it when finished. Done with care this disk will NOT be used at boot (it might actually boot the kernel, BUT it is not considered one of the providers in gmirror if you "remove" it, so it will not come back into the configuration on a restart) If a hacker scribbles on your disks, this one can still be booted manually with a bit of effort (couple of commands from single user mode.) It will not come up clean but if care is taken (e.g. flushing any open DBMS processes that are active at the time of the detach) you can insure that critical areas on the system are intact, even though a FSCK will be required. You can also (since the disk is detached) physically remove it from the machine (assuming hardware support for such a thing) and physically take the disk somewhere and shove it in an offsite location. The beauty of this over a tape backup is that it is MUCH faster (I can copy about 300GB this way in under five hours), is a true image copy and the resulting media is directly bootable (no restore required) It can also be mounted separately if necessary with the system running (if set up correctly) so you can incrementally copy a file that has been removed by accident, for example, back onto the working volumes. Another option is to DUMP to a disk. Using the snapshop features this is even safer in terms of data integrity but you lose the online nature of the backup (it has to be restored if there is a problem; you can't just boot the volume.) It also allows incremental backups if you desire to use them. As with all backup strategies (absent write-once media in SOME cases) if the media is PHYSICALLY connected to the machine and it is hacked it is possible for a hacker to scribble on THAT as well. This is no more likely, however, than it is for a tape cartridge system (e.g. tape library, etc) that is likewise available while the machine is running. Backup up to a disk drive is becoming much more attractive in terms of total cost, especially when one includes in the picture the time required to restore. The high-capacity tape makers are no longer necessarily the option of choice for this necessary function. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Repeatable crash with 5.4-p1-RELEASE and SMP
Hi!
This is very similar to Brendan White problem just reported here. My guess
is it is the very same problem. I've reported the same problem on some
occasions before (although I use amd64, so my postings are to
[EMAIL PROTECTED]).
My system is also Dell 2850, dual CPUs, 3GB RAM, running amd64 FreeBSD
5.4-p1. It is quite stable (but slow) when running without SMP. When SMP is
on, it crashes within a few hours. High load, around 4. See my postings on
amd64@ for many more details.
Anyway, I have managed to get an automatic reboot and a core dump. Giant
leap for mankind :-) . It looks kind of partly overwritten, though.
According to the Developer's handbook, the core should be saved *before*
the swap partition is added to the system. I can easily verifying that this
is not the case, the swap is "mounted" first. I once again raise the
question if PR conf/73834 shouln't be addressed? Or perhaps my core dump is
quite normal? Doesn't look like it. In rc.conf, I have:
# kernel crash dumps
dumpdev="/dev/amrd0s2b"
dumpdir="/misc/crash"
Here's the dump. Anything else I shall extract, please just ask.
# kgdb kernel.debug /misc/crash/vmcore.11
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined 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 "amd64-marcel-freebsd".
#0 doadump () at pcpu.h:167
167 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:167
#1 0x in ?? ()
#2 0x80341267 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:410
#3 0x80341ac6 in panic (fmt=0xff007b76d000 " «x{") at
/usr/src/sys/kern/kern_shutdown.c:566
#4 0x804f0f52 in trap_fatal (frame=0xc, eva=18446742976269307904)
at /usr/src/sys/amd64/amd64/trap.c:639
#5 0x804f11ef in trap_pfault (frame=0xb1d229b0, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:562
#6 0x804f1457 in trap (frame=
{tf_rdi = -1097427517200, tf_rsi = -1097440243712, tf_rdx = 1056,
tf_rcx = 0, tf_r8 = 0, tf_r9 = 0, tf_r
ax = 1056, tf_rbx = 0, tf_rbp = -1098069766144, tf_r10 = 4503599627366400,
tf_r11 = 3392, tf_r12 = 4, tf_r13 =
4, tf_r14 = -1099313881192, tf_r15 = -1097364452848, tf_trapno = 12,
tf_addr = 136, tf_flags = -1099313881192
, tf_err = 0, tf_rip = -2144020582, tf_cs = 8, tf_rflags = 66050, tf_rsp =
-1311626640, tf_ss = 0})
at /usr/src/sys/amd64/amd64/trap.c:341
#7 0x804deb0b in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:171
#8 0xff007c3900f0 in ?? ()
#9 0xff007b76d000 in ?? ()
#10 0x0420 in ?? ()
#11 0x in ?? ()
#12 0x in ?? ()
#13 0x in ?? ()
#14 0x0420 in ?? ()
#15 0x in ?? ()
#16 0xff0055f11000 in ?? ()
#17 0x000ff000 in ?? ()
#18 0x0d40 in ?? ()
#19 0x0004 in ?? ()
#20 0x0004 in ?? ()
#21 0xff000bc95f98 in ?? ()
#22 0xff007ffb4a10 in ?? ()
#23 0x000c in ?? ()
#24 0x0088 in ?? ()
#25 0xff000bc95f98 in ?? ()
#26 0x in ?? ()
#27 0x8034d79a in thread_fini (mem=0x0, size=0) at
/usr/src/sys/kern/kern_thread.c:271
#28 0x in ?? ()
#29 0x0001 in ?? ()
#30 0xff007ffb4a00 in ?? ()
#31 0xff0055f11f98 in ?? ()
#32 0x804d46ff in zone_drain (zone=0x8) at
/usr/src/sys/vm/uma_core.c:749
#33 0x804d22b6 in zone_foreach (zfunc=0x804d4530
)
at /usr/src/sys/vm/uma_core.c:1494
#34 0x804d5ec9 in uma_reclaim () at /usr/src/sys/vm/uma_core.c:2623
#35 0x804cfcac in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:674
#36 0x8032805c in fork_exit (callout=0x804cf6b0
, arg=0x0,
frame=0xb1d22c50) at /usr/src/sys/kern/kern_fork.c:791
#37 0x804ded0e in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:296
#38 0x in ?? ()
#39 0x in ?? ()
#40 0x0001 in ?? ()
#41 0x in ?? ()
#42 0x in ?? ()
#43 0x in ?? ()
#44 0x in ?? ()
#45 0x in ?? ()
#46 0x in ?? ()
#47 0x in ?? ()
#48 0x in ?? ()
---Type to continue, or q to quit---
#49 0x in ?? ()
#50 0x in ?? ()
#51 0x in ?? ()
#52 0x in ?? ()
#53 0x in ?? ()
#54 0x in ?? ()
#55 0x in ?? ()
#56 0x in ?? ()
#57 0x in ?? ()
#58 0x in
USB Flash memory based mp3 player problems. Tried but failed.
Hello,
FreeBSD lolownia 5.4-STABLE FreeBSD 5.4-STABLE #4: Sat Jun 4 01:54:40 CEST 2005
cvsupped today. Basically a GENERIC kernel with hw i don't need commented out.
I have Samsung's YP-55 MP3 player. When I try to copy a file to it,
the process hangs for a while, and then kernel produces:
umass0: BBB reset failed, STALLED
umass0: BBB bulk-in clear stall failed, STALLED
umass0: BBB bulk-out clear stall failed, STALLED
System becomes not responsive (blocking a lot on i/o), even after pulling
the device out. Reboot mandatory.
I found several threads in google describeing this problem. Tried to follow
the instructions and:
1. Added my YP-55 to sys/dev/usb/usbdevs
/* Samsung products */
product SAMSUNG ML6060 0x3008 ML-6060 laser printer
+product SAMSUNG YP55 0x500d YP-55 MP3 Player
2. Added entries for quirks suggested there:
+++ umass.c
+ { USB_VENDOR_SAMSUNG, USB_PRODUCT_SAMSUNG_YP55, RID_WILDCARD,
+ UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
+ NO_INQUIRY | NO_GETMAXLUN
+ },
3. Added scsi quirks for it (also suggested in google)
+++ scsi_da.c
+ {
+ /*
+* Samsung YP-55, rev 1.10/0.01, addr 3
+*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, "Samsung Electronics" , "YP-55 M
P3 Player", "*"},
+ /*quirks*/ /*DA_Q_NO_SYNC_CACHE*/ DA_Q_NO_6_BYTE
+ },
I tried these in various combinations, with DA_Q_NO_SYNC_CACHE,
with DA_Q_NO_6_BYTE, without scsi quirks at all, etc.
All failed.
I have even downloaded a 36mb linux kernel source just to find out my player
is not present in their drivers/usb/storage/unusual_devs.h .
As a last resort, I'm asking for help here.
Any hints?
I'm attaching some logs. (sorry it got thaat long)
Here is debug data with hw.usb.uhci.debug=7
Jun 4 03:06:16 lolownia kernel: FreeBSD 5.4-STABLE #4: Sat Jun 4 01:54:40
CEST 2005
Jun 4 03:06:16 lolownia kernel: [EMAIL
PROTECTED]:/usr/src/sys/i386/compile/ROBAL
()
Jun 4 03:06:16 lolownia kernel: uhci0: port 0xc000-0xc01f irq 9 at device 7.2 on pci0
Jun 4 03:06:16 lolownia kernel: usb0: on uhci0
Jun 4 03:06:16 lolownia kernel: usb0: USB revision 1.0
Jun 4 03:06:16 lolownia kernel: usbd_get_string: getting lang failed, using 0
Jun 4 03:06:16 lolownia kernel: uhub0: Intel UHCI root hub, class 9/0, rev
1.00/1.00, addr 1
Jun 4 03:06:16 lolownia kernel: uhub0: 2 ports with 2 removable, self powered
(.)
Jun 4 03:06:16 lolownia kernel: ulpt0: Hewlett-Packard DeskJet 840C, rev
1.00/1.00, addr 2, iclass 7/1
Jun 4 03:06:16 lolownia kernel: ulpt0: using bi-directional mode
(...)
Jun 4 03:09:45 lolownia kernel: uhci_root_ctrl_control type=0xa3 request=00
Jun 4 03:09:45 lolownia kernel: uhci_root_ctrl_control type=0x23 request=01
Jun 4 03:09:45 lolownia kernel: uhci_root_ctrl_control: UR_CLEAR_PORT_FEATURE
port=1 feature=16
Jun 4 03:09:45 lolownia kernel: uhci_root_ctrl_control type=0x23 request=03
Jun 4 03:09:45 lolownia kernel: uhci port 1 reset, status0 = 0x0280
Jun 4 03:09:45 lolownia kernel: uhci port 1 reset, status1 = 0x0083
Jun 4 03:09:45 lolownia kernel: uhci port 1 iteration 9, status = 0x0097
Jun 4 03:09:45 lolownia kernel: uhci port 1 iteration 8, status = 0x0095
Jun 4 03:09:45 lolownia kernel: uhci port 1 reset, status2 = 0x0095
Jun 4 03:09:45 lolownia kernel: uhci_root_ctrl_control type=0xa3 request=00
Jun 4 03:09:45 lolownia kernel: uhci_root_ctrl_control type=0x23 request=01
Jun 4 03:09:45 lolownia kernel: uhci_root_ctrl_control: UR_CLEAR_PORT_FEATURE
port=1 feature=20
Jun 4 03:09:46 lolownia kernel: uhci_root_ctrl_control type=0xa3 request=00
Jun 4 03:09:46 lolownia kernel: uhci_open: pipe=0xc1b86180, addr=0, endpt=0 (1)
Jun 4 03:09:46 lolownia kernel: uhci_device_control type=0x00, request=0x05,
wValue=0x0003, wIndex=0x len=0, addr=0, endpt=0
Jun 4 03:09:46 lolownia kernel: uhci_device_ctrl_done: length=0
Jun 4 03:09:46 lolownia kernel: uhci_device_control type=0x80, request=0x06,
wValue=0x0100, wIndex=0x len=8, addr=3, endpt=0
Jun 4 03:09:46 lolownia kernel: uhci_device_ctrl_done: length=8
Jun 4 03:09:46 lolownia kernel: uhci_device_control type=0x80, request=0x06,
wValue=0x0100, wIndex=0x len=18, addr=3, endpt=0
Jun 4 03:09:46 lolownia kernel: uhci_device_ctrl_done: length=18
Jun 4 03:09:46 lolownia kernel: uhci_device_control type=0x80, request=0x06,
wValue=0x0300, wIndex=0x len=2, addr=3, endpt=0
Jun 4 03:09:46 lolownia kernel: uhci_device_ctrl_done: length=2
Jun 4 03:09:46 lolownia kernel: uhci_device_control type=0x80, request=0x06,
wValue=0x0300, wIndex=0x len=4, addr=3, endpt=0
Jun 4 03:09:46 lolownia kernel: uhci_device_ctrl_done: length=4
Jun 4 03:09:46 lolownia kernel: uhci_device_control type=0x80, request=0x06,
wValue=0x0303, wIndex=0x0409 len=2, addr=3, endpt=0
Jun 4 03:09:46 lolownia kernel: uhci_device_ctrl_done: length=2
Jun 4 03:09:46 lolownia kernel: uhci_device_control type=0x80, request=0x06,
wValue=0x0303
Re: Context sensitivity in beastie.4th?
On Fri, 27 May 2005 03:13 pm, Scott Long wrote:
> Scott Long wrote:
> > Malcolm Kay wrote:
> >> I have installed FreeBSD 5.4 RELEASE on a new machine,
> >> Celeron + SATA drive, without and problems, include a
> >> kernel rebuild to support a PCI serial card.
> >>
> >> But now I wish to change the graphic, beastie, that appears
> >> in the boot menu. I am certainly no expert or even acolyte
> >> in forth programming but the job appears to be simple
> >> enough -- just change the characters in the
> >> 'beastie' constructions and if we don't exceed the
> >> available screen space all should be well!
> >>
> >> Well what I got was a cycling reboot going back ech time to
> >> the BIOS splash screen and advancing an apparently
> >> negligable distance into the FBSD
> >> boot sequence.
> >>
> >> I had actually copied /boot/beastie.4th to
> >> /boot/phoenix.4th, edited the copy and pointed
> >> /boot/loader.rc at phoenix.4th instead of beastie.4th.
> >> Recovery by booting from the distribution CD and entering
> >> "Fixit" to change
> >> the pointer back to beastie.4th.
> >>
> >> Most variants on my original attempt ended up the same way,
> >> but some crashed with a "directory full" message which
> >> seems quite strange as my images have always been smaller
> >> than the original 'beastie'.
> >>
> >> Replacing the colourised version of my 'phoenix' with a
> >> copy of the monochrome version worked.
> >>
> >> At present I have a phoenix.4th file which works but does
> >> not exhibit the full image. The differences to the original
> >> beastie.4th file are shown here
> >> with escape characters replaced by '{esc}' to limit mail
> >> confusion.
> >>
> >> With the line:
> >> ( 2dup at-xy ." {esc}[1m^ ^" 1+ )
> >> uncommented the system goes back to an infinite boot loop.
> >>
> >> This all seems very strange and unbelievable -- I must
> >> surely be doing something very stupid. Does anyone have any
> >> idea what that might be?
> >
> > Seems to work for me with the commented lines fixed. Btw,
> > you by no doubt have noticed that it's somewhat inconvenient
> > to do 4th programming by modifying the boot scripts and then
> > praying that the reboot works. It's possible to do 90% of
> > the testing in userland, like I did when I wrote
> > beastie.4th.
> >
> > Go to /sys/boot/ficl. Do 'make clean && make testmain'.
> > This will create a binary called 'testmain' either in the
> > '.' directory or in /usr/obj/usr/src/sys/boot/ficl. Copy
> > this binary to your home directory. Then copy screen.4th,
> > frames.4th, and beastie.4th from /boot to your home
> > directory. Next create a file called init.4th
> >
> > containing the following:
> > : boot drop exit ;
> > : reboot drop exit ;
> >
> > load screen.4th
> > load frames.4th
> > load beastie.4th
> > beastie-start
> >
> > Then run it via './testmain init.4th'. The countdown timer
> > won't work and most of the keys naturally won't do what they
> > are supposed to do, but everything else in the menu should
> > work just as it would at boot. I tested your colorized
> > phoenix this way just now and it worked.
>
> Oh, one thing I forgot to mention is that you'll need to
> comment out the 'include' lines in beastie.4th since the
> testmain environment doesn't implement those words.
>
I found I also needed to do something about
getsenv
setenv
and
unsetenv
The following at the start of init.4th worked:
--
: getenv
2dup s" loader_color" compare 0= if
2drop
s" NO"
exit
then
2dup s" beastie_disable" compare 0= if
2drop
-1
exit
then
2drop
-1
exit
;
: setenv drop drop ;
: unsetenv drop ;
Where the fourth line might also be
s" YES"
Symptoms suggested to me that I had a memory problem but
memtest86 ran without difficulty.
I also found much works differently at boot. Closer examination
shows that a number of things take different paths oftem using
BIOS or simplified code when called at boot -- I wonder whether
there is some anomaly in memory allocation when run from boot
that raises its ugly head on my machine.
I have achieved what I want by using a empirically derived
context but the underlying problem persists.
Anyway thanks for your input.
Malcolm
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Repeatable crash with 5.4-p1-RELEASE and SMP
On Sat, Jun 04, 2005 at 03:48:04AM +0200, Palle Girgensohn wrote:
> Here's the dump. Anything else I shall extract, please just ask.
>
> # kgdb kernel.debug /misc/crash/vmcore.11
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
> Undefined 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 "amd64-marcel-freebsd".
> #0 doadump () at pcpu.h:167
> 167 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> (kgdb) backtrace
> #0 doadump () at pcpu.h:167
> #1 0x in ?? ()
> #2 0x80341267 in boot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:410
> #3 0x80341ac6 in panic (fmt=0xff007b76d000 "??x{") at
> /usr/src/sys/kern/kern_shutdown.c:566
> #4 0x804f0f52 in trap_fatal (frame=0xc, eva=18446742976269307904)
>at /usr/src/sys/amd64/amd64/trap.c:639
> #5 0x804f11ef in trap_pfault (frame=0xb1d229b0, usermode=0)
>at /usr/src/sys/amd64/amd64/trap.c:562
> #6 0x804f1457 in trap (frame=
> {tf_rdi = -1097427517200, tf_rsi = -1097440243712, tf_rdx = 1056,
> tf_rcx = 0, tf_r8 = 0, tf_r9 = 0, tf_r
> ax = 1056, tf_rbx = 0, tf_rbp = -1098069766144, tf_r10 = 4503599627366400,
> tf_r11 = 3392, tf_r12 = 4, tf_r13 =
> 4, tf_r14 = -1099313881192, tf_r15 = -1097364452848, tf_trapno = 12,
> tf_addr = 136, tf_flags = -1099313881192
> , tf_err = 0, tf_rip = -2144020582, tf_cs = 8, tf_rflags = 66050, tf_rsp =
> -1311626640, tf_ss = 0})
>at /usr/src/sys/amd64/amd64/trap.c:341
> #7 0x804deb0b in calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:171
> #8 0xff007c3900f0 in ?? ()
> #9 0xff007b76d000 in ?? ()
Is your kernel built with -O2, or -O? There are a lot of bogus stack
frames here, which suggest the former.
Kris
pgpiEg3KIUXRh.pgp
Description: PGP signature
Re: Context sensitivity in beastie.4th?
Malcolm Kay wrote:
On Fri, 27 May 2005 03:13 pm, Scott Long wrote:
Scott Long wrote:
Malcolm Kay wrote:
I have installed FreeBSD 5.4 RELEASE on a new machine,
Celeron + SATA drive, without and problems, include a
kernel rebuild to support a PCI serial card.
But now I wish to change the graphic, beastie, that appears
in the boot menu. I am certainly no expert or even acolyte
in forth programming but the job appears to be simple
enough -- just change the characters in the
'beastie' constructions and if we don't exceed the
available screen space all should be well!
Well what I got was a cycling reboot going back ech time to
the BIOS splash screen and advancing an apparently
negligable distance into the FBSD
boot sequence.
I had actually copied /boot/beastie.4th to
/boot/phoenix.4th, edited the copy and pointed
/boot/loader.rc at phoenix.4th instead of beastie.4th.
Recovery by booting from the distribution CD and entering
"Fixit" to change
the pointer back to beastie.4th.
Most variants on my original attempt ended up the same way,
but some crashed with a "directory full" message which
seems quite strange as my images have always been smaller
than the original 'beastie'.
Replacing the colourised version of my 'phoenix' with a
copy of the monochrome version worked.
At present I have a phoenix.4th file which works but does
not exhibit the full image. The differences to the original
beastie.4th file are shown here
with escape characters replaced by '{esc}' to limit mail
confusion.
With the line:
( 2dup at-xy ." {esc}[1m^ ^" 1+ )
uncommented the system goes back to an infinite boot loop.
This all seems very strange and unbelievable -- I must
surely be doing something very stupid. Does anyone have any
idea what that might be?
Seems to work for me with the commented lines fixed. Btw,
you by no doubt have noticed that it's somewhat inconvenient
to do 4th programming by modifying the boot scripts and then
praying that the reboot works. It's possible to do 90% of
the testing in userland, like I did when I wrote
beastie.4th.
Go to /sys/boot/ficl. Do 'make clean && make testmain'.
This will create a binary called 'testmain' either in the
'.' directory or in /usr/obj/usr/src/sys/boot/ficl. Copy
this binary to your home directory. Then copy screen.4th,
frames.4th, and beastie.4th from /boot to your home
directory. Next create a file called init.4th
containing the following:
: boot drop exit ;
: reboot drop exit ;
load screen.4th
load frames.4th
load beastie.4th
beastie-start
Then run it via './testmain init.4th'. The countdown timer
won't work and most of the keys naturally won't do what they
are supposed to do, but everything else in the menu should
work just as it would at boot. I tested your colorized
phoenix this way just now and it worked.
Oh, one thing I forgot to mention is that you'll need to
comment out the 'include' lines in beastie.4th since the
testmain environment doesn't implement those words.
I found I also needed to do something about
getsenv
setenv
and
unsetenv
The following at the start of init.4th worked:
--
: getenv
2dup s" loader_color" compare 0= if
2drop
s" NO"
exit
then
2dup s" beastie_disable" compare 0= if
2drop
-1
exit
then
2drop
-1
exit
;
: setenv drop drop ;
: unsetenv drop ;
Where the fourth line might also be
s" YES"
Symptoms suggested to me that I had a memory problem but
memtest86 ran without difficulty.
I also found much works differently at boot. Closer examination
shows that a number of things take different paths oftem using
BIOS or simplified code when called at boot -- I wonder whether
there is some anomaly in memory allocation when run from boot
that raises its ugly head on my machine.
I have achieved what I want by using a empirically derived
context but the underlying problem persists.
Anyway thanks for your input.
Malcolm
Look at rev 1.11 of /sys/boot/ficl/loader.c. I guess I never merged it
back to RELENG_5. Yes, not having a working getenv word makes some
things act different, but emulating the real functionality would require
simulating a lot more of the underlying loader environment, and that's
more work than I'm able to do right now.
Scott
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
