Re: kern_yield vs ukbd_yield
on 17/12/2011 19:06 Hans Petter Selasky said the following: If the problem is only in UKBD driver, I don't think this is a big problem to solve. The reason for the auto-magic locking, is that I've sometimes seen callers in non-polling mode call into UKBD without Giant locked. And this causes a panic when starting USB transfers, because the code expects Giant to be locked. Hmm, do you have an example of such a panic? I couldn't find how this could be possible in my examination of non-polling entry points into syscons and kbd drives. Requirement: I would say that to use UKBD polling mode, the scheduler must be stopped. Else you should not use polling mode at all. I think that mountroot is getting characters the wrong way in this regard. I think that this is a too strong / unnecessary requirement. I think that now (after my recent syscons commits) ukbd should work correctly and optimally in this context. I have written a small article about my analysis of locking in syscons, underlying kbd drivers and ukbd in particular: http://wiki.freebsd.org/AvgSyscons I could have misunderstood or missed things, so I will appreciate a review and discussion of my observations. Thank you! -- 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: kern_yield vs ukbd_yield
On Sunday 18 December 2011 11:58:57 Andriy Gapon wrote: on 17/12/2011 19:06 Hans Petter Selasky said the following: If the problem is only in UKBD driver, I don't think this is a big problem to solve. The reason for the auto-magic locking, is that I've sometimes seen callers in non-polling mode call into UKBD without Giant locked. And this causes a panic when starting USB transfers, because the code expects Giant to be locked. Hmm, do you have an example of such a panic? I couldn't find how this could be possible in my examination of non-polling entry points into syscons and kbd drives. mtx_assert(Giant, MTX_OWNED); will panic if Giant is not locked. Do you need an example? Requirement: I would say that to use UKBD polling mode, the scheduler must be stopped. Else you should not use polling mode at all. I think that mountroot is getting characters the wrong way in this regard. I think that this is a too strong / unnecessary requirement. I think that now (after my recent syscons commits) ukbd should work correctly and optimally in this context. I have written a small article about my analysis of locking in syscons, underlying kbd drivers and ukbd in particular: http://wiki.freebsd.org/AvgSyscons I could have misunderstood or missed things, so I will appreciate a review and discussion of my observations. Thank you! I will have a look at it when I find some time! --HPS ___ 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: kern_yield vs ukbd_yield
on 18/12/2011 19:39 Hans Petter Selasky said the following: On Sunday 18 December 2011 11:58:57 Andriy Gapon wrote: on 17/12/2011 19:06 Hans Petter Selasky said the following: If the problem is only in UKBD driver, I don't think this is a big problem to solve. The reason for the auto-magic locking, is that I've sometimes seen callers in non-polling mode call into UKBD without Giant locked. And this causes a panic when starting USB transfers, because the code expects Giant to be locked. Hmm, do you have an example of such a panic? I couldn't find how this could be possible in my examination of non-polling entry points into syscons and kbd drives. mtx_assert(Giant, MTX_OWNED); will panic if Giant is not locked. Do you need an example? Yes :-) I want to see a non-polled code path in the keyboard layer where Giant is not locked. Requirement: I would say that to use UKBD polling mode, the scheduler must be stopped. Else you should not use polling mode at all. I think that mountroot is getting characters the wrong way in this regard. I think that this is a too strong / unnecessary requirement. I think that now (after my recent syscons commits) ukbd should work correctly and optimally in this context. I have written a small article about my analysis of locking in syscons, underlying kbd drivers and ukbd in particular: http://wiki.freebsd.org/AvgSyscons I could have misunderstood or missed things, so I will appreciate a review and discussion of my observations. Thank you! I will have a look at it when I find some time! Hope it won't be long. Thank you! -- 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
sysctl variable question
Hi all, I'm writing a small module just for fun. I would like to have two variables: - pid of type unsigned int and RW so the user can set a pid - process_name as a string RD that will display the process name associated to that pid (or a message if the pid doesn't exist anymore) My problem is with the handler functions. For process_name, as it is read only, I wrote a simple handler that works fine. However, I want to write another one for pid so I can sanitize the input (avoiding pids 0 and so). As I understand, the handler I specify with SYSCTL_OID will be called for both reads and writes. But, how can I tell what kind of operation is it, so I know if I have to use SYSCTL_OUT or SYSCTL_IN? I tried to have a look at sysctl_handle_int but I don't fully understand what is going on with the arg1 parameter. What is it for? Thanks in advance. ___ 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: sysctl variable question
On 12/18/11 12:18 PM, Fernando Apesteguía wrote: Hi all, I'm writing a small module just for fun. I would like to have two variables: - pid of type unsigned int and RW so the user can set a pid - process_name as a string RD that will display the process name associated to that pid (or a message if the pid doesn't exist anymore) this is dangerous as there are some places in the kernel where processes are referenced by pid, so changing it may break kernel assumptions. My problem is with the handler functions. For process_name, as it is read only, I wrote a simple handler that works fine. However, I want to write another one for pid so I can sanitize the input (avoiding pids 0 and so). As I understand, the handler I specify with SYSCTL_OID will be called for both reads and writes. But, how can I tell what kind of operation is it, so I know if I have to use SYSCTL_OUT or SYSCTL_IN? I tried to have a look at sysctl_handle_int but I don't fully understand what is going on with the arg1 parameter. What is it for? Thanks in advance. ___ 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 ___ 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: mfi (Dell H700) + hot swapping doesn't appear to work with RC1
On 15/12/2011, at 2:16 AM, Borja Marcos wrote: On Dec 14, 2011, at 2:09 PM, Hugo Silva wrote: Hello, First of all apologies if this has been fixed in RC3. I set this server up with mfsbsd, which is RC1, and didn't get to update the system yet. This box has 6 hdds, a 2-mirror zpool was set up as the root pool, with 2 spares. While testing hot swapping I noticed that while the controller detects disk removal/insertion, the zpool will never recover. The problem seems to be deeper than ZFS, as disklabel/fdisk/etc also fail on the removed-and-reinserted disk. At the ZFS level, doing a zpool clear yields more errors on the removed disk; rebooting becomes the only option to make the pool healthy again. Is this normal? Did I miss any step? I assume that you have tried to use the H700 as a JBOD card, defining logical volume for each hard disk. The problem is: that gorgeous, fantastic, masterful, Nobel award candidate card, has a wonderful behavior in that case. If you extract one of the disks, the logical volume associated to it is invalidated. So, you insert a replacement disk, and the card refuses to recognize the volume. What is even worse, in order to recover it's mandatory to reboot the complete system *AND* go through the RAID configuration utility. That's the problem. The card refuses to work as a simple disk controller without frills, and the frills get in the way. To summarize: it isn't FreeBSD's fault, no matter which version you use. It's a feature coming directly from the geniuses who designed the card. Hugo: You missed a step. Borja: No reboot required. For the mfi controllers I have been testing recently (MegaRAID 9261-8i), you need to install the sysutils/megacli port, and use that to clear the foreignness of the disk you just added. Something like: MegaCli -CfgForeign -Clear -a0 You should be able to then recreate it as a JBOD device, and progress through whatever higher level recovery you need to do. Regards, Jan Mikkelsen ___ 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: sysctl variable question
El 18/12/2011 22:12, Julian Elischer jul...@freebsd.org escribió: On 12/18/11 12:18 PM, Fernando Apesteguía wrote: Hi all, I'm writing a small module just for fun. I would like to have two variables: - pid of type unsigned int and RW so the user can set a pid - process_name as a string RD that will display the process name associated to that pid (or a message if the pid doesn't exist anymore) this is dangerous as there are some places in the kernel where processes are referenced by pid, so changing it may break kernel assumptions. Sorry, i think i didn't explain it clearly. The pid variable is static in my module and it is used just to tell the module which information it should show in the other variable. My problem is with the handler functions. For process_name, as it is read only, I wrote a simple handler that works fine. However, I want to write another one for pid so I can sanitize the input (avoiding pids 0 and so). As I understand, the handler I specify with SYSCTL_OID will be called for both reads and writes. But, how can I tell what kind of operation is it, so I know if I have to use SYSCTL_OUT or SYSCTL_IN? I tried to have a look at sysctl_handle_int but I don't fully understand what is going on with the arg1 parameter. What is it for? Thanks in advance. ___ 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 ___ 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: sysctl variable question
2011/12/18 Fernando Apesteguía fernando.apesteg...@gmail.com: El 18/12/2011 22:12, Julian Elischer jul...@freebsd.org escribió: On 12/18/11 12:18 PM, Fernando Apesteguía wrote: Hi all, I'm writing a small module just for fun. I would like to have two variables: - pid of type unsigned int and RW so the user can set a pid - process_name as a string RD that will display the process name associated to that pid (or a message if the pid doesn't exist anymore) this is dangerous as there are some places in the kernel where processes are referenced by pid, so changing it may break kernel assumptions. Sorry, i think i didn't explain it clearly. The pid variable is static in my module and it is used just to tell the module which information it should show in the other variable. Many sysctl handlers look for a req-newptr and leave early if it's NULL. If it's non-NULL then you can use SYSCTL_IN to fetch the data. Note that a caller of sysctl(3) API can specify both old pointer and new pointer, which is why most handlers always do a SYSCTL_OUT on the current value. Cheers, matthew My problem is with the handler functions. For process_name, as it is read only, I wrote a simple handler that works fine. However, I want to write another one for pid so I can sanitize the input (avoiding pids 0 and so). As I understand, the handler I specify with SYSCTL_OID will be called for both reads and writes. But, how can I tell what kind of operation is it, so I know if I have to use SYSCTL_OUT or SYSCTL_IN? I tried to have a look at sysctl_handle_int but I don't fully understand what is going on with the arg1 parameter. What is it for? Thanks in advance. ___ 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 ___ 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 ___ 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
