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

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, Telefax: +49 6221 54 8

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

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, Telefax: +49 6221 54 8868 E-mail

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

ink 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 Wissenschaftliches Rechnen Universit

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

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 line &q

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 Wissenschaftliches

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 Wissenschaftliches

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

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 line unsubscribe linux

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

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 Wissenschaftliches Rechnen Universitaet

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

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 Telephone: +49 6221 54 8

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

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 Telephone: +49

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

ble 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 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 5

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

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 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869

Re: Linux and system area networks

er 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] - To unsu

Re: Linux and system area networks

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] - To unsubscribe from this list: send

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

ast 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 8869, Telefax: +49 62

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

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 8869, Telefax: +49 6221 54 8868 E-mail: [EMAIL PROTECTED

Re: PATCH: ethtool MII helpers

gt;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 advertised capabilities. If I missed this possibility, please point me to it...

Re: PATCH: ethtool MII helpers

autonegotiation even without changing any of the advertised capabilities. If I missed this possibility, please point me to it... Nice work! -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49

Re: Looking for device to write device driver for

c 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 line

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 '& 0

Re: Looking for device to write device driver for

! 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 line unsubscribe linux

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 ' 0x1f' for both transceiver number

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

o 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 Heidelberg, GERMANY Telephone: +49 6221 54 8

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 be done ou

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

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 be done outside the driver. Hmm, most of my previous arguments are no longer valid 8-( -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer

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

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 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: [EMAIL

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

laying 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 fuer Wissenschaftliches R

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

nk 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 Telephone: +49 6221

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

ing 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, Telefax:

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

), 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 Universitaet Heidelberg, INF 368,

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

h depends 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 Heidelberg

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, Bogdan Costescu

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

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, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer

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

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 fuer Wissenschaftliches Rechnen

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

-/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 Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY

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

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, Telefax: +49

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

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 Heidelberg, GERMANY

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

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 Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: [EMAIL PROTECTED

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

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 ? Since

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

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 ? Sincerely, Bogdan

Re: LANANA: To Pending Device Number Registrants

ss 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 a /dev/eth//MAC_in_u

Re: LANANA: To Pending Device Number Registrants

/eth/n/MAC has different values depending on whether bonding is active or not. Should /dev/eth/n/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 a /dev/eth/n/MAC_in_use ? Sincerely, Bogdan Costescu IWR

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

y 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 Heid

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

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 Heidelberg

Re: [RFC] Configuring synchronous interfaces in Linux

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. Sincerely, Bogdan Costescu IWR

Re: [RFC] Configuring synchronous interfaces in Linux

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. Sincerely, Bogdan Costescu IWR - Interdisziplinaer

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 Heidelb

Re: Preallocated skb's?

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. Sincerely, B

Re: Preallocated skb's?

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. Sincerely, Bogdan Cos

Re: Preallocated skb's?

). 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 Heidelberg, INF 368, D-69120 Heidelberg