Re: Possible bug in scheduler.
John Baldwin wrote: On 18-Oct-01 Alexander Langer wrote: Thus spake Alex Levine ([EMAIL PROTECTED]): resetpriority() calls maybe_resched() at the end after updating p_usrpri based on changed p_estcpu. maybe_resched() uses curpriority_cmp to compare priorities of current and given process and this function ( curpriority_cmp ) uses p_priority which is unchanged yet - the new p_usrpri is not reflected to p_priority yet. In -CURRENT, it's more obvious: maybe_resched() only rescheds, if the resetted process' priority level changes. Since resetpriority() doesn't modify the priority level but only the user priority, the call to maybe_resched() has no effect at all -- only some overhead for the comparisons (curproc will have had the higher or same priority level as the resetted process anyways, otherwise it hadn't been curproc :) So, either - p's priority level in resetpriority has to be re-calculted as well, or - the call to maybe_resched() can be removed w/o loss of functionality. or c) in the preemptive kernel maybe_resched() doesn't exist as it's functionality is more properly handled in other places. I took another look in CURRENT. The same call to maybe_resched from reset_priority is as useless as in STABLE. Only there the recalculation relies on pri_level, which replaced p_priority as I understand but the thing which is being changed is usr_pri. So it's the same. Regards, Alex Levine To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
question about mmap() on FreeBSD3.3
Hello I have a question about the behavior of mmap() in the kernel built without VM_STACK option. The platform is FreeBSD3.3. When the area allocated by mmap() overlaps the area between vm_maxsaddr and USRSTACK, accessing the overlapped area causes Segmentation Fault, although mmap() is returned successfully. Is this a bug or the intended behavior? Looking through the source code, what happens seems: When grow() is called by the page fault handler trap_pfault(), grow() failes to grow a user stack area because virtual address space has already been taken by mmap(). - Kenji Kaneshige [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vmiodirenable vs isofs, some proof
About a month ago I suggested that vfs.vmiodirenable=1 and the cd9660 file system interract badly. I have not got absolute proof, but I think fairly good evidence of a causal link. At work I have an Athlon 1.4GHz with 512MB ram, IDE disk, IDE burner running FreeBSD 4.4 (no special options). For the last few days, I have had vfs.vmiodirenable=1 without any non-CD related strangeness. I mounted a CD full of mp3s (about 600MB). I copied the contents to the IDE disk (using tar piped to tar). Other programs were active (linux opera, xmms, xterms, probably others), but I wasn't thrashing the box. Shortly after copying the files, I noticed that many files had the wrong contents. In particular, in most directories, the n'th file had the contents of the n'th file of the first directory. I verified that the mounted CD was in this peculiar state. Files read from the CD had the wrong contents. I copied the files several more times, and the particular file substitutions remained stable (ie the same files had the same wrong contents). I set vfs.vmiodirenable=0 and copied again. Exactly the same incorrect files. In other words, the corruption, whatever it is, was not magically removed by disabling vmiodirenable while the cache remained. I unmounted and remounted the CD. A copy operation was flawless at this point (vmiodirenable still off). I enabled vmiodirenable and the next copy was corrupt in the same manner (cross linked files), but the set of cross links was different than before. (Dang, I can't remember if I did another unmount/remount cycle before this copy. Oh well.) At this point, I noticed that the cross links were actual hard links in my HD copies. (I should have noticed how fast they were copying, I suppose). Using ls -li on the cdrom showed low inode numbers instead of the high numbers you would expect, and most directories contained the same set of low inode numbers. (Again I have erred. I've left my saved directory listings at work. The bad inums were 1000 while normal inums are 5, at least on this CD.) Is this enough for you to form a theory? Any more experiments you think would be worthwhile? Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Tim, Your license with SBS for the DDK would prevent you from posting your code. If you read through it, you'll find that it prohibits the release of any of their DDK code under any circumstances. You could release everything EXCEPT the API for the card that SBS provides and offer the rest in object-only format. Doug On Thu, 18 Oct 2001, Tim Wiess wrote: If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. I'm actually working on a driver for the SBS WANic 600 and 800 cards. There is still a lot of work and testing to be done, but (assuming there are no problems with the powers that be over here, and there are no conflicts with our agreements with SBS) I do eventually plan on posting the code (under a BSD license). I'll keep y'all posted. tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Possible bug in scheduler.
On 19-Oct-01 Alex Levine wrote: John Baldwin wrote: On 18-Oct-01 Alexander Langer wrote: Thus spake Alex Levine ([EMAIL PROTECTED]): resetpriority() calls maybe_resched() at the end after updating p_usrpri based on changed p_estcpu. maybe_resched() uses curpriority_cmp to compare priorities of current and given process and this function ( curpriority_cmp ) uses p_priority which is unchanged yet - the new p_usrpri is not reflected to p_priority yet. In -CURRENT, it's more obvious: maybe_resched() only rescheds, if the resetted process' priority level changes. Since resetpriority() doesn't modify the priority level but only the user priority, the call to maybe_resched() has no effect at all -- only some overhead for the comparisons (curproc will have had the higher or same priority level as the resetted process anyways, otherwise it hadn't been curproc :) So, either - p's priority level in resetpriority has to be re-calculted as well, or - the call to maybe_resched() can be removed w/o loss of functionality. or c) in the preemptive kernel maybe_resched() doesn't exist as it's functionality is more properly handled in other places. I took another look in CURRENT. The same call to maybe_resched from reset_priority is as useless as in STABLE. Only there the recalculation relies on pri_level, which replaced p_priority as I understand but the thing which is being changed is usr_pri. So it's the same. Yes, but in the uncommitted (b/c it's not fully stable and I need to update the patches) preemptive kernel, it doesn't exist. :) So it will be fixed in -current by removing it in favor of something else. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
On Thu, 18 Oct 2001, Mike Smith wrote: Well, honestly, FreeBSD makes the life of the developers of third-party binary-only drivers fairly difficult. It does? On the whole, actually, I'd say we do a pretty good job of making it easy. The reason is that there are a lot of API changes happening between the releases (take Julian Elisher's recent problem for example). It's a poor example. Drivers don't involve themselves in the sysinit chain. welll it gets involved.. if you redefine the SYSINIT values, old drivers's aren't 'notified' (should be a module but the supplier didn't make one..) So the driver writers are forced to at least recompile their drivers for each release. This isn't typically the case, actually. 4.x has in fact been very good in this regard. with the above exception, I agree. though in userland, the library changes have caused us some grief. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Circular log patches for syslog
-Original Message- From: Peter Wullinger [mailto:[EMAIL PROTECTED]] Subject: Re: Circular log patches for syslog Just to spoil the thread: Shouldn't things like this be available as additional package, so that the base system supplies only bas(e)ic functionality an everything else should be available as packages only? I would certainly be glad if these patches were incorporated into FreeBSD proper, just to eliminate the need to track future changes to syslogd and produce new (possibly buggy) patches. However, it is not clear that this feature is of wide enough usefulness to warrant that. Since it requires both a patch to an existing system utility and a new utility, it doesn't fit the package metaphor very well either. Hence, the patch and utility are available from my web page. I'm not sure I fully understand your concern, or the definition of basic functionality but I can certainly say that it would be tough for it to be more modular and optional than it is right now. :) From what I have learned, it is possible that this would be suited to .../src/release/picobsd/tinyware but even that seems premature right now. Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: patch #3 (was Re: bleh. Re: ufs_rename panic)
FYI: http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-10-15end=2001-10-21 (about how things done in Linux). Zhihui Zhang wrote: (1) I am always wondering why not use a global rename lock so that there is only one rename operation in progress at any time. This method is used by GFS and probably Linux. This could make the code simply. Maybe we can even get rid of the relookup() stuff. This may reduce concurrency, but rename should not be a frequent operation. -- Yevgeniy Aleynikov Infospace, Inc. SysAdmin, USE Work: (206)357-4594 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmiodirenable vs isofs, some proof
-Matt Matthew Dillon [EMAIL PROTECTED] :About a month ago I suggested that vfs.vmiodirenable=1 and the cd9660 :file system interract badly. I have not got absolute proof, but I :think fairly good evidence of a causal link. :... :I set vfs.vmiodirenable=0 and copied again. Exactly the same incorrect :files. In other words, the corruption, whatever it is, was not magically :removed by disabling vmiodirenable while the cache remained. Turning off vmiodirenable does not effect things that are already VMIO backed, so this is expected. :I unmounted and remounted the CD. A copy operation was flawless at this :point (vmiodirenable still off). : :I enabled vmiodirenable and the next copy was corrupt in the same manner :(cross linked files), but the set of cross links was different than before. :(Dang, I can't remember if I did another unmount/remount cycle before :this copy. Oh well.) : :At this point, I noticed that the cross links were actual hard links :in my HD copies. (I should have noticed how fast they were copying, I :suppose). :.. :Is this enough for you to form a theory? Any more experiments you :think would be worthwhile? : :Stephen. It sure looks like you can reproduce the bug at will, which is great! Now I need to reproduce it over here. If you could email me an ls -liaR of the CD with vmiodirenable turned off, and another ls -liaR of the CD with vmiodirenable turned on and the corruption present, I should be able to use that to burn a junk CD of my own to try to reproduce the bug. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
SBS WANic (was FYI)
I don't doubt that. As I mentioned, there are several factors that I need to check into, especially our agreements with SBS. tim On Fri, 19 Oct 2001, Doug Hass wrote: Tim, Your license with SBS for the DDK would prevent you from posting your code. If you read through it, you'll find that it prohibits the release of any of their DDK code under any circumstances. You could release everything EXCEPT the API for the card that SBS provides and offer the rest in object-only format. Doug On Thu, 18 Oct 2001, Tim Wiess wrote: If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. I'm actually working on a driver for the SBS WANic 600 and 800 cards. There is still a lot of work and testing to be done, but (assuming there are no problems with the powers that be over here, and there are no conflicts with our agreements with SBS) I do eventually plan on posting the code (under a BSD license). I'll keep y'all posted. tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
On Thu, Oct 18, 2001 at 11:29:59PM +0200, Cyrille Lefevre wrote: I've prepared a status report about this project. the xml file in attachment have to be reviewed since I've just put descriptions from FreeBSD-rc's Yahoo! Group and your email message. WHY in the world are you sending in a status report about this? From this thread we are still flushing out details to the point there is nothing we can say. first of all, there should be a consensus about the owner of this project ? also, who create the FreeBSD-rc's Yahoo! Group ? We don't need a Yahoo! group. There is zero wrong with the archived FreeBSD mailing lists. They have worked for FreeBSD development for 8 years now. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
David O'Brien wrote: On Thu, Oct 18, 2001 at 11:29:59PM +0200, Cyrille Lefevre wrote: I've prepared a status report about this project. the xml file in attachment have to be reviewed since I've just put descriptions from FreeBSD-rc's Yahoo! Group and your email message. WHY in the world are you sending in a status report about this? to record this task as a real project and to avoid duplicates works... From this thread we are still flushing out details to the point there is nothing we can say. first of all, there should be a consensus about the owner of this project ? also, who create the FreeBSD-rc's Yahoo! Group ? We don't need a Yahoo! group. There is zero wrong with the archived FreeBSD mailing lists. They have worked for FreeBSD development for 8 years now. I'm just reporting this one exists as you report the existence of Kevin Way's work two days ago. of course, it would be better to have a -rc mailing list. Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
system hung with runnable processes
I didn't see anything like this in the archives, so I'm sending this to the questions list and hackers list for assistance. I am running FreeBSD 4.3 on a L440GX+ motherboard with dual PCI buses: 32/33 and 32/66 dual Pentium III @ 700MHz with 256KB L2 cache. The system is running in Uniprocessor mode. Although running the tests on FreeBSD 4.1 has not caused the problem. My problem: I have an application that reads from a SCSI bus, and forwards the SCSI CDB's to another system over TCP. When running a large load the system gets SCSI bus device reset's that the application acknowledges and clears an error bit. After a period of time, in this example about 2.5 hours, the system stops processing any SCSI CDB's. In DDB the ps output show 11 runnable process, p_wchan == 0, and curproc points to one of the processes. However, when checking the run queues via gdb, none of the runnable processes is in a run queue. According to rtqueuebits, queuebits, and idqueuebits, only queue[12] has any runnable processes. Examing the proc structures for the runnable processes, their priority is 6, so they should be in queue[6]. I cannot determine anything obvious in the process scheduling code, but something is happening. I am attaching the system dmesg output from boot to taking the system dump, the ddb output on the serial console, and the output from gdb of the process' stack trace and proc structure. If anyone needs more information just ask and I'll try to get it for you. Does anyone believe upgrading to FreeBSD 4.4 would resolve the problem? == /var/run/dmesg output = Oct 15 11:15:54 nstg19 su: jkf to root on /dev/ttyp0 Oct 15 11:26:10 nstg19 su: fgu to root on /dev/ttyp1 Oct 15 11:38:54 nstg19 reboot: rebooted by fgu Oct 15 11:38:54 nstg19 syslogd: exiting on signal 15 Oct 15 11:40:55 nstg19 /kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Oct 15 11:40:55 nstg19 /kernel: Waiting (max 60 seconds) for system process `syncer' to stop...stopped Oct 15 11:40:55 nstg19 /kernel: Oct 15 11:40:55 nstg19 /kernel: syncing disks... Oct 15 11:40:55 nstg19 /kernel: done Oct 15 11:40:55 nstg19 /kernel: Uptime: 2d20h1m57s Oct 15 11:40:55 nstg19 /kernel: Rebooting... Oct 15 11:40:55 nstg19 /kernel: Copyright (c) 1992-2001 The FreeBSD Project. Oct 15 11:40:55 nstg19 /kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Oct 15 11:40:55 nstg19 /kernel: The Regents of the University of California. All rights reserved. Oct 15 11:40:55 nstg19 /kernel: FreeBSD 4.3-RELEASE #0: Mon Oct 15 11:35:39 EDT 2001 Oct 15 11:40:55 nstg19 /kernel: [EMAIL PROTECTED]:/usr/src/sys/compile/NSTG19.FGU.UP Oct 15 11:40:55 nstg19 /kernel: Timecounter i8254 frequency 1193182 Hz Oct 15 11:40:55 nstg19 /kernel: CPU: Pentium III/Pentium III Xeon/Celeron (999.53-MHz 686-class CPU) Oct 15 11:40:55 nstg19 /kernel: Origin = GenuineIntel Id = 0x686 Stepping = 6 Oct 15 11:40:55 nstg19 /kernel: Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Oct 15 11:40:55 nstg19 /kernel: real memory = 1073676288 (1048512K bytes) Oct 15 11:40:55 nstg19 /kernel: avail memory = 1040621568 (1016232K bytes) Oct 15 11:40:55 nstg19 /kernel: Preloaded elf kernel kernel at 0xc04ed000. Oct 15 11:40:55 nstg19 /kernel: Pentium Pro MTRR support enabled Oct 15 11:40:55 nstg19 /kernel: md0: Malloc disk Oct 15 11:40:55 nstg19 /kernel: npx0: math processor on motherboard Oct 15 11:40:55 nstg19 /kernel: npx0: INT 16 interface Oct 15 11:40:55 nstg19 /kernel: pcib0: ServerWorks host to PCI bridge on motherboard Oct 15 11:40:55 nstg19 /kernel: pci0: PCI bus on pcib0 Oct 15 11:40:55 nstg19 /kernel: nvram probe: type: 81166 Oct 15 11:40:55 nstg19 /kernel: nvram probe: type: 91166 Oct 15 11:40:55 nstg19 /kernel: pcib4: PCI to PCI bridge (vendor=1166 device=0009) at device 0.1 on pci0 Oct 15 11:40:55 nstg19 /kernel: pci1: PCI bus on pcib4 Oct 15 11:40:55 nstg19 /kernel: nvram probe: type: 474d1002 Oct 15 11:40:55 nstg19 /kernel: pci1: ATI Mach64-GM graphics accelerator at 0.0 irq 11 Oct 15 11:40:55 nstg19 /kernel: nvram probe: type: 61166 Oct 15 11:40:55 nstg19 /kernel: nvram probe: type: 61166 Oct 15 11:40:55 nstg19 /kernel: nvram probe: type: 109005 Oct 15 11:40:55 nstg19 /kernel: ahc0: Adaptec 2940 Ultra2 SCSI adapter port 0xde00-0xdeff mem 0xfeafa000-0xfeafafff irq 11 at device 3.0 on pci0 Oct 15 11:40:55 nstg19 /kernel: aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs Oct 15 11:40:55 nstg19 /kernel: nvram probe: type: cf9005 Oct 15 11:40:55 nstg19 /kernel: ahc1: Adaptec aic7899 Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xfeafb000-0xfeafbfff irq 5 at device 5.0 on pci0 Oct 15 11:40:55 nstg19 /kernel: aic7899: Wide Channel A, SCSI Id=7, 32/255 SCBs Oct 15 11:40:55 nstg19 /kernel: nvram probe: type: cf9005 Oct 15 11:40:55 nstg19 /kernel: ahc2: Adaptec aic7899 Ultra160 SCSI adapter port
RE: Circular log patches for syslog
Jeffrey D. Wheelhouse [EMAIL PROTECTED] types: -Original Message- From: Peter Wullinger [mailto:[EMAIL PROTECTED]] Subject: Re: Circular log patches for syslog Just to spoil the thread: Shouldn't things like this be available as additional package, so that the base system supplies only bas(e)ic functionality an everything else should be available as packages only? I would certainly be glad if these patches were incorporated into FreeBSD proper, just to eliminate the need to track future changes to syslogd and produce new (possibly buggy) patches. However, it is not clear that this feature is of wide enough usefulness to warrant that. Since it requires both a patch to an existing system utility and a new utility, it doesn't fit the package metaphor very well either. I almost commented on this one earlier - there's a utility in ports called flog which I use to avoid your general problem - that of running out of space on the logging device. It's not as nice a solution as you've got, though, so I skipped it. However, there are lots of system utilities that have replacements in the ports tree. In particular, there are at least two syslog daemons, one of which - msyslog - supports modules for input and output processing. Possibly this functionality could be done as an output module for msyslog, and that bundled as a port. Or even given back to the msyslog project. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
Cyrille Lefevre [EMAIL PROTECTED] wrote: I'm just reporting this one exists as you report the existence of Kevin Way's work two days ago. of course, it would be better to have a -rc mailing list. Not really. One more list to follow, when threads in existing lists will probably be enough for this. We don't have one mailing list for every port category, or for every different part of contrib/. It's overkill to create a list for something like this IMHO :/ -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more on Re: Please review: bugfix for vinvalbuf()
Unfortunately, the recent patch to vinvalbuf() hasn't solved all of
our problems. We had another, different panic today. The process that
caused it was a 'tail' of a growing logfile over NFS.
I have actually had this problem before, with FreeBSD 3.4, and reported
it then. I believed this PR to be relevant at the time, however, I do
not believe this client was writing to the file.
[1998/06/23] kern/7028 http://www.freebsd.org/cgi/query-pr.cgi?pr=7028
panic in vinvalbuf when appending/looking at tail of NFS file
The system is running 4.4-RELEASE with the vinvalbuf() patch. Debugging
information is below. If I can provide any additional information,
let me know.
Thanks for any help,
Doug
-- panic message --
SMP 2 cpus
IdlePTD 3555328
initial pcb at 2cf300
panicstr: vinvalbuf: flush failed
panic messages:
---
panic: vinvalbuf: flush failed
mp_lock = 0101; cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... 8
done
Uptime: 19d20h13m23s
-- gdb session --
(kgdb) back
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:473
#1 0xc016cf8f in boot (howto=0x100) at /usr/src/sys/kern/kern_shutdown.c:313
#2 0xc016d3a9 in panic (fmt=0xc028745a vinvalbuf: flush failed)
at /usr/src/sys/kern/kern_shutdown.c:581
#3 0xc019a719 in vinvalbuf (vp=0xd7dde8c0, flags=0x1, cred=0xc2c60780,
p=0xd79a0680, slpflag=0x100, slptimeo=0x0)
at /usr/src/sys/kern/vfs_subr.c:753
#4 0xc01d0b30 in nfs_vinvalbuf (vp=0xd7dde8c0, flags=0x1, cred=0xc2c60780,
p=0xd79a0680, intrflg=0x1) at /usr/src/sys/nfs/nfs_bio.c:1190
#5 0xc01cf668 in nfs_bioread (vp=0xd7dde8c0, uio=0xd7a42ed4,
ioflag=0x7f, cred=0xc2c60780) at /usr/src/sys/nfs/nfs_bio.c:401
#6 0xc01f68d2 in nfs_read (ap=0xd7a42e64)
at /usr/src/sys/nfs/nfs_vnops.c:1008
#7 0xc01a235c in vn_read (fp=0xc254cd40, uio=0xd7a42ed4, cred=0xc2c60780,
flags=0x0, p=0xd79a0680) at vnode_if.h:334
#8 0xc017b690 in dofileread (p=0xd79a0680, fp=0xc254cd40, fd=0x3,
buf=0x804d000, nbyte=0x200, offset=0x, flags=0x0)
at /usr/src/sys/sys/file.h:146
#9 0xc017b556 in read (p=0xd79a0680, uap=0xd7a42f80)
at /usr/src/sys/kern/sys_generic.c:117
#10 0xc025d7b5 in syscall2 (frame={tf_fs = 0x2f, tf_es = 0x2f,
tf_ds = 0xbfbf002f, tf_edi = 0x4, tf_esi = 0x280fc3a0,
tf_ebp = 0xbfbff8c0, tf_isp = 0xd7a42fd4, tf_ebx = 0x280ea424,
tf_edx = 0x37, tf_ecx = 0x37, tf_eax = 0x3, tf_trapno = 0x7,
tf_err = 0x2, tf_eip = 0x280defcc, tf_cs = 0x1f, tf_eflags = 0x293,
tf_esp = 0xbfbff894, tf_ss = 0x2f})
at /usr/src/sys/i386/i386/trap.c:1155
#11 0xc024a62b in Xint0x80_syscall ()
cannot read proc at 0
(kgdb) up
#1 0xc016cf8f in boot (howto=0x100) at /usr/src/sys/kern/kern_shutdown.c:313
313 dumpsys();
(kgdb) up
#2 0xc016d3a9 in panic (fmt=0xc028745a vinvalbuf: flush failed)
at /usr/src/sys/kern/kern_shutdown.c:581
581 boot(bootopt);
(kgdb) up
#3 0xc019a719 in vinvalbuf (vp=0xd7dde8c0, flags=0x1, cred=0xc2c60780,
p=0xd79a0680, slpflag=0x100, slptimeo=0x0)
at /usr/src/sys/kern/vfs_subr.c:753
753 panic(vinvalbuf: flush failed);
(kgdb) print vp-v_dirtyblkhd
$1 = {tqh_first = 0x0, tqh_last = 0xd7dde8f4}
(kgdb) print vp-v_cleanblkhd
$2 = {tqh_first = 0xcc5fa5ec, tqh_last = 0xcc5fa5f4}
(kgdb) print *(vp-v_cleanblkhd-tqh_first)
$3 = {b_hash = {le_next = 0xcc607e80, le_prev = 0xcc666e9c}, b_vnbufs = {
tqe_next = 0x0, tqe_prev = 0xd7dde8ec}, b_freelist = {
tqe_next = 0xcc5f8bfc, tqe_prev = 0xcc6060bc}, b_act = {tqe_next = 0x0,
tqe_prev = 0xc2001d90}, b_flags = 537919520, b_qindex = 2,
b_xflags = 2 '\002', b_lock = {lk_interlock = {lock_data = 0},
lk_flags = 0, lk_sharecount = 0, lk_waitcount = 0,
lk_exclusivecount = 0, lk_prio = 20, lk_wmesg = 0xc02860b0 bufwait,
lk_timo = 0, lk_lockholder = -1}, b_error = 0, b_bufsize = 3584,
b_runningbufspace = 0, b_bcount = 3147, b_resid = 0, b_dev = 0x,
b_data = 0xceeec000 ...,
b_kvabase = 0xceeec000 ...,
b_kvasize = 16384, b_lblkno = 6949, b_blkno = 84, b_offset = 56926208,
b_iodone = 0, b_iodone_chain = 0x0, b_vp = 0xd7dde8c0, b_dirtyoff = 0,
b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_pblkno = 1771566,
b_saveaddr = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_caller1 = 0x0,
b_caller2 = 0x0, b_pager = {pg_spc = 0x0, pg_reqpage = 0}, b_cluster = {
cluster_head = {tqh_first = 0xcc5c66a0, tqh_last = 0xcc640720},
cluster_entry = {tqe_next = 0xcc5c66a0, tqe_prev = 0xcc640720}},
b_pages = {0xc0afb4ac, 0x0 repeats 31 times}, b_npages = 1, b_dep = {
lh_first = 0x0}, b_chain = {parent = 0x0, count = 0}}
(kgdb) up
#4 0xc01d0b30 in nfs_vinvalbuf (vp=0xd7dde8c0, flags=0x1, cred=0xc2c60780,
p=0xd79a0680, intrflg=0x1) at /usr/src/sys/nfs/nfs_bio.c:1190
1190error = vinvalbuf(vp, flags, cred, p, 0, slptimeo);
(kgdb) print p-p_pid
$4 = 0x14594
(kgdb) btp 83348
frame 0 at 0xd7a42cb4: ebp d7a42cd8, eip 0xc016cf8f
Re: more on Re: Please review: bugfix for vinvalbuf()
On Fri, Oct 19, 2001 at 09:51:10PM -0700, Matthew Dillon wrote: : :Unfortunately, the recent patch to vinvalbuf() hasn't solved all of :our problems. We had another, different panic today. The process that :caused it was a 'tail' of a growing logfile over NFS. : :I have actually had this problem before, with FreeBSD 3.4, and reported :it then. I believed this PR to be relevant at the time, however, I do :not believe this client was writing to the file. : : [1998/06/23] kern/7028 http://www.freebsd.org/cgi/query-pr.cgi?pr=7028 : panic in vinvalbuf when appending/looking at tail of NFS file : :The system is running 4.4-RELEASE with the vinvalbuf() patch. Debugging :information is below. If I can provide any additional information, :let me know. : :Thanks for any help, :Doug How easily can you reproduce this? How often does it occur if you leave a tail running? -Matt I'm not able to reproduce this at will at the moment. The PR I mention has a program which it claims can cause the crash, which I will try running. I'll also try tailing various logfiles, including the one which caused this crash, which is being written to on the machine that is the NFS server. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more on Re: Please review: bugfix for vinvalbuf()
:I'm not able to reproduce this at will at the moment. The PR I mention :has a program which it claims can cause the crash, which I will try :running. I'll also try tailing various logfiles, including the one which :caused this crash, which is being written to on the machine that is the :NFS server. : :Doug In looking at the code the solution may simply be to loop back up to the top of vinvalbuf() instead of panic if we wind up with buffer cache buffers. If V_SAVE is set the act of writing dirty VM pages can cause new buffer to instantiate and result in the panic. But I would really like to get the bug reproduceable to make sure that the solution really does fix it. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
fxp driver - receive interrupt bundling
On http://fly.cc.fer.hr/~zec/index.html you can find a 4.4-RELEASE fxp driver source, with patches that incorporate receive interrupt bundling microcode, borrowed from the Intel's Linux e100 driver. Bundling interrupts for a couple of received Ethernet frames can significantly lower interrupt processing overhead, so if you have a really busy server or router or whatever this code can make a noticeable difference. On an 1200 MHz Athlon machine, the microcode saves around 10% of CPU utilization, with incoming traffic of 20k pps on a single interface. The code is tested on 82558 rev B0 hardware, I'd be glad to know how it works on other versions of Intel's fxp cards. Pls. send your comments, suggestions etc. to [EMAIL PROTECTED] Have fun! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
On Thu, Oct 18, 2001 at 09:47:53PM +0200, Dag-Erling Smorgrav wrote: Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Your rcorder patch is incorrect. Here's a correct patch. Does anybody mind if I commit this and connect rcorder(8) to the build? YES I MIND!! What part of it is on the vendor branch for now don't you understand? Stop picking at the trival fruit on the ground and instead help with the fruit in /etc/rc.d/. I really didn't think this thread was going to bikeshed, but I was very wrong. Lets work on an actual prototype (who cares if it is rough) so we have something that actually does *something*. If you don't like my patch, you are certainly free to post another one. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
On 18-Oct-01 Dag-Erling Smorgrav wrote: Gordon Tetlow [EMAIL PROTECTED] writes: Actually, fparseln() is defined in libutil.h (per the man page). I don't have my current box available (power outage at home), but if you could look over it, it should work. Ah, that's right - I couldn't find the right header, I should have simply looked at the libutil Makefile. Thanks! Or the fparseln(3) manpage which lists the includes. :) -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
TCP windowsize...
Hi, Is there someone who can tell me how to set TCP windowsize? Best Regards, Gunnar Gunnar Olsson Phone: +46 8 5062 5762 Xelerated Packet Devices AB Fax: +46 8 5455 3211 Regeringsgatan 67 Mobile: +46 73 3279765 SE-10386 Stockholm Web: http://www.xelerated.com Email: mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: fxp driver - receive interrupt bundling
On http://fly.cc.fer.hr/~zec/index.html you can find a 4.4-RELEASE fxp driver source, with patches that incorporate receive interrupt bundling microcode, borrowed from the Intel's Linux e100 driver. Bundling interrupts for a couple of received Ethernet frames can significantly lower interrupt processing overhead, so if you have a really busy server or router or whatever this code can make a noticeable difference. On an 1200 MHz Athlon machine, the microcode saves around 10% of CPU utilization, with incoming traffic of 20k pps on a single interface. The code is tested on 82558 rev B0 hardware, I'd be glad to know how it works on other versions of Intel's fxp cards. Pls. send your comments, suggestions etc. to [EMAIL PROTECTED] Have fun! Nifty! -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
On 18 Oct 2001, Dag-Erling Smorgrav wrote: John Baldwin [EMAIL PROTECTED] writes: Huh? Int on alpha is 32, and pointer is 64. I thought we were ILP64 on 64-bit archs, but you're right. And I ought to know better... Fortunately (?) it doesn't matter in this case. Function arguments which are passed in registers are all promoted to 64bits. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
