Re: utmpx for OpenBSD
On Tue, 13 Jul 2010, Christian Weisgerber wrote: > Theo de Raadt wrote: > > > > - posix_openpt(), grantpt(), unlockpt() and ptsname(), and > > > - utmpx. > > > > > > This causes a real burden on people trying to write network login > > > services, terminal emulators, terminal multiplexers, etc. > > > > You are killing us with hyperbole. > > Well, I have been waiting for some time for porters to run against > a wall because of the lack of posix_openpt() etc, but so far it > hasn't happened yet. I know of some functionnalities in gnomevfs and gvfs that don't work because of this (not such a big of a deal; I've been wanting to port it to openpty if possible but never found the time yet). Also, devel/vte installs libexec/gnome-pty-helper setgid utmp because of the same reason. These are the only ones that I am aware of that would need some "love". -- Antoine
Re: utmpx for OpenBSD
On Tue, Jul 13, 2010 at 10:28:47PM +, Christian Weisgerber wrote: > Theo de Raadt wrote: > > > > - posix_openpt(), grantpt(), unlockpt() and ptsname(), and > > > - utmpx. > > > > > > This causes a real burden on people trying to write network login > > > services, terminal emulators, terminal multiplexers, etc. > > > > You are killing us with hyperbole. > > Well, I have been waiting for some time for porters to run against > a wall because of the lack of posix_openpt() etc, but so far it > hasn't happened yet. > > I certainly don't think it's a burden on third party developers--they'll > just shrug and ignore us. > > (app/luit in xenocara was broken until I fixed it to use openpty(); > the upstream of net/rtorrent essentially told me to shove it if we > didn't support the POSIX interface and ignored my patch, but that > was for a configure test and isn't even really used in the program.) When I initially ported SBCL, it took me all of half an hour to realize the standard POSIX interfaces weren't available, read the docs of the native interfaces, then modify the code to use openpty() on OpenBSD. It's not like any real-world program doesn't already have it's share of the language's equivalent of #ifdefs.
typos in #ifdef DEBUG
Hi tech@
While building a kernel with option DEBUG to try to hunt down my issue
with the Libretto 70CT (PR 6052) I came across the following typos which
prevented the build:
sys/arch/i386/i386/trap.c
--- trap.c Wed Jul 14 00:55:31 2010
+++ mytrap.cWed Jul 14 00:44:26 2010
@@ -173,7 +173,7 @@
#ifdef DEBUG
if (trapdebug) {
printf("trap %d code %x eip %x cs %x eflags %x cr2 %x
cpl %x\n",
- frame->tf_trapno, frame->tf_err, frame.->f_eip,
+ frame->tf_trapno, frame->tf_err, frame->tf_eip,
frame->tf_cs, frame->tf_eflags, rcr2(), lapic_tpr);
printf("curproc %p\n", curproc);
}
and in sys/kern/dma_alloc.c
--- dma_alloc.c Wed Jul 14 01:05:14 2010
+++ my_dma_alloc.c Wed Jul 14 00:26:56 2010
@@ -49,7 +49,7 @@
if (sz <= (1 << (b + DMA_BUCKET_OFFSET)))
return (b);
#ifdef DEBUG
- printf("dma_alloc/free: object %d too large\n", sz)
+ printf("dma_alloc/free: object %d too large\n", sz);
#endif
return (-1);
}
Thanks
Fred
Re: utmpx for OpenBSD
Theo de Raadt wrote: > > - posix_openpt(), grantpt(), unlockpt() and ptsname(), and > > - utmpx. > > > > This causes a real burden on people trying to write network login > > services, terminal emulators, terminal multiplexers, etc. > > You are killing us with hyperbole. Well, I have been waiting for some time for porters to run against a wall because of the lack of posix_openpt() etc, but so far it hasn't happened yet. I certainly don't think it's a burden on third party developers--they'll just shrug and ignore us. (app/luit in xenocara was broken until I fixed it to use openpty(); the upstream of net/rtorrent essentially told me to shove it if we didn't support the POSIX interface and ignored my patch, but that was for a configure test and isn't even really used in the program.) -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: utmpx for OpenBSD
> * Theo de Raadt wrote: > > First off, to get that off the plate, we don't have the POSIX, no call > > it what it is --- SVR4 -- pty stuff because it is a gigantic race. It > > was designed in response to the pty race research by Dan Bernstein, > > but the result was that the SVR4 guys still got it wrong. > > Can you please explain why. As I mentioned a long time, our > implementation on FreeBSD implements grantpt() and unlockpt() as no-ops, > which will be allowed behaviour as of the next version of POSIX. Is > FreeBSD's implementation also affected by this race? If not, why not > implement something similar for OpenBSD? I don't see the point. > > But regarding the utmpx stuff, you've now sent us a diff which > > - writes uninitialized stack data to the file (date.c, init.c, > > perhaps more) > > No, it does not. Our implementation never writes inapplicable fields or > data past terminating null bytes of strings to disk. If you want, I can > add the memset() calls for you. So, since your library code is safe, you go and write unsafe applications, so that if anyone else copies the code and uses it somewhere else, it will cause risk. You will not add memset calls for me -- You'll add them because it is the only right programming model. > > - delete etc/ttys.pty because you don't know what it is for > > There is really no use to store pseudo-terminals in /etc/ttys, since the > utmpx implementation does not use any slot-based indexing. Apart from > utmp, I've never seen any other pieces of code that use the slot > numbering as well. What a load of bullshit. There is a need since there are old applications which still use the old way of opening ttys. > > - removes an API from libc which you have not verified > > is unused > > - crank the minor of libc, without realizing that since you have > > changed and removed interfaces, you would need to do a *major* > > bump of libc, libutil, a few X libraries, and probably 20-30 > > packages with libraries which will now detect the new interfaces > > and potentially change the behaviour. > > Well, and ttyslot() have been removed, since my experience has > been that supporting both utmp and utmpx in fact causes more breakage. Not interested. > > - sneaks bits of incompatible behaviour into various programs > > (ie. last) > > Can you please clarify? As I mentioned, take into account that the patch > is not yet complete, finished, etc. I think I've said enough. > > We have a utmp which was extended a decade ago to have much longer fields. > > It works just fine. > >=20 > > I don't see what benefit the extra junk in the utmpx file provides to > > anyone. Oh, it's got a pid, so that you can send a signal to the wrong > > process... > > I'm not saying utmpx is some kind of Endl=F6sung or anything. At least > it's standardized by *something*. If there are things in your eyes wrong > with standards like POSIX, why not discuss those issues with the Austin > Group? I don't see a need in glibc compatibility.
Re: utmpx for OpenBSD
Hi Theo, * Theo de Raadt wrote: > First off, to get that off the plate, we don't have the POSIX, no call > it what it is --- SVR4 -- pty stuff because it is a gigantic race. It > was designed in response to the pty race research by Dan Bernstein, > but the result was that the SVR4 guys still got it wrong. Can you please explain why. As I mentioned a long time, our implementation on FreeBSD implements grantpt() and unlockpt() as no-ops, which will be allowed behaviour as of the next version of POSIX. Is FreeBSD's implementation also affected by this race? If not, why not implement something similar for OpenBSD? > But regarding the utmpx stuff, you've now sent us a diff which > - writes uninitialized stack data to the file (date.c, init.c, > perhaps more) No, it does not. Our implementation never writes inapplicable fields or data past terminating null bytes of strings to disk. If you want, I can add the memset() calls for you. > - delete etc/ttys.pty because you don't know what it is for There is really no use to store pseudo-terminals in /etc/ttys, since the utmpx implementation does not use any slot-based indexing. Apart from utmp, I've never seen any other pieces of code that use the slot numbering as well. > - removes an API from libc which you have not verified > is unused > - crank the minor of libc, without realizing that since you have > changed and removed interfaces, you would need to do a *major* > bump of libc, libutil, a few X libraries, and probably 20-30 > packages with libraries which will now detect the new interfaces > and potentially change the behaviour. Well, and ttyslot() have been removed, since my experience has been that supporting both utmp and utmpx in fact causes more breakage. > - sneaks bits of incompatible behaviour into various programs > (ie. last) Can you please clarify? As I mentioned, take into account that the patch is not yet complete, finished, etc. > We have a utmp which was extended a decade ago to have much longer fields. > It works just fine. > > I don't see what benefit the extra junk in the utmpx file provides to > anyone. Oh, it's got a pid, so that you can send a signal to the wrong > process... I'm not saying utmpx is some kind of Endlvsung or anything. At least it's standardized by *something*. If there are things in your eyes wrong with standards like POSIX, why not discuss those issues with the Austin Group? -- Ed Schouten WWW: http://80386.nl/ [demime 1.01d removed an attachment of type application/pgp-signature]
Re: utmpx for OpenBSD
On Tue, Jul 13, 2010 at 9:45 AM, Ed Schouten wrote: > I sent an email to tedu@ the other day, but I thought it may be better > to just send it to tech@ to see whether we can sort this out. Don't worry, I have not ignored your mail, only postponed processing it. > - Is there any interest in getting utmpx support integrated into > OpenBSD? > - If so, is there a developer willing to work with me to get my patchset > smashed into shape and eventually committed? I could be considered an interested party, but for the most part "newer for the sake of being newer" patches don't carry a lot of momentum. If the main concern is you have software that uses these interfaces and you want it to run on OpenBSD, I think if it's interesting software than there are people here (or ports@ more likely) who can help making it run on OpenBSD.
Re: em(4) testers required
On Wed, Jul 14, 2010 at 01:40:26AM +1000, Jonathan Gray wrote:
> On Tue, Jul 13, 2010 at 01:58:50PM +, Michael Shalayeff wrote:
> > re
> > i was testing the diff on our shitz here and it works.
> > dual-port Intel PRO/1000 on pci-express and on-boards.
> > added a couple more checks where it seemed to make sense.
> > those ports having problems before seem to work now.
> > cu
>
> Skipping the parts from the original diff
>
> > @@ -846,20 +847,21 @@ em_initialize_hardware_bits(struct em_hw *hw)
> >
> > if (reg_tctl & E1000_TCTL_MULR)
> > reg_tarc1 &= ~0x1000; /* Clear bit 28 if MULR is
> > 1b */
> > else
> > reg_tarc1 |= 0x1000;/* Set bit 28 if MULR is
> > 0b */
> >
> > E1000_WRITE_REG(hw, TARC1, reg_tarc1);
> > break;
> > case em_82573:
> > case em_82574:
> > +case em_82575:
> > reg_ctrl_ext = E1000_READ_REG(hw, CTRL_EXT);
> > reg_ctrl = E1000_READ_REG(hw, CTRL);
> >
> > reg_ctrl_ext &= ~0x0080;/* Clear bit 23 */
> > reg_ctrl_ext |= 0x0040; /* Set bit 22 */
> > reg_ctrl &= ~0x2000;/* Clear bit 29 */
> >
> > E1000_WRITE_REG(hw, CTRL_EXT, reg_ctrl_ext);
> > E1000_WRITE_REG(hw, CTRL, reg_ctrl);
> > break;
>
> What are these magic numbers doing and why is it needed on 82575+?
magic io pins (: freebsd does it seems...
> > @@ -5944,20 +5946,21 @@ em_rar_set(struct em_hw *hw,
> > * while we work. Then, we clear the Address Valid AV bit for all MAC
> > * addresses and undo the re-direction to manageability.
> > * Now, frames are coming in again, but the MAC won't accept them, so
> > * far so good. We now proceed to initialize RSS (if necessary) and
> > * configure the Rx unit. Last, we re-enable the AV bits and continue
> > * on our merry way.
> > */
> > switch (hw->mac_type) {
> > case em_82571:
> > case em_82572:
> > +case em_82575:
> > case em_80003es2lan:
> > if (hw->leave_av_bit_off == TRUE)
> > break;
> > default:
> > /* Indicate to hardware the Address is Valid. */
> > rar_high |= E1000_RAH_AV;
> > break;
> > }
> >
> > E1000_WRITE_REG_ARRAY(hw, RA, (index << 1), rar_low);
>
> I'm not convinced about this part either, the rar handling
> in the most recent version of the Intel code in FreeBSD is
> quite different, perhaps more than just this should be changed.
well it seems to follow the behaviour of earlier chips so it seems
logical to do it same way.
cu
--
paranoic mickey (my employers have changed but, the name has remained)
Re: utmpx for OpenBSD
> I sent an email to tedu@ the other day, but I thought it may be better > to just send it to tech@ to see whether we can sort this out. > > After I implemented utmpx for FreeBSD, I realized OpenBSD is the only > commonly used maintained UNIX-like operating system which doesn't > implement: > > - posix_openpt(), grantpt(), unlockpt() and ptsname(), and > - utmpx. > > This causes a real burden on people trying to write network login > services, terminal emulators, terminal multiplexers, etc. You are killing us with hyperbole. It is now hard to take anything you say seriously. > It would be so > much easier if authors of (new) pieces of software can just use these > interfaces with confidence and expect things to work properly. I strongly doubt it, since the old and new interfaces both suck, just in different ways. This is apparent from the size of your diff and the number of errors introduced. > So as a proof of concept I am working on a patchset, where I took my > utmpx implementation that I wrote for FreeBSD and added it to OpenBSD's > libc. It also contains patches for various utilities in the base system > to let it use utmpx. It is by no means complete, but should give you at > least an idea of what it's going to look like. Below is a link to the > latest version: > > http://80386.nl/pub/openbsd-utmpx.txt > > Ignoring the build failures, it is already possible to ssh into the > system and send messages to each other using wall/write. > > I have two questions: > > - Is there any interest in getting utmpx support integrated into > OpenBSD? > - If so, is there a developer willing to work with me to get my patchset > smashed into shape and eventually committed? If I recall correctly, we've told you no before, because you've pushed for this about two years ago. First off, to get that off the plate, we don't have the POSIX, no call it what it is --- SVR4 -- pty stuff because it is a gigantic race. It was designed in response to the pty race research by Dan Bernstein, but the result was that the SVR4 guys still got it wrong. But regarding the utmpx stuff, you've now sent us a diff which - writes uninitialized stack data to the file (date.c, init.c, perhaps more) - delete etc/ttys.pty because you don't know what it is for - removes an API from libc which you have not verified is unused - crank the minor of libc, without realizing that since you have changed and removed interfaces, you would need to do a *major* bump of libc, libutil, a few X libraries, and probably 20-30 packages with libraries which will now detect the new interfaces and potentially change the behaviour. - sneaks bits of incompatible behaviour into various programs (ie. last) We have a utmp which was extended a decade ago to have much longer fields. It works just fine. I don't see what benefit the extra junk in the utmpx file provides to anyone. Oh, it's got a pid, so that you can send a signal to the wrong process...
Re: cvsinfo
On Tue, Jul 13, 2010 at 10:20:58AM -0600, Tobias Weingartner wrote: > On Tuesday, July 13, Jonathan Gray wrote: > > On Mon, Jul 12, 2010 at 09:32:30PM -0400, Ted Unangst wrote: > > > To help investigate some changes recently, I wrote a tool that will > > > extract (reverse) patches from cvs. I was telling a coworker about this > > > today, and he said it was a lot like cvsps. Maybe it is, but cvsps > > > chokes > > > big time trying to import our tree. Running it just in sys/dev for > > > testing printed billions of lines of nonsense warnings without making > > > much progress. > > > > This is because cvsps interprets the rcs information in a log > > message of midway.c wrong, manually fixing it works > > around the problem. > > It's not all that hard to write a yacc/lex parser that can parse *,v > RCS files and pull out what you need... :) So, when are you going to have it ready, tomorrow ? :-)
Re: cvsinfo
On Tuesday, July 13, Jonathan Gray wrote: > On Mon, Jul 12, 2010 at 09:32:30PM -0400, Ted Unangst wrote: > > To help investigate some changes recently, I wrote a tool that will > > extract (reverse) patches from cvs. I was telling a coworker about this > > today, and he said it was a lot like cvsps. Maybe it is, but cvsps chokes > > big time trying to import our tree. Running it just in sys/dev for > > testing printed billions of lines of nonsense warnings without making > > much progress. > > This is because cvsps interprets the rcs information in a log > message of midway.c wrong, manually fixing it works > around the problem. It's not all that hard to write a yacc/lex parser that can parse *,v RCS files and pull out what you need... :) --Toby.
Re: utmpx for OpenBSD
> This causes a real burden on people trying to write network login > services, terminal emulators, terminal multiplexers, etc. it is really hard to take you serious when you say that every year, to us.
Re: em(4) testers required
On Tue, Jul 13, 2010 at 01:58:50PM +, Michael Shalayeff wrote:
> re
> i was testing the diff on our shitz here and it works.
> dual-port Intel PRO/1000 on pci-express and on-boards.
> added a couple more checks where it seemed to make sense.
> those ports having problems before seem to work now.
> cu
Skipping the parts from the original diff
> @@ -846,20 +847,21 @@ em_initialize_hardware_bits(struct em_hw *hw)
>
> if (reg_tctl & E1000_TCTL_MULR)
> reg_tarc1 &= ~0x1000; /* Clear bit 28 if MULR is
> 1b */
> else
> reg_tarc1 |= 0x1000;/* Set bit 28 if MULR is 0b
> */
>
> E1000_WRITE_REG(hw, TARC1, reg_tarc1);
> break;
> case em_82573:
> case em_82574:
> +case em_82575:
> reg_ctrl_ext = E1000_READ_REG(hw, CTRL_EXT);
> reg_ctrl = E1000_READ_REG(hw, CTRL);
>
> reg_ctrl_ext &= ~0x0080;/* Clear bit 23 */
> reg_ctrl_ext |= 0x0040; /* Set bit 22 */
> reg_ctrl &= ~0x2000;/* Clear bit 29 */
>
> E1000_WRITE_REG(hw, CTRL_EXT, reg_ctrl_ext);
> E1000_WRITE_REG(hw, CTRL, reg_ctrl);
> break;
What are these magic numbers doing and why is it needed on 82575+?
> @@ -3864,21 +3866,21 @@ em_write_phy_reg_ex(struct em_hw *hw, uint32_t reg_add
>
> STATIC int32_t
> em_read_kmrn_reg(struct em_hw *hw,
> uint32_t reg_addr,
> uint16_t *data)
> {
> uint32_t reg_val;
> uint16_t swfw;
> DEBUGFUNC("em_read_kmrn_reg");
>
> -if ((hw->mac_type == em_80003es2lan) &&
> +if ((hw->mac_type == em_80003es2lan || hw->mac_type == em_82575) &&
> (E1000_READ_REG(hw, STATUS) & E1000_STATUS_FUNC_1)) {
> swfw = E1000_SWFW_PHY1_SM;
> } else {
> swfw = E1000_SWFW_PHY0_SM;
> }
> if (em_swfw_sync_acquire(hw, swfw))
> return -E1000_ERR_SWFW_SYNC;
>
> /* Write register address */
> reg_val = ((reg_addr << E1000_KUMCTRLSTA_OFFSET_SHIFT) &
Yes, although this function is never called on 82575/82576.
> @@ -5944,20 +5946,21 @@ em_rar_set(struct em_hw *hw,
> * while we work. Then, we clear the Address Valid AV bit for all MAC
> * addresses and undo the re-direction to manageability.
> * Now, frames are coming in again, but the MAC won't accept them, so
> * far so good. We now proceed to initialize RSS (if necessary) and
> * configure the Rx unit. Last, we re-enable the AV bits and continue
> * on our merry way.
> */
> switch (hw->mac_type) {
> case em_82571:
> case em_82572:
> +case em_82575:
> case em_80003es2lan:
> if (hw->leave_av_bit_off == TRUE)
> break;
> default:
> /* Indicate to hardware the Address is Valid. */
> rar_high |= E1000_RAH_AV;
> break;
> }
>
> E1000_WRITE_REG_ARRAY(hw, RA, (index << 1), rar_low);
I'm not convinced about this part either, the rar handling
in the most recent version of the Intel code in FreeBSD is
quite different, perhaps more than just this should be changed.
Re: utmpx for OpenBSD
Hi I'm interested, although I don't know what other opinions are of utmpx. >From a quick look: - Why delete ttyslot? Or, at least, why at the same time? Seems like better done separately later to me. - Not sure about removing the signal handler in last. - How much third party software is this likely to affect since it is breaking the existing interface? It would be easier to have separate diffs for each bit: add utmpx, remove utmp and for each program. Can both utmp and utmpx coexist, at least temporarily? On Tue, Jul 13, 2010 at 03:45:33PM +0200, Ed Schouten wrote: > Hi folks, > > I sent an email to tedu@ the other day, but I thought it may be better > to just send it to tech@ to see whether we can sort this out. > > After I implemented utmpx for FreeBSD, I realized OpenBSD is the only > commonly used maintained UNIX-like operating system which doesn't > implement: > > - posix_openpt(), grantpt(), unlockpt() and ptsname(), and > - utmpx. > > This causes a real burden on people trying to write network login > services, terminal emulators, terminal multiplexers, etc. It would be so > much easier if authors of (new) pieces of software can just use these > interfaces with confidence and expect things to work properly. > > So as a proof of concept I am working on a patchset, where I took my > utmpx implementation that I wrote for FreeBSD and added it to OpenBSD's > libc. It also contains patches for various utilities in the base system > to let it use utmpx. It is by no means complete, but should give you at > least an idea of what it's going to look like. Below is a link to the > latest version: > > http://80386.nl/pub/openbsd-utmpx.txt > > Ignoring the build failures, it is already possible to ssh into the > system and send messages to each other using wall/write. > > I have two questions: > > - Is there any interest in getting utmpx support integrated into > OpenBSD? > - If so, is there a developer willing to work with me to get my patchset > smashed into shape and eventually committed? > > Greetings, > -- > Ed Schouten > > [demime 1.01d removed an attachment of type application/pgp-signature]
Još veći popusti celo leto
NajveDi Top Shop popusti do sada Niske cene... I još niE>e! Najbolje cene ovog leta, samo za vas! Uz popuste koji veD vaE>e, svaka 4 dana još jedan proizvod iz programa fitnes, lepota, zdrav E>ivot ili domaDinstvo na raspolaganju je uz... DODATNI POPUST od -10%! Ekskluzivna sniE>enja traju do isteka zaliha! Zato poE>urite. Sve iz ove super ponude moE>ete videti OVDE! Vreme je kupovinu uz popust - ne oklevajte! 1. Najbolje iz fitnes ponude - do 62% popusta Shake Weight -52% Shake Weight Vaša cena: 1.190 RSD PoruD i! 3 Minute Legs -30% 3 Minute Legs Vaša cena: 3.490 RSD PoruD i! Winsor Pilates -62% Winsor Pilates Vaša cena: 1.341 RSD PoruD i! 2. Hit proizvodi za zavodljiv izgled, do 48% popusta Velform Enhance Bra -29% Velform Enchance Bra Vaša cena: 2.490 RSD PoruD i! Tweeze -48% Tweeze Vaša cena: 1.290 RSD PoruD i! Velform Sauna Massage -31% Velform Sauna Massage Vaša cena: 4.490 RSD PoruD i! 3. Potrebno u svakom domaDinstvu, do 40% popusta Samurai Shark -40% Samurai Shark Vaša cena: 1.490 RSD PoruD i! Perfect Peddy -8% Perfect Peddy Vaša cena: 1.490 RSD PoruD i! Perfect Brownie -39% Perfect Brownie Vaša cena: 1.590 RSD PoruD i! 4. FantastiD no opuštanje u Vašem domu, do 50% popusta Back Magic -40% Back Magic Dodatnih 10%: 1.341 RSD PoruD i! Side Sleeper Pro -50% Side Sleeper Pro Vaša cena: 1.490 RSD PoruD i! Dragon Fly -45% Dragon Fly Vaša cena: 2.490 RSD PoruD i! 5. Proizvodi za automobil i uradi sam, do 60% popusta Slime Smart -43% Slime Smart Vaša cena: 2.290 RSD PoruD i! Point and Paint -60% Point and Paint Vaša cena: 1.190 RSD PoruD i! Mighty Putty -50% Mighty Putti Vaša cena: 1.390 RSD PoruD i! Devojke ponovite se za leto - Quelle uz D ak 40% POPUSTA! 100% sigurna kupovina preko interneta! 100 % garancija! U sluD aju nezadovoljstva proizvod moE>ete vratiti u roku od 15 dana. Dostava PouzeDem. Vrši se putem sluE>be Post Express. Sigurna kupovina! PoruD enu robu plaDate tek po preuzimanju svog paketa. Kupovina na rate! OtplaDivanje na rate putem administrativne zabrane za lakšu kupovinu. Ovu elektronsku poštu primate, ukoliko ste svojevoljno ostavili svoju e-mail adresu na nekom od sajtova Top Shop-a, uD estvovali u našoj poklon igri ili nagradnom kvizu ili se prijavili za e-D asopis Top Shop-a ili nekog od nasih brendova. Ponude date u ovom e-mailu vaE>e iskljuD ivo za porudE>bine upuDene putem Interneta ili broja telefona 021 489 26 60. Ukoliko ne E>elite više da primate naše elektronske poruke, za odjavljivanje sa naše e-mailing liste, kliknite ovde. Studio Moderna d.o.o., Bulevar vojvode Stepe 30, 21000 Novi Sad, Tel: 021 489 26 60, Fax: 021 489 29 08, E-mail: i...@news.e-topshop.tv [IMAGE]If you would no longer like to receive our emails please unsubscribe by clicking here.
Re: em(4) testers required
re
i was testing the diff on our shitz here and it works.
dual-port Intel PRO/1000 on pci-express and on-boards.
added a couple more checks where it seemed to make sense.
those ports having problems before seem to work now.
cu
--
paranoic mickey (my employers have changed but, the name has remained)
--- src/sys/dev/pci/if_em_hw.c Tue Oct 20 15:37:12 2009
+++ src/sys/dev/pci/if_em_hw.c Tue Jul 13 12:58:34 2010
@@ -499,20 +499,21 @@ em_set_mac_type(struct em_hw *hw)
}
switch (hw->mac_type) {
case em_ich8lan:
case em_ich9lan:
case em_ich10lan:
hw->swfwhw_semaphore_present = TRUE;
hw->asf_firmware_present = TRUE;
break;
case em_80003es2lan:
+case em_82575:
hw->swfw_sync_present = TRUE;
/* FALLTHROUGH */
case em_82571:
case em_82572:
case em_82573:
case em_82574:
hw->eeprom_semaphore_present = TRUE;
/* FALLTHROUGH */
case em_82541:
case em_82547:
@@ -846,20 +847,21 @@ em_initialize_hardware_bits(struct em_hw *hw)
if (reg_tctl & E1000_TCTL_MULR)
reg_tarc1 &= ~0x1000; /* Clear bit 28 if MULR is 1b
*/
else
reg_tarc1 |= 0x1000;/* Set bit 28 if MULR is 0b */
E1000_WRITE_REG(hw, TARC1, reg_tarc1);
break;
case em_82573:
case em_82574:
+case em_82575:
reg_ctrl_ext = E1000_READ_REG(hw, CTRL_EXT);
reg_ctrl = E1000_READ_REG(hw, CTRL);
reg_ctrl_ext &= ~0x0080;/* Clear bit 23 */
reg_ctrl_ext |= 0x0040; /* Set bit 22 */
reg_ctrl &= ~0x2000;/* Clear bit 29 */
E1000_WRITE_REG(hw, CTRL_EXT, reg_ctrl_ext);
E1000_WRITE_REG(hw, CTRL, reg_ctrl);
break;
@@ -3593,21 +3595,21 @@ em_swfw_sync_release(struct em_hw *hw, uint16_t mask)
int32_t
em_read_phy_reg(struct em_hw *hw,
uint32_t reg_addr,
uint16_t *phy_data)
{
uint32_t ret_val;
uint16_t swfw;
DEBUGFUNC("em_read_phy_reg");
-if ((hw->mac_type == em_80003es2lan) &&
+if ((hw->mac_type == em_80003es2lan || hw->mac_type == em_82575) &&
(E1000_READ_REG(hw, STATUS) & E1000_STATUS_FUNC_1)) {
swfw = E1000_SWFW_PHY1_SM;
} else {
swfw = E1000_SWFW_PHY0_SM;
}
if (em_swfw_sync_acquire(hw, swfw))
return -E1000_ERR_SWFW_SYNC;
if ((hw->phy_type == em_phy_igp ||
hw->phy_type == em_phy_igp_3 ||
@@ -3738,21 +3740,21 @@ em_read_phy_reg_ex(struct em_hw *hw, uint32_t reg_addr
**/
int32_t
em_write_phy_reg(struct em_hw *hw, uint32_t reg_addr,
uint16_t phy_data)
{
uint32_t ret_val;
uint16_t swfw;
DEBUGFUNC("em_write_phy_reg");
-if ((hw->mac_type == em_80003es2lan) &&
+if ((hw->mac_type == em_80003es2lan || hw->mac_type == em_82575) &&
(E1000_READ_REG(hw, STATUS) & E1000_STATUS_FUNC_1)) {
swfw = E1000_SWFW_PHY1_SM;
} else {
swfw = E1000_SWFW_PHY0_SM;
}
if (em_swfw_sync_acquire(hw, swfw))
return -E1000_ERR_SWFW_SYNC;
if ((hw->phy_type == em_phy_igp ||
hw->phy_type == em_phy_igp_3 ||
@@ -3864,21 +3866,21 @@ em_write_phy_reg_ex(struct em_hw *hw, uint32_t reg_add
STATIC int32_t
em_read_kmrn_reg(struct em_hw *hw,
uint32_t reg_addr,
uint16_t *data)
{
uint32_t reg_val;
uint16_t swfw;
DEBUGFUNC("em_read_kmrn_reg");
-if ((hw->mac_type == em_80003es2lan) &&
+if ((hw->mac_type == em_80003es2lan || hw->mac_type == em_82575) &&
(E1000_READ_REG(hw, STATUS) & E1000_STATUS_FUNC_1)) {
swfw = E1000_SWFW_PHY1_SM;
} else {
swfw = E1000_SWFW_PHY0_SM;
}
if (em_swfw_sync_acquire(hw, swfw))
return -E1000_ERR_SWFW_SYNC;
/* Write register address */
reg_val = ((reg_addr << E1000_KUMCTRLSTA_OFFSET_SHIFT) &
@@ -3939,21 +3941,21 @@ em_phy_hw_reset(struct em_hw *hw)
/* In the case of the phy reset being blocked, it's not an error, we
* simply return success without performing the reset. */
ret_val = em_check_phy_reset_block(hw);
if (ret_val)
return E1000_SUCCESS;
DEBUGOUT("Resetting Phy...\n");
if (hw->mac_type > em_82543) {
-if ((hw->mac_type == em_80003es2lan) &&
+if ((hw->mac_type == em_80003es2lan || hw->mac_type == em_82575) &&
(E1000_READ_REG(hw, STATUS) & E1000_STATUS_FUNC_1)) {
swfw = E1000_SWFW_PHY1_SM;
} else {
swfw = E1000_SWFW_PHY0_SM;
}
if (em_swfw_sync_acquire(hw, swfw)) {
DEBUGOUT("Unable to acquire swfw sync\n");
return -E1000_ERR_SWFW_SYNC;
utmpx for OpenBSD
Hi folks, I sent an email to tedu@ the other day, but I thought it may be better to just send it to tech@ to see whether we can sort this out. After I implemented utmpx for FreeBSD, I realized OpenBSD is the only commonly used maintained UNIX-like operating system which doesn't implement: - posix_openpt(), grantpt(), unlockpt() and ptsname(), and - utmpx. This causes a real burden on people trying to write network login services, terminal emulators, terminal multiplexers, etc. It would be so much easier if authors of (new) pieces of software can just use these interfaces with confidence and expect things to work properly. So as a proof of concept I am working on a patchset, where I took my utmpx implementation that I wrote for FreeBSD and added it to OpenBSD's libc. It also contains patches for various utilities in the base system to let it use utmpx. It is by no means complete, but should give you at least an idea of what it's going to look like. Below is a link to the latest version: http://80386.nl/pub/openbsd-utmpx.txt Ignoring the build failures, it is already possible to ssh into the system and send messages to each other using wall/write. I have two questions: - Is there any interest in getting utmpx support integrated into OpenBSD? - If so, is there a developer willing to work with me to get my patchset smashed into shape and eventually committed? Greetings, -- Ed Schouten [demime 1.01d removed an attachment of type application/pgp-signature]
Re: ioprbs(4) patch needs testing
On Tue, Jul 13, 2010 at 08:32:18AM -0400, Kenneth R Westerback wrote:
> On Tue, Jul 13, 2010 at 01:36:34PM +0200, Mark Kettenis wrote:
> > > Date: Tue, 13 Jul 2010 12:45:08 +0200
> > > From: Claudio Jeker
> > >
> > > On Sun, Jun 27, 2010 at 09:48:03AM -0700, Matthew Dempsky wrote:
> > > > Anyone still using ioprbs(4)? If so, please test the diff below and
> > > > report back to me.
> > > >
> > >
> > > No bad effects seen after light testing on a ADAPTEC 3200S that I found in
> > > a dark corner of the basement. Dmesg below.
> > >
> > > iop0 at pci0 dev 11 function 1 "DPT SmartRAID (I2O)" rev 0x02: : > > 3200S>, irq 11
> >
> > Noticed that iop(4) screws up the dmesg printing. Diff below fixes it.
> >
> > ok?
>
> ok krw@
>
OK claudio@
new line is now:
iop0 at pci0 dev 11 function 1 "DPT SmartRAID (I2O)" rev 0x02: ,
irq 11
> Ken
>
> >
> >
> > Index: iop_pci.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/iop_pci.c,v
> > retrieving revision 1.7
> > diff -u -p -r1.7 iop_pci.c
> > --- iop_pci.c 8 Apr 2010 00:23:53 - 1.7
> > +++ iop_pci.c 13 Jul 2010 11:34:42 -
> > @@ -98,7 +98,6 @@ iop_pci_attach(struct device *parent, st
> > sc = (struct iop_softc *)self;
> > pa = (struct pci_attach_args *)aux;
> > pc = pa->pa_pc;
> > - printf(": ");
> >
> > /*
> > * The kernel always uses the first memory mapping to communicate
> > @@ -110,14 +109,14 @@ iop_pci_attach(struct device *parent, st
> > break;
> > }
> > if (i == PCI_MAPREG_END) {
> > - printf("can't find mapping\n");
> > + printf(": can't find mapping\n");
> > return;
> > }
> >
> > /* Map the register window. */
> > if (pci_mapreg_map(pa, i, PCI_MAPREG_TYPE_MEM, 0, &sc->sc_iot,
> > &sc->sc_ioh, NULL, NULL, 0x4)) {
> > - printf("%s: can't map register window\n", sc->sc_dv.dv_xname);
> > + printf(": can't map register window\n");
> > return;
> > }
> >
> > @@ -127,14 +126,14 @@ iop_pci_attach(struct device *parent, st
> >
> > /* Map and establish the interrupt. XXX IPL_BIO. */
> > if (pci_intr_map(pa, &ih)) {
> > - printf("can't map interrupt\n");
> > + printf(": can't map interrupt\n");
> > return;
> > }
> > intrstr = pci_intr_string(pc, ih);
> > sc->sc_ih = pci_intr_establish(pc, ih, IPL_BIO, iop_intr, sc,
> > sc->sc_dv.dv_xname);
> > if (sc->sc_ih == NULL) {
> > - printf("can't establish interrupt");
> > + printf(": can't establish interrupt");
> > if (intrstr != NULL)
> > printf(" at %s", intrstr);
> > printf("\n");
>
--
:wq Claudio
Re: ioprbs(4) patch needs testing
On Tue, Jul 13, 2010 at 01:36:34PM +0200, Mark Kettenis wrote:
> > Date: Tue, 13 Jul 2010 12:45:08 +0200
> > From: Claudio Jeker
> >
> > On Sun, Jun 27, 2010 at 09:48:03AM -0700, Matthew Dempsky wrote:
> > > Anyone still using ioprbs(4)? If so, please test the diff below and
> > > report back to me.
> > >
> >
> > No bad effects seen after light testing on a ADAPTEC 3200S that I found in
> > a dark corner of the basement. Dmesg below.
> >
> > iop0 at pci0 dev 11 function 1 "DPT SmartRAID (I2O)" rev 0x02: : > 3200S>, irq 11
>
> Noticed that iop(4) screws up the dmesg printing. Diff below fixes it.
>
> ok?
ok krw@
Ken
>
>
> Index: iop_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/iop_pci.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 iop_pci.c
> --- iop_pci.c 8 Apr 2010 00:23:53 - 1.7
> +++ iop_pci.c 13 Jul 2010 11:34:42 -
> @@ -98,7 +98,6 @@ iop_pci_attach(struct device *parent, st
> sc = (struct iop_softc *)self;
> pa = (struct pci_attach_args *)aux;
> pc = pa->pa_pc;
> - printf(": ");
>
> /*
>* The kernel always uses the first memory mapping to communicate
> @@ -110,14 +109,14 @@ iop_pci_attach(struct device *parent, st
> break;
> }
> if (i == PCI_MAPREG_END) {
> - printf("can't find mapping\n");
> + printf(": can't find mapping\n");
> return;
> }
>
> /* Map the register window. */
> if (pci_mapreg_map(pa, i, PCI_MAPREG_TYPE_MEM, 0, &sc->sc_iot,
> &sc->sc_ioh, NULL, NULL, 0x4)) {
> - printf("%s: can't map register window\n", sc->sc_dv.dv_xname);
> + printf(": can't map register window\n");
> return;
> }
>
> @@ -127,14 +126,14 @@ iop_pci_attach(struct device *parent, st
>
> /* Map and establish the interrupt. XXX IPL_BIO. */
> if (pci_intr_map(pa, &ih)) {
> - printf("can't map interrupt\n");
> + printf(": can't map interrupt\n");
> return;
> }
> intrstr = pci_intr_string(pc, ih);
> sc->sc_ih = pci_intr_establish(pc, ih, IPL_BIO, iop_intr, sc,
> sc->sc_dv.dv_xname);
> if (sc->sc_ih == NULL) {
> - printf("can't establish interrupt");
> + printf(": can't establish interrupt");
> if (intrstr != NULL)
> printf(" at %s", intrstr);
> printf("\n");
Re: ioprbs(4) patch needs testing
> Date: Tue, 13 Jul 2010 12:45:08 +0200
> From: Claudio Jeker
>
> On Sun, Jun 27, 2010 at 09:48:03AM -0700, Matthew Dempsky wrote:
> > Anyone still using ioprbs(4)? If so, please test the diff below and
> > report back to me.
> >
>
> No bad effects seen after light testing on a ADAPTEC 3200S that I found in
> a dark corner of the basement. Dmesg below.
>
> iop0 at pci0 dev 11 function 1 "DPT SmartRAID (I2O)" rev 0x02: : 3200S>, irq 11
Noticed that iop(4) screws up the dmesg printing. Diff below fixes it.
ok?
Index: iop_pci.c
===
RCS file: /cvs/src/sys/dev/pci/iop_pci.c,v
retrieving revision 1.7
diff -u -p -r1.7 iop_pci.c
--- iop_pci.c 8 Apr 2010 00:23:53 - 1.7
+++ iop_pci.c 13 Jul 2010 11:34:42 -
@@ -98,7 +98,6 @@ iop_pci_attach(struct device *parent, st
sc = (struct iop_softc *)self;
pa = (struct pci_attach_args *)aux;
pc = pa->pa_pc;
- printf(": ");
/*
* The kernel always uses the first memory mapping to communicate
@@ -110,14 +109,14 @@ iop_pci_attach(struct device *parent, st
break;
}
if (i == PCI_MAPREG_END) {
- printf("can't find mapping\n");
+ printf(": can't find mapping\n");
return;
}
/* Map the register window. */
if (pci_mapreg_map(pa, i, PCI_MAPREG_TYPE_MEM, 0, &sc->sc_iot,
&sc->sc_ioh, NULL, NULL, 0x4)) {
- printf("%s: can't map register window\n", sc->sc_dv.dv_xname);
+ printf(": can't map register window\n");
return;
}
@@ -127,14 +126,14 @@ iop_pci_attach(struct device *parent, st
/* Map and establish the interrupt. XXX IPL_BIO. */
if (pci_intr_map(pa, &ih)) {
- printf("can't map interrupt\n");
+ printf(": can't map interrupt\n");
return;
}
intrstr = pci_intr_string(pc, ih);
sc->sc_ih = pci_intr_establish(pc, ih, IPL_BIO, iop_intr, sc,
sc->sc_dv.dv_xname);
if (sc->sc_ih == NULL) {
- printf("can't establish interrupt");
+ printf(": can't establish interrupt");
if (intrstr != NULL)
printf(" at %s", intrstr);
printf("\n");
Re: ioprbs(4) patch needs testing
On Sun, Jun 27, 2010 at 09:48:03AM -0700, Matthew Dempsky wrote:
> Anyone still using ioprbs(4)? If so, please test the diff below and
> report back to me.
>
No bad effects seen after light testing on a ADAPTEC 3200S that I found in
a dark corner of the basement. Dmesg below.
--
:wq Claudio
OpenBSD 4.7-current (GENERIC) #0: Tue Jul 13 12:50:08 CEST 2010
r...@foo.networx.ch:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class) 804 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE
real mem = 536358912 (511MB)
avail mem = 517607424 (493MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/12/01, BIOS32 rev. 0 @ 0xf0ad0, SMBIOS
rev. 2.3 @ 0xf2970 (46 entries)
bios0: vendor Award Software, Inc. version "ASUS CUV4X-E ACPI BIOS Revision
1003" date 06/12/2001
bios0: ASUSTeK Computer INC. CUV4X-E
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf/0x1322
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf1280/160 (8 entries)
pcibios0: PCI Interrupt Router at 000:04:0 ("VIA VT82C586 ISA" rev 0x00)
pcibios0: PCI bus #2 is the last bus
bios0: ROM list: 0xc/0xc000 0xcc000/0x1800 0xd/0x5000
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "VIA VT82C691 PCI" rev 0xc4
viaagp0 at pchb0: v2
agp0 at viaagp0: aperture at 0xfc00, size 0x1000
ppb0 at pci0 dev 1 function 0 "VIA VT82C598 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Rage 128 Pro" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 4 function 0 "VIA VT82C686 ISA" rev 0x40
pciide0 at pci0 dev 4 function 1 "VIA VT82C571 IDE" rev 0x06: ATA100, channel 0
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 ignored (disabled)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
viaenv0 at pci0 dev 4 function 4 "VIA VT82C686 SMBus" rev 0x40: HWM disabled:
24-bit timer at 3579545Hz
fxp0 at pci0 dev 8 function 0 "Intel 8255x" rev 0x0c, i82550: irq 10, address
00:02:b3:27:f1:67
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
ppb1 at pci0 dev 11 function 0 "DPT PCI-PCI" rev 0x02
pci2 at ppb1 bus 2
iop0 at pci0 dev 11 function 1 "DPT SmartRAID (I2O)" rev 0x02: : , irq 11
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
biomask fb65 netmask ff65 ttymask
mtrr: Pentium Pro MTRR support
iop0: configuring...
ioprbs0 at iop0 tid 518: direct access, fixed
scsibus1 at ioprbs0: 1 targets
sd0 at scsibus1 targ 0 lun 0: SCSI2 0/direct fixed
sd0: 17501MB, 512 bytes/sec, 35843653 sec total
ioprbs1 at iop0 tid 517: direct access, fixed
scsibus2 at ioprbs1: 1 targets
sd1 at scsibus2 targ 0 lun 0: SCSI2 0/direct fixed
sd1: 34715MB, 512 bytes/sec, 71096623 sec total
ioprbs2 at iop0 tid 521: direct access, fixed
scsibus3 at ioprbs2: 1 targets
sd2 at scsibus3 targ 0 lun 0: SCSI2 0/direct fixed
sd2: 8678MB, 512 bytes/sec, 17772544 sec total
iopsp0 at iop0 tid 8: SCSI port
scsibus4 at iopsp0: 16 targets, initiator 7
iopsp1 at iop0 tid 9: SCSI port
scsibus5 at iopsp1: 16 targets, initiator 7
iopsp2 at iop0 tid 10: SCSI port
scsibus6 at iopsp2: 16 targets, initiator 7
iopsp3 at iop0 tid 11: SCSI port
scsibus7 at iopsp3: 16 targets, initiator 7
vscsi0 at root
scsibus8 at vscsi0: 256 targets
softraid0 at root
root on sd0a swap on sd0b dump on sd0b
Re: cvsinfo
On Mon, Jul 12, 2010 at 09:32:30PM -0400, Ted Unangst wrote: > To help investigate some changes recently, I wrote a tool that will > extract (reverse) patches from cvs. I was telling a coworker about this > today, and he said it was a lot like cvsps. Maybe it is, but cvsps chokes > big time trying to import our tree. Running it just in sys/dev for > testing printed billions of lines of nonsense warnings without making > much progress. This is because cvsps interprets the rcs information in a log message of midway.c wrong, manually fixing it works around the problem.
Re: cvsinfo
On Mon, Jul 12, 2010 at 09:32:30PM -0400, Ted Unangst wrote: > To help investigate some changes recently, I wrote a tool that will > extract (reverse) patches from cvs. I was telling a coworker about this > today, and he said it was a lot like cvsps. Maybe it is, but cvsps chokes > big time trying to import our tree. Running it just in sys/dev for > testing printed billions of lines of nonsense warnings without making > much progress. > > Anyway, on to the good stuff. My tool is called cvsinfo. Let's say I'm > looking for a change I know deraadt made to acpi. Something about the > workq. So I run "cvsinfo search workq" and it prints out some helpful > info. I could also have run "cvsinfo search author:deraadt path:acpi" and > found the same result. Whatever you remember or suspect about the change > in question. Now I run this get the patch to undo that change "cvsinfo > unpatch dev/acpi/acpi.c 1.171". Apply that, ready to test. > > It's written in Lua and there's a few moving parts you'll need to collect > before you can make use of it, so I made one of those web things. > > The DBs are also interesting for stat mining, like how many developers > committed to src this year (94) or how many commits they made (80177). > > http://www.tedunangst.com/cvsinfo.html [t...@anja ~]$ sudo pkg_add cvsinfo Password: Can't find cvsinfo Port please! :-) Looks neat though.
