* Re: [linux-lvm] help: can't read name(s) of physical volumes (Debian kernel weirdness also involved)
From: Patrick Caulfield @ 2002-12-16 2:17 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <Pine.GSO.4.44L-027.0212151823290.10369-100000@unix3.andrew.cmu.edu>
On Sun, Dec 15, 2002 at 06:25:47PM -0500, Daniel J Hannum wrote:
> Thanks a ton. Debian needs to make their documentation more clear. When
> you install lvm, they say to either mount devfs (they don't say how) OR
> install devfsd. Turns out, that should be AND. I had to send the kernel
> param like you said. And it doesn't work without devfsd, either.
Actually it is possible to get it to work without devfsd but it's just too
annoying IMHO :)
patrick
^ permalink raw reply
* subterfugue 0.2.1a for kernel testing - update
From: Carl Spalletta @ 2002-12-16 2:20 UTC (permalink / raw)
To: linux-kernel
SUBTERFUGUE UPDATE/PATCH:
Since subterfugue is such a good tool for syscall tracing, &c, I have
updated syscallmap.table from syscallmap.py in the latest (0.2.1a) release
of subterfugue, to include all the syscalls added through kernel 2.5.51.
It proved necessary to do this because of errors like the following:
$ sf --trick=Delay:delay=.000001 /bin/ls -l
Traceback (most recent call last):
File "/usr/lib/subterfugue/subterfugue.py", line 572, in main
do_main(allflags)
File "/usr/lib/subterfugue/subterfugue.py", line 547, in do_main
newkid = trace_syscall(wpid, flags, tricklist)
File "/usr/lib/subterfugue/p_linux_i386.py", line 154, in trace_syscall
assert (0 <= scno < len(syscallmap.table)
AssertionError: unknown system call (=229, ...
Apparently some utilities (in this case from RH8) will attempt, in an
anticipatory manner, to use syscalls that _may_ be unimplemented in whatever
the current kernel happens to be (in this case 2.4.18):
$ strace ls -l
...
lstat64("COPYING", {st_mode=S_IFREG|0644, st_size=18454, ...}) = 0
getxattr("COPYING", "system.posix_acl_access", (nil), 0) = -1 ENOSYS
(Function not implemented)
...
IMPLEMENTATION NOTE:
For those interested in doing further updating - the last field of
syscallmap.table is a tuple - 'None' stands for the empty tuple and a
non-empty tuple is presented only when the arg list for the given syscall
includes one or more null-terminated strings. Then it takes a form
such as:
( 3, TF, "sys_open", "open", ('P', None, None)), # 5
^ ^^^^ ^^^
where the 'P' in the tuple means a null-terminated string - in this case
it stands for the 'pathname' arg to open(2); and 'None,None' are placeholders
for the remaining non-string args.
RATIONALE (or rationalization):
I don't consider posting this patch here to be off-topic since the majority
of the users of subterfugue are found right here on this list.
--------------------------------CUT HERE-------------------------------------
--- syscallmap.py.orig 2002-12-15 18:58:35.000000000 -0500
+++ syscallmap.py 2002-12-15 20:01:51.000000000 -0500
@@ -240,6 +240,43 @@
( 3, 0, "sys_madvise", "madvise", None),# 219
( 3, 0, "sys_getdents64", "getdents64", None),# 220
( 3, 0, "sys_fcntl64", "fcntl64", None),# 221
+ ( 4, 0, "printargs", "SYS_222", None),# 222
+ ( 3, 0, "sys_security", "security", None),# 223
+ ( 0, 0, "sys_gettid", "gettid", None),# 224
+ ( 3, 0, "sys_readahead", "readahead", None),# 225
+ ( 5, TF, "sys_setxattr", "setxattr", None),# 226
+ ( 5, TF, "sys_setxattr", "lsetxattr", None),# 227
+ ( 5, TF, "sys_fsetxattr", "fsetxattr", None),# 228
+ ( 4, TF, "sys_getxattr", "getxattr", None),# 229
+ ( 4, TF, "sys_getxattr", "lgetxattr", None),# 230
+ ( 4, TF, "sys_fgetxattr", "fgetxattr", None),# 231
+ ( 3, TF, "sys_listxattr", "listxattr", None),# 232
+ ( 3, TF, "sys_listxattr", "llistxattr", None),# 233
+ ( 3, TF, "sys_flistxattr", "flistxattr", None),# 234
+ ( 2, TF, "sys_removexattr", "removexattr", None),# 235
+ ( 2, TF, "sys_removexattr", "lremovexattr", None),# 236
+ ( 2, TF, "sys_fremovexattr", "fremovexattr", None),# 237
+ ( 2, TS, "sys_tkill", "tkill", None),# 238
+ ( 4, TF, "sys_sendfile64", "sendfile64", None),# 239
+ ( 4, 0, "sys_futex", "futex", None),# 240
+ ( 3, 0, "sys_sched_setaffinity","sched_setaffinity", None),# 241
+ ( 3, 0, "sys_sched_getaffinity","sched_getaffinity", None),# 242
+ ( 1, 0, "sys_set_thread_area", "set_thread_area", None),# 243
+ ( 1, 0, "sys_get_thread_area", "get_thread_area", None),# 244
+ ( 2, TI, "sys_io_setup", "io_setup", None),# 245
+ ( 1, TI, "sys_io_destroy", "io_destroy", None),# 246
+ ( 5, TI, "sys_io_getevents", "io_getevents", None),# 247
+ ( 3, TI, "sys_io_submit", "io_submit", None),# 248
+ ( 3, TI, "sys_io_cancel", "io_cancel", None),# 249
+ ( 5, 0, "sys_alloc_hugepages", "alloc_hugepages", None),# 250
+ ( 1, 0, "sys_free_hugepages", "free_hugepages", None),# 251
+ ( 1, 0, "sys_exit_group", "exit_group", None),# 252
+ ( 3, TF, "sys_lookup_dcookie", "lookup_dcookie", None),# 253
+ ( 1, TF, "sys_epoll_create", "epoll_create", None),# 254
+ ( 4, TF, "sys_epoll_ctl", "epoll_ctl", None),# 255
+ ( 4, TF, "sys_epoll_wait", "epoll_wait", None),# 256
+ ( 5, TF, "sys_remap_file_pages", "remap_file_pages", None),# 257
+ ( 2, 0, "sys_set_tid_address", "set_tid_address", None),# 258
)
^ permalink raw reply
* Arctic ethernet
From: David Gibson @ 2002-12-16 2:11 UTC (permalink / raw)
To: linuxppc-embedded
...and another driver for Arctic-2, this time for Ethernet (which is
actually on a debug board, no on the Arctic-2 itself). It's based on
a RTL8019 chip and this driver was based on the ariadne2 driver.
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/drivers/net/Config.in linux-bartholomew/drivers/net/Config.in
--- /home/dgibson/kernel/linuxppc_2_4_devel/drivers/net/Config.in 2002-12-04 10:44:50.000000000 +1100
+++ linux-bartholomew/drivers/net/Config.in 2002-12-12 16:50:02.000000000 +1100
@@ -43,6 +43,9 @@
if [ "$CONFIG_BEECH" = "y" ]; then
tristate ' Beech onboard CS8900A Ethernet support' CONFIG_CS89x0
fi
+ if [ "$CONFIG_ARCTIC2" = "y" ]; then
+ tristate ' Arctic-II debug sled ethernet support' CONFIG_ARCTIC_ENET
+ fi
if [ "$CONFIG_XILINX_OCP" = "y" ]; then
tristate ' Xilinx on-chip ethernet' CONFIG_XILINX_ENET
fi
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/drivers/net/Makefile linux-bartholomew/drivers/net/Makefile
--- /home/dgibson/kernel/linuxppc_2_4_devel/drivers/net/Makefile 2002-09-27 09:11:02.000000000 +1000
+++ linux-bartholomew/drivers/net/Makefile 2002-12-12 16:48:59.000000000 +1100
@@ -149,6 +149,7 @@
obj-$(CONFIG_NET_SB1250_MAC) += sb1250-mac.o
obj-$(CONFIG_GT64260_ETH) += gt64260_eth.o
obj-$(CONFIG_NPNET) += npnet.o
+obj-$(CONFIG_ARCTIC_ENET) += arctic_enet.o 8390.o
obj-$(CONFIG_PPP) += ppp_generic.o slhc.o
obj-$(CONFIG_PPP_ASYNC) += ppp_async.o
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/drivers/net/arctic_enet.c linux-bartholomew/drivers/net/arctic_enet.c
--- /home/dgibson/kernel/linuxppc_2_4_devel/drivers/net/arctic_enet.c Thu Jan 01 10:00:00 1970
+++ linux-bartholomew/drivers/net/arctic_enet.c Fri Dec 13 14:03:36 2002
@@ -0,0 +1,658 @@
+/*
+ * IPE405 (IBM IAP 405 chip evaluation board) Debug Support Board
+ * Ehernet Driver
+ * (C) Copyright 2001 by S.nishino (jl04348@jp.ibm.com) IBM-Japan
+ *
+ * ---------- Strategy ----------
+ *
+ * This NIC is RTL8019AS, simply connected to External Bus Controller
+ * of IAP 405 chip. As many folks of 8390 based NIC, 8390 core driver
+ * is usable. luckily, the following driver is already available for
+ * Amiga zorro bus (however I don't know this architecture beyond
+ * below), this is modified based on this driver (ariadne2).
+ *
+ * ---------- original header ----------
+ * Amiga Linux/m68k Ariadne II Ethernet Driver
+ *
+ * (C) Copyright 1998 by some Elitist 680x0 Users(TM)
+ *
+ * ---------------------------------------------------------------------------
+ *
+ * This program is based on all the other NE2000 drivers for Linux
+ *
+ * ---------------------------------------------------------------------------
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of the Linux
+ * distribution for more details. */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/irq.h>
+
+
+#include <asm/system.h>
+#include <asm/io.h>
+#include <asm/irq.h>
+#include <asm/ppc4xx_pic.h>
+#if defined(CONFIG_ARCTIC2)
+#include <platforms/arctic2.h>
+#else
+#error The driver only works on Arctic
+#endif
+
+#include "8390.h"
+
+
+#define ARCTIC_ENET_BASE8 (ARCTIC2_FPGA8_PADDR + 256*1024)
+#define ARCTIC_ENET_BASE16 (ARCTIC2_FPGA16_PADDR + 0)
+
+#define ARCTIC_ENET_IOBASE 0x0300 /* io base offset from NIC region */
+
+#define ARCTIC_ENET_IRQ 29 /* irq number in UIC */
+#define ARCTIC_ENET_IRQ_MASK (0x80000000 >> ARCTIC_ENET_IRQ)
+
+#define NE_BASE (ARCTIC_ENET_BASE8 + ARCTIC_ENET_IOBASE)
+#define NE_BASE16 (ARCTIC_ENET_BASE16 + ARCTIC_ENET_IOBASE)
+
+/* 8390 register address */
+#define NE_CMD (0x00)
+#define NE_DATAPORT (0x10) /* NatSemi-defined port window offset. */
+#define NE_DATAPORT16 (NE_DATAPORT / sizeof(u16))
+#define NE_RESET (0x1f) /* Issue a read to reset, a write to clear. */
+#define NE_IO_EXTENT (0x20) /* region extent */
+
+#define NE_EN0_ISR (0x07)
+#define NE_EN0_DCFG (0x0e)
+
+#define NE_EN0_RSARLO (0x08)
+#define NE_EN0_RSARHI (0x09)
+#define NE_EN0_RCNTLO (0x0a)
+#define NE_EN0_RXCR (0x0c)
+#define NE_EN0_TXCR (0x0d)
+#define NE_EN0_RCNTHI (0x0b)
+#define NE_EN0_IMR (0x0f)
+
+/* 8390 packet buffer page number */
+#define NESM_START_PG 0x40 /* First page of TX buffer */
+#define NESM_STOP_PG 0x80 /* Last page +1 of RX ring */
+
+static u8 *iobase8;
+static u16 *iobase16;
+
+static int arctic_enet_probe(struct net_device *dev);
+static int arctic_enet_init(struct net_device *dev);
+
+static int arctic_enet_open(struct net_device *dev);
+static int arctic_enet_close(struct net_device *dev);
+
+static void arctic_enet_reset_8390(struct net_device *dev);
+static void arctic_enet_get_8390_hdr(struct net_device *dev,
+ struct e8390_pkt_hdr *hdr,
+ int ring_page);
+static void arctic_enet_block_input(struct net_device *dev, int count,
+ struct sk_buff *skb, int ring_offset);
+static void arctic_enet_block_output(struct net_device *dev,
+ const int count,
+ const unsigned char *buf,
+ const int start_page);
+
+/* These macros will do something on Arctic-I if we ever add support
+ * for it back in */
+#define switch_16bit_bank() do { } while (0)
+#define switch_8bit_bank() do { } while (0)
+
+void p_dump(unsigned char *p, int sz)
+{
+ int i;
+ unsigned char *wp;
+
+ wp = p;
+
+ printk("------ PACKET START : %d Bytes ------ \n", sz);
+
+ for (i = 0; i < sz; i++) {
+ if (i % 16 == 0) {
+ printk("\n %04X: %02X ", i, *wp);
+ } else if (i % 16 == 15) {
+ printk("%02X", *wp);
+ } else {
+ printk("%02X ", *wp);
+ }
+ wp++;
+ }
+
+ printk("------ PACKET END ------ \n");
+}
+
+/* Code for reading the MAC address from the Arctic ethernet based on
+ * similar code in PIBS */
+
+static void __init writereg_9346(volatile u8 *iobase, u8 value)
+{
+ /* Switch to register page 3 */
+ writeb(readb(iobase + NE_CMD) | 0xc0, iobase + NE_CMD);
+ writeb(value, iobase + 0x01);
+}
+
+static u8 __init readreg_9346(volatile u8 *iobase)
+{
+ /* Switch to register page 3 */
+ writeb(readb(iobase + NE_CMD) | 0xc0, iobase + NE_CMD);
+ return readb(iobase + 0x01);
+}
+
+static void __init write_bit_9346(volatile u8 *iobase, u8 bit)
+{
+ u8 mask = ~0x06;
+
+ writereg_9346(iobase, (readreg_9346(iobase) & mask) | bit);
+ udelay(1000);
+ writereg_9346(iobase, (readreg_9346(iobase) & mask) | bit | 0x04);
+ udelay(1000);
+}
+
+static u8 __init read_bit_9346(volatile u8 *iobase)
+{
+ u8 bit;
+ u8 mask = ~0x05;
+
+ mask = ~0x05;
+ writereg_9346(iobase, readreg_9346(iobase) & mask);
+ udelay(1000);
+ writereg_9346(iobase, (readreg_9346(iobase) & mask) | 0x04);
+ bit = readreg_9346(iobase) & 0x01;
+ udelay(1000);
+
+ return bit;
+}
+
+static u16 __init arctic_read_9346(volatile u8 *iobase, unsigned long addr)
+{
+ unsigned long flags;
+ int i;
+ u16 data;
+
+ local_irq_save(flags);
+
+ /* Put the chip into 8390 programming mode */
+ writereg_9346(iobase, (readreg_9346(iobase) & ~0xc0) | 0x80);
+ udelay(1000);
+
+ /* Send command (read 16-bit value) to EEPROM */
+ /* Bring CS Low */
+ writereg_9346(iobase, readreg_9346(iobase) & ~0x0f);
+ udelay(1000);
+ /* Bring CS High */
+ writereg_9346(iobase, (readreg_9346(iobase) & ~0x0f) | 0x08);
+ udelay(1000);
+
+ /* Send a 1 */
+ write_bit_9346(iobase, 0x02);
+ /* Send opcode 0b10 */
+ write_bit_9346(iobase, 0x02);
+ write_bit_9346(iobase, 0x00);
+ /* Send address to read */
+ for (i = 0; i < 6; i++) {
+ if (addr & 0x20)
+ write_bit_9346(iobase, 0x02);
+ else
+ write_bit_9346(iobase, 0x00);
+ addr <<= 1;
+ }
+
+ /* Read the value back, bit by bit */
+ data = 0;
+ for (i = 0; i < 16; i++) {
+ data <<= 1;
+ if (read_bit_9346(iobase))
+ data |= 0x1;
+ }
+
+ /* Bring CS Low */
+ writereg_9346(iobase, readreg_9346(iobase) & ~0x0f);
+ udelay(1000);
+ /* Bring the chip out of 8390 programming mode */
+ writereg_9346(iobase, readreg_9346(iobase) & ~0xc0);
+ udelay(1000);
+
+ /* Return to register page 0 */
+ writeb(readb(iobase + NE_CMD) & ~0xc0, iobase + NE_CMD);
+ udelay(1000);
+
+ local_irq_restore(flags);
+
+ return data;
+}
+
+static void __init arctic_get_macaddr(struct net_device *dev)
+{
+ u16 t0, t1, t2, v0, v1;
+
+ t0 = arctic_read_9346(iobase8, 0);
+ t1 = arctic_read_9346(iobase8, 2);
+ t2 = arctic_read_9346(iobase8, 4);
+ v0 = arctic_read_9346(iobase8, 6);
+ v1 = arctic_read_9346(iobase8, 8);
+
+ printk("arctic_enet: %04x-%04x-%04x (%04x/%04x)\n",
+ t0, t1, t2, v0, v1);
+
+ if ( (v0 != 0x4d50) || (v1 != 0x5400) ) {
+ printk(KERN_WARNING "%s: MAC address is not set in EEPROM\n", dev->name);
+ return;
+ }
+
+ printk("%s: MAC address from EEPROM is %04x:%04x:%04x\n",
+ dev->name, (unsigned)t0, (unsigned)t1, (unsigned)t2);
+
+ dev->dev_addr[0] = t0 >> 8;
+ dev->dev_addr[1] = t0 & 0xff;
+ dev->dev_addr[2] = t1 >> 8;
+ dev->dev_addr[3] = t1 & 0xff;
+ dev->dev_addr[4] = t2 >> 8;
+ dev->dev_addr[5] = t2 & 0xff;
+}
+
+int __init arctic_enet_probe(struct net_device *dev)
+{
+ unsigned long reset_start_time;
+
+ switch_8bit_bank();
+ /* Reset card. Who knows what dain-bramaged state it was left in. */
+ reset_start_time = jiffies;
+
+ writeb(readb(iobase8 + NE_RESET), iobase8 + NE_RESET);
+
+ while ((readb(iobase8 + NE_EN0_ISR) & ENISR_RESET) == 0)
+ if (jiffies - reset_start_time > 2 * HZ / 100) {
+ printk("arctic_enet: not found (no reset ack).\n");
+ return -ENODEV;
+ }
+
+ writeb(0xff, iobase8 + NE_EN0_ISR); /* Ack all intr. */
+
+ arctic_get_macaddr(dev);
+
+ printk("arctic_enet: found at 0x%08x/0x%08x, MAC address "
+ "%02x:%02x:%02x:%02x:%02x:%02x\n",
+ NE_BASE, NE_BASE16,
+ dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
+ dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
+
+ /* Hack to let 8390.c work properly - it assumes IO space
+ * addresses */
+ dev->base_addr = (unsigned long)iobase8 - _IO_BASE;
+ dev->irq = ARCTIC_ENET_IRQ;
+
+ return 0;
+}
+
+static int __init arctic_enet_init(struct net_device *dev)
+{
+ static u32 arctic_enet_offsets[16] = {
+ 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
+ 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
+ };
+
+ /* Since this irq is connected to uic as edge interrupt, its pending must be cleared. */
+ /* FIXME: it would be nice to get rid of the direct reference
+ * to the 4xx irq structure */
+ ppc4xx_pic->ack(dev->irq);
+
+ /* Install the Interrupt handler */
+ if (request_irq(dev->irq, ei_interrupt, SA_SHIRQ, dev->name, dev))
+ return -EAGAIN;
+
+ /* Allocate dev->priv and fill in 8390 specific dev fields. */
+ if (ethdev_init(dev)) {
+ printk(" Unable to get memory for dev->priv.\n");
+ return -ENOMEM;
+ }
+
+ /*
+ * Fill 8390 specific member for 8390 core driver
+ */
+ ei_status.name = "RTL8019AS";
+ ei_status.tx_start_page = NESM_START_PG;
+ ei_status.stop_page = NESM_STOP_PG;
+ ei_status.word16 = 1;
+ ei_status.rx_start_page = NESM_START_PG + TX_PAGES;
+
+ ei_status.reset_8390 = &arctic_enet_reset_8390;
+ ei_status.block_input = &arctic_enet_block_input;
+ ei_status.block_output = &arctic_enet_block_output;
+ ei_status.get_8390_hdr = &arctic_enet_get_8390_hdr;
+ ei_status.reg_offset = arctic_enet_offsets;
+
+ NS8390_init(dev, 0);
+ return 0;
+}
+
+static int arctic_enet_open(struct net_device *dev)
+{
+ int err;
+ err = ei_open(dev);
+ if (err)
+ return err;
+
+ MOD_INC_USE_COUNT;
+ return 0;
+}
+
+static int arctic_enet_close(struct net_device *dev)
+{
+ int err;
+
+ err = ei_close(dev);
+ if (err)
+ return err;
+
+ MOD_DEC_USE_COUNT;
+ return 0;
+}
+
+/* Hard reset the card. This used to pause for the same period that a
+ 8390 reset command required, but that shouldn't be necessary. */
+static void arctic_enet_reset_8390(struct net_device *dev)
+{
+ unsigned long reset_start_time = jiffies;
+
+ if (ei_debug > 1)
+ printk("resetting the 8390 t=%ld...", jiffies);
+
+ writeb(readb(iobase8 + NE_RESET), iobase8 + NE_RESET);
+
+ ei_status.txing = 0;
+ ei_status.dmaing = 0;
+
+ /* This check _should_not_ be necessary, omit eventually. */
+ while ((readb(iobase8 + NE_EN0_ISR) & ENISR_RESET) == 0)
+ if (jiffies - reset_start_time > 2 * HZ / 100) {
+ printk("%s: ne_reset_8390() did not complete.\n",
+ dev->name);
+ break;
+ }
+ writeb(ENISR_RESET, iobase8 + NE_EN0_ISR); /* Ack intr. */
+}
+
+/* Grab the 8390 specific header. Similar to the block_input routine, but
+ we don't need to be concerned with ring wrap as the header will be at
+ the start of a page, so we optimize accordingly. */
+
+static void arctic_enet_get_8390_hdr(struct net_device *dev,
+ struct e8390_pkt_hdr *hdr,
+ int ring_page)
+{
+ int cnt;
+ u16 *ptrs;
+ unsigned char *ptrc;
+
+ /* This *shouldn't* happen. If it does, it's the last thing you'll see */
+ if (ei_status.dmaing) {
+ printk("%s: DMAing conflict in ne_get_8390_hdr "
+ "[DMAstat:%d][irqlock:%d].\n", dev->name,
+ ei_status.dmaing, ei_status.irqlock);
+ return;
+ }
+
+ ei_status.dmaing |= 0x01;
+ writeb(E8390_NODMA + E8390_PAGE0 + E8390_START, iobase8 + NE_CMD);
+ writeb(ENISR_RDC, iobase8 + NE_EN0_ISR);
+ writeb(sizeof(struct e8390_pkt_hdr), iobase8 + NE_EN0_RCNTLO);
+ writeb(0, iobase8 + NE_EN0_RCNTHI);
+ writeb(0, iobase8 + NE_EN0_RSARLO); /* On page boundary */
+ writeb(ring_page, iobase8 + NE_EN0_RSARHI);
+ writeb(E8390_RREAD + E8390_START, iobase8 + NE_CMD);
+
+ if (ei_status.word16) {
+ switch_16bit_bank();
+ ptrs = (u16 *) hdr;
+ for (cnt = 0; cnt < (sizeof(struct e8390_pkt_hdr) >> 1);
+ cnt++)
+ *ptrs++ = in_be16((u16 *) (iobase16 + NE_DATAPORT16));
+ switch_8bit_bank();
+ } else {
+
+ ptrc = (unsigned char *) hdr;
+ for (cnt = 0; cnt < sizeof(struct e8390_pkt_hdr); cnt++)
+ *ptrc++ = readb(iobase8 + NE_DATAPORT);
+ }
+
+
+ writeb(ENISR_RDC, iobase8 + NE_EN0_ISR); /* Ack intr. */
+
+ /* I am Big Endian, but received byte count is Little Endian. */
+ hdr->count = le16_to_cpu(hdr->count);
+
+ ei_status.dmaing &= ~0x01;
+}
+
+/* Block input and output, similar to the Crynwr packet driver. If you
+ are porting to a new ethercard, look at the packet driver source for hints.
+ The NEx000 doesn't share the on-board packet memory -- you have to put
+ the packet out through the "remote DMA" dataport using writeb. */
+
+static void arctic_enet_block_input(struct net_device *dev, int count,
+ struct sk_buff *skb, int ring_offset)
+{
+ char *buf = skb->data;
+ u16 *ptrs;
+ unsigned char *ptrc;
+
+ int cnt;
+
+ /* This *shouldn't* happen. If it does, it's the last thing you'll see */
+ if (ei_status.dmaing) {
+ printk("%s: DMAing conflict in ne_block_input "
+ "[DMAstat:%d][irqlock:%d].\n",
+ dev->name, ei_status.dmaing, ei_status.irqlock);
+ return;
+ }
+ ei_status.dmaing |= 0x01;
+ writeb(E8390_NODMA + E8390_PAGE0 + E8390_START, iobase8 + NE_CMD);
+ writeb(ENISR_RDC, iobase8 + NE_EN0_ISR);
+ writeb(count & 0xff, iobase8 + NE_EN0_RCNTLO);
+ writeb(count >> 8, iobase8 + NE_EN0_RCNTHI);
+ writeb(ring_offset & 0xff, iobase8 + NE_EN0_RSARLO);
+ writeb(ring_offset >> 8, iobase8 + NE_EN0_RSARHI);
+ writeb(E8390_RREAD + E8390_START, iobase8 + NE_CMD);
+
+
+ if (ei_status.word16) {
+
+ switch_16bit_bank();
+
+ ptrs = (u16 *) buf;
+ for (cnt = 0; cnt < (count >> 1); cnt++)
+ /* At 16 bits mode, bus acts as Little Endian mode
+ That's swap is needed ??? */
+ *ptrs++ = in_be16((u16 *) (iobase16 + NE_DATAPORT16));
+ switch_8bit_bank();
+
+ if (count & 0x01)
+ buf[count - 1] = readb(iobase8 + NE_DATAPORT);
+
+ } else {
+
+
+ ptrc = (unsigned char *) buf;
+ for (cnt = 0; cnt < count; cnt++)
+ *ptrc++ = readb(iobase8 + NE_DATAPORT);
+ }
+
+ writeb(ENISR_RDC, iobase8 + NE_EN0_ISR); /* Ack intr. */
+ ei_status.dmaing &= ~0x01;
+}
+
+static void arctic_enet_block_output(struct net_device *dev, int count,
+ const unsigned char *buf,
+ const int start_page)
+{
+ unsigned long dma_start;
+ u16 *ptrs;
+ unsigned char *ptrc;
+ int cnt;
+
+ /* Round the count up for word writes. Do we need to do this?
+ What effect will an odd byte count have on the 8390?
+ I should check someday. */
+ if (count & 0x01)
+ count++;
+
+ /* This *shouldn't* happen. If it does, it's the last thing you'll see */
+ if (ei_status.dmaing) {
+ printk("%s: DMAing conflict in ne_block_output."
+ "[DMAstat:%d][irqlock:%d]\n", dev->name,
+ ei_status.dmaing, ei_status.irqlock);
+ return;
+ }
+ ei_status.dmaing |= 0x01;
+
+#if 1 /* FIXME: not sure what this is for -dwg */
+ writeb(0x42, iobase8 + EN0_RCNTLO);
+ writeb(0x00, iobase8 + EN0_RCNTHI);
+ writeb(0x42, iobase8 + EN0_RSARLO);
+ writeb(0x00, iobase8 + EN0_RSARHI);
+#endif
+ /* We should already be in page 0, but to be safe... */
+ writeb(E8390_PAGE0 + E8390_START + E8390_NODMA, iobase8 + NE_CMD);
+
+ writeb(ENISR_RDC, iobase8 + NE_EN0_ISR);
+
+ /* Now the normal output. */
+ writeb(count & 0xff, iobase8 + NE_EN0_RCNTLO);
+ writeb(count >> 8, iobase8 + NE_EN0_RCNTHI);
+ writeb(0x00, iobase8 + NE_EN0_RSARLO);
+ writeb(start_page, iobase8 + NE_EN0_RSARHI);
+
+ writeb(E8390_RWRITE + E8390_START, iobase8 + NE_CMD);
+
+ if (ei_status.word16) {
+ switch_16bit_bank();
+
+ ptrs = (u16 *) buf;
+ for (cnt = 0; cnt < count >> 1; cnt++) {
+ /* At 16 bits mode, bus acts as Little Endian mode
+ That's swap is needed ??? */
+ out_be16((u16 *) (iobase16 + NE_DATAPORT16),
+ *ptrs);
+ ptrs++;
+ }
+
+ switch_8bit_bank();
+
+ } else {
+ ptrc = (unsigned char *) buf;
+ for (cnt = 0; cnt < count; cnt++)
+ writeb(*ptrc++, iobase8 + NE_DATAPORT);
+ }
+
+ dma_start = jiffies;
+
+ while ((readb(iobase8 + NE_EN0_ISR) & ENISR_RDC) == 0)
+ if (jiffies - dma_start > 2 * HZ / 100) { /* 20ms */
+ printk("%s: timeout waiting for Tx RDC.\n",
+ dev->name);
+ arctic_enet_reset_8390(dev);
+ NS8390_init(dev, 1);
+ break;
+ }
+
+ writeb(ENISR_RDC, iobase8 + NE_EN0_ISR); /* Ack intr. */
+ ei_status.dmaing &= ~0x01;
+ return;
+}
+
+static struct net_device arctic_enet_dev = {
+ .init = arctic_enet_init,
+ .open = arctic_enet_open,
+ .stop = arctic_enet_close,
+};
+
+int init_arctic_enet(void)
+{
+ struct net_device *dev = &arctic_enet_dev;
+ int rsvd8 = 0;
+ int rsvd16 = 0;
+ int err;
+
+ /* First set up our IO regions */
+ if (! request_mem_region(NE_BASE, NE_IO_EXTENT, "arctic_enet"))
+ goto fail;
+ rsvd8 = 1;
+
+ iobase8 = ioremap(NE_BASE, NE_IO_EXTENT);
+ if (! iobase8) {
+ err = -EBUSY;
+ goto fail;
+ }
+
+ if (NE_BASE16 != NE_BASE) {
+ if (! request_mem_region(NE_BASE16, NE_IO_EXTENT, "arctic_enet"))
+ goto fail;
+ rsvd16 = 1;
+ }
+
+ iobase16 = ioremap(NE_BASE16, NE_IO_EXTENT);
+ if (! iobase16) {
+ err = -EBUSY;
+ goto fail;
+ }
+
+ /* Configure IRQ */
+ cli();
+ mtdcr(DCRN_UIC0_TR, mfdcr(DCRN_UIC0_TR) | ARCTIC_ENET_IRQ_MASK);
+ mtdcr(DCRN_UIC0_PR, mfdcr(DCRN_UIC0_PR) | ARCTIC_ENET_IRQ_MASK);
+ mtdcr(DCRN_UIC0_SR, ARCTIC_ENET_IRQ_MASK);
+ sti();
+
+ err = arctic_enet_probe(dev);
+ if (err) {
+ printk(KERN_ERR "arctic_enet: No Arctic ethernet card found.\n");
+ goto fail;
+ }
+
+ err = register_netdev(dev);
+ if (err)
+ goto fail;
+
+ return 0;
+
+ fail:
+ if (iobase16)
+ iounmap(iobase16);
+ if (rsvd16)
+ release_mem_region(NE_BASE16, NE_IO_EXTENT);
+ if (iobase8)
+ iounmap(iobase8);
+ if (rsvd8)
+ release_mem_region(NE_BASE, NE_IO_EXTENT);
+
+ return err;
+
+}
+
+void remove_arctic_enet(void)
+{
+ unregister_netdev(&arctic_enet_dev);
+ free_irq(ARCTIC_ENET_IRQ, &arctic_enet_dev);
+
+ if (iobase16) {
+ iounmap(iobase16);
+ release_mem_region(NE_BASE16, NE_IO_EXTENT);
+ }
+ if (iobase8) {
+ iounmap(iobase8);
+ release_mem_region(NE_BASE, NE_IO_EXTENT);
+ }
+}
+
+module_init(init_arctic_enet);
+module_exit(remove_arctic_enet);
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Arctic-2 MTD driver
From: David Gibson @ 2002-12-16 2:09 UTC (permalink / raw)
To: linuxppc-embedded
Having committed the core support code for the Arctic-2, here come
some drivers for it. Below is an MTD map for the Arctic-2, derived
from beech-mtd.c. Essentially all it does is provide suitable
hardwired partitions.
Again, any comments before I commit this?
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/drivers/mtd/maps/Config.in linux-bartholomew/drivers/mtd/maps/Config.in
--- /home/dgibson/kernel/linuxppc_2_4_devel/drivers/mtd/maps/Config.in 2002-09-13 16:01:34.000000000 +1000
+++ linux-bartholomew/drivers/mtd/maps/Config.in 2002-12-12 15:28:27.000000000 +1100
@@ -57,6 +57,9 @@
if [ "$CONFIG_BEECH" = "y" ]; then
dep_tristate ' CFI Flash device mapped on IBM Beech' CONFIG_MTD_BEECH $CONFIG_MTD_CFI
fi
+ if [ "$CONFIG_ARCTIC2" = "y" ]; then
+ dep_tristate ' CFI Flash device mapped on IBM Arctic' CONFIG_MTD_ARCTIC $CONFIG_MTD_CFI
+ fi
dep_tristate ' CFI Flash device mapped on D-Box2' CONFIG_MTD_DBOX2 $CONFIG_MTD_CFI
dep_tristate ' CFI Flash device mapping on FlagaDM' CONFIG_MTD_CFI_FLAGADM $CONFIG_MTD_CFI
fi
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/drivers/mtd/maps/Makefile linux-bartholomew/drivers/mtd/maps/Makefile
--- /home/dgibson/kernel/linuxppc_2_4_devel/drivers/mtd/maps/Makefile 2002-09-13 16:08:05.000000000 +1000
+++ linux-bartholomew/drivers/mtd/maps/Makefile 2002-12-12 15:28:08.000000000 +1100
@@ -44,5 +44,6 @@
obj-$(CONFIG_MTD_MOT_MVP) += mot-mvp.o
obj-$(CONFIG_MTD_EBONY) += ebony.o
obj-$(CONFIG_MTD_BEECH) += beech-mtd.o
+obj-$(CONFIG_MTD_ARCTIC) += arctic-mtd.o
include $(TOPDIR)/Rules.make
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/drivers/mtd/maps/arctic-mtd.c linux-bartholomew/drivers/mtd/maps/arctic-mtd.c
--- /home/dgibson/kernel/linuxppc_2_4_devel/drivers/mtd/maps/arctic-mtd.c Thu Jan 01 10:00:00 1970
+++ linux-bartholomew/drivers/mtd/maps/arctic-mtd.c Mon Dec 16 13:08:02 2002
@@ -0,0 +1,168 @@
+/*
+ * drivers/mtd/maps/arctic-mtd.c MTD mappings and partition tables for
+ * IBM 405LP Arctic boards.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Copyright (C) 2002, International Business Machines Corporation
+ * All Rights Reserved.
+ *
+ * Bishop Brock
+ * IBM Research, Austin Center for Low-Power Computing
+ * bcbrock@us.ibm.com
+ * March 2002
+ *
+ * modified for Arctic by,
+ * David Gibson
+ * IBM OzLabs, Canberra, Australia
+ * <arctic@gibson.dropbear.id.au>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/types.h>
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+
+#include <asm/io.h>
+#include <asm/ibm4xx.h>
+
+#define ARCTIC_FFS_SIZE 0x1a00000 /* 26 M */
+
+#define NAME "Arctic Linux Flash"
+#define PADDR SUBZERO_BOOTFLASH_PADDR
+#define SIZE SUBZERO_BOOTFLASH_SIZE
+#define BUSWIDTH 2
+
+/* Flash memories on these boards are memory resources, accessed big-endian. */
+
+static u8
+arctic_mtd_read8(struct map_info *map, unsigned long offset)
+{
+ return __raw_readb(map->map_priv_1 + offset);
+}
+
+static u16
+arctic_mtd_read16(struct map_info *map, unsigned long offset)
+{
+ return __raw_readw(map->map_priv_1 + offset);
+}
+
+static u32
+arctic_mtd_read32(struct map_info *map, unsigned long offset)
+{
+ return __raw_readl(map->map_priv_1 + offset);
+}
+
+static void
+arctic_mtd_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
+{
+ memcpy_fromio(to, (void *) (map->map_priv_1 + from), len);
+}
+
+static void
+arctic_mtd_write8(struct map_info *map, u8 data, unsigned long address)
+{
+ __raw_writeb(data, map->map_priv_1 + address);
+ mb();
+}
+
+static void
+arctic_mtd_write16(struct map_info *map, u16 data, unsigned long address)
+{
+ __raw_writew(data, map->map_priv_1 + address);
+ mb();
+}
+
+static void
+arctic_mtd_write32(struct map_info *map, u32 data, unsigned long address)
+{
+ __raw_writel(data, map->map_priv_1 + address);
+ mb();
+}
+
+static void
+arctic_mtd_copy_to(struct map_info *map,
+ unsigned long to, const void *from, ssize_t len)
+{
+ memcpy_toio((void *) (map->map_priv_1 + to), from, len);
+}
+
+static struct map_info arctic_mtd_map = {
+ .name = NAME,
+ .size = SIZE,
+ .buswidth = BUSWIDTH,
+ .read8 = arctic_mtd_read8,
+ .read16 = arctic_mtd_read16,
+ .read32 = arctic_mtd_read32,
+ .copy_from = arctic_mtd_copy_from,
+ .write8 = arctic_mtd_write8,
+ .write16 = arctic_mtd_write16,
+ .write32 = arctic_mtd_write32,
+ .copy_to = arctic_mtd_copy_to,
+};
+
+static struct mtd_info *arctic_mtd;
+
+static struct mtd_partition arctic_partitions[2] = {
+ { .name = "Arctic FFS",
+ .size = ARCTIC_FFS_SIZE,
+ .offset = 0,},
+ { .name = "Kernel & firmware",
+ .size = (SUBZERO_BOOTFLASH_SIZE - ARCTIC_FFS_SIZE),
+ .offset = ARCTIC_FFS_SIZE,},
+};
+
+static int __init
+init_arctic_mtd(void)
+{
+ printk("%s: 0x%08x at 0x%08x\n", NAME, SIZE, PADDR);
+
+ arctic_mtd_map.map_priv_1 = (unsigned long) ioremap(PADDR, SIZE);
+
+ if (!arctic_mtd_map.map_priv_1) {
+ printk("%s: failed to ioremap 0x%x\n", NAME, PADDR);
+ return -EIO;
+ }
+
+ printk("%s: probing %d-bit flash bus\n", NAME, BUSWIDTH * 8);
+ arctic_mtd = do_map_probe("cfi_probe", &arctic_mtd_map);
+
+ if (!arctic_mtd)
+ return -ENXIO;
+
+ arctic_mtd->module = THIS_MODULE;
+
+ return add_mtd_partitions(arctic_mtd, arctic_partitions, 2);
+}
+
+static void __exit
+cleanup_arctic_mtd(void)
+{
+ if (arctic_mtd) {
+ del_mtd_partitions(arctic_mtd);
+ map_destroy(arctic_mtd);
+ iounmap((void *) arctic_mtd_map.map_priv_1);
+ }
+}
+
+module_init(init_arctic_mtd);
+module_exit(cleanup_arctic_mtd);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("David Gibson <arctic@gibson.dropbear.id.au>");
+MODULE_DESCRIPTION("MTD map and partitions for IBM 405LP Arctic boards");
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: installing Predict on a RedHat 7.3 box , no go :^(
From: Nate Bargmann @ 2002-12-16 2:02 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <200212151628.02870.n7bfs@qwest.net>
* Douglas Cole <n7bfs@qwest.net> [2002 Dec 15 18:35 -0600]:
> [root@n7bfs predict-2.2.1]# ./configure
> One moment please... installer.c:16:20: curses.h: No such file or directory
> Compilation failed. Are you sure you have a C compiler (gcc) installed?
> [root@n7bfs predict-2.2.1]#
>
>
> Now , what I get from that is that my node box does not have curses installed.
>
> Hmm , so I check and sure enough it has "ncurses" installed , but not curses,
> so I check all 3 install cd's and none have a curses package on them , so I
> check the SuSE install dvd and sure enough -it- has it!
Most likely your system is lacking the ncurses development package. To
keep installation size smaller the binary library and files needed for
compiling packages that use the binary library are in seperate packages.
So, just install ncurses-dev or something similar and you should be
fine.
73, de Nate >>
--
Wireless | Amateur Radio Station N0NB | "We have awakened a
Internet | n0nb@networksplus.net | sleeping giant and
Location | Bremen, Kansas USA EM19ov | have instilled in him
Amateur radio exams; ham radio; Linux info @ | a terrible resolve".
http://www.qsl.net/n0nb/ | - Admiral Yamamoto
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: David Gibson @ 2002-12-16 1:58 UTC (permalink / raw)
To: Todd Poynor, linuxppc-embedded
In-Reply-To: <20021215073549.GB16755@zax.zax>
On Sun, Dec 15, 2002 at 06:35:49PM +1100, David Gibson wrote:
> > CONFIG_IBM_OPENBIOS is taken out of the CONFIG_SYCAMORE section of
> > arch/ppc/config.in?
>
> Err... I have no idea what you're asking. How did SYCAMORE get into
> this?
>
> > Duplication of the CONFIG_BEECH case in
> > arch/ppc/boot/simple/embed_config.c: might be trying to enable the SSX
> > bootloader for Beech, but since CONFIG_IBM_OPENBIOS is on for Beech it
> > seems we'd have dup definitions? Would more SSX code would be necessary
> > anyhow?
>
> Again, I'm afraid I'm having trouble parsing that paragraph - what do
> you want to know?
Gah, ok, now I see what you're talking about: the diffs to the
SYCMORE config and the extra beech code in my patch. Yes, as you
probably suspected they were just mistakes - now corrected.
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: installing Predict on a RedHat 7.3 box , no go :^(
From: Douglas Cole @ 2002-12-16 1:56 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <200212151628.02870.n7bfs@qwest.net>
On Sunday 15 December 2002 16:28, Douglas Cole wrote:
> Ok , I must admit to not being very good at installing something if its
> not in a RPM form , so when I tried to install Predict on a SuSE 8.0 box
> and it went flawlessly I got rather overconfident and tried to install it
> on my RedHat IRLP node box , so I could let it run as a server 24/7 since
> that machine is always on , and has alot of process time doing nothing...
>
> BUT , it will not even begin to install :^(
> here is what I get when I try to run ./configure on the RedHat box...
>
> [root@n7bfs predict-2.2.1]# ./configure
> One moment please... installer.c:16:20: curses.h: No such file or directory
> Compilation failed. Are you sure you have a C compiler (gcc) installed?
> [root@n7bfs predict-2.2.1]#
>
Well , I figured it out , apparently I needed to install the development
package for ncurses which I found on rpmfind.net , once I did that it took
right off ...
Since the node box has a small drive I didn't install the "developement"
packages, and I downloaded the Redhat ISO's from linuxiso.org , the sources
were not complete since I only burnt the first three disk's , so anywho , all
is well , and I am in the process of setting it up to work on my IRLP node
box , then will make it automagically update the kep's , then I won't have to
think about it again :)
Boy do I like Linux :^))
>
> Now , what I get from that is that my node box does not have curses
> installed.
>
> Hmm , so I check and sure enough it has "ncurses" installed , but not
> curses, so I check all 3 install cd's and none have a curses package on
> them , so I check the SuSE install dvd and sure enough -it- has it!
>
> So my general question is , has anyone who is using the latest version of
> predict running it on a RedHat box and if so what did you have to do to
> make it happen ?
>
> I have done a search on rpmfind.net and have not found any curses packages
> for Redhat , which seems kinda confusing , but not surprising .
>
> Or could someone point me in the direction of a how-to/info page that would
> help me figure out how to install curses from sources so I don't need a
> stinking RPM file to install curses on my node box ;^}
> Or maybe I just didn't install RedHat properly...
>
> tia for any input!
--
Douglas Cole N7BFS
AMSAT#26182 , K2 # 544
http://www.users.qwest.net/~cdoug3
Registered Linux user # 188922
^ permalink raw reply
* big load
From: Milan Roubal @ 2002-12-16 1:54 UTC (permalink / raw)
To: linux-kernel
Hi,
I have got server runnig 5 days and now its doing this:
2:48am up 5 days, 11:23, 2 users, load average: 19.97, 15.70, 10.63
61 processes: 60 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states: 0.0% user, 8.1% system, 0.0% nice, 91.4% idle
CPU1 states: 0.0% user, 0.1% system, 0.0% nice, 99.4% idle
I can't understand where I can got so big load
processor is idle all the time, but load is going higher and higher.
2:50am up 5 days, 11:24, 2 users, load average: 21.45, 17.45, 11.80
62 processes: 61 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
CPU1 states: 0.0% user, 0.1% system, 0.0% nice, 99.4% idle
my process:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
13782 root 13 0 892 892 696 R 0.2 0.0 0:00 top
1 root 20 0 84 84 52 S 0.0 0.0 0:11 init
2 root 20 0 0 0 0 SW 0.0 0.0 0:00 keventd
3 root 20 19 0 0 0 SWN 0.0 0.0 0:03 ksoftirqd_CPU0
4 root 20 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU1
5 root 20 0 0 0 0 SW 0.0 0.0 17:22 kswapd
6 root 0 0 0 0 0 SW 0.0 0.0 1:45 bdflush
7 root 20 0 0 0 0 SW 0.0 0.0 33:48 kupdated
8 root 20 0 0 0 0 SW 0.0 0.0 0:00 kinoded
11 root 0 -20 0 0 0 SW< 0.0 0.0 0:00 mdrecoveryd
14 root 20 0 0 0 0 SW 0.0 0.0 0:03 kreiserfsd
51 root 20 -20 0 0 0 SW< 0.0 0.0 11:20 raid5d
245 root 20 0 0 0 0 DW 0.0 0.0 0:09 pagebuf_daemon
388 root 20 0 316 316 208 S 0.0 0.0 0:00 syslogd
391 root 20 0 440 440 216 S 0.0 0.0 0:00 klogd
427 root 20 0 0 0 0 SW 0.0 0.0 0:00 khubd
What could be wrong?
In log is only this message:
Dec 16 02:32:37 fileserver kernel: lease timed out
# /usr/local/samba/bin/smbd -V
Version 2.2.6
System is 2.4.18-3 from SuSE,
SuSE 8.1 distribution.
Filesystem XFS on 1TB RAID5 array
Thanx
Milan Roubal
^ permalink raw reply
* Re: increase base memory
From: Stas Sergeev @ 2002-12-16 1:45 UTC (permalink / raw)
To: linux-msdos
Hello.
kandan bala wrote:
> I came to know the dosemu reserves A000 segment
> reserved for graphics.
> Is it possible to shift OR change another segment
> for graphics.
Ralf Brown memory.lst states:
--------V-MA0000000--------------------------
MEM A000h:0000h - EGA+ GRAPHICS BUFFER
Size: 65536 BYTEs
So it was always there. QEMM have a
program called "vidram", which allows
to use that region as a base memory
by the cost of not being able to diplay
graphics, but vidram will not work
under dosemu because qemm itself doesn't
work under dosemu.
> Is it logically correct.
But how are you running your program
at a pure dos at first (i.e. not
under linux/dosemu)? If your program
works only with QEMM's vidram or something
similar, then your program is broken
at a first place.
Dosemu allows you to use both UMB and
HMA, so there should be no disadvantages
against the pure dos (except that QEMM
with all its wonderfull tricks can't
be used).
> and running a cobol application.
I don't know what cobol was used, but
if it is a MicroFocus cobol, they
provide a DOS extender for it called xm,
wich will let the program to use all
the memory available for DPMI.
Increasing the base memory above 640Kb
is definitely the bad idea, as it is
used very rarely even in a pure DOS
and will cost you the inability to
display graphics.
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: David Gibson @ 2002-12-16 1:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Cort Dougan, Tom Rini, linuxppc-embedded
In-Reply-To: <15869.5023.549830.146265@argo.ozlabs.ibm.com>
On Mon, Dec 16, 2002 at 10:43:27AM +1100, Paul Mackerras wrote:
>
> Cort Dougan writes:
>
> > How about killing the _2_4_devel tree? When I created it I want it to be a
> > playground for stabilizing then moving things over to 2_4 failry quickly.
> > It seems to have become the defacto "want board X, you better use
> > _2_4_devel" tree.
>
> Now that Marcelo is using BK, what I would really like to do is to
> kill both the linuxppc_2_4 and linuxppc_2_4_devel trees and move to a
> tree that is a child of Marcelo's linux-2.4 tree.
>
> > When I went looking for a working 4xx tree recently I had to write a script
> > that would go through the last year of changesets in _2_4 and _2_4_devel
> > and try to build them then stick the result into a file. That ran for 7
> > days on a 2.0Ghz Dual x86. Then, that only gave me a list of building
> > trees. Knowing that there's only 1 tree would be much easier!
>
> 4xx in particular is a problem because I'm not convinced about the
> approach that has been taken for some of the 4xx infrastructure. The
> ocp stuff seems a lot more complicated than it needs to be, for
> instance. There is no particular reason that I can see why the 8xx
> stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.
Well, it sounds as if linuxppc_2_4_devel is the place to commit the
Arctic2 code. Killing that tree off, by whatever means, sounds like a
very good idea, but not actually something that committing my code
elsewhere would help to accomplish.
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: 2 (minor) Alpha probs in 2.5.51
From: Richard Henderson @ 2002-12-16 1:38 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: linux-kernel
In-Reply-To: <20021216003327.GC709@gallifrey>
On Mon, Dec 16, 2002 at 12:33:27AM +0000, Dr. David Alan Gilbert wrote:
> arch/alpha/kernel/built-in.o(.data+0x3030): undefined reference to
> `cia_bwx_inb'
> arch/alpha/kernel/built-in.o(.data+0x3038): undefined reference to
> `cia_bwx_inw'
Fixed in current TOT.
> 2) This is a kind of subtle one. Straight after boot up if I run 'w'
> or 'top' I get the warning:
>
> Unknown HZ value! (831) Assume 1024.
>
> This value creeps up:
>
> Unknown HZ value! (958) Assume 1024.
>
> over a period of a few minutes till the warning goes away.
Dunno. Could be your clock chip is going bad.
r~
^ permalink raw reply
* [Linux-ia64] gas generates incorrect ia64 unwind rlen values
From: Keith Owens @ 2002-12-16 1:24 UTC (permalink / raw)
To: linux-ia64
Using binutils-2.11.90.0.8-12 (old I know, but it is the only version
supported on Redhat ia64), the rlen field in the body part of the
unwind descriptors is incorrect, it is short of the real body size.
Any function calls after the short body rlen are unwound incorrectly.
The unwind code is correct but the invalid rlen makes unwind think that
the calling function has reached its epilogue. That results in an
attempt to unwind using the 'return address' in b0 which is no longer
valid.
Commands to demonstrate the problem. Kernel is a native compile of
2.4.19-ia64-020821 plus SGI changes, the SGI changes have not touched
unwind or binutils. I have also verified the bug on a standard
2.4.19-ia64-020821 kernel, using both native and 386->ia64 cross
compilers.
For system verification reasons, upgrading to binutils 2.13 is not an
option. Also a check of the binutils changelog, mailing list archives
and bugzilla found no mention of this bug, AFAICT 2.13 has no fix.
# cd arch/ia64/kernel
# gcc -D__KERNEL__ -I/usr/src/redhat/lbs/linux/include -Wall \
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing \
-fno-common -fomit-frame-pointer -pipe -ffixed-r13 \
-mfixed-rangeñ0-f15,f32-f127 -falign-functions2 \
-DSGI_SN_EXECUTABLE_STACKS -mconstant-gp -nostdinc \
-I /usr/lib/gcc-lib/ia64-redhat-linux/2.96/include \
-DKBUILD_BASENAME=traps -c -o traps.o traps.c -v
Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.7.2)
/usr/lib/gcc-lib/ia64-redhat-linux/2.96/cpp0 -lang-c -nostdinc -v \
-I/usr/src/redhat/lbs/linux/include \
-I /usr/lib/gcc-lib/ia64-redhat-linux/2.96/include \
-D__GNUC__=2 -D__GNUC_MINOR__– -D__GNUC_PATCHLEVEL__=0 \
-D__ia64 -D__ia64__ -D__linux -D__linux__ -D_LONGLONG -Dlinux \
-Dunix -D__LP64__ -D__ELF__ -D__ia64 -D__ia64__ -D__linux \
-D__linux__ -D_LONGLONG -D__linux__ -D__unix__ -D__LP64__ \
-D__ELF__ -D__linux -D__unix -Asystem(linux) -Acpu(ia64) \
-Amachine(ia64) -D__OPTIMIZE__ -Wall -Wstrict-prototypes \
-Wno-trigraphs -D__LONG_MAX__’23372036854775807L -D__KERNEL__ \
-DSGI_SN_EXECUTABLE_STACKS -DKBUILD_BASENAME=traps traps.c | \
/usr/lib/gcc-lib/ia64-redhat-linux/2.96/cc1 -mb-step -quiet -dumpbase \
traps.c -mfixed-rangeñ0-f15,f32-f127 -mconstant-gp -O2 -Wall \
-Wstrict-prototypes -Wno-trigraphs -version -fno-strict-aliasing \
-fno-common -fomit-frame-pointer -ffixed-r13 \
-falign-functions2 -o - | \
as -x -mconstant-gp -o traps.o -
GNU CPP version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.7.2) (cpplib) (IA-64)
#include "..." search starts here:
#include <...> search starts here:
/usr/src/redhat/lbs/linux/include
/usr/lib/gcc-lib/ia64-redhat-linux/2.96/include
End of search list.
GNU C version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.7.2) (ia64-redhat-linux) compiled by GNU C version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.7.2).
bash-2.05# as -v
GNU assembler version 2.11.90.0.8 (ia64-redhat-linux) using BFD version 2.11.90.0.8
Using the 2.13 readelf to print the unwind data. readelf is correct,
the encoded rlen in unwind info really is 475.
# /usr/src/redhat/BUILD/binutils-2.13.90.0.2/binutils/readelf -u traps.o
Unwind section '.IA_64.unwind' at offset 0x2600 contains 8 entries:
...
<ia64_fault>: [0x1300-0x1dd0), info at +0xc8
v1, flags=0x0 ( ), len\x16 bytes
R2:prologue_gr(mask=[rp,ar.pfs],grsave=r37,rlen=8)
P7:pfs_when(t=0)
P7:mem_stack_f(t=2,size%6)
P7:rp_when(t=7)
R3:body(rlenG5)
B2:epilogue(t=2,ecount=0)
R1:prologue(rlen=0)
ia64_fault is 2768 bytes long, 519 slots. The total of the prologue
and body rlen is only 483 slots. Any calls past slot 483 are not
unwound correctly. Unfortunately that includes the call to
die_if_kernel().
# /usr/src/redhat/BUILD/binutils-2.13.90.0.2/binutils/objdump -Sr traps.o
...
0000000000001300 <ia64_fault>:
1300: 0c 30 31 0e 80 05 [MFI] alloc r38=ar.pfs,12,7,0
1306: 00 00 00 02 00 80 nop.f 0x0
130c: 01 60 f8 8c adds r12=-256,r12
1310: 04 00 00 00 01 00 [MLX] nop.m 0x0
1316: 00 08 00 00 00 c0 movl r14=0x80000000f
131c: f1 00 00 60
1320: 02 00 00 00 01 00 [MII] nop.m 0x0
1326: 50 02 00 62 00 c0 mov r37°;;
== 8 slots, end of prologue, correct
132c: e1 08 31 80 and r14=r14,r33
1330: 05 00 00 00 01 00 [MLX] nop.m 0x0
1336: 00 08 00 00 00 e0 movl r15=0x800000004;;
133c: 41 00 00 60
.......
1cd2: PCREL21B printk
1cd6: 00 00 00 02 00 00 nop.f 0x0
1cdc: 08 00 00 50 br.call.sptk.many b0\x1cd0 <ia64_fault+0x9d0>;;
1ce0: 01 70 20 48 00 21 [MII] adds r14=8,r36
1ce1: LTOFF22 .LC40
1ce6: 70 02 04 00 48 20 addl r39=0,r1
1cec: 05 10 01 84 mov r41=r34;;
1cf0: 08 40 01 1c 18 10 [MMI] ld8 r40=[r14]
1cf6: 70 02 9c 30 20 40 ld8 r39=[r39]
1cfc: 05 08 01 84 mov r42=r33
1d00: 1d 58 01 46 00 21 [MFB] mov r43=r35
1d02: PCREL21B printk
1d06: 00 00 00 02 00 00 nop.f 0x0
1d0c: 08 00 00 50 br.call.sptk.many b0\x1d00 <ia64_fault+0xa00>;;
== unwind says this (slot 483) is end of body, wrong!
1d10: 11 38 2d 00 00 24 [MIB] mov r39\x11
1d12: PCREL21B force_sig
1d16: 80 02 34 00 42 00 mov r40=r13
1d1c: 08 00 00 50 br.call.sptk.many b0\x1d10 <ia64_fault+0xa10>;;
1d20: 1c 00 00 00 01 00 [MFB] nop.m 0x0
1d26: 00 00 00 02 00 00 nop.f 0x0
1d2c: 90 00 00 40 br.few 1db0 <ia64_fault+0xab0>
1d30: 01 10 41 18 01 21 [MII] adds r34\x144,r12
1d31: LTOFF22 .LC41
1d36: 80 02 04 00 48 20 addl r40=0,r1
1d3c: 05 0a bd 52 shr.u r41=r33,16;;
1d40: 19 38 01 44 00 21 [MMB] mov r39=r34
1d42: PCREL21B sprintf
1d46: 80 02 a0 30 20 00 ld8 r40=[r40]
1d4c: 08 00 00 50 br.call.sptk.many b0\x1d40 <ia64_fault+0xa40>;;
1d50: 1c 00 00 00 01 00 [MFB] nop.m 0x0
1d56: 00 00 00 02 00 00 nop.f 0x0
1d5c: 30 00 00 40 br.few 1d80 <ia64_fault+0xa80>
1d60: 01 10 41 18 01 21 [MII] adds r34\x144,r12
1d61: LTOFF22 .LC42
1d66: 80 02 04 00 48 20 addl r40=0,r1
1d6c: 05 00 01 84 mov r41=r32;;
1d70: 19 38 01 44 00 21 [MMB] mov r39=r34
1d72: PCREL21B sprintf
1d76: 80 02 a0 30 20 00 ld8 r40=[r40]
1d7c: 08 00 00 50 br.call.sptk.many b0\x1d70 <ia64_fault+0xa70>;;
1d80: 00 38 01 44 00 21 [MII] mov r39=r34
1d86: 80 02 90 00 42 20 mov r40=r36
1d8c: 05 08 01 84 mov r41=r33
1d90: 1d 00 00 00 01 00 [MFB] nop.m 0x0
== this call to die_if_kernel() is treated as post epilogue and unwind gives up
1d92: PCREL21B die_if_kernel
1d96: 00 00 00 02 00 00 nop.f 0x0
1d9c: 08 00 00 50 br.call.sptk.many b0\x1d90 <ia64_fault+0xa90>;;
1da0: 11 38 11 00 00 24 [MIB] mov r39=4
1da2: PCREL21B force_sig
1da6: 80 02 34 00 42 00 mov r40=r13
1dac: 08 00 00 50 br.call.sptk.many b0\x1da0 <ia64_fault+0xaa0>;;
1db0: 00 00 00 00 01 00 [MII] nop.m 0x0
1db6: 00 30 01 55 00 00 mov.i ar.pfs=r38
1dbc: 50 0a 00 07 mov b0=r37
1dc0: 1d 60 00 18 02 21 [MFB] adds r12%6,r12
1dc6: 00 00 00 02 00 80 nop.f 0x0
1dcc: 08 00 84 00 br.ret.sptk.many b0;;
1dd0: 0c 00 00 00 01 00 [MFI] nop.m 0x0
1dd6: 00 00 00 02 00 00 nop.f 0x0
1ddc: 00 00 04 00 nop.i 0x0
^ permalink raw reply
* (unknown),
From: ray @ 2002-12-16 1:15 UTC (permalink / raw)
To: linux-smp
1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
CPU: After vendor init, caps: 3febfbff 00000000 00000000 00000000
Intel machine check reporting enabled on CPU#2.
CPU: After generic, caps: 3febfbff 00000000 00000000 00000000
CPU: Common caps: 3febfbff 00000000 00000000 00000000
CPU2: Intel(R) XEON(TM) CPU 2.40GHz stepping 04
Booting processor 3/7 eip 2000
Initializing CPU#3
masked ExtINT on CPU#3
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 4784.26 BogoMIPS
CPU: Before vendor init, caps: 3febfbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 0K, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
CPU: After vendor init, caps: 3febfbff 00000000 00000000 00000000
Intel machine check reporting enabled on CPU#3.
CPU: After generic, caps: 3febfbff 00000000 00000000 00000000
CPU: Common caps: 3febfbff 00000000 00000000 00000000
CPU3: Intel(R) XEON(TM) CPU 2.40GHz stepping 04
Total of 4 processors activated (19103.65 BogoMIPS).
cpu_sibling_map[0] = 1
cpu_sibling_map[1] = 0
cpu_sibling_map[2] = 3
cpu_sibling_map[3] = 2
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
Setting 3 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 3 ... ok.
Setting 4 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 4 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-17, 2-20, 2-23, 3-0, 3-1, 3-2,
3-3, 3-4, 3-5, 3-6, 3-7, 3-8, 3-9, 3-10, 3-11, 3-12, 3-13, 3-14, 3-15, 3-16,
3-17, 3-18, 3-19, 3-20, 3-21, 3-22, 3-23, 4-0, 4-1, 4-2, 4-3, 4-4, 4-5, 4-7,
4-8, 4-9, 4-10, 4-11, 4-12, 4-13, 4-14, 4-15, 4-16, 4-17, 4-18, 4-19, 4-20,
4-21, 4-22, 4-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 19.
number of IO-APIC #2 registers: 24.
number of IO-APIC #3 registers: 24.
number of IO-APIC #4 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02008000
....... : physical APIC id: 02
WARNING: unexpected IO-APIC, please mail
to linux-smp@vger.kernel.org
.... register #01: 00178020
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0020
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 00F 0F 0 0 0 0 0 1 1 39
02 008 08 0 0 0 0 0 1 1 31
03 00F 0F 0 0 0 0 0 1 1 41
04 00F 0F 0 0 0 0 0 1 1 49
05 000 00 1 0 0 0 0 0 0 00
06 00F 0F 0 0 0 0 0 1 1 51
07 00F 0F 0 0 0 0 0 1 1 59
08 00F 0F 0 0 0 0 0 1 1 61
09 00F 0F 0 0 0 0 0 1 1 69
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 00F 0F 0 0 0 0 0 1 1 71
0d 00F 0F 0 0 0 0 0 1 1 79
0e 00F 0F 0 0 0 0 0 1 1 81
0f 00F 0F 0 0 0 0 0 1 1 89
10 00F 0F 1 1 0 1 0 1 1 91
11 000 00 1 0 0 0 0 0 0 00
12 00F 0F 1 1 0 1 0 1 1 99
13 00F 0F 1 1 0 1 0 1 1 A1
14 000 00 1 0 0 0 0 0 0 00
15 00F 0F 1 1 0 1 0 1 1 A9
16 00F 0F 1 1 0 1 0 1 1 B1
17 000 00 1 0 0 0 0 0 0 00
IO APIC #3......
.... register #00: 03000000
....... : physical APIC id: 03
.... register #01: 00178020
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0020
.... register #02: 03000000
....... : arbitration: 03
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 000 00 1 0 0 0 0 0 0 00
02 000 00 1 0 0 0 0 0 0 00
03 000 00 1 0 0 0 0 0 0 00
04 000 00 1 0 0 0 0 0 0 00
05 000 00 1 0 0 0 0 0 0 00
06 000 00 1 0 0 0 0 0 0 00
07 000 00 1 0 0 0 0 0 0 00
08 000 00 1 0 0 0 0 0 0 00
09 000 00 1 0 0 0 0 0 0 00
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 000 00 1 0 0 0 0 0 0 00
0e 000 00 1 0 0 0 0 0 0 00
0f 000 00 1 0 0 0 0 0 0 00
10 000 00 1 0 0 0 0 0 0 00
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IO APIC #4......
.... register #00: 04000000
....... : physical APIC id: 04
.... register #01: 00178020
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0020
.... register #02: 04000000
....... : arbitration: 04
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 000 00 1 0 0 0 0 0 0 00
02 000 00 1 0 0 0 0 0 0 00
03 000 00 1 0 0 0 0 0 0 00
04 000 00 1 0 0 0 0 0 0 00
05 000 00 1 0 0 0 0 0 0 00
06 00F 0F 1 1 0 1 0 1 1 B9
07 000 00 1 0 0 0 0 0 0 00
08 000 00 1 0 0 0 0 0 0 00
09 000 00 1 0 0 0 0 0 0 00
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 000 00 1 0 0 0 0 0 0 00
0e 000 00 1 0 0 0 0 0 0 00
0f 000 00 1 0 0 0 0 0 0 00
10 000 00 1 0 0 0 0 0 0 00
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ18 -> 0:18
IRQ19 -> 0:19
IRQ21 -> 0:21
IRQ22 -> 0:22
IRQ54 -> 2:6
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 2395.1076 MHz.
..... host bus clock speed is 99.1591 MHz.
cpu: 0, clocks: 194938, slice: 38987
CPU0<T0:194928,T1:155936,D:5,S:38987,C:194938>
cpu: 1, clocks: 194938, slice: 38987
cpu: 3, clocks: 194938, slice: 38987
cpu: 2, clocks: 194938, slice: 38987
CPU1<T0:194928,T1:116944,D:10,S:38987,C:194938>
CPU2<T0:194928,T1:77936,D:31,S:38987,C:194938>
CPU3<T0:194928,T1:38976,D:4,S:38987,C:194938>
checking TSC synchronization across CPUs: passed.
migration_task 0 on cpu=0
migration_task 1 on cpu=1
migration_task 2 on cpu=2
migration_task 3 on cpu=3
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs
PCI: PCI BIOS revision 2.10 entry at 0xfd8b5, last bus=4
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 2: assuming transparent
Unknown bridge resource 2: assuming transparent
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Discovered primary peer bus 10 [IRQ]
PCI: Discovered primary peer bus 11 [IRQ]
PCI: Discovered primary peer bus 12 [IRQ]
PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0
PCI->APIC IRQ transform: (B0,I29,P0) -> 16
PCI->APIC IRQ transform: (B0,I29,P1) -> 19
PCI->APIC IRQ transform: (B0,I29,P2) -> 18
PCI->APIC IRQ transform: (B2,I3,P0) -> 54
PCI->APIC IRQ transform: (B4,I4,P0) -> 21
PCI->APIC IRQ transform: (B4,I5,P0) -> 22
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
speakup: initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16)
apm: disabled - APM is not SMP safe.
Starting kswapd
allocated 64 pages and 64 bhs reserved for the highmem bounces
VFS: Diskquotas version dquot_6.5.0 initialized
Detected PS/2 Mouse Port.
pty: 2048 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ
SERIAL_PCI ISAPNP enabled
ttyS0 at 0x03f8 (irq = 4) is a 16550A
ttyS1 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10e
oprofile: can't get RTC I/O Ports
block: 1024 slots per queue, batch=256
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev f9
PCI: Enabling device 00:1f.1 (0005 -> 0007)
PCI: No IRQ known for interrupt pin A of device 00:1f.1. Probably buggy MP table.
PIIX4: chipset revision 2
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x2060-0x2067, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x2068-0x206f, BIOS settings: hdc:pio, hdd:pio
hda: WDC WD400JB-00ENA0, ATA DISK drive
hdc: CDU5211, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c0438b04, I/O limit 4095Mb (mask 0xffffffff)
blk: queue c0438b04, I/O limit 4095Mb (mask 0xffffffff)
hda: 78165360 sectors (40021 MB) w/8192KiB Cache, CHS=77545/16/63, UDMA(100)
ide-floppy driver 0.99.newide
Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
NET4: Frame Diverter 0.46
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
ide-floppy driver 0.99.newide
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
pci_hotplug: PCI Hot Plug PCI Core version: 0.4
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 129k freed
VFS: Mounted root (ext2 filesystem).
Journalled Block Device driver loaded
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Freeing unused kernel memory: 240k freed
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.275 $ time 12:50:27 Sep 4 2002
usb-uhci.c: High bandwidth mode enabled
PCI: Setting latency timer of device 00:1d.0 to 64
usb-uhci.c: USB UHCI at I/O 0x2000, IRQ 16
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Setting latency timer of device 00:1d.1 to 64
usb-uhci.c: USB UHCI at I/O 0x2020, IRQ 19
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Setting latency timer of device 00:1d.2 to 64
usb-uhci.c: USB UHCI at I/O 0x2040, IRQ 18
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 3
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
usb.c: registered new driver hiddev
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
EXT3 FS 2.4-0.9.18, 14 May 2002 on ide0(3,6), internal journal
Adding Swap: 2047744k swap-space (priority -1)
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.18, 14 May 2002 on ide0(3,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.18, 14 May 2002 on ide0(3,5), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.18, 14 May 2002 on ide0(3,2), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.18, 14 May 2002 on ide0(3,7), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
ohci1394: pci_module_init failed
ip_tables: (C) 2000-2002 Netfilter core team
Intel(R) PRO/1000 Network Driver - version 4.3.2-k1 NAPI (020618)
Copyright (c) 1999-2002 Intel Corporation.
divert: allocating divert_blk for eth0
eth0: Intel(R) PRO/1000 Network Connection
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
<saw@saw.sw.com.sg> and others
divert: allocating divert_blk for eth1
eth1: OEM i82557/i82558 10/100 Ethernet, 00:30:48:20:11:3E, IRQ 22.
Board assembly 000000-000, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0xd0a6c714).
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
^ permalink raw reply
* increase base memory
From: kandan bala @ 2002-12-16 1:12 UTC (permalink / raw)
To: linux-msdos
Hello,
I am using dosemu-1.0.1.0 and running a cobol
application. The application quits when I selected
some options, like F1-HELP due to insuffecient base
memory. I changed the xms,ems and dpmi memory also.
There is no use. Then I set base memory to 704Kb and
the program running well in text mode. If I run xdos
OR dos -X then dosemu quits with sigsegv.
ERROR: general protection at 0xae580: c6
ERROR: SIGSEGV, protected insn...exiting!
I came to know the dosemu reserves A000 segment
reserved for graphics.
Is it possible to shift OR change another segment
for graphics.If so, I get 64K additional base memory.
Is it logically correct.I am expecting help to get
more base memory.
Regards
Kandan
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
^ permalink raw reply
* Re: freemaps
From: William Lee Irwin III @ 2002-12-16 1:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ingo Molnar, Frederic Rossi (LMC), linux-mm
In-Reply-To: <3DFD266A.422CB70C@digeo.com>
On Sun, Dec 15, 2002 at 01:03:26AM -0800, Andrew Morton wrote:
>>> - How does it play with non-linear mappings?
William Lee Irwin III wrote:
>> It doesn't care; they're just vma's parked on a virtual address range
>> like the rest of them.
On Sun, Dec 15, 2002 at 05:03:38PM -0800, Andrew Morton wrote:
> But the searching needs are different. If someone has a nonlinear mmap
> of the 0-1M region of a file and then requests an mmap of the 4-5M region,
> that can just be tacked onto the 0-1M mapping's vma (can't it?).
Well, that's more of a merging criterion that a search criterion. At
any rate, while it's true that they can/could be merged arbitrarily
since they're not actually associated with any particular file offset
range, there isn't any indicator I know of now that would actually
allow this distinction wrt. mergeability to be made.
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: freemaps
From: Andrew Morton @ 2002-12-16 1:03 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Ingo Molnar, Frederic Rossi (LMC), linux-mm
In-Reply-To: <20021216005103.GF2690@holomorphy.com>
William Lee Irwin III wrote:
>
> On Sun, Dec 15, 2002 at 01:03:26AM -0800, Andrew Morton wrote:
> > - How does it play with non-linear mappings?
>
> It doesn't care; they're just vma's parked on a virtual address range
> like the rest of them.
>
But the searching needs are different. If someone has a nonlinear mmap
of the 0-1M region of a file and then requests an mmap of the 4-5M region,
that can just be tacked onto the 0-1M mapping's vma (can't it?).
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: 2 (minor) Alpha probs in 2.5.51
From: Matt Reppert @ 2002-12-16 1:07 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: linux-kernel
In-Reply-To: <20021216003327.GC709@gallifrey>
On Mon, 16 Dec 2002 00:33:27 +0000
"Dr. David Alan Gilbert" <gilbertd@treblig.org> wrote:
> (This is with rth's exception patch to fix the mount problem).
>
> 1) If compiled for the LX164 platform it is missing a number of symbols
> at link time (fine if built generic):
>
> arch/alpha/kernel/built-in.o(.data+0x3030): undefined reference to
> `cia_bwx_inb'
> arch/alpha/kernel/built-in.o(.data+0x3038): undefined reference to
> `cia_bwx_inw'
> .
> .
> .
> (and a handful more)
I had this exact same problem the other day, and this is fixed in -bk now.
Remove the #include <asm/io.h> in include/asm/pci.h.
Matt
^ permalink raw reply
* Re: freemaps
From: William Lee Irwin III @ 2002-12-16 0:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ingo Molnar, Frederic Rossi (LMC), linux-mm
In-Reply-To: <3DFC455E.1FD92CBC@digeo.com>
On Sun, Dec 15, 2002 at 01:03:26AM -0800, Andrew Morton wrote:
> I expect this could be solved with two trees:
> - For searching, a radix-tree indexed by hole size. A list
> of same-sized holes at each leaf.
> - For insertion (where we must perform merging) an rbtree.
It's not quite that easy, because what this appears to suggest
would result in best fit, not address-ordered first fit.
My first thought is a length-constrained address minimization on a 2-d
tree, quadtree, or 2D k-d-b tree keyed on address and length; the
duelling tree solutions aren't really capable of providing O(lg(n))
guarantees for address-ordered first fit (or implementing address-
ordered first fit at all). I have no clue how to do this both
nonrecursively and without frequently-dirtied temporary node linkage,
though, as it appears to require a work stack (or potentially even a
queue for prioritized searches) like many other graph searches. Also,
I don't have a proof in hand that this is really O(lg(n)) worst-case,
though there are relatively obvious intuitive reasons to suspect so.
On Sun, Dec 15, 2002 at 01:03:26AM -0800, Andrew Morton wrote:
> But:
> - Do we need to keep the lists of same-sized holes sorted by
> virtual address, to avoid fragmentation?
Well, not so much to avoid fragmentation, but avoid worst cases.
On Sun, Dec 15, 2002 at 01:03:26AM -0800, Andrew Morton wrote:
> - Do all mm's incur all this stuff, or do we build it all when
> some threshold is crossed?
Not all incur these kinds of problems; but it is probably expensive
to build non-incrementally once the threshold is crossed.
On Sun, Dec 15, 2002 at 01:03:26AM -0800, Andrew Morton wrote:
> - How does it play with non-linear mappings?
It doesn't care; they're just vma's parked on a virtual address range
like the rest of them.
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: Cort Dougan @ 2002-12-16 0:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <15869.5023.549830.146265@argo.ozlabs.ibm.com>
} Now that Marcelo is using BK, what I would really like to do is to
} kill both the linuxppc_2_4 and linuxppc_2_4_devel trees and move to a
} tree that is a child of Marcelo's linux-2.4 tree.
I've been moving patches from the _2_4 and _2_4_devel ppc trees over to the
marcelo tree. I've love to see the switch so I don't have to do that!
} 4xx in particular is a problem because I'm not convinced about the
} approach that has been taken for some of the 4xx infrastructure. The
} ocp stuff seems a lot more complicated than it needs to be, for
} instance. There is no particular reason that I can see why the 8xx
} stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.
How about a linuxppc_2_4 that is a child of Marcelo's. Then a
linuxppc_2_4_4xx (and what have you) that is a child of the linuxppc_2_4
tree? It would make integration much much easier. Right now the
diff between _2_4 and _2_4_devel seems to be non-monotonically increasing.
I think it would be hard to arrest that growth without switching to a
Macelo based tree.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Linus Torvalds @ 2002-12-16 0:50 UTC (permalink / raw)
To: Joe Thornber; +Cc: Kevin Corry, Kernel Mailing List, lvm-devel
In-Reply-To: <20021211121749.GA20782@reti>
Guys, can you please re-send the split-up version of these patches, I'm
currently ignoring them simply because I don't know what the end result of
the discussion really ended up being..
Linus
^ permalink raw reply
* Re: Mirrored Display?
From: Michel Dänzer @ 2002-12-16 0:40 UTC (permalink / raw)
To: Antonino Daplas; +Cc: Michael Kaufmann, Linux Fbdev development list
In-Reply-To: <1039985803.1080.119.camel@localhost.localdomain>
On Son, 2002-12-15 at 21:57, Antonino Daplas wrote:
>
> User apps will always assume that the first pixel written to the
> framebuffer will appear as the first pixel of the first scanline of your
> display. Meaning, for apps that will always use mmap, you have to
> rewrite them so they raster "right->left" instead of "left->right".
>
> If you think about it, a hardware solution seems to be more feasible.
This may be true in general, but at least for X it wouldn't be hard to
add an option for mirroring via a shadow framebuffer.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* 2.5.50 working great so far
From: Matt Young @ 2002-12-16 0:43 UTC (permalink / raw)
To: linux-kernel
I did side step the SUSE net config system on my system.
Running devfs
Mouse in not detected on hardware scan. but a separate Suse utilily will find
it.
^ permalink raw reply
* Re: [PATCH] kexec for 2.5.51....
From: Eric W. Biederman @ 2002-12-16 0:41 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel, Greg KH
In-Reply-To: <200212151641.49062.tomlins@cam.org>
Ed Tomlinson <tomlins@cam.org> writes:
> On December 15, 2002 04:03 pm, Eric W. Biederman wrote:
> > Ed Tomlinson <tomlins@cam.org> writes:
> > > Why not include this info in kexec -h ? Bet it would prevent a few
> > > failure reports...
> >
> > I will look, at that.
> >
> > > Two more possible additions to the kexec command.
> > >
> > > 1. kexec -q which returns rc=1 and types the pending selection and
> > > its command/append string if one exists and returns rc=0 if nothing
> > > is pending.
> >
> > This would require effort to little purpose. If you just call kexec
> > it loads the kernel and then calls shutdown -r now. So the loaded kernel
> > should be a transient entity anyway.
>
> Consider, you are not sure what kexec has been setup to do (maybe
> some other admin has something setup to take a crash dump etc). You
> do not want to destroy this setup, so you do kexec -q
>
> Think being able to query the pending kexec is very usefull. Also
> using an rc means that scripts can use it too.
I think setting up something like /etc/lilo.conf say /etc/kexec.conf
is probably practical. You have already seen how difficult it is to
bring up the hardware into a sane state from an arbitrary point. So
we can cross the crash dump bridge when we come to it.
If this was simply a case of supporting linux the problem would be
some easier. But I also intend to support booting other operating
systems.
Now I think there is some advantage in setting up a new set of page
tables and just switching to those at kexec time, it slightly reduces
the amount of work I need to do at kexec time, enhancing the
reliability of something like kexec on panic. And that could
probably be exported in /proc/<pid>/mem. So if and when I go this
route I will keep your request in mind.
> > > 2. kexec -c which clears any pending kernels.
> >
> > This I can and should do. The kernel side is already implemented.
Oh, and of course I accept patches so you don't have to wait for me to
implement something.
Eric
^ permalink raw reply
* installing Predict on a RedHat 7.3 box , no go :^(
From: Douglas Cole @ 2002-12-16 0:28 UTC (permalink / raw)
To: linux-hams
Ok , I must admit to not being very good at installing something if its not
in a RPM form , so when I tried to install Predict on a SuSE 8.0 box and it
went flawlessly I got rather overconfident and tried to install it on my
RedHat IRLP node box , so I could let it run as a server 24/7 since that
machine is always on , and has alot of process time doing nothing...
BUT , it will not even begin to install :^(
here is what I get when I try to run ./configure on the RedHat box...
[root@n7bfs predict-2.2.1]# ./configure
One moment please... installer.c:16:20: curses.h: No such file or directory
Compilation failed. Are you sure you have a C compiler (gcc) installed?
[root@n7bfs predict-2.2.1]#
Now , what I get from that is that my node box does not have curses installed.
Hmm , so I check and sure enough it has "ncurses" installed , but not curses,
so I check all 3 install cd's and none have a curses package on them , so I
check the SuSE install dvd and sure enough -it- has it!
So my general question is , has anyone who is using the latest version of
predict running it on a RedHat box and if so what did you have to do to make
it happen ?
I have done a search on rpmfind.net and have not found any curses packages for
Redhat , which seems kinda confusing , but not surprising .
Or could someone point me in the direction of a how-to/info page that would
help me figure out how to install curses from sources so I don't need a
stinking RPM file to install curses on my node box ;^}
Or maybe I just didn't install RedHat properly...
tia for any input!
--
Douglas Cole N7BFS
Spokane IRLP node owner
AMSAT#26182 , K2 # 544
http://www.users.qwest.net/~cdoug3
Registered Linux user # 188922
^ permalink raw reply
* 2 (minor) Alpha probs in 2.5.51
From: Dr. David Alan Gilbert @ 2002-12-16 0:33 UTC (permalink / raw)
To: linux-kernel; +Cc: rth
(This is with rth's exception patch to fix the mount problem).
1) If compiled for the LX164 platform it is missing a number of symbols
at link time (fine if built generic):
arch/alpha/kernel/built-in.o(.data+0x3030): undefined reference to
`cia_bwx_inb'
arch/alpha/kernel/built-in.o(.data+0x3038): undefined reference to
`cia_bwx_inw'
.
.
.
(and a handful more)
2) This is a kind of subtle one. Straight after boot up if I run 'w'
or 'top' I get the warning:
Unknown HZ value! (831) Assume 1024.
This value creeps up:
Unknown HZ value! (958) Assume 1024.
over a period of a few minutes till the warning goes away.
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.