Re: Status of Debian on Sun Blade 150
I don't think I can necessarily help with your parted issue. I just wanted to say that I was amazed with your creativity and patience in creating this special installation, and that I was impressed with your diagram of the disk. Also, the black magic you described in your e-mail to get this all to work was well thought out and very hilarious. It reminded me of what I did at work today: A few weeks ago, I spent half of a workday fighting with the Xerces-C++ XML processing library which we need for validating some integration data files. I was trying to get it to compile on Solaris 2.9 in 64 bit mode with GCC/G++ instead of the officially supported (but expensive and not installed by default at work) Sun Forte. Their pre-GNU-configure build script performs some disturbing mungefest on some environment variables, inserting some secret values that GNU-configure uses to configure the build. Of course, the secret values that work right for Forte don't work well at all for GCC/G++. Not surprising. So, today, I spent half of a day reverse-engineering the secret values, then making some educated guesses at what GCC/G++ and GNU-configure might prefer that they be. Amazingly, it built right on the first try! However, ironically, when I tried to redo the build with optimization, it failed. I believe I figured out why. Firstly, GNU-configure makes some changes to the tree that make distclean does not fully reverse. Secondly, I moved the directory to a different volume between compilations. I believe that this broke some of the directory paths that GNU-configure hardcoded into the source tree someplace. Tomorrow I'll fix it all (at least everything always seems to work right on Fridays at my job) and make it happy again. One philosophical question. Does the fact that I am demented enough to figure out how this sick and twisted build system works lead to the need to question my own mental state? I wondered about this on the way home this afternoon. Anyhow, thanks for motivating me to write this funny story down. --- Wiktor Wandachowicz [EMAIL PROTECTED] wrote: Jurij Smakov wrote: Everyone is working towards the same goal here, so let's not get too picky about the choice of words. Thanks for bringing me back to my senses. Let's focus on the topic. # fdisk -l /dev/hda Disk /dev/hda (Sun disk label): 16 heads, 255 sectors, 19158 cylinders Units = cylinders of 4080 * 512 bytes Device FlagStart EndBlocks Id System /dev/hda1 258 319124440 83 Linux native /dev/hda2 0 2585263203 SunOS swap /dev/hda3 0 19158 390823205 Whole disk /dev/hda4 15391 19156 76806002 SunOS root /dev/hda5 3660 6744 6291360 83 Linux native /dev/hda6 6744 10574 7813200 83 Linux native /dev/hda7 10574 15391 9826680 83 Linux native /dev/hda8 319 3660 68156408 SunOS home I'd like to reiterate: I was doing tests on a live system. It came to life this way: 1) Install Solaris 9 on a clean disk: +--+ \ | hda2 SunOS swap 514 MB | \ | || +--+| | || | || +--+| | hda8 SunOS home 6 GB || |UFS / (Solaris) || | || +--+| | || | | \ | |hda3 Whole disk | | / | || | || | || | || | || | || | || +--+| | hda4 SunOS root 6,5 GB || |UFS / (Solaris) || | | / +--+ / Solaris installer proposed this in different way: (look where hda1 and hda2 were going to be!) +--+ \ | hda2 SunOS swap 514 MB | \ | || +--+| | hda8 SunOS home ~23 GB || | || | | \ | |hda3 Whole disk | | / | || +--+| | hda1 SunOS root 6 GB || | || |
Re: Kernel panic - not syncing: Aiee, killing interrupt handler!
I've had issues with the ESP controller in 2.6.xx before but do not have access to the box on which it occurred in order to do anything about the problem. Might want to put the output of uname -a, prtconf -v (must be root), and dmesg. From 2.4 since 2.6 OOPSes. Also tell us about your disks if the dmesg output gives an incomplete picture of their setup. HTH! --- Bob Tanner [EMAIL PROTECTED] wrote: I've search the list and google for a fix, but I cannot seem to find a solution. 2.4.27 seems to work, but 2.6.10 does not. What other info should I add to this post to be more informative? ESP: Total of 1 ESP hosts found, 1 actually in use. scsi0 : Sparc ESP100A-FAST Vendor: IBM Model: DNES-318350 Rev: SA30 Type: Direct-Access ANSI SCSI revision: 03 esp0: target 0 [period 100ns offset 15 10.00MHz FAST SCSI-II] esp0: Aborting command esp0: dumping state esp0: dma -- cond_rega6400310 addrf0007e40 esp0: SW [sreg11 sstep04 ireg18] esp0: HW reread [sreg01 sstepc4 ireg00] esp0: current command [tgt00 lun01 pphaseCLUELESS cphaseDATAIN] esp0: disconnected esp0: Aborting command esp0: dumping state esp0: dma -- cond_rega6400310 addrf0007e40 esp0: SW [sreg11 sstep04 ireg18] esp0: HW reread [sreg01 sstepc4 ireg00] esp0: current command [tgt00 lun01 pphaseUNISSUED cphaseUNISSUED] esp0: disconnected esp0: Resetting scsi bus esp0: Gross error sreg=40 esp0: SCSI bus reset interrupt esp0: DMA error a4400302 esp0: Resetting scsi bus esp0: SCSI bus reset interrupt \|/ \|/ @'/ ,. \`@ /_| \__/ |_\ \__U_/ swapper(0): Kernel bad trap [#1] PSR: 1e401fc4 PC: f00c92bc NPC: f00c92c0 Y: Tainted: GF PC: bit_map_clear+0x44/0x7c %G: 0080 0001 f070e000 f000e000 %O: f327e630 0007 0001 0002 0001 f000fa90 fe61c630 RPC: esp_finish_reset+0x18/0xc0 [esp] %L: f01efca0 f002fc94 f002fc98 0020 06b3 f000e000 f8ba0180 %I: f07bd21c fd011000 f01b7594 f000faf8 fe61fa1c Caller[fe61fa1c]: esp_handle+0xf0/0x2f4 [esp] Caller[fe61fc54]: esp_intr+0x34/0x5c [esp] Caller[f0012dcc]: handler_irq+0x78/0xe0 Caller[f001057c]: patch_handler_irq+0x0/0x24 Caller[f00344a0]: __do_softirq+0x20/0xcc Caller[f003458c]: do_softirq+0x40/0x54 Caller[f001057c]: patch_handler_irq+0x0/0x24 Caller[f018dc48]: schedule+0x2c/0x308 Caller[f0013f5c]: cpu_idle+0x74/0x110 Caller[f01e9ee8]: start_kernel+0x218/0x22c Caller[f01e9790]: sun4c_continue_boot+0x314/0x324 Caller[]: 0x0 Instruction DUMP: 85310001 8088a001 832b4001 83d02005 82290001 8e01e001 8 Kernel panic - not syncing: Aiee, killing interrupt handler! 0Press L1-A to return to the boot prom -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of Debian on Sun Blade 150 (parted and the like)
On Friday 29 April 2005 15:47, Wiktor Wandachowicz wrote: So, after all it looks like the problem was on my side. I'm terribly sorry for misinforming you, and I take back my words. Looks like Frans was right when he wrote about user error. I bow my head before him. He is the one who really knows better how to handle Debian on sparc... But I'm learning :-) :-) /me is only a newbie regarding Sparc himself ;-) Probably putting swap partition in a different location could save me a bit of trouble. But on the side note, it was Solaris installer that put swap partition on cylinders 0-258 of the hard drive. So it looked to me that it knew what it was doing proposing such layout upon install. It probably does for Solaris. I think that Solaris may format/use the swap partition in a different way than linux (and thus Debian) does. So, the problem is that the installer blindly re-uses (and also formats by default) a swap partition that starts in sector 0. There already is some code and dialogs in silo-installer that hooks into partman to warn about this, but that code appears to be unfinished and is currently not used. Cheers, FJP pgpNkeMTxbmkT.pgp Description: PGP signature
Re: Status of Debian on Sun Blade 150 (parted and the like)
Frans Pop wrote: Wiktor Wandachowicz wrote: Probably putting swap partition in a different location could save me a bit of trouble. But on the side note, it was Solaris installer that put swap partition on cylinders 0-258 of the hard drive. So it looked to me that it knew what it was doing proposing such layout upon install. It probably does for Solaris. I think that Solaris may format/use the swap partition in a different way than linux (and thus Debian) does. When we'll be able to see the sources of OpenSolaris, it may as well become quite obvious. But I'd like to repeat: on running Debian system I've put a script which recreates swap every time Linux boots (btw. Solaris initializes swap itself, without any action needed). The sript I've made is in /etc/init.d/regenswap.sh, and is symlinked to /etc/rcS.d/S09regenswap.sh. This script essentially calls mkswap for every swap partition listed in /etc/fstab, BEFORE any swapon is called. This way the swap partition is shared between Linux and Solaris and there is no need to create an additional partition for linux-style swap only. So, the problem is that the installer blindly re-uses (and also formats by default) a swap partition that starts in sector 0. There already is some code and dialogs in silo-installer that hooks into partman to warn about this, but that code appears to be unfinished and is currently not used. I don't know if it could stop me, though. I'm quite determined sometimes :-) Friendly, Wiktor Wandachowicz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel panic - not syncing: Aiee, killing interrupt handler!
[EMAIL PROTECTED] wrote: I've had issues with the ESP controller in 2.6.xx before but do not have access to the box on which it occurred in order to do anything about the problem. Might want to put the output of uname -a, prtconf -v (must be root), and dmesg. From 2.4 since 2.6 OOPSes. Also tell us about your disks if the dmesg output gives an incomplete picture of their setup. HTH! # uname -a Linux xxx 2.4.24-sparc32 #1 Fri Jan 30 16:04:55 EST 2004 sparc GNU/Linux # prtconf -v System Configuration: Sun Microsystems sun4m Memory size: 128 Megabytes System Peripherals (Software Nodes): SUNW,SPARCstation-10 packages (driver probably installed) disk-label (driver probably installed) deblocker (driver probably installed) obp-tftp (driver probably installed) options (driver probably installed) aliases (driver probably installed) openprom (driver probably installed) iommu (driver probably installed) sbus (driver probably installed) espdma (driver probably installed) esp (driver probably installed) sd (driver probably installed) st (driver probably installed) ledma (driver probably installed) le (driver probably installed) SUNW,bpp (driver probably installed) SUNW,DBRIe (driver probably installed) mmcodec (driver probably installed) obio (driver probably installed) zs (driver probably installed) zs (driver probably installed) eeprom (driver probably installed) counter (driver probably installed) interrupt (driver probably installed) SUNW,fdtwo (driver probably installed) auxio (driver probably installed) power (driver probably installed) memory (driver probably installed) virtual-memory (driver probably installed) eccmemctl (driver probably installed) Ross,RT625 (driver probably installed) Ross,RT625 (driver probably installed) # dmesg PROMLIB: Sun Boot Prom Version 3 Revision 2 Linux version 2.4.24-sparc32 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040125 (prerel4 ARCH: SUN4M TYPE: Sun4m SparcStation10/20 Ethernet address: 0:c0:78:50:0:b6 SRMMU: Using VAC size of 262144 bytes, line size 64 bytes. Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek ([EMAIL PROTECTED]). Patching kernu 16265MB HIGHMEM available. On node 0 totalpages: 32014 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 65418 pages. Found CPU 0 node=ffd74140,mid=8 Found CPU 1 node=ffd74390,mid=9 Found 2 CPU prom device tree node(s). Power off control detected. Kernel command line: root=/dev/sda3 ro Calibrating delay loop... 89.90 BogoMIPS Memory: 122060k available (1824k kernel code, 300k data, 132k init, 65060k high] Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) Inode cache hash table entries: 4096 (order: 3, 32768 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX IOMMU: impl 0 vers 3 page table at f088 of size 262144 bytes sbus0: Clock 20.0 MHz dma0: Revision 2 dma1: Revision 2 Sparc Zilog8530 serial driver version 1.68.2.2 Sun Mouse-Systems mouse driver version 1.00 tty00 at 0xffede004 (irq = 44) is a Zilog8530 tty01 at 0xffede000 (irq = 44) is a Zilog8530 tty02 at 0xffedb004 (irq = 44) is a Zilog8530 tty03 at 0xffedb000 (irq = 44) is a Zilog8530 keyboard: not present Console: ttyS0 (Zilog8530) Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd allocated 32 pages and 32 bhs reserved for the highmem bounces Journalled Block Device driver loaded devfs: v1.12c (20020818) Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x0 pty: 256 Unix98 ptys configured Floppy drive(s): fd0 is 1.44M ioremap: done with statics, switching to malloc FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) sunlance.c:v2.01 08/Nov/01 Miguel de Icaza ([EMAIL PROTECTED]) eth0: LANCE 00:c0:78:50:00:b6 eth0: using auto-carrier-detection. SCSI subsystem driver Revision: 1.00 esp0: IRQ 36 SCSI ID 7 Clk 40MHz CCYC=25000 CCF=8 TOut 167 NCR53C9XF(espfast) ESP: Total of 1 ESP hosts found, 1 actually in use. scsi0 : Sparc ESP100A-FAST Vendor: IBM Model: DNES-318350 Rev: SA30 Type: Direct-Access ANSI SCSI revision: 03 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 esp0: target 0 [period 100ns offset 15 10.00MHz FAST SCSI-II] SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB) Partition check: /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 Initializing Cryptographic API NET4: Linux TCP/IP 1.0 for NET4.0 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096
Re: chrony: [sparc] Fails to read RTC and floods logfiles
On Fri, 29 Apr 2005 11:48:07 +0200
Frans Pop [EMAIL PROTECTED] wrote:
One problem is that the Mostek RTC driver currently does not support the
RTC_(RD/SET)_TIME. However, the thread contains a patch that will fix
this. I am not completely sure if this patch is final yet or if has will
be (has been) submitted for inclusion in the kernel.
Please let us know your/upstream's thoughts on this.
THe fix is in upstream 2.6.x and will be in upstream 2.4.x as
soon as Marcelo sets up a GIT tree I can use to merge changes
to him.
From an strace [3] I ran on chrony when it fails and floods the logs, it
seems that the main problem is in the use of RTC_UIE_ON, RTC_UIE_OFF
calls as the clock chip does not have an interrupt node.
Perhaps some error handling can be added there.
That's correct, not all RTC devices have interrupt generation
capabilities, and thus support UIE. So logging an error when
RTC_UIE_{ON,OFF} returns -EINVAL or similar is not such a good
idea.
Now, to be fair, there is a generic RTC driver in the kernel we could
move over to, called drivers/char/genrtc.c that makes some kind of
attempt to emulate UIE in software by using timers. I may at
some point in the future move the Mostek RTC driver over to that
thing, but not anytime soon.
So in the meantime, chrony should probably not log when UIE
ioctls do not succeed, it can just mean that the RTC device
does not support generating interrupts.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chrony: [sparc] Fails to read RTC and floods logfiles
On Friday 29 April 2005 18:45, David S. Miller wrote: Frans Pop [EMAIL PROTECTED] wrote: One problem is that the Mostek RTC driver currently does not support the RTC_(RD/SET)_TIME. However, the thread contains a patch that will fix this. I am not completely sure if this patch is final yet or if has will be (has been) submitted for inclusion in the kernel. Please let us know your/upstream's thoughts on this. THe fix is in upstream 2.6.x and will be in upstream 2.4.x as soon as Marcelo sets up a GIT tree I can use to merge changes to him. Could you submit the final patches you made to the BTS so they can be included in the 2.4 and 2.6 Debian kernels? pgpcF9x1IoKnp.pgp Description: PGP signature
