Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds
On Sun, Mar 17, 2013 at 09:48:46PM +, Will Deacon wrote: > Due to all of the goodness being packed into today's kernels, the > resulting image isn't as slim as it once was. > > In light of this, don't pass -msmall-data to the tools, which results in > link failures due to impossible relocations when compiling anything but > the most trivial configurations. I use the same patch locally for quite some time, so Tested-by: Thorsten Kranzkowski > > Cc: Richard Henderson > Cc: Ivan Kokshaysky > Cc: Matt Turner > Signed-off-by: Will Deacon > --- > arch/alpha/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile > index 4759fe7..2cc3cc5 100644 > --- a/arch/alpha/Makefile > +++ b/arch/alpha/Makefile > @@ -12,7 +12,7 @@ NM := $(NM) -B > > LDFLAGS_vmlinux := -static -N #-relax > CHECKFLAGS += -D__alpha__ -m64 > -cflags-y := -pipe -mno-fp-regs -ffixed-8 -msmall-data > +cflags-y := -pipe -mno-fp-regs -ffixed-8 > cflags-y += $(call cc-option, -fno-jump-tables) > > cpuflags-$(CONFIG_ALPHA_EV4) := -mcpu=ev4 -- | Thorsten KranzkowskiInternet: dl8...@dl8bcu.de | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8...@marvin.dl8bcu.ampr.org [44.130.8.19] | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] task_work: Add local_irq_enable() into task_work_run()
On Sat, Oct 13, 2012 at 10:09:36AM +0900, Linus Torvalds wrote: > On Sat, Oct 13, 2012 at 1:03 AM, Oleg Nesterov wrote: > > arch/alpha and probably some other architectures call > > do_notify_resume()->task_work_run() with irqs disabled. > > I'm going to ignore this patch because I *hope* it is unnecessary > after the pull from Al that I just did. > > But if that turns out to be not the case, please holler. Torsten, you > seem to be the one who reported this, can you check the current git > tree? I can confirm that 4d7127d (i.e. without Olegs patch) boots without problems. There is still the warning below, but it was already present before the breakage. Thanks to everyone involved, Thorsten > > Thanks, > >Linus SMP starting up secondaries. Brought up 2 CPUs SMP: Total of 2 processors activated (1985.89 BogoMIPS). xor: automatically using best checksumming function: alpha prefetch: 2097.152 MB/sec NET: Registered protocol family 16 [ cut here ] WARNING: at /usr/src/linux.git/kernel/softirq.c:139 __local_bh_enable+0x8c/0xbc() Modules linked in: fcb83c80 fcb924b8 fc32cc14 fcbc4078 0200 0001 fc32d130 fcb7d980 fcc27160 fc3535c4 fc31a93c fcb84000 fc3157a0 fcb83dc0 0be0 fc0001e060c0 Trace: [] __local_bh_enable+0x8c/0xbc [] irq_enter+0x58/0x78 [] scheduler_ipi+0x50/0xec [] handle_ipi+0xb8/0x248 [] do_entInt+0x6c/0x240 [] irq_exit+0x68/0x7c [] handle_irq+0xd4/0xf4 [] do_entInt+0x130/0x240 [] ret_from_sys_call+0x0/0x10 [] load_balance+0x1e4/0x770 [] cpu_idle+0x2c/0x6c [] atomic_add.constprop.42+0x0/0x14 [] cpu_idle+0x38/0x6c [] rest_init+0xc0/0xd4 [] _stext+0x1c/0x20 ---[ end trace 40b31a85666b44ea ]--- PCI host bridge to bus :00 pci_bus :00: root bus resource [io 0x-0x1ff] pci_bus :00: root bus resource [mem 0x-0x3fff] pci_bus :00: No busn resource found for root bus, will use [bus 00-ff] -- | Thorsten KranzkowskiInternet: dl8...@dl8bcu.de | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8...@marvin.dl8bcu.ampr.org [44.130.8.19] | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] boot failure on alpha, bisected
On Sun, Oct 07, 2012 at 09:16:27PM +0200, Oleg Nesterov wrote: > On 10/07, Thorsten Kranzkowski wrote: > > On Sun, Oct 07, 2012 at 07:13:00PM +0200, Oleg Nesterov wrote: > > > On 10/07, Oleg Nesterov wrote: > > > > > > > > Hmm. I know nothing about arch/alpha and I can't understand its entry.S. > > > > But _it seems_ to me that do_notify_resume() is called with irqs > > > > disabled. > > > > If this is true, then imho arch/alpha should be fixed. > > > > > > > > Before this commit task_work_run() enabled irqs, but this was the "side > > > > effect" of spin_lock_irq/spin_unlock_irq, we should not rely on this. > > > > > > Could you please test the debugging patch below? > > > > Of course. With that patch applied the kernel (ac3d0da) boots again. The > > trace line > > is printed about once a second, with values '2' and '4'. > > Thanks a lot Thorsten! > > So I'll probably send the patch which enables interrupts in > task_work_run(). I guess this needs "if (irqs_disabled())" > for lockdep. > > The question is, should I add the warning to remind that this > arch needs a fix? If you do, then please warn only once, otherwise there will be a lot of warnings :-) Thorsten -- | Thorsten KranzkowskiInternet: dl8...@dl8bcu.de | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8...@marvin.dl8bcu.ampr.org [44.130.8.19] | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] boot failure on alpha, bisected
On Sun, Oct 07, 2012 at 07:13:00PM +0200, Oleg Nesterov wrote:
> On 10/07, Oleg Nesterov wrote:
> >
> > Hmm. I know nothing about arch/alpha and I can't understand its entry.S.
> > But _it seems_ to me that do_notify_resume() is called with irqs disabled.
> > If this is true, then imho arch/alpha should be fixed.
> >
> > Before this commit task_work_run() enabled irqs, but this was the "side
> > effect" of spin_lock_irq/spin_unlock_irq, we should not rely on this.
>
> Could you please test the debugging patch below?
Of course. With that patch applied the kernel (ac3d0da) boots again. The trace
line
is printed about once a second, with values '2' and '4'.
Thorsten
>
> Oleg.
>
>
> --- x/arch/alpha/kernel/signal.c
> +++ x/arch/alpha/kernel/signal.c
> @@ -567,11 +567,19 @@ do_signal(struct pt_regs * regs, struct
> ptrace_set_bpt(current);/* re-set breakpoint */
> }
>
> +#include
> +
> void
> do_notify_resume(struct pt_regs *regs, struct switch_stack *sw,
>unsigned long thread_info_flags,
>unsigned long r0, unsigned long r19)
> {
> + if (irqs_disabled()) {
> + printk_ratelimited(KERN_WARNING
> + "NOTIFY with irqs_disabled:%lx\n", thread_info_flags);
> + local_irq_enable();
> + }
> +
> if (thread_info_flags & _TIF_SIGPENDING)
> do_signal(regs, sw, r0, r19);
>
>
--
| Thorsten KranzkowskiInternet: dl8...@dl8bcu.de |
| Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8...@marvin.dl8bcu.ampr.org [44.130.8.19] |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Silent data corruption when using sendfile()
On Sat, Jul 14, 2012 at 12:33:24PM +0200, Eric Dumazet wrote: > On Sat, 2012-07-14 at 12:13 +0200, Johannes Truschnigg wrote: > > On Sat, Jul 14, 2012 at 10:31:36AM +0200, Willy Tarreau wrote: > > > > Please Johannes could you try latest kernel tree ? > > > > > > It would be useful, especially given the amount of changes you performed > > > in this area in latest version, it could be very possible that this new > > > bug got fixed as a side effect ! > > > > I upgraded to 3.4.4 (identical config as the 3.4.0 build I've been running) > > and what can I say - the problem really seems to have disappeared. I > > performed > > about 3700 iterations of my previos tests over the night, and the data > > always > > turned out to be OK, not a single byte turned out kaput! > > > > I wish I would have tested that earlier, and spared you the noise... well, > > maybe someone who runs into a similar problem in the future will have this > > discovery save her/him some time and headaches and make her/him just upgrade > > kernels :) > > > > Thanks a lot for your polite and quick responses! > > > > Nice to hear. Now we should make sure we have all needed fixes for prior > stable kernels as well ! > > Still trying to understand the issue, since I thought I only did > optimizations, not bug fixes. So maybe real bug is still there but its > probability of occurrence lowered enough to not hit your workload. > > Hmmm... > Not sure if this is related, but I had a similar data corruption problem: Reading data from filesystem 'normally' (including through nfs) showed corruption at random places, mostly 0xff tuning into 0xfe. Reading with ODIRECT (I used 'dd iflag=direct') was OK. I found my problem to be fixed by fffaee365fded09f9ebf2db19066065fa54323c3 (upstrem) which was backported as b642cb6a143da812f188307c2661c0357776a9d0 (stable, v3.4.1-66-gb642cb6) Bye, Thorsten -- | Thorsten KranzkowskiInternet: dl8...@dl8bcu.de | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8...@marvin.dl8bcu.ampr.org [44.130.8.19] | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: high load average when idle
On Tue, Oct 02, 2007 at 11:37:31PM +0200, Anders Bostr?m wrote: > Hi! > > My computer suffers from high load average when the system is idle, > introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 . Another datapoint: I observe a similar effect on both of my alphas: top - 09:30:43 up 13 min, 18 users, load average: 0.65, 0.64, 0.44 Tasks: 76 total, 1 running, 75 sleeping, 0 stopped, 0 zombie Cpu(s): 0.1% us, 0.5% sy, 0.0% ni, 99.1% id, 0.2% wa, 0.1% hi, 0.0% si Mem: 2067792k total,55792k used, 2012000k free, 4160k buffers Swap: 1048560k total,0k used, 1048560k free,18752k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 637 root 15 0 2904 1552 1192 R1 0.1 0:01.35 top 556 root 15 0 2008 528 432 S0 0.0 0:00.01 gpm 1 root 15 0 1960 800 680 S0 0.0 0:01.43 init 2 root 10 -5 000 S0 0.0 0:00.00 kthreadd 3 root RT -5 000 S0 0.0 0:00.00 migration/0 4 root 34 19 000 S0 0.0 0:00.00 ksoftirqd/0 5 root RT -5 000 S0 0.0 0:00.00 watchdog/0 6 root RT -5 000 S0 0.0 0:00.00 migration/1 7 root 34 19 000 S0 0.0 0:00.00 ksoftirqd/1 This is the dual-ev6 one, currently 2.6.22-rc5. I didn't bother to do any investigation, yet ;-) > This fixes the problem: I'll check this evening. Bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED] | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: [EMAIL PROTECTED], [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Odd log message associated with NFS
On Wed, Mar 28, 2007 at 07:23:48PM -0400, J. Bruce Fields wrote:
> On Wed, Mar 28, 2007 at 07:05:36PM +0000, Thorsten Kranzkowski wrote:
> > I'll let a tcpdump run this evening and see if I can correlate the message
> > with anything.
> >
> > If you have a printk or other patch for me to try, just let me know.
>
> Well, just for fun, you could try something like this--should dump some
> data the first time it hits the "bad direction" error.
Time to check my iptables setup it seems
Thanks for the lesson ;-)
The source address obviously isn't from my local net, and the clear text speaks
for itself. looks like an attack to some Windows service with phishing content.
luckily this machine is neither windows based nor intel compatible :)
bye,
Thorsten
Mar 30 18:29:54 Marvin kernel: svc: bad direction 268435456, dropping request
Mar 30 18:29:54 Marvin kernel: dumping request; rq_addr = 61.180.228.240,
port=59653, rq_deferred = , rq_arg:
Mar 30 18:29:54 Marvin kernel: buf->head[0].iov_base = fc0008ea8850,
buf->head[0].iov_len = 887
Mar 30 18:29:54 Marvin kernel: buf->tail[0].iov_base = ,
buf->tail[0].iov_len = 0
Mar 30 18:29:54 Marvin kernel: pages = fc000b1bd168, page_base = 0,
page_len = 0
Mar 30 18:29:54 Marvin kernel: buflen = 0, len = 899
Mar 30 18:29:54 Marvin kernel: head data (from fc0008ea8844):
Mar 30 18:29:54 Marvin kernel: RPC: print_hexl: length 899
Mar 30 18:29:54 Marvin kernel: : 0400 2800 1000
..(.
Mar 30 18:29:54 Marvin kernel: 0010: f891 7b5a 00ff d011
..{Z
Mar 30 18:29:54 Marvin kernel: 0020: a9b2 00c0 4fb6 e6fc
O...
Mar 30 18:29:54 Marvin kernel: 0030: 0100
Mar 30 18:29:54 Marvin kernel: 0040: 3303
..3.
Mar 30 18:29:54 Marvin kernel: 0050: 1000 1000 5359 5354
SYST
Mar 30 18:29:54 Marvin kernel: 0060: 454d 1000
EM..
Mar 30 18:29:54 Marvin kernel: 0070: 1000 414c 4552 5400
ALERT...
Mar 30 18:29:54 Marvin kernel: 0080: ef02
Mar 30 18:29:54 Marvin kernel: 0090: ef02 596f 7572 2073 7973 7465 6d20
Your system
Mar 30 18:29:54 Marvin kernel: 00a0: 7265 6769 7374 7279 2069 7320 636f 7272
registry is corr
Mar 30 18:29:54 Marvin kernel: 00b0: 7570 7465 6420 616e 6420 6e65 6564 7320
upted and needs
Mar 30 18:29:54 Marvin kernel: 00c0: 746f 2062 6520 636c 6561 6e65 6420 696d
to be cleaned im
Mar 30 18:29:54 Marvin kernel: 00d0: 6d65 6469 6174 656c 792e 0a0a 0a43 6f6d
mediatelyCom
Mar 30 18:29:54 Marvin kernel: 00e0: 7072 6f6d 6973 6564 2072 6567 6973 7472
promised registr
Mar 30 18:29:54 Marvin kernel: 00f0: 7920 6669 6c65 7320 6361 6e20 6c65 6164
y files can lead
Mar 30 18:29:54 Marvin kernel: 0100: 2074 6f20 7468 6520 666f 6c6c 6f77 696e
to the followin
Mar 30 18:29:54 Marvin kernel: 0110: 673a 0a0a 312e 2043 6f6d 706c 6574 6520
g:..1. Complete
Mar 30 18:29:54 Marvin kernel: 0120: 6163 6365 7373 206f 6620 796f 7572 2050
access of your P
Mar 30 18:29:54 Marvin kernel: 0130: 4320 6279 2068 6163 6b65 7273 0a32 2e20
C by hackers.2.
Mar 30 18:29:54 Marvin kernel: 0140: 536c 6f77 2073 7065 6564 7320 7265 7375
Slow speeds resu
Mar 30 18:29:54 Marvin kernel: 0150: 6c74 696e 6720 696e 2073 6c6f 7720 646f
lting in slow do
Mar 30 18:29:54 Marvin kernel: 0160: 776e 6c6f 6164 7320 6f66 2069 6e74 6572
wnloads of inter
Mar 30 18:29:54 Marvin kernel: 0170: 6e65 7420 6669 6c65 730a 332e 2054 6865
net files.3. The
Mar 30 18:29:54 Marvin kernel: 0180: 2063 6f6d 7072 6f6d 6973 6520 6f66 2070
compromise of p
Mar 30 18:29:54 Marvin kernel: 0190: 6572 736f 6e61 6c20 696e 666f 726d 6174
ersonal informat
Mar 30 18:29:54 Marvin kernel: 01a0: 696f 6e20 7374 6f72 6564 206f 6e20 796f
ion stored on yo
Mar 30 18:29:54 Marvin kernel: 01b0: 7572 2063 6f6d 7075 7465 720a 342e 2043
ur computer.4. C
Mar 30 18:29:54 Marvin kernel: 01c0: 6f6d 706c 6574 6520 7379 7374 656d 2066
omplete system f
Mar 30 18:29:54 Marvin kernel: 01d0: 6169 6c75 7265 2072 6573 756c 7469 6e67
ailure resulting
Mar 30 18:29:54 Marvin kernel: 01e0: 2069 6e20 7468 6520 6e65 6564 2066 6f72
in the need for
Mar 30 18:29:54 Marvin kernel: 01f0: 2061 2063 6f6d 706c 6574 6520 7265 696e
a complete rein
Mar 30 18:29:54 Marvin kernel: 0200: 7374 616c 6c20 6f66 2079 6f75 7220 6861
stall of your ha
Mar 30 18:29:54 Marvin kernel: 0210: 7264 2064 7269 7665 2e0a 0a54 6f20 6669
rd drive...To fi
Mar 30 18:29:54 Marvin kernel: 0220: 7820 7468 6973 2070 726f 626c 656d 3a0a
x this problem:.
Mar 30 18:29:54
Re: Odd log message associated with NFS
On Wed, Mar 28, 2007 at 12:19:52PM +1000, Neil Brown wrote:
> On Tuesday March 27, [EMAIL PROTECTED] wrote:
> > On Tue, Mar 27, 2007 at 11:40:48AM -0700, Phy Prabab wrote:
> > > kernel: rpcsvc: received unknown control message:-2144992132/-1
> >
> > Just a 'me, too':
>
> For the 'unknown control message' messages,
> see: "fix typo in svc_udp_recvfrom" previously on
> [EMAIL PROTECTED]
>
> Fix is in -mm and below.
will try, thanks.
> For "svc: bad direction" Don't know... garbage on the net maybe?
> Or maybe not. I have seen something like that before, but haven't
I don't think so as it would mean corruption at other places, too. The
Network is quite uninteresting: single ethernet segment, 2 switches
involved, longest cable 8 meters ...
> been able to pin it on anything yet.
> NeilBrown
I _had_ problems with the previous kernel (same version, same config,
different (older) compiler (gcc 3.4.5 instead of 4.1.2), on both client and
server)
It would randomly (usually within 30 mins) 'lock up' NFS, where the client
sends out requests but doesn't get any answer (apart from tcp-ack) from the
server. Only a forced umount/remount recovered that (until the next lock-up).
But I'm willing to attribute that to a somehow broken gcc.
again, thanks for commenting.
bye,
Thorsten
> --- linux-2.6.orig/net/sunrpc/svcsock.c
> +++ linux-2.6/net/sunrpc/svcsock.c
> @@ -779,7 +779,7 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
> }
>
> clear_bit(SK_DATA, &svsk->sk_flags);
> - while ((err == kernel_recvmsg(svsk->sk_sock, &msg, NULL,
> + while ((err = kernel_recvmsg(svsk->sk_sock, &msg, NULL,
> 0, 0, MSG_PEEK | MSG_DONTWAIT)) < 0 ||
> (skb = skb_recv_datagram(svsk->sk_sk, 0, 1, &err)) == NULL) {
> if (err == -EAGAIN) {
>
>
> >
> > Mar 16 16:57:06 Marvin kernel: svc: bad direction 268435456, dropping
> > request
> > Mar 16 17:58:19 Marvin kernel: svc: bad direction 268435456, dropping
> > request
> > Mar 16 19:55:49 Marvin kernel: svc: bad direction 268435456, dropping
> > request
> > ...
> > Mar 17 04:30:03 Marvin kernel: svc: bad direction 268435456, dropping
> > request
--
| Thorsten KranzkowskiInternet: [EMAIL PROTECTED] |
| Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany |
| Ampr: [EMAIL PROTECTED], [EMAIL PROTECTED] [44.130.8.19] |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Odd log message associated with NFS
On Wed, Mar 28, 2007 at 12:59:25PM -0400, J. Bruce Fields wrote: > On Tue, Mar 27, 2007 at 07:39:10PM +0000, Thorsten Kranzkowski wrote: > > Mar 16 16:57:06 Marvin kernel: svc: bad direction 268435456, dropping > > request > > Mar 16 17:58:19 Marvin kernel: svc: bad direction 268435456, dropping > > request > > Mar 16 19:55:49 Marvin kernel: svc: bad direction 268435456, dropping > > request > > So that's 2^28, in a field that should always be zero. It's the very ahh. indeed. I didn't do the math, yet :) > first check of any data read from the rpc call, so it'd be consistent > with the call data being garbage, for one reason or another. > > What would cause that to happen, I don't know. Do you have a reliable > way to reproduce it? just sit and wait :-) I'll let a tcpdump run this evening and see if I can correlate the message with anything. If you have a printk or other patch for me to try, just let me know. bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED] | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: [EMAIL PROTECTED], [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Odd log message associated with NFS
On Tue, Mar 27, 2007 at 11:40:48AM -0700, Phy Prabab wrote: > Hello, > > I am currently running 2.6.21-rc5 and I am seeing quite a bit of this > message in my log files: > kernel: rpcsvc: received unknown control message:-2144992132/-1 > > This machine is an dual dual core opteron with 3Ware 9650 (14 disk > RAID10), 4G RAM, 64bit kernel, nfsutils-1.0.12 running knfsd. This > machine is a file server. Just a 'me, too': Mar 16 16:57:06 Marvin kernel: svc: bad direction 268435456, dropping request Mar 16 17:58:19 Marvin kernel: svc: bad direction 268435456, dropping request Mar 16 19:55:49 Marvin kernel: svc: bad direction 268435456, dropping request ... Mar 17 04:30:03 Marvin kernel: svc: bad direction 268435456, dropping request Mar 17 06:28:52 Marvin kernel: pppd(795): unaligned trap at 02207f90: 00011fd8d33d 29 1 Mar 17 06:28:55 Marvin kernel: inet_sk_reselect_saddr(): shifting inet->saddr from 82.149.xxx.xxx to 89.166.xxx.xxx Mar 17 09:05:21 Marvin kernel: rpcsvc: received unknown control message:-1024/186028080 Mar 17 14:17:04 Marvin kernel: rpcsvc: received unknown control message:-1024/186028040 Mar 17 14:17:31 Marvin kernel: rpcsvc: received unknown control message:-1024/186028040 Mar 17 14:49:14 Marvin kernel: rpcsvc: received unknown control message:-1024/186028080 Mar 17 14:49:15 Marvin kernel: rpcsvc: received unknown control message:-1024/186028040 This is from my little 'server', alpha ev4 'noname', 2.6.21-rc3, compiled with gcc 4.1.2 client is mostly an alpha ev6 2.6.21-rc3, gcc 4.1.2. Apart from the messages NFS seems to run just fine currently. Bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED] | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: [EMAIL PROTECTED], [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Alpha port: LVM
On Mon, Apr 18, 2005 at 02:48:41PM +0200, Rao Davide wrote: > Is LVM working on the alpha port 2.6 kernel series ? works fine for me. > If so where do I get libdevmapper so that I can build the userspace LVM > utils ? > > I tryied downloading > ftp://sources.redhat.com/pub/dm/multipath-toolsmultipath-tools-0.4.3.tar.bz2 what do you think the 'dm' in that url stands for, hm? > But I fail to compile it so I'm also unable tu build the userspace lvm > utils. 'userspace lvm utils' can be found here: ftp://sources.redhat.com/pub/lvm2 multipath tools might be something different ... :) > -- > Regards > Davide Rao > Client/server Unix > Atos Origin > Via C.Viola - Pont St. Martin (AO) Italy > Cell : +39 3357599151 > Tel : +39 125810433 > Email: [EMAIL PROTECTED] 73 Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED] | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: [EMAIL PROTECTED], [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/sch0 interface
On Tue, May 15, 2001 at 03:08:01PM -0600, Jeff V. Merkey wrote: > > > Is anyone actuaslly using the /dev/sch0 interface for SCSI tape changers > in Linux? I noticed that the device definitions are present, but I do not > see any driver shipped in the standard base that actually uses it. http://www.in-berlin.de/User/kraxel/linux.html works very well here (needs a minor #include to compile correctly, though) I actually wonder why this isn't in the mainline kernel. > > Thanks > > Jeff > Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial driver question
On Thu, Mar 22, 2001 at 06:07:52PM -0500, John Covici wrote: > I have been wondering about the serial drivers shared irq > configuration parameter. Will it allow two dumb serial ports which > know nothing about sharing irq's to actually share the same irq, or no. > does the actual hardware have to support some kind of irq sharing for > this to work? yes. For one there are multiport serial cards that combine every ports' irq into one. PCI cards should also be able to share their irqs (with other PCI cards). But you can't share an ISA irq with a PCI one. And you can't share one ISA card's irq with another ISA one nor the irqs of a dumb ISA multiport card either ... ... without some modification, that is ;-) Imagine the situation on a typical ISA card: Card ISA Mainboard connector ---+ " | to other ISA connectors | Jumper " | IC |-+--*=*---"--+ | |" | ---+ +--* *-- " | to IRQ-Controller-IC |" +--* *-- Now replace the jumper for each irq sharing device with a diode and add one resistor to the irq line: ---+Diode " | to other ISA connectors | e.g. 1n4148" | IC |-+--*=*--|>|---+--"--+ | | A K | " | ---+ +--* *--- | " | to IRQ-Controller-IC | # " +--* *--- # Resistor 20kOhm # | __|__ GND So for 4 serial ports sharing a single irq line you wuld use 4 diodes and 1 resistor. > I did try two ports on the same irq, but one of them isn't seem at all > by Linux, so I am quite curious whether I am barking up the wrong > line? It should be seen. You won't be able to use them effectively (they'll be transmitting only about 16 bytes every 30 seconds or something) but they should definitively be detected both. Did you use setserial to convince the kernel of their presence? > > Thanks. > Bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Mon, Dec 25, 2000 at 06:09:35AM +0100, Mike Galbraith wrote:
> I wouldn't (not going to here;) spend a lot of time on it. The compiler
> has problems. It won't build glibc-2.2, and chokes horribly on ipchains.
>
> int ipt_register_table(struct ipt_table *table)
> {
> int ret;
> struct ipt_table_info *newinfo;
> static struct ipt_table_info bootstrap
> = { 0, 0, { 0 }, { 0 }, { } };
>^
> ip_tables.c:1361: Internal compiler error in array_size_for_constructor, at
>varasm.c:4456
Well, I 'fixed' this by changing above line to:
= { 0, 0, { 0 }, { 0 }, };
and repeating this change (deleting the braces) about 15 times in 2 or 3 other
files of iptables. (patch available on request)
Of course gcc shouldn't die but issue a useful message if/when syntax rules
may have changed.
Apart from that and a hand-edited arch/alpha/vmlinux.lds that got some
newlines wrong, the kernel compiled fine and is up for over a day now.
Though this is not intel but alpha (ev4 / AXPpci33).
Marvin:~$ uname -a
Linux Marvin 2.4.0-test13pre4-ac2 #13 Sun Dec 24 15:26:57 UTC 2000 alpha unknown
Marvin:~$ uptime
8:19pm up 1 day, 4:28, 4 users, load average: 0.00, 0.00, 0.00
Marvin:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/alpha-unknown-linux-gnu/2.97/specs
Configured with: ../gcc-20001211/configure --enable-threads --enable-shared
--prefix=/usr --enable-languages=c,c++
gcc version 2.97 20001211 (experimental)
I use iptables for masquerading my local ethernet and that works as expected
so far.
Thorsten.
--
| Thorsten KranzkowskiInternet: [EMAIL PROTECTED]|
| Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Question on SCSI Tape Changer Status
On Wed, Nov 15, 2000 at 10:32:19AM -0600, George R. Kasica wrote: > I've got an HP 4mm DAT Autochanger here (Scsi detection shown below > >from boot)...what I'm wondering is this: Is there a way to tell WHICH > ONE of the 6 tapes is in the actual tape drive from the OS? And if so, > a way to make it load a specific tape (1-6 or maybe 0-5 I'm not sure There's a kernel patch along with userspace ustils at http://www.in-berlin.de/User/kraxel/linux.html (scsi-changer) that exactly does what you want. I use it with 2.2.18pre_something at work but a 2.4 patch is also provided. It works great with our DLT-loader. I wonder why this still isn't in the mainline kernel though > Oct 26 22:20:27 eagle kernel: Vendor: HPModel: C1553A > Rev:NS01 > Oct 26 22:20:27 eagle kernel: Type: Medium Changer ^^ The patch makes this /dev/sch0 > ANSI SCSI revision: 02 > Oct 26 22:20:27 eagle kernel: Detected scsi generic sg2 at scsi0, > channel 0, id 3, lun 1 Bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: floppy on alpha
On Fri, Oct 13, 2000 at 04:40:45PM +, Thorsten Kranzkowski wrote: > Since I received a success report for 2.4.0pre8 for the very same board > but compiled with 2.96.2 I tend to think that it's indeed the compiler. ^^ 2.95.2 of course - friday 13th :-) -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: floppy on alpha
On Fri, Oct 13, 2000 at 10:13:11AM +0900, Tom Holroyd wrote: > On Thu, 12 Oct 2000, Thorsten Kranzkowski wrote: > > > > Huh - your floppy is working? > > gcc version 2.96 2925 (experimental) > > Mine works OK, except for that invalidate on last close thing (how do I go > back to the old behavior? Why was it changed?). I compiled with 2.95.2. Since I received a success report for 2.4.0pre8 for the very same board but compiled with 2.96.2 I tend to think that it's indeed the compiler. > You might try that. I have floppy.o configured as a module, also. Try > that, too. I almost never used modules. The floppy was working during 2.3 btw. > > Dr. Tom Holroyd Bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9 not using buffers
On Wed, Oct 11, 2000 at 09:04:07PM -0400, Alexander Viro wrote: > On Thu, 12 Oct 2000, Tom Holroyd wrote: > > > Alpha DP264 (UP), SCSI, floppy > > > > If I do a dd if=/dev/zero of=/tmp/moo count=10, I don't see any > > increase in buffers, as reported by vmstat. Furthermore, if I read from > > /dev/fd0, it used to buffer the whole thing, so a second read would be > > fast -- now it hits the floppy again. > > Huh - your floppy is working? Mine does not (with 2.4.0pre10-test1 that is): [Marvin:~#] dd if=/dev/fd0 |od -c |more 2880+0 records in 2880+0 records out 000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 550 [Marvin:~#] This floppy currently holds my MILO image so output is definitively wrong :-) I also saw pure random data (fragments from libc etc.) on different runs. AXPpci33 ev4 UP gcc version 2.96 2925 (experimental) > Bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9-pre9 floppy not working on Alpha
Hi! since at least 2.4.0-test5 (the oldest kernel I have around) floppy support is broken on alpha. If I e.g. do od -c /dev/fd0 | more I get all sorts of weird stuff (parts of libc, directory contents, other binary data) but not the floppy's real contents. Mounting of floppies also doesn't work. The floppy drive and controller hardware is presumably ok since I currently sucessfully boot MILO from it. System is AXPpci33 'noname', onboard floppy controller gcc version 2.96 2925 (experimental) Linux kernel 2.4.0-9-9 (problem exists since at least 2.4.0-5) Does anbody else have this problem? Where can I start hunting this down? Bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: milo
On Tue, Sep 26, 2000 at 09:56:55AM +0200, Listuser AVA System wrote: > Sorry to bother all ya important ones. > I'm about to disect 2.4, however the little bugger won't boot. > I suspect the milo. Which is built for 2.2.13. Use a recent MILO (milo-2.2-17.tar.bz2) or check the 'legacy kernel start address' option in your kernel build. using 2.4.0-test7 with milo on a AXPpci33 board just now. Bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [DOC] Debugging early kernel hangs
On Sat, Sep 23, 2000 at 09:57:38PM +1100, Keith Owens wrote: > On Sat, 23 Sep 2000 12:42:13 +0200, > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > >However, there's still a huge gap between the last progress() message and > >availability of the frame buffer device. The simple console has the > >advantage of outputing existing printk messages. (basically, it's a > >console using prom_printf). > > Something I forgot to mention about debugging using screen writes. If > the problem is caused by incorrect compiler output then even printk can > fail. Not because the C code is wrong but because the generated > assembler is wrong. Writing direct to screen memory is as simple as it > gets and gives the compiler little or no chance to get it wrong. How about the possibility to use architecture specific backends? E.g. my little Alpha machine has an 8-bit debugging LED port that would be very suited for this. Or you could use a parallel port in a similar manner (for those vga-less server machines...). Other machines may have a LED system display for displaying HEX-digits. So when you use an 8-bit value and display it as 2 hex-digits (ok that would be 2 assembler insns instead of one..) this kind of devices could be supported equally well. my 0.02 EUR Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
