Re: IRQ sharing with newbus
On Tue, 1 Jun 1999, Matthew N. Dodd wrote: > On Tue, 1 Jun 1999, Doug Rabson wrote: > > For EISA, it should be possible to add RF_SHAREABLE to the > > bus_alloc_resource call (assuming that EISA interrupts are shareable > > like pci interrupts). > > The observed behavior suggests that RF_SHAREABLE is not being honored. > > dpt99: DPT PM2022A/9X FW Rev. 07CK, 1 channel, 64 CCBs > dpt0: at slot 4 on eisa0 > dpt0: DPT PM2022A/9X FW Rev. 07CK, 1 channel, 64 CCBs > dpt99: DPT PM2022A/9X FW Rev. 005A, 1 channel, 64 CCBs > dpt1: at slot 5 on eisa0 > dpt1: No irq?! > device_probe_and_attach: dpt1 attach returned -1 > > (The 'dpt99' lines are an artifact of the mechanism I'm using to complete > the probe.) > > Now, since the resource ranges aren't printed anymore, you can't see that > both cards are using (set to use) the same IRQ. The EISA bus code needs a new maintainer (who could put back such things as resource reporting). Are you interested? You seem to be one of the few people who actively uses this bus. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: No sound (Ensoniq Audio PCI 1370)
On Tue, 1 Jun 1999, Joachim Kuebart wrote: > Stefan Esser wrote: > > On 1999-05-27 22:12 +0400, oZZ!!! wrote: > > > > > > wmsound with my card too can't work correct. > > > SB 128 PCI its a PCI-device & (as i known) it must be detect as es0 + pcm1 > > > (not pcm0), because pcm0 reserved for ISA-device (right?). Kernel at > > > boot-time detect my SB 128 PCI as es0 + pcm0... > > > > What's going on ? > > > > I guess that after the PCI attach of es0/pcm0, the ISA probe tries to > > attach an ISA card as pcm0, too, and stomps over the values filled into > > the device structure for the PCI card ... > > That's right, and it's because the implementation is broken: the PCI driver > part in /sys/pci/es1370.c uses the name "es" instead of "pcm". I.e. if it > used "pcm", different unit numbers would get assigned to ISA and PCI > devices and no clashes would result. > > Sorry I didn't make this a PR before, but I'm working on the driver and > it's in no condition to be released. This was my fault, so here's the fix: There is no need for a PR. Cameron's driver already has the correct name for this driver. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
On Tue, Jun 01, 1999 at 02:16:55PM -0600, Nate Williams wrote: > > this is less and less of a problem because > > if you lose your link on PPP > > you are liable to get a differetn IP address on your redial. > > Not true. Only if you're using a dynamic IP address setup. Most > business connections have a static connection, so they'll end up with > the same IP address everytime. I would take issue with that. All of the regional registries require extremely good justification for allocating static IP addresses to transient network connections. This might be something that older, established providers are able to do (since they were delegated way too many addresses in the good ol' days) but it isn't an option for (m)any ISPs younger than three or four years. When it comes down to it, there is very little justification for a static address. The one I most commonly hear is "so we can do SMTP mail delivery to the customer", but even that doesn't mandate use of static addressing -- we support SMTP mail delivery (we call it "mailbagging" for some reason) to dynamically-addressed dial-up clients, and it works just fine. Other times the reason is "so the customer can carry on downloading after the line dropped" to which the answer is "maintain your access servers properly and this won't happen". Anyway, this is off-topic. Back to your scheduled programming. Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
svr4 module broken after VM86 change
The svr4 module is broken after the following change to svr4_machdep.c
rev 1.5.
--
revision 1.5
date: 1999/06/01 18:20:23; author: jlemon; state: Exp; lines: +0 -4
Unifdef VM86.
Reviewed by:silence on on -current
--
The problem is svr4_getcontext() and svr4_setcontext() now refers
to tf_vm86_xx fields which are defined in struct trapframe_vm68
but not in p->p_md.md_regs (struct trapframe).
int
svr4_setcontext(p, uc)
struct proc *p;
struct svr4_ucontext *uc;
{
struct sigacts *psp = p->p_sigacts;
register struct trapframe *tf;
svr4_greg_t *r = uc->uc_mcontext.greg;
struct svr4_sigaltstack *s = &uc->uc_stack;
struct sigaltstack *sf = &psp->ps_sigstk;
int mask;
[...]
if ((uc->uc_flags & SVR4_UC_CPU) == 0)
return 0;
tf = p->p_md.md_regs;
/*
* Restore register context.
*/
if (r[SVR4_X86_EFL] & PSL_VM) {
tf->tf_vm86_gs = r[SVR4_X86_GS];
tf->tf_vm86_ffs = r[SVR4_X86_FS];
tf->tf_vm86_es = r[SVR4_X86_ES];
tf->tf_vm86_ds = r[SVR4_X86_DS];
set_vflags(p, r[SVR4_X86_EFL]);
} else
{
[...]
Kazu
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: IRQ sharing with newbus
On Wed, 2 Jun 1999, Doug Rabson wrote: > The EISA bus code needs a new maintainer (who could put back such > things as resource reporting). Are you interested? You seem to be one > of the few people who actively uses this bus. I'm still fairly far behind on the learning curve with respect to the new_bus code so I can't really promise anything. :/ -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | win...@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: svr4 module broken after VM86 change
Kazutaka YOKOTA wrote: > The svr4 module is broken after the following change to svr4_machdep.c > rev 1.5. > -- > revision 1.5 > date: 1999/06/01 18:20:23; author: jlemon; state: Exp; lines: +0 -4 > Unifdef VM86. > Reviewed by:silence on on -current > -- Ah, that would be a mistake: I haven't completed the VM86 stuff yet (it has been among the lower of my priorities). Sorry, I didn't see your mesage on -current asking about it. I'l back the change out, anyway. - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Finding out what function an interrupt is tied to..
I'm having some problems since when the newbus code went in, in that my sound card doesn't seem to be interrupting anymore (PAS16, Voxware drivers). So what I'd like to do is look at the kernel and see if an interrupt actually has a function associated with it, and if it's being masked out. Any ideas? Of course, this would have to happen just as I learnt to rip my music CD's into mp3s. Stephen To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
The official splash screen
Where can I find a nice splash-screen? I'd like to try getting a splash screen, but I'm not sure the image is bad, or I just have misconfigured it wrong. So I wonder if an 'official FreeBSD splash screen' exists. Or does somebody have any splash screen for download somewhere? Leif To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How can i fail buf?
>> This isn't solved. It was less serious before rev.1.196 of vfs_bio.c >> when B_ERROR buffers were discarded insead of re-dirtied in the above >> code fragment. See also PR 11697, and about 20 PRs reporting problems >> with i/o errors and EOF "errors" (ENOSPC/EINVAL) for (mis)using buffered >> devices (especially fd0). >> > >Why they have done so? B_ERROR have to mean unrecoverable >error, doesn't it? Or we need something like > >Writing to ... at ... failed. >(A)bort, (R)etry, (I)gnore? > >:-) Even that has some advantages over our current and previous handling :-(. >> I use the following variant of the patch in PR 11697: >> >> [patch skipped] >> > >Will it ever included in current? I'm waiting for the committer of vfs_bio.c rev.1.196 to fix it. >> This fixes the primary problem in all cases except the most interesting one: >> for real i/o errors. It doesn't touch the secondary problem that most >> VOP_FSYNC() routines don't try hard enough to write all dirty buffers in >> the MNT_WAIT case, so vinvalbuf() may panic. > >As i see, we need some B_FATAL flag, that will signal brelse to >do not redirty buf, for example to set when media in fd >was changed. Still not quite right. I debugged this with write protected floppies. The driver currently retries a lot and spews a message for each failure. The best handling is close to what is provided by Abort/Retry/Fail (don't do anything until the disk is changed...). >About F_SYNC: usually they do, they try very hard to free >dirty queue, look at msdosfs_vnops.c, and 'man VOP_FSYNC' >pseudocode. Pseudocode even loops infinitly if there is a >not writable buf. I overestimated the extent of this problem. It seems to be limited to ffs_fsync(), which gives up after a couple of passes. I think the fatal case is only reached for unmount(). Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
writes: > Is it that long? I honestly don't think I have ever seen one stay up for a > week. Are you sure you did not mean 48 hours? I don't speak in jest. 49.7 days until an internal millisecond counter rolls around and crashes the machine. Microsoft have a patch out, but according to their web site, it's untested. I don't know what's worse; that Microsoft themselves can't keep Windows running for 50 days, or that they're incapable of manually bumping the counter to a value close to UINT_MAX and wait a few minutes for it to roll over. 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
Re: The official splash screen
On Wed, 2 Jun 1999, Leif Neland wrote: > Where can I find a nice splash-screen? > > I'd like to try getting a splash screen, but I'm not sure the image is > bad, or I just have misconfigured it wrong. > > So I wonder if an 'official FreeBSD splash screen' exists. > > Or does somebody have any splash screen for download somewhere? In the future, questions like this should be directed to freebsd-questions, as it doesn't directly pertain to -current. The FreeBSD Advocacy site at http://advocacy.freebsd.org/ has a collection of splash screens. See http://advocacy.freebsd.org/ammunition/splash.html -- Brian Buchanan br...@csua.berkeley.edu -- FreeBSD - The Power to Serve! http://www.freebsd.org daemon(n): 1. an attendant power or spirit : GENIUS 2. the cute little mascot of the FreeBSD operating system To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FTP passive mode - a new default?
Nathan Dorfman writes: > Certain shareware lose95 FTP servers don't know how to do passive mode. No need to go looking through Windows software; the unjustly popular ncftp is equally braindead. The ncftp man page makes for very interesting (and depressing) reading; it is quite obvious that the author has never read RFC959. 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
Re: IRQ sharing with newbus
As Doug Rabson wrote ... > On Tue, 1 Jun 1999, Matthew N. Dodd wrote: > > > On Tue, 1 Jun 1999, Mark Newton wrote: > > > So, guys -- What is the officially blessed way of sharing IRQs under > > > newbus? > > > > If you find out, let me know since the EISA code suffers the same problem > > (though the drivers do a bit better job detecting the condition, and just > > fail to attach instead of panicing.) > > For EISA, it should be possible to add RF_SHAREABLE to the > bus_alloc_resource call (assuming that EISA interrupts are shareable like > pci interrupts). IRRC (it's been years) EISA cards can, but don't have to, support shared interrupts. I think the SCU/ECU can set this based on what the .CFG file of the card tells it the hardware can do. I once designed a EISA 2 channel SCSI adapter but that was > 9 years ago. Bitrot.. | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: IRQ sharing with newbus
On Wed, 2 Jun 1999, Wilko Bulte wrote: > > For EISA, it should be possible to add RF_SHAREABLE to the > > bus_alloc_resource call (assuming that EISA interrupts are shareable like > > pci interrupts). > > IRRC (it's been years) EISA cards can, but don't have to, support shared > interrupts. I think the SCU/ECU can set this based on what the .CFG > file of the card tells it the hardware can do. > > I once designed a EISA 2 channel SCSI adapter but that was > 9 years ago. > Bitrot.. The point that I continue to try to make is that the new_bus code isn't honoring the RF_SHAREABLE flag. I believe this issue to be outside of the EISA specific bits but have nothing more than idle speculation to back that up as it appears the ISA issue was caused by a different feature of the new_bus code. Most EISA devices can be set to used 'EDGE' or 'LEVEL' triggered IRQs. Most that allow this, only allow sharing with other cards of the same type. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | win...@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: IRQ sharing with newbus
< said: >> But the sio non-multiport stuff should be able to use RF_TIMESHARE. -- >> If I'm not using my serial port, I should be able to use my >> infrared > Preemptive timesharing would be hard to implement reasonably for irqs. > A uniform timeslice would have to be 86 usec to work properly for > unbuffered sio devices at 115200 bps. You're talking intervals about six orders of magnitude smaller than I am. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
FDC_YE and newbus
FDC_YE is still marked as broken with newbus. What's the timetable on getting this fixed, and is there anything I can do to help out? (I've been looking for an excuse to learn kernel internals, anyway... ;) I'd like to upgrade my Libretto to -current, but having a nonfunctional floppy drive is kind of a pain. -- Brian Buchanan br...@csua.berkeley.edu -- FreeBSD - The Power to Serve! http://www.freebsd.org daemon(n): 1. an attendant power or spirit : GENIUS 2. the cute little mascot of the FreeBSD operating system To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Finding out what function an interrupt is tied to..
On Wed, 2 Jun 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > I'm having some problems since when the newbus code went in, in that > my sound card doesn't seem to be interrupting anymore (PAS16, Voxware > drivers). So what I'd like to do is look at the kernel and see > if an interrupt actually has a function associated with it, and if > it's being masked out. Any ideas? Of course, this would have to happen > just as I learnt to rip my music CD's into mp3s. I suggest that you start by putting print statements (or using the kernel debugger) to find out what is going on in nexus_setup_intr() (i386/i386/nexus.c). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
Matthew Hunt wrote: > > On Tue, Jun 01, 1999 at 01:59:48PM -0700, David Schwartz wrote: > > > I think he was suggesting that the apps close the connection if they > > receive no data from some amount of time. (Isn't this common sense?) > > No, I frequently keep telnet/ssh connections idle for long periods, > and have no particular desire for them to close on me. They don't close on you because keepalive would succeed. It would only drop your connection after the keepalive times out when you become unreachable by IP. -- Andre Oppermann CEO / Geschaeftsfuehrer Internet Business Solutions Ltd. (AG) Hardstrasse 235, 8005 Zurich, Switzerland Fon +41 1 277 75 75 / Fax +41 1 277 75 77 http://www.pipeline.chi...@pipeline.ch To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
SMTP to dynamic ip's
> When it comes down to it, there is very little justification for a static > address. The one I most commonly hear is "so we can do SMTP mail delivery > to the customer", but even that doesn't mandate use of static addressing -- > we support SMTP mail delivery (we call it "mailbagging" for some reason) > to dynamically-addressed dial-up clients, and it works just fine. > Would you care to explain how? Very interested. Leif To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
On Wed, Jun 02, 1999 at 10:58:41PM +0200, Andre Oppermann wrote: > Matthew Hunt wrote: > > On Tue, Jun 01, 1999 at 01:59:48PM -0700, David Schwartz wrote: > > > > > I think he was suggesting that the apps close the connection if they > > > receive no data from some amount of time. (Isn't this common sense?) > > > > No, I frequently keep telnet/ssh connections idle for long periods, > > and have no particular desire for them to close on me. > > They don't close on you because keepalive would succeed. It would > only drop your connection after the keepalive times out when you become > unreachable by IP. That's how keepalives work. My understanding is that David Schwartz's comment referred to application idle timeouts, not keepalives. -- Matthew Hunt * Stay close to the Vorlon. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SMTP to dynamic ip's
On Wed, Jun 02, 1999 at 11:03:05PM +0200, Leif Neland wrote: > > When it comes down to it, there is very little justification for a static > > address. The one I most commonly hear is "so we can do SMTP mail delivery > > to the customer", but even that doesn't mandate use of static addressing -- > > we support SMTP mail delivery (we call it "mailbagging" for some reason) > > to dynamically-addressed dial-up clients, and it works just fine. > > Would you care to explain how? > > Very interested. Inbound mail to "mailbagging" customers is not queued normally by sendmail, but is delivered through a local-like mailer to a separate per-user queue directory. When users authenticate, radius uses a back-end RPC service to register users as connected from a particular IP address. This IP address is dynamically assigned. When we receive a stop record from radius (indicating that the user has disconnected) a similar RPC removes the record. Inserting this record triggers an SMTP delivery attempt after a few seconds' delay. The per-user queue directory (the "mailbag") is emptied as messages are sent to the connected user. A periodic job (every ten minutes, I think, to give people a chance to idle out their automatically-dialled connection) checks for connected mailbagging customers for whom a queue run is not in progress. For each of these users, the mailbag is delivered by SMTP to the registered, connected address. The main thing to be careful on all this is to do paranoid checking at every stage to try to ensure that the user hasn't disconnected and been replaced by someone else (who should not get their mail). Incidentally, ETRN is still accepted (some people like to do it) but it doesn't do anything. We rely on mail being delivered regularly enough for ETRN not to be necessary. Calling the RPCs is very cheap, and we have experienced no load issues with scaling this to "large" numbers of customers. Joe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SMTP to dynamic ip's
On 2 Jun 1999 17:20:38 -0400, in sentex.lists.freebsd.current you wrote: >Inbound mail to "mailbagging" customers is not queued normally by sendmail, >but is delivered through a local-like mailer to a separate per-user >queue directory. > >When users authenticate, radius uses a back-end RPC service to register >users as connected from a particular IP address. This IP address is >dynamically assigned. When we receive a stop record from radius >(indicating that the user has disconnected) a similar RPC removes >the record. Do you make checks to see that the person does not login twice with the same account name ? Also, what happens if one user who has a big queue, gets killed mid transit, than another user comes on with the same IP. Do you have a facility for stopping the queue ? ---Mike Mike Tancsa (mdtan...@sentex.net) Sentex Communications Corp, Waterloo, Ontario, Canada To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
