* Re: 2.5.52 compile error
From: Richard B. Tilley (Brad) @ 2002-12-17 21:27 UTC (permalink / raw)
To: Bob Miller; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20021217211618.GB1069@doc.pdx.osdl.net>
[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]
CONFIG_INPUT is modular, do I *have* to build it in inorder to compile?
On Tue, 2002-12-17 at 16:16, Bob Miller wrote:
> On Tue, Dec 17, 2002 at 03:57:01PM -0500, rtilley wrote:
> > Using RH's default *i686.config to build a vanilla 2.5.52 kernel. It keeps
> > returning this error on 2 totally different x86 PCs:
> >
> >
> > drivers/built-in.o: In function `kd_nosound':
> > drivers/built-in.o(.text+0x1883f): undefined reference to `input_event'
> > drivers/built-in.o(.text+0x18861): undefined reference to `input_event'
> > drivers/built-in.o: In function `kd_mksound':
> > drivers/built-in.o(.text+0x1890a): undefined reference to `input_event'
> > drivers/built-in.o: In function `kbd_bh':
> > drivers/built-in.o(.text+0x197a2): undefined reference to `input_event'
> > drivers/built-in.o(.text+0x197c1): undefined reference to `input_event'
> > drivers/built-in.o(.text+0x197e0): more undefined references to `input_event'
> > follow
> > drivers/built-in.o: In function `kbd_connect':
> > drivers/built-in.o(.text+0x19d54): undefined reference to `input_open_device'
> > drivers/built-in.o: In function `kbd_disconnect':
> > drivers/built-in.o(.text+0x19d7f): undefined reference to `input_close_device'
> > drivers/built-in.o: In function `kbd_init':
> > drivers/built-in.o(.init.text+0x12c1): undefined reference to
> > `input_register_handler'
> > make: *** [.tmp_vmlinux1] Error 1
> >
> >
> > Where is the fix for this?
> >
> At your finger tips ;-). Turn on CONFIG_INPUT via "Input device support"
> off the main page.
>
> --
> Bob Miller Email: rem@osdl.org
> Open Source Development Lab Phone: 503.626.2455 Ext. 17
> -
> 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/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* RE: packet analysis....
From: Nigel Clarke @ 2002-12-17 21:17 UTC (permalink / raw)
To: Arindam Haldar, NETFILTER
In-Reply-To: <3DFF61AF.3080304@inbox.lv>
Without going into to much detail...
BDU from root bridge within spanning topology.
Pathcost 0
Age 0
Max 0
Hello 2
Fdely 15
--
Nigel Clarke Forever Networks
Network Security Engineer Consultant
*********www.forever-networks.com************
-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Arindam Haldar
Sent: Tuesday, December 17, 2002 9:41 AM
To: NETFILTER
Subject: packet analysis....
hi all,
what the folowwing tcpdump messages mean ??...
802.1d--does this packet related to wireless ??
23:11:47.946515 0:40:96:51:ef:74 1:80:c2:0:0:0 0026 60: 802.1d config
8000.00:40:96:51:ef:74.8001 root 8000.00:40:96:51:ef:74 pathcost 0 age 0
max 20 hello 2 fdelay 15
23:11:49.948042 0:40:96:51:ef:74 1:80:c2:0:0:0 0026 60: 802.1d config
8000.00:40:96:51:ef:74.8001 root 8000.00:40:96:51:ef:74 pathcost 0 age 0
max 20 hello 2 fdelay 15
thanking in advance...
A.H
^ permalink raw reply
* Re: mac address change on an eth alias
From: pa3gcu @ 2002-12-17 21:14 UTC (permalink / raw)
To: Petre Bandac, linux-newbie
In-Reply-To: <200212172207.22480.g38@rdsbv.ro>
On Tuesday 17 December 2002 20:07, Petre Bandac wrote:
> root@k:~# ifconfig eth0:1 123.123.123.123 netmask 255.255.255.0 hw ether
> 00:E0:7D:02:C6:0C
> SIOCSIFHWADDR: Device or resource busy
> root@k:~#
>
> am I trying to do something impossible or is it only my NIC (Realtek 8139)
> that can't do it ?
AFAIK yes, at least the way you are doing it, you can however change a MAC
adress before configuring the card.
ifconfig eth0 00:E0:7D:02:C6:0C
ifconfig eth0 123.123.123 netmask 255.255.255.0
So what i am saying is, you cant change the MAC address when a IP# is
assigned.
I tested it on my eth0 interface but without aliasing, but i doubt if that is
an issue here.
> I want to have 2 ip's on the same interface - but with 2 different macs ...
> why? because this is my testing server and, among others (dhcp, bind,
> sendmail/postfix, asterisk, etc) I want to actually see how a mac address
> can be changed ... if it's possible
Down the IFC's, change the MAC(s), then configure the card and its aliases.
>
> thank you for you patience,
>
> petre
--
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/
-
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: make module_install
From: Wolfgang Denk @ 2002-12-17 21:10 UTC (permalink / raw)
To: Ing.Gianfranco Morandi, LinuxPPC
In-Reply-To: <20021217190611.AA903C6139@atlas.denx.de>
In message <20021217190611.AA903C6139@atlas.denx.de> I wrote:
...
> Do not hesitate to relase your code early. This is one of the basic
> ideas of Open Source development, and a source of huge mutual
> benefit: first, a duplication of effort may result, as others can
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Nonsense. I meant: duplication of effort can be AVOIDED
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
On a clear disk you can seek forever.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: 2.5.52 compile error
From: Bob Miller @ 2002-12-17 21:16 UTC (permalink / raw)
To: rtilley; +Cc: linux-kernel
In-Reply-To: <3E058049@zathras>
On Tue, Dec 17, 2002 at 03:57:01PM -0500, rtilley wrote:
> Using RH's default *i686.config to build a vanilla 2.5.52 kernel. It keeps
> returning this error on 2 totally different x86 PCs:
>
>
> drivers/built-in.o: In function `kd_nosound':
> drivers/built-in.o(.text+0x1883f): undefined reference to `input_event'
> drivers/built-in.o(.text+0x18861): undefined reference to `input_event'
> drivers/built-in.o: In function `kd_mksound':
> drivers/built-in.o(.text+0x1890a): undefined reference to `input_event'
> drivers/built-in.o: In function `kbd_bh':
> drivers/built-in.o(.text+0x197a2): undefined reference to `input_event'
> drivers/built-in.o(.text+0x197c1): undefined reference to `input_event'
> drivers/built-in.o(.text+0x197e0): more undefined references to `input_event'
> follow
> drivers/built-in.o: In function `kbd_connect':
> drivers/built-in.o(.text+0x19d54): undefined reference to `input_open_device'
> drivers/built-in.o: In function `kbd_disconnect':
> drivers/built-in.o(.text+0x19d7f): undefined reference to `input_close_device'
> drivers/built-in.o: In function `kbd_init':
> drivers/built-in.o(.init.text+0x12c1): undefined reference to
> `input_register_handler'
> make: *** [.tmp_vmlinux1] Error 1
>
>
> Where is the fix for this?
>
At your finger tips ;-). Turn on CONFIG_INPUT via "Input device support"
off the main page.
--
Bob Miller Email: rem@osdl.org
Open Source Development Lab Phone: 503.626.2455 Ext. 17
^ permalink raw reply
* 2.5.52 compile error
From: rtilley @ 2002-12-17 20:57 UTC (permalink / raw)
To: linux-kernel
Using RH's default *i686.config to build a vanilla 2.5.52 kernel. It keeps
returning this error on 2 totally different x86 PCs:
drivers/built-in.o: In function `kd_nosound':
drivers/built-in.o(.text+0x1883f): undefined reference to `input_event'
drivers/built-in.o(.text+0x18861): undefined reference to `input_event'
drivers/built-in.o: In function `kd_mksound':
drivers/built-in.o(.text+0x1890a): undefined reference to `input_event'
drivers/built-in.o: In function `kbd_bh':
drivers/built-in.o(.text+0x197a2): undefined reference to `input_event'
drivers/built-in.o(.text+0x197c1): undefined reference to `input_event'
drivers/built-in.o(.text+0x197e0): more undefined references to `input_event'
follow
drivers/built-in.o: In function `kbd_connect':
drivers/built-in.o(.text+0x19d54): undefined reference to `input_open_device'
drivers/built-in.o: In function `kbd_disconnect':
drivers/built-in.o(.text+0x19d7f): undefined reference to `input_close_device'
drivers/built-in.o: In function `kbd_init':
drivers/built-in.o(.init.text+0x12c1): undefined reference to
`input_register_handler'
make: *** [.tmp_vmlinux1] Error 1
Where is the fix for this?
^ permalink raw reply
* [PATCH] S4bios for 2.5.52.
From: Ducrot Bruno @ 2002-12-17 20:39 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Pavel Machek, Grover, Andrew,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
This patch add s4bios support for 2.5.52.
S4bios is an alternative for the ACPI S4 system suspend state, but is a bit
more easy to implement. It suppose though that the BIOS support this feature.
For some BIOS, creating a so-called suspend partition with the help
of lphdisk is OK.
Plus, it permit for Pavel to have a nice graphic display at suspend/resume.
echo 4 > /proc/acpi/sleep is for swsusp;
echo 4b > /proc/acpi/sleep is for s4bios.
Cheers,
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
[-- Attachment #2: s4bios-2.5.52.diff --]
[-- Type: text/plain, Size: 7973 bytes --]
arch/i386/kernel/acpi_wakeup.S | 33 +++++++++++++++++++--
drivers/acpi/acpi_ksyms.c | 1
drivers/acpi/hardware/hwsleep.c | 61 ++++++++++++++++++++++++++++++++++++----
drivers/acpi/include/acpixf.h | 4 ++
drivers/acpi/sleep.c | 28 +++++++++++++++---
include/linux/suspend.h | 2 +
6 files changed, 117 insertions(+), 12 deletions(-)
arch/i386/kernel/acpi_wakeup.S
--- linux-2.5.52/arch/i386/kernel/acpi_wakeup.S 2002/12/17 19:15:12 1.1
+++ linux-2.5.52/arch/i386/kernel/acpi_wakeup.S 2002/12/17 19:20:34
@@ -272,7 +272,7 @@
ENTRY(do_suspend_lowlevel)
cmpl $0,4(%esp)
- jne .L1432
+ jne ret_point
call save_processor_state
movl %esp, saved_context_esp
@@ -285,7 +285,7 @@
movl %edi, saved_context_edi
pushfl ; popl saved_context_eflags
- movl $.L1432,saved_eip
+ movl $ret_point,saved_eip
movl %esp,saved_esp
movl %ebp,saved_ebp
movl %ebx,saved_ebx
@@ -297,7 +297,7 @@
addl $4,%esp
ret
.p2align 4,,7
-.L1432:
+ret_point:
movl $__KERNEL_DS,%eax
movw %ax, %ds
movl saved_context_esp, %esp
@@ -310,6 +310,33 @@
movl saved_context_edi, %edi
call restore_processor_state
pushl saved_context_eflags ; popfl
+ ret
+
+ENTRY(do_suspend_lowlevel_s4bios)
+ cmpl $0,4(%esp)
+ jne ret_point
+ call save_processor_state
+
+ movl %esp, saved_context_esp
+ movl %eax, saved_context_eax
+ movl %ebx, saved_context_ebx
+ movl %ecx, saved_context_ecx
+ movl %edx, saved_context_edx
+ movl %ebp, saved_context_ebp
+ movl %esi, saved_context_esi
+ movl %edi, saved_context_edi
+ pushfl ; popl saved_context_eflags
+
+ movl $ret_point,saved_eip
+ movl %esp,saved_esp
+ movl %ebp,saved_ebp
+ movl %ebx,saved_ebx
+ movl %edi,saved_edi
+ movl %esi,saved_esi
+
+ pushl $3
+ call acpi_enter_sleep_state_s4bios
+ addl $4,%esp
ret
ALIGN
drivers/acpi/include/acpixf.h
--- linux-2.5.52/drivers/acpi/include/acpixf.h 2002/12/17 19:15:16 1.1
+++ linux-2.5.52/drivers/acpi/include/acpixf.h 2002/12/17 19:17:11
@@ -380,6 +380,10 @@
u8 sleep_state);
acpi_status
+acpi_enter_sleep_state_s4bios (
+ void);
+
+acpi_status
acpi_leave_sleep_state (
u8 sleep_state);
drivers/acpi/hardware/hwsleep.c
--- linux-2.5.52/drivers/acpi/hardware/hwsleep.c 2002/12/17 19:15:17 1.1
+++ linux-2.5.52/drivers/acpi/hardware/hwsleep.c 2002/12/17 19:39:30
@@ -184,6 +184,7 @@
acpi_enter_sleep_state (
u8 sleep_state)
{
+ int i;
u32 PM1Acontrol;
u32 PM1Bcontrol;
ACPI_BIT_REGISTER_INFO *sleep_type_reg_info;
@@ -298,16 +299,18 @@
}
/* Wait until we enter sleep state */
+ /* But gracefully fail if we wait too long. */
+ i = 10;
do {
status = acpi_get_register (ACPI_BITREG_WAKE_STATUS, &in_value, ACPI_MTX_LOCK);
if (ACPI_FAILURE (status)) {
return_ACPI_STATUS (status);
}
-
+ acpi_os_stall (1000);
/* Spin until we wake */
- } while (!in_value);
+ } while (!in_value && --i);
status = acpi_set_register (ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_LOCK);
if (ACPI_FAILURE (status)) {
@@ -319,6 +322,54 @@
/******************************************************************************
*
+ * FUNCTION: Acpi_enter_sleep_state_s4bios
+ *
+ * PARAMETERS: None
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Perform a s4 bios request.
+ * THIS FUNCTION MUST BE CALLED WITH INTERRUPTS DISABLED
+ *
+ ******************************************************************************/
+
+acpi_status
+acpi_enter_sleep_state_s4bios (void)
+{
+ u32 in_value;
+ int i;
+ acpi_status status;
+
+
+ ACPI_FUNCTION_TRACE ("Acpi_enter_sleep_state_s4bios");
+
+
+ acpi_set_register (ACPI_BITREG_WAKE_STATUS, 1, ACPI_MTX_LOCK);
+ acpi_hw_clear_acpi_status();
+
+ acpi_hw_disable_non_wakeup_gpes();
+
+ ACPI_FLUSH_CPU_CACHE();
+
+ acpi_os_stall (10000);
+
+ status = acpi_os_write_port (acpi_gbl_FADT->smi_cmd, (acpi_integer) acpi_gbl_FADT->S4bios_req, 8);
+
+ i = 10;
+ do {
+ status = acpi_get_register (ACPI_BITREG_WAKE_STATUS, &in_value, ACPI_MTX_LOCK);
+ if (ACPI_FAILURE (status)) {
+ return_ACPI_STATUS (status);
+ }
+ acpi_os_stall (1000);
+ } while (!in_value && --i);
+
+ return_ACPI_STATUS (AE_OK);
+}
+
+
+/******************************************************************************
+ *
* FUNCTION: Acpi_leave_sleep_state
*
* PARAMETERS: Sleep_state - Which sleep state we just exited
@@ -341,6 +392,9 @@
ACPI_FUNCTION_TRACE ("Acpi_leave_sleep_state");
+ /* Be sure to have BM arbitration */
+ status = acpi_set_register (ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_LOCK);
+
/* Ensure Enter_sleep_state_prep -> Enter_sleep_state ordering */
acpi_gbl_sleep_type_a = ACPI_SLEEP_TYPE_INVALID;
@@ -371,9 +425,6 @@
if (ACPI_FAILURE (status)) {
return_ACPI_STATUS (status);
}
-
- /* Disable BM arbitration */
- status = acpi_set_register (ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_LOCK);
return_ACPI_STATUS (status);
}
drivers/acpi/sleep.c
--- linux-2.5.52/drivers/acpi/sleep.c 2002/12/17 19:15:18 1.1
+++ linux-2.5.52/drivers/acpi/sleep.c 2002/12/17 19:47:28
@@ -149,8 +149,15 @@
if (state > ACPI_STATE_S1) {
error = acpi_save_state_mem();
+ /*
+ * Do not kill this #if 0 please.
+ * If one day we get S4, we should be happy to remember
+ * where to save to disk.
+ */
+#if 0
if (!error && (state == ACPI_STATE_S4))
error = acpi_save_state_disk();
+#endif
if (error) {
device_resume(RESUME_RESTORE_STATE);
@@ -227,6 +234,8 @@
case ACPI_STATE_S3:
do_suspend_lowlevel(0);
#endif
+ case ACPI_STATE_S4:
+ do_suspend_lowlevel_s4bios(0);
break;
}
local_irq_restore(flags);
@@ -250,10 +259,14 @@
if (state < ACPI_STATE_S1 || state > ACPI_STATE_S5)
return AE_ERROR;
+ /* Since we handle S4 via a different path (swsusp), give up if no s4bios. */
+ if (state == ACPI_STATE_S4 && !acpi_gbl_FACS->S4bios_f)
+ return AE_ERROR;
+
freeze_processes(); /* device_suspend needs processes to be stopped */
/* do we have a wakeup address for S2 and S3? */
- if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3) {
+ if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3 || state == ACPI_STATE_S4) {
if (!acpi_wakeup_address)
return AE_ERROR;
acpi_set_firmware_waking_vector((ACPI_PHYSICAL_ADDRESS) acpi_wakeup_address);
@@ -296,8 +309,11 @@
ACPI_FUNCTION_TRACE("acpi_system_sleep_seq_show");
for (i = 0; i <= ACPI_STATE_S5; i++) {
- if (sleep_states[i])
+ if (sleep_states[i]) {
seq_printf(seq,"S%d ", i);
+ if (i == ACPI_STATE_S4 && acpi_gbl_FACS->S4bios_f)
+ seq_printf(seq, "S4b ");
+ }
}
seq_puts(seq, "\n");
@@ -336,12 +352,12 @@
if (!sleep_states[state])
return_VALUE(-ENODEV);
+ if (state == 4 && state_string[1] != 'b') {
#ifdef CONFIG_SOFTWARE_SUSPEND
- if (state == 4) {
software_suspend();
return_VALUE(count);
- }
#endif
+ }
status = acpi_suspend(state);
if (ACPI_FAILURE(status))
@@ -660,6 +676,10 @@
if (ACPI_SUCCESS(status)) {
sleep_states[i] = 1;
printk(" S%d", i);
+ }
+ if (i == ACPI_STATE_S4 && acpi_gbl_FACS->S4bios_f) {
+ sleep_states[i] = 1;
+ printk(" S4b");
}
}
printk(")\n");
drivers/acpi/acpi_ksyms.c
--- linux-2.5.52/drivers/acpi/acpi_ksyms.c 2002/12/17 19:15:19 1.1
+++ linux-2.5.52/drivers/acpi/acpi_ksyms.c 2002/12/17 19:17:11
@@ -86,6 +86,7 @@
EXPORT_SYMBOL(acpi_get_register);
EXPORT_SYMBOL(acpi_set_register);
EXPORT_SYMBOL(acpi_enter_sleep_state);
+EXPORT_SYMBOL(acpi_enter_sleep_state_s4bios);
EXPORT_SYMBOL(acpi_get_system_info);
EXPORT_SYMBOL(acpi_get_devices);
include/linux/suspend.h
--- linux-2.5.52/include/linux/suspend.h 2002/12/17 19:15:19 1.1
+++ linux-2.5.52/include/linux/suspend.h 2002/12/17 19:17:11
@@ -71,6 +71,8 @@
extern void do_suspend_lowlevel(int resume);
+extern void do_suspend_lowlevel_s4bios(int resume);
+
#else
static inline void software_suspend(void)
{
^ permalink raw reply
* Re:slow NFS performance extracting bits from large files
From: Bruce Allen @ 2002-12-17 20:38 UTC (permalink / raw)
To: Heflin, Roger A.; +Cc: nfs
In-Reply-To: <5CA6F03EF05E0046AC5594562398B9160C77AF@POEXMB3.conoco.net>
Hi Roger,
> > the files are "more or less" contiguous on the disk, a typical iteration
> > of the loop above starting from the first read, should involve:
> >
> > read 32 bytes
> > seek to middle (2 tracks) 2 msec
> > read 620 bytes
> > seek to next file (2 tracks) 2 msec
> >
> > hence 4 msec/file x 10k files = 40 sec read time if the kernel disk cache
> > buffers are all dirty. Does the estimate above look reasonable?
> >
> > I'll do the experiment that you suggest, using wc to clear the cache
> > first, and see how this compares to what's above.
> >
> Track to track does not really count. The average time per io is
> 1/2 of the rotational latency. If it is a 7200 rpm disk, it means
> that even once you get to the proper track it takes 1/2 * 60/7200 seconds
> for the proper data to come under the head on average. The number
> for the above is 4.2ms and then you need to add in the track-to-track
> number to get 5.2ms or so per operation.
I realized this myself a few hours after I sent my email. I completely
agree with the analysis. It also explains why my measured times where
about four times longer than I had predicted.
So I completely agree with this.
> And probably you have a operation
> also to open each file. And given that the filename entry data (name, and such) may
> not be close, it may not be a short quick seek, it may take longer. Exactly
> how many seeks you have depends on exactly how the filesystem
> lays
> the data out on disk.
It happens that all the files are in the same directory, and were created
at the same time during an otherwise quiescent period of operation. So in
fact I think that the directory is probably read at the very start, and
then sits in cache after that. If so, I think that the other operations
associated with the file access are probably all to/from cache.
> So you have open, read32b, read620b, each taking 5.2ms or so, so a total
> of 15.6ms per file, times 10k files = 156 seconds, and that is in a perfect
> world. You may also have a operation to update the file access time since
It's within 10% of what I measure. I think that the explanation is that
the directory info is all in cache. [I must say I find it quite satisfying
to be able to predict the code's performance this closely.]
> you have read the file, and each of the seeks could require a read to figure
> out exactly where that block actually is on disk. So there could be as
> many as 4 reads and a write going on on the far end. And then on top
> of that you have the network latency of around a 1 ms or so to send
> the packets back and forth for each operation. And my experience in
> the past has been that opens by themselves are pretty expensive, so
> there may be alot of operations going on in the background to make an
> open happen.
And indeed the additional time taken by the NFS-based accesses is also
very close to 30000*ping_time.
> > ttl=255 time=0.264 ms
> > ....
> > --- storage1.medusa.phys.uwm.edu ping statistics ---
> > 26 packets transmitted, 26 received, 0% loss, time 25250ms
> > rtt min/avg/max/mdev = 0.156/0.230/0.499/0.063 ms
> >
> > so 230 usec (average) x 30,000 = 7 seconds
> >
> > OK, so if all is well, then if I run the code locally on the NFS server
> > itself (with disk cache buffers all dirty) it should take around 7
> > seconds less time than if I run it on an NFS client.
> >
> > I'll check the numbers and report back.
> >
> >
> On the ping, you really need to ping for at least an hour or more, my
> experience is that if you are ping 1/second for an hour and you are
> losing 1 of 3600 pings (losing 1 ping per hour) it is very obvious to
> anything or anyone running that things are being affected, and this
> needs to be fixed. A clean network will lose the pings at a rate
> of less than 1 of 3600. And if you are losing 1 of 3600
> packets this will have ugly results on UDP nfs and even on
> other applications.
In our case, the network is completely under control. I'm running on our
research group's beowulf cluster, so it's a private network -- the only
packets on it come from our own applications. So again, I am highly
confident that at least while I am running the code, the round-trip ping
times I showed are reprsentative.
Thanks again for your comments. I completely agree about the
time-per-read above being at least 1msec plus half a rotation period.
Cheers,
Bruce Allen
-------------------------------------------------------
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/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Brute force printk routines for looking at netfilter structures
From: Patrick Schaaf @ 2002-12-17 20:37 UTC (permalink / raw)
To: Ranjeet Shetye; +Cc: netfilter-devel
In-Reply-To: <000001c2a609$30f256e0$0100a8c0@zultys.com>
Hello "Kernel Professor" :-)
some quick and dirty comments, after cursory reading of nf_debug.c:
> signed int nf_debug_indent = 0;
Why signed? Anyway, this will fall on its face on SMP systems.
Cure: use atomic_t.
I bet you can speed up your NF_DPF macro a lot. Try this:
#define NF_DPF(format, args...) \
{ \
printk( \
"%s() at %s:%d " \
"%.*s" \
format , \
__FUNCTION__, __FILE__, __LINE__, \
nf_debug_indent, "\t", \
##args ); \
}
(Lightly tested; note that with that macro 'format' has to be
a string constant)
best regards
Patrick
^ permalink raw reply
* Re: HT Benchmarks (was: /proc/cpuinfo and hyperthreading)
From: H. Peter Anvin @ 2002-12-17 20:44 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200212170614.gBH6ELs15888@Port.imtp.ilyichevsk.odessa.ua>
Followup to: <200212170614.gBH6ELs15888@Port.imtp.ilyichevsk.odessa.ua>
By author: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
In newsgroup: linux.dev.kernel
>
> As to HT, it's definitely a good thing. Multiple CPUs on a chip is
> a logical step. HT in P4 is rather weak, but future processors will
> likely have more advanced cores.
>
SMT and SMP-on-chip are two very different things.
> I never heard about HT from AMD camp. I'm curious what they do. ;)
Not have insanely long pipelines, so that a single thread can actually
use the processor functional units?
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* Re: 2.5.49: Severe PIIX4/ATA filesystem corruption
From: H. Peter Anvin @ 2002-12-17 20:41 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1038359021.3267.110.camel@irongate.swansea.linux.org.uk>
Followup to: <1038359021.3267.110.camel@irongate.swansea.linux.org.uk>
By author: Alan Cox <alan@lxorguk.ukuu.org.uk>
In newsgroup: linux.dev.kernel
>
> I would be interested to know what happens if you boot a base 2.5.49
> without raid6 adulteration and stress it on your hw there, just to be
> sure.
>
Well, I finally got the system up and running again, after moving, and
ran it without loading any of the md modules (thus nothing modified by
the raid6 code.) Leaving it running overnight at the shell prompt but
cron jobs running -- including the one that backs up the SCSI drives
onto the IDE drive -- left me with tons of ext3fs error messages in
the morning on the IDE drive in question.
This is unfortunately all the information I have right at the moment.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* [PATCH] S4bios for 2.5.52.
From: Ducrot Bruno @ 2002-12-17 20:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Pavel Machek, Grover, Andrew, acpi-devel
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
This patch add s4bios support for 2.5.52.
S4bios is an alternative for the ACPI S4 system suspend state, but is a bit
more easy to implement. It suppose though that the BIOS support this feature.
For some BIOS, creating a so-called suspend partition with the help
of lphdisk is OK.
Plus, it permit for Pavel to have a nice graphic display at suspend/resume.
echo 4 > /proc/acpi/sleep is for swsusp;
echo 4b > /proc/acpi/sleep is for s4bios.
Cheers,
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
[-- Attachment #2: s4bios-2.5.52.diff --]
[-- Type: text/plain, Size: 7973 bytes --]
arch/i386/kernel/acpi_wakeup.S | 33 +++++++++++++++++++--
drivers/acpi/acpi_ksyms.c | 1
drivers/acpi/hardware/hwsleep.c | 61 ++++++++++++++++++++++++++++++++++++----
drivers/acpi/include/acpixf.h | 4 ++
drivers/acpi/sleep.c | 28 +++++++++++++++---
include/linux/suspend.h | 2 +
6 files changed, 117 insertions(+), 12 deletions(-)
arch/i386/kernel/acpi_wakeup.S
--- linux-2.5.52/arch/i386/kernel/acpi_wakeup.S 2002/12/17 19:15:12 1.1
+++ linux-2.5.52/arch/i386/kernel/acpi_wakeup.S 2002/12/17 19:20:34
@@ -272,7 +272,7 @@
ENTRY(do_suspend_lowlevel)
cmpl $0,4(%esp)
- jne .L1432
+ jne ret_point
call save_processor_state
movl %esp, saved_context_esp
@@ -285,7 +285,7 @@
movl %edi, saved_context_edi
pushfl ; popl saved_context_eflags
- movl $.L1432,saved_eip
+ movl $ret_point,saved_eip
movl %esp,saved_esp
movl %ebp,saved_ebp
movl %ebx,saved_ebx
@@ -297,7 +297,7 @@
addl $4,%esp
ret
.p2align 4,,7
-.L1432:
+ret_point:
movl $__KERNEL_DS,%eax
movw %ax, %ds
movl saved_context_esp, %esp
@@ -310,6 +310,33 @@
movl saved_context_edi, %edi
call restore_processor_state
pushl saved_context_eflags ; popfl
+ ret
+
+ENTRY(do_suspend_lowlevel_s4bios)
+ cmpl $0,4(%esp)
+ jne ret_point
+ call save_processor_state
+
+ movl %esp, saved_context_esp
+ movl %eax, saved_context_eax
+ movl %ebx, saved_context_ebx
+ movl %ecx, saved_context_ecx
+ movl %edx, saved_context_edx
+ movl %ebp, saved_context_ebp
+ movl %esi, saved_context_esi
+ movl %edi, saved_context_edi
+ pushfl ; popl saved_context_eflags
+
+ movl $ret_point,saved_eip
+ movl %esp,saved_esp
+ movl %ebp,saved_ebp
+ movl %ebx,saved_ebx
+ movl %edi,saved_edi
+ movl %esi,saved_esi
+
+ pushl $3
+ call acpi_enter_sleep_state_s4bios
+ addl $4,%esp
ret
ALIGN
drivers/acpi/include/acpixf.h
--- linux-2.5.52/drivers/acpi/include/acpixf.h 2002/12/17 19:15:16 1.1
+++ linux-2.5.52/drivers/acpi/include/acpixf.h 2002/12/17 19:17:11
@@ -380,6 +380,10 @@
u8 sleep_state);
acpi_status
+acpi_enter_sleep_state_s4bios (
+ void);
+
+acpi_status
acpi_leave_sleep_state (
u8 sleep_state);
drivers/acpi/hardware/hwsleep.c
--- linux-2.5.52/drivers/acpi/hardware/hwsleep.c 2002/12/17 19:15:17 1.1
+++ linux-2.5.52/drivers/acpi/hardware/hwsleep.c 2002/12/17 19:39:30
@@ -184,6 +184,7 @@
acpi_enter_sleep_state (
u8 sleep_state)
{
+ int i;
u32 PM1Acontrol;
u32 PM1Bcontrol;
ACPI_BIT_REGISTER_INFO *sleep_type_reg_info;
@@ -298,16 +299,18 @@
}
/* Wait until we enter sleep state */
+ /* But gracefully fail if we wait too long. */
+ i = 10;
do {
status = acpi_get_register (ACPI_BITREG_WAKE_STATUS, &in_value, ACPI_MTX_LOCK);
if (ACPI_FAILURE (status)) {
return_ACPI_STATUS (status);
}
-
+ acpi_os_stall (1000);
/* Spin until we wake */
- } while (!in_value);
+ } while (!in_value && --i);
status = acpi_set_register (ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_LOCK);
if (ACPI_FAILURE (status)) {
@@ -319,6 +322,54 @@
/******************************************************************************
*
+ * FUNCTION: Acpi_enter_sleep_state_s4bios
+ *
+ * PARAMETERS: None
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Perform a s4 bios request.
+ * THIS FUNCTION MUST BE CALLED WITH INTERRUPTS DISABLED
+ *
+ ******************************************************************************/
+
+acpi_status
+acpi_enter_sleep_state_s4bios (void)
+{
+ u32 in_value;
+ int i;
+ acpi_status status;
+
+
+ ACPI_FUNCTION_TRACE ("Acpi_enter_sleep_state_s4bios");
+
+
+ acpi_set_register (ACPI_BITREG_WAKE_STATUS, 1, ACPI_MTX_LOCK);
+ acpi_hw_clear_acpi_status();
+
+ acpi_hw_disable_non_wakeup_gpes();
+
+ ACPI_FLUSH_CPU_CACHE();
+
+ acpi_os_stall (10000);
+
+ status = acpi_os_write_port (acpi_gbl_FADT->smi_cmd, (acpi_integer) acpi_gbl_FADT->S4bios_req, 8);
+
+ i = 10;
+ do {
+ status = acpi_get_register (ACPI_BITREG_WAKE_STATUS, &in_value, ACPI_MTX_LOCK);
+ if (ACPI_FAILURE (status)) {
+ return_ACPI_STATUS (status);
+ }
+ acpi_os_stall (1000);
+ } while (!in_value && --i);
+
+ return_ACPI_STATUS (AE_OK);
+}
+
+
+/******************************************************************************
+ *
* FUNCTION: Acpi_leave_sleep_state
*
* PARAMETERS: Sleep_state - Which sleep state we just exited
@@ -341,6 +392,9 @@
ACPI_FUNCTION_TRACE ("Acpi_leave_sleep_state");
+ /* Be sure to have BM arbitration */
+ status = acpi_set_register (ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_LOCK);
+
/* Ensure Enter_sleep_state_prep -> Enter_sleep_state ordering */
acpi_gbl_sleep_type_a = ACPI_SLEEP_TYPE_INVALID;
@@ -371,9 +425,6 @@
if (ACPI_FAILURE (status)) {
return_ACPI_STATUS (status);
}
-
- /* Disable BM arbitration */
- status = acpi_set_register (ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_LOCK);
return_ACPI_STATUS (status);
}
drivers/acpi/sleep.c
--- linux-2.5.52/drivers/acpi/sleep.c 2002/12/17 19:15:18 1.1
+++ linux-2.5.52/drivers/acpi/sleep.c 2002/12/17 19:47:28
@@ -149,8 +149,15 @@
if (state > ACPI_STATE_S1) {
error = acpi_save_state_mem();
+ /*
+ * Do not kill this #if 0 please.
+ * If one day we get S4, we should be happy to remember
+ * where to save to disk.
+ */
+#if 0
if (!error && (state == ACPI_STATE_S4))
error = acpi_save_state_disk();
+#endif
if (error) {
device_resume(RESUME_RESTORE_STATE);
@@ -227,6 +234,8 @@
case ACPI_STATE_S3:
do_suspend_lowlevel(0);
#endif
+ case ACPI_STATE_S4:
+ do_suspend_lowlevel_s4bios(0);
break;
}
local_irq_restore(flags);
@@ -250,10 +259,14 @@
if (state < ACPI_STATE_S1 || state > ACPI_STATE_S5)
return AE_ERROR;
+ /* Since we handle S4 via a different path (swsusp), give up if no s4bios. */
+ if (state == ACPI_STATE_S4 && !acpi_gbl_FACS->S4bios_f)
+ return AE_ERROR;
+
freeze_processes(); /* device_suspend needs processes to be stopped */
/* do we have a wakeup address for S2 and S3? */
- if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3) {
+ if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3 || state == ACPI_STATE_S4) {
if (!acpi_wakeup_address)
return AE_ERROR;
acpi_set_firmware_waking_vector((ACPI_PHYSICAL_ADDRESS) acpi_wakeup_address);
@@ -296,8 +309,11 @@
ACPI_FUNCTION_TRACE("acpi_system_sleep_seq_show");
for (i = 0; i <= ACPI_STATE_S5; i++) {
- if (sleep_states[i])
+ if (sleep_states[i]) {
seq_printf(seq,"S%d ", i);
+ if (i == ACPI_STATE_S4 && acpi_gbl_FACS->S4bios_f)
+ seq_printf(seq, "S4b ");
+ }
}
seq_puts(seq, "\n");
@@ -336,12 +352,12 @@
if (!sleep_states[state])
return_VALUE(-ENODEV);
+ if (state == 4 && state_string[1] != 'b') {
#ifdef CONFIG_SOFTWARE_SUSPEND
- if (state == 4) {
software_suspend();
return_VALUE(count);
- }
#endif
+ }
status = acpi_suspend(state);
if (ACPI_FAILURE(status))
@@ -660,6 +676,10 @@
if (ACPI_SUCCESS(status)) {
sleep_states[i] = 1;
printk(" S%d", i);
+ }
+ if (i == ACPI_STATE_S4 && acpi_gbl_FACS->S4bios_f) {
+ sleep_states[i] = 1;
+ printk(" S4b");
}
}
printk(")\n");
drivers/acpi/acpi_ksyms.c
--- linux-2.5.52/drivers/acpi/acpi_ksyms.c 2002/12/17 19:15:19 1.1
+++ linux-2.5.52/drivers/acpi/acpi_ksyms.c 2002/12/17 19:17:11
@@ -86,6 +86,7 @@
EXPORT_SYMBOL(acpi_get_register);
EXPORT_SYMBOL(acpi_set_register);
EXPORT_SYMBOL(acpi_enter_sleep_state);
+EXPORT_SYMBOL(acpi_enter_sleep_state_s4bios);
EXPORT_SYMBOL(acpi_get_system_info);
EXPORT_SYMBOL(acpi_get_devices);
include/linux/suspend.h
--- linux-2.5.52/include/linux/suspend.h 2002/12/17 19:15:19 1.1
+++ linux-2.5.52/include/linux/suspend.h 2002/12/17 19:17:11
@@ -71,6 +71,8 @@
extern void do_suspend_lowlevel(int resume);
+extern void do_suspend_lowlevel_s4bios(int resume);
+
#else
static inline void software_suspend(void)
{
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Daniel Jacobowitz @ 2002-12-17 20:35 UTC (permalink / raw)
To: Linux Kernel Mailing List
In-Reply-To: <3DFF83C5.6000007@redhat.com>
On Tue, Dec 17, 2002 at 12:06:29PM -0800, Ulrich Drepper wrote:
> Linus Torvalds wrote:
>
> > The thing is, gettimeofday() isn't _that_ special. It's just not worth a
> > vsyscall of it's own, I feel. Where do you stop? Do we do getpid() too?
>
> This is why I'd say mkae no distinction at all. Have the first
> nr_syscalls * 8 bytes starting at 0xfffff000 as a jump table. We can
> transfer to a different slot for each syscall. Each slot then could be
> a PC-relative jump to the common sysenter code or to some special code
> sequence which is also in the global page.
>
> If we don't do this now and it seems desirable in future we wither have
> to introduce a second ABI for the vsyscall stuff (ugly!) or you'll have
> to do the demultiplexing yourself in the code starting at 0xfffff000.
But what does this do to things like PTRACE_SYSCALL? And do we care...
I suppose not if we keep the syscall trace checks on every kernel entry
path.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* Re: slave_destroy called in scsi_scan.c:scsi_probe_and_add_lun()
From: Justin T. Gibbs @ 2002-12-17 20:25 UTC (permalink / raw)
To: Doug Ledford; +Cc: linux-scsi
In-Reply-To: <20021217054102.GH13989@redhat.com>
>> So, you cannot rely on slave_destroy as an indication of a device really
>> going away in the physical sense.
>
> No, you can. In the code snippet above you might be destroying something
> at scsi0:0:0:0 and adding something at scsi0:0:1:0. Regardless, the
> thing being destroyed is in fact going away permanently.
The SDEV, yes. The physical device, not necessarily. The concern is that
the API should only be called when the system is saying "physical device
gone", not due to some quirk in how the mid-layer manages its data objects.
In otherwords, the mid-layer could just as easily free the sdev every
time a probe fails, retain the already allocated sdev for the "found
device", and allocate a new sdev for each new probe. This would avoid
callbacks for physical devices that Linux has successfully probed.
> Whenever we do
> find a device, we actually allocate a new device struct identical to our
> current device struct and call slave_alloc() for the newly created
> device. So, whenever we find a new device, there will be a momentary
> point in time at which two device structs will exist that point to the
> same device. After the new device is allocated and set up, the original
> sdevscan device is simply renumbered in place (by updating the target or
> lun value) and then we call slave_destroy()/slave_alloc() so that the
> low level driver can also update their target/lun values to match.
Actually, this danger only exists if the low lever driver attaches
something to the SDEV and/or has a pointer to the SDEV. The device
at a particular target/lun is still the same device. The little dance
performed in the mid-layer can't change that.
>> In SPI, for example, the driver can only
>> tell that the device is gone if a command is issued to it. I had hoped
>> that I could detect hot-pull/scsi-remove-single-device operations via
>> this callback.
>
> You can. On any device we find, at device tear down time your
> slave_destroy() entry point will get called right before the device
> struct itself is kfree()ed.
The problem is that the SDEV lifetime is not representative to the
device's lifetime.
>> Granted, for some drivers, recreating and destroying state associated
>> with a particular device might be pretty cheap, but certainly not in all
>> cases. The
>> aic7xxx and aic79xx drivers maintain domain validation and other
>> negotiation state in these structures. You certainly don't want to go
>> through another full
>> Domain Validation sequence the next time a device is allocated via
>> slave_alloc() if the device isn't really "new".
>
> In this case I would suggest that the better course of action is to delay
> any domain validation stuff until the slave_configure() call.
Waiting for Linux to get around to probing devices will cause, at minimum,
a 2X (7902 is a dual channel device) increase in the time it takes to
perform domain validation. Because Linux does not probe busses in
parallel, both of these drivers actually perform their DV to all busses in
parallel
before the return from the detect routine (and on any later hot-plugged
device). This means that the underlying, per-device, data structures are
already configured prior to the first call to slave_alloc() or
slave_configure(). Now I can work around this little wart by ignoring
slave_destroy() calls that occur before slave_configure() is called, but
I would rather the API have semantics that mirror the physical world
rather than be dictated by poor programming practice.
> The
> original intent of slave_alloc() was for it to be as lightweight as
> possible simply because I knew that it would get called for every single
> target/lun value scanned. Once we do find a device though, and once we
> have retrieved INQUIRY data so we know what the device is capable of,
> then we get the slave_configure() call which is a much more appropriate
> place for heavier initializations once you know a device has been found
> and not that we are just scanning.
Actually, the slave_configure() is postponed until way after the inquiry
data is retrieved. If slave_congigure() were called as soon as the
device were properly detected, the slave_destroy() in scsi_scan.c would
be destroying a device that had been slave_configured.
--
Justin
^ permalink raw reply
* [PATCH] acpi_wakeup fixes
From: Ducrot Bruno @ 2002-12-17 20:21 UTC (permalink / raw)
To: Pavel Machek
Cc: Grover, Andrew, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 155 bytes --]
Hi Pavel.
This diff should be OK (I hope)
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
[-- Attachment #2: 00_acpi_wakeup.S.fix --]
[-- Type: text/plain, Size: 679 bytes --]
--- linux-2.5.52/arch/i386/kernel/acpi_wakeup.S 2002/12/17 19:15:12 1.1
+++ linux-2.5.52/arch/i386/kernel/acpi_wakeup.S 2002/12/17 20:03:40
@@ -41,7 +41,7 @@
cmpl $0x12345678, %eax
jne bogus_real_magic
-#if 1
+#if 0
lcall $0xc000,$3
#endif
#if 0
@@ -69,8 +69,12 @@
movl real_save_cr0 - wakeup_code, %eax
movl %eax, %cr0
+
+ # flush the prefetch queue.
jmp 1f
+1: jmp 1f
1:
+
movw $0x0e00 + 'n', %fs:(0x14)
movl real_magic - wakeup_code, %eax
@@ -160,11 +164,12 @@
ALIGN
-.org 0x2000
+.org 0x800
wakeup_stack:
-.org 0x3000
+.org 0x900
ENTRY(wakeup_end)
-.org 0x4000
+# .org 0x1000
+ .align 4096
wakeup_pmode_return:
movl $__KERNEL_DS, %eax
^ permalink raw reply
* RE: Problem Compiling Linux Kernel 2.4.20
From: Joseph D. Wagner @ 2002-12-17 20:27 UTC (permalink / raw)
To: redhat-devel-list; +Cc: linux-kernel
In-Reply-To: <1040146480.5653.0.camel@stantz.corp.sgi.com>
It (make xconfig) works fine on the 2.4.18-3 kernel that comes pre-installed
with Redhat 7.3. It just doesn't work with the kernel I downloaded from
http://www.kernel.org (version 2.4.20).
-----Original Message-----
From: redhat-devel-list-admin@redhat.com
[mailto:redhat-devel-list-admin@redhat.com] On Behalf Of Florin Andrei
Sent: Tuesday, December 17, 2002 11:35 AM
To: redhat-devel-list@redhat.com
Subject: RE: Problem Compiling Linux Kernel 2.4.20
On Mon, 2002-12-16 at 14:45, Joseph D. Wagner wrote:
>
> [root@localhost linux-2.4.20]# make xconfig
> cat header.tk >> ./kconfig.tk
> ./tkparse < ../arch/i386/config.in >> kconfig.tk
> -: 6: unknown command
> make[1]: *** [kconfig.tk] Error 1
Did you installed the Tcl and Tk stuff?
--
Florin Andrei
When it comes to discussing Linux, some people become temporarily
insane.
_______________________________________________
Redhat-devel-list mailing list
Redhat-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
^ permalink raw reply
* Re: rmap and nvidia?
From: O.Sezer @ 2002-12-17 20:14 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew McGregor
In-Reply-To: <49770000.1040153722@localhost.localdomain>
So, we should thank to wli for the information.
Andrew McGregor wrote:
> So, first apply the patch for 4191 from www.minion.de, then the attached
> one based on yours. Been running overnight and beaten on by
> XScreesaver, no memory leak anymore.
>
> Andrew
>
> --On Tuesday, December 17, 2002 00:22:34 +0200 "O.Sezer"
> <sezero@superonline.com> wrote:
>
>> Is this patch correct in any way?
>> (Ripped out of the 2.5 patch and modified some).
>>
>> Thanks.
>>
>
^ permalink raw reply
* Brute force printk routines for looking at netfilter structures
From: Ranjeet Shetye @ 2002-12-17 20:16 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]
I was trying to understand how the various data values were being
transferred within the connection tracking and the nat modules.
Unfortunately, I dont have the brains of Einstein so I went for the
brute force method.
I slit open Netfilter's guts and printk'd the whole damn thing out. Its
gross, its not kernel-style or systems-style coding, but hey it let me
figure out what was happening inside the netfilter mechanism. I wrote my
own stuff instead of using the builtin print mechanisms cos I want to
see and understand EVERY variable, every pointer, every data value,
EVERYTHING!
Within one day, I have gained more confidence. Now you can too!!!! The
Amazing nf_debug.c method by the Kernel Professor. :D (legal disclaimer:
Results not typical of regular users.)
The kernel works really slowly with all the printks, like its stuck in
molasses. Since I am working with multiple kernel trees, I've put the
original copy in my home directory, and linked to it in the netfilter
dirs of every kernel I am interested in. Modify Makefile to add
nf_debug.o to the list of nat objects, run make dep, make bzimage, and
you should be set to observe a very slow kernel.
The way to use this file is to use it VERY sparingly, and you should
trigger the debug code using a SINGLE packet. YOU HAVE BEEN WARNED!
I am still adding some routines and will post a complete copy once I am
done.
Thanks,
Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
771 Vaqueros Avenue
Sunnyvale CA 94085
USA
Ranjeet.Shetye@Zultys.com
http://www.zultys.com/
[-- Attachment #2: nf_debug.c --]
[-- Type: application/octet-stream, Size: 11599 bytes --]
/* Written by Ranjeet dot Shetye at Zultys dot com */
#include <linux/types.h>
#include <linux/init.h>
#include <linux/netfilter.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/if.h>
#include <linux/netfilter_ipv4/ip_nat.h>
#include <linux/netfilter_ipv4/ip_nat_rule.h>
#include <linux/netfilter_ipv4/ip_nat_protocol.h>
#include "nf_debug.h"
signed int nf_debug_indent = 0;
#define NF_DPF(format, args...) \
{\
/* printk ("%s () at %s:%d ", __FUNCTION__, __FILE__, __LINE__); */\
{\
int i = 0;\
for ( i = 0; i < nf_debug_indent; i++)\
{\
printk ("\t");\
}\
}\
printk (format,##args);\
}
void my_print_ip_nat_manip_type (enum ip_nat_manip_type * maniptype)
{
nf_debug_indent++;
if (maniptype == NULL)
{
NF_DPF ("pointer to enum ip_nat_manip_type:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("enum ip_nat_manip_type:: [TBD]\n");
nf_debug_indent--;
return;
}
void my_print_ip_nat_hash (struct ip_nat_hash * hash)
{
nf_debug_indent++;
if (hash == NULL)
{
NF_DPF ("pointer to ip_nat_hash:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_nat_hash:: [TBD]\n");
nf_debug_indent--;
return;
}
void my_print_ip_nat_helper (struct ip_nat_helper * helper)
{
nf_debug_indent++;
if (helper == NULL)
{
NF_DPF ("pointer to ip_nat_helper:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_nat_helper:: [TBD]\n");
nf_debug_indent--;
return;
}
void my_print_ip_nat_info_manip (struct ip_nat_info_manip * manip)
{
nf_debug_indent++;
if (manip == NULL)
{
NF_DPF ("pointer to ip_nat_info_manip:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_nat_info_manip:: [TBD]\n");
nf_debug_indent--;
return;
}
void my_print_ip_nat_mapping_type (struct ip_nat_mapping_type * mapping_type)
{
nf_debug_indent++;
if (mapping_type == NULL)
{
NF_DPF ("pointer to ip_nat_mapping_type:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_nat_mapping_type:: [TBD]\n");
nf_debug_indent--;
return;
}
void my_print_ip_nat_seq (struct ip_nat_seq * seq)
{
nf_debug_indent++;
if (seq == NULL)
{
NF_DPF ("pointer to ip_nat_seq:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_nat_seq:: [TBD]\n");
nf_debug_indent--;
return;
}
void my_print_ip_ct_tcp (struct ip_ct_tcp * tcp)
{
nf_debug_indent++;
if (tcp == NULL)
{
NF_DPF ("pointer to ip_ct_tcp:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_ct_tcp:: [TBD]\n");
nf_debug_indent--;
return;
}
void my_print_ip_ct_icmp (struct ip_ct_icmp * icmp)
{
nf_debug_indent++;
if (icmp == NULL)
{
NF_DPF ("pointer to ip_ct_icmp:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_ct_icmp:: [TBD]\n");
nf_debug_indent--;
return;
}
void my_print_timer_list (struct timer_list * timerlist)
{
nf_debug_indent++;
if (timerlist == NULL)
{
NF_DPF ("pointer to timer_list:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("timer_list:: [TBD]\n");
nf_debug_indent--;
return;
}
void my_print_ip_conntrack_tuple_hash (struct ip_conntrack_tuple_hash * hash)
{
nf_debug_indent++;
if (hash == NULL)
{
NF_DPF ("pointer to ip_conntrack_tuple_hash:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_conntrack_tuple_hash:: [TBD]\n");
nf_debug_indent--;
return;
}
void my_print_ip_conntrack_manip_proto (union ip_conntrack_manip_proto * manip_proto)
{
nf_debug_indent++;
if (manip_proto == NULL)
{
NF_DPF ("pointer to ip_conntrack_manip_proto:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_conntrack_manip_proto::Union of all, icmp.id, tcp.port, "
"udp.port = %d\n", manip_proto->all);
nf_debug_indent--;
return;
}
void my_print_ip_nat_range (struct ip_nat_range * range)
{
nf_debug_indent++;
if (range == NULL)
{
NF_DPF ("pointer to ip_nat_range:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_nat_range::flags = %d\n", range->flags);
NF_DPF ("ip_nat_range::min_ip = 0x%08X\n", range->min_ip);
NF_DPF ("ip_nat_range::max_ip = 0x%08X\n", range->max_ip);
NF_DPF ("ip_nat_range::Union of min and max, of type ip_conntrack_manip_proto\n");
my_print_ip_conntrack_manip_proto (&(range->max));
nf_debug_indent--;
return;
}
void my_print_nf_conntrack (struct nf_conntrack * nfc_ptr)
{
nf_debug_indent++;
if (nfc_ptr == NULL)
{
NF_DPF ("pointer to nf_conntrack:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("nf_conntrack::use.counter = %d\n", nfc_ptr->use.counter);
NF_DPF ("nf_conntrack::(*destroy) = %p\n", nfc_ptr->destroy);
nf_debug_indent--;
return;
}
void my_print_list_head (struct list_head * list)
{
nf_debug_indent++;
if (list == NULL)
{
NF_DPF ("list_head:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("list_head::next is of type list_head\n");
my_print_list_head (list->next);
NF_DPF ("list_head::prev is of type list_head\n");
my_print_list_head (list->prev);
nf_debug_indent--;
return;
}
void my_print_ip_conntrack_expect (struct ip_conntrack_expect * expect)
{
nf_debug_indent++;
if (expect == NULL)
{
NF_DPF ("pointer to ip_conntrack_expect:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_conntrack_expect::expectant is of type ip_conntrack\n");
my_print_ip_conntrack (expect->expectant);
NF_DPF ("ip_conntrack_expect::list is of type struct list_head\n");
my_print_list_head (&(expect->list));
NF_DPF ("ip_conntrack_expect::mask is of type struct ip_conntrack_tuple\n");
my_print_ip_conntrack_tuple (&(expect->mask));
NF_DPF ("ip_conntrack_expect::tuple is of type struct ip_conntrack_tuple\n");
my_print_ip_conntrack_tuple (&(expect->tuple));
nf_debug_indent--;
return;
}
void my_print_ip_conntrack_helper (struct ip_conntrack_helper * helper)
{
nf_debug_indent++;
if (helper == NULL)
{
NF_DPF ("ip_conntrack_helper:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_conntrack_helper::list is of type struct list_head [TBD]\n");
/* my_print_list_head (helper->list); */
NF_DPF ("ip_conntrack_helper::mask is of type struct ip_conntrack_tuple [TBD]\n");
/* my_print_ip_conntrack_tuple (&(helper->mask)); */
NF_DPF ("ip_conntrack_helper::tuple is of type struct ip_conntrack_tuple [TBD]\n");
/* my_print_ip_conntrack_tuple (&(helper->tuple)); */
nf_debug_indent--;
return;
}
void my_print_nf_ct_info (struct nf_ct_info * info)
{
nf_debug_indent++;
if (info == NULL)
{
NF_DPF ("pointer to nf_nt_info:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("nf_ct_info::master is of type struct nf_conntrack *\n");
my_print_nf_conntrack (info->master);
nf_debug_indent--;
return;
}
void my_print_ip_nat_info (struct ip_nat_info * info)
{
int i = 0;
nf_debug_indent++;
if (info == NULL)
{
NF_DPF ("pointer to ip_nat_info:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_nat_info::byipsproto is of type struct ip_nat_hash\n");
my_print_ip_nat_hash (&(info->byipsproto));
NF_DPF ("ip_nat_info::bysource is of type struct ip_nat_hash\n");
my_print_ip_nat_hash (&(info->bysource));
NF_DPF ("ip_nat_info::helper is of type struct ip_nat_helper *\n");
my_print_ip_nat_helper (info->helper);
NF_DPF ("ip_nat_info::initialized = %d\n", info->initialized);
NF_DPF ("ip_nat_info::manips[IP_NAT_MAX_MANIPS] is an array of type struct ip_nat_info_manip\n");
for (i = 0; i < IP_NAT_MAX_MANIPS; i++)
{
NF_DPF ("ip_nat_info::manips[%d]\n", i);
my_print_ip_nat_info_manip (&(info->manips[i]));
}
NF_DPF ("ip_nat_info::mtype is of type struct ip_nat_mapping_type *\n");
my_print_ip_nat_mapping_type (info->mtype);
NF_DPF ("ip_nat_info::num_manips = %d\n", info->num_manips);
NF_DPF ("ip_nat_info::seq[IP_CT_DIR_MAX] is an array of type struct ip_nat_seq\n");
for (i = 0; i < IP_CT_DIR_MAX; i++)
{
NF_DPF ("ip_nat_info::seq[%d]\n", i);
my_print_ip_nat_seq (&(info->seq[i]));
}
nf_debug_indent--;
return;
}
void my_print_ip_conntrack (struct ip_conntrack *conntrack)
{
int i = 0;
nf_debug_indent++;
if (conntrack == NULL)
{
NF_DPF ("pointer to ip_conntrack:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_conntrack::ct_general is of type nf_conntrack\n");
my_print_nf_conntrack (&(conntrack->ct_general));
NF_DPF ("ip_conntrack::expected is of type ip_conntrack_expect\n");
my_print_ip_conntrack_expect (&(conntrack->expected));
NF_DPF ("ip_conntrack::help.ct_ftp_info is of type ip_ct_ftp [TBD]\n");
NF_DPF ("ip_conntrack::help.ct_irc_info is of type ip_ct_irc [TBD]\n");
NF_DPF ("ip_conntrack::helper is of type ip_conntrack_helper\n");
my_print_ip_conntrack_helper (conntrack->helper);
NF_DPF ("ip_conntrack::infos[IP_CT_NUMBER] is an array of type nf_ct_info\n");
for (i = 0; i < IP_CT_NUMBER; i++)
{
NF_DPF ("ip_conntrack::infos[%d]\n", i);
my_print_nf_ct_info (&(conntrack->infos[i]));
}
NF_DPF ("ip_conntrack::master is of type nf_ct_info\n");
my_print_nf_ct_info (&(conntrack->master));
NF_DPF ("ip_conntrack::nat is of type anonymous\n");
NF_DPF ("ip_conntrack::nat.masq_index=%d\n", conntrack->nat.masq_index);
NF_DPF ("ip_conntrack::nat.info is of type ip_nat_info\n");
my_print_ip_nat_info (&(conntrack->nat.info));
NF_DPF ("ip_conntrack::Union of tcp and icmp, of type anonymous\n");
my_print_ip_ct_tcp (&(conntrack->proto.tcp));
my_print_ip_ct_icmp (&(conntrack->proto.icmp));
NF_DPF ("ip_conntrack::status = %lu\n", conntrack->status);
NF_DPF ("ip_conntrack::timeout is of type struct timer_list\n");
my_print_timer_list (&(conntrack->timeout));
NF_DPF ("ip_conntrack::tuplehash[IP_CT_DIR_MAX] is an array of type struct ip_conntrack_tuple_hash\n");
for (i = 0; i < IP_CT_DIR_MAX; i++)
{
NF_DPF ("ip_conntrack::tuplehash[%d]\n", i);
my_print_ip_conntrack_tuple_hash (&(conntrack->tuplehash[i]));
}
nf_debug_indent--;
return;
}
void my_print_ip_conntrack_tuple (struct ip_conntrack_tuple *tuple)
{
nf_debug_indent++;
if (tuple == NULL)
{
NF_DPF ("pointer to ip_conntrack_tuple:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_conntrack_tuple::dst.ip = 0x%08X\n", tuple->dst.ip);
NF_DPF ("ip_conntrack_tuple::dst.protonum = %d\n", tuple->dst.protonum);
NF_DPF ("ip_conntrack_tuple::Union of dst.u.all, dst.u.icmp.id, dst.u.tcp.port, "
"dst.u.udp.port = %d\n", tuple->dst.u.all);
NF_DPF ("ip_conntrack_tuple::src is of type ip_conntrack_manip\n");
my_print_ip_conntrack_manip (&(tuple->src));
nf_debug_indent--;
return;
}
void my_print_maniptype (enum ip_nat_manip_type maniptype)
{
nf_debug_indent++;
if (maniptype == IP_NAT_MANIP_SRC)
{
NF_DPF ("ip_nat_manip_type::IP_NAT_MANIP_SRC\n");
}
else if (maniptype == IP_NAT_MANIP_DST)
{
NF_DPF ("ip_nat_manip_type::IP_NAT_MANIP_DST\n");
}
else
{
NF_DPF ("ip_nat_manip_type::maniptype=%d (Unknown)\n", maniptype);
}
nf_debug_indent--;
return;
}
void my_print_ip_conntrack_manip (struct ip_conntrack_manip * manip)
{
nf_debug_indent++;
if (manip == NULL)
{
NF_DPF ("pointer to ip_conntrack_manip:: is NULL\n");
nf_debug_indent--;
return;
}
NF_DPF ("ip_conntrack_manip::ip = 0x%08X\n", manip->ip);
NF_DPF ("ip_conntrack_manip::u is of type ip_conntrack_manip_proto\n");
my_print_ip_conntrack_manip_proto (&(manip->u));
nf_debug_indent--;
return;
}
[-- Attachment #3: nf_debug.h --]
[-- Type: application/octet-stream, Size: 1848 bytes --]
#ifndef _NF_DEBUG_H_
#define _NF_DEBUG_H_
/* Written by Ranjeet dot Shetye at Zultys dot com */
#include <linux/types.h>
#include <linux/init.h>
#include <linux/netfilter.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/if.h>
#include <linux/netfilter_ipv4/ip_nat.h>
#include <linux/netfilter_ipv4/ip_nat_rule.h>
#include <linux/netfilter_ipv4/ip_nat_protocol.h>
void my_print_ip_nat_manip_type (enum ip_nat_manip_type * maniptype);
void my_print_ip_nat_hash (struct ip_nat_hash * hash);
void my_print_ip_nat_helper (struct ip_nat_helper * helper);
void my_print_ip_nat_info_manip (struct ip_nat_info_manip * manip);
void my_print_ip_nat_mapping_type (struct ip_nat_mapping_type * mapping_type);
void my_print_ip_nat_seq (struct ip_nat_seq * seq);
void my_print_ip_ct_tcp (struct ip_ct_tcp * tcp);
void my_print_ip_ct_icmp (struct ip_ct_icmp * icmp);
void my_print_timer_list (struct timer_list * timerlist);
void my_print_ip_conntrack_tuple_hash (struct ip_conntrack_tuple_hash * hash);
void my_print_ip_conntrack_manip_proto (union ip_conntrack_manip_proto * manip_proto);
void my_print_ip_nat_range (struct ip_nat_range * range);
void my_print_nf_conntrack (struct nf_conntrack * nfc_ptr);
void my_print_list_head (struct list_head * list);
void my_print_ip_conntrack_expect (struct ip_conntrack_expect * expect);
void my_print_ip_conntrack_helper (struct ip_conntrack_helper * helper);
void my_print_nf_ct_info (struct nf_ct_info * info);
void my_print_ip_nat_info (struct ip_nat_info * info);
void my_print_ip_conntrack (struct ip_conntrack *conntrack);
void my_print_ip_conntrack_tuple (struct ip_conntrack_tuple *tuple);
void my_print_maniptype (enum ip_nat_manip_type maniptype);
void my_print_ip_conntrack_manip (struct ip_conntrack_manip * manip);
#endif /* _NF_DEBUG_H_ */
^ permalink raw reply
* Re: [Linux-ia64] RTC support on ia64
From: Alex Williamson @ 2002-12-17 20:13 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805600@msgid-missing>
Joel,
Does this provide more functionality than the EFI RTC?
Concerns I have w/ it on ia64 is that the rtc driver assumes
you have a legacy rtc at the legacy irq and port address.
This won't work on HP zx1 boxes, the legacy hardware doesn't
exist. In the future, there's a possibility that the port
address could be allocated to non-legacy purposes. Maybe
ACPI could tell you if you have a legacy RTC, it could at
least tell you if you support PC/AT compatible interrupts.
Thanks,
Alex
Joel GUILLET wrote:
>
> Hi,
>
> Here is a patch to use the Real Time Clock (RTC) on ia64.
> It works on a tiger. It doesn't on early lion machines. (Why ?)
> I don't know about others ia64 machines. Please report me - if you test
> it.
> To see if it works, please check the /var/log/messages. The driver reports
> sometimes that "rtc losts some interrupts..." It usually means that the
> rtc doesn't work, and the interruptions that arrived were coming from a
> software-timer (see the driver code).
>
> This patch is very simple.
> I changed the irq affected for the rtc as it is an "ex-i386" interruption.
> (an Ox20 offset)
> And copied some files from the asm-i386 to asm-ia64...
> The duplication of these files is a waste of disk space, but it's coherent
> with the way it has been made on i386.
>
> You may want to try this patch and test it.
> There is a program test included in the Documentation/rtc.txt of the
> kernel tree.
>
> The actual priority of the interruption is low but perhaps it might be
> changed (Do anyone know how to make it ?) for some usages.
>
> For the kernel releases after 2.5.45, I've seen that the Kconfig will be
> modified so that the option will not be available (unless you activate it
> manually).
>
> This can be used for example to run scheduler latencies tests (a way of
> using amlat) - I've got some more stuff for this, please mail me.
>
> Here is the patch :
>
> ********************************************
> diff -urN linux-2.5.45/arch/ia64/kernel/ia64_ksyms.c linux-2.5.45-clean/arch/ia64/kernel/ia64_ksyms.c
> --- linux-2.5.45/arch/ia64/kernel/ia64_ksyms.c Thu Oct 31 01:42:54 2002
> +++ linux-2.5.45-clean/arch/ia64/kernel/ia64_ksyms.c Tue Dec 17 15:08:19 2002
> @@ -143,3 +143,5 @@
> #endif
> EXPORT_SYMBOL(machvec_noop);
>
> +extern spinlock_t rtc_lock;
> +EXPORT_SYMBOL(rtc_lock);
> diff -urN linux-2.5.45/arch/ia64/kernel/time.c linux-2.5.45-clean/arch/ia64/kernel/time.c
> --- linux-2.5.45/arch/ia64/kernel/time.c Thu Oct 31 01:42:20 2002
> +++ linux-2.5.45-clean/arch/ia64/kernel/time.c Tue Dec 17 15:08:19 2002
> @@ -27,6 +27,7 @@
> extern rwlock_t xtime_lock;
> extern unsigned long wall_jiffies;
> extern unsigned long last_time_offset;
> +spinlock_t rtc_lock = SPIN_LOCK_UNLOCKED;
>
> u64 jiffies_64;
>
> diff -urN linux-2.5.45/include/asm-ia64/mc146818rtc.h linux-2.5.45-clean/include/asm-ia64/mc146818rtc.h
> --- linux-2.5.45/include/asm-ia64/mc146818rtc.h Thu Oct 31 01:43:38 2002
> +++ linux-2.5.45-clean/include/asm-ia64/mc146818rtc.h Tue Dec 17 15:10:12 2002
> @@ -1,10 +1,29 @@
> +/*
> + * Machine dependent access functions for RTC registers.
> + */
> #ifndef _ASM_IA64_MC146818RTC_H
> #define _ASM_IA64_MC146818RTC_H
>
> +#include <asm/io.h>
> +
> +#ifndef RTC_PORT
> +#define RTC_PORT(x) (0x70 + (x))
> +#define RTC_ALWAYS_BCD 1 /* RTC operates in binary mode */
> +#endif
> +
> /*
> - * Machine dependent access functions for RTC registers.
> + * The yet supported machines all access the RTC index register via
> + * an ISA port access but the way to access the date register differs ...
> */
> +#define CMOS_READ(addr) ({ \
> +outb_p((addr),RTC_PORT(0)); \
> +inb_p(RTC_PORT(1)); \
> +})
> +#define CMOS_WRITE(val, addr) ({ \
> +outb_p((addr),RTC_PORT(0)); \
> +outb_p((val),RTC_PORT(1)); \
> +})
>
> -/* empty include file to satisfy the include in genrtc.c */
> +#define RTC_IRQ 40 /* irq on a i386 + Ox20 */
>
> #endif /* _ASM_IA64_MC146818RTC_H */
> diff -urN linux-2.5.45/include/asm-ia64/rtc.h linux-2.5.45-clean/include/asm-ia64/rtc.h
> --- linux-2.5.45/include/asm-ia64/rtc.h Thu Jan 1 01:00:00 1970
> +++ linux-2.5.45-clean/include/asm-ia64/rtc.h Tue Dec 17 15:09:03 2002
> @@ -0,0 +1,10 @@
> +#ifndef _IA64_RTC_H
> +#define _IA64_RTC_H
> +
> +/*
> + * ia64 uses the default access methods for the RTC.
> + */
> +
> +#include <asm-generic/rtc.h>
> +
> +#endif
> **************************************************************
>
> --------------
> ** Joel
>
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
--
Alex Williamson Linux Development Lab
alex_williamson@hp.com Hewlett Packard
970-898-9173 Fort Collins, CO
^ permalink raw reply
* [PATCH] acpi_wakeup fixes
From: Ducrot Bruno @ 2002-12-17 20:21 UTC (permalink / raw)
To: Pavel Machek; +Cc: Grover, Andrew, acpi-devel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 155 bytes --]
Hi Pavel.
This diff should be OK (I hope)
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
[-- Attachment #2: 00_acpi_wakeup.S.fix --]
[-- Type: text/plain, Size: 679 bytes --]
--- linux-2.5.52/arch/i386/kernel/acpi_wakeup.S 2002/12/17 19:15:12 1.1
+++ linux-2.5.52/arch/i386/kernel/acpi_wakeup.S 2002/12/17 20:03:40
@@ -41,7 +41,7 @@
cmpl $0x12345678, %eax
jne bogus_real_magic
-#if 1
+#if 0
lcall $0xc000,$3
#endif
#if 0
@@ -69,8 +69,12 @@
movl real_save_cr0 - wakeup_code, %eax
movl %eax, %cr0
+
+ # flush the prefetch queue.
jmp 1f
+1: jmp 1f
1:
+
movw $0x0e00 + 'n', %fs:(0x14)
movl real_magic - wakeup_code, %eax
@@ -160,11 +164,12 @@
ALIGN
-.org 0x2000
+.org 0x800
wakeup_stack:
-.org 0x3000
+.org 0x900
ENTRY(wakeup_end)
-.org 0x4000
+# .org 0x1000
+ .align 4096
wakeup_pmode_return:
movl $__KERNEL_DS, %eax
^ permalink raw reply
* RE: [PATCH] 2.4.21pre1 cpqfc
From: White, Charles @ 2002-12-17 20:19 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
Is this enough detail?
#1) Initialize DumCmnd.lun (used as LUN index in fcFindLoggedInPort()).
There is a senerio where the value remands
from the last ioctl command.
#2) Checked for invalid values being return by the device.
-----Original Message-----
From: Marcelo Tosatti [mailto:marcelo@conectiva.com.br]
Sent: Tuesday, December 17, 2002 10:58 AM
To: White, Charles
Cc: lkml
Subject: Re: [PATCH] 2.4.21pre1 cpqfc
Could you make a short list of the fixed bugs?
On Tue, 17 Dec 2002, White, Charles wrote:
> This patch fixes two minor bugs in cpqfc and makes it version 2.1.2.
>
> diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfc.Readme
> linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfc.Readme
> --- linux-2.4.21-pre1.orig/drivers/scsi/cpqfc.Readme Thu Oct 25
> 16:53:50 2001
> +++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfc.Readme Tue Dec
> 17 09:33:18 2002
> @@ -22,6 +22,9 @@
> * Makefile changes to bring cpqfc into line w/ rest of SCSI
drivers
> (thanks to Keith Owens)
>
> +Ver 2.1.2 Jul 22, 2002
> + * initialize DumCmnd.lun (used as LUN index in
> +fcFindLoggedInPort())
> +
> Ver 2.0.5 Aug 06, 2001
> * Reject non-existent luns in the driver rather than letting the
> hardware do it. (some HW behaves differently than others in
> this
> area.)
> diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSinit.c
> linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSinit.c
> --- linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSinit.c Tue Dec 17
> 09:25:01 2002
> +++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSinit.c Tue Dec
> 17 13:18:20 2002
> @@ -64,7 +64,7 @@
>
> /* Embedded module documentation macros - see module.h */
> MODULE_AUTHOR("Compaq Computer Corporation");
> -MODULE_DESCRIPTION("Driver for Compaq 64-bit/66Mhz PCI Fibre Channel
> HBA v. 2.1.1");
> +MODULE_DESCRIPTION("Driver for Compaq 64-bit/66Mhz PCI Fibre Channel
> HBA v. 2.1.2");
> MODULE_LICENSE("GPL");
>
> int cpqfcTS_TargetDeviceReset(Scsi_Device * ScsiDev, unsigned int
> reset_flags); @@ -411,6 +411,7 @@
> // can we find an FC device mapping to this SCSI target?
> DumCmnd.channel = ScsiDev->channel; // For searching
> DumCmnd.target = ScsiDev->id;
> + DumCmnd.lun = ScsiDev->lun;
> pLoggedInPort = fcFindLoggedInPort(fcChip, &DumCmnd, //
> search Scsi Nexus
> 0, // DON'T search linked
> list for FC port id
> NULL, // DON'T search
> linked list for FC WWN
> diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSstructs.h
> linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSstructs.h
> --- linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSstructs.h Tue Dec
> 17 09:25:01 2002
> +++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSstructs.h Tue Dec
> 17 09:33:18 2002
> @@ -35,7 +35,7 @@
> /* don't forget to also change MODULE_DESCRIPTION in cpqfcTSinit.c */
> #define VER_MAJOR 2 #define VER_MINOR 1
> -#define VER_SUBMINOR 1
> +#define VER_SUBMINOR 2
>
> /*
> * Macros for kernel (esp. SMP) tracing using a PCI analyzer
> diff -urN linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSworker.c
> linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSworker.c
> --- linux-2.4.21-pre1.orig/drivers/scsi/cpqfcTSworker.c Tue Dec
17
> 09:25:01 2002
> +++ linux-2.4.21-pre1.cpqfc212/drivers/scsi/cpqfcTSworker.c Tue Dec
> 17 09:41:11 2002
> @@ -2706,6 +2706,10 @@
> // Report Luns command
> if
> (pLoggedInPort->ScsiNexus.LunMasking == 1) {
> // we KNOW all the valid
> LUNs... 0xFF is invalid!
> + if (Cmnd->lun >
> sizeof(pLoggedInPort->ScsiNexus.lun)){
> + // printk("
> cpqfcTS FATAL: Invalid LUN index !!!!\n ");
> + return NULL;
> + }
> Cmnd->SCp.have_data_in =
> pLoggedInPort->ScsiNexus.lun[Cmnd->lun];
> if
> (pLoggedInPort->ScsiNexus.lun[Cmnd->lun] == 0xFF)
> return NULL;
> -
> 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: 3c59x AUI and sockets AF_PACKET
From: Ben Greear @ 2002-12-17 20:10 UTC (permalink / raw)
To: kernel; +Cc: netdev
In-Reply-To: <1939.192.168.0.31.1040120199.squirrel@www.itris.fr>
kernel@itris.fr wrote:
> Hi,
>
> I have got an important problem to solve :
>
> When I load the 3c59x module with no option, my 2 network cards
> are working well with 10baseT, and vortex-diag tells me then :
> Transceiver type in use: Autonegociate.
>
> I can open a socket with AF_PACKET level, and bind() works fine !
> I can send data to the socket through RJ45.
>
> But, when I load 3c59x with options=1, vortex-diag tells me
> Transceiver type in use : AUI10baseFL.
>
> I can configure my 2 network cards with ifconfig.
>
> Everything is ok, but, when i want to open my socket AF_PACKET to
> send data to AUI port, bind () returns -1, as though all my interfaces
> are ok (ifconfig sees them all).
After the call fails, do this (it may offer a clue):
printf("%i: %s\n", errno, strerror(errno));
/* Hopes syntax is correct */
>
> I would like to send data to AUI, what is the problem ?
>
> Thanks !!
>
> Christophe Baillon
>
>
--
Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Ulrich Drepper @ 2002-12-17 20:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel,
hpa
In-Reply-To: <Pine.LNX.4.44.0212171159440.1095-100000@home.transmeta.com>
Linus Torvalds wrote:
> ===== arch/i386/kernel/sysenter.c 1.1 vs edited =====
> --- 1.1/arch/i386/kernel/sysenter.c Mon Dec 16 21:39:04 2002
> +++ edited/arch/i386/kernel/sysenter.c Tue Dec 17 11:39:39 2002
> @@ -48,14 +48,14 @@
> 0xc3 /* ret */
> };
> static const char sysent[] = {
> - 0x55, /* push %ebp */
> 0x51, /* push %ecx */
> 0x52, /* push %edx */
> + 0x55, /* push %ebp */
> 0x89, 0xe5, /* movl %esp,%ebp */
> 0x0f, 0x34, /* sysenter */
> + 0x5d, /* pop %ebp */
> 0x5a, /* pop %edx */
> 0x59, /* pop %ecx */
> - 0x5d, /* pop %ebp */
> 0xc3 /* ret */
Instead of duplicating the push/pop %ebp just use the first one by using
movl 12(%ebo), %ebp
in the kernel code or remove the first. The later is better, smaller code.
--
--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 20:16 UTC (permalink / raw)
To: Alan Cox
Cc: Martin J. Bligh, Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List
In-Reply-To: <1040158271.20765.26.camel@irongate.swansea.linux.org.uk>
Alan Cox wrote:
> On Tue, 2002-12-17 at 19:26, Martin J. Bligh wrote:
>
>>>>It's not as good as a pure user-mode solution using tsc could be, but
>>
>>You can't use the TSC to do gettimeofday on boxes where they aren't
>>syncronised anyway though. That's nothing to do with vsyscalls, you just
>>need a different time source (eg the legacy stuff or HPET/cyclone).
>
>
> Ditto all the laptops and the like. With code provided by the kernel we
> can cheat however. If we know the fastest the CPU can go (ie full speed
> on spudstop/powernow etc) we can tell the tsc value at which we have to
> query the kernel to get time to any given accuracy, so allowing limited
> caching
>
> Ditto by knowing the worst case drift on summit
>
Clever. I like it :)
-hpa
^ permalink raw reply
* mac address change on an eth alias
From: Petre Bandac @ 2002-12-17 20:07 UTC (permalink / raw)
To: linux-newbie
root@k:~# ifconfig eth0:1 123.123.123.123 netmask 255.255.255.0 hw ether
00:E0:7D:02:C6:0C
SIOCSIFHWADDR: Device or resource busy
root@k:~#
am I trying to do something impossible or is it only my NIC (Realtek 8139)
that can't do it ?
I want to have 2 ip's on the same interface - but with 2 different macs ...
why? because this is my testing server and, among others (dhcp, bind,
sendmail/postfix, asterisk, etc) I want to actually see how a mac address can
be changed ... if it's possible
thank you for you patience,
petre
--
22:01:49 up 5:31, 1 user, load average: 0.04, 0.11, 0.14
-
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
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.