Patch review [was: Re: viapropm doesnt like sys/dev/pci.c rev 1.214]
On Thu, Jun 05, 2003 at 04:17:38AM -0700, Terry Lambert wrote:
> How about RF_DONTCHECK or RF_ALWAYSWORKS? It better implies
> what's happening here, since you're going to assume success in
> the face of diagnostics to the contrary.
>
> So instead of:
>
> if (flag)
> return (0);
> command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
> if (command & bit)
> return (0);
> device_printf(child, "failed to enable %s mapping!\n", error);
> return (ENXIO);
>
> You do:
>
> command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
> if ((command & bit) || flag)
> return (0);
> device_printf(child, "failed to enable %s mapping!\n", error);
> return (ENXIO);
>
> Yeah, I know the disctinction is subtle, but there migh be other
> PCI_READ_CONFIG() results later that people care about, besides
> just this one bit, which *do* work on some other chip with the
> same issue.
Sounds good like that? (ignore more changes in amdpm.c. Just consider
that RF_DONTCHECK was added to the resource allocation). Note that
AMD-768 PM has the same flaw as the VIA chipset.
Index: dev/cardbus/cardbus_cis.c
===
RCS file: /home/ncvs/src/sys/dev/cardbus/cardbus_cis.c,v
retrieving revision 1.37
diff -u -r1.37 cardbus_cis.c
--- dev/cardbus/cardbus_cis.c 24 May 2003 23:23:41 - 1.37
+++ dev/cardbus/cardbus_cis.c 15 Jun 2003 16:05:16 -
@@ -457,7 +457,7 @@
* Mark the appropriate bit in the PCI command register so that
* device drivers will know which type of BARs can be used.
*/
- pci_enable_io(child, type);
+ pci_enable_io(child, type, 0);
return (0);
}
@@ -624,7 +624,7 @@
rman_get_start(res) | ((*rid == CARDBUS_ROM_REG)?
CARDBUS_ROM_ENABLE : 0),
4);
- PCI_ENABLE_IO(cbdev, child, SYS_RES_MEMORY);
+ PCI_ENABLE_IO(cbdev, child, SYS_RES_MEMORY, 0);
/* Flip to the right ROM image if CIS is in ROM */
if (CARDBUS_CIS_SPACE(*start) == CARDBUS_CIS_ASI_ROM) {
Index: dev/hifn/hifn7751.c
===
RCS file: /home/ncvs/src/sys/dev/hifn/hifn7751.c,v
retrieving revision 1.13
diff -u -r1.13 hifn7751.c
--- dev/hifn/hifn7751.c 11 Mar 2003 22:47:06 - 1.13
+++ dev/hifn/hifn7751.c 15 Jun 2003 16:03:43 -
@@ -616,7 +616,7 @@
/* reenable busmastering */
pci_enable_busmaster(dev);
- pci_enable_io(dev, HIFN_RES);
+ pci_enable_io(dev, HIFN_RES, 0);
/* reinitialize interface if necessary */
if (ifp->if_flags & IFF_UP)
Index: dev/pci/pci.c
===
RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.214
diff -u -r1.214 pci.c
--- dev/pci/pci.c 16 Apr 2003 03:15:08 - 1.214
+++ dev/pci/pci.c 15 Jun 2003 15:25:57 -
@@ -583,7 +583,7 @@
}
int
-pci_enable_io_method(device_t dev, device_t child, int space)
+pci_enable_io_method(device_t dev, device_t child, int space, u_int flags)
{
u_int16_t command;
u_int16_t bit;
@@ -607,7 +607,7 @@
}
pci_set_command_bit(dev, child, bit);
command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
- if (command & bit)
+ if ((command & bit) || (flags & RF_DONTCHECK))
return (0);
device_printf(child, "failed to enable %s mapping!\n", error);
return (ENXIO);
@@ -1365,7 +1365,7 @@
* Enable the I/O mode. We should also be allocating
* resources too. XXX
*/
- if (PCI_ENABLE_IO(dev, child, type))
+ if (PCI_ENABLE_IO(dev, child, type, flags))
return (NULL);
break;
}
Index: dev/pci/pci_if.m
===
RCS file: /home/ncvs/src/sys/dev/pci/pci_if.m,v
retrieving revision 1.5
diff -u -r1.5 pci_if.m
--- dev/pci/pci_if.m16 Apr 2003 03:15:08 - 1.5
+++ dev/pci/pci_if.m15 Jun 2003 15:23:23 -
@@ -70,6 +70,7 @@
device_tdev;
device_tchild;
int space;
+ u_int flags;
};
METHOD int disable_io {
Index: dev/pci/pci_private.h
===
RCS file: /home/ncvs/src/sys/dev/pci/pci_private.h,v
retrieving revision 1.8
diff -u -r1.8 pci_private.h
--- dev/pci/pci_private.h 16 Apr 2003 03:15:08 - 1.8
+++ dev/pci/pci_private.h 15 Jun 2003 15:27:55 -
@@ -56,7 +56,8 @@
int reg, u_int32_t val, int width);
intpci_enable_busmaster_method(device_t dev, device_t child);
intpci_disable_busmaster_method(device_t dev, device_t child);
Re: viapropm doesnt like sys/dev/pci.c rev 1.214
On Tue, Jun 03, 2003 at 10:54:30AM -0700, David P. Reese Jr. wrote: [...] > : The datasheet states that the command bits are RW but "fixed at 0". > > A snip of code from sys/dev/pci/pci.c:pci_enable_io_method(): > > pci_set_command_bit(dev, child, bit); > command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); > if (command & bit) > return (0); > device_printf(child, "failed to enable %s mapping!\n", error); > return (ENXIO); > > Because the viapropm's command register bits will always read as zero, > this code will always fail when trying to enable port mapping. > > Whatever problems viapropm may have, it is the new pci code that prevents it > from attaching. It is not the fault of anything in sys/pci/viapm.c. And I personally don't know how to fix it except by an option with an ifdef to workaround it. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: viapropm doesnt like sys/dev/pci.c rev 1.214
On Sun, Jun 01, 2003 at 01:52:57AM +0200, Dag-Erling Smorgrav wrote:
> "David P. Reese Jr." <[EMAIL PROTECTED]> writes:
> > In rev 1.214 of sys/dev/pci/pci.c, we have started checking if a
> > pci_set_command_bit() was successful with a subsequent PCI_READ_CONFIG
> > and comparing the results. For some odd reason, this doesnt work when
> > my viapropm tries to attach.
>
> viapropm is seriously broken for other reasons and needs professional
> help.
What kind of breakage? Setting resources in probe? Right. Anybody having
the viapm driver loaded usually should please try the attached patch.
> > pci_set_command_bit(dev, child, bit);
> > command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
> > if (command & bit)
> > return (0);
>
> It should allow the register to "settle" between write and read, which
> may take some time (see chipset docs for timing details). DELAY(1000)
> should be OK in an attach function.
The datasheet states that the command bits are RW but "fixed at 0".
Nicholas
--
Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED]
Index: viapm.c
===
RCS file: /home/ncvs/src/sys/pci/viapm.c,v
retrieving revision 1.2
diff -u -r1.2 viapm.c
--- viapm.c 9 Nov 2002 20:13:16 - 1.2
+++ viapm.c 25 May 2003 22:00:03 -
@@ -79,7 +79,6 @@
#define VIAPM_TYP_8233 5
struct viapm_softc {
- int type;
u_int32_t base;
bus_space_tag_t st;
bus_space_handle_t sh;
@@ -179,137 +178,42 @@
static int
viapm_586b_probe(device_t dev)
{
- struct viapm_softc *viapm = (struct viapm_softc *)device_get_softc(dev);
- u_int32_t l;
- u_int16_t s;
- u_int8_t c;
+ if (pci_get_devid(dev) != VIA_586B_PMU_ID)
+ return ENXIO;
- switch (pci_get_devid(dev)) {
- case VIA_586B_PMU_ID:
-
- bzero(viapm, sizeof(struct viapm_softc));
-
- l = pci_read_config(dev, VIAPM_586B_REVID, 1);
- switch (l) {
- case VIAPM_586B_OEM_REV_E:
- viapm->type = VIAPM_TYP_586B_3040E;
- viapm->iorid = VIAPM_586B_3040E_BASE;
-
- /* Activate IO block access */
- s = pci_read_config(dev, VIAPM_586B_3040E_ACTIV, 2);
- pci_write_config(dev, VIAPM_586B_3040E_ACTIV, s | 0x1, 2);
- break;
-
- case VIAPM_586B_OEM_REV_F:
- case VIAPM_586B_PROD_REV_A:
- default:
- viapm->type = VIAPM_TYP_586B_3040F;
- viapm->iorid = VIAPM_586B_3040F_BASE;
-
- /* Activate IO block access */
- c = pci_read_config(dev, VIAPM_586B_3040F_ACTIV, 1);
- pci_write_config(dev, VIAPM_586B_3040F_ACTIV, c | 0x80, 1);
- break;
- }
-
- viapm->base = pci_read_config(dev, viapm->iorid, 4) &
- VIAPM_586B_BA_MASK;
-
- /*
-* We have to set the I/O resources by hand because it is
-* described outside the viapmope of the traditional maps
-*/
- if (bus_set_resource(dev, SYS_RES_IOPORT, viapm->iorid,
- viapm->base, 256)) {
- device_printf(dev, "could not set bus resource\n");
- return ENXIO;
- }
- device_set_desc(dev, "VIA VT82C586B Power Management Unit");
- return 0;
-
- default:
- break;
- }
-
- return ENXIO;
+ device_set_desc(dev, "VIA VT82C586B Power Management Unit");
+ return 0;
}
-
static int
viapm_pro_probe(device_t dev)
{
- struct viapm_softc *viapm = (struct viapm_softc *)device_get_softc(dev);
-#ifdef VIAPM_BASE_ADDR
- u_int32_t l;
-#endif
- u_int32_t base_cfgreg;
char *desc;
switch (pci_get_devid(dev)) {
case VIA_596A_PMU_ID:
desc = "VIA VT82C596A Power Management Unit";
- viapm->type = VIAPM_TYP_596B;
- base_cfgreg = VIAPM_PRO_BASE;
- goto viapro;
+ break;
case VIA_596B_PMU_ID:
desc = "VIA VT82C596B Power Management Unit";
- viapm->type = VIAPM_TYP_596B;
- base_cfgreg = VIAPM_PRO_BASE;
- goto viapro;
+ break;
case VIA_686A_PMU_ID:
desc = "VIA VT82C686A Power Management Unit";
- viapm->type = VIAPM_TYP_686A;
- base_cfgreg = VIAPM_PRO_BASE;
- goto viapro;
+ break;
case VIA_8233_PMU_ID:
desc = "VIA VT8233 Power Management Unit";
- viapm->type = VIAPM_TYP_UNKNOWN;
- base_
Re: Polled mode with device.hints
On Sun, Nov 24, 2002 at 01:08:51PM +0100, Marc Fonvieille wrote: > Hello, > > I'm currently updating some part of the Handbook for 5.X, and I need > to know how to put some ports like sio0 or ppc0 in polled mode. > > I did a search and tried some syntax like "0" for the irq etc. but no > way to put something in polled mode or to find an info on it. > > It's a "lack" of device.hints(5) and some devices manual pages :) If you set bit 5 of ppc(4) 'flags' lpt will do polling. But lptcontrol won't change it anymore. Nicholas -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lpt ppbus ppi modules
On Sun, Oct 06, 2002 at 03:05:10PM +0100, n0g0013 wrote: > trying to build the current kernel as modular as possible but if i > remove the 'ppbus' and 'lpt' from the kernel config the modules fail > (the 'ppc' is still there of course). > > should these build as KLMs ? Yes. What's exactly the problem? How the modules fail? Nicholas -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current as guest of VMWare2
Hi folks, I'm currently trying to install -current as a guest OS of VMWare2 running under 4.6RC. The problem is that it works correctly except that after some processing, the VMWare2 engine slows down the OS incredibly. To get things back to a correct speed I have to suspend the VMWare session then restore it. I also have a VMWare2 guest 4.6RC (running on the same 4.6RC host) which works like a charm. I've compiled with the following machine file: Any idea? Nicholas # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.343 2002/05/22 19:00:48 obrien Exp $ machine i386 cpu I486_CPU cpu I586_CPU ident RATZ maxusers0 #To statically compile in device wiring instead of /boot/device.hints hints "RATZ.hints"#Default places to look for devices. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFS_ROOT#NFS usable as root device, requires NFSCLIENT options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev # Debugging for use in -current options DDB #Enable the kernel debugger options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #optionsWITNESS #Enable checks to detect deadlocks and cycles #optionsWITNESS_SKIPSPIN#Don't run witness on spinlocks for speed options ALT_BREAK_TO_DEBUGGER device isa device pci #optionsPCI_ENABLE_IO_MODES # Enable pci resources left off by a "lazy BIOS" # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc 1 # At keyboard controller device atkbd # at keyboard device psm # psm mouse device vga # VGA screen # splash screen/screen saver device splash # syscons is the default console driver, resembling an SCO console device sc 1 # Enable this for the pcvt (VT220 compatible) console driver #device vt #optionsXSERVER # support for X server on a vt console #optionsFAT_CURSOR # start with block cursor # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) device apm # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # ISA Ethernet NICs. pccard nics included. device lnc # NE2100, NE32-VL Lance Ethernet cards # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop# Network loopback device ether # Ethernet support device sl # Kernel SLIP device ppp 1 # Kernel PPP device tun #
Re: S3 Savage on Thinkpad T23 using -CURRENT
On Tue, May 14, 2002 at 09:10:57AM -0500, Troy wrote: > Michael, > > Thanks for posting your Thinkpad T23 configuration. A lot has changed with regards >to kernel configuration from STABLE to CURRENT. > > The outstanding issue with the Thinkpad T23 in CURRENT is still the S3 SAVAGE video >card. I've had two folks mail their working XF86Config files (used in STABLE) to me >and they still do not produce resolution above 1024x768. > > It appears that the problem is because the video card is not being > recognized by the pci configuration (as noted by non0@pci1:0:0:). I'll try > posting this on the current and multimedia mailing lists to see if anyone > has an idea. Graphic board are not attach to any driver either in my configuration: none1@pci0:11:0:class=0x03 card=0x chip=0x88115333 rev=0x54 hdr=0x00 none2@pci1:0:0: class=0x03 card=0x0641102b chip=0x0525102b rev=0x82 hdr=0x00 XFree drivers are userland. Only the vga driver is attach by the kernel, which is not PCI. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bktr breakage
On Mon, Mar 25, 2002 at 10:21:49PM +0100, Nicolas Souchu wrote: > Hi there, > > *Sorry* for the breakage. I'm currently fixing it. > > smbus.h is due to the missing rule, smbus.h removed from OBJS. > > bktr_i2c.c is due to its automatic inclusion in kernel by conf/files: > conditional compilation inserted. > > pcf.c breakage is due to iicbus_alloc_bus() removed, device_add_child() > inserted instead. > > LINT ok. > GENERIC is compiling... > > I tell you once commited. Done. Thanks guys. Nicholas -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bktr breakage
Hi there, *Sorry* for the breakage. I'm currently fixing it. smbus.h is due to the missing rule, smbus.h removed from OBJS. bktr_i2c.c is due to its automatic inclusion in kernel by conf/files: conditional compilation inserted. pcf.c breakage is due to iicbus_alloc_bus() removed, device_add_child() inserted instead. LINT ok. GENERIC is compiling... I tell you once commited. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
booting -current with etherboot?
High folks, etherboot-5.0.3 doesn't boot my -current kernel. I previously had to upgrade the loader because of a similar problem when booting a -current kernel with a -stable loader. What are exactly the differences? Etherboot boots a -stable kernel just fine. Thanks, nicholas -- [EMAIL PROTECTED] - http://www.alcove.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: parallel port i/o hogs cpu badly; is this normal?
On Sun, Dec 02, 2001 at 02:10:58PM -0500, Kenneth Culver wrote: > I don't know if there's a way to stop this, but it's normal, whenever I use > my Parallel port zip drive, I have similar problems. For extended mode, currently FIFO+DMA, you may try : lptcontrol -e By this is experimental. It worked on my own config, but nobody else tried it, even me since a long time. Otherwise, you have lptcontrol -i but this should be the default already. -- Alcôve Technical Manager - [EMAIL PROTECTED] - http://www.alcove.com FreeBSD Developer - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I2C, bktr BIG patch
Hi folks, There's a patch a http://www.freebsd.org/~nsouch/download for using SMBus and I2C controllers of recent motherboards. It includes viapm, amdpm and an update of alpm(4). The viapm driver supports VIA 586, 596, 686 chipsets. The amdpm is for AMD760 chipset. These drivers may be used with /usr/ports/sysutils/healthd or other hand made tools to read SDRAM info... (see http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/) The patch also provide a huge update of the I2C framework, especially for dynamic module support. It includes big changes in the bit-banging interface which is used by bktr, lpbb, viapm. Unfortunatly, I could not test the bktr changes... I need volonteers to test the bktr changes before I can commit the patch to -current. The patch is organised as follows: iic-current.diffs shall be applied to sys/ iic_mods.tgz contains the sys/modules/i2c and sys/dev/pm directories. A later trick I have to solve: sys/dev/pm/viapm-686a.diff shall also be applied to sys/dev/pm/viapm.c On the TODO list: - apply viapm-686a.diff to viapm.c - move sys/pci/*pm.c to sys/dev/pm - Test/fix bktr with new bit-banging interface - Commit everything to -current - Write manpage for viapm - Include the amdpm manpage Thanks in advance, Nicholas -- Alcôve Technical Manager - [EMAIL PROTECTED] - http://www.alcove.com FreeBSD Developer - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[HEADSUP] iicbus/smbus testers before major commit
Hi folks, I finally have an update for the iicbus/smbus in -current. See http://people.freebsd.org/~nsouch/iicbus.html - April 2001 The major improvments are: - loadable / unloadable by means of modules - major cleanup of bus framework - support for the VIA 82C586 chipset - support for AMD 760 chipset (needs testing) By the way, I propose to remove the i386/isa/pcf.c iicbus/if_ic.c and ppbus/lpbb.c files from the tree since I can't do non-regression tests anymore for it. They could be maintained on a personal page instead... Tanks for you feedbacks. -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Tekram DC3x5 driver and -CURRENT
On Thu, Mar 22, 2001 at 11:01:07PM +0100, Daniel Rock wrote: > Hi, > > there exists a Tekram SCSI driver, which doesn't have an NCR/SymBIOS/LSILogic or > AMD chip. On the Tekram FTP site you can download a driver for FreeBSD though. > > Unfortunately, the latest one is for 4.x, which won't work on a current -CURRENT > system. > > Perhaps this driver should be integrated into the main tree, so it can be > actively maintained. > > I just have newbus'ified the driver and it seems to work in my machine, but I am > no FreeBSD kernel hacker. I don't have the slightest idea what I have done. I just > generated some diff's from other drivers which have been newbus'ified recently and > did the same steps. > > If some brave man is still interested I can mail him the modifications or post > them here. Unfortunatly, nobody might want to maintain it. It's programming style was horrible the last time I checked it. Also, I don't know if 4.x version is better, but 3.x never worked with my umax scanner. Linux one works pretty fine :( Nicolas -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [RFC] New features for libvgl
On Mon, Jan 22, 2001 at 08:45:19PM +0200, Maxim Sobolev wrote:
> Hi folks,
>
> Now I'm in process of writing a libvgl driver for SDL (almost finished - I'm
> testing it right now) and found that two handy features are currently missed
> from the libvgl: ability to query video modes supported by the video hardware
> and ability to install custom mouse eventhandler. So I extended libvgl
> attaching patches with this message. I would like that someone review/comment
> attached patches. Please also note that VGLListModes() part of these patches
> are not optimal right now (it largely duplicates VGLInit()), so please
> concentrate on concept rather than on implementation details.
Isn't your list of modes redundant with the internal data structures of the
VGA/VESA driver? Why do you list modes if it's not to query a specific one?
This is how I query the console (note that I planned to add it to VGL):
memset(&modeinfo, 0, sizeof(modeinfo));
switch(gt) {
case GT_1BIT : modeinfo.vi_depth = 1; break;
case GT_4BIT : modeinfo.vi_depth = 4; break;
case GT_8BIT : modeinfo.vi_depth = 8; break;
case GT_16BIT: modeinfo.vi_depth = 16; break;
case GT_32BIT: modeinfo.vi_depth = 32; break;
/* Unsupported mode depths */
case GT_15BIT:
case GT_24BIT:
default:
return -1;
}
modeinfo.vi_width = tm->visible.x;
modeinfo.vi_height = tm->visible.y;
/* XXX should be added to libvgl */
if (ioctl(0, FBIO_FINDMODE, &modeinfo))
return -1;
GGIDPRINT("Setting VGLlib mode %d (0x%x)\n",
modeinfo.vi_mode, modeinfo.vi_mode);
/* Terminate any current mode before initialising another */
if (priv->vgl_init_done) {
priv->vgl_init_done = 0;
VGLEnd();
}
/* XXX should be in VGL */
if ((modeinfo.vi_mode >= M_B40x25) && (modeinfo.vi_mode <= M_VGA_M90x60)
)
modenum = _IO('S', modeinfo.vi_mode);
if ((modeinfo.vi_mode >= M_TEXT_80x25) && (modeinfo.vi_mode <= M_TEXT_13
2x60))
modenum = _IO('S', modeinfo.vi_mode);
if ((modeinfo.vi_mode >= M_VESA_CG640x400) &&
(modeinfo.vi_mode <= M_VESA_FULL_1280))
modenum = _IO('V', modeinfo.vi_mode - M_VESA_BASE);
if ((err = VGLInit(modenum)) != 0) {
GGIDPRINT("display-vgl: setting mode 0x%x failed with error %d\n
",
modeinfo.vi_mode, err);
return GGI_EFATAL;
}
About the mouse stuff, what is the exact usage of MousePointerShow? It's
not documented in the manpage.
Nicholas
--
[EMAIL PROTECTED]
Alcôve - Open Source Software Engineer - http://www.alcove.fr
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: turning off vga_pci
On Thu, Jan 04, 2001 at 11:11:54PM -0800, Mike Smith wrote: > > On Sat, Dec 30, 2000 at 03:13:24AM +1000, Andrew Kenneth Milton wrote: > > > Is there a nice way to stop vga_pci from attaching to my video card, or > > > to allow another driver to attach to it after vga_pci has done its thing? > > > > > > At the moment I'm removing all traces of vga_pci from the Makefile in > > > my kernel 'compile' directory (which works)... > > > > Just remove the vga_pci entry in sys/conf/files. > > vga_pci is actually more of a nuisance than anything, and I've no > objections to seeing it removed (or doing it myself for that matter). > All the good reasons I thought I had for keeping it are long gone. Ok, that's on my todo list. -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: missing THREAD_UNLOCK in libc?
On Wed, Jan 03, 2001 at 10:00:22AM -0800, David O'Brien wrote: > On Wed, Jan 03, 2001 at 05:54:26PM +0100, Nicolas Souchu wrote: > > A program that previously worked (-current of November) with -pthread now > > fails with an abort and a " in free(): error: recursive call" warning. > > I need a copy of this program (source form) to test with. Tell me rather how you'd investigate it. It's a bit large (GGI). Nicholas -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off vga_pci
On Sat, Dec 30, 2000 at 03:13:24AM +1000, Andrew Kenneth Milton wrote: > Is there a nice way to stop vga_pci from attaching to my video card, or > to allow another driver to attach to it after vga_pci has done its thing? > > At the moment I'm removing all traces of vga_pci from the Makefile in > my kernel 'compile' directory (which works)... Just remove the vga_pci entry in sys/conf/files. It would be nice to make this optional if we want to load a module for a given graphic card later on. I have for example a VESA-extended driver (http://www.freebsd.org/~nsouch/download/s3pci.c) for S3 graphic cards that _have_ linear framebuffer but only VESA 1.2 bios. It currently works on top of VESA by replacing the video switch by another. Exactly as VESA does on top of VGA. What about including it into the tree as a module... s3_pci.c would be in sys/dev/pci, nothing in sys/conf/files: just a module in sys/modules/s3. Nicholas -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
missing THREAD_UNLOCK in libc?
I have some troubleshootings with -current. A program that previously worked (-current of November) with -pthread now fails with an abort and a " in free(): error: recursive call" warning. I think that there may be some errors in my program and I'd like to know what was recently modified in libc or libc_r in order to track them down. While looking at the source of the warning in free(), I noticed that a THREAD_UNLOCK() may be missing in the case of a recursive call... Nicholas -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Various VGA, VGL, FB questions
On Tue, Dec 19, 2000 at 01:32:47AM -0800, Mike Smith wrote: > > Why is there the same VGA code in dev/fb/vga.c and libvgl? I think > > especially of the set_palette routines. > > The framebuffer code is a newer addition. Libvgl was done quite a while > ago as more or less a proof-of-concept. > > > As a more general rule, what's the philosophy for the future of > > libvgl and framebuffer? Should VGL drawing routines be moved to > > dev/fb/vga.c? > > The framebuffer should grow a set of drawing primitives, yes. Exactly > what these primitives is is probably open to discussion. A good idea > might be to look at the GGI project, which is producing > BSD-license-compatible kernel-side graphics code. I'm currently porting GGI ;) This is why I'm interested in kernel graphic support. I have already something done which is based on the VGL library (keyboard and display in VGA modes -- the mouse is the standard linux-mouse of GGI on top of /dev/sysmouse). It's already in the GGI library source package. I can't hide much longer that my project is to get KGI ported to FreeBSD. But that's another huge part. First, I'd like to have a clean overview of VGA/VESA/FB support in FreeBSD. I think that with some efforts in the newbus direction, I'd get rapidly this overview, isn't it? Actually I moved to GGI / FreeBSD considerations because we need, in my company, some proof of our capability to integrate low level stuff in open source kernels. The second point is that I personaly think that FreeBSD has some lacks in graphic support and that XFree is something to heavy. I'd really love... a graphic boot. Yes, I know, that's not a priority for FreeBSD headquarters :) For this I'll need graphic very early in the boot stages and I'll certainly ask you more about this soon or later. Nicholas -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Various VGA, VGL, FB questions
Dear hackers, Why is there the same VGA code in dev/fb/vga.c and libvgl? I think especially of the set_palette routines. As a more general rule, what's the philosophy for the future of libvgl and framebuffer? Should VGL drawing routines be moved to dev/fb/vga.c? Also, there are some drawing routines enclosed with notyet defines. What are there state? bogus? Finally, is someone working on this part of the tree currently? Nicholas -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
link_elf: symbol undefined when loading module
Hi there, Don't know how to deal with the following error: link_elf: symbol PPBUS_IO undefined when loading the vpo module. PPBUS_IO is defined in ppbus_if.h as a static __inline fonction and does not appear as an undefined symbol in vpo.kld... Any clue? How should I investigate the pb? Nicholas -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
console freeze
Hi there, I did browse the lists but found nothing about my problem. Compiling GENERIC of 5.0 works correctly but once I remove most of uneeded hardware, the console/kbd freeze. I join the MACHINE file and the output. I even tried to change the graphic card to a PCI S3, same. I can get the getty on the serial line, so I tried vidcontrol -i on it. It reports stupid info. Is there something I can try? Nicholas -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr # # BAIKAL # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the NOTES configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.291 2000/11/15 18:36:24 imp Exp $ machine i386 cpu I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU ident BAIKAL maxusers32 #To statically compile in device wiring instead of /boot/device.hints #hints "BAIKAL.hints" #Default places to look for devices. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options DDB options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] #optionsSOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem #optionsNFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem #optionsDEVFS #Device Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev # To make an SMP kernel, the next two are needed #optionsSMP # Symmetric MultiProcessor Kernel #optionsAPIC_IO # Symmetric (APIC) I/O device isa device pci #optionsCOMPAT_OLDISA # compatability shims for lnc, le #optionsCOMPAT_OLDPCI # compatability shims for lnc # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device pass# Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc 1 # At keyboard controller device atkbd # at keyboard device psm # psm mouse device vga # VGA screen # splash screen/screen saver device splash # syscons is the default console driver, resembling an SCO console device sc 1 # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) device apm # Add suspend/resume support for the i8254. device pmtimer # Audio support #device pcm # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel
Re: Mutex, SMBUS, ACPI (Re: how to mutex'ify a device driver)
On Tue, Nov 28, 2000 at 02:30:50PM +0100, Dag-Erling Smorgrav wrote: > Nicolas Souchu <[EMAIL PROTECTED]> writes: > > What are kernel mutex? A new mechanism for spl replacement? Is it > > introduced with the new SMP? I found nothing in the mail archives... > > You mean you don't read -committers, -developers and -arch? I see... No, not recently. I know that's unacceptable and I could not remain silent anymore with this huge fault on my shoulders :) Before I got my new job, I was really busy and could not contribute at all. Now, things are changing as I have some time allocated for personnal open source projects. Nicholas -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Mutex, SMBUS, ACPI (Re: how to mutex'ify a device driver)
On Wed, Nov 22, 2000 at 04:58:32PM -0800, Archie Cobbs wrote: > As a relatively simple exercise in -current kernel programming, > I'm planning to mutex'ify the ichsmb(4) device driver (this is > a relatively simple driver that currently uses splhigh()). I'd > appreciate some feedback if what I'm doing is the right thing. What are kernel mutex? A new mechanism for spl replacement? Is it introduced with the new SMP? I found nothing in the mail archives... > > The plan is to give each instance of the device a mutex. This > mutex will be grabbed by both the top level code (when programming > the chip to do something or reading the results) and the interrupt > code (when servicing an interrupt). Have you comments about smbus/iicbus? What would you add to the todo list of the framework? Did you participate to ACPI discussions? -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current and diskless...
On Fri, Feb 04, 2000 at 09:31:16PM +0100, Mark Huizer wrote: > >Is it possible to boot current diskless? Yes. > >I'd say (from the times I tried it in 3.1 or something) to use netboot, >but that fails because it can't boot an ELF kernel. net/etherboot port will do the job. > >Should I build an aout kernel, and how do I do that for current? etherboot knows FreeBSD elf. > >Can I do it another way? > >One might say that with the rc.diskless files in /etc, that it should >work somehow... Sure it does. I use it. rc.diskless is powerfull and allow you to share your server config (binaries + most configuration files) with bootp clients. Here's the result for the currently running bootp client: >>> Filesystem 512-blocks UsedAvail Capacity Mounted on 10.3.0.2:/ 198366 1204946200466%/ mfs:30 1918 1416 35080%/conf/etc mfs:3463486 33658072 1%/tmp /conf/etc 1918 1416 35080%/etc procfs880 100%/proc breizh:/diskless/varfs/armor4063844 2559428 117931068%/var breizh:/usr 595326 4550529264883%/usr breizh:/usr/X11R6595326 4550529264883% /usr/X11R6_elf-3.3.3 breizh:/usr/local 2051134 1415828 47121675%/usr/local breizh:/usr/contrib 4063844 2559428 117931068%/usr/contrib mfs:64 3022 106 2676 4%/dev breizh:/usr/X11R6595326 4550529264883% /usr/X11R6_elf-3.3.3 Note that 10.3.0.2 is breizh. DHCP port is running on breizh and serves tftp/bootp requests to booting clients. I use the following options in my client MACHINE files: options BOOTP # Use BOOTP to obtain IP address/hostname options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info options BOOTP_COMPAT# Workaround for broken bootp daemons. options BOOTP_WIRED_TO=ed1 # Use interface fxp0 for BOOTP options MFS #Memory Filesystem options NFS #Network Filesystem pseudo-device vn 4 #Vnode driver (turns a file into a device) > >Greetings > >mark >-- >Nice testing in little China... > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > Nicholas -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
On Sun, Jan 30, 2000 at 02:42:39PM -0500, Brian Dean wrote:
>
>
>For what its worth, I am able to reproduce this problem on my system.
Would you mind trying this patch before I send it to Jordan?
Index: lpt.c
===
RCS file: /home/ncvs/src/sys/dev/ppbus/lpt.c,v
retrieving revision 1.13
diff -u -r1.13 lpt.c
--- lpt.c 2000/01/25 22:23:47 1.13
+++ lpt.c 2000/02/02 23:10:36
@@ -865,12 +865,12 @@
/*
* No more data waiting for printer.
-* Wakeup is not done if write call was interrupted.
+* Wakeup is not done if write call was not interrupted.
*/
sc->sc_state &= ~OBUSY;
if(!(sc->sc_state & INTERRUPTED))
- wakeup((caddr_t)sc);
+ wakeup((caddr_t)lptdev);
lprintf(("w "));
return;
} else { /* check for error */
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: bootp and diskless failure
On Mon, Jan 31, 2000 at 12:17:11AM +0100, Nicolas Souchu wrote: > >Hi, > >Is there something changed on BOOTP/diskless configuration? > >This problem reappears some times and was fixed in August if I remember. >A hack was proposed before August, something like 'make root dev' call in >bootp_subr.c > >Thanks, > >Nicholas NFS_ROOT which wasn't mandotory, is now. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
On Sun, Jan 30, 2000 at 10:38:57PM -0500, David Gilbert wrote: > >> "Michael" == Michael Remski <[EMAIL PROTECTED]> writes: > >Michael> ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: SMC-like chipset >Michael> (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with >Michael> 16/16/7 bytes threshold lpt0: on ppbus 0 >Michael> lpt0: Interrupt-driven port > >I don't get the FIFO portion of the probe. With ECP mode available? You should. > >Dave. > >-- > >|David Gilbert, Velocet Communications. | Two things can only be | >|Mail: [EMAIL PROTECTED] | equal if and only if they | >|http://www.velocet.net/~dgilbert | are precisely opposite. | >=GLO > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bootp and diskless failure
Hi,
Is there something changed on BOOTP/diskless configuration?
This problem reappears some times and was fixed in August if I remember.
A hack was proposed before August, something like 'make root dev' call in
bootp_subr.c
Thanks,
Nicholas
bootpc_init: using network interface 'ed0'
Bootpc testing starting
bootpc hw address is 0:40:5:e2:a0:e9
My ip address is 10.2.0.1
Server ip address is 10.2.0.2
Gateway ip address is 0.0.0.0
boot file is kernel.coreff
Ignoring field type 54
Subnet mask is 255.255.0.0
rootfs is 10.2.0.2:/diskless/rootfs/current
Ignoring field type 28
no B_DEVMAGIC (bootdev=0x)
Manual root filesystem specification:
: Mount using filesystem
eg. ufs:/dev/da0s1a
? List valid disk boot devices
Abort manual input
>>>
panic: Root mount failed, startup aborted.
Debugger("panic")
Stopped at Debugger+0x35: movb$0,0xc02d7f00
db> panic
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
On Sat, Jan 29, 2000 at 08:21:33PM -0800, Matthew Dillon wrote: > >When the new parallel port stuff was put several months ago, my >machine stopped working. I had to set flags to 0x40 to make it >work again. Flags of 0x40 force the driver to use the most >basic probes possible. It was put in because a number of people's >machines stopped working. > >It looks like Peter removed the flags 0x40 in rev 1.228 of GENERIC >on Jan 14. Specific chipset detection is now disabled by default since most of the chipsets detected on new MB are not recognised by ppc. A MACHINE option shall be set to activate chipset detection. See http://www.freebsd.org/~nsouch/ppbus.html for more info. [...] > >David, try putting flags 0x40 back in and see if that fixes your >problem. 0x40 has the same effect only if chipset specific detection is activated at compile time by the correct option. Otherwise the action is null. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
On Sat, Jan 29, 2000 at 10:59:15PM -0500, David Gilbert wrote: > >> "Chris" == Chris Costello <[EMAIL PROTECTED]> writes: > >Chris> On Saturday, January 29, 2000, David Gilbert wrote: >>> When this happens, the entire machine freezes until someone feeds >>> the printer --- the momment it starts printing again, the computer >>> unfreezes. > >Chris>Could it be a printer-specific (or printer-compatibility) >Chris> problem? My HP DeskJet 880C does not have that problem at all: > >To my mind, the printer shouldn't be able to hang the comptuer ... no >matter what it does. My biggest problem is that it hangs the system. Even if rapid interrupts are sent to the computer? A priority issue among various interrupt sources maybe. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
On Sat, Jan 29, 2000 at 09:49:40PM -0600, Chris Costello wrote: > >On Saturday, January 29, 2000, David Gilbert wrote: >> When this happens, the entire machine freezes until someone feeds the >> printer --- the momment it starts printing again, the computer >> unfreezes. > > Could it be a printer-specific (or printer-compatibility) >problem? My HP DeskJet 880C does not have that problem at all: > >ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 >ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode >ppb0: IEEE1284 device found /NIBBLE/ECP >Probing for PnP devices on ppbus0: >ppbus0: MLC,PCL,PML >plip0: on ppbus 0 >lpt0: on ppbus 0 >lpt0: Interrupt-driven port >ppi0: on ppbus 0 Note that you're using an older ppbus/lpt drivers. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Parallel Port Zip Drive works when EPP-Mode is choosen in Bios
On Sat, Jan 22, 2000 at 10:03:25AM +, Doug Rabson wrote: >> >> Nice. The newbus architecture introduces overhead in I/O and old chipsets >> (or old compatible modes) do not always support it. >> >> Your drive runs really faster too, doesn't it? > >Have you measured the overhead? I think it should be trivial compared to >the effort of using inb/outb to poll a port. No, but each time function calls are introduced in the ppbus framework (initially to isolate ppbus layers and now with newbus) some parallel port stop working. Certainly more a timing issue than a performance issue I think. But some good hardware never failed, some bad hardware fails with either slow (486) or fast processors. > >-- >Doug RabsonMail: [EMAIL PROTECTED] >Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > > -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Parallel Port Zip Drive works when EPP-Mode is choosen in Bios
On Thu, Jan 20, 2000 at 12:26:08PM +0100, F. Heinrichmeyer wrote: > > >Subject says all! This evening i will try a patch for the ata driver so >maybe all my >hardware at home will work again with current when certain patches are >applied. Nice. The newbus architecture introduces overhead in I/O and old chipsets (or old compatible modes) do not always support it. Your drive runs really faster too, doesn't it? > > >-- >Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] >FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) >tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: no more parallel port zip drive
On Sun, Jan 16, 2000 at 03:21:16PM +0100, F. Heinrichmeyer wrote: > >My parallel port zip-drive stopped working this weekend with the new ppc >code. There is no printer attached: Hmm, any chance to change parallel port bios setting on your MB? > > >-- >Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] >FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) >tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: latest ppbus changes
On Fri, Jan 14, 2000 at 01:38:47AM -0500, Kenneth Wayne Culver wrote: No problem here, I attach you the MACHINE and dmesg. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Fri Jan 14 08:49:41 CET 2000 nsouch@armor:/usr/devel/current/src/sys/compile/COREFF Timecounter "i8254" frequency 1193182 Hz CPU: AMD Enhanced Am486DX4 Write-Through (486-class CPU) Origin = "AuthenticAMD" Id = 0x484 Stepping = 4 Features=0x1 real memory = 25165824 (24576K bytes) avail memory = 21917696 (21404K bytes) npx0: on motherboard npx0: INT 16 interface isa0: on motherboard devclass_alloc_unit: npx0 already exists, using next available unit number fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x0> sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 flags 0xb0 on isa0 sio1: type 16550A, console sio2: not probed (disabled) sio3: not probed (disabled) pcf0: at port 0x320-0x321 irq 5 on isa0 iicbus0: on pcf0 addr 0xaa iicsmb0: on iicbus0 smbus0: on iicsmb0 smb0: on smbus0 iic0: on iicbus0 ppc0: at port 0x278-0x27f irq 7 on isa0 ppc0: SMC FDC37C666GT chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: PRINTER HP ENHANCED PCL5,PJL pps0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port plip0: on ppbus0 ppi0: on ppbus0 vpo0: on ppbus0 vpo0: EPP 1.9 mode pca0 at port 0x40 on isa0 pca0: PC speaker audio driver ed0 at port 0x300-0x31f iomem 0xd8000 irq 10 on isa0 ed0: address 00:40:05:4a:29:02, type NE2000 (16 bit) ep0: not probed (disabled) da0 at vpo0 bus 0 target 6 lun 0 da0: Removable Direct Access SCSI-2 device da0: Attempt to query device size failed: NOT READY, Medium not present bootpc_init: wired to interface 'ed0' bootpc_init: using network interface 'ed0' Bootpc testing starting bootpc hw address is 0:40:5:4a:29:2 My ip address is 10.2.0.1 Server ip address is 10.2.0.2 Gateway ip address is 0.0.0.0 boot file is kernel.coreff Ignoring field type 54 Subnet mask is 255.255.0.0 rootfs is 10.2.0.2:/ Ignoring field type 28 swapfs is 10.2.0.2:/diskless/swapfs md_lookup_swap: Swap size is 16000 KB Mounting root from nfs: NFS ROOT: 10.2.0.2:/ NFS SWAP: 10.2.0.2:/diskless/swapfs # # COREFF # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # http://www.FreeBSD.ORG/> # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # machine "i386" cpu "I486_CPU" ident COREFF maxusers32 options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options MFS #Memory Filesystem options NFS #Network Filesystem options NFS_ROOT#NFS usable as root device, "NFS" req'ed options MSDOSFS #MSDOS Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Be pessimistic about Joe SCSI device options UCONSOLE#Allow users to grab the console # Kernel BOOTP support options BOOTP # Use BOOTP to obtain IP address/hostname options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info #optionsBOOTP_NFSV3 # Use NFS v3 to NFS mount root options BOOTP_COMPAT# Workaround for broken bootp daemons. options BOOTP_WIRED_TO=ed0 # Use interface fxp0 for BOOTP #optionsDDB # enable debugger #optionsGDB_REMOTE_CHAT #optionsPNPBIOS device isa0 device pci0 device fdc0at isa? port "IO_FD1" irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 #device wdc0at isa? port "IO_WD1" bio irq 14 #device wd0 at wdc0
Re: latest ppbus changes
On Fri, Jan 14, 2000 at 01:38:47AM -0500, Kenneth Wayne Culver wrote: > >The latest ppbus changes seem to have made some things break. My dmesg no >longer shows lpt0 or vpo0 as being detected ( even though they are defined >in the kernel conf file, and are being compiled into the kernel) which >means I can't print anything or use my parallel port zip drive. (yes I >have scbus0 and da0 defined in the kernel also.) Just thought I'd let >someone know. Would you mind checking your ioconf.c file and send it to me eventually. In principle, ppbus now relies on it to attach/probe devices. Otherwise, the rest of ppbus (ppc/ppbus and maybe plip/ppi) are probed and attached? > > >= >| Kenneth Culver | FreeBSD: The best OS around.| >| Unix Systems Administrator | ICQ #: 24767726 | >| and student at The | AIM: AgRSkaterq| >| The University of Maryland, | Website: (Under Construction) | >| College Park. | http://www.wam.umd.edu/~culverk/| >= > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP newppbus for beta-testing
On Thu, Jan 06, 2000 at 12:45:36AM +0200, Maxim Sobolev wrote: > >Nicolas Souchu wrote: > >> On Mon, Jan 03, 2000 at 09:24:52PM +0200, Maxim Sobolev wrote: >> > >> >Nicolas Souchu wrote: >> > >> >> Hi there! >> >> >> >> FOR ANYBODY THAT USES ZIP/PRINTER/PLIP ON THE PARALLEL PORT UNDER -current >> >> >> >> A major ppbus(4) release is available for beta-testing. >> > >> >Good work! Now plip, which has been broken for ages, works perfectly - no more >> >lockups, spontaneous reboots, panics, etc! To test it I even managed to get X >> >and NFS working over plip line, things which was impossible with oldppbus. >> >> Nice! But, sure the 'net' interrupt level mask (at the ppc0 declaration) >> in you MACHINE config file would have done the job. > >Unfortunately it is not a solution because net,tty and bio keywords went away from >config(8) long time ago... I've only received `syntax error' message. Ooops! A really bad thing. I did not notice it. They did not use to manage compatibility issues like this before?! > >-Maxim > > > -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ppbus in 4.0-stable? (was: Re: 4.0 code freeze scheduled for Jan 15th)
Hi committers! On Wed, Jan 05, 2000 at 11:44:06AM -0800, Jordan K. Hubbard wrote: > >And given that we've already slipped from December 15th, I think you >can treat this as a pretty hard deadline, to be further slipped only >grudgingly and in response to clear and dire need. > >10 days, folks! Make 'em count.. :) > As usual, the last wheel of the coach: ppbus. You may or may not know new-ppbus is now available for the newbus interfaces. It would make it really easier to maintain it if submitted before the -stable jump. http://www.freebsd.org/~nsouch/ppbus.html reports the improvements. Regression tests shows the newppbus is quite solid... but now I can't rely on a wild commit which would force everybody to test it :) So, please try it! And we'll decide. Thanks in advance, and sorry for being so late :( Nicholas. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP newppbus for beta-testing
On Mon, Jan 03, 2000 at 09:24:52PM +0200, Maxim Sobolev wrote: > >Nicolas Souchu wrote: > >> Hi there! >> >> FOR ANYBODY THAT USES ZIP/PRINTER/PLIP ON THE PARALLEL PORT UNDER -current >> >> A major ppbus(4) release is available for beta-testing. > >Good work! Now plip, which has been broken for ages, works perfectly - no more >lockups, spontaneous reboots, panics, etc! To test it I even managed to get X >and NFS working over plip line, things which was impossible with oldppbus. Nice! But, sure the 'net' interrupt level mask (at the ppc0 declaration) in you MACHINE config file would have done the job. > >Count on my vote to commit it before branch split because IMHO it should be >considered as a bugfix rather that a new feature. > >-Maxim > Nicholas -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS-UP newppbus for beta-testing
Hi there! FOR ANYBODY THAT USES ZIP/PRINTER/PLIP ON THE PARALLEL PORT UNDER -current A major ppbus(4) release is available for beta-testing. It includes the port of the ppbus framework to the newbus system. http://www.freebsd.org/~nsouch/ppbus.html provides usefull notes about the configuration of ppbus through the MACHINE file and the newppbus developement progression (stability, caveats...) The newppbus will come in remplacement to the previous standalone ppbus architectural system. I did not read recent announces about future FreeBSD 4.x releases :( Of course, newppbus introduction would better before any -stable jump. Note that, only probe/attach and function interfaces were concerned by the port and tests are consequently only regression tests. The port was not to hard and the result should not be too bad. Moreover the current ppbus high level drivers stress the system well I think: vpo (SCSI controller), lpt (with PS data filtered by ghostscript and interrupts) Feel free to contact me for more, Nicholas. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATAPI CR writing problem after onp
Hi, I have the following errors when I try to append audio to a fixated onp CD-R First, shall I reuse burnaudio when reopening a CD? I made burnaudio work with the following tricks: >>> device=/dev/r$1 wormcontrol -f$device prepdisk single shift for f in $* do echo Burning file $f wormcontrol -f $device track audio wormcontrol -f $device nextwriteable dd if=$f of=$device bs=2352 done wormcontrol -f $device fixate 0 onp <<< fixate 0 instead of 1 prepdisk single instead of double >>> atapi_error: READ_TOC - ILLEGAL REQUEST skey=5 asc=24 ascq=00 error=00 acd0: sequence error (PREP_TRACK) atapi_error: READ_TOC - ILLEGAL REQUEST skey=5 asc=24 ascq=00 error=00 atapi_error: READ_TOC - ILLEGAL REQUEST skey=5 asc=24 ascq=00 error=00 atapi_error: WRITE_BIG - ILLEGAL REQUEST skey=5 asc=21 ascq=17 error=00 atapi_error: READ_TOC - ILLEGAL REQUEST skey=5 asc=24 ascq=00 error=00 atapi_error: READ_TOC - ILLEGAL REQUEST skey=5 asc=24 ascq=00 error=00 acd0: read_toc failed acd0: read_toc failed i4b-L1-timer4_expired: state = F3 Deactivated atapi_error: READ_TRACK_INFO - ILLEGAL REQUEST skey=5 asc=21 ascq=10 error=00 atapi_error: WRITE_BIG - ILLEGAL REQUEST skey=5 asc=64 ascq=21 error=00 atapi_error: READ_TRACK_INFO - ILLEGAL REQUEST skey=5 asc=21 ascq=10 error=00 atapi_error: WRITE_BIG - ILLEGAL REQUEST skey=5 asc=64 ascq=21 error=00 cd9660: Joliet Extension i4b-L1-timer4_expired: state = F3 Deactivated atapi_error: READ_TRACK_INFO - ILLEGAL REQUEST skey=5 asc=21 ascq=10 error=00 atapi_error: WRITE_BIG - ILLEGAL REQUEST skey=5 asc=64 ascq=21 error=00 atapi_error: READ_TRACK_INFO - ILLEGAL REQUEST skey=5 asc=21 ascq=10 error=00 atapi_error: WRITE_BIG - ILLEGAL REQUEST skey=5 asc=64 ascq=21 error=00 <<< The dmesg is >>> atapi: piomode=3, dmamode=1, udmamode=-1 atapi: PIO transfer mode set acd0: CDROM drive at ata0 as master acd0: drive speed 1034KB/sec, 768KB cache acd0: supported read types: CD-R, CD-RW, CD-DA, packet track acd0: supported write types: CD-R, CD-RW, test write acd0: Audio: play, 128 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm audio disc loaded, unlocked, lock protected ata0: unwanted interrupt 2 status = 00 ata_command: timeout waiting for interrupt <<< Thanks in advance! Nicholas -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with the ata driver
On Tue, Aug 24, 1999 at 08:39:25AM +0200, Soren Schmidt wrote: >> Which ones, I found nothing in the LINT file related to ATA. > >"There is no user serviceable parts inside" :) and if patch someone just >posted works it seems like the drive is abusing the standard. I'll look >at it asap, then lets see how far it comes... Ok nice, let me know. > >-Søren > -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with the ata driver
On Mon, Aug 23, 1999 at 08:27:15AM +0200, Soren Schmidt wrote: > >It seems Nicolas Souchu wrote: >> acd0: CDROM drive at ata0 as master >> acd0: drive speed 0KB/sec >> acd0: supported read types: >> acd0: Mechanism: caddy >> acd0: Medium: CD-ROM unknown medium >> >> Any clue? >> >> The drive was running flawlessly with the old wdc driver and with various >> primary releases of the new ata driver (some, not all). > >Hmm, looks like the timeout I've chosen for timing out on the probes >*might* be too short for some devices.. Which ones, I found nothing in the LINT file related to ATA. > >-Søren > Thanks. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
problem with the ata driver
Hi there, hi Soren, First of all, the dump. Preloaded elf kernel "kernel" at 0xc0302000. Intel Pentium detected, installing workaround for F00F bug Probing for PnP devices: npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm: found APM BIOS version 1.2 pcib0: on motherboard pci0: on pcib0 chip0: at device 0.0 on pci0 isab0: at device 7.0 on pci0 ata-pci0: at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ahc0: irq 3 at device 9.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs vga-pci0: irq 11 at device 11.0 on pci0 fxp0: irq 9 at device 12.0 on pci0 fxp0: Ethernet address 00:90:27:3d:36:f9 devclass_alloc_unit: npx0 already exists, using next available unit number isa0: on motherboard fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: on isa0 sc0: on isa0 sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppb0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: PRINTER HP ENHANCED PCL5,PJL plip0: on ppbus 0 lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 isic0 at port 0x268 irq 5 flags 0x7 on isa0 isic0: USRobotics Sportster ISDN TA intern isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) (Addr=0xc268) isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x268, AddrB=0x4268) pca0 at port 0x40 on isa0 pca0: PC speaker audio driver ed0 at port 0x300-0x31f iomem 0xd8000-0xdbfff irq 10 on isa0 ed0: address 00:00:c0:37:f2:d0, type SMC8216/SMC8216C (16 bit) ep0: not probed (disabled) ata0: unwanted interrupt 1 status = ff i4b: ISDN call control device attached i4bisppp: 4 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached i4bipr: 4 IP over raw HDLC ISDN device(s) attached (VJ header compression) i4btel: 2 ISDN telephony interface device(s) attached i4brbch: 4 raw B channel access device(s) attached i4btrc: 4 ISDN trace device(s) attached acd0: CDROM drive at ata0 as master acd0: drive speed 0KB/sec acd0: supported read types: acd0: Mechanism: caddy acd0: Medium: CD-ROM unknown medium Waiting 15 seconds for SCSI devices to settle changing root device to da0s1a da0 at ahc0 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da1 at ahc0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4067MB (8330542 512 byte sectors: 255H 63S/T 518C) As you can see the drive is not properly detected. Note the "ata0: unwanted interrupt 1 status = ff" Any clue? The drive was running flawlessly with the old wdc driver and with various primary releases of the new ata driver (some, not all). Nicholas -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PLIP is still broken :(
On Mon, Jul 26, 1999 at 05:04:42AM +1000, Bruce Evans wrote:
>
>>>Otherwise,
>>>the generic code is missing mainly update of the interrupt masks when
>>>an interrupt is unregistered.
>>
>>For the low level side, we could consider something like the following code.
>>But this shall be called by the nexus layer and then needs generic newbus
>>support (as you said above, didn't you?).
>
>>/*
>> * Switch an irq from a maskptr to another without unregistering the irq
>> * handler.
>> * This function is supposed to work with only one handler per irq.
>> */
>>void
>>switch_masks(intrmask_t *oldmaskptr, intrmask_t *newmaskptr, int irq)
>
>
>I don't like most of this. Driver level code won't even know the
>correct maskptrs. (irq, maskptr) pairs depend on i386 implementation
>details for uniqueness. Use { s = splhigh(); BUS_TEARDOWN_INTR(...);
>BUS_SETUP_INTR(...); splx(s); } until/unless the newbus level provides
This is what I meant when I said the nexus layer shall do the switch_masks()
call. The current implementation of SETUP_INTR/TEARDOWN involves the overhead
of unregistering and registering the interrupt. This is why I propose
switch_masks() which doesn't.
Moreover, in the ppbus model, the ppc_intr() function is _always_ the registered
interrupt handler and it dispatches the interrupt depending on the device driver
which currently owns the bus when the interrupt occurs.
>a better interface. The problem with the masks not being updated when
>interrupts are unregistered should be fixed in update*_masks().
I agree if unregistering/registering is declared better than switching masks
for the current registered handler.
>
>Bruce
>
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PLIP is still broken :(
On Sun, Jul 25, 1999 at 09:35:36AM +1000, Bruce Evans wrote:
>
>>>Possible quick fix (hack): change all the spltty()'s in lpt.c to
>>>splnet()'s. lpt isn't a tty driver; it just abuses spltty(). Abusing
>>>splnet() instead should work OK for lpt and fix if_plip.
>>
>>This seems good until the intr stuff handle dynamic update of a interrupt spl.
>>Is there some work in progress on that?
>
>Not much. ppc needs to do most of the work by registering its interrupt
>with the correct interrupt maskptr for the currently attached device.
>This may involve unregistering the interrupt when the device changes.
>The generic code could help here by supporting atomic changing of
>interrupt maskptrs without unregistering the interrupt. Otherwise,
>the generic code is missing mainly update of the interrupt masks when
>an interrupt is unregistered.
For the low level side, we could consider something like the following code.
But this shall be called by the nexus layer and then needs generic newbus
support (as you said above, didn't you?).
/*
* Switch an irq from a maskptr to another without unregistering the irq
* handler.
* This function is supposed to work with only one handler per irq.
*/
void
switch_masks(intrmask_t *oldmaskptr, intrmask_t *newmaskptr, int irq)
{
int s;
intrec *idesc;
intrmask_t mask = 1 << irq;
if ((oldmaskptr == NULL) || (newmaskptr == NULL))
return;
if (((idesc = find_idesc(oldmaskptr, irq)) == NULL) ||
(find_idesc(newmaskptr, irq) != NULL))
return;
/* block all interrupts */
s = splhigh();
/* update the irq mask ptr */
idesc->maskptr = newmaskptr;
/* remove the irq from the old mask and add it to the new one */
INTRUNMASK(*oldmaskptr, mask);
INTRMASK(*newmaskptr, mask);
/* we need to update all values in the intr_mask[irq] array */
update_intr_masks();
/* update mask in chains of the interrupt multiplex handler as well */
update_mux_masks();
/* restore interrupts */
splx(s);
return;
}
Your opinion?
Nicholas.
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PLIP is still broken :(
On Mon, Jul 19, 1999 at 07:37:02PM +1000, Bruce Evans wrote: > >>You misunderstood what Bruce wrote. PLIP has always been broken. It >>used to be possible to hack around the brokenness by setting the >>interrupt mask to net instead of tty. With newbus, this hack is no >>longer possible (it was never correct anyway; it broke printing). Or we shall consider changing isa_compat.c if we choose splnet for lpt. > >Or by statically configuring SLIP (which forced tty = net), or maybe >by dynamically configuring PPP. The tty = net hack went away with >old-bus, so SLIP is broken in much the same way as PLIP. > >>The problem with PLIP is that it tries to do splnet stuff in at >>spltty. If you force the parallell port driver to run at splnet, PLIP >>works but you get panics when you print because it tries to do spltty >>stuff at splnet. > >Possible quick fix (hack): change all the spltty()'s in lpt.c to >splnet()'s. lpt isn't a tty driver; it just abuses spltty(). Abusing >splnet() instead should work OK for lpt and fix if_plip. This seems good until the intr stuff handle dynamic update of a interrupt spl. Is there some work in progress on that? > >Bruce > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PLIP is still broken :(
On Mon, Jul 19, 1999 at 11:15:24AM +0200, Poul-Henning Kamp wrote: > > >This is actually a deficiency in the ppbus stuff, there is no >telling what SPL level the subdriver wants to use, so the interrupt This is changing. I'm currently working on porting ppbus to newbus. >should actually be released back to the system when no subdrivers What do you exactly call back to the system? Not served? If so, this is the current behaviour of the generic ppbus interrupt dispatcher (eg ppb_intr()) >are open and be grabbed the way the subdriver wants it once it >aquires the bus. But the newbus which relies on the old machdep intr stuff doesn't seem to offer such a service. Doesn't it? Why was the SLIP hack removed then? And I noticed the PPP workaround is still alive in net/ppp_tty.c... Nicholas. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! config(8) changes..
On Mon, May 24, 1999 at 10:46:41PM -0700, Mike Smith wrote: >> >> Someone who would help me driving ppbus, yes. I didn't have enough time >> last months. > >Do you expect that the situation will improve, or do you feel you need >to hand it over to a new maintainer? > The situation shall improve. But I'd like to keep time to manage iic/smbus a bit more closely. What takes time is not the development, but answering to questions, track bugs, fix them... the second live of the software. I don't have time for both, especially when the whole operating system is changing very fast like it did last few months, breaking all development tools (ether/netboot, elf/aout, gdb...). I stop here :) Most of the framework is ready to work. Just some fixes and more testing are needed for the topics mentionned later (excepted ECP support which needs more work). > >> - fix ppc probe bugs with recent mainboards > >I think that this needs to wait on the PnP hooks into the resource >manager. If the chipset probes are killing something, I'd wager that >the something in question is mentioned in the PnP data. > >> - sync -current and -stable > >This would be handy, and could probably be achieved easily. > >> - test plip in depth > >That'd be useful. > >I would add > >- Improve ECP/EPP performance if possible. What do you mean here? PLIP? Then yes. I was in contact with the Linux part for this. We'll have to look at there protocol choices. > >- Add/finish bidirectional ECP printer support. Shall not be too hard with an ECP printer. Most of the needed routines are already in the ppbus framework. But I'm afraid that it will lead to the rewrite of lpt driver, not a bad thing though. > >> I think there is more to do with making ppbus more and more stable than >> bringing new capabilities to it yet. > >That's certainly a worthwhile perspective. What can we do to help you? Thanks. I can't afford both developments and ppbus support. Peter proposed me some help for the newbus port (removing linker_sets). I still need manpower for the support (I know this may not be the finest part of the advanture) and the plip extensions if requested by the FreeBSD community (may not be mandatory with cheaper network cards and USB...). And finally find an ECP printer around. > >-- >\\ The mind's the standard \\ Mike Smith >\\ of the man. \\ msm...@freebsd.org >\\-- Joseph Merrick \\ msm...@cdrom.com > > > Nicholas -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! config(8) changes..
On Thu, Apr 29, 1999 at 10:26:48PM -0700, Mike Smith wrote: > >> In article <19990424190901.d3a791...@spinner.netplex.com.au>, >> Peter Wemm wrote: >> > This shouldn't cause much in the way of trouble, but it will complain >> > about old lint in your config files. That includes 'net/tty/bio/cam' >> > mask indicators, and 'vector xxxintr' as well as some of the wierder >> > workarounds for the poor 'options' parsing. >> > >> > So: things like: >> > device sio1 at isa? tty port "IO_COM2" tty irq 3 >> > become: >> > device sio1 at isa? port IO_COM2 irq3 >> >> What do you do about the "ppc" device? Formerly, it needed to be "net >> irq ..." if the "plip" device was going to be used, but "tty irq ..." >> otherwise. Which one did you pick? > >It needs to flip between one or both, but I can't raise Nicolas lately, >so I'm starting to fear that we're going to need a new maintainer. >That bites, given how well things were going. Someone who would help me driving ppbus, yes. I didn't have enough time last months. So, what are the next issues: - porting ppbus to newbus (especially irq managment) - fix ppc probe bugs with recent mainboards - sync -current and -stable - test plip in depth I think there is more to do with making ppbus more and more stable than bringing new capabilities to it yet. > >-- >\\ Sometimes you're ahead, \\ Mike Smith >\\ sometimes you're behind. \\ m...@smith.net.au >\\ The race is long, and in the \\ msm...@freebsd.org >\\ end it's only with yourself. \\ msm...@cdrom.com > > > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Printing is vvveeerrryyy slow
On Tue, Mar 02, 1999 at 11:32:51PM -0800, Thomas Dean wrote: > >I am running smp, 4.0-current, as of Mon Feb 15 03:34:29 PST 1999. > >Printing is very slow. I have a HP LaserJet III attached to lpt0. >Printing in the pcl, text, mode is slower than I expect. Printing in >the postscipt mode is extremely slow. A 30K postscript file has been >OVER 5 minutes and is not finished! > >>From dmesg: > >Probing for devices on the ISA bus: >sc0 on isa >sc0: VGA color <16 virtual consoles, flags=0x0> >atkbdc0 at 0x60-0x6f on motherboard >atkbd0 irq 1 on isa >psm0 irq 12 on isa >psm0: model Generic PS/2 mouse, device ID 0 >sio0 at 0x3f8-0x3ff irq 4 on isa >sio0: type 16550A >sio1 at 0x2f8-0x2ff irq 3 on isa >sio1: type 16550A >ppc0 at 0x378 irq 7 on isa >ppc0: PC87334 chipset (PS2/NIBBLE) in COMPATIBLE mode >lpt0: on ppbus 0 >lpt0: Interrupt-driven port >fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > Another clue: The National Semiconductors are tricky to configure and your parallel port chipset is one of them (moreover a recent one). Compare the boot detection (PS2/NIBBLE) with your BIOS settings. Try to change your BIOS settings and dump me your dmesg (with verbose output). You may also try to force the operating mode with ppc boot flags. See ppc(4) for more info about this. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: CALL FOR TESTERS of new ATA/ATAPI driver..
On Mon, Mar 01, 1999 at 10:21:05PM +0100, Søren Schmidt wrote: > > >Finally!! > >The much roumored replacement for our current IDE/ATA/ATAPI is >materialising in the CVS repositories around the globe. > >So what does this bring us: > >A new reengineered ATA/ATAPI subsystem, that tries to overcome >most of the deficiencies with the current drivers. > >It supports PCI as well as ISA devices without all the hackery >in ide_pci.c to make PCI devices look like ISA counterparts. What would you think of parallel port devices? Would it be easy to make the new ATAPI stuff work with ppbus? I especially think about the HP7200 CD-RW which has certainly hard real-time constraints to burn a CD. > >It doesn't have the excessive wait problem on probe, in fact you >shouldn't notice any delay when your devices are getting probed. > >Probing and attaching of devices are postponed until interrupts >are enabled (well almost, not finished yet for disks), making >things alot cleaner. Really good work. I'll give it a try this week-end. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel build failure at nfs_serv.c
On Wed, Feb 24, 1999 at 08:51:03AM +, Doug Rabson wrote: > >On Tue, 23 Feb 1999, Nicolas Souchu wrote: > >> Hi folks, >> >> Updating at Mar 23 fév 1999 22:52:33 CET, >> >> cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >> -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include >> -DKERNEL -DVM_STACK -include opt_global.h -elf ../../nfs/nfs_serv.c >> ../../nfs/nfs_serv.c:103: `sysctl__vfs_nfs_children' undeclared here (not in >> a function) >> ../../nfs/nfs_serv.c:103: initializer element for >> `sysctl___vfs_nfs_async.oid_parent' is not constant >> *** Error code 1 >> >> Stop. >> >> Any clue? > >I think this is fixed - try updating nfs_serv.c > World updated yesterday still fails in modules/nfs. Thanks for your help. Nicholas. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lpt0
On Tue, Feb 16, 1999 at 10:16:05PM -0700, Warner Losh wrote: > >In message <199902141331.faa27...@hub.freebsd.org> "Jonathan M. Bresler" >writes: >: how much information about this should be included in >: /usr/src/UPDATING? the entry there talks about the change but does >: not provide enough information to successfully upgrade (ppc0 is not >: mentioned, nor does it provide a pointer to where to go for more >: information.) ;( > >I'm about to commit a change to UPDATING to point to this URL and man >page. I'm just now catching up from being gone for a week. Thanks, I've update the web page since you refer to it in UPDATING. > >Warner > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
kernel build failure at nfs_serv.c
Hi folks, Updating at Mar 23 fév 1999 22:52:33 CET, cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h -elf ../../nfs/nfs_serv.c ../../nfs/nfs_serv.c:103: `sysctl__vfs_nfs_children' undeclared here (not in a function) ../../nfs/nfs_serv.c:103: initializer element for `sysctl___vfs_nfs_async.oid_parent' is not constant *** Error code 1 Stop. Any clue? -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Hold it! LINT / GENERIC inconsistency
On Sun, Feb 21, 1999 at 12:19:08PM +0100, Jeroen Ruigrok/Asmodai wrote: > >Anyone care to look at LINT and GENERIC and in particular at the ppc0 line? > >GENERIC lists ppc0 as a device, LINT as a controller. GENERIC wins. > >Since config accepts GENERIC's format I'm inclined to think that's the >correct one. But one of my own files has controller in it and is also >accepted, but I don't think we can mix device/controller lines with each >other, right? > >Someone care to enlighten me or update the appropriate files? I do it. Thanks for the report. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, Feb 14, 1999 at 07:41:25PM -0500, Brian Feldman wrote: > >On Sun, 14 Feb 1999, Nicolas Souchu wrote: > >> On Sun, Feb 14, 1999 at 04:30:27PM -0500, Brian Feldman wrote: >> >> >> > >> >On spd I would get an error message, and if I ever did spd 1 it got as far >> >as printing 128 bytes used, then erred out... >> > >> >> rm alpm.o ; make CC="cc -DDEBUG" >> > >> >I'll rm alpm.o; CC='cc -DDEBUG' make alpm.o; make, if that's what you mean. >> >> any difference? > >Yes: >Feb 14 17:12:16 green /kernel: alpm: idle? STS=0x0 >Feb 14 17:12:48 green last message repeated 380 times >Feb 14 17:13:14 green last message repeated 5 times > The controller seems to stick on the bus. The Linux team has reported such problems with there own driver and couldn't do anything (reset of controller, SMBus abort...). The problem seem to have disappeared with an additional device plugged on the bus. I'll dig into your problem, but yet, I have no problem with the ASUS. I'll browse the datasheets.. > >> >> -- >> nso...@teaser.fr / nso...@freebsd.org >> FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org >> >> To Unsubscribe: send mail to majord...@freebsd.org >> with "unsubscribe freebsd-current" in the body of the message >> > > Brian Feldman _ __ ___ ___ ___ > gr...@unixhelp.org _ __ ___ | _ ) __| \ >http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | > FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ > > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, Feb 14, 1999 at 11:09:45PM +0100, Nicolas Souchu wrote: > >On Sun, Feb 14, 1999 at 04:30:27PM -0500, Brian Feldman wrote: >>> >> >>On spd I would get an error message, and if I ever did spd 1 it got as far >>as printing 128 bytes used, then erred out... >> >>> rm alpm.o ; make CC="cc -DDEBUG" >> >>I'll rm alpm.o; CC='cc -DDEBUG' make alpm.o; make, if that's what you mean. > >any difference? I meant any difference between the two command lines? -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, Feb 14, 1999 at 04:30:27PM -0500, Brian Feldman wrote: >> > >On spd I would get an error message, and if I ever did spd 1 it got as far >as printing 128 bytes used, then erred out... > >> rm alpm.o ; make CC="cc -DDEBUG" > >I'll rm alpm.o; CC='cc -DDEBUG' make alpm.o; make, if that's what you mean. any difference? -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lpt0
On Sun, Feb 14, 1999 at 11:58:48AM -0800, Jordan K. Hubbard wrote: > >> The alternative is to just update GENERIC, LINT et al to use ppbus >> instead of the old lpt driver, and throw in a warning in the probe >> messages in src/sys/i386/lpt.c telling people to move to ppbus. It >> should be pretty safe. > >Now that I could live with. Are you up for that? Not better than the actual state, since I renamed nlpt to lpt today in -current, as wished by most of you. So, we should let it as is (nlpt+lpt) in 3.1. Anyway, 3.1 is stable and what is more stable than the old-lpt? > >- Jordan > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lpt0
On Sun, Feb 14, 1999 at 11:43:36AM -0800, Jordan K. Hubbard wrote: > >> Ok, we should keep lpt, but I'll need to sync ppbus before the release >> just to fix some bugs discovered by all these new testers. > >OK, better do it soon then! :) > >> BTW, I really don't know when 3.1 will be released. > >The tag goes down tonite (in approximately 7 hours) and the release is >tomorrow afternoon. Arg! I'll do the best and most wise. > >- Jordan > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Aladdin chipset SMBus support available!
On Mon, Feb 15, 1999 at 03:55:07AM +0900, takaw...@shidahara1.planet.sci.kobe-u.ac.jp wrote: > >>d2 found. > >I want to know about this address. SMBus in my motherboard will hang >up when I issue RECV_BYTE method for this port. It does not for me. It's supposed to be the address of a clock chip, isn't it? > >>> BTW, as outlined by -pkh all this is just a first step in a huge monitoring >>> adventure where all still need to be _defined_ (architecture and interfaces) >>> and implemented. Any proposition for doing the job is wellcome, >>> since I just have enough time to do the hardware SMBus support. >> >>Sounds like fun > >I think so too. >/dev/smb? should not be used in casual use,because it is dangerous,as >banging I/O port.I want to discuss about the interface. Where did he >wrote it? He wrote nothing, just: >>> Not to stop you in your tracks, but I would really love to see somebody (more capable than the PAO people) work out a power management architecture for us before we have too many more hacks in this area... Poul-Henning In message <199902131808.kaa79...@freefall.freebsd.org>, Nicolas Souchu writes: >nsouch 1999/02/13 10:08:35 PST > > Modified files: >share/man/man4 intpm.4 > Log: > Fix the date and add an smbus declaration > > Revision ChangesPath > 1.2 +3 -2 src/share/man/man4/intpm.4 > <<< -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lpt0
On Sun, Feb 14, 1999 at 09:58:39AM -0800, Jordan K. Hubbard wrote: > >> On Sat, Feb 13, 1999 at 07:36:37PM -0800, Jordan K. Hubbard wrote: >> > >> >FWIW, I would also like to see this happen. >> >> What's the deadline? I did it for -current this day. I'm waiting for >> some feedback before the 3.1 replica. > >Actually, subsequent discussions with Dag-Erling have sort of shown >this to have been rather too ambitious of me and now I've major second >thoughts. :( > >I think the number of changes involved in making the cut-over are just >too likely to hang us at the last minute, and that's nothing any of us >want. Any there any last cosmetic tie-ups of a less scary nature, or >are we good to go as-is in the 3.0 branch? Ok, we should keep lpt, but I'll need to sync ppbus before the release just to fix some bugs discovered by all these new testers. BTW, I really don't know when 3.1 will be released. > >- Jordan > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New print interface
On Sun, Feb 14, 1999 at 01:33:24PM -0500, Brian Feldman wrote: > >It says "generic" every time, whther or not there's a printer attached. Yes, fun isn't it? >lpt0: on ppbus 0 >lpt0: Interrupt-driven port >should be >lpt0: generic printer port on ppbus 0 >lpt0: Interrupt-driven port You certainly mean that only hardware shall be enclosed by <>s? But this how device driver boot info is handled in the new bus system. ppbus is for you guys anyway. You're bootverbose preferences will be mine until it remains homogeneous with the whole system. > > Brian Feldman _ __ ___ ___ ___ > gr...@unixhelp.org _ __ ___ | _ ) __| \ >http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | > FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ > > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, Feb 14, 1999 at 01:01:27PM -0500, Brian Feldman wrote:
[...]
>
>Sorta. It did work. Then it stopped working. Running detect seems to kill my
>SM (or at least reset it to some weird state)
>
>{"/home/green/examples"}$ ./detect
>{"/home/green/examples"}$
You mean you got some output from spd? Which? Try recompiling alpm.o with
DEBUG defined.
rm alpm.o ; make CC="cc -DDEBUG"
--
nso...@teaser.fr / nso...@freebsd.org
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: New print interface
On Sun, Feb 14, 1999 at 01:16:11PM -0500, Chuck Robey wrote: >> >ppc0 at 0x378 irq 7 drq 3 on isa >> >ppc0: SMC FDC37C665GT chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode >> >ppc0: FIFO with 16/16/15 bytes threshold >> >ppb0: IEEE1284 device found /NIBBLE/ECP >> >Probing for PnP devices on ppbus0: >> >ppbus0: MLC,PCL,PML >> >plip0: on ppbus 0 >> >lpt0: on ppbus 0 >> >lpt0: Interrupt-driven port >> >ppi0: on ppbus 0 >> >lppps0: on ppbus 0 >> > >> >Notice how the ppbus finds and correctly IDs my printer (yea!) but then >> >the lpt0 and ppi0 lines find generic ... this is a little odd, isn't it? >> >Even if the lpt0 and ppi0 parts are less intelligent, they should share >> >info to at least some degree, shouldn't they? >> >> i/o is generic here. > >If IO is generic, then printing the type of printer it finds is >meaningless, right? It's going to announce "generic" no matter what, >then it should stay silent, right? Better to say nothing than to get it >wrong every time, especially with the correct info sitting mere lines >above, advertising the mistake. ppi and lpt are really different. ppb probe and lpt too; and finally, ppb probe and ppi are quite different also ;) The ppbus architecture is made of an interface layer (ppc), a mid level (ppbus or ppb) and a device level (lpt, ppi, pps..). ppc does the chipset detection, here you have an SMC chipset, and properly configure it respecting the SMC datasheets. Not usual for a parallel port chip ;) It also detect ECP FIFO and test it. Then it calls the ppb level power_up routine. During ppb level power_up, the parallel port bus is probed, trying to find out an IEEE1284 device and only one (further developments could be made to find _every_ IEEE1284 devices daisy chain to the port, thanks to the IEEE1284-3 standard). IEEE1284 devices shall have an device_id feature that let the host retrieve identification info from them. This is referenced as the NIBBLE_ID mode. Once done, the ppb level initializes every device it knows about. lpt have been there before any IEEE1284 support. Actually, lpt _is_ the old lpt driver with machine-independent calls to the ppc interface and some request/release calls to the bus to allow bus sharing with a ZIP or what else. That's why lpt support is generic. No matter with the previous probe. IEEE1284 support is only a set of functions any device driver may call to take advantage of it. Actually, lpt uses it since recently. When you do a 'cat /dev/lpt0', it tries to negocition NIBBLE mode with the printer and fetch data if the peripheral has some. Yours doesn't seem to. But I'm not sure, since I know some peripherals fails to say they have/dont_have data to send. You should really dig into this with DEBUG_1284 option enabled. Since there are things specific and things that are not, I prefered to differenciate it in the past. But you're probably rigth, only this printer driver may ever exist. Look at the ppbus(4) architecture, the ppi code and tell me if I shall change the boot outputs. > >> >2nd note ... you said I should use lptcontrol -e. I did that, exactly, >> >and it came back to tell me that it had switched me to extended mode >> >(which I expected) AND to polled mode (which I neither expected nor >> >wanted). The man page says that only one action is taken at a time. I >> >was able to switch on the interrupt mode again (which I did want) by >> >using the -i switch (advertised correctly on the man page now) but isn't >> >this wrong, switching to polled mode like that on entering the -e? >> >> Hmm, yes. It is interrupt driven tough. > >Then the lptcontrol command should not announce, when you enter >'lptcontrol -e' that it's setting polled mode (which it did). If it's >still in interrupt mode (which is good) then it's fibbing to me, right? > I agree. But it was to simple ;) >> >> But, can you print with extended mode set?! > >I can't cat /dev/lpt0 and get any status. I did the lptcontrol -e, so I >*think* I;m in extended mode, and it *does* print. I guess I have to ^^ A! Try, DEBUG_1284 to see what happen with lpt read. >find out what I can buy to play with this further. I would like to have >some logic level outputs, so I can do some direct machine control, and >doing it via my printer port sounds cool. Know anything like that? > >Having my computer be my alarm clock would be neat. I have 5 different >wakeup times (because of odd class schedules) and that would, in fact, >be a real nice win. A better idea would be to do it with I2C. Which I also promote in FreeBSD ;) See http://www.freebsd.org/~nsouch/iicbus.html > > If true, imagine you use >> DMA+FIFO when printing! If not convinced, enable PPC_DEBUG when compiling >> i386/isa/ppc.c. > >OK, experimenting. > >What about 'cat /dev/lpt0' doing nothing? Am I doing that right? What >did you expect me to see, when you asked that? DEBUG_1284. -- nso...@teaser.fr / n
Re: New print interface
On Sun, Feb 14, 1999 at 12:48:56PM -0500, Chuck Robey wrote: >> But there's at least FIFO+DMA support in the nlpt driver. Try 'lptcontrol -e' >> with you BIOS configured to ECP. Recompile with the appropriate >> drq on the 'device ppc at isa?...' line. > >Experimentation mode (on a machine I can crash here if I need to now). >I stuck the drq 3 into the 'controller ppc0' line. BTW, since LINT was >changed, there's now no indication as to where to stick the dma channel >info, for users. Info is in the lpt(4) manpage. > >Anyhow, now my config looks like: > >controller ppc0at isa? port? tty irq 7 drq 3 >controller ppbus0 >device lpt0at ppbus? >device plip0 at ppbus? >device ppi0at ppbus? >device pps0at ppbus? Good. > >There are a couple of things that have happened that strike me as worthy >of comment. Here's my relevant dmesg part: > >ppc0 at 0x378 irq 7 drq 3 on isa >ppc0: SMC FDC37C665GT chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode >ppc0: FIFO with 16/16/15 bytes threshold >ppb0: IEEE1284 device found /NIBBLE/ECP >Probing for PnP devices on ppbus0: >ppbus0: MLC,PCL,PML >plip0: on ppbus 0 >lpt0: on ppbus 0 >lpt0: Interrupt-driven port >ppi0: on ppbus 0 >lppps0: on ppbus 0 > >Notice how the ppbus finds and correctly IDs my printer (yea!) but then >the lpt0 and ppi0 lines find generic ... this is a little odd, isn't it? >Even if the lpt0 and ppi0 parts are less intelligent, they should share >info to at least some degree, shouldn't they? i/o is generic here. > >2nd note ... you said I should use lptcontrol -e. I did that, exactly, >and it came back to tell me that it had switched me to extended mode >(which I expected) AND to polled mode (which I neither expected nor >wanted). The man page says that only one action is taken at a time. I >was able to switch on the interrupt mode again (which I did want) by >using the -i switch (advertised correctly on the man page now) but isn't >this wrong, switching to polled mode like that on entering the -e? Hmm, yes. It is interrupt driven tough. But, can you print with extended mode set?! If true, imagine you use DMA+FIFO when printing! If not convinced, enable PPC_DEBUG when compiling i386/isa/ppc.c. > >Last thing ... I did the 'cat /dev/lpt0' like you asked. No response >whatsoever, the prompt just came back. I did this both before and after >all the changes done with lptcontrol, each and every time, but the exact >same response, nothing. Like typing echo. No status. Something >incomplete yet? > >This isn't criticism, this is the feeling of a child at Christmas >opening new toys, but wondering if maybe there's more under the tree I >haven't quite spotted yet. > >+--- >Chuck Robey | Interests include any kind of voice or data >chu...@glue.umd.edu | communications topic, C programming, and Unix. >213 Lakeside Drive Apt T-1 | >Greenbelt, MD 20770 | I run picnic (FreeBSD-current) >(301) 220-2114 | and jaunt (Solaris7). >+--- > > > > > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, Feb 14, 1999 at 12:11:09PM -0500, Brian Feldman wrote:
>
>On Sun, 14 Feb 1999, Nicolas Souchu wrote:
>
>> On Sun, Feb 14, 1999 at 08:40:11AM -0500, Brian Feldman wrote:
>> >
>> >On Sun, 14 Feb 1999, Nicolas Souchu wrote:
>> >
>> >> On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote:
>> >> >
>> >> >On Sat, 13 Feb 1999, Nicolas Souchu wrote:
>> >> >
>> >> >> Example program to fetch temperature or voltages is available at
>> >> >> http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/
>> >> >> There's also an example program to fetch SDRAM info over the smbus.
>> >>
>> >> I attach you the detect.c program. It's very simple and may help us
>> >> in knowing what I2C hardware you have on your mobo.
>> >
>> >Where's my detect.c? I think you forgot to attach it :)
>>
>> :) here it is!
>
>alpm0: rev 0x00 on pci0.3.0
>alsmb0:
>smbus0: on alsmb0
>smb0: on smbus0
>
>{"/home/green/examples"}$ ./detect
>a2 found.
>d2 found.
So,
./spd 1
will work!
--
nso...@teaser.fr / nso...@freebsd.org
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: lpt0
On Sat, Feb 13, 1999 at 07:36:37PM -0800, Jordan K. Hubbard wrote: > >FWIW, I would also like to see this happen. What's the deadline? I did it for -current this day. I'm waiting for some feedback before the 3.1 replica. > >> On 13 Feb 1999, Dag-Erling Smorgrav wrote: >> >> > Nicolas Souchu writes: >> > > controller ppbus0 # The ppbus system >> > > device nlpt0 at ppbus? # The printer driver >> > >> > OBTW, when are you planning to rename nlpt0 to lpt0? >> >> Hopefully before 3.1 goes out...it would be a bummer to have one >> release with a different name than the rest; it confuses >> documentation that tries to cover multiple versions. >> >> -john >> I agree. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New print interface
On Sun, Feb 14, 1999 at 11:52:04AM -0500, Chuck Robey wrote: > >On Sun, 14 Feb 1999, Nicolas Souchu wrote: > >> >I *never* expected to see the PNP functions actually pick up the name of >> >my printer. I was economically bushwacked by the Windows corps into >> >buying the 693C (the version with the Windows software floppies tacked >> >on) so I was actually pleased that it ID'd the printer as the more >> >generic 690C (sans the Windows extortia). >> > >> >Very nice. The mistake I'd made earlier was in not knowing that the >> >config needed all 3 lines, not just some subset of 2 of them as I'd >> >guessed. >> > >> >Great job, Nicolas! >> >> BTW, try 'cat /dev/lpt0' ;) > >OK, I just cvsupped, I will quickly. There's a reference to setting a >drq for lpt, which isn't something I'd had to do before ... I guess >there's dma capability since I last looked at it, but how do I tell what >dma channel has been chosen for it? Will my bios set it for me, or is >it going to be probed somehow? How do I set it? I saw an example with >it set to 3, is that a default value (shall I experiment?) Your BIOS tells you the DMA channel your parallel port is configured to run with. Something like, device ppc0 at isa? port? tty irq 7 drq 3 should be ok if DMA channel is 3 in your BIOS ECP setting. It might be channel 1 though, then set drq to '1'. > >+--- >Chuck Robey | Interests include any kind of voice or data >chu...@glue.umd.edu | communications topic, C programming, and Unix. >213 Lakeside Drive Apt T-1 | >Greenbelt, MD 20770 | I run picnic (FreeBSD-current) >(301) 220-2114 | and jaunt (Solaris7). >+--- > > > > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
HEADS UP! nlpt removed, lpt still alive!
No, not a joke :) nlpt name was only a trick not to collide with lpt while both were in the system. As you noticed, the old isa lpt driver has been removed. Consequently, nlpt makes no more sense. This is I hope the last confusion about printing drivers... before the next one. So, here is one of the right declarations to get your printer working: controller ppbus0 device lpt0 at ppbus? device ppc0 at isa? port? tty irq 7 Please, read carefully the lpt(4) manpage. It's not long and will reveal you last lpt features. It's important for us to get feedback about all of this, since we'd like to rapidly move the changes to 3.1 before the jump. Have fun until the next time ;) -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New print interface
On Sat, Feb 13, 1999 at 10:03:41PM -0500, Chuck Robey wrote: > >I have to add an addendum here, to my previous question about the new >config file setup for a simple printer. I was looking forward to seeing >the probing come back to my dmesg, when I finally got it right, but >seeing this: > >Feb 13 14:02:01 picnic /kernel: ppc0 at 0x378 irq 7 on isa >Feb 13 14:02:01 picnic /kernel: ppc0: SMC FDC37C665GT chipset >(EPP/PS2/NIBBLE) in COMPATIBLE mode >Feb 13 14:02:01 picnic /kernel: ppb0: IEEE1284 device found /NIBBLE/ECP >Feb 13 14:02:01 picnic /kernel: Probing for PnP devices on ppbus0: >Feb 13 14:02:01 picnic /kernel: ppbus0: >MLC,PCL,PML >Feb 13 14:02:01 picnic /kernel: nlpt0: on ppbus 0 >Feb 13 14:02:01 picnic /kernel: nlpt0: Interrupt-driven port > >I *never* expected to see the PNP functions actually pick up the name of >my printer. I was economically bushwacked by the Windows corps into >buying the 693C (the version with the Windows software floppies tacked >on) so I was actually pleased that it ID'd the printer as the more >generic 690C (sans the Windows extortia). > >Very nice. The mistake I'd made earlier was in not knowing that the >config needed all 3 lines, not just some subset of 2 of them as I'd >guessed. > >Great job, Nicolas! BTW, try 'cat /dev/lpt0' ;) -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, Feb 14, 1999 at 08:40:11AM -0500, Brian Feldman wrote:
>
>On Sun, 14 Feb 1999, Nicolas Souchu wrote:
>
>> On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote:
>> >
>> >On Sat, 13 Feb 1999, Nicolas Souchu wrote:
>> >
>> >> Example program to fetch temperature or voltages is available at
>> >> http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/
>> >> There's also an example program to fetch SDRAM info over the smbus.
>>
>> I attach you the detect.c program. It's very simple and may help us
>> in knowing what I2C hardware you have on your mobo.
>
>Where's my detect.c? I think you forgot to attach it :)
:) here it is!
>
>> >I tried them, and there's the problem: all the ioctl()s they perform return
>> >EINTR! Has this driver been tested on many motherboards? Why should I expect
>> >an EINTR? Just wondering :)
>>
>> EINTR is odd. It just mean that the device at the address requested on the
>> I2C bus do not respond. I have to translate SMBus errors to the appropriate
>> unix ones.
>
>Hmm... wouldn't the appropriate error for something not responding be an
>ENXIO or ETIMEDOUT? EINTR seems more than a little wrong for this purpouse.
Fix committed.
BTW, as outlined by -pkh all this is just a first step in a huge monitoring
adventure where all still need to be _defined_ (architecture and interfaces)
and implemented. Any proposition for doing the job is wellcome,
since I just have enough time to do the hardware SMBus support.
Nicholas
--
nso...@teaser.fr / nso...@freebsd.org
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
/*-
* Copyright (c) 1999 Nicolas Souchu
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* [id for your version control system, if any]
*/
/*This program is prototype version. I'll write better one*/
#include
#include
#include
const double vfactor[]={1,1,1,1.67,4,-4,-1.67};
const char *Inpname[]={
"Vcore","Vit","VIO","+5V","+12V","-12V","-5V"
};
int doioctl(int alias, int cmd, caddr_t param)
{
int error = 1;
int retry = 3;
while (error && retry--) {
usleep(200);
error = ioctl(alias, cmd, param);
}
return (error);
}
int main (int argc,char argv[])
{
int alias, i;
unsigned char byte=0;
struct smbcmd cmd;
bzero(&cmd, sizeof(cmd));
cmd.data.byte_ptr = &byte;
alias = open("/dev/smb0", O_RDWR);
for (i=2; i<254; i+=2)
{
cmd.slave=(u_char)i;
if(doioctl(alias, SMB_RECVB, (caddr_t)&cmd)!=-1){
printf("%x found.\n",i);
}
}
close(alias);
return 0;
}
Re: lpt0
On Sun, Feb 14, 1999 at 05:31:08AM -0800, Jonathan M. Bresler wrote: > >> Date: Sat, 13 Feb 1999 19:17:14 +0100 >> From: Nicolas Souchu >> >> You need: >> >> controller ppbus0 # The ppbus system >> device nlpt0 at ppbus? # The printer driver >> >> And finally the parallel port chipset interface, >> >> controller ppc0at isa? port? tty irq 7 drq 3 >> >> See ppbus(4) and/or http://www.freebsd.org/~nsouch/ppbus.html for more info >> about the ppbus architecture. > > how much information about this should be included in > /usr/src/UPDATING? the entry there talks about the change but does > not provide enough information to successfully upgrade (ppc0 is not > mentioned, nor does it provide a pointer to where to go for more > information.) ;( Sorry, your efforts are lost. I've just renamed nlpt to lpt. But I've properly updated lpt.4, I think. You may just add, the minimal configuration and point to the manpage for further details. Something like: >>> Now the lpt driver, previously named nlpt in the ppbus system not to collide with the original isa/lpt.c functions, shall be declared with: controller ppbus0 device lpt0 at ppbus? controller ppc0 at isa? port "IO_LPT1" tty irq 7 The ppc(4) driver is the ISA parallel port interface driver. The ppbus(4) controller stands for the whole ppbus system code. And finally, you have lpt(4). <<< > >jmb > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Aladdin chipset SMBus support available!
On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote: > >On Sat, 13 Feb 1999, Nicolas Souchu wrote: > >> Hi folks, >> >> I've just committed the alpm(4) driver to -current: the Aladdin SMBus >> driver. > >Great, my newest mobo is an AcerLabs. > >> >> With an onboard system management chip (lm7x or w87381), >> it offers monitoring capabilities to recent Acer based motherboards like >> the ASUS P5AB. > >I'm using a matsonic. > >> >> Example program to fetch temperature or voltages is available at >> http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/ >> There's also an example program to fetch SDRAM info over the smbus. I attach you the detect.c program. It's very simple and may help us in knowing what I2C hardware you have on your mobo. > >I tried them, and there's the problem: all the ioctl()s they perform return >EINTR! Has this driver been tested on many motherboards? Why should I expect >an EINTR? Just wondering :) EINTR is odd. It just mean that the device at the address requested on the I2C bus do not respond. I have to translate SMBus errors to the appropriate unix ones. > > >> >> You may also want to know what smbus(4) is: >> http://www.freebsd.org/~nsouch/iicbus.html >> >> Feedbacks are wellcome. >> >> Nicholas. >> >> PS: A driver is also available for the Intel PIIX4, see intpm(4). >> >> -- >> nso...@teaser.fr / nso...@freebsd.org >> FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org >> >> To Unsubscribe: send mail to majord...@freebsd.org >> with "unsubscribe freebsd-current" in the body of the message >> > > Brian Feldman _ __ ___ ___ ___ > gr...@unixhelp.org _ __ ___ | _ ) __| \ >http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | > FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ > > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lpt0
On Sat, Feb 13, 1999 at 08:04:12PM +0100, Dag-Erling Smorgrav wrote: > >Nicolas Souchu writes: >> controller ppbus0 # The ppbus system >> device nlpt0 at ppbus? # The printer driver > >OBTW, when are you planning to rename nlpt0 to lpt0? Today. > >DES >-- >Dag-Erling Smorgrav - d...@flood.ping.uio.no > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New print interface
On Sat, Feb 13, 1999 at 10:03:41PM -0500, Chuck Robey wrote: > >I have to add an addendum here, to my previous question about the new >config file setup for a simple printer. I was looking forward to seeing >the probing come back to my dmesg, when I finally got it right, but >seeing this: > >Feb 13 14:02:01 picnic /kernel: ppc0 at 0x378 irq 7 on isa >Feb 13 14:02:01 picnic /kernel: ppc0: SMC FDC37C665GT chipset >(EPP/PS2/NIBBLE) in COMPATIBLE mode >Feb 13 14:02:01 picnic /kernel: ppb0: IEEE1284 device found /NIBBLE/ECP >Feb 13 14:02:01 picnic /kernel: Probing for PnP devices on ppbus0: >Feb 13 14:02:01 picnic /kernel: ppbus0: >MLC,PCL,PML >Feb 13 14:02:01 picnic /kernel: nlpt0: on ppbus 0 >Feb 13 14:02:01 picnic /kernel: nlpt0: Interrupt-driven port > >I *never* expected to see the PNP functions actually pick up the name of >my printer. I was economically bushwacked by the Windows corps into >buying the 693C (the version with the Windows software floppies tacked >on) so I was actually pleased that it ID'd the printer as the more >generic 690C (sans the Windows extortia). > >Very nice. The mistake I'd made earlier was in not knowing that the >config needed all 3 lines, not just some subset of 2 of them as I'd >guessed. > >Great job, Nicolas! Not finished. ECP is not supported yet. I'm glad to see the 690C is ECP compliant. I bougth an HP6L, thinking it was :( But there's at least FIFO+DMA support in the nlpt driver. Try 'lptcontrol -e' with you BIOS configured to ECP. Recompile with the appropriate drq on the 'device ppc at isa?...' line. > >+--- >Chuck Robey | Interests include any kind of voice or data >chu...@glue.umd.edu | communications topic, C programming, and Unix. >213 Lakeside Drive Apt T-1 | >Greenbelt, MD 20770 | I run picnic (FreeBSD-current) >(301) 220-2114 | and jaunt (Solaris7). >+--- > > > > > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lpt0
You need: controller ppbus0 # The ppbus system device nlpt0 at ppbus? # The printer driver And finally the parallel port chipset interface, controller ppc0at isa? port? tty irq 7 drq 3 See ppbus(4) and/or http://www.freebsd.org/~nsouch/ppbus.html for more info about the ppbus architecture. On Sat, Feb 13, 1999 at 01:11:25PM -0500, Chuck Robey wrote: > >Recently I noticed that lpt0 has been replaced by the ppbus stuff, in >LINT. The problem is, I can't find any example as to how to set it up >for a plain, vanilla printer ppbus has so many more capabilities >than lp, I think it's embarrassed about it's dowdy origins. I don't >know what controller to use (ppbus0 or maybe ppc0?) and the old device, >lpt0, doesn't even exist in LINT anymore. > >I tried picking up the lines for ppbus0 and nlpt, which I guessed might >be right, from LINT, and dropping them into my config file. They >compile fine, but nothing is probed (my dmesg shows no printer) and I >can't print. > >What's the right setup for a plain, ordinary IRQ 7 printer port? >Please, don't answer if you're going to talk about connecting some >parallel interfaced thing like a zip drive. I can't seem to find any >docs on this, nor any mail messages (nothing in UPDATING either). There >is much discussion about things like zip drive connecting, though ... > >+--- >Chuck Robey | Interests include any kind of voice or data >chu...@glue.umd.edu | communications topic, C programming, and Unix. >213 Lakeside Drive Apt T-1 | >Greenbelt, MD 20770 | I run picnic (FreeBSD-current) >(301) 220-2114 | and jaunt (Solaris7). >+--- > > > > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Aladdin chipset SMBus support available!
Hi folks, I've just committed the alpm(4) driver to -current: the Aladdin SMBus driver. With an onboard system management chip (lm7x or w87381), it offers monitoring capabilities to recent Acer based motherboards like the ASUS P5AB. Example program to fetch temperature or voltages is available at http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/ There's also an example program to fetch SDRAM info over the smbus. You may also want to know what smbus(4) is: http://www.freebsd.org/~nsouch/iicbus.html Feedbacks are wellcome. Nicholas. PS: A driver is also available for the Intel PIIX4, see intpm(4). -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ppbus0: MEDIA CPIA_1-20
On Wed, Feb 03, 1999 at 02:15:39AM +, Stephen Palmer wrote: > >While looking at the output from dmesg, I noticed the following >which I don't remember having seen before. (Of course I might >not have had the camera hooked up to this system while running >FreeBSD before ;-) Sure, this is really new. > >Probing for PnP devices on ppbus0: >ppbus0: MEDIA CPIA_1-20 What it means: the parallel port bus system - ppbus - probes the parallel port in order to detect eventually an IEEE1284 (parallel port standard released in 1994) compliant device. So your camera is IEEE1284 compliant because ppbus could enter the NIBBLE-get_device_id mode and retrieve PnP info from it. The line before tells you something like "IEEE1284 device found..." with the available IEEE1284 modes supported by your device. > >This is actualy a "Zoom/Video Cam PPC" which I use under Win98 >from time to time. Any chance of getting working images from >this device under FreeBSD-current? How would I go about this? The link protocol is supported by FreeBSD, this is what the IEEE1284 stuff is for. But you'll also need info about higher protocols of the device to drive it correctly. (1) The device is really simple and a 'cat' from the parallel port in any of the supported modes is enough. That would suppose the camera dumps pictures to the port as they are captured. Of course, you should guess the format. This is the case with printers supporting IEEE1284: cat /dev/lpt0 gives printer info (READY, OUT OF PAPER...). If NIBBLE mode is supported by your device, which is not certain if I remember well your logs, you can try cat /dev/lpt0. Otherwise we'll have to hack ppi(4) to give it a try.. (2) The device is more complicated and an analyser under windows may give you the magic sequence to enter plain reverse mode to retrieve pictures as they are captured. > >This system is not currently very current (Jan 14, 1999 / no pun >intended) but I'm cvsup'ing as I type this... > >Stephen L. Palmer >slpal...@netscape.net > Nicholas. > > >More than just email--Get your FREE Netscape WebMail account today at >http://home.netscape.com/netcenter/mail > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How do I query system temperature probes ?
On Wed, Feb 03, 1999 at 02:51:37PM +1030, Matthew Thyer wrote: > >I seem to have all the hardware required for querying the temperature >probes in the system (At least I can do it from the BIOS). > >How can I query this info ? > >I assume I need "controller smbus0" and "controller intpm0" in my >kernel. But do I also need "device smb0 at smbus?" and/or any >of the following: > ># ici2c network interface ># iic i2c standard io ># iicsmb i2c to smb bridge. Allow i2c i/o with smb commands. You need: controller intpm0 # the PIIX4 interface controller smbus0 # the SMBus system device smb0 at smbus? # user access to the SMBus > > >Once I have all this stuff in my kernel, what commands do I use to >query the probes ?? Takanori Watanabe as example code to do this. > >My system is FreeBSD 4.0-CURRENT (of CTM 3722 - but will soon be really >-CURRENT) > > >Extract from dmesg: > >chip0: rev 0x03 on >pci0.0.0 >chip1: rev 0x03 on >pci0.1.0 >chip2: rev 0x01 on pci0.7.0 >ide_pci0: rev 0x01 on pci0.7.1 >chip3: rev 0x01 on pci0.7.3 >-- > Matthew Thyer Phone: +61 8 8259 7249 > Corporate Information Systems Fax:+61 8 8259 5537 > Defence Science and Technology Organisation, Salisbury > PO Box 1500 Salisbury South Australia 5108 > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: PLIP code giving funny logs...
On Sat, Jan 23, 1999 at 02:59:22PM +0200, Mark Murray wrote: > >Hi > >I het a lot of this in my PLIP connection: > >Jan 23 14:44:00 gratis /kernel: X >Jan 23 14:44:00 gratis /kernel: X >Jan 23 14:44:01 gratis /kernel: RR >Jan 23 14:44:01 gratis /kernel: RR >Jan 23 14:44:02 gratis /kernel: X^RRR&RX^R >Jan 23 14:44:02 gratis /kernel: X^RRR&RX^R > >Seems that in src/sys/dev/ppbus/if_plip.c there is > >#ifndef DEBUG >#define DEBUG >#endif > >Is this really necessary? What do the letters actually mean? An error occured, timeout, incorrect handshake.. It was intended to catch potential problems of the plip driver. I should remove it now. Thanks for your note. > >M >-- >Mark Murray >Join the anti-SPAM movement: http://www.cauce.org > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > Nicholas. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: softupdates bug shows on zip drive and parallel port in NIBBLE mode
On Sat, Jan 23, 1999 at 01:34:40AM -0500, Mikhail Teterin wrote: > >I tried both cam and bio -- no difference. It is not that it's >slow -- I was prepared for that, it is that it totally hangs -- >forever. > >I narrowed it down to softupdates. If I disable the softupdates on >the cartridge's filesystem copying finishes successfully. Somehow >the `cp' process takes 150% of the CPU time (purely single CPU system), >but that's a different story, I guess. The drive is polling-capable only. So it makes no difference with the cam/bio configuration. And it explains your performance result. > >I hope, this sad experience of mine will help further improve >softupdates. Thanks. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ZIP+ detection, need testers for the patch
On Sat, Jan 16, 1999 at 06:49:25PM +, Doug Rabson wrote: > >On Sat, 16 Jan 1999, Nicolas Souchu wrote: > >> On Fri, Jan 15, 1999 at 11:13:09AM +, Doug Rabson wrote: >> > >> >On Fri, 15 Jan 1999, Nicolas Souchu wrote: >> > >> >> Hi there, >> >> >> >> Currently, the ZIP+ probe is intrusive and sends char to the printer if >> >> no ZIP+ is connected. >> >> >> >> Here is a patch that corrects the problem for my printer, but I haven't >> >> any ZIP+ :) >> >> >> >> So, please check the ZIP+ is still detected. >> > >> >With this patch, I can *not* detect my ZIP+ (attached to a machine which >> >detects it using the existing code). >> >> Ok :( >> >> Does the last ppbus committed code (with IEEE1284 support) detects your >> ZIP+ at boot? Something like "IEEE1284 device found /NIBBLE..." with >> its id 2 lines after? This may be another way to detect properly the ZIP+ > >Afraid not :-(. The ppb_1284_negociate fails with an error of >PPB_NOT_IEEE1284. I haven't tried using the PERIPH_1284 option which >seems to affect the negotiation - is it worth trying? No. PERIPH_1284 should allow a computer to act as a IEEE1284 compliant peripheral when connected to another computer. > >P.S. The correct spelling is 'negotiate'. I keep wanting to do a >global-replace :-) Now, everybody on -current knows it :) I'm burned, as we say here. > >-- >Doug RabsonMail: d...@nlsystems.com >Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ZIP+ detection, need testers for the patch
On Fri, Jan 15, 1999 at 11:13:09AM +, Doug Rabson wrote: > >On Fri, 15 Jan 1999, Nicolas Souchu wrote: > >> Hi there, >> >> Currently, the ZIP+ probe is intrusive and sends char to the printer if >> no ZIP+ is connected. >> >> Here is a patch that corrects the problem for my printer, but I haven't >> any ZIP+ :) >> >> So, please check the ZIP+ is still detected. > >With this patch, I can *not* detect my ZIP+ (attached to a machine which >detects it using the existing code). Ok :( Does the last ppbus committed code (with IEEE1284 support) detects your ZIP+ at boot? Something like "IEEE1284 device found /NIBBLE..." with its id 2 lines after? This may be another way to detect properly the ZIP+ Nicholas. > >-- >Doug RabsonMail: d...@nlsystems.com >Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > > -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
