Unsuscribe

Jobs (jobs@i-team.com)
Tue, 14 Sep 1999 08:37:17 -0300


-----Mensaje original-----
De: owner-linux-kernel-digest@vger.rutgers.edu
[mailto:owner-linux-kernel-digest@vger.rutgers.edu]
Enviado el: Martes, 14 de Septiembre de 1999 01:12 a.m.
Para: linux-kernel-digest@vger.rutgers.edu
Asunto: linux-kernel-digest V1 #4452

linux-kernel-digest Tuesday, 14 September 1999 Volume 01 : Number
4452

In this issue:

Linux 2.3.18ac3
oops:0000
Re: IDE Driver in Linux Reports different geometry that Netware during
Volume and Partition Create, causing loss of user data under Linux
Re: weird top results in 2.3.18ac2
SCSI interrupts, system latency
Re: Re: New Idea? Capture video settings details in Win98/etc. forXFree86
config
MTRR setting and framebuffer driver
who is planning to develop a usb net adapter driver?
Re: Designing a keyboard controller
Re: [PATCH] final support for MODULE_PARAM as kernel commandline
Re: [PATCH] final support for MODULE_PARAM as kernel commandline
bug in linux-2.2.13pre7, arch/i386/kernel/setup.c doesn't compile if
CONFIG_PCI without CONFIG_PCI_QUIRKS, invalid lvalue in assignment
Re: [PATCH] final support for MODULE_PARAM as kernel commandline
Re: who is planning to develop a usb net adapter driver?
Re: MTRR setting and framebuffer driver
Re: IDE Driver in Linux Reports different geometry that Netware during
Volume and Partition Create, causing loss of user data unO
Re: oops:0000
Re: IDE Driver in Linux Reports different geometry that Netware during
Volume and Partition Create, causing loss of user data under Linux
=?ISO-8859-1?Q?linux-kernel=B4=D4?=
=?ISO-8859-1?Q?=BE=C8=B3=E7=C7=CF=BC=BC=BF=E4?= -
=?ISO-8859-1?Q?=C3=DF=BC=AE=BC=B1=B9=B0?= -
Re: [patch] pci probing
Re: Disk Corruption with ide hpt-366 controller & software raid5
Re: [PATCH] final support for MODULE_PARAM as kernel commandline
RE: Disk Corruption with ide hpt-366 controller & software raid5
eth0: RTL8139 Interrupt line blocked, status 4.
Yamaha CRW4416S problem playing audio CD's
Re: Lock-up on boot, Kernel 2.3.18-ac2
RE: Disk Corruption with ide hpt-366 controller & software raid5

See the end of the digest for information on subscribing to the linux-kernel
or linux-kernel-digest mailing lists.

----------------------------------------------------------------------

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Tue, 14 Sep 1999 00:59:20 +0100
Subject: Linux 2.3.18ac3

The big ones here are the new config files. They are now consistent about
EXPERIMENTAL. Driver authors please check if you think the tagging is
right. Its now consistent, but the old values were not so at times David
has guessed which of the several counterclaims you meant.

Also the MODULE_PARM change should clean up __setup stuff for many people.
Some drivers have MODULE_PARM inside ifdef MODULE at do not want it now,
some vice versa.

2.3.18ac3
o Cleaned up the PCMCIA makefiles - now works (me)
modular
o Move proc fs documentation into fileysystems (Jeff Garzik)
o Fixed SMP locking for softdog read/write (me)
| Note in 2.3.x the master kernel lock isnt held
| for read/write methods on drivers
o Added SMP locking to bw-qcam and bttv (me)
Also to some other drivers (eg radio*)
o Fix LAVA PCI idents (Tim Waugh)
o Fix kunmap debug bug (Andrea Arcangeli)
o Kill remaining __init calls (Tigran Aivazian)
o Big config file cleanup (David Weienhall)
o MediaGX audio workarounds (me)
o Set PCI master flags on OHCI USB (me)
o OHCI SMM to native takeover (me)
o Re-enable FOOF fix (Mikael Pettersson)
o Parport fixes (Mikael Pettersson)
o Wavelan fixes (Jean Tourrilhes)
o ParPort init fixes (Tim Waugh)
o ISAPnP for ne2k (Richard Guenther)
| Someone could generalise the probe table stuff ..
o Export scsi_wait_cmd (Doug Gilbert)
o Errno comment fixes (Artur Skawina)
o Automagical module parameter->setup parser (Richard Guenther)
| This was broken for non arrays. I think I have
| it fixed properly.
o Hopefully fixed the Defxx driver (me)

2.3.18ac2

o Fix PCMCIA link error on net modules (me)
o Various small tidyups (Jeff Garzik)
o Turn the freeing of kernel resources to become
a kernel thread into a single function (me)
o Flushpage fix (Andrea Arcangeli)
o Update USB audio patches (Tom Sailer)
o E820 memory sizing fixes (should sort the IBMs) (David Parsons)
o Use xargs for the make clean pass (David Parsons)
o Made APM a bool for now (me)
o s/Happyly/Happily/ (David Weinehall)
o Fix invalid resource free in serial (Nick Holloway)

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: "Sandip K. Shah" <sandy@cs.uky.edu>
Date: Mon, 13 Sep 1999 20:07:05 -0400 (EDT)
Subject: oops:0000

Hi,

I am implementing a transport layer protocol in linux kernel
2.2.10. When I try to boot my kernel, I get the following error message &
the system gets hanged!

Please help me to trace the problem as this is URGENT.

- - Sandip

Error Message:
-------------
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0000
EIP: 0010:[<c0107e2a]
EFLAGS: 00010093
eax: 315e97cc ebx: 003a6f80 ecx: 001be77b edx: 00237c0c
esi: 00000000 edi: bffffdb3 ebp: 00589f90 esp: 00589f8c
ds: 0018 es: 0018 ss: 0018
Process swapper( ... )
Stack: ....
.
.
.
Killing the interrupt handler.
Kernel panic: Attempt to kill the idle task.

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: "Jeff Merkey" <jmerkey@timpanogas.com>
Date: Mon, 13 Sep 1999 18:09:19 -0600
Subject: Re: IDE Driver in Linux Reports different geometry that Netware
during Volume and Partition Create, causing loss of user data under Linux

Andries,

I changed the drive setting to "AUTO" in the CMOS for this drive, and now
the drive reports 850/63/64. It is interesting to note that there was no
setting for this disk device that matched any of the configurations you gave
me. Long ago I wrote an IDE driver on Netware (Wolf Mountain), so I am
aware of the ability to translate drives into other logical geometries and
am very famliar with low level IDE stuff (unfortunately). The one thing
that sucks about IDE and ATA is that both use IO port reads and writes to
transfer data to and from the disk (which sucks up a lot of bus cycles).
It's better, however, to get this type of info to the right folks who
maintain the driver. There are several IDE drivers out there on other OS's
that for some reason did not implement the new commands for EIDE when they
came out. I try to focus on the stuff I am supposed to be working on and
not trying to fix everyone else's bugs, but report then to them instead. I
did not know if there were underlying hardware issues that I was unaware of
since it's been about two years since I did any IDE work. I thought someone
else may be more recently on top of it (like you).

Thanks for the help. I am relieved to know that the Linux IDE drivers are
not busted and don''t have any cross platform issues that will cuase
different OS's to report different geometry.

Thanks,

Jeff

- ----- Original Message -----
From: Guest section DW <dwguest@win.tue.nl>
To: <dwguest@win.tue.nl>; <jmerkey@timpanogas.com>;
<linux-kernel@vger.rutgers.edu>
Sent: Monday, September 13, 1999 4:37 PM
Subject: Re: IDE Driver in Linux Reports different geometry that Netware
during Volume and Partition Create, causing loss of user data under Linux

> > > With a MAXTOR 81750-A4 disk device, Netware reports that this disk
> > > has a geometry of 850 cylinders, 64 heads, and 63 sectors per
track.
> >
> > That sounds correct.
> >
> > > Under Linux, the same device reports a geometry of 780 cylinders,
> > > 64 heads, and 63 sectors per track.
> >
> > I always repeat the same question: what are the boot messages?
> > And in case you answer you might as well add the output of
hdparm -I.
> > My first conjecture in such cases is user error.
> > For example, the disk may be entered incorrectly in BIOS/CMOS.
>
> From jmerkey@timpanogas.com Mon Sep 13 23:13:41 1999
>
> Boot messages report the wrong geometry as well. These newer drives
use a
> EIDE command to get the correct geometry and typically, at least in
modern
> times, don't rely on the information in CMOS since it can be
incorrect.
>
> Jeff
>
> Ah - you are naive. There is no `correct geometry'.
> But there is a geometry reported by the disk (two geometries, in fact).
> And there is a correct geometry for doing I/O (if LBA is not used).
> And there is a correct geometry for booting, for LILO to use.
> And there is a correct geometry for interaction with other
> operating systems - the one that everybody agrees upon for the
> interpretation of the partition table.
> These geometries differ in general.
>
> The disk here reports 3400 cylinders, 16 heads and 63 sectors per track.
> For the partition table you would have liked 850 cylinders, 64 heads,
> and 63 sectors per track.
> It sounds as if you told the computer in the CMOS setup not to use
> more than 780 cylinders.
>
> If that is the case, then just correct that, and the problem is gone.
> Otherwise I would like to see more precise data.
>
> Andries - aeb@cwi.nl
>

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Rogerio Brito <rbrito@iname.com>
Date: Sun, 12 Sep 1999 23:53:11 -0300
Subject: Re: weird top results in 2.3.18ac2

On Sep 13 1999, CaT wrote:
> This looks very wrong. Mainly the shared mem usage report and the
> use of swap...
>
> 12:18am up 10:28, 27 users, load average: 1.00, 0.88, 0.75
> 87 processes: 82 sleeping, 4 running, 1 zombie, 0 stopped
> CPU states: 32.0% user, 11.4% system, 0.0% nice, 56.5% idle
> Mem: 126240K av, 123164K used, 3076K free, 0K shrd, 18532K buff
> Swap: 128516K av, 16108K used, 112408K free 17860K cached

Geee... Is that a problem? I've seeing 0k shrd in a 486DX2
since 2.3.16 here. I thought it was extremely strange, but for
some reason I didn't report.

And this happens with 2.3.1[678], which were the first
versions I tried on that 486.

I also see that 2.3.x is *MUCH* more memory hungry than 2.2.12
(for instance) regarding memory on a 8MB machine (this 486).

I can give much details if anybody wants me to.

[]s, Roger...

- --
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogerio Brito - rbrito@iname.com - http://www.ime.usp.br/~rbrito/
Nectar homepage: http://www.linux.ime.usp.br/~rbrito/opeth/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Blu3Viper <david@james.kalifornia.com>
Date: Mon, 13 Sep 1999 17:33:33 -0700 (PDT)
Subject: SCSI interrupts, system latency

ok, for the past few months i've been baffled.

this workstation is abhorently slow. mouse moves, keyboard typing, etc.
lagged, jerky, dropped actions, etc.

i put 2.3.18 on today to see if there was any better performance.

sequence of events:

- - boot
- - five minutes pass with no activity
- - i log in and cat /proc/interrupts

lo and behold:

# cat /proc/interrupts
CPU0 CPU1
0: 15209 15096 IO-APIC-edge timer
1: 432 448 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
8: 0 0 IO-APIC-edge rtc
11: 0 0 IO-APIC-edge uhci
12: 41 53 IO-APIC-edge PS/2 Mouse
13: 1 0 XT-PIC fpu
15: 5 2 IO-APIC-edge ide1
17: 69 91 IO-APIC-level eth0
19: 4684031 4683931 IO-APIC-level sym53c8xx
NMI: 0
ERR: 0

_wow_

nearly a million per cpu per minute. now the question. why?

system info:
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 3
model name : Pentium II (Klamath)
stepping : 3
cpu MHz : 300.691244
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov mmx
bogomips : 299.83

cpu #1 is the same as cpu #0.

# lspci
00:00.0 Host bridge: Intel Corporation 440BX - 82443BX Host (rev 02)
00:01.0 PCI bridge: Intel Corporation 440BX - 82443BX AGP (rev 02)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:09.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2064W
[Millennium] (rev 01)
00:0c.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875J
(rev 04)
00:0d.0 Ethernet controller: Intel Corporation 82557 (rev 05)

there isn't any disk seeking happening. the heads are silent. there is an
onboard adaptec which gave the same symptoms. it was disabled and the above
card was installed.

if anyone has any ideas, feel free to inform me. further information avail
upon request.

- -d

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Audin Malmin <amalmin@halcyon.com>
Date: Mon, 13 Sep 1999 17:43:44 -0700
Subject: Re: Re: New Idea? Capture video settings details in Win98/etc.
forXFree86 config

On Mon, Sep 13, 1999 at 05:38:21PM -0400, Jeremy Katz wrote:
> On Mon, 13 Sep 1999, Jens Benecke wrote:
>
> > On Mon, Sep 13, 1999 at 09:16:12AM -0400, Stephen D. Williams wrote:
> >
> > How does windows find these infos? Normally it doesn't even look for it.
I
> > have yet to see a Windows fresh install that does _not_ come up in
> > 640x480x16.
> >
> > Is there someone working on "Monitor PnP" (DDC?) or something?, that
would
> > probably be the way to go. Steal infos from Windows is not bad, but not
> > everybody has Windows.
>
> It is indeed DDC and the RedHat Beta (Lorax) currently uses ddc probing to
> determine timings for your monitor.

XFree86 4.0 is supposed to do this as well... If only I owned a monitor
which was new enough to support it........

- --
Audin Malmin -
amalmin@halcyon.com

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Jamie Lokier <lkd@tantalophile.demon.co.uk>
Date: Tue, 14 Sep 1999 02:48:02 +0200
Subject: MTRR setting and framebuffer driver

vesafb tries to set a 2.5MB MTRR on my machine. This makes sense: I
have 2.5MB video memory

The MTRR driver rejects this as not a power of two.
That's fair, but not necessary in this case.

Because the 2.5MB region is a PCI region, it is power-of-two aligned,
and effectively carves 4MB in PCI mmio space.

vesafb doesn't know that: it only knows what the Vesa BIOS reports.

But we know that because we can see it in the mmio resource tree. The
2.5MB region is a subregion of a 4MB region.

Request
- -------

I would like either vesafb, or the MTRR driver to realise that this
2.5MB region is a sub-region of the 4MB region that won't be used by
anything else, so it is safe to allocate a 4MB write-combining MTRR.

Richard, is this possible now that we have the resource tree to examine?
Perhaps it is possible to generically permit rounding an MTRR range,
provided the extra address space is not used in the resource tree, and
if this condition changes in the tree, to remove the MTRR.

- -- Jamie

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: "DarkDong" <darkdong@usa.net>
Date: Mon, 13 Sep 1999 16:56:12 +0800
Subject: who is planning to develop a usb net adapter driver?

This is a multi-part message in MIME format.

- ------=_NextPart_000_0008_01BEFE08.E2463D00
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable

i'm a software engineer in Genius Company.
we have some products(e.g. mouse,net adapter...).
they need drivers in linux,but i'm a novice in developing linux device =
driver.So if you are interested in writting some driver (e.g. net =
adapter)for us,we'll reward your work.i hope we can cooperate in =
developing the usb device driver.

- ------=_NextPart_000_0008_01BEFE08.E2463D00
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">

i'm a software engineer in Genius=20 Company.
we have some products(e.g. mouse,net = adapter...).
they need drivers in linux,but i'm a = novice in=20 developing linux device driver.So if you = are=20 interested in writting some driver (e.g. net adapter)for us,we'll reward = your=20 work.i hope we can cooperate in = developing the=20 usb device driver.
- ------=_NextPart_000_0008_01BEFE08.E2463D00-- Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Nicolas Pitre Date: Mon, 13 Sep 1999 20:51:33 -0400 (EDT) Subject: Re: Designing a keyboard controller On Mon, 13 Sep 1999, J.D. Bakker wrote: > [Hope this is not too off-topic...] > > Hi all, > > I'm designing an embedded StrongARM-based system[1] that I want to use with > Linux. I need to design a keyboard/mouse interface for this beast, and > going by the kernel sources PS/2 seems the way to go (I'd really like to > use commodity hardware to talk to X and friends). > > I've since found notes on how to capture a PS/2 stream with a > microcontroller, but I don't know what the best interface is to offer > Linux, ie what should the hardware look like when seen from the kernel . > I'd rather not use an 8042 ;-), but I'm open for other suggestions. The > StrongARM has an I/O space that is almost but not entirely unlike ISA, and > I have some GP I/O pins to spare. Does anyone have an idea what the best > interface would be ? Whatever hardware you need, the best is really to use something that can be atached to the so called pcmcia bus on the SA1100. You might need some logic to decode the address and activate a chip-enable signal if you have more than one port to address. A GPIO, preferably between 0 and 10, can be used as interrupt line. With such a setup around the SA1100, current ISA drivers can be used with very minimal modifications as long as they aren't using DMA. The kernel code for the SA1100 already provides access to that bus through the in*()/out*() macros. You then have plenty of choice for an interface chip. Nicolas Pitre nico@cam.org nico@visuaide.com Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: David Hinds Date: Mon, 13 Sep 1999 18:05:31 -0700 Subject: Re: [PATCH] final support for MODULE_PARAM as kernel commandline I think this is generally a GREAT thing, and something I've wanted for a long time, but never got around to doing. However... I think we can't just grab the module parameter name and use that as a boot parameter name: each module currently has its own "namespace" for parameters, and you're going to get tons of conflicts this way. For instance, there are tons of things like: MODULE_PARM(io, "i"); MODULE_PARM(debug, "i"); etc. There are two options for dealing with this: either invent a standard naming convention (i.e., "io" becomes "3c501_io") and live with that for both module parameters and boot parameters, or, have a way of specifying a prefix just for boot parameters, like: __setup(MODULE_PREFIX #var "=", modparm##var##_setup); I tend to prefer the prefix thing because I think it would cause less disruption. Module parameters could still use the short form everyone expects. Driver updates would consist of just adding a macro for the prefix. It would also be nice to parse more of the argument classes, including the array-of-int things. But that can be added later. - -- Dave Hinds Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: grant@torque.net Date: Mon, 13 Sep 1999 21:14:25 -0400 (EDT) Subject: Re: [PATCH] final support for MODULE_PARAM as kernel commandline > There are two options for dealing with this: either invent a standard > naming convention (i.e., "io" becomes "3c501_io") and live with that > for both module parameters and boot parameters, or, have a way of > specifying a prefix just for boot parameters, like: > > __setup(MODULE_PREFIX #var "=", modparm##var##_setup); > > I tend to prefer the prefix thing because I think it would cause less > disruption. Module parameters could still use the short form everyone > expects. Driver updates would consist of just adding a macro for the > prefix. Of course, there is already some precedent for this. All the PARIDE drivers use parameters like pcd.verbose= or pd.drive0= ... - -------------------------------------------------------------------------- Grant R. Guenther grant@torque.net - -------------------------------------------------------------------------- Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: David Dyck Date: Mon, 13 Sep 1999 18:17:46 -0700 (PDT) Subject: bug in linux-2.2.13pre7, arch/i386/kernel/setup.c doesn't compile if CONFIG_PCI without CONFIG_PCI_QUIRKS, invalid lvalue in assignment arch/i386/kernel/setup.c doesn't compile if CONFIG_PCI without CONFIG_PCI_QUIRKS A workaround would be to define CONFIG_PCI_QUIRKS The code in ./arch/i386/kernel/setup.c needs to check if CONFIG_PCI_QUIRKS is defined before assigning to isa_dma_bridge_buggy on line 642. I'd send a patch, but I don't know the best solution yet. I just know that I had CONFIG_PCI=y # CONFIG_PCI_QUIRKS is not set in .config and got the following error Perhaps the #ifdef should have been for CONFIG_PCI_QUIRKS instead of CONFIG_PCI or what exactly should be done when the kernel detects the Cyrix MediaGX magic needs to be applied but since CONFIG_PCI_QUIRKS wasn't defined the kernel can't set isa_dma_bridge_buggy (a constant 0) to 1, include/asm-i386/dma.h #ifdef CONFIG_PCI_QUIRKS extern int isa_dma_bridge_buggy; #else #define isa_dma_bridge_buggy (0) #endif  gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fom it-frame-pointer -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o setup.o setup.c setup.c: In function `cyrix_model': setup.c:642: invalid lvalue in assignment make[1]: *** [setup.o] Error 1 make[1]: Leaving directory `/usr/src/linux-2.2.13pre7/arch/i386/kernel' make: *** [_dir_arch/i386/kernel] Error 2 dd:linux-2.2.13pre7$ g CONFIG_PCI_QUIRKS .co* # CONFIG_PCI_QUIRKS is not set !h Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Alan Cox Date: Tue, 14 Sep 1999 02:20:42 +0100 (BST) Subject: Re: [PATCH] final support for MODULE_PARAM as kernel commandline > However... I think we can't just grab the module parameter name and > use that as a boot parameter name: each module currently has its own > "namespace" for parameters, and you're going to get tons of conflicts > this way. For instance, there are tons of things like: Agreed > for both module parameters and boot parameters, or, have a way of > specifying a prefix just for boot parameters, like: > > __setup(MODULE_PREFIX #var "=", modparm##var##_setup); I think there are two obvious things here. You got one of them bang on the head. The other is to make SETUP_PARM() both and MODULE_PARM() module only I think ? Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Alan Cox Date: Tue, 14 Sep 1999 02:22:24 +0100 (BST) Subject: Re: who is planning to develop a usb net adapter driver? > i'm a software engineer in Genius Company. > we have some products(e.g. mouse,net adapter...). > they need drivers in linux,but i'm a novice in developing linux device = > driver.So if you are interested in writting some driver (e.g. net = > adapter)for us,we'll reward your work.i hope we can cooperate in = > developing the usb device driver. > I'm willing to help on the network side, but ideally by helping someone else who takes up the offer by answering the network questions As to mice. HID isnt yet in the code but HIDBP is and your mouse probably already works in that (limited) mode. Alan Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Jeff Garzik Date: Mon, 13 Sep 1999 21:23:48 -0400 Subject: Re: MTRR setting and framebuffer driver Jamie Lokier wrote: > I would like either vesafb, or the MTRR driver to realise that this > 2.5MB region is a sub-region of the 4MB region that won't be used by > anything else, so it is safe to allocate a 4MB write-combining MTRR. > > Richard, is this possible now that we have the resource tree to examine? > Perhaps it is possible to generically permit rounding an MTRR range, > provided the extra address space is not used in the resource tree, and > if this condition changes in the tree, to remove the MTRR. IMHO this should be done in vesafb, possibly based on the value passed to __request_region(). Jeff - -- Custom driver development | Never worry about theory as long Open source programming | as the machinery does what it's | supposed to do. -- R. A. Heinlein Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Andre Hedrick Date: Mon, 13 Sep 1999 18:57:05 -0700 (PDT) Subject: Re: IDE Driver in Linux Reports different geometry that Netware during Volume and Partition Create, causing loss of user data unO Andre Hedrick The Linux IDE guy > P.S. Totally Kick-Ass IPO -- RedHat is **SMOKING** on Wall Street right > now.. Must you remind us that got screwed by "ETrade" of this fact......FLAME ON. Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: "Richard B. Johnson" Date: Mon, 13 Sep 1999 21:57:58 -0400 (EDT) Subject: Re: oops:0000 On Mon, 13 Sep 1999, Sandip K. Shah wrote: > Hi, > > I am implementing a transport layer protocol in linux kernel > 2.2.10. When I try to boot my kernel, I get the following error message & > the system gets hanged! > > Please help me to trace the problem as this is URGENT. > > - Sandip > > Error Message: > ------------- > current->tss.cr3 = 00101000, %cr3 = 00101000 > *pde = 00000000 > Oops: 0000 > EIP: 0010:[ EFLAGS: 00010093 > eax: 315e97cc ebx: 003a6f80 ecx: 001be77b edx: 00237c0c > esi: 00000000 edi: bffffdb3 ebp: 00589f90 esp: 00589f8c > ds: 0018 es: 0018 ss: 0018 > Process swapper( ... ) > Stack: .... > . > . > . > Killing the interrupt handler. > Kernel panic: Attempt to kill the idle task. > You don't really provide enough information. However, the hint I see is 'Process swapper'. It looks as though there was a page-fault when the kernel was in an interrupt. This could happen if you are trying to copy to user from within an interrupt or something similar. If your 'transport layer' code executes off from an interrupt, you could be in trouble; "Don't do that!". You have to buffer interrupt stuff somewhere to access it later in a user context. Cheers, Dick Johnson **** FILE SYSTEM WAS MODIFIED **** Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips). Warning : It's hard to remain at the trailing edge of technology. Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Andre Hedrick Date: Mon, 13 Sep 1999 18:59:58 -0700 (PDT) Subject: Re: IDE Driver in Linux Reports different geometry that Netware during Volume and Partition Create, causing loss of user data under Linux Everyone else should take note taht AUTO is preferred unless you know how to force the issue. As for the CMOS probing of drives, I hope that it goes away a soon as Andries cleans up the geometry mess (of mine). Andre Hedrick The Linux IDE guy On Mon, 13 Sep 1999, Jeff Merkey wrote: > Andries, > > I changed the drive setting to "AUTO" in the CMOS for this drive, and now > the drive reports 850/63/64. It is interesting to note that there was no > setting for this disk device that matched any of the configurations you gave > me. Long ago I wrote an IDE driver on Netware (Wolf Mountain), so I am > aware of the ability to translate drives into other logical geometries and > am very famliar with low level IDE stuff (unfortunately). The one thing > that sucks about IDE and ATA is that both use IO port reads and writes to > transfer data to and from the disk (which sucks up a lot of bus cycles). > It's better, however, to get this type of info to the right folks who > maintain the driver. There are several IDE drivers out there on other OS's > that for some reason did not implement the new commands for EIDE when they > came out. I try to focus on the stuff I am supposed to be working on and > not trying to fix everyone else's bugs, but report then to them instead. I > did not know if there were underlying hardware issues that I was unaware of > since it's been about two years since I did any IDE work. I thought someone > else may be more recently on top of it (like you). > > Thanks for the help. I am relieved to know that the Linux IDE drivers are > not busted and don''t have any cross platform issues that will cuase > different OS's to report different geometry. > > Thanks, > > Jeff > > ----- Original Message ----- > From: Guest section DW > To: ; ; > > Sent: Monday, September 13, 1999 4:37 PM > Subject: Re: IDE Driver in Linux Reports different geometry that Netware > during Volume and Partition Create, causing loss of user data under Linux > > > > > > With a MAXTOR 81750-A4 disk device, Netware reports that this disk > > > > has a geometry of 850 cylinders, 64 heads, and 63 sectors per > track. > > > > > > That sounds correct. > > > > > > > Under Linux, the same device reports a geometry of 780 cylinders, > > > > 64 heads, and 63 sectors per track. > > > > > > I always repeat the same question: what are the boot messages? > > > And in case you answer you might as well add the output of > hdparm -I. > > > My first conjecture in such cases is user error. > > > For example, the disk may be entered incorrectly in BIOS/CMOS. > > > > From jmerkey@timpanogas.com Mon Sep 13 23:13:41 1999 > > > > Boot messages report the wrong geometry as well. These newer drives > use a > > EIDE command to get the correct geometry and typically, at least in > modern > > times, don't rely on the information in CMOS since it can be > incorrect. > > > > Jeff > > > > Ah - you are naive. There is no `correct geometry'. > > But there is a geometry reported by the disk (two geometries, in fact). > > And there is a correct geometry for doing I/O (if LBA is not used). > > And there is a correct geometry for booting, for LILO to use. > > And there is a correct geometry for interaction with other > > operating systems - the one that everybody agrees upon for the > > interpretation of the partition table. > > These geometries differ in general. > > > > The disk here reports 3400 cylinders, 16 heads and 63 sectors per track. > > For the partition table you would have liked 850 cylinders, 64 heads, > > and 63 sectors per track. > > It sounds as if you told the computer in the CMOS setup not to use > > more than 780 cylinders. > > > > If that is the case, then just correct that, and the problem is gone. > > Otherwise I would like to see more precise data. > > > > Andries - aeb@cwi.nl > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu > Please read the FAQ at http://www.tux.org/lkml/ > Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: =?ISO-8859-1?Q?=B1=E8=C1=A4=B3=B2?= Date: Tue, 14 Sep 99 09:35:14 =?ISO-8859-1?Q?=B4=EB=C7=D1=B9=CE=B1=B9?= =?ISO-8859-1?Q?=C7=A5=C1=D8=BD=C3?= Subject: =?ISO-8859-1?Q?linux-kernel=B4=D4?= =?ISO-8859-1?Q?=BE=C8=B3=E7=C7=CF=BC=BC=BF=E4?= - =?ISO-8859-1?Q?=C3=DF=BC=AE=BC=B1=B9=B0?= - This is a multi-part message in MIME format. - --AD_2000_PART_BOUNDARY_19990606 Content-Type: text/plain Content-Transfer-Encoding: 7Bit ¾È³çÇϼ¼¿ä. Çã¶ô¾øÀÌ ¸ÞÀÏÀ» º¸³½Á¡ »ç°úµå¸³´Ï´Ù. ±×³É »èÁ¦¸¦ Çϼŵµ µË´Ï´Ù. Ãß¼®À» ¸Â¾Æ ÁÁÀº ¼±¹°À» ¼Ò°³ ½ÃÄÑ µå¸®°íÀÚ ÇÕ´Ï´Ù. Á¦¸ñ : Ãß¼®¼±¹° - Áö¸®»ê °Ç°­½ÄÇ° 1. ±¹³»ÃÖÃÊ Ç°ÁúÀÎÁõ ȹµæ È«È­¾¾ -»À, °ñ´Ù°øÁõ Áö¸®»ê »êû È«È­¾¾ Á¦Ç°ÀÔ´Ï´Ù. (http://www.honghwawon.co.kr) ±¹¸³ ³ó»ê¹° °Ë»ç¿øÀ¸·ÎºÎÅÍ ÃÖÃÊ·Î Ç°Áú ÀÎÁõÀ» ¹Þ¾Ò½À´Ï´Ù. °ñÀý, °ñ´Ù°øÁõ ¿¹¹æ µî »À°ü·Ã Áúº´¿¡ ƯȿÀÔ´Ï´Ù. ´ë·®»ý»êÀ¸·Î °¡°Ý¶ÇÇÑ Àú·ÅÇϸç, Ç°ÁúÀÎÁõÀÌ ¸»ÇØÁÖµí Ç°Áú¶ÇÇÑ ÃÖ°í ÀÔ´Ï´Ù. °Ç°­»ó´ãµµ ÇÏ°í ÀÖÀ¸´Ï ¸¹Àº ¹æ¹® ¹Ù¶ø´Ï´Ù. Ãß¼®À» ´ëºñÇÑ È«È­²Ü 250°³ ÇÑÁ¤ÆǸÅ, ÆÐÅ°Áö »óÇ°¶ÇÇÑ D.CµÈ °¡°ÝÀ¸·Î ÆǸÅÇÕ´Ï´Ù. http://www.honghwawon.co.kr Tel : 080-973-8880, 0596-973-8830 2. ´ç´¢¿¡´Â ´©¿¡°¡·ç ? Áö¸®»ê »êûÀÇ ¾çÀáÇùµ¿Á¶ÇÕÀÔ´Ï´Ù. (http://www.nue.co.kr) ´ç´¢¿£ õ¿¬Ç÷´ç°­ÇÏÁ¦ÀÎ ´©¿¡°¡·ç¸¦ »ý»ê ÆǸÅÇÕ´Ï´Ù. ûÁ¤Áö¿ªÀÎ Áö¸®»ê »êû¿¡¼­ »ý»êµÇ¾ú½À´Ï´Ù. ȨÆäÀÌÁö¸¦ ¹æ¹®Çϼż­ ´©¿¡¿¡ ´ëÇؼ­ ¸¹Àº ³»¿ëµµ Âü°íÇϽñ⠹ٶø´Ï´Ù. »ý»êÀÚ Á÷°Å·¡·Î °¡°Ý ¶ÇÇÑ Àú·ÅÇÕ´Ï´Ù. ¸¹ÀÌ ¸¹ÀÌ ¹æ¹®ÇØ ÁÖ¼¼¿ä. http://www.nue.co.kr Tel : 080-973-5110, 0596-973-8441 3. °£±â´É¿¡ Áö¸®»ê ÀÎÁø¾¦À» µå¼Åº¸¼¼¿ä. Áö¸®»ê ¾¦À» ´Ù·Á¼­ ¸¸µç Á¦Ç°ÀÔ´Ï´Ù. (http://www.injinssuk.co.kr) ƯÈ÷, °£ ±â´É °³¼±¿¡ µµ¿òÀÌ µÇ´Â ÀÎÁö¾¦ÀÔ´Ï´Ù. ȨÆäÀÌÁö¸¦ ¹æ¹®ÇØ ÁÖ¼¼¿ä. ¸¸È­ µ¿ÀǺ¸°¨µµ ÀÖ½À´Ï´Ù. Âü°í Çϼ¼¿ä. »ý»êÀÚ Á÷°Å·¡·Î °¡°Ý ¶ÇÇÑ Àú·ÅÇÕ´Ï´Ù. ȨÆäÀÌÁö¿¡¼­ ºË°Ú½À´Ï´Ù. http://www.injinssuk.co.kr Tel : 080-973-8880, 0596-973-8830 Á¦¸ñ : Ãß¼® ƯÆÇ - ½ÅºñÀÇ "µ¿ÃæÇÏÃÊ" ½ÅºñÀÇ ºÒ·ÎÃʶó ºÒ¸®¿ì´Â "µ¿ÃæÇÏÃÊ" ½ÃÁß°¡º¸´Ù 30% D.CµÈ °¡°Ý¿¡ 10 Box¸¸ ÇÑÁ¤ÆǸŠÇÕ´Ï´Ù. ¼­µÑ·¯ ÁֽʽÿÀ. Ư¡ : µ¿ÃæÇÏÃÊ´Â ¹ö¼¸ ±Õ»çü°¡ µ¿Àý±â¿¡´Â °ïÃæÀÇ À¯ÃæÀ̳ª ¼ºÃæÀÇ Ã¼³»¿¡ ÀẹÇØ ÀÖ´Ù°¡, ÇÏÀý±â¿¡´Â °ïÃæÀÇ Ã¼³»¿¡¼­ ¹ö¼¸À¸·Î ÇǾ´Â ½ÅºñÀÇ ¿µ¾àÀÔ´Ï´Ù. Áß±¹ÀÇ ºñ¾à : µ¿ÃæÇÏÃÊ´Â ¿¹·ÎºÎÅÍ °í»êÁö´ë¿¡¼­ ÀÚ¿¬»êÀ¸·Î¸¸ äÃëµÇ´Â µ¶Æ¯ÇÑ »ýÅÂƯ¼º ¶§¹®¿¡ ÀϹÝÈ­ µÇÁö ¸øÇÏ°í ºñ¾àÀ¸·Î Ãë±ÞµÇ°í ÀÖ¾úÀ¸¸ç ÃÖ±Ù¿¡ Áß±¹ÀÇ 'µî¼ÒÆò' ÁÖ¼®°ú '¸¶±º´Ü' À°»ó ¼±¼öÆÀÀÌ »óº¹ÇÏ¿´´Ù ÇÏ¿© ´õ¿í À¯¸íÇÏ¿©Á³½À´Ï´Ù. ¾à¸®È¿°ú : Ç×¾ÏÈ¿°ú, °£º¸È£ È¿°ú, Ç×ÇÇ·Î È¿°ú, ¸é¿ª·Â Áõ°­È¿°ú, Ç× Stress È¿°ú, Ç׳ë¼è È¿°ú »óÇ°¸í : ¹öµé³óÀå µ¿ÃæÇÏÃÊ °ñµå ³»¿ë·® : 380g (³¹°³ ÀÚ½Çü µ¿ÃæÇÏÃÊ 180g, »ê¾à 100g, ´ëÃß 200g) / 1Box °¡°Ý : 220,000 ¿ø (¹è¼ÛºñÆ÷ÇÔ) 10 Box ÇÑÁ¤ ÆǸŠ±¸ÀÔ¹®ÀÇ : ¾ç»óÈÆ (017-427-5110) ÀÔ±Ý : ³óÇù 721110-52-065437 ¿¹±ÝÁÖ : ¾ç»óÈÆ - --AD_2000_PART_BOUNDARY_19990606-- Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: David Hinds Date: Mon, 13 Sep 1999 19:09:24 -0700 Subject: Re: [patch] pci probing > > The PCI code in 2.2 cannot be harder to use even if the only reason > > were that it's backward-compatible with the one in 2.3 :-) Also, > > can you tell me any concrete example where the new PCI interface > > is harder to use? > > Yes. Every PCI device has an identifying structure, and the structure > is growing at an alarming rate. For instance, there is substructure for > the base address register. Each base address register exists as a 32 bit > register on the card, and most drivers only care about one of the first two > registers (I/O vs. memory space). The structure now uses up to 32 bytes for > each of the six possible (most are unused) registers. There are 16 resource structures in a pci_dev now. This wasn't due to Martin, though: much of the expansion is because pci_dev is now supposed to handle the union of PCI and PnP device needs. And because of (imho) wrong-headed things like putting human-readable device descriptions in the pci_dev struct. The new PCI code did make CardBus support somewhat more complicated. The code needed for initializing a new PCI device has gotten larger. I have mixed feelings about this: I do think the linux device model needed work, however, I've also grown to appreciate the philosophy of keeping kernel interfaces simple. The current CardBus code fills in enough fields to make things work, but with the latest kernel, that means I'm leaving the majority of fields uninitialized. The old interfaces did not make CardBus and hot plug stuff especially difficult. The resource management changes also didn't really make things any easier. The new resource code does distinguish between reserving resources, and associating them with a device driver, and that is useful. I can't use it for PCMCIA, however, because the kernel can only pre-enumerate PCI resources for now. CardBus works just as well in 2.0.* kernels as in the latest 2.3.* kernels: the only deficiency in 2.0.* is the reliance on possibly buggy PCI BIOS's to access configuration space. > > Maybe the resource code in 2.3 is designed sub-optimally, but I'm > > sure we really need such a thing if we want to support hot-pluggable > > devices > > Uhmmm... No. We've been doing hot-pluggable PCI devices with CardBus > for years. A valid concern is hot-pluggable bus bridges, but that's > not what drove this change. I'd have to agree with this. There may be some things for which the new PCI code is better, but hot plug support is not one of them. - -- Dave Hinds Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Andre Hedrick Date: Mon, 13 Sep 1999 19:11:40 -0700 (PDT) Subject: Re: Disk Corruption with ide hpt-366 controller & software raid5 Are you sure? I know that there is a SMP issue with RAID 5 and 20 disks regardless of the IDE host adapter cluster. This list includes all of the best cards. HighPoint HPT366 and both of Promise's PDC20246 and PDC20262. Under heavy load tests at CERN all three models fail under SMP with sequential access; however are clean with UP. Fabien, can you authenticate this? Mingo, Alan, and Andrea I am down to designing an extention to the request queing, please stop me. There has to be a better answer than doubling up code. Thoughts? Andre Hedrick The Linux IDE guy On Mon, 13 Sep 1999, Tom Livingston wrote: > Hello all, > > I am encountering reproducible read time errors while reading from my > existing RAID array with at least one disk running on a HPT-366 driven > channel. This manifests itself as random errors... e.g. if you read the > same thing five times, you will get five different answers. I first > encountered this as massive corruption in my superblocks and file systems, > but I have included set of dd results below to make the explanation more > scientific. > > As I point out below with the dd tests, this problem does not occur when > accessing the disk on the hpt-366 controller alone, and not through the raid > set /dev/md0. Also, this same raid set "passes" the tests when none of the > disks are connected to the hpt-366. > > I am running redhat-6.0+updates, linux kernel 2.2.12, with > raid0145-19990824-2.2.11.gz and 2.2.12.uniform-ide-6.20.hydra.patch.gz Note > that the raid patch is for 2.2.11, however it applies cleanly, minus one > reject in include/linux/fs.h. This patch in the raid code was already > applied to 2.2.12. > > Hardware is Abit BP-6 motherboard, single celeron 366, 128MB ram. IDE disk > controllers present: PIIX4 (onboard), three PDC20246 (3 pci cards), HPT-366 > (onboard). These controllers run 12 drives, 10 in the raid5 set. All 10 > raid disks are Maxtor 9084[05]D[456] (e.g. 90845D4) drives. All related > dmesg type output is included at the bottom. > > This array had been running using only the PIIX4 and the PDC20246's, with > two channels hosting two drives in the raid set, the others holding 1 > drive/channel. Set up like this, the RAID system has worked fine for > months. > > [note that the entire time these tests were run, the raid system was running > in degraded mode, as I had forcibly removed hde1 from the raid array before > these tests began, in order to do a little testing with the hpt-366 before I > committed to moving the active parts of the raid. these tests ran fine] > > [root@music /root]# for i in 1 2 3 4 5 > > do > > dd if=/dev/md0 count=500000 2> /dev/null | md5sum > > done > 48ed7a0be7aac6a7f27be473737ee097 - > 48ed7a0be7aac6a7f27be473737ee097 - > 48ed7a0be7aac6a7f27be473737ee097 - > 48ed7a0be7aac6a7f27be473737ee097 - > 48ed7a0be7aac6a7f27be473737ee097 - > > However, when a disk from the existing raid set is moved from a PDC channel > to an HPT channel, dd shows me reading unreliably from the /dev/md0 set: > > [root@music /root]# for i in 1 2 3 4 5 > > do > > dd if=/dev/md0 count=500000 2> /dev/null | md5sum > > done > 08d3b2b34dfc667ca96c549f8a8a3c15 - > cee7aa5dd1ee81ff63a93bba3830ca31 - > a577d2d50f9ebc535b9e49905c29631c - > f8c6aea89094543aaf2982ef6504285d - > 596f99e3047d18eef9798634a091670b - > > Interestingly, this does not manifest itself if you read directly from the > lone drive on the hpt-366, ignoring the raid set: > > [root@music /root]# for i in 1 2 3 4 5 > > do > > dd if=/dev/hdq1 count=500000 2> /dev/null | md5sum > > done > eada67dc62f41de461b96f0daac0983d - > eada67dc62f41de461b96f0daac0983d - > eada67dc62f41de461b96f0daac0983d - > eada67dc62f41de461b96f0daac0983d - > eada67dc62f41de461b96f0daac0983d - > > The amount of corruption, seems to be minimal. I tested one 300000 block > sample twice, and found that only 82 bytes were different: > > [root@music /root]# dd if=/dev/md0 count=300000 of=test1 > [root@music /root]# dd if=/dev/md0 count=300000 of=test2 > > [root@music /root]# cmp -l test1 test2 > 6031611 243 253 [ed note: binary: 10100011 10101011] > 6031612 323 134 [ed note: binary: 11010011 01011100] > 6293755 256 246 [ed note: binary: 10101110 10100110] > 6293756 261 76 [ed note: binary: 10110001 00111110] > 7641340 102 166 [ed note: binary: 01000010 01110110] > 7660796 147 255 [ed note: binary: 01100111 10101101] > 10296572 35 175 > 11292924 235 300 > 11369724 5 304 > 11555068 165 50 > 11631868 166 267 > [ed note: etc.. full test available] > > [root@music /root]# cmp -l test1 test2 | wc > 82 246 1422 > > The output of my boot when a drive is connected to the HPT-266 is as > follows: > > Sep 12 23:45:45 music syslog: syslogd startup succeeded > Sep 12 23:45:45 music syslog: klogd startup succeeded > Sep 12 23:45:45 music kernel: klogd 1.3-3, log source = /proc/kmsg started. > Sep 12 23:45:45 music kernel: Inspecting /boot/System.map > Sep 12 23:45:45 music kernel: Loaded 5217 symbols from /boot/System.map. > Sep 12 23:45:45 music kernel: Symbols match kernel version 2.2.12. > Sep 12 23:45:45 music kernel: No module symbols loaded - kernel modules not > enabled. > Sep 12 23:45:45 music kernel: Linux version 2.2.12 (root@music.volition.org) > (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 re > lease)) #1 Fri Sep 10 18:46:26 PDT 1999 > Sep 12 23:45:45 music kernel: Detected 367505372 Hz processor. > Sep 12 23:45:45 music kernel: Console: colour VGA+ 80x25 > Sep 12 23:45:45 music kernel: Calibrating delay loop... 367.00 BogoMIPS > Sep 12 23:45:45 music kernel: Memory: 128080k/131072k available (992k kernel > code, 416k reserved, 1528k data, 56k init) > Sep 12 23:45:45 music kernel: CPU: Intel Celeron (Mendocino) stepping 05 > Sep 12 23:45:45 music kernel: Checking 386/387 coupling... OK, FPU using > exception 16 error reporting. > Sep 12 23:45:45 music kernel: Checking 'hlt' instruction... OK. > Sep 12 23:45:45 music kernel: POSIX conformance testing by UNIFIX > Sep 12 23:45:45 music kernel: PCI: PCI BIOS revision 2.10 entry at 0xfb420 > Sep 12 23:45:45 music kernel: PCI: Using configuration type 1 > Sep 12 23:45:45 music kernel: PCI: Probing PCI hardware > Sep 12 23:45:45 music kernel: Linux NET4.0 for Linux 2.2 > Sep 12 23:45:45 music kernel: Based upon Swansea University Computer Society > NET3.039 > Sep 12 23:45:45 music kernel: NET4: Unix domain sockets 1.0 for Linux > NET4.0. > Sep 12 23:45:45 music kernel: NET4: Linux TCP/IP 1.0 for NET4.0 > Sep 12 23:45:45 music kernel: IP Protocols: ICMP, UDP, TCP > Sep 12 23:45:45 music kernel: Initializing RT netlink socket > Sep 12 23:45:45 music kernel: Starting kswapd v 1.5 > Sep 12 23:45:45 music kernel: Detected PS/2 Mouse Port. > Sep 12 23:45:45 music kernel: Serial driver version 4.27 with no serial > options enabled > Sep 12 23:45:45 music kernel: pty: 256 Unix98 ptys configured > Sep 12 23:45:45 music kernel: Uniform Multi-Platform E-IDE driver Revision: > 6.20 > Sep 12 23:45:45 music kernel: PIIX4: IDE controller on PCI bus 00 dev 39 > Sep 12 23:45:45 music kernel: PIIX4: not 100% native mode: will probe irqs > later > Sep 12 23:45:45 music kernel: ide0: BM-DMA at 0xf000-0xf007, BIOS > settings: hda:DMA, hdb:DMA > Sep 12 23:45:45 music kernel: ide1: BM-DMA at 0xf008-0xf00f, BIOS > settings: hdc:DMA, hdd:DMA > Sep 12 23:45:45 music kernel: PDC20246: IDE controller on PCI bus 00 dev 58 > Sep 12 23:45:45 music kernel: PDC20246: not 100% native mode: will probe > irqs later > Sep 12 23:45:45 music kernel: PDC20246: ROM enabled at 0xe6000000 > Sep 12 23:45:45 music kernel: PDC20246: (U)DMA Burst Bit ENABLED Primary PCI > Mode Secondary PCI Mode. > Sep 12 23:45:45 music kernel: ide2: BM-DMA at 0xa400-0xa407, BIOS > settings: hde:DMA, hdf:DMA > Sep 12 23:45:45 music kernel: ide3: BM-DMA at 0xa408-0xa40f, BIOS > settings: hdg:DMA, hdh:DMA > Sep 12 23:45:45 music kernel: PDC20246: IDE controller on PCI bus 00 dev 68 > Sep 12 23:45:45 music kernel: PDC20246: not 100% native mode: will probe > irqs later > Sep 12 23:45:45 music kernel: PDC20246: ROM enabled at 0xe7000000 > Sep 12 23:45:45 music kernel: PDC20246: (U)DMA Burst Bit ENABLED Primary PCI > Mode Secondary PCI Mode. > Sep 12 23:45:46 music atd: atd startup succeeded > Sep 12 23:45:45 music kernel: ide4: BM-DMA at 0xb800-0xb807, BIOS > settings: hdi:DMA, hdj:pio > Sep 12 23:45:45 music kernel: ide5: BM-DMA at 0xb808-0xb80f, BIOS > settings: hdk:DMA, hdl:pio > Sep 12 23:45:45 music kernel: PDC20246: IDE controller on PCI bus 00 dev 78 > Sep 12 23:45:45 music kernel: PDC20246: not 100% native mode: will probe > irqs later > Sep 12 23:45:45 music kernel: PDC20246: ROM enabled at 0xe8000000 > Sep 12 23:45:45 music kernel: PDC20246: (U)DMA Burst Bit DISABLED Primary > PCI Mode Secondary PCI Mode. > Sep 12 23:45:45 music kernel: PDC20246: FORCING BURST BIT 0x00 -> 0x01 > ACTIVE > Sep 12 23:45:45 music kernel: ide6: BM-DMA at 0xcc00-0xcc07, BIOS > settings: hdm:pio, hdn:pio > Sep 12 23:45:45 music kernel: ide7: BM-DMA at 0xcc08-0xcc0f, BIOS > settings: hdo:DMA, hdp:pio > Sep 12 23:45:45 music kernel: HPT366: onboard version of chipset, pin1=1 > pin2=2 > Sep 12 23:45:45 music kernel: HPT366: IDE controller on PCI bus 00 dev 98 > Sep 12 23:45:45 music kernel: HPT366: not 100% native mode: will probe irqs > later > Sep 12 23:45:45 music kernel: HPT366: reg5ah=0x03 ATA-33 Cable Port0 > Sep 12 23:45:45 music kernel: ide8: BM-DMA at 0xdc00-0xdc07, BIOS > settings: hdq:pio, hdr:pio > Sep 12 23:45:45 music kernel: HPT366: IDE controller on PCI bus 00 dev 99 > Sep 12 23:45:45 music kernel: HPT366: not 100% native mode: will probe irqs > later > Sep 12 23:45:45 music kernel: HPT366: reg5ah=0x01 ATA-66 Cable Port1 > Sep 12 23:45:45 music kernel: ide9: BM-DMA at 0xe800-0xe807, BIOS > settings: hds:pio, hdt:pio > Sep 12 23:45:45 music kernel: hda: QUANTUM FIREBALL ST4.3A, ATA DISK drive > Sep 12 23:45:45 music kernel: hdb: Maxtor 90845D4, ATA DISK drive > Sep 12 23:45:45 music kernel: hdc: Maxtor 84320D4, ATA DISK drive > Sep 12 23:45:45 music kernel: hdd: Maxtor 90845D4, ATA DISK drive > Sep 12 23:45:45 music kernel: hde: Maxtor 90845D4, ATA DISK drive > Sep 12 23:45:45 music kernel: hdf: Maxtor 90840D6, ATA DISK drive > Sep 12 23:45:45 music kernel: hdg: Maxtor 90845D4, ATA DISK drive > Sep 12 23:45:45 music kernel: hdi: Maxtor 90840D6, ATA DISK drive > Sep 12 23:45:46 music crond: crond startup succeeded > Sep 12 23:45:45 music kernel: hdk: Maxtor 90840D5, ATA DISK drive > Sep 12 23:45:45 music kernel: hdm: Maxtor 90845D4, ATA DISK drive > Sep 12 23:45:45 music kernel: hdo: Maxtor 90840D6, ATA DISK drive > Sep 12 23:45:45 music kernel: hdq: Maxtor 90845D4, ATA DISK drive > Sep 12 23:45:45 music kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Sep 12 23:45:45 music kernel: ide1 at 0x170-0x177,0x376 on irq 15 > Sep 12 23:45:45 music kernel: ide2 at 0x9400-0x9407,0x9806 on irq 11 > Sep 12 23:45:45 music kernel: ide3 at 0x9c00-0x9c07,0xa006 on irq 11 > Sep 12 23:45:45 music kernel: ide4 at 0xa800-0xa807,0xac06 on irq 7 > Sep 12 23:45:45 music kernel: ide5 at 0xb000-0xb007,0xb406 on irq 7 > Sep 12 23:45:45 music kernel: ide6 at 0xbc00-0xbc07,0xc002 on irq 5 > Sep 12 23:45:45 music kernel: ide7 at 0xc400-0xc407,0xc802 on irq 5 > Sep 12 23:45:45 music kernel: ide8 at 0xd400-0xd407,0xd802 on irq 11 > Sep 12 23:45:45 music kernel: hda: QUANTUM FIREBALL ST4.3A, 4110MB w/81kB > Cache, CHS=524/255/63, UDMA(33) > Sep 12 23:45:45 music kernel: hdb: Maxtor 90845D4, 8063MB w/256kB Cache, > CHS=16383/16/63, UDMA(33) > Sep 12 16:45:39 music rc.sysinit: Loading default keymap succeeded > Sep 12 16:45:39 music rc.sysinit: Setting default font succeeded > Sep 12 16:45:39 music swapon: swapon: warning: /dev/hda5 has insecure > permissions 0660, 0600 suggested > Sep 12 16:45:39 music swapon: swapon: warning: /dev/hda6 has insecure > permissions 0660, 0600 suggested > Sep 12 16:45:39 music rc.sysinit: Activating swap partitions succeeded > Sep 12 16:45:39 music rc.sysinit: Setting hostname music.volition.org > succeeded > Sep 12 16:45:39 music fsck: /dev/hda7: clean, 82206/514000 files, > 1488680/2048001 blocks > Sep 12 16:45:39 music rc.sysinit: Checking root filesystem succeeded > Sep 12 16:45:39 music rc.sysinit: Remounting root filesystem in read-write > mode succeeded > Sep 12 16:45:39 music fsck: /dev/hda1: clean, 58/52208 files, 26401/208813 > blocks > Sep 12 16:45:39 music rc.sysinit: Checking filesystems succeeded > Sep 12 16:45:40 music rc.sysinit: Mounting local filesystems succeeded > Sep 12 23:45:45 music kernel: hdc: Maxtor 84320D4, 4120MB w/256kB Cache, > CHS=8930/15/63, UDMA(33) > Sep 12 23:45:45 music kernel: hdd: Maxtor 90845D4, 8063MB w/256kB Cache, > CHS=16383/16/63, UDMA(33) > Sep 12 23:45:45 music kernel: hde: Maxtor 90845D4, 8063MB w/256kB Cache, > CHS=16383/16/63, UDMA(33) > Sep 12 23:45:45 music kernel: hdf: Maxtor 90840D6, 8010MB w/256kB Cache, > CHS=16276/16/63, UDMA(33) > Sep 12 23:45:45 music kernel: hdg: Maxtor 90845D4, 8063MB w/256kB Cache, > CHS=16383/16/63, UDMA(33) > Sep 12 23:45:45 music kernel: hdi: Maxtor 90840D6, 8010MB w/256kB Cache, > CHS=16276/16/63, UDMA(33) > Sep 12 23:45:45 music kernel: hdk: Maxtor 90840D5, 8047MB w/256kB Cache, > CHS=16351/16/63, UDMA(33) > Sep 12 23:45:45 music kernel: hdm: Maxtor 90845D4, 8063MB w/256kB Cache, > CHS=16383/16/63, UDMA(33) > Sep 12 23:45:45 music kernel: hdo: Maxtor 90840D6, 8010MB w/256kB Cache, > CHS=16276/16/63, UDMA(33) > Sep 12 23:45:45 music kernel: hdq: Maxtor 90845D4, 8063MB w/256kB Cache, > CHS=16383/16/63, (U)DMA > Sep 12 23:45:45 music kernel: Floppy drive(s): fd0 is 1.44M > Sep 12 23:45:46 music inet: inetd startup succeeded > Sep 12 16:45:40 music rc.sysinit: Turning on user and group quotas for local > filesystems succeeded > Sep 12 23:45:42 music date: Sun Sep 12 23:45:42 PDT 1999 > Sep 12 23:45:42 music rc.sysinit: Setting clock : Sun Sep 12 23:45:42 PDT > 1999 succeeded > Sep 12 23:45:42 music rc.sysinit: Enabling swap space succeeded > Sep 12 23:45:42 music init: Entering runlevel: 3 > Sep 12 23:45:44 music network: Bringing up interface lo succeeded > Sep 12 23:45:44 music network: Bringing up interface eth0 succeeded > Sep 12 23:45:45 music portmap: portmap startup succeeded > Sep 12 23:45:45 music random: Initializing random number generator succeeded > Sep 12 23:45:45 music kernel: FDC 0 is a post-1991 82077 > Sep 12 23:45:45 music kernel: md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12 > Sep 12 23:45:45 music kernel: translucent personality registered > Sep 12 23:45:45 music kernel: linear personality registered > Sep 12 23:45:45 music kernel: raid0 personality registered > Sep 12 23:45:45 music kernel: raid1 personality registered > Sep 12 23:45:45 music kernel: raid5 personality registered > Sep 12 23:45:45 music kernel: raid5: measuring checksumming speed > Sep 12 23:45:45 music kernel: raid5: MMX detected, trying high-speed MMX > checksum routines > Sep 12 23:45:45 music kernel: pII_mmx : 817.626 MB/sec > Sep 12 23:45:45 music kernel: p5_mmx : 858.774 MB/sec > Sep 12 23:45:45 music kernel: 8regs : 631.317 MB/sec > Sep 12 23:45:45 music kernel: 32regs : 353.949 MB/sec > Sep 12 23:45:45 music kernel: using fastest function: p5_mmx (858.774 > MB/sec) > Sep 12 23:45:45 music kernel: scsi : 0 hosts. > Sep 12 23:45:45 music kernel: scsi : detected total. > Sep 12 23:45:47 music named[316]: starting. named 8.2 Wed Mar 31 10:57:12 > EST 1999 ^Iroot@porky.devel.redhat.com:/usr/src/bs/BUILD/ > bind-8.2/src/bin/named > Sep 12 23:45:47 music named[316]: cache zone "" (IN) loaded (serial 0) > Sep 12 23:45:47 music named[316]: Zone "0.0.127.in-addr.arpa" (file > named.local): No default TTL set using SOA minimum instead > Sep 12 23:45:47 music named[316]: master zone "0.0.127.in-addr.arpa" (IN) > loaded (serial 1997022700) > Sep 12 23:45:47 music named[316]: listening on [127.0.0.1].53 (lo) > Sep 12 23:45:47 music named[316]: listening on [10.10.10.199].53 (eth0) > Sep 12 23:45:47 music named[316]: Forwarding source address is > [0.0.0.0].1024 > Sep 12 23:45:45 music kernel: 3c59x.c:v0.99H 11/17/98 Donald Becker > http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html > Sep 12 23:45:45 music kernel: eth0: 3Com 3c905 Boomerang 100baseTx at > 0xd000, 00:60:08:b0:2e:3c, IRQ 10 > Sep 12 23:45:45 music kernel: 8K word-wide RAM 3:5 Rx:Tx split, > autoselect/MII interface. > Sep 12 23:45:45 music kernel: MII transceiver found at address 24, status > 786f. > Sep 12 23:45:45 music kernel: Enabling bus-master transmits and > whole-frame receives. > Sep 12 23:45:45 music kernel: md.c: sizeof(mdp_super_t) = 4096 > Sep 12 23:45:45 music kernel: Partition check: > Sep 12 23:45:45 music kernel: hda: hda1 hda2 < hda5 hda6 hda7 > > Sep 12 23:45:45 music kernel: hdb: hdb1 > Sep 12 23:45:45 music kernel: hdc: [PTBL] [525/255/63] hdc1 hdc2 < hdc5 > hdc6 hdc7 > > Sep 12 23:45:45 music kernel: hdd: hdd1 > Sep 12 23:45:45 music kernel: hde: hde1 > Sep 12 23:45:45 music kernel: hdf: hdf1 > Sep 12 23:45:45 music kernel: hdg: hdg1 > Sep 12 23:45:45 music kernel: hdi: hdi1 > Sep 12 23:45:45 music kernel: hdk: hdk1 > Sep 12 23:45:45 music kernel: hdm: hdm1 > Sep 12 23:45:45 music kernel: hdo: hdo1 > Sep 12 23:45:47 music named: named startup succeeded > Sep 12 23:45:47 music named[317]: Ready to answer queries. > Sep 12 23:45:45 music kernel: hdq: hdq1 > Sep 12 23:45:45 music kernel: autodetecting RAID arrays > Sep 12 23:45:45 music kernel: (read) hdb1's sb offset: 8256896 [events: > 00000002] > Sep 12 23:45:45 music kernel: (read) hdd1's sb offset: 8256896 [events: > 00000002] > Sep 12 23:45:45 music kernel: (read) hde1's sb offset: 8256896 [events: > 00000002] > Sep 12 23:45:45 music kernel: (read) hdf1's sb offset: 8203008 [events: > 00000002] > Sep 12 23:45:45 music kernel: (read) hdg1's sb offset: 8256896 [events: > 00000002] > Sep 12 23:45:45 music kernel: (read) hdi1's sb offset: 8203008 [events: > 00000002] > Sep 12 23:45:45 music kernel: (read) hdk1's sb offset: 8240768 [events: > 00000002] > Sep 12 23:45:45 music kernel: (read) hdm1's sb offset: 8256896 [events: > 00000002] > Sep 12 23:45:45 music kernel: (read) hdo1's sb offset: 8203008 [events: > 00000002] > Sep 12 23:45:45 music kernel: (read) hdq1's sb offset: 8256896 [events: > 00000002] > Sep 12 23:45:45 music kernel: autorun ... > Sep 12 23:45:45 music kernel: considering hdq1 ... > Sep 12 23:45:47 music keytable: Loading keymap: > Sep 12 23:45:45 music kernel: adding hdq1 ... > Sep 12 23:45:45 music kernel: adding hdo1 ... > Sep 12 23:45:45 music kernel: adding hdm1 ... > Sep 12 23:45:45 music kernel: adding hdk1 ... > Sep 12 23:45:45 music kernel: adding hdi1 ... > Sep 12 23:45:45 music kernel: adding hdg1 ... > Sep 12 23:45:45 music kernel: adding hdf1 ... > Sep 12 23:45:45 music kernel: adding hdd1 ... > Sep 12 23:45:45 music kernel: adding hdb1 ... > Sep 12 23:45:45 music kernel: created md0 > Sep 12 23:45:45 music kernel: bind > Sep 12 23:45:45 music kernel: bind > Sep 12 23:45:45 music kernel: bind > Sep 12 23:45:45 music kernel: bind > Sep 12 23:45:45 music kernel: bind > Sep 12 23:45:45 music kernel: bind > Sep 12 23:45:45 music kernel: bind > Sep 12 23:45:45 music kernel: bind > Sep 12 23:45:45 music kernel: bind > Sep 12 23:45:45 music kernel: running: > > Sep 12 23:45:45 music kernel: now! > Sep 12 23:45:45 music kernel: hdq1's event counter: 00000002 > Sep 12 23:45:45 music kernel: hdo1's event counter: 00000002 > Sep 12 23:45:48 music keytable: Loading > /usr/lib/kbd/keymaps/i386/qwerty/us.kmap.gz > Sep 12 23:45:45 music kernel: hdm1's event counter: 00000002 > Sep 12 23:45:45 music kernel: hdk1's event counter: 00000002 > Sep 12 23:45:45 music kernel: hdi1's event counter: 00000002 > Sep 12 23:45:45 music kernel: hdg1's event counter: 00000002 > Sep 12 23:45:45 music kernel: hdf1's event counter: 00000002 > Sep 12 23:45:45 music kernel: hdd1's event counter: 00000002 > Sep 12 23:45:45 music kernel: hdb1's event counter: 00000002 > Sep 12 23:45:45 music kernel: md: device name has changed from hdh1 to hdq1 > since last import! > Sep 12 23:45:45 music kernel: md0: max total readahead window set to 4608k > Sep 12 23:45:45 music kernel: md0: 9 data-disks, max readahead per > data-disk: 512k > Sep 12 23:45:45 music kernel: raid5: device hdq1 operational as raid disk 6 > Sep 12 23:45:45 music kernel: raid5: device hdo1 operational as raid disk 7 > Sep 12 23:45:45 music kernel: raid5: device hdm1 operational as raid disk 4 > Sep 12 23:45:45 music kernel: raid5: device hdk1 operational as raid disk 9 > Sep 12 23:45:48 music keytable: Loading system font: > Sep 12 23:45:45 music kernel: raid5: device hdi1 operational as raid disk 3 > Sep 12 23:45:45 music kernel: raid5: device hdg1 operational as raid disk 1 > Sep 12 23:45:45 music kernel: raid5: device hdf1 operational as raid disk 2 > Sep 12 23:45:45 music kernel: raid5: device hdd1 operational as raid disk 5 > Sep 12 23:45:45 music kernel: raid5: device hdb1 operational as raid disk 0 > Sep 12 23:45:45 music kernel: raid5: md0, not all disks are operational -- > trying to recover array > Sep 12 23:45:45 music kernel: raid5: allocated 10554kB for md0 > Sep 12 23:45:45 music kernel: raid5: raid level 5 set md0 active with 9 out > of 10 devices, algorithm 2 > Sep 12 23:45:45 music kernel: RAID5 conf printout: > Sep 12 23:45:45 music kernel: --- rd:10 wd:9 fd:1 > Sep 12 23:45:45 music kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hdb1 > Sep 12 23:45:45 music kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 > Sep 12 23:45:45 music kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdf1 > Sep 12 23:45:45 music kernel: disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdi1 > Sep 12 23:45:45 music kernel: disk 4, s:0, o:1, n:4 rd:4 us:1 dev:hdm1 > Sep 12 23:45:49 music rc: Starting keytable succeeded > Sep 12 23:45:45 music kernel: disk 5, s:0, o:1, n:5 rd:5 us:1 dev:hdd1 > Sep 12 23:45:45 music kernel: disk 6, s:0, o:1, n:6 rd:6 us:1 dev:hdq1 > Sep 12 23:45:45 music kernel: disk 7, s:0, o:1, n:7 rd:7 us:1 dev:hdo1 > Sep 12 23:45:45 music kernel: disk 8, s:0, o:0, n:8 rd:8 us:1 dev:[dev > 00:00] > Sep 12 23:45:45 music kernel: disk 9, s:0, o:1, n:9 rd:9 us:1 dev:hdk1 > Sep 12 23:45:45 music kernel: disk 10, s:0, o:0, n:0 rd:0 us:0 dev:[dev > 00:00] > Sep 12 23:45:45 music kernel: disk 11, s:0, o:0, n:0 rd:0 us:0 dev:[dev > 00:00] > Sep 12 23:45:45 music kernel: RAID5 conf printout: > Sep 12 23:45:45 music kernel: --- rd:10 wd:9 fd:1 > Sep 12 23:45:45 music kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hdb1 > Sep 12 23:45:45 music kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1 > Sep 12 23:45:45 music kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdf1 > Sep 12 23:45:45 music kernel: disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdi1 > Sep 12 23:45:45 music kernel: disk 4, s:0, o:1, n:4 rd:4 us:1 dev:hdm1 > Sep 12 23:45:45 music kernel: disk 5, s:0, o:1, n:5 rd:5 us:1 dev:hdd1 > Sep 12 23:45:45 music kernel: disk 6, s:0, o:1, n:6 rd:6 us:1 dev:hdq1 > Sep 12 23:45:45 music kernel: disk 7, s:0, o:1, n:7 rd:7 us:1 dev:hdo1 > Sep 12 23:45:45 music kernel: disk 8, s:0, o:0, n:8 rd:8 us:1 dev:[dev > 00:00] > Sep 12 23:45:45 music kernel: disk 9, s:0, o:1, n:9 rd:9 us:1 dev:hdk1 > Sep 12 23:45:45 music kernel: disk 10, s:0, o:0, n:0 rd:0 us:0 dev:[dev > 00:00] > Sep 12 23:45:45 music kernel: disk 11, s:0, o:0, n:0 rd:0 us:0 dev:[dev > 00:00] > Sep 12 23:45:45 music kernel: md: updating md0 RAID superblock on device > Sep 12 23:45:45 music kernel: hdq1 [events: 00000003](write) hdq1's sb > offset: 8256896 > Sep 12 23:45:45 music kernel: md: recovery thread got woken up ... > Sep 12 23:45:45 music kernel: md0: no spare disk to reconstruct array! -- > continuing in degraded mode > Sep 12 23:45:45 music kernel: md: recovery thread finished ... > Sep 12 23:45:45 music kernel: hdo1 [events: 00000003](write) hdo1's sb > offset: 8203008 > Sep 12 23:45:45 music kernel: hdm1 [events: 00000003](write) hdm1's sb > offset: 8256896 > Sep 12 23:45:52 music sendmail: sendmail startup succeeded > Sep 12 23:45:45 music kernel: hdk1 [events: 00000003](write) hdk1's sb > offset: 8240768 > Sep 12 23:45:45 music kernel: hdi1 [events: 00000003](write) hdi1's sb > offset: 8203008 > Sep 12 23:45:45 music kernel: hdg1 [events: 00000003](write) hdg1's sb > offset: 8256896 > Sep 12 23:45:45 music kernel: hdf1 [events: 00000003](write) hdf1's sb > offset: 8203008 > Sep 12 23:45:45 music kernel: hdd1 [events: 00000003](write) hdd1's sb > offset: 8256896 > Sep 12 23:45:45 music kernel: hdb1 [events: 00000003](write) hdb1's sb > offset: 8256896 > Sep 12 23:45:45 music kernel: . > > Let me know if I can be of any more help. > > Tom > Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: David Hinds Date: Mon, 13 Sep 1999 19:22:17 -0700 Subject: Re: [PATCH] final support for MODULE_PARAM as kernel commandline On Tue, Sep 14, 1999 at 02:20:42AM +0100, Alan Cox wrote: > > > for both module parameters and boot parameters, or, have a way of > > specifying a prefix just for boot parameters, like: > > > > __setup(MODULE_PREFIX #var "=", modparm##var##_setup); > > I think there are two obvious things here. You got one of them bang on the > head. The other is to make SETUP_PARM() both and MODULE_PARM() module only > I think ? What kinds of things did you have in mind for module-only parameters? Or would this mainly be for things that already have their own setup parameter parsing code? - -- Dave Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: "Tom Livingston" Date: Mon, 13 Sep 1999 19:55:33 -0700 Subject: RE: Disk Corruption with ide hpt-366 controller & software raid5 > Are you sure? Considering the cc: on this list, I am loathe to say I am completely sure. But yes, basically, I am completely sure. Every time I do a dd | md5sum it returns a different value, where when the raid only uses the pdc the value is always the same. * This behavior definitely happens in uni-processor mode * It turns out you don't even need RAID to cause this problem, you just need very heavy IO load. * This behavior never causes a crash, only corrupted reads (unsure about writes) * I cannot duplicate this behavior at all with the PIIX4 or any of the PDC20246's connected to the same machine Besides the issue with the HPT, this system runs in production (albeit, in uni-processor mode as SMP causes hangs) and causes 0 problems. My data on the raid is checksummed when created and verified every evening, so I know if I get even a 1 bit error... and for 3+ months this system has ran as an active server without any sort of corruption or issue (though the server is limited by it's pipe, so it never really gets IO stressed... max is 3mbit/sec) There were a couple of other emails in this thread where I give some more information, if you missed those I'd be happy to re-send. Thanks for your help! Tom Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: George Date: Mon, 13 Sep 1999 22:57:11 -0400 (EDT) Subject: eth0: RTL8139 Interrupt line blocked, status 4. Linux 2.2.11 (yes, yes, I know) It seems to be ignorable (I have 3 of those messages) but I'm wondering if it could be potentially bad? - -George Greer Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: "Gregory A. Zornetzer" Date: Mon, 13 Sep 1999 22:43:52 -0500 Subject: Yamaha CRW4416S problem playing audio CD's Hi everyone, I just got a Yamaha CRW4416S, firmware revision 1.0g, and put it on my linux box - the SCSI controller is an Adaptec 2940. Anyway, the drive seems to work beautifully, except that it has a problem when using the cdplay program from RH6.0. Invoking the CD player always seems to lock the SCSI bus. I have consistently seen loops of: Domain Validation Successful Performing Domain Validation I've also sometimes seen messages that say that the card is renegotiating at a lower speed due to Domain Validation failures. I rebooted into 2.2.13pre7 with init=/bin/sh, and used the debug=1 option to the Uniform CD-Rom driver and got the list of messages below. Is this a problem with the drive's firmware, the linux drivers, or the SCSI controller? The drive seems to play audio fine in win95, and can read data CD's, and can use cdda2wav to rip audio tracks from the CD. I don't get linux-kernel directly, so I'd appreciate it if replies were also CC'ed to gazornetzer@students.wisc.edu Thanks very much, - -Greg Zornetzer cdrom.o messages: Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0 sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray cdrom: entering register_cdrom Uniform CDROM driver Revision: 2.56 cdrom: drive "/dev/sr0" registered cdrom: entering cdrom_open cdrom: entering open_for_data cdrom: drive_status=4 cdrom: entering cdrom_count_tracks cdrom: track 1: format=2, ctrl=0 cdrom: track 2: format=2, ctrl=0 cdrom: track 3: format=2, ctrl=0 cdrom: track 4: format=2, ctrl=0 cdrom: track 5: format=2, ctrl=0 cdrom: track 6: format=2, ctrl=0 cdrom: track 7: format=2, ctrl=0 cdrom: track 8: format=2, ctrl=0 cdrom: track 9: format=2, ctrl=0 cdrom: track 10: format=2, ctrl=0 cdrom: track 11: format=2, ctrl=0 cdrom: disc has 11 tracks: 11=audio 0=data 0=Cd-I 0=XA cdrom: wrong media type, but CDO_CHECK_TYPE not set. cdrom: all seems well, opening the device. VFS: Disk change detected on device sr(11,0) cdrom: opening the device gave me 0. cdrom: door locked. cdrom: device opened successfully. cdrom: Use count for "/dev/sr0" now 1 cdrom: doing audio ioctl (start/stop/pause/resume) cdrom: entering check_for_audio_disc cdrom: entering CDROMPLAYMSF cdrom: entering check_for_audio_disc cdrom: entering cdrom_release cdrom: Use count for "/dev/sr0" now zero cdrom: Unlocking door! Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Richard Rak Date: Mon, 13 Sep 1999 23:57:30 -0400 Subject: Re: Lock-up on boot, Kernel 2.3.18-ac2 Alan Cox wrote: > > > NOTE: This problem does not occur when the kernel is compiled for only > > one processor. This seems to be an SMP issue. > > > > Below is my .config file (comments removed). If anyone needs any more > > information, I'm on the list. > > If they keyboard is working use right-alt or shift or ctrl to see whats > going on. In paticular get the EIP values so you can see where it is stuck > The only EIP value that I can get is c0107a1e, which doesn't appear in my System.map. I have also tried booting 2.3.18-ac3, but have had no luck there either. Any ideas??? - -- Richard Rak (rakr@home.com) A+ Certified Service Technician Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Andre Hedrick Date: Mon, 13 Sep 1999 21:09:29 -0700 (PDT) Subject: RE: Disk Corruption with ide hpt-366 controller & software raid5 On Mon, 13 Sep 1999, Tom Livingston wrote: > > Are you sure? > > Considering the cc: on this list, I am loathe to say I am completely sure. > But yes, basically, I am completely sure. Every time I do a dd | md5sum it > returns a different value, where when the raid only uses the pdc the value > is always the same. Don't worry about the CC list. This issue overrides all. There are a few quirks I found last night. AGP Card Slot PCI 1 PDC20246: IDE controller on PCI bus 00 dev 78 hdm/n/o/p PCI 2 PDC20246: IDE controller on PCI bus 00 dev 68 hdi/j/k/l PCI 3 PDC20246: IDE controller on PCI bus 00 dev 58 hde/f/g/h PCI 4 PCI 5 Update "2.2.12.uniform-ide-6.20.hydra.patch.gz" to straight "ide.2.2.12.patch.gz" There is a change or two that enables a flag or two. Next move card in pci slot 3 to slot 4. Next turn off the irq in the BIOS for the AGP video. Due to the pci-irq routing table design, there is a potential mess. Some of this is not documented in the shipped manual. : PIRQ 0 : PIRQ 1 : PIRQ 2 : PIRQ 3 : PIRQ 4 AGP & Slot 1 : A : B : C : D : ? Slot 2 : D : A : B : C : ? Slot 3 & HPT366 : C : D : A : B : ? Slot 4 & Slot 5 : B : C : D : A : ? USB : I am not sure if the kernel will mix shared interrupts yet of this nature. If you move the primary Promise card to slot 4 and repeat the test, it will tell me if it is in the ide-driver core or in the chipset. I suspect the former and not the later. If this is the case, the hunt may expand to other parts of the kernel down to the "arch" specific handling. The next test (dangerous) is to pair off two cards into slots 4 and 5. This will verify it is not chipset, but driver core. If this more than you want to try I understand, I just need a quick class in raid setup (had not planned to do this yet) so I can use my drives that are for testing, wrecking, and trashing. I have the Promise cards and access to Promise's engineers. I managed to find the one assigned to "Linux". > * This behavior definitely happens in uni-processor mode > * It turns out you don't even need RAID to cause this problem, you just need > very heavy IO load. This makes me think it is more than chipset specific and in the request/services against a mainboard design. A quirk.... > * This behavior never causes a crash, only corrupted reads (unsure about > writes) > * I cannot duplicate this behavior at all with the PIIX4 or any of the > PDC20246's connected to the same machine Again, these are not overlapped in the irqs. > There were a couple of other emails in this thread where I give some more > information, if you missed those I'd be happy to re-send. Not needed, found them. Andre Hedrick The Linux IDE guy Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ End of linux-kernel-digest V1 #4452 *********************************** To subscribe to linux-kernel-digest, send the command: subscribe linux-kernel-digest in the body of a message to "Majordomo@vger.rutgers.edu". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-linux-kernel": subscribe linux-kernel-digest local-linux-kernel@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "linux-kernel-digest" in the commands above with "linux-kernel". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/