Re: DMA problems with IBM DeskStar drive
Greg Lehey writes: > What chip set are you using? Aladdin (it's a Super Socket 7 motherboard): Copyright (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 #1: Wed May 12 17:34:21 CEST 1999 r...@des.follo.net:/usr/src/sys/compile/DES Timecounter "i8254" frequency 1193182 Hz CPU: AMD-K6(tm) 3D processor (350.80-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping=12 Features=0x8021bf real memory = 134217728 (131072K bytes) sio0: system console avail memory = 128090112 (125088K bytes) Preloaded elf kernel "kernel" at 0xc026f000. Preloaded splash_image_data "/boot/splash.pcx" at 0xc026f09c. Preloaded elf module "splash_pcx.ko" at 0xc026f0ec. Probing for PnP devices: CSN 1 Vendor ID: CTL00f0 [0xf0008c0e] Serial 0x Comp ID: PNPb02f [0x2fb0d041] pcm1 (SB16pnp sn 0x) at 0x220-0x22f irq 10 drq 1 flags 0x10 on isa npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm: found APM BIOS version 1.2 pcib0: on motherboard pci0: on pcib0 chip0: at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: irq 11 at device 0.0 on pci1 chip1: at device 3.0 on pci0 isab0: at device 7.0 on pci0 xl0: <3Com 3c900-COMBO Etherlink XL> irq 12 at device 11.0 on pci0 xl0: Ethernet address: 00:60:08:cf:a8:e4 xl0: selecting 10baseT transceiver, half duplex ata-pci0: irq 0 at device 15.0 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 devclass_alloc_unit: apm0 already exists, using next available unit number isa0: on motherboard fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 atkbdc0: at port 0x60 on isa0 atkbd0: irq 1 on atkbdc0 vga0: on isa0 sc0: on isa0 sc0: VGA color <16 virtual consoles, flags=0x0> 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 ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold plip0: on ppbus 0 lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 IP packet filtering initialized, divert disabled, rule-based forwarding disabled, unlimited logging ata0: master: settting up UDMA2 mode on Aladdin chip OK ad0: ATA-4 disk at ata0 as master ad0: 9641MB (19746720 sectors), 19590 cyls, 16 heads, 63 S/T, 512 B/S ad0: piomode=4, dmamode=2, udmamode=2 ad0: 16 secs/int, 31 depth queue, DMA mode ata1: master: settting up UDMA2 mode on Aladdin chip OK ad1: ATA-2 disk at ata1 as master ad1: 2014MB (4124736 sectors), 4092 cyls, 16 heads, 63 S/T, 512 B/S ad1: piomode=4, dmamode=2, udmamode=2 ad1: 16 secs/int, 0 depth queue, DMA mode changing root device to wd0s4a changing root device to wd0a xl0: selecting BNC port, half duplex DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NAKAGAWA Yoshihisa writes: > > Then explain to us why newbus is wrong and why the 4.4BSD scheme is > > right. > Because, you are misunderstanding 4.4BSD scheme (and newconfig). This is pointless. All you're doing is pointing your finger and screaming "It's not right! It's not fair!" without saying anything of actual value. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Alladdin IDE slow?
I'm using an Alladin chipset in a -current machine... CPU: AMD-K6(tm) 3D processor (337.19-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping=0 Features=0x8001bf real memory = 134217728 (131072K bytes) avail memory = 126808064 (123836K bytes) chip0: at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 ata-pci0: at device 15.0 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 ata0: master: settting up UDMA2 mode on Aladdin chip OK ad0: ATA-3 disk at ata0 as master ad0: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S ad0: piomode=4, dmamode=2, udmamode=2 ad0: 16 secs/int, 0 depth queue, DMA mode ata0: slave: settting up UDMA2 mode on Aladdin chip OK ad1: ATA-3 disk at ata0 as slave ad1: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S ad1: piomode=4, dmamode=2, udmamode=2 ad1: 16 secs/int, 0 depth queue, DMA mode ata1: master: settting up UDMA2 mode on Aladdin chip OK ad2: ATA-3 disk at ata1 as master ad2: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S ad2: piomode=4, dmamode=2, udmamode=2 ata1: slave: settting up UDMA2 mode on Aladdin chip OK ad3: ATA-4 disk at ata1 as slave ad3: 16479MB (33750864 sectors), 33483 cyls, 16 heads, 63 S/T, 512 B/S ad3: piomode=4, dmamode=2, udmamode=2 ad3: 16 secs/int, 0 depth queue, DMA mode ad3 is the one getting the heaviest use, from me... However, I notice a few things from when I went to the ata driver, from a 3.1 kernel using the wd0 driver. The drive is now much slower... While I don't have numbers either way, this system acts as a nfs server. Not only are the NFS clients acting slower after my switch, but nearly all my nfsd's are sitting in biord or biowr now, where before they were usually idle. Also, the IDE LED on the case/motherboard is now acting kinda erratic. I can hear the HD doing accesses when the light is off, and at times the light seems to stay on for 2-3 seconds, when there's no activity. (This didn't happen under wd0)... Is this a case of DMA just not working well for me, or is there a magic flag I'm missing? This is -current from about a week ago. Kevin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: egcs, libstdc++, libg++, Class Library
On Thu, May 13, 1999 at 09:32:06PM -0500, Thomas T. Veldhouse wrote: > Have you tried using the C++ standard way? It works. > > #include > #include > > using namespace std; > > Of course, there are many times you won't want to include the entire > namespace. You don't need to. EGCS is still buggy with namespaces because namespace std is on by default. -- German Tischler ta...@gaspode.franken.de ta...@cip.informatik.uni-wuerzburg.de To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> This is pointless. All you're doing is pointing your finger and > screaming "It's not right! It's not fair!" without saying anything of > actual value. OK OK, you are right. I have language barrier, so I can't explain well. I talk other newconfig member, one of member, Furuta-san will go to Usenix and presentation of newconfig paper. After Usenix, still misunderstanding is exist, argument again. I will become to explain if needed. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NAKAGAWA Yoshihisa writes: > OK OK, you are right. I have language barrier, so I can't explain > well. I talk other newconfig member, one of member, Furuta-san > will go to Usenix and presentation of newconfig paper. Any chance of getting a preview of that paper? Is it, or will it be, available on the Web? DES (who won't make it to Usenix this year...) -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> Any chance of getting a preview of that paper? Is it, or will it be, > available on the Web? I don't know, probably the paper not yet available on Web. Please ask to Furuta-san. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Mikhail Teterin wrote: > > Mike Smith once wrote: > > > For a usable dynamic architecture, loadable modules need to be > > compiled to support both UP and SMP architectures simultaneously. Thus > > the locking primitives need to be conditionalised at _runtime_. > > What about > > kldload /modules/up/whatever.ko > and > kldload /modules/smp/whatever.ko > > and even > > kldload /debug-modules/up/whatever.ko > [...] Horrible kludges. Things should just work. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Proof of Trotsky's farsightedness is that _none_ of his predictions have come true yet." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: de driver problem
Wilko Bulte wrote: > > Sounds very reasonable to me. Running the same command twice to get > things really clean sounds suspicious ;-) > > In any case: I'm rebuilding now after a cvsup && chflags -R noschg > /usr/obj/* && rm -rf /usr/obj/* > > We'll see what happens next. Nothing will happen, I suppose. The idea of running clean twice is that the first one will remove /usr/obj, and the second will remove .o files in the *source* tree. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Proof of Trotsky's farsightedness is that _none_ of his predictions have come true yet." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: de driver problem
"Rodney W. Grimes" wrote:
>
> > I periodically see this one reported, and It is always repaired
> > by the reporter making sure their tree is _really_ clean before
> > doing a make world. "Really clean" means "make cleandir" _twice_,
>
> This indicates to me, the original author of ``cleandir'', that
> something has broken the functionality that it had. This something
> is more than likely the removal of code similiar to:
>
> cd /usr/obj/{.CURDIR}; chflags -R noschg tmp; rm -rf *;
>
> before the equiv of:
> cd {.CURDIR}; ${make} clean
>
> > and complete removal of the contents of /usr/obj. _Then_ cvsup.
> > I prefer to usr CVS checkout, as it shows all the differences and
> > other turds in my source tree.
>
> If ``make cleandir'' is leaving some cruft in any form behind anyplace
> in the build tree things are broken.
Not really. The problem results from people doing subtree makes
(including cleans), which results in .o files in the source tree
instead of the object tree.
--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org
"Proof of Trotsky's farsightedness is that _none_ of his
predictions have come true yet."
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
>> In article , Dag-Erling Smorgrav writes: > Any chance of getting a preview of that paper? Is it, or will it be, > available on the Web? Nakagawa-san slightly misunderstands. I have no time to write full paper, so I have already submitted presentation slide. Instead of it, I will also write speech draft of the presentation, and will place anywhere before the talk. Please wait. -- fur...@sra.co.jp (Atsushi Furuta) Advanced Technology Group. Software Research Associates, Inc. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: problem with NewScroll Mouse, etc
On Thu, 13 May 1999 23:14:25 +0930, Matthew Thyer wrote: > This is the PS/2 Intellimouse clone. (I'm note sure if 'real' > MicroSoft Intellimice work ??). Mine does under CURRENT. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: somebody has broken sysctlbyname() in -current
Stefan Bethke wrote: > > Any pointer on Forth literature/web pages would be appreciated, especially > if it's not the ANSI standard (I've looked at it, and it is that: a > standard, not a reference manual or a tutorial). My Forth knowledge is > rather rusty, I realised... last time I remember I was sitting in front of > my Apple II clone about 15 years ago. A number of documents, including tutorials, can be found starting at www.forth.org. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Proof of Trotsky's farsightedness is that _none_ of his predictions have come true yet." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NAKAGAWA Yoshihisa wrote: > > > Then explain to us why newbus is wrong and why the 4.4BSD scheme is > > right. > > Because, you are misunderstanding 4.4BSD scheme (and newconfig). The *GOAL* here is the following: You bought a computer with the super-ultra-new Microsoft (tm) Microsoft Bus (tm), for which you bought the latest and greatest device X. Now, you want device X to work. Your FreeBSD 4.5 doesn't know about Microsoft Bus, much less about device X. As it happens, this Microsoft Bus is actually mounted through USB, which happens to be available through an CardBus device, which is actually mounted on a PCI card providing the bus. What you *must* achieve is the following: cd /modules fetch http://www.microsoft.com/FreeBSD/drivers/yeah.sure./msbus.ko fetch http://www.company.x.com/drivers/deviceX/x.ko kldload x results in the msbus being loaded on demand, located and mounted across the assorted bridges, and device X driver then getting loaded, having it's resources automatically set up, and becoming available for use. No kernel recompiling of file editing can be added to above sequence, and other files should be kept to the minimum possible (strictly -- if it can be done with less, it should be done with less). The newconfig opponents fear that one must edit some file to add the information that x must be mounted over msbus, or even worse (such as kernel recompiling). If you can show that the four lines above would suffice in newconfig, you got a winner. Feel free to change the kldload x to dconfig x if you like, but 'dconfig x "at msbus"' will not be well received. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Proof of Trotsky's farsightedness is that _none_ of his predictions have come true yet." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: the new config and booting
John-Mark Gurney wrote: > > I did a couple installs using normal slices and standard MBR, and when > the machine restarted, I got the "Operating System Missing" error... > the only way I was able to install on the system was to use dangerous > dedicated mode... I've seen this happen a couple times w/ 3.0-R and > 3.1-19990328-STABLE IIRC... Standard MBR? How about using booteasy/boot0 instead? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Proof of Trotsky's farsightedness is that _none_ of his predictions have come true yet." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
David Schwartz wrote: > > Believe it or not, good ideas can even come from people who can't > code at > all, and the ideas are just as good. Slapping these people down just ensures > they don't contribute in the future. > > Now if their ideas genuinely are bad, you are more than welcome to > slap > them down as much as you wish. If that means they don't contribute more bad > ideas in the future, so much the better. Heck, it even may save you the idea > of having to explain why the bad idea is, in fact, bad. > > But "if it's such a good idea, why don't you code it?" doesn't fall > into > any of these categories. It's one of those "that's what you think" type > arguments that serves as an excuse to ignore the merits of the other side's > case. Well, it would help if the people who can't code wouldn't so often make bad suggestions and then keep trying someone else to implement them even when the people who *can* code tells them it's a bad idea, and they just won't take that for an answer. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Proof of Trotsky's farsightedness is that _none_ of his predictions have come true yet." 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
On Fri, May 14, 1999 at 02:17:28AM +0200, a little birdie told me that Sheldon Hearn remarked > > > On Fri, 14 May 1999 01:13:36 +0200, Gianmarco Giovannelli wrote: > > > Here it continues to panic with screen, same errors of yesterday... I'll > > try with X right now but I think it is the same story... :-) > > Cvsupped and maked world this afternoon (CEST). > > Well guesss what? I'm seeing panics too, after suggesting that > everything was cool and froody. :-) > > I don't have to start X, I get a panic as soon as I try to mount_mfs > -- 100% reproducible. Someone else posted a backtrace, the one that > incriminates checkalias(), I think? I have one here with sources cvsup'd around 4am (CDT) today (as in, ~4 hours ago). Start X, start up screen in an xterm, and *bing*. However, I strut my skill in manpiluating DDB while staring at a frozen X session ;> Here's some quickies from kgdb: Fatal trap 12: page fault while in kernel mode mp_lock = 0102; cpuid = 1; lapic.id = 0c00 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0162490 stack pointer = 0x10:0xcb271d4c frame pointer = 0x10:0xcb271d60 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 = 570 (screen-3.7.6) interrupt mask = tty <- SMP: XXX panic: from debugger mp_lock = 0103; cpuid = 1; lapic.id = 0c00 boot() called on cpu#1 (kgdb) where #0 0xc014f350 in boot () #1 0xc014f6ed in panic () #2 0xc012c899 in db_panic () #3 0xc012c839 in db_command () #4 0xc012c8fe in db_command_loop () #5 0xc012ea5f in db_trap () #6 0xc0213982 in kdb_trap () #7 0xc02265c2 in trap_fatal () #8 0xc0226259 in trap_pfault () #9 0xc0225ecf in trap () #10 0xc0162490 in ttyflush () #11 0xc0161bf1 in ttioctl () #12 0xc01650fe in ptyioctl () #13 0xc0181ad0 in spec_ioctl () #14 0xc01812f1 in spec_vnoperate () #15 0xc01f64c9 in ufs_vnoperatespec () #16 0xc017c045 in vn_ioctl () #17 0xc015b73f in ioctl () #18 0xc0226886 in syscall () #19 0xc02143a5 in Xint0x80_syscall () Unfortunately, it seems to be not giving me symbols. I'll try recompiling it with makeoptions=-g and see if I can't pull up one more good panic/dump real quick. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Matthew FullerMF4839http://www.over-yonder.net/ | * fulle...@futuresouth.com fulle...@over-yonder.net * | UNIX Systems Administrator Specializing in FreeBSD | * FutureSouth Communications ISPHelp ISP Consulting * | "The only reason I'm burning my candle at both ends, | *is because I haven't figured out how to light the* | middle yet" | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 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
On Fri, 14 May 1999 07:39:29 EST, "Matthew D. Fuller" wrote: > I have one here with sources cvsup'd around 4am (CDT) today (as in, > ~4 hours ago). Start X, start up screen in an xterm, and *bing*. > However, I strut my skill in manpiluating DDB while staring at a > frozen X session ;> Unfortunately, I'm using Soren's new ATA* driver, so I can't get crashdumps. Copying panics and backtraces is a PIAWUTA, as you can well imagine. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Panic with screen w/info (was Re: Today's kernel crashes on starting X)
Well, this apparently doesn't involve X, only screen.
(X may still be broken/flaky, but this doesn't involve it specifically)
This time I just ran screen on a vty, and *poof*
--
Looking at the trace below, does this look like a (if not the) problem?
#10 0xc0162490 in ttyflush (tp=0xc029dc20, rw=3) at ../../kern/tty.c:1192
1192(*devsw(tp->t_dev)->d_stop)(tp, rw);
(kgdb) print tp
$1 = (struct tty *) 0xc30010b2
(kgdb) print tp->t_dev
Cannot access memory at address 0xc300110a.
--
I can keep this trace and compile tree around for a good while, just let
me know what to poke at and I'll prod it. Panic msg and trace below.
--
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id = 0c00
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0162490
stack pointer = 0x10:0xcb1c9d4c
frame pointer = 0x10:0xcb1c9d60
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 = 372 (screen-3.7.6)
interrupt mask = tty <- SMP: XXX
panic: from debugger
mp_lock = 0103; cpuid = 1; lapic.id = 0c00
boot() called on cpu#1
#0 boot (howto=256) at ../../kern/kern_shutdown.c:288
#1 0xc014f6ed in panic (fmt=0xc0253514 "from debugger") at
../../kern/kern_shutdown.c:451
#2 0xc012c899 in db_panic (addr=-1072290672, have_addr=0, count=-1,
modif=0xcb1c9bc8 "")
at ../../ddb/db_command.c:434
#3 0xc012c839 in db_command (last_cmdp=0xc027e870, cmd_table=0xc027e6d0,
aux_cmd_tablep=0xc029ac78) at ../../ddb/db_command.c:334
#4 0xc012c8fe in db_command_loop () at ../../ddb/db_command.c:456
#5 0xc012ea5f in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#6 0xc0213982 in kdb_trap (type=12, code=0, regs=0xcb1c9d0c)
at ../../i386/i386/db_interface.c:157
#7 0xc02265c2 in trap_fatal (frame=0xcb1c9d0c, eva=20) at
../../i386/i386/trap.c:912
#8 0xc0226259 in trap_pfault (frame=0xcb1c9d0c, usermode=0, eva=20)
at ../../i386/i386/trap.c:810
#9 0xc0225ecf in trap (frame={tf_fs = -2147483624, tf_es = -1054801904,
tf_ds = 16777232,
tf_edi = -2147483648, tf_esi = 3, tf_ebp = -887317152, tf_isp =
-887317192,
tf_ebx = -1070998496, tf_edx = 0, tf_ecx = 16777217, tf_eax = 0,
tf_trapno = 12,
tf_err = 0, tf_eip = -1072290672, tf_cs = 8, tf_eflags = 66178,
tf_esp = -1070998496,
tf_ss = 3}) at ../../i386/i386/trap.c:436
#10 0xc0162490 in ttyflush (tp=0xc029dc20, rw=3) at ../../kern/tty.c:1192
#11 0xc0161bf1 in ttioctl (tp=0xc029dc20, cmd=2147775504,
data=0xcb1c9ecc, flag=3)
at ../../kern/tty.c:803
#12 0xc01650fe in ptyioctl (dev=0xf700, cmd=2147775504, data=0xcb1c9ecc
"\003", flag=3,
p=0xc9d9ea20) at ../../kern/tty_pty.c:740
#13 0xc0181ad0 in spec_ioctl (ap=0xcb1c9e08) at
../../miscfs/specfs/spec_vnops.c:441
#14 0xc01812f1 in spec_vnoperate (ap=0xcb1c9e08) at
../../miscfs/specfs/spec_vnops.c:129
#15 0xc01f64c9 in ufs_vnoperatespec (ap=0xcb1c9e08) at
../../ufs/ufs/ufs_vnops.c:2327
#16 0xc017c045 in vn_ioctl (fp=0xc1196bc0, com=2147775504,
data=0xcb1c9ecc "\003",
p=0xc9d9ea20) at vnode_if.h:395
#17 0xc015b73f in ioctl (p=0xc9d9ea20, uap=0xcb1c9f80) at
../../kern/sys_generic.c:564
#18 0xc0226886 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134697096,
tf_esi = 134672224, tf_ebp = -1077951692, tf_isp = -887316524,
tf_ebx = 672221300,
tf_edx = 134697128, tf_ecx = 6, tf_eax = 54, tf_trapno = 12, tf_err
= 2,
tf_eip = 671965400, tf_cs = 31, tf_eflags = 582, tf_esp =
-1077951716, tf_ss = 47})
at ../../i386/i386/trap.c:1066
#19 0xc02143a5 in Xint0x80_syscall ()
--
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Matthew FullerMF4839http://www.over-yonder.net/ |
* fulle...@futuresouth.com fulle...@over-yonder.net *
| UNIX Systems Administrator Specializing in FreeBSD |
* FutureSouth Communications ISPHelp ISP Consulting *
| "The only reason I'm burning my candle at both ends, |
*is because I haven't figured out how to light the*
| middle yet" |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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
Ilya Naumov writes: > GR> I'm currently running into a problem, that when I start my system, > GR> it spontaneously reboots when starting X. Has anyone else run into > GR> this? > yes, i'm experiencing the same problem with today's (May, 12) kernels. Me three. The box freezes solid before switching to graphics mode. Didn't have time to grab relevant info as this is my home box and I was late for work. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
panic still here ...
This morning after cvsupping I made a world again, but "screen" continue to go in panics. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc685bd64 stack pointer = 0x10:0xc685bd64 frame pointer = 0x10:0xc685bd78 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 kernel : type 12 trap, code 0 Stopped at ttyflush+0x48: movl 0x14(%eax), %eax It is identical at yesterday panics ... Please test also to your system. I'd like to know I am the only it happened to :-) Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
New ATA driver still can't attach to ISA controllers
Dear Soren, Do you remember that currently your famous driver (after new-bus announcement) don't probed on ISA hardwsre (in my case Toshiba CDX445)? Sincerely, Maxim ? ? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Berkeley DB 1.85 --> 2.0
Of course, DB 2 is still available as an easily installed port/package. John To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Berkeley DB 1.85 --> 2.0
On Fri, May 14, 1999 at 11:15:35AM -0400, John R. LoVerso wrote: > Of course, DB 2 is still available as an easily installed port/package. Not so easily, it conflict with libc's DB in subtle but harmful manner. -- Andrey A. Chernov http://nagual.pp.ru/~ache/ MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Berkeley DB 1.85 --> 2.0
On Fri, May 14, 1999 at 07:21:23PM +0400, Andrey A. Chernov wrote: > Not so easily, it conflict with libc's DB in subtle but harmful manner. Talking about upgrades: people on the mutt-dev list say our (outdated) ncurses is to blame for not dealing properly with SIGWINCH. Newer versions (4.2 at least) are said to get it right. Would installing the ncurses port be able to cause similar problems? Just wondering... -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Berkeley DB 1.85 --> 2.0
> Talking about upgrades: people on the mutt-dev list say our (outdated) ncurses > is to blame for not dealing properly with SIGWINCH. Works fine with libslang. > Newer versions (4.2 at least) are said to get it right. Would > installing the ncurses port be able to cause similar problems? Mutt will resize Ok with the Ncurses port. However, it is a huge library. libslang is much smaller. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Berkeley DB 1.85 --> 2.0
On Fri, May 14, 1999 at 09:17:24AM -0700, David O'Brien wrote: > Works fine with libslang. Indeed it does. -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: DMA problems with IBM DeskStar drive
Look for that setting in the SCSI BIOS > -Original Message- > From: owner-freebsd-curr...@freebsd.org > [mailto:owner-freebsd-curr...@freebsd.org]on Behalf Of Brian Feldman > Sent: Thursday, May 13, 1999 7:52 PM > To: Jordan K. Hubbard > Cc: Poul-Henning Kamp; Soren Schmidt; Dag-Erling Smorgrav; > curr...@freebsd.org > Subject: Re: DMA problems with IBM DeskStar drive > > > On Wed, 12 May 1999, Jordan K. Hubbard wrote: > > > > Try disabling "ultra DMA" in the BIOS, that seems to have worked for > > > me on my IBM-DJNA-371800 drive. > > > > > > (Jordan: We may want to put something in the README about > this in 3.2!) > > > > I'd welcome suggestions as to what the text should look like; I'm > > still unclear as to what exactly the problem us. :) > > > > I'd also be interested to know how you plan on describing > disabling UDMA, since > I don't see that option in my AMIBIOS. > > > - Jordan > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > > with "unsubscribe freebsd-current" in the body of the message > > > > Brian Feldman_ __ ___ ___ ___ ___ > gr...@unixhelp.org_ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | > http://www.freebsd.org _ |___)___/___/ > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DMA problems with IBM DeskStar drive
"Alok K. Dhir" writes: > Look for that setting in the SCSI BIOS I think not. DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DMA problems with IBM DeskStar drive
On 14 May 1999, Dag-Erling Smorgrav wrote: > "Alok K. Dhir" writes: > > Look for that setting in the SCSI BIOS > > I think not. I think not too. EIDE drives tend to not mess with SCSI too much... > > DES > -- > Dag-Erling Smorgrav - d...@yes.no > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ 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: DMA problems with IBM DeskStar drive
Sorry - I spaced. I read 'UltraSCSI', not 'UltraDMA'. *sheepish grin* Al > -Original Message- > From: Brian Feldman [mailto:gr...@unixhelp.org] > Sent: Friday, May 14, 1999 1:10 PM > To: Dag-Erling Smorgrav > Cc: ad...@forumone.com; Jordan K. Hubbard; Poul-Henning Kamp; Soren > Schmidt; curr...@freebsd.org > Subject: Re: DMA problems with IBM DeskStar drive > > > On 14 May 1999, Dag-Erling Smorgrav wrote: > > > "Alok K. Dhir" writes: > > > Look for that setting in the SCSI BIOS > > > > I think not. > > I think not too. EIDE drives tend to not mess with SCSI too much... > > > > > DES > > -- > > Dag-Erling Smorgrav - d...@yes.no > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > > with "unsubscribe freebsd-current" in the body of the message > > > > Brian Feldman_ __ ___ ___ ___ ___ > gr...@unixhelp.org_ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | > http://www.freebsd.org _ |___)___/___/ > > 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)
This looks a lot like the "I didn't use 'config -r' to generate my
latest kernel build tree" problem.
> Well, this apparently doesn't involve X, only screen.
> (X may still be broken/flaky, but this doesn't involve it specifically)
> This time I just ran screen on a vty, and *poof*
>
> --
> Looking at the trace below, does this look like a (if not the) problem?
> #10 0xc0162490 in ttyflush (tp=0xc029dc20, rw=3) at ../../kern/tty.c:1192
> 1192(*devsw(tp->t_dev)->d_stop)(tp, rw);
> (kgdb) print tp
> $1 = (struct tty *) 0xc30010b2
> (kgdb) print tp->t_dev
> Cannot access memory at address 0xc300110a.
> --
>
> I can keep this trace and compile tree around for a good while, just let
> me know what to poke at and I'll prod it. Panic msg and trace below.
>
> --
> Fatal trap 12: page fault while in kernel mode
> mp_lock = 0102; cpuid = 1; lapic.id = 0c00
> fault virtual address = 0x14
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc0162490
> stack pointer = 0x10:0xcb1c9d4c
> frame pointer = 0x10:0xcb1c9d60
> 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 = 372 (screen-3.7.6)
> interrupt mask = tty <- SMP: XXX
> panic: from debugger
> mp_lock = 0103; cpuid = 1; lapic.id = 0c00
> boot() called on cpu#1
>
>
> #0 boot (howto=256) at ../../kern/kern_shutdown.c:288
> #1 0xc014f6ed in panic (fmt=0xc0253514 "from debugger") at
> ../../kern/kern_shutdown.c:451
> #2 0xc012c899 in db_panic (addr=-1072290672, have_addr=0, count=-1,
> modif=0xcb1c9bc8 "")
> at ../../ddb/db_command.c:434
> #3 0xc012c839 in db_command (last_cmdp=0xc027e870, cmd_table=0xc027e6d0,
>
> aux_cmd_tablep=0xc029ac78) at ../../ddb/db_command.c:334
> #4 0xc012c8fe in db_command_loop () at ../../ddb/db_command.c:456
> #5 0xc012ea5f in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
> #6 0xc0213982 in kdb_trap (type=12, code=0, regs=0xcb1c9d0c)
> at ../../i386/i386/db_interface.c:157
> #7 0xc02265c2 in trap_fatal (frame=0xcb1c9d0c, eva=20) at
> ../../i386/i386/trap.c:912
> #8 0xc0226259 in trap_pfault (frame=0xcb1c9d0c, usermode=0, eva=20)
> at ../../i386/i386/trap.c:810
> #9 0xc0225ecf in trap (frame={tf_fs = -2147483624, tf_es = -1054801904,
> tf_ds = 16777232,
> tf_edi = -2147483648, tf_esi = 3, tf_ebp = -887317152, tf_isp =
> -887317192,
> tf_ebx = -1070998496, tf_edx = 0, tf_ecx = 16777217, tf_eax = 0,
> tf_trapno = 12,
> tf_err = 0, tf_eip = -1072290672, tf_cs = 8, tf_eflags = 66178,
> tf_esp = -1070998496,
> tf_ss = 3}) at ../../i386/i386/trap.c:436
> #10 0xc0162490 in ttyflush (tp=0xc029dc20, rw=3) at ../../kern/tty.c:1192
> #11 0xc0161bf1 in ttioctl (tp=0xc029dc20, cmd=2147775504,
> data=0xcb1c9ecc, flag=3)
> at ../../kern/tty.c:803
> #12 0xc01650fe in ptyioctl (dev=0xf700, cmd=2147775504, data=0xcb1c9ecc
> "\003", flag=3,
> p=0xc9d9ea20) at ../../kern/tty_pty.c:740
> #13 0xc0181ad0 in spec_ioctl (ap=0xcb1c9e08) at
> ../../miscfs/specfs/spec_vnops.c:441
> #14 0xc01812f1 in spec_vnoperate (ap=0xcb1c9e08) at
> ../../miscfs/specfs/spec_vnops.c:129
> #15 0xc01f64c9 in ufs_vnoperatespec (ap=0xcb1c9e08) at
> ../../ufs/ufs/ufs_vnops.c:2327
> #16 0xc017c045 in vn_ioctl (fp=0xc1196bc0, com=2147775504,
> data=0xcb1c9ecc "\003",
> p=0xc9d9ea20) at vnode_if.h:395
> #17 0xc015b73f in ioctl (p=0xc9d9ea20, uap=0xcb1c9f80) at
> ../../kern/sys_generic.c:564
> #18 0xc0226886 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
> tf_edi = 134697096,
> tf_esi = 134672224, tf_ebp = -1077951692, tf_isp = -887316524,
> tf_ebx = 672221300,
> tf_edx = 134697128, tf_ecx = 6, tf_eax = 54, tf_trapno = 12, tf_err
> = 2,
> tf_eip = 671965400, tf_cs = 31, tf_eflags = 582, tf_esp =
> -1077951716, tf_ss = 47})
> at ../../i386/i386/trap.c:1066
> #19 0xc02143a5 in Xint0x80_syscall ()
> --
>
>
>
> --
>
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> | Matthew FullerMF4839http://www.over-yonder.net/ |
> * fulle...@futuresouth.com fulle...@over-yonder.net *
> | UNIX Systems Administrator Specializing in FreeBSD |
> * FutureSouth Communications ISPHelp ISP Consulting *
> | "The only reason I'm burning my candle at both ends, |
> *is because I haven't figured out how to light the*
> | middle yet" |
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
>
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ m...@smith.net.au
\\ The race is long, and in the \\ msm...@freebsd.org
\\ end it's only with yourself. \\ msm...@cdrom.c
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
In message <199905141824.oaa06...@lor.watermarkgroup.com>, Luoqi Chen writes: >> > 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. I would prefer if somebody would make MFS register a devsw* entry now, because that would also work if/when DEVFS comes to town... -- 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! 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)
On Fri, May 14, 1999 at 01:36:41PM -0400, a little birdie told me
that Luoqi Chen remarked
> Here's the better fix, please let me know if it works,
I won't be in a position to crash this box again until tomorrow, but I'll
give it a whirl then.
Thanks.
> 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);
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Matthew FullerMF4839http://www.over-yonder.net/ |
* fulle...@futuresouth.com fulle...@over-yonder.net *
| UNIX Systems Administrator Specializing in FreeBSD |
* FutureSouth Communications ISPHelp ISP Consulting *
| "The only reason I'm burning my candle at both ends, |
*is because I haven't figured out how to light the*
| middle yet" |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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
On Fri, 14 May 1999, Luoqi Chen wrote: > > > 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. Actually this problem is the one that makes DEVFS explode.. It does an alias lookup on it's 'dummy' vnode and since teh sytem has been switched to use devfs routines for everything, some of it's assumptions are not longer true.. > > -lq > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New ATA driver still can't attach to ISA controllers
It seems Maxim Sobolev wrote: >Dear Soren, > >Do you remember that currently your famous driver (after new-bus >announcement) don't probed on ISA hardwsre (in my case Toshiba CDX445)? > Yes, and I have the patches right here, I just need to test it a bit more and get the time to commit it (hopefully this weekend). -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Nt source licenses...
At 3:51 PM +0700 5/12/99, Ustimenko Semen wrote: > Are we going to get this license? I am interested in NTFS > source code a lot... I would be very careful about getting an NT source license if your intention is to write NTFS support for some other operating system. Microsoft is not doing this licensing for the benefit of mankind, they are doing it to attract college-type users to sticking with WinNT over open-source unixes. The last thing we need is some code from WinNT which causes us to be sued by Microsoft... --- Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu Senior Systems Programmer(MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NYUSA To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Alladdin IDE slow?
It seems Kevin Day wrote: > > I'm using an Alladin chipset in a -current machine... > > ad3 is the one getting the heaviest use, from me... However, I notice a few > things from when I went to the ata driver, from a 3.1 kernel using the wd0 > driver. > > The drive is now much slower... While I don't have numbers either way, this > system acts as a nfs server. Not only are the NFS clients acting slower > after my switch, but nearly all my nfsd's are sitting in biord or biowr now, > where before they were usually idle. > > Also, the IDE LED on the case/motherboard is now acting kinda erratic. I can > hear the HD doing accesses when the light is off, and at times the light > seems to stay on for 2-3 seconds, when there's no activity. (This didn't > happen under wd0)... > > Is this a case of DMA just not working well for me, or is there a magic flag > I'm missing? This is -current from about a week ago. Hmm, this sounds stange, I have a noard here with the Alladin on it on which I did the support for the ata driver, it works just fine for me at least... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New ATA driver still can't attach to ISA controllers
Hi: I just wanted to say that I really appreciate the work you have/are doing. The disk drive performance under IDE is very important for the practical use of FreeBSD. Thank you! Rick Whitesel Scientist NBase-Xyplex Eml: rwhite...@nbase-xyplex.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 - Original Message - From: Soren Schmidt To: Cc: Sent: Friday, May 14, 1999 3:30 PM Subject: Re: New ATA driver still can't attach to ISA controllers It seems Maxim Sobolev wrote: >Dear Soren, > >Do you remember that currently your famous driver (after new-bus >announcement) don't probed on ISA hardwsre (in my case Toshiba CDX445)? > Yes, and I have the patches right here, I just need to test it a bit more and get the time to commit it (hopefully this weekend). -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Inlining ucmpdi2 et al
A recent commit by "Justin T. Gibbs" : > Nuke ucmpdi2.c from i386/libkern to serve as a reminder that switch > statements on 64bit values generate poor code. Looking thru libkern, many of the functions shouldn't be there since gcc should be generating in-line code. I believe the following are (or should be) superfluous: adddi3.c anddi3.c ashldi3.c ashrdi3.c cmpdi2.c iordi3.c lshldi3.c lshrdi3.c negdi2.c notdi2.c subdi3.c ucmpdi2.c udivdi3.c umoddi3.c xordi3.c I know gcc-2.8.1 had a bug relating to cmpdi2. It seems the fix didn't make it into egcs. Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Berkeley DB 1.85 --> 2.0
"Andrey A. Chernov" wrote: > On Fri, May 14, 1999 at 11:15:35AM -0400, John R. LoVerso wrote: > > Of course, DB 2 is still available as an easily installed port/package. > > Not so easily, it conflict with libc's DB in subtle but harmful manner. Only if it is configured with --enable-compat185. Just Don't Do That. (Yep, the port do it, and for this reason I consider it broken). Dima To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Solved: NPX code reports negative i586_bzero() bandwidth
Maxim Sobolev wrote:
> i586_bzero() bandwidth = -2082577916 bytes/sec
> bzero() bandwidth = 184877056 bytes/sec
It seems that on a fast machines with a lot of cache long type is not
sufficient to print i586_bzero bandwith values in bytes/s (in my case it was
slightly overruned). Following is the patch:
--- npx.c.orig Sat May 15 01:14:13 1999
+++ npx.c Sat May 15 02:01:51 1999
@@ -696,8 +696,8 @@
if (usec <= 0)
usec = 1;
if (bootverbose)
- printf("%s bandwidth = %ld bytes/sec\n",
- funcname, (long)(BUFSIZE * (int64_t)100 / usec));
+ printf("%s bandwidth = %ld Kbytes/sec\n",
+ funcname, (long)(BUFSIZE * (int64_t)100 / (1024*usec)));
free(buf, M_TEMP);
return (usec);
}
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
stable snap for smp?
If anyone has applied reasonable stress to a recent MP kernel, preferrably with X, VESA, VM86, and found it stable, do please report on your last cvs update time: I, for one, would very much like to isolate a fairly stable post-newbus world. Presumably this would be helpful to other readers as well, it being so much easier to bounce between worlds which are more nearly contemporaneous. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Inlining ucmpdi2 et al
>Looking thru libkern, many of the functions shouldn't be there since >gcc should be generating in-line code. I believe the following are >(or should be) superfluous: adddi3.c anddi3.c ashldi3.c ashrdi3.c >cmpdi2.c iordi3.c lshldi3.c lshrdi3.c negdi2.c notdi2.c subdi3.c >ucmpdi2.c udivdi3.c umoddi3.c xordi3.c We leave all these out (of files.i386) for i386's, but they might be necessary for another arch, and *cmpdi2.c turn out to be not quite superfluous. >I know gcc-2.8.1 had a bug relating to cmpdi2. It seems the fix didn't >make it into egcs. The one for comparison in 64-bit signed divisions seems to be fixed, but there is another for 64-bit case comparisons. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic still here ...
On Friday, 14 May 1999 at 14:36:58 +0200, Gianmarco Giovannelli wrote: > > This morning after cvsupping I made a world again, but "screen" continue to > go in panics. > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x14 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc685bd64 > stack pointer = 0x10:0xc685bd64 > frame pointer = 0x10:0xc685bd78 > 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 > kernel : type 12 trap, code 0 > Stopped at ttyflush+0x48: movl 0x14(%eax), %eax > > It is identical at yesterday panics ... > Please test also to your system. I'd like to know I am the only it happened > to :-) The real thing to do here is to take a dump and see where it's happening. There's a description in the handbook. Contact me if you have trouble. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> You bought a computer with the super-ultra-new Microsoft (tm) > Microsoft Bus (tm), for which you bought the latest and greatest > device X. It is extremely vulgar joke. I doubt your character. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! config(8) changes..
In old mail, John Polstra wrote: >In article <19990424190901.d3a791...@spinner.netplex.com.au>, >Peter Wemm wrote: >> ... >> So: things like: >> device sio1 at isa? tty port "IO_COM2" tty irq 3 >> become: >> device sio1 at isa? port IO_COM2 irq3 > >What do you do about the "ppc" device? Formerly, it needed to be "net >irq ..." if the "plip" device was going to be used, but "tty irq ..." >otherwise. Which one did you pick? tty was picked (see isa_compat.h). Also, support for the hack of setting net_imask = tty_imask if slip is configured went away, so slip now has the same problems as plip. I think most of these problems can be avoided by configuring (kernel) ppp. ppp sets net_imask >= tty_imask, which is sufficient provided slip and plip call splimp() as required. Only cases where the masks change significantly after ppp is initialised are necessarily broken. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! config(8) changes..
Bruce Evans wrote: > In old mail, John Polstra wrote: >> >>What do you do about the "ppc" device? Formerly, it needed to be "net >>irq ..." if the "plip" device was going to be used, but "tty irq ..." >>otherwise. Which one did you pick? > > tty was picked (see isa_compat.h). Also, support for the hack of > setting net_imask = tty_imask if slip is configured went away, so slip > now has the same problems as plip. I think most of these problems can be > avoided by configuring (kernel) ppp. ppp sets net_imask >= tty_imask, > which is sufficient provided slip and plip call splimp() as required. > Only cases where the masks change significantly after ppp is initialised > are necessarily broken. It seems to me that all this spl hackery would be better avoided, through a userland approach that used the tun device or something similar. John To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New ATA driver still can't attach to ISA controllers
On Fri, 14 May 1999, Rick Whitesel wrote: > I just wanted to say that I really appreciate the work you have/are > doing. The disk drive performance under IDE is very important for the > practical use of FreeBSD. > > Thank you! I second that - thank you ! Andrew. -- +-- | Andrew Atrens Nortel Networks, Ottawa, Canada. | | All opinions expressed are my own, not those of any employer. | --+ Heller's Law: The first myth of management is that it exists. Johnson's Corollary: Nobody really knows what is going on anywhere within the organization. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
From: NAKAGAWA Yoshihisa y-nakaga> > You bought a computer with the super-ultra-new Microsoft (tm) y-nakaga> > Microsoft Bus (tm), for which you bought the latest and greatest y-nakaga> > device X. y-nakaga> y-nakaga> It is extremely vulgar joke. I doubt your character. No, I don't think this is a joke, but a serious situation. We should stick on technical problem if we continue to discuss. Tomoaki Nishiyama e-mail:tomo...@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo 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
In message , Julian Elischer writes: > >On Fri, 14 May 1999, Luoqi Chen wrote: > >> > > 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. > >Actually this problem is the one that makes DEVFS explode.. >It does an alias lookup on it's 'dummy' vnode and since teh sytem has been >switched to use devfs routines for everything, some of it's >assumptions are not longer true.. I don't expect the current DEVFS prototype to be indicative of how our real DEVFS will work. -- 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! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
