RE: ATA MODE_SENSE_BIG timeout
For those want to fix ATA code, I have another problem
with CURRENT. I have a Tyan Tiger 230T which is based
on VIA Apollo 133T, south bridge is VIA 686B.
On second IDE, I have a Mitsubishi 52X cdrom as master,
and a Sony 16X CD R/W as slave, when startup, kernel
is always stuck at MODE_SENSE_BIG timeout.
I fortunately catched the dmesg text since ATA code past the
probing stage. In most case, it will be stuck there forever.
BTW, both Linux (2.2.14, Redhat) and MS Windows can probe
these devices in few seconds without any problem.
I had more than a few machines behaved this way. I believe
the problem is with the probe and attach sequence of our
ata driver. After an ATA reset, according to spec, an ATAPI
device is supposed to present the ATAPI signature and deassert
the ready bit, until it receives its first packet command.
However when the ata driver issues the first mode sense command,
it polls first for the ready bit which never becomes set and
the operation times out. The most obviously solution is
sending the first command without checking for the ready bit.
My solution is a little different, but works equally well,
instead I issue an ATAPI reset (what now called a device reset?),
because I don't want to write another or alter the current
ata_command function and we need an atapi_reset function anyway.
According spec, atapi devices SHOULD ONLY be reset via the
atapi reset command (our ata driver doesn't follow this rule).
The patch is for -stable. I hope it's not too difficult to port
to -current.
-lq
Index: atapi-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-all.c,v
retrieving revision 1.46.2.18
diff -u -r1.46.2.18 atapi-all.c
--- atapi-all.c 31 Oct 2002 23:10:33 - 1.46.2.18
+++ atapi-all.c 19 Dec 2002 19:59:20 -
@@ -48,6 +48,7 @@
#include dev/ata/atapi-all.h
/* prototypes */
+static void atapi_reset(struct ata_device *);
static void atapi_read(struct atapi_request *, int);
static void atapi_write(struct atapi_request *, int);
static void atapi_finish(struct atapi_request *);
@@ -77,6 +78,7 @@
ata_umode(atadev-param), atadev-param-support_dma);
ATA_SLEEPLOCK_CH(atadev-channel, ATA_CONTROL);
+atapi_reset(atadev);
if (atapi_dma !(atadev-param-drq_type == ATAPI_DRQT_INTR)) {
ata_dmainit(atadev-channel, atadev-unit,
(ata_pmode(atadev-param) 0) ?
@@ -483,6 +485,8 @@
void
atapi_reinit(struct ata_device *atadev)
{
+atapi_reset(atadev);
+
/* reinit device parameters */
if (atadev-mode = ATA_DMA)
ata_dmainit(atadev-channel, atadev-unit,
@@ -536,6 +540,43 @@
}
static void
+atapi_reset(struct ata_device *atadev)
+{
+struct ata_channel *ch = atadev-channel;
+u_int8_t stat, lsb, msb;
+int timeout;
+
+ATA_OUTB(ch-r_io, ATA_DRIVE, ATA_D_IBM | atadev-unit);
+DELAY(10);
+ATA_OUTB(ch-r_altio, ATA_ALTSTAT, ATA_A_4BIT | ATA_A_IDS);
+DELAY(10);
+ATA_OUTB(ch-r_io, ATA_DRIVE, ATA_D_IBM | atadev-unit);
+DELAY(10);
+ATA_OUTB(ch-r_io, ATA_CMD, ATA_C_ATAPI_RESET);
+
+for (timeout = 1; timeout; timeout--) {
+ DELAY(100);
+ ATA_OUTB(ch-r_io, ATA_DRIVE, ATA_D_IBM | atadev-unit);
+ DELAY(10);
+ lsb = ATA_INB(ch-r_io, ATA_CYL_LSB);
+ msb = ATA_INB(ch-r_io, ATA_CYL_MSB);
+ stat = ATA_INB(ch-r_io, ATA_STATUS);
+ if ((stat ATA_S_BUSY) == 0)
+ break;
+}
+
+if (bootverbose)
+ ata_prtdev(atadev, stat %x, lsb %x, msb %x\n, stat, lsb, msb);
+
+if (timeout == 0)
+ ata_prtdev(atadev, soft reset failed\n);
+
+ATA_OUTB(ch-r_io, ATA_DRIVE, ATA_D_IBM | atadev-unit);
+DELAY(10);
+ATA_OUTB(ch-r_altio, ATA_ALTSTAT, ATA_A_4BIT);
+}
+
+static void
atapi_read(struct atapi_request *request, int length)
{
int8_t **buffer = (int8_t **)request-data;
@@ -617,10 +658,13 @@
{
struct ata_device *atadev = request-device;
+ATA_FORCELOCK_CH(atadev-channel, ATA_CONTROL);
atadev-channel-running = NULL;
ata_prtdev(atadev, %s command timeout - resetting\n,
atapi_cmd2str(request-ccb[0]));
+atapi_reset(atadev);
+
if (request-flags ATPR_F_DMA_USED) {
ata_dmadone(atadev-channel);
if (request-retries == ATAPI_MAX_RETRIES) {
@@ -631,17 +675,20 @@
request-retries = 0;
}
}
+ATA_UNLOCK_CH(atadev-channel);
/* if retries still permit, reinject this request */
if (request-retries++ ATAPI_MAX_RETRIES) {
+ int s = splbio();
TAILQ_INSERT_HEAD(atadev-channel-atapi_queue, request, chain);
+ ata_start(atadev-channel);
+ splx(s);
}
else {
/* retries all used up, return error */
request-error = EIO;
wakeup((caddr_t)request);
}
-ata_reinit(atadev-channel);
}
static char *
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body
RE: SIS 962 chipset, problems ...
Good year everybody Luigi, I converted your patch to CURRENT, there were only minor changes to do and it seems to work ! sis0: SiS 900 10/100BaseTX port 0x2000-0x20ff mem 0xec005000-0xec005fff irq 1$ at device 4.0 on pci0 sis0: Ethernet address: 00:00:e2:94:66:99 miibus0: MII bus on sis0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto http://people.freebsd.org/~mbr/patches/ifsis-luigi.diff and added the Linux way of reading the eeprom. I guess we should make this the default for accessing the eeprom (for this chipset), since it is not only the mac address which gets read. Luigi: Or isn't this neccessary ? http://people.freebsd.org/~mbr/patches/ifsis-mbr.diff Martin Yes, I think it is neccesary, but all my machines have 0x90 revisions. I've discovered another issue with the integrated device, the dma burst size should be limited to 64 bytes. This is in the Linux driver, search for EDB_MASTER_EN, if this bit is set in config register, dma burst size can be no larger than 64, otherwise data errors would sometimes appear at 64 byte data boundaries. There's also a bug exists in almost all Bill's network drivers: when reading PHY regs over the i2c bus, the turnaround ACK bit is read one clock edge too late. This bit is driven low by slave (as any other input data bits from slave) when the clock is LOW. The current code reads the bit after the clock is driven high again. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: SIS 962 chipset, problems ...
Hi, Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff Dec 23 15:17:03 kernel: sis0: MII without any PHY! Dec 23 15:17:03 kernel: device_probe_and_attach: sis0 attach returned 6 Dec 23 15:17:03 kernel: sis0: SiS 900 10/100BaseTX port 0x2000-0x20ff mem 0xec005000-0xec005fff irq 11 at device 4.0 on pci0 Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff Dec 23 15:17:03 kernel: sis0: MII without any PHY! The linux driver tells me : /** * sis96x_get_mac_addr: - Get MAC address for SiS962 or SiS963 model * @pci_dev: the sis900 pci device * @net_dev: the net device to get address for * * SiS962 or SiS963 model, use EEPROM to store MAC address. And EEPROM * is shared by * LAN and 1394. When access EEPROM, send EEREQ signal to hardware first * and wait for EEGNT. If EEGNT is ON, EEPROM is permitted to be access * by LAN, otherwise is not. After MAC address is read from EEPROM, send * EEDONE signal to refuse EEPROM access by LAN. * The EEPROM map of SiS962 or SiS963 is different to SiS900. * The signature field in SiS962 or SiS963 spec is meaningless. * MAC address is read into @net_dev-dev_addr. */ So we definitly are missing the support for the SiS 962/963 southbridge. Martin This is just one part of the problem. The other half is PHY couldn't be detected. It seems that sis no longer implementes the enhanced phy control register, and phy has to be directly accessed via mdio. I have a patch (-stable only) for this problem, http://www.freebsd.org/~luoqi/sis.diff . I've also notice some other quirks of the chip our driver should be dealing with. Among them, the multicast address filter and DMA burst size. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic at shutdown
#7 0xc017a726 in vput (vp=0xc8710840) at vnode_if.h:794 #8 0xc01aee87 in ffs_sync (mp=0xc0ade800, waitfor=2, cred=0xc0721700, p=0xc026d5e0) at ../../ufs/ffs/ffs_vfsops.c:955 Change the vput(vp) call at line 955 of ffs_vfsops.c back to two separate calls (see previous revision): VOP_UNLOCK(vp, 0, p); vrele(vp); vput assumes curproc is the lock holder, but it's not true in this case. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
page fault at write-only mmapped address
Because there is no write-only hardware page protection on ia32, a write-only page fault is handled just like a read/write one. But the mi vm layer distinguishes between the write-only and the read/write protections, so if the fault takes place in a write-only region, the vm layer would think that the write-only operation is trying to read from a write-only address and violates the page protection. As a consequence, if you want to use the sound device in mmapped mode, you'll have to map the playback buffer read/write instead of write-only. I'd like to reverse the way read/write and write-only page faults are handled, i.e., handle both of them like a write-only fault. Does anyone know any reason why I shouldn't do that? I'm currently running a kernel with this modification and I have seen no ill-effect so far. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: bioops patch.
Background: Ideally struct buf should have had a real OO like operations vector like vnodes have it, and struct bioops is the first step towards that. struct buf will eventually become merely an iocmd structure, so why do we want to complicate things here? No, struct buf will remain the cache-handle. the iocmd is called struct bio. Even if struct buf stays around, its cache-handle role will be diminished, probably just a translation layer to vm object based caching. We already have an OO method for bwrite: VOP_BWRITE(), the problem is most of the code are still calling bwrite() directly. Will it solve your problem if we change every bwrite() into a VOP_BWRITE()? Well, I'm not sure it is correct to go the detour around Vnodes, if we do, we need to add VOP_BAWRITE, VOP_BDWRITE and all those other operations as well. Don't you need bp-b_ops-bawrite(), bp-b_ops-bdwrite() as well? I feel it's better to go through the vnode, because for all the bufs belong to the same vnode, these b_ops are most likely to be the same. And for a stackable filesystem, you may easily implement a passthru call with vnode, how would you deal with it using struct buf? But what vnode would you use for a buffer associated with a freeblock bitmap ? Each buffer belongs to a vnode, a buffer associated with a freeblock bitmap belongs to the device vnode, and that's the vnode we could use. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
In [EMAIL PROTECTED], Luoqi Chen wrote: It is not the loader's job to detect the underlying hardware configuration. I disagree. I would like to tell which machine I am booting on to choose an appropriate kernel. Eventually (it may take a while) we should be able to boot any i386/AT based machine with a single kernel which dynamically loads drivers for available hardware (and different locking modules for UP and SMP for that matter). My -current harddisk (physically) moves between 3 machines with very different requirements, not just SMP. FPU, few or much RAM, ISA stuff on identical places etc. I can select the kernel manually, but after a crash or power fail I might not be in a position to do it again. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: bioops patch.
Background: The bioops operation vector is a list of OO-like operations which can be performed on struct buf. They are used by the softupdates code to handle dependencies. Ideally struct buf should have had a real OO like operations vector like vnodes have it, and struct bioops is the first step towards that. struct buf will eventually become merely an iocmd structure, so why do we want to complicate things here? One of the reasons we should have OO-like struct buf, is that as long as bwrite(bp) "knows" that the buffer is backed by a disk device, we cannot use the UFS layer on top of a storage manager which isn't based on disk-devices: When UFS modifies a directory inode, it will call bwrite(bp) on the buffer with the data. This would not work if the backing were based on malloc(9) or anonymous swap-backed VM objects for instance. We already have an OO method for bwrite: VOP_BWRITE(), the problem is most of the code are still calling bwrite() directly. Will it solve your problem if we change every bwrite() into a VOP_BWRITE()? -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird 4.0-STABLE problem, might be related to 5.0 as well
This is the third time this happened to a 4.0-STABLE host of ours. The problem starts with havnig a number of processes which are unable to be killed. So we want to reboot the box. All goes well, bufdaemon and syncer stop normally. Then it gets to syncing disks done. And there it hangs. At this point only the NIC is reachable on its IP address for ping. At this point the kernel is trying to unmount all filesystems, it hangs probably because it's waiting for locks those unkillable processes hold. So I break into DDB and get this from a trace: The trace didn't reveal anything wrong: xl is updating its status during a scheduled timeout. The best way to diagnose the problem is to work on the live system when the same symptom occurs (unkillable process), find out which channels these processes are sleeping on and why they're not waken up (hardware failure might contribute to it). A `ps axl' report would be very helpful. For those unkillable processes, you might want to report the backtrace for each, here's how to get them, # gdb -k /kernel /dev/mem (kgdb) proc pid (kgdb) bt -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Given the way VMware works, I'd have nothing against making it a FICL words, except... ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. I'm quite reluctant to add the ficl word myself. Ideally, we should not need to know which platform we're running on, be it a dell, a gateway or a software emulation like vmware. The problem is our inability to have a single kernel to boot an UP and a SMP machine, once we've solved this problem, I would remove this ficl word. I see this as a temporary solution to a specific problem, I don't want to generalize this into a larger issue. It is not the loader's job to detect the underlying hardware configuration. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
We have inb and outb. Can't vmware be written in Forth? If inl cannot be replaced with inb, I'd rather add inl than vmware. But we can't set registers to specific values before inb/outb, which also means our inb/outb are quite useless in making BIOS calls. IMHO, it would be better to add exec="include /boot/vmware.4th" to the end of your /boot/loader.conf, and either execute vmware-conf from there or script the whole thing: s" arch-i386" environment? [if] \ Get vmware version, magic 0x564d868 ( VMware magic ) = [if] .( VMware version ) . cr .( Loading /boot/vmware.conf...) cr s" /boot/vmware.conf" read-conf [else] drop [then] [then] Either way, no changes to /boot/loader.rc would be required. This looks much better, I didn't know we could tell the loader to execute a script in loader.conf. -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hmmm - I have to go check this. My reality assumptions are shattered. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
As for setting registers ti specific values... huh? Why does this matter? Can you explain exactly what your code does and how? VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VMware detection code in boot loader
Would anyone object if I add a ficl word to detect whether we're booting
from a vmware virtual machine? I find it extremely useful when I'm running
FreeBSD as a guest under NT. Because it is a dual cpu box, I can't use a
single kernel to boot both directly or inside the virtual machine. With this
new word, I can determine which kernel to use in the loader script, saving
me the trouble to unload and reload a new kernel each time I reboot.
Here's the patch to the boot loader,
Index: boot/ficl/ficl.h
===
RCS file: /home/ncvs/src/sys/boot/ficl/ficl.h,v
retrieving revision 1.14
diff -u -r1.14 ficl.h
--- boot/ficl/ficl.h2000/06/01 18:10:43 1.14
+++ boot/ficl/ficl.h2000/06/07 18:18:38
@@ -860,6 +860,7 @@
#if defined(__i386__) !defined(TESTMAIN)
extern void ficlOutb(FICL_VM *pVM);
extern void ficlInb(FICL_VM *pVM);
+extern void vmware(FICL_VM *pVM);
#endif
#ifdef __cplusplus
Index: boot/ficl/words.c
===
RCS file: /home/ncvs/src/sys/boot/ficl/words.c,v
retrieving revision 1.27
diff -u -r1.27 words.c
--- boot/ficl/words.c 2000/06/01 18:10:43 1.27
+++ boot/ficl/words.c 2000/06/07 18:19:13
@@ -4800,6 +4800,7 @@
#ifdef __i386__
dictAppendWord(dp, "outb", ficlOutb, FW_DEFAULT);
dictAppendWord(dp, "inb", ficlInb,FW_DEFAULT);
+dictAppendWord(dp, "vmware",vmware, FW_DEFAULT);
#endif
#endif
Index: boot/ficl/i386/sysdep.c
===
RCS file: /home/ncvs/src/sys/boot/ficl/i386/sysdep.c,v
retrieving revision 1.7
diff -u -r1.7 sysdep.c
--- boot/ficl/i386/sysdep.c 1999/09/29 04:43:07 1.7
+++ boot/ficl/i386/sysdep.c 2000/06/07 18:18:13
@@ -111,6 +111,26 @@
c=inb(port);
stackPushINT(pVM-pStack,c);
}
+
+/*
+ * vmware ( -- version )
+ * Get vmware version.
+ */
+void
+vmware(FICL_VM *pVM)
+{
+int version, magic = 0;
+
+#defineVMWARE_MAGIC0x564d5868
+#defineVMWARE_PORT 0x5658
+
+ __asm __volatile("inl %%dx, %%eax"
+ : "=a" (version), "=b" (magic)
+ : "0" (VMWARE_MAGIC), "d" (VMWARE_PORT), "c" (0xa));
+ if (magic != VMWARE_MAGIC)
+ version = -1;
+ stackPushINT(pVM-pStack, version);
+}
#endif
#endif
To use this feature, you first create a file /boot/vmware.4th:
: vmware-conf
vmware dup 0 if
." VMware version " . cr
." Loading /boot/vmware.conf..." cr
s" /boot/vmware.conf" read-conf
else
drop
then
;
then create /boot/vmware.conf which sets the kernel to use:
kernel="/kernel.VMWARE"
finally, change your /boot/loader.rc to
include /boot/loader.4th
include /boot/vmware.4th
initialize drop
vmware-conf
boot-conf
check-password
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: tunefs -p doesn't work for read-write mounts
Hi folks,
Shouldn't I be able to show the current tuneables for a given filesystem?
# tunefs -p /usr
tunefs: cannot work on read-write mounted file system
This is on a recent CURRENT.
Ciao,
Sheldon.
You were supposed to use a raw device for a mounted fs, but that no longer
works after the elimination of block device. I have a quick fix for this
problem: open the device read-only to read the superblock and later re-open
it read-write before writing back.
-lq
Index: tunefs.c
===
RCS file: /home/ncvs/src/sbin/tunefs/tunefs.c,v
retrieving revision 1.11
diff -u -r1.11 tunefs.c
--- tunefs.c2000/01/30 05:24:55 1.11
+++ tunefs.c2000/03/03 16:04:04
@@ -75,9 +75,10 @@
int fi;
long dev_bsize = 1;
-void bwrite(daddr_t, char *, int);
-int bread(daddr_t, char *, int);
-void getsb(struct fs *, char *);
+void bwrite __P((daddr_t, char *, int));
+int bread __P((daddr_t, char *, int));
+void getsb __P((struct fs *, char *));
+void putsb __P((struct fs *, char *, int));
void usage __P((void));
void printfs __P((void));
@@ -103,9 +104,6 @@
if (fs) {
if (statfs(special, stfs) == 0
strcmp(special, stfs.f_mntonname) == 0) {
- if ((stfs.f_flags MNT_RDONLY) == 0) {
- errx(1, "cannot work on read-write mounted file
system");
- }
active = 1;
}
special = fs-fs_spec;
@@ -251,12 +249,7 @@
}
if (argc != 1)
usage();
- bwrite((daddr_t)SBOFF / dev_bsize, (char *)sblock, SBSIZE);
- if (Aflag)
- for (i = 0; i sblock.fs_ncg; i++)
- bwrite(fsbtodb(sblock, cgsblock(sblock, i)),
- (char *)sblock, SBSIZE);
- close(fi);
+ putsb(sblock, special, Aflag);
if (active) {
bzero(args, sizeof(args));
if (mount("ufs", fs-fs_file,
@@ -283,7 +276,7 @@
char *file;
{
- fi = open(file, 2);
+ fi = open(file, 0);
if (fi 0)
err(3, "cannot open %s", file);
if (bread((daddr_t)SBOFF, (char *)fs, SBSIZE))
@@ -291,6 +284,30 @@
if (fs-fs_magic != FS_MAGIC)
err(5, "%s: bad magic number", file);
dev_bsize = fs-fs_fsize / fsbtodb(fs, 1);
+}
+
+void
+putsb(fs, file, all)
+ register struct fs *fs;
+ char *file;
+ int all;
+{
+ int i;
+
+ /*
+* Re-open the device read-write. Use the read-only file
+* descriptor as an interlock to prevent the device from
+* being mounted while we are switching mode.
+*/
+ i = fi; fi = open(file, 2); close(i);
+ if (fi 0)
+ err(3, "cannot open %s", file);
+ bwrite((daddr_t)SBOFF / dev_bsize, (char *)fs, SBSIZE);
+ if (all)
+ for (i = 0; i fs-fs_ncg; i++)
+ bwrite(fsbtodb(fs, cgsblock(fs, i)),
+ (char *)fs, SBSIZE);
+ close(fi);
}
void
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: repost of procfs crashes in -CURRENT (no html)..
Kernel:
===
FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Feb
14 23:00:42 GMT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/KARMA i386
Background:
3 users. One with X running me, and two users running breakwidgets
binary testing script, which make use of a minimized version of the
"killall" perl script which reads procfs.
This crash appears to be the old one where when two processes read procfs
simultaneously, ugly things can happen. mdillon described this in more
depth to me once but I've since lost the e-mail. I posted similar crash
reports in late November early december. He suggested having my
programs "lock" procfs reads so only one could do it's killall function at
a time. Unfortunatly, the binary testing script is very time sensitive and
this would slow things down my current run-through is about 48 hours
paralleled on 4 machines
I don't believe that's the cause.
The kernel is a GENERIC one with ipv6, softupdates, and pcm added to it.
Crash #1:
=
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc014e194 in poweroff_wait (junk=0xc02b9480, howto=-871862272) at
../../kern/kern_shutdown.c:554
#2 0xc022d064 in vm_fault (map=0xc031ee28, vaddr=3423105024, fault_type=1
'\001', fault_flags=0) at ../../vm/vm_fault.c:240
#3 0xc02810d2 in trap_pfault (frame=0xcc136cc4, usermode=0,
eva=3423108180) at ../../i386/i386/trap.c:788
#4 0xc0280d37 in trap (frame={tf_fs = -871170032, tf_es = -871170032,
tf_ds = 16, tf_edi = -871142055, tf_esi = -871142025,
tf_ebp = -871141804, tf_isp = -871142160, tf_ebx = -872323392,
tf_edx = 0, tf_ecx = -872323392, tf_eax = -871859336,
tf_trapno = 12, tf_err = 0, tf_eip = -1072160861, tf_cs = 8,
tf_eflags = 66118, tf_esp = 0, tf_ss = 0})
at ../../i386/i386/trap.c:423
#5 0xc0181fa3 in procfs_dostatus (curp=0xcc145e00, p=0xcc0166c0,
pfs=0xc14abf60, uio=0xcc136eec)
at ../../miscfs/procfs/procfs_status.c:115
The fault is taken when trying to access the target process' p_stats which
resides in the u area. What's interesting here is the code checks P_INMEM
flag prior to accessing p_stats, so there shouldn't be a fault. My guess is
this is an embryonic process, the p_stats field is inherited from the corpse
of another process which points to no where. Would you print out p-p_stat
(not p_stats) and check if it is 1 (SIDL)? That would confirm my theory.
If this indeed is the case, the fix should be delaying setting P_INMEM flags
in fork() until after the u area is allocated. It maybe also a good idea to
skip embryonic processes in procfs altogether.
#6 0xc0182590 in procfs_rw (ap=0xcc136ea0) at
../../miscfs/procfs/procfs_subr.c:277
#7 0xc017dc0a in vn_read (fp=0xc14431c0, uio=0xcc136eec, cred=0xc1450700,
flags=0, p=0xcc145e00) at vnode_if.h:334
#8 0xc015ac50 in dofileread (p=0xcc145e00, fp=0xc14431c0, fd=6,
buf=0x8235000, nbyte=4096, offset=-1, flags=0)
at ../../sys/file.h:140
#9 0xc015ab57 in read (p=0xcc145e00, uap=0xcc136f80) at
../../kern/sys_generic.c:111
#10 0xc028167e in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077946820, tf_esi = 672915688,
tf_ebp = -1077946996, tf_isp = -871141420, tf_ebx = 672858084,
tf_edx = 672809512, tf_ecx = 136531968, tf_eax = 3,
tf_trapno = 0, tf_err = 2, tf_eip = 672818732, tf_cs = 31, tf_eflags
= 659, tf_esp = -1077947040, tf_ss = 47})
at ../../i386/i386/trap.c:1055
Crash #2:
=
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc014e194 in poweroff_wait (junk=0xc02b9480, howto=-873472000) at
../../kern/kern_shutdown.c:554
#2 0xc022d064 in vm_fault (map=0xc031ee28, vaddr=3421495296, fault_type=1
'\001', fault_flags=0) at ../../vm/vm_fault.c:240
#3 0xc02810d2 in trap_pfault (frame=0xcbe0ccc4, usermode=0,
eva=3421498452) at ../../i386/i386/trap.c:788
#4 0xc0280d37 in trap (frame={tf_fs = -874512368, tf_es = -874512368,
tf_ds = 16, tf_edi = -874459817, tf_esi = -874459788,
tf_ebp = -874459564, tf_isp = -874459920, tf_ebx = -873997056,
tf_edx = 0, tf_ecx = -873997056, tf_eax = -873469064,
tf_trapno = 12, tf_err = 0, tf_eip = -1072160861, tf_cs = 8,
tf_eflags = 66118, tf_esp = 0, tf_ss = 0})
at ../../i386/i386/trap.c:423
#5 0xc0181fa3 in procfs_dostatus (curp=0xcbd7df20, p=0xcbe7dd00,
pfs=0xc154ac20, uio=0xcbe0ceec)
at ../../miscfs/procfs/procfs_status.c:115
#6 0xc0182590 in procfs_rw (ap=0xcbe0cea0) at
../../miscfs/procfs/procfs_subr.c:277
#7 0xc017dc0a in vn_read (fp=0xc1469200, uio=0xcbe0ceec, cred=0xc153d180,
flags=0, p=0xcbd7df20) at vnode_if.h:334
#8 0xc015ac50 in dofileread (p=0xcbd7df20, fp=0xc1469200, fd=5,
buf=0x8253000, nbyte=4096, offset=-1, flags=0)
at ../../sys/file.h:140
#9 0xc015ab57 in read (p=0xcbd7df20, uap=0xcbe0cf80) at
../../kern/sys_generic.c:111
#10 0xc028167e in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077945828, tf_esi =
Re: Dell 2400 and APIC problem
I have tried doing this on -current but it doesnt make any difference. I have also removed every non-essential item out of the kernel. I am using boot -dv with "options DIAGNOSTIC" in the kernel and it doesnt tell me what the PnP probe is hanging on. Any other suggestions? I don't think it's pnp probing. You don't seem to have any pnp devices at all from your dmesg output. Could you do a 'pnpinfo' and verify if it is indeed the case? Isa bus is the last bus probed, and immediately (well, almost) follows that configure hooks with interrupt enabled. That is also the first time BSP gives up mplock, and the APs have a chance to initialize themselves. I believe that is where it hangs. Just to make sure, do you have "options NAPIC 2" in your kernel config? The default is 1, so you absolutely need this line for things to work. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: indirection in bus space
Do you have any comment anout the patch? If there isn't any big problem, I hope to commit it to current. Thank you. I wrote: Do you remember this topic? I have revised the indirection support patch. What I have changed are: - to make diff files more readable - introduce the bus_simple_create_bsh() that creates a bus_space_handle_tag from a base address. We shouldn't need bus_simple_create_bsh(). All drivers ought to use rman_get_bushandle()/rman_get_bustag() to retrieve the bus handle and tag, and use them in bus_space_read/write calls to perform device io. Drivers that don't do that should be fixed. Why have two files bus_at386.h and bus_pc98.h? I386_BUS_PIO_IND should be able to live with I386_BUS_PIO and I386_BUS_MEMIO happily together. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: indirection in bus space
Why have two files bus_at386.h and bus_pc98.h? I386_BUS_PIO_IND should be
able to live with I386_BUS_PIO and I386_BUS_MEMIO happily together.
Because they are different in the type of bus_space_tag_t from each
other. It is the u_long in PC/AT and the structure in PC-98. For
example, bus_space_read_1()s of them are:
PC/AT:
bus_space_read_1(...)
{
...
return (inb(handle + offset));
...
}
PC-98:
bus_space_read_1(...)
{
...
return (inb(bsh.bsh_iat[offset]));
...
}
You could set the handle to point to the structure instead:
bus_space_read_1(...)
{
if (tag == I386_BUS_PIO) {
return (inb(handle + offset));
} else if (tag == I386_BUS_PIO_IND) {
struct bus_space_handle_pc98 *bsh = handle;
return (inb(bsh-bsh_iat[offset]));
} else if (tag == I386_BUS_MEMIO) {
...
}
}
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: indirection in bus space
I think it is difficult to implement such conversion because: - Not only bus space stuff also resource manager stuff need to perform such conversion. Why? Both bus_space_handle_t and bus_space_tag_t are supposed to be opaque types. Resource manager needs not know the implementation details. - The type of the bus_space_handle_t can by determined only by the bus tag. The isa_alloc_resourcev (new function) cannot modify bus tag because what it does is only to allocate resources and it cannot register the address to the bus_space_handle_pc98. But allocated resources must be stored into bus_space_handle_pc98. We could create a new resource type SYS_RES_IOPORT_ARRAY, and intercept it in all isa_*_resoruce() methods. In isa_alloc_resource(), we malloc and return a fake resource record, in which we store I386_BUS_PIO_IND as bus tag and address of bus_space_handle_pc98 as bus handle. And in isa_release_resource(), we first release the underlying resources stored in the bus_space_handle_pc98 record and then free the fake resource record itself. It should be safe as long as we don't manipulate this resource by direct resource manager calls, which we shouldn't do anyway. (or we should implement it at the root bus level, if pci devices in pc98 systems also use discrete port addresses). -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __sigisempty() undefined if cc -g used.
In an effort to chase down a libc_r bug, I compiled libc_r with CFLAGS=-g
(and later CFLAGS=-g3), but ran into linker problems as a result.
blitz:~ gcc poll.c -pthread
/usr/lib/libc_r.so: undefined reference to `__sigisempty'
Even the simplest of C programs will get this linker error if using the
-pthread option.
So, __sigisempty is an inline function, defined in
/usr/include/sys/signalvar.h:
extern __inline int
__sigisempty(sigset_t *set)
{
int i;
for (i = 0; i _SIG_WORDS; i++) {
if (set-__bits[i])
return (0);
}
return (1);
}
It doesn't make much sense to have an "extern" inline function, gcc probably
was confused by this, change "extern" to "static" and try again.
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mount(2) broken?
I'd like to add something about the last buffer wouldn't sync. This occurs when a shutdown syscall is issued when the syncer process is asleep waiting for a buffer write to complete. The write will never complete, because the syncer won't be given a chance to run again, and the buffer will stay marked as busy and become the buffer that wouldn't sync. I haven't thought about a clean way of handling this situation, maybe some of you out there have better ideas... I always thought it would make sense to have the syncer perform the shutdown and cleanup since it had code to write buffers with anyway... This sounds like a good idea, and should be easy to implement. I'll work on it tonight. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount(2) broken?
I've seen this exact same thing before too. In fact it was two rather annoying things, one being a single solitary last buffer that wouldn't sync and thus left the whole fs marked dirty, and then fsck would check it, see it was fine, but mount wouldn't recognize that it was clean. 'Course I saw this this morning too. Yes, with a new kernel, new devices, ata driver, and new world. 'Twas very odd. - alex I'd like to add something about the last buffer wouldn't sync. This occurs when a shutdown syscall is issued when the syncer process is asleep waiting for a buffer write to complete. The write will never complete, because the syncer won't be given a chance to run again, and the buffer will stay marked as busy and become the buffer that wouldn't sync. I haven't thought about a clean way of handling this situation, maybe some of you out there have better ideas... -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
init runs with console as control terminal?
Since sometime last month, rc5des failed to start from my rc.local. I did a little investigation and it turned out that rc5des was started but later terminated by a SIGHUP. During its brief lifetime, /dev/console was its control terminal. Does anyone know what was going on? -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wine under -current. patches.. comments?
The latest port of wine references PR 14652 for patches to make -current work. some of these ptches are however in areas I don't understand. In particular signals, register contexts, etc. This refers to validity of segment registers fs/gs in sigcontext. Under -stable both of them are unused and signal handlers have to read the registers directly. Under -current fs was valid and gs still unused until I changed it recently, now they are both valid. This was done a couple weeks before 3.3-RELEASE, so I didn't have time to change -stable as well. I planned to do it immediately afterwards, but Marcel's 128-signal change came in, and I decided to wait for -current to stablize first. I guess it's time for me to make the changes. A word of warning, after the changes wine should be source compatible between -stable and -current, binary compiled on -stable should still work on -current, but not vice versa. There's another patch regarding SIGTRAP in the PR. I recall there were some discussions about it, but I don't know what's the final resolution (if there was one). Maybe Marcel and Bruce know better. There is reference to a patch of luoqi's as well as other comments. This is the ldt sharing patch I had a while ago. It's still in my local tree, but I haven't updated the patch on my web page for a long time. I wanted to commit this patch, but I haven't found any one with enough time and interest to review it. Julian, would you? I can send you the latest diff. Some of the patches are simply to newer code back to 3.3 but there are obviously problems with -current as well. Is there anyone with their fingers in that stuff that has a patchset for -current? If I could get the ldt sharing stuff committed, the patchset would be a lot more manageable :-) Julian -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CMAP2 busy ?
Hi. I've been experiencing problems with my machine crashing when in X, when idle overnight. Normally it panics with XF86_S3. Today however the machine returned something a little different, which I haven't seen before. I hope this helps someone. The machine worlds with no problems, and is perfectly stable when in console mode. X has been rebuilt several times. GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... IdlePTD 3559424 initial pcb at 29d280 panicstr: pmap_zero_page: CMAP2 busy panic messages: --- panic: pmap_zero_page: CMAP2 busy It looked like an interrupt hit when the cpu was in an idle loop replenishing zero filled pages, and the interrupt handler somehow also tried to zero some pages itself. In vm_page_zero_idle(), pmap_zero_page should be called at splvm() to prevent this from happening, or allocate another pte exclusively for the idle loop. The latter seems to be preferable. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aic driver camified
Luoqi Chen wrote: I compiled a kernel for -stable, but was unable to boot from it. Does anyone know if there is any incompatibility between the -current boot loader and a -stable kernel? AFAIK, there is no difference between them (the loaders :). Try from boot2. It was not the loader, it was the config file. I used a -current config file without those spl levels, no wonder the machine hung at its earliest convenience... -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "People call him Neutron Star, 'cuz he's so dense lights bends around him." -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: luoqi's aic driver problem
cd0 at aic0 bus 0 target 0 lun 0
cd0: PINNACLE RCD-1000 2.35 Removable Worm SCSI-2 device
cd0: 3.300MB/s transfers
cd0: cd present [1 x 77747 byte records]
^
These numbers don't look right...
but, unfortunately, scsi probe precedure seems to be relatively
unstable. _sometimes_ (often enough) the kernel doesn't boot with the
following diagnostics:
I have fixed a few places that might have caused the timeout problem.
Could you download the new code and try again? Would you also add these
debug options to your config file?
options CAMDEBUG
options CAM_DEBUG_BUS=-1
options CAM_DEBUG_TARGET=-1
options CAM_DEBUG_LUN=-1
options CAM_DEBUG_FLAGS="CAM_DEBUG_INFO|CAM_DEBUG_TRACE|CAM_DEBUG_CDB"
what is possible reason of such behaviour and what should i try to do to
make my aic/cdrom combination working?
For now you could add a quirk entry for this drive to prevent multi-lun
probing,
ok, but how? :)
Add this entry to the xpt_quirk_table in cam/cam_xpt.c,
{
{ T_WORM, SIP_MEDIA_REMOVABLE, "PINNACLE", "RCD*", "*" },
CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0
},
sincerely,
ilya naumov (at work)
Thanks for trying the driver out, I really appreciate your patience. Since I
don't have the hardware myself, I have to rely on your help.
Thanks
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: aic driver camified
I also tried to experiment with the aic driver (and also failed, little similar to Ilya's problems) Could you download the new set of files and see if it helps? as devices. What puzzles me is why the probe at the aic0 wants to look at bus 0. Shouldn't that be bus 1? Or should I add a scbus1 line in my config file (I think of this while I type, I will try this when I have sent this message) I think this bus number is only used to differentiate the individual channels of multi-channel cards. What people usually refer to as bus id is actually the path id, unique for each hba + bus number combination. TIA Koen. -- Dr. K.R.A.M. Schreel | Eindhoven University of Technology | Faculty of Mechanical Engineering Combustion Research | Section Energy Technology | P. O. Box 513 [EMAIL PROTECTED] | 5600 MB Eindhoven, The Netherlands Thanks -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aic driver camified
Luoqi Chen wrote: I've ported it to -stable, but I don't have a machine to test it, please if you could. The code is in http://www.freebsd.org/~luoqi/aic/stable, apply patch files.diff, copy aic_isa.c to i386/isa, the rest goes to dev/aic. I cannot compile a kernel. It reports the following errors: Did the patch files.diff apply cleanly? It should add one line to each of the sys/conf/files and sys/i386/conf/files.i386, please make sure they are there. It looks as though aic.c is not compiled in. B.T.W., in fist line of aic.c a reference to aic.h is placed, but that file is not present in your directory. aic.h is generated by config, it should be present in the kernel compile directory. I compiled a kernel for -stable, but was unable to boot from it. Does anyone know if there is any incompatibility between the -current boot loader and a -stable kernel? TIA Koen. -- Dr. K.R.A.M. Schreel | Eindhoven University of Technology | Faculty of Mechanical Engineering Combustion Research | Section Energy Technology | P. O. Box 513 [EMAIL PROTECTED] | 5600 MB Eindhoven, The Netherlands Thanks -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: luoqi's aic driver problem
i've tried new "camfied" aic driver today and failed. here is a brief report. my configuration: Chaintech 6BTM mainboard with Celeron 416A processor and 128 Mb of memory Adaptec AIC-6360 SCSI controller (port 0x340 irq 9), irq 9 is reserved for Legacy/ISA card in bios setup Pinnacle 1000 CD writer (with SCSI device ID set to 0) kernel settings: options "CD9660" options "CD9660_ROOT" options SCSI_DELAY=15000 controller scbus0 controller aic0 at isa? port 0x340 irq 9 device cd0 at aic? should be just "device cd0" results: aic controller was successfully found by the kernel, but after "Waiting 15 seconds for SCSI devices to settle" message it said the following: (probe0:aic0:0:0:0): REQUEST SENSE. CDB: 3 0 0 0 20 0 (probe0:aic0:0:0:0): UNIT ATTENTION info?:1 asc:29,0 (probe0:aic0:0:0:0): Power on, reset, or bus device reset occured (probe0:aic0:0:0:1): REQUEST SENSE. CDB: 3 4 0 0 12 0 (probe0:aic0:0:0:1): ILLEGAL REQEST asc:25,0 (probe0:aic0:0:0:1): Logical unit not supported The request sense command clobbered the original command, I've changed the code from doing that, please download a new copy of aic.c file. (probe0:aic0:0:0:2): ccb 0xc09c3000 - timed out (probe0:aic0:0:0:2): ccb 0xc09c3000 - timed out Was there a long period between these two messages and the previous ones? Please try the new aic.c file, it will print out if a different command is holding up the scsi bus. after that my system just hangs. The timeout handling code is flaky, I need to understand how it should work a little better. what is possible reason of such behaviour and what should i try to do to make my aic/cdrom combination working? For now you could add a quirk entry for this drive to prevent multi-lun probing, until we figure out what went wrong. thank you in advance. sincerely, ilya naumov (at work) -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aic driver camified
On Mon, 18 Oct 1999, Chris Dillon wrote: Should this apply cleanly to -stable? If so, I'll give it a shot when I get home. I'll answer my own question (which, oddly enough, still hasn't made it to the list after about two hours). I forgot about newbus. It doesn't work, of course, and my Clue Quotient(TM) isn't high enough to backport this to -stable. I think I'll teach myself how to do this next weekend, if nobody else gets to it. :-) I've ported it to -stable, but I don't have a machine to test it, please if you could. The code is in http://www.freebsd.org/~luoqi/aic/stable, apply patch files.diff, copy aic_isa.c to i386/isa, the rest goes to dev/aic. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
aic driver camified
After the recent signal related changes, the pre-cam kernel I saved a long time ago no longer works with (even statically compiled) user applications, which meant I had no way to access my files on an old disk hanging off an aic6360 card. So I decided to bite the bullet and camify the aic driver myself (I've long given up hope someone else would do it.) The source is at http://www.freebsd.org/~luoqi/aic. Copy the source files into sys/dev/aic, apply the patch files.diff to sys/conf/files. Don't forget to add the controller aic0 line back to your config file. Since I don't have *any* documentation on the chip or card, except for the existing source code (FreeBSD/NetBSD/Linux), and my knowledge of our cam implementation is quite limited, so consider this code extremely experimental and use at your own risk. DMA is not supported, sync transfer is supported but not tested, neither pnp nor pccard is supported. My card doesn't support any of these, so there's not much I could do, I hope sopme of you could fill in the blanks. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup segfaults identified/solved [PATCH]
Hi, It seems that the trampoline code got too long and resulted in the coredumps people reported. The following patch solves that. it basicly works as follows: o Simplify the trampoline code so that it doesn't have to distinguish between an old- and new sigframe and also restoring %gs in both cases. o Which sigreturn to use is now determined by the process flag that is used to determine which sendsig is to be used (symmetry) o restoring %gs is now handled in the proper sigreturn. I'll commit this if noone objects. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] Restoration of %gs should not be in the kernel because it comes from user application and maybe invalid, if you restore it inside the kernel it could be fatal to the whole system, and on the other hand just a core dump if done in the trampoline code which is still in user mode. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup segfaults identified/solved [PATCH]
Luoqi Chen wrote: o restoring %gs is now handled in the proper sigreturn. Restoration of %gs should not be in the kernel because it comes from user application and maybe invalid, if you restore it inside the kernel it could be fatal to the whole system, and on the other hand just a core dump if done in the trampoline code which is still in user mode. Hmmm... What if the application passes a (possibly handcrafted) sigcontext to an explicit call to sigreturn. %gs should be restored in that case too, right? Isn't it therefore better to have %gs in the trapframe? -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] The only place sigreturn is called explicitly is to enter VM86 mode, and in that case, %gs is restored inside kernel as part of vm86 trapframe. In fact, you may choose to restore %gs in the kernel, but you have to be prepared to take a fault on the load_gs operation and to recover from the fault properly. The reason why %gs is not in the trapframe is that trapframe is used at all entrances to the kernel (syscall/trap/intr), if %gs is included, then we need to save and restore %gs for each syscall/trap/intr, that's about 40 clock cycles wasted each time. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rtc?
Kenneth Culver writes: I reinstalled -current today, and for some reason there is an extra device generating interrupts. When I do a systat -vm 1 I find that there is a device called rtc at irq8 generating 128 interrupts. What is it? I didn't configure it, and it wasn't there before. It has always been there, it is the RTC clock or "softclock" which is ^ You meant statclock, right? used to tally up the user/system times for processes and a few similar statistics jobs. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
TSC is initialized to 0 at hardware reset, which should happen to all CPUs at the same time (invalid assumption?), in another words, all TSCs should be automatically synchronized. They are not. The PLL is local to each cpu and every single clock-stop/start event has then inching away from each other because the on-chip VCO is very temperature dependent. Furthermore Linux The internal clock is phase-locked to an external clock source, which should be the same bus clock and identical for all cpus. The multipliers for the internal clocks should also be identical (in almost all cases unless you design your own mother board). The highest multiplier as of today is 6x (600MHz cpu on a 100MHz bus), it might increase over time, but I expect it to be still around 10. If the PLL's accuracy is 1%, the difference between two cpus could at most be 10% (or 3% = 1% * sqrt(10), assuming a Gaussian distribution of the drift) of the internal clock cycle, that is 10% (3%) of the time you might get two different readings (differ by 1) if you read TSCs of two cpus simultaneously, that's still much more accurate than the i8254 timer. people have found sufficiently many cases where the counters are not in sync after the BIOS is done. I would really like to know how they managed to read the TSCs simultaneously, or they resorted to some kind of statistical means (which I tried without much success, maybe I will try later with some kernel hooks). The multiplier is set at hard reset, so BIOS couldn't change that (some mother boards may be soft configurable, but the change has to take effect after next reset). Bus clock is external, BIOS couldn't change that either. So the internal clock is not affected by BIOS. Now it would be really hard or me to believe that TSC is not a simple counter that increments at each internal clock edge. I am very skeptical about the Linux people's findings. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers please!
If you have a PIIX4 based SMP system and run current, could you please try out this patch: http://phk.freebsd.dk/piix/ I'm very interested in hearing if there are any measurable difference apart from clock granularity being 3 times better. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! This reminds me about the usage of TSC counter on SMP. First even though we don't use TSC for time keeping on SMP, the TSC frequency from calibration is still valid (at least for BSP), and we can show it in the cpu identification message. Second, the listed reason for not using TSC on SMP is the inability to synchronize TSCs on all cpus. My question is, is it really necessary? TSC is initialized to 0 at hardware reset, which should happen to all CPUs at the same time (invalid assumption?), in another words, all TSCs should be automatically synchronized. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
start xdm on a particular vty
There have been discussions about the xdm entry /etc/ttys does not guarantee the X server being started on the particular vty. So I wrote a shell script to explicitly tell xdm to start X server on a specific vty. It's been working great. I'd like to share it with you, maybe we could include it in the base system. Here's the script (I call it xdmstart), it's very simple, #!/bin/sh case $1 in ttyv*) vt=vt`expr $1 : 'ttyv\(.*\)' + 1`;; *) vt=;; esac exec /usr/X11R6/bin/xdm -nodaemon -server ":0 local /usr/X11R6/bin/X :0 $vt" and in /etc/ttys replace the xdm line with ttyv3 "/usr/local/bin/xdmstart" xterm on secure There's one thing should be noted, the vtxx option isn't a standard X server option, but both XFree86 and Xig support it, so majority of the people should be covered. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: start xdm on a particular vty
There have been discussions about the xdm entry /etc/ttys does not guarantee the X server being started on the particular vty. So I wrote a shell script to explicitly tell xdm to start X server on a specific vty. I *like* it. I think you should share it with the XFree86 folks, and I think this would be great to have in the base installation (after proper testing of course...). Do you know the appropriate channel to contact the XFree86 folks? In the mean while, I can take Sheldon's advice, submit it to our XFree86 port. However, does this work with non-XFree86 X servers? (Or, maybe you can't test that...) I've only tested it with XFree86. Xig's document indicates it also supports the vtxx option (but I am unable to test it). I don't know anything about servers from other vendors. Nate -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with the sound card.
Could you send the output of dmesg. It could be that your BIOS has rearranged the irq settings and has put another card on that IRQ. Is the sound card PNP? If not, could you check that the card's IRQ is marked as legacy in the BIOS? Nick My sound card used to work, and with a backup kernel it still did ( I lost it ) but after doing a make update world yesturday I came to the realization that it no longer works. Did someone break the sb drivers? I get a drq / irq conflict error, but they are set to the sound card's settings. Arthur H. Johnson II http://www.linuxberg.com Linuxberg Manager [EMAIL PROTECTED] I too have problems with my on board CS4236 sound chip and it is of a very strange nature: in the new isa pnp code, function isa_assign_resources() mysteriously overwrites the isa_device structure and sets logical_id to 0, and as a result subsequent probe would not recognize it any more. I have narrowed it down to the bus_release_resource() call at the end of isa_find_irq(). It was so convoluted beyond that point and I gave up. I'd like to see someone more familiar with the code to continue. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with the sound card.
I too have problems with my on board CS4236 sound chip and it is of a very strange nature: in the new isa pnp code, function isa_assign_resources() mysteriously overwrites the isa_device structure and sets logical_id to 0, and as a result subsequent probe would not recognize it any more. I have narrowed it down to the bus_release_resource() call at the end of isa_find_irq(). It was so convoluted beyond that point and I gave up. I'd like to see someone more familiar with the code to continue. This sounds pretty strange. What do you have in your kernel config? For PnP cards, you just need: device pcm0 in the config file (i.e. no explicit bus location or resource assignments). That's exactly what I have. This is just so weird. I am now reading the debug register chapter of intel's manual, it is virtually impossible to pinpoint the location by single-stepping through the code... -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with the sound card.
That's exactly what I have. This is just so weird. I am now reading the debug register chapter of intel's manual, it is virtually impossible to pinpoint the location by single-stepping through the code... The debug register trick worked, and the discovery was quite unexpected: because the isa bus is hanging off the pci bus, bus_release_resource() call by a isa device, eventually reaches the pci_release_resource(), where the device is blindly assumed to be a pci device and its isa_device struct overwritten as if it were a struct pci_devinfo. pci_release_resource() should check for pass-thru releases. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new ncurses lib changed tgetstr() API
After the import of ncurses 5.0 (beta?), I noticed strange behavior of clear
on my xterm. I tracked it down to an API change of tgetstr(), here is the
new code:
char *tgetstr(NCURSES_CONST char *id, char **area GCC_UNUSED)
{
int i;
T((T_CALLED("tgetstr(%s,%p)"), id, area));
if (cur_term != 0) {
TERMTYPE *tp = (cur_term-type);
for_each_string(i, tp) {
const char *capname = ExtStrname(tp, i, strcodes);
T(("trying %s", capname));
if (!strncmp(id, capname, 2)) {
T(("found match : %s", _nc_visbuf(tp-Strings[i])));
/* setupterm forces cancelled strings to null */
returnPtr(tp-Strings[i]);
}
}
}
returnPtr(NULL);
}
and here is what termcap(3) says,
char *
tgetstr(const char *id, char **area)
The tgetstr() function returns the string value of the capability id,
places it in the buffer at area, and advances the area pointer.
It decodes the abbreviations for this field described in termcap(5),
except for cursor addressing and padding information. The tgetstr()
function returns NULL if the capability was not found.
The new code doesn't copy the cap string to the provided storage area, and
programs like tset and tputs expect that.
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make -j 4 buildworld race problem
Bruce Evans wrote:
"make buildworld" completes without a problem.
"make -j 4 buildworld" gives:
libncurses now has lots of internal utilities. Apparently the
dependencies for them are incomplete. The utilities are are also
built at the wrong time and break cross compiling. See the old curses
(libmytinfo part) for a (bad) way to handle internal utilities.
The right way to handle them is not to have any.
After I sent the initial email, I started to look at the
Makefile for ncurses (and friends). I knew that it had to
be a dependence problem, but quite frankly I couldn't determine
the (quick) fix.
Here's my quick fix:
Index: Makefile
===
RCS file: /home/ncvs/src/lib/libncurses/Makefile,v
retrieving revision 1.28
diff -u -r1.28 Makefile
--- Makefile1999/08/30 23:15:40 1.28
+++ Makefile1999/09/01 02:30:16
@@ -305,7 +305,7 @@
make_keys: make_keys.c names.c
${CC} -o $@ ${CFLAGS} ${NCURSES}/ncurses/tinfo/make_keys.c
-make_hash: comp_hash.c
+make_hash: comp_hash.c hashsize.h
${CC} -o $@ ${CFLAGS} -DMAIN_PROGRAM \
${NCURSES}/ncurses/tinfo/comp_hash.c
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Problems with the latest changes to ifconfig (I guess) - Bad guess...
Ian Whalley [EMAIL PROTECTED] wrote: My card is identified as 3Com 3c905B-TX Fast Etherlink XL. FWIW, I'm running a kernel about 30 hours old with a 3Com 3c905-TX Fast Etherlink XL and I'm not seeing this problem. At a quick quess, something in the miibus support broke the 3C905B support. Peter I got the same panic tonight. The xlphy attach function doesn't clean up appropriately when it aborts, here's the fix. Index: exphy.c === RCS file: /home/ncvs/src/sys/dev/mii/exphy.c,v retrieving revision 1.3 diff -u -r1.3 exphy.c --- exphy.c 1999/08/29 15:42:03 1.3 +++ exphy.c 1999/09/01 03:12:01 @@ -161,12 +161,6 @@ ma = device_get_ivars(dev); sc-mii_dev = device_get_parent(dev); mii = device_get_softc(sc-mii_dev); - LIST_INSERT_HEAD(mii-mii_phys, sc, mii_list); - - sc-mii_inst = mii-mii_instance; - sc-mii_phy = ma-mii_phyno; - sc-mii_service = exphy_service; - sc-mii_pdata = mii; /* * The 3Com PHY can never be isolated, so never allow non-zero @@ -176,6 +170,12 @@ device_printf(dev, "ignoring this PHY, non-zero instance\n"); return(ENXIO); } + LIST_INSERT_HEAD(mii-mii_phys, sc, mii_list); + + sc-mii_inst = mii-mii_instance; + sc-mii_phy = ma-mii_phyno; + sc-mii_service = exphy_service; + sc-mii_pdata = mii; mii-mii_instance++; -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with NFSv3 on a CURRENT/SMP system
I'm generating a core dump. Please note that as tara is my test machine, I use "INVARIANT" "INVARIANT_SUPPORT". Should I remove them ? It seems that from my reading of the code, the panic would not had happened without INVARIANT. It is these options that caused the panic, you either remove them from the kernel proper, or compile the kld with them. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry in free
I've been getting this panic when I've installed new kernels the last couple of times. The panic is occuring when I have freshly booted the system with a new kernel and logged on for the first time. It appears to occur at the point at which I start fetchmail in my profile, FWIW. Get rid of INVARIANTS in your config file. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4-way SMP broken ?
I have added more debugging messages, and the crash appears to be inside mp_start(). I don't have a log because this is too early in the boot to get the messages saved anywhere, and they go by too quickly to write it down. The evidence that this is an SMP problem is simple - with 2 cpu's plugged in, it works fine; with 3 or 4 cpu's plugged in, it crashes. Could you narrow down the crash further inside mp_start()? I'd like to know whether the crash occurred inside start_all_aps(). One or two lines of debug messages would be really helpful, you don't have to write down the exact words. Do you have options DDB enabled in the kernel? It helps to stop the last few lines of console messages to scroll of the screen. I believe the hardware is fine because I was previously running 19990421-CURRENT with all 4 cpu's without serious problems (it was a little unstable, but always booted ok). If possible, could you try a kernel built from sources with the POST_SMP_VMSHARE tag? I may have broken something during the commit. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 4-way SMP broken ?
Hi, I've been trying to install 19990604-CURRENT on a couple of SC450NX boxes. It works fine with 2 cpu's, but an SMP kernel with 4 cpu's falls over very quickly (I think while it's setting up the APIC stuff, or very shortly after - the messages about APIC bus ids appear on the screen very briefly, then the machine reboots itself). Do you mean messages like these? FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec0 By the time you see these messages, all cpus should have been booted up successfully, any crash immediately follows is not likely to be SMP related. It's helpful to pinpoint the crash if you could include the last few lines from a verbose boot. Does anyone know a) when was the last time it worked on 4 cpu's b) what's changed recently which might relate to this. Also in trying to figure this out I looked at the DRAM probing code in /usr/src/sys/i386/i386/machdep.c:getmemsize(), and it looks as though it's not safe for 2GB (e.g. comparisons of byte addresses against signed int end). It would also be good if this probing code was carefule not to ventrue past 4GB-64MB (PCI device space) - then a generic kernel could work on a 4GB machine without any tweaking, which would simplify installation - I get nervous shuffling DIMMs in and out of the machine ... Thanks Richard Cownie (t...@ma.ikos.com) -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 4-way SMP broken ?
Do you mean messages like these? FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec0 By the time you see these messages, all cpus should have been booted up successfully, any crash immediately follows is not likely to be SMP related. It's helpful to pinpoint the crash if you could include the last few lines from a verbose boot. interesting. then why the delay in bringing up the AP? Note in the dmesg output below, that the AP only comes up during th SCSI delay. I have also added other comments to the following output. The APs are up, but not fully initialized. Initializations that require holding of the giant lock are done near the end of the booting process, until then the APs are just spinning around the lock. Tor Egge tried once to move to an earlier time, but it didn't work well on some motherboards. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FBSDBOOT.EXE
Jonathan Lemon jle...@americantv.com says: : : Not true. VM86 is also required to support VESA. Also, it is used : for reliable memory detection (which is why I want to make it mandatory). : No more My Stinkpad only detected 64M, what do I do now??! questions. Actually, even with VM86, the kernel still doesn't correctly detect the StinkPad's memory. --Jerry name: Jerry Alexandratos || Open-Source software isn't a phone: 302.521.1018 || matter of life or death... email: jalex...@perspectives.net || ...It's much more important || than that! It just occurred to me that we might be able to use initial MTRR settings by BIOS for memory detection (P6 and above, of course). Don't know how reliable that is. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FBSDBOOT.EXE
Not at all. If there's 640k chopped off the end of eg. 128M of physical memory, you'd have to use a 64M segment, a 32M segment, a 16M segment, an 8M segment, a 4M segment, a 2M segment, a 1M segment, a 256k segment and a 128k segment to map it accurately. That's 9 variable MTRRs, and the P6 only has 8. No you don't need that many, fixed MTRRs take precedence over variable MTRRs, so you can just use one variable segment covering 0-128M and override with fixed MTRRs in the low memory area. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel and hence the whole system. Obviously it makes no sense at all to make special DOS boot floppy with older DOS just to run FBSDBOOT - it simply enough to make native FreeBSD boot floppy with /boot/loader and hacked /boot/loader.conf to boot kernel from your hard drive, so it seems that FBSDBOOT now totally useless :( Sincerely, Maxim Why can't we make a copy of the vector table and save to file and have fbsdboot use the table from the file? -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: MFS still hosed
With todays -current, mounting /tmp using swap /tmp mfs rw,nosuid,nodev,-s=32768 0 0 yields a Are you sure you have the latest -current? I committed a fix Friday night. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: page fault (apparently caused by mount_mfs)
Hi, I have been getting a panic lately with every -current kernel that I have built for the past week or so (-current cvsupped daily). Even the GENERIC kernel panics. It is occuring when the mount for a /tmp mfs filesystem is attempted. If I boot an old kernel from 5/11 or remove the fstab entry for the mfs file system the system boots up okay. My fstab entry for this is: /dev/da0s1b/tmp mfs rw,nosuid,-s=102400 0 0 and the panic messages are: Fatal trap 12: pagefault while in kernel mode fault virtual address = 0x9d334e68 fault code= Supervisor read, page not present instruction pointer = 0x8:0xc0185cb0 stack pointer = 0x10:0xc98ad84 frame pointer = 0x10:0xc98adb0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 40 (mount_mfs) interrupt mask= trap number = 12 panic: page fault Any ideas on what may be wrong? Thanks, Bob -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt How about recompile mfs kld module and try again? -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: screen panics -current
Well, this is just a quick note to anyone more knowledgable than me. screen 3.7.6 panics a current kernel. -- [gjvc] We're not laughing at you; we're laughing with you. But I'm not laughing. I committed a fix yesterday afternoon, could you cvsup and try again? -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Panic with screen w/info (was Re: Today's kernel crashes on starting X)
It seems that screen was trying to flush the master pty, before the slave tty was even open. We were lucky that this didn't crash our machines before the dev_t changes, it only caused the console to be flushed instead. But after the dev_t changes, it is fatal. Try this fix (band-aid only, better fix should involve checking of TS_OPEN bit), Index: tty_pty.c === RCS file: /home/ncvs/src/sys/kern/tty_pty.c,v retrieving revision 1.57 diff -u -r1.57 tty_pty.c --- tty_pty.c 1999/05/08 06:39:43 1.57 +++ tty_pty.c 1999/05/14 16:51:58 @@ -336,6 +336,7 @@ tp = pt_tty[minor(dev)]; if (tp-t_oproc) return (EIO); + tp-t_dev = dev; tp-t_oproc = ptsstart; #ifdef sun4c tp-t_stop = ptsstop; -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Panic with screen w/info (was Re: Today's kernel crashes on starting X)
It seems that screen was trying to flush the master pty, before the slave
tty was even open. We were lucky that this didn't crash our machines before
the dev_t changes, it only caused the console to be flushed instead. But
after the dev_t changes, it is fatal. Try this fix (band-aid only, better
fix should involve checking of TS_OPEN bit),
Here's the better fix, please let me know if it works,
Index: tty_pty.c
===
RCS file: /home/ncvs/src/sys/kern/tty_pty.c,v
retrieving revision 1.57
diff -u -r1.57 tty_pty.c
--- tty_pty.c 1999/05/08 06:39:43 1.57
+++ tty_pty.c 1999/05/14 17:32:33
@@ -674,8 +674,7 @@
tp-t_lflag = ~EXTPROC;
}
return(0);
- } else
- if (devsw(dev)-d_open == ptcopen)
+ } else if (devsw(dev)-d_open == ptcopen) {
switch (cmd) {
case TIOCGPGRP:
@@ -711,7 +710,16 @@
pti-pt_flags = ~PF_REMOTE;
ttyflush(tp, FREAD|FWRITE);
return (0);
+ }
+
+ /*
+* The rest of the ioctls shouldn't be called until
+* the slave is open. (Should we return an error?)
+*/
+ if ((tp-t_state TS_ISOPEN) == 0)
+ return (0);
+ switch (cmd) {
#ifdef COMPAT_43
case TIOCSETP:
case TIOCSETN:
@@ -735,6 +743,7 @@
ttyinfo(tp);
return(0);
}
+ }
error = (*linesw[tp-t_line].l_ioctl)(tp, cmd, data, flag, p);
if (error == ENOIOCTL)
error = ttioctl(tp, cmd, data, flag);
-lq
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
This was due to a kludge in mfs implementation. Try change NUMCDEV in kern_conf.c to 255. Are you saying that there is a bug in the mfs implementation and a fix will be commited soon? (and change NUMCDEV until then) Or are you saying, the mfs implementation is now considered correct (but there are some kludges in there) and that changing NUMCDEV in kern_conf.c to 255 is the perminate fix? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) This is a fundamental problem with mfs' design, mfs steals bdev major 255 for its private use. One thing we could do is to have mfs legally acquire this major number, i.e., setup a devsw structure and register with device conf system. This problem probably would go away after we have a fully functional DEVFS. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's kernel crashes on starting X
This also fixes the panic that I got with mfs_mount: (with options MFS in the config file, 'cvsup'ed at May 13th 19:43 UTC) Fatal trap 12: page fault while inkernel mode fault virtual address = 0x9d19fd34 fault code= supervisor read, page not present instruction pointer = 0x8:0xc016f7a0 stack pointer = 0x10:0xc494cd68 frame pointer = 0x10:0xc494cd94 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, Rres 1,def 32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 38 (mount_mfs) interrupt mask= kernel: type 12 trap, code: 0 stopped at checkalias+0x150: movl cdevsw(%eax), %edx db trace checkalias(c4478980, ff00, 0) at checkalias+0x150 mfs_mount(c08a3e00, bfbfde98, bfbfd7ac, c494cea0, c44804c0) at mfs_mount+0x132 mount(c44804c0, c494cf80,0,80691e0,2000) at mount+0x50e syscall(2f,2f,2f,2000,80691e0) at syscall+0x182 Xint0x80_syscall() at Xint0x80_syscall+0x30 Bye, Philipp This was due to a kludge in mfs implementation. Try change NUMCDEV in kern_conf.c to 255. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic ! panic ! panic !
After make world this morning I received this panic : Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0155ca4 stack pointer = 0x10:0xc6864d64 frame pointer = 0x10:0xc6864d78 code segment = base 0x0, limit 0xf, type 0x1b = DPL0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume , IOPL=0 current process = 374 (screen-3.7.6) interrupt mask = tty trap number = 12 panic: page fault I receive this panic with screen, but before I kept this box resetting itself trying to enter in X... and I was trying Xfree 3.3.3.1 (recompiled and reinstalled) SVGA, Metrolink and Xaccel 5.0 . But I could not seen the panic probably due to X loading. Could you show us the symbols around the faulting instruction at 0xc0155ca4? It would be even better if you have a crash dump and the gdb backtrace. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SMP APM
Hi, Has anyone tried having APM and SMP in the same kernel? It panic()'s mine :) Basically the machine panics a few seconds after I do 'apmconf -e'. apm seems to return normal values though. I've attached a sample output from APM, dmesg and my kernel config. I get a trap 12: page fault in kernel mode mp_lock = 0109; cpuid = 1; lapic.id = 0100 fault virtual address = 0x75f0 fault code = supervisor read, page not present interrupt pointer = 0x8:0xc0208a4c stack pointer = 0x10:0xff80dd78 frame pointer = 0x10:0xff80dd7c code segment = base 0x0, limit 0xf, type 0x1b DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask =- SMP: XXX Also, nm kernel.debug | sort shows that 0xc0208a4c is in Xbpt Are you sure it's in Xbpt? Xbpt has only 6 lines of code and none of them is likely to generate a page fault. What's the address of symbol Xbpt? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SMP APM
Yeah, well, it didn't look likely to me either but.. :-/ Here is part of nm kernel.debug | sort ... c0208a30 T Xnmi c0208a3c T Xbpt c0208a50 T Xofl ... Did you actually boot from kernel.debug? If not, use the kernel you booted from, the symbols should still be there. I'll give it another bash and see how goes.. Unfortunatly I can't get crash dumps. I should be able to get a null modem cable tomorrow, so I can try a serial console and remote gdb. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum -lq PS: `nm -n' sorts the output by address. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SMP APM
Hi,
Has anyone tried having APM and SMP in the same kernel? It panic()'s mine :)
Basically the machine panics a few seconds after I do 'apmconf -e'. apm seems
to return normal values though.
I've attached a sample output from APM, dmesg and my kernel config.
I get a trap 12: page fault in kernel mode
mp_lock = 0109; cpuid = 1; lapic.id = 0100
fault virtual address = 0x75f0
fault code = supervisor read, page not present
interrupt pointer = 0x8:0xc0208a4c
stack pointer = 0x10:0xff80dd78
frame pointer = 0x10:0xff80dd7c
code segment = base 0x0, limit 0xf, type 0x1b
DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask =- SMP: XXX
Also, nm kernel.debug | sort shows that 0xc0208a4c is in Xbpt
---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
My SMP vm sharing commit broke APM. Please try out this patch,
Index: apm.c
===
RCS file: /home/ncvs/src/sys/i386/apm/apm.c,v
retrieving revision 1.80
diff -u -r1.80 apm.c
--- apm.c 1999/04/21 07:57:55 1.80
+++ apm.c 1999/05/05 15:44:48
@@ -20,6 +20,7 @@
#include opt_devfs.h
#include opt_vm86.h
+#include opt_smp.h
#include sys/param.h
#include sys/conf.h
@@ -45,6 +46,10 @@
#include machine/vm86.h
#endif
+#ifdef SMP
+#include machine/smp.h
+#endif
+
static int apm_display __P((int newstate));
static int apm_int __P((u_long *eax, u_long *ebx, u_long *ecx, u_long *edx));
static void apm_resume __P((void));
@@ -92,6 +97,10 @@
static void
setup_apm_gdt(u_int code32_base, u_int code16_base, u_int data_base, u_int
code32_limit, u_int code16_limit, u_int data_limit)
{
+#ifdef SMP
+ int x;
+#endif
+
/* setup 32bit code segment */
gdt_segs[GAPMCODE32_SEL].ssd_base = code32_base;
gdt_segs[GAPMCODE32_SEL].ssd_limit = code32_limit;
@@ -108,6 +117,14 @@
ssdtosd(gdt_segs + GAPMCODE32_SEL, gdt[GAPMCODE32_SEL].sd);
ssdtosd(gdt_segs + GAPMCODE16_SEL, gdt[GAPMCODE16_SEL].sd);
ssdtosd(gdt_segs + GAPMDATA_SEL , gdt[GAPMDATA_SEL ].sd);
+
+#ifdef SMP
+ for (x = 1; x mp_ncpus; x++) {
+ gdt[x * NGDT + GAPMCODE32_SEL].sd = gdt[GAPMCODE32_SEL].sd;
+ gdt[x * NGDT + GAPMCODE16_SEL].sd = gdt[GAPMCODE16_SEL].sd;
+ gdt[x * NGDT + GAPMDATA_SEL ].sd = gdt[GAPMDATA_SEL ].sd;
+ }
+#endif
}
/* 48bit far pointer. Do not staticize - used from apm_setup.s */
-lq
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP! to commit SMP vmspace sharing patches
In message 199904272349.taa28...@lor.watermarkgroup.com, Luoqi Chen writes: I'm about to commit the SMP vmspace sharing patch (the %fs approach). All kernel modules will need to be recompiled. Recompilation is not neccessary for user land applications including ps, libkvm and friends. In this %fs approach, per-processor private pages are no longer mapped at identical virtual address for each cpu, instead a new segment descriptor (%fs) is setup to access per-cpu global variables like curproc. How is this accessed from C sources ? curproc is now a macro defined as an inline asm function. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
HEADS UP! to commit SMP vmspace sharing patches
I'm about to commit the SMP vmspace sharing patch (the %fs approach). All kernel modules will need to be recompiled. Recompilation is not neccessary for user land applications including ps, libkvm and friends. In this %fs approach, per-processor private pages are no longer mapped at identical virtual address for each cpu, instead a new segment descriptor (%fs) is setup to access per-cpu global variables like curproc. As a result the %fs register needs to be saved and restored at the kernel boundary, this would impose a small penalty (cpu model dependent) for each syscall and interrupt. UP kernel will also be affected as efforts were made to ensure portability of kernel modules between UP and SMP architectures. Fast vfork is now possible for SMP and is turned on as default. We're also able to get rid of vmspace juggling kludges in aio code, aio should now work correctly on SMP. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: config NO_F00F_HACK
On Sun, Apr 25, 1999, a.leidin...@wurzelausix.cs.uni-sb.de wrote:
Hi,
=20
# ident LINT
LINT:
$Id: LINT,v 1.589 1999/04/24 21:45:44 peter Exp $
=20
with:
option NO_F00F_HACK
=20
# config WORK
WORK:15: unknown option NO_F0F_HACK
^
You made a typo.
No, it is a parsing/stringification botch. It's parsed like this:
ID: NO_F
NUMBER: 00 (octal 0)
ID: F_HACK
Of course, an atoi of 00 and then a sprintf(%d) results in a single 0.
I've fixed this here and will commit it shortly, but I'm a bit nervous about
the scope of the change required to prevent this information loss. :-/ I
don't know enough lex/yacc to do context-sensitive tokenization.
This should be fairly simple, please try this,
Index: lang.l
===
RCS file: /home/ncvs/src/usr.sbin/config/lang.l,v
retrieving revision 1.19
diff -u -r1.19 lang.l
--- lang.l 1999/04/24 18:59:19 1.19
+++ lang.l 1999/04/26 11:47:35
@@ -105,11 +105,14 @@
int hex __P((char *));
%}
-WORD [-A-Za-z_][-A-Za-z_]*
+WORD [A-Za-z_][-A-Za-z_]*
+ALNUM [A-Za-z_][-A-Za-z_0-9]*
+%s NONUM
%%
-{WORD} {
+NONUM{WORD} {
int i;
+ BEGIN(0);
if ((i = kw_lookup(yytext)) == -1)
{
yylval.str = strdup(yytext);
@@ -118,6 +121,22 @@
}
tprintf((%s) , yytext);
return i;
+ }
+INITIAL{WORD} {
+ int i;
+
+ if ((i = kw_lookup(yytext)) == -1)
+ REJECT
+ if (i == CONTROLLER || i == DEVICE || i == DISK ||
+ i == PSEUDO_DEVICE || i == AT || i == ON)
+ BEGIN(NONUM);
+ tprintf((%s) , yytext);
+ return i;
+ }
+INITIAL{ALNUM} {
+ yylval.str = strdup(yytext);
+ tprintf(id(%s) , yytext);
+ return ID;
}
\\\[^]+\\\ {
yytext[strlen(yytext)-2] = '';
Cheers,
-Peter
-lq
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: config NO_F00F_HACK
It works here fine, but I can't pretend that I understand it. :-) Will you commit it? Cheers, -Peter There's some problems with one I posted (e.g. can't deal with cases where a keyword is followed immediately by a number like irq1), I'll commit a better one. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Steve Kargl wrote: That's a little foolish since we've still not found all the egcs optimizer bugs and whatnot; didn't you guys see the one Luigi found the other day for ftpd? Now *that* had to be some obscure debugging work! :-) Clearly, that goes to show Luigi must have no life... :-) Luigi is an interesting spelling of Louqi. To my defense, I thought it was Louqi, but since I have been making a lot of mistaken comments lately, I decided to trust what Jordan has said... I thought you guys had better things to do other than arguing about how to spell my name. None of them is correct anyway, it is not even in alphabets... I just wish april would go away, very, very fast... Here's a challenge to help you get by the rest of the days, figure out how to write my name, in its original form I was given at birth :-) -- Daniel C. Sobral (8-DCS) d...@newsguy.com d...@freebsd.org Well, Windows works, using a loose definition of 'works'... -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
egcs bug caused ftp hang problem
An egcs optimizer bug caused incorrect tcp checksum recalculation in libalias for the rewritten PORT command packet and the server subsequently discard the packet. The following piece of C code (from TcpChecksum() in alias_util.c) u_short *ptr; int sum, oddbyte; oddbyte = 0; *((u_char *) oddbyte) = *(u_char *) ptr; sum += oddbyte; is compiled into (%esi = ptr, %ecx = sum) 0x28067038 TcpChecksum+80:movb (%esi),%al 0x2806703a TcpChecksum+82:addl %eax,%ecx egcs should have zeroed %eax before the movb. libalias compiled without -O works correctly. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: newbus and isa auto irq
Hi,
I ave found one more thing that seems to be broken. I have used the
irq autodetect feature of the ed(4) for a long time, but it seems
that the newbus compatability shim is not doing the right thing
with it. My kernel config file have a line like this:
device ed0 at isa? port 0x280 net irq ? iomem 0xd8000
The card gets probed but you just get device timeouts and there is no
mention of an irq for that device in the probe output. Booting with
-c and specifying the irq there also didn't work. Rebuilding the kernel
with a config file which specified the irq did work though.
John
--
John Hay -- john@mikom.csir.co.za
I had the same problem. Here's a fix:
Index: isa_compat.c
===
RCS file: /home/ncvs/src/sys/i386/isa/isa_compat.c,v
retrieving revision 1.3
diff -u -r1.3 isa_compat.c
--- isa_compat.c1999/04/19 08:42:39 1.3
+++ isa_compat.c1999/04/19 10:07:41
@@ -131,12 +131,14 @@
}
}
+#defineirqmask(x) ((x) 0 ? 0 : (1 (x)))
+
static int
isa_compat_probe(device_t dev)
{
struct isa_device *dvp = device_get_softc(dev);
struct isa_compat_resources res;
-
+
bzero(res, sizeof(res));
/*
* Fill in the isa_device fields.
@@ -144,7 +146,7 @@
dvp-id_id = isa_compat_nextid();
dvp-id_driver = device_get_driver(dev)-priv;
dvp-id_iobase = isa_get_port(dev);
- dvp-id_irq = (1 isa_get_irq(dev));
+ dvp-id_irq = irqmask(isa_get_irq(dev));
dvp-id_drq = isa_get_drq(dev);
dvp-id_maddr = (void *)isa_get_maddr(dev);
dvp-id_msize = isa_get_msize(dev);
@@ -171,7 +173,7 @@
isa_set_portsize(dev, portsize);
if (dvp-id_iobase != isa_get_port(dev))
isa_set_port(dev, dvp-id_iobase);
- if (dvp-id_irq != (1 isa_get_irq(dev)))
+ if (dvp-id_irq != irqmask(isa_get_irq(dev)))
isa_set_irq(dev, ffs(dvp-id_irq) - 1);
if (dvp-id_drq != isa_get_drq(dev))
isa_set_drq(dev, dvp-id_drq);
-lq
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: newbus and isa auto irq
This is not happening for the maddr stuff. I suspect this would do better: if (portsize 0) isa_set_portsize(dev, portsize); if (dvp-id_iobase = 0) isa_set_port(dev, dvp-id_iobase); if (dvp-id_irq != 0) isa_set_irq(dev, ffs(dvp-id_irq) - 1); if (dvp-id_drq != -1) isa_set_drq(dev, dvp-id_drq); if (dvp-id_maddr != 0) isa_set_maddr(dev, (int) dvp-id_maddr - KERNBASE); if (dvp-id_msize != 0) isa_set_msize(dev, dvp-id_msize); I'm not sure about the nothing value for id_drq though, it might need to be 0 - but that's a valid dma channel. IMHO, isa_release_resources() clearing of the default values for the probe hints is a timebomb... I thought about adding a seperate store for the hint values rather than using the id_foo[0] entries, and leaving the tracked resource entries for alloc/free without risking the hints. Cheers, -Peter Off the topic, I think we should replace (dvp-id_maddr - KERNBASE) with kvtop(dvp-id_maddr), too much assumption about vm layout... -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
Hey! I've add UNICODE support to the Joliet patch. It contains few charsets now, but to add other charsets is very easy. Currently, iso8859-1 and euc-jp is included. Mixture of Joliet/RockRidge Extension is also available, however untested. Cool! I think NTFS and VFATFS could use this code too, is it possible to move the code to place like libkern/unicode? -- Motomichi Matsuzaki mz...@e-mail.ne.jp Dept. of Biological Science, Fuculty of Sciences, Univ. of Tokyo, Japan -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some news about ftp hangs
trying different configurations i have encountered the following 1. ftp in passive mode (pftp or ftp with -p options) DOES NOT hang; 2. ncftp3 from ports DOES NOT hang; 3. netscape communicator 4 DOES NOT hang. so it seems that the problem is in native FreeBSD's ftp or a library (libedit.so.2, libtermcap.so.2 or libc.so.3). I suspect libalias' ftp PORT command handling. -- sincerely, ilya naumov (at work) Here's async log output from alias enabled ppp, while ftp was retransmitting the PORT command packet: Async: 7e 3d c0 00 00 9d 21 45 00 00 38 13 42 00 00 ff ^^ Async: 01 e3 a7 cf ca 49 aa d0 17 db 4e 03 03 a2 f8 00 Async: 00 00 00 45 00 00 39 a4 4e 00 00 2e 11 79 35 d0 ^^ Async: 17 db 4e cf ca 49 aa 04 00 00 35 00 25 00 00 e3 Async: 69 7e If looked like somehow the first ip frame was overwritten by a second ip frame... -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some news about ftp hangs
Here's async log output from alias enabled ppp, while ftp was retransmitting the PORT command packet: Async: 7e 3d c0 00 00 9d 21 45 00 00 38 13 42 00 00 ff ^^ Async: 01 e3 a7 cf ca 49 aa d0 17 db 4e 03 03 a2 f8 00 ^^ ^^ ^^ protocol = ICMP unreachable port Async: 00 00 00 45 00 00 39 a4 4e 00 00 2e 11 79 35 d0 ^^ ^^ UDP Async: 17 db 4e cf ca 49 aa 04 00 00 35 00 25 00 00 e3 ^ port 53 = DNS Async: 69 7e If looked like somehow the first ip frame was overwritten by a second ip frame... Hmm, I don't see any PORT command in there ;-/ Sorry, this is a legitimate ICMP packet: port unreacheable. It looks like the ftp server (ftp.freebsd.org) was making an UDP query to DNS port on the client (which happens to have a named server running, but that's just for the internal network, external ip address is served by an outside server) and the client responds with port unreacheable even though there is a named running. I'm totally confused. I'll try to find out more. By the way, if I turn off aliasing (set alias enable off), ftp works fine again. -lq -- Brian br...@awfulhak.orgbr...@freebsd.org http://www.Awfulhak.org br...@openbsd.org Don't _EVER_ lose your sense of humour ! br...@uk.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Consistent errors making buildworld
Do you have an empty /usr/X11R6/include? The Makefile assumes you have the header files if the directory /usr/X11R6/include is present and tries to build the X version of doscmd. This assumption may not be true though. I'll change the Makefile to check for /usr/X11R6/include/X11/X.h instead. By the way, X headers only take 4M disk space, you might want to consider installing them. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Panic from today's current
The kernel-configfile and dmesg-output is available from: http://www.attic.ch/fuchur_kernel.html panic at: generic_bcopy+0x1arepe movsl (%esi), %es:(%edi) db trace generic_bcopy(c02cc380,c7bb9b1f,0,a,0) at generic_bcopy+0x1a sccnputc(cff,1,c7bb9b80,c016c066) at sccnputc+0x180 cnputc(a,0,0,a,c7bb9bcc) at cnputc+0x3d putchar(a,c7bb9bf0) at putchar+0xa6 kvprintf(c028da63,c016bfc0,c7bb9bf0,a,c7bb9c04) at kvprintf+0x64 printf(c028da49,8000,c1159b00,a8,c7bc3e60) at printf+0x3d trap(10,10,a8,c1159b00,c7bb9ce8) at trap+0x462 calltrap() at calltrap+0x3c --- trap 0x13, eip = 0xc7bb9c68, ebp = 0xc7bb9ce8 --- Trap 19 (0x13) is NMI, this problem doesn't seem to be software related. ufs_lookup(c7bb9d2c,c7bb9d40,c0184946,c7bb9d2c,c79ba00e) at ufs_lookup+0x353 ufs_vnoperate(c7bb9d2c,c79ba00e,c746e580,c7bb9f10,c746e580 at ufs_vnoperate+0x15 vfs_cache_lookup(c7bb9d84,c7bb9d94,c0186d2b,c7bb9d84,c7470e00) at vfs_cache_lookup+0x26a ufs_vnoperate(c7bb9d84,c7470e00,c7bb9f10,c1303a00,0) at ufs_vnoperate+0x15 lookup(c7bb9eec,0,c7bb9f84,fffc,c7b757f0) at lookup+0x2af namei(c7bb9eec,0,c7bb9f84,fffc,c02df240) at namei+0x291 vn_open(c7bb9eec603,1a4c7bc3e60,c029d3f0) at vn_open+0x59 open(c7bc3e60,c7bb9f84,8070aa0,10,8085680) at open+0xbb syscall(2f,2f,8085680,10,bfbfcb84) at syscall+0x182 Xint0x80_syscall() at Xint0x80_syscall+0x4c It seams to be ufs-related. Does anybody know what happened ? Martin Martin Blapp, mbl...@solnet.ch -- SolNet, Internet Solution Provider Bechburgstrasse 29, 4528 Zuchwil, Switzerland Phone: +41 32 686 82 82, Fax: +41 32 685 96 13 -- -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
thread-safe libgcc
For threaded applications to work correctly, we need a thread-safe version of libgcc. It is straight forward to build: define _PTHREADS in CFLAGS. We can have both versions just like libc and libc_r, and use the thread-safe version when linking threaded applications. If no one objects, I will add it to our tree and make necessary changes to gcc to use it. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
VM86 assembly code problem
There're a couple places in swtch.s with code like, #ifdef VM86 btrl%esi, _private_tss je 3f ... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
VM86 assembly code problem
There're a couple of places in swtch.s where code looks like this, #ifdef VM86 btrl%esi, _private_tss je 3f ... 3: #endif The conditional jump statement doesn't seem right, according to manual, btrl instruction modifies CF flag but not Z, so the jump should be jae/jb instead of je/jne. Could anyone confirm this? -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap()
The question is whether there is a way to do the autogrow function if the map lock is already held. Allow lock recurse? -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Filesystem deadlock
Luoqi Chen said: Do you still have that piece of code? Does it handle the case involves more than one process? For example, process 1 mmaps file B and reads file A into the mmapped region, while process 2 mmaps file A and reads file B, this could also result in a deadlock. It used to be part of the tree, but I seem to remember that it was removed (by those who understand the code :-)) soon after I left. I will look for it, and see if it would help with the problem(s). -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. I have some thoughts on how to solve this problem. A deadlock can occur when you read into a mmapped region or write from a mmapped region, a solution to this problem must be able to handle both cases. For the first case (read), (as originally suggested by Tor Egge), we could allow vm_fault's shared lock attempt to succeed even if there's already a process waiting for the exclusive lock. This is unlikely to create any starvation problem. For the second case (write), it's trickier if there're two processes involved. My solution is not to use exclusive lock for write, because in most cases we don't need to lock the vnode exclusively, except when disk block allocation is required. We could instead perform a lock upgrade before and a downgrade after the block allocation, so the process will only hold a shared lock when copying from the mmapped address, and thus deadlock can be avoided just as in the first case. Comments? -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Filesystem deadlock
Luoqi Chen said: This seems to be the good old vnode deadlock during vm_fault() that has been reported a couple of times, and there's still no satisfactory solution to it: fgrep does something like this: (don't ask me why) addr = mmap(0, len, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, offset); read(fd, addr, count); the read() syscall first locks the vnode, read the data from disk, then copy the data to buffer at addr, now if addr is not in core, there'll be a page fault and the fault handler vm_fault will try to lock the vnode pager backing the page at addr, which is already locked, deadlock. This deadlock then propagates all the way back to the root vnode and the whole system would freeze. I believe that I had a pseudo-fix to that, and it might have been removed. (In non-multithreaded kernels, when having to do things like the above, allowing recursive locks under certain circumstances can solve the problem. The key is to avoid the case where it covers up real bugs.) -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. Do you still have that piece of code? Does it handle the case involves more than one process? For example, process 1 mmaps file B and reads file A into the mmapped region, while process 2 mmaps file A and reads file B, this could also result in a deadlock. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Filesystem deadlock
On Mon, 22 Feb 1999, Alexander N. Kabaev wrote: The following script reliably causes FreeBSD 4.0-CURRENT (and 3.1-STABLE as of today) to lookup. Shortly after this script is started, all disk activity stops and any attempt to create new process causes system to freese. While in DDB, ps command shows, that all ten fgrep processes are sleeping on inode, all xargs are in waitpid and all sh processes are in wait. You forget about all the processes (just a few, actually) stuck in kmaw (kmem_alloc_wait). This is definitely reproducible :( Should be simple for someone more knowledgeable to diagnose, as it looks to be a straight vm/vfs(ufs/ffs) interaction. This seems to be the good old vnode deadlock during vm_fault() that has been reported a couple of times, and there's still no satisfactory solution to it: fgrep does something like this: (don't ask me why) addr = mmap(0, len, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, offset); read(fd, addr, count); the read() syscall first locks the vnode, read the data from disk, then copy the data to buffer at addr, now if addr is not in core, there'll be a page fault and the fault handler vm_fault will try to lock the vnode pager backing the page at addr, which is already locked, deadlock. This deadlock then propagates all the way back to the root vnode and the whole system would freeze. -lq Unfortunately, I cannot run -g kernel on my box at this time, so amount of useful information I can provide is pretty much limited :( #!/bin/sh for j in 1 2 3 4 5 6 7 8 9 10; do echo -n $i $j nohup sh -c 'while :; do find /usr -type f | xargs fgrep zukabuka; done' \ /dev/null 21 echo done To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: VM patch.. SMP and SO5.0
who's looked at this. Tor Egge, he has been very helpful during the development of the code. The pmap change was a result of discussions with him. It looks to me that this is serious stuff spliting the pmap out of the vmspace structure is a big change. caertainly a logical move but requires checking.. I guess it should be refered to the VM cabal. I presume that this is to be done in conjunction with the linuxthreads (and native threads) code already committed... What exactly is the reason for separating them? First, pmap is not split out of vmspace structure, it's just a trick to keep struct kinfo_proc constant size (i.e. independent of NCPU), vmspace_alloc() has been changed to allocate sizeof(struct vmspace)+sizeof(struct pmap) amount of space and pmap lives at the bottom half. julian -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SMP and SO5.0
I've gone through these patches and I can see that they are really needed for SMP where address spaces are shared. There are details I didn't get, such as where is the per-processor pde pointed, (i.e. where is the per processor KVM range) and is there a single page table for each processor that is always mapped into the processor specific slot for that process. I didn't change any of these (that's main reason I chose to have multiple page directories over a single page directory with a different slot for each processor and reference the per-processor data through a pointer in processor local storage, e.g. %fs, which is simply too complicated without compiler support. In fact I like the 2nd way better), so the process specific slot is still MPPTDI (KVM 0xff80-0xffbf?). another question that is raised I guess is how do we tell gdb to switch between processors when reading core-dumps :-). Tor has sent me a patch which implements a cpu command allowing you to switch among cpus. I've never actually used it, in most of the cases, you don't really care on which cpu the crash occurred. If you want to try it, I can send a copy of the gdb patch to you. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
/etc/defaults/rc.conf
Initially I though /etc/defaults/rc.conf stored the default settings and then we could override some of the settings in /etc/rc.conf, but after a close look at how they are used in /etc/rc*, I am confused: if [ -f /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf elif [ -f /etc/rc.conf ]; then . /etc/rc.conf fi If I have a /etc/defaults/rc.conf, then my /etc/rc.conf won't be consulted. So what is the purpose of /etc/defaults/rc.conf? -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SMP and SO5.0
Hi,
I downloaded Star Office 5 and only THEN realised that the code for doing
linux thread
emulation is #ifndef SMP :) Still, after downloading 70 meg over a 56k modem
and paying
19c/meg I was gonna try the sucker regardless.. And well, it works!
The install hung at the end, after its done everything, so I killed it, but
after that I
can run it with (seemingly) no problems.. (Except for the 2000 odd 'shared
address space
fork attempted' messages in my syslog)
I only had a quick fiddle, but it started up everything fine and ran quite
well..
The install was a pain tho, as I had to unpack the setup program (its a self
extracting
zip) and rename the libs in it to lower case and then add an LD_LIBRARY_PATH
to point to
them, but apart from that it was OK.
Its worth noting though, that eMusic which uses Linux threads doesn't work
under
emulation (it just hangs) I think I'll boot a non-SMP kernel and have a go
('cause it
took me an hour to find all of the $...@$ dependancies it needs because Linux
ldd doesn't
work anymore)
---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
You may try my patch at http://www.freebsd.org/~luoqi, which would allow
linux threads to run on SMP.
-lq
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Problems in VM structure ?
Hi. I saw that my 4-CURRENT box from 8 February dropped to ddb after my last make world. I rebuilt world today, and the same problem is occuring. These problems started occuring after Matt Dillon's changes to the VM system. What is worrying/troubling is that in single user mode, the machine is stable, and manages to build world without a problem. When booted into multi-user mode, it's stable and usable for anywhere from 1 to 3 hours, and then panics. There are no active users on at the time, and the machine is not heavily loaded (0.0-0.2) I suspected a hardware error, so swopped all the RAM from a production machine, and it still produces the same fault. The error is panic: vm_fault: fault on nofault entry, addr : f2572000 This indicates an unmapped struct buf, should be a software bug. Debugger (panic) Stopped at Debuger+0x37: movl $0,in_Debugger When I hit c, I get this : Could you type in bt next time this happens, and post the result? -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: world broken
having spent almost an hour trying to decode the complexities of the crypt making process I admit defeat.. can SOMEBODY please fix the build in -current and sent branson a nice pointy hat.. I think he committed and went on vacation (I haven't seen any commits that say they fixed this but I'm waiting for cvsup to connect just in case I missed it...) julian I spend half night yesterday to sort this mess out. If no one objects, I'll commit my fixes. (anyone volunteers to make the hat?) -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: world broken
Luoqi Chen wrote:
I spend half night yesterday to sort this mess out. If no one objects,
I'll commit my fixes. (anyone volunteers to make the hat?)
I know who gets the hat; please cool it on the fixes until the original
committer has finished.
I'm watching this one closely, and I need to track it on Internat
as well. Not long now.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
Ok, I'll let the original committer do it. For those who can't wait to try
Matt's new VM system, the following diff will help you get by. After applied
the patch, mv/cp/ln secure/lib/libcrypt/crypt.c to crypt-des.c in the same
directory. (I hope this patch doesn't reveal any information that would
harm national security :-)
-lq
Index: lib/Makefile
===
RCS file: /home/ncvs/src/lib/Makefile,v
retrieving revision 1.87
diff -u -r1.87 Makefile
--- Makefile1998/12/17 23:02:11 1.87
+++ Makefile1999/01/21 20:22:54
@@ -39,9 +39,7 @@
# Build both libraries. They have different names, so no harm,
# and this avoids having stale libscrypt.*
-.if exists(${.CURDIR}/../secure) !defined(NOSECURE) !defined(NOCRYPT)
-_libcrypt= ../secure/lib/libcrypt libcrypt
-.else
+.if !defined(NOCRYPT)
_libcrypt= libcrypt
.endif
Index: secure/lib/libcrypt/crypt.c
===
RCS file: /home/ncvs/src/secure/lib/libcrypt/crypt.c,v
retrieving revision 1.9
diff -u -r1.9 crypt.c
--- crypt.c 1997/02/22 14:40:30 1.9
+++ crypt.c 1999/01/22 23:38:24
@@ -59,9 +59,8 @@
#include sys/param.h
#include pwd.h
#include string.h
+#include crypt.h
-char *crypt_md5(const char *pw, const char *salt);
-
/* We can't always assume gcc */
#ifdef __GNUC__
#define INLINE inline
@@ -578,20 +577,26 @@
return(retval);
}
-char *
-crypt(char *key, char *setting)
+char *
+crypt_des(pw, pl, sp, sl, passwd, token)
+ const unsigned char *pw;
+ const unsigned int pl;
+ const unsigned char *sp;
+ const unsigned int sl;
+ char * passwd;
+ char * token;
{
- int i;
- u_long count, salt, l, r0, r1, keybuf[2];
- u_char *p, *q;
- static u_char output[21];
+ int i;
+ u_long count, salt, l, r0, r1, keybuf[2];
+ u_char *p, *q;
+ u_char *key = pw, *setting = sp;
+ u_char *output = (u_char *)passwd;
- if (!strncmp(setting, $1$, 3))
- return crypt_md5(key, setting);
+ if (!*setting)
+ setting = key;
if (!des_initialised)
des_init();
-
/*
* Copy the key, shifting each character up by one bit
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: src/secure breaks world
On Thu, Jan 21, 1999 at 12:26:04PM -0800, Steve Kargl wrote: cd /usr/src/secure/lib/libcrypt; /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend; /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED all; /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -B install cleandir obj rm -f .depend /usr/obj/usr/src/secure/lib/libcrypt/GPATH /usr/obj/usr/src/secure/lib/libcrypt/GRTAGS /usr/obj/usr/src/secure/lib/libcrypt/GSYMS /usr/obj/usr/src/secure/lib/libcrypt/GTAGS make: don't know how to make crypt-md5.c. Stop *** Error code 2 1 error Seem crypt-md5.c was moved into the attic, but the Makefile was updated. Do you mean wasn't updated? I am not sure that fixing the Makefile will resolve all the issues with the recent libcrypt changes. I just finished a make world, here're the changes I made, Makefile.inc1: delete secure/lib/libcrypt from bootstrap library list lib/Makefile: delete secure/lib/libcrypt from SUBDIR list secure/lib/libcrypt:rename crypt.c to crypt-des.c -lq -- Regards, Norman C. Rice, Jr. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Trouble executing from NFS with latest 4.0-current
Execute anything from NFS would result in an Input/output error, but if I do a hexdump of the executable first, the execution would be successful. If I reverse the order, i.e., execute first then hexdump, execution would fail and hexdump would hang at pgtblk. No problem with FFS. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Trouble executing from NFS with latest 4.0-current
:Execute anything from NFS would result in an Input/output error, but if I do :a hexdump of the executable first, the execution would be successful. If I :reverse the order, i.e., execute first then hexdump, execution would fail and :hexdump would hang at pgtblk. No problem with FFS. : :-lq Hmmm. It's working fine for me between two FreeBSD boxes. Do a cvs diff against your entire /usr/src/sys tree first to make sure you are up to date on all the patches. If it's still broken, we need to identify whether it is NFSV2, V3, and whether the problem is related to FreeBSD-FreeBSD or FreeBSD w/ some other platform. Also any mount options, such as read and write buffer settings, etc... -Matt Matthew Dillon dil...@backplane.com Sorry, it was an outdated nfs.ko, please disregard the report. I had some trouble with making world because of the libcrypt stuff and I'm still struggling to get everything installed right. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS problem found - pleaes try this patch.
The check is correct and should be there, the B_CACHE bit was cleared because I made a mistake when setting the valid bit in the vm page. Index: vfs_bio.c === RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.192 diff -u -r1.192 vfs_bio.c --- vfs_bio.c 1999/01/12 11:59:34 1.192 +++ vfs_bio.c 1999/01/18 14:45:33 @@ -2171,7 +2171,7 @@ (vm_offset_t) (soff PAGE_MASK), (vm_offset_t) (eoff - soff)); sv = (bp-b_offset + bp-b_validoff + DEV_BSIZE - 1) ~(DEV_BSIZE - 1); - ev = (bp-b_offset + bp-b_validend) ~(DEV_BSIZE - 1); + ev = (bp-b_offset + bp-b_validend + DEV_BSIZE - 1) ~(DEV_BSIZE - 1); soff = qmax(sv, soff); eoff = qmin(ev, eoff); } Note the calculation of ev, the original code was a round-up and I changed it to round-down in my -r1.188 commit (I thought it was a bug in the original code, but it was actually me who didn't understand the nfs code well enough). -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: arplookup 127.0.0.1 failed: could not allocate llinfo
Well, I REALLY should search mailing lists before sending useless messages... There is PR conf/14913 which describes what is going wrong. Will somebody commit the fix? I was REALLY surprised that people are so ready to accept this as a configuration bug. By all means, it is NOT, it is a kernel bug, and has to be fixed inside the kernel. Users ought to be able to config interfaces in whatever order they choose. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: init runs with console as control terminal?
Bug the authors to fix it? daemon(3) is provided for a reason! Here's my version of a simple daemonizing program Neither TIOCNOTTY nor setpgid() is sufficient to detach from a terminal session in a POSIX environment; setsid() is required. daemon(3) does a nice job of encapsulating this along with the other more obvious prerequisites. Time for a daemon(1)? I'd like to have a more flexible approach towards closing of stdin/out/err, maybe something similar to what Matt did, or similar to nohup: close it iff it's a tty. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: arplookup 127.0.0.1 failed: could not allocate llinfo
There is no need to fix kernel if the same result could be achieved by simple rc.network file modification. Yes, solution proposed in conf/14913 is not complete and only works in network_interfaces="auto" case, but the modification to make it work in 100% cases is pretty trivial. I finally found the problem, it was not a kernel bug, it was dhcp client. In /sbin/dhclient-script, it tried to install a route from localhost to the ether interface, which was bogus if the loop-back interface was not configured. Under BSD4.4, there's no need to add such a route, it will be automatically generated by the kernel. So the simplest solution to this problem is to delete all `route add xxx 127.0.0.1' statements from the script. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: init runs with console as control terminal?
/etc/rc's shell is a controlling process with control terminal /etc/console, so /dev/console is supposed to be revoked when /etc/rc's shell exits. Control terminal is for job control, and we don't need job control during /etc/rc's execution, so why don't we change init not to acquire a control terminal when executing /etc/rc. Then there's no need for the revoke, syslogd/postfix would be happy, and anything that doesn't daemonize could also be safely started as a background process. For now, I'll be using nohup to start rc5des. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
arplookup 127.0.0.1 failed: could not allocate llinfo
With the latest current, whenever I start amd, I would see a lot of log messages repeating: arplookup 127.0.0.1 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 127.0.0.1rt If I ifconfig my ether interface down, as expected, the messages would stop. It's puzzling that a packet destined for 127.0.0.1 could end up on the output queue of an ethernet card. It happens only if I run amd, I could telnet to localhost without any problem. Any idea? -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
