Menu
▾
▴
projectudi-code — Programmer discussion of reference implementation
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(12) |
Mar
(24) |
Apr
(12) |
May
(13) |
Jun
(67) |
Jul
(9) |
Aug
(11) |
Sep
(13) |
Oct
(7) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(56) |
Feb
(58) |
Mar
(9) |
Apr
(16) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Burkhard D. <ma...@bu...> - 2002-03-07 16:07:06
|
Folks, we have a conference call today at 12:30 pm EST. Unisys is hosting. The info is: toll free outside number within US and Canada: 1-877-302-3764 international callers use: 215-986-7139 Passcode: 3354108 Burk. -- Burkhard Daniel * ma...@bu... * http://www.burkhard.net Our lives are poems sung against the wind, with nothing but our voices to make a difference. |
|
From: Van M. K. <kev...@un...> - 2002-03-04 22:17:40
|
Bob is going to host next month. This month, Unisys will be hosting: toll free outside number within US and Canada: 1-877-302-3764 international callers use: 215-986-7139 Passcode: 3354108 Kevin Van Maren |
|
From: Barned, R. <rob...@lm...> - 2002-03-04 16:16:03
|
I can host the call. Bob > -----Original Message----- > From: udi...@pr... > [mailto:udi...@pr...]On Behalf Of Burkhard Daniel > Sent: Monday, March 04, 2002 6:59 AM > To: UDI Architecture Discussions; UDI Programming Discussions > Subject: [UDI-Tech] Conference Call This Week > > > Hi gang, > > this coming thursday is the 1st thursday in the month of march, so we > should be having a conference call. > > However, we do not have a host for this month at this time. > > If we are to have the call, we need somebody to host it. > > Any volunteers? > > Burk. > -- > Burkhard Daniel > Software Technologies Group, Inc. > bu...@st... * http://www.stg.com > fon: +49-179-5319489 fax: +49-179-5319489 > > > _______________________________________________ > UDI-Tech mailing list > UDI...@pr... > http://lists.projectudi.org/mailman/listinfo/udi-tech > |
|
From: Van M. K. <kev...@un...> - 2002-03-04 15:22:11
|
I'll take march -- I'll send out the conference call info later today/tomorrow. Kevin -----Original Message----- From: Burkhard Daniel To: UDI Architecture Discussions; UDI Programming Discussions Sent: 3/4/02 6:58 AM Subject: [UDI-Tech] Conference Call This Week Hi gang, this coming thursday is the 1st thursday in the month of march, so we should be having a conference call. However, we do not have a host for this month at this time. If we are to have the call, we need somebody to host it. Any volunteers? Burk. -- |
|
From: Burkhard D. <bu...@st...> - 2002-03-04 12:00:02
|
Hi gang, this coming thursday is the 1st thursday in the month of march, so we should be having a conference call. However, we do not have a host for this month at this time. If we are to have the call, we need somebody to host it. Any volunteers? Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: Quick, K. <Kev...@Su...> - 2002-02-21 15:15:47
|
UDI Teleconference Minutes
07 February 2002
Attendees:
Bob Barned Lockheed-Martin ba...@sy...
Kurt Gollhardt Caldera ku...@ce...
Robert Lipe Caldera ro...@ca...
Kevin Quick Surgient
kev...@su...
* ATOMIC_INT_READ is still needed because of the potential need for
specific instructions to do this for atomic integers.
- Change name to ATOMIC_INT_READ_STALE? No, we have to figure that
people have some fundamental knowledge of how to use ATOMIC_INT
stuff if they are using it.
- Still need to review remaining code
* Bus bridge interrupt patch checked in to handle state issues.
- Symptom was that the int PIO shutdown (entry point 2) could be
pending when more control blocks arrived, but int PIO startup
(entry point x) needs to wait until the shutdown completes to
restart things.
* USBDI Documents
- Aaron Biver is amenable to transferring responsibility for USB
Metalanguage documents to Project UDI.
- Ultimately a representative from the USB Implementer's Forum will
need to approve this since that's who holds the copyright on the
current version.
- Aaron is to get back to Project UDI regarding contact with this
representative.
* Dual mail archives are a bit of a drag. The SourceForge version
doesn't seem to archive attachments, but neither site has full
history and neither site is actually directly owned by ProjectUDI.
- For now we'll maintain dual archiving.
* UDI Marketing mail archive on projectudi.org is private and
requiring a password. This is supposed to be a public archive and
will be changed.
-------------------------------
This e-mail is for the sole use of the intended recipient and may
contain confidential and privileged information. Any unauthorized
review, use or disclosure is strictly prohibited. If you are not the
intended recipient of this e-mail, please notify sender and delete
all copies immediately.
|
|
From: Burkhard D. <bu...@st...> - 2002-02-21 14:57:15
|
While I haven't sent out a heads-up this Monday that we have a conference call scheduled for today, we nevertheless do. The info is: As usual, the call will be at 9:30am PST/10:30am MT/11:30am CST/12:30pm EST/5:30pm GMT/6:30pm CET. Call in number: 800-280-9862 and 913-312-4163 (int'l) Pass code: 223091. Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: <mr...@ni...> - 2002-02-14 16:44:11
|
> >No APIC support? Yes, but I map the PCI interrupts to the same IRQs set up by the BIOS to keep it simple and compatible with the non-IOAPIC (uniprocessor) module. If I should need 20 interrupt vectors someday, I can change it. > >Loss of carrier is your friend. Yanking the cable out should get you >control of the system again. > >I'd wanted to change the loop in whipit to drive from a timer or somehow >govern the amount of work it does, but never got around to it. It serves its purpose as is. Mike -----------------------------7d2dd149901c6 Content-Disposition: form-data; name="send_att1"; filename="" Content-Type: application/octet-stream -----------------------------7d2dd149901c6 |
|
From: Robert L. <ro...@ca...> - 2002-02-14 16:05:58
|
> >> Seems the osinfo struct passed to _udi_register_isr got ka-reamed, > > Even stupider than that. I have an 16-entry array, one entry per IRQ. Well, No APIC support? > Help!! Jane!! Stop this crazy thing!! Jane!! > My network is saturated!! Di control-C does not respond!! Loss of carrier is your friend. Yanking the cable out should get you control of the system again. I'd wanted to change the loop in whipit to drive from a timer or somehow govern the amount of work it does, but never got around to it. RJL |
|
From: <mr...@ni...> - 2002-02-14 13:58:52
|
> >> Seems the osinfo struct passed to _udi_register_isr got ka-reamed, > Even stupider than that. I have an 16-entry array, one entry per IRQ. Well, the index into the array was getting fu'd, so naturally it wasn't getting the right answer anymore. This was just in the shared interrupt routine where it loops to check for more isr's to process, the exclusive one doesn't loop. Help!! Jane!! Stop this crazy thing!! Jane!! My network is saturated!! Di control-C does not respond!! Mike -----------------------------19500497591457381033509010500 Content-Disposition: form-data; name="send_att1"; filename="" -----------------------------19500497591457381033509010500 |
|
From: Robert L. <ro...@ca...> - 2002-02-14 01:42:29
|
> I whipped it!! Yippy!! So you're transmitting packets? Excellent. Congrats! > It crashed after a couple seconds though. Wanna know the number of OSes where I've brought UDI up and watched it survive the "last man standing" battle of packets on the first boot? Zero. :-) > Seems the osinfo struct passed to _udi_register_isr got ka-reamed, While it probably means relatively little to you, the context pointer that gets passed to uw/udi_osdep.c::_udi_register_isr survives. So I don't think we have a flagrant memory overwrite in there or anything. > so I'll turn the hardware breakpoint on it and see what happens to Those probably won't trigger if it's DMA scribbling on them, but it's a good starting place. > it (and hope it's that simple to fix). I "assume" this struct is > supposed to stay around until the driver is shut down. It's completely opaque to the common bridge mapper. You're passed a pointer to a struct you define to a functino you define on ISR registration and passed that same pointer back during ISR deregistration. As a practical matter, OSes use this to "connect" the attach/detach operations, and they typically DO hang around for the duration of the bind. RJL |
|
From: Quick, K. <Kev...@Su...> - 2002-02-13 16:40:07
|
Very Cool!! Keep us updated, we like this kind of news! -Kevin > -----Original Message----- > From: Mike Rieker [mailto:mr...@ni...] > Sent: Wednesday, February 13, 2002 10:16 AM > To: projectudi, code > Subject: [Projectudi-code] ozone port > > > I whipped it!! Yippy!! > > It crashed after a couple seconds though. Seems the osinfo > struct passed to > _udi_register_isr got ka-reamed, so I'll turn the hardware > breakpoint on it > and see what happens to it (and hope it's that simple to > fix). I "assume" > this struct is supposed to stay around until the driver is shut down. > > Mike > > > > _______________________________________________ > Projectudi-code mailing list > Pro...@li... > https://lists.sourceforge.net/lists/listinfo/projectudi-code > ------------------------------- This e-mail is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use or disclosure is strictly prohibited. If you are not the intended recipient of this e-mail, please notify sender and delete all copies immediately. ------------------------------- This e-mail is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use or disclosure is strictly prohibited. If you are not the intended recipient of this e-mail, please notify sender and delete all copies immediately. |
|
From: Mike R. <mr...@ni...> - 2002-02-13 16:15:34
|
I whipped it!! Yippy!! It crashed after a couple seconds though. Seems the osinfo struct passed to _udi_register_isr got ka-reamed, so I'll turn the hardware breakpoint on it and see what happens to it (and hope it's that simple to fix). I "assume" this struct is supposed to stay around until the driver is shut down. Mike |
|
From: Robert L. <ro...@ca...> - 2002-02-12 06:57:18
|
We know that reading a dictionary can be a hard way to learn a language. if you just don't like the spec approach to learning, you might find some of the tutorials handy. Becuase of the stupid frames, I can't get a direct link to it, but docsrv.caldera.com:80 hardware and driver dev->UDI Driver Writer's guide is a nice overview. I can't say it's had a huge number of eyeballs on it, but it should resemble reality. (Yes, I know it's in a stupid place on our web site, but I was told to quit complaining about it...) We also have some training tapes made of a couple days worth of presentations that Kurt, I, and a few others did. I'm not really sure where to find those, but if you're interested, I'll ask around. RJL |
|
From: Kurt G. <ku...@ce...> - 2002-02-09 01:59:08
|
Burkhard Daniel wrote: > Unless your driver resets it, it will. A driver can reset the region > context in a control block to whatever it wants to, and whenever that > control block is passed to a region, that context will be preserved. To clarify: When a CB comes into a region, its context pointer is set to the current channel context for the incoming channel endpoint through which it was delivered (as of the moment of invocation of the channel op function within the new region). While the CB is in the region, the driver can change its context pointer any time the CB is "idle" (not involved in an active environment service call), and this value will be preserved until the CB leaves the region. The channel context is initially set to any pre-allocated channel context memory requested by the driver via chan_context_size in its udi_ops_init structures (not available for mgmt ops) or else the pre-allocated region data. The driver may change the channel context at any time, using udi_channel_set_context. -- Kurt Gollhardt, CerTek Software Designs, Inc. (www.certek-software.com) 877-7CERTEK (877-723-7835) in...@ce... |
|
From: Burkhard D. <bu...@st...> - 2002-02-09 00:13:23
|
Mike Rieker wrote: > Regarding xxx_usage_ind, for the first call, does UDI_GCB(cb)->context > always point to the primary region's driver-specific data struct? If not, Yes it does. It points to the region context, the size of which you told the environment in your udi_primary_init. This is also known as "rdata" (region data). > what? For all subsequent calls, does it still always point to primary > region's driver-specific data? Unless your driver resets it, it will. A driver can reset the region context in a control block to whatever it wants to, and whenever that control block is passed to a region, that context will be preserved. Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: Mike R. <mr...@ni...> - 2002-02-08 23:53:31
|
I'll get flamed for this... Question to answer in the spec sometime: Regarding xxx_usage_ind, for the first call, does UDI_GCB(cb)->context always point to the primary region's driver-specific data struct? If not, what? For all subsequent calls, does it still always point to primary region's driver-specific data? Should I come up with more such stupid questions to answer in the doc? This is the first routine in shrkudi.c. Only 249?? to go! Mike |
|
From: Kurt G. <ku...@ce...> - 2002-02-07 14:16:32
|
mr...@ni... wrote: >I am trying to get whipit to work with the shrkudi driver. > >So apparently, I had to change the 'device 3 1' in the whipit udiprops.txt >to 'device 3 2' to get it to match up, after tracking it all down to routine >_udi_MA_match_devline. > >So that '2' in whipit/udiprops.txt means to match it with the 'meta 2 udi_nic' >line in that udiprops.txt file, to mean that this driver can be a child to >'udi_nic' devices, ie, it is on the child side of an udi_nic channel? > > device 3 2 > meta 2 udi_nic > >I noticed that the shrkudi/udiprops.txt file has this: > > device 5 3 ... > device 6 3 ... > meta 3 udi_bridge > >which 'must' mean the shrkudi driver sits on the child side of an udi_bridge >channel? > You're right on all of the above. Not sure how it worked for other folks with the incorrect device line. Maybe the MA was made more strict since the last time someone used whipit. -- Kurt Gollhardt, CerTek Software Designs, Inc. (www.certek-software.com) 877-7CERTEK (877-723-7835) in...@ce... |
|
From: Burkhard D. <bu...@st...> - 2002-02-07 13:22:00
|
As forewarned in my mail on Monday, we will be having a conference call today. The info is: As usual, the call will be at 9:30am PST/10:30am MT/11:30am CST/12:30pm EST/5:30pm GMT/6:30pm CET. Call in number: 800-280-9862 and 913-312-4163 (int'l) Pass code: 223091. Have fun, Burk. P.S. I can't make today's call. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: <mr...@ni...> - 2002-02-07 05:17:42
|
I am trying to get whipit to work with the shrkudi driver. So apparently, I had to change the 'device 3 1' in the whipit udiprops.txt to 'device 3 2' to get it to match up, after tracking it all down to routine _udi_MA_match_devline. So that '2' in whipit/udiprops.txt means to match it with the 'meta 2 udi_nic' line in that udiprops.txt file, to mean that this driver can be a child to 'udi_nic' devices, ie, it is on the child side of an udi_nic channel? device 3 2 meta 2 udi_nic I noticed that the shrkudi/udiprops.txt file has this: device 5 3 ... device 6 3 ... meta 3 udi_bridge which 'must' mean the shrkudi driver sits on the child side of an udi_bridge channel? It still hasn't whipped my net yet because I think the shrkudi driver is trying to put my board in 100MHz mode, but my network is only 10MHz. I think the SMC board is a different configuration than what the shrkudi driver was made for. But at least I can tell they are talking as I get a bunch of messages on my screen. Mike -----------------------------18307754454916309021714243462 Content-Disposition: form-data; name="send_att1"; filename="" -----------------------------18307754454916309021714243462 |
|
From: James H. - S. UK - S. E. <jh1...@sr...> - 2002-02-06 23:43:24
|
Hi Mike, The routines that should be called are the xxx_usage_ind() entrypoints in the shrkudi and whipit drivers. To see if the MA is actually binding the drivers together you will need to i) build a debug environment using udibuild -D from env/ozone (or wherever) before you udimkpkg and then load your environment and then ii) [or maybe it should be iv)] you'll need to set the environment global _udi_debug_level to a reasonable value (3 is pretty good w/o being too verbose). Once you've done this you should load whipit and shrkudi and see what output gets produced. There should be a load of messages of the form T.xxxx-udi<ENV Info>: and some of these should have _udi_MA_install_driver(shrkudi) followed by Load Driver shrkudi and a whole slew of messages containing something like: shrkudi parent meta[1] = [udi_bridge] If you aren't seeing anything like this then the backend OS-dependent MA code may not be loading the drivers quite as expected. Sorry to ramble but I hope this points out a further line of investigation. Cheers, James |
|
From: <mr...@ni...> - 2002-02-06 17:43:26
|
So I load whipit and it does nothing. I put a print statement at the beginning of each whipit routine and none of them get called. I noticed the ethernet driver is doing something as it starts farbling the light on the hub about 3 times a second. This is without whipit. So does anyone know what routine in whipit should get called by the environment first? And what in the ethernet driver causes it to be called? I tried loading whipit before and after the ethernet driver, didn't make any apparent difference. It's probably not initializing the ethernet board correctly or something, but in 5000+ lines of code for an ethernet driver, I get lost. So if someone could tell me where it tells UDI that it is ready to accept requests, maybe I can somehow trace through it. Thanks, Mike -----------------------------490142877744405302126541206 Content-Disposition: form-data; name="send_att1"; filename="" -----------------------------490142877744405302126541206 |
|
From: Robert L. <ro...@ca...> - 2002-02-05 23:16:29
|
They're different things. One might use an atomic operator to implement a semaphore, but the oppostite seems somewhere between strange and impossible. After the big patch I just checked in, any environment that has _POSIX_SEMAPHORES available is broken. Maybe I'm being dense, but I just don't see how to get the semantics we want from a sema. Could someone (esp. the original author, if still with us) comment on the appropriateness of the definitions of osdep_atomic_int_blah that use the sem_trywait and semd_init stuff? Is this stuff really right and just over my head? RJL |
|
From: James H. <jam...@Su...> - 2002-02-05 17:57:04
|
"Quick, Kevin" wrote: [ useful stuff snipped out ] > Also note that most of the MA is common code, so you shouldn't > have any active porting work to do here. In your situation, it > probably couldn't find an NSR mapper in the system and so that's > where the whole process stopped. Just load a functional NSR mapper > and watch the fun begin (yes, I skipped a lot of work that's just > a "mere matter of coding" here :). > An alternative to just (!) test the environment + physio + DMA codepaths is to build the 'whipit' driver that Robert mentioned in an earlier thread. Then loading both the shrkudi and the whipit driver (maybe whipit has to be first - it's been a while) will cause the MA to bind both of them together. If I remember correctly, whipit will simply send data as fast as it can to the ND, so you'll probably want to connect it to a separate test net (or wait for the screams as the other users find all their bandwidth disappearing :-)) You can find the whipit driver in driver/examples/whipit in the reference tree. Cheers, James |
|
From: Robert L. <ro...@ca...> - 2002-02-05 17:46:30
|
Quick, Kevin wrote: > probably couldn't find an NSR mapper in the system and so that's > where the whole process stopped. Just load a functional NSR mapper > and watch the fun begin (yes, I skipped a lot of work that's just And if you don't want to bring up a 'real' NSR mapper yet, use 'whipit'. It is an NSR that will slap a driver silly but has no uptstream connection and no concept of real networking. Load your NIC driver, load whipit, and watch packets come flying out of the back of the system. RJL |
2 messages has been excluded from this view by a project administrator.
