[newbie question] addresses of loaded programs/functions
Hello I am writing a profiling tool for a project I am working on, and I need to know how to map addresses of calling functions to the appropriate human-readable name. Is there a data structure in the kernel that I can access to achieve this? Or can I reference a load map (in days gone by, I used to refer to this as a link-edit map) given the load address of the program? Where can I find the load address of the program? Thanks Tom Collins - 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: Is it possible to read NTFS5 in the future?
At 13:17 01/06/01, Liu Wen wrote: >NTFS5 is really an efficient filesystem under Windows 2000. I have a 12G >data partition kept as FAT32 just in order to use it under Linux. But I >am thinking of converting it to NTFS,which would be very inconvinient >to use Linux. How about the kernel developing project to work on NTFS? Using the at least kernel 2.4.4-ac18 (note you have to use -ac kernels at the moment) you should be fine accessing Win2k NTFS volumes from Linux READ-ONLY. Only the advanced Win2k NTFS features like reparse points, quota, etc. will not work under linux as of now. As of the moment write support for NTFS is still EXTREMELY DANGEROUS, especially under Win2k, so you better not do it unless you are participating in NTFS development on Linux and have backups... So basically NTFS is under development. There is no need for yet another NTFS project. Just join ours if you are interested: http://sf.net/projects/linux-ntfs Anton -- "Nothing succeeds like success." - Alexandre Dumas -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis
Jeff Garzik writes: > For your HA application specifically, right now, I would suggest making > sure your net driver calls netif_carrier_xxx correctly, then checking > for IFF_RUNNING interface flag. IFF_RUNNING will disappear if the > interface is up, but there is no carrier [as according to > netif_carrier_ok]. Don't such HA apps need to run as root anyways? Regardless, I agree that, long term, the way to do this is via netlink. Later, David S. Miller [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/
2.2.19 SMP - timing problems
After adding second CPU to my server, I get the following strange behavior: earth:/home/czajnik# ping -s 1 213.25.174.24 PING 213.25.174.24 (213.25.174.24): 1 data bytes 10008 bytes from 213.25.174.24: icmp_seq=0 ttl=255 time=10551.5 ms 10008 bytes from 213.25.174.24: icmp_seq=6 ttl=255 time=535.8 ms 10008 bytes from 213.25.174.24: icmp_seq=7 ttl=255 time=660.6 ms 10008 bytes from 213.25.174.24: icmp_seq=8 ttl=255 time=18.1 ms 10008 bytes from 213.25.174.24: icmp_seq=9 ttl=255 time=9890.6 ms 10008 bytes from 213.25.174.24: icmp_seq=10 ttl=255 time=9765.5 ms 10008 bytes from 213.25.174.24: icmp_seq=11 ttl=255 time=1160.6 ms 10008 bytes from 213.25.174.24: icmp_seq=12 ttl=255 time=1285.6 ms 10008 bytes from 213.25.174.24: icmp_seq=13 ttl=255 time=1410.6 ms Every ping comes back in below one second, it seems to be a problem with time measurement. It started to happen after adding second CPU. We use 2.2.19 + Openwall patch + new AIC7xxx drivers + latest ReiserFS What can It be ? How can I do any tests ? -=Czaj-nick=- - 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: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis
Bogdan Costescu wrote:
> No way! If I implement a HA application which 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.
To tangent a little bit, and add netdev to the CC...
The loss and regain of link status should be proactively signalled to
userspace using netlink or something similar. Currently we have
netif_carrier_{on,off,ok} but it is only passively checked.
netif_carrier_{on,off} should probably schedule_task() to fire off a
netlink message...
For your HA application specifically, right now, I would suggest making
sure your net driver calls netif_carrier_xxx correctly, then checking
for IFF_RUNNING interface flag. IFF_RUNNING will disappear if the
interface is up, but there is no carrier [as according to
netif_carrier_ok].
--
Jeff Garzik | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
-
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: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis
On Fri, 1 Jun 2001, Alan Cox wrote: > I am sure that to an unpriviledged application reporting back the same result > as we saw last time we asked the hardware unless it is over 30 seconds old > will work fine. Maybe 10 for link partner ? No way! If I implement a HA application which 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, 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-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/
[NEW ISDN DRIVER] TurboPAM isdn card
Hi, I've wrote a driver for the ISDN active card TurboPAM made by Auvertech: http://www.auvertech.fr This is a card targeted at ISPs / access providers, supporting up to 30 B-channel connections simultaneously. The patch is available against Linux 2.4.5 and 2.2.19. Since it is rather big, I won't post it here but just give the URL: http://download.alcove-labs.org/software/tpam/tpam-2.4.5.patch.bz2 and http://download.alcove-labs.org/software/tpam/tpam-2.2.19.patch.bz2 Please apply. Thanks, Stelian. -- Stelian Pop <[EMAIL PROTECTED]> |- Ingénieur Informatique Libre --| | Alcôve - http://www.alcove.com - Tel: +33 1 49 22 68 00 | |--- Alcôve, l'informatique est libre | - 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: Configure.help is complete
On Fri, Jun 01, 2001 at 08:43:58AM -0400, Phil Auld wrote: > Alexander Viro wrote: > > ...snip... > > > > > We should start removing the crap from procfs in 2.5. Documenting shit is > > a good step, but taking it out would be better. > > > > Not to open a what may be can of worms but ... > > What's wrong with procfs? Imho, a procfs should be for process-information, nothing else. The procfs in its current form, while useful, is something horrible that should be taken out on the backyard and shot using slugs. Ehrmmm. No, but seriously, the non-process stuff should be separate from the procfs. Maybe call it kernfs or whatever. > It allows a general interface to the kernel that does not require new > syscalls/ioctls and can be accessed from user space without specifically > compiled programs. You can use shell scripts, java, command line etc. Yes, and it's also totally non standardised. /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] support for Cobalt Networks (x86 only) systems (for realthis
> Only some of them can be cached... (some of the MIIs in some drivers > are already cached, in fact) you can't cache stuff like what your link > partner is advertising at the moment, or what your battery status is at > the moment. I am sure that to an unpriviledged application reporting back the same result as we saw last time we asked the hardware unless it is over 30 seconds old will work fine. Maybe 10 for link partner ? - 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: [PATCH] support for Cobalt Networks (x86 only) systems (for realthis
Alan Cox wrote: > > In both of these situations, calling the ioctls without priveleges is > > quite useful, so maybe rate-limiting for ioctls and proc files like this > > would be a good idea in general. > Many of them (like the MII and APM ones) the result can be cached Only some of them can be cached... (some of the MIIs in some drivers are already cached, in fact) you can't cache stuff like what your link partner is advertising at the moment, or what your battery status is at the moment. -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - 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: [PATCH] support for Cobalt Networks (x86 only) systems (for realthis
> In both of these situations, calling the ioctls without priveleges is > quite useful, so maybe rate-limiting for ioctls and proc files like this > would be a good idea in general. Many of them (like the MII and APM ones) the result can be cached - 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: Configure.help is complete
Alexander Viro wrote: ...snip... > > We should start removing the crap from procfs in 2.5. Documenting shit is > a good step, but taking it out would be better. > Not to open a what may be can of worms but ... What's wrong with procfs? It allows a general interface to the kernel that does not require new syscalls/ioctls and can be accessed from user space without specifically compiled programs. You can use shell scripts, java, command line etc. Cheers, Phil -- Philip R. Auld, Ph.D. Technical Staff Egenera Corp.[EMAIL PROTECTED] 165 Forest St, Marlboro, MA 01752(508)786-9444 - 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: USB mouse wheel breakage was Re: Linux 2.4.5-ac5
On 01 Jun 2001 10:57:17 +0100, Michael wrote: > On Wed, May 30, 2001 at 09:30:39PM +0100, Alan Cox wrote: > > 2.4.5-ac4 > > o Update USB hid drivers (Vojtech Pavlik) > > I think these changes have broken my USB wheel mouse. > > Events seems to be getting lost (/dev/input/mice) > > It only scrolls when either the scroll direction has changed or if other > mouse events occur (e.g. you need to wiggle mouse from side to side to > scroll down a long page in mozilla) > > problems seems to be in drivers/usb/hid-core.c hid_input_field line 772 ive noticed the same problem -- mouse movement itself is even jerky, so i suspect events are being lost. the mouse is not really even usable for me in X. i too traced the problem down to hid-core.c, i think, and i am going to try to write up a patch against the latest ac, but the Maintainer may already realize the problem? -- Robert M. Love [EMAIL PROTECTED] [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/
Problem with kernel 2.2.19 Ultra-DMA and SMP
Hi Andre, I just wrote this Email but I had an old address to Suse. I have some problems with Ultra-DMA and SMP and don't know if I did something wrong of their are known problems. - On 1st of June 2001 Magnus Sandberg wrote; - To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] From: Magnus Sandberg <[EMAIL PROTECTED]> Subject: Problem with kernel 2.2.19 Ultra-DMA and SMP Date: Fri, 01 Jun 2001 13:55:02 +0200 Hi, I need some help with Linux kernel 2.2.19. I added Andre Hidrick's IDE-patch to get Ultra-DMA for my IDE disk. That kernel has worked for a month. Yesterday I decided to activate SMP to really use both of the CPUs in the system. That didn't work. The system hangs during boot phase, no oops or other error messages, just a silent stop. First of all I have a question, should SMP work with Hidrick's IDE-patch? If so, what could be wrong? For the moment I don't have to much information to give to you, but I can get what ever you want when I get back home from work. I compiled the none-SMP kernel at 22nd of April, which means that the IDE-patch must be older than that. I run a Debian 2.2 (Potato) system. The motherboard is a Micro Star 694D-Pro with two PIII-850 CPUs, 256 MB RAM, etc. The only information I have for the moment is a "dmesg" output from my non-SMP functional kernel and two .config from /usr/src/linux/ one from the functional none-SMP and the other for the problematic SMP-version. Of cause the dmesg outputs differ depending on the kernel type but I have inserted a pointer that show where the SMP-kernel friezes. As the kernel friezes I have to write don't the output by hand and I din't have the time to do it yesterday evening. Linux version 2.2.19 (root@debian) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #2 Sun Apr 22 21:21:38 CEST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009f000 @ (usable) BIOS-e820: 0fef @ 0010 (usable) Detected 801838 kHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1599.07 BogoMIPS Memory: 257840k/262080k available (932k kernel code, 412k reserved, 2824k data, 72k init) Dentry hash table entries: 32768 (order 6, 256k) Buffer cache hash table entries: 262144 (order 8, 1024k) Page cache hash table entries: 65536 (order 6, 256k) VFS: Diskquotas version dquot_6.4.0 initialized Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. 256K L2 cache (8 way) CPU: L2 Cache: 256K CPU: Intel Pentium III (Coppermine) stepping 03 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfb2d0 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 262144 bhash 65536) Starting kswapd v 1.5 Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured Real Time Clock Driver v1.09 RAM disk driver initialized: 16 RAM disks of 4096K size loop: registered device at major 7 Uniform Multi-Platform E-IDE driver Revision: 6.30 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio PDC20265: IDE controller on PCI bus 00 dev 60 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide1: BM-DMA at 0xdc00-0xdc07, BIOS settings: hdc:DMA, hdd:pio ide2: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hde:pio, hdf:pio hda: FUJITSU MPG3102AH, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 -> Silent stop when trying SMP hda: FUJITSU MPG3102AH, 9541MB w/2048kB Cache, CHS=1216/255/63, UDMA(66) Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 md driver 0.36.6 MAX_MD_DEV=4, MAX_REAL=8 Partition check: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 > apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13) VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 72k freed NET4: Unix domain sockets 1.0 for Linux NET4.0. Adding Swap: 498004k swap-space (priority -1) rtl8139.c:v1.07 5/6/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html eth0: RealTek RTL8139 Fast Ethernet at 0xe800, IRQ 11, 00:48:54:53:a2:fa. ncr53c8xx: at PCI bus 0, device 17, function 0 ncr53c8xx: 53c810 detected ncr53c810-0: rev 0x2 on pci bus 0 device 17 function 0 irq 15 ncr53c810-0: ID 7, Fast-10, Parity Checking scsi0 : ncr53c8xx
BUG: kernel-2.4.5: "Flags; bus-master 1, dirty ..."
Hi! Sometimes syslog suddenly starts to log a lot of messages, an example is included. So far I get the impression that this is vortex related (I do have a 3c905b). Rolf ... May 28 23:15:25 linux06 kernel: Flags; bus-master 1, dirty 15505(1) current 15505(1) May 28 23:15:25 linux06 kernel: Transmit list vs. ce44a240. May 28 23:15:25 linux06 kernel: 0: @ce44a200 length 85ea status 800105ea May 28 23:15:25 linux06 kernel: 1: @ce44a240 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 2: @ce44a280 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 3: @ce44a2c0 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 4: @ce44a300 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 5: @ce44a340 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 6: @ce44a380 length 80de status 000100de May 28 23:15:25 linux06 kernel: 7: @ce44a3c0 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 8: @ce44a400 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 9: @ce44a440 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 10: @ce44a480 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 11: @ce44a4c0 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 12: @ce44a500 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 13: @ce44a540 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 14: @ce44a580 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 15: @ce44a5c0 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: Flags; bus-master 1, dirty 15515(11) current 15515(11) May 28 23:15:25 linux06 kernel: Transmit list vs. ce44a4c0. May 28 23:15:25 linux06 kernel: 0: @ce44a200 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 1: @ce44a240 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 2: @ce44a280 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 3: @ce44a2c0 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 4: @ce44a300 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 5: @ce44a340 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 6: @ce44a380 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 7: @ce44a3c0 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 8: @ce44a400 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 9: @ce44a440 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 10: @ce44a480 length 85ea status 800105ea May 28 23:15:25 linux06 kernel: 11: @ce44a4c0 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 12: @ce44a500 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 13: @ce44a540 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 14: @ce44a580 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 15: @ce44a5c0 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: Flags; bus-master 1, dirty 15551(15) current 15553(1) May 28 23:15:25 linux06 kernel: Transmit list vs. ce44a5c0. May 28 23:15:25 linux06 kernel: 0: @ce44a200 length 85ea status 800105ea May 28 23:15:25 linux06 kernel: 1: @ce44a240 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 2: @ce44a280 length 85ea status 000105ea May 28 23:15:25 linux06 kernel: 3: @ce44a2c0 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 4: @ce44a300 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 5: @ce44a340 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 6: @ce44a380 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 7: @ce44a3c0 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 8: @ce44a400 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 9: @ce44a440 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 10: @ce44a480 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 11: @ce44a4c0 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 12: @ce44a500 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 13: @ce44a540 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 14: @ce44a580 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 15: @ce44a5c0 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: Flags; bus-master 1, dirty 15557(5) current 15557(5) May 28 23:15:26 linux06 kernel: Transmit list vs. ce44a340. May 28 23:15:26 linux06 kernel: 0: @ce44a200 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 1: @ce44a240 length 85ea status 000105ea May 28 23:15:26 linux06 kernel: 2: @ce44a280 length 85ea status 000105ea May 28 23:15:26 linux06 kerne
[Fwd: Re: cs46xx bug in 2.4.5-ac5]
I've tried with ac6. Immediate cs46xx unloading now works. But problem with xmms still remains. Now instead single 'Unable to handle kernel NULL pointer...' i had flow of 'cs46xx: ERROR DAC count<0 or count > dmasize (-4160)' ( number in parenthesis may vary ). Such messages increases uptime on my machine to 2.00. Alan Cox wrote: > Wait for ac6, try that and let me know > - Good luck! Nicholas L. Nigay Jun 1 15:54:12 test kernel: cs46xx: cs46xx_init_module()+ Jun 1 15:54:12 test kernel: cs46xx: probe()+ Jun 1 15:54:12 test kernel: PCI: Found IRQ 10 for device 00:06.0 Jun 1 15:54:12 test kernel: PCI: The same IRQ used for device 00:10.0 Jun 1 15:54:12 test kernel: Crystal 4280/46xx + AC97 Audio, version 1.28.32, 15:30:57 Jun 1 2001 Jun 1 15:54:12 test kernel: cs46xx: Card found at 0xf410 and 0xf400, IRQ 10 Jun 1 15:54:12 test kernel: cs46xx: Unknown card (1013:4280) at 0xf410/0xf400, IRQ 10 Jun 1 15:54:12 test kernel: cs46xx: card=0xc6595000 card->ba0=0xc9138000 Jun 1 15:54:12 test kernel: cs46xx: card->ba1=0xc913b000 0xc913f000 0xc9144000 0xc914c000 Jun 1 15:54:12 test kernel: cs46xx: cs_hardware_init()+ Jun 1 15:54:13 test kernel: cs46xx: cs_ac97_init()+ Jun 1 15:54:13 test kernel: ac97_codec: AC97 Audio codec, id: 0x4352:0x5903 (Cirrus Logic CS4297) Jun 1 15:54:13 test kernel: cs46xx: cs_ac97_init() found codec 0 Jun 1 15:54:13 test kernel: cs46xx: cs_ac97_init() ac97_codec[0] set to 0xc6364d80 Jun 1 15:54:13 test kernel: cs46xx: cs_ac97_init()- 1 Jun 1 15:54:13 test kernel: cs46xx: cs_hardware_init()- 0 Jun 1 15:54:13 test kernel: cs46xx: probe() pm_register() failed (0x0). Jun 1 15:54:13 test kernel: cs46xx: probe()- device allocated successfully Jun 1 15:54:13 test kernel: cs46xx: cs46xx_init_module()- (0) Jun 1 15:54:27 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4096) Jun 1 15:54:34 test last message repeated 315 times Jun 1 15:54:34 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4160) Jun 1 15:54:34 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4032) Jun 1 15:54:34 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4096) Jun 1 15:54:34 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4224) Jun 1 15:54:34 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-3968) Jun 1 15:54:34 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4096) Jun 1 15:55:05 test last message repeated 1303 times Jun 1 15:55:15 test last message repeated 473 times Jun 1 15:55:16 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4160) Jun 1 15:55:16 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4224) Jun 1 15:55:16 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-3904) Jun 1 15:55:16 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4096) Jun 1 15:55:16 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4224) Jun 1 15:55:16 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-3968) Jun 1 15:55:16 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4096) Jun 1 15:55:27 test last message repeated 495 times Jun 1 15:55:27 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4160) Jun 1 15:55:27 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4032) Jun 1 15:55:27 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4096) Jun 1 15:55:58 test last message repeated 1305 times Jun 1 15:56:17 test last message repeated 841 times Jun 1 15:56:17 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4160) Jun 1 15:56:17 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4032) Jun 1 15:56:17 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4096) Jun 1 15:56:48 test last message repeated 1310 times Jun 1 15:57:05 test last message repeated 773 times Jun 1 15:57:06 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4416) Jun 1 15:57:06 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-3776) Jun 1 15:57:06 test kernel: cs46xx: ERROR DAC count<0 or count > dmasize (-4096) Jun 1 15:57:11 test last message repeated 248 times # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set # CONFIG_KMOD is not set # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BS
Re: [PATCH] support for Cobalt Networks (x86 only) systems (for realthis time)
Bogdan Costescu wrote: > > On Fri, 1 Jun 2001, Pete Zaitcev wrote: > > > > But, each time a user cats this proc file, the user is banging the > > > hardware. What happens when a malicious user forks off 100 processes to > > > continually cat this file? :) > > > > Nothing good, probably. Same story as /proc/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). And a malicious user calling those at a high rate is bound to get ugly. In both of these situations, calling the ioctls without priveleges is quite useful, so maybe rate-limiting for ioctls and proc files like this would be a good idea in general. Jeff -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - 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: Linux 2.4.5-ac6
ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.8-2.4.5-ac6.gz is available. - 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/
Is it possible to read NTFS5 in the future?
NTFS5 is really an efficient filesystem under Windows 2000. I have a 12G data partition kept as FAT32 just in order to use it under Linux. But I am thinking of converting it to NTFS,which would be very inconvinient to use Linux. How about the kernel developing project to work on NTFS? Regards Liu - 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: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)
On Fri, 1 Jun 2001, Pete Zaitcev wrote: > > But, each time a user cats this proc file, the user is banging the > > hardware. What happens when a malicious user forks off 100 processes to > > continually cat this file? :) > > Nothing good, probably. Same story as /proc/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 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-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: Linux 2.4.5-ac6
> Tt's still broken on r/w. R/o should be OK now. > > > o Move UFS file system to use dcache for metadata (Al Viro) > > What??? My error. I was pasting down the notes when you were talking about that bit on #kernel and forgot to take it out - 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/
Q: ip_build_and_send_pkt
Hello. I have a couple of questions about 2.4.5 IP layer and will be very grateful if someone will answer :) In net/ipv4/ip_output.c there is the function ip_build_and_send_pkt(). This function adds an IP header to given skbuff and sends it out. But it seems that the only place where this function is called is tcp_v4_send_synack() in tcp_ipv4.c. Questions: 1. What is the difference between tcp synack and other types of packets? Why tcp synack needs separate entry point in IP layer? 2. Is it really good to have such common name (ip_build_and_send_pkt) for this function? I'd say that function with this name pretends to be IP layer entry point for upper layer protocols. But it isn't? -- Alexey - 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: Linux 2.4.5-ac6
On Fri, 1 Jun 2001, Alan Cox wrote: > o Fix the cs46xx right this time (me) > o Further FATfs cleanup (OGAWA Hirofumi) > o ISDN PPP code cleanup, cvs tag update (Kai Germaschewski) > o Large amount of UFS file system cleanup (Al Viro) Tt's still broken on r/w. R/o should be OK now. > o Move UFS file system to use dcache for metadata (Al Viro) What??? - 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/
Linux 2.4.5-ac6
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org In terms of going through the code audit almost all the sound drivers still need fixing to lock against format changes during a read/write. Poll creating and starting a buffer as write does and also mmap during write, write during an mmap. 2.4.5-ac6 o Fix the cs46xx right this time (me) o Further FATfs cleanup (OGAWA Hirofumi) o ISDN PPP code cleanup, cvs tag update (Kai Germaschewski) o Large amount of UFS file system cleanup (Al Viro) o Move UFS file system to use dcache for metadata (Al Viro) o Fix endianness problems in FATfs(Petr Vandrovec) o Fix -ac quota crashes (Jan Kara) o Fix bluetooth out of memory handling(Greg Kroah-Hartmann) o Fix freevxfs readdir(Christoph Hellwig) o Fix freevxfs sign/unsigned issues (Christoph Hellwig) o Fix doctypos, other freevxfs cleanup(Christoph Hellwig) o Fix flush_dirty_buffers warning (J A Magallon) o Add Carlos Gorges to credits(Carlos Gorges) o Further atm cleanup fixes (kmalloc/signedness) (Mitchell Blank) o Fix hotplug variable in matroxfb(Petr Vandrovec) o Fix ns558 crash (Vojtech Pavlik) o Revert to Pete Zaitcev's khub locking (Pete Zaitcev) | It works for me, Johannes changes don't seem to o Fix usb Config.in breakage for input devices(Vojtech Pavlik) o Add another 3c509 ISAPnP id (Marcus Meissner) o Fix oopses and null checks on iphase(Mitchell Blank) o CS46xx update (Thomas Woller) o Fix mmap cornercase (Maciej Rozycki) o Tidy up aironet and saa9730 delay abuse(Andrzej Krzysztofowicz) o Force initial umask to be sane for broken (Andrew Tridgell) init programs o Teach CML1 to strip out from the (Eric Raymond) Configure.help o Resync with Eric's master Configure.help(Eric Raymond) o Revert FIOQSIZE o Fix missing copy_*_user in cosa driver (me) | From Stanford tools o Fix missing copy_*_user in eicon(me) + clean up ioctls a bit more | From Stanford tools o Fix use after free in lpbether (me) | From Stanford tools o Fix missing return in rose_dev (me) | From Stanford tools o Fix use after free in bpqether (me) | From Stanford tools 2.4.5-ac5 o Fix bug introduced in cs46xx/trident locking(me) o Fix reiserfs unload/exit locking race (Paul Mundt) o Miscellaneous small UML updates (Jeff Dike) o Further FAT cleanups(OGAWA Hirofumi) o Fix ext2fs oops following disk error(Andreas Dilger) o Optimise segment reloads, syscall path (Andi Kleen) o Clean up .byte abuse where asm is now known (Brian Gerst) by required tools o Fix eepro100 on 64bit machine bitops bug(Andrea Arcangeli) o Move the pagecache and pagemap_lru_lock to (Andrea Arcangeli) different cache lines o Clean up .byte abuse where asm is now known (Brian Gerst) by required tools o Fix user space dereference in bluetooth (me) | From Stanford tools o Fix user space dereference in sbc60wdt (me) | From Stanford tools o Fix user space dereference in mdc800(me) | From Stanford tools o Fix a rather wrong memset in nubus.c(Chris Peterson) o Remove fpu references from dmfe (Arjan van de Ven) o Fix spelling of Portuguese (Nerijus Baliunas) 2.4.5-ac4 o APIC parsing updates(Ingo Molnar) o Retry rather than losing I/O on an IDE DMA (Jens Axboe) timeout. o Add missing locking to cs46xx (Frank Davis) o Clean up sym53c416 and add PnP support (me) o Tidy up changelog in apm.c (Stephen Rothwell) o Update jffs2, remove abuse of kdev_t(David Woodhouse) o Fix oops on unplugging bluetooth(Greg Kroah-Hartmann) o Move stuff into bss on aironet4500 (Rasmus Andersen) o Fix up alpha oops output(George France) o Update SysKonnect PCI id list (Mirko Lindner) o Update SysKonnect GigE driver
USB mouse wheel breakage was Re: Linux 2.4.5-ac5
On Wed, May 30, 2001 at 09:30:39PM +0100, Alan Cox wrote:
> 2.4.5-ac4
> o Update USB hid drivers (Vojtech Pavlik)
I think these changes have broken my USB wheel mouse.
Events seems to be getting lost (/dev/input/mice)
It only scrolls when either the scroll direction has changed or if other
mouse events occur (e.g. you need to wiggle mouse from side to side to
scroll down a long page in mozilla)
problems seems to be in drivers/usb/hid-core.c hid_input_field line 772
for (n = 0; n < count; n++) {
if (HID_MAIN_ITEM_VARIABLE & field->flags) {
if ((field->flags & HID_MAIN_ITEM_RELATIVE) && !value[n])
continue;
The next 2 lines are dropping the scroll wheel events (which appear in the
input code as type:2, code: 8, value -1 or 1 depending on direction)
if (value[n] == field->value[n])
continue;
hid_process_event(hid, field, &field->usage[n], value[n]);
continue;
}
Works fine in ac3.
--
Michael.
-
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: [PATCH] sym53c8xx timer and smp fixes
Jeff wrote: > > so, this driver is mixed spinlocks and save/restore_flags? Any > chance this can be converted to all spinlocks? > It's spinlock for 2.2 and 2.4 kernels, and save_flags for 2.0. Tim, did you cc Gerard Roudier? He mainains the sym53c8xx driver. All mail archives strip the cc list :-( -- Manfred - 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/
cs46xx bug in 2.4.5-ac5
Hello. I have Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 1). xmms-1.2.5-pre1 worked fine with 2.4.4-ac11. Sound support is compiled as modules. After last kernel upgrade to 2.4.5-ac5 following problems occured. 1 xmms crashes with kernel message like "Unable to handle kernel NULL pointer ..." ( whole message in attached file ) 2 Even executed immediately after module loading following happens bash-2.04# rmmod cs46xx cs46xx: Device or resource busy cs46xx is loaded with cs_debuglevel=9 More information is in attached files. PS: If additional information would be necessary mail me directly since i was not subscribed to linux-kernel. - Good luck! Nicholas L. Nigay # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set # CONFIG_KMOD is not set # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_PM=y # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # CONFIG_PNPBIOS is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_RTNETLINK=y CONFIG_NETLINK=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y # CONFIG_IP_ROUTE_MULTIPATH is not set # CONFIG_IP_ROUTE_TOS is not set CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_ROUTE_LARGE_TABLES is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=y CONFIG_NET_IPGRE=y # CONFIG_NET_IPGRE_BROADCAST is not set CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y # CONFIG_IP_PIMSM_V2 is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_TCPMSS=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_UNCLEAN=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_MIRROR=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_TCPMSS=y # CO
Re: APIC problem or 3com 3c590 driver problem in smp kernel 2.4.x
On Thu, May 31, 2001 at 12:27:07PM -0400, Feng Xian wrote: > The driver for my pci device, I have the SA_SHIRQ set. What kind of PCI device do you have? I had this problem once with an PCI-Matchmaker[1] based board (for which we still have the wrong PCI-ID btw, but my patch was rejected twice...). > Actually what I am thinking it may be APIC support problem. I rebuild my > kernel to use single cpu without APIC support, my device and 3c905 both > work fine. they don't work for SMP kernel (APIC is by default enabled) > Then I configured my uni-processor kernel to enable the APIC support, my > device won't work with the 3c905, just exactly same as it behaves in the > SMP kernel. With 2.2 I also had this without APIC. I have been flooded with interrupts which have been intended for the Cyclone card (3c905B 100BaseTX), and exited the ISR quickly after querying the interrupt register of my Matchmaker board without any ACKing, but the Cyclone never got these interrupts anymore. But is doesn't seem to be a 3c905 based problem, as I have 11: 95772726 XT-PIC es1371, eth0, eth1 in /proc/interrupts where eth0 and eth1 are both Cyclones. Even the vga card has IRQ 11 assigned. So this is not really unknown ;-) Regards Ingo Oeser [1] class 0b40, vendor id: 10e8, device id: 807d -- To the systems programmer, users and applications serve only to provide a test load. - 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: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
> /dev/hda10/space1 reiserfsdefaults 1 2
/dev/sdb1 /var/log/LOGS reiserfs defaults 0 0
> strace umount /space1:
>
> open("/usr/lib/locale/en_US/LC_TIME", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=2441, ...}) = 0
> old_mmap(NULL, 2441, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001f000
> close(3)= 0
> open("/usr/lib/locale/en_US/LC_NUMERIC", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
> old_mmap(NULL, 44, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4002
> close(3)= 0
> open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=104804, ...}) = 0
> old_mmap(NULL, 104804, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40137000
> close(3)= 0
> SYS_199(0x40131ad8, 0, 0x40132760, 0x40130210, 0) = 0
> semop(1074993880, 0x40130210, 0)= 0
> brk(0x8056000) = 0x8056000
> readlink("/space1", 0xbfffe51c, 4095) = -1 EINVAL (Invalid argument)
> open("/etc/mtab", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=680, ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>0x40021000
> read(3, "/dev/hde1 / ext2 rw 0 0\nproc /pr"..., 4096) = 680
> read(3, "", 4096) = 0
> close(3)= 0
> munmap(0x40021000, 4096)= 0
> oldumount("/space1"
strace /sbin/umount /dev/sdb1
execve("/sbin/umount", ["/sbin/umount", "/dev/sdb1"], [/* 30 vars */]) = 0
brk(0) = 0x80500c0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40016000
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(0x3, 0xbfffedb4)= 0
old_mmap(NULL, 37548, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\264\323"..., 1024) = 1024
fstat64(0x3, 0xbfffedfc)= 0
old_mmap(NULL, 1116516, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40021000
mprotect(0x40128000, 39268, PROT_NONE) = 0
old_mmap(0x40128000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x106000)
= 0x40128000
old_mmap(0x4012e000, 14692, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x4012e000
close(3)= 0
munmap(0x40017000, 37548) = 0
getpid()= 421
brk(0) = 0x80500c0
brk(0x80500e8) = 0x80500e8
brk(0x8051000) = 0x8051000
SYS_199(0x4012ca58, 0, 0x4012d760, 0x4012b1f0, 0) = 0
semop(1074973272, 0x4012b1f0, 0)= 0
brk(0x8053000) = 0x8053000
readlink("/dev", 0xbfffe96c, 4095) = -1 EINVAL (Invalid argument)
readlink("/dev/sdb1", 0xbfffe96c, 4095) = -1 EINVAL (Invalid argument)
open("/etc/mtab", O_RDONLY|0x8000) = 3
fstat64(0x3, 0xb6ec)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40017000
read(3, "/dev/sda6 / ext2 rw 0 0\n/dev/sda"..., 4096) = 273
read(3, "", 4096) = 0
close(3)= 0
munmap(0x40017000, 4096)= 0
oldumount("/var/log/LOGS"
> and there it hangs. The kernel doesn't hang,
Ditto.
> but while 'mount' displays
> /space1 as mounted, ls /space1/ says nothing. df -m reveals:
>
> Filesystem 1M-blocks Used Available Use% Mounted on
> /dev/hda102015 907 1005 48% /space1
In my case:
- before umount:
root@logs2:/mnt# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda6 8130996 1356716 6354584 18% /
/dev/sda7 813099620 7711280 1% /spare
/dev/sda8 203847244 1933204 1% /home
/dev/sda9 2038472 41964 1891284 3% /tmp
/dev/sda1014016248 46444 13969804 1% /mnt
/dev/sdb1 35542688 32840 35509848 1% /mnt/log/LOGS
- after (unfinished od course) umount:
lech7@logs2:~$ df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda6 8130996 1356572 6354728 18% /
/dev/sda7 813099620 7711280 1% /spare
/dev/sda8 203847244 1933204 1% /home
/dev/sda9 2038472 41968 1891280 3% /tmp
/dev/sda1014016248 46540 13969708 1% /var
/dev/sdb1 14016248 46540 13969708 1% /var/log/LOGS
--
Leszek.
-- [EMAIL PROTECTED] 2:480/33.7 -- REAL programmers use INTEGERS --
-- speaking just for myself...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
Re: PATCH: tulip net driver update
On Fri, 1 Jun 2001, Jeff Garzik wrote: > tulip needs a small delay during rxtx restart. different optimization > patterns in newer gccs served to expose this bug which was previously > hidden, so random users might hit a lack-of-networking depending on the > speed of their machine, their compiler, etc. Grrr, hold off on applying, it needs a further update as reported by one test user. - 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: tulip net driver update
tulip needs a small delay during rxtx restart. different optimization
patterns in newer gccs served to expose this bug which was previously
hidden, so random users might hit a lack-of-networking depending on the
speed of their machine, their compiler, etc.
--
Jeff Garzik | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
Index: linux_2_4/drivers/net/tulip/21142.c
diff -u linux_2_4/drivers/net/tulip/21142.c:1.1.1.28
linux_2_4/drivers/net/tulip/21142.c:1.1.1.28.26.1
--- linux_2_4/drivers/net/tulip/21142.c:1.1.1.28Wed May 16 14:46:45 2001
+++ linux_2_4/drivers/net/tulip/21142.c Fri Jun 1 02:19:08 2001
@@ -84,7 +84,7 @@
tp->csr6 &= 0x00D5;
tp->csr6 |= new_csr6;
outl(0x0301, ioaddr + CSR12);
- tulip_restart_rxtx(tp, tp->csr6);
+ tulip_restart_rxtx(tp);
}
next_tick = 3*HZ;
}
@@ -117,7 +117,7 @@
udelay(100);
outl(csr14, ioaddr + CSR14);
tp->csr6 = 0x8242 | (tp->sym_advertise & 0x0040 ? FullDuplex : 0);
- tulip_outl_csr(tp, tp->csr6, CSR6);
+ outl(tp->csr6, ioaddr + CSR6);
if (tp->mtable && tp->mtable->csr15dir) {
outl(tp->mtable->csr15dir, ioaddr + CSR15);
outl(tp->mtable->csr15val, ioaddr + CSR15);
@@ -201,12 +201,12 @@
outl(1, ioaddr + CSR13);
}
#if 0 /* Restart shouldn't be
needed. */
- tulip_outl_csr(tp, tp->csr6 | csr6_sr, CSR6);
+ outl(tp->csr6 | RxOn, ioaddr + CSR6);
if (tulip_debug > 2)
printk(KERN_DEBUG "%s: Restarting Tx and Rx, CSR5 is
%8.8x.\n",
dev->name, inl(ioaddr + CSR5));
#endif
- tulip_outl_csr(tp, tp->csr6 | csr6_st | csr6_sr, CSR6);
+ tulip_start_rxtx(tp);
if (tulip_debug > 2)
printk(KERN_DEBUG "%s: Setting CSR6 %8.8x/%x CSR12 %8.8x.\n",
dev->name, tp->csr6, inl(ioaddr + CSR6),
@@ -252,7 +252,7 @@
tp->csr6 = 0x8386;
outl(0x0003FF7F, ioaddr + CSR14);
outl(0x0301, ioaddr + CSR12);
- tulip_restart_rxtx(tp, tp->csr6);
+ tulip_restart_rxtx(tp);
}
}
Index: linux_2_4/drivers/net/tulip/ChangeLog
diff -u linux_2_4/drivers/net/tulip/ChangeLog:1.1.1.11
linux_2_4/drivers/net/tulip/ChangeLog:1.1.1.11.20.1
--- linux_2_4/drivers/net/tulip/ChangeLog:1.1.1.11 Sat May 19 18:57:05 2001
+++ linux_2_4/drivers/net/tulip/ChangeLog Fri Jun 1 02:19:08 2001
@@ -1,3 +1,23 @@
+2001-06-01 Jeff Garzik <[EMAIL PROTECTED]>
+
+ * tulip.h:
+ - Remove tulip_outl_csr helper, redundant.
+ - Add tulip_start_rxtx inline helper.
+ - tulip_stop_rxtx helper: Add synchronization. Always use current
+ csr6 value, instead of tp->csr6 value or value passed as arg.
+ - tulip_restart_rxtx helper: Add synchronization. Always
+ use tp->csr6 for desired mode, not value passed as arg.
+ - New RxOn, TxOn, RxTx constants for csr6 modes.
+ - Remove now-redundant constants csr6_st, csr6_sr.
+
+ * 21142.c, interrupt.c, media.c, pnic.c, tulip_core.c:
+ Update for above rxtx helper changes.
+
+ * interrupt.c:
+ - whitespace cleanup around #ifdef CONFIG_NET_HW_FLOWCONTROL,
+ convert tabs to spaces.
+ - Move tp->stats.rx_missed_errors update outside the ifdef.
+
2001-05-18 Jeff Garzik <[EMAIL PROTECTED]>
* tulip_core.c: Added ethtool support.
Index: linux_2_4/drivers/net/tulip/interrupt.c
diff -u linux_2_4/drivers/net/tulip/interrupt.c:1.1.1.40
linux_2_4/drivers/net/tulip/interrupt.c:1.1.1.40.10.1
--- linux_2_4/drivers/net/tulip/interrupt.c:1.1.1.40Thu May 24 01:49:55 2001
+++ linux_2_4/drivers/net/tulip/interrupt.c Fri Jun 1 02:19:08 2001
@@ -418,7 +418,7 @@
printk(KERN_WARNING "%s: The transmitter
stopped."
" CSR5 is %x, CSR6 %x, new CSR6
%x.\n",
dev->name, csr5, inl(ioaddr +
CSR6), tp->csr6);
- tulip_restart_rxtx(tp, tp->csr6);
+ tulip_restart_rxtx(tp);
}
spin_unlock(&tp->lock);
}
@@ -434,7 +434,7 @@
else
tp->csr6 |= 0x0020; /* Store-n-forward. */
/* Restart the transmit process. */
- tulip_restart_rxtx(tp, tp->csr6);
+ tulip_restart_rxtx(tp);
outl(0, ioaddr + CSR1);
}
qlogicfc driver
My previous mail about Qlogic Fiber Channel driver didn't get so many attention. The QLogic support is like a wall. You can't use a normal e-mail. Instead of that you should use a http form. And the answer you get is anonymous and IMHO a standart one. "... Please check our site periodically for driver updates. QLogic CSG Product Support " I know that they have a working IP enhanced driver, DOCs are distributed under NDA and the IP-enhanced firmware also. What we have in the kernel today is a nearly broken driver with an obscure firmware. I believe that this situation only tell (lie) people "this card is supported under linux" and so they buy this hardware. That's what I've done. I'm ready to spend time to modify the driver but I'm not fluent in firmware microcode reading and I've not managed to find documentations. There's no maintener for it and Chris Loveland is unreachable. If somebody has a valid email address for Chris Loveland, Please send it to me. If somebody can give me a email address for a HUMAN person working for QLogic (I hate their e-support What about removing this driver ? Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: 2.4.4 Kernel Oops and ls+rm segfaults
Am Freitag, 1. Juni 2001 10:52 schrieb Alexander Viro: > On Fri, 1 Jun 2001, Gregor Jasny wrote: > > Can anyone tell me, where this oops came from? > > The machine is a HP NetServer II lc (EISA+PCI architecture). > > The distribution is a slackware 7.0 with parts of 7.1 and current. > > gcc: 2.95.4 20010319 (Debian prerelease) > > > > Pagecache corruption somewhere. > a) what filesystems do you have? > b) is the thing reproducable? a) pure ext2-fs (sometimes a mounted nfs) b) Not really. It happend with earlier kernel revisions, too. I alredy replaced the fs-utils and compiled the kernel at my workstation (with gcc-2.95.3) If it matters: we have the Compushack FDDI driver installed. It can be found at: http://hell.wh8.tu-dresden.de/~gjadm/csfddi-3.0.0-5.diff.gz Regards, -Gregor - 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: interrupt problem with MPS 1.4 / not with MPS 1.1 ?
On Thu, May 31, 2001 at 11:56:44AM -0700, Greg KH wrote: > Is the BIOS set to "Plug and Play supported OS" somewhere? If not, try > enabling it. > It wasn't set, but with it set there is no difference. Greetings, Jurriaan -- IF MICROSOFT BUILT CARS.. New seats would force everyone to have the same size butt. GNU/Linux 2.4.5-ac5 SMP/ReiserFS 2x1402 bogomips load av: 0.87 0.42 0.16 - 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: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
On Thu, May 31, 2001 at 05:04:50PM -0500, Jordan wrote:
> Alan Cox wrote:
> >
> > > I'm staying on 2.4.5-ac5 for whatever it's worth (putting my life on the
> > > line for the community? kidding...) and will report anything new. I will
> > > be on the lookout for later ac patches, 2.4.6 ... and hopefully anything
> > > anybody can share with me about this. I hope we'll see an end to these
> >
> > Can you tell me if 2.4.5-ac4 is ok. ac5 has a small 'obviously correct'
> > reiserfs module unload change that seems the first suspect
> >
> > 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/
>
> I have seen this same problem with unmounting in 2.4.5-ac5, it was
> perfectly fine in 2.4.5-ac3 and ac4. I would guess the module unload is
> what did it.
>
2.4.5-ac4 was fine, 2.4.5-ac5:
/space in /etc/fstab:
/dev/hda10 /space1 reiserfsdefaults 1 2
strace umount /space1:
open("/usr/lib/locale/en_US/LC_TIME", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2441, ...}) = 0
old_mmap(NULL, 2441, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001f000
close(3)= 0
open("/usr/lib/locale/en_US/LC_NUMERIC", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
old_mmap(NULL, 44, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4002
close(3)= 0
open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=104804, ...}) = 0
old_mmap(NULL, 104804, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40137000
close(3)= 0
SYS_199(0x40131ad8, 0, 0x40132760, 0x40130210, 0) = 0
semop(1074993880, 0x40130210, 0)= 0
brk(0x8056000) = 0x8056000
readlink("/space1", 0xbfffe51c, 4095) = -1 EINVAL (Invalid argument)
open("/etc/mtab", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=680, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40021000
read(3, "/dev/hde1 / ext2 rw 0 0\nproc /pr"..., 4096) = 680
read(3, "", 4096) = 0
close(3)= 0
munmap(0x40021000, 4096)= 0
oldumount("/space1"
and there it hangs. The kernel doesn't hang, but while 'mount' displays
/space1 as mounted, ls /space1/ says nothing. df -m reveals:
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/hda102015 907 1005 48% /space1
Good luck,
Jurriaan
--
The music in my heart I bore long after it was heard no more.
William Wordsworth
GNU/Linux 2.4.5-ac5 SMP/ReiserFS 2x1402 bogomips load av: 5.60 2.71 1.16
-
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: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)
> But, each time a user cats this proc file, the user is banging the > hardware. What happens when a malicious user forks off 100 processes to > continually cat this file? :) Nothing good, probably. Same story as /proc/apm, which only hits BIOS instead (and it's debateable what is better). > Security: don't you want CAP_RAW_IO or something before executing any of > these ioctls? Perhaps it's mode 600 in their distro... > bug: you can't hold a spinlock while you are sleeping in copy_from_user Yep... I meant to check for it but forgot. -- Pete - 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: 2.4.4 Kernel Oops and ls+rm segfaults
On Fri, 1 Jun 2001, Gregor Jasny wrote: > Hi! > > Can anyone tell me, where this oops came from? > The machine is a HP NetServer II lc (EISA+PCI architecture). > The distribution is a slackware 7.0 with parts of 7.1 and current. > gcc: 2.95.4 20010319 (Debian prerelease) > > I hope you can help me. Pagecache corruption somewhere. a) what filesystems do you have? b) is the thing reproducable? - 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: [PATCH] support for Cobalt Networks (x86 only) systems (for real this
> + /* setup osb4 i/o regions */
> + if ((reg = get_reg(OSB4_INDEX_PORT, OSB4_DATA_PORT, 0x20)))
> + request_region(reg, 4, "OSB4 (pm1a_evt_blk)");
Check request_region worked
> +static int
> +i2c_wait_for_smi(void)
Obvious question - why duplicate the i2c layer
> +/* device structure */
> +static struct miscdevice lcd_dev = {
> + COBALT_LCD_MINOR,
Is this an officially allocated minor ?
> + /* Get the current cursor position */
> +case LCD_Get_Cursor_Pos:
> +display.cursor_address = lcddev_read_inst();
> +display.cursor_address = display.cursor_address & 0x07F;
> +copy_to_user((struct lcd_display *)arg, &display, dlen);
Sleeping holding a spinlock
> +case LCD_Set_Cursor_Pos:
> +copy_from_user(&display, (struct lcd_display *)arg, dlen);
Ditto. Also should check the return and return -EFAULT if so
> +/* LED daemon sits on this, we wake it up once a key is pressed */
> +static ssize_t
> +cobalt_lcd_read(struct file *file, char *buf, size_t count, loff_t *ppos)
> +{
> + int buttons_now;
> + static atomic_t lcd_waiters = ATOMIC_INIT(0);
> +
> + if (atomic_read(&lcd_waiters) > 0)
> + return -EINVAL;
> + atomic_inc(&lcd_waiters);
Unsafe. Two people can execute the atomic_read before anyone executes
the atomic_inc. You probably want test_and_set_bit() or a semaphore
> + while (((buttons_now = button_pressed()) == 0) &&
> +!(signal_pending(current)))
> + {
> + current->state = TASK_INTERRUPTIBLE;
We have a set_ function for this.. ALso what stops an ioctl occuring at
the same instant ?
-
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/
2.4.4 Kernel Oops and ls+rm segfaults
Hi! Can anyone tell me, where this oops came from? The machine is a HP NetServer II lc (EISA+PCI architecture). The distribution is a slackware 7.0 with parts of 7.1 and current. gcc: 2.95.4 20010319 (Debian prerelease) I hope you can help me. Regards, -Gregor ksymoops 2.4.1 on i586 2.4.4-csfddi. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.4-csfddi/ (default) -m /boot/System.map-2.4.4-csfddi (specified) Unable to handle kernel paging request at virtual address c936d300 c0122d8c *pde = Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010087 eax: 338b95ef ebx: 01f954ba ecx: c1518000 edx: 0023 esi: c119fcdc edi: 0202 ebp: c105be90 esp: c1ea1ec4 ds: 0018 es: 0018 ss: 0018 Process rm (pid: 3877, stackpage=c1ea1000) Stack: c1518ba0 c1518360 c150dbc0 c105be90 c012e3d9 c119fcdc c1518ba0 c150dbc0 1000 c150dbc0 1000 0001 c012ce08 c105be90 c105be90 11c0 c5d264c4 c011d9fe c105be90 c1ea1f48 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 89 44 99 18 89 59 14 8b 56 14 8b 41 10 ff 49 10 39 d0 74 08 >>EIP; c0122d8c<= Trace; c012e3d9 Trace; c012ce08 Trace; c011d9fe Trace; c011dacc Trace; c013dda6 Trace; c013c398 Trace; c0136194 Trace; c013626b Trace; c858b8cc Trace; c0106ac3 Code; c0122d8c <_EIP>: Code; c0122d8c<= 0: 89 44 99 18 mov%eax,0x18(%ecx,%ebx,4) <= Code; c0122d90 4: 89 59 14 mov%ebx,0x14(%ecx) Code; c0122d93 7: 8b 56 14 mov0x14(%esi),%edx Code; c0122d96 a: 8b 41 10 mov0x10(%ecx),%eax Code; c0122d99 d: ff 49 10 decl 0x10(%ecx) Code; c0122d9c 10: 39 d0 cmp%edx,%eax Code; c0122d9e 12: 74 08 je 1c <_EIP+0x1c> c0122da8
Re: [PATCH] almost forgot this one
> Add a rwproc entry to the ide structure, for recalling what happened last > time! > > Please let me knwo if there are any problems with this patch (some of the > patches I sent earlier depend on this). Looks ok to me, but check with Andre - 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: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)
> From: Tim Hockin <[EMAIL PROTECTED]> > Date: Thu, 31 May 2001 23:57:48 -0700 (PDT) > > i2c framework is not used, I wonder why. Someone thought that > > it was too heavy perhaps? If so, I disagree. > > i2c is only in our stuff because the i2c core is not in the standard kernel > yet. As soon as it is, I will make cobalt_i2c* go away. I am puzzled by this comment. Did you look into drivers/i2c/? It certainly is a part of a stock kernel. The main user is the V4L, in drivers/media/video, but I think LM sensors use it too. -- Pete - 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: 2.4.5 VM
I don't know myself, (it sounds like other bigmem problems), but setting up a 2GB swap file is easy enough to test. :-) -Dave On Fri, Jun 01, 2001 at 10:29:39AM +0200, Marcin Kowalski wrote: > > I found this post of interest. I have 1.1 Gig of RAM but only 800mb of > Swap as I expect NOT to use that much memory... Could this be the cause of > the machines VERY erratic behaviour??? Kernel Panics, HUGE INOde and > Dcache ?? > > On Thu, 31 May 2001 [EMAIL PROTECTED] wrote: > > > > My system has 128 Meg of Swap and RAM. > > > > Linus 2.4.0 notes are quite clear that you need at least twice RAM of swap > > with 2.4. > > > > Marcelo is working to change that but right now you are running something > > explicitly explained as not going to work as you want - 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: sk_buff question
Emmanuel Varagnat <[EMAIL PROTECTED]> écrit : > I need to had a header to the data in the sk_buff. > But what to do if there is no enough space left at the head ? I assume "alloc+copy" isn't the expected answer, is it ? > I saw skb_copy_expand, but it gives me a new sk_buff. Is there > a way to expand the headroom and keep the pointer on the sk_buff ? pskb_expand_head maybe. -- Ueimor - 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: select() - Linux vs. BSD
On Tue, 29 May 2001, John Chris Wren wrote: > In BSD, select() states that when a time out occurs, > the bits passed to select will not be altered. > In Linux, which claims BSD compliancy for this > in the man page (but does not state either way > what will happen to the bits), zeros the users bit masks > when a timeout occurs. (i) "In BSD" - which one did you look at? 4.2? 4.3? 4.4? Details differ a bit. (ii) The Linux man page only says RETURN VALUE On success, select and pselect return the number of descriptors contained in the descriptor sets, which may be zero if the timeout expires before anything interesting happens. On error, -1 is returned, and errno is set appropriately; the sets and timeout become undefined, so do not rely on their contents after an error. That is, a wise programmer does not assume any particular value for the bits after a timeout. > Should the man pages be changed to reflect reality, They do reflect reality. > or select() fixed to act like BSD? No, select() is fine. dean gaudet answered: sounds like a man page bug. Shame on him for noticing man page bugs without cc'ing the man page maintainer! Fortunately however, I do not think anything is wrong here. But just to be sure I added a sentence to select.2: On BSD, when a timeout occurs, the file descriptor bits are not changed. Linux follows SUSv2 and sets the bit masks to zero upon a timeout. Andries - 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: [PATCH] sym53c8xx timer and smp fixes
Tim Hockin wrote:
> spinlock_t sym53c8xx_lock = SPIN_LOCK_UNLOCKED;
> +spinlock_t sym53c8xx_host_lock = SPIN_LOCK_UNLOCKED;
> #defineNCR_LOCK_DRIVER(flags) spin_lock_irqsave(&sym53c8xx_lock, flags)
> #defineNCR_UNLOCK_DRIVER(flags)
>spin_unlock_irqrestore(&sym53c8xx_lock,flags)
> +#defineNCR_LOCK_HOSTS(flags) spin_lock_irqsave(&sym53c8xx_host_lock,
>flags)
> +#defineNCR_UNLOCK_HOSTS(flags)
>spin_unlock_irqrestore(&sym53c8xx_host_lock,flags)
>
> #define NCR_INIT_LOCK_NCB(np) spin_lock_init(&np->smp_lock);
> #defineNCR_LOCK_NCB(np, flags)spin_lock_irqsave(&np->smp_lock, flags)
> @@ -650,6 +655,8 @@
>
> #defineNCR_LOCK_DRIVER(flags) do { save_flags(flags); cli(); } while (0)
> #defineNCR_UNLOCK_DRIVER(flags) do { restore_flags(flags); } while (0)
> +#defineNCR_LOCK_HOSTS(flags) do { save_flags(flags); cli(); } while (0)
> +#defineNCR_UNLOCK_HOSTS(flags) do { restore_flags(flags); } while (0)
>
> #defineNCR_INIT_LOCK_NCB(np) do { } while (0)
> #defineNCR_LOCK_NCB(np, flags)do { save_flags(flags); cli(); } while (0)
> @@ -695,7 +702,7 @@
so, this driver is mixed spinlocks and save/restore_flags? Any chance
this can be converted to all spinlocks?
> #ifdef SCSI_NCR_DYNAMIC_DMA_MAPPING
> - if (pci_set_dma_mask(pdev, (dma_addr_t) (0xUL))) {
> + if (!pci_dma_supported(pdev, (dma_addr_t) (0xUL))) {
totally wrong. you are going backwards.
--
Jeff Garzik | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
-
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: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)
Tim Hockin wrote:
> +int __init
> +cobalt_acpi_init(void)
> +{
> + int err, reg;
> + u16 addr;
> + unsigned long flags;
> +
> + if (cobt_is_5k()) {
> + /* setup osb4 i/o regions */
> + if ((reg = get_reg(OSB4_INDEX_PORT, OSB4_DATA_PORT, 0x20)))
> + request_region(reg, 4, "OSB4 (pm1a_evt_blk)");
> + if ((reg = get_reg(OSB4_INDEX_PORT, OSB4_DATA_PORT, 0x22)))
> + request_region(reg, 2, "OSB4 (pm1a_cnt_blk)");
> + if ((reg = get_reg(OSB4_INDEX_PORT, OSB4_DATA_PORT, 0x24)))
> + request_region(reg, 4, "OSB4 (pm_tmr_blk)");
> + if ((reg = get_reg(OSB4_INDEX_PORT, OSB4_DATA_PORT, 0x26)))
> + request_region(reg, 6, "OSB4 (p_cnt_blk)");
> + if ((reg = get_reg(OSB4_INDEX_PORT, OSB4_DATA_PORT, 0x28)))
> + request_region(reg, 8, "OSB4 (gpe0_blk)");
> + osb4_port = reg;
> +
> + spin_lock_irqsave(&cobalt_superio_lock, flags);
> +
> + /* superi/o -- select pm logical device and get base address */
> + outb(SUPERIO_LOGICAL_DEV, SUPERIO_INDEX_PORT);
> + outb(SUPERIO_DEV_PM, SUPERIO_DATA_PORT);
> + outb(SUPERIO_ADDR_HIGH, SUPERIO_INDEX_PORT);
> + addr = inb(SUPERIO_DATA_PORT) << 8;
> + outb(SUPERIO_ADDR_LOW, SUPERIO_INDEX_PORT);
> + addr |= inb(SUPERIO_DATA_PORT);
> + if (addr) {
> + /* get registers */
> + if ((reg = get_reg(addr, addr + 1, 0x08))) {
> + request_region(reg, 4, "SUPERIO (pm1_evt_blk)");
> + superio_port = reg;
> + }
> + if ((reg = get_reg(addr, addr + 1, 0x0c)))
> + request_region(reg, 2, "SUPERIO (pm1_cnt_blk)");
> + if ((reg = get_reg(addr, addr + 1, 0x0e)))
> + request_region(reg, 16, "SUPERIO (gpe_blk)");
need to check for request_region failure. since you have a lot of
request_region calls, you may want to consider breaking them out into a
separate function which returns success or failure, and handles details
of cleaning up after 4 request_regions succeed but the 5th one fails.
if (!request_region(region1))
goto out;
if (!request_region(region2))
goto cleanup_1;
if (!request_region(region3))
goto cleanup_2;
return 0;
cleanup_2:
release_region(region2);
cleanup_1:
release_region(region1);
out:
return -EBUSY;
> + /* setup an interrupt handler for an ACPI SCI */
> + err = request_irq(ACPI_IRQ, acpi_interrupt,
> + SA_SHIRQ, ACPI_NAME, (void *)ACPI_MAGIC);
> + if (err) {
> + EPRINTK("couldn't assign ACPI IRQ (%d)\n", ACPI_IRQ);
> + return -1;
> + }
return 'err' not -1 here?
> +bool 'Support for Cobalt Networks x86 servers' CONFIG_COBALT
> +
> +if [ "$CONFIG_COBALT" != "n" ]; then
> + bool 'Gen III (3000 series) system support' CONFIG_COBALT_GEN_III
> + bool 'Gen V (5000 series) system support' CONFIG_COBALT_GEN_V
> + bool 'Create legacy /proc files' CONFIG_COBALT_OLDPROC
> +
> + comment 'Cobalt hardware options'
> +
> + bool 'Front panel (LCD) support' CONFIG_COBALT_LCD
> + bool 'Software controlled LED support' CONFIG_COBALT_LED
> + bool 'Serial number support' CONFIG_COBALT_SERNUM
> + bool 'Watchdog timer support' CONFIG_COBALT_WDT
> + bool 'Thermal sensor support' CONFIG_COBALT_THERMAL
> + bool 'Fan tachometer support' CONFIG_COBALT_FANS
> + bool 'Disk drive ruler support' CONFIG_COBALT_RULER
> +fi
Style: s/bool '/bool ' /
> +#ifdef CONFIG_PROC_FS
> +#ifdef CONFIG_COBALT_OLDPROC
> + proc_faninfo = create_proc_read_entry("faninfo", S_IFREG | S_IRUGO,
> + NULL, fan_read_proc, NULL);
> +if (!proc_faninfo) {
> + EPRINTK("can't create /proc/faninfo\n");
> + }
> +#endif
> + proc_cfaninfo = create_proc_read_entry("faninfo", S_IFREG | S_IRUGO,
> + proc_cobalt, fan_read_proc, NULL);
> +if (!proc_cfaninfo) {
> + EPRINTK("can't create /proc/cobalt/faninfo\n");
> + }
> +#endif
> +
> + printk("Cobalt Networks fan tachometers v1.2\n");
> +
> + return 0;
> +}
S_IFREG|S_IRUGO is the default, so simply pass zero mode for this
behavior.
But, each time a user cats this proc file, the user is banging the
hardware. What happens when a malicious user forks off 100 processes to
continually cat this file? :)
> +/* various file operations we support for this driver */
> +static struct file_operations lcd_fops = {
> + read: cobalt_lcd_read,
> + ioctl: cobalt_lcd_ioctl,
Re: [CHECKER] 2.4.5-ac4 non-init functions calling init functions
On Wed, 30 May 2001, Dawson Engler wrote:
> Here are *uninspected* 2.4.5-ac4 results of a checker that warns when a
> non-__init function calls an __init function (suggested by
> [EMAIL PROTECTED]). There seem to be two cases:
>
> 1. The best case: the caller should actually be an __init function
> as well. This is a performance bug since it won't be freed.
>
> 2. The worst case: some random post-initialization routine
> calls an __init routine which can cause the kernel to go into
> hyperspace if the __init routine's code has been deleted.
>
> The current messages do not differentiate between these two cases. If these
> results are generally useful, I can fix up the checker, but as it now stands
> there shouldn't be that many false positives.
>
> Dawson
> MC linux bug database: http://hands.stanford.edu/linux
>
> /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/video/cyber2000fb.c:1548:cyberpro_probe:
>ERROR:INIT: non-init fn 'cyberpro_probe' calling init fn 'fb_find_mode'
[ I'm responding to this one only, woken up by Russell ]
But cyberpro_probe() is marked __devinit, so it's used during driver
initialization only.
And fb_find_mode() is special: it's indeed an __init function, but there's also
a special inline variant in , protected by #ifdef MODULE. So this
doesn't harm.
For clarification, fb_find_mode() finds a suitable video mode in the video mode
database (drivers/video/modedb.c). Since we don't want to waste memory, this
database is __initdata. To make life easier for the driver writers, they
can still use fb_find_mode() through the inline function, which knows only
about 640x480@60 Hz.
I guess the correct fix is to (re)implement __init for modules, then we can
link the whole modedb with every frame buffer device driver module...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)
General comments:
* Code looks really clean. Nice work.
* Use module_init/exit. I know, I know, you heard it before :)
* I dunno if Linus will take it as-is because he has been threatening to
stop taking PCI drives that use old-style PCI init for no good reason.
(he even made me change a driver that used old-style PCI init for a good
reason :))
* There is a ton of procfs stuff in there. I suppose !CONFIG_PROC_FS is
not a supported configuration on Cobalt? :)
Tim Hockin wrote:
> +/* this is essentially an exported function - it is in the hwif structs */
> +static int
> +ruler_busproc_fn(ide_hwif_t *hwif, int arg)
[...]
> + read_lock(&ruler_lock);
[...]
> + read_unlock(&ruler_lock);
Should this be read_lock_bh, since other uses are in a timer function or
_irqsave/restore?
> + /* The GPIO tied to the ID chip is on the PMU */
> + id_dev = pci_find_device(PCI_VENDOR_ID_AL,
> + PCI_DEVICE_ID_AL_M7101, NULL);
as mentioned earlier, pci_register_driver is preferred over "old style"
PCI.
> + spin_lock_irqsave(&cobalt_superio_lock, flags);
> + outb(SUPERIO_LOGICAL_DEV, SUPERIO_INDEX_PORT);
> + outb(SUPERIO_DEV_GPIO, SUPERIO_DATA_PORT);
> + outb(SUPERIO_ADDR_HIGH, SUPERIO_INDEX_PORT);
> + addr = inb(SUPERIO_DATA_PORT) << 8;
> + outb(SUPERIO_ADDR_LOW, SUPERIO_INDEX_PORT);
> + addr |= inb(SUPERIO_DATA_PORT);
> + spin_unlock_irqrestore(&cobalt_superio_lock, flags);
Nothing wrong here, just commenting that I wish other superio did this
sometimes in some cases... :)
> +static void __init
> +io_write_byte(unsigned char c)
> +{
> + int i;
> + unsigned long flags;
> +
> + save_flags(flags);
> +
> + for (i = 0; i < 8; i++, c >>= 1) {
> + cli();
> + if (c & 1) {
> + /* Transmit a 1 */
> + io_write(5);
> + udelay(80);
> + } else {
> + /* Transmit a 0 */
> + io_write(80);
> + udelay(10);
> + }
> + restore_flags(flags);
> + }
> +}
Can save/restore flags be replaced with a spinlock?
> + /* get version from CVS */
> + version = strchr("$Revision: 1.4 $", ':') + 2;
> + if (version) {
> + char *p;
> +
> + strncpy(vstring, version, sizeof(vstring));
> + if ((p = strchr(vstring, ' '))) {
> + *p = '\0';
> + }
> + } else {
> + strncpy(vstring, "unknown", sizeof(vstring));
> + }
ug :) It would be nice if this could be done at compile time
> + proc_serialnum = create_proc_read_entry("serialnumber", 0, NULL,
> + serialnum_read, NULL);
> + if (!proc_serialnum) {
> + EPRINTK("can't create /proc/serialnumber\n");
> + }
> +#endif
> + proc_chostid = create_proc_read_entry("hostid", 0, proc_cobalt,
> + hostid_read, NULL);
> + if (!proc_chostid) {
> + EPRINTK("can't create /proc/cobalt/hostid\n");
> + }
> + proc_cserialnum = create_proc_read_entry("serialnumber", 0,
> + proc_cobalt, serialnum_read, NULL);
> + if (!proc_cserialnum) {
> + EPRINTK("can't create /proc/cobalt/serialnumber\n");
security concern?
We disable CPU processor serial numbers on x86, maybe you want to make
everything except the output of /usr/bin/hostid priveleged?
> diff -ruN dist-2.4.5/drivers/cobalt/wdt.c cobalt-2.4.5/drivers/cobalt/wdt.c
> --- dist-2.4.5/drivers/cobalt/wdt.c Wed Dec 31 16:00:00 1969
> +++ cobalt-2.4.5/drivers/cobalt/wdt.c Thu May 31 14:32:15 2001
Shouldn't this be stored with other watchdog timers?
> diff -ruN dist-2.4.5/include/linux/cobalt-acpi.h
>cobalt-2.4.5/include/linux/cobalt-acpi.h
> --- dist-2.4.5/include/linux/cobalt-acpi.h Wed Dec 31 16:00:00 1969
> +++ cobalt-2.4.5/include/linux/cobalt-acpi.hThu May 31 14:33:16 2001
Another ACPI user... neat!
> +/* the root of /proc/cobalt */
> +extern struct proc_dir_entry *proc_cobalt;
I am wondering if some of this stuff can be a sysctl instead of
procfs???
> +
> +#endif
> diff -ruN dist-2.4.5/include/linux/cobalt-i2c.h
>cobalt-2.4.5/include/linux/cobalt-i2c.h
> --- dist-2.4.5/include/linux/cobalt-i2c.h Wed Dec 31 16:00:00 1969
> +++ cobalt-2.4.5/include/linux/cobalt-i2c.h Thu May 31 14:33:16 2001
Sometimes I wish for a directory structure with:
* arch-specific includes
* platform-specific includes
* generic core includes
Then we could put this stuff in include/cobalt/* or
platform/cobalt/include or somesuch.
> +extern cobt_sys_t cobt_type;
> +/* one for each major board-type - COBT_SUPPORT_* from */
> +#define cobt_is_raq3() (COBT_SUPPORT_GEN_III && cobt_type == COBT_RAQ3)
> +#
Re: [CHECKER] 2.4.5-ac4 security holes
> [BUG] looks really broken.
> /u2/engler/mc/oses/linux/2.4.5-ac4/fs/ioctl.c:108:sys_ioctl: ERROR:PARAM:70:108:
>Deref tainted var 'arg' (tainted from line 70)
Been meaning to dump that anyway so that was solved by the delete approach
- real bug
> [BUG] sure seems like it. In general, all 4 dereferences seem pretty bad.
> /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/net/wan/cosa.c:1049:cosa_download:
>ERROR:PARAM:1046:1049: Deref tainted var 'd' (tainted from line 1046)
> return -EPERM;
Fixed .. only available to root anyway
> /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/net/wan/cosa.c:1057:cosa_download:
>ERROR:PARAM:1046:1057: Deref tainted var 'd' (tainted from line 1046)
> return -EPERM;
> }
>
Ditto
> switch (cmd) {
> case SNDCTL_SYNTH_INFO:
> memcpy (&((char *) arg)[0], &wavefront_info,
Fixed
> [BUG] [RESURRECTED] Should be fixed in ac5, though.
> /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/isdn/eicon/linchr.c:128:do_ioctl:
>ERROR:PARAM:60:128: tainted var 'arg' (from line 60) used as arg 0 to 'DivasGetList'
Done (wasnt fixed in ac5)
-
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: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)
> > Off-hand I see old style initialization. Is it right for new driver? > > the old-style init is because it is an old driver. I want to do a full-on > rework, but haven't had the time. New-style init by itself shouldn't be hard to do, independent of a full re-work... > > 2. Spaces and tabs are mixed in funny ways, makes to cute effects > > when quoting diffs. > > I've tried to eliminate that when I see it - I'll give the diff a close > examination. Why not just run indent over the source before submitting. That will regularize this stuff, and ensure that you are close to Documentation/CodingStyle. Here is the command I use. The first two options are the only really importants ones... indent -kr -i8 -npsl -pcs -l100 -lc120 (line length is 100 because line length 72/75/80 winds up wrapping long printk and logic lines when typically the programmer didn't want them to be wrapped) -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - 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/
