Re: How to support an Ethernet PHY without ID registers?
Sepherosa Ziehau wrote: Are you sure you could read from BMSR? Return invalid value from BMSR is the usual cause of miibus attaching/probing failure. For ID1/ID2 reading, you could just fake some values in npe(4)'s miibus_readreg implementation. Thanks for the tip (from you and Pyun). I had to spoof the BMSR read to get npe(4) to attach just to begin with. For whatever reason the chip doesn't seem to respond on any of the PHY IDs which the Linux folk are using (5 and 4 for npe0 (-B) and npe1 (-C) respectively). I noticed the ucLinux folk needed a similar patch to force driver attach under Linux w/the IXP: http://mailman.uclinux.org/pipermail/uclinux-dev/2005-March/031419.html The switch pretty much disappears after npe(4) attaches, I don't see any activity lights or link lights at that point. This seems to happen after any mii register access. If I frob things to allow rlswitch to attach, by using hints and hacking if_npe.c, I can get dumps of the PHY register space, but it's all ones, suggesting that it failed at xScale register level -- that would suggest the PHY IDs are *wrong*, or something else isn't right. Pyun also suggested trying to manually take the PHYs out of power-down mode. I tried that with a code snippet I sent him, but still no dice. I can't even be sure that the PHYs are being addressed right. At this point I kind of have to go, whoah, wish I had a logic analyzer and grabbers! I believe the firmware configures the switch chip in a certain VLAN configuration which isn't meant to be disrupted, although Freecom's own SnapGear-based distro apparently does the right thing. I've looked through all of their GPL materials and cannot find the driver for the switch. I suppose one thing I could try is re-flashing the box with the official Freecom firmware, and using mii-diag to dump out what Linux thinks the registers are. thanks BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel profiling: spinlock_exit consumes 36% CPU time.
邱剑 wrote: Many thanks for the information. Could we say that interrupt handlers consumed ~36% execution time? Is this number too high? Is it possible that we abuse the use of critical sections in kernel? Also note that profiling itself is using ~40% of CPU. That means you need to worry about whether it is seriously skewing the results away from what they would be without profiling. If you can use hwpmc then the profiling overhead is much less. However support for modern Intel CPUs was only recently added in -CURRENT and may not have been merged to 7.x yet, so it might not be usable for you yet. If you run without profiling then top(1) will show you the CPU use of the interrupt handlers. Kris Looking forward to your options. Many thanks. Qiu Jian On Tuesday 07 October 2008 07:44:00 am 邱剑 wrote: Hi, folks, I did kernel profiling when a single thread client sends UDP packets to a single thread server on the same machine. In the output kernel profile, the first few kernel functions that consumes the most CPU time are listed below: granularity: each sample hit covers 16 byte(s) for 0.01% of 25.68 seconds % cumulative self self total time seconds secondscalls ms/call ms/call name 42.4 10.8810.880 100.00% __mcount [1] 36.1 20.14 9.26 17937541 0.00 0.00 spinlock_exit [4] 4.2 21.22 1.08 3145728 0.00 0.00 in_cksum_skip [40] 1.8 21.68 0.45 7351987 0.00 0.00 generic_copyin [43] 1.1 21.96 0.29 3146028 0.00 0.00 generic_copyout [48] 1.0 22.21 0.24 2108904 0.00 0.00 Xint0x80_syscall [3] 0.8 22.42 0.21 6292131 0.00 0.00 uma_zalloc_arg [46] 0.8 22.62 0.20 1048576 0.00 0.00 soreceive_generic [9] It is very strange that spinlock_exit consumes over 36% CPU time while it seems a very simple function. It's because the intr_restore() re-enables interrupts and the resulting time spent executing the handlers for any pending interrupts are attributed to spinlock_exit(). -- John Baldwin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
