* Re: [ACPI] Re: [2.5.50, ACPI] link error
From: Pavel Machek @ 2002-12-10 20:40 UTC (permalink / raw)
To: Alan Cox
Cc: Grover, Andrew, 'Ducrot Bruno', Pavel Machek,
Ducrot Bruno, Patrick Mochel, Linux Kernel Mailing List,
ACPI mailing list
In-Reply-To: <1039481341.12046.21.camel@irongate.swansea.linux.org.uk>
Hi!
> > I concur with your pros and cons. This makes me think that if S4BIOS support
> > ever gets added, it should get added to 2.4 only.
And S4BIOS will never get added to 2.4 since it needs driver model
:-(.
> That assumes no box exists where S4bios works an S4 doesnt (eg due to
> bad tables or "knowing" what other-os does)
We have full control over S4 (== swsusp), so we can fix that in most
cases.
S4BIOS is still little friendlier to the user -- no need to set up
swap partition and command line parameter, can't go wrong if you boot
without resume=, etc.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
^ permalink raw reply
* Re: 2.2 networking, NET_BH latency
From: David S. Miller @ 2002-12-10 21:02 UTC (permalink / raw)
To: Stelian Pop; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021210153134.GB23479@laguna.alcove-fr>
On Tue, 2002-12-10 at 07:31, Stelian Pop wrote:
> [
> I posted this on lkml two weeks ago, and got no responses.
> Am I asking something too trivial or nobody knows the answers ? :-)
>
> Thanks.
> ]
Most of us have forgotten even how the 2.2.x networking works
it's been so long since we even glanced at the code.
^ permalink raw reply
* Re: [BENCHMARK] 2.5.51 with contest
From: Con Kolivas @ 2002-12-10 20:24 UTC (permalink / raw)
To: Stan Bubrouski; +Cc: linux kernel mailing list
In-Reply-To: <3DF621D0.6040505@ccs.neu.edu>
Quoting Stan Bubrouski <stan@ccs.neu.edu>:
> Con Kolivas wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Here are contest results (http://contest.kolivas.net) for 2.5.51 and
> related
> > kerneles using the dedicated osdl (http://www.osdl.org) hardware.
> >
> > Uniprocessor:
> > noload:
> > Kernel [runs] Time CPU% Loads LCPU% Ratio
> > 2.5.49 [5] 70.0 96 0 0 1.05
> > 2.5.50 [5] 69.9 96 0 0 1.05
> > 2.5.50-mm1 [5] 71.4 94 0 0 1.07
> > 2.5.51 [2] 69.8 96 0 0 1.05
>
> I know this has been brought up before, but
> these don't seem to mean much unless you
> include 2.4.20 in the comaprison.
Repeated benchmarks of each successive release allow to detect subtle
differences of each change. If contest shows these changes the people who can
act on them will see them clearly if displayed only with relevant results. If
you want previous results, a full comparison is available at the full logs of
all previous benchmarks as I mention.
http://www.osdl.org/projects/ctdevel/results/
Con
^ permalink raw reply
* Re: [BK-2.4] [PATCH] Small do_mmap_pgoff correction
From: David S. Miller @ 2002-12-10 20:19 UTC (permalink / raw)
To: linux-kernel; +Cc: marcelo, raul
In-Reply-To: <200212101931.gBAJV1K10639@hera.kernel.org>
From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Date: Tue, 10 Dec 2002 15:51:07 +0000
+
+/*
+ * NOTE: in this function we rely on TASK_SIZE being lower than
+ * SIZE_MAX-PAGE_SIZE at least. I'm pretty sure that it is.
+ */
+
This assumption is wrong. It is totally possible for TASK_SIZE
to be the entire 64-bit address space on sparc64 and thus larger
than SIZE_MAX - PAGE_SIZE, and I definitely plan on supporting
that.
User processes live entirely in their very own address space seperate
from the kernel, so kernel stuff does not take up any part of the user
virtual addresses.
Please revert this change, it adds absolutely nothing.
^ permalink raw reply
* Re: buffer head read/write
From: Andrew Morton @ 2002-12-10 20:13 UTC (permalink / raw)
To: David Chow; +Cc: linux-fsdevel
In-Reply-To: <3DF4C40D.2010201@shaolinmicro.com>
David Chow wrote:
>
> Hi all,
>
> Is there a way to make sure I submit a buffer head read/write and make
> sure it is commited immediately? (sychronized) . Please give direction
> on examples in the kernel code? Thanks.
grep wait_on_buffer fs/ext2/*.c - you'll see lots of examples. eg:
mark_buffer_dirty(bh);
if (sb->s_flags & MS_SYNCHRONOUS) {
ll_rw_block (WRITE, 1, &bh);
wait_on_buffer (bh);
}
^ permalink raw reply
* [2.5.51, APM, USB] APM not sleeping
From: Jochen Hein @ 2002-12-10 19:54 UTC (permalink / raw)
To: linux-kernel
Running "apm -s" I get:
bad: scheduling while atomic!
Call Trace: [<c0119e81>] [<c012379e>] [<c0123714>] [<c6a6d043>] [<c6a6d3cb>] [<c6a6f3b7>] [<c6a5cfca>] [<c0147491>] [<c018391d>] [<c0173a6a>] [<c01233e0>] [<c024c7b5>] [<c01234f9>] [<c024c790>] [<c018391d>] [<c017f063>] [<c017f7ce>] [<c01720bb>] [<c011a1f0>] [<c017fc7c>] [<c0173054>] [<c017b5ed>] [<c0159e0b>] [<c015ac10>] [<c015ad36>] [<c015adac>] [<c0159536>] [<c015853f>] [<c01523fc>] [<c01bd7a5>] [<c015463f>] [<c0108cd7>]
apm: suspend: Unable to enter requested state
Decoded:
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; c0119e81 <schedule+3d/2c8>
Trace; c012379e <schedule_timeout+7a/a0>
Trace; c0123714 <process_timeout+0/10>
Trace; c6a6d043 <END_OF_CODE+66768c3/????>
Trace; c6a6d3cb <END_OF_CODE+6676c4b/????>
Trace; c6a6f3b7 <END_OF_CODE+6678c37/????>
Trace; c6a5cfca <END_OF_CODE+666684a/????>
Trace; c0147491 <bh_lru_install+d9/e4>
Trace; c018391d <journal_cancel_revoke+101/178>
Trace; c0173a6a <ext3_get_block_handle+be/310>
Trace; c01233e0 <update_process_times+2c/38>
Trace; c024c7b5 <cursor_timer_handler+25/2c>
Trace; c01234f9 <run_timer_softirq+f1/144>
Trace; c024c790 <cursor_timer_handler+0/2c>
Trace; c018391d <journal_cancel_revoke+101/178>
Trace; c017f063 <do_get_write_access+50f/530>
Trace; c017f7ce <journal_dirty_metadata+1ba/1f0>
Trace; c01720bb <ext3_free_inode+397/3c8>
Trace; c011a1f0 <__wake_up+20/40>
Trace; c017fc7c <journal_stop+258/268>
Trace; c0173054 <ext3_delete_inode+0/194>
Trace; c017b5ed <ext3_destroy_inode+15/1c>
Trace; c0159e0b <destroy_inode+3f/58>
Trace; c015ac10 <generic_delete_inode+c4/d0>
Trace; c015ad36 <generic_drop_inode+12/20>
Trace; c015adac <iput+68/70>
Trace; c0159536 <d_delete+6a/c4>
Trace; c015853f <dput+1b/158>
Trace; c01523fc <sys_unlink+dc/11c>
Trace; c01bd7a5 <capable+1d/38>
Trace; c015463f <sys_ioctl+21f/270>
Trace; c0108cd7 <syscall_call+7/b>
Loaded modules are:
root@gswi1164:/var/log# lsmod
Module Size Used by
neofb 10861 0
pcnet_cs 11048 1 [unsafe]
8390 6272 1 pcnet_cs
ds 6460 3 pcnet_cs
yenta_socket 10301 2 [unsafe]
pcmcia_core 37598 3 pcnet_cs ds yenta_socket
ppp_async 6573 0
ppp_generic 18147 1 ppp_async
slhc 4896 1 ppp_generic
rxrpc 51733 0
vfat 8945 0
fat 33837 1 vfat
I suspect pcnet_cs or yenta_socket, because:
Module yenta_socket cannot be unloaded due to unsafe usage in drivers/pcmcia/yenta.c:940
Module pcnet_cs cannot be unloaded due to unsafe usage in drivers/net/pcmcia/pcnet_cs.c:1033
On a related note, I removed the USB driver uhci-hcd for
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
because going to sleep stopped with
Dec 9 00:33:52 gswi1164 kernel: drivers/usb/core/hcd-pci.c: suspend 00:07.2 to state 3
Dec 9 00:33:52 gswi1164 kernel: drivers/usb/host/uhci-hcd.c: 8400: suspend_hc
Dec 9 00:33:52 gswi1164 kernel: atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
Dec 9 00:33:52 gswi1164 kernel: apm: suspend: Unable to enter requested state
Dec 9 00:33:52 gswi1164 kernel: drivers/usb/core/hcd-pci.c: resume 00:07.2
Any ideas?
Jochen
--
Wenn Du nicht weißt was Du tust, tu's mit Eleganz.
^ permalink raw reply
* RE: IDE feature request & problem
From: Manish Lachwani @ 2002-12-10 19:50 UTC (permalink / raw)
To: 'Milan Roubal', Petr Sebor, Alan Cox; +Cc: linux-kernel
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
----- Original Message -----
From: "Petr Sebor" <petr@scssoft.com>
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: <linux-kernel@vger.kernel.org>; <roubm9am@barbora.ms.mff.cuni.cz>
Sent: Monday, December 09, 2002 12:41 AM
Subject: Re: IDE feature request
> On Sun, Dec 08, 2002 at 01:09:34AM +0000, Alan Cox wrote:
> > Fix ide.c to generate a b c d e f and you should be able to get 16.
>
> Like this?
>
> -Petr
>
-
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: fetchmail and smtp problem (was tuning iptables)
From: Ray Olszewski @ 2002-12-10 20:10 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <200212101943.gBAJhgW03033@hartford-hwp.com>
Comments below, interspersed.
At 02:43 PM 12/10/02 -0500, Haines Brown wrote:
>Here are some preliminary results on fetchmail.
>
>------------------
>When I originally ran netsat -l, I got:
>
> Active Internet connections (only servers)
>
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 127.0.0.1:smtp *:* LISTEN
>
>But now for some reason it has changed to:
> tcp 0 0 hartford-hwp.com:smtp *:* LISTEN
This is *probably* a side effect of changing the entry in /etc/hosts . If
you want to see it the old way, the command is probably "netstat -ln".
>Whatever the reason for the change, I gather this means something is
>listing on the smtp port (25).
Right. But we already knew that from before.
>--------------------
>
>Setting up /etc/mail/access. I have:
>
> localhost.localdomain RELAY
> localhost RELAY
> 127.0.0.1 RELAY You suggest inserting
>--------------------
>
>I also checked /etc/mail/local-host-names. It is empty by default.
>You suggest entering "mailserver.mydomain.com", but since my machine
>has neither a static IP address nor hame, I was not sure what to do. I
>instead just put in my hostname (hartford-hwp.com), figuring it would
>do no harm.
>
> # local-host-names - include all aliases for your machine here.
> localhost
> localhost.localdomain
> hartford-hwp.com
>
>--------------------
>
>Next, I ran netstat -lp
>
> # netstat -lp
> tcp 0 0 *:smtp *:* LISTEN 856/sendmail: accep
>
>Port 25 accepts messages from sendmail?
No. sendmail is the name of the program that is LISTENing on port 25. That
part is good. And now it is listening on all IP addresses, not just
localhost (that's why you have *:smtp instead of 127.0.0.1:smtp, as you did
earlier).
>--------------------
>
>I started a telnet session, but didn't log in. Will do that, too, if
>useful.
When you telnet to a port other than the telnetd port, the concept of
"logging in" does not carry over. See below for more.
> # telnet localhost 25
> Trying 127.0.0.1...
> Connected to hartford-hwp.com (127.0.0.1).
> Escape character is '^]'.
> 220 hartford-hwp.com ESMTP Sendmail 8.12.5/8.12.5; Tue, 10 Dec 2002
> 13:12:00 -0500
This is good; sendmail does respond on this address/port. You might see if
it also responds to an attempt to deliver a message. Try entering this
sequence of commands (until you get an error response; then tell us what it
is):
HELO localhost
MAIL from: haines@localhost
RCPT to: brownh@hartford-hwp.com
DATA
(any text, follow the instructions for ending)
QUIT
If all of this works (assuming brownh@hartford-hwp.com is a vaild e-mail
address for this machine; if not, pick one that is), then the smtp side of
things is working and you need to concentrate on your fetchmail settings.
>-------------------
>I didn't know what might be useful from /etc/mail/sendmail.cf, but as
>I waited thinking about that, I saw that my fetchmail -k command
>actually carried through. It took about 20 seconds to start the first
>download. The next few messages took about 10 seconds each. Then a
>batch of about 8 downloaded normally (2-3 seconds for the batch), then
>slow again. Then fast again. The pattern was consistent for additional
>tries.
>
>The first messages was an undeliverable notive from when I tried to
>send myself a test message almost a week ago:
>
> brownh@hartford-hwp.com... Deferred: hartford-hwp.com.: Network is
> unreachable
This is not enough information to interpret. Who (what host) generated the
"Network is unreachable" message? Your Linux box or the ISP's mail server?
I'm guessing the second, and to interpret that, I need to know what else it
said (since from here hartford-hwp.com is perfectly reachable).
>After five days, it was deleted from queue. The batch of test messages
>I sent myself (also 127.0.0.1, also localhost.localdomain) fell into a
>black hole.
>
>I don't know where to look for a fechmail log, but I ran fetchmail -v
>-v > /opt/tmp/-fetchmail.log. Because it was just one new message that
>(successfully) downloaded, I'll here venture to paste the entire log:
Now I'm confused again. Above, you talked about fetchmail downloading a
dozen or so messages, but here you say "it was just one new message".
Please be more clear.
>Oops. Left it on the wrong HD. Will have to retrieve it next time I
>boot the disk. But the message did not wave any red flags (but I may
>well not recognize one even if I saw it).
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: Why does C3 CPU downgrade in kernel 2.4.20?
From: Jeff Garzik @ 2002-12-10 20:17 UTC (permalink / raw)
To: Daniel Egger; +Cc: Alan Cox, Dave Jones, Linux Kernel Mailing List
In-Reply-To: <1039549178.7224.7.camel@sonja>
On Tue, Dec 10, 2002 at 08:39:38PM +0100, Daniel Egger wrote:
> Am Die, 2002-12-10 um 17.51 schrieb Alan Cox:
>
> > Well if you optimise for ppro it won't actually always work.
>
> Yeah, I had to learn earlier that it seems to support certain
> kind of cmovs but certainly not all of them and some other
> instructions seem also to be missing.
Yes.
> > Also thescheduling seems to be best with 486.
> > Remember the C3 is a single issue risc processor.
>
> Do you have pointers to some optimisation manual or whatever?
> gcc currently defines the c3 as 486+mmx+3dnow however I doubt
> that this model is entirely correct and as such leaves some
> space for improvements.
Definitely. Read my email message that went along with that commit for
more details ;-) (finding it isn't hard, it's probably one of the few
gcc-patches mails I have ever sent)
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Justin T. Gibbs @ 2002-12-10 20:03 UTC (permalink / raw)
To: James Bottomley, Christoph Hellwig
Cc: linux-scsi, Alan Cox, Marcelo Tosatti, Linus Torvalds
In-Reply-To: <200212101602.gBAG2Hi02930@localhost.localdomain>
> The tarball contained a lot of extraneous files, but I think I got them
> all weeded out. I've but the result at:
>
> http://linux-scsi.bkbits.net/scsi-aic7xxx-2.5
>
> it needs to be tested to make sure I captured everything.
I've updated the tarfiles. For some reason my --exclude directive
didn't stick the first time. <sigh>
> Justin, this would be why patches are a lot easier to handle: we have
> automated scripts to import them rather than having to do error prone
> manual steps. All I need to know for a patch is where it was based, and
> I can get bitkeeper and the tools to do the rest.
Unfortunately, even though I've setup a BK repository in an attempt
to make this task easier, BK doesn't do what I want. It seems that
only if I can push to a public repository or can export my repository
for others to pull from, will BK auto-matically figure out which change
sets don't exist where and generate the correct stuff. Unfortunately
my IT department will not allow me to export a BK server, so that is
out of the question. Anyone care to tell me the magic incantation to
get BK to generate a cumulative patch set against the parent repository?
Or must I do a second clone and manually create patches?
--
Justin
^ permalink raw reply
* sync_fs for 2.5
From: Andrew Morton @ 2002-12-10 20:01 UTC (permalink / raw)
To: linux-fsdevel@vger.kernel.org
Here's my shot at a 2.5 version of the sync_fs() superblock operation.
It is more elaborate than in 2.4 - it is independent of s_dirt, and
does a two pass operation. The first to get IO underway, the second
to wait on it.
Seeking comments...
Documentation/filesystems/Locking | 2 +
fs/buffer.c | 11 ++++++--
fs/super.c | 48 +++++++++++++++++++++++++++++++++++---
include/linux/fs.h | 3 ++
4 files changed, 58 insertions(+), 6 deletions(-)
--- 25/fs/buffer.c~sync_fs Fri Dec 6 12:54:47 2002
+++ 25-akpm/fs/buffer.c Fri Dec 6 13:23:32 2002
@@ -222,6 +222,9 @@ int fsync_super(struct super_block *sb)
lock_super(sb);
if (sb->s_dirt && sb->s_op && sb->s_op->write_super)
sb->s_op->write_super(sb);
+ if (sb->s_op && sb->s_op->sync_fs) {
+ sb->s_op->sync_fs(sb, 1);
+ }
unlock_super(sb);
sync_blockdev(sb->s_bdev);
sync_inodes_sb(sb, 1);
@@ -252,10 +255,12 @@ int fsync_bdev(struct block_device *bdev
asmlinkage long sys_sync(void)
{
wakeup_bdflush(0);
- sync_inodes(0); /* All mappings and inodes, including block devices */
+ sync_inodes(0); /* All mappings, inodes and their blockdevs */
DQUOT_SYNC(NULL);
- sync_supers(); /* Write the superblocks */
- sync_inodes(1); /* All the mappings and inodes, again. */
+ sync_supers(); /* Write the superblocks */
+ sync_filesystems(0); /* Start syncing the filesystems */
+ sync_filesystems(1); /* Waitingly sync the filesystems */
+ sync_inodes(1); /* Mappings, inodes and blockdevs, again. */
return 0;
}
--- 25/include/linux/fs.h~sync_fs Fri Dec 6 12:54:47 2002
+++ 25-akpm/include/linux/fs.h Fri Dec 6 13:23:56 2002
@@ -632,6 +632,7 @@ struct super_block {
struct semaphore s_lock;
int s_count;
int s_syncing;
+ int s_need_sync_fs;
atomic_t s_active;
void *s_security;
@@ -810,6 +811,7 @@ struct super_operations {
void (*delete_inode) (struct inode *);
void (*put_super) (struct super_block *);
void (*write_super) (struct super_block *);
+ int (*sync_fs)(struct super_block *sb, int wait);
void (*write_super_lockfs) (struct super_block *);
void (*unlockfs) (struct super_block *);
int (*statfs) (struct super_block *, struct statfs *);
@@ -1143,6 +1145,7 @@ extern void write_inode_now(struct inode
extern int filemap_fdatawrite(struct address_space *);
extern int filemap_fdatawait(struct address_space *);
extern void sync_supers(void);
+extern void sync_filesystems(int wait);
extern sector_t bmap(struct inode *, sector_t);
extern int setattr_mask(unsigned int);
extern int notify_change(struct dentry *, struct iattr *);
--- 25/fs/super.c~sync_fs Fri Dec 6 12:54:47 2002
+++ 25-akpm/fs/super.c Fri Dec 6 13:27:10 2002
@@ -189,6 +189,8 @@ void generic_shutdown_super(struct super
if (sop) {
if (sop->write_super && sb->s_dirt)
sop->write_super(sb);
+ if (sop->sync_fs)
+ sop->sync_fs(sb, 1);
if (sop->put_super)
sop->put_super(sb);
}
@@ -266,8 +268,8 @@ void drop_super(struct super_block *sb)
static inline void write_super(struct super_block *sb)
{
lock_super(sb);
- if (sb->s_root && sb->s_dirt)
- if (sb->s_op && sb->s_op->write_super)
+ if (sb->s_op && sb->s_root && sb->s_dirt)
+ if (sb->s_op->write_super)
sb->s_op->write_super(sb);
unlock_super(sb);
}
@@ -277,7 +279,7 @@ static inline void write_super(struct su
* hold up the sync while mounting a device. (The newly
* mounted device won't need syncing.)
*/
-void sync_supers(void)
+void sync_supers()
{
struct super_block * sb;
restart:
@@ -296,6 +298,46 @@ restart:
spin_unlock(&sb_lock);
}
+/*
+ * Call the ->sync_fs super_op against all filesytems which are r/w and
+ * which implement it.
+ */
+void sync_filesystems(int wait)
+{
+ struct super_block * sb;
+
+ spin_lock(&sb_lock);
+ for (sb = sb_entry(super_blocks.next); sb != sb_entry(&super_blocks);
+ sb = sb_entry(sb->s_list.next)) {
+ if (!sb->s_op)
+ continue;
+ if (!sb->s_op->sync_fs);
+ continue;
+ if (sb->s_flags & MS_RDONLY)
+ continue;
+ sb->s_need_sync_fs = 1;
+ }
+ spin_unlock(&sb_lock);
+
+restart:
+ spin_lock(&sb_lock);
+ for (sb = sb_entry(super_blocks.next); sb != sb_entry(&super_blocks);
+ sb = sb_entry(sb->s_list.next)) {
+ if (!sb->s_need_sync_fs)
+ continue;
+ sb->s_need_sync_fs = 0;
+ if (sb->s_flags & MS_RDONLY)
+ continue; /* hm. Was remounted r/w meanwhile */
+ sb->s_count++;
+ spin_unlock(&sb_lock);
+ down_read(&sb->s_umount);
+ sb->s_op->sync_fs(sb, wait);
+ drop_super(sb);
+ goto restart;
+ }
+ spin_unlock(&sb_lock);
+}
+
/**
* get_super - get the superblock of a device
* @dev: device to get the superblock for
--- 25/Documentation/filesystems/Locking~sync_fs Fri Dec 6 12:54:47 2002
+++ 25-akpm/Documentation/filesystems/Locking Fri Dec 6 12:54:47 2002
@@ -92,6 +92,7 @@ prototypes:
void (*delete_inode) (struct inode *);
void (*put_super) (struct super_block *);
void (*write_super) (struct super_block *);
+ void (*sync_fs) (struct super_block *);
int (*statfs) (struct super_block *, struct statfs *);
int (*remount_fs) (struct super_block *, int *, char *);
void (*clear_inode) (struct inode *);
@@ -108,6 +109,7 @@ delete_inode: no
clear_inode: no
put_super: yes yes maybe (see below)
write_super: no yes maybe (see below)
+sync_fs: no no maybe (see below)
statfs: no no no
remount_fs: yes yes maybe (see below)
umount_begin: yes no maybe (see below)
_
^ permalink raw reply
* Completely discharging LION batteries
From: Frank Mehnert @ 2002-12-10 19:59 UTC (permalink / raw)
To: acpi-devel-pyega4qmqnRoyOMFzWx49A
Hi,
I'm using Linux 2.4.20 together with the acpi patches 20021205-2.4.20 on a
Thinkpad T20. If I use two batteries (the builtin and a second in the Ultra-
Bay), the second battery first gets discharged _completely_ and after that
the internal battery is used.
The bad thing about that is that if I allow the Laptop to fully discharge
the LION battery, the usable capacity gets reduced. I have looked at
/proc/acpi/battery/BAT1/{state,info}: Before completely discharging the
battery, the "last full capacity" entry was about 30500 mWh. The design
capacity is 34560 mWh. After completely discharging the battery, the
maximum capacity to which the battery can be charged is only 28120 mWh,
so I lost about 2000 mWh or about 8 percent of the battery capacity!!!
So since I found that out I don't allow the Laptop to fully discharge the
battery anymore. So may questions are: Can I set the capacity at which the
Laptop switches to the builtin battery? Can you acknowledge my experiences?
Frank
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* RE: iptables and Poptop
From: Justin Kay @ 2002-12-10 19:58 UTC (permalink / raw)
To: 'netfilter@tommi.org'; +Cc: Netfilter (E-mail)
You were right on. It was a ppp issue. Thanks for the tip.
Justin
-----Original Message-----
From: netfilter@tommi.org [mailto:netfilter@tommi.org]
Sent: Monday, December 09, 2002 1:05 PM
To: Justin Kay
Cc: Netfilter (E-mail)
Subject: Re: iptables and Poptop
I belive this is a PPP issue, try looking up the ppp proxyarp
option.
- Tomas Edwardsson
- Unix/Linux Support
- Opin Kerfi HF
On Mon, Dec 09, 2002 at 11:26:30AM -0700, Justin Kay wrote:
> From: Justin Kay <jkay@nwrecc.org>
> To: "Netfilter (E-mail)" <netfilter@lists.netfilter.org>
> Subject: iptables and Poptop
> X-Mailer: Internet Mail Service (5.5.2653.19)
> Date: Mon, 9 Dec 2002 11:26:30 -0700
>
> I am trying to set up a server as a firewall/vpn server. I am using
> iptables 1.2.6a and poptop 1.1.3. I can connect to the poptop server just
> fine from the internet. I can ping to the 10.0.0.1 address that my poptop
> server uses on the internal interface from the poptop client, but I don't
> get any further that that. I can't ping anything else internally (ten net
> addresses) and I can't ping out to the address issued to the poptop client
> from a LAN machine. Any ideas on where to look?
>
> Rules:
>
> ########################## Policy Section #########################
>
> $IPTABLES -P INPUT DROP
> $IPTABLES -P OUTPUT DROP
> $IPTABLES -P FORWARD DROP
>
> ####################### User defined chains #####################
>
> $IPTABLES -N icmp_packets
>
> $IPTABLES -A icmp_packets -p ICMP --icmp-type 8 -j ACCEPT
> $IPTABLES -A icmp_packets -p ICMP --icmp-type 11 -j ACCEPT
> $IPTABLES -A icmp_packets -p ICMP --icmp-type 3 -j ACCEPT
> $IPTABLES -A icmp_packets -p ICMP -s $LAN_IP_RANGE -j ACCEPT
>
> ########################## Input Section ################################
>
> $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT
> $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LAN_IP -j ACCEPT
> $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $INET_IP -j ACCEPT
> $IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s $LAN_IP_RANGE -j ACCEPT
>
> $IPTABLES -A INPUT -p ALL -d $INET_IP -m state --state ESTABLISHED,RELATED
\
> -j ACCEPT
> $IPTABLES -A INPUT -p TCP --dport 1723 -j ACCEPT
> $IPTABLES -A INPUT -p 47 -j ACCEPT
>
> $IPTABLES -A INPUT -i ppp+ -j ACCEPT
>
> $IPTABLES -A INPUT -p ICMP -j icmp_packets
>
> $IPTABLES -A INPUT -j LOG --log-prefix "INPUT chain "
> ########################### Forward Section #############################
>
> $IPTABLES -A FORWARD -i $INET_IFACE -p tcp -d $NT --dport 25 -j ACCEPT
> $IPTABLES -A FORWARD -i $INET_IFACE -p tcp -d $NT --dport 110 -j ACCEPT
> $IPTABLES -A FORWARD -i $INET_IFACE -p tcp -d $TETON --dport 80 -j ACCEPT
> $IPTABLES -A FORWARD -i $INET_IFACE -p tcp -d $TETON --dport 443 -j ACCEPT
> #$IPTABLES -A FORWARD -p ICMP -j icmp_packets
> $IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
> $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> $IPTABLES -A FORWARD -i ppp+ -o $LAN_IFACE -j ACCEPT
> $IPTABLES -A FORWARD -i $LAN_IFACE -o ppp+ -j ACCEPT
>
> $IPTABLES -A FORWARD -j LOG --log-prefix "FORWARD chain "
> ########################### Output Section ###############################
>
> $IPTABLES -A OUTPUT -p ALL -o ppp+ -j ACCEPT
> $IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
> $IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
> $IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT
> $IPTABLES -A OUTPUT -p ALL -s $INET_IP2 -j ACCEPT
> $IPTABLES -A OUTPUT -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> $IPTABLES -A OUTPUT -j LOG --log-prefix "OUTPUT packet died: "
>
> ########################## end script ####################################
>
> Justin
^ permalink raw reply
* Re: [PATCH] Re: #! incompatible -- binfmt_script.c broken?
From: Pavel Machek @ 2002-12-09 21:49 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux-kernel
In-Reply-To: <at2qin$fgn$1@cesium.transmeta.com>
Hi!
> > > > Why can't we simply have /bin/bash_that_splits_args_itself
> > >
> > > We could, but it would in practice mean doing an extra exec() for each
> > > executable. This seems undesirable.
> >
> > Only for executables that need argument spliting... For such scripts I
> > guess we can get handle the overhead.
> >
>
> We probably can, but a better question is really: what are the
> semantics that users expect? Given that Unices are by and large
> inconsistent, we should pick the behaviour that makes sense to the
> most people. I suspect that most people would expect whitespace
> partition.
Most people would also expect " and ' to work, and $FOO to work
:-(. So I believe keeping it simple is right.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* boot sequence
From: dave @ 2002-12-10 19:57 UTC (permalink / raw)
To: linux-newbie
I'm having a problem with MySQL starting on boot and I don't quit understand
the boot sequence of Mandrake 9.0. What files get executed and where they
are located. Anyone have a link to a writeup about this? Thanks for your
time.
Dave Pomeroy K7DNP SouthWestern Washington
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: Why does C3 CPU downgrade in kernel 2.4.20?
From: Daniel Egger @ 2002-12-10 19:39 UTC (permalink / raw)
To: Alan Cox; +Cc: Dave Jones, Linux Kernel Mailing List
In-Reply-To: <1039539080.14302.29.camel@irongate.swansea.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
Am Die, 2002-12-10 um 17.51 schrieb Alan Cox:
> Well if you optimise for ppro it won't actually always work.
Yeah, I had to learn earlier that it seems to support certain
kind of cmovs but certainly not all of them and some other
instructions seem also to be missing.
> Also thescheduling seems to be best with 486.
> Remember the C3 is a single issue risc processor.
Do you have pointers to some optimisation manual or whatever?
gcc currently defines the c3 as 486+mmx+3dnow however I doubt
that this model is entirely correct and as such leaves some
space for improvements.
> --
> Servus,
> Daniel
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* "get_cnode failed" error
From: Alexandre Ratti @ 2002-12-10 19:55 UTC (permalink / raw)
To: reiserfs-list
Hello,
I got a "get_cnode failed" error while running a script on a large ReiserFS
partition (120 GB). Snippet from /var/syslog is included below. The system
did not crash. I did not find any other error in the system log.
When the error happened, the system was running a Linux 2.4.18 kernel
(compiled with source package from Debian stable). System is Debian Woody.
I've just moved to a 2.4.19 kernel.
I checked the partition with reiserfsck. No corruption found.
The FS looks OK, but I'm curious. What does this error mean? It is serious?
Thanks.
Alexandre
----------
Dec 10 00:15:01 p120 /USR/SBIN/CRON[7356]: (backup) CMD
(/usr/local/bin/roller.py)
Dec 10 00:18:39 p120 kernel: <0>get_cnode failed!
Dec 10 00:18:40 p120 kernel: invalid operand: 0000
Dec 10 00:18:40 p120 kernel: CPU: 0
Dec 10 00:18:40 p120 kernel: EIP: 0010:[reiserfs_panic+41/88] Not tainted
Dec 10 00:18:40 p120 kernel: EFLAGS: 00010282
Dec 10 00:18:40 p120 kernel: eax: 00000015 ebx: c0215ada ecx:
c087e000 edx: c118da80
Dec 10 00:18:40 p120 kernel: esi: c13be000 edi: 00000000 ebp:
c13be000 esp: c087fe30
Dec 10 00:18:40 p120 kernel: ds: 0018 es: 0018 ss: 0018
Dec 10 00:18:40 p120 kernel: Process cp (pid: 7360, stackpage=c087f000)
Dec 10 00:18:40 p120 kernel: Stack: c0212f5a c02909e0 c0215ada c087fe54
c087ff2c c20d7140 c01813d9 c13be000
Dec 10 00:18:40 p120 kernel: c0215ada 0141411a c20d7140 c087fe98
c087ff08 c016cfb0 ffffffff 00000000
Dec 10 00:18:40 p120 kernel: c016d11b c087ff2c c13be000 c20d7140
c087feb0 c0392460 c0392460 c087ff2c
Dec 10 00:18:40 p120 kernel: Call Trace: [journal_mark_dirty+501/772]
[update_st at_data+224/232] [reiserfs_update_sd+355/380]
[reiserfs_link+199/256] [vfs_link+137/188]
Dec 10 00:18:41 p120 kernel: [sys_link+212/308] [sys_lstat64+100/112]
[system_call+51/64]
Dec 10 00:18:41 p120 kernel:
Dec 10 00:18:41 p120 kernel: Code: 0f 0b 68 e0 09 29 c0 85 f6 74 11 31 c0
66 8b 46 08 50 e8 88
----------
^ permalink raw reply
* Re: [BENCHMARK] 2.5.51 with contest
From: Stan Bubrouski @ 2002-12-10 20:02 UTC (permalink / raw)
To: Robert Love; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <1039545941.1831.849.camel@phantasy>
Robert Love wrote:
> On Tue, 2002-12-10 at 12:18, Stan Bubrouski wrote:
>
>
>>I know this has been brought up before, but
>>these don't seem to mean much unless you
>>include 2.4.20 in the comaprison.
>
>
> Comparing this to 2.4 achieves nothing because so much changed.
I disagree, 2.4.20 is the current stable kernel, it would
be nice to see how it compares to the current development,
what's faster, what's not... from Con's previous results
we can see that some things are indeed not as fast in 2.5.x
as in 2.4.x. It's just nice to be able to see the whole
picture. I often follow these threads for just this purpose.
-Stan
>
> The point of these benchmarks are not marketing, but to find
> improvements or regressions from one version to the next and find out
> what caused them.
>
> Comparing the kernel to 2.4 has some uses (i.e. finding micro-ops) but
> Con's mission is much different (and imo more useful).
>
> Robert Love
>
^ permalink raw reply
* Re: fetchmail and smtp problem (was tuning iptables)
From: Haines Brown @ 2002-12-10 19:43 UTC (permalink / raw)
To: carl; +Cc: linux-newbie
In-Reply-To: <5.1.1.6.0.20021210124205.01f826f0@pop3.demon.co.uk>
Here are some preliminary results on fetchmail.
------------------
When I originally ran netsat -l, I got:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:smtp *:* LISTEN
But now for some reason it has changed to:
tcp 0 0 hartford-hwp.com:smtp *:* LISTEN
Whatever the reason for the change, I gather this means something is
listing on the smtp port (25).
--------------------
Setting up /etc/mail/access. I have:
localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY You suggest inserting
--------------------
I also checked /etc/mail/local-host-names. It is empty by default.
You suggest entering "mailserver.mydomain.com", but since my machine
has neither a static IP address nor hame, I was not sure what to do. I
instead just put in my hostname (hartford-hwp.com), figuring it would
do no harm.
# local-host-names - include all aliases for your machine here.
localhost
localhost.localdomain
hartford-hwp.com
--------------------
Next, I ran netstat -lp
# netstat -lp
tcp 0 0 *:smtp *:* LISTEN 856/sendmail: accep
Port 25 accepts messages from sendmail?
--------------------
I started a telnet session, but didn't log in. Will do that, too, if
useful.
# telnet localhost 25
Trying 127.0.0.1...
Connected to hartford-hwp.com (127.0.0.1).
Escape character is '^]'.
220 hartford-hwp.com ESMTP Sendmail 8.12.5/8.12.5; Tue, 10 Dec 2002
13:12:00 -0500
-------------------
I didn't know what might be useful from /etc/mail/sendmail.cf, but as
I waited thinking about that, I saw that my fetchmail -k command
actually carried through. It took about 20 seconds to start the first
download. The next few messages took about 10 seconds each. Then a
batch of about 8 downloaded normally (2-3 seconds for the batch), then
slow again. Then fast again. The pattern was consistent for additional
tries.
The first messages was an undeliverable notive from when I tried to
send myself a test message almost a week ago:
brownh@hartford-hwp.com... Deferred: hartford-hwp.com.: Network is unreachable
After five days, it was deleted from queue. The batch of test messages
I sent myself (also 127.0.0.1, also localhost.localdomain) fell into a
black hole.
I don't know where to look for a fechmail log, but I ran fetchmail -v
-v > /opt/tmp/-fetchmail.log. Because it was just one new message that
(successfully) downloaded, I'll here venture to paste the entire log:
Oops. Left it on the wrong HD. Will have to retrieve it next time I
boot the disk. But the message did not wave any red flags (but I may
well not recognize one even if I saw it).
Haines
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: move LOG_BUF_SIZE to header file
From: Andrew Morton @ 2002-12-10 19:41 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.33L2.0212101108550.12283-100000@dragon.pdx.osdl.net>
"Randy.Dunlap" wrote:
>
> Hi,
>
> I'd like to see LOG_BUF_LEN from kernel/printk.c moved to a header file
> so that some non-kernel (kernel-mode) tools can know the value being
> used (tools like kmsgdump or lkcd etc.).
>
> This patch moves LOG_BUF_LEN to include/linux/kernel.h .
> Or it could go to a separate (new) header file...
>
> ...
> -#if defined(CONFIG_X86_NUMAQ) || defined(CONFIG_IA64)
> -#define LOG_BUF_LEN (65536)
> -#elif defined(CONFIG_ARCH_S390)
> -#define LOG_BUF_LEN (131072)
> -#elif defined(CONFIG_SMP)
> -#define LOG_BUF_LEN (32768)
> -#else
> -#define LOG_BUF_LEN (16384) /* This must be a power of two */
> -#endif
> -
> -#define LOG_BUF_MASK (LOG_BUF_LEN-1)
It's probably better to move all this gunk into the config
system. Then your app can use CONFIG_LOG_BUF_LEN, too.
^ permalink raw reply
* Trouble with kernel 2.4.18-18.7.x
From: Karina @ 2002-12-10 19:33 UTC (permalink / raw)
To: linux-kernel
Hi, i've just installed kernel 2.4.18-18.7.x (from RPM) and now it
seems there are problems with my scsi devices.
I have attached an adaptec scsi AIC7XXX adapter, the system detects the
device, but in the logs appears messages: "blk: queue c24afa18, I/0
limit 4095Mb (mask0xfffffff)", these messages didn't appear before with
my old kernel.
Also, there are another messages in the dmesg results:
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter errno = 2
When i try to list or do something with my tape the message: st0 block
limits 1 - 16777215 bytes appears...
Sorry i'm new in this ?
Is this a bug ? a big one ? should i use instead my old kernel ?
Thanks in advance,
Karina.
^ permalink raw reply
* Re: GDB patch
From: Daniel Jacobowitz @ 2002-12-10 19:32 UTC (permalink / raw)
To: nigel; +Cc: Carsten Langgaard, Ralf Baechle, linux-mips
In-Reply-To: <15862.15924.283825.28108@hendon.algor.co.uk>
On Tue, Dec 10, 2002 at 07:19:16PM +0000, Nigel Stephens wrote:
> > On Tue, Dec 10, 2002 at 01:07:31PM +0100, Carsten Langgaard wrote:
> >
> > > I've attached a patch for gdb-stub.c to make it work better with the
> > > sde-gdb.
> > > These changes should be backwards compatible with a standard gdb, so it
> > > shouldn't break anything.
> > > Ralf, could you please apply it.
> >
> >
> > Strongly object. While I didn't check the implementation, it's nice to
> > see 'X' implemented. And P. But what the heck is this?
> >
> >
> > > @@ -816,13 +839,64 @@
> > > case 'k' :
> > > break; /* do nothing */
> > >
> > > + case 'R':
> > > + /* RNN[:SS], Set the value of CPU register NN (size SS) */
> > > + /* FALL THROUGH */
> >
> >
> > > - /*
> > > - * Reset the whole machine (FIXME: system dependent)
> > > - */
> > > case 'r':
> > > - break;
> > > + /* rNN[:SS] Return the value of CPU register NN (size SS) */
> >
> >
> >
> > We're not making up a protocol here, we're implementing one. R and r
> > don't have anything to do with setting registers.
>
> Hi Dan
>
> Actually Carsten *is* trying to implement a protocol, it's just that
> it's an extension to the gdb remote debug protocol, as used in our
> SDE-MIPS toolchain (viz sde-gdb). Algorithmics (now MIPS Technologies
> UK), always extended the gdb remote debug protocol to support reading
> and writing of single registers, and to support variable register
> sizes (to allow a 64-bit debug stub to inter-work with gdb debugging a
> 32-bit application).
My point is that we implement the GDB protocol, for use with GDB -
implementing random extensions to it is not a good idea. I would
strongly prefer these extensions be discussed on the GDB list before
you try adding them to the CVS tree. Also, I bet Andrew has a
different idea of how the 64/32 thing ought to work than you do. He's
the remote protocol maintainer.
These things should be planned on the GDB side before making yet more
stubs use them.
> When we first implemented these extensions we used the 'R' command to
> write a single register, and 'r' to read one (they weren't then used
> by gdb). Since then the remote protocol has gained the 'P' command to
'R' was added in 1995 according to my records. Really?
> write a single register, so we no longer use 'R' - and it would be
> dangerous to do so since it can restart the target (so you can get rid
> of the special 'R' case, Carsten).
>
> But the standard gdb remote protocol still doesn't have the ability to
> read a single register, so I believe that 'r' (or something like it)
> is a useful addition, which speeds up the remote protocol
> significantly when running over a serial line. And it won't break the
> kernel to add support for this extension.
The protocol does, actually. GDB doesn't _implement_ it, but the
extension is documented in the manual ('p') and I wouldn't be surprised
if Red Hat actually had an implementation somewhere. I recommend the
documentation of the protocol, on the GDB web site.
Also note that `R' is extended restart process; the manual lists `r' as
"restart entire target system". I don't know when that was used but
it's reason enough to stay away from using that letter to read a
register.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* Re: 2.5.51 won't boot with devfs enabled
From: Eric Buddington @ 2002-12-10 19:36 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200212101645.gBAGii6R019092@mail.wesleyan.edu>
This fixed my problem (though now it doesn't find init, *sigh*)
-Eric
On Tue, Dec 10, 2002 at 04:44:43PM +0000, jordan.breeding@attbi.com wrote:
> Are you using grub to boot? If so try using something
> like /dev/discs/disc0/part1 or the full ide /dev pathname for devfs to boot
> with instead of /dev/hda1. I have a scsi disk subsystem and have to
> use /dev/discs/disc0/part9 instead of /dev/sda9 to get devfs to work.
>
> Jordan
> > With 2.5.51 (gcc-3.2, Athlon, mostly modules, DEVFS=y, DEVFS_DEBUG=y),
> > boot panics with "VFS: Cannot open root device "hda1" or
> > 03:01".
> >
> > I had the same problem with 2.5.50, avoidable by disabling devfs entirely.
> >
> > -Eric
> > -
> > 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: [parisc-linux] SMP on kernel version 19 pa 23
From: Randolph Chung @ 2002-12-10 19:31 UTC (permalink / raw)
To: FARINATI,LEANDRO (HP-Brazil,ex1); +Cc: Parisc-Linux List (E-mail)
In-Reply-To: <9A0482A7BD2506488AD9417C93F3714FB4ABC3@xsp01.brazil.hp.com>
> I'm make this question because when I enable SMP to compile this
> kernel and put it to run, it crashes when the systen try do boot.
> If anyone know something about this, please give me a tip to solve
> this.
Please follow http://www.parisc-linux.org/faq/kernelbug-howto.html to
report the problem.
randolph
^ permalink raw reply
* Re: [parisc-linux] SMP on kernel version 19 pa 23
From: Grant Grundler @ 2002-12-10 19:24 UTC (permalink / raw)
To: FARINATI,LEANDRO (HP-Brazil,ex1); +Cc: Parisc-Linux List (E-mail)
In-Reply-To: <9A0482A7BD2506488AD9417C93F3714FB4ABC3@xsp01.brazil.hp.com>
On Tue, Dec 10, 2002 at 10:41:00AM -0800, FARINATI,LEANDRO wrote:
> I would link to know if the SMP is working on kernel 19 pa 23, 32
> bits?
I assume you mean 2.4.19-pa23.
IIRC 2.4.19-pa24 booted/worked on a500 (64-bit) and I thought that was
an SMP kernel but aren't sure now.
> I'm make this question because when I enable SMP to compile this
> kernel and put it to run, it crashes when the systen try do boot.
can you post the console output?
And you .config file? (if it's not the default)
grant
^ 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.