hold off on commits
I'm trying to generate and commit a correct backout of David's changes. but since I have to synthesise the backout patch from cvs and check it could people refrain from updating the following files? I believe this is the complete set that are involved. (if you know of any others let me know) alpha/alpha/interrupt.c alpha/alpha/trap.c alpha/alpha/vm_machdep.c ddb/db_ps.c i386/i386/critical.c i386/i386/exception.s i386/i386/genassym.c i386/i386/trap.c i386/i386/vm_machdep.c i386/i386/mp_machdep.c ia64/ia64/trap.c ia64/ia64/interrupt.c ia64/ia64/vm_machdep.c kern/init_main.c kern/kern_clock.c kern/kern_exec.c kern/kern_exit.c kern/kern_fork.c kern/kern_lock.c kern/kern_resource.c kern/kern_sig.c kern/kern_switch.c kern/kern_thread.c kern/subr_prof.c kern/subr_trap.c kern/subr_witness.c powerpc/powerpc/vm_machdep.c sparc64/sparc64/mp_machdep.c sparc64/sparc64/trap.c sparc64/sparc64/vm_machdep.c sys/buf.h sys/lockmgr.h sys/proc.h sys/resourcevar.h sys/systm.h To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
split out patch
I'm working on backing out david's patch. Part of his megacommit was a patch that should ahve been separatly handled. I have split it out.. Can people have a look at it and see if it makes sense. http://www.freebsd.org/~julian/lock.diff basically locks need to be per thread but were per process. Can we just use a thread* for this? I think so but I wonder why it wasn't a proc* before.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Request for info from SiS chipset owners
I'm currently in the midst of an ATA chipset support mega rewrite/update, and the last item on the list is SiS support. That where _you_ come into the picture, I need a pciconf -l from your SiS based system! Just reply to this message with the output from pciconf -l and you have helped me sort out the myriads of SiS chipsets out there. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request for info from SiS chipset owners
Hope this helps: agp0@pci0:0:0: class=0x06 card=0x chip=0x07351039 rev=0x01 hdr=0x00 pcib1@pci0:1:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01 isab0@pci0:2:0: class=0x060100 card=0x chip=0x00081039 rev=0x00 hdr=0x00 atapci0@pci0:2:5: class=0x010180 card=0x55131039 chip=0x55131039 rev=0xd0 hdr=0x00 bktr0@pci0:11:0:class=0x04 card=0x13eb0070 chip=0x036e109e rev=0x11 hdr=0x00 none0@pci0:11:1:class=0x048000 card=0x13eb0070 chip=0x0878109e rev=0x11 hdr=0x00 ed0@pci0:13:0: class=0x02 card=0x802910ec chip=0x802910ec rev=0x00 hdr=0x00 pcm0@pci0:17:0: class=0x040100 card=0x80401102 chip=0x00021102 rev=0x05 hdr=0x00 emujoy0@pci0:17:1: class=0x098000 card=0x00201102 chip=0x70021102 rev=0x05 hdr=0x00 none1@pci1:0:0: class=0x03 card=0x88081462 chip=0x002d10de rev=0x15 hdr=0x00 - Chhristopher To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Feb 1 03:11:00 PST 2003 -- Kernel build for GENERIC completed on Sat Feb 1 03:43:16 PST 2003 -- Kernel build for LINT started on Sat Feb 1 03:43:16 PST 2003 -- === vinum Makefile, line 4447: warning: duplicate script for target geom_bsd.o ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and is not compiled with LINT /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is not compiled with LINT /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open': /h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once /h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.) cc1: warnings being treated as errors /h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close': /h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read': /h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write': /h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl': /h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap': /h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from incompatible pointer type *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
end of hold-off
I've reverted the patch in question. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pam_ssh broken in recent (as of yesterday) -current?
On Mon, 6 Jan 2003 11:17:23 +0100 Alexander Leidinger [EMAIL PROTECTED] wrote: On Fri, 03 Jan 2003 03:19:28 +0100 Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: Alexander Leidinger [EMAIL PROTECTED] writes: Dag-Erling, any ideas? http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/46628 Fixed a couple of minutes ago. Just tested with a world from yesterday: it doesn't segfault anymore, but there's no ssh-agent running. No messages in xdm-errors, .xsession-errors, XFree86.0.log or messages. Ping. Bye, Alexander. -- Press every key to continue. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request for info from SiS chipset owners
On Sat, Feb 01, 2003 at 12:02:05PM +0100, Soeren Schmidt wrote: Just reply to this message with the output from pciconf -l and you have helped me sort out the myriads of SiS chipsets out there. agp0@pci0:0:0: class=0x06 card=0x06481039 chip=0x06481039 rev=0x02 hdr=0x00 pcib1@pci0:1:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01 isab0@pci0:2:0: class=0x060100 card=0x chip=0x00081039 rev=0x04 hdr=0x00 atapci0@pci0:2:5: class=0x010180 card=0x55131039 chip=0x55131039 rev=0x00 hdr=0x00 none0@pci0:3:0: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x0f hdr=0x00 none1@pci0:3:1: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x0f hdr=0x00 none2@pci0:3:2: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x0f hdr=0x00 none3@pci0:3:3: class=0x0c0320 card=0x50041458 chip=0x70021039 rev=0x00 hdr=0x00 dc0@pci0:11:0: class=0x02 card=0x03151025 chip=0x00191011 rev=0x30 hdr=0x00 xl0@pci0:12:0: class=0x02 card=0x chip=0x905010b7 rev=0x00 hdr=0x00 pcm0@pci0:13:0: class=0x040100 card=0x13711274 chip=0x13711274 rev=0x06 hdr=0x00 nvidia0@pci1:0:0: class=0x03 card=0x chip=0x017110de rev=0xa3 hdr=0x00 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, Jan 31, 2003 at 11:48:17AM -0800, Peter Wemm wrote: The cache and most of the execution hardware is shared. The execution units can run something like 4 instructions per clock. If the idle logical core is in a spinloop, then it is generating instructions for execution, so you are dividing the execution resources between one context that is doing real work, and the other context that is burning off the excess resources. Overall, it is a huge loss. It is absolutely essential that logical cpus be halted when they are not doing useful work. What bothers me is that we have systems like UMA and mb_alloc (and possibly others) which have per-CPU structures, i.e., per-CPU caches, and when HTT is enabled, even the logical CPUs get their own cache when, in fact, it would probably be better (and less cache polluting) if the logical units (states) shared the same per-CPU structures. Briefly back to the cpu_idle_hlt story: Would it be possible to, at runtime - besides for just getting cpuid which gives us the logical unit number - get the actual physical CPU number that we're executing on? e.g., in a 2 x 4 Xeon with HTT enabled, cpuid will range from 0 to 3, would it be possible to have an equivalent variable that will give us only the physical unit number (in this case, it would range from 0 to 1, as there are two physical execution units). That way, we can count how many times we issue 'hlt' for a thread running on physical unit number N, for example, and if we have 2 logical units per physical unit for instance, then when the count hits 1 no longer do the 'hlt' to not lose a tick? The counter would have to be re-set at the next tick everytime a logical unit comes out of hlt and schedules a process. You know what I mean? It sounds a little complicated and I'm not sure it would be worth the effort, but it would get us the best of both scenarios, i.e., halt the logical unit when another logical unit on the same core is executing Real Code, and not halt the logical unit if both logical units on the given execution engine are idle. In any case, even if the above is not worth it, I'd still like to know if it's possible to get the physical unit number, as opposed to the logical unit number, at runtime? [...] Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, Jan 31, 2003 at 11:52:53AM -0800, Matthew Dillon wrote: Another solution would be to have a global mask of 'idle' cpus and send an IPI to them when a new KSE is scheduled on a non-idle cpu that would simply serve to wakeup the HLT. IPIs are nasty, but there are large (power consumption) advantages to standardizing on the HLT methodology. Or, as I explained in my previous post, only HLT the [virtual] CPU if the other [virtual] CPU that is sharing the same execution cache units is not HLT'd itself. If the other one is HLT'd, then not do the HLT. -Matt Matthew Dillon [EMAIL PROTECTED] -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request for info from SiS chipset owners
Hi, chip0@pci0:0:0: class=0x06 card=0x chip=0x55711039 rev=0x01 hdr=0x00 isab0@pci0:1:0: class=0x060100 card=0x chip=0x00081039 rev=0x01 hdr=0x00 atapci0@pci0:1:1: class=0x01018a card=0x0063000d chip=0x55131039 rev=0xc1 hdr=0x00 none0@pci0:11:0: class=0x03 card=0x chip=0x00e0102c rev=0xc6 hdr=0x00 atapci0: SiS 5591 ATA33 controller port 0x4000-0x400f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 irq 14 at device 1.1 on pci0 bye, Soeren Schmidt wrote: I'm currently in the midst of an ATA chipset support mega rewrite/update, and the last item on the list is SiS support. That where _you_ come into the picture, I need a pciconf -l from your SiS based system! Just reply to this message with the output from pciconf -l and you have helped me sort out the myriads of SiS chipsets out there. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- --- - Michael Bretterklieber- [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200-- privat --- A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com --- - ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request for info from SiS chipset owners
Soeren Schmidt wrote: Just reply to this message with the output from pciconf -l and you have helped me sort out the myriads of SiS chipsets out there. ~# pciconf -l chip0@pci0:0:0: class=0x06 card=0x chip=0x55911039 rev=0x02 hdr=0x00 atapci0@pci0:0:1: class=0x010180 card=0x55131039 chip=0x55131039 rev=0xd0 hdr=0x00 isab0@pci0:1:0: class=0x060100 card=0x chip=0x00081039 rev=0x01 hdr=0x00 none0@pci0:1:1: class=0xff card=0x chip=0x00091039 rev=0x00 hdr=0x00 pcib2@pci0:2:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01 rl0@pci0:11:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 none1@pci1:0:0: class=0x03 card=0x63261039 chip=0x63261039 rev=0x0b hdr=0x00 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request for info from SiS chipset owners
agp0@pci0:0:0: class=0x06 card=0x chip=0x07301039 rev=0x02 hdr=0x00 atapci0@pci0:0:1: class=0x010180 card=0x0a011019 chip=0x55131039 rev=0xd0 hdr=0x00 isab0@pci0:1:0: class=0x060100 card=0x chip=0x00081039 rev=0x00 hdr=0x00 ohci0@pci0:1:2: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x07 hdr=0x00 ohci1@pci0:1:3: class=0x0c0310 card=0x70001039 chip=0x70011039 rev=0x07 hdr=0x00 none0@pci0:1:4: class=0x040100 card=0x0a011019 chip=0x70181039 rev=0x02 hdr=0x00 pcib1@pci0:2:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01 rl0@pci0:13:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 drm0@pci1:0:0: class=0x03 card=0x013a1002 chip=0x51571002 rev=0x00 hdr=0x00 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ata0: resetting device - ASUS P4S8X
I bought new hardware for a server today, an ASUS P4S8X with an 1.8 GHZ P4 CPU, nothing fancy I would say, which has an onboard RAID controller (Promise) but I'm not using it for the moment. I attached an IBM 60GB Deskstar ATA/IDE disk to the IDE 1 port. FreeBSD 5.0R boots until the point where it says: ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting device and there it hangs forever. -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ata0: resetting device - ASUS P4S8X
In message [EMAIL PROTECTED], Christoph Kuk ulies writes: I bought new hardware for a server today, an ASUS P4S8X with an 1.8 GHZ P4 CPU, nothing fancy I would say, which has an onboard RAID controller (Promise) but I'm not using it for the moment. I attached an IBM 60GB Deskstar ATA/IDE disk to the IDE 1 port. FreeBSD 5.0R boots until the point where it says: ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting device and there it hangs forever. set hw.ata.ata_dma=0 in the bootloader. Sos@ is working the issue and will love to have a tester :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request for info from SiS chipset owners
Soeren Schmidt wrote: I'm currently in the midst of an ATA chipset support mega rewrite/update, and the last item on the list is SiS support. That where _you_ come into the picture, I need a pciconf -l from your SiS based system! Just reply to this message with the output from pciconf -l and you have helped me sort out the myriads of SiS chipsets out there. atapci0: SiS 5591 ATA33 controller port 0xd000-0xd00f,0xd400-0xd403,\ 0xd800-0xd807,0xe000-0xe003,0xe400-0xe407 irq 11 at device 1.1 on pci0 hostb0@pci0:0:0:\ class=0x06 card=0x chip=0x55971039 rev=0x02 hdr=0x00 isab0@pci0:1:0:\ class=0x060100 card=0x chip=0x00081039 rev=0x01 hdr=0x00 atapci0@pci0:1:1:\ class=0x01018a card=0x chip=0x55131039 rev=0xd0 hdr=0x00 ed0@pci0:11:0:\ class=0x02 card=0x chip=0x802910ec rev=0x00 hdr=0x00 none0@pci0:19:0:\ class=0x03 card=0x1039 chip=0x02001039 rev=0x65 hdr=0x00 ciao, -robert To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ata0: resetting device - ASUS P4S8X
It seems Christoph Kukulies wrote: I bought new hardware for a server today, an ASUS P4S8X with an 1.8 GHZ P4 CPU, nothing fancy I would say, which has an onboard RAID controller (Promise) but I'm not using it for the moment. I attached an IBM 60GB Deskstar ATA/IDE disk to the IDE 1 port. FreeBSD 5.0R boots until the point where it says: ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting device Thats because that board uses a new SiS chips which is not supported yet. I'm currently working on it, but since I have no SiS based HW here in the lab it takes time and is not the top most priority... Meanwhile turn off DMA in loader.conf and then mail me the output from pciconf -l from that system... Hint to sponsors: I need a SiS based motherboard !! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Question about devd concept
Hi, I'm currently experimenting with 5-CURRENT on my Notebook an have a question regarding the concept of devd. With 4-STABLE I had pccardd running. Whenever a pccard was inserted I had pccardd starting the corresponding scripts. I have configured devd to do so now (especially for my wavelan pccard). So far everything works, except for one case: When the pccard is already inserted during boot, devd does not recognize the card as newly inserted device (of course, it's already there). So I have currently setup a script in /usr/local/etc/rc.d which starts the script corresponding to the wavelan pccard, if interface wi0 is found during boot. I think this cannot be the considered solution for that problem? What am I missing about the concept of devd? Thanx, Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
still no comments? this patch seems to be working, but a review from another developer would be good.. particularly re: the point mentionned.. On Sat, 1 Feb 2003, Julian Elischer wrote: I'm working on backing out david's patch. Part of his megacommit was a patch that should ahve been separatly handled. I have split it out.. Can people have a look at it and see if it makes sense. http://www.freebsd.org/~julian/lock.diff basically locks need to be per thread but were per process. Can we just use a thread* for this? I think so but I wonder why it wasn't a proc* before.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
In message [EMAIL PROTECTED], Ju lian Elischer writes: still no comments? Julian, you sent this out a few hours ago, after people had spent a lot of time and getting quite frustrated trying to get you to DTRT with your mentee's inappropriate commit. If people are sick and tired of you right now, you can't blame them. Expecting any kind of response to this until people have gotten their trees working again is premature, and if you end up at the bottom of their TODO pile because of what came before this, there is nothing for you to do, except to wait patiently. Rushing an untested patch (Yes, I know you you havn't. I know how long time it takes, and you don't even have an SMP box to test it on.) at this point it time would be downright stupid. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request for info from SiS chipset owners
On Sat, Feb 01, 2003 at 12:02:05PM +0100, Soeren Schmidt wrote: I'm currently in the midst of an ATA chipset support mega rewrite/update, and the last item on the list is SiS support. That where _you_ come into the picture, I need a pciconf -l from your SiS based system! Just reply to this message with the output from pciconf -l and you have helped me sort out the myriads of SiS chipsets out there. -Søren chip0@pci0:0:0: class=0x06 card=0x chip=0x55961039 rev=0x00 hdr=0x00 isab0@pci0:1:0: class=0x060100 card=0x chip=0x00081039 rev=0x01 hdr=0x00 atapci0@pci0:1:1: class=0x01018a card=0x chip=0x55131039 rev=0x09 hdr=0x00 atapci1@pci0:11:0: class=0x018085 card=0x4d68105a chip=0x4d68105a rev=0x02 hdr=0x00 none0@pci0:13:0:class=0x03 card=0x63261569 chip=0x63261039 rev=0x0b hdr=0x00 ed0@pci0:15:0: class=0x02 card=0x802910ec chip=0x802910ec rev=0x00 hdr=0x00 none1@pci0:20:0:class=0x03 card=0x chip=0x02051039 rev=0x11 hdr=0x00 The chipset used on this motherboard is a SiS 5596/5513. (Even though dmesg likes to claim that the ATA controller is a SiS 5591, which it isn't. It is a SiS 5513.) -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
LockOrderReversal in current
From time-to-time I notice people reporting lock-order-reversal messages here. My system popped up with one sometime overnight, I have no idea what it might have been doing at the time. lock order reversal 1st 0xc0514fc0 arp mutex (arp mutex) @ /usr/src/sys/netinet/if_ether.c:151 2nd 0xc410707c radix node head (radix node head) @ /usr/src/sys/net/route.c:549 This is on a dual-CPU system. Current-branch as built on Jan 27th. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
Bosko Milekic wrote: On Fri, Jan 31, 2003 at 11:52:53AM -0800, Matthew Dillon wrote: Another solution would be to have a global mask of 'idle' cpus and send an IPI to them when a new KSE is scheduled on a non-idle cpu that would simply serve to wakeup the HLT. IPIs are nasty, but there are large (power consumption) advantages to standardizing on the HLT methodology. Or, as I explained in my previous post, only HLT the [virtual] CPU if the other [virtual] CPU that is sharing the same execution cache units is not HLT'd itself. If the other one is HLT'd, then not do the HLT. Actually, why is that? Why would you not want to HLT all the units that are not being used? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Sat, Feb 01, 2003 at 12:47:59PM -0800, Terry Lambert wrote: Bosko Milekic wrote: On Fri, Jan 31, 2003 at 11:52:53AM -0800, Matthew Dillon wrote: Another solution would be to have a global mask of 'idle' cpus and send an IPI to them when a new KSE is scheduled on a non-idle cpu that would simply serve to wakeup the HLT. IPIs are nasty, but there are large (power consumption) advantages to standardizing on the HLT methodology. Or, as I explained in my previous post, only HLT the [virtual] CPU if the other [virtual] CPU that is sharing the same execution cache units is not HLT'd itself. If the other one is HLT'd, then not do the HLT. Actually, why is that? Why would you not want to HLT all the units that are not being used? Because, the comment explains, a halted CPU will not pick up a new thread off the run queue until the next timer tick. So if all your logical units are idled then you can afford to just loop checking whether something is runnable without interfering with the performance of other threads running on a different logical cpu sharing your execution unit (because the other logical units are idle anyway). That way, you don't have to necessarily wait for the next timer tick to check whether something is runnable, especially if it's made runnable before. The disadvantage is that you don't really economize on power consumption. The ideal situation would be to have as Matt (and the comment actually) says a cpu mask of idle cpus and generate an IPI to wake up CPUs sitting in HLT when something hits the runqueue, then you can just hlt all of them and rely on the IPI to wake you up, or the next timer tick, whichever comes first and you can really get the best of both worlds. -- Terry -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
On Sat, 1 Feb 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: still no comments? Julian, you sent this out a few hours ago, after people had spent a lot of time and getting quite frustrated trying to get you to DTRT with your mentee's inappropriate commit. If people are sick and tired of you right now, you can't blame them. Expecting any kind of response to this until people have gotten their trees working again is premature, and if you end up at the bottom of their TODO pile because of what came before this, there is nothing for you to do, except to wait patiently. Rushing an untested patch (Yes, I know you you havn't. I know how long time it takes, and you don't even have an SMP box to test it on.) at this point it time would be downright stupid. Oh shut up Poul-Henning. I know I'm on your shit list, and have been for years but don't consider youself as spokesman for anyone but yourself. Go invade Ireland or something. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
Bosko Milekic wrote: Or, as I explained in my previous post, only HLT the [virtual] CPU if the other [virtual] CPU that is sharing the same execution cache units is not HLT'd itself. If the other one is HLT'd, then not do the HLT. Actually, why is that? Why would you not want to HLT all the units that are not being used? Because, the comment explains, a halted CPU will not pick up a new thread off the run queue until the next timer tick. So if all your logical units are idled then you can afford to just loop checking whether something is runnable without interfering with the performance of other threads running on a different logical cpu sharing your execution unit (because the other logical units are idle anyway). That way, you don't have to necessarily wait for the next timer tick to check whether something is runnable, especially if it's made runnable before. The disadvantage is that you don't really economize on power consumption. There's an assumption in there of a shared scheduler queue, and a lack of CPU affinity (or negaffinity, for multiple threads in a single process), isn't there? Or are you talking about processes that are ready-to-run as a result of an event that was handled by another CPU? It seems to me that a non-shared queue would need to signal wakeups with IPIs, which would wake up a HLT'ed processor, which would make it a non-problem (since there's no way to avoid per-CPU queue locking, if you don't have an IPI-based mechanism available). The ideal situation would be to have as Matt (and the comment actually) says a cpu mask of idle cpus and generate an IPI to wake up CPUs sitting in HLT when something hits the runqueue, then you can just hlt all of them and rely on the IPI to wake you up, or the next timer tick, whichever comes first and you can really get the best of both worlds. I think it's more complicated than that; you don't want to have anything other than the CPU that owns the per CPU run queue doing anything with it, which means that it's the wakeup event, not the arrival on the run queue, which needs to be signalled. Then the CPU in question has to do it's own processing of pending wakeup events in order to handle the placing of the process on the run queue itself, rather than it being handled by another CPU. This also implies per-CPU wait queues, and a reliable message delivery mechanism for wakeup messages. Though it may be enough to simple mark everything on the wait queue as wakeup pending, for a first rev., and run the wait queue, it's probably not a good idea for a production system, since it brings back the Giant Scheduler Lock for the wait queue (on the plus side, items awakened could be moved to the head of the queue when they were marked, with the lock held anyway, and that would shorten the list of traversed items per CPU to all pending wakeup processing, rather than all queue entries). But it's still too ugly for words. I think something like wakeup signalling, as a message abstraction, is required, in any case, considering support for clustering or NUMA, going forward, to deal with slower signal paths on a single system image for much more loosely coupled CPUs. Directly modifying queues in memory of other CPUs is unlikely to scale well, if it can even be made to work at all. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Sat, Feb 01, 2003 at 01:28:45PM -0800, Terry Lambert wrote: Bosko Milekic wrote: Or, as I explained in my previous post, only HLT the [virtual] CPU if the other [virtual] CPU that is sharing the same execution cache units is not HLT'd itself. If the other one is HLT'd, then not do the HLT. Actually, why is that? Why would you not want to HLT all the units that are not being used? Because, the comment explains, a halted CPU will not pick up a new thread off the run queue until the next timer tick. So if all your logical units are idled then you can afford to just loop checking whether something is runnable without interfering with the performance of other threads running on a different logical cpu sharing your execution unit (because the other logical units are idle anyway). That way, you don't have to necessarily wait for the next timer tick to check whether something is runnable, especially if it's made runnable before. The disadvantage is that you don't really economize on power consumption. There's an assumption in there of a shared scheduler queue, and a lack of CPU affinity (or negaffinity, for multiple threads in a single process), isn't there? Well, euh, yeah, the runqueue was global the last time I checked (Jeff R.'s new stuff aside). Maybe I'm just out of it, I don't know. [... other probably meaningful stuff that makes the assumption that we do have per-CPU queues protected by their own locks ...] -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
In message [EMAIL PROTECTED], Ju lian Elischer writes: Oh shut up Poul-Henning. Try to remain civil here Julian :-) I tried to explain the situation to you, to make sure you would not be tempted to do rush something which needs to take the time things take. I know I'm on your shit list, and have been for years but don't consider youself as spokesman for anyone but yourself. I consider myself spokesman for nobody but myself, and to that end I am very happy to not be on core anymore :-) Go invade Ireland or something. No way, it might disrupt their breweries or something. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
: The ideal situation would be to have as Matt (and the comment : actually) says a cpu mask of idle cpus and generate an IPI to wake up : CPUs sitting in HLT when something hits the runqueue, then you can : just hlt all of them and rely on the IPI to wake you up, or the next : timer tick, whichever comes first and you can really get the best of : both worlds. : :I think it's more complicated than that; you don't want to have :anything other than the CPU that owns the per CPU run queue doing :anything with it, which means that it's the wakeup event, not the :arrival on the run queue, which needs to be signalled. Then the :CPU in question has to do it's own processing of pending wakeup :events in order to handle the placing of the process on the run :queue itself, rather than it being handled by another CPU. : :This also implies per-CPU wait queues, and a reliable message :delivery mechanism for wakeup messages. : :Though it may be enough to simple mark everything on the wait :queue as wakeup pending, for a first rev., and run the wait :queue, it's probably not a good idea for a production system, :since it brings back the Giant Scheduler Lock for the wait queue :(on the plus side, items awakened could be moved to the head of :the queue when they were marked, with the lock held anyway, and :that would shorten the list of traversed items per CPU to all :pending wakeup processing, rather than all queue entries). :But it's still too ugly for words. The HLT/clock interrupt issue is precisely what I describe in the idle_hlt comments in i386/i386/machdep.c (last July). I wish we had a better mechanism then the stupid IPI stuff, like a simple per-cpu latch/acknowledge level interrupt (softint), but we don't. I don't think we want to over-engineer per-cpu scheduling. The system really doesn't know what cpu a task is going to wind up running on until a cpu scheduler (sched_choose()) comes along and needs to locate the next task to run. Too many things can happen in between the initiation of the wait, the wakeup, and the task actually getting cpu. Introducing a complex per-cpu wait queue or trying to do something complex at wakeup time instead of at sched_choose() time is just going to be a waste of time. I think it is best to wakeup a task by placing it on the same cpu run queue as it was previously on (which is what Jeffs code does for the most part), and deal with task stealing in sched_choose(). The scheduler, when it comes time to actually switch in the next runnable task, then deals with complexities associated with misbalancing (i.e. cpu A is idle and ready to accept a new task, and cpu B's run-queue has a task ready to be run). While it is true that we would like a cpu to predominantly use the per-cpu run-queue that it owns, we don't really lose anything in the way of performance by allowing cpu A to add a task to cpu B's run queue or for cpu A to steal a task from cpu B's run queue. Sure we have the overhead of a per-cpu mutex, but the reason we don't lose anything is that this sort of mechanism will *STILL* scale linearly with the number of cpus in the system (whereas the global run queue in sched_4bsd.c constricts at a single sched_mtx and does not scale). The overhead of a per-cpu run-queue with a per-cpu mutex is *STILL* effectively O(1) and the more complex overheads involved with locating a new task to schedule from some other cpu's run queue when the current cpu's run-queue is empty are irrelevant because you are only eating into cycles which would otherwise be idle anyway. -Matt Matthew Dillon [EMAIL PROTECTED] :I think something like wakeup signalling, as a message abstraction, :is required, in any case, considering support for clustering or NUMA, :going forward, to deal with slower signal paths on a single system :image for much more loosely coupled CPUs. Directly modifying queues :in memory of other CPUs is unlikely to scale well, if it can even be :made to work at all. : :-- Terry : To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: appending files on smbfs
Dear/Beste Patrick, Thursday, January 30, 2003, 8:37:04 PM, you wrote: has anyone every had problems with appending existing files on volumes mounted by smbfs or shlight? $ echo sdsad hey $ echo sdsad hey cannot create hey: Permission denied You should look at permission on the windows machine if the system has NTFS. -- Best regards/Met vriendelijke groet, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Style fixups for proc.h
Hi OK to commit the style fixups below? (They just make sure that all function prototypes have all arguments named, and that all names are protected). int foo(int bar); becomes int foo(int _bar); M Index: proc.h === RCS file: /home/ncvs/src/sys/sys/proc.h,v retrieving revision 1.291 diff -u -d -r1.291 proc.h @@ -860,101 +860,101 @@ extern int lastpid; -struct proc *pfind(pid_t); /* Find process by id. */ -struct pgrp *pgfind(pid_t);/* Find process group by id. */ -struct proc *zpfind(pid_t);/* Find zombie process by id. */ +struct proc *pfind(pid_t _pid);/* Find process by id. */ +struct pgrp *pgfind(pid_t _pid); /* Find process group by id. */ +struct proc *zpfind(pid_t _pid); /* Find zombie process by id. */ -void adjustrunqueue(struct thread *, int newpri); -void ast(struct trapframe *framep); +void adjustrunqueue(struct thread *_td, int _newpri); +void ast(struct trapframe *_framep); struct thread *choosethread(void); -intcr_cansignal(struct ucred *cred, struct proc *proc, int signum); -intenterpgrp(struct proc *p, pid_t pgid, struct pgrp *pgrp, struct session *sess); -intenterthispgrp(struct proc *p, struct pgrp *pgrp); -void faultin(struct proc *p); -void fixjobc(struct proc *p, struct pgrp *pgrp, int entering); -intfork1(struct thread *, int, int, struct proc **); -void fork_exit(void (*)(void *, struct trapframe *), void *, - struct trapframe *); -void fork_return(struct thread *, struct trapframe *); -intinferior(struct proc *p); -intleavepgrp(struct proc *p); +intcr_cansignal(struct ucred *_cred, struct proc *_p, int _signum); +intenterpgrp(struct proc *_p, pid_t _pgid, struct pgrp *pgrp, struct session +*_sess); +intenterthispgrp(struct proc *_p, struct pgrp *_pgrp); +void faultin(struct proc *_p); +void fixjobc(struct proc *_p, struct pgrp *_pgrp, int _entering); +intfork1(struct thread *_td, int, int, struct proc **_p); +void fork_exit(void (*_func)(void *_ptr, struct trapframe *_tf), void *_ptr, + struct trapframe *_tf); +void fork_return(struct thread *_td, struct trapframe *_tf); +intinferior(struct proc *_p); +intleavepgrp(struct proc *_p); void mi_switch(void); -intp_candebug(struct thread *td, struct proc *p); -intp_cansee(struct thread *td, struct proc *p); -intp_cansched(struct thread *td, struct proc *p); -intp_cansignal(struct thread *td, struct proc *p, int signum); -struct pargs *pargs_alloc(int len); -void pargs_drop(struct pargs *pa); -void pargs_free(struct pargs *pa); -void pargs_hold(struct pargs *pa); +intp_candebug(struct thread *_td, struct proc *_p); +intp_cansee(struct thread *_td, struct proc *_p); +intp_cansched(struct thread *_td, struct proc *_p); +intp_cansignal(struct thread *_td, struct proc *_p, int _signum); +struct pargs *pargs_alloc(int _len); +void pargs_drop(struct pargs *_pa); +void pargs_free(struct pargs *_pa); +void pargs_hold(struct pargs *_pa); void procinit(void); void threadinit(void); -void proc_linkup(struct proc *p, struct ksegrp *kg, - struct kse *ke, struct thread *td); -void proc_reparent(struct proc *child, struct proc *newparent); -intsecurelevel_ge(struct ucred *cr, int level); +void proc_linkup(struct proc *_p, struct ksegrp *_kg, + struct kse *_ke, struct thread *_td); +void proc_reparent(struct proc *_child, struct proc *_newparent); +intsecurelevel_ge(struct ucred *_cr, int _level); intsecurelevel_gt(struct ucred *cr, int level); -void setrunnable(struct thread *); -void setrunqueue(struct thread *); -void setsugid(struct proc *p); +void setrunnable(struct thread *_td); +void setrunqueue(struct thread *_td); +void setsugid(struct proc *_p); void sleepinit(void); -void stopevent(struct proc *, u_int, u_int); +void stopevent(struct proc *_p, u_int _arg1, u_int _arg2); void cpu_idle(void); void cpu_switch(void); void cpu_throw(void) __dead2; -void unsleep(struct thread *); -void userret(struct thread *, struct trapframe *, u_int); +void unsleep(struct thread *_td); +void userret(struct thread *_td, struct trapframe *_tf, u_int _arg); -void cpu_exit(struct thread *); -void cpu_sched_exit(struct thread *); -void exit1(struct thread *, int) __dead2; -void cpu_fork(struct thread *, struct proc *, struct thread *, int); -void cpu_set_fork_handler(struct thread *, void (*)(void *), void *); -void cpu_wait(struct proc *); +void cpu_exit(struct thread *_td); +void cpu_sched_exit(struct thread *_td); +void exit1(struct thread *_td, int _ret) __dead2; +void cpu_fork(struct thread *_td1, struct proc *_p, struct thread *_td2, int _ret); +void cpu_set_fork_handler(struct thread *_td, void (*_pfunc)(void *_arg), void +*_ptr); +void cpu_wait(struct proc *_p); /* New in KSE. */ struct ksegrp
Re: Request for info from SiS chipset owners
atapci0: SiS 5591 ATA100 controller port 0xd800-0xd80f at device 0.1 on pci0 agp0@pci0:0:0: class=0x06 card=0x chip=0x07301039 rev=0x02 hdr=0x00 atapci0@pci0:0:1: class=0x010180 card=0x80321043 chip=0x55131039 rev=0xd0 hdr=0x00 isab0@pci0:1:0: class=0x060100 card=0x chip=0x00081039 rev=0x00 hdr=0x00 ohci0@pci0:1:2: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x07 hdr=0x00 ohci1@pci0:1:3: class=0x0c0310 card=0x70001039 chip=0x70011039 rev=0x07 hdr=0x00 pcm0@pci0:1:4: class=0x040100 card=0x80321043 chip=0x70181039 rev=0x02 hdr=0x00 pcib1@pci0:2:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01 rl0@pci0:9:0: class=0x02 card=0x80261043 chip=0x813910ec rev=0x10 hdr=0x00 xl0@pci0:13:0: class=0x02 card=0x100010b7 chip=0x920010b7 rev=0x78 hdr=0x00 wi0@pci0:16:0: class=0x028000 card=0x41051385 chip=0x38731260 rev=0x01 hdr=0x00 none0@pci1:0:0: class=0x03 card=0x80321043 chip=0x63001039 rev=0x31 hdr=0x00 Scott - Original Message - From: Soeren Schmidt [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, February 01, 2003 6:02 AM Subject: Request for info from SiS chipset owners I'm currently in the midst of an ATA chipset support mega rewrite/update, and the last item on the list is SiS support. That where _you_ come into the picture, I need a pciconf -l from your SiS based system! Just reply to this message with the output from pciconf -l and you have helped me sort out the myriads of SiS chipsets out there. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. It's certainly not part of style(9) that I've ever noticed and it's generally noy done that way.. is there a move to do this on all the other files? On Sat, 1 Feb 2003, Mark Murray wrote: Hi OK to commit the style fixups below? (They just make sure that all function prototypes have all arguments named, and that all names are protected). int foo(int bar); becomes int foo(int _bar); M Index: proc.h === RCS file: /home/ncvs/src/sys/sys/proc.h,v retrieving revision 1.291 diff -u -d -r1.291 proc.h @@ -860,101 +860,101 @@ extern int lastpid; -struct proc *pfind(pid_t); /* Find process by id. */ -struct pgrp *pgfind(pid_t);/* Find process group by id. */ -struct proc *zpfind(pid_t);/* Find zombie process by id. */ +struct proc *pfind(pid_t _pid);/* Find process by id. */ +struct pgrp *pgfind(pid_t _pid); /* Find process group by id. */ +struct proc *zpfind(pid_t _pid); /* Find zombie process by id. */ -void adjustrunqueue(struct thread *, int newpri); -void ast(struct trapframe *framep); +void adjustrunqueue(struct thread *_td, int _newpri); +void ast(struct trapframe *_framep); struct thread *choosethread(void); -int cr_cansignal(struct ucred *cred, struct proc *proc, int signum); -int enterpgrp(struct proc *p, pid_t pgid, struct pgrp *pgrp, struct session *sess); -int enterthispgrp(struct proc *p, struct pgrp *pgrp); -void faultin(struct proc *p); -void fixjobc(struct proc *p, struct pgrp *pgrp, int entering); -int fork1(struct thread *, int, int, struct proc **); -void fork_exit(void (*)(void *, struct trapframe *), void *, - struct trapframe *); -void fork_return(struct thread *, struct trapframe *); -int inferior(struct proc *p); -int leavepgrp(struct proc *p); +int cr_cansignal(struct ucred *_cred, struct proc *_p, int _signum); +int enterpgrp(struct proc *_p, pid_t _pgid, struct pgrp *pgrp, struct session *_sess); +int enterthispgrp(struct proc *_p, struct pgrp *_pgrp); +void faultin(struct proc *_p); +void fixjobc(struct proc *_p, struct pgrp *_pgrp, int _entering); +int fork1(struct thread *_td, int, int, struct proc **_p); +void fork_exit(void (*_func)(void *_ptr, struct trapframe *_tf), void *_ptr, + struct trapframe *_tf); +void fork_return(struct thread *_td, struct trapframe *_tf); +int inferior(struct proc *_p); +int leavepgrp(struct proc *_p); void mi_switch(void); -int p_candebug(struct thread *td, struct proc *p); -int p_cansee(struct thread *td, struct proc *p); -int p_cansched(struct thread *td, struct proc *p); -int p_cansignal(struct thread *td, struct proc *p, int signum); -struct pargs *pargs_alloc(int len); -void pargs_drop(struct pargs *pa); -void pargs_free(struct pargs *pa); -void pargs_hold(struct pargs *pa); +int p_candebug(struct thread *_td, struct proc *_p); +int p_cansee(struct thread *_td, struct proc *_p); +int p_cansched(struct thread *_td, struct proc *_p); +int p_cansignal(struct thread *_td, struct proc *_p, int _signum); +struct pargs *pargs_alloc(int _len); +void pargs_drop(struct pargs *_pa); +void pargs_free(struct pargs *_pa); +void pargs_hold(struct pargs *_pa); void procinit(void); void threadinit(void); -void proc_linkup(struct proc *p, struct ksegrp *kg, - struct kse *ke, struct thread *td); -void proc_reparent(struct proc *child, struct proc *newparent); -int securelevel_ge(struct ucred *cr, int level); +void proc_linkup(struct proc *_p, struct ksegrp *_kg, + struct kse *_ke, struct thread *_td); +void proc_reparent(struct proc *_child, struct proc *_newparent); +int securelevel_ge(struct ucred *_cr, int _level); int securelevel_gt(struct ucred *cr, int level); -void setrunnable(struct thread *); -void setrunqueue(struct thread *); -void setsugid(struct proc *p); +void setrunnable(struct thread *_td); +void setrunqueue(struct thread *_td); +void setsugid(struct proc *_p); void sleepinit(void); -void stopevent(struct proc *, u_int, u_int); +void stopevent(struct proc *_p, u_int _arg1, u_int _arg2); void cpu_idle(void); void cpu_switch(void); void cpu_throw(void) __dead2; -void unsleep(struct thread *); -void userret(struct thread *, struct trapframe *, u_int); +void unsleep(struct thread *_td); +void userret(struct thread *_td, struct trapframe *_tf, u_int _arg); -void cpu_exit(struct thread *); -void cpu_sched_exit(struct thread *); -void exit1(struct thread *, int) __dead2; -void cpu_fork(struct thread *, struct proc *, struct thread *, int); -void cpu_set_fork_handler(struct thread *, void (*)(void *), void *); -void cpu_wait(struct proc *); +void cpu_exit(struct thread *_td); +void
Re: Request for info from SiS chipset owners
Folks, Please send this info to SOREN, not to the list. Thanks, Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
trouble with ogle performance after going to 5.0-R
I recently installed 5.0-R (and KDE 3.1, thus the cc:). Ogle now has terrible performance - very jerky. Last weekend, when this computer (an Athlon XP 1800+) had 4-stable and KDE 3.0.5, ogle perfomance on the same DVD was perfectly smooth. Since ogle didn't change, I assume it's something to do with FreeBSD. Any idea what could be causing it? At first I thought it was that I hadn't put CPU_ENABLE_SSE in my kernel, like I had in 4-stable, but after putting it in, the performance is still just as bad. While playing a DVD the load goes from about 0.02 to about 1.5. Unfortunately I don't know what it did under 4-stable, but if anyone else can compare... -David -- Whatever it is that the government does, sensible Americans would prefer that the government does it to somebody else. This is the idea behind foreign policy. -P. J. O'Rourke Astronomy and Astrophysics Center The University of Chicago To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
Julian Elischer writes: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. When the prototype parameter name matches a local variable, the C compiler (and lint) whine about clashes between names in local/global namespace. 2 ways to fix this are to protect the prototype argument names with the _, or to remove the argument name altogether. proc.h has no clear guidance, in that recent commits don't stick to the established style of the file. Some newish prototypes have a mixture of named/unnamed args in the same function. While I was making all prototypes' args named, I protected them. I'd like to fix the warnings, and I'd like the file to be consistent WRT argument naming. It's certainly not part of style(9) that I've ever noticed and it's generally noy done that way.. is there a move to do this on all the other files? There is a move to fix lint(1) warnings. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
On Sat, 1 Feb 2003, Mark Murray wrote: Julian Elischer writes: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. When the prototype parameter name matches a local variable, the C compiler (and lint) whine about clashes between names in local/global namespace. 2 ways to fix this are to protect the prototype argument names with the _, or to remove the argument name altogether. I'd rather have the names removed altogether. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Question about devd concept
Date: Sat, 1 Feb 2003 19:20:12 +0100 From: Oliver Brandmueller [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi, I'm currently experimenting with 5-CURRENT on my Notebook an have a question regarding the concept of devd. With 4-STABLE I had pccardd running. Whenever a pccard was inserted I had pccardd starting the corresponding scripts. I have configured devd to do so now (especially for my wavelan pccard). So far everything works, except for one case: When the pccard is already inserted during boot, devd does not recognize the card as newly inserted device (of course, it's already there). So I have currently setup a script in /usr/local/etc/rc.d which starts the script corresponding to the wavelan pccard, if interface wi0 is found during boot. I think this cannot be the considered solution for that problem? What am I missing about the concept of devd? While I think you have the concept down fine, the execution may still be a bit fuzzy in places. If the device is in place when the system boots, devd should not be required, as it should be probed in the traditional manner. But this does not seem to execute the added things that need to be done to bring up a new network interface. After the system is up I need to execute /etc/pccard_ether to get the interface on-line. I have two Xircom cards, an old RE-100 16-bit card and a newer RBEM-56 CardBus Ethernet/modem card. The former uses if_xe and the latter uses if_dc. The behavior is very inconsistent. If I have if_xe loaded at boot, the RE-100 comes up fine. It has the annoying watchdog timeout and then comes up fine. If I insert the card into the running system, it also works, but prints out a failure to load the driver since the driver is already present. But it I don't have the drive in the kernel when I insert the card, it fails to initialize. The CardBus unit seems to only work when the driver is loaded at boot time and then the Ethernet part simply works. Unfortunately, the modem does not as the devices are not created in /dev by devfs. (I suspect I can get this working once I get devfs figured out a bit better.) But, I still need to execute /etc/paccard_ether before the Ethernet is usable. If I insert the card into a running system, I just get continuous watchdog timeouts and can't do much until I eject the card. I hope to have some time Monday to sit down and try as many combinations of card insertions/ejections and driver loading as possible to see if I can see a clear pattern to the operation of these cards. Maybe that will provide a pointer as to where things are breaking down in both of our cases. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
:Julian Elischer writes: : I don't know about the protection with a '_'. : : It's not standard and usually the name matches that used in the actual : function. : :When the prototype parameter name matches a local variable, the C compiler :(and lint) whine about clashes between names in local/global namespace. I've never in my life heard of this behavior before, what compiler arguments reproduce it? :2 ways to fix this are to protect the prototype argument names with the :_, or to remove the argument name altogether. If it is a problem, why not simply use the same variable names that are declared in the procedure proper? The underscore looks ugly and out of place and doesn't make that much sense to me. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: trouble with ogle performance after going to 5.0-R
David Syphers wrote: I recently installed 5.0-R (and KDE 3.1, thus the cc:). Ogle now has terrible performance - very jerky. Last weekend, when this computer (an Athlon XP 1800+) had 4-stable and KDE 3.0.5, ogle perfomance on the same DVD was perfectly smooth. Since ogle didn't change, I assume it's something to do with FreeBSD. Any idea what could be causing it? At first I thought it was that I hadn't put CPU_ENABLE_SSE in my kernel, like I had in 4-stable, but after putting it in, the performance is still just as bad. While playing a DVD the load goes from about 0.02 to about 1.5. Unfortunately I don't know what it did under 4-stable, but if anyone else can compare... -David First, 5.0 does suffer a significant slowdown in many areas compared to 4.x. Ogle plays fine on my P4-1.6Ghz laptop, though. Have you made sure that the DVD drive is using DMA? 'sysctl hw.ata.atapi_dma' will tell you, and can be set at boot from /boot/loader.conf. Also, I beleive that if you enable the SSE instructions that the mpeg2 and audio libraries that ogle uses will have to be recompiled to make sure that they generate the SSE instructions. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: trouble with ogle performance after going to 5.0-R
Hi, hw.ata.atapi_dma=1 ? Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
:When the prototype parameter name matches a local variable, the C compiler :(and lint) whine about clashes between names in local/global namespace. I've never in my life heard of this behavior before, what compiler arguments reproduce it? WARNS=5. :2 ways to fix this are to protect the prototype argument names with the :_, or to remove the argument name altogether. If it is a problem, why not simply use the same variable names that are declared in the procedure proper? The underscore looks ugly and out of place and doesn't make that much sense to me. Because this doesn't always help, or if it did, the diffs are often much bigger and to many more files. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
On Sat, Feb 01, 2003 at 03:04:32PM -0800, Julian Elischer wrote: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. It's certainly not part of style(9) that I've ever noticed and it's generally noy done that way.. is there a move to do this on all the other files? man 9 style In header files visible to userland applications, prototypes that are visible must use either ``protected'' names (ones beginning with an underscore) or no names with the types. It is preferable to use pro- tected names. E.g., use: voidfunction(int); or: voidfunction(int _fd); -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
Julian Elischer writes: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. When the prototype parameter name matches a local variable, the C compiler (and lint) whine about clashes between names in local/global namespace. According to C99, a function prototype has its own scope or name space. It terminates at the end of the function declarator. Basically naming a parameter in a function prototype is an aide to the human user; it is not needed for correct compilation[1] so this warning is bogus. As the spec says in section 6.7.5.3 (according the draft I have) The identifiers [naming parameters] are declared for descriptive purposes only and go out of scope at the end of the [prototype] declaration. I can't see what actual error is avoided by this warning. 2 ways to fix this are to protect the prototype argument names with the _, or to remove the argument name altogether. Why not fix the compiler lint instead of cluttering up declarations? -- bakul [1] Except for what is needed for declaring flexible or variable length array parameters. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
* De: Bakul Shah [EMAIL PROTECTED] [ Data: 2003-02-01 ] [ Subjecte: Re: Style fixups for proc.h ] Julian Elischer writes: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. When the prototype parameter name matches a local variable, the C compiler (and lint) whine about clashes between names in local/global namespace. According to C99, a function prototype has its own scope or name space. It terminates at the end of the function declarator. Basically naming a parameter in a function prototype is an aide to the human user; it is not needed for correct compilation[1] so this warning is bogus. As the spec says in section 6.7.5.3 (according the draft I have) The identifiers [naming parameters] are declared for descriptive purposes only and go out of scope at the end of the [prototype] declaration. I can't see what actual error is avoided by this warning. If a named prototype clashes with something in global scope, isn't it still a shadowing issue? They should probably never be *in* scope. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
:WARNS=5. This isn't helpful. I tried adding every -W switch in bsd.sys.mk and couldn't reproduce the problem. What compiler option is causing the problem? : :2 ways to fix this are to protect the prototype argument names with the : :_, or to remove the argument name altogether. : : If it is a problem, why not simply use the same variable names that are : declared in the procedure proper? The underscore looks ugly and out of : place and doesn't make that much sense to me. : :Because this doesn't always help, or if it did, the diffs are often :much bigger and to many more files. : :M :-- :Mark Murray :iumop ap!sdn w,I idlaH Ok, now I'm really confused. How can it not always help? If the arguments are the same as the arguments declared in the underlying procedures why would an error still be produced? The diff you produced for proc.h is *already* fairly extensive. If you want to fix this, you only need to fix the lines generating compiler warnings. I really dislike screwing around with source code to work around bugs in the the compiler, or lint. Given the choice of underlines or leaving the arguments unnamed, I would leave them unnamed. Or I would figure out and remove whatever broken compiler option is generating the warning in the first place. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
Why not fix the compiler lint instead of cluttering up declarations? Can we at least get proc.h to have a consistent style of function parameter usage? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
:If a named prototype clashes with something in global scope,
:isn't it still a shadowing issue? They should probably never
:be *in* scope.
:--
:Juli Mallett [EMAIL PROTECTED]
:AIM: BSDFlata -- IRC: juli on EFnet
I finally was able to reproduce the bug. But it's an obvious bug in the
compiler at least in regards to named arguments in prototypes.
The -Wshadow switch causes the error message to be produced and it
occurs both for named arguments in prototypes and, named arguments
in the procedure proper, and named locals in the procedure.
The solution is simply to name the arguments in the prototype the same
as the arguments in the procedure. If we are going to use -Wshadow then
the arguments in the procedure will generate the error too so naming
the prototype arguments the same will not make things any better OR worse.
So the prototype arguments should either be named the same as those in the
procedure proper, or should not be named at all.
We definitely should not go adding underscores to the prototypes to
work around this problem.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
int x;
int fubar(int x);
int
fubar(int y)
{
int x = 2;
++x;
y = 1;
return(1);
}
int
fubar2(int x)
{
++x;
return(1);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Feb 1 15:17:17 PST 2003 -- Kernel build for GENERIC completed on Sat Feb 1 15:50:42 PST 2003 -- Kernel build for LINT started on Sat Feb 1 15:50:43 PST 2003 -- === vinum Makefile, line 4447: warning: duplicate script for target geom_bsd.o ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and is not compiled with LINT /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is not compiled with LINT /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open': /h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once /h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.) cc1: warnings being treated as errors /h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close': /h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read': /h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write': /h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl': /h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap': /h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from incompatible pointer type *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
subscribe
To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
subscribe
To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
On Sat, 01 Feb 2003 16:02:57 -0800, Bakul Shah [EMAIL PROTECTED] said:
I can't see what actual error is avoided by this warning.
It's a potential error -- if there were an actual error, it would be
an error and not a warning.
The issue is simple:
Say you have an object and a function declared in global scope:
int foo;
/* many lines of declarations */
/* perhaps this is even in a different file */
void bar(quux_t foo);
At some point, somebody changes the spelling of `foo' and adds a
preprocessor macro for compatibility:
union baz {
int foo;
struct frotz *gorp;
} foobaz;
#define foo foobaz.foo
What happens to the declaration of that function? Well,
void bar(quux_t foobaz.foo);
is a syntax error.
My personal opinion, which is different from what style(9) recommends,
is that parameter names should be omitted for all functions, EXCEPT
those with ambiguous parameter types. Most functions in the kernel
only operate on one object of a given type at a time, so even without
the names it is (or should be) obvious what the object is used for.
Some functions, however, take multiple objects of the same type (e.g.,
two different sorts of flags); in these cases some additional help may
be warranted.
In the case of user headers, if parameter names are included, they
MUST be protected, because they would otherwise be polluting the
user's namespace. Hence, most headers historically do not use
parameter names.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
On Sat, 1 Feb 2003 19:31:47 -0500 (EST), I wrote:
union baz {
int foo;
struct frotz *gorp;
} foobaz;
#define foo foobaz.foo
Oops... What I meant to say:
union baz {
int bazu_foo;
struct frotz *bazu_gorp;
} foobaz;
#define foo foobaz.bazu_foo
With this emendation, my post will actually make sense.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
Matthew Dillon writes: :WARNS=5. This isn't helpful. I tried adding every -W switch in bsd.sys.mk and couldn't reproduce the problem. What compiler option is causing the problem? I don't know which specific one. Ok, now I'm really confused. How can it not always help? If the arguments are the same as the arguments declared in the underlying procedures why would an error still be produced? The diff you produced for proc.h is *already* fairly extensive. If you want to fix this, you only need to fix the lines generating compiler warnings. arg in a function prototype gets confused with variable arg in some function(s). I really dislike screwing around with source code to work around bugs in the the compiler, or lint. Given the choice of underlines or leaving the arguments unnamed, I would leave them unnamed. Or I would figure out and remove whatever broken compiler option is generating the warning in the first place. Then can we just get the proc.h prototypes into a (any) consistent style? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
:I really dislike screwing around with source code to work around :bugs in the the compiler, or lint. Given the choice of underlines :or leaving the arguments unnamed, I would leave them unnamed. Or I :would figure out and remove whatever broken compiler option is generating :the warning in the first place. : :Then can we just get the proc.h prototypes into a (any) consistent :style? : :M :-- :Mark Murray Lets ask ourselves what the goal of the named prototypes is... the compiler doesn't need them, obviously, so one would presume that the goal is human readability. So if we care about human readability we should simply name them after the argument names used in the procedures proper. If we don't care about human readability we should omit the names entirely. An underscore would be detrimental to human readability. It makes the prototypes look rather nasty when I look at the fully patched proc.h, and also makes them different from the arguments as declared in the procedures proper. A quick perusal of include files shows that we use a mix. Examples: sys/acl.h -- looks like the authors tried to use the underscore technique but forgot a couple. sys/aio.h -- a mix of named (without underscore) and unnamed. sys/blist.h -- named prototypes without underscore (mine originally) sys/buf.h -- a mix of named (without underscore) and unnamed. Mostly unnamed, and __P() is still being used. (the named one is probably mine). sys/callout.h -- unnamed. sys/conf.h -- mostly named (without underscore) (not mine) sys/cons.h -- unnamed And it goes on. Quite a mess we have, actually. We still have __P in many places. The newest header file would arguably be acl.h in which the author used underscores. I can't say I like the way it reads on the screen. Older header files either still have __P, don't have __P and the arguments are named (typically without an underscore), or mix with some of the arguments named and some not (some wholely not). -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
I can't see what actual error is avoided by this warning.
s/actual/potential/
If a named prototype clashes with something in global scope,
isn't it still a shadowing issue? They should probably never
be *in* scope.
Nothing is being shadowed. Paramater names in a function
prototype (as opposed to a function definition) are simply
not relevant to the compiler (their distinctness, type and
positions are but not the actual names). No potential bug is
being hidden by saying, for example,
int x;
int foo(int x);
It is perfectly fine to later define foo as
int foo(int y)
{
return x + y;
}
The compiler should simply discard any parameter names in a
prototype once the prototype is digested and C programmers
need to know that. Now if parameter y shadows a global y one
may want to be warned about it.
Garrett gives an example:
Say you have an object and a function declared in global scope:
int foo;
/* many lines of declarations */
/* perhaps this is even in a different file */
void bar(quux_t foo);
At some point, somebody changes the spelling of `foo' and adds a
preprocessor macro for compatibility:
union baz {
int foo;
struct frotz *gorp;
} foobaz;
#define foo foobaz.foo
What happens to the declaration of that function? Well,
void bar(quux_t foobaz.foo);
is a syntax error.
This sort of problem can occur when you have any two objects named the
same. Consider:
struct dumb { int foo; };
After the above redefinition this defn won't compile (even
after his amendation:-).
Not naming parameters is one solution but with some loss of
perspicuity. Consider:
int* make_matrix(int, int);
versus
int* make_matrix(int rows, int columns);
-- bakul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: trouble with ogle performance after going to 5.0-R
On Saturday 01 February 2003 05:43 pm, Scott Long wrote: Have you made sure that the DVD drive is using DMA? 'sysctl hw.ata.atapi_dma' will tell you, and can be set at boot from /boot/loader.conf. This was the main problem. Turning on DMA makes everything run smoothly and drops the load averages significantly. I must have made this change to my 4.x system once about a year ago, and completely forgotten about it since. I should write an addition to the handbook about this... Thanks! -David -- Whatever it is that the government does, sensible Americans would prefer that the government does it to somebody else. This is the idea behind foreign policy. -P. J. O'Rourke Astronomy and Astrophysics Center The University of Chicago To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
At 10:47 AM -0800 2003/02/01, Julian Elischer wrote: still no comments? this patch seems to be working, but a review from another developer would be good.. particularly re: the point mentionned.. You first announced the split-out patch at Sat, 1 Feb 2003 02:59:24 -0800 (PST). The date/time stamp on the message that I am replying to is Sat, 1 Feb 2003 10:47:44 -0800 (PST). That's something around seven hours and forty-five minutes, unless I have miscalculated. Is it really normal to expect replies within that kind of a time frame, especially since we're talking about 3:00 AM to 10:45 AM, and most people are likely to be asleep? Granted, not everyone is in PST, but it's still a relatively quiet period of time for most people outside of Asia, and we don't seem to have a whole lot of people from those time zones on this list. I'm not questioning the patch at all, just the apparent impatience. If I am wrong and it is normal to expect a reasonable response within this period of time and within this particular period of time on a Saturday morning, please let me know. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
:02:59:24 -0800 (PST). The date/time stamp on the message that I am :replying to is Sat, 1 Feb 2003 10:47:44 -0800 (PST). That's :something around seven hours and forty-five minutes, unless I have :miscalculated. : : Is it really normal to expect replies within that kind of a time :frame, especially since we're talking about 3:00 AM to 10:45 AM, and :most people are likely to be asleep? Granted, not everyone is in :PST, but it's still a relatively quiet period of time for most people :... : I'm not questioning the patch at all, just the apparent impatience. :-- :Brad Knowles, [EMAIL PROTECTED] Well, it is an active conversation/thread. Either people care enough to stay involved or they don't. Considering how much time has been wasted so far bickering back and forth over a commit that was *almost* corrected before the inevitable calls for a backout, and the fairly hostile history between some of the participants, I can understand Julian's impatience. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
On Sun, 2 Feb 2003, Mark Murray wrote: Why not fix the compiler lint instead of cluttering up declarations? Can we at least get proc.h to have a consistent style of function parameter usage? Sure. let's be consistent with all the other .h files in the kernel. what does a quick census show? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
Matthew Dillon wrote: The HLT/clock interrupt issue is precisely what I describe in the idle_hlt comments in i386/i386/machdep.c (last July). I wish we had a better mechanism then the stupid IPI stuff, like a simple per-cpu latch/acknowledge level interrupt (softint), but we don't. Thanks, Intel. 8-). I don't think we want to over-engineer per-cpu scheduling. The system really doesn't know what cpu a task is going to wind up running on until a cpu scheduler (sched_choose()) comes along and needs to locate the next task to run. Too many things can happen in between the initiation of the wait, the wakeup, and the task actually getting cpu. Introducing a complex per-cpu wait queue or trying to do something complex at wakeup time instead of at sched_choose() time is just going to be a waste of time. I think it is best to wakeup a task by placing it on the same cpu run queue as it was previously on (which is what Jeffs code does for the most part), The approach I've *always* advocated involves per-CPU run queues. While it's possible to implement affinity and negaffinity with a global queue, like Linux did, it's not really a good idea. I know that the current Linux code works, because Ingo Molnar put a huge amount of effort into it. However, the problem of affinity is not NP-complete, and it's not really possible to deal with it with a single queue. Noting the process which is awoken gets on the same CPU ready-to-run queue is just an obvious way of dealing with CPU affinity. It fails to deal with negaffinity, which is necessary for parallel execution, and it fails to deal with the issue of eliminating locks: you still get the TLB shootdowns, cache line invalidations, and inter-APIC arbitration traffic, even if you don't issue an explicit IPI. and deal with task stealing in sched_choose(). A task stealing or pull approach to balancing is just plain wrong. It can't deal with transient load spikes, which should be expected in any heterogeneous load situation. This is the reason you never see anyone running benchmarks on such a system, without the system being otherwise idle, and without homogeneous test loads: hetergenous test loads would fail to show improvement, due to excessive bouncing. The other problem with a pull model is that it requires that the per CPU scheduler queue be locked on all accesses, so a different CPU can lock it to traverse it to pull new tasks for itself. Finally, the pull model is very hard to deal with SMT, in terms of making negaffinity decisions (you have to know too much), or giving an intentional affinity bias (e.g. stay on the same physical CPU, but go to the other side to avoid cache-busting). By going to a push model, you limit locking to the migration code path, and a per-CPU check for a non-NULL per-CPU migration list head can be done without acquiring the lock that must be acquired to pull data off the migration queue, or to push tasks off to another CPU (locking the target's queue for the operation). What that means is no locking in the common case. And no cache line invalidation, and no TLB shootdown, and no inter-APIC arbitration. Actually, it's very easy to compare these models implicitly, by running a single CPU with SMT enabled, and comparing it to two identical CPUs, with SMT disabled, such that the only real change is the shared parts, and the lack of the cache, TLB, and APIC crap in the first case. With the inherent stalls from shared resources in the SMT case, you'd expect a true SMP to have significantly higher performance than SMT. But that's not what you see, even with Jeff's new scheduler. The scheduler, when it comes time to actually switch in the next runnable task, then deals with complexities associated with misbalancing (i.e. cpu A is idle and ready to accept a new task, and cpu B's run-queue has a task ready to be run). Yes, currently, and this is wrong. Or rather, the underutilized CPU should not be doing the balancing, if it has to stall the most heavily loaded CPU in order to do it... and therefore, pull is wrong. What *should* happen is that, at the time of the next context switch, the heavily loaded CPU should decide to shed load. Proper hysteresis really wants that decision to be made periodically, with a periodicity equal to once per (N+1) entries into the per CPU scheduler, where N is the number of CPUs participating in the SMP region in which tasks may be migrated (as part of the strategy for avoiding excessive migration). If this decision can be made on a single figure of merit, which we'll call load, and the figure is stored in an atomic (e.g. integer) data area, then it can be read without locks. Since it's only written by the CPU for whom it's the figure of merit, again, no locks are required to arbitrate the process of determining a load imbalace. While it is true that we would like a cpu to predominantly
Re: cvs commit: src/sbin/disklabel disklabel.8 disklabel.c
At 1:01 PM +0100 2003/01/26, [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Ruslan Ermilov writes: Welcome to the club if people who was bitten by the poor design choices in the BSD disklabel. Now the question. Where is the code in the kernel that prevents swapping and/or writing to a disklabel portion of a physically first partition on the disk? This reminds me of a related suggestion / request. boot0cfg should be smarter, and require confirmation (unless forced) before overwrite a disklabel with an MBR (boot0cfg -b /dev/ad0s2g or similar). I believe overwriting a disklabel is much more likely to be pilot error, as in my case, than an deliberate choice. boot0cfg.8 says: On PCs, a boot manager typically occupies sector 0 of a disk, which is known as the Master Boot Record (MBR). The MBR contains both code (to which control is passed by the PC BIOS) and data (an embedded table of defined slices). Regards, Chris Pepper -- Chris Pepper: http://www.reppep.com/~pepper/ Rockefeller University: http://www.rockefeller.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
On Sun, 2 Feb 2003, Brad Knowles wrote: At 10:47 AM -0800 2003/02/01, Julian Elischer wrote: still no comments? this patch seems to be working, but a review from another developer would be good.. particularly re: the point mentionned.. [...] If I am wrong and it is normal to expect a reasonable response within this period of time and within this particular period of time on a Saturday morning, please let me know. I guess I am spoiled by working on FreeBSD a few years ago when one could expect at least 4 or 5 responses overnight. The developers now are so over-worked that it is quite possible these days to put out a proposal on and have no-one respond to it for two weeks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
At 6:27 PM -0800 2003/02/01, Matthew Dillon wrote: Well, it is an active conversation/thread. Either people care enough to stay involved or they don't. But don't people have to sleep sometime? Shouldn't we allow for that? I mean, I can understand impatience, too. I get impatient when I've done things and I'm waiting on other people to respond. I guess I'm just trying to find out what level of impatience would be appropriate in this kind of situation -- given the amount of time that had passed and the specific day and hours in question. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
On Sat, 1 Feb 2003, Julian Elischer wrote: On Sun, 2 Feb 2003, Brad Knowles wrote: At 10:47 AM -0800 2003/02/01, Julian Elischer wrote: still no comments? this patch seems to be working, but a review from another developer would be good.. particularly re: the point mentionned.. [...] If I am wrong and it is normal to expect a reasonable response within this period of time and within this particular period of time on a Saturday morning, please let me know. I guess I am spoiled by working on FreeBSD a few years ago when one could expect at least 4 or 5 responses overnight. The developers now are so over-worked that it is quite possible these days to put out a proposal on and have no-one respond to it for two weeks. I might add that the patch was part of one that was already under discussion so all the people who declared the other patch broken should have already reviewed this code. (one would think that one wouldn't call for or a backout if one hasn't even looked at the patch concerned) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
On 2003-02-01 19:31, Garrett Wollman [EMAIL PROTECTED] wrote: On Sat, 01 Feb 2003 16:02:57 -0800, Bakul Shah [EMAIL PROTECTED] said: I can't see what actual error is avoided by this warning. My personal opinion, which is different from what style(9) recommends, is that parameter names should be omitted for all functions, EXCEPT those with ambiguous parameter types. This is what I am almost inclined to agree with too. But then, headers are one of the sources of information for newbie programmers too. I have learned a lot of stuff by reading headers and not having names in any prototype would arguably make it harder to use the prototypes of functions in headers to learn things :-/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
did the backout solve anything?
In an attempt to understand where and how the last KSE patch may have been broken, I'd like to know if there is anyone who had a system magically cured by the backout. (Assuming you had the 'ticks' patch beforehand). If so, can you tell me what your system was doing wrong beforehand, and what kind of system you have? Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
Matthew Dillon wrote:
Mark Murray wrote:
:Then can we just get the proc.h prototypes into a (any) consistent
:style?
Yes; no brainer, except where Garrett has indicated (e.g. a
function that takes a fromvp and tovp, or other similar arguments).
Lets ask ourselves what the goal of the named prototypes is... the
compiler doesn't need them, obviously, so one would presume that the
goal is human readability.
Technically, the compiler doesn't need prototypes at all; they
are merely a band-aid for the compiler vendors, who did not want
to have to deal with changing object file format. Because of
that, we also have symbol decoration for C++, and we have a C++
compiler that requires explicit declaration of some functions
which should be implicit. If the object file had attribution,
and you wanted to make implied coercion, the linker could emit
glue, as necessary, and be done with it: no prototypes in scope.
If you wanted to disallow implied coercion, it could be a link-time
error. Either way, the same complaining could take place, with
no need to abuse the compiler semantics.
Prototypes, in general, are things for compiler vendors, and the
goal of the named arguments in a prototype was, at least at one
point, to help out ANSI C compilers that wanted to requse the
function declaration parsing code, and would barf without some
token there to jam into a symbol table. The shadowing warning
that is being complained about by Mark Murray is, as has been
pointed out, a compiler bug: according to the standards, the
symbols are supposed to go out of scope anyway. In fact, it should
ignore tokens to the coma or closing parenthesis, and not be bitching
in the first place.
So if we care about human readability we should simply name them after
the argument names used in the procedures proper. If we don't care
about human readability we should omit the names entirely.
Yes, this makes sense. The grip that Garrett brought up is an
artifact of the compiler being stupid. In fact, the same problem
would occur for the function declaration, and all compilation units
for which there are header files containing prototypes should include
those headers themselves, in order to ensure the prototype was in
scope at the time the function was encountered, to insure against
trivial errors from the prototype not matching the function declaration.
Thus, if the prototype is:
int xxx(int _foo);
Then the function should be:
int xxx(int _foo)
{
}
...since what a
#define foo foobaz.bazu_foo
will do to a prototype declaration, it will surely do to the function
declaration as well, if it is in a header which is in scope at the
time the compiler encounters the actual function declaration.
An underscore would be detrimental to human readability. It makes the
prototypes look rather nasty when I look at the fully patched proc.h,
and also makes them different from the arguments as declared in the
procedures proper.
It's just ugly, in general, and confusing, when combined with
structure pointer element references. 8-(.
[ ... ]
And it goes on. Quite a mess we have, actually. We still have __P in
many places. The newest header file would arguably be acl.h in which
the author used underscores. I can't say I like the way it reads on the
screen. Older header files either still have __P, don't have __P and
the arguments are named (typically without an underscore), or mix with
some of the arguments named and some not (some wholely not).
So let Mark correct them into uniformity; that can be done
without protecting everything, which can be done as a seperate
protection or argument name removal pass.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: split out patch
Brad Knowles [EMAIL PROTECTED] writes: At 6:27 PM -0800 2003/02/01, Matthew Dillon wrote: Well, it is an active conversation/thread. Either people care enough to stay involved or they don't. But don't people have to sleep sometime? Shouldn't we allow for that? Real hackers don't sleep. :) Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mylex support under 5.0-R
Simon, This is a known issue. Have a look at http://www.freebsd.org/releases/5.0R/errata.html under section 3 (Late-Breaking News). Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ On Fri, 31 Jan 2003, Simon wrote: Hi, Is it just me or is the Mylex driver broken under FreeBSD 5.0-Release? I couldn't dig up anything related in archives. I'm aware of bootup issues using Mylex cards, but I already have it installed on IDE and trying to work with a drive connected to a mylex controller locks up the system. Thank you, Simon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
On Sat, 1 Feb 2003, Mike Barcroft wrote: Brad Knowles [EMAIL PROTECTED] writes: At 6:27 PM -0800 2003/02/01, Matthew Dillon wrote: Well, it is an active conversation/thread. Either people care enough to stay involved or they don't. But don't people have to sleep sometime? Shouldn't we allow for that? Real hackers don't sleep. :) That as may be, but even real hackers can't poll every mailing list every five minutes :-). Otherwise, real hackers would have no time for coding, and that might present a problem. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
On Sat 01 Feb, Steve Kargl wrote: From: Steve Kargl [EMAIL PROTECTED] To: Julian Elischer [EMAIL PROTECTED] Cc: Mark Murray [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Style fixups for proc.h On Sat, Feb 01, 2003 at 03:04:32PM -0800, Julian Elischer wrote: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. It's certainly not part of style(9) that I've ever noticed and it's generally noy done that way.. is there a move to do this on all the other files? man 9 style In header files visible to userland applications, prototypes that are visible must use either ``protected'' names (ones beginning with an underscore) or no names with the types. It is preferable to use pro- tected names. E.g., use: voidfunction(int); or: voidfunction(int _fd); Since having actual names in can be helpful if the names are relevant, but having dozens of *_p floating all over the place is not more easily readable, why not leave names out completely when they are not relevant and protect with the underscore when they are? This agrees with style(9). Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h
Well, there is something to be said for trying to avoid userland namespace pollution, but it is still somewhat of a stretch since most userland programs #include standard and system headers before they #include their own, and the includes are typically done before any code. But I see no reason why the underscore methodology would need to be used for kernelland prototypes. C has its problems and we need to live with them, but we shouldn't have to add bogus underscores to prototyped arguments to work around those problems. I'd prefer normally named arguments but if I were given only a choice between underscored named arguments and unnamed arguments, I'd take unnamed arguments hands down. -Matt :Actually, the pattern is that the function prototypes exposed to userspace :are prefixed with '_' to prevent interfering with the application :namespace. The ones exposed only in the kernel don't. I should probably :update the kernel ones as well. This is mostly because of the profound :evils associated with the C preprocessor, which can cause substitutions to :occur in function prototypes (this is often used intentionally). : :For an example of this evil: there appears to be a convention in which we :name structure elements with a prefix, such as m_blah, based on the :structure name. At one point I added m_flags to struct mac. When I :included mbuf.h, this became m_hdr.mh_flags, resulting in fairly obtuse :compile errors. Protecting user applications against hard to understand :compile errors is an important part of providing useful include files to :application writers, so avoiding exposing things to the application :namespace where it can be avoided. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Projects To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h by andrew@driftin.net
On Sat 01 Feb, Matthew Dillon wrote: Well, there is something to be said for trying to avoid userland namespace pollution, but it is still somewhat of a stretch since most userland programs #include standard and system headers before they #include their own, and the includes are typically done before any code. But I see no reason why the underscore methodology would need to be used for kernelland prototypes. C has its problems and we need to live with them, but we shouldn't have to add bogus underscores to prototyped arguments to work around those problems. I'd prefer normally named arguments but if I were given only a choice between underscored named arguments and unnamed arguments, I'd take unnamed arguments hands down. As has been said earlier in this thread, having named arguments can often help new coders learn and help readability (one knows what an argument is for from looking at the header file as opposed to having to look through the C file), which is why I suggested having underscored named arguments when they are useful to have named, and no names when naming them is not useful. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rand() is broken
FreeBSD's rand() implementation has been broken for the past 23
months, since the following commit:
Revision 1.3 / (download) - annotate - [select for diffs], Tue Feb 27 14:42:19 2001
UTC (23 months ago) by ache
Branch: MAIN
Changes since 1.2: +26 -0 lines
Diff to previous 1.2 (colored)
Use formula with better random distribution for rand()
Even better formula from random() could not be intetgrated because rand_r()
supposed to store its state in the single variable (but table needed for
random() algorithm integration).
The following simple test program exhibits the breakage:
#include stdlib.h
#include stdio.h
int main() {
int i;
for(i=1; i=1000; i++) {
srand(i);
printf(%d: %d\n, i, rand());
}
}
1: 16807
2: 33614
3: 50421
4: 67228
5: 84035
6: 100842
7: 117649
8: 134456
9: 151263
10: 168070
11: 184877
12: 201684
13: 218491
14: 235298
15: 252105
16: 268912
17: 285719
18: 302526
...
i.e. the first value returned from rand() is correlated with the seed
given to srand(). This is a big problem unless your seed is randomly
chosen over its entire integer range. I noticed this because awk
exhibits the same problem, and the script seeds the generator with a
PID. The script works fine under 4.x since the rand() implementation
does not have this feature.
Kris
msg51490/pgp0.pgp
Description: PGP signature
