The Daily Fortune
[databat@ebob ~]$ /usr/games/fortune
If God hadn't wanted you to be paranoid, he wouldn't have given you such a vivid imagination.
[databat@ebob ~]$
This blog started out as an e-zine, or an electronic magazine. It contains technology, computer, and internet related articles. You will also find poetry, fictional stories, art, and other various tidbits related to cyber culture. Visit often, as content is updated almost daily.
[databat@ebob ~]$ /usr/games/fortune
If God hadn't wanted you to be paranoid, he wouldn't have given you such a vivid imagination.
[databat@ebob ~]$
Posted by databat at 1:00 AM 0 comments
Labels: The Daily Fortune
Ever want to make a sand sculpture? Well now here's your chance!!!
http://kopykat.com/sand.html
Posted by GracieDuck at 12:48 AM 0 comments
Labels: icywind's thoughts
My heart went out to her when I read this post. As much as I may joke about people not knowing what they're doing when it comes to computers, it's mainly because those people usually don't try. She tried her best, and with impaired vision. Props to you CyberGal. You have my respect and admiration. Congratulations on a job well done. Read her traumatic story.
CyberGalsBlog: Installing RAM: From Arrogance To Humility In One Hour!
Posted by databat at 12:12 AM 0 comments
Labels: Databat's Delusions
Found this little gem whilst exploring the net. Very helpful. Click the title to view the full article on this guy's Blog.
Eyestrain is defined as an eye discomfort that can occur when the eyes tire after a prolonged visual task. Eyestrain can be manifested by headache or discomfort around the eyes.
These symptoms are never present when you wake, never accompanied by ultra-sensitivity to light, but is made worse by visual tasks like reading. Most often you may need a new pair of glasses or contact lenses, or the muscles that align the eyes are strained and needs a break. Health 24
Sitting several hours in front of your computers can be eye-straining. If you work at a computer for more then three hours a day you are likely to have symptoms of eye strain. This can be prevented however with these tips provided by Health 24:
1. Ensure that any close-up work or computer screen is not too close to your eyes. As a general rule, view material from as great a distance as possible, provided it can still be read easily.
2. Take frequent vision breaks (at least every hour) to relax your eye muscles. Try closing your eyes and relaxing for one minute. Other useful exercises may include rolling or blinking your eyes, or closing them tightly for a few seconds.
3. Changing focus is another way to relieve the eye muscles. Every 15 to 30 minutes, look across the room or out of the window at an object at least 6 m away, for at least 20 seconds.
4. You can tire your eyes if you have to look frequently between two objects placed at different focus distances. If more than one close-up focus area is needed (when you are using printed reference material and a computer screen simultaneously), keep the viewed objects at the same distance and as close to each other as possible. This helps to reduce focusing changes.
5. Workstations and lighting should be arranged to avoid direct and reflected glare anywhere in your field of vision. Place the computer or TV screen where there is no glare from windows or lights and keep screens clean and dust-free. Use a glare filter on the screen if lighting cannot be modified.
Posted by databat at 11:52 PM 0 comments
Labels: Databat's Delusions
Welcome to the second issue of Binary Hole. In this edition, we have several tasty articles for your viewing pleasure. First up, we have an interesting article about the mainstream media, and how they enjoy skewing the truth for fun and profit.
Next up, we have a helpful article on how to choose a shell account. It gets down to the nitty gritty. There are many options available, depending on your needs. This one is a must read if your thinking about getting one.
We also have a guide for employers jumping on the bandwagon and hiring hackers to work for them. This guide will hopefully enlighten them on proper care and feeding of their hackers. It might be a good idea to print that one out and drop on someones desk at your company. ;)
Then there is the in depth guide on IRQ's and Interrupt. The first few paragraphs will give you a brief explanation. Further in you'll learn more than you ever wanted to know about them, different types, etc.
Next we have an in depth article about DMA's, what they are, what they do, why, as well as the different speeds. Again, if you just want a simple answer, read the first couple paragraphs. If you're into fine details, read the entire thing.
And of course, we have our usual GPF and /dev/null sections for your viewing pleasure. Laugh until your sides hurt.
Posted by databat at 5:01 AM 0 comments
Labels: Binary Hole - All Articles
So you're thinking of hiring a hacker to help your business manage it's computer infrastructure. You've probably heard about other companies successfully hiring hackers. You also probably have some concerns about this. Won't the hacker break into all the computers, and steal sensitive company information just to profit? What if they do something illegal? There are a lot of misconceptions about hackers. This article attempts to clear those up, as well as help you understand a hacker.
First of all, I'll start by saying this. The media has had a field day with the word hacker. They've hyped it up to sinister creepy proportions. A hacker does not break into computers to steal information, only to profit from it. That is a criminal. Those people are often called crackers. Heads up, new terms. To understand this a bit easier, lets break things up into a top down food chain.
Hackers - These are at the top of our food chain. They are extremely analytical. They like to take things apart to see how they work. They think outside the box. They will look at a problem in many different ways from an unbiased point of view, evaluate many different ways to solve it choose the most secure, most efficient one, then recommend it, and/or implement it. All hackers have the ability to crack. However, hackers also have a sense of ethics. While they are able to point out security flaws, they will not use their knowledge to steal your information to sell to your competitor unless they are criminals, in which case they fall into a different category. Crackers can't hack, although a lot of them like to be called hackers, and enjoy the media attention they receive. Hackers are programmers. Some may be able to code in more programming languages than others. They may have also once programmed, but no longer do this. However, they still retain the same analytical thought process. Most hackers can, and do use a process called extreme programming. This is where they sit down and start writing code without planning it out. Some do light, general programming, then code in the details as they go. We'll get into this later on.
Phreakers - These are the telephone equivalent of hackers. They specialize in exploring the telephone system. There is a gray area in this group where the category of criminal and phreaker begins and ends. These people are extremely knowledgeable in the area of telecommunication. The criminal element uses their knowledge to rip off the telephone companies. The ethical group uses their knowledge to gain more knowledge, point out security flaws in the current systems, and urge those in charge to fix these flaws. These people also possess cracking skills. Some of these are also programmers. A person can be a hacker and a phreaker. (The term phreak is coined from phone and freak) These people may write software related to phreaking, or build electronic devices related to phreaking. These people are extremely electronic savvy. (as in chips and components electronics, low level stuff)
Crackers - These people haven't quite made it to hacker status. Some of them can program, but most of them that do possess programming knowledge fall into the Wares Dudes sub-category. These are the people who can, and do break into computer systems. They do not sell the information for profit, or exploit what they find unless they are criminals, which is a different category all together. These people crack passwords, accounts, serial numbers, etc. The skills required to do this are a subset of what is in the hackers arsenal. Crackers usually don't create new software from scratch, unless it is a utility to aid in the cracking process. The field of vision is narrow.
Wares Dudes - This is a sub-category of a cracker. These people specialize in defeating the serial, and various other copy protection schemes. Many of these people also distribute their cracked software on the net. Many of these people also fit into the criminal category. Script Kiddies - These are the people who are also called wannabe hackers or crackers. They download programs, utilities, scripts, etc. created by the crackers and hackers in an attempt to define themselves as a hacker. Most hackers at one time started out as a script kiddie. You tend to run into them in the hacker channels on IRC. These people tend to be young teens or actual kids, however, some never get past this status as they grow up. A good portion of these people also fit into the criminal group if they stay in this status for a while. This is because they have improper morals, ethics, and lack the knowledge to keep from getting caught.
Criminals - Some hackers, crackers, wares dudes, and script kiddies can fall into this catagory if they do not maintain a sense of ethics and morals. These are the people the media love to do stories about, and label them as hackers. In reality, these people are a very small portion of the hacker community, a small amount of the cracker community, and a larger (but still small) portion of the script kiddie community.
I've only scratched the surface of these different categories. In fact they can be broken down further, or organized a little differently, but the general idea will still hold true. These categories will serve the purposes of this article.
Now as for the hiring process, do you really want to hire a criminal? No one does. Treat that as you normally would when hiring a standard employee. You know, the usual resume, references, criminal background check, etc. Please note, it is possible for a criminal to reform. There have been some hackers, crackers, phreakers, etc. who have been arrested, served their time, released, and obtained good jobs where they use their knowledge ethically now. Some have ever started their own companies. Do not be biased when evaluating a potential employee. Ok, so you've hired a hacker. Wow, they're really weird aren't they? Of course they are. They don't think like your standard employee. They probably even dress strangely. Your hacker will wear what they feel comfortable in, unless you've made it clear up front that there is a certain dress code. If there is a special event, company function, etc. that will take place, feel free to ask your hacker to dress differently. Don't be rude. Just explain politely. They will be more than happy to accommodate you. However, for their everyday work, it is best to let them dress how they are most comfortable, They are more productive that way. If your hacker must interact with customers occasionally, or regularly, sit down and have a chat with them about it. Hackers are reasonable people. Unless you are a rude, demanding boss, you and your hacker will be able to work out a compromise.
My hacker occasionally wanders around, or stares blankly at the wall, *insert weird behavior instead of doing work here*, etc. Are they on drugs? Why are they doing this instead of working? What can I do about this? Ok, stop right there. Your hacker is working. He's thinking. Most likely, you've given your hacker a problem to work on. First your hacker will inspect the problem, gather all of the symptoms, what was recently done before the problem developed, etc After that, your hacker must analyze it all. Do not interrupt your hacker. They aren't on drugs. (Your company does do regular random drug screening right? For every employee? This shouldn't even cross your mind.) Your hacker is either listening to loud music, surfing the net, looking blankly at some object, wandering around aimlessly, etc. If you speak to your hacker while they are in this state, they will most likely ignore you unless you get in their field of vision. This is normal. Your hacker is actually thinking more about the problem, picturing what was done to cause the problem, and mentally applying various solutions to the problem, and evaluating what may go wrong with that solution, and it's probable outcome in fixing the problem. This is one of the things that makes your hacker more productive than a standard employee. Once the problem is fixed, feel free to discuss it with your hacker. He will attempt to explain it to you, but it may come out as an abstract explanation that is difficult to understand. Your hacker isn't trying to mislead you. Most hackers don't even realize what they are doing when they are in this extremely deep state of thought.
My hacker regularly misses breaks, and sometimes skips lunch, or takes breaks and lunches at weird times. This seems to be very anti-social. What's going on? Relax! You've probably given your hacker a problem to work on. Your hacker isn't being anti-social. In fact, most hackers are very social people. However, once a hacker gets started on something, they want to keep working on it until it is finished. This is normal behavior. Now I'm not telling you to let your hacker starve either. If you are truly concerned, when you go out to lunch, ask your hacker if they would like something to eat. Most will happily fork over some cash, and cover your gas for this service. You may also want to offer to let them eat at their desk. Don't worry about crumbs and such getting into your computers. Hackers detest such crud in their computers at home. While at work, they tend to view the equipment they are working on as "theirs" as well. It's a personal pride thing. They will take care of your equipment as if it were theirs.
I think I've upset my hacker, or I'm worried about upsetting my hacker. What do I do? Hackers are very different from regular employees. The things that motivate them are very different. Did you give your hacker a simple task to perform, like mundane data entry, or sweeping the floor? This is a good way to tick off your hacker. While you may have been choosing the closest person nearby, your hacker probably viewed it as an insult to their intelligence. They will get extremely bored while performing these tasks. Try not to give your hacker these simple tasks very often, or they will think you are mad at them. Instead, give them challenging things to do. They tend to view this as a reward instead of work. To them, their work is like play time. You can also reward your hacker with a pay raise. However, this can't always be done, depending on company policy, and the financial situation of the company. You can also reward your hacker with other perks, such as giving them old computer equipment that the company no longer uses buying them computer related books, caffeinated beverages, hot pockets, *insert hackers favorite snack food here*. It is generally a bad idea to promote your hacker to a non-technical managerial position. Hackers love hands on work. They will hate you if you force them to manage people instead of working on equipment. However, depending on the hacker, managing people while working on software and equipment is acceptable. That kind of promotion should be discussed with your hacker.
How can I make my hacker more productive? A good start would be to stock your hackers favorite caffeinated beverage in the break room. If cost is an issue, put a vending machine in there. Your hacker will be more than happy to pay a fair price. Most hackers consume highly caffeinated beverages regularly. A few go too far and consume too much however. If that becomes a problem, talk to your hacker about it. Most hackers only go through that issue once, and never repeat the mistake of consuming too much. (it tends to do bad things to the stomach) Hot Pockets, and various other microwaveable snack foods are also another good idea. (see above regarding missing breaks and lunches) Hackers tend to keep weird eating habits, usually due to working on a problem. Allow your hacker to listen to music with headphones. This helps them block out outside distractions. Allow your hacker to decorate their work area (within reason). A hacker is more productive when they feel comfortable. The same thing applies to the clothing issue. Let them be comfortable. You may also want to offer your hacker the option of telecommuting. Most hackers have a certain time of day, night, or somewhere in between where they are more productive. For this reason, hackers are better as being paid as salaried employees. Your hacker may work for 24 hours straight before sleeping. This happens when your hacker gets in their "zone", their mind is on the right track, and things get done very quickly. Having to stop working at a certain time wrecks this process, especially if your hacker usually gets into their zone at the end of their work day.
My hacker speaks to me, and everyone else in management as equals! They don't respect me! What can I do? Typically, the hacker isn't disrespecting you. In fact, they don't see management as above them. They view management as performing a different job within the company. If your hacker speaks to you as an equal, this is generally a compliment from your hacker. If you feel that your hacker doesn't respect you, it is most likely because you haven't shown your hacker any respect. A hackers respect must be earned. It isn't automatically given because of your title. You must get past this if you wish to have a productive business relationship with your hacker. If you feel that your hacker talks down to you, it is most likely because you are talking down to your hacker. This is an easy way to upset your hacker. They do not like to be treated like children. They will also quit because of this. The more stubborn ones will refuse to quit, and instead wait and see how long you'll continue disrespecting them before you either quit or admit you are wrong and change your behavior. Your hacker isn't trying to be your boss. They just want the space to do their job, and to feel that they are respected as a valued employee.
My hacker looks like crap! Are they going to drop dead on me? This is a valid concern. The number one reason they look like this the next day is probably because they have been working on a personal project at home all night, and didn't get any sleep. The fact that they showed up for work is proof enough that they aren't sick. They are just tired. They may also have the standard issues going on in life that your other employees are having. Your hacker will most likely discuss what's going on with you if you politely ask them in a private conversation. Your hacker may also have a sore back, wrist, etc. from working. It is a good idea to get your hacker a comfortable chair if they are sitting at a terminal most of the day. There are also wrist supports that can be purchased that help prevent repetitive stress medical issues. These would be a wise investment for all of your employees, as it will save in health insurance, and missed time at work. If your hacker calls in sick, they are really sick. Remember, your hacker loves their job. Missing work is like missing a vacation. Accusing them of otherwise will only upset your hacker.
I'm afraid my hacker will quit. What do I do? Investigate why they may want to quit. Is it a pay issue? Did they get a better job offer? A better job offer for a hacker may not just include a pay raise. It may also be a chance for them to work on equipment they have always wanted to work on, even if it is at a lower pay. Unless your company plans to upgrade, or offer your hacker enough money to stay, there isn't much you can do about this except to hire another hacker. While you give your hacker technical things to work on, your hacker may be leaving to accept their dream job. For hackers, these are always technical positions, but usually a hacker has one specific area they really enjoy with a passion. In this situation, there is nothing you can do to convince your hacker to stay. If you have treated your hacker fairly, they will leave a notice, an attempt to leave on good terms. Do not attempt to bully your hacker into staying. This is the number one thing that causes ethical hackers to turn criminal. They do it out of self defense. No it isn't right. But it isn't right for you to treat your hacker like crap because they are leaving either. In fact, your hacker may come to the end of his analysis thought process, and either walk out, or sue, depending on how much bullying you are doing. It would be more productive to either have your hacker train another employ on what to do until you hire another hacker, or hire another hacker and have your hacker show them what needs to be done.
In conclusion, depending on the technical aspects of your company, hiring a hacker may be very productive. O hire two so they will have someone to talk to, and relate to. Hackers just have a different set of guidelines to follow when dealing with them. These guidelines aren't set in stone however. Hackers are also people. As such, all people are different, therefore, all hackers are different. Act accordingly. I hope this article has cleared up a few misconceptions about hackers in general. There are also probably many out there that would disagree with me, especially with the categories I set forth above. Your mileage may vary. I welcome anyone to submit an article on the subject with their point of view on the subject. This article reflects my point of view based on personal experiences.
-=databat=-
Posted by databat at 5:00 AM 0 comments
Labels: Binary Hole - All Articles
Most people today rely on television for their news. Most have either satellite, or cable. Fewer and fewer are using broadcast T.V. However, everything that is on broadcast can be found on cable and satellite. For the purposes of this article, I'm grouping all television sources together.
How many times have you watched the evening news, and saw something that just made your blood boil? Did your opinion match the message they news show was making on T.V.? Welcome to skewed news. We live in sad times where most of the news programs hype and slant their stories to a. improve ratings, and b. to agree with those who are paying the bills, and c. to agree with the big bosses, who are most likely the same as b.
Currently I use standard broadcast T.V. at home. However, I have been (un) privileged enough to watch cable news shows at a friends house, or satellite. I repeatedly see the same trends over and over. Most of the news programs are slanted towards the left. That isn't surprising once you research who owns those stations, networks, and who pays the bills. Now don't get me wrong, I'm not here to bash anyone. I would just like to point out that neutral journalism is difficult to achieve, and that we should all keep this in mind when watching the news. Some political slant in news stories is expected, as long as those reporting the news make it clear as to what is hard fact, and what is opinion.
The second thing that I constantly notice in the news is the proverbial beating a dead horse. By this I am referring to something that happens, that might not really be that Earth shattering, yet it ends up on every channel, interrupting the rest of the crap on T.V. (I'll get into the lack of decent programming a bit later)
Third, depending on who holds political office, the Government either gets praised, or beaten like a little kid with extra lunch money. Some of the following examples illustrates one, several, or all of these points.
My first example is when Pope John Paul II died, every media outlet made the story their top priority. For weeks afterward, all you heard was the Pope this, and the Pope that. Now I'm not knocking the Pope, or his importance to the Catholic religion. He is the leader of the Catholic church. But the man died! Burry him peacefully. Respect the family's wishes. Don't put the body on display for weeks! Don't turn it into a parade! If you want to see someone, see them while they are alive. Give them flowers while they are alive, and able to enjoy them. Honor and respect people while they are here to enjoy it. This is just a minor example. Keep reading.
My second example is about the events that took place before, during, and after September 11th in America. To truly understand this, we must look at America's attitude, and what we were all taught, and what truly happened. America was always taught to cooperate with hijackers. Before 911, most hijackers just wanted money, to escape, etc. They really didn't tend to harm people. We were all taught to cooperate to live. The hijackers had box cutters for crying out loud! Do you know how easy it is to disarm someone with a box cutter? Sure you may get cut. But grab someone's carry on luggage and beat the crap out of em. Poke the eyes, kick the groin. They'll drop that box cutter. The reason the hijackers were able to take over a plane was because American's let it happen. (I have a right to say this because I am an American) We were taught to let it happen. Now here's what all of the security advocates neglect to mention. Back then, box cutters were allowed on planes. The hijackers had the proper "fake" id. Research the net. Fake ID's aren't difficult to get. Back then airport security was doing it's job. However, after all of those people were killed on 911, the media took the story and had a field day with it. The media instilled fear into everyone. Draconian laws were passed by congress. Airport security was taken over by the government. This was done to appease the masses that cried out for the government to take care of them. Yes, some administrative jobs within the government were created. But a lot of jobs were lost when the private security companies passed the torch over to the government. A lot of the private security personnel was even hired by the government. They were trained according to the new government regulations regarding airport security. So as far as jobs go, it pretty much balanced out. As far as airport security goes, it seemed a lot like fixing something that wasn't really broken in the first place. I worked for TSA for a short time. I have great respect for them. It's a stressful job. (left that job due to ulcers btw) Not only do you have to keep up with the latest regulations from D.C. on how you are suppose to do your job, but you also have to keep a close eye on everything that is going on around you. Add to that the general public who cried out for the government to keep them safe, who also hate you because you must invade their privacy and search their belongings thoroughly. You tend to hear the typical, "Do I look like a terrorist?" While I worked there, I had to be polite in my responses. But now, this is my message to the public.
It was you (the public) who gave in to media hysteria. It was you who cried out to the government to keep you safe. It was you who agreed to give up your rights while flying in order to keep that safety. It is you who are paying for them to do their job. You are the reason they are there. Either get your friends together and have congress reverse the decision, or shut up and get over it!
Even the media has taken to this double standard. While working there, I had to come home every day and watch the "latest news" about TSA. What they're doing wrong, etc. Most of the regulations as to how they do their job is classified. Those regulations sometimes change weekly, or daily, depending on threat level, and the latest crap going through congress. Now how is the media, who is neither employed by TSA, or a member of congress, the ones to say whether or not they are doing their jobs properly? As of writing this article, I haven't worked for TSA in over two and a half years. No I won't discuss the policies that I had to follow either. I don't remember the NDA I had to sign, but I'm sure it's over by now. Those regs have probably already been changed. It would accomplish nothing, except to give fuel for the media zealots. The media instilled the fear into the public, and put it into everyone's head that the government should keep them safe. The public demanded that the government do this. The government did something about it. Now the media scrutinizes the government for what the media helped to create. The people need to wake up and read the Constitution of the United States, and the Bill of Rights. It was created to protect the people from the government. So why are the people rolling over and giving the government so much power? More importantly, don't the people that work for the government (the people that in effect, are our government) realize that these laws also apply to them?
Now you're probably thinking I'm holding a double standard by writing this article against the television media. Not so. They have a right to report and say what they wish. However, the public has a responsibility to research what is reported, to find the real story behind it, and form opinions for themselves instead of being lead by sheep.
"Amendment I : Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances."
This amendment gives the television media the right to say whatever they want. It also gives me the right to write this article speaking out against the television media. It also gives me the right to write to congress, various government officials, etc. addressing my issues with the laws that have been, or are about to be passed. Sadly however, when someone's first amendment rights are violated, most American's keep quiet, and let it happen. STOP!!! Each time you give up one of your rights, you are telling them it is ok to further violate your rights. When will the line be drawn? When we live in a dictatorship? Again, I blame the people for not fighting some of the draconian laws that exist today limiting free speech. Again I blame the people for not fighting when their rights are violated. Take your case through the system, and appeal if needed. Take it up to the supreme court. That's why it exists!
"Amendment II: A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed."
This does not specifically give us the right to carry a gun anywhere we wish. However, it does give us the right to arm ourselves with a weapon to defend ourselves, and for the states to form their own private militia (army) to protect that state against the government and/or foreign invaders should the need arise. I bring up this amendment specifically in relation to the plane hijackings in 911. While at the time you were not allowed to carry a firearm on a plane, (never a good idea to shoot a hole in the plane your flying in) it gives you the right to use any other tool available to defend yourself. The passengers on the planes that crashed into the World Trade Center did not exercise this right. Instead they did what they were always taught and cooperated. Not only did they die in the crash, but by their inaction, many other lives were lost. The plane that crashed over Pennsylvania, they exercised this right. Perhaps a bit too late to save their pilot, but they did exercise it. Their plane crashed and they died. However, that plane never reached it's target, and lives were saved. For the people on that plane, I humbly salute them, and hope that if I am ever faced with that choice, that I will have enough courage to exercise that right. They were true Americans.
"Amendment IV: The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized."
Remember the Patriot Act that was hastily passed? It has been the center of controversy in many forums. I do not completely agree with this act. However, it has it's merits. Have you ever taken time to actually read it? Most of it actually attempts to clarify other laws. In the rare cases where it was used wrongfully, the system worked, and the courts sorted it out. However, it does open the door for the government to further encroach upon our freedoms later on. Read carefully, and always stay informed. Any new law is always tested to it's limit. As of the time of writing, the text of the US PATRIOT ACT can be found here.
It's a long read so be prepared. The media has also blown this one out of proportion, as well as spreading FUD (Fear, Uncertainty, and Doubt). (Fear, Uncertainty, and Doubt) This act is up for review soon, and with the nudging of your congressperson, the fuzzy parts will be sorted. (hint hint, write congress, let them know how you feel) My biggest gripe with it, is that it is extremely wordy, and difficult to understand. This in turn makes it difficult to interpret, which leads to people spreading FUD. It also makes great fuel for anti-government groups. (in my opinion, the DMCA is a bigger threat than the PATRIOT ACT, esp. since we already had the Computer Fraud and Abuse Act of 1986, but I'll save that one for a future article) Check your local library, internet, etc. and please read and understand your constitutional rights. I've spent far too much time on this paragraph already and strayed a bit off topic. Let's move on.
Me personally, I'm not against government. I'm against oppressive government however. Our current system works. It's not without it's speed bumps. It takes time for new laws to be tested in court, revised, and eventually sorted out. The T.V. media outlets often take this process and hype it to get viewers to watch their show, so that they can in turn get more paid advertisements.
Another good example of media hype would be the war in IRAQ. For a while all I ever heard about was when a soldier would get killed, and I still hear about it. However, when you research the total number of American casualties in the IRAQ war versus the number of deaths in peace time training accidents, health problems, etc. There's not much of a difference. Yet you hear about all of our brave men and women getting killed. Please... In every war there are casualties. Me personally, I'd rather die fighting for what I believe in than in a freak training accident. The media needs a clue. It would be nice sometime to turn on the T.V. and see a story about the botanical gardens, or the latest and greatest *insert interesting invention here*. Ya know, news you could learn something from instead of listening to your neighbors cringe in fear, stockpile weapons, food, and water in their bomb shelters, etc. Or how about reporting on the SCO vs. *insert long list here* case. Most likely, they'd twist the facts on all of it. Ya know, a cannibalistic flower in the gardens, new invention kills little old lady then eats inventor, SCO poised to take over the world. *sigh*
Perhaps when we all turn off the T.V., go outside and do something enjoyable, get rid of the pasty deathlike skin tones, and the T.V. networks loose enough money to where they have to start listening to their viewers again. But always remember, you still have the freedom of press. Start your own magazine, website, or if you have enough funding, television station. Participate in various forums to voice your concerns. Even if you don't agree with everything I've mentioned in this article, please voice your opinions. The worst thing you can do is to do nothing. Don't willingly give up your rights! Don't willingly give up your freedom to think for yourself! Don't be lead by others! Don't even believe everything in this article! Research it for yourself!
-=databat=-
Posted by databat at 5:00 AM 0 comments
Labels: Binary Hole - All Articles
If something you've written or done has made it here, then gratz! You're a knob head lamer who doesn't know a dough nut hole from a hole in the ground. Doesn't it make you feel all warm and fuzzy that we thought of you!?!? Some of these responses to the lame e-mails may be real, some may be dramatizations. Your mileage may vary.
Posted by databat at 5:00 AM 0 comments
Labels: /dev/null, Binary Hole - All Articles
If you tinker with computers long enough, you will eventually hear about IRQ's and interrupts. Yes, more acronyms. But what the heck are they? Well, most likely if your an old schooler from way back in the DOS days, when your parents had to walk five miles to school and back in the snow uphill both ways (yea yea lame old age joke), you probably have an idea of what they do, or at least know they are of some importance. This article will attempt to demystify them.
The best place to begin our story is at the beginning, in the early days of PC's. I'm talking real early, when PC's had Intel 8085, 8086, and 8088 processors. These machines also had Programmable Interrupt Controllers. (PIC's) These handy dandy chips acted as a traffic cop of sorts. They handled input from the various other hardware devices sitting on the system bus, and decided who got the processors attention and when. These original PIC's were made by Intel, dubbed the 8259 family. There were several types of these made, but I won't go into the various differences of them, as they are minor. This chip acts as a multi-plexer.It combines multiple hardware interrupt inputs into a single interrupt output to interrupt one device. The device that gets interrupted in your computer is the processor. (Today these chips are built in as part of the Southbridge chipset on x86 compatible motherboards.) These chips were created to take care of a performance bottleneck in early computing design.
Before these chips were created, computer processors had to poll each hardware device to see if it needed something processed. This resulted in a lot of wasted processing power. PIC's allow the processor to continue number crunching until a hardware interrupt is encountered. The processor will then take care of the request, then go about it's business. The main connectors on an 8259 chip consisted of 8 interrupt input request lines labeled IRQ0 through IRQ7, an interrupt request output line labeled INTR, an interrupt acknowledgment line labeled INTA, and D0 through D7 for communicating the interrupt level or vector offset. (An interrupt vector is the memory address of an interrupt handler, or an index into an array called an interrupt vector table or dispatch table. Interrupt vector tables contain the memory addresses of interrupt handlers. When an interrupt is generated, the processor saves its execution state via a context switch, and begins execution of the interrupt handler at the interrupt vector.) It also had CAS0 through CAS2 for cascading between two chips. (connecting multiple 8259's together to obtain more interrupts) Up to eight slave 8259s may be cascaded to a master 8259 to provide up to 64 IRQs. They are cascaded by connecting the INT line of one slave 8259 to the IRQ line of one master 8259.
A register is a small area of static RAM that the chip is able to access very quickly, as well as manipulate. They can come in different sizes, from 8-bit, 16-bit, 32-bit, 64-bit, and so on. The 8259A has three 8-bit registers that determine its behavior: the IMR (Interrupt Mask Register), the ISR (In-Service Register), and the IRR (Interrupt Request Register). The bits of these registers are numbered 0 through 7, where 0 is the least significant and 7 is the most significant bit. Each bit of each of these registers corresponds to the respective interrupt pin on the PIC. That is, bit 7 corresponds to IRQ 7, bit 6 corresponds to IRQ 6, and so on.
The IMR. This register lets the programmer disable or "mask" individual interrupts so that the PIC doesn't interrupt the processor when the corresponding interrupt is signaled. For an interrupt to be disabled, its corresponding bit in the IMR must be 1. To be enabled, its bit must be 0. Interrupts can be enabled or disabled by the programmer by reading the IMR, setting or clearing the appropriate bits, then writing the new value back to the IMR.
The IRR. This register indicates when an interrupt has been signaled by a device. As soon as a device signals an interrupt, the corresponding bit in the IRR is set to a 1. This register can only be modified by the PIC and its contents usually aren't important to the programmer. It can be used to tell which interrupts are waiting to be serviced.
The ISR. This register indicates which interrupts are currently being serviced (i.e., which ISRs have begun execution and have not yet finished). A 1 bit indicates that the corresponding ISR is currently in-service. Several interrupts can be in-service at the same time because of interrupt nesting. The PIC uses this register to determine the highest priority of the interrupts currently being serviced. With this information, the PIC will only interrupt the processor if the highest priority set bit in the IRR has a higher priority than the highest priority set bit in the ISR. In other words, the PIC will never interrupt an in-service interrupt in order to service another interrupt of the same or lower priority. Before an ISR finishes executing, it must send to the PIC the end of interrupt command (EOI) so that the PIC knows that it can safely clear the highest priority bit in the ISR and signal any other pending interrupts. Be careful not to confuse "In-Service Register" with "Interrupt Service Routine". Both of these use the "ISR" acronym.
The first PC's only contained one PIC, but later on two were cascaded together to allow more device to be attached to the system. The following chart lists the IRQ's and what they are normally used for.
IRQs 0 to 7 are managed by one Intel 8259 PIC, and IRQs 8 to 15 by a second Intel 8259 PIC. The first PIC, the master, is the only one that directly signals the CPU. The second PIC, the slave, instead signals to the master on its IRQ2 line, and the master passes the signal on. Because of this, there are only 15 interrupt request lines available for hardware. Lower IRQ's have a higher priority. From looking at the list, you can definitely see why. The system timer is the most important. It is essentially the heartbeat of the system. Next is the keyboard. Generally, if everything is connected properly, and your keyboard caps lock key won't even change the state of it's status L.E.D. then your pretty much screwed, and will have to reboot.
Now IRQ 2 presents an interesting case. It's cascaded. This means everything on the slave PIC gets priority over everything else below it on the master PIC. So next in the pecking order we have the real time clock which keeps your date and time correct. Next up we have the ACPI (Advanced Configuration Power Interface) which controls various power saving features for the system, or the ISA MPU-401 which is a MIDI interface. (allows you to connect musical instruments to your computer) It continues down the list until IRQ 15, then goes back to IRQ3 and continues to IRQ 7. IRQ's 0, 1, 2, and 13 can't be changed. However, the other ones can. Usually its easier to use the settings listed in the chart, as these have become the standard.
When DOS and the early days of Windows, (pre-Windows 95), when you bought an add in card for your computer, you had to configure the card to use a free IRQ. This was typically done by placing a jumper on the card onto the appropriate connectors. If two cards in your system were not designed to share an IRQ and you attempted to do so, the result would usually be a system crash, or possibly not even boot at all.
Interrupts may be implemented in hardware as a distinct system with control lines, or they may be integrated into the memory subsystem. If implemented in hardware, a PIC, as we discussed earlier, or an APIC (Advanced Programmable Interrupt controller) may be used. (we'll get to APIC's in a bit) If implemented as part of the memory controller, interrupts are mapped into the system's memory address space. These interrupts can also be divided further as follows:
Processors also have an internal interrupt mask that will allow it to ignore all hardware interrupts while it is set. This is typically used in programs that require specific timing and the fastest execution possible for the program. However, misuse of this mask can slow down the system.
A level-triggered interrupt is a class of interrupts where the presence of an unserviced interrupt is indicated by a high level (1), or low level (0), of the interrupt request line. A device that wants to signal an interrupt changes the line to its active level, and then holds it at that level until serviced. It stops asserting the line when the CPU commands it to or otherwise handles the condition that caused it to signal the interrupt. Normally, the processor samples the interrupt input at predefined times during each bus cycle. If the interrupt isn't active when the processor samples it, the CPU doesn't see it. This helps to prevent erroneous interrupts that may be caused by line noise. (electromagnetic interference) Multiple devices may share a level-triggered interrupt line if they are designed to. The interrupt line must have a pull-down or pull-up resistor so that when not active, it settles to its inactive state. Devices actively assert the line to indicate an outstanding interrupt, but let the line float (do not actively drive it) when not signaling an interrupt. The line is then in its asserted state when any (one or more than one) of the sharing devices is signaling an outstanding interrupt.
This class of interrupts is favored by some because of a convenient behavior when the line is shared. When the interrupt line is activated, the CPU must search through the devices sharing it until the one who activated it is detected. After servicing that one, the CPU may recheck the interrupt line status to see if any other devices need servicing. If the line is no longer asserted, then the CPU avoids the need to check all the remaining devices on the line. Where some devices interrupt much more than others, or where some devices are particularly expensive to check for interrupt status, a careful ordering of device checks brings some efficiency gain.
The protocol of a level-triggered interrupt goes like this:
This is good for sharing, because it confirms that the operating system handled the interrupting device. The algorithm is:
If multiple devices interrupt, the operating system will find the first one, run its ISR, and then ACK the interrupt. Then the operating system will immediately take another interrupt on that vector. At this point, the operating system runs through all the ISRs until it finds the second device, runs its ISR, and ACKs the interrupt again.
There are some serious problems with sharing level-triggered interrupts. As long as any device on the line is requesting service, the line remains active, so it is not possible to detect a change in the status of any other device. Delaying the servicing of a low-priority device is not an option, because this would prevent detection of service requests from higher-priority devices. If there is a device on the line that the CPU does not know how to service, then any interrupt from that device permanently blocks all interrupts from the other devices.
For example, lets say we're a suit, working for a fortune 500 company. We have our own top of the line laptop, and do a lot of work with it. We have docking stations both at home, and at work. We've got a printer, network card, DVD+R drive, maybe a USB camera, throw in a gamepad for the docking station at home, PDA docking station connected as well, and oh maybe a video capture device, scanner, etc. connected to the docking station. Lets say we have twelve devices all chained on one vector, on this docked laptop. Every time the operating system takes an interrupt, the operating system must run as many as twelve ISRs before it begins to handle the condition that caused the interrupt. I'm sure you can see where this is going.
(Just in case you don't remember, an ISR is an Interrupt Service Routine. Basically it's a bit of code that does what it's suppose to do for a particular interrupt. For all you die hard programmers out there, think of it as a function call for hardware.)
Even assuming that every device in the chain is well designed and can determine within a few I/O cycles whether it is generating an interrupt, a huge interrupt latency (delay) occurs, as each interrupt causes the operating system to touch up to twelve different pieces of hardware to find the correct one.
Unfortunately, the reality of the modern PC market is that many devices are poorly designed and misbehave. Most hardware is designed with the mindset that the ISR will handle all the work of the interrupt. In other words, the hardware designers are passing the buck to the programmers writing the device driver. So now you have a lazy engineer ignoring the need for good hardware synchronization in their chip designs. This forces the driver programmer to write larger, slower code to compensate. The result is device drivers that do most of their real work in their ISR. This exponentially lengthens the time the OS spends running the ISR chain, causing it to run for relatively long periods of time with interrupts off and no threads or deferred procedure calls (DPCs). Imagine trying to do real-time video manipulation when every interrupt causes a 500us delay in processing. (*click* *go make coffee* *click* *order out for pizza* *click* *go take a nap*...)
The previous examples assume that all device drivers are well behaved. However, if even one device driver returns FALSE from its ISR when its device is actually interrupting, then a system will hang as a result. The ACK causes the interrupt controller to generate another interrupt. The operating system runs the ISR chain forever.
APICs provide more interrupt resources, thus greatly reducing, if not removing, the need to share interrupts among hardware devices. The original PCI standard mandated shareable level-triggered interrupts. The rationale for this was the efficiency gain discussed above. (Newer versions of PCI allow, and PCI Express requires, the use of message-signaled interrupts.)
An edge-triggered interrupt is a class of interrupts that are signaled by a level transition on the interrupt line, either a falling edge (1 to 0) or (usually) a rising edge (0 to 1). A device that wants to signal an interrupt drives a pulse onto the line, then returns the line to its normal state. If the pulse is too short to be detect by polled I/O, then special hardware may be required to detect the edge. Multiple devices can share an edge-triggered interrupt line if they are designed to. The interrupt line must have a pull-down or pull-up resistor so that when not actively driven, it settles to one particular state. Devices signal an interrupt by briefly driving the line to its non-default state, and let the line float (do not actively drive it) when not signaling an interrupt. The line then carries all the pulses created by all the devices. However, interrupt pulses from different devices may merge if they occur too close to each other. To avoid losing interrupts the CPU must trigger on the trailing edge of the pulse (the rising edge if the line is pulled up and driven low).
After detecting an interrupt the CPU must check all the devices for service requirements. Edge-triggered interrupts don't suffer the problems that level-triggered interrupts have with sharing. Servicing a low-priority device can be delayed, and interrupts will continue to be received from the high-priority devices that are being serviced. If there's a device that the CPU doesn't know how to service, it may cause a spurious interrupt, or even periodic spurious interrupts, but it doesn't interfere with the interrupt signaling of the other devices.
With any interrupt controller, an edge-triggered interrupt is a one-time event. There isn't any feedback to the OS. The OS never really knows when it has handled the situation that caused the interrupt. It can only know that an event happened recently. The only rational response to an edge-triggered interrupt is to run all the Interrupt Service Routines (ISRs) associated with that vector once, with the hope that this will resolve it. (kinda like killing a mouse with an elephant gun) This situation is especially sketchy when dealing with hardware that doesn't give any real indication of why it interrupted. This is a common occurrence among today's edge-triggering devices. The result is that the OS can miss interrupts delivered in the interval between when an interrupt is first taken and when it is acknowledged. With an 8259 PIC, the situation is even worse. The 8259 is inherently unreliable, particularly when coupled with an actual ISA bus. The old ISA bus uses edge-triggered interrupts, but doesn't mandate that devices be able to share them. Many older devices assume that they have exclusive use of their interrupt line, making it electrically unsafe to share them. The operating system software will see a number of spurious interrupts, some of which show up on different vectors than the original signal. However, ISA motherboards include pull-up resistors on the IRQ lines, so well-behaved devices share ISA interrupts just fine. When dealing with this older hardware, it's usually safer not to assume anything though. Always check your documentation.
Some systems use a hybrid of level-triggered and edge-triggered signaling. The hardware looks for an edge and verifies that the interrupt signal stays active for a certain period of time. A common hybrid interrupt is the NMI (non-maskable interrupt) input. Because NMIs generally signal major, or even catastrophic system events, a good implementation of this signal tries to ensure that the interrupt is valid by verifying that it remains active for a period of time. This two step approach helps to prevent false interrupts from screwing up the system. There are also some BIOS implementations that allow you to configure which method you wish to use as well as using the combined method.
A message-signaled interrupt doesn't use a physical interrupt line. Instead, a device signals its request for service by sending a short message over some communications medium, typically a bus. The message might be of a type reserved for interrupts, or it might be of some pre-existing type such as a memory write. Message-signaled interrupts behave very much like edge-triggered interrupts. The interrupt is a momentary signal instead of a continuous condition. Interrupt handling software treats the two in almost the same manner. Usually, multiple pending message signaled interrupts with the same message (the same virtual interrupt line) are allowed to merge, just as closely spaced edge-triggered interrupts can merge. Message-signaled interrupt vectors can share the same communications medium (the same bus) without any extra effort. The identity of the interrupt is indicated by a pattern of data bits. It doesn't require a separate physical conductor. More separate interrupts can be handled, reducing the need for sharing. Interrupt messages can also be passed over a serial bus, not requiring any additional lines. PCI Express is a serial computer bus, and uses message-signaled interrupts exclusively.
Regardless of the triggering style, multiple devices sharing an interrupt line act as spurious interrupt sources to each other. With many devices on one line, the workload in servicing interrupts grows as the square of the number of devices. It's preferred to spread devices evenly across the available interrupt lines. Shortage of interrupt lines is a problem in older system designs where the interrupt lines are actual physical conductors. Message-signaled interrupts, where the interrupt line is virtual, are favored in new system architectures (such as PCI Express) and go a long way towards fixing this problem. Some devices with poorly designed programming interfaces provide no way to determine if they have requested service. They may lock up or otherwise misbehave if serviced when they don't want it. Such devices can't tolerate spurious interrupts, and are useless when it comes to interrupt sharing. ISA cards are usually cheaply designed and constructed, and are notorious for this problem. Luckily, these are rarer today thanks to cheaper hardware logic, and newer specs that mandate interrupt sharing. On PIC-based systems, sharing interrupts is the only way to allow all or even most of the devices in the system to function. OS vendors have provided a lot of information to help hardware vendors design hardware and drivers that can successfully share interrupts. However, interrupt sharing cannot be considered a sufficient solution to the interrupt problem on todays PIC-based PCs. Interrupt sharing has been required on many PC platforms, but it is viewed as a necessary evil. The real solution to interrupt problems is to move to APIC-based systems.
The problem with the lack of IRQs is not solved even when the OS can attach all the PCI devices in a given system to one or just a few IRQs so that IRQs remain to serve other devices. A quick review of driver development newsgroups, for example, makes it clear that a lot of hardware designs are very sensitive to interrupt latency. To work around this sensitivity, hardware vendors often want to know how to make ure their device never shares an interrupt. For these devices, running on an APIC system is the only option.
These problems of interrupt latency aren't the only issues in today's machines that have to be addressed before real-time behavior can be convincingly achieved. But, these problems are on the critical path.
Other architectural problems can arise when you cause PCI devices to share interrupts. For example, a machine contains a sound device and a USB controller. Lets say both of these are connected to the same IRQ. The BIOS might try to use both devices during boot up. The BIOS might try to access the sound device in order to play a welcome sound on startup. The BIOS might also try to access the USB controller on startup to determine whether the system uses a USB keyboard or mouse.
As of PCI 2.0, the PCI specification doesn't provide a generic way to stop a device from interrupting. The interrupt disable bit in PCI 2.3 addresses this problem, but won't impact the older machines already out there. (In contrast, PCI 2.0 does provide a way to stop a device from decoding I/O and memory resources, and stop bus-master transactions, by clearing the Command register.) This means that the BIOS could leave both the USB controller and the sound device in an interrupting state. (This also is quite common.)
The operating system has to load either the USB driver or the sound driver first. (Some might argue that these could be simultaneously loaded, but this is not possible if the system uses USB 2.0 and you are booting off of a USB-connected disk. And, it is certainly not possible to retrofit every existing Microsoft operating system to force drivers to enable interrupts simultaneously.) If you load USB before sound, you enable the IRQ with a sound interrupt pending. This causes an interrupt to be delivered, but with no ISR for the sound device in the ISR chain. The OS calls the USB ISR and it returns with a value indicating that the interrupt was not caused by USB. The OS then acknowledges the interrupt. However, because the interrupt is level-triggered, it's immediately reasserted and the OS jumps right back into the interrupt-handling code. The result is that the machine is hung, endlessly dismissing interrupts (in other words, the machine is hung in an interrupt storm). Similar cases can occur when a machine is brought out of a suspended or hibernating state.
So far, the discussion assumes that everything is working perfectly, that all hardware is perfectly well behaved, and that all device drivers are perfectly written. However, this is not always the case.
Consider a case where driver A is poorly written and always indicates that its ISR has just handled an interrupt. Driver A operates a device that uses level-triggered interrupts. (This is true for all new devices, because everything either is PCI or looks like PCI these days.) Imagine also that driver B exists with an ISR that is farther down the chain. If the device associated with driver B interrupts, the OS will never be able to call its ISR, because driver A will always claim the interrupt. In this case, the machine also hangs because of an interrupt storm. However, if it is able to get its own IRQ, driver A functions without a problem.
Here's another example. Two devices, a modem, and a CardBus controller share an IRQ. The machine is a laptop, and the user is not making any phone calls at the moment. The OS puts the modem in the D3 (powered-off) state. The driver for the modem unregisters its ISR and powers off its hardware. But, because of either a hardware or a software bug, the modem delivers an interrupt if the phone rings. If the modem had its own IRQ, the operating system would mask that IRQ when the driver unregistered its ISR. However, because these two devices share an IRQ, the operating system must leave the IRQ unmasked so the CardBus controller can function. If the phone rings at this time, an interrupt is delivered on the unmasked IRQ. There is no ISR registered for the modem hardware, so only the CardBus ISR is called, after which the operating system acknowledges the interrupt. Because the interrupt is still pending, the result is another interrupt storm.
That example is actually very common, because many hardware designers confuse the concept of an "interrupt" with that of a "wake signal", or PME. Hardware designers often wrong in thinking that a device interrupt should be triggered to cause a device to wake up. These scenarios are avoided by putting an APIC in the system. (we'll get to APIC's in a moment.) This allows most, or all devices to get their own IRQ.
Also worth noting, the native interrupt mechanism for PCI Express is MSI (message-signaled interrupts). This is also true for PCI-X. You cannot use MSI without APIC.
Ok, so now you have a good idea of what an interrupt is, what it does, and the different types. But what the heck is it used for!?!? Well, typical interrupt uses include the following:
A classic system timer interrupt will periodically interrupt from a counter or the power-line. The interrupt handler counts the interrupts to keep time. The timer interrupt may also be used by the OS's task scheduler to reschedule the priorities of running processes. Counters are very popular, but some older computers did use the power line frequency instead. This was because power companies in most Western countries control the power-line frequency with an atomic clock. In the U.S.A. the frequency is 60 Hz. A disk interrupt signals the completion of a data transfer from or to the disk drive. This interrupt lets a program know when to continue or wait while reading or writing data to the drive. A power-off interrupt predicts or requests a loss of power. It allows the computer equipment to perform an orderly shutdown. In newer computer, this is sometimes called intelligent off, where the power button effectively clicks the start button, shutdown, turn power off selections on a Windows 9x and higher computer. (Why you have to click start to stop your computer still boggles my mind to this day...) Interrupts are also used in type ahead features for buffering events like keystrokes. I haven't used this type of software on a desktop computer, but if you have a newer cell phone you most likely have used this. Though now it's given flashy titles like predictive text, etc.
Now that we've covered the basics of interrupts, we can move on to the APIC, or the Advanced Programmable Interface Controller. The Intel APIC Architecture is a system of APICs designed by Intel for use in Symmetric Multi-Processor (SMP) computer systems. It was originally implemented by the Intel 82093AA and 82489DX, and is found in most x86 SMP motherboards. It's one of several attempts to solve interrupt routing efficiency issues in multiprocessor computer systems. There are two components in the Intel APIC system, the Local APIC (LAPIC) and the I/O APIC. The LAPIC is integrated into each CPU in the system, and the I/O APIC is used throughout the system's peripheral buses. There is typically one I/O APIC for each peripheral bus in the system. In original system designs, LAPICs and I/O APICs were connected by a dedicated APIC bus. Newer systems use the system bus for communication between all APIC components. In systems containing an 8259 PIC, the 8259 may be connected to the LAPIC in the system's bootstrap processor (BSP), or to one of the system's I/O APICs.
LAPICs manage all external interrupts for the processor that it's part of. It's also able to send and receive inter-processor interrupts (IPIs) between LAPICs. LAPIC's can support up to 224 usable IRQ vectors from an I/O APIC. Vectors numbers 0 to 31, out of 0 to 255, are reserved for exception handling by x86 processors.
I/O APICs contain a redirection table, that is used to route the interrupts it receives from peripheral buses to one or more Local APICs.
The Intel APIC architecture is well known for having a large amount of unwanted variation in one or more of it's signals in its interrupt latency.
There are a number of known bugs in implementations of APIC systems, especially when it comes to how the 8259 is connected. There are defective BIOS implementations which don't setup interrupt routing properly. This includes the errors in the implementation of ACPI tables and Intel Multiprocessor Specification tables.
It can be a cause of system failure, as some versions of some operating systems don't support it properly. If this is the case, disabling I/O APIC may cure the problem. For Linux, try the 'noapic nolapic' kernel parameters; for FreeBSD, the 'hint.apic.0.disabled' kernel environment variable. In Linux, problems with I/O APIC are one of several causes of error messages concerning "spurious 8259A interrupt: IRQ7.". It's also possible that I/O APIC can cause problems with network interfaces based on the via-rhine driver, causing a transmission time out. Uniprocessor kernels with APIC enabled can cause spurious interrupts to be generated.
Lets stop for a moment and look at things from a Windows point of view. The PIC interrupt controller has a built-in hardware priority scheme that is not appropriate for machines running operating systems based on Windows NT Technology. To address this problem, a different hardware priority scheme is used by the oOS.
When the OS raises or lowers IRQL, a new mask is written into the 8259 that enables only the interrupts allowed at this IRQL. Raising or lowering IRQL causes either two "out" instructions or software simulation of one sort or another. Each of these I/O instructions must make it all the way to the South Bridge and back.
The Compaq Alpha interrupt controller has software levels that are used in Windows NT and Windows 2000 to cause DPC and APC interrupts. On Intel Architecture platforms using a PIC, this has to be simulated because there isn't any hardware to cause the interrupts. When the OS drops below DISPATCH_LEVEL, it must check to see whether a DPC has been queued. If it has, it must simulate an interrupt.
With an APIC device, the OS can queue a DPC at any time by sending itself an interrupt at a priority that matches DISPATCH_LEVEL. Then, whenever it lowers the IRQL below DISPATCH_LEVEL, the DPC fires in hardware with no software intervention at all.
Raising or lowering IRQL on an APIC is just a matter of adjusting the Task Priority Register in the local APIC. This is just a "mov" instruction that adjusts a register inside the processor. It can happen much more quickly than multiple writes to the South Bridge. Keep in mind that every time anything is synchronized using any of the Win32 or Windows NT native synchronization primitives, the IRQL is changed at least twice. APICs, therefore, provide better speed in interrupt handling.
Windows 95/98 both have a design requirement to support DOS device drivers. Because DOS drivers may assume that they can write directly to the 8259 PIC and its associated IDT entries, the APIC is unsupportable on these OS's. The 8259 PIC cannot be used in machines with multiple processors either.
The traditional 8259 PIC is subject to significant legacy issues. IRQs 0, 1, 2, 6, 8, 12, 13, 14, and 15 are consumed by legacy devices. Even when legacy devices are not present, these IRQs are often claimed by legacy software or firmware. IRQs 3 and 4 sometimes fall into this category as well. (COM1 and COM2)
This leaves IRQs 5, 7, 9, 10, and 11 available for general use on a typical machine. Audio hardware is almost always programmed to use IRQ 5. That leaves us with only four IRQs available for other devices to use. Most machines today have far more than four devices that are programmed to interrupt. APIC interrupt subsystems can have as many IRQs as are required in a specific machine. Chipset vendors usually design I/O APICs to have 24 IRQs each, and a client machine almost always contains only one I/O APIC. This is enough to guarantee a dedicated IRQ for each PCI device, which would make sharing necessary only when the user installs many devices.
In an APIC-based system, each PCI device can be routed directly to an interrupt controller input on an IOAPIC. Some can be routed directly to the I/O APIC, and some can be routed through the IRQ steering devices. Ideally, the chipset could include more steering devices. (No OEM has ever taken on the extra cost of providing steering devices outside the chipset, on single-processor systems.)
Most laptops are equipped with so few IRQs that they ship with the COM port or other internal devices disabled to ensure that IRQs remain available for PCMCIA devices. It gets worse on machines using docking stations. Laptops usually ship with confusing utilities that allow the end user to disable the modem, just so they can enable the COM port, and so on. Attempting to Compensating for the lack of IRQs in this way degrades the usability of the system by making users do what the software should do, and what it would do, if the hardware made it possible. The 8259 interrupt controller can actually drop interrupts, because of how it handles spurious interrupts. The APIC is less likely to have this problem.
In conclusion, the industry is constantly pushing forward to fix a major flaw in the original interrupt design. They are using APIC style designs along with message signaled interrupts to accomplish this goal. We've gone over the many types of interrupt detection and resolution, the good, the bad, and the ugly of it all. By now you should also have a deeper understanding of what goes on under the hood, as well as how even the smallest delay can become quite noticeable over time.
-=databat=-
Posted by databat at 5:00 AM 0 comments
Labels: Binary Hole - All Articles