Re: what would take to allow binary upgrade to amd64?
On Sun, May 30, 2010 at 4:30 PM, Eitan Adler li...@eitanadler.com wrote: On Sun, May 30, 2010 at 10:52 PM, Rob Farmer rfar...@predatorlabs.net wrote: On Sun, May 30, 2010 at 11:51 AM, Eitan Adler li...@eitanadler.com wrote: I know that attempting to change from i386 to amd64 is is not possible The proper procedure for such an upgrade is as follows: If the thought of reformatting your system is scary, because you don't have backups or aren't sure they are comprehensive or work, then solve that problem, rather than trying to invent workarounds to cover for bad system administration. It will serve you much better in the long run. This isn't my question. I know how to currently perform the upgrade. My question is a) is it possible in theory to allow binary upgrades to be done? and b) if yes how much work would it take? In theory, yes, it is possible; in practice, in limited scope, it is practical to do so. I have done it, and have the ability to do so at will. As for widespread use, the COMPAT_FREEBSD32 option needs to be fixed first, because as it stands now a 64bit kernel with a 32bit userland is not complete, for example, on 8.0, a 32bit ifconfig cannot set an ip address on an interface, because of ioctl incompatibility. This prevents the intermediate step of running a 32bit userland with a 64bit kernel (though it can be sidestepped by segregating the architecture specific parts of the userland). Full 32bit support on 64bit kernels has other, more widespread benefits then an after install sidegrade. Work is already moving in this direction, as it's a natural progression for architecture support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Enabling sound?
I don't get the pcm0 lines that section 7.2.2 in the manual talks about. cat /dev/sndstat returns: FreeBSD Audio Driver (newpcm) Installed devices: and nothing else. The driver isn't attached to the device, either because the pci id's don't match or the card isn't using an emu10k* chip. Please type pciconf -l -v and reply with the portion that matches the card. kldload snd_emu10k1 yields no output whatsoever. When followed by cat /dev/sndstat it produces the same outputs as above. kld_load snd_driver yields: ppc0: parallel port not found. sio1: configured irq 3 not in bitmap of probed irqs 0x20 sio1: port may not be enabled ppc0: parallel port not found. sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ppc0: parallel port not found. sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ppc0: parallel port not found. sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ppc0: parallel port not found. sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ppc0: parallel port not found. sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ppc0: parallel port not found. sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled This is because snd_driver kldload's EVERY known sound driver, including ones for ISA. Hence the use in the handbook of only using it to find the driver for your card. (Blind probing ISA is a quick way to crash an older machine) I recompiled with the sound and emu10k1 drivers commented out, and the kldload and cat /dev/sndstat commands still yield the same. compiling the kernel with those options is almost exactly the same as kldloading it after it boots. I need to get sound enabled on this box, so I can do some online training provided through streaming video. Please, please, please tell me I don't have to break down and install wankers on this thing ... pciconf -l -v will be the best bet, at least you'll have a better idea of what you're dealing with. isab0: PCI-ISA bridge at device 10.0 on pci0 . . . pci3: multimedia, audio at device 10.0 (no driver attached) IIRC, and I'm really not 100%, that the older emu10k1 cards used a pci-isa bridge to the actual device (I'm away from my machine with a working one of those cards, so I can't confirm that's normal, though I recall seeing that in dmesg). I've re-compiled my kernel yet again to remove the sio device, since this thing has no 8250 or 16[45]50 serial ports on it, which got rid of the error messages in dmesg I was seeing about the port not being enabled and the IRQ not mapping. It also has no parallel port on it -- can I remove the ppc, ppbus, lpt, plip, and ppi devices without breaking anything else? NO, you can't remove ppbus in 6.1 or any previous versions I've tried. And it's a quick way to kernel panic on boot (the note in the GENERIC kernel comments agrees with me, it IS required for i386 at least for now). The only peripheral ports this thing has on it are USB2. I'm pretty much stuck with a custom kernel on this machine, since the wireless network I'm on requires WEP, and the wlan_wep module would need to be loaded by hand if I went with the generic kernel and module loading ... which would also mean hand-starting dhcpclient and ifconfig, since both will fail at boot-time without wlan_wep. All the wireless stuff works just fine with ath, ath_hal, ath_rate_sample, wlan, and wlan_wep compiled into the kernel. You don't really need to do this, though it's irrelevant to the problem at hand. You can use/boot/loader.conf can load ko's at boot time before the kernel is loaded, /boot/defaults/loader.conf has examples at the bottom. typically it's module_load=YES You can also add a shell script to /usr/local/etc/rc.d/ that will load it and add a tunable in rc.conf that will enable/disable wireless on boot, just add a BEFORE: netif line. Use rcorder /etc/rc.d/* /usr/local/etc/rc.d/* to make sure your script is before netif (this will make sure the drivers are loaded before dhclient and everything else). The only thing I can't seem to get working is this blasted sound card. I wouldn't even worry about it if I didn't have to do this stupid flash based video training crap (why can't they just send me TFM so I can R it?!?). *sigh* I hope this helps, if you understand C and how pci works you can use the pci id output that pciconf provides and modify the #define EMU10K1_PCI_ID 0x00021102 line in /usr/src/sys/dev/sound/pci/emu10k1.c to match it, this will force the driver to try to bind to the card. This may not work, it's not supported, and definately DON'T link the driver to the kernel (ie, don't add a device snd_emu10k1 line to the kernel config) in the off chance it causes
Re: Enabling sound?
On 7/22/06, Rich Demanowski [EMAIL PROTECTED] wrote: Dylan Cochran wrote: I don't get the pcm0 lines that section 7.2.2 in the manual talks about. cat /dev/sndstat returns: FreeBSD Audio Driver (newpcm) Installed devices: and nothing else. The driver isn't attached to the device, either because the pci id's don't match or the card isn't using an emu10k* chip. Please type pciconf -l -v and reply with the portion that matches the card. Well, I'm still not getting any further. I pulled the SB Live! card out and enabled the on-board sound in the BIOS, to see if doing a kldload snd_driver would recognize *that*. It doesn't. The on-board sound shows up like this in pciconf -l -v: [EMAIL PROTECTED]:16:1: class=0x040300 card=0x2a3e103c chip=0x026c10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class= multimedia kldload snd_driver followed by cat /dev/sndstat yields: FreeBSD Audio Driver (newpcm) Installed devices: just like before. :( --- Information I can glean from looking at the SoundBlaster card: On the board: Sound Blaster Live! 24-bit Model: SB0410 On the chips: Creative CA0106-DAT LF (c) Creative Tech '02 C0524 KD692 Cirrus Logic CS4382-KQZ WAEXAR0452 WM WM8775SEDS 4AAADOG Everything else on there seems to be simple resistors, caps, and maybe a mosfet or three. Changing emu10k1.c so that the definition of EMU10K1_PCI_ID matches what pciconf -l -v found gets the module to recognize that there's a card there, and then it pukes on the ac97 stuff (which confuses me since this card claims to be ac97 compliant and the Cirrus chips is there ...) pcm0: Creative EMU10K1 port 0xcf00-0xcf1f irq 18 at device 10.0 on pci3 pcm0: AC97 reset timed out. pcm0: ac97 codec invalid or not present (id == 0) device_attach: pcm0 attach returned 6 Looking through sound/pcm/ac97.c I can see that the reset() function is failing, and the id = line in the ac97_initmixer() function isn't recognizing the chip on the board. I got a SoundBlaster Live! because it was listed as a known working piece of hardware. Apparently this is a newer version of the board that isn't supported yet. Getting it to work is becoming a PITA beyond what I have the time and willpower to put in right now. Is there a piece of sound hardware I can just run down to CompUSA and buy, that I can drop in here and get this thing working with *today*? Newer Audigy's use a completely different DSP chip then the older SoundBlasters. The SoundBlaster brand is so vague now with regard to the actual chips that it's misleading. The el cheapo CompUSA brand card is iirc a very old and generic chip, it's not the best quality wise but when I bought them months ago they seemed to work with everything I threw at them. In all honesty I don't remember testing them with FreeBSD, but it works out of the box with BeOS R5, so I'd assume FreeBSD comes with the driver. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A New FreeBSD Server
On 6/26/06, Bob Richards [EMAIL PROTECTED] wrote: [...] OK; Install successfully completed, want to add APPS? Sure! Why not! So I picked out some editors and shells I use all the time, and PORTS went out to get them. at this point, my DSL connecton went down! Damn! I reset the router, and back up. BUT An IP change occurred and the download from the FTP site never continued! I could do nothing except ABORT the install! So fine! I aborted. Since I had received the Congratulations on an Install message, I ASSUMED all I had to do was re-boot from HD and go to SYSINSTALL and complete the install. NOT! With packages installed from the ftp servers (not from the cdl; as the packages on the cd will generally match the package list at the time of disk fabrication), it's usually simpler to not install binary packages until after the first boot. sysinstall can be run at any time after the install and work fine (though not for disk slicing/labeling on the boot drive). It will not only 'solve' strange problems with regards to sysinstall's package error handling, but it will also let you multitask while the Really Big Meta-Packages (gnome, kde) download, which can take hours on some connections/servers. For reference, pkg_add -r portname (ex. pkg_add -r gnome) seems to be the canonical way to install binary packages from the web. sysinstall's a not-to-pretty hack of a binary that filled a need and was user friendly and stable enough, not really flexible beyond installing things off a dos partition or cd. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
