thekx

Thanks scarecrow, that explains that. Tracking what gets dropped across versions isn't easy unless it's something you're using daily...

Thanks arctic. Now I've had a bit of free time I've managed to provoke the kernel panic, and tried your suggestions. None of them even provoked a line in syslog, and the blue LED on the DVB stick stayed lit all the way through. Bummer. Oddly, I don't even have hotplug as a service in /etc/rcX.d Plan B is, I guess to try to get the kernel panic fixed. I guess I'll try to find an appropriate list to post on for v4l-dvb...

Hi, I'm getting occasional kernel panics from my Leadtek Winfast DTV dongle, which leave it in an unusable (locked) state. 'service hotplug restart' seems to do a warm reset - not enough to help here. Equally, a system reboot doesn't fix it. I have to pull the USB connection, or poweroff and disconnect the power to the PSU. The system box isn't very accessible, so I'd really like to find a gentler alternative... So, is there any way in software to hard reset USB devices? I can tolerate resetting the whole USB subsystem if it fixes this. I've tried googling, but either there's no easy answer, or I'm like a n00b and missing the magic search terms. Best, Nick

Richard: if you're running the mdv 2007 stock kernel, I think you can probably skip steps 5-12. If you're still seeing errors about xmit-lock, it's either that the kernel version you're running is newer than Phil and mine and no longer needs the hack in steps 13-15, or that you missed one occurence - step 15 is easy to overlook! As I understand it, you don't need to use modprobe explicitly. Once everything is compiled and installed, the hotplug service will notice a new USB device getting plugged in, and does all necessary module loads for you. Hope you get it working! It'd be good to get feedback if you do/did... Nick

OK, it took a bit more work (doesn't it always) to get it to work, but I've got the Leadtek dongle registering now. I had installed the latest version of v4l using mercurial (another versioning system like cvs/svn) instead of the snapshot. It still didn't register the stick until after I deleted /lib/modules/2.6.17-6mdv/kernel/drivers/media/* - presumably a conflict with a module already in the kernel. Then I had a problem when I recompiled ivtv (for the PVR350 already running). It compiled fine, but gave a kernel oops and froze the machine when modprobe'd. Thank goodness for 'linux init=/bin/bash' at the lilo prompt to let me in to disable the ivtv modules! I got ivtv back running by replacing the header files in /usr/src/linux/include/media with the new ones supplied with v4l (maybe there's a better way to do this, but I don't know it). Again, version differences seem to get in the way, although I'm surprised that the v4l make install doesn't copy across the .h files automatically to save headaches... Nick

Wow, thanks Phil! I've been trying to get my new USB DVB-T stick (a Leadtek WinFast DTV Dongle) to work, and I'd got as far as the compilation errors you mentioned. As far as I can understand, Mandriva seem to have backported some features from 2.6.18 to their customised 2.6.17 kernel, and that makes compiling some things a nightmare unless you know what to change where. By Thursday evening, I'd found some things saying you could hack the v4l source to work with 2007.0, but not what the actual hacks were until now! This looks like it'll work a treat. I've got some stuff running that I don't want to interrupt, so I can't test yet, but I'm pretty confident it'll work B) . I'll post back as requested when I've had a chance to try.

Sneaky! :P Didn't see this in the Help section FAQ - maybe worth adding under the 'posting' or 'topics' heading? N

Well, after spending the best part of ten consecutive nights on this, I took some overdue family time before coming back to attack this problem fresh. First the good news - I managed to get the network working. Yay! The more puzzling news is that I can't work out exactly why... I brought the router upstairs, and found that I got different responses depending which LAN port I used. It seemed that ports 1, 2 and 3 worked with the linux box, but 4 wouldn't. When plugged in to any port, the link LEDs were showing a good 100Mb connection. The only difference was that on port 4, the activity LED was 'strobing' - flashing quickly. According to the manual, this is normal response for a busy port. Whilst it may be doing something it just isn't exchanging packets. I figured maybe it was just a weird port failure on that one socket on the router. I thought it seemed odd that I hadn't noticed it before in all my other swapping of leads, but never mind. So, I moved the router back downstairs, and reconnected the same patch cables through a 'good' port. Guess what - once again I was seeing the activity LED strobing, and no network via the linux box. Switch port or cable again, and it works. Savage. So, I've found a combination of port and cable which works, and it's been stable for a couple of days. In summary, it doesn't actually seem to be consistently specific to any port or any patch cable. The combinations which don't work on the linux box do work on the Windows box. The only consistent thing is the combination of router and NIC hardware. The most frustrating thing is that the router LEDs suggested that it's a good, active connection at a hardware level; but this now looks bogus. In truth I guess I must have just positioned the box with bad feng shui when I loaded up the DVD to install mdk10.1. Now it does talk to the router, everything seems to work really smoothly, thanks to all the advice here! I think I'll work on the basis of 'let it be' and consider a router upgrade in the longer term. Thanks to all who have offered suggestions, especially streeter. You guys are gurus. If a mod wants to mark this thread solved, that's fine by me - I can't see any way to edit the title as a regular punter. Best, Nick

Unfortunately, as I posted (some time back now, I grant you!), I've actually gone through three full installs with format, keeping only the /home partition each time. I've been through the wizards several times before going back to bash where at least I know what's getting edited. :sad: N

Hi Qchem, MCC 'manage connections' reports: Device selected eth0: VIA Technologies|VT6102 [Rhine II 10/100] TCP/IP protocol static ip, netmask, gateway, dns all set correctly search domain none Options (yes) Start at boot (no) Track network card id (no) Network Hotplugging Metric 10 Information Vendor: VIA Technologies Description: VT6102 [Rhine II 10/100] Media class: NETWORK_ETHERNET Module name: via-rhine Mac Address: 0:40:***** Bus: PCI Location on the bus: - That's it. N

Well spotted! Unfortunately, I fear I can already eliminate the cable running downstairs, unless these are very heavy packets :P For both Windows and linux I've used the same two fixed CAT5 ports in the wall. I've wired the house with CAT5 as I've renovated it - it'll probably be obsolete within 10 years but should work now! Yesterday's efforts were with a 15m patch cord direct port-to-port just in case I managed to really screw up the patch panel wiring somewhere. So I don't think it's that. If I can I'll haul the router upstairs later and test out with shorter leads in case it's some wierd whole-house interference that offends only linux boxen. Well, I guess I know a fair amount, but you never stop learning, and you can always completely forget the blindingly obvious! Router did default to ...1.1 which fits with the linux settings. Ta, Nick

Double-checked. I wondered if it would something really dumb like I'd got the wrong port in the router downstairs but no, the hub was in regular port 4, nothing in uplink. I tried the uplink instead (as the manual suggests this is where a hub should connect), and this completely killed the connection. I lost the link light until I switched the hub port back to normal mode - so it confirms that the router's 'uplink' port is just an unswitched connection - basically the Linksys uplink port is the only "ordinary LAN socket on the router" as you describe it above. Ports 1-4 are "out of the ordinary" because they're switched. I've factory-reset the router and run through the pings. Still nothing on linux, and still the odd additional behaviour where Windows equally fails to connect, if going through the hub. I can't help feeling this is a clue, but to what? I think I'm bailing for tonight too. Appreciate your help this far, Chris. Seems to confirm I have some sanity left. If anyone else has other ideas on what might be stopping my router talking to everything like it used to, I'd welcome it... G'night all, Nick

Hi again, and thanks for the quick reply. Really appreciate it! The router is a Linksys BEFW11S4. In addition to WiFi and a WAN uplink it has 4x 10/100 switched LAN ports. The hub is a Netgear DS106 with 6x internally-bridged 10/100 ports, one of which is switchable between 'normal' and 'uplink' position. To clarify, I'm connecting the 'uplink' port of the hub to one of the 4 LAN ports of the router, not to the router WAN uplink. Since the router ports are switched (I omitted to mention before - sorry, the implication didn't occur to me), I need to use the uplink rather than a normal hub port. Ah, this surprises me. I'd have thought that I should see packets broadcast to 192.168.1.255 even among the switched ports. For instance, to allow me to run a dhcp server on a (working) linux box if I chose to disable the router's in-built dhcp. Well, things are certainly starting to point to the router. Trouble is, the same router/NIC/wiring combination worked last week, and I didn't change the router settings in between. What can have changed when I did the mdk10.1 install, that stopped the NIC talking to the router? BIOS? MBR? Evil NIC probing which accidentally reflashes firmware?! It seems too much of a coincidence for it to work in the morning on 9.1 and fail in the afternoon on 10.1. N

I've been doing some other tests, and the results have me confused. I hope someone here can make sense of it. I installed Packetyser onto the Windows box to monitor the LAN activity. With this, I could clearly see the Windows and Linksys router negotiating an IP address via DHCP. But I couldn't see anything to/from the linux box - the router appeared to be acting as a switch to hide activity from the linux box although they should be on the same segment. Next, I inserted a hub between the router and linux box to try to see what was going on there. When I ran `ping -bf 192.168.1.255` to flood ping my LAN with broadcast packets, I got a stack of activity on the hub LEDS. The NIC answered fine (>6,200 packets/sec, with 0% packet loss). I surmise from this that the NIC hardware is getting something onto the local ethernet. Next, I plug both the Windows and linux box on the hub, sharing an uplink to the router. Now I can see the linux box, broadcasting ARP requests every second or so: ARP: Who has 192.168.1.1? Tell 192.168.1.2 At the same time, the Windows box tries to re-negotiate DHCP, but now gets no answer from the Linksys router! So, to summarise: If the two boxes are patched direct to any two LAN ports of the router, Windows networks fine, linux sees nothing. Router shows link lights for both. If they share a router LAN socket through the hub, neither box can see the router, but they can see each other's packets. All 3 sockets on the hub show link lights, as does the router at the end of the uplink. If I have either box alone attached through the hub to the router, I get no answer from the router. Again, link lights fine. The crazy thing is that this network and hardware all worked perfectly on 12 March, until I upgraded the linux box from mdk9.1. Aagh?! Nick

For sure. I dread to think how many hours I've been trying different things to solve this... it'd be easy to miss something simple. OK. Windows pings linux, with both connected to router via separate patch leads = nothing. I swap the patch lead from Windows box to linux box. Link light on router returns. Turn off router for 1/2 hour and go have a cup of tea. Power it up again, reboot linux. Check `ifconfig eth0` is up, have: inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 `ping 192.168.1.2` (linux NIC) - 0% packet loss, 0.01ms avg TTL `ping 192.168.1.1` (router) - destination host unreachable, 100% packet loss `route -n` gives: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 N

Please excuse me following myself up again, but I thought I ought to add, I've pinged the router again and still get host unreachable. After this ping though, the number of packets and bytes has gone up in both input and output chains of iptables -nvL. N

OK, installed iptables and now running iptables -nvL gives: Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Looks like no rules. Which may or may not be good news... Time to hit the man page! N

Hi Chris, Thanks for replying. That's news to me about iptables being frontend only. I'll install and test that out. On the other things, yes, I can ping the router from the 'doze box just fine. Haven't got a crossover cable to try - may yet have to make one up! Trying another NIC could be tricky; it's a Mini-ITX EPIA mobo, so there's only one PCI slot. That's occupied by a TV card as this is the family PVR that's out of action. It's OK to pull it for testing, but it would make the box redundant in practice! :lol: I'll test out iptables and report back. Thanks, Nick

Hi QChem, First efforts were with the via-rhine.ko.gz driver module autodetected and installed by the mdk10.1 installer. This gets eth0 up (statically) but still lack connectivity to the rest of the LAN. I tried to download and compile a fresh driver from VIA. This module had a different name of rhinefet.ko. Even though compiled against the kernel-source2.6 off the DVD, it wouldn't insert, as the magic number was different. AFAIR, it was 2.6.8.1-12mdk in the module and 2.6.8.1-12mdk-i586-up-1GB was expected. Clearly some clever tweak required somewhere, but it's somewhere buried in the linux source hooks rather than the driver. I tried poking around in version.h but decided to back out as I'm not that great at parsing C! :o So, everything since has been back to the default driver. Hope that explains. Thanks, Nick

Hi all, One thing to add. With the static IP defined: ping 192.168.1.2 (the eth0 interface) answers fine. ping 192.168.1.1 (the router/gateway) 100% packet loss. My instinct is that there's nothing getting down the cable to the router. How can I test this out? LEDs are lit at both ends of the cable (I've tried different cables and ports into the router) and ifplugd seems to see a link working... I'd *really* welcome any ideas from people out there :unsure: Best, Nick

Just to add an aside, I wondered if it might be a problem with the via-rhine driver module itself. I downloaded a fairly recent source tarball for the driver (dated november 04) and compiled it, having installed the kernel-source-2.6 package from the mdk 10.1 official DVD. Unfortunately, the module created (rhinefet.ko) won't insmod, since it has the wrong magic number. No idea how to get it to have the right magic number though, so I can't even tell if that would have helped... :sad: N

Hi arctic, thanks for the welcome - I've read quite a few posts from you over the past few days, so it's reassuring to hear from you! To (hopefully)eliminate a couple of things, no firewall is installed (iptables not found), no firefox installed yet, and the / partition is ext3. resolv.conf is not yet locked, but no change evident before or after trying to service network restart. Without a connection, I'll have to retype the current state of the requested files. With dhcp: ifcfg-eth0 DEVICE=eth0 BOOTPROTO=dhcp NETMASK=255.255.255.0 ONBOOT=yes METRIC=10 MII_NOT_SUPPORTED=no# or yes, I've tried with both NEEDHOSTNAME= yes # or no, I've tried with both ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:40:53:CC:33:33 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:13 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:303 (303.0 b) TX bytes:4446 (4.3 Kb) Interrupt:11 Base address:0xe800 >ping www.google.com ping: unknown host www.google.com With static IP I used exactly the settings from Chris's setup guide sticky'd on mandrakeusers.org as they're using the correct IP class for my router. Only difference is in address of nameservers, which are same as work on my Windoze box. With this setup, ifconfig eth0 is same as above, with addition of: inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 below first line. After a reboot, eth0 comes up, but ping requests return 100% packet loss. Does this point to anything obvious? Best, Nick

I've installed 10.1 to replace my previous install of mdk9.1 (which networked fine) on a VIA EPIA/Eden box. Install runs smoothly but on reboot I can't connect eth0. Looking at syslog, dhclient reports a series of: 'DHCPDISCOVER on eth0 to 255.255.255.255 port 67' messages, followed by: 'no DHCPOFFERS received...no working leases...sleeping'. This is from a LAN connection to my Linksys router, which is leasing fine via DHCP to my Windows box alongside, and was fine with mdk9.1 before. Sanity checks: eth0 is UP BROADCAST RUNNING MULTICAST according to ifconfig, and link beat is detected according to dmesg. Driver is via-rhine, which was autodetected OK and is loaded without error according to lsmod and dmesg. I noticed a message in syslog about no IPv6 routers found. I tried editing sysctl.conf and modprobe.conf as suggested on: http://mandrakeusers.org/index.php?showtopic=23508 which I found through google. The ipv6 messages have stopped, but still no network. I've since tried a complete re-install from media (twice). I've also tried setting a static IP address/netmask/gateway within the correct IP class for the router, but that doesn't work either - with this the eth0 interface comes up (which is arguably progress), but `route` returns nothing. Even if I manually add nameservers to /etc/resolv.conf and `route add` a default gateway, I still can't seem to ping out. I've been battling this for 3 days now Can anyone please help! I thought this should be a straightforward upgrade... :-( Nick