Re: weird-o-rama: Type5 keyboard suddenly becomes PC104 keyboard...
Thanks, all! The mouse is working now. The config that works for me (custom 2.6.8 kernel on an Ultra5 with Type 5 (actually, type 6 on KB) serial keyboard Crossbow serial mouse), if anyone cares, is Section InputDevice Identifier Sun Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons false EndSection When I had /dev/psaux as CorePointer, kdm caught Signal 11 refused to start up. No other discernable comments in kdm.log. I do have to unplug re-plug the mouse connector, though. Any thoughts on what's up with that? A minor annoyance, but since I'll be running this machine 24/7 anyway, it shouldn't be much of a problem for me. Thanks again. Dan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: weird-o-rama: Type5 keyboard suddenly becomes PC104 keyboard...
It's as though the Sun keyboard's firmware was reprogrammed to generate PC104 scan codes. That's completely normal behavior with 2.6 kernels (where the input layer was redesigned). So you're saying I should use the us (PC104) keyboard mapping even with the Sun type 5 keyboard on a 2.6 kernel? Let me give it a shot... See the post-halloween-2.6.txt doc in kernel source Documentation dir. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: weird-o-rama: Type5 keyboard suddenly becomes PC104 keyboard...
| So you're saying I should use the us (PC104) keyboard mapping even | with the Sun type 5 keyboard on a 2.6 kernel? Let me give it a shot... Any X keymap available ? This is what I used successfully in XF86Config-4 on a 2.4.27 kernel with the system (console) keyboard mapping set to sunkeymap: Section InputDevice Identifier Sun Keyboard Driver keyboard Option CoreKeyboard Option XkbRules sun Option XkbModel type5 Option XkbLayout us EndSection and this is what I'm using now, on a 2.6.8 kernel with the system (console) keyboard mapping set to us (pc104): Section InputDevice Identifier Sun Keyboard Driver keyboard Option CoreKeyboard Option Device/dev/input/event1 Option XkbRules xfree86 Option XkbModel pc104 Option XkbLayout us EndSection I'm pretty sure that the 2.4 kernel didn't even need a Device entry like the 2.6 kernel does. Or maybe I accidentally deleted it. In any case, I tried the 2.6 kernel's block with sun and type5, but the key mappings were all wrong. AFAIK this might be the best one can do, but I'm the one with the questions in ths case, not the answers... The keyboard seems to be working OK now (except, as noted above by Vincent Pelletier, for a possible lack of special Sun key functionality), but I can't get the Sun serial mouse going. I tried /dev/sunmouse, which is what the 2.4 kernel liked, as well as /dev/input/mice (which is what the 2.6 kernel likes for the USB mouse) and /dev/input/mouse0 : Section InputDevice Identifier Sun Mouse Driver mouse Option CorePointer Option Device/dev/input/mouse0 Option Protocol BusMouse Option Emulate3Buttons true EndSection None of these work. /dev/sunmouse maps to no existing device, and apparently neither of the other two (existing) devices above correspond to the Sun mouse. If anybody out there with a Sun serial mouse working under XFree86 4.0 and a 2.6 kernel could send me their mouse section (as above), or if anyone could tell me what device a Sun serial mouse maps to under X, I'd be grateful. Actually, maybe the Protocol section might be wrong also (maybe ImPS/2 rather than BusMouse?), so please correct me there if that's the case. Thanks. Dan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cannot boot 2.6.8 kernel from ext3 root partition on Ultra5
Sorry for the re-post, I left the subject blank the first time I sent this message... Perhaps his /boot was simply full? There were an awful lot of modules listed. Butwouldn't it be simpler to just compile the stuff in and be done with it? I mean, I understand why the installation kernel relays on initrd, but for a tuned, self compiled kernel, this isn't necessary. 'df -h' reports that /boot is only 26% full (22M out of 90M used). I was also wondering about the possibility of using an initrd-less kernel. Somewhere in the Xconfig/Kconfig option sequence, I remember reading in one of the help screens about initrd support that it's not really necessary in many cases. I guess this is a little beyond this message, but why does Linux need an initrd at all? Does it speed up the boot process? Or does it have something to do with compressing the kernel to fit onto a floppy (in which case, one would only need an initrd on a boot floppy, not the HD)? Or maybe it's got to do with having all the modules needed to boot in one handy place, in which case if one were to compile everything monolithically for a specific machine it shouldn't be needed? A URL explaining why linux uses initrds would be great... Daniel, could you attach ls -l /boot from your machine? www2# cd /boot www2# ls -l total 18223 lrwxrwxrwx 1 root root 1 2004-11-12 10:41 boot - . -rw-r--r-- 1 root root 18958 2004-12-16 10:07 config-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 23847 2004-08-24 02:50 config-2.4.27-1-sparc64 -rw-r--r-- 1 root root 20236 2004-12-27 17:52 config-2.6.810.1-dej-usb -rw-r--r-- 1 root root 29705 2004-11-28 00:08 config-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 1 2004-11-12 10:41 etc - . -rw-r--r-- 1 root root1024 2004-07-14 10:38 fd.b -rw-r--r-- 1 root root 512 2004-07-14 10:38 first.b -rw-r--r-- 1 root root1024 2004-07-14 10:38 generic.b -rw-r--r-- 1 root root 784 2004-07-14 10:38 ieee32.b lrwxrwxrwx 1 root root 31 2004-12-28 14:58 initrd-268 - boot/initrd.img-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 33 2004-12-28 09:39 initrd-268usb - boot/initrd.img-2.6.810.1-dej-usb lrwxrwxrwx 1 root root 33 2004-12-28 09:36 initrd.img - boot/initrd.img-2.6.810.1-dej-usb -rw-r--r-- 1 root root 1802240 2004-12-16 11:35 initrd.img-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 3358720 2004-11-12 10:40 initrd.img-2.4.27-1-sparc64 -rw-r--r-- 1 root root 2007040 2004-12-28 09:36 initrd.img-2.6.810.1-dej-usb -rw-r--r-- 1 root root 3620864 2004-12-28 14:55 initrd.img-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 32 2004-12-28 09:42 initrd-sun - boot/initrd.img-2.4.27-1-sparc64 lrwxrwxrwx 1 root root 35 2004-12-28 09:42 initrd-usb - boot/initrd.img-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root7184 2004-07-14 10:38 isofs.b drwxr-xr-x 2 root root 12288 2004-11-12 10:29 lost+found -rw-r--r-- 1 root root7680 2004-11-12 10:41 old.b -rw-r--r-- 1 root root 64000 2004-11-12 10:41 second.b -rw-r--r-- 1 root root 315 2004-12-28 18:13 silo.conf -rw-r--r-- 1 root root 420 2004-12-28 15:02 silo.conf~ -rw-r--r-- 1 root root 61405 2004-07-14 10:38 silotftp.b -rw-r--r-- 1 root root 478536 2004-12-16 11:31 System.map-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 495144 2004-08-24 04:46 System.map-2.4.27-1-sparc64 -rw-r--r-- 1 root root 798041 2004-12-27 19:38 System.map-2.6.810.1-dej-usb -rw-r--r-- 1 root root 801887 2004-11-28 01:18 System.map-2.6.8-1-sparc64 -rw-r--r-- 1 root root 512 2004-07-14 10:38 ultra.b lrwxrwxrwx 1 root root 30 2004-12-28 09:36 vmlinuz - boot/vmlinuz-2.6.810.1-dej-usb -rw-r--r-- 1 root root 1294079 2004-12-16 11:31 vmlinuz-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 1109207 2004-08-24 04:46 vmlinuz-2.4.27-1-sparc64 lrwxrwxrwx 1 root root 23 2004-12-28 15:00 vmlinuz-268 - vmlinuz-2.6.8-1-sparc64 -rw-r--r-- 1 root root 1274753 2004-12-27 19:38 vmlinuz-2.6.810.1-dej-usb -rw-r--r-- 1 root root 1265285 2004-11-28 01:17 vmlinuz-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 30 2004-12-28 09:53 vmlinuz-268usb - boot/vmlinuz-2.6.810.1-dej-usb lrwxrwxrwx 1 root root 29 2004-12-28 09:44 vmlinuz-sun - boot/vmlinuz-2.4.27-1-sparc64 lrwxrwxrwx 1 root root 32 2004-12-28 09:45 vmlinuz-usb - boot/vmlinuz-2.4.27-10.1-dej-usb www2# Thanks again. -Dan
[no subject]
Perhaps his /boot was simply full? There were an awful lot of modules listed. Butwouldn't it be simpler to just compile the stuff in and be done with it? I mean, I understand why the installation kernel relays on initrd, but for a tuned, self compiled kernel, this isn't necessary. 'df -h' reports that /boot is only 26% full (22M out of 90M used). I was also wondering about the possibility of using an initrd-less kernel. Somewhere in the Xconfig/Kconfig option sequence, I remember reading in one of the help screens about initrd support that it's not really necessary in many cases. I guess this is a little beyond this message, but why does Linux need an initrd at all? Does it speed up the boot process? Or does it have something to do with compressing the kernel to fit onto a floppy (in which case, one would only need an initrd on a boot floppy, not the HD)? Or maybe it's got to do with having all the modules needed to boot in one handy place, in which case if one were to compile everything monolithically for a specific machine it shouldn't be needed? A URL explaining why linux uses initrds would be great... Daniel, could you attach ls -l /boot from your machine? www2# cd /boot www2# ls -l total 18223 lrwxrwxrwx 1 root root 1 2004-11-12 10:41 boot - . -rw-r--r-- 1 root root 18958 2004-12-16 10:07 config-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 23847 2004-08-24 02:50 config-2.4.27-1-sparc64 -rw-r--r-- 1 root root 20236 2004-12-27 17:52 config-2.6.810.1-dej-usb -rw-r--r-- 1 root root 29705 2004-11-28 00:08 config-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 1 2004-11-12 10:41 etc - . -rw-r--r-- 1 root root1024 2004-07-14 10:38 fd.b -rw-r--r-- 1 root root 512 2004-07-14 10:38 first.b -rw-r--r-- 1 root root1024 2004-07-14 10:38 generic.b -rw-r--r-- 1 root root 784 2004-07-14 10:38 ieee32.b lrwxrwxrwx 1 root root 31 2004-12-28 14:58 initrd-268 - boot/initrd.img-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 33 2004-12-28 09:39 initrd-268usb - boot/initrd.img-2.6.810.1-dej-usb lrwxrwxrwx 1 root root 33 2004-12-28 09:36 initrd.img - boot/initrd.img-2.6.810.1-dej-usb -rw-r--r-- 1 root root 1802240 2004-12-16 11:35 initrd.img-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 3358720 2004-11-12 10:40 initrd.img-2.4.27-1-sparc64 -rw-r--r-- 1 root root 2007040 2004-12-28 09:36 initrd.img-2.6.810.1-dej-usb -rw-r--r-- 1 root root 3620864 2004-12-28 14:55 initrd.img-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 32 2004-12-28 09:42 initrd-sun - boot/initrd.img-2.4.27-1-sparc64 lrwxrwxrwx 1 root root 35 2004-12-28 09:42 initrd-usb - boot/initrd.img-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root7184 2004-07-14 10:38 isofs.b drwxr-xr-x 2 root root 12288 2004-11-12 10:29 lost+found -rw-r--r-- 1 root root7680 2004-11-12 10:41 old.b -rw-r--r-- 1 root root 64000 2004-11-12 10:41 second.b -rw-r--r-- 1 root root 315 2004-12-28 18:13 silo.conf -rw-r--r-- 1 root root 420 2004-12-28 15:02 silo.conf~ -rw-r--r-- 1 root root 61405 2004-07-14 10:38 silotftp.b -rw-r--r-- 1 root root 478536 2004-12-16 11:31 System.map-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 495144 2004-08-24 04:46 System.map-2.4.27-1-sparc64 -rw-r--r-- 1 root root 798041 2004-12-27 19:38 System.map-2.6.810.1-dej-usb -rw-r--r-- 1 root root 801887 2004-11-28 01:18 System.map-2.6.8-1-sparc64 -rw-r--r-- 1 root root 512 2004-07-14 10:38 ultra.b lrwxrwxrwx 1 root root 30 2004-12-28 09:36 vmlinuz - boot/vmlinuz-2.6.810.1-dej-usb -rw-r--r-- 1 root root 1294079 2004-12-16 11:31 vmlinuz-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 1109207 2004-08-24 04:46 vmlinuz-2.4.27-1-sparc64 lrwxrwxrwx 1 root root 23 2004-12-28 15:00 vmlinuz-268 - vmlinuz-2.6.8-1-sparc64 -rw-r--r-- 1 root root 1274753 2004-12-27 19:38 vmlinuz-2.6.810.1-dej-usb -rw-r--r-- 1 root root 1265285 2004-11-28 01:17 vmlinuz-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 30 2004-12-28 09:53 vmlinuz-268usb - boot/vmlinuz-2.6.810.1-dej-usb lrwxrwxrwx 1 root root 29 2004-12-28 09:44 vmlinuz-sun - boot/vmlinuz-2.4.27-1-sparc64 lrwxrwxrwx 1 root root 32 2004-12-28 09:45 vmlinuz-usb - boot/vmlinuz-2.4.27-10.1-dej-usb www2# Thanks again. -Dan
Re: Cannot boot 2.6.8 kernel from ext3 root partition on Ultra5
Joshua Kwan wrote: Is there a way I can copy/paste these messages? I used a good old fashioned pen and paper to write down the last six lines. I really would like to avoid using this method for the whole boot sequence, which is about 50 lines. You can use a serial console. Discussing how to do that is kind of out of the scope of this message, Google can help you out on that. Basically, though, all I need is stuff related to 'CMD64X' (if there isn't any, that is a problem) and IDE. Common sense should be enough to get what I need. :) I managed to scrape together some cabling for a serial console connection. The whole boot sequence, starting with OpenBoot, is shown below. Unfortunately, I don't see any reference to CMD64X (actually, no opccurrences of CMD! So what does this mean? Thanks. -Dan = = Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz), No Keyboard OpenBoot 3.15, 128 MB memory installed, Serial #11001011. Ethernet address 8:0:20:a7:dc:b3, Host ID: 80a7dcb3. ok boot Boot device: disk File and args: SILO Version 1.4.8 boot: linux-268usb Allocated 8 Megs of memory at 0x4000 for kernel Uncompressing image... Loaded kernel version 2.6.8 Error: initial ramdisk loading failed. No initrd will be used. Remapping the kernel... done. Booting Linux... PROMLIB: Sun IEEE Boot Prom 3.15.2 1998/11/10 10:35 Linux version 2.6.8-10.1-dej-usb ([EMAIL PROTECTED]) (gcc version 3.3.4 (Debian 1:3.3.4-13)) #1 Mon Dec 27 18:40:26 EST 2004 ARCH: SUN4U Ethernet address: 08:00:20:a7:dc:b3 Built 1 zonelists Kernel command line: root=/dev/hda2 ro PID hash table entries: 2048 (order 11: 32768 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 16384 (order: 4, 131072 bytes) Inode-cache hash table entries: 8192 (order: 3, 65536 bytes) Memory: 125736k available (2008k kernel code, 608k data, 144k init) [f800,17f3c000] Calibrating delay loop... 536.57 BogoMIPS Mount-cache hash table entries: 512 (order: 0, 8192 bytes) NET: Registered protocol family 16 PCI: Probing for controllers. PCI: Found SABRE, main regs at 01fe, wsync at 01fe1c20 SABRE: Shared PCI config space at 01fe0100 SABRE: DVMA at c000 [2000] PCI-IRQ: Routing bus[ 2] slot[ 1] map[0] to INO[11] PCI-IRQ: Routing bus[ 2] slot[ 3] map[0] to INO[18] PCI-IRQ: Routing bus[ 2] slot[ 3] map[0] to INO[19] PCI-IRQ: Routing bus[ 2] slot[ 3] map[0] to INO[1a] PCI0(PBMA): Bus running at 33MHz PCI-IRQ: Routing bus[ 1] slot[ 1] map[0] to INO[21] PCI-IRQ: Routing bus[ 1] slot[ 2] map[0] to INO[0f] PCI-IRQ: Routing bus[ 1] slot[ 3] map[0] to INO[20] PCI0(PBMB): Bus running at 33MHz ebus0: [auxio] [power] [SUNW,pll] [se] [su] [su] [ecpp] [fdthree] [eeprom] [flashprom] [SUNW,CS4231] power: Control reg at 01fff1724000 ... powerd running. usbcore: registered new driver usbfs usbcore: registered new driver hub VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 8192 bytes) devfs: 2004-01-31 Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x0 Initializing Cryptographic API Console: switching to mono PROM 80x34 rtc_init: no PC rtc found su0 at 0x01fff13062f8 (irq = 4,7ea) is a 16550A su1 at 0x01fff13083f8 (irq = 9,7e9) is a 16550A ttyS0 at MMIO 0x1fff140 (irq = 7134176) is a SAB82532 V3.2 ttyS1 at MMIO 0x1fff1400040 (irq = 7134176) is a SAB82532 V3.2 Console: ttyS0 (SAB82532) Using anticipatory io scheduler Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize loop: loaded (max 8 devices) sunhme.c:v2.02 24/Aug/2003 David S. Miller (davem@redhat.com) eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:a7:dc:b3 eth1: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:a7:dc:b3 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx usbcore: registered new driver hiddev usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 1024 buckets, 8Kbytes TCP: Hash tables configured (established 16384 bind 16384) NET: Registered protocol family 1 NET: Registered protocol family 17 VFS: Cannot open root device hda2 or unknown-block(0,0) Please append a correct root= boot option Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0) 0Press L1-A to return to the boot prom
Re: Cannot boot 2.6.8 kernel from ext3 root partition on Ultra5
Joshua Kwan wrote: Daniel E. Jonsen wrote: Allocated 8 Megs of memory at 0x4000 for kernel Uncompressing image... Loaded kernel version 2.6.8 Error: initial ramdisk loading failed. No initrd will be used. Well hello there! Does this happen when booting the Debian kernel, too? That would be your problem. But I see that this is with your custom kernel. Please send its .config file. Yes, this happens for all four kernels I have installed: Debian 2.4.27, custom 2.4.27, Debian 2.6.8 and custom 2.6.8. Actually, the one kernel I'm not sure about is the Debian 2.4.27, since I haven't used that one in a while. But that one puts up errors at the very beginning, complaining that it can't read the partition table. Probably doesn't have Sun partition table support. It boots OK, though, despite the complaints. When compiling the custom kernels, I configured myself using xconfig/kconfig, then did 'make-kpkg --initrd --revision=10.1 kernel_image' to do the compile. Everything APPEARED to go OK, and apparently it did if the Debian-supplied kernels are doing the same thing. The .config file for the custom 2.6.8 is attached as config-268-dej-usb, and just for kicks the debian 2.6.8 config is attached as config-2.6.8-1-sparc64. Thanks. -Dan # # Automatically generated make config: don't edit # CONFIG_64BIT=y CONFIG_MMU=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # General setup # CONFIG_BBC_I2C=m CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SMP is not set # CONFIG_PREEMPT is not set # CONFIG_CPU_FREQ is not set CONFIG_SPARC64=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_ISA_DMA=y CONFIG_SBUS=y CONFIG_SBUSCHAR=y CONFIG_SUN_AUXIO=y CONFIG_SUN_IO=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_RTC=y # CONFIG_PCI_LEGACY_PROC is not set # CONFIG_PCI_NAMES is not set CONFIG_SUN_OPENPROMFS=m CONFIG_SPARC32_COMPAT=y CONFIG_COMPAT=y CONFIG_UID16=y CONFIG_BINFMT_ELF32=y # CONFIG_BINFMT_AOUT32 is not set CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_SOLARIS_EMUL is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set CONFIG_PARPORT_SUNBPP=m # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y CONFIG_PRINTER=m # CONFIG_ENVCTRL is not set # CONFIG_DISPLAY7SEG is not set # CONFIG_CMDLINE_BOOL is not set # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m # # Graphics support # CONFIG_FB=y # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON_OLD is not set # CONFIG_FB_RADEON is not set CONFIG_FB_ATY128=y CONFIG_FB_ATY=y CONFIG_FB_ATY_CT=y CONFIG_FB_ATY_GX=y # CONFIG_FB_ATY_XL_INIT is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_SBUS is not set # CONFIG_FB_PCI is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # # CONFIG_MDA_CONSOLE is not set CONFIG_PROM_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_SUN8x16=y # CONFIG_FONT_SUN12x22 is not set # # Logo configuration # CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set # CONFIG_LOGO_LINUX_CLUT224 is not set CONFIG_LOGO_SUN_CLUT224=y # # Serial drivers # # # Non-8250 serial port support # CONFIG_SERIAL_SUNCORE=y CONFIG_SERIAL_SUNZILOG=y CONFIG_SERIAL_SUNZILOG_CONSOLE=y CONFIG_SERIAL_SUNSU=y CONFIG_SERIAL_SUNSU_CONSOLE=y CONFIG_SERIAL_SUNSAB=y CONFIG_SERIAL_SUNSAB_CONSOLE=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # # Misc Linux/SPARC drivers # CONFIG_SUN_OPENPROMIO=y CONFIG_SUN_MOSTEK_RTC=y CONFIG_OBP_FLASH=m # CONFIG_SUN_BPP is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD
Cannot boot 2.6.8 kernel from ext3 root partition on Ultra5
I have an Ultra5 that I've been running Sarge (testing - official snapshot 11/07/04, kernel 2.4.27). I downloaded and installed kernel-image-2.6.8-1-sparc64_2.6.8-5_sparc.deb, and also the corresponding source deb. I compiled my own custom 2.6.8 kernel and installed it. Both of the 2.6.8 kernels panic during boot-up. The following is the last 6 lines on the screen from an attempted boot: NET: Registered protocol family 1 NET: Registered protocol family 17 VFS: Cannot open root device hda2 or unknown-block(0,0) Please append a correct root= boot option Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0) 0Press L1-A to return to the boot prom When I use the Debian binary, I can press [Stop]-A to get back to the boot PROM, but when I use my self-compiled kernel, this does nothing - I have to use the hard power switch on the back of the CPU. Maybe this has something to do with the fact that I compiled Sun keyboard mouse support as modules (I want to use a USB KB mouse on a PCI USB card as the primary console)? My silo.conf looks like this: == root=/dev/hda2 partition=1 default=linux-usb read-only timeout=100 image=/vmlinuz-sun label=linux-sun initrd=initrd-sun image=/vmlinuz-usb label=linux-usb initrd=initrd-usb image=/vmlinuz-268 label=linux-268 initrd=initrd-268 image=/vmlinuz-268usb label=linux-268usb initrd=initrd-268usb == After booting into a 2.4.27 kernel, 'df -h' gives me this: == FilesystemSize Used Avail Use% Mounted on /dev/hda2 3.7G 2.7G 846M 77% / tmpfs 62M 0 62M 0% /dev/shm /dev/hda1 90M 22M 63M 26% /boot == In the Debian kernel, they have ext3 support as a module. In my kernel, I compiled it in monolithically. The only feature I don't have enabled is EXT3_FS_SECURITY. Everything else related to ext3 is enabled. Anybody out ther know what might be causing this? Any suggestions would be greatly appreciated. -Dan
Re: USB keyboard mouse on Sun Ultra 5 w/PCI USB card
After many attempts at trying to disable Sun KB mouse support in the Debian-supplied 2.4.27 source, nothing worked. First of all, with kernel 2.4.27, there are no options for Sun KB mouse support listed in xconfig. One has to manually edit .config to change these settings. Even after manually editing .config, I found that my settings were put back to monolithic support for the Sun KB mouse, presumably by the file (srcroot)/arch/sparc64/config.in which has some lines like define_boolean CONFIG_SUN_KEYBOARD=y etc. etc.. I changed these to define_tristate CONFIG_SUN_KEYBOARD=m etc. etc., and the compile failed exactly when looking for a routine called handle_keyboard_event or something similar. So apparently, the sparc64 port of the 2.4.27 kernel does NOT like to have Sun KB mouse support disabled. I then downloaded the 2.6.8 kernel source from Debian, and lo and behold! Sun KB mouse support are configurable from xconfig (kconfig). So I compiled up a lean, mean 2.6.8 kernel with Sun KB mouse support as modules. The compile went fine, but now I have a new problem, as explained in my new post, Cannot boot 2.6.8 kernel from ext3 root partition on Ultra5 (http://lists.debian.org/debian-sparc/2004/12/msg00174.html) Disable support for the sun keyboard or build it as a module but don't load it. BTW, Is there a way I can add something to, e.g., modules.conf (or one of the manual tweak files since modules.conf is auto-generated) in order to tell the kernel, never load the Sun keyboard module, even if you find a Sun keyboard attached? Thanks again. -Dan
Re: Cannot boot 2.6.8 kernel from ext3 root partition on Ultra5
Joshua Kwan wrote: NET: Registered protocol family 1 NET: Registered protocol family 17 VFS: Cannot open root device hda2 or unknown-block(0,0) Please append a correct root= boot option Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0) 0Press L1-A to return to the boot prom Could you paste the log _up to_ the VFS: Cannot open... message? You use an Ultra 5, so your initrd should be loading the 'cmd64x' module for the stock kernel, and it should work. Or do you use a different setup? Thanks Is there a way I can copy/paste these messages? I used a good old fashioned pen and paper to write down the last six lines. I really would like to avoid using this method for the whole boot sequence, which is about 50 lines. Again, I have to press [Stop]-A and do reset-all, or use the hard power switch on the back of the CPU. Can I still get dmesg-like output from failed boot attempts after flipping the switch? If so, how? If not, are there any key lines in the boot sequence that I should zero in on? I suppose if I really start to pull my hair out I could conceivably use pen and paper on 50 lines, but that would take me about an hour... Thanks -Dan
Re: USB keyboard mouse on Sun Ultra 5 w/PCI USB card
Sorry, all, about the long pause before responding. I really would like to kick this problem. In the last few days, I have had a chance to look at things a bit more closely. One thing I should say is that I am a total newbie to Sun hardware and OpenBoot, so please keep this in mind. In response to Martin's message, before I sent the first message, I didn't really know where to start, so I didn't really DO that much, but I did a lot of poking around. I ran config-debian and reconfigured the X11 settings in an attempt to use a PC104 USB keyboard (PC104 rules) instead of the Sun (type 6) keyboard (sun rules). That did absolutely nothing. Also, I want to be able to use the USB keyboard in runlevel 3, which I intend to make the default once everything is running smoothly. I also poked around in OpenBoot, and I see three entries for the USB board itself, but no devices on the USB bus, so I am skeptical about the prospects of using OpenBoot to remap the keyboard and mouse aliases to the USB devices. I also poked around in the /dev directory (not /proc !), looking for something that looked like the USB KB mouse, so that maybe I could mention them in XFree86Config-4. Again, nothing useful. With the USB 2.0 CD-RW drive attached, I get Exhibit #1 below when I run 'cat /proc/bus/usb/devices'. I don't see anything resembling a keyboard or mouse. My kernel version is 2.4.27, compiled from kernel-source-2.4.27_2.4.27-5_all.deb. In response to Blars' message, I find the serial console concept intriguing. Could you point me to a website or two that explain how to set it up, the necessary cabling required (straight-through vs. crossover, DB9-DB9 or DB9-DB25, pinouts would be nice), the comm parameters (I think I saw this in OpenBoot), etc. etc In response to Jeremy's message, I re-compiled the kernel 3 times, again, from kernel-source-2.4.27_2.4.27-5_all.deb. The first time, I tried to compile it manually (make xconfig, make dep, make, make install, make modules_install), but that didn't work - I'm not sure how to go about creating the initrd image. The second and third times, I used the kernel-package package, and everything went great with the compile and the install. The first time, I set the (relevant) lines in .config (mostly using 'make xconfig', some I had to do manually) as shown in Exhibit #2. That didn't work. The second time, I used the .config parameters shown in Exhibit #3 below. That didn't work either. I just noticed, in the USB HID section that I didn't have CONFIG_USB_HIDDEV set, but I gather from the explanation of it in xconfig (something about raw devices that aren't true HID devices) that it's probably not necessary. If I'm wrong, please let me know. In all future compiles, I will have this flag set to Y. I also noticed, upon looking at .config in the root source directory after running make-kpkg, that several parameters were automatically set, as if they are not optional or are required by some other flag that I still have set. The parameters that were flipped are shown in Exhibit #4 below. You might notice that those were the key options that I was TRYING to nix. After noticing this, I looked in the top-level Makefile and Rules.make for anything which would say that those flags are mandatory. No such luck. Is there something else I need to do to override these flags? Maybe I need to nix CONFIG_SUN_CONSOLE, CONFIG_SUN_AUXIO, and CONFIG_SUN_IO as well? Or maybe just CONFIG_SUN_CONSOLE as it seems to me now? If flag interdependency isn't the issue, where else should I look in order to override this rather draconian behavior of auto-setting these flags? BTW, Jeremy, did you do your recompiles on a 2.4 kernel or a 2.6 kernel? I've been trying to avoid 2.6 kernels for several reasons, but if it is NECESSARY for this to work, I might reconsider... Again, all, thanks for bearing with me, and any further info. would be greatly appreciated. -Dan === Exhibit #1: 'cat /proc/bus/usb/devices' === T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 1 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB OHCI Root Hub S: SerialNumber=280a000 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB OHCI Root Hub S: SerialNumber=2808000 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2
USB keyboard mouse on Sun Ultra 5 w/PCI USB card
I recently inherited a Sun Ultra 5 from my company which I would like to use as a LAMP server. I downloaded the 13-CD sarge testing distribution (official snapshot 11/07/04) and got the system up and running normally with the Sun keyboard and mouse. I have it connected to a 4-port USB KVM switch, and I bought and installed a Belkin F5U219 3-port (2 external, 1 internal) USB 2.0 PCI card so that I can use the USB keyboard mouse instead of the Sun keyboard and mouse, which I would really like to get off of my desk. For the life of me, I cannot get the sparc to accept input from either the USB keyboard (Microsoft Internet Keyboard Pro) or the USB mouse (Kensington Expert Mouse Pro). When I plug in an external USB 2.0 CD-RW drive and type cdrecord --scanbus the CD-RW drive shows up just fine. Thus the USB subsystem appears to be functioning in general. On bootup, I also get plenty of messages indicating that the kernel found a USB keyboard and mouse. Under the double lines below is an excerpt from 'dmesg' that looks relevant to me. Does anyone out there know how to get a Sun Ultra 5 to accept input from a PC104 USB keyboard and a USB mouse? Any hints would be greatly appreciated. -Dan = Excerpt from 'dmesg': = PROMLIB: Sun IEEE Boot Prom 3.15.2 1998/11/10 10:35 Linux version 2.4.27-1-sparc64 ([EMAIL PROTECTED]) (gcc version 3.3.4 (Debian 1:3.3.4-7)) #1 Mon Aug 23 23:59:55 PDT 2004 ARCH: SUN4U ... PCIO serial driver version 1.54 su(mouse) at 0x1fff13062f8 (irq = 4,7ea) is a 16550A Sun Mouse-Systems mouse driver version 1.00 su(kbd) at 0x1fff13083f8 (irq = 9,7e9) is a 16550A Sun TYPE 5 keyboard detected without keyclick SAB82532 serial driver version 1.65 ttyS00 at 0x1fff140 (irq = 12,7eb) is a SAB82532 V3.2 ttyS01 at 0x1fff1400040 (irq = 12,7eb) is a SAB82532 V3.2 ... usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb.c: registered new driver usbmouse usbmouse.c: v1.6:USB HID Boot Protocol mouse driver usb.c: registered new driver usbkbd usbkbd.c: :USB HID Boot Protocol keyboard driver mice: PS/2 mouse device common for all mice ... usb-ohci.c: USB OHCI at membase 0x1ff02808000, IRQ 10,7d8 usb-ohci.c: usb-02:03.0, PCI device 1033:0035 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected usb-ohci.c: USB OHCI at membase 0x1ff0280a000, IRQ 10,7d9 usb-ohci.c: usb-02:03.1, PCI device 1033:0035 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 1 port detected ehci_hcd 02:03.2: PCI device 1033:00e0 ehci_hcd 02:03.2: irq 10,7da, pci mem 01ff0280c000 usb.c: new USB bus registered, assigned bus number 3 ehci_hcd 02:03.2: USB 2.0 enabled, EHCI 1.00, driver 2003-Dec-29/2.4 hub.c: USB hub found hub.c: 3 ports detected eth0: Link is up using internal transceiver at 100Mb/s, Full Duplex. usb.c: registered new driver hid hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik [EMAIL PROTECTED] hid-core.c: USB HID support drivers ip_tables: (C) 2000-2002 Netfilter core team sunmouse: Successfully adjusted to 1200 baud.
