problem in drivers/block/Config.in
hi, I noticed that the option CONFIG_PARIDE_PARPORT will always be "y", even if CONFIG_PARIDE_PARPORT="n". I checked with kernels 2.2.18 and 2.2.19. the file responsible is "drivers/block/Config.in", around line 126. it reads: # PARIDE doesn't need PARPORT, but if PARPORT is configured as a module, # PARIDE must also be a module. The bogus CONFIG_PARIDE_PARPORT option # controls the choices given to the user ... if [ "$CONFIG_PARPORT" = "y" -o "$CONFIG_PARPORT" = "n" ] ; then define_bool CONFIG_PARIDE_PARPORT y else define_bool CONFIG_PARIDE_PARPORT m fi so, as you can see, CONFIG_PARIDE_PARPORT will be set to "yes" even if CONFIG_PARPORT="no". why not simply write: define_bool CONFIG_PARIDE_PARPORT $CONFIG_PARPORT instead? regards, herbert rosmanith [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
patch: af_netlink rmmod problem
hello,
when doing a series of insmod/rmmod of af_netlink, I noticed
/proc/net/netlink entries being added each time.
this small patch addresses the problem:
--- snip ---
bash-2.03# diff -u linux-2.4.5.orig/net/netlink/af_netlink.c
linux-2.4.5.new/net/netlink/af_netlink.c
--- linux-2.4.5.orig/net/netlink/af_netlink.c Thu Apr 12 21:11:39 2001
+++ linux-2.4.5.new/net/netlink/af_netlink.cTue Jun 26 14:41:25 2001
@@ -9,6 +9,9 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
+ * Tue Jun 26 14:36:48 MEST 2001 Herbert "herp" Rosmanith
+ * added netlink_proto_exit
+ *
*/
#include
@@ -985,4 +988,11 @@
return 0;
}
+static void __exit netlink_proto_exit(void)
+{
+ sock_unregister(PF_NETLINK);
+ remove_proc_entry("net/netlink", NULL);
+}
+
module_init(netlink_proto_init);
+module_exit(netlink_proto_exit);
--- snip ---
thanks,
h.rosmanith
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
kernel panic w/ 2.6.22.1, VIA EPIA Mini ITX
good day, when setting up a more or less old board, 2.6.22.1 crashes during an "emerge --sync" (gentoo installation). first, the screen will start funny - like a crashed C64 (from the "good" old days). I made a photo, you can look at it here: http://wildsau.enemy.org/~kernel/epia-crash.jpg actually, that's not a static picture, but there's also a lotta blinking going on. the image you see is from a non-framebuffer mode kernel, since I first suspected the framebuffer being the culprit, because when I framebuffer mode, the crash will result in many coloured pixels on the screen, like when doing "cat /dev/random /dev/fb0". But since this happens in textmode too, something else is triggering this. anyway hardware: the board is a VIA EPIA 500Mhz fanless (Mini ITX) with a C3 processor and 1GB (2x512) SD-RAM. the kernel complains about this: Jul 28 22:30:17 localhost BUG: unable to handle kernel paging request at virtual address 00ff or, to me more specific: Jul 28 22:30:17 localhost BUG: unable to handle kernel paging request at virtual address 00ff Jul 28 22:30:17 localhost printing eip: Jul 28 22:30:17 localhost c016c506 Jul 28 22:30:17 localhost *pde = Jul 28 22:30:17 localhost Oops: [#1] Jul 28 22:30:17 localhost Modules linked in: parport_pc parport uhci_hcd usbcore Jul 28 22:30:17 localhost CPU:0 Jul 28 22:30:17 localhost EIP:0060:[]Not tainted VLI Jul 28 22:30:17 localhost EFLAGS: 00010206 (2.6.22.1 #2) Jul 28 22:30:17 localhost EIP is at __d_lookup+0x66/0xe0 Jul 28 22:30:17 localhost eax: 4c482617 ebx: 00ff ecx: 0011 edx: c 1819180 Jul 28 22:30:17 localhost esi: 00ff edi: f7634005 ebp: ef848780 esp: f 7a87dc0 Jul 28 22:30:17 localhost ds: 007b es: 007b fs: gs: 0033 ss: 0068 Jul 28 22:30:17 localhost Process bash (pid: 4209, ti=f7a86000 task=c1bb8070 tas k.ti=f7a86000) Jul 28 22:30:17 localhost Stack: 4c482617 f7a87e1c f7a87e3c f7fe7114 f7a87f30 00 11 f7634005 f7634016 Jul 28 22:30:17 localhost f7a87e3c f7a87f04 f7a87e3c c0162f48 f7a87e48 c18e6220 c01a82b0 f7ef12a0 Jul 28 22:30:17 localhost f7634016 f7a87e3c f7ef12a0 f7a87f04 c0164a69 f7634005 0001 4c482617 Jul 28 22:30:17 localhost Call Trace: Jul 28 22:30:17 localhost [] do_lookup+0x28/0x190 Jul 28 22:30:17 localhost [] ext3_permission+0x0/0x10 Jul 28 22:30:17 localhost [] __link_path_walk+0x669/0xb20 Jul 28 22:30:17 localhost [] mntput_no_expire+0x1b/0x70 Jul 28 22:30:17 localhost [] link_path_walk+0x63/0xc0 Jul 28 22:30:17 localhost [] link_path_walk+0x43/0xc0 Jul 28 22:30:17 localhost [] do_path_lookup+0x64/0x180 Jul 28 22:30:17 localhost [] getname+0xb3/0xe0 Jul 28 22:30:17 localhost [] __user_walk_fd+0x3b/0x60 Jul 28 22:30:17 localhost [] vfs_stat_fd+0x22/0x60 Jul 28 22:30:17 localhost [] sys_stat64+0xf/0x30 Jul 28 22:30:17 localhost [] syscall_call+0x7/0xb Jul 28 22:30:17 localhost === Jul 28 22:30:17 localhost Code: ea 31 d0 8b 15 b4 9e 3b c0 89 7c 24 18 21 d0 8b 15 bc 9e 3b c0 8b 34 82 85 f6 75 0f eb 54 8d b4 26 00 00 00 00 85 db 89 de 74 47 <8b> 1e 8d 74 26 00 8d 6e f4 8b 04 24 3b 45 18 75 e9 8b 44 24 0c Jul 28 22:30:17 localhost EIP: [] __d_lookup+0x66/0xe0 SS:ESP 0068:f7a 87dc0 Jul 28 22:30:17 localhost BUG: unable to handle kernel paging request at virtual address 00ff Jul 28 22:30:17 localhost printing eip: Jul 28 22:30:17 localhost c016c506 Jul 28 22:30:17 localhost *pde = Jul 28 22:30:17 localhost Oops: [#2] Jul 28 22:30:17 localhost Modules linked in: parport_pc parport uhci_hcd usbcore Jul 28 22:30:17 localhost CPU:0 Jul 28 22:30:17 localhost EIP:0060:[]Not tainted VLI Jul 28 22:30:17 localhost EFLAGS: 00010206 (2.6.22.1 #2) Jul 28 22:30:17 localhost EIP is at __d_lookup+0x66/0xe0 Jul 28 22:30:17 localhost eax: 00284951 ebx: 00ff ecx: 0011 edx: c 1819180 Jul 28 22:30:17 localhost esi: 00ff edi: f7bb1005 ebp: efa49688 esp: e 4837dc0 Jul 28 22:30:17 localhost ds: 007b es: 007b fs: gs: 0033 ss: 0068 Jul 28 22:30:17 localhost Process utempter (pid: 4308, ti=e4836000 task=f7c34090 task.ti=e4836000) Jul 28 22:30:17 localhost Stack: 00284951 e4837e1c e4837e3c f7d3a5ec e4837e48 00 03 f7bb1005 f7bb1009 Jul 28 22:30:17 localhost e4837e3c e4837f04 e4837e3c c0162f48 e4837e48 c18e6e20 c0158690 c1b54cc0 I have absolutely no idea what triggers this crash. cheers, herp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic w/ 2.6.22.1, VIA EPIA Mini ITX
> Checked the RAM on the box? Kinda weird if you're getting VRAM corruption, I > wonder if this is due to the RAM failing at the point where the framebuffer > is mapped? you are probably right... I removed one of the RAMs, no crash anymore. This is not ... nice. The manual says, that the board can handle up to 1GB (2x512MB). I don't think the RAM itself is damaged -- these are brandnew Kingston "ValueRam" PC133 SD-RAMs with lifelong guarantee. I wonder if this behaviour only apperas with my particular board, or if all VIA EPIA Mini ITX 500 are affected (I've run out of boards to test ...) thanks, herp > Try running memtest86 on it. good idea. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA EPIA EK: strange eth dev numbering
hi, I see a strange numbering of ethernet devices with a VIA EPIA EK board. This board has two ethernet connectors, you can see it here: http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=420 I configured the system such that via-rhine is loaded as a module. When doing the module load, the kernel says: via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker via-rhine: Broken BIOS detected, avoid_D3 enabled. ACPI: PCI Interrupt :00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17 eth0: VIA Rhine III at 0x1d000, 00:40:63:ee:96:56, IRQ 17. eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1. ACPI: PCI Interrupt Link [ALKD] enabled at IRQ 23 ACPI: PCI Interrupt :00:12.0[A] -> Link [ALKD] -> GSI 23 (level, low) -> IRQ 18 eth1: VIA Rhine II at 0x1ec00, 00:40:63:ee:96:55, IRQ 18. eth1: MII PHY found at address 1, status 0x7849 advertising 05e1 Link . but, when continuing, no such eth0 or eth1 device is present (and thus, dhcpcd will not receive any address). an "ifconfig eth"0(eth1) will report: localhost ~ # ifconfig eth0 eth0: error fetching interface information: Device not found localhost ~ # ifconfig eth1 eth1: error fetching interface information: Device not found it took a while until, just out of a feeling in my stomach, I tried "ifconfig -a", and surprise, surprise, the ethernet devices were in fact there, *but* there names where eth2 and eth3. doing an "ifconig eth2 192.168." in fact "upped" the interface, and I was able to work with the net. after ifconfig, the kernel would say: eth2: link up, 100Mbps, full-duplex, lpa 0x45E1 and ifconfig -a: localhost ~ # ifconfig -a eth2 Link encap:Ethernet HWaddr 00:40:63:EE:96:56 inet addr:192.168.1.23 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:16713 errors:0 dropped:0 overruns:0 frame:0 TX packets:10522 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:18133391 (17.2 Mb) TX bytes:1176276 (1.1 Mb) Interrupt:17 Base address:0xd000 eth3 Link encap:Ethernet HWaddr 00:40:63:EE:96:55 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:18 Base address:0xec00 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) localhost ~ # pretty strange?! I dont think this is the correct behaviour, is it? cheers, herp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA EPIA EK: strange eth dev numbering
> > Strange or not, correct or not - depends on the point of view. > > The key word here is "udev" - check your udev rules. Since some time > ago udev on some distros comes with rules to give persistent device > names for network interfaces. Some time ago you had eth0 and eth1 > with different hardware, and udev remembered this fact somewhere. > Now it sees new hardware, and gives it consecutive numbers, renaming > kernel devices. hu. where are the days when eth0 was eth0 ... this means that, when I exchange a network card and replace it with a new one, it will cost an "ethX" device name each time. FYI, distribution is latest Gentoo. as a friend of mine puts it: "Haha das is geil, das is wie bei Windows" "Wo er merkt, dass du ein neues Mainboard hast :)" which translates: "Haha, that's randy, that's like in Windows, which notices that you've got a new mainboard" Bad, bad Ferdl! How dare you compare this to M$Windows ;-) well, Michael, thanks for the help, herp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA EPIA EK: strange eth dev numbering
> > On Aug 2 2007 12:42, Herbert Rosmanith wrote: > There never *were* days when eth0 remained eth0 across such changes. but there *were* days when eth0 was eth0, if the kernel reports it as such. now there is no eth0 at all. if I see an "eth0" from dmesg, I expect it to be present. Instead, udev remembers the old MAC address in /etc/udev/rules.d/70-persistent-net.rules which contains the old MAC adresses, too. of course, that's problem with gentoo, not with the kernel. Now I know why I never trusted udev much :-/ thanks, herp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA EPIA EK: strange eth dev numbering
> > cards around), eth0 would also suddenly become a different one. There never > > *were* days when eth0 remained eth0 across such changes. > > but there *were* days when eth0 was eth0, if the kernel reports it as such. > now there is no eth0 at all. if I see an "eth0" from dmesg, I expect > it to be present. hm, well, a thought, maybe udev should report what is doing, like printinig "renamed eth0 to eth2", or such. the problem with this device renaming in my case was that other software, in particular dhcpcd, didnt get any lease, because (obviously?) dhcpcd on the other hand _still_ seemed to look for eth0, and thus, after booting, there was no network configured at all. Maybe the name "eth0" is hardcoded in the gentoo init scripts, I dont know. Can this be considered a distrubtion bug? cheers, herp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA EPIA EK: strange eth dev numbering
> Wait, you forget that something may change the name. That dmesg message > from 1 second ago does not need to be valid anymore, just as anything > else in this world. there are many things in this world which are usually very persistent, and people rely on their persistence. e.g. in my office, I assume the phone number is still the same I used 1 second ago ... but what has this to do with ethernet device names? well: I expected the names persist - like they did without udev. I'm used that things persist, as probably the rest of the world :-) cheers, herp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: renaming kernel devices [was: VIA EPIA EK: strange eth dev numbering]
> >And now tell me please how can I connect two messages from dmesg: > >eth0: Tigon3 [partno(BCM95721) rev 4201 PHY(5750)] (PCI Express) > >10/100/1000Base-T Ethernet 00:14:5e:5d:18:26 > >nic10: Link is up at 100 Mbps, full duplex. > > Generally, the "link is xyz" message comes directly after loading the module, > so it should be eth0 before udev gets a chance to rename it. Or maybe not - you mean like this: eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1. ... eth2: link up, 100Mbps, full-duplex, lpa 0x45E1 with eth0 really being (same MAC) == eth2. > in which case, well, you're literally fubared, and your distro should put a > "renamed A to B" into syslog. I think it would be helpful. /herp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.11.10: rtl8192cu device name, kernel crash
hello list, this afternoon I bought a new usb/wlan adapter, which identifies itself as: # lsusb ... Bus 001 Device 017: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter the first thing I noticed is that the device name is renamed: [ .688299] systemd-udevd[3090]: renamed network interface wlan1 to wlp0s29f7u4u4u2 Excellent! I always hated that userfriendly and easy to remember names like "wlan1". Finally I have a more sophisticated name, "wlp0s29f7u4u4u2" that strictly follows The Tao Of Terribly Silly Device Naming. Additionally, iwconfig and ifconfig cannot decide upon the device name. While iwconfig sees "wlp0s29f7u4u4u2", ifconfig is a bit short-sighted and only sees "wlp0s29f7". The problem is that none of the two devicenames can be used for configuring it: # dhclient -d wlp0s29f7 ... SIOCSIFADDR: No such device wlp0s29f7: ERROR while getting interface flags: No such device wlp0s29f7: ERROR while getting interface flags: No such device Bind socket to interface: No such device and: # dhclient -d wlp0s29f7u4u4u2 ... Bind socket to interface: No such device Renaming "wlp0s29f7u4u4u2" back to "wlan1" will make the adapter known to dhclient/ifconfig (finally udev can do something useful), but not without crashing the system in between: I added the mac-addr. to the persistent-net udev-rules, did a /etc/init.d/udev restart, and removed the adapter from the usb hub. Instantly, the system froze, I had to push the power button to get it back. This was the 2nd time the system crashed, the first time on the console: it was some kernel panic. As the system didn't react anymore, I did not bother to write down the lengthy panic message. By the way, kernel version is 3.11.10. As the device is handled by the rtl8192cu module, which is not in the staging directory, it is considered stable, isn't it? cheers, herp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
