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 idle_loop+64 (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 stdio.h
FILE
*fp
;
main(){register int
i ;
for
(i=0;i1000;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 ? -- a href="http://www.poohsticks.org/drew/"Home Page/a 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 Heuerwrote
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
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
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
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/EY, 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
