Re: Intel 82559 based NIC support: Where?
Steven E Lumos wrote: According to some posts I've found with deja and by searching the mailing lists, these cards are now supported in the fxp driver. Since the string "82559" does not appear either in the CVS logs, nor the latest version of the driver available for CVS, I need somebody to tell me which version of the driver has 82559 support. Specifically, is there a version that I can build in a 3.1 source tree, and if not then what is the minimum amount of work I can do to get a working system with this card supported. One of the posts I saw said that there was support in 3.2, but the GENERIC 3.2 kernel (from the June 1999 CDs) doesn't recognise the card. The card is an Intel InBusiness 10/100. Find out what the device ID is. I have an 82559 card running right now, and it ran under 3.1-RELEASE as well as it's software compatable with the 82557/8. Under -current: pciconf -l reports: fxp0@pci0:11:0: class=0x02 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 Under 3.1-release (network installed from floppy), and later upgraded to 3.2-stable: Aug 30 12:59:14 auth /kernel: FreeBSD 3.1-RELEASE #0: Mon Feb 15 11:08:08 GMT 19 99 [..] Aug 30 12:59:14 auth /kernel: fxp0: Intel EtherExpress Pro 10/100B Ethernet re v 0x08 int a irq 11 on pci0.11.0 Aug 30 12:59:14 auth /kernel: fxp0: Ethernet address 00:90:27:58:42:9f The card was an OEM version, I don't know *exactly* what it's called, and it has no identifying marks, but it's intel-style model number is: 721383-006. This is on the sticker on the front next to the ethernet address and another number "10927", which could mean anything. The Intel docs for this chip say explicitly that it's software compatable with drivers for older versions. An older board with an 82557 or 558 on the motherboard has: fxp0@pci0:6:0: class=0x02 card=0x chip=0x12298086 rev=0x01 hdr=0x00 The device ID's are the same, just a lower revision number. Thanks in advance. Steve Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
Ken, Unfortunately the AIC7890 has a 68pin HD connector for which I don't have a cable. As far as the scanner goes: I didn't expect it to have a decent SCSI implementation, this is the reason I used a separate NCR810 to connect it to my system. But I find it strange that the system panics on this configuration, if something is wrong I expected the kernel to complain but not panic (you could call a panic the ultimate way for the kernel to compain, but this was not very helpfull). I'll try to get my hands on an 25 (Centronics) - 68pin HD cable (is there someone near Delft, NL that has such a cable that I can borrow for a day or two?). Whould it help if I took my old PC and installed FreeBSD 2.2.6 (the latest 2.2R i've got) and see what happens? Rene Rene de Vries wrote... Hi, Today I bought a Umax 1220S scanner and tried to connect this to my FreeBSD Stable (3.3RC) system. I added a NCR810 specially for the scanner (I don't want such a device on the same bus as my root disk which is on an aic7890). The kernel boots perfectly with both scsi adapters configured (as expected ;-), but as soon as the scanner is connected to the NCR810 the kernel panics. The scanner is the only device on that bus and termination is ok. The message is: "cam_periph_error: scsi status of CHECK COND returned but no sense information is availible. Controller should have returned CAM_AUTOSENSE_FAILED" (line 1441 of cam_periph.c). As far as understand the comments there, this means that the ncr810 driver did something cam did not expect. (This all happens during booting, at the time when the devices are probed.) For now I've connected the scanner to my other PC running W95 where its seems to work as expected. I hope someone can help me finding what the problem is and how to fix it. It sounds like there may be a couple of things going on. First, your scanner may not be returning sense information properly. Second, the NCR driver may be doing something wrong. It would be helpful if you could hook this up to your 7890 controller and see what happens. In general, the Adaptec driver behaves a little better than the NCR driver. Ken -- Rene de Vrieshttp://www.tcja.nl/~rene; mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: K6 Write Combining FreeBSD
On Sat, 4 Sep 1999, Randall Hopper wrote: Does FreeBSD support Write Combining on K6 processors? Randall Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0. -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is\ [EMAIL PROTECTED] | indistinguishable from a feature." | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: K6 Write Combining FreeBSD
Brian F. Feldman: |Randall Hopper: | Does FreeBSD support Write Combining on K6 processors? | |Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0. Great! Thanks. Do you know what the status is on the XFree86-FreeBSD MTRR interface that was being hammered out (to coordinate write-combine setup on the frame buffer)? All I find in Dejanews is: http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=452806764 http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=502908632 Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE :-) Thanks, Randall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: K6 Write Combining FreeBSD
On Sun, 5 Sep 1999, Randall Hopper wrote: Brian F. Feldman: |Randall Hopper: | Does FreeBSD support Write Combining on K6 processors? | |Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0. Great! Thanks. Do you know what the status is on the XFree86-FreeBSD MTRR interface that was being hammered out (to coordinate write-combine setup on the frame buffer)? All I find in Dejanews is: http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=452806764 http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=502908632 Well, from 3.9.16, I get (==) NV(0): Write-combining range (0xcc00,0x100):-) Nice to know that my work ...errr works. Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE :-) Use cvsup to go to 3.3-STABLE. Thanks, Randall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is\ [EMAIL PROTECTED] | indistinguishable from a feature." | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: K6 Write Combining FreeBSD
Brian F. Feldman: |Well, from 3.9.16, I get |(==) NV(0): Write-combining range (0xcc00,0x100):-) | |Nice to know that my work ...errr works. Great! Thanks for the good piece of work. | Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE :-) | |Use cvsup to go to 3.3-STABLE. Hmmm... I've got a stable OS now, so any upgrade makes me a little nervous. But I'll read up on it. (Might be easier to wait for 3.3-R since I hear we're in kernel freeze). Thanks, Randall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Fri, 03 Sep 1999 20:34:22 -0400, John Baldwin wrote: It was the adding a new user/group just for the sake of adding a new user/group that bothered many of us. ;) I've learned to accept that argument on principle is inevitable. :-) Later, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux StarOffice51 runs on -stable
Before running soffice for the first time -- apply the trick described by Andre Albsmeier on http://www.freebsd.org/cgi/getmsg.cgi?fetch=432982+436209+/usr/local/www/db/text/1998/freebsd-hackers/19980628.freebsd-hackers to the freshly installed lib/libosl516li.so mv libosl516li.so libosl516li.so.bak sed -e 's,/proc/%u/cmdline,/compat/linux/so,' \ libosl516li.so.bak libosl516li.so touch /compat/linux/so I don't think this one is needed anymore ?!? It is. Without it, soffice keeps bringing up setup over and over instead of just starting the damn office. Well, my copy calls this file libosl517li.so, and doing this "sed" trick on it just makes it exit without doing anything. Not doing it gives me the previously noted "can't get out of setup" problem. And my .sversionrc file looked like it was fine. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: K6 Write Combining FreeBSD
Brian F. Feldman: |Randall Hopper: | Does FreeBSD support Write Combining on K6 processors? | |Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0. Great! Thanks. Do you know what the status is on the XFree86-FreeBSD MTRR interface that was being hammered out (to coordinate write-combine setup on the frame buffer)? All I find in Dejanews is: The MTRR interface in FreeBSD was developed under consultation with the XFree86 and Xi Graphics folks. I haven't heard any complaints from them lately. Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE :-) You could try to backport the two sets of commits I just made to the -stable branch, but you might be better off moving to -stable or to 3.3-RELEASE. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
As Kenneth D. Merry wrote ...
Rene de Vries wrote...
Hi,
Today I bought a Umax 1220S scanner and tried to connect this to my FreeBSD
Stable (3.3RC) system. I added a NCR810 specially for the scanner (I don't
want such a device on the same bus as my root disk which is on an aic7890).
The kernel boots perfectly with both scsi adapters configured
(as expected ;-), but as soon as the scanner is connected to the NCR810
the kernel panics.
The scanner is the only device on that bus and termination is ok.
The message is: "cam_periph_error: scsi status of CHECK COND returned but no
sense information is availible. Controller should have returned
CAM_AUTOSENSE_FAILED" (line 1441 of cam_periph.c). As far as understand the
comments there, this means that the ncr810 driver did something cam did not
expect. (This all happens during booting, at the time when the devices are
probed.)
For now I've connected the scanner to my other PC running W95 where its
seems to work as expected.
I hope someone can help me finding what the problem is and how to fix it.
It sounds like there may be a couple of things going on. First, your
scanner may not be returning sense information properly.
Second, the NCR driver may be doing something wrong.
It would be helpful if you could hook this up to your 7890 controller and
see what happens. In general, the Adaptec driver behaves a little better
than the NCR driver.
The relevant code snippet is:
} else if (ccb-csio.scsi_status ==
SCSI_STATUS_CHECK_COND
status != CAM_AUTOSENSE_FAIL) {
/* no point in decrementing the retry count
*/
panic("cam_periph_error: scsi status of "
"CHECK COND returned but no sense "
"information is availible. "
"Controller should have returned "
"CAM_AUTOSENSE_FAILED");
/* NOTREACHED */
error = EIO;
Even if we assume the scanner yelled for attention and/or the ncr
driver is at fault I don't really understand why the cam layer
decides to panic the machine. Wouldn't it be sufficient to return
EIO, or maybe just whine on the console?
IIRC I've seen systems report 'no sense' in their log files in situations
like this (non-FreeBSD systems that is). So I *guess* there are
SCSI devices out there that exhibit this behaviour..
Wilko
--
| / o / / _ Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
PCI modems do not work???
Well.. i just looked through some archives and also on the recent traffic in freebsd-questions. It seems there are great many people that have same problem i do - apparently our beloved system does not support PCI modems? Now if i am wrong here - kick me and ignore the rest of the message. If i am right - this really has to be fixed and soon. There aren't many ISA 56K modems out there that aren't winmodems. On my last search everything that was 56K was divided about 80% winmodems and 20% PCI modems (with UART). I don't think for someone with understanding of low level drivers implementing this should be too hard? After all all the difference AFAIK is in how interrupts are delivered from a device. It still has the same ports, doesn't it? If this is not fixed soon FreeBSD users won't be able to get a modem working at all... and then how the hell is this going to be a network system?: --Ugen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
Well.. i just looked through some archives and also on the recent traffic in freebsd-questions. It seems there are great many people that have same problem i do - apparently our beloved system does not support PCI modems? Now if i am wrong here - kick me and ignore the rest of the message. If i am right - this really has to be fixed and soon. There aren't many ISA 56K modems out there that aren't winmodems. On my last search everything that was 56K was divided about 80% winmodems and 20% PCI modems (with UART). I don't think for someone with understanding of low level drivers implementing this should be too hard? After all all the difference AFAIK is in how interrupts are delivered from a device. It still has the same ports, doesn't it? If this is not fixed soon FreeBSD users won't be able to get a modem working at all... and then how the hell is this going to be a network system?: --Ugen I'm actually going to look at doing this tommorow, but I have to admit the sio driver isn't really going to like doing this. Has anyone looked at this before and could possibly give any suggestions as to how I should begin this? Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Kevin Day wrote: Well.. i just looked through some archives and also on the recent traffic in freebsd-questions. It seems there are great many people that have same problem i do - apparently our beloved system does not support PCI modems? Now if i am wrong here - kick me and ignore the rest of the message. If i am right - this really has to be fixed and soon. There aren't many ISA 56K modems out there that aren't winmodems. On my last search everything that was 56K was divided about 80% winmodems and 20% PCI modems (with UART). I don't think for someone with understanding of low level drivers implementing this should be too hard? After all all the difference AFAIK is in how interrupts are delivered from a device. It still has the same ports, doesn't it? If this is not fixed soon FreeBSD users won't be able to get a modem working at all... and then how the hell is this going to be a network system?: --Ugen I'm actually going to look at doing this tommorow, but I have to admit the sio driver isn't really going to like doing this. Has anyone looked at this before and could possibly give any suggestions as to how I should begin this? Are you aware that the least part of making this work is the PCI interface question? What's needed is the entire AT command set, and sometimes all the dsp processing too. What's left on those PCI modems isn't as smart as my wind up alarm clock. The only reason interfacing isn't a Windows nightmare is because of the Bios that all the Winmodems have (there isn't any standard for this strange interface). Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message ---+--- Chuck Robey| Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, Unix and 213 Lakeside Drive Apt T-1 | carpentry. It's all in the design! Greenbelt, MD 20770| picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---+--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: K6 Write Combining FreeBSD
Mike Smith: | Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE | |You could try to backport the two sets of commits I just made to the |-stable branch, but you might be better off moving to -stable or to |3.3-RELEASE. Ok, I might try that. From Brian's message, it sounds like he's made some commits for MTRR. Would I need those as well (or are your commits the work he spoke of). Randall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Kevin Day wrote: Well.. i just looked through some archives and also on the recent traffic in freebsd-questions. It seems there are great many people that have same problem i do - apparently our beloved system does not support PCI modems? Now if i am wrong here - kick me and ignore the rest of the message. If i am right - this really has to be fixed and soon. There aren't many ISA 56K modems out there that aren't winmodems. On my last search everything that was 56K was divided about 80% winmodems and 20% PCI modems (with UART). I don't think for someone with understanding of low level drivers implementing this should be too hard? After all all the difference AFAIK is in how interrupts are delivered from a device. It still has the same ports, doesn't it? I'm actually going to look at doing this tommorow, but I have to admit the sio driver isn't really going to like doing this. Has anyone looked at this before and could possibly give any suggestions as to how I should begin this? Are you aware that the least part of making this work is the PCI interface question? What's needed is the entire AT command set, and sometimes all the dsp processing too. What's left on those PCI modems isn't as smart as my wind up alarm clock. The only reason interfacing isn't a Windows nightmare is because of the Bios that all the Winmodems have (there isn't any standard for this strange interface). No, I'm working on adding support for PCI based non-winmodems. Modems that still have a 16550 based uart interface to them, but just happen to sit on the PCI bus. I'm not at all planning on writing support for winmodems, just making sio.c understand UARTs on the PCI bus. There *are* PCI modems out there that aren't winmodems, they're just hard to find. 3Com makes one, as well as a few other companies. Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
VFS stuff agein, VOP_FSYNC and async lock notification.
I've been doing quite a bit of reasearch on NFS lately and some issues have come up: async locks, fsync, and a certain person returning from vacation. 1) async locks To avoid polling on locks by the userland rpc.lockd I'd like to be able to queue a lock on a file. This can also help database like systems. I'd like some suggestions to a notification method for the kernel to notify a process of locks it has gained. Perhaps even something that can lead to a generic async notification model. 2) VOP_FSYNC I noticed that there seems to be no method besideds mmap and msync to force a partial update on files. I have a proposal that addresses this. add an argument to the VOP_FSYNC call to take an offset and a length. add a syscall pfsync, and pfsyncv, pfsync would take a filehandle, offset and length to flush, and pfsyncv would take a an array somewhat like a iovec that specified regions to flush. pfsyncv would run through the array calling VOP_FSYNC on the regions. filesystems that don't support partial sync will default to a complete sync... or return EOPNOTSUPP? My inclination is to silently do a complete fsync. If I start on pfsync the only code at first will be to add the arguments to the VOP, I think I can manage getting partial syncs to work in UFS, and probably NFS, the rest will be the default. 3) someone on vacation I've been told by my sponsor and other committers to wait until Kirk McKusick gets back from vacation for a review of my VFS diffs... I've heard you're back. Kirk, can you please look at: http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.mp.diff (VFS_CHECKEXP on a mount point) and http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff (VFS_CHECKEXP on a vnode) The diffs add fhopen, fhstat, and fhstatfs syscalls (from NetBSD). There is also some cleanup of the VFS system by pointing all unsupported VFS calls to functions in kern/sys_generic.c that seem to handle the default cases pretty well. It also splits the VFS_FHTOVP into 2 VFS operations, VFS_FHTOVP no longer does access checks, that is done in the derived VFS_CHECKEXP, VFS_FHTOVP now does only what it stands for, filehandle to vnode pointer. Any comments/critisizm you can offer? I think I'm more in favor of the first set of diffs. I'm also signed up for your second session at FreeBSDcon, I really look forward to it. See you in October. :) thanks, -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Ugen Antsilevitch wrote: If i am right - this really has to be fixed and soon. There aren't many ISA 56K modems out there that aren't winmodems. On my last search everything that was 56K was divided about 80% winmodems and 20% PCI modems (with UART). I think if you investigate, you'll find that that 20% for PCI modems breaks down to 15% PCI winmodems and 5% "self-contained" modems. I've got a URL around here somewhere that discusses the issues. If I can find, it, I'll post it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
At 02:27 PM 9/5/99 -0500, Kevin Day wrote: I'm actually going to look at doing this tommorow, but I have to admit the sio driver isn't really going to like doing this. Has anyone looked at this before and could possibly give any suggestions as to how I should begin this? I might also point out, that other multiport comms cards are now starting to appear with PCI interface, and something even more important to me at this point, a number of ACTIVE ISDN cards have just been released (and some about to be released), that support the AT command set and basically just look like a couple of serial ports, except they have a PCI interface... I'd really like to see the sio driver code being able to support PCI devices... My 2c worth... ;-) Warren [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: K6 Write Combining FreeBSD
On Sun, 5 Sep 1999, Randall Hopper wrote: Mike Smith: | Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE | |You could try to backport the two sets of commits I just made to the |-stable branch, but you might be better off moving to -stable or to |3.3-RELEASE. Ok, I might try that. From Brian's message, it sounds like he's made some commits for MTRR. Would I need those as well (or are your commits the work he spoke of). It may be worth specifying that k6_mem.c should be disabled in RELENG_3 pending further investigation of problems with the MTRR interfeace (i.e. that it can corrupt other memory...) For now, it's unsafe. Randall -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is\ [EMAIL PROTECTED] | indistinguishable from a feature." | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Kevin Day wrote: I'm actually going to look at doing this tommorow, but I have to admit the sio driver isn't really going to like doing this. Has anyone looked at this before and could possibly give any suggestions as to how I should begin this? It looks really ugly. The real problem is the 'isa_get_foo()' calls that are used. I've got a small start of splitting out the ISA bits from the probe/attach routines but I'm really not sure what the best way to solve these issues is. (They're the same issues I'm dealing with on the if_ed driver...) -- | 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-hackers" in the body of the message
Re: Intel 82559 based NIC support: Where?
Thanks! Mine reports (after patching):
fxp0@pci0:13:0: class=0x02 card=0x10308086 chip=0x10308086 rev=0x08 hdr=0x00
I have no clue what is really the right way to do it, but here is
the tiny patch I made anyway:
*** if_fxpreg.h.origSat Sep 4 13:33:29 1999
--- if_fxpreg.h Sun Sep 5 14:30:42 1999
***
*** 29,34
--- 29,35
#define FXP_VENDORID_INTEL0x8086
#define FXP_DEVICEID_i82557 0x1229
+ #define FXP_DEVICEID_i82559 0x1030
#define FXP_PCI_MMBA 0x10
#define FXP_PCI_IOBA 0x14
*** if_fxp.c.orig Sat Sep 4 13:33:29 1999
--- if_fxp.cSun Sep 5 14:40:44 1999
***
*** 510,516
if (((device_id 0x) == FXP_VENDORID_INTEL)
((device_id 16) 0x) == FXP_DEVICEID_i82557)
return ("Intel EtherExpress Pro 10/100B Ethernet");
!
return NULL;
}
--- 510,518
if (((device_id 0x) == FXP_VENDORID_INTEL)
((device_id 16) 0x) == FXP_DEVICEID_i82557)
return ("Intel EtherExpress Pro 10/100B Ethernet");
! else if (((device_id 0x) == FXP_VENDORID_INTEL)
! ((device_id 16) 0x) == FXP_DEVICEID_i82559)
! return ("Intel InBusiness 10/100 Ethernet");
return NULL;
}
For anyone who is interested, I bought these cards at CompUSA because
they were cheap. There is a sticker on them with the net address
followed by "32913" and then "742252-001".
Steve
Peter Wemm [EMAIL PROTECTED]:
Steven E Lumos wrote:
According to some posts I've found with deja and by searching the
mailing lists, these cards are now supported in the fxp driver. Since
the string "82559" does not appear either in the CVS logs, nor the
latest version of the driver available for CVS, I need somebody to tell
me which version of the driver has 82559 support. Specifically, is
there a version that I can build in a 3.1 source tree, and if not then
what is the minimum amount of work I can do to get a working system
with this card supported.
One of the posts I saw said that there was support in 3.2, but the
GENERIC 3.2 kernel (from the June 1999 CDs) doesn't recognise the
card. The card is an Intel InBusiness 10/100.
Find out what the device ID is. I have an 82559 card running right now,
and it ran under 3.1-RELEASE as well as it's software compatable with the
82557/8.
Under -current: pciconf -l reports:
fxp0@pci0:11:0: class=0x02 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x
00
Under 3.1-release (network installed from floppy), and later upgraded to
3.2-stable:
Aug 30 12:59:14 auth /kernel: FreeBSD 3.1-RELEASE #0: Mon Feb 15 11:08:08 GMT
19
99
[..]
Aug 30 12:59:14 auth /kernel: fxp0: Intel EtherExpress Pro 10/100B Ethernet
re
v 0x08 int a irq 11 on pci0.11.0
Aug 30 12:59:14 auth /kernel: fxp0: Ethernet address 00:90:27:58:42:9f
The card was an OEM version, I don't know *exactly* what it's called, and it
has no identifying marks, but it's intel-style model number is: 721383-006.
This is on the sticker on the front next to the ethernet address and
another number "10927", which could mean anything.
The Intel docs for this chip say explicitly that it's software compatable
with drivers for older versions.
An older board with an 82557 or 558 on the motherboard has:
fxp0@pci0:6:0: class=0x02 card=0x chip=0x12298086 rev=0x01 hdr=0x
00
The device ID's are the same, just a lower revision number.
Thanks in advance.
Steve
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: placement of vi in the filesystem
Ben Rosengart wrote: I'm sure this is old ground, but could anyone please tell me why vi is in /usr/bin instead of /bin? It would be nice to be able to edit files in /etc (especially the fstab) without /usr mounted on a vanilla install. /bin/ed - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: placement of vi in the filesystem
On Sun, 5 Sep 1999, Ben Rosengart wrote: I'm sure this is old ground, but could anyone please tell me why vi is in /usr/bin instead of /bin? It would be nice to be able to edit files in /etc (especially the fstab) without /usr mounted on a vanilla install. IIRC, because vi has a lot of bagage like termcap and curses. I know it's rough, but you do have ed when in single-user mode. On the other hand I built a static nvi and put it in /tmp with a copy of termcap and set the TERMCAP variable. With only / mounted, nvi did just fine, and it only took 460592 and 188100 bytes for the static nvi and termcap respectivly. 620K isn't much to argue about these days unless you want it on a floppy. cheers, Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
In message [EMAIL PROTECTED] Kevin Day writes: : No, I'm working on adding support for PCI based non-winmodems. Modems that : still have a 16550 based uart interface to them, but just happen to sit on : the PCI bus. I'm not at all planning on writing support for winmodems, just : making sio.c understand UARTs on the PCI bus. : : There *are* PCI modems out there that aren't winmodems, they're just hard to : find. 3Com makes one, as well as a few other companies. SIO doesn't support anything but isa attachments right now. Its probe and attach routines need to be corrected to not be ISA specific. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
In message [EMAIL PROTECTED] Warren Welch writes: : I'd really like to see the sio driver code being able to support PCI : devices... Might be a good time have a sys/dev/sio and have pccard, cardbus, pci and isa attachments there. Yes, I did say cardbus, since I have seen cardbus PCI modems that are NOT winmodems. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
/etc sh script cleanup ready for testing
The long-awaited moment (well, by me anyway) has arrived. Except for the files in /etc/periodic I have finished the cleanup of the /bin/sh scripts in /etc. I've followed the style guidelines requested by the majority of -hackers, so I hope that I've made everyone as happy as possible here. You can find the files at http://gorean.org/rcfiles/ I've tested as much of this stuff as I can here, but I don't have some possible options; like an alpha, pc cards, isdn, ppp, etc. I have been extremely careful in my changes however, so I'm confident that you can employ these patches without fear of system mangling. In addition to the previous comments, here are the notes I made while working on this: 1. A few files had no $FreeBSD tag, so I added them. 2. Lots of (spurious?) double spaces in rc.serial. 3. In rc.alpha and rc.i386 some of the one-line comments can probably be deleted. 4. There are a number of gratuitous punctation diffs between etc.i386/MAKEFILE and etc.alpha/MAKEFILE. 5. rc.network.S* is Sheldon's work, my thanks to him for doing the first pass on that file. (Of course, final responsibility for any errors is mine alone.) 6. In rc and rc.network I provided the defaults for *_program variables to avoid a possible case of user foot shooting. In the case of files with heavy white space changes you might find it easier to isolate the significant changes by saving the file and doing a diff -[uc]Bb between it and the current version. At some point in the future I plan to start on the periodic scripts, if no one gets there first. However, I'd like to submit these now for testing/committing partly so that they don't get stale, and partly because if I don't take a break and start working on something else my brain is going to explode. :) All of the patches are up to date as of tonight's -Current. Any questions, comments, suggestions, or what have you are welcome of course; although I'm really hoping that too many changes are not called for since that was the purpose of asking for review ahead of time. I'll have some freebsd-hacking time tomorrow if there are any more nits to be picked. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[no subject]
subscribe freebsd-hackers@freebsd.org tr...@abraxis.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Sun StarOffice51
Kherry Zamore wrote: I installed Sun StarOffice 5.1 on my 4.0-CURRENT machine without any modifications at all.. Downloaded, set the ld library path, installed and started staroffice. I didn't modify _any_ files at all and it runs without a problem as root. I haven't tried playing with it yet so users can run it, but it makes me wonder why everyone else is having so many problems with it. Ditto, this morning. I already had the linuxulator loaded. I ran the setup from the CD, installed the app, docked it in Window Maker, and updated my resume in 30 minutes. Worked like a charm. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Intel 82559 based NIC support: Where?
According to some posts I've found with deja and by searching the mailing lists, these cards are now supported in the fxp driver. Since the string 82559 does not appear either in the CVS logs, nor the latest version of the driver available for CVS, I need somebody to tell me which version of the driver has 82559 support. Specifically, is there a version that I can build in a 3.1 source tree, and if not then what is the minimum amount of work I can do to get a working system with this card supported. One of the posts I saw said that there was support in 3.2, but the GENERIC 3.2 kernel (from the June 1999 CDs) doesn't recognise the card. The card is an Intel InBusiness 10/100. Thanks in advance. Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Intel 82559 based NIC support: Where?
Steven E Lumos wrote: According to some posts I've found with deja and by searching the mailing lists, these cards are now supported in the fxp driver. Since the string 82559 does not appear either in the CVS logs, nor the latest version of the driver available for CVS, I need somebody to tell me which version of the driver has 82559 support. Specifically, is there a version that I can build in a 3.1 source tree, and if not then what is the minimum amount of work I can do to get a working system with this card supported. One of the posts I saw said that there was support in 3.2, but the GENERIC 3.2 kernel (from the June 1999 CDs) doesn't recognise the card. The card is an Intel InBusiness 10/100. Find out what the device ID is. I have an 82559 card running right now, and it ran under 3.1-RELEASE as well as it's software compatable with the 82557/8. Under -current: pciconf -l reports: f...@pci0:11:0: class=0x02 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 Under 3.1-release (network installed from floppy), and later upgraded to 3.2-stable: Aug 30 12:59:14 auth /kernel: FreeBSD 3.1-RELEASE #0: Mon Feb 15 11:08:08 GMT 19 99 [..] Aug 30 12:59:14 auth /kernel: fxp0: Intel EtherExpress Pro 10/100B Ethernet re v 0x08 int a irq 11 on pci0.11.0 Aug 30 12:59:14 auth /kernel: fxp0: Ethernet address 00:90:27:58:42:9f The card was an OEM version, I don't know *exactly* what it's called, and it has no identifying marks, but it's intel-style model number is: 721383-006. This is on the sticker on the front next to the ethernet address and another number 10927, which could mean anything. The Intel docs for this chip say explicitly that it's software compatable with drivers for older versions. An older board with an 82557 or 558 on the motherboard has: f...@pci0:6:0: class=0x02 card=0x chip=0x12298086 rev=0x01 hdr=0x00 The device ID's are the same, just a lower revision number. Thanks in advance. Steve Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
Ken, Unfortunately the AIC7890 has a 68pin HD connector for which I don't have a cable. As far as the scanner goes: I didn't expect it to have a decent SCSI implementation, this is the reason I used a separate NCR810 to connect it to my system. But I find it strange that the system panics on this configuration, if something is wrong I expected the kernel to complain but not panic (you could call a panic the ultimate way for the kernel to compain, but this was not very helpfull). I'll try to get my hands on an 25 (Centronics) - 68pin HD cable (is there someone near Delft, NL that has such a cable that I can borrow for a day or two?). Whould it help if I took my old PC and installed FreeBSD 2.2.6 (the latest 2.2R i've got) and see what happens? Rene Rene de Vries wrote... Hi, Today I bought a Umax 1220S scanner and tried to connect this to my FreeBSD Stable (3.3RC) system. I added a NCR810 specially for the scanner (I don't want such a device on the same bus as my root disk which is on an aic7890). The kernel boots perfectly with both scsi adapters configured (as expected ;-), but as soon as the scanner is connected to the NCR810 the kernel panics. The scanner is the only device on that bus and termination is ok. The message is: cam_periph_error: scsi status of CHECK COND returned but no sense information is availible. Controller should have returned CAM_AUTOSENSE_FAILED (line 1441 of cam_periph.c). As far as understand the comments there, this means that the ncr810 driver did something cam did not expect. (This all happens during booting, at the time when the devices are probed.) For now I've connected the scanner to my other PC running W95 where its seems to work as expected. I hope someone can help me finding what the problem is and how to fix it. It sounds like there may be a couple of things going on. First, your scanner may not be returning sense information properly. Second, the NCR driver may be doing something wrong. It would be helpful if you could hook this up to your 7890 controller and see what happens. In general, the Adaptec driver behaves a little better than the NCR driver. Ken -- Rene de Vrieshttp://www.tcja.nl/~rene; mailto:r...@tcja.nl To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: K6 Write Combining FreeBSD
On Sat, 4 Sep 1999, Randall Hopper wrote: Does FreeBSD support Write Combining on K6 processors? Randall Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0. -- Brian Fundakowski Feldman / Any sufficiently advanced bug is\ gr...@freebsd.org | indistinguishable from a feature. | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: K6 Write Combining FreeBSD
Brian F. Feldman: |Randall Hopper: | Does FreeBSD support Write Combining on K6 processors? | |Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0. Great! Thanks. Do you know what the status is on the XFree86-FreeBSD MTRR interface that was being hammered out (to coordinate write-combine setup on the frame buffer)? All I find in Dejanews is: http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=452806764 http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=502908632 Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE :-) Thanks, Randall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: K6 Write Combining FreeBSD
On Sun, 5 Sep 1999, Randall Hopper wrote: Brian F. Feldman: |Randall Hopper: | Does FreeBSD support Write Combining on K6 processors? | |Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0. Great! Thanks. Do you know what the status is on the XFree86-FreeBSD MTRR interface that was being hammered out (to coordinate write-combine setup on the frame buffer)? All I find in Dejanews is: http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=452806764 http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=502908632 Well, from 3.9.16, I get (==) NV(0): Write-combining range (0xcc00,0x100) :-) Nice to know that my work ...errr works. Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE :-) Use cvsup to go to 3.3-STABLE. Thanks, Randall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- Brian Fundakowski Feldman / Any sufficiently advanced bug is\ gr...@freebsd.org | indistinguishable from a feature. | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
���α��� ���� ����Ʈ�Դϴ�.
To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: K6 Write Combining FreeBSD
Brian F. Feldman: |Well, from 3.9.16, I get |(==) NV(0): Write-combining range (0xcc00,0x100) :-) | |Nice to know that my work ...errr works. Great! Thanks for the good piece of work. | Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE :-) | |Use cvsup to go to 3.3-STABLE. Hmmm... I've got a stable OS now, so any upgrade makes me a little nervous. But I'll read up on it. (Might be easier to wait for 3.3-R since I hear we're in kernel freeze). Thanks, Randall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Fri, 03 Sep 1999 20:34:22 -0400, John Baldwin wrote: It was the adding a new user/group just for the sake of adding a new user/group that bothered many of us. ;) I've learned to accept that argument on principle is inevitable. :-) Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Linux StarOffice51 runs on -stable
Before running soffice for the first time -- apply the trick described by Andre Albsmeier on http://www.freebsd.org/cgi/getmsg.cgi?fetch=432982+436209+/usr/local/www/db/text/1998/freebsd-hackers/19980628.freebsd-hackers to the freshly installed lib/libosl516li.so mv libosl516li.so libosl516li.so.bak sed -e 's,/proc/%u/cmdline,/compat/linux/so,' \ libosl516li.so.bak libosl516li.so touch /compat/linux/so I don't think this one is needed anymore ?!? It is. Without it, soffice keeps bringing up setup over and over instead of just starting the damn office. Well, my copy calls this file libosl517li.so, and doing this sed trick on it just makes it exit without doing anything. Not doing it gives me the previously noted can't get out of setup problem. And my .sversionrc file looked like it was fine. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: K6 Write Combining FreeBSD
Brian F. Feldman: |Randall Hopper: | Does FreeBSD support Write Combining on K6 processors? | |Do you mean the MTRR support for K6-2 and above? Yes, that's in 3.3 and 4.0. Great! Thanks. Do you know what the status is on the XFree86-FreeBSD MTRR interface that was being hammered out (to coordinate write-combine setup on the frame buffer)? All I find in Dejanews is: The MTRR interface in FreeBSD was developed under consultation with the XFree86 and Xi Graphics folks. I haven't heard any complaints from them lately. Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE :-) You could try to backport the two sets of commits I just made to the -stable branch, but you might be better off moving to -stable or to 3.3-RELEASE. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
As Kenneth D. Merry wrote ...
Rene de Vries wrote...
Hi,
Today I bought a Umax 1220S scanner and tried to connect this to my FreeBSD
Stable (3.3RC) system. I added a NCR810 specially for the scanner (I don't
want such a device on the same bus as my root disk which is on an aic7890).
The kernel boots perfectly with both scsi adapters configured
(as expected ;-), but as soon as the scanner is connected to the NCR810
the kernel panics.
The scanner is the only device on that bus and termination is ok.
The message is: cam_periph_error: scsi status of CHECK COND returned but no
sense information is availible. Controller should have returned
CAM_AUTOSENSE_FAILED (line 1441 of cam_periph.c). As far as understand the
comments there, this means that the ncr810 driver did something cam did not
expect. (This all happens during booting, at the time when the devices are
probed.)
For now I've connected the scanner to my other PC running W95 where its
seems to work as expected.
I hope someone can help me finding what the problem is and how to fix it.
It sounds like there may be a couple of things going on. First, your
scanner may not be returning sense information properly.
Second, the NCR driver may be doing something wrong.
It would be helpful if you could hook this up to your 7890 controller and
see what happens. In general, the Adaptec driver behaves a little better
than the NCR driver.
The relevant code snippet is:
} else if (ccb-csio.scsi_status ==
SCSI_STATUS_CHECK_COND
status != CAM_AUTOSENSE_FAIL) {
/* no point in decrementing the retry count
*/
panic(cam_periph_error: scsi status of
CHECK COND returned but no sense
information is availible.
Controller should have returned
CAM_AUTOSENSE_FAILED);
/* NOTREACHED */
error = EIO;
Even if we assume the scanner yelled for attention and/or the ncr
driver is at fault I don't really understand why the cam layer
decides to panic the machine. Wouldn't it be sufficient to return
EIO, or maybe just whine on the console?
IIRC I've seen systems report 'no sense' in their log files in situations
like this (non-FreeBSD systems that is). So I *guess* there are
SCSI devices out there that exhibit this behaviour..
Wilko
--
| / 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-hackers in the body of the message
PCI modems do not work???
Well.. i just looked through some archives and also on the recent traffic in freebsd-questions. It seems there are great many people that have same problem i do - apparently our beloved system does not support PCI modems? Now if i am wrong here - kick me and ignore the rest of the message. If i am right - this really has to be fixed and soon. There aren't many ISA 56K modems out there that aren't winmodems. On my last search everything that was 56K was divided about 80% winmodems and 20% PCI modems (with UART). I don't think for someone with understanding of low level drivers implementing this should be too hard? After all all the difference AFAIK is in how interrupts are delivered from a device. It still has the same ports, doesn't it? If this is not fixed soon FreeBSD users won't be able to get a modem working at all... and then how the hell is this going to be a network system?: --Ugen To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
Well.. i just looked through some archives and also on the recent traffic in freebsd-questions. It seems there are great many people that have same problem i do - apparently our beloved system does not support PCI modems? Now if i am wrong here - kick me and ignore the rest of the message. If i am right - this really has to be fixed and soon. There aren't many ISA 56K modems out there that aren't winmodems. On my last search everything that was 56K was divided about 80% winmodems and 20% PCI modems (with UART). I don't think for someone with understanding of low level drivers implementing this should be too hard? After all all the difference AFAIK is in how interrupts are delivered from a device. It still has the same ports, doesn't it? If this is not fixed soon FreeBSD users won't be able to get a modem working at all... and then how the hell is this going to be a network system?: --Ugen I'm actually going to look at doing this tommorow, but I have to admit the sio driver isn't really going to like doing this. Has anyone looked at this before and could possibly give any suggestions as to how I should begin this? Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Ugen Antsilevitch wrote: Well.. i just looked through some archives and also on the recent traffic in freebsd-questions. It seems there are great many people that have same problem i do - apparently our beloved system does not support PCI modems? Now if i am wrong here - kick me and ignore the rest of the message. If i am right - this really has to be fixed and soon. There aren't many ISA 56K modems out there that aren't winmodems. On my last search everything that was 56K was divided about 80% winmodems and 20% PCI modems (with UART). I don't think for someone with understanding of low level drivers implementing this should be too hard? After all all the difference AFAIK is in how interrupts are delivered from a device. It still has the same ports, doesn't it? If this is not fixed soon FreeBSD users won't be able to get a modem working at all... and then how the hell is this going to be a network system?: If you want one, then you have to write one. No one who knows how to do that wants to support something like that. I *think* that the way that modems are going is not going to eliminate regular modems (and it's _certainly_ not done that yet). --Ugen To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message ---+--- Chuck Robey| Interests include any kind of voice or data chu...@mat.net | communications topic, C programming, Unix and 213 Lakeside Drive Apt T-1 | carpentry. It's all in the design! Greenbelt, MD 20770| picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---+--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Kevin Day wrote: Well.. i just looked through some archives and also on the recent traffic in freebsd-questions. It seems there are great many people that have same problem i do - apparently our beloved system does not support PCI modems? Now if i am wrong here - kick me and ignore the rest of the message. If i am right - this really has to be fixed and soon. There aren't many ISA 56K modems out there that aren't winmodems. On my last search everything that was 56K was divided about 80% winmodems and 20% PCI modems (with UART). I don't think for someone with understanding of low level drivers implementing this should be too hard? After all all the difference AFAIK is in how interrupts are delivered from a device. It still has the same ports, doesn't it? If this is not fixed soon FreeBSD users won't be able to get a modem working at all... and then how the hell is this going to be a network system?: --Ugen I'm actually going to look at doing this tommorow, but I have to admit the sio driver isn't really going to like doing this. Has anyone looked at this before and could possibly give any suggestions as to how I should begin this? Are you aware that the least part of making this work is the PCI interface question? What's needed is the entire AT command set, and sometimes all the dsp processing too. What's left on those PCI modems isn't as smart as my wind up alarm clock. The only reason interfacing isn't a Windows nightmare is because of the Bios that all the Winmodems have (there isn't any standard for this strange interface). Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message ---+--- Chuck Robey| Interests include any kind of voice or data chu...@mat.net | communications topic, C programming, Unix and 213 Lakeside Drive Apt T-1 | carpentry. It's all in the design! Greenbelt, MD 20770| picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---+--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: K6 Write Combining FreeBSD
Mike Smith: | Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE | |You could try to backport the two sets of commits I just made to the |-stable branch, but you might be better off moving to -stable or to |3.3-RELEASE. Ok, I might try that. From Brian's message, it sounds like he's made some commits for MTRR. Would I need those as well (or are your commits the work he spoke of). Randall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Kevin Day wrote: Well.. i just looked through some archives and also on the recent traffic in freebsd-questions. It seems there are great many people that have same problem i do - apparently our beloved system does not support PCI modems? Now if i am wrong here - kick me and ignore the rest of the message. If i am right - this really has to be fixed and soon. There aren't many ISA 56K modems out there that aren't winmodems. On my last search everything that was 56K was divided about 80% winmodems and 20% PCI modems (with UART). I don't think for someone with understanding of low level drivers implementing this should be too hard? After all all the difference AFAIK is in how interrupts are delivered from a device. It still has the same ports, doesn't it? I'm actually going to look at doing this tommorow, but I have to admit the sio driver isn't really going to like doing this. Has anyone looked at this before and could possibly give any suggestions as to how I should begin this? Are you aware that the least part of making this work is the PCI interface question? What's needed is the entire AT command set, and sometimes all the dsp processing too. What's left on those PCI modems isn't as smart as my wind up alarm clock. The only reason interfacing isn't a Windows nightmare is because of the Bios that all the Winmodems have (there isn't any standard for this strange interface). No, I'm working on adding support for PCI based non-winmodems. Modems that still have a 16550 based uart interface to them, but just happen to sit on the PCI bus. I'm not at all planning on writing support for winmodems, just making sio.c understand UARTs on the PCI bus. There *are* PCI modems out there that aren't winmodems, they're just hard to find. 3Com makes one, as well as a few other companies. Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
VFS stuff agein, VOP_FSYNC and async lock notification.
I've been doing quite a bit of reasearch on NFS lately and some issues have come up: async locks, fsync, and a certain person returning from vacation. 1) async locks To avoid polling on locks by the userland rpc.lockd I'd like to be able to queue a lock on a file. This can also help database like systems. I'd like some suggestions to a notification method for the kernel to notify a process of locks it has gained. Perhaps even something that can lead to a generic async notification model. 2) VOP_FSYNC I noticed that there seems to be no method besideds mmap and msync to force a partial update on files. I have a proposal that addresses this. add an argument to the VOP_FSYNC call to take an offset and a length. add a syscall pfsync, and pfsyncv, pfsync would take a filehandle, offset and length to flush, and pfsyncv would take a an array somewhat like a iovec that specified regions to flush. pfsyncv would run through the array calling VOP_FSYNC on the regions. filesystems that don't support partial sync will default to a complete sync... or return EOPNOTSUPP? My inclination is to silently do a complete fsync. If I start on pfsync the only code at first will be to add the arguments to the VOP, I think I can manage getting partial syncs to work in UFS, and probably NFS, the rest will be the default. 3) someone on vacation I've been told by my sponsor and other committers to wait until Kirk McKusick gets back from vacation for a review of my VFS diffs... I've heard you're back. Kirk, can you please look at: http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.mp.diff (VFS_CHECKEXP on a mount point) and http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff (VFS_CHECKEXP on a vnode) The diffs add fhopen, fhstat, and fhstatfs syscalls (from NetBSD). There is also some cleanup of the VFS system by pointing all unsupported VFS calls to functions in kern/sys_generic.c that seem to handle the default cases pretty well. It also splits the VFS_FHTOVP into 2 VFS operations, VFS_FHTOVP no longer does access checks, that is done in the derived VFS_CHECKEXP, VFS_FHTOVP now does only what it stands for, filehandle to vnode pointer. Any comments/critisizm you can offer? I think I'm more in favor of the first set of diffs. I'm also signed up for your second session at FreeBSDcon, I really look forward to it. See you in October. :) thanks, -Alfred Perlstein - [bri...@rush.net|alf...@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bri...@wintelcom.net] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Ugen Antsilevitch wrote: If i am right - this really has to be fixed and soon. There aren't many ISA 56K modems out there that aren't winmodems. On my last search everything that was 56K was divided about 80% winmodems and 20% PCI modems (with UART). I think if you investigate, you'll find that that 20% for PCI modems breaks down to 15% PCI winmodems and 5% self-contained modems. I've got a URL around here somewhere that discusses the issues. If I can find, it, I'll post it. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
Hey! Thanx a lot first of all! Anytime i CAN write something myself - i do. I can go as low as networking code or pseudodevice driver. But i am at loss when it comes to hardware (and within my scope of work etc. i doubt i will ever learn this stuff). Thats why i pleaded for help. I volonteer to be your first alpha-tester. I have this modem blaster thing. It is PCI and it has a UART. I was going to sell it and shell out lots of money for USRobotics 56K ISA real modem. BTW they call it legacy modem - i think the general direction is such that PCI will be the only kind available very soon... Well..actually i listed my modem on ebay to get rid of it , but if your code comes first - i will try to keep it. --Ugen No, I'm working on adding support for PCI based non-winmodems. Modems that still have a 16550 based uart interface to them, but just happen to sit on the PCI bus. I'm not at all planning on writing support for winmodems, just making sio.c understand UARTs on the PCI bus. There *are* PCI modems out there that aren't winmodems, they're just hard to find. 3Com makes one, as well as a few other companies. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Linux StarOffice51 runs on -stable
The different results people are having may be a result of the date of their FreeBSD. It Works Here[tm] OOTB (setup requires the LD_LIBRARY_PATH set) with the following -current of about Aug 22nd -stable of Aug 26th -stable of Sep 2nd -stable of Sep 4th It does not work here with -current of Jun 26th (the SNAP CD) The program just recalls the setup screen -stable of Aug something with SMP setup and the program both freeze with a ton of kernel messages about forking shared memory -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
At 02:27 PM 9/5/99 -0500, Kevin Day wrote: I'm actually going to look at doing this tommorow, but I have to admit the sio driver isn't really going to like doing this. Has anyone looked at this before and could possibly give any suggestions as to how I should begin this? I might also point out, that other multiport comms cards are now starting to appear with PCI interface, and something even more important to me at this point, a number of ACTIVE ISDN cards have just been released (and some about to be released), that support the AT command set and basically just look like a couple of serial ports, except they have a PCI interface... I'd really like to see the sio driver code being able to support PCI devices... My 2c worth... ;-) Warren wwe...@intraceptives.com.au To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: K6 Write Combining FreeBSD
On Sun, 5 Sep 1999, Randall Hopper wrote: Mike Smith: | Also, I wonder if you've seen/heard of an MTRR patch for 3.2-RELEASE | |You could try to backport the two sets of commits I just made to the |-stable branch, but you might be better off moving to -stable or to |3.3-RELEASE. Ok, I might try that. From Brian's message, it sounds like he's made some commits for MTRR. Would I need those as well (or are your commits the work he spoke of). It may be worth specifying that k6_mem.c should be disabled in RELENG_3 pending further investigation of problems with the MTRR interfeace (i.e. that it can corrupt other memory...) For now, it's unsafe. Randall -- Brian Fundakowski Feldman / Any sufficiently advanced bug is\ gr...@freebsd.org | indistinguishable from a feature. | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
placement of vi in the filesystem
I'm sure this is old ground, but could anyone please tell me why vi is in /usr/bin instead of /bin? It would be nice to be able to edit files in /etc (especially the fstab) without /usr mounted on a vanilla install. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Kevin Day wrote: I'm actually going to look at doing this tommorow, but I have to admit the sio driver isn't really going to like doing this. Has anyone looked at this before and could possibly give any suggestions as to how I should begin this? It looks really ugly. The real problem is the 'isa_get_foo()' calls that are used. I've got a small start of splitting out the ISA bits from the probe/attach routines but I'm really not sure what the best way to solve these issues is. (They're the same issues I'm dealing with on the if_ed driver...) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | win...@jurai.net | 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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Intel 82559 based NIC support: Where?
Thanks! Mine reports (after patching): f...@pci0:13:0: class=0x02 card=0x10308086 chip=0x10308086 rev=0x08 hdr=0x00 I have no clue what is really the right way to do it, but here is the tiny patch I made anyway: *** if_fxpreg.h.origSat Sep 4 13:33:29 1999 --- if_fxpreg.h Sun Sep 5 14:30:42 1999 *** *** 29,34 --- 29,35 #define FXP_VENDORID_INTEL0x8086 #define FXP_DEVICEID_i82557 0x1229 + #define FXP_DEVICEID_i82559 0x1030 #define FXP_PCI_MMBA 0x10 #define FXP_PCI_IOBA 0x14 *** if_fxp.c.orig Sat Sep 4 13:33:29 1999 --- if_fxp.cSun Sep 5 14:40:44 1999 *** *** 510,516 if (((device_id 0x) == FXP_VENDORID_INTEL) ((device_id 16) 0x) == FXP_DEVICEID_i82557) return (Intel EtherExpress Pro 10/100B Ethernet); ! return NULL; } --- 510,518 if (((device_id 0x) == FXP_VENDORID_INTEL) ((device_id 16) 0x) == FXP_DEVICEID_i82557) return (Intel EtherExpress Pro 10/100B Ethernet); ! else if (((device_id 0x) == FXP_VENDORID_INTEL) ! ((device_id 16) 0x) == FXP_DEVICEID_i82559) ! return (Intel InBusiness 10/100 Ethernet); return NULL; } For anyone who is interested, I bought these cards at CompUSA because they were cheap. There is a sticker on them with the net address followed by 32913 and then 742252-001. Steve Peter Wemm pe...@netplex.com.au: Steven E Lumos wrote: According to some posts I've found with deja and by searching the mailing lists, these cards are now supported in the fxp driver. Since the string 82559 does not appear either in the CVS logs, nor the latest version of the driver available for CVS, I need somebody to tell me which version of the driver has 82559 support. Specifically, is there a version that I can build in a 3.1 source tree, and if not then what is the minimum amount of work I can do to get a working system with this card supported. One of the posts I saw said that there was support in 3.2, but the GENERIC 3.2 kernel (from the June 1999 CDs) doesn't recognise the card. The card is an Intel InBusiness 10/100. Find out what the device ID is. I have an 82559 card running right now, and it ran under 3.1-RELEASE as well as it's software compatable with the 82557/8. Under -current: pciconf -l reports: f...@pci0:11:0: class=0x02 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x 00 Under 3.1-release (network installed from floppy), and later upgraded to 3.2-stable: Aug 30 12:59:14 auth /kernel: FreeBSD 3.1-RELEASE #0: Mon Feb 15 11:08:08 GMT 19 99 [..] Aug 30 12:59:14 auth /kernel: fxp0: Intel EtherExpress Pro 10/100B Ethernet re v 0x08 int a irq 11 on pci0.11.0 Aug 30 12:59:14 auth /kernel: fxp0: Ethernet address 00:90:27:58:42:9f The card was an OEM version, I don't know *exactly* what it's called, and it has no identifying marks, but it's intel-style model number is: 721383-006. This is on the sticker on the front next to the ethernet address and another number 10927, which could mean anything. The Intel docs for this chip say explicitly that it's software compatable with drivers for older versions. An older board with an 82557 or 558 on the motherboard has: f...@pci0:6:0: class=0x02 card=0x chip=0x12298086 rev=0x01 hdr=0x 00 The device ID's are the same, just a lower revision number. Thanks in advance. Steve Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: placement of vi in the filesystem
Ben Rosengart wrote: I'm sure this is old ground, but could anyone please tell me why vi is in /usr/bin instead of /bin? It would be nice to be able to edit files in /etc (especially the fstab) without /usr mounted on a vanilla install. /bin/ed - 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-hackers in the body of the message
Re: placement of vi in the filesystem
On Sun, 5 Sep 1999, Ben Rosengart wrote: I'm sure this is old ground, but could anyone please tell me why vi is in /usr/bin instead of /bin? It would be nice to be able to edit files in /etc (especially the fstab) without /usr mounted on a vanilla install. IIRC, because vi has a lot of bagage like termcap and curses. I know it's rough, but you do have ed when in single-user mode. On the other hand I built a static nvi and put it in /tmp with a copy of termcap and set the TERMCAP variable. With only / mounted, nvi did just fine, and it only took 460592 and 188100 bytes for the static nvi and termcap respectivly. 620K isn't much to argue about these days unless you want it on a floppy. cheers, Adrian -- [ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
In message 199909051942.oaa42...@celery.dragondata.com Kevin Day writes: : No, I'm working on adding support for PCI based non-winmodems. Modems that : still have a 16550 based uart interface to them, but just happen to sit on : the PCI bus. I'm not at all planning on writing support for winmodems, just : making sio.c understand UARTs on the PCI bus. : : There *are* PCI modems out there that aren't winmodems, they're just hard to : find. 3Com makes one, as well as a few other companies. SIO doesn't support anything but isa attachments right now. Its probe and attach routines need to be corrected to not be ISA specific. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
In message 4.2.0.58.19990906100437.04bf3...@arthur.intraceptives.com.au Warren Welch writes: : I'd really like to see the sio driver code being able to support PCI : devices... Might be a good time have a sys/dev/sio and have pccard, cardbus, pci and isa attachments there. Yes, I did say cardbus, since I have seen cardbus PCI modems that are NOT winmodems. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
mbuf shortage situations
This post is somewhat in relation to the local DoS thread started on --security a few days ago. To slightly put things back into context: The panic() signaling out of mbuf clusters is a result of the initial MGET failing, calling m_retry, and failing again. Since we seem to be okay with waiting (e.g.: M_WAIT), and we fail in getting an mbuf cluster, m_retry panic()s. As far as what I've understood from glancing at some OpenBSD and NetBSD code, I'm pretty sure that they both handle this situation the same way we handle it if the m_retry is called with M_DONTWAIT, which is to return null to MGET, which would consequently set the mbuf structure pointer (in this case, struct mbuf *m) to null. This would probably result in packet loss. The only reason that I see for which we would actually panic() in this situation (as opposed to suffer the packet loss) is if we get to the point where we're losing packets because some script kid starts up something that will eat up sockbuf space and continuously fork, then we would lose all remote access to the machine in question (since all packets would be dropped) and we wouldn't really mind a panic() for obvious practical reasons. In any case, I, personally, would prefer to suffer packet loss as opposed to a panic (especially now that Brian is in the process of writing diffs that will allow us to limit socket buffer space per UID through login.conf!) Having MGET store that null (e.g. fail as opposed to panic) on a M_WAIT seems fairly easy to fix, and would probably require some patching that would ensure that the packet loss is handeled relatively 'cleanly' (probably some debugging), but I wouldn't mind doing this. However, I'd like to know if there are objections to doing this or, in fact, if there are any suggestions on how to handle mbuf shortage situations (aside from just limiting -- although limiting is in itself a good solution and I'm glad that Brian F. is working on that). Cheers, Bosko. /* * Bosko Milekic bmile...@dsuper.net http://www.dsuper.net/~bmilekic/ * A method of solution is perfect if we can foresee from the start, and * even prove, that by following that method we shall obtain our aim. */ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
FreeBSD install questions
Hi, I have a few questions on FreeBSD installation; I hope you would help me to answer them. 1. How to change the labels and modify the FreeBSD Booteasy. I.e., From: F1 ?? F2 DOS F3 DOS F4 FreeBSD F5 Disk1 toF1 WinNT 4.0 F2 (delete, not in used empty partition) F3 Win98 F4 FreeBSD 3.2 F5 Solaris 2.7 2. How to install the Solaris Boot Record so I can use Booteasy to boot from, Right now, when I push F5 from Booteasy, it gives error message: Boot Record not found. 3. How to set up my computer to make a dial in to my ISP. Please provide me the steps or example to do the setup. My ISP is worldnet.att.net using: User ID/account no. is 740136...@worldnet.att.net Password is abcdefghijk12 Phone for ISP is (415) 276-0107 Pop3 in coming mail is postoffice.worldnet.att.net Pop3 out going mail is mailhost.wordnet.att.net Mail account ID is SysX Email password is 122345678mm Email address is s...@worldnet.att.net My modem is in COM2 I have tried several combonations of setup but it doesnt work, I would like to FTP the FreeBSD update from my computer. Thank you very much for your kind reply. Sincerely, Robert Kuan s...@worldnet.att.net rk...@visa.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf shortage situations
: The only reason that I see for which we would actually panic() in :this situation (as opposed to suffer the packet loss) is if we get to the :point where we're losing packets because some script kid starts up :something that will eat up sockbuf space and continuously fork, then we :would lose all remote access to the machine in question (since all packets :would be dropped) and we wouldn't really mind a panic() for obvious :practical reasons. : In any case, I, personally, would prefer to suffer packet loss as :opposed to a panic (especially now that Brian is in the process of writing :diffs that will allow us to limit socket buffer space per UID through :login.conf!) : Having MGET store that null (e.g. fail as opposed to panic) on a :M_WAIT seems fairly easy to fix, and would probably require some patching :that would ensure that the packet loss is handeled relatively 'cleanly' :(probably some debugging), but I wouldn't mind doing this. However, I'd :like to know if there are objections to doing this or, in fact, if there :are any suggestions on how to handle mbuf shortage situations (aside from :just limiting -- although limiting is in itself a good solution and I'm :glad that Brian F. is working on that). : :Cheers, :Bosko. The issue is basically having someone find the time to figure out how to gracefully unwind various pieces of network code when an mbuf cannot be allocated. Once that is done, the panic can be turned into a (rate-limited) printf. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Init(8) cannot decrease securelevel
Once securelevel has been increased, no process can decrease it because kernel always refuse decreasing it. This is inconsistent with the manual page of init: The kernel runs with four different levels of security. Any super-user process can raise the security level, but only init can lower it. Is there any security problem to implement this? If no, could someone review following patch? kato -- BEGIN -- *** kern_mib.c.ORIG Mon Sep 6 13:46:40 1999 --- kern_mib.c Mon Sep 6 13:49:44 1999 *** *** 178,184 error = sysctl_handle_int(oidp, level, 0, req); if (error || !req-newptr) return (error); ! if (level securelevel) return (EPERM); securelevel = level; return (error); --- 178,184 error = sysctl_handle_int(oidp, level, 0, req); if (error || !req-newptr) return (error); ! if (level securelevel req-p-p_pid != 1) return (EPERM); securelevel = level; return (error); -- END -- ---+--+ KATO Takenori k...@ganko.eps.nagoya-u.ac.jp |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | FreeBSD(98) 3.2: Rev. 01 available! |http://www.jp.FreeBSD.org/| FreeBSD(98) 2.2.8: Rev. 02 available! +==+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCI modems do not work???
On Sun, Sep 05, 1999 at 09:00:00PM -0600, Warner Losh wrote: In message 4.2.0.58.19990906100437.04bf3...@arthur.intraceptives.com.au Warren Welch writes: Might be a good time have a sys/dev/sio and have pccard, cardbus, pci and isa attachments there. Yes, I did say cardbus, since I have seen cardbus PCI modems that are NOT winmodems. And USB? This reference says that you can (now? soon?) buy a laptop docking station with all of the usual ports, connected only by USB... http://www.infoworld.com/cgi-bin/displayStory.pl?99093.piusb.htm Hmm. What sort of level of nesting do we support for this sort of thing? It's probably possible to buy USB interface cards that plug into ISA, PCI, SCSI? And vice-versa? -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
Once securelevel has been increased, no process can decrease it because kernel always refuse decreasing it. This is inconsistent with the manual page of init: The kernel runs with four different levels of security. Any super-user process can raise the security level, but only init can lower it. Is there any security problem to implement this? If no, could someone review following patch? The patch just backs out rev.1.9: RCS file: /home/ncvs/src/sys/kern/kern_mib.c,v Working file: kern_mib.c head: 1.25 ... revision 1.9 date: 1997/06/25 07:31:47; author: joerg; state: Exp; lines: +2 -2 Don't ever allow lowering the securelevel at all. Allowing it does nothing good except of opening a can of (potential or real) security holes. People maintaining a machine with higher security requirements need to be on the console anyway, so there's no point in not forcing them to reboot before starting maintenance. Agreed by: hackers, guido There used to be security holes that allowed root to lower `securelevel' using init. Rev.1.9 defends against any undiscovered holes. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
Rene de Vries wrote...
It sounds like there may be a couple of things going on. First, your
scanner may not be returning sense information properly.
Second, the NCR driver may be doing something wrong.
It would be helpful if you could hook this up to your 7890 controller and
see what happens. In general, the Adaptec driver behaves a little better
than the NCR driver.
Unfortunately the AIC7890 has a 68pin HD connector for which I don't have a
cable. As far as the scanner goes: I didn't expect it to have a decent SCSI
implementation, this is the reason I used a separate NCR810 to connect it to
my system. But I find it strange that the system panics on this
configuration, if something is wrong I expected the kernel to complain but
not panic (you could call a panic the ultimate way for the kernel to compain,
but this was not very helpfull). I'll try to get my hands on an
25 (Centronics) - 68pin HD cable (is there someone near Delft, NL that
has such a cable that I can borrow for a day or two?).
Whould it help if I took my old PC and installed FreeBSD 2.2.6 (the latest
2.2R i've got) and see what happens?
I'm not sure installing 2.2.6 would be that helpful, since it probably
won't exhibit the same behavior.
Here are some things to try:
- if you can, put the scanner on your 7890
- turn the panic statement into a printf
If you turn it into a printf, that may give us a better idea of just what
command is failing. The attached patch for cam_periph.c should do the
trick. The patch is against -current, but I think it should apply to
-stable okay.
I haven't checked to make sure it compiles or works, so you may have to
tweak it if it doesn't.
Ken
--
Kenneth Merry
k...@kdm.org
//depot/cam/sys/cam/cam_periph.c#74 -
/a/ken/perforce/cam/sys/cam/cam_periph.c
*** /tmp/tmp.25426.0Sun Sep 5 23:10:36 1999
--- /a/ken/perforce/cam/sys/cam/cam_periph.cSun Sep 5 23:10:02 1999
***
*** 1434,1445
SCSI_STATUS_CHECK_COND
status != CAM_AUTOSENSE_FAIL) {
/* no point in decrementing the retry count */
! panic(cam_periph_error: scsi status of
CHECK COND returned but no sense
! information is availible.
! Controller should have returned
! CAM_AUTOSENSE_FAILED);
! /* NOTREACHED */
error = EIO;
} else if (ccb-ccb_h.retry_count 0) {
/*
--- 1434,1448
SCSI_STATUS_CHECK_COND
status != CAM_AUTOSENSE_FAIL) {
/* no point in decrementing the retry count */
! printf(cam_periph_error: scsi status of
CHECK COND returned but no sense
! information is availible.\n
! cam_periph_error: Controller should
! have returned CAM_AUTOSENSE_FAILED\n);
!
! retry = ccb-ccb_h.retry_count 0;
! if (retry)
! ccb-ccb_h.retry_count--;
error = EIO;
} else if (ccb-ccb_h.retry_count 0) {
/*
Re: PCI modems do not work???
[[ questions trimmed ]] In message 19990906151211.a21...@gurney.reilly.home Andrew Reilly writes: : And USB? This reference says that you can (now? soon?) buy a : laptop docking station with all of the usual ports, connected : only by USB... : : http://www.infoworld.com/cgi-bin/displayStory.pl?99093.piusb.htm : : Hmm. What sort of level of nesting do we support for this sort : of thing? It's probably possible to buy USB interface cards : that plug into ISA, PCI, SCSI? And vice-versa? USB doesn't present a 16550A interface to the host, so I don't think that sio would have a USB attachment. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FBSD3.3RC + UMAX astra 1220S + NCR810 = panic
Wilko Bulte wrote...
As Kenneth D. Merry wrote ...
It sounds like there may be a couple of things going on. First, your
scanner may not be returning sense information properly.
Second, the NCR driver may be doing something wrong.
It would be helpful if you could hook this up to your 7890 controller and
see what happens. In general, the Adaptec driver behaves a little better
than the NCR driver.
The relevant code snippet is:
} else if (ccb-csio.scsi_status ==
SCSI_STATUS_CHECK_COND
status != CAM_AUTOSENSE_FAIL) {
/* no point in decrementing the retry count
*/
panic(cam_periph_error: scsi status of
CHECK COND returned but no sense
information is availible.
Controller should have returned
CAM_AUTOSENSE_FAILED);
/* NOTREACHED */
error = EIO;
Even if we assume the scanner yelled for attention and/or the ncr
driver is at fault I don't really understand why the cam layer
decides to panic the machine. Wouldn't it be sufficient to return
EIO, or maybe just whine on the console?
Well, perhaps. My guess is that the intent was to catch problems with
incorrectly written device drivers. It looks like it may have caught a
problem in the NCR driver somewhere. I can't remember the rationale behind
having a panic instead of a printf at the moment.
IIRC I've seen systems report 'no sense' in their log files in situations
like this (non-FreeBSD systems that is). So I *guess* there are
SCSI devices out there that exhibit this behaviour..
Apparantly so. I sent Rene a patch to turn the panic into a printf. The
idea is that the error will get propagated back up, and we may be able to
get a better idea of just what is failing.
Ken
--
Kenneth Merry
k...@kdm.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
Bruce Evans b...@zeta.org.au wrote: There used to be security holes that allowed root to lower `securelevel' using init. Rev.1.9 defends against any undiscovered holes. How about following change? -- *** init.8.ORIG Mon Sep 6 14:20:46 1999 --- init.8 Mon Sep 6 14:23:01 1999 *** *** 92,99 .Dq secure . .Pp The kernel runs with four different levels of security. ! Any super-user process can raise the security level, but only ! .Nm can lower it. The security levels are: .Bl -tag -width flag --- 92,98 .Dq secure . .Pp The kernel runs with four different levels of security. ! Any super-user process can raise the security level, but no process can lower it. The security levels are: .Bl -tag -width flag -- ---+--+ KATO Takenori k...@ganko.eps.nagoya-u.ac.jp |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | FreeBSD(98) 3.2: Rev. 01 available! |http://www.jp.FreeBSD.org/| FreeBSD(98) 2.2.8: Rev. 02 available! +==+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
There used to be security holes that allowed root to lower `securelevel' using init. Rev.1.9 defends against any undiscovered holes. How about following change? OK. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Limit of bus hierarchies (was Re: PCI modems do not work???)
On Mon, 06 Sep 1999, Warner Losh wrote: : http://www.infoworld.com/cgi-bin/displayStory.pl?99093.piusb.htm : : Hmm. What sort of level of nesting do we support for this sort : of thing? It's probably possible to buy USB interface cards : that plug into ISA, PCI, SCSI? And vice-versa? USB doesn't present a 16550A interface to the host, so I don't think that sio would have a USB attachment. So there's going to be manufacturer-specific terminal/serial port drivers to talk to the serial ports on USB-attached laptop docking stations, like the Annex ethernet terminal server things? I guess in the Windows world they must provide 16550-virtualisation software, or else everyone's copy of Telix or TeraTerm won't work. Or the parallel ports vs parallel-port scanners. Or maybe these docking stations just won't work at all... -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Limit of bus hierarchies (was Re: PCI modems do not work???)
USB doesn't present a 16550A interface to the host, so I don't think that sio would have a USB attachment. So there's going to be manufacturer-specific terminal/serial port drivers to talk to the serial ports on USB-attached laptop docking stations, like the Annex ethernet terminal server things? Presuming we are able to get any documentation out of any of these vendors; so far USB serial ports have been one of the worst things to enquire about. I guess in the Windows world they must provide 16550-virtualisation software, or else everyone's copy of Telix or TeraTerm won't work. Or the parallel ports vs parallel-port scanners. Or maybe these docking stations just won't work at all... Anything running under Windows uses the Windows COM driver or a replacement. If it's running in a DOS box, then it uses the 16550 virtualisation services that Windows offers, which layers over the COM driver or workalike. Basically, the same way that OS/2 does it. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Limit of bus hierarchies (was Re: PCI modems do not work???)
In message 9909061532290g.69...@gurney.reilly.home Andrew Reilly writes: : So there's going to be manufacturer-specific terminal/serial port drivers : to talk to the serial ports on USB-attached laptop docking stations, like : the Annex ethernet terminal server things? I guess in the Windows world : they must provide 16550-virtualisation software, or else everyone's copy of : Telix or TeraTerm won't work. Or the parallel ports vs parallel-port : scanners. Or maybe these docking stations just won't work at all... No. The Windows world presents a standard SERIAL DRIVER interface, at least that's the theory that is preached. I see no reason why a USB serial port wouldn't do the same. USB defines a serial port interface, IIRC, which is the same across manufacturers (in theory) which would be handled by a single USB driver in our USB stack. Likewise with parallel ports. Although turning a USB parallel port into a bit twiddling interface may present some interesting challanges. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Problems with FIFO open in non-blocking mode?
Hello!
The following program
#include stdio.h
#include fcntl.h
main() {
int control;
if ((control = open(STATUS,O_WRONLY|O_NONBLOCK))0) {
perror(Could not open STATUS );
exit(1);
}
printf(STATUS ready\n);
close(control);
return(0);
}
fails to run (STATUS is pre-created FIFO file) with error Device not
configured, which seems kinda odd for me.
However, when FIFO is opened with O_RDWR and O_NONBLOCK, every attempt
to select(2) its handler for writing doesn't wait until someone opens
FIFO for reading, but instead FIFO is ready to write at every select.
Is it a bug or a feature?
--
Alexander B. Povolotsky[ICQ 18277558]
[2:5020/145] [http://freebsd.svib.ru] [tark...@asteroid.svib.ru]
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
