Jump to content

Glitz

Members
  • Posts

    402
  • Joined

  • Last visited

Posts posted by Glitz

  1. I installed the iso file to a U.S.B. stick and booted into the liveCD option. Everything worked. I chose to install the operating system to a SATA hard-drive partition. I opted to install the GRUB boot loader to pclinuxos's root partition as I have a boot loader already in the MBR. I couldn't boot, however.

     

    I then booted back into the liveCD option to try to install GRUB via the command line. I did:

     

    (as root user)

    Grub

    find /boot/grub/stage1

    root (hd1,7)

    setup (hd1,7)

     

    as the root partition is on sdb8. This did not work. I also tried

    grub-install /dev/sdb8

     

    Any ideas?

     

    What bootloader do you have in the MBR? This is what the BIOS will boot. Somehow you have to get that bootloader to boot linux.

     

    Glitz.

  2. This is just a quick tip on getting digital audio out working on the SBlive! and possibly other soundcards especially with the ALSA system.

     

    In KMIX (with SBlive! soundcard):

     

    Make sure the following settings in the Switches section are set properly:

    1. IEC958 Optical Raw -> Unless you are using a fiber optic cable make sure this is deselected.

    2. SB Live Analog/Digital Output Jack -> Make sure this is selected.

     

    Note that the regular sound volume controls no longer have any effect. You have to use the ones in the Input section. eg. Surround, Synth, Wave. For digital CD input use IEC958 TTL. For analog CD input set Capture to about the fifth tick (more tends to introduce distortion) and use the AC97 slider in the Output section. Make sure the volume controls are not set to zero.

     

    This will ensure that audio data is being sent out of the SPDIF port.

     

    Now, it may happen that you still have no sound. Or, it can happen that the sound works fine but TOTEM (or some other video program) was using the AC3 passthrough option and it crashed, leaving you with working AC3 passthrough but no sound otherwise. This is annoying, and contrary to what you might find on the internet, does not require a re-install of linux. After reading many, many manpages, I figured out what was happening and how to fix it.

     

    Quick technical aside: Data piped out of the digital port to a receiver requires header information for the receiver to know how to interpret the signal. The soundcard automatically appends this data to the LPCM signal output from the soundcard. However, when invoking AC3 passthrough mode, the soundcard is disabled from attaching this header since the AC3 data already has the necessary headers for the receiver. It then just passes the data unaltered. When AC3 passthrough mode is enabled and the video player crashes, it tends to stay enabled and does not get switched back again (even if you load up the player again and then exit). And so the LPCM data gets no headers attached and the receiver doesn't have a clue what to do with the data.

     

    Now, how can you tell if this has happened? From a command console run:

     

    iecset

     

    You will get some output that looks like this:

     

    Mode: consumer

    Data: audio

    Rate: 48000 Hz

    Copyright: permitted

    Emphasis: none

    Category: PCM coder

    Original: original

    Clock: 1000 ppm

     

    In particular, note the field that says "Data: audio". If it says this then headers are being added and you should have sound. If it says "Data: non-audio" then no headers are being added to the output (it is in AC3 passthrough mode).

     

    To change this flag use the following command:

     

    iecset audio 1

     

    You should now have sound.

     

    If you still don't have sound then as a last resort open up System->Configuration->Configure Your Desktop and select Sound->Sound System. From here select "Test Sound". If no sound is heard then deselect "Enable the sound system". Press apply and then Reselect "Enable the sound system". Press apply one more time and the select "Test Sound". If you still don't hear anything then something else is wrong and I'm afraid I can't help you any further.

     

    Good Luck!

  3. I've been using a Mandriva 2006 64 bit install as my main system for about a year now. There are still a few things you can't find on the 64 bit version (eg. codecs) that would be nice but you can run 32 bit programs as well (or so they say). The installer does get confused sometimes and tries to fill dependencies for x86_64 programs with i586 packages, even though 64 bit ones exist. The linker and makefile system also get confused if your compiling source code and they try to link in 32 bit libraries instead of the 64 bit versions if both exist on the same system. This is especially problematic with a site such as PLF.

     

    When installing packages, if such a conflict occurs, you can first install the 64 bit versions of any problem packages and then try again to install the package you originally wanted.

     

    As for crashes and things of that nature, I have had no problems. The Nvidia drivers work great.

     

    I'm hoping that 2007 will fix some of these issues.

     

    Glitz.

  4. Actually, TS in this case stands for Transport Stream. An MPEG TS file is one that combines several video mpeg and audio streams together with time synchronization information. This is the native format of cable and over-the-air HD broadcasts in North America. PES stands for Program Elementary Stream and is usually either a single video stream or a single audio stream. PS stands for Program Stream and may contain one or more PES streams (usually a video stream and its accompanying audio stream).

     

    I typically record raw MPEG TS files from over-the-air HD programs to DVD or DVD DL disks and then play them back on my HD TV using Kaffeine.

     

    Glitz.

  5. I have been battling with the LILO timestamp mismatch problem for about a week now (LM10.0 on an Epia M10000). I don't know if your problem is the same or not but maybe my experience will help.

     

    I have been duplicating disks in an embedded system by booting from /dev/hdd and copying to /dev/hda (for reasons that will not become any clearer right now) and when I have two drives in the system I often get this error. I also get this error when I have two flash disks in the system. This time on /dev/hda and /dev/hdc. However, I never get the problem if one of the two devices is blank. Additionally, when having multiple possible disks to boot from in the system at the same time, the BIOS does not honor the order in which I place the boot devices. In fact, I believe it simply boots off the first partition marked bootable going in the order /dev/hda, /dev/hdb, /dev/hdc, then /dev/hdd. That last bit seemed to be the clue I needed. From what I could tell, it would load the first boot sector off the disk from the proper drive but would not assign that drive to 0x80. This meant that when LILO tried to continue the boot process using BIOS drive 0x80 it would in fact load LILO's second stage boot off of the other disk and hence there is the timestamp mismatch.

     

    As far as I can tell, the problem is with the BIOS, but I've found a clever work around. Simply disable all drives in the bios except the boot drive. This way the BIOS has no choice but to keep the drive as 0x80. For linux this is not a problem since it does its own scan during bootup to determine what devices are connected. So far, this works like a charm.

     

    In your case, the problem is a little different but probably produces the same result. What partitions do you have marked as bootable in the partition table? I suspect that there may be more than one thus causing the BIOS to load the boot sector from one partition and then assign drive 0x80 to a completely different partition (one with another copy of LILO on it).

     

    Then again, I could be completely wrong about your case ;-) But I hope that this might at least provide a clue.

     

    Glitz.

     

    PS. By the way, if you haven't already guessed, the LILO timestamp error occurs when the first boot sector and the rest of LILO have different timestamps.

    PPS. I don't know if GRUB used the BIOS to access drives at all. This could explain why it doesn't run into these sorts of problems.

  6. Sorry, I can't help you but for what it's worth you're experiencing the chicken and egg problem. I installed LM9.2 on a 512MB bootable USB flash drive. The bios loads the boot sector just fine. After that, however, LILO doesn't have USB drivers to access the flash disk (it gets as far as LI). Booting off a hard drive and telling LILO that your system is on a USB key doesn't help either. It manages to load the kernel off the USB key but the kernel drivers for USB access can't be loaded (since they are on the USB drive) so the kernel panics. I've heard of a kernel patch for thiis but I've had no luck locating this.

     

    Good luck,

     

    Glitz.

  7. It might be worthwhile to just chuck the Dell SB Live! card and purchase a barebones OEM SB live! 5.1 for $35CDN (approx. $25US).

     

    I recommend a card with a copyright notice of 2002 or earlier. The 2003 version is not properly recognized in the ALSA version that comes with LM9.2. It may be properly recognized in the ALSA version that comes with LM10.0.

     

    Glitz.

  8. Turn based RPG's (eg. Wizardry series), turn based strategy games (eg. Master of Orion series), text adventure games (eg. Zork series, Suspended, Starcross), and old arcade games (eg. Pacman, Puzzle Bobble, Lode Runner).

     

    Glitz.

  9. It's been a while since I've had to specifically compile Linksys drivers for Linux (over 4 years) but back then they had instructions on their site for how to compile and install them. I think it took some digging to find them but they were there. I'm sorry I don't have the link bookmarked anymore.

     

    Good Luck!

     

    Glitz.

  10. I didn't recompile (I still have my previously compiled attempt).

     

    When I try to 'make install' the following errors occur:

     

    depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o

    depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/saa7108e.o

    depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/saa7111a.o

    depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/saa7113h.o

    depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/tuner.o

    depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/tvaudio.o

    depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/tvmixer.o

    depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/tw98.o

    depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/vpx32xx.o

     

    If I then do 'modprobe rivatv' the following errors occur:

     

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol i2c_master_send

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol proc_root_driver

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol __wake_up

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol proc_symlink

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol kernel_flag_cacheline

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol pci_free_consistent

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol create_proc_entry

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol i2c_bit_del_bus

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol video_register_device

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol remove_wait_queue

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol video_unregister_device

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol i2c_bit_add_bus

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol pci_alloc_consistent

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol remove_proc_entry

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol add_wait_queue

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol i2c_master_recv

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol mem_map

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol irq_stat

    /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol vmalloc_to_page

    modprobe: insmod /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o failed

    modprobe: insmod rivatv failed

     

    Glitz.

  11. I have an idea of what your shooting for but your missing a few things also.

     

    First will you ever point the bios to anything other than the hard drive?

    If nothing is in my MBR like on a new drive we're stuck right here now.

    If so then it needs to have keyboard support before it points to the boot device. That way you can tell it were to boot from. Now what kind of keyboard. PS2 or USB. Well now it needs to know about PS2 and USB devices.

    If it also points to a floppy drive it needs to know about those and how to use them. And what kind of floppy drive will that be?

    What if I want to boot my machine from the cdrom to load my linux OS.

    What if the owner wants to boot from a USB device. Good thing it already knows about those things.

    What about a diskless machine? You know, boot from the network.

    What about booting from a riad device. They are different than the normal IDE or even SATA.

    What about memory maping? Can't load an OS without knowing how much memory you have to play with.

    You also have to have built in error detection of some sort. And a form of error output so you have an idea of whats wrong. Maybe some kind of simple beep that can tell you by beep code.

     

    Now you see we're right back to the same old AT style of bios that we already have. Unless all computers in the future are not upgradable in anyway. Changing the boot devices in anyway totaly screws up the old bios, unless flexability is written in.

     

    Just how many of us have ever left a computer unupgraded?

     

    Oh my god a flash bios? Can we say LG drive here.

    I said it would be possible to boot Linux, I didn't claim it would be a luxury liner. Obviously the more assorted the peripherals are, the more boot devices you have to configure into the bios.

     

    Adding a bit of code for keyboard input and text screen output is not difficult. Memory management is not a problem since the x86 line of processors boot in real mode. The memory management starts when the second stage or third stage bootloader runs. They can also configure the majority of the hardware or else let the OS do it.

     

    If you always have a hard drive available then the code to boot from you're super deluxe widget could be loaded off the hard drive instead of putting it in the bios.

     

    Maybe the point I'm trying to get across here is that bios's main purpose is to load in enough code from some larger device so that booting can continue from the code on that device. In this way, the booting process can be customized without relying on any one person's code. As long as the bios can read in a bit of your own code, then you are home free to load any OS you want.

     

    Obviously, the bios will have to have the ability to boot from at least one removable device so that a fresh OS can be installed. Again, more supported devices are like car accessories.

     

    The technology used to hold the bios is irrelevant. The only criteria is that it can be directly accessed by the CPU at powerup. The LG fiasco had nothing to do with the type of memory used to hold the code. The problem was that the code was buggy. Had the defective code been burned into EPROM then the only difference would have been that it would not have been repairable without physically swapping the chip.

     

    But think about the advantage of flash. You could compile a bios like a Linux kernel and configure it to boot from the devices you want. This could then be written to the flash. The small protected boot block of the flash could be used to provide a primitive method of reflashing the device from a floppy drive or CDROM (or some other device on the machine) should the rest of the bios be corrupted or unprogrammed.

     

    It seems there are as many ways of starting a computer as there are grains of sand on a beach. There may be one optimal solution but you are unlikely to find it. There are probably a few excelent ways of doing it. There are most likely many ways of doing it well. There are many, many ways of doing it adequately. And there are infinitely more ways of doing it badly. Take your pick.

     

    Glitz.

  12. Glitz: You're right - but with all the RAID and other modern configurations the BIOS'es do need enough in 'em, right? (Otherwise there wouldn't be a need to revamp / re-write it)

    Yes, you do have to have enough code in the bios to be able to read the second stage boot loader off of whatever devices you intend to boot from. However, you don't really need any more than that. In fact, with flash bioses, you could almost customize the bios to boot off of whatever device you install the OS to at the time you install the OS. The OS could install it's own bios. Hmmm, that's an interesting idea...

     

    People, however, love to fill programs up with all sorts of eye candy (hardware candy?). At any rate, the point is that in the grand scheme of things, as soon as you have the second stage boot loader loaded, then the bios is no longer required. Or to put it another way, as long as the specs to the hardware are known (and they are) then the bios is not some kind of magic key to the system that one person (company) can control.

     

    Mind you, a bios full of "hardware candy" to configure and provide nice standard interfaces to the hardware (for the OS) is nice. It means less hardware driver programming for you. That's what makes it appealing. Linux programmers, however, have so far ignored the bios for the most part. As far as I know, only LILO (maybe GRUB) and the ACPI (and APM) driver uses it. Oh, the bios will also partially configure the PCI cards if you let it (I think Linux can do that by itself now fairly competently).

     

    Glitz.

  13. How would I boot to floppy to load my favorite OS?

     

    Personally that just sounds like a viri problem waiting to be started.

    Booting from floppy is virtually identical to booting from a hard disk. You read the second stage boot loader from the boot sector on the disk and that loads in the rest. In fact, that is exactly what happens now when you boot from floppy.

     

    As for the virus thing, well, if you put viruses on your MBR or boot sector then what do you expect? The way to prevent viruses from placing themselves there is to make sure the OS doesn't allow them to put themselves there in the first place.

     

    Glitz.

  14. Exactly. Send the command over the ATA bus to read the MBR, stick the code in the MBR in the RAM, and branch to it. Instant bios. After that point, the operating system can be in complete control and no more bios calls should be required. Get the ATA spec, write a bit a assembly code and burn it into an EPROM or flash chip. Instant bios. All the rest of the functions normally found in the bios can be part of the OS during or after booting.

     

    You just need enough code in the bios in order to read the second stage boot code off the hard drive. After that, it is up to the second stage boot loader to read in the rest.

     

    Glitz.

  15. The Athlon 64 FX and Opterons are both socket940 chips. The Athlon 64 is a socket754 chip.

     

    If you really want to buy an AMD system then you might want to check AMD's site for recommended motherboards. Select the chip you are interested in, then select "system component information", and finally (on the right) select "recommended motherboards". AMD also recommends to check the motherboard manufacturer's site to determine what memory has been tested to work with the board. This is very important.

     

    Glitz.

×
×
  • Create New...