Well, the 3Com 574BT is still broken.
And there appears to be some more brokenness. I've attached my latest (verbose) dmesg output. USB support is weird, and (not listed in dmesg) pccardd is failing to attach my Xircom modem card (which had been working), claiming "device not configured." Suggestions? I could Really Use an ethernet connection on this laptop; right now I have the cardbus card (3Com 575CT) and the pcmcia card (the 574BT) sitting here, useless. -- Frank Mayhar [EMAIL PROTECTED] (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard found- vendor=0x8086, dev=0x7190, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base e000, size 26 found- vendor=0x8086, dev=0x7191, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 found- vendor=0x104c, dev=0xac17, revid=0x02 class=06-07-00, hdrtype=0x02, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=255 found- vendor=0x104c, dev=0xac17, revid=0x02 class=06-07-00, hdrtype=0x02, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=255 found- vendor=0x8086, dev=0x7110, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base fcd0, size 4 found- vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=d, irq=11 map[20]: type 1, range 32, base fce0, size 5 found- vendor=0x8086, dev=0x7113, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[90]: type 1, range 32, base 2180, size 4 pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 found- vendor=0x10c8, dev=0x0005, revid=0x20 class=03-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=255 map[10]: type 1, range 32, base fd00, size 24 map[14]: type 1, range 32, base fe80, size 22 map[18]: type 1, range 32, base fec0, size 20 found- vendor=0x10c8, dev=0x8005, revid=0x20 class=04-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=b, irq=11 map[10]: type 1, range 32, base fe00, size 22 map[14]: type 1, range 32, base fe70, size 20 pci1: PCI bus on pcib1 vga-pci0: NeoMagic MagicMedia 256AV SVGA controller at device 0.0 on pci1 pci1: unknown card (vendor=0x10c8, dev=0x8005) at 0.1 irq 11 chip1: PCI to CardBus bridge (vendor=104c device=ac17) at device 4.0 on pci0 chip2: PCI to CardBus bridge (vendor=104c device=ac17) at device 4.1 on pci0 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX4 IDE controller at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0: iobase=0x01f0 altiobase=0x03f6 ata0: mask=03 status0=50 status1=00 ata0: mask=03 status0=50 status1=00 ata0: devices = 0x1 ata0 at 0x01f0 irq 14 on ata-pci0 ata1: iobase=0x0170 altiobase=0x0376 ata1: mask=03 status0=50 status1=00 ata1: mask=03 status0=00 status1=00 ata1: devices = 0x4 ata1 at 0x0170 irq 15 on ata-pci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 11 at device 7.2 on pci0 uhci0: USB version 1.0, chip rev. 1 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision unknown, not supported uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: Intel 82371AB Power management controller at device 7.3 on pci0 intpm0: I/O mapped 2180 intpm0: intr IRQ 9 enabled revision 0 smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped 8000 Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 isa0: if_ep: unknown ID 0x isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0
Re: Well, the 3Com 574BT is still broken.
On Thu, 2 Dec 1999, Frank Mayhar wrote: Suggestions? I could Really Use an ethernet connection on this laptop; right now I have the cardbus card (3Com 575CT) and the pcmcia card (the 574BT) sitting here, useless. Looking at the NetBSD driver it appears that the MAC address for the 574 is stored in the CIS. It appears that the 574 has a different EEPROM layout as well, which is sort of handled by sc-epb.cmd_off but not in a manner I'm happy with. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please check missing logical IDs for SB
On Wed, Dec 01, 1999 at 10:18:26AM +0900, Seigo Tanimura wrote: If you have an SB card not probed since the import of the bridge dirvers, could you please apply the following patch, add the logical ID of your card into sbc_ids[] and see how it works? (I have asked peter to review the PnP part of the patch) Applying your patch made the kernel recognise the soundcard again without adding additional pnp ids. Thanks, Timo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Ok, I've checked, and in -current, userland stack boundary alignment
is useless because the stack pointer is initially only aligned on a
word-boundary.
I've also verified that the correct alignment is indeed expected to
apply to frame pointers, i.e. stored frame pointers are at aligned
stack slots and the current frame pointer points to an aligned
address.
Alignment can be verified by doing something like this:
struct { int a[4]; } x __attribute__((aligned(16)));
printf("offset: %u\n", (unsigned int)x 15);
You have to run the program using different arguments and argument
lengths to ensure that what you get isn't coincidental. When things
are working properly, the above should always print 0.
Note that double-alignment vs. word-alignment can really have 30%
performance impact, at least on an Athlon and one meaningless floating
point microbenchmark (operations on small, fixed-sized
matrices...maybe it isn't even *that* meaningless).
Here's a patch against -current that fixes this problem (note that
this doesn't maintain alignment for constructors, and it isn't very
pretty because it has to be done all in asm...):
Index: crt1.c
===
RCS file: /m/cvs/freebsd/src/lib/csu/i386-elf/crt1.c,v
retrieving revision 1.4
diff -u -r1.4 crt1.c
--- crt1.c 1999/08/27 23:57:57 1.4
+++ crt1.c 1999/12/02 09:02:05
@@ -92,7 +92,17 @@
monstartup(eprol, etext);
#endif
_init();
-exit( main(argc, argv, env) );
+asm volatile("andl $~15,%%esp;"
+"addl $4,%%esp;"
+"pushl %2;"
+"pushl %1;"
+"pushl %0;"
+"call main;"
+"movl %%eax,(%%esp);"
+"call exit"
+: : "rm" (argc), "rm" (argv), "rm" (env));
+for (;;)
+ ;
}
#ifdef GCRT
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: minor bug in ee?
On Thu, 02 Dec 1999 00:54:11 CST, [EMAIL PROTECTED] wrote: I recently noticed that ^v (the scroll down a page command in ee) must be entered twice to scroll down once (i.e. if you hit ^v once it won't do anything, you must hit it again) on a 4.0-CURRENT system. Sounds like ncurses takes the first ^v as "next character is literal". I doubt this is very important - should I file a PR or anything? Probably. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
re: rpc.umntall does not work with AIX
Bad MNT PRC: RPC: Remote system error Hi, This is a RPC problem, not an NFS problem. Maybe AIX does not support RPC_UMNTALL ? Because our support was buggy, noone may have notified it before. Or do you have problems with the AIX rpc.mountd ? Can you trace mountd(8) on the AIX side and look at the output ? Can you test the following cases too and tell me if it works or not (please umount and mount kan:/home/ak03 again after each command) # rpc.umtall -h kan -p /home/ak03 # rpc.umtall -h kan # umount kan:/home/ak03 What entries do you have in /var/db/mounttab ? Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor bug in ee?
On Thu, 2 Dec 1999 [EMAIL PROTECTED] wrote:
I recently noticed that ^v (the scroll down a page command in ee) must be
entered twice to scroll down once (i.e. if you hit ^v once it won't do
anything, you must hit it again) on a 4.0-CURRENT system. As far as I can
recall, this has been happening for as long as I've been tracking -CURRENT
(~1 month), and still continues on the system I updated as of Nov. 30.
3-STABLE (as of Dec. 1) doesn't have this problem - it has a simple
one-to-one ratio for ^v / scroll down. As far as I can recall, none of the
other 3.x or 2.x releases had this problem either.
I doubt this is very important - should I file a PR or anything?
This is the classic IEXTEN bug. The interaction of IEXTEN with ICANON is
implementation-defined. In FreeBSD, IEXTEN is independent of ICANON.
Buggy software doesn't know this and leaves IEXTEN set in "raw" mode.
This normally leaves ^V as the lnext character.
This bug, as it affects ee, is another libncurses bug. The old libcurses
never had it, and it was "fixed" in in rev.1.4 of lib_raw.c in the old
libncurses. Here is the "fix" cleaned up and merged into the current
lib_raw.c:
Index: ncurses/tinfo/lib_raw.c
===
RCS file: /home/ncvs/src/contrib/ncurses/ncurses/tinfo/lib_raw.c,v
retrieving revision 1.1.1.1
diff -c -2 -r1.1.1.1 lib_raw.c
*** lib_raw.c 1999/08/24 01:06:44 1.1.1.1
--- lib_raw.c 1999/12/02 10:39:01
***
*** 75,78
--- 75,82
#endif /* TRACE */
+ #ifdef TERMIOS
+ static tcflag_t iexten = 0;
+ #endif
+
int raw(void)
{
***
*** 89,93
#ifdef TERMIOS
BEFORE("raw");
! cur_term-Nttyb.c_lflag = ~(ICANON|ISIG);
cur_term-Nttyb.c_iflag = ~(COOKED_INPUT);
cur_term-Nttyb.c_cc[VMIN] = 1;
--- 93,99
#ifdef TERMIOS
BEFORE("raw");
! if (iexten == 0)
! iexten = cur_term-Nttyb.c_lflag IEXTEN;
! cur_term-Nttyb.c_lflag = ~(ICANON|ISIG|IEXTEN);
cur_term-Nttyb.c_iflag = ~(COOKED_INPUT);
cur_term-Nttyb.c_cc[VMIN] = 1;
***
*** 158,162
#ifdef TERMIOS
BEFORE("noraw");
! cur_term-Nttyb.c_lflag |= ISIG|ICANON;
cur_term-Nttyb.c_iflag |= COOKED_INPUT;
AFTER("noraw");
--- 164,168
#ifdef TERMIOS
BEFORE("noraw");
! cur_term-Nttyb.c_lflag |= ISIG|ICANON|iexten;
cur_term-Nttyb.c_iflag |= COOKED_INPUT;
AFTER("noraw");
Problems with this fix: `iexten' shouldn't exist. The IEXTEN setting for
the "noraw" state should be obtained from the original setting or forced
on or off.
Unfixed nearby problems: About 27 termios flags must be set (on or off)
for raw mode (see libc/gen/termios.c:cfmakeraw()), but raw() only sets
about 5 of them.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Problem with syscons in VESA mode
Hi, I'm using non-standard 100x37 console mode on my notebook, because in 80x25 text mode letters seems too big for my 12' panel, while other modes doesn't cover all panel size. So I've patched vidcontrol to switch to the VESA_800x600 100x37 mode (instead of default 80x25) with 8x16 font, and in most cases all works just fine (including ncurses and dialog bases apps), but sometimes when I'm building world or some other app text suddenly shifts from the edge of the screen by several spaces and all text passed to the console after that also being printed with that offset. For example: bash$ make someapp [...] blablabla blablabla blablabla blablabla blablabla [...] bash$ ls a b c d bash$ [...] I've also found that this effect disappears by switching to the other virtual console and returning to the misbehaving one. I've did some tests to find out what exactly should be passed to the console to trigger this misbehaviour and found that following string being printed when mergemaster is executing expose that (please note that this should be ONE CONTINUOUS STRING): for i in answer isdntel.sh record tell tell-record ; do install -c -o root -g wheel -m 700 $i /var/tmp/temproot/etc/isdn ; done ; for i in isdnd.rates.D isdnd.rates.F isdnd.rates.UK.BT isdnd.rc.sample isdntel.alias.sample ; do install -c -o root -g wheel -m 600 $i /var/tmp/temproot/etc/isdn ; done Sincerely, Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soundblaster 128 PCI
Russell Cattelan [EMAIL PROTECTED] writes: Dag-Erling Smorgrav wrote: I have a Soundblaster 128 PCI (labeled "MODEL:CT4810") which I can't get to work with newpcm. What mother board are you using? Asus Socket 7. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc-2.95.2, jade and freebsd-sgml-documentation
-On [19991201 23:30], Nik Clayton ([EMAIL PROTECTED]) wrote: On Sun, Nov 28, 1999 at 05:38:57PM +0100, F. Heinrichmeyer wrote: i tried to make me a new handbook, so i needed jade. But the newest C++ fashion (g++ under current) has changed to fast for this very old 1998 heavily template based source code distribution ;-). I had a lot of problems with const and not const .. and gave up. It is far to much to post here ... Unfortunately, jade is the tool of choice. I don't run -current, so haven't had a chance to test out jade with the new GCC. I think someone (obrien prolly) committed some patches to the jade port to make it compile on CURRENT. HTH, -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED] bART Internet Services / Tel: +31 - (0) 10 - 240 39 70 VIA NET.WORKS Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Ville-Pertti Keinonen wrote: Maybe alignment can even be done in the kernel... It gets messy, it has to be done before putting the env and argv pointers in place... Alignment also applies to calling signal handlers... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Maybe alignment can even be done in the kernel... It gets messy, it has to be done before putting the env and argv pointers in place... Alignment also applies to calling signal handlers... Which is easier because sigframe has a constant size and you know what the relationship between the start of the sigframe and the stack pointer at the point of signal handler entry is (unlike when copying the arguments, in which case the fixup-code for the binary type determines this). And signal handlers probably don't execute performance-critical floating point code very often... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
On 2 Dec 1999, Ville-Pertti Keinonen wrote: ... Note that double-alignment vs. word-alignment can really have 30% performance impact, at least on an Athlon and one meaningless floating point microbenchmark (operations on small, fixed-sized matrices...maybe it isn't even *that* meaningless). I verified that the default alignment is a pessimisation of 1% for a meaningful benchmark (compiling a RELENG_3 kernel) on a Celeron: gcc (current) compiled with gcc: 29.00 real11.42 user 2.28 sys 158.47 real 146.48 user10.35 sys 13.58 real11.31 user 2.20 sys 157.99 real 146.16 user11.19 sys 13.58 real11.37 user 2.14 sys 158.06 real 146.57 user10.87 sys gcc (current) compiled with gcc -mpreferred-stack-boundary=2: 13.42 real10.92 user 2.34 sys 156.94 real 144.14 user11.16 sys 13.29 real10.87 user 2.34 sys 156.43 real 144.22 user11.23 sys 13.30 real10.85 user 2.38 sys 156.14 real 144.70 user10.73 sys The times are for `time make depend; time make' after `make clean; sync; sleep 1' (2 times for each run). The stack may have been perfectly misaligned for the default gcc. Corresponding times for egcs with various PQ_L2_SIZE's a few months ago: 16 pages: 28.50 real11.78 user 2.62 sys 140.53 real 129.08 user10.55 sys 14.17 real11.72 user 2.43 sys 140.27 real 129.13 user10.83 sys 14.15 real11.77 user 2.35 sys 140.45 real 129.25 user10.85 sys 32 pages: 28.57 real11.60 user 2.69 sys 139.89 real 129.34 user 9.74 sys 14.09 real11.67 user 2.39 sys 139.65 real 128.91 user10.42 sys 14.06 real11.57 user 2.45 sys 139.80 real 129.10 user10.33 sys 64 pages: 28.51 real11.88 user 2.46 sys 140.12 real 129.18 user10.01 sys 14.11 real11.59 user 2.49 sys 139.98 real 129.10 user10.67 sys 14.10 real11.89 user 2.18 sys 140.24 real 129.24 user10.59 sys 128 pages: 28.11 real11.94 user 2.40 sys 140.14 real 129.11 user10.14 sys 14.08 real11.82 user 2.23 sys 139.97 real 129.01 user10.66 sys 14.09 real11.64 user 2.44 sys 140.22 real 129.15 user10.83 sys 256 pages: 28.31 real11.74 user 2.45 sys 139.87 real 128.90 user10.13 sys 14.17 real11.67 user 2.48 sys 139.58 real 129.36 user 9.95 sys 14.15 real11.49 user 2.60 sys 139.90 real 129.07 user10.45 sys Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: semi-HEADS-UP (dumpon now wants raw disk device)
On Wednesday, 1 December 1999 at 4:43:05 +1100, Bruce Evans wrote: On Tue, 30 Nov 1999, Thomas Stromberg wrote: [ache wrote]: " I see no needs of this change. I have -current dumpon/savecore work with old entrly like /dev/wd0... savecore understand both character and old block devices now. You must not have a very current -current :-). /dev/wd0 is a character device (with the same major/minor and character as /dev/rwd0) in -current: crw-r- 1 root operator3, 0x00010002 Dec 1 04:34 rwd0 crw-r- 1 root operator3, 0x00010002 Dec 1 04:34 wd0 Just doing a 'make world' won't do this; indeed, make world doesn't even install the new ./MAKEDEV. What steps do you use to keep your device nodes up to date? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Note that double-alignment vs. word-alignment can really have 30% performance impact, at least on an Athlon and one meaningless floating point microbenchmark (operations on small, fixed-sized matrices...maybe it isn't even *that* meaningless). I verified that the default alignment is a pessimisation of 1% for a meaningful benchmark (compiling a RELENG_3 kernel) on a Celeron: If you haven't patched crt1.c (and assuming random-length command lines) on average half of the command invocations produce double-misaligned and 75% 16-byte-misaligned stacks. The effect might not be significant when there isn't a lot of floating point code involved, it may have inadvertent side-effects on the cache-line locality of local variables. If the pessimization persists when the initial alignment is fixed, then there's a trade-off between a small pessimization for typical code and a big pessimization for less common (but more often performance-critical) code. gcc (current) compiled with gcc: 29.00 real11.42 user 2.28 sys 158.47 real 146.48 user10.35 sys 13.58 real11.31 user 2.20 sys 157.99 real 146.16 user11.19 sys The first run should be ignored because you don't have predictable cache contents at that point (I assume that's the explanation for the above), or start each sequence of timed runs in a predictable state (e.g. fresh boot). The initial overhead doesn't affect your conclusions, though, since the further runs are consistent. The times are for `time make depend; time make' after `make clean; sync; sleep 1' (2 times for each run). The stack may have been perfectly misaligned for the default gcc. It depends on the command line. It took me a while to figure out what was going on the first time I benchmarked a program that ran much faster when run under one name compared to when it was run using another name... ;--) Corresponding times for egcs with various PQ_L2_SIZE's a few months ago: Properly benchmarking page coloring can't be done in a straightforward manner, since one of the desired effects is to prevent the page selection behavior from degrading over time. Did you set up the machine specially for those runs? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Ville-Pertti Keinonen wrote: If the pessimization persists when the initial alignment is fixed, then there's a trade-off between a small pessimization for typical code and a big pessimization for less common (but more often performance-critical) code. Performance critical code should always be coded and compiled in such a way that the machine code is optimal (for whatever optimal means in this case). It doesn't really make sense to argue how default compiler settings affect the performance critical code, because default compiler settings are per definition set to suit the majority of the programs. With 16 byte alignment and even with 8 byte alignment, defaults are not set for the majority of the programs, but clearly for the special cases. That's why I want 4 byte alignments by default and 8 or 16 byte alignments explicitely set for the special cases. Anyway, enough said. This has already taken enough bandwidth without any intent to change anything :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
On 2 Dec 1999, Ville-Pertti Keinonen wrote: The times are for `time make depend; time make' after `make clean; sync; sleep 1' (2 times for each run). The stack may have been perfectly misaligned for the default gcc. It depends on the command line. It took me a while to figure out what was going on the first time I benchmarked a program that ran much faster when run under one name compared to when it was run using another name... ;--) It also depends on the environment. The bw_pipe benchmark in lmbench is 20% (?) slower on some machines (P5's or K6/1's but not both) with certain enviroments and/or command lines, because it puts its buffers on the stack and the kernel doesn't bother to align the target addresses to more than 4-byte boundaries. Corresponding times for egcs with various PQ_L2_SIZE's a few months ago: Properly benchmarking page coloring can't be done in a straightforward manner, since one of the desired effects is to prevent the page selection behavior from degrading over time. Did you set up the machine specially for those runs? I was improving page coloring, but wasn't very careful with those benchmarks, only with makeworld benchmarks. There was enough memory (320MB) to not stress my color allocator at all for kernel builds. That made kernel builds a bad benchmark for degradation of coloring but good for a quick test that color allocation hasn't become too expensive. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
There are other contexts for the same issues anyway. USB has devices that go away suddenly, and it _is_ designed to be hot-removable, so people are going to be pulling the plug on network adapters, ZIP drives, etc. We need drivers that are capable of going away cleanly, or at least without a panic. If a USB device all of a sudden disappears, in the middle of a transaction for example, the transaction simply fails. This means that all is needed is proper error checking on all functions that return an error. PCMCIA has the problem that the hardware register you are talking to can disappear on the spot, between 2 outb()s. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Well, the 3Com 574BT is still broken.
Matthew N. Dodd wrote: On Thu, 2 Dec 1999, Frank Mayhar wrote: Suggestions? I could Really Use an ethernet connection on this laptop; right now I have the cardbus card (3Com 575CT) and the pcmcia card (the 574BT) sitting here, useless. Looking at the NetBSD driver it appears that the MAC address for the 574 is stored in the CIS. It appears that the 574 has a different EEPROM layout as well, which is sort of handled by sc-epb.cmd_off but not in a manner I'm happy with. Well, if there's _anything_ I can help with, please let me know. I did dump the CIS using pccardc, but I didn't see the MAC address. I can even set the laptop up with a serial console and hook it up to a system you can log into, if that would help. I'm a pretty good kernel programmer, btw, so I _can_ get down and dirty with the code. The problem is that there's just so much I don't know about the FreeBSD kernel, that it would take me hours or days just to figure out where to start. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Well, the 3Com 574BT is still broken.
On Thu, 2 Dec 1999, Frank Mayhar wrote: Well, if there's _anything_ I can help with, please let me know. I did dump the CIS using pccardc, but I didn't see the MAC address. I can even set the laptop up with a serial console and hook it up to a system you can log into, if that would help. I'm a pretty good kernel programmer, btw, so I _can_ get down and dirty with the code. The problem is that there's just so much I don't know about the FreeBSD kernel, that it would take me hours or days just to figure out where to start. Add debugging printfs to print the value of the various things that are set using get_e(). I suspect that everything will be set to the card's board ID. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soundblaster 128 PCI
Jeroen Ruigrok/Asmodai wrote: -On [19991201 20:01], Russell Cattelan ([EMAIL PROTECTED]) wrote: Dag-Erling Smorgrav wrote: I have a Soundblaster 128 PCI (labeled "MODEL:CT4810") which I can't get to work with newpcm. What mother board are you using? There have been some reports of the new 1371's not working with non intel chip sets. Asus boards are know to be a problem. Apparently it is a timing bug in the sound card. The timing bug, is that a PCI bus clock/signal bug which the card has, or an internal timing problem? I found this message in the als archives. http://hyppo.screwdriver.net/show.phtml?id=119845 Summary: I had quite a few conversations via email with David Sowa at Ensoniq, ran a boatload of tests, found that the card worked fine in a different system, swapped cards, and finally learned the answer. Turns out that there's a hardware bug in one batch of one vendor's codecs, which causes them to lock up if the PCI reset-line timing is just so. The ALI chipset in my ASUS motherboard tickled the bug, while the Intel chipset in my test system at work did not. I have been watching the list to see if anybody has found a solution to the problem. I've had at least 4 reports of the new PCI128 not working with an ASUS board. -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Learn e-mail netiquette: http://www.lemis.com/email.html We do not count a man's years, until he has nothing left to count... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
Tony Finch wrote: Maxim Sobolev [EMAIL PROTECTED] wrote: I'm using non-standard 100x37 console mode on my notebook, because in 80x25 text mode letters seems too big for my 12' panel, while other modes doesn't cover all panel size. So I've patched vidcontrol to switch to the VESA_800x600 100x37 mode (instead of default 80x25) with 8x16 font, and in most cases all works just fine (including ncurses and dialog bases apps), but sometimes when I'm building world or some other app text suddenly shifts from the edge of the screen by several spaces and all text passed to the console after that also being printed with that offset. I've seen this on -stable with standard large modes set by vidcontrol. It is interesting. Seems like it is not only VESA modes bug. Strange that nobody else observed this misbehaviour. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
On 02-Dec-99 Maxim Sobolev wrote: Tony Finch wrote: Maxim Sobolev [EMAIL PROTECTED] wrote: I'm using non-standard 100x37 console mode on my notebook, because in 80x25 text mode letters seems too big for my 12' panel, while other modes doesn't cover all panel size. So I've patched vidcontrol to switch to the VESA_800x600 100x37 mode (instead of default 80x25) with 8x16 font, and in most cases all works just fine (including ncurses and dialog bases apps), but sometimes when I'm building world or some other app text suddenly shifts from the edge of the screen by several spaces and all text passed to the console after that also being printed with that offset. I've seen this on -stable with standard large modes set by vidcontrol. It is interesting. Seems like it is not only VESA modes bug. Strange that nobody else observed this misbehaviour. -Maxim I have seen it in 132 x anything on both -stable and -current but just haven't been bothered enough by it to complain. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Thu, 2 Dec 1999, Nick Hibma wrote: PCMCIA has the problem that the hardware register you are talking to can disappear on the spot, between 2 outb()s. Can't we do something about this using bus_space? This would give us a fair bit of overhead for PCMCIA devices as well as require us to more tightly couple newbus and bus_space (we'd probably want to 'cache' a function pointer to the method to avoid method lookup overhead.) /dirty hack -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] Nick Hibma writes: : PCMCIA has the problem that the hardware register you are talking to can : disappear on the spot, between 2 outb()s. Yes. That's why one must poll the device, from time to time, to see if it is gone. Yucky-poo. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Thu, 2 Dec 1999, Nick Hibma wrote: : PCMCIA has the problem that the hardware register you are talking to can : disappear on the spot, between 2 outb()s. : : Can't we do something about this using bus_space? This would give us a : fair bit of overhead for PCMCIA devices as well as require us to more : tightly couple newbus and bus_space (we'd probably want to 'cache' a : function pointer to the method to avoid method lookup overhead.) I had the same thought, but w/o a signal or other out of band error communication, I'm not sure how to implement this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modules building...
Did you do a config of your kernel after updating? opt_linux.h is generated by config. Nick On Tue, 30 Nov 1999, Kenneth Culver wrote: I tried to rebuild the linux kernel module, but it doesn't work: Warning: Object directory not changed from original /usr/src/sys/modules/linux cc -c -O -pipe -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/linux -I/usr/src/sys/modules/linux/@ -mpreferred-stack-boundary=2 -UKERNEL /usr/src/sys/modules/linux/../../i386/linux/linux_genassym.c cc -static -O -pipe -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/linux -I/usr/src/sys/modules/linux/@ -mpreferred-stack-boundary=2 -o linux_genassym linux_genassym.o ./linux_genassym linux_assym.h make: don't know how to make opt_linux.h. Stop several other modules exhibit similar behavior... = | Kenneth Culver| FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How do I get a USB mouse working in todays -CURRENT ?
The problem is that the mouse doesn't work (its not a hardware problem),
all I get whenever I move the mouse are lots of the following messages
on the console:
Discarded 7 bytes in queue
This means that your mouse is working but moused is closing while the
buffer is not empty yet. This looks a lot like my mistake I fixed
earlier.
Do I need to change /etc/usbd.conf in some way ?
No, you are probably looking at a stale moused.c. Please update the file
/usr/src/usr.sbin/moused/moused.c with the following diff (there is an
extra semicolon at the end of that line) and execute makemake install
in that directory:
Index: src/usr.sbin/moused/moused.c
===
RCS file: /home/ncvs/src/usr.sbin/moused/moused.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -w -r1.32 -r1.33
--- moused.c1999/11/29 17:21:07 1.32
+++ moused.c1999/11/30 10:20:33 1.33
@@ -746,7 +746,7 @@
}
/* mouse event */
- if (read(rodent.mfd, b, 1) == -1);
+ if (read(rodent.mfd, b, 1) == -1)
return; /* file seems to be closed on us */
if (r_protocol(b, action)) { /* handler detected action */
Nick
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: block devices dumpon.
I agree (patches accepted), although it is hard to figure out just exactly what is needed to "run one's system". Maybe a "remake" entry in MAKEDEV which remakes all current entries if possible. cd /dev/; sh MAKEDEV * perhaps? It is going to be one hell of a ride on your disk, remaking some nodes various times, but it should work. As Warner says, it's time for devfs. Julian? Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
On Thu, Dec 02, 1999 at 12:22:54PM -0500, John Baldwin wrote: On 02-Dec-99 Maxim Sobolev wrote: Tony Finch wrote: Maxim Sobolev [EMAIL PROTECTED] wrote: I'm using non-standard 100x37 console mode on my notebook, because in 80x25 text mode letters seems too big for my 12' panel, while other modes doesn't cover all panel size. So I've patched vidcontrol to switch to the VESA_800x600 100x37 mode (instead of default 80x25) with 8x16 font, and in most cases all works just fine (including ncurses and dialog bases apps), but sometimes when I'm building world or some other app text suddenly shifts from the edge of the screen by several spaces and all text passed to the console after that also being printed with that offset. I've seen this on -stable with standard large modes set by vidcontrol. It is interesting. Seems like it is not only VESA modes bug. Strange that nobody else observed this misbehaviour. -Maxim I have seen it in 132 x anything on both -stable and -current but just haven't been bothered enough by it to complain. Same here - just havn't found the time to check if it's maybe BIOS related (it's a rather old version on the card) or is already fixed in a newer current. It happens with current from July on a Millenium using 132x60. I don't know about other modes but I never saw this in plain mode. VESA: v2.0, 8192k memory, flags:0x0x1, mode table:0xc0bc0102 (0x122) VESA: Matrox Graphics Inc. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
According to Maxim Sobolev: It is interesting. Seems like it is not only VESA modes bug. Strange that nobody else observed this misbehaviour. I used to see that in 132 col. mode a year or so (maybe more) and it was fixed at that time... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #75: Tue Nov 2 21:03:12 CET 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: vm_page_free: freeing wired page
I am having the following panic, with a -CURRENT system as fo CTM
cvs-cur.5868. I *think* the panic was induced by running mpg123 with a not
an mp3 file. I've had two (maybe three, something happened to the box over
night.) of these panics, but hte first was with no dump device configured.
I suspect I can reproduce it, since this one I did.
su-2.03# gdb -k
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".
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /u/crash/kernel.0
(kgdb) core-file /u/crash/vmcore.0
IdlePTD 3047424
initial pcb at 2749e0
panicstr: vm_page_free: freeing wired page
panic messages:
---
panic: vm_page_free: freeing wired page
syncing disks... 6
done
dumping to dev #wd/0x20001, offset 262144
dump ata0: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110
109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88
87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63
62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38
37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13
12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:273
273 dumppcb.pcb_cr3 = rcr3();
(kgdb) trace
trace command requires an argument
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:273
#1 0xc0137115 in panic (fmt=0xc02405c0 "vm_page_free: freeing wired
page\n")
at ../../kern/kern_shutdown.c:523
#2 0xc01e1bf6 in vm_page_free_toq (m=0xc04e5a50) at ../../vm/vm_page.c:1102
#3 0xc01d9f59 in vm_fault (map=0xd8a18980, vaddr=672231424,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_page.h:504
#4 0xc021a46a in trap_pfault (frame=0xd9451fa8, usermode=1, eva=672231424)
at ../../i386/i386/trap.c:781
#5 0xc0219f7f in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134661840, tf_esi = -1077946152, tf_ebp = 0,
tf_isp = -649781292, tf_ebx = -1077946153, tf_edx = -1077946796,
tf_ecx = -1077946796, tf_eax = 672231424, tf_trapno = 12, tf_err = 4,
tf_eip = 134592249, tf_cs = 31, tf_eflags = 66070, tf_esp =
-1077946820,
tf_ss = 47}) at ../../i386/i386/trap.c:348
(kgdb)
dmesg:
opyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #6: Thu Dec 2 15:55:20 GMT 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/RALLY3
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium II/Xeon/Celeron (348.49-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x651 Stepping = 1
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR
real memory = 134217728 (131072K bytes)
avail memory = 127102976 (124124K bytes)
Preloaded elf kernel "kernel" at 0xc02d6000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc02d609c.
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard
pci0: PCI bus on pcib0
pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
vga-pci0: ATI model 4742 graphics accelerator irq 11 at device 0.0 on pci1
fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 10 at device 18.0 on
pci0
fxp0: Ethernet address 00:08:c7:89:57:ed
isab0: Intel 82371AB PCI to ISA bridge at device 20.0 on pci0
isa0: ISA bus on isab0
ata-pci0: Intel PIIX4 IDE controller at device 20.1 on pci0
ata-pci0: Busmastering DMA supported
ata0 at 0x01f0 irq 14 on ata-pci0
ata1 at 0x0170 irq 15 on ata-pci0
pci0: UHCI USB controller (vendor=0x8086, dev=0x7112) at 20.2
chip1: Intel 82371AB Power management controller at device 20.3 on pci0
isa0: unexpected tag 14
isa0: unexpected tag 14
fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5" drive on fdc0 drive 0
atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0
atkbd0: AT Keyboard irq 1 on atkbdc0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0
sc0: System console on isa0
sc0: VGA 16 virtual consoles, flags=0x200
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio2: not probed (disabled)
sio3: not probed (disabled)
ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO
Re: Problem with syscons in VESA mode
On 2 Dec, John Baldwin wrote: It is interesting. Seems like it is not only VESA modes bug. Strange that nobody else observed this misbehaviour. I have seen it in 132 x anything on both -stable and -current but just haven't been bothered enough by it to complain. I´ve seen this once (but normaly I use a xterm): - current - 132x60 If I remember correcly switching virtual consoles didn´t helped me. Bye, Alexander. -- Slower than a herd of turtles stampeding through peanut butter. http://netchild.home.pages.de Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Thu, 2 Dec 1999, Nick Hibma wrote: : PCMCIA has the problem that the hardware register you are talking to can : disappear on the spot, between 2 outb()s. : : Can't we do something about this using bus_space? This would give us a : fair bit of overhead for PCMCIA devices as well as require us to more : tightly couple newbus and bus_space (we'd probably want to 'cache' a : function pointer to the method to avoid method lookup overhead.) I had the same thought, but w/o a signal or other out of band error communication, I'm not sure how to implement this. You can't without a race. You'd have to poll the hardware before and after every I/O operation to ensure that it was still there. Yick. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
I'm using non-standard 100x37 console mode on my notebook, because in 80x25 text mode letters seems too big for my 12' panel, while other modes doesn't cover all panel size. So I've patched vidcontrol to switch to the VESA_800x600 100x37 mode (instead of default 80x25) with 8x16 font, and in most cases all works just fine (including ncurses and dialog bases apps), but sometimes when I'm building world or some other app text suddenly shifts from the edge of the screen by several spaces and all text passed to the console after that also being printed with that offset. For example: [...] This strange behavior was reported several times in the past. It must be related to screen update logic in syscons. But, I don't think we have successfully fixed it at that time :-( It's time to analyze the problem again... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
On Thursday, 2 December 1999 at 17:21:55 -0800, Matthew Jacob wrote: Well, I am truly f*cked now. I read enough of this thread, saw nothing new in UPDATING, and did the following: alpha kernel from today MAKEDEV from today (but not a make world install- the binaries/libs are ~week old) cannot get out of single user mode. fsck core dumps. Any failed command causes the single user shell to exit. What can I do to get out of this disaster other than attempt a reinstall? Can't you boot from the old kernel? Or have you already wiped the bdevs? If so, how about the fixit floppy/CD-ROM? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
Can't you boot from the old kernel? Or have you already wiped the I can boot the old kernel. A MAKEDEV using the new MAKEDEV has now wiped all block devs, so swapon, etc. ,fail.. However, this is the conundrum- it's not safe to do a 'make installworld' on a two week old kernel, but the new kernel with old mount, fsck, etc., obviously cannot cope with the new 'raw-only' devices. An experience like this will move users to OpenBSD. This kind of jump up is completely unacceptable. bdevs? If so, how about the fixit floppy/CD-ROM? This is alpha, and no floppy. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libpam?
In article [EMAIL PROTECTED], David Scheidt [EMAIL PROTECTED] wrote: Seeing this trying to build world, cvsup'd earlier today. cc -O -pipe -static -DSETPROCTITLE -DSKEY -DLOGIN_CAP -DVIRTUAL_HOSTING -Wall -I/usr/src/libexec/ftpd/../../contrib-crypto/telnet -DINTERNAL_LS -Dmain=ls_main -I/usr/src/libexec/ftpd/../../bin/ls -I/usr/obj/usr/src/tmp/usr/include -o ftpd ftpd.o ftpcmd.o logwtmp.o popen.o skey-stuff.o ls.o cmp.o print.o stat_flags.o util.o -lskey -lmd -lcrypt -lutil -lpam /usr/obj/usr/src/tmp/usr/lib/libpam.a(pam_static_modules.o): In function `_pam_get_static_sym': pam_static_modules.o(.text+0x299): undefined reference to `rad_create_request' pam_static_modules.o(.text+0x2af): undefined reference to `rad_strerror' pam_static_modules.o(.text+0x2cc): undefined reference to `rad_put_string' pam_static_modules.o(.text+0x2e9): undefined reference to `rad_put_string' ... I think it's because of the "-static" in the link command. I don't have time to find the fix at the moment, but if you look at src/bin/login you might be able to work it out yourself. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic after make new kernel with ctm source upto src-cur.4115
hello, I make world and new kernel with ctm source up to src-cur.4115 successfully. However, my system go to panic when I boot it with new kernel. The error was === Error === resume IOPL = 0 interrupt mask none -- SMPXXX trap number = 12 mp_lock = 0102 cpuid = 1 boot() call on cpu #1 . . === Error === any idea ? Thanks clarence To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
Matthew Jacob writes: Can't you boot from the old kernel? Or have you already wiped the I can boot the old kernel. A MAKEDEV using the new MAKEDEV has now wiped all block devs, so swapon, etc. ,fail.. However, this is the conundrum- it's not safe to do a 'make installworld' on a two week old kernel, but the new kernel with old mount, fsck, etc., obviously cannot cope with the new 'raw-only' devices. An experience like this will move users to OpenBSD. This kind of jump up is completely unacceptable. Slow down. You are getting screwed by a combination of things. It isn't all phk's fault. The bdev elimination is one factor, but the most important one (the fsck/mount segv) is due to int/long breakage introduced version 1.85 of mount.h. This happened at the worst possible time (just after the bdev elimination). If I wasn't such a timid committer, I would have just committed the damned fix yesterday, before running it by Kirk you wouldn't have had this problem. I tried to be vocal about it (messages to -alpha and -committers), but I guss that wasn't enought. Sorry, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FOLLOWUP: Re: HEADS-UP: bdevs have been assimilated.
Sorry- maybe more of an edge case. It really has to do with 'ad' support seemingly vanishing from the alpha. Or, rather, it's hard to say exactly what has happened: Mounting root from ufs:/dev/rad0a no such device 'rad' setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 But then, there's an older system on da0: Mounting root from ufs:da0a WARNING: clock gained 14 days -- CHECK AND RESET THE DATE! swapon: adding /dev/da0b as swap device which makes it less of a bad bad but still very very annoying. It's hard to find out what's going on because even though there is some vague attempts to stop the loader (whereupon you get a phony 'ok' prompt), no passing of variables set there occurs (so no 'bootverbose'). So, it's conceivable that this is just edge case alpha breakage. With 2 weeks to feature freeze for 4.0 it is very hard for some of us who attempt to make sure things we deliver actually work on both platforms if the second platform is broken. I'm plenty pissed off, but, c'est la vie... -matt On Thu, 2 Dec 1999, Matthew Jacob wrote: Well, I am truly f*cked now. I read enough of this thread, saw nothing new in UPDATING, and did the following: alpha kernel from today MAKEDEV from today (but not a make world install- the binaries/libs are ~week old) cannot get out of single user mode. fsck core dumps. Any failed command causes the single user shell to exit. What can I do to get out of this disaster other than attempt a reinstall? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
(removed from general list) Slow down. You are getting screwed by a combination of things. It isn't all phk's fault. The bdev elimination is one factor, but the most important one (the fsck/mount segv) is due to int/long breakage introduced version 1.85 of mount.h. This happened at the worst possible time (just after the bdev elimination). If I wasn't such a timid committer, I would have just committed the damned fix yesterday, before running it by Kirk you wouldn't have had this problem. I tried to be vocal about it (messages to -alpha and -committers), but I guss that wasn't enought. Well, I wasn't back in town until last night with 5000 messages to catch up on. Sorry for not getting your questions first. There are other things broken too. Oh well- I really shouldn't get wired. *BSD will get taken as a serious effort as much as it deserves based upon what actually *occurs*, not what I would *wish* to actually occur -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sorry....
Well, I wasn't back in town until last night with 5000 messages to catch up on. Sorry for not getting your questions first. There are other things broken too. Oh well- I really shouldn't get wired. *BSD will get taken as a serious effort as much as it deserves based upon what actually *occurs*, not what I would *wish* to actually occur Sorry- I shouldn't get so bitchy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FOLLOWUP: Re: HEADS-UP: bdevs have been assimilated.
Sorry- maybe more of an edge case. It really has to do with 'ad' support seemingly vanishing from the alpha. Or, rather, it's hard to say exactly what has happened: Mounting root from ufs:/dev/rad0a no such device 'rad' You never mount 'r' devices. That should be '/dev/ad0a', and you can override the default with either: set vfs.root.mountfrom="ufs:/dev/ad0a" in the loader at the 'ok' prompt, or by entering 'ufs:/dev/ad0a' at the emergency recovery prompt that you get after the error messages you've quoted above. But then, there's an older system on da0: Mounting root from ufs:da0a WARNING: clock gained 14 days -- CHECK AND RESET THE DATE! swapon: adding /dev/da0b as swap device which makes it less of a bad bad but still very very annoying. It's hard to find out what's going on because even though there is some vague attempts to stop the loader (whereupon you get a phony 'ok' prompt), no passing of variables set there occurs (so no 'bootverbose'). The variable's name is boot_verbose, but the Alpha has never supported it (a combination of oversight and overbusiness on both my part and Doug's). You'll find that 'boot -v' and 'load kernel -v' will achieve the desired results in the meantime, and I'll try to get it working "right" soon now that I have a 'real' alpha to work on. I'm also curious as to what's "phony" about the 'ok' prompt? Is it just that things aren't 'ok'? 8) So, it's conceivable that this is just edge case alpha breakage. With 2 weeks to feature freeze for 4.0 it is very hard for some of us who attempt to make sure things we deliver actually work on both platforms if the second platform is broken. I'm plenty pissed off, but, c'est la vie... So we should, like, feature freeze before we feature freeze? That's not so good. I don't mean to be insulting or anything, but so far most of your problems appear to be pilot error. If you take them out of the picture, it's not _really_ that bad. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Apologies
I realize that I have been much more upset and unpleasant about this than the situation warranted, and I would like to extend my apologies to all and sundry for venting my frustration so publicly. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
On Thu, Dec 02, 1999 at 08:24:19PM -0500, Greg Lehey wrote: Can't you boot from the old kernel? Or have you already wiped the bdevs? If so, how about the fixit floppy/CD-ROM? At 2MB the Alpha fixit floppy isn't very useful. Nor is there a live files system for the Alpha. Nor can you even boot sysinstall and get a shell if you use a serial console. All-in-all recovery on the Alpha is "lacking". -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
incorrect irqs with pci devices
Hi,
I have recently noticed that the irqs for my PCI devices are being screwed up
somehow. It is easily noticeable with dmesg, the correct one's are in paren.:
vga-pci0: Matrox model 0521 graphics accelerator irq 17(real 11)
at device 0.0 on pci1 ^^ ^^
pcm1: SoundBlaster Live irq 16(real 10) at device 15.0 on pci0
^^ ^^
ed0: NE2000 PCI Ethernet (RealTek 8029) irq 18(real 9) at device 18.0 on pci0
^^ ^
I used the following hack to show the real irqs:
--- pci.c.orig Fri Dec 3 02:20:56 1999
+++ pci.c Fri Dec 3 02:25:08 1999
@@ -1149,8 +1149,10 @@
retval += bus_print_child_header(dev, child);
-if (cfg-intpin 0 cfg-intline != 255)
+if (cfg-intpin 0 cfg-intline != 255){
retval += printf(" irq %d", cfg-intline);
+ printf("(real %u)", pci_read_config(child, PCI_INTERRUPT_REG,
1));
+ }
retval += printf(" at device %d.%d", pci_get_slot(child),
pci_get_function(child));
pciconf also shows the incorrect irqs (but I can read the correct
ones with the -r option for pciconf). Is this a known problem, is anyone else
experiencing this? I haven't really looked at any of the code yet ( i got lost).
Here's some other relevant info (more available on request):
pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard
pci0: PCI bus on pcib0
pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
-
Mike Heffner [EMAIL PROTECTED]
Fredericksburg, VA
ICQ# 882073
Date: 03-Dec-99 Time: 02:08:53
-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
