Re: kexec not working

[Rami Rosen]

Hi Ronit,
Can you please tell what happens when you ran the "kexec -p" that you
mentioned ? Do you see any message on screen ? Does it hang immediately ?
Regards,
Rami Rosen
בתאריך 6 במרץ 2016 05:23, "Ronit Halder"  כתב:

> When I am doing normal load of kernel using kexec, it works.
>
> #kexec -l /boot/vmlinuz-4.3.0-crash+
> --initrd=/boot/initramfs-4.3.0-crash+.img
> --append="root=/dev/mapper/fedora-root  1 irqpoll maxcpus=1
> reset_devices"
>
> #kexec -e
>
>
> But, when I am doing load on panic using kexec, it isn't working.
>
> #kexec -p /boot/vmlinuz-4.3.0-crash+
> --initrd=/boot/initramfs-4.3.0-crash+.img
> --append="root=/dev/mapper/fedora-root  1 irqpoll maxcpus=1
> reset_devices"
>
> #echo "1" >/proc/sys/kernel/sysrq
>
> #echo c > /proc/sysrq-trigger
>
>
> What am I doing wrong?
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: remote system call

[Nitin Varyani]

Codes are huge and documentation is negligible. How can I separate whay I
want to achieve from that big code?

On Thu, Mar 3, 2016 at 10:07 PM, Mulyadi Santosa 
wrote:

>
>
> On Thu, Mar 3, 2016 at 6:12 PM, Nitin Varyani 
> wrote:
>
>> Hi,
>>   I want to migrate user context of a process to a remote machine
>> (i.e. registers, code, data, virtual memory and program counter) and when
>> it makes a system call or file i/o, I want to send that request to its home
>> node.
>>
>> That is, the user process executing at remote node will copy desired
>> system call number to %eax of home node and will execute 'int 0x80'. This
>> will generate interrupt 0x80 which should be sent to home node and an
>> interrupt service routine at home node will be called. This routine will
>> execute in ring 0 of home node.
>>
>> A portion of process context which is system dependent has to be kept at
>> the home node.
>>
>> That is, link to open files and link to kernel stack.
>>
>> For eg: the following portion of the task_struct has to be kept at home
>> node
>> /* filesystem information */
>> struct fs_struct *fs;
>> /* open file information */
>> struct files_struct *files;
>>
>>
>>
>> Is it feasible? Can someone show some more light into it?
>>
>> Nitin
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
> Feasible, yes.
>
> Try to check the source code of MOSIX/OpenMosix or OpenSSI.
>
> Kerrighed is another project which done similar thing too.
>
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: GSoC: RFC: fbdev fbtft auxdisplay or IIO

[gre...@linuxfoundation.org]

On Sat, Mar 05, 2016 at 06:02:09PM +0100, Martin Kepplinger wrote:
> Hi GregKH,
> 
> In looking around what I could do in the mid-future, possibly as a GSoC
> project (?), I have 2 questions:
> 
> Is there active ongoing work on getting rid of drivers/auxdisplay? There
> are 2 drivers left in there... If not, would that be desired?

I really do not know, do you have the hardware for those devices?

> What is the status of fbtft? Moving drivers *in* to staging feels wrong,
> but fbtft isn't yet present in the main tree. I would guess that fbtft
> is where these auxdisplay drivers could go. Would you put them into
> another area? fbdev?

There's a thread in the archives somewhere that talks about moving fbtft
into being a "real" drm driver.  I suggest you look into that if you are
curious.

> Different topic: IIO: I have ideas for mma8452 driver additions, and
> along this way, additions to the iio sysfs ABI. Would it make sense to
> lay this out and make a project out of it?

That might be good, care to go into more details about this?

thanks,

greg k-h

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Booting with SYSLINUX on Loopback Device: Kernel Panic - Where to Start?

[Patrick]

>
> What filesystem is on the /dev/sda image that qemu is using?  You'll need
> to
> ​​
> ​
> either build your kernel with the support for that built into the kernel,
> or an initrd that modprobes the filesystem module, and then mounts the
> filesystem (then there's a few fun and games involved in pivoting from
> the ram filesystem the initrd is using as root, to the disk image
> filesystem
> that you want as the root filesystem after boot).
>


​Thanks for the response. This is helpful. I copied the vmlinuz and initrd
image from my host, and that seemed to get me further.

Now blkid says:

/dev/sda: ​SEC_TYPE="msdos" UUID="6815-7325" TYPE="vfat"

The mount command indicates that it mounted successfully at /root.

​The contents of /root are just:

​vmlinuz syslinux.cfg initrd.img ldlinux.c32 ldlinux.sys

I realize that isn't enough to get the system up, so I would like to try to
figure out what I need to drop in there to get the system going. I think
that the other responses that people have so kindly sent to my question
might help me further, since they talk about init.

Although I copied vmlinuz and initrd from the host to get this far, I hope
to eventually figure out how to do something less hacky. I am able to build
the kernel, but I don't really know what's involved with building initrd
for the guest. (It seems I was able to build one on the host using
initramfs, but I'd like to figure out how to build one for the host. I'd
also like to better understand the "fun and games" you were talking about
with pivoting from the ram filesystem to the disk image filesystem. ...but
I'll take it one step at a time, I guess.)

By the way, I'm a double alum (BS and MS) from VT. Go Hokies!

Thanks again,
Patrick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

GSoC: RFC: fbdev fbtft auxdisplay or IIO

[Martin Kepplinger]

Hi GregKH,

In looking around what I could do in the mid-future, possibly as a GSoC
project (?), I have 2 questions:

Is there active ongoing work on getting rid of drivers/auxdisplay? There
are 2 drivers left in there... If not, would that be desired?

What is the status of fbtft? Moving drivers *in* to staging feels wrong,
but fbtft isn't yet present in the main tree. I would guess that fbtft
is where these auxdisplay drivers could go. Would you put them into
another area? fbdev?

Different topic: IIO: I have ideas for mma8452 driver additions, and
along this way, additions to the iio sysfs ABI. Would it make sense to
lay this out and make a project out of it?

Thanks for your time and work,

  martin
-- 
Martin Kepplinger
https://martinkepplinger.com

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies