[uPATCH] cross-compile scripts/lxdialog/ on AIX
AIX curses.h defines macros 'clear_screen' and 'color_names' but does
not define 'scroll()'.
Signed-Off-By: Peter Samuelson <[EMAIL PROTECTED]>
diff -urN 2.6.11-rc5/scripts/lxdialog/checklist.c.old
2.6.11-rc5/scripts/lxdialog/checklist.c
--- 2.6.11-rc5/scripts/lxdialog/checklist.c.old 2005-02-27 00:49:00.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/checklist.c 2005-02-27 01:01:17.0
-0600
@@ -269,7 +269,7 @@
status[scroll + max_choice - 1],
max_choice - 1, FALSE);
scrollok (list, TRUE);
- scroll (list);
+ wscrl (list, 1);
scrollok (list, FALSE);
}
scroll++;
diff -urN 2.6.11-rc5/scripts/lxdialog/colors.h.old
2.6.11-rc5/scripts/lxdialog/colors.h
--- 2.6.11-rc5/scripts/lxdialog/colors.h.old2004-02-03 21:43:07.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/colors.h2005-02-27 01:45:28.0
-0600
@@ -152,10 +152,4 @@
* Global variables
*/
-typedef struct {
-char name[COLOR_NAME_LEN];
-int value;
-} color_names_st;
-
-extern color_names_st color_names[];
extern int color_table[][3];
diff -urN 2.6.11-rc5/scripts/lxdialog/lxdialog.c.old
2.6.11-rc5/scripts/lxdialog/lxdialog.c
--- 2.6.11-rc5/scripts/lxdialog/lxdialog.c.old 2004-02-03 21:43:57.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/lxdialog.c 2005-02-27 01:31:11.0
-0600
@@ -56,7 +56,7 @@
int
main (int argc, const char * const * argv)
{
-int offset = 0, clear_screen = 0, end_common_opts = 0, retval;
+int offset = 0, opt_clear = 0, end_common_opts = 0, retval;
const char *title = NULL;
#ifdef LOCALE
@@ -89,7 +89,7 @@
offset += 2;
}
} else if (!strcmp (argv[offset + 1], "--clear")) {
- if (clear_screen) { /* Hey, "--clear" can't appear twice! */
+ if (opt_clear) {/* Hey, "--clear" can't appear twice! */
Usage (argv[0]);
exit (-1);
} else if (argc == 2) { /* we only want to clear the screen */
@@ -98,7 +98,7 @@
end_dialog ();
return 0;
} else {
- clear_screen = 1;
+ opt_clear = 1;
offset++;
}
} else /* no more common options */
@@ -127,7 +127,7 @@
init_dialog ();
retval = (*(modePtr->jumper)) (title, argc - offset, argv + offset);
-if (clear_screen) {/* clear screen before exit */
+if (opt_clear) { /* clear screen before exit */
attr_clear (stdscr, LINES, COLS, screen_attr);
refresh ();
}
diff -urN 2.6.11-rc5/scripts/lxdialog/menubox.c.old
2.6.11-rc5/scripts/lxdialog/menubox.c
--- 2.6.11-rc5/scripts/lxdialog/menubox.c.old 2005-02-27 00:23:54.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/menubox.c 2005-02-27 01:32:08.0
-0600
@@ -327,7 +327,7 @@
) {
/* Scroll menu up */
scrollok (menu, TRUE);
-scroll (menu);
+ wscrl (menu, 1);
scrollok (menu, FALSE);
scroll++;
@@ -357,7 +357,7 @@
for (i=0; (i < max_choice); i++) {
if (scroll+max_choice < item_no) {
scrollok (menu, TRUE);
- scroll(menu);
+ wscrl (menu, 1);
scrollok (menu, FALSE);
scroll++;
print_item (menu, items[(scroll+max_choice-1)*2+1],
signature.asc
Description: Digital signature
Re: ALPS tapping disabled. WHY?
On Thu, Feb 24, 2005 at 10:08:15PM -0500, Dmitry Torokhov wrote: > > So now, can anyone explain what bit 3 of param[0] does, and why you would > > want to disable hardware tapping support when it's set? My pad (ALPS > > 56AAA1760C on a Sager NP8560V) has always worked with hardware tapping as a > > plain PS/2 mouse, no special ALPS support req'd. > > > > Can this disabling of hardware tapping support be made optional (boot time > > param or other)? I don't want to have to patch every kernel from here on > > out. > > > > It still should do software tap emulation (although support is a bit flakey > with ALPS I must admit, but there are patches that should improve it) - so > people who don't like tapping can deactivate it. > > Anyway, "psmouse.proto=exps" boot option should disable ALPS native mode and > restore previous behavior. Also, in my tree currently (and planned for 2.6.12) hardware tapping is enabled again, because double taps don't work otherwise (hardware limitation). -- Vojtech Pavlik SuSE Labs, SuSE CR - 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 2.6.11-rc3 10/11] ide: make ide_cmd_ioctl() use TASKFILE
For what it's worth... Some vendor-specific commands on PATA devices require -exact- specification of registers in, and registers out. You never want to read more registers than are flagged. Ditto for write. Jeff - 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: Invalid module format in Fedora core2
linux-os wrote: I attached a typical makefile so you can see how complicated this new crap is. In the meantime, you can just take this and link it with your "module.o" to make a "module.ko". What is all this stuff for? Unless you are doing some pretty bizarre things in your module this is far more complex than it needs to be. See: http://linuxdevices.com/articles/AT4389927951.html Given your previous posts on this issue I can't help but think you'd be better off reading how this can be done simply, rather than whining about the "political correctness" of the build process.. - 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 ide-dev 8/9] make ide_task_ioctl() use REQ_DRIVE_TASKFILE
Hello, Bartlomiej.
This patch should be modified to use flagged taskfile if the
task_end_request_fix patch isn't applied. As non-flagged taskfile
won't return valid result registers, TASK ioctl users won't get the
correct register output.
IMHO, this flag-to-get-result-registers thing is way too subtle. How
about keeping old behavior by just not copying out register outputs in
ide_taskfile_ioctl() in applicable cases instead of not reading
registers when ending commands? That is, unless there's some
noticeable performance impacts I'm not aware of.
Thanks.
On Thu, Feb 24, 2005 at 03:48:33PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> ide_task_ioctl() rewritten to use taskfile transport.
> This is the last user of REQ_DRIVE_TASK.
>
> bart: ported to recent IDE changes by me
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>
> diff -Nru a/drivers/ide/ide-taskfile.c b/drivers/ide/ide-taskfile.c
> --- a/drivers/ide/ide-taskfile.c 2005-02-24 15:30:02 +01:00
> +++ b/drivers/ide/ide-taskfile.c 2005-02-24 15:30:02 +01:00
> @@ -777,30 +777,42 @@
> return err;
> }
>
> -static int ide_wait_cmd_task(ide_drive_t *drive, u8 *buf)
> -{
> - struct request rq;
> -
> - ide_init_drive_cmd(&rq);
> - rq.flags = REQ_DRIVE_TASK;
> - rq.buffer = buf;
> - return ide_do_drive_cmd(drive, &rq, ide_wait);
> -}
> -
> -/*
> - * FIXME : this needs to map into at taskfile. <[EMAIL PROTECTED]>
> - */
> -int ide_task_ioctl (ide_drive_t *drive, unsigned int cmd, unsigned long arg)
> +int ide_task_ioctl(ide_drive_t *drive, unsigned int cmd, unsigned long arg)
> {
> void __user *p = (void __user *)arg;
> - int err = 0;
> - u8 args[7], *argbuf = args;
> - int argsize = 7;
> + int err;
> + u8 args[7];
> + ide_task_t task;
> + struct ata_taskfile *tf = &task.tf;
>
> if (copy_from_user(args, p, 7))
> return -EFAULT;
> - err = ide_wait_cmd_task(drive, argbuf);
> - if (copy_to_user(p, argbuf, argsize))
> +
> + memset(&task, 0, sizeof(task));
> +
> + tf->command = args[0];
> + tf->feature = args[1];
> + tf->nsect = args[2];
> + tf->lbal= args[3];
> + tf->lbam= args[4];
> + tf->lbah= args[5];
> + tf->device = args[6];
> +
> + task.command_type = IDE_DRIVE_TASK_NO_DATA;
> + task.data_phase = TASKFILE_NO_DATA;
> + task.handler = &task_no_data_intr;
> +
> + err = ide_diag_taskfile(drive, &task, 0, NULL);
> +
> + args[0] = tf->command;
> + args[1] = tf->feature;
> + args[2] = tf->nsect;
> + args[3] = tf->lbal;
> + args[4] = tf->lbam;
> + args[5] = tf->lbah;
> + args[6] = tf->device;
> +
> + if (copy_to_user(p, args, 7))
> err = -EFAULT;
> return err;
> }
--
tejun
-
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/
ext3 bug
Hi, Looks like I ran into an ext3 bug (or at least the log says so). I got a bunch of messages like: ext3_free_blocks_sb: aborting transaction: Journal has aborted in __ext3_journal_get_undo_access<2>EXT3-fs error (device sda2) in ext3_free_blocks_sb: Journal has aborted EXT3-fs error (device sda2): ext3_free_blocks: Freeing blocks in system zones -Block = 228, count = 1 It happened while I was doing an "rm -rf" on a directory. The "rm" gave a segfault and now I can't unmount the filesystem: unmount says "device is busy", even though lsof reports nothing. The filesystem is on a USB hard disk. The actual dump is in attachment. I'm running Debian unstable with a custom 2.6.10 kernel on a 1.6 GHz Pentium-M. Jean-Marc -- Jean-Marc Valin <[EMAIL PROTECTED]> Université de Sherbrooke Feb 27 01:15:48 idefix kernel: [ cut here ] Feb 27 01:15:48 idefix kernel: PREEMPT Feb 27 01:15:48 idefix kernel: Modules linked in: msdos sd_mod udf isofs sr_mod usb_storage scsi_mod joydev usbhid appletalk ax25 ipx radeon ipt_state iptable_filter iptable_mangle iptable_nat ip_conntrack ip_tables ipv6 orinoco_cs orinoco hermes pcmcia lp binfmt_misc af_packet parport_pc parport uhci_hcd pci_hotplug intel_agp agpgart yenta_socket pcmcia_core tg3 snd_intel8x0 snd_ac97_codec ehci_hcd usbcore nls_iso8859_1 nls_cp437 vfat fat ppp_async ppp_generic slhc crc_ccitt snd_pcm_oss tsdev evdev snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd soundcore psmouse thermal fan button ac battery cpufreq_ondemand cpufreq_powersave speedstep_centrino freq_table processor Feb 27 01:15:48 idefix kernel: CPU:0 Feb 27 01:15:48 idefix kernel: EIP:0060:[]Not tainted VLI Feb 27 01:15:48 idefix kernel: EFLAGS: 00210286 (2.6.10) Feb 27 01:15:48 idefix kernel: EIP is at journal_forget+0x1d0/0x220 Feb 27 01:15:48 idefix kernel: eax: 005f ebx: d1f1c000 ecx: b032c7cc edx: b032c7cc Feb 27 01:15:48 idefix kernel: esi: b8932d48 edi: bb2ad41c ebp: dd668080 esp: d1f1dda0 Feb 27 01:15:48 idefix kernel: ds: 007b es: 007b ss: 0068 Feb 27 01:15:48 idefix kernel: Process rm (pid: 10370, threadinfo=d1f1c000 task=c97f49e0) Feb 27 01:15:48 idefix kernel: Stack: b02f67e0 b02e1027 b02f445b 04ca b02f4571 be0a5aac b8932d48 Feb 27 01:15:48 idefix kernel:dfc002b8 b019c940 dfc002b8 b8932d48 e73d7980 b275f400 b8932d48 0006 Feb 27 01:15:48 idefix kernel:b0aeb448 dfc002b8 be0a5aac b019f028 dfc002b8 be0a5aac b8932d48 Feb 27 01:15:48 idefix kernel: Call Trace: Feb 27 01:15:48 idefix kernel: [] ext3_forget+0xf0/0x100 Feb 27 01:15:48 idefix kernel: [] ext3_clear_blocks+0x118/0x170 Feb 27 01:15:48 idefix kernel: [] ext3_free_data+0x98/0x150 Feb 27 01:15:48 idefix kernel: [] ext3_free_branches+0xec/0x270 Feb 27 01:15:48 idefix kernel: [] ext3_truncate+0x46b/0x5d0 Feb 27 01:15:48 idefix kernel: [] ext3_mark_iloc_dirty+0x28/0x40 Feb 27 01:15:48 idefix kernel: [] journal_start+0xad/0xe0 Feb 27 01:15:48 idefix kernel: [] __ext3_journal_stop+0x24/0x50 Feb 27 01:15:48 idefix kernel: [] start_transaction+0x29/0x70 Feb 27 01:15:48 idefix kernel: [] ext3_delete_inode+0xc8/0x100 Feb 27 01:15:48 idefix kernel: [] ext3_delete_inode+0x0/0x100 Feb 27 01:15:48 idefix kernel: [] generic_delete_inode+0xa5/0x170 Feb 27 01:15:48 idefix kernel: [] iput+0x63/0x90 Feb 27 01:15:48 idefix kernel: [] sys_unlink+0xd7/0x150 Feb 27 01:15:48 idefix kernel: [] sys_getdents64+0xa0/0xaa Feb 27 01:15:48 idefix kernel: [] filldir64+0x0/0x100 Feb 27 01:15:48 idefix kernel: [] syscall_call+0x7/0xb Feb 27 01:15:48 idefix kernel: Code: 2f b0 b8 71 45 2f b0 89 44 24 10 b8 ca 04 00 00 89 44 24 0c b8 5b 44 2f b0 89 44 24 08 b8 27 10 2e b0 89 44 24 04 e8 c0 a6 f6 ff <0f> 0b ca 04 5b 44 2f b0 e9 4d ff ff ff c7 04 24 e0 67 2f b0 b8 Feb 27 01:15:48 idefix kernel: <6>note: rm[10370] exited with preempt_count 2 Feb 27 01:15:48 idefix kernel: [] schedule+0x532/0x540 Feb 27 01:15:48 idefix kernel: [] unmap_page_range+0x53/0x80 Feb 27 01:15:48 idefix kernel: [] unmap_vmas+0x1b6/0x1d0 Feb 27 01:15:48 idefix kernel: [] exit_mmap+0x7d/0x160 Feb 27 01:15:48 idefix kernel: [] mmput+0x37/0xa0 Feb 27 01:15:48 idefix kernel: [] do_exit+0x16f/0x470 Feb 27 01:15:48 idefix kernel: [] do_invalid_op+0x0/0xd0 Feb 27 01:15:48 idefix kernel: [] die+0x18b/0x190 Feb 27 01:15:48 idefix kernel: [] do_invalid_op+0xb2/0xd0 Feb 27 01:15:48 idefix kernel: [] journal_forget+0x1d0/0x220 Feb 27 01:15:48 idefix kernel: [] __wake_up_common+0x41/0x70 Feb 27 01:15:48 idefix kernel: [] release_console_sem+0xbf/0xd0 Feb 27 01:15:48 idefix kernel: [] error_code+0x2b/0x30 Feb 27 01:15:48 idefix kernel: [] journal_forget+0x1d0/0x220 Feb 27 01:15:48 idefix kernel: [] ext3_forget+0xf0/0x100 Feb 27 01:15:48 idefix kernel: [] ext3_clear_blocks+0x118/0x170 Feb 27 01:15:48 idefix kernel: [] ext3_free_data+0x98/0x150 Feb 27 01:15:48 idefix kernel: [] ext3_free_branches+0xec/0x270 Feb 27 01:15:48 idefix kernel: [] ex
Re: [PATCH 2.6.11-rc3 10/11] ide: make ide_cmd_ioctl() use TASKFILE
Hello, Bartlomiej. On Thu, Feb 24, 2005 at 04:50:39PM +0100, Bartlomiej Zolnierkiewicz wrote: > > + in_valid->b.status_command = 1; > > + in_valid->b.error_feature = 1; > > + in_valid->b.nsector = 1; > > ide_end_drive_cmd() must be fixed first to respect ->tf_in_flags > and it must be done *without* affecting HDIO_DRIVE_TASKFILE. Hmmm... does it make any difference other than reading more registers? Are you worried about performance impacts? Is there hardware which acts differently if more registers are read? > > > extern int ide_driveid_update(ide_drive_t *); > > -extern int ide_ata66_check(ide_drive_t *, ide_task_t *); > > +int ide_ata66_check(ide_drive_t *, ide_task_t *); > > extern int ide_config_drive_speed(ide_drive_t *, u8); > > extern u8 eighty_ninty_three (ide_drive_t *); > > -extern int set_transfer(ide_drive_t *, ide_task_t *); > > +int set_transfer(ide_drive_t *, ide_task_t *); > > extern int taskfile_lib_get_identify(ide_drive_t *drive, u8 *); > > leftovers from previous version of the patch Yeah, sorry. Thanks. -- tejun - 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 2.6.11-rc3 01/11] ide: task_end_request() fix
On Thu, Feb 24, 2005 at 04:58:03PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thu, 10 Feb 2005 17:38:14 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> >
> > 01_ide_task_end_request_fix.patch
> >
> > task_end_request() modified to always call ide_end_drive_cmd()
> > for taskfile requests. Previously, ide_end_drive_cmd() was
> > called only when task->tf_out_flags.all was set. Also,
> > ide_dma_intr() is modified to use task_end_request().
> >
> > * fixes taskfile ioctl oops bug which was caused by referencing
> > NULL rq->rq_disk of taskfile requests.
>
> I fixed it in slightly different way in ide-dev-2.6 - by calling
> ide_end_request() instead of ->end_request().
Taskfile DMA path is still broken. Also calling ide_end_request()
will work there, but IMHO it's just cleaner to finish special commands
inside ide_end_drive_cmd(). Currently,
* Successful flagged taskfile -> ide_end_drive_cmd()
* All other successful non-DMA special cmds-> ide_end_request()
* Successful DMA taskfile -> segfault
* All failed special cmds -> ide_end_drive_cmd()
It just shouldn't be like this. :-(
>
> > * enables TASKFILE ioctls to get valid register outputs on
> > successful completion.
>
> This change makes *all* taskfile registers to be read on completion
> of *any* command. Currently this is done only for flagged taskfiles
> and commands using no-data protocol.
>
> With all your changes it will be also done for:
> * HDIO_DRIVE_[TASKFILE,CMD] ioctls
> * /proc/ide/hd?/{identify,smart_thresholds,smart_values}
> but reading back all registers is not always needed.
None is on a hot path or even near to one, but maybe I don't have
enough experience with old hardware. Are there some old hardware
which make the additional reads stand out?
> It is already bad enough (and we can't fix it cause it is exported
> to user-space through HDIO_DRIVE_TASKFILE), we shouldn't
> make it worse.
Yeah, the whole IDE ioctl interface seems disturbingly messy. :-(
* Register output is available only if
1. The command fails.
2. The command is a flagged taskfile.
* taskfile->device_head is used regardless of outflags setting.
* In flagged taskfile, taskfile->device_head can turn on the device
bit, so we can issue commands to hdb with permissions to hda.
* In TASK and TASKFILE, LBA commands can be issued to drives in CHS
mode but the reverse isn't true. However, in TASKFILE, if the
command isn't flagged, the lower nibble of device register is
zeroed depending on addressing setting.
* taskfile->data endianess is reversed on big endian machines.
* ide_reg_valid_t endianess issue.
* And, none of above is documented.
So, I don't know. Do you think we should keep all of the above
behaviors? Please let me know; then, I'll update ioctl/hdio.txt so
that people can at least know these gotchas.
Thanks.
--
tejun
-
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: ALPS touchpad not seen by 2.6.11 kernels
On Saturday 26 February 2005 17:55, Frank Victor Fischer wrote:
> I have had the same problem and the solution worked for me as well.
>
> Where should I put the DSDT?
>
> Please reply to my e-mail, as I am no linux-kernel subscriber.
Thanks for DSDT! Could you please try the follwing patch?
Andrew, if this works I'd like to see it in 2.6.11...
Vojtech, I will send you patch for PNP shortly after.
--
Dmitry
=
Input: add more PNP IDs to i8042 driver.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
= drivers/input/serio/i8042-x86ia64io.h 1.2 vs edited =
--- 1.2/drivers/input/serio/i8042-x86ia64io.h 2004-10-19 05:58:22 -05:00
+++ edited/drivers/input/serio/i8042-x86ia64io.h2005-02-27 01:27:58
-05:00
@@ -224,7 +224,7 @@
static struct acpi_driver i8042_acpi_aux_driver = {
.name = "i8042",
- .ids= "PNP0F13,SYN0801",
+ .ids= "PNP0F03,PNP0F0B,PNP0F0E,PNP0F12,PNP0F13,SYN0801",
.ops= {
.add= i8042_acpi_aux_add,
},
-
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/
BUG_* broken since 2.6.11-rc1 ...
Hi Folks!
couldn't believe it when I discovered that BUG_ON()
and friends is broken (at least on x86) ...
(while it was definitely working with 2.6.10 ;)
the following 'patch':
--- ./init/main.c.orig Thu Feb 17 19:25:21 2005
+++ ./init/main.c Sun Feb 27 05:13:45 2005
@@ -684,6 +684,8 @@ static int init(void * unused)
* trying to recover a really broken machine.
*/
+ BUG_ON(0==0);
+
if (execute_command)
run_init_process(execute_command);
results in this oops:
(look at the filename and linenumber ;)
Freeing unused kernel memory: 244k freed
[ cut here ]
kernel BUG at :9377!
invalid operand: [#1]
PREEMPT SMP
Modules linked in:
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010296 (2.6.11-rc1)
EIP is at init+0xf5/0x1a0
eax: 0002 ebx: c04ed91c ecx: 0001 edx: 0001
esi: edi: ebp: esp: c2113fdc
ds: 007b es: 007b ss: 0068
Process swapper (pid: 1, threadinfo=c2113000 task=c2114a80)
Stack: 0002 c0100320 c0101375
Call Trace:
[] init+0x0/0x1a0
[] kernel_thread_helper+0x5/0x10
Code: 00 00 89 54 24 08 89 44 24 04 e8 97 f8 05 00 85 c0 78 6d c7 04 24 00 00 0
<0>Kernel panic - not syncing: Attempted to kill init!
this is still true/valid for 2.6.11-rc5 ...
best,
Herbert
-
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/
SELinux and sysfs
Perhaps in future, maybe SELinux could take advantage of sysfs to modify some policies? Is this doable? Sure, we still need some flat files for static configurations, but what about dynamic ones? Shawn. - 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 ide-dev 4/9] add ide_task_init_flush() helper
Hello,
Just one minor thing. Doesn't moving ide_task_s upward belong to
patch #7?
On Thu, Feb 24, 2005 at 03:41:06PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> * add ide_task_init_flush() helper
> * use it in do_idedisk_cacheflush() and ide_start_power_step()
> * inline do_idedisk_cacheflush() into ide_cacheflush_p()
>
> diff -Nru a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
> --- a/drivers/ide/ide-disk.c 2005-02-19 17:22:58 +01:00
> +++ b/drivers/ide/ide-disk.c 2005-02-19 17:22:58 +01:00
> @@ -723,24 +723,6 @@
> return 0;
> }
>
> -static int do_idedisk_flushcache (ide_drive_t *drive)
> -{
> - ide_task_t args;
> - struct ata_taskfile *tf = &args.tf;
> -
> - memset(&args, 0, sizeof(ide_task_t));
> -
> - if (ide_id_has_flush_cache_ext(drive->id)) {
> - tf->command = WIN_FLUSH_CACHE_EXT;
> - tf->flags |= ATA_TFLAG_LBA48;
> - } else
> - tf->command = WIN_FLUSH_CACHE;
> -
> - args.command_type = IDE_DRIVE_TASK_NO_DATA;
> - args.handler= &task_no_data_intr;
> - return ide_raw_taskfile(drive, &args, NULL);
> -}
> -
> static int set_acoustic (ide_drive_t *drive, int arg)
> {
> ide_task_t args;
> @@ -931,10 +913,14 @@
>
> static void ide_cacheflush_p(ide_drive_t *drive)
> {
> + ide_task_t task;
> +
> if (!drive->wcache || !ide_id_has_flush_cache(drive->id))
> return;
>
> - if (do_idedisk_flushcache(drive))
> + ide_task_init_flush(drive, &task);
> +
> + if (ide_raw_taskfile(drive, &task, NULL))
> printk(KERN_INFO "%s: wcache flush failed!\n", drive->name);
> }
>
> diff -Nru a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
> --- a/drivers/ide/ide-io.c2005-02-19 17:22:58 +01:00
> +++ b/drivers/ide/ide-io.c2005-02-19 17:22:58 +01:00
> @@ -55,6 +55,24 @@
> #include
> #include
>
> +void ide_task_init_flush(ide_drive_t *drive, ide_task_t *task)
> +{
> + struct ata_taskfile *tf = &task->tf;
> +
> + memset(task, 0, sizeof(*task));
> +
> + if (ide_id_has_flush_cache_ext(drive->id)) {
> + tf->command = WIN_FLUSH_CACHE_EXT;
> + tf->flags |= ATA_TFLAG_LBA48;
> + } else
> + tf->command = WIN_FLUSH_CACHE;
> +
> + task->command_type = IDE_DRIVE_TASK_NO_DATA;
> + task->handler = &task_no_data_intr;
> +}
> +
> +EXPORT_SYMBOL_GPL(ide_task_init_flush);
> +
> static void ide_fill_flush_cmd(ide_drive_t *drive, struct request *rq)
> {
> char *buf = rq->cmd;
> @@ -247,14 +265,8 @@
> return ide_stopped;
> }
>
> - if (ide_id_has_flush_cache_ext(drive->id)) {
> - tf->command = WIN_FLUSH_CACHE_EXT;
> - tf->flags |= ATA_TFLAG_LBA48;
> - } else
> - tf->command = WIN_FLUSH_CACHE;
> + ide_task_init_flush(drive, args);
>
> - args->command_type = IDE_DRIVE_TASK_NO_DATA;
> - args->handler = &task_no_data_intr;
> return do_rw_taskfile(drive, args);
>
> case idedisk_pm_standby:/* Suspend step 2 (standby) */
> diff -Nru a/include/linux/ide.h b/include/linux/ide.h
> --- a/include/linux/ide.h 2005-02-19 17:22:58 +01:00
> +++ b/include/linux/ide.h 2005-02-19 17:22:58 +01:00
> @@ -924,6 +924,19 @@
> typedef ide_startstop_t (ide_handler_t)(ide_drive_t *);
> typedef int (ide_expiry_t)(ide_drive_t *);
>
> +typedef struct ide_task_s {
> + struct ata_taskfile tf;
> + u16 data;
> + ide_reg_valid_t tf_out_flags;
> + ide_reg_valid_t tf_in_flags;
> + int data_phase;
> + int command_type;
> + ide_pre_handler_t *prehandler;
> + ide_handler_t *handler;
> + struct request *rq;/* copy of request */
> + void*special; /* valid_t generally */
> +} ide_task_t;
> +
> typedef struct hwgroup_s {
> /* irq handler, if active */
> ide_startstop_t (*handler)(ide_drive_t *);
> @@ -1189,6 +1202,8 @@
> */
> extern void ide_init_drive_cmd (struct request *rq);
>
> +void ide_task_init_flush(ide_drive_t *, ide_task_t *);
> +
> u64 ide_tf_get_address(struct ata_taskfile *);
>
> /*
> @@ -1250,19 +1265,6 @@
> * (ide_drive_t *drive, u8 cmd, u8 nsect, u8 feature, u8 sectors, u8 *buf)
> */
> extern int ide_wait_cmd(ide_drive_t *, u8, u8, u8, u8, u8 *);
> -
> -typedef struct ide_task_s {
> - struct ata_taskfile tf;
> - u16 data;
> - ide_reg_valid_t tf_out_flags;
> - ide_reg_valid_t tf_in_flags;
> - int data_phase;
> - int command_type;
> - ide_pre_handler_t *prehandler;
> - ide_handler_t *handler;
> - struct request *rq;/* copy of request */
> -
Re: [patch ide-dev 1/9] use struct ata_taskfile in ide_task_t
Hello, Bartlomiej.
Neat patch. Codes look much better now. :-)
On Thu, Feb 24, 2005 at 03:36:44PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> * use struct ata_taskfile instead of .flags,
> .tfRegister[] and .hobRegister[] in ide_task_t
> * add #ifndef __KERNEL__ around definitions of {task,hob}_struct_t
> * don't set write-only .hobRegister[6] and .hobRegister[7]
> in idedisk_set_max_address_ext()
> * remove no longer needed IDE_CONTROL_OFFSET_HOB define
>
> diff -Nru a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
> --- a/drivers/ide/ide-disk.c 2005-02-17 23:38:30 +01:00
> +++ b/drivers/ide/ide-disk.c 2005-02-17 23:38:30 +01:00
> @@ -328,23 +328,24 @@
> static unsigned long idedisk_read_native_max_address(ide_drive_t *drive)
> {
> ide_task_t args;
> + struct ata_taskfile *tf = &args.tf;
> unsigned long addr = 0;
>
> /* Create IDE/ATA command request structure */
> memset(&args, 0, sizeof(ide_task_t));
> - args.tfRegister[IDE_SELECT_OFFSET] = 0x40;
> - args.tfRegister[IDE_COMMAND_OFFSET] = WIN_READ_NATIVE_MAX;
> +
> + tf->device = 0x40;
Wouldn't ATA_LBA be clearer?
> + tf->command = WIN_READ_NATIVE_MAX;
> +
> args.command_type = IDE_DRIVE_TASK_NO_DATA;
> args.handler= &task_no_data_intr;
> /* submit command request */
> ide_raw_taskfile(drive, &args, NULL);
>
> /* if OK, compute maximum address value */
> - if ((args.tfRegister[IDE_STATUS_OFFSET] & 0x01) == 0) {
> - addr = ((args.tfRegister[IDE_SELECT_OFFSET] & 0x0f) << 24)
> - | ((args.tfRegister[ IDE_HCYL_OFFSET] ) << 16)
> - | ((args.tfRegister[ IDE_LCYL_OFFSET] ) << 8)
> - | ((args.tfRegister[IDE_SECTOR_OFFSET] ));
> + if ((tf->command & 1) == 0) {
> + addr = ((tf->device & 0xf) << 24) |
> +(tf->lbah << 16) | (tf->lbam << 8) | tf->lbal;
> addr++; /* since the return value is (maxlba - 1), we add 1 */
> }
> return addr;
> @@ -353,29 +354,27 @@
> static unsigned long long idedisk_read_native_max_address_ext(ide_drive_t
> *drive)
> {
> ide_task_t args;
> + struct ata_taskfile *tf = &args.tf;
> unsigned long long addr = 0;
>
> /* Create IDE/ATA command request structure */
> memset(&args, 0, sizeof(ide_task_t));
>
> - args.tfRegister[IDE_SELECT_OFFSET] = 0x40;
> - args.tfRegister[IDE_COMMAND_OFFSET] = WIN_READ_NATIVE_MAX_EXT;
> + tf->device = 0x40;
Ditto.
> + tf->command = WIN_READ_NATIVE_MAX_EXT;
> +
> args.command_type = IDE_DRIVE_TASK_NO_DATA;
> args.handler= &task_no_data_intr;
>
> - args.flags |= ATA_TFLAG_LBA48;
> + tf->flags |= ATA_TFLAG_LBA48;
>
> /* submit command request */
> ide_raw_taskfile(drive, &args, NULL);
>
> /* if OK, compute maximum address value */
> - if ((args.tfRegister[IDE_STATUS_OFFSET] & 0x01) == 0) {
> - u32 high = (args.hobRegister[IDE_HCYL_OFFSET] << 16) |
> -(args.hobRegister[IDE_LCYL_OFFSET] << 8) |
> - args.hobRegister[IDE_SECTOR_OFFSET];
> - u32 low = ((args.tfRegister[IDE_HCYL_OFFSET])<<16) |
> -((args.tfRegister[IDE_LCYL_OFFSET])<<8) |
> - (args.tfRegister[IDE_SECTOR_OFFSET]);
> + if ((tf->command & 1) == 0) {
> + u32 high = (tf->hob_lbah << 16) | (tf->hob_lbam << 8) |
> tf->hob_lbal;
> + u32 low = (tf->lbah << 16) | (tf->lbam << 8) | tf->lbal;
> addr = ((__u64)high << 24) | low;
> addr++; /* since the return value is (maxlba - 1), we add 1 */
> }
> @@ -389,26 +388,27 @@
> static unsigned long idedisk_set_max_address(ide_drive_t *drive, unsigned
> long addr_req)
> {
> ide_task_t args;
> + struct ata_taskfile *tf = &args.tf;
> unsigned long addr_set = 0;
>
> addr_req--;
> /* Create IDE/ATA command request structure */
> memset(&args, 0, sizeof(ide_task_t));
> - args.tfRegister[IDE_SECTOR_OFFSET] = ((addr_req >> 0) & 0xff);
> - args.tfRegister[IDE_LCYL_OFFSET]= ((addr_req >> 8) & 0xff);
> - args.tfRegister[IDE_HCYL_OFFSET]= ((addr_req >> 16) & 0xff);
> - args.tfRegister[IDE_SELECT_OFFSET] = ((addr_req >> 24) & 0x0f) |
> 0x40;
> - args.tfRegister[IDE_COMMAND_OFFSET] = WIN_SET_MAX;
> +
> + tf->lbal= addr_req;
> + tf->lbam= addr_req >> 8;
> + tf->lbah= addr_req >> 16;
> + tf->device = ((addr_req >> 24) & 0xf) | 0x40;
Ditto.
> + tf->command = WIN_SET_MAX;
> +
> args.command_type = IDE_DRIVE_TASK_NO_DATA;
> args.handler= &task_no_data_intr;
> /* submit comman
Re: [patch ide-dev 7/9] convert disk flush functions to use REQ_DRIVE_TASKFILE
Hello, Bartlomiej,
On Thu, Feb 24, 2005 at 03:45:39PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> Original patch from Tejun Heo <[EMAIL PROTECTED]>,
> ported over recent IDE changes by me.
>
> * teach ide_tf_get_address() about CHS
IMHO, as patch #4 moves LBA/CHS selection into taskfile, I think
using taskfile->device to determine whether LBA or CHS is used instead
of drive->select makes more sense.
> * use ide_tf_get_address() and remove ide_get_error_location()
IIRC, error responses for WIN_FLUSH_CACHE is in CHS if the LBA bit in
the device register is zero; likewise, in LBA if the LBA bit is one.
I don't know if drives can change the LBA bit when posting error
result. The original code reads back the device register on error to
determine whether to interpret the error response in CHS or LBA.
(ATA/ATAPI-6 isn't clear on this issue. Is ATA/ATAPI-7 updated?)
This change combined with patch #2/#5 can make error address
calculation wrong on LBA28 drives. I think setting the LBA bit in the
device register according to the drive's addressing mode in
ide_task_init_flush() and use taskfile->device in ide_tf_get_address()
should fix the problem.
> * use ide_task_init_flush() and remove ide_fill_flush_cmd()
> * convert idedisk_issue_flush() to use REQ_DRIVE_TASKFILE.
> This and switching to ide_tf_get_address() removes
> a possible race condition between getting the failed
> sector number and other requests.
> * convert ide_queue_flush_cmd() to use REQ_DRIVE_TASKFILE
>
> By this change, when WIN_FLUSH_CACHE_EXT is used, full HOB
> registers are written and read. This isn't optimal but
> shouldn't be noticeable either.
>
> diff -Nru a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
> --- a/drivers/ide/ide-disk.c 2005-02-24 15:29:50 +01:00
> +++ b/drivers/ide/ide-disk.c 2005-02-24 15:29:50 +01:00
> @@ -349,7 +349,7 @@
>
> /* if OK, compute maximum address value */
> if ((tf->command & 1) == 0) {
> - addr = ide_tf_get_address(tf);
> + addr = ide_tf_get_address(drive, tf);
> addr++; /* since the return value is (maxlba - 1), we add 1 */
> }
> return addr;
> @@ -392,7 +392,7 @@
> ide_raw_taskfile(drive, &args, NULL);
> /* if OK, compute maximum address value */
> if ((tf->command & 1) == 0) {
> - addr_set = ide_tf_get_address(tf);
> + addr_set = ide_tf_get_address(drive, tf);
> addr_set++;
> }
> return addr_set;
> @@ -639,24 +639,18 @@
> {
> ide_drive_t *drive = q->queuedata;
> struct request *rq;
> + ide_task_t task;
> int ret;
>
> if (!drive->wcache)
> return 0;
>
> - rq = blk_get_request(q, WRITE, __GFP_WAIT);
> -
> - memset(rq->cmd, 0, sizeof(rq->cmd));
> -
> - if (ide_id_has_flush_cache_ext(drive->id) &&
> - (drive->capacity64 >= (1UL << 28)))
> - rq->cmd[0] = WIN_FLUSH_CACHE_EXT;
> - else
> - rq->cmd[0] = WIN_FLUSH_CACHE;
> + ide_task_init_flush(drive, &task);
>
> + rq = blk_get_request(q, WRITE, __GFP_WAIT);
>
> - rq->flags |= REQ_DRIVE_TASK | REQ_SOFTBARRIER;
> - rq->buffer = rq->cmd;
> + rq->flags |= REQ_DRIVE_TASKFILE | REQ_SOFTBARRIER;
> + rq->special = &task;
>
> ret = blk_execute_rq(q, disk, rq);
>
> @@ -664,7 +658,7 @@
>* if we failed and caller wants error offset, get it
>*/
> if (ret && error_sector)
> - *error_sector = ide_get_error_location(drive, rq->cmd);
> + *error_sector = ide_tf_get_address(drive, &task.tf);
>
> blk_put_request(rq);
> return ret;
> diff -Nru a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
> --- a/drivers/ide/ide-io.c2005-02-24 15:29:50 +01:00
> +++ b/drivers/ide/ide-io.c2005-02-24 15:29:50 +01:00
> @@ -74,24 +74,6 @@
>
> EXPORT_SYMBOL_GPL(ide_task_init_flush);
>
> -static void ide_fill_flush_cmd(ide_drive_t *drive, struct request *rq)
> -{
> - char *buf = rq->cmd;
> -
> - /*
> - * reuse cdb space for ata command
> - */
> - memset(buf, 0, sizeof(rq->cmd));
> -
> - rq->flags |= REQ_DRIVE_TASK | REQ_STARTED;
> - rq->buffer = buf;
> - rq->buffer[0] = WIN_FLUSH_CACHE;
> -
> - if (ide_id_has_flush_cache_ext(drive->id) &&
> - (drive->capacity64 >= (1UL << 28)))
> - rq->buffer[0] = WIN_FLUSH_CACHE_EXT;
> -}
> -
> /*
> * preempt pending requests, and store this cache flush for immediate
> * execution
> @@ -99,7 +81,9 @@
> static struct request *ide_queue_flush_cmd(ide_drive_t *drive,
> struct request *rq, int post)
> {
> - struct request *flush_rq = &HWGROUP(drive)->wrq;
> + ide_hwgroup_t *hwgroup = drive->hwif->hwgroup;
> + struct request *flush_rq = &hwgroup->flush_rq;
> + ide_task_t *task = &hwgroup->flush_task;
>
> /*
>* write cache disabled, clear the barrier bit and treat it like
> @@ -110,11 +94,14 @@
[PATCH] possible bug in i2c-algo-bit's inb function
Hi,
while writing a driver for a cardbus card which is supposed to use the
bit-banging algorithm I noticed that communication with the I2C slave
(Philips TDA10046) would fail without this patch. It forces SDA to high
for every bit in i2c_inb() instead of once per byte. Can this patch go
into the mainline kernel or will this break other drivers? I am using
Kernel version 2.6.10.
Signed-off-by: Andreas Oberritter <[EMAIL PROTECTED]>
--- linux-2.6/drivers/i2c/algos/i2c-algo-bit.c.orig 2005-02-27
04:39:33.663444536 +0100
+++ linux-2.6/drivers/i2c/algos/i2c-algo-bit.c 2005-02-27 04:39:54.978204200
+0100
@@ -197,8 +197,8 @@ static int i2c_inb(struct i2c_adapter *i
struct i2c_algo_bit_data *adap = i2c_adap->algo_data;
/* assert: scl is low */
- sdahi(adap);
for (i=0;i<8;i++) {
+ sdahi(adap);
if (sclhi(adap)<0) { /* timeout */
DEB2(printk(KERN_DEBUG " i2c_inb: timeout at bit
#%d\n", 7-i));
return -ETIMEDOUT;
-
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] orinoco rfmon
On Sat, Feb 26, 2005 at 10:10:15AM -0800, Eric Gaumer wrote: > Could anyone elaborate on the status of this patch? I've had 344 days of > uptime on a PPC > powerbook using it on 2.4.22 and about 3 months of solid use on 2.6. > > If the code looks problematic could someone point out possible deficiencies > so we can work > toward a satisfactory resolution? I didn't write the code but I'm willing > do what I have to > in order to get this (wireless scanning) into the official tree. This looks like the ancient version of the monitor patch - which includes importing a lot of needless junk from the linux-wlan-ng tree. A cleaned up version of monitor has been merged in the orinoco CVS tree for ages now, but unfortunately that's long overdue for a merge with mainline. I'm trying to get that merge done - I just don't have much time or energy for the orinoco driver these days. One stack of patches which gets part of the way went to Jeff Garzik last week. We'll see how we go. In the meantime go to http://savannah.nongnu.org/projects/orinoco for access to the driver CVS. You probably want to get the "for_linus" branch of CVS if you're planning to work with 2.6. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson signature.asc Description: Digital signature
Re: EBDA Question
Bukie Mabayoje wrote: In general, dropping the EBDA below 0x9a000 is probably a bad idea. Recent Linux kernels and boot loaders should handle it, though. Keep in mind that you might find yourself in serious trouble if you then have, for example, a PXE stack layered on top of your SCSI BIOS. There are test software used in manufacturing line that needs this DOS memory. For that purpose, you can probably get away with a lot more than that. -hpa - 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: ALPS touchpad not seen by 2.6.11 kernels
On Saturday 26 February 2005 17:55, Frank Victor Fischer wrote: > I have had the same problem and the solution worked for me as well. > > Where should I put the DSDT? > Just e-mail it to me - I suspect your PS/2 port has a wierd ID assigned to it, one that i8042 driver does not expect. -- Dmitry - 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: Invalid module format in Fedora core2
hai sam, thanks for ur valuable info reg. 2.6 module insertion. Thanks&Regards, P.Manohar, n Fri, 25 Feb 2005, it was written: There are new books that you are supposed to buy which will tell you how to re-write all your modules to interface with the new crap. Whats wrong with the free articles at lwn.net? I attached a typical makefile so you can see how complicated this new crap is. This is utterly crap. There is no difference in the Makefile being in-kernel or for an external module if the Makefile is used solely to specify content of the Module. So for a sample module named mymodule you need: Makefile: obj-m := mymodule.o mymodule-y := file1.o file2.o file3.o Here assuming 3 files are needed to build the actual module. If you then want some wrapping to make things a bit easier you can add a second file: makefile: VERS := $(shell uname -r) CDIR := $(shell pwd) all: $(MAKE) V=1 -C /usr/src/linux-$(VERS) SUBDIRS=$(CDIR) modules strip -x -R .note -R .comment mymodule.ko And nothing special is needed with respect to vermagic etc. The kernel do it for you. Please keep in mind the original poster did not ask for a method that could be used for both 2.4 _and_ 2.6. Sam - 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: via 6420 pata/sata controller
>>Bartlomiej Zolnierkiewicz wrote:
>>> On Tuesday 30 of March 2004 15:24, Zdenek Tlusty wrote:
>>>
Hello,
I have problem with via 6420 controller under linux (I have
mandrake 9.1
with kernel 2.4.25 with libata patch version 16).
This controller has two sata and one pata channels. Sata channel
works fine
with libata. My problem is with pata channel. I have pata hard disk
on this
controller. Bios of the controller detected this disk but linux did
not.
What is the current status of the driver for this controller?
Thank you for your time.
>>>
>>>
>>> There are some patches floating around adding support for VT6410
>>> (not VT6420) to generic IDE PCI driver. This controller may also work
>>> with generic IDE PCI driver (PCI VendorID/ProductID needs to be added
>>> to drivers/ide/pci/generic.h and drivers/ide/pci/generic.c).
>>
>>VT 6420 should be added to via82cxxx.c, since it does the necessary bus
>>setup and such. AFAICS it is programmed just like all the other VIA
>>PATA controllers.
>>
>> BTW Does anybody has contacts in VIA?
>>
>>Sure... I'll check my VT 6420 cards as well. It should just be another
>>PCI id added to via82cxxx.c.
>>
>> Jeff
>>
>
>Hello,
>
>I tried to modify via82cxxx.c and .h, but was unsuccessful. Has anyone
got it to work properly?
>
>Kamil Okac
* Per my message (last quoted line), the user should add the PCI ID to
* drivers/ide/via82cxxx.[ch] and see what happens.
*
* Jeff
Hello,
i trying resurrect this discussion again for solve this problem successfuly.
My experiments:
I changed two files:
usr/src/linux-2.6.11-rc5/include/linux/pci_ids.h
--- cut here ---
#define PCI_DEVICE_ID_VIA_8703_51_0 0x3148
#define PCI_DEVICE_ID_VIA_8237_SATA 0x3149
#define PCI_DEVICE_ID_VIA_6420 0x4149; <= this i was
add
#define PCI_DEVICE_ID_VIA_XN266 0x3156
#define PCI_DEVICE_ID_VIA_8754C_0 0x3168
--- cut here ---
/use/src/linux-2.6.11-rc5/drivers/ide/pci/via82cxxx.c
--- cut here ---
{ "vt8233c", PCI_DEVICE_ID_VIA_8233C_0, 0x00, 0x2f, VIA_UDMA_100 },
{ "vt8233", PCI_DEVICE_ID_VIA_8233_0, 0x00, 0x2f, VIA_UDMA_100 },
{ "vt8231", PCI_DEVICE_ID_VIA_8231, 0x00, 0x2f, VIA_UDMA_100 },
{ "vt6420", PCI_DEVICE_ID_VIA_6420, 0x00, 0x2f, VIA_UDMA_100 },
; <= this i was add
{ "vt82c686b", PCI_DEVICE_ID_VIA_82C686, 0x40, 0x4f, VIA_UDMA_100 },
{ "vt82c686a", PCI_DEVICE_ID_VIA_82C686, 0x10, 0x2f, VIA_UDMA_66 },
--- cut here ---
But i was not successful :'-(
Informations from my computer:
dmesg
--- cut here ---
Linux version 2.6.11-rc5 ([EMAIL PROTECTED]) (gcc version 2.95.4 20011002
(Debian prerelease)) #1 Sat Feb 26 02:18:02 CET 2005
.
.
.
SCSI subsystem initialized
libata version 1.10 loaded.
sata_via version 1.1
sata_via(:00:0f.0): routed to hard irq line 10
ata1: SATA max UDMA/133 cmd 0x6200 ctl 0x6302 bmdma 0x6600 irq 10
ata2: SATA max UDMA/133 cmd 0x6400 ctl 0x6502 bmdma 0x6608 irq 10
ata1: no device found (phy stat )
scsi0 : sata_via
ata2: no device found (phy stat )
scsi1 : sata_via
--- cut here ---
lspci
--- cut here ---
:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA
RAID Controller (rev 50)
:00:0f.1 RAID bus controller: VIA Technologies, Inc.: Unknown device
4149 (rev 80)
--- cut here ---
lspci -n
--- cut here ---
:00:0f.0 0104: 1106:3149 (rev 50)
:00:0f.1 0104: 1106:4149 (rev 80)
--- cut here ---
cat /proc/ioports
--- cut here ---
6200-6207 : :00:0f.0
6200-6207 : sata_via
6300-6303 : :00:0f.0
6300-6303 : sata_via
6400-6407 : :00:0f.0
6400-6407 : sata_via
6500-6503 : :00:0f.0
6500-6503 : sata_via
6600-660f : :00:0f.0
6600-660f : sata_via
6700-67ff : :00:0f.0
6700-67ff : sata_via
6800-6807 : :00:0f.1
6900-6903 : :00:0f.1
6a00-6a07 : :00:0f.1
6b00-6b03 : :00:0f.1
6c00-6c0f : :00:0f.1
--- cut here ---
This controller talking about:
http://www.sunsway.com.hk/products/sata-ide.html
http://www.viatech.co.jp/en/Products/vt6420.jsp
http://www.via.com.tw/en/products/peripherals/serial-ata_raid/vt6420/
Forum where they talked about - linux talking:
http://www.ussg.iu.edu/hypermail/linux/kernel/0403.3/1565.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0403.3/1814.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0403.3/1821.html
_http://www.ussg.iu.edu/hypermail/linux/kernel/0404.2/0573.html_
Forum where they talked about - freebsd talking:
http://lists.freebsd.org/pipermail/freebsd-current/2004-January/017706.html
http://lists.freebsd.org/pipermail/freebsd-current/2004-January/017725.html
Your's Sincerely
Petr Novák
[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: userspace app needing signal on parport input change
Melkor Ainur <[EMAIL PROTECTED]> wrote: > Is there a way for a user space app to get a signal or > maybe woken up from select/read when there is a change > on a particular input pin on the parallel port? The easiest hack I can think of is: Change the db9-driver to be freely configurable and make yourself a zero-axis 13-button "joystick". http://www.infonewsindia.com/pinout/ibmlpt.txt might help for the pin assignment. I guess you don't need it, but maybe some other vicolunteer does. - 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] config option for default loglevel
Am Sat, 26 Feb 2005 18:15:52 -0800 schrieb Andrew Morton <[EMAIL PROTECTED]>:
> I don't see a need for the compile-time option now..
>
Well i would prefer to also have a compile-time option, but only a boot
paramter will also do the job.
diff -Naur linux-2.6.10/Documentation/kernel-parameters.txt
linux-2.6.10-new/Documentation/kernel-parameters.txt
--- linux-2.6.10/Documentation/kernel-parameters.txt2005-02-27
02:47:09.0 +0100
+++ linux-2.6.10-new/Documentation/kernel-parameters.txt2005-02-27
02:52:36.0 +0100
@@ -634,6 +634,20 @@
logibm.irq= [HW,MOUSE] Logitech Bus Mouse Driver
Format:
+loglevel= All Kernel Messages with a loglevel smaller than the
+console loglevel will be printed to the console. It can
+also be changed with klogd or other programs. The
+loglevels are defined as follows:
+
+0 (KERN_EMERG)system is unusable
+1 (KERN_ALERT)action must be taken immediately
+2 (KERN_CRIT) critical conditions
+3 (KERN_ERR) error conditions
+4 (KERN_WARNING) warning conditions
+5 (KERN_NOTICE) normal but significant condition
+6 (KERN_INFO) informational
+7 (KERN_DEBUG)debug-level messages
+
log_buf_len=n Sets the size of the printk ring buffer, in bytes.
Format is n, nk, nM. n must be a power of two. The
default is set in kernel config.
diff -Naur linux-2.6.10/init/main.c linux-2.6.10-new/init/main.c
--- linux-2.6.10/init/main.c2005-02-27 02:48:32.0 +0100
+++ linux-2.6.10-new/init/main.c2005-02-27 02:39:08.0 +0100
@@ -209,6 +209,14 @@
__setup("debug", debug_kernel);
__setup("quiet", quiet_kernel);
+static int __init loglevel(char *str)
+{
+get_option(&str, &console_loglevel);
+return 1;
+}
+
+__setup("loglevel=", loglevel);
+
/*
* Unknown boot options get handed to init, unless they look like
* failed parameters
-
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/
System stops because /var/log not found after moving to new partition
Hi ! I have a Red Hat 8.0 on a intel 2.4 machine with 512 MB . I have kernel 2.4.20-30.8-legacy & 2.4.20-30.8-legacy bigmem. I used to have all my directories /var , /tmp , /usr , /home under one partition / . Thanks to everybody , now I was able to re-partition my drive into extended drives (drives < 4) and move my /var , /tmp into hda5 & ,my /usr , /home into /hda6 . Bu I am facing one problem. When I boot my system logger does not see the /var/log which has been moved to the new location . The system just hangs . When I boot in single mode by passing an argument to my kernel that does show in the dmesg in the new location . In addtion when I run a command like 'clear ' it shows that it could not find the library to run it . I have mounted hda5 & hda6 in my fstab . I did create soft link for my new var , new tmp & new usr to the the /var , /tmp , /usr as ffs :- ln -s /mnt/hda5/var /var ln -s /mnt/hda5/tmp /tmp ln -s /mnt/hda6/usr /usr I moved the old files using the ff commands:- cd source directory cp -ax * /mnt/usr5/var or cd /src/dir ; tar cf - . | (cd /dest/dir && tar xvf - ) But still it does not work . Please find attached the dmesg & library error and fstab. Please advice. Thank you for your help in advance. bj Linux version 2.4.20-30.8.legacy ([EMAIL PROTECTED]) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Fri Feb 20 17:47:48 PST 2004 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff3000 (ACPI NVS) BIOS-e820: 1fff3000 - 2000 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. On node 0 totalpages: 131056 zone(0): 4096 pages. zone(1): 126960 pages. zone(2): 0 pages. Kernel command line: ro root=LABEL=/ hdb=ide-scsi ide_setup: hdb=ide-scsi Initializing CPU#0 Detected 2393.991 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 4771.02 BogoMIPS Memory: 511512k/524224k available (1340k kernel code, 10148k reserved, 999k data, 128k init, 0k highmem) Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode cache hash table entries: 32768 (order: 6, 262144 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: bfebfbff CPU: Common caps: bfebfbff CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz stepping 07 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfb270, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router VIA [1106/3177] at 00:11.0 isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16) Starting kswapd VFS: Disk quotas vdquot_6.5.1 pty: 2048 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS0 at 0x03f8 (irq = 4) is a 16550A ttyS1 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10e Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 NET4: Frame Diverter 0.46 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 7.00beta3-.2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 00:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1 ide0: BM-DMA at 0xdc00-0xdc07, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hdc:pio, hdd:DMA hda: ST360020A, ATA DISK drive hdb: SONY CD-RW CRX1611, ATAPI CD/DVD-ROM drive blk: queue c03a6260, I/O limit 4095Mb (mask 0x) hdd: ST380011A, ATA DISK drive blk: queue c03a6808, I/O limit 4095Mb (mask 0x) ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: attached ide-disk driver. hda: host protected area => 1 hda: 117231408 sectors (60022 MB) w/2048KiB Cache, CHS=7297/255/63, UDMA(100) hdd: attached ide-disk driver. hdd: host protected area =>
Re: [PATCH] config option for default loglevel
On Sun, Feb 27, 2005 at 03:04:31AM +0100, Matthias Kunze wrote: +config DEFAULT_CONSOLE_LOGLEVEL You do not want to add yet another config option. Config options are used to select or deselect major subsystems, or support for specific hardware. Not to tweak variables. Adding more config variables is not an improvement. There are many ways to set the loglevel from user space. You add one on the command line - maybe useful in case more output is needed when the kernel crashes in early boot. I see no justification for DEFAULT_CONSOLE_LOGLEVEL. Andries - 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] config option for default loglevel
Matthias Kunze <[EMAIL PROTECTED]> wrote: > > I've added the boot option, it will override the compile-time option. I don't see a need for the compile-time option now.. - 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] config option for default loglevel
Am Sat, 26 Feb 2005 15:45:05 -0800 schrieb Andrew Morton <[EMAIL PROTECTED]>:
> Matthias Kunze <[EMAIL PROTECTED]> wrote:
> >
> > I've created a little patch to make the default loglevel a configurable
> > option.
>
> It'd be better to make it a kernel boot option, IMO. We already have
> `debug' and `quiet' (init/main.c), which are rather silly things. An
> option to set the initial loglevel would make sense.
>
I've added the boot option, it will override the compile-time option.
diff -Naur linux-2.6.10/Documentation/kernel-parameters.txt
linux-2.6.10-new/Documentation/kernel-parameters.txt
--- linux-2.6.10/Documentation/kernel-parameters.txt2005-02-27
02:47:09.0 +0100
+++ linux-2.6.10-new/Documentation/kernel-parameters.txt2005-02-27
02:52:36.0 +0100
@@ -634,6 +634,20 @@
logibm.irq= [HW,MOUSE] Logitech Bus Mouse Driver
Format:
+loglevel= All Kernel Messages with a loglevel smaller than the
+console loglevel will be printed to the console. It can
+also be changed with klogd or other programs. The
+loglevels are defined as follows:
+
+0 (KERN_EMERG)system is unusable
+1 (KERN_ALERT)action must be taken immediately
+2 (KERN_CRIT) critical conditions
+3 (KERN_ERR) error conditions
+4 (KERN_WARNING) warning conditions
+5 (KERN_NOTICE) normal but significant condition
+6 (KERN_INFO) informational
+7 (KERN_DEBUG)debug-level messages
+
log_buf_len=n Sets the size of the printk ring buffer, in bytes.
Format is n, nk, nM. n must be a power of two. The
default is set in kernel config.
diff -Naur linux-2.6.10/drivers/video/console/Kconfig
linux-2.6.10-new/drivers/video/console/Kconfig
--- linux-2.6.10/drivers/video/console/Kconfig 2004-12-24 22:34:26.0
+0100
+++ linux-2.6.10-new/drivers/video/console/Kconfig 2005-02-27
02:44:58.0 +0100
@@ -186,5 +186,26 @@
big letters (like the letters used in the SPARC PROM). If the
standard font is unreadable for you, say Y, otherwise say N.
+config DEFAULT_CONSOLE_LOGLEVEL
+int "Default Console Loglevel"
+range 1 8
+default 7
+help
+ All Kernel Messages with a loglevel smaller than the console loglevel
+ will be printed to the console. This value can be overriden by the
+ boot parameter loglevel=NUM. It can also be changed with klogd or
+ other programs. The loglevels are defined as follows:
+
+ 0 (KERN_EMERG)system is unusable
+ 1 (KERN_ALERT)action must be taken immediately
+ 2 (KERN_CRIT) critical conditions
+ 3 (KERN_ERR) error conditions
+ 4 (KERN_WARNING) warning conditions
+ 5 (KERN_NOTICE) normal but significant condition
+ 6 (KERN_INFO) informational
+ 7 (KERN_DEBUG)debug-level messages
+
+ The console loglevel can be set to a value in the range from 1 to 8.
+
endmenu
diff -Naur linux-2.6.10/init/main.c linux-2.6.10-new/init/main.c
--- linux-2.6.10/init/main.c2005-02-27 02:48:32.0 +0100
+++ linux-2.6.10-new/init/main.c2005-02-27 02:39:08.0 +0100
@@ -209,6 +209,14 @@
__setup("debug", debug_kernel);
__setup("quiet", quiet_kernel);
+static int __init loglevel(char *str)
+{
+get_option(&str, &console_loglevel);
+return 1;
+}
+
+__setup("loglevel=", loglevel);
+
/*
* Unknown boot options get handed to init, unless they look like
* failed parameters
diff -Naur linux-2.6.10/kernel/printk.c linux-2.6.10-new/kernel/printk.c
--- linux-2.6.10/kernel/printk.c2005-02-27 02:48:32.0 +0100
+++ linux-2.6.10-new/kernel/printk.c2005-02-27 02:39:18.0 +0100
@@ -41,7 +41,7 @@
/* We show everything that is MORE important than this.. */
#define MINIMUM_CONSOLE_LOGLEVEL 1 /* Minimum loglevel we let people use */
-#define DEFAULT_CONSOLE_LOGLEVEL 7 /* anything MORE serious than KERN_DEBUG */
+#define DEFAULT_CONSOLE_LOGLEVEL CONFIG_DEFAULT_CONSOLE_LOGLEVEL
DECLARE_WAIT_QUEUE_HEAD(log_wait);
-
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] more apic.c
Andries Brouwer wrote:
setup_APIC_timer is only called in __init context and uses __initdata
Andries
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
--- a/arch/i386/kernel/apic.c 2005-02-26 12:13:28.0 +0100
+++ b/arch/i386/kernel/apic.c 2005-02-26 16:13:21.0 +0100
@@ -930,7 +930,7 @@ void __setup_APIC_LVTT(unsigned int cloc
apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
}
-static void setup_APIC_timer(unsigned int clocks)
+static void __init setup_APIC_timer(unsigned int clocks)
{
unsigned long flags;
Ack.
http://marc.theaimsgroup.com/?l=linux-kernel&m=108727726207069&w=2
--
~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/
Re: [PATCH] partitions/msdos.c
On Sun, Feb 27, 2005 at 01:47:43AM +0100, Uwe Bonnes wrote: > on a Suse 9.2 System with Suse Hotplug, the phantom partition was somehow > recognized as Reiserfs, and then the Hotplug mechanism trying to mount the > bogus partition as a Reiser Filesystem ended in an Oops... Always report the oops. It is well-known that mounting garbage may crash the kernel. Earlier the reply was "don't do that then". Nowadays we have more layers of software trying to probe and do automatic things, and the kernel must survive attempts to mount garbage. Andries - 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] partitions/msdos.c
On Sun, 27 Feb 2005, Uwe Bonnes wrote: > > on a Suse 9.2 System with Suse Hotplug, the phantom partition was somehow > recognized as Reiserfs, and then the Hotplug mechanism trying to mount the > bogus partition as a Reiser Filesystem ended in an Oops... Heh. That oops would be interesting in itself, since it implies that reiserfs is not doing very well on the sanity-checking front. But yes, point taken. 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/
[2.6 patch] SCSI NCR_D700.c: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/NCR_D700.c.old 2005-02-27
01:03:50.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/NCR_D700.c 2005-02-27
01:04:25.0 +0100
@@ -106,7 +106,7 @@
#include "53c700.h"
#include "NCR_D700.h"
-char *NCR_D700;/* command line from insmod */
+static char *NCR_D700; /* command line from insmod */
MODULE_AUTHOR("James Bottomley");
MODULE_DESCRIPTION("NCR Dual700 SCSI Driver");
@@ -352,7 +352,7 @@
static short NCR_D700_id_table[] = { NCR_D700_MCA_ID, 0 };
-struct mca_driver NCR_D700_driver = {
+static struct mca_driver NCR_D700_driver = {
.id_table = NCR_D700_id_table,
.driver = {
.name = "NCR_D700",
-
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.6 patch] drivers/scsi/aacraid/: cleanups
This patch contains the following cleanups:
- make needlessly global functions static
- commsup.c: remove the unused global function aac_consumer_avail
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/scsi/aacraid/aachba.c | 10 +-
drivers/scsi/aacraid/aacraid.h |2 --
drivers/scsi/aacraid/commctrl.c |4 ++--
drivers/scsi/aacraid/comminit.c |2 +-
drivers/scsi/aacraid/commsup.c |7 +--
drivers/scsi/aacraid/linit.c|2 +-
drivers/scsi/aacraid/sa.c |2 +-
7 files changed, 11 insertions(+), 18 deletions(-)
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/aachba.c.old 2005-02-27
01:05:38.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/aachba.c 2005-02-27
01:06:18.0 +0100
@@ -560,10 +560,10 @@
inqstrcpy ("V1.0", str->prl);
}
-void set_sense(u8 *sense_buf, u8 sense_key, u8 sense_code,
- u8 a_sense_code, u8 incorrect_length,
- u8 bit_pointer, u16 field_pointer,
- u32 residue)
+static void set_sense(u8 *sense_buf, u8 sense_key, u8 sense_code,
+ u8 a_sense_code, u8 incorrect_length,
+ u8 bit_pointer, u16 field_pointer,
+ u32 residue)
{
sense_buf[0] = 0xF0;/* Sense data valid, err code 70h (current
error) */
sense_buf[1] = 0; /* Segment number, always zero */
@@ -807,7 +807,7 @@
aac_io_done(scsicmd);
}
-int aac_read(struct scsi_cmnd * scsicmd, int cid)
+static int aac_read(struct scsi_cmnd * scsicmd, int cid)
{
u32 lba;
u32 count;
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/commctrl.c.old
2005-02-27 01:06:31.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/commctrl.c 2005-02-27
01:07:03.0 +0100
@@ -403,7 +403,7 @@
*
*/
-int aac_send_raw_srb(struct aac_dev* dev, void __user * arg)
+static int aac_send_raw_srb(struct aac_dev* dev, void __user * arg)
{
struct fib* srbfib;
int status;
@@ -621,7 +621,7 @@
};
-int aac_get_pci_info(struct aac_dev* dev, void __user *arg)
+static int aac_get_pci_info(struct aac_dev* dev, void __user *arg)
{
struct aac_pci_info pci_info;
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/comminit.c.old
2005-02-27 01:07:25.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/comminit.c 2005-02-27
01:07:34.0 +0100
@@ -204,7 +204,7 @@
* 0 - If there were errors initing. This is a fatal error.
*/
-int aac_comm_init(struct aac_dev * dev)
+static int aac_comm_init(struct aac_dev * dev)
{
unsigned long hdrsize = (sizeof(u32) * NUMBER_OF_COMM_QUEUES) * 2;
unsigned long queuesize = sizeof(struct aac_entry) *
TOTAL_QUEUE_ENTRIES;
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/aacraid.h.old
2005-02-27 01:04:59.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/aacraid.h2005-02-27
01:09:03.0 +0100
@@ -1595,11 +1595,9 @@
void fib_map_free(struct aac_dev *dev);
void fib_free(struct fib * context);
void fib_init(struct fib * context);
-void fib_dealloc(struct fib * context);
void aac_printf(struct aac_dev *dev, u32 val);
int fib_send(u16 command, struct fib * context, unsigned long size, int
priority, int wait, int reply, fib_callback callback, void *ctxt);
int aac_consumer_get(struct aac_dev * dev, struct aac_queue * q, struct
aac_entry **entry);
-int aac_consumer_avail(struct aac_dev * dev, struct aac_queue * q);
void aac_consumer_free(struct aac_dev * dev, struct aac_queue * q, u32 qnum);
int fib_complete(struct fib * context);
#define fib_data(fibctx) ((void *)(fibctx)->hw_fib->data)
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/commsup.c.old
2005-02-27 01:08:23.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/commsup.c2005-02-27
01:09:11.0 +0100
@@ -210,7 +210,7 @@
* caller.
*/
-void fib_dealloc(struct fib * fibptr)
+static void fib_dealloc(struct fib * fibptr)
{
struct hw_fib *hw_fib = fibptr->hw_fib;
if(hw_fib->header.StructType != FIB_MAGIC)
@@ -566,11 +566,6 @@
return(status);
}
-int aac_consumer_avail(struct aac_dev *dev, struct aac_queue * q)
-{
- return (le32_to_cpu(*q->headers.producer) !=
le32_to_cpu(*q->headers.consumer));
-}
-
/**
* aac_consumer_free - free consumer entry
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/linit.c.old 2005-02-27
01:09:30.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/aacraid/linit.c 2005-02-27
01:09:38.0 +0100
@@ -215,7 +215,7 @@
* Returns a static string describing the device in question
*/
-const char *aac_info(struct Scsi_Host *shost)
+static const char *aac_info(struct Scsi_Host *shost)
{
struct aac_dev *dev = (struct aac_dev *)shost->hostdata;
return aac_drivers[dev->cardtype].name;
--- linux-2.6.11-rc4-mm1-full/d
[2.6 patch] drivers/pnp/: possible cleanups
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global function:
- core.c: pnp_remove_device
- remove the following unneeded EXPORT_SYMBOL's:
- card.c: pnp_add_card
- card.c: pnp_remove_card
- card.c: pnp_add_card_device
- card.c: pnp_remove_card_device
- card.c: pnp_add_card_id
- core.c: pnp_register_protocol
- core.c: pnp_unregister_protocol
- core.c: pnp_add_device
- core.c: pnp_remove_device
- pnpacpi/core.c: pnpacpi_protocol
- driver.c: pnp_add_id
- isapnp/core.c: isapnp_read_byte
- manager.c: pnp_auto_config_dev
- resource.c: pnp_register_dependent_option
- resource.c: pnp_register_independent_option
- resource.c: pnp_register_irq_resource
- resource.c: pnp_register_dma_resource
- resource.c: pnp_register_port_resource
- resource.c: pnp_register_mem_resource
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/pnp/card.c |7 +--
drivers/pnp/core.c |7 ++-
drivers/pnp/driver.c |1 -
drivers/pnp/isapnp/core.c |1 -
drivers/pnp/manager.c |1 -
drivers/pnp/pnpacpi/core.c |5 ++---
drivers/pnp/resource.c |8
include/linux/pnp.h|2 --
8 files changed, 5 insertions(+), 27 deletions(-)
--- linux-2.6.11-rc4-mm1-full/drivers/pnp/card.c.old2005-02-26
15:54:16.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/pnp/card.c2005-02-26
16:16:07.0 +0100
@@ -19,7 +19,7 @@
#include "base.h"
LIST_HEAD(pnp_cards);
-LIST_HEAD(pnp_card_drivers);
+static LIST_HEAD(pnp_card_drivers);
static const struct pnp_card_device_id * match_card(struct pnp_card_driver *
drv, struct pnp_card * card)
@@ -380,11 +380,6 @@
pnp_unregister_driver(&drv->link);
}
-EXPORT_SYMBOL(pnp_add_card);
-EXPORT_SYMBOL(pnp_remove_card);
-EXPORT_SYMBOL(pnp_add_card_device);
-EXPORT_SYMBOL(pnp_remove_card_device);
-EXPORT_SYMBOL(pnp_add_card_id);
EXPORT_SYMBOL(pnp_request_card_device);
EXPORT_SYMBOL(pnp_release_card_device);
EXPORT_SYMBOL(pnp_register_card_driver);
--- linux-2.6.11-rc4-mm1-full/include/linux/pnp.h.old 2005-02-26
15:54:39.0 +0100
+++ linux-2.6.11-rc4-mm1-full/include/linux/pnp.h 2005-02-26
15:54:59.0 +0100
@@ -353,7 +353,6 @@
int pnp_register_protocol(struct pnp_protocol *protocol);
void pnp_unregister_protocol(struct pnp_protocol *protocol);
int pnp_add_device(struct pnp_dev *dev);
-void pnp_remove_device(struct pnp_dev *dev);
int pnp_device_attach(struct pnp_dev *pnp_dev);
void pnp_device_detach(struct pnp_dev *pnp_dev);
extern struct list_head pnp_global;
@@ -399,7 +398,6 @@
static inline void pnp_unregister_protocol(struct pnp_protocol *protocol) { }
static inline int pnp_init_device(struct pnp_dev *dev) { return -ENODEV; }
static inline int pnp_add_device(struct pnp_dev *dev) { return -ENODEV; }
-static inline void pnp_remove_device(struct pnp_dev *dev) { }
static inline int pnp_device_attach(struct pnp_dev *pnp_dev) { return -ENODEV;
}
static inline void pnp_device_detach(struct pnp_dev *pnp_dev) { ; }
--- linux-2.6.11-rc4-mm1-full/drivers/pnp/core.c.old2005-02-26
15:55:56.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/pnp/core.c2005-02-26
16:48:31.0 +0100
@@ -158,13 +158,14 @@
*
* this function will free all mem used by dev
*/
-
+#if 0
void pnp_remove_device(struct pnp_dev *dev)
{
if (!dev || dev->card)
return;
__pnp_remove_device(dev);
}
+#endif /* 0 */
static int __init pnp_init(void)
{
@@ -174,7 +175,3 @@
subsys_initcall(pnp_init);
-EXPORT_SYMBOL(pnp_register_protocol);
-EXPORT_SYMBOL(pnp_unregister_protocol);
-EXPORT_SYMBOL(pnp_add_device);
-EXPORT_SYMBOL(pnp_remove_device);
--- linux-2.6.11-rc4-mm1-full/drivers/pnp/pnpacpi/core.c.old2005-02-26
15:57:01.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/pnp/pnpacpi/core.c2005-02-26
15:57:26.0 +0100
@@ -124,7 +124,7 @@
return ACPI_FAILURE(status) ? -ENODEV : 0;
}
-struct pnp_protocol pnpacpi_protocol = {
+static struct pnp_protocol pnpacpi_protocol = {
.name = "Plug and Play ACPI",
.get= pnpacpi_get_resources,
.set= pnpacpi_set_resources,
@@ -242,7 +242,7 @@
}
int pnpacpi_disabled __initdata;
-int __init pnpacpi_init(void)
+static int __init pnpacpi_init(void)
{
if (acpi_disabled || pnpacpi_disabled) {
pnp_info("PnP ACPI: disabled");
@@ -266,4 +266,3 @@
}
__setup("pnpacpi=", pnpacpi_setup);
-EXPORT_SYMBOL(pnpacpi_protocol);
--- linux-2.6.11-rc4-mm1-full/drivers/pnp/driver.c.old 2005-02-26
16:09:23.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/pnp/driver.c 2005-02-26
16:09:52.0 +0100
@@ -217,6 +217,5 @@
EXPORT_SYMBOL(pnp_register_driver);
EXPORT_SYMBOL(pnp_unregister_driver);
-EXPORT_SYMBOL(pnp_add_id);
EXPORT_SYMBOL(pnp_device_attach);
EXPORT_SYMBOL(pnp_device_detach);
--- linu
Re: [PATCH] partitions/msdos.c
> "Linus" == Linus Torvalds <[EMAIL PROTECTED]> writes: Linus> On Sun, 27 Feb 2005, Andries Brouwer wrote: >> (Concerning the "size" version: it occurred to me that there is one >> very minor objection: For extended partitions so far the size did not >> normally play a role. Only the starting sector was significant. If, >> at some moment we decide also to check the size, then a weaker check, >> namely only checking for non-extended partitions, might be better at >> first.) Linus> Yes. I agree - checking the size is likely _more_ dangerous and Linus> likely to break something silly than checking the ID for zero. Linus> So your patch it is. I'll put it in immediately after doing a Linus> 2.6.11 (no need to worry about getting into 2.6.11, since afaik Linus> the worst problem right now is an extra partition that isn't Linus> usable). Well, on a Suse 9.2 System with Suse Hotplug, the phantom partition was somehow recognized as Reiserfs, and then the Hotplug mechanism trying to mount the bogus partition as a Reiser Filesystem ended in an Oops... -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- - 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.6 patch] drivers/pcmcia/: possible cleanups
This patch contains the following possible cleanups:
- make needlessly global code static
- remove the following unneeded EXPORT_SYMBOL's:
- ds.c: pcmcia_report_error
- ds.c: pcmcia_bus_type
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/pcmcia/ds.c | 10 +-
drivers/pcmcia/rsrc_nonstatic.c |4 ++--
include/pcmcia/cs.h |1 -
include/pcmcia/ds.h |2 --
4 files changed, 7 insertions(+), 10 deletions(-)
--- linux-2.6.11-rc4-mm1-full/include/pcmcia/cs.h.old 2005-02-26
15:49:49.0 +0100
+++ linux-2.6.11-rc4-mm1-full/include/pcmcia/cs.h 2005-02-26
15:50:07.0 +0100
@@ -417,7 +417,6 @@
int pcmcia_resume_card(struct pcmcia_socket *skt);
int pcmcia_eject_card(struct pcmcia_socket *skt);
int pcmcia_insert_card(struct pcmcia_socket *skt);
-int pcmcia_report_error(client_handle_t handle, error_info_t *err);
struct pcmcia_socket * pcmcia_get_socket(struct pcmcia_socket *skt);
void pcmcia_put_socket(struct pcmcia_socket *skt);
--- linux-2.6.11-rc4-mm1-full/include/pcmcia/ds.h.old 2005-02-26
15:45:28.0 +0100
+++ linux-2.6.11-rc4-mm1-full/include/pcmcia/ds.h 2005-02-26
15:45:32.0 +0100
@@ -129,8 +129,6 @@
struct pcmcia_socket;
-extern struct bus_type pcmcia_bus_type;
-
struct pcmcia_driver {
dev_link_t *(*attach)(void);
void(*detach)(dev_link_t *);
--- linux-2.6.11-rc4-mm1-full/drivers/pcmcia/ds.c.old 2005-02-26
15:44:48.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/pcmcia/ds.c 2005-02-26
15:49:33.0 +0100
@@ -58,7 +58,7 @@
MODULE_LICENSE("GPL");
#ifdef DEBUG
-int ds_pc_debug;
+static int ds_pc_debug;
module_param_named(pc_debug, ds_pc_debug, int, 0644);
@@ -214,7 +214,7 @@
};
-int pcmcia_report_error(client_handle_t handle, error_info_t *err)
+static int pcmcia_report_error(client_handle_t handle, error_info_t *err)
{
int i;
char *serv;
@@ -244,7 +244,6 @@
return CS_SUCCESS;
} /* report_error */
-EXPORT_SYMBOL(pcmcia_report_error);
/* end of code which was in cs.c before */
@@ -262,6 +261,8 @@
static struct pcmcia_driver * get_pcmcia_driver (dev_info_t *dev_info);
static struct pcmcia_bus_socket * get_socket_info_by_nr(unsigned int nr);
+static struct bus_type pcmcia_bus_type;
+
static void pcmcia_release_bus_socket(struct kref *refcount)
{
struct pcmcia_bus_socket *s = container_of(refcount, struct
pcmcia_bus_socket, refcount);
@@ -1610,12 +1611,11 @@
};
-struct bus_type pcmcia_bus_type = {
+static struct bus_type pcmcia_bus_type = {
.name = "pcmcia",
.match = pcmcia_bus_match,
.dev_attrs = pcmcia_dev_attrs,
};
-EXPORT_SYMBOL(pcmcia_bus_type);
static int __init init_pcmcia_bus(void)
--- linux-2.6.11-rc4-mm1-full/drivers/pcmcia/rsrc_nonstatic.c.old
2005-02-26 18:41:19.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/pcmcia/rsrc_nonstatic.c 2005-02-26
18:41:34.0 +0100
@@ -606,7 +606,7 @@
==*/
-struct resource *nonstatic_find_io_region(unsigned long base, int num,
+static struct resource *nonstatic_find_io_region(unsigned long base, int num,
unsigned long align, struct pcmcia_socket *s)
{
struct resource *res = make_resource(0, num, IORESOURCE_IO,
s->dev.class_id);
@@ -640,7 +640,7 @@
return res;
}
-struct resource * nonstatic_find_mem_region(u_long base, u_long num, u_long
align,
+static struct resource * nonstatic_find_mem_region(u_long base, u_long num,
u_long align,
int low, struct pcmcia_socket *s)
{
struct resource *res = make_resource(0, num, IORESOURCE_MEM,
s->dev.class_id);
-
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.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)
On Sat, Feb 26, 2005 at 05:29:22PM +, Russell King wrote: > On Sat, Feb 26, 2005 at 06:13:25PM +0100, Adrian Bunk wrote: > > You call it "breakage" because you have a relatively dogmatic view > > regarding the selection of user visible symbols. > > Other people care more about the usability of the kernel config system, > > and therefore a select of one of the I2C* options is quite common from > > both outside and inside the i2c subsystem. > > I think you have to realise that we're different in the ARM world. > We tend to rely on the default configuration files to come out with > something that works, rather than hard coding the "what works" into > the kernel configuration subsystem. > > If you want to see an example of this kind of "usability" approach, > take a look at arch/arm/Kconfig LEDS options - lines of 250 or so > characters of dependencies. Not what I'd call particularly > maintainable. > > That is what your approach has in store for the other Kconfig files > when it comes down to getting dependencies Correct(tm). LEDS=n and LEDS_TIMER=y is a legal configuration if ARCH_EBSA110? The LEDS_TIMER dependencies seem to be incorrect at least regarding ARCH_CDB89712. Yes, it is ugly annd error-prone. > (I do have a simplified LEDS configuration set, but it still keeps > one huge LEDS dependency.) The current LEDS configuration is ugly, but that's not an ARM specific problem. Compare e.g. the big #if in include/linux/parport.h 30 lines before the end of the file in Linus' tree and see how this is resolved in -mm in non-pc-parport-config-change.patch . One solution for LEDS would be to add a helper option HAS_LEDS that gets selected by the ARCH_* options if the platform supports LEDS, and LEDS simply depends on HAS_LEDS. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)
On Sat, Feb 26, 2005 at 05:20:18PM +, Russell King wrote: > On Sat, Feb 26, 2005 at 06:13:25PM +0100, Adrian Bunk wrote: > > You call it "breakage" because you have a relatively dogmatic view > > regarding the selection of user visible symbols. > > Other people care more about the usability of the kernel config system, > > and therefore a select of one of the I2C* options is quite common from > > both outside and inside the i2c subsystem. > > > > There are two possbile situations: > > - these RTC drivers are nice add-ons that could be shown if all > > required I2C* options are already enabled > > - these RTC drivers are pretty essential and should really be enabled > > on the platforms they are for > > > > Which of these two cases describes the situation of these RTC drivers? > > Since RTCs aren't _actually_ essential for Linux kernel operation, > the former clearly applies. > > Other people may have differing opinions, but having worked with a > large number of SoC platforms where the RTC is reset when the SoC > is reset, or even platforms where there is no RTC at all, it brings > a different perspective to this that people who have only ever > experienced systems where the RTC is always true do not have. No problem with this. I'm hereby withdrawing my patch. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.29-lck1
Updated the lck patchset. This is the patchset formerly known as the 2.4-ck patchset. http://www.plumlocosoft.com/kernel/ Includes: O(1) scheduler with batch scheduling, interactivity Preemptible kernel Low Latency Read Latency2 Variable Hz 64-bit jiffies Supermount-NG v1.2.11a Bootsplash v3.0.7 POSIX ACL/xattr v0.8.71 POSIX extended security attributes v0.8.71 NTFS file system v2.1.6b Updated: - GCC 3.4 compile fixes. Thanks to Daniel Drake and Benigno Junior Pending: - GRsec update to version 2.1.1. -- Eric Hustvedt <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
[PATCH 7/10] I386: C99 initializers for hw_interrupt_type structures
Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
kernel/i8259.c | 15 +++
mach-voyager/voyager_smp.c | 16
2 files changed, 15 insertions(+), 16 deletions(-)
---
diff -urN 2.6.11-rc5.orig/arch/i386/kernel/i8259.c
2.6.11-rc5/arch/i386/kernel/i8259.c
--- 2.6.11-rc5.orig/arch/i386/kernel/i8259.c2005-01-24 12:25:33.0
+0100
+++ 2.6.11-rc5/arch/i386/kernel/i8259.c 2005-02-26 21:51:58.0 +0100
@@ -58,14 +58,13 @@
}
static struct hw_interrupt_type i8259A_irq_type = {
- "XT-PIC",
- startup_8259A_irq,
- shutdown_8259A_irq,
- enable_8259A_irq,
- disable_8259A_irq,
- mask_and_ack_8259A,
- end_8259A_irq,
- NULL
+ .typename = "XT-PIC",
+ .startup = startup_8259A_irq,
+ .shutdown = shutdown_8259A_irq,
+ .enable = enable_8259A_irq,
+ .disable = disable_8259A_irq,
+ .ack = mask_and_ack_8259A,
+ .end = end_8259A_irq,
};
/*
diff -urN 2.6.11-rc5.orig/arch/i386/mach-voyager/voyager_smp.c
2.6.11-rc5/arch/i386/mach-voyager/voyager_smp.c
--- 2.6.11-rc5.orig/arch/i386/mach-voyager/voyager_smp.c2005-02-14
11:01:03.0 +0100
+++ 2.6.11-rc5/arch/i386/mach-voyager/voyager_smp.c 2005-02-26
20:54:19.0 +0100
@@ -210,14 +210,14 @@
* 8259 IRQs except that masks and things must be kept per processor
*/
static struct hw_interrupt_type vic_irq_type = {
- "VIC-level",
- startup_vic_irq,/* startup */
- disable_vic_irq,/* shutdown */
- enable_vic_irq, /* enable */
- disable_vic_irq,/* disable */
- before_handle_vic_irq, /* ack */
- after_handle_vic_irq, /* end */
- set_vic_irq_affinity, /* affinity */
+ .typename = "VIC-level",
+ .startup = startup_vic_irq,
+ .shutdown = disable_vic_irq,
+ .enable = enable_vic_irq,
+ .disable = disable_vic_irq,
+ .ack = before_handle_vic_irq,
+ .end = after_handle_vic_irq,
+ .set_affinity = set_vic_irq_affinity,
};
/* used to count up as CPUs are brought on line (starts at 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/
[PATCH 10/10] IA64: C99 initializers for hw_interrupt_type structures
Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
irq.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
---
diff -urN 2.6.11-rc5.orig/arch/ia64/sn/kernel/irq.c
2.6.11-rc5/arch/ia64/sn/kernel/irq.c
--- 2.6.11-rc5.orig/arch/ia64/sn/kernel/irq.c 2005-02-14 11:01:04.0
+0100
+++ 2.6.11-rc5/arch/ia64/sn/kernel/irq.c2005-02-26 20:54:19.0
+0100
@@ -194,14 +194,14 @@
}
struct hw_interrupt_type irq_type_sn = {
- "SN hub",
- sn_startup_irq,
- sn_shutdown_irq,
- sn_enable_irq,
- sn_disable_irq,
- sn_ack_irq,
- sn_end_irq,
- sn_set_affinity_irq
+ .typename = "SN hub",
+ .startup = sn_startup_irq,
+ .shutdown = sn_shutdown_irq,
+ .enable = sn_enable_irq,
+ .disable = sn_disable_irq,
+ .ack = sn_ack_irq,
+ .end = sn_end_irq,
+ .set_affinity = sn_set_affinity_irq
};
unsigned int sn_local_vector_to_irq(u8 vector)
-
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 6/10] V850: C99 initializers for hw_interrupt_type structures
Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
irq.c | 14 +++---
setup.c | 14 +++---
sim.c | 14 +++---
3 files changed, 21 insertions(+), 21 deletions(-)
---
diff -urN 2.6.11-rc5.orig/arch/v850/kernel/irq.c
2.6.11-rc5/arch/v850/kernel/irq.c
--- 2.6.11-rc5.orig/arch/v850/kernel/irq.c 2004-12-24 22:35:24.0
+0100
+++ 2.6.11-rc5/arch/v850/kernel/irq.c 2005-02-26 20:54:19.0 +0100
@@ -67,13 +67,13 @@
#define end_none enable_none
struct hw_interrupt_type no_irq_type = {
- "none",
- startup_none,
- shutdown_none,
- enable_none,
- disable_none,
- ack_none,
- end_none
+ .typename = "none",
+ .startup = startup_none,
+ .shutdown = shutdown_none,
+ .enable = enable_none,
+ .disable = disable_none,
+ .ack = ack_none,
+ .end = end_none
};
volatile unsigned long irq_err_count, spurious_count;
diff -urN 2.6.11-rc5.orig/arch/v850/kernel/setup.c
2.6.11-rc5/arch/v850/kernel/setup.c
--- 2.6.11-rc5.orig/arch/v850/kernel/setup.c2004-12-24 22:34:32.0
+0100
+++ 2.6.11-rc5/arch/v850/kernel/setup.c 2005-02-26 20:54:19.0 +0100
@@ -128,13 +128,13 @@
}
static struct hw_interrupt_type nmi_irq_type = {
- "NMI",
- irq_zero, /* startup */
- irq_nop,/* shutdown */
- irq_nop,/* enable */
- irq_nop,/* disable */
- irq_nop,/* ack */
- nmi_end,/* end */
+ .typename = "NMI",
+ .startup = irq_zero,/* startup */
+ .shutdown = irq_nop,/* shutdown */
+ .enable = irq_nop, /* enable */
+ .disable = irq_nop, /* disable */
+ .ack = irq_nop, /* ack */
+ .end = nmi_end, /* end */
};
void __init init_IRQ (void)
diff -urN 2.6.11-rc5.orig/arch/v850/kernel/sim.c
2.6.11-rc5/arch/v850/kernel/sim.c
--- 2.6.11-rc5.orig/arch/v850/kernel/sim.c 2004-12-24 22:35:24.0
+0100
+++ 2.6.11-rc5/arch/v850/kernel/sim.c 2005-02-26 20:54:19.0 +0100
@@ -73,13 +73,13 @@
static unsigned irq_zero (unsigned irq) { return 0; }
static struct hw_interrupt_type sim_irq_type = {
- "IRQ",
- irq_zero, /* startup */
- irq_nop,/* shutdown */
- irq_nop,/* enable */
- irq_nop,/* disable */
- irq_nop,/* ack */
- irq_nop,/* end */
+ .typename = "IRQ",
+ .startup = irq_zero,/* startup */
+ .shutdown = irq_nop,/* shutdown */
+ .enable = irq_nop, /* enable */
+ .disable = irq_nop, /* disable */
+ .ack = irq_nop, /* ack */
+ .end = irq_nop, /* end */
};
void __init mach_init_irqs (void)
-
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 9/10] X86_64: C99 initializers for hw_interrupt_type structures
Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
i8259.c | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
---
diff -urN 2.6.11-rc5.orig/arch/x86_64/kernel/i8259.c
2.6.11-rc5/arch/x86_64/kernel/i8259.c
--- 2.6.11-rc5.orig/arch/x86_64/kernel/i8259.c 2005-01-24 12:25:39.0
+0100
+++ 2.6.11-rc5/arch/x86_64/kernel/i8259.c 2005-02-26 20:54:19.0
+0100
@@ -157,14 +157,13 @@
}
static struct hw_interrupt_type i8259A_irq_type = {
- "XT-PIC",
- startup_8259A_irq,
- shutdown_8259A_irq,
- enable_8259A_irq,
- disable_8259A_irq,
- mask_and_ack_8259A,
- end_8259A_irq,
- NULL
+ .typename = "XT-PIC",
+ .startup = startup_8259A_irq,
+ .shutdown = shutdown_8259A_irq,
+ .enable = enable_8259A_irq,
+ .disable = disable_8259A_irq,
+ .ack = mask_and_ack_8259A,
+ .end = end_8259A_irq,
};
/*
-
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 8/10] SH64: C99 initializers for hw_interrupt_type structures
Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
irq.c | 14 +++---
irq_intc.c | 14 +++---
2 files changed, 14 insertions(+), 14 deletions(-)
---
diff -urN 2.6.11-rc5.orig/arch/sh64/kernel/irq.c
2.6.11-rc5/arch/sh64/kernel/irq.c
--- 2.6.11-rc5.orig/arch/sh64/kernel/irq.c 2004-12-24 22:34:01.0
+0100
+++ 2.6.11-rc5/arch/sh64/kernel/irq.c 2005-02-26 20:54:19.0 +0100
@@ -81,13 +81,13 @@
#define end_none enable_none
struct hw_interrupt_type no_irq_type = {
- "none",
- startup_none,
- shutdown_none,
- enable_none,
- disable_none,
- ack_none,
- end_none
+ .typename= "none",
+ .startup = startup_none,
+ .shutdown = shutdown_none,
+ .enable = enable_none,
+ .disable = disable_none,
+ .ack = ack_none,
+ .end = end_none
};
#if defined(CONFIG_PROC_FS)
diff -urN 2.6.11-rc5.orig/arch/sh64/kernel/irq_intc.c
2.6.11-rc5/arch/sh64/kernel/irq_intc.c
--- 2.6.11-rc5.orig/arch/sh64/kernel/irq_intc.c 2004-12-24 22:35:40.0
+0100
+++ 2.6.11-rc5/arch/sh64/kernel/irq_intc.c 2005-02-26 20:54:19.0
+0100
@@ -107,13 +107,13 @@
static void end_intc_irq(unsigned int irq);
static struct hw_interrupt_type intc_irq_type = {
- "INTC",
- startup_intc_irq,
- shutdown_intc_irq,
- enable_intc_irq,
- disable_intc_irq,
- mask_and_ack_intc,
- end_intc_irq
+ .typename = "INTC",
+ .startup = startup_intc_irq,
+ .shutdown = shutdown_intc_irq,
+ .enable = enable_intc_irq,
+ .disable = disable_intc_irq,
+ .ack = mask_and_ack_intc,
+ .end = end_intc_irq
};
static int irlm; /* IRL mode */
-
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 3/10] SH: C99 initializers for hw_interrupt_type structures
Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
boards/adx/irq_maskreg.c | 14 +++---
boards/bigsur/irq.c | 28 ++--
boards/cqreek/irq.c | 14 +++---
boards/harp/irq.c| 14 +++---
boards/overdrive/irq.c | 14 +++---
boards/renesas/hs7751rvoip/irq.c | 14 +++---
boards/renesas/rts7751r2d/irq.c | 14 +++---
boards/renesas/systemh/irq.c | 14 +++---
boards/superh/microdev/irq.c | 14 +++---
cchips/voyagergx/irq.c | 14 +++---
kernel/cpu/irq_imask.c | 14 +++---
kernel/cpu/irq_ipr.c | 28 ++--
kernel/cpu/sh4/irq_intc2.c | 14 +++---
kernel/irq.c | 14 +++---
14 files changed, 112 insertions(+), 112 deletions(-)
---
diff -urN 2.6.11-rc5.orig/arch/sh/boards/adx/irq_maskreg.c
2.6.11-rc5/arch/sh/boards/adx/irq_maskreg.c
--- 2.6.11-rc5.orig/arch/sh/boards/adx/irq_maskreg.c2004-12-24
22:33:48.0 +0100
+++ 2.6.11-rc5/arch/sh/boards/adx/irq_maskreg.c 2005-02-26 20:54:19.0
+0100
@@ -37,13 +37,13 @@
/* hw_interrupt_type */
static struct hw_interrupt_type maskreg_irq_type = {
- " Mask Register",
- startup_maskreg_irq,
- shutdown_maskreg_irq,
- enable_maskreg_irq,
- disable_maskreg_irq,
- mask_and_ack_maskreg,
- end_maskreg_irq
+ .typename = " Mask Register",
+ .startup = startup_maskreg_irq,
+ .shutdown = shutdown_maskreg_irq,
+ .enable = enable_maskreg_irq,
+ .disable = disable_maskreg_irq,
+ .ack = mask_and_ack_maskreg,
+ .end = end_maskreg_irq
};
/* actual implementatin */
diff -urN 2.6.11-rc5.orig/arch/sh/boards/bigsur/irq.c
2.6.11-rc5/arch/sh/boards/bigsur/irq.c
--- 2.6.11-rc5.orig/arch/sh/boards/bigsur/irq.c 2004-12-24 22:35:24.0
+0100
+++ 2.6.11-rc5/arch/sh/boards/bigsur/irq.c 2005-02-26 20:54:19.0
+0100
@@ -228,23 +228,23 @@
/* Define the IRQ structures for the L1 and L2 IRQ types */
static struct hw_interrupt_type bigsur_l1irq_type = {
-"BigSur-CPLD-Level1-IRQ",
-startup_bigsur_irq,
-shutdown_bigsur_irq,
-enable_bigsur_l1irq,
-disable_bigsur_l1irq,
-mask_and_ack_bigsur,
-end_bigsur_irq
+ .typename = "BigSur-CPLD-Level1-IRQ",
+ .startup = startup_bigsur_irq,
+ .shutdown = shutdown_bigsur_irq,
+ .enable = enable_bigsur_l1irq,
+ .disable = disable_bigsur_l1irq,
+ .ack = mask_and_ack_bigsur,
+ .end = end_bigsur_irq
};
static struct hw_interrupt_type bigsur_l2irq_type = {
-"BigSur-CPLD-Level2-IRQ",
-startup_bigsur_irq,
-shutdown_bigsur_irq,
-enable_bigsur_l2irq,
-disable_bigsur_l2irq,
-mask_and_ack_bigsur,
-end_bigsur_irq
+ .typename = "BigSur-CPLD-Level2-IRQ",
+ .startup = startup_bigsur_irq,
+ .shutdown =shutdown_bigsur_irq,
+ .enable = enable_bigsur_l2irq,
+ .disable = disable_bigsur_l2irq,
+ .ack = mask_and_ack_bigsur,
+ .end = end_bigsur_irq
};
diff -urN 2.6.11-rc5.orig/arch/sh/boards/cqreek/irq.c
2.6.11-rc5/arch/sh/boards/cqreek/irq.c
--- 2.6.11-rc5.orig/arch/sh/boards/cqreek/irq.c 2004-12-24 22:35:00.0
+0100
+++ 2.6.11-rc5/arch/sh/boards/cqreek/irq.c 2005-02-26 20:54:19.0
+0100
@@ -83,13 +83,13 @@
}
static struct hw_interrupt_type cqreek_irq_type = {
- "CqREEK-IRQ",
- startup_cqreek_irq,
- shutdown_cqreek_irq,
- enable_cqreek_irq,
- disable_cqreek_irq,
- mask_and_ack_cqreek,
- end_cqreek_irq
+ .typename = "CqREEK-IRQ",
+ .startup = startup_cqreek_irq,
+ .shutdown = shutdown_cqreek_irq,
+ .enable = enable_cqreek_irq,
+ .disable = disable_cqreek_irq,
+ .ack = mask_and_ack_cqreek,
+ .end = end_cqreek_irq
};
int cqreek_has_ide, cqreek_has_isa;
diff -urN 2.6.11-rc5.orig/arch/sh/boards/harp/irq.c
2.6.11-rc5/arch/sh/boards/harp/irq.c
--- 2.6.11-rc5.orig/arch/sh/boards/harp/irq.c 2004-12-24 22:34:45.0
+0100
+++ 2.6.11-rc5/arch/sh/boards/harp/irq.c2005-02-26 20:54:19.0
+0100
@@ -39,13 +39,13 @@
}
static struct hw_interrupt_type harp_irq_type = {
- "Harp-IRQ",
- startup_harp_irq,
- shutdown_harp_irq,
- enable_harp_irq,
- disable_harp_irq,
- mask_and_ack_harp,
- end_harp_irq
+ .typename = "Harp-IRQ",
+ .startup = startup_harp_irq,
+ .shutdown = shutdown_harp_irq,
+ .enable = enable_harp_irq,
+ .disable = disable_harp_irq,
+ .ack = mask_and_ack_harp,
+ .end = end_harp_irq
};
static void disable_harp_irq(unsigned int irq)
diff -urN 2.6.11-rc5.orig/arch/sh/boards/overd
[PATCH 5/10] MIPS: C99 initializers for hw_interrupt_type structures
Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
au1000/common/irq.c | 60 +++--
ddb5xxx/ddb5074/nile4_pic.c | 15 +++-
ddb5xxx/ddb5476/vrc5476_irq.c | 15 +++-
ddb5xxx/ddb5477/irq_5477.c| 15 +++-
ite-boards/generic/irq.c | 29 +++-
jazz/irq.c| 15 +++-
jmr3927/rbhma3100/irq.c | 14 +++
kernel/i8259.c| 15 +++-
kernel/irq-msc01.c| 30 +++-
kernel/irq-mv6434x.c | 15 +++-
kernel/irq-rm7000.c | 14 +++
kernel/irq-rm9000.c | 28 +++
kernel/irq_cpu.c | 15 +++-
lasat/interrupt.c | 15 +++-
mips-boards/atlas/atlas_int.c | 15 +++-
momentum/ocelot_c/cpci-irq.c | 15 +++-
momentum/ocelot_c/uart-irq.c | 15 +++-
sgi-ip32/ip32-irq.c | 75 +++---
sibyte/sb1250/irq.c | 18 --
sni/irq.c | 15 +++-
vr4181/common/irq.c | 30 +++-
21 files changed, 225 insertions(+), 253 deletions(-)
---
diff -urN 2.6.11-rc5.orig/arch/mips/au1000/common/irq.c
2.6.11-rc5/arch/mips/au1000/common/irq.c
--- 2.6.11-rc5.orig/arch/mips/au1000/common/irq.c 2005-02-14
11:01:04.0 +0100
+++ 2.6.11-rc5/arch/mips/au1000/common/irq.c2005-02-26 20:54:19.0
+0100
@@ -253,47 +253,43 @@
static struct hw_interrupt_type rise_edge_irq_type = {
- "Au1000 Rise Edge",
- startup_irq,
- shutdown_irq,
- local_enable_irq,
- local_disable_irq,
- mask_and_ack_rise_edge_irq,
- end_irq,
- NULL
+ .typename = "Au1000 Rise Edge",
+ .startup = startup_irq,
+ .shutdown = shutdown_irq,
+ .enable = local_enable_irq,
+ .disable = local_disable_irq,
+ .ack = mask_and_ack_rise_edge_irq,
+ .end = end_irq,
};
static struct hw_interrupt_type fall_edge_irq_type = {
- "Au1000 Fall Edge",
- startup_irq,
- shutdown_irq,
- local_enable_irq,
- local_disable_irq,
- mask_and_ack_fall_edge_irq,
- end_irq,
- NULL
+ .typename = "Au1000 Fall Edge",
+ .startup = startup_irq,
+ .shutdown = shutdown_irq,
+ .enable = local_enable_irq,
+ .disable = local_disable_irq,
+ .ack = mask_and_ack_fall_edge_irq,
+ .end = end_irq,
};
static struct hw_interrupt_type either_edge_irq_type = {
- "Au1000 Rise or Fall Edge",
- startup_irq,
- shutdown_irq,
- local_enable_irq,
- local_disable_irq,
- mask_and_ack_either_edge_irq,
- end_irq,
- NULL
+ .typename = "Au1000 Rise or Fall Edge",
+ .startup = startup_irq,
+ .shutdown = shutdown_irq,
+ .enable = local_enable_irq,
+ .disable = local_disable_irq,
+ .ack = mask_and_ack_either_edge_irq,
+ .end = end_irq,
};
static struct hw_interrupt_type level_irq_type = {
- "Au1000 Level",
- startup_irq,
- shutdown_irq,
- local_enable_irq,
- local_disable_irq,
- mask_and_ack_level_irq,
- end_irq,
- NULL
+ .typename = "Au1000 Level",
+ .startup = startup_irq,
+ .shutdown = shutdown_irq,
+ .enable = local_enable_irq,
+ .disable = local_disable_irq,
+ .ack = mask_and_ack_level_irq,
+ .end = end_irq,
};
#ifdef CONFIG_PM
diff -urN 2.6.11-rc5.orig/arch/mips/ddb5xxx/ddb5074/nile4_pic.c
2.6.11-rc5/arch/mips/ddb5xxx/ddb5074/nile4_pic.c
--- 2.6.11-rc5.orig/arch/mips/ddb5xxx/ddb5074/nile4_pic.c 2004-12-24
22:35:50.0 +0100
+++ 2.6.11-rc5/arch/mips/ddb5xxx/ddb5074/nile4_pic.c2005-02-26
20:54:19.0 +0100
@@ -209,14 +209,13 @@
#define nile4_irq_shutdown nile4_disable_irq
static hw_irq_controller nile4_irq_controller = {
-"nile4",
-nile4_irq_startup,
-nile4_irq_shutdown,
-nile4_enable_irq,
-nile4_disable_irq,
-nile4_ack_irq,
-nile4_irq_end,
-NULL
+ .typename = "nile4",
+ .startup = nile4_irq_startup,
+ .shutdown = nile4_irq_shutdown,
+ .enable = nile4_enable_irq,
+ .disable = nile4_disable_irq,
+ .ack = nile4_ack_irq,
+ .end = nile4_irq_end,
};
void nile4_irq_setup(u32 base) {
diff -urN 2.6.11-rc5.orig/arch/mips/ddb5xxx/ddb5476/vrc5476_irq.c
2.6.11-rc5/arch/mips/ddb5xxx/ddb5476/vrc5476_irq.c
--- 2.6.11-rc5.orig/arch/mips/ddb5xxx/ddb5476/vrc5476_irq.c 2004-12-24
22:35:25.0 +0100
+++ 2.6.11-rc5/arch/mips/ddb5xxx/ddb5476/vrc5476_irq.c 2005-02-26
20:54:19.0 +0100
@@ -53,14 +53,13 @@
}
static hw_irq_controller vrc5476_irq_controller = {
- "vrc5476",
- vrc5476_irq_startup,
- vrc5476_irq_shutdown,
- vrc5476_irq_enable,
- vrc5476_irq_disable,
- vrc5476
[PATCH 4/10] PPC64: C99 initializers for hw_interrupt_type structures
Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
i8259.c | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
---
diff -urN 2.6.11-rc5.orig/arch/ppc64/kernel/i8259.c
2.6.11-rc5/arch/ppc64/kernel/i8259.c
--- 2.6.11-rc5.orig/arch/ppc64/kernel/i8259.c 2005-01-24 12:25:36.0
+0100
+++ 2.6.11-rc5/arch/ppc64/kernel/i8259.c2005-02-26 20:54:19.0
+0100
@@ -131,14 +131,11 @@
}
struct hw_interrupt_type i8259_pic = {
-" i8259",
-NULL,
-NULL,
-i8259_unmask_irq,
-i8259_mask_irq,
-i8259_mask_and_ack_irq,
-i8259_end_irq,
-NULL
+ .typename = " i8259",
+ .enable = i8259_unmask_irq,
+ .disable = i8259_mask_irq,
+ .ack = i8259_mask_and_ack_irq,
+ .end = i8259_end_irq,
};
void __init i8259_init(int offset)
-
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/10] M32R: C99 initializers for hw_interrupt_type structures
Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
setup_m32700ut.c | 56 +++
setup_mappi.c| 14 ++---
setup_mappi2.c | 14 ++---
setup_oaks32r.c | 14 ++---
setup_opsput.c | 56 +++
setup_usrv.c | 28 +--
6 files changed, 91 insertions(+), 91 deletions(-)
---
diff -urN 2.6.11-rc5.orig/arch/m32r/kernel/setup_m32700ut.c
2.6.11-rc5/arch/m32r/kernel/setup_m32700ut.c
--- 2.6.11-rc5.orig/arch/m32r/kernel/setup_m32700ut.c 2004-12-24
22:35:27.0 +0100
+++ 2.6.11-rc5/arch/m32r/kernel/setup_m32700ut.c2005-02-26
20:54:19.0 +0100
@@ -78,13 +78,13 @@
static struct hw_interrupt_type m32700ut_irq_type =
{
- "M32700UT-IRQ",
- startup_m32700ut_irq,
- shutdown_m32700ut_irq,
- enable_m32700ut_irq,
- disable_m32700ut_irq,
- mask_and_ack_m32700ut,
- end_m32700ut_irq
+ .typename = "M32700UT-IRQ",
+ .startup = startup_m32700ut_irq,
+ .shutdown = shutdown_m32700ut_irq,
+ .enable = enable_m32700ut_irq,
+ .disable = disable_m32700ut_irq,
+ .ack = mask_and_ack_m32700ut,
+ .end = end_m32700ut_irq
};
/*
@@ -155,13 +155,13 @@
static struct hw_interrupt_type m32700ut_pld_irq_type =
{
- "M32700UT-PLD-IRQ",
- startup_m32700ut_pld_irq,
- shutdown_m32700ut_pld_irq,
- enable_m32700ut_pld_irq,
- disable_m32700ut_pld_irq,
- mask_and_ack_m32700ut_pld,
- end_m32700ut_pld_irq
+ .typename = "M32700UT-PLD-IRQ",
+ .startup = startup_m32700ut_pld_irq,
+ .shutdown = shutdown_m32700ut_pld_irq,
+ .enable = enable_m32700ut_pld_irq,
+ .disable = disable_m32700ut_pld_irq,
+ .ack = mask_and_ack_m32700ut_pld,
+ .end = end_m32700ut_pld_irq
};
/*
@@ -224,13 +224,13 @@
static struct hw_interrupt_type m32700ut_lanpld_irq_type =
{
- "M32700UT-PLD-LAN-IRQ",
- startup_m32700ut_lanpld_irq,
- shutdown_m32700ut_lanpld_irq,
- enable_m32700ut_lanpld_irq,
- disable_m32700ut_lanpld_irq,
- mask_and_ack_m32700ut_lanpld,
- end_m32700ut_lanpld_irq
+ .typename = "M32700UT-PLD-LAN-IRQ",
+ .startup = startup_m32700ut_lanpld_irq,
+ .shutdown = shutdown_m32700ut_lanpld_irq,
+ .enable = enable_m32700ut_lanpld_irq,
+ .disable = disable_m32700ut_lanpld_irq,
+ .ack = mask_and_ack_m32700ut_lanpld,
+ .end = end_m32700ut_lanpld_irq
};
/*
@@ -293,13 +293,13 @@
static struct hw_interrupt_type m32700ut_lcdpld_irq_type =
{
- "M32700UT-PLD-LCD-IRQ",
- startup_m32700ut_lcdpld_irq,
- shutdown_m32700ut_lcdpld_irq,
- enable_m32700ut_lcdpld_irq,
- disable_m32700ut_lcdpld_irq,
- mask_and_ack_m32700ut_lcdpld,
- end_m32700ut_lcdpld_irq
+ .typename = "M32700UT-PLD-LCD-IRQ",
+ .startup = startup_m32700ut_lcdpld_irq,
+ .shutdown = shutdown_m32700ut_lcdpld_irq,
+ .enable = enable_m32700ut_lcdpld_irq,
+ .disable = disable_m32700ut_lcdpld_irq,
+ .ack = mask_and_ack_m32700ut_lcdpld,
+ .end = end_m32700ut_lcdpld_irq
};
void __init init_IRQ(void)
diff -urN 2.6.11-rc5.orig/arch/m32r/kernel/setup_mappi2.c
2.6.11-rc5/arch/m32r/kernel/setup_mappi2.c
--- 2.6.11-rc5.orig/arch/m32r/kernel/setup_mappi2.c 2004-12-24
22:35:50.0 +0100
+++ 2.6.11-rc5/arch/m32r/kernel/setup_mappi2.c 2005-02-26 20:54:19.0
+0100
@@ -79,13 +79,13 @@
static struct hw_interrupt_type mappi2_irq_type =
{
- "MAPPI2-IRQ",
- startup_mappi2_irq,
- shutdown_mappi2_irq,
- enable_mappi2_irq,
- disable_mappi2_irq,
- mask_and_ack_mappi2,
- end_mappi2_irq
+ .typename = "MAPPI2-IRQ",
+ .startup = startup_mappi2_irq,
+ .shutdown = shutdown_mappi2_irq,
+ .enable = enable_mappi2_irq,
+ .disable = disable_mappi2_irq,
+ .ack = mask_and_ack_mappi2,
+ .end = end_mappi2_irq
};
void __init init_IRQ(void)
diff -urN 2.6.11-rc5.orig/arch/m32r/kernel/setup_mappi.c
2.6.11-rc5/arch/m32r/kernel/setup_mappi.c
--- 2.6.11-rc5.orig/arch/m32r/kernel/setup_mappi.c 2004-12-24
22:35:00.0 +0100
+++ 2.6.11-rc5/arch/m32r/kernel/setup_mappi.c 2005-02-26 20:54:19.0
+0100
@@ -70,13 +70,13 @@
static struct hw_interrupt_type mappi_irq_type =
{
- "MAPPI-IRQ",
- startup_mappi_irq,
- shutdown_mappi_irq,
- enable_mappi_irq,
- disable_mappi_irq,
- mask_and_ack_mappi,
- end_mappi_irq
+ .typename = "MAPPI-IRQ",
+ .startup = startup_mappi_irq,
+ .shutdown = shutdown_mappi_irq,
+ .enable = enable_mappi_irq,
+ .disable = disable_mappi_irq,
+ .ack = mask_and_ack_mappi,
+ .end = end_mappi_irq
};
void __init init_IRQ(void)
d
[PATCH 1/10] PPC: C99 initializers for hw_interrupt_type structures
Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
platforms/adir_pic.c | 12
syslib/cpc700_pic.c | 12
syslib/cpm2_pic.c| 13 +
syslib/i8259.c | 13 +
syslib/mpc52xx_pic.c | 13 +
syslib/open_pic2.c | 12 +---
syslib/ppc403_pic.c | 11 ---
syslib/xilinx_pic.c | 13 +
8 files changed, 37 insertions(+), 62 deletions(-)
---
diff -urN 2.6.11-rc5.orig/arch/ppc/platforms/adir_pic.c
2.6.11-rc5/arch/ppc/platforms/adir_pic.c
--- 2.6.11-rc5.orig/arch/ppc/platforms/adir_pic.c 2004-12-24
22:33:52.0 +0100
+++ 2.6.11-rc5/arch/ppc/platforms/adir_pic.c2005-02-26 20:54:19.0
+0100
@@ -73,14 +73,10 @@
}
static struct hw_interrupt_type adir_onboard_pic = {
- " ADIR PIC ",
- NULL,
- NULL,
- adir_onboard_pic_enable,/* unmask */
- adir_onboard_pic_disable, /* mask */
- adir_onboard_pic_disable, /* mask and ack */
- NULL,
- NULL
+ .typename = " ADIR PIC ",
+ .enable = adir_onboard_pic_enable, /* unmask */
+ .disable = adir_onboard_pic_disable,/* mask */
+ .ack = adir_onboard_pic_disable,/* mask and ack */
};
static struct irqaction noop_action = {
diff -urN 2.6.11-rc5.orig/arch/ppc/syslib/cpc700_pic.c
2.6.11-rc5/arch/ppc/syslib/cpc700_pic.c
--- 2.6.11-rc5.orig/arch/ppc/syslib/cpc700_pic.c2004-12-24
22:34:26.0 +0100
+++ 2.6.11-rc5/arch/ppc/syslib/cpc700_pic.c 2005-02-26 20:54:19.0
+0100
@@ -90,14 +90,10 @@
}
static struct hw_interrupt_type cpc700_pic = {
- "CPC700 PIC",
- NULL,
- NULL,
- cpc700_unmask_irq,
- cpc700_mask_irq,
- cpc700_mask_and_ack_irq,
- NULL,
- NULL
+ .typename = "CPC700 PIC",
+ .enable = cpc700_unmask_irq,
+ .disable = cpc700_mask_irq,
+ .ack = cpc700_mask_and_ack_irq,
};
__init static void
diff -urN 2.6.11-rc5.orig/arch/ppc/syslib/cpm2_pic.c
2.6.11-rc5/arch/ppc/syslib/cpm2_pic.c
--- 2.6.11-rc5.orig/arch/ppc/syslib/cpm2_pic.c 2004-12-24 22:34:57.0
+0100
+++ 2.6.11-rc5/arch/ppc/syslib/cpm2_pic.c 2005-02-26 20:54:19.0
+0100
@@ -102,14 +102,11 @@
}
struct hw_interrupt_type cpm2_pic = {
- " CPM2 SIU ",
- NULL,
- NULL,
- cpm2_unmask_irq,
- cpm2_mask_irq,
- cpm2_mask_and_ack,
- cpm2_end_irq,
- 0
+ .typename = " CPM2 SIU ",
+ .enable = cpm2_unmask_irq,
+ .disable = cpm2_mask_irq,
+ .ack = cpm2_mask_and_ack,
+ .end = cpm2_end_irq,
};
diff -urN 2.6.11-rc5.orig/arch/ppc/syslib/i8259.c
2.6.11-rc5/arch/ppc/syslib/i8259.c
--- 2.6.11-rc5.orig/arch/ppc/syslib/i8259.c 2005-02-26 20:38:12.0
+0100
+++ 2.6.11-rc5/arch/ppc/syslib/i8259.c 2005-02-26 20:54:19.0 +0100
@@ -129,14 +129,11 @@
}
struct hw_interrupt_type i8259_pic = {
- " i8259",
- NULL,
- NULL,
- i8259_unmask_irq,
- i8259_mask_irq,
- i8259_mask_and_ack_irq,
- i8259_end_irq,
- NULL
+ .typename = " i8259",
+ .enable = i8259_unmask_irq,
+ .disable = i8259_mask_irq,
+ .ack = i8259_mask_and_ack_irq,
+ .end = i8259_end_irq,
};
static struct resource pic1_iores = {
diff -urN 2.6.11-rc5.orig/arch/ppc/syslib/mpc52xx_pic.c
2.6.11-rc5/arch/ppc/syslib/mpc52xx_pic.c
--- 2.6.11-rc5.orig/arch/ppc/syslib/mpc52xx_pic.c 2004-12-24
22:35:59.0 +0100
+++ 2.6.11-rc5/arch/ppc/syslib/mpc52xx_pic.c2005-02-26 20:54:19.0
+0100
@@ -166,14 +166,11 @@
}
static struct hw_interrupt_type mpc52xx_ic = {
- "MPC52xx",
- NULL, /* startup(irq) */
- NULL, /* shutdown(irq) */
- mpc52xx_ic_enable, /* enable(irq) */
- mpc52xx_ic_disable, /* disable(irq) */
- mpc52xx_ic_disable_and_ack, /* disable_and_ack(irq) */
- mpc52xx_ic_end, /* end(irq) */
- 0 /* set_affinity(irq, cpumask) SMP. */
+ .typename = "MPC52xx",
+ .enable = mpc52xx_ic_enable,/* enable(irq) */
+ .disable = mpc52xx_ic_disable, /* disable(irq) */
+ .ack = mpc52xx_ic_disable_and_ack, /* disable_and_ack(irq) */
+ .end = mpc52xx_ic_end, /* end(irq) */
};
void __init
diff -urN 2.6.11-rc5.orig/arch/ppc/syslib/open_pic2.c
2.6.11-rc5/arch/ppc/syslib/open_pic2.c
--- 2.6.11-rc5.orig/arch/ppc/syslib/open_pic2.c 2005-01-24 12:25:36.0
+0100
+++ 2.6.11-rc5/arch/ppc/syslib/open_pic2.c 2005-02-26 20:54:19.0
+0100
@@ -83,13 +83,11 @@
static void openpic2_ack_irq(unsigned int irq_nr);
struct hw_interrupt_type open_pic2 = {
- " OpenPIC2 ",
- NUL
Re: [PATCH] partitions/msdos.c
On Sat, Feb 26, 2005 at 03:46:03PM -0800, Linus Torvalds wrote:
> We should probably do the same for the
> extended partition case, just to be consistent.
True.
diff -uprN -X /linux/dontdiff a/fs/partitions/msdos.c b/fs/partitions/msdos.c
--- a/fs/partitions/msdos.c 2004-12-29 03:39:55.0 +0100
+++ b/fs/partitions/msdos.c 2005-02-27 01:10:06.0 +0100
@@ -114,6 +114,9 @@ parse_extended(struct parsed_partitions
*/
for (i=0; i<4; i++, p++) {
u32 offs, size, next;
+
+ if (SYS_IND(p) == 0)
+ continue;
if (!NR_SECTS(p) || is_extended_partition(p))
continue;
@@ -430,6 +433,8 @@ int msdos_partition(struct parsed_partit
for (slot = 1 ; slot <= 4 ; slot++, p++) {
u32 start = START_SECT(p)*sector_size;
u32 size = NR_SECTS(p)*sector_size;
+ if (SYS_IND(p) == 0)
+ continue;
if (!size)
continue;
if (is_extended_partition(p)) {
-
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] partitions/msdos.c
On Sun, 27 Feb 2005, Andries Brouwer wrote: > > (Concerning the "size" version: it occurred to me that there is one > very minor objection: For extended partitions so far the size did > not normally play a role. Only the starting sector was significant. > If, at some moment we decide also to check the size, then a weaker > check, namely only checking for non-extended partitions, might be > better at first.) Yes. I agree - checking the size is likely _more_ dangerous and likely to break something silly than checking the ID for zero. So your patch it is. I'll put it in immediately after doing a 2.6.11 (no need to worry about getting into 2.6.11, since afaik the worst problem right now is an extra partition that isn't usable). 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: [PATCH] config option for default loglevel
Matthias Kunze <[EMAIL PROTECTED]> wrote: > > I've created a little patch to make the default loglevel a configurable > option. It'd be better to make it a kernel boot option, IMO. We already have `debug' and `quiet' (init/main.c), which are rather silly things. An option to set the initial loglevel would make sense. - 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] partitions/msdos.c
On Sun, 27 Feb 2005, Uwe Bonnes wrote: > > /dev/sda4 3512348 6003585 698791990+ 0 Empty > Partition 4 has different physical/logical beginnings (non-Linux?): > phys=(0, 0, 0) logical=(3512347, 6, 16) > Partition 4 has different physical/logical endings: > phys=(0, 0, 0) logical=(6003584, 7, 6) > Partition 4 does not end on cylinder boundary. Yeah, your case could check for zero in the physical sector stuff too, but I'm not sure that matters, since nobody really cares about the physical values and they've long been too limited to matter. So I'm not at all convinced that adding a few more checks for zero would be any better than checking the one zero that Andries does. I think Andries' patch is fine. We should probably do the same for the extended partition case, just to be consistent. 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: [PATCH] partitions/msdos.c
On Sat, Feb 26, 2005 at 03:12:28PM -0800, Linus Torvalds wrote: > > The default fdisk will assign type 83 to a newly created partition. > > Ok. Is that a "it has done so for the last 5 years" thing? The last twelve years. > > (About type 0: DOS has used type 0 as definition of unused. It is not > > bad if Linux uses DOS-conventions for a DOS-type partition table.) > > Agreed. At the same time, I could well imagine that some people might use > such a type exactly to make DOS ignore it (but I assume the same is true > of the regular 0x83 type too, so maybe I'm just being difficult). > > There's certainly a good argument for fixing a known problem (Uwe) and a > small enough risk of it breaking anything else. Yes. Andries (Concerning the "size" version: it occurred to me that there is one very minor objection: For extended partitions so far the size did not normally play a role. Only the starting sector was significant. If, at some moment we decide also to check the size, then a weaker check, namely only checking for non-extended partitions, might be better at first.) (Yes, disk capacity is not always known - see e.g. ll_rw_blk.c: /* Test device or partition size, when known. */ See also sd.c, with the strange sdkp->capacity = 0x20; /* 1 GB - random */ In such cases we just access the blocks user space tells us to access.) - 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] Dump partition list on inability to mount /
Hi,
The attached patch dumps a list of partitions (in a similar
format to /proc/partitions) to the console just before the kernel
panics complaining that it can't mount /, the aim being to allow
the victim to see quickly if all his devices have been found
and to understand if they have the names he expects them to have.
This is especially useful when debugging problems on other
peoples machines, systems you don't know the hardware config of,
or machines where the config has just changed (who moved
that scsi device.). The patch displays the minor/major
numbers (in hex for use on a root=), the name and the name
of the device driver associated with it (e.g. ide-disk) -
suggestions on easy ways to get the model of the device
in a generic way would be appreciated.
One of the annoying things about the fail to mount / panics is that you
can no longer scroll up to find out what errors came from device driver
initialisation - I'm tempted to remove or delay the panics. Thoughts?
The patch is against 2.6.11-rc5 and has been tested on Alpha and x86.
I ask that it be included in the main kernel tree.
Comments and reports welcome.
Dave
Signed off by: Dave Gilbert <[EMAIL PROTECTED]>
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _|_ http://www.treblig.org |___/
diff -urN linux-2.6.11-rc5.orig/drivers/block/genhd.c
linux-2.6.11-rc5/drivers/block/genhd.c
--- linux-2.6.11-rc5.orig/drivers/block/genhd.c 2005-02-24 16:40:25.0
+
+++ linux-2.6.11-rc5/drivers/block/genhd.c 2005-02-26 21:17:02.0
+
@@ -219,6 +219,52 @@
return kobj ? to_disk(kobj) : NULL;
}
+/*
+ * printk a full list of all partitions - intended for
+ * places where the root filesystem can't be mounted and thus
+ * to give the victim some idea of what went wrong
+ */
+void printk_all_partitions(void)
+{
+ int n;
+struct gendisk* sgp;
+ down(&block_subsys_sem);
+
+/* For each block device... */
+ list_for_each_entry(sgp,&block_subsys.kset.list, kobj.entry) {
+ char buf[BDEVNAME_SIZE];
+ /* Don't show empty devices or things that have been surpressed
*/
+ if (get_capacity(sgp) && !(sgp->flags &
GENHD_FL_SUPPRESS_PARTITION_INFO)) {
+ /* Note, unlike /proc/partitions I'm showing the
numbers in hex
+ in the same format as the root= option */
+ printk("%02x%02x %10llu %s",
+ sgp->major, sgp->first_minor,
+ (unsigned long long)get_capacity(sgp) >> 1,
+ disk_name(sgp, 0, buf));
+ if ((sgp->driverfs_dev) && (sgp->driverfs_dev->driver))
{
+ printk(" driver: %s\n",
sgp->driverfs_dev->driver->name);
+ } else {
+ printk(" (driver?)\n");
+ }
+
+ /* now show the partitions */
+ for (n = 0; n < sgp->minors - 1; n++) {
+ if (!sgp->part[n])
+ continue;
+ if (sgp->part[n]->nr_sects == 0)
+ continue;
+ printk(" %02x%02x %10llu %s\n",
+ sgp->major, n + 1 + sgp->first_minor,
+ (unsigned long
long)sgp->part[n]->nr_sects >> 1 ,
+ disk_name(sgp, n + 1, buf));
+ } /* partition subloop */
+ } /* Non 0 size, not surpressed */
+ } /* Block device loop */
+
+ up(&block_subsys_sem);
+
+}
+
#ifdef CONFIG_PROC_FS
/* iterator */
static void *part_start(struct seq_file *part, loff_t *pos)
diff -urN linux-2.6.11-rc5.orig/include/linux/genhd.h
linux-2.6.11-rc5/include/linux/genhd.h
--- linux-2.6.11-rc5.orig/include/linux/genhd.h 2005-02-24 16:39:54.0
+
+++ linux-2.6.11-rc5/include/linux/genhd.h 2005-02-26 19:41:13.0
+
@@ -250,6 +250,7 @@
disk->capacity = size;
}
+
#endif /* __KERNEL__ */
#ifdef CONFIG_SOLARIS_X86_PARTITION
@@ -402,6 +403,7 @@
extern int rescan_partitions(struct gendisk *disk, struct block_device *bdev);
extern void add_partition(struct gendisk *, int, sector_t, sector_t);
extern void delete_partition(struct gendisk *, int);
+extern void printk_all_partitions(void);
extern struct gendisk *alloc_disk(int minors);
extern struct kobject *get_disk(struct gendisk *disk);
diff -urN linux-2.6.11-rc5.orig/init/do_mounts.c
linux-2.6.11-rc5/init/do_mounts.c
--- linux-2.6.11-rc5.orig/init/do_mounts.c 2005-02-24 16:40:14.0
+
+++ linux-2.6.11-rc5
Re: [PATCH] partitions/msdos.c
> "Linus" == Linus Torvalds <[EMAIL PROTECTED]> writes: Linus> On Sat, 26 Feb 2005, Linus Torvalds wrote: >> Would it not make more sense to just sanity-check the size itself, >> and throw it out if the partition size (plus start) is bigger than >> the disk size? Linus> Something like this (TOTALLY UNTESTED AS USUAL!)? Yes, no phantom partitions also with your approach. Linus> What does fdisk and other tools do on that disk? Just out of Linus> interest.. To be honest: r50:~ # fdisk /dev/sda Command (m for help): p Disk /dev/sda: 65 MB, 65536000 bytes 17 heads, 33 sectors/track, 228 cylinders Units = cylinders of 561 * 512 = 287232 bytes Device Boot Start End Blocks Id System /dev/sda1 1 229 63981+ 6 FAT16 Partition 1 has different physical/logical beginnings (non-Linux?): phys=(0, 1, 1) logical=(0, 1, 5) Partition 1 has different physical/logical endings: phys=(125, 16, 33) logical=(228, 2, 26) /dev/sda4 3512348 6003585 698791990+ 0 Empty Partition 4 has different physical/logical beginnings (non-Linux?): phys=(0, 0, 0) logical=(3512347, 6, 16) Partition 4 has different physical/logical endings: phys=(0, 0, 0) logical=(6003584, 7, 6) Partition 4 does not end on cylinder boundary. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- - 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] Re: 2.6.11-rc4 libata-core (irq 30: nobody cared!)
First of all, thank you very much for your reply, Jeff. On Feb 26 2005, Jeff Garzik wrote: > "irq XX: nobody cared" is a screaming interrupt situation, which could > have 1001 causes. Ok, I didn't know that. > Normally it's something that "pci=biosirq" or "acpi=off" will fix, but > on occasion the driver itself is what needs fixing. Well, I already tried both of those options (and some others too) and nothing seems to make my kernel quiet regarding my Promise controller (just as a reminder, it is a PDC20265, embedded in my Asus A7V motherboard). If you want me to test any patches, feel free to contact me. Thanks, Rogério Brito. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - 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] partitions/msdos.c
On Sat, 26 Feb 2005, Andries Brouwer wrote: > > The default fdisk will assign type 83 to a newly created partition. Ok. Is that a "it has done so for the last 5 years" thing? > (About type 0: DOS has used type 0 as definition of unused. It is not > bad if Linux uses DOS-conventions for a DOS-type partition table.) Agreed. At the same time, I could well imagine that some people might use such a type exactly to make DOS ignore it (but I assume the same is true of the regular 0x83 type too, so maybe I'm just being difficult). There's certainly a good argument for fixing a known problem (Uwe) and a small enough risk of it breaking anything else. 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: ALPS touchpad not seen by 2.6.11 kernels
I have had the same problem and the solution worked for me as well. Where should I put the DSDT? Please reply to my e-mail, as I am no linux-kernel subscriber. Victor Fischer - 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] partitions/msdos.c
On Sat, Feb 26, 2005 at 02:28:45PM -0800, Linus Torvalds wrote: > Would it not make more sense to just sanity-check the size itself, and > throw it out if the partition size (plus start) is bigger than the disk > size? I don't mind. > There might well be people use use partition type 0, just because they > just never _set_ the partition type.. I don't think Linux has ever cared > about any type except for the "extended partition" type, so checking for > zero doesn't seem very safe.. The default fdisk will assign type 83 to a newly created partition. One has to change it by hand to 0. So, I do not think testing against 0 is so bad. A heuristic, You give another heuristic. Probably there will be a point in time where we need both. (About type 0: DOS has used type 0 as definition of unused. It is not bad if Linux uses DOS-conventions for a DOS-type partition table.) Andries - 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] orinoco rfmon
Alexey Dobriyan wrote: On Saturday 26 February 2005 20:10, Eric Gaumer wrote: If the code looks problematic could someone point out possible deficiencies so we can work toward a satisfactory resolution? I didn't write the code but I'm willing do what I have to in order to get this (wireless scanning) into the official tree. Uhhh... Started to comment line-by-line but then realized it would take too much time. * Read Documentaion/CodingStyle. * Indent code with tabs where it is already indented with tabs. * Brackets around a single number in #define's are useless. * Use u8, u16, u32 (not uint*_t) where the code already uses them. * Comments are supposed to be anonymous. * Use appropriate KERN_* constant in printk()'s. * Don't pack simple types (uint32_t, ...) * Common convention is to return 0 on success, negative number on error. Positive return values don't fit well into this scheme. If possible follow it. Oh, and the type p80211item_uint32_t when in fact it is a 12-bytes long structure ... Alexey What is the difference between u* and uint*_t ? Both are derived from the same basic data type. typedef unsigned char __u8; typedef __u8uint8_t; And... typedef unsigned char u8; -- "Education is what remains after one has forgotten everything he learned in school." - Albert Einstein signature.asc Description: OpenPGP digital signature
Re: [PATCH] partitions/msdos.c
On Sat, 26 Feb 2005, Linus Torvalds wrote:
>
> Would it not make more sense to just sanity-check the size itself, and
> throw it out if the partition size (plus start) is bigger than the disk
> size?
Something like this (TOTALLY UNTESTED AS USUAL!)?
What does fdisk and other tools do on that disk? Just out of interest..
Linus
---
= fs/partitions/msdos.c 1.26 vs edited =
--- 1.26/fs/partitions/msdos.c 2004-11-09 12:43:17 -08:00
+++ edited/fs/partitions/msdos.c2005-02-26 14:33:33 -08:00
@@ -381,6 +381,7 @@
int msdos_partition(struct parsed_partitions *state, struct block_device *bdev)
{
int sector_size = bdev_hardsect_size(bdev) / 512;
+ sector_t nr_sectors;
Sector sect;
unsigned char *data;
struct partition *p;
@@ -426,11 +427,12 @@
* On the second pass look inside *BSD, Unixware and Solaris partitions.
*/
+ nr_sectors = get_capacity(bdev->bd_disk);
state->next = 5;
for (slot = 1 ; slot <= 4 ; slot++, p++) {
u32 start = START_SECT(p)*sector_size;
u32 size = NR_SECTS(p)*sector_size;
- if (!size)
+ if (!size || size > nr_sectors)
continue;
if (is_extended_partition(p)) {
/* prevent someone doing mkfs or mkswap on an
-
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] partitions/msdos.c
On Sat, 26 Feb 2005, Uwe Bonnes wrote: > > Andrew, > > Andries> I think nobody uses such partitions seriously, but nevertheless > Andries> this should probably live in -mm for a while to see if anybody > Andries> complains. > > the partition table of the USB stick in question is valid: > > 1B0: 00 00 00 00 00 00 00 00 53 3F 3C B9 00 00 00 01 S?<. > 1C0: 01 00 06 10 21 7D 25 00 00 00 DB F3 01 00 00 00 !}%. > 1D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >* > 1F0: 00 00 00 00 00 00 00 54 72 75 6D 70 4D 53 55 AA ...TrumpMSU. > > Entry 1 is a FAT partition of exactly the size of the stick, and entries 2 > to 4 are empty, marked by id zero. However the manufacturer decided to put a > name string "Trump" ( /sbin/lsusb gives > Bus 004 Device 012: ID 090a:1bc0 Trumpion Microelectronics, Inc.) just before > the "55 AA" partition table magic and our code reads this string as a > (bogus) size for the fourth entry, taking it for real. Would it not make more sense to just sanity-check the size itself, and throw it out if the partition size (plus start) is bigger than the disk size? We already do that within extended partitions, ie we do if (offs + size > this_size) continue; to just ignore crap. For some reason we don't do this for the primary one (possibly because we don't trust disk size reporting, I guess). There might well be people use use partition type 0, just because they just never _set_ the partition type.. I don't think Linux has ever cared about any type except for the "extended partition" type, so checking for zero doesn't seem very safe.. 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: [PATCH] New operation for kref to help avoid locks
Sergey Vlasov wrote:
On Sat, 26 Feb 2005 09:55:41 -0600 Corey Minyard wrote:
Greg,
This is the patch for krefs that we talked about. If you don't like it
but like the docs, feel free just to take the documentation and cut out
the stuff at the end about the new operation.
See below for comments to the patch.
Sergey, right on all counts. Here's a patch with the fixes you suggest.
Thanks,
-Corey
Add a routine to kref that allows the kref_put() routine to be
unserialized even when the get routine attempts to kref_get()
an object without first holding a valid reference to it. This is
useful in situations where this happens multiple times without
freeing the object, as it will avoid having to do a lock/semaphore
except on the final kref_put().
This also adds some kref documentation to the Documentation
directory.
Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc4/include/linux/kref.h
===
--- linux-2.6.11-rc4.orig/include/linux/kref.h
+++ linux-2.6.11-rc4/include/linux/kref.h
@@ -28,5 +28,11 @@
void kref_get(struct kref *kref);
void kref_put(struct kref *kref, void (*release) (struct kref *kref));
+/* Get a kref if the count is not already zero. This can be used to
+ avoid a lock in the routine that calls kref_put(). Returns 1 if
+ successful or zero if the count was already zero. See
+ Documentation/kref.txt for details on how to use this. */
+int kref_get_with_check(struct kref *kref);
+
#endif /* __KERNEL__ */
#endif /* _KREF_H_ */
Index: linux-2.6.11-rc4/lib/kref.c
===
--- linux-2.6.11-rc4.orig/lib/kref.c
+++ linux-2.6.11-rc4/lib/kref.c
@@ -52,6 +52,20 @@
release(kref);
}
+/**
+ * kref_get_with_check - increment refcount if the refcount is not already 0.
+ * @kref: object.
+ */
+int kref_get_with_check(struct kref *kref)
+{
+ if (atomic_inc_return(&kref->refcount) == 1) {
+ atomic_dec(&kref->refcount);
+ return 0;
+ }
+ return 1;
+}
+
EXPORT_SYMBOL(kref_init);
EXPORT_SYMBOL(kref_get);
EXPORT_SYMBOL(kref_put);
+EXPORT_SYMBOL(kref_get_with_check);
Index: linux-2.6.11-rc4/Documentation/kref.txt
===
--- /dev/null
+++ linux-2.6.11-rc4/Documentation/kref.txt
@@ -0,0 +1,283 @@
+krefs allow you to add reference counters to your objects. If you
+have objects that are used in multiple places and passed around, and
+you don't have refcounts, your code is almost certainly broken. If
+you want refcounts, krefs are the way to go.
+
+To use a kref, add a one to your data structures like:
+
+struct my_data
+{
+ .
+ .
+ struct kref refcount;
+ .
+ .
+};
+
+The kref can occur anywhere within the data structure.
+
+You must initialize the kref after you allocate it. To do this, call
+kref init as so:
+
+ struct my_data *data;
+
+ data = kmalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+return -ENOMEM;
+ kref_init(&data->refcount);
+
+This sets the refcount in the kref to 1.
+
+Once you have a refcount, you must follow the following rules:
+
+1) If you make a non-temporary copy of a pointer, especially if
+ it can be passed to another thread of execution, you must
+ increment the refcount with kref_get() before passing it off:
+ kref_get(&data->refcount);
+ If you already have a valid pointer to a kref-ed structure (the
+ refcount cannot go to zero) you may do this without a lock.
+
+2) When you are done with a pointer, you must call kref_put():
+ kref_put(&data->refcount, data_release);
+ If this is the last reference to the pointer, the release
+ routine will be called. If the code never tries to get
+ a valid pointer to a kref-ed structure without already
+ holding a valid pointer, it is safe to do this without
+ a lock.
+
+3) If the code attempts to gain a reference to a kref-ed structure
+ without already holding a valid pointer, it must serialize access
+ where a kref_put() cannot occur during the kref_get(), and the
+ structure must remain valid during the kref_get().
+
+For example, if you allocate some data and then pass it to another
+thread to process:
+
+void data_release(struct kref *ref)
+{
+ struct my_data *data = container_of(ref, struct my_data, refcount);
+ kfree(data);
+}
+
+void more_data_handling(void *cb_data)
+{
+ struct my_data *data = cb_data;
+ .
+ . do stuff with data here
+ .
+ kref_put(data, data_release);
+}
+
+int my_data_handler(void)
+{
+ int rv = 0;
+ struct my_data *data;
+ struct task_struct *task;
+ data = kmalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+ kref_init(&data->refcount);
+
+ kref_get(&data->refcount);
+ task = kthread_run(more_data_handling, data, "more_
Re: [PATCH] partitions/msdos.c
> "Andries" == Andries Brouwer <[EMAIL PROTECTED]> writes: Andrew, Andries> I think nobody uses such partitions seriously, but nevertheless Andries> this should probably live in -mm for a while to see if anybody Andries> complains. the partition table of the USB stick in question is valid: 1B0: 00 00 00 00 00 00 00 00 53 3F 3C B9 00 00 00 01 S?<. 1C0: 01 00 06 10 21 7D 25 00 00 00 DB F3 01 00 00 00 !}%. 1D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 1F0: 00 00 00 00 00 00 00 54 72 75 6D 70 4D 53 55 AA ...TrumpMSU. Entry 1 is a FAT partition of exactly the size of the stick, and entries 2 to 4 are empty, marked by id zero. However the manufacturer decided to put a name string "Trump" ( /sbin/lsusb gives Bus 004 Device 012: ID 090a:1bc0 Trumpion Microelectronics, Inc.) just before the "55 AA" partition table magic and our code reads this string as a (bogus) size for the fourth entry, taking it for real. Please consider the patch for the main kernel distribution. Cheers -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- - 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/
cyrix_arr_init and centaur_mcr_init unused?
arch/i386/kernel/cpu/mtrr/cyrix.c has a routine cyrix_arr_init(), and arch/i386/kernel/cpu/mtrr/centaur.c has a routine centaur_mcr_init(). At first sight it looks like these are unused. Do I overlook something? (They occur as the .init fields of some struct, and I did not find any calls of ->init().) If there are no calls and the code is needed, then some systems may be broken today. If the code is not needed, maybe it should be removed. Andries - 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/
userspace app needing signal on parport input change
Hello, Is there a way for a user space app to get a signal or maybe woken up from select/read when there is a change on a particular input pin on the parallel port? Thanks. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around 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/
[PATCH] partitions/msdos.c
A well-known kernel bug is that it guesses at the partition type
and the partitions on any disk it encounters. This is bad because
needless I/O is done, slowing down the boot, sometimes quite a lot,
especially when I/O errors occur. And it is bad because sometimes
we guess wrong.
In other words, we need the user space command `partition',
where "partition -t dos /dev/sda" reads a DOS-type partition
table. (And "partition /dev/sda" tries all known heuristics
to decide what type of partitioning might be present.)
The two variants are: (i) partition tells the kernel
to do the partition table reading, and (ii) partition uses partx
to read the partition table and tells the kernel one-by-one
about the partitions found this way.
Since this is a fundamental change, a long transition period
is needed, and that period could start with a kernel boot parameter
telling the kernel not to do partition table parsing on a particular
disk, or a particular type of disks, or all disks.
This could have been the intro to a patch doing that, but is not.
(It is just an RFC.)
The tiny patch below prompted the above - it was suggested by Uwe Bonnes
who encountered USB devices without partition table where our present
heuristics did not suffice to stop partition table parsing.
It causes the kernel to ignore partitions of type 0. A band-aid.
I think nobody uses such partitions seriously, but nevertheless this
should probably live in -mm for a while to see if anybody complains.
Andries
diff -uprN -X /linux/dontdiff a/fs/partitions/msdos.c b/fs/partitions/msdos.c
--- a/fs/partitions/msdos.c 2004-12-29 03:39:55.0 +0100
+++ b/fs/partitions/msdos.c 2005-02-26 22:21:06.0 +0100
@@ -430,6 +430,8 @@ int msdos_partition(struct parsed_partit
for (slot = 1 ; slot <= 4 ; slot++, p++) {
u32 start = START_SECT(p)*sector_size;
u32 size = NR_SECTS(p)*sector_size;
+ if (SYS_IND(p) == 0)
+ continue;
if (!size)
continue;
if (is_extended_partition(p)) {
-
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: arch/xen is a bad idea
> > I think there's an interim compromise position that > everyone might go > > for: > > > > Phase 1 is for us to submit a load of patches that squeeze > out the low > > hanging fruit in unifying xen/i386 and i386. Most of these will be > > strict cleanups to i386, and the result will be to almost halve the > > number of files that we need to modify. > > OK. It would be good to have a phase 0: any refactoring, > abstracting, etc > to the core kernel and to i386 which is a preparatory step, prior to > introducing any Xen code. After phase 0 everything should > still compile > and run. The subsequent Xen patches should merely add stuff > and not move > existing code around. I think my phase 1 and your phase 0 are actually the same. I'm not proposing that we put any Xen code in the tree at this point, but that we do the many easy cleanups to i386 which will mean that we can remove modifications to files from the arch/xen tree we maintain . Example cleanups would be: use a macro for testing to see whether you're in the kernel or not; use isa_bus_to_virt instead of phys_to_virt for the access the address of the VGA console etc etc. > What would you propose doing with the i386 header files? Such as the > pagetable handling? We'd certainly still need to have xen-specific versions of some of the i386 header files. Perhaps the neatest thing is to have an include/asm-i386/xen ahead of include/asm-i386 on the include search path? Not sure. Ian - 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] New operation for kref to help avoid locks
On Sat, 26 Feb 2005 09:55:41 -0600 Corey Minyard wrote:
> Greg,
>
> This is the patch for krefs that we talked about. If you don't like it
> but like the docs, feel free just to take the documentation and cut out
> the stuff at the end about the new operation.
See below for comments to the patch.
>
> Thanks,
>
> -Corey
>
>
> [kref_checked.diff text/plain (10576 bytes)]
> Add a routine to kref that allows the kref_put() routine to be
> unserialized even when the get routine attempts to kref_get()
> an object without first holding a valid reference to it. This is
> useful in situations where this happens multiple times without
> freeing the object, as it will avoid having to do a lock/semaphore
> except on the final kref_put().
>
> This also adds some kref documentation to the Documentation
> directory.
>
> Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
>
> Index: linux-2.6.11-rc4/include/linux/kref.h
> ===
> --- linux-2.6.11-rc4.orig/include/linux/kref.h
> +++ linux-2.6.11-rc4/include/linux/kref.h
> @@ -28,5 +28,11 @@
> void kref_get(struct kref *kref);
> void kref_put(struct kref *kref, void (*release) (struct kref *kref));
>
> +/* Get a kref if the count is not already zero. This can be used to
> + avoid a lock in the routine that calls kref_put(). Returns 1 if
> + successful or zero if the count was already zero. See
> + Documentation/kref.txt for details on how to use this. */
> +int kref_get_with_check(struct kref *kref);
> +
> #endif /* __KERNEL__ */
> #endif /* _KREF_H_ */
> Index: linux-2.6.11-rc4/lib/kref.c
> ===
> --- linux-2.6.11-rc4.orig/lib/kref.c
> +++ linux-2.6.11-rc4/lib/kref.c
> @@ -52,6 +52,21 @@
> release(kref);
> }
>
> +/**
> + * kref_get_with_check - increment refcount if the refcount is not already 0.
> + * @kref: object.
> + */
> +int kref_get_with_check(struct kref *kref)
> +{
> + atomic_inc(&kref->refcount);
> + if (atomic_read(&kref->refcount) == 1) {
> + atomic_dec(&kref->refcount);
> + return 0;
> + }
> + return 1;
> +}
Consider this situation:
initially refcount is 1
CPU1 does kref_get_with_check() CPU2 does kref_put()
atomic_inc(&kref->refcount)
(increments refcount to 2)
atomic_dec_and_test(&kref->refcount)
(decrements refcount to 1)
(kref_put() does nothing more
because the refcount did not
reach zero)
atomic_read(&kref->refcount)
(finds refcount == 1 and decides
that the entry was being deleted)
atomic_dec(&kref->refcount);
(decrements refcount to 0)
(then proceeds thinking that the
entry was about to be finalized,
thus creating a leak)
Because of this, separate atomic_inc+atomic_read sequence is unsafe -
you need atomic_inc_return() here instead:
int kref_get_with_check(struct kref *kref)
{
if (atomic_inc_return(&kref->refcount) == 1) {
atomic_dec(&kref->refcount);
return 0;
}
return 1;
}
> +
> EXPORT_SYMBOL(kref_init);
> EXPORT_SYMBOL(kref_get);
> EXPORT_SYMBOL(kref_put);
> +EXPORT_SYMBOL(kref_get_with_check);
> Index: linux-2.6.11-rc4/Documentation/kref.txt
> ===
> --- /dev/null
> +++ linux-2.6.11-rc4/Documentation/kref.txt
> @@ -0,0 +1,274 @@
> +krefs allow you to add reference counters to your objects. If you
> +have objects that are used in multiple places and passed around, and
> +you don't have refcounts, your code is almost certainly broken. If
> +you want refcounts, krefs are the way to go.
> +
> +To use a kref, add a one to your data structures like:
> +
> +struct my_data
> +{
> + .
> + .
> + struct kref refcount;
> + .
> + .
> +};
> +
> +The kref can occur anywhere within the data structure.
> +
> +You must initialize the kref after you allocate it. To do this, call
> +kref init as so:
> +
> + struct my_data *data;
> +
> + data = kmalloc(sizeof(*data), GFP_KERNEL);
> + if (!data)
> +return -ENOMEM;
> + kref_init(&data->refcount);
> +
> +This sets the refcount in the kref to 1.
> +
> +Once you have a refcount, you must follow the following rules:
> +
> +1) If you make a non-temporary copy of a pointer, especially if
> + it can be passed to another thread of execution, you must
> + increment the refcount with kref_get() before passing it off:
> + kref_get(&data->refcount);
> + If you already have a valid pointer to a kref-ed structure (the
> + refcount cannot go to zero) you may do this without a lock.
> +
> +2) When you are done with a pointer, you must call kref_put():
> + kref_put(&data-
Re: [PATCH] Re: 2.6.11-rc4 libata-core (irq 30: nobody cared!)
Rogério Brito wrote: On Feb 23 2005, Jeff Garzik wrote: Does this patch do anything useful? Jeff (...) The patch you posted seems to only affect people using SATA, right? BTW, just for clarity I'm seeing the message in a PATA environment (on i386) and Brian is seeing his problem with a SATA device on ppc. "irq XX: nobody cared" is a screaming interrupt situation, which could have 1001 causes. Normally it's something that "pci=biosirq" or "acpi=off" will fix, but on occasion the driver itself is what needs fixing. Jeff - 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] Removes unused label from /drivers/isdn/hisax/hisax_fcpcipnp.c
This Patch removes (in kernel 2.6.10) an unused label (fixes compiler WARNING) and a function (inside a preprocessor directive) that is never called. Signed-off- by: Telemaque Ndizihiwe <[EMAIL PROTECTED]> --- linux-2.6.10/drivers/isdn/hisax/hisax_fcpcipnp.c.orig 2005-02-26 19:16:06.030150400 + +++ linux-2.6.10/drivers/isdn/hisax/hisax_fcpcipnp.c2005-02-26 19:18:01.023668728 + @@ -1010,12 +1010,6 @@ static int __init hisax_fcpcipnp_init(vo #endif return 0; -#if !defined(CONFIG_HOTPLUG) || defined(MODULE) - out_unregister_isapnp: -#ifdef __ISAPNP__ - pnp_unregister_driver(&fcpnp_driver); -#endif -#endif out_unregister_pci: pci_unregister_driver(&fcpci_driver); out: - 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] orinoco rfmon
On Saturday 26 February 2005 20:10, Eric Gaumer wrote: > If the code looks problematic could someone point out possible > deficiencies so we can work toward a satisfactory resolution? I didn't > write the code but I'm willing do what I have to in order to get this > (wireless scanning) into the official tree. Uhhh... Started to comment line-by-line but then realized it would take too much time. * Read Documentaion/CodingStyle. * Indent code with tabs where it is already indented with tabs. * Brackets around a single number in #define's are useless. * Use u8, u16, u32 (not uint*_t) where the code already uses them. * Comments are supposed to be anonymous. * Use appropriate KERN_* constant in printk()'s. * Don't pack simple types (uint32_t, ...) * Common convention is to return 0 on success, negative number on error. Positive return values don't fit well into this scheme. If possible follow it. Oh, and the type p80211item_uint32_t when in fact it is a 12-bytes long structure ... Alexey - 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] Re: 2.6.11-rc4 libata-core (irq 30: nobody cared!)
On Feb 23 2005, Jeff Garzik wrote: > Does this patch do anything useful? > Jeff (...) The patch you posted seems to only affect people using SATA, right? BTW, just for clarity I'm seeing the message in a PATA environment (on i386) and Brian is seeing his problem with a SATA device on ppc. Thanks, Rogério Brito. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - 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] fix units/partition count in sd.c (2.4.x)
Thanks for your attention.
I think It only matters when there're many scsi controllers but less disks like
one disk per controller.
Even in such case
The main user of nr_real does
genhd.c:part_show()
/* show the full disk and all non-0 size partitions of it */
for (n = 0; n < (gp->nr_real << gp->minor_shift); n++) {
if (gp->part[n].nr_sects) {
It's very tight loop when there's no real device.
If "(gp->nr_real << gp->minor_shift)" part is taken out from the loop
it'll be much more efficient.
And much simpler proof of "It's safe" is that
we are already living with monsters.
./drivers/md/md.c: nr_real: MAX_MD_DEVS, == 256
./drivers/md/lvm.c: .nr_real= MAX_LV, == 256
So using md or lvm simply adds overhead of 16 scsi controllers.
So we are safe or we are not safe already.
Soohoon Lee.
-- Original Message --
From: Marcelo Tosatti <[EMAIL PROTECTED]>
Date: Sat, 26 Feb 2005 10:48:52 -0300
>On Wed, Feb 16, 2005 at 11:23:53AM -0500, Luben Tuikov wrote:
>> Hi,
>>
>> This patch fixes the nr_real count in sd.c, which is also used
>> in genhd.c to print out the partitions/units. The problem is that
>> nr_real is decremented on detach, the genhd's nr_sects is
>> cleared but the entry is still there and is being counted
>> for when displaying the partitions. Thus when nr_real
>> is decremented _and_ a 0-ed partition/unit is counted,
>> we get to not display 1 or more entries of the tail of
>> the list.
>>
>> The solution is to not decrement nr_real on detach, effectively
>> never decrementing it, and so that it doesn't grow without a bound,
>> to throttle it on attach, incrementing it only if it would be
>> smaller than nr_dev.
>>
>> This was observed on a RH kernel and on the current BK kernel.
>> Tested and fixed on 2.4.30-pre1 (BK). This patch is against 2.4.30-pre1.
>>
>> To reproduce: assume 4 scsi disks sda, sdb, sdc, sdd.
>> #echo "scsi remove-single-device " > /proc/scsi/scsi
>> #cat /proc/partitions
>> <>
>
>Luben,
>
>On James Bottomley advice I have applied Soo Lee's fix, which looks cleaner.
>
>Also as James notice this will increase overhead of /proc/partitions which
>might be
>a problem on higher-end systems with many devices.
>
>Testing of it on such systems is highly appreciated.
>
>
># 05/02/26 [EMAIL PROTECTED] 1.1558
># [PATCH] Fix units/partition count in sd.c
>#
># Symptom:
>#When a scsi disk is removed other scsi disk with biggest minor #
>#disapears in /proc/partition at the same time.
>#
># Cause and fix:
>#sd.c decreases nr_real on disk removal but because nr_real is not
>#real # of devices but max # of devices of a major #,
>#it doesn't need to be changed on disk add/remove.
>#
># 2.6 has little different structure but it does like this
>#
># sd.c:sd_probe()
># gd->minors = 16;
>#
>#
>diff -Nru a/drivers/scsi/sd.c b/drivers/scsi/sd.c
>--- a/drivers/scsi/sd.c Sat Feb 26 10:46:42 2005
>+++ b/drivers/scsi/sd.c Sat Feb 26 10:46:42 2005
>@@ -1220,7 +1220,7 @@
>goto cleanup_gendisks_part;
>memset(sd_gendisks[i].part, 0, (SCSI_DISKS_PER_MAJOR << 4) *
> sizeof(struct hd_struct));
>sd_gendisks[i].sizes = sd_sizes + (i * SCSI_DISKS_PER_MAJOR <<
> 4);
>- sd_gendisks[i].nr_real = 0;
>+ sd_gendisks[i].nr_real = SCSI_DISKS_PER_MAJOR;
>sd_gendisks[i].real_devices =
>(void *) (rscsi_disks + i * SCSI_DISKS_PER_MAJOR);
>}
>@@ -1333,7 +1333,6 @@
>rscsi_disks[i].device = SDp;
>rscsi_disks[i].has_part_table = 0;
>sd_template.nr_dev++;
>- SD_GENDISK(i).nr_real++;
> devnum = i % SCSI_DISKS_PER_MAJOR;
> SD_GENDISK(i).de_arr[devnum] = SDp->de;
> if (SDp->removable)
>@@ -1447,7 +1446,6 @@
>SDp->attached--;
>sd_template.dev_noticed--;
>sd_template.nr_dev--;
>- SD_GENDISK(i).nr_real--;
>return;
>}
>return;
>
>
>
>
-
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 IDE Connector
Well, basically I would like to test the file system. And since I travel I lot, I carry laptop and this external disk with me. So, was just wondering if I could somehow conduct a disk-level test. Thanks. On Fri, 25 Feb 2005 14:36:49 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > On Fri, Feb 25, 2005 at 10:30:27AM +0530, Sumit Narayan wrote: > > Hi, > > > > I have an external IDE connector through USB port. Where could I get > > the exact point inside the kernel, from where I would get information > > such as Block No., Request size, partition details for a particular > > request, _just_ before being sent to the disk. > > > > Like, for a normal IDE, I could gather these details from inside the > > function __ide_do_rw_disk from "struct request". Is there anyway for > > finding out the same for a USB mass storage device? > > Why would you want to know this information for a controller device that > acts like a scsi one, not an IDE one (that's what usb storage devices > do...) > > thanks, > > greg k-h > - 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: EBDA Question
"H. Peter Anvin" wrote: > Followup to: <[EMAIL PROTECTED]> > By author:"Moore, Eric Dean" <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > EBDA - Extended Bios Data Area > > > > Does Linux and various boot loaders(lilo/grub/etc) > > having any restrictions on where and how big > > memory allocated in EBDA is? Is this > > handled for 2.4/2.6 Kernels? > > > > Reason I ask is we are considering having > > BIOS(for a SCSI HBA Controller) allocating > > memory in EBDA for Firmware use. > > We are concerned whether Linux would be writing > > over this region of memory during the handoff > > of BIOS to scsi lower layer driver loading. > > > > In general, dropping the EBDA below 0x9a000 is probably a > bad idea. Recent Linux kernels and boot loaders should handle it, > though. Keep in mind that you might find yourself in serious trouble > if you then have, for example, a PXE stack layered on top of your SCSI > BIOS. There are test software used in manufacturing line that needs this DOS memory. > > > -hpa > > - > 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: System call problem
Steven Rostedt wrote: On Sat, 2005-02-26 at 15:17 +0100, Josef E. Galea wrote: I compiled and booted the kernel and am trying to build a user space application that uses my system call, however gcc is returning this error: /tmp/cc4zgzUr.o(.text+0x4e): In functiono `get_rmt_paging': : undefined reference to `errno' Where you defined your system call in the user space program (ie. where you declared your _syscall macro), did you also include ? -- Steve I included and it didn't solve the problem. Now i included and it did. Thanks for you help! Josef - 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 4/6] Bind Mount Extensions 0.06
On Tue, Feb 22, 2005 at 09:45:37AM -0500, Trond Myklebust wrote:
> ty den 22.02.2005 Klokka 13:12 (+0100) skreiv Herbert Poetzl:
>
> > * Special case: O_CREAT|O_EXCL implies O_NOFOLLOW for security
> > * reasons.
> > @@ -1518,23 +1536,28 @@ do_link:
> > struct dentry *lookup_create(struct nameidata *nd, int is_dir)
> > {
> > struct dentry *dentry;
> > + int error;
> >
> > down(&nd->dentry->d_inode->i_sem);
> > - dentry = ERR_PTR(-EEXIST);
> > + error = -EEXIST;
> > if (nd->last_type != LAST_NORM)
> > - goto fail;
> > + goto out;
> > nd->flags &= ~LOOKUP_PARENT;
> > dentry = lookup_hash(&nd->last, nd->dentry);
> > if (IS_ERR(dentry))
> > + goto ret;
> > + error = mnt_may_create(nd->mnt, nd->dentry->d_inode, dentry);
> > + if (error)
> > goto fail;
> > + error = -ENOENT;
> > if (!is_dir && nd->last.name[nd->last.len] && !dentry->d_inode)
> > - goto enoent;
> > + goto fail;
> > +ret:
> > return dentry;
> > -enoent:
> > - dput(dentry);
> > - dentry = ERR_PTR(-ENOENT);
> > fail:
> > - return dentry;
> > + dput(dentry);
> > +out:
> > + return ERR_PTR(error);
> > }
>
> What is the value of adding "error"? The current code is more efficient,
> and just as readable.
okay, had a deeper look at this and now I remember
why I added 'error' in the first place (quite some
time ago ;)
basically we need to check for RO in lookup_create()
now to give the same (error) results than a 'normal'
ro mounted filesystem, it is required to do the
dentry lookup and check the dentry->d_inode to return
EEXIST before returning EROFS ...
something like this would be the result:
if (dentry->d_inode) {
dput(dentry);
dentry = ERR_PTR(-EEXIST);
goto fail;
}
if (MNT_IS_RDONLY(nd->mnt)) {
dput(dentry);
dentry = ERR_PTR(-EROFS);
goto fail;
}
I'm currently looking into moving that check upwards
so that it will happen _after_ the EEXIST one ...
best,
Herbert
> Cheers,
> Trond
>
> --
> Trond Myklebust <[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: [PATCH] config option for default loglevel
Matthias Kunze wrote: Hi, I've created a little patch to make the default loglevel a configurable option. Is there a chance that this patch will be included in a future release? diff -Naur linux-2.6.10/drivers/video/console/Kconfig linux-2.6.10-new/drivers/video/console/Kconfig --- linux-2.6.10/drivers/video/console/Kconfig 2004-12-24 22:34:26.0 +0100 +++ linux-2.6.10-new/drivers/video/console/Kconfig 2005-02-26 17:11:03.0 +0100 @@ -186,5 +186,25 @@ big letters (like the letters used in the SPARC PROM). If the standard font is unreadable for you, say Y, otherwise say N. +config DEFAULT_CONSOLE_LOGLEVEL +int "Default Console Loglevel" +range 1 8 +default 7 +help + All Kernel Messages with a loglevel smaller than the console loglevel + will be printed to the console. This value can later be changed with + klogd or other programs. The loglevels are defined as follows: + + 0 (KERN_EMERG)system is unusable + 1 (KERN_ALERT)action must be taken immediately + 2 (KERN_CRIT) critical conditions + 3 (KERN_ERR) error conditions + 4 (KERN_WARNING) warning conditions + 5 (KERN_NOTICE) normal but significant condition + 6 (KERN_INFO) informational + 7 (KERN_DEBUG)debug-level messages + + The console loglevel can be set to a value in the range from 1 to 8. + endmenu diff -Naur linux-2.6.10/kernel/printk.c linux-2.6.10-new/kernel/printk.c --- linux-2.6.10/kernel/printk.c2005-02-26 16:49:03.0 +0100 +++ linux-2.6.10-new/kernel/printk.c2005-02-26 17:32:09.0 +0100 @@ -41,7 +41,7 @@ /* We show everything that is MORE important than this.. */ #define MINIMUM_CONSOLE_LOGLEVEL 1 /* Minimum loglevel we let people use */ -#define DEFAULT_CONSOLE_LOGLEVEL 7 /* anything MORE serious than KERN_DEBUG */ +#define DEFAULT_CONSOLE_LOGLEVEL CONFIG_DEFAULT_CONSOLE_LOGLEVEL DECLARE_WAIT_QUEUE_HEAD(log_wait); --- Matthias Kunze http://elpp.foofighter.de - 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/ Hi! I think this patch is useful and should be included in further Kernel releases. Matthias-Christian Ott - 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] orinoco rfmon
Could anyone elaborate on the status of this patch? I've had 344 days of uptime
on a PPC
powerbook using it on 2.4.22 and about 3 months of solid use on 2.6.
If the code looks problematic could someone point out possible deficiencies so
we can work
toward a satisfactory resolution? I didn't write the code but I'm willing do
what I have to
in order to get this (wireless scanning) into the official tree.
diff -ur linux-2.6.9/drivers/net/wireless/hermes.c
linux-2.6.9-orinoco/drivers/net/wireless/hermes.c
--- linux-2.6.9/drivers/net/wireless/hermes.c 2004-10-20 15:26:41.0
-0400
+++ linux-2.6.9-orinoco/drivers/net/wireless/hermes.c 2004-10-20
14:55:01.0 -0400
@@ -182,6 +182,10 @@
if (err)
return err;
+for ( k = 0; k < HERMES_NUMPORTS_MAX; k++) {
+ hw->port_enabled[k] = 0;
+ }
+
reg = hermes_read_regn(hw, EVSTAT);
k = CMD_INIT_TIMEOUT;
while ( (! (reg & HERMES_EV_CMD)) && k) {
diff -ur linux-2.6.9/drivers/net/wireless/hermes.h
linux-2.6.9-orinoco/drivers/net/wireless/hermes.h
--- linux-2.6.9/drivers/net/wireless/hermes.h 2004-10-20 15:26:41.0
-0400
+++ linux-2.6.9-orinoco/drivers/net/wireless/hermes.h 2004-10-20
15:24:55.0 -0400
@@ -34,6 +34,10 @@
#include
#include
+#defineHFA384x_PORTTYPE_IBSS ((uint16_t)3)
+#defineHFA384x_WEPFLAGS_DISABLE_TXCRYPT(0x10)
+#defineHFA384x_WEPFLAGS_DISABLE_RXCRYPT(0x80)
+
/*
* Limits and constants
*/
@@ -150,6 +154,11 @@
/*--- Debugging Commands -*/
#defineHERMES_CMD_TEST (0x0038)
+/*--- Debugging Commands -*/
+/* We want these in this byte arrangement. Why is it even being changed? */
+#defineHERMES_CMD_MONITOR (0x0038)
+#defineHERMES_MONITOR_ENABLE (0x000b)
+#defineHERMES_MONITOR_DISABLE (0x000f)
/* Test command arguments */
#defineHERMES_TEST_SET_CHANNEL 0x0800
@@ -173,6 +182,38 @@
#defineHERMES_HOSTSCAN_SYMBOL_BCAST0x0080
/*
+ * Configuration RIDs
+ */
+
+#defineHERMES_RID_CNF_PORTTYPE (0xfc00)
+#defineHERMES_RID_CNF_CHANNEL (0xfc03)
+#defineHERMES_RID_CNF_PRISM2_WEP_ON(0xfc28)
+
+/*-- Status Fields --*/
+#defineHERMES_RXSTATUS_MSGTYPE (0xE000)
+#defineHERMES_RXSTATUS_MACPORT (0x0700)
+#defineHERMES_RXSTATUS_UNDECR (0x0002)
+#defineHERMES_RXSTATUS_FCSERR (0x0001)
+
+/*
+Communication Frames: Test/Get/Set Field Values for Receive Frames
+*/
+#defineHERMES_RXSTATUS_MSGTYPE_GET(value) (((value) &
HERMES_RXSTATUS_MSGTYPE) >> 13)
+#defineHERMES_RXSTATUS_MSGTYPE_SET(value) ((value) << 13)
+#defineHERMES_RXSTATUS_MACPORT_GET(value) (((value) &
HERMES_RXSTATUS_MACPORT) >> 8)
+#defineHERMES_RXSTATUS_MACPORT_SET(value) ((value) << 8)
+#defineHERMES_RXSTATUS_ISUNDECR(value) ((value) &
HERMES_RXSTATUS_UNDECR)
+#defineHERMES_RXSTATUS_ISFCSERR(value) ((value) &
HERMES_RXSTATUS_FCSERR)
+
+/*
+Communication Frames: Field Masks for Receive Frames
+*/
+/*-- Offsets */
+#defineHERMES_RX_DATA_LEN_OFF (44)
+#defineHERMES_RX_80211HDR_OFF (14)
+#defineHERMES_RX_DATA_OFF (60)
+
+/*
* Frame structures and constants
*/
@@ -181,6 +222,16 @@
#define HERMES_802_3_OFFSET(14+32)
#define HERMES_802_2_OFFSET(14+32+14)
+struct hermes_rx_descriptor {
+ u16 status;
+ u32 time;
+ u8 silence;
+ u8 signal;
+ u8 rate;
+ u8 rxflow;
+ u32 reserved;
+} __attribute__ ((packed));
+
#define HERMES_RXSTAT_ERR (0x0003)
#defineHERMES_RXSTAT_BADCRC(0x0001)
#defineHERMES_RXSTAT_UNDECRYPTABLE (0x0002)
@@ -353,6 +404,7 @@
#define HERMES_32BIT_REGSPACING1
u16 inten; /* Which interrupts should be enabled? */
+ uint8_t port_enabled[HERMES_NUMPORTS_MAX];
#ifdef HERMES_DEBUG_BUFFER
struct hermes_debug_entry dbuf[HERMES_DEBUG_BUFSIZE];
@@ -406,12 +458,14 @@
static inline int hermes_enable_port(hermes_t *hw, int port)
{
+hw->port_enabled[port] = 1;
return hermes_docmd_wait(hw, HERMES_CMD_ENABLE | (port << 8),
0, NULL);
}
static inline int hermes_disable_port(hermes_t *hw, int
[RFT] Preliminary w83627ehf hardware monitoring driver
Hi all,
I have been working on a w83627ehf hardware monitoring driver. The
W83627EHF is a Super-I/O chip made by Winbond. Like other chips of the
family (W83627HF, W83697HF, W83627THF...), it integrates hardware
monitoring functions. Of these, my preliminary driver only handles
temperature and fan inputs at the moment. I lack time and do not have
hardware to test it, so I will not improve it significantly in a near
future.
So that my work isn't lost, I am releasing it today in the form of a
patch against linux-2.6.11-rc5 (attached). You can also obtain it here
for now:
http://jdelvare.net1.nerim.net/sensors/linux-2.6.11-rc5-i2c-w83627ehf-beta1.diff
If it could get some testing, I would possibly get this is the main
kernel tree, so that at least what is implemented can be used, and
anyone interested in improving it would have a base to start from.
The W83627EHF doesn't seem to be found on many motherboards, but a quick
searched listed these ones:
* Asus P5AD2 Premium
* Asus P5GD1-VM
* Asus P5GD2 Premium
* Asus P5GDC-V Deluxe
* Asus P5P800
So if you have any of these motherboards (or any other with a W83627EHF
chip, for that matter), I would welcome any feedback about my driver.
Thanks,
--
Jean Delvare
diff -ruN linux-2.6.11-rc5/drivers/i2c/chips.orig/Kconfig
linux-2.6.11-rc5/drivers/i2c/chips/Kconfig
--- linux-2.6.11-rc5/drivers/i2c/chips.orig/Kconfig 2005-02-25
07:59:12.0 +0100
+++ linux-2.6.11-rc5/drivers/i2c/chips/Kconfig 2005-02-26 15:07:39.0
+0100
@@ -311,6 +311,20 @@
This driver can also be built as a module. If so, the module
will be called w83627hf.
+config SENSORS_W83627EHF
+ tristate "Winbond W83627EHF"
+ depends on I2C && EXPERIMENTAL
+ select I2C_SENSOR
+ select I2C_ISA
+ help
+ If you say yes here you get preliminary support for the hardware
+ monitoring functionality of the Winbond W83627EHF Super-I/O chip.
+ Only fan and temperature inputs are supported at the moment, while
+ the chip does much more than that.
+
+ This driver can also be built as a module. If so, the module
+ will be called w83627ehf.
+
endmenu
menu "Other I2C Chip support"
diff -ruN linux-2.6.11-rc5/drivers/i2c/chips.orig/Makefile
linux-2.6.11-rc5/drivers/i2c/chips/Makefile
--- linux-2.6.11-rc5/drivers/i2c/chips.orig/Makefile2005-02-25
07:59:12.0 +0100
+++ linux-2.6.11-rc5/drivers/i2c/chips/Makefile 2005-02-26 15:04:11.0
+0100
@@ -33,6 +33,7 @@
obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o
obj-$(CONFIG_SENSORS_SMSC47M1) += smsc47m1.o
obj-$(CONFIG_SENSORS_VIA686A) += via686a.o
+obj-$(CONFIG_SENSORS_W83627EHF)+= w83627ehf.o
obj-$(CONFIG_SENSORS_W83L785TS)+= w83l785ts.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
diff -ruN linux-2.6.11-rc5/drivers/i2c/chips.orig/w83627ehf.c
linux-2.6.11-rc5/drivers/i2c/chips/w83627ehf.c
--- linux-2.6.11-rc5/drivers/i2c/chips.orig/w83627ehf.c 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.11-rc5/drivers/i2c/chips/w83627ehf.c 2005-02-26
17:50:50.0 +0100
@@ -0,0 +1,793 @@
+/*
+w83627ehf - Driver for the hardware monitoring functionality of
+the Winbond W83627EHF Super-I/O chip
+Copyright (C) 2005 Jean Delvare <[EMAIL PROTECTED]>
+
+Shamelessly ripped from the w83627hf driver
+Copyright (C) 2003 Mark Studebaker
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+
+Supports the following chips:
+
+Chip#vin#fan#pwm#temp chip_id man_id
+w83627ehf - 5 - 3 0x880x5ca3
+
+This is a preliminary version of the driver, only supporting the
+fan and temperature inputs. The chip does much more than that.
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "lm75.h"
+
+/* Addresses to scan
+ The actual ISA address is read from Super-I/O configuration space */
+static unsigned short normal_i2c[] = { I2C_CLIENT_END };
+static unsigned int normal_isa[] = { 0, I2C_CLIENT_ISA_END };
+
+/* Insmod parameters */
+SENSORS_INSMOD_1(w83627ehf);
+
+/*
+ * Super-I/O constants and functions
+ */
+
+static int REG;/* The register to read/write */
+static int VAL;/* The value to read/write */
+
+#def
Re: [PATCH] fix units/partition count in sd.c (2.4.x)
On Wed, Feb 16, 2005 at 11:23:53AM -0500, Luben Tuikov wrote: > Hi, > > This patch fixes the nr_real count in sd.c, which is also used > in genhd.c to print out the partitions/units. The problem is that > nr_real is decremented on detach, the genhd's nr_sects is > cleared but the entry is still there and is being counted > for when displaying the partitions. Thus when nr_real > is decremented _and_ a 0-ed partition/unit is counted, > we get to not display 1 or more entries of the tail of > the list. > > The solution is to not decrement nr_real on detach, effectively > never decrementing it, and so that it doesn't grow without a bound, > to throttle it on attach, incrementing it only if it would be > smaller than nr_dev. > > This was observed on a RH kernel and on the current BK kernel. > Tested and fixed on 2.4.30-pre1 (BK). This patch is against 2.4.30-pre1. > > To reproduce: assume 4 scsi disks sda, sdb, sdc, sdd. > #echo "scsi remove-single-device " > /proc/scsi/scsi > #cat /proc/partitions > <> Luben, On James Bottomley advice I have applied Soo Lee's fix, which looks cleaner. Also as James notice this will increase overhead of /proc/partitions which might be a problem on higher-end systems with many devices. Testing of it on such systems is highly appreciated. # 05/02/26 [EMAIL PROTECTED] 1.1558 # [PATCH] Fix units/partition count in sd.c # # Symptom: #When a scsi disk is removed other scsi disk with biggest minor # #disapears in /proc/partition at the same time. # # Cause and fix: #sd.c decreases nr_real on disk removal but because nr_real is not #real # of devices but max # of devices of a major #, #it doesn't need to be changed on disk add/remove. # # 2.6 has little different structure but it does like this # # sd.c:sd_probe() # gd->minors = 16; # # diff -Nru a/drivers/scsi/sd.c b/drivers/scsi/sd.c --- a/drivers/scsi/sd.c Sat Feb 26 10:46:42 2005 +++ b/drivers/scsi/sd.c Sat Feb 26 10:46:42 2005 @@ -1220,7 +1220,7 @@ goto cleanup_gendisks_part; memset(sd_gendisks[i].part, 0, (SCSI_DISKS_PER_MAJOR << 4) * sizeof(struct hd_struct)); sd_gendisks[i].sizes = sd_sizes + (i * SCSI_DISKS_PER_MAJOR << 4); - sd_gendisks[i].nr_real = 0; + sd_gendisks[i].nr_real = SCSI_DISKS_PER_MAJOR; sd_gendisks[i].real_devices = (void *) (rscsi_disks + i * SCSI_DISKS_PER_MAJOR); } @@ -1333,7 +1333,6 @@ rscsi_disks[i].device = SDp; rscsi_disks[i].has_part_table = 0; sd_template.nr_dev++; - SD_GENDISK(i).nr_real++; devnum = i % SCSI_DISKS_PER_MAJOR; SD_GENDISK(i).de_arr[devnum] = SDp->de; if (SDp->removable) @@ -1447,7 +1446,6 @@ SDp->attached--; sd_template.dev_noticed--; sd_template.nr_dev--; - SD_GENDISK(i).nr_real--; return; } return; - 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] config option for default loglevel
Hi, I've created a little patch to make the default loglevel a configurable option. Is there a chance that this patch will be included in a future release? diff -Naur linux-2.6.10/drivers/video/console/Kconfig linux-2.6.10-new/drivers/video/console/Kconfig --- linux-2.6.10/drivers/video/console/Kconfig 2004-12-24 22:34:26.0 +0100 +++ linux-2.6.10-new/drivers/video/console/Kconfig 2005-02-26 17:11:03.0 +0100 @@ -186,5 +186,25 @@ big letters (like the letters used in the SPARC PROM). If the standard font is unreadable for you, say Y, otherwise say N. +config DEFAULT_CONSOLE_LOGLEVEL +int "Default Console Loglevel" +range 1 8 +default 7 +help + All Kernel Messages with a loglevel smaller than the console loglevel + will be printed to the console. This value can later be changed with + klogd or other programs. The loglevels are defined as follows: + + 0 (KERN_EMERG)system is unusable + 1 (KERN_ALERT)action must be taken immediately + 2 (KERN_CRIT) critical conditions + 3 (KERN_ERR) error conditions + 4 (KERN_WARNING) warning conditions + 5 (KERN_NOTICE) normal but significant condition + 6 (KERN_INFO) informational + 7 (KERN_DEBUG)debug-level messages + + The console loglevel can be set to a value in the range from 1 to 8. + endmenu diff -Naur linux-2.6.10/kernel/printk.c linux-2.6.10-new/kernel/printk.c --- linux-2.6.10/kernel/printk.c2005-02-26 16:49:03.0 +0100 +++ linux-2.6.10-new/kernel/printk.c2005-02-26 17:32:09.0 +0100 @@ -41,7 +41,7 @@ /* We show everything that is MORE important than this.. */ #define MINIMUM_CONSOLE_LOGLEVEL 1 /* Minimum loglevel we let people use */ -#define DEFAULT_CONSOLE_LOGLEVEL 7 /* anything MORE serious than KERN_DEBUG */ +#define DEFAULT_CONSOLE_LOGLEVEL CONFIG_DEFAULT_CONSOLE_LOGLEVEL DECLARE_WAIT_QUEUE_HEAD(log_wait); --- Matthias Kunze http://elpp.foofighter.de - 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] Properly share process and session keyrings with CLONE_THREAD
On Sat, 26 Feb 2005, David Howells wrote: > > There's a per-thread keyring available too; and that is strictly per thread. Ahh, I'd forgotten about that. Yeah, as long as the per-thread thing is still there, I guess I'm ok with it (what I _really_ don't want to lose is the ability to have independent threads - threaded servers using per-request keys etc, and that's my main gripe with the stupid POSIX threading model: it takes away per-thread data). Can you not do the "thread_group_lock()" thing, though? I hate hiding locks in "helper functions". You search for the lock, and now you've hidden that "siglock" usage away and made it very different from all the other siglock usage. You've also hidden the fact that it accesses "current->signal" (while not hiding it would mean that the code would likely be more cleanly done as struct sighand *grp = current->sighand; spin_lock_irq(grp->siglock); .. access group keys .. spin_unlock_irq(grp->siglock); Also, you have "current->thread_group" in there: + key_check(current->thread_group->session_keyring); + key_check(current->thread_group->process_keyring); which seems to have gotten through only because your key debug stuff is disabled.. 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: Bad page state at prep_new_page
On Sat, 26 Feb 2005, Jay Roplekar wrote:
> I have been getting this error off and on with vendor kernel 2.6.8, I have
> posted about it on lkml 3/4 times before. Actually I had offered to provide a
> summary of similar reports from the web with no takers, I can still provide
> that to somebody if it is useful.
If I had had time to spare, I'd have taken you up on the offer.
Some of those will be ones I've spent hours thinking about without
success, some just gone away, some found guilty by memtest86, some
I probably have overlooked.
> I had run memtest overnight with no errors, I use DRM etc.. The reason to
> post this is that very first line in the syslog entries related to this
> error seems to be different than before. {It is typically is kernel BUG at
> mm/rmap.c or sth similar}. Thanks,
>
> Jay
>
> P.S. I am getting this error once in 3 days on an average (based on grep of
> moths worth syslog) so I might have dubious distinction of being more
> repeatable. May be it confirms Hugh's suspicion of hardware misbehaving but
> I am not ready to accept it yet :-)
>
>
> Feb 26 09:37:03 localhost kernel: mm/memory.c:110: bad pmd 0500.
Wow. Just two days ago, in unrelated mail, I asked
"Has anyone _ever_ seen a p??_ERROR message?" and you now show us one!
Thank you - but you do seem to have quite bad memory corruption.
> Feb 26 09:39:58 localhost kernel: Bad page state at prep_new_page (in process
> 'X', page c12678e0)
> Feb 26 09:39:58 localhost kernel: flags:0x2004 mapping:f700
> mapcount:0
> count:0
Again you have a page mapping which should be NULL here anyway,
and doesn't even look like a pointer which is what goes in there
at other times.
I understand that you have a sentimental attachment to your setup.
And the corruption you're seeing could as well be from software as
hardware - but I don't think anyone else is seeing it on this scale,
which does point to your particular hardware.
But I don't want to close down this thread: if someone else can
suggest something useful to try, please go ahead.
Hugh
-
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.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)
On Sat, Feb 26, 2005 at 06:13:25PM +0100, Adrian Bunk wrote: > You call it "breakage" because you have a relatively dogmatic view > regarding the selection of user visible symbols. > Other people care more about the usability of the kernel config system, > and therefore a select of one of the I2C* options is quite common from > both outside and inside the i2c subsystem. I think you have to realise that we're different in the ARM world. We tend to rely on the default configuration files to come out with something that works, rather than hard coding the "what works" into the kernel configuration subsystem. If you want to see an example of this kind of "usability" approach, take a look at arch/arm/Kconfig LEDS options - lines of 250 or so characters of dependencies. Not what I'd call particularly maintainable. That is what your approach has in store for the other Kconfig files when it comes down to getting dependencies Correct(tm). (I do have a simplified LEDS configuration set, but it still keeps one huge LEDS dependency.) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - 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: how to use schedule_work()
hai, Thanks for information, I have already seen that material. If you find any more info regarding that plz send it to me. Thanks&Regards, KernelNewbie. On Sat, 26 Feb 2005, Vicente Feito wrote: This is for workqueues, it includes schedule_work() and how to call it http://lwn.net/Articles/23634/ Vicente - 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] allow vma merging with mlock et. al.
On Fri, 25 Feb 2005, Chris Wright wrote:
>
> Actually I think it winds up being fine since we don't do merging with
> mlock. But why not? Patch below remedies that.
I shared Darren's assumption, that mlock merging had been found too
expensive. But Andrea says it's just that nobody asked for it, so
now you've done the work, let's give it a try in -mm. We can always
back it out if somebody perceives a regression.
Do madvise and mempolicy too? I've no strong feelings about them.
> Successive mlock/munlock calls can leave fragmented vmas because they can
> be split but not merged. Give mlock et. al. full vma merging support.
Phew, you followed mprotect, saving me from having to think too deeply
about the correctness of this (I'm assuming mprotect is perfect ;))
Some remarks then on the three places where you departed from mprotect.
> = mm/mlock.c 1.19 vs edited =
> --- 1.19/mm/mlock.c 2005-02-11 11:07:35 -08:00
> +++ edited/mm/mlock.c 2005-02-24 23:53:10 -08:00
> @@ -7,18 +7,32 @@
>
> #include
> #include
> +#include
> #include
>
>
> -static int mlock_fixup(struct vm_area_struct * vma,
> +static int mlock_fixup(struct vm_area_struct *vma, struct vm_area_struct
> **prev,
> unsigned long start, unsigned long end, unsigned int newflags)
> {
> struct mm_struct * mm = vma->vm_mm;
> + pgoff_t pgoff;
> int pages;
> int ret = 0;
>
> - if (newflags == vma->vm_flags)
> + if (newflags == vma->vm_flags) {
> + *prev = vma;
> goto out;
> + }
> +
> + pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT);
> + *prev = vma_merge(mm, *prev, start, end, newflags, vma->anon_vma,
> + vma->vm_file, pgoff, vma_policy(vma));
> + if (*prev) {
> + vma = *prev;
> + goto success;
> + }
> +
> + *prev = vma;
You've raised that line higher (so do_mlockall's "Ignore errors" works):
that's an improvement because it saves special casing errors, I'd like
you to make the same adjustment to mprotect_fixup, even though it's not
required there (and delete "Unless it returns an error, " from comment).
Let's keep the two in step.
> if (start != vma->vm_start) {
> ret = split_vma(mm, vma, start, 1);
> @@ -32,6 +46,7 @@ static int mlock_fixup(struct vm_area_st
> goto out;
> }
>
> +success:
> /*
>* vm_flags is protected by the mmap_sem held in write mode.
>* It's okay if try_to_unmap_one unmaps a page just after we
> @@ -59,7 +74,7 @@ out:
> static int do_mlock(unsigned long start, size_t len, int on)
> {
> unsigned long nstart, end, tmp;
> - struct vm_area_struct * vma, * next;
> + struct vm_area_struct * vma, * prev;
> int error;
>
> len = PAGE_ALIGN(len);
> @@ -68,7 +83,7 @@ static int do_mlock(unsigned long start,
> return -EINVAL;
> if (end == start)
> return 0;
> - vma = find_vma(current->mm, start);
> + vma = find_vma_prev(current->mm, start, &prev);
> if (!vma || vma->vm_start > start)
> return -ENOMEM;
But here sys_mprotect also says:
if (start > vma->vm_start)
prev = vma;
Perhaps you've worked your way through vma_merge and convinced yourself
this is never necessary, that's quite possible; but I'd still be happier
if you were to add it into your do_mlock: it limits the cases vma_merge
has to worry about. Or if you feel strongly about it, explain why I'm
just being silly, and delete it from mprotect too.
> @@ -81,18 +96,19 @@ static int do_mlock(unsigned long start,
> if (!on)
> newflags &= ~VM_LOCKED;
>
> - if (vma->vm_end >= end) {
> - error = mlock_fixup(vma, nstart, end, newflags);
> - break;
> - }
> -
> tmp = vma->vm_end;
> - next = vma->vm_next;
> - error = mlock_fixup(vma, nstart, tmp, newflags);
> + if (tmp > end)
> + tmp = end;
> + error = mlock_fixup(vma, &prev, nstart, tmp, newflags);
> if (error)
> break;
> nstart = tmp;
> - vma = next;
> + if (nstart < prev->vm_end)
> + nstart = prev->vm_end;
> + if (nstart >= end)
> + break;
> +
> + vma = prev->vm_next;
> if (!vma || vma->vm_start != nstart) {
> error = -ENOMEM;
> break;
> @@ -141,7 +157,7 @@ asmlinkage long sys_munlock(unsigned lon
>
> static int do_mlockall(int flags)
> {
> - struct vm_area_struct * vma;
> + struct vm_area_struct * vma, * prev;
> unsigned int def_flags = 0;
>
> if (flags & MCL_FUTURE)
> @@ -150,7 +166,7 @@ static int do_mlockall(int flags)
> if (flags == MCL_FUTURE)
> goto out
Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)
On Sat, Feb 26, 2005 at 06:13:25PM +0100, Adrian Bunk wrote: > You call it "breakage" because you have a relatively dogmatic view > regarding the selection of user visible symbols. > Other people care more about the usability of the kernel config system, > and therefore a select of one of the I2C* options is quite common from > both outside and inside the i2c subsystem. > > There are two possbile situations: > - these RTC drivers are nice add-ons that could be shown if all > required I2C* options are already enabled > - these RTC drivers are pretty essential and should really be enabled > on the platforms they are for > > Which of these two cases describes the situation of these RTC drivers? Since RTCs aren't _actually_ essential for Linux kernel operation, the former clearly applies. Other people may have differing opinions, but having worked with a large number of SoC platforms where the RTC is reset when the SoC is reset, or even platforms where there is no RTC at all, it brings a different perspective to this that people who have only ever experienced systems where the RTC is always true do not have. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - 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: how to use schedule_work()
This is for workqueues, it includes schedule_work() and how to call it http://lwn.net/Articles/23634/ Vicente - 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.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)
On Sat, Feb 26, 2005 at 04:46:13PM +, Russell King wrote: >... > There are a number of ARM platforms which use a Ricoh RTC chip, and > the driver for this will live in drivers/i2c/chips/ricoh-rtc.c. This > is a stand alone driver in its own sense, handling the power management > issues (saving the time offset/restoring the time) and setting the > system time upon its initialisation. (In turn, this requires some i2c > patches which add power management to the i2c subsystem to be merged > first.) > > It's already used in some ARM platforms, including one which I was > involved in. It just hasn't been merged. > > As far as drivers/acorn/char i2c rtc stuff goes, I plan to make this > a full and proper i2c citizen, so adding breakage to the Kconfig with > random select statements for publically viewable symbols isn't the > way to go. You call it "breakage" because you have a relatively dogmatic view regarding the selection of user visible symbols. Other people care more about the usability of the kernel config system, and therefore a select of one of the I2C* options is quite common from both outside and inside the i2c subsystem. There are two possbile situations: - these RTC drivers are nice add-ons that could be shown if all required I2C* options are already enabled - these RTC drivers are pretty essential and should really be enabled on the platforms they are for Which of these two cases describes the situation of these RTC drivers? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: how to use schedule_work()
hai, Thanks for the information. Thanks&Regards, KernelNewbie. eb 2005, Parag Warudkar wrote: hai all, I want to call call_usermodehelper() from schedule_work() to run the user program in the process context. Can u please tell me how to call schedule_work(), plz give any reference manual for that. Download cscope from cscope.sourceforge.net - The site has a good tutorial on using it with linux kernel. (It's a source code searching tool - you can find for example, all functions that call a particular function and so on.) I find it very useful when you want to understand things from source code. Then find for schedule_work, look into the source where it is used and see if you can comprehend it that way. In essence - you need to setup and initialize a struct work_struct (this cannot be on a function local stack since callers stack will not be available when the work is executed) fill it with function to be called and arguments to be passed and then call schedule_work from say an interrupt. Parag - 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: how to use schedule_work()
> > hai all, > I want to call call_usermodehelper() from schedule_work() to run the > user program in the process context. Can u please tell me how to call > schedule_work(), plz give any reference manual for that. > Download cscope from cscope.sourceforge.net - The site has a good tutorial on using it with linux kernel. (It's a source code searching tool - you can find for example, all functions that call a particular function and so on.) I find it very useful when you want to understand things from source code. Then find for schedule_work, look into the source where it is used and see if you can comprehend it that way. In essence - you need to setup and initialize a struct work_struct (this cannot be on a function local stack since callers stack will not be available when the work is executed) fill it with function to be called and arguments to be passed and then call schedule_work from say an interrupt. Parag - 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/
Bad page state at prep_new_page
I have been getting this error off and on with vendor kernel 2.6.8, I have
posted about it on lkml 3/4 times before. Actually I had offered to provide a
summary of similar reports from the web with no takers, I can still provide
that to somebody if it is useful.
I had run memtest overnight with no errors, I use DRM etc.. The reason to
post this is that very first line in the syslog entries related to this
error seems to be different than before. {It is typically is kernel BUG at
mm/rmap.c or sth similar}. Thanks,
Jay
P.S. I am getting this error once in 3 days on an average (based on grep of
moths worth syslog) so I might have dubious distinction of being more
repeatable. May be it confirms Hugh's suspicion of hardware misbehaving but
I am not ready to accept it yet :-)
Feb 26 09:37:03 localhost kernel: mm/memory.c:110: bad pmd 0500.
Feb 26 09:39:58 localhost kernel: Bad page state at prep_new_page (in process
'X', page c12678e0)
Feb 26 09:39:58 localhost kernel: flags:0x2004 mapping:f700 mapcount:0
count:0
Feb 26 09:39:58 localhost kernel: Backtrace:
Feb 26 09:39:58 localhost kernel: [dump_stack+30/32] dump_stack+0x1e/0x20
Feb 26 09:39:58 localhost kernel: [] dump_stack+0x1e/0x20
Feb 26 09:39:58 localhost kernel: [bad_page+108/160] bad_page+0x6c/0xa0
Feb 26 09:39:58 localhost kernel: [] bad_page+0x6c/0xa0
Feb 26 09:39:58 localhost kernel: [prep_new_page+40/112]
prep_new_page+0x28/0x70
Feb 26 09:39:58 localhost kernel: [] prep_new_page+0x28/0x70
Feb 26 09:39:58 localhost kernel: [buffered_rmqueue+216/384]
buffered_rmqueue+0xd8/0x180
Feb 26 09:39:58 localhost kernel: [] buffered_rmqueue+0xd8/0x180
Feb 26 09:39:58 localhost kernel: [__alloc_pages+161/752]
__alloc_pages+0xa1/0x2f0
Feb 26 09:39:58 localhost kernel: [] __alloc_pages+0xa1/0x2f0
Feb 26 09:39:58 localhost kernel: [do_anonymous_page+102/368]
do_anonymous_page+0x66/0x170
Feb 26 09:39:58 localhost kernel: [] do_anonymous_page+0x66/0x170
Feb 26 09:39:58 localhost kernel: [do_no_page+95/816] do_no_page+0x5f/0x330
Feb 26 09:39:58 localhost kernel: [] do_no_page+0x5f/0x330
Feb 26 09:39:58 localhost kernel: [handle_mm_fault+341/416]
handle_mm_fault+0x155/0x1a0
Feb 26 09:39:58 localhost kernel: [] handle_mm_fault+0x155/0x1a0
Feb 26 09:39:58 localhost kernel: [do_page_fault+396/1456]
do_page_fault+0x18c/0x5b0
Feb 26 09:39:58 localhost kernel: [] do_page_fault+0x18c/0x5b0
Feb 26 09:39:58 localhost kernel: [error_code+45/56] error_code+0x2d/0x38
Feb 26 09:39:58 localhost kernel: [] error_code+0x2d/0x38
Feb 26 09:39:58 localhost kernel: Trying to fix it up, but a reboot is needed
-
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: BKCVS still updated?
On Sat, Feb 26, 2005 at 12:49:53PM +0100, Stelian Pop wrote: > On Fri, Feb 25, 2005 at 10:02:18AM -0800, Larry McVoy wrote: > > > > He should be back now, maybe he can tell us more about what happened ? > > > > We had a nameserver problem and the machine dedicated to this didn't get > > updated with a new resolve.conf. It's fixed now and updating, probably > > be there in an hour. > > I confirm it works again, thanks. > > While you're at it, could you please increase the rate of update, > as we discussed a few weeks ago ? Yes but I want to think about it a bit, I need to go relearn how it picks the changesets it exports 1:1 to CVS commits vs the csets that get collapsed into the merge nodes. I'm worried that more frequent exports may result yield suboptimal results. If that's not true then we'll export it every few hours or every time bkbits.net gets updated. -- --- Larry McVoylm at bitmover.com http://www.bitkeeper.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: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)
On Sat, Feb 26, 2005 at 05:23:41PM +0100, Adrian Bunk wrote: > On Sat, Feb 26, 2005 at 02:46:35PM +, Russell King wrote: > > On Sat, Feb 26, 2005 at 02:33:37PM +0100, Adrian Bunk wrote: > > > > Please don't deprecate this symbol. ARM has a large variety of RTC > > implementations, some of which reside in I2C modules which are yet > > to be merged. > > > > Firstly, these aren't accessible until the i2c subsystem has been > > initialised. Secondly, i2c is modular, so this function must be > > accessible from a module in order for the system time/date to be > > initialised from the RTC with a modular build. > > > > (It can be argued that you wouldn't want to build such a thing as a > > module in the first place, in which case removing the export would > > of course be fine. However, we can't sanely force I2C to be either > > always builtin, and placing this expectation on people will eventually > > lead other janitors to complain that the symbol is used by modules but > > isn't exported.) > > I saw drivers/acorn/char/i2c.c, but this file is always built statically > on ARCH_ACORN without any dependency between ARCH_ACORN and I2C. > This is buggy. > > Why can't such drivers select I2C and other required I2C_* variables? > > Appropriate depends or selects are required in any case. > If you plan to make drivers like drivers/acorn/char/i2c.c modular, my > patch is void. That driver is buggy for other reasons, but thankfully doesn't show itself very often... However, that isn't the one I was talking about, since I was talking about an unmerged driver. There are a number of ARM platforms which use a Ricoh RTC chip, and the driver for this will live in drivers/i2c/chips/ricoh-rtc.c. This is a stand alone driver in its own sense, handling the power management issues (saving the time offset/restoring the time) and setting the system time upon its initialisation. (In turn, this requires some i2c patches which add power management to the i2c subsystem to be merged first.) It's already used in some ARM platforms, including one which I was involved in. It just hasn't been merged. As far as drivers/acorn/char i2c rtc stuff goes, I plan to make this a full and proper i2c citizen, so adding breakage to the Kconfig with random select statements for publically viewable symbols isn't the way to go. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - 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.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)
On Sat, Feb 26, 2005 at 02:46:35PM +, Russell King wrote: > On Sat, Feb 26, 2005 at 02:33:37PM +0100, Adrian Bunk wrote: > > Please don't deprecate this symbol. ARM has a large variety of RTC > implementations, some of which reside in I2C modules which are yet > to be merged. > > Firstly, these aren't accessible until the i2c subsystem has been > initialised. Secondly, i2c is modular, so this function must be > accessible from a module in order for the system time/date to be > initialised from the RTC with a modular build. > > (It can be argued that you wouldn't want to build such a thing as a > module in the first place, in which case removing the export would > of course be fine. However, we can't sanely force I2C to be either > always builtin, and placing this expectation on people will eventually > lead other janitors to complain that the symbol is used by modules but > isn't exported.) I saw drivers/acorn/char/i2c.c, but this file is always built statically on ARCH_ACORN without any dependency between ARCH_ACORN and I2C. This is buggy. Why can't such drivers select I2C and other required I2C_* variables? Appropriate depends or selects are required in any case. If you plan to make drivers like drivers/acorn/char/i2c.c modular, my patch is void. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
how to use schedule_work()
hai all, I want to call call_usermodehelper() from schedule_work() to run the user program in the process context. Can u please tell me how to call schedule_work(), plz give any reference manual for that. Any help appreciated. Thanks&Regards, KernelNewbie. - 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/
NVRM: rm_init_adapter failed (2.6.11-rc4-RT-V0.7.39-02)
Hello list, /* please, CC me since I'm on dialup and not subscribed to LKML anymore :( */ It seems nvidia is broken with latest kernels; in fact, the last kernel I could use is 2.6.9-rc4-mm1-RT-U4. With 2.6.11-rc4-RT-V0.7.39-02 modprobing nvidia goes without error but X doesn't start, screen goes black and then it kicks back to the terminal. In dmesg I see: NVRM: rm_init_adapter failed I'm attaching .config, Xorg.0.log and dmesg. Is this a know bug/problem with nvidia, or is there some option I'm missing in my config? Thanks, Norberto # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc4-RT-V0.7.39-02 # Fri Feb 25 19:30:18 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_EMBEDDED=y # CONFIG_KALLSYMS is not set CONFIG_FUTEX=y # CONFIG_EPOLL is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT_DESKTOP is not set # CONFIG_PREEMPT_RT is not set CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y CONFIG_ASM_SEMAPHORES=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y # CONFIG_X86_MCE is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y # CONFIG_ACPI_SLEEP is not set # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set # CONFIG_ACPI_BUTTON is not set # CONFIG_ACPI_VIDEO is not set # CONFIG_ACPI_FAN is not set # CONFIG_ACPI_PROCESSOR is not set # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set # CONFIG_ACPI_CONTAINER is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_MSI is not set CONFIG_PCI_LEGACY_PROC=y # CONFIG_PCI_NAMES is not set # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCC
2.4.29-hf3
Hi, I've just uploaded 2.4.29 hotfix 3 here : http://linux.exosec.net/kernel/2.4-hf/2.4.29-hf3/ Just merged some small fixes to stay up to date with -bk, nothing critical. Changelog below. Cheers, Willy -- Changelog From 2.4.29-hf2 to 2.4.29-hf3 (semi-automated) --- '+' = added ; '-' = removed + net-oops-base_reachable_time-zero-1(Hideaki Yoshifuji) [NET]: Fix kernel oops if base_reachable_time is set to 0. + tunsetiff-needs-copy-back-after-ioctl-1 (David S. Miller) [COMPAT]: TUNSETIFF needs to copy back data after ioctl. It is defined as a _IOW() which is erroneous, it should have been defined as _IORW() but that cannot be changed now without breaking all existing applications using this ioctl. + sparc32-smp-clear-psr_ef-on-fork-1 (David S. Miller) [SPARC32]: Need to clear PSR_EF in psr of childregs on fork() on SMP. + netlink_remove-unhash-leaks-sockets-1(Patrick McHardy) netlink_remove() only unhashes sockets contained in the first hash bucket. This leads to leaking sockets and, over time, to bind conflicts which confuse iproute. + brlock-causes-deadlock-1 (David S. Miller) There were two versions of the big-reader lock implementation. 1) One using per-cpu reader locks, and a singular write lock. Predominantly enabled on x86 and it's brothers. 2) One using non-atomic per-cpu counter, and a single write lock. This is what all other platforms were using. #1 is unfortunately buggy. brlocks were meant to provide a high performance implementation of rwlock_t locks when it is known that the lock is taken %99 of the time by readers and that writers are thus rare. (...) + 32bit-sys_recvmsg-corruption-1 (Stephen Rothwell) In the presence of threads, there is a possibility of the kernel being fooled by the 32 bit sys_recvmsg control data into copying more than it should into the kernel and corrupting kernel data structures. (...) This patch just does some more length checking. This bug was actually being hit by BIND running at a customer site. It is very hard to hit, but (obviously) possible. + sparc64-32bit-compat-bugs-1 (David S. Miller) Fix 32bit compat layer bugs in sys_ipc() and sys_rt_sigtimedwait(). 1) sys_ipc() compat wrappers need to verify length before allocating kernel data and performing copies. 2) sys_rt_sigtimedwait() had one schedule_timeout() too many. - sparc-membar-extra-semi-colons-1 (Willy Tarreau) - sparc64-membar-extra-semi-colons-1 (Willy Tarreau) This was my quick build fix. Now David has sent the clean stuff. + sparc-smb_macros-extra-semicolons-1 (David S. Miller) [SPARC]: Fix bogus trailing semicolon in smb_*() macros. Backported from 2.6.x + sparc-nop-extra-semicolons-1 (David S. Miller) [SPARC]: nop() macro has bogus trailing semicolon Noticed by Bob Breuer. + sparc64-membar-extra-semicolons-2(David S. Miller) [SPARC64]: Fix trailing semicolon in membar macros. - 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] New operation for kref to help avoid locks
Greg,
This is the patch for krefs that we talked about. If you don't like it
but like the docs, feel free just to take the documentation and cut out
the stuff at the end about the new operation.
Thanks,
-Corey
Add a routine to kref that allows the kref_put() routine to be
unserialized even when the get routine attempts to kref_get()
an object without first holding a valid reference to it. This is
useful in situations where this happens multiple times without
freeing the object, as it will avoid having to do a lock/semaphore
except on the final kref_put().
This also adds some kref documentation to the Documentation
directory.
Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc4/include/linux/kref.h
===
--- linux-2.6.11-rc4.orig/include/linux/kref.h
+++ linux-2.6.11-rc4/include/linux/kref.h
@@ -28,5 +28,11 @@
void kref_get(struct kref *kref);
void kref_put(struct kref *kref, void (*release) (struct kref *kref));
+/* Get a kref if the count is not already zero. This can be used to
+ avoid a lock in the routine that calls kref_put(). Returns 1 if
+ successful or zero if the count was already zero. See
+ Documentation/kref.txt for details on how to use this. */
+int kref_get_with_check(struct kref *kref);
+
#endif /* __KERNEL__ */
#endif /* _KREF_H_ */
Index: linux-2.6.11-rc4/lib/kref.c
===
--- linux-2.6.11-rc4.orig/lib/kref.c
+++ linux-2.6.11-rc4/lib/kref.c
@@ -52,6 +52,21 @@
release(kref);
}
+/**
+ * kref_get_with_check - increment refcount if the refcount is not already 0.
+ * @kref: object.
+ */
+int kref_get_with_check(struct kref *kref)
+{
+ atomic_inc(&kref->refcount);
+ if (atomic_read(&kref->refcount) == 1) {
+ atomic_dec(&kref->refcount);
+ return 0;
+ }
+ return 1;
+}
+
EXPORT_SYMBOL(kref_init);
EXPORT_SYMBOL(kref_get);
EXPORT_SYMBOL(kref_put);
+EXPORT_SYMBOL(kref_get_with_check);
Index: linux-2.6.11-rc4/Documentation/kref.txt
===
--- /dev/null
+++ linux-2.6.11-rc4/Documentation/kref.txt
@@ -0,0 +1,274 @@
+krefs allow you to add reference counters to your objects. If you
+have objects that are used in multiple places and passed around, and
+you don't have refcounts, your code is almost certainly broken. If
+you want refcounts, krefs are the way to go.
+
+To use a kref, add a one to your data structures like:
+
+struct my_data
+{
+ .
+ .
+ struct kref refcount;
+ .
+ .
+};
+
+The kref can occur anywhere within the data structure.
+
+You must initialize the kref after you allocate it. To do this, call
+kref init as so:
+
+ struct my_data *data;
+
+ data = kmalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+return -ENOMEM;
+ kref_init(&data->refcount);
+
+This sets the refcount in the kref to 1.
+
+Once you have a refcount, you must follow the following rules:
+
+1) If you make a non-temporary copy of a pointer, especially if
+ it can be passed to another thread of execution, you must
+ increment the refcount with kref_get() before passing it off:
+ kref_get(&data->refcount);
+ If you already have a valid pointer to a kref-ed structure (the
+ refcount cannot go to zero) you may do this without a lock.
+
+2) When you are done with a pointer, you must call kref_put():
+ kref_put(&data->refcount, data_release);
+ If this is the last reference to the pointer, the release
+ routine will be called. If the code never tries to get
+ a valid pointer to a kref-ed structure without already
+ holding a valid pointer, it is safe to do this without
+ a lock.
+
+3) If the code attempts to gain a reference to a kref-ed structure
+ without already holding a valid pointer, it must serialize access
+ where a kref_put() cannot occur during the kref_get(), and the
+ structure must remain valid during the kref_get().
+
+For example, if you allocate some data and then pass it to another
+thread to process:
+
+void data_release(struct kref *ref)
+{
+ struct my_data *data = container_of(ref, struct my_data, refcount);
+ kfree(data);
+}
+
+void more_data_handling(void *cb_data)
+{
+ struct my_data *data = cb_data;
+ .
+ . do stuff with data here
+ .
+ kref_put(data, data_release);
+}
+
+void my_data_handler(void)
+{
+ int rv = 0;
+ struct my_data *data;
+ data = kmalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+ kref_init(&data->refcount);
+
+ kref_get(&data->refcount);
+ rv = kthread_run(more_data_handling, data, "more_data_handling");
+ if (rv) {
+ kref_put(&data->refcount);
+ goto out;
+ }
+
+ .
+ . do stuff with data here
+ .
+ out:
+ kref_put(data, d
