Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I've installed Linux a couple times before, and something would always happen and I'd mess up the MBR to where I couldn't boot up my computer. So this time around, I'm not messing with the MBR and just going to go the safe route with booting through a floppy.
I recompiled the kernel by adding some sound support through xconfig (it actually says gconfig when it runs, who knows lol). When I do that, am I incorporating those modules into the kernal itself, or is it accessing something like /etc/rc.d/rc.modules and just adding modprobe lines?
And I'm assumming that putting modules into the kernel itself is faster than modprobe-ing them individually?
Correct, when you use x or g config, and select an item, most items can be selected either as 'M' for module, and usually a checkmark or something for 'compiled-in'. If the difference is either a dot or a check, then the dot means module, and the check means compiled in.
If you use make 'menuconfig' instead of make xconfig, then items with a < > beside them can be made as modules, as opposed to items with [ ] beside them, which can usually be modules OR be compiled right in.
With modules, the modules get compiled as little chunks, and will be put into /lib/modules/<kernel-name>/, and will be loaded either by script, manually, or by hotplug on 2.4 kernels, or by udev on 2.6 kernels.
When they are compiled in, they are actually built-into the kernel. No loading required.
If I had to guess, logically it would seem that having them compiled statically into the kernel would be the faster way of doing it, but probably not noticably faster to the naked eye, so to speak.
Last edited by GrapefruiTgirl; 03-20-2007 at 06:50 PM.
OK, each option has a help, or a blurb about it, which *usually* can tell you if you need it, should have it, dont need it, etc.
the RTC is optional, but as I recall you can add it, and if your machine doesn't have a use for it, linux will default to not using it.
Installing everything you want into the kernel is not harmful, will not noticeably slow anything down, won't bother LILO, and is better than not loading enough stuff. I actually prefer loading everything into my kernel too. The main reason people make modules is to conserve space by making the kernel smaller, for example if they plan to install the kernel to a floppy, or run it on a machine with like no memory. Also, if you were to want this kernel to run on a variety of different machines, you would select loads of modules for everything, but compile in the absolutely needed ones. It is better to err on the side of caution, ie putting extra stuff in, rather than missing something. NOTE: You MUST compile in the support for your IDE chipset, and the type of filesystem that your root is mounted on. So if you use IDE/ATA hard disk with the root system as an EXT2 filesystem, those things MUST be built in, because at the early stage of booting, the kernel has no modules in it yet, and cannot load modules, for a filesystem if it doesn't yet know how to read that filesystem. Get it? .
LOL, it wont blow up your machine It will either run perfect, run not perfect, or not boot or work properly. But it wont blow up.
If you are using xconfig, the second option from the very top of it all, you can go into and 'name your kernel' with an extension to its release number. I usually tack on the date, with an additional hex character if I make more than one in the same day, so my current kernel for example is called 2.6.20-fe19-0e. The 0e tells me it is the 5th version of the kernel I made originally on Feb 19.
When you are all done, Select FILE at the top menu, and save the config as something you recognize. THEN, after that, press the little disk picture, to save the .config file.
Every time you run xconfig and save it when done, it will save a new version of the file .config, which is what 'Make' uses to build the kernel.
Last edited by GrapefruiTgirl; 03-20-2007 at 08:08 PM.
Something else you should research, is what sort of hardware monitoring sensor chips are present on your motherboard.
There is a tool called lm_sensors which can help do this. Alternatively, you can physically investigate the board, or get a data sheet/spec sheet for the boatd from the manufacturer.
This allows you to enable support for system temperature, fan speeds, CPU temperature, etc etc.. Could come in handy when one day the CPU fan dies and the CPU starts to overheat. The sensors monitors can warn you or shut the machine off.
Hmm, I don't remember you posting that about the Jump drive.
What's a Jump drive anyways?
First, if it didn't mount the device, verify by reading /var/log/dmesg that the device was detected during boot.
Second, Verify that /etc/fstab lists the device correctly, ie that it has the correct name.
Third: Is that a USB device?
and Fourth: Did you get screen display this time during boot? If not, then you are missing either the module(s) needed by your video hardware, or a suitable frame-buffer device, in your configuration.
lol yes I got the screen to boot, with two Tux's at the top! Woo!
yes, the Jump Drive is a USB Mass storage device
There is this "usbfs" and "sysfs" when I type "mount"
Here is everything from dmesg pertaining to USB:
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 18, io mem 0xffa80800
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 16, io base 0x0000ff80
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000ff60
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 20, io base 0x0000ff40
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000ff20
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usb 1-7: new high speed USB device using ehci_hcd and address 4
usb 1-7: configuration #1 chosen from 1 choice
usb 4-1: new low speed USB device using uhci_hcd and address 2
usb 4-1: configuration #1 chosen from 1 choice
usb 4-2: new low speed USB device using uhci_hcd and address 3
usb 4-2: configuration #1 chosen from 1 choice
usbcore: registered new interface driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 4
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
I disabled SCSI from the kernel, because I don't have anything SCSI, but now that I think about it, USB is SCSI isn't it?
Umm.... USB is not SCSI, no. However, your drive may be SCSI protocol, but plugged into USB.
Not sure on that option. I have also disabled all SCSI stuff, but I don't have any USB things currently in use to test it out.
I think you are safe w/o SCSI, because the USB options are clearly specified in the config.
AND.. YOU GOT TWO TUXES!?!?!? Bwaahahahah I want 2 Tuxes How the heck you did that??
And from what I see in your dmesg, everything is detected properly, it looks very good Nice job!
I see USP Mass storage device, and a USP printer (do you have one of them?)
And I see that it actually is using SCSI-emulation for the USB storage devices at scsi-0. interesting.
Hmmmmm.. I'm trynna think of what to do next for the USB drive, while the coffee boils..
Could you be missing something else from the .config, that might be needed to mount the drive?
Far as I can tell, the machine has no trouble seeing the drive.
And which device is claiming to have no DMA?
You can enable DMA manually if it isn't coming on by default. Also, there's BIOS settings for DMA usually too.
As for enabling DMA, in a console type 'hdparm' and you will get a list of settings you can apply to a drive or CD/DVD device. DMA=ON is one of them.
The format for hdparm is usually 'hdparm -X -# /dev/ds1' where X, # and ds1 are whatever command, number and device.
Last edited by GrapefruiTgirl; 03-20-2007 at 09:24 PM.
All I have to say for that dma thing is if it ain't broke, dont fix it. I don't see anything not drive working, other than the USB. does 184.108.40.206 not use /dev/sda for a usb drive? Did they switch it to that other one?