* Re: IDE feature request & problem
From: Alan Cox @ 2002-12-11 1:20 UTC (permalink / raw)
To: Milan Roubal; +Cc: Petr Sebor, Linux Kernel Mailing List
In-Reply-To: <039d01c2a0ab$b19a5ad0$551b71c3@krlis>
On Wed, 2002-12-11 at 00:24, Milan Roubal wrote:
> Hi Alan,
> I have got xfs partition and man fsck.xfs say
> that it will run automatically on reboot.
You need to force one. Something (I assume XFS) asked the disk for a
stupid sector number. Thats mostly likely due to some kind of internal
corruption on the XFS
^ permalink raw reply
* Re: Hanging Init
From: Wolfgang Denk @ 2002-12-11 0:33 UTC (permalink / raw)
To: Pagnotta, Chris; +Cc: linuxppc-embedded
In-Reply-To: <0509218DDAD7D6118055006008F6D5F6A1E3A2@postal.viasat.com>
In message <0509218DDAD7D6118055006008F6D5F6A1E3A2@postal.viasat.com> you wrote:
>
> I figure I am at the last stage in boot (I hope). I am however having an
> issue that I was hoping someone
> may shed some light on. I am having a hanging init.
>
> 1) I rebuilt busybox and here are the dependencies:
Ummm... why did you do that? The ELDK already cntains BusyBox
binaries, both dymnamically and staically linked.
> 3) Here is the output from PPCBoot. It looks like NFS mount was successfull.
> I am using
...and if you're using the root filesystem over NFS you don;t need
any busybox at all.
If you're looking for a ramdisk environment, check for
images/pRamdisk in your ELDK directory - there is a SELF RPM included
with ELDK 2.0.
> NFS mount server that run in user space NOT kernel. Don't know of this
> makes any difference,
> but I was able to NFS mount the directory from another machine.
> mount -t nfs 172.25.4.55:/tftpboot/powerpc/ /mnt/nfs.
Did you run the ELDK_MAKEDEV and ELDK_FIXOWNER sripts as documented
in section "7. Mounting Target Components via NFS" ?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
You're too beautiful to ignore. Too much woman.
-- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: module-init-tools 0.9.3 -- "missing" issue
From: Rusty Russell @ 2002-12-11 0:35 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: linux-kernel
In-Reply-To: <3DF67878.6090703@oracle.com>
In message <3DF67878.6090703@oracle.com> you write:
> Rusty Russell wrote:
> > 5) If you want to hack on the source:
> > aclocal && automake --add-missing --copy && autoconf
> to modprobe vfat - but not the full irda stack, I'll report this
> separately to Jean) _and_ on 2.4.20 (modular IrDA and PPP are
I'd appreciate receiving a copy of that irda report. It's probably
not Jean's fault.
Thanks,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: Is this going to be true ?
From: Michael Melanson @ 2002-12-11 0:33 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <058f01c2a09a$7b9dc4a0$9c094d8e@wcom.ca>
Didn't they support an "Unix subsystem" on older versions of NT, to emulate
console Unix apps? I seem to remember something about a that a while ago.
-----------------------------------------
Michael Melanson
ve3mtm@rac.ca
73 33
----- Original Message -----
From: "Serge Kuznetsov" <serge@wcom.ca>
To: "Herman Oosthuysen" <Herman@WirelessNetworksInc.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Tuesday, December 10, 2002 5:21 PM
Subject: Re: Is this going to be true ?
>
>
> > Probably not true, since MS doesn't like the GPL. However, MS may
> > release *nix applications any time they want to. Way back in
> > prehistory, they did supply unix applications and currently
>
> Are you saying about Xenix? I remember M$ supports it in late '80s.
>
> All the Best!
> Serge.
> -
> 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: IDE feature request & problem
From: Manish Lachwani @ 2002-12-11 0:29 UTC (permalink / raw)
To: 'Milan Roubal ', Manish Lachwani
Cc: 'linux-kernel@vger.kernel.org '
SMART data looks clean.
Thanks
Manish
-----Original Message-----
From: Milan Roubal
To: Manish Lachwani
Cc: linux-kernel@vger.kernel.org
Sent: 12/10/02 4:13 PM
Subject: Re: IDE feature request & problem
Hi,
here it is from one good drive. When I removed that two disks, I am sure
there was
No Errors Logged at the end of the list, I will send details tommorow
when I
connect
them back inside the computer.
Milan
Device: WDC WD1200JB-00DUA0 Supports ATA Version 6
Drive supports S.M.A.R.T. and is enabled
Check S.M.A.R.T. Passed
General Smart Values:
Off-line data collection status: (0x82) Offline data collection activity
completed without error
Self-test execution status: ( 0) The previous self-test routine
completed
without error or no self-test
has
ever
been run
Total time to complete off-line
data collection: (4668) Seconds
Offline data collection
Capabilities: (0x7b) SMART EXECUTE OFF-LINE IMMEDIATE
Automatic timer ON/OFF support
Suspend Offline Collection upon
new
command
Offline surface scan supported
Self-test supported
Smart Capablilities: (0x0003) Saves SMART data before entering
power-saving mode
Supports SMART auto save timer
Error logging capability: (0x01) Error logging supported
Short self-test routine
recommended polling time: ( 2) Minutes
Extended self-test routine
recommended polling time: ( 61) Minutes
Vendor Specific SMART Attributes with Thresholds:
Revision Number: 16
Attribute Flag Value Worst Threshold Raw Value
( 1)Raw Read Error Rate 0x000b 200 200 051 000000000000
( 3)Spin Up Time 0x0007 253 253 021 00000000161a
( 4)Start Stop Count 0x0032 100 100 040 000000000000
( 5)Reallocated Sector Ct 0x0033 200 200 140 000000000000
( 7)Seek Error Rate 0x000b 200 200 051 000000000000
( 9)Power On Hours 0x0032 099 099 000 000000000435
( 10)Spin Retry Count 0x0013 100 253 051 000000000000
( 11)Unknown Attribute 0x0013 100 253 051 000000000000
( 12)Power Cycle Count 0x0032 100 100 000 000000000000
(196)Reallocated Event Count 0x0032 200 200 000 000000000000
(197)Current Pending Sector 0x0012 200 200 000 000000000000
(198)Offline Uncorrectable 0x0012 200 200 000 000000000000
(199)UDMA CRC Error Count 0x000a 200 253 000 000000000000
(200)Unknown Attribute 0x0009 200 200 051 000000000000
SMART Error Log:
SMART Error Logging Version: 1
No Errors Logged
----- Original Message -----
From: "Manish Lachwani" <manish@Zambeel.com>
To: "'Milan Roubal'" <roubm9am@barbora.ms.mff.cuni.cz>; "Petr Sebor"
<petr@scssoft.com>; "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: <linux-kernel@vger.kernel.org>
Sent: Tuesday, December 10, 2002 8:50 PM
Subject: RE: IDE feature request & problem
> Can you also send the SMART data of the drive using smartctl?
>
> Thanks
> Manish
>
> -----Original Message-----
> From: Milan Roubal [mailto:roubm9am@barbora.ms.mff.cuni.cz]
> Sent: Tuesday, December 10, 2002 7:08 AM
> To: Petr Sebor; Alan Cox
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: IDE feature request & problem
>
>
> Wow, GREAT!, its really working :)) Thanx a lot.
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0x3020-0x3027,0x3016 on irq 48
> ide3 at 0x3018-0x301f,0x3012 on irq 48
> ide4 at 0x5040-0x5047,0x5036 on irq 96
> ide7 at 0x5050-0x5057,0x504a on irq 100
> ide8 at 0x5070-0x5077,0x5066 on irq 104
> ide9 at 0x5068-0x506f,0x5062 on irq 104
> idea at 0x6020-0x6027,0x6016 on irq 72
> ideb at 0x6018-0x601f,0x6012 on irq 72
>
> I have got another problem. In my log I have got this messages.
> My disks are WDC WD1200JB-00DUA0, ATA DISK drive
> The problem is that utility from Western Digital marks this fault
disks
> ok - so where should I look for problem? Thanx a lot. Milan
> Nov 28 17:54:04 fileserver kernel: hdn: dma_intr: status=0x11 {
SeekComplete
> Error }
> Nov 28 17:54:04 fileserver kernel: hdn: dma_intr: error=0x04 {
> DriveStatusError }
> Nov 28 17:54:04 fileserver kernel: hdn: status error: status=0x11 {
> SeekComplete Error }
> Nov 28 17:54:04 fileserver kernel: hdn: status error: error=0x04 {
> DriveStatusError }
> Nov 28 17:54:04 fileserver kernel: hdn: drive not ready for command
> Nov 28 17:54:04 fileserver kernel: hdn: status error: status=0x11 {
> SeekComplete Error }
> Nov 28 17:54:04 fileserver kernel: hdn: status error: error=0x04 {
> DriveStatusError }
> Nov 28 17:54:04 fileserver kernel: hdn: drive not ready for command
> Nov 28 17:54:04 fileserver kernel: hdn: status error: status=0x11 {
> SeekComplete Error }
> Nov 28 17:54:04 fileserver kernel: hdn: status error: error=0x04 {
> DriveStatusError }
> Nov 28 17:54:04 fileserver kernel: hdn: DMA disabled
> Nov 28 17:54:04 fileserver kernel: PDC202XX: Primary channel reset.
> Nov 28 17:54:04 fileserver kernel: hdn: drive not ready for command
> Nov 28 17:54:04 fileserver kernel: klogd 1.4.1, ---------- state
> change ----------
> Nov 28 17:54:04 fileserver kernel: Inspecting /boot/System.map
> Nov 28 17:54:04 fileserver kernel: Symbol table has incorrect version
> number.
> Nov 28 17:54:04 fileserver kernel: Cannot find map file.
> Nov 28 17:54:04 fileserver kernel: Loaded 489 symbols from 13 modules.
> Nov 28 17:54:04 fileserver kernel: ide6: reset: master: error (0x7f?)
> Nov 28 17:54:14 fileserver kernel: hdn: lost interrupt
> Nov 28 17:54:14 fileserver kernel: hdn: set_multmode: status=0x7f {
> DriveReady DeviceFault SeekComplete DataRequest CorrectedError Index
Error }
> Nov 28 17:54:14 fileserver kernel: hdn: set_multmode: error=0x7f {
> DriveStatusError UncorrectableError SectorIdNotFound TrackZeroNotFound
> AddrMarkNotFound }, LBAsect=8830595334015, high=526344, low=8355711,
> sector=196817664
> Nov 28 17:54:24 fileserver kernel: hdn: lost interrupt
> Nov 28 17:54:24 fileserver kernel: hdn: recal_intr: status=0x7f {
DriveReady
> DeviceFault SeekComplete DataRequest CorrectedError Index Error }
> Nov 28 17:54:24 fileserver kernel: hdn: recal_intr: error=0x7f {
> DriveStatusError UncorrectableError SectorIdNotFound TrackZeroNotFound
> AddrMarkNotFound }, LBAsect=8830595334015, high=526344, low=8355711,
> sector=196817664
> Nov 28 17:54:24 fileserver kernel: PDC202XX: Primary channel reset.
> Nov 28 17:54:24 fileserver kernel: ide6: reset: master: error (0x7f?)
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817664
> Nov 28 17:54:24 fileserver kernel: raid5: Disk failure on hdn1,
disabling
> device. Operation continuing on 8 devices
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817672
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817680
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817688
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817696
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817704
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817712
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817720
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817728
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817736
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817744
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817752
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817760
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817768
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817776
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817784
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817792
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817800
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817808
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817816
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817824
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817832
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817840
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817848
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817856
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817864
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817872
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817880
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817888
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817896
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817904
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817912
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817920
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817928
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817936
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817944
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817952
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817960
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817968
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817976
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817984
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817992
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818000
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818008
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818016
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818024
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818032
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818040
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818048
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818056
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818064
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818072
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818080
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818088
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818096
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818104
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818112
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818120
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818128
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818136
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818144
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818152
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818160
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818168
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818176
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818184
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818192
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818200
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818208
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818216
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818224
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818232
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818240
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818248
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818256
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818264
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818272
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818280
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818288
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818296
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818304
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818312
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818320
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818328
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818336
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818344
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818352
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818360
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818368
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818376
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818384
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818392
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818400
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818408
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818416
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818424
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818432
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818440
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818448
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818456
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818464
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818472
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818480
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818488
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818496
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818504
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818512
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818520
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818528
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818536
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818544
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818552
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818560
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818568
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818576
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818584
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818592
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818600
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818608
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818616
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818624
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818632
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818640
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818648
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818656
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818664
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818672
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818680
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818688
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818696
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818704
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818712
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818720
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818728
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818736
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818744
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818752
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818760
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818768
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818776
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818784
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818792
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818800
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818808
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818816
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818824
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818832
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818840
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818848
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818856
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818864
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818872
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818880
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818888
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818896
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818904
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818912
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818920
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818928
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818936
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818944
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818952
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818960
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818968
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818976
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818984
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818992
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819000
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819008
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819016
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819024
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819032
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819040
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819048
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819056
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819064
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819072
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819080
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819088
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819096
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819104
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819112
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819120
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819128
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819136
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819144
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819152
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819160
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819168
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819176
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819184
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819192
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819200
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819208
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819216
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819224
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819232
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819240
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819248
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819256
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819264
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819272
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819280
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819288
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819296
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819304
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819312
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819320
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819328
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819336
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819344
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819352
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819360
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819368
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819376
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819384
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819392
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819400
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819408
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819416
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819424
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819432
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819440
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819448
>
> Nov 29 11:01:22 fileserver kernel: hdg: dma_intr: status=0x61 {
DriveReady
> DeviceFault Error }
> Nov 29 11:01:22 fileserver kernel: hdg: dma_intr: error=0x04 {
> DriveStatusError }
> Nov 29 11:01:22 fileserver kernel: hdg: DMA disabled
> Nov 29 11:01:22 fileserver kernel: PDC202XX: Secondary channel reset.
> Nov 29 11:01:22 fileserver kernel: ide3: reset: success
> Nov 29 11:01:32 fileserver kernel: hdg: irq timeout: status=0xd0 {
Busy }
> Nov 29 11:01:32 fileserver kernel: PDC202XX: Secondary channel reset.
> Nov 29 11:01:33 fileserver kernel: ide3: reset: success
> Nov 29 11:01:48 fileserver kernel: hdg: irq timeout: status=0xd0 {
Busy }
> Nov 29 11:01:48 fileserver kernel: end_request: I/O error, dev 22:01
(hdg),
> sector 0
> Nov 29 11:01:48 fileserver kernel: raid5: Disk failure on hdg1,
disabling
> device. Operation continuing on 8 devices
> Nov 29 11:01:48 fileserver kernel: hdg: status timeout: status=0xd0 {
Busy }
> Nov 29 11:01:48 fileserver kernel: PDC202XX: Secondary channel reset.
> Nov 29 11:01:48 fileserver kernel: hdg: drive not ready for command
> Nov 29 11:01:48 fileserver kernel: md: updating md0 RAID superblock on
> device
> Nov 29 11:01:48 fileserver kernel: md: hdc1 [events:
00000036]<6>(write)
> hdc1's sb offset: 117220672
> Nov 29 11:01:48 fileserver kernel: md: (skipping faulty hdg1 )
> Nov 29 11:01:48 fileserver kernel: md: hdb1 [events:
00000036]<6>(write)
> hdb1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: hdb1 [events:
00000036]<6>(write)
> hdb1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: hdt1 [events:
00000036]<6>(write)
> hdt1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: hdr1 [events:
00000036]<6>(write)
> hdr1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: hdp1 [events:
00000036]<6>(write)
> hdp1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: (skipping faulty hdn1 )
> Nov 29 11:01:48 fileserver kernel: md: hdj1 [events:
00000036]<6>(write)
> hdj1's sb offset: 117220672
> Nov 29 11:01:48 fileserver kernel: md: hdf1 [events:
00000036]<6>(write)
> hdf1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: recovery thread got woken up
...
> Nov 29 11:01:48 fileserver kernel: md0: no spare disk to reconstruct
> array! -- continuing in degraded mode
> Nov 29 11:01:48 fileserver kernel: md: recovery thread finished ...
> Nov 29 11:01:48 fileserver kernel: ide3: reset: success
> Nov 29 11:01:58 fileserver kernel: hdg: irq timeout: status=0xd0 {
Busy }
> Nov 29 11:01:58 fileserver kernel: PDC202XX: Secondary channel reset.
> Nov 29 11:02:02 fileserver kernel: ide3: reset: success
> Nov 29 11:02:12 fileserver kernel: hdg: irq timeout: status=0xd0 {
Busy }
> Nov 29 11:02:12 fileserver kernel: end_request: I/O error, dev 22:01
(hdg),
> sector 165669889
>
> Part of dmesg:
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
> PIIX4: IDE controller on PCI bus 00 dev f9
> PCI: Enabling device 00:1f.1 (0005 -> 0007)
> PCI: No IRQ known for interrupt pin A of device 00:1f.1. Probably
buggy MP
> table.
> PIIX4: chipset revision 2
> PIIX4: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0x2060-0x2067, BIOS settings: hda:pio, hdb:pio
> ide1: BM-DMA at 0x2068-0x206f, BIOS settings: hdc:pio, hdd:pio
> PDC20269: IDE controller on PCI bus 02 dev 08
> PDC20269: chipset revision 2
> PDC20269: not 100% native mode: will probe irqs later
> ide2: BM-DMA at 0x3000-0x3007, BIOS settings: hde:pio, hdf:pio
> ide3: BM-DMA at 0x3008-0x300f, BIOS settings: hdg:pio, hdh:pio
> PDC20269: IDE controller on PCI bus 05 dev 08
> PDC20269: chipset revision 2
> PDC20269: not 100% native mode: will probe irqs later
> ide4: BM-DMA at 0x5000-0x5007, BIOS settings: hdi:pio, hdj:pio
> ide5: BM-DMA at 0x5008-0x500f, BIOS settings: hdk:pio, hdl:pio
> PDC20269: IDE controller on PCI bus 05 dev 10
> PDC20269: chipset revision 2
> PDC20269: not 100% native mode: will probe irqs later
> ide6: BM-DMA at 0x5010-0x5017, BIOS settings: hdm:pio, hdn:pio
> ide7: BM-DMA at 0x5018-0x501f, BIOS settings: hdo:pio, hdp:pio
> PDC20269: IDE controller on PCI bus 05 dev 18
> PDC20269: chipset revision 2
> PDC20269: not 100% native mode: will probe irqs later
> ide8: BM-DMA at 0x5020-0x5027, BIOS settings: hdq:pio, hdr:pio
> ide9: BM-DMA at 0x5028-0x502f, BIOS settings: hds:pio, hdt:pio
> PDC20269: IDE controller on PCI bus 06 dev 08
> PDC20269: chipset revision 2
> PDC20269: not 100% native mode: will probe irqs later
> idea: BM-DMA at 0x6000-0x6007, BIOS settings: hdu:pio, hdv:pio
> ideb: BM-DMA at 0x6008-0x600f, BIOS settings: hdw:pio, hdx:pio
> hda: ST340016A, ATA DISK drive
> keyboard: Timeout - AT keyboard not present?(ed)
> hdc: WDC WD1200JB-75CRA0, ATA DISK drive
> keyboard: Timeout - AT keyboard not present?(f4)
> hdf: WDC WD1200JB-00DUA0, ATA DISK drive
> hdg: WDC WD1200JB-00DUA0, ATA DISK drive
> hdj: WDC WD1200JB-00DUA0, ATA DISK drive
> hdp: WDC WD1200JB-00DUA0, ATA DISK drive
> hdr: WDC WD1200JB-00DUA0, ATA DISK drive
> hdt: WDC WD1200JB-00DUA0, ATA DISK drive
> hdv: WDC WD1200JB-00DUA0, ATA DISK drive
> hdx: WDC WD1200JB-00DUA0, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0x3020-0x3027,0x3016 on irq 48
> ide3 at 0x3018-0x301f,0x3012 on irq 48
> ide4 at 0x5040-0x5047,0x5036 on irq 96
> ide7 at 0x5050-0x5057,0x504a on irq 100
> ide8 at 0x5070-0x5077,0x5066 on irq 104
> ide9 at 0x5068-0x506f,0x5062 on irq 104
> idea at 0x6020-0x6027,0x6016 on irq 72
> ideb at 0x6018-0x601f,0x6012 on irq 72
>
^ permalink raw reply
* Re: 2.5.51 don't compil with dvb
From: Alan Cox @ 2002-12-11 1:04 UTC (permalink / raw)
To: Rusty Russell; +Cc: greg, Linux Kernel Mailing List, linux-dvb
In-Reply-To: <20021211105343.4385029a.rusty@rustcorp.com.au>
On Tue, 2002-12-10 at 23:53, Rusty Russell wrote:
> On 10 Dec 2002 16:05:15 +0000
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> > On Tue, 2002-12-10 at 15:07, Gregoire Favre wrote:
> > > drivers/built-in.o(.text+0x38655): In function `try_attach_device':
> > > : undefined reference to `MOD_CAN_QUERY'
> > > make: *** [vmlinux] Error 1
> > >
> >
> > Modules are still very broken in 2.5.51, its best to compile a system
> > which doesn't use modules or stay at an older kernel
>
> That may be true, but in this case, it's the only occurrance of MOD_CAN_QUERY
> outside the archs which haven't been updated to the new module loader yet,
> and it's a very odd thing to do.
>
> I assume the author meant this:
That looks right to me yes
^ permalink raw reply
* Re: IDE feature request & problem
From: Milan Roubal @ 2002-12-11 0:24 UTC (permalink / raw)
To: Alan Cox; +Cc: Petr Sebor, Linux Kernel Mailing List
In-Reply-To: <1039540202.14251.43.camel@irongate.swansea.linux.org.uk>
Hi Alan,
I have got xfs partition and man fsck.xfs say
that it will run automatically on reboot.
I don't know where to find any results of the
test, because in syslog is only
SGI XFS with ACLs, DMAPI, realtime, quota, no debug enabled
XFS mounting filesystem md(9,0)
Thanx for help
Milan
----- Original Message -----
From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
To: "Milan Roubal" <roubm9am@barbora.ms.mff.cuni.cz>
Cc: "Petr Sebor" <petr@scssoft.com>; "Linux Kernel Mailing List"
<linux-kernel@vger.kernel.org>
Sent: Tuesday, December 10, 2002 6:10 PM
Subject: Re: IDE feature request & problem
> On Tue, 2002-12-10 at 15:07, Milan Roubal wrote:
> > DriveStatusError UncorrectableError SectorIdNotFound TrackZeroNotFound
> > AddrMarkNotFound }, LBAsect=8830595334015, high=526344, low=8355711,
> > sector=196817664
>
> Can you force an fsck of the volume firstly. AddrMark not found isnt too
> nreasonable a compliant given the LBAsect in question
>
^ permalink raw reply
* Re: buffer head read/write
From: Bryan Henderson @ 2002-12-11 0:19 UTC (permalink / raw)
To: David Chow; +Cc: linux-fsdevel, Neil Brown
In-Reply-To: <3DF60083.2010101@shaolinmicro.com>
>I know how to make a call to general_make_request() but
>wait for the buffer to complete which is too slow.
>If I am doing a continuous sychronous read/write ..., can I put those
"dirty
>buffers"/"non-up-to-date buffers" in the head of the buffer queue so
>that they get written by their respective handler immediately?
"immediately" in computer systems normally means "while I wait" rather than
"before doing anything else." That's why you got a bunch of answers that
weren't what you were looking for.
What you want is a way to assign priority to a block I/O request, so that
a particular one gets executed first regardless of other factors, like
that it's a mile away from where the head is now or 100 other requests
came in before it. There's no way to do priority in today's block I/O
layer.
Incidentally, this has nothing to do with the buffer cache. The queue in
question is for all I/O to a block device; it is below the buffer cache.
^ permalink raw reply
* [RFC][PATCH] linux-2.4.20-pre1_cyclone-timer_B3
From: john stultz @ 2002-12-11 0:21 UTC (permalink / raw)
To: marcelo; +Cc: lkml
Marcelo, All,
This patch fixes gettimeofday for multi-node Summit based systems (IBM
x440, etc). These systems suffer from TSC skew, and thus require an
alternate high res time source. This patch allows do_gettimeofday to
access a register on the cyclone chip found on these systems, which
functions as a global time source.
Please consider for acceptance.
thanks
-john
diff -Nru a/arch/i386/config.in b/arch/i386/config.in
--- a/arch/i386/config.in Tue Dec 10 16:11:18 2002
+++ b/arch/i386/config.in Tue Dec 10 16:11:18 2002
@@ -231,9 +231,11 @@
fi
fi
-bool 'Unsynced TSC support' CONFIG_X86_TSC_DISABLE
-if [ "$CONFIG_X86_TSC_DISABLE" != "y" -a "$CONFIG_X86_HAS_TSC" = "y" ]; then
- define_bool CONFIG_X86_TSC y
+if [ "$CONFIG_X86_NUMA" != "y" ]; then
+ bool 'Unsynced TSC support' CONFIG_X86_TSC_DISABLE
+ if [ "$CONFIG_X86_TSC_DISABLE" != "y" -a "$CONFIG_X86_HAS_TSC" = "y" ]; then
+ define_bool CONFIG_X86_TSC y
+ fi
fi
if [ "$CONFIG_SMP" = "y" -a "$CONFIG_X86_CMPXCHG" = "y" ]; then
diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c Tue Dec 10 16:11:18 2002
+++ b/arch/i386/kernel/time.c Tue Dec 10 16:11:18 2002
@@ -256,12 +256,177 @@
static unsigned long (*do_gettimeoffset)(void) = do_slow_gettimeoffset;
+
+/* IBM Summit (EXA) Cyclone Timer code*/
+#ifdef CONFIG_X86_SUMMIT
+
+#define CYCLONE_CBAR_ADDR 0xFEB00CD0
+#define CYCLONE_PMCC_OFFSET 0x51A0
+#define CYCLONE_MPMC_OFFSET 0x51D0
+#define CYCLONE_MPCS_OFFSET 0x51A8
+#define CYCLONE_TIMER_FREQ 100000000
+
+int use_cyclone = 0;
+int __init cyclone_setup(char *str)
+{
+ use_cyclone = 1;
+ return 1;
+}
+
+static u32* volatile cyclone_timer; /* Cyclone MPMC0 register */
+static u32 last_cyclone_timer;
+
+static inline void mark_timeoffset_cyclone(void)
+{
+ int count;
+ spin_lock(&i8253_lock);
+ /* quickly read the cyclone timer */
+ if(cyclone_timer)
+ last_cyclone_timer = cyclone_timer[0];
+
+ /* calculate delay_at_last_interrupt */
+ outb_p(0x00, 0x43); /* latch the count ASAP */
+
+ count = inb_p(0x40); /* read the latched count */
+ count |= inb(0x40) << 8;
+ spin_unlock(&i8253_lock);
+
+ count = ((LATCH-1) - count) * TICK_SIZE;
+ delay_at_last_interrupt = (count + LATCH/2) / LATCH;
+}
+
+static unsigned long do_gettimeoffset_cyclone(void)
+{
+ u32 offset;
+
+ if(!cyclone_timer)
+ return delay_at_last_interrupt;
+
+ /* Read the cyclone timer */
+ offset = cyclone_timer[0];
+
+ /* .. relative to previous jiffy */
+ offset = offset - last_cyclone_timer;
+
+ /* convert cyclone ticks to microseconds */
+ /* XXX slow, can we speed this up? */
+ offset = offset/(CYCLONE_TIMER_FREQ/1000000);
+
+ /* our adjusted time offset in microseconds */
+ return delay_at_last_interrupt + offset;
+}
+
+static void __init init_cyclone_clock(void)
+{
+ u32* reg;
+ u32 base; /* saved cyclone base address */
+ u32 pageaddr; /* page that contains cyclone_timer register */
+ u32 offset; /* offset from pageaddr to cyclone_timer register */
+ int i;
+
+ printk(KERN_INFO "Summit chipset: Starting Cyclone Counter.\n");
+
+ /* find base address */
+ pageaddr = (CYCLONE_CBAR_ADDR)&PAGE_MASK;
+ offset = (CYCLONE_CBAR_ADDR)&(~PAGE_MASK);
+ set_fixmap_nocache(FIX_CYCLONE_TIMER, pageaddr);
+ reg = (u32*)(fix_to_virt(FIX_CYCLONE_TIMER) + offset);
+ if(!reg){
+ printk(KERN_ERR "Summit chipset: Could not find valid CBAR register.\n");
+ use_cyclone = 0;
+ return;
+ }
+ base = *reg;
+ if(!base){
+ printk(KERN_ERR "Summit chipset: Could not find valid CBAR value.\n");
+ use_cyclone = 0;
+ return;
+ }
+
+ /* setup PMCC */
+ pageaddr = (base + CYCLONE_PMCC_OFFSET)&PAGE_MASK;
+ offset = (base + CYCLONE_PMCC_OFFSET)&(~PAGE_MASK);
+ set_fixmap_nocache(FIX_CYCLONE_TIMER, pageaddr);
+ reg = (u32*)(fix_to_virt(FIX_CYCLONE_TIMER) + offset);
+ if(!reg){
+ printk(KERN_ERR "Summit chipset: Could not find valid PMCC register.\n");
+ use_cyclone = 0;
+ return;
+ }
+ reg[0] = 0x00000001;
+
+ /* setup MPCS */
+ pageaddr = (base + CYCLONE_MPCS_OFFSET)&PAGE_MASK;
+ offset = (base + CYCLONE_MPCS_OFFSET)&(~PAGE_MASK);
+ set_fixmap_nocache(FIX_CYCLONE_TIMER, pageaddr);
+ reg = (u32*)(fix_to_virt(FIX_CYCLONE_TIMER) + offset);
+ if(!reg){
+ printk(KERN_ERR "Summit chipset: Could not find valid MPCS register.\n");
+ use_cyclone = 0;
+ return;
+ }
+ reg[0] = 0x00000001;
+
+ /* map in cyclone_timer */
+ pageaddr = (base + CYCLONE_MPMC_OFFSET)&PAGE_MASK;
+ offset = (base + CYCLONE_MPMC_OFFSET)&(~PAGE_MASK);
+ set_fixmap_nocache(FIX_CYCLONE_TIMER, pageaddr);
+ cyclone_timer = (u32*)(fix_to_virt(FIX_CYCLONE_TIMER) + offset);
+ if(!cyclone_timer){
+ printk(KERN_ERR "Summit chipset: Could not find valid MPMC register.\n");
+ use_cyclone = 0;
+ return;
+ }
+
+ /*quick test to make sure its ticking*/
+ for(i=0; i<3; i++){
+ u32 old = cyclone_timer[0];
+ int stall = 100;
+ while(stall--) barrier();
+ if(cyclone_timer[0] == old){
+ printk(KERN_ERR "Summit chipset: Counter not counting! DISABLED\n");
+ cyclone_timer = 0;
+ use_cyclone = 0;
+ return;
+ }
+ }
+ /* Everything looks good, so set do_gettimeoffset */
+ do_gettimeoffset = do_gettimeoffset_cyclone;
+}
+void __cyclone_delay(unsigned long loops)
+{
+ unsigned long bclock, now;
+ if(!cyclone_timer)
+ return;
+ bclock = cyclone_timer[0];
+ do {
+ rep_nop();
+ now = cyclone_timer[0];
+ } while ((now-bclock) < loops);
+}
+#endif /* CONFIG_X86_SUMMIT */
+
#else
#define do_gettimeoffset() do_fast_gettimeoffset()
#endif
+/* No-cyclone stubs */
+#ifndef CONFIG_X86_SUMMIT
+int __init cyclone_setup(char *str)
+{
+ printk(KERN_ERR "cyclone: Kernel not compiled with CONFIG_X86_SUMMIT, cannot use the cyclone-timer.\n");
+ return 1;
+}
+
+const int use_cyclone = 0;
+static void mark_timeoffset_cyclone(void) {}
+static unsigned long do_gettimeoffset_cyclone(void) {return 0;}
+static void init_cyclone_clock(void) {}
+void __cyclone_delay(unsigned long loops) {}
+#endif /* CONFIG_X86_SUMMIT */
+
/*
* This version of gettimeofday has microsecond resolution
* and better than microsecond precision on fast x86 machines with TSC.
@@ -481,8 +646,9 @@
*/
write_lock(&xtime_lock);
- if (use_tsc)
- {
+ if(use_cyclone)
+ mark_timeoffset_cyclone();
+ else if (use_tsc) {
/*
* It is important that these two operations happen almost at
* the same time. We do the RDTSC stuff first, since it's
@@ -531,7 +697,7 @@
count = ((LATCH-1) - count) * TICK_SIZE;
delay_at_last_interrupt = (count + LATCH/2) / LATCH;
}
-
+
do_timer_interrupt(irq, NULL, regs);
write_unlock(&xtime_lock);
@@ -692,21 +858,30 @@
*/
dodgy_tsc();
-
+
+ if(use_cyclone)
+ init_cyclone_clock();
+
if (cpu_has_tsc) {
unsigned long tsc_quotient = calibrate_tsc();
if (tsc_quotient) {
fast_gettimeoffset_quotient = tsc_quotient;
- use_tsc = 1;
- /*
- * We could be more selective here I suspect
- * and just enable this for the next intel chips ?
+ /* XXX: This is messy
+ * However, we want to allow for the cyclone timer
+ * to work w/ or w/o the TSCs being avaliable
+ * -johnstul@us.ibm.com
*/
- x86_udelay_tsc = 1;
+ if(!use_cyclone){
+ /*
+ * We could be more selective here I suspect
+ * and just enable this for the next intel chips ?
+ */
+ use_tsc = 1;
+ x86_udelay_tsc = 1;
#ifndef do_gettimeoffset
- do_gettimeoffset = do_fast_gettimeoffset;
+ do_gettimeoffset = do_fast_gettimeoffset;
#endif
-
+ }
/* report CPU clock rate in Hz.
* The formula is (10^6 * 2^32) / (2^32 * 1 / (clocks/us)) =
* clock/second. Our precision is about 100 ppm.
@@ -720,6 +895,7 @@
}
}
}
+
#ifdef CONFIG_VISWS
printk("Starting Cobalt Timer system clock\n");
diff -Nru a/arch/i386/lib/delay.c b/arch/i386/lib/delay.c
--- a/arch/i386/lib/delay.c Tue Dec 10 16:11:18 2002
+++ b/arch/i386/lib/delay.c Tue Dec 10 16:11:18 2002
@@ -56,10 +56,13 @@
:"=&a" (d0)
:"0" (loops));
}
-
+extern __cyclone_delay(unsigned long loops);
+extern int use_cyclone;
void __delay(unsigned long loops)
{
- if (x86_udelay_tsc)
+ if (use_cyclone)
+ __cyclone_delay(loops);
+ else if (x86_udelay_tsc)
__rdtsc_delay(loops);
else
__loop_delay(loops);
diff -Nru a/include/asm-i386/fixmap.h b/include/asm-i386/fixmap.h
--- a/include/asm-i386/fixmap.h Tue Dec 10 16:11:18 2002
+++ b/include/asm-i386/fixmap.h Tue Dec 10 16:11:18 2002
@@ -64,6 +64,9 @@
#ifndef CONFIG_X86_F00F_WORKS_OK
FIX_F00F,
#endif
+#ifdef CONFIG_X86_SUMMIT
+ FIX_CYCLONE_TIMER, /*cyclone timer register*/
+#endif
#ifdef CONFIG_HIGHMEM
FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
diff -Nru a/include/asm-i386/smpboot.h b/include/asm-i386/smpboot.h
--- a/include/asm-i386/smpboot.h Tue Dec 10 16:11:18 2002
+++ b/include/asm-i386/smpboot.h Tue Dec 10 16:11:18 2002
@@ -14,6 +14,8 @@
extern unsigned char esr_disable;
extern unsigned char int_delivery_mode;
extern unsigned int int_dest_addr_mode;
+extern int cyclone_setup(char*);
+
static inline void detect_clustered_apic(char* oem, char* prod)
{
/*
@@ -25,6 +27,8 @@
int_dest_addr_mode = APIC_DEST_PHYSICAL;
int_delivery_mode = dest_Fixed;
esr_disable = 1;
+ /*Start cyclone clock*/
+ cyclone_setup(0);
}
else if (!strncmp(oem, "IBM NUMA", 8)){
clustered_apic_mode = CLUSTERED_APIC_NUMAQ;
^ permalink raw reply
* Re: [RFC] countdown timer driver
From: george anzinger @ 2002-12-11 0:19 UTC (permalink / raw)
To: Dan Kegel; +Cc: Daniel.Heater, linux-kernel
In-Reply-To: <3DF54765.2020505@ixiacom.com>
Dan Kegel wrote:
>
> > Questions:
> > 1. Is there already a standard kernel interface to this type of timer?
>
> The Posix high-res timer stuff, I think. Have you tried expressing
> what you want user programs to do in terms of Posix high-res timers yet?
>
> > 2. Is there any reason to interface/integrate this type of device with the
> > high-res timer stuff currently under development for the 2.5 kernel?
>
> Yes; perhaps you could create a service provider interface
> for the posix high-res timer stuff, then use that SPI
> to plug your hardware in?
>
> I may be way off base here, but it does seem like it's due dilligence
> to verify that you're not reinventing an interface here.
> - Dan
>
Let me help out here if I may. First, not to rain on your
parade but, when I did high-res timers on another system,
far away and long ago, we dropped support for the hardware
timers. I.e. I would submit that the POSIX timers interface
to a common system timer does all you need and more. You
MAY want to consider using your hardware as the system clock
underlying jiffies and all the system timers, but that is
another issue.
You also may want to define a new CLOCK for the POSIX
timers. Most of this capability is in place in the current
patch. I did notice, however, that I took a short cut on
the clock_nanosleep code and assumed that it was a standard
clock. This is easy to change... The new CLOCK(s) would
then talk to your hardware. The problem you will encounter,
and which the high-res-patch solves, is making the timers
available to all comers, i.e. there is no reservation system
or busy counter, etc. Just a nice set timer and give me a
signal when it is done.
You can code a blocking interface using the sigwait and
friends calls which will also cut down of the timer delivery
overhead by eliminating the signal.
So what more could you ask for?
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: Board specific info for no EEPROM case
From: Matt Porter @ 2002-12-11 0:10 UTC (permalink / raw)
To: Prakash kanthi; +Cc: linuxppc-embedded
In-Reply-To: <20021210231853.23902.qmail@web41203.mail.yahoo.com>
On Tue, Dec 10, 2002 at 03:18:53PM -0800, Prakash kanthi wrote:
>
> Hi Folks,
>
> I do not have a NVRAM or EEPROM on my board (PPC405
> based). I see that during the linux booting, it is
> trying to read bd_t info from EEPROM and failing. Is
> there an alternative to this problem? Can i hardcode
> the stuff in decompress_kernel method and go ahead?
There are a pile of examples of this very thing in
arch/ppc/boot/simple/embed_config.c. Create an
embed_config() and hardcode your board-specific values
into the bd_t.
Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Complete freeze with 2.4.20 on 4-proc IBM xSeries 350
From: Martin J. Bligh @ 2002-12-11 0:10 UTC (permalink / raw)
To: "Rüegg, Peter H.",
'linux-kernel@vger.kernel.org'
In-Reply-To: <E8EE16A19D69D611B40000D0B73EBB250F06BE@exchange.intern.eproduction.ch>
> I'm experiencing serious problems with Kernel 2.4.20 on a IBM xSeries 350
> machine, having 4 700 MHz processors and 4 GB RAM (same on another machine
> with the same configuration, but only 3 GB RAM). The machine just com-
> pletely freezes after some time, ranging from 20 minutes to 3 hours. It
> is running IBM DB/2 with quite some load, the base system is RedHat 7.2
> with all the updates applied. There is no oops or other fault, just a
> plain freeze.
Can you watch /proc/meminfo and see how low "lowfree" gets?
If it gets low (eg below 50Mb), dump /proc/slabinfo as well.
M.
^ permalink raw reply
* Re: IDE feature request & problem
From: Milan Roubal @ 2002-12-11 0:13 UTC (permalink / raw)
To: Manish Lachwani; +Cc: linux-kernel
In-Reply-To: <233C89823A37714D95B1A891DE3BCE5202AB1B15@xch-a.win.zambeel.com>
Hi,
here it is from one good drive. When I removed that two disks, I am sure
there was
No Errors Logged at the end of the list, I will send details tommorow when I
connect
them back inside the computer.
Milan
Device: WDC WD1200JB-00DUA0 Supports ATA Version 6
Drive supports S.M.A.R.T. and is enabled
Check S.M.A.R.T. Passed
General Smart Values:
Off-line data collection status: (0x82) Offline data collection activity
completed without error
Self-test execution status: ( 0) The previous self-test routine
completed
without error or no self-test has
ever
been run
Total time to complete off-line
data collection: (4668) Seconds
Offline data collection
Capabilities: (0x7b) SMART EXECUTE OFF-LINE IMMEDIATE
Automatic timer ON/OFF support
Suspend Offline Collection upon new
command
Offline surface scan supported
Self-test supported
Smart Capablilities: (0x0003) Saves SMART data before entering
power-saving mode
Supports SMART auto save timer
Error logging capability: (0x01) Error logging supported
Short self-test routine
recommended polling time: ( 2) Minutes
Extended self-test routine
recommended polling time: ( 61) Minutes
Vendor Specific SMART Attributes with Thresholds:
Revision Number: 16
Attribute Flag Value Worst Threshold Raw Value
( 1)Raw Read Error Rate 0x000b 200 200 051 000000000000
( 3)Spin Up Time 0x0007 253 253 021 00000000161a
( 4)Start Stop Count 0x0032 100 100 040 000000000000
( 5)Reallocated Sector Ct 0x0033 200 200 140 000000000000
( 7)Seek Error Rate 0x000b 200 200 051 000000000000
( 9)Power On Hours 0x0032 099 099 000 000000000435
( 10)Spin Retry Count 0x0013 100 253 051 000000000000
( 11)Unknown Attribute 0x0013 100 253 051 000000000000
( 12)Power Cycle Count 0x0032 100 100 000 000000000000
(196)Reallocated Event Count 0x0032 200 200 000 000000000000
(197)Current Pending Sector 0x0012 200 200 000 000000000000
(198)Offline Uncorrectable 0x0012 200 200 000 000000000000
(199)UDMA CRC Error Count 0x000a 200 253 000 000000000000
(200)Unknown Attribute 0x0009 200 200 051 000000000000
SMART Error Log:
SMART Error Logging Version: 1
No Errors Logged
----- Original Message -----
From: "Manish Lachwani" <manish@Zambeel.com>
To: "'Milan Roubal'" <roubm9am@barbora.ms.mff.cuni.cz>; "Petr Sebor"
<petr@scssoft.com>; "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: <linux-kernel@vger.kernel.org>
Sent: Tuesday, December 10, 2002 8:50 PM
Subject: RE: IDE feature request & problem
> Can you also send the SMART data of the drive using smartctl?
>
> Thanks
> Manish
>
> -----Original Message-----
> From: Milan Roubal [mailto:roubm9am@barbora.ms.mff.cuni.cz]
> Sent: Tuesday, December 10, 2002 7:08 AM
> To: Petr Sebor; Alan Cox
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: IDE feature request & problem
>
>
> Wow, GREAT!, its really working :)) Thanx a lot.
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0x3020-0x3027,0x3016 on irq 48
> ide3 at 0x3018-0x301f,0x3012 on irq 48
> ide4 at 0x5040-0x5047,0x5036 on irq 96
> ide7 at 0x5050-0x5057,0x504a on irq 100
> ide8 at 0x5070-0x5077,0x5066 on irq 104
> ide9 at 0x5068-0x506f,0x5062 on irq 104
> idea at 0x6020-0x6027,0x6016 on irq 72
> ideb at 0x6018-0x601f,0x6012 on irq 72
>
> I have got another problem. In my log I have got this messages.
> My disks are WDC WD1200JB-00DUA0, ATA DISK drive
> The problem is that utility from Western Digital marks this fault disks
> ok - so where should I look for problem? Thanx a lot. Milan
> Nov 28 17:54:04 fileserver kernel: hdn: dma_intr: status=0x11 {
SeekComplete
> Error }
> Nov 28 17:54:04 fileserver kernel: hdn: dma_intr: error=0x04 {
> DriveStatusError }
> Nov 28 17:54:04 fileserver kernel: hdn: status error: status=0x11 {
> SeekComplete Error }
> Nov 28 17:54:04 fileserver kernel: hdn: status error: error=0x04 {
> DriveStatusError }
> Nov 28 17:54:04 fileserver kernel: hdn: drive not ready for command
> Nov 28 17:54:04 fileserver kernel: hdn: status error: status=0x11 {
> SeekComplete Error }
> Nov 28 17:54:04 fileserver kernel: hdn: status error: error=0x04 {
> DriveStatusError }
> Nov 28 17:54:04 fileserver kernel: hdn: drive not ready for command
> Nov 28 17:54:04 fileserver kernel: hdn: status error: status=0x11 {
> SeekComplete Error }
> Nov 28 17:54:04 fileserver kernel: hdn: status error: error=0x04 {
> DriveStatusError }
> Nov 28 17:54:04 fileserver kernel: hdn: DMA disabled
> Nov 28 17:54:04 fileserver kernel: PDC202XX: Primary channel reset.
> Nov 28 17:54:04 fileserver kernel: hdn: drive not ready for command
> Nov 28 17:54:04 fileserver kernel: klogd 1.4.1, ---------- state
> change ----------
> Nov 28 17:54:04 fileserver kernel: Inspecting /boot/System.map
> Nov 28 17:54:04 fileserver kernel: Symbol table has incorrect version
> number.
> Nov 28 17:54:04 fileserver kernel: Cannot find map file.
> Nov 28 17:54:04 fileserver kernel: Loaded 489 symbols from 13 modules.
> Nov 28 17:54:04 fileserver kernel: ide6: reset: master: error (0x7f?)
> Nov 28 17:54:14 fileserver kernel: hdn: lost interrupt
> Nov 28 17:54:14 fileserver kernel: hdn: set_multmode: status=0x7f {
> DriveReady DeviceFault SeekComplete DataRequest CorrectedError Index
Error }
> Nov 28 17:54:14 fileserver kernel: hdn: set_multmode: error=0x7f {
> DriveStatusError UncorrectableError SectorIdNotFound TrackZeroNotFound
> AddrMarkNotFound }, LBAsect=8830595334015, high=526344, low=8355711,
> sector=196817664
> Nov 28 17:54:24 fileserver kernel: hdn: lost interrupt
> Nov 28 17:54:24 fileserver kernel: hdn: recal_intr: status=0x7f {
DriveReady
> DeviceFault SeekComplete DataRequest CorrectedError Index Error }
> Nov 28 17:54:24 fileserver kernel: hdn: recal_intr: error=0x7f {
> DriveStatusError UncorrectableError SectorIdNotFound TrackZeroNotFound
> AddrMarkNotFound }, LBAsect=8830595334015, high=526344, low=8355711,
> sector=196817664
> Nov 28 17:54:24 fileserver kernel: PDC202XX: Primary channel reset.
> Nov 28 17:54:24 fileserver kernel: ide6: reset: master: error (0x7f?)
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817664
> Nov 28 17:54:24 fileserver kernel: raid5: Disk failure on hdn1, disabling
> device. Operation continuing on 8 devices
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817672
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817680
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817688
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817696
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817704
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817712
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817720
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817728
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817736
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817744
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817752
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817760
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817768
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817776
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817784
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817792
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817800
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817808
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817816
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817824
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817832
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817840
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817848
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817856
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817864
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817872
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817880
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817888
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817896
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817904
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817912
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817920
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817928
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817936
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817944
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817952
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817960
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817968
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817976
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817984
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196817992
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818000
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818008
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818016
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818024
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818032
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818040
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818048
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818056
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818064
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818072
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818080
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818088
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818096
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818104
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818112
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818120
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818128
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818136
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818144
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818152
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818160
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818168
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818176
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818184
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818192
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818200
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818208
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818216
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818224
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818232
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818240
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818248
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818256
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818264
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818272
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818280
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818288
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818296
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818304
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818312
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818320
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818328
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818336
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818344
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818352
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818360
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818368
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818376
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818384
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818392
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818400
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818408
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818416
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818424
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818432
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818440
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818448
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818456
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818464
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818472
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818480
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818488
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818496
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818504
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818512
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818520
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818528
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818536
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818544
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818552
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818560
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818568
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818576
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818584
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818592
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818600
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818608
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818616
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818624
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818632
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818640
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818648
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818656
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818664
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818672
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818680
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818688
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818696
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818704
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818712
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818720
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818728
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818736
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818744
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818752
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818760
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818768
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818776
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818784
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818792
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818800
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818808
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818816
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818824
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818832
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818840
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818848
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818856
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818864
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818872
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818880
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818888
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818896
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818904
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818912
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818920
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818928
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818936
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818944
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818952
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818960
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818968
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818976
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818984
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196818992
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819000
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819008
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819016
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819024
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819032
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819040
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819048
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819056
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819064
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819072
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819080
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819088
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819096
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819104
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819112
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819120
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819128
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819136
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819144
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819152
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819160
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819168
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819176
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819184
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819192
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819200
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819208
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819216
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819224
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819232
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819240
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819248
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819256
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819264
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819272
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819280
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819288
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819296
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819304
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819312
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819320
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819328
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819336
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819344
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819352
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819360
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819368
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819376
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819384
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819392
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819400
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819408
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819416
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819424
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819432
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819440
> Nov 28 17:54:24 fileserver kernel: end_request: I/O error, dev 58:41
(hdn),
> sector 196819448
>
> Nov 29 11:01:22 fileserver kernel: hdg: dma_intr: status=0x61 { DriveReady
> DeviceFault Error }
> Nov 29 11:01:22 fileserver kernel: hdg: dma_intr: error=0x04 {
> DriveStatusError }
> Nov 29 11:01:22 fileserver kernel: hdg: DMA disabled
> Nov 29 11:01:22 fileserver kernel: PDC202XX: Secondary channel reset.
> Nov 29 11:01:22 fileserver kernel: ide3: reset: success
> Nov 29 11:01:32 fileserver kernel: hdg: irq timeout: status=0xd0 { Busy }
> Nov 29 11:01:32 fileserver kernel: PDC202XX: Secondary channel reset.
> Nov 29 11:01:33 fileserver kernel: ide3: reset: success
> Nov 29 11:01:48 fileserver kernel: hdg: irq timeout: status=0xd0 { Busy }
> Nov 29 11:01:48 fileserver kernel: end_request: I/O error, dev 22:01
(hdg),
> sector 0
> Nov 29 11:01:48 fileserver kernel: raid5: Disk failure on hdg1, disabling
> device. Operation continuing on 8 devices
> Nov 29 11:01:48 fileserver kernel: hdg: status timeout: status=0xd0 {
Busy }
> Nov 29 11:01:48 fileserver kernel: PDC202XX: Secondary channel reset.
> Nov 29 11:01:48 fileserver kernel: hdg: drive not ready for command
> Nov 29 11:01:48 fileserver kernel: md: updating md0 RAID superblock on
> device
> Nov 29 11:01:48 fileserver kernel: md: hdc1 [events: 00000036]<6>(write)
> hdc1's sb offset: 117220672
> Nov 29 11:01:48 fileserver kernel: md: (skipping faulty hdg1 )
> Nov 29 11:01:48 fileserver kernel: md: hdb1 [events: 00000036]<6>(write)
> hdb1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: hdb1 [events: 00000036]<6>(write)
> hdb1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: hdt1 [events: 00000036]<6>(write)
> hdt1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: hdr1 [events: 00000036]<6>(write)
> hdr1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: hdp1 [events: 00000036]<6>(write)
> hdp1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: (skipping faulty hdn1 )
> Nov 29 11:01:48 fileserver kernel: md: hdj1 [events: 00000036]<6>(write)
> hdj1's sb offset: 117220672
> Nov 29 11:01:48 fileserver kernel: md: hdf1 [events: 00000036]<6>(write)
> hdf1's sb offset: 117218176
> Nov 29 11:01:48 fileserver kernel: md: recovery thread got woken up ...
> Nov 29 11:01:48 fileserver kernel: md0: no spare disk to reconstruct
> array! -- continuing in degraded mode
> Nov 29 11:01:48 fileserver kernel: md: recovery thread finished ...
> Nov 29 11:01:48 fileserver kernel: ide3: reset: success
> Nov 29 11:01:58 fileserver kernel: hdg: irq timeout: status=0xd0 { Busy }
> Nov 29 11:01:58 fileserver kernel: PDC202XX: Secondary channel reset.
> Nov 29 11:02:02 fileserver kernel: ide3: reset: success
> Nov 29 11:02:12 fileserver kernel: hdg: irq timeout: status=0xd0 { Busy }
> Nov 29 11:02:12 fileserver kernel: end_request: I/O error, dev 22:01
(hdg),
> sector 165669889
>
> Part of dmesg:
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
> PIIX4: IDE controller on PCI bus 00 dev f9
> PCI: Enabling device 00:1f.1 (0005 -> 0007)
> PCI: No IRQ known for interrupt pin A of device 00:1f.1. Probably buggy MP
> table.
> PIIX4: chipset revision 2
> PIIX4: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0x2060-0x2067, BIOS settings: hda:pio, hdb:pio
> ide1: BM-DMA at 0x2068-0x206f, BIOS settings: hdc:pio, hdd:pio
> PDC20269: IDE controller on PCI bus 02 dev 08
> PDC20269: chipset revision 2
> PDC20269: not 100% native mode: will probe irqs later
> ide2: BM-DMA at 0x3000-0x3007, BIOS settings: hde:pio, hdf:pio
> ide3: BM-DMA at 0x3008-0x300f, BIOS settings: hdg:pio, hdh:pio
> PDC20269: IDE controller on PCI bus 05 dev 08
> PDC20269: chipset revision 2
> PDC20269: not 100% native mode: will probe irqs later
> ide4: BM-DMA at 0x5000-0x5007, BIOS settings: hdi:pio, hdj:pio
> ide5: BM-DMA at 0x5008-0x500f, BIOS settings: hdk:pio, hdl:pio
> PDC20269: IDE controller on PCI bus 05 dev 10
> PDC20269: chipset revision 2
> PDC20269: not 100% native mode: will probe irqs later
> ide6: BM-DMA at 0x5010-0x5017, BIOS settings: hdm:pio, hdn:pio
> ide7: BM-DMA at 0x5018-0x501f, BIOS settings: hdo:pio, hdp:pio
> PDC20269: IDE controller on PCI bus 05 dev 18
> PDC20269: chipset revision 2
> PDC20269: not 100% native mode: will probe irqs later
> ide8: BM-DMA at 0x5020-0x5027, BIOS settings: hdq:pio, hdr:pio
> ide9: BM-DMA at 0x5028-0x502f, BIOS settings: hds:pio, hdt:pio
> PDC20269: IDE controller on PCI bus 06 dev 08
> PDC20269: chipset revision 2
> PDC20269: not 100% native mode: will probe irqs later
> idea: BM-DMA at 0x6000-0x6007, BIOS settings: hdu:pio, hdv:pio
> ideb: BM-DMA at 0x6008-0x600f, BIOS settings: hdw:pio, hdx:pio
> hda: ST340016A, ATA DISK drive
> keyboard: Timeout - AT keyboard not present?(ed)
> hdc: WDC WD1200JB-75CRA0, ATA DISK drive
> keyboard: Timeout - AT keyboard not present?(f4)
> hdf: WDC WD1200JB-00DUA0, ATA DISK drive
> hdg: WDC WD1200JB-00DUA0, ATA DISK drive
> hdj: WDC WD1200JB-00DUA0, ATA DISK drive
> hdp: WDC WD1200JB-00DUA0, ATA DISK drive
> hdr: WDC WD1200JB-00DUA0, ATA DISK drive
> hdt: WDC WD1200JB-00DUA0, ATA DISK drive
> hdv: WDC WD1200JB-00DUA0, ATA DISK drive
> hdx: WDC WD1200JB-00DUA0, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0x3020-0x3027,0x3016 on irq 48
> ide3 at 0x3018-0x301f,0x3012 on irq 48
> ide4 at 0x5040-0x5047,0x5036 on irq 96
> ide7 at 0x5050-0x5057,0x504a on irq 100
> ide8 at 0x5070-0x5077,0x5066 on irq 104
> ide9 at 0x5068-0x506f,0x5062 on irq 104
> idea at 0x6020-0x6027,0x6016 on irq 72
> ideb at 0x6018-0x601f,0x6012 on irq 72
>
^ permalink raw reply
* is not plain file nor directory
From: Wahib Nackad @ 2002-12-11 0:16 UTC (permalink / raw)
To: linux-kernel
Hello,
I'm able to compile kernel 2.4.20 via SRPMS with spec file without problem
as long as I don't enable pcmcia support with the kernel. If I enable pcmcia
support, then compilation fail when the 'make module_install' command runs
and return the following error message for each pcmcia drivers:
depmod:
/var/tmp/kernel-2.4.20-root/lib/modules/2.4.20-1/pcmcia/xircom_tulip_cb.o is
not plain file nor directory
The /var/tmp/kernel-2.4.20-root/lib/modules/2.4.20-1/pcmcia is a directory
created by the 'make module_install' command with all pcmcia drivers made as
symbolic link inside it. Those symbolic links point to the right
subdirectory under the kernel directory but it seem to me that the system or
something else do not want to follow the symbolic link and this is why I
receive the "is not plain file nor directory" error.
Can someone exlain me how to fix this?
Thanks a lot.
W
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
http://join.msn.com/?page=features/virus
^ permalink raw reply
* Re: RFC - new raid superblock layout for md driver
From: Neil Brown @ 2002-12-11 0:07 UTC (permalink / raw)
To: Kenneth D. Merry; +Cc: Anton Altaparmakov, linux-kernel, linux-raid
In-Reply-To: <20021209232856.A47324@panzer.kdm.org>
On Monday December 9, ken@kdm.org wrote:
> On Mon, Dec 09, 2002 at 14:52:11 +1100, Neil Brown wrote:
> > > - Enough per-disk state so you can determine, if you're doing a resync or
> > > reconstruction, which disk is the target of the operation. When I was
> > > doing a lot of work on md a while back, one of the things I ran into is
> > > that when you do a resync of a RAID-1, it always resyncs from the first
> > > to the second disk, even if the first disk is the one out of sync. (I
> > > changed this, with Adaptec metadata at least, so it would resync onto
> > > the correct disk.)
> >
> > When a raid1 array is out of sync, it doesn't mean anything to say
> > which disc is out of sync. They all are, with each other...
> > Nonetheless, the per-device stateflags have an 'in-sync' bit which can
> > be set or cleared as appropriate.
>
> This sort of information (if it is used) would be very useful for dealing
> with Adaptec metadata. Adaptec HostRAID adapters let you build a RAID-1 by
> copying one disk onto the other, with the state set to indicate the source
> and target disks.
>
> Since the BIOS on those adapters takes a long time to do a copy, it's
> easier to break out of the build after it gets started, and let the kernel
> pick back up where the BIOS left off. To do that, you need checkpointing
> support (i.e. be able to figure out where we left off with a particular
> operation) and you need to be able to determine which disk is the source
> and which is the target.
>
> To do this with the first set of Adaptec metadata patches I wrote for
> md, I had to kinda "bolt on" some extra state in the kernel, so I could
> figure out which disk was the target, since md doesn't really pay attention
> to the current per-disk in sync flags.
The way to solve this that would be most in-keeping with the raid code
in 2.4 would be for the drives that were not yet in-sync to appear as
'spare' drives. On array assembly, the first spare would get rebuilt
by md and then fully incorporated into the array. I agree that this is
not a very good conceptual fit.
The 2.5 code is a lot tidier with respect to this. Each device has an
'in-sync' flag so when an array has a missing drive, a spare is added
and marked not-in-sync. When recovery finishes, the drive that was
spare has the in-sync flag set.
2.5 code has an insync flag to, but it is not used sensibly.
Note that this relates to a drive being out-of-sync (as in a
reconstruction or recovery operation). It is quite different to the
array being out-of-sync which requires a resync operation.
> > >
> > > If each disk had a list of the uuids of every disk in the array,
> > > you could tell from the disk table on the "freshest" disk that
> > > the disk the user stuck back in isn't part of the array, despite
> > > the fact that it claims to be. (It was at one point, and then
> > > was removed.) You can then make the user add it back explicitly,
> > > instead of just resyncing onto it.
> >
> > The event counter is enough to determine if a device is really part of
> > the current array or not, and I cannot see why you need more than
> > that.
> > As far as I can tell, everything that you have said can be achieved
> > with setuid/devnumber/event.
>
> It'll work with just the setuuid/devnumber/event, but as I mentioned in the
> last paragraph above, you'll end up resyncing onto the disk that is pulled
> and then reinserted, because you don't really have any way of knowing it is
> no longer a part of the array. All you know is that it is out of
> date.
If you pull drive N, then it will appear to fail and all other drives
will be marked to say that 'drive N is faulty'.
If you plug drive N back in, the md code simply wont notice.
If you tell it to 'hot-add' the drive, it will rebuild onto it, but
that is what you asked to do.
If you shut down and restart, the auto-detection may well find drive
N, but even if it's event number is sufficiently recent (which would
require an unclean shutdown of the array), the fact that the most
recent superblocks will say that drive N is failed will mean that it
doesn't get incorporated into the array. You still have to explicitly
hot-add it before it will resync.
I still don't see the problem, sorry.
>
> > > - Possibly the ability to setup multilevel arrays within a given piece of
> > > metadata. As far as multilevel arrays go, there are two basic
> > > approaches to the metadata:
> >
> > How many actual uses of multi-level arrays are there??
> >
> > The most common one is raid0 over raid1, and I think there is a strong
> > case for implementing a 'raid10' module that does that, but also
> > allows a raid10 of an odd number of drives and things like that.
>
> RAID-10 is the most common, but RAID-50 is found in the "wild" as well.
>
> It would be more flexible if you could stack personalities on top of each
> other. This would give people the option of combining whatever
> personalities they want (within reason; the multipath personality doesn't
> make a whole lot of sense to stack).
>
> > I don't think anything else is sufficiently common to really deserve
> > special treatment: recursive metadata is adequate I think.
>
> Recursive metadata is fine, but I would encourage you to think about how
> you would (structurally) support multilevel arrays that use integrated
> metadata. (e.g. like RAID-10 on an Adaptec HostRAID board)
How about this:
Option 1:
Assertion: The only sensible raid stacks involve two levels: A
level that provides redundancy (Raid1/raid5) on the bottom, and a
level that compbines capacity on the top (raid0/linear).
Observation: in-kernel knowledge of superblock is only needed for
levels that provide redundancy (raid1/raid5) and so need to
update to superblock after errors, etc. raid0/linear can
be managed fine without any in-kernel knowledge of superblocks.
Approach:
Teach the kernel to read your adaptec raid10 superblock and
present it to md as N separate raid1 arrays.
Have a user-space tool that assembles the array as follows:
1/ read the superblocks
2/ build the raid1 arrays
3/ build the raid0 on-top using non-persistant superblocks.
There may need to be small changes to the md code to make this work
properly, but I feel that it is a good approach.
Option 2:
Possibly you disagree with the above assertion. Possibly you
think that a raid5 build from a number of raid1's is a good idea.
And maybe you are right.
Approach:
Add an ioctl, or possibly an 'magic' address, so that it is
possible to read a raw superblock from an md array.
Define two in-kernel superblock reading methods. One reads the
superblock and presents it as the bottom level only. The other
reads the raw superblock out of the underlying device, using the
ioctl or magic address (e.g. read from MAX_SECTOR-8) and
presents it as the next level of the raid stack.
I think this approach, possible with some refinement, would be
adequate to support any sort of stacking and any sort of raid
superblock, and it would be my preferred way to go, if this were
necessary.
>
> > Concerning the auto-assembly of multi-level arrays, that is not
> > particularly difficult, it just needs to be described precisely, and
> > coded.
> > It is a user-space thing and easily solved at that level.
>
> How does it work if you're trying to boot off the array? The kernel needs
> to know how to auto-assemble the array in order to run init and everything
> else that makes a userland program run.
initramdisk or initramfs or whatever is appropriate for the kernel you
are using.
Also, remember to keep the concepts of 'boot' and 'root' distinct.
To boot off an array, your BIOS needs to know about the array. There
are no two ways about that. It doesn't need to know a lot about the
array, and for raid1 all it needs to know is 'try this device, and if
it fails, try that device'.
To have root on an array, you need to be able to assemble the array
before root is mounted. md= kernel parameters in one option, but not
a very extensible one.
initramfs will be the preferred approach in 2.6. i.e. an initial root
is loaded along with the kernel, and it has the user-space tools for
finding, assembling and mounting the root device.
>
> > >
> > > I know Neil has philosophical issues with autoconfiguration (or perhaps
> > > in-kernel autoconfiguration), but it really is helpful, especially in
> > > certain situations.
> >
> > I have issues with autoconfiguration that is not adequately
> > configurable, and current linux in-kernel autoconfiguration is not
> > adequately configurable. With mdadm autoconfiguration is (very
> > nearly) adequately configurable and is fine. There is still room for
> > some improvement, but not much.
>
> I agree that userland configuration is very flexible, but I think there is
> a place for kernel-level autoconfiguration as well. With something like an
> Adaptec HostRAID board (i.e. something you can boot from), you need kernel
> level autoconfiguration in order for it to work smoothly.
I disagree, and the development directions of 2.5 tend to support me.
You certainly need something before root is mounted, but 2.5 is
leading us to 'early-user-space configuration' rather than 'in-kernel
configuration'.
NeilBrown
^ permalink raw reply
* 2.5.51 compile fails (fs/readdir.c)
From: Pete Clements @ 2002-12-11 0:11 UTC (permalink / raw)
To: linux-kernel
FYI:
gcc -Wp,-MD,fs/.readdir.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -Iarch/i386/mach-generic -fomit-frame-pointer -nostdinc -iwithprefix include -DKBUILD_BASENAME=readdir -DKBUILD_MODNAME=readdir -c -o fs/readdir.o fs/readdir.c
fs/readdir.c: In function `filldir64':
fs/readdir.c:242: internal error--unrecognizable insn:
(insn 187 186 448 (set (reg/v:SI 4 %esi)
(asm_operands/v ("1: movl %%eax,0(%2)
2: movl %%edx,4(%2)
3:
.section .fixup,"ax"
4: movl %3,%0
jmp 3b
.previous
.section __ex_table,"a"
.align 4
.long 1b,4b
.long 2b,4b
.previous") ("=r") 0[
(reg:DI 1 %edx)
(reg:SI 0 %eax)
(const_int -14 [0xfffffff2])
(reg/v:SI 4 %esi)
]
[
(asm_input:DI ("A"))
(asm_input:SI ("r"))
(asm_input:SI ("i"))
(asm_input:SI ("0"))
] ("fs/readdir.c") 226)) -1 (insn_list 184 (insn_list 186 (nil)))
(nil))
make[1]: *** [fs/readdir.o] Error 1
make: *** [fs] Error 2
--
Pete Clements
clem@clem.digital.net
^ permalink raw reply
* RE: Is this going to be true ?
From: Joseph D. Wagner @ 2002-12-11 0:05 UTC (permalink / raw)
To: 'Serge Kuznetsov', linux-kernel
In-Reply-To: <050c01c2a091$77564600$9c094d8e@wcom.ca>
> I am just curious if someone has an opinion for the
> following link?
>
> Research Firm: Microsoft Will Use Linux by 2004:
> [trim]
Over Bill Gates' dead body. The Microsoft Corporation (and by that, I mean
the people running it: Chairman of the Board, CEO, CIO, CFO, Board of
Directors, most of the stockholders, etc.) is of the genuine belief that
Microsoft Windows is the operating system of the future. (Whether you
believe it or not is a separate topic.) Developing products for the Linux
platform is both 1) an admission that this belief was wrong, and 2) an
admission that their own current version of Microsoft Windows is somehow
shoddy, not-up-to-par, insufficient, or even on an equal footing with Linux.
The Microsoft Corporation will never admit either of those two things.
After all, it's the MICROSOFT CORPORATION. If they didn't believe these
things, they would go somewhere else.
The following scenarios are far more likely.
1) Future development of the Windows operating system or some of its
components will be *BSD based. The Microsoft Corporation will never touch
Linux. Period. The lawyers simply wouldn't allow it. The lawyers think of
GNU GPL as an infectious disease, and so anything Linux is out of the
question. The BSD license is far more favorable to proprietary development,
since it allows you to close off the source. Hence, assimilating a *BSD
structure, component, or piece of code is far more likely.
In fact, Microsoft Windows 2000/XP already did that with Kerberos.
2) Lower prices for Microsoft Licensing or more broadly interpreted
licensing. It may be that to better compete with Linux that Microsoft
lowers the prices of some of its Microsoft products.
One thing Microsoft has already done in this regard is to change the
licensing on Terminal Server. On Windows NT 4.0, each copy of Windows NT
Workstation needed a Client Access License and a Terminal Server Client
Access License to connect to a server and a server's Terminal Server,
respectively. Now, with Windows 2000 and XP Pro, a Terminal Server Client
Access License is included with either a regular Client Access License or a
Windows 2000 or XP Pro operating system license (I forget which).
3) Develop kits, wizards, and other software to help people convert from
Linux to Windows. Microsoft already has Unix for Windows Services (or
something like that with a similar name). It's purpose is to help people
convert from SCO UNIX to Windows. I see no reason that Microsoft can't
develop a similar such kit for, say, Red Hat Linux. (Sure, it would be one
heck-of-a-kit and very complicated, but I can see it).
*Sigh* Yet, another topic for the linux-politics list. There is no such
list, BTW, but this email highlights the need for one.
Joseph Wagner
^ permalink raw reply
* 2.5.51 nanosleep fails
From: Marco d'Itri @ 2002-12-10 23:57 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
nanosleep fails after being interrupted:
[...]
fstat64(3, {st_mode=S_IFREG|0644, st_size=5444, ...}) = 0
gettimeofday({1039564416, 703895}, NULL) = 0
nanosleep({1, 0}, NULL) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=5444, ...}) = 0
gettimeofday({1039564417, 777452}, NULL) = 0
nanosleep({1, 0},
[1]+ Stopped strace tail -f /var/log/uucp/Log
md@wonderland:~$ fg
strace tail -f /var/log/uucp/Log
<unfinished ...>
--- SIGCONT (Continued) ---
<... nanosleep resumed> 0) = -1 ENOSYS (Function not implemented)
This can be reliably reproduced.
Linux wonderland 2.5.51 #13 Tue Dec 10 14:15:49 CET 2002 i686 unknown unknown GNU/Linux
--
ciao,
Marco
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.5.51 don't compil with dvb
From: Rusty Russell @ 2002-12-10 23:53 UTC (permalink / raw)
To: Alan Cox; +Cc: greg, linux-kernel, linux-dvb
In-Reply-To: <1039536315.14175.2.camel@irongate.swansea.linux.org.uk>
On 10 Dec 2002 16:05:15 +0000
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Tue, 2002-12-10 at 15:07, Gregoire Favre wrote:
> > drivers/built-in.o(.text+0x38655): In function `try_attach_device':
> > : undefined reference to `MOD_CAN_QUERY'
> > make: *** [vmlinux] Error 1
> >
>
> Modules are still very broken in 2.5.51, its best to compile a system
> which doesn't use modules or stay at an older kernel
That may be true, but in this case, it's the only occurrance of MOD_CAN_QUERY
outside the archs which haven't been updated to the new module loader yet,
and it's a very odd thing to do.
I assume the author meant this:
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.51/drivers/media/dvb/dvb-core/dvb_i2c.c working-2.5.51-dvb/drivers/media/dvb/dvb-core/dvb_i2c.c
--- linux-2.5.51/drivers/media/dvb/dvb-core/dvb_i2c.c 2002-11-28 10:20:07.000000000 +1100
+++ working-2.5.51-dvb/drivers/media/dvb/dvb-core/dvb_i2c.c 2002-12-11 10:53:09.000000000 +1100
@@ -64,10 +64,8 @@ static
void try_attach_device (struct dvb_i2c_bus *i2c, struct dvb_i2c_device *dev)
{
if (dev->owner) {
- if (!MOD_CAN_QUERY(dev->owner))
+ if (!try_inc_mod_count(dev->owner))
return;
-
- __MOD_INC_USE_COUNT(dev->owner);
}
if (dev->attach (i2c) == 0) {
--
there are those who do and those who hang on and you don't see too
many doers quoting their contemporaries. -- Larry McVoy
^ permalink raw reply
* [linux-lvm] LVM is wont restore. DESPERATE. PLEASE HELP!
From: acpretty @ 2002-12-10 23:33 UTC (permalink / raw)
To: linux-lvm
Hey all,
If someone is around who could help me it would be SO appreciated.
I have a volume group (vg00) with two physical volumes in it.
with in about half an hour .....
I extended one of the logical volumes, no probs
I extended the file system, noprobs
was doing a large-ish transfer to my enlarged fs when the machine crashed...
upon restarting the machine told me I had inconsistencies in my PV's so I did a vgcfgrestore. Now upon restarting I get no acknowledgement of the volume group at all....
SO! I thought I'd try and force a vgimport of the volume group only to find that vgimport says that the two PV's in the VG are not from the same VG.
now I'm a bit lost, if anyone could help, PLEASE!!!! I have one last thing I think I should try but I'm uncertain.
When I run pvdata the bit at the bottom says:
--- List of physical volume UUIDs ---
001: EtJbdT-qZBP-P6Bf-yRwi-I4Bn-0qzS-L13XYu
002: --- EMPTY ---
shouldn't each PV know about all the other PV's UUID's in this list and therefore can anyone tell me if using the UUID fixer program is the thing to do?
more importantly can anyone tell me how much of the partitions I need to dd in order to preserve the meta data in case this doesn't help
Thanks reading this far and thanks in advance to the help
Alex
This message was sent through MyMail http://www.mymail.com.au
^ permalink raw reply
* Re: [PATCH 3/3] High-res-timers part 3 (posix to hrposix) take 20
From: george anzinger @ 2002-12-10 23:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <3DF5B2D1.FD134082@digeo.com>
Andrew Morton wrote:
>
> george anzinger wrote:
> >
> > ...
> > > radix-trees do not currently have a "find next empty slot from this
> > > offset" function but that is quite straightforward. Not quite
> > > as fast, unless an occupancy bitmap is added to the radix-tree
> > > node. That's something whcih I have done before - in fact it was
> > > an array of occupancy maps so I could do an efficient in-order
> > > gang lookup of "all dirty pages from this offset" and "all locked
> > > pages from this offset". It was before its time, and mouldered.
> >
> > Gosh, I think this is what I have. Is it already in the
> > kernel tree somewhere? Oh, I found it. I will look at
> > this, tomorrow...
> >
>
> A simple way of doing the "find an empty slot" is to descend the
> tree, following the trail of nodes which have `count < 64' until
> you hit the bottom. At each node you'll need to walk the slots[]
> array to locate the first empty one.
>
> That's quite a few cache misses. It can be optimised by adding
> a 64-bit DECLARE_BITMAP to struct radix_tree_node. This actually
> obsoletes `count', because you can just replace the test for
> zero count with a test for `all 64 bits are zero'.
Uh, I tried something like this. The flaw is that the count
is a count of used slots at in that node and does not say
anything about slots in any nodes below that one. In my
tree the bit map is an indication of empty leaf node slots.
This means that when a leaf slot becomes free it needs to be
reflected in each node in the path to that leaf and when a
leaf node fills, that also needs to be reflected in each
node in the path.
>
> Such a search would be an extension to or variant of radix_tree_gang_lookup.
> Something like the (old, untested) code below.
>
> But it's a big job. First thing to do is to write a userspace
> test harness for the radix-tree code. That's something I need to
> do anyway, because radix_tree_gang_lookup fails for offests beyond
> the 8TB mark, and it's such a pita fixing that stuff in-kernel.
>
> Good luck ;)
Hm, the question becomes:
a.)Should I add code to the radix-tree to make it do what I
need and, most likely take longer and be harder to debug, or
b.)Should I just enhance what I have to remove the
recursion, which should be rather easy to do and test, even
in kernel land?
>
> .
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: NAND and concat
From: Charles Manning @ 2002-12-10 23:58 UTC (permalink / raw)
To: Christian Gan, linux-mtd, yaffs list
In-Reply-To: <NFBBLPGPLKFIKCCPLALEOEPHCEAA.cgan@iders.ca>
I'm not sure I understand what you mean by concat for NAND. Do you mean being
able to read/write directly to the char device?
Certainly handling OOB and pages makes things a bit different. Someone wrote
a nand dumper which maybe does what you want (or can be persuaded :-). The
yaffs format tool uses the char interface. It needs to expand to load up a
mkyaffsimage image into flash.
-- CHarles
^ permalink raw reply
* Linux 2.4.21-pre1
From: Marcelo Tosatti @ 2002-12-10 20:37 UTC (permalink / raw)
To: lkml
So here goes the first pre of 2.4.21 including the new IDE code merged
from Alan's tree.
Test it carefully, since the new IDE code is not yet fully tested.
Do not use it with critical data.
Summary of changes from v2.4.20 to v2.4.21-pre1
============================================
<baldrick@wanadoo.fr>:
o usbdevfs: finalize urbs on interface release
o usbdevfs: finalize urbs on interface release
o usbdevfs: more list cleanups
<chris@qwirx.com>:
o [SPARC]: Add missing iounmap to display7seg driver
<dana.lacoste@peregrine.com>:
o RATOC USB-60 patch
<eranian@frankl.hpl.hp.com>:
o efirtc update
<erik@aarg.net>:
o USB: added support for Palm Tungsten T devices to visor driver
<ganesh@tuxtop.vxindia.veritas.com>:
o USB ipaq: brown paper bag bug - uninitialized spinlock fixed
o USB ipaq: added support for insmod options to specify vendor/product id
<gronkin@nerdvana.com>:
o [netdrvr tulip] new pci id
<henning@meier-geinitz.de>:
o [PATCH 2.4.20-rc1] scanner.h: add/fix vendor/product ids
<m.c.p@wolk-project.de>:
o ide-scsi update to new IDE
o Remove IDE init calls from blk_dev_init (IDE merge)
o Add missing system.h bits (IDE merge)
<marcel@holtmann.org[holtmann]>:
o [Bluetooth] Add RFCOMM protocol support
o [Bluetooth] UART driver update
o [Bluetooth] Add HCI UART PC Card driver
o [Bluetooth] Add BCSP TXCRC option
<nicolas.mailhot@laposte.net>:
o AGP support for VIA KT400
<oliver@oenone.homelinux.org>:
o use of unplugged scanner oops fix
<petkan@tequila.dce.bg>:
o USB: pegasus: the kmalloc/kfree crap removed from [get|set]_registers();
<plcl@telefonica.net>:
o usb-midi patch for 2.4.20-pre11
<srompf@isg.de>:
o [netdrvr starfire] add netif_carrier_{on,off} calls
<stelian@popies.net>:
o sonypi driver update
o meye driver update
o export pci symbols for pcmcia modules
<tvrtko@net4u.hr>:
o usb-uhci, fixed memory leak with one-shot interrupt transfers
<will@sowerbutts.com>:
o USB: add USB powermate driver
<wstinson@wanadoo.fr>:
o [netdrvr de620] remove unneeded, and ifdef'd out, check_region call
Adam Kropelin <akropel1@rochester.rr.com>:
o [netdrvr ewrk3] fix and enable ethtool phys-id ioctl
o [netdrvr ewrk3] allow user to change MAC address via SIOCSIFHWADDR
Adrian Bunk <bunk@fs.tum.de>:
o CONFIG_AGP_AMD_8151 Configure.help entry
o Fix pcmcia_net link error
Alan Cox <alan@lxorguk.ukuu.org.uk>:
o ppc stuff for new ide layer
o update mousedriver docs as in 2.5
o bring loop device up to date
o parisc mux console config
o add scx200 drivers
o work around ALi magick chipset hangs with video capture
o fix cyclades resource handling
o vendor update for mpt fusion
o pcmcia networking updates
o lanstreamer updates
o pcmcia parport update
o new pci ids
o reserve some I/O ports on the ATI radeon IGP
o new pci idents
o pcmcia core updates from David Hinds
o backport 2.5 advansys off by one fix
o ac IDE merge
o t128 compile fix if non modular
o core code for new nsp32 driver
o fix ac97 string formatting errors
o fix mad16 bugs
o some laptops need longer delay
o make cdcether work
o latest i810 audio update
o BeOS fs updates
o fix off by one in module loader rename of module
o work around 8253 timer funnies
o ensure memcpy_to/from_io don't prefetch
o Sort out the tachyon driver
Andrew Morton <akpm@digeo.com>:
o Fix for the ext3 data=journal unmount problem
Arnaldo Carvalho de Melo <acme@conectiva.com.br>:
o Add support for JTEC FA8101 USB to Ethernet device
Charles White <charles.white@hp.com>:
o Add support for the SA641, SA642 and SA6400 controllers
Christoph Hellwig <hch@lst.de>:
o small sd error handling fix
o update scsi largelun blacklist
o make flock Posix 2001 compatible
Christoph Hellwig <hch@sgi.com>:
o cleanup b_inode usage and fix onstack inode abuse
o backport 2.5 inode allocation changes
o fix memory leak in sd.c
Dave Jones <davej@suse.de>:
o Intel cache handling fixes
Dave Kleikamp <shaggy@shaggy.austin.ibm.com>:
o Add more statistics to /proc/fs/jfs/ to help with performance tuning
o JFS: Avoid writing partial log pages for lazy transactions
o JFS: forced metadata pages were not being flushed to disk
o jfs_clear_inode should skip bad inodes instead of choking on them
o JFS: Move index table out of directory inode's address space
o JFS: Fix off-by one error when symlink size == 256 bytes
o JFS: flush pending commit records to journal during unmount
o jfs_truncate needs to call block_truncate_page
David Brownell <david-b@pacbell.net>:
o usbnet talks to Zaurus
David Brownell <dbrownell@users.sourceforge.net>:
o USB: USB 2.0 controller and hubs bugfixes
David S. Miller <davem@nuts.ninka.net>:
o [SPARC]: Ignore SIGURG if not caught
o [SPARC]: NR_IRQS is off by one
o [SPARC64]: Fix dnotify_parent call in do_readv_writev32
o [SPARC64]: Add some missing semicolons newer gcc warns about
o [SPARC64]: Add -finline-limit=100000 to CFLAGS if gcc supports it
o [SPARC64]: Clobber register l1 in switch_to if gcc >= 3.0
o [SPARC]: Synchronize MAINTAINERS entry with 2.5.x
o [SPARC]: Fix dependency on previous NR_IRQS value
o [SPARC64]: Export __flush_dcache_range
o [SPARC64]: Update defconfig
o [SPARC]: Implement local_irq_set
o [SPARC64]: Fix read_pil_and_sti
Edward Peng <edward_peng@dlink.com.tw>:
o dl2k net driver update from vendor
o [netdrvr dl2k] only read 0x100 through 0x150 statistics registers if mem mapping
Eric Brower <ebrower@usa.net>:
o [SPARC]: Make APC idle a boot time cmdline option
Greg Kroah-Hartman <greg@kroah.com>:
o Cset exclude: acme@conectiva.com.br|ChangeSet|20021011180213|25533
o USB: added support for Clie NX60 device
o removed vicamurbs.h
o USB: added Palm Tungsten W support
Ivan Kokshaysky <ink@jurassic.park.msu.ru>:
o alpha: alcor and sable fixes
o alpha misc fixes
o alpha initrd fix
o asm-alpha/regdef.h
o alpha __stxncpy fixes
o Fixup Alpha IDE PCI
Jeff Garzik <jgarzik@redhat.com>:
o Add 00-INDEX file describing contents of Documentation/BK-usage directory
o Small clarification in BK kernel howto
o In several drivers, use pci_[gs]et_drvdata instead of directly referencing struct pci_dev::driver_data.
o [net drivers] update hamachi and starfire to use MII lib
o Update my email address
o Remove performance barrier in i810_rng char driver
o [netdrvr bmac] remove init_timer call that was erroneously removed
o [netdrvr fealnx] remove bogus line due to patch error
o [netdrvr] add "r8169", a new Realtek 8169 gigabit ethernet driver
o [netdrvr r8169] large style cleanup
o [netdrvr r8169] minor functional cleanups and bug fixes
o Handle internal proc_register failure in proc_symlink, proc_mknod, proc_mkdir, and create_proc_entry.
o [netdrvr] Make a special section in drivers/net/Makefile for
o [netdrvr sunhme] remove memset in init, alloc_etherdev does it for us
o [netdrvr] fix Stanford checker buffer overflows in ni52, 3c523 (rarely if ever would be hit)
o [netdrvr 3c515] fix unlikely buffer overrun when >8 adapters present
o [netdrvr] zap PCI_VPD_ADDR constants from skfp, sk98lin drivers
o [netdrvr r8169] use pci_[gs]et_drvdata instead of pdev->driver_data
o Clarify locking/context docs for network interfaces, in Documentation/networking/netdevices.txt.
Joe Burks <joe@wavicle.org>:
o Vicam patch against 2.4.20-pre9
John Stultz <johnstul@us.ibm.com>:
o Summit chipset support: Clustered apic tweaks
o Summit chipset support: Logical/Physical apicid additions
o Summit chipset support: CLUSTERED_APIC_XAPIC switches
o Summit chipset support: CONFIG_X86_SUMMIT, auto-detection, cleanup
Juan Quintela <quintela@mandrakesoft.com>:
o Fix journalling api documentation
Kent Yoder <key@austin.ibm.com>:
o [netdrvr lanstreamer] a fix and a feature addition
Maksim Krasnyanskiy <maxk@qualcomm.com>:
o RFCOMM TTY fixes
o BNEP fixes
o HCI UART fixes
o Fix typo in hci_usb_open() (MAX_BULK_TX -> MAX_BULK_RX)
o Fix L2CAP client/server PSM clash
o Fix hci_dev_get_list() for big endian machines
o Ordinary users are not allowed to use raw L2CAP sockets
o BNEP extension headers handling fix
Manfred Spraul <manfred@colorfullife.com>:
o [netdrvr 8139too] skb_copy_and_csum_dev use allows us to enable the NETIF_F_HIGHDMA feature.
Marcel Holtmann <marcel@holtmann.org>:
o [Bluetooth] Module description cleanup for BNEP
o [Bluetooth] Config cleanup for BNEP
o [Bluetooth] Add HCI id for Bluetooth PCI cards
o [Bluetooth] Support for suspend/resume interface for HCI devices
o [Bluetooth] Fix typo in role change event size
o [Bluetooth] Cosmetic changes to the config files
o [Bluetooth] Initialize hardware broadcast
o [Bluetooth] Check for signals while waiting for DLC
o [Bluetooth] Fix operator precedence for modem status
o [Bluetooth] Don't do wakeup if protocol is not set
o [Bluetooth] Fix some bits of the modem status handling
o [Bluetooth] Free skbs with kfree_skb() instead of kfree()
o [Bluetooth] Fix another operator precedence for modem status
o [Bluetooth] Update help entry for CONFIG_BLUEZ
o [Bluetooth] The function l2cap_do_connect() should be static
o [Bluetooth] Don't use %d notation for non devfs name field of tty_driver
o Disable bluetooth.o if Bluetooth subsystem is used
Marcelo Tosatti <marcelo@freak.distro.conectiva>:
o megaraid driver update
o Update gdth driver
o Cset exclude: akpm@digeo.com|ChangeSet|20021202135530|52474
o Backout wrong change of gdth update
o Cset exclude: khalid_aziz@hp.com|ChangeSet|20021129142249|58780
o Add missing x86 system.h bits from IDE -ac merge
o Changed EXTRAVERSION to -pre1
o Cset exclude: raul@pleyades.net|ChangeSet|20021210155107|09736
o Cset exclude: hch@lst.de|ChangeSet|20021210165533|06540
Matt Domsch <matt_domsch@dell.com>:
o aacraid Dell PERC 320/DC support
Matthew Wilcox <willy@debian.org>:
o update lasi_82596 net driver to use spinlock instead of cli/sti
o Add PCI-X register definitions
Olaf Hering <olh@suse.de>:
o minor fixes for compile warnings in 2.4.20pre11 , usb-2.4 tree
Pete Zaitcev <zaitcev@redhat.com>:
o [SPARC]: Clobber l3 in context switch
o [SPARC]: kill NR_IRQS + 1 stuff
Randy Dunlap <randy.dunlap@verizon.net>:
o USB: use time_before() to compare times
o tiglusb timeouts
Randy Dunlap <rddunlap@osdl.org>:
o USB requires MIDI
Richard Henderson <rth@dorothy.sfbay.redhat.com>:
o [ALPHA] Add local_irq_set
o [ALPHA] Fix asm clobber problem diagnosed by current gcc 3.3 snap
o CREDITS
Rob Radez <rob@osinvestor.com>:
o [SPARC]: Fix loop terminator in iommu_get_scsi_sgl_pflush
Roger Luethi <rl@hellgate.ch>:
o [netdrvr ns83820] fix oops in ioctl, and initialize dev->priv to prevent such slipups again
o [netdrvr via-rhine] version bump, C99 initializers
o [netdrvr via-rhine] fix up strange C99 notation in previous patch
Rolf Eike Beer <eike@bilbo.math.uni-mannheim.de>:
o Kill unneeded declaration from drivers/scsi/sim710.h
Romain Lievin <rlievin@free.fr>:
o USB: tiglusb sync with 2.5
Scott Feldman <scott.feldman@intel.com>:
o e100 net driver: remove driver-isolated flag/lock
Takayoshi Kouchi <t-kouchi@mvf.biglobe.ne.jp>:
o ACPI PCI hotplug updates
Tim Waugh <twaugh@redhat.com>:
o 2.4.20: fix aladdin card hang
^ permalink raw reply
* Re: module-init-tools 0.9.3 -- "missing" issue
From: Alessandro Suardi @ 2002-12-10 23:27 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-kernel
In-Reply-To: <20021210231301.1301B2C078@lists.samba.org>
Rusty Russell wrote:
> In message <2105495.1039535073217.JavaMail.nobody@web55.us.oracle.com> you write:
>
>>As per the README...
[snip]
>
> Hmm, you don't need to run aclocal, automake and autoconf if you don't
> alter the sources. I have altered the README to put that at the
> bottom:
>
> 5) If you want to hack on the source:
> aclocal && automake --add-missing --copy && autoconf
>
> Thanks for the report!
Thanks for the clarification. Just wanted to add that following
Rusty Lynch's hint to ignore the 'missing' issue I successfully
installed 0.9.3 and they appear to work on 2.5.51 (I was able
to modprobe vfat - but not the full irda stack, I'll report this
separately to Jean) _and_ on 2.4.20 (modular IrDA and PPP are
channeling this message to you - loaded by 0.9.3 :).
--alessandro
"Seems that you can't get any more than half free"
(Bruce Springsteen, "Straight Time")
^ permalink raw reply
* Re: hidden interface (ARP) 2.4.20 / network performance
From: Willy TARREAU @ 2002-12-10 23:29 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: Roberto Nibali, willy, linux-kernel, linux-net
In-Reply-To: <20021210140912.7a9092b6.skraw@ithnet.com>
On Tue, Dec 10, 2002 at 02:09:12PM +0100, Stephan von Krawczynski wrote:
> Well, what I am trying to say is this: my experience is that under load with
> small sized packets even standard routing/packet forwarding becomes lossy.
This is more often dependant on hardware itself (NICs, chipsets). When your NIC
doesn't support scatter/gather, mitigated interrupts and other wonderful features,
and it receives 148600 pkts/second, it generates as many interrupts. Many chipsets
completely die under such a load. I can tell you that I wasn't proud of hanging my
Dual Athlon 1800+ with its 64/66 PCI slots and so from a single Celeron 800 on
100 Mbps copper !
> If I put NAT and other nice netfilter features on top of such a situation things
> get a lot worse (obviously) - no comparison to building the "application" (e.g.
> cluster) with routing and hidden-patch (mainly because of its pure simplicity I
> guess).
don't even need that to kill a system. Only a cheap NIC, a responding MAC address
and that's all. Of course routing make it worse and NAT even more. And BTW, when I
get 10 to 12 kHits/s with Tux on a 100 Mbps network, you'll notice that it only
happens on empty files. This is about 1 kB per hit, from a wire point of vue.
Count the ACKs, the data (tcp headers), and global overhead, and you're not far
from wire-speed on very small packets.
> Don't get me wrong: I am pretty content with the hidden-patch and my setup
> without NAT. But I wanted to point to the direction of possible further routing
> performance improvement in 2.4.X tree. Is it correct that I can expect higher
> data-rates (concerning small packets) if using higher HZ ?
don't know. perhaps forwarding packets between input and output involves queues
that are processed alternatively at HZ rate, but that seems strange to me.
> Someone selling E3 cards told me he cannot manage loads like these (small
> packet stuff) with a stock kernel, and that you _at least_ have to increase HZ
> to get acceptable throughput results.
E3 is only 45 Mbps (or I'm mistaken) ? Tweaking such parameters for such medium
rates doesn't seem the most appropriate to me. Perhaps his driver has some problems.
Cheers,
Willy
^ 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.