HEADSUP: Call for FreeBSD Status Reports - 3Q/2010
Dear all, I would like to remind you that the next round of status reports covering the third quarter of 2010 is due on October 15th, 2010. This initiative is very welcome in our community. Therefore, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines - a short description about what you are working on, what are your plans and goals, so we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved with the FreeBSD community, you do not have to be a FreeBSD committer. Submissions about anything related to FreeBSD are very welcome! Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to mont...@freebsd.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to disallow logout
Atom Smasher wrote: On Fri, 10 Sep 2010, Ivan Voras wrote: 1) power outage of the server 2) power outage on the client 3) network problems (ssh or TCP connection drop) 4) administrative command (e.g. root executes "killall $shell") ? I don't think there is a way to protect from all of those, so any effort in protecting from only part of the problem looks useless. you forgot cosmic rays, nuclear war and zombie apocalypse, among other failure modes. *NOTHING* is capable of protecting against everything; a good solution will most always have pitfalls; as a sysadmin/engineer/manager one has to either accept the pitfalls or find a more acceptable solution, which usually means different pitfalls. that doesn't mean a given solution is useless. Bah. since you mentioned .logout, i'm assuming you are using tcsh. what i would suggest is that you create an md and check out the files into that. this solves the power fail issue completely, also, it solves the main issue. have the logout script simply umount and mdconfig -d the ramdisk. also, this way, security is enhanced because no fragments, even of deleted files, are left on disk after logout. the only question i have is if a bzero is done before returning the ram to the os, if not, simply dd if=/dev/zero of=/dev/md0 bs=whatever to be sure that the ram formeerly contained in the ramdisk isn't readable by later procs. have you considered trustedbsd? it should perform the bzero by default. TBSD MAC is in fbsd these days to control access to the mountpoint, but that might not help if you are worried about a lifted disk, MAC don't mean shit without physical security, the kind involved in the environments for which it was commissioned. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Adding a V=R mapping for amd64?
On Wed, Sep 29, 2010 at 1:12 PM, Kostik Belousov wrote:
> On Wed, Sep 29, 2010 at 12:40:57PM -0700, Matthew Fleming wrote:
>> I'm hacking around with making a "fast reboot" that puts a copy of the
>> MBR from disk into address 0x7c00 and, after disabling various
>> translation bits and stopping other CPUs, branches to it, to skip the
>> hardware self test that normally happens on boot.
>>
>> I haven't gotten to the point of attempting to run the code at 0x7c00
>> because I'm first hitting a different error. Despite my attempts to
>> enter a translation into the hardware page table, I get a panic trying
>> to write to address 0x7000, where I intended to put the trampoline
>> code that turns off translation.
>>
>> Rebooting...
>> Attempt to reset to MBR...
>> XXX attempting pmap_kenter()...
>> XXX copying bootstrap code...
>> panic @ time 1285760103.939, thread 0xff000775d960: Fatal trap 12:
>> page fault while in kernel mode
>>
>> cpuid = 0
>> Panic occurred in module kernel loaded at 0x8010:
>>
>> Stack: --
>> kernel:trap_fatal+0xac
>> kernel:trap_pfault+0x24c
>> kernel:trap+0x42e
>> kernel:bcopy+0x16
>> kernel:shutdown_reset+0x48
>> kernel:boot+0x317
>> kernel:reboot+0x60
>> kernel:ia32_syscall+0x1cd
>> --
>> cpuid = 0; apic id = 00
>> fault virtual address = 0x7000
>> fault code = supervisor write data, page not present
>> stack pointer = 0x10:0xff8059e07670
>> frame pointer = 0x10:0xff8059e07780
>>
>> Here's what I think is the relevant snippets of code. Note that I
>> reserved the vm_page_t for physical page 7 as mbr_page early in boot,
>> so I know the memory is free.
>>
>> void
>> pmap_kenter_VR(vm_paddr_t pa)
>> {
>> pmap_t pmap = kernel_pmap;
>> vm_page_t mpte;
>> pd_entry_t *pde;
>> pt_entry_t *pte;
>>
>> vm_page_lock_queues();
>> PMAP_LOCK(pmap);
>> mpte = pmap_allocpte(pmap, pa, M_WAITOK);
>>
>> pde = pmap_pde(pmap, pa);
>> if (pde == NULL || (*pde & PG_V) == 0)
>> panic("%s: invalid page directory va=%#lx", __func__, pa);
>> if ((*pde & PG_PS) != 0)
>> panic("%s: attempted pmap_enter on 2MB page", __func__);
>> pte = pmap_pde_to_pte(pde, pa);
>> if (pte == NULL)
>> panic("%s: no pte va=%#lx", __func__, pa);
>>
>> if (*pte != 0) {
>> /* Remove extra pte reference. */
>> mpte->wire_count--;
>> }
>> pte_store(pte, pa | PG_RW | PG_V | PG_G | pg_nx);
>>
>> vm_page_unlock_queues();
>> PMAP_UNLOCK(pmap);
>> }
>>
>> Then in cpu_reset():
>>
>> /*
>> * Establish a V=R mapping for the MBR page, and copy a
>> * reasonable guess at the size of the bootstrap code into the
>> * beginning of the page.
>> */
>> printf("XXX attempting pmap_kenter()...\n");
>> pmap_kenter_VR(trunc_page(mbaddr));
>> printf("XXX copying bootstrap code...\n");
>> to_copy = (uintptr_t)xxx_reset_end - (uintptr_t)xxx_reset_real;
>> if (to_copy > mbaddr - trunc_page(mbaddr))
>> to_copy = mbaddr - trunc_page(mbaddr);
>> bcopy(xxx_reset_real, (void *)trunc_page(mbaddr), to_copy); /* die
>> here */
>> printf("XXX attempting to turn off xlation and re-run MBR...\n");
>> xxx_reset_real(mbaddr);
>>
>>
>> My first attempt was a call to
>> pmap_kenter(trunc_page(0x7c00), trunc_page(0x7c00));
>> which failed trying to dereference the non-existent PDE.
>>
>> My second attempt called
>> pmap_enter(kernel_pmap, trunc_page(0x7c00), VM_PROT_WRITE, mbr_page,
>> VM_PROT_ALL, 0);
>> That failed with the same crash as the attempt using pmap_kenter_VR().
>>
>> So... any thoughts as to why, after an apparently successful
>> installation of an xlation, I still get a panic as though there were
>> no xlation?
>
> Weird formatting of backtrace. Is this some proprietary code ?
Yeah, there's some Isilon local modifications.
> Why do you try to create 1-1 mapping at all ? The MBR code should be
> executing in real mode anyway, and the mapping address at the moment of
> bcopy does not matter at all. I think that the use of PHYS_TO_DMAP()
> should give you direct mapping.
I assumed I need trampoline code. The moment I turn off the xlation
bits, if the instruction pointer I'm running from is the normal kernel
addresses, won't I die horribly trying to access 0x8000 or
so in real mode?
> About the #pf that you see. I think that this is due to the fact that
> you are modifying kernel pmap, while the active one is the pmap of
> the user process which context issued reboot().
Isn't the kernel pmap active in the kernel, since I've entered via the
syscall reboot(2) ?
Thanks,
matthew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
Re: Adding a V=R mapping for amd64?
On Wed, Sep 29, 2010 at 12:40:57PM -0700, Matthew Fleming wrote:
> I'm hacking around with making a "fast reboot" that puts a copy of the
> MBR from disk into address 0x7c00 and, after disabling various
> translation bits and stopping other CPUs, branches to it, to skip the
> hardware self test that normally happens on boot.
>
> I haven't gotten to the point of attempting to run the code at 0x7c00
> because I'm first hitting a different error. Despite my attempts to
> enter a translation into the hardware page table, I get a panic trying
> to write to address 0x7000, where I intended to put the trampoline
> code that turns off translation.
>
> Rebooting...
> Attempt to reset to MBR...
> XXX attempting pmap_kenter()...
> XXX copying bootstrap code...
> panic @ time 1285760103.939, thread 0xff000775d960: Fatal trap 12:
> page fault while in kernel mode
>
> cpuid = 0
> Panic occurred in module kernel loaded at 0x8010:
>
> Stack: --
> kernel:trap_fatal+0xac
> kernel:trap_pfault+0x24c
> kernel:trap+0x42e
> kernel:bcopy+0x16
> kernel:shutdown_reset+0x48
> kernel:boot+0x317
> kernel:reboot+0x60
> kernel:ia32_syscall+0x1cd
> --
> cpuid = 0; apic id = 00
> fault virtual address = 0x7000
> fault code = supervisor write data, page not present
> stack pointer = 0x10:0xff8059e07670
> frame pointer = 0x10:0xff8059e07780
>
> Here's what I think is the relevant snippets of code. Note that I
> reserved the vm_page_t for physical page 7 as mbr_page early in boot,
> so I know the memory is free.
>
> void
> pmap_kenter_VR(vm_paddr_t pa)
> {
> pmap_t pmap = kernel_pmap;
> vm_page_t mpte;
> pd_entry_t *pde;
> pt_entry_t *pte;
>
> vm_page_lock_queues();
> PMAP_LOCK(pmap);
> mpte = pmap_allocpte(pmap, pa, M_WAITOK);
>
> pde = pmap_pde(pmap, pa);
> if (pde == NULL || (*pde & PG_V) == 0)
> panic("%s: invalid page directory va=%#lx", __func__, pa);
> if ((*pde & PG_PS) != 0)
> panic("%s: attempted pmap_enter on 2MB page", __func__);
> pte = pmap_pde_to_pte(pde, pa);
> if (pte == NULL)
> panic("%s: no pte va=%#lx", __func__, pa);
>
> if (*pte != 0) {
> /* Remove extra pte reference. */
> mpte->wire_count--;
> }
> pte_store(pte, pa | PG_RW | PG_V | PG_G | pg_nx);
>
> vm_page_unlock_queues();
> PMAP_UNLOCK(pmap);
> }
>
> Then in cpu_reset():
>
> /*
>* Establish a V=R mapping for the MBR page, and copy a
>* reasonable guess at the size of the bootstrap code into the
>* beginning of the page.
>*/
> printf("XXX attempting pmap_kenter()...\n");
> pmap_kenter_VR(trunc_page(mbaddr));
> printf("XXX copying bootstrap code...\n");
> to_copy = (uintptr_t)xxx_reset_end - (uintptr_t)xxx_reset_real;
> if (to_copy > mbaddr - trunc_page(mbaddr))
> to_copy = mbaddr - trunc_page(mbaddr);
> bcopy(xxx_reset_real, (void *)trunc_page(mbaddr), to_copy); /* die
> here */
> printf("XXX attempting to turn off xlation and re-run MBR...\n");
> xxx_reset_real(mbaddr);
>
>
> My first attempt was a call to
> pmap_kenter(trunc_page(0x7c00), trunc_page(0x7c00));
> which failed trying to dereference the non-existent PDE.
>
> My second attempt called
> pmap_enter(kernel_pmap, trunc_page(0x7c00), VM_PROT_WRITE, mbr_page,
> VM_PROT_ALL, 0);
> That failed with the same crash as the attempt using pmap_kenter_VR().
>
> So... any thoughts as to why, after an apparently successful
> installation of an xlation, I still get a panic as though there were
> no xlation?
Weird formatting of backtrace. Is this some proprietary code ?
Why do you try to create 1-1 mapping at all ? The MBR code should be
executing in real mode anyway, and the mapping address at the moment of
bcopy does not matter at all. I think that the use of PHYS_TO_DMAP()
should give you direct mapping.
About the #pf that you see. I think that this is due to the fact that
you are modifying kernel pmap, while the active one is the pmap of
the user process which context issued reboot().
pgpXxYNsxfubF.pgp
Description: PGP signature
Adding a V=R mapping for amd64?
I'm hacking around with making a "fast reboot" that puts a copy of the
MBR from disk into address 0x7c00 and, after disabling various
translation bits and stopping other CPUs, branches to it, to skip the
hardware self test that normally happens on boot.
I haven't gotten to the point of attempting to run the code at 0x7c00
because I'm first hitting a different error. Despite my attempts to
enter a translation into the hardware page table, I get a panic trying
to write to address 0x7000, where I intended to put the trampoline
code that turns off translation.
Rebooting...
Attempt to reset to MBR...
XXX attempting pmap_kenter()...
XXX copying bootstrap code...
panic @ time 1285760103.939, thread 0xff000775d960: Fatal trap 12:
page fault while in kernel mode
cpuid = 0
Panic occurred in module kernel loaded at 0x8010:
Stack: --
kernel:trap_fatal+0xac
kernel:trap_pfault+0x24c
kernel:trap+0x42e
kernel:bcopy+0x16
kernel:shutdown_reset+0x48
kernel:boot+0x317
kernel:reboot+0x60
kernel:ia32_syscall+0x1cd
--
cpuid = 0; apic id = 00
fault virtual address = 0x7000
fault code = supervisor write data, page not present
stack pointer = 0x10:0xff8059e07670
frame pointer = 0x10:0xff8059e07780
Here's what I think is the relevant snippets of code. Note that I
reserved the vm_page_t for physical page 7 as mbr_page early in boot,
so I know the memory is free.
void
pmap_kenter_VR(vm_paddr_t pa)
{
pmap_t pmap = kernel_pmap;
vm_page_t mpte;
pd_entry_t *pde;
pt_entry_t *pte;
vm_page_lock_queues();
PMAP_LOCK(pmap);
mpte = pmap_allocpte(pmap, pa, M_WAITOK);
pde = pmap_pde(pmap, pa);
if (pde == NULL || (*pde & PG_V) == 0)
panic("%s: invalid page directory va=%#lx", __func__, pa);
if ((*pde & PG_PS) != 0)
panic("%s: attempted pmap_enter on 2MB page", __func__);
pte = pmap_pde_to_pte(pde, pa);
if (pte == NULL)
panic("%s: no pte va=%#lx", __func__, pa);
if (*pte != 0) {
/* Remove extra pte reference. */
mpte->wire_count--;
}
pte_store(pte, pa | PG_RW | PG_V | PG_G | pg_nx);
vm_page_unlock_queues();
PMAP_UNLOCK(pmap);
}
Then in cpu_reset():
/*
* Establish a V=R mapping for the MBR page, and copy a
* reasonable guess at the size of the bootstrap code into the
* beginning of the page.
*/
printf("XXX attempting pmap_kenter()...\n");
pmap_kenter_VR(trunc_page(mbaddr));
printf("XXX copying bootstrap code...\n");
to_copy = (uintptr_t)xxx_reset_end - (uintptr_t)xxx_reset_real;
if (to_copy > mbaddr - trunc_page(mbaddr))
to_copy = mbaddr - trunc_page(mbaddr);
bcopy(xxx_reset_real, (void *)trunc_page(mbaddr), to_copy); /* die
here */
printf("XXX attempting to turn off xlation and re-run MBR...\n");
xxx_reset_real(mbaddr);
My first attempt was a call to
pmap_kenter(trunc_page(0x7c00), trunc_page(0x7c00));
which failed trying to dereference the non-existent PDE.
My second attempt called
pmap_enter(kernel_pmap, trunc_page(0x7c00), VM_PROT_WRITE, mbr_page,
VM_PROT_ALL, 0);
That failed with the same crash as the attempt using pmap_kenter_VR().
So... any thoughts as to why, after an apparently successful
installation of an xlation, I still get a panic as though there were
no xlation?
Thanks,
matthew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Unnecessary reads on write load
Tracking down a performance issue where the system apparently needlessly
reads on a 100% write load... consider the following C test case: (more
after the code)
#include
#include
#include
#include
int main(int argc, char **argv)
{
unsigned char dir1[4], dir2[4], filename[15], pathname[1024],
buffer[130944];
unsigned int filenum, count, filesize;
int fd;
arc4random_buf(buffer, 131072);
count=atoi(argv[1]);
for(;count>0;count--) {
filenum=arc4random();
filesize=arc4random_uniform(130944) + 128;
sprintf(filename, "%08x", filenum);
strncpy(dir1,filename,3);
strncpy(dir2,filename+3, 3);
dir1[3]=dir2[3]=0;
sprintf(pathname, "%s/%s/%s", dir1, dir2, filename);
fd=open(pathname, O_CREAT | O_WRONLY, 0644);
if (fd < 0) {
sprintf(pathname, "%s/%s", dir1, dir2);
if (mkdir(pathname, 0755) < 0) {
mkdir(dir1, 0755);
mkdir(pathname, 0755);
};
sprintf(pathname, "%s/%s/%s", dir1, dir2, filename);
fd=open(pathname, O_CREAT | O_WRONLY, 0644);
}
if (fd <0)
continue;
write(fd,buffer, filesize);
close(fd);
}
return 0;
}
In running that in an empty directory (it takes one argument, the number
of files to create), I see that it spends most of its time in BIORD?!.
If I have a debugging kernel I can see that its all in NAMI cache
misses, and doing block fetches... but "why?" the only directories that
exist are ones that it just created, and should therefore be in the
cache, right? Any ideas? Give it a try yourself and tell me what you get.
--
David E. Cross
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: question regarding link_elf.c
Dnia 29-09-2010 o godz. 16:58 Andriy Gapon napisał(a):
> on 29/09/2010 17:44 PL said the following:
> > Dnia 29-09-2010 o godz. 16:23 Andriy Gapon napisał(a):
> >> on 29/09/2010 17:13 PL said the following:
> >>> It seems like it is not a problem in my own code, since readelf -S on a
> >>> elf file
> >>> gives me the same results as my debug messages. I've created an empty
> >>> module, to
> >>> simplify debugging. Both my code, and readelf says, that '.text' section
> >>> address
> >>> is 0x3e0, and its size is 7 bytes. Adding 0x3e0 to lf->address points to
> >>> a valid location.
> >>>
> >>> '.data' is supposed to be at 0x1424 (again, both my code and readelf
> >>> returns the same thing),
> >>> but the actual data starts at lf->address + 0x3e7. How do I know ? I've
> >>> added global
> >>> initialized string variable in empty test module, and Im looking at the
> >>> memory to determine
> >>> it's location. I'm not sure what is wrong then.
> >>
> >>
> >> Can you post a link to the compiled test module?
> >>
> >> --
> >> Andriy Gapon
> >
> > Well.. i don't have any public 'hosting', but I put it in here:
> >
> > http://www.4shared.com/dir/LHn_I393/sharing.html
> >
> > Also, the code is as simple as:
> >
> > 1 #include
> > 2 #include
> > 3 #include
> > 4
> > 5
> > 6 char *str = "THIS IS A STR MARKING DATA START";
>
> You marker was put into .rodata section.
> Try char str[] instead.
>
> > 8 static int kms_null_handler(module_t m, int op, void *data)
> > 9 {
> > 10 return (0);
> > 11 }
> > 12
> > 13 static moduledata_t kms_null_data = {
> > 14 "kms_null",
> > 15 kms_null_handler,
> > 16 NULL,
> > 17 };
> > 18
> > 19 DECLARE_MODULE(kms_null, kms_null_data, SI_SUB_EXEC, SI_ORDER_ANY);
> >
> > It is being compiled on i386/GENERIC kernel.
> >
> >
>
>
> --
> Andriy Gapon
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
THANKS ! How could I miss that ? :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: question regarding link_elf.c
on 29/09/2010 17:44 PL said the following:
> Dnia 29-09-2010 o godz. 16:23 Andriy Gapon napisał(a):
>> on 29/09/2010 17:13 PL said the following:
>>> It seems like it is not a problem in my own code, since readelf -S on a
>>> elf file
>>> gives me the same results as my debug messages. I've created an empty
>>> module, to
>>> simplify debugging. Both my code, and readelf says, that '.text' section
>>> address
>>> is 0x3e0, and its size is 7 bytes. Adding 0x3e0 to lf->address points to
>>> a valid location.
>>>
>>> '.data' is supposed to be at 0x1424 (again, both my code and readelf
>>> returns the same thing),
>>> but the actual data starts at lf->address + 0x3e7. How do I know ? I've
>>> added global
>>> initialized string variable in empty test module, and Im looking at the
>>> memory to determine
>>> it's location. I'm not sure what is wrong then.
>>
>>
>> Can you post a link to the compiled test module?
>>
>> --
>> Andriy Gapon
>
> Well.. i don't have any public 'hosting', but I put it in here:
>
> http://www.4shared.com/dir/LHn_I393/sharing.html
>
> Also, the code is as simple as:
>
> 1 #include
> 2 #include
> 3 #include
> 4
> 5
> 6 char *str = "THIS IS A STR MARKING DATA START";
You marker was put into .rodata section.
Try char str[] instead.
> 8 static int kms_null_handler(module_t m, int op, void *data)
> 9 {
> 10 return (0);
> 11 }
> 12
> 13 static moduledata_t kms_null_data = {
> 14 "kms_null",
> 15 kms_null_handler,
> 16 NULL,
> 17 };
> 18
> 19 DECLARE_MODULE(kms_null, kms_null_data, SI_SUB_EXEC, SI_ORDER_ANY);
>
> It is being compiled on i386/GENERIC kernel.
>
>
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: question regarding link_elf.c
Dnia 29-09-2010 o godz. 16:23 Andriy Gapon napisał(a):
> on 29/09/2010 17:13 PL said the following:
> > It seems like it is not a problem in my own code, since readelf -S on a
> > elf file
> > gives me the same results as my debug messages. I've created an empty
> > module, to
> > simplify debugging. Both my code, and readelf says, that '.text' section
> > address
> > is 0x3e0, and its size is 7 bytes. Adding 0x3e0 to lf->address points to
> > a valid location.
> >
> > '.data' is supposed to be at 0x1424 (again, both my code and readelf
> > returns the same thing),
> > but the actual data starts at lf->address + 0x3e7. How do I know ? I've
> > added global
> > initialized string variable in empty test module, and Im looking at the
> > memory to determine
> > it's location. I'm not sure what is wrong then.
>
>
> Can you post a link to the compiled test module?
>
> --
> Andriy Gapon
Well.. i don't have any public 'hosting', but I put it in here:
http://www.4shared.com/dir/LHn_I393/sharing.html
Also, the code is as simple as:
1 #include
2 #include
3 #include
4
5
6 char *str = "THIS IS A STR MARKING DATA START";
7
8 static int kms_null_handler(module_t m, int op, void *data)
9 {
10 return (0);
11 }
12
13 static moduledata_t kms_null_data = {
14 "kms_null",
15 kms_null_handler,
16 NULL,
17 };
18
19 DECLARE_MODULE(kms_null, kms_null_data, SI_SUB_EXEC, SI_ORDER_ANY);
It is being compiled on i386/GENERIC kernel.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: question regarding link_elf.c
on 29/09/2010 17:13 PL said the following: > It seems like it is not a problem in my own code, since readelf -S on a > elf file > gives me the same results as my debug messages. I've created an empty > module, to > simplify debugging. Both my code, and readelf says, that '.text' section > address > is 0x3e0, and its size is 7 bytes. Adding 0x3e0 to lf->address points to > a valid location. > > '.data' is supposed to be at 0x1424 (again, both my code and readelf > returns the same thing), > but the actual data starts at lf->address + 0x3e7. How do I know ? I've > added global > initialized string variable in empty test module, and Im looking at the > memory to determine > it's location. I'm not sure what is wrong then. Can you post a link to the compiled test module? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: question regarding link_elf.c
Dnia 29-09-2010 o godz. 10:58 Andriy Gapon napisał(a): > on 29/09/2010 11:18 PL said the following: > > Hi everyone, > > I'm not quiet sure if it is proper place to ask the question I have. If > > not, please > > direct me to the correct place I should post questions like: > > > > Im working on some modifications around link_elf.c. According to elf(5) > > man pages, > > Elf_Shdr structure contains field called 'sh_addr', containing the > > address at > > which first byte of a section shall reside in the memory image. I am > > particularily > > interested in '.text' and '.data' sections. After link_elf_load_file() > > loads the > > file into a memory, we have linker_file structure filled in, including > > 'address' > > field. Now, assuming 'lf' being linker_file_t, already filled in by the > > loading > > routine, 'text_sh' being 'Elf_Shdr' for text section, and 'data_sh' > > being 'Elf_Shdr' > > for data section: > > - lf->address + text_sh.sh_addr really points to the beginning of a > > '.text' section > > in memory, however.. > > > > - lf->address + data_sh.sh_addr does not point to the valid location of > > '.data' section > > in memory. > > > > Sorry if my question is stupid, but im wondering why it is so ? I guess > > it has something > > to do with virtual memory mapping (?). > > Perhaps the reason is simpler, like a bug in your code :-) > You can do 'readelf -a' on a module that you load and check attributes > of .data > section and then compare with data_sh that you get at run-time. > > -- > Andriy Gapon > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" It seems like it is not a problem in my own code, since readelf -S on a elf file gives me the same results as my debug messages. I've created an empty module, to simplify debugging. Both my code, and readelf says, that '.text' section address is 0x3e0, and its size is 7 bytes. Adding 0x3e0 to lf->address points to a valid location. '.data' is supposed to be at 0x1424 (again, both my code and readelf returns the same thing), but the actual data starts at lf->address + 0x3e7. How do I know ? I've added global initialized string variable in empty test module, and Im looking at the memory to determine it's location. I'm not sure what is wrong then. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: PATCH: fix bogus error message "bus_dmamem_alloc failed to align memory properly"
On Tuesday, September 28, 2010 4:02:08 pm Neel Natu wrote:
> Hi John,
>
> On Tue, Sep 28, 2010 at 6:36 AM, John Baldwin wrote:
> > On Monday, September 27, 2010 5:13:03 pm Neel Natu wrote:
> >> Hi John,
> >>
> >> Thanks for reviewing this.
> >>
> >> On Mon, Sep 27, 2010 at 8:04 AM, John Baldwin wrote:
> >> > On Friday, September 24, 2010 9:00:44 pm Neel Natu wrote:
> >> >> Hi,
> >> >>
> >> >> This patch fixes the bogus error message from bus_dmamem_alloc() about
> >> >> the buffer not being aligned properly.
> >> >>
> >> >> The problem is that the check is against a virtual address as opposed
> >> >> to the physical address. contigmalloc() makes guarantees about
> >> >> the alignment of physical addresses but not the virtual address
> >> >> mapping it.
> >> >>
> >> >> Any objections if I commit this patch?
> >> >
> >> > Hmmm, I guess you are doing super-page alignment rather than sub-page
> >> > alignment? In general I thought the busdma code only handled sub-page
> >> > alignment and doesn't fully handle requests for super-page alignment.
> >> >
> >>
> >> Yes, this is for allocations with sizes greater than PAGE_SIZE and
> >> alignment requirements also greater than a PAGE_SIZE.
> >>
> >> > For example, since it insists on walking individual pages at a time, if
> >> > you
> >> > had an alignment setting of 4 pages and passed in a single, aligned
> >> > 4-page
> >> > buffer, bus_dma would actually bounce the last 3 pages so that each
> >> > individual
> >> > page is 4-page aligned. At least, I think that is what would happen.
> >> >
> >>
> >> I think you are referring to bus_dmamap_load() operation that would
> >> follow the bus_dmamem_alloc(), right? The memory allocated by
> >> bus_dmamem_alloc() does not need to be bounced. In fact, the dmamap
> >> pointer returned by bus_dmamem_alloc() is NULL.
> >>
> >> At least for the amd64 implementation there is code in
> >> _bus_dmamap_load_buffer() which will coalesce individual dma segments
> >> if they satisfy 'boundary' and 'segsize' constraints.
> >
> > So the problem is earlier in the routine where it does this:
> >
> >/*
> > * Get the physical address for this segment.
> > */
> >if (pmap)
> >curaddr = pmap_extract(pmap, vaddr);
> >else
> >curaddr = pmap_kextract(vaddr);
> >
> >/*
> > * Compute the segment size, and adjust counts.
> > */
> >max_sgsize = MIN(buflen, dmat->maxsegsz);
> >sgsize = PAGE_SIZE - ((vm_offset_t)curaddr & PAGE_MASK);
> >if (map->pagesneeded != 0 && run_filter(dmat, curaddr)) {
> >sgsize = roundup2(sgsize, dmat->alignment);
> >sgsize = MIN(sgsize, max_sgsize);
> >curaddr = add_bounce_page(dmat, map, vaddr, sgsize);
> >} else {
> >sgsize = MIN(sgsize, max_sgsize);
> >}
> >
> > If you have a map that does need bouncing, then it will split up the pages.
> > It happens to work for bus_dmamem_alloc() because that returns a NULL map
> > which doesn't bounce. But if you had a PCI device which supported only
> > 32-bit addresses on a 64-bit machine with an aligned, 4 page buffer above
> > 4GB and did a bus_dma_map_load() on that buffer, it would get split up into
> > 4 separate 4 page-aligned pages.
> >
>
> You are right.
>
> I assume that you are ok with the patch and the discussion above was
> an FYI, right?
I think the patch is ok, but my point is that super-page alignment isn't
really part of the design of the current bus_dma and only works for
bus_dmammem_alloc() by accident.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
8.1-R - Marvell 88SX6081 SATA controller via mvs = lots of errors
Hi, I just switched my 8.1-R/amd64 (dual Opteron) system from ATA over to the new mvs driver, and started seeing a whole bunch of errors (which appear to have hosed one of my zfs volumes during a scrub) - anyone know what the following errors actually mean? The machine has 2 * 88SX6081's in it: " Sep 28 19:58:49 kernel: mvs0: port 0x3000-0x30ff mem 0xd010-0xd01f,0xd040-0xd07f irq 24 at device 4.0 on pci17 Sep 28 19:58:49 kernel: mvs0: Gen-II, 8 3Gbps ports, Port Multiplier ... Sep 28 19:58:49 kernel: mvs1: port 0x4000-0x40ff mem 0xd0c0-0xd0cf,0xd080-0xd0bf irq 28 at device 4.0 on pci18 Sep 28 19:58:49 kernel: mvs1: Gen-II, 8 3Gbps ports, Port Multiplier supported " Under 7.2 they ran fine, with the ATA driver. I use ZFS on this machine - and both pools were scrubbed before the upgrade (and backed up fortunately!). With the mvs driver, during a scrub of the main volume, I see: " Sep 29 08:56:13 kernel: mvsch12: EMPTY CRPB 6 (->14) 1 4000 Sep 29 08:56:13 kernel: mvsch12: EMPTY CRPB 7 (->14) 0 4000 Sep 29 08:56:13 kernel: mvsch12: EMPTY CRPB 8 (->14) 2 4000 " [repeated a lot - interspersed with zfs reporting problems with files, on all the devices in the pool] I then also get a whole bunch of: " Sep 29 08:56:56 kernel: mvsch0: Timeout on slot 1 Sep 29 08:56:56 kernel: mvsch0: iec 0200 sstat 0123 serr edma_s 1020 dma_c dma_s rs 0006 statu s 40 Sep 29 08:56:56 kernel: mvsch0: ... waiting for slots 0004 Sep 29 08:56:56 kernel: mvsch12: Timeout on slot 5 Sep 29 08:56:56 kernel: mvsch12: iec 0200 sstat 0123 serr edma_s 1121 dma_c dma_s rs 0028 stat us 40 " The system has 2 pools (one is 12 disks of mirrored pairs - each side of the mirror is on alternate Marvell's), the other is 1 RAIDZ of 4 disks, 2 are on alternate Marvell's - the other 2 drives are on the motherboards nForce CK804 ports). I scrubbed the second pool yesterday without incident, so this only seemed to happen using drives exclusively on the 88SX6081's (or the I/O system is stressed, running the I/O for all 12 drives through the Marvells, as opposed to just the I/O for 2 drives [1 each] through the Marvells when the other pool is scrubbed). -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: question regarding link_elf.c
on 29/09/2010 11:18 PL said the following: > Hi everyone, > I'm not quiet sure if it is proper place to ask the question I have. If > not, please > direct me to the correct place I should post questions like: > > Im working on some modifications around link_elf.c. According to elf(5) > man pages, > Elf_Shdr structure contains field called 'sh_addr', containing the > address at > which first byte of a section shall reside in the memory image. I am > particularily > interested in '.text' and '.data' sections. After link_elf_load_file() > loads the > file into a memory, we have linker_file structure filled in, including > 'address' > field. Now, assuming 'lf' being linker_file_t, already filled in by the > loading > routine, 'text_sh' being 'Elf_Shdr' for text section, and 'data_sh' > being 'Elf_Shdr' > for data section: > - lf->address + text_sh.sh_addr really points to the beginning of a > '.text' section > in memory, however.. > > - lf->address + data_sh.sh_addr does not point to the valid location of > '.data' section > in memory. > > Sorry if my question is stupid, but im wondering why it is so ? I guess > it has something > to do with virtual memory mapping (?). Perhaps the reason is simpler, like a bug in your code :-) You can do 'readelf -a' on a module that you load and check attributes of .data section and then compare with data_sh that you get at run-time. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
question regarding link_elf.c
Hi everyone, I'm not quiet sure if it is proper place to ask the question I have. If not, please direct me to the correct place I should post questions like: Im working on some modifications around link_elf.c. According to elf(5) man pages, Elf_Shdr structure contains field called 'sh_addr', containing the address at which first byte of a section shall reside in the memory image. I am particularily interested in '.text' and '.data' sections. After link_elf_load_file() loads the file into a memory, we have linker_file structure filled in, including 'address' field. Now, assuming 'lf' being linker_file_t, already filled in by the loading routine, 'text_sh' being 'Elf_Shdr' for text section, and 'data_sh' being 'Elf_Shdr' for data section: - lf->address + text_sh.sh_addr really points to the beginning of a '.text' section in memory, however.. - lf->address + data_sh.sh_addr does not point to the valid location of '.data' section in memory. Sorry if my question is stupid, but im wondering why it is so ? I guess it has something to do with virtual memory mapping (?). Thanks in advance for your kind help. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
