First openSUSE 12.3 Upgrade

Last night I upgraded one of my spare laptops (an HP DV7-3165DX) to the new openSUSE 12.3.  In a word: flawless.  It updated, rebooted, and was ready to go.  Everything just works and all my work-a-day applications resumed operation with their expected configuration.  Defined VPN connections all remained operational as well.

Now running the 3.7.10-1.1-desktop kernel and some shiny new versions.  No separate repository is required to get to the excellent GNOME Shell 3.6.x (the version where GNOME Shell got all grow'd up).

Now I can get back to work.  As good as this is looking I'll probably upgrade my workstation and work-a-day laptop in short order.

gnome-shell-3.6.3.1-1.1.1.x86_64
pulseaudio-3.0-1.1.1.x86_64
evolution-3.6.3-1.2.1.x86_64
banshee-2.6.0-3.2.1.x86_64
python-2.7.3-10.1.1.x86_64
libreoffice-3.6.3.2.4-2.4.1.x86_64
gnucash-2.4.11-2.1.2.x86_64
cups-1.5.4-5.2.1.x86_64
rabbitmq-server-2.8.7-2.1.3.x86_64
postgresql-server-9.2-2.1.1.noarch
glade-sharp2-2.12.10-38.2.1.x86_64.rpm
monodevelop-3.0.6-1.2.1
cadaver-0.23.3-65.1.2.x86_64
ghostscript-9.06-4.1.1.x86_64
MozillaFirefox-19.0-1.1.1.x86_64
tracker-0.14.4-2.1.2.x86_64
zeitgeist-0.9.5-2.1.1.x86_64
gnome-activity-journal-0.8.0-8.1.2.noarch
New Versions!

Only disappointment is that LibreOffice 4 didn't make the cut for the new release.

For anyone researching hardware issues, below is the low-down on the DV7-3165DX.  Probably nobody is looking, as the entire DV6 & DV7 seem to work flawlessly with LINUX,  but for the search engines...

00:00.0 Host bridge: Advanced Micro Devices [AMD] RS880 Host Bridge
00:01.0 PCI bridge: Hewlett-Packard Company Device 9602
00:04.0 PCI bridge: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI
bridge (PCIE port 0)
00:05.0 PCI bridge: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI
bridge (PCIE port 1)
00:06.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge
(PCIE port 2)
00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]
00:12.0 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB
OHCI1 Controller
00:12.2 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB
OHCI1 Controller
00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus
Controller (rev 3c)
00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia
(Intel HDA)
00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 LPC host controller
00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to
PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
Link Control
01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
RS880M [Mobility Radeon HD 4200 Series]
01:05.1 Audio device: Advanced Micro Devices [AMD] nee ATI RS880 HDMI
Audio [Radeon HD 4200 Series]
08:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless
Network Adapter (PCI-Express) (rev 01)
09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
/sbin/lscpi

processor       : 0 [and 1]
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 6
model name      : AMD Turion(tm) II Ultra Dual-Core Mobile M620
stepping        : 2
microcode       : 0x10000c7
cpu MHz         : 800.000
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc
extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic
cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt
hw_pstate npt lbrv svm_lock nrip_save
bogomips        : 4986.89
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
/proc/cpuinfo

Unknown Protocol Drops

I've seen this one a few times and it is always momentarily confusing:  on an interface on a Cisco router there is a rather high number of "unknown protocol drops".  What protocol could that be?!  Is it some type of hack attempt?  Ambitious if they are shaping there own raw packets onto the wire.  But, no, the explanation is the much less exciting, and typical, lazy ape kind of error.

  5 minute input rate 2,586,000 bits/sec, 652 packets/sec
  5 minute output rate 2,079,000 bits/sec, 691 packets/sec
     366,895,050 packets input, 3,977,644,910 bytes
     Received 15,91,926 broadcasts (11,358 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog
     0 input packets with dribble condition detected
     401,139,438 packets output, 2,385,281,473 bytes, 0 underruns
     0 output errors, 0 collisions, 3 interface resets
     97,481 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred

This is probably the result of CDP (Cisco Discovery Protocol) being enabled on one interface on the network and disabled in this interface.  CDP is the unknown protocol.  CDP is a proprietary Data Link layer protocol, that if enabled, sends an announcement out the interface every 60 seconds.  If the receiving end gets the CDP packet and has "no cdp enable" in the interface configuration - those announcements count as "unknown protocol drops".  The solution is to make the CDP settings, enabled or disabled, consistent on every device in the interface's scope.