Re: test12-pre4 drivers/net/dummy
the fix is in module.h which needs extra parens in the def of set_module_owner... Jeff On Mon, 4 Dec 2000, Mohammad A. Haque wrote: > Patch posted here... > http://marc.theaimsgroup.com/?l=linux-kernel=97590235825341=2 > > "Garst R. Reese" wrote: > > > > Fails to compile module at line 103, > > invalid type argument of -> > > Sorry if this well known. > > Garst > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > -- > > = > Mohammad A. Haque http://www.haque.net/ >[EMAIL PROTECTED] > > "Alcohol and calculus don't mix. Project Lead >Don't drink and derive." --Unknown http://wm.themes.org/ >[EMAIL PROTECTED] > = > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre4
On Sun, 3 Dec 2000, Mohammad A. Haque wrote: > Was borking on dummy.c. This seemed to fix it. Verification please? > > gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11/include -Wall > -Wstrict-prototypes -O6 -fomit-frame-pointer -fno-strict-aliasing -pipe > -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include > /usr/src/linux-2.4.0-test11/include/linux/modversions.h -c -o dummy.o > dummy.c > dummy.c: In function `dummy_init_module': > dummy.c:103: invalid type argument of `->' > make[2]: *** [dummy.o] Error 1 > No, module.h needs fixing. I guess I didn't send that one to Alan... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0test11: some issues and a possible show stopper
Reading the article in the German computer magazine c't that Linux 2-4
is scheduled for release in December, and that Linux complained people
do not want to test the new kernel, I decided to test it.
The Hardware was: Spacewalker/Shuttle AV11 (VIA Apollo Pro chipset),
Intel Celeron-500 ("boxed"), 128MB PC133 SD-ROM (Infineon, no crap),
EIDE IBM hardisk (4GB, supporting UDMA 33).
[If you need more detail, I can provide them]
First the lesser important issues:
During config I noticed that documentation is missing for CONFIG_INPUT
(which is later required for USB), CONFIG_NLS_UTF8 (which is probably
even less clear as 88591 or CP850).
Some source files produced an assembler warning about an Indirect lcall
without '*'
When booting, the kernel said
"Unknow bridge resource 0; assuming transparent". I don't know what
this means.
When typing "cat /proc/kmsg" I noticed that the process is not
interuptible.
Loading the keymap failed, but it seems SuSE Linux 7.0 is not quite 3.4-
ready (util-linux, modutils, e2fsprogs too old).
I also got "EXT2 check option not supported", "can't locate module
"vfat", probably because of old modutils however).
During some heavy disk I/O I got the impression that buffer writes are
delayed significantly, and that reading can be delayed by several
seconds when there is "writing back dirty buffers".
Finally I got a "gzip -t" CRC error on the kernel tar archive that was
without error when tried with 2.2.17. This is the possible show
stopper. The syslog messages did not report any problem (harddisk
operating in UDMA 33 mode, using a proper cable).
Documentation/sysctl/kernel.txt still is 2.2.10!
After hacking the kernel I got a conflict between
and , but it was too late to investigate. (I had done
over 4 hours merging rejected diffs, and I was tired from pressing C-d
C-d C-n in Emacs ;-))
Regards,
Ulrich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Soundconfig
Jordi Colomer writes: > There is a little bug in the kernel file drivers/sound/Config.in for ARM > machines. This mail has been forwarded to the ARM Linux lists since this is not in the standard kernel tree (yet). _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops in pdev_sort_resources
Alpha DP264, test12. Panic during boot.
I copied this from the console (by hand):
swapper(1): Oops 0
pc = [] ra = [] ps =
v0 = fc003ff70300 t0 = 0001 t1 = 01f7
t2 = 01f0 t3 = t4 = 03f6
t5 = 03f6 t6 = 0001 t7 = fc00015f8000
s0 = s1 = fc003ff6a8b8 s2 =
s3 = s4 = s5 =
s6 =
a0 = a1 = a2 =
a3 = a4 = a5 =
t8 = t9 = t10=
t11= pv = fc33f260 at =
gp = fc4b2000 sp = fc00015fbd20
Code: a4ca0010 ldq t5,16(s1)
a4aa0008 ldq t4,8(s1)
c3e3 br .+16
47ff041f or zero,zero,zero
2fe0 ldq_u zero,0(v0)
47e9040b or zero,s0,s2
*a52b ldq s0,0(s2)
40c50524 subq t5,t4,t3
Trace:310080 310080 310080 310098 310630 310080 310604 3105d8 310604
Kernel panic: Attempted to kill init!
Ksymoops (2.3.5) refused to process it (couldn't find the Code line) but
it did locate this code in pdev_sort_resources() in
drivers/pci/setup-res.c, which was compiled as
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mno-fp-regs -ffixed-8
-mcpu=ev6 -Wa,-mev6-c -o setup-res.o setup-res.c
resulting in:
ldq $6,16($10)
ldq $5,8($10)
br $31,$L911
.align 4
$L913:
mov $9,$11 list = list->next
$L911:
ldq $9,0($11) ln = list->next
subq $6,$5,$4
in which $L913: is the top of the loop:
for (list = head; ; list = list->next) {
unsigned long size = 0;
struct resource_list *ln = list->next;
if (ln)
size = ln->res->end - ln->res->start;
if (r->end - r->start > size) {
tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
tmp->next = ln;
tmp->res = r;
tmp->dev = dev;
list->next = tmp;
break;
}
}
So, presumably, near the end of the loop list->next is NULL and
the line
struct resource_list *ln = list->next;
causes the oops.
Dr. Tom Holroyd
"I am, as I said, inspired by the biological phenomena in which
chemical forces are used in repetitious fashion to produce all
kinds of weird effects (one of which is the author)."
-- Richard Feynman, _There's Plenty of Room at the Bottom_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: IDE_TAPE problem wiht ONSTREAM DI30
On Sun, 3 Dec 2000, Eckhard Jokisch wrote: > Am Don, 30 Nov 2000 schrieben Sie: > > On Thu, Nov 30, 2000 at 04:26:09PM +, Eckhard Jokisch wrote: > > > > > > I tried the ide-tape driver for several weeks now. And after some time during > > > writing or reading tar stops because of errors. > > > > > > Error messages are: > > > Nov 30 15:32:20 kernel: ide-tape: ht0: I/O error, pc = 8, key = 0, > > > asc = 0, ascq = 2 Nov 30 15:32:25 eckhard last message repeated 1000 times > > > Nov 30 15:32:25 kernel: ide-tape: ht0: unrecovered read error on logical block >number 461706, skipping You have to love the new ARD media... > > > > I ran into such problems since februari or so and have been in contact with > > the ide-tape developers and Onstream about it. > > I recently volunteered to try improving the end of media handling (basicly by > > implementing early warning EOM) but so far have not had much time to work on it... > > Where can I start to do that? > Can you tell me how I can set the debug_level to 3 or 5? > Why do I get this errors on make modules when I compile the driver with > IDETAPE_DEBUG_LOG_VERBOSE to 1 in ide-tape.c?: gcc -D__KERNEL__ > -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer > -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 > -malign-functions=4 -DMODULE -DMODVERSIONS -include > /usr/src/linux/include/linux/modversions.h -c -o ide-tape.o ide-tape.c > ide-tape.c: In function `idetape_sense_key_verbose': ide-tape.c:1395: warning: > function returns address of local variable ide-tape.c: In function > `idetape_command_key_verbose': ide-tape.c:1413: parse error before `case' > ide-tape.c:1424: warning: function returns address of local variable make[2]: > *** [ide-tape.o] Error 1 make[2]: Leaving directory > `/src/2.4-test11/drivers/ide' make[1]: *** [_modsubdir_ide] Error 2 make[1]: > Leaving directory `/src/2.4-test11/drivers' make: *** [_mod_drivers] Error 2 This I can fix, but the decoding noise makers are still in progress. Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Soundconfig
Hello, There is a little bug in the kernel file drivers/sound/Config.in for ARM machines. When I do make xconfig, an error shows up. The cause is in line 11 of this file : if [ "$CONFIG_SA1100_ASSABET" = "y" -o "$CONFIG_SA1100_BITSY" = "y" -o \ "$CONFIG_SA1100_PANGOLIN" = "y" -o $CONFIG_SA1100_FREEBIRD = "y" -o \ "$CONFIG_SA1100_YOPY" = "y" ]; then dep_tristate ' Assabet/Bitsy/Pangolin/Yopy audio support (UDA1341)' CONFIG_SOUND_UDA1341 $CONFIG_SOUND fi Note that $CONFIG_SA1100_FREEBIRD must be quoted : "$CONFIG_SA1100_FREEBIRD". That's all. Thank you for your work. Jordi Colomer. P.S. : This message was sent originally to [EMAIL PROTECTED], but he replied : "I am not actively maintaining this file any more. Please send a copy of your letter to [EMAIL PROTECTED] Feel free to quote my e-mail to other people if you think it will be helpful." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre4 drivers/net/dummy
Patch posted here... http://marc.theaimsgroup.com/?l=linux-kernel=97590235825341=2 "Garst R. Reese" wrote: > > Fails to compile module at line 103, > invalid type argument of -> > Sorry if this well known. > Garst > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test12-pre4 drivers/net/dummy
Fails to compile module at line 103, invalid type argument of -> Sorry if this well known. Garst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] inode dirty blocks Re: test12-pre4
On Sun, 3 Dec 2000, Linus Torvalds wrote:
>
> Synching up with Alan and various other stuff. The most important one
> being the fix to the inode dirty block list.
It doesn't solve the problem. If you unlink a file with dirty metadata
you have a nice chance to hit the BUG() in inode.c:83. I hope that patch
below closes all remaining holes. See analysis in previous posting
(basically, bforget() is not enough when we free the block; bh should
be removed from the inode's list regardless of the ->b_count).
Cheers,
Al
diff -urN rc12-pre4/fs/buffer.c rc12-pre4-dirty_blocks/fs/buffer.c
--- rc12-pre4/fs/buffer.c Mon Dec 4 01:01:43 2000
+++ rc12-pre4-dirty_blocks/fs/buffer.c Mon Dec 4 01:11:42 2000
@@ -1164,6 +1164,31 @@
}
/*
+ * Call it when you are going to free the block. The difference between
+ * that and bforget() is that we remove the thing from inode queue
+ * unconditionally.
+ */
+void bforget_inode(struct buffer_head * buf)
+{
+ /* grab the lru lock here to block bdflush. */
+ spin_lock(_list_lock);
+ write_lock(_table_lock);
+ remove_inode_queue(buf);
+ if (!atomic_dec_and_test(>b_count) || buffer_locked(buf))
+ goto in_use;
+ __hash_unlink(buf);
+ write_unlock(_table_lock);
+ __remove_from_lru_list(buf, buf->b_list);
+ spin_unlock(_list_lock);
+ put_last_free(buf);
+ return;
+
+ in_use:
+ write_unlock(_table_lock);
+ spin_unlock(_list_lock);
+}
+
+/*
* bread() reads a specified block and returns the buffer that contains
* it. It returns NULL if the block was unreadable.
*/
@@ -1460,6 +1485,9 @@
clear_bit(BH_Mapped, >b_state);
clear_bit(BH_Req, >b_state);
clear_bit(BH_New, >b_state);
+ spin_lock(_list_lock);
+ remove_inode_queue(bh);
+ spin_unlock(_list_lock);
}
}
diff -urN rc12-pre4/fs/ext2/inode.c rc12-pre4-dirty_blocks/fs/ext2/inode.c
--- rc12-pre4/fs/ext2/inode.c Mon Dec 4 01:01:43 2000
+++ rc12-pre4-dirty_blocks/fs/ext2/inode.c Mon Dec 4 01:13:10 2000
@@ -416,7 +416,7 @@
/* Allocation failed, free what we already allocated */
for (i = 1; i < n; i++)
- bforget(branch[i].bh);
+ bforget_inode(branch[i].bh);
for (i = 0; i < n; i++)
ext2_free_blocks(inode, le32_to_cpu(branch[i].key), 1);
return err;
@@ -484,7 +484,7 @@
changed:
for (i = 1; i < num; i++)
- bforget(where[i].bh);
+ bforget_inode(where[i].bh);
for (i = 0; i < num; i++)
ext2_free_blocks(inode, le32_to_cpu(where[i].key), 1);
return -EAGAIN;
@@ -854,7 +854,7 @@
(u32*)bh->b_data,
(u32*)bh->b_data + addr_per_block,
depth);
- bforget(bh);
+ bforget_inode(bh);
/* Writer: ->i_blocks */
inode->i_blocks -= inode->i_sb->s_blocksize / 512;
/* Writer: end */
diff -urN rc12-pre4/include/linux/fs.h rc12-pre4-dirty_blocks/include/linux/fs.h
--- rc12-pre4/include/linux/fs.hMon Dec 4 01:01:47 2000
+++ rc12-pre4-dirty_blocks/include/linux/fs.h Mon Dec 4 01:12:03 2000
@@ -1201,6 +1201,7 @@
__brelse(buf);
}
extern void __bforget(struct buffer_head *);
+extern void bforget_inode(struct buffer_head *);
static inline void bforget(struct buffer_head *buf)
{
if (buf)
diff -urN rc12-pre4/kernel/ksyms.c rc12-pre4-dirty_blocks/kernel/ksyms.c
--- rc12-pre4/kernel/ksyms.cMon Dec 4 01:01:49 2000
+++ rc12-pre4-dirty_blocks/kernel/ksyms.c Mon Dec 4 01:12:19 2000
@@ -188,6 +188,7 @@
EXPORT_SYMBOL(breada);
EXPORT_SYMBOL(__brelse);
EXPORT_SYMBOL(__bforget);
+EXPORT_SYMBOL(bforget_inode);
EXPORT_SYMBOL(ll_rw_block);
EXPORT_SYMBOL(__wait_on_buffer);
EXPORT_SYMBOL(___wait_on_page);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre4
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mno-fp-regs -ffixed-8 -mcpu=ev6
-Wa,-mev6-DEXPORT_SYMTAB -c pci.c
pci.c: In function `pci_read_bases':
pci.c:576: `tmp' undeclared (first use in this function)
pci.c:576: (Each undeclared identifier is reported only once
pci.c:576: for each function it appears in.)
--- drivers/pci/#pci.c Mon Dec 4 14:30:40 2000
+++ drivers/pci/pci.c Mon Dec 4 14:44:29 2000
@@ -540,7 +540,7 @@
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
unsigned int pos, reg, next;
- u32 l, sz;
+ u32 l, sz, tmp;
struct resource *res;
for(pos=0; poshttp://www.tux.org/lkml/
Re: multiprocessor kernel problem
In message <[EMAIL PROTECTED]> you write:
> yes, but is it a dual machine or is it an N-way SMP with N > 2? the
> other guy with iptables/SMP problems also has a quad box. could this
> perhaps be a problem only when you have more than two processors?
Yes, hacked my machine to think it had 4 cpus, and boom.
There are two problems:
(1) initialization of multiple tables was wrong, and
(2) iterating through tables should not use cpu_number_map (doesn't
matter on X86 though).
Please try attached patch.
Thanks,
Rusty,
--
Hacking time.
--- working-2.4.0-test11-5/net/ipv4/netfilter/ip_tables.c.~1~ Sat Aug 12 00:23:40
2000
+++ working-2.4.0-test11-5/net/ipv4/netfilter/ip_tables.c Mon Dec 4 16:12:44
+2000
@@ -89,10 +89,8 @@
unsigned int hook_entry[NF_IP_NUMHOOKS];
unsigned int underflow[NF_IP_NUMHOOKS];
- char padding[SMP_ALIGN((NF_IP_NUMHOOKS*2+2)*sizeof(unsigned int))];
-
/* ipt_entry tables: one per CPU */
- char entries[0];
+ char entries[0] __attribute__((aligned(SMP_CACHE_BYTES)));
};
static LIST_HEAD(ipt_target);
@@ -101,7 +99,7 @@
#define ADD_COUNTER(c,b,p) do { (c).bcnt += (b); (c).pcnt += (p); } while(0)
#ifdef CONFIG_SMP
-#define TABLE_OFFSET(t,p) (SMP_ALIGN((t)->size)*cpu_number_map(p))
+#define TABLE_OFFSET(t,p) (SMP_ALIGN((t)->size)*(p))
#else
#define TABLE_OFFSET(t,p) 0
#endif
@@ -283,7 +281,8 @@
read_lock_bh(>lock);
IP_NF_ASSERT(table->valid_hooks & (1 << hook));
table_base = (void *)table->private->entries
- + TABLE_OFFSET(table->private, smp_processor_id());
+ + TABLE_OFFSET(table->private,
+ cpu_number_map(smp_processor_id()));
e = get_entry(table_base, table->private->hook_entry[hook]);
#ifdef CONFIG_NETFILTER_DEBUG
@@ -860,7 +859,7 @@
/* And one copy for every other CPU */
for (i = 1; i < smp_num_cpus; i++) {
- memcpy(newinfo->entries + SMP_ALIGN(newinfo->size*i),
+ memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i,
newinfo->entries,
SMP_ALIGN(newinfo->size));
}
@@ -1359,7 +1358,7 @@
int ret;
struct ipt_table_info *newinfo;
static struct ipt_table_info bootstrap
- = { 0, 0, { 0 }, { 0 }, { }, { } };
+ = { 0, 0, { 0 }, { 0 }, { } };
MOD_INC_USE_COUNT;
newinfo = vmalloc(sizeof(struct ipt_table_info)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: negative NFS cookies: bad C library or bad kernel?
Trond Myklebust <[EMAIL PROTECTED]> writes: > > The problem then arises that lseek tries to cram both a returned > offset and an error value into the return values. Oops. You're right; I didn't think of this. So, I guess the best short-term solution is to fix the C library so it always uses llseek for directories and never tries something stupid like a SEEK_CUR. Then, at least it'll always work for NFSv2. I'll file a bug report. At the same time, a patch for CFS to use "small" (from a little-endian perspective) cookies couldn't hurt, so I'll do that, too. Thanks for the help. Kevin <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Linux for local languages - patch
Hi, I am Ratheesh , student of Indian Institute of Technology Madras. I am working on enabling Linux console for Local languages. As the current PSF format doesn't support variable width fonts , I have made a patch in the console driver so that it will load a user defined multi-glyph mapping table so that multiple glyphs can be displayed for a single character code. All editing operations will also be taken care of. Further, for Indian languages, there are various consonant/vowel modifiers which result in complex character clusters. So I have extended the patch to load user defined context sensitive parse rules for glyphs / character codes as well. Again, all editing operations will behave according to the parse rule specifications. Even though the patch has been developed keeping Indian languages in mind, I feel it will be applicable to many other languages (for eg. Chinese) which require wider fonts on console or user defined parsing at I/O level. Currently I have developed the patch for Kernel versions 2.2.14 and and am in the process of making it for 2.2.16 and 2.2.17. I request people to try out this patch and give comments and suggestions to me. Those who want to try out this patch can send mail to me in the address [EMAIL PROTECTED] or to [EMAIL PROTECTED] The package , containing the patch , some documentation ,utilities and sample files will come around 100 KB. Thanking you, Ratheesh --- Ratheesh K Res: 242 Tapti, IIT Madras , Chennai-36, India Tel:+91-44-4459089 Lab: Distributed Systems& Optical Networks Lab,IIT Madras Tel:+91-44-4458353 www.ratheeshkvadhyar.com[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre4
Was borking on dummy.c. This seemed to fix it. Verification please?
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11/include -Wall
-Wstrict-prototypes -O6 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include
/usr/src/linux-2.4.0-test11/include/linux/modversions.h -c -o dummy.o
dummy.c
dummy.c: In function `dummy_init_module':
dummy.c:103: invalid type argument of `->'
make[2]: *** [dummy.o] Error 1
Linus Torvalds wrote:
>
> Synching up with Alan and various other stuff. The most important one
> being the fix to the inode dirty block list.
>
> Linus
>
--
=
Mohammad A. Haque http://www.haque.net/
[EMAIL PROTECTED]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[EMAIL PROTECTED]
=
--- linux/drivers/net/dummy.c.orig Sun Dec 3 21:59:18 2000
+++ linux/drivers/net/dummy.c Sun Dec 3 22:52:13 2000
@@ -53,6 +53,8 @@
static int __init dummy_init(struct net_device *dev)
{
+ SET_MODULE_OWNER(dev);
+
/* Initialize the device structure. */
dev->hard_start_xmit= dummy_xmit;
@@ -100,7 +102,6 @@
int err;
dev_dummy.init = dummy_init;
- SET_MODULE_OWNER(_dummy);
/* Find a name for this unit */
err=dev_alloc_name(_dummy,"dummy%d");
Re: Phantom PS/2 mouse persists..
On Sun, 3 Dec 2000, Jeff V. Merkey wrote: > On Sun, Dec 03, 2000 at 05:42:03PM -0500, Steven N. Hirsch wrote: > > FWIW, USB isn't compiled into the kernel in question. > > Yes it is. I am also seeing compile problems. I will post to a new subject > since they are not mouse related, but IPVS related. I was referring to _my_ kernel, which I can assure you does not have USB compiled in. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Phantom PS/2 mouse persists..
On Mon, 4 Dec 2000, Daniel Roesen wrote: > On Sun, Dec 03, 2000 at 10:24:19AM -0500, Steven N. Hirsch wrote: > > Unfortunately, 2.2.18pre24 is still convinced that I have a PS/2 mouse > > attached to my machine. > > Nod. Which board? I'm seeing the problem with Asus CUWE. Asus P2B-DS here. Wonder what on earth they're doing differently with the Aux port? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Exporting access_process_vm
Hi, Back in September, David Howells sent in a one-line patch that just exported access_process_vm. It doesn't seem to have been applied, and there was no discussion of it. Was it simply overlooked, or was there a good reason not to apply it and no one ever replied to the list about it? I'm dragging some checkpointing code into the Wonderful World of Linux 2.4, and it'd be great if I could chuck all the scary walk-the-page-tables-and-hope-it-works code that's currently in there with more modern stuff. Thanks! -Erik This was the original message: (I can re-create the "patch" against the current release, but it seemed straight-forward enough :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Could you please apply this little patch to export access_process_vm()? Cheers, David Howells = diff -uNr linux-2.4.0-test8-orig/kernel/ksyms.c linux-2.4.0-test8/kernel/ksyms.c --- linux-2.4.0-test8-orig/kernel/ksyms.c Fri Sep 15 00:04:36 2000 +++ linux-2.4.0-test8/kernel/ksyms.c Mon Sep 11 23:39:38 2000 @@ -123,6 +123,7 @@ EXPORT_SYMBOL(find_vma); EXPORT_SYMBOL(get_unmapped_area); EXPORT_SYMBOL(init_mm); +EXPORT_SYMBOL(access_process_vm); #ifdef CONFIG_HIGHMEM EXPORT_SYMBOL(kmap_high); EXPORT_SYMBOL(kunmap_high); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test12-pre4
Synching up with Alan and various other stuff. The most important one being the fix to the inode dirty block list. Linus - pre4: - Andries Brouwer: final isofs pieces. - Kai Germaschewski: ISDN - play CD audio correctly, don't stop after 12 minutes. - Anton Altaparmakov: disable NTFS mmap for now, as it doesn't work. - Stephen Tweedie: fix inode dirty block handling - Bill Hartner: reschedule_idle - prefer right cpu - Johannes Erdfelt: USB updates - Alan Cox: synchronize - Richard Henderson: alpha updates and optimizations - Geert Uytterhoeven: fbdev could be fooled into crashing fix - Trond Myklebust: NFS filehandles in inode rather than dentry - pre3: - me: more PageDirty / swapcache handling - Neil Brown: raid and md init fixes - David Brownell: pci hotplug sanitization. - Kanoj Sarcar: mips64 update - Kai Germaschewski: ISDN sync - Andreas Bombe: ieee1394 cleanups and fixes - Johannes Erdfelt: USB update - David Miller: Sparc and net update - Trond Myklebust: RPC layer SMP fixes - Thomas Sailer: mixed sound driver fixes - Tigran Aivazian: use atomic_dec_and_lock() for free_uid() - pre2: - Peter Anvin: more P4 configuration parsing - Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync do the right thing. - Keith Owens: make mdule loading use the right struct module size - Boszormenyi Zoltan: get MTRR's right for the >32-bit case - Alan Cox: various random documentation etc - Dario Ballabio: EATA and u14-34f update - Ivan Kokshaysky: unbreak alpha ruffian - Richard Henderson: PCI bridge initialization on alpha - Zach Brown: correct locking in Maestro driver - Geert Uytterhoeven: more m68k updates - Andrey Savochkin: eepro100 update - Dag Brattli: irda update - Johannes Erdfelt: USB update - pre1: (for ISDN synchronization _ONLY_! Not complete!) - Byron Stanoszek: correct decimal precision for CPU MHz in /proc/cpuinfo - Ollie Lho: SiS pirq routing. - Andries Brouwer: isofs cleanups - Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL - me: be stricter about what we accept as a PCI bridge setup. - me: always set PCI interrupts to be level-triggered when we enable them. - me: updated PageDirty and swap cache handling - Peter Anvin: update A20 code to work without keyboard controller - Kai Germaschewski: ISDN updates - Russell King: ARM updates - Geert Uytterhoeven: m68k updates - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Phantom PS/2 mouse persists..
- Original Message - From: "Steven N. Hirsch" <[EMAIL PROTECTED]> To: "Jeff V. Merkey" <[EMAIL PROTECTED]> Cc: "Alan Cox" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, December 03, 2000 5:42 PM Subject: Re: Phantom PS/2 mouse persists.. > On Sun, 3 Dec 2000, Jeff V. Merkey wrote: > > > > On Sun, Dec 03, 2000 at 06:27:52PM +, Alan Cox wrote: > > > > > > > > I've fixed the major case. I can see no definitive answer to the other ghost > > > > PS/2 stuff (except maybe USB interactions). I take it like the others 2.4test > > > > also misreports a PS/2 mouse being present. > > > > > > > > Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected > > > > board can piece together the picture > > > I just tested 2.2.18-24 as a boot kernel with anaconda -- works great -- > > mouse problem on PS/2 system is nailed. > > I always seem to own the wierd hardware. I agree the mouse > mis-detection isn't a showstopper - just damn annoying. > > FWIW, USB isn't compiled into the kernel in question. > Definately could be your hardware. I once saw a 486 board (PcChips M571 I think) which would report a PS/2 mouse even though the port didn't even exist on the motherboard. This problem showed up on all versions of Win9x. >From what I could tell it appeared as if the BIOS had support for the PS/2 mouse port but the port pins themself had not been saudered onto the board and for some reason the board alway thaught it had a PS/2 mouse and reported as so to Windows. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ip_nat_ftp and different ports
On Mon, 4 Dec 2000, Taco IJsselmuiden wrote: > On Sun, 3 Dec 2000, Martin Josefsson wrote: > > > On Sun, 3 Dec 2000, Taco IJsselmuiden wrote: > > > > > Hi, > > > > > > I'm having trouble masquerading ftp-ports other than 20/21. > > > For some service i'm using, i need to masquerade port 42,43,62,63 for FTP > > > (I know it's weird...). > > > Now, when using 2.2.x kernels i could use > > > 'insmod ip_masq_ftp ports=21,41,42,62,63' > > > but using 2.4.0-testx the 'ports=' parameter doesn't seem to work for > > > ip_nat_ftp. > > > Is there any other param I should use (couldn't find it in the docs ;(( ) > > > > There is a ftp-multi patch that you can apply to get this working > > > > download iptables-1.2 and run 'make patch-o-matic' and apply the ftp-multi > > patch and recompile the ftp module... you're done. > hmm... iptables-1.2 ? > I can only find iptables-1.1.2 (netfilter.filewatcher.org, > netfilter.kernelnotes.org)... > Where could I find 1.2 then ?? Ouch, I was typing a little too fast there... it should be 1.1.2 > I'm running 1.1.2 right now, actually, which should have the 'ftp-multi > patch for non-standard ftp servers'... Well have you applied the ftp-multi patch? (this is a patch so that the ftp-module takes a ports parameter, the thing you probably are talking about is a bug which I and several others found in the ftp-module, these two things have nothing with each other to do.) /Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: multiprocessor kernel problem
Rusty, I have two identical machines and the problem exists on both. The machines have Megaplex II quad Pentium III Xeon PCI ISA system boards. I have 550 Pentium III Xeon, 100/512 processors. I am running test11 which I downloaded a few days ago. I have installed no patches. My iptables is 1.1.2. I compiled two version of the kernel, one is single processor and one is SMP. I can successfully run iptables on the single processor kernel and I can also get it to work with two processors using the SMP kernel. With 4 processors the system boots fine, but when I try to run iptables with 4 processors the system freezes solid. It does not write anything to the system log. We currently have iptables working on a single processor machine in our network. It typically tracks an average of 13000 connections with peaks reaching 21000 connections. It works flawlessly. We want to upgrade from 10/100 interfaces to GigE. We hoped to use the 4 processor machines to do this. I am attaching my kernel config file. If you have any ideas how to get all four processors working please let me know. Thanks Roger Rusty Russell wrote: > In message <[EMAIL PROTECTED]> you write: > > > > I have 2.4.0 test 10 and test 11 installed on a multiprocessor (Intel) > > machine. I have tried both test versions of the kernel. I configured > > the kernel for single > > and multi processor. When I boot single processor, iptables will run > > fine. When I boot the machine with the multiprocessor kernel and run > > iptables, the kernel dumps several pages of hex and the final two lines > > of output are: > > > > Killing interrupt handler > > scheduling in interrupt > > My development box (running test10pre5) is SMP, and it works fine. I > haven't updated to the latest kernel version because I like my > filesystems in one piece, and the netfilter code hasn't changed. > > What is your kernel configuration, and iptables version? Have you > patched the kernel? > > Thanks for the report, > Rusty. > -- > Hacking time. # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_M686FXSR=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MTRR is not set CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # CONFIG_LVM_PROC_FS is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set CONFIG_IP_ADVANCED_ROUTER=y CONFIG_RTNETLINK=y
Re: 2.4.0-11 AIC7xxx.o driver barfs on AHA27XX adapter
On Sun, Dec 03, 2000 at 06:15:24PM -0700, Jeff V. Merkey wrote: > > > On a four processor POCA system with dual Fast-SCSI AHA274X/VLB bus > controllers I am seeing the following timeout errors right after > the sequencer scripts are downloaded and the driver starts polling. > It does not happen when compiled in kernel, only when loaded from > an initrd image. The root FS is getting mounted properly and > probing and loading the driver. > > aborting command due to timeout: pid 00 scsi 00 channel 00 lun 00 > inquiry 00 00 00 ff 00 > > The machine then hard hangs after it gets this error and has to be > powered off in order to reboot it. I tested 2.2.18-24 with an initrd and works fine on the same hardware, BTW Jeff > > Jeff > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
Re: ip_nat_ftp and different ports
On Sun, 3 Dec 2000, Martin Josefsson wrote: > On Sun, 3 Dec 2000, Taco IJsselmuiden wrote: > > > Hi, > > > > I'm having trouble masquerading ftp-ports other than 20/21. > > For some service i'm using, i need to masquerade port 42,43,62,63 for FTP > > (I know it's weird...). > > Now, when using 2.2.x kernels i could use > > 'insmod ip_masq_ftp ports=21,41,42,62,63' > > but using 2.4.0-testx the 'ports=' parameter doesn't seem to work for > > ip_nat_ftp. > > Is there any other param I should use (couldn't find it in the docs ;(( ) > > There is a ftp-multi patch that you can apply to get this working > > download iptables-1.2 and run 'make patch-o-matic' and apply the ftp-multi > patch and recompile the ftp module... you're done. hmm... iptables-1.2 ? I can only find iptables-1.1.2 (netfilter.filewatcher.org, netfilter.kernelnotes.org)... Where could I find 1.2 then ?? I'm running 1.1.2 right now, actually, which should have the 'ftp-multi patch for non-standard ftp servers'... Greetz, Taco. --- "I was only 75 years old when I met her and I was still a kid" -- Duncan McLeod - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH - documentation for ll_rw_block and generic_make_request
Linus,
below is a patch for 2.4.0-test that adds documentation for
ll_rw_block and generic_make_request. It also corrects a type error
in a printk call.
I would really like to change a couple of names in the file:
"generic_make_request" would sound much better as "raw_rw_block".
that would highlight it's similarity to ll_rw_block, and would
remove the "generic" which seems to imply that it is possible to
replace it with a specific_make_request - which is wrong.
also
"__make_request" would sound much better as elevator_make_request, as
that is more descriptive of what it does. Also __foo() normally is
a special (e.g. no locking) case of foo(), but that is not the
case here.
Would you accept such as patch at this stage?
NeilBrown
--- drivers/block/ll_rw_blk.c 2000/12/03 23:59:07 1.1
+++ drivers/block/ll_rw_blk.c 2000/12/04 00:17:34
@@ -262,13 +262,18 @@
*
* Description:
*The normal way for buffer_heads to be passed to a device driver
- *it to collect into requests on a request queue, and allow the device
- *driver to select requests off that queue when it is ready. This works
- *well for many block devices. However some block devices (typically
- *virtual devices such as md or lvm) do not benefit from the processes on
+ *is for them to be collected into requests on a request queue, and then to
+ *allow the device driver to select requests off that queue when it is ready.
+ *This works well for many block devices. However some block devices (typically
+ *virtual devices such as md or lvm) do not benefit from the processing on
*the request queue, and are served best by having the requests passed
*directly to them. This can be achieved by providing a function to
*blk_queue_make_request().
+ *
+ * Caveat:
+ *The driver that does this *must* be able to deal appropriately with
+ *buffers in "highmemory", either by calling bh_kmap() to get a kernel mapping,
+ *to by calling create_bounce() to create a buffer in normal memory.
**/
void blk_queue_make_request(request_queue_t * q, make_request_fn * mfn)
@@ -831,6 +836,40 @@
return 0;
}
+/**
+ * generic_make_request: hand a buffer head to it's device driver for I/O
+ * @rw: READ, WRITE, or READA - what sort of I/O is desired.
+ * @bh: The buffer head describing the location in memory and on the device.
+ *
+ * generic_make_request() is used to make I/O requests of block
+ * devices. It is passed a buffer_head and a value. The
+ * %READ and %WRITE options are (hopefully) obvious in meaning. The
+ * %READA value means that a read is required, but that the driver is
+ * free to fail the request if, for example, it cannot get needed
+ * resources immediately.
+ *
+ * generic_make_request() does not return any status. The
+ * success/failure status of the request, along with notification of
+ * completion, is delivered asynchronously through the bh->b_end_io
+ * function described (one day) else where.
+ *
+ * The caller of generic_make_request must make sure that b_page,
+ * b_addr, b_size are set to describe the memory buffer, that b_rdev
+ * and b_rsector are set to describe the device address, and the
+ * b_end_io and optionally b_private are set to describe how
+ * completion notification should be signaled. BH_Mapped should also
+ * be set (to confirm that b_dev and b_blocknr are valid).
+ *
+ * generic_make_request and the drivers it calls may use b_reqnext,
+ * and may change b_rdev and b_rsector. So the values of these fields
+ * should NOT be depended on after the call to generic_make_request.
+ * Because of this, the caller should record the device address
+ * information in b_dev and b_blocknr.
+ *
+ * Apart from those fields mentioned above, no other fields, and in
+ * particular, no other flags, are changed by generic_make_request or
+ * any lower level drivers.
+ * */
void generic_make_request (int rw, struct buffer_head * bh)
{
int major = MAJOR(bh->b_rdev);
@@ -851,7 +890,7 @@
when mounting a device. */
printk(KERN_INFO
"attempt to access beyond end of device\n");
- printk(KERN_INFO "%s: rw=%d, want=%d, limit=%d\n",
+ printk(KERN_INFO "%s: rw=%d, want=%ld, limit=%d\n",
kdevname(bh->b_rdev), rw,
(sector + count)>>1,
blk_size[major][MINOR(bh->b_rdev)]);
@@ -883,9 +922,39 @@
while (q->make_request_fn(q, rw, bh));
}
-/* This function can be used to request a number of buffers from a block
- device. Currently the only restriction is that all buffers must belong to
- the same device */
+/**
+ * ll_rw_block: low-level access to block devices
+ * @rw: whether to %READ or %WRITE or maybe %READA (readahead)
Re: multiprocessor kernel problem
Rusty Russell <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> you write: > > > > I have 2.4.0 test 10 and test 11 installed on a multiprocessor (Intel) > > machine. I have tried both test versions of the kernel. I configured > > the kernel for single > > and multi processor. When I boot single processor, iptables will run > > fine. When I boot the machine with the multiprocessor kernel and run > > iptables, the kernel dumps several pages of hex and the final two lines > > of output are: > > > > Killing interrupt handler > > scheduling in interrupt > > My development box (running test10pre5) is SMP, and it works fine. yes, but is it a dual machine or is it an N-way SMP with N > 2? the other guy with iptables/SMP problems also has a quad box. could this perhaps be a problem only when you have more than two processors? > I > haven't updated to the latest kernel version because I like my > filesystems in one piece, and the netfilter code hasn't changed. > > What is your kernel configuration, and iptables version? Have you > patched the kernel? i tried 2.4.0-test10 (no patches) with iptables 1.1.2. this is an alr revolution quad6 (4 ppros). i posted this to the netfilter mailing list a while back. http://lists.samba.org/pipermail/netfilter/2000-November/005838.html> -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-11 AIC7xxx.o driver barfs on AHA27XX adapter
On a four processor POCA system with dual Fast-SCSI AHA274X/VLB bus controllers I am seeing the following timeout errors right after the sequencer scripts are downloaded and the driver starts polling. It does not happen when compiled in kernel, only when loaded from an initrd image. The root FS is getting mounted properly and probing and loading the driver. aborting command due to timeout: pid 00 scsi 00 channel 00 lun 00 inquiry 00 00 00 ff 00 The machine then hard hangs after it gets this error and has to be powered off in order to reboot it. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre3 (FireWire issue)
On Thu, Nov 30, 2000 at 11:00:07PM -0700, Dax Kelson wrote: > Linus Torvalds said once upon a time (Tue, 28 Nov 2000): > > > - pre3: > > - Andreas Bombe: ieee1394 cleanups and fixes > > Linus, Andreas, > > I've been using this same config since FireWire was merged, just tried out > test12-pre3 and got an unresolved symbol problem with raw1394.o Frankly, I don't know where the missing symbols could come from. Nothing in that area was recently changed. The patch merged into pre3 was just removing Linux 2.2 compatibility macros and fixing two bugs, symbols were not messed with. I haven't compiled pre3 myself so far, however. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18-24 with IPVS patch has compile errors
On Sun, Dec 03, 2000 at 05:52:26PM -0700, Jeff V. Merkey wrote: > > > With the 2.2.17 IPVS patch applied to 2.2.18-24, I am seeing the following > compile errors. > > -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 >-fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce > -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include >/usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o emd.o emd.c > cc -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 >-fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce > -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include >/usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o check.o check.c > cc -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 >-fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce > -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include >/usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o fsync.o fsync.c > touch: /usr/src/ute/BUILD/linux/include/linux/sdladrv.h: No such file or directory > make[2]: *** No rule to make target >`/usr/src/ute/BUILD/linux/include/linux/sdlasfm.h', needed by `sdladrv.o'. Stop. > make[2]: *** Waiting for unfinished jobs > make[2]: *** [/usr/src/ute/BUILD/linux/include/linux/sdladrv.h] Error 1 > shell-init: could not get current directory > job-working-directory: could not get current directory > > > The IPVS patch is also attached. They would seem to be unrelated, but > 2.2.18-23 builds clean with this patch. > > Jeff > Update. 2.2.18-24 requires that the patch be applied to 2.2.17 before applying the pre-patch. 2.2.18-23 didn't seem to care about patch order. Got it to build with piranha after switching the patch order. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [resync?] Re: corruption
On Sun, Dec 03, 2000 at 05:45:57PM -0500, Alexander Viro wrote: > > > On Mon, 4 Dec 2000, Andrew Morton wrote: > > > Sorry, it's still failing. It took three hours. > > Yes. For one thing, original was plain wrong wrt locking (lru_list_lock > should be held). For another, it does not take care of metadata. And > that's way more serious. What really happens: > > ext2_truncate() got a buffer_head of indirect block that is going to > die. Fine, we release the blocks refered from it and... do bforget() > on our block. Notice that we are not guaranteed that bh will actually > die here. buffer.c code might bump its ->b_count for a while, it might > be written out right now, etc. As the result, bforget() leaves the > sucker alive. It's not a big deal, since we will do unmap_underlying_metadata() > before we write anything there (if it will be reused for data) or we'll > just pick the bh and zero the buffer out (if it will be reused for metadata). > > Unfortunately, we also leave it on the per-inode dirty blocks list. Guess > what happens if inode is destroyed, page that used to hold it gets reused > and bh gets finally written? Exactly. > > Suggested fix: void bforget_inode(struct buffer_head *bh) that would > be a copy of __bforget(), except that it would call remove_inode_queue(bh) > unconditionally. And replace bforget() with bforget_inode() in those places > of ext2/inode.c that are followed by freeing the block. > > Comments? I'll do a patch, but I'ld really like to know what had already > gone into the main tree. Linus, could you put the 12-pre4-dont-use on > ftp.kernel.org? Al, I am always amazed at how rapidly you seem to be able to run down some of these file system corruption problems. You seem to understand the interaction of this layer extremely well. :-) Jeff > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Phantom PS/2 mouse persists..
On Mon, Dec 04, 2000 at 12:49:47AM +0100, Daniel Roesen wrote: > On Sun, Dec 03, 2000 at 10:24:19AM -0500, Steven N. Hirsch wrote: > > Unfortunately, 2.2.18pre24 is still convinced that I have a PS/2 mouse > > attached to my machine. > > Nod. Which board? I'm seeing the problem with Asus CUWE. Number Nine 9FX 772. Jeff > > > Best regards, > Daniel > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
2.2.18-24 with IPVS patch has compile errors
With the 2.2.17 IPVS patch applied to 2.2.18-24, I am seeing the following compile errors. -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include /usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o emd.o emd.c cc -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include /usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o check.o check.c cc -D__KERNEL__ -I/usr/src/ute/BUILD/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m386 -DCPU=386 -DMODULE -DMODVERSIONS -include /usr/src/ute/BUILD/linux/include/linux/modversions.h -c -o fsync.o fsync.c touch: /usr/src/ute/BUILD/linux/include/linux/sdladrv.h: No such file or directory make[2]: *** No rule to make target `/usr/src/ute/BUILD/linux/include/linux/sdlasfm.h', needed by `sdladrv.o'. Stop. make[2]: *** Waiting for unfinished jobs make[2]: *** [/usr/src/ute/BUILD/linux/include/linux/sdladrv.h] Error 1 shell-init: could not get current directory job-working-directory: could not get current directory The IPVS patch is also attached. They would seem to be unrelated, but 2.2.18-23 builds clean with this patch. Jeff ipvs-0.9.16-2.2.17.patch.gz
Re: Phantom PS/2 mouse persists..
On Sun, Dec 03, 2000 at 05:42:03PM -0500, Steven N. Hirsch wrote: > On Sun, 3 Dec 2000, Jeff V. Merkey wrote: > > > > On Sun, Dec 03, 2000 at 06:27:52PM +, Alan Cox wrote: > > > > > > > > I've fixed the major case. I can see no definitive answer to the other ghost > > > > PS/2 stuff (except maybe USB interactions). I take it like the others 2.4test > > > > also misreports a PS/2 mouse being present. > > > > > > > > Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected > > > > board can piece together the picture > > > I just tested 2.2.18-24 as a boot kernel with anaconda -- works great -- > > mouse problem on PS/2 system is nailed. > > I always seem to own the wierd hardware. I agree the mouse > mis-detection isn't a showstopper - just damn annoying. > > FWIW, USB isn't compiled into the kernel in question. Yes it is. I am also seeing compile problems. I will post to a new subject since they are not mouse related, but IPVS related. Jeff > > Steve > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Phantom PS/2 mouse persists..
On Sun, Dec 03, 2000 at 10:24:19AM -0500, Steven N. Hirsch wrote: > Unfortunately, 2.2.18pre24 is still convinced that I have a PS/2 mouse > attached to my machine. Nod. Which board? I'm seeing the problem with Asus CUWE. Best regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test11: kernel: waitpid(823) failed, -512
While playing with routing (zebra) and PPP I regularly see this message appearing. It always happens when pppd terminates a connection, e.g: Dec 3 23:09:08 mimas pppd[784]: Modem hangup Dec 3 23:09:08 mimas pppd[784]: Connection terminated. Dec 3 23:09:08 mimas pppd[784]: Connect time 2.0 minutes. Dec 3 23:09:08 mimas pppd[784]: Sent 499 bytes, received 977 bytes. Dec 3 23:09:08 mimas pppd[822]: Hangup (SIGHUP) Dec 3 23:09:08 mimas kernel: waitpid(823) failed, -512 Dec 3 23:09:08 mimas pppd[784]: Hangup (SIGHUP) Dec 3 23:09:08 mimas pppd[784]: Exit. The (incoming) PPP connection is tunnelled through a telnet connection so there are some other processes involved. On the outgoing side (other system also running 2.4.0-test11) I sometimes see the same message, e.g: Nov 29 23:37:08 iapetus pppd[1777]: Connection terminated. Nov 29 23:37:08 iapetus pppd[1777]: Connect time 2.5 minutes. Nov 29 23:37:08 iapetus pppd[1777]: Sent 85 bytes, received 87 bytes. Nov 29 23:37:08 iapetus pppd[1777]: Exit. Nov 29 23:37:08 iapetus kernel: waitpid(1857) failed, -512 -- Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[resync?] Re: corruption
On Mon, 4 Dec 2000, Andrew Morton wrote: > Sorry, it's still failing. It took three hours. Yes. For one thing, original was plain wrong wrt locking (lru_list_lock should be held). For another, it does not take care of metadata. And that's way more serious. What really happens: ext2_truncate() got a buffer_head of indirect block that is going to die. Fine, we release the blocks refered from it and... do bforget() on our block. Notice that we are not guaranteed that bh will actually die here. buffer.c code might bump its ->b_count for a while, it might be written out right now, etc. As the result, bforget() leaves the sucker alive. It's not a big deal, since we will do unmap_underlying_metadata() before we write anything there (if it will be reused for data) or we'll just pick the bh and zero the buffer out (if it will be reused for metadata). Unfortunately, we also leave it on the per-inode dirty blocks list. Guess what happens if inode is destroyed, page that used to hold it gets reused and bh gets finally written? Exactly. Suggested fix: void bforget_inode(struct buffer_head *bh) that would be a copy of __bforget(), except that it would call remove_inode_queue(bh) unconditionally. And replace bforget() with bforget_inode() in those places of ext2/inode.c that are followed by freeing the block. Comments? I'll do a patch, but I'ld really like to know what had already gone into the main tree. Linus, could you put the 12-pre4-dont-use on ftp.kernel.org? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Phantom PS/2 mouse persists..
On Sun, 3 Dec 2000, Jeff V. Merkey wrote: > > On Sun, Dec 03, 2000 at 06:27:52PM +, Alan Cox wrote: > > > > > > I've fixed the major case. I can see no definitive answer to the other ghost > > > PS/2 stuff (except maybe USB interactions). I take it like the others 2.4test > > > also misreports a PS/2 mouse being present. > > > > > > Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected > > > board can piece together the picture > I just tested 2.2.18-24 as a boot kernel with anaconda -- works great -- > mouse problem on PS/2 system is nailed. I always seem to own the wierd hardware. I agree the mouse mis-detection isn't a showstopper - just damn annoying. FWIW, USB isn't compiled into the kernel in question. Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Phantom PS/2 mouse persists..
On Sun, Dec 03, 2000 at 02:45:58PM -0700, Jeff V. Merkey wrote: > On Sun, Dec 03, 2000 at 06:27:52PM +, Alan Cox wrote: > > > Unfortunately, 2.2.18pre24 is still convinced that I have a PS/2 mouse > > > attached to my machine. > > > > I've fixed the major case. I can see no definitive answer to the other ghost > > PS/2 stuff (except maybe USB interactions). I take it like the others 2.4test > > also misreports a PS/2 mouse being present. > > > > Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected > > board can piece together the picture > > > I see it on pre18-23 but pre18-24 seems to be fixed. I need to test with the > anaconda installer, since I an still using a pre18-23 boot kernel for > the install. > > Jeff I just tested 2.2.18-24 as a boot kernel with anaconda -- works great -- mouse problem on PS/2 system is nailed. New problem, BTW. With Frame buffer enabled, a system here with an older S3 video card has some sickness with the mouse (???). The mouse is a giant 2" x 2" block of wavy lines. Jeff > > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > 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] > 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] Please read the FAQ at http://www.tux.org/lkml/
Re: ip_nat_ftp and different ports
On Sun, 3 Dec 2000, Taco IJsselmuiden wrote: > Hi, > > I'm having trouble masquerading ftp-ports other than 20/21. > For some service i'm using, i need to masquerade port 42,43,62,63 for FTP > (I know it's weird...). > Now, when using 2.2.x kernels i could use > 'insmod ip_masq_ftp ports=21,41,42,62,63' > but using 2.4.0-testx the 'ports=' parameter doesn't seem to work for > ip_nat_ftp. > Is there any other param I should use (couldn't find it in the docs ;(( ) There is a ftp-multi patch that you can apply to get this working download iptables-1.2 and run 'make patch-o-matic' and apply the ftp-multi patch and recompile the ftp module... you're done. /Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: corruption
Alexander Viro wrote:
>
> On Sun, 3 Dec 2000, Andrew Morton wrote:
>
> > It appears that this problem is not fixed.
>
> Sure, it isn't. Place where the shit hits the fan: fs/buffer.c::unmap_buffer().
> Add the call of remove_inode_queue(bh) there and see if it helps. I.e.
>
> ed fs/buffer.c < /unmap_buffer/
> /}/i
> remove_inode_queue(bh);
> .
> wq
> EOF
>
Sorry, it's still failing. It took three hours.
>i_dirty_buffers=0xca9e63f8
next=0xc30a2598
prev=0xc30a2598
kernel BUG at inode.c:86!
The ksymoops output is here, as is my current diff wrt test12-pre3.
ksymoops 0.7c on i686 2.4.0-test12-pre3. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test12-pre3/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Reading Oops report from the terminal
Dec 4 01:56:02 mnm kernel: EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
Dec 4 01:56:02 mnm kernel: EFLAGS: 00010282
Dec 4 01:56:02 mnm kernel: eax: 001a ebx: ca9e63e0 ecx: 0001 edx:
Dec 4 01:56:02 mnm kernel: esi: c025b8a0 edi: cfbcb040 ebp: ce2b0260 esp:
ced4df3c
Dec 4 01:56:02 mnm kernel: ds: 0018 es: 0018 ss: 0018
Dec 4 01:56:02 mnm kernel: Process lat_fs (pid: 17559, stackpage=ced4d000)
Dec 4 01:56:02 mnm kernel: Stack: c021b845 c021b939
0056 ca9e63e0 c0146966 ca9e63e0 ce2b0260 ca9e63e0
Dec 4 01:56:02 mnm kernel: Call Trace: [] [] []
[] [] [] []
Dec 4 01:56:02 mnm kernel: Code: 0f 0b 83 c4 0c 8d 76 00 53 a1 10 d1 2a c0 50 e8 80
3d fe ff
>>EIP; c0145758<=
Trace; c021b845
Trace; c021b939
Trace; c0146966
Trace; c01450b6
Trace; c013de6d
Trace; c013df45
Trace; c0108fdf
Code; c0145758
<_EIP>:
Code; c0145758<=
0: 0f 0b ud2a <=
Code; c014575a
2: 83 c4 0c add$0xc,%esp
Code; c014575d
5: 8d 76 00 lea0x0(%esi),%esi
Code; c0145760
8: 53push %ebx
Code; c0145761
9: a1 10 d1 2a c0mov0xc02ad110,%eax
Code; c0145766
e: 50push %eax
Code; c0145767
f: e8 80 3d fe ffcall fffe3d94 <_EIP+0xfffe3d94> c01294ec
1 warning issued. Results may not be reliable.
--- linux-2.4.0-test12-pre3/include/linux/list.hFri Aug 11 19:06:12 2000
+++ linux-akpm/include/linux/list.h Fri Dec 1 17:31:35 2000
@@ -90,6 +90,7 @@
static __inline__ void list_del(struct list_head *entry)
{
__list_del(entry->prev, entry->next);
+ entry->next = entry->prev = 0;
}
/**
--- linux-2.4.0-test12-pre3/fs/buffer.c Wed Nov 29 18:23:19 2000
+++ linux-akpm/fs/buffer.c Sun Dec 3 22:36:18 2000
@@ -871,10 +871,11 @@
else {
bh->b_inode =
list_add(>b_inode_buffers, _dirty_buffers);
- atomic_inc(>b_count);
if (buffer_dirty(bh)) {
+ atomic_inc(>b_count);
spin_unlock(_list_lock);
ll_rw_block(WRITE, 1, );
+ brelse(bh);
spin_lock(_list_lock);
}
}
@@ -883,6 +884,7 @@
while (!list_empty(_dirty_buffers)) {
bh = BH_ENTRY(tmp.i_dirty_buffers.prev);
remove_inode_queue(bh);
+ atomic_inc(>b_count);
spin_unlock(_list_lock);
wait_on_buffer(bh);
if (!buffer_uptodate(bh))
@@ -929,9 +931,9 @@
atomic_inc(>b_count);
spin_unlock(_list_lock);
wait_on_buffer(bh);
- brelse(bh);
if (!buffer_uptodate(bh))
err = -EIO;
+ brelse(bh);
spin_lock(_list_lock);
goto repeat;
}
@@ -1459,6 +1461,9 @@
clear_bit(BH_Mapped, >b_state);
clear_bit(BH_Req, >b_state);
clear_bit(BH_New, >b_state);
+ spin_lock(_list_lock);
+ remove_inode_queue(bh);
+ spin_unlock(_list_lock);
}
}
--- linux-2.4.0-test12-pre3/fs/inode.c Wed Nov 29 18:23:19 2000
+++ linux-akpm/fs/inode.c Sat Dec 2
Re: Phantom PS/2 mouse persists..
On Sun, Dec 03, 2000 at 06:27:52PM +, Alan Cox wrote: > > Unfortunately, 2.2.18pre24 is still convinced that I have a PS/2 mouse > > attached to my machine. > > I've fixed the major case. I can see no definitive answer to the other ghost > PS/2 stuff (except maybe USB interactions). I take it like the others 2.4test > also misreports a PS/2 mouse being present. > > Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected > board can piece together the picture I see it on pre18-23 but pre18-24 seems to be fixed. I need to test with the anaconda installer, since I an still using a pre18-23 boot kernel for the install. Jeff > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
On Mon, 04 Dec 2000 07:29:10 +1100, Keith Owens <[EMAIL PROTECTED]> wrote: >On Sun, 3 Dec 2000 07:43:01 -0600 (CST), >Jeff Garzik <[EMAIL PROTECTED]> wrote: >>On Sun, 3 Dec 2000, Keith Owens wrote: >>> If you go down this path, please add a standard performance monitoring >>> method to query the current capacity of an interface. >>Well, ethtool interface supports reporting media selection as well as >>[re]setting media setting. I dunno if we could report what capacity >>an interface is handling without adding code to hot paths... > >You calculate the capacity during ifconfig up or during speed change. >That is not on the hot path. Replying to my own mail, I just realised it was ambiguous. By "current capacity" I mean the maximum capacity of the link based on the current settings. We can get capacity _used_ from the byte counters, we do not have a figure for maximum capacity. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
On Sun, 3 Dec 2000 07:43:01 -0600 (CST), Jeff Garzik <[EMAIL PROTECTED]> wrote: >On Sun, 3 Dec 2000, Keith Owens wrote: >> If you go down this path, please add a standard performance monitoring >> method to query the current capacity of an interface. >Well, ethtool interface supports reporting media selection as well as >[re]setting media setting. I dunno if we could report what capacity >an interface is handling without adding code to hot paths... You calculate the capacity during ifconfig up or during speed change. That is not on the hot path. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: corruption
In article <[EMAIL PROTECTED]>, Alexander Viro <[EMAIL PROTECTED]> writes: AV> >> > ed fs/buffer.c <> > /unmap_buffer/ >> > /}/i AV> spin_lock(_list_lock); >> >remove_inode_queue(bh); AV> spin_unlock(_list_lock); >> > . >> > wq >> > EOF AV> I applied this on top the the previous SCT patch, and have thrashed the system harder than I would have dared previously. It's still running. I feel very comfortable with this, much more so than any prior 2.4.0t*. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IDE_TAPE problem wiht ONSTREAM DI30
Am Don, 30 Nov 2000 schrieben Sie: > On Thu, Nov 30, 2000 at 04:26:09PM +, Eckhard Jokisch wrote: > > > > I tried the ide-tape driver for several weeks now. And after some time during > > writing or reading tar stops because of errors. > > > > Error messages are: > > Nov 30 15:32:20 kernel: ide-tape: ht0: I/O error, pc = 8, key = 0, > > asc = 0, ascq = 2 Nov 30 15:32:25 eckhard last message repeated 1000 times > > Nov 30 15:32:25 kernel: ide-tape: ht0: unrecovered read error on logical block >number 461706, skipping > I ran into such problems since februari or so and have been in contact with > the ide-tape developers and Onstream about it. > I recently volunteered to try improving the end of media handling (basicly by > implementing early warning EOM) but so far have not had much time to work on it... Where can I start to do that? Can you tell me how I can set the debug_level to 3 or 5? Why do I get this errors on make modules when I compile the driver with IDETAPE_DEBUG_LOG_VERBOSE to 1 in ide-tape.c?: gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -DMODULE -DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h -c -o ide-tape.o ide-tape.c ide-tape.c: In function `idetape_sense_key_verbose': ide-tape.c:1395: warning: function returns address of local variable ide-tape.c: In function `idetape_command_key_verbose': ide-tape.c:1413: parse error before `case' ide-tape.c:1424: warning: function returns address of local variable make[2]: *** [ide-tape.o] Error 1 make[2]: Leaving directory `/src/2.4-test11/drivers/ide' make[1]: *** [_modsubdir_ide] Error 2 make[1]: Leaving directory `/src/2.4-test11/drivers' make: *** [_mod_drivers] Error 2 Hopefully Eckhard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
> This is standard stuff... You are really pissing into the wind here ;) Guess I am. Still isn't an explaination why I see a lot of broken code out there regarding this issue. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
Igmar Palsenberg wrote: > > This is standard stuff... You are really pissing into the wind here ;) > > Guess I am. Still isn't an explaination why I see a lot of broken code out > there regarding this issue. > > Igmar Broken code due to broken programmers. -d begin:vcard n:Ford;David x-mozilla-html:TRUE url:www.blue-labs.org adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A x-mozilla-cpt:;9952 fn:David Ford end:vcard
Re: [patch] Re: test12-pre2
> > It just oops continuously. It finds the scsi drives and says it's enabling > > a few pci devices but it scrolls too fast to see what it really does > > If it finds scsi drives, PCI setup is probably ok. There could be > a lot of other problems - too much changes since 2.2. > > Capturing kernel messages via serial port would be helpful, > but I understand that it is not always possible. :-( I have the capture. It actually mounts / and attempts to free unused memory and then it continuously oops's in swapper. (See attached) For the people on the list, I have also included the patch that allows me to boot my machine. -- Lab tests show that use of micro$oft causes cancer in lab animals Linux version 2.4.0-test12 (wakko@kakarot) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #3 Sun Dec 3 14:06:12 EST 2000 Booting on Noritake using machine vector Noritake from SRM Command line: root=/dev/sda1 ro single console=ttyS0 memcluster 0, usage 1, start0, end 171 memcluster 1, usage 0, start 171, end20403 memcluster 2, usage 1, start20403, end20480 freeing pages 171:384 freeing pages 627:20403 On node 0 totalpages: 20480 zone(0): 20480 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/sda1 ro single console=ttyS0 Using epoch = 1900 Console: colour VGA+ 80x25 Calibrating delay loop... 524.29 BogoMIPS Memory: 157152k/163224k available (1114k kernel code, 4704k reserved, 241k data, 224k init) Dentry-cache hash table entries: 32768 (order: 6, 524288 bytes) Buffer-cache hash table entries: 8192 (order: 3, 65536 bytes) Page-cache hash table entries: 32768 (order: 5, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 262144 bytes) POSIX conformance testing by UNIFIX got res[280:2ff] for resource 1 of 3DLabs Permedia II 2D+3D got res[300:37f] for resource 2 of 3DLabs Permedia II 2D+3D got res[220:221] for resource 0 of 3DLabs Permedia II 2D+3D got res[222:222] for resource 6 of 3DLabs Permedia II 2D+3D got res[9000:90ff] for resource 0 of Q Logic ISP1020 got res[9400:947f] for resource 0 of Digital Equipment Corporation DECchip 21142/43 got res[9480:94bf] for resource 0 of 3Com Corporation 3c905 100BaseTX [Boomerang] got res[380:383] for resource 6 of Digital Equipment Corporation DECchip 21142/43 got res[384:384] for resource 6 of Q Logic ISP1020 got res[385:385] for resource 6 of 3Com Corporation 3c905 100BaseTX [Boomerang] got res[386:3860fff] for resource 1 of Q Logic ISP1020 got res[3861000:386107f] for resource 1 of Digital Equipment Corporation DECchip 21142/43 PCI: Bus 1, bridge: Digital Equipment Corporation DECchip 21050 IO window: 1000-9fff MEM window: 0380-038f PCI enable device: (Intel Corporation 82375EB) cmd reg 0x7 PCI enable device: (Digital Equipment Corporation DECchip 21050) cmd reg 0x107 PCI enable device: (3DLabs Permedia II 2D+3D) cmd reg 0x7 PCI enable device: (Q Logic ISP1020) cmd reg 0x47 PCI enable device: (Digital Equipment Corporation DECchip 21142/43) cmd reg 0x47 PCI enable device: (3Com Corporation 3c905 100BaseTX [Boomerang]) cmd reg 0x47 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A ttyS03 at 0x02e8 (irq = 3) is a 16550A SCSI subsystem driver Revision: 1.00 qlogicisp : new isp1020 revision ID (2) scsi0 : QLogic ISP1020 SCSI on PCI bus 01 device 00 irq 17 I/O base 0x9000 Vendor: WDIGTLModel: ENTERPRISERev: 1.80 Type: Direct-Access ANSI SCSI revision: 02 Vendor: DEC Model: RZ28D(C) DEC Rev: 0010 Type: Direct-Access ANSI SCSI revision: 02 Vendor: DEC Model: RZ28D(C) DEC Rev: 0008 Type: Direct-Access ANSI SCSI revision: 02 Vendor: DEC Model: RZ28D(C) DEC Rev: 0008 Type: Direct-Access ANSI SCSI revision: 02 Vendor: ARCHIVE Model: Python 25501-XXX Rev: 2.54 Type: Sequential-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0 Detected scsi disk sdc at scsi0, channel 0, id 2, lun 0 Detected scsi disk sdd at scsi0, channel 0, id 3, lun 0 SCSI device sda: 4254819 512-byte hdwr sectors (2178 MB) Partition check: sda: sda1 sda2 sda3 sda4 sda5 SCSI device sdb: 4110480 512-byte hdwr sectors (2105 MB) sdb: unknown partition table SCSI device sdc: 4110480 512-byte hdwr sectors (2105 MB) sdc: unknown partition table SCSI device sdd: 4110480 512-byte hdwr sectors (2105 MB) sdd: unknown partition table NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of
Re: lost dirs after fsck-1.18 (kt133, ide, dma, test10, test11)
From: "Saber Taylor" <[EMAIL PROTECTED]> Date:Sun, 03 Dec 2000 05:59:47 - Well that's the last time I run a devel kernel with a nontest system. sigh. Had one directory replaced with a different directory and also a directory replaced with a file. Possible further corruption. I don't think I lost the directories until I did a 'fsck -y' on the partition. Something to remember. If it was just the directories that got lost, the files should have been reparented to the /lost+found directory for that filesystrem. If however the bug wiped out part of your inode table, then you would have probably lost both the directory and the files in that directory, since directories and files tend to be stored in the same block group. If anyone has advice on recovering the directories other than the following links, I'm all ears: Without more details about how the corruption happened or what the nature of the corruption is, it's hard to give good general advice. Those websites aren't bad places to start. Good luck. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ip_nat_ftp and different ports
Hi, I'm having trouble masquerading ftp-ports other than 20/21. For some service i'm using, i need to masquerade port 42,43,62,63 for FTP (I know it's weird...). Now, when using 2.2.x kernels i could use 'insmod ip_masq_ftp ports=21,41,42,62,63' but using 2.4.0-testx the 'ports=' parameter doesn't seem to work for ip_nat_ftp. Is there any other param I should use (couldn't find it in the docs ;(( ) Please cc me because i'm not on the list (only reading the web-archives) Thanks, Taco. --- "I was only 75 years old when I met her and I was still a kid" -- Duncan McLeod - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
On Sun, 3 Dec 2000, Igmar Palsenberg wrote: > > Any programmer who has evolved sufficiently from a scriptie should take > > necessary precautions to check how much data was transferred. Those who > > don't..well, there is still tomorrow. > > > > There is no reason to add any additional documentation. If we did, we'd be > > starting the trend of documenting the direction a mouse moves when it's > > pushed and not to be alarmed if you turn the mouse sideways and the result is > > 90 degrees off. > > random devices are different. If it request 10 bytes on random stuff, I > want 10 bytes. Anything less is a waste of the read, because I need 10 > bytes. > > At least, in my opinion. > > Anyone has an insight how other *NIX'es handle this ? This is standard stuff... You are really pissing into the wind here ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fasttrak100 questions...
> Where can this Lucent driver be found? The one I use with my Thinkpad is > version 5.68. It comes as a loadable module (ltmodem.o) with no serial.c, and I > havent gotten it to work with any kernel later than 2.2.14. The serial API had to change in 2.2.15. I know it broke the lucent driver, the fix was a neccessary security fix Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mmap_sem (and generic) semaphore fairness question
On Thu, 2 Nov 2000, Petr Vandrovec wrote: > Yes, it can happens. It for sure happens in ncpfs - as ncpfs uses > ping-pong protocol, and I'm lazy to use different thing than semaphore, > connection to server is guarded by semaphore. If you use a rw semaphore taken for writing by two writers, it will alternate between the two because the second writer will bias the lock (its next state is predetermined when the second writer goes to sleep). This is also true for the mix of reader -> writer and writer -> reader. -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: corruption on my ext2fs with 2.4.0-test10
Mircea Damian writes:
> ... file-utils like ls, rm say:
> root@invasion:/usr/src/perl-5.6.0/t# ls -sail
> /bin/ls: big: Value too large for defined data type
> total 8
> 10973604 drwx-- 2 504 1001 4096 Dec 3 13:43 ./
> 13549794 drwxr-xr-x 3 504 1001 4096 Dec 3 13:43 ../
The file's got holes in it (regions of zeros), so it doesn't occupy as
much space on disk as it claims to. The reason your normal tools can't
deal with it is that your C library has been built without LFS
support, so stat will fail on files larger than 2 gig.
You can remove it by just calling unlink.
int main(int argc, char **argv) {
unlink("mybigfile");
}
--
Adam Sampson
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Phantom PS/2 mouse persists..
> Unfortunately, 2.2.18pre24 is still convinced that I have a PS/2 mouse > attached to my machine. I've fixed the major case. I can see no definitive answer to the other ghost PS/2 stuff (except maybe USB interactions). I take it like the others 2.4test also misreports a PS/2 mouse being present. Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected board can piece together the picture - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fasttrak100 questions...
Hi! > Where can this Lucent driver be found? The one I use with my Thinkpad is > version 5.68. It comes as a loadable module (ltmodem.o) with no serial.c, and I > havent gotten it to work with any kernel later than 2.2.14. Search [EMAIL PROTECTED] mailing list, it was there. Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Bug in implementation of fcntl64 syscall?
Hi,
I'm trying to investigate why my apache compiled with
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 (and glibc 2.2
build against 2.4.0-test10 headers) immediately dies with
[emerg] (11)Resource temporarily unavailable: fcntl:
F_SETLKW: Error getting accept lock, exiting!
This happens while trying to get the file lock to serialize accept.
The first child gets the lock, the other should block.
However, fnctl(fd, F_SETLKW, ...) returns with EAGAIN
(which shouldn't be possible, it would be correct for F_SETLK).
Note that for the above compile flags, libc's F_SETLKW is 14 (on i386)
which in the kernel is F_SETLKW64 (kernel's F_SETLKW is 7).
strace shows that the actual system call used by libc is fcntl64.
For 2.4.0-test11, fs/fcntl.c has the following code:
asmlinkage long sys_fcntl64(unsigned int fd, unsigned int cmd, unsigned long arg
)
{
...
switch (cmd) {
case F_GETLK64:
err = fcntl_getlk64(fd, (struct flock64 *) arg);
break;
case F_SETLK64:
err = fcntl_setlk64(fd, cmd, (struct flock64 *) arg);
break;
case F_SETLKW64:
err = fcntl_setlk64(fd, cmd, (struct flock64 *) arg);
break
...
i.e. fcntl_setlk64() is called with cmd==F_SETLKW64,
but in fs/locks.c:
int fcntl_setlk64(unsigned int fd, unsigned int cmd, struct flock64 *l)
{
...
error = posix_lock_file(filp, file_lock, cmd == F_SETLKW);
where the last argumet to posix_lock_file governs
wait vs. immediate return.
Cheers, Roderich
--
"Thou shalt not follow the NULL pointer
for chaos and madness await thee at its end."
Roderich Schupp mailto:[EMAIL PROTECTED]
ExperTeam GmbH http://www.experteam.de/
Munich, Germany
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fasttrak100 questions...
Where can this Lucent driver be found? The one I use with my Thinkpad is version 5.68. It comes as a loadable module (ltmodem.o) with no serial.c, and I havent gotten it to work with any kernel later than 2.2.14. Pavel Machek <[EMAIL PROTECTED]> on 12/02/2000 10:50:35 AM To: Alan Cox <[EMAIL PROTECTED]>, "Dr. Kelsey Hudson" <[EMAIL PROTECTED]> cc: "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec) Subject: Re: Fasttrak100 questions... Hi! > > You are wrong: If you modify the kernel you have to make it available for > > anyone who wishes to use it; that's also in the GPL. You can't add stuff > > No it isnt. Some people seem to think it is. You only have to provide a > change if you give someone the binaries concerned. Some people also think > that 'linking' clauses mean they can just direct the customer to do the link, > that also would appear to be untrue in legal precedent - the law cares about > the intent. This is currently happening with lucent winmodem driver: there's modified version of serial.c, and customers are asked to compile it and (staticaly-)link it against proprietary code to get usable driver. Is that okay or not? 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] 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] Please read the FAQ at http://www.tux.org/lkml/
Re: corruption on my ext2fs with 2.4.0-test10
OK, problem found.
Something is broken (I've tested on a new 2.4.0-test12-pre3). Look here:
If I run strace through the perl script I get something like:
root@invasion:/usr/src/archives/perl-5.6.0/t# strace ./perl op/lfs.t
...
open("big", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40015000
_llseek(3, 50, [50], SEEK_SET) = 0
write(3, "big", 3) = 3
close(3)= 0
munmap(0x40015000, 4096)= 0
stat("big", 0xb980) = -1 EOVERFLOW (Value too large for defined
data type)
...
I believe that _llseek() call should return EINVAL. Right?
On Sun, Dec 03, 2000 at 02:46:06PM +0200, Mircea Damian wrote:
>
> Sorry that I have to follow my self but I forgot to say that e2fsck is
> happy with it:
>
> root@invasion:~# e2fsck -C 0 -f /dev/hda2
> e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> /dev/hda2: 43056/1548288 files (1.7% non-contiguous), 237689/1548264 blocks
>
> ... file-utils like ls, rm say:
> root@invasion:/usr/src/perl-5.6.0/t# ls -sail
> /bin/ls: big: Value too large for defined data type
> total 8
> 10973604 drwx-- 2 504 1001 4096 Dec 3 13:43 ./
> 13549794 drwxr-xr-x 3 504 1001 4096 Dec 3 13:43 ../
>
> root@invasion:/usr/src/perl-5.6.0/t# rm big
> rm: cannot remove `big': Value too large for defined data type
>
> I can not keep this machine down (my /-fs is read-only right now just to be
> sure that nothing changes) for too much time.
--
Mircea Damian
E-mails: [EMAIL PROTECTED], [EMAIL PROTECTED]
WebPage: http://taz.mania.k.ro/~dmircea/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)
On Sun, 3 Dec 2000, Matti Aarnio wrote: > On Sat, Dec 02, 2000 at 10:11:28PM +, Tigran Aivazian wrote: > > Second attempt. The linux-kernel list is broken at the moment (reported > > fault to postmaster already) so some messages get lost at random: > >Tigran has local problems with his outgoing email. >Nothing to do with vger.kernel.org. > >His email didn't make it out from his machine to some ISP outgoing relay. >Looks like he dialed using ISP2, but the relay he used was at ISP1. >Quite naturally that fails. Yes, Matti is right. Although there are no ISP1 and ISP2. There is just ISP1 (btconnect.com) and it is broken, i.e. the smtp server which sendmail discovers is wrong. So I manually set pine(1) to use mail.btconnect.com and that works. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)
On Sat, Dec 02, 2000 at 10:11:28PM +, Tigran Aivazian wrote: > Second attempt. The linux-kernel list is broken at the moment (reported > fault to postmaster already) so some messages get lost at random: Tigran has local problems with his outgoing email. Nothing to do with vger.kernel.org. His email didn't make it out from his machine to some ISP outgoing relay. Looks like he dialed using ISP2, but the relay he used was at ISP1. Quite naturally that fails. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
> Well, that's the Unix interface you. I you don't like it, why don't you > become a Windows programmer and try your hand at the Win32 interface? :-) > > Seriously, doing something different for /dev/random compared to all > other read(2) calls is a bad idea; it will get people confused. The > answer is whenever you call read(2), you must check the return values. > People who don't are waiting to get themselves into a lot of trouble, > particularly people who writing network programs. The number of people > who assume that they can get an entire (variable-length) RPC packet by > doing a single read() call astounds me. TCP doesn't provide message > boundaries, never did and never will. The problem is that such program > will work on a LAN, and then blow up when you try using them across the > real Internet. > > Secondly, the number of times that you end up going into a kernel is > relatively rare; I doubt you'd be able to notice a performance > difference in the real world using a real-world program. As far as > source/object code bloat, well, how much space does a while loop take? > And I usyally write a helper function which takes care of the while > loop, checks for errors, calls read again if EINTR is returned, etc. Agree. I thought that en exhausted entropy pool gave less random numbers on the next read. After having a look at the source I realized I was taking nonsense. > - Ted Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
HP E60 strange network problems
Hello, Have strange problem: HP E60 server(Intel 82559 onboard NIC) + RedHat 6.2 with latest fixes. About 40 computers(WIN9X) in local network, 3COM dual speed switch and 3 compex 10Mb hubs. Everything is OK except sometimes can't ping workstations from linux server. From workstations I can ping everything without any problems, but from linux server sometimes can't ping another computers on network. Here is no "request timed out" errors, just ping freezes. No error entries in /var/log/messages. Boot log without problems too. Someone expierenced similiar problems Tried to replace switch with 10Mb hub, to move server on another port, all cabling is UTP5(tested) nothing helps Please answer to email, because I'm not subscribed to this list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Phantom PS/2 mouse persists..
Alan, Unfortunately, 2.2.18pre24 is still convinced that I have a PS/2 mouse attached to my machine. Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
> > Making /dev/random block if the amount requirements aren't met makes sense > > to me. If I request x bytes of random stuff, and get less, I probably > > reread /dev/random. If it's entropy pool is exhausted it makes sense to be > > to block. > > This is the job of the program accessing /dev/random. Open it blocking or > non-blocking and read until you satisfy your read buffer. Agree, if randomness is guaranteed in that case. I usually bail out in that case. Time to change that :) > -d Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
> > I know. Still leaves lot's of people that assume that reading /dev/random > > will return data, or will block. > > > > I've seen lots of programs that will assume that if we request x bytes > > from /dev/random it will return x bytes. > > I find this really humorous honestly. I see a lot of people assuming that if > you write N bytes or read N bytes that you will have done N bytes. There are > return values for these functions that tell you clearly how many bytes were > done. Of course. Lesson one : check return values > Any programmer who has evolved sufficiently from a scriptie should take > necessary precautions to check how much data was transferred. Those who > don't..well, there is still tomorrow. > > There is no reason to add any additional documentation. If we did, we'd be > starting the trend of documenting the direction a mouse moves when it's > pushed and not to be alarmed if you turn the mouse sideways and the result is > 90 degrees off. random devices are different. If it request 10 bytes on random stuff, I want 10 bytes. Anything less is a waste of the read, because I need 10 bytes. At least, in my opinion. Anyone has an insight how other *NIX'es handle this ? > -d Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Q: tq_scheduler slower on SMP ?
Hi, with kernel 2.2.17 I need to have a function in my driver to handle some data. I used BH with tq_immediate, but I found out, that my function need to be called outside of interrupt context, but still as soon as I need it. So I decided to use the tq_scheduler queue and put my function on the task_queue in my interrupt handler. It seems to work good without SMP, but with SMP my function is called with delays of many msecs. Since the tq_scheduler queue is only started from schedule(), do I need to set some flag to run schedule asap ? Or has someone better idea for my function ? Thanx, Armin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: how to compile redhat6.0 kernel
At 03:00 AM 12/3/00 +, Mourad wrote: >hi: > >i wanna recompile the kernel to reset some variables "ip multicasting", >and i have a root access. > >so can you please tell me in steps (detailed) , how to recompile an >installed kernel of redhat6.0. > >thanx >mourad, Here is a URL for a Linux Journal article that discusses Kernel Compiling http://www2.linuxjournal.com/lj-issues/issue43/2404.html Pete =-= A4C7 3342 EF0C 2504 9FBF 6808 C5C0 7A78 354A B81D =-= Hi! I'm a signature virus! add me to your signature to help me spread! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
On Sun, 3 Dec 2000, Keith Owens wrote: > If you go down this path, please add a standard performance monitoring > method to query the current capacity of an interface. > to report "eth0 is handling 1 Megabyte/second, but we cannot tell if > that is 90% (10BaseT) or 9% (100BaseT) utilization". We should report > capacity rather than speed because speed alone is not the controlling > factor, other things like half or full duplex affect the capacity. Well, ethtool interface supports reporting media selection as well as [re]setting media setting. I dunno if we could report what capacity an interface is handling without adding code to hot paths... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
negative NFS cookies: bad C library or bad kernel?
> " " == Kevin Buhr <[EMAIL PROTECTED]> writes: > However, who's to blame here? It can't be CFS---any four-byte > cookie should be valid, right? > Is the kernel NFS client code to blame? If it's going to be > using cookies as offsets, shouldn't we have an nfs_lseek that > special-cases directory lseeks (at least those using SEEK_SET) > to take negative offsets, so utilities and libraries don't need > to be bigfile-aware just to read directories? And what in the > world can we do about bogus code like the: The problem here is that in NFS we have to match cookies in lieu of using true directory 'offsets'. I did try to work around this by using offsets into the page cache and the likes, however this sort of scheme is almost impossible to implement sanely because an offset into the page cache changes all the time. This was why I returned to Olaf's scheme in which we use the cookie as the return value for lseek & friends. The problem then arises that lseek tries to cram both a returned offset and an error value into the return values. When NFS returns an opaque type, this causes a problem; one that won't be fixed by adding an nfs_lseek. Furthermore, lseek is 32-bits: for NFSv3 and higher, the cookie is 64-bits... I know of no scheme that can fix all problems with lseek. For example concerning SEEK_CUR: forget about it. NFS is not POSIX and never will be. You simply cannot give meaningful semantics to SEEK_CUR as long as the client knows nothing about the organization of dirents on the server. We can return offsets that are based on the internal caching of dirents, but the problem then is that you need to find some permanent 'index' that doesn't change when we invalidate the cache and read it in anew. Making stuff like 'rm -rf *' work (when the directory size & organization keeps changing) is quite a challenge... One possibility would be to make a pointer into a table of cookies be our 'offset'. That could work if we can ensure that cookies can't move around... Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problems with CDROMVOLCTRL
Hi, CDROMVOLCTRL does not work with my configuration in test11. The ioctl always returns an error and volume stays the same (seen with xmcd and gtcd). I tried the patch at *.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-test11/cd-1.bz2 This changed the error code from some bogus large positive number to -EOPNOTSUPP :) However, volume control works fine in 2.2.17, so the hardware shouldn't be the culprit. The cdrom drive in question is an old TEAC CD-56S on an Adaptec AHA-2940 (narrow) controller. Cheers, Roderich -- There is something to be learned from a rainstorm. When meeting with a sudden shower, you try not to get wet and run quickly along the road. But doing such things as passing under the eaves of houses, you still get wet. When you are resolved from the beginning, you will not be perplexed, though you still get the same soaking. -- Hagakure - The Book of the Samurai Roderich Schupp mailto:[EMAIL PROTECTED] ExperTeam GmbH http://www.experteam.de/ Munich, Germany - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: corruption on my ext2fs with 2.4.0-test10
Sorry that I have to follow my self but I forgot to say that e2fsck is happy with it: root@invasion:~# e2fsck -C 0 -f /dev/hda2 e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/hda2: 43056/1548288 files (1.7% non-contiguous), 237689/1548264 blocks ... file-utils like ls, rm say: root@invasion:/usr/src/perl-5.6.0/t# ls -sail /bin/ls: big: Value too large for defined data type total 8 10973604 drwx-- 2 504 1001 4096 Dec 3 13:43 ./ 13549794 drwxr-xr-x 3 504 1001 4096 Dec 3 13:43 ../ root@invasion:/usr/src/perl-5.6.0/t# rm big rm: cannot remove `big': Value too large for defined data type I can not keep this machine down (my /-fs is read-only right now just to be sure that nothing changes) for too much time. On Sun, Dec 03, 2000 at 02:24:33PM +0200, Mircea Damian wrote: > > Hello people, > > Since I've seen that there are some problems with corruption on ext2fs I > thought that it would be a good idea to report my problem too. > > I have a 2.4.0-test10 patched with reiserfs (but I do not use it - it was > just in my plan to create a partition sometime; so I think that it does not > matter to much). Kernel compiled with egcs-1.1.2: > > root@invasion:~# gcc -v > Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/egcs-2.91.66/specs > gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > > The problem is that I tried to build perl-5.6.0 and some of my tests were > failing. First I thought that it is a problem with shared libraries but I > was wrong, in the test directory I have a file named "big" which has 5Gb > (almost): > > root@invasion:/# debugfs /dev/hda2 > debugfs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 > debugfs: cd /usr/src/perl-5.6.0/t/ > debugfs: ls > 1097360 (12) . 1354979 (184) .. 1097503 (3900) big > debugfs: ls -l > 1097360 40700504 10014096 3-Dec-2000 13:43 . > 1354979 40755504 10014096 3-Dec-2000 13:43 .. > 1097503 100644 0 0 53 3-Dec-2000 10:00 big > > Ofcourse this is wrong because: > debugfs: q > root@invasion:/# df > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/hda2 5999072756772 4932648 13% / > > > I've checked my syslog and messages for ext2 warnings but I found nothing > unusual. > > The system is UP and dmesg output is attached. > > OTOH does anyone know how to silent messages like: > NAT: 0 dropping untracked packet c7d205c0 1 192.129.3.151 -> 224.0.0.1 > NAT: 0 dropping untracked packet c7d129a0 1 192.129.3.151 -> 224.0.0.1 > They are annoying and after some time they just fill up my dmesg output > (all dropped packets are multicast just like the two above). > > > > uto BOOT_IMAGE=Linux ro root=302 console=ttyS0,38400 > Initializing CPU#0 > Detected 400.914 MHz processor. > Console: colour VGA+ 80x30 > Calibrating delay loop... 799.54 BogoMIPS > Memory: 126788k/131072k available (1207k kernel code, 3896k reserved, 85k data, 196k >init, 0k highmem) > Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) > Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) > Page-cache hash table entries: 32768 (order: 5, 131072 bytes) > Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) > CPU: Before vendor init, caps: 0183fbff , vendor = 0 > CPU: L1 I cache: 16K, L1 D cache: 16K > CPU: L2 cache: 512K > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > CPU: After vendor init, caps: 0183fbff > CPU: After generic, caps: 0183fbff > CPU: Common caps: 0183fbff > CPU: Intel Pentium II (Deschutes) stepping 02 > Checking 'hlt' instruction... OK. > POSIX conformance testing by UNIFIX > enabled ExtINT on CPU#0 > ESR value before enabling vector: 0004 > ESR value after enabling vector: > ENABLING IO-APIC IRQs > ...changing IO-APIC physical APIC ID to 2 ... ok. > Synchronizing Arb IDs. > init IO_APIC IRQs > IO-APIC (apicid-pin) 2-0, 2-16, 2-20, 2-21, 2-22, 2-23 not connected. > ..TIMER: vector=49 pin1=2 pin2=0 > activating NMI Watchdog ... done. > number of MP IRQ sources: 20. > number of IO-APIC #2 registers: 24. > testing the IO APIC... > > IO APIC #2.. > register #00: 0200 > ...: physical APIC id: 02 > register #01: 00170011 > ... : max redirection entries: 0017 > ... : IO APIC version: 0011 > register #02: > ... : arbitration: 00 > IRQ redirection table: > NR Log Phy Mask Trig IRR
Re: Problems building test10 or test11 with AMD Duron CPU
On Sun, Dec 03, 2000 at 11:56:32AM +0100, Frederik Vanrenterghem wrote: > Hi, > > I've been unable to build kernel 2.4.0test10 or test 11 on my new system, > which has an Asus A7V mb and a AMD Duron 700 CPU, running Debian Woody > (gcc 2.95.2). If I select as CPU: Athlon/K7, building the kernel fails. If > I choose PPro, the kernel builds fine, and I can use it. > Is this normal behaviour? I would expect to be able to build a kernel on > this system with Athlon/K7 optimisations, since a Duron is from the same > line of CPU's, or is that incorrect? I have got the exact same setup. Everything works fine when compiling for Athlon/K7. I will send you my .config. Jens -- Jens Taprogge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
corruption on my ext2fs with 2.4.0-test10
Hello people, Since I've seen that there are some problems with corruption on ext2fs I thought that it would be a good idea to report my problem too. I have a 2.4.0-test10 patched with reiserfs (but I do not use it - it was just in my plan to create a partition sometime; so I think that it does not matter to much). Kernel compiled with egcs-1.1.2: root@invasion:~# gcc -v Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) The problem is that I tried to build perl-5.6.0 and some of my tests were failing. First I thought that it is a problem with shared libraries but I was wrong, in the test directory I have a file named "big" which has 5Gb (almost): root@invasion:/# debugfs /dev/hda2 debugfs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 debugfs: cd /usr/src/perl-5.6.0/t/ debugfs: ls 1097360 (12) . 1354979 (184) .. 1097503 (3900) big debugfs: ls -l 1097360 40700504 10014096 3-Dec-2000 13:43 . 1354979 40755504 10014096 3-Dec-2000 13:43 .. 1097503 100644 0 0 53 3-Dec-2000 10:00 big Ofcourse this is wrong because: debugfs: q root@invasion:/# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 5999072756772 4932648 13% / I've checked my syslog and messages for ext2 warnings but I found nothing unusual. The system is UP and dmesg output is attached. OTOH does anyone know how to silent messages like: NAT: 0 dropping untracked packet c7d205c0 1 192.129.3.151 -> 224.0.0.1 NAT: 0 dropping untracked packet c7d129a0 1 192.129.3.151 -> 224.0.0.1 They are annoying and after some time they just fill up my dmesg output (all dropped packets are multicast just like the two above). -- Mircea Damian E-mails: [EMAIL PROTECTED], [EMAIL PROTECTED] WebPage: http://taz.mania.k.ro/~dmircea/ uto BOOT_IMAGE=Linux ro root=302 console=ttyS0,38400 Initializing CPU#0 Detected 400.914 MHz processor. Console: colour VGA+ 80x30 Calibrating delay loop... 799.54 BogoMIPS Memory: 126788k/131072k available (1207k kernel code, 3896k reserved, 85k data, 196k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Before vendor init, caps: 0183fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0183fbff CPU: After generic, caps: 0183fbff CPU: Common caps: 0183fbff CPU: Intel Pentium II (Deschutes) stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 0004 ESR value after enabling vector: ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. Synchronizing Arb IDs. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-16, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 activating NMI Watchdog ... done. number of MP IRQ sources: 20. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00170011 ... : max redirection entries: 0017 ... : IO APIC version: 0011 register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 001 01 000 0 01139 02 001 01 000 0 01131 03 001 01 000 0 01141 04 001 01 000 0 01149 05 001 01 000 0 01151 06 001 01 000 0 01159 07 001 01 000 0 01161 08 001 01 000 0 01169 09 001 01 000 0 01171 0a 001 01 000 0 01179 0b 001 01 000 0 01181 0c 001 01 000 0 01189 0d 000 00 100 0 00000 0e 001 01 000 0 01191 0f 001 01 000 0 01199 10 000 00 100 0 00000 11 001 01 110 1 011A1 12 001 01 110 1 011A9 13 001 01 110 1 011B1 14 000 00 100 0 00000 15 000 00 100 0 00000 16 000 00 100 0 00000 17 000 00 100 0 00000 IRQ to pin mappings: IRQ0 -> 2 IRQ1 -> 1 IRQ3 -> 3 IRQ4 -> 4 IRQ5 -> 5 IRQ6 -> 6 IRQ7 -> 7 IRQ8 -> 8 IRQ9
Re: /dev/random probs in 2.4test(12-pre3)
Alexander Viro wrote: > > Erm... Not that ignoring the return values was a bright idea, but the > lack of reliable ordered datagram protocol in IP family is not a good > thing. It can be implemented over TCP, but it's a big overkill. IL is a > nice thing to have... Pet peeve? There are about five "reliable UDPs" floating around. Take a look at http://www.faqs.org/rfcs/rfc2960.html SCTP is mainly designed as a way of transporting telephony signalling information across IP. But it is now a quite general purpose protocol. Culturally, this is "Telephony industry comes to IP. Telephony industry is appalled. IP industry gets a clue". SCTP provides the reliable delivery of messages to which you refer. It's slightly more efficient than TCP for a given set of network characteristics - there's no statement about implementation efficiency here. No head-of-line blocking issues. One very interesting part of SCTP is that transport endpoints are explicitly set up between *hosts*, not between IP addresses. The protocol is designed around multihomed hosts. I don't know if anyone has looked into mapping SCTP capabilities onto the BSD socket API. It may be hard. The reference implementation is for userland Linux. It's at ftp://standards.nortelnetworks.com/sigtran/ A good kernel-mode implementation of SCTP for Linux would be a very big project. But also a very big contribution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Multi-Chanel ATA, was: Re: ATA-4, ATA-5 TCQ status
On Tue, 28 Nov 2000, Uwe Bonnes wrote: > I bought the 2 channel thing for 400 DM (~160$). I guess the 8 chanel You can buy one for under $30 with two channels. So even is the 8 channel one is $200 and not $120 (4x30) I would still prefer this one. > thing is about 1000DM. That's not too much I think. Even single two > chanel PCI adapter is around 100 DM. And as your ideal card propably > isn't produced in big numbers, it will be more expensive per chanel > than the commodity products... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Bugs in test8 and test11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! I encountered some wiered bugs in test8 -- and after an upgrade to test11 there too -- yesterday. I hope this address is not totally inadequate for this report. test8: I noticed for a while now, that the keyboard on my console does not work sometimes. Yesterday I figured out, that this only happens when I have my Printer turned on. I have A Gigabyte 6BXDS Mainboard an a HP 6P Laserprinter. The rest of my system is quite recent (I do regular updates to whatever is in debian's unstable branch, the last update for this computer was about 4 weeks ago). test11: Doesen't start, but hangs right after "Uncompressing the kernel". I since I overwrote the test8 kernel with the new one I can't produce more informations (I had to reinstall the kernel from my newest LInux CDs which unfortunatly did not allow access to my disc. I used the new e2fs-features that are incompatible to pre-2.2 kernels:( ). Well, it does not really matter because of the data, but it is bad that I can't add the informations you requested to this mail. Please feel free to contact me for more information (or additional tests). I'll do what I can to help. - -- Gruss, Tobias - --- Tobias Hunger The box said: 'Windows 95 or better' [EMAIL PROTECTED] So I installed Linux. - --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE6KjEiVND+cGpk748RAoMHAJ9jpQfyrryGu83fXuiVQr8QVhonggCeIT4N OVPHDsZ6h2QAmoCe2jQhMEg= =rrWu -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
(CC list trimmed)
Philip Blundell writes:
> >Does it? At which point? To me it looks like it calls dev->do_ioctl
> >or am I missing something?
>
> It uses SIOCSIFMAP, which (I think) winds up in dev.c here:
>
> case SIOCSIFMAP:
> if (dev->set_config) {
> if (!netif_device_present(dev))
> return -ENODEV;
> return dev->set_config(dev,>ifr_map);
> }
> return -EOPNOTSUPP;
It definitely does end up there. However, the ethtool ioctls end up
in dev->do_ioctl.
_
|_| - ---+---+-
| | Russell King[EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ - /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test12-pre3] ip_conntrack_proto_tcp.c compilation fix.
Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
> --- linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c.origSat Dec 2 16:18:05
>2000
> +++ linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Sat Dec 2 16:19:04 2000
> @@ -228,6 +228,6 @@
> }
>
> struct ip_conntrack_protocol ip_conntrack_protocol_tcp
> -= { { NULL, NULLpkt_IPPROTO_TCP, "tcp",
> -tcp_ableto_tuple, tcp_invert_tuple, tcp_print_tuple, tcp_print_conntrack,
> += { { NULL, NULL }, IPPROTO_TCP, "tcp",
> +tcp_pkt_to_tuple, tcp_invert_tuple, tcp_print_tuple, tcp_print_conntrack,
> tcp_packet, tcp_new, NULL };
Just ignore this patch, it seem this file got corrupted on my FS...
--
-- Yoann http://www.mandrakesoft.com/~yoann/
An engineer from NVidia, while asking him to release cards specs said :
"Actually, we do write our drivers without documentation."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
>Does it? At which point? To me it looks like it calls dev->do_ioctl
>or am I missing something?
It uses SIOCSIFMAP, which (I think) winds up in dev.c here:
case SIOCSIFMAP:
if (dev->set_config) {
if (!netif_device_present(dev))
return -ENODEV;
return dev->set_config(dev,>ifr_map);
}
return -EOPNOTSUPP;
p.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re[2]: DMA !NOT ONLY! for triton again...
-Original Message-An interesting addition: I've just got a reply from WD - they say my disk only supports PIO4 and not DMA... > I'm taking the case off the machine right now, i can guarantee you its not UDMA >compatible, simply because this thing was made in early1997. :) > > Here we go: > > MDL WDAC21600-00H > P/N 99-004199-000 > CCC F3 20 FEB 97 > DCM: BHBBKLP > > I've got various of these hard drives in service, for the last 4 years. Many run in >windows pc's, and DMA mode in osr2 and newer, works, and is noticeablely faster. > > Guennadi Liakhovetski wrote: > > > Glad all this discussion helped at least one of us:-)) > > > > As for me, as I already mentioned in my last posting - I don't know why BIOS makes >the difference (as in your case) if ide.txt says it shouldn't?! Ok, chipset, perhaps, >is fine. But what about the hard drive? You told you had WDC AC21600H. Can you PLEASE >check waht CCC is marked on its label? PLEASE! I am trying to get an answer from WD >on this, but not yet alas... > > > > And - COME ON, GUYS! - somebody MUST know the answer - how to spot the guilty one >- kernel configuration / BIOS / chipset / disk??? > > > > Guennadi > > > > > back in, started playing in the bios. Finally fixed it. I was getting > the >same operation not permitted, that you > > > were,until i got that bios setting. But it's making me > > > wonder if it's something similar in your bios! > > > I know it wasn't the actual UDMA setting in the bios, i'm > > > wondering what it was though. I'll put a keyboard on it, > > > and poke around tonight or this weekend. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problems building test10 or test11 with AMD Duron CPU
Hi, I've been unable to build kernel 2.4.0test10 or test 11 on my new system, which has an Asus A7V mb and a AMD Duron 700 CPU, running Debian Woody (gcc 2.95.2). If I select as CPU: Athlon/K7, building the kernel fails. If I choose PPro, the kernel builds fine, and I can use it. Is this normal behaviour? I would expect to be able to build a kernel on this system with Athlon/K7 optimisations, since a Duron is from the same line of CPU's, or is that incorrect? Error messages: gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4-c -o init/main.o init/main.c In file included from /usr/src/linux/include/linux/irq.h:57, from /usr/src/linux/include/asm/hardirq.h:6, from /usr/src/linux/include/linux/interrupt.h:45, from /usr/src/linux/include/asm/string.h:296, from /usr/src/linux/include/linux/string.h:21, from /usr/src/linux/include/linux/fs.h:23, from /usr/src/linux/include/linux/capability.h:17, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:9, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/malloc.h:4, from /usr/src/linux/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux/include/asm/hw_irq.h: In function `x86_do_profile': /usr/src/linux/include/asm/hw_irq.h:198: `current' undeclared (first use in this function) /usr/src/linux/include/asm/hw_irq.h:198: (Each undeclared identifier is reported only once /usr/src/linux/include/asm/hw_irq.h:198: for each function it appears in.) In file included from /usr/src/linux/include/asm/string.h:296, from /usr/src/linux/include/linux/string.h:21, from /usr/src/linux/include/linux/fs.h:23, from /usr/src/linux/include/linux/capability.h:17, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:9, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/malloc.h:4, from /usr/src/linux/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux/include/asm/hw_irq.h: In function `x86_do_profile': /usr/src/linux/include/asm/hw_irq.h:198: `current' undeclared (first use in this function) /usr/src/linux/include/asm/hw_irq.h:198: (Each undeclared identifier is reported only once /usr/src/linux/include/asm/hw_irq.h:198: for each function it appears in.) In file included from /usr/src/linux/include/asm/string.h:296, from /usr/src/linux/include/linux/string.h:21, from /usr/src/linux/include/linux/fs.h:23, from /usr/src/linux/include/linux/capability.h:17, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:9, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/malloc.h:4, from /usr/src/linux/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux/include/linux/interrupt.h: In function `raise_softirq': /usr/src/linux/include/linux/interrupt.h:89: `current' undeclared (first use in this function) /usr/src/linux/include/linux/interrupt.h: In function `tasklet_schedule': /usr/src/linux/include/linux/interrupt.h:160: `current' undeclared (first use in this function) /usr/src/linux/include/linux/interrupt.h: In function `tasklet_hi_schedule': /usr/src/linux/include/linux/interrupt.h:174: `current' undeclared (first use in this function) In file included from /usr/src/linux/include/linux/string.h:21, from /usr/src/linux/include/linux/fs.h:23, from /usr/src/linux/include/linux/capability.h:17, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:9, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/malloc.h:4, from /usr/src/linux/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux/include/asm/string.h: In function `__constant_memcpy3d': /usr/src/linux/include/asm/string.h:305: `current' undeclared (first use in this function) /usr/src/linux/include/asm/string.h: In function `__memcpy3d': /usr/src/linux/include/asm/string.h:312: `current' undeclared (first use in this function) make[1]: *** [init/main.o]
Re: Transmeta and Linux-2.4.0-test12-pre3
On Sat, 2 Dec 2000, Alan Cox wrote: > > > But the camera is cool, and works beautifully (once you get XFree86 > > happy) thanks to Andrew Tridgell. (If I could just coax the X server > > into giving my a YUV overlay I could play DVD's with this thing). > > Start at http://www.core.binghamton.edu/~insomnia/gatos/ Heh. I integrated "ati_video.c" from ati_xv into the current XFree86 CVS sources, and yup, sure as h*ll, I can play movies fine. Quite smooth (at least the 24 fps stuff - I bet it drops frames like mad for any 30fps movies). It's quite cute. There's some redraw bug in the overlay code, and it doesn't understand virtual desktops larger than the physical desktop. Details, details. Thanks for the pointer, Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Transmeta and Linux-2.4.0-test12-pre3
On Sat, 2 Dec 2000, Alan Cox wrote: But the camera is cool, and works beautifully (once you get XFree86 happy) thanks to Andrew Tridgell. (If I could just coax the X server into giving my a YUV overlay I could play DVD's with this thing). Start at http://www.core.binghamton.edu/~insomnia/gatos/ Heh. I integrated "ati_video.c" from ati_xv into the current XFree86 CVS sources, and yup, sure as h*ll, I can play movies fine. Quite smooth (at least the 24 fps stuff - I bet it drops frames like mad for any 30fps movies). It's quite cute. There's some redraw bug in the overlay code, and it doesn't understand virtual desktops larger than the physical desktop. Details, details. Thanks for the pointer, Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problems building test10 or test11 with AMD Duron CPU
Hi, I've been unable to build kernel 2.4.0test10 or test 11 on my new system, which has an Asus A7V mb and a AMD Duron 700 CPU, running Debian Woody (gcc 2.95.2). If I select as CPU: Athlon/K7, building the kernel fails. If I choose PPro, the kernel builds fine, and I can use it. Is this normal behaviour? I would expect to be able to build a kernel on this system with Athlon/K7 optimisations, since a Duron is from the same line of CPU's, or is that incorrect? Error messages: gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4-c -o init/main.o init/main.c In file included from /usr/src/linux/include/linux/irq.h:57, from /usr/src/linux/include/asm/hardirq.h:6, from /usr/src/linux/include/linux/interrupt.h:45, from /usr/src/linux/include/asm/string.h:296, from /usr/src/linux/include/linux/string.h:21, from /usr/src/linux/include/linux/fs.h:23, from /usr/src/linux/include/linux/capability.h:17, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:9, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/malloc.h:4, from /usr/src/linux/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux/include/asm/hw_irq.h: In function `x86_do_profile': /usr/src/linux/include/asm/hw_irq.h:198: `current' undeclared (first use in this function) /usr/src/linux/include/asm/hw_irq.h:198: (Each undeclared identifier is reported only once /usr/src/linux/include/asm/hw_irq.h:198: for each function it appears in.) In file included from /usr/src/linux/include/asm/string.h:296, from /usr/src/linux/include/linux/string.h:21, from /usr/src/linux/include/linux/fs.h:23, from /usr/src/linux/include/linux/capability.h:17, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:9, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/malloc.h:4, from /usr/src/linux/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux/include/asm/hw_irq.h: In function `x86_do_profile': /usr/src/linux/include/asm/hw_irq.h:198: `current' undeclared (first use in this function) /usr/src/linux/include/asm/hw_irq.h:198: (Each undeclared identifier is reported only once /usr/src/linux/include/asm/hw_irq.h:198: for each function it appears in.) In file included from /usr/src/linux/include/asm/string.h:296, from /usr/src/linux/include/linux/string.h:21, from /usr/src/linux/include/linux/fs.h:23, from /usr/src/linux/include/linux/capability.h:17, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:9, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/malloc.h:4, from /usr/src/linux/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux/include/linux/interrupt.h: In function `raise_softirq': /usr/src/linux/include/linux/interrupt.h:89: `current' undeclared (first use in this function) /usr/src/linux/include/linux/interrupt.h: In function `tasklet_schedule': /usr/src/linux/include/linux/interrupt.h:160: `current' undeclared (first use in this function) /usr/src/linux/include/linux/interrupt.h: In function `tasklet_hi_schedule': /usr/src/linux/include/linux/interrupt.h:174: `current' undeclared (first use in this function) In file included from /usr/src/linux/include/linux/string.h:21, from /usr/src/linux/include/linux/fs.h:23, from /usr/src/linux/include/linux/capability.h:17, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:9, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/malloc.h:4, from /usr/src/linux/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux/include/asm/string.h: In function `__constant_memcpy3d': /usr/src/linux/include/asm/string.h:305: `current' undeclared (first use in this function) /usr/src/linux/include/asm/string.h: In function `__memcpy3d': /usr/src/linux/include/asm/string.h:312: `current' undeclared (first use in this function) make[1]: *** [init/main.o]
Re[2]: DMA !NOT ONLY! for triton again...
-Original Message-An interesting addition: I've just got a reply from WD - they say my disk only supports PIO4 and not DMA... I'm taking the case off the machine right now, i can guarantee you its not UDMA compatible, simply because this thing was made in early1997. :) Here we go: MDL WDAC21600-00H P/N 99-004199-000 CCC F3 20 FEB 97 DCM: BHBBKLP I've got various of these hard drives in service, for the last 4 years. Many run in windows pc's, and DMA mode in osr2 and newer, works, and is noticeablely faster. Guennadi Liakhovetski wrote: Glad all this discussion helped at least one of us:-)) As for me, as I already mentioned in my last posting - I don't know why BIOS makes the difference (as in your case) if ide.txt says it shouldn't?! Ok, chipset, perhaps, is fine. But what about the hard drive? You told you had WDC AC21600H. Can you PLEASE check waht CCC is marked on its label? PLEASE! I am trying to get an answer from WD on this, but not yet alas... And - COME ON, GUYS! - somebody MUST know the answer - how to spot the guilty one - kernel configuration / BIOS / chipset / disk??? Guennadi back in, started playing in the bios. Finally fixed it. I was getting the same operation not permitted, that you were,until i got that bios setting. But it's making me wonder if it's something similar in your bios! I know it wasn't the actual UDMA setting in the bios, i'm wondering what it was though. I'll put a keyboard on it, and poke around tonight or this weekend. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
Does it? At which point? To me it looks like it calls dev-do_ioctl
or am I missing something?
It uses SIOCSIFMAP, which (I think) winds up in dev.c here:
case SIOCSIFMAP:
if (dev-set_config) {
if (!netif_device_present(dev))
return -ENODEV;
return dev-set_config(dev,ifr-ifr_map);
}
return -EOPNOTSUPP;
p.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
(CC list trimmed)
Philip Blundell writes:
Does it? At which point? To me it looks like it calls dev-do_ioctl
or am I missing something?
It uses SIOCSIFMAP, which (I think) winds up in dev.c here:
case SIOCSIFMAP:
if (dev-set_config) {
if (!netif_device_present(dev))
return -ENODEV;
return dev-set_config(dev,ifr-ifr_map);
}
return -EOPNOTSUPP;
It definitely does end up there. However, the ethtool ioctls end up
in dev-do_ioctl.
_
|_| - ---+---+-
| | Russell King[EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ - /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test12-pre3] ip_conntrack_proto_tcp.c compilation fix.
Yoann Vandoorselaere [EMAIL PROTECTED] writes:
--- linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c.origSat Dec 2 16:18:05
2000
+++ linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Sat Dec 2 16:19:04 2000
@@ -228,6 +228,6 @@
}
struct ip_conntrack_protocol ip_conntrack_protocol_tcp
-= { { NULL, NULLpkt_IPPROTO_TCP, "tcp",
-tcp_ableto_tuple, tcp_invert_tuple, tcp_print_tuple, tcp_print_conntrack,
+= { { NULL, NULL }, IPPROTO_TCP, "tcp",
+tcp_pkt_to_tuple, tcp_invert_tuple, tcp_print_tuple, tcp_print_conntrack,
tcp_packet, tcp_new, NULL };
Just ignore this patch, it seem this file got corrupted on my FS...
--
-- Yoann http://www.mandrakesoft.com/~yoann/
An engineer from NVidia, while asking him to release cards specs said :
"Actually, we do write our drivers without documentation."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Bugs in test8 and test11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! I encountered some wiered bugs in test8 -- and after an upgrade to test11 there too -- yesterday. I hope this address is not totally inadequate for this report. test8: I noticed for a while now, that the keyboard on my console does not work sometimes. Yesterday I figured out, that this only happens when I have my Printer turned on. I have A Gigabyte 6BXDS Mainboard an a HP 6P Laserprinter. The rest of my system is quite recent (I do regular updates to whatever is in debian's unstable branch, the last update for this computer was about 4 weeks ago). test11: Doesen't start, but hangs right after "Uncompressing the kernel". I since I overwrote the test8 kernel with the new one I can't produce more informations (I had to reinstall the kernel from my newest LInux CDs which unfortunatly did not allow access to my disc. I used the new e2fs-features that are incompatible to pre-2.2 kernels:( ). Well, it does not really matter because of the data, but it is bad that I can't add the informations you requested to this mail. Please feel free to contact me for more information (or additional tests). I'll do what I can to help. - -- Gruss, Tobias - --- Tobias Hunger The box said: 'Windows 95 or better' [EMAIL PROTECTED] So I installed Linux. - --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE6KjEiVND+cGpk748RAoMHAJ9jpQfyrryGu83fXuiVQr8QVhonggCeIT4N OVPHDsZ6h2QAmoCe2jQhMEg= =rrWu -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Multi-Chanel ATA, was: Re: ATA-4, ATA-5 TCQ status
On Tue, 28 Nov 2000, Uwe Bonnes wrote: I bought the 2 channel thing for 400 DM (~160$). I guess the 8 chanel You can buy one for under $30 with two channels. So even is the 8 channel one is $200 and not $120 (4x30) I would still prefer this one. thing is about 1000DM. That's not too much I think. Even single two chanel PCI adapter is around 100 DM. And as your ideal card propably isn't produced in big numbers, it will be more expensive per chanel than the commodity products... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
Alexander Viro wrote: Erm... Not that ignoring the return values was a bright idea, but the lack of reliable ordered datagram protocol in IP family is not a good thing. It can be implemented over TCP, but it's a big overkill. IL is a nice thing to have... Pet peeve? There are about five "reliable UDPs" floating around. Take a look at http://www.faqs.org/rfcs/rfc2960.html SCTP is mainly designed as a way of transporting telephony signalling information across IP. But it is now a quite general purpose protocol. Culturally, this is "Telephony industry comes to IP. Telephony industry is appalled. IP industry gets a clue". SCTP provides the reliable delivery of messages to which you refer. It's slightly more efficient than TCP for a given set of network characteristics - there's no statement about implementation efficiency here. No head-of-line blocking issues. One very interesting part of SCTP is that transport endpoints are explicitly set up between *hosts*, not between IP addresses. The protocol is designed around multihomed hosts. I don't know if anyone has looked into mapping SCTP capabilities onto the BSD socket API. It may be hard. The reference implementation is for userland Linux. It's at ftp://standards.nortelnetworks.com/sigtran/ A good kernel-mode implementation of SCTP for Linux would be a very big project. But also a very big contribution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
corruption on my ext2fs with 2.4.0-test10
Hello people, Since I've seen that there are some problems with corruption on ext2fs I thought that it would be a good idea to report my problem too. I have a 2.4.0-test10 patched with reiserfs (but I do not use it - it was just in my plan to create a partition sometime; so I think that it does not matter to much). Kernel compiled with egcs-1.1.2: root@invasion:~# gcc -v Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) The problem is that I tried to build perl-5.6.0 and some of my tests were failing. First I thought that it is a problem with shared libraries but I was wrong, in the test directory I have a file named "big" which has 5Gb (almost): root@invasion:/# debugfs /dev/hda2 debugfs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 debugfs: cd /usr/src/perl-5.6.0/t/ debugfs: ls 1097360 (12) . 1354979 (184) .. 1097503 (3900) big debugfs: ls -l 1097360 40700504 10014096 3-Dec-2000 13:43 . 1354979 40755504 10014096 3-Dec-2000 13:43 .. 1097503 100644 0 0 53 3-Dec-2000 10:00 big Ofcourse this is wrong because: debugfs: q root@invasion:/# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 5999072756772 4932648 13% / I've checked my syslog and messages for ext2 warnings but I found nothing unusual. The system is UP and dmesg output is attached. OTOH does anyone know how to silent messages like: NAT: 0 dropping untracked packet c7d205c0 1 192.129.3.151 - 224.0.0.1 NAT: 0 dropping untracked packet c7d129a0 1 192.129.3.151 - 224.0.0.1 They are annoying and after some time they just fill up my dmesg output (all dropped packets are multicast just like the two above). -- Mircea Damian E-mails: [EMAIL PROTECTED], [EMAIL PROTECTED] WebPage: http://taz.mania.k.ro/~dmircea/ uto BOOT_IMAGE=Linux ro root=302 console=ttyS0,38400 Initializing CPU#0 Detected 400.914 MHz processor. Console: colour VGA+ 80x30 Calibrating delay loop... 799.54 BogoMIPS Memory: 126788k/131072k available (1207k kernel code, 3896k reserved, 85k data, 196k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Before vendor init, caps: 0183fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0183fbff CPU: After generic, caps: 0183fbff CPU: Common caps: 0183fbff CPU: Intel Pentium II (Deschutes) stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 0004 ESR value after enabling vector: ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. Synchronizing Arb IDs. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-16, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 activating NMI Watchdog ... done. number of MP IRQ sources: 20. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00170011 ... : max redirection entries: 0017 ... : IO APIC version: 0011 register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 001 01 000 0 01139 02 001 01 000 0 01131 03 001 01 000 0 01141 04 001 01 000 0 01149 05 001 01 000 0 01151 06 001 01 000 0 01159 07 001 01 000 0 01161 08 001 01 000 0 01169 09 001 01 000 0 01171 0a 001 01 000 0 01179 0b 001 01 000 0 01181 0c 001 01 000 0 01189 0d 000 00 100 0 00000 0e 001 01 000 0 01191 0f 001 01 000 0 01199 10 000 00 100 0 00000 11 001 01 110 1 011A1 12 001 01 110 1 011A9 13 001 01 110 1 011B1 14 000 00 100 0 00000 15 000 00 100 0 00000 16 000 00 100 0 00000 17 000 00 100 0 00000 IRQ to pin mappings: IRQ0 - 2 IRQ1 - 1 IRQ3 - 3 IRQ4 - 4 IRQ5 - 5 IRQ6 - 6 IRQ7 - 7 IRQ8 - 8 IRQ9 - 9 IRQ10
Re: Problems building test10 or test11 with AMD Duron CPU
On Sun, Dec 03, 2000 at 11:56:32AM +0100, Frederik Vanrenterghem wrote: Hi, I've been unable to build kernel 2.4.0test10 or test 11 on my new system, which has an Asus A7V mb and a AMD Duron 700 CPU, running Debian Woody (gcc 2.95.2). If I select as CPU: Athlon/K7, building the kernel fails. If I choose PPro, the kernel builds fine, and I can use it. Is this normal behaviour? I would expect to be able to build a kernel on this system with Athlon/K7 optimisations, since a Duron is from the same line of CPU's, or is that incorrect? I have got the exact same setup. Everything works fine when compiling for Athlon/K7. I will send you my .config. Jens -- Jens Taprogge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: corruption on my ext2fs with 2.4.0-test10
Sorry that I have to follow my self but I forgot to say that e2fsck is happy with it: root@invasion:~# e2fsck -C 0 -f /dev/hda2 e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/hda2: 43056/1548288 files (1.7% non-contiguous), 237689/1548264 blocks ... file-utils like ls, rm say: root@invasion:/usr/src/perl-5.6.0/t# ls -sail /bin/ls: big: Value too large for defined data type total 8 10973604 drwx-- 2 504 1001 4096 Dec 3 13:43 ./ 13549794 drwxr-xr-x 3 504 1001 4096 Dec 3 13:43 ../ root@invasion:/usr/src/perl-5.6.0/t# rm big rm: cannot remove `big': Value too large for defined data type I can not keep this machine down (my /-fs is read-only right now just to be sure that nothing changes) for too much time. On Sun, Dec 03, 2000 at 02:24:33PM +0200, Mircea Damian wrote: Hello people, Since I've seen that there are some problems with corruption on ext2fs I thought that it would be a good idea to report my problem too. I have a 2.4.0-test10 patched with reiserfs (but I do not use it - it was just in my plan to create a partition sometime; so I think that it does not matter to much). Kernel compiled with egcs-1.1.2: root@invasion:~# gcc -v Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) The problem is that I tried to build perl-5.6.0 and some of my tests were failing. First I thought that it is a problem with shared libraries but I was wrong, in the test directory I have a file named "big" which has 5Gb (almost): root@invasion:/# debugfs /dev/hda2 debugfs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 debugfs: cd /usr/src/perl-5.6.0/t/ debugfs: ls 1097360 (12) . 1354979 (184) .. 1097503 (3900) big debugfs: ls -l 1097360 40700504 10014096 3-Dec-2000 13:43 . 1354979 40755504 10014096 3-Dec-2000 13:43 .. 1097503 100644 0 0 53 3-Dec-2000 10:00 big Ofcourse this is wrong because: debugfs: q root@invasion:/# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 5999072756772 4932648 13% / I've checked my syslog and messages for ext2 warnings but I found nothing unusual. The system is UP and dmesg output is attached. OTOH does anyone know how to silent messages like: NAT: 0 dropping untracked packet c7d205c0 1 192.129.3.151 - 224.0.0.1 NAT: 0 dropping untracked packet c7d129a0 1 192.129.3.151 - 224.0.0.1 They are annoying and after some time they just fill up my dmesg output (all dropped packets are multicast just like the two above). uto BOOT_IMAGE=Linux ro root=302 console=ttyS0,38400 Initializing CPU#0 Detected 400.914 MHz processor. Console: colour VGA+ 80x30 Calibrating delay loop... 799.54 BogoMIPS Memory: 126788k/131072k available (1207k kernel code, 3896k reserved, 85k data, 196k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Before vendor init, caps: 0183fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0183fbff CPU: After generic, caps: 0183fbff CPU: Common caps: 0183fbff CPU: Intel Pentium II (Deschutes) stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 0004 ESR value after enabling vector: ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. Synchronizing Arb IDs. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-16, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 activating NMI Watchdog ... done. number of MP IRQ sources: 20. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00170011 ... : max redirection entries: 0017 ... : IO APIC version: 0011 register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 001 01 00
Problems with CDROMVOLCTRL
Hi, CDROMVOLCTRL does not work with my configuration in test11. The ioctl always returns an error and volume stays the same (seen with xmcd and gtcd). I tried the patch at *.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-test11/cd-1.bz2 This changed the error code from some bogus large positive number to -EOPNOTSUPP :) However, volume control works fine in 2.2.17, so the hardware shouldn't be the culprit. The cdrom drive in question is an old TEAC CD-56S on an Adaptec AHA-2940 (narrow) controller. Cheers, Roderich -- There is something to be learned from a rainstorm. When meeting with a sudden shower, you try not to get wet and run quickly along the road. But doing such things as passing under the eaves of houses, you still get wet. When you are resolved from the beginning, you will not be perplexed, though you still get the same soaking. -- Hagakure - The Book of the Samurai Roderich Schupp mailto:[EMAIL PROTECTED] ExperTeam GmbH http://www.experteam.de/ Munich, Germany - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
negative NFS cookies: bad C library or bad kernel?
" " == Kevin Buhr [EMAIL PROTECTED] writes: However, who's to blame here? It can't be CFS---any four-byte cookie should be valid, right? Is the kernel NFS client code to blame? If it's going to be using cookies as offsets, shouldn't we have an nfs_lseek that special-cases directory lseeks (at least those using SEEK_SET) to take negative offsets, so utilities and libraries don't need to be bigfile-aware just to read directories? And what in the world can we do about bogus code like the: The problem here is that in NFS we have to match cookies in lieu of using true directory 'offsets'. I did try to work around this by using offsets into the page cache and the likes, however this sort of scheme is almost impossible to implement sanely because an offset into the page cache changes all the time. This was why I returned to Olaf's scheme in which we use the cookie as the return value for lseek friends. The problem then arises that lseek tries to cram both a returned offset and an error value into the return values. When NFS returns an opaque type, this causes a problem; one that won't be fixed by adding an nfs_lseek. Furthermore, lseek is 32-bits: for NFSv3 and higher, the cookie is 64-bits... I know of no scheme that can fix all problems with lseek. For example concerning SEEK_CUR: forget about it. NFS is not POSIX and never will be. You simply cannot give meaningful semantics to SEEK_CUR as long as the client knows nothing about the organization of dirents on the server. We can return offsets that are based on the internal caching of dirents, but the problem then is that you need to find some permanent 'index' that doesn't change when we invalidate the cache and read it in anew. Making stuff like 'rm -rf *' work (when the directory size organization keeps changing) is quite a challenge... One possibility would be to make a pointer into a table of cookies be our 'offset'. That could work if we can ensure that cookies can't move around... Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
On Sun, 3 Dec 2000, Keith Owens wrote: If you go down this path, please add a standard performance monitoring method to query the current capacity of an interface. to report "eth0 is handling 1 Megabyte/second, but we cannot tell if that is 90% (10BaseT) or 9% (100BaseT) utilization". We should report capacity rather than speed because speed alone is not the controlling factor, other things like half or full duplex affect the capacity. Well, ethtool interface supports reporting media selection as well as [re]setting media setting. I dunno if we could report what capacity an interface is handling without adding code to hot paths... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: how to compile redhat6.0 kernel
At 03:00 AM 12/3/00 +, Mourad wrote: hi: i wanna recompile the kernel to reset some variables "ip multicasting", and i have a root access. so can you please tell me in steps (detailed) , how to recompile an installed kernel of redhat6.0. thanx mourad, Here is a URL for a Linux Journal article that discusses Kernel Compiling http://www2.linuxjournal.com/lj-issues/issue43/2404.html Pete =-= A4C7 3342 EF0C 2504 9FBF 6808 C5C0 7A78 354A B81D =-= Hi! I'm a signature virus! add me to your signature to help me spread! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Q: tq_scheduler slower on SMP ?
Hi, with kernel 2.2.17 I need to have a function in my driver to handle some data. I used BH with tq_immediate, but I found out, that my function need to be called outside of interrupt context, but still as soon as I need it. So I decided to use the tq_scheduler queue and put my function on the task_queue in my interrupt handler. It seems to work good without SMP, but with SMP my function is called with delays of many msecs. Since the tq_scheduler queue is only started from schedule(), do I need to set some flag to run schedule asap ? Or has someone better idea for my function ? Thanx, Armin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
