* Re: [PATCH] Double x86 initialise fix.
From: Alan Cox @ 2002-10-26 15:46 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Alan Cox, Dave Jones, Linux Kernel Mailing List
In-Reply-To: <3007712682.1035619204@[10.10.2.3]>
On Sat, 2002-10-26 at 16:00, Martin J. Bligh wrote:
> >> Isn't this always the case on x86 ?
> >> /me waits to hear gory details of some IBM monster.
> >
> > It isnt. The boot CPU may be any number. In addition you can strap dual
> > pentium boxes to arbitrate for who is boot cpu (this is used for fault
> > tolerance).
>
> Eh? I don't understand this, and I think Dave is right for all the
> IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU
> numbers are dynamically assigned as we boot, so the boot CPU will
> always get 0, surely?
Ok its a logical ID - so yes
^ permalink raw reply
* Re: Swap doesn't work
From: Alan Cox @ 2002-10-26 15:44 UTC (permalink / raw)
To: Vladimír T Tý; +Cc: Linux Kernel Mailing List
In-Reply-To: <001001c27d02$6297fe50$4500a8c0@cybernet.cz>
On Sat, 2002-10-26 at 16:14, Vladimír Třebický wrote:
> Hi,
>
> I've made my linux-from-scratch with latest stable (2.4.19) kernel, made
> swap, turned it on but it doesn't work. It seems it does but when there's
> not enough memory, the system crashes. Either it kills the application
> desiring more memory (gcc or something) or crashes the kernel with memory
> dump. Neither the 2.4.20-pre5-ac3 helped.
Does this occur if you take a kernel build on a standard distribution
and boot it on your box rather than one generated by a hand built tool
chain ?
^ permalink raw reply
* Swap doesn't work
From: Vladimír Třebický @ 2002-10-26 15:14 UTC (permalink / raw)
To: linux-kernel
Hi,
I've made my linux-from-scratch with latest stable (2.4.19) kernel, made
swap, turned it on but it doesn't work. It seems it does but when there's
not enough memory, the system crashes. Either it kills the application
desiring more memory (gcc or something) or crashes the kernel with memory
dump. Neither the 2.4.20-pre5-ac3 helped.
Thank you for your help,
Vladimir Trebicky
--
Vladimir Trebicky
guru@cimice.yo.cz
^ permalink raw reply
* Re: The return of the return of crunch time (2.5 merge candidate list 1.6)
From: Eric W. Biederman @ 2002-10-26 15:09 UTC (permalink / raw)
To: landley; +Cc: linux-kernel
In-Reply-To: <200210251557.55202.landley@trommello.org>
Rob Landley <landley@trommello.org> writes:
> I'm also looking for other things that can similarly be removed from
> this list and pushed for integration during the next stable series.
> Criteria for this: no API changes, and no impact on people who don't
> actually try to use the thing.
>
> If people familiar with these features can suggest stuff that's
> deferrable, please let me know. I've been trying very hard not to make
> judgement calls on these patches (not my job), but I'm certainly open
> to advice.
> 11) Kexec, luanch new linux kernel from Linux (Eric W. Biederman)
>
> Announcement with links:
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
>
> And this thread is just too brazen not to include:
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/7952.html
sys_kexec introduces no new APIs to the rest of the kernel and is
fairly self contained. Making it non intrusive enough that by that
criterion it may be deferred.
Currently the device driver support is lacking. sys_kexec calls the
reboot notifier call chain, and device_shutdown to shut devices down
cleanly. Due to a bug fix/cleanup that went into of 2.5.44
device_shutdown is neutered, and does nothing.
So far with all of the review sys_kexec has gotten not one bug has
been found in it's core. However actually using it is problematic.
In the 2.5.44 kexec to 2.5.44 case quite a few devices cannot
reinitialize when the new kernel comes up.
The proof of concept of what sys_kexec can do is etherboot.
http://www.etherboot.org. Etherboot contains real hardware drivers often
adapted from the linux kernel drivers. It is quite possible to boot
DOS from etherboot, and I can quite definitely run all of setup.S.
However when I attempt this from sys_kexec in a number of significant
cases I cannot even reliably execute the BIOS calls in setup.S after
the kernel has run. Though most of them can reliably be executed.
So the remaining work with sys_kexec is to track down why it is less
reliable than etherboot. A few cases like being loaded from loadlin
and the BIOS interrupt table has hooks to code that is not longer
running is quite explainable. The rest of the failures need more
investigation.
All of the hardware driver stabilization work for sys_kexec can be
postponed until after the feature freeze. And on that note I plan
on removing the few driver fixes in my current patch and posting a
stripped down version later today.
Having sys_kexec in the kernel makes what I am doing more explainable,
and makes people think a little differently about device_shutdown, and
the reboot notifier call chain. And with sys_kexec in the kernel
people mutating the internal kernel interfaces will be encouraged to
take sys_kexec into account.
My point is that while the sys_kexec patch is not especially intrusive
in and of itself, I am fairly certain usage of it can be stabilized
easier in the kernel than outside of it.
Unless something comes up the plan for today is to incorporate the
very minor changes that have been suggested (Makefile, Config.in,
Config.help type), to split out the driver fixes I currently have
into separate patches, and post just a bare bones sys_kexec patch,
ready for inclusion in 2.5.
After the feature freeze I have on the todo list to look at porting
sys_kexec to the Itanium and Hammer. As well as building debugging
tools, and in general debugging sys_kexec so it is generally useful.
Eric
^ permalink raw reply
* Re: [PATCH] Double x86 initialise fix.
From: Martin J. Bligh @ 2002-10-26 15:03 UTC (permalink / raw)
To: Alan Cox, Dave Jones; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <3007712682.1035619204@[10.10.2.3]>
>>> Isn't this always the case on x86 ?
>>> /me waits to hear gory details of some IBM monster.
>>
>> It isnt. The boot CPU may be any number. In addition you can strap dual
>> pentium boxes to arbitrate for who is boot cpu (this is used for fault
>> tolerance).
>
> Eh? I don't understand this, and I think Dave is right for all the
> IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU
> numbers are dynamically assigned as we boot, so the boot CPU will
> always get 0, surely?
Indeed cscope indicates these are acutally hardcoded into the calls:
1 smpboot.c smp_callin 418 smp_store_cpu_info(cpuid);
2 smpboot.c smp_boot_cpus 989 smp_store_cpu_info(0);
The only thing that does smp_callin is a secondary ... so the boot
CPU has this hardcoded to 0 ... I think Dave's fine.
M.
^ permalink raw reply
* Re: [PATCH] Double x86 initialise fix.
From: Martin J. Bligh @ 2002-10-26 15:00 UTC (permalink / raw)
To: Alan Cox, Dave Jones; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <200210261357.g9QDvgl13774@devserv.devel.redhat.com>
>> Isn't this always the case on x86 ?
>> /me waits to hear gory details of some IBM monster.
>
> It isnt. The boot CPU may be any number. In addition you can strap dual
> pentium boxes to arbitrate for who is boot cpu (this is used for fault
> tolerance).
Eh? I don't understand this, and I think Dave is right for all the
IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU
numbers are dynamically assigned as we boot, so the boot CPU will
always get 0, surely?
M.
^ permalink raw reply
* Re: Wide negotiation fails with 80->68 LVD adapter?
From: Alexy Khrabrov @ 2002-10-26 14:53 UTC (permalink / raw)
To: Alexy Khrabrov; +Cc: linux-scsi
In-Reply-To: <20021022221958.GA17112@angle.setup.org>
OK, I've got the CSC (Corpsys) "sca2lvd" adapters and tried them
with my Barracuda ST150176LC's. The adapters look much more solid
than the anonymous Taiwan-made "v1.1" ones. The CSC adapters have
two ig red LEDs onboard, the inner part of the circuit board
has a cover, etc.
However, they too failed to spin my drives at 160, only at 80.
I went back and enabled Wide Negotiation, then trying
to set speed at 160 caused Adaptec 7899 to recognize
the drives as ASYN, hangup, decreasing it to 80 led to their
recognition as 80 and working fine.
I went back and tried the "v1.1" adapters in that setting,
Wide Negotiation enabled, 80 sync speed, and they worked
at the same speed (as measured by copying a 5 GB from
the 160 drive). Doh.
So I reread the drive manual, which says that
Barracuda 50 drives support ANSI SCSI, SCSI-2 and SCSI-3
(Fast-20 and Fast-40), which it says are the same
as Ultra-1 and Ultra-2 for Fast-20/40, respectively.
Mysteriously, Ultra2 is referred to as Ultra80 elsewhere,
so looks like Fast-40 _is_ 80? If SCSI veterans could
clarify this, I'd see how 40=80... Especially, given
aic7xxx says something about 80 (40 MHz) in parentheses...
In all cases, seems that it's really the drive, Barracuda 50
family is Ultra2 <=> Ultra80 (right?) but I was able to
enable Wide Negotiation and set speed to 80, and aic7xxx v6.2.8
showed them registered at 80. I'm just curious if I still could
kinda spin them up to 160 anyways... :-)
Hence, so far, both SCA<->68 LVD adapters worked as advertised.
I'm going to get a real 160 SCA drive and test it further.
In the same vein, if I do end up getting an Ultra 320 card,
and I will get an Adaptec one, what should I look for in the
drive to see if it's capable of supporting 320? I'm interested
in Ultra160 drives, usually SCA ones I can get at closeouts,
but I heard (in the Ultra320 thread) that they can spin at 320
in case they support "HBA" -- can someone please elaborate?
Many thanks, I'll put together a SCA<->68 mini-HOWTO based
on this.
--
Cheers,
Alexy Khrabrov :: www.setup.org :: Age Quod Agis
^ permalink raw reply
* Re: New changes
From: Alan Cox @ 2002-10-26 14:49 UTC (permalink / raw)
To: Harry Kalogirou; +Cc: Linux-8086
In-Reply-To: <1035641027.5491.23.camel@cool>
On Sat, 2002-10-26 at 15:03, Harry Kalogirou wrote:
>
> Hi all,
> after a long time there are some new changes in the CVS! Any happy beta
> testers out there?
Oh for a time machine
^ permalink raw reply
* Re: "mount" bug
From: Harry Kalogirou @ 2002-10-26 14:49 UTC (permalink / raw)
To: jb1; +Cc: Linux-8086
In-Reply-To: <Pine.LNX.4.33.0210260124250.31977-100000@olympus.btstream.com>
> This was my fault; since the machine was happily using both floppy drives
> under Windows 95 I didn't bother to run the BIOS Setup program. While
> checking the "impossible" I discovered that it was set up for only for a
> 1.2M first drive. After correcting this to 1.44M first drive and 1.2M
> second drive, it worked.
>
> This leads to an interesting question: is the fact the floppy mounted, but
> was otherwise inaccessible a bug or a feature? If ELKS should be handling
> all possible low-level functions then it's a bug in the mount() function
> (presumably in the kernel). If mount invokes the ROM BIOS to reduce the
> size of the kernel then it's a feature, and perhaps it could be reduced
> further by using the ROM BIOS for more of the diskette-handling (which
> might have made the diskette accessible despite my incorrect settings).
All floppy access goes through the BIOS. There is a direct floppy
version of the code in the kernel source tree but probably needs a lot
of work. Also the size of the code might be a problem. On the other hand
if we make it work, floppy access wont pause the whole system any more.
> I now think the "Cannot fork", reduced free memory and deteriorating
> system are *not* diagnostic of an incorrect BIOS setup, but rather a
> hardware incompatibility and maybe an ELKS bug revealed by the
> incompatibility. The system on which this occurred has a VL-Bus/EISA
> motherboard and a "bootable" EISA SCSI card. I noticed that when I
> repeated "ps" its process ID jumped by large amounts, and the problems
> occurred when the process ID was displayed as a negative number, after
> which the init process disappeared entirely; I also saw two "init" entries
> once. I suspect the hardware is somehow spawning, then killing new init
> processes frequently, and that when the process ID is negative (or maybe
> when it rolls over to positive again) killing the second init also kills
> the first. "Cannot fork" seems to appear when there's no active init
> process. I'll investigate further, but these should have their own threads
> in the mailing list.
"Cannot fork" is emmited by the shell, when the fork() system call
fails. The system call will fail :
1) If there are no more process slots available.
2) There is not enough free memory.
What exacly happend there, I realy can't tell. The only thing I can tell
is that something "very" bad happed there. I personaly havedn't seen
ELKS behave like that before.
Harry
^ permalink raw reply
* IDESCSI emulation with 2.4.20-pre10aa1
From: Maintaniner on duty @ 2002-10-26 14:56 UTC (permalink / raw)
To: linux-kernel
I do not think this problem has anything to do with -aa1 patch.
Anyway, I tried to make a CDROM of an .iso file using a command
like
cdrecord -v dev=0,0 boot.iso
It correctly identified the cdrom in /dev/sr0
and strarted to write on the blank cd.
Well.. almost at the end of it, "data write error" appeared with
no reason. The file size of the file "boot.iso" is just about 13M.
I then looked into the made cd, I could mount it. Inside, everything
looked normal.
HOwever, when I tried to boot my machine with this CDROM, it showed
top of the familiar page. But in the middle, it cannot finish
showing the whole page of SuSE-8.1 boot.iso page.
I suspect that in this particular kernel version, the idescsi emulation is
not bug-free, because I remember that there was a lot of communication
going on in kernel mailing list on this very topic.
Can someone point me a working kernel version for idescsi?
Thanks.
HUgh
^ permalink raw reply
* Re: 2.5.44-ac3 - don't compile.
From: Andrey Nekrasov @ 2002-10-26 14:45 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <002f01c27c57$a3e8fef0$0b00a8c0@runner>
Hello Rune,
Thank.
Once you wrote about "Re: 2.5.44-ac3 - don't compile.":
> From: "Mikael Pettersson"
> Sent: Wednesday, October 23, 2002 1:43 PM
> Subject: Re: [PATCH 2.5.44] compile error whit LOCAL_APIC disabled...
>
>
> >
> > Known bug in scripts/Configure when switching from an APIC-enabled to
> > an APIC-disabled config. `make oldconfig' fixes it.
>
>
> or just comment out in your ".config":
> CONFIG_X86_EXTRA_IRQS
> CONFIG_X86_FIND_SMP_CONFIG
> CONFIG_X86_MPPARSE
>
> Rune Petersen
> ----- Original Message -----
> From: "Martin J. Bligh" <mbligh@aracnet.com>
> To: "Andrey Nekrasov" <andy@spylog.ru>; <linux-kernel@vger.kernel.org>
> Sent: Friday, October 25, 2002 6:06 PM
> Subject: Re: 2.5.44-ac3 - don't compile.
>
>
> > Odd. I'm sure akpm fixed this in 44, unless -ac3 reverts it.
> > Can you search back for posts by Andrew Morton, and find the
> > fix, and try it?
> >
> > M.
> >
> > --On Friday, October 25, 2002 5:13 PM +0400 Andrey Nekrasov
> <andy@spylog.ru> wrote:
> >
> > > Hello.
> > >
> > >
> > > x86, no SMP.
> > >
> > >
> > > ...
> > > make -f init/Makefile
> > > Generating init/../include/linux/compile.h (updated)
> > >
>
>
> gcc -Wp,-MD,init/.version.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototyp
> es
> > > -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe
> > > -mpreferred-stack-boundary=2 -march=i686 -Iarch/i386/mach-generic
> > > -fomit-frame-pointer -nostdinc -iwithprefix
> lude -DKBUILD_BASENAME=version
> > > -c -o init/version.o init/version.c
> > > ld -m elf_i386 -r -o init/built-in.o init/main.o init/version.o
> > > init/do_mounts.o
> > > ld -m elf_i386 -e stext -T arch/i386/vmlinux.lds.s
> arch/i386/kernel/head.o
> > > arch/i386/kernel/init_task.o init/built-in.o --start-group
> > > arch/i386/kernel/built-in.o arch/i386/mm/built-in.o
> > > arch/i386/mach-generic/built-in.o kernel/built-in.o mm/built-in.o
> fs/built-in.o
> > > ipc/built-in.o security/built-in.o lib/lib.a arch/i386/lib/lib.a
> > > drivers/built-in.o sound/built-in.o arch/i386/pci/built-in.o
> net/built-in.o
> > > --end-group -o vmlinux
> > > arch/i386/kernel/built-in.o: In function `MP_processor_info':
> > > arch/i386/kernel/built-in.o(.init.text+0x46a3): undefined reference to
> `Dprintk'
> > > arch/i386/kernel/built-in.o(.init.text+0x46b6): undefined reference to
> `Dprintk'
> > > arch/i386/kernel/built-in.o(.init.text+0x46c9): undefined reference to
> `Dprintk'
> > > arch/i386/kernel/built-in.o(.init.text+0x46dc): undefined reference to
> `Dprintk'
> > > arch/i386/kernel/built-in.o(.init.text+0x46ef): undefined reference to
> `Dprintk'
> > > arch/i386/kernel/built-in.o(.init.text+0x4702): more undefined
> references to
> > > `Dprintk' follow
> > > make: *** [vmlinux] Error 1
> > > ...
> > >
> > > Why?
> > >
> > >
> > >
> > > --
> > > bye.
> > > Andrey Nekrasov, SpyLOG.
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
> > >
> > >
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
bye.
Andrey Nekrasov, SpyLOG.
^ permalink raw reply
* RE: ASUS TUSL2-C and Promise Ultra100 TX2
From: Robbert Kouprie @ 2002-10-26 14:38 UTC (permalink / raw)
To: 'Cajoline'; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0210260632370.13879-100000@andaxin.gau.hu>
> This board should be rather similar to mine, with the main difference
> being suport for Coppermine/Tualatin processors.
> also use the PIIX4 onboard IDE chipset?
>From the Asus website, the motherboards are very similar, both have the
Intel 815 north bridge, and both have the ICH2 (Intel 82801BA Enhanced
I/O Controller Hub 2) IDE controller onboard. This chip is handled by
the piix.c driver.
> Indeed, that could be a workaround, but I'm afraid it's not that good
> after all, because not all the drives have the same capabilities, it's
> still slower than udma 5 (UDMA100) and from my tests, with such a
> forced setting, the performance is still poor even for this udma mode.
Note that "ata66" actually means UDMA66 and up (it actually means that
you use 80-conductor cables), so with this parameter your drive _will_
run at UDMA 100 if that's supported by the drive and controller. I have
several boxes which need this parameter with the Linus kernel tree, and
they all have disks running at UDMA100 with this boot parameter. Also,
my tests show good speeds on these drives.
> This is interesting. Excuse my ignorance, but do you know what has
> actually changed exactly regarding PDC20268 and PDC20269?
LBA48 support (for disks > 127Gb) I think was added.
> > > What's even funnier is that if I try to copy files from a
> > > filesystem on
> > > a
> > >
> > > drive attached to a PDC20268 and a drive attached to the
> motherboard
> > > controller (PIIX4 chipset), the system eventually locks up
> > > (after about
> > > 3
> > > GB).
This night, I experienced another hang on my box. Even magic sysreq
doesn't do anything anymore. Do you have a reproducible testcase to
trigger this?
> OK fine, I agree, but how do you explain this only happens
> when running on
> this motherboard?
Maybe we should start blaming the onboard ICH2 controller, or the piix.c
driver in this case, because that's the only common thing in our faulty
setups. I also noticed that the ICH2 on the Asus TUSL2-C and CUSL2-C
boards have its own PCI device id in the pci.ids file. So this could
mean they have something different than regular ICH2 chips. I'll include
my full lspci -vvvx for anyone who is interested.
> Indeed. The same controllers work just fine on a P3 600 + QDI
> Advance 10F
> motherboard (with onboard VIA vt82c686a IDE UDMA66 controller).
Did you also try this motherboard with a different brand add-on PCI
controller (like a CMD one)?
Regards,
- Robbert
Lspci -vvvx:
00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and
Memory Controller Hub (rev 02)
Subsystem: Asustek Computer, Inc. TUSL2-C Mainboard
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [88] #09 [f104]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
00: 86 80 30 11 06 00 90 20 02 00 00 06 00 00 00 00
10: 08 00 00 f8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 27 80
30: 00 00 00 00 88 00 00 00 00 00 00 00 00 00 00 00
00:01.0 PCI bridge: Intel Corp. 82815 815 Chipset AGP Bridge (rev 02)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000e000-0000dfff
Memory behind bridge: f7b00000-f7bfffff
Prefetchable memory behind bridge: f7f00000-f7ffffff
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
00: 86 80 31 11 07 00 20 00 02 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 e0 d0 a0 22
20: b0 f7 b0 f7 f0 f7 f0 f7 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 01)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: 0000b000-0000dfff
Memory behind bridge: f0000000-f7afffff
Prefetchable memory behind bridge: f7c00000-f7efffff
BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
00: 86 80 4e 24 07 01 80 00 01 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 02 02 20 b0 d0 80 22
20: 00 f0 a0 f7 c0 f7 e0 f7 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0e 00
00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00: 86 80 40 24 0f 01 80 02 01 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 01) (prog-if 80
[Master])
Subsystem: Asustek Computer, Inc. TUSL2-C Mainboard
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 4: I/O ports at a800 [size=16]
00: 86 80 4b 24 05 00 80 02 01 80 01 01 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 a8 00 00 00 00 00 00 00 00 00 00 43 10 27 80
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 01)
Subsystem: Asustek Computer, Inc. TUSL2-C Mainboard
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 11
Region 4: I/O ports at e800 [size=16]
00: 86 80 43 24 01 00 80 02 01 00 05 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 e8 00 00 00 00 00 00 00 00 00 00 43 10 27 80
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 02 00 00
02:09.0 Unknown mass storage controller: Promise Technology, Inc. 20269
(rev 02) (prog-if 85)
Subsystem: Promise Technology, Inc.: Unknown device 4d68
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1000ns min, 4500ns max), cache line size 08
Interrupt: pin A routed to IRQ 4
Region 0: I/O ports at d800 [size=8]
Region 1: I/O ports at d400 [size=4]
Region 2: I/O ports at d000 [size=8]
Region 3: I/O ports at b800 [size=4]
Region 4: I/O ports at b400 [size=16]
Region 5: Memory at f7000000 (32-bit, non-prefetchable)
[size=16K]
Expansion ROM at <unassigned> [disabled] [size=16K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 5a 10 69 4d 07 00 30 04 02 85 80 01 08 20 00 00
10: 01 d8 00 00 01 d4 00 00 01 d0 00 00 01 b8 00 00
20: 01 b4 00 00 00 00 00 f7 00 00 00 00 5a 10 68 4d
30: 00 00 00 00 60 00 00 00 00 00 00 00 04 01 04 12
02:0b.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 09)
Subsystem: Intel Corp. EtherExpress PRO/100 S Management Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), cache line size 08
Interrupt: pin A routed to IRQ 3
Region 0: Memory at f6800000 (32-bit, non-prefetchable)
[size=4K]
Region 1: I/O ports at b000 [size=64]
Region 2: Memory at f6000000 (32-bit, non-prefetchable)
[size=128K]
Expansion ROM at <unassigned> [disabled] [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00: 86 80 29 12 17 00 90 02 09 00 00 02 08 20 00 00
10: 00 00 80 f6 01 b0 00 00 00 00 00 f6 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 11 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 03 01 08 38
02:0e.0 VGA compatible controller: S3 Inc. 86c325 [ViRGE] (rev 06)
(prog-if 00 [VGA])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f0000000 (32-bit, non-prefetchable)
[size=64M]
Expansion ROM at f7cf0000 [disabled] [size=64K]
00: 33 53 31 56 07 00 00 02 06 00 00 03 00 20 00 00
10: 00 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 cf f7 00 00 00 00 00 00 00 00 0a 01 04 ff
^ permalink raw reply
* Re: how do plugins work?
From: Edward Shishkin @ 2002-10-26 14:30 UTC (permalink / raw)
To: Hans Reiser; +Cc: gregor, reiserfs mailing list
In-Reply-To: <3DB9DE71.7000503@namesys.com>
Hans Reiser wrote:
>
> Edward Shishkin wrote:
>
> >Hans Reiser wrote:
> >
> >
> >>Edward Shishkin wrote:
> >>
> >>
> >>
> >>>Gregor Zeitlinger wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>I'm new to this list. I'm wondering how the file plugins work. Are they
> >>>>just a means of accessing the file contents or are they also designed to
> >>>>save the file differently.
> >>>>
> >>>>For example, could you create a plugin that automatically zips each
> >>>>text/plain file, which is totally transparent to the user?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Yeah, we could. Although transparentness means a bit worse compression..
> >>>
> >>>
> >>>
> >>?
> >>
> >>You mean because of choosing to use compression atoms
> >>
> >>
> >
> >Yes, but it is not the only reason.
> >
> >
> >
> >>that are node sized?
> >>
> >>
> >
> >No, compression atoms are limited by common sense ;)
> >Obviously, it doesn't make sense to choose it less then node size, if you
> >want to compress a file presented by tails. On the other hand, I am not
> >sure if you will be delighted from transparent compression supported by 256K
> >clusters even for larger files.
> >
> >
> >
> >> Maybe it might be more precise to say that efficient random
> >>access motivates small compression atoms which are less efficient?
> >> (Assuming that I understood you.)
> >>
> >>
> >
> >There is one more obscured reason that makes transparent compression worser.
> >I have to remind that its primary assignment is the same: to provide more
> >efficient disk space usage. Let's take a look how transparent compression
> >and the package using the same compression algorithm will provide it:
> >Suppose we want to compress a 8S-byte file, and both transparent compression
> >and package is supported by 4-blocks clusters, S - block size.
> >
> > File system:
> >divides the file into 2 clusters, suppose each cluster was compressed up to
> >(2S+1) bytes, so compressed file occupies 6 blocks.
> > Package:
> >makes compressed file which occupies 2*(2S+1) = 4S+2 bytes and passes it
> >to the file system, which places it (aieee!) into 5 blocks..
> >
> > So we do have the actual compression ratio produced by the file system is
> >6/8 = 25% against actual ones (5/8 = 37,5%) produced by the package. The user
> >can observe this effect only by using "du" (when he does "df", he see that
> >file system and package produce the same compression ratio 37,5%).
> >This is another effect caused by the specific of packing policy (for the
> >ext2 files, reiserfs files presented by indirect items, etc..) Obviously
> >we can avoid this by using bigger cluster (8 blocks).
> >
> >Edward.
> >
> >
> >
> >
> Or by not block aligning the clusters, which might be the right
> solution,
It is impossible for the files presented by indirect items, since
it means you'll place dead space in memory per file.
> and might allow for compression atoms larger than nodes.
> Please consider that approach.
>
> Hans
^ permalink raw reply
* [UPDATE] version 3.0-pre3 of performance counters driver for 2.5.44
From: Mikael Pettersson @ 2002-10-26 14:20 UTC (permalink / raw)
To: linux-kernel; +Cc: ak
perfctr-3.0-pre3 has been released. The only significant change
from -pre2 is that the x86 driver's per-cpu cache now uses the
per_cpu() framework, as recommended by Andi Kleen.
The updated patch kit is available from
http://www.csd.uu.se/~mikpe/linux/perfctr/3.x/patchkit/
/Mikael
^ permalink raw reply
* Re: KT333, IO-APIC, Promise Fasttrak, Initrd
From: freaky @ 2002-10-26 14:19 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1035641191.13244.108.camel@irongate.swansea.linux.org.uk>
There's no data loss that I know off... Shouldn't I atleast have notices
something if data was overwritten? Shouldn't the partition tables be corrupt
then? (Both disk manager and linux fdisk see them correctly). Don't get me
wrong :-) I'm not saying you're wrong, I wouldn't dare :-), I just find it
strange I haven't noticed anything and I've been running this setup for
several weeks now. Is there anyway I could see this block so I can see it
actually did create it? Perhaps it's written on space unlikely to be used?
Booted into the slack rescue disk this morning (busybox) and tried email the
log but the telnet can't handle pipes or something (it didn't work :-() so
I'll guess I'll have to write the whole thing down.
fdisk did recognize all the partitions as they were on the PIIX controllers
the disks come from (on the hd[e-h] devices) I was unable to mount anything
tho' mount /dev/hdh3 /mnt/hd gave me a file doesn't exist (mnt/hd dir
exists) support for the required filesystems is compiled in.
Also, the /dev/d<x>p<y> devices didn't exist, so I probably have to create
them myself perhaps then I can mount. I'll check the files for the
major/minors.
The dmesg in busy box returned more data then the kernel itself spewed
during boot. I've never seen that before? Is it writing extra debuging info
nowadays?
----- Original Message -----
From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
To: "freaky" <freaky@bananateam.nl>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Sent: Saturday, October 26, 2002 4:06 PM
Subject: Re: KT333, IO-APIC, Promise Fasttrak, Initrd
> On Sat, 2002-10-26 at 07:53, freaky wrote:
> > So that would be data on the MBR, or partition table? Perhaps win
doesn't
> > have probs because it can handle to partitions types properly. MSI told
me
>
> No its seperate. The hpt/promise raid "borrows" part of the disk and
> hides it.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* Re: [LARTC] Problem with fw filters
From: Stef Coene @ 2002-10-26 14:09 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103563976509242@msgid-missing>
Hi,
Prio is a number between 0 and 7. prio 10 is actually prio 7.
It's reported before that using the uid in routing keys is not working. Maybe
it's the same problem. The marking is working, but I'm wondering why the fw
filter is not picking up the packets. Don't know.
Stef
On Saturday 26 October 2002 15:44, Aigars Mahinovs wrote:
> Hi all,
>
> I am trying to priorityse outgoing traffic basing on UID of the sender.
> Script follows:
>
> # First mark packets with their respective priority
>
> iptables -t mangle -F OUTPUT
>
> iptables -t mangle -A OUTPUT -m owner --uid-owner root -j MARK
> --set-mark 1
> iptables -t mangle -A OUTPUT -m owner --uid-owner aigarius -j MARK
> --set-mark 2
> iptables -t mangle -A OUTPUT -m owner --uid-owner bind -j MARK
> --set-mark 3
> iptables -t mangle -A OUTPUT -m owner --uid-owner proxy -j MARK
> --set-mark 4
> iptables -t mangle -A OUTPUT -m owner --uid-owner nobody -j MARK
> --set-mark 5
> iptables -t mangle -A OUTPUT -m owner --uid-owner www-data -j MARK
> --set-mark 6
> iptables -t mangle -A OUTPUT -m owner --uid-owner ftp -j MARK --set-mark
> 7
> iptables -t mangle -A OUTPUT -m owner --uid-owner ivarix -j MARK
> --set-mark 8
> iptables -t mangle -A OUTPUT -m owner --uid-owner blacky -j MARK
> --set-mark 9
> iptables -t mangle -A OUTPUT -j MARK --set-mark 666
>
> # now make outgoing traffic classes
> # clean existing qdiscs, hide errors
> /home/aigarius/bin/tc qdisc del dev eth0 root 2> /dev/null >
> /dev/null
>
> /home/aigarius/bin/tc qdisc add dev eth0 root handle 1: htb
> /home/aigarius/bin/tc class add dev eth0 parent 1: classid 1:1 htb rate
> 100mbit burst 64k
> /home/aigarius/bin/tc class add dev eth0 parent 1:1 classid 1:10 htb
> rate 100mbit burst 64k prio 1
> /home/aigarius/bin/tc class add dev eth0 parent 1:1 classid 1:20 htb
> rate 100mbit burst 64k prio 2
> /home/aigarius/bin/tc class add dev eth0 parent 1:1 classid 1:30 htb
> rate 100mbit burst 64k prio 3
> /home/aigarius/bin/tc class add dev eth0 parent 1:1 classid 1:40 htb
> rate 100mbit burst 64k prio 4
> /home/aigarius/bin/tc class add dev eth0 parent 1:1 classid 1:50 htb
> rate 100mbit burst 64k prio 5
> /home/aigarius/bin/tc class add dev eth0 parent 1:1 classid 1:60 htb
> rate 100mbit burst 64k prio 6
> /home/aigarius/bin/tc class add dev eth0 parent 1:1 classid 1:70 htb
> rate 100mbit burst 64k prio 7
> /home/aigarius/bin/tc class add dev eth0 parent 1:1 classid 1:80 htb
> rate 100mbit burst 64k prio 8
> /home/aigarius/bin/tc class add dev eth0 parent 1:1 classid 1:90 htb
> rate 100mbit burst 64k prio 9
> /home/aigarius/bin/tc class add dev eth0 parent 1:1 classid 1:666 htb
> rate 10mbit burst 64k prio 20
> # all get Stochastic Fairness:
> /home/aigarius/bin/tc qdisc add dev eth0 parent 1:10 handle 10: sfq
> perturb 10
> /home/aigarius/bin/tc qdisc add dev eth0 parent 1:20 handle 20: sfq
> perturb 10
> /home/aigarius/bin/tc qdisc add dev eth0 parent 1:30 handle 30: sfq
> perturb 10
> /home/aigarius/bin/tc qdisc add dev eth0 parent 1:40 handle 40: sfq
> perturb 10
> /home/aigarius/bin/tc qdisc add dev eth0 parent 1:50 handle 50: sfq
> perturb 10
> /home/aigarius/bin/tc qdisc add dev eth0 parent 1:60 handle 60: sfq
> perturb 10
> /home/aigarius/bin/tc qdisc add dev eth0 parent 1:70 handle 70: sfq
> perturb 10
> /home/aigarius/bin/tc qdisc add dev eth0 parent 1:80 handle 80: sfq
> perturb 10
> /home/aigarius/bin/tc qdisc add dev eth0 parent 1:90 handle 90: sfq
> perturb 10
> /home/aigarius/bin/tc qdisc add dev eth0 parent 1:666 handle 666: sfq
> perturb 10
> # Filter traffic into classes
> /home/aigarius/bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10
> handle 1 fw flowid 1:10
> /home/aigarius/bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10
> handle 2 fw flowid 1:20
> /home/aigarius/bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10
> handle 3 fw flowid 1:30
> /home/aigarius/bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10
> handle 4 fw flowid 1:40
> /home/aigarius/bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10
> handle 5 fw flowid 1:50
> /home/aigarius/bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10
> handle 6 fw flowid 1:60
> /home/aigarius/bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10
> handle 7 fw flowid 1:70
> /home/aigarius/bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10
> handle 8 fw flowid 1:80
> /home/aigarius/bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10
> handle 9 fw flowid 1:90
> /home/aigarius/bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10
> handle 666 fw flowid 1:666
>
> --- END OF SCRIPT ---
>
> Problem:
> no shaping is done
>
> # tc -s qdisc show
> qdisc sfq 666: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb
> 10sec
> Sent 679086470 bytes 985634 pkts (dropped 0, overlimits 0)
>
> qdisc sfq 90: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb
> 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
>
> qdisc sfq 80: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb
> 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
>
> qdisc sfq 70: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb
> 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
>
> qdisc sfq 60: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb
> 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
>
> qdisc sfq 50: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb
> 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
>
> qdisc sfq 40: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb
> 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
>
> qdisc sfq 30: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb
> 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
>
> qdisc sfq 20: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb
> 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
>
> qdisc sfq 10: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb
> 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
>
> qdisc htb 1: dev eth0 r2q 10 default 0 direct_packets_stat 778 ver 3.6
> Sent 679175569 bytes 986412 pkts (dropped 0, overlimits 9647)
>
> #iptables -v -t mangle -L OUTPUT
> Chain OUTPUT (policy ACCEPT 25M packets, 16G bytes)
> pkts bytes target prot opt in out source
> destination
> 6782 802K MARK all -- any any anywhere
> anywhere OWNER UID match root MARK set 0x1
> 7439 393K MARK all -- any any anywhere
> anywhere OWNER UID match aigarius MARK set 0x2
> 7878 2018K MARK all -- any any anywhere
> anywhere OWNER UID match bind MARK set 0x3
> 65687 49M MARK all -- any any anywhere
> anywhere OWNER UID match proxy MARK set 0x4
> 752K 524M MARK all -- any any anywhere
> anywhere OWNER UID match nobody MARK set 0x5
> 24388 35M MARK all -- any any anywhere
> anywhere OWNER UID match www-data MARK set 0x6
> 44401 62M MARK all -- any any anywhere
> anywhere OWNER UID match ftp MARK set 0x7
> 7 600 MARK all -- any any anywhere
> anywhere OWNER UID match ivarix MARK set 0x8
> 0 0 MARK all -- any any anywhere
> anywhere OWNER UID match blacky MARK set 0x9
> 1019K 680M MARK all -- any any anywhere
> anywhere MARK set 0x29a
>
> As I see there is no shaping done -- the filters do not work.
> I also do routing based on firewall key -> it doesn't work either, but
> nothing shows any errors.
>
> Please help. Thanks.
>
> PS. I am using kernel 2.4.19 patched with htb3 and gr-security patch and
> htb3 precompiled tc on Debian unstable system.
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [PATCH] Double x86 initialise fix.
From: Eric W. Biederman @ 2002-10-26 14:08 UTC (permalink / raw)
To: Dave Jones; +Cc: Alan Cox, Linux Kernel Mailing List, alan
In-Reply-To: <20021026134947.GA31349@suse.de>
Dave Jones <davej@codemonkey.org.uk> writes:
> On Sat, Oct 26, 2002 at 02:56:20PM +0100, Alan Cox wrote:
> > > For many moons, we've been executing identify_cpu()
> > > on the boot processor twice on SMP kernels.
> > > This is harmless, but has a few downsides..
> > > - Extra cruft in bootlog/dmesg
> > > - Spawns one too many timers for the mcheck handler
> > > - possibly other wasteful things..
> > >
> > > This seems to do the right thing here..
>
> Isn't this always the case on x86 ?
> /me waits to hear gory details of some IBM monster.
If it is the logical cpu id yes, then id 0 is always the bootstrap
cpu.
For apic id #0 to not be the bootstrap cpu you don't need an IBM
monster, there are several SMP machines with that property.
Eric
^ permalink raw reply
* New changes
From: Harry Kalogirou @ 2002-10-26 14:03 UTC (permalink / raw)
To: Linux-8086
Hi all,
after a long time there are some new changes in the CVS! Any happy beta
testers out there?
Harry
^ permalink raw reply
* 2.5.44-ac3 usb audio - illegal sleep call
From: Kevin Brosius @ 2002-10-26 14:13 UTC (permalink / raw)
To: kernel
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
I've been trying to get USB up to test a audio device and just managed
to get it all working to some extent. When using xmms to play audio
(usb audio module - oss soundcore) I see the following kernel messages
repeatedly, maybe once a second or so:
Oct 26 09:15:56 sea kernel: Debug: sleeping function called from illegal
context at mm/slab.c:1374
Oct 26 09:15:56 sea kernel: Call Trace:
Oct 26 09:15:56 sea kernel: [<c013fd0b>] __kmem_cache_alloc+0x17b/0x180
Oct 26 09:15:56 sea kernel: [<e0a28bb5>] ohci_urb_enqueue+0xb5/0x2d0
[ohci-hcd]
Oct 26 09:15:56 sea kernel: [<e09b9017>] hcd_submit_urb+0x117/0x180
[usbcore]
Oct 26 09:15:56 sea kernel: [<e09c9d20>] usb_hcd_operations+0x0/0x40
[usbcore]
Oct 26 09:15:56 sea kernel: [<e09b993b>] usb_submit_urb+0x1db/0x250
[usbcore]
Oct 26 09:15:56 sea kernel: [<e0a30b75>] usbout_completed+0xe5/0x110
[audio]
Oct 26 09:15:56 sea kernel: [<e09b9409>] usb_hcd_giveback_urb+0x19/0x30
[usbcore]
Oct 26 09:15:56 sea kernel: [<e0a28add>] dl_done_list+0x13d/0x160
[ohci-hcd]
Oct 26 09:15:56 sea kernel: [<e0a2945b>] ohci_irq+0xfb/0x160 [ohci-hcd]
Oct 26 09:15:56 sea kernel: [<e09b9442>] usb_hcd_irq+0x22/0x60
[usbcore]
Oct 26 09:15:56 sea kernel: [<c010b8c5>] handle_IRQ_event+0x45/0x70
Oct 26 09:15:56 sea kernel: [<c010bb6a>] do_IRQ+0xba/0x160
Oct 26 09:15:56 sea kernel: [<c0107100>] default_idle+0x0/0x50
Oct 26 09:15:56 sea kernel: [<c010a1ba>] common_interrupt+0x42/0x58
Oct 26 09:15:56 sea kernel:
Oct 26 09:15:57 sea kernel: Debug: sleeping function called from illegal
context at mm/slab.c:1374
Oct 26 09:15:57 sea kernel: Call Trace:
Oct 26 09:15:57 sea kernel: [<c013fd0b>] __kmem_cache_alloc+0x17b/0x180
Oct 26 09:15:57 sea kernel: [<e0a28bb5>] ohci_urb_enqueue+0xb5/0x2d0
[ohci-hcd]
Oct 26 09:15:57 sea kernel: [<e09b9017>] hcd_submit_urb+0x117/0x180
[usbcore]
Oct 26 09:15:57 sea kernel: [<e09c9d20>] usb_hcd_operations+0x0/0x40
[usbcore]
Oct 26 09:15:57 sea kernel: [<e09b993b>] usb_submit_urb+0x1db/0x250
[usbcore]
Oct 26 09:15:57 sea kernel: [<e0a30b75>] usbout_completed+0xe5/0x110
[audio]
Oct 26 09:15:57 sea kernel: [<e09b9409>] usb_hcd_giveback_urb+0x19/0x30
[usbcore]
Oct 26 09:15:57 sea kernel: [<e0a28add>] dl_done_list+0x13d/0x160
[ohci-hcd]
Oct 26 09:15:57 sea kernel: [<e0a2945b>] ohci_irq+0xfb/0x160 [ohci-hcd]
Oct 26 09:15:57 sea kernel: [<e09b9442>] usb_hcd_irq+0x22/0x60
[usbcore]
Oct 26 09:15:57 sea kernel: [<c010b8c5>] handle_IRQ_event+0x45/0x70
Oct 26 09:15:57 sea kernel: [<c010bb6a>] do_IRQ+0xba/0x160
Oct 26 09:15:57 sea kernel: [<c0107100>] default_idle+0x0/0x50
Oct 26 09:15:57 sea kernel: [<c010a1ba>] common_interrupt+0x42/0x58
Hardware:
Athlon MP - AMD 760MP
USB audio - Sound Blaster Extigy
I also notice that usb audio dies when closing the Netscape browser.
Has anyone seen this? I haven't run across other trouble reports about
this, and it also occurs on 2.4.1[89] kernels. rmmod'ing the USB layer
and reloading it fixes the problem until it gets killed again on 2.4.
Looks like it might be the hub, but not sure yet.
--
Kevin
[-- Attachment #2: .config_small --]
[-- Type: text/plain, Size: 17078 bytes --]
CONFIG_X86=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_EXPERIMENTAL=y
CONFIG_NET=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_M686=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_HAS_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_HAVE_CMOV=y
CONFIG_HUGETLB_PAGE=y
CONFIG_SMP=y
CONFIG_PREEMPT=y
CONFIG_NR_CPUS=32
CONFIG_TOSHIBA=m
CONFIG_I8K=m
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
CONFIG_HIGHPTE=y
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA=y
CONFIG_EISA=y
CONFIG_HOTPLUG=y
CONFIG_PCMCIA=m
CONFIG_CARDBUS=y
CONFIG_I82092=m
CONFIG_I82365=m
CONFIG_TCIC=m
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_COMPAQ=m
CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM=y
CONFIG_HOTPLUG_PCI_IBM=m
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
CONFIG_PARPORT_PC_PCMCIA=m
CONFIG_PARPORT_OTHER=y
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_PNP_NAMES=y
CONFIG_ISAPNP=y
CONFIG_BLK_DEV_FD=y
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_BPCK6=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPATC8=y
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=64000
CONFIG_BLK_DEV_INITRD=y
CONFIG_LBD=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_IDEDMA_ONLYDISK=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT34X=y
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_NS87415=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDE_CHIPSETS=y
CONFIG_BLK_DEV_4DRIVES=y
CONFIG_BLK_DEV_ALI14XX=y
CONFIG_BLK_DEV_DTC2278=y
CONFIG_BLK_DEV_HT6560B=y
CONFIG_BLK_DEV_QD65XX=y
CONFIG_BLK_DEV_UMC8672=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=y
CONFIG_SR_EXTRA_DEVS=4
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_REPORT_LUNS=y
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
CONFIG_AIC7XXX_RESET_DELAY_MS=5000
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_ADVANSYS=m
CONFIG_SCSI_BUSLOGIC=m
CONFIG_SCSI_CPQFCTS=m
CONFIG_SCSI_IPS=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
CONFIG_SCSI_SYM53C8XX=m
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=80
CONFIG_SCSI_NCR53C8XX_PROFILE=y
CONFIG_SCSI_NCR53C8XX_PQS_PDS=y
CONFIG_SCSI_PSI240I=m
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_ISP=m
CONFIG_SCSI_QLOGIC_FC=m
CONFIG_SCSI_QLOGIC_FC_FIRMWARE=y
CONFIG_SCSI_ULTRASTOR=m
CONFIG_SCSI_DEBUG=m
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID5=m
CONFIG_MD_MULTIPATH=m
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_NETFILTER=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_LARGE_TABLES=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_COMPAT_IPCHAINS=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_COMPAT_IPFWADM=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IPV6=m
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
CONFIG_IPV6_SCTP__=m
CONFIG_VLAN_8021Q=m
CONFIG_LLC=y
CONFIG_DECNET=m
CONFIG_DECNET_SIOCGIFCONF=y
CONFIG_BRIDGE=m
CONFIG_X25=m
CONFIG_LAPB=m
CONFIG_ECONET=m
CONFIG_WAN_ROUTER=m
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y
CONFIG_NETDEVICES=y
CONFIG_ARCNET=m
CONFIG_ARCNET_1201=m
CONFIG_ARCNET_1051=m
CONFIG_ARCNET_RAW=m
CONFIG_ARCNET_COM90xx=m
CONFIG_ARCNET_COM90xxIO=m
CONFIG_ARCNET_RIM_I=m
CONFIG_ARCNET_COM20020=m
CONFIG_ARCNET_COM20020_ISA=m
CONFIG_ARCNET_COM20020_PCI=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_ETHERTAP=m
CONFIG_NET_SB1000=m
CONFIG_NET_ETHERNET=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL1=m
CONFIG_EL2=m
CONFIG_ELPLUS=m
CONFIG_EL16=m
CONFIG_EL3=m
CONFIG_3C515=m
CONFIG_VORTEX=m
CONFIG_LANCE=m
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=m
CONFIG_ULTRA=m
CONFIG_ULTRA32=m
CONFIG_SMC9194=m
CONFIG_NET_VENDOR_RACAL=y
CONFIG_NI5010=m
CONFIG_NI52=m
CONFIG_NI65=m
CONFIG_AT1700=m
CONFIG_DEPCA=m
CONFIG_HP100=m
CONFIG_NET_ISA=y
CONFIG_E2100=m
CONFIG_EWRK3=m
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
CONFIG_HPLAN_PLUS=m
CONFIG_HPLAN=m
CONFIG_LP486E=m
CONFIG_ETH16I=m
CONFIG_NE2000=m
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_AC3200=m
CONFIG_APRICOT=m
CONFIG_CS89x0=m
CONFIG_DGRS=m
CONFIG_EEPRO100=m
CONFIG_E100=m
CONFIG_LNE390=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_NE3210=m
CONFIG_ES3210=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
CONFIG_8139TOO_8129=y
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m
CONFIG_ACENIC=m
CONFIG_DL2K=m
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_SK98LIN=m
CONFIG_TIGON3=m
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NET_RADIO=y
CONFIG_STRIP=m
CONFIG_ARLAN=m
CONFIG_AIRONET4500=m
CONFIG_AIRONET4500_NONCS=m
CONFIG_AIRONET4500_PNP=y
CONFIG_AIRONET4500_PCI=y
CONFIG_AIRONET4500_ISA=y
CONFIG_AIRONET4500_I365=y
CONFIG_AIRONET4500_PROC=m
CONFIG_WAVELAN=m
CONFIG_AIRO=m
CONFIG_HERMES=m
CONFIG_PLX_HERMES=m
CONFIG_PCMCIA_NETWAVE=m
CONFIG_PCMCIA_WAVELAN=m
CONFIG_PCMCIA_HERMES=m
CONFIG_AIRO_CS=m
CONFIG_NET_WIRELESS=y
CONFIG_TR=y
CONFIG_IBMTR=m
CONFIG_IBMOL=m
CONFIG_IBMLS=m
CONFIG_3C359=m
CONFIG_TMS380TR=m
CONFIG_TMSPCI=m
CONFIG_TMSISA=m
CONFIG_ABYSS=m
CONFIG_SMCTR=m
CONFIG_NET_FC=y
CONFIG_SHAPER=m
CONFIG_IRDA=m
CONFIG_IRLAN=m
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRTTY_SIR=m
CONFIG_IRPORT_SIR=m
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_LITELINK_DONGLE=m
CONFIG_OLD_BELKIN_DONGLE=m
CONFIG_USB_IRDA=m
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
CONFIG_TOSHIBA_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=m
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_CT82C710=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_XTKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=y
CONFIG_MOUSE_INPORT=m
CONFIG_MOUSE_LOGIBM=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
CONFIG_PPDEV=m
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ELEKTOR=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=m
CONFIG_BUSMOUSE=m
CONFIG_QIC02_TAPE=m
CONFIG_QIC02_DYNCONF=y
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_SOFT_WATCHDOG=m
CONFIG_WDT=m
CONFIG_WDTPCI=m
CONFIG_WDT_501=y
CONFIG_WDT_501_FAN=y
CONFIG_PCWATCHDOG=m
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
CONFIG_EUROTECH_WDT=m
CONFIG_IB700_WDT=m
CONFIG_I810_TCO=m
CONFIG_MIXCOMWD=m
CONFIG_60XX_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_MACHZ_WDT=m
CONFIG_INTEL_RNG=m
CONFIG_AMD_RNG=m
CONFIG_NVRAM=m
CONFIG_RTC=y
CONFIG_DTLK=m
CONFIG_APPLICOM=m
CONFIG_SONYPI=m
CONFIG_MWAVE=m
CONFIG_QUOTA=y
CONFIG_QFMT_V1=m
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_REISERFS_FS=m
CONFIG_ADFS_FS=m
CONFIG_AFFS_FS=m
CONFIG_HFS_FS=m
CONFIG_BFS_FS=m
CONFIG_EXT3_FS=m
CONFIG_JBD=m
CONFIG_JBD_DEBUG=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_EFS_FS=m
CONFIG_CRAMFS=m
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_JFS_FS=m
CONFIG_JFS_STATISTICS=y
CONFIG_MINIX_FS=y
CONFIG_VXFS_FS=m
CONFIG_NTFS_FS=m
CONFIG_NTFS_DEBUG=y
CONFIG_HPFS_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_QNX4FS_FS=m
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=y
CONFIG_SYSV_FS=m
CONFIG_UDF_FS=m
CONFIG_UDF_RW=y
CONFIG_UFS_FS=m
CONFIG_XFS_FS=m
CONFIG_XFS_RT=y
CONFIG_XFS_QUOTA=y
CONFIG_QUOTACTL=y
CONFIG_CODA_FS=m
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_ZISOFS_FS=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_OSF_PARTITION=y
CONFIG_ATARI_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_ULTRIX_PARTITION=y
CONFIG_SUN_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_MDA_CONSOLE=m
CONFIG_SOUND=m
CONFIG_SOUND_PRIME=m
CONFIG_SOUND_BT878=m
CONFIG_SOUND_CMPCI=m
CONFIG_SOUND_CMPCI_FM=y
CONFIG_SOUND_CMPCI_FMIO=388
CONFIG_SOUND_CMPCI_MIDI=y
CONFIG_SOUND_CMPCI_MPUIO=330
CONFIG_SOUND_CMPCI_JOYSTICK=y
CONFIG_SOUND_CMPCI_CM8738=y
CONFIG_SOUND_CMPCI_SPDIFLOOP=y
CONFIG_SOUND_CMPCI_SPEAKERS=2
CONFIG_SOUND_EMU10K1=m
CONFIG_MIDI_EMU10K1=y
CONFIG_SOUND_FUSION=m
CONFIG_SOUND_CS4281=m
CONFIG_SOUND_ES1370=m
CONFIG_SOUND_ES1371=m
CONFIG_SOUND_ESSSOLO1=m
CONFIG_SOUND_MAESTRO=m
CONFIG_SOUND_MAESTRO3=m
CONFIG_SOUND_ICH=m
CONFIG_SOUND_RME96XX=m
CONFIG_SOUND_SONICVIBES=m
CONFIG_SOUND_TRIDENT=m
CONFIG_SOUND_VIA82CXXX=m
CONFIG_MIDI_VIA82CXXX=y
CONFIG_SOUND_OSS=m
CONFIG_SOUND_TRACEINIT=y
CONFIG_SOUND_DMAP=y
CONFIG_SOUND_AD1816=m
CONFIG_SOUND_SGALAXY=m
CONFIG_SOUND_ADLIB=m
CONFIG_SOUND_ACI_MIXER=m
CONFIG_SOUND_CS4232=m
CONFIG_SOUND_SSCAPE=m
CONFIG_SOUND_GUS=m
CONFIG_SOUND_GUSMAX=y
CONFIG_SOUND_TRIX=m
CONFIG_SOUND_MSS=m
CONFIG_SOUND_MPU401=m
CONFIG_SOUND_NM256=m
CONFIG_SOUND_MAD16=m
CONFIG_MAD16_OLDCARD=y
CONFIG_SOUND_PAS=m
CONFIG_SOUND_PSS=m
CONFIG_PSS_MIXER=y
CONFIG_SOUND_SB=m
CONFIG_SOUND_AWE32_SYNTH=m
CONFIG_SOUND_WAVEFRONT=m
CONFIG_SOUND_MAUI=m
CONFIG_SOUND_YM3812=m
CONFIG_SOUND_OPL3SA1=m
CONFIG_SOUND_OPL3SA2=m
CONFIG_SOUND_YMFPCI=m
CONFIG_SOUND_YMFPCI_LEGACY=y
CONFIG_SOUND_UART6850=m
CONFIG_SOUND_AEDSP16=m
CONFIG_SC6600=y
CONFIG_SC6600_JOY=y
CONFIG_SC6600_CDROM=4
CONFIG_SC6600_CDROMBASE=0
CONFIG_AEDSP16_SBPRO=y
CONFIG_AEDSP16_MPU401=y
CONFIG_SOUND_TVMIXER=m
CONFIG_USB=m
CONFIG_USB_DEVICEFS=y
CONFIG_USB_LONG_TIMEOUT=y
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_UHCI_HCD_ALT=m
CONFIG_USB_AUDIO=m
CONFIG_USB_MIDI=m
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_HP8200e=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_USB_HIDDEV=y
CONFIG_USB_AIPTEK=m
CONFIG_USB_WACOM=m
CONFIG_USB_MDC800=m
CONFIG_USB_SCANNER=m
CONFIG_USB_MICROTEK=m
CONFIG_USB_HPUSBSCSI=m
CONFIG_USB_DABUSB=m
CONFIG_USB_CATC=m
CONFIG_USB_CDCETHER=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_USBNET=m
CONFIG_USB_USS720=m
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_AUERSWALD=m
CONFIG_USB_RIO500=m
CONFIG_USB_TEST=m
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_KALLSYMS=y
CONFIG_SECURITY_CAPABILITIES=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TSC=y
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
^ permalink raw reply
* Sharing the home directory...
From: Ibrahim El-Shafei @ 2002-10-26 14:01 UTC (permalink / raw)
To: linux-admin, linux-config
Dear Sir,
I have about 5 linux boxes on my site. I want to make all of them share
the same home directory and users, so I exported the home directory of
one of them and then pointed to this home directory as /home for the
other boxes. It didn't work, why?
Thank you for your help.
Yours,
Ibrahim El-Shafei
"HimaTech"
Ibrahim El-Shafei
"HimaTech"
^ permalink raw reply
* Re: [PATCH] de-cryptify ide-disk host protected area output
From: Alan Cox @ 2002-10-26 14:25 UTC (permalink / raw)
To: andersen; +Cc: bert hubert, Andre Hedrick, Linux Kernel Mailing List
In-Reply-To: <20021026132419.GA11930@codepoet.org>
On Sat, 2002-10-26 at 14:24, Erik Andersen wrote:
> Even better -- kill the prink entirely. If anyone really
> cares, they can run 'hdparm -I <drivename>' and get the
> exhaustive list of everything the drive supports....
Please leave it alone for now. There are a whole collection of extremely
verbose and pointless IDE messages left, and I want them left until we
are close to release, so we can debug stuff
In fact I will probably add more very soon
^ permalink raw reply
* Re: [LARTC] can anyone help me to solve this problem?
From: Folke Aeon @ 2002-10-26 13:57 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103555834517971@msgid-missing>
hi , Werner :)
i do the following modification to the net/sched/sch_ingress.c
ingress_enqueue() function , i simply add the following lines
after the line 169: skb->tc_index = TC_H_MIN(res.classid);
if (skb->tc_index > 0xf || skb->tc_index = 0) {
switch (skb->protocol) {
case __constant_htons(ETH_P_IP):
ipv4_change_dsfield(skb->nh.iph,
0x3,skb->tc_index);
break;
case __constant_htons(ETH_P_IPV6):
ipv6_change_dsfield(skb->nh.ipv6h,
0x3,skb->tc_index);
break;
default:
break;
};
};
it works currently, but wonder whether there will be
any negative influence or not. would you please give
some comment on this ?
again , thanks for your precious time.
another thing, i noticed that since the dsmark dequeue
function does not support mpls protocol, so when a mpls
packet arrives, it complains "unsupported protocol".
Although the tcindex value is still there, it just cannot
use it . i think this is where the problem lies in.
folke.
_________________________________________________________________
Surf the Web without missing calls! Get MSN Broadband.
http://resourcecenter.msn.com/access/plans/freeactivation.asp
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Behavior of tails with respect to shred, wipe, etc
From: Hans Reiser @ 2002-10-26 13:53 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Reiserfs-List
In-Reply-To: <200210260709.g9Q79N8Q012571@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
>On Sat, 26 Oct 2002 05:41:10 +0400, Hans Reiser said:
>
>
>
>>Use encryption. Encryption still leaves you vulnerable to those who can
>>extract the key out of the owner though.
>>
>>
>
>If you have multiple users on the same filesystem, key management becomes...
>umm... "interesting". Projects like loop-AES usually finesse it by only
>having one key per filesystem.
>
>It's 3AM, I'm going to avoid thinking about what's involved if *one* user on
>a multi-user partition needs to change a compromised key.... ;)
>
>
Try thinking about what happens if you build a distributed filesystem
with security based on keys, and you want to remove one user from access
to a file.
;-)
This may be an inherent limitation on key based security.
We are going to allow users to supply whatever key they want to for
encrypting a file in reiser4.1. Unfortunately, due to Halloween, it
looks like reiser4.0 will have little in the way of new features, and
all the new stuff will be delayed until 4.1, which will hopefully come
out sometime around January.
Hans
^ permalink raw reply
* Re: make xconfig - 2.5.44
From: Alan Cox @ 2002-10-26 14:16 UTC (permalink / raw)
To: Mike Tharp; +Cc: Linux Kernel Mailing List
In-Reply-To: <3DB9EB82.7060106@insightbb.com>
On Sat, 2002-10-26 at 02:10, Mike Tharp wrote:
> Maybe this has already been addressed. I looked for a solution like
> crazy first. Trying to configure 2.5.44. "make menuconfig" works fine
> to my knowledge.
Should be ok in 2.5.44-ac
^ permalink raw reply
* Re: [PATCH] Double x86 initialise fix.
From: Alan Cox @ 2002-10-26 13:57 UTC (permalink / raw)
To: Dave Jones; +Cc: Alan Cox, Linux Kernel Mailing List, alan
In-Reply-To: <20021026134947.GA31349@suse.de>
> Isn't this always the case on x86 ?
> /me waits to hear gory details of some IBM monster.
It isnt. The boot CPU may be any number. In addition you can strap dual
pentium boxes to arbitrate for who is boot cpu (this is used for fault
tolerance).
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.