Re: Panics when using Mylex RAID with SMP under RELENG_4
* Drew Eckhardt ([EMAIL PROTECTED]) [000502 13:24]: > In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: > >I am trying to run a Mylex Acceleraid 1100 in a Dell Poweredge 2450. > > What is a Dell Poweredge 2450, in terms of chipset and processors? Dual 600 PIII, 256k cache. 512mb PC133 RAM. Serverworks RCC LE chipset. Adaptec 7899 Ultra160 SCSI controller. > To add another datapoint: > > I just swapped the 350MHz PII in my Super Micro P6DGS (your generic > 440GX dual slot-1 board) for a pair of PIII600Es. Since then, I have been > getting panics under both 4.0 and 5.0 current from trap 29 that seem > correlated to IDE disk I/O load. > > The first crash dump I grabbed showed that the faulting address was > idle_loop + 64, which is at the cli instruction. > > Trap 29 could come from processor fault 19 (SIMD), an APIC, or PIC. Since > cli isn't a SIMD instruction, I suspect the APICs or PICs but have yet to > instrument and test this hypothesis. > > > tf_eip = -1071757093, tf_cs = 8, tf_eflags = 582, tf_esp = 0, > > tf_ss = -8359936}) at ../../i386/i386/trap.c:586 > >(kgdb) > > What do you get when you feed kgdb > > frame 3 > info line * (void *)frame->tf_eip (kgdb) info line * (void *)frame->tf_eip No line number information available for address 0xc01e48db (kgdb) Well, at least that matches it to your problem. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lpr: order of print requests
I don't know if I make any strange mistake, but I
have done the following simple thing.
File p.c :
#include
FILE
*fp
;
main(){register int
i ;
for
(i=0;i<1000;i++)
{ fp=popen("lpr
-Plp","w"); fprintf(fp,"Richiesta
N. %d\n",i);
pclose(fp);
}}
then
cc -o p p.c
./p
the result of lpq after this is:
waiting for lp to become ready
(offline?)Rank Owner Job
Files
Total Size1st root
33 (standard
input)
15 bytes2nd root
30 (standard
input)
15 bytes3rd root
35 (standard
input)
15 bytes4th root
36 (standard
input)
15 bytes5th root
29 (standard
input)
15 bytes6th root
31 (standard
input)
15 bytes7th root
37 (standard
input)
15 bytes8th root
38 (standard
input)
15 bytes9th root
39 (standard
input)
16 bytes10th root
40 (standard
input)
16 bytes11th root
41 (standard
input)
16 bytes12th root
42 (standard
input)
16 bytes13th root
32 (standard
input)
15 bytes14th root
34 (standard
input)
15 bytes15th root
56 (standard
input)
16 bytes16th root
57 (standard
input)
16 bytes17th root
43 (standard
input)
16 bytes
etc
As you can see, the first on the queue is Job 33,
while the second is 30 and so on
The sizes are irrilevant because they are the
same.
For this reason, and for similar problems, it is
desiderable that the order of the requests is the same. I think that must be a
chance to respect the order of the requests to avoid situations like
this.
Thanks.
Re: lpr: order of print requests
Submitting the files with a single command should prevent reordering. lpc's topq command can be used to move a job to the top of the queue. Printing small jobs first is a desirable feature. Too often I've found a dozen people waiting while large jobs tied up the printers and that user wasn't present. I haven't looked at the code, but was told it took both size and submission time into consideration so that even large jobs would eventually print. If sending to a private printer, who does the print order matter? Are you trying to use forms? > I think you're right, because the process that generates the requests > is only one. It consecutively opens pipes to lpr and then closes > them. In effect it builds invoices from delivery documents and the > printed numbers of invoices is effectively out of order, while the > requests are ordered by number of invoice. Each pipe is opened and > closed: so the processes are not concurrent: one begins after the > other has finished. So, is there a way to disable this strange > behavior? > > Thanks. >> LPR queues up the reuqests and prints them in order smallest to >> largest to reduce the average wait time for a job at the expense of >> having a larger standard deviation in the wait times for jobs. Maybe >> this is what you are running into. I don't know if there's a way to >> disable this behavior or not. At least that's what I recall lpd doing >> years ago when I ran a unix lab in school. I didn't go check the code >> to see if it still did that or not. >> >> Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Panics when using Mylex RAID with SMP under RELENG_4
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: >I am trying to run a Mylex Acceleraid 1100 in a Dell Poweredge 2450. What is a Dell Poweredge 2450, in terms of chipset and processors? >When >running rawio against the mylex partition, the system panics within 2 >minutes, always with a trap #29. I have kernel dumps for four panics, but >kgdb doesn't show any similarities between the panics (other than that they >are all #29). To add another datapoint: I just swapped the 350MHz PII in my Super Micro P6DGS (your generic 440GX dual slot-1 board) for a pair of PIII600Es. Since then, I have been getting panics under both 4.0 and 5.0 current from trap 29 that seem correlated to IDE disk I/O load. The first crash dump I grabbed showed that the faulting address was idle_loop + 64, which is at the cli instruction. Trap 29 could come from processor fault 19 (SIMD), an APIC, or PIC. Since cli isn't a SIMD instruction, I suspect the APICs or PICs but have yet to instrument and test this hypothesis. > tf_eip = -1071757093, tf_cs = 8, tf_eflags = 582, tf_esp = 0, > tf_ss = -8359936}) at ../../i386/i386/trap.c:586 >(kgdb) What do you get when you feed kgdb frame 3 info line * (void *)frame->tf_eip ? -- http://www.poohsticks.org/drew/">Home Page For those who do, no explanation is necessary. For those who don't, no explanation is possible. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Panics when using Mylex RAID with SMP under RELENG_4
I am trying to run a Mylex Acceleraid 1100 in a Dell Poweredge 2450. When
running rawio against the mylex partition, the system panics within 2
minutes, always with a trap #29. I have kernel dumps for four panics, but
kgdb doesn't show any similarities between the panics (other than that they
are all #29).
This is using RELENG_4 cvsupped recently, and the APIC patch is in. I've
tried using a kernel both with and without Matt Dillon's experimental SMP
patch, but both cause problems.
If I boot this machine with kernel.GENERIC (no SMP), then rawio completes
successfully. If I run the test on a single SCSI drive not attached to the
Mylex, it completes without error regardless of whether I am using
kernel.GENERIC or my SMP-enabled kernel.
I'm wondering if anyone can help debug this problem. I can make the box
accessible on the net and give an account to anyone with sufficient
knowledge to help; I can also send the kernel dumps to anyone who is
interested.
I've looked over the CVS repository to see if there have been changes to the
driver in -CURRENT, and there do appear to be changes, but I'm not sure if
they might fix this problem. If they might, I'll install the latest current
snapshot and give it a shot, but if that avenue won't do any good I'd rather
not bother. Any info along those lines is also appreciated.
The traps almost always look like this in kgdb:
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc014b574 in poweroff_wait (junk=0xc0216039, howto=0)
at ../../kern/kern_shutdown.c:554
#2 0xc01e587e in trap_fatal (frame=0xff806fbc, eva=0)
at ../../i386/i386/trap.c:926
#3 0xc01e5242 in trap (frame={tf_fs = 24, tf_es = -1071448048, tf_ds = 16,
tf_edi = -1, tf_esi = 0, tf_ebp = 0, tf_isp = -8359960, tf_ebx = 0,
tf_edx = 160165, tf_ecx = 1, tf_eax = 0, tf_trapno = 29, tf_err = 0,
tf_eip = -1071757093, tf_cs = 8, tf_eflags = 582, tf_esp = 0,
tf_ss = -8359936}) at ../../i386/i386/trap.c:586
(kgdb)
Any help appreciated. Those with sufficient skill and contract hopes are
invited to contact me directly.
TIA.
--
j.
James FitzGibbon [EMAIL PROTECTED]
Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Toshiba 4260 screen problem
Greetings, I've got myself a bright new shiny Toshiba 4260 laptop, with one small problem. I cannot seem to get the screen any bigger than a small window (similiar to Fn + F on my Vaio). Any ideas how I can get this full screen? -Dan -- Dan Moschuk ([EMAIL PROTECTED]) "Don't get even -- get odd!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lpr: order of print requests
Warren Losh wrote: > LPR queues up the reuqests and prints them in order smallest to > largest to reduce the average wait time for a job at the expense of > having a larger standard deviation in the wait times for jobs. Maybe > this is what you are running into. I don't know if there's a way to > disable this behavior or not. At least that's what I recall lpd doing > years ago when I ran a unix lab in school. I didn't go check the code > to see if it still did that or not. > > Warner > I think you're right, because the process that generates the requests is only one. It consecutively opens pipes to lpr and then closes them. In effect it builds invoices from delivery documents and the printed numbers of invoices is effectively out of order, while the requests are ordered by number of invoice. Each pipe is opened and closed: so the processes are not concurrent: one begins after the other has finished. So, is there a way to disable this strange behavior? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: testers for PR 17698
On Tue, 02 May 2000 15:45:04 +0200, Johan Karlsson wrote: > Did you get any alpha/pc98 testers for the patch in PR 17698 Not yet, but since I know that lots of people have been away the last two weeks, I'd like to wait another week before I go ahead without review. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Where to send PC98 review requests
Hi folks, I have patches that I'd like to run by PC98 people for testing. What mailing list should I send them to? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
testers for PR 17698
Hi Sheldon, Did you get any alpha/pc98 testers for the patch in PR 17698 see http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=515536+522235+/usr/local/www/db /text/2000/freebsd-hackers/2402.freebsd-hacker Even if you didn't maybe you can commit it and MFC to 4-Stable. Thanks Johan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mbufs & ip stack
Hi
I am writing some custom code into the freebsd ip stack (as a project)
I am trying to get the payload of an ip packet out of an mbuf and cast it to
the type of data being carried (an ipmp header).
When i try to get the ipmp_hdr out of the mbuf, and try to do some work with
it, i seem to be referencing the ip_hdr with the ipmp_hdr pointer (based on
the values i extract from it)
What am i doing wrong? I have based my code on the Freebsd 3.2 icmp code
and am running under freebsd 3.2
Also, why is the ICMP_ADVLENMIN defined as (8 + sizeof(struct ip) + 8) in
ip_icmp.h ??
Below is the source for what i am doing
Hopefully someone can help
Matthew
#define IPMP_ADVLENMIN (8 + sizeof(struct ip) + 8)
void ipmp_input(struct mbuf *m, int off)
{
struct ip *ip_hdr;
int ipmplen;
int hlen;
int i;
struct ipmp_header *ipmp_hdr;
ip_hdr = mtod(m, struct ip *);
ipmplen = ip_hdr->ip_len;
hlen= off;
/* check that the length of the data in the packet is the minimum reqd */
if(ipmplen < IPMP_MINLEN)
{
ipmpstat.tooshort++;
goto freeit;
}
/* pull up the header of the ipmp packet */
i = hlen + min(ipmplen, IPMP_ADVLENMIN);
if(m->m_len < i && (m = m_pullup(m,i)) == 0)
{
/* if the call fails to m_pullup, the buffer is freed automatically */
ipmpstat.tooshort++;
return;
}
/* get the ip header again as the mbuf locn has probably changed */
ip_hdr = mtod(m, struct ip *);
/* get the ipmp header */
m->m_len -= hlen;
m->m_data += hlen;
ipmp_hdr = mtod(m, struct ipmp_header *);
m->m_len += hlen;
m->m_data -= hlen;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: lpr: order of print requests
Konrad Heuer wrote
> Hmm, I've never seen such a strange behaviour.
Lpd should do FIFO. Could> you give some more infos about your
environment (os release, input filter> program, printer
type)?
Yes, I think it's a very strange
behaviour.
In effect in the file
/usr/src/usr.sbin/lpr/common_source/common.c there is:
.
/* * Scan the current directory and make a
list of daemon files sorted by * creation time. * Return the
number of entries and a pointer to the list. */intgetq(pp,
namelist) const struct printer
*pp; struct queue
*(*namelist[]);{.
However I had the problem in more than one
installation of the os from 2.2.7 to 3.4.
The printers are used in a very simple
way,
...
lp|local line
printer:\
:sh:sf:mx#0:\
:lp=/dev/lpt0:sd=/usr/spool/output/lpd:lf=/var/log/lpd-errs:
but the order is wrong. The problem occur when the
number of consecutive requests grows, i. e. when I have to print requests from 1
to 100 (from tha same process), the first 40 are in the right order, then are
printed those from 50 to 100 in the right order and at last those from 41 to
49.
All I do is simply open a pipe by a call to
fp=popen("lpr -Plp","a");
fprintf(fp,X);
.
..
.
fclose(fp);
The contents are almost the same for each request,
simply characters; I don't use any input filter. The printer is always a
character printer like IBM, EPSON ...
So I don't understand why this
happens.
Any suggestions??
bug (?) in trapsignal
Hi all,
I was having a look at the last kern_sig.c and the following seems wrong :
/*
* Send a signal caused by a trap to the current process.
* If it will be caught immediately, deliver it with correct code.
* Otherwise, post it normally.
*/
void
trapsignal(p, sig, code)
struct proc *p;
register int sig;
u_long code;
{
register struct sigacts *ps = p->p_sigacts;
if ((p->p_flag & P_TRACED) == 0 && SIGISMEMBER(p->p_sigcatch, sig) &&
SIGISMEMBER(p->p_sigmask, sig)) {
~~
p->p_stats->p_ru.ru_nsignals++;
.
Seems to me one needs a :
SIGISMEMBER(p->p_sigmask, sig) == 0
Dimitri
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Toshiba 4260 screen problem
I recall someone on the freebsd-mobile mailing list having a similar problem. What I told them to try was using options VESA in their kernel config or use the vesa.ko kernel module. I looked at it a little more closely and it appears that you might also need the SC_PIXEL_MODE option in your kernel config to get raster text mode to work. After you have that in your kernel then you can use vidcontrol to change the video mode to VESA_800x600 for 800x600 raster text mode. They seemed to be happy with the results. Try it out and let me know wether or not it was helpful. -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" On Tue, 2 May 2000, Dan Moschuk wrote: > >Greetings, > >I've got myself a bright new shiny Toshiba 4260 laptop, with one small >problem. I cannot seem to get the screen any bigger than a small window >(similiar to Fn + F on my Vaio). > >Any ideas how I can get this full screen? > >-Dan >-- >Dan Moschuk ([EMAIL PROTECTED]) >"Don't get even -- get odd!" > > >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: /usr/share/examples/cvsup -> /usr/local/share/examples/cvsup
On Mon, May 01, 2000 at 07:25:17AM -0700, Peter Wemm wrote: > Nik Clayton wrote: > > Would anyone object to pulling /usr/share/examples/cvsup out of the base > > system, and into /usr/local/share/examples/cvsup, to be installed by the > > CVSup port? There's no technical reason for the change, but it would be > > more consistent with our other ports. > > Which cvsup port would get it? There are two... Both. Or, to make it easier to keep things consistent, have an additional CVSup port to contain common items and use the MASTERDIR variable to use them. > And what about the folks who ftp the binary and never install the ports > collection? If they FTP the binary package then they'll get it as part of the install. If they FTP a binary and copy it by hand in to /usr/local/bin/cvsup (or whatever) then they get to read section 18.3.3 (currently) of the Handbook. > They use the /usr/share/examples stuff as a base. I certainly > do not install the ports dist at sysinstall time and only do so eventually > after cvsup'ing the ncvs tree and checking source and ports out of there. How do you install CVSup? pkg_add? > Also, the share/examples stuff is supposed to be preset for getting the > active branch that the release is from, when using checkout mode. To > duplicate that in the port you'd need multiple versions of the files and be > sensitive on the OS version. True -- but if you're going to be touching something as sensitive as your local CVS tree I would have thought that everyone's going to take the time to look over the config file before they actually use it. Multiple supfiles such as supfile.RELENG_3 or supfile.RELENG_4 would be a possibilty. While I'm talking about it, make.conf's SUPFILE default of looking in /usr/share/examples/cvsup doesn't give me a warm fuzzy feeling either. IMHO that would make more sense as: [...] # # CVSup update flags. Copy an example supfile from # /usr/local/share/examples/cvsup to /usr/local/etc/supfile (or similar), # edit to taste, and uncomment/edit a SUPFILE definition below. Then # "make update" in /usr/src. # [...] N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PROBLEM FOUND (sort of): Re: lpr: order of print requests
On Tue, 2 May 2000, Konrad Heuer wrote: > > On Tue, 2 May 2000, Lorenzo Iania wrote: > > > Warren Losh wrote: > > > > > LPR queues up the reuqests and prints them in order smallest to > > > largest to reduce the average wait time for a job at the expense of > > > having a larger standard deviation in the wait times for jobs. Maybe > > > this is what you are running into. I don't know if there's a way to > > > disable this behavior or not. At least that's what I recall lpd doing > > > years ago when I ran a unix lab in school. I didn't go check the code > > > to see if it still did that or not. > > > > > > Warner > > > > > > > I think you're right, because the process that generates the requests is > > only one. It consecutively opens pipes to lpr and then closes them. In > > effect it builds invoices from delivery documents and the printed numbers of > > invoices is effectively out of order, while the requests are ordered by > > number of invoice. Each pipe is opened and closed: so the processes are not > > concurrent: one begins after the other has finished. > > So, is there a way to disable this strange behavior? > > Hmm, I've never seen such a strange behaviour. Lpd should do FIFO. Could > you give some more infos about your environment (os release, input filter > program, printer type)? I had the same problem when I used Samba and a FreeBSD box as an intermediary print queue to a networked laser printer for some Win95 boxes. Needless to say, the secretaries didn't like the fact that all of the checks they printed were out of order on numbered check stock. :-( This is definately a bug, probably in the queue sort routine in usr.sbin/lpr/common_source/common.c. I'm no good at C programming, or I'd take a shot at finding the exact culprit and fixing it myself. I'm on 4.0-STABLE, and here is what I can produce: # lpq -a # for foo in 1 2 3 4 5 6 7 8 9 10; do echo "$foo" | lpr -Praw; done # lpq -a raw: Warning: raw is down: printing disabled Warning: no daemon present Rank Owner Job Files Total Size 1stroot 41 (standard input) 3 bytes 2ndroot 33 (standard input) 2 bytes 3rdroot 34 (standard input) 2 bytes 4throot 35 (standard input) 2 bytes 5throot 36 (standard input) 2 bytes 6throot 37 (standard input) 2 bytes 7throot 38 (standard input) 2 bytes 8throot 39 (standard input) 2 bytes 9throot 40 (standard input) 2 bytes 10th root 32 (standard input) 2 bytes Notice the rank and job numbers, and that jobs 32 and 41 are swapped. Looking at the raw job data in the spool directory verifies that each sequential job is being placed into the queue with a correct sequential job number. Investigating further, this happens: Place just six jobs in the queue, and things are peachy: # lpq -a raw: Warning: raw is down: printing disabled Warning: no daemon present Rank Owner Job Files Total Size 1stroot 79 (standard input) 2 bytes 2ndroot 80 (standard input) 2 bytes 3rdroot 81 (standard input) 2 bytes 4throot 82 (standard input) 2 bytes 5throot 83 (standard input) 2 bytes 6throot 84 (standard input) 2 bytes Add a seventh job and the odd sorting behaviour happens: # lpq -a raw: Warning: raw is down: printing disabled Warning: no daemon present Rank Owner Job Files Total Size 1stroot 82 (standard input) 2 bytes 2ndroot 80 (standard input) 2 bytes 3rdroot 81 (standard input) 2 bytes 4throot 79 (standard input) 2 bytes 5throot 83 (standard input) 2 bytes 6throot 84 (standard input) 2 bytes 7throot 85 (standard input) 2 bytes The print queue is sorted by qsort(), so this wouldn't have anything to do with the magic number "7" I see in lib/libc/stdlib/qsort.c, would it? (ignore me... its probably just a coincidence) :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PROBLEM FOUND (sort of): Re: lpr: order of print requests
I'd bet it does, quicksort is not a stable sort and all of your print requests are the same length. -Ira To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PROBLEM FOUND (sort of): Re: lpr: order of print requests
In the last episode (May 02), Chris Dillon said: > On Tue, 2 May 2000, Konrad Heuer wrote: > > Hmm, I've never seen such a strange behaviour. Lpd should do FIFO. > > Could you give some more infos about your environment (os release, > > input filter program, printer type)? Aha. Yes, it _does_ do FIFO, but if you look at the source, the queue sorting routine simply sorts on stat(mtime) of the queue file, so jobs submitted in the same second will sort randomly. A quick fix would be to sleep for 1 second between "lpr" calls. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lpr: order of print requests
At 2:09 PM -0600 5/1/00, Warner Losh wrote: >LPR queues up the reuqests and prints them in order smallest to >largest to reduce the average wait time for a job at the expense of >having a larger standard deviation in the wait times for jobs. Maybe >this is what you are running into. I don't know if there's a way to >disable this behavior or not. At least that's what I recall lpd doing >years ago when I ran a unix lab in school. I didn't go check the code >to see if it still did that or not. FreeBSD's lpr, as it ships, does not do queue reordering based on size. It is probably best that it remain this way. In the case of postscript jobs, for instance, reordering a queue based on the byte-size of the postscript job is pretty pointless. You can have a short job which takes a long time to print, or a long job which pretty much flies right through the queue. The byte-size of the postscript job does not accurately indicate how long it will take to plot. Postscript is a language. Saying which job will print faster is like claiming you can tell which C-program will execute in less time based on the byte-size of the C source files. I am sure that many sites would change lpr's behavior to implement some kind of prioritization based on file size or file type, but lpr as exists in freebsd source is FIFO (assuming no one does an 'lpc topq' to explicitly change that order...). Looking at the source code (the getq() and compar() routines in lpr/common_source/common.c), it is clear that it only checks the last-modification time of the cf files for each job. 'lpc topq' works by altering those last-modification timestamps. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PROBLEM FOUND (sort of): Re: lpr: order of print requests
At 5:47 PM -0500 5/2/00, Dan Nelson wrote: >In the last episode (May 02), Chris Dillon said: > > On Tue, 2 May 2000, Konrad Heuer wrote: > > > Hmm, I've never seen such a strange behaviour. Lpd should do FIFO. > > > Could you give some more infos about your environment (os release, > > > input filter program, printer type)? > >Aha. Yes, it _does_ do FIFO, but if you look at the source, the queue >sorting routine simply sorts on stat(mtime) of the queue file, so jobs >submitted in the same second will sort randomly. A quick fix would be >to sleep for 1 second between "lpr" calls. I would call that more of a "workaround" than a "fix"... :-) For the example situation that Lorenzo is talking about, a quick fix to lpr might be to change the compar() routine in common_source/common.c. The code should probably check for the case where two files have the same last-modification time (to the degree of accuracy that stat() can tell the last-mod time), and if they match then the routine should sort the cf files based on the file-name. That means 'cfA001some.host.name' would always come before 'cfA002some.host.name', so it solves the problem when jobs area all coming from the same hostname, except for the case where the jobid wraps around from '999' to '000'. Probably could handle that case easily enough, too, with a little extra thought. This should not break anything. I will write up an update which does this, unless someone thinks it is a BadIdea(tm) for some reason. Someone else would have to commit the change to the official source, but at least Lorenzo could try that change and see if it helps his situation. Given the example he gave in a different message, I am not completely convinced that this is the problem he is seeing. Still, this change does seem like a good idea to do. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
GET OUT THE VOTE! Please support Java port to *BSD
Hi: Since last week when the message below and other messages began to circulate, approximately 230 votes have been cast for the java port to *BSD. This has raised our total count to 3182, an increase of 7.75%. Additionally, it is heartening to read the comments left by those who have voted which clearly demonstrate the depth of loyalty that *BSD users have for their platform of choice. Greg Lewis, who heads the FreeBSD-java porting effort has released the first "alpha" patchset for FreeBSD, the seventh in a series of patchsets representing months of work by many *BSD-ers. These volunteers have made a tremendous effort that is sure to enhance the *BSD plaform whether Sun comes around to an "official" port or not. The best way to say "Thanks" is to 1) help with testing, 2) VOTE! FYI: I am not a part of the java porting team, just a user who would like to use a native port and support the *BSD platform. John Last week, John Daniels wrote: >Hi: > >In November 1999 a request for enhancement (RFE) was opened at Sun's >Java Developer's Connection titled: Port jdk 1.2.x to FreeBSD (bug >id: 4288745). > >Members of the Java Developer's Connection help prioritize bug fixes >and RFE's by voting for the one's that they believe are needed most. The >FreeBSD port RFE currently is the #1 request by far with 2953 votes vs. 819 >for the #2 request. > >Even with this wide lead, Sun has no obligation to make an official >port of Java to FreeBSD or *BSD, or to be helpful to the *BSD efforts >to port Java (see www.freebsd.org/java). The larger the number of >votes >for our RFE, however, the more difficult it is for Sun to >ignore. And the more that we can widen the lead between our #1 RFE >and #2, the more dramatic a statement we (collectively) make. > >An official Java JDK port to FreeBSD would likely mean that all BSD's >would benefit either by being able to use the FreeBSD port or by >being much closer to a port of their own. In fact, many who have >voted for the RFE have left comments supporting a port to *BSD, not >just FreeBSD. > >As you may know, Sun recently teamed with Inprise to create an >official port of Java to Linux (building on the work of Blackdown). >The *BSD's, with a large and loyal base of developers, also deserve >an official native version of Java. > >Please support the Java on *BSD effort by voting for the RFE at: >http://developer.java.sun.com/developer/bugParade/bugs/4288745.html If you >are not already a member of Sun's Java Developers Connection, >you will need to register before voting (membership is free). > >Your support is greatly appreciated. Thank you. > >John > >PS Please forward this message to any person, list, or organization >that may want to support this effort. Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GET OUT THE VOTE! Please support Java port to *BSD
> >Please support the Java on *BSD effort by voting for the RFE at: > >http://developer.java.sun.com/developer/bugParade/bugs/4288745.html If you > >are not already a member of Sun's Java Developers Connection, > >you will need to register before voting (membership is free). I have spent five minutes to register as a member and go to the above site and click the radio button to vote for this bug. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Which is the best filesystem to share data between fBSD and nBSD?
Hello! I plan to install three flawors of BSD: Free, Net, and possibly Open. I'm thinking of what is the best way of sharing data between them? If their FFS filesystems has the same layout, so I don't really have to care about it, simply mounting the slices, or there are certain differences, and I need to specify some mount options, or even use another FS, like ext2fs, or even VFAT [sic]. Please cc me since I am the member of the list, and sorry for crossposting. Cheers, /* Alexey N. Dokuchaev, more commonly |*/ /* known as DAN Fe | mailto:[EMAIL PROTECTED] */ /* | ICQ UIN: 38934845 */ /* Novosibirsk State University | http://inet.ssc.nsu.ru/~danfe/ */ /* Scientific Study Center Computer Lab |*/ [Team Assembler] [Team BSD] [Team DooM] [Team Quake] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d-@ s+: a--- C++(+++) UBL$ P++>$ L+ E-- W++ N++ o? K? w-- O- M V- PS PE Y+ PGP+ t+ 5+ X+ R- !tv b++ DI+ D+++ G++ e h !r !y+ --END GEEK CODE BLOCK-- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD:Are you guys coming or what? Microsoft: What are we going to rip off today and claim as our own? Microsoft: Where do you want to be taken today? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3Com's all-in-one XJack modem/NIC
In message <[EMAIL PROTECTED]> Matt Peterson writes: : when can we expect 4.0-RELEASE PAO floppies?). Thx. There are no current plans for a PAO based on 4.0. Instead, the strategy has been to integrate the PAO 3x stuff into -current and then MFC as appropriate into 4.x stable. This is just my understanding of things. I could be wrong. My Japanese isn't that good :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: testers for PR 17698
In message <[EMAIL PROTECTED]> Sheldon Hearn writes: : > Did you get any alpha/pc98 testers for the patch in PR 17698 : : Not yet, but since I know that lots of people have been away the last : two weeks, I'd like to wait another week before I go ahead without : review. There's a [EMAIL PROTECTED] (likely in Japanese) that you can send to. Also [EMAIL PROTECTED] has done a lot of commits to this part of the tree. There may also be a [EMAIL PROTECTED], but I'm less sure of that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PROBLEM FOUND: Re: lpr: order of print requests
At 8:37 PM -0400 5/2/00, Garance A Drosihn wrote: >This should not break anything. I will write up an update which >does this, unless someone thinks it is a BadIdea(tm) for some reason. >Someone else would have to commit the change to the official source, >but at least Lorenzo could try that change and see if it helps his >situation. Well, I waited several whole minutes and no one complained, and I happen to be working on RPI's lpd right now, so I wrote up an update for this. Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=18361 [PATCH] Fix for queue-ordering problem in lpr/lpd/lpq or pick up the update from: ftp://freefour.acs.rpi.edu/pub/bsdlpr/lpr_qfix.diff and test it out. It seems to work fine for me. If no problems come up, please submit a follow-up to the PR so people know it has been tested. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
MAKE MONEY FOR DOING NOTHING!!!!!!!!! PROMISE
WILL SURF FOR YOU, JUST FOR FILLING OUT A SMALL FORM Do you realize how valuable you are as an Internet user? Did you know that you can be paid when youre on the Web? AND off the WEB!! Interested? Become an AllAdvantage.com member now! It's free to join and your privacy is completely protected. Check out these impressive facts: They've paid over $10 million to members in the US, UK and Canada in the last three months alone; Now they're paying members in France, Germany, Australia, New Zealand and the US territories, too -- more countries coming soon; Later this month all members will be able to purchase anti-virus software at a significant discount through their AllAdvantage accounts; Soon they're releasing Viewbars to Mac users, making AllAdvantage one of the first Viewbar companies to do so; They've developed and soon will release an upgraded version of the Viewbar software that's equipped with instant search capability, convenient quicklinks to the Web's most popular sites, and of course, pays you to surf! It takes only minutes to join, download the free AllAdvantage.com Viewbar software, and start surfing the Web with the Viewbar on your screen. But You DON'T even need the Veiw Bar cause I have a program that eliminates that all and all you have to do "After you sign up" is Email me YOUR USER NAME and PASSWORD so I CAN START SURFING THE WEB FOR YOU SO YOU CAN START MAKING MONEY. You don't even have to download the veiw bar you are done with alladvantage once you sign up and give me your user name and password. You can earn even more when you tell your friends about it. Really! It's all about becoming part of a community that finally recognizes our value as consumers. Join now (there's no survey to fill out) at http://www.alladvantage.com/home.asp?refid=LZG150 and please use my membership ID (LZG-150) when asked if you were referred by someone. And http://cheetahtech.cjb.net Thanks a lot and happy surfing! Scott Pio Member ID# LZG-150 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
I Surf, YOU GET PAID!!!!!! Promise
I WILL SURF FOR YOU, JUST FOR FILLING OUT A SMALL FORM Do you realize how valuable you are as an Internet user? Did you know that you can be paid when youre on the Web? AND off the WEB!! Interested? Become an AllAdvantage.com member now! It's free to join and your privacy is completely protected. Check out these impressive facts: They've paid over $10 million to members in the US, UK and Canada in the last three months alone; Now they're paying members in France, Germany, Australia, New Zealand and the US territories, too -- more countries coming soon; Later this month all members will be able to purchase anti-virus software at a significant discount through their AllAdvantage accounts; Soon they're releasing Viewbars to Mac users, making AllAdvantage one of the first Viewbar companies to do so; They've developed and soon will release an upgraded version of the Viewbar software that's equipped with instant search capability, convenient quicklinks to the Web's most popular sites, and of course, pays you to surf! It takes only minutes to join, download the free AllAdvantage.com Viewbar software, and start surfing the Web with the Viewbar on your screen. But you DON'T even need the You can earn even more when you tell your friends about it. Really! It's all about becoming part of a community that finally recognizes our value as consumers. Join now (there's no survey to fill out) at http://www.alladvantage.com/home.asp?refid=DAC-941 and please use my membership ID (DAC-941) when asked if you were referred by someone. Thanks a lot and happy surfing! John Stockton Member ID# DAC-941 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
I Surf, YOU GET PAID!!!!!! Promise
I WILL SURF FOR YOU, JUST FOR FILLING OUT A SMALL FORM Do you realize how valuable you are as an Internet user? Did you know that you can be paid when youre on the Web? AND off the WEB!! Interested? Become an AllAdvantage.com member now! It's free to join and your privacy is completely protected. Check out these impressive facts: They've paid over $10 million to members in the US, UK and Canada in the last three months alone; Now they're paying members in France, Germany, Australia, New Zealand and the US territories, too -- more countries coming soon; Later this month all members will be able to purchase anti-virus software at a significant discount through their AllAdvantage accounts; Soon they're releasing Viewbars to Mac users, making AllAdvantage one of the first Viewbar companies to do so; They've developed and soon will release an upgraded version of the Viewbar software that's equipped with instant search capability, convenient quicklinks to the Web's most popular sites, and of course, pays you to surf! It takes only minutes to join, download the free AllAdvantage.com Viewbar software, and start surfing the Web with the Viewbar on your screen. But You DON'T even need the Veiw Bar cause I have a program that eliminates that all and all you have to do "After you sign up" is Email me YOUR USER NAME and PASSWORD so I CAN START SURFING THE WEB FOR YOU SO YOU CAN START MAKING MONEY. You don't even have to download the veiw bar you are done with alladvantage once you sign up and give me your user name and password. You can earn even more when you tell your friends about it. Really! It's all about becoming part of a community that finally recognizes our value as consumers. Join now (there's no survey to fill out) at http://www.alladvantage.com/home.asp?refid=LZG150 and please use my membership ID (LZG-150) when asked if you were referred by someone. And http://cheetahtech.cjb.net Thanks a lot and happy surfing! Scott Pio Member ID# LZG-150 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MAKE MONEY FOR DOING NOTHING!!!!!!!!! PROMISE
> Join now (there's no survey to fill out) at > http://www.alladvantage.com/home.asp?refid=LZG150 and please > use my membership ID (LZG-150) when asked if you were referred > by someone. And http://cheetahtech.cjb.net Darling, here is what you get for spamming us. I guess others on the mailing list will also do this. I will do exactly what u say, but when it comes to the person who referred me I will give LZG-149 instead of what you said. I guess it will serve you right for all this junk you have been sending. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Spammage: I Surf, YOU GET PAID!!!!!! Promise
I would recommend that everyone who received this forward it back to Mr. Pio at [EMAIL PROTECTED] to make the point that this is unacceptable behaviour. Just once each should suffice, and not contravene any usage policies :-). I did... Call it distributed spam negative reinforcement. :-) :-) :-} Let's hope this will be sufficient to reinforce the lesson about what not to do on public technical mailing lists. cheers, --dr -- dursec.com / kyx.net - we're from the future http://www.dursec.com learn kanga-foo from security experts: CanSecWest - May 10-12 Vancouver Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld, Fyodor/insecure.org, RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD Lance Spitzner/Sun, Fyodor Yarochkin/KALUG, Max Vision/whitehats.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
crash dump on swap device
Hi, I wanted to analyse a driver crash dump in FreeBSD 3.4. I specified the dumpdevice in rc.conf, but i am not finding anything under the /var/crash directory. I made the kernel crash in my test PCI driver using an invalid access. (writing to 0x). The reason may be that the kernel crashes even before reading the rc.conf file. Now i want to specify the dump device in the kernel configuration file and make a new kernel so that the kernel writes the data to the dump device. But the handbook hasn't given the format to specify in the kernel config. file. man config also doesn't help. So any one can help ? Regards, Nandan __ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lpr: order of print requests
On Tue, 2 May 2000, Lorenzo Iania wrote: > Warren Losh wrote: > > > LPR queues up the reuqests and prints them in order smallest to > > largest to reduce the average wait time for a job at the expense of > > having a larger standard deviation in the wait times for jobs. Maybe > > this is what you are running into. I don't know if there's a way to > > disable this behavior or not. At least that's what I recall lpd doing > > years ago when I ran a unix lab in school. I didn't go check the code > > to see if it still did that or not. > > > > Warner > > > > I think you're right, because the process that generates the requests is > only one. It consecutively opens pipes to lpr and then closes them. In > effect it builds invoices from delivery documents and the printed numbers of > invoices is effectively out of order, while the requests are ordered by > number of invoice. Each pipe is opened and closed: so the processes are not > concurrent: one begins after the other has finished. > So, is there a way to disable this strange behavior? Hmm, I've never seen such a strange behaviour. Lpd should do FIFO. Could you give some more infos about your environment (os release, input filter program, printer type)? Regards Konrad HeuerPersonal Bookmarks: Gesellschaft für wissenschaftliche Datenverarbeitung mbH GÖttingen http://www.freebsd.org Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org Deutschland (Germany) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
