dgb driver update
Hello! We've updated dgb driver so that it doesn't 'use old compatibility schemes' I think this update is worth being included into source tree. Should I send it to the list or there is now another way of submitting updates? -- Oleg Sharoiko. Software and Network Engineer Computer Center of Rostov State University. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dgb driver update
On Mon, Nov 04, 2002 at 11:05:29AM +0300, Oleg Sharoiko wrote: you could use send-pr to make the proposed patch visible in the bug tracking database Wilko > Hello! > > We've updated dgb driver so that it doesn't 'use old compatibility schemes' > I think this update is worth being included into source tree. Should I send it > to the list or there is now another way of submitting updates? > > -- > Oleg Sharoiko. > Software and Network Engineer > Computer Center of Rostov State University. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message ---end of quoted text--- -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
D-Link DGE-550T NIC
Hi people, did anybody use it with FreeBSD 4.5? The problem is that the system doesn't see it, however 'nge' and 'miibus' support are included into the kernel. Is it correct that it must be 'nge', because as described in the man page, only DGE-500T card is supported by nge, however both DGE-550T and DGE-500T use the same DP83820 chip. Or am I missing something here? Thanks Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
subscribe
This e-mail was scanned by Antivirus! http://www.kssgm.gov.tr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dgb driver update
Wilko Bulte wrote: > On Mon, Nov 04, 2002 at 11:05:29AM +0300, Oleg Sharoiko wrote: > > you could use send-pr to make the proposed patch visible in the > bug tracking database Submit it to the PR database. It can get in line behind the other almost 3000 open PR's, 65% of which are ports, 30% of which are against kern, and for which many contain patches, but have not been committed (yes, I am skeptical about the effectiveness of "send-pr", and will probably remain so, until all PR's with patches attached have their patches committed and are closed). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
On Sun, 27-Oct-2002 at 09:12:33 -0800, David Nicholas Kayal wrote:
> I'm looking for a 5 volt signal.
>
> I have wires plugged into pins 2 and 25 of the parallel port.
>
> I have written a small program:
>
> #include
> #include
> #include
>
> int main()
> {
> int fd;
> while(1)
> {
> ioctl(fd, PPISDATA, 255);
> }
> }
>
I had at least one machine where I had to drive the STROBE signal
to actually get the data appear on the bus. The program attached
below did the trick. It does a little bit more so here is a quick
explanation:
I wanted to physically push the RESET button of another machine
(running Windoze, btw. :-)). To make things a bit more robust
I used all 8 lines of data which are attached to a HC 688 (iirc)
whose second 8 bit input is hardwired to the value 0x5A. Its
output drives an optocoupler whose output is connected to the
RESET connector of the Windoze box. The power was supplied by
all output capable lines of the parallel port (8 data, strobe,
some control lines) which are all connected via diodes and a
resistor to a capacitor. The program first drives the 8 databits
high to charge the capacitor for 5 seconds. It then puts the
0x5A word on the wire for one second. This is when the HC 688's
output goes high and drives the optocoupler to reset the windoze
box.
If you look at the program you'll find that every dataoutput
is surrounded by the apprpropriate STROBE action.
Hth,
-Andre
#include
#include
#include
#include
#include
#include
#include
int Fd;
void send( u_int8_t byte )
{
u_int8_t myc, tmp;
printf( "Sending %02X\n", byte );
if( ioctl( Fd, PPIGCTRL, &myc ) == -1 ) // save old control
err( EX_IOERR, "save control" );
myc &= ~STROBE & ~PCD;// strobe high
tmp = myc;
if( ioctl( Fd, PPISCTRL, &tmp )== -1 )
err( EX_IOERR, "set control" );
if( ioctl( Fd, PPISDATA, &byte ) == 1 ) // set my code
err( EX_IOERR, "set data" );
tmp = myc | STROBE; // strobe low
if( ioctl( Fd, PPISCTRL, &tmp )== -1 )
err( EX_IOERR, "set control" );
tmp = myc;
if( ioctl( Fd, PPISCTRL, &tmp )== -1 )// strobe high
err( EX_IOERR, "set control" );
}
int main( int argc, const char* argv[] )
{
if( (Fd = open( "/dev/ppi0", O_RDWR)) <= 0 )
err( EX_IOERR, "open /dev/ppi0" );
send( 0xFF ); // charge C
sleep( 5 );
send( 0x5A ); // send code
sleep( 1 );
send( 0xFF ); // disable code
return( 0 );
}
Re: dgb driver update
On Mon, Nov 04, 2002 at 03:14:01AM -0800, Terry Lambert wrote: > Wilko Bulte wrote: > > On Mon, Nov 04, 2002 at 11:05:29AM +0300, Oleg Sharoiko wrote: > > > > you could use send-pr to make the proposed patch visible in the > > bug tracking database > > > Submit it to the PR database. > > It can get in line behind the other almost 3000 open PR's, 65% of > which are ports, 30% of which are against kern, and for which many > contain patches, but have not been committed (yes, I am skeptical > about the effectiveness of "send-pr", and will probably remain so, You have every right to be sceptical. I'm unfortunately just as sceptical about a patch floating in a random mailing list. Rock & a hard place :( W/ -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Panic: ffs_clusteralloc: map mismatch (fwd)
I sent this to freebsd-questions a few minutes ago.. if anyone here can
help too I'd really be indebted :-)
-- Forwarded message --
From: Avleen Vig <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Mon, 4 Nov 2002 09:56:36 + (GMT)
Subject: Panic: ffs_clusteralloc: map mismatch
Maybe a question for freebsd-hackers.. not sure..
FreeBSD 4.4, P166, 128Mb, 3 HD's: ad0, ad1, ad4, as ata0-master,
ata1-master and ata2-master. ata2-master is a Promise ata 100 controller
(tx2 I think).
For several months my server has been panicing, and I'm starting to think
it's a bad harddrive. I don't believe it's bad code (although I guess it
could be). I really need help in finding the drive responsible so that I
can replace it, but my debugging skills are limited to what I've learnt
from the OnLamp kernel debugging lesson :-)
I'd really appreciate it if someone could look over the crash dump output
below and let me know how I might be able to find out what write was
attempted when the server paniced. I have the last 4 crash dumps saved so
I can go back and look for matches in consistancy too. Also running a
debugging kernel but the code was last CVSUp'd about 8 months ago.
If it is a bad drive, I plan to replace it with 4.7-RELEASE.
#0 dumpsys () at ../../kern/kern_shutdown.c:473
#1 0xc0142f17 in boot (howto=256) at ../../kern/kern_shutdown.c:313
#2 0xc01432fd in panic (fmt=0xc0210e20 "ffs_clusteralloc: map mismatch")
at ../../kern/kern_shutdown.c:581
#3 0xc019ddd1 in ffs_clusteralloc (ip=0xc198c800, cg=1, bpref=0, len=13)
at ../../ufs/ffs/ffs_alloc.c:1190
#4 0xc019d1b2 in ffs_hashalloc (ip=0xc198c800, cg=0, pref=8, size=13,
allocator=0xc019dba8 ) at
../../ufs/ffs/ffs_alloc.c:778
#5 0xc019cbd7 in ffs_reallocblks (ap=0xc9de2dc4) at
../../ufs/ffs/ffs_alloc.c:442
#6 0xc016d096 in cluster_write (bp=0xc3ccd5d8, filesize=106496,
seqcount=14)
at vnode_if.h:1077
#7 0xc01a899e in ffs_write (ap=0xc9de2e68) at
../../ufs/ufs/ufs_readwrite.c:535
#8 0xc0177b46 in vn_write (fp=0xc15ba880, uio=0xc9de2ed8,
cred=0xc1ac7700, flags=0,
p=0xc9856d00) at vnode_if.h:363
#9 0xc01518e5 in dofilewrite (p=0xc9856d00, fp=0xc15ba880, fd=3,
buf=0x8161000,
nbyte=8192, offset=-1, flags=0) at ../../sys/file.h:162
#10 0xc015179e in write (p=0xc9856d00, uap=0xc9de2f80) at
../../kern/sys_generic.c:329
#11 0xc01f07e1 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 135663616, tf_esi = 672134208, tf_ebp = -1077945820, tf_isp
= -908185644,
tf_ebx = 672060612, tf_edx = 672134208, tf_ecx = 0, tf_eax = 4,
tf_trapno = 0,
tf_err = 2, tf_eip = 672014432, tf_cs = 31, tf_eflags = 659, tf_esp
= -1077945864,
tf_ss = 47}) at ../../i386/i386/trap.c:1155
#12 0xc01e41c5 in Xint0x80_syscall ()
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: dgb driver update
On Mon, 4 Nov 2002, Wilko Bulte wrote: > On Mon, Nov 04, 2002 at 03:14:01AM -0800, Terry Lambert wrote: > > Wilko Bulte wrote: > > > On Mon, Nov 04, 2002 at 11:05:29AM +0300, Oleg Sharoiko wrote: > > > > > > you could use send-pr to make the proposed patch visible in the > > > bug tracking database > > > > Submit it to the PR database. > > > > It can get in line behind the other almost 3000 open PR's, 65% of > > which are ports, 30% of which are against kern, and for which many > > contain patches, but have not been committed (yes, I am skeptical > > about the effectiveness of "send-pr", and will probably remain so, > > You have every right to be sceptical. I'm unfortunately just as > sceptical about a patch floating in a random mailing list. > > Rock & a hard place :( The best way is to send a pr and then followup on mailing lists as appropriate or perhaps by contacting the maintainer. The PR provides history for a given problem and patch and the followup initiates action on behalf of the committers. It's important to get someone to take up the "responsible" field before any action can happen. BTW, the number of PRs is not totally the fault of committers. I've been scanning through the DB with about 50% of my FreeBSD-time and fixing things that I find there. However, it has taken about 3x as long as I expected to commit a patch because almost all of them are very incomplete and actually are more a suggestion on an area that needs improvement, not a fix. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Request for submissions: FreeBSD Bi-Monthly Development Status Report Sept-Oct 2002 (fwd)
Reminder that the deadline for status report submissions is rapidly approaching. Please follow the directions below to submit a FreeBSD development status report. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories -- Forwarded message -- Date: Fri, 1 Nov 2002 13:29:54 -0500 (EST) From: Robert Watson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Request for submissions: FreeBSD Bi-Monthly Development Status Report Sept-Oct 2002 This is a solicitation for submissions for the September 2002 - October 2002 FreeBSD Bi-Monthly Development Status Report. All submissions are due by November 10, 2002. Submissions should be made by filling out the template found at: http://www.FreeBSD.org/news/status/report-sample.xml Submissions must then be e-mailed to the following address for automated processing (IT HAS CHANGED): [EMAIL PROTECTED] Reports must be submitted in the XML format described, or they will be silently dropped. Submissions made to other e-mail addresses will be ignored. If more than one report is submitted for a project, the latest instance will be used. Status reports should be submitted once per project, although project developers may choose to submit additional reports on specific sub-projects of substantial size. Status reports are typically one or two short paragraphs, but the text may be up to 20 lines in length. Submissions are welcome on a variety of topics relating to FreeBSD, including development, documentation, advocacy, and development processes. Submitting developer status reports help maintain an important link between FreeBSD developers, as well as a link to the user and sponsor communities. By submitting a report, you help share information about the rapid progress made by the project, making it easier for advocates to point at the excellent work that's being done! Prior status reports may be viewed at: http://www.FreeBSD.org/news/status/ Of particular interest, rolling up to the 5.0 release, are reports relating to the major architectural projects with results in 5.0, including SMPng, KSE, GEOM, TrustedBSD, UFS2, newcard, firewire, ACPI, IPsec acceleration, and new hardware ports including sparc64 and ia64. Including reports on the status approaching the release, and identifying areas where "must be done" requirements are present for the release will help consumers of FreeBSD get a sense of what they can expect in 5.0, as well as what other developers need to work on in order to make it happen. Robert Watson, Scott Long FreeBSD Project 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
max phy mem known working with FreeBSD 4.x
Anyone knows the max physical mem that can be used with FreeBSD4.3? Thanks in advance To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: max phy mem known working with FreeBSD 4.x
On Mon, 4 Nov 2002, Matt wrote: > Anyone knows the max physical mem that can be used with FreeBSD4.3? Well, we have 4GB in a 4.6.2 system, and I think that we ran 4.3 on those systems for a while. However, you lose anywhere between 128M and 512M because of the PCI address space. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], http://www.richardsharpe.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: max phy mem known working with FreeBSD 4.x
any chance going more than 4G? Best Regards Matt http://www.xgforce.com/product.html The Next Generation Server Clustering and Clustered Enterprise SQL database, and Firewall/VPN Solutions. - Original Message - From: "Richard Sharpe" <[EMAIL PROTECTED]> To: "Matt" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, November 04, 2002 10:50 PM Subject: Re: max phy mem known working with FreeBSD 4.x > On Mon, 4 Nov 2002, Matt wrote: > > > Anyone knows the max physical mem that can be used with FreeBSD4.3? > > Well, we have 4GB in a 4.6.2 system, and I think that we ran 4.3 on those > systems for a while. > > However, you lose anywhere between 128M and 512M because of the PCI > address space. > > Regards > - > Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED], http://www.richardsharpe.com > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: max phy mem known working with FreeBSD 4.x
Matt wrote: > Anyone knows the max physical mem that can be used with FreeBSD4.3? 2G on Alpha. 4G on Intel, if you tune your kernel and modify your KVA size to 3G. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: max phy mem known working with FreeBSD 4.x
On Mon, 4 Nov 2002, Matt wrote: > any chance going more than 4G? Not yet. (on x86) The hardware changes to do > 32 bit physical addresses include a redefinition of how page tables and page directories are layed out and to be able to use it we'd have to define and turn on code for that differnt mode. iIt has not yet been written. It wouldn't be hard to make a system that ONLY ran in that mode but one that can run on new systems withthat mode and also run on old 486 machines is much harder. Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
