Updating vmware3 (and missing "avail_end" from /usr/include/machine/pmap.h)
Hi all: I'm trying to get vmware3 working on FreeBSD RELEASE 7.0 for i386 I've resolved every compilation problem except one: the driver.c in vmware3 requires the "avail_end" variable in 6.2's /usr/include/machine/pmap.h but is missing from 7.0's /usr/include/machine/pmap.h The vmware3 code goes like this: r = malloc(sizeof *r, M_DEVBUF, M_WAITOK); if (r == NULL) return ENOMEM; if (avail_end > ISA_DMA_BOUNCE_THRESHOLD) high = trunc_page(ISA_DMA_BOUNCE_THRESHOLD); else high = trunc_page(avail_end); It turns out "avail_end" was removed from /usr/include/machine/pmap.h by revision 1.125, whose commit message reads: The global variable avail_end is redundant and only used once. Eliminate it. Make avail_start static to the pmap on amd64. (It no longer exists on other architectures.) So it appears that we can still get the value represented by the old avail_end variable, but I don't know anything about the kernel and I don't understand that comment. Could some kind soul help me decipher that so I can try to get vmware3 compilable again? Thank you! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with loading all fixed now
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck Robey wrote: > Chuck Robey wrote: >> Ben Kaduk wrote: > >>> cat nvidia_load="YES"" >> /boot/loader.conf >> I'd never heard that about it needing absolutely to load at boot time, but >> you were absolutely right, I have it working now. > >> It also made my loading problem (I don't know if I complained on hackers >> about that or not). No, in looking back to by send-cache, I don't think I >> did, Immediately after I finally got all my raid array proboems fixed, I >> found really that there was only 1 remaining: booting my raid. > >> I have definitely the boot-manager loaded onto ad1 (my 100G emergency eide >> disk) and da0 (my raid). I normally would strike f1 to load the eide for >> emergencies, and f5, then f1, to load from the raid. Well, now, no matter >> what I press, I load from the eide disk. If I intercept the boot at the >> beastie menu, and press 6 to get into the loader, I find currdev is >> _always_ set to disk1s1a (the eide, ad1). If I want to boot the raid, I >> need to manually do a "set currdev=disk2s1a" then unload, then load the >> kernel AND manually load all the modules, because loder.conf isn't getting >> read either. > >> Once I went thru all that, the nvidia driver worked fine, as you predicted, >> any notion why the loading has gone screwey? I can add one thing: When I >> initially installed the system, I was just coming back from using Linux for >> some years, and I forgot that while Linux is in love with using a small >> /boot partition to store the kernels and the bootloader, FreeBSD isn't. I >> had stuck the /boot only onto da1s1d, with my root onto da0s1a. I was >> loading my root via /etc/fstab, I thought, but in fact, I had an old >> version of a just-useable boot onto myu da1s1a, and that was what was >> actually booting. When I got rid of the /boot mount line in fstab, and >> expected things to work ok, this odd refusal to correctly boot from >> disk2s1a began. > > Well, found 50% of the problems, my device,hints had a line mis-setting > currdev, once I fixed that, it now boots from the right disk. One booting > problem remaining: it won't read my /boot/loader.conf. simple file, 2 > whole lines: I found that my linker.hints was loading one module, so (thinks I) why not try to load them all there, and it workedd like a charm. My loader.conf isn't working now, but it really doesn't bother me all that much. I have only a single problem remaining, it's a audio one, so I am off to the multimedia list, and I thank you for letting me lean on you whilst I stewed in my problems. They all seem to come to me in big waves, never one at a time, and it's not even a thing of one problme having multiple symptoms, they each had t heir own fix. God is watching me and having a nice chuckle over this, I guess. > > TCSH-april:chuckr:~:#101-12:50>cat /boot/loader.conf > linux_load="YES" > nvidia_load="YES" > > that's all, but when (in the loader, preboot) I execute the read-conf > command to force it to read the file, it comes back with a syntax error, > saying exactly this: > > " > ^ > > That's it, the single (double) quote, and a caret in column 1 beneath that. > Noting else. Could it maybe be something to do with what zi have in > rc.conf? I have a line in rc.conf, linux_enable="YES", that's ok along > with the loader line, right? > >> Any idea here? Booting is a real drag now. > >> thanks! > > >>> -Ben Kaduk > OK, I'm not giving my ldconfig problem to you folks, its quite likely its a FreeBSD-current problem, so let those folks handle that one. Boy, I feel like the little boy who cried wolf! > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHyE7Rz62J6PPcoOkRAtjmAKCJPKipDoRaoW5lKch/DEecBnDN7QCfbD8I pN43DuNTPuoxu58VankO0mQ= =7VXA -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with loading 1/2 fixed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck Robey wrote: > Ben Kaduk wrote: > >> cat nvidia_load="YES"" >> /boot/loader.conf > > I'd never heard that about it needing absolutely to load at boot time, but > you were absolutely right, I have it working now. > > It also made my loading problem (I don't know if I complained on hackers > about that or not). No, in looking back to by send-cache, I don't think I > did, Immediately after I finally got all my raid array proboems fixed, I > found really that there was only 1 remaining: booting my raid. > > I have definitely the boot-manager loaded onto ad1 (my 100G emergency eide > disk) and da0 (my raid). I normally would strike f1 to load the eide for > emergencies, and f5, then f1, to load from the raid. Well, now, no matter > what I press, I load from the eide disk. If I intercept the boot at the > beastie menu, and press 6 to get into the loader, I find currdev is > _always_ set to disk1s1a (the eide, ad1). If I want to boot the raid, I > need to manually do a "set currdev=disk2s1a" then unload, then load the > kernel AND manually load all the modules, because loder.conf isn't getting > read either. > > Once I went thru all that, the nvidia driver worked fine, as you predicted, > any notion why the loading has gone screwey? I can add one thing: When I > initially installed the system, I was just coming back from using Linux for > some years, and I forgot that while Linux is in love with using a small > /boot partition to store the kernels and the bootloader, FreeBSD isn't. I > had stuck the /boot only onto da1s1d, with my root onto da0s1a. I was > loading my root via /etc/fstab, I thought, but in fact, I had an old > version of a just-useable boot onto myu da1s1a, and that was what was > actually booting. When I got rid of the /boot mount line in fstab, and > expected things to work ok, this odd refusal to correctly boot from > disk2s1a began. Well, found 50% of the problems, my device,hints had a line mis-setting currdev, once I fixed that, it now boots from the right disk. One booting problem remaining: it won't read my /boot/loader.conf. simple file, 2 whole lines: TCSH-april:chuckr:~:#101-12:50>cat /boot/loader.conf linux_load="YES" nvidia_load="YES" that's all, but when (in the loader, preboot) I execute the read-conf command to force it to read the file, it comes back with a syntax error, saying exactly this: " ^ That's it, the single (double) quote, and a caret in column 1 beneath that. Noting else. Could it maybe be something to do with what zi have in rc.conf? I have a line in rc.conf, linux_enable="YES", that's ok along with the loader line, right? > > Any idea here? Booting is a real drag now. > > thanks! > > >> -Ben Kaduk > > >>> OK, I'm not giving my ldconfig problem to you folks, its quite likely its a >>> FreeBSD-current problem, so let those folks handle that one. >>> >>> Boy, I feel like the little boy who cried wolf! >>> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHyEcaz62J6PPcoOkRAmSCAKCPS+g/rJ7A4fjfErjLcoxOzq/IawCcDcat B7Y4mGGyvrtv7sP6Cn097QI= =6eLu -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with ldconfig; nvidia loading fixed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Kaduk wrote: > Hi Chuck, > > On 2/28/08, Chuck Robey <[EMAIL PROTECTED]> wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> > [snip RAID/loader interaction] >> Well, the other thing that's come up, I can't get my nvidia driver to work >> along with xorg. It used to show it's arrival both in kldstat, AND also >> because, in /dev, a file named nvidiactl would show up. This has stopped >> happening. I had been using the old version 100.14.19, and when I checked >> the nvidia website, it seems a couple of newer versions had appeared, so I >> downloaded and built version 169.12. Don't ask me why the crazy version >> numbering, I looked around for something like a changelog, but had no luck. >> Anyhow, updating to the newer version wasn't too hard, but didn't show any >> change. Consulting the /var/log/Xorg.0.log file, even though kldstat says >> that nvidia.ko is loaded, it never shows a /dev/nvidiactl, and the log file >> says clearly that it never finds the Nvidia kernel module. Using it with >> Vesa lets me limp, so I do that, but howcome? > > The nvidia kernel module now needs to be loaded at boot-time; > it won't supercede the default vga support if loaded later. > > cat nvidia_load="YES"" >> /boot/loader.conf I'd never heard that about it needing absolutely to load at boot time, but you were absolutely right, I have it working now. It also made my loading problem (I don't know if I complained on hackers about that or not). No, in looking back to by send-cache, I don't think I did, Immediately after I finally got all my raid array proboems fixed, I found really that there was only 1 remaining: booting my raid. I have definitely the boot-manager loaded onto ad1 (my 100G emergency eide disk) and da0 (my raid). I normally would strike f1 to load the eide for emergencies, and f5, then f1, to load from the raid. Well, now, no matter what I press, I load from the eide disk. If I intercept the boot at the beastie menu, and press 6 to get into the loader, I find currdev is _always_ set to disk1s1a (the eide, ad1). If I want to boot the raid, I need to manually do a "set currdev=disk2s1a" then unload, then load the kernel AND manually load all the modules, because loder.conf isn't getting read either. Once I went thru all that, the nvidia driver worked fine, as you predicted, any notion why the loading has gone screwey? I can add one thing: When I initially installed the system, I was just coming back from using Linux for some years, and I forgot that while Linux is in love with using a small /boot partition to store the kernels and the bootloader, FreeBSD isn't. I had stuck the /boot only onto da1s1d, with my root onto da0s1a. I was loading my root via /etc/fstab, I thought, but in fact, I had an old version of a just-useable boot onto myu da1s1a, and that was what was actually booting. When I got rid of the /boot mount line in fstab, and expected things to work ok, this odd refusal to correctly boot from disk2s1a began. Any idea here? Booting is a real drag now. thanks! > > > -Ben Kaduk > > >> OK, I'm not giving my ldconfig problem to you folks, its quite likely its a >> FreeBSD-current problem, so let those folks handle that one. >> >> Boy, I feel like the little boy who cried wolf! >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2.0.4 (FreeBSD) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFHxylOz62J6PPcoOkRAudcAJ9ex65oZUoh+0gf/7WcpNi6KhwsxwCgje63 >> m4GwVJZrkoU3McfHK1NAArk= >> =wLpy >> -END PGP SIGNATURE- >> ___ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "[EMAIL PROTECTED]" >> -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHyDsqz62J6PPcoOkRAiHkAJ4irPHgJa8Cdx/0Q/cAK6sfzntLhQCgm/W+ 82dYth4MSJgdPHLuCSo4b70= =wKsU -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PXE on 7.0 problem and solution
On Thu, Feb 28, 2008 at 12:30:26PM -0800, Tim Clewlow wrote: > Hi there, > > Installing 7.0 via PXE has a slight problem that is easily worked around. The > file /boot/mfsroot.gz on the installation media needs to be unzipped to make > PXE boot via tftp/nfs work. Otherwise the loader ultimately complains that it > cant find the device to boot from. For example, if you have the installation > media living at /usr/pxe/nfs/ on the PXE server, then do: I documented this in my "how to get FreeBSD to install via PXE and serial console" document: http://jdc.parodius.com/freebsd/pxeboot_serial_install.html I opened a PR at the time of this discovery as well: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120127 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umass: should the device specific information be moved from C code to the text file?
On Fri, Feb 29, 2008 at 12:44:44PM +0100, Ivan Voras wrote: > Peter Jeremy wrote: > > > This sounds like a nice idea - it's also a nuisance having to recompile > > the kernel just to support a weird new USB device you've acquired. > > You can probably keep USB support as a module if you need to recompile > it often :) > > On the original topic: please don't do that. Recent ultra-modern Linux > systems have started offloading such critical kernel functionalities to > the userland, making it almost impossible to deal with when things go > bad (e.g. in single user mode). See also trouble ZFS has in single user > mode because it relies on files in the file system and a userland rc.d > script (hostid). It doesn't work anyway, since umass doesn't attach to device/vendor-ID. umass(4) is a interface class driver and attaches to each device containg a umass class interface independend of vendor/device-ID. There may be some exeptions for devices, which fail to supply the correct decriptor tables however, but the majority of supported devices are unknown to the driver. If you need ugen and umass, then fix ugen to attach even if another driver(s) already controls the device or some interfaces. This may be tricky, since ugen allows things that may break the expectations of other drivers, but we should have a solution for this problem anyway. Maybe we can live with this risk, while ugen is enhanced to do dafety catches - we have much more dangerous risks with USB right now, such as detaching mounted umass media. Not sure if HPS stack already handles the ugen vs. other driver problematic. AFAIK under Linux the generic userland interface allows claiming devices/interfaces from userland. It could be good idea for us as well and it would be good for libusb support as well. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with ldconfig
Hi Chuck, On 2/28/08, Chuck Robey <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > [snip RAID/loader interaction] > Well, the other thing that's come up, I can't get my nvidia driver to work > along with xorg. It used to show it's arrival both in kldstat, AND also > because, in /dev, a file named nvidiactl would show up. This has stopped > happening. I had been using the old version 100.14.19, and when I checked > the nvidia website, it seems a couple of newer versions had appeared, so I > downloaded and built version 169.12. Don't ask me why the crazy version > numbering, I looked around for something like a changelog, but had no luck. > Anyhow, updating to the newer version wasn't too hard, but didn't show any > change. Consulting the /var/log/Xorg.0.log file, even though kldstat says > that nvidia.ko is loaded, it never shows a /dev/nvidiactl, and the log file > says clearly that it never finds the Nvidia kernel module. Using it with > Vesa lets me limp, so I do that, but howcome? The nvidia kernel module now needs to be loaded at boot-time; it won't supercede the default vga support if loaded later. cat nvidia_load="YES"" >> /boot/loader.conf -Ben Kaduk > > OK, I'm not giving my ldconfig problem to you folks, its quite likely its a > FreeBSD-current problem, so let those folks handle that one. > > Boy, I feel like the little boy who cried wolf! > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.4 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHxylOz62J6PPcoOkRAudcAJ9ex65oZUoh+0gf/7WcpNi6KhwsxwCgje63 > m4GwVJZrkoU3McfHK1NAArk= > =wLpy > -END PGP SIGNATURE- > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umass: should the device specific information be moved from C code to the text file?
Peter Jeremy wrote: > This sounds like a nice idea - it's also a nuisance having to recompile > the kernel just to support a weird new USB device you've acquired. You can probably keep USB support as a module if you need to recompile it often :) On the original topic: please don't do that. Recent ultra-modern Linux systems have started offloading such critical kernel functionalities to the userland, making it almost impossible to deal with when things go bad (e.g. in single user mode). See also trouble ZFS has in single user mode because it relies on files in the file system and a userland rc.d script (hostid). signature.asc Description: OpenPGP digital signature
