Re: Ideas for TUX2
>> If a file's data has been changed, it suffices to update the inode and the >> of free blocks bitmap (fbb). >> But updating them in one go is not possible > >You seem to have missed some fundamental understanding of >exactly how phase tree works; the wohle point of phase >tree is to make atomic updates like this possible! Well, my point was, that with several thousand inodes spread over the disk it won't always be possible to update the inode AND the fbb in one go. So I proposed the 2nd inode with generation counter! Regards, Phil - 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/
[PATCH] update for ALi Audio Driver
Dear all,
Here is ALi M5451 audio's patch file. In this new release ,version 0.14.8, we've
made such modifications.
1, Set EBUF1 and EBUF2 to still mode to avoid that upon some platforms the audio
will stop after playing for a while.
2, Reset m5451 controller to avoid ac97 access timeout error.
3, Fix bug in power management function ali_restore_regs.
4, Add cache for ac97 access to avoid access to ac97 codec at runtime.
Best regards,
Matt Wu
http://www.ali.com.tw
Information about update:
Updated files: trident.c trident.h
Location: drivers/sound
Driver Version: 0.14.8
Kernel Version: 2.4.X
patch file:
--- drivers/sound/trident.h.orig Tue Jul 3 13:42:35 2001
+++ drivers/sound/trident.h Tue Jul 3 13:44:18 2001
@@ -90,7 +90,10 @@
T4D_STOP_B = 0xb8, T4D_CSPF_B = 0xbc,
T4D_SBBL_SBCL = 0xc0, T4D_SBCTRL_SBE2R_SBDD= 0xc4,
T4D_STIMER = 0xc8, T4D_LFO_B_I2S_DELTA = 0xcc,
-T4D_AINT_B = 0xd8, T4D_AINTEN_B= 0xdc
+T4D_AINT_B = 0xd8, T4D_AINTEN_B= 0xdc,
+ALI_MPUR2 = 0x22,
+ALI_EBUF1 = 0xf4,
+ALI_EBUF2 = 0xf8
};
enum ali_op_registers {
@@ -137,6 +140,13 @@
ALI_STOP_ALL_CHANNELS= 0x,
ALI_MULTI_CHANNELS_START_STOP = 0x0780
+};
+
+enum ali_EMOD_control_bit {
+ALI_EMOD_DEC = 0x,
+ALI_EMOD_INC = 0x1000,
+ALI_EMOD_Delay = 0x2000,
+ALI_EMOD_Still = 0x3000
};
enum ali_pcm_in_channel_num {
--- drivers/sound/trident.c.orig Tue Jul 3 13:41:23 2001
+++ drivers/sound/trident.c Tue Jul 3 13:44:14 2001
@@ -12,7 +12,6 @@
* Hacked up by:
* Aaron Holtzman <[EMAIL PROTECTED]>
* Ollie Lho <[EMAIL PROTECTED]> SiS 7018 Audio Core Support
- * Ching-Ling Lee <[EMAIL PROTECTED]> ALi 5451 Audio Core Support
* Matt Wu <[EMAIL PROTECTED]> ALi 5451 Audio Core Support
*
*
@@ -31,6 +30,13 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* History
+ * v0.14.8
+ * Apr 30 2001 Matt Wu
+ * Set EBUF1 and EBUF2 to still mode
+ * Add dc97/ac97 reset function
+ * Fix power management: ali_restore_regs
+ * Mar 09 2001 Matt Wu
+ * Add cache for ac97 access
* v0.14.7
* Feb 06 2001 Matt Wu
* Fix ac97 initialization
@@ -135,7 +141,7 @@
#include
-#define DRIVER_VERSION "0.14.6"
+#define DRIVER_VERSION "0.14.8"
/* magic numbers to protect our data structures */
#define TRIDENT_CARD_MAGIC 0x5072696E /* "Prin" */
@@ -319,10 +325,12 @@
struct trident_channel *(*alloc_rec_pcm_channel)(struct trident_card *);
void (*free_pcm_channel)(struct trident_card *, unsigned int chan);
void (*address_interrupt)(struct trident_card *);
+
-/* Add by Matt Wu 01-05-2001 for spdif in */
-int multi_channel_use_count;
-int rec_channel_use_count;
+//Add by Matt Wu 01-05-2001 for spdif in
+int multi_channel_use_count;
+int rec_channel_use_count;
+//End add
};
/* table to map from CHANNELMASK to channel attribute for SiS 7018 */
@@ -338,10 +346,18 @@
DSP_BIND_I2S, DSP_BIND_CENTER_LFE, DSP_BIND_SURR, DSP_BIND_SPDIF
};
-/* Add by Matt Wu 01-05-2001 for spdif in */
+
+//Add by Matt Wu 01-05-2001 for spdif in
static int ali_close_multi_channels(void);
-static void ali_delay(struct trident_card *card,int interval);
-static void ali_detect_spdif_rate(struct trident_card *card);
+void ali_delay(struct trident_card *card,int interval);
+void ali_detect_spdif_rate(struct trident_card *card);
+//End add
+
+u16 MixerRegs[64][NR_AC97];
+int bRegsReady = 0;
+
+static void ali_ac97_write(struct ac97_codec *codec, u8 reg, u16 val);
+static u16 ali_ac97_read(struct ac97_codec *codec, u8 reg);
static struct trident_card *devs;
@@ -353,8 +369,8 @@
unsigned long arg);
static loff_t trident_llseek(struct file *file, loff_t offset, int origin);
-static void ali_ac97_set(struct ac97_codec *codec, u8 reg, u16 val);
-static u16 ali_ac97_get(struct ac97_codec *codec, u8 reg);
+static void ali_ac97_set(struct trident_card *card, int secondary, u8 reg, u16
val);
+static u16 ali_ac97_get(struct trident_card *card, int secondary, u8 reg);
static void ali_set_spdif_out_rate(struct trident_card *card, unsigned int
rate);
static void ali_enable_special_channel(struct trident_state *stat);
static struct trident_channel *ali_alloc_rec_pcm_channel(struct trident_card
*card);
@@ -381,6 +397,7 @@
unsigned mixer_regs[ALI_MIXER_REGS];
} ali_registers;
+
#define seek_offset(dma_ptr, buffer, cnt, offset, copy_count)(dma_ptr) +=
(offset); \
(buffer) += (offset); \
(cnt) -= (offset); \
@@ -599,6 +616,9 @@
/* select hardware channel to write */
outb(channel, TRID_REG(card, T4D_LFO_GC_CIR));
+#ifdef DEBUG
+printk("GC_CIR=%xh\n", inb(TRID_REG(card, T4D_LFO_GC_CIR)));
+#endif
/* Output the channel registers, but don't write
[PATCH] initial detailed VM statistics code
Hi, Well, I've started working on VM stats code for 2.4. vmstat output: # r b w swpd free buff cache si sobibo incs us sy id # 0 1 1 102624 1412120 89472 90 9114 304 9160 336 1102 12 7 92 This is the already known part.. # launder launder_w ref_inact alloc_r kswapd_w krec_w kflush_w # 33 11 1471260 23328 151 First, the global statistics: launder: nr of page_launder() calls launder_w: nr of times page_launder() started writing out pages ref_inac: nr of refill_inactive_scan() calls alloc_r: number of reschedules on __alloc_pages() kswapd_w: kswapd wakeups krec_w: kreclaimd wakeups kflush_w: kflushd wakeups # Zone fshort ishort scan clean skipl skipd launder react rescue deact recfail #DMA 0224 3915 1500342 1406531153 0 452 636 # Normal 0 0 28073 12490 2451 9295 2678676 0 2654 947 Then the perzone statistics: fshort: per-zone free shortage ishort: per-zone inactive shortage scan: number of pages scanned by page_launder clean: number of pages cleaned by page_launder skipl: number of locked pages skipped by page_launder skipd: number of unlocked but dirty pages skipped by page_launder launder: number of pages laundered by page_launder react: number of pages reactivated by page_launder rescue: number of pages reactivated by reclaim_page deat: number of pages deactivated by refill_inactive_scan recfail: number of reclaim_page failures The code: Patch against 2.4.6pre9: http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.6pre9/vmstats.patch Patch against procps from Conectiva's srpm (which is not stock procps): http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.6pre9/procps.patch And full vmstat.c so people don't need to get Conectiva's srpm: http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.6pre9/vmstat.c The vmstat code is really crappy and new fields are painfull to add. If anyone is willing to help me to write a decent vmstat, tell me. The hacked vmstat will coredump on a non-patched kernel. - 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: history of mrproper
On Tue, 3 Jul 2001, Mike Sklar wrote: > > Hopefully someone could enlighten me on the history of mrproper. I think > its a great name for making sources *proper*. In particular I'd like to > know what the *mr* might stand for. > Mr Proper looks like he's an alias of Mr. Clean (Procter and Gamble). A very appropriate name considering the deep cleaning that "make mrproper" does! See e.g. www.mrproper.de and www.mrclean.com :-) - 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: history of mrproper
Mr. Proper On Tue, 3 Jul 2001, Mike Sklar wrote: > > Hopefully someone could enlighten me on the history of mrproper. I think > its a great name for making sources *proper*. In particular I'd like to > know what the *mr* might stand for. > > - > 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/ > - 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: history of mrproper
On Tuesday 03 July 2001 22:33, Mike Sklar ignorantly blabbered: > Hopefully someone could enlighten me on the history of mrproper. I think > its a great name for making sources *proper*. In particular I'd like to > know what the *mr* might stand for. To differentiate it from Mrs. Proper. -- Regards, Kurt Weber [EMAIL PROTECTED] - 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: Why Plan 9 C compilers don't have asm("")
On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote:
> In other words, if you know the push sequence of your C compiler's
> function calls, you don't need asm("");.
You are very much forgetting _inline_ asm. And if you think that's
unimportant for performance, well, as Al would say, go back playing
with Hurd.
OG.
-
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/
history of mrproper
Hopefully someone could enlighten me on the history of mrproper. I think its a great name for making sources *proper*. In particular I'd like to know what the *mr* might stand for. - 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/
Why Plan 9 C compilers don't have asm("")
Because it's messy and unnecessary. Break this into asmlinkbuild,
asmlink.c, asmlink.h and asmlink.S, chmod +x asmlinkbuild, run it, and
behold a 6.
__
#..
# asmlinkbuild
gcc -c asmlink.S
gcc -o asmlinked asmlink.c asmlink.o
asmlinked
cat asmlinkbuild asmlink.S asmlink.c > asmlink.post
/* ***
asmlink.S
int bla (int ha, int hahaha, int uh) ;
That does...
push uh
push hahaha
push ha
*/
.globl bla
bla:
add 4(%esp), %eax
add 8(%esp), %eax
add 12(%esp), %eax
ret
/* asmlink.c */
#include "asmlink.h"
int main () {
printf("%d\n", bla(1, 2 , 3 ) ) ;
}
_
That's with the GNU tools, without asm(), and without proper declaration
of printf, as is my tendency. I don't actually return an int either, do I?
LAAETTR.
In other words, if you know the push sequence of your C compiler's
function calls, you don't need asm("");. x86 Gcc is "push last declared
first, return in EAX". Plan 9 guys, not surprisingly, seem to prefer to
keep C as C, and asm as asm. I encountered this while trying to build
Linux 1.2.13 with current GNU tools. It breaks on changes in GNU C
asm()'s. Rather a silly thing to break on, eh?
I don't think this is much less clear than the : "=r" $0; stuff, if at
all. This thing didn't take as long to code as it did to construct this
post. Perhaps the C-labels-in-asms optimizes better. I doubt if it's by
much, or if it's worth it.
Oops. I didn't include asmlink.h in the above, except as a comment
in asmlink.S. Here it is by itself...
/* asmlink.h*/
int bla (int ha, int hahaha, int uh) ;
Another easy win from Plan 9 that's related to this but that is not in
evidence here is that this thing on Plan 9 could build asmlinkbuild for
itself on the fly based on #pragma's in the headers that simply state what
library they are the header for. This to me is so obviously an improvement
to the usual state of affairs, an ornate system of dead-ends, as to be
depressing. The guys that wrote UNIX don't do such things to themselves
anymore.
Rick Hohensee
:; cLIeNUX /dev/tty11 11:00:14 /
:;d
ABOUTLGPL boot device log subroutine
ABOUT.Linux Linuxcommand floppy mounts suite
GPL README configureguestownertemp
H3nixRIGHTS dev help source
:; cLIeNUX /dev/tty11 22:44:25 /
:;
-
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/
What are rules for acpi_ex_enter_interpreter?
Hi Andrew,
ACPI was reporting no S* states on my machine (ASUS A7V) for some time
and today I finally got some time to debug it. Problem is that during
initialization namespace init calls acpi_walk_namespace without
interpreter lock held - but it is wrong - as you can see from stack
trace, acpi_walk_namespace can call down to acpi_ev_address_space_dispatch,
which can call acpi_ex_exit_interpreter - and this is fatal on unlocked
lock :-(
This points us to another problem - when acpi is compiled into kernel,
for some reason there is pending signal in thread doing ospm_busmgr and
ospm_system initialization, so it fails to acquire lock because of
down_interruptible fails... but does not print any message, just no
valid S states are found. When acpi is compiled as module, modprobe
hangs until you hit ^C - then it is converted to previous case - module
says OK, but did nothing in reality.
I did NOT verified other callers of acpi_walk_namespace... And there
is still some problem left, as although now S5 is listed as available,
poweroff still does nothing instead of poweroff.
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
Jul 4 02:03:02 ppc kernel: CPU:0
Jul 4 02:03:02 ppc kernel: EIP:0010:[printstate+9/48]
Jul 4 02:03:02 ppc kernel: EFLAGS: 0202
Jul 4 02:03:02 ppc kernel: eax: 000e ebx: c01680d0 ecx: c020e996 edx:
0001
Jul 4 02:03:02 ppc kernel: esi: cff75e3c edi: c1428a4c ebp: c1428c8c esp:
c140dc34
Jul 4 02:03:02 ppc kernel: ds: 0018 es: 0018 ss: 0018
Jul 4 02:03:02 ppc kernel: Process swapper (pid: 1, stackpage=c140d000)
Jul 4 02:03:02 ppc kernel: Stack: c140dc38 0018 c016955a c016206c 000fdf00
Jul 4 02:03:02 ppc kernel:c1428a4c c140dcd4 c0166438 c1428a4c 0001
000fdf00 0020
Jul 4 02:03:02 ppc kernel:c140dcd4 c140e50c c020c5cc c015c8a5 c140e50c
c020c685 0001 c020e320
Jul 4 02:03:02 ppc kernel: Call Trace: [acpi_ex_exit_interpreter+26/48]
[acpi_ev_address_space_dispatch+124/208] [acpi_ex_read_field_datum+120/224]
[debug_print+21/160] [function_status_exit+49/64]
Jul 4 02:03:02 ppc kernel:[acpi_ex_extract_from_field+123/432]
[acpi_ex_common_access_field+56/64] [acpi_ex_access_region_field+36/64]
[acpi_ex_read_data_from_field+220/288] [acpi_ex_resolve_node_to_value+411/560]
[acpi_ex_resolve_to_value+42/80]
Jul 4 02:03:02 ppc kernel:[acpi_ex_resolve_operands+282/768]
[acpi_ds_eval_region_operands+56/144] [acpi_ds_exec_end_op+705/752]
[acpi_ps_parse_loop+945/1904] [acpi_ut_release_mutex+103/144]
[acpi_ut_create_generic_state+63/128]
Jul 4 02:03:02 ppc kernel:[acpi_ps_parse_aml+519/640]
[acpi_ds_get_region_arguments+222/256] [acpi_ds_exec_begin_op+0/304]
[acpi_ds_exec_end_op+0/752] [acpi_ns_init_one_object+91/96]
[acpi_ns_walk_namespace+193/288]
Jul 4 02:03:02 ppc kernel:[acpi_ns_init_one_object+0/96]
[acpi_walk_namespace+85/128] [acpi_ns_init_one_object+0/96]
[acpi_ns_initialize_objects+61/80] [acpi_ns_init_one_object+0/96]
[acpi_enable_subsystem+149/320]
Jul 4 02:03:02 ppc kernel:[acpi_enable_subsystem+188/320] [acpi_init+283/352]
[rest_init+0/48] [init+11/320] [rest_init+0/48] [kernel_thread+38/48]
Jul 4 02:03:02 ppc kernel:[init+0/320]
Jul 4 02:03:02 ppc kernel:
Jul 4 02:03:02 ppc kernel: Code: 50 1e 06 50 55 57 56 52 51 53 89 e0 50 e8 b5 fe ff
ff 83 c4
diff -urdN linux/drivers/acpi/namespace/nsinit.c linux/drivers/acpi/namespace/nsinit.c
--- linux/drivers/acpi/namespace/nsinit.c Tue Jul 3 15:58:35 2001
+++ linux/drivers/acpi/namespace/nsinit.c Wed Jul 4 02:20:49 2001
@@ -27,6 +27,7 @@
#include "acpi.h"
#include "acnamesp.h"
#include "acdispat.h"
+#include "acinterp.h"
#define _COMPONENT ACPI_NAMESPACE
MODULE_NAME ("nsinit")
@@ -62,10 +63,17 @@
/* Walk entire namespace from the supplied root */
+ status = acpi_ex_enter_interpreter();
+ if (ACPI_FAILURE(status)) {
+ return status;
+ }
+
status = acpi_walk_namespace (ACPI_TYPE_ANY, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, acpi_ns_init_one_object,
, NULL);
+ acpi_ex_exit_interpreter();
+
return (AE_OK);
}
-
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: [PATCH] small patch to ide-tape.c
> This patch adds a missing semicolon that is noticed only if you define > IDETAPE_DEBUG_LOG_VERBOSE: > > John Guthrie > [EMAIL PROTECTED] It makes me curious, why do you need to define IDETAPE_DEBUG_LOG_VERBOSE? I fixed some stuff with files not restoring properly with last block corrupt. Talking with Andre and Gadi now. What is your problem? -- Pete - 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: USB printing == kernel lockup?
> When I do anything (print to it, query its ink levels with escputil, > etc.) with my Epson 870 while it's hooked to my computer via USB, the > whole machine locks hard. [...] > Has anyone else has seen this problem? I posted to the gimp-print and > linux-usb lists, but there was nary a response. I think I saw your message, but very little can be extracted from that data. -- Pete - 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: Sticky IO-APIC problem
"Randy.Dunlap" <[EMAIL PROTECTED]> wrote: >What mobo (model/name) is it? >Can you give us the output from "lspci -vv"? OK, it's an Intel BN810E Desktop Board; here's the output from lspci -vv: [root@fortytwo /root]# lspci -vv 00:00.0 Host bridge: Intel Corporation 82810E GMCH [Graphics Memory Controller Hub] (rev 03) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- This shows that Linux mapped the APIC (part of the processor). >It says nothing about mapping any IO APICs (unless you deleted >that part :). Oops, sorry -- misunderstood the meaning of the message. 8-P >So, how does one know if a (UP) system has an IO APIC and that >Linux can be configured to use the UP IO APIC code?... > >(That's a serious question: does an IO APIC show up in lspci output?) > >And why do you think that this system has an IO APIC? >Is it documented to have one? >[just digging for clues] There's no IO-APIC in the lspci output, but that's because it's integrated as part of the i810 chipset; it's probably hidden to keep people from tinkering with the settings -- there's not much one can do to modify an interrupt controller that wouldn't end badly 8=;-) (according to Intel's docs, the IO-APIC's carried somewhere on the 82801AA I/O Controller Hub, and I quote:) >From Intel's 82801AA I/O Controller Hub Datasheet >(http://developer.intel.com/design/chipsets/datashts/29065503.pdf): Features List: (page 3) ... - Interrupt Controller - Two cascaded 82C59 - Integrated IO-APIC capability - 15 Interrupt support in 8259 mode, 24 Interrupt support in IO-APIC mode ... 82801AA Simplified Block Diagram: (page 4) SERIRQ <---> | | PIRQ[A..D]# <--> | | IRQ[14..15] ---> | Interrupt |<--- APICCLK ---> | | APICD[1..0] <--> |___| 82801AA Datasheet Introduction: (page 25) Advanced Programmable Interrupt Controller (APIC) In addition to the standard ISA compatible interrupt controller (PIC) described in the previous section, the ICH incorporates the Advanced Programmable Interrupt Controller (APIC). While the standard interrupt controller is intended for use in a uni-processor system, APIC can be used in either a uni-processor or multi-processor system. Hope this clears up some confusion. -- Colin The CompNerd Network: http://www.compnerd.com/ Where a nerd can be a nerd. Get your free [EMAIL PROTECTED]! - 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/
page reserved twice
I'm curious if there is any significance to this, which occurs at each reboot on an SMP system running noapic (sometimes Netscape manages to produce a hard lockup on the system, sometimes a core dump indicates NS had signal 7, bus error, in cases where it doesn't lock the system), 2.4.6-pre1 with XFS patches: kernel: BIOS-provided physical RAM map: kernel: BIOS-e820: - 0009fc00 (usable) kernel: BIOS-e820: 0009fc00 - 000a (reserved) kernel: BIOS-e820: 000e - 0010 (reserved) kernel: BIOS-e820: 0010 - 0ffe (usable) kernel: BIOS-e820: 0ffe - 0fff8000 (ACPI data) kernel: BIOS-e820: 0fff8000 - 1000 (ACPI NVS) kernel: Scan SMP from c000 for 1024 bytes. kernel: Scan SMP from c009fc00 for 1024 bytes. kernel: Scan SMP from c00f for 65536 bytes. kernel: found SMP MP-table at 000faf50 kernel: hm, page 000fa000 reserved twice. kernel: hm, page 000fb000 reserved twice. kernel: hm, page 000f4000 reserved twice. thanteros kernel: hm, page 000f5000 reserved twice. thanteros kernel: On node 0 totalpages: 65504 thanteros kernel: zone(0): 4096 pages. kernel: zone(1): 61408 pages. kernel: zone(2): 0 pages. kernel: Intel MultiProcessor Specification v1.1 kernel: Virtual Wire compatibility mode. kernel: OEM ID: _AMI_Product ID: 840_CARMEL__ APIC at: 0xFEE0 Very similar messages seem to occur on a different machine with RH's 2.4.2 kernel, BX chipset, and IO-APIC enabled. The machine this is from has had this message on earlier kernels as well, none of which had XFS patches. What is the significance (or consequence) of pages reserved twice? D. Stimits, [EMAIL PROTECTED] - 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: 2.4.5 keyspan driver
In the hopes that it might prove helpful, I reran coldsync after loading usbserial.o and keyspan.o with the "debug=1" option. Here's what was logged: - - Jul 3 19:10:45 glitch kernel: usbserial.c: USB Serial support registered for Generic Jul 3 19:10:45 glitch kernel: usb.c: registered new driver serial Jul 3 19:10:45 glitch kernel: usbserial.c: none matched Jul 3 19:10:45 glitch kernel: usbserial.c: v1.0.0 Greg Kroah-Hartman, [EMAIL PROTECTED], http://www.kroah.com/linux-usb/ Jul 3 19:10:45 glitch kernel: usbserial.c: USB Serial Driver Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA18X - (without firmware) Jul 3 19:10:51 glitch kernel: usbserial.c: none matched Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA19 - (without firmware) Jul 3 19:10:51 glitch kernel: usbserial.c: none matched Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA19W - (without firmware) Jul 3 19:10:51 glitch kernel: usbserial.c: none matched Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA28 - (without firmware) Jul 3 19:10:51 glitch kernel: usbserial.c: none matched Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA28X - (without firmware) Jul 3 19:10:51 glitch kernel: usbserial.c: none matched Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA49W - (without firmware) Jul 3 19:10:51 glitch kernel: usbserial.c: none matched Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA18X Jul 3 19:10:51 glitch kernel: usbserial.c: none matched Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA19 Jul 3 19:10:51 glitch kernel: usbserial.c: descriptor matches Jul 3 19:10:51 glitch kernel: usbserial.c: found bulk out Jul 3 19:10:51 glitch last message repeated 2 times Jul 3 19:10:51 glitch kernel: usbserial.c: found bulk in Jul 3 19:10:51 glitch last message repeated 3 times Jul 3 19:10:51 glitch kernel: usbserial.c: Keyspan USA19 converter detected Jul 3 19:10:51 glitch kernel: usbserial.c: get_free_serial 1 Jul 3 19:10:51 glitch kernel: usbserial.c: get_free_serial - minor base = 0 Jul 3 19:10:51 glitch kernel: usbserial.c: usb_serial_probe - setting up 4 port structures for this device Jul 3 19:10:51 glitch kernel: usbserial.c: Keyspan USA19 converter now attached to ttyUSB0 (or usb/tts/0 for devfs) Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA19W Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA28 Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA28X Jul 3 19:10:51 glitch kernel: usbserial.c: USB Serial support registered for Keyspan USA49W Jul 3 19:10:51 glitch kernel: keyspan.c: v1.0.0 Hugh Blemings <[EMAIL PROTECTED]> Jul 3 19:10:51 glitch kernel: keyspan.c: Keyspan USB to Serial Converter Driver Jul 3 19:10:56 glitch kernel: usbserial.c: serial_open Jul 3 19:10:56 glitch kernel: keyspan.c: keyspan_usa19_calc_baud 9600 ff b2. Jul 3 19:10:56 glitch kernel: usbserial.c: serial_ioctl - port 0, cmd 0x5401 Jul 3 19:10:56 glitch kernel: usbserial.c: serial_ioctl - port 0, cmd 0x5402 Jul 3 19:10:56 glitch kernel: usbserial.c: serial_set_termios - port 0 Jul 3 19:10:56 glitch kernel: keyspan.c: keyspan_usa19_calc_baud 9600 ff b2. Jul 3 19:10:56 glitch kernel: usbserial.c: serial_ioctl - port 0, cmd 0x5401 Jul 3 19:10:56 glitch kernel: usbserial.c: serial_ioctl - port 0, cmd 0x5401 Jul 3 19:10:56 glitch kernel: usbserial.c: serial_ioctl - port 0, cmd 0x5402 Jul 3 19:10:56 glitch kernel: usbserial.c: serial_set_termios - port 0 Jul 3 19:10:56 glitch kernel: keyspan.c: keyspan_usa19_calc_baud 9600 ff b2. Jul 3 19:10:56 glitch kernel: usbserial.c: serial_ioctl - port 0, cmd 0x5401 Jul 3 19:11:00 glitch kernel: usbserial.c: serial_write - port 0, 16 byte(s) Jul 3 19:11:00 glitch kernel: usbserial.c: serial_write - port 0, 26 byte(s) Jul 3 19:11:00 glitch kernel: usbserial.c: port_softint - port 0 Jul 3 19:11:02 glitch kernel: usbserial.c: serial_write - port 0, 26 byte(s) Jul 3 19:11:02 glitch kernel: usbserial.c: port_softint - port 0 Jul 3 19:11:04 glitch kernel: usbserial.c: serial_write - port 0, 26 byte(s) Jul 3 19:11:04 glitch kernel: usbserial.c: port_softint - port 0 Jul 3 19:11:04 glitch kernel: usbserial.c: serial_ioctl - port 0, cmd 0x5401 Jul 3 19:11:04 glitch kernel: usbserial.c: serial_ioctl - port 0, cmd 0x5402 Jul 3 19:11:04 glitch kernel: usbserial.c: serial_set_termios - port 0 Jul 3 19:11:04 glitch kernel: keyspan.c: keyspan_usa19_calc_baud 9600 ff b2. Jul 3 19:11:04 glitch kernel: usbserial.c: serial_ioctl - port 0, cmd 0x5401 Jul 3 19:11:04 glitch kernel: usbserial.c: serial_write - port 0, 18 byte(s) Jul 3 19:11:04
Re: Ideas for TUX2
On Tue, 3 Jul 2001, Ph. Marek wrote: > If a file's data has been changed, it suffices to update the inode and the > of free blocks bitmap (fbb). > But updating them in one go is not possible You seem to have missed some fundamental understanding of exactly how phase tree works; the wohle point of phase tree is to make atomic updates like this possible! Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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/
RPC: rpciod waiting on sync task!
Hi,
I modified the linux NFS client, kernel 2.4.5 and 2.4.6-pre7, to send
an extra SETATTR, with special values, within nfs_open and nfs_release
so that I would be able to track file open and close. For the server I
am using a slightly modified linux user level nfs server.
What I noticed is that after this change I get:
RPC: rpciod waiting on sync task!
coming from the kernel under heavy read load, especially with
larger chunks of data 8k, 16, and 64k.
The code introduced into nfs_open and nfs_release is:
memset( , 0, sizeof(struct nfs_fattr) );
memset( , 0, sizeof(struct iattr) );
attr.ia_valid = ATTR_MODE | ATTR_UID | ATTR_GID | ATTR_SIZE;
attr.ia_mode = inode->i_mode;
attr.ia_uid = -10;
attr.ia_gid = -10;
attr.ia_size = -10;
attr.ia_atime = -1;
attr.ia_mtime = -1;
attr.ia_ctime = -1;
attr.ia_attr_flags = -1;
error = NFS_PROTO(inode)->setattr(inode, , );
if ( error ) {
printk( "nfs_network_openclose: error=%d\n", error );
}
Does anybody see any problems with this code? The unmodified nfs client
works fine with the unmodified nfs server.
Thanks
ttyl
Dima
--
Dima Brodsky [EMAIL PROTECTED]
http://www.cs.ubc.ca/~dima
201-2366 Main Mall (604) 822-6179 (Office)
Department of Computer Science (604) 822-2895 (DSG Lab)
University of British Columbia, Canada (604) 822-5485 (FAX)
Computers are like Old Testament gods; lots of rules and no mercy.
(Joseph Campbell)
-
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/
[PATCH] small patch to ide-tape.c
Hello all,
This patch adds a missing semicolon that is noticed only if you define
IDETAPE_DEBUG_LOG_VERBOSE:
John Guthrie
[EMAIL PROTECTED]
--CUT HERE-
--- ide-tape.c.orig Tue Jul 3 18:20:22 2001
+++ ide-tape.c Tue Jul 3 18:22:41 2001
@@ -1409,7 +1409,7 @@
case IDETAPE_WRITE_FILEMARK_CMD:return("WRITE_FILEMARK_CMD");
case IDETAPE_SPACE_CMD: return("SPACE_CMD");
case IDETAPE_INQUIRY_CMD: return("INQUIRY_CMD");
- case IDETAPE_ERASE_CMD: return("ERASE_CMD")
+ case IDETAPE_ERASE_CMD: return("ERASE_CMD");
case IDETAPE_MODE_SENSE_CMD:return("MODE_SENSE_CMD");
case IDETAPE_MODE_SELECT_CMD: return("MODE_SELECT_CMD");
case IDETAPE_LOAD_UNLOAD_CMD: return("LOAD_UNLOAD_CMD");
-
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: Sticky IO-APIC problem
Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > This shows that Linux mapped the APIC (part of the processor). > It says nothing about mapping any IO APICs (unless you deleted > that part :). > Correct. Linux always enables the APIC, but it needs some bios tables for the IO APIC. And the IO APIC is not present on all uniprocessor motherboards. > So, how does one know if a (UP) system has an IO APIC and that > Linux can be configured to use the UP IO APIC code?... Figure out which ICH is used (lspci?), then check Intel's documentation. But even if an io apic is present, Linux can only use it if a MP table is present. Afaik ACPI tables are not yet supported on i386, but ia64 already supports detecting the IO APIC's based on ACPI tables. -- Manfred - 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/
USB printing == kernel lockup?
Hello, I'm still looking into this, but has anybody else seen this problem? When I do anything (print to it, query its ink levels with escputil, etc.) with my Epson 870 while it's hooked to my computer via USB, the whole machine locks hard. If I change the connection over to a printer cable on a parallel port connection, eveything works fine. USB printing used to work fine until recently. (I don't print much, so how recently, I don't know yet.) I'm in the process of trying other kernels (tested 2.4.5 and 2.4.6-pre[68]) and USB controllers (JE's UHCI vs the standard UHCI) but I'm not done yet. Has anyone else has seen this problem? I posted to the gimp-print and linux-usb lists, but there was nary a response. The printer is connected to the USB hub in my Nokia monitor, which also has a mouse connected to it and that's running fine. I'm using a Tyan Tiger 133 mother board (VIA Apollo Pro 133A chipset) and SMP-enabled kernel. Thanks, pete - 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/
SCHED_FIFO task blocks magic sysrq
It seems like the sysrq code can get starved by a SCHED_FIFO task. I learned this by having an accidentally runaway SCHED_FIFO task which locked up my system. No SAK, no sync, no unmount, no reboot. Big Red Button. David -- David Mansfield (718) 963-2020 [EMAIL PROTECTED] Ultramaster Group, LLC www.ultramaster.com - 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: ACPI fundamental locking problems
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > BTW of course ACPI can be turned off via make menuconfig. > > Can you point me to the name of the option? I can't find it on my IA64 ACPI is required for IA64 to boot, so you can't disable it AFAIK. Sorry, I should have included that caveat in my previous message. -- Andy - 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: Sticky IO-APIC problem
Colin Bayer scribed: | I have a Pentium III 933/133 (Coppermine, stepping 6) in an Intel-manufactured | i810 motherboard (hey, I What mobo (model/name) is it? Can you give us the output from "lspci -vv"? | know it's a lame chipset, but it was on sale). On boot, the kernel (version | 2.4.6-pre8) identifies and maps the | IO-APIC onboard, but does not assign any IRQs to it. | | The relevant boot log snippet follows. | | [root@fortytwo i386]# cat /var/log/dmesg | ... | ... | mapped APIC to e000 (0121c000) This shows that Linux mapped the APIC (part of the processor). It says nothing about mapping any IO APICs (unless you deleted that part :). So, how does one know if a (UP) system has an IO APIC and that Linux can be configured to use the UP IO APIC code?... (That's a serious question: does an IO APIC show up in lspci output?) And why do you think that this system has an IO APIC? Is it documented to have one? [just digging for clues] | Kernel command line: auto BOOT_IMAGE=linux-test ro root=307 | BOOT_FILE=/boot/vmlinuz-2.4.6-pre8 | devfs=mount pirq=9,4 | PIRQ redirection, working around broken MP-BIOS. | ... PIRQ0 -> IRQ 9 | ... PIRQ1 -> IRQ 4 | ... | ... | | And /proc/interrupts: | [root@fortytwo i386]# cat /proc/interrupts |CPU0 | 0: 79409 XT-PIC timer | 1: 5911 XT-PIC keyboard | 2: 0 XT-PIC cascade | 4: 990 XT-PIC es1371 | 8: 1 XT-PIC rtc | 9: 26402 XT-PIC usb-uhci, serial | 11: 16473 XT-PIC i810@PCI:0:1:0 | 14: 5152 XT-PIC ide0 | 15: 47 XT-PIC ide1 | NMI: 0 | ERR: 0 | MIS: 0 | [root@fortytwo i386]# | | This problem also occurs when booting without the pirq switch. I've configured | everything the way it's | mentioned in Documentation/i386/IO-APIC.txt, but it doesn't help. Anyway, thx in | advance for the help. ~Randy - 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/
[PATCH] 2.4.5 i810_audio.c, ac97_codec.c
Hello,
Attached is a patch to the above files. Here's what they do:
1. ac97_codec.c, allow ad1886 to be recognized and brought up
properly, and sets S/PDIF rate to the 48 kHz rate prescribed by
ac97 2.2 spec.
Reference for this is in...
http://www.alsa-project.org/alsa/ftp/manuals/ad/AD1886.pdf
(page 20)
and
ftp://download.intel.com/ial/scalableplatforms/ac97r22.pdf
(page 62)
Perhaps someone (Ollie?) would prefer that these changes apply to
other ac97 codecs, since the ac97r22.pdf spec says that SPDIF bit
in register 2A shall be 0 when modifying register 3A -- thus this
is not unique to ad1886?
2. i810_audio.c, turn S/PDIF *on* when bringing up the codec; also
added comments to explain what [some of] the bits do.
Descriptions of the bits are [supposed to be] in the above PDF
files: p.19 of the AD1886.pdf, p.59 of ac97r22.pdf
There are some other bits whose function I don't understand; I
didn't alter them, but inserted comments.
Perhaps someone (Zach, Jaroslav, Alan, ...?) would prefer to look
more closely at the bits being set in AC97_EXTENDED_STATUS... i.e.,
the 0x8000 bit, which is not described in the ac97 2.2 spec as
other than 'x', why we turn on PRL, PRK, and PRI but have PRJ
turned off (indeed, with PRL=1, the mic adc is off, so why turn on
VRM?), etc. I don't know what most of these bits are, but as I
mentioned just modify the bit[s] that I know I need set.
These patches were tested under 2.4.4 (neither file has changed much
from 2.4.4 to 2.4.5 and indeed a 2.4.4 patch goes cleanly onto 2.4.5).
Comments, corrections, suggestions? In case TAB characters get
trashed by the mail system, these patches will also be available, for
a while anyway, at
http://www.sonic.net/~cpark/245-sound-drivers.patch
cut here ---
diff -ru linux-2.4.5-stock/drivers/sound/ac97_codec.c
linux-2.4.5_patched/drivers/sound/ac97_codec.c
--- linux-2.4.5-stock/drivers/sound/ac97_codec.cThu Apr 19 22:58:20 2001
+++ linux-2.4.5_patched/drivers/sound/ac97_codec.c Tue Jul 3 11:40:51 2001
@@ -66,6 +66,8 @@
static int sigmatel_9721_init(struct ac97_codec *codec);
static int sigmatel_9744_init(struct ac97_codec *codec);
static int enable_eapd(struct ac97_codec *codec);
+static int setup_ad1886(struct ac97_codec *codec);
+
/* sorted by vendor/device id */
static const struct {
@@ -77,6 +79,7 @@
{0x41445340, "Analog Devices AD1881", NULL},
{0x41445348, "Analog Devices AD1881A", NULL},
{0x41445460, "Analog Devices AD1885", enable_eapd},
+ {0x41445361, "Analog Devices AD1886" , setup_ad1886},
{0x414B4D00, "Asahi Kasei AK4540", NULL},
{0x414B4D01, "Asahi Kasei AK4542", NULL},
{0x414B4D02, "Asahi Kasei AK4543", NULL},
@@ -852,6 +855,22 @@
codec->codec_write(codec, AC97_POWER_CONTROL,
codec->codec_read(codec, AC97_POWER_CONTROL)|0x8000);
return 0;
+}
+
+/*
+ * Bring up an AD1886
+ */
+
+static int setup_ad1886(struct ac97_codec * codec)
+{
+/* The spec says not to mess with other bits unless
+ S/PDIF is turned *off* in reg 2A */
+codec->codec_write(codec, AC97_EXTENDED_STATUS, 0);
+
+/* The 1886 spec dated 08/25/00 says default value=0
+ but ac97 2.2 says it should be 0x2000. */
+codec->codec_write(codec, AC97_RESERVED_3A, 0x2000); /* 48 kHz */
+return 0;
}
diff -ru linux-2.4.5-stock/drivers/sound/i810_audio.c
linux-2.4.5_patched/drivers/sound/i810_audio.c
--- linux-2.4.5-stock/drivers/sound/i810_audio.cSat May 19 17:43:07 2001
+++ linux-2.4.5_patched/drivers/sound/i810_audio.c Tue Jul 3 11:40:51 2001
@@ -2001,8 +2001,12 @@
printk(KERN_WARNING "i810_audio: only 48Khz playback
available.\n");
else
{
- /* Enable variable rate mode */
- i810_ac97_set(codec, AC97_EXTENDED_STATUS, 9);
+ /* Turn on VRA, VRM (enable variable rate mode), turn off DRA.
+ Turn on SPDIF, set source data to AC-link slots 3&4.
+ (see AC'97 component specification rev 2.2 from intel) */
+ i810_ac97_set(codec, AC97_EXTENDED_STATUS, 0xD);
+/* ac'97 2.2 doesn't say what the 0x8000 bit is, but 0x6800
+ bits turn PCM center DAC, PCM LFE DACs, and MIC ADC all
+off */
i810_ac97_set(codec,AC97_EXTENDED_STATUS,
i810_ac97_get(codec, AC97_EXTENDED_STATUS)|0xE800);
cut here ---
--
Neither I nor my employer will accept any liability for any problems
or consequential loss caused by relying on this information. Sorry.
Collin Park Not a
Re: ACPI fundamental locking problems
In article <[EMAIL PROTECTED]> you wrote: >> walking into their top secret menwith hill base playing the >> mission impossible >> theme tune then chaining themselves to things.. > You're kidding.right? > BTW of course ACPI can be turned off via make menuconfig. Can you point me to the name of the option? I can't find it on my IA64 - 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: ACPI fundamental locking problems
> This goes to the special nature of the Global Lock. If we cannot acquire it, > we set a bit, and the system interrupts when it is released. Please see > acpi_ev_acquire_global_lock(). Gotcha..now I follow - I read it as acquire or spin not acquire or fail > > if you make a callback from the ACPI code - eg power > > management that itself > > needs to call AML code ? > > All we do at interrupt level is signal the semaphore that threads needing > the GL have blocked on. They continue execution at non-interrupt level. Obvious question - you call kmalloc with that lock held - that can sleep as it is GFP_KERNEL so other threads can run and make acpi calls .. I assume the other threads block on the acpi lock, and the kmalloc eventually returns. > > Microsoft very early on in debugging Win2K problems ask > > people to use non > > ACPI settings. > > What is your source for this? They certainly could have said that, but > everything I've heard is that MS was so committed to ACPI, they almost left > APM support out of W2K. Microsoft helpdesk engineers I know (contrary to assumptions from some quarters there is a lot of respect between some of the MS and linux folks for each others work) > 3) ACPI increases visibility of vendor code. You can disassemble AML. You > can step through it with our debugger. Well actually the license on the intel bios says not. Of course the license is invalid here but nevertheless.. > > Governments. They'd hate the US to get prior warning of say protestors > > walking into their top secret menwith hill base playing the > > mission impossible > > theme tune then chaining themselves to things.. > > You're kidding.right? No. There are people more paranoid than I care to consider sane. They have lots of money. There are also a bunch of greenpeace people who today walked straight into a US top secret base in the UK singing the mission impossible theme tune .. which did you doubt ? [Come to think of it which do you find the more improbable ..] Alan - 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: ACPI fundamental locking problems
Some of this discussion's getting a little X-Files-y. However, there are some points I'd like to touch on... > From: Alan Cox [mailto:[EMAIL PROTECTED]] > Well lets take a look at the asm shall we > 1.It doesnt have a seperate loop when it fails to take the lock > polling it (See intels own docs on spin locks). You do read your > own publications ? This goes to the special nature of the Global Lock. If we cannot acquire it, we set a bit, and the system interrupts when it is released. Please see acpi_ev_acquire_global_lock(). > 2.It should be using rep nop (See your own Intel PIV > publications) > 3.Should be asm __volatile__ or gcc can move it You are most likely right about all this stuff. Haven't had the need to fix it because it's been working fine. Patches accepted. > I am also somewhat puzzled about contexts here. What happens > if you take > an IRQ during the global lock acquire and want to do ACPI. > What happens > if you make a callback from the ACPI code - eg power > management that itself > needs to call AML code ? All we do at interrupt level is signal the semaphore that threads needing the GL have blocked on. They continue execution at non-interrupt level. > I am assuming the ACPI stuff has no IRQ level execution > ability, but are you > sure ACPI never calls a single code path that can require an > ACPI operation > from a callback - eg the PM layer ? Otherwise how can you be > sure there won't > be any priority inversions between the bios/acpi locking set > and the kernel > locking set We're aware of this issue and have coded accordingly. We have run into these issues (specifically with the Embedded Controller driver) and we fix them when they crop up. > Microsoft very early on in debugging Win2K problems ask > people to use non > ACPI settings. What is your source for this? They certainly could have said that, but everything I've heard is that MS was so committed to ACPI, they almost left APM support out of W2K. > > Jeff Garzik: > > The difference with ACPI is that vendors can write code > that is executed > > in the kernel's context (instead of what you can consider the BIOS's > > context). That is a whole new can of worms. (I know I'm replying to Jeff's point in your email, sorry) 1) Vendors can write code that is *interpreted* by the OS. 2) If vendors write a malicious BIOS, it's game over even without ACPI 3) ACPI increases visibility of vendor code. You can disassemble AML. You can step through it with our debugger. > For security reasons alone we need to ensure ACPI can be > firmly in the off > position. Executing US written binary code in the Linux > kernel will not be > acceptable to european corporations, non US military bodies and most > Governments. They'd hate the US to get prior warning of say protestors > walking into their top secret menwith hill base playing the > mission impossible > theme tune then chaining themselves to things.. You're kidding.right? BTW of course ACPI can be turned off via make menuconfig. > And we have customers who pointedly don't talk to the BIOS > and kill SMI/SMM > early on... And from what I understand, Itanium doesn't necessarily have a Global Lock either. Great, no problem. However, we still need to handle machines that do. Regards -- Andy PS Have I read *all* the Intel pubs? Cover to cover? Um, no. ;-) - 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: O_DIRECT! or O_DIRECT?
At 21:34 03/07/2001, Samium Gromoff wrote: [snip] >One more problem i see here, and i think it is an > *extremely* important one, that making open( ... , > BLA_BLA_BLA | O_DIRECT) is a thing some people may > overspeculate with. I mean that implementing O_DIRECT > in cp(1), wins the prize, but in the case of, say, Why should it? It is very well possible that the file(s) being copied have been accessed beforehand and hence are already in the page/buffer cache. Using O_DIRECT would not only completely bypass the page/buffer cache but it would also cause the cache to be flushed (if dirty) and the cache buffers/pages invalidated (otherwise you lose coherency). This is going to be _slower_ than not using O_DIRECT. > find(1) it is definitely not a wise move. The problem > may be determined as "poisoning" software with this > godblessed O_DIRECT, to the state, when 70% of code > on an average machine will use it, thus *completely* > killing the advantages of buffered access, and > suddenly *bang!*: the overall performance is died. Er. Using O_DIRECT means you are doing _unbuffered_ access. - Maybe I am misunderstanding your comments, but is seems to me you have the whole concept of O_DIRECT the wrong way round. >But the worst thing, is what the process of > poisoning is completely uncontrollable: each > stupid doodie can think, that His shitful piece of Code, > is Especially Important, ant that in his case O_DIRECT > is perfectly suitable. And in the case His code is > someway performance critical, then most likely O_DIRECT > will really improve his Code benchmarks, and that is > making things really awful, leading to the hell large > crowd of pig happy dudes thinking their useless code > is life critical, and thus dooming linux. O_DIRECT _decreases_ performance drastically in most cases. So nobody in their right mind would use it for normal applications. - The people who would use it and would actually experience a speed _increase_ would be programmers of large databases which perform their own caching in user space (thus making the normal fs level caching unnecessary, and in fact, worse than the unbuffered case) and programmers of multi media streaming applications (e.g. video/audio streaming including DVD playback[1] for example) which know that A) the data is not in the cache and B) the data will never be accessed again in the near future so caching the data is not only pointless but causes actually useful (other, unrelated) data present in the cache to be displaced out of the cache. >Maybe i`m stupid, as these potential dudes, and > painting things in too dark colors, but O_DIRECT, > i think, is a dangerous thing to play with. It is indeed. It is only useful in very special circumstances as described above. Using it in "normal" applications is stupid and will lead to degradation of performance of the application using it. >Maybe i`m missing the whole point, and thus i want to > hear what other people will tell about it. I think you do... I hope I managed to explain what O_DIRECT actually is above. Shame you didn't attend the Linux Developers Conference (in Manchester) last weekend as Andrea Arcangeli gave a very nice talk explaining O_DIRECT in depth. Best regards, Anton [1] Actually DVD players make use or raw i/o to access the DVD disk device as a whole, thus bypassing file system code altogether, which is even faster, but if you were to copy a DVD to your hard drive than O_DIRECT would give you the described benefits. -- "Nothing succeeds like success." - Alexandre Dumas -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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 port O_SYNC functionality in 2.4.5
On Tue, Jul 03, 2001 at 04:42:00PM -0400, Stuart MacDonald wrote: > Best way to get this in the serial driver is to do some patches for it > and send them to Ted. :-) Please copy them to me as well. The ARM tree has a core uart driver in currently which handles several different types of serial ports. Thanks. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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/
Linux 2.4.5-ac24
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org 2.4.5-ac24 o Serverworks AGP support (Jeff Hartmann) o Split I/O requests on pdcraid/hptraid when (Arjan van de Ven) they cross stride o Fix hangs on TI1410 cardbus bridge (Erik Mouw) o Update Configure.help (Eric Raymond) o Fix bug in ext2_new_inode (Al Viro) o Fix double pci_set_power_state stub (Jeff Garzik) o Fix mcheck_disable (Andrew Morton) o Merge 2.4.6-pre9 - Ignored ATI changes versus old atyfb codebase - Remove several totally broken drivers/net/Config.in changes o Update act2000 isdn driver (Kai Germaschewski) o Fix ELOOP handling bug (Al Viro) 2.4.5-ac23 o Merge with 2.4.6pre8 | This should make things much more stable o Restore backed out shm patches (Christoph Rohland) o Fix quotaoff crash (Jan Kara) o Move stuff into BSS on decnet (Xavier Bestel) o Update ims twinturbo fb maintainer (Paul Mundt) o Update Crutcher Dunnavant's email address (Crutcher Dunnavant) o UML ^S/^Q support for the console and serial(Livio Soares) o code cleanups in UML drivers(Jeff Dike) o UML include and #define cleanups(Niels Kristian Bech Jensen) o UML ubd driver defines blk_size correctly (Roman Zippel) o which allowed clean up of related ubd code (Jeff Dike) o tweak the UML definition is a fixable seg fault (Jeff Dike) o fix the UML TASK_UNINTERRUPTIBLE deadlock (Jeff Dike) o Update ldconfig scripts for multiple rodata (Jakub Jelinek) o Small isdn.h fixes (Kai Germaschewski) o Add Advantech TurboPAM isdn (Stelian Pop) o Maxine frame buffer cleanups(Paul Mundt) o UDF cleanup (Arnaldo Carvalho de Melo) o Fix jffs2 includes (Keith Owens) o Small cleanups to vt.c (Arnaldo Carvalho de Melo) o Clean up istallion driver (Arnaldo Carvalho de Melo) o Clean up sh-sci driver (Arnaldo Carvalho de Melo) o Clean up selection (Arnaldo Carvalho de Melo) o Small random driver cleanups(Arnaldo Carvalho de Melo) o Small tty_io cleanup(Arnaldo Carvalho de Melo) o Small isdn_tty cleanup (Arnaldo Carvalho de Melo) o Expose scsi_add/del_timer for hosts to adjust timeouts when they know better(Matthew Jacob) o Remove unneeded init of data(Xavier Bestel) o Remove unneeded init of data in wavfront(Xavier Bestel) o Remove unneeded init of data in sb (Xavier Bestel) o Remove unneeded init of data in nm256 (Xavier Bestel) o Remove unneeded init of data in oss sound (Xavier Bestel) o Remove unneeded init of data in cs4232 (Xavier Bestel) o Remove unneeded init of data in ultrastor (Xavier Bestel) o Remove unneeded init of data in scsi/hosts.c(Xavier Bestel) o Remove unneeded init of data in i2o_core(Xavier Bestel) o Fix strange fs/exec.c error return (Andrew Morton) o Remove unneeded init of data in mcd (Xavier Bestel) o Clean up belkin_sa ioctl code (Arnaldo Carvalho de Melo) o Clean up ftdi_sio ioctl code(Arnaldo Carvalho de Melo) o Clean up mct_u232 ioctl code(Arnaldo Carvalho de Melo) o Tidy ircomm_tty_ioctl (Arnaldo Carvalho de Melo) o Work around cypress cy723c693 RTC stability bug (Ivan Kokshaysky) o Clean up autofs user access slightly(Arnaldo Carvalho de Melo) o Small fs/exec.c clean ups (Arnaldo Carvalho de Melo) o Fix eepro100 oops with power management (Marc Boucher) 2.4.5-ac22 o Fix the remaining make xconfig mess (me) o Add APM disabling on DMI match (me) | Needed for the Trigem Delhi3 (aka E Machines E-Tower 333cs) o Fix pnpbios without hotplug (I hope)(me) o Merge an escaped via midi fixup (Adrian Cox) o Revert minixfs changes 2.4.5-ac21 o Fix pnpbios compile failure and add docking (me) station hotplug (/sbin/hotplug dock) o Fix make xconfig failure(Keith Owens) o Fix cciss pci device table
[PATCH] ppp_generic.c - kfree(ppp) called twice, kernel 2.4.0
Hi,
In ppp_destroy_interface(), there is a chance that kfree(ppp) is called
twice, causing a kernel oops when ppp is opened again. I was able to cause
this by running PPPOE, and killing -9 pppd and pppoe-daemon with one kill
command. By doing this, the closing of ppp->dev causes a
ppp_disconnect_channel(), which calls kfree(ppp) assuming the ppp unit is
dead. But destroy_interface() hasn't finished, and it tries to kfree(ppp)
also. I simply moved the closing of the device to after the channels == 0
check. Anyways, follows is the patch. Please cc comments to
[EMAIL PROTECTED]
thanks,
Eli Chen
--- ppp_generic.c 2001/02/21 00:53:01 1.1.1.2
+++ ppp_generic.c 2001/07/03 20:37:22
@@ -2268,13 +2268,6 @@
ppp->dev = 0;
ppp_unlock(ppp);
- if (dev) {
- rtnl_lock();
- dev_close(dev);
- unregister_netdevice(dev);
- rtnl_unlock();
- }
-
/*
* We can't acquire any new channels (since we have the
* all_ppp_lock) so if n_channels is 0, we can free the
@@ -2283,6 +2276,13 @@
*/
if (ppp->n_channels == 0)
kfree(ppp);
+
+ if (dev) {
+ rtnl_lock();
+ dev_close(dev);
+ unregister_netdevice(dev);
+ rtnl_unlock();
+ }
spin_unlock(_ppp_lock);
}
-
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/
2.2.19 kernel hang
Summary: Kernel 2.2.19 hang [stuck on TLB IPI wait (CPU#0)] Description: After recently upgrading the kernel on a production server to kernel 2.2.19 with the reiserfs patch and kernel-patch-2.2.19-ide from Andre Hendrick, the system became hung. The server was responsive to ping but ssh and http service stopped working until we rebooted. The hang did not happen instantly, but took several days of uptime before the system hung. Looking through the logs we noticed that "stuck on TLB IPI wait (CPU#0) was logged 128 times in one second. Also during that second, 4443 packets were rejected by the kernel coming in on eth0, of which 2681 were aimed at port 137. These packets came from 60 addresses not on our local network (packets destined to 137 on our local network are rejected, but not logged). Of other note was this kernel message: "dst cache overflow" "last message repeated 9 times". Since this did not crash the machine, there is no oops output. We were running the mon package from 3 other servers during this time and noticed shortly after the hang that several services were failing (ssh, http, etc). Even ping failed a few times. Kernel Version: Linux version 2.2.19 (cjf@linux00) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 SMP Tue Jun 26 11:55:50 EDT 2001 Output from ver_linux: Linux www.fi.edu 2.2.19 #1 SMP Tue Jun 26 11:55:50 EDT 2001 i686 unknown Gnu C 2.95.2 Gnu make 3.79.1 binutils 2.9.5.0.37 util-linux 2.10f modutils 2.3.11 e2fsprogs 1.18 Linux C Library2.1.3 ldd: version 1.9.11 Procps 2.0.6 Net-tools 1.54 Console-tools 0.2.3 Sh-utils 2.0 Modules Loaded CPU Info: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 933.040 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 psn mmx fxsr xmm bogomips: 1854.66 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 933.040 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 psn mmx fxsr xmm bogomips: 1861.22 SCSI Info: Host: scsi0 Channel: 00 Id: 04 Lun: 00 Vendor: ARCHIVE Model: Python 04106-XXX Rev: 743B Type: Sequential-AccessANSI SCSI revision: 02 Interrupts (/proc/interrupts): CPU0 CPU1 0:56749385598011IO-APIC-edge timer 1: 1 1IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 0 1IO-APIC-edge rtc 10:18293101817099 IO-APIC-level Mylex DAC960PTL1, eth0 11: 18 18 IO-APIC-level aic7xxx 13: 1 0 XT-PIC fpu NMI: 0 ERR: 0 - 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: O_DIRECT! or O_DIRECT?
On Wed, 4 Jul 2001, Samium Gromoff wrote: > Maybe i`m missing the whole point, and thus i want to > hear what other people will tell about it. Several of us are working on it. -ben - 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 port O_SYNC functionality in 2.4.5
From: "James R Bruce" <[EMAIL PROTECTED]> > The overall size of the circular buffer would have to be decreased > too, but that's more of a hack to fix it now; Which I guess is what it > comes to. I see what you're saying; AFAIUnderstand, the low latency patches bypass the circular buffer. Or make it size one. > This is not really a problem; 16 bytes of hardware buffering I can > live with; at 19200 baud this is 7ms of lag. The 4096 byte software > buffer causes 1706ms of lag; That *is* a problem. It's a bit like the > difference between a hard disk drive's local buffer and the OS's (much > larger) buffering. O_SYNC on a disk garuntees that the output has > been flushed to the disk, but maybe not the physical medium. On a > serial port, similar functionality would be to have output to pushed > to the UART, but maybe not yet over the actual port. Gotchya. > The manpage seems to imply this would work, but it doesn't seem to > affect the software buffering at all (I tried this yesterday). AFAICT > from looking at the driver, the low_latency mode only applies to > reading, not writing: tty_flip_buffer_push(tty) is the only place the > latency flag is ever checked, and that is only called in receive_chars > in serial.c. The application that caused this doesn't get any serial > input whatsoever, so that won't (or at least shouldn't) get called. Hm. I haven't looked at the low_latency stuff, I was just repeating what I'd heard... > I changed WAKEUP_CHARS to 1 rather than 256 (0 would cause processes > to hang forever, btw), and SERIAL_XMIT_SIZE to 16 rather than > PAGE_SIZE. A proper solution would make this conditional on O_SYNC or > low_latency or even a kernel option. Suggestions? If you check the code, the circ buffer will never have a count < 0, so the hang is predictible; tty is never called for more tx chars. I'd say it should be part of low_latency. Although it's probably best to have rx low_latency and tx low_latency separately configurable. Honouring O_SYNC might not be a bad idea as well. Whatever option probably should make SERIAL_XMIT_SIZE == WAKEUP_CHARS; SERIAL needs to be a power of two, so 2, 4, 8 or 16 would be good choices. Probably should be similar to the rx low_latency. Best way to get this in the serial driver is to do some patches for it and send them to Ted. :-) ..Stu - 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/
O_DIRECT! or O_DIRECT?
HI folks, sometime ago i seen on lkml a post from >< regarding the implementation of O_DIRECT. The thing about to care, is the fact, that *nobody*, reacted on this post. It seems to me that nobody was happy enough about this to tell "oh yes! at last!" This is interesting, because one real advantage of O_DIRECT are these greased weasel fast 15-20 Mb/s file copies, which ones makes windoze users to look on us as on lesser beings. I understand, though, that this approach scales bad in the terms of multithread loads, which ones are especially important in server environments, the place linux initially growed from, and that is why it wasn`t already implemented. One more problem i see here, and i think it is an *extremely* important one, that making open( ... , BLA_BLA_BLA | O_DIRECT) is a thing some people may overspeculate with. I mean that implementing O_DIRECT in cp(1), wins the prize, but in the case of, say, find(1) it is definitely not a wise move. The problem may be determined as "poisoning" software with this godblessed O_DIRECT, to the state, when 70% of code on an average machine will use it, thus *completely* killing the advantages of buffered access, and suddenly *bang!*: the overall performance is died. But the worst thing, is what the process of poisoning is completely uncontrollable: each stupid doodie can think, that His shitful piece of Code, is Especially Important, ant that in his case O_DIRECT is perfectly suitable. And in the case His code is someway performance critical, then most likely O_DIRECT will really improve his Code benchmarks, and that is making things really awful, leading to the hell large crowd of pig happy dudes thinking their useless code is life critical, and thus dooming linux. Maybe i`m stupid, as these potential dudes, and painting things in too dark colors, but O_DIRECT, i think, is a dangerous thing to play with. That is why, i think, Linus as far as i can properly recall, wasn`t happy with it et al. Maybe i`m missing the whole point, and thus i want to hear what other people will tell about it. Cheers, Samium Gromoff - 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/
wait_event() problems
I have been trying to get the following to work:
atomic_t stop;
struct wait_queue wait_queue_stuff, another_wait_queue;
/* Initialized before use with init_wait_queue() */
kernel_thread()
{
for(;;)
{
if(atomic_read(stop))
interruptible_sleep_on(_queue_stuff);
do_regular_stuff();
}
}
ioctl_start()
{
if(waitqueue_active(_queue_stuff))
{
atomic_set(, 0);
wake_up_interruptible(_queue_stuff);
}
}
ioctl_stop()
{
if(!waitqueue_active(_queue_stuff))
{
atomic_set(, 1);
wait_event(another_wait_queue, waitqueue_active(_queue_stuff));
}
}
The problem is that when ioctl_stop() is executed, the kernel thread
never gets any CPU time so it remains stuck in "D" state forever.
Maybe I'm doing something wrong, but something seems to be broken.
The following patch 'fixes' it.
--- linux-2.4.1/include/linux/sched.h.orig Tue Jul 3 15:14:07 2001
+++ linux-2.4.1/include/linux/sched.h Tue Jul 3 15:16:27 2001
@@ -763,6 +763,7 @@
set_current_state(TASK_UNINTERRUPTIBLE);\
if (condition) \
break; \
+current->policy = SCHED_YIELD; \
schedule(); \
} \
current->state = TASK_RUNNING; \
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
-
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 port O_SYNC functionality in 2.4.5
Re: serial port O_SYNC func.. by "Stuart MacDonald"@conne > From: "James R Bruce" <[EMAIL PROTECTED]> > > As far as I can tell from observed operation and from perusing the > > code, O_SYNC doesn't seem to be supported by the serial driver in > > 2.4.5. Writes are forced as far as the serial.c's circular queue, but > > O_SYNC seems to be ignored from there on, so any application trying to > > do small synchronous writes to the serial port will end up backing it > > up PAGE_SIZE bytes rather than getting synchronous operation (which is > > incidentally what I was trying to do when I ran into this :). > > > > I'm unfamiliar with the serial driver so I'm not sure the right way to > > fix it is, but perhaps using a smaller value for WAKEUP_CHARS from > > drivers/char/serial.c when the port is opened with O_SYNC > > functionality might do the trick (i.e. 0 rather than 256). > > That might help, but it might not. That will only make sure that the > tx circular buffer is empty before getting another byte from the tty > layer into the buffer. The overall size of the circular buffer would have to be decreased too, but that's more of a hack to fix it now; Which I guess is what it comes to. > I think you will find that the real problem is that bytes written > into the hardware go into the fifo, and there's no general way to > tell when a byte has be actually txed; not in regular operation. This is not really a problem; 16 bytes of hardware buffering I can live with; at 19200 baud this is 7ms of lag. The 4096 byte software buffer causes 1706ms of lag; That *is* a problem. It's a bit like the difference between a hard disk drive's local buffer and the OS's (much larger) buffering. O_SYNC on a disk garuntees that the output has been flushed to the disk, but maybe not the physical medium. On a serial port, similar functionality would be to have output to pushed to the UART, but maybe not yet over the actual port. > You want to run the port in polled mode, which ensures one byte is > txed/rxed at a time. It's slow and cpu intensive though. setserial's > man page might have some info on this, also known as "low latency"; > meaning a specific byte has a low period of time between being rxed > and read/written and txed. The manpage seems to imply this would work, but it doesn't seem to affect the software buffering at all (I tried this yesterday). AFAICT from looking at the driver, the low_latency mode only applies to reading, not writing: tty_flip_buffer_push(tty) is the only place the latency flag is ever checked, and that is only called in receive_chars in serial.c. The application that caused this doesn't get any serial input whatsoever, so that won't (or at least shouldn't) get called. I changed WAKEUP_CHARS to 1 rather than 256 (0 would cause processes to hang forever, btw), and SERIAL_XMIT_SIZE to 16 rather than PAGE_SIZE. A proper solution would make this conditional on O_SYNC or low_latency or even a kernel option. Suggestions? - Jim Bruce - 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/
eCos
Does anyone on the list use eCos (RedHat's embedded Linux)? I'm having some build and other general problems, and I'd like to ask someone about them off-list. Thanks... - Matt - 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/
Linux HA FC based cluster
First of all my apologies: I know linux-kernel is not the better place to post that mail, but trust me: is a little emercency for us. We are (sigh... very urgently) looking for any available info about succesfully running HA clusters based on Redhat Linux 6.2 (two systems sharing a single storage device). Our (customer) requirement is to use Kimberlite on two HP LH6000r servers. Based on information found at oss.missioncriticallinux.com, we should evaluate a Qlogin QLA2200 host adapter. Does someone have recent success report? The customer owns an HP rack storage 12fc with HSSDC (copper) ports. Someone tryied that setup? What other storage can be used? Thanks a lot for any answer; please cc: also to me, I'm not subscribed. Best wishes, Gabriele Turchi P.S.: I'm sorry, my english is alpha version... -- Gabriele Turchi (Responsabile Tecnico)[EMAIL PROTECTED] Tieffe Sistemi S.r.l.www.tieffesistemi.com V.le Piceno 21 - 20129 Milano - Italia tel/fax +39 02 76115215 - 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: ACPI fundamental locking problems
Other ACPI problems, that come with the increased potential for malicious code: - Much easier for NSA to snoop machine activity undetected (hello paranoid people) - Much easier to write worms and virii and similar (it's much easier for someone malicious to patch an acpi table than bios binary code.) -- Jeff Garzik | "I respect faith, but doubt is Building 1024| what gives you an education." MandrakeSoft | -- Wilson Mizner - 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: ACPI fundamental locking problems
On Tue, 3 Jul 2001, Grover, Andrew wrote: > We're depending on vendors (aka the BIOS) for all the ACPI tables, as well > as every other piece of a priori data we need to boot the OS. And this is the part that I find terrifying. The minute we rely on BIOS vendors, they seem to find wonderful new ways to screw things up royally. > Could I please ask that you at least show me a system where this is a > problem before throwing out all the work we've done on ACPI because of this > technical nit? Currently, with what we extract from BIOS space, we can blacklist/whitelist according to DMI entries. With ACPI providing AML code that's executed in kernel space, there's no telling what could happen. The whole "black box, you don't need to know how this works, just call it" approach is scary. With ACPI having access to IDE taskfile commands, the possibilities for all sorts of evil exist. Just when we thought the CPRM nightmare was over, we have the BIOS feeding us IDE commands to throw at drives with vendors telling us "Trust it, it's ok, really." Maybe I'm overly paranoid, but I'm sure I'm not the only one who feels this way. regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - 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: ACPI fundamental locking problems
> > That is the case here. The Global Lock is for synchronizing accesses between > > the OS (that's us) and the firmware (SMI). Normal spinlocks are for intra-OS > > locking. Here, we're synchronizing access with the BIOS. It's different. > > I realize what the purpose of the global lock is... > > How is the asm code in ACPI_ACQUIRE_GLOBAL_LOCK specific to interaction > between OS and SMI? Well lets take a look at the asm shall we 1. It doesnt have a seperate loop when it fails to take the lock polling it (See intels own docs on spin locks). You do read your own publications ? 2. It should be using rep nop (See your own Intel PIV publications) 3. Should be asm __volatile__ or gcc can move it I am also somewhat puzzled about contexts here. What happens if you take an IRQ during the global lock acquire and want to do ACPI. What happens if you make a callback from the ACPI code - eg power management that itself needs to call AML code ? I am assuming the ACPI stuff has no IRQ level execution ability, but are you sure ACPI never calls a single code path that can require an ACPI operation from a callback - eg the PM layer ? Otherwise how can you be sure there won't be any priority inversions between the bios/acpi locking set and the kernel locking set > > All this code has been working for as long as I can remember. > > ;-) Under Windows? Irrelevant. Linux uses the hardware totally Microsoft very early on in debugging Win2K problems ask people to use non ACPI settings. > The difference with ACPI is that vendors can write code that is executed > in the kernel's context (instead of what you can consider the BIOS's > context). That is a whole new can of worms. For security reasons alone we need to ensure ACPI can be firmly in the off position. Executing US written binary code in the Linux kernel will not be acceptable to european corporations, non US military bodies and most Governments. They'd hate the US to get prior warning of say protestors walking into their top secret menwith hill base playing the mission impossible theme tune then chaining themselves to things.. And if the NSA wants the US goverment to execute binary only chinese bios code on all their critical systems I am sure people will be happy. > Look at the Linux boot sequence, which Randy Dunlap documented. We > collect as much information as is reasonable from BIOS at startup, so we > won't have to talk to it again at runtime. And we have customers who pointedly don't talk to the BIOS and kill SMI/SMM early on... - 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: Kernel Module tracing.
On Friday 29 June 2001 23:37, Tom spaziani wrote: > I've recently been laboring over a kernel module that allows other > kernel modules to send messages > and tracing statements. If anyone has any input on whether this would > be a usefull thing or not > please let me know. Here is a quick breakdown on how it works. > > Beware, this is only a BRIEF explaination.. I'll follow up with more > details if anyone is intereasted. > > trace.o <- Tracing module > mymodule .o <- Client module > > 1: Load tracing module > 2: Load a module that uses the tracing modules for reporting. > a. the client module requests a certain number of reporting levels. > b. the trace module creates a devFS entry for each of the requested > reporting levels. > ( /dev/trace/mymodule/mymodule0 > mymodule1 ... > ) > 3. Now the client module can send messages with a specific severity > rating and have it set > to the appropriate character file. > 4. User space programs listening on each of the character files can do > whatever, log the messages > or perform tasks depending on the message. > 5. When a client module is unloaded the devFS entries are removed and > the user programs are also > told to close the file. > > I am using the devFS filesystem because of the abilities to easily > dynamically create new entries and > remove them.. Currently devFS does not recycle Major and Minor numbers, > but a co-worker of mine > has created a patch to fix that. I want this. I've been thinking about it since your original post, and having just gone through a round of development involving massive amounts of kprint output (real time performance monitoring) I can say I'd prefer a more flexible way to do it, not to mention more efficient. I'd like to have the option of leaving tracing code in some of my development projects all the time, just disabled until I say the magic word, then have it routed to a device as you describe. Presumably you intend to use a ring buffer as printk does, simplified by the fact that you don't have to parse "level" information out of the string. This will all be a lot more useful if it works from interrupts etc. Perhaps you should also think about a non-devfs way of doing this, I don't know, it's a matter of taste. Here's a Rube Goldbergesque way: when the client registers, export a dynamically allocated major number through proc and let the user mknod a device with that major. Please cc me when you have something to try. -- Daniel - 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: ACPI fundamental locking problems
"Grover, Andrew" wrote: > > > From: Jeff Garzik [mailto:[EMAIL PROTECTED]] > > events/evxface.c:610:acpi_acquire_global_lock -> > > events/evmisc.c:337:acpi_ev_acquire_global_lock -> > > include/platform/acgcc.h:52:ACPI_ACQUIRE_GLOBAL_LOCK > > > > My immediate objections are, > > (a) acgcc.h is re-implementing spinlocks in a non-standard, > > non-portable, and expensive way, and (b) this entire code path is > > incredibly expensive. > > Well, when I look at other Linux code, I assume that if it does something > weird, it does it for a reason. > > That is the case here. The Global Lock is for synchronizing accesses between > the OS (that's us) and the firmware (SMI). Normal spinlocks are for intra-OS > locking. Here, we're synchronizing access with the BIOS. It's different. I realize what the purpose of the global lock is... How is the asm code in ACPI_ACQUIRE_GLOBAL_LOCK specific to interaction between OS and SMI? > All this code has been working for as long as I can remember. ;-) Under Windows? Irrelevant. Linux uses the hardware totally differently from Windows. Under Linux? You cannot come close to saying CONFIG_ACPI is used by a large number of users... I don't think that claim can really be made yet. > You mention twice that it is "expensive". Keeping in mind the 80-20 rule, in > what way do you find this code costly? Compare your x86 asm code with the spinlock asm code. More importantly, why is a spinlock or other kernel intrinsic avoided in acgcc.h? It's much less portable this way. > > But my fundamental objection is, > > we are depending on vendors to get locking right in their > > ACPI tables. > > And assume by some magic or design that said locking works > > with whatever > > unrelated kernel locking is going on. > > By design, it works. We get to slipstream Windows a little here in that > vendors need to have a working Global Lock interface to pass WHQL. (1) A working lock interface does not imply that -users- of the lock interface are correct (2) Nobody here puts stock in Windows tests, which I'm assuming the WHQL is. > > It is my initial belief that a smaller info query interface that can > > parse useful ACPI would be more effective. For times like > > suspend/resume where we would want to execute control methods, well, > > there's always the disasm -> write-small-driver cycle. Who knows if > > this is a realistics proposed solution. But it really scares me to > > depend on vendors to get locking right. > > We're depending on vendors (aka the BIOS) for all the ACPI tables, as well > as every other piece of a priori data we need to boot the OS. The difference with ACPI is that vendors can write code that is executed in the kernel's context (instead of what you can consider the BIOS's context). That is a whole new can of worms. > Could I please ask that you at least show me a system where this is a > problem before throwing out all the work we've done on ACPI because of this > technical nit? ACPI is so new I do not think this is necessary. I am reading straight from the spec, the same thing system implementors will read. Anyway, for the main point, which you missed: The global lock is not ONLY for SMM type stuff. The vendor can use it in control methods all over the place. And the vendor can just as easily screw up it up. I do not trust a bios vendor to get runtime OS locking correct... and that is -totally- different from trusting the BIOS to provide us with a tiny bit of information. Look at the Linux boot sequence, which Randy Dunlap documented. We collect as much information as is reasonable from BIOS at startup, so we won't have to talk to it again at runtime. Jeff -- Jeff Garzik | "I respect faith, but doubt is Building 1024| what gives you an education." MandrakeSoft | -- Wilson Mizner - 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: include/asm-i386/checksum.h
Ok.
Sending dozens of patches today, I was asked if I could mail the whole
files, not only the patch and send it Cc'ed to you, Linus.
Here they are:
linux/include/asm-i386/checksum.h and
linux/include/asm-i386/floppy.h
both based on stable linux-2.4.5.
Well, have a lot of fun and thanks in advance!
mfg, Erik
#ifndef _I386_CHECKSUM_H
#define _I386_CHECKSUM_H
/*
* computes the checksum of a memory block at buff, length len,
* and adds in "sum" (32-bit)
*
* returns a 32-bit number suitable for feeding into itself
* or csum_tcpudp_magic
*
* this function must be called with even lengths, except
* for the last fragment, which may be odd
*
* it's best to have buff aligned on a 32-bit boundary
*/
asmlinkage unsigned int csum_partial(const unsigned char * buff, int len, unsigned int sum);
/*
* the same as csum_partial, but copies from src while it
* checksums, and handles user-space pointer exceptions correctly, when needed.
*
* here even more important to align src and dst on a 32-bit (or even
* better 64-bit) boundary
*/
asmlinkage unsigned int csum_partial_copy_generic( const char *src, char *dst, int len, int sum,
int *src_err_ptr, int *dst_err_ptr);
/*
* Note: when you get a NULL pointer exception here this means someone
* passed in an incorrect kernel address to one of these functions.
*
* If you use these functions directly please don't forget the
* verify_area().
*/
extern __inline__
unsigned int csum_partial_copy_nocheck ( const char *src, char *dst,
int len, int sum)
{
return csum_partial_copy_generic ( src, dst, len, sum, NULL, NULL);
}
extern __inline__
unsigned int csum_partial_copy_from_user ( const char *src, char *dst,
int len, int sum, int *err_ptr)
{
return csum_partial_copy_generic ( src, dst, len, sum, err_ptr, NULL);
}
/*
* These are the old (and unsafe) way of doing checksums, a warning message will be
* printed if they are used and an exeption occurs.
*
* these functions should go away after some time.
*/
#define csum_partial_copy_fromuser csum_partial_copy
unsigned int csum_partial_copy( const char *src, char *dst, int len, int sum);
/*
* This is a version of ip_compute_csum() optimized for IP headers,
* which always checksum on 4 octet boundaries.
*
* By Jorge Cwik <[EMAIL PROTECTED]>, adapted for linux by
* Arnt Gulbrandsen.
*/
static inline unsigned short ip_fast_csum(unsigned char * iph,
unsigned int ihl) {
unsigned int sum;
__asm__ __volatile__("\
movl (%1), %0 \
subl $4, %2 \
jbe 2f \
addl 4(%1), %0 \
adcl 8(%1), %0 \
adcl 12(%1), %0 \
1: adcl 16(%1), %0 \
lea 4(%1), %1 \
decl %2 \
jne 1b \
adcl $0, %0 \
movl %0, %2 \
shrl $16, %0 \
addw %w2, %w0 \
adcl $0, %0 \
notl %0 \
2: \
"
/* Since the input registers which are loaded with iph and ipl
are modified, we must also specify them as outputs, or gcc
will assume they contain their original values. */
: "=r" (sum), "=r" (iph), "=r" (ihl)
: "1" (iph), "2" (ihl));
return(sum);
}
/*
* Fold a partial checksum
*/
static inline unsigned int csum_fold(unsigned int sum)
{
__asm__("\
addl %1, %0 \
adcl $0x, %0 \
"
: "=r" (sum)
: "r" (sum << 16), "0" (sum & 0x)
);
return (~sum) >> 16;
}
static inline unsigned long csum_tcpudp_nofold(unsigned long saddr,
unsigned long daddr,
unsigned short len,
unsigned short proto,
unsigned int sum)
{
__asm__("\
addl %1, %0 \
adcl %2, %0 \
adcl %3, %0 \
adcl $0, %0 \
"
: "=r" (sum)
: "g" (daddr), "g"(saddr), "g"((ntohs(len)<<16)+proto*256), "0"(sum));
return sum;
}
/*
* computes the checksum of the TCP/UDP pseudo-header
* returns a 16-bit checksum, already complemented
*/
static inline unsigned short int csum_tcpudp_magic(unsigned long saddr,
unsigned long daddr,
unsigned short len,
unsigned short proto,
unsigned int sum)
{
return csum_fold(csum_tcpudp_nofold(saddr,daddr,len,proto,sum));
}
/*
* this routine is used for miscellaneous IP-like checksums, mainly
* in icmp.c
*/
static inline unsigned short ip_compute_csum(unsigned char * buff, int len) {
return csum_fold (csum_partial(buff, len, 0));
}
#define _HAVE_ARCH_IPV6_CSUM
static __inline__ unsigned short int csum_ipv6_magic(struct in6_addr *saddr,
struct in6_addr *daddr,
__u32 len,
unsigned short proto,
unsigned int sum)
{
__asm__("\
addl 0(%1), %0 \
adcl 4(%1), %0 \
adcl 8(%1), %0 \
adcl 12(%1), %0 \
adcl 0(%2), %0 \
adcl 4(%2), %0 \
adcl 8(%2), %0 \
adcl 12(%2), %0 \
adcl %3, %0 \
adcl %4, %0 \
adcl $0, %0 \
"
: "=" (sum)
: "r" (saddr), "r" (daddr),
"r"(htonl(len)), "r"(htonl(proto)), "0"(sum));
Re: ACPI fundamental locking problems
On Tue, Jul 03, 2001, Jeff Garzik <[EMAIL PROTECTED]> wrote: > I was reading through the ACPI spec, to see what was required to obtain > the IRQ routing table from AML. FWIW, ia64 already does this, if you're looking for the code to do it. JE - 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: pte_val(*pte) as lvalue
On Tue, Jul 03, 2001 at 01:50:05PM -0500, Timur Tabi wrote: > Russell King wrote: > >Can I ask what the nature of the PTE modification is, and where you > >are making this modification? > > > I've written a hack which enables PAT (Page Address Translation) for a > particular page: Firstly, I'll say I'm no x86 expert by any means. However, it may be better to extend the pte bit handling functions in include/asm-i386/pgtable.h to include the bits you need to handle. (eg, see how pte_mkwrite and pte_wrprotect are implemented.) This is probably the cleanest way of handling these bits. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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: ACPI fundamental locking problems
> We're depending on vendors (aka the BIOS) for all the ACPI tables, as well > as every other piece of a priori data we need to boot the OS. They have had enough problems getting simpler API's right. The ACPI spec is bloated, complex, and very hard to follow - and its written in my native language. I really do not envy a random BIOS writers task. > Could I please ask that you at least show me a system where this is a > problem before throwing out all the work we've done on ACPI because of this > technical nit? The goal isnt a technical nit, its to avoid loading 300Kbytes of crud (which should mostly be in user space anyway) on the 99.9% of machines where we dont need it. The user space thing isnt an idle comment btw, its something that I think we should actively pursue for 2.5. By making better use of initrd and the clean ramfsroot stuff Al wants to do we can push a lot of stuff (bootp, dhcp, dmi based configuration fixups, acpi) almost entirely into user space. That makes me a lot lot happier. The fact that it takes more code to parse and interpret ACPI than it does to route traffic on the internet backbones should be a hint something is badly wrong either in ACPI the spec, ACPI the implenentation or both. Reading the code I can find some examples of pointless code bloat, but not enough to convince me the broken part isnt the spec. Alan - 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: ACPI fundamental locking problems
> From: Jeff Garzik [mailto:[EMAIL PROTECTED]] > events/evxface.c:610:acpi_acquire_global_lock -> > events/evmisc.c:337:acpi_ev_acquire_global_lock -> > include/platform/acgcc.h:52:ACPI_ACQUIRE_GLOBAL_LOCK > > My immediate objections are, > (a) acgcc.h is re-implementing spinlocks in a non-standard, > non-portable, and expensive way, and (b) this entire code path is > incredibly expensive. Well, when I look at other Linux code, I assume that if it does something weird, it does it for a reason. That is the case here. The Global Lock is for synchronizing accesses between the OS (that's us) and the firmware (SMI). Normal spinlocks are for intra-OS locking. Here, we're synchronizing access with the BIOS. It's different. All this code has been working for as long as I can remember. You mention twice that it is "expensive". Keeping in mind the 80-20 rule, in what way do you find this code costly? > But my fundamental objection is, > we are depending on vendors to get locking right in their > ACPI tables. > And assume by some magic or design that said locking works > with whatever > unrelated kernel locking is going on. By design, it works. We get to slipstream Windows a little here in that vendors need to have a working Global Lock interface to pass WHQL. > It is my initial belief that a smaller info query interface that can > parse useful ACPI would be more effective. For times like > suspend/resume where we would want to execute control methods, well, > there's always the disasm -> write-small-driver cycle. Who knows if > this is a realistics proposed solution. But it really scares me to > depend on vendors to get locking right. We're depending on vendors (aka the BIOS) for all the ACPI tables, as well as every other piece of a priori data we need to boot the OS. Could I please ask that you at least show me a system where this is a problem before throwing out all the work we've done on ACPI because of this technical nit? Thanks -- Regards -- Andy - 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: Strange thread behaviour on 8-way x86 machine
On Tue, Jul 03, 2001 at 12:25:12PM -0600, Sasha Pachev wrote: > Hi, > > I have observed a rather strange behaviour doing a multi-threaded CPU > benchmark on an 8-way machine running 2.4.2 SMP kernel. Even when the > priority is reniced to the highest possible value, I am still unable to reach > more than 50% CPU utilization. My benchmark just creates a bunch of threads > with pthread_create(), and then runs a simple integer computation in each > thread. On a dual with 2.4.3 kernel, and a 4-way with 2.4.2 kernel, I am able > to reach full CPU utilization. I haven't had any problem fully utilizing 8 CPUs on 2.4.* kernels. This may seem obvious, but do you have more than 4 CPUs worth of work for the system to do? What is the runqueue length during this benchmark? -- Mike Kravetz [EMAIL PROTECTED] IBM Linux Technology Center - 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: pte_val(*pte) as lvalue
Russell King wrote:
>Can I ask what the nature of the PTE modification is, and where you
>are making this modification?
>
I've written a hack which enables PAT (Page Address Translation) for a
particular page:
void set_pte_pat(pte_t *pte, unsigned long pat_index)
{
unsigned long p = pte_val(*pte);
p &= ~(_PAGE_PROTNONE | _PAGE_PCD | _PAGE_PWT);// zero-out the
relevant bits
if (pat_index & 4)
p |= _PAGE_PROTNONE;
if (pat_index & 2)
p |= _PAGE_PCD;
if (pat_index & 1)
p |= _PAGE_PWT;
#if CONFIG_X86_PAE
pte->pte_high = 0;
pte->pte_low = p;
#else
pte_val(*pte) = p;
#endif
--
Timur Tabi
Interactive Silicon
-
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/
PROBLEM: memory allocation error with token ring tms380/abyss modules[follow-up]
Hello, I got a few responses to this original problem... thanks! I've compiled the abyss.o and tms380 token ring drivers into the kernel as opposed to running them as modules. Yesterday the system crashed again and I copied down all the Oops stuff and ran it through ksymoops... I'm including the output from that in this e-mail. I hope it is useful to the maintainer of the tms380 code and maybe the abyss code! BTW, Adam Fritzler is listed as the tms380 maintainer, but his e-mail address, listed as [EMAIL PROTECTED], is failing and the URL listed -- http://www.auk.cx/tms380tr/ -- also fails. Output from ksymoops, all other information in the original e-mail still applies: [root@ohdrouter /root]# ksymoops oops.7.2.2001 ksymoops 0.7c on i686 2.4.5. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Oops: 0002 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010046 eax: ebx: c391ede0 ecx: 0246 edx: c02a7080 esi: 0292 edi: ebp: c000b5c8 esp: c0245f10 ds: 0018 es: 0018 ss: 0018 Process swapper (pid:0, stackpage=c0245000) Stack: c391ede0 c0292010 0001 c019092d c391ede0 c391ede0 c114a40 000a c114a400 000a c0008000 000a 0040 c0008000 c018f124 c114a400 c114a400 c1128b40 0401 000c c0245fac c0107dad 000c c114a400 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: ff 80 24 00 00 00 82 42 0c 89 43 08 ff 40 08 8b 50 04 89 03 >>EIP; c01afd48<= Trace; c019092d Trace; c018f124 Trace; c0107dad Trace; c0107f17 Trace; c0105170 Trace; c0105170 Trace; c0106b98 Trace; c0105170 Trace; c0105170 Trace; c0100018 Trace; c0105193 Trace; c01051f4 Trace; c0105000 Trace; c0100197 Code; c01afd48 <_EIP>: Code; c01afd48<= 0: ff 80 24 00 00 00 incl 0x24(%eax) <= Code; c01afd4e 6: 82(bad) Code; c01afd4f 7: 42inc%edx Code; c01afd50 8: 0c 89 or $0x89,%al Code; c01afd52 a: 43inc%ebx Code; c01afd53 b: 08 ff or %bh,%bh Code; c01afd55 d: 40inc%eax Code; c01afd56 e: 08 8b 50 04 89 03 or %cl,0x3890450(%ebx) 2 warnings issued. Results may not be reliable. I hope this is useful to the maintainer(s)! Please let me know if there is anything I can do to help. Thank you, Brian On Tue, 19 Jun 2001, Brian McEntire wrote: > [1.] memory allocation error with token ring tms380/abyss modules > > [2.] a memory allocation error causes the system to go into an infinite > loop about once every week or two. This most recent time was 8 days, to > the hour from the last crash. Everything on the system stops working and I > need to hit the reset button to reboot the system. At crash time, the > following message scrolls up the screen: > > __alloc_pages: 1-order allocation failed > > * Actually, I did some searching on the web and found this problem > discussed but not fixed. According to one e-mail, I patched > mm/page_alloc.c and rebuilt the kernel so that I could get the following > _slightly_ more informative message after the crash: > > __alloc_pages: 1-order allocation failed from c01290e8 > > The modification I made to mm/page_alloc.c is: > change the line: > > printk(KERN_ERR "__alloc_pages: %lu-order allocation failed.\n", order); > > to: > > printk(KERN_ERR "__alloc_pages: %lu-order allocation failed from %p\n", > order, __builtin_return_address(0)); > > Then I'm supposed to be able to look up the hex code from the error > message in the /boot/System.map (it is the correct one for my kernel) and > find out what function is causing the problem. > > But, I don't find c01290e8 in my System.map. Two hex addresses close to it > are found there: > > c01290d4 T __get_free_pages > c01290f4 T get_zeroed_page > > Yup, looks like it has something to do with memory allocation alright ;-) > > Everytime this crash occurs, it is the same hex address given in the error > message. I can't cause this error to occur. The system is running as a > basic router and has two Netgear FA310TX ethernet cards in it and one > Madge Smart 16/4 PCI Ringnode Mk2 token ring card in it. > > The system logs don't give any indication that the crash
Re: pte_val(*pte) as lvalue
On Tue, Jul 03, 2001 at 01:32:36PM -0500, Timur Tabi wrote: > ** Reply to message from Andi Kleen <[EMAIL PROTECTED]> on 03 Jul 2001 01:33:42 +0200 > > set_pte(pte, mk_pte( ... )) > > I'm not sure how to use mk_pte. The first parameter is a struct page *, > which I don't have. All I'm doing is modifying the PTE value. I don't > want to "make" another one. set_pte is the only way you can guarantee that the architecture implementation gets to do what it needs to do with the PTE value before stuffing it into the PTE tables. Can I ask what the nature of the PTE modification is, and where you are making this modification? -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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: pte_val(*pte) as lvalue
** Reply to message from Andi Kleen <[EMAIL PROTECTED]> on 03 Jul 2001 01:33:42 +0200 > Timur Tabi <[EMAIL PROTECTED]> writes: > > > > > What is the accepted way to assign an integer to a pte that works in 2.2 and > > 2.4? > > set_pte(pte, mk_pte( ... )) I'm not sure how to use mk_pte. The first parameter is a struct page *, which I don't have. All I'm doing is modifying the PTE value. I don't want to "make" another one. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com - 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/
Strange thread behaviour on 8-way x86 machine
Hi, I have observed a rather strange behaviour doing a multi-threaded CPU benchmark on an 8-way machine running 2.4.2 SMP kernel. Even when the priority is reniced to the highest possible value, I am still unable to reach more than 50% CPU utilization. My benchmark just creates a bunch of threads with pthread_create(), and then runs a simple integer computation in each thread. On a dual with 2.4.3 kernel, and a 4-way with 2.4.2 kernel, I am able to reach full CPU utilization. At first glance, it appears to be like some overzealous fairness problem in the scheduler that is exhibited only when you have more than 4 CPUs. Before I start scrutinizing the source trying to understand the inner workings of the scheduler, I would like to get some feedback from people that know something about the subject. Any ideas/suggestions would be appreciated. -- MySQL Development Team For technical support contracts, visit https://order.mysql.com/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA <___/ - 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: VM Requirement Document - v0.0
On Monday 02 July 2001 20:42, Rik van Riel wrote: > On Thu, 28 Jun 2001, Marco Colombo wrote: > > I'm not sure that, in general, recent pages with only one access are > > still better eviction candidates compared to 8 hours old pages. Here > > we need either another way to detect one-shot activity (like the one > > performed by updatedb), > > Fully agreed, but there is one problem with this idea. > Suppose you have a maximum of 20% of your RAM for these > "one-shot" things, now how are you going to be able to > page in an application with a working set of, say, 25% > the size of RAM ? Easy. What's the definition of working set? Those pages that are frequently referenced. So as the application starts up some of its pages will get promoted from used-once to used-often. (On the other hand, the target behavior here conflicts with the goal of grouping together several temporally-related accesses to the same page together as one access, so there's a subtle distinction to be made here, see below.) The point here is that there are such things as run-once program pages, just as there are use-once file pages. Both should get low priority and be evicted early, regardless of the fact they were just loaded. > If you don't have any special measures, the pages from > this "new" application will always be treated as one-shot > pages and the process will never be able to be cached in > memory completely... The self-balancing way of doing this is to promote pages from the old end of the used-once list to the used-often (active) list at a rate corresponding to the fault-in rate so we get more aggressive promotion of referenced-often pages during program loading, and conversely, aggressive demotion of referenced-once pages. -- Daniel -- Daniel - 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: VM Requirement Document - v0.0
An ammendment to my previous post... > I see three page priority levels: > > 0 - accessed-never/aged to zero > 1 - accessed-once/just loaded > 2 - accessed-often > > with these transitions: > > 0 -> 1, if a page is accessed > 1 -> 2, if a page is accessed a second time > 1 -> 0, if a page gets old > 2 -> 0, if a page gets old Better: 1 -> 0, if a page was not referenced before arriving at the old end 1 -> 2, if it was Meaning that multiple accesses to pages on the level 1 list are treated as a single access. In addition, this reflects what we can do practically with the hardware referenced bit. -- Daniel - 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: ufs on linux question/problem
> > You need support of Solaris disklabels. isn't that what CONFIG_SOLARIS_X86_PARTITION is? > And UFS patches that are in > -ac. Then you can get more or less safe r/o mounts. r/w is hopeless > at that stage. that's ok, i only need to read. -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - 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-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols
Alan Cox wrote: > > > The way that I architected the raw NAND flash device driver was to > > break it into 2 parts. 'nand.c' contains the actual driver code and > > is considered to be device independent. 'spia.c' is the device > > dependent part. You should write your own version of 'spia.c' and > > So the Config.in is wrong since I can select spia on x86 > Indeed. That should be fixed now with this patch. Now onto the stuff for ESR. -Steve -- Steven J. Hill - Embedded SW Engineer spia.diff
Regrding module programing
Hi all, I like to know whether the kernel modules concepts is present only in linux (or) it is also supported in some other flavour of unix operating systems. Can any one please update me, regarding this ? Thanks, siva __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - 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/
ACPI fundamental locking problems
I used to be pretty excited about ACPI, until today. I was reading through the ACPI spec, to see what was required to obtain the IRQ routing table from AML. Continued reading... until I hit a section talking about the ACPI global lock. events/evxface.c:610:acpi_acquire_global_lock -> events/evmisc.c:337:acpi_ev_acquire_global_lock -> include/platform/acgcc.h:52:ACPI_ACQUIRE_GLOBAL_LOCK My immediate objections are, (a) acgcc.h is re-implementing spinlocks in a non-standard, non-portable, and expensive way, and (b) this entire code path is incredibly expensive. But my fundamental objection is, we are depending on vendors to get locking right in their ACPI tables. And assume by some magic or design that said locking works with whatever unrelated kernel locking is going on. It is my initial belief that a smaller info query interface that can parse useful ACPI would be more effective. For times like suspend/resume where we would want to execute control methods, well, there's always the disasm -> write-small-driver cycle. Who knows if this is a realistics proposed solution. But it really scares me to depend on vendors to get locking right. We'll see what 2.5 will bring... -- Jeff Garzik | "I respect faith, but doubt is Building 1024| what gives you an education." MandrakeSoft | -- Wilson Mizner - 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: mmap
On Mon, Jul 02 2001, [EMAIL PROTECTED] wrote: > [1] IMHO it would be more useful if iobufs would use a scatterlist > instead of an struct page* array. No that would be horrible, at least with the current scatterlist. A page based scatterlist would be alright though -- but this boils down to the per-page offset debate again. -- Jens Axboe - 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: Cross-reference analysis reveals problems in 2.4.6pre9
David Woodhouse <[EMAIL PROTECTED]>: > Upon further investigation, it seems I was mistaken. I apologise for my tone. Accepted. I wish more people had the grace you do, to apologize when you know you've been mistaken or unfair; it would make this list a better place. > Momenco Ocelot boot flash device > CONFIG_MTD_OCELOT > This enables access routines for the boot flash device and for the > NVRAM on the Momenco Ocelot board. If you have one of these boards > and would like access to either of these, say 'Y'. Incorporated. I have also received mail from someone who can fill in the new MIPS entries, so initial results from the posting are quite good. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The direct use of physical force is so poor a solution to the problem of limited resources that it is commonly employed only by small children and great nations. -- David Friedman - 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: Cross-reference analysis reveals problems in 2.4.6pre9
[EMAIL PROTECTED] said: > I put the symbols we discussed previously on my ignore list. What's > your beef this time? It looked like you were again reporting config symbols which the user can't be asked about - because they're only there as dependencies or as ifdefs in the code, rather than as selectable options. Upon further investigation, it seems I was mistaken. I apologise for my tone. In fact, it seems that a lot of MIPS code has been merged into -pre9, and those options _are_ now selectable, rather than just being there as dependencies for some of my code. CONFIG_MTD_OCELOT is mine and I thought I'd already submitted help text for it - evidently I'd missed it but because its dependencies were unselectable your scripts weren't noticing it: Momenco Ocelot boot flash device CONFIG_MTD_OCELOT This enables access routines for the boot flash device and for the NVRAM on the Momenco Ocelot board. If you have one of these boards and would like access to either of these, say 'Y'. -- dwmw2 - 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: ufs on linux question/problem
On Tue, 3 Jul 2001, Admin Mailing Lists wrote: > > Trying to mount a solaris x86 drive under linux. > kernel 2.4.5, ufs support and x86 partition support compiled in (no > module) > On boot, linux recognizes the drive, but shows no solaris partitions on > it. > Below, linux drive is hda, solaris is hdb. You need support of Solaris disklabels. And UFS patches that are in -ac. Then you can get more or less safe r/o mounts. r/w is hopeless at that stage. - 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/
Patch for IDE hang after resetting quirk drive
I have a Promise PDC20265 ide controller with one of the "quirk" drives, a Quantum Fireballp LM30. That drive has a bad sector and accessing it would result in a DMA timeout. Unfortunately, after the IDE driver resets the controller, the drive never responded. The following patch appears to correct the problem. It duplicates the workaround for "quirky" drives found in ide-features.c -Dale Dale Farnsworth [EMAIL PROTECTED] --- oldlinux-2.4.5/drivers/ide/ide.cTue Jul 3 09:35:57 2001 +++ linux-2.4.5/drivers/ide/ide.c Tue Jul 3 09:23:58 2001 @@ -758,7 +758,10 @@ */ OUT_BYTE(drive->ctl|6,IDE_CONTROL_REG); /* set SRST and nIEN */ udelay(10); /* more than enough time */ - OUT_BYTE(drive->ctl|2,IDE_CONTROL_REG); /* clear SRST, leave nIEN */ + if (drive->quirk_list == 2) + OUT_BYTE(drive->ctl, IDE_CONTROL_REG); /* clear SRST and nIEN */ + else + OUT_BYTE(drive->ctl|2,IDE_CONTROL_REG); /* clear SRST only */ udelay(10); /* more than enough time */ hwgroup->poll_timeout = jiffies + WAIT_WORSTCASE; ide_set_handler (drive, _pollfunc, HZ/20, NULL); - 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: Cross-reference analysis reveals problems in 2.4.6pre9
* Eric S. Raymond <[EMAIL PROTECTED]> on Tue, Jul 03, 2001: > According to my cross-reference generator, the following symbols have > missing help in 2.4.6-pre9: > [...] > CONFIG_MAPLE > CONFIG_MAPLE_KEYBOARD > CONFIG_MAPLE_MOUSE These three are for the Dreamcast driver port. I can write help entries for them, but I don't think NIIBE has sent SuperH updates in awhile, the only missing symbol is CONFIG_INPUT_MAPLE_CONTROL, I'll write that one as well. M. R. - 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: Removal of PG_marker scheme from 2.4.6-pre
On Sun, 1 Jul 2001, Rik van Riel wrote: > On Sat, 30 Jun 2001, Marcelo Tosatti wrote: > > > In pre7: > > > > "me: undo page_launder() LRU changes, they have nasty side effects" > > > > Can you be more verbose about this ? > > I think this was fixed by the GFP_BUFFER vs. GFP_CAN_FS + GFP_CAN_IO > thing and Linus accidentally backed out the wrong code ;) > > cheers, > Rik Nope. -ac also freezes and it does not have the GFP_BUFFER changes. - 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/
ufs on linux question/problem
Trying to mount a solaris x86 drive under linux. kernel 2.4.5, ufs support and x86 partition support compiled in (no module) On boot, linux recognizes the drive, but shows no solaris partitions on it. Below, linux drive is hda, solaris is hdb. Jul 2 19:57:56 stevenjude2 kernel: PIIX4: chipset revision 2 Jul 2 19:57:56 stevenjude2 kernel: PIIX4: not 100%% native mode: will probe irqs later Jul 2 19:57:56 stevenjude2 kernel: ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio Jul 2 19:57:56 stevenjude2 kernel: ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio Jul 2 19:57:56 stevenjude2 kernel: hda: WDC AC26400B, ATA DISK drive Jul 2 19:57:56 stevenjude2 kernel: hdb: QUANTUM FIREBALL ST3.2A, ATA DISK driveJul 2 19:57:56 stevenjude2 kernel: hdc: SAMSUNG SC-140B, ATAPI CD/DVD-ROM driveJul 2 19:57:56 stevenjude2 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Jul 2 19:57:56 stevenjude2 kernel: ide1 at 0x170-0x177,0x376 on irq 15 Jul 2 19:57:56 stevenjude2 kernel: hda: 12594960 sectors (6449 MB) w/512KiB Cache, CHS=784/255/63, UDMA(33) Jul 2 19:57:56 stevenjude2 kernel: hdb: 6306048 sectors (3229 MB) w/81KiB Cache, CHS=6256/16/63, UDMA(33) Jul 2 19:57:56 stevenjude2 kernel: Partition check: Jul 2 19:57:56 stevenjude2 kernel: hda: hda1 hda2 hda3 < hda5 > Jul 2 19:57:56 stevenjude2 kernel: hdb: Tried to mount from the command line with: mount -r -t ufs -o ufstype=sunx86,ro /dev/hdb /mnt mount -r -t ufs -o ufstype=sunx86,ro /dev/hdb1 /mnt All failed. Only relevant log message i saw was: Jul 2 22:04:02 stevenjude2 kernel: ufs_read_super: bad magic number a fdisk on /dev/hdb shows no partitions. could the drive or partitions be corrupted or something? if so, is data salvage likely? Thanx, -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - 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: Cross-reference analysis reveals problems in 2.4.6pre9
Steven J. Hill <[EMAIL PROTECTED]>: > I can fill in the blanks on all of these for you. I won't clutter > up the mailing list with the complete descriptions. That would be excellent. Please do! -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The spirit of resistance to government is so valuable on certain occasions, that I wish it always to be kept alive. It will often be exercised when wrong, but better so than not to be exercised at all. I like a little rebellion now and then. -- Thomas Jefferson, letter to Abigail Adams, 1787 - 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: Cross-reference analysis reveals problems in 2.4.6pre9
David Woodhouse <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] said: > > According to my cross-reference generator, the following symbols have > > missing help in 2.4.6-pre9: > > Please fix your cross-reference generator as previously discussed before > posting these lists again. I put the symbols we discussed previously on my ignore list. What's your beef this time? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The saddest life is that of a political aspirant under democracy. His failure is ignominious and his success is disgraceful. -- H.L. Mencken - 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: Cross-reference analysis reveals problems in 2.4.6pre9
"Eric S. Raymond" wrote: > > CONFIG_MIPS_EV64120 > CONFIG_MIPS_EV96100 > CONFIG_MIPS_ITE8172 > CONFIG_MIPS_IVR > CONFIG_MIPS_PB1000 > CONFIG_MIPS_UNCACHED > CONFIG_NINO > CONFIG_NINO_16MB > CONFIG_NINO_4MB > CONFIG_NINO_8MB > I can fill in the blanks on all of these for you. I won't clutter up the mailing list with the complete descriptions. -Steve -- Steven J. Hill - Embedded SW Engineer - 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: Cross-reference analysis reveals problems in 2.4.6pre9
[EMAIL PROTECTED] said: > According to my cross-reference generator, the following symbols have > missing help in 2.4.6-pre9: Please fix your cross-reference generator as previously discussed before posting these lists again. -- dwmw2 - 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/
Kernel oops 2.4.2
Hello everyone,
I got the following oops on a HP Netserver (single CPU) running Linux
version
2.4.2-SGI_XFS_1.0 compiled with gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)
with two modifications:
--- v2.4.4/linux/fs/nfsd/nfsfh.cFri Feb 9 11:29:44 2001
+++ linux/fs/nfsd/nfsfh.c Sat May 19 17:47:55 2001
@@ -244,6 +245,11 @@
*/
pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry);
d_drop(tdentry); /* we never want ".." hashed */
+ if (!pdentry && tdentry->d_inode == NULL) {
+ /* File system cannot find ".." ... sad but possible */
+ dput(tdentry);
+ pdentry = ERR_PTR(-EINVAL);
+ }
if (!pdentry) {
/* I don't want to return a ".." dentry.
* I would prefer to return an unconnected "IS_ROOT" dentry,
Without this patch the machine would cause an oops with NULL pointer
dereference (probably looking up ../).
Furthermore the megaraid driver 1.14b is used in this kernel.
kernel BUG at dcache.c:128!
invalid operand:
CPU:0
EIP:0010:[dput+40/376]
EIP:0010:[]
EFLAGS: 00013286
eax: 001c ebx: de98e1e0 ecx: edx:
esi: de98e1e0 edi: de98e6e0 ebp: de98e6e0 esp: deecdebc
ds: 0018 es: 0018 ss: 0018
Process nfsd (pid: 749, stackpage=deecd000)
Stack: c02ca5cb c02ca66b 0080 ffea de98e1e0 c0172ddc de98e1e0
0503317e c0173176 de98e6e0 deedbe14 1127 deedbe04
c0113638
ef5619e0 deecc000 ff8c c0173504 ef561800 0503317e
Call Trace: [error_table+41059/44824] [error_table+41219/44824]
[nfsd_findparent+212/220] [find_fh_dentry+582/880] [schedule+736/1080]
[fh_verify+612/1128] [nfsd3_proc_getattr+149/160]
Call Trace: [] [] [] [] []
[] []
[nfsd_dispatch+203/360] [svc_process+684/1348] [nfsd+401/760]
[kernel_thread+35/48]
[] [] [] []
Code: 0f 0b 83 c4 0c 8d 76 00 ff 0b 0f 94 c0 84 c0 0f 84 35 01 00
This oops is more or less reproduce. Several HP-UX machines mount a
directory from this Linux machine via NFS. Running 'ls -lR' + some
filemanager actions make this oops happen.
What could be causing this problem? A bug in the knfsd or is it related
to SGI's XFS? nfs-utils-0.3.1-5 from RedHat are used. If further infos
are required just send me an email ...
Kind regards,
Jochen Heuer
-
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: 2.4.6-pre9: Failed HPT370 detection
On Tuesday 03 July 2001 17:22, Gav wrote: > This kernel refuses to detect my HPT370 chipset. (where my root filesystem > is, on raid0). It just hangs where the detection usually takes place, so no > oops and no meaningfull bugreport :/ > > I have the same options set in my config as I always have, I've never had > any problem with this before. > > CONFIG_BLK_DEV_HPT366=y > CONFIG_MD_RAID0=y > > Anyone else seen this? Maybe its more VIA weirdness. > Actually its the drives ON the HPT chipset that arent being detected, not the chipset itself. usually: HPT370: IDE controller on PCI bus 00 dev 98 PCI: Found IRQ 11 for device 00:13.0 HPT370: chipset revision 3 HPT370: not 100%% native mode: will probe irqs later ide2: BM-DMA at 0xe000-0xe007, BIOS settings: hde:DMA, hdf:pio ide3: BM-DMA at 0xe008-0xe00f, BIOS settings: hdg:DMA, hdh:pio hda: SAMSUNG SV0322A, ATA DISK drive hdb: Hewlett-Packard CD-Writer Plus 9100b, ATAPI CD/DVD-ROM drive hde: IBM-DTLA-305040, ATA DISK drive hdg: IBM-DTLA-305040, ATA DISK drive in 2.4.6-pre9: HPT370: IDE controller on PCI bus 00 dev 98 PCI: Found IRQ 11 for device 00:13.0 HPT370: chipset revision 3 HPT370: not 100%% native mode: will probe irqs later ide2: BM-DMA at 0xe000-0xe007, BIOS settings: hde:DMA, hdf:pio ide3: BM-DMA at 0xe008-0xe00f, BIOS settings: hdg:DMA, hdh:pio hda: SAMSUNG SV0322A, ATA DISK drive hdb: Hewlett-Packard CD-Writer Plus 9100b, ATAPI CD/DVD-ROM drive Sorry about that. -- Gavin Baker - 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/
Cross-reference analysis reveals problems in 2.4.6pre9
According to my cross-reference generator, the following symbols have missing help in 2.4.6-pre9: CONFIG_AU1000_UART CONFIG_BLUEZ_L2CAP CONFIG_DDB5477 CONFIG_EVB_PCI1 CONFIG_FORWARD_KEYBOARD CONFIG_GDB_CONSOLE CONFIG_HD64465_IOBASE CONFIG_IT8172_REVC CONFIG_IT8172_SCR0 CONFIG_IT8172_SCR1 CONFIG_LL_DEBUG CONFIG_MAPLE CONFIG_MAPLE_KEYBOARD CONFIG_MAPLE_MOUSE CONFIG_MIDI_VIA82CXXX CONFIG_MIPS_EV64120 CONFIG_MIPS_EV96100 CONFIG_MIPS_ITE8172 CONFIG_MIPS_IVR CONFIG_MIPS_PB1000 CONFIG_MIPS_UNCACHED CONFIG_MTD_OCELOT CONFIG_NINO CONFIG_NINO_16MB CONFIG_NINO_4MB CONFIG_NINO_8MB CONFIG_ORION CONFIG_SH_7751_SOLUTION_ENGINE CONFIG_ST40_LMI_MEMORY CONFIG_SYSCLK_100 CONFIG_SYSCLK_75 CONFIG_SYSCLK_83 CONFIG_TULIP_MMIO This list exposes a couple of problems: 1. CONFIG_ORION has been removed from the main MIPS config.in but is still referenced in drivers/net/config.in. 2. The MIPS config.in sets CONFIG_AU1000 but does not reference it, then references CONFIG_AU1000_UART without ever setting it. This probably indicates that one of these is a mistake. I have already written help entries for three other symbols CONFIG_DDB5477, CONFIG_QTRONIX_KEYBOARD, and CONFIG_AGP_SWORKS. Would responsible maintainers please supply help entries for the above? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond "Boys who own legal firearms have much lower rates of delinquency and drug use and are even slightly less delinquent than nonowners of guns." -- U.S. Department of Justice, National Institute of Justice, Office of Juvenile Justice and Delinquency Prevention, NCJ-143454, "Urban Delinquency and Substance Abuse," August 1995. - 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/
2.4.6-pre9: Failed HPT370 detection
This kernel refuses to detect my HPT370 chipset. (where my root filesystem is, on raid0). It just hangs where the detection usually takes place, so no oops and no meaningfull bugreport :/ I have the same options set in my config as I always have, I've never had any problem with this before. CONFIG_BLK_DEV_HPT366=y CONFIG_MD_RAID0=y Anyone else seen this? Maybe its more VIA weirdness. -- Regards, Gavin Baker - 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/
Fun with Athlon, VIA KX133, and kernel 2.4.x
Hello, My system has a Procomp BVK1A mainboard sporting one of those dreaded VIA KX133 chipsets. I have been a virtual lurker, monitoring the archives, and have heard plenty of horror stories about this chipset, but let me make clear that this board was rock-solid for the better part of a year. It would go for weeks without a power-off or reboot. People would look at me funny, and ask, "Doesn't your computer *crash*?" (Of course not; it runs Linux!) Then, a couple of months ago, I installed 2.4.4. And that, as Stevie B. once said, was where the heartache began. Every time I use X, given sufficient time (between 15 minutes and 24 hours), the system would freeze. Solid. I haven't tried the Magic SysRq key, but heck, my CapsLock won't even go on and off. Usually it takes a while but the problem seems to be exacerbated by heavy-load, graphics-intensive applications (GIMP and Mozilla come to mind). Console mode seems to run okay, but in the Real World sometimes a GUI is necessary. That's not the half of it. Sometimes, Windows freezes in identical fashion. I've even experienced it occasionally under NetBSD, but that usually takes quite a long while. I've tried 2.4.4, 2.4.5, several AC patches to 2.4.5, then I went back and tried 2.4.1. I've compiled it for an Athlon, a PII, a Pentium, and a 486. I suspected the AGPGART and DRI drivers and so I unloaded those as well. I'm typing this message to you under kernel 2.2.19. I am still experiencing freezes. Remember, this box was incredibly stable before 2.4.4 and I really don't want to give up this mainboard and CPU; it's got some nice things (like 2 serial ports!) that are hard to find anymore. The CPU is not overclocked and I have ruled out cooling problems (the fans hum nicely at top speed). I was wondering if anyone knew what's going on, and if there's some patch I need to apply. Did I tickle some sort of schroedinbug in the chipset that was kind of hiding there, waiting to make things fail? If anyone has any answers, please CC me personally. Thanks for all your time and patience. -- -- Jeff Read <[EMAIL PROTECTED]> Unix Code Artist, Anime Fan, Really Cool Guy _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - 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: about kmap_high function
Hi, On Tue, Jul 03, 2001 at 10:47:20PM +1000, Paul Mackerras wrote: > Stephen C. Tweedie writes: > > On PPC it is a bit different. Flushing a single TLB entry is > relatively cheap - the hardware broadcasts the TLB invalidation on the > bus (in most implementations) so there are no cross-calls required. But > flushing the whole TLB is expensive because we (strictly speaking) > have to flush the whole of the MMU hash table as well. How much difference is there? We only flush once per kmap sweep, and we have 1024 entries in the global kmap pool, so the single tlb flush would have to be more than a thousand times less expensive overall than the global flush for that change to be worthwhile. If the page flush really is _that_ much faster, then sure, this decision can easily be made per-architecture: the kmap_high code already has all of the locking and refcounting to know when a per-page tlb flush would be safe. Cheers, Stephen - 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: O_DIRECT please; Sybase 12.5
Hi, On Tue, Jul 03, 2001 at 08:10:39AM -0700, Daryll Strauss wrote: > I recall hearing about a problem with the md device and raw IO. It was > something about the block sizes not matching causing performance > problems. Has anything been done to improve those issues? The problem is a combination of two things. First, raw IO is always fully synchronous, so with raw IO (and O_DIRECT) you are, in effect, explicitly instructing the kernel not to do any readahead. That makes it hard to keep two disks running in parallel with soft raid if you are using small IOs, obviously. Secondly, raw IO pins buffers in physical memory, and to avoid causing serious VM problems due to having too much unswappable memory pinned by arbitrary applications, the current raw IO driver limits the pinned chunk size to 64k. That, combined with the sequential nature of raw IO, can limit performance, certainly. Raw IO is quite capable of running with larger chunk sizes, but we really need a kernel limiter of some description to prevent users from using this mechanism to pin massive amounts of memory for raw IO at once. There are several candidate mechanisms for that, but none in the main kernel right now. Cheers, Stephen - 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-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols
"Adam J. Richter" wrote: > > If there is no architecture on which > linux-2.4.6-pre8/drivers/mtd/nand/spia.c will compile in its > "pristine" form, then the CONFIG_MTD_NAND_SPIA should be commented > out from drivers/mtd/nand/Config.in to avoid wasting the time of > users and automated build processes alike that just want to build > all available modules by default. (At the moment, this code is > not even bracketed by CONFIG_EXPERIMENTAL, although changing that > would not be a sufficient fix.) > David has fixed this and it is in the MTD CVS now. > Alternatively, if you will send me a one line description > of each of those four #define parameters, I will be happy to do the grunt > work of submiting a patch to you or whoever is appropriate to replace > those values with module and setup parameters that default to those > values if there are #defined and otherwise will abort initialization > if they are not #defined and no values were provided at run time. > (Or, better, yet, you can do this work!) > I have filled in the #define values and placed the new 'spia.c' into the MTD CVS. I added comments for how those various values should be defined. Shame on me for forgetting to comment those months ago. Sorry. I believe that fixes things now? -Steve -- Steven J. Hill - Embedded SW Engineer - 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: Memory access
> My question: is the kernel using or protecting this area of the memory, > and is there a way to deprotect it??? (how dangerous!) The kernel maps ISA space at different addresses. What address and how it is accessed depends on the CPU and system isa_readb/readw/readl(addr) isa/writeb/writew/writel(value,addr) to read/write 8,16,32 bit values - 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: O_DIRECT please; Sybase 12.5
On Tue, Jul 03, 2001 at 10:42:53AM +0100, Stephen C. Tweedie wrote: > On Fri, Jun 29, 2001 at 02:39:00AM -0700, Dan Kegel wrote: > > > It supports raw partitions, which is good; that might satisfy my > > boss (although the administration will be a pain, and I'm not > > sure whether it's really supported by Dell RAID devices). > > All block devices support raw IO --- the raw IO mechanism talks to the > device driver through the normal kernel-internal block IO entry > points. > > > I'd prefer O_DIRECT :-( > > Andrea Arcangeli has already posted patches you can try for ext2. The > functionality isn't in the mainline kernel yet, though. I recall hearing about a problem with the md device and raw IO. It was something about the block sizes not matching causing performance problems. Has anything been done to improve those issues? - |Daryll - 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: VM Requirement Document - v0.0
On Tuesday 03 July 2001 12:33, Marco Colombo wrote: > Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only > when background aging, maybe it's not enough to keep processes like > updatedb from causing interactive pages to be evicted. > That's why I said we should have another way to detect that kind of > activity... well, the application could just let us know (no need to > embed an autotuning-genetic-page-replacement-optimizer into the kernel). > We should just drop all FS metadata accessed by updatedb, since we > know that's one-shot only, without raising pressure at all. Note that some of updatedb's metadata pages are of the accessed-often kind, e.g., directory blocks and inodes. A blanket low priority on all the pages updatedb touches just won't do. > Just like > (not that I'm proposing it) putting those "one-shot" pages directly on > the inactive-clean list instead of the active list. How an application > could declare such a behaviour is an open question, of course. Maybe it's > even possible to detect it. And BTW that's really fine tuning. > Evicting an 8 hours old page may be a mistake sometime, but it's never > a *big* mistake. IMHO, updatedb *should* evict all the "interactive" pages that aren't actually doing anything[1]. That way it should run faster, provided of course its accessed-once pages are properly given low priority. I see three page priority levels: 0 - accessed-never/aged to zero 1 - accessed-once/just loaded 2 - accessed-often with these transitions: 0 -> 1, if a page is accessed 1 -> 2, if a page is accessed a second time 1 -> 0, if a page gets old 2 -> 0, if a page gets old The 0 and 1 level pages are on a fifo queue, the 2 level pages are scanned clock-wise, relying on the age computation[2]. Eviction candidates are taken from the cold end of the 0 level list, unless it is empty, in which case they are taken from the 1 level list. In desperation, eviction candidates are taken from the 2 level list, i.e., random eviction policy, as opposed to what we do now which is to initiate an emergency scan of the active list for new inactive candidates - rather like calling a quick board meeting when the building is on fire. Note that the above is only a very slight departure from the current design. And by the way, this is just brainstorming, it hasn't reached the 'proposal' stage yet. [1] It would be nice to have a mechanism whereby the evicted 'interactive' pages are automatically reloaded when updatedb has finished its work. This is a case of scavenging unused disk bandwidth for something useful, i.e., improving the interactive experience. [2] I much prefer the hot/cold terminology over old/young. The latter gets confusing because a 'high' age is 'young'. I'd rather think of a high value as being 'hot'. -- Daniel - 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: Problem with SMC Etherpower II + kernel newer 2.4.2
On 0, Florian Schmitt <[EMAIL PROTECTED]> wrote: > > > Does anybody else got these errors or knows about a solution for this ?? > > Same problem here, it won't run at all on newer kernels. But it isn't even > 100% stable in 2.2.x here - on very high network traffic the card stops > working. In this case, it helps to pull the network plug for a short time, > then everything goes back to normal. I reduced speed to 10MB, and now it is > stable at least in 2.2.x. I use (kernel 2.4.4 and 2.4.5) a cron script that pings, and will run ifdown eth0; ifup eth0 when the ping fails, this seems to be good enough to get it up and running again, sometimes I need to reload the module, but it's indeed very annoying. if ! ping -c 1 -n -q 192.168.100.2 ; then ifdown eth0 ifup eth0 if ! ping -c 1 -n -q 192.168.100.2 ; then ifdown eth0 rmmod epic100 insmod epic100 ifup eth0 fi fi regards, Olivier - 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: Memory access
On Tue, 3 Jul 2001, [iso-8859-1] Guillaume Lancelin wrote: > Writing a device driver for a IO card, I have the following message from > the kernel: > Unable to handle kernel paging request at virtual address 000d0804. > [then it gives the register values] > Segmentation fault." > > This address (0xd0804) is the location of a "mailbox" reserved by the IO > card, and from which commands are passed to the card. > > My question: is the kernel using or protecting this area of the memory, > and is there a way to deprotect it??? (how dangerous!) > This is not the correct address!! The addresses in the kernel are virtual addresses, you need to execute ioremap(0xd0804, LENGTH) to get the correct virtual address for access. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any. - 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/
Scsi errors on boot.
I am getting the follwing error messages on the kernel boot. Does anyone have any idea what the problem might be? The kernel is 2.2.19. Thanks. Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 (scsi0:0:0:1) Synchronous at 160.0 Mbyte/sec, offset 63. (scsi0:0:0:1) CHECK_CONDITION on REQUEST_SENSE, returning an error. (scsi0:0:0:1) CHECK_CONDITION on REQUEST_SENSE, returning an error. scsi0 channel 0 : resetting for second half of retries. SCSI bus is being reset for host 0 channel 0. (scsi0:0:0:1) Synchronous at 160.0 Mbyte/sec, offset 63. (scsi0:0:0:1) CHECK_CONDITION on REQUEST_SENSE, returning an error. (scsi0:0:0:1) CHECK_CONDITION on REQUEST_SENSE, returning an error. (scsi0:0:0:1) CHECK_CONDITION on REQUEST_SENSE, returning an error. Vendor: SEAGATE Model: ST39204LW Rev: 0002 Type: Direct-Access ANSI SCSI revision: 03 Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0 (scsi0:0:1:1) Synchronous at 160.0 Mbyte/sec, offset 63. (scsi0:0:1:1) CHECK_CONDITION on REQUEST_SENSE, returning an error. (scsi0:0:1:1) CHECK_CONDITION on REQUEST_SENSE, returning an error. scsi0 channel 0 : resetting for second half of retries. SCSI bus is being reset for host 0 channel 0. (scsi0:0:1:1) Synchronous at 160.0 Mbyte/sec, offset 63. (scsi0:0:1:1) CHECK_CONDITION on REQUEST_SENSE, returning an error. (scsi0:0:1:1) CHECK_CONDITION on REQUEST_SENSE, returning an error. (scsi0:0:1:1) CHECK_CONDITION on REQUEST_SENSE, returning an error. scsi : detected 2 SCSI disks total. (scsi0:0:0:0) Synchronous at 160.0 Mbyte/sec, offset 63. - 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: Memory access
Guillaume Lancelin wrote: > > Writing a device driver for a IO card, I have the following message from > the kernel: > Unable to handle kernel paging request at virtual address 000d0804. > [then it gives the register values] > Segmentation fault." > > This address (0xd0804) is the location of a "mailbox" reserved by the IO > card, and from which commands are passed to the card. > > My question: is the kernel using or protecting this area of the memory, > and is there a way to deprotect it??? (how dangerous!) Sounds like you may want to look into ioremap() and maybe buy Linux Device Drivers by Rubini (O'Reilly). Have fun! Eli ---. No wonder we didn't get this right first time Eli Carter | through. It's not really all that horribly eli.carter(at)inet.com `- complicated, but the _details_ kill you. Linus - 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: Memory access
Guillaume Lancelin wrote: > > Writing a device driver for a IO card, I have the following message from > the kernel: > Unable to handle kernel paging request at virtual address 000d0804. > [then it gives the register values] > Segmentation fault." > > This address (0xd0804) is the location of a "mailbox" reserved by the IO > card, and from which commands are passed to the card. > > My question: is the kernel using or protecting this area of the memory, > and is there a way to deprotect it??? (how dangerous!) Use ioremap() -- Brian Gerst - 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: Memory access
Em Tue, Jul 03, 2001 at 04:45:32PM +0200, Guillaume Lancelin escreveu: > Writing a device driver for a IO card, I have the following message from > the kernel: > Unable to handle kernel paging request at virtual address 000d0804. > [then it gives the register values] > Segmentation fault." > > This address (0xd0804) is the location of a "mailbox" reserved by the IO > card, and from which commands are passed to the card. > > My question: is the kernel using or protecting this area of the memory, > and is there a way to deprotect it??? (how dangerous!) are you accessing it directly? read Documentation/IO-mapping.txt - Arnaldo - 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/
Memory access
Writing a device driver for a IO card, I have the following message from the kernel: Unable to handle kernel paging request at virtual address 000d0804. [then it gives the register values] Segmentation fault." This address (0xd0804) is the location of a "mailbox" reserved by the IO card, and from which commands are passed to the card. My question: is the kernel using or protecting this area of the memory, and is there a way to deprotect it??? (how dangerous!) Thanks Guillaume ___ Do You Yahoo!? Yahoo! Messenger: Comunicación instantánea gratis con tu gente - http://messenger.yahoo.es - 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: [RFC] I/O Access Abstractions
>> I'm more concerned about having all that space mapped permanently in >> kernel virtual space. I'd prefer mapping on-demand, and that would >> require a specific ioremap for IOs. > >I have no problem with the idea of a function to indicate which I/O maps you >are and are not using. But passing resource structs around is way too heavy Too heavy for inx/outx, I agree, but why too heavy to ioremap ? That would make a clean abstract implementation, with a semantic like "prepare this resource for use by the driver". A kind of generic ioremap for IOs, resources, and whatever another bus type may want to define, returning a token that is to be passed to readx/writex in all cases but PIO, where it's passed to inx/outx. That souds to me like the most flexible mecanism, and the small bit of overhead of passing the resource pointer is done _once_, usually at driver init. Something like iomap_resource(struct resource *); iounmap_resource(struct resource *); Eventually, we can have it more fine grained in case where the driver don't need the entire resource (maybe useful for framebuffers exporting very large double-endian apertures where only one half is needed). iomap_resource(struct resource *, unsigned long offset, unsigned long size); iounmap_resource(struct resource *, unsigned long offset, unsigned long size); The implementation would just call ioremap/iounmap for memory type resources, and the identity for IO resources on x86. Other archs can then play whatever tricks, like placing cookies in there. One thing I have in mind here is the ability for things like embedded that can have weird bus types, to have additional flags in the resources taken into account by iomap/unmap to locate the proper bus, or build the proper cookie that will be used by inx/outx, or define some access attributes depending on other resource flags (write combine ?). Ben. - 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: include/asm-i386/checksum.h
On Tue, 3 Jul 2001, J . A . Magallon wrote: > make a couple symlinks and you will not have to touch kernel makefiles: > ln -s /usr/local/include/ncurses /usr/include That's the thing I wanted to work around, but ok. It was just a suggestion. mfg, Erik - 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: include/asm-i386/checksum.h
On 20010703 Erik Meusel wrote: >On Tue, 3 Jul 2001, Keith Owens wrote: > >> >P.S.: would it be possible to patch the menuconfig in that way, that it >> >does look in the whole include-path for the and relating >> >files? they aren't in /usr/include/ in my system and I'm tired of patching >> >linux/scripts/lxdialog/Makefile all the time. :) >> Where is it on your system? What patch do you apply? >It is in /usr/local/include/ since I installed it myself, months ago. >The patch is attached. Just made silly to use /usr/local/ instead of /usr/. > make a couple symlinks and you will not have to touch kernel makefiles: ln -s /usr/local/include/ncurses /usr/include -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Mandrake Linux release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac23 #1 SMP Tue Jul 3 01:58:06 CEST 2001 i686 - 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-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols
>> linux-2.4.6-pre8/drivers/mtd/nand/spia.c references four >> undefined symbols, presumably intended to be #define constants, >> although I am not sure what their values are supposed to be: >> >> IO_BASE >> FIO_BASE >> PEDR >> PEDDR >> >The way that I architected the raw NAND flash device driver was to >break it into 2 parts. 'nand.c' contains the actual driver code and >is considered to be device independent. 'spia.c' is the device >dependent part. You should write your own version of 'spia.c' and >"simply" fill in the addresses for the IO address and control >register address depending on your specific hardware. The above >symbols are only defined for my specific hardware. They should be >changed to values used on your hardware platform. Let me know if >you need further assistance. >-Steve >-- > Steven J. Hill - Embedded SW Engineer If there is no architecture on which linux-2.4.6-pre8/drivers/mtd/nand/spia.c will compile in its "pristine" form, then the CONFIG_MTD_NAND_SPIA should be commented out from drivers/mtd/nand/Config.in to avoid wasting the time of users and automated build processes alike that just want to build all available modules by default. (At the moment, this code is not even bracketed by CONFIG_EXPERIMENTAL, although changing that would not be a sufficient fix.) Alternatively, if you will send me a one line description of each of those four #define parameters, I will be happy to do the grunt work of submiting a patch to you or whoever is appropriate to replace those values with module and setup parameters that default to those values if there are #defined and otherwise will abort initialization if they are not #defined and no values were provided at run time. (Or, better, yet, you can do this work!) Please let me know how you want to proceed. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - 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: alpha - generic_init_pit - why using RTC for calibration?
Here is the patch against the buggy Cypress RTC which is found on some
Alpha boards. It's tested with 2.2.16 & 2.2.19 kernels and as seems should
work with 2.4.x kernels. This patch differs from initial Ivan's version by
the "cc" variable type & different calibrate divisor usage for better
accuracy.
Please consider applying this patch against the 2.2.x tree. It's really
needed due to overall performance reasons.
Thanks,
Oleg.
--- linux/arch/alpha/kernel/time.c.orig Mon Jul 2 14:05:09 2001
+++ linux/arch/alpha/kernel/time.c Mon Jul 2 15:47:45 2001
@@ -231,6 +231,49 @@
outb(0x13, 0x42);
}
+/*
+ * Calibrate CPU clock using legacy 8254 timer/counter. Stolen from
+ * arch/i386/time.c.
+ */
+
+#define CALIBRATE_DIVISOR 0x
+
+static unsigned long __init
+calibrate_cc(void)
+{
+ unsigned int cc;
+ unsigned long count = 0;
+
+ /* Set the Gate high, disable speaker */
+ outb((inb(0x61) & ~0x02) | 0x01, 0x61);
+
+ /*
+ * Now let's take care of CTC channel 2
+ *
+ * Set the Gate high, program CTC channel 2 for mode 0,
+ * (interrupt on terminal count mode), binary count,
+ * load maximum divisor we can get for accuracy - 65535
+ */
+
+ outb(0xb0, 0x43); /* binary, mode 0, LSB/MSB, Ch 2 */
+ outb(CALIBRATE_DIVISOR & 0xff, 0x42); /* LSB of count */
+ outb(CALIBRATE_DIVISOR >> 8, 0x42); /* MSB of count */
+
+ /* we still should not hang if timer not runing or N/A */
+ for (cc = rpcc(); (inb(0x61) & 0x20) == 0 && !(count >> 32); count++);
+
+ /* cycles delta */
+ cc = rpcc() - cc;
+
+ /* check for the reliable result */
+ if ((count < 1) || (count >> 32))
+ return 0;
+
+ /* and the final result in HZ */
+ return ((unsigned long)cc * CLOCK_TICK_RATE) / CALIBRATE_DIVISOR;
+}
+
+
void
time_init(void)
{
@@ -239,6 +282,10 @@
unsigned long cycle_freq, ppm_error;
long diff;
+ /* Calibrate CPU clock using CTC. If this fails, use RTC. */
+ if (!est_cycle_freq)
+ est_cycle_freq = calibrate_cc();
+
/*
* The Linux interpretation of the CMOS clock register contents:
* When the Update-In-Progress (UIP) flag goes from 1 to 0, the
linux-2.2.x.rtc.patch
Re: about kmap_high function
Stephen C. Tweedie writes: > kmap_high is intended to be called routinely for access to highmem > pages. It is coded to be as fast as possible as a result. TLB > flushes are expensive, especially on SMP, so kmap_high tries hard to > avoid unnecessary flushes. The code assumes that flushing a single TLB entry is expensive on SMP, while flushing the whole TLB is relatively cheap - certainly cheaper than flushing several individual entries. And that assumption is of course true on i386. On PPC it is a bit different. Flushing a single TLB entry is relatively cheap - the hardware broadcasts the TLB invalidation on the bus (in most implementations) so there are no cross-calls required. But flushing the whole TLB is expensive because we (strictly speaking) have to flush the whole of the MMU hash table as well. The MMU gets its PTEs from a hash table (which can be very large) and we use the hash table as a kind of level-2 cache of PTEs, which means that the flush_tlb_* routines have to flush entries from the MMU hash table as well. The hash table can store PTEs from many contexts, so it can have a lot of PTEs in it at any given time. So flushing the whole TLB would imply going through every single entry in the hash table and clearing it. In fact, currently we cheat - flush_tlb_all actually only flushes the kernel portion of the address space, which is all that is required in the three places where flush_tlb_all is called at the moment. This is not a criticism, rather a request that we expand the interfaces so that the architecture-specific code can make the decisions about when and how to flush TLB entries. For example, I would like to get rid of flush_tlb_all and define a flush_tlb_kernel_range instead. In all the places where flush_tlb_all is currently used, we do actually know the range of addresses which are affected, and having that information would let us do things a lot more efficiently on PPC. On other platforms we could define flush_tlb_kernel_range to just flush the whole TLB, or whatever. Note that there is already a flush_tlb_range which could be used, but some architectures assume that it is only used on user addresses. Regards, Paul. - 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: RFC: modules and 2.5
On Tue, Jul 03, 2001 at 01:13:45AM -0400, Jeff Garzik wrote: > A couple things that would be nice for 2.5 is > - let MOD_INC_USE_COUNT work even when module is built into kernel, and > - let THIS_MODULE exist and be valid even when module is built into > kernel I have something similar that I have wanted for a long time, and it would accomplish what you want too. I would like for the .o files for modules and compiled in drivers to be identical. It seems like this would be better for testing because it should eleminate module vs non-module bugs. We might even want them to show up in /proc/modules, perhaps with some mechinism to keep the reference count from going to 0. I dont think I would want to unleash it on an end user, but if you omit the part about letting the reference count go to zero, it should even be possible to unload a compiled in driver and replace it with a new module. If you did not load each module into its own section, you would have to leak its text and data memory, but this still might be useful for development. Anyway, just some ideas I have been wanting to share for about 5 years. Thanks for giving me an excuse. Jim - 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: [RFC] I/O Access Abstractions
> I'm more concerned about having all that space mapped permanently in > kernel virtual space. I'd prefer mapping on-demand, and that would > require a specific ioremap for IOs. I have no problem with the idea of a function to indicate which I/O maps you are and are not using. But passing resource structs around is way too heavy Alan - 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: [RFC] I/O Access Abstractions
> For example, one board I've got doesn't allow you to do a straight > memory-mapped I/O access to your PCI device directly, but have to reposition a > window in the CPU's memory space over part of the PCI memory space first, and > then hold a spinlock whilst you do it. What does this prove. PA-RISC has this problem in reverse for I/O cycle access to PCI slots on hppa1.1 at least. Cookies work _fine_ And by the time you are taking a spinlock who cares about the add, you can do that while the bus transactions for the atomic op are completing On the other hand each call, each push of resource * pointers costs real clocks on x86 - 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/
