Re: Linus' laptop and Num lock status
On Wed, 2007-02-14 at 11:32 -0800, Linus Torvalds wrote: > > On Wed, 14 Feb 2007, Jean Delvare wrote: > > > > On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The > > BIOS RAM is mapped at 0x400 so all we need to do is to one byte from > > RAM (offset 0x497). This is how Suse's hwinfo does. > > Heh. Shows just how much I ever used DOS and BIOS. > > > But maybe the first question to ask is: why is the BIOS setting lost in > > the first place? Why is the kernel resetting the led state? > > Ehh. Silly question. "Those flags, they do nothing." > > The kernel needs to know what they are in order to react correctly to > them. And since you can't read them from hardware, the only way to know > what they are (if you don't know about BIOS magic areas) is to SET THEM. > > Which is what the kernel has traditionally always done. Going forward can the kernel peek at 0x497 and follow the BIOS setting? I checked, and looking at offset 0x497 seems to work fine on a couple of systems with USB keyboards. People have long grumbled and complained about the current kernel behavior (1). Dax Kelson (1) http://lkml.org/lkml/1999/2/27/6 http://www.google.com/search?q=linux+num+lock https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115909 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
On Wed, 2007-02-14 at 11:12 -0800, Linus Torvalds wrote:
>
> On Wed, 14 Feb 2007, Dax Kelson wrote:
> >
> > Are there any technical or political reasons why kernel can't change
> > from "force off" to "Follow BIOS"?
>
> How would you query it? I'm not even 100% sure that you can on all
> keyboards. We never query the leds, we always set them. I think. I don't
> know of any AT kbd command to read the led state out of the keyboard.
>
> Linus
The GPL'd "hwinfo" command shipped with SUSE queries the BIOS setting by
reading a single byte from /dev/mem.
In src/hd/bios.c around line 262 it has:
if(hd_data->bios_ram.data) {
bios_ram = hd_data->bios_ram.data;
[snip]
bt->led.scroll_lock = bios_ram[0x97] & 1;
bt->led.num_lock = (bios_ram[0x97] >> 1) & 1;
bt->led.caps_lock = (bios_ram[0x97] >> 2) & 1;
bt->led.ok = 1;
Cut-n-paste commands to get to the source:
cd /tmp
wget
http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/src/hwinfo-13.21-3.src.rpm
rpm2cpio < hwinfo-13.21-3.src.rpm | cpio -id
tar jxf hwinfo-13.21.tar.bz2
cd hwinfo-13.21/src/hd
Dax Kelson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus' laptop and Num lock status
According to the lore(1) the reason that the kernel unconditionally turns off the num lock was so that Linus' laptop came up ready to type. The issue is that if you force num lock on, then laptop users are messed up since for most laptops your keyboard changes as follows: 7890 = 789* uiop = 456- jkl; = 123+ m./ = 0./ So the only safe choice is "force off" or "Follow BIOS" (preferable). Are there any technical or political reasons why kernel can't change from "force off" to "Follow BIOS"? Some distributions implement "Follow BIOS" in their bootup scripts but the most just follow the kernel. IMHO, it would be very nice if the "Follow BIOS" was done by the kernel so this would Just Work(tm) everywhere in all situations (such as rescue environments where the normal bootup scripts aren't processed). Thanks, Dax Kelson (1) http://www.redhat.com/archives/fedora-test-list/2003-September/msg00713.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linus' laptop and Num lock status
According to the lore(1) the reason that the kernel unconditionally turns off the num lock was so that Linus' laptop came up ready to type. The issue is that if you force num lock on, then laptop users are messed up since for most laptops your keyboard changes as follows: 7890 = 789* uiop = 456- jkl; = 123+ m./ = 0./ So the only safe choice is force off or Follow BIOS (preferable). Are there any technical or political reasons why kernel can't change from force off to Follow BIOS? Some distributions implement Follow BIOS in their bootup scripts but the most just follow the kernel. IMHO, it would be very nice if the Follow BIOS was done by the kernel so this would Just Work(tm) everywhere in all situations (such as rescue environments where the normal bootup scripts aren't processed). Thanks, Dax Kelson (1) http://www.redhat.com/archives/fedora-test-list/2003-September/msg00713.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
On Wed, 2007-02-14 at 11:12 -0800, Linus Torvalds wrote:
On Wed, 14 Feb 2007, Dax Kelson wrote:
Are there any technical or political reasons why kernel can't change
from force off to Follow BIOS?
How would you query it? I'm not even 100% sure that you can on all
keyboards. We never query the leds, we always set them. I think. I don't
know of any AT kbd command to read the led state out of the keyboard.
Linus
The GPL'd hwinfo command shipped with SUSE queries the BIOS setting by
reading a single byte from /dev/mem.
In src/hd/bios.c around line 262 it has:
if(hd_data-bios_ram.data) {
bios_ram = hd_data-bios_ram.data;
[snip]
bt-led.scroll_lock = bios_ram[0x97] 1;
bt-led.num_lock = (bios_ram[0x97] 1) 1;
bt-led.caps_lock = (bios_ram[0x97] 2) 1;
bt-led.ok = 1;
Cut-n-paste commands to get to the source:
cd /tmp
wget
http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/src/hwinfo-13.21-3.src.rpm
rpm2cpio hwinfo-13.21-3.src.rpm | cpio -id
tar jxf hwinfo-13.21.tar.bz2
cd hwinfo-13.21/src/hd
Dax Kelson
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
On Wed, 2007-02-14 at 11:32 -0800, Linus Torvalds wrote: On Wed, 14 Feb 2007, Jean Delvare wrote: On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The BIOS RAM is mapped at 0x400 so all we need to do is to one byte from RAM (offset 0x497). This is how Suse's hwinfo does. Heh. Shows just how much I ever used DOS and BIOS. But maybe the first question to ask is: why is the BIOS setting lost in the first place? Why is the kernel resetting the led state? Ehh. Silly question. Those flags, they do nothing. The kernel needs to know what they are in order to react correctly to them. And since you can't read them from hardware, the only way to know what they are (if you don't know about BIOS magic areas) is to SET THEM. Which is what the kernel has traditionally always done. Going forward can the kernel peek at 0x497 and follow the BIOS setting? I checked, and looking at offset 0x497 seems to work fine on a couple of systems with USB keyboards. People have long grumbled and complained about the current kernel behavior (1). Dax Kelson (1) http://lkml.org/lkml/1999/2/27/6 http://www.google.com/search?q=linux+num+lock https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115909 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Sat, 2006-12-02 at 01:56 +0100, Christoph Anton Mitterer wrote: > Hi. > > Perhaps some of you have read my older two threads: > http://marc.theaimsgroup.com/?t=11631244001=1=2 and the even > older http://marc.theaimsgroup.com/?t=11629131451=1=2 > > The issue was basically the following: > I found a severe bug mainly by fortune because it occurs very rarely. > My test looks like the following: I have about 30GB of testing data on > my harddisk,... I repeat verifying sha512 sums on these files and check > if errors occur. > One test pass verifies the 30GB 50 times,... about one to four > differences are found in each pass. This sounds very similar to a corruption issue I was experiencing on my nforce4 based system. After replacing most of my hardware to no avail, I discovered that if increased the voltage for my RAM chips the corruption went away. Note that I was not overclocking at all. Worth a try. Dax Kelson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Sat, 2006-12-02 at 01:56 +0100, Christoph Anton Mitterer wrote: Hi. Perhaps some of you have read my older two threads: http://marc.theaimsgroup.com/?t=11631244001r=1w=2 and the even older http://marc.theaimsgroup.com/?t=11629131451r=1w=2 The issue was basically the following: I found a severe bug mainly by fortune because it occurs very rarely. My test looks like the following: I have about 30GB of testing data on my harddisk,... I repeat verifying sha512 sums on these files and check if errors occur. One test pass verifies the 30GB 50 times,... about one to four differences are found in each pass. This sounds very similar to a corruption issue I was experiencing on my nforce4 based system. After replacing most of my hardware to no avail, I discovered that if increased the voltage for my RAM chips the corruption went away. Note that I was not overclocking at all. Worth a try. Dax Kelson - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should VLANs be devices or something else?
On Tue, 19 Jun 2001, Ben Greear wrote: > I have had a good discussion with Dave Miller today, and there > is one outstanding issue to clear up before my 802.1Q VLAN patch may > be considered for acceptance into the kernel: > > Should VLANs be devices or some other thing? I would vote that VLANs be devices. Conceptually, VLANs as network devices is a no brainer. Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should VLANs be devices or something else?
On Tue, 19 Jun 2001, Ben Greear wrote: I have had a good discussion with Dave Miller today, and there is one outstanding issue to clear up before my 802.1Q VLAN patch may be considered for acceptance into the kernel: Should VLANs be devices or some other thing? I would vote that VLANs be devices. Conceptually, VLANs as network devices is a no brainer. Dax - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] support for Cobalt Networks (x86 only) systems (for realthis time)
Tim Hockin said once upon a time (Thu, 31 May 2001): > Aattached is a (large, but self contained) patch for Cobalt Networks suport > for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there > is anything that would prevent this from general inclusion in the next > release. I can vouch for these patches stability wise. I've been running an earlier version of these patches (for 2.4.4) on a Qube 3 acting as a firewall for 3 weeks without any problems. Incidently, that Qube 3 is running Red Hat 7.1 and using reiserfs on all filesystems except for /boot. Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] support for Cobalt Networks (x86 only) systems (for realthis time)
Tim Hockin said once upon a time (Thu, 31 May 2001): Aattached is a (large, but self contained) patch for Cobalt Networks suport for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there is anything that would prevent this from general inclusion in the next release. I can vouch for these patches stability wise. I've been running an earlier version of these patches (for 2.4.4) on a Qube 3 acting as a firewall for 3 weeks without any problems. Incidently, that Qube 3 is running Red Hat 7.1 and using reiserfs on all filesystems except for /boot. Dax - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Xircom RealPort versus 3COM 3C3FEM656C
I currently have three Xircom RealPort Carbus modem/fast ethernet cards. The current driver blows major chunks (it has very poor performance, and stops working under load). I'm told the driver issues are because of hardware issues. The really nice feature of this card is the form factor though. 3COM has a new card that has a form factor like the Xircom RealPort. It is the 3C3FEM656C card. You and find information about it here: http://www.3com.com/products/en_US/detail.jsp?pathtype=purchase=features=3C3FEM656C I've been unable to find information about Linux support for this 3COM card. Is the modem a win modem, or a regular modem? Is there any planned support for this 3COM card? Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Xircom RealPort versus 3COM 3C3FEM656C
I currently have three Xircom RealPort Carbus modem/fast ethernet cards. The current driver blows major chunks (it has very poor performance, and stops working under load). I'm told the driver issues are because of hardware issues. The really nice feature of this card is the form factor though. 3COM has a new card that has a form factor like the Xircom RealPort. It is the 3C3FEM656C card. You and find information about it here: http://www.3com.com/products/en_US/detail.jsp?pathtype=purchasetab=featuressku=3C3FEM656C I've been unable to find information about Linux support for this 3COM card. Is the modem a win modem, or a regular modem? Is there any planned support for this 3COM card? Dax - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question: Status of USAGI/FreeSWAN?
FreeSWAN has IPSec for IPv4 on Linux. USAGI is better/more conformant IPv6 (with IPSec for IPv6 in development) for Linux. The USAGI goal is to get themselves folded into the official kernel (and glibc) at some point "in the near future". What are the plans to get all this (FreeSWAN,USAGI) folded into the kernel. Are the "crypto" legal issues resolved enough now to have crypto in the official kernel? It would nice to not to have to chase down all these seperate components and eventually manually patch. I'm going a bit crazy keeping track of several different kernel patches (IPSec,IPv6 in particular) while my *BSD friends just laugh at me. :) Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question: Status of USAGI/FreeSWAN?
FreeSWAN has IPSec for IPv4 on Linux. USAGI is better/more conformant IPv6 (with IPSec for IPv6 in development) for Linux. The USAGI goal is to get themselves folded into the official kernel (and glibc) at some point in the near future. What are the plans to get all this (FreeSWAN,USAGI) folded into the kernel. Are the crypto legal issues resolved enough now to have crypto in the official kernel? It would nice to not to have to chase down all these seperate components and eventually manually patch. I'm going a bit crazy keeping track of several different kernel patches (IPSec,IPv6 in particular) while my *BSD friends just laugh at me. :) Dax - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP Acounting Idea for 2.5
David Findlay said once upon a time (Tue, 17 Apr 2001): > I am using the kernel IP Accounting in Linux to record the amount of data > transfered via my Linux internet gateway from individual IP addresses. This > currently requires me to set up an accounting rule for each IP address that I > want to record accounting info for. If I had 200 machines to individually log > this would require me to set 200 rules. In 1999 I setup a Linux kernel 2.2 box to monitor traffic for about 2500 hosts. I created two rules for each host (to monitor inbound and outbound). I had over 5000 total rules on a Pentium II 300 Mhz box. I wrote some perl glue so I could accounts on a per customer basis (each customer had one or more IPs, not necessarily contiguous) and graph the results in MRTG. There was ZERO performance problems on the box. The box is still runningly happily today. I don't there is a "problem" to fix. Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP Acounting Idea for 2.5
David Findlay said once upon a time (Tue, 17 Apr 2001): I am using the kernel IP Accounting in Linux to record the amount of data transfered via my Linux internet gateway from individual IP addresses. This currently requires me to set up an accounting rule for each IP address that I want to record accounting info for. If I had 200 machines to individually log this would require me to set 200 rules. In 1999 I setup a Linux kernel 2.2 box to monitor traffic for about 2500 hosts. I created two rules for each host (to monitor inbound and outbound). I had over 5000 total rules on a Pentium II 300 Mhz box. I wrote some perl glue so I could accounts on a per customer basis (each customer had one or more IPs, not necessarily contiguous) and graph the results in MRTG. There was ZERO performance problems on the box. The box is still runningly happily today. I don't there is a "problem" to fix. Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Worm (fwd)
Gerhard Mack said once upon a time (Fri, 23 Mar 2001): > On Fri, 23 Mar 2001, Bob Lorenzini wrote: > > > I'm annoyed when persons post virus alerts to unrelated lists but this > > is a serious threat. If your offended flame away. > > This should be a wake up call... distributions need to stop using product > with consistently bad security records. This TSIG bug in BIND 8 that is being exploited was added to BIND 8 by the same team who wrote BIND 9. In fact the last two major remote root compromises (TSIG and NXT) for BIND 8 was in code added to BIND 8 by the BIND 9 developers. Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Worm (fwd)
Gerhard Mack said once upon a time (Fri, 23 Mar 2001): On Fri, 23 Mar 2001, Bob Lorenzini wrote: I'm annoyed when persons post virus alerts to unrelated lists but this is a serious threat. If your offended flame away. This should be a wake up call... distributions need to stop using product with consistently bad security records. This TSIG bug in BIND 8 that is being exploited was added to BIND 8 by the same team who wrote BIND 9. In fact the last two major remote root compromises (TSIG and NXT) for BIND 8 was in code added to BIND 8 by the BIND 9 developers. Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1-ac3 oops decoded with ksymoops
Here is an oops I got on one of my computers. It came about 5 mins after I forcibly ejected a PCMCIA card (A Spectrum24t 802.11b card), I don't know if it is related. The oops: == kernel BUG at sched.c:714! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001b ebx: c1167de0 ecx: c3602000 edx: c0227c08 esi: c1167d70 edi: c1166000 ebp: c1167d5c esp: c1167d2c ds: 0018 es: 0018 ss: 0018 Process kapmd-idled (pid: 3, stackpage=c1167000) Stack: c01eaee5 c01eb036 02ca c1167de0 c1167d70 c1166000 c3a16c80 c3dbb380 c0231a80 c0228b40 c1167de0 c1167de0 c010792d c1167dcc c1167db8 c1167dcc 0001 c1166000 c1167dec c1167dec c0107a78 c1167de0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 55 89 e5 83 ec 10 57 56 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing ksymoops output: === ksymoops 2.3.4 on i586 2.4.1-ac3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1-ac3/ (default) -m /usr/src/linux/System.map (specified) invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 001b ebx: c1167de0 ecx: c3602000 edx: c0227c08 esi: c1167d70 edi: c1166000 ebp: c1167d5c esp: c1167d2c ds: 0018 es: 0018 ss: 0018 Process kapmd-idled (pid: 3, stackpage=c1167000) Stack: c01eaee5 c01eb036 02ca c1167de0 c1167d70 c1166000 c3a16c80 c3dbb380 c0231a80 c0228b40 c1167de0 c1167de0 c010792d c1167dcc c1167db8 c1167dcc 0001 c1166000 c1167dec c1167dec c0107a78 c1167de0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 55 89 e5 83 ec 10 57 56 >>EIP; c0111634<= Trace; c010792d <__down+55/9c> Trace; c0107a78 <__down_failed+8/c> Trace; c01e41c5 Trace; c011d4e0 <__call_usermodehelper+0/2c> Trace; c011d4e0 <__call_usermodehelper+0/2c> Trace; c01a574d Trace; c0181f66 Trace; c01853b1 Trace; c01a55bd Trace; c018ca48 Trace; c48cd52e <[spectrum24t_cs]adapter_release+c6/188> Trace; c48d31c4 <[spectrum24t_cs]__FUNC__.1131+10/60> Trace; c48cd468 <[spectrum24t_cs]adapter_release+0/188> Trace; c01199bd Trace; c0119897 Trace; c0119ca2 Trace; c010ccd6 Trace; c0117123 Trace; c0117058 Trace; c0116f60 Trace; c010a161 Trace; c0108e60 Trace; c010f26a Trace; c0100018 Trace; c010f340 Trace; c010faad Trace; c01103e7 Trace; c0107423 Trace; c010742c Code; c0111634 <_EIP>: Code; c0111634<= 0: 0f 0b ud2a <= Code; c0111636 2: 8d 65 dc lea0xffdc(%ebp),%esp Code; c0111639 5: 5bpop%ebx Code; c011163a 6: 5epop%esi Code; c011163b 7: 5fpop%edi Code; c011163c 8: 89 ec mov%ebp,%esp Code; c011163e a: 5dpop%ebp Code; c011163f b: c3ret Code; c0111640 <__wake_up+0/98> c: 55push %ebp Code; c0111641 <__wake_up+1/98> d: 89 e5 mov%esp,%ebp Code; c0111643 <__wake_up+3/98> f: 83 ec 10 sub$0x10,%esp Code; c0111646 <__wake_up+6/98> 12: 57push %edi Code; c0111647 <__wake_up+7/98> 13: 56 push %esi Kernel panic: Aiee, killing interrupt handler! Dax Kelson - 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.1-ac3 oops decoded with ksymoops
Here is an oops I got on one of my computers. It came about 5 mins after I forcibly ejected a PCMCIA card (A Spectrum24t 802.11b card), I don't know if it is related. The oops: == kernel BUG at sched.c:714! invalid operand: CPU:0 EIP:0010:[c0111634] EFLAGS: 00010286 eax: 001b ebx: c1167de0 ecx: c3602000 edx: c0227c08 esi: c1167d70 edi: c1166000 ebp: c1167d5c esp: c1167d2c ds: 0018 es: 0018 ss: 0018 Process kapmd-idled (pid: 3, stackpage=c1167000) Stack: c01eaee5 c01eb036 02ca c1167de0 c1167d70 c1166000 c3a16c80 c3dbb380 c0231a80 c0228b40 c1167de0 c1167de0 c010792d c1167dcc c1167db8 c1167dcc 0001 c1166000 c1167dec c1167dec c0107a78 c1167de0 Call Trace: [c010792d] [c0107a78] [c01e41c5] [c011d4e0] [c011d4e0] [c01a574d] [c0181f66] [c01853b1] [c01a55bd] [c018ca48] [c48cd52e] [c48d31c4] [c48cd468] [c01199bd] [c0119897] [c0119ca2] [c010ccd6] [c0117123] [c0117058] [c0116f60] [c010a161] [c0108e60] [c010f26a] [c0100018] [c010f340] [c010faad] [c01103e7] [c0107423] [c010742c] Code: 0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 55 89 e5 83 ec 10 57 56 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing ksymoops output: === ksymoops 2.3.4 on i586 2.4.1-ac3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1-ac3/ (default) -m /usr/src/linux/System.map (specified) invalid operand: CPU:0 EIP:0010:[c0111634] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 001b ebx: c1167de0 ecx: c3602000 edx: c0227c08 esi: c1167d70 edi: c1166000 ebp: c1167d5c esp: c1167d2c ds: 0018 es: 0018 ss: 0018 Process kapmd-idled (pid: 3, stackpage=c1167000) Stack: c01eaee5 c01eb036 02ca c1167de0 c1167d70 c1166000 c3a16c80 c3dbb380 c0231a80 c0228b40 c1167de0 c1167de0 c010792d c1167dcc c1167db8 c1167dcc 0001 c1166000 c1167dec c1167dec c0107a78 c1167de0 Call Trace: [c010792d] [c0107a78] [c01e41c5] [c011d4e0] [c011d4e0] [c01a574d] [c0181f66] [c01853b1] [c01a55bd] [c018ca48] [c48cd52e] [c48d31c4] [c48cd468] [c01199bd] [c0119897] [c0119ca2] [c010ccd6] [c0117123] [c0117058] [c0116f60] [c010a161] [c0108e60] [c010f26a] [c0100018] [c010f340] [c010faad] [c01103e7] [c0107423] [c010742c] Code: 0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 55 89 e5 83 ec 10 57 56 EIP; c0111634 schedule+388/394 = Trace; c010792d __down+55/9c Trace; c0107a78 __down_failed+8/c Trace; c01e41c5 stext_lock+195/10c2 Trace; c011d4e0 __call_usermodehelper+0/2c Trace; c011d4e0 __call_usermodehelper+0/2c Trace; c01a574d net_run_sbin_hotplug+79/8c Trace; c0181f66 set_cursor+6e/88 Trace; c01853b1 vt_console_print+2c1/2d8 Trace; c01a55bd unregister_netdevice+b5/1cc Trace; c018ca48 unregister_netdev+10/28 Trace; c48cd52e [spectrum24t_cs]adapter_release+c6/188 Trace; c48d31c4 [spectrum24t_cs]__FUNC__.1131+10/60 Trace; c48cd468 [spectrum24t_cs]adapter_release+0/188 Trace; c01199bd update_process_times+1d/8c Trace; c0119897 update_wall_time+b/3c Trace; c0119ca2 timer_bh+23e/27c Trace; c010ccd6 timer_interrupt+62/110 Trace; c0117123 bh_action+1b/5c Trace; c0117058 tasklet_hi_action+3c/60 Trace; c0116f60 do_softirq+40/64 Trace; c010a161 do_IRQ+a1/b0 Trace; c0108e60 ret_from_intr+0/20 Trace; c010f26a apm_bios_call_simple+4e/58 Trace; c0100018 startup_32+18/139 Trace; c010f340 apm_do_idle+14/30 Trace; c010faad apm_mainloop+8d/f4 Trace; c01103e7 apm+27b/294 Trace; c0107423 kernel_thread+1f/38 Trace; c010742c kernel_thread+28/38 Code; c0111634 schedule+388/394 _EIP: Code; c0111634 schedule+388/394 = 0: 0f 0b ud2a = Code; c0111636 schedule+38a/394 2: 8d 65 dc lea0xffdc(%ebp),%esp Code; c0111639 schedule+38d/394 5: 5bpop%ebx Code; c011163a schedule+38e/394 6: 5epop%esi Code; c011163b schedule+38f/394 7: 5fpop%edi Code; c011163c schedule+390/394 8: 89 ec mov%ebp,%esp Code; c011163e schedule+392/394 a: 5dpop%ebp Code; c011163f schedule+393/394 b: c3ret Code; c0111640 __wake_up+0/98 c: 55push %ebp Code; c0111641 __wake_up+1/98 d: 89 e5 mov%esp,%ebp Code; c0111643 __wake_up+3/98 f: 83 ec 10 sub$0x10,%esp Code; c0111646 __wake_up+6/98 12: 57push %edi Code; c0111647 __wake_up+7/98 13: 56push %esi Kernel panic: Aiee, killing interrupt handler! Dax Kelson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
2.4.1 FireWire compile problem
# IEEE 1394 (FireWire) support CONFIG_IEEE1394=y # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_RAWIO=y # CONFIG_IEEE1394_VERBOSEDEBUG is not set gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o ohci1394.o ohci1394.c ohci1394.c:152: warning: `ohci1394_pci_tbl' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o video1394.o video1394.c video1394.c:1229: warning: `video1394_fops' defined but not used video1394.c:1239: warning: `video1394_init' defined but not used video1394.c:1277: warning: `remove_card' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o raw1394.o raw1394.c rm -f ieee1394drv.o ld -m elf_i386 -r -o ieee1394drv.o ieee1394.o ohci1394.o video1394.o raw1394.o video1394.o(.data+0x0): multiple definition of `ohci_csr_rom' ohci1394.o(.data+0x0): first defined here make[3]: *** [ieee1394drv.o] Error 1 make[3]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[1]: *** [_subdir_ieee1394] Error 2 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [_dir_drivers] Error 2 [root@thud 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: 2.4.1 FireWire compile problem
Dax Kelson said once upon a time (Wed, 31 Jan 2001): > > # IEEE 1394 (FireWire) support > CONFIG_IEEE1394=y > # CONFIG_IEEE1394_PCILYNX is not set > CONFIG_IEEE1394_OHCI1394=y > CONFIG_IEEE1394_VIDEO1394=y > CONFIG_IEEE1394_RAWIO=y > # CONFIG_IEEE1394_VERBOSEDEBUG is not set I noticed when I compile everything modular, there are no problems. Dax - 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.1 FireWire compile problem
# IEEE 1394 (FireWire) support CONFIG_IEEE1394=y # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_RAWIO=y # CONFIG_IEEE1394_VERBOSEDEBUG is not set gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o ohci1394.o ohci1394.c ohci1394.c:152: warning: `ohci1394_pci_tbl' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o video1394.o video1394.c video1394.c:1229: warning: `video1394_fops' defined but not used video1394.c:1239: warning: `video1394_init' defined but not used video1394.c:1277: warning: `remove_card' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o raw1394.o raw1394.c rm -f ieee1394drv.o ld -m elf_i386 -r -o ieee1394drv.o ieee1394.o ohci1394.o video1394.o raw1394.o video1394.o(.data+0x0): multiple definition of `ohci_csr_rom' ohci1394.o(.data+0x0): first defined here make[3]: *** [ieee1394drv.o] Error 1 make[3]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[1]: *** [_subdir_ieee1394] Error 2 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [_dir_drivers] Error 2 [root@thud 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: 2.4.1 FireWire compile problem
Dax Kelson said once upon a time (Wed, 31 Jan 2001): # IEEE 1394 (FireWire) support CONFIG_IEEE1394=y # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_RAWIO=y # CONFIG_IEEE1394_VERBOSEDEBUG is not set I noticed when I compile everything modular, there are no problems. Dax - 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/
Multiplexing mouse input
My laptop has a touchpad builtin with two buttons, I also have an external PS2 and/or USB mouse (3 buttons with scroll wheel). I would like to be able to use the touchpad, and then plug in the mouse (with either PS2 or USB connector) and use it without reconfiguring anything. In fact, it would be cool if I could use both at the same time. Is this possible with the new "Input Drivers" in the 2.4 kernel? Is it possible with Linux at all? As a comparison, at least two other OSes, Windows 2000 and NetBSD 1.5 multiplex mouse input and allow use of two (or more!) mice at the same time. Dax Kelson NetBSD "wscons console driver" info: http://www.netbsd.org/Documentation/wscons/ - 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/
Multiplexing mouse input
My laptop has a touchpad builtin with two buttons, I also have an external PS2 and/or USB mouse (3 buttons with scroll wheel). I would like to be able to use the touchpad, and then plug in the mouse (with either PS2 or USB connector) and use it without reconfiguring anything. In fact, it would be cool if I could use both at the same time. Is this possible with the new "Input Drivers" in the 2.4 kernel? Is it possible with Linux at all? As a comparison, at least two other OSes, Windows 2000 and NetBSD 1.5 multiplex mouse input and allow use of two (or more!) mice at the same time. Dax Kelson NetBSD "wscons console driver" info: http://www.netbsd.org/Documentation/wscons/ - 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/
ECN connectivity surveys
For test methodology and results go to this website, about 1/3 the way down you'll see the ECN bullet point. http://www.aciri.org/tbit/ Dax Kelson Guru Labs - 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/
ECN fixes for Cisco gear
In Sept of 2000, I did a survey of 30,000 websites and found that 8% of them were unreachable from an ECN capable client. Two major culprits were identified, the Cisco PIX and Local Director. To Cisco's credit, fixes were released quickly. Here is a message I sent with info about the Cisco updates: http://www.uwsg.iu.edu/hypermail/linux/kernel/0010.1/1205.html Here is the fix for PIX: (see http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds23698) Bud ID: CSCds23698 Headline: PIX sends RSET in response to tcp connections with ECN bits set Product: PIX Component: fw Severity: 2 Status: R [Resolved] Version Found: 5.1(1) Fixed-in Version: 5.1(2.206) 5.1(2.207) 5.2(1.200) Here is the fix for Local Director: (see http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds40921) Bug Id : CSCds40921 Headline: LD rejects syn with reserved bits set in flags field of TCP hdr Product: ld Component: rotor Severity: 3 Status: R [Resolved] Version Found: 3.3(3) Fixed-in Version: 3.3.3.107 Dax Kelson Guru Labs - 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/
ECN fixes for Cisco gear
In Sept of 2000, I did a survey of 30,000 websites and found that 8% of them were unreachable from an ECN capable client. Two major culprits were identified, the Cisco PIX and Local Director. To Cisco's credit, fixes were released quickly. Here is a message I sent with info about the Cisco updates: http://www.uwsg.iu.edu/hypermail/linux/kernel/0010.1/1205.html Here is the fix for PIX: (see http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds23698) Bud ID: CSCds23698 Headline: PIX sends RSET in response to tcp connections with ECN bits set Product: PIX Component: fw Severity: 2 Status: R [Resolved] Version Found: 5.1(1) Fixed-in Version: 5.1(2.206) 5.1(2.207) 5.2(1.200) Here is the fix for Local Director: (see http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds40921) Bug Id : CSCds40921 Headline: LD rejects syn with reserved bits set in flags field of TCP hdr Product: ld Component: rotor Severity: 3 Status: R [Resolved] Version Found: 3.3(3) Fixed-in Version: 3.3.3.107 Dax Kelson Guru Labs - 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/
ECN connectivity surveys
For test methodology and results go to this website, about 1/3 the way down you'll see the ECN bullet point. http://www.aciri.org/tbit/ Dax Kelson Guru Labs - 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: hotmail not dealing with ECN
Jamie Lokier said once upon a time (Fri, 26 Jan 2001): > Does ECN provide perceived benefits to the node using it? Why are you even making suggestions when you haven't even read the RFC? It seems that knowing what ECN is would be prerequisite to engaging in discussion about it. Dax - 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: hotmail not dealing with ECN
Jamie Lokier said once upon a time (Fri, 26 Jan 2001): Does ECN provide perceived benefits to the node using it? Why are you even making suggestions when you haven't even read the RFC? It seems that knowing what ECN is would be prerequisite to engaging in discussion about it. Dax - 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: DRI doesn't work on 2.4.0 but does on prerelease-ac5
Alan Olsen said once upon a time (Sat, 6 Jan 2001): > On Sat, 6 Jan 2001, Michael D. Crawford wrote: > > > AGP, VIA support, DRM, and r128 DRM are all compiled in statically rather than > > as modules. > > AGPGART doe *not* work if compiled statically. Compile it as a module. > You will be much happier. (i.e. It might actually work.) I would also > compile DRM and the r128 drivers as modules as well. AGPGART works fine for me compiled in. Dax - 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: DRI doesn't work on 2.4.0 but does on prerelease-ac5
Alan Olsen said once upon a time (Sat, 6 Jan 2001): On Sat, 6 Jan 2001, Michael D. Crawford wrote: AGP, VIA support, DRM, and r128 DRM are all compiled in statically rather than as modules. AGPGART doe *not* work if compiled statically. Compile it as a module. You will be much happier. (i.e. It might actually work.) I would also compile DRM and the r128 drivers as modules as well. AGPGART works fine for me compiled in. Dax - 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/
IEEE1394 2.4.0 (final) compile problems
# IEEE 1394 (FireWire) support # CONFIG_IEEE1394=y # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_RAWIO=y # CONFIG_IEEE1394_VERBOSEDEBUG is not set 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-DEXPORT_SYMTAB -c ieee1394_syms.c ld -m elf_i386 -r -o ieee1394.o ieee1394_core.o ieee1394_transactions.o hosts.o highlevel.o csr.o guid.o ieee1394_syms.o 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-c -o ohci1394.o ohci1394.c ohci1394.c:152: warning: `ohci1394_pci_tbl' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o video1394.o video1394.c video1394.c:1229: warning: `video1394_fops' defined but not used video1394.c:1239: warning: `video1394_init' defined but not used video1394.c:1277: warning: `remove_card' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o raw1394.o raw1394.c rm -f ieee1394drv.o ld -m elf_i386 -r -o ieee1394drv.o ieee1394.o ohci1394.o video1394.o raw1394.o video1394.o(.data+0x0): multiple definition of `ohci_csr_rom' ohci1394.o(.data+0x0): first defined here make[3]: *** [ieee1394drv.o] Error 1 make[3]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[1]: *** [_subdir_ieee1394] Error 2 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [_dir_drivers] Error 2 [root@thud 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/
IEEE1394 2.4.0 (final) compile problems
# IEEE 1394 (FireWire) support # CONFIG_IEEE1394=y # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_RAWIO=y # CONFIG_IEEE1394_VERBOSEDEBUG is not set 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-DEXPORT_SYMTAB -c ieee1394_syms.c ld -m elf_i386 -r -o ieee1394.o ieee1394_core.o ieee1394_transactions.o hosts.o highlevel.o csr.o guid.o ieee1394_syms.o 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-c -o ohci1394.o ohci1394.c ohci1394.c:152: warning: `ohci1394_pci_tbl' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o video1394.o video1394.c video1394.c:1229: warning: `video1394_fops' defined but not used video1394.c:1239: warning: `video1394_init' defined but not used video1394.c:1277: warning: `remove_card' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o raw1394.o raw1394.c rm -f ieee1394drv.o ld -m elf_i386 -r -o ieee1394drv.o ieee1394.o ohci1394.o video1394.o raw1394.o video1394.o(.data+0x0): multiple definition of `ohci_csr_rom' ohci1394.o(.data+0x0): first defined here make[3]: *** [ieee1394drv.o] Error 1 make[3]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[1]: *** [_subdir_ieee1394] Error 2 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [_dir_drivers] Error 2 [root@thud 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/
2.4.0-prerelease IEEE1394 problem
I haven't been able to compile IEEE1394 into the kernel since test12. I get the error: ld: cannot open drivers/ieee1394/ieee1394.a: No such file or directory make: *** [vmlinux] Error 1 [root@thud linux]# When I compile it completely modular, it works fine. This works: # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=m CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_RAWIO=m # CONFIG_IEEE1394_VERBOSEDEBUG is not set This doesn't: # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=y # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_RAWIO=m # CONFIG_IEEE1394_VERBOSEDEBUG is not set Dax - 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-prerelease IEEE1394 problem
I haven't been able to compile IEEE1394 into the kernel since test12. I get the error: ld: cannot open drivers/ieee1394/ieee1394.a: No such file or directory make: *** [vmlinux] Error 1 [root@thud linux]# When I compile it completely modular, it works fine. This works: # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=m CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_RAWIO=m # CONFIG_IEEE1394_VERBOSEDEBUG is not set This doesn't: # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=y # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_RAWIO=m # CONFIG_IEEE1394_VERBOSEDEBUG is not set Dax - 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: iptables: "stateful inspection?"
Michael Rothwell said once upon a time (Wed, 20 Dec 2000): > Alan Cox wrote: > > > It does SYN checking. If you are running 'serious' security you wouldnt be > > allowing outgoing connections anyway. One windows christmascard.exe virus that > > connects back to an irc server to take input and you are hosed. > > Thankfully, pine and mutt are, to date, immune to that kind of thing. :) Try again. Pine less than 4.30 has a buffer overflow builtin. A properly formated "From" header (or something) can hose you. No need for any attachment. Dax - 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: iptables: stateful inspection?
Michael Rothwell said once upon a time (Wed, 20 Dec 2000): Alan Cox wrote: It does SYN checking. If you are running 'serious' security you wouldnt be allowing outgoing connections anyway. One windows christmascard.exe virus that connects back to an irc server to take input and you are hosed. Thankfully, pine and mutt are, to date, immune to that kind of thing. :) Try again. Pine less than 4.30 has a buffer overflow builtin. A properly formated "From" header (or something) can hose you. No need for any attachment. Dax - 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/
test13pre2 - ieee1394 compile failure
Linus Torvalds said once upon a time (Sat, 16 Dec 2000): > Can anybody else find build irregularities with the new Makefiles? Please > holler.. I've been having problems building Firewire support since test12-pre3, I'm still having problems with test13-pre2 (although different problems). You can read about my test12-pre3+ problems here: http://lists.insecure.org/linux-kernel/2000/Dec/0186.html My current test13-pre2 problems: ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/ieee1394/ieee1394.a drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/usb/usbdrv.o drivers/input/inputdrv.o drivers/i2c/i2c.o \ net/network.o \ /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a \ --end-group \ -o vmlinux ld: cannot open drivers/ieee1394/ieee1394.a: No such file or directory >From my .config: # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=y # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_RAWIO=m # CONFIG_IEEE1394_VERBOSEDEBUG is not set Dax Kelson - 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/
test13pre2 - ieee1394 compile failure
Linus Torvalds said once upon a time (Sat, 16 Dec 2000): Can anybody else find build irregularities with the new Makefiles? Please holler.. I've been having problems building Firewire support since test12-pre3, I'm still having problems with test13-pre2 (although different problems). You can read about my test12-pre3+ problems here: http://lists.insecure.org/linux-kernel/2000/Dec/0186.html My current test13-pre2 problems: ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/ieee1394/ieee1394.a drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/usb/usbdrv.o drivers/input/inputdrv.o drivers/i2c/i2c.o \ net/network.o \ /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a \ --end-group \ -o vmlinux ld: cannot open drivers/ieee1394/ieee1394.a: No such file or directory From my .config: # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=y # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_RAWIO=m # CONFIG_IEEE1394_VERBOSEDEBUG is not set Dax Kelson - 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.4 routing problem
Dries van Oosten said once upon a time (Fri, 1 Dec 2000): > Can someone point me to how routing is done in the 2.4 kernel? > My net-tools don't work anymore (specifically route fails to produce the > routing table). I look around a bit in the kernel sources and notice > things have changed. What kind of options are there now to influence the > routing table? My net-tools v1.56 that comes with Red Hat 7 works fine. If you want to take full advantage of all the networking features, you need to use iproute2. ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.2.4-now-ss??????.tar.gz Dax Kelson Guru Labs - 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.4 routing problem
Dries van Oosten said once upon a time (Fri, 1 Dec 2000): Can someone point me to how routing is done in the 2.4 kernel? My net-tools don't work anymore (specifically route fails to produce the routing table). I look around a bit in the kernel sources and notice things have changed. What kind of options are there now to influence the routing table? My net-tools v1.56 that comes with Red Hat 7 works fine. If you want to take full advantage of all the networking features, you need to use iproute2. ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.2.4-now-ss??.tar.gz Dax Kelson Guru Labs - 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)
Frank Davis said once upon a time (Fri, 1 Dec 2000): > Dax, >What is your modutils version? Is this the first test12 that has > caused this error? > Regards, Frank [root@thud security]# depmod --version depmod version 2.3.21 I was running 2.4.0-test11-pre3 before I upgraded to test12-pre3. I haven't had problems before test12-pre3. Dax - 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)
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
#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=y
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=y
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_RAWIO=m
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
make bzImage; make modules; make modules_install
modules_install bombs out with:
cd /lib/modules/2.4.0-test12; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.0-test12; fi
depmod: *** Unresolved symbols in
/lib/modules/2.4.0-test12/kernel/drivers/ieee1394/raw1394.o
depmod: free_tlabel
depmod: fill_iso_packet
depmod: hpsb_register_highlevel
depmod: highlevel_lock
depmod: hpsb_unregister_highlevel
depmod: hpsb_send_packet
depmod: highlevel_read
depmod: hpsb_make_lockpacket
depmod: alloc_hpsb_packet
depmod: highlevel_write
depmod: hpsb_dec_host_usage
depmod: hpsb_reset_bus
depmod: hpsb_generation
depmod: hpsb_unlisten_channel
depmod: hpsb_make_readbpacket
depmod: hpsb_listen_channel
depmod: free_hpsb_packet
depmod: hpsb_make_readqpacket
depmod: hpsb_make_writebpacket
depmod: hpsb_inc_host_usage
depmod: hpsb_make_writeqpacket
[root@thud linux]#
Dax Kelson
Guru Labs
-
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)
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
#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=y
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=y
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_RAWIO=m
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
make bzImage; make modules; make modules_install
modules_install bombs out with:
cd /lib/modules/2.4.0-test12; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.0-test12; fi
depmod: *** Unresolved symbols in
/lib/modules/2.4.0-test12/kernel/drivers/ieee1394/raw1394.o
depmod: free_tlabel
depmod: fill_iso_packet
depmod: hpsb_register_highlevel
depmod: highlevel_lock
depmod: hpsb_unregister_highlevel
depmod: hpsb_send_packet
depmod: highlevel_read
depmod: hpsb_make_lockpacket
depmod: alloc_hpsb_packet
depmod: highlevel_write
depmod: hpsb_dec_host_usage
depmod: hpsb_reset_bus
depmod: hpsb_generation
depmod: hpsb_unlisten_channel
depmod: hpsb_make_readbpacket
depmod: hpsb_listen_channel
depmod: free_hpsb_packet
depmod: hpsb_make_readqpacket
depmod: hpsb_make_writebpacket
depmod: hpsb_inc_host_usage
depmod: hpsb_make_writeqpacket
[root@thud linux]#
Dax Kelson
Guru Labs
-
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)
Frank Davis said once upon a time (Fri, 1 Dec 2000): Dax, What is your modutils version? Is this the first test12 that has caused this error? Regards, Frank [root@thud security]# depmod --version depmod version 2.3.21 I was running 2.4.0-test11-pre3 before I upgraded to test12-pre3. I haven't had problems before test12-pre3. Dax - 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: APM oops with Dell 5000e laptop
Alan Cox said once upon a time (Thu, 16 Nov 2000): > > I just got a Sceptre 6950 (also known as a Dell 5000e), I just installed > > Red Hat 7.0 on it, and got an APM related oops at boot. > > Yep. This is not a Linux problem The kernel works around/ignores/disables other broken hardware or broken features of otherwise working hardware with black lists. There will be many *many* of these laptops sold. Is there a way to uniquely identify the affected BIOSes at boot time and turn off APM? According to Brad Douglas, the 32-bit Get Power Status (0AH) call is broken. Supposedly there will be a BIOS update in the "future" to correct this problem. Dax - 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: APM oops with Dell 5000e laptop
Alan Cox said once upon a time (Thu, 16 Nov 2000): I just got a Sceptre 6950 (also known as a Dell 5000e), I just installed Red Hat 7.0 on it, and got an APM related oops at boot. Yep. This is not a Linux problem The kernel works around/ignores/disables other broken hardware or broken features of otherwise working hardware with black lists. There will be many *many* of these laptops sold. Is there a way to uniquely identify the affected BIOSes at boot time and turn off APM? According to Brad Douglas, the 32-bit Get Power Status (0AH) call is broken. Supposedly there will be a BIOS update in the "future" to correct this problem. Dax - 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/
APM oops with Dell 5000e laptop
I just got a Sceptre 6950 (also known as a Dell 5000e), I just installed
Red Hat 7.0 on it, and got an APM related oops at boot.
I found that this was reported on l-k in late September with a couple
responses, but no resolution.
Here are a couple detailed bug reports on this same problem, again with no
response.
http://linuxcare.com.au/cgi-bin/apm/incoming?id=90
http://linuxcare.com.au/cgi-bin/apm/incoming?id=91
Here is what got in /var/log/messages, I'm willing to try suggested fixes,
etc. The problem also happens with the 2.4 test kernels.
general protection fault: ea3c
CPU:0
EIP:0050:[<3319>]
EFLAGS: 00010046
eax: ebx: 0001 ecx: edx:
esi: 00ff edi: 0014 ebp: c78b1ea4 esp: c78b1ea4
ds: 0058 es: ss: 0018
Process apmd (pid: 342, process nr: 10, stackpage=c78b1000)
Stack: 0058 00ff 1eb80050 0001 530a 0016 00485c5f
c78b1f28 c01078f2 0010 c78b1f28 c64e0018 0018 c01d8b51
00ff 0286 c64e c0107ae6 530a
Call Trace: [apm_bios_call+58/120] [error_table+1009/9344]
[apm_get_power_status+42/100] [apm_get_info+58/248] [proc_file_read+154/468]
[sys_read+174/196] [system_call+52/56]
Code: <1>Unable to handle kernel paging request at virtual address 3319
current->tss.cr3 = 05fe, %%cr3 = 05fe
*pde =
Oops:
CPU:0
EIP:0010:[show_registers+653/704]
EFLAGS: 00010046
eax: ebx: ecx: 3319 edx: c76ca000
esi: 002b edi: c78b2000 ebp: c800 esp: c78b1df4
ds: 0018 es: 0018 ss: 0018
Process apmd (pid: 342, process nr: 10, stackpage=c78b1000)
Stack: 0014 c78b1ea4 c02490c2 00ff 0014 c78b1ea4 0001
3319 00010046 331a c880 c010a470 c78b1e68
c01d91a7 c01d927c ea3c c78b1e68 c010a974 c01d927c c78b1e68 ea3c
Call Trace: [] [die+48/56] [error_table+2631/9344] [error_table+2844/9344]
[do_general_protection+108/116] [error_table+2844/9344] [error_code+45/56]
[apm_bios_call+58/120] [error_table+1009/9344] [apm_get_power_status+42/100]
[apm_get_info+58/248] [proc_file_read+154/468] [sys_read+174/196] [system_call+52/56]
Code: 8a 04 0b 89 44 24 38 50 68 9f 91 1d c0 e8 f5 9b 00 00 83 c4
Dax Kelson
-
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: /net/ip_vs.h in stock kernels
Jeff V. Merkey said once upon a time (Fri, 10 Nov 2000): > > I noticed that the ip_vs.h include is not in the main kernel tree or ip > virtual switch support while I was attempting to buid the pirahnna web > server. Is this module a patch located somewhere else on > ftp.kernel.org. Jeff, Red Hat started included the IPVS patches from http://www.linuxvirtualserver.org/ starting with RH6.1 (I believe). You can find the patch they use in the kernel src.rpm, or go get the patch from the URL listed above. Dax - 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: /net/ip_vs.h in stock kernels
Jeff V. Merkey said once upon a time (Fri, 10 Nov 2000): I noticed that the ip_vs.h include is not in the main kernel tree or ip virtual switch support while I was attempting to buid the pirahnna web server. Is this module a patch located somewhere else on ftp.kernel.org. Jeff, Red Hat started included the IPVS patches from http://www.linuxvirtualserver.org/ starting with RH6.1 (I believe). You can find the patch they use in the kernel src.rpm, or go get the patch from the URL listed above. Dax - 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-scsi works now "used to be On ide-scsi recorder failure
safemode said once upon a time (Sun, 15 Oct 2000): > Everything seems to be working great now... i'm using a patch Andre > Hedrick gave me and everything works like normal again. Thanks again for > everyone's help. Back to burning cds. The error you were getting is the error I get on my system when I incorrectly try to access the SCSI cdrom device instead of of the SCSI generic. See: [root@thud linux]# cdrecord dev=/dev/sr1 -inq Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jrg Schilling scsidev: '/dev/sr1' devname: '/dev/sr1' scsibus: -2 target: -2 lun: -2 cdrecord: No such file or directory. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. [root@thud linux]# However, when I correctly reference the SCSI generic device, it works: [root@thud linux]# cdrecord dev=/dev/sg1 -inq Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jrg Schilling scsidev: '/dev/sg1' devname: '/dev/sg1' scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.1.17 Using libscg version 'schily-0.1' Device type: Removable CD-ROM Version: 2 Response Format: 2 Capabilities : SYNC Vendor_info: 'YAMAHA ' Identifikation : 'CRW4416S' Revision : '1.0j' Device seems to be: Generic mmc CD-RW. [root@thud linux]# In short, I don't think there was a problem, simply incorrect usage of cdrecord. Dax - 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: On ide-scsi recorder failure
safemode said once upon a time (Sun, 15 Oct 2000): > Alright, first off let me say that this cdrecord was working fine with > 2.4.0-test8. The recorder is on /dev/scd0 and also on /dev/sr0. maybe > this has something to do with it? i'm not sure, but cdrecord keeps saying Make sure you have SCSI generic support compiled into your kernel, or as a module (sg). You don't burn through the /dev/(sr0|scd0) devices. You burn through the scsi generic device /dev/sg0. After you verify this, run cdrecord -scanbus. Dax - 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: On ide-scsi recorder failure
safemode said once upon a time (Sun, 15 Oct 2000): Alright, first off let me say that this cdrecord was working fine with 2.4.0-test8. The recorder is on /dev/scd0 and also on /dev/sr0. maybe this has something to do with it? i'm not sure, but cdrecord keeps saying Make sure you have SCSI generic support compiled into your kernel, or as a module (sg). You don't burn through the /dev/(sr0|scd0) devices. You burn through the scsi generic device /dev/sg0. After you verify this, run cdrecord -scanbus. Dax - 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-scsi works now used to be On ide-scsi recorder failure
safemode said once upon a time (Sun, 15 Oct 2000): Everything seems to be working great now... i'm using a patch Andre Hedrick gave me and everything works like normal again. Thanks again for everyone's help. Back to burning cds. The error you were getting is the error I get on my system when I incorrectly try to access the SCSI cdrom device instead of of the SCSI generic. See: [root@thud linux]# cdrecord dev=/dev/sr1 -inq Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jrg Schilling scsidev: '/dev/sr1' devname: '/dev/sr1' scsibus: -2 target: -2 lun: -2 cdrecord: No such file or directory. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. [root@thud linux]# However, when I correctly reference the SCSI generic device, it works: [root@thud linux]# cdrecord dev=/dev/sg1 -inq Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jrg Schilling scsidev: '/dev/sg1' devname: '/dev/sg1' scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.1.17 Using libscg version 'schily-0.1' Device type: Removable CD-ROM Version: 2 Response Format: 2 Capabilities : SYNC Vendor_info: 'YAMAHA ' Identifikation : 'CRW4416S' Revision : '1.0j' Device seems to be: Generic mmc CD-RW. [root@thud linux]# In short, I don't think there was a problem, simply incorrect usage of cdrecord. Dax - 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/
ECN fixes for Cisco gear
The two main culprits for ECN breakage are Cisco PIX, and Cisco Local Director. Here is the fix for PIX: (see http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds23698) Bud ID:CSCds23698 Headline: PIX sends RSET in response to tcp connections with ECN bits set Product: PIX Component: fw Severity: 2Status: R [Resolved] Version Found: 5.1(1) Fixed-in Version: 5.1(2.206) 5.1(2.207) 5.2(1.200) Here is the fix for Local Director: (see http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds40921) Bug Id : CSCds40921 Headline: LD rejects syn with reserved bits set in flags field of TCP hdr Product: ld Component: rotor Severity: 3 Status:R [Resolved] Version Found: 3.3(3) Fixed-in Version: 3.3.3.107 Dax - 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/
No SCSI burning problem (was: Bug in "ide-pci.c")
Jeff V. Merkey said once upon a time (Fri, 6 Oct 2000): > > Andre, > > BTW, how did your testing of the speed=4 problem with ide-scsi turn > out. We are still seeing the speed=2 problem on 2.4.0-pre9. I cannot > get the drive to burn clean unless the speed setting is cranked down to > speed=2. > > Jeff I just burned Red Hat 7.0 disk1 iso image at on a SCSI 4x burner without any problems. I have an IDE Plextor 12x burner at work, Monday I'll try a burn under 2.4.0-test9. distro: Red Hat 7.0 kernel: 2.4.0-test9-pre8 Cdrecord 1.9 True SCSI Yamaha 4x burner (scsi0) found at PCI 0/16/0 (scsi0:0:4:0) Synchronous at 8.0 Mbyte/sec, offset 15. Vendor: YAMAHAModel: CRW4416S Rev: 1.0j Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0 Uniform CD-ROM driver Revision: 3.11 sr1: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray [root@localhost burn]# md5sum redhat-7.0-disc1.iso 626b7d18033e320c27c8cd58cc37a288 redhat-7.0-disc1.iso [did a 4x burn] [root@localhost dkelson]# md5sum /dev/scd1 626b7d18033e320c27c8cd58cc37a288 /dev/scd1 - 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/
No SCSI burning problem (was: Bug in ide-pci.c)
Jeff V. Merkey said once upon a time (Fri, 6 Oct 2000): Andre, BTW, how did your testing of the speed=4 problem with ide-scsi turn out. We are still seeing the speed=2 problem on 2.4.0-pre9. I cannot get the drive to burn clean unless the speed setting is cranked down to speed=2. Jeff I just burned Red Hat 7.0 disk1 iso image at on a SCSI 4x burner without any problems. I have an IDE Plextor 12x burner at work, Monday I'll try a burn under 2.4.0-test9. distro: Red Hat 7.0 kernel: 2.4.0-test9-pre8 Cdrecord 1.9 True SCSI Yamaha 4x burner (scsi0) Adaptec AHA-2940UW Pro Ultra SCSI host adapter found at PCI 0/16/0 (scsi0:0:4:0) Synchronous at 8.0 Mbyte/sec, offset 15. Vendor: YAMAHAModel: CRW4416S Rev: 1.0j Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0 Uniform CD-ROM driver Revision: 3.11 sr1: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray [root@localhost burn]# md5sum redhat-7.0-disc1.iso 626b7d18033e320c27c8cd58cc37a288 redhat-7.0-disc1.iso [did a 4x burn] [root@localhost dkelson]# md5sum /dev/scd1 626b7d18033e320c27c8cd58cc37a288 /dev/scd1 - 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/
35k host ECN survey script and results
Many people have asked for the script, my initial list, and the raw results from the current run. I've made them available here: http://www.gurulabs.com/ecn-check.tar.bz2 (367KB) It took 12 hours to check the list. It would pretty easy to automatically email a message to the broken sites. Which firewalls are causing the problem (Cisco PIX, at least, although it is interesting that www.cisco.com is reachable. Are they not running a PIX?)? Have any firewall vendors released patches or fixes? Which firewalls can be manually configured to allow ECN packets? It would be very nice if the email sent included such pointers and information. If you have any information, send it to me and I'll create a draft email. I'll run it by l-k for any comments, and then send it to ECN blocking sites. Dax Kelson Guru Labs - 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/
8% of the Internet unreachable!
Executive Summary: Survey shows 8.3% of websites unreachable from an ECN capable client. Notable unreachable sites: www.amazon.com, www.ibm.com, www.sun.com, www.apple.com, www.intel.com, www.disney.com, www.espn.com, www.zdnet.com, www.ups.com, www.visa.com, abc.com, cbs.com, fox.com, sharkyextreme.com, www.linuxtoday.com, www.linuxstart.com, www.linuxplanet.com, www.linuxnewbie.org, www.linux-usb.org Firewalls are improperly rejecting connections, if they aren't fixed, there will be lots of complaining when the linux 2.4 kernel gets widespread deployment. Long version: The current 2.4 test kernels include support for "ECN" in the IP stack. You can read about it here: http://www.faqs.org/rfcs/rfc2481.html As the Internet grows, ECN is needed to provide better congestion management. Theoretically, a fully ECN enabled Internet would have ZERO packet loss. The "problem" is that ECN uses two previously unused bits in the IP header, and because of that many firewalls improperly drop or reject IP packets from a ECN capable host. There have been various postings to l-k about unreachable sites, I wondered how widespread the problem was. With the help of perl, and friends, I came up with list of 34,579 unique websites. The websites were plucked from the log file of a moderately busy proxy server that has about 10,000 users behind it. The sites in the list are sites that were contacted by the proxy server in the last 5 days. I wrote a perl script to connect to each website with ECN turned off, and if I could connect, then to turn on ECN and try again. The results: >From the 34,579 sites I came up with, 33177 were up. Sites checked: 34,579 Sites responding: 33177 Responding sites rejecting ECN packets: 2741 (8.3% of responding sites) It took 12 hours to run the test. According to NetCraft, there are 19+ million websites. Did I sample enough sites? Mostly likely not, however, the 35k sites I checked probably are the most popular sites on the Internet. Maybe NetCraft should do an ECN check as part of their normal survey. If anyone is interested in the perl script, or the list of sites, let me know. Dax Kelson Guru Labs - 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/
8% of the Internet unreachable!
Executive Summary: Survey shows 8.3% of websites unreachable from an ECN capable client. Notable unreachable sites: www.amazon.com, www.ibm.com, www.sun.com, www.apple.com, www.intel.com, www.disney.com, www.espn.com, www.zdnet.com, www.ups.com, www.visa.com, abc.com, cbs.com, fox.com, sharkyextreme.com, www.linuxtoday.com, www.linuxstart.com, www.linuxplanet.com, www.linuxnewbie.org, www.linux-usb.org Firewalls are improperly rejecting connections, if they aren't fixed, there will be lots of complaining when the linux 2.4 kernel gets widespread deployment. Long version: The current 2.4 test kernels include support for "ECN" in the IP stack. You can read about it here: http://www.faqs.org/rfcs/rfc2481.html As the Internet grows, ECN is needed to provide better congestion management. Theoretically, a fully ECN enabled Internet would have ZERO packet loss. The "problem" is that ECN uses two previously unused bits in the IP header, and because of that many firewalls improperly drop or reject IP packets from a ECN capable host. There have been various postings to l-k about unreachable sites, I wondered how widespread the problem was. With the help of perl, and friends, I came up with list of 34,579 unique websites. The websites were plucked from the log file of a moderately busy proxy server that has about 10,000 users behind it. The sites in the list are sites that were contacted by the proxy server in the last 5 days. I wrote a perl script to connect to each website with ECN turned off, and if I could connect, then to turn on ECN and try again. The results: From the 34,579 sites I came up with, 33177 were up. Sites checked: 34,579 Sites responding: 33177 Responding sites rejecting ECN packets: 2741 (8.3% of responding sites) It took 12 hours to run the test. According to NetCraft, there are 19+ million websites. Did I sample enough sites? Mostly likely not, however, the 35k sites I checked probably are the most popular sites on the Internet. Maybe NetCraft should do an ECN check as part of their normal survey. If anyone is interested in the perl script, or the list of sites, let me know. Dax Kelson Guru Labs - 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/
35k host ECN survey script and results
Many people have asked for the script, my initial list, and the raw results from the current run. I've made them available here: http://www.gurulabs.com/ecn-check.tar.bz2 (367KB) It took 12 hours to check the list. It would pretty easy to automatically email a message to the broken sites. Which firewalls are causing the problem (Cisco PIX, at least, although it is interesting that www.cisco.com is reachable. Are they not running a PIX?)? Have any firewall vendors released patches or fixes? Which firewalls can be manually configured to allow ECN packets? It would be very nice if the email sent included such pointers and information. If you have any information, send it to me and I'll create a draft email. I'll run it by l-k for any comments, and then send it to ECN blocking sites. Dax Kelson Guru Labs - 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.2: /proc/config.gz
Timur Tabi said once upon a time (Thu, 31 Aug 2000): > Of course, the smartest thing would be if the installation routine actually > built the kernel, with all options finely tuned to the hardware. If I'm > installing on a single CPU system, then I don't want the SMP kernel. Red Hat > doesn't understand that. It DOES understand that. The Red Hat installer does the right thing and install a proper kernel. My RH6.2 install CD has the following: kernel-2.2.16-3.i386.rpm kernel-2.2.16-3.i586.rpm kernel-2.2.16-3.i686.rpm kernel-smp-2.2.16-3.i386.rpm kernel-smp-2.2.16-3.i586.rpm kernel-smp-2.2.16-3.i686.rpm Dax - 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: File system
Robert Schweikert said once upon a time (Tue, 29 Aug 2000): > I read in the September issue of Linux Journal that there is a potential > development of an ext3 FS, which would be a journaling file system. This > seems kind of odd to me, as JFS and XFS are both proven file systems, > the code for both is I think GPLed, wouldn't the resources for ext3 not > be better used getting JFS and XFS ported as quickly as possible? > > I'm just curious. It is not potential, it exists, it works (no "meta-data only" or performance tuning yet). Ext3 is simply ext2+journaling. It is very low risk to try it out as you can easily go back to ext2. I dare say that 95% of the Linux boxes out there currently run ext2. Once ext3 releases, it provides an easy in place upgrade of functionality without the trouble of nuking your current filesystem, creating new XYZ filesystem, and restoring your data. I converted a 25GB ext2 filesystem to ext3 and back to ext2 without problems. Dax Kelson Guru Labs - 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/
