Re: contigmalloc + contigfree = memory leak?
Oops, I'm sorry for the self-reply. Just found a highly helpful thread
posted from 11th (`contigfree, free what?'), so please disregard my
message.
/me bonks his head against a wall that says `mea culpa'
Thanks,
Eugene
On Tue, Oct 16, 2001 at 02:42:17PM +0900, Eugene M. Kim wrote:
>
>
> Greetings,
>
> QUESTION:
> Does contigfree() really free up memory allocated using contigmalloc()?
>
> BACKGROUND:
> I've been trying to make up a kmod that allocates/deallocates memory in
> a specific physical address range. Mike Smith suggested using busdma
> functions to do the job, so I followed it.
>
> After allocating and deallocating memory several times, it seemed that
> bus_dmamem_free() was not freeing the memory properly. I looked at
> busdma_machdep.c where bus_dmamem_free() was defined, and found:
>
> void
> bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, bus_dmamap_t map)
> {
> /*
> * dmamem does not need to be bounced, so the map should be
> * NULL
> */
> if (map != NULL)
> panic("bus_dmamem_free: Invalid map freed\n");
> /* XXX There is no "contigfree" and "free" doesn't work */
> if ((dmat->maxsize <= PAGE_SIZE) && dmat->lowaddr >= ptoa(Maxmem))
> free(vaddr, M_DEVBUF);
> }
>
> However, there *is* contigfree() and a related patch was applied on
> -current around August, so I did the same thing (adding an else clause
> to call contigfree(vaddr, dmat->maxsize, M_DEVBUF)).
>
> It didn't solve the memory leak problem either, so I'm stuck here...
>
> Could anyone shed a light on this?
>
> Regards,
> Eugene
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
contigmalloc + contigfree = memory leak?
Greetings,
QUESTION:
Does contigfree() really free up memory allocated using contigmalloc()?
BACKGROUND:
I've been trying to make up a kmod that allocates/deallocates memory in
a specific physical address range. Mike Smith suggested using busdma
functions to do the job, so I followed it.
After allocating and deallocating memory several times, it seemed that
bus_dmamem_free() was not freeing the memory properly. I looked at
busdma_machdep.c where bus_dmamem_free() was defined, and found:
void
bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, bus_dmamap_t map)
{
/*
* dmamem does not need to be bounced, so the map should be
* NULL
*/
if (map != NULL)
panic("bus_dmamem_free: Invalid map freed\n");
/* XXX There is no "contigfree" and "free" doesn't work */
if ((dmat->maxsize <= PAGE_SIZE) && dmat->lowaddr >= ptoa(Maxmem))
free(vaddr, M_DEVBUF);
}
However, there *is* contigfree() and a related patch was applied on
-current around August, so I did the same thing (adding an else clause
to call contigfree(vaddr, dmat->maxsize, M_DEVBUF)).
It didn't solve the memory leak problem either, so I'm stuck here...
Could anyone shed a light on this?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
>-Original Message- >From: Andrew C. Hornback [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 15, 2001 2:59 PM >To: Doug Hass; Ted Mittelstaedt >Cc: Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED]; Alfred Shippen >Subject: RE: FYI > > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass >> Sent: Monday, October 15, 2001 9:53 AM >> To: Ted Mittelstaedt >> Cc: Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; >> [EMAIL PROTECTED]; Alfred Shippen >> Subject: RE: FYI >> >> > And if you want to sell these to FreeBSD users then make your >> Linux driver >> > source (not the SAND stuff) available so that we can mod it into our own >> > driver. Many other companies do this and as a matter of fact, >> we (meaning >> > FreeBSD) have even found bugs in crummy Linux drivers that have >> been reported >> > back to Linux and helped those manufacturers better their products. >> >> I'm not going to get dragged into an OS war. Both Linux and FreeBSD >> have their share of "crummy" drivers and features. That discussion is >> honestly beyond the scope of a discussion of ImageStream's SAND >> architecture and the WANic 400 series. > > I don't believe Ted was trying to start an OS war, he's not >that petty of a >person. been there, done that. :-) No, it's not an OS war, just trying to illustrate why making source available is a Good Thing. His point, and I hope that I'm not reading this incorrectly, is >that FreeBSD not only has fixed problems with drivers released by hardware >vendors, but also with drivers given over to "us" by the Linux group, as >that was all that we had to work with when the hardware vendors have refused >to provide any help whatsoever. > correct. >[snip] > >> > No offense, but once Imagestream stopped selling WANic400's you >> > ceased being an entity of interest to FreeBSD, as you no longer sell >> > any products that run under it. >> >> I'll reiterate what I've said to you privately: ImageStream DID NOT make >> the decision to discontinue the 400 series or the RISCom/N2 series. This >> decision rested solely with SBS. >> >> However, FreeBSD users are NOT without options: >> >> 1) FreeBSD users can still get the WANic 400 and RISCom cards from the >> second hand market, as another person mentioned. > > What is wrong with THIS picture? You're telling people to >purchase used >hardware, instead of purchasing components from your company? *shakes his >head* > I'll point out that the "1000 cards closed out" is not "used" hardware, it's brand new stuff that's never been opened. This is quite common in the hardware industry. The difficulty is finding out who that highest bidder was and if they are going to use those 1000 cards for themselves or are going to sell them off in dribs and drabs over the next 10 years. >> 2) WANic 400 series cards are still available in quantity. If the market >> for FreeBSD is as large as you claim, then you or someone else in the >> community should have no problem snapping up a quantity of these cards and >> reselling them to interested parties. I'll go one step further: If anyone >> contacts me about the WANic 400 series, mentions that they are for >> FreeBSD, I promise to give an extra 15% discount over and above our normal >> volume discounts just to illustrate my desire to support the FreeBSD >> community. > > Perhaps a better idea, if I may be so bold, would be to offer >samples of >the newer cards (520 series, I believe they are) to FreeBSD developers >interested in producing drivers, software and utilities for these cards. >After all, you are saying that the 400 is EOL. Wouldn't the idea of >engineering samples be more beneficial to all involved? > Just about every hardware vendor is happy to provide samples to developers, anyone working on this would get plenty of support. >> 3) Virtually ALL of our customers, save for OEMs making their own >> products, purchase complete routers. Going this route would eliminate the >> need to have FreeBSD support, as any user would have a standalone router. > > This sounds quite argumentative to me. Simply because >everyone else is >buying a router, there's a refusal to support FreeBSD, since people with >"true routers" would have no need for using FreeBSD as a router engine. > No company is going to support a product that has no market, and it's reasonable to ask who would buy these cards since Cisco's are so cheap on the seconds market. > It's a vicious cycle that I believe we're seeing here... >chicken and the >egg, or rather, the driver and the market. Without a proper driver, there >won't be a market for this card to be used with FreeBSD. However, without >the manufacturer seeing visability in this market, there won't be a driver >as it would be a waste of their developers time. > This is the truth for commercial projects. Open Source drivers, on the other hand, operate somewhat differently
Re: Network Startup
On Mon, Oct 15, 2001 at 09:20:17PM -0500, Dan Nelson wrote:
> > That's a bit of a problem as far as I'm concerned. Perhaps the network
> > scripts should be redesigned in a similar manner to the one taken on be
> > RedHat.
>
> Of course, you can always run the equivalent commands yourself to get
> the system in synch with what you put in rc.conf. i.e. if you added an
> alias ip to an interface, you can run
>
> ifconfig xxx inet 1.2.3.4 alias
Oh, for sure. That's what I, and the majority of the community, do
now. I think that it's not particularly convenient if you want to
restart the network if you've got 3 or 4 network interfaces.
> > I started playing around with such a thing, using usr/local/etc/rc.d/
> > as a base for 'network' scripts which take arguments such as 'start',
> > 'stop' and 'restart'.
> >
> > Implementation of such a thing would be fairly trivial methinks. What
> > are the thoughts on this sort of approach to management of network
> > interfaces and ancillary services?
>
> Is it smart enough to only add the alias interface on "restart", or
> does it try to deconfigure the whole NIC, and add all the IPs back?
I've only gone as far as nuking the entire interface and bringing it all
up again, including the alias. I've not tested the time difference
between doing it the way it current does, and being 'smart' (as you
say), and only configure the alias.
However, if someone issues 'sh network.sh restart', I'd expect just that
to happen -- the entire network to be restarted, not bits of it.
Similarly, if I was to issue 'sh network.sh start rl0', I'd expect it to
start the interface from scratch. Perhaps there is room there for some
'smartness' whereby the ifconfig commands are only issued if the current
interface configuration is different to that in the configuration file.
> How about if you change an IP number? Is it smart enough to kill and
> restart named, inetd, smbd, or any other programs that might have bound
> to that IP? It's not as simple as "I'll just rerun the ifconfig
> commands", and I stand by "reboot is the only sure way" :)
Perhaps it could be. For services that are controlled by
/usr/local/etc/rc.d/*.sh, it mightn't be that hard. Control of inetd,
named, smbd, or anything like that could also be done by a
/usr/local/etc/rc.d/*.sh file.
I can see this entire issue of startup scripts will spiral quickly into
a larger task if it was decided that there needed to be a change in the
way that the activity of other daemons such as inetd, named et al. were
controlled. Then again, I don't consider such a change as a "bad thing".
- andrew
--
void signature () {
cout << "Andrew Reid -- [EMAIL PROTECTED]" << endl;
cout << "Cell: +61 401 946 813" << endl;
cout << "Quidquid latine dictum sit, altum viditur" << endl;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Network Startup
In the last episode (Oct 16), Andrew Reid said: > On Mon, Oct 15, 2001 at 04:22:21PM -0500, Dan Nelson wrote: > > In the last episode (Oct 15), j balan said: > > > Does anyone know the command to reload rc.conf > > > > 'reboot' is the only sure way. > > That's a bit of a problem as far as I'm concerned. Perhaps the network > scripts should be redesigned in a similar manner to the one taken on be > RedHat. Of course, you can always run the equivalent commands yourself to get the system in synch with what you put in rc.conf. i.e. if you added an alias ip to an interface, you can run ifconfig xxx inet 1.2.3.4 alias > I started playing around with such a thing, using usr/local/etc/rc.d/ > as a base for 'network' scripts which take arguments such as 'start', > 'stop' and 'restart'. > > Implementation of such a thing would be fairly trivial methinks. What > are the thoughts on this sort of approach to management of network > interfaces and ancillary services? Is it smart enough to only add the alias interface on "restart", or does it try to deconfigure the whole NIC, and add all the IPs back? How about if you change an IP number? Is it smart enough to kill and restart named, inetd, smbd, or any other programs that might have bound to that IP? It's not as simple as "I'll just rerun the ifconfig commands", and I stand by "reboot is the only sure way" :) -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Network Startup
On Mon, Oct 15, 2001 at 04:22:21PM -0500, Dan Nelson wrote:
> In the last episode (Oct 15), j balan said:
> > Does anyone know the command to reload rc.conf
>
> 'reboot' is the only sure way.
That's a bit of a problem as far as I'm concerned. Perhaps the network
scripts should be redesigned in a similar manner to the one taken on be
RedHat.
I started playing around with such a thing, using /usr/local/etc/rc.d/
as a base for 'network' scripts which take arguments such as 'start',
'stop' and 'restart'.
Implementation of such a thing would be fairly trivial methinks. What
are the thoughts on this sort of approach to management of network
interfaces and ancillary services?
- andrew
--
void signature () {
cout << "Andrew Reid -- [EMAIL PROTECTED]" << endl;
cout << "Cell: +61 401 946 813" << endl;
cout << "Quidquid latine dictum sit, altum viditur" << endl;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
> > 1) FreeBSD users can still get the WANic 400 and RISCom cards from the > > second hand market, as another person mentioned. > > What is wrong with THIS picture? You're telling people to purchase used > hardware, instead of purchasing components from your company? *shakes his > head* Perhaps you missed the earlier post. Someone posted about purchasing used gear or auction gear to "go it on the cheap" so to speak. Personally, I think wasting money on used, out-of-warranty, unsupported gear is akin to playing Russian Roulette with your money. I'd buy new every time. > > > 2) WANic 400 series cards are still available in quantity. If the market > > for FreeBSD is as large as you claim, then you or someone else in the > > community should have no problem snapping up a quantity of these cards and > > reselling them to interested parties. I'll go one step further: If anyone > > contacts me about the WANic 400 series, mentions that they are for > > FreeBSD, I promise to give an extra 15% discount over and above our normal > > volume discounts just to illustrate my desire to support the FreeBSD > > community. > > Perhaps a better idea, if I may be so bold, would be to offer samples of > the newer cards (520 series, I believe they are) to FreeBSD developers > interested in producing drivers, software and utilities for these cards. > After all, you are saying that the 400 is EOL. Wouldn't the idea of > engineering samples be more beneficial to all involved? Those have ALWAYS been available. My phone rings all day. I pick it up, and it's never a BSD developer wanting to order cards and port drivers. :-) All you have to do is ask. Driver source, demo cards, and development tools have been available to the BSD community since 1995. To date, only BSDI took up the effort, and only briefly. Where are all the FreeBSD developers and why aren't they beating down my door for these samples and code? I'll get back to this in a minute. > > 3) Virtually ALL of our customers, save for OEMs making their own > > products, purchase complete routers. Going this route would eliminate the > > need to have FreeBSD support, as any user would have a standalone router. > > This sounds quite argumentative to me. Simply because everyone else is > buying a router, there's a refusal to support FreeBSD, since people with > "true routers" would have no need for using FreeBSD as a router engine. Nope--it's just a matter of laying out the options. There are 4--buy used, buy new in quantity, and buy routers. You can also develop drivers for the "new" cards (they aren't new--they've been out for 3 years). > It's a vicious cycle that I believe we're seeing here... chicken and the > egg, or rather, the driver and the market. Without a proper driver, there > won't be a market for this card to be used with FreeBSD. However, without > the manufacturer seeing visability in this market, there won't be a driver > as it would be a waste of their developers time. It's not a vicious cycle at all. Ted has said repeatedly in earlier e-mails that there is a large market for the 400/405 and that discontinuing them was foolish. I've actually proposed a solution that solves both problems. I'll recap for those who missed my earlier message: 1) If the *BSD community has the 400 series cards in such high demand, someone should step up and order them in quantity. This solves the issue with the cards not being available in one and two unit quantities. You'll have a ready supply from someone in the community, and you'll be supporting the community when you buy the cards from them. 2) If someone from the FreeBSD community orders the cards, ImageStream will put up a minimum of $8,100 for a developer or developer group to port drivers for the rest of the cards. Actually, it's 15% of the purchase price of any 400 series cards. The more "in demand" the current cards are, the more money we'll pledge to make sure that FreeBSd drivers exist for ALL of the cards. My phone number is below. If these cards and the future of the drivers are as important as everyone who has posted says they are, let's move quickly toward a solution. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass > Sent: Monday, October 15, 2001 9:53 AM > To: Ted Mittelstaedt > Cc: Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Alfred Shippen > Subject: RE: FYI > > > And if you want to sell these to FreeBSD users then make your > Linux driver > > source (not the SAND stuff) available so that we can mod it into our own > > driver. Many other companies do this and as a matter of fact, > we (meaning > > FreeBSD) have even found bugs in crummy Linux drivers that have > been reported > > back to Linux and helped those manufacturers better their products. > > I'm not going to get dragged into an OS war. Both Linux and FreeBSD > have their share of "crummy" drivers and features. That discussion is > honestly beyond the scope of a discussion of ImageStream's SAND > architecture and the WANic 400 series. I don't believe Ted was trying to start an OS war, he's not that petty of a person. His point, and I hope that I'm not reading this incorrectly, is that FreeBSD not only has fixed problems with drivers released by hardware vendors, but also with drivers given over to "us" by the Linux group, as that was all that we had to work with when the hardware vendors have refused to provide any help whatsoever. [snip] > > No offense, but once Imagestream stopped selling WANic400's you > > ceased being an entity of interest to FreeBSD, as you no longer sell > > any products that run under it. > > I'll reiterate what I've said to you privately: ImageStream DID NOT make > the decision to discontinue the 400 series or the RISCom/N2 series. This > decision rested solely with SBS. > > However, FreeBSD users are NOT without options: > > 1) FreeBSD users can still get the WANic 400 and RISCom cards from the > second hand market, as another person mentioned. What is wrong with THIS picture? You're telling people to purchase used hardware, instead of purchasing components from your company? *shakes his head* > 2) WANic 400 series cards are still available in quantity. If the market > for FreeBSD is as large as you claim, then you or someone else in the > community should have no problem snapping up a quantity of these cards and > reselling them to interested parties. I'll go one step further: If anyone > contacts me about the WANic 400 series, mentions that they are for > FreeBSD, I promise to give an extra 15% discount over and above our normal > volume discounts just to illustrate my desire to support the FreeBSD > community. Perhaps a better idea, if I may be so bold, would be to offer samples of the newer cards (520 series, I believe they are) to FreeBSD developers interested in producing drivers, software and utilities for these cards. After all, you are saying that the 400 is EOL. Wouldn't the idea of engineering samples be more beneficial to all involved? > 3) Virtually ALL of our customers, save for OEMs making their own > products, purchase complete routers. Going this route would eliminate the > need to have FreeBSD support, as any user would have a standalone router. This sounds quite argumentative to me. Simply because everyone else is buying a router, there's a refusal to support FreeBSD, since people with "true routers" would have no need for using FreeBSD as a router engine. It's a vicious cycle that I believe we're seeing here... chicken and the egg, or rather, the driver and the market. Without a proper driver, there won't be a market for this card to be used with FreeBSD. However, without the manufacturer seeing visability in this market, there won't be a driver as it would be a waste of their developers time. --- Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Más de 15.000 Empresas a su disposición
Mensaje enviado por [EMAIL PROTECTED] Empres@s - Colombia Potente Herramienta para Mercadeo y Ventas. Encuentre los clientes que usted necesita, con un simple click en nuestra base de datos de más de 15Mil Empresas Importantes de Colombia, con más de 70.000 directivos y ejecutivos. La Base de Datos y la Aplicación le permiten localizar y calificar sus mejores prospectos, aprender más sobre sus clientes, proveedores y competidores y crear eficientes campañas de correo, teléfono, e-mail, fax y campañas de campo. La Base de Datos de Empresas (más de 15Mil) maneja los siguientes campos: Razón Social, sigla, Nit, dirección, teléfono, fax, actividad empresarial (código CIIU Rev. 3.0), número de empleados, ciudad y departamento. La Base de Datos de directivos y ejecutivos (más de 70Mil) maneja los siguientes campos: nombre, cargo, area por cargos, dirección, teléfono, fax. Estas bases de datos se encuentran relacionadas, de tal forma que la aplicación hace búsquedas simples o complejas por todos estos campos, agrupa diferentes tipos de búsquedas, prepara e imprime reportes, rótulos y cartas, hace llamadas telefónicas y envía email´s. COMO VALOR AGREGADO le damos acceso a toda la información sobre COMERCIO EXTERIOR, a través de enlaces Vía Internet a las Bases de Datos de MINCOMEX (27000 Importadores), PROEXPO (4.000 Exportadores y sus ejecutivos), Y LA COMUNIDAD ANDINA. También le facilitamos la conexión a sus propios enlaces. Solicite información adicional vía email sobre contenido de la base de datos, fuentes de la información, actualización, funciones que permite ejecutar la aplicación, versiones, precios y empresas que la estan utilizando, o enviando los siguientes datos al Fax 6178102 - 6179073 Bogotá Colombia o llamando directamente a Florentino Rueda, gerente comercial al Cel. 033-3396180 Empresa Nit Ciudad Dirección Teléfono Fax Nombre Cargo P.D. Si este mensaje no es de su interés, considere dirigirlo a la Gerencia General y/o Mercadeo, si no desea recibir mensajes como este, por favor déjenos saberlo a [EMAIL PROTECTED] para eliminar su dirección en nuestra base de datos. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Severe I/O Problems
Well- that's good to know. WC helps you overall. That was my one idea. On Mon, 15 Oct 2001, Jay Rossiter wrote: > > dmesg: > atapci0: port 0xffa0-0xffaf at device 31.1 > on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > ad0: 38146MB [77504/16/63] at ata0-master UDMA100 > acd0: DVD-ROM at ata1-master using PIO4 > > sysctl: > hw.ata.ata_dma: 1 > hw.ata.wc: 0 > hw.ata.tags: 0 > hw.ata.atapi_dma: 0 > hw.atamodes: dma,---,pio,---, > > mount: > /dev/ad0s1a on / (ufs, local) > /dev/ad0s1d on /home (ufs, local) > /dev/ad0s1f on /usr (ufs, local) > /dev/ad0s1h on /usr/ports (ufs, asynchronous, local) > /dev/ad0s1g on /usr/src (ufs, asynchronous, local) > /dev/ad0s1e on /var (ufs, local) > > All of the data work for this project is taking place on /home > > > The writecache flag appeared as though it was going to help significantly, > however the total run took about five hours longer than previous. (~21 > hours) > > Start: Fri Oct 12 15:16:35 PDT 2001 > Stop: Sat Oct 13 12:28:40 PDT 2001 > > > > > > > > > Mikko > Tyolajarvi To: [EMAIL PROTECTED] > <[EMAIL PROTECTED] cc: [EMAIL PROTECTED] > e> Subject: Re: Severe I/O Problems > > 10/12/2001 > 05:25 PM > > > > > > > In local.freebsd.hackers you write: > > >There appear to be a lot of changes that went into the filesystem and I/O > >code between 4.3 and 4.4. A little over a week ago I upgraded my 4.3 box > >to 4.4-STABLE and immediately I started having I/O slowdown. I do > >development and QA on a program that is very I/O bound, but the changes > >between 4.3 and 4.4 aren't small enough that I can ignore them. > > >A few statistics: > > >BSD, P4 1.4GHz, ATA100 drives > >- Normal test run on 4.3 was taking ~3 hours. > >- Normal test run on 4.4 is taking 15-16 hours. > > >P3-800, ATA66 drives, SuSE Linux 7.1: > >- Normal test run takes ~4.5 hours. > > >UltraSparc 10, Solaris 8, ATA66 drives: > >- Normal test run takes ~6 hours. > > >As you can see, this jump was just phenomenal. > > Yup, sure looks bad. Post output from at least: > > % dmesg | grep ata > % sysctl -a | grep ata > % mount | grep ufs > > to give people something more to go on. > > $.02, > /Mikko > -- > Mikko > Työläjä[EMAIL PROTECTED] > RSA Security > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Severe I/O Problems
dmesg: atapci0: port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 38146MB [77504/16/63] at ata0-master UDMA100 acd0: DVD-ROM at ata1-master using PIO4 sysctl: hw.ata.ata_dma: 1 hw.ata.wc: 0 hw.ata.tags: 0 hw.ata.atapi_dma: 0 hw.atamodes: dma,---,pio,---, mount: /dev/ad0s1a on / (ufs, local) /dev/ad0s1d on /home (ufs, local) /dev/ad0s1f on /usr (ufs, local) /dev/ad0s1h on /usr/ports (ufs, asynchronous, local) /dev/ad0s1g on /usr/src (ufs, asynchronous, local) /dev/ad0s1e on /var (ufs, local) All of the data work for this project is taking place on /home The writecache flag appeared as though it was going to help significantly, however the total run took about five hours longer than previous. (~21 hours) Start: Fri Oct 12 15:16:35 PDT 2001 Stop: Sat Oct 13 12:28:40 PDT 2001 Mikko Tyolajarvi To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: [EMAIL PROTECTED] e> Subject: Re: Severe I/O Problems 10/12/2001 05:25 PM In local.freebsd.hackers you write: >There appear to be a lot of changes that went into the filesystem and I/O >code between 4.3 and 4.4. A little over a week ago I upgraded my 4.3 box >to 4.4-STABLE and immediately I started having I/O slowdown. I do >development and QA on a program that is very I/O bound, but the changes >between 4.3 and 4.4 aren't small enough that I can ignore them. >A few statistics: >BSD, P4 1.4GHz, ATA100 drives >- Normal test run on 4.3 was taking ~3 hours. >- Normal test run on 4.4 is taking 15-16 hours. >P3-800, ATA66 drives, SuSE Linux 7.1: >- Normal test run takes ~4.5 hours. >UltraSparc 10, Solaris 8, ATA66 drives: >- Normal test run takes ~6 hours. >As you can see, this jump was just phenomenal. Yup, sure looks bad. Post output from at least: % dmesg | grep ata % sysctl -a | grep ata % mount | grep ufs to give people something more to go on. $.02, /Mikko -- Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: contigfree, free what?
Assuming we are using Thomas' patch that already removed the vm_page_wire()
from the earlier for loop, then at the point of this VM space allocation
failure, we haven't done anything too serious to the vm_page nor to the pmap,
nor are they in any object. We should be able to simply place it back to the
colored free list, something as easy as:
*** vm_page.c Mon Oct 15 10:26:14 2001
--- vm_page.c.new Mon Oct 15 11:32:46 2001
***
*** 1934,1939
--- 1934,1942
* above available.
*/
vm_map_unlock(map);
+ for (i = start; i < (start + size / PAGE_SIZE); i++) {
+ (void)vm_add_new_page(VM_PAGE_TO_PHYS(&pga[i]));
+ }
splx(s);
return (NULL);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
debugging question
I received the following from gdb today: #0 0x0 in ?? () #1 0x280a8d22 in svc_getreqset2 () from /usr/lib/libc.so.4 #2 0x280a8c5b in svc_getreqset () from /usr/lib/libc.so.4 #3 0x804c85f in yp_svc_run () #4 0x804cd94 in main () #5 0x8049a09 in _start () Uhm... I didn't think that was possible. I thought the kernel stored the last stack frame iteslf, from the SIG handler in kernel-space. -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: contigfree, free what?
: :I have a potentially silly question about contigmalloc1(), if the very :unlikely occurance that the kernel VM space ran out, (the vm_map_findspace() :failed) wouldn't we want to return the chunk of contiguous physical space :back on the free queue before we return an allocation failure? : :--mark tinguely. Ah, you came across that XXX comment? You are absolutely right. The original implementor rushed writing the routine and didn't finish it. contigmalloc() is only supposed to be used in the early life of the system when its loading device drivers that need contiguous space, so the case is not supposed to come up. Of course, that means that it does come up from time to time :-(. If you want to have a go at fixing it I will be happy to review. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: contigfree, free what?
I have a potentially silly question about contigmalloc1(), if the very unlikely occurance that the kernel VM space ran out, (the vm_map_findspace() failed) wouldn't we want to return the chunk of contiguous physical space back on the free queue before we return an allocation failure? --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI
In a private e-mail, Leo writes: > You offered a discount on these boards on the list. If you think there > is a real opportunity to sell these to the *BSD crowd, I recomend you > take that 15% (or some part of it) and offer to partially fund a driver > developer. There are many freelance programmers working on the project > who for $1000-$5000 (depending on complexity) could make your driver a > reality. A good developer could probably also make them work under > OpenBSD and NetBSD in one fell swoop. I'd be happy to pledge the 15% to a driver developer. That's a great idea! It will accomplish two objectives: 1) There will be at least 100 WANic 400 series cards available for purchase to support existing installations (assuming someone out there places the order). 2) ImageStream will pledge 15% of the purchase price of any lots of these 400 series cards toward porting of our SAND architecture to FreeBSD. That's a MINIMUM of $8,100 that ImageStream is willing to pay a developer or group of developers to port the drivers for the rest of the cards. Ted--you've indicated that there is a significant market for the 400 series cards in the community. Why don't you contact me privately and we'll get you an order of the cards so that we can accomplish the above. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: clustering code
Ok Ron, well you're right, a bunch-of-more code is not really useful, I'll check Plan 9, it seems it convinced you a little bit, :-) thanks, and regards, Fabián >From: Ronald G Minnich <[EMAIL PROTECTED]> >To: Rayson Ho <[EMAIL PROTECTED]> >CC: Fabián Salamanca <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> >Subject: Re: clustering code >Date: Sun, 14 Oct 2001 21:21:58 -0600 (MDT) > >On Sun, 14 Oct 2001, Rayson Ho wrote: > > > http://ssic-linux.sourceforge.net/ > >A collection of some really bad ideas, not likely to scale well. Note that >they've got up to 30 nodes, wow. Double it once and that's where this kind >of "global everything" idea starts to fall over. Badly. > >It would be neat to see freebsd do something really new and novel in >clustering. ssci-linux is not it. It's going to be very hard to pick >something new, a lot of the ground is well-trod. > >For other examples of what you can do (maybe not what you SHOULD do) see >npaci ROCKS, OSCAR, and follow the references from there. > >On the should-do list, see plan 9 -- (on plan 9 I tend to sound like a >broken record) read and understand the Plan 9 stuff, see how well it would >work as a cluster technology (we have a 32-node plan 9 cluster here, it's >quite cool), and see about bringing those neat ideas to freebsd. > >ron > Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding support for Duxbury PCI modem to FreeBSD 4.4
In message <[EMAIL PROTECTED]> "Peter van Heusden" writes: : I noticed that PCI modems are detected in /sys/isa/sio.c. I added the : chip : id of the modem to the list of PCI devices (pci_ids), and now : sio_pci_probe detects the modem, but the sioprobe() fails. Before I got : digging into the sioprobe code (which seems rather complex), I'd like to : verify that my pci_ids entry is correct. : : One thing I don't understand is the rid field of the pci_id structure. : Some modems have this set to 0x10, others to 0x14. I'm not sure what to : set it : to - how do I determine this? look for the I/o space bar. this will be the the ones in the range 0x10-0x24 that are odd (as in bit 0 is set). note, bars are 4 bytes long (except for some 64 bit cards, but you can safely ignore that). Alternatively, pciconf -r pciX:Y:Z 0x10:0x2f and post it to the list. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI
> Would your agreements allow you to provide resources to a small > number of developers (under NDA and all that of course) to produce > drivers that you would then release in binary form (eg a kernel > module) under a free license? It sure would. > If you cannot release the source code to your drivers, can you > release hardware programming specifications (again, perhaps under > NDA) that allowed someone to develop an independant free licensed > driver? Unfortunately, the API to the cards (the driver development kit, hardware programming specifications or whatever you want to call them) are licensed from several third parties and we are bound by agreement not to make them public. The 400 series cards (and, for that matter, the RISCom/N2 series cards) did not require an API, which is how BSDI and FreeBSD drivers came about in the first place. As I mentioned above, we CAN license the driver code and the DDK for development. This means that you could produce FreeBSD drivers which we could then distribute in a binary form under a free end-user license. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI
On Mon, Oct 15, 2001 at 08:53:14AM -0500, Doug Hass wrote: > We are bound by third party agreements and are not allowed to release any > more free code (legally) than we already have. If we were not restricted > by SBS, Trillium, and Rockwell (among others), we would release all of the > code under GPL or lGPL. These agreements do NOT prevent us from working > with developers to support other platforms, though. It only prevents the > free release of portions of the code. Would your agreements allow you to provide resources to a small number of developers (under NDA and all that of course) to produce drivers that you would then release in binary form (eg a kernel module) under a free license? If you cannot release the source code to your drivers, can you release hardware programming specifications (again, perhaps under NDA) that allowed someone to develop an independant free licensed driver? -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
> And if you want to sell these to FreeBSD users then make your Linux driver > source (not the SAND stuff) available so that we can mod it into our own > driver. Many other companies do this and as a matter of fact, we (meaning > FreeBSD) have even found bugs in crummy Linux drivers that have been reported > back to Linux and helped those manufacturers better their products. I'm not going to get dragged into an OS war. Both Linux and FreeBSD have their share of "crummy" drivers and features. That discussion is honestly beyond the scope of a discussion of ImageStream's SAND architecture and the WANic 400 series. We are bound by third party agreements and are not allowed to release any more free code (legally) than we already have. If we were not restricted by SBS, Trillium, and Rockwell (among others), we would release all of the code under GPL or lGPL. These agreements do NOT prevent us from working with developers to support other platforms, though. It only prevents the free release of portions of the code. That being said, we're always interested in supporting a wide variety of platforms. Without the SAND architecture, though, there really is little hope of having FreeBSD support for the WANic 520 series cards (or other cards, for that matter). If there are developers in the community interested in porting SAND and the various hardware modules (for the 520 series and other cards) to FreeBSD, we'll be happy to work with them and support that effort. It is in ALL of our interests to have the widest support for standards-based technologies as possible. > No offense, but once Imagestream stopped selling WANic400's you > ceased being an entity of interest to FreeBSD, as you no longer sell > any products that run under it. I'll reiterate what I've said to you privately: ImageStream DID NOT make the decision to discontinue the 400 series or the RISCom/N2 series. This decision rested solely with SBS. However, FreeBSD users are NOT without options: 1) FreeBSD users can still get the WANic 400 and RISCom cards from the second hand market, as another person mentioned. 2) WANic 400 series cards are still available in quantity. If the market for FreeBSD is as large as you claim, then you or someone else in the community should have no problem snapping up a quantity of these cards and reselling them to interested parties. I'll go one step further: If anyone contacts me about the WANic 400 series, mentions that they are for FreeBSD, I promise to give an extra 15% discount over and above our normal volume discounts just to illustrate my desire to support the FreeBSD community. 3) Virtually ALL of our customers, save for OEMs making their own products, purchase complete routers. Going this route would eliminate the need to have FreeBSD support, as any user would have a standalone router. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: My contributions to the close a PR campaign
Seth Kingsley <[EMAIL PROTECTED]> writes: > Why not remove it after using it to restore the mixer state? It would > only exist to survive a reboot. You'd have to reset everything manually after a crash. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Poul-Henning >Kamp >Sent: Monday, October 15, 2001 2:53 AM >To: Ted Mittelstaedt >Cc: Soren Kristensen; MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based >alternatives?? > > >We want something with an integral T1/E1 DSU/CSU, otherwise cost is >still prohibitive. as long as there's a carrier detect and a DTE light I hope. A little button for a hard loop would be good too. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
In message <003e01c1555b$db6e2c20$[EMAIL PROTECTED]>, "Ted Mittelstaedt" >>We already have drivers in the tree for the infinion "MUNICHX" chip, >>when used with a FALC frontend. We also have drivers for the MUSYCC >>from Conexant. >> >Ha hmm - Poul, do you how what the reference boards were that these >drivers were tested/developed with? Yes I know (since I wrote them :-) The MUNICHX driver were written on the "EASY321" eval kit from Siemens (Now Infinieon) and the MUSYCC was written on LMC's 1504 card which is now discontinued. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
In message <[EMAIL PROTECTED]>, Soren Kristensen writes: >The PEB20321 (Munich32) supported in that driver is a channelized >version, that not really what people are asking for It's also low >speed, and support only one interface if used unchannelized. One one wire you have only one "circuit" if unchannelized. There is a "bigger brother" MUNIC128X now which is suitable for an 4 port card. >I don't >remember about the Conexant chip, but I think it's channelized too. Both the Munich and Connexant can run channelized or unchannelized. >Paul, do you know how close the PEB20321 and PEB20534 are from a >programming point if view ? But the FALC phy might be good for the T1/E1 >versions. > >I have look around for sync serial controllers, but keep comming back to >the PEB20534, I think that the best chip available for the job. I don't know how similar they are, either way, all the work on the if_mn and musycc drivers were in the framers and clocking. The HDLC is just a piece of cake... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
In message <002f01c15557$44f1d660$[EMAIL PROTECTED]>, "Ted Mittelstaedt" writes: >An interesting proposition. However, you might find it even easier to >do a Hitachi HD64570-based board. It should be much easier to modify >the sr driver to work with it than to write a new one from scratch. We want something with an integral T1/E1 DSU/CSU, otherwise cost is still prohibitive. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
Hi, Ted Mittelstaedt wrote: > > An interesting proposition. However, you might find it even easier to > do a Hitachi HD64570-based board. It should be much easier to modify > the sr driver to work with it than to write a new one from scratch. > As other people already has said, it don't looks like that Hitachi is in it for the long run, and it's not for higher speeds, I would like to also be able to do E3/T3. And anyway, the HD64570 is not a PCI chip, requering additional chips to interface to the PCI bus. Poul-Henning Kamp wrote: > > We already have drivers in the tree for the infinion "MUNICHX" chip, > when used with a FALC frontend. We also have drivers for the MUSYCC > from Conexant. > The PEB20321 (Munich32) supported in that driver is a channelized version, that not really what people are asking for It's also low speed, and support only one interface if used unchannelized. I don't remember about the Conexant chip, but I think it's channelized too. Paul, do you know how close the PEB20321 and PEB20534 are from a programming point if view ? But the FALC phy might be good for the T1/E1 versions. I have look around for sync serial controllers, but keep comming back to the PEB20534, I think that the best chip available for the job. Regards, Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
>-Original Message- >From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 15, 2001 2:05 AM >To: Soren Kristensen >Cc: Ted Mittelstaedt; MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based >alternatives?? > > >In message <[EMAIL PROTECTED]>, Soren Kristensen writes: > >>So maybe I should just make one, and sell for cheap, I need them anyway >>for my small boxes (see http://www.soekris.com) The most common chip >>for the PCI bus, the 4 channel Infinion DSCC4 PEB20534 (used by cronyx >>and others...) cost around $60 in small volume, so the basic 2 ch board >>would probably go for around $250 qty 1. Boards with more channels or >>integrated T1/E1 phys will be a little higher. > >We already have drivers in the tree for the infinion "MUNICHX" chip, >when used with a FALC frontend. We also have drivers for the MUSYCC >from Conexant. > Ha hmm - Poul, do you how what the reference boards were that these drivers were tested/developed with? Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[no subject]
still aint working (connection dropped on reset, unknown error 0); Im a total newbie so maybe I did something wrong, i did exactly this, cd /usr/ports/someport make FETCH_BEFORE_ARGS=-p >hi, >when i am trying to port some program from ports directory (4.3stable) it >never connects to a ftp. Problem might be a firewall, there are so few ports >allowed, but 21 is. Anyone has the same experience? Of course, establishing an active data connection also means having the server connect to an ephemeral port on your machine which is not allowed. make FETCH_BEFORE_ARGS=-p will give you passive ftp instead. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
In message <[EMAIL PROTECTED]>, Soren Kristensen writes: >So maybe I should just make one, and sell for cheap, I need them anyway >for my small boxes (see http://www.soekris.com) The most common chip >for the PCI bus, the 4 channel Infinion DSCC4 PEB20534 (used by cronyx >and others...) cost around $60 in small volume, so the basic 2 ch board >would probably go for around $250 qty 1. Boards with more channels or >integrated T1/E1 phys will be a little higher. We already have drivers in the tree for the infinion "MUNICHX" chip, when used with a FALC frontend. We also have drivers for the MUSYCC from Conexant. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
>-Original Message- >From: Soren Kristensen [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 15, 2001 1:17 AM >To: Ted Mittelstaedt >Cc: MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based >alternatives?? > > >Hi Everybody, > >I've been following the sync serial board discussion a little, and it >seems like that there's no source for inexpensive sync serial boards >with FreeBSD, or boards with documentation to make a driver, or from >companies with a good policy towards open source and/or FreeBSD > >The only one close seems to be the cronyx, they seems to have full >source code, but their boards is not easily available in the US, or >available with T1 interfaces. > >So maybe I should just make one, and sell for cheap, I need them anyway >for my small boxes (see http://www.soekris.com) The most common chip >for the PCI bus, the 4 channel Infinion DSCC4 PEB20534 (used by cronyx >and others...) cost around $60 in small volume, so the basic 2 ch board >would probably go for around $250 qty 1. Boards with more channels or >integrated T1/E1 phys will be a little higher. > >FreeBSd drivers should be relatively easy, t.ex based on the cronyx >drivers, they're even netgraph enabled > >I would then be happy to supply hardware and documentation to somebody >that could do and maintain the drivers. > An interesting proposition. However, you might find it even easier to do a Hitachi HD64570-based board. It should be much easier to modify the sr driver to work with it than to write a new one from scratch. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass >Sent: Sunday, October 14, 2001 7:23 PM >To: Jim Bryant >Cc: Ted Mittelstaedt; [EMAIL PROTECTED]; MurrayTaylor; >[EMAIL PROTECTED]; [EMAIL PROTECTED]; Alfred >Shippen >Subject: Re: FYI > > >Also--understand that the replacement for the 400 and 405 is a >multi-interface card (supports all of the wiring specs instead of just 1), >and costs virtually the same (or less as a reseller or in volume) than the >400/405 did. > And if you want to sell these to FreeBSD users then make your Linux driver source (not the SAND stuff) available so that we can mod it into our own driver. Many other companies do this and as a matter of fact, we (meaning FreeBSD) have even found bugs in crummy Linux drivers that have been reported back to Linux and helped those manufacturers better their products. No offense, but once Imagestream stopped selling WANic400's you ceased being an entity of interest to FreeBSD, as you no longer sell any products that run under it. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com >Doug > >On Sun, 14 Oct 2001, Jim Bryant wrote: > >> No offense to you or your sales partners, but the way I see it, >this means that tons of these will be available for a song on eBay >> soon, and will be in the hands of a lot of FreeBSD and Linux >people [not all of which can afford top-of-the-line all of the time]. >> >> Doug Hass wrote: >> >> > Ted, >> > >> > We're SBS' worldwide distributor. Others who resell them buy >them from us >> > or from one of our distributors. In any case, I can ASSURE you without a >> > doubt that the WANic 400 series and the entire RISCom/N2 series >are end of >> > life as of the end of September. >> > >> > If you have questions, feel free to contact me at your convenience. >> > >> > Regards, >> > >> > Doug >> > >> > - >> > >> > Doug Hass >> > ImageStream Internet Solutions >> > [EMAIL PROTECTED] >> > http://www.imagestream.com >> > Office: 1-219-935-8484 >> > Fax: 1-219-935-8488 >> >> >> jim >> -- >> ET has one helluva sense of humor! >> He's always anal-probing right-wing schizos! >> - >> POWER TO THE PEOPLE! >> - >> "Religious fundamentalism is the biggest threat to >> international security that exists today." >> United Nations Secretary General B.B.Ghali >> >> >> _ >> Do You Yahoo!? >> Get your free @yahoo.com address at http://mail.yahoo.com >> > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
Hi Everybody, I've been following the sync serial board discussion a little, and it seems like that there's no source for inexpensive sync serial boards with FreeBSD, or boards with documentation to make a driver, or from companies with a good policy towards open source and/or FreeBSD The only one close seems to be the cronyx, they seems to have full source code, but their boards is not easily available in the US, or available with T1 interfaces. So maybe I should just make one, and sell for cheap, I need them anyway for my small boxes (see http://www.soekris.com) The most common chip for the PCI bus, the 4 channel Infinion DSCC4 PEB20534 (used by cronyx and others...) cost around $60 in small volume, so the basic 2 ch board would probably go for around $250 qty 1. Boards with more channels or integrated T1/E1 phys will be a little higher. FreeBSd drivers should be relatively easy, t.ex based on the cronyx drivers, they're even netgraph enabled I would then be happy to supply hardware and documentation to somebody that could do and maintain the drivers. Regards, Soren Kristensen Soekris Engineering To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Adding support for Duxbury PCI modem to FreeBSD 4.4
Hi all I've just installed FreeBSD 4.4, and also recently purchased a \Duxbury 56kpci modem (a real modem, not a winmodem). I'm now trying to get this to work with 4.4, so... I noticed that PCI modems are detected in /sys/isa/sio.c. I added the chip id of the modem to the list of PCI devices (pci_ids), and now sio_pci_probe detects the modem, but the sioprobe() fails. Before I got digging into the sioprobe code (which seems rather complex), I'd like to verify that my pci_ids entry is correct. One thing I don't understand is the rid field of the pci_id structure. Some modems have this set to 0x10, others to 0x14. I'm not sure what to set it to - how do I determine this? Thanks for any help (btw. this is my first attempt to add anything to the FreeBSD kernel, so please excuse any naive questions). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
