Re: [PATCH] 3c59x: read current link status from phy

a serial protocol, such that each MII register read is in fact about 200 (in total) of outw and inw/inl operations. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Te

Re: [PATCH] 3c59x: read current link status from phy

rrupt whenever the link changes, which can be used instead of polling for link state. This feature is not used in the 3c59x driver and could give you much less than 10 seconds accuracy - but you have to code it. ;-) -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftlich

Re: [PATCH] 3c59x: read current link status from phy

t for "portfast". -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the li

Re: [PATCH] 3c59x: read current link status from phy

this operation is I/O expensive - it is performed inside a region protected by a spinlock - it is performed often, every 60 seconds Is there some specific hardware that exhibits a problem that is solved by this double reading ? -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftl

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

xposed another problem in my previous message: after 'rmmod sata_mv', the controller can still generate interrupts, f.e. when a drive is attached. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

ting for some hints or patches :-) Side note: I was able some time ago to use this controller with the mv_sata driver 3.40, also with a RHEL kernel, without any fiddling with ACPI. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF

Re: Linux and system area networks

ot be faster than the underlying communication features. Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: [EMAIL PROTECTED]

Re: 3C905B -- EEPROM (i blive so) problem

u decide to go the last way, maybe I can help with some interpretation of the docs - please e-mail me in private. Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8

Re: PATCH: ethtool MII helpers

& (mii->bmcr & BMCR_ANENABLE)) { + mii->mdio_write(dev, mii->phy_id, MII_BMCR, + mii->bmcr & ~BMCR_ANENABLE); + } This is nice, but I would like to able to restart autonegotiation even without changing any of the advertise

Re: Looking for device to write device driver for

basic operations! Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the

Re: MII access (was [PATCH] support for Cobalt Networks (x86 only)

On Sun, 3 Jun 2001, Jeff Garzik wrote: > Bogdan Costescu wrote: > > With clearer mind, I have to make some a correction to one of the previous > > messages: the problem of not checking arguments range does not apply to > > 3c59x which has in the ioctl function '&a

Re: MII access (was [PATCH] support for Cobalt Networks (x86 only)

nk or any other way, you have to read it from the hardware and deliver to user-space at user request. So the "doing the MII monitoring" is the tough part. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelber

MII access (was [PATCH] support for Cobalt Networks (x86 only)systems)

= (0xf6 << 10) | ((phy_id & 0x1f) << 5) | (location & 0x1f); > You don't need timers. Too tired to think straight yesterday... You're right. And if you alloc 32*sizeof(int) (you want to keep jiffies, right ?) per netdevice, I think that it could even

Re: [PATCH] support for Cobalt Networks (x86 only) systems (for

e. But when somebody is playing tricks while you need data, you have the chance of detecting this by using rate limits. And yes, I agree that either of them (cache or rate limit) should be modifiable through proc entry/ioctl/whatever. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum

Re: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis

he link is down. Yes, but is this a good approximation ? I'm not saying that it's not, I'm merely asking for counter-arguments. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY

Re: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis

limiting solution allows a warning to be issued when the limit is exceeded, so that the poor sysadmin knows what hit him 8-) -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Tele

Re: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis

o be defined), so he/she can't shoot his-/her-self in the foot. Legit use of current hardware state is possible. IMHO, solution 2 is much better. Can you find situations when it's not ? -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universit

Re: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis

epends on link status, I want the info to be accurate, I don't want to know that 30 seconds ago I had good link. IMHO, rate limiting is the only solution. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heide

Re: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)

c/apm, which only > hits BIOS instead (and it's debateable what is better). Hmm, the MII related ioctl's in some net drivers (checked for 3c59x, tulip, eepro100) are also querying the hardware. And a user is allowed to ask for this info (but not able to modify it). Sincerely, Bogda

Re: APIC problem or 3com 3c590 driver problem in smp kernel 2.4.x

e in 3c59x ISR is: if ((status & IntLatch) == 0) goto handler_exit; /* No interrupt: shared IRQs can cause this */ with which the driver detects if the interrupt was generated by the card. Are you sure the driver for the other PCI device knows to play nice with shared interrupts ?

Re: LANANA: To Pending Device Number Registrants

nging MAC address when the interface is down. So Al's /dev/eth//MAC has different values depending on whether bonding is active or not. Should /dev/eth//MAC always have the original value (to be able to uniquely identify this card) or the in-use value (used by ARP, I believe) ? Or maybe have

Re: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ?

sually some error messages from the driver, but everything should otherwise work. To verify the media settings, you might want to use mii-diag (from ftp.scyld.com). Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120

Re: [RFC] Configuring synchronous interfaces in Linux

rease the speed in case it's not able to get it ? (the example is Ethernet specific, but the ideea is not). And finally (also Ethernet specific): some devices don't like forced media settings when they support autonegotiation. Look at the tulip recent archives for examples. Sincere

Re: Preallocated skb's?

e decision (lookup etc). > i.e this will allow for a better FF; it will not offload things. Just that you span several layers by doing this, it's not driver specific anymore. Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet He

Re: Preallocated skb's?

by the hardware and you try to fit a packet in a skbuff sized for the previous packet (in case several packets can be transferred during the "overhead" time) - under load, because interrupts occur anyway (the Rx early ones), you don't loose anything in terms of latency.