Re: international patches from kerneli far behind
L Larssen <[EMAIL PROTECTED]> wrote: >At this moment the latest patches are 2.2.18.3 and 2.4.3.1 while the kernel at >now is at 2.2.19 and 2.4.5. I try and keep a crypto up-to-date with the latest ac-tree: www.bzimage.org/kernel-patches/v2.4/alan/v2.4.5/ currently: against 2.4.5-ac6 (268 kilobyte) Will make an entry in the main page of www.bzimage.org next week. Danny -- Holland Hosting www.hoho.nl [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: Highmem Bigmem question
[EMAIL PROTECTED] writes: > This is probably an FAQ, but I read the FAQ and its not in there. Odd. > I have a machine with 2G of memory. I compiled the kernel with the > 4G memory option. How much address space should each process be > able to address? 3 GB for user stuff, or 3.5 GB with a patch > Does this change if I use the 64G option? No. Don't do that. > I'm after 2.4 information. Right now I am running on a 2.2 kernel > and it looks like the user processes are limited to ~1G. This is not a kernel problem. Try a libc upgrade, or use some other way to allocate memory. At least sbrk() and mmap() can be used. - 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.5-ac6 and 2.4.4-ac11 boot fails with APIC timer
The message on the screen calibrating APIC timer . CPU clock speed is 1395.7390MHz ... host bus clock speed is 0. MHz cpu: 0, clocks: 0, slic: 0 Then nothing. I had to push the reset button at this point. ACPI and APM were disabled from the kernel config. This boot failure messages was obtained from Pentium4 board GB-450(?) from Intel, NVIDIA M64 video. Sound Blaster 128 PCI. Netgear PNIC fast ethernet The same kernel was able to boot up the other Pentium 4 board from Gigabyte flawlessly. So, it depends on the motherboard manufacturers. Regards to all. G. Hugh Song - 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/
Benchmarks for Linux kernel
Can please point me some nice benchmarks for linux kernel . Which tells the performance of following , under Linux Kernel :- 1. CPU 2. Bus 3. Cache 4. DMA 5. Interrupts and Exceptions 6. File Systems 7. FPU 8. forking and pthread (Process Management) 9. IDE 10. Ethernet 11. Memory Management 12. PCI 13. USB 14. Serial 15. Clocks and Timers 16. Sound 17. SMP 18. Virtual Memory Management 19. Networking 20. PCMCIA 21. RAID Thank you, Jaswinder. -- These are my opinions not 3Di. - 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: APIC problem or 3com 3c590 driver problem in smp kernel 2.4.x
It's our own's card. so it could be the card's problem. does the pci device have to do some special thing to support APIC? my card won't work properly on uni-processor with APIC enable kernel or smp kernel when the card is sharing IRQ with some other pci devices. Alex On Fri, 1 Jun 2001, Ingo Oeser wrote: > 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 > -- Feng Xian _o) .~. (o_ /\\ /V\ //\ _\_V// \\ V_/_ /( )\ ^^-^^ ALEX - 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/
Announce: Win2K LDM Docs (Logical Disk Manager)
Hi All, I'm pleased to announce the first version of the LDM Documentation. Windows 2000 introduced a new partitioning scheme and with it, the Logical Disk Manager. Like Linux's Logical Volume Manager is allows changes to partitioning, and volumes, to be made without rebooting. To create Mirrored, Spanned, Striped or RAID disks under Win2K, you must use their "Dynamic Disks". Unfortunately Linux cannot read these Dynamic Disks. Yet. The documentation, although only a first draft, contains enough information to locate and piece together the disks, partitions and volumes used by Win2K. The docs show the on-disk structures that make up the 1MB database at the end of the physical disk. The docs are available online at: http://linux-ntfs.sourceforge.net/ldm and to download at: http://sourceforge.net/project/showfiles.php?group_id=13956 Also, I've written a test program to dump the LDM information stored on a dynamic disk. It's available at: http://linux-ntfs.sourceforge.net/ldm/ldm.c If you have any questions, comments or additions, please email me. Thanks, FlatCap (Richard Russon) [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
> o Fix mmap cornercase (Maciej Rozycki) when i try running osf/1 netscape on alpha, mmap of libXmu fails. works fine on -ac5. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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: international patches from kerneli far behind
L Larssen wrote: > Sorry if this subject does not fit in this list. > I am a bit worried about the development of the international kernel patches > from kerneli.org. > > These patches are getting far behind on the real kernel distributions. > At this moment the latest patches are 2.2.18.3 and 2.4.3.1 while the kernel at > now is at 2.2.19 and 2.4.5. > > There is now news to the public why these patches are falling behind. > > I hope more people are consirned about this. International crypto patch is misdesigned and broken, period. Block device drivers are supposed handle varying transfer sizes, international crypto patch doesn't. Loop device transfers are supposed to be re-entrant, international crypto patch transfers are not. Summary: international crypto patch will corrupt your data. Avoid using it. If you don't want to play russian roulette with your data, you should consider using loop-AES package. loop-AES announcement is here: http://mail.nl.linux.org/linux-crypto/2001-05/msg3.html http://marc.theaimsgroup.com/?l=linux-crypto=98923954103730=2 Regards, Jari Ruusu <[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: Problem with kernel 2.2.19 Ultra-DMA and SMP, once more
:: If this is a VIA SMP system there are APIC problems that you :: do not want :: to even think about addressing. :: :: MPS1.1 and passing "noapic" will fix most of there mess, but :: you have a :: semi-crippled system, but it runs. Andre, I don't suppose these APIC problems are documented anywhere...? -- Juha, who's wrestling with a VIA 694X dualie mobo here. - 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/
More data on 2.4.5 VM issues
This is 2.4.5 with Andrea Arcangeli's aa1 patch compiled with himem: Why is kswapd using so much CPU? If you reboot the machine and run the same user process kswapd CPU usage is almost 0% and none of the swap is used. This machine was upgraded from 2.2 and we did not have the luxury of re-partitioning it support the "new" 2.4 swap size requirements. After running for a few days with relatively constant memory usage: vmstat: procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 2 0 1 136512 5408504 209744 0 0 0 2 1949 10 26 64 top: 5:38pm up 3 days, 19:44, 2 users, load average: 2.08, 2.13, 2.15 34 processes: 32 sleeping, 2 running, 0 zombie, 0 stopped CPU0 states: 16.0% user, 56.4% system, 16.2% nice, 26.3% idle CPU1 states: 11.1% user, 57.0% system, 11.0% nice, 31.3% idle Mem: 1028804K av, 1023744K used,5060K free, 0K shrd, 504K buff Swap: 136512K av, 136512K used, 0K free 209876K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 28442 root 18 10 898M 812M 36188 R N 56.0 80.9 296:12 gateway.smart.5 28438 root 16 10 898M 811M 35084 S N 43.7 80.7 291:03 gateway.smart.5 5 root 9 0 00 0 SW 37.6 0.0 164:58 kswapd 2509 root 18 0 492 492 300 R 2.5 0.0 0:00 top 1 root 9 0680 0 SW0.0 0.0 0:08 init 2 root 9 0 00 0 SW0.0 0.0 0:00 keventd 3 root 19 19 00 0 SWN 0.0 0.0 1:11 ksoftirqd_CPU0 4 root 19 19 00 0 SWN 0.0 0.0 1:04 ksoftirqd_CPU1 6 root 9 0 00 0 SW0.0 0.0 0:00 kreclaimd 7 root 9 0 00 0 SW0.0 0.0 0:00 bdflush 8 root 9 0 00 0 SW0.0 0.0 0:07 kupdated 11 root 9 0 00 0 SW0.0 0.0 0:00 scsi_eh_0 315 root 9 0 1000 0 SW0.0 0.0 0:00 syslogd Hope this helps - 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: cs4232 isapnp support
Hi,
> This adds ISAPnP support to cs4232.c.
[...]
> diff -u -r1.10 cs4232.c
> --- drivers/sound/cs4232.c2001/05/27 18:06:09 1.10
> +++ drivers/sound/cs4232.c2001/06/01 17:26:52
[...]
> @@ -318,22 +325,92 @@
> static int __initdata mpuirq = -1;
> static int __initdata synthio= -1;
> static int __initdata synthirq = -1;
> -
> +static int __initdata isapnp = 1;
According to the comment in include/linux/init.h these are incorrect:
* For initialized data:
* You should insert __initdata between the variable name and equal
* sign followed by value, e.g.:
*
* static int init_variable __initdata = 0;
* static char linux_logo[] __initdata = { 0x32, 0x36, ... };
*
AFAIR, moving the __initdata cause problems with some gcc versions.
Andrzej
-
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-ac5 locks on ReiserFS umount (ac4 doesn't)
Hi, Ken! > Try -ac6, this issue was discussed in depth on the list yesterday and > rehashed twice already today. Check the archives. Too bad that the changelog for -ac6 doesn't mention reiserfs, so I didn't bother trying it. Another problem is that the archive at http://www.uwsg.indiana.edu/hypermail/linux/kernel/ updates only once a day. I checked it and decided that my information could still be useful. I'd be grateful if somebody pointed me to a better archive. -- Regards, Pavel Roskin - 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: Problem with kernel 2.2.19 Ultra-DMA and SMP, once more
If this is a VIA SMP system there are APIC problems that you do not want to even think about addressing. MPS1.1 and passing "noapic" will fix most of there mess, but you have a semi-crippled system, but it runs. On Fri, 1 Jun 2001 [EMAIL PROTECTED] wrote: > Hi once more... > > I'm sorry for the layout of this mail. It is written in a web mail > system... > The attachements are in ASCII format even if the web-mail make it base-64 > > Now I have compiled a vanilla 2.2.19 kernel and have SMP working, without > Ultra-DMA. I used the functional kernel config from 2.2.19-ide and just > activated SMP. > > >From that I have 3 very simular kernel configurations: > 2.2.19 with Hidrick's IDE-patch, no SMP: working > 2.2.19 without IDE-patch, with SMP: working > 2.2.19 with IDE-patch and SMP: not booting > > With all the information I hope that someone can help me with the > IDE-and-SMP > problem. > > _\\|//_ > (-0-0-) > /---ooO-(_)-Ooo--\ > | Magnus SandbergEmail: [EMAIL PROTECTED] | > | Network Engineer, Bluelabs http://www.bluelabs.se/ | > | Phone: +46-8-470 2155(FAX: +46-8-470 2199)GSM: +46-708-225 805 | > \/ > || || > ooO Ooo Andre Hedrick ASL Kernel Development Linux ATA Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.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: [NFS] Re: [RFC] yet another knfsd-reiserfs patch
Hi Chris, Do you really need the parent inode in the filehandle? That screws rename up pretty badly, since the filehandle changes when you rename into a different directory. It means for instance that when I do open(foo) mv foo bar/ write (foo) close(foo) then I have a pretty good chance of getting an ESTALE on the write() statement. Cheers, Trond - 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, once more
Hi once more... I'm sorry for the layout of this mail. It is written in a web mail system... The attachements are in ASCII format even if the web-mail make it base-64 Now I have compiled a vanilla 2.2.19 kernel and have SMP working, without Ultra-DMA. I used the functional kernel config from 2.2.19-ide and just activated SMP. >From that I have 3 very simular kernel configurations: 2.2.19 with Hidrick's IDE-patch, no SMP: working 2.2.19 without IDE-patch, with SMP: working 2.2.19 with IDE-patch and SMP: not booting With all the information I hope that someone can help me with the IDE-and-SMP problem. _\\|//_ (-0-0-) /---ooO-(_)-Ooo--\ | Magnus SandbergEmail: [EMAIL PROTECTED] | | Network Engineer, Bluelabs http://www.bluelabs.se/ | | Phone: +46-8-470 2155(FAX: +46-8-470 2199)GSM: +46-708-225 805 | \/ || || ooO Ooo kernel-2.2.19_1st-smp-no_cleanup.config boot-log-2.2.19-smp-no_ide.txt
Re: New USB HID driver in -ac series
On 01 Jun 2001 14:35:44 -0400, Nathan Walp wrote: > I upgraded from 2.4.5-ac2 to 2.4.5-ac5 recently, and all seemed well. > However, I noticed that the scrollwheel on my mouse wasn't working very > well. I have been working on a patch all day, but can not figure it out. The problem is in the new hid-core.c. See the thread "USB mouse wheel breakage" for more information. I CC the last e-mail to the Maintainer, hopefully he can figure a solution. -- 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/
¡¯¯Â°Ó·~¿ì¤½«Ç¥X¯²¡¯
**
¯Â°Ó·~¿ì¤½«Ç¥X¯²
**
±MªùªA°È°Ó¥Î¿ì¤½«Ç¤§©Ó¯²¤H¡C
¥x¥_¦Uµ¥¯Å°Ó¥Î¿ì¤½«Ç®×¥ó¡A¾A¦X¦UºØ°Ó·~»Ý¨D¡I¡I
§Ú֦̾³ºZ³qªº¸ê°T¡B¦³«Ü¦h¥ß§Yn¥X¯²ªº¿ì¤½«Ç¡A¥¿µ¥«ÝµÛ±zªº¬D¿ï¡A
¤@©wn¬°±z§ä¨ì¤@³B³Ì¾A¦X±z¹ê²{±z¶¯¹Ï§§§Óªº³õ©Ò¡I¡I¡I¡I
°Ï°ì¡G
¤j¦w°Ï ¦p ¡G´°¤Æ«n¡B¥_¸ô¯Â¿ì¡A80¢w700©W¡I¡I
ªQ¤s°Ï ¦p ¡G«n¨ÊªF¸ô ¤T¡B¥|¬q¯Â¿ì 50¢w250©W ¡I¡I
«H¸q°Ï ¦p ¡G°ò¶©¸ô¤G¬q¡A«H¸q¸ô¤T¬q¯Â¿ì¡A¬Á¼þ±c¹õ¤j¼Ó¡C 30-280©W¡I¡I
¤¤¤s°Ï ¦p ¡Gªø¦wªF¸ô¡A¤¤¤s¥_¸ô¯Â¿ì 70¢w200©W ¡I¡I
ªA°È²Ä¤@¡A«~½è«OÃÒ¡CÅwªï¬¢¸ß.
·ç°T¤£°Ê²£ °Ó¥ò³¡
Ápµ¸¤H¡G³³¤p©j
TeL¡]¥Nªí¸¹¡^¡G 02-27548587
¦æ°Ê¹q¸Ü¡G0937063831
±zªºº¡·N¡A¬O§Ú̪º¦¨´N¡C
-
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
USB mouse wheel has been broke since 2.4.5-ac4 (when new USB HID, hid-core.c, was integrated). The mouse in general seems jerky, and specifically the input device does not receive events for consecutive wheel movements -- just the first "spin," until the mouse is moved again. obviously the bug is in the new hid-core.c, but I confirmed this by compiling with that part of the ac6 patch removed. I have since been trying to write a patch but I can not fix the problem, so I am reporting it to you. I and another user thought the problem was in hid_input_field, but upon looking I now think not. My mouse is fairly unusable in X, and unfortunately I can not figure out a fix. -- 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/
Re: [RFC] yet another knfsd-reiserfs patch
> On Monday, April 23, 2001 10:45:14 AM -0400 Chris Mason <[EMAIL PROTECTED]> wrote:
>
>>
>> Hi guys,
>>
>> This patch is not meant to replace Neil Brown's knfsd ops stuff, the
>> goal was to whip up something that had a chance of getting into 2.4.x,
>> and that might be usable by the AFS guys too. Neil's patch tries to
>> address a bunch of things that I didn't, and looks better for the
>> long run.
>>
>
Updated to 2.4.5, with the nfs list cc'd this time in hopes of comments
or flames...
-chris
diff -Nru a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
--- a/fs/nfsd/nfsfh.c Fri Jun 1 16:08:41 2001
+++ b/fs/nfsd/nfsfh.c Fri Jun 1 16:08:41 2001
@@ -116,40 +116,12 @@
return error;
}
-/* this should be provided by each filesystem in an nfsd_operations interface as
- * iget isn't really the right interface
- */
-static struct dentry *nfsd_iget(struct super_block *sb, unsigned long ino, __u32
generation)
+static struct dentry *dentry_from_inode(struct inode *inode)
{
-
- /* iget isn't really right if the inode is currently unallocated!!
-* This should really all be done inside each filesystem
-*
-* ext2fs' read_inode has been strengthed to return a bad_inode if the inode
-* had been deleted.
-*
-* Currently we don't know the generation for parent directory, so a generation
-* of 0 means "accept any"
-*/
- struct inode *inode;
struct list_head *lp;
struct dentry *result;
- inode = iget(sb, ino);
- if (is_bad_inode(inode)
- || (generation && inode->i_generation != generation)
- ) {
- /* we didn't find the right inode.. */
- dprintk("fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n",
- inode->i_ino,
- inode->i_nlink, atomic_read(>i_count),
- inode->i_generation,
- generation);
-
- iput(inode);
- return ERR_PTR(-ESTALE);
- }
- /* now to find a dentry.
-* If possible, get a well-connected one
+ /*
+* If possible, get a well-connected dentry
*/
spin_lock(_lock);
for (lp = inode->i_dentry.next; lp != >i_dentry ; lp=lp->next) {
@@ -173,6 +145,92 @@
return result;
}
+static struct inode *__inode_from_fh(struct super_block *sb, int ino,
+int generation)
+{
+ struct inode *inode ;
+
+ inode = iget(sb, ino);
+ if (is_bad_inode(inode)
+ || (generation && inode->i_generation != generation)
+ ) {
+ /* we didn't find the right inode.. */
+ dprintk("fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n",
+ inode->i_ino,
+ inode->i_nlink, atomic_read(>i_count),
+ inode->i_generation,
+ generation);
+
+ iput(inode);
+ return ERR_PTR(-ESTALE);
+ }
+ return inode ;
+}
+
+static struct inode *inode_from_fh(struct super_block *sb,
+ __u32 *datap,
+ int len)
+{
+ if (sb->s_op->inode_from_fh)
+ return sb->s_op->inode_from_fh(sb, datap, len) ;
+ return __inode_from_fh(sb, datap[0], datap[1]) ;
+}
+
+static struct inode *parent_from_fh(struct super_block *sb,
+ __u32 *datap,
+ int len)
+{
+ if (sb->s_op->parent_from_fh)
+ return sb->s_op->parent_from_fh(sb, datap, len) ;
+
+ if (len >= 3)
+ return __inode_from_fh(sb, datap[2], 0) ;
+ return ERR_PTR(-ESTALE);
+}
+
+/*
+ * two iget funcs, one for inode, and one for parent directory
+ *
+ * this should be provided by each filesystem in an nfsd_operations interface as
+ * iget isn't really the right interface
+ *
+ * If the filesystem doesn't provide funcs to get inodes from datap,
+ * it must be: inum, generation, dir inum. Length of 2 means the
+ * dir inum isn't there.
+ *
+ * iget isn't really right if the inode is currently unallocated!!
+ * This should really all be done inside each filesystem
+ *
+ * ext2fs' read_inode has been strengthed to return a bad_inode if the inode
+ * had been deleted.
+ *
+ * Currently we don't know the generation for parent directory, so a generation
+ * of 0 means "accept any"
+ */
+static struct dentry *nfsd_iget(struct super_block *sb, __u32 *datap, int len)
+{
+
+ struct inode *inode;
+
+ inode = inode_from_fh(sb, datap, len) ;
+ if (IS_ERR(inode)) {
+ return ERR_PTR(PTR_ERR(inode)) ;
+ }
+ return dentry_from_inode(inode) ;
+}
+
+static struct dentry *nfsd_parent_iget(struct super_block *sb, __u32 *datap,
+
Re: HowTo: Kernel verbose logging.
On Fri, Jun 01, 2001 at 04:51:27PM +0200, Ola Theander wrote: > Therefore I would like to know if it's possible to compile the used kernel > (2.2.18) in some kind of verbose logging mode? Ultimately every kernel call > should be logged, with parameters and everything. I realize that this > probably isn't feasible but perhaps there is something that takes me > halfway? You probably want strace, see man strace. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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 USB HID driver in -ac series
I upgraded from 2.4.5-ac2 to 2.4.5-ac5 recently, and all seemed well. However, I noticed that the scrollwheel on my mouse wasn't working very well. I have that new Logitech cordless optical mouse, so my first thought was that the batteries were low, but it was late at night, and I didn't have spares, so I just dealt with it. I got new batteries, and the problem didn't go away. Booted into windows, and the scrollwheel worked fine. I then remembered seeing the HID drivers in Alan's changelog. I booted back into -ac2, and the scrollwheel worked fine. -ac5 and -ac6 both show this problem, and I assume every kernel since the HID driver update has it as well. Here's the contents of /proc/bus/usb/devices: T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 11/900 us ( 1%), #Int= 1, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d000 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=058f ProdID=9254 Rev= 1.00 S: Manufacturer=ALCOR S: Product=Generic USB Hub C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc=118/900 us (13%), #Int= 1, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d400 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=046d ProdID=c501 Rev= 9.10 S: Manufacturer=Logitech S: Product=USB Receiver C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 50mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=hid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl= 10ms Hope this is of some help Nathan -- Nathan Walp || [EMAIL PROTECTED] GPG Fingerprint:|| http://faceprint.com/ 5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E PGP signature
[PATCH] Re: interrupt problem with MPS 1.4 / not with MPS 1.1 ?
Does this patch fix things for you, such that MPS 1.1 and MPS 1.4 both
work?
--
Jeff Garzik | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
diff -urN linux-2.4.5/drivers/pci/quirks.c linux.viairq/drivers/pci/quirks.c
--- linux-2.4.5/drivers/pci/quirks.cSat May 19 20:43:06 2001
+++ linux.viairq/drivers/pci/quirks.c Fri Jun 1 16:33:21 2001
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#undef DEBUG
@@ -267,6 +268,8 @@
/*
* VIA 686A/B: If an IO-APIC is active, we need to route all on-chip
* devices to the external APIC.
+ *
+ * TODO: this should be done at IRQ assign time (pci_enable_device call)
*/
static void __init quirk_via_ioapic(struct pci_dev *dev)
{
@@ -277,6 +280,8 @@
else
tmp = 0x1f; /* all known bits (4-0) routed to external APIC */
+ printk(KERN_INFO "PCI: Setting Via APIC control\n");
+
/* Offset 0x58: External APIC IRQ output control */
pci_write_config_byte (dev, 0x58, tmp);
}
@@ -285,6 +290,35 @@
/*
+ * Via 686A/B: The PCI_INTERRUPT_LINE register for the on-chip
+ * devices, USB0/1, AC97, MC97, and ACPI, has an unusual feature:
+ * when written, it makes an internal connection to the PIC.
+ * For these devices, this register is defined to be 4 bits wide.
+ * Normally this is fine. However for IO-APIC motherboards, or
+ * non-x86 architectures (yes Via exists on PPC among other places),
+ * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
+ * interrupts delivered properly.
+ *
+ * TODO: this should be done at IRQ assign time (pci_enable_device call)
+ */
+static void __init quirk_via_irqpic(struct pci_dev *dev)
+{
+ u8 tmp;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, );
+if ((tmp & 0x0F) != dev->irq) {
+ printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d to %d\n",
+ dev->slot_name, tmp, (tmp & 0xF0) | dev->irq);
+udelay (15);
+
+tmp &= 0xF0;
+tmp |= dev->irq;
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, tmp);
+ }
+}
+
+
+/*
* PIIX3 USB: We have to disable USB interrupts that are
* hardwired to PIRQD# and may be shared with an
* external device.
@@ -372,6 +406,11 @@
#ifdef CONFIG_X86_IO_APIC
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686,
quirk_via_ioapic },
#endif
+
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2,
+ quirk_via_irqpic },
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4,
+ quirk_via_irqpic },
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
+ quirk_via_irqpic },
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_6,
+ quirk_via_irqpic },
{ 0 }
};
diff -urN linux-2.4.5/drivers/sound/via82cxxx_audio.c
linux.viairq/drivers/sound/via82cxxx_audio.c
--- linux-2.4.5/drivers/sound/via82cxxx_audio.c Tue May 1 19:05:00 2001
+++ linux.viairq/drivers/sound/via82cxxx_audio.cFri Jun 1 16:32:25 2001
@@ -3012,7 +3012,6 @@
{
int rc;
struct via_info *card;
- u8 tmp;
static int printed_version = 0;
DPRINTK ("ENTER\n");
@@ -3107,19 +3106,6 @@
if (rc) {
printk (KERN_ERR PFX "interrupt init failed, aborting\n");
goto err_out_have_proc;
- }
-
- pci_read_config_byte (pdev, 0x3C, );
- if ((tmp & 0x0F) != pdev->irq) {
- printk (KERN_WARNING PFX "IRQ fixup, 0x3C==0x%02X\n", tmp);
- udelay (15);
- tmp &= 0xF0;
- tmp |= pdev->irq;
- pci_write_config_byte (pdev, 0x3C, tmp);
- DPRINTK ("new 0x3c==0x%02x\n", tmp);
- } else {
- DPRINTK ("IRQ reg 0x3c==0x%02x, irq==%d\n",
- tmp, tmp & 0x0F);
}
printk (KERN_INFO PFX "board #%d at 0x%04lX, IRQ %d\n",
Re: missing sysrq
Am Freitag, 1. Juni 2001 16:51 schrieben Sie: > > Have you tried "echo 1 > /proc/sys/kernel/sysrq"? > > You need both, compiled in and activation. > > no, look at the code. the enable variable defaults to 1. Then there must be a bug? I get "0" with 2.4.5-ac2 and -ac5 without "echo 1". Fresh booted 2.4.5-ac2: SunWave1>cat /proc/version Linux version 2.4.5-ac2 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Mon May 28 05:42:09 CEST 2001 SunWave1>cat /proc/sys/kernel/sysrq 0 -Dieter - 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
On Fri, 1 Jun 2001, Jeff Garzik wrote:
> 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(_lock,
>flags)
> > #defineNCR_UNLOCK_DRIVER(flags)
>spin_unlock_irqrestore(_lock,flags)
> > +#defineNCR_LOCK_HOSTS(flags) spin_lock_irqsave(_host_lock,
>flags)
> > +#defineNCR_UNLOCK_HOSTS(flags)
>spin_unlock_irqrestore(_host_lock,flags)
> >
> > #define NCR_INIT_LOCK_NCB(np) spin_lock_init(>smp_lock);
> > #defineNCR_LOCK_NCB(np, flags)spin_lock_irqsave(>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?
This has been done years ago for linux 2.1.93.
The save/restore flags locking methods are conditionnaly compiled for
earlier kernels. This makes the corresponding code very probably quite
useless nowadays and I should remove it from the source.
Gérard.
-
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/
international patches from kerneli far behind
Hello, Sorry if this subject does not fit in this list. I am a bit worried about the development of the international kernel patches from kerneli.org. These patches are getting far behind on the real kernel distributions. At this moment the latest patches are 2.2.18.3 and 2.4.3.1 while the kernel at now is at 2.2.19 and 2.4.5. There is now news to the public why these patches are falling behind. I hope more people are consirned about this. best regards, L. Larssen PS: Due to mailbox restrictions of my account I'm not able to subscribe to the list. Please also CC any reply's to my e-mail address. Thank you. Get free email and a permanent address at http://www.netaddress.com/?N=1 - 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's Southbridge bug: Latest (pseudo-)patch
On Fri, Jun 01, 2001 at 11:28:48AM -0400, Jeff Garzik <[EMAIL PROTECTED]> wrote: > Once you get into the area of flushing data (or not flushing, which is > what delayed txn would imply), it is entirely possible that the driver > simply does not support what occurs when the PCI Delay Txn option is > set. Aren't PCI delayed transaction supposed to be handled by the pci master (e.g. my northbridge), not by the (software) driver for my pdc(?) I would also be surprised if my pdc actually used that feature, not to speak of the fact that the promise + harddisk worked fine in another computer (the data corruption was easily detectable, one couldn't even write 500megs without altered bytes). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - 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, more info
Hi again, Earlier today I wrote about my SMP and Ultra-DMA problem. Now have I written down the boot information. I hope that the attachment show the correct information, it was written in W*rd so some lower case chars can have been converted into upper case... I also checked the IDE-patch and the filename was kernel-patch-2.2.19-ide_20010325-1.tar.gz. Could a newer IDE-patch handle SMP better than this one? Thanks! _\\|//_ (-0-0-) /---ooO-(_)-Ooo--\ | Magnus SandbergEmail: [EMAIL PROTECTED] | | Network Engineer, Bluelabs http://www.bluelabs.se/ | | Phone: +46-8-470 2155(FAX: +46-8-470 2199)GSM: +46-708-225 805 | \/ || || ooO Ooo boot-log-2.2.19-ide-smp-error.txt
2.4.5-ac5 locks on ReiserFS umount (ac4 doesn't)
Hello! I'm using ReiserFS in the kernel, not as a module. My root filesystem is ReiserFS. I mounted another ReiserFS partition and then tried to unmount it. umount hung. sync hung. shutdown hung. Both umount and sync were shown in the "D" state on Ctrl-ScrollLock. I reverted to 2.4.5-ac4 and could not reproduce the problem. I saw a suggestion that it may have to do with module unloading, but in my case reiserfs is not a module. Full config file if here: http://www.red-bean.com/~proski/linux/config -- Regards, Pavel Roskin - 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.2.19 locks up on SMP - tcp-hang patch NOT fixed the problem!
On Tue, 29 May 2001 15:50:22 +0200, [EMAIL PROTECTED] wrote: > Today I tried to install freeswan1.9. After establishing ipsec tunnel with > my peer I got the wait_on_bh message. > (I cannot paste exactly because It is a production machine, and I restarted > it as fast as I could) > > So what to do? Take it up with the freeswan people. It is very likely an SMP bug in their code. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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 Fri, Jun 01, 2001 at 07:28:33PM +0200, Manfred Spraul wrote: > [EMAIL PROTECTED] wrote: > > > > :setpci -s 00:07.2 INTERRUPT_LINE=15 > > :lspci -vx -s 00:07.2 > > 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 >[UHCI]) > > Subsystem: Unknown device 0925:1234 > > Flags: bus master, medium devsel, latency 32, IRQ 19 > > I/O ports at a000 [size=32] > > Capabilities: [80] Power Management version 2 > > 30: 00 00 00 00 80 00 00 00 00 00 00 00 15 04 00 > > :setpci -s 00:07.2 INTERRUPT_LINE=19 > > :lspci -vx -s 00:07.2 > > 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 >[UHCI]) > > Subsystem: Unknown device 0925:1234 > > Flags: bus master, medium devsel, latency 32, IRQ 19 > > I/O ports at a000 [size=32] > > Capabilities: [80] Power Management version 2 > > 30: 00 00 00 00 80 00 00 00 00 00 00 00 19 04 00 00 > > > > So that is correct. I'll attach all the information from the MPS 1.4 > > reboot, in which 00:07.2 happily points at 05, while everything else > > thinks it's at 19. > > > > Could you compile uhci as a module, set the configuration to MPS1.4 and > find out with which interrupt line setting it works. > I'd try both > > setpci -s 00:07.2 INTERRUPT_LINE=13 no change, still this in /var/log/messages: Jun 1 20:57:48 middle kernel: uhci.c: USB Universal Host Controller Interface driver Jun 1 20:57:48 middle kernel: hub.c: USB new device connect on bus1/1, assigned device number 2 Jun 1 20:57:51 middle kernel: usb_control/bulk_msg: timeout Jun 1 20:57:51 middle kernel: usb.c: USB device not accepting new address=2 (error=-110) Jun 1 20:57:51 middle kernel: hub.c: USB new device connect on bus1/1, assigned device number 3 Jun 1 20:57:54 middle kernel: usb_control/bulk_msg: timeout Jun 1 20:57:54 middle kernel: usb.c: USB device not accepting new address=3 (error=-110) > setpci -s 00:07.2 INTERRUPT_LINE=3 > [even if 13 works, please try 03 as well. 13 is hexadecimal==19] Bingo!! Jun 1 20:59:34 middle kernel: Type: Direct-Access ANSI SCSI revision: 02 Jun 1 20:59:34 middle kernel: Attached scsi removable disk sda at scsi3, channel 0, id 0, lun 0 Jun 1 20:59:34 middle kernel: sda : READ CAPACITY failed. Jun 1 20:59:34 middle kernel: sda : status = 1, message = 00, host = 0, driver = 08 Jun 1 20:59:34 middle kernel: sda : extended sense code = 2 Jun 1 20:59:34 middle kernel: sda : block size assumed to be 512 bytes, disk size 1GB. Jun 1 20:59:34 middle kernel: sda: I/O error: dev 08:00, sector 0 Jun 1 20:59:34 middle kernel: unable to read partition table Jun 1 20:59:34 middle kernel: WARNING: USB Mass Storage data integrity not assured Jun 1 20:59:34 middle kernel: USB Mass Storage device found at 2 > > The via ac97 sound driver contains an irq fixup for this problem. Either > a similar fixup is necessary in the uhci driver, or the fixup from the > ac97 driver could be moved to the pci-quirks and applied to all devices > in the southbridge. > Just to be sure, the lspci -vvvxxx reading of 07.2 after this setpci -s 00:07.2 INTERRUPT_LINE=3 with MPS=1.4 in the bios: 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: isdn connecting error(auth failed) with 2.4.4-ac9 and2.4.5
On Thu, 31 May 2001, CZUCZY Gergely wrote:
> May 27 15:00:52 kign ipppd[391]: Remote message: Access Denied
> May 27 15:00:52 kign ipppd[391]: PAP authentication failed
You passwors in /etc/{ppp,isdn}/pap-secrets is wrong.
> Modules Loaded NVdriver hisax isdn slhc au8820
^^
Don't report errors to Linux Kernel Mailing List with two
binary-only-kernel-modules loaded. Nobody will help you expect Nvidia and
Aureal(now Create Labs) themselves.
BYtE
Philipp
--
/ / (_)__ __ __ Philipp Hahn
/ /__/ / _ \/ // /\ \/ /
//_/_//_/\_,_/ /_/\_\ [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
The oops problem with the cs46xx in my ThinkPad 600X under -ac4 and -ac5 has
changed now. It no longer gives an oops; instead the program trying to access
the sound card hangs (until I kill it). Subsequent attempts to access the sound
card get a "Device or resource busy" error. There are no messages on the screen
or sent to syslog (or messages or debug) when the hang occurs. I don't know if
it will help or not, but here are the last few lines of an strace of the hanging
process:
stat("/usr/bin/sox", {st_mode=S_IFREG|0755, st_size=120744, ...}) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
fork() = 186
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x806c04c, [], 0x400}, {SIG_DFL}, 8) = 0
wait4(-1, 0xb744, 0, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGTERM (Terminated) ---
+++ killed by SIGTERM +++
At the point of the hang, the output stops at "wait4(-1, " and the rest of that
line (and the next two lines) appears after I kill the process.
Here are the last few lines of another strace of the same program under
2.4.5-ac3, which works fine:
stat("/usr/bin/sox", {st_mode=S_IFREG|0755, st_size=120744, ...}) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
fork() = 435
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x806c04c, [], 0x400}, {SIG_DFL}, 8) = 0
wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 435
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) ---
wait4(-1, 0xb438, WNOHANG, NULL)= -1 ECHILD (No child processes)
sigreturn() = ? (mask now [])
rt_sigaction(SIGINT, {SIG_DFL}, {0x806c04c, [], 0x400}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
read(255, "", 4472) = 0
_exit(0)= ?h
-
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: Makefile patch for cscope and saner Ctags
cscope: Minor stuff: 1) in cscope.files - I'd be replacing cscope.files with $@ within the rule - you don't need a yellow belt to know $@ within a Makefile 2) /bin/rm vs rm tags: Not going deep into it, I possibly should say here that hardwiring depth 5 is not the best thing probably - once someone extends down to 6, this place in the Makefile will for sure not be updated. You can make a loop here to max depth, which you can discover right here, rather than the current manually unrolled loop. In general, I am not a tags user in the kernel (sticking to local tags + global cscope), so I'd be happy if you and Pete could merge together your tags stuff. As for the ignore list, I don't see much of maintenance work there - and, if you guys think there is, maybe it is just possible to add Pete on the Kernel Build maintainers WRT to that file? Overall, IMHO, after you give it the last touch (maybe just dismissing my present letter :-) ) the cscope stuff is mature enough for going to KO & Co. (i.e. the kernel build guys); I don't consider myself a hardcore tags user to say so about the tags portion. Keith, what do you think? Vassilii > -Original Message- > From: Mark Frazer [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 31, 2001 4:45 PM > To: Khachaturov, Vassilii > Cc: Linux Kernel > Subject: Re: Makefile patch for cscope and saner Ctags > > > Khachaturov, Vassilii <[EMAIL PROTECTED]> > [01/05/31 15:00]: > > Don't forget to bug RH package maintainer on that. Whatever > > bugzilla submitted > > > I use source-built cscope v.15.1, and -k works for me here, > > works for me too! > > > WHY?! Isn't it better to put $(shell cat cscope.files) on > the list of > > I only have a yellow belt in makefile kungfu. These fancy > gnu make things > are relatively new to some of us... > > The latest patch is attached. include/linux/compile.h seems to get > built whenever I run make, so that's why I've excluded it > from the deps > for cscope.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/
Re: 2.4.5 still breaks dhcpcd with 8139too
On Fri, 01 Jun 2001, Jeff Garzik wrote: > Matthias Andree wrote: > > > > Will that 8139too be able to share its IRQ with a bttv card (Hauppauge > > WinTV in my case)? With 2.2.19, it's currently possible, at least after > > unloading and reloading the 8139too module, but it's a no-go with 2.4.5. > > Can you be more explicit than "no-go"? 8139too should share interrupts > just fine. Not sure if it's related to IRQ sharing or another initialization issue. Here's the hardware setup, machine at the time of testing also had 2 64 MB DIMMS and a Duron 700, all in a Gigabyte 7ZX-R. First column is the IRQ (decimally), if any. (lspci, merged with lspci -v IRQ information) 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) 05 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) 05 00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) 00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 12 00:09.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02) 12 00:09.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02) 11 00:0a.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03) 12 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) 11 00:0e.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02) 05 00:0f.0 Ethernet controller: 3Com Corporation 3c900 Combo [Boomerang] 05 00:10.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) 09 01:00.0 VGA compatible controller: nVidia Corporation Riva TnT 128 [NV04] (rev 04) /proc/interrupts (2.2) 0:1536577 XT-PIC timer 1: 33313 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 9 XT-PIC serial 4: 57284 XT-PIC serial 5: 24965 XT-PIC ide2, eth0 6: 28 XT-PIC floppy 8: 2503 XT-PIC rtc 10:340 XT-PIC serial 11: 9581 XT-PIC sym53c8xx, es1371 12: 64495 XT-PIC eth1 13: 1 XT-PIC fpu 14: 80681 XT-PIC ide0 So, here's the story. Initially, the card was in the next-to-bottom PCI slot, sharing its IRQ with the nvidia (which isn't listed here for reasons beyond my knowledge), IRQ 09. With Linux 2.2.19, I caught error messages I already reported on May 19, thread subject "RTL8139 difficulties in 2.2, not in 2.4"; the IRQs weren't reported properly. That report related to rtl8139, but 8139too showed the same problems, it just was less verbose in its error reporting. I got replies by Donald Becker, who suggested to boot with "noapic", but that didn't help. On May 21, I found out, that 2.4.4 didn't work either. While the RTL8139 card shared its IRQs with the nvidia, unloading the module (rmmod 8139too), reloading it by running "ifconfig eth1 up" (literally) brought the card to work on Linux 2.2 reliably, and I believe also with 2.4. "To work" means: pppoe on that card talks through the DSL modem, discovers the Access Concentrator and tunnels PPP for use with pppd 2.4.0. Not working means: pppoe does not receive PAD replies. Note: PPPoE doesn't talk IP. A couple of days ago, I moved the card down one slow, now it shares its IRQ with the Hauppauge WinTV BT878 board. With Linux 2.2, the situation is the same, although, from time to time, the card just works. With Linux 2.4, the situation is worse now, the card almost never works, and it won't work at all in 2.4.5. As I'm totally unaware of how the card initalization procedures are done, I don't know how to reasonably debug this, I'd like to do that systematically. I'm also willing to move the card around to figure what's going on, but I need directions on what to look for. I'm talking about initialization because I believe it might be involved as unloading and reloading the 8139too.o driver module seems to help out. Again, please send directions on how to track this down. What output is helpful and what is unnecessary (mii-diag? /proc/interrupts of either kernel version? what else?). What am I supposed to change in hardware configuration to find the problem? What debug options should I switch on when recompiling a debug kernel? Thanks in advance, Matthias - 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: DVD blockdevice buffers
Hi! > I can easily give more examples - just ask. BTW, the fact that this stuff > is so fragmented is not a bug - we want it evenly spread over disk, just > to have the ability to allocate a block/inode not too far from the piece > of bitmap we'll need to modify. BTW is this still true? This assumes that long seek takes more time than short seek. With 12.000rpm drive, one rotation takes 5msec. "Full" seek is around 12msec these days, no? Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - 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] remove unnecessary zero initializations from aironet4500_proc.c (245ac1)
Hi!
> Hi.
>
> The following patch removes two superfluous initializations
> from aironet4500_proc.c, making the .o ~12K smaller in
> size. It applies against 245ac1 and was discovered by Adam
> Ritcher some time ago.
>
> --- linux-245-ac1-clean/drivers/net/aironet4500_proc.cSat May 19 20:58:24
>2001
> +++ linux-245-ac1/drivers/net/aironet4500_proc.c Mon May 28 22:13:26 2001
> @@ -59,7 +59,7 @@
> charproc_name[10];
> };
> static char awc_drive_info[AWC_STR_SIZE]="Zcom \n\0";
~~
When you are at cleaning, kill that ugly \0, too.
> -static char awc_proc_buff[AWC_STR_SIZE]="\0";
> +static char awc_proc_buff[AWC_STR_SIZE];
> static int awc_int_buff;
> static struct awc_proc_private awc_proc_priv[MAX_AWCS];
>
> @@ -403,7 +403,7 @@
> {0}
> };
>
> -struct ctl_table_header * awc_driver_sysctl_header = NULL;
> +struct ctl_table_header * awc_driver_sysctl_header;
>
> const char awc_procname[]= "awc5";
Pavel
--
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)
Pete Zaitcev wrote: > > 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. sorry, I meant to say: The core is in, but the drivers for the adapters in question are not. They are part of lm_sensors, and as such, make it very hard for us to maintain. I have encouraged the lm_sensors crew to get at LEAST the adapters/algorithms submitted for general inclusion. Once that is in, I will make cobalt_i2c go away. Tim -- Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [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: [newbie] NFS client: port-unreachable
> " " == Roland Kuhn <[EMAIL PROTECTED]> writes: > Hi folks! When I lstat64 a directory on an nfs mount the > answer to GETATTR is received by the network interface but > dropped (not seen by the client) afterwards. Only 50musec after > the receive of the answer an icmp-destination-unreachable > (port-unreachable) goes out to the server. This is annoying > since it blocks all access to that directory. The request in > question is sent and received at port 772. > I'm using kernel 2.4.4. You probably have set ipchains or ipfilter to block port 772 on your client. Cheers, Trond - 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: PROBLEM: isdn connecting error(auth failed) with 2.4.4-ac9 and2.4.5
On Thu, 31 May 2001, CZUCZY Gergely wrote: > May 27 15:00:50 kign kernel: ippp0: dialing 1 0651201201... > May 27 15:00:51 kign kernel: isdn_net: ippp0 connected > May 27 15:00:51 kign ipppd[391]: Local number: 2536889, Remote > number: 0651201201, Type: outgoing > May 27 15:00:51 kign ipppd[391]: PHASE_WAIT -> PHASE_ESTABLISHED, > ifunit: 0, linkunit: 0, fd: 7 > May 27 15:00:52 kign ipppd[391]: Remote message: Access Denied > May 27 15:00:52 kign ipppd[391]: PAP authentication failed > May 27 15:00:52 kign ipppd[391]: LCP terminated by peer That really looks more like an authentication problem. Is this problem reproducible, and does it vanish if you go back to 2.4.4? If the problem persists, contact me off list, and I'll try to sort it out. --Kai - 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: [CHECKER] 2.4.5-ac4 non-init functions calling init functions
If you do implement such a thing, make sure that you don't mistakenly spot smth that gets exported to a non-kernel-tree driver, or smth that gets called by a non-__init, --- but not in the current kernel config! V. > -Original Message- > From: Dawson Engler [mailto:[EMAIL PROTECTED]] > checker to > > find functions which are only called from __init functions, but not > > marked __init themselves, you'd most likely find lots more > performance > > bugs of this kind. > > I haven't hacked this in --- I was waiting to get a feel for how > important the checker was before spending too much time on - 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/
cobalt patches
Thanks for all the comments, so far. I'm going to incorporate all the changes mentioned, and resubmit the questioned patches. Tim -- Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [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: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
On Fri, 1 Jun 2001, Hans Reiser wrote: > known VFS bug, ask viro for details, 2.4.5 is not stable because of it, use > 2.4.4 Different issue. Missing lock_kernel()/unlock_kernel() in kill_super() appeared in -pre6 and was fixed in -ac2 or so. -ac5 apparently had introduced something new, that had been reverted (fixing the problem) in -ac6. - 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/
unresolved symbol irda_cleanup
Hi,
I solved this problem. IrDA hasn't worked since 2.4.2 kernel with this
error message. Problem was static definition of irda_clenup() in irsyms.c
My patch is from kernel 2.4.4, but can be aplied to 2.4.5 too.
Dave.
PS: I'm not in mailing list.
diff -urN linux-2.4.4.orig/net/irda/irsyms.c linux-2.4.4/net/irda/irsyms.c
--- linux-2.4.4.orig/net/irda/irsyms.c Thu May 31 16:02:07 2001
+++ linux-2.4.4/net/irda/irsyms.c Thu May 31 16:02:00 2001
@@ -218,7 +218,7 @@
return 0;
}
-static void __exit irda_cleanup(void)
+void __exit irda_cleanup(void)
{
#ifdef CONFIG_SYSCTL
irda_sysctl_unregister();
--
---
David "Dave" JezBrno, CZ, Europe
E-mail: [EMAIL PROTECTED]
PGP key: finger [EMAIL PROTECTED]
-=[ ~EOF ]=
-
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'd be forced to agree. I have 2.4.x in limited production, and with the exception of the HP/APIC fatal issues that have a "noapic" work-around, I have had no problem at all with any of the 2.4.x kernels I've used. Open software by definition will never reach the kind of monolithic stability that years of code freeze requires. Linux (especially 2.4.x) offers too much in return, and I can always run a 2.2.x kernel. I would say that the stability of the kernel has been *above* my expectations, frankly, considering all that's changed. It's definitely our responsibility as admins to test these kernels. I was running 2.4.0-test1 the second it was released, and the one problem I've found has been reported and investigated (it's apparently a tough one). As far as VM, I've never had the severe issues that some are reporting. This doesn't mean it's not a problem, but it definitely indicates that it's not a global showstopper. For VM-intense applications, I roll out a 2.2.19 kernel as a preventative measure while I wait for the VM code to be tweaked. I guess I would have expected these complaints during the -test phase. Not to mention that the distributions seem to have rolled out 2.4.x just fine. To wit: box1 1 ~> uptime 10:27am up 168 days, 2:43, 3 users, load average: 2.45, 2.30, 2.32 box1 2 ~> uname -a Linux box1.mynetwork.tld 2.4.0-test6 #1 SMP Sat Aug 19 04:26:58 PDT 2000 i686 unknown Not true production, but totally representative of my experiences FWIW. IMHO, YMMV, etc. -- Ken. On Friday, June 1, 2001, at 10:15 AM, Miquel Colom Piza wrote: > This is my first email to the list. I'm not subscribed but I've read it > for years. > > I don't agree with those claiming that 2.4.xx is bad or still beta. > > We the administrators have the responsability to test early kernels and > send good bug reports so the developers can solve the bugs. That's the > way we can contribute to the community. > > But it's really risky to use these kernels on MAIN 24x7 production > servers. > > This has been true for 1.2.x 2.0.x (I think that was the best linux > kernel series) 2.2.x and 2.4.x and will be for 2.6.x also > > Given we know that the support from open source developers is clearly > better than commercial contract supports, I don't see the reason to > complain about the work of those wonderfull hackers spending their spare > time coding for all of us. > > (I'm not subscribed to the list, Please CC me). > > - > 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/ - 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: [newbie] NFS broken in 2.4.4?
> When a process tries to lstat64 a file on nfs and the reply is not > received it gets blocked forever. Should it be that way? Yes. Unless you made the mount with -o soft. The box will wait until the server comes back - 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 ?
Manfred Spraul wrote: > Could you compile uhci as a module, set the configuration to MPS1.4 and > find out with which interrupt line setting it works. > I'd try both > > setpci -s 00:07.2 INTERRUPT_LINE=13 > setpci -s 00:07.2 INTERRUPT_LINE=3 > [even if 13 works, please try 03 as well. 13 is hexadecimal==19] > > The via ac97 sound driver contains an irq fixup for this problem. Either I am not sure this fixup is necessary, though IIRC it did solve some problems. Since this latest round of Via fixups, I would like to remove that little change in via audio, and see it anyone complains. The 686A and 686B docs list no irq after 14. Adrian Cox has said that setting the PCI intr line value actually makes a connection on the PIC, instead of just being a scratchpad register like it is normally. Adrian said the same thing about the USB IRQ, and I presume the other internal irqs (like ACPI) listed for register 0x58 apply as well. -- 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: 2.4.5 still breaks dhcpcd with 8139too
Matthias Andree wrote: > > On Wed, 30 May 2001, Jeff Garzik wrote: > > > > I see that Alan has reverted back to the 2.4.3 driver for his ac-series for > > > other reasons, hopefully either the old driver will going in to 2.4.6 or the > > > new one will get fixed? > > > > I've got one of the two problems fixed here at the test lab, and am > > working on the second. Hopefully this week I'll have this sorted out, > > and a driver for you guys to test. > > Will that 8139too be able to share its IRQ with a bttv card (Hauppauge > WinTV in my case)? With 2.2.19, it's currently possible, at least after > unloading and reloading the 8139too module, but it's a no-go with 2.4.5. Can you be more explicit than "no-go"? 8139too should share interrupts just fine. -- 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: select() - Linux vs. BSD
> So how does this say the value of the fdsets are undefined > after a timeout? You are right, it doesn't say so. I should have said That is, a wise programmer does not assume any particular value for the bits after an error. 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: ethernet still quits
On Fri, Jun 01, 2001 at 03:45:46PM +, Danny ter Haar wrote: > >the current 'ac' patches or a previous version on > >http://sf.net/projects/gkernel/ temporarily. > > also on : > www.bzimage.org/kernel-patches/v2.4/alan/v2.4.5/ > > 8139_too_work.c (62kB) > > And also there: > > patch-2.4.5-ac6-crypto.bz2 (268kB) Thanks Jeff and Danny. you're a help ! -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - 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 ?
[EMAIL PROTECTED] wrote: > > :setpci -s 00:07.2 INTERRUPT_LINE=15 > :lspci -vx -s 00:07.2 > 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI]) > Subsystem: Unknown device 0925:1234 > Flags: bus master, medium devsel, latency 32, IRQ 19 > I/O ports at a000 [size=32] > Capabilities: [80] Power Management version 2 > 30: 00 00 00 00 80 00 00 00 00 00 00 00 15 04 00 > :setpci -s 00:07.2 INTERRUPT_LINE=19 > :lspci -vx -s 00:07.2 > 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI]) > Subsystem: Unknown device 0925:1234 > Flags: bus master, medium devsel, latency 32, IRQ 19 > I/O ports at a000 [size=32] > Capabilities: [80] Power Management version 2 > 30: 00 00 00 00 80 00 00 00 00 00 00 00 19 04 00 00 > > So that is correct. I'll attach all the information from the MPS 1.4 > reboot, in which 00:07.2 happily points at 05, while everything else > thinks it's at 19. > Could you compile uhci as a module, set the configuration to MPS1.4 and find out with which interrupt line setting it works. I'd try both setpci -s 00:07.2 INTERRUPT_LINE=13 setpci -s 00:07.2 INTERRUPT_LINE=3 [even if 13 works, please try 03 as well. 13 is hexadecimal==19] The via ac97 sound driver contains an irq fixup for this problem. Either a similar fixup is necessary in the uhci driver, or the fixup from the ac97 driver could be moved to the pci-quirks and applied to all devices in the southbridge. -- 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/
Re: 2.4.5 VM
This is my first email to the list. I'm not subscribed but I've read it for years. I don't agree with those claiming that 2.4.xx is bad or still beta. We the administrators have the responsability to test early kernels and send good bug reports so the developers can solve the bugs. That's the way we can contribute to the community. But it's really risky to use these kernels on MAIN 24x7 production servers. This has been true for 1.2.x 2.0.x (I think that was the best linux kernel series) 2.2.x and 2.4.x and will be for 2.6.x also Given we know that the support from open source developers is clearly better than commercial contract supports, I don't see the reason to complain about the work of those wonderfull hackers spending their spare time coding for all of us. (I'm not subscribed to the list, Please CC me). - 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
known VFS bug, ask viro for details, 2.4.5 is not stable because of it, use
2.4.4
Hans
[EMAIL PROTECTED] wrote:
>
> 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/
-
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/
[newbie] NFS client: port-unreachable
Hi folks! When I lstat64 a directory on an nfs mount the answer to GETATTR is received by the network interface but dropped (not seen by the client) afterwards. Only 50musec after the receive of the answer an icmp-destination-unreachable (port-unreachable) goes out to the server. This is annoying since it blocks all access to that directory. The request in question is sent and received at port 772. I'm using kernel 2.4.4. Please help, Roland - 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/
MD Auth messages.
Sorry if you got any majordomo auth messages from me. Just mailman messing up :\ John 'Neuron' McGarrigle Email: [EMAIL PROTECTED] ICQ: 18220396 Phone: +44 (0)7944 604 644 - 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 Fri, 1 Jun 2001 [EMAIL PROTECTED] wrote: > (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. So how does this say the value of the fdsets are undefined after a timeout? It says specifically that upon success it returns the number of descriptors in the sets, zero if the timeout expires. That is a success condition upon which select() sets the fdsets to contain the descriptors upon which something interesting happened. In the case of a timeout with no descriptor having anything interesting, the sets would, logically, be cleared. The man page does state that the value of "timeout" is effectively undefined upon return and that "timeout" and the fdsets are undefined after an error, however. Of course, not looking at the sets upon a zero return is a fairly obvious optimization as there is little point in doing so. William Astle finger [EMAIL PROTECTED] for further information Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y? - 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/
ifconfig freezes in 2.4.5
Hi, When I compiled and booted 2.4.5, the machine got stuck in ifconfig lo 127.0.0.1 (SysRq still worked, ^C did not seem to). I tried to strace it. Last thing strace managed to write was: ioctl(4, 0x8914 (no comma, not including the trird argument). I tried to switch of some compile-time parameters I changed from 2.4.4, but problem persisted. After reversing 2.4.5 patch and recompiling the kernel (using exactly the same config), the problem dispaeared. I include the .config used. I'll try to gen any aother information you might consider some use, but currently have no idea what it might be. --- Jan 'Bulb' Hudec <[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: [newbie] NFS broken in 2.4.4?
Roland Kuhn <[EMAIL PROTECTED]> writes: > Hi folks! > > When a process tries to lstat64 a file on nfs and the reply is not > received it gets blocked forever. Should it be that way? If it's a hard nfs mount, yes. Mount soft if you want timeouts. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - 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/
[newbie] NFS broken in 2.4.4?
Hi folks! When a process tries to lstat64 a file on nfs and the reply is not received it gets blocked forever. Should it be that way? Please help, Roland - 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
On Fri, 1 Jun 2001, Marcin Kowalski wrote: > Relating to Huge Dcache and InodeCache Entries and < 2xMem Swap. > I have a server with > 1.1gig of RAM which I have limited to 1gig (due to > stability - BUG at HIGHMEM.c: 155 crashes)... > > The size of the Swap space is 620mb... my memory usage is below : > > Mem:98 892748 7260 0 14796 171796 > -/+ buffers/cache: 706156 193852 > Swap: 641016 1792 639224 > > The extract out of slabinfo is: > inode_cache 903876 930840480 116355 1163551 : 124 62 > bdev_cache 1160 1357 64 23 231 : 252 126 > sigqueue 261261132991 : 252 126 > dentry_cache 775520 934560128 31152 311521 : 252 126 > > As you can see the usage is crazybearing in mind a number of things. > The system is running hardware raid5, reiserfs and massive amount of files > > 50 in >2000 directories.. > > It is a 2x933mhz PIII + 1.1gig of ram NEtservers > > What I really want to know is DOES THIS REALLY Matter. IE If memory is > needed by and application are these entries simply purged then.. In which > case there is no problem Could you check if they are purged heavily enough for you case when you start a big app? - 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: missing sysrq
Dieter Nützel wrote: > > > D. Stimits wrote: > > > > > Bernd Eckenfels wrote: > > > > > > > In article <[EMAIL PROTECTED]> you wrote: > > > > However, if I go to /proc/sys/kernel/sysrq does not exist. > > > > > > It is a compile time option, so the person who compiled your kernel > > > left it out. > > > > I compiled it, and the sysrq is definitely in the config. No doubt at > > all. I also use make mrproper and config again before dep and actual > > compile. Maybe it is just a quirk/oddball. > > > > D. Stimits, [EMAIL PROTECTED] > > Have you tried "echo 1 > /proc/sys/kernel/sysrq"? > You need both, compiled in and activation. It is compiled in, but the echo is summarily rejected. Root is not allowed to write to that file, which doesn't exist. I'm going to just wipe out everything from that kernel and redo the whole thing. D. Stimits, [EMAIL PROTECTED] > > Regards, > Dieter > -- > Dieter Nützel > Graduate Student, Computer Science > > email: [EMAIL PROTECTED] > @home: [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/
Question regarding pci_alloc_consitent() and __get_free_pages
Hi, I have a question regarding the pci_alloc_consistent() function. Will this function allocate pages that are physical contiguous ? i.e if I call this function with a size argument of 32KByte will that be 8 consecutive pages in memory on i386 architecture (4 pages on alpha). In general, will __get_free_pages(GFP_ATOMIC, order) always return physical contiguous memory ? All feedback appreciated, -- Steffen Persvold Systems Engineer Email : mailto:[EMAIL PROTECTED] Scali AS (http://www.scali.com) Tlf : (+47) 22 62 89 50 Olaf Helsets vei 6 Fax : (+47) 22 62 89 51 N-0621 Oslo, Norway - 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: ethernet still quits
Danny ter Haar wrote: > > Jeff Garzik <[EMAIL PROTECTED]> wrote: > >Working on the problem. You'll need to downgrade the 8139too driver to > >the current 'ac' patches or a previous version on > >http://sf.net/projects/gkernel/ temporarily. > > also on : > www.bzimage.org/kernel-patches/v2.4/alan/v2.4.5/ > > 8139_too_work.c (62kB) That's fine, it is a previous version (0.9.15c). Note that the current (broken) 8139too works for some people where earlier versions don't, so obviously you should not downgrade unless you are having problems. > And also there: > > patch-2.4.5-ac6-crypto.bz2 (268kB) What's that? -- 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: ethernet still quits
Jeff Garzik <[EMAIL PROTECTED]> wrote: >Working on the problem. You'll need to downgrade the 8139too driver to >the current 'ac' patches or a previous version on >http://sf.net/projects/gkernel/ temporarily. also on : www.bzimage.org/kernel-patches/v2.4/alan/v2.4.5/ 8139_too_work.c (62kB) And also there: patch-2.4.5-ac6-crypto.bz2 (268kB) Danny -- Holland Hosting www.hoho.nl [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: Configure.help is complete
At 2:59 PM +0200 2001-06-01, David Weinehall wrote: > > 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. It clearly fills a need, though, and has the distinct side benefit of cutting down on the proliferation of ioctls. Sure, it's non-standard and a mess. But it's semi-documented, easy to use, and v. general. What's the preferred alternative, to state the first question another way? For any single small project/driver, creating a new fs simply isn't going to happen. -- /Jonathan Lundell. - 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 have a 2.4.5-ac3 box with 1G RAM and 2.6G Swapfirst time developers hit apache/php/zendcache after reboot and it swapped to a stop. I stop/restarted apache and it seems very happy...can't goto production like this tho :( Alan Cox 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/ -- --- Russell Leighton[EMAIL PROTECTED] Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook --- - 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: ns558 bugfix / CSC ids
Hi,
I have added two CSC function ids to the ISAPNP joystick probing.
CSC cards use a lot of varying ids for the functions, but in my
set of data, 0010 and 0110 are always 'CTL'Game Controllers.
One bugfix: port->size must be set, or the release_region on rmmod ns558
fails badly.
Tested on IBM Netfinity 3500.
Ciao, Marcus
Index: drivers/char/joystick/ns558.c
===
RCS file: /build/mm/work/repository/linux-mm/drivers/char/joystick/ns558.c,v
retrieving revision 1.16
diff -u -r1.16 ns558.c
--- drivers/char/joystick/ns558.c 2001/06/01 11:33:11 1.16
+++ drivers/char/joystick/ns558.c 2001/06/01 15:31:09
@@ -178,6 +178,8 @@
{ ISAPNP_ANY_ID, ISAPNP_ANY_ID, ISAPNP_VENDOR('C','T','L'),
ISAPNP_DEVICE(0x7001), 0 },
{ ISAPNP_ANY_ID, ISAPNP_ANY_ID, ISAPNP_VENDOR('C','T','L'),
ISAPNP_DEVICE(0x7002), 0 },
{ ISAPNP_ANY_ID, ISAPNP_ANY_ID, ISAPNP_VENDOR('C','S','C'),
ISAPNP_DEVICE(0x0b35), 0 },
+ { ISAPNP_ANY_ID, ISAPNP_ANY_ID, ISAPNP_VENDOR('C','S','C'),
+ISAPNP_DEVICE(0x0010), 0 },
+ { ISAPNP_ANY_ID, ISAPNP_ANY_ID, ISAPNP_VENDOR('C','S','C'),
+ISAPNP_DEVICE(0x0110), 0 },
{ ISAPNP_ANY_ID, ISAPNP_ANY_ID, ISAPNP_VENDOR('P','N','P'),
ISAPNP_DEVICE(0xb02f), 0 },
{ 0, },
};
@@ -217,6 +219,7 @@
port->next = next;
port->type = NS558_PNP;
port->gameport.io = ioport;
+ port->size = iolen;
port->dev = dev;
gameport_register_port(>gameport);
-
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: [QUESTION] which routines must be re-entrant?
On Thu, May 31, 2001 at 04:01:34PM -0700, Dawson Engler wrote: > Is there an easy way to tell which routines must be re-entrant? > (it doesn't have to be exhaustive, even an incomplete set is useful) > > I was going to write a checker to make sure supposedly re-entrant > routines actually were, but was having a hard time figuring out which > ones were supposed to be... Their was an post on bugtraq a few days ago about this, it had a list with all system calls which are reentrant safe under OpenBSD. The paper was about signals, and is available at http://razor.bindview.com/publish/papers/signals.txt OpenBSD had a manpage wich lists all the function which should be be safe to call from a signal handler. It might be a nice place to start. You should only look at those from section 2 of course. http://www.openbsd.org/cgi-bin/man.cgi?query=sigaction Kurt - 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: megaraid
I've had to keep an old 1.14b version of the driver around in order to build a functional kernel for a while now. If I use the newer version (1.14g-ac2), then the kernel can't find my root filesystem on boot. Is this a problem other people have seen? I believe I have the very latest firmware and I also believe my lilo.conf is correct. The most instructive error is the "please a append a correct "root=" boot option", but why is my lilo.conf correct for 1.14b and not correct for 1.14g? a successful startup with 1.14b looks like this: SCSI subsystem driver Revision: 1.00 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.11 aic7899: Wide Channel A, SCSI Id=7, 32/255 SCBs scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.11 aic7899: Wide Channel B, SCSI Id=7, 32/255 SCBs megaraid: v1.14b (Release Date: Jan 18, 2001; 17:06) megaraid: found 0x101e:0x1960:idx 0:bus 4:slot 0:func 0 scsi2 : Found a MegaRAID controller at 0xc0808000, IRQ: 22 megaraid: [l148:3.11] detected 1 logical drives scsi2 : AMI MegaRAID l148 254 commands 16 targs 2 chans 40 luns scsi2: scanning channel 1 for devices. scsi2: scanning channel 2 for devices. scsi2: scanning virtual channel for logical drives. Vendor: MegaRAID Model: LD0 RAID1 35255R Rev: l148 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi disk sda at scsi2, channel 2, id 0, lun 0 SCSI device sda: 72202240 512-byte hdwr sectors (36968 MB) Partition check: sda: sda1 sda2 < sda5 > sda3 sda4 usb.c: registered new driver hub usb-ohci.c: USB OHCI at membase 0xc080a000, IRQ 10 usb-ohci.c: usb-00:0f.2, PCI device 1166:0220 (ServerWorks) usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 4 ports detected NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET 4.0. NET4: AppleTalk 0.18a for Linux NET4.0 reiserfs: checking transaction log (device 08:01) ... Using tea hash to sort names reiserfs: using 3.5.x disk format ReiserFS version 3.6.25 VFS: Mounted root (reiserfs filesystem) readonly. an unsuccessful startup with 1.14g looks like this: SCSI subsystem driver Revision: 1.00 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13 aic7899: Wide Channel A, SCSI Id=7, 32/255 SCBs scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13 aic7899: Wide Channel B, SCSI Id=7, 32/255 SCBs megaraid: v1.14g-ac2 (Release Date: Mar 22, 2001; 19:34:02) megaraid: found 0x101e:0x1960:idx 0:bus 4:slot 0:func 0 scsi2 : Found a MegaRAID controller at 0xc0808000, IRQ: 22 scsi2 : enabling 64 bit support megaraid: [l148:3.11] detected 1 logical drives scsi2 : AMI MegaRAID l148 254 commands 16 targs 2 chans 40 luns scsi2 : scanning channel 1 for devices. scsi2 : scanning channel 2 for devices. scsi2 : scanning virtual channel for logical drives. Vendor MegaRAID Model: LD0 RAID1 35255R Rev: l148 Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 72202240 512-byte hdwr sectors (36968 MB) Partition check: sda: unknown partition table VFS: Cannot open root device "801" or 08:01 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 08:01 Here's my configuration: dual AIC-7899 SCSI controllers, bios 2.57 MegaRAID 40-LD bios ver 3.11 12/13/2000 lilo.conf: boot=/dev/sda map=/boot/map install=/boot/boot.b prompt timeout=50 message=/boot/message vga=ext #linear lba32 default=linux2.4.5-ac4 image=/boot/vmlinuz-2.4.5-ac4 label=linux2.4.5-ac4 read-only root=/dev/sda1 image=/boot/vmlinuz-2.4.4tuxA1 label=linux2.4.4tuxA1 read-only root=/dev/sda1 .configs are the same for both kernel builds... _ Get your FREE download of MSN Explorer at http://explorer.msn.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: ethernet still quits
"Roeland Th. Jansen" wrote: > when quote some xfers have taken place, the realtek card dies here. Working on the problem. You'll need to downgrade the 8139too driver to the current 'ac' patches or a previous version on http://sf.net/projects/gkernel/ temporarily. -- 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/
[PATCH] devfs v178 available
Hi, all. Version 178 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Fixed handling of inverted options in Regards, Richard Permanent: [EMAIL PROTECTED] Current: [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: VIA's Southbridge bug: Latest (pseudo-)patch
Marc Lehmann wrote: > one thing I found out using triel and error is that setting "PCI Delay > Transaction" to enabled causes data corruption on WRITE to my ide drives > connected to an Promise Ultra 100 PCI controlelr (I didn't get any > corruption on the devices connected to the via ide interface, presumably > because my bios already had the right fix). > > So, while the every pci master grant setting apperently fixes the internal > via ide interface corruption the PCI Delay Transaction option also must be > buggy (or my promise controller is) and causes data corruption at least > with an additional promise ultra 100. I do not mean to point fingers, but don't assume Via is at fault here. Once you get into the area of flushing data (or not flushing, which is what delayed txn would imply), it is entirely possible that the driver simply does not support what occurs when the PCI Delay Txn option is set. -- 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/
ethernet still quits
2.4.5 : when quote some xfers have taken place, the realtek card dies here. Jun 1 14:58:12 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 1 14:58:12 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=1303. Jun 1 14:58:14 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 1 14:58:14 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=103. Jun 1 14:58:28 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 1 14:58:28 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=103. Jun 1 14:58:30 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 1 14:58:30 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=123. Jun 1 14:58:32 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 1 14:58:32 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=103. etc. only rebooting helps. hardware BP6, non OC, happens with older kernels as well sometimes. -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - 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/
Highmem Bigmem question
Hello All, This is probably an FAQ, but I read the FAQ and its not in there. I have a machine with 2G of memory. I compiled the kernel with the 4G memory option. How much address space should each process be able to address? Does this change if I use the 64G option? I'm after 2.4 information. Right now I am running on a 2.2 kernel and it looks like the user processes are limited to ~1G. Thanks, Jim - 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's Southbridge bug: Latest (pseudo-)patch
On Sat, May 19, 2001 at 11:07:21AM +0200, Axel Thimm <[EMAIL PROTECTED]>
wrote:
> if( KT133A || KT133 || KX133 ) {
> if( Mainboard=="Epox 8KTA-3(+)" && BIOS>="8kt31417" )
> return 0; /* EPOX already fixed it their way. */
> #ifdef NEW_PATCH
> Offset 76: Set bit5=0 and bit4=1 ("every PCI master grand")
> #else /* this is already part of 2.4.4 */
> Offset 70: Set bit1=0 ("PCI Delay Transaction = 0")
one thing I found out using triel and error is that setting "PCI Delay
Transaction" to enabled causes data corruption on WRITE to my ide drives
connected to an Promise Ultra 100 PCI controlelr (I didn't get any
corruption on the devices connected to the via ide interface, presumably
because my bios already had the right fix).
So, while the every pci master grant setting apperently fixes the internal
via ide interface corruption the PCI Delay Transaction option also must be
buggy (or my promise controller is) and causes data corruption at least
with an additional promise ultra 100.
board: asus cuv4x-d (Apollo MVP3 AGP + via686b southbridge)
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
-
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
[ OK, this time I cc'ed netdev 8-) ] On Fri, 1 Jun 2001, Alan Cox wrote: > Please re-read your comment. Then think about it. Then tell me how rate > limiting differs from caching to the application. For caching, the kernel establishes the rate with which the info is updated. There's nothing wrong, but how is the application to know if the value is actual or cached (from when, until when) ? That means that a single application that needs data more often than the caching rate will get bogus data and not know about it. With rate limiting, you always get new values, unless the limit is exceeded. When the limit is exceeded, you log and: - block any request until some timer is expired. The application can detect that it's been blocked and react. You can detect if there are several calls waiting and return the same value to all. - return error until some timer is expired. The application can again detect that. In both cases, the application is also capable of guessing the value of the delay. For one application which follows the rules (doesn't need data more often than the caching rate or doesn't exceed the rate limit) there is no difference, I agree. But when somebody is playing tricks while you need data, you have the chance of detecting this by using rate limits. And yes, I agree that either of them (cache or rate limit) should be modifiable through proc entry/ioctl/whatever. -- 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/
VIA timer bug
Hello! I hope this is the right place for my request. I have heard about a VIA sytem timer bug. I have a Via KX-133 (for athlon) board and the following problem: Once the bug is triggered, the system timer goes crazy (i think it is the system timer, i am not sure). following things happen then: X blanks the screen all the time, licq auto-aways or auto-disconnects... the bug is triggered by high disk throughput (copying large amounts of data from one hd to another) and it often occurs during open-gl. I have heard, that there is a patch since 2.4.4-ac?, so i upgraded to 2.4.5, but the bug still occurs. do i have to set up something in make menuconfig? if so, what? -regards, Jonas Diemer PS: I have NOT subscribed to the list, so please CC me your response. PPS: Sorry for posting twice, the first posting lacked a subject entry. - 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 oops
(many apologies for repost - i'll actually attach the attachment this
time)
I am running gnome netleds_applet version 0.9.1 and it is sporadically
dieing, with a various kernel oops warnings in my syslogs. I caught
the last one and ran it through ksymoops - I've attached the output of
that. It happens every few days and doesn't seem to be caused by
anything specific that I can see. Always the same program, and the
overall stability of the system seems unaffected. If it makes any
difference I have two copies of netleds running (they monitor eth0
and ppp0 separately). The processor is a Cyric 6x86MX233. Any other
information you'd find useful, please contact me!
yours
David Harris
--
David Harris, 10 Carlton Way, | My name is Inigo Montoya.
Cambridge CB4 2BZ Tel: 01223 524413 |You killed my father.
Mob: 07977 226941 Fax: 07970 091596 | Prepare to die.
http://www.srcf.ucam.org/~djh59/ |
ksymoops 2.4.1 on i686 2.4.4. Options used
-V (default)
-k /proc/ksyms (specified)
-l /proc/modules (specified)
-o /lib/modules/2.4.4/ (default)
-m /boot/System.map-2.4.4 (specified)
Unable to handle kernel paging request at virtual address 856d1cfc
c013690b
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010203
eax: 32ae102f ebx: 005e1a04 ecx: c2e62900 edx: 0001
esi: 08095529 edi: 404e5ded ebp: 005e1a04 esp: c1ebbf54
ds: 0018 es: 0018 ss: 0018
Process netleds_applet (pid: 501, stackpage=c1ebb000)
Stack: c013715a 005e1a04 08095528 404e5ded c33ba000 c012c4f7 c33ba000
0001 01b6 c1ebbf84 000f c33ba000 08095528 404e5ded c33ba000
c2e62900 0400 c012c80c c33ba000 01b6 c1eba000
Call Trace: [] [] [] [] []
Code: 00 83 f8 02 0f 85 eb 00 00 00 80 7a 01 2e 0f 85 e1 00 00 00
>>EIP; c013690b<=
Trace; c013715a
Trace; c012c4f7
Trace; c012c80c
Trace; c0106ac3
Trace; c010002b
Code; c013690b
<_EIP>:
Code; c013690b<=
0: 00 83 f8 02 0f 85 add%al,0x850f02f8(%ebx) <=
Code; c0136911
6: eb 00 jmp8 <_EIP+0x8> c0136913
Code; c0136913
8: 00 00 add%al,(%eax)
Code; c0136915
a: 80 7a 01 2e cmpb $0x2e,0x1(%edx)
Code; c0136919
e: 0f 85 e1 00 00 00 jnef5 <_EIP+0xf5> c0136a00
Kernel oops
I am running gnome netleds_applet version 0.9.1 and it is sporadically dieing, with a various kernel oops warnings in my syslogs. I caught the last one and ran it through ksymoops - I've attached the output of that. It happens every few days and doesn't seem to be caused by anything specific that I can see. Always the same program, and the overall stability of the system seems unaffected. If it makes any difference I have two copies of netleds running (they monitor eth0 and ppp0 separately). The processor is a Cyric 6x86MX233. Any other information you'd find useful, please contact me! yours David Harris -- David Harris, 10 Carlton Way, | My name is Inigo Montoya. Cambridge CB4 2BZ Tel: 01223 524413 |You killed my father. Mob: 07977 226941 Fax: 07970 091596 | Prepare to die. http://www.srcf.ucam.org/~djh59/ | - 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/
union mounting file systems... retry #1
Hi all After reading "Wonderful World of Linux 2.4" (Penguin Wizard) at http://www.linuxdevices.com/files/misc/WWOL2.4.html, I found somthing about union mounting file systems under "Linux internals", (seventh paragraph). I've been trying to find out how to do this, but I just fail. Some places I get the expression that I just have to mount the first file system, and afterwards, just use the option "-o union" to mount, but still, the originally mounted file system will disappear as soon as I mount another on top of it. Q: Is it possible to union mount file systems in linux 2.4 (currently using 2.4.5)? Q: Should I just go home and start doing my homework? Best regards roy - 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.[35] + Dell Poweredge 8450 + Oops on boot
Just before I got your suggestion, I tried just that (disabling the PNP Bios) .. I looked up the trace addresses in the system.map (which I forgot to include) and saw that it was from the pnp bios) .. It did the trick :) I will also see if there's an updated bios available .. Thanks! Terry > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Alan Cox > Sent: Friday, June 01, 2001 10:25 AM > To: Terry Katz > Cc: Linux Kernel > Subject: Re: 2.4.[35] + Dell Poweredge 8450 + Oops on boot > > > > isapnp: Scanning for PnP cards... > > isapnp: No Plug & Play device found > > PnP: PNP BIOS installation structure at 0xc00f68f0 > > PnP: PNP BIOS version 1.0, entry at f:a611, dseg at 400 > Unable to > > handle kernel paging request at virtual address ff48 printing > > eip: 3c9c *pde = > > Oops: 0002 > > CPU:0 > > EIP:0068:[<3c9c>] > > Your Pnp BIOS crahsed somewhere in the BIOS when we called it > - Disable PnP bios support or get a bios update > - > 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/ - 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/
HowTo: Kernel verbose logging.
Dear subscribers. I'm currently experimenting with a third party application, VMWare's GSX-server. This application allows you to run multiple virtual servers on a single physical computer, providing there are enough resources, such as memory, available. The problem is that this application under certain circumstances completely freezes the server, and I mean completely stone dead. The only thing to do is to turn off the power. I'm currently discussing the problem with the VMWare support staff but we're kind of stuck, so I would like to collect more data about the problem. Therefore I would like to know if it's possible to compile the used kernel (2.2.18) in some kind of verbose logging mode? Ultimately every kernel call should be logged, with parameters and everything. I realize that this probably isn't feasible but perhaps there is something that takes me halfway? Kind regards, Ola Theander - 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
Alan Cox <[EMAIL PROTECTED]> [01/06/01 10:32]: > > 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. > > Please re-read your comment. Then think about it. Then tell me how rate limiting > differs from caching to the application. > I'd argue for rate limiting as the application only gets back new data, never a cached value n times in a row. With caching, you'd have to let the application know when the cached value was last read and how long it will be cached for. With rate limiting, you'd just block the app and get the new data to the app once the timer has expired. Or, if the app doesn't read the data until after the timer has expired, it will not block at all. Seems to me that you'd have less redundant application processing with rate limiting. - 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
> I'd argue for rate limiting as the application only gets back new data, > never a cached value n times in a row. Which is worse. I cat the proc file a few times and your HA app is unlucky. It now gets *NO* data for five minutes. If we cache the values it gets approximate data - 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/
Strange bug (?) in 2.4.5
Hi I suspect that I've found a bug in 2.4.5. I use isolinux (1.62) for CD-booting, and its configuration file is like this: default linux display some.msg label linux kernel linux append ramdisk_start=0 ramdisk_size=12288 root=/dev/rd/0 load_ramdisk=1 initrd=initrd The kernel has devfs enabled and is configured to automatically mount /dev on boot. This is what happens: RAMDISK: Compressed image found at block 0 Freeing initrd memory: 3682 k freed VFS: Mounted root (ext2 filesystem). Mounted devfs on /dev VFS: Mounted root (ext2 filesystem). change_root: old root has d_count=5 Mounted devfs on /dev Trying to unmount old root ... okay Freeing unused kernel memory: 96 k freed Kernel panic: No init found. Try passing init= option to kernel. Okay, this is strange, because I haven't touched the initrd image since the last time it worked. :-) So, what I tried next was replacing the kernel with the 2.4.4 that I had used before (identical kernel configuration), wrote another CD-R, and voila, it worked (I've even repeated this twice (2.4.4 and 2.4.5), same result each time). So, something is definitely wrong. On the other hand, 2.4.5 works fine when booting from floppies (using syslinux) and this configuration: default linux display some.msg label linux kernel linux append ramdisk_start=0 load_ramdisk=1 prompt_ramdisk=1 ramdisk_size=12288 root=/dev/fd/0 Thanks, Ole André Vadla Ravnås - 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, jamal wrote: > Jeff, Thanks for copying netdev. Wish more people would do that. Shame on me, I should have thought of that too... I joined lkml only about 2 weeks ago because netdev related topics are sometimes discussed only there... > Not really. > > One idea i have been toying with is to maintain hysteris or threshold of > some form in dev_watchdog; AFAIK, dev_watchdog is right now used only for Tx (if I'm wrong, please correct me!). So how do you sense link loss if you expect only high Rx traffic ? > example: if watchdog timer expires threshold times, you declare the link > dead and send netif_carrier_off netlink message. > On recovery, you send netif_carrier_on I assume that you mean "on recovery" as in "first succesful hard_start_xmit". > Assumption: > If the tx path is blocked, more than likely the link is down. Yes, but is this a good approximation ? I'm not saying that it's not, I'm merely asking for counter-arguments. -- 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: 2.4.[35] + Dell Poweredge 8450 + Oops on boot
> isapnp: Scanning for PnP cards... > isapnp: No Plug & Play device found > PnP: PNP BIOS installation structure at 0xc00f68f0 > PnP: PNP BIOS version 1.0, entry at f:a611, dseg at 400 Unable to > handle kernel paging request at virtual address ff48 printing eip: > 3c9c *pde = > Oops: 0002 > CPU:0 > EIP:0068:[<3c9c>] Your Pnp BIOS crahsed somewhere in the BIOS when we called it - Disable PnP bios support or get a bios update - 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.[35] + Dell Poweredge 8450 + Oops on boot
> my config settings .. The settings, and kernels I'm trying (at least > 2.4.3-ac9) work on other Dell boxes here, such as the 2450, and 6350 > (with same internals, ie the raid (dual channel) + nic)... > > Quick spec of the box is: > Dell PowerEdge 8450 > 4x550 Xeon / 2gig > Onboard Adaptec SCSI > AMI MegaRaid Single Channel 16mb > Dual Port Intel EtherExpress Pro/100+ Can you check the firmware on the PERC 2/SC? (You claim you tried a different system with a dual-channel, but that would be the PERC 2/DC). There's a bug in the megaraid driver for some versions of the PERC 2/SC firmware which can cause an oops when the megaraid driver loads. It's fixed by upgrading to v3.13 firmware, available by link on http://domsch.com/linux. That *shouldn't* be the problem, as I don't see the megaraid sign-on message, but it could be. Also, the onboard SCSI adapter isn't an Adaptec, it's a Symbios 810. Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Solutions www.dell.com/linux - 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
> 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. Please re-read your comment. Then think about it. Then tell me how rate limiting differs from caching to the application. Alan - 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, Thanks for copying netdev. Wish more people would do that.
On Fri, 1 Jun 2001, Bogdan Costescu wrote:
> On Fri, 1 Jun 2001, Jeff Garzik wrote:
>
> > The loss and regain of link status should be proactively signalled to
> > userspace using netlink or something similar.
>
> [ For the general discussion ]
> I fully agree, but I just wanted to give an example of legit use from
> user space of _current_ values from hardware.
>
> > 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...
>
> [ Link status details ]
> Just that not all NICs have hardware support (and/or not all drivers use
> these facilities) for link status change notification using interrupts.
> Right now, most drivers _poll_ for media status and based on the poll
> rate, netif_carrier routines are (or should be) called. We can't make the
> poll rate very small for the general case, as MII access is time
> consuming (same discussion was some months ago when the bonding driver
> was updated). However, for users who know that they need this info to be
> more accurate (at the expense of CPU time), polling through ioctl's is the
> only solution.
Not really.
One idea i have been toying with is to maintain hysteris or threshold of
some form in dev_watchdog;
example: if watchdog timer expires threshold times, you declare the link
dead and send netif_carrier_off netlink message.
On recovery, you send netif_carrier_on
Assumption:
If the tx path is blocked, more than likely the link is down.
cheers,
jamal
-
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.[35] + Dell Poweredge 8450 + Oops on boot
Hello, I'm trying to get 2.4 to run on a Dell Poweredge 8450, with no luck so far .. Below is what I get when I boot a 2.4 kernel (happens in 2.4.3(-ac9) and 2.4.5(-ac5), 2.2.19 works fine).. I've attached a full boot log and my config settings .. The settings, and kernels I'm trying (at least 2.4.3-ac9) work on other Dell boxes here, such as the 2450, and 6350 (with same internals, ie the raid (dual channel) + nic)... Quick spec of the box is: Dell PowerEdge 8450 4x550 Xeon / 2gig Onboard Adaptec SCSI AMI MegaRaid Single Channel 16mb Dual Port Intel EtherExpress Pro/100+ Any ideas as to why this is happening, are welcome :) If any more information is needed, it can be provided ... Thanks, Terry . . . isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found PnP: PNP BIOS installation structure at 0xc00f68f0 PnP: PNP BIOS version 1.0, entry at f:a611, dseg at 400 Unable to handle kernel paging request at virtual address ff48 printing eip: 3c9c *pde = Oops: 0002 CPU:0 EIP:0068:[<3c9c>] EFLAGS: 00010246 eax: 0001 ebx: 0002 ecx: 0001 edx: 0313 esi: edi: ebp: c3feff4a esp: c3feff28 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c3fef000) Stack: d14e c3feff4a c3feff48 0002 0313 028e ff80997b 5889 d4e0 8066 d4e0a81e a7ee a6ec 0018a6c4 0018 e478 8080c02f 0078 00780070 ff82 c3feff88 Call Trace: [] [] [] [] [] Code: Bad EIP value. <0>Kernel panic: Attempted to kill init! poweredge-2.4.config LILO 21.7-5 Loading Linux Linux version 2.4.5-ac5 (root@dev) (gcc version 2.95.4 20010506 (Debian prerelease)) #1 SMP Fri Jun 1 08:48:12 EDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009e000 (usable) BIOS-e820: 0009e000 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 03ff8000 (usable) BIOS-e820: 03ff8000 - 03fffc00 (ACPI data) BIOS-e820: 03fffc00 - 0400 (ACPI NVS) BIOS-e820: 0400 - 8000 (usable) BIOS-e820: fec0 - 0001 (reserved) 1152MB HIGHMEM available. found SMP MP-table at 000f6570 hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. hm, page 0009e000 reserved twice. hm, page 0009f000 reserved twice. On node 0 totalpages: 524288 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 294912 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: INTELProduct ID: OCPRF100 APIC at: 0xFEE0 Processor #7 Pentium(tm) Pro APIC version 17 Processor #4 Pentium(tm) Pro APIC version 17 Processor #5 Pentium(tm) Pro APIC version 17 Processor #6 Pentium(tm) Pro APIC version 17 I/O APIC #0 Version 19 at 0xFEC0. Processors: 4 Kernel command line: auto BOOT_IMAGE=Linux ro root=801 console=ttyS0 Initializing CPU#0 Detected 550.052 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1097.72 BogoMIPS Memory: 2059512k/2097152k available (1309k kernel code, 37216k reserved, 390k data, 200k init, 1179648k highmem) Dentry-cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Buffer-cache hash table entries: 131072 (order: 7, 524288 bytes) Page-cache hash table entries: 524288 (order: 9, 2097152 bytes) CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 2048K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 2048K Intel machine check reporting enabled on CPU#0. CPU0: Intel Pentium III (Katmai) stepping 03 per-CPU timeslice cutoff: 5850.23 usecs. enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: Booting processor 1/4 eip 2000 Initializing CPU#1 masked ExtINT on CPU#1 ESR value before enabling vector: ESR value after enabling vector: Calibrating delay loop... 1097.72 BogoMIPS CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 2048K Intel machine check reporting enabled on CPU#1. CPU1: Intel Pentium III (Katmai) stepping 03 Booting processor 2/5 eip 2000 Initializing CPU#2 masked ExtINT on CPU#2 ESR value before enabling vector: ESR value after enabling vector: Calibrating delay loop... 1097.72 BogoMIPS CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 2048K Intel machine check reporting enabled on CPU#2. CPU2: Intel Pentium III (Katmai) stepping 03 Booting processor 3/6 eip 2000
Re: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis
On Fri, 1 Jun 2001, David S. Miller wrote: > Don't such HA apps need to run as root anyways? Not necessarily, but eventually you can let root (CAP_NET_ADMIN, anyway) go through without any limitations, root can bring down the system at will in other ways. In addition, the rate limiting solution allows a warning to be issued when the limit is exceeded, so that the poor sysadmin knows what hit him 8-) -- 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: [PATCH] for Linux IRDA initialisation bug 2.4.5
On Fri, 1 Jun 2001 23:32:46 +1000, Matt Chapman <[EMAIL PROTECTED]> wrote: >I've found that if you compile IRDA into the kernel, irda_proto_init >gets called twice - once at do_initcalls time, and once explicitly >in do_basic_setup - eventually resulting in a hang (as >register_netdevice_notifier gets called twice with the same struct, >and it's list becomes circular). The suggested patch has one non-obvious side effect which somebody in irda needs to verify is OK. Previously irda_proto_init() and irda_device_init() were called after every other driver had initialized. Now irda_proto_init() is called based on the object order in the top level Makefile, so irda is initialized before i2c, telephony, acpi and mddev. Is this a valid initialization order? If not, move DRIVERS-$(CONFIG_IRDA) += drivers/net/irda/irda.o to the end of the drivers list and document why it needs to be there. - 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: [kbuild-devel] Re: Remaining undocumented Configure.help symbols
On Thu, May 31, 2001 at 07:10:55PM -0400, Eric S. Raymond wrote: > Jim Freeman <[EMAIL PROTECTED]>: > > The verbiage in these entries seems 'make config' / text-interaction > > -centric. Granted, that's likely the context most kernel builders will > > use, but it would seem fair to at least consider a broader audience > > who may be using more gui-ish tools wrapped around extant content. > > This is a general problem with almost all the existing entries, and > will have to await a future editing pass for solution. For now I think > it's more important to have consistent cues that users can recognize, > even if they're not literally appropriate. Agreed - in the meantime, just wanted to have the issue acknowledged and put on the roadmap. - 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/
HDD Errors ?!
Hi All,
today I found this in my /var/log/messages:
Jun 1 05:26:47 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:26:47 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25358813, sector=25165970
Jun 1 05:26:47 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 25165970
Jun 1 05:26:47 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_read_inode: unable to read inode block - inode=1570229, block=3145746
Jun 1 05:26:53 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:26:53 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25358813, sector=25165970
Jun 1 05:26:53 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 25165970
Jun 1 05:26:53 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_write_inode: unable to read inode block - inode=1570229, block=3145746
Jun 1 05:27:18 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:27:18 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25096667, sector=24903824
Jun 1 05:27:18 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 24903824
Jun 1 05:27:18 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_read_inode: unable to read inode block - inode=1553880, block=3112978
Jun 1 05:27:23 radius kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Jun 1 05:27:23 radius kernel: hda: read_intr: error=0x40 {
UncorrectableError }, LBAsect=25096667, sector=24903824
Jun 1 05:27:23 radius kernel: end_request: I/O error, dev 03:06 (hda),
sector 24903824
Jun 1 05:27:23 radius kernel: EXT2-fs error (device ide0(3,6)):
ext2_write_inode: unable to read inode block - inode=1553880, block=3112978
It's a disk error or a FS error ? What can I do to fix the problem ? I
500Km distant from this machine :-(
and I want made some check remotely before reboot it.
Any suggestion ?
Thanks in advance.
Roberto Fichera.
-
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
Looks like -ac6 has fixed this problem :) -- 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 [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, Jeff Garzik wrote:
> The loss and regain of link status should be proactively signalled to
> userspace using netlink or something similar.
[ For the general discussion ]
I fully agree, but I just wanted to give an example of legit use from
user space of _current_ values from hardware.
> 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...
[ Link status details ]
Just that not all NICs have hardware support (and/or not all drivers use
these facilities) for link status change notification using interrupts.
Right now, most drivers _poll_ for media status and based on the poll
rate, netif_carrier routines are (or should be) called. We can't make the
poll rate very small for the general case, as MII access is time
consuming (same discussion was some months ago when the bonding driver
was updated). However, for users who know that they need this info to be
more accurate (at the expense of CPU time), polling through ioctl's is the
only solution.
[ Back to general discussion ]
So far, to the problem of too often access to hardware, 2 solutions were
proposed:
1. cache the values. You can then let the user shoot him-/her-self in the
foot by making too many ioctl calls. But this prevent any legit use of
current hardware state.
2. rate limiting. You don't let the user access the hardware too often (to
be defined), so he/she can't shoot his-/her-self in the foot. Legit use
of current hardware state is possible.
IMHO, solution 2 is much better. Can you find situations when it's not ?
--
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/
Promise Ultra100 TX2 Issue
Hi all, I have a system running that uses two Promise Ultra66 cards (PDC20262). However, the hard disks are capible of Ultra100 transfer rates. I needed an Ultra66 card for another machine, so I decided to upgrade this one's cards to Ultra100. I purchased a pair of Promise Ultra100 TX2's so that the hard disks could run at their full speed. However, these new cards do not seem to work properly. I upgraded the kernel to 2.2.19 (from 2.2.18) while still using the old cards, just to verify everything worked. After verifing everything came back up alright, I swaped the cards. After the swap, it seemed that everthing would be fine, except that whenever I try to write more than a few bytes to the disk, the system locks hard, no oops or anything else. I did notice that when booting up with the new card, these lines PDC20268: IDE controller on PCI bus 00 dev 78 PDC20268: chipset revision 1 PDC20268: not 100% native mode: will probe irqs later PDC20268: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode. ide2: BM-DMA at 0xb000-0xb007, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0xb008-0xb00f, BIOS settings: hdg:pio, hdh:pio PDC20268: IDE controller on PCI bus 00 dev 88 PDC20268: chipset revision 1 PDC20268: not 100% native mode: will probe irqs later PDC20268: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode. ide4: BM-DMA at 0xc400-0xc407, BIOS settings: hdi:pio, hdj:pio ide5: BM-DMA at 0xc408-0xc40f, BIOS settings: hdk:pio, hdl:pio tell me that the disks are using pio, instead of DMA like they were with the old card. To get more information, I started to look in /proc: With the old, Ultra66 cards in, this is the report from /proc/ide/pdc202xx PDC20262 Chipset. --- General Status - Burst Mode : enabled Host Mode: Normal Bus Clocking : 33 PCI Internal IO pad select: 6 mA Status Polling Period: 15 Interrupt Check Status Polling Delay : 15 --- Primary Channel Secondary Channel - enabled enabled 66 Clocking enabled enabled Mode PCI Mode PCI FIFO Empty FIFO Empty --- drive0 - drive1 drive0 -- drive1 -- DMA enabled:yes yes yes yes DMA Mode: UDMA 4 UDMA 4 UDMA 4UDMA 4 PIO Mode: PIO 4PIO 4 PIO 4PIO 4 However, with the new card in (no kernel changes), the report appears to be confused PDC20268 TX2 Chipset. --- General Status - Burst Mode : enabled Host Mode: Tri-Stated Bus Clocking : 100 External IO pad select: 10 mA Status Polling Period: 15 Interrupt Check Status Polling Delay : 15 --- Primary Channel Secondary Channel - enabled enabled 66 Clocking enabled enabled Mode MASTER Mode MASTER ErrorError --- drive0 - drive1 drive0 -- drive1 -- DMA enabled:yes yes yes yes DMA Mode: PIO--- PIO--- PIO---PIO--- PIO Mode: PIO ?PIO ? PIO ?PIO ? (btw, how do I generate a report for the 2nd Promise card in the system?) I've tried many different combinations of the settings in the "Block Devices" portion of the kernel, but nothing seems to help the situation. Thanks for the help! Ryan Allgaier I'm using Linux-2.2.19 with the following patches - ide.2.2.19.05042001.patch - linux-2.2.19-reiserfs-3.5.32-patch - raid-2.2.19-A1 - linux-2.2.19-ow1 The system is a Athlon 800, running on an Abit KA7 with the latest BIOS, 512mb RAM. This motherboard does not have 66Mhz PCI slots, AFAIK. Both Promise Ultra100 TX2 cards were put into the exact same PCI slots that the Ultra66's were removed from. Here's an lspci -vv 00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [PCI-PCI Bridge] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
[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/
